Re: Port Reclaim

2023-11-06 Thread Christopher Jones
Run

 > port list requested

and check everything you expect to be there is. If not, manually set it as 
requested yourself

> sudo port setrequested  XYZ

port reclaim will not remove anything in the above list, or anything in the 
dependency tree of something in that list. Anything else is fair game to remove.

cheers Chris

> On 6 Nov 2023, at 5:29 pm, Mark Anderson  wrote:
> 
> This is a 100% fresh install. I have had this problem with migrations before 
> - so I decided to start fresh this time. 
> 
> —Mark
> ___
> Mark E. Anderson mailto:m...@macports.org>>
> MacPorts Trac WikiPage 
> GitHub Profile 
> 
> 
> 
> On Mon, Nov 6, 2023 at 8:18 AM Kirill A. Korinsky  > wrote:
>> are you sure that you have migrated list of requested ports as well?
>> 
>> As far as I recall the list of requested ports are migrated at separetly 
>> steps.
>> 
>> Otherwise it should be expected and default behaviour to mark something as 
>> requested when you install it via `port install blabla`
>> 
>> -- 
>> wbr, Kirill
>> 
>>> On 6. Nov 2023, at 12:03, Mark Anderson >> > wrote:
>>> 
>>> Is that the only way? I've done that in the past with migrations, but for 
>>> Sonoma, I did a fresh install and installed ports as I wanted them again 
>>> from a list I kept. I assumed if I did a `port install` on any port it 
>>> would have marked those as requested.
>>> 
>>> —Mark
>>> ___
>>> Mark E. Anderson mailto:m...@macports.org>>
>>> MacPorts Trac WikiPage 
>>> GitHub Profile 
>>> 
>>> 
>>> 
>>> On Mon, Nov 6, 2023 at 6:47 AM Kirill A. Korinsky >> > wrote:
 you may specificly mark your port to be requested via `port setrequested 
 blabla`
 
 -- 
 wbr, Kirill
 
> On 6. Nov 2023, at 11:39, Mark Anderson  > wrote:
> 
> I'm noticing that port reclaim routinely is asking to uninstall all my 
> ports. And this is not post migration. The rest of the command works as I 
> expect.
> 
> —Mark
> ___
> Mark E. Anderson mailto:m...@macports.org>>
> MacPorts Trac WikiPage 
> GitHub Profile 
> 
 
>> 



call for Xcode15 Intel testers ?

2023-10-02 Thread Christopher Jones
Hi all,

Could I ask if anyone is running an Intel system, with Xcode 15 installed to 
take a look at

https://trac.macports.org/ticket/68322

and in particular report if they can build libgcc12 or not. The report there is 
seemingly showing issues with the ‘ld -ld_classic’ workaround we are using for 
the linker issues Xcode 15 has, which I don’t yet understand.

Chris

Re: { darwin any } ports getting reinstalled after OS upgrade

2023-09-27 Thread Christopher Jones



> On 27 Sep 2023, at 2:01 pm, Nils Breunese  wrote:
> 
> Christopher Jones  wrote:
> 
>> I had no idea we supported single tarballs for multiple OS versions. 
>> 
>> I must say, the distinction between
>> 
>> platforms { darwin any }
>> 
>> and
>> 
>> platforms {darwin >= 11}
>> 
>> which *does* result in specific tarballs for each OS is a bit too subtle for 
>> my tastes. I presume it’s the present of ‘any’ which is important here ?
> 
> You can do this:
> 
>   platforms { darwin any } { darwin >= 11 }
> 
> Which means that the port will install on Darwin 11+, and it will install 
> identically on all of those supported versions.

Yes, I get that now, but it wasn’t my point.




Re: { darwin any } ports getting reinstalled after OS upgrade

2023-09-27 Thread Christopher Jones



> On 27 Sep 2023, at 12:32 pm, Ryan Schmidt  wrote:
> 
> On Sep 27, 2023, at 06:09, Christopher Jones wrote:
>> 
>> That just means they are *supported* on any drawn version. Each version 
>> still have its own build.
> 
> But that's just what "any" means: they build identically on any OS version. 
> That's why only one single archive gets produced for these ports by the build 
> system. When MacPorts on any OS version installs such a port, they all grab 
> and untar the same file from the server. 

I had no idea we supported single tarballs for multiple OS versions. 

I must say, the distinction between

platforms { darwin any }

and

platforms {darwin >= 11}

which *does* result in specific tarballs for each OS is a bit too subtle for my 
tastes. I presume it’s the present of ‘any’ which is important here ?

Is the logic behind what all the various options we can now use with platforms 
documented somewhere ?

cheers Chris

> 
> Nils is right in pointing out that there should be no need to reinstall those 
> ports when upgrading the OS, but nobody has written any code to make that 
> happen yet. For now, MacPorts will consider any port to need to be 
> reinstalled if it was installed on a different OS version, even if that port 
> is marked "any". 
> 
>> b.t.w. When upgrading to a new major OS version, you anyway should follow 
>> the migration instructions, which involves manually removing all ports 
>> anyway.
> 
> We do recommend that, but the piecemeal method Nils is using is also viable.



Re: { darwin any } ports getting reinstalled after OS upgrade

2023-09-27 Thread Christopher Jones

That just means they are *supported* on any drawn version. Each version still 
have its own build.

b.t.w. When upgrading to a new major OS version, you anyway should follow the 
migration instructions, which involves manually removing all ports anyway.

https://trac.macports.org/wiki/Migration

See point 3c.

Chris

> On 27 Sep 2023, at 11:42 am, Nils Breunese  wrote:
> 
> Hi,
> 
> I’ve updated to macOS 14, installed MacPorts 2.8.1 for Sonoma and then 
> upgraded my ports. I noticed that ports that use ‘platform { darwin any }’ 
> get reinstalled during this process, and ‘port outdated’ shows ‘(platform 
> darwin 22 ≠ 23)’. Does MacPorts really need to reinstall these ports if 
> they’re marked as being suitable for any Darwin version?
> 
> Nils.



Re: Why some ports seem to install universal when I do not request it ?

2023-08-15 Thread Christopher Jones
Hi,

Thanks, eventually I figured that out for myself as well. I didn’t appreciate 
that if a port indicated it didn’t support arm, the x86_64 would be installed 
instead and used via rosetta etc. nice.

I  have though already found a number of ports I use indicate they only support 
x86_64 but this seems unnecessary as remove it they build fine for arm64, so 
can be removed.

cheers Chris

> On 15 Aug 2023, at 5:59 am, Joshua Root  wrote:
> 
> On 15/8/2023 05:06, Christopher Jones wrote:
>> Hi All,
>> Just migrated from an intel to AppleSilicon machine.
>> Reinstalling MacPOrts, from scratch off course, I’ve noticed some ports get 
>> install universal, when it’s not something I have requested. e.g.
>> --->  Fetching archive for zlib
>> --->  Attempting to fetch 
>> zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2 from 
>> https://packages.macports.org/zlib
>> --->  Attempting to fetch 
>> zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2.rmd160 from 
>> https://packages.macports.org/zlib
>> --->  Installing zlib @1.2.13_0+universal
>> --->  Cleaning zlib
>> --->  Deactivating zlib @1.2.13_0
>> --->  Cleaning zlib
>> --->  Activating zlib @1.2.13_0+universal
>> zlib has a universal port, but its not a default one, and I didn’t request 
>> it, nor have I ever set my default settings to always install universal.
>> As I am new to apple silicon machines, is this normal ?
> 
> Most likely you installed a port that supports x86_64 but not arm64. The 
> behaviour is the same as as when you install a port that only supports i386 
> on an x86_64 system.
> 
> - Josh



Why some ports seem to install universal when I do not request it ?

2023-08-14 Thread Christopher Jones
Hi All,

Just migrated from an intel to AppleSilicon machine.

Reinstalling MacPOrts, from scratch off course, I’ve noticed some ports get 
install universal, when it’s not something I have requested. e.g.

--->  Fetching archive for zlib
--->  Attempting to fetch zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2 
from https://packages.macports.org/zlib
--->  Attempting to fetch 
zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2.rmd160 from 
https://packages.macports.org/zlib
--->  Installing zlib @1.2.13_0+universal
--->  Cleaning zlib
--->  Deactivating zlib @1.2.13_0
--->  Cleaning zlib
--->  Activating zlib @1.2.13_0+universal

zlib has a universal port, but its not a default one, and I didn’t request it, 
nor have I ever set my default settings to always install universal.

As I am new to apple silicon machines, is this normal ?

cheers Chris

Re: The State of Rust in MacPorts Today

2022-12-13 Thread Christopher Jones
Hi,

> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev 
>  wrote:
> 
> David,
> 
> the idea is creating a dependency chain:
> 
> Port rust (version 1.66) depends on rust-1.65 to be build; 
> Port rust-1.65 depends on rust-1.64 to be build;
> Port rust-1.64 depends on rust-1.63 to be build;
> ...
> Port rust-1.56 depends on rust-1.55 to be build;
> Port rust-1.55 depends on rust-1.54 to be build;
> Port rust-1.54 depends on mrsutc to be build.
> 
> :)
> 
> When someone would like to add rust 1.67, he need to add port rust-1.66 which 
> should be used as bootstrap compiler.
> 
> I hate this way, but it is the only way to bootstrap it from scratch.

Clearly some thought has to be given to how to ensure the dependency tree does 
not get too long. We don’t want, when a new OS comes out for it to have to 
build tens of rust versions, just to ultimately bootstrap the last one. That 
might just be keeping the first bootstrap port, mrustc new enough at all times 
such that the list is kept manageable.

Chris


> 
> When mrust had support new rust, we may cut the tree by removing a lot of 
> unused ports.
> 
> 
> -- 
> wbr, Kirill
> 
>> On 13. Dec 2022, at 17:53, David Gilman > <mailto:davidgilm...@gmail.com>> wrote:
>> 
>> The work on mrustc is novel but I don't think it solves the issues we have 
>> here. On modern systems MacPorts uses bootstrap compilers provided by Rust 
>> upstream. MCL's bootstrap compilers are for older systems.
>> 
>> To update rust, my understanding is that you have to do the usual work of 
>> rebasing patches (my PR), but you also have to provide the binaries for 
>> older systems which I could not provide.
>> 
>> 
>> On Tue, Dec 13, 2022, 11:07 AM Kirill A. Korinsky via macports-dev 
>> mailto:macports-dev@lists.macports.org>> 
>> wrote:
>> Folks,
>> 
>> From the third hand we may build our own bootstrap chain of rust from 
>> scratch.
>> 
>> Or almost.
>> 
>> We have a https://ports.macports.org/port/mrustc/details/ 
>> <https://ports.macports.org/port/mrustc/details/> which is able to bootstrap 
>> 1.54 rust on x86_64 and arm64.
>> 
>> Unfortunately support of i386 isn't yet finished at upstream. I plan to fix 
>> it, but it requires time and availability of hardware to test it :)
>> 
>> I do have a commits which implements rust bootstrap by cahin: mrustc -> rust 
>> 1.54 -> rust 1.55 -> rust 1.56; I can start to open PRs to move step-by-step 
>> and in month we'll have the last rust via this chain. 
>> 
>> -- 
>> wbr, Kirill
>> 
>>> On 13. Dec 2022, at 16:49, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> Hi,
>>> 
>>> In my opinion, hosting and maintaining these ‘bootstrap’ compilers outside 
>>> the macports infrastructure was a poor choice, for all the reasons you 
>>> mention below. I thought this at the time it was done, and even more so now.
>>> 
>>> Personally, I would suggest you think about a change to how the rust 
>>> compiler is package, to mirror a bit how things are done with gcc and 
>>> clang. Namely, move to a model where the version is part of the port name, 
>>> e.g. the current one would be called something like rust-1.61.
>>> 
>>> The main reason for doing this, is adding a new version would that not 
>>> remove the previous version, and thus you could simple use it as the 
>>> bootstrap compiler. So with the above, when you add rust-1.62 that would 
>>> simple configure itself to bootstrap using the macports rust-1.61 port.
>>> 
>>> Yes, this will require some work to set up. You will need to make all the 
>>> various rust versions installable along side each other, so some tweaking 
>>> of the install prefix would be needed. 
>>> 
>>> One thing I would do differently though to how gcc/clang do things is I 
>>> would try and have a single rust port file, that implements all the 
>>> versions as sub-ports. I suspect most of what each needs can then just be 
>>> shared , such that what needs to be different for each sub-port is actually 
>>> not that much.
>>> 
>>> Regarding how users of rust then use these ports, there are a couple options
>>> 
>>> 1. Add a shim port ‘rust’ which simply installs sym-links etc. to the 
>>> ‘current best version’ that mimics the current installation, i.e. in the 
>>> main prefix. If done well, users should then be blind to the changes above.
>>> 2. Use

Re: The State of Rust in MacPorts Today

2022-12-13 Thread Christopher Jones
Hi,

In my opinion, hosting and maintaining these ‘bootstrap’ compilers outside the 
macports infrastructure was a poor choice, for all the reasons you mention 
below. I thought this at the time it was done, and even more so now.

Personally, I would suggest you think about a change to how the rust compiler 
is package, to mirror a bit how things are done with gcc and clang. Namely, 
move to a model where the version is part of the port name, e.g. the current 
one would be called something like rust-1.61.

The main reason for doing this, is adding a new version would that not remove 
the previous version, and thus you could simple use it as the bootstrap 
compiler. So with the above, when you add rust-1.62 that would simple configure 
itself to bootstrap using the macports rust-1.61 port.

Yes, this will require some work to set up. You will need to make all the 
various rust versions installable along side each other, so some tweaking of 
the install prefix would be needed. 

One thing I would do differently though to how gcc/clang do things is I would 
try and have a single rust port file, that implements all the versions as 
sub-ports. I suspect most of what each needs can then just be shared , such 
that what needs to be different for each sub-port is actually not that much.

Regarding how users of rust then use these ports, there are a couple options

1. Add a shim port ‘rust’ which simply installs sym-links etc. to the ‘current 
best version’ that mimics the current installation, i.e. in the main prefix. If 
done well, users should then be blind to the changes above.
2. Users that want an older rust could explicitly depend on and use a specific 
versioned rust-N

For me, this approach makes a lot more sense than the current way these 
bootstrap compilers are maintained.

cheers Chris


> On 13 Dec 2022, at 2:57 pm, Herby G  wrote:
> 
> Hello all,
> 
> Right now, Rust in MacPorts is severely out of date. It's about 5 versions 
> behind the current release, which at the moment is at 1.65.0. In comparison, 
> MacPorts Rust is currently at 1.61.0.
> 
> As a core language underlying a lot of other ports, many of these ports 
> cannot be updated to their latest versions because these versions require 
> current versions of Rust. At the time of this writing, 156 ports are being 
> built using Rust ( https://ports.macports.org/port/rust/details/ 
>  ), some quite heavily used by 
> the community, including projects like `git-delta`, `bat` and `fd`.
> 
> MarcusCalhoun-Lopez's PR here ( 
> https://github.com/macports/macports-ports/pull/14277 
>  ) heavily rewrote the 
> Rust port to run on older systems, and was very much celebrated and endorsed. 
> However, as a result of this PR, the Rust port became a lot more complicated, 
> and also introduced a new critical bootstrap compiler (referenced in the Rust 
> portgroup here: 
> https://github.com/macports/macports-ports/blob/2d39b30a32fcf0f5e1cff04f172e9d55ae08ba48/_resources/port1.0/group/rust-1.0.tcl#L140
>  
> ),
>  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
> https://github.com/MarcusCalhoun-Lopez/rust/releases 
>  ).  Marcus did try to 
> ask about a more official location to host the bootstrap compiler in a 
> macports-dev thread: 
> https://lists.macports.org/pipermail/macports-dev/2022-April/044243.html 
>  , 
> but ultimately per the  responses he decided to just host it in his personal 
> account himself.
> 
> Since this massive change to the Rust port at 1.60.0, it's only seen one 
> update since then to 1.61.0 ( 
> https://github.com/macports/macports-ports/commit/8431ccb48eec4824736eca51f643523356091cd6
>  
> 
>  )
> 
> David Gilman opened a PR recently attempting to update Rust to 1.64.0 ( 
> https://github.com/macports/macports-ports/pull/16329 
>  ), but Gilman doesn't 
> have access to update the bootstrap compiler, because as of right now, only 
> MarcusCalhoun-Lopez knows how to build it, and also it's hosted in Calhoun's 
> Github account as mentioned prior.
> 
> We need to figure out a more sustainable approach for this bootstrap 
> compiler, including how it can be built, and hosting it somewhere where a 
> small set of MacPorts maintainers can build and update it so that we can get 
> MacPorts Rust back on track.  As things are today, only MarcusCalhoun-Lopez 
> has all the pieces required to update this port, and there's been no word 
> from him for months now as the Rust port has fallen further and 

Re: MacPorts 2.8.0-beta1 now available for testing

2022-10-20 Thread Christopher Jones

No, thats not what I am saying. What you are doing works just fine for me…

My own checkout has

Oberon ~/Projects/MacPorts/ports > git remote -v
cjones  g...@github.com:cjones051073/macports-ports.git (fetch)
cjones  g...@github.com:cjones051073/macports-ports.git (push)
origin  g...@github.com:macports/macports-ports.git (fetch)
origin  g...@github.com:macports/macports-ports.git (push)

So I have set origin to be the main repo, and my own clone is the ‘clones’ 
remote.

running port sync (or port selfupdate for that matter) works fine (at least as 
far as the git pull part goes).

Oberon ~/Projects/MacPorts/ports > sudo port -d selfupdate
DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: MacPorts sources location: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
--->  Updating MacPorts base sources using rsync
DEBUG: system: /usr/bin/rsync -rtzvl --delete-after --include=/base.tar 
--include=/base.tar.rmd160 --exclude=* 
rsync://rsync.macports.org/macports/release/tarballs/ 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 66 bytes  received 98 bytes  109.33 bytes/sec
total size is 113716736  speedup is 693394.73
DEBUG: successful verification with key 
/opt/local/share/macports/macports-pubkey.pem
DEBUG: system: /usr/bin/tar -C 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/tmp
 -xf 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base.tar
MacPorts base version 2.8.0 installed,
DEBUG: Rebuilding and reinstalling MacPorts if needed
MacPorts base version 2.8.0 downloaded.
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/chris/Projects/MacPorts/ports
DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.3Ry328lG9D/Listeners
DEBUG: /opt/local/bin/git pull --rebase --autostash
DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git pull 
--rebase --autostash
Already up to date.

So the git pull works just fine. ( It hangs after this but thats a different 
issue. )

Why you are having problems I cannot say, but you should start by checking how 
you have the remotes setup for your checkout.

Chris

> On 20 Oct 2022, at 1:52 pm, Marius Schamschula  wrote:
> 
> Chris,
> 
> In other words, I shouldn’t ever run port selfupdate in my local repo (which 
> syncs to my personal GitHub repo), but rather in the 
> 
> /opt/local/var/macports/sources/github.com/macports/macports-ports 
> <http://github.com/macports/macports-ports>
> 
> directory. Make sense, but the update has always worked in the past.
> 
>> On Oct 20, 2022, at 7:26 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> The message
>> 
>> There is no tracking information for the current branch.
>> Please specify which branch you want to rebase against.
>> See git-pull(1) for details.
>> 
>> git pull  
>> 
>> If you wish to set tracking information for this branch you can do so with:
>> 
>> git branch --set-upstream-to=origin/ master
>> 
>> Indicates you have 
>> 
>> /Users/marius/Development/MacPorts/ports 
>> 
>> 
>> switched to a branch that does not have its tracking information set. This 
>> normally happens if you have a feature branch (e.g. for a PR) checked out, 
>> but the above is for master which is a bit weird.
>> 
>> running
>> 
>> git branch --set-upstream-to=origin/master master
>> 
>> might fix this, but again, it is a bit odd you need to do this for your 
>> master checkout, unless you have done something ‘odd’ to it such that it has 
>> lost its tracking info.
>> 
>> Chris
>> 
>>> On 20 Oct 2022, at 12:17 pm, Marius Schamschula >> <mailto:li...@schamschula.com>> wrote:
>>> 
>>> I’m seeing something very similar with MacPorts 2.8.0 (release)
>>> 
>>> marius@Mira ports % sudo port selfupdate 
>>> --->  Updating MacPorts base sources using rsync
>>> MacPorts base version 2.7.2 installed,
>>> MacPorts base version 2.8.0 downloaded.
>>> --->  Updating the ports tree
>>> --->  MacPorts base is outdated, installing new version 2.8.0
>>> Installing new MacPorts release in /opt/local as root:wheel; permissions 
>>> 0755
>>> 
>>> Error: Couldn't change permissions of th

Re: MacPorts 2.8.0-beta1 now available for testing

2022-10-20 Thread Christopher Jones
 release_1_5_0-archive
>  * [new tag] release_1_6_0-archive  -> 
> release_1_6_0-archive
>  * [new tag] release_1_7_0-archive  -> 
> release_1_7_0-archive
>  * [new tag] release_1_8_0-archive  -> 
> release_1_8_0-archive
>  * [new tag] release_1_9_0-archive  -> 
> release_1_9_0-archive
>  * [new tag] release_2_0_0-archive  -> 
> release_2_0_0-archive
>  * [new tag] release_2_1_0-archive  -> 
> release_2_1_0-archive
>  * [new tag] release_2_2_0-archive  -> 
> release_2_2_0-archive
>  * [new tag] release_2_3_0-archive  -> 
> release_2_3_0-archive
>  * [new tag] v2.4.0-archive -> v2.4.0-archive
>  * [new tag] v2.5.0-archive -> v2.5.0-archive
>  * [new tag] v2.6.0-archive -> v2.6.0-archive
>  * [new tag] v2.7.0-archive -> v2.7.0-archive
>  * [new tag] v2.8.0-archive -> v2.8.0-archive
> There is no tracking information for the current branch.
> Please specify which branch you want to rebase against.
> See git-pull(1) for details.
> 
> git pull  
> 
> If you wish to set tracking information for this branch you can do so with:
> 
> git branch --set-upstream-to=origin/ master
> 
> Command failed: /opt/local/bin/git pull --rebase --autostash
> Exit code: 1
> Syncing local Git ports tree failed
> Error: Couldn't sync the ports tree: Synchronization of 2 sources failed
> Error: Follow https://guide.macports.org/#project.tickets 
> <https://guide.macports.org/#project.tickets> if you believe there is a bug.
> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
> tree: Synchronization of 2 sources failed
> marius@Mira ports % port version
> Version: 2.8.0
> marius@Mira ports % 
> 
>> On Oct 20, 2022, at 4:49 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Hi,
>> 
>> I’m afraid I have no idea how to go about setting up a reproducer for this. 
>> It seems it randomly comes and goes, so perhaps is related to something else 
>> going on in the system (I am on macOS12 intel b.t.w.).
>> 
>> The best I can do is monitor it and see if I can spot any pattern as to when 
>> it happens or not. I am now on the official 2.8.0 release and still see it 
>> happen, so lets also see if any others start to see the same or not.
>> 
>> Chris
>> 
>>> On 19 Oct 2022, at 2:07 am, Joshua Root >> <mailto:j...@macports.org>> wrote:
>>> 
>>> I can't repro this. The VCS sync logic hasn't changed since the privilege 
>>> dropping fix in April. The only thing I can think of that might have made a 
>>> difference is the update to Tcl 8.6 and the associated update of all the 
>>> try/catch blocks.
>>> 
>>> All that should be happening between running git and running portindex is 
>>> the environment restore in VCSCleanup. You might have to do some more 
>>> digging to figure out a repro recipe I'm afraid.
>>> 
>>> - Josh
>>> 
>>> On 2022-10-18 20:09 , Christopher Jones wrote:
>>>> Hi,
>>>> I’m not running the beta but the current master branch of base, but I 
>>>> guess its similar.
>>>> I’m noticing with the latest version  `sudo port sync` just hangs up after 
>>>> updating my local git clone. e.g.
>>>> Oberon ~/Projects/MacPorts/ports > sudo port -d sync
>>>> DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist 
>>>> to /opt/local/var/macports/home/Library/Preferences
>>>> --->  Updating the ports tree
>>>> Synchronizing local ports tree from 
>>>> file:///Users/chris/Projects/MacPorts/ports 
>>>> 
>>>> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
>>>> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.vx1uKV7YtR/Listeners
>>>> DEBUG: /opt/local/bin/git pull --rebase --autostash
>>>> DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git 
>>>> pull --rebase --autostash
>>>> Already up to date.
>>>> and thats it, it never gets any further and just hangs up there.
>>>> If I contrl-c the process I can get it to continue.
>>>> ^CDEBUG: euid/egid restored to: 0/0, env restored
>>>> DEBUG: system: /opt/local/bin/portindex 
>>>> /Users/chris/Projects/MacPorts/ports
>>>> Creating port index in /Users/chris/Projects/MacPorts/ports
>>>> Total number of ports parsed:  0
>>>> Ports successfully parsed: 0
>>>> Ports failed:  0
>>>> Up-to-date ports skipped:  29934
>>>> any ideas what step its hanging up on ?
>>>> Chris
>>>>> On 14 Oct 2022, at 12:57 am, Joshua Root >>>> <mailto:j...@macports.org>> wrote:
>>>>> 
>>>>> Well, only one issue has been reported against the beta so far (the NULL 
>>>>> cxx_stdlib error that Ken saw.) I guess I'll tag an RC soon.
>>>>> 
>>>>> - Josh
>>> 
>> 
> 



Re: MacPorts 2.8.0-beta1 now available for testing

2022-10-20 Thread Christopher Jones
e_1_3_1-archive
>  * [new tag] release_1_3_2-archive  -> 
> release_1_3_2-archive
>  * [new tag] release_1_4_0-archive  -> 
> release_1_4_0-archive
>  * [new tag] release_1_5_0-archive  -> 
> release_1_5_0-archive
>  * [new tag] release_1_6_0-archive  -> 
> release_1_6_0-archive
>  * [new tag] release_1_7_0-archive  -> 
> release_1_7_0-archive
>  * [new tag] release_1_8_0-archive  -> 
> release_1_8_0-archive
>  * [new tag] release_1_9_0-archive  -> 
> release_1_9_0-archive
>  * [new tag] release_2_0_0-archive  -> 
> release_2_0_0-archive
>  * [new tag] release_2_1_0-archive  -> 
> release_2_1_0-archive
>  * [new tag] release_2_2_0-archive  -> 
> release_2_2_0-archive
>  * [new tag] release_2_3_0-archive  -> 
> release_2_3_0-archive
>  * [new tag] v2.4.0-archive -> v2.4.0-archive
>  * [new tag] v2.5.0-archive -> v2.5.0-archive
>  * [new tag] v2.6.0-archive -> v2.6.0-archive
>  * [new tag] v2.7.0-archive -> v2.7.0-archive
>  * [new tag] v2.8.0-archive -> v2.8.0-archive
> There is no tracking information for the current branch.
> Please specify which branch you want to rebase against.
> See git-pull(1) for details.
> 
> git pull  
> 
> If you wish to set tracking information for this branch you can do so with:
> 
> git branch --set-upstream-to=origin/ master
> 
> Command failed: /opt/local/bin/git pull --rebase --autostash
> Exit code: 1
> Syncing local Git ports tree failed
> Error: Couldn't sync the ports tree: Synchronization of 2 sources failed
> Error: Follow https://guide.macports.org/#project.tickets 
> <https://guide.macports.org/#project.tickets> if you believe there is a bug.
> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
> tree: Synchronization of 2 sources failed
> marius@Mira ports % port version
> Version: 2.8.0
> marius@Mira ports % 
> 
>> On Oct 20, 2022, at 4:49 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Hi,
>> 
>> I’m afraid I have no idea how to go about setting up a reproducer for this. 
>> It seems it randomly comes and goes, so perhaps is related to something else 
>> going on in the system (I am on macOS12 intel b.t.w.).
>> 
>> The best I can do is monitor it and see if I can spot any pattern as to when 
>> it happens or not. I am now on the official 2.8.0 release and still see it 
>> happen, so lets also see if any others start to see the same or not.
>> 
>> Chris
>> 
>>> On 19 Oct 2022, at 2:07 am, Joshua Root >> <mailto:j...@macports.org>> wrote:
>>> 
>>> I can't repro this. The VCS sync logic hasn't changed since the privilege 
>>> dropping fix in April. The only thing I can think of that might have made a 
>>> difference is the update to Tcl 8.6 and the associated update of all the 
>>> try/catch blocks.
>>> 
>>> All that should be happening between running git and running portindex is 
>>> the environment restore in VCSCleanup. You might have to do some more 
>>> digging to figure out a repro recipe I'm afraid.
>>> 
>>> - Josh
>>> 
>>> On 2022-10-18 20:09 , Christopher Jones wrote:
>>>> Hi,
>>>> I’m not running the beta but the current master branch of base, but I 
>>>> guess its similar.
>>>> I’m noticing with the latest version  `sudo port sync` just hangs up after 
>>>> updating my local git clone. e.g.
>>>> Oberon ~/Projects/MacPorts/ports > sudo port -d sync
>>>> DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist 
>>>> to /opt/local/var/macports/home/Library/Preferences
>>>> --->  Updating the ports tree
>>>> Synchronizing local ports tree from 
>>>> file:///Users/chris/Projects/MacPorts/ports 
>>>> 
>>>> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
>>>> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.vx1uKV7YtR/Listeners
>>>> DEBUG: /opt/local/bin/git pull --rebase --autostash
>>>> DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git 
>>>> pull --rebase --autostash
>>>> Already up to date.
>>>> and thats it, it never gets any further and just hangs up there.
>>>> If I contrl-c the process I can get it to continue.
>>>> ^CDEBUG: euid/egid restored to: 0/0, env restored
>>>> DEBUG: system: /opt/local/bin/portindex 
>>>> /Users/chris/Projects/MacPorts/ports
>>>> Creating port index in /Users/chris/Projects/MacPorts/ports
>>>> Total number of ports parsed:  0
>>>> Ports successfully parsed: 0
>>>> Ports failed:  0
>>>> Up-to-date ports skipped:  29934
>>>> any ideas what step its hanging up on ?
>>>> Chris
>>>>> On 14 Oct 2022, at 12:57 am, Joshua Root >>>> <mailto:j...@macports.org>> wrote:
>>>>> 
>>>>> Well, only one issue has been reported against the beta so far (the NULL 
>>>>> cxx_stdlib error that Ken saw.) I guess I'll tag an RC soon.
>>>>> 
>>>>> - Josh
>>> 
>> 
> 



Re: MacPorts 2.8.0-beta1 now available for testing

2022-10-20 Thread Christopher Jones
Hi,

I’m afraid I have no idea how to go about setting up a reproducer for this. It 
seems it randomly comes and goes, so perhaps is related to something else going 
on in the system (I am on macOS12 intel b.t.w.).

The best I can do is monitor it and see if I can spot any pattern as to when it 
happens or not. I am now on the official 2.8.0 release and still see it happen, 
so lets also see if any others start to see the same or not.

Chris

> On 19 Oct 2022, at 2:07 am, Joshua Root  wrote:
> 
> I can't repro this. The VCS sync logic hasn't changed since the privilege 
> dropping fix in April. The only thing I can think of that might have made a 
> difference is the update to Tcl 8.6 and the associated update of all the 
> try/catch blocks.
> 
> All that should be happening between running git and running portindex is the 
> environment restore in VCSCleanup. You might have to do some more digging to 
> figure out a repro recipe I'm afraid.
> 
> - Josh
> 
> On 2022-10-18 20:09 , Christopher Jones wrote:
>> Hi,
>> I’m not running the beta but the current master branch of base, but I guess 
>> its similar.
>> I’m noticing with the latest version  `sudo port sync` just hangs up after 
>> updating my local git clone. e.g.
>> Oberon ~/Projects/MacPorts/ports > sudo port -d sync
>> DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> --->  Updating the ports tree
>> Synchronizing local ports tree from 
>> file:///Users/chris/Projects/MacPorts/ports
>> DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
>> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.vx1uKV7YtR/Listeners
>> DEBUG: /opt/local/bin/git pull --rebase --autostash
>> DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git 
>> pull --rebase --autostash
>> Already up to date.
>> and thats it, it never gets any further and just hangs up there.
>> If I contrl-c the process I can get it to continue.
>> ^CDEBUG: euid/egid restored to: 0/0, env restored
>> DEBUG: system: /opt/local/bin/portindex /Users/chris/Projects/MacPorts/ports
>> Creating port index in /Users/chris/Projects/MacPorts/ports
>> Total number of ports parsed:0
>> Ports successfully parsed:   0
>> Ports failed:0
>> Up-to-date ports skipped:29934
>> any ideas what step its hanging up on ?
>> Chris
>>> On 14 Oct 2022, at 12:57 am, Joshua Root  wrote:
>>> 
>>> Well, only one issue has been reported against the beta so far (the NULL 
>>> cxx_stdlib error that Ken saw.) I guess I'll tag an RC soon.
>>> 
>>> - Josh
> 



Re: MacPorts 2.8.0-beta1 now available for testing

2022-10-18 Thread Christopher Jones
Hi,

I’m not running the beta but the current master branch of base, but I guess its 
similar.

I’m noticing with the latest version  `sudo port sync` just hangs up after 
updating my local git clone. e.g.

Oberon ~/Projects/MacPorts/ports > sudo port -d sync
DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/chris/Projects/MacPorts/ports
DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.vx1uKV7YtR/Listeners
DEBUG: /opt/local/bin/git pull --rebase --autostash
DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git pull 
--rebase --autostash
Already up to date.


and thats it, it never gets any further and just hangs up there.

If I contrl-c the process I can get it to continue.

^CDEBUG: euid/egid restored to: 0/0, env restored
DEBUG: system: /opt/local/bin/portindex /Users/chris/Projects/MacPorts/ports
Creating port index in /Users/chris/Projects/MacPorts/ports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   29934

any ideas what step its hanging up on ?

Chris


> On 14 Oct 2022, at 12:57 am, Joshua Root  wrote:
> 
> Well, only one issue has been reported against the beta so far (the NULL 
> cxx_stdlib error that Ken saw.) I guess I'll tag an RC soon.
> 
> - Josh



Re: ports.macports.org gives strange port dependencies

2022-09-25 Thread Christopher Jones


> On 24 Sep 2022, at 3:52 pm, Arjun Salyan  wrote:
> 
> The output of "port info pciids” from the same Docker container says:

Can you please run

> port -d info pciids 

pipe the output to file and send it here ? I want to see if we can figure out 
what is leading port to decide to add these deps.

If you can do this also for the macosx_19_i386 port index as well that would be 
useful.

Chris

> Build Dependencies:   clang-3.4
> 
> And the PortIndex on the same machine (generated using “-p macosx_19_i386”) 
> has:
> 
> depends_build port:clang-15
> 
> 
> The MacPorts docker image used is 
> https://github.com/arjunsalyan/macports-ubuntu 
>  (Docker hub:  
> https://hub.docker.com/r/arjunsalyan/macports-ubuntu 
>  )
> 
>> On 24-Sep-2022, at 3:10 PM, Chris Jones > > wrote:
>> 
>> 
>> 
>>> On 24 Sep 2022, at 9:52 am, Mojca Miklavec >> > wrote:
>>> 
>>> On Sat, 24 Sept 2022 at 10:30, Chris Jones wrote:
 
 Hi,
 
 I have noticed the ports web site appears to give some odd looking 
 dependencies between ports. Take as a random example
 
 https://ports.macports.org/port/pciids/details/ 
 
 
 clang-15 is listed as a build dep. if you check the port file though I see 
 no reason for this at all, in fact the port does not build anything and 
 just installs a single file during destroot. So why does the site give the 
 build dep it does ? Just running
 
 port info pciids
 
 On macOS12 does not give any deps, as expected.
 
 I guess a probably related question is what OS is used to generate the 
 deps, as these do vary across OSes, particularly build deps, and this is 
 something the site does not take into account.
>>> 
>>> The list is generated inside a Docker container (that is: on Linux),
>>> apparently with "-p macosx_19_i386":
>>> 
>>> https://github.com/macports/macports-webapp/blob/22e548bd3dd05860f53e1d16899b1e8364c69796/app/parsing_scripts/git_update.py#L59
>>>  
>>> 
>> 
>> Ah, it runs on linux..
>> 
>> subprocess.run(['portindex', '-p', 'macosx_19_i386', '-x'])
>> 
>> Do I understand the above correctly in that it is supposed to mimic a Darwin 
>> 19 machine ?
>> 
>> I think my question still remains, regardless of the arch why is clang-x 
>> being listed as a build dep, for a port that doesn’t need it ?
>> 
>> Chris
>>> 
>>> Mojca
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: ports.macports.org gives strange port dependencies

2022-09-25 Thread Christopher Jones


> On 24 Sep 2022, at 4:00 pm, Christopher Jones  
> wrote:
> 
> 
> 
>> On 24 Sep 2022, at 3:52 pm, Arjun Salyan > <mailto:ar...@macports.org>> wrote:
>> 
>> The output of "port info pciids” from the same Docker container says:
>> 
>> Build Dependencies:   clang-3.4
>> 
>> And the PortIndex on the same machine (generated using “-p macosx_19_i386”) 
>> has:
>> 
>> depends_build port:clang-15
> 
> 
> right, but these are fake dependencies as per what you get on a real MacOS 
> system. i.e. on macOS12 (but it will be the same on others)

small correction. I actually ran this on a 10.9 VM, not macOS12. Point remains 
the same though…

> 
> 
> MacVM109 ~ > port info pciids
> pciids @2022.09.09 (sysutils)
> 
> Description:  This repository contains the history of the pci.ids 
> file, which is automatically generated from the PCI ID Database at 
> https://pci-ids.ucw.cz <https://pci-ids.ucw.cz/>.
> Homepage: https://pci-ids.ucw.cz <https://pci-ids.ucw.cz/>
> 
> Platforms:darwin
> License:  (GPL-2+ or BSD)
> Maintainers:  Email: i0ntemp...@macports.org 
> <mailto:i0ntemp...@macports.org>, GitHub: i0ntempest
>   Policy: openmaintainer
> 
> So no build deps.
> 
> So I go back to my original question. Why are these reps appearing when 
> running this on linux.
> 
> The problem is its giving incorrect information on the web site w.r.t. what 
> is actually needed on macOS.
> 
> Chris
> 
>> 
>> 
>> The MacPorts docker image used is 
>> https://github.com/arjunsalyan/macports-ubuntu 
>> <https://github.com/arjunsalyan/macports-ubuntu> (Docker hub:  
>> https://hub.docker.com/r/arjunsalyan/macports-ubuntu 
>> <https://hub.docker.com/r/arjunsalyan/macports-ubuntu> )
>> 
>>> On 24-Sep-2022, at 3:10 PM, Chris Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> 
>>>> On 24 Sep 2022, at 9:52 am, Mojca Miklavec >>> <mailto:mojca.miklavec.li...@gmail.com>> wrote:
>>>> 
>>>> On Sat, 24 Sept 2022 at 10:30, Chris Jones wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I have noticed the ports web site appears to give some odd looking 
>>>>> dependencies between ports. Take as a random example
>>>>> 
>>>>> https://ports.macports.org/port/pciids/details/ 
>>>>> <https://ports.macports.org/port/pciids/details/>
>>>>> 
>>>>> clang-15 is listed as a build dep. if you check the port file though I 
>>>>> see no reason for this at all, in fact the port does not build anything 
>>>>> and just installs a single file during destroot. So why does the site 
>>>>> give the build dep it does ? Just running
>>>>> 
>>>>> port info pciids
>>>>> 
>>>>> On macOS12 does not give any deps, as expected.
>>>>> 
>>>>> I guess a probably related question is what OS is used to generate the 
>>>>> deps, as these do vary across OSes, particularly build deps, and this is 
>>>>> something the site does not take into account.
>>>> 
>>>> The list is generated inside a Docker container (that is: on Linux),
>>>> apparently with "-p macosx_19_i386":
>>>> 
>>>> https://github.com/macports/macports-webapp/blob/22e548bd3dd05860f53e1d16899b1e8364c69796/app/parsing_scripts/git_update.py#L59
>>>>  
>>>> <https://github.com/macports/macports-webapp/blob/22e548bd3dd05860f53e1d16899b1e8364c69796/app/parsing_scripts/git_update.py#L59>
>>> 
>>> Ah, it runs on linux..
>>> 
>>> subprocess.run(['portindex', '-p', 'macosx_19_i386', '-x'])
>>> 
>>> Do I understand the above correctly in that it is supposed to mimic a 
>>> Darwin 19 machine ?
>>> 
>>> I think my question still remains, regardless of the arch why is clang-x 
>>> being listed as a build dep, for a port that doesn’t need it ?
>>> 
>>> Chris
>>>> 
>>>> Mojca
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: ports.macports.org gives strange port dependencies

2022-09-25 Thread Christopher Jones


> On 24 Sep 2022, at 3:52 pm, Arjun Salyan  wrote:
> 
> The output of "port info pciids” from the same Docker container says:
> 
> Build Dependencies:   clang-3.4
> 
> And the PortIndex on the same machine (generated using “-p macosx_19_i386”) 
> has:
> 
> depends_build port:clang-15


right, but these are fake dependencies as per what you get on a real MacOS 
system. i.e. on macOS12 (but it will be the same on others)


MacVM109 ~ > port info pciids
pciids @2022.09.09 (sysutils)

Description:  This repository contains the history of the pci.ids file, 
which is automatically generated from the PCI ID Database at 
https://pci-ids.ucw.cz.
Homepage: https://pci-ids.ucw.cz

Platforms:darwin
License:  (GPL-2+ or BSD)
Maintainers:  Email: i0ntemp...@macports.org, GitHub: i0ntempest
  Policy: openmaintainer

So no build deps.

So I go back to my original question. Why are these reps appearing when running 
this on linux.

The problem is its giving incorrect information on the web site w.r.t. what is 
actually needed on macOS.

Chris

> 
> 
> The MacPorts docker image used is 
> https://github.com/arjunsalyan/macports-ubuntu 
>  (Docker hub:  
> https://hub.docker.com/r/arjunsalyan/macports-ubuntu 
>  )
> 
>> On 24-Sep-2022, at 3:10 PM, Chris Jones > > wrote:
>> 
>> 
>> 
>>> On 24 Sep 2022, at 9:52 am, Mojca Miklavec >> > wrote:
>>> 
>>> On Sat, 24 Sept 2022 at 10:30, Chris Jones wrote:
 
 Hi,
 
 I have noticed the ports web site appears to give some odd looking 
 dependencies between ports. Take as a random example
 
 https://ports.macports.org/port/pciids/details/ 
 
 
 clang-15 is listed as a build dep. if you check the port file though I see 
 no reason for this at all, in fact the port does not build anything and 
 just installs a single file during destroot. So why does the site give the 
 build dep it does ? Just running
 
 port info pciids
 
 On macOS12 does not give any deps, as expected.
 
 I guess a probably related question is what OS is used to generate the 
 deps, as these do vary across OSes, particularly build deps, and this is 
 something the site does not take into account.
>>> 
>>> The list is generated inside a Docker container (that is: on Linux),
>>> apparently with "-p macosx_19_i386":
>>> 
>>> https://github.com/macports/macports-webapp/blob/22e548bd3dd05860f53e1d16899b1e8364c69796/app/parsing_scripts/git_update.py#L59
>>>  
>>> 
>> 
>> Ah, it runs on linux..
>> 
>> subprocess.run(['portindex', '-p', 'macosx_19_i386', '-x'])
>> 
>> Do I understand the above correctly in that it is supposed to mimic a Darwin 
>> 19 machine ?
>> 
>> I think my question still remains, regardless of the arch why is clang-x 
>> being listed as a build dep, for a port that doesn’t need it ?
>> 
>> Chris
>>> 
>>> Mojca
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: CalculiX build error using clang

2022-07-26 Thread Christopher Jones

clang is correct in this case, gcc is being sloppy. 

Basically you cannot return a value, from a function declared as void… fairly 
basic stuff really..

> On 26 Jul 2022, at 5:34 pm, Mark Brethen  wrote:
> 
> I’m seeing this build error when using clang (gcc doesn’t complain):
> 
> info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ 
> -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
> -I../../glut-3.5/src-c -o pickFunktions.o pickFunktions.c
> :info:build pickFunktions.c:4599:7: error: void function 'moveLineEndPoint' 
> should not return a value [-Wreturn-type]
> :info:build   return(-1);
> :info:build   ^ 
> 
> code snippet below:
> 
>  void moveLineEndPoint(int lineNr, int pntNr, double llength)
> {
>   int p1,p2, flag=0;
>   double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];
> 
> p1=line[lineNr].p1;
> p2=line[lineNr].p2;
> 
> /* determine which side of the line has to be moved */
> if(pntNr==p1) flag=-1;
> else if(pntNr==p2) flag=1;
> else
> {
>   printf("ERROR: selected point:%s is no line endpoint\n", 
> point[pntNr].name);
>   return(-1);
> }
> u=flag*llength;
> u/=scale->w;
> 
> /* calc direction */
> if(line[lineNr].typ=='s')
> {
>   if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
>   else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
> }
> P1[0]=point[p1].px;
> P1[1]=point[p1].py;
> P1[2]=point[p1].pz;
> P2[0]=point[p2].px;
> P2[1]=point[p2].py;
> P2[2]=point[p2].pz;
> v_result( P1, P2, p0p1_2);
> v_norm(p0p1_2,eva);
> v_scal(,eva, va);
> point[pntNr].px+=va[0];
> point[pntNr].py+=va[1];
> point[pntNr].pz+=va[2];
> printf("moved by dxyz= %lf %lf %lf\n",
>   (va[0]* scale->w),
>   (va[1]* scale->w),
>   (va[2]* scale->w));
> }
> 
> I do not code in C, so I’ll pass this up to the developer. How should this be 
> patched?
> 
> Thanks,
> Mark
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: fetch timeout

2022-07-20 Thread Christopher Jones


> On 20 Jul 2022, at 6:32 pm, Dave Allured - NOAA Affiliate via macports-dev 
>  wrote:
> 
> On Wed, Jul 20, 2022 at 2:30 AM Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> On 20 Jul 2022, at 1:13 am, Dave Allured - NOAA Affiliate via macports-dev 
>> mailto:macports-dev@lists.macports.org>> 
>> wrote:
>> 
>> Hmmm.  If port curl is already installed and active, then why would 
>> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
> 
> No. port does not rely on finding ‘curl’, from PATH. It instead uses the 
> system lib curl which it is liked against. The only way to get port to use a 
> different curl is to rebuild base, configured to use that version.
> 
> Ah, that is what I missed.  How about adding a fallback option to use an 
> alternate command line curl through PATH, when available, after normal fetch 
> attempts have failed?  My hope is that this would ultimately reduce time 
> spent on debugging connection and SSL issues.

Please read the discussion at

https://trac.macports.org/ticket/51516 <https://trac.macports.org/ticket/51516>

and add any comments you might have. 

In short, adding a ‘fallback to curl’ is very non trivial to do, perhaps not 
even possible.

smime.p7s
Description: S/MIME cryptographic signature


Re: fetch timeout

2022-07-20 Thread Christopher Jones


> On 20 Jul 2022, at 1:13 am, Dave Allured - NOAA Affiliate via macports-dev 
>  wrote:
> 
> Hmmm.  If port curl is already installed and active, then why would 
> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?

No. port does not rely on finding ‘curl’, from PATH. It instead uses the system 
lib curl which it is liked against. The only way to get port to use a different 
curl is to rebuild base, configured to use that version.

> 
> 
> On Tue, Jul 19, 2022 at 6:00 PM Mark Brethen  > wrote:
> tetgen has dependency on cmake which depends on curl. If it's possible to 
> check the machine and os version, could override fetch under those specific 
> cases.
> 
> I’ll also contact the host, but I suspect it’s a bug in openssl:
> 
> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>  alert number 40
> 
> Mark Brethen
> mark.bret...@gmail.com 
> 
>> On Jul 19, 2022, at 6:00 PM, Dave Allured - NOAA Affiliate via macports-dev 
>> mailto:macports-dev@lists.macports.org>> 
>> wrote:
>> 
>> Several of us have now reproduced the SSL problem.  I see two things in 
>> common:
>> (1)  Older curl/SSL versions bundled into older MacOS versions, such as 
>> Catalina.
>> (2)  The target website, wias-berlin.de .
>> 
>> I suspect wias-berlin.de  is misconfigured somehow.  
>> Mark, consider showing this problem to them, and ask them to check their 
>> server configuration.  It is reasonable to expect Catalina Macs to be able 
>> to download their files using the system curl.  I can certainly download 
>> from many other websites.
>> 
>> Another possibility is to go back to one of Mark's earlier ideas.  Get 
>> Macports to use the MP version of curl.  I don't know how to do this.  What 
>> happens if you simply install and activate port curl, before install tetgen 
>> (Mark's new port)?
>> 
>> 
>> On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen > > wrote:
>> Big Sur installs the same version curl/openssl and it does not work on 
>> intel. It does work on an M1, which is surprising.
>> 
>> ~ $ /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> ~ $ 
>> 
>> I noticed nghttp2 @1.41.0 vs 1.39.2.
>> 
>> Mark Brethen
>> mark.bret...@gmail.com 
>> 
>>> On Jul 19, 2022, at 12:07 PM, Gary Palter >> > wrote:
>>> 
>>> Apparently not.
 Last login: Tue Jul 19 12:56:44 on console
 palter@Catalina ~ % /usr/bin/curl --version
 curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) 
 LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
 Release-Date: 2019-03-27
 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
 pop3s rtsp smb smbs smtp smtps telnet tftp 
 Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
 MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
 palter@Catalina ~ % cd Downloads 
 palter@Catalina Downloads % /usr/bin/curl -O 
 https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
 
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  
 Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--   
   0
 curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
 handshake failure
 palter@Catalina Downloads % 
>>> The above is a vanilla install of Intel Catalina running in a VM.
>>> 
>>>   - Gary
>>> 
 On Jul 19, 2022, at 12:55 PM, Mark Brethen >>> > wrote:
 
 Anyone else confirm system curl works with this host on intel mac with 
 catalina or big sur?
 
 Mark
 
> On Jul 19, 2022, at 11:49 AM, Mark Brethen  > wrote:
> 
> Yes, I have mp curl as well. Unfortunately, port uses Apple’s 
> curl/openssl. Only work around is to override fetch and use mp.
> 
> Mark Brethen
> mark.bret...@gmail.com 
> 
>> On Jul 19, 2022, at 11:42 AM, Nils Breunese > > wrote:
>> 
>> Mark Brethen mailto:mark.bret...@gmail.com>> 
>> wrote:
>> 
>>> What 

Re: fetch timeout

2022-07-18 Thread Christopher Jones


> On 17 Jul 2022, at 7:12 pm, Mark Brethen  wrote:
> 
> It’s interesting that curl fails from my older MacBook Air, but passes on the 
> M1 iMac, both with OS 11 installed. Even after a clean reinstall. I suspect 
> it’s something about Apple’s openssl. Browsers don’t seem to mind the 
> certificate.

No, I very much doubt that is the case. If it where the case if would fail for 
you on both machines.

> 
> As a work around, I’d like to add something like this:
> 
> set check.os.major 21
> if {${check.os.major} > ${os.major}} {
> depends_fetch-append curl
> fetch {
> system "curl -L -o ${distpath}/${distfiles} 
> ${master_sites}${distfiles}"
> }
> }

It is not appropriate to add that to a port file when the origin of the issue 
is still not understood, and quite likely something specific to your setup.

Chris

> 
> 
> 
> Mark Brethen
> mark.bret...@gmail.com 
> 
> 
> 
>> On Jul 17, 2022, at 8:49 AM, Mark Brethen > > wrote:
>> 
>> I think I’m getting to the root of the problem. I tried to obtain the SSL 
>> certificate from the host server using openssl.
>> 
>> Downloads $ echo | openssl s_client -servername wias-berlin.de 
>>  -connect wias-berlin.de:443 
>>  |\  
>>   
>>   sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certificate.crt
>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
>> Center, CN = T-TeleSec GlobalRoot Class 2
>> verify return:1
>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>> verify return:1
>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>> verify return:1
>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>> RT, CN = www.wias-berlin.de 
>> verify return:1
>> 4479426220:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>> handshake 
>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>>  alert number 40
>> 4479426220:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
>> 
>> 
>> I don’t get this error on the iMac with the same OS, same openssl versions.
>> 
>> Mark
>> 
>> 
>> 
>>> On Jul 15, 2022, at 1:44 PM, Mark Brethen >> > wrote:
>>> 
>>> Maybe it’s openssl in /opt/local/bin? On the MacBook Air:
>>> 
>>> ports $ which openssl
>>> /opt/local/bin/openssl
>>> ports $ openssl version
>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>>> 
>>> The iMac has /opt/local/bin/openssl 1.1.1
>>> 
>>> /usr/bin/openssl is libressl 2.8.3 for both.
>>> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com 
>>> 
>>> 
>>> 
 On Jul 15, 2022, at 1:32 PM, Mark Brethen >>> > wrote:
 
 Heck if I know what’s wrong. Everything being equal, curl on the iMac 
 works, but on the MacBook Air it does not. Both have the same OS, same 
 curl version at /usr/bin, same cert.pem.
 
 
 Mark Brethen
 mark.bret...@gmail.com 
 
 
 
> On Jul 15, 2022, at 11:42 AM, Mark Brethen  > wrote:
> 
> On the MacBook Air openssl is able to get the certificate
> 
> Downloads $ openssl s_client -connect wias-berlin.de:443 
> 
> CONNECTED(0005)
> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
> Trust Center, CN = T-TeleSec GlobalRoot Class 2
> verify return:1
> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen 
> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification 
> Authority 2
> verify return:1
> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen 
> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> verify return:1
> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin 
> e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik 
> (WIAS), OU = RT, CN = www.wias-berlin.de 
> verify return:1
> ---
> Certificate chain
>  0 s:C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU 
> = RT, CN = www.wias-berlin.de 

Re: +universal for x864+arm64 on Macintel

2022-06-15 Thread Christopher Jones



> On 15 Jun 2022, at 3:25 pm, René J.V. Bertin  wrote:
>
>
>> Base is exactly smart enough. When supported_archs contains only 1 arch, it 
>> does make sense to offer a universal variant, therefore base prevents it.
>
> As I said before, supported_archs contains x86_64 and arm64.

what about configure.universal_archs though, have you set that to have > 1 
entry ? thats what base cares about, hence the "due to < 2 supported 
universal_archs

>
> If ports should be able to create a universal variant in case that variant 
> isn't created automatically, "base" should be polite enough to assume that 
> the port maintainers know and have a reason for what they're doing.



smime.p7s
Description: S/MIME cryptographic signature


latest git version no longer detected by base

2022-04-14 Thread Christopher Jones
Hi All,

Does anyone have any ideas on

https://github.com/macports/macports-ports/commit/053dbb666a57972ceefba10b1edd12f16d886fd4#commitcomment-71271508
 



something about the latest git port is causing it to no longer to properly 
detected and used by base..

cheers Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: /usr/bin/python will be removed in macOS 12.3!

2022-02-19 Thread Christopher Jones



> On 19 Feb 2022, at 5:06 pm, Gerben Wierda  wrote:
>
> Well, yes, I kind of knew already that it was a terrible idea. Kind of felt 
> terrible in the first place (was just checking).
>
> But how does one (a) find out the dependency exists and (b) make sure the 
> software finds python from MacPorts?

Not so easy, as it could be hidden away in the build infrastructure. It might 
not be at all obvious from just looking at the port file...

Probably the only way is to wait for the bug reports once 12.3 is out ...

>
> G
>
> Sent from my iPhone
>
>> On 19 Feb 2022, at 17:26, Christopher Jones  wrote:
>>
>> 
>>
>>> On 19 Feb 2022, at 1:58 pm, Gerben Wierda via macports-dev 
>>>  wrote:
>>>
>>> Oof.
>>>
>>> I’m happy to check as soon as 12.3 is out, but I wonder how to check. 
>>> Installing a port is easy enough to do, but how do I find out if a port 
>>> uses it in some arcane way? And if it does, how should one fix.
>>>
>>> I was wondering if a reasonable band-aid would be to have /usr/bin/python 
>>> link to the one from MacPorts when installed, but given Apple’s strategy in 
>>> clamping down, I guess that will not work in the long term, even if it 
>>> might work in the short term. And of course, such a band-at only hides the 
>>> debt that has now been created in the ports so it is a bad idea in other 
>>> senses as well.
>>
>> Terrible idea all round. Don’t do it.
>>
>> Note /usr/bin/python3 is still there (for now). Ports that can use python3 
>> instead could just use this, on the OSes that provide it.
>>
>> Better solution, as it works across more OSes, is to declare a dependency 
>> (build, or lib depending on how python3 is used) on one of the macports 
>> python3 versions and configure the builds to find that directly in ${prefix}.
>>
>> Chris
>>
>>



smime.p7s
Description: S/MIME cryptographic signature


Re: /usr/bin/python will be removed in macOS 12.3!

2022-02-19 Thread Christopher Jones



> On 19 Feb 2022, at 1:58 pm, Gerben Wierda via macports-dev 
>  wrote:
>
> Oof.
>
> I’m happy to check as soon as 12.3 is out, but I wonder how to check. 
> Installing a port is easy enough to do, but how do I find out if a port uses 
> it in some arcane way? And if it does, how should one fix.
>
> I was wondering if a reasonable band-aid would be to have /usr/bin/python 
> link to the one from MacPorts when installed, but given Apple’s strategy in 
> clamping down, I guess that will not work in the long term, even if it might 
> work in the short term. And of course, such a band-at only hides the debt 
> that has now been created in the ports so it is a bad idea in other senses as 
> well.

Terrible idea all round. Don’t do it.

Note /usr/bin/python3 is still there (for now). Ports that can use python3 
instead could just use this, on the OSes that provide it.

Better solution, as it works across more OSes, is to declare a dependency 
(build, or lib depending on how python3 is used) on one of the macports python3 
versions and configure the builds to find that directly in ${prefix}.

Chris




smime.p7s
Description: S/MIME cryptographic signature


Re: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

2022-01-14 Thread Christopher Jones

please open a trac ticket and we will discuss there. better than a mailing list.

> On 14 Jan 2022, at 11:55 am, Steven Smith  wrote:
> 
> Chris, Thanks, and concur on the wonderfulness of bazel.
> 
> To be clear, I am not building bazel-3.7 here. I am building 
> py38-tensorflow-metadata, which uses bazel-3.7. I’ve attached the log file. 
> It was produced with a build (please see attached Portfile) that adds 
> `bazel.build_opts-append --sandbox_debug`, not that I see that helping a 
> diagnosis.
> 
> FWIW, I looked in the binary /opt/local/libexec/bazel-3.7/bin/bazel for the 
> string “_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel” but it’s 
> not there, at least not in plain text. I have no idea how this path is being 
> introduced at the build stage. 
> 
> 
> Attachments:
> 
> 
> 
> 
> 
>> On Jan 14, 2022, at 2:52 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> 
>>> On 14 Jan 2022, at 3:14 am, Steven Smith >> <mailto:steve.t.sm...@gmail.com>> wrote:
>>> 
>>> I’m trying to build/update py-tensforflow-metadat and am hitting this 
>>> (bizarre) bazel issue.
>>> 
>>> First, the build fails with the error:
>>> 
>>>> :info:build Execution platform: @local_config_platform//:host
>>>> :info:build Use --sandbox_debug to see verbose messages from the sandbox
>>>> :info:build xcrun: error: can't exec 
>>>> '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc'
>>>>  (errno=No such file or directory)
>>> 
>>> 
>>> Weird that bazel wants to look in a MacPorts build directory.
>>> 
>>> Searching for this string in ${worksrcpath}, it appears in the file created 
>>> during the build stage:
>>> 
>>> ${worksrcpath}/bazel_build/install//embedded_tools/tools/osx/crosstool/wrapped_clang.cc
>>>  <http://wrapped_clang.cc/>:
>>> 
>>>>   if (binary_name == "wrapped_clang_pp") {
>>>> tool_name = 
>>>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cxx";
>>>>   } else if (binary_name == "wrapped_clang") {
>>>> tool_name = 
>>>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc";
>>> 
>>> This is not the file from 
>>> https://github.com/bazelbuild/bazel/blob/master/tools/osx/crosstool/wrapped_clang.cc
>>>  
>>> <https://github.com/bazelbuild/bazel/blob/master/tools/osx/crosstool/wrapped_clang.cc>
>>> 
>>> I’m stumped. Does anyone have insight on what’s causing this weird bazel 
>>> build issue?
>>> 
>> 
>> The above is intentional, and performed by the bazel build to (attempt) to 
>> work around issues with the bazel build on older systems, which is 
>> spectacularly difficult to work with . Specifically see
>> 
>> https://github.com/macports/macports-ports/blob/6569ac3bcc84a00f72513d0f8ceebb6b6cec1576/devel/bazel/Portfile#L259
>>  
>> <https://github.com/macports/macports-ports/blob/6569ac3bcc84a00f72513d0f8ceebb6b6cec1576/devel/bazel/Portfile#L259>
>> 
>> why you see the above I cannot say. Please also post a complete log, not 
>> just snippets like above.
>> 
>> is there a specific reason you are building bazel-3.7 from source ? binary 
>> tarballs are availing for 10.11 and newer
>> 
>> https://ports.macports.org/port/bazel-3.7/details/ 
>> <https://ports.macports.org/port/bazel-3.7/details/>
>> 
>> Chris
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

2022-01-13 Thread Christopher Jones

> On 14 Jan 2022, at 3:14 am, Steven Smith  wrote:
> 
> I’m trying to build/update py-tensforflow-metadat and am hitting this 
> (bizarre) bazel issue.
> 
> First, the build fails with the error:
> 
>> :info:build Execution platform: @local_config_platform//:host
>> :info:build Use --sandbox_debug to see verbose messages from the sandbox
>> :info:build xcrun: error: can't exec 
>> '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc'
>>  (errno=No such file or directory)
> 
> 
> Weird that bazel wants to look in a MacPorts build directory.
> 
> Searching for this string in ${worksrcpath}, it appears in the file created 
> during the build stage:
> 
> ${worksrcpath}/bazel_build/install//embedded_tools/tools/osx/crosstool/wrapped_clang.cc
>  :
> 
>>   if (binary_name == "wrapped_clang_pp") {
>> tool_name = 
>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cxx";
>>   } else if (binary_name == "wrapped_clang") {
>> tool_name = 
>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc";
> 
> This is not the file from 
> https://github.com/bazelbuild/bazel/blob/master/tools/osx/crosstool/wrapped_clang.cc
>  
> 
> 
> I’m stumped. Does anyone have insight on what’s causing this weird bazel 
> build issue?
> 

The above is intentional, and performed by the bazel build to (attempt) to work 
around issues with the bazel build on older systems, which is spectacularly 
difficult to work with . Specifically see

https://github.com/macports/macports-ports/blob/6569ac3bcc84a00f72513d0f8ceebb6b6cec1576/devel/bazel/Portfile#L259
 


why you see the above I cannot say. Please also post a complete log, not just 
snippets like above.

is there a specific reason you are building bazel-3.7 from source ? binary 
tarballs are availing for 10.11 and newer

https://ports.macports.org/port/bazel-3.7/details/ 


Chris




smime.p7s
Description: S/MIME cryptographic signature


Re: SecTrustEvaluateWithError on 10.12 and earlier?

2022-01-10 Thread Christopher Jones
Have you reported it to the developers to see what they say ?

> On 9 Jan 2022, at 7:31 pm, Herby G  wrote:
> 
> The latest Go (1.17.6) isn't building on 10.12 and earlier due to missing 
> SecTrustEvaluateWithError 
> (https://developer.apple.com/documentation/security/2980705-sectrustevaluatewitherror
>  
> )
> 
> Here's the log from the 10.12 buildbot: 
> https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/173366/steps/install-port/logs/stdio
>  
> 
> 
> Any ideas or recommendations?



smime.p7s
Description: S/MIME cryptographic signature


Re: [10.6.8] MySQL 5.7.36_1 compile hell

2021-12-20 Thread Christopher Jones

>
> DEBUG: configure phase started at Mon Dec 20 14:44:46 CET 2021
> --->  Configuring mysql57
> DEBUG: Preferred compilers: macports-clang-9.0 macports-clang-8.0
> macports-clang-7.0 macports-clang-6.0 macports-clang-5.0
> macports-clang-11 macports-clang-10 macports-clang-3.7 macports-clang-3.4
> DEBUG: Using compiler 'MacPorts Clang 9.0'
> DEBUG: Executing proc-pre-org.macports.configure-configure-0
> Error: mysql57 cannot be built while boost is active.
> Error: Please forcibly deactivate boost, e.g. by running:
> Error:
> Error: sudo port -f deactivate boost
> Error:
> Error: Then try again. You can reactivate boost again later.
> Error: Failed to configure mysql57: boost is active
> DEBUG: Error code: NONE
> DEBUG: Backtrace: boost is active


and… did you try following the instructions above ?



smime.p7s
Description: S/MIME cryptographic signature


Re: [10.6.8] MySQL 5.7.36_1 compile hell

2021-12-20 Thread Christopher Jones
protobuf-cpp and protobuf3-cpp are two different ports…

anyway, looks like you have got your registry into a screwy state in someway, 
to get

DEBUG: Registry error: protobuf3-cpp not registered as installed & active.

try installing protobuf3-cpp (i.e. with a 3…) and then see what happens.

> On 20 Dec 2021, at 1:34 pm, Bjarne D Mathiesen  
> wrote:
> 
> 2nd Attempt
> ---
> 
> DEBUG: Registry error: protobuf-cpp not registered as installed & active.
> 
> root@MiniWeb 14:24:01 ~
> #=> port clean --work mysql57
> --->  Cleaning mysql57
> 
> root@MiniWeb 14:26:05 ~
> #=> port -cuNp install protobuf-cpp
> --->  Computing dependencies for protobuf-cpp
> --->  Dependencies to be installed: autoconf automake
> --->  Fetching archive for autoconf
> --->  Attempting to fetch autoconf-2.71_1.darwin_10.noarch.tbz2 from
> http://cph.dk.packages.macports.org/autoconf
> --->  Attempting to fetch autoconf-2.71_1.darwin_10.noarch.tbz2.rmd160
> from http://cph.dk.packages.macports.org/autoconf
> --->  Installing autoconf @2.71_1
> --->  Activating autoconf @2.71_1
> --->  Cleaning autoconf
> --->  Fetching archive for automake
> --->  Attempting to fetch automake-1.16.5_0.darwin_10.noarch.tbz2 from
> http://cph.dk.packages.macports.org/automake
> --->  Attempting to fetch automake-1.16.5_0.darwin_10.noarch.tbz2.rmd160
> from http://cph.dk.packages.macports.org/automake
> --->  Installing automake @1.16.5_0
> --->  Activating automake @1.16.5_0
> --->  Cleaning automake
> --->  Fetching archive for protobuf-cpp
> --->  Attempting to fetch protobuf-cpp-2.6.1_0.darwin_10.x86_64.tbz2
> from http://cph.dk.packages.macports.org/protobuf-cpp
> --->  Attempting to fetch
> protobuf-cpp-2.6.1_0.darwin_10.x86_64.tbz2.rmd160 from
> http://cph.dk.packages.macports.org/protobuf-cpp
> --->  Installing protobuf-cpp @2.6.1_0
> --->  Activating protobuf-cpp @2.6.1_0
> --->  Cleaning protobuf-cpp
> 
> root@MiniWeb 14:27:10 ~
> #=> port -d -cuNp upgrade mysql57
> 
> DEBUG: configure phase started at Mon Dec 20 14:29:08 CET 2021
> --->  Configuring mysql57
> DEBUG: Preferred compilers: macports-clang-9.0 macports-clang-8.0
> macports-clang-7.0 macports-clang-6.0 macports-clang-5.0
> macports-clang-11 macports-clang-10 macports-clang-3.7 macports-clang-3.4
> DEBUG: Using compiler 'MacPorts Clang 9.0'
> DEBUG: Executing proc-pre-org.macports.configure-configure-0
> Error: mysql57 cannot be built while protobuf-cpp is active.
> Error: Please forcibly deactivate protobuf-cpp, e.g. by running:
> Error:
> Error: sudo port -f deactivate protobuf-cpp
> Error:
> Error: Then try again. You can reactivate protobuf-cpp again later.
> Error: Failed to configure mysql57: protobuf-cpp is active
> DEBUG: Error code: NONE
> DEBUG: Backtrace: protobuf-cpp is active
>while executing
> "$pre $targetname"
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql57/mysql57/main.log
> for details.
> DEBUG: Registry error: protobuf3-cpp not registered as installed & active.
> 
> So, now I've got :
> 
> 1) It can see protobuf-cpp;
>   but complains about it being active
>   which contradicts the original error-message somewhat
> 2) and now it furthermore complains about protobuf3-cpp
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
> 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
> ATI Radeon RX 590 8 GB



smime.p7s
Description: S/MIME cryptographic signature


Re: Acceptability of depends_build bin:…

2021-12-13 Thread Christopher Jones



> On 13 Dec 2021, at 10:48 am, Christopher Chavez  wrote:
>
> I recently specified bin:node:… build dependency in qt5-qtwebengine. I would 
> not consider Node.js to be a lightweight dependency, so I thought it would be 
> preferable to allow using whichever is present, even a non-MacPorts one, 
> before having to install a fallback; and because I had not investigated 
> whether the build process would always respect a path:… or port:… dependency.
>
> It has now been requested that bin:node:… not be used, in light of this 
> comment: 
> https://github.com/macports/macports-ports/commit/afad77a86ba6be6572cf0aff35db0b13401196f1#commitcomment-61791005
>
>
>> A `bin:`-style dependency allows any binary in the path, even in locations 
>> outside of MacPorts, to satisfy a dependency, which is not usually desired.
>
>
> While I’m somewhat aware why bin:… dependencies are particularly undesirable 
> for library or runtime dependencies, how strongly does the recommendation to 
> avoid them apply to dependencies only used during build? Are they to still be 
> avoided as much as possible, regardless of how heavy the dependencies are or 
> whether one believes allowing third-party dependencies would not cause any 
> significant difference in the built port (w.r.t. build reproducibility) nor 
> pose a risk of build failure?

In my opinion yes, they should be avoided. Just because it is a build dep. 
doesn’t make a difference, as we want reproducible builds, which means having 
control over the whole process, and allowing whatever is found in 'bin’ to 
satisfy a dependency breaks this.



smime.p7s
Description: S/MIME cryptographic signature


Re: Recent OpenSSL changes and CA certs

2021-10-13 Thread Christopher Jones
Hi,

> On 13 Oct 2021, at 9:41 am, Aaron Madlon-Kay  wrote:
> 
> Thanks. Two questions:
> 
> 1. Is it not a problem that the user may not have curl-ca-bundle
> installed? (I guess it would just be a dangling symlink and that's not
> a problem?)

I figured a dangling sym. link was no worse than anyway not having the file it 
pointed at.

> 
> 2. Does openssl10 not need the same workaround?

yes, and openssl3. Just doing some test builds on these before pushing them.

Chris

> 
> -Aaron
> 
> On Wed, Oct 13, 2021 at 5:35 PM Christopher Jones
>  wrote:
>> 
>> 
>> Should be addressed by
>> 
>> https://github.com/macports/macports-ports/commit/f972290289d1d8370b3ca69554cbcf046c7023fa
>> 
>> 
>> On 13 Oct 2021, at 9:21 am, Christopher Jones  
>> wrote:
>> 
>> 
>> Sorry, forget the comment below, read it the wrong way around…
>> 
>> 
>> 
>> On 13 Oct 2021, at 9:00 am, Christopher Jones  
>> wrote:
>> 
>> Hi,
>> 
>> Howe does
>> 
>> /opt/local/libexec/openssl11/etc/openssl/cert.pem
>> 
>> get created, as its not actually part of the openssl11 port itself ?
>> 
>> Oberon ~/Projects/MacPorts/ports > port contents openssl11 | grep cert.pem
>> Oberon ~/Projects/MacPorts/ports >
>> 
>> Chris
>> 
>> On 13 Oct 2021, at 5:58 am, Aaron Madlon-Kay  wrote:
>> 
>> Hi all.
>> 
>> I know there are some important changes being made to the OpenSSL
>> ports. Today I updated my ports and now have the following installed:
>> 
>> % port installed name:openssl
>> The following ports are currently installed:
>> openssl @1.1_0 (active)
>> openssl10 @1.0.2u_2 (active)
>> openssl11 @1.1.1l_2 (active)
>> 
>> Apparently as a result of this, my Ruby environment (managed by rbenv
>> + ruby-build, both available as ports) seems to no longer be able to
>> connect to HTTPS hosts.
>> 
>> By some trial and error, I managed to find that symlinking the certs
>> installed by the curl-ca-bundle port into the new "real" home of
>> OpenSSL solved the problem:
>> 
>> sudo ln -s /opt/local/share/curl/curl-ca-bundle.crt
>> /opt/local/libexec/openssl11/etc/openssl/cert.pem
>> 
>> Can anyone point me to a better solution?
>> 
>> I note that the Ruby OpenSSL module (built under the old OpenSSL port
>> regime) is linked to /opt/local/lib/{libssl,libcrypto}.1.1.dylib. If I
>> rebuild Ruby after updating to the new port regime, it is linked to
>> /opt/local/libexec/openssl11/lib/{libssl,libcrypto}.1.1.dylib. Either
>> way, SSL connections fail unless I symlink cert.pem as above. There
>> are no apparent breakages in the linking itself.
>> 
>> Thanks,
>> Aaron
>> 
>> 
>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Recent OpenSSL changes and CA certs

2021-10-13 Thread Christopher Jones

Should be addressed by

https://github.com/macports/macports-ports/commit/f972290289d1d8370b3ca69554cbcf046c7023fa
 
<https://github.com/macports/macports-ports/commit/f972290289d1d8370b3ca69554cbcf046c7023fa>


> On 13 Oct 2021, at 9:21 am, Christopher Jones  
> wrote:
> 
> 
> Sorry, forget the comment below, read it the wrong way around…
> 
> 
> 
>> On 13 Oct 2021, at 9:00 am, Christopher Jones  
>> wrote:
>> 
>> Hi,
>> 
>> Howe does
>> 
>> /opt/local/libexec/openssl11/etc/openssl/cert.pem
>> 
>> get created, as its not actually part of the openssl11 port itself ?
>> 
>> Oberon ~/Projects/MacPorts/ports > port contents openssl11 | grep cert.pem
>> Oberon ~/Projects/MacPorts/ports >
>> 
>> Chris
>> 
>>> On 13 Oct 2021, at 5:58 am, Aaron Madlon-Kay  wrote:
>>> 
>>> Hi all.
>>> 
>>> I know there are some important changes being made to the OpenSSL
>>> ports. Today I updated my ports and now have the following installed:
>>> 
>>> % port installed name:openssl
>>> The following ports are currently installed:
>>> openssl @1.1_0 (active)
>>> openssl10 @1.0.2u_2 (active)
>>> openssl11 @1.1.1l_2 (active)
>>> 
>>> Apparently as a result of this, my Ruby environment (managed by rbenv
>>> + ruby-build, both available as ports) seems to no longer be able to
>>> connect to HTTPS hosts.
>>> 
>>> By some trial and error, I managed to find that symlinking the certs
>>> installed by the curl-ca-bundle port into the new "real" home of
>>> OpenSSL solved the problem:
>>> 
>>> sudo ln -s /opt/local/share/curl/curl-ca-bundle.crt
>>> /opt/local/libexec/openssl11/etc/openssl/cert.pem
>>> 
>>> Can anyone point me to a better solution?
>>> 
>>> I note that the Ruby OpenSSL module (built under the old OpenSSL port
>>> regime) is linked to /opt/local/lib/{libssl,libcrypto}.1.1.dylib. If I
>>> rebuild Ruby after updating to the new port regime, it is linked to
>>> /opt/local/libexec/openssl11/lib/{libssl,libcrypto}.1.1.dylib. Either
>>> way, SSL connections fail unless I symlink cert.pem as above. There
>>> are no apparent breakages in the linking itself.
>>> 
>>> Thanks,
>>> Aaron
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Recent OpenSSL changes and CA certs

2021-10-13 Thread Christopher Jones

Sorry, forget the comment below, read it the wrong way around…



> On 13 Oct 2021, at 9:00 am, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Howe does
> 
> /opt/local/libexec/openssl11/etc/openssl/cert.pem
> 
> get created, as its not actually part of the openssl11 port itself ?
> 
> Oberon ~/Projects/MacPorts/ports > port contents openssl11 | grep cert.pem
> Oberon ~/Projects/MacPorts/ports >
> 
> Chris
> 
>> On 13 Oct 2021, at 5:58 am, Aaron Madlon-Kay  wrote:
>> 
>> Hi all.
>> 
>> I know there are some important changes being made to the OpenSSL
>> ports. Today I updated my ports and now have the following installed:
>> 
>> % port installed name:openssl
>> The following ports are currently installed:
>> openssl @1.1_0 (active)
>> openssl10 @1.0.2u_2 (active)
>> openssl11 @1.1.1l_2 (active)
>> 
>> Apparently as a result of this, my Ruby environment (managed by rbenv
>> + ruby-build, both available as ports) seems to no longer be able to
>> connect to HTTPS hosts.
>> 
>> By some trial and error, I managed to find that symlinking the certs
>> installed by the curl-ca-bundle port into the new "real" home of
>> OpenSSL solved the problem:
>> 
>> sudo ln -s /opt/local/share/curl/curl-ca-bundle.crt
>> /opt/local/libexec/openssl11/etc/openssl/cert.pem
>> 
>> Can anyone point me to a better solution?
>> 
>> I note that the Ruby OpenSSL module (built under the old OpenSSL port
>> regime) is linked to /opt/local/lib/{libssl,libcrypto}.1.1.dylib. If I
>> rebuild Ruby after updating to the new port regime, it is linked to
>> /opt/local/libexec/openssl11/lib/{libssl,libcrypto}.1.1.dylib. Either
>> way, SSL connections fail unless I symlink cert.pem as above. There
>> are no apparent breakages in the linking itself.
>> 
>> Thanks,
>> Aaron
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Recent OpenSSL changes and CA certs

2021-10-13 Thread Christopher Jones
Hi,

Howe does

/opt/local/libexec/openssl11/etc/openssl/cert.pem

get created, as its not actually part of the openssl11 port itself ?

Oberon ~/Projects/MacPorts/ports > port contents openssl11 | grep cert.pem
Oberon ~/Projects/MacPorts/ports >

Chris

> On 13 Oct 2021, at 5:58 am, Aaron Madlon-Kay  wrote:
> 
> Hi all.
> 
> I know there are some important changes being made to the OpenSSL
> ports. Today I updated my ports and now have the following installed:
> 
> % port installed name:openssl
> The following ports are currently installed:
>  openssl @1.1_0 (active)
>  openssl10 @1.0.2u_2 (active)
>  openssl11 @1.1.1l_2 (active)
> 
> Apparently as a result of this, my Ruby environment (managed by rbenv
> + ruby-build, both available as ports) seems to no longer be able to
> connect to HTTPS hosts.
> 
> By some trial and error, I managed to find that symlinking the certs
> installed by the curl-ca-bundle port into the new "real" home of
> OpenSSL solved the problem:
> 
> sudo ln -s /opt/local/share/curl/curl-ca-bundle.crt
> /opt/local/libexec/openssl11/etc/openssl/cert.pem
> 
> Can anyone point me to a better solution?
> 
> I note that the Ruby OpenSSL module (built under the old OpenSSL port
> regime) is linked to /opt/local/lib/{libssl,libcrypto}.1.1.dylib. If I
> rebuild Ruby after updating to the new port regime, it is linked to
> /opt/local/libexec/openssl11/lib/{libssl,libcrypto}.1.1.dylib. Either
> way, SSL connections fail unless I symlink cert.pem as above. There
> are no apparent breakages in the linking itself.
> 
> Thanks,
> Aaron



smime.p7s
Description: S/MIME cryptographic signature


Re: upgrade to openssl 3.0.0

2021-10-07 Thread Christopher Jones

https://github.com/macports/macports-ports/pull/12514 
<https://github.com/macports/macports-ports/pull/12514>


> On 6 Oct 2021, at 5:46 pm, Christopher Jones  wrote:
> 
> I’m working on the basic changes to implement my suggestion at the moment. 
> Once that is there testing specific ports against version 3 ’the canaries’ 
> will be trivial. more in a bit.
> 
>> On 6 Oct 2021, at 5:40 pm, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote:
>> 
>> For whoever gets up the enthusiasm to take on the storm of nay-sayers:
>> 
>> Although I found about 90% of the 100 or so ports I tried built without any 
>> changes against openssl 3.0.0 (rust, cargo, qt5, qt4-mac, etc, etc), and the 
>> rest were easy < 5 min fixes to use our openssl11 port, I noted in the 
>> openssl 3 migration guide that the FIPS mode is disabled by default on the 
>> openssl 3 build, and has to be expressly enabled.
>> 
>> I recall that most of the (very few) build failures I saw were in fact FIPS 
>> failures, so enabling that module might fix a bunch of them.
>> 
>> Best,
>> 
>> Ken
>> 
>> 
>> On Tue, Oct 5, 2021 at 12:54 PM Fred Wright > <mailto:f...@fwright.net>> wrote:
>> 
>> On Mon, 4 Oct 2021, Christopher Jones wrote:
>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
>> >> > >> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>> >>
>> >> I was hoping to move this along for the overwhelming benefit of the 
>> >> license, but TBH the push-back so far is 99.99% negative about moving 
>> >> to openssl 3.0.0 this year, so too controversial for me to get involved 
>> >> with. I'll sit back for six to twelve months and see what you guys work 
>> >> out over the coming year.
>> >
>> > All the more reason to follow my suggested migration path then I would 
>> > say, as it allows an openssl30 port to be made available, and those 
>> > ports that wish to can use it via the new PG, but it doesn’t have to 
>> > become the default until some later date.
>> 
>> The PR thread contained (approximately) the following two statements:
>> 
>> 1) Unless v3 is the default, nobody will bother to use it.
>> 
>> 2) Everybody is really, *really* anxious to move to v3 for the more 
>> permissive license.
>> 
>> Clearly those two statements are in conflict.
>> 
>> At Google, we had a process called "canarying".  Although technically a 
>> misnomer, it referred to the "canary in the coal mine" concept, with the 
>> idea that rolling out new stuff with possible issues should start small, 
>> so that problems could be found (and hopefully fixed) before they caused 
>> large-scale breakage.
>> 
>> If the OpenSSL folks were committed to maintaining backward compatibility, 
>> then none of this nonsense would be necessary, but it's clear that they're 
>> not.  And there's no reason to assume that they won't pull the same crap 
>> again in the future (having done so at least twice already), so having a 
>> mechanism for multiple coexisting OpenSSL "major" versions could have 
>> long-term value beyond the v3 transition.
>> 
>> > TBH I also was quite dubious of making 3.0.0 the default any time ’soon’
>> 
>> I agree, especially if the only end benefit is the license.  Remember, 
>> OpenSSL is the poster child for why *not* to assume that that newer is 
>> more secure. :-)
>> 
>> Fred Wright
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: upgrade to openssl 3.0.0

2021-10-06 Thread Christopher Jones
I’m working on the basic changes to implement my suggestion at the moment. Once 
that is there testing specific ports against version 3 ’the canaries’ will be 
trivial. more in a bit.

> On 6 Oct 2021, at 5:40 pm, Ken Cunningham  
> wrote:
> 
> For whoever gets up the enthusiasm to take on the storm of nay-sayers:
> 
> Although I found about 90% of the 100 or so ports I tried built without any 
> changes against openssl 3.0.0 (rust, cargo, qt5, qt4-mac, etc, etc), and the 
> rest were easy < 5 min fixes to use our openssl11 port, I noted in the 
> openssl 3 migration guide that the FIPS mode is disabled by default on the 
> openssl 3 build, and has to be expressly enabled.
> 
> I recall that most of the (very few) build failures I saw were in fact FIPS 
> failures, so enabling that module might fix a bunch of them.
> 
> Best,
> 
> Ken
> 
> 
> On Tue, Oct 5, 2021 at 12:54 PM Fred Wright  <mailto:f...@fwright.net>> wrote:
> 
> On Mon, 4 Oct 2021, Christopher Jones wrote:
> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham  >> <mailto:ken.cunningham.web...@gmail.com>> wrote:
> >>
> >> I was hoping to move this along for the overwhelming benefit of the 
> >> license, but TBH the push-back so far is 99.99% negative about moving 
> >> to openssl 3.0.0 this year, so too controversial for me to get involved 
> >> with. I'll sit back for six to twelve months and see what you guys work 
> >> out over the coming year.
> >
> > All the more reason to follow my suggested migration path then I would 
> > say, as it allows an openssl30 port to be made available, and those 
> > ports that wish to can use it via the new PG, but it doesn’t have to 
> > become the default until some later date.
> 
> The PR thread contained (approximately) the following two statements:
> 
> 1) Unless v3 is the default, nobody will bother to use it.
> 
> 2) Everybody is really, *really* anxious to move to v3 for the more 
> permissive license.
> 
> Clearly those two statements are in conflict.
> 
> At Google, we had a process called "canarying".  Although technically a 
> misnomer, it referred to the "canary in the coal mine" concept, with the 
> idea that rolling out new stuff with possible issues should start small, 
> so that problems could be found (and hopefully fixed) before they caused 
> large-scale breakage.
> 
> If the OpenSSL folks were committed to maintaining backward compatibility, 
> then none of this nonsense would be necessary, but it's clear that they're 
> not.  And there's no reason to assume that they won't pull the same crap 
> again in the future (having done so at least twice already), so having a 
> mechanism for multiple coexisting OpenSSL "major" versions could have 
> long-term value beyond the v3 transition.
> 
> > TBH I also was quite dubious of making 3.0.0 the default any time ’soon’
> 
> I agree, especially if the only end benefit is the license.  Remember, 
> OpenSSL is the poster child for why *not* to assume that that newer is 
> more secure. :-)
> 
> Fred Wright



smime.p7s
Description: S/MIME cryptographic signature


Re: upgrade to openssl 3.0.0

2021-10-04 Thread Christopher Jones


> On 4 Oct 2021, at 5:54 pm, Ken Cunningham  
> wrote:
> 
> as you wish, Chris.
> 
> 
> I was hoping to move this along for the overwhelming benefit of the license, 
> but TBH the push-back so far is 99.99% negative about moving to openssl 3.0.0 
> this year, so too controversial for me to get involved with. I'll sit back 
> for six to twelve months and see what you guys work out over the coming year.

All the more reason to follow my suggested migration path then I would say, as 
it allows an openssl30 port to be made available, and those ports that wish to 
can use it via the new PG, but it doesn’t have to become the default until some 
later date.

TBH I also was quite dubious of making 3.0.0 the default any time ’soon’

Chris

> 
> K
> 
> On Mon, Oct 4, 2021 at 8:18 AM Chris Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> 
> Reading this thread again, I think there is some confusion over what I 
> am suggesting, compared to Renee/Ken, as really the differences are 
> minor and cosmetic packaging differences.
> 
> The main difference is I am suggesting aiming for consistency across 
> where all the openssl ports install to. Instead of having some install 
> to libexec, and then one 'blessed' default port install directly into 
> ${prefix} have opensslXYZ ports for *all* versions we need, that all 
> install to their own libexec area. Then, have a trivial shim port for 
> the general 'openssl' port that just installs a few sym links from 
> whatever the 'default' openssl version is deemed to be (currently 1.1.1) 
> into the primary ${prefix} install.
> 
> We could do this, right now, i.e. move the current openssl port to an 
> isolated libexec openssl11 port, and update openssl to just be a shim to 
> that install. This would be completely transparent to all ports using 
> openssl.
> 
> The advantage of this to me would be
> 
> 1. Consistency across all the openssl ports, as they would all, 
> regardless of their version, be treated (installed) the same way.
> 
> 2. Once there, we could then introduce a new port group that extends 
> what the current old_openssl PG does but in a more general way, as it 
> would work for not just 'old' openssl versions, but also the current 
> default and also new ones. e.g. we could then add a openssl30 port and 
> allow a few ports to experiment with it.
> 
> 3. Once we are OK with a few ports using openssl30 we could 'throw the 
> switch' and update the shim port to point to the 3.0 version.
> 
> The above, if you think about it, is really no different to what 
> Ken/Renee are suggesting in terms of what ports have to do. If ports are 
> OK with just relying on the default they can carry on using the 
> 'openssl' (shim) port, just as they are now. Nothing is forcing us to 
> change these ports. *If* ports wanted to migrate to use the new PG that 
> is fine, but its an optional choice (unless they are not compatible with 
> 3.0 of course, but then they will need updating anyway once 3.0 is the 
> default).
> 
> So why do the above instead of what Ken/Renee suggest ? for me the 
> primary reason is we end up with a system where in future it will be 
> much easier to deal with future new major versions, without having to 
> have these discussions again... Say 3.1 or 4.0 comes out, a new isolated 
> opensslXY port can be added to provide that, that will live alongside 
> the current ones. A few ports could be tested against it, and as and 
> when we are ready the default can be flipped again to point to it.
> 
> Chris
> 
> 
> On 04/10/2021 10:24 am, Christopher Jones wrote:
> > 
> > 
> >> On 2 Oct 2021, at 8:06 pm, Ken Cunningham 
> >> mailto:ken.cunningham.web...@gmail.com> 
> >> <mailto:ken.cunningham.web...@gmail.com 
> >> <mailto:ken.cunningham.web...@gmail.com>>> wrote:
> >>
> >> That is exactly the approach that I don't find workable, Chris.
> >>
> >> Specifically:
> >>
> >> 1. every single port (think: rust, ghc, blah blah) will have to be 
> >> needlessly managed to build against an alternate openssl location.
> > 
> > why ? They can start of using the shim port and only use the isolated 
> > builds as and when they are ready
> > 
> >> 2. there will be no default openssl ever in prefix.
> > 
> > why not ? The boost set has one and I see no reason why openssl cannot 
> > as well.
> > 
> > Chris
> > 
> >>
> >> So I am not on board for trying to implement that myself, but should 
> >> that be the selected course I will watch from the sidelines as others 
> >> proceed down that path.
> >>
> >> K
> >&

Re: upgrade to openssl 3.0.0

2021-10-04 Thread Christopher Jones


> On 2 Oct 2021, at 8:06 pm, Ken Cunningham  
> wrote:
> 
> That is exactly the approach that I don't find workable, Chris.
> 
> Specifically:
> 
> 1. every single port (think: rust, ghc, blah blah) will have to be needlessly 
> managed to build against an alternate openssl location.

why ? They can start of using the shim port and only use the isolated builds as 
and when they are ready

> 2. there will be no default openssl ever in prefix.

why not ? The boost set has one and I see no reason why openssl cannot as well.

Chris

> 
> So I am not on board for trying to implement that myself, but should that be 
> the selected course I will watch from the sidelines as others proceed down 
> that path.
> 
> K
> 
>> On Oct 2, 2021, at 12:02 PM, Chris Jones > > wrote:
>> 
>> Hi,
>> 
>> Personally I would strongly recommend following a migration path that does 
>> not require an enmass change but allows ports to migrate  at their own pace. 
>> I would personally very much recommend an approach similar to that we used 
>> for boost recently
>> 
>> 1. Introduced a set of new isolated opensslXYZ ports that install specific 
>> versions into isolated install areas under libexec.
>> 2. Create a new portgroup that handles the confirmation of ports to pick the 
>> openssl version they wish to use, with some default, and performs various 
>> standard configurations for standard build systems such that for most ports 
>> they work out the box with the new portgroup. For those that don’t provide 
>> various proc methods that return the configured install paths such that 
>> ports can used them to configure themselves as required.
>> 3. Make the current openssl port a basic shim port that just installs sym 
>> links into the primary install area to the default openssl version (for now 
>> 1.1.1), so ports building against the current openssl port carry on working 
>> just as they are now, but are redirected to use the same versioned 1.1.1 
>> port as those using the PG.
>> 
>> Once this is in place, ports can be migrated to use the new PG individually 
>> as and when we want.
>> 
>> Chris
>> 
>>> On 2 Oct 2021, at 6:17 pm, Ken Cunningham >> > wrote:
>>> 
>>> 
>>> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that 
>>> will let many previously non-distributable ports become distributable.  
>>> However, there are 758 ports that indicate they link against openssl. That 
>>> is a daunting number of ports indeed.
>>> 
>>> One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) 
>>> into subdirectories out of ${prefix}, have no default openssl installed in 
>>> $[prefix} directly, create a new PortGroup, openssl_select or some such, 
>>> add that PG to all 758 ports, default it to openssl 1.1.1, and then allow 
>>> people to gradually move the 758 ports to openssl 3.0.0 as they get to it.
>>> 
>>> Although that is possible with suitable effort, I don’t think that is 
>>> workable for many reasons, the most obvious being that we would then have 
>>> to modify every single port in some way to find an openssl installed into a 
>>> non-default prefix. Creating the PG and adding it to 758 ports might be 
>>> work enough, but then finding the right way to force all 758 ports to build 
>>> properly against an openssl that is not in the default prefix is the real 
>>> horror, and seems like a nightmare of wasted labours.
>>> 
>>> So it would appear that the same option that was chosen last time, ie 
>>> upgrade the default openssl in ${prefix} to the newer openssl, and then fix 
>>> the subset of ports that will not build against it to use an older openssl 
>>> appears both the better option and lot less work (assuming most ports do 
>>> build against openssl 3.0.0, which seems to be the case so far). Some will 
>>> disagree, but I put it to you that it is going to be far less work in the 
>>> end to force a few % of the ports to a specific alternate openssl than 
>>> force all of them, all the time, forever.
>>> 
>>> Most things I have attempted to rebuild over the past few days have rebuilt 
>>> without any issues, but a few things don’t build with openssl 3.0.0 yet and 
>>> will need to stay with openssl 1.1.1 for a while until patched or updated 
>>> (or forever). That will require both forcing those ports to find an 
>>> alternate openssl installation, and also (the tricky part) forcing them to 
>>> ignore the openssl in the default prefix.
>>> 
>>> To support this, there is a new openssl11 port that provides openssl 1.1.1 
>>> tucked away in a subdir, much like we have openssl10, and a few new options 
>>> were added to the old_openssl PortGroup to allow most ports to be forced to 
>>> the alternate openssl with minimal fuss. Add the PortGroup, spec the 
>>> branch, and choose the method, for the most part.
>>> 
>>> If this plan holds, I would anticipate that we move ports that we find need 
>>> to stay on openssl 

Re: upgrade to openssl 3.0.0

2021-10-04 Thread Christopher Jones


> On 2 Oct 2021, at 9:03 pm, Renee Otten  wrote:
> 
> I was initially suggesting the same approach, which is a slightly more 
> conservative approach, in the Trac ticket 
> (https://trac.macports.org/ticket/63461 
> ) but by now I am in favor of the 
> approach that Ken suggested. This was doable for boost as there were a much 
> more limited number of ports affected (probably about one third or so), but 
> even there I presume that you spend a significant amount of time to implement 
> this (which is of course much appreciated). I am not saying that it cannot be 
> done and the advantage would be that things don’t need to be done en masse, 
> but the drawback is that chances are high that the transition will happen 
> very slowly and might never finish as probably many ports are “nomaintainer”. 
> 
> So the approach outlined by Ken (i.e., testing now moving ports that don’t 
> build to 1.1.1) and then make the change and fix stuff if it breaks seems the 
> faster way to get to the finish line. 


The approach Ken suggests is a minor variant of what I suggested. The only 
difference is what openssl version you make the ‘default’ in the new openssl 
PortGroup. I was suggesting starting with with making that 1.1.1, to minimise 
the disruption, but sure once that change is made and everything is OK we can 
try migrating that to 3.0.0 and see what happens.

You can see what version the shim port provides for boost here

https://github.com/macports/macports-ports/blob/master/devel/boost/Portfile 


see how the shim port version is bound to the same version as the default 
version in the PG. This way ports still using the shim, and those using the 
default PG version, are actually using the same binaries.

Chris

> 
> Renee
> 
> 
>> On Oct 2, 2021, at 3:06 PM, Ken Cunningham > > wrote:
>> 
>> That is exactly the approach that I don't find workable, Chris.
>> 
>> Specifically:
>> 
>> 1. every single port (think: rust, ghc, blah blah) will have to be 
>> needlessly managed to build against an alternate openssl location.
>> 2. there will be no default openssl ever in prefix.
>> 
>> So I am not on board for trying to implement that myself, but should that be 
>> the selected course I will watch from the sidelines as others proceed down 
>> that path.
>> 
>> K
>> 
>>> On Oct 2, 2021, at 12:02 PM, Chris Jones >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Personally I would strongly recommend following a migration path that does 
>>> not require an enmass change but allows ports to migrate  at their own 
>>> pace. I would personally very much recommend an approach similar to that we 
>>> used for boost recently
>>> 
>>> 1. Introduced a set of new isolated opensslXYZ ports that install specific 
>>> versions into isolated install areas under libexec.
>>> 2. Create a new portgroup that handles the confirmation of ports to pick 
>>> the openssl version they wish to use, with some default, and performs 
>>> various standard configurations for standard build systems such that for 
>>> most ports they work out the box with the new portgroup. For those that 
>>> don’t provide various proc methods that return the configured install paths 
>>> such that ports can used them to configure themselves as required.
>>> 3. Make the current openssl port a basic shim port that just installs sym 
>>> links into the primary install area to the default openssl version (for now 
>>> 1.1.1), so ports building against the current openssl port carry on working 
>>> just as they are now, but are redirected to use the same versioned 1.1.1 
>>> port as those using the PG.
>>> 
>>> Once this is in place, ports can be migrated to use the new PG individually 
>>> as and when we want.
>>> 
>>> Chris
>>> 
 On 2 Oct 2021, at 6:17 pm, Ken Cunningham >>> > wrote:
 
 
 openssl 3.0.0 is out, with a new and very favourable Apache-2 license that 
 will let many previously non-distributable ports become distributable.  
 However, there are 758 ports that indicate they link against openssl. That 
 is a daunting number of ports indeed.
 
 One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) 
 into subdirectories out of ${prefix}, have no default openssl installed in 
 $[prefix} directly, create a new PortGroup, openssl_select or some such, 
 add that PG to all 758 ports, default it to openssl 1.1.1, and then allow 
 people to gradually move the 758 ports to openssl 3.0.0 as they get to it.
 
 Although that is possible with suitable effort, I don’t think that is 
 workable for many reasons, the most obvious being that we would then have 
 to modify every single port in some way to find an openssl installed into 
 a non-default prefix. Creating the PG and 

Re: [NEW] www/unit

2021-09-29 Thread Christopher Jones

Rather than sending around attachments, it would be much more convenient for 
commenting if you could open a PR with the update. 

https://github.com/macports/macports-ports 


Chris

> On 29 Sep 2021, at 10:50 am, Sergey A. Osokin  wrote:
> 
> Hi,
> 
> updated version of the www/unit/Portfile is attached, here's the list
> of changes:
> 
> 1. multi-versions support for perl, python and ruby languages
> 2. added php module, commented out at the moment, PHP embed SAPI is
>   required to build Unit's PHP module, here's the
>   `./configure php .. ' output:
> 
>configuring PHP module
>checking for PHP ... found
> + PHP SAPI: [cli phpdbg]
>checking for PHP version ... not found
>checking for PHP embed SAPI ... not found
> 
> 3. added `--ld-opt' flag to the configure script
> 
> Please provide your comments, questions, suggestions.
> 
> Thank you.
> 
> -- 
> Sergey Osokin
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Haskell Stack Ports on Apple Silicon

2021-08-13 Thread Christopher Jones

That line is indeed limiting support to intel machines. If it works on arm add 
that to the list, or probably better just remove it and rely on the defaults.

Chris

> On 13 Aug 2021, at 1:55 pm, Steven Smith  wrote:
> 
> Is this line in the stack Portfile the issue? Ports (like pandoc) that are 
> built using stack depend on the stack port, and port stack says that x86_64 
> is supported, but not arm64. However, stack installs and runs just fine on an 
> M1 box.
> 
>> supported_archs x86_64
> 
> 
> https://github.com/macports/macports-ports/blob/4e94528cf34ba0ac86ee26d8f33b43351214/lang/stack/Portfile#L31
>  
> 
> 
> 
>> On Aug 13, 2021, at 5:27 AM, Ryan Schmidt > > wrote:
>> 
>> As far as I could tell, this applies to individual ports, but not to a 
>> port's dependencies. See:
>> 
>> https://trac.macports.org/ticket/63092 
>> 



smime.p7s
Description: S/MIME cryptographic signature


Re: upgrade outdated finals with can't read "epoch_installed": no such variable

2021-07-07 Thread Christopher Jones
thanks, that was it.

Chris

> On 7 Jul 2021, at 3:04 pm, Kurt Hindenburg  wrote:
> 
> Hi, I had the same issue on src master a few weeks ago;  Joshua fixed it on 
> June 26th.  
> 
> Kurt
> 
>> On Jul 7, 2021, at 9:21 AM, Christopher Jones  
>> wrote:
>> 
>> Hi,
>> 
>> My usual update procedure is now failing with
>> 
>> Oberon ~/Projects/MacPorts/ports > sudo port -v upgrade outdated 
>> Error: process_cmd failed: can't read "epoch_installed": no such variable
>> 
>> Any ideas what might be wrong here ? Started in last few days…
>> 
>> Chris
> 



smime.p7s
Description: S/MIME cryptographic signature


upgrade outdated finals with can't read "epoch_installed": no such variable

2021-07-07 Thread Christopher Jones
Hi,

My usual update procedure is now failing with

Oberon ~/Projects/MacPorts/ports > sudo port -v upgrade outdated 
Error: process_cmd failed: can't read "epoch_installed": no such variable

Any ideas what might be wrong here ? Started in last few days…

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: live check fetch failures

2021-06-19 Thread Christopher Jones
Hi Ken,

To get specific/technical, if you view the raw source for the first mail I sent 
in this tread, you will see it  has in its headers

Message-Id: 

thats the unique identifier for that mail. 

Then, if you look at Joshua’s reply, it has

References: 

Message-ID: 

Its that Reference line that Mail applications use to know that that mail is a 
reply to another mail, and exactly which mail it is. The then use these fields 
to correct thread all the messages in a discussion in the right way.

Now, if you look at your reply, it is missing the Reference field from its 
headers, even though it is a reply to another message.

Whatever emailer you are using is failing to add this.

cheers Chris
 

> On 19 Jun 2021, at 4:22 pm, Chris Jones  wrote:
> 
> Hi Ken,
> 
> I think you miss understand my point. I was not suggesting you where 
> subscribed to digest or anything.Your mails indeed come in for me as you send 
> them, just like everyone elses.
> 
> When you send an email to the macports mailing list, for some reason your 
> mailer screws up the header information in the mail such that if you are 
> replying to an on going thread my mailer at least (Apple Mail) fails to 
> recognise your mail as a reply to that thread, and thus does not correctly 
> include the message in that thread. It appears as if you have started a brand 
> new mail thread, such as when you compose a new mail rather than reply to 
> one. No one elses mails seem to have this problem, only yours.
> 
> Mailers use specific fields in the header of each mail to decide if a mail 
> belongs to a specifiv thread, and thus for some reason this information is 
> not being correctly set in your emials.
> 
> Cheers Chris 
> 
>> On 19 Jun 2021, at 4:02 pm, Ken Cunningham  
>> wrote:
>> 
>> I don't subscribe to any of MacPorts' email lists, or any others.
>> 
>> So any comments come in new. Didn't realize that was troubling anyone, but 
>> thank for letting me know it is.
>> 
>> K
>> 
>> On Saturday, June 19, 2021, Chris Jones > > wrote:
>> Hi Ken,
>> 
>> OT, but whenever you reply to a thread on these lists your emailer always 
>> seems to screw up the headers such that your reply starts a new thread. We 
>> get the messages but it makes following the discussion harder. I don’t know 
>> what emailer you use, but maybe you could look into it ?
>> 
>> Chris
>> 
>> > On 19 Jun 2021, at 3:43 pm, Ken Cunningham 
>> > mailto:ken.cunningham.web...@gmail.com>> 
>> > wrote:
>> > 
>> > Hey, maybe we will finally start bundling curl (there is a years-old 
>> > ticket about this, and someone already laid out the autotools changes to 
>> > do it).
>> > 
>> > I have been building MacPorts against a custom libcurl on most systems 
>> > 10.10 and older for years and years.
>> > 
>> > It's trivially simple to do, but to make it easy and resilient I keep a 
>> > "default" MacPorts installed in /opt/bootstrap and install curl in that, 
>> > then use that for the primary MP in /opt/local.
>> > 
>> > 
>> 



smime.p7s
Description: S/MIME cryptographic signature


Re: live check fetch failures

2021-06-19 Thread Christopher Jones


> On 19 Jun 2021, at 1:35 pm, Joshua Root  wrote:
> 
> On 2021-6-19 20:12 , Christopher Jones wrote:
>> A quick web search suggests this could be an issue with an older version of 
>> (lib)curl being used ? Does anyone have any insights into this ?
> 
> Certainly seems OK with the MacPorts version but not the system version. I 
> don't know any specifics, but it seems like maybe the system version defaults 
> to an older TLS protocol and this server doesn't allow it.
> 
> % /opt/local/bin/curl -Lo test.html https://downloads.xiph.org/releases/ogg/
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100   161  100   1610 0275  0 --:--:-- --:--:-- --:--:--   277
> 100 127360 127360 0   9545  0 --:--:--  0:00:01 --:--:-- 34144
> 
> % /usr/bin/curl -Lo test.html https://downloads.xiph.org/releases/ogg/
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert 
> protocol version
> 
> - Josh

I guess base doesn’t use macports curl, even if it is installed and first in 
PATH, as I do have it installed ? Or does base not invoke ‘curl’ at all but use 
some library instead ?

smime.p7s
Description: S/MIME cryptographic signature


Re: list ports that depend on a given port

2021-06-04 Thread Christopher Jones

> On 4 Jun 2021, at 8:14 pm, Gregory Anders  wrote:
> 
> port echo depends:'(^|\W)boost(\W|$)’

Thanks, that seems a bit better but it still matches port it should not. i.e. 
it matches 

py39-scikit-hep-hist   

which in fact only depends on

 > port deps py39-scikit-hep-hist
Full Name: py39-scikit-hep-hist @2.3.0_0
Fetch Dependencies:   git
Build Dependencies:   py39-setuptools
Library Dependencies: python39, py39-scikit-hep-boost-histogram
Test Dependencies:py39-pytest

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: list ports that depend on a given port

2021-06-04 Thread Christopher Jones
> 
> This exact question came up on IRC a while back. IIRC the query is 
> interpreted as a regular expression. So in order to get matches for only 
> dependents that begin with “boost” you could try
> 
> port echo depends '^boost'
> 
> (I’m not at my computer ATM so I can’t test this to verify.)
> 
> Greg

Thats for the suggestion, I had a similar thought but cannot seem to get that 
to work, e.g.

Oberon ~/Projects/MacPorts/ports > port echo depends:'^boost'
Oberon ~/Projects/MacPorts/ports > 

it matches nothing

Chris



smime.p7s
Description: S/MIME cryptographic signature


Re: list ports that depend on a given port

2021-06-04 Thread Christopher Jones


> On 4 Jun 2021, at 6:16 pm, atmail.dreamhost.com  wrote:
> 
> On Jun 4, 2021, 11:55 AM -0500, Christopher Jones , 
> wrote:
> Hi,
> 
> I want to get a list of all the ports that depend on a given port, boost. I 
> have been using this 
> 
> port echo depends:boost
> Oh so close:
> 
> port echo rdepends:boost

no, that has the same issue.

Chris

> as per 
> 
> https://guide.macports.org/chunked/using.common-tasks.html 
> <https://guide.macports.org/chunked/using.common-tasks.html>
> to do this, but just noticed it is not just include ports that depend on 
> ‘boost’, but ports that depend on any port which has boost in its name. e.g. 
> it is incorrectly listing  py39-scikit-hep-hist which does not depend on 
> boost, but py39-scikit-hep-boost-histogram.
> 
> The guide seems to infer the above should only give exact matches, so is this 
> a bug in base, or am I mis-understanding ?
> 
> cheers Chris
> 
> Marius
> __
> Marius Schamschula



smime.p7s
Description: S/MIME cryptographic signature


list ports that depend on a given port

2021-06-04 Thread Christopher Jones
Hi,

I want to get a list of all the ports that depend on a given port, boost. I 
have been using this 

port echo depends:boost

as per 

https://guide.macports.org/chunked/using.common-tasks.html 


to do this, but just noticed it is not just include ports that depend on 
‘boost’, but ports that depend on any port which has boost in its name. e.g. it 
is incorrectly listing  py39-scikit-hep-hist which does not depend on boost, 
but py39-scikit-hep-boost-histogram.

The guide seems to infer the above should only give exact matches, so is this a 
bug in base, or am I mis-understanding ?

cheers Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: mailutils: update to version 3.12 - building from command line but failing to build using macports

2021-05-28 Thread Christopher Jones
OK, then please open a ticket.

Can you also rerun your builds with the  

 --disable-silent-rules 

configure option appended, and compare the two builds to see what exactly is 
different between the two.

Chris

> On 28 May 2021, at 11:17 am, Giuseppe 'ferdy' Miceli  wrote:
> 
> ciao! thanks for the prompt reply.
> 
> i have checked and if i am not mistaken there is no ticket for this port.
> —
> 
> 
>> On 28 May 2021, at 12:13, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Hi,
>> 
>> Please check for open tickets against this port at
>> 
>> https://trac.macports.org/wiki/Tickets 
>> <https://trac.macports.org/wiki/Tickets>
>> 
>> and if there is none open one with the relevant information.
>> 
>> Chris
>> 
>>> On 28 May 2021, at 11:09 am, Giuseppe 'ferdy' Miceli >> <mailto:fe...@ferdy.it>> wrote:
>>> 
>>> Ciao,
>>> 
>>> as mentioned this afternoon on irc/rocket.chat i stumbled in a weird 
>>> behaviour which i am too newbie to understand and i would really appreciate 
>>> any help about.
>>> 
>>> context: couple of years ago, i submit the Portfile for GNU mailutils 3.6, 
>>> which is still in the repository, which i needed to build emacs from git.
>>> having changed hardware and osx version, i found out it doesn’t build on 
>>> osx 11.x (https://ports.macports.org/port/mailutils/summary 
>>> <https://ports.macports.org/port/mailutils/summary>), thus i thought to 
>>> update the portfile to the last version 3.12.
>>> 
>>> status: i can successfully build mailutils 3.12 on macOS 11.3.1 20E241 with 
>>> Xcode 12.5 12E262 from command line yet using macports (whist it configures 
>>> correctly with the same configure output summary), it fails to build.
>>> 
>>> all the relevant files are here: http://ferdy.it/mp-mailutils-3.12/ 
>>> <http://ferdy.it/mp-mailutils-3.12/> 
>>> 
>>> thank you very much in advance for any support you can provide.
>>> 
>>> cheers,
>>> —
>>> ferdy
>>> 
>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: mailutils: update to version 3.12 - building from command line but failing to build using macports

2021-05-28 Thread Christopher Jones
Hi,

Please check for open tickets against this port at

https://trac.macports.org/wiki/Tickets 

and if there is none open one with the relevant information.

Chris

> On 28 May 2021, at 11:09 am, Giuseppe 'ferdy' Miceli  wrote:
> 
>   Ciao,
> 
> as mentioned this afternoon on irc/rocket.chat i stumbled in a weird 
> behaviour which i am too newbie to understand and i would really appreciate 
> any help about.
> 
> context: couple of years ago, i submit the Portfile for GNU mailutils 3.6, 
> which is still in the repository, which i needed to build emacs from git.
> having changed hardware and osx version, i found out it doesn’t build on osx 
> 11.x (https://ports.macports.org/port/mailutils/summary), thus i thought to 
> update the portfile to the last version 3.12.
> 
> status: i can successfully build mailutils 3.12 on macOS 11.3.1 20E241 with 
> Xcode 12.5 12E262 from command line yet using macports (whist it configures 
> correctly with the same configure output summary), it fails to build.
> 
> all the relevant files are here: http://ferdy.it/mp-mailutils-3.12/ 
> 
> thank you very much in advance for any support you can provide.
> 
> cheers,
> —
> ferdy
> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Ports updated without maintainer notification?

2021-05-07 Thread Christopher Jones

> OSL in particular appears to be a problem on my machine. I've copied the 
> newer version of the portfile directly to my local machine, and tried to 
> build it, but it's failing to build because osl is indirectly dependent on 
> opencolorio (by way of openimageio), and apparently there's a new problem 
> with either opencolorio or openimageio:
> 
> :info:build dyld: Symbol not found: __ZN4YAML6detail9node_data12empty_scalarE
> :info:build   Referenced from: /opt/local/lib/libOpenColorIO.1.dylib
> :info:build   Expected in: /opt/local/lib/libyaml-cpp.0.6.dylib
> :info:build  in /opt/local/lib/libOpenColorIO.1.dylib
> :info:build /bin/sh: line 1: 34490 Trace/BPT trap: 5
> :info: build  
> opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/bin/oslc
>  -q 
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders/emitter.osl
>  -o 
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/src/shaders/emitter.oso


Did you also update all the other outdated ports on your ‘local’ machine, or 
did you just cherry-pick the updated osl from the current master ? 

If so it is really not a good idea to do that, as it means, as appears above, 
you could get an updated binary tarball install that was built against another 
updated port you do not have.

You should *always* keep all your ports updated and consistent.

if you run

> sudo port -d sync
> sudo port update outdated

does that help >

Just finally to note, there is nothing wrong with the current osl builds, they 
are available (apart from arm) down to 10.9

https://ports.macports.org/port/osl/summary 


Chris

> 
> -- 
> Jason Liu
> 
> 
> On Fri, May 7, 2021 at 7:32 AM Ryan Schmidt  > wrote:
> 
> 
> On May 7, 2021, at 01:59, Jason Liu wrote:
> 
> > I've run across a situation that has left me confused. I started updating 
> > some of the portfiles for which I'm the maintainer, and then I noticed that 
> > the portfiles seem to have already been updated in git. However, I can't 
> > find any PRs for such an update, and I was never notified that the ports 
> > for which I'm the maintainer was getting updated... usually, if someone 
> > submits a PR for a portfile for which I'm the maintainer, I get a 
> > notification through GitHub.
> 
> If your ports are marked openmaintainer, that gives permission to others to 
> make minor modifications to your ports without notifying you. Not all changes 
> happen via PRs; some are committed directly to master.
> 
> If there is an urgent issue that needs to be fixed in a port, someone else 
> might make that fix, even if the port is not marked openmaintainer.
> 
> If you let us know specifically which ports, we could take a look.
> 
> 
> > In addition, I have run a "port selfupdate" on my machine, and yet the 
> > MacPorts on my machine isn't seeing the new version of the port. Is 
> > something broken, either on my machine, or on GitHub?
> 
> If your MacPorts is configured to get ports via rsync, it can take an hour 
> for changes to propagate from git to the main rsync server, and up to a day 
> longer for changes to propagate from there to other rsync mirrors.



smime.p7s
Description: S/MIME cryptographic signature


Re: Ports updated without maintainer notification?

2021-05-07 Thread Christopher Jones
> 
> In addition, I have run a "port selfupdate" on my machine, and yet the 
> MacPorts on my machine isn't seeing the new version of the port. Is something 
> broken, either on my machine, or on GitHub?

If you aren’t already, I strongly recommend using a direct git clone of the 
ports tree rather than the default rsync’ed tarball. i.e.something like this in 
your sources.conf

~/Projects/MacPorts/ports > tail -3 /opt/local/etc/macports/sources.conf

#rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]
file:///Users/chris/Projects/MacPorts/ports [default]

where the path above points to where ever you choose to git clone the ports 
repo.

Once you have done this, ‘port sync’ automatically updates this via a git 
rebase rather than the rsync tarball.

e.g.

Oberon ~/Projects/MacPorts/ports > port -d sync
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/chris/Projects/MacPorts/ports
DEBUG: /opt/local/bin/git pull --rebase --autostash
DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git pull 
--rebase --autostash
Current branch master is up to date.
DEBUG: system: /opt/local/bin/portindex /Users/chris/Projects/MacPorts/ports
Creating port index in /Users/chris/Projects/MacPorts/ports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   26290


the -d option is very useful here as you get to see the git rebase, tother with 
the portindex update.

If you do this regularly, and before submitting any PR’s, it is basically 
impossible  to ‘miss’ updates to any ports.

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: OpenMPI Builds for MacOS 10.8 and Earlier, Targetting GCC

2021-05-04 Thread Christopher Jones
> 
> clang: warning: argument unused during compilation: '-I 
> /opt/local/include/LegacySupport'
> clang: warning: argument unused during compilation: '-I /opt/local/include'
> clang: warning: argument unused during compilation: '-I /opt/local/include'
> clang: warning: argument unused during compilation: '-I /usr/local/include'
> clang: warning: argument unused during compilation: '-I /usr/local/include'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/include/LegacySupport'
> clang: warning: argument unused during compilation: '-I .'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_openmpi/openmpi-gcc9/work/openmpi-4.1.0/opal/datatype'
> clang: warning: argument unused during compilation: '-I ../../opal/include'
> clang: warning: argument unused during compilation: '-I ../../ompi/include'
> clang: warning: argument unused during compilation: '-I ../../oshmem/include'
> clang: warning: argument unused during compilation: '-I 
> ../../opal/mca/hwloc/hwloc201/hwloc/include/private/autogen'
> clang: warning: argument unused during compilation: '-I 
> ../../opal/mca/hwloc/hwloc201/hwloc/include/hwloc/autogen'
> clang: warning: argument unused during compilation: '-I 
> ../../ompi/mpiext/cuda/c'
> clang: warning: argument unused during compilation: '-I ../..'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_openmpi/openmpi-gcc9/work/openmpi-4.1.0/opal/include'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_openmpi/openmpi-gcc9/work/openmpi-4.1.0/orte/include'
> clang: warning: argument unused during compilation: '-I ../../orte/include'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_openmpi/openmpi-gcc9/work/openmpi-4.1.0/ompi/include'
> clang: warning: argument unused during compilation: '-I 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_openmpi/openmpi-gcc9/work/openmpi-4.1.0/oshmem/include'
> 
> Given the includes for LegacySupport, is this being caused by that portgroup…?

No, not caused by the legacy support PG, as there are plenty of warnings above 
that are nothing to do with that, e.g. 

clang: warning: argument unused during compilation: '-I /usr/local/include'

smime.p7s
Description: S/MIME cryptographic signature


Re: M1 CPU features

2021-04-26 Thread Christopher Jones


> On 26 Apr 2021, at 6:28 pm, Jason Liu  wrote:
> 
> Thanks Arno :)
> 
> I'm kind of surprised that the M1 doesn't seem to support any SSE or AVX


Thats not at all surprising as those instruction sets are very much specific to 
X86_64 systems.

RISC processors, Arm, do have their own sets of SIMD instructions (e.g. Neon), 
but they are entirely different to those on X86_64 machines. 

Whether or these are supported on Apple’s M1 processors I have no idea.

Chris



> 
> Does "sysctl machdep.cpu.features" return anything?
> 
> -- 
> Jason Liu
> 
> 
> On Mon, Apr 26, 2021 at 1:23 PM Arno Hautala  > wrote:
> > On 26 Apr 2021, at 13:20, Jason Liu  > > wrote:
> > 
> > sysctl machdep.cpu.brand_string ; sysctl machdep.cpu | grep -i "avx\|sse”
> 
> $ sysctl machdep.cpu.brand_string ; sysctl machdep.cpu | grep -i "avx\|sse”
> machdep.cpu.brand_string: Apple M1
> 
> -- 
> arno  s  hautala/-|   a...@alum.wpi.edu 
> 
> pgp b2c9d448
> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: GitHub CI Jobs Failing During MacPorts Bootstrap

2021-04-26 Thread Christopher Jones

See the mail Ryan sent a few days back

The Bintray service will cease to exist on May 1. Our pull request CI checks 
rely on being able to download certain assets from Bintray, so unless we do 
something to fix this before then, our pull request CI checks will no longer 
work as of May 1.

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
 


looks like today is

"We will have some short service brown-outs to remind users about the services 
that are going away on May 1st. (Specific hours will be advertised in the 
Bintray status page.)”

Chris

> On 26 Apr 2021, at 5:35 pm, Christopher Nielsen  
> wrote:
> 
> I’m seeing the following failures in the CI jobs, during the MacPorts 
> Bootstrap phase:
> 
> Installing MacPorts
> Fetching...
> curl: (22) The requested URL returned error: 403 Forbidden
> curl: (22) The requested URL returned error: 403 Forbidden
> Error: Process completed with exit code 22.
> 
> Any thoughts/ideas…?



smime.p7s
Description: S/MIME cryptographic signature


Re: Publicizing MacPorts

2021-04-24 Thread Christopher Jones
Hi,

> On 24 Apr 2021, at 12:04 pm, Georges Martin  wrote:
> 
>> Le 22 avr. 2021 à 17:46, Steven Smith > > a écrit :
>> 
>> Another reason major news like M1 support must be announced.
> 
> 
> May I ask: how do we *define* "M1 support" in MacPorts? What are the 
> *metrics* used to support that statement?
> 
> - How does the MacPorts base "support the M1"? (I know I had to install it 
> from git then switch to the master branch for other reasons -- not a typical 
> user installation) 

port runs natively on M1 machines, and can build ports natively as well. Also, 
as far as I am aware the macOS11 pkg installer at 

https://www.macports.org/install.php

natively supports both intel and arm (disclaimer, I always build base from 
source myself, as I work with the a git checkout of base, so I haven’t actually 
run the above myself. I also am not lucky enough to have an M1 machine at this 
time). 

> - Is it when you set buildfromsource to always, build_arch to arm64 and 
> everything run smoothly afterwards? :-)

11_arm64 is support to the same degree as other OSes. The buildbots build for 
this arch, and when possible distribute binary installation tarballs for it. 
Always building from source is not required.

> 
> - How does a port "supports the M1"? Is it when it can be built, tested and 
> installed on a M1? Even if it's just compiled as x86_64 and running on 
> Rosetta? Or is it when it can be successfully built, tested and installed as 
> native and/or +universal  on both M1 and Intel?

I believe we consider support to be building natively for arm. 11_x86_64 and 
11_arm64 are separate platforms, just like other OSes are. Yes, you can if you 
want build ports universal, but just like on other OSes (eg. 32/64 bit, or 
intel/PPC) its port dependent if this works or not.

> 
> - How many ports are building on M1 today? (can a user do a search on 
> architecture on ports.macports.org ?) Before 
> installing, how can a user know if a port is building/testing successfully on 
> M1? (can he do a `port info --name --supported-archs` on a port?)

I am not sure if that site can give you an overall number of ports currently 
working on arm. But you can check the stats for individual ports. Note though, 
the info there is sometimes a little out of date unfortunately, e.g. there has 
recently been issues with the site not correctly important build logs from the 
builders.

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind) What if ports are not building because 
> major dependencies are not? (thinking of you, libffi) Is it documented 
> anywhere?

Not systematically/automatically. If someone has submitted a ticket you can 
search for it, e.g. starting at 

https://trac.macports.org/wiki/BigSurProblems 


> 
> - How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 
> call for help" for maintainers? Is there a M1 "Hot Problems" page for users 
> and maintainers like we have for macOS releases?

See above. Priority is mostly based on personal opinion. If someone cares 
enough about a port they will work on it.

The above is just my thoughts, not an ‘official stance’ in any way….

cheers Chris

> 
> 
> To be clear: I am **not** complaining. I switched to M1 a month and a half 
> ago and decided to contribute to the effort as much as I can: I installed 
> from git, set up buildfromsource to always and build_arch to arm64, then 
> switched to git master. After Ken's call for help on ICU, I set my variants 
> to +universal, recompiled everything that could be (but had to stop because 
> of libffi...).  I'm trying to natively build all the ports I was using on 
> Catalina/x86_64, I'm not there yet (today, py{38,39}-pandas do not build 
> anymore because of OpenBLAS...) and I am not complaining: it's part of the 
> game... :-)
> 
> 
> But: I'm afraid this "marketing" effort could backfire if we don't clearly 
> define what "M1 support" means and provide some metrics to maintainers and 
> users. As well as news sites.
> 
> 
> G.



smime.p7s
Description: S/MIME cryptographic signature


Re: emacs-app-devel build fail on master not detected by buildbot

2021-04-22 Thread Christopher Jones


> On 23 Apr 2021, at 3:48 am, Dan Ports  wrote:
> 
> On Thu, Apr 22, 2021 at 11:05:34PM +0900, Aaron Madlon-Kay wrote:
>> However it was rejected by the maintainer because he *wants* the current 
>> setup. If the port no longer builds because the referenced commit is more 
>> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
>> the depth or using a date-based strategy will just balloon the amount of 
>> data fetched.
> 
> To be clear, the problem here was that MacPorts uses the xcode-provided
> git, and certain older systems have a version of git that's too old to
> support the --shallow-since option, causing the port to break on
> systems where it's buildable today.
> 
> Now, those systems are pretty old at this point (IIRC, it was El
> Capitan and older) so perhaps that is worth reconsidering. We could
> also install and use our own version of git on older systems as we do
> for some other fetch/extract dependencies, but that would require a
> base update.

why a base update ? Just adding port:git as a build dep would do it, as port 
would then use that version instead.

Chris

> 
> Dan
> 
> -- 
> Dan R. K. Ports  https://drkp.net/



smime.p7s
Description: S/MIME cryptographic signature


Re: emacs-app-devel build fail on master not detected by buildbot

2021-04-22 Thread Christopher Jones


> On 22 Apr 2021, at 10:44 pm, Aaron Madlon-Kay  wrote:
> 
> > all it does is save a bit of bandwidth during the fetch
> 
> In the case of Emacs, it saves *gigabytes* during fetch.

OK, fair enough. I didn’t realise emacs had quite that much history ;)…

> 
> The depth restriction was a lifesaver when I worked on the nativecomp variant 
> a while back. 
> 
> -Aaron



smime.p7s
Description: S/MIME cryptographic signature


Re: emacs-app-devel build fail on master not detected by buildbot

2021-04-22 Thread Christopher Jones


> On 22 Apr 2021, at 10:04 pm, Christopher Jones  
> wrote:
> 
> 
> 
>> On 22 Apr 2021, at 9:59 pm, Nathaniel W Griswold  
>> wrote:
>> 
>> Thank you, Christopher.
>> 
>> Are you saying the date-style depth would be the right way forward? That 
>> seems fine and then the maintainers could either keep up or not. The current 
>> idea of using the breakage event as a signal to update the port file is 
>> kinda bad IMO.
> 
> I was simply stating that updating the port is anyway a good thing to do, and 
> would fix the current issue.
> 
> But yes, on the 1000 depth thing I agree that doesn’t seem like a great thing 
> to be doing in the port file, but thats the maintainers decision to change ….

… but changing it to 3000 doesn’t do anything but delay the inevitable… I would 
just remove it, as we don’t really do this sort of thing elsewhere where we 
perform git fetches, and as fas as I can see all it does is save a bit of 
bandwidth during the fetch…..

> 
> Chris
> 
> 
>> 
>> Nate
>> 
>>> On Apr 22, 2021, at 3:55 PM, Christopher Jones  
>>> wrote:
>>> 
>>> 
>>> 
>>>> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
>>>> 
>>>> I proposed in a past PR to emacs-app-devel to use a modern git flag that 
>>>> lets you specify a depth based on commit date. That would be the “real” 
>>>> solution in the direction you’re going.
>>>> 
>>>> However it was rejected by the maintainer because he *wants* the current 
>>>> setup. If the port no longer builds because the referenced commit is more 
>>>> than 1,000 commits in the past, then the port is ripe for a bump. 
>>>> Increasing the depth or using a date-based strategy will just balloon the 
>>>> amount of data fetched.
>>>> 
>>>> So rather than increasing the depth to 3,000, I recommend you either:
>>>> 
>>>> - bump the commit to a recent one, or
>>>> - file a Trac ticket so that someone else is prompted to do so
>>> 
>>> Indeed that is the correct way forward really…
>>> 
>>> https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
>>> 
>>>> 
>>>> Thanks,
>>>> Aaron
>>>> 
>>>> 
>>>>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  
>>>>> wrote:
>>>>> 
>>>>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>>>>> system (with variants +imagemagick, +rsvg). The build failed during my 
>>>>> last port upgrade outdated and i investigated why.
>>>>> 
>>>>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>>>>> exceeded 1000 new commits since the commit referenced by the Portfile 
>>>>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>>>>> the Portfile uses depth 1000, This means that port cannot check out that 
>>>>> commit in its local checkout and the port build fails on that step.
>>>>> 
>>>>> I thought about it a bit and i feel like if the logic to trigger a build 
>>>>> is already Portfile-aware this could be detected with a small change to 
>>>>> the system. If a git clone with a —depth=${val} is found in the Portfile 
>>>>> for a port or subport, then the build system could trigger a build 
>>>>> periodically at some rate that doesn’t stress the build setup too much. I 
>>>>> don’t know how many Portfiles have `git clone —depth=${val} ${repo}` 
>>>>> git.url values but if there aren’t that many you could trigger these 
>>>>> builds quite often.
>>>>> 
>>>>> I will increase the depth to 3000 for now and submit my updated Portfile.
>>>>> 
>>>>> Thank you
>>>>> 
>>>>> Nate
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: emacs-app-devel build fail on master not detected by buildbot

2021-04-22 Thread Christopher Jones


> On 22 Apr 2021, at 9:59 pm, Nathaniel W Griswold  wrote:
> 
> Thank you, Christopher.
> 
> Are you saying the date-style depth would be the right way forward? That 
> seems fine and then the maintainers could either keep up or not. The current 
> idea of using the breakage event as a signal to update the port file is kinda 
> bad IMO.

I was simply stating that updating the port is anyway a good thing to do, and 
would fix the current issue.

But yes, on the 1000 depth thing I agree that doesn’t seem like a great thing 
to be doing in the port file, but thats the maintainers decision to change ….

Chris


> 
> Nate
> 
>> On Apr 22, 2021, at 3:55 PM, Christopher Jones  
>> wrote:
>> 
>> 
>> 
>>> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
>>> 
>>> I proposed in a past PR to emacs-app-devel to use a modern git flag that 
>>> lets you specify a depth based on commit date. That would be the “real” 
>>> solution in the direction you’re going.
>>> 
>>> However it was rejected by the maintainer because he *wants* the current 
>>> setup. If the port no longer builds because the referenced commit is more 
>>> than 1,000 commits in the past, then the port is ripe for a bump. 
>>> Increasing the depth or using a date-based strategy will just balloon the 
>>> amount of data fetched.
>>> 
>>> So rather than increasing the depth to 3,000, I recommend you either:
>>> 
>>> - bump the commit to a recent one, or
>>> - file a Trac ticket so that someone else is prompted to do so
>> 
>> Indeed that is the correct way forward really…
>> 
>> https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
>> 
>>> 
>>> Thanks,
>>> Aaron
>>> 
>>> 
>>>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  
>>>> wrote:
>>>> 
>>>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>>>> system (with variants +imagemagick, +rsvg). The build failed during my 
>>>> last port upgrade outdated and i investigated why.
>>>> 
>>>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>>>> exceeded 1000 new commits since the commit referenced by the Portfile 
>>>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>>>> the Portfile uses depth 1000, This means that port cannot check out that 
>>>> commit in its local checkout and the port build fails on that step.
>>>> 
>>>> I thought about it a bit and i feel like if the logic to trigger a build 
>>>> is already Portfile-aware this could be detected with a small change to 
>>>> the system. If a git clone with a —depth=${val} is found in the Portfile 
>>>> for a port or subport, then the build system could trigger a build 
>>>> periodically at some rate that doesn’t stress the build setup too much. I 
>>>> don’t know how many Portfiles have `git clone —depth=${val} ${repo}` 
>>>> git.url values but if there aren’t that many you could trigger these 
>>>> builds quite often.
>>>> 
>>>> I will increase the depth to 3000 for now and submit my updated Portfile.
>>>> 
>>>> Thank you
>>>> 
>>>> Nate
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: emacs-app-devel build fail on master not detected by buildbot

2021-04-22 Thread Christopher Jones


> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
> 
> I proposed in a past PR to emacs-app-devel to use a modern git flag that lets 
> you specify a depth based on commit date. That would be the “real” solution 
> in the direction you’re going.
> 
> However it was rejected by the maintainer because he *wants* the current 
> setup. If the port no longer builds because the referenced commit is more 
> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
> the depth or using a date-based strategy will just balloon the amount of data 
> fetched.
> 
> So rather than increasing the depth to 3,000, I recommend you either:
> 
> - bump the commit to a recent one, or
> - file a Trac ticket so that someone else is prompted to do so

Indeed that is the correct way forward really…

https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
 


> 
> Thanks,
> Aaron
> 
> 
>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  wrote:
>> 
>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>> system (with variants +imagemagick, +rsvg). The build failed during my last 
>> port upgrade outdated and i investigated why.
>> 
>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>> exceeded 1000 new commits since the commit referenced by the Portfile 
>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>> the Portfile uses depth 1000, This means that port cannot check out that 
>> commit in its local checkout and the port build fails on that step.
>> 
>> I thought about it a bit and i feel like if the logic to trigger a build is 
>> already Portfile-aware this could be detected with a small change to the 
>> system. If a git clone with a —depth=${val} is found in the Portfile for a 
>> port or subport, then the build system could trigger a build periodically at 
>> some rate that doesn’t stress the build setup too much. I don’t know how 
>> many Portfiles have `git clone —depth=${val} ${repo}` git.url values but if 
>> there aren’t that many you could trigger these builds quite often.
>> 
>> I will increase the depth to 3000 for now and submit my updated Portfile.
>> 
>> Thank you
>> 
>> Nate
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Tcl help ...

2021-03-29 Thread Christopher Jones
Hi,

> On 29 Mar 2021, at 9:40 pm, Joshua Root  wrote:
> 
> On 2021-3-30 06:35 , Christopher Jones wrote:
>> Hi All,
>> Working on fixing a build issue and hitting a limit in my current 
>> understanding of Tcl… I am trying to set some new env vars in the build.env
>> set ldflags ${configure.ldflags}
>> build.env-append   GO_EXTLINK_ENABLED=1
>> build.env-append   GO_LDFLAGS='-extldflags\=$ldflags’
>> however, when the port in question using ${build.env} I get
>> DEBUG: system -W 
>> /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_codesearch/codesearch/work/gopath/src/github.com/google/codesearch:
>>  <http://github.com/google/codesearch:> 
>> GOPATH=/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_codesearch/codesearch/work/gopath
>>  GOARCH=amd64 GOOS=darwin CC=/usr/bin/clang CXX=/usr/bin/clang++ GOPROXY=off 
>> GO111MODULE=off C_INCLUDE_PATH=/opt/local/include/LegacySupport 
>> OBJC_INCLUDE_PATH=/opt/local/include/LegacySupport 
>> CPLUS_INCLUDE_PATH=/opt/local/include/LegacySupport 
>> OBJCPLUS_INCLUDE_PATH=/opt/local/include/LegacySupport GO_EXTLINK_ENABLED=1 
>> {GO_LDFLAGS='-extldflags=-L/opt/local/lib -Wl,-headerpad_max_install_names 
>> -lMacportsLegacySupport'} /opt/local/bin/go build cmd/cgrep/cgrep.go
>> sh: {GO_LDFLAGS=-extldflags=-L/opt/local/lib 
>> -Wl,-headerpad_max_install_names -lMacportsLegacySupport}:
> 
> That isn't a result of setting build.env. You must have added this to 
> build.args or similar.


I haven’t, but I think some ports do, see below.

> 
>> See how the second env var I define above is shown inside {} braces, which 
>> of course sh cannot parse.
>> I have tried numerous forms of how to set
>> build.env-append   GO_LDFLAGS='-extldflags\=$ldflags’
>> but they all have the same issue.
>> I suspect this is just my lack of really undertanding quoting in tcl, so I 
>> am hoping someone can tell me what I am doing wrong ?
> 
> Do you want literal single quotes in the value of the environment variable? 
> If so:
> 
> build.env-append   GO_LDFLAGS='-extldflags=${configure.ldflags}’
> 
> if not:
> 
> build.env-append   GO_LDFLAGS=-extldflags=${configure.ldflags}
> 
> The value of the *.env options never gets passed to a shell; the environment 
> variables are set directly by our code. The parsing is very simple, perhaps 
> deceptively so if you expect it to work like a shell. Each list element is 
> expected to contain a single assignment, with everything before the first '=' 
> used as the variable name, and everything after it used as the value to set 
> it to.

This is probably the problem, as there are a few ports that do pass it to a 
shell. see e.g.

https://github.com/macports/macports-ports/blob/749ad2787c30497020bdc4cca116eff9f09c800b/devel/codesearch/Portfile#L33
 
<https://github.com/macports/macports-ports/blob/749ad2787c30497020bdc4cca116eff9f09c800b/devel/codesearch/Portfile#L33>

All I have been trying to do is fix a few issues with go based builds, by 
adding some additional build env vars, on older systems, and I ran into the 
port above having problems. It appears to take build.env and directly pass it 
to a sell command, which from what you say should probably never be done. If 
thats the case I won’t worry about this one corner case port.

There are a handful of other ports that do something similar.

Chris


> 
> A corollary is that something like this won't (in general) work:
> 
> build.args-append ${build.env}
> 
> because build.args has to deal with shell quoting. There's also a second bug 
> in that line because it appends the entirety of build.env, which is a list, 
> as a single element. The {*} operator is essential when doing something like 
> this:
> 
> build.args foo bar
> destroot.args-append {*}${build.args}
> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Tcl help ...

2021-03-29 Thread Christopher Jones
Hi All,

Working on fixing a build issue and hitting a limit in my current understanding 
of Tcl… I am trying to set some new env vars in the build.env

set ldflags ${configure.ldflags}   
build.env-append   GO_EXTLINK_ENABLED=1
build.env-append   GO_LDFLAGS='-extldflags\=$ldflags’

however, when the port in question using ${build.env} I get

DEBUG: system -W 
/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_codesearch/codesearch/work/gopath/src/github.com/google/codesearch:
 
GOPATH=/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_codesearch/codesearch/work/gopath
 GOARCH=amd64 GOOS=darwin CC=/usr/bin/clang CXX=/usr/bin/clang++ GOPROXY=off 
GO111MODULE=off C_INCLUDE_PATH=/opt/local/include/LegacySupport 
OBJC_INCLUDE_PATH=/opt/local/include/LegacySupport 
CPLUS_INCLUDE_PATH=/opt/local/include/LegacySupport 
OBJCPLUS_INCLUDE_PATH=/opt/local/include/LegacySupport GO_EXTLINK_ENABLED=1 
{GO_LDFLAGS='-extldflags=-L/opt/local/lib -Wl,-headerpad_max_install_names 
-lMacportsLegacySupport'} /opt/local/bin/go build cmd/cgrep/cgrep.go
sh: {GO_LDFLAGS=-extldflags=-L/opt/local/lib -Wl,-headerpad_max_install_names 
-lMacportsLegacySupport}: 


See how the second env var I define above is shown inside {} braces, which of 
course sh cannot parse.

I have tried numerous forms of how to set

build.env-append   GO_LDFLAGS='-extldflags\=$ldflags’

but they all have the same issue.

I suspect this is just my lack of really undertanding quoting in tcl, so I am 
hoping someone can tell me what I am doing wrong ?

cheers Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: 11_x86 build - build failures due to 'no space on device'

2021-03-23 Thread Christopher Jones
Hi,

Great, thanks. As it happens I’ve been working on the bazel builds a bit, and 
discovered an option to disable local build caching. To quote the manual

--[no]use_action_cache 
<https://docs.bazel.build/versions/master/user-manual.html#flag--use_action_cache>
This option is enabled by default. If disabled, Bazel will not use its local 
action cache. Disabling the local action cache saves memory and disk space for 
clean builds, but will make incremental builds slower.

As the ‘incremental’ build option is not an issue for MacPorts, as builds are 
always started afresh with an empty cache, enabling this does not help us at 
all, and just uses resources. So I will turn this off.

Chris


> On 23 Mar 2021, at 4:04 pm, Ryan Schmidt  wrote:
> 
> On Feb 11, 2021, at 04:21, Christopher Jones wrote:
> 
>> I am seeing some large builds fail due to drive space issues
>> 
>> https://build.macports.org/builders/ports-11_x86_64-builder/builds/21466/steps/install-port/logs/stdio
>> error: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>>  can't write output file: 
>> bazel-out/host/bin/tensorflow/python/_pywrap_tfcompile.so.XX (No space 
>> left on device)
>> Could the space on the drive for this build be reviewed and purged / 
>> increased a bit ?
>> 
>> cheers Chris
> 
> I did make an additional change to mpbb to delete more unneeded ports:
> 
> https://trac.macports.org/ticket/57464#comment:12
> 
> And after updating to macOS 11.2.3 and Xcode 12.4 I deleted the simulator 
> directories again and I don't think they've come back.
> 
> We have 26GB free at the moment. So let's let the next builds of 
> py-tensorflow* run without interrupting them and see if they complete now.
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: github portgroup regex stopped matching

2021-03-20 Thread Christopher Jones
Hi,

Yes, it appears something changed here as I am seeing this for all ports that 
use the GitHub PG defaults. Seems fixed with

https://github.com/macports/macports-ports/commit/3f55e163e05ed4c0a7595bfb5b394e0766039c86
 


Chris

> On 19 Mar 2021, at 5:55 pm, Blair Zajac  wrote:
> 
> Maybe something has changed on github.com just now, however, a number of 
> ports using github now don’t match:
> 
> $ port livecheck protobuf3-cpp yarn timescaledb
> Error: cannot check if protobuf3-cpp was updated (regex didn't match)
> Error: cannot check if yarn was updated (regex didn't match)
> Error: cannot check if timescaledb was updated (regex didn't match)
> 
> Blair
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 4:34 pm, Joshua Root  wrote:
> 
> On 2020-12-16 02:53 , Christopher Jones wrote:
>> 
>> Suggestion for a fix...
>> 
>> <https://github.com/macports/macports-base/pull/221>
> 
> I don't think we can assume that users will always update the OS and
> Xcode in lockstep.

I am aware of that scenario, but I do not know how to handle that properly… 
That PR just makes things a bit better for those that do at least…

> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 4:06 pm, Joshua Root  wrote:
> 
> On 2020-12-16 03:03 , Christopher Jones wrote:
>> 
>> 
>>> On 15 Dec 2020, at 3:55 pm, Joshua Root  wrote:
>>> 
>>> On 2020-12-16 02:40 , Christopher Jones wrote:
>>>> 
>>>> Yes, you are right, ${configure.sdkroot} does indeed fallback to the
>>>> versionless SDK path, but there are other variables like
>>>> ${configure.sdk_version} which are set incorrectly now, and thus any
>>>> port explicitly using these will likely run into problems.
>>> 
>>> That option has always meant "this is the SDK version we are going to
>>> try to use", not "this is the SDK version we are definitely actually using".
>>> 
>>> Does `xcrun --sdk macosx11 --show-sdk-path` give a useful result, or do
>>> you have to specify an exact version?
>> 
>> you have to give the full version
>> 
>> Oberon ~/Projects/MacPorts/ports > xcrun --sdk macosx11 --show-sdk-path
>> xcodebuild: error: SDK "macosx11" cannot be located.
>> xcodebuild: error: SDK "macosx11" cannot be located.
>> xcrun: error: unable to lookup item 'Path' in SDK 'macosx11'
>> 
>> Oberon ~/Projects/MacPorts/ports > xcrun --sdk macosx11.1 --show-sdk-path
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
> 
> OK, thanks. And I suppose asking for macosx11.0 doesn't work either when
> all you have is 11.1.

I’m afraid not...

Oberon ~/Projects/MacPorts/ports > xcrun --sdk macosx11.0 --show-sdk-path
xcodebuild: error: SDK "macosx11.0" cannot be located.
xcodebuild: error: SDK "macosx11.0" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK ‘macosx11.0'


> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 3:55 pm, Joshua Root  wrote:
> 
> On 2020-12-16 02:40 , Christopher Jones wrote:
>> 
>> Yes, you are right, ${configure.sdkroot} does indeed fallback to the
>> versionless SDK path, but there are other variables like
>> ${configure.sdk_version} which are set incorrectly now, and thus any
>> port explicitly using these will likely run into problems.
> 
> That option has always meant "this is the SDK version we are going to
> try to use", not "this is the SDK version we are definitely actually using".
> 
> Does `xcrun --sdk macosx11 --show-sdk-path` give a useful result, or do
> you have to specify an exact version?

you have to give the full version

Oberon ~/Projects/MacPorts/ports > xcrun --sdk macosx11 --show-sdk-path
xcodebuild: error: SDK "macosx11" cannot be located.
xcodebuild: error: SDK "macosx11" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx11'

Oberon ~/Projects/MacPorts/ports > xcrun --sdk macosx11.1 --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk


> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 3:40 pm, Christopher Jones  
> wrote:
> 
> 
> 
>> On 15 Dec 2020, at 3:26 pm, Joshua Root > <mailto:j...@macports.org>> wrote:
>> 
>> On 2020-12-16 02:11 , Christopher Jones wrote:
>>> Hi All,
>>> 
>>> Just a warning that following the macOS 11.1 update (and corresponding
>>> Xcode 12.3) the SDK version has indeed changed from 11.0 to 11.1
>>> 
>>> Oberon ~/Projects/MacPorts/base > ls
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
>>> DriverKit20.2.sdkMacOSX.sdkMacOSX11.1.sdk
>>> Oberon ~/Projects/MacPorts/base > ls
>>> /Library/Developer/CommandLineTools/SDKs/  
>>> MacOSX.sdkMacOSX10.15.sdkMacOSX11.1.sdk
>>> 
>>> This causes problems, as there appears to be places in base that assume
>>> the SDk would always be 11.0 for all Big Sur, macOS11 releases, e.g.
>>> 
>>> 
>>> Oberon ~/Projects/MacPorts/ports > sudo port -s -v configure root6
>>> Warning: The macOS 11.0 SDK does not appear to be installed. Ports may
>>> not build correctly.
>>> Warning: You can install it as part of the Xcode Command Line Tools
>>> package by running `xcode-select --install’.
>>> 
>>> I haven’t checked in detail, but at least 
>>> 
>>> 
>>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>>>  
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157>
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>>>  
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157>>
>>> 
>>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>>  
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>>  
>>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>>
>>> 
>>> are two places that need fixing.
>>> 
>>> As I guess people running macOS11 are likely to update to 11.1, we
>>> should probably look to fixing this quite quickly.
>> 
>> Did you check what happens with the release or just master? It's not
>> quite as urgent as you might think in any case, since it will fall back
>> to MacOSX.sdk. It won't be a problem until that starts pointing to the
>> macOS 12 SDK.
> 
> Yes, you are right, ${configure.sdkroot} does indeed fallback to the 
> versionless SDK path, but there are other variables like 
> ${configure.sdk_version} which are set incorrectly now, and thus any port 
> explicitly using these will likely run into problems.

Suggestion for a fix...

https://github.com/macports/macports-base/pull/221 
<https://github.com/macports/macports-base/pull/221>

> 
>> 
>> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 3:26 pm, Joshua Root  wrote:
> 
> On 2020-12-16 02:11 , Christopher Jones wrote:
>> Hi All,
>> 
>> Just a warning that following the macOS 11.1 update (and corresponding
>> Xcode 12.3) the SDK version has indeed changed from 11.0 to 11.1
>> 
>> Oberon ~/Projects/MacPorts/base > ls
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
>> DriverKit20.2.sdkMacOSX.sdkMacOSX11.1.sdk
>> Oberon ~/Projects/MacPorts/base > ls
>> /Library/Developer/CommandLineTools/SDKs/  
>> MacOSX.sdkMacOSX10.15.sdkMacOSX11.1.sdk
>> 
>> This causes problems, as there appears to be places in base that assume
>> the SDk would always be 11.0 for all Big Sur, macOS11 releases, e.g.
>> 
>> 
>> Oberon ~/Projects/MacPorts/ports > sudo port -s -v configure root6
>> Warning: The macOS 11.0 SDK does not appear to be installed. Ports may
>> not build correctly.
>> Warning: You can install it as part of the Xcode Command Line Tools
>> package by running `xcode-select --install’.
>> 
>> I haven’t checked in detail, but at least 
>> 
>> 
>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157>>
>> 
>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>>
>> 
>> are two places that need fixing.
>> 
>> As I guess people running macOS11 are likely to update to 11.1, we
>> should probably look to fixing this quite quickly.
> 
> Did you check what happens with the release or just master? It's not
> quite as urgent as you might think in any case, since it will fall back
> to MacOSX.sdk. It won't be a problem until that starts pointing to the
> macOS 12 SDK.

Yes, you are right, ${configure.sdkroot} does indeed fallback to the 
versionless SDK path, but there are other variables like 
${configure.sdk_version} which are set incorrectly now, and thus any port 
explicitly using these will likely run into problems.

> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


Re: warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones


> On 15 Dec 2020, at 3:26 pm, Joshua Root  wrote:
> 
> On 2020-12-16 02:11 , Christopher Jones wrote:
>> Hi All,
>> 
>> Just a warning that following the macOS 11.1 update (and corresponding
>> Xcode 12.3) the SDK version has indeed changed from 11.0 to 11.1
>> 
>> Oberon ~/Projects/MacPorts/base > ls
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
>> DriverKit20.2.sdkMacOSX.sdkMacOSX11.1.sdk
>> Oberon ~/Projects/MacPorts/base > ls
>> /Library/Developer/CommandLineTools/SDKs/  
>> MacOSX.sdkMacOSX10.15.sdkMacOSX11.1.sdk
>> 
>> This causes problems, as there appears to be places in base that assume
>> the SDk would always be 11.0 for all Big Sur, macOS11 releases, e.g.
>> 
>> 
>> Oberon ~/Projects/MacPorts/ports > sudo port -s -v configure root6
>> Warning: The macOS 11.0 SDK does not appear to be installed. Ports may
>> not build correctly.
>> Warning: You can install it as part of the Xcode Command Line Tools
>> package by running `xcode-select --install’.
>> 
>> I haven’t checked in detail, but at least 
>> 
>> 
>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157>>
>> 
>> https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
>>  
>> <https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164>>
>> 
>> are two places that need fixing.
>> 
>> As I guess people running macOS11 are likely to update to 11.1, we
>> should probably look to fixing this quite quickly.
> 
> Did you check what happens with the release or just master? It's not
> quite as urgent as you might think in any case, since it will fall back
> to MacOSX.sdk. It won't be a problem until that starts pointing to the
> macOS 12 SDK.

I am running master. I haven’t tried the release, no.

Chris


> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature


warning - base incorrectly sets SDK version with macOS 11.1 / Xcode 12.3

2020-12-15 Thread Christopher Jones
Hi All,

Just a warning that following the macOS 11.1 update (and corresponding Xcode 
12.3) the SDK version has indeed changed from 11.0 to 11.1

Oberon ~/Projects/MacPorts/base > ls 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
DriverKit20.2.sdk   MacOSX.sdk  MacOSX11.1.sdk
Oberon ~/Projects/MacPorts/base > ls /Library/Developer/CommandLineTools/SDKs/  

MacOSX.sdk  MacOSX10.15.sdk MacOSX11.1.sdk

This causes problems, as there appears to be places in base that assume the SDk 
would always be 11.0 for all Big Sur, macOS11 releases, e.g.


Oberon ~/Projects/MacPorts/ports > sudo port -s -v configure root6
Warning: The macOS 11.0 SDK does not appear to be installed. Ports may not 
build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install’.

I haven’t checked in detail, but at least 


https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1157
 


https://github.com/macports/macports-base/blob/6c1396fd48a85c71cda98bc169f95561e07d1eda/src/macports1.0/macports.tcl#L1164
 


are two places that need fixing.

As I guess people running macOS11 are likely to update to 11.1, we should 
probably look to fixing this quite quickly.

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: Problem with libomp (was supertux)

2020-12-05 Thread Christopher Jones
Hi,

> On 5 Dec 2020, at 5:20 pm, Eric Borisch  wrote:
> 
> It's part of the LLVM project, and can be built at the same time 
> (-DLLVM_ENABLE_PROJECTS=openmp)as other tools; I think losing OpenMP support 
> for MP's clang by default is a step backwards, but most of the google results 
> for "clang openmp mac" point you to homebrew anyway, so perhaps it doesn't 
> matter.

No one is suggestion removing support for it, just a different way of 
packaging. To be honest having openmp as a port external to the LLVM ports has 
never made complete sense to me.

Currently the way the LLVM suite of ports are built is a bit peculiar and 
frankly a bit of a relic from SVN days and doesn’t use the LLVM_ENABLE_PROJECTS 
option to enable components. I believe Ken has looked into using this to 
simplify the builds, which I think would be good, and then enabling it would be 
a lot simpler than it currently is. Doing this for all the current LLVM 
versions is not really practical but perhaps for a future release (maybe an 
update to 11) we should move to this way of building thing, and then for that 
version remove the external libomp port dep. and just build it as part of the 
LLVM port itself.

Chris

> 
>  - Eric
> 
> On Sat, Dec 5, 2020 at 9:20 AM Chris Jones  > wrote:
> 
> 
>> On 5 Dec 2020, at 3:09 pm, Ken Cunningham > > wrote:
>> 
>> 
>> Good morning!
>> 
>> Chris - I suspected  it just needed the flag as well. There were some cmake 
>> rearrangements recently in libomp.
>> 
>> Eric - it would not be a big deal to have libomp something needs to be 
>> specified by the libomp PortGroup we either have or will need to make libomp 
>> work right. By having it as a build/lilb/run dep for clang, that means 
>> libomp has to be built with the oldest, frailest, least capable, least 
>> optimizing compiler macports has available, rather than the current compiler.
> 
> I agree with Ken here. If this does not really need to be a dep of clang 
> itself, but could be handled by the PG that handles MPI support, then we 
> should probably do this as minimising the deps that the clang ports have 
> makes things a lot simpler...
> 
> Chris
> 
>> 
>> K
>> 
>> 
>> 
>>> On Dec 5, 2020, at 6:55 AM, Eric Borisch >> > wrote:
>>> 
>>> I’m fine moving either way (leave as a separate port, pinned to older 
>>> versions on older systems, or build it as part of each clang 
>>> independently), but I think removing it as something that comes along with 
>>> MP’s clang would be a mistake.
>>> 
>>> Thanks,
>>>   - Eric
>>> 
>>> On Sat, Dec 5, 2020 at 7:04 AM Ken Cunningham 
>>> mailto:ken.cunningham.web...@gmail.com>> 
>>> wrote:
>>> the std:atomic thing was added in 2018, so something else seems funny... 
>>> clang-3.4 supports c++11 after all...
>>> 
>>> libomp probably should not be a dependency of clang at all
>>> 
>>> if it was separate from clang, it can be installed using the current 
>>> toolchain rathervthan block it
>>> 
>>> K
>>> 
>>> On Dec 5, 2020, at 04:56, Chris Jones >> > wrote:
>>> 
 Hi,
 
 The problem is simply the latest version uses std::atomic, which requires 
 c++11, and the usual fix of requesting this c++ standard in the port file 
 does not work due to the fact this port is a clang dependency, so using 
 clang as a fallback compiler is not possible.
 
 Note, the port already installs a different version for some systems, 
 those using libstdc++ 
 
 https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile
  
 
 
 So a relatively trivial fix would be to peg macOS 10.9 and older to the 
 last version that builds there, version 10.x. Probably a bit simpler than 
 having to deal with multiple libomp-X ports...
 
 Chris
 
> On 5 Dec 2020, at 5:57 am, Ken Cunningham 
>  > wrote:
> 
> 
>>> 
>> Attempting to install supertux complains on libomp.
>> 
>> Logfile shows compiler complaints about atomic and variable templates.
>> 
> I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 
> (and 10.6 and less).
> 
> This is not a big surprise — more likely a miracle that libomp up to 10.0 
> built without trouble on every system.
> 
> I will see if I can fix it — maybe I can — but even if so, libomp 12, 13, 
> or … will be unbuildable eventually.
> 
> So we’ll need to come up with a libomp plan. There is really no reason (I 
> think) that we can only have one libomp — we could install the one that 
> comes with each llvm and then it would always work, I think. Eg clang-9 
> would use libomp-9.
> 
> Anyway, that is for the future. until libomp is fixed, every clang is 
> dead 

Re: Problem with libomp (was supertux)

2020-12-05 Thread Christopher Jones

should be fixed with

https://github.com/macports/macports-ports/commit/d88607f06cd18787529edcd9f7fb6dd5c26114bd
 
<https://github.com/macports/macports-ports/commit/d88607f06cd18787529edcd9f7fb6dd5c26114bd>

built for for me in my 10.9 VM.

> On 5 Dec 2020, at 1:11 pm, Christopher Jones  wrote:
> 
> Hi,
> 
> c++ standard support in compilers isn’t always black and white. Compilers 
> often claim to support a given standard, but then fail in some corner cases..
> 
> That said, in this case looking at
> 
> https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/31506/steps/install-port/logs/stdio
>  
> <https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/31506/steps/install-port/logs/stdio>
> 
> I don’t see -std=c++11 in the list of compiler options, so as c++11 is not 
> default for this old OS, it might just be a case of adding this
> 
> configure.cxxflags-append -std=c++11
> 
> Chris
> 
>> On 5 Dec 2020, at 1:03 pm, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote:
>> 
>> the std:atomic thing was added in 2018, so something else seems funny... 
>> clang-3.4 supports c++11 after all...
>> 
>> libomp probably should not be a dependency of clang at all
>> 
>> if it was separate from clang, it can be installed using the current 
>> toolchain rathervthan block it
>> 
>> K
>> 
>> On Dec 5, 2020, at 04:56, Chris Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>>> Hi,
>>> 
>>> The problem is simply the latest version uses std::atomic, which requires 
>>> c++11, and the usual fix of requesting this c++ standard in the port file 
>>> does not work due to the fact this port is a clang dependency, so using 
>>> clang as a fallback compiler is not possible.
>>> 
>>> Note, the port already installs a different version for some systems, those 
>>> using libstdc++ 
>>> 
>>> https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile 
>>> <https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile>
>>> 
>>> So a relatively trivial fix would be to peg macOS 10.9 and older to the 
>>> last version that builds there, version 10.x. Probably a bit simpler than 
>>> having to deal with multiple libomp-X ports...
>>> 
>>> Chris
>>> 
>>>> On 5 Dec 2020, at 5:57 am, Ken Cunningham >>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>>> 
>>>> 
>>>>> 
>>>>> Attempting to install supertux complains on libomp.
>>>>> 
>>>>> Logfile shows compiler complaints about atomic and variable templates.
>>>>> 
>>>> I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 (and 
>>>> 10.6 and less).
>>>> 
>>>> This is not a big surprise — more likely a miracle that libomp up to 10.0 
>>>> built without trouble on every system.
>>>> 
>>>> I will see if I can fix it — maybe I can — but even if so, libomp 12, 13, 
>>>> or … will be unbuildable eventually.
>>>> 
>>>> So we’ll need to come up with a libomp plan. There is really no reason (I 
>>>> think) that we can only have one libomp — we could install the one that 
>>>> comes with each llvm and then it would always work, I think. Eg clang-9 
>>>> would use libomp-9.
>>>> 
>>>> Anyway, that is for the future. until libomp is fixed, every clang is dead 
>>>> on 10.8 and 10.9
>>>> 
>>>> BUT — good news. clang (and most everything else) doesn’t really need 
>>>> libomp anyway. I don’t even know why it is listed as a dependency, to be 
>>>> honest. Just delete from the clang portfile, and you’re good to go again, 
>>>> I think (haven’t tried it… but …).
>>>> 
>>>> Ken
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Problem with libomp (was supertux)

2020-12-05 Thread Christopher Jones
Hi,

c++ standard support in compilers isn’t always black and white. Compilers often 
claim to support a given standard, but then fail in some corner cases..

That said, in this case looking at

https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/31506/steps/install-port/logs/stdio
 


I don’t see -std=c++11 in the list of compiler options, so as c++11 is not 
default for this old OS, it might just be a case of adding this

configure.cxxflags-append -std=c++11

Chris

> On 5 Dec 2020, at 1:03 pm, Ken Cunningham  
> wrote:
> 
> the std:atomic thing was added in 2018, so something else seems funny... 
> clang-3.4 supports c++11 after all...
> 
> libomp probably should not be a dependency of clang at all
> 
> if it was separate from clang, it can be installed using the current 
> toolchain rathervthan block it
> 
> K
> 
> On Dec 5, 2020, at 04:56, Chris Jones  > wrote:
> 
>> Hi,
>> 
>> The problem is simply the latest version uses std::atomic, which requires 
>> c++11, and the usual fix of requesting this c++ standard in the port file 
>> does not work due to the fact this port is a clang dependency, so using 
>> clang as a fallback compiler is not possible.
>> 
>> Note, the port already installs a different version for some systems, those 
>> using libstdc++ 
>> 
>> https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile 
>> 
>> 
>> So a relatively trivial fix would be to peg macOS 10.9 and older to the last 
>> version that builds there, version 10.x. Probably a bit simpler than having 
>> to deal with multiple libomp-X ports...
>> 
>> Chris
>> 
>>> On 5 Dec 2020, at 5:57 am, Ken Cunningham >> > wrote:
>>> 
>>> 
 
 Attempting to install supertux complains on libomp.
 
 Logfile shows compiler complaints about atomic and variable templates.
 
>>> I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 (and 
>>> 10.6 and less).
>>> 
>>> This is not a big surprise — more likely a miracle that libomp up to 10.0 
>>> built without trouble on every system.
>>> 
>>> I will see if I can fix it — maybe I can — but even if so, libomp 12, 13, 
>>> or … will be unbuildable eventually.
>>> 
>>> So we’ll need to come up with a libomp plan. There is really no reason (I 
>>> think) that we can only have one libomp — we could install the one that 
>>> comes with each llvm and then it would always work, I think. Eg clang-9 
>>> would use libomp-9.
>>> 
>>> Anyway, that is for the future. until libomp is fixed, every clang is dead 
>>> on 10.8 and 10.9
>>> 
>>> BUT — good news. clang (and most everything else) doesn’t really need 
>>> libomp anyway. I don’t even know why it is listed as a dependency, to be 
>>> honest. Just delete from the clang portfile, and you’re good to go again, I 
>>> think (haven’t tried it… but …).
>>> 
>>> Ken



smime.p7s
Description: S/MIME cryptographic signature


Re: homebrew moving to /opt/homebrew

2020-11-18 Thread Christopher Jones

The young learn, eventually...

> On 18 Nov 2020, at 3:12 pm, Ken Cunningham  
> wrote:
> 
> As of Apple silicon, apparently.
> 
> https://github.com/Homebrew/brew/issues/7857 
> 
> 
> Being in /usr/local was always said to be homebrew's biggest, no-sudo 
> advantage...
> 
> So those of you who said previously that they would eventually figure out 
> they would have to move to /opt look to have been right on the button...
> 
> Ken
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Problems with Darwin 20 tarballs ?

2020-11-16 Thread Christopher Jones


> On 17 Nov 2020, at 2:18 am, Zero King  wrote:
> 
> On Tue, Nov 17, 2020 at 02:09:11AM +, Christopher Jones wrote:
>> Hi,
>> Is anyone else having problems installing tarballs from the new Darwin20 
>> builedbot ?
> 
> Yes, see https://trac.macports.org/ticket/61500 
> <https://trac.macports.org/ticket/61500>.
> 
>> Oberon-macOS-11 ~/Projects/MacPorts/ports > sudo port -v install llvm-9.0
>> --->  Computing dependencies for llvm-9.0.
>> --->  Fetching archive for llvm-9.0
>> Warning: Your DNS servers incorrectly claim to know the address of 
>> nonexistent hosts. This may cause checksum mismatches for some ports. See 
>> this page for more information: 
>> <https://trac.macports.org/wiki/MisbehavingServers>
>> --->  llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 doesn't seem to exist in 
>> /opt/local/var/macports/incoming/verified
>> --->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 from 
>> https://packages.macports.org/llvm-9.0
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100 45.9M  100 45.9M0 0  22.5M  0  0:00:02  0:00:02 --:--:-- 
>> 22.5M
>> --->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2.rmd160 from 
>> https://packages.macports.org/llvm-9.0
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100   512  100   5120 0  23272  0 --:--:-- --:--:-- --:--:-- 
>> 23272
>> --->  Installing llvm-9.0 @9.0.1_1
>> tar: ./+CONTENTS: Not found in archive
>> tar: Error exit delayed from previous errors.
>> Error: Failed to install llvm-9.0: child process exited abnormally
>> Error: See 
>> /opt/local/var/macports/logs/_Users_chris_Projects_MacPorts_ports_lang_llvm-9.0/llvm-9.0/main.log
>>  for details.
>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>> Error: Processing of port llvm-9.0 failed
>> Whats also a little odd is if I go to
>> 
>> https://packages.macports.org/llvm-9.0/ 
>> <https://packages.macports.org/llvm-9.0/> 
>> <https://packages.macports.org/llvm-9.0/ 
>> <https://packages.macports.org/llvm-9.0/>>
>> 
>> I cannot actually see the tarball just downloaded ?
> 
> It was purged by Ryan.

right, but how come then port can still fetch it from 
https://packages.macports.org/llvm-9.0 <https://packages.macports.org/llvm-9.0>

something must still be caching it somewhere..


>> Chris



smime.p7s
Description: S/MIME cryptographic signature


Problems with Darwin 20 tarballs ?

2020-11-16 Thread Christopher Jones
Hi,
Is anyone else having problems installing tarballs from the new Darwin20 
builedbot ?
Oberon-macOS-11 ~/Projects/MacPorts/ports > sudo port -v install llvm-9.0
--->  Computing dependencies for llvm-9.0.
--->  Fetching archive for llvm-9.0
Warning: Your DNS servers incorrectly claim to know the address of nonexistent 
hosts. This may cause checksum mismatches for some ports. See this page for 
more information: 
--->  llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 doesn't seem to exist in 
/opt/local/var/macports/incoming/verified
--->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 from 
https://packages.macports.org/llvm-9.0
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 45.9M  100 45.9M0 0  22.5M  0  0:00:02  0:00:02 --:--:-- 22.5M
--->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2.rmd160 from 
https://packages.macports.org/llvm-9.0
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   512  100   5120 0  23272  0 --:--:-- --:--:-- --:--:-- 23272
--->  Installing llvm-9.0 @9.0.1_1
tar: ./+CONTENTS: Not found in archive
tar: Error exit delayed from previous errors.
Error: Failed to install llvm-9.0: child process exited abnormally
Error: See 
/opt/local/var/macports/logs/_Users_chris_Projects_MacPorts_ports_lang_llvm-9.0/llvm-9.0/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port llvm-9.0 failed
Whats also a little odd is if I go to

https://packages.macports.org/llvm-9.0/ 


I cannot actually see the tarball just downloaded ?

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

2020-11-13 Thread Christopher Jones
Installed just fine for me here on mac OS 11.0.1 …. so shrug…

Chris

> On 13 Nov 2020, at 10:43 pm, Nils Breunese  wrote:
> 
> Hello,
> 
> Every time MacPorts tries to install the p5.28-locale-gettext port on my Big 
> Sur 11.0.1 machine, the OS crashes and the Problem Reporter shows the crash 
> report below. Does installing this port work for others on Big Sur 11.0.1? 
> Any ideas?
> 
> Nils Breunese.
> 
> ——
> 
> panic(cpu 8 caller 0xff8003753a13): userspace watchdog timeout: no 
> successful checkins from com.apple.remoted in 180 seconds
> service returned not alive with context : unresponsive work processor(s): 
> remoted heartbeat on bridge 
> service: com.apple.logd, total successful checkins since load (800 seconds 
> ago): 81, last successful checkin: 0 seconds ago
> service: com.apple.WindowServer, total successful checkins since load (770 
> seconds ago): 77, last successful checkin: 0 seconds ago
> service: com.apple.remoted, total successful checkins since load (800 seconds 
> ago): 61, last successful checkin: 180 seconds ago
> 
> Backtrace (CPU 8), Frame : Return Address
> 0xffa0af363670 : 0xff80004bc66d 
> 0xffa0af3636c0 : 0xff80005ff073 
> 0xffa0af363700 : 0xff80005ef6aa 
> 0xffa0af363750 : 0xff8000461a2f 
> 0xffa0af363770 : 0xff80004bbf0d 
> 0xffa0af363890 : 0xff80004bc1f8 
> 0xffa0af363900 : 0xff8000cbee84 
> 0xffa0af363970 : 0xff8003753a13 
> 0xffa0af363980 : 0xff80037536ba 
> 0xffa0af3639a0 : 0xff8000c460ee 
> 0xffa0af3639f0 : 0xff8003752b0a 
> 0xffa0af363b20 : 0xff8000c502bb 
> 0xffa0af363c80 : 0xff80005aaa61 
> 0xffa0af363d90 : 0xff80004c1d77 
> 0xffa0af363e00 : 0xff80004985d5 
> 0xffa0af363e60 : 0xff80004afb82 
> 0xffa0af363ef0 : 0xff80005d3823 
> 0xffa0af363fa0 : 0xff8000462216 
>  Kernel Extensions in backtrace:
> 
> com.apple.driver.watchdog(1.0)[7948A279-A8B8-3650-AFBF-B1E3EB68942A]@0xff8003752000->0xff8003753fff
> 
> Process name corresponding to current thread: watchdogd
> Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
> 
> Mac OS version:
> 20B29
> 
> Kernel version:
> Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; 
> root:xnu-7195.50.7~2/RELEASE_X86_64
> Kernel UUID: 84C6DC45-6B02-335F-9439-5D2A9BC385A4
> KernelCache slide: 0x0020
> KernelCache base:  0xff800040
> Kernel slide:  0x0021
> Kernel text base:  0xff800041
> __HIB  text base: 0xff800030
> System model name: MacBookPro16,1 (Mac-E1008331FDC96864)
> System shutdown begun: NO
> Hibernation exit count: 0
> 
> System uptime in nanoseconds: 814426222551
> Last Sleep:   absolute   base_tsc  base_nano
>  Uptime  : 0x00bd9f95f9ce
>  Sleep   : 0x 0x 0x
>  Wake: 0x 0x000df35d5870 0x
> last started kext at 22473489130: >AudioAUUC  1.70 (addr 0xff7f9fbd5000, 
> size 12288)
> last stopped kext at 288586604576: >usb.!UHostPacketFilter1.0 (addr 
> 0xff8003246000, size 8192)
> loaded kexts:
> com.cisco.kext.acsock 4.8.0
>> AudioAUUC1.70
>> !ATopCaseHIDEventDriver  4000.27
>> !AHIDALSService  1
>> AGPM 119
>> !APlatformEnabler2.7.0d0
>> X86PlatformShim  1.0.0
> @filesystems.autofs   3.0
> @fileutil 20.036.15
> @kext.AMDRadeonX6000  4.0.0
> @kext.AMDRadeonServiceManager 4.0.0
>> !AUpstreamUserClient 3.6.8
>> !AGraphicsDevicePolicy   6.1.27
>> AGDCBacklightControl 6.1.27
>> !A!IKBLGraphics  16.0.0
> @AGDCPluginDisplayMetrics 6.1.27
>> pmtelemetry  1
>> LuaHardwareAccess1.0.16
> |IOUserEthernet   1.0.1
>> !AMCCSControl1.14
>> !ABridgeAudio!C  100.2
> |IO!BSerialManager8.0.1f5
>> !AGFXHDA 100.1.431
>> !A!ICFLGraphicsFramebuffer   16.0.0
>> !AMuxControl26.1.27
>> !A!IPCHPMC   2.0.1
> @Dont_Steal_Mac_OS_X  7.0.0
>> !AHV 1
>> !ADiskImages21
>> BridgeAudioCommunication 100.2
>> !AAVEBridge  6.1
>> !AThunderboltIP  4.0.3
>> !A!ISlowAdaptiveClocking 4.0.0
>> usb.!UHostBillboardDevice1.0
>> BCMWLANFirmware4378.Hashstore1
>> BCMWLANFirmware4377.Hashstore1
>> BCMWLANFirmware4364.Hashstore1
>> BCMWLANFirmware4355.Hashstore1
>> !ABCMWLANBusInterfacePCIeMac 1
> @filesystems.tmpfs1
> @filesystems.hfs.kext 556.41.1
> @BootCache40
> @filesystems.apfs 1677.50.1
> @!AFSCompression.!AFSCompressionTypeZlib  1.0.0
> @!AFSCompression.!AFSCompressionTypeDataless  1.0.0d1
> @private.KextAudit1.0
>> !ASmartBatteryManager161.0.0
>> !AACPIButtons6.1
>> !ASMBIOS 2.1
>> !AACPIEC 6.1
>> !AAPIC   1.7
> @!ASystemPolicy   2.0.0
> @nke.applicationfirewall  310
> |IOKitRegistryCompatibility   1
> |EndpointSecurity 1
>> !AHS!BDriver 4000.27
>> IO!BHIDDriver8.0.1f5
>> !AHIDKeyboard222
>> 

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

2020-10-23 Thread Christopher Jones
Hi,

This file has annoyed me on a number of occasions. I work with a full git 
checkout and tend to use utilities like ‘git grep’ a lot, and this file often 
gets a hit in those searches, and due to its size spams the results rendering 
it almost impossible to view any after that file.

One option, if the port still needs to patch these rules, would be to store it 
compressed in git, and uncompress it on the fly during patching

https://github.com/macports/macports-ports/blob/6d838b9cdbde1c2704da396a95ab99222b8db2c6/www/libhttpseverywhere/Portfile#L50
 


Chris

> On 23 Oct 2020, at 2:52 am, Ken Cunningham  
> wrote:
> 
> The ports tree is getting bloaty as it is, but is is fairly egregious bloat…
> 
> ls -la
> total 13680
> drwxr-xr-x  5 root  wheel  160 22 Oct 18:46 .
> drwxr-xr-x  4 root  wheel  128 23 Aug 15:39 ..
> -rw-r--r--  1 root  wheel  6992700 23 Aug 15:39 default.rulesets
> -rw-r--r--  1 root  wheel  664 23 Aug 15:39 
> patch-fix-typelib-generation.diff
> -rw-r--r--  1 root  wheel  910 28 Jun 07:30 patch-vala-0.42.diff
> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: port "cask" -- installing prebuilt binaries

2020-08-06 Thread Christopher Jones


> On 6 Aug 2020, at 8:02 pm, Ken Cunningham  
> wrote:
> 
> category-only identifier is
> 
> less clear and less obvious
> harder to remember how to search for
> name conflicts with a non-binary version (eg for newer systems that can build 
> it)
> 
> so far, name-suffix is winning on all fronts...with no downsides yet.

For you maybe…

For me, the port category is clearly the better approach. I fail to see how

port echo category:binary and installed

is any harder to run than

port -v installed | grep binar

If anything, your suggestion involves the use of a pipe and secondary command 
(grep) so could be argued to be more complicated.

FWIW, I dislike the proposal of using the port name here, if we are going to do 
this, when there is already a mechanism in macports (the categories) for 
exactly this use case.

Chris

> 
> K



smime.p7s
Description: S/MIME cryptographic signature


Re: Help with UsingTheRightCompiler

2020-07-24 Thread Christopher Jones

You should be setting CXX, not CC, to define the c++ compiler to use…

Chris

> On 24 Jul 2020, at 7:47 pm, Frank Schima  wrote:
> 
> Hi Ken,
> 
>> On Jul 23, 2020, at 10:38 PM, Ken Cunningham 
>> mailto:ken.cunningham.web...@gmail.com>> 
>> wrote:
>> 
>>> You have to use clang++ if you are calling in c++ includes.
>>> 
>>> Then it will work.
>> 
>> Having read over the other comments, and in case that wan’t clear — if you 
>> use /usr/bin/clang++ your build will automatically find the c++ includes, 
>> and you don’t need to do any of those suggestions with -isysroot or SDKROOT 
>> or xcrun etc.
>> It is presently failing because /usr/bin/clang does not automatically add 
>> the search path for the c++ includes, and  is only in the c++ 
>> includes, not in the c includes.
> 
> Thanks for the advice. I’m having  problems implementing it though. 
> 
> I tried setting CC like so:
> 
> build.args  CC="${configure.cpp} [get_canonical_archflags cc]"
> 
> But it still does not work. Here is the resulting compiler used:
> 
> /usr/bin/cpp -arch x86_64 -Wall -g -O2 -I/opt/X11/include -DPNG -DPNG15 
> -Wno-write-strings -Wno-overflow -c ascii.c
> 
> Also, I don’t see clang++ in the compilers listed in 
> https://trac.macports.org/wiki/UsingTheRightCompiler 
> . 
> 
> So I hacked it by using:
> 
> build.args  CC="/usr/bin/clang++"
> 
> And it builds! But that does not seem to be the Macports way. How can I set 
> the compiler with Macports?
> 
> Thoughts?
> 
> 
> Cheers!
> Frank



smime.p7s
Description: S/MIME cryptographic signature


Re: Help with UsingTheRightCompiler

2020-07-23 Thread Christopher Jones

> Mojave 10.14 and later doesn't provide /usr/include anymore. System headers 
> like  are only in the SDK now. Note the -isystem flag with the 
> path to the SDK isn't in that compile line. MacPorts put that flag into 
> CFLAGS, CXXFLAGS, CPPFLAGS, and a comparable one into LDFLAGS for you, so 
> this shows you that your build system isn't respecting those variables yet. 
> Read the makefile portgroup to see if any of the options it provides can help 
> you. Read your project's Makefile to see how it expects those values to be 
> supplied. The Makefile may not provide a way. If not, you'll have to patch it 
> to make it possible.

clang (and gcc) both respect the SDKROOT env. var. This is an easy way to by  
the right SDK root.

Add this to your login profile

export SDKROOT=`xcrun --show-sdk-path`

Note. you can also use xcrun directly with clang/gcc to do the same

 > xcrun clang …..

but that requires the build commands to be patched, whereas setting SDKROOT, 
assuming the build system does not actively remove it, should work.

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: Deepmind Tree Bazel Build Portfile Help Request

2020-07-06 Thread Christopher Jones


> On 6 Jul 2020, at 5:22 pm, Steven Smith  wrote:
> 
> I am not using --max_idle_secs=60.
> 
> Also, neither is port py-tensorflow

yes, it does. See

https://github.com/macports/macports-ports/blob/master/python/py-tensorflow/Portfile#L187
 
<https://github.com/macports/macports-ports/blob/master/python/py-tensorflow/Portfile#L187>

Chris

> nor the repo tensorflow/tensorflow itself, nor any other MacPorts repo, and 
> these all build fine without this option:
> https://github.com/macports/macports-ports/blob/master/python/py-tensorflow/Portfile
>  
> <https://github.com/macports/macports-ports/blob/master/python/py-tensorflow/Portfile>
> https://github.com/tensorflow/tensorflow/search?q=max_idle_secs=Code 
> <https://github.com/tensorflow/tensorflow/search?q=max_idle_secs=Code>
> https://github.com/macports/macports-ports/search?q=max_idle_secs=Code 
> <https://github.com/macports/macports-ports/search?q=max_idle_secs=Code>
> 
> I’m happy to try adding it, but my expectation is that some other issue is 
> causing the hang when run within the port command (the build itself only 
> takes few seconds when run by hand).
> 
> I must also add the bazel-based builds tensorflow-probability and others, so 
> getting a robust bazel build approach would be very helpful and useful.
> 
> Steve
> 
> 
>> On Jul 6, 2020, at 11:57 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Hi,
>> 
>> Are you using this option 
>> 
>> bazel --max_idle_secs=60
>> 
>> when building with bazel ?
>> 
>> Bazel builds start an underlying ’server’ process, that by default hangs 
>> around for 3600 secs (yes, 1hour) before disappearing. Without the above 
>> your build will hang around waiting for this to happen…
>> 
>> Chris
>> 
>>> On 6 Jul 2020, at 2:57 am, Steven Smith >> <mailto:steve.t.sm...@gmail.com>> wrote:
>>> 
>>> I’m preparing a PR for the Google Magenta project 
>>> <https://magenta.tensorflow.org <https://magenta.tensorflow.org/>>, and am 
>>> running into this issue for the “dm-tree” dependent package with the bazel 
>>> build.
>>> 
>>> The command `port -dv test py37-dm-tree` hangs during the bazel build.
>>> I can’t even Ctl-C out of the process—it requires a full ps command then a 
>>> kill -9 to shut down everything.
>>> However, running the build by hand works:
>>> sudo -u macports bash -c 
>>> '/opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 
>>> setup.py --no-user-cfg build'
>>> 
>>> Any pointers or help would be appreciated. I’ve never used bazel, so I 
>>> copied a bunch of relevant stuff from the py-tensorflow Portfile and 
>>> attempted a few obvious hacks, but nothing changes the underlying problem 
>>> of a hung port command.
>>> 
>>> Relevant files:
>>> 
>>> https://github.com/deepmind/tree/blob/master/setup.py 
>>> <https://github.com/deepmind/tree/blob/master/setup.py>
>>> https://github.com/deepmind/tree/blob/master/bazel/BUILD 
>>> <https://github.com/deepmind/tree/blob/master/bazel/BUILD>
>>> 
>>> Bazel process (hung when called from MacPorts):
>>> 
>>>> bazel(tree-0.1.6.20200524) -XX:+HeapDumpOnOutOfMemoryError 
>>>> -XX:HeapDumpPath=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a
>>>>  -Xverify:none 
>>>> -Djava.util.logging.config.file=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a/javalog.properties
>>>>  
>>>> -Dcom.google.devtools.build.lib.util.LogHandlerQuerier.class=com.google.devtools.build.lib.util.SimpleLogHandler$HandlerQuerier
>>>>  -XX:-MaxFDLimit 
>>>> -Djava.library.path=/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/embedded_tools/tools/objc:/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/
>>>>  -Dfile.encoding=ISO-8859-1 -jar 
>>>> /var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/A-server.jar 
>>>> --max_idle_secs=10800 --noshutdown_on_low_sys_mem 
>>>> --connect_timeout_secs=30 --output_user_root=/var/tmp/_bazel_root 
>>>> --install_base=/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905
>>>>  --install_md5=e3bdf1a360e6d6cc38da72ec898bd905 
>>>> --output_base=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a
>>>>  
>>>> --workspace_directory=/opt/local/var/macports/build/_opt_local_ports_python_py-dm-tree/py37-dm-tree/work/tree-0.1.6.2020052

Re: Deepmind Tree Bazel Build Portfile Help Request

2020-07-06 Thread Christopher Jones
Hi,

Are you using this option 

bazel --max_idle_secs=60

when building with bazel ?

Bazel builds start an underlying ’server’ process, that by default hangs around 
for 3600 secs (yes, 1hour) before disappearing. Without the above your build 
will hang around waiting for this to happen…

Chris

> On 6 Jul 2020, at 2:57 am, Steven Smith  wrote:
> 
> I’m preparing a PR for the Google Magenta project 
> >, and am 
> running into this issue for the “dm-tree” dependent package with the bazel 
> build.
> 
> The command `port -dv test py37-dm-tree` hangs during the bazel build.
> I can’t even Ctl-C out of the process—it requires a full ps command then a 
> kill -9 to shut down everything.
> However, running the build by hand works:
> sudo -u macports bash -c 
> '/opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 
> setup.py --no-user-cfg build'
> 
> Any pointers or help would be appreciated. I’ve never used bazel, so I copied 
> a bunch of relevant stuff from the py-tensorflow Portfile and attempted a few 
> obvious hacks, but nothing changes the underlying problem of a hung port 
> command.
> 
> Relevant files:
> 
> https://github.com/deepmind/tree/blob/master/setup.py 
> 
> https://github.com/deepmind/tree/blob/master/bazel/BUILD 
> 
> 
> Bazel process (hung when called from MacPorts):
> 
>> bazel(tree-0.1.6.20200524) -XX:+HeapDumpOnOutOfMemoryError 
>> -XX:HeapDumpPath=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a
>>  -Xverify:none 
>> -Djava.util.logging.config.file=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a/javalog.properties
>>  
>> -Dcom.google.devtools.build.lib.util.LogHandlerQuerier.class=com.google.devtools.build.lib.util.SimpleLogHandler$HandlerQuerier
>>  -XX:-MaxFDLimit 
>> -Djava.library.path=/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/embedded_tools/tools/objc:/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/
>>  -Dfile.encoding=ISO-8859-1 -jar 
>> /var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905/A-server.jar 
>> --max_idle_secs=10800 --noshutdown_on_low_sys_mem --connect_timeout_secs=30 
>> --output_user_root=/var/tmp/_bazel_root 
>> --install_base=/var/tmp/_bazel_root/install/e3bdf1a360e6d6cc38da72ec898bd905 
>> --install_md5=e3bdf1a360e6d6cc38da72ec898bd905 
>> --output_base=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a 
>> --workspace_directory=/opt/local/var/macports/build/_opt_local_ports_python_py-dm-tree/py37-dm-tree/work/tree-0.1.6.20200524
>>  
>> --default_system_javabase=/Library/Java/JavaVirtualMachines/openjdk13/Contents/Home
>>  
>> --failure_detail_out=/private/var/tmp/_bazel_root/54b8ea352146bad8adc65c2e363d519a/failure_detail.rawproto
>>  --deep_execroot --expand_configs_in_place --idle_server_tasks 
>> --write_command_log --nowatchfs --nofatal_event_bus_exceptions 
>> --nowindows_enable_symlinks --client_debug=false --product_name=Bazel 
>> --noincompatible_enable_execution_transition --option_sources=
> 
> 
> Draft Portfile:
> 
>> # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> 
>> PortSystem  1.0
>> PortGroup   compilers 1.0
>> PortGroup   compiler_blacklist_versions 1.0
>> PortGroup   github 1.0
>> PortGroup   java 1.0
>> PortGroup   python 1.0
>> PortGroup   xcodeversion 1.0
>> PortGroup   xcode_workaround 1.0
>> 
>> github.setupdeepmind tree 2b81872
>> # no official release; version from __init__.py plus github commit date
>> version 0.1.6.20200524
>> namepy-dm-${github.project}
>> revision 0
>> 
>> platforms   darwin
>> license Apache-2
>> maintainers nomaintainer
>> 
>> description Deepmind tree is a library for working with nested\
>> data structures.
>> long_description${description} In a way, tree generalizes the builtin\
>> map function which only supports flat sequences, and\
>> allows to apply a function to each "leaf" preserving\
>> the overall structure.
>> 
>> homepagehttps://github.com/deepmind/tree 
>> 
>> distname${github.project}-${version}
>> 
>> checksums   rmd160  40518b306e8f5a80b12ef5e76ca9e2f8ef232de3 \
>> sha256  
>> 0748428f70fae2209b8763bf99cadaf22276a4391851ba919dce9d3d0bc047bf \
>> size35176
>> 
>> python.versions 37 38
>> 
>> # Required java version
>> java.version11+
>> # JDK port to install if required java not found
>> java.fallback   openjdk14
>> # JDK only needed at build time, but java PG sets lib dependency so
>> # 

Re: Need some advice regarding patches for old AppKit compatibility

2020-06-04 Thread Christopher Jones
Hi,

> On 4 Jun 2020, at 3:06 pm, Jason Liu  wrote:
> 
> Well, Blender and MaterialX both use cmake to build, so hopefully it'll work 
> without any major issues.
> 
> Then, my next question is: If the header that I'm going to be wrapping is 
> #include , then where should I be putting my file in the 
> macports-legacy-support package? I'm assuming inside the include/ folder, but 
> then what? Do I need to create an AppKit/ subfolder inside there?

yes, under the include/ dir. you need to replicate the same structure as would 
normally be included, so if that is



then you need to replicate exactly that.

Then, inside that file there are certain things you need to do.  check some of 
the other examples. but it boils down to

1. use 

#include_next 

that triggers the inclusion of the header that would have been used, if the 
wrapper did not exist. Doing this makes builds blind to the fact they are using 
the wrapper.

2. Inside appropriate OSX version checks, add the additional bits and pieces 
you need to add to support older OSX versions. The checks should be specific to 
make sure its only done when needed. See 

MacportsLegacySupport.h

for how this is done.

If all you need to do is add a few typedefs to deal with some type renaming, 
then what you need to add insider the OS check is quite simple (i.e. doesn’t 
need an associated X.c file).

3. Finally, we really like to have basic tests to validate the new features. 
Whatever you think makes minimal sense. see the test dir for examples.

Chris



> 
> Actually, the reality is a bit more complicated than that. The source codes 
> of Blender and MaterialX actually use #include , which if you 
> take a look at the file located at 
> /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h, has #import 
> . Hopefully just wrapping AppKit.h will be sufficient?
> 
> Jason
> 
> -- 
> Jason Liu
> 
> 
> On Thu, Jun 4, 2020 at 5:49 AM Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> 
> 
>> On 4 Jun 2020, at 5:50 am, Jason Liu > <mailto:jason...@umich.edu>> wrote:
>> 
>> Looking through the link that Chris provided, it looks like the MacPorts 
>> legacy support package might indeed be the perfect place to add my AppKit 
>> compatibility layer file. One tiny question that I have is: In the readme, 
>> where it says "GNU make is a hard build dependency", does that sentence mean 
>> that the MacPorts legacy support package itself needs GNU make, or does it 
>> mean that any portfile that uses the legacysupport PortGroup needs to add 
>> GNU make as a build dependency?
> 
> Just the former. ports using it can use other build systems. it works well 
> with most build systems, but not all. which do you have in mind ?
> 
> Chris
> 
>> 
>> Jason
>> 
>> -- 
>> Jason Liu
>> 
>> 
>> On Wed, Jun 3, 2020 at 5:34 PM Jason Liu > <mailto:jason...@umich.edu>> wrote:
>> Great, I'll have a look at the stuff in that area. Thanks, Chris.
>> 
>> Jason
>> 
>> -- 
>> Jason Liu
>> 
>> 
>> On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> Hi,
>> 
>> Sounds like this *could* be a candidate for something to add to our legacy 
>> support package. see
>> 
>> https://github.com/macports/macports-legacy-support 
>> <https://github.com/macports/macports-legacy-support>
>> 
>> A port for this exists in MacPorts, and is applied as required to ports that 
>> need the support layer using the legacysupport PortGroup.
>> 
>> I think if we are to have a compatibility layer, as you describe below, 
>> putting it in the same place as the above is the way to go, so please take a 
>> look and submit MRs adding what you think is needed to it.
>> 
>> Chris
>> 
>>> On 3 Jun 2020, at 7:01 pm, Jason Liu >> <mailto:jason...@umich.edu>> wrote:
>>> 
>>> In my course of packaging some new ports, I've run across a couple 
>>> instances of applications which are claimed by their devs to only be 
>>> compatible with "macOS 10.12 and above". However, I've discovered that in 
>>> reality, the only reason they're no longer compatible with older versions 
>>> of macOS is because the names of a lot of constants changed in AppKit 
>>> starting in 10.12. All of these constants appear to be related to either 
>>> the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse 
>>> dragged, etc.).
>>> 
>>> So far, I've encountered two pieces of software where this is happening: 
>>> Blender and MaterialX.
&

Re: Need some advice regarding patches for old AppKit compatibility

2020-06-04 Thread Christopher Jones


> On 4 Jun 2020, at 5:50 am, Jason Liu  wrote:
> 
> Looking through the link that Chris provided, it looks like the MacPorts 
> legacy support package might indeed be the perfect place to add my AppKit 
> compatibility layer file. One tiny question that I have is: In the readme, 
> where it says "GNU make is a hard build dependency", does that sentence mean 
> that the MacPorts legacy support package itself needs GNU make, or does it 
> mean that any portfile that uses the legacysupport PortGroup needs to add GNU 
> make as a build dependency?

Just the former. ports using it can use other build systems. it works well with 
most build systems, but not all. which do you have in mind ?

Chris

> 
> Jason
> 
> -- 
> Jason Liu
> 
> 
> On Wed, Jun 3, 2020 at 5:34 PM Jason Liu  <mailto:jason...@umich.edu>> wrote:
> Great, I'll have a look at the stuff in that area. Thanks, Chris.
> 
> Jason
> 
> -- 
> Jason Liu
> 
> 
> On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
> Sounds like this *could* be a candidate for something to add to our legacy 
> support package. see
> 
> https://github.com/macports/macports-legacy-support 
> <https://github.com/macports/macports-legacy-support>
> 
> A port for this exists in MacPorts, and is applied as required to ports that 
> need the support layer using the legacysupport PortGroup.
> 
> I think if we are to have a compatibility layer, as you describe below, 
> putting it in the same place as the above is the way to go, so please take a 
> look and submit MRs adding what you think is needed to it.
> 
> Chris
> 
>> On 3 Jun 2020, at 7:01 pm, Jason Liu > <mailto:jason...@umich.edu>> wrote:
>> 
>> In my course of packaging some new ports, I've run across a couple instances 
>> of applications which are claimed by their devs to only be compatible with 
>> "macOS 10.12 and above". However, I've discovered that in reality, the only 
>> reason they're no longer compatible with older versions of macOS is because 
>> the names of a lot of constants changed in AppKit starting in 10.12. All of 
>> these constants appear to be related to either the drawing of GUI Cocoa 
>> windows or UI events (e.g. mouse down, mouse dragged, etc.).
>> 
>> So far, I've encountered two pieces of software where this is happening: 
>> Blender and MaterialX.
>> 
>> A solution I found which some projects (e.g. Qemu) have implemented 
>> basically replaces the new AppKit constants with the old AppKit ones using 
>> #define directives if the OS version is below 10.12. I've created a separate 
>> header file that gathers together a list of the constants I've been able to 
>> find, which is modeled on information from this message:
>> 
>> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04330.html 
>> <https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04330.html>
>> 
>> I'm doing my portfile development on a machine running 10.11, and have 
>> verified that my patch seems to allow me to build these applications without 
>> any noticeable issues (no runtime crashes, segfaults, etc.).
>> 
>> So my question to everyone is: Should I just add my header file to the 
>> files/ folder for whichever ports need it? Or is this something that might 
>> benefit from me creating a project in GitHub? I'm guessing that there could 
>> be other software packages which might benefit from such a compatibility 
>> layer.
>> 
>> -- 
>> Jason Liu
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: Need some advice regarding patches for old AppKit compatibility

2020-06-03 Thread Christopher Jones
Hi,

Sounds like this *could* be a candidate for something to add to our legacy 
support package. see

https://github.com/macports/macports-legacy-support 


A port for this exists in MacPorts, and is applied as required to ports that 
need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting 
it in the same place as the above is the way to go, so please take a look and 
submit MRs adding what you think is needed to it.

Chris

> On 3 Jun 2020, at 7:01 pm, Jason Liu  wrote:
> 
> In my course of packaging some new ports, I've run across a couple instances 
> of applications which are claimed by their devs to only be compatible with 
> "macOS 10.12 and above". However, I've discovered that in reality, the only 
> reason they're no longer compatible with older versions of macOS is because 
> the names of a lot of constants changed in AppKit starting in 10.12. All of 
> these constants appear to be related to either the drawing of GUI Cocoa 
> windows or UI events (e.g. mouse down, mouse dragged, etc.).
> 
> So far, I've encountered two pieces of software where this is happening: 
> Blender and MaterialX.
> 
> A solution I found which some projects (e.g. Qemu) have implemented basically 
> replaces the new AppKit constants with the old AppKit ones using #define 
> directives if the OS version is below 10.12. I've created a separate header 
> file that gathers together a list of the constants I've been able to find, 
> which is modeled on information from this message:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04330.html 
> 
> 
> I'm doing my portfile development on a machine running 10.11, and have 
> verified that my patch seems to allow me to build these applications without 
> any noticeable issues (no runtime crashes, segfaults, etc.).
> 
> So my question to everyone is: Should I just add my header file to the files/ 
> folder for whichever ports need it? Or is this something that might benefit 
> from me creating a project in GitHub? I'm guessing that there could be other 
> software packages which might benefit from such a compatibility layer.
> 
> -- 
> Jason Liu



smime.p7s
Description: S/MIME cryptographic signature


Re: Best way to get submodules into extracted source?

2020-05-22 Thread Christopher Jones
Hi,

No, there is I believe no way. If the project has sub modules that need to be 
initialised, I think the only real way out is to use a direct git fetch. i.e. 
follow

https://guide.macports.org/#reference.portgroup.github.submodule 


Chris

> On 22 May 2020, at 8:16 pm, Zhenfu Shi via macports-dev 
>  wrote:
> 
> Hey guys,
> I’m trying updating transmission(-x11) to just-released version 3.0, but it 
> uses a lot of 3rd party submodules. I found the macports guide reads "the 
> best distfile candidate (if available) is a distfile from GitHub releases”, 
> so I’d like to know what’s the best way to put submodules into the extracted 
> tarball, without using `fetch.type git` and `git submodule update —init`. 
> Would be great if there’s a port already doing this so I could learn from it.
> 
> Thanks in advance!



smime.p7s
Description: S/MIME cryptographic signature


Re: control verbose mode in Portfile?

2020-05-21 Thread Christopher Jones


> On 21 May 2020, at 9:31 am, René J.V. Bertin  wrote:
> 
> Hi,
> 
> Out of curiosity: is it possible to control verbose mode in a Portfile, like 
> with `set +x` / `set -x` in shell scripts?
> 
> I'd be interested to use that in the post-activate block of a number of my 
> ports, as an easy way to give a little more feedback to the user.

verbose mode printout is only visible if the user activates it, i.e. 'port -v’.

If you want pass a message on to the user, you should not use verbose output to 
do that. Instead just use a regular ‘ui_msg'

Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: make xorg-server a dependency of x11 ports?

2020-05-20 Thread Christopher Jones


> On 20 May 2020, at 3:55 pm, Rainer Müller  wrote:
> 
> On 20/05/2020 15.30, Ken Cunningham wrote:
>> Should xorg-server should be made a dependency of some key x11 component, so
>> that when people install an x11 application, xorg-server installs and it
>> actually works for them “out-of-the-box”.
> 
> I doubt even with the dependency it will not work "out of the box" as 
> expected,
> because installing xorg-server requires a logout/login cycle to get the 
> updated
> launchd environment as documented in the port notes of xinit. Hiding the
> installation of the X server may cause people to also overlook this essential 
> step.

Yes, that is required, but port notes will be printed at the end of the 
installation explaining to the user they need to do this. Hopefully at least 
some users will see this an do this step. It is stil, I would say, better than 
just failing later on with a much more cryptic error message, as Ken points 
out, when the users tries to start the application.

Chris

> 
> Rainer



smime.p7s
Description: S/MIME cryptographic signature


Re: make xorg-server a dependency of x11 ports?

2020-05-20 Thread Christopher Jones
Hi,

Personally, I would say yes, this makes sense given the current state of 
XQuartz.app

cheers Chris

> On 20 May 2020, at 2:30 pm, Ken Cunningham  
> wrote:
> 
> Should xorg-server should be made a dependency of some key x11 component, so 
> that when people install an x11 application, xorg-server installs and it 
> actually works for them “out-of-the-box”.
> 
> For example, CherryTree is apparently a very popular gtk application, and 
> there was some pressure for the past few years for a Mac version. I just 
> stumbled across it recently — took about 15 minutes to write the Portfile 
> (and a couple of minor edits after to get it completely right :>).
> 
> But when people try "sudo port -v install cherrytree” it delivers a broken 
> installation due to no xorg-server (see below).
> 
> It’s one more step to go back and explain how to install the server, but 
> really, as XQuartz.app is really out of date now, and MacOS no longer comes 
> with any X11 window server, I think we could just make our xorg-server a 
> dependency of some key part and have it installed automatically.
> 
> Otherwise, it seems like just one more needless headache for people that they 
> should not have to worry about, and we’re all about making this work “out of 
> the box” for people, right? — or we should be, if we want to recruit keep 
> users.
> 
> Ken
> 
> — example of cryptic error without xorg-server installed, gives people no 
> clue what is wrong.
> 
> 
> =
> So I've tried to run this using port myself and get the following error:
> 
> phillips321@Mac13:~$ cherrytree
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57:
>  GtkWarning: could not open display
>   warnings.warn(str(e), _gtk.Warning)
> dbus[77158]: Dynamic session lookup supported but failed: launchd did not 
> provide a socket path, verify that org.freedesktop.dbus-session.plist is 
> loaded!
> dbus fail, maybe a firewall problem, centralized instances disabled
> libc.prctl not available, the process name will be python and not cherrytree
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:69:
>  Warning: invalid (NULL) pointer instance
>   self.window = gtk.Window()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:69:
>  Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' 
> failed
>   self.window = gtk.Window()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/clipboard.py:93:
>  GtkWarning: gtk_clipboard_get_for_display: assertion 'display != NULL' failed
>   self.clipboard = gtk.clipboard_get()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  Warning: invalid (NULL) pointer instance
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' 
> failed
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' 
> failed
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  Warning: g_object_get: assertion 'G_IS_OBJECT (object)' failed
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  Warning: value "TRUE" of type 'gboolean' is invalid or out of range for 
> property 'visible' of type 'gboolean'
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  GtkWarning: gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
>  Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
>   vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:119:
>  GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' 
> failed
>   self.scrolledwindow_tree = gtk.ScrolledWindow()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:121:
>  GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' 
> failed
>   self.scrolledwindow_text = gtk.ScrolledWindow()
> 

Re: One large pull request vs. several small ones?

2020-05-13 Thread Christopher Jones
Hi,

> On 13 May 2020, at 3:05 pm, Jason Liu  wrote:
> 
> Maybe it would be better to start by submitting one PR for one isolated port. 
> We can then give you feedback on anything that might need to be changed and 
> merge it. This may enable you to make similar changes in your other ports 
> before submitting them. Then submit a PR for a second port. At some point, 
> once your PRs are getting accepted with no changes, you could submit two or 
> more ports together in a single PR, if the ports are similar and not too 
> complex
> 
> Actually I already started the process more than a week ago. The first 
> library, Partio, was accepted and merged yesterday:
> 
> https://github.com/macports/macports-ports/pull/7006 
> 
> 
> But of course, Open Shading Language (OSL), the library that depends on 
> Partio, failed the Travis CI build, since Partio didn't exist in the ports 
> tree when I submitted it at the same time:
> 
> https://github.com/macports/macports-ports/pull/7007 
> 
> 
> This is what prompted me to write my original question, because it seems that 
> a piece of software like Blender which has a complex dependency tree could 
> potentially take weeks or months for all of the new libraries to get accepted 
> into MacPorts.

That might well be true I am afraid. The point though is simply putting all the 
changes into a single PR will not help. If anything it makes it worse as large 
PRs with a lot of changes are harder to review. Smaller bitesize pieces are 
much easier to deal with, one step at a time.

Chris



smime.p7s
Description: S/MIME cryptographic signature


build.macports.org sites down ?

2020-05-12 Thread Christopher Jones
Hi,

Is there an issue with the build site ? e.g. if I try and load

https://build.macports.org/waterfall 

I just get

“Processing Failed”

https://build.macports.org 

seems to be working, and some of the links from there, but a number give the 
same error.

cheers Chris

smime.p7s
Description: S/MIME cryptographic signature


Re: One large pull request vs. several small ones?

2020-05-12 Thread Christopher Jones
Hi,

I would definitely say the many small PR approach is preferred to a single 
massive one with many many changes. A big PR like that is not going to help get 
it reviewed quicker. Mixing up new ports, with port updates, in one PR would 
really be a bit of a mess, I would say.

So yes, please try and submit each update separately. Once you have all the 
bits in place you ca then submit Blender update itself.

Chris

> On 12 May 2020, at 6:59 pm, Ruben Di Battista  
> wrote:
> 
> I think the best approach is to isolate “atomic” changes, and open a PR for 
> each of them. This way problems with dependencies can be isolated and 
> decoupled from those for Blender. 
> 
> If they are really too many, maybe try to provide PRs for semantically 
> related libraries or somehow related in some other way (like, “python” 
> dependencies). I would say a maximum of 3 - 4 ports per PR? 
> 
> I’ll leave the word to more expert members of the community, that’s my 
> general approach when I need to merge upstream complex trees of ports...
> 
>   _   
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
> 
> https://rdb.is 
> 
> On 12 May 2020 at 19:45:30, Jason Liu (jason...@umich.edu 
> ) wrote:
> 
>> I would like to contribute a portfile for the newest version of Blender. I 
>> already have a local portfile that is compiling successfully, and I am doing 
>> some cleanup before submitting a pull request on GitHub. In addition to 
>> Blender itself, I have also packaged several of Blender's dependent 
>> libraries, which would also be new ports. My question is: Would it be better 
>> for me to submit all of the portfiles for Blender and the libraries in one 
>> single pull request? Or should I submit one pull request for each new 
>> package individually?
>> 
>> The reason why I ask is that the dependency tree is a bit complex, with some 
>> of the libraries dependent on other libraries which I packaged as well. And 
>> if I were to submit each of the libraries individually, there's no telling 
>> how long it would take to get each one of them accepted and merged before I 
>> would be able to submit the Blender portfile.
>> 
>> -- 
>> Jason Liu



smime.p7s
Description: S/MIME cryptographic signature


Re: alternative for github clone with submodules -> make: *** [install] Error 71

2020-05-07 Thread Christopher Jones

destroy -> destroot ( blame auto-correct…. )

> On 7 May 2020, at 5:21 pm, Christopher Jones  wrote:
> 
> 
> 
>> On 7 May 2020, at 5:11 pm, macpo...@parvis.nl <mailto:macpo...@parvis.nl> 
>> wrote:
>> 
>> 
>>> On 2020-05-07, at 17:46, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> On 7 May 2020, at 4:41 pm, macpo...@parvis.nl <mailto:macpo...@parvis.nl> 
>>> wrote:
>>>> ...
>>>> 
>>>> but now destroot fails.
>>>> 
>>>> log:
>>>> 
>>>> 
>>>> make: Entering directory 
>>>> `/opt/local/var/macports/build/_usr_local_macports_hfsinspect_sysutils_hfsinspect/hfsinspect/work/hfsinspect-02e0853'
>>>> + echo 'Installing hfsinspect in /usr/local'
>>>> Installing hfsinspect in /usr/local
>>>> + mkdir -p /usr/local/bin
>>>> + install build/Darwin-x86_64/hfsinspect /usr/local/bin
>>>> install: /usr/local/bin/hfsinspect: Operation not permitted
>>>> make: *** [install] Error 71
>>>> 
>>>> 
>>>> what should i do now?
>>> 
>>> Any reference to /usr/local is wrong, macports does not use that location. 
>>> The port file needs to configure the build to install to ${prefix} (which 
>>> in default installations points to /opt/local).
>> 
>> typical OOPS moment. 
>> changed Portfile: build.cmd make PREFIX=${prefix}
>> 
>> make: Entering directory 
>> `/opt/local/var/macports/build/_usr_local_macports_hfsinspect_sysutils_hfsinspect/hfsinspect/work/hfsinspect-02e0853'
>> + echo 'Installing hfsinspect in /opt/local'
>> Installing hfsinspect in /opt/local
>> + mkdir -p /opt/local/bin
>> + install build/Darwin-x86_64/hfsinspect /opt/local/bin
>> install: /opt/local/bin/hfsinspect: Operation not permitted
>> make: *** [install] Error 71
> 
> 
> If that error is occurring during the destroy phase, then thats the problem. 
> The build should not attempt to write anything to the final installation 
> destination at this point. If this is the problem you need to configure the 
> build to respect the DESTROOT setting.
> 
> cheers Chris
> 
>> 
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: alternative for github clone with submodules -> make: *** [install] Error 71

2020-05-07 Thread Christopher Jones


> On 7 May 2020, at 5:11 pm, macpo...@parvis.nl wrote:
> 
> 
>> On 2020-05-07, at 17:46, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> On 7 May 2020, at 4:41 pm, macpo...@parvis.nl <mailto:macpo...@parvis.nl> 
>> wrote:
>>> ...
>>> 
>>> but now destroot fails.
>>> 
>>> log:
>>> 
>>> 
>>> make: Entering directory 
>>> `/opt/local/var/macports/build/_usr_local_macports_hfsinspect_sysutils_hfsinspect/hfsinspect/work/hfsinspect-02e0853'
>>> + echo 'Installing hfsinspect in /usr/local'
>>> Installing hfsinspect in /usr/local
>>> + mkdir -p /usr/local/bin
>>> + install build/Darwin-x86_64/hfsinspect /usr/local/bin
>>> install: /usr/local/bin/hfsinspect: Operation not permitted
>>> make: *** [install] Error 71
>>> 
>>> 
>>> what should i do now?
>> 
>> Any reference to /usr/local is wrong, macports does not use that location. 
>> The port file needs to configure the build to install to ${prefix} (which in 
>> default installations points to /opt/local).
> 
> typical OOPS moment. 
> changed Portfile: build.cmd make PREFIX=${prefix}
> 
> make: Entering directory 
> `/opt/local/var/macports/build/_usr_local_macports_hfsinspect_sysutils_hfsinspect/hfsinspect/work/hfsinspect-02e0853'
> + echo 'Installing hfsinspect in /opt/local'
> Installing hfsinspect in /opt/local
> + mkdir -p /opt/local/bin
> + install build/Darwin-x86_64/hfsinspect /opt/local/bin
> install: /opt/local/bin/hfsinspect: Operation not permitted
> make: *** [install] Error 71


If that error is occurring during the destroy phase, then thats the problem. 
The build should not attempt to write anything to the final installation 
destination at this point. If this is the problem you need to configure the 
build to respect the DESTROOT setting.

cheers Chris

> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: alternative for github clone with submodules

2020-05-07 Thread Christopher Jones


> On 7 May 2020, at 4:41 pm, macpo...@parvis.nl wrote:
> 
> 
>> On 2020-05-07, at 14:58, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> see
>> 
>> https://github.com/macports/macports-ports/blob/master/python/py-pytorch/Portfile#L92
>>  
>> <https://github.com/macports/macports-ports/blob/master/python/py-pytorch/Portfile#L92>
>> 
>> Chris
> 
> 
> thanks!
> 
> i had to add 'fetch.type git’ to Portfile to get it working.
> 
> but now destroot fails.
> 
> log:
> 
> 
> make: Entering directory 
> `/opt/local/var/macports/build/_usr_local_macports_hfsinspect_sysutils_hfsinspect/hfsinspect/work/hfsinspect-02e0853'
> + echo 'Installing hfsinspect in /usr/local'
> Installing hfsinspect in /usr/local
> + mkdir -p /usr/local/bin
> + install build/Darwin-x86_64/hfsinspect /usr/local/bin
> install: /usr/local/bin/hfsinspect: Operation not permitted
> make: *** [install] Error 71
> 
> 
> what should i do now?

Any reference to /usr/local is wrong, macports does not use that location. The 
port file needs to configure the build to install to ${prefix} (which in 
default installations points to /opt/local).

> 
> 
> 
> BTW: i tried to install py37-pytorch as a tutorial for me but it failed:
> distutils.errors.DistutilsError: the `allow-hosts` option is not supported 
> when using pip to install requirements.
> Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-spaCy/py37-spaCy/work/spaCy-2.2.4"
>  && /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 
> setup.py build_ext --inplace build -j8
> Exit code: 1
> Error: Failed to build py37-spaCy: command execution failed

Hmm, not seen that before..

Chris

> 
> 



smime.p7s
Description: S/MIME cryptographic signature


  1   2   >