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
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
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
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
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
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
https://trac.macports.org/ticket/67607
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/67685
What everyone thinks? I am merely asking – no issues if you guys think
it is unneeded or undesirable.
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?
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.
> 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
, 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
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
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
> >&
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,
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
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
<
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
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.
>
&
; 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
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:
> &
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
; 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
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
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
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
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
> 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
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
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
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
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
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 = &
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
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
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
If Macports is running as root, but tests require non-root user, how to do
that?
There is no test.asroot no, apparently.
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
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:
: 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
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
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
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.
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
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
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
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
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
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
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
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
pango is an essential port, and currently fails to build on 10.4.11:
https://trac.macports.org/ticket/69876
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
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
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
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
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
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
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
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];
> { }
/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
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
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
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
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
/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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
Is it something trivially doable or is it gonna require some rewrites?
On Tue, Mar 25, 2025 at 1:28 AM Ryan Carsten Schmidt <
ryandes...@macports.org> wrote:
> On Mar 24, 2025, at 09:23, Sergey Fedorov wrote:
> >
> >
> > On a slow connection downloading ports be
On a slow connection downloading ports becomes a nightmare: MacPorts keeps
dropping connection, and since fetch starts anew every time, it may take
literally forever to proceed.
A lot of tools support resumable downloads. Is it possible to implement
that?
If the question is whether it is possible to compile for 10.6 x86_64, then
certainly yes.
However, you seem to be doing rather non-trivial thing: compiling on 10.6 with
libc++ from 10.7 and intention to have binaries working on 10.6+.
If you do not have to build texlive often and have some spac
On Sat, Apr 5, 2025 at 7:32 AM Mojca Miklavec wrote:
> On Sat, 5 Apr 2025 at 00:55, Sergey Fedorov wrote:
> >
> > If you do not have to build texlive often and have some space on a
> drive, won’t it be easier to just use a native C++ runtime, libstdc++, for
> 10.6?
>
>
Is there a way to revbump every port which includes a given portgroup?
A quick attempt to place `incr revision` did not have an effect (or I did
it wrong).
Use cases: R ports (4.4.x to 4.5.x, for example), OCaml ports (I am not
sure of an algorithm here, but at least on some updates of OCaml every
ckages after a major version upgrade of octave itself.
>
> Note: these updates don’t always go well.
>
> > On Apr 22, 2025, at 1:22 AM, Sergey Fedorov wrote:
> >
> > Is there a way to revbump every port which includes a given portgroup?
> > A quick attempt to place
Ok, got it. Thank you for clarifying.
On Apr 22, 2025 at 22:47 +0800, Ryan Carsten Schmidt ,
wrote:
> On Apr 22, 2025, at 01:23, Sergey Fedorov wrote:
> >
> > Is there a way to revbump every port which includes a given portgroup?
>
> Only by (manually or using a script) editi
It should, of course, and I am pretty sure I actually had libmpc built as
+universal at least on Leopard.
Serge
On Feb 19, 2025 at 19:17 +0700, Ryan Carsten Schmidt ,
wrote:
> On Feb 19, 2025, at 04:17, Riccardo Mottola wrote:
> >
> > Error: its dependency libmpc cannot build for the required ar
For ppc part I am in. Especially if Palemoon fixing doesn’t proceed much (it
builds, but does not work yet).
Serge
On Feb 19, 2025 at 17:23 +0700, Riccardo Mottola via macports-dev
, wrote:
> raf via macports-dev wrote:
> > > Without you, no TenFourFox on Intel and also no ArcticFox on Macs.
> >
This is on Sonoma, not PowerPC:
Synchronizing local ports tree from rsync://
rsync.macports.org/macports/release/tarballs/ports.tar
rsync: failed to connect to rsync.macports.org: Connection refused (61)
rsync error: error in socket IO (code 10) at
/AppleInternal/Library/BuildRoots/289ffcb4-455d
Everything started re-indexing again now.
This was never happening with official sources.
(It does happen with *my* sources, because git updates timestamps on all
files, and MacPorts thinks that all ports are changed, and I just do not
know how to fix this annoying behavior, but at least my sourc
It is the second time in about 12 hrs that all ports are reindexing from
scratch. This should not be happening. Likely something messes up
timestamps on the server side.
1 - 100 of 109 matches
Mail list logo
