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
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
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.
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, 202
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
oc 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:
&
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
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
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
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 m
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 ,
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
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,
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?
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
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
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
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
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
> 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
>> qui
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
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
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
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
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
> 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
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!
>
>
> >
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
> 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
> 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
:
>>
>>
>>
>>> 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
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 anyo
> 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
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
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
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
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
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
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 wrot
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.
t 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
> 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
&
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.
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? :)
;
> 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
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:
> >
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
48 matches
Mail list logo
