Just for a note, there is no problem in explicitly stating that no tickets for
10.4 will be accepted and just close such tickets as wontfix.
(And Ken, for example, recently went as far as closing as wontfix all tickets
for bugs discovered on 10.6 PowerPC even when those had not been specific to
Ken, you got some degree of superficial acquaintance with the system in
question 2,5 years ago and keep convincing yourself and others that your,
obviously emotionally biased, take represents an accurate account of
reality, and that reality could not possibly have changed ever since.
As a matter o
On Jan 25, 2025 at 04:34 +0800, Ken Cunningham
, wrote:
> PS. -- I personally have absolutely no intention of ever supporting efforts
> to shoehorn MacPorts into the pre-beta of 10.6 stolen from from the Apple Dev
> meeting, and agree it is just plain frickin' silly to have a crap-ton of
> spag
issue
standing is a broken UDP (and no DHCP therefore).
Currently dns is resolved via tcp, this works fine for web access, but DHCP
remains broken, so network setup needs to be done manually.
You may want to give it a try.
On Jan 24, 2025 at 05:19 +0800, Riccardo Mottola ,
wrote:
> Hi,
>
&g
No point supporting anything below 10.5. All PowerPC machines that are actually
usable can run 10.5–10.6.
10.4 is much more broken than later systems and got no advantages.
While I do not appreciate Homebrew policy and do not think it would be wise to
mimic it, it is reasonable to expect that Ma
ot very interested in spending a lot of effort testing every
> > > possible version of macOS. Can these supports have their own supported
> > > macOS versions?
> > >
> > > Can older OS versions select the netatalk2 support?
> > >
> > >
> >
hat old versions of macOS can still use the
> older netatalk packages? I think that the 'netatalk' port should be
> whatever is the latest version of the package, instead of having a new port
> called 'netatalk4'.
>
> --
> Jason Liu
>
>
> On Tue, Jan 2
I had a port for netatalk 3 somewhere; as I recall, it needed some fixes
for the build. That was a while ago, I do not know what is the current
status.
Very much likely that netatalk 4 will be broken on older systems and
possibly less useful than earlier versions.
So yeah, I think it should be a se
I think it compiles with no issues on 10.6 ppc with gcc-14, so perhaps the OS
issue, not an arch or compiler one.
On Dec 20, 2024 at 18:41 +0800, Riccardo Mottola via macports-dev
, wrote:
> Hi,
>
> Ken Cunningham wrote:
> > https://trac.macports.org/ticket/71601#comment:3
> >
> > and I mentioned
Just in case, dropping gcc-4.2 from this line does not change anything,
right?
https://github.com/macports/macports-ports/blob/0dea602a9f195ca39a6a0318d54c10b80036d35d/lang/gcc14/Portfile#L350
Sorry, cannot check at the moment.
At least before that was a bug in the port, which introduced circular
An example of the issue: https://gitlab.gnome.org/World/secrets/-/issues/604
On Fri, Nov 29, 2024 at 8:02 AM Sergey Fedorov wrote:
> Hi,
> Does anyone find this familiar?
>
> I got this crash with three unrelated ports:
> ```
> Exception Type: EXC_BAD_ACCESS (SIGBUS)
Hi,
Does anyone find this familiar?
I got this crash with three unrelated ports:
```
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x022c
Crashed Thread: 3
. . .
Thread 3 Crashed:
0 libauto.dylib 0x00967f18
Auto::Zone::regis
I will deal with R-related ports, either dropping or adding related test
deps.
For Ruby: IMO, everything Ruby19-based should be either updated to the
modern Rubies or removed. (However, I am not gonna be involved in that.)
On Mon, Oct 28, 2024 at 8:33 PM MacPorts wrote:
> #71182: Ports that dep
I will deal with R-related ports, either dropping or adding related test
deps.
For Ruby: IMO, everything Ruby19-based should be either updated to the
modern Rubies or removed. (However, I am not gonna be involved in that.)
On Mon, Oct 28, 2024 at 8:48 PM Sergey Fedorov wrote:
> I will d
Ok, but why does Sonoma use a mismatching version of Xcode? At least before
it is fixed.
On Sun, Sep 22, 2024 at 6:17 AM Joshua Root wrote:
> On 22/9/2024 07:27, Sergey Fedorov wrote:
> > I can’t make anything of the error messages too:
> > ```
> > 2024-09-21T21:12:38.72
Something weird going on with CI. Look at this:
https://github.com/macports/macports-ports/actions/runs/10974946673/job/30474027942?pr=25864
I rebased this PR several times, without changing ports in it, and every
time failures are random.
(There was one non-random one, it is fixed.)
I can’t make
On Tue, Sep 17, 2024 at 10:12 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:
> In my PPC Debian world, my 64-bit installation of Debian PPC is quite able
> to run 32 bit software.
>
> Linux does this by putting the libraries into lib64 or lib32 subfolders,
> as Linux does not use "Fat
On Wed, Sep 18, 2024 at 8:41 AM Fred Wright wrote:
>
> On Tue, 17 Sep 2024, Fred Wright wrote:
> And just to clarify, I'm saying that running ldconfig *instead of* messing
> with libdir is probably the correct fix.
>
I am not an expert on Linux, so if someone implements some solution that
makes
On Wed, Sep 18, 2024 at 7:12 AM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:
> Of course, if you over-write 64 bit libs with 32 bit libs of the same
> name, or vice versa, in the same location, you are just hosed, ldconfig or
> no ldconfig.
>
> Which is why linux has the lib32 and lib6
is
>
> On 15 Sep 2024, at 1:59 PM, Sergey Fedorov wrote:
>
> Currently nothing in MacPorts sets libdir for CMake ports. On MacOS this
> is no issue. On Linux this leaves multiple ports broken, since CMake throws
> libs into ${prefix}/lib64, where nothing looks for them, so all depen
Currently nothing in MacPorts sets libdir for CMake ports. On MacOS this is
no issue. On Linux this leaves multiple ports broken, since CMake throws
libs into ${prefix}/lib64, where nothing looks for them, so all dependents
are broken.
As a few examples: libdeflate, lerc, libjpeg-turbo.
I think th
/main.c:272
#4 0x00014fc8 in server_thread (arg=) at ../xorg-server-2.8.5/hw/xquartz/quartzStartup.c:65
#5 0x00673064 in _pthread_start ()
```
On Sat, Aug 31, 2024 at 4:18 AM René J.V. Bertin
wrote:
> On Saturday August 31 2024 04:06:09 Sergey Fedorov wrote:
>
> >2. Does anyone know
Greetings, everyone
A couple of questions re xorg-server:
1. Is there any special reason to keep xorg-server at an apparently archaic
version in MacPorts? For legacy systems there is a dedicated port, so that
is not a concern.
2. Does anyone know if xorg-server is modular, specifically, is hw/xqu
For testing purposes, I want to use an existing MacPorts installation with
another local system (same major darwin version, different minor). Is there
a way to do that besides actually copying the whole tree (or reproducing it
via installing)?
Specifically, I want to try building a few specific po
I am interested in trying MacPorts on Linux on RISC-V by the way.
Last non-Mac attempt, on OpenBSD, failed on sqlite3 being broken:
https://trac.macports.org/ticket/69354
On Wed, Jul 17, 2024 at 10:37 PM René J.V. Bertin
wrote:
> Hi,
>
> I've been updating a number of the python packages I have
he same thing as:
> >
> > @autoreleasepool
> > {
> >
> > }
> >
> > but just a little less beautifully.
> >
> > Now the commit you referenced has this older construct still in place.
> But I didn't look at the current source code that you are
/java_md_macosx.c#L1034-L1063
But we get that warnings on start-up.
On Tue, Jul 16, 2024 at 10:48 PM Sergey Fedorov wrote:
> Thank you, Ken.
>
> This is the reference to the current code in OpenJDK 8:
> https://github.com/openjdk/jdk8u/blob/105098218562ce8b62938fb7def2cde918df0b45/jdk/sr
less beautifully.
>
> Now the commit you referenced has this older construct still in place. But
> I didn't look at the current source code that you are compiling to see what
> it has.
>
> Ken
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> { }
On Tue, Jul 16, 2024 at 6:19 PM Saagar Jha wrote:
> I’m guessing that since the block runs elsewhere there isn’t an
> autoreleasepool for it anymore. You can probably fix this by wrapping the
> call to JavaMain in @autoreleasepool {}?
> Saagar Jha
>
This syntax is not supported by GCC, we need t
Ones linked above.
*wontfix* is appropriate for something either impossible or going against
MacPorts policies.
I do not think it should be used in a sense of “I am not gonna deal with
fixing it”, because the problem is unresolved, and someone else may wish to
fix it.
There is nothing here, AF
Perhaps actually close two of the three, and let one ticket be opened,
which can be assigned to myself, if there are no objections.
On Tue, Jul 9, 2024 at 12:32 AM Sergey Fedorov wrote:
> It is fine to close the ticket if someone really wants, however why not
> just remove assignment
It is fine to close the ticket if someone really wants, however why not
just remove assignment to the maintainer?
I intend to return to fixing that, but no time at the moment, busy with
other stuff.
On Tue, Jul 9, 2024 at 12:24 AM Joshua Root wrote:
> On 9/7/2024 02:05, bl...@netjibbing.com wrot
https://trac.macports.org/ticket/70306
Most of Python deps are not in MacPorts for it, apparently:
https://github.com/FalkAlexander/PasswordSafe/blob/e38d04d18db2faa2be0fa04dfadd0ce3d0c0b329/meson.build#L29-L43
I am not good with Python stuff, though I can probably handle PasswordSafe
itself, onc
Could someone please trigger rebuild for
https://ports.macports.org/port/R-RcppParallel/details on 10.10 and 10.11?
OneTBB is fixed on those OS by
https://github.com/macports/macports-ports/pull/24492
Yes, it got fixed pretty quickly.
But when it failed, it failed on two systems which have nothing in common,
so should not have been local.
On Sun, Jun 2, 2024 at 1:58 AM grey wrote:
> I am guessing this was fixed?
>
> Regardless, I can't seem to reproduce a failed signature verification
> loca
pango is an essential port, and currently fails to build on 10.4.11:
https://trac.macports.org/ticket/69876
Great, thank you.
Wonder when this annoying bug is fixed:
https://gitlab.kitware.com/cmake/cmake/-/issues/25656
https://gitlab.kitware.com/cmake/cmake/-/issues/25514
On Thu, Apr 25, 2024 at 5:41 AM René J.V. Bertin
wrote:
> FYI: https://gitlab.kitware.com/cmake/cmake/-/issues/25931
>
> (fix sho
BTW, linking to LegacySupport is not done correctly with py-numpy at the
moment, so even though on ppc it builds, it is not built in the right way
now.
Something I planned to fix, but need to find time for that.
Also, make sure to avoid blis being active, otherwise it gets linked to it,
and that w
I am pretty sure there are people outside of Macports, or at least not on
its developers list, who use < 10.7.
Some on MacRumors, for instance; quite likely that those who are on KDX and
Hotline also run those on 10.4–10.5, though I have no statistics on that.
Sure enough, it is not a numerous grou
It actually could be that debugging flags are ruining the build. MongoDB
passes `-ggdb` and some other.
Throw that away, and chances are it compiles.
Difference, apparently, can be huge:
https://lists.apple.com/archives/xcode-users/2008/Oct/msg00279.html
https://lists.gnu.org/archive/html/libtool
Can something be done about this error or is it a hard constraint of 32-bit
arch?
I have encountered the same error with NodeJS, as I recall, and now with
MongoDB:
```
libtool: can't vm_allocate() buffer for output file:
build/MP/mongo/db/s/libsharding_commands_d.a of size 1218661592 ((os/kern)
no
UPD. Judging from my notes, it actually may be fixable now, since gcc
upstream addressed the stopping bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
Need to rebuild gcc13 adding this patch and see if it helps.
On Mon, Mar 18, 2024 at 12:34 AM Sergio Had wrote:
> Upon sorting X11 instal
I actually wonder if we get SDL2 and VLC2 working then as well on Leopard
via X11 backend then.
On Sun, Mar 17, 2024 at 3:47 AM Sergey Fedorov wrote:
> Ken, thanks for fixing it for gcc7, and great to hear that it works with
> GUI.
>
> I tested it in CLI on 10.6 ppc, that worked f
Ken, thanks for fixing it for gcc7, and great to hear that it works with
GUI.
I tested it in CLI on 10.6 ppc, that worked fine, but X11 one fails to
launch. (However, it is likely that it is not a problem with the code or
with the 10.6 ppc, but rather with conflict between Macports and
non-Macport
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.
Related PR: https://github.com/macports/macports-ports/pull/22796
(Tests still run only manually under a regular user though.)
On Sun, Feb 25, 2024 at 1:21 PM Sergey Fedorov wrote:
> For some reason sudo is not allowed. For example, I try using *system
> "sudo -u svacchanda ./Vidal
1.0 and cmake 1.1 fail identically with regard to running
tests.
On Sat, Feb 24, 2024 at 2:28 PM Joshua Root wrote:
> On 24/2/2024 17:27, Sergey Fedorov wrote:
> > If Macports is running as root, but tests require non-root user, how to
> > do that?
> > There is no test.asroot no
: TorrcTestSuite::testRunningTor()
PASS : TorrcTestSuite::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped, 0 blacklisted, 12273ms
* Finished testing of TorrcTestSuite *
On Sun, Feb 25, 2024 at 12:06 AM Sergey Fedorov wrote:
> Thank you.
>
> This bran
test Vidalia: command execution failed
On Sat, Feb 24, 2024 at 11:56 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:
> Oh, OK…. That’s different then, for sure.
>
> Let me see if I get the same result.
>
> K
>
> On Feb 24, 2024, at 08:32, Sergey Fedorov wrote:
Ken, you are right about 10.6-ppc, of course, but in this particular case I
am having an issue with Sonoma.
Specifically, I cannot get Vidalia tests run with *sudo port test*. At the
same time, they run fine if I launch the test binary manually without sudo.
What fails:
1. sudo port test vidalia
2
If Macports is running as root, but tests require non-root user, how to do
that?
There is no test.asroot no, apparently.
I can test it on PowerPC, so that archs are set correctly.
Which port though?
On Wed, Jan 24, 2024 at 9:49 AM Mark Anderson wrote:
>
> supported_archs x86_64 (perhaps those others work too) is in my branch
> already to be pushed and I plan on pushing it up shortly, but it seems to
> still fail
Dave, Josh, thanks for taking care of h5fortran!
On Sun, Jan 14, 2024 at 10:34 AM Dave Allured - NOAA Affiliate via
macports-dev wrote:
> On Sat, Jan 13, 2024 at 6:24 PM Joshua Root wrote:
>
>> On 14/1/2024 12:04, Dave Allured - NOAA Affiliate via macports-dev wrote:
>> > Would someone please p
system I used back then, when added support for
tests for this port) performs better than Sonoma with CMake. (No
exaggeration, it is literally the case: with CMake 12 tests fail on 14.2.1.)
On Tue, Jan 9, 2024 at 8:34 PM Sergey Fedorov wrote:
> So, to Ken’s claim re gperftools.
>
> > A
ign.
> tcmalloc_zone.version = 6;
> - tcmalloc_zone.free_definite_size = &mz_free_definite_size;
> tcmalloc_zone.memalign = &mz_memalign;
> +#ifndef __POWERPC__
> + tcmalloc_zone.free_definite_size = &mz_free_definite_size;
> tcmalloc_introspection.zone_locked = &
do it.
>
> My assumption is no, or possibly a very, very small number of people. You
> can buy a much newer and better machine for a pittance on eBay or the
> equivalent.
>
> I will note, however, that there are a huge number of people who rely on
> Sonoma on Intel or ARM as
they should not take more time
to merge.
There is also not much problem to maintain ppc-specific code: if it is
there at all, do not touch it, and it gonna work. PPC does not change much
nowadays ;)
On Tue, Jan 9, 2024 at 2:26 AM Perry E. Metzger wrote:
> On 1/8/24 12:50, Sergey Fedorov wr
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
> 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
This is forever broken, which means that nothing can be built on Leopard
for ppc64 in default Macports setup: https://trac.macports.org/ticket/68614
Linker requires llvm-3.3 (or llvm-3.4, optionally), neither builds for
ppc64.
While cctools have dropped requirement for depending on llvm, it is st
Kirill A. Korinsky wrote:
> X11 for old system is dramatically more time which I won't have for a
> while.
>
> :(
>
> --
> wbr, Kirill
>
> On 22. Oct 2023, at 20:19, Sergey Fedorov wrote:
>
> Kirill, when you will have time for this, please also check if we can
&g
Kirill, when you will have time for this, please also check if we can build
this as X11-only for old systems, where native ObjC libs fail to build.
I fixed the build on PPC up to AWT libs, but those are hopeless, or I got
no idea what to do to fix them anyway.
If we get rid of those, perhaps we can
Could someone who understands what mpbb scripts are doing address this?
https://trac.macports.org/ticket/68408
We got numerous R ports broken by this on CI. (Locally everything works
fine, buildbot apparently too.)
I can’t keep updating R ports unless this is fixed. It is too much of a
meaningles
; In PROJ version 5 through 8 the API was transformed, this means with
>> version 8 the “old” API was abandoned.
>> SAGA, for example, still only support the old API, thus the proj version
>> 7 is the latest one supported.
>>
>> Cheers,
>> Nicklas
>>
>> On 8
to the latest upstream version,
> as proposed.
>
>
> On Thu, Jun 8, 2023 at 2:09 PM Sergey Fedorov wrote:
>
>> IMO that makes sense.
>>
>> My R ports are supposed to support more recent versions of Proj than 5,
>> but since that is untested locally (and a
Intel is the most compatible here
with default thoughtless choices of some upstreams).
In this context maybe someone would have an interest in making it work on
the older Intel? (If I get this to work on PPC, I will test on Intel too.)
On Sat, Aug 5, 2023 at 9:20 PM Sergey Fedorov wrote:
> &
; their full GUIs needing more current SDK features.
>
> A recent update to the mplayer-devel code broke <10.7 , but that looks
> like an easy fix to me.
>
>
>
>
>
> On Aug 4, 2023, at 23:03, Sergey Fedorov wrote:
>
>
> > even if you find some old versio
l even on Tiger
> PPC last I tried it.
>
> Anyway, play with VLC as you wish, of course.
>
>
>
> On Aug 4, 2023, at 5:26 PM, Sergey Fedorov wrote:
>
> Don’t worry, I will not submit a PR for VLC unless it actually works with
> video. There is no point otherwise.
>
&
<
ken.cunningham.web...@gmail.com> wrote:
> For playing videos on older systems, I think MPlayer is the way to go.
>
> Give that a try if you haven't.
>
> Ken
>
>
> On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:
>
> I need an advice.
>
> We got VLC2 port (which
I need an advice.
We got VLC2 port (which is totally broken for all systems) and VLC port,
which installs pre-built binary. Neither supports PPC, obviously, and even
i386.
Leaving the main VLC aside, VLC2 is already a mess and in the present state
is unusable for practical purposes. Rewriting the
Thank you, this reply from Ken answers the query about 10.6 Intel and early
Qt5 usefulness:
> Now I did get qt5.4 to build on 10.6, with moderate efforts, but it was
not overly useful because by the time I did that, not much software would
still build against qt5.4 anyway.
On Sat, Jul 29, 2023 at
Apparently it works now?
https://github.com/macports/macports-ports/pull/19047#issuecomment-1645344425
On Fri, Jul 21, 2023 at 4:14 AM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:
> Some interested users discovered a deficiency in a part of
> legacy-support’s fdopendir implementation,
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
> >&
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
, 2023 at 3:17 AM Fred Wright wrote:
>
> On Sun, 16 Jul 2023, Sergey Fedorov wrote:
>
> >> The linked code is for an emulator, and is providing a *C*
> > implementation, not a ppc32 machine-code
> >
> > Whatever provides the needed functionality, gonna be good en
> However, patching it into a source file that needs it on a case-by-case
basis is probably a fairly trivial thing to do.
This is what I meant.
> The linked code is for an emulator, and is providing a *C*
implementation, not a ppc32 machine-code
Whatever provides the needed functionality, gonna
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.
https://trac.macports.org/ticket/67712
We either need to make a fallback for needed functions, or revert a
breaking commit, or at least peg the last working version (0.4.45?).
Thoughts? What will be a better solution?
https://trac.macports.org/ticket/67685
What everyone thinks? I am merely asking – no issues if you guys think
it is unneeded or undesirable.
I am afraid I cannot help much here: I neither have 10.9 nor have any
substantial understanding of Clang builds, since I only use GCC.
Maybe open a ticket on Trac?
P. S. Fixes are always welcome, just make sure they are conditional on
Clang or libc++, whenever appropriate. (GCC build on 10.6 compl
https://trac.macports.org/ticket/67607
IMO that makes sense.
My R ports are supposed to support more recent versions of Proj than 5, but
since that is untested locally (and also requires minor adjustments to
configure args besides swapping version number), it is perhaps safer to
keep them at Proj5 for now (I guess that is also simpler
If anyone knows modern Fortran well enough and got a bit of time, I would
greatly appreciate some advice on two issues:
1. Currently gfortran has no support for ieee_arithmetic on PPC. I have
written an implementation, which kinda works – most of tests from Gfortran
suite pass fine. However there
FFMpeg can certainly be compiled without Rust, including the latest
(upstream) version.
Perhaps a component that is pulling in Rust should rather be made an
optional variant for all systems – it is hardly justified to have it as the
default, IMHO.
On Wed, Dec 14, 2022 at 12:32 AM grey wrote:
> T
In fact, we even have ports which only install pre-built app when the
source are freely available:
https://github.com/macports/macports-ports/blob/master/audio/xld/Portfile
Someone, explain me please, what makes OnyX different?
On 11/23/22, Sergey Fedorov wrote:
> My initial thought was
MacPorts on my machine.
>
> Nils.
>
> Op 23 nov. 2022 om 04:50 heeft Sergey Fedorov het
> volgende geschreven:
>
>
> Hi everyone, I have recently made a port that installs OnyX for every
> system from Tiger onwards:
> https://github.com/macports/macports-ports/pull/16710
indeed unneeded to have gazillions of ports of such a kind;
however, as for OnyX goes, it is a useful and widely used app, supporting
every version of macOS. How does it hurt to have it?
Best regards,
Sergey Fedorov
GitHub: @barracuda156
88 matches
Mail list logo
