Re: Apple Clang and port:libomp

[Eric Borisch]

Jason,

You want to set:

compiler.openmp_version   3.0
(or whatever version of openmp you need.)

And the short answer is yes, this means you will build with something other
than Apple's clang, where they don't have the OpenMP support enabled  for
some reason.

Thanks,
  - Eric

On Wed, Nov 10, 2021 at 4:08 PM Jason Liu  wrote:

> Hi all,
>
> I feel like I should already know the answer to this question, but my
> brain is too tired at the moment to try to dig it out from my memory banks.
>
> If a MacPorts build is using Apple Clang, then does that mean that it will
> be unable to see port:libomp for OpenMP support? I've got a port that I'm
> working on that is giving the following messages:
>
> :info:configure -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS
> OpenMP_C_LIB_NAMES)
> :info:configure -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
> OpenMP_CXX_LIB_NAMES)
> :info:configure -- Could NOT find OpenMP (missing: OpenMP_C_FOUND
> OpenMP_CXX_FOUND)
>
> (Note: I do already have depends_lib-append port:libomp in my Portfile.)
>
> Does this mean that I need to blacklist Apple Clang in order for the build
> to be able to see libomp? Or is there something like a PortGroup that I'm
> missing?
>
> --
> Jason Liu
>

Apple Clang and port:libomp

[Jason Liu]

Hi all,

I feel like I should already know the answer to this question, but my brain
is too tired at the moment to try to dig it out from my memory banks.

If a MacPorts build is using Apple Clang, then does that mean that it will
be unable to see port:libomp for OpenMP support? I've got a port that I'm
working on that is giving the following messages:

:info:configure -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS
OpenMP_C_LIB_NAMES)
:info:configure -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
OpenMP_CXX_LIB_NAMES)
:info:configure -- Could NOT find OpenMP (missing: OpenMP_C_FOUND
OpenMP_CXX_FOUND)

(Note: I do already have depends_lib-append port:libomp in my Portfile.)

Does this mean that I need to blacklist Apple Clang in order for the build
to be able to see libomp? Or is there something like a PortGroup that I'm
missing?

-- 
Jason Liu

Re: GitHub Sponsors

[Perry E. Metzger]

On 11/10/21 15:17, Ryan Schmidt wrote:
To expand on that: Some years we receive income from Google Summer of 
Code. When we do, that money goes to one of the MacPorts elder 
council. He holds the money in his personal bank account and 
distributes it as needed for MacPorts-related purposes, and he pays 
tax on that income on his personal income taxes. I feel that this 
situation would be compounded by starting to accept donations. 


So again, several obvious options:

1. Get a TIN for "MacPorts" as an unincorporated association, open a 
bank account for it, have it file annual taxes (which should be near zero.)


2. Get the Software Freedom Conservancy to handle things for us. They do 
that for a vast number of projects (including brew! and git!) and 
they're likely to do a fine job.


3. Incorporate. I've done this for past software projects I've been 
involved in. I don't recommend it, but it's not so horrible. I'd 
strongly recommend (2) over this though.


I'll note again that unincorporated associations are totally a thing. 
Indeed, for legal reasons, many political campaigns in the US are 
unincorporated associations ("The Committee to Elect Jane Doe" is a 
typical pattern) and they file their own paperwork and are just fine. 
Most law and accounting firms until recently were unincorporated (though 
now they're often PCs or LLPs). But doing (2) has significant advantages 
including that donations are then likely tax deductible.


And no, none of this has to change the very informal way the MacPorts 
elders run things.


Perry

Re: GitHub Sponsors

[Perry E. Metzger]

On 11/10/21 15:02, Ryan Schmidt wrote:

MacPorts is not a legal organization so I don't see how it could accept 
donations.

You don't need to be incorporated to accept money. Incorporation is only 
necessary if you want to claim to be a nonprofit or if you worry that you need 
limited liability. There's no legal obstacle to an unincorporated association 
opening a bank account, and they do all the time.

These donations would be classified as somebody's income. Somebody would have 
to pay income taxes on them. Who?

Not necessarily any individual. We'd want to consult an accountant of 
course, but the organization can file its own return. Yes, the IRS 
happily issues TINs for unincorporated associations. That said, there 
are other options here too. For example, the Software Freedom 
Conservancy was set up specifically to deal with this sort of thing on 
behalf of projects too small to set up their own incorporation and 
accounting.



Perry

Re: GitHub Sponsors

[Mark Anderson]

This is where I'd like to again pitch reaching out to
https://sfconservancy.org/ - I'd be willing to do the leg work - but I'd
need permission from the council of elders before I did such a thing.

https://sfconservancy.org/projects/services/

—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage 
GitHub Profile 



On Wed, Nov 10, 2021 at 3:02 PM Ryan Schmidt 
wrote:

> On Nov 10, 2021, at 14:01, Perry E. Metzger wrote:
>
> > On 11/10/21 14:59, Ryan Schmidt wrote:
> >> On Nov 10, 2021, at 12:11, Perry E. Metzger wrote:
> >>
> >>> Should we turn on the GitHub Sponsors functionality for the project on
> GitHub?
> >>>
> >>> It doesn't cost us anything to do it, and the money raised could be
> used to do things like buying hardware for builds and such.
> >> MacPorts is not a legal organization so I don't see how it could accept
> donations.
> >
> > You don't need to be incorporated to accept money. Incorporation is only
> necessary if you want to claim to be a nonprofit or if you worry that you
> need limited liability. There's no legal obstacle to an unincorporated
> association opening a bank account, and they do all the time.
>
> These donations would be classified as somebody's income. Somebody would
> have to pay income taxes on them. Who?
>
>

Re: GitHub Sponsors

[Ryan Schmidt]

On Nov 10, 2021, at 14:01, Perry E. Metzger wrote:

> On 11/10/21 14:59, Ryan Schmidt wrote:
>> On Nov 10, 2021, at 12:11, Perry E. Metzger wrote:
>> 
>>> Should we turn on the GitHub Sponsors functionality for the project on 
>>> GitHub?
>>> 
>>> It doesn't cost us anything to do it, and the money raised could be used to 
>>> do things like buying hardware for builds and such.
>> MacPorts is not a legal organization so I don't see how it could accept 
>> donations.
> 
> You don't need to be incorporated to accept money. Incorporation is only 
> necessary if you want to claim to be a nonprofit or if you worry that you 
> need limited liability. There's no legal obstacle to an unincorporated 
> association opening a bank account, and they do all the time.

These donations would be classified as somebody's income. Somebody would have 
to pay income taxes on them. Who?

Re: GitHub Sponsors

[Perry E. Metzger]

On 11/10/21 14:59, Ryan Schmidt wrote:

On Nov 10, 2021, at 12:11, Perry E. Metzger wrote:


Should we turn on the GitHub Sponsors functionality for the project on GitHub?

It doesn't cost us anything to do it, and the money raised could be used to do 
things like buying hardware for builds and such.

MacPorts is not a legal organization so I don't see how it could accept 
donations.


You don't need to be incorporated to accept money. Incorporation is only 
necessary if you want to claim to be a nonprofit or if you worry that 
you need limited liability. There's no legal obstacle to an 
unincorporated association opening a bank account, and they do all the time.


Perry

Re: [10.6.8] mysql57 5.7.36 fails to configure

[Ryan Schmidt]

Build failures should be reported by filing a bug report in the issue tracker.

Re: rmd160 deprecated with openssl 3

[Ryan Schmidt]

On Nov 9, 2021, at 13:28, Chris Jones wrote:

> we should review our use of rmd160 in macports

Yes. I filed https://trac.macports.org/ticket/63885 to cover this.

Re: rmd160 deprecated with openssl 3

[Perry E. Metzger]

We should only be using widely vetted algorithms, IMHO. We really don't 
actually need more than sha256, but if we're going have a second hash 
and to replace rmd160, I'd recommend using SHA-3 (which is Keccak based 
and uses a quite different construction than SHA-2, and is a national 
standard.) Failing that, I'd suggest BLAKE2 or BLAKE3, which are based 
on very heavily studied primitives.


In no case should a hash as short as 128 bits be used; birthday attacks 
on such hashes are feasible.


Perry

On 11/9/21 15:33, Vadim-Valdis Yudaev wrote:

Hi Chris,

What about the SHAKE algorithm? We could choose shake-128 to replace rmd160. 
It's a new and fast hash function. Anyway, I'm just suggesting.

Vadim-Valdis


On Nov 9, 2021, at 21:28, Chris Jones  wrote:

Hi,

One thing that became apparent with the recent migration to openssl 3 is that 
rmd160 has been declared obsolete. Openssl3 has done this, and moved this 
algorithm to its ‘legacy’ set of providers, such that by default it is not 
available.

I ‘fixed’ this in the openssl3 port with

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

But I am thinking the fact this is required should be taken as an indication 
that we should review our use of rmd160 in macports, in preparation for some 
future OS where it is no longer available. I am not imagining this will likely 
be ‘soon’, but I think its probably better we start planing for it sooner 
rather than later.

We use rmd160 in a few places in macports. A possibly incomplete list is

1. Its one of the default checksums we provide in portfiles to validate source 
tarballs.
2. Its the checksum we provide alongside out binary tarballs

I don’t think either of those is hard to ‘fix’. I.e. for 1. We could (should?) 
start recommending a different checksum to replace the rmd160 one we use. For 
2., we could start publishing a second more modern checksum along side the 
rmd160 one, and then have base use this if present and fallback to rmd160 if 
missing.

Thoughts ?

Chris

Re: [10.6.8] mysql57 5.7.36 fails to compile

[Bjarne D Mathiesen]

Ok . doing as Renee Otten suggests in
 <232402be-9785-425e-8300-3019c32bb...@macports.org>
and inserting 'openssl.branch1.1' makes it configure; but it still
fails to compile.

log here :

https://macports.mathiesen.info/logs/databases/mysql57/openssl11-main.log

-- 
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