From dave.allured at noaa.gov  Tue Jul  1 16:15:06 2025
From: dave.allured at noaa.gov (Dave Allured - NOAA Affiliate)
Date: Tue, 1 Jul 2025 10:15:06 -0600
Subject: Fetching remote content
In-Reply-To: <48dd155d-237a-4267-8daf-1f24c2009930@macports.org>
References: <CALqwTFNf_tgD9eXKvMfCfxsgkO=V-icUdgjEGUoD1k3c0YrBdQ@mail.gmail.com>
 <48dd155d-237a-4267-8daf-1f24c2009930@macports.org>
Message-ID: <CALqwTFP1mYOhbisTvJS3+NAtFC+n9+6Se9ocxTJZYT=d9W6XQA@mail.gmail.com>

On Mon, Jun 30, 2025 at 1:48?PM Joshua Root <jmr at macports.org> wrote:

> On 1/7/2025 01:01, Dave Allured - NOAA Affiliate via macports-dev wrote:
> > Build systems may include features to fetch arbitrary remote code
> > outside of normal MacPorts controls.  An example is FetchContent in
> > CMake.  This can result in unexpected dependency versions and other
> > surprises.
> >
> > What are MacPorts guidelines for allowing or blocking remote fetching?
> > I could not find an established policy.  Should there be one?
>
> "Don't fetch anything outside the fetch phase if at all possible."
>
> We don't disallow it entirely because there are (unfortunately) some
> build systems that will not work that way. I don't know how distros like
> FreeBSD that do completely disallow such behaviour deal with those build
> systems.
>

 Well put.  I fully agree with this conservative approach.  Thank you for
confirming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20250701/3152375a/attachment.htm>

From jmr at macports.org  Tue Jul  1 21:22:41 2025
From: jmr at macports.org (Joshua Root)
Date: Wed, 2 Jul 2025 07:22:41 +1000
Subject: Fetching remote content
In-Reply-To: <CALqwTFP1mYOhbisTvJS3+NAtFC+n9+6Se9ocxTJZYT=d9W6XQA@mail.gmail.com>
References: <CALqwTFNf_tgD9eXKvMfCfxsgkO=V-icUdgjEGUoD1k3c0YrBdQ@mail.gmail.com>
 <48dd155d-237a-4267-8daf-1f24c2009930@macports.org>
 <CALqwTFP1mYOhbisTvJS3+NAtFC+n9+6Se9ocxTJZYT=d9W6XQA@mail.gmail.com>
Message-ID: <296afc72-754f-47b6-91e5-3432b8dadf8d@macports.org>

On 2/7/2025 02:15, Dave Allured - NOAA Affiliate wrote:
> 
> 
> On Mon, Jun 30, 2025 at 1:48?PM Joshua Root <jmr at macports.org 
> <mailto:jmr at macports.org>> wrote:
> 
>     On 1/7/2025 01:01, Dave Allured - NOAA Affiliate via macports-dev wrote:
>      > Build systems may include features to fetch arbitrary remote code
>      > outside of normal MacPorts controls.? An example is FetchContent in
>      > CMake.? This can result in unexpected dependency versions and other
>      > surprises.
>      >
>      > What are MacPorts guidelines for allowing or blocking remote
>     fetching?
>      > I could not find an established policy.? Should there be one?
> 
>     "Don't fetch anything outside the fetch phase if at all possible."
> 
>     We don't disallow it entirely because there are (unfortunately) some
>     build systems that will not work that way. I don't know how distros
>     like
>     FreeBSD that do completely disallow such behaviour deal with those
>     build
>     systems.
> 
> 
>  ?Well put.? I fully agree with this conservative approach.? Thank you 
> for confirming.

BTW, the aforementioned "other surprises" include breaking offline 
builds and making it impossible for us to mirror all sources. The latter 
can go beyond causing fetch issues as it can actually be a license 
violation in some cases if we distribute binaries.

We have a global sandbox_network setting that is off by default due to 
the potential for breakage. Maybe we should look at changing the default 
to on and allow overriding it via a Portfile option, so we would at 
least know which ports are badly behaved.

- Josh

From broly at mac.com  Tue Jul  1 21:39:28 2025
From: broly at mac.com (Gagan Sidhu)
Date: Tue, 1 Jul 2025 15:39:28 -0600
Subject: updating macports-libcxx to llvm-19+
In-Reply-To: <CALBOmsYWJJrEBjTj7rSJw9_cUJKGjNpSNrSWOkKnXWNtY91onA@mail.gmail.com>
References: <B5D3219D-3EBC-42C2-AF2D-94E85DF2023A@mac.com>
 <7DD2E62D-65CB-478D-A99C-35E9AFB8EA9E@mac.com>
 <2cef07ad-8bc0-45ea-9928-98ff383275f8@hep.phy.cam.ac.uk>
 <7BBE8C6D-D408-4DF9-9685-46574917EEE8@mac.com>
 <BDBF7EB0-4DBC-45AE-97F0-EC64CFA66FCE@mac.com>
 <CALBOmsYWJJrEBjTj7rSJw9_cUJKGjNpSNrSWOkKnXWNtY91onA@mail.gmail.com>
Message-ID: <B9F1E287-FAD3-4F50-B13D-5F9024002948@mac.com>

i am just responding on the list because i think the information is helpful to others as well, sorry mojca if you weren't expecting that. 
	-i won't do it in the future if that's the case.

two things: i did manage to get llvm-19 to build without issue on snow leopard.

however it seems there's a problem for clang-19 and higher which is they don't allow building for 10.6 targets because of x86_64h?

surely this is probably some kind of macro people removed in the past for clang-17 etc?

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-19/clang-19/work/llvm-project-19.1.7.src/compiler-rt/cmake/config-ix.cmake

"    # Note: In order to target x86_64h on OS X the minimum deployment target must
    # be 10.8 or higher.
    if(MIN_OSX_VERSION VERSION_LESS "10.7")
      message(FATAL_ERROR "macOS deployment target '${SANITIZER_MIN_OSX_VERSION}' is too old.")
    endif()

"

in short, as it stands: it seems clang-19 doesn't even support 10.6 so this shouldn't be a concern?

Thanks,
Gagan

> On Jun 30, 2025, at 3:20 AM, Mojca Miklavec <mojca.miklavec.lists at gmail.com> wrote:
> 
> Off-list, and please note that I'm not really active / not much time
> myself, so please don't expect answers from me.
> 
> Please open merge requests with your patches.
> Does clang-19 also build on Snow Leopard (10.6 is still relatively
> important platform)?
> 
> Mojca
> 
> On Mon, 30 Jun 2025 at 04:07, Gagan Sidhu via macports-dev
> <macports-dev at lists.macports.org> wrote:
>> 
>> first i want to thank the team for reworking the clang stuff.
>> 
>> clang-19 has now built successfully on lion. it wasn't bad at all. like a couple of lines.
>>        -i suspect someone on the team deliberately didn't make these changes to see if i cared. i do, i'm just busy with a bunch of things right now
>>                -hopefully if i get these e55 fuel pumps going in my 4matic tomorrow i'll have more time to enjoy my summer
>>                        -like, sitting in the sun getting wasted in front of my 2020 i9 16" 5600m
>> 
>> what are the other prerequisites for tabling the update of macports-libcxx to clang-19?
>> 
>> we need to do this asap so i can try to push out fixes for node
>> 
>> hoping someone on the team is ready to receive and test a "patch" (as much of a joke as the patch is)
>> 
>> Thanks,
>> Gagan
>> 
>>> On Mar 31, 2025, at 9:05 AM, Gagan Sidhu via macports-dev <macports-dev at lists.macports.org> wrote:
>>> 
>>> interesting.
>>> 
>>> i will try to look into that.
>>> 
>>> thanks
>>> 
>>>> On Mar 31, 2025, at 9:03 AM, Chris Jones via macports-dev <macports-dev at lists.macports.org> wrote:
>>>> 
>>>> 
>>>> clang-19+ currently does  not build on a number of older OSes, its limited to Darwin15 and newer. Before updating macports-libcxx someone with the time and inclination should look into that first I would say.
>>>> 
>>>> cheers Chris
>>>> 
>>>> On 31/03/2025 2:40 pm, Gagan Sidhu via macports-dev wrote:
>>>>> any thoughts on this?
>>>>> i think it?s time.
>>>>> Thanks,
>>>>> Gagan
>>>> 
>>> 
>> 



Thanks,
Gagan


From atod101101 at gmail.com  Thu Jul  3 04:47:00 2025
From: atod101101 at gmail.com (Nick)
Date: Thu, 3 Jul 2025 00:47:00 -0400
Subject: are there pre-built binaries that can run on non privileged account?
Message-ID: <CAG9BPSXcn+t1VAuUgJbo_E3jX40hgpj7pe3E9QLW8LGC3hPKwQ@mail.gmail.com>

I'm currently using macports-base configured as:
--prefix=${HOME}/mp --with-install-user=u00 --with-install-group=g00
with some success so far, compiling everything from a clone of
macports-ports.

I encountered an issue, where 'xinit' build broke because it required root
privileges.  I worked around that by changing the Portfile.

I'm curious if the buildbot build non privileged binaries as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20250703/f582d058/attachment.htm>

From jmr at macports.org  Thu Jul  3 14:31:58 2025
From: jmr at macports.org (Joshua Root)
Date: Fri, 4 Jul 2025 00:31:58 +1000
Subject: are there pre-built binaries that can run on non privileged
 account?
In-Reply-To: <CAG9BPSXcn+t1VAuUgJbo_E3jX40hgpj7pe3E9QLW8LGC3hPKwQ@mail.gmail.com>
References: <CAG9BPSXcn+t1VAuUgJbo_E3jX40hgpj7pe3E9QLW8LGC3hPKwQ@mail.gmail.com>
Message-ID: <e28f270e-e91c-4937-9529-bb0da359bd88@macports.org>

On 3/7/2025 14:47, Nick wrote:
> I'm currently using macports-base configured as:
> --prefix=${HOME}/mp --with-install-user=u00 --with-install-group=g00
> with some success so far, compiling everything from a clone of macports- 
> ports.

FYI, the --with-no-root-privileges configure option will automatically 
set the installer user and group based on the current user, and will 
also set the initial value of startupitem_install to "no".

> I encountered an issue, where 'xinit' build broke because it required 
> root privileges.? I worked around that by changing the Portfile.

That allowed you to install it, but does it actually work without root?

> I'm curious if the buildbot build non privileged binaries as well?

Our buildbot builds binaries only for the /opt/local prefix, which is 
the main reason you can't use them from a typical non-root installation. 
In principle, someone could run a buildbot configured to build ports for 
whatever prefix they like, but it would not be widely useful if that 
prefix is inside the home directory of a particular user.

The permissions on our binaries are set such that anyone on the system 
can read the non-sensitive files and run the executables after the 
binary has been installed into a root-owned MacPorts prefix, so in that 
sense most of the binaries are unprivileged.

Some binaries will of course require additional privileges to do their 
job when run, and many will run more securely when started as root 
because then they can setuid to an unprivileged user right after starting.

- Josh