To conclude gperftools topic:
The following commit drops local rosetta patch, as well as another patch,
since both issues are fixed in upstream.
It also fixes a broken tests target and updates the port to 2.15.
https://github.com/macports/macports-ports/pull/22097/commits/005cd16fae819210578ac2ccd
So, to Ken’s claim re gperftools.
> And now there it sits in the ports tree, a useless MacPorts-only patch,
just waiting to break something.
To begin with, this is a false statement. The patch is NOT MacPorts-only
but backported from the upstream. Of course, Ken did not bother to take a
look.
Her
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 effo
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 re
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-
> On 8. Jan 2024, at 20:55, Joshua Root wrote:
>
> On 9/1/2024 01:53, Kirill A. Korinsky wrote:
>> How do you see the way to backport changes from upstream MacPorts to legacy
>> MacPorts?
>> at some point automatical merge would be broken on conflicts, and I assume
>> quite fast.
>
> I would p
On 9/1/2024 01:53, Kirill A. Korinsky wrote:
How do you see the way to backport changes from upstream MacPorts to legacy
MacPorts?
at some point automatical merge would be broken on conflicts, and I assume
quite fast.
I would posit that if maintaining a patch set in your fork is a lot of
wo
On 1/8/24 14:15, Sergey Fedorov wrote:
/The whole of open-source is largely a hobby project/ :)
Lots of people are paid to work with or on open source software.
MacPorts is not an abstract pass-time like playing cards; it provides
people with functionality that they need to do their work and
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 re
*The whole of open-source is largely a hobby project* :)
> I will note, however, that there are a huge number of people who rely on
Sonoma on Intel or ARM as their daily work machine.
This is not the right question to ask. How many people exclusively depend
on Macports for their daily work will b
To begin with, it is not up to me to decide what Macports should or should
not do, it is not my project.
However solution, if you ask me, if not to dump some users, who may be few,
but interested to contribute (I think no one can honestly accuse me of
fixing only PowerPC stuff – well, Ken may, but
On 1/8/24 10:44, Nicklas Larsson wrote:
Hi all!
I’m seriously curious: does anyone still today use a PPC machine today as (1)
main/only workstation with (2) necessary use of latest software and (3) without
using it as hobby project?
I think it's a hobby.
Perry
The question is very simple. "Does anyone using MacPorts actually depend
on the machines in question for their daily work". Not "could someone in
theory do so". Not "is there a way that you could do such a thing if you
really really wanted to". Does anyone *actually* do it.
My assumption is no
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?
Just to be clear about my position on almost everything here:
I don't mind people spendin
I do not particularly get the question. By “not using as a hobby project”
you mean using it commercially? Obviously, “the latest software” condition
restricts this to open-source.
I can name at least a few areas where macOS PowerPC *can be* used either
commercially or with the latest software but
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 unr
There is no hiccup in MacPorts support for PowerPC systems, despite the
dramatic title of the PR.
Also there is no hiccup in support for older released Apple operating systems.
10.4 and 10.5 remain fully supported by MacPorts (although 10.4 might be on
last legs).
There is also no need (IMHO)
Hi all!
I’m seriously curious: does anyone still today use a PPC machine today as (1)
main/only workstation with (2) necessary use of latest software and (3) without
using it as hobby project?
Best regards,
Nicklas
> On 8 Jan 2024, at 15:50, Perry E. Metzger wrote:
>
> There's been a bit o
> somewhere here I stop to understand why we need the fork to keep it?
> To avoid tickets in track?
It can be set in the policy not to file Trac tickets for < 10.x, or
priority can be set to low automatically.
Having a separate repo is gonna be an unmaintainable disaster IMO indeed.
On Mon, Jan
> On 8. Jan 2024, at 16:18, Perry E. Metzger wrote:
>
> On 1/8/24 10:12, Kirill A. Korinsky wrote:
>>> I don't think there should be overly much in the way of trouble if legacy
>>> reasonably disciplined about frequently applying commits from upstream to
>>> legacy. If it's done often, then one
On 1/8/24 10:12, Kirill A. Korinsky wrote:
I don't think there should be overly much in the way of trouble if
legacy reasonably disciplined about frequently applying commits from
upstream to legacy. If it's done often, then one doesn't risk falling
far behind and having a giant mess to clean up
> On 8. Jan 2024, at 16:08, Perry E. Metzger wrote:
>
> On 1/8/24 09:53, Kirill A. Korinsky wrote:
>>> On 8. Jan 2024, at 15:50, Perry E. Metzger wrote:
>>>
>>> I'd like to float the idea that we create a fork of the MacPorts repository
>>> that is devoted to operating systems and hardware tha
There aren’t going to be great answers to this because it is hard to solve
a social issue via technical means. But my 2c here is that if you
absolutely have to fork, maintaining the fork as a patchwork repo on top of
the Portfile repo is in play. If the rebase is done manually, or with some
CI, you
On 1/8/24 09:53, Kirill A. Korinsky wrote:
On 8. Jan 2024, at 15:50, Perry E. Metzger wrote:
I'd like to float the idea that we create a fork of the MacPorts repository
that is devoted to operating systems and hardware that is more than (say) a
decade old, and that we allow the people who are
Hi Perry,
> On 8. Jan 2024, at 15:50, Perry E. Metzger wrote:
>
> I'd like to float the idea that we create a fork of the MacPorts repository
> that is devoted to operating systems and hardware that is more than (say) a
> decade old, and that we allow the people who are interested in maintaini
There's been a bit of tension recently because of a group of people who
are very interested in keeping MacPorts working on PowerPC hardware,
none of which has been made for the last 18 years or so.
I'd like to float the idea that we create a fork of the MacPorts
repository that is devoted to o
26 matches
Mail list logo
