Re: [10.6.8] certbot & pyOpenSSL problems

[Marius Schamschula]

What does

port installed py39-openssl

say? On my machine I get 21.00.0_0.

Also, IIRC there was a change in py-cryptography versioning. On my machine I 
have 35.0.0_3.

Mixing pip with MacPorts will guarantee a broken installation within weeks.if 
not within days.

Marius
--
Marius Schamschula




> On Dec 16, 2021, at 5:17 PM, Bjarne D Mathiesen  
> wrote:
> 
> System Version: Mac OS X 10.6.8 (10K549)
> Kernel Version: Darwin 10.8.0
> 
> Ok, I've got certbot installed, but a recent upgrade of something has
> broken it :
> 
> #=> certbot certificates
> 
> gives the following error-message :
> 
> pkg_resources.ContextualVersionConflict: (cryptography 2.9.2
> (/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages),
> Requirement.parse('cryptography>=3.3'), {'PyOpenSSL'})
> 
> which to me indicates, that PyOpenSSL needs to be upgraded.
> So, I installed py39-pip, and did the following :
> 
> #=> pip install pyopenssl
> Requirement already satisfied: pyopenssl in
> /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
> (21.0.0)
> Collecting cryptography>=3.3
>  Downloading cryptography-36.0.1.tar.gz (572 kB)
> || 572 kB 1.0 MB/s
>  Installing build dependencies ... done
> 
> which resulted in the following error-message :
> 
>  running build_rust
> 
>  =DEBUG
> ASSISTANCE=
>  If you are seeing a compilation error please try the following
> steps to
>  successfully install cryptography:
>  1) Upgrade to the latest pip and try again. This will fix errors
> for most
> users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
>  2) Read https://cryptography.io/en/latest/installation/ for specific
> instructions for your platform.
>  3) Check our frequently asked questions for more information:
> https://cryptography.io/en/latest/faq/
>  4) Ensure you have a recent Rust toolchain installed:
> https://cryptography.io/en/latest/installation/#rust
> 
>  Python: 3.9.9
>  platform: macOS-10.6.8-i386-64bit
>  pip: n/a
>  setuptools: 59.6.0
>  setuptools_rust: 1.1.2
>  =DEBUG
> ASSISTANCE=
> 
>  error: can't find Rust compiler
> 
> So, it's missing the rust compiler !
> OK, let me install that one :
> 
> --->  Fetching distfiles for rust-compiler-wrap
> Error: rust is only supported on macOS 10.7 or later.
> Error: Failed to fetch rust-compiler-wrap: unsupported platform version
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust-compiler-wrap/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets if you believe
> there is a bug.
> Error: Processing of port rust failed
> 
> 
> Any ideas as to how I can upgrade PyOpenSSL -or- the cryptography ?
> Or am I just lost ???
> 
> 
> -- 
> 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

deleting -DNDEBUG added by cmake PG

[Kurt Hindenburg]

Hello,
  The cmake PG adds -DNDEBUG to various flags.  For the next release of ipbt I 
need to remove it.  The normal configure.*-delete do not seem to work.
Does anyone have suggestions on how to do this?

configure.cflags-append -DNDEBUG 
configure.cxxflags-append   -DNDEBUG

https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cmake-1.1.tcl
 


 Kurt

Re: Acceptability of depends_build bin:…

[Ryan Schmidt]

On Dec 13, 2021, at 04:48, 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?

I stand by my statement.

If a user already has "node" installed outside of MacPorts, you know nothing 
about it. Perhaps it is an ancient version the user installed 10 years ago and 
forgot about. Perhaps it's compiled for an architecture that doesn't run on 
this OS version anymore. Perhaps it's linked with libraries that the user has 
since removed.

To increase the chance of a successful build that is the same as the one the 
maintainer intended to happen, use MacPorts ports as dependencies rather than 
whatever random thing might exist on the user's system.

Re: Question about `platforms` and `${os.platform}`

[Ryan Schmidt]

On Dec 13, 2021, at 20:41, Christopher Chavez wrote:

>> Before you mentioned the AppKit overhaul some time ago and started 
>> addressing it in your ports, I had never heard of it and I don't think 
>> anyone else's ports do anything about it. So either we have a lot of broken 
>> ports due to this problem that we're not aware of, or for some reason it 
>> uniquely affects the ports you maintain...
> 
> 
> I want say this issue is not extremely uncommon, even if awareness of it is. 
> One instance of this is Tcl/Tk, which decided to predefine the deprecated 
> names of constants/functions/etc. to the 10.12 names when compiling for 
> ≥10.12, and leave usage of deprecated constants in their codebase alone 
> (leaving nothing for MacPorts to fix).
> 
> Maybe there are still projects using the deprecated names which ignore or 
> suppress warnings from -Wdeprecated-declarations.
> 
> But if an upstream project switched to the 10.12 names and effectively 
> dropped support for ≤10.11, I imagine the easiest course of action for a port 
> that then broke on ≤10.11 was to just drop support for ≤10.11 (and not 
> necessarily leave a more specific comment explaining why). Next up from that 
> might be to patch the old names back in, and either ignore deprecation 
> warnings on ≥10.12, patch only on ≤10.11, or suppressing warnings on ≥10.12.

I thought the "AppKit overhaul" referred to much more than just some symbols 
being renamed. If it's just renamed symbols, that seems like a simple enough 
problem to fix in either direction.

Re: fetch phase: sourceforge with 302 redirects?

[Ryan Schmidt]

On Dec 16, 2021, at 15:24, Jason Liu wrote:

> Is there any way to get MacPorts to follow redirects during the fetch phase?

MacPorts always does so already. But SourceForge has a bug in at least one of 
their mirror servers where redirects are not working correctly. Therefore, 
refer to the AvoidRedirects recipe for how to ensure you avoid the redirects in 
the first place.

[10.6.8] certbot & pyOpenSSL problems

[Bjarne D Mathiesen]

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0

Ok, I've got certbot installed, but a recent upgrade of something has
broken it :

#=> certbot certificates

gives the following error-message :

pkg_resources.ContextualVersionConflict: (cryptography 2.9.2
(/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages),
Requirement.parse('cryptography>=3.3'), {'PyOpenSSL'})

which to me indicates, that PyOpenSSL needs to be upgraded.
So, I installed py39-pip, and did the following :

#=> pip install pyopenssl
Requirement already satisfied: pyopenssl in
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
(21.0.0)
Collecting cryptography>=3.3
  Downloading cryptography-36.0.1.tar.gz (572 kB)
 || 572 kB 1.0 MB/s
  Installing build dependencies ... done

which resulted in the following error-message :

  running build_rust

  =DEBUG
ASSISTANCE=
  If you are seeing a compilation error please try the following
steps to
  successfully install cryptography:
  1) Upgrade to the latest pip and try again. This will fix errors
for most
 users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
  2) Read https://cryptography.io/en/latest/installation/ for specific
 instructions for your platform.
  3) Check our frequently asked questions for more information:
 https://cryptography.io/en/latest/faq/
  4) Ensure you have a recent Rust toolchain installed:
 https://cryptography.io/en/latest/installation/#rust

  Python: 3.9.9
  platform: macOS-10.6.8-i386-64bit
  pip: n/a
  setuptools: 59.6.0
  setuptools_rust: 1.1.2
  =DEBUG
ASSISTANCE=

  error: can't find Rust compiler

So, it's missing the rust compiler !
OK, let me install that one :

--->  Fetching distfiles for rust-compiler-wrap
Error: rust is only supported on macOS 10.7 or later.
Error: Failed to fetch rust-compiler-wrap: unsupported platform version
Error: See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust-compiler-wrap/main.log
for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe
there is a bug.
Error: Processing of port rust failed


Any ideas as to how I can upgrade PyOpenSSL -or- the cryptography ?
Or am I just lost ???


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

Re: fetch phase: sourceforge with 302 redirects?

[Jason Liu]

Yes, using the `curl -IL` command to obtain the part of the path I need to
extract (which is very slightly different from the web browser URL), did
the trick. Thanks! :)

-- 
Jason Liu


On Thu, Dec 16, 2021 at 4:29 PM Daniel J. Luke  wrote:

> On Dec 16, 2021, at 4:24 PM, Jason Liu  wrote:
> > I'm working on a new portfile that has its source stored on sourceforge.
> MacPorts is having trouble obtaining the tarball, because apparently the
> mirrors are pointing to the wrong file, and if I put the full URL into
> `master_sites`, it's unable to find the tarball at all. It seems that
> sourceforge is using 301 redirects to point to the actual file. If I use
> the URL with a `curl -L`, the correct file downloads just fine. Is there
> any way to get MacPorts to follow redirects during the fetch phase? If at
> all possible, I'd like to avoid manually using curl through a `system`
> call, but I suppose it could work as a last resort.
>
> Does this sourceforge example help?
>
> https://trac.macports.org/wiki/howto/AvoidRedirects
>
> --
> Daniel J. Luke
>
>

Re: fetch phase: sourceforge with 302 redirects?

[Daniel J. Luke]

On Dec 16, 2021, at 4:24 PM, Jason Liu  wrote:
> I'm working on a new portfile that has its source stored on sourceforge. 
> MacPorts is having trouble obtaining the tarball, because apparently the 
> mirrors are pointing to the wrong file, and if I put the full URL into 
> `master_sites`, it's unable to find the tarball at all. It seems that 
> sourceforge is using 301 redirects to point to the actual file. If I use the 
> URL with a `curl -L`, the correct file downloads just fine. Is there any way 
> to get MacPorts to follow redirects during the fetch phase? If at all 
> possible, I'd like to avoid manually using curl through a `system` call, but 
> I suppose it could work as a last resort.

Does this sourceforge example help?

https://trac.macports.org/wiki/howto/AvoidRedirects

-- 
Daniel J. Luke

fetch phase: sourceforge with 302 redirects?

[Jason Liu]

Hi everyone,

I'm working on a new portfile that has its source stored on sourceforge.
MacPorts is having trouble obtaining the tarball, because apparently the
mirrors are pointing to the wrong file, and if I put the full URL into `
master_sites`, it's unable to find the tarball at all. It seems that
sourceforge is using 301 redirects to point to the actual file. If I use
the URL with a `curl -L`, the correct file downloads just fine. Is there
any way to get MacPorts to follow redirects during the fetch phase? If at
all possible, I'd like to avoid manually using curl through a `system`
call, but I suppose it could work as a last resort.

-- 
Jason Liu