Port sync is broken: Error: Failed to verify signature for ports tree!

[Sergio Had]

sent 78567 bytes  received 194729 bytes  20244.15 bytes/sec
total size is 125495808  speedup is 459.19
Error: Failed to verify signature for ports tree!
port sync failed: Synchronization of 1 source failed

There should be a requirement to check if a port exists before committing something right into the master

[Sergio Had]

Otherwise we get this: 
https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed

While LimeChat has existed for 4 years in MacPorts: 
https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile

And now two conflicting ports for the same thing.

Could someone run tests for gfortran on ppc32?

[Sergio Had]

Hi, I am working on some fix ups for gfortran on Darwin ppc, and it would be 
helpful to have a reference point of test results from another OS on the same 
arch.

Does anyone have a reasonably fast machine with OpenBSD to try that?

Ideally we should test gcc trunk. Clone gcc upstream repo, build gcc with 
gfortran enabled. From there cd to gcc directory (build_gcc_folder/gcc).

What I am interested in is the output from `make check-gfortran`, doing it with 
verbose would be nice.

Test results for macOS and related discussion: 
https://github.com/iains/darwin-toolchains-start-here/discussions/40#discussioncomment-9566907

gcc12/gcc13 will also do, if that is easier for some reason.

Sergey

Re: Glade should not use GJS on PowerPC

[Sergio Had]

For imlib2, rather add a fallback version of librsvg which does not need Rust 
to be used on ppc (and wherever else needed).

We use that on macOS for ppc and old x86, it works fine.

Serge
On Apr 28, 2024 at 00:53 +0800, George Koehler , wrote:
> On Fri, 26 Apr 2024 07:15:51 +0800
> Sergio Had  wrote:
>
> > Hi, could someone assist with fixing this?
> > We have XFCE unnecessarily broken due to dependency on GJS being forced. It 
> > is in fact optional and not required for Glade.
> >
> > It can be moved to a variant, and that variant made default for archs where 
> > GJS builds.
> >
> > Serge
>
> Sorry, this won't be enough. devel/glade depends (at runtime) on
> x11/gnome/devhelp which depends on www/webkitgtk4,webkitgtk41 but
> powerpc failed to build webkitgtk4. Therefore, even if one might
> build glade without x11/gnome/gjs, we still can't run glade without
> webkitgtk4, so we can't use glade to build x11/xfce4/libxfce4ui.
>
> We have a recent webkitgtk4 fix for powerpc [1], but nobody has built
> it yet, so we still don't know whether webkitgtk4 needs more fixes to
> finish the build.
> [1] https://marc.info/?l=openbsd-ports=171319628713727=2
>
> My webkitgtk4 build froze the kernel on my macppc G5 after several
> hours; I might need to build it on G4.
>
> graphics/imlib2 has logic to depend on x11/gnome/librsvg only for rust
> archs. We might want similar logic in glade to depend on gjs only for
> rust archs, but I'm not trying it until I have webkit and devhelp.
> --gkoehler

Glade should not use GJS on PowerPC

[Sergio Had]

Hi, could someone assist with fixing this?
We have XFCE unnecessarily broken due to dependency on GJS being forced. It is 
in fact optional and not required for Glade.

It can be moved to a variant, and that variant made default for archs where GJS 
builds.

Serge

Re: Git-devel has broken git-credential-osxkeychain.c for older systems

[Sergio Had]

Given it is in contrib, presumably it got its own upstream?
On Apr 21, 2024 at 11:24 +0800, Fred Wright , wrote:
>
> On Sat, 20 Apr 2024, Saagar Jha wrote:
>
> > Wait, I use osxkeychain. It’s basically a requirement if you’re pushing
> > to an authenticated server over HTTPS and don’t want to have to deal
> > with storing keys yourself. I suspect it is used a lot for this.
>
> I have yet to see a Git repo that didn't allow you to push via SSH
> (git://) rather than HTTPS, and that's preferable, anyway. I usually
> configure repos to use git:// in both directions, though git allows you to
> configure fetch and push separately if you want.
>
> I avoid Keychain as much as I possibly can, after reading in some
> documentation somewhere that it stores all your passwords on the disk in
> cleartext the entire time you're logged in.
>
> I have no objection to having the osxkeychain feature, but I don't
> recommend actually using it.
>
> Fred Wright
>
> > > On Apr 19, 2024, at 23:52, Kirill A. Korinsky  wrote:
> > >
> > > On Sat, 20 Apr 2024 00:25:47 +0200,
> > > Sergio Had wrote:
> > > >
> > > > What do we do? :)
> > >
> > > To fix the build you have two options:
> > > 1. Revert that patch for system before 10.7
> > > 2. Remove folder contrib/credential/osxkeychain
> > >
> > > I suggest to follow (2) as simpler thay and the good news that osxkeychain
> > > is something that isn't often used.

Re: Git-devel has broken git-credential-osxkeychain.c for older systems

[Sergio Had]

Is someone in touch with Git upstream? It should be pretty trivial to retain 
the working code, they are perhaps simply assuming that nobody uses it. Which 
is not the case, obviously.
On Apr 21, 2024 at 02:41 +0800, Kirill A. Korinsky , wrote:
> On Sat, 20 Apr 2024 18:19:30 +0200,
> Saagar Jha wrote:
> >
> > Wait, I use osxkeychain. It’s basically a requirement if you’re pushing to
> > an authenticated server over HTTPS and don’t want to have to deal with
> > storing keys yourself. I suspect it is used a lot for this.
> >
>
> Do you use on 10.6?
>
> I mean to remove it for 10.6 where it can't work after the patch.
>
> --
> wbr, Kirill

Re: Git-devel has broken git-credential-osxkeychain.c for older systems

[Sergio Had]

Yes, I also use it for this.

We want it to work.
On Apr 21, 2024 at 00:19 +0800, Saagar Jha , wrote:
> Wait, I use osxkeychain. It’s basically a requirement if you’re pushing to an 
> authenticated server over HTTPS and don’t want to have to deal with storing 
> keys yourself. I suspect it is used a lot for this.
>
> > On Apr 19, 2024, at 23:52, Kirill A. Korinsky  wrote:
> >
> > On Sat, 20 Apr 2024 00:25:47 +0200,
> > Sergio Had wrote:
> > >
> > > What do we do? :)
> >
> > To fix the build you have two options:
> > 1. Revert that patch for system before 10.7
> > 2. Remove folder contrib/credential/osxkeychain
> >
> > I suggest to follow (2) as simpler thay and the good news that osxkeychain
> > is something that isn't often used.
> >
> > --
> > wbr, Kirill

Git-devel has broken git-credential-osxkeychain.c for older systems

[Sergio Had]

See: 
https://lore.kernel.org/all/f7031316a043b36fac10ecf784d2294894967e7b.1708212896.git.gitgitgad...@gmail.com/

Fails on 10.6 Intel now: 
https://github.com/macports/macports-ports/commit/e21cd2a3df66db81d79807fd83b5a7742fa07f97#commitcomment-141174012

What do we do? :) 

Python build system help needed for py-pyobjc6

[Sergio Had]

Could someone please look into https://trac.macports.org/ticket/69728 ticket?
I need this port now, but it is broken by some change in Python builds.
Since it uses custom a set-up, it is confusing what to do with it to have it 
built and installed properly.

After 7.5 update PowerBook stopped seeing iPhone hotspot

[Sergio Had]

Hi, has anyone encountered the issue?

I literally used the same hotspot for sysupgrade from 7.4, that went nicely, 
however after rebooting into 7.5 the PowerBook cannot see it anymore.
Wifi itself works: at least, ifconfig bwi0 scan shows other Wifi networks, but 
not the iPhone one.
At the same time MacBook with macOS sees iPhone hotspot (so the issue is only 
on OpenBSD side, not with the iPhone as such).

File with settings is unchanged, but trying to invoke sh /etc/netstart bwi0 has 
no effect now: hotpot is invisible for 7.5.

Best regards,
Sergey

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

[Sergio Had]

Well, the PR is either merged or not merged :)

I think my proposal addresses all possible rational concerns.
If irrational concerns will happen to dominate, well, I can’t do anything about 
that.


> On Mar 29, 2024, at 7:47 PM, Ken Cunningham  
> wrote:
> 
> I am not a MacPorts admin, however I believe they were pretty clear that 
> 10.6-ppc-specific fixes belong in an overlay repo, not in macports code.
> 
> If you want that changed, take it up with them.
> 
> I personally agree with that decision, so I abide by it, until such time as 
> it changes.
> 
> K
> 
> 
> 
>> On Mar 29, 2024, at 04:00, Sergio Had  wrote:
>> 
>> 
>> Ken, the last time you objected to having gcc10-bootstrap building for ppc 
>> on 10.6 in gcc13 port.
>> Because that was extra 10 characters of code in the macro, which was too 
>> ugly to tolerate, apparently.
>> (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use 
>> clangs on any powerpc, be it released macOS or pre-released.)
>> 
>> Anyway, what I suggest is the following:
>> 
>> 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
>> only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
>> code”, which you dislike.
>> 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can 
>> add tweaks I want, and restrict that port to PowerPC. Throw away everything 
>> unneeded from there, make it easy to maintain.
>> 
>> To that separate port I can add support for libc++ on PowerPC, fix IEEE 
>> arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which 
>> will not land into any other gcc ports, unless someone else – not me – 
>> decides to pick that.
>> 
>> As I bonus I (and whomever decides to use it) can avoid unnecessary 
>> revbumps, wasting many hours of compilation time for nothing, and on the 
>> other hand revbump powerpc port without causing pain to anyone else.
>> 
>> I honestly hope this can keep everyone satisfied.
>> 
>> I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, 
>> since we should not have a disagreement anymore.
>> 
>> 
>>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham 
>>>  wrote:
>>> 
>>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
>>> anything to do with why nobody had gotten around to updating the gcc 
>>> version used on older systems.
>>> 
>>> At least, it was not anywhere on my radar.
>>> 
>>> Just -- nobody did the legwork.
>>> 
>>> Ken
>>> 
>>> 
>>> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
>>> 
>>>> Let me make another, final attempt to sort this out once for all and for 
>>>> everyone on old systems.
>>>> 
>>>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
>>>> on 10.6 in gcc ports and my need to support those.
>>>> 
>>>> That was the stopper so far, not allowing an agreement to merge.
>>>> 
>>>> I may do this today itself: I have everything working for months, just 
>>>> need to sort commits to make it readable and implement a solution for what 
>>>> I want.
>>>> 
>>>> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
>>>> existed on ppc.
>>>> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
>>>>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 
>>>>> too). I have seen people using gcc13 on 10.5 ppc following my 
>>>>> instructions from the PR.
>>>>> 
>>>>> What is the point of gcc8?
>>>>> 
>>>>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
>>>>> needed in between.
>>>>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
>>>>> , wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> after all the talk about gcc versions, I tried to build gcc 8 here.
>>>>>> Officially it says "gcc8 is known to fail".
>>>>>> 
>>>>>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
>>>>>> later, I fear my MacBook has fan issues.
>>>>>> 
>>>>>> Intel 64bit finished build! Took several hours. I thus tried to install
>>>>>> it... and it says again
>>>>>> "libgcc8 is kno

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

[Sergio Had]

Ken, the last time you objected to having gcc10-bootstrap building for ppc on 
10.6 in gcc13 port.
Because that was extra 10 characters of code in the macro, which was too ugly 
to tolerate, apparently.
(It was needed for 10.6.8 Rosetta just as much, of course: we cannot use clangs 
on any powerpc, be it released macOS or pre-released.)

Anyway, what I suggest is the following:

1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
code”, which you dislike.
2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can add 
tweaks I want, and restrict that port to PowerPC. Throw away everything 
unneeded from there, make it easy to maintain.

To that separate port I can add support for libc++ on PowerPC, fix IEEE 
arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which will 
not land into any other gcc ports, unless someone else – not me – decides to 
pick that.

As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, 
wasting many hours of compilation time for nothing, and on the other hand 
revbump powerpc port without causing pain to anyone else.

I honestly hope this can keep everyone satisfied.

I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, since 
we should not have a disagreement anymore.


> On Mar 29, 2024, at 5:34 AM, Ken Cunningham  
> wrote:
> 
> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
> anything to do with why nobody had gotten around to updating the gcc version 
> used on older systems.
> 
> At least, it was not anywhere on my radar.
> 
> Just -- nobody did the legwork.
> 
> Ken
> 
> 
> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
> 
>> Let me make another, final attempt to sort this out once for all and for 
>> everyone on old systems.
>> 
>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
>> on 10.6 in gcc ports and my need to support those.
>> 
>> That was the stopper so far, not allowing an agreement to merge.
>> 
>> I may do this today itself: I have everything working for months, just need 
>> to sort commits to make it readable and implement a solution for what I want.
>> 
>> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
>> existed on ppc.
>> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
>>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). 
>>> I have seen people using gcc13 on 10.5 ppc following my instructions from 
>>> the PR.
>>> 
>>> What is the point of gcc8?
>>> 
>>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
>>> needed in between.
>>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
>>> , wrote:
>>>> Hi,
>>>> 
>>>> after all the talk about gcc versions, I tried to build gcc 8 here.
>>>> Officially it says "gcc8 is known to fail".
>>>> 
>>>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
>>>> later, I fear my MacBook has fan issues.
>>>> 
>>>> Intel 64bit finished build! Took several hours. I thus tried to install
>>>> it... and it says again
>>>> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
>>>> 
>>>> However then it asks about libgcc9 but I want to stay on libgcc8,
>>>> that was the point... am Inheriting that it will go up to gcc13?
>>>> 
>>>> 
>>>> On PowerPC instead build fails (and ultimate goal is to enable newer
>>>> gccs on PPC too, where it is needed)
>>>> 
>>>> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
>>>> '-fPIC', '-fpie' or '-fPIE'
>>>> :info:build
>>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
>>>> In member function 'gcc::jit::result*
>>>> gcc::jit::playback::context::dlopen_built_dso()':
>>>> :info:build
>>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
>>>> error: 'dlerror' was not declared in this scope
>>>> :info:build dlerror ();
>>>> :info:build ^~~
>>>> 
>>>> 
>>>> Already seen this? Full build log is 6.7MB
>>>> Should I open a ticket on this or is there already one for gcc8 efforts?
>>>> didn't find it.
>>>> 
>>>> Riccardo
> 

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

[Sergio Had]

Let me make another, final attempt to sort this out once for all and for 
everyone on old systems.

I got an idea how to satisfy Ken’s preference of not supporting ppc builds on 
10.6 in gcc ports and my need to support those.

That was the stopper so far, not allowing an agreement to merge.

I may do this today itself: I have everything working for months, just need to 
sort commits to make it readable and implement a solution for what I want.

As a bonus, you will get IEEE intrinsics in Fortran – something that never 
existed on ppc.
On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I 
> have seen people using gcc13 on 10.5 ppc following my instructions from the 
> PR.
>
> What is the point of gcc8?
>
> You build gcc10-bootstrap and then use it to build gcc13. Nothing else needed 
> in between.
> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
> , wrote:
> > Hi,
> >
> > after all the talk about gcc versions, I tried to build gcc 8 here.
> > Officially it says "gcc8 is known to fail".
> >
> > I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
> > later, I fear my MacBook has fan issues.
> >
> > Intel 64bit finished build! Took several hours. I thus tried to install
> > it... and it says again
> > "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
> >
> > However then it asks about libgcc9 but I want to stay on libgcc8,
> > that was the point... am Inheriting that it will go up to gcc13?
> >
> >
> > On PowerPC instead build fails (and ultimate goal is to enable newer
> > gccs on PPC too, where it is needed)
> >
> > :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
> > '-fPIC', '-fpie' or '-fPIE'
> > :info:build
> > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
> > In member function 'gcc::jit::result*
> > gcc::jit::playback::context::dlopen_built_dso()':
> > :info:build
> > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
> > error: 'dlerror' was not declared in this scope
> > :info:build dlerror ();
> > :info:build ^~~
> >
> >
> > Already seen this? Full build log is 6.7MB
> > Should I open a ticket on this or is there already one for gcc8 efforts?
> > didn't find it.
> >
> > Riccardo

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

[Sergio Had]

You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I 
have seen people using gcc13 on 10.5 ppc following my instructions from the PR.

What is the point of gcc8?

You build gcc10-bootstrap and then use it to build gcc13. Nothing else needed 
in between.
On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
, wrote:
> Hi,
>
> after all the talk about gcc versions, I tried to build gcc 8 here.
> Officially it says "gcc8 is known to fail".
>
> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
> later, I fear my MacBook has fan issues.
>
> Intel 64bit finished build! Took several hours. I thus tried to install
> it... and it says again
> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
>
> However then it asks about libgcc9 but I want to stay on libgcc8,
> that was the point... am Inheriting that it will go up to gcc13?
>
>
> On PowerPC instead build fails (and ultimate goal is to enable newer
> gccs on PPC too, where it is needed)
>
> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
> '-fPIC', '-fpie' or '-fPIE'
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
> In member function 'gcc::jit::result*
> gcc::jit::playback::context::dlopen_built_dso()':
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
> error: 'dlerror' was not declared in this scope
> :info:build dlerror ();
> :info:build ^~~
>
>
> Already seen this? Full build log is 6.7MB
> Should I open a ticket on this or is there already one for gcc8 efforts?
> didn't find it.
>
> Riccardo

Re: wget errors - malloc

[Sergio Had]

This should fix it: https://github.com/macports/macports-ports/pull/23248


> On Mar 27, 2024, at 11:14 PM, Sergio Had  wrote:
> 
> Oh, I can confirm the error on my side too.
> 
> Let me try fixing it.
> 
> 
> 
>> On Mar 27, 2024, at 9:53 PM, Sergio Had  wrote:
>> 
>> You could try adding this to its portfile:
>> 
>> PortGroup   legacysupport 1.1
>> legacysupport.redirect_bins wget
>> 
>> And rebuild it.
>> If it solved the issue, perhaps submit a PR.
>> 
>> 
>>> On Mar 27, 2024, at 5:41 PM, Riccardo Mottola via macports-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I just noticed this on 10.5 intel 64bit... Often I don't check the
>>> console so I don't know if it is fresh.
>>> 
>>> Artax:~ multix$ wget
>>> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
>>> wget(77577) malloc: *** error for object 0x7fff7020c200:
>>> non-page-aligned, non-allocated pointer being freed
>>> *** set a breakpoint in malloc_error_break to debug
>>> wget(77577) malloc: *** error for object 0x7fff7020c120: Non-aligned
>>> pointer being freed (2)
>>> *** set a breakpoint in malloc_error_break to debug
>>> --2024-03-27 10:37:25--
>>> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
>>> Resolving github.com (github.com)... 140.82.121.4
>>> Connecting to github.com (github.com)|140.82.121.4|:443... connected.
>>> HTTP request sent, awaiting response... 302 Found
>>> 
>>> 
>>> I'll test on other systems and see what happens and if there is a
>>> batter, but please test too.
>>> 
>>> 
>>> Riccardo
>> 
> 

Re: wget errors - malloc

[Sergio Had]

Oh, I can confirm the error on my side too.

Let me try fixing it.



> On Mar 27, 2024, at 9:53 PM, Sergio Had  wrote:
> 
> You could try adding this to its portfile:
> 
> PortGroup   legacysupport 1.1
> legacysupport.redirect_bins wget
> 
> And rebuild it.
> If it solved the issue, perhaps submit a PR.
> 
> 
>> On Mar 27, 2024, at 5:41 PM, Riccardo Mottola via macports-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I just noticed this on 10.5 intel 64bit... Often I don't check the
>> console so I don't know if it is fresh.
>> 
>> Artax:~ multix$ wget
>> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
>> wget(77577) malloc: *** error for object 0x7fff7020c200:
>> non-page-aligned, non-allocated pointer being freed
>> *** set a breakpoint in malloc_error_break to debug
>> wget(77577) malloc: *** error for object 0x7fff7020c120: Non-aligned
>> pointer being freed (2)
>> *** set a breakpoint in malloc_error_break to debug
>> --2024-03-27 10:37:25--
>> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
>> Resolving github.com (github.com)... 140.82.121.4
>> Connecting to github.com (github.com)|140.82.121.4|:443... connected.
>> HTTP request sent, awaiting response... 302 Found
>> 
>> 
>> I'll test on other systems and see what happens and if there is a
>> batter, but please test too.
>> 
>> 
>> Riccardo
> 

Re: wget errors - malloc

[Sergio Had]

You could try adding this to its portfile:

PortGroup   legacysupport 1.1
legacysupport.redirect_bins wget

And rebuild it.
If it solved the issue, perhaps submit a PR.


> On Mar 27, 2024, at 5:41 PM, Riccardo Mottola via macports-dev 
>  wrote:
> 
> Hi,
> 
> I just noticed this on 10.5 intel 64bit... Often I don't check the
> console so I don't know if it is fresh.
> 
> Artax:~ multix$ wget
> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
> wget(77577) malloc: *** error for object 0x7fff7020c200:
> non-page-aligned, non-allocated pointer being freed
> *** set a breakpoint in malloc_error_break to debug
> wget(77577) malloc: *** error for object 0x7fff7020c120: Non-aligned
> pointer being freed (2)
> *** set a breakpoint in malloc_error_break to debug
> --2024-03-27 10:37:25--
> https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
> Resolving github.com (github.com)... 140.82.121.4
> Connecting to github.com (github.com)|140.82.121.4|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> 
> 
> I'll test on other systems and see what happens and if there is a
> batter, but please test too.
> 
> 
> Riccardo

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

[Sergio Had]

Just for the record, cmake-devel 3.29.0 works fine for me on native systems 
where 3.28.1 was failing (10.6 ppc and 10.6 i386).

It does not build on 10.6.8 Rosetta, likely due to an unrelated issue, but this 
is not a stopper, since no one uses Rosetta outside of testing/development. If 
anyone happens to use Macports in Rosetta (I recall Kirill had such a set-up), 
the last version to work there is 3.28.4 from Ken’s recent update to the port.


> On Mar 27, 2024, at 8:48 PM, Ken Cunningham  
> wrote:
> 
> We sorted out a workaround for the failing systems that was incorporated 
> upstream, and after some further testing, updated the cmake port to the 
> current version on all systems.
> 
> Both cmake and cmake-devel are about the same now, so feel free to go back to 
> the main cmake port.
> 
> Tiger needs verification.
> 
> K
> 
>> On Mar 27, 2024, at 02:29, Riccardo Mottola  
>> wrote:
>> 
>> Hi Ken,
>> 
>> Ken Cunningham wrote:
>>> 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.
>>> 
>> 
>> I deactivated cmake and installed cmake-devel as test on 10.5 intel
>> 64bit, 10.7, 10.11
>> 
>> Build when file on all systems. I think the best test is using it during
>> more upgrades... I don't remember off-hand which ports use to test.
>> I hope that w e don't get red-herrings of failures on other packages due
>> to that.
>> 
>>> 
>>> 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.
>> 
>> At a first glance I don't understand the issue, it looks like
>> compiler/linker gets confused. If you want... we can try to tinker on it.
>> 
>> Riccardo

wxWidgets-related question

[Sergio Had]

Does anyone know what is responsible in wxWidgets 3.0 for dialog windows 
handling, and specifically buttons in those like Okay?
Those are broken on 10.6 for me: any dialog window which opens does not respond 
to Okay or Cancel at all.

Everything works fine on 10.8 though, from the same port.

I briefly looked into patches we apply, and nothing appears relevant to the 
matter.
Perhaps a bug in the upstream code, due to lack of testing for < 10.7. As usual.

Re: MacPorts vs. Apple compiler issues, Handle

[Sergio Had]

Well, “involved” perhaps was too much of a statement, I meant we communicated 
on the matter and it was/is work-in-progress to make it work on PowerPC.

We got White Star (Palemoon) building on ppc not long ago btw, but it does not 
yet run.

P. S. I should change my Gmail settings, otherwise I’m unrecognizable :)
@barracuda156
On Mar 20, 2024 at 00:30 +0800, Riccardo Mottola , 
wrote:
> Hi,
>
> Sergio Had wrote:
> > Could you refer me to the beginning of this discussion please?
> it started on the Mac Users mailing list, you can find in the archives!
>
>
> >
> > I am also involved in AF project:)
>
> Oh, I am curious, how?
> I am essentially the only active developer currently, except Roy who
> does its windows fork.
>
> Riccardo

Re: MacPorts vs. Apple compiler issues, Handle

[Sergio Had]

Could you refer me to the beginning of this discussion please?

I am also involved in AF project :)


> On Mar 19, 2024, at 10:11 AM, Joshua Root  wrote:
> 
> (Moving to macports-dev as it is a better fit for this topic.)
> 
> On 18/3/2024 22:50, Riccardo Mottola wrote:
>> I will do another compilation reducing the optimization level. GCC has an 
>> issue where beyond gcc6 certain optimizations need to be disabled, or AF 
>> crashes.
> 
> Issues that only appear at higher optimisation levels also often involve 
> undefined behaviour.
> 
>> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes:   KERN_INVALID_ADDRESS at 0x7ffe2007
> 
> So here is what happened: SIGSEGV means the program tried to access memory 
> that it should not have. The page was not mapped or had the wrong permissions 
> for what it was trying to do. The memory address that it attempted to access 
> is also shown.
> 
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   XUL   0x00010f5468e1 
>> nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char 
>> const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, 
>> nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273
> 
> And this is where it happened. Since this is not a full debug build, there is 
> no line number information, but you at least know which method is doing the 
> bad memory access.
> 
> - Josh

SDL2 on PowerPC: it works now, can we fix joystick for it?

[Sergio Had]

Upon sorting X11 installation, turned out that most of X11 ports actually work 
with GUI on PowerPC, including SDL2 and VLC.

However, most of Macports dependents of libsdl2 are games and emulators, and 
they need a joystick module, which is broken quite badly in SDL 2.1+.
So those ports will build but won’t start, complaining about joystick support 
missing.

Even without that, SDL is useful (SDL video out works with VLC now), and 
personally I do not really care for games’ support, but apparently there is a 
demand, so why not make someone happier :)

Can we find a way to fix it?

Re: GTK on PowerPC: does anyone have it actually working?

[Sergio Had]

Well, I have VLC2 and SDL2 working on 10.6 PowerPC now :) 

VLC2 looks good now, no messed up colors anymore. SDL2 needs more testing, but 
I am able to run Grafx2, for example, and it actually works (but very slow, not 
sure if the code is that bad or SDL2 is that slow as such).



> On Mar 16, 2024, at 9:06 AM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Mar 15, 2024, at 6:05 PM, Ken Cunningham 
>>  wrote:
>> 
>> 
>> 
>>> On Mar 14, 2024, at 4:07 AM, Sergio Had  wrote:
>>> 
>>> I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
>>> `transmission-x11` 
>> 
>> transmission-x11 works on 10.6 PPC.
>> 
>> (I had to do a little minor surgery on the transmission source code to make 
>> it build with gcc7.)
>> 
>> Ken
> 
> Freudian slip :>
> 
> Works on 10.5 PPC.

Re: GTK on PowerPC: does anyone have it actually working?

[Sergio Had]

Ok, you inspired me to finally sort out the mess with X11.

And it works in fact.

Transmission-x11 is running on 10.6 ppc now with GUI too.



> On Mar 16, 2024, at 9:06 AM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Mar 15, 2024, at 6:05 PM, Ken Cunningham 
>>  wrote:
>> 
>> 
>> 
>>> On Mar 14, 2024, at 4:07 AM, Sergio Had  wrote:
>>> 
>>> I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
>>> `transmission-x11` 
>> 
>> transmission-x11 works on 10.6 PPC.
>> 
>> (I had to do a little minor surgery on the transmission source code to make 
>> it build with gcc7.)
>> 
>> Ken
> 
> Freudian slip :>
> 
> Works on 10.5 PPC.

Re: Ruby question: solution for dependency version specs?

[Sergio Had]

> On Mar 17, 2024, at 6:09 AM, Austin Ziegler  wrote:
> I reiterate that Ruby application ports (like sup or t) should *probably* be 
> set up more like Go or Rust ports and that a tool like `go2port` or 
> `cargo2port` (`gemspec2port, bundler2port`) which ultimately downloads the 
> gemfiles and uses `gem install --local …` will be better than blindly 
> modifying the *intentional* use of `~> 3.0` or installing `rb33-launch 3.0`.

If you could find time to modify Ruby PG to allow this kind of thing, it would 
be great.

At the moment there are simply no tools to allow it, AFAIU.

Re: Ruby question: solution for dependency version specs?

[Sergio Had]

> On Mar 17, 2024, at 12:57 AM, Austin Ziegler  wrote:
> 
> I am most definitely a Ruby expert, but I have yet to run any version of Ruby 
> from MacPorts (because I use `ruby-build` and `mise` to build versions of 
> Ruby that I require), and I almost exclusively install Ruby packages via `gem 
> install`.

You could perhaps try sudo port install ruby33 or whatever needed?
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.

> Many gemspecs contain information about the minimum Ruby that they require to 
> run (mime-types 3 requires Ruby 2+, 
> https://github.com/mime-types/ruby-mime-types/blob/main/mime-types.gemspec#L20;
>  diff-lcs advertises compatibility with Ruby 1.8+; app_identity advertises 
> Ruby 2.7+, but not Ruby 4, 
> https://github.com/KineticCafe/app_identity/blob/8afdd1caaab8d18032f60416eb62add88d308ee0/ruby/app_identity.gemspec#L21).

What I mean is that gemspec files often require a version of some another gem 
using ~> instead of >= like https://rubygems.org/gems/t
That prevents gems from running if a dependency is newer. For example, 
rb-launchy is at 3.0.0: https://rubygems.org/gems/launchy
Then I need to do something like this: 
https://github.com/macports/macports-ports/blob/c778ebc838a41e5761b76e7c6bc5a7ec3c256ab2/ruby/rb-t/Portfile#L30-L33
Problem is that this is quite painful to deal with for every relevant case.

> I don't know whether the Ruby and various gem ports are set up to work like 
> the Python and package ports (e.g., py311, py311-requests), but as each gem 
> must be installed into each Ruby, that's the best approach to use (e.g., for 
> *every* Ruby port, there should be Ruby version ports; rb-diff-lcs and 
> rb19-diff-lcs should have versions for rb18, rb19, rb20, rb21, rb22, rb23, 
> rb24, rb25, rb26, rb27, rb30, rb31, rb32, and rb33).
> 
> 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).

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.

> *Or* there should be an option with Ruby ports to treat them like non-offline 
> Go ports and allow them to do `gem install` or `bundle install` for more 
> complex environments.
> 
> Unfortunately, my tcl isn't really good enough (aside from what bits of Tcl 
> I’ve done now that I am contributing to MacPorts port maintenance, I last 
> used Tcl in about 2004) to start working with rethinking the Ruby portgroup 
> to have something like `ruby.bundle` or `ruby.gems` that works like 
> `cargo.crates` or `go.vendors`, which would *probably* be the better choice 
> (and it would pull from `rubygems.org ` *not* 
> github.com ; gems are source distributions most of the 
> time, although some gems exist that contain precompiled binaries for 
> hard-to-build dependencies).

I think that is done in most of the case already.
Only a few Ruby ports use GitHub, and that is either historically (and should 
be switched to RubyGems) or for a specific reason.
https://ports.macports.org/port/rb33-sup/details
https://github.com/macports/macports-ports/blob/c778ebc838a41e5761b76e7c6bc5a7ec3c256ab2/ruby/rb-sup/Portfile#L7-L16

Precompiled libs is a problem, unfortunately, and some upstream is not 
interested to bother fixing it.
https://github.com/ankane/lightgbm-ruby/issues/7
In result, that is a broken package.

Ruby question: solution for dependency version specs?

[Sergio Had]

Any Ruby experts among us?

Some Ruby ports hardcode versions for dependencies in a form restricting those 
to a given major or minor version. Since many Ruby gems are not updated for 
years (but still required for other stuff), this presents a problem: any 
dependency using those will build but not run.
Is there a way to solve this other than by patching every such instance? 
Patching works but is pretty tedious.
Ideally a solution via Ruby PG is preferred, I think.

Re: GTK on PowerPC: does anyone have it actually working?

[Sergio Had]

> On Mar 14, 2024, at 5:33 PM, Riccardo Mottola via macports-dev 
>  wrote:
> 
> Hi,
> 
> Ken Cunningham wrote:
>> gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.
> 
> I'm hacking on GTK2 and GTK3 quartz support for Leopard... intel first, they 
> were working well enough to get gimp starting up (gtk2...)

I think I could not get it to start, though it builds fine.

> The only other GTK3 app I use is meld, which is now unusable (doesn't even 
> show a window) on 10.6 and 10.7, so I didn't even attempt on 10.5. on 
> 10.11-10.13 it has heavy redraw issues (has since about a year). But it is 
> really a maze of dependencies, so I don't know if the bug is in GTK or one of 
> the many dependent libraries.

I did have problems with GTK and X11 ports on 10.6 ppc, but however:

1. 10.6 ppc is not an officially supported system in Macports, so some stuff 
may need extra fix-ups (usually trivial – fix some macros).
2. It is not impossible that I have a messed-up X11, since macOS implementation 
may conflict with MacPorts one, and there is also XQuartz. Unfortunately, there 
is no clear instruction how to go about that, and I have seen related 
complaints re 10.5 and 10.4.

Once I rebuild gcc13 on Leopard, I will try again there.

> I will try to build on 10.5 PPC tomorrow and see how things fare
> 
> What app(s) do you use?


I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
`transmission-x11` and `gtk-gnutella`?

P. S. On a side note, wxWidgets 3.1 also does not work for me, at least on 
PowerPC. At the same time almost everything Qt4-based works beautifully. 
Cocoa-based apps work, as long as the code does not rely on incompatible ObjC 
syntax and new SDKs.

Re: inserting -stdlib=libstdc++ into cxxflags

[Sergio Had]

> On Mar 13, 2024, at 4:07 AM, René J.V. Bertin  wrote:
> 
>> Building against libstdc++ is broken for Intel
> 
> Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ 
> from GCC13 and that works.

What I rather meant is that Macports cannot handle that properly, since it is 
kinda hardcoded to use clang and libc++ on anything besides powerpc.
I think we have a few older ports broken now, which required libstdc++.

> Yes, gcc 13 isn't yet compatible with libc++, but the current -stdlib=libc++ 
> implementation also fails (for me) on Qt5 (5.9) projects because libc++ has 
> its own version of (IIRC) cstddef and raises an error if the one from GCC has 
> already been included. To avoid that the c++/v1 directory must be before the 
> GCC C header dirs in the search list, and not after as GCC currently does it. 
> I've signalled that, and you can achieve the same thing with the traditional 
> recipe to use libc++ with GCC: `-nostdinc++ -isystem/path/to/c++/v1`.

AFAIK nobody tested GCC with libc++, neither in upstream nor in Macports, so it 
is not overly surprising that it does not work :) 

It is worth opening a ticket on GCC Bugzilla, if there is none yet for this 
issue.

> FWIW, I patched GCC 6 and 7 back in the day to add a `-stdlib=` argument. I 
> don't really know why I didn't use it, probably because the concurrent clang 
> versions were still faster. That's no longer the case; GCC 12 is about as 
> slow as clang 12 (but a lot more modern, with full, non-buggy C++20 support, 
> and apparently less resource hungry).

On a side note, for older Intel systems it is not even clear if libc++ is a 
better choice.

Re: inserting -stdlib=libstdc++ into cxxflags

[Sergio Had]

Which OS are we talking about?

Building against libstdc++ is broken for Intel and arm64, I believe, though it 
should be fixable. But the problem is not passing the flag, but broken Apple 
headers, it seems.
I managed to build some ports like CMake and a few others against libstdc++ on 
Sonoma arm64, but kinda gave up, since too much stuff is broken, and there is 
no immediate advantage in the switch.
I have this in macports.conf: `cxx_stdlib macports-libstdc++` (on Sonoma). 
However you may need to pass both cxxflags and ldflags manually.

On PowerPC it is the reverse: building against libstdc++ is the default and 
works fine, building against libc++ is very experimental and will likely need 
fixups. Also, it requires enabling stdlib_flag variant for gcc and making it 
use libcxx-powerpc port instead of clangs.

P. S. There is a bug in gcc13 which prevents it working correctly with libc++ 
headers (regardless of the arch, I think), should be fixed in upstream but 
perhaps not in Macports, but gcc12 should be fine.



> On Mar 13, 2024, at 3:32 AM, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I've been tinkering a bit with a personal GCC12 build patched to use libc++ 
> by default, and now find myself unable to build against libstdc++.
> 
> `configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out 
> somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears 
> not to have any effect either. I'm not seeing any warnings in the logfile, 
> which is surprising (and rather bad practise IMHO).
> 
> What am I missing here, and what backdoor(s) could I use? I notice that 
> CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet 
> checked if "base" preserves its settings when initialising it (have been 
> assuming it won't). With autoconf-based projects one can set `configure.cxx 
> ${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based 
> projects...
> 
> Thanks,
> R.

Re: maintaining packages in macports vs. in a language package manager

[Sergio Had]

From my limited experience, most of OCaml ports are pretty trivial to write 
portfiles even by hand. (This does not apply to heavy and complex stuff like 
coq, of course.)

You just need to pick the right build system and use existing port examples.

But yes, automatic parsing would be helpful to have. (If anyone knows about the 
same for R packages, that would also be great.)


> On Mar 11, 2024, at 5:58 AM, Perry Metzger  wrote:
> 
> On 3/9/24 13:26, Zero King wrote:
>> It seems that we are going with option 2 for ocaml ports now and many new 
>> ports
>> have being added. Are you aware of any tool like pypi2port that could help
>> speed up the process of packaging new ocaml ports for MacPorts?
> 
> So I'm not familiar with such a tool yet. However, opam files contain all the 
> information MacPorts would want to build an ocaml package, and it should be 
> very simple to parse them into Portfiles. The format of an opam file is 
> pretty trivial. I never have had the time to do this, but it would be very 
> welcome if someone did it.
> 
> Perry
> 

Re: GTK on PowerPC: does anyone have it actually working?

[Sergio Had]

Thank you, Ken, this is helpful.

Could you say whether you did any specific manual setup for X11?



> On Mar 11, 2024, at 3:36 AM, Ken Cunningham  
> wrote:
> 
> 
> 
>> Sergey said:
> 
>> It looks like while even gtk4 builds fine with no hacks (and of course gtk2 
>> and gtk3 do), none of the apps built against then actually work. Everything 
>> crashes on start.
>> 
>> Could anyone confirm if any GTK version is known to work on a PPC system, 
>> and point at a specific app to test?
>> 
> 
> gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.
> 
> Just installed pan2 and a few other ports and no issues noted.
> 
> 

Re: CI are forcing tests for ports where tests are disabled

[Sergio Had]

Thank you, Josh, I will look into changing that then.


> On Feb 29, 2024, at 2:46 PM, Joshua Root  wrote:
> 
> Oh I see, the R portgroup is overriding the test phase entirely, which makes 
> test.run useless. Don't do that; set test.cmd, test.args and so on.
> 
> - Josh
> 
> On 29/2/2024 18:34, Sergio Had wrote:
>> I believe, they were not forced for R stuff until /very/ recently.
>> I found a solution which should work to fix running tests for R packages 
>> even when tests are unsupported and forced to run, but this situation is 
>> quite fragile.
>> For the context: there are some R packages which are in themselves trivial, 
>> but required as dependencies for some important ones. By default R checks 
>> require all /optional/ dependencies to be installed, which sometimes means 
>> /a lot/ of stuff to build. Adding every such optional dependency to MacPorts 
>> just to support testing is a) practically unfeasible and b) hardly needed. 
>> So while I tend to add support for testing wherever find it important or 
>> wherever it does not take too much of effort, there are a number of packages 
>> which have /test.run no – /and that is unlikely to change.
>> While default behavior of R can be changed via passing a variable in 
>> environment, this a) does not guarantee that some tests won’t fail due to 
>> missing optional dependency nevertheless and b) is not clearly a superior 
>> choice, since it becomes less clear if some optional dependencies are 
>> missing (which we may care about in specific cases).
>>> On Feb 29, 2024, at 2:17 PM, Joshua Root  wrote:
>>> 
>>> On 29/2/2024 17:01, Sergey Fedorov wrote:
>>>> There is something broken with CI now.
>>>> Tests phase must not be run when it is disabled (test.run is set to no), 
>>>> but it is.
>>> 
>>> Built-in tests can always be run. See 2.9 release notes.
>>> 
>>> - Josh
> 

Re: CI are forcing tests for ports where tests are disabled

[Sergio Had]

I believe, they were not forced for R stuff until very recently.

I found a solution which should work to fix running tests for R packages even 
when tests are unsupported and forced to run, but this situation is quite 
fragile.

For the context: there are some R packages which are in themselves trivial, but 
required as dependencies for some important ones. By default R checks require 
all optional dependencies to be installed, which sometimes means a lot of stuff 
to build. Adding every such optional dependency to MacPorts just to support 
testing is a) practically unfeasible and b) hardly needed. So while I tend to 
add support for testing wherever find it important or wherever it does not take 
too much of effort, there are a number of packages which have test.run no – and 
that is unlikely to change.
While default behavior of R can be changed via passing a variable in 
environment, this a) does not guarantee that some tests won’t fail due to 
missing optional dependency nevertheless and b) is not clearly a superior 
choice, since it becomes less clear if some optional dependencies are missing 
(which we may care about in specific cases).


> On Feb 29, 2024, at 2:17 PM, Joshua Root  wrote:
> 
> On 29/2/2024 17:01, Sergey Fedorov wrote:
>> There is something broken with CI now.
>> Tests phase must not be run when it is disabled (test.run is set to no), but 
>> it is.
> 
> Built-in tests can always be run. See 2.9 release notes.
> 
> - Josh

Re: How to force run tests as non-root?

[Sergio Had]

Could you reproduce the issue? I tried a number of ways to fix that, but 
nothing worked.
Sudo anything does not work from the portfile code, and I am not sure how to 
otherwise emulate “sudo -u normal-non-root-user”.

(If you got no arm64 hardware, presumably things will be the same on 
recent-enough x86_64, though I cannot verify that. For the same reason I cannot 
try running tests with 2.x version, as there is no Qt5 support in it.)
On Feb 25, 2024 at 04:49 +0700, Ken Cunningham 
, wrote:
> You are completely right, and I was wrong about this.
>
> I am now not certain how it came to be that macports was installed under the 
> root user for the 10.6-ppc installation in the mentioned ticket (assuming I 
> got the part right).
>
> K
>
> > On Feb 24, 2024, at 13:07, Joshua Root  wrote:
> >
> > On 25/2/2024 03:07, Ken Cunningham wrote:
> > > Some of your macports installations are installed as the root user, 
> > > instead of the macports user.
> > > This happened because there is no installer for 10.6-ppc to automatically 
> > > create the macports user. You have an open ticket about this too, where I 
> > > pointed to the commands to be run to generate the macports user.
> > > Sooner or later you will probably have to fix this.
> >
> > It shouldn't make any difference to this whether you use the pkg installer 
> > or install from source, since the Makefile also creates the run user. 
> > Unless of course you specifically tell configure --with-macports-user=root 
> > (very not recommended).
> >
> > - Josh

Re: Modern browsers on OpenBSD for PowerPC?

[Sergio Had]

> On Feb 20, 2024, at 5:23 AM, George Koehler  wrote:
> 
> On Mon, 19 Feb 2024 16:08:36 +0800
> Sergio Had  wrote:
> 
>> Palemoon and Arctic Fox are non-Rust options. Those should be
>> feasible and reasonably functional.
> 
> I don't want to discuss Pale Moon,
> https://github.com/jasperla/openbsd-wip/issues/86

I agree, the tone of that message it just ridiculous, but who needs their 
“official branding” anyway.
There are forks of Palemoon with perfectly reasonable developers.

>> It may be worth dumping LLVM/Clang in favor of GCC in fact, the
>> latter has way better support for PPC and more reasonable upstream,
>> in my experience.
> 
> clang runs better than gcc on OpenBSD.  clang, with OpenBSD's patches,
> has features like RETGUARD, https://www.openbsd.org/innovations.html

Surprising, since GCC normally has a better support for non-mainstream 
platforms.
Especially PowerPC and 32-bit.

> OpenBSD is stuck on old gcc versions, uses gcc 8.4.0 to compile
> Fortran code in powerpc packages.

I noticed that, but assumed that no one just bothered to update it.
I have gcc-13.2.0 on macOS PowerPC.

Re: Modern browsers on OpenBSD for PowerPC?

[Sergio Had]

> On Feb 19, 2024, at 3:41 PM, George Koehler  wrote:
> 
> On Sun, 18 Feb 2024 05:11:49 +0800
> Sergey Fedorov  wrote:
> 
>> Could someone say what is the current state of *modern* web browsers for
>> PowerPC?
> 
> All 3 major engines are broken on powerpc or powerpc64:
> 
> - www/chromium recently broke on i386, because it is now too big for
>   32-bit pointers.  It has no chance to run on powerpc.

The way to handle that is to peg the port for a select architecture/platform to 
the last working version.
That will get some years of meaningful functionality which is way better than 
having it just broken.


>  Other than
>   i386, I believe that only aarch64 and amd64 have ever completed a
>   chromium build, so powerpc64 seems unlikely.

This is surprising, to be honest, since ppc64 is supposed to work with V8 (not 
on macOS, but other ELF-using systems).
Though this is useless unless OpenBSD ppc64 itself is fixed for G5 to begin 
with.

> - www/mozilla-firefox needs a rust compiler, which is missing on
>   powerpc and crashes on powerpc64.  After you have rust, there might
>   be other problems.

Palemoon and Arctic Fox are non-Rust options. Those should be feasible and 
reasonably functional.

> - www/webkitgtk4 is broken in the powerpc bulk build report [1].
>   It is now a clang error, "failed to perform tail call elimination
>   on a call site marked musttail", but if someone fixed the error,
>   there might be other errors.  Older versions failed a static_assert
>   on powerpc.

This won’t save us, but static asserts are often just wrong for a 
non-mainstream archs since those who add them are unaware of correct alignment, 
padding etc. It may be worth simply commenting it out, and see how it goes 
further.

> webkitgtk4 is unreachable on powerpc64, because some
>   other packages are broken on powerpc64.
> 
> [1] https://marc.info/?l=openbsd-ports=170725239028843=2
> 
> OpenBSD/macppc uses the powerpc packages.  OpenBSD/powerpc64 only runs
> on PowerNV models (with OPAL firmware), not on a Mac.

Is it something fixable or not?

> The problem is elsewhere: qutebrowser needs x11/qt5/qtwebengine which
> is a fork of chromium; powerpc can't run chromium.  In your link, the
> check for "${PROPERTIES:Mrust}" correctly excludes powerpc.

I had an impression that Qt5 is only broken on macOS. Disappointing if this is 
so on BSD as well. But not something I am ready to try fixing from my side.

> On Sun, 18 Feb 2024 14:07:14 +0100
> Florian Märkl  wrote:
> 
>> last time I tried, netsurf from ports worked fairly well.
> 
> I have been using M-x eww in emacs--gtk3 on macppc, which can load
> only simple websites, but is better than nothing.
> 
> Someone had proposed www/ladybird on ports, but I never looked at it.

There is also Nyxt, which is using Lisp, which works on ppc. But I think it 
also needs some chromium components now.
AFAIR it used webkitgtk2 before, that could potentially work.
(We need Kirll @catap feedback here, I will request him to respond.)

> On Sun, 18 Feb 2024 22:41:18 +
> Roberto Arturo Gonzalez Godinez  wrote:
> 
>> If so, from your MacPorts maintenance, I can imagine that you have the 
>> required hardware. If you don't, in the following weeks, I could setup a 
>> G4 tower and give you ssh access to it so you could leave Firefox 
>> building on it.
> 
> Don't try Firefox as long as there is no rust.  Linux or NetBSD might
> have rust on powerpc, but OpenBSD never did.

mrustc may become a workable choice, but needs gcc backend, at least for macOS.
Another one is gccrs, but not idea when it becomes generally usable. (I does 
work, judging from tests, but apparently is not yet able to build real-life 
Rust apps.)

> OpenBSD briefly had lang/rust on powerpc64, but it broke, and some
> other problems on powerpc64 are blocking a rust fix.  (Less than a week
> ago, I noticed that C++ exceptions are crashing on powerpc64.  Working
> C++ exceptions might unbreak gdb, so gdb can debug other problems.)

Is there a GitHub or bugzilla issue to track that?

> After rust has a package (on either powerpc or powerpc64), the next
> obstacle is devel/spidermonkey115, the JavaScript engine from Firefox
> 115.  It needs patches on powerpc64 and probably on powerpc.  (It was
> missing code to handle powerpc64's ucontext_t.)  If spidermonkey115
> has a package, then x11/gnome/gjs and devel/glade might get packages,
> which might unblock other stuff like xfce.
> 
> An attempt at www/mozilla-firefox would require at least bringing
> forward the spidermonkey patches.

If it does not rely on Rust in itself, I could take a look.

> www/webkitgtk4 is in the "parallel2" category, among the slowest
> packages to build.  A fast PowerPC Mac might take days to build it.
> I don't know, because the build now stops early at an error.
> 
> I would not build llvm (which is smaller than webkit) on a PowerPC
> Mac unless it had at least a 750 MHz cpu and 1G ram.  I want to build
> llvm, because I have a possible fix 

Re: Modern browsers on OpenBSD for PowerPC?

[Sergio Had]

On Feb 18, 2024 at 21:07 +0800, Florian Märkl , wrote:
> last time I tried, netsurf from ports worked fairly well.
> It does not support all the latest web standards, but can display simple 
> websites.

I tried a few browsers advised earlier in MacRumors OpenBSD thread, and none of 
the better ones installed from pkg_add. Netsurf did, but that will be not even 
on TFF level.
Not sure what happened, need to check commit history. It is not impossible that 
stuff gets broken accidentally just because someone committed without having 
ppc in mind :) Casually happens in Macports by the way.
And without PowerPC buildbots we won’t even know something got broken.
> By the way, a huge thanks for your work on MacPorts maintenance for ppc. I am 
> an avid user of both Mac OS X with MacPorts and OpenBSD on multiple G5 
> machines and find it amazing to see how much is still possible with them!
Since you use G5s,

1. Any change of making ppc64 to work? That would be a deal-breaker.
2. I have issues trying to install OpenBSD on G5 even in 32-bit version for 
some reason. It installs, but then freezes after some time, and attempts to 
revive it fail (kernel panic, more freezes). After reinstalling three times I 
gave up. The machine works perfectly with macOS though.

Re: Modern browsers on OpenBSD for PowerPC?

[Sergio Had]

Greetings,

On Feb 19, 2024 at 06:41 +0800, Roberto Arturo Gonzalez Godinez 
, wrote:
> Prior upgrading to OpenBSD 7.4 on my powerbook G4 I did see that there
> where a couple of webkit based browsers ports such as vimb.
>
> It seems that vimb no longer available, but I did not look to find the
> reason as of why it was possibly removed. (It is still present on 7.3)

OpenBSD has a pretty non-transparent system here, but I guess the port can be 
restored trivially, locally first, and then in the master.

I am not really keen on building a browser on G4 though, and so far I could not 
get OpenBSD working on G5 (fragile installation, kernel panic, freezes). If it 
works, I will try.

Anyone knows why Chromium does not build? V8 in the master has a broken PowerPC 
code, but I have the build fixed on macOS ppc (notice, it builds, but does not 
yet work: I suspect ABI should be fixed, and it is a non-trivial task; however, 
for ELF systems this may not be a problem).

If OpenBSD supported ppc64, that would solve the issue with V8 (almost, not 
completely, since VSX code should be made conditional, upstream totally messed 
that up). But AFAIU, ppc64 is broken with OpenBSD officially (on a side note, 
it is broken de facto with FreeBSD too, despite being supported on paper).
> I was poking around with the idea of running a recent Firefox version on
> AIX and I was told that apparently there are recent versions of Firefox
> for Solaris. So, with a bunch of work, running Firefox on BE and on
> other UNIX's is possible.

Firefox needs Rust, unfortunately, and that is likely to be broken, until 
mrustc is able to bootstrap modern-enough Rust and we fix it for PowerPC, and 
gcc backend is implemented.
Or until gccrs is usable in real-life applications (it builds and even passes 
the test suites on ppc, last time I tried).
>  guess that it's lack of interest, resources and possibly hardware to
> port a recent version of Firefox on macppc OpenBSD. Building Firefox
> on an older PowerPC box sure will be long.

TFF or Palemoon take about 3 hrs on the G5 Quad, I think. Palemoon does not 
work yet, but it builds.
There are hopes we get it running: https://github.com/dbsoft/White-Star/issues/2
> As Florian pointed out, Netsurf does work well for simple websites.
AFAIK, this is not a meaningful option. I meant something which supports html5 
and modern web.
> I guess that you could ask Landry for more information on the status
> of Firefox on PowerPC (He is the maintainer of Firefox).
>
> I would of liked to help, but I no longer have the time to contribute.
> Are you planning to help building Firefox for OpenBSD macpp?
Well, if the question is just running the build, sure. It is not something I 
can fix on my own, perhaps, though. We struggle even with MacOS for quite some 
time, and that stuff is at least familiar.

Provided Palemoon is made to work on macOS ppc, I could try porting the build 
to OpenBSD.
> If so, from your MacPorts maintenance, I can imagine that you have the
> required hardware. If you don't, in the following weeks, I could setup a
> G4 tower and give you ssh access to it so you could leave Firefox
> building on it.
>
> And if there's enough interest, I can check if I could setup an OpenBSD
> macppc vm on a Linux PPC64 LE host and benefit from kvm as it's quite a
> powerful machine, but I don't know if OpenBSD macppc runs under kvm. I'd
> have to check that out.
>
> Let me know!
>
> On Sunday, February 18th, 2024 at 08:07, Florian Märkl 
>  wrote:
>
> > Hi Sergey,
> >
> > last time I tried, netsurf from ports worked fairly well.
> > It does not support all the latest web standards, but can
> > display simple websites.
> >
> > By the way, a huge thanks for your work on MacPorts maintenance for
> > ppc. I am an avid user of both Mac OS X with MacPorts and OpenBSD on
> > multiple G5 machines and find it amazing to see how much is still
> > possible with them!
> >
> > Cheers
> > Florian
> >
> > > Am 17.02.2024 um 22:11 schrieb Sergey Fedorov vital@gmail.com:
> > >
> > > Greetings,
> > >
> > > Could someone say what is the current state of modern web browsers for
> > > PowerPC?
> > > Is anything working? I tried to install via pkg_add and nothing was
> > > available, sadly. (Unless I missed something.)
> > >
> > > By the way, I assume the following code is wrong, and would prevent
> > > qutebrowser from building:
> > > https://github.com/openbsd/ports/blob/0bf6e78f8ed8dfcc1d253d505b23eeed7c28606c/www/qutebrowser/Makefile#L43-L49
> > > It is very likely that something broken both on ppc64 and i386 cannot work
> > > fine on ppc, that too Rust-related. I believe, powerpc should be added to
> > > the exclusion list for Rust-using dependency.

Ruby ports: should we retain archaic versions or dump?

[Sergio Had]

There is a discussion here: 
https://github.com/macports/macports-ports/pull/22181

What we have now is rather odd. Ruby port installs pre-historic version and 
everything depending on it is outdated by many years.

I don’t think anyone should need Ruby 1.8, 1.8.6 and 1.9 in three separate 
ports even for compatibility. Arguably no one should need any of these at all.

Ruby 3.1+ should work on 10.5+, including PowerPC. Even if something is 
discovered not to work on 10.5–10.6, the right solution is to fix such issue 
with Ruby upstream rather than remain stuck at archaic versions (nothing can be 
updated to current versions if Ruby itself is that old).

Having said that, I am fine with retaining support for 1.8–1.9 in a passive 
way: I can update existing ports preserving whatever old versions are there and 
add new ones for new Ruby. In a case someone wants to keep supporting old Ruby.

Generally, IMO, we should follow Python model: no unversioned ports, no “Ruby”, 
no dragging something ridiculously archaic that could have been needed for 10.3 
which is not supported anyway.

Re: pre-built quartz variant packages

[Sergio Had]

AFAIK ports are only being pre-built with the default variant.

GTK should be trivial to build though.
On Jan 14, 2024 at 23:58 +0800, Valerio Messina via macports-dev 
, wrote:
> I'm not sure this is the right list to ask for pre-built macports.
>
> In case can you please direct me to the right one?
>
> thank you,
> Valerio
>
>
> On 12/5/23 10:47 PM, Valerio Messina via macports-dev wrote:
> > hi,
> > as a user of osxcross, I also use the good of macports.
> > I read that is not your main target, but tolerate cross-built from other
> > OS. I'm on Debian.
> >
> > I saw there are pre-built packages here:
> > https://packages.macports.org/
> > and this is where the 'osxcross-macport' get the packages.
> >
> > Native macport client has support for variants with something like:
> > $ port variants  # show package variants
> > $ port install  + -   # install variant1, not variant2
> >
> > I saw on packages.macports.org there are only X11 packages, and seems
> > native quartz variant are missing.
> > So for example for gtk3-devel:
> > https://ports.macports.org/port/gtk3-devel/details/
> > is available for X11 backend only as pre-built for foreign OS.
> >
> > Is there a reason for this?
> >
> > Having native quartz pre-built packages will help developer to target
> > quartz instead of xquartz, without the need to (cross)build the GTK
> > itself. This is so for other library with variants.
> >
> > As now the bash script 'osxcross-macport' do not support variants, but
> > I'm sure can be easily upgraded if packages server will host quartz
> > variants.
> >
> > thank you for explanation and work,
>
>
> --
> Valerio

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

[Sergio Had]

On Jan 9, 2024 at 03:37 +0800, Joshua Root , wrote:
> On 9/1/2024 05:26, Perry E. Metzger wrote:
> > On 1/8/24 12:50, Sergey Fedorov wrote:
> > > 2. Standard 10.6.8 release from Apple does support building and
> > > running ppc binaries via Rosetta.
> >
> > Why would one want to spend time and effort on doing that, though?
>
> You wouldn't, if you were running a public release of 10.6. The ppc libs
> were put there to support existing ppc binaries, which will have been
> built targeting 10.5 or older. With MacPorts, native x86_64 or i386
> builds would be far preferable. Unless, of course, you're running on a
> CPU that can't run those archs, which can only be the case if you are
> running an early development version of the OS.

Yet gcc supports 10.6.8 Rosetta in the master. Current gcc. (And no, it is not 
me who brought it there.)
> > So far as I can tell, the project's primary goal is to provide support
> > for the millions of people who run MacOS on current hardware and
> > operating systems and want up to date software for their machine. The
> > goal is not (primarily) to assist in running PPC binaries on Rosetta on
> > 20 year old hardware for the couple of people for whom that is
> > interesting. Certainly there's nothing wrong with supporting that to the
> > extent that it does not interfere with the primary goal.
>
> As a reminder, the project policy is (and has been virtually since the
> beginning) to support the versions of macOS that are still getting
> updates from Apple. That is the expectation for maintainers. Maintainers
> can voluntarily support older stuff, but they are under no obligation to
> so so.

There is no obligation, obviously, no one claims there is, I believe.

As for the policy, I can see that Macports offers distributives for older OS 
which do not get updates from Apple for years. This is much more than not 
prohibiting such builds. I did not dig through the whole of documentation, but 
I believe that if an installable binary for the specific OS is provided, there 
is an implication it should actually work.

There is also no obligation to break something which a maintainer is not 
personally interested in.

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

[Sergio Had]

It is quite a jump from one to hundreds. I stand by my statement: you 
deliberately mislead everyone claiming that there are numerous 10a190-specific 
hacks.

From memory I recall one merged fix which was not required on standard 10.6.8 
but was on 10a190. There are perhaps a dozen which are not required on 10a190 
but required on standard 10.6.8 Rosetta, for the reason I pointed earlier: arch 
gets misdetected.

tcmalloc stuff, as I recall, is common and not 10a190-specific. I will check 
that.

If the specific case is wrong (I need to look into the thing), it should be 
made correct, of course; I never claimed that my code is a priori flawless.

Unlike some, at least I don’t commit it straight into the master without even 
trying to build the thing ;)
On Jan 9, 2024 at 12:31 +0800, Ken Cunningham 
, wrote:
> I think you just don't realize the wreckage you've done.
>
> Here is one of hundreds of your typical commits, although this is a simpler 
> one than most, to be honest.
>
> The commit below has no purpose other than to allow the port to build as PPC 
> on 10.6. And as that is really only of interest on 10.6-for-PPC, it is 
> specifically for that. You say you want to support "Rosetta" but nobody 
> builds for PPC on 10.6.
>
> Here, you've reordered a few instructions, and blocked out some code from 
> running on PPC (presumably because the instructions don't exist on 
> 10.6-for-PPC so it wouldn't compile).
>
> However, this changes the code. And it's not simple code, it is complicated 
> code. Does this change the function of the code? Would it still work properly 
> on 10.6 Intel? Does it work at all on 10.6 for PPC? Who can tell? I certainly 
> don't think you have the experience to know. I can't eyeball it as being fine.
>
> It used to say:
>
> tcmalloc_zone.version = 6;
> tcmalloc_zone.free_definite_size = _free_definite_size;
> tcmalloc_zone.memalign = _memalign;
> tcmalloc_introspection.zone_locked = _zone_locked;
>
> and now it says (I think) on Intel:
>
> tcmalloc_zone.version = 6;
> tcmalloc_zone.memalign = _memalign;
> tcmalloc_zone.free_definite_size = _free_definite_size;
> tcmalloc_introspection.zone_locked = _zone_locked;
>
> and on 10.6-PPC you just get this:
>
> tcmalloc_zone.version = 6;
> tcmalloc_zone.memalign = _memalign;
>
> Does reordering those statements change the function? Does it work at all 
> with the two statements removed? It would take me considerable reading to 
> find out. It took me 10 minutes just to figure out what your patch did.
>
> And now there it sits in the ports tree, a useless MacPorts-only patch, just 
> waiting to break something. Some poor sot might bring an issue to upstream 
> about this, having no idea that this is not even upstream's code any more.
>
> And there are HUNDREDS of these all throughout the codebase that need to be 
> all stripped out.
>
> This is unfortunately a huge mess now.
>
> K
>
>
>
>
> https://github.com/macports/macports-ports/commit/418232ebb3d0e68579364c6246de4464f8f494c9
>
> ==
> --- src/libc_override_osx.h.orig 2021-12-13 14:28:06.0 +0800
> +++ src/libc_override_osx.h 2023-01-19 20:14:36.0 +0800
> @@ -276,9 +276,11 @@
> MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
> // Switch to version 6 on OSX 10.6 to support memalign.
> tcmalloc_zone.version = 6;
> - tcmalloc_zone.free_definite_size = _free_definite_size;
> tcmalloc_zone.memalign = _memalign;
> +#ifndef __POWERPC__
> + tcmalloc_zone.free_definite_size = _free_definite_size;
> tcmalloc_introspection.zone_locked = _zone_locked;
> +#endif
>
> // Request the default purgable zone to force its creation. The
> // current default zone is registered with the purgable zone for
> =
>
>
>
> > On Jan 8, 2024, at 9:50 AM, Sergey Fedorov  wrote:
> >
> > Here we go again.
> >
> > 1. To begin with, nobody is submitting 10A190-specific fixes to Macports. 
> > They are sitting in my local repo. Please, do not mislead people who are 
> > unaware of the matter.
> >
> > 2. Standard 10.6.8 release from Apple does support building and running ppc 
> > binaries via Rosetta. Nothing unreleased or, as you [mis]frame, “stolen”.
> > While I think your opposition is completely unjustified, there has been no 
> > demands or even active discussion about supporting pre-released builds on 
> > 10.6. The point is supporting officially released 10.6.8.
> >
> > 3. If anyone did wonder, the whole issue with 10A190 is literally ~20 ports 
> > altogether, and those fixes amount to a few lines of code to adjust a few 
> > assumptions re SDK. Despite it being portrayed as something like half of 
> > the Macports tree is broken and needs tailored hacks which gonna break 
> > everything. This is nowhere the case.
> > However, as I said above, nobody demanded 10A190 being supported in the 
> > master. Nobody commits 10A190-specific fixups.
> >
> > 4. > “The problem was that there were many fragile and sharply increasing 
> > *specific* workarounds added into the ports tree 

GTK on PowerPC: does anyone have it actually working?

[Sergio Had]

It looks like while even gtk4 builds fine with no hacks (and of course gtk2 and 
gtk3 do), none of the apps built against then actually work. Everything crashes 
on start.

Could anyone confirm if any GTK version is known to work on a PPC system, and 
point at a specific app to test?

Re: librsvg, and what MacPorts is for

[Sergio Had]

What is perfectly doable, done in fact with many ports (including the discussed 
one), and IMO should be done – provide fallbacks whenever the latest version is 
unfixable for the older systems.
Of course, it is an open source project, and what is actually done is 
conditional on good will and subject to understandable constraints.

I also don’t think anyone holds an opinion that the latest OS should not be 
prioritized.

However supporting only the latest OS is a lazy maintaining which normally 
amounts to checksum verification. In such a case Macports would not really 
offer much, and becomes a download tool with delayed updates, just like Brew is.
There is little value in such an approach, even more so that there is already 
another download tool, Brew, and offering the same shall inevitably reduce user 
base.

Support for older systems, which is unique to Macports, keeps some developers 
engaged specifically with Macports, and even if end users count in dozens and 
not thousands, there are “positive externalities” to this:

1. People who use Macports on old systems tend to tell other people use 
Macports (and those use whatever systems). Why? Because they enthusiastically 
use Macports and see a value in it, which they don’t see in a download manager 
with “we-don’t-care-about-you” approach like Brew.
2. Developers who use or wish to maintain old systems provide fixes to the 
software (which are not limited to the OS version they use), which improves the 
code base for everyone. You won’t have it, if the testing is done on a couple 
of latest OS versions and one arch.
3. You get some software into Macports exactly because Macports supports old 
systems. Which then you or anyone can use on the latest OS too. Example: the 
only reason I brought R ports here is to make it work on PowerPC. I would not 
have bothered and spent several months on this, if the sole point was to 
support macOS-11+. And I think no one would do – and that is why Brew does not 
have it. However in result anyone with Sonoma can run R packages. And we have 
better code for R than CRAN, where they test on a few latest systems, and in 
result bugs are unfixed. Notice, this does not only mean that their code is 
broken on 10.6; some fixes I did – as a consequence – fixed Linux and 
BSD-affecting bugs, even that was out of my intentions. Any healthy code should 
work on every sane platform, and if it does not, it is broken, even if errors 
are obscured by ineffective testing.

We do not need to have identical and even aligned goals and use-cases. What we 
need is the environment conducive to productive cooperation, where independent 
individuals are allowed to pursue their goals – the only requirement being not 
to harm what others do. This is exactly like a market. It should not be 
centrally planned, but be emergent. Then people prosper :)

P. S. On a side note, it is a questionable security solution to use a single 
compiler which can only be built with itself. It is an ill-thought decision to 
dump multiple systems which do not have Rust. As a consequence, less bugs will 
be fixed, and the software will accumulate them over time. Yes, it may be 
easier to develop for people who don’t know C well enough but do know Rust. It 
is understandable that people try to minimize effort spent. But no, it is not 
something to improve security. It is, at least potentially, quite the opposite.
On Oct 11, 2023 at 01:48 +0800, Perry E. Metzger , wrote:
> See the following thread:
> https://github.com/macports/macports-ports/pull/20744 — but to
> summarize, Mascguy does not want to update librsvg to a safe / modern
> one because ancient versions of MacOS can't support Rust.
>
> So I don't want to be a pain in the neck, but I have little interest in
> MacPorts if the point is to preserve compatibility with MacOS 10.5 at
> the expense of having the thousands of users of current Macs and current
> MacOS have a dangerously insecure version of a basic SVG graphics
> library that other things depend on.
>
> (The upstream librsvg maintainers have washed their hands of the old C
> version and don't support it any more, and for good reason. The Rust
> version of the library provides a far more secure codebase.)
>
> I don't know how other people feel here, but I don't work on MacPorts
> because I like retrocomputing, but rather because I want to use Unix
> tools on my modern Macs.
>
> If we're all on the same page that the priority is current MacOS users,
> then we need to make sure that policy is well understood by all and we
> need to update ports that are being held back for the benefit of people
> using an OS from 2007.
>
> If the consensus is that we prioritize ancient versions of MacOS with
> three users (or sometimes none) over the experience the bulk of the
> users have, that's fine, and I'll accept it, but then I'm switching to
> Brew, and I will advise others to do the same, and will explain that
> current versions of MacPorts cannot be trusted to 

Re: Why some ports seem to install universal when I do not request it ?

[Sergio Had]

As long as there are dependencies, it is a potentially breaking behavior.
I think libunwind was (is?) forcing universal which breaks ppc build.
On Aug 15, 2023 03:07 +0800, Christopher Jones , 
wrote:
> Hi All,
>
> Just migrated from an intel to AppleSilicon machine.
>
> Reinstalling MacPOrts, from scratch off course, I’ve noticed some ports get 
> install universal, when it’s not something I have requested. e.g.
>
> ---> Fetching archive for zlib
> ---> Attempting to fetch zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2 
> from https://packages.macports.org/zlib
> ---> Attempting to fetch 
> zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2.rmd160 from 
> https://packages.macports.org/zlib
> ---> Installing zlib @1.2.13_0+universal
> ---> Cleaning zlib
> ---> Deactivating zlib @1.2.13_0
> ---> Cleaning zlib
> ---> Activating zlib @1.2.13_0+universal
>
> zlib has a universal port, but its not a default one, and I didn’t request 
> it, nor have I ever set my default settings to always install universal.
>
> As I am new to apple silicon machines, is this normal ?
>
> cheers Chris

Qt5 on <= 10.6

[Sergio Had]

Does Qt5 work on 10.5–10.6 Intel?

It looks that at least earlier 5.x versions installed on 10.6: 
https://ports.macports.org/port/qt53/stats
Presumably that should be fixable for 10.5 and PPC.
(I am not sure if 5.3 is of much use though – do developers of ports depending 
on Qt5 support it still?)

P. S. Given how much efforts it takes every time to fix something for Qt4, even 
if it means just digging out a right version and reverting some commits, I 
start asking a question if it is easier just to fix some early 5.x version. 
There should not be anything arch-specific, it should be just C++, I guess. 
Just find fallbacks for whatever misses in SDK, but if it works on 10.6 Intel, 
it might be pretty feasible.

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

[Sergio Had]

P. S. I wonder now if the current SDL2 gonna build with X11 backend and Cocoa 
off. Given that upstream concentrated efforts on skillfully breaking Cocoa 
beyond repair, everything else might be intact.
On Jul 20, 2023 07:15 +0800, Ken Cunningham , 
wrote:
> As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All 
> the ports use the Cocoa interface.
>
> The modifications that were made to SDL2 by miniupnp to run on Tiger and 
> Leopard were fairly extensive, to an older version of SDL2, but they worked 
> to allow a number of ports that required libsdl2 to work on those systems. I 
> have those mods tucked away in the archives of the TigerPorts and 
> LeopardPorts repos.
>
> Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful on 
> those older systems. We did have one newer version that would build, but was 
> so broken by the hacks needed to make it build that it was useless in 
> practical use.
>
> Which brings me to the next point.
>
> It is quite possible to make hacks/patches to software that will allow it to 
> build -- at an extreme, you and #if 0 / #endif out that entire source, and it 
> will compile just fine.
>
> But especially for things like SDL2, what is needed is more than that -- you 
> have to see if software built against such patched versions will actually 
> work, and this sometimes takes some fairly extensive testing to see what the 
> warts might be.
>
>
>
> Ken
>
>
>
> > On Jul 19, 2023, at 8:32 AM, Sergey Fedorov  wrote:
> >
> > libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive 
> > fixes, however I had to disable cocoa video and joystick for that.
> > They are likely fixable (though no idea whether and how they gonna work), 
> > but at least cocoa video gonna require a massive rewrite – or perhaps 
> > falling back to an earlier implementation. (Well, this is not a kind of 
> > code I can genuinely rewrite – only adapt patches and maybe improve 
> > something a bit.)
> >
> > However, if X11 implementation is a meaningful replacement, it builds fine 
> > with no trickery.
> >
> > Any thoughts?
> >
> > P. S. ICE on hidapi is trivially fixable – I just reverted a commit which 
> > has broken that. After that, hidapi builds fine.
>

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

[Sergio Had]

Of course, we could also make a separate -legacy port using 2.0.9, for example 
(last version miniupnp patched was 2.0.8 but we know 2.0.9 builds and likely 
gonna work), but it will be disappointing to having wasted many hours on 2.0.22 
without a positive outcome LOL

There is also no harm in switching to X11 for systems which it does not build 
at all presently. With that option enabled, other ports can be tested to see if 
X11 can be likewise used for old systems with SDL2.
On Jul 20, 2023 17:41 +0800, Sergio Had , wrote:
> That was my point: X11 does not require violating sources much. What does is 
> essentially one file: SDL_cocoamodes.m. It is used by cocoa video, otherwise 
> it is not built.
>
> I did not have to throw chunks of code away, aside of cocoa video case (which 
> still fails to build so far). And miniupnp and your patches are adaptable: 
> again, leaving off cocoa video part. (I didn’t bother with joystick at all 
> yet, aside of seeing it gets ICE akin to hidapi, which only Iain can fix, but 
> it has been many months since it was filed to Bugzilla, and here we are.)
>
> I will review my patches today to make sure nothing silly creeped in, and 
> what I suggest is I make a PR with X11 backend and no cocoa video, and you or 
> someone interested take a look.
> It is easy to switch portfile logic to use X11 on ppc and old Intel, while 
> keeping existing settings for 10.6 Intel.
> On Jul 20, 2023 07:15 +0800, Ken Cunningham 
> , wrote:
> > As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. 
> > All the ports use the Cocoa interface.
> >
> > The modifications that were made to SDL2 by miniupnp to run on Tiger and 
> > Leopard were fairly extensive, to an older version of SDL2, but they worked 
> > to allow a number of ports that required libsdl2 to work on those systems. 
> > I have those mods tucked away in the archives of the TigerPorts and 
> > LeopardPorts repos.
> >
> > Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful 
> > on those older systems. We did have one newer version that would build, but 
> > was so broken by the hacks needed to make it build that it was useless in 
> > practical use.
> >
> > Which brings me to the next point.
> >
> > It is quite possible to make hacks/patches to software that will allow it 
> > to build -- at an extreme, you and #if 0 / #endif out that entire source, 
> > and it will compile just fine.
> >
> > But especially for things like SDL2, what is needed is more than that -- 
> > you have to see if software built against such patched versions will 
> > actually work, and this sometimes takes some fairly extensive testing to 
> > see what the warts might be.
> >
> >
> >
> > Ken
> >
> >
> >
> > > On Jul 19, 2023, at 8:32 AM, Sergey Fedorov  wrote:
> > >
> > > libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive 
> > > fixes, however I had to disable cocoa video and joystick for that.
> > > They are likely fixable (though no idea whether and how they gonna work), 
> > > but at least cocoa video gonna require a massive rewrite – or perhaps 
> > > falling back to an earlier implementation. (Well, this is not a kind of 
> > > code I can genuinely rewrite – only adapt patches and maybe improve 
> > > something a bit.)
> > >
> > > However, if X11 implementation is a meaningful replacement, it builds 
> > > fine with no trickery.
> > >
> > > Any thoughts?
> > >
> > > P. S. ICE on hidapi is trivially fixable – I just reverted a commit which 
> > > has broken that. After that, hidapi builds fine.
> >

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

[Sergio Had]

That was my point: X11 does not require violating sources much. What does is 
essentially one file: SDL_cocoamodes.m. It is used by cocoa video, otherwise it 
is not built.

I did not have to throw chunks of code away, aside of cocoa video case (which 
still fails to build so far). And miniupnp and your patches are adaptable: 
again, leaving off cocoa video part. (I didn’t bother with joystick at all yet, 
aside of seeing it gets ICE akin to hidapi, which only Iain can fix, but it has 
been many months since it was filed to Bugzilla, and here we are.)

I will review my patches today to make sure nothing silly creeped in, and what 
I suggest is I make a PR with X11 backend and no cocoa video, and you or 
someone interested take a look.
It is easy to switch portfile logic to use X11 on ppc and old Intel, while 
keeping existing settings for 10.6 Intel.
On Jul 20, 2023 07:15 +0800, Ken Cunningham , 
wrote:
> As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All 
> the ports use the Cocoa interface.
>
> The modifications that were made to SDL2 by miniupnp to run on Tiger and 
> Leopard were fairly extensive, to an older version of SDL2, but they worked 
> to allow a number of ports that required libsdl2 to work on those systems. I 
> have those mods tucked away in the archives of the TigerPorts and 
> LeopardPorts repos.
>
> Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful on 
> those older systems. We did have one newer version that would build, but was 
> so broken by the hacks needed to make it build that it was useless in 
> practical use.
>
> Which brings me to the next point.
>
> It is quite possible to make hacks/patches to software that will allow it to 
> build -- at an extreme, you and #if 0 / #endif out that entire source, and it 
> will compile just fine.
>
> But especially for things like SDL2, what is needed is more than that -- you 
> have to see if software built against such patched versions will actually 
> work, and this sometimes takes some fairly extensive testing to see what the 
> warts might be.
>
>
>
> Ken
>
>
>
> > On Jul 19, 2023, at 8:32 AM, Sergey Fedorov  wrote:
> >
> > libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive 
> > fixes, however I had to disable cocoa video and joystick for that.
> > They are likely fixable (though no idea whether and how they gonna work), 
> > but at least cocoa video gonna require a massive rewrite – or perhaps 
> > falling back to an earlier implementation. (Well, this is not a kind of 
> > code I can genuinely rewrite – only adapt patches and maybe improve 
> > something a bit.)
> >
> > However, if X11 implementation is a meaningful replacement, it builds fine 
> > with no trickery.
> >
> > Any thoughts?
> >
> > P. S. ICE on hidapi is trivially fixable – I just reverted a commit which 
> > has broken that. After that, hidapi builds fine.
>

Re: rldicl / rldicr for 32-bit powerpc?

[Sergio Had]

Well, I didn’t mean copy-pasting the patch, of course, it was just the only 
relevant thing that was found.

NodeJS uses those instructions in some procedures (either in codebase or 
PPC-specific patches), and I am looking to fixing it finally for 32-bit.
On Jul 16, 2023 02:39 +0800, Fred Wright , wrote:
>
> On Sat, 15 Jul 2023, Sergey Fedorov wrote:
>
> > Is there an implementation to replace these on ppc32?
> >
> > There is some Linux version online which I found:
> > https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/
> > But since it is a magic code, no idea if it is portable or not.
>
> You'd have to be more specific about the intended context. AFAIK,
> OSX/macOS didn't have anything like KVM until 10.10, so this specific
> patch wouldn't be relevant.
>
> Fred Wright

Re: Portfile syntax highlighting

[Sergio Had]

Anyone using BBEdit? It has portfile syntax highlighting as an add-on.
On Mar 26, 2023 03:15 +0700, Vadym-Valdis Yudaiev , wrote:
>
>
> > On 25 Mar 2023, at 22:10, Vadym-Valdis Yudaiev  wrote:
> >
> > Hi,
> >
> > It is difficult to answer because I make changes from time to time. You can 
> > see full keywords list here:
> >
> > https://github.com/judaew/macports.nvim/blob/main/dict/macports-keywords.lua
> >
> > - Vadym-Valdis
> >
> > > On 24 Mar 2023, at 03:44, contextnerror ​  
> > > wrote:
> > >
> > > Do you have a list of the new keywords you needed to add? I’ve been 
> > > working on my own TextMate syntax in the meantime, and was hoping to add 
> > > those keywords as well.
> >
> >
>

Re: Legacy Support for GHC-Based Projects

[Sergio Had]

GHC can be cross-compiled. You do not need ppc binary. Not necessarily.
On Jan 17, 2023 22:45 +0800, Steven Smith , wrote:
> A stack binary is required to build stack, and to the best of my knowledge 
> there is no ppc stack binary: 
> https://github.com/commercialhaskell/stack/search?q=ppc=. I recommend 
> such requests be taken upstream, as there is no “fix” for PPC on our end.
>
> Back to topic, is anyone able to confirm that stack-based pandoc is working 
> (or not) on a legacy platform also supported by stack back to Sierra?
>
> > On Jan 17, 2023, at 09:08, Sergio Had  wrote:
> >
> > If PPC is fixed on our end, I will try to upstream patches, so we won’t 
> > need to carry those.
> > On Jan 17, 2023 21:47 +0800, Steven Smith , wrote:
> > > To clarify, the question is how to specify that these ports use the 
> > > latest stack version for builds on legacy systems. Does it work for 
> > > pandoc now?
> > >
> > > stack on ppc or other very old non-supported systems will be 
> > > extraordinarily fragile and time-consuming, and I expect difficult to 
> > > anticipate sustained MacPorts support, especially as stack migrates to 
> > > arm.
> > >
> > > > On Jan 17, 2023, at 08:39, Sergio Had  wrote:
> > > >
> > > > I assume stack-based builds are still broken for PPC, as well as Intel 
> > > > builds on 10.6.8, but I will try to find time to work on fixing it. Ken 
> > > > kindly shared his work on GHC for Snow Leopard, but it is for x86 (and 
> > > > not in Macports).
> > > >
> > > > If anyone is good at cross-compiling, please ping me. We need to first 
> > > > build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.
> > > > On Jan 17, 2023 06:15 +0800, Steven Smith , 
> > > > wrote:
> > > > > I recently added legacy-based support to pandoc, but I’m not sure 
> > > > > that the code I used is working. I’ll issue a revised PR based on any 
> > > > > feedback and use a working version for other GHC-based projects.
> > > > >
> > > > > I used this code to force stack-based builds on macOS versions that 
> > > > > predate Apple Silicon. After Apple Silicon, we need cabal-based 
> > > > > builds for native binaries.
> > > > >
> > > > > > set arm64_minimum_supported_major_version 20
> > > > > > if {${os.platform} eq {darwin}
> > > > > > && ${os.major} < ${arm64_minimum_supported_major_version}} {
> > > > > > # use stack to build x86_64 binaries
> > > > > > default_variants-append \
> > > > > > +stack
> > > > > > }
> > > > >
> > > > > stack-based stack builds work all the way back to Snow Leopard: 
> > > > > https://ports.macports.org/port/stack/details/. I’d expect the same 
> > > > > of pandoc, but it only builds back to Sierra: 
> > > > > https://ports.macports.org/port/pandoc/details/
> > > > >
> > > > > Is anyone able to suggest profile code that will accomplish this? Is 
> > > > > this related to the design choice to use a the port variant +stack to 
> > > > > specify the build tool?

Re: Legacy Support for GHC-Based Projects

[Sergio Had]

If PPC is fixed on our end, I will try to upstream patches, so we won’t need to 
carry those.
On Jan 17, 2023 21:47 +0800, Steven Smith , wrote:
> To clarify, the question is how to specify that these ports use the latest 
> stack version for builds on legacy systems. Does it work for pandoc now?
>
> stack on ppc or other very old non-supported systems will be extraordinarily 
> fragile and time-consuming, and I expect difficult to anticipate sustained 
> MacPorts support, especially as stack migrates to arm.
>
> > On Jan 17, 2023, at 08:39, Sergio Had  wrote:
> >
> > I assume stack-based builds are still broken for PPC, as well as Intel 
> > builds on 10.6.8, but I will try to find time to work on fixing it. Ken 
> > kindly shared his work on GHC for Snow Leopard, but it is for x86 (and not 
> > in Macports).
> >
> > If anyone is good at cross-compiling, please ping me. We need to first 
> > build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.
> > On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
> > > I recently added legacy-based support to pandoc, but I’m not sure that 
> > > the code I used is working. I’ll issue a revised PR based on any feedback 
> > > and use a working version for other GHC-based projects.
> > >
> > > I used this code to force stack-based builds on macOS versions that 
> > > predate Apple Silicon. After Apple Silicon, we need cabal-based builds 
> > > for native binaries.
> > >
> > > > set arm64_minimum_supported_major_version 20
> > > > if {${os.platform} eq {darwin}
> > > > && ${os.major} < ${arm64_minimum_supported_major_version}} {
> > > > # use stack to build x86_64 binaries
> > > > default_variants-append \
> > > > +stack
> > > > }
> > >
> > > stack-based stack builds work all the way back to Snow Leopard: 
> > > https://ports.macports.org/port/stack/details/. I’d expect the same of 
> > > pandoc, but it only builds back to Sierra: 
> > > https://ports.macports.org/port/pandoc/details/
> > >
> > > Is anyone able to suggest profile code that will accomplish this? Is this 
> > > related to the design choice to use a the port variant +stack to specify 
> > > the build tool?

Re: Legacy Support for GHC-Based Projects

[Sergio Had]

I assume stack-based builds are still broken for PPC, as well as Intel builds 
on 10.6.8, but I will try to find time to work on fixing it. Ken kindly shared 
his work on GHC for Snow Leopard, but it is for x86 (and not in Macports).

If anyone is good at cross-compiling, please ping me. We need to first build 
the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.
On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
> I recently added legacy-based support to pandoc, but I’m not sure that the 
> code I used is working. I’ll issue a revised PR based on any feedback and use 
> a working version for other GHC-based projects.
>
> I used this code to force stack-based builds on macOS versions that predate 
> Apple Silicon. After Apple Silicon, we need cabal-based builds for native 
> binaries.
>
> > set arm64_minimum_supported_major_version 20
> > if {${os.platform} eq {darwin}
> > && ${os.major} < ${arm64_minimum_supported_major_version}} {
> > # use stack to build x86_64 binaries
> > default_variants-append \
> > +stack
> > }
>
> stack-based stack builds work all the way back to Snow Leopard: 
> https://ports.macports.org/port/stack/details/. I’d expect the same of 
> pandoc, but it only builds back to Sierra: 
> https://ports.macports.org/port/pandoc/details/
>
> Is anyone able to suggest profile code that will accomplish this? Is this 
> related to the design choice to use a the port variant +stack to specify the 
> build tool?

Re: The State of Rust in MacPorts Today

[Sergio Had]

Kirill, when you gonna deal with i386, consider also PPC. Sure enough, it is 
not a priority, but it may be fixable, given that mrustc itself builds on ppc32.
To be clear, I do not expect any dedicated fixes, just making sure x86 is not 
hard-coded and 32-bit platforms are supported.
Then all PPC testing can be done on my hardware (second half of Jan, once I am 
home).
On Dec 13, 2022 23:07 +0700, Kirill A. Korinsky via macports-dev 
, wrote:
> Folks,
>
> From the third hand we may build our own bootstrap chain of rust from scratch.
>
> Or almost.
>
> We have a https://ports.macports.org/port/mrustc/details/ which is able to 
> bootstrap 1.54 rust on x86_64 and arm64.
>
> Unfortunately support of i386 isn't yet finished at upstream. I plan to fix 
> it, but it requires time and availability of hardware to test it :)
>
> I do have a commits which implements rust bootstrap by cahin: mrustc -> rust 
> 1.54 -> rust 1.55 -> rust 1.56; I can start to open PRs to move step-by-step 
> and in month we'll have the last rust via this chain.
>
> --
> wbr, Kirill
>
> > On 13. Dec 2022, at 16:49, Christopher Jones  
> > wrote:
> >
> > Hi,
> >
> > In my opinion, hosting and maintaining these ‘bootstrap’ compilers outside 
> > the macports infrastructure was a poor choice, for all the reasons you 
> > mention below. I thought this at the time it was done, and even more so now.
> >
> > Personally, I would suggest you think about a change to how the rust 
> > compiler is package, to mirror a bit how things are done with gcc and 
> > clang. Namely, move to a model where the version is part of the port name, 
> > e.g. the current one would be called something like rust-1.61.
> >
> > The main reason for doing this, is adding a new version would that not 
> > remove the previous version, and thus you could simple use it as the 
> > bootstrap compiler. So with the above, when you add rust-1.62 that would 
> > simple configure itself to bootstrap using the macports rust-1.61 port.
> >
> > Yes, this will require some work to set up. You will need to make all the 
> > various rust versions installable along side each other, so some tweaking 
> > of the install prefix would be needed.
> >
> > One thing I would do differently though to how gcc/clang do things is I 
> > would try and have a single rust port file, that implements all the 
> > versions as sub-ports. I suspect most of what each needs can then just be 
> > shared , such that what needs to be different for each sub-port is actually 
> > not that much.
> >
> > Regarding how users of rust then use these ports, there are a couple options
> >
> > 1. Add a shim port ‘rust’ which simply installs sym-links etc. to the 
> > ‘current best version’ that mimics the current installation, i.e. in the 
> > main prefix. If done well, users should then be blind to the changes above.
> > 2. Users that want an older rust could explicitly depend on and use a 
> > specific versioned rust-N
> >
> > For me, this approach makes a lot more sense than the current way these 
> > bootstrap compilers are maintained.
> >
> > cheers Chris
> >
> >
> > > On 13 Dec 2022, at 2:57 pm, Herby G  wrote:
> > >
> > > Hello all,
> > >
> > > Right now, Rust in MacPorts is severely out of date. It's about 5 
> > > versions behind the current release, which at the moment is at 1.65.0. In 
> > > comparison, MacPorts Rust is currently at 1.61.0.
> > >
> > > As a core language underlying a lot of other ports, many of these ports 
> > > cannot be updated to their latest versions because these versions require 
> > > current versions of Rust. At the time of this writing, 156 ports are 
> > > being built using Rust ( https://ports.macports.org/port/rust/details/ ), 
> > > some quite heavily used by the community, including projects like 
> > > `git-delta`, `bat` and `fd`.
> > >
> > > MarcusCalhoun-Lopez's PR here ( 
> > > https://github.com/macports/macports-ports/pull/14277 ) heavily rewrote 
> > > the Rust port to run on older systems, and was very much celebrated and 
> > > endorsed. However, as a result of this PR, the Rust port became a lot 
> > > more complicated, and also introduced a new critical bootstrap compiler 
> > > (referenced in the Rust portgroup here: 
> > > https://github.com/macports/macports-ports/blob/2d39b30a32fcf0f5e1cff04f172e9d55ae08ba48/_resources/port1.0/group/rust-1.0.tcl#L140),
> > >  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
> > > https://github.com/MarcusCalhoun-Lopez/rust/releases ).  Marcus did try 
> > > to ask about a more official location to host the bootstrap compiler in a 
> > > macports-dev thread: 
> > > https://lists.macports.org/pipermail/macports-dev/2022-April/044243.html 
> > > , but ultimately per the  responses he decided to just host it in his 
> > > personal account himself.
> > >
> > > Since this massive change to the Rust port at 1.60.0, it's only seen one 
> > > update since then to 1.61.0 ( 
> > > 

Implementing R packages via ports

[Sergio Had]

Are there some non-obvious reasons not to have ports for R packages? Or just no 
one felt like making any?

R basically uses a mechanism akin to Python, OCaml or Perl, installing stuff 
into its “mini-prefix”. While we do have ports for the latter three (not many 
for OCaml), there are none for R.
FreeBSD at the same time does have ports for select R packages.

Why bother?

1. Some packages are broken for old systems (including Intel), but can be 
trivially fixed with patches. Those include some basic packages, like fs and 
xml2.
2. In a number of cases all that is needed is legacysupport PG.
3. With a fancy complicated packages we may prefer using existing dependencies 
rather than building supplied – usually outdated – duplicate copies. (At least 
for testing/development.)

What do you think?