Re: Missing m4 forcing CLT reinstallation loop

[Dave Allured - NOAA Affiliate via macports-users]

There are multiple tickets on M4.  There is a fix in the works.  Yours
seems like the same thing.  Please see PR
https://github.com/macports/macports-ports/pull/22984 .


On Thu, Mar 14, 2024 at 7:16 PM Larry Stone 
wrote:

> This seems like an Xcode issue more than MacPorts but since MacPorts is
> why I have Xcode and its command line tools installed, I’ll ask here.
>
> I upgraded to Sonoma about three weeks ago. All went well including
> following the MacPorts instructions for major MacOS upgrades. All was
> working fine. At the time, Xcode and CLT was version 15.1 but both have
> been upgraded to 15.3 since then.
>
> Today, for the first time since upgrading to Sonoma, I ran the MacPorts
> update sequence starting with port selfudpate. One of the packages needing
> updating was Postfix which requires local building. The upgrade script
> errored and an error box popped up saying "the m4 command requires the
> command line developer tools.” Uh, they’re installed. Thinking maybe
> something had changed, I let it rerun the CLT installation but per System
> Information, the version was the same. Tried to upgrade Postfix again and
> the same thing.
>
> Looking in the CLT directory, I saw usr/bin/gm4 but not m4. A search
> suggested that gm4 is just m4 with a different name (maybe GNU m4) and to
> link m4 to gm4. I did and Postfix upgraded OK.
>
> So what happened? Built OK three weeks ago with CLT 15.1 but failed today
> with CLT 15.3. Was m4 in 15.1 but is now missing? (Normally, I’d just go to
> the Time Machine disk to take a look but I had to reinitialize it just a
> few days ago due to an error trying to expand the Time Machine partition on
> the disk). Am I OK linking m4 to gm4?
>
> --
> Larry Stone
> lston...@stonejongleux.com
>
>
>
>
>

Re: mozjs102

[Dave Allured - NOAA Affiliate via macports-users]

Following Ryan's suggestion, I am working on an update which should remove
the mozjs102 dependency, and enable gjs and glade for Sonoma.  Please try
the portfile from PR https://github.com/macports/macports-ports/pull/22974 .


On Thu, Mar 7, 2024 at 5:22 PM Lukas Oberhuber  wrote:

> i was never able to get gjs to work (at least when included in GIMP. It
> did compile, at least when I last tried (which was at least a year ago).
>
> On Thu, 7 Mar 2024 at 12:23, Ryan Schmidt  wrote:
>
>> On Mar 6, 2024, at 06:13, Gregory Dodwell wrote:
>>
>>
>> 
>> Will there ever be a mozjs102 port for the Sonoma version of MacPorts
>> 2.9.1?
>>
>> I can't install Glade without it. On the MacPorts bugs re mozjs102 page
>> there's a big red 'X' near the Sonoma version.
>>
>> Any plans for an update?
>>
>>
>> Nobody maintains this port. Somebody has to volunteer to investigate and
>> fix the problem. This is the bug report:
>>
>> https://trac.macports.org/ticket/68511
>>
>> mozjs115 does build on Sonoma so perhaps a fix already exists that can be
>> backported to mozjs102.
>>
>> And/or maybe the ports that depend on mozjs102 (currently only gjs and
>> gjs-devel) can switch to mozjs115.
>>
>

Re: mozjs102

[Dave Allured - NOAA Affiliate via macports-users]

On Thu, Mar 7, 2024 at 5:22 PM Lukas Oberhuber  wrote:

> i was never able to get gjs to work (at least when included in GIMP. It
> did compile, at least when I last tried (which was at least a year ago).
>
> On Thu, 7 Mar 2024 at 12:23, Ryan Schmidt  wrote:
>
>> On Mar 6, 2024, at 06:13, Gregory Dodwell wrote:
>>
>>
>> 
>> Will there ever be a mozjs102 port for the Sonoma version of MacPorts
>> 2.9.1?
>>
>> I can't install Glade without it. On the MacPorts bugs re mozjs102 page
>> there's a big red 'X' near the Sonoma version.
>>
>> Any plans for an update?
>>
>>
>> Nobody maintains this port. Somebody has to volunteer to investigate and
>> fix the problem. This is the bug report:
>>
>> https://trac.macports.org/ticket/68511
>>
>> mozjs115 does build on Sonoma so perhaps a fix already exists that can be
>> backported to mozjs102.
>>
>> And/or maybe the ports that depend on mozjs102 (currently only gjs and
>> gjs-devel) can switch to mozjs115.
>>
>>

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Dave Allured - NOAA Affiliate via macports-users]

Thanks Chris, that is good advice.  I forgot about port select.  In my case
I had to resort to a manual workaround for gfortran, because the port
command is disabled on my corporate controlled Mac.


On Mon, Mar 4, 2024 at 4:04 AM Chris Jones  wrote:

>
> You should not sym link manually yourself. That is precisely what `sudo
> port select gcc` is there for 
>
> On 02/03/2024 4:43 am, Dave Allured - NOAA Affiliate via macports-users
> wrote:
> > Yes, that is it.  Macports implementation decided to decorate the name
> > of the executable.  There is no naked "gfortran".  It is gfortran-mp-12,
> > gfortran-mp-13, etc.  This way you can have multiple versions installed
> > side by side, if you wish.  For convenience, I usually sym link
> > "gfortran" to the latest MP version.
> >
> >
> > On Fri, Mar 1, 2024 at 9:35 PM Kenneth Wolcott  > <mailto:kennethwolc...@gmail.com>> wrote:
> >
> > Should I be using gfortran-mp-13?
> >
> > ls /opt/local/bin | grep fortran
> > arm64-apple-darwin23-gfortran-mp-12
> > arm64-apple-darwin23-gfortran-mp-13
> > gfortran-mp-12
> > gfortran-mp-13
> > lfortran
> >
> > On Fri, Mar 1, 2024 at 8:28 PM Kenneth Wolcott
> > mailto:kennethwolc...@gmail.com>> wrote:
> >  >
> >  > I do have a GNAT Ada compiler located at:
> >  >
> >  > /opt/gcc-13.2.0-aarch64
> >  >
> >  > Does the existence of this confuse or mislead MacPorts?
> >  >
> >  > Thanks,
> >  > Ken W.
> >  >
> >  > On Fri, Mar 1, 2024 at 8:24 PM Kenneth Wolcott
> > mailto:kennethwolc...@gmail.com>> wrote:
> >  > >
> >  > > Hi Joshua;
> >  > >
> >  > > port contents gcc13 | grep gfortran
> >  > >   /opt/local/bin/arm64-apple-darwin23-gfortran-mp-13
> >  > >   /opt/local/bin/gfortran-mp-13
> >  > >   /opt/local/lib/gcc13/libgfortran.5.dylib
> >  > >   /opt/local/lib/gcc13/libgfortran.a
> >  > >   /opt/local/lib/gcc13/libgfortran.dylib
> >  > >   /opt/local/lib/gcc13/libgfortran.spec
> >  > >   /opt/local/share/info/gfortran-mp-13.info
> > <http://gfortran-mp-13.info>
> >  > >   /opt/local/share/man/man1/gfortran-mp-13.1.gz
> >  > > ~:
> >  > >
> >  > > But "ls /usr/local/bin | grep -i fortran"
> >  > >
> >  > > Has no output. ??!!
> >  > >
> >  > > Thanks,
> >  > > Ken W.
> >  > >
> >  > > On Fri, Mar 1, 2024 at 7:19 PM Joshua Root  > <mailto:j...@macports.org>> wrote:
> >  > > >
> >  > > > Are you sure of that? Check e.g. 'port contents gcc13 | grep
> > gfortran'.
> >  > > >
> >  > > > - Josh
> >  > > >
> >  > > > Kenneth Wolcott wrote:
> >  > > >
> >  > > > > Hi Noam;
> >  > > > >
> >  > > > >I do not have gfortran, therefore I must not have gcc?
> >  > > > >
> >  > > > > Here is a filtered list of the ports that I have installed
> > that pertain to gcc:
> >  > > > >gcc12 @12.3.0_4+stdlib_flag (active)
> >  > > > >gcc12-libcxx @12.3.0_4+clang14 (active)
> >  > > > >gcc13 @13.2.0_4+stdlib_flag (active)
> >  > > > >gcc13-libcxx @13.2.0_4+clang16 (active)
> >  > > > >gcc_select @0.1_10 (active)
> >  > > > >libgcc @7.0_0 (active)
> >  > > > >libgcc12 @12.3.0_4+stdlib_flag (active)
> >  > > > >libgcc13 @13.2.0_4+stdlib_flag (active)
> >  > > > >mpich-default @4.1.2_2+gcc13 (active)
> >  > > > >
> >  > > > > Still confused...
> >  > > > >
> >  > > > > Thanks,
> >  > > > > Ken W.
> >  > > > >
> >  > > > > On Fri, Mar 1, 2024 at 6:03 PM Bernstein, Noam CIV USN NRL
> > WASHINGTON
> >  > > > > DC (USA)  > <http://us.navy.mil>
> > <https://lists.macports.org/mailman/listinfo/macports-users
> > <https://lists.macports.org/mailman/listinfo/macports-users>>>
> wrote:
> >  > > > > >//>/Pretty sure that macports gcc installs gfortran by
> > default, which is
> >  > > > > a f90 (and 95, and maybe f2003) compiler./
> >  > > >
> >
>

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Dave Allured - NOAA Affiliate via macports-users]

Yes, that is it.  Macports implementation decided to decorate the name of
the executable.  There is no naked "gfortran".  It is gfortran-mp-12,
gfortran-mp-13, etc.  This way you can have multiple versions installed
side by side, if you wish.  For convenience, I usually sym link "gfortran"
to the latest MP version.


On Fri, Mar 1, 2024 at 9:35 PM Kenneth Wolcott 
wrote:

> Should I be using gfortran-mp-13?
>
> ls /opt/local/bin | grep fortran
> arm64-apple-darwin23-gfortran-mp-12
> arm64-apple-darwin23-gfortran-mp-13
> gfortran-mp-12
> gfortran-mp-13
> lfortran
>
> On Fri, Mar 1, 2024 at 8:28 PM Kenneth Wolcott 
> wrote:
> >
> > I do have a GNAT Ada compiler located at:
> >
> > /opt/gcc-13.2.0-aarch64
> >
> > Does the existence of this confuse or mislead MacPorts?
> >
> > Thanks,
> > Ken W.
> >
> > On Fri, Mar 1, 2024 at 8:24 PM Kenneth Wolcott 
> wrote:
> > >
> > > Hi Joshua;
> > >
> > > port contents gcc13 | grep gfortran
> > >   /opt/local/bin/arm64-apple-darwin23-gfortran-mp-13
> > >   /opt/local/bin/gfortran-mp-13
> > >   /opt/local/lib/gcc13/libgfortran.5.dylib
> > >   /opt/local/lib/gcc13/libgfortran.a
> > >   /opt/local/lib/gcc13/libgfortran.dylib
> > >   /opt/local/lib/gcc13/libgfortran.spec
> > >   /opt/local/share/info/gfortran-mp-13.info
> > >   /opt/local/share/man/man1/gfortran-mp-13.1.gz
> > > ~:
> > >
> > > But "ls /usr/local/bin | grep -i fortran"
> > >
> > > Has no output. ??!!
> > >
> > > Thanks,
> > > Ken W.
> > >
> > > On Fri, Mar 1, 2024 at 7:19 PM Joshua Root  wrote:
> > > >
> > > > Are you sure of that? Check e.g. 'port contents gcc13 | grep
> gfortran'.
> > > >
> > > > - Josh
> > > >
> > > > Kenneth Wolcott wrote:
> > > >
> > > > > Hi Noam;
> > > > >
> > > > >I do not have gfortran, therefore I must not have gcc?
> > > > >
> > > > > Here is a filtered list of the ports that I have installed that
> pertain to gcc:
> > > > >gcc12 @12.3.0_4+stdlib_flag (active)
> > > > >gcc12-libcxx @12.3.0_4+clang14 (active)
> > > > >gcc13 @13.2.0_4+stdlib_flag (active)
> > > > >gcc13-libcxx @13.2.0_4+clang16 (active)
> > > > >gcc_select @0.1_10 (active)
> > > > >libgcc @7.0_0 (active)
> > > > >libgcc12 @12.3.0_4+stdlib_flag (active)
> > > > >libgcc13 @13.2.0_4+stdlib_flag (active)
> > > > >mpich-default @4.1.2_2+gcc13 (active)
> > > > >
> > > > > Still confused...
> > > > >
> > > > > Thanks,
> > > > > Ken W.
> > > > >
> > > > > On Fri, Mar 1, 2024 at 6:03 PM Bernstein, Noam CIV USN NRL
> WASHINGTON
> > > > > DC (USA)  https://lists.macports.org/mailman/listinfo/macports-users>> wrote:
> > > > > >//>/Pretty sure that macports gcc installs gfortran by default,
> which is
> > > > > a f90 (and 95, and maybe f2003) compiler./
> > > >
>

Re: How to download builds from macports?

[Dave Allured - NOAA Affiliate via macports-users]

Thanks, Joshua.  Also, Pavel, your project might do better to simply use
standard Macports in sub shells as your Macports library manager, rather
than accessing mirrors directly.  This will take care of many issues for
you, such as updates, dependencies, and mirror changes, as well as what
Joshua mentioned.


On Tue, Dec 26, 2023 at 6:00 PM Joshua Root  wrote:

> Be aware that not all ports are available as binary archives, and some
> ports rely on post-activate code in the Portfile being run in order to
> work properly.
>
> - Josh
>
> PavelTurk wrote:
>
> > Hi Dave,
> >
> > Thank you very much for your answer.
> >
> > Best regards, Pavel
> >
> > On 12/26/23 5:19 PM, Dave Allured - NOAA Affiliate wrote:
> > >/Use one of the several mirror sites for pre-built binary
> > distributions.  Look under section "Archives" here: />/
> https://trac.macports.org/wiki/Mirrors
> >  />//>/Because each home page
> is huge, I find it convenient to postfix the
> > package name for use in a browser, e.g.: />/
> http://atl.us.packages.macports.org/ffmpeg/
> >  />//>//>/On Tue, Dec 26,
> 2023 at 3:47 AM PavelTurk  > 
> >  > >> wrote:
> />//>/Hi all,
> />//>/We have a Java project that must work on linux, windows, mac. To make 
> project cross-platform
>
> >
> />/we provide jars with shared libraries - so, dll. These libraries are 
> dowloaded with .sh script while
>
> >
> />/jar is built. We have libraries for linux and windows, but mac library is 
> on macports.
>
> >
> />//>/Could anyone say how to donwload build/package, for example, for 
> project `ffmpeg` using curl or wget?
>
> > />/Or what is the link to to it - http/https?/
>

Re: How to download builds from macports?

[Dave Allured - NOAA Affiliate via macports-users]

Use one of the several mirror sites for pre-built binary distributions.
Look under section "Archives" here:
https://trac.macports.org/wiki/Mirrors

Because each home page is huge, I find it convenient to postfix the package
name for use in a browser, e.g.:
http://atl.us.packages.macports.org/ffmpeg/


On Tue, Dec 26, 2023 at 3:47 AM PavelTurk  wrote:

> Hi all,
>
>
> We have a Java project that must work on linux, windows, mac. To make project 
> cross-platform
>
> we provide jars with shared libraries - so, dll. These libraries are 
> dowloaded with .sh script while
>
> jar is built. We have libraries for linux and windows, but mac library is on 
> macports.
>
>
> Could anyone say how to donwload build/package, for example, for project 
> `ffmpeg` using curl or wget?
> Or what is the link to to it - http/https?
>
> Best regards, Pavel
>

Re: Status of Macports on Sonoma?

[Dave Allured - NOAA Affiliate via macports-users]

Yes, the linker in CLT 15.0 is also affected.  I believe it is exactly the
same linker as the one in Xcode 15.0.


On Sat, Oct 7, 2023 at 9:46 AM Jim Secan  wrote:

> A related question - I install and use only the CLI toolkit for Xcode, not
> the entire Xcode package.  Does this linker problem also effect use of the
> CLI toolkit, or can I safely upgrade to just the toolkit (I’m still on
> Ventura).
>
> Jim
> Seattle, WA
> > On 10/07/2023, at 8:03 AM, Chris Jones  wrote:
> >
> > Hi,
> >
> >> On 7 Oct 2023, at 3:40 pm, Murray Eisenberg 
> wrote:
> >>
> >> 
> >>> OnFri, 6 Oct 2023 19:10:39 -0500,Kevin Horton 
> wrote:
> >>>
> >>> I'm pondering whether I should upgrade to macOS Sonoma now, or
> continue to wait.  Generally speaking, how well is Macports working on
> Sonoma?  I have seen a surprising small number of issues posted on this
> list, and am wondering whether that is a good reflection of the status.
> >>
> >>
> >> It depends on which ports you require. Most of those I had under
> Ventura I could finally get installed under Sonoma.
> >>
> >> But a number of ports will not as yet re-install under Sonoma owing to
> a change in C compiler flags in Xcode 15 (and Sonoma seems not to allow
> using an earlier version of Xcode).
> >
> >
> > Not wishing to be pedantic, but the issue is not relating to the
> compiler, but instead the linker. Xcode 15 switched to a new implementation
> which has issues in some scenarios, for instance whenever asked to link
> against object files or dylibs created with GCC. A common reason for this
> is ports that need to use GCC to build fortran source code. OpenBLAS is a
> specific example that a number of ports use and thus are having issues
> linking against.
> >
> > Workarounds exist, basically by using specific linker options to go back
> to using the so called ‘classic’ linker. The problem is not all builds are
> easy to convince to use these flags.
> >
> > Cheers Chris
> >
> >>
> >> Among those troublesome ports is sbcl, and unfortunately the maxima
> port depends on sbcl.
>

Re: meld quartz breakage

[Dave Allured - NOAA Affiliate via macports-users]

On Fri, Oct 6, 2023 at 4:08 PM Henning Hraban Ramm  wrote:

> Am 07.10.23 um 00:00 schrieb Riccardo Mottola via macports-users:
> > Hi,
> >
> > as I opened this bug report some months ago, at a certain point meld
> > stopped working properly on Mac Quartz
> > https://trac.macports.org/ticket/67169
> >
> > File tree displays randomly with blank and flashes when moving the
> > mouse over, sometimes revealing the file. What is even more
> > interesting is that left and right tree might display exclusively the
> > file name.
> >
> > Interestingly, breakage does not appear to be related to a new version
> > of meld itself (I also tried reverting) but it must be one of the many
> > dependencies. When it broke, it happened on all systems I had access
> > and got it compiling: 10.6, 10.7, 10.11 and 10.13
> >
> > Could someone test on their systems?
> > I know that on linux it works.
> >
> It works for me on 10.14 under XQuartz; I remember having strange
> problems with meld on some linux machine where it didn’t fill its window…
>
> Hraban
>


 The current meld port is 2.4 years out of date.  There are various fixes
in the release notes.  Would you like to try the latest stable version?

Re: [unable to compile and link C++ code with g++ 12.3]

[Dave Allured - NOAA Affiliate via macports-users]

Maxim, thanks.  Yours is the third report of compile or link problems
related to Command Line Tools 15.0, released only two days ago, that I have
seen.  I do not know what to make of that error message.  I have not heard
of "xcodebuild -version" failing when Xcode was actually installed.  Other
than maybe downgrading Xcode and CLT to 14.x, I do not have any other ideas
right now.  Anyone else?

(Resending to include the mailing list)


On Wed, Sep 20, 2023 at 11:12 AM Maxim Abalenkov 
wrote:

> Dear Dave et al.,
>
> I’m unable to run the ‘xcodebuild —version’. It complains:
>
> xcode-select: error: tool 'xcodebuild' requires Xcode, but active
> developer directory '/Library/Developer/CommandLineTools' is a command line
> tools instance
>
> The version of Xcode reported by the ‘About Xcode’ graphical menu item is:
>
> Version 15.0 (15A240d)
> —
> Best wishes,
> Maxim
>
> On 20 Sep 2023, at 17:41, Dave Allured - NOAA Affiliate <
> dave.allu...@noaa.gov> wrote:
>
> Maxim, thank you for the detailed follow-up.  What is the full output from
> "xcodebuild -version"?
>
>
> On Wed, Sep 20, 2023 at 10:36 AM Maxim Abalenkov <
> maxim.abalen...@gmail.com> wrote:
>
>> Dear all,
>>
>> I can compile and link the code with Clang C++ compiler from the MacPorts
>> collection:
>>
>> clang version 15.0.7
>> Target: x86_64-apple-darwin22.6.0
>> Thread model: posix
>> InstalledDir: /opt/local/libexec/llvm-15/bin
>>
>> To complement my previous email: my target system is macOS 13.5.2 (22G91)
>> and the new command line tools version is:
>>
>> package-id: com.apple.pkg.CLTools_Executables
>> version: 15.0.0.0.1.1694021235
>> volume: /
>> location: /
>> install-time: 1695112544
>>
>> —
>> Best wishes,
>> Maxim
>>
>> On 20 Sep 2023, at 17:11, Maxim Abalenkov 
>> wrote:
>>
>> Dear all,
>>
>> How are you? I hope all is well with you. I need help please. I’m no
>> longer able to compile and link a C++ code on my Mac. I use the latest GNU
>> C++ compiler available via MacPorts:
>>
>> g++ (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0
>>
>> Please find below the output of the make tool:
>>
>> g++ ifm.o Core/engine.o Core/filter.o Core/watershed.o
>> FileIO/interpolation.o FileIO/mapfile.o FileIO/netcdf_io.o
>> FileIO/rain_table.o -o ifm -fopenmp -O3   -lm -lz -lnetcdf_c++ -lnetcdf
>> -L/opt/local/lib
>> -macosx_version_min has been renamed to -macos_version_min
>> 0  0x109822f43  __assert_rtn + 64
>> 1  0x109724f43  ld::AtomPlacement::findAtom(unsigned char, unsigned long
>> long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411
>> 2  0x109741431
>>  ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const
>> + 19745
>> 3  0x109751b71  ld::InputFiles::parseAllFiles(void (ld::AtomFile const*)
>> block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const +
>> 657
>> 4  0x7ff810954066  _dispatch_client_callout2 + 8
>> 5  0x7ff810965e09  _dispatch_apply_invoke + 213
>> 6  0x7ff810954033  _dispatch_client_callout + 8
>> 7  0x7ff8109640f6  _dispatch_root_queue_drain + 683
>> 8  0x7ff810964768  _dispatch_worker_thread2 + 170
>> 9  0x7ff810af1c0f  _pthread_wqthread + 257
>> ld: Assertion failed: (resultIndex < sectData.atoms.size()), function
>> findAtom, file Relocations.cpp, line 1336.
>> collect2: error: ld returned 1 exit status
>> make: *** [Makefile:58: ifm] Error 1
>>
>> All this may be related to the update of Xcode command line tools that I
>> performed yesterday. Any help on how to debug and make it compile would be
>> most welcome. Thank you and have a great day ahead!
>> —
>> Best wishes,
>> Maxim
>>
>> Maxim Abalenkov \\ maxim.abalen...@gmail.com
>> +44 7 486 486 505 \\ www.maxim.abalenkov.uk
>>
>>

Re: checksum error on tree-sitter-go-mod

[Dave Allured - NOAA Affiliate via macports-users]

There is a Macports FAQ on checksum errors.  It would be helpful if you
would figure out whether this is a stealth update, or something else.


On Sat, Aug 5, 2023 at 12:38 PM  wrote:

> I'm getting a checksum error on tree-sitter-go-mod:
>
> --->  Verifying checksums for tree-sitter-go-mod
> Error: Checksum (rmd160) mismatch for tree-sitter-go-mod-1.0.0.tar.gz
> Error: Checksum (sha256) mismatch for tree-sitter-go-mod-1.0.0.tar.gz
> Error: Checksum (size) mismatch for tree-sitter-go-mod-1.0.0.tar.gz
> Error: Failed to checksum tree-sitter-go-mod: Unable to verify file
> checksums
>
>
> Regards
>

Re: trufflehog checksum fail

[Dave Allured - NOAA Affiliate via macports-users]

Please read about checksum failures and when to build from source, in the
Macports FAQ.  I would guess that you experienced either an intermittent
server outage, or a stealth update.  You can self diagnose this by trying a
manual download with curl.  Examine the result file.

Macports is designed to keep users in sync with the latest versions.
Please read about how to use older port versions in the HOWTO section.  In
general, using a down level version is not recommended, especially for a
security tool.  But it is possible.

I would not worry about the golang update.  Either version of trufflehog
will probably work just fine with either version of golang.


On Tue, Aug 1, 2023 at 9:38 PM Frank Cusack via macports-users <
macports-users@lists.macports.org> wrote:

> excuse the long copy paste at the end, but this way you can see exactly
> what happened.
>
> `sudo port install trufflehog` failed with source checksum failures. i
> don't know if the checksums were actually bad or if this is an anomaly when
> fetching the non-latest version. it does mean that i can never install that
> version of trufflehog, which is sad.
>
> anyway i got a hint to update first, so than after `selfupdate` (only! no
> port upgrades!) and another `sudo port install trufflehog` it worked.
>
> BUT it updated my golang!! this reminds me of brew. :( :~(
>
> I guess trufflehog is built from source? and it is hard coded to require
> go-1.20.7? ok, fine but you shouldn't be updating my runtime (vs buildtime)
> packages at least not without the Y/n prompt like on other implicit
> upgrades.
>
> I then discovered I merely had to activate the older version. OK, but the
> install/build process should have done this at the end, since I didn't
> request that upgrade.
>
> 1. did the failed version (3.45.3) of trufflehog actually have some error
> with checksum? or is this a macports anomaly.
> 2. do you agree macports has a bug re: forced, non-prompted, build deps
> upgrades?
>
> thanks
>
> [frank@mbp:~]$ sudo port install trufflehog
> Password:
> --->  Computing dependencies for trufflehog
> --->  Fetching archive for trufflehog
> --->  Attempting to fetch trufflehog-3.45.3_0.darwin_22.x86_64.tbz2 from
> https://packages.macports.org/trufflehog
> --->  Attempting to fetch trufflehog-3.45.3_0.darwin_22.x86_64.tbz2 from
> http://mirror.fcix.net/macports/packages/trufflehog
> --->  Attempting to fetch trufflehog-3.45.3_0.darwin_22.x86_64.tbz2 from
> https://ywg.ca.packages.macports.org/mirror/macports/packages/trufflehog
> --->  Fetching distfiles for trufflehog
> --->  Attempting to fetch trufflehog-3.45.3.tar.gz from
> https://distfiles.macports.org/go
> --->  Attempting to fetch trufflehog-3.45.3.tar.gz from
> https://github.com/trufflesecurity/trufflehog/archive/v3.45.3
> --->  Verifying checksums for trufflehog
> Error: Checksum (rmd160) mismatch for trufflehog-3.45.3.tar.gz
> Error: Checksum (sha256) mismatch for trufflehog-3.45.3.tar.gz
> Error: Checksum (size) mismatch for trufflehog-3.45.3.tar.gz
> Error: Failed to checksum trufflehog: Unable to verify file checksums
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_security_trufflehog/trufflehog/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets if you believe
> there is a bug.
> Error: Processing of port trufflehog failed
> [frank@mbp:~]$ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.8.1 installed,
> MacPorts base version 2.8.1 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is already the latest version
>
> The ports tree has been updated. To upgrade your installed ports, you
> should run
>   port upgrade outdated
> [frank@mbp:~]$ sudo port install trufflehog
> Portfile changed since last build; discarding previous state.
> --->  Fetching archive for go
> --->  Attempting to fetch go-1.20.7_0.darwin_22.x86_64.tbz2 from
> https://packages.macports.org/go
> --->  Attempting to fetch go-1.20.7_0.darwin_22.x86_64.tbz2 from
> http://mirror.fcix.net/macports/packages/go
> --->  Attempting to fetch go-1.20.7_0.darwin_22.x86_64.tbz2 from
> https://ywg.ca.packages.macports.org/mirror/macports/packages/go
> --->  Fetching distfiles for go
> --->  Attempting to fetch go1.20.7.src.tar.gz from
> https://distfiles.macports.org/go
> --->  Attempting to fetch go1.20.7.darwin-amd64.tar.gz from
> https://distfiles.macports.org/go
> --->  Verifying checksums for go
> --->  Extracting go
> --->  Configuring go
> --->  Building go
> --->  Staging go into destroot
> --->  Installing go @1.20.7_0
> --->  Cleaning go
> --->  Deactivating go @1.20.6_0
> --->  Cleaning go
> --->  Activating go @1.20.7_0
> --->  Cleaning go
> --->  Computing dependencies for trufflehog
> --->  Fetching archive for trufflehog
> --->  Attempting to fetch trufflehog-3.46.2_0.darwin_22.x86_64.tbz2 from
> https://packages.macports.org/trufflehog
> --->  

Re: master_sites and codeberg.org

[Dave Allured - NOAA Affiliate via macports-users]

Raf, I can not directly answer your question about the download URL.
Recent work added a new codeberg portgroup to make this simpler.  I suggest
you see what was done in the portfiles for other recent codeberg ports:
 smake, star, cdrtools.  There are also a few older codeberg ports to
examine, pre-portgroup, if you wish.


On Wed, Jun 14, 2023 at 2:58 AM raf via macports-users <
macports-users@lists.macports.org> wrote:

> Hi,
>
> I have a Portfile question.
>
> I have the (possibly incorrect) impression that
> values in the list of ${master_sites} need to be
> URLs to a directory that can have a filename appended
> to it to download the distfile. Is that correct?
> Or can it be the URL to the distfile itself?
>
> I'm asking because I use the codeberg.org git repository site,
> and when you make a "release" there, you can attach a file
> such as your official distfile/tarball. But the URL for it
> looks like:
>
>   https://codeberg.org/attachments/
>
> I'd like to put that in a Portfile, but I'm worried that
> macports will append "/${name}-${version}.tar.gz" and try
> to download that. If it does, that won't work. But if it
> just downloads the URL itself, it would work.
>
> Does macports work with URLs like this in ${master_sites}?
>
> cheers,
> raf
>

Re: chez-scheme compilation issue

[Dave Allured - NOAA Affiliate via macports-users]

There is a new upstream version just released today, that advertises to fix
your new compile errors.  I suggest file a port update ticket.  My guess is
that #60772 is stale and the old problem was already solved.


On Wed, Apr 26, 2023 at 12:51 PM  wrote:

> I see a related trac ticket from 3 years ago with a related issue
> (#60772). I compiled it outside macports w/o the error (just warnings)
> and it runs fine.  Should I update the previous ticket or add a new one?
>
> Regards
> Pete
>
>
>  Forwarded Message 
> Subject:chez-scheme compilation issue
> Date:   Sun, 16 Apr 2023 17:43:38 -0700
> From:   ppadil...@gmail.com
> To: macports-users@lists.macports.org
>
> I get an error when compiling chez-scheme (see below) should I submit a
> ticket?
> ---
> /usr/bin/clang -I/opt/local/include
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -m64
> -Wpointer-arith -Wall -Wextra -Wno-implicit-fallthrough -Werror -O2
> -I/opt/X11/include/ -pipe -Os
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch
> x86_64 -c -DX86_64 -I../boot/ta6osx   stats.c
> segment.c:328:17: error: a function declaration without a prototype is
> deprecated in all versions of C and is not supported in C2x
> [-Werror,-Wdeprecated-non-prototype]
> static seginfo *allocate_segments(nreq) uptr nreq; {
>  ^
> segment.c:328:17: error: a function declaration without a prototype is
> deprecated in all versions of C and is not supported in C2x
> [-Werror,-Wdeprecated-non-prototype]
> 2 errors generated.
> number.c:781:13: error: a function declaration without a prototype is
> deprecated in all versions of C and is not supported in C2x
> [-Werror,-Wdeprecated-non-prototype]
> static void big_trunc(tc, x, y, xl, yl, qs, rs, q, r)
>  ^
> number.c:781:13: error: a function declaration without a prototype is
> deprecated in all versions of C and is not supported in C2x
> [-Werror,-Wdeprecated-non-prototype]
> make[2]: *** [segment.o] Error 1
> ---
> Regards
>

Re: tree-sitter-cli port error

[Dave Allured - NOAA Affiliate via macports-users]

Stealth update.  Read about that in the Macports FAQ.  Please file a trac
ticket on this port.

This one looks legitimate.  Looking around their github site, they were
working on their automated release system.  It spat out two releases with
the same dist file name, several weeks apart.

If you don't want to wait, you can download the original distfile from a
macports mirror such as
https://distfiles.macports.org/tree-sitter/tree-sitter-0.20.8.tar.gz.
Currently the size and sha256 match the current portfile, but please check
it yourself.  Copy into your macports distfile directory, then try port
install again.


On Tue, Apr 25, 2023 at 7:56 PM  wrote:

> trying to install tree-sitter-cli I get:
>
> Error: Failed to checksum tree-sitter-cli: Unable to verify file checksums
>
> Regards
>

Re: the future of port:audacity

[Dave Allured - NOAA Affiliate via macports-users]

So *that's* what I was missing.  Ouch.


On Mon, Feb 13, 2023 at 1:54 PM Clemens Lang  wrote:

> Hi again,
>
> On Mon, Feb 13, 2023 at 07:43:43PM +0100, Clemens Lang wrote:
>
> > On Sun, Feb 12, 2023 at 01:53:20PM -0500, Dave Allured - NOAA Affiliate
> via macports-users wrote:
> > > I looked at the Audacity website, https://www.audacityteam.org .  It
> > > looks like Audacity is in robust current maintenance, sources are
> > > available, and legacy and modern Mac OS versions are supported through
> > > Ventura and Intel/M1/M2.  The current release is 3.2.4, almost two
> > > years ahead of the version cited by René.  You said this is in limbo?
> > > What am I missing?
> >
> > We should probably consider moving to Tenacity, as upstream Audacity has
> > recently taken a few decisions that are questionable.
> >
> > See [1] for more details on this and the current Tenacity source code.
> > Ideally, we'd add a new tenacity port and possibly mark audacity as
> > replaced_by tenacity, or at least add a note about this.
> >
> >   [1]:
> https://codeberg.org/tenacityteam/tenacity/src/branch/main/README.md#user-content-motivation
>
> Actually re-reading some of the upstream tickets referenced there, the
> audacity developers seem to have taken the feedback they received on
> these changes seriously, so maybe the situation isn't as bad as I made
> it out to be.
>
> Something to be aware of regardless, but please do check upstream
> sources and come to your own conclusions.
>
> --
> Clemens
>

Re: python310 build fail ticket?

[Dave Allured - NOAA Affiliate via macports-users]

Nope.  That's a dual python310/311 ticket.  Same issue for both.


On Sun, Feb 12, 2023 at 1:47 PM chilli.names...@gmail.com <
chilli.names...@gmail.com> wrote:

> Nope. That's python311.  I'm looking for an open python310 build fail
> ticket, which is whatever
>
> this
> https://trac.macports.org/ticket/66892
>
> and this
> https://trac.macports.org/ticket/66889
>
> are duplicates of
>
> On Feb 12, 2023, at 13:01, Giuseppe 'ferdy' Miceli  wrote:
>
> this one?
>
> #66242 (python311 @3.11.0 +lto +optimizations fails to build with broken
> symlink in include path) 
> trac.macports.org 
> 
> 
> 
>
> On 12 Feb 2023, at 18:47, chilli.names...@gmail.com wrote:
>
> Where is a recent ticket for python310 build failure? All I see is a few
> recent tickets closed as duplicates. Duplicates of what? I don't see any
> previous recent python310 ticket. My build is failing on Mojave and holding
> up cairo and gnutls upgrades. Whenever there is an upgrade holdup, it means
> I have to type more than I like to upgrade other ports. Thanks.
>
>

Re: the future of port:audacity

[Dave Allured - NOAA Affiliate via macports-users]

I looked at the Audacity website, https://www.audacityteam.org .  It looks
like Audacity is in robust current maintenance, sources are available, and
legacy and modern Mac OS versions are supported through Ventura and
Intel/M1/M2.  The current release is 3.2.4, almost two years ahead of the
version cited by René.  You said this is in limbo?  What am I missing?


On Sun, Feb 12, 2023 at 1:03 PM Peter Hancock  wrote:

> On 10/02/2023 23:04, René J.V. Bertin wrote:
> > Hello,
> >
> > port:audacity is (apparently) in a state of limbo currently, with a
> number of build failure reports. It's also outdated.
>
> That's sad, for me. I use it under Catalina, on a machine bought (mostly)
> for Work.
> I worry about it whether it'll work on whatever computer I buy next.
>
> My 2 cents is I care more that it to work on newer Macs.
> Else I'd have to use some other (less attractive, more expensive) audio
> software or OS.
>
> Thank you for looking after Macports audacity so far!
>
> P
>
> > A few observations:
> > - the official build still runs on OS X 10.9 and it looks I can get it
> to build there too
> > - older OS versions are out of luck, while I think the current Audacity
> version (3.0.1.x) still supports 10.7 (it builds targeting that OS).
> > - I'm currently doing test builds against wxWidgets 3.1.3.x, the very
> latest intermediate version that still supports 10.9 . The current
> port:wxWidgets-3.2 requires 10.11 and I haven't checked yet if Audacity
> will build against port:wxWidgets-3.0
> > - it appears that building the current port:audacity with the embedded
> special wxWidgets version fails on the latest OSes or ARM hardware.
> >
> > This raises 2 questions:
> > - do we introduce an additional legacy port (3.0.1) for older OS users
> who'd still like to be able to run an Audacity version with the new file
> format?
> > - do we drop the wxWidget variants and dependency and just make Audacity
> build its own fixed & customised version of that middleware?
> >
> > I don't plan on remaining port maintainer but I do use Audacity and thus
> have some interest in leaving this port in as best a state as possible.
>

Re: Old TeXShop checksum issue rears its ugly head again

[Dave Allured - NOAA Affiliate via macports-users]

Also, the TeXShop upstream developer just now agreed to start using
suffixes rather than stealth updates.  So disregard my suggestion to write
to them.


On Fri, Sep 16, 2022 at 9:07 AM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> The upstream developer said they intend to release TeXShop 5.03 later
> today.  So port maintainers might as well wait for that, before portfile
> repair.
>
>
> On Fri, Sep 16, 2022 at 7:30 AM Dave Allured - NOAA Affiliate <
> dave.allu...@noaa.gov> wrote:
>
>> Stealth upgrade detected.  This means the TeXShop developers changed
>> their published source code file without changing the file name.  Version
>> 5.02 was published on September 2.  Checksums in the Macports portfile were
>> last fixed on September 5.  Then the upstream developers changed the source
>> code file on September 9.  Please read more about this in the Macports FAQ,
>> "stealth upgrade".
>>
>> Macports tracks published source code files and uses checksums as a
>> security measure to avoid tampering.  It would be constructive if you would
>> contact the TeXShop developers and ask them to change the file name every
>> time they make any change to a published source code file.  They could bump
>> the version number, or add a suffix, or something.
>>
>> In the future, you can detect a stealth upgrade yourself, by downloading
>> the source code file directly from the source website, and looking for
>> signs of changes after the portfile was last updated.  "There is more than
>> one way to do this."  When you find a stealth update, please notify the
>> port maintainers by filing a Trac ticket.
>>
>> It looks like the port maintainers are responsive and will fix this
>> portfile soon.  If you like, you can try to fix your own local copy of the
>> portfile, so that you can complete your TeXShop installation.
>>
>>
>> On Fri, Sep 16, 2022 at 5:08 AM Gregory Dodwell 
>> wrote:
>>
>>> Macports base version 2.7.2
>>> Mac OS 12.6
>>> XCode 14 with Command-line tools installed.
>>> M1 Macbook Pro
>>>
>>> After performing my regular sudo port selfupdate; sudo port upgrade
>>> outdated maintenance routine I get TeXShop checksum errors.
>>>
>>> Cleaning and reinstalling TeXShop doesn't help.
>>>
>>> TeXShop is crucial for my role as a voluntary secretary for my local
>>> primary school P (I set the agendas in LaTeX, using texmaker).
>>>
>>> Here's what the log says:
>>>
>>> " ...
>>> version:1
>>> :debug:main Starting logging for TeXShop @5.02_0
>>> :debug:sysinfo macOS 12.6 (darwin/21.6.0) arch arm
>>> :debug:sysinfo MacPorts 2.7.2
>>> :debug:sysinfo Xcode 14.0
>>> :debug:sysinfo SDK 12
>>> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 12.0
>>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>>> ^unzip$
>>> :msg:main --->  Computing dependencies for TeXShop:info:main
>>> .:debug:main TeXShop has no conflicts
>>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>>> ^unzip$
>>> :debug:main Searching for dependency: unzip
>>> :debug:main Didn't find receipt, going to depspec regex for: unzip
>>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>>> ^unzip$
>>> :debug:main Executing org.macports.main (TeXShop)
>>> :debug:main dropping privileges: euid changed to 503, egid changed to
>>> 502.
>>> :debug:archivefetch archivefetch phase started at Fri Sep 16 20:41:05
>>> AEST 2022
>>> :msg:archivefetch --->  Fetching archive for TeXShop
>>> :debug:archivefetch Executing org.macports.archivefetch (TeXShop)
>>> :debug:archivefetch euid/egid changed to: 0/0
>>> :debug:archivefetch chowned /opt/local/var/macports/incoming to macports
>>> :debug:archivefetch euid/egid changed to: 503/502
>>> :info:archivefetch --->  TeXShop-5.02_0.darwin_21.arm64.tbz2 doesn't
>>> seem to exist in /opt/local/var/macports/incoming/verified
>>> :msg:archivefetch --->  Attempting to fetch
>>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>>> https://packages.macports.org/TeXShop
>>> :debug:archivefetch Fetching archive failed: The requested URL returned
>>> error: 404
>>> :msg:archivefetch --->  Attempting to fetch
>>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>>> https://ywg.ca.packages.macports.org/mirror/macports/packages/TeXShop
>>> :debug:archivefetch Fetching archive failed: The requested URL returned
>>> error: 404
>>> :msg:archivefetch --->  Attempting to fetch
>>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>>> https://kmq.jp.packages.macports.org/TeXShop
>>> :debug:archivefetch Fetching archive failed: The requested URL returned
>>> error: 404
>>> :debug:archivefetch Privilege de-escalation not attempted as not running
>>> as root.
>>> :debug:fetch fetch phase started at Fri Sep 16 20:41:08 AEST 2022
>>> :notice:fetch --->  Fetching distfiles for TeXShop
>>> :debug:fetch Executing org.macports.fetch (TeXShop)
>>> :debug:fetch Privilege de-escalation not attempted as not running as
>>> root.
>>> :debug:checksum checksum phase started at Fri Sep 16 20:41:08 AEST 2022
>>> 

Re: Old TeXShop checksum issue rears its ugly head again

[Dave Allured - NOAA Affiliate via macports-users]

The upstream developer said they intend to release TeXShop 5.03 later
today.  So port maintainers might as well wait for that, before portfile
repair.


On Fri, Sep 16, 2022 at 7:30 AM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> Stealth upgrade detected.  This means the TeXShop developers changed their
> published source code file without changing the file name.  Version 5.02
> was published on September 2.  Checksums in the Macports portfile were last
> fixed on September 5.  Then the upstream developers changed the source code
> file on September 9.  Please read more about this in the Macports FAQ,
> "stealth upgrade".
>
> Macports tracks published source code files and uses checksums as a
> security measure to avoid tampering.  It would be constructive if you would
> contact the TeXShop developers and ask them to change the file name every
> time they make any change to a published source code file.  They could bump
> the version number, or add a suffix, or something.
>
> In the future, you can detect a stealth upgrade yourself, by downloading
> the source code file directly from the source website, and looking for
> signs of changes after the portfile was last updated.  "There is more than
> one way to do this."  When you find a stealth update, please notify the
> port maintainers by filing a Trac ticket.
>
> It looks like the port maintainers are responsive and will fix this
> portfile soon.  If you like, you can try to fix your own local copy of the
> portfile, so that you can complete your TeXShop installation.
>
>
> On Fri, Sep 16, 2022 at 5:08 AM Gregory Dodwell 
> wrote:
>
>> Macports base version 2.7.2
>> Mac OS 12.6
>> XCode 14 with Command-line tools installed.
>> M1 Macbook Pro
>>
>> After performing my regular sudo port selfupdate; sudo port upgrade
>> outdated maintenance routine I get TeXShop checksum errors.
>>
>> Cleaning and reinstalling TeXShop doesn't help.
>>
>> TeXShop is crucial for my role as a voluntary secretary for my local
>> primary school P (I set the agendas in LaTeX, using texmaker).
>>
>> Here's what the log says:
>>
>> " ...
>> version:1
>> :debug:main Starting logging for TeXShop @5.02_0
>> :debug:sysinfo macOS 12.6 (darwin/21.6.0) arch arm
>> :debug:sysinfo MacPorts 2.7.2
>> :debug:sysinfo Xcode 14.0
>> :debug:sysinfo SDK 12
>> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 12.0
>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>> ^unzip$
>> :msg:main --->  Computing dependencies for TeXShop:info:main .:debug:main
>> TeXShop has no conflicts
>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>> ^unzip$
>> :debug:main Searching for dependency: unzip
>> :debug:main Didn't find receipt, going to depspec regex for: unzip
>> :debug:main Found Dependency: path: /usr/bin filename: unzip regex:
>> ^unzip$
>> :debug:main Executing org.macports.main (TeXShop)
>> :debug:main dropping privileges: euid changed to 503, egid changed to 502.
>> :debug:archivefetch archivefetch phase started at Fri Sep 16 20:41:05
>> AEST 2022
>> :msg:archivefetch --->  Fetching archive for TeXShop
>> :debug:archivefetch Executing org.macports.archivefetch (TeXShop)
>> :debug:archivefetch euid/egid changed to: 0/0
>> :debug:archivefetch chowned /opt/local/var/macports/incoming to macports
>> :debug:archivefetch euid/egid changed to: 503/502
>> :info:archivefetch --->  TeXShop-5.02_0.darwin_21.arm64.tbz2 doesn't seem
>> to exist in /opt/local/var/macports/incoming/verified
>> :msg:archivefetch --->  Attempting to fetch
>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>> https://packages.macports.org/TeXShop
>> :debug:archivefetch Fetching archive failed: The requested URL returned
>> error: 404
>> :msg:archivefetch --->  Attempting to fetch
>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>> https://ywg.ca.packages.macports.org/mirror/macports/packages/TeXShop
>> :debug:archivefetch Fetching archive failed: The requested URL returned
>> error: 404
>> :msg:archivefetch --->  Attempting to fetch
>> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
>> https://kmq.jp.packages.macports.org/TeXShop
>> :debug:archivefetch Fetching archive failed: The requested URL returned
>> error: 404
>> :debug:archivefetch Privilege de-escalation not attempted as not running
>> as root.
>> :debug:fetch fetch phase started at Fri Sep 16 20:41:08 AEST 2022
>> :notice:fetch --->  Fetching distfiles for TeXShop
>> :debug:fetch Executing org.macports.fetch (TeXShop)
>> :debug:fetch Privilege de-escalation not attempted as not running as root.
>> :debug:checksum checksum phase started at Fri Sep 16 20:41:08 AEST 2022
>> :notice:checksum --->  Verifying checksums for TeXShop
>> :debug:checksum Executing org.macports.checksum (TeXShop)
>> :info:checksum --->  Checksumming texshopsource502.zip
>> :debug:checksum Calculated (rmd160) is
>> ae8bccdf9ad901070fec3d4f25b426b2415f1279
>> :error:checksum Checksum (rmd160) mismatch for texshopsource502.zip
>> :info:checksum Portfile checksum: 

Re: Old TeXShop checksum issue rears its ugly head again

[Dave Allured - NOAA Affiliate via macports-users]

Stealth upgrade detected.  This means the TeXShop developers changed their
published source code file without changing the file name.  Version 5.02
was published on September 2.  Checksums in the Macports portfile were last
fixed on September 5.  Then the upstream developers changed the source code
file on September 9.  Please read more about this in the Macports FAQ,
"stealth upgrade".

Macports tracks published source code files and uses checksums as a
security measure to avoid tampering.  It would be constructive if you would
contact the TeXShop developers and ask them to change the file name every
time they make any change to a published source code file.  They could bump
the version number, or add a suffix, or something.

In the future, you can detect a stealth upgrade yourself, by downloading
the source code file directly from the source website, and looking for
signs of changes after the portfile was last updated.  "There is more than
one way to do this."  When you find a stealth update, please notify the
port maintainers by filing a Trac ticket.

It looks like the port maintainers are responsive and will fix this
portfile soon.  If you like, you can try to fix your own local copy of the
portfile, so that you can complete your TeXShop installation.


On Fri, Sep 16, 2022 at 5:08 AM Gregory Dodwell 
wrote:

> Macports base version 2.7.2
> Mac OS 12.6
> XCode 14 with Command-line tools installed.
> M1 Macbook Pro
>
> After performing my regular sudo port selfupdate; sudo port upgrade
> outdated maintenance routine I get TeXShop checksum errors.
>
> Cleaning and reinstalling TeXShop doesn't help.
>
> TeXShop is crucial for my role as a voluntary secretary for my local
> primary school P (I set the agendas in LaTeX, using texmaker).
>
> Here's what the log says:
>
> " ...
> version:1
> :debug:main Starting logging for TeXShop @5.02_0
> :debug:sysinfo macOS 12.6 (darwin/21.6.0) arch arm
> :debug:sysinfo MacPorts 2.7.2
> :debug:sysinfo Xcode 14.0
> :debug:sysinfo SDK 12
> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 12.0
> :debug:main Found Dependency: path: /usr/bin filename: unzip regex: ^unzip$
> :msg:main --->  Computing dependencies for TeXShop:info:main .:debug:main
> TeXShop has no conflicts
> :debug:main Found Dependency: path: /usr/bin filename: unzip regex: ^unzip$
> :debug:main Searching for dependency: unzip
> :debug:main Didn't find receipt, going to depspec regex for: unzip
> :debug:main Found Dependency: path: /usr/bin filename: unzip regex: ^unzip$
> :debug:main Executing org.macports.main (TeXShop)
> :debug:main dropping privileges: euid changed to 503, egid changed to 502.
> :debug:archivefetch archivefetch phase started at Fri Sep 16 20:41:05 AEST
> 2022
> :msg:archivefetch --->  Fetching archive for TeXShop
> :debug:archivefetch Executing org.macports.archivefetch (TeXShop)
> :debug:archivefetch euid/egid changed to: 0/0
> :debug:archivefetch chowned /opt/local/var/macports/incoming to macports
> :debug:archivefetch euid/egid changed to: 503/502
> :info:archivefetch --->  TeXShop-5.02_0.darwin_21.arm64.tbz2 doesn't seem
> to exist in /opt/local/var/macports/incoming/verified
> :msg:archivefetch --->  Attempting to fetch
> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
> https://packages.macports.org/TeXShop
> :debug:archivefetch Fetching archive failed: The requested URL returned
> error: 404
> :msg:archivefetch --->  Attempting to fetch
> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
> https://ywg.ca.packages.macports.org/mirror/macports/packages/TeXShop
> :debug:archivefetch Fetching archive failed: The requested URL returned
> error: 404
> :msg:archivefetch --->  Attempting to fetch
> TeXShop-5.02_0.darwin_21.arm64.tbz2 from
> https://kmq.jp.packages.macports.org/TeXShop
> :debug:archivefetch Fetching archive failed: The requested URL returned
> error: 404
> :debug:archivefetch Privilege de-escalation not attempted as not running
> as root.
> :debug:fetch fetch phase started at Fri Sep 16 20:41:08 AEST 2022
> :notice:fetch --->  Fetching distfiles for TeXShop
> :debug:fetch Executing org.macports.fetch (TeXShop)
> :debug:fetch Privilege de-escalation not attempted as not running as root.
> :debug:checksum checksum phase started at Fri Sep 16 20:41:08 AEST 2022
> :notice:checksum --->  Verifying checksums for TeXShop
> :debug:checksum Executing org.macports.checksum (TeXShop)
> :info:checksum --->  Checksumming texshopsource502.zip
> :debug:checksum Calculated (rmd160) is
> ae8bccdf9ad901070fec3d4f25b426b2415f1279
> :error:checksum Checksum (rmd160) mismatch for texshopsource502.zip
> :info:checksum Portfile checksum: texshopsource502.zip rmd160
> a5d51d8d3f015b8dc588f903e2c7b5eb323384df
> :info:checksum Distfile checksum: texshopsource502.zip rmd160
> ae8bccdf9ad901070fec3d4f25b426b2415f1279
> :debug:checksum Calculated (sha256) is
> c257ec0d870a5925ff92298ae67edcb40b5b87e842f0f60a67d890826e705251
> :error:checksum Checksum (sha256) mismatch for texshopsource502.zip
> :info:checksum Portfile 

Re: ftp client

[Dave Allured - NOAA Affiliate via macports-users]

I like ncftp for command line use.  It includes command line utilities for
recursive remote directory listing, and recursive bulk downloading.


On Wed, Aug 24, 2022 at 12:30 PM André-John Mas 
wrote:

> If you already know the destination path, then scp would be the way to go,
> otherwise sftp. I don’t remember if the latter is available by default on
> the Mac.
>
> André-John
>
>
> > On 24 Aug 2022, at 14:24, Mark Brethen  wrote:
> >
> > What’s the recommended ftp client nowadays for ease of use? There are
> too many to list from 'port search'. I intend to use it with qemu between
> host/guest.
> >
> > Thanks,
> > Mark
>

Re: port diagnose output on M1 MacBook Pro

[Dave Allured - NOAA Affiliate via macports-users]

On Mon, Apr 4, 2022 at 5:26 PM Ryan Schmidt  wrote:

> On Apr 4, 2022, at 14:25, Dave Allured - NOAA Affiliate wrote:
> > On Sun, Apr 3, 2022 at 4:23 PM Ryan Schmidt wrote:
> >> On Apr 1, 2022, at 13:09, Artemio González López wrote:
> >>
> >> > After executing “port diagnose” in my 2020 13” MacBook Pro running
> the latest version of the operating system (Monterrey 12.1.3, I believe) I
> got the following output:
> >> >
> >> > Warning: objc[10836]: Class AppleTypeCRetimerRestoreInfoHelper is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1053484f8). One of the two will be used. Which one is undefined.
> >> > objc[10836]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator
> is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348548). One of the two will be used. Which one is undefined.
> >> > objc[10836]: Class AppleTypeCRetimerFirmwareRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348598). One of the two will be used. Which one is undefined.
> >> > objc[10836]: Class ATCRTRestoreInfoFTABFile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1053485e8). One of the two will be used. Which one is undefined.
> >> > objc[10836]: Class AppleTypeCRetimerFirmwareCopier is implemented in
> both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348638). One of the two will be used. Which one is undefined.
> >> > objc[10836]: Class ATCRTRestoreInfoFTABSubfile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af6040) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348688). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class AppleTypeCRetimerRestoreInfoHelper is implemented
> in both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e04f8). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator
> is implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0548). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class AppleTypeCRetimerFirmwareRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0598). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class ATCRTRestoreInfoFTABFile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e05e8). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class AppleTypeCRetimerFirmwareCopier is implemented in
> both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0638). One of the two will be used. Which one is undefined.
> >> > objc[10837]: Class ATCRTRestoreInfoFTABSubfile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af6040) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0688). One of the two will be used. Which one is undefined.
> >> > 2022-04-01 19:39:17.575 xcodebuild[10837:118106] Requested but did
> not find extension point with identifier
> Xcode.IDEKit.ExtensionSentinelHostApplications for extension
> Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in
> com.apple.dt.IDEWatchSupportCore
> >> > 2022-04-01 19:39:17.576 xcodebuild[10837:118106] Requested but did
> not find extension point with identifier
> Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension
> Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of
> plug-in com.apple.dt.IDEWatchSupportCore
> >> >
> >> > Is any of this a problem?
> >>
> >> I haven't heard of these messages before. You may need to report them
> to Apple. The files being mentioned are provided by Apple, not MacPorts.
> >
> >  "is implemented in both" -- The same symbol is present in two different
> libraries that are both referenced by the same program.  This represents a
> possible build 

Re: port diagnose output on M1 MacBook Pro

[Dave Allured - NOAA Affiliate via macports-users]

On Sun, Apr 3, 2022 at 4:23 PM Ryan Schmidt  wrote:

> On Apr 1, 2022, at 13:09, Artemio González López wrote:
>
> > After executing “port diagnose” in my 2020 13” MacBook Pro running the
> latest version of the operating system (Monterrey 12.1.3, I believe) I got
> the following output:
> >
> > Warning: objc[10836]: Class AppleTypeCRetimerRestoreInfoHelper is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1053484f8). One of the two will be used. Which one is undefined.
> > objc[10836]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348548). One of the two will be used. Which one is undefined.
> > objc[10836]: Class AppleTypeCRetimerFirmwareRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348598). One of the two will be used. Which one is undefined.
> > objc[10836]: Class ATCRTRestoreInfoFTABFile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1053485e8). One of the two will be used. Which one is undefined.
> > objc[10836]: Class AppleTypeCRetimerFirmwareCopier is implemented in
> both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348638). One of the two will be used. Which one is undefined.
> > objc[10836]: Class ATCRTRestoreInfoFTABSubfile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af6040) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x105348688). One of the two will be used. Which one is undefined.
> > objc[10837]: Class AppleTypeCRetimerRestoreInfoHelper is implemented in
> both /usr/lib/libauthinstall.dylib (0x1f6af5eb0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e04f8). One of the two will be used. Which one is undefined.
> > objc[10837]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f00) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0548). One of the two will be used. Which one is undefined.
> > objc[10837]: Class AppleTypeCRetimerFirmwareRequestCreator is
> implemented in both /usr/lib/libauthinstall.dylib (0x1f6af5f50) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0598). One of the two will be used. Which one is undefined.
> > objc[10837]: Class ATCRTRestoreInfoFTABFile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af5fa0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e05e8). One of the two will be used. Which one is undefined.
> > objc[10837]: Class AppleTypeCRetimerFirmwareCopier is implemented in
> both /usr/lib/libauthinstall.dylib (0x1f6af5ff0) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0638). One of the two will be used. Which one is undefined.
> > objc[10837]: Class ATCRTRestoreInfoFTABSubfile is implemented in both
> /usr/lib/libauthinstall.dylib (0x1f6af6040) and
> /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
> (0x1085e0688). One of the two will be used. Which one is undefined.
> > 2022-04-01 19:39:17.575 xcodebuild[10837:118106] Requested but did not
> find extension point with identifier
> Xcode.IDEKit.ExtensionSentinelHostApplications for extension
> Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in
> com.apple.dt.IDEWatchSupportCore
> > 2022-04-01 19:39:17.576 xcodebuild[10837:118106] Requested but did not
> find extension point with identifier
> Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension
> Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of
> plug-in com.apple.dt.IDEWatchSupportCore
> >
> > Is any of this a problem?
>
> I haven't heard of these messages before. You may need to report them to
> Apple. The files being mentioned are provided by Apple, not MacPorts.
>

 "is implemented in both" -- The same symbol is present in two different
libraries that are both referenced by the same program.  This represents a
possible build mix-up and potential for runtime problems.  Apple decided
several years ago to issue warnings for this, rather than simply accept the
first found instance for the symbol.

This is distilled from 

Re: qt4-mac on M1

[Dave Allured - NOAA Affiliate via macports-users]

On Github:
https://github.com/macports/macports-ports/tree/master/_resources/port1.0/group

In your local install:
/opt/local/var/macports/sources/
rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group


On Fri, Apr 1, 2022 at 9:36 PM Peter West  wrote:

> Where are the portgroups (like qt4) defined?
> —
> Peter West
> p...@ehealth.id.au
> “Truly, truly, I say to you, an hour is coming, and is now here, when the
> dead will hear the voice of the Son of God, and those who hear will live.”
>
> On 2 Apr 2022, at 1:26 pm, Peter West  wrote:
>
> Down the rabbit hole.
>
> I’m following dependencies which have their own dependency on qt4-mac and
> are set to universal, I presume, because I get messages like
>
> Error: Cannot install automoc for the archs 'arm64 x86_64' because
> Error: its dependency qt4-mac only supports the archs 'ppc ppc64 i386
> x86_64'.
> —
> Peter West
> p...@ehealth.id.au
> “Truly, truly, I say to you, an hour is coming, and is now here, when the
> dead will hear the voice of the Son of God, and those who hear will live.”
>
> On 2 Apr 2022, at 12:44 am, Ryan Schmidt  wrote:
>
>
> On Apr 1, 2022, at 09:42, Peter West wrote:
>
> On 1 Apr 2022, at 11:53 pm, Ryan Schmidt wrote:
>
> On Apr 1, 2022, at 04:32, Peter West wrote:
>
> On 1 Apr 2022, at 7:22 pm, Peter West wrote:
>
>
> I just tried to install kmymoney4 on my M1 running 12.2.1. MacPorts spat
> the dummy with
>
> Error: Cannot install kmymoney4 for the arch 'arm64' because
> Error: its dependency qt4-mac only supports the archs 'ppc ppc64 i386
> x86_64’.
>
>
> Is it possible for me to install this somehow?
>
> Should I file a ticket for this?
>
>
> My Xcode version is 13.3. #61789 was closed as fixed 8 months ago.
>
>
> https://trac.macports.org/ticket/61789#comment:6 says "qt4-mac is old
> enough that my best guess is it'll take significant work to get it working
> on ARM64". Therefore #61789 was fixed by making the qt4-mac port indicate
> that it does not support the arm64 architecture, and thus if you try to
> install it on an Apple Silicon Mac, MacPorts should install it for the
> x86_64 architecture instead and it will run in emulation via Rosetta 2.
>
> However, kmymoney4 and probably most other ports that depend on qt4-mac do
> not similarly indicate that they do not support arm64, therefore MacPorts
> tries to install them and their dependencies (including qt4-mac) for arm64,
> which as we know doesn't work.
>
> The kmymoney4 portfile does include the kde4 portgroup which in turn
> includes the qt4 portgroup. The qt4 portgroup seems like a great place to
> set supported_archs to indicate non-support of arm64.
>
>
> Can I do this with a local portfile?
>
>
> Sure. To test whether this works, you could add the line
>
> supported_archs ppc ppc64 i386 x86_64
>
> to the kmymoney4 portfile.
>
>

Re: Is there a binary editor for MacPorts?

[Dave Allured - NOAA Affiliate via macports-users]

I don't know about true binary editors.  However it seems like you might be
trying to bridge older vs. newer character sets, like me.  For this I have
found the following approaches to be better than your "vi" experience.  If
your purpose is more general than character set translation, then someone
else may have a better suggestion.

* Open the file with the TextEdit app, which I believe is a built-in MacOS
application.  This will make a reasonable effort to open and display any
kind of file, including true binary files never intended for direct
viewing.  ASCII, UTF-8, and many other character sets will be detected and
displayed properly.  If you want to override the automatic character set
guessing, go to Options in the File/Open dialog.  Overtyping can be done
manually, if the number of substitutions is small.

* Use iconv on the command line to translate to a different character set.
This is also included with MacOS.  Man iconv for more details.  Caveat,
this program will stop on the first unrecognized sequence, unless one of
the substitution options is used.  For example, translate UTF-8 to
ISO-8859-1, and insert legible escape sequences for all unrecognized
sequences:

iconv -f UTF-8 -t ISO-8859-1 --unicode-subst="" infile > outfile

* To simply display binary, not edit, use "od -Ad -c" or "od -Ad -tx1" on
the command line.


On Wed, Sep 22, 2021 at 3:27 PM Dave Horsfall  wrote:

> I can see heaps of 3rd-party stuff out there, but is there an "official"
> one?
>
> I have a file with some binary stuff in it (8-bit accents, perhaps?) and
> "vi" just spits the dummy at that point and I want to search down further.
>
> Thanks.
>
> -- Dave
>

Re: Update on Big Sur Problems

[Dave Allured - NOAA Affiliate via macports-users]

Petr, you originally said you wanted cantera.  All this trouble with
sundials2, atlas, etc. is because the cantera port at v2.3.0 is more than
three years out of date.  Many versions have passed.  Sundials2 (v2.7.0)
and atlas should both be considered obsolete ports as far as modern
machines are concerned.

Cantera source is in current and robust maintenance.  Mac OS is
actively supported.  It uses sundials -- NOT sundials2 -- which is also
actively maintained and up to date on Macports, at v5.7.0.  Leave behind
all this old sundials2, atlas, gcc5.  I recommend that you update port
cantera to current version 2.5.1, or file an update request ticket.  From
the looks of cantera upstream install docs, it looks like there may be some
work involved.


On Sun, Apr 18, 2021 at 8:57 AM  wrote:

> I am not sure. I do the clean:
>
> pmm:~ pet$ sudo port clean atlas
> --->  Cleaning atlas
> pmm:~ pet$ sudo port install atlas -gcc5
> Warning: The macOS 11.2 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'.
> --->  Fetching archive for atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://packages.macports.org/atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://cph.dk.packages.macports.org/atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://lil.fr.packages.macports.org/atlas
> --->  Fetching distfiles for atlas
> --->  Verifying checksums for atlas
> --->  Extracting atlas
> --->  Applying patches to atlas
> --->  Configuring atlas
> Selected C compiler: /usr/bin/clang
> Selected F77 compiler: gfortran5
> Warning: reinplace s|-no-cpp-precomp||g didn't change anything in
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_atlas/atlas/work/ATLAS/CONFIG/src/atlcomp.txt
> Error: Failed to configure atlas: sysctl failed: No such file or directory
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_atlas/atlas/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port atlas failed
>
>
> pmm:~ pet$ sudo port clean atlas
> --->  Cleaning atlas
> pmm:~ pet$ sudo port install atlas
> Warning: The macOS 11.2 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'.
> --->  Computing dependencies for atlas
> Error: Can't install libgcc9 because conflicting ports are active:
> libgcc-devel
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port atlas failed
>
> Well, it is strange that in the case of " sudo port install atlas" it does
> not fetch the package again.
>
> pmm:~ pet$ port variants atlas
> atlas has the variants:
>gcc49: build using macports-gcc-4.9
>  * conflicts with gcc5 mpclang37 perf
> [+]gcc5: build using macports-gcc-5
>  * conflicts with gcc49 mpclang37 perf
>mpclang37: use mp-clang-3.7 and gfortran
>  * conflicts with gcc49 gcc5 perf
>nofortran: Forgo use of fortran compiler
>universal: Build for multiple architectures
>
> finally I tried to suppress both gcc variants:
>
> pmm:~ pet$ sudo port clean atlas
> Password:
> --->  Cleaning atlas
> pmm:~ pet$ sudo port install atlas -gcc5 -gcc49
> Warning: The macOS 11.2 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'.
> --->  Fetching archive for atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://packages.macports.org/atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://cph.dk.packages.macports.org/atlas
> --->  Attempting to fetch atlas-3.10.2_2.darwin_20.arm64.tbz2 from
> https://lil.fr.packages.macports.org/atlas
> --->  Fetching distfiles for atlas
> --->  Verifying checksums for atlas
> --->  Extracting atlas
> --->  Applying patches to atlas
> --->  Configuring atlas
> Selected C compiler: /usr/bin/clang
> Selected F77 compiler: gfortran5
> Warning: reinplace s|-no-cpp-precomp||g didn't change anything in
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_atlas/atlas/work/ATLAS/CONFIG/src/atlcomp.txt
> Error: Failed to configure atlas: sysctl failed: No such file or directory
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_atlas/atlas/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port 

Re: Forcing python39 on M1

[Dave Allured - NOAA Affiliate via macports-users]

*Sigh*.  The ports.macports.org site has not been getting updates since Feb
20.  See recent threads.  Yes, this is *usually* reliable.  Not this month.


On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> > Having heard that python39 is the only one (so far) to compile natively
> on M1, I’m trying to force the python ports I use to python39
>
> Hello Peter,
>
> FYI, an arm64 version of python38 appears to be available:
>
> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2
>
> and is “green” on the ports review page:
>
> https://ports.macports.org/port/python38/summary
>
>
> The ports.macports.org page can be misleading at times, unfortunately, as
> it will show “green” if the port has been blocked from building even if it
> can’t be built, which is no doubt confusing to people at times and there is
> (I believe) a ticket about that somewhere.
>
> The packages.macports.org site is pretty reliable, although to be 100%
> certain, you do need to actually install the port and examine it with
> “file” or “arch” or similar.
>
> And the fact that the arm64 python38 exists doesn’t necessarily mean a
> universal python38 exists for x86_64/arm64 or can be built. It might or
> might not.
>
> So there are some caveats to the presence of the python38 file there on
> packages, but it is there.
>
> Best,
>
> Ken
>

Re: ImageMagick port outdated

[Dave Allured - NOAA Affiliate via macports-users]

Short answer, that is being considered, and it will take some work.
Details in the ticket showed below by Ruben:
https://trac.macports.org/ticket/51310


On Fri, Sep 25, 2020 at 2:10 PM Fred Weinhaus  wrote:

> Why not just offer both ImageMagick 6 and Imagemagick 7. The user could
> then choose which he wants to use.
>
> Fred
>
>
> On Sep 25, 2020, at 1:02 PM, Sean DALY  wrote:
>
> Dave - that is my understanding, but I haven’t tested it. I have a ton of
> scripts and code snippets which would break with IMv7 and my Macs also run
> older OSes so I am not in a rush to move to IMv7. I use sips often in
> conjuction with imagemagick, the sips color profile and metadata handling
> is excellent
>
> Sean
>
>
> On Friday, September 25, 2020, Dave Allured - NOAA Affiliate via
> macports-users  wrote:
>
>> Sean,
>>
>> "possible to invoke the previous parser" -- Do you mean that some of the
>> IMv6 commands can be used with IMv7, simply by prefixing with "magick" and
>> a space?  I wonder how many of the many ports depending on IMv6 could be
>> satisfied with this simple patch.
>>
>>
>> On Fri, Sep 25, 2020 at 12:32 PM Sean DALY  wrote:
>>
>>> Hi Christoph,
>>>
>>> I use imagemagick every day and IMv7 introduces a number of changes, in
>>> particular the "magick" command which replaces the previous "identify",
>>> "convert", "montage", "composite" etc. commands. The CLI parser has been
>>> rewritten and following the previous CLI parameters order will not work. It
>>> is however possible to invoke the previous parser using "magick convert" or
>>> "magick composite" for example.
>>>
>>> As an alternative, if you are on a Mac running OSX v10.13 or later, for
>>> HEIF files use the OSX sips (Scriptable Image Processing System) tool, e.g.:
>>>
>>> # inspect file properties
>>> $ sips --getProperty allheic_image.heic
>>>
>>> # convert to JPEG
>>> $ sips --setProperty format jpeg heic_image.heic --setProperty
>>> formatOptions high --out heic_image.jpg
>>>
>>> sips is a good companion to imagemagick's convert for raster formats, it
>>> is fast and offers a number of features.
>>>
>>> As IM have stated they will support IMv6 for another ten years, it's
>>> probably best to not rush to IMv7 considering the number of changes
>>>
>>> Sean
>>>
>>>
>>> On Fri, Sep 25, 2020 at 11:59 AM Ruben Di Battista <
>>> rubendibatti...@gmail.com> wrote:
>>>
>>>> Moreover, HEIC format seems to be included here:
>>>> https://github.com/macports/macports-ports/pull/6021
>>>>
>>>> Are there any problems?
>>>>
>>>> On Fri, Sep 25, 2020 at 5:58 PM Ruben Di Battista
>>>>  wrote:
>>>> >
>>>> > Hello Christoph,
>>>> >
>>>> > here's there's a discussion about version 7:
>>>> > https://github.com/macports/macports-ports/pull/5014 and here
>>>> > https://trac.macports.org/ticket/51310. It probably will be provided
>>>> > as a separate port.
>>>> >
>>>> > On Fri, Sep 25, 2020 at 5:40 PM Christoph Kukulies 
>>>> wrote:
>>>> > >
>>>> > > I was seeking for a means to convert Apples new HEIC/HEIF format to
>>>> more traditional formats and I always remembered  ImageMagick being a good
>>>> choice for that.
>>>> > > Unfortunately the macports version is quite outdated.
>>>> > > 6.9.11-29
>>>> > >
>>>> > > vs. 7.0.10-30 being the latest.
>>>> > >
>>>> > > How can I get a newer version via macports?
>>>> > >
>>>> > > —
>>>> > > Christoph
>>>
>>>

Re: ImageMagick port outdated

[Dave Allured - NOAA Affiliate via macports-users]

Sean,

"possible to invoke the previous parser" -- Do you mean that some of the
IMv6 commands can be used with IMv7, simply by prefixing with "magick" and
a space?  I wonder how many of the many ports depending on IMv6 could be
satisfied with this simple patch.


On Fri, Sep 25, 2020 at 12:32 PM Sean DALY  wrote:

> Hi Christoph,
>
> I use imagemagick every day and IMv7 introduces a number of changes, in
> particular the "magick" command which replaces the previous "identify",
> "convert", "montage", "composite" etc. commands. The CLI parser has been
> rewritten and following the previous CLI parameters order will not work. It
> is however possible to invoke the previous parser using "magick convert" or
> "magick composite" for example.
>
> As an alternative, if you are on a Mac running OSX v10.13 or later, for
> HEIF files use the OSX sips (Scriptable Image Processing System) tool, e.g.:
>
> # inspect file properties
> $ sips --getProperty allheic_image.heic
>
> # convert to JPEG
> $ sips --setProperty format jpeg heic_image.heic --setProperty
> formatOptions high --out heic_image.jpg
>
> sips is a good companion to imagemagick's convert for raster formats, it
> is fast and offers a number of features.
>
> As IM have stated they will support IMv6 for another ten years, it's
> probably best to not rush to IMv7 considering the number of changes
>
> Sean
>
>
> On Fri, Sep 25, 2020 at 11:59 AM Ruben Di Battista <
> rubendibatti...@gmail.com> wrote:
>
>> Moreover, HEIC format seems to be included here:
>> https://github.com/macports/macports-ports/pull/6021
>>
>> Are there any problems?
>>
>> On Fri, Sep 25, 2020 at 5:58 PM Ruben Di Battista
>>  wrote:
>> >
>> > Hello Christoph,
>> >
>> > here's there's a discussion about version 7:
>> > https://github.com/macports/macports-ports/pull/5014 and here
>> > https://trac.macports.org/ticket/51310. It probably will be provided
>> > as a separate port.
>> >
>> > On Fri, Sep 25, 2020 at 5:40 PM Christoph Kukulies 
>> wrote:
>> > >
>> > > I was seeking for a means to convert Apples new HEIC/HEIF format to
>> more traditional formats and I always remembered  ImageMagick being a good
>> choice for that.
>> > > Unfortunately the macports version is quite outdated.
>> > > 6.9.11-29
>> > >
>> > > vs. 7.0.10-30 being the latest.
>> > >
>> > > How can I get a newer version via macports?
>> > >
>> > > —
>> > > Christoph
>>
>

Re: 2nd try, Most recent version of mplayer

[Dave Allured - NOAA Affiliate via macports-users]

On Tue, Jul 21, 2020 at 8:20 AM dan d.  wrote:



> I used this suggested work around:
>
> port clean --work mplayer-devel>
>
> After getting additional error messages with ways to fix the issue, I
> finally saw what looks like a typical install of mplayer-devel.
>
> However it doesn't show up in /opt/local/bin nand trying to run it with
> mplayer-devel produces the bash "no such command"." error message.
> There is no man entry either.
>
> I tried uninstalling it, it looked like a typical uninstall. Anew install
> was typical again, but with the results above as though it did not exist.
> --
> Am I missing something obvious in this?


This port is in good health according to the on-line port summary.  Some
debugging is warranted.  I do not use mplayer, but I offer a few
suggestions.

1.  Check /opt/local/bin for variations on spelling of the mplayer
executable.  Check upper/lower case and variations on the suffix.

2.  If you saved a console log, or if you try another install, check for
earlier error messages that might point to the origin of your problem.

3.  Follow the procedures under FAQ #1, "A port fails to build".  Among
other things, this ensures that dependencies are working and up to date.

https://trac.macports.org/wiki/FAQ#buildfails

4.  If #3 does not succeed, file a problem ticket as directed in #3.

Re: Most recent version of mplayer

[Dave Allured - NOAA Affiliate via macports-users]

Port mplayer-devel is from the same code base, but it is based on recent
SVN versions, not release versions.  Therefore it is more recently updated
than version 1.4.  Will mplayer-devel be satisfactory for your application?


On Sat, Jul 18, 2020 at 5:58 AM dan d.  wrote:

>
> The currentt version in macports is 1.3 for mplayer.  For a couple years
> now there is a 1.4 version available. from the developers.
>
> A couple of times I have asked the mmaintainer about the possibility of
> getting the current version with no response.
>
> What is possible for getting the latest version in macports?
> --
> XR
>

Re: Xterm scrolling very slow

[Dave Allured - NOAA Affiliate via macports-users]

Christoph, consider using Apple Terminal (in Utilities), rather than
Xterm.  This does not directly answer your question, but it was definitely
an improvement for me.  After I started using Mac OS a long time ago, I
discovered Apple Terminal as an alternative to Xterm.  As a native Apple
application, this freed me from a variety of idiosyncrasies with
Xterm's dependence on X11.  I never looked back.  The only drawback was
awkwardness with cut and paste between this and my X11-based text editor.
I got used to it.

I do not have Catalina yet, so I can not test your reported problem.
Perhaps someone else can say more about this Xterm problem in Catalina.  I
would also suggest bringing your question to an XQuartz or X11 support
forum.


On Thu, Apr 30, 2020 at 12:49 PM Christoph Kukulies 
wrote:

> I fired up X11 on my MacbookPro Catalina 10.15.4 and ran a Terminal
> (xterm).
>
> Scrolling looks funny and very slow. Is this a graphic card thing (BLT
> accelerator ?)
>
> —
> Christoph
>

Re: Using "clang" - toolchain question

[Dave Allured - NOAA Affiliate via macports-users]

Greg, I am repeatedly building port NCARG with a simple recipe, as part of
my local testing regime.  I never use any special options related to a
clang version or OpenMP.  This seems to work fine every time.  I am on a
Mac Pro, currently running OS 10.14.6 Mojave and Xcode 11.3.  This also
worked fine with recent earlier versions.  Here is a summary of my current
recipe.

Create local test directory in user space, not /opt/local
Isolate a test environment, omit /opt/local and /usr /local

Install macports base, current version
port install -s gcc9(with libunwind workaround)
port install -s hdf5 +gcc9
port install -s ncarg

I repeatedly confirmed that the hdf5 +gcc9 variant is necessary here.
OpenMP requirements seem to be satisfied automatically within this simple
scenario.  It is possible that my brief executable tests (NCL scripts) are
not properly exercising OpenMP.

I would expect that a similar recipe would also work in the standard
/opt/local location.  You might not need to source-build anything other
than NCARG, maybe this hdf5 variant; not sure about that.  Try this if you
think it might help.


On Wed, Jan 22, 2020 at 11:58 PM Greg Earle  wrote:

> I'm looking at my dev Mac and there are several versions of "clang" on
> the system:
>
> mac{cmbuild}% /usr/bin/clang -v
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> mac{cmbuild}% /Library/Developer/CommandLineTools/usr/bin/clang -v
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> mac{cmbuild}%
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>
> -v
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
>
> mac{cmbuild}% /opt/local/libexec/llvm-9.0/bin/clang -v
> clang version 9.0.1
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /opt/local/libexec/llvm-9.0/bin
>
> Now the MacPorts "clang-9.0" port might be a little behind the Apple
> version but it has something the Apple "clang" binaries don't have -
> support for "-fopenmp".
>
> I'm trying to build something (NCAR Graphics) that wants/demands
> "-fopenmp" support.
>
> How can I get the build to use the MacPorts "clang" part of the
> toolchain?
>
> Do I just stick "/opt/local/libexec/llvm-9.0/bin" at the front of $PATH
> and hope that "gcc"/"gfortran" et al. don't have any embedded "clang"
> paths (like "/usr/bin/clang") in them?
>
> Or do I have to install a matching GCC port (like libgcc8/gcc8 @8.2.0)
> to match up with "clang-9.0"?
>
> (I'm using a gfortran that's GCC 8.2.0-based, if it matters.)
>
> Thanks,
>
> - Greg
>

Re: possible malware in db48 port

[Dave Allured - NOAA Affiliate via macports-users]

On Wed, Jan 22, 2020 at 12:34 AM Bill Cole <
macportsusers-20171...@billmail.scconsult.com> wrote:

> On 21 Jan 2020, at 18:11, Artemio González López via macports-users
> wrote:
>
> > Bitdefender has flagged two files from the db48 MacPorts port
> > installed in my Mac, namely
> >
> > /opt/local/lib/db48/libdb_cxx-4.8.dylib
> > /opt/local/var/macports/software/db48/db48-4.8.30_4.darwin_17.x86_64.tbz2
> >
> > which seem to be infected by something called
> >
> > Gen:Variant.Application.MAC.Koiot.575
>
> The is not an indication of a specific 'infection' but rather a generic
> heuristic match with characteristics seen in known malware. This is NOT
> a match with any specific known malware.
>
> > Does this sound plausible,
>
> I believe Bitdefender flagged it. I don't believe it is worth concern. I
> have no reason to believe that a Bitdefender generic match it worth
> anything. Do you?
>
> > or is it more likely a false positive?
>
> It's nothing. It's not a 'positive' of any sort, it's an almost random
> assertion that a file has some vague characteristics in common with
> unspecified malware.
>
> Generic matches by "antivirus" programs that do not document those
> patterns are worse than worthless. Your use of Bitdefender has wasted
> your valuable time.
>
> > In any case, I am thinking of reinstalling the port. Is this possible,
> > and how should I proceed? (uninstall first, perhaps, but what about
> > dependents?).
>
> You can't make Bitdefender worthwhile software by reinstalling Berkeley
> DB 4.8.
>
> I have machines with these local source builds of the db48 port,
> v4.8.30_4:
>
> Darwin10/i386
> Darwin15/x86_64
> Darwin17/x86_64
> Darwin18/x86_64
>
> All of these now show the same 5 junk hits at VirusTotal on their
> libdb_cxx-4.8.dylib. The first 2 did not show any hits in years-old
> tests, but they hit when rescanned in the last few hours. I also have
> downloaded the pristine source from Oracle, patched it to fix naming
> conflicts, and built it without using anything from MacPorts. That
> libdb_cxx-4.8.dylib hits at VT identically to the 4 other builds I have.
>
> It is certainly possible that the source code of BerkeleyDB v4.8.30 has
> been compromised at its definitive repository by some
> as-yet-unidentified MacOS X malware which has unspecified similarities
> to some unspecified  known malware which is only known to 5 3rd-rate AV
> tools, 4 of which give it the same name which is unreferenced anywhere.
>
> It is more likely that those junk AV packages have detected the use of
> BerkeleyDB v4.8.30 (one of the most ubiquitous open source libraries in
> existence) by some malware and have deemed some of its characteristics
> as being indicative of malware, incorrectly.
>
> If you are a paying customer of Bitdefender, I urge you to ask them what
> this detection actually means and ask that they justify the waste of
> your time over this apparently pointless "detection." They owe you an
> explanation.
>

 Thanks Bill and Ryan for your perspectives and additional testing.  I am
inclined to agree with your skepticism.

The comedy of errors is expanding.  This morning, the number of hits via
virustotal.com had increased from the original 5 to 9.  I suppose that
scanners are industriously sharing their patterns.

For fun I dragged out the analogous library file from one of our linux
systems, /usr/lib64/libdb_cxx-4.7.so.  It is more than three years old, not
even the same code version.  Yet this morning, one of those VT reported
scanners had flagging this linux file.  The "engine" was Trapdoor, which
has not been responding for the past few hours.
https://www.virustotal.com/gui/file/e2746e958da892cd2485d9264bb0470b04159b63f5580a487d9b06c83fbf7780

( I added a single trailing line feed to preserve the state of the previous
original VT scan report; more than a year ago, and no hits.)

Re: possible malware in db48 port

[Dave Allured - NOAA Affiliate via macports-users]

My apologies, I am unfamiliar with Bitdefender.  Did you mean that you
reported this to bitdefender.com, or added to an exception list on your
local system?


On Wed, Jan 22, 2020 at 11:11 AM Artemio González López via macports-users <
macports-users@lists.macports.org> wrote:

> Thank you all. I have just put these two files in Bitdefeneder's exception
> list.
>
> Artemio Gonzalez Lopez
> artem...@mac.com
>

Re: possible malware in db48 port

[Dave Allured - NOAA Affiliate via macports-users]

On Tue, Jan 21, 2020 at 6:12 PM Christopher Chavez 
wrote:

> On 1/21/2020 7:03 PM, Christopher Chavez wrote:
> > VirusTotal doesn't report anything for
> > http://packages.macports.org/db48/db48-4.8.30_4.darwin_17.x86_64.tbz2:
> > see
> >
> https://www.virustotal.com/gui/url/c368d42293be904ef4710ad8ac1790b476e48ccdc8763c0267def2985222aad5/
>
> …although the report the archive itself (instead of the URL) *does*
> report a few positives, including BitDefender:
>
> https://www.virustotal.com/gui/file/20ab2a1bb6af8cf2b55a8fb5903adb3e3627fc8bd7b2f0937786be5567947629/
> ; I'm not sure why the URL report doesn't indicate this.
>

Another version of this file, recently built from source on my local Mac,
got the same 5 positives as the Macports binary version.  This does not
bode well for rebuilding as a remedy.

https://www.virustotal.com/gui/file/11faee65deeb057dfab168ad915b3f08a8a0c72eb2cf47d4fe2ea7c26c6179e1/detection

Thanks for the great tool, Chris.  I did not know about this one.

Re: Test in local repository without privileges

[Dave Allured - NOAA Affiliate via macports-users]

On Sat, Jan 18, 2020 at 3:20 AM Mojca Miklavec  wrote:

> On Fri, 17 Jan 2020 at 23:44, Christopher Jones
>  wrote:
> > On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via
> macports-users  wrote:
> >
> > Chris, thanks for the quick reply.  You are correct, a private macports
> installation would enable testing ports without special privilege.
> Actually I have already done this many times for testing and debugging
> other cases.
> >
> > However, I would like to find an intermediate solution that avoids full
> build-up from sources.  My main reasons are (1) test sensitivity to
> installed ports in the system prefix; (2) save time and effort; and (3) be
> able to provide compact, uncomplicated reproducers to third parties.
> >
> > If not currently possible, it would be nice to have a new feature to
> enable local repository testing, with fallback to the system prefix for
> everything not found in the local repository.
> >
> > What you are asking for is I am afraid really not possible, I suspect.
> The installation prefix is a fundamental parameter in most port builds.
> Many directly use this via the ${prefix} variable, which is a single valued
> path. What you are asking for is for a port use to use one location for
> some ports and a second one from others. I just don’t see how that could
> work.
> >
> > I think your only option is really to go with a second installation
> using a custom prefix.
>
> The only thing we could potentially do (but sadly I don't see it
> coming any time soon unless we get a devoted developer with sufficient
> time and skillset willing to work on this) is to support
> "relocatability" of packages to avoid building everything from source.
> It should be possible to a certain extent (at least our competitors
> did it).
>
> However installing some packages in one prefix and others in another
> is going to lead to countless troubles. Binaries have absolute links
> to their dependencies. So if you have library A, library B which
> depends on A, and binary C which depends on B, you install all three
> to /opt/local and then decide to test B in local installation using A
> from global prefix, this will generate a mess and will stop working as
> soon as A in global prefix is updated. Moreover you also need to
> install C to local prefix, else the test won't be "complete". I could
> keep on talking about problems, but long story short: not an option.
>
> Mojca
>

Chris and Mojca,

Thank you for carefully considering this request.  I understand the
problems that you described.  I can get by without this feature.

Here is a similar question that might help my current debugging scenario.
This is hypothetical because the source of my current issue was just fixed
upstream, so I do not really need to debug this one any further.

Is there an easy way to get macports to go through the motions of "port
install -s" for a single port, using macports infrastructure, and taking
port dependencies from /opt/local, but writing only inside a user
directory?  This would only be for testing that port's build process, not
for actually installing into the real port tree.  My now-hypothetical case
is a package that fails parallel build under macports, but never fails when
parallel building externally, with only autotools.  I would like to find
what the differences are, to help make a simpler reproducer.

Re: Test in local repository without privileges

[Dave Allured - NOAA Affiliate via macports-users]

Chris, thanks for the quick reply.  You are correct, a private macports
installation would enable testing ports without special privilege.
Actually I have already done this many times for testing and debugging
other cases.

However, I would like to find an intermediate solution that avoids full
build-up from sources.  My main reasons are (1) test sensitivity to
installed ports in the system prefix; (2) save time and effort; and (3) be
able to provide compact, uncomplicated reproducers to third parties.

If not currently possible, it would be nice to have a new feature to enable
local repository testing, with fallback to the system prefix for everything
not found in the local repository.


On Fri, Jan 17, 2020 at 3:09 PM Christopher Jones 
wrote:

> Hi,
>
> I might be wrong, but I do not believe it is possible to temporarily
> change the install prefix, for a single port.
>
> Most probably you will need to start a new installation, using a custom
> installation prefix, from scratch. see
>
> https://www.macports.org/install.php#source
>
> on installing from source, which you will need to do to change the
> installation prefix, as its a configure time option.
>
> Chris
>
> On 17 Jan 2020, at 9:33 pm, Dave Allured - NOAA Affiliate via
> macports-users  wrote:
>
> I am on a corporate network with ports installed normally in /opt/local,
> controlled by system admins.  Users do not have any write access into
> system directories.  I would like to use a local portfile repository in
> user space, as described in Macports guide 4.6.
>
> How can I test ports in the local repository?  The "portindex" command
> works as expected in this directory.  However, "port install" fails with
> "Insufficient privileges to write to MacPorts install prefix".  I need a
> way to tell "port install" to use a local prefix, rather than the default
> system prefix, for only the port under test.
>
> I figured that I could avoid tampering with the protected sources.conf, by
> manually pre-staging the desired distfiles in the local repository.  Here
> is my embryonic directory structure:
>
> $HOME/portx/science/netcdf-fortran/Portfile
> $HOME/portx/science/netcdf-fortran/files/patch-Makefile.in.diff
>
> $HOME/portx/var/macports/distfiles/netcdf-fortran/netcdf-fortran-4.5.2.tar.gz
>
> Thank you for any advice.
>
>

Test in local repository without privileges

[Dave Allured - NOAA Affiliate via macports-users]

I am on a corporate network with ports installed normally in /opt/local,
controlled by system admins.  Users do not have any write access into
system directories.  I would like to use a local portfile repository in
user space, as described in Macports guide 4.6.

How can I test ports in the local repository?  The "portindex" command
works as expected in this directory.  However, "port install" fails with
"Insufficient privileges to write to MacPorts install prefix".  I need a
way to tell "port install" to use a local prefix, rather than the default
system prefix, for only the port under test.

I figured that I could avoid tampering with the protected sources.conf, by
manually pre-staging the desired distfiles in the local repository.  Here
is my embryonic directory structure:

$HOME/portx/science/netcdf-fortran/Portfile
$HOME/portx/science/netcdf-fortran/files/patch-Makefile.in.diff
$HOME/portx/var/macports/distfiles/netcdf-fortran/netcdf-fortran-4.5.2.tar.gz

Thank you for any advice.

Re: gdal@3.0.1_3: Argument list too long

[Dave Allured - NOAA Affiliate via macports-users]

On Fri, Nov 29, 2019 at 7:41 PM Ryan Schmidt 
wrote:

> On Nov 29, 2019, at 10:01, Dave Allured wrote:
>
> > I have the longer user home prefix because my institutional network
> policy prevents all write access to /opt/anything.
>
> I still think the suggestion I made in
> https://trac.macports.org/ticket/59510#comment:2 is worth a try. If you
> can't put a clone of the macports-ports git repo in /opt/anything, you can
> pick another short path that you can write to. For example, /var/tmp should
> be writable, and the OS doesn't clear it out automatically (unlike /tmp);
> you could put your ports in /var/tmp/p. That would shorten the paths a lot,
> but I'm not sure if it'll shorten them enough to fit into the 256K arg
> length limit.
>

I am pretty sure that your suggestions of /var/tmp/p or /opt/ports would
shorten paths and result in a one time fix.  However I am also trying to
clean up port builds in general, for community benefit.  Therefore I am a
bit pedantic about clean port fixes.  Please bear with me.

The good news is that the upstream developer created an easy makefile fix
which will presumably be in the next GDAL release.  I will post the link in
https://trac.macports.org/ticket/59510.

Re: gdal@3.0.1_3: Argument list too long

[Dave Allured - NOAA Affiliate via macports-users]

Thanks to Ryan, Bill, Richard for all the advice about stack and maximum
command length.  I think the relation to stack size is something I picked
up from a Linux discussion.  Apparently some versions of Linux work this
way.

I have the longer user home prefix because my institutional network policy
prevents all write access to /opt/anything.  I will report this upstream to
gdal, and see if they can segment their giant link commands, or something.
One gdal user recently suggested the following, which seems viable (see
near bottom of the message):

https://github.com/OSGeo/gdal/issues/1429#issuecomment-481215759


On Fri, Nov 29, 2019 at 6:36 AM Richard L. Hamilton 
wrote:

>
> With some  OSs, ARG_MAX aka NCARGS  is adjustable, with others it isn't.
>  macOS's is not necessarily the lowest with an apparently fixed limit, but
> not exceptionally high either.
>

gdal@3.0.1_3: Argument list too long

[Dave Allured - NOAA Affiliate via macports-users]

I am trying to solve "Argument list too long" when building gdal@3.0.1_3
from source under macports.  The command that fails is "libtool clang++",
used here to combine a large number of objects into a single library
libgdal.la.  The trac ticket is https://trac.macports.org/ticket/59510 .

I found advice suggesting that the maximum command length is related to the
stack size.  I am not sure this is correct for Mac OS.  However, if true,
this would be an easy fix for argument list too long.

Can anyone tell me whether increasing the stack size would increase the
maximum command length?  If so, what is the best way to increase stack size
in a port file or patch, such that it would apply when this libtool command
is executed?

Re: output like "port list all" over the web?

[Dave Allured - NOAA Affiliate via macports-users]

On Sun, Aug 4, 2019 at 8:14 PM Christopher Chavez 
wrote:

>
> > On Aug 4, 2019, at 7:32 PM, Richard L. Hamilton 
> wrote:
> >
> > That got me to wondering if there's a way to get the equivalent of "port
> list all", all on one page, over the web; for someone that might not want to
> > install MacPorts, but wanted to see what its current versions of all its
> packages were (and perhaps even generate feedback on availability of newer
> > packages), that might be useful.
> >
> > I can get that on https://www.macports.org/ports.php?by=all but that's
> not all on one page, and it has a lot of other stuff that makes it more
> difficult
> > to consume as machine-readable.
>
> I’m just another user, but such a page containing all 21000+ ports sounds
> like an easy way to hang or crash the user's browser, so whatever links to
> it should probably warn "huge page--might crash your browser". I don't
> quite see how the complete listing is useful to a human (except maybe
> someone who likes reading the dictionary or the phone book for fun), so
> maybe only a plaintext and/or machine-readable format is sufficient.
>

So will it be sufficient to simply run "port list all" on the current
stable MacPorts package, as a frequent automatic process?  Capture the text
result and put it in a public downloadable location.

Re: "Fetching archive" fails for all ports on multiple systems, different networks

[Dave Allured - NOAA Affiliate via macports-users]

Otherwise, I am a macports novice.  In the absence of better advice, I
would be inclined to some hacking along the lines of uninstalling and
reinstalling things.  Wait and see if there is better advice from those who
know macports internals.


On Sat, Apr 13, 2019 at 6:20 PM Lee Finn  wrote:

> Hi Dave et al.
>
> I repeated the curl. The md5 checks: the xfer was completed correctly.
>
> Advice welcome!
>
> Sam
>
>
> On Apr 13, 2019, at 5:57 PM, Dave Allured - NOAA Affiliate via
> macports-users  wrote:
>
> I think you all are overlooking this report from a few days back.  The
> requested "curl" test passed on Sam's machine.  This strongly indicates a
> problem within Sam's Macports software, NOT a network problem.  Excerpt:
>
> On Mon, Apr 8, 2019 at 10:54 AM Lee Finn  wrote:
>
>> Hi Chris  ...  Thanks for your note  ...  Running the indicated command
>> gives the following:
>>
>> Quedo [2] Yeah? curl -O -R
>> https://packages.macports.org/libiconv/libiconv-1.15_0.darwin_18.x86_64.tbz2
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>> Current
>>  Dload  Upload   Total   SpentLeft
>> Speed
>> 100 1471k  100 1471k0 0  2719k  0 --:--:-- --:--:-- --:--:--
>> 2714k
>>
>
> Without seeing checksums, this "Received 1471K " is a perfect result which
> replicates on my own mac.  Curl reads this archive with no trouble at all.
> Sam, if you want to double check this curl result:
>
> mac56:~/temp/curl 9> md5 libiconv-1.15_0.darwin_18.x86_64.tbz2
> MD5 (libiconv-1.15_0.darwin_18.x86_64.tbz2) =
> 9fe8db26b61e61d0c1b44401d602955b
>
> Either let me know how I am misreading this, or else take a closer look at
> Sam's Macports setup.  I hope this helps!
>
> --Dave
>
>
> On Sat, Apr 13, 2019 at 1:28 PM Chris Jones 
> wrote:
>
>>
>> What network are you on ? Home or work ? Could something have changed
>> with that ?
>>
>> On 13 Apr 2019, at 8:04 pm, Lee Finn  wrote:
>>
>> Thank for your note.
>>
>> A quick question: since everything was working up until 1 Apr (I
>> routinely update my macports every monday, and did so as recently as 25
>> Mar), is there anything you can advise I look to first? The only system
>> updates that I’m aware of in that week were the 10.14.4 and xCode 10.2
>> updates.
>>
>> Thanks again,
>>
>> Sam
>>
>> —
>> Sam Finn
>> lsf...@gmail.com
>>
>>
>> On Apr 11, 2019, at 4:57 PM, Ryan Schmidt 
>> wrote:
>>
>> On Apr 10, 2019, at 10:28, Lee Finn wrote:
>>
>> Hi,
>>
>> This is a more directed followup to an earlier message.  Three specific
>> questions:
>>
>> * How should I interpret the error message  ":debug:archivefetch Fetching
>> archive failed: The requested URL returned error: 403 OK”, which appears in
>> the logfile for the installation of gettext?
>> - Further context: this error message occurs for all gettext servers on
>> two different networks (one a university network, one a home network) on
>> two different systems, over several days.
>> * Is anyone else seeing a similar or related problems? Please share
>> details: it will help me decide if this is somehow a local problem
>> (although it is happening on two independently maintained systems on two
>> different networks), or a macports problem for which a bug report should be
>> filed.
>>
>>
>> The web server appeared to return the response "403 OK". This is a
>> nonsensical response, since http standards tell us that "403" actually
>> means "Forbidden", while "200 OK" is the response you would get for a
>> normal successful file transfer. Since you get the same nonsensical
>> response from many servers managed by different organizations, it's logical
>> to conclude that the response is not actually coming from those servers but
>> from something intercepting the traffic between you and the servers -- such
>> as a badly-configured proxy managed by your network administrator, or
>> perhaps badly-written antivirus software installed on your computers which
>> is hooking itself into your network stream in an effort to protect you from
>> malicious content, or it could even be malware trying to modify your
>> network traffic for some nefarious purpose. Usually a workaround for
>> circumventing network interference is to use https, since man-in-the-middle
>> content modification is not possible with an encrypted data stream, but
>> your error messages in your previous mes

Re: "Fetching archive" fails for all ports on multiple systems, different networks

[Dave Allured - NOAA Affiliate via macports-users]

I think you all are overlooking this report from a few days back.  The
requested "curl" test passed on Sam's machine.  This strongly indicates a
problem within Sam's Macports software, NOT a network problem.  Excerpt:

On Mon, Apr 8, 2019 at 10:54 AM Lee Finn  wrote:

> Hi Chris  ...  Thanks for your note  ...  Running the indicated command
> gives the following:
>
> Quedo [2] Yeah? curl -O -R
> https://packages.macports.org/libiconv/libiconv-1.15_0.darwin_18.x86_64.tbz2
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100 1471k  100 1471k0 0  2719k  0 --:--:-- --:--:-- --:--:--
> 2714k
>

Without seeing checksums, this "Received 1471K " is a perfect result which
replicates on my own mac.  Curl reads this archive with no trouble at all.
Sam, if you want to double check this curl result:

mac56:~/temp/curl 9> md5 libiconv-1.15_0.darwin_18.x86_64.tbz2
MD5 (libiconv-1.15_0.darwin_18.x86_64.tbz2) =
9fe8db26b61e61d0c1b44401d602955b

Either let me know how I am misreading this, or else take a closer look at
Sam's Macports setup.  I hope this helps!

--Dave


On Sat, Apr 13, 2019 at 1:28 PM Chris Jones 
wrote:

>
> What network are you on ? Home or work ? Could something have changed with
> that ?
>
> On 13 Apr 2019, at 8:04 pm, Lee Finn  wrote:
>
> Thank for your note.
>
> A quick question: since everything was working up until 1 Apr (I routinely
> update my macports every monday, and did so as recently as 25 Mar), is
> there anything you can advise I look to first? The only system updates that
> I’m aware of in that week were the 10.14.4 and xCode 10.2 updates.
>
> Thanks again,
>
> Sam
>
> —
> Sam Finn
> lsf...@gmail.com
>
>
> On Apr 11, 2019, at 4:57 PM, Ryan Schmidt  wrote:
>
> On Apr 10, 2019, at 10:28, Lee Finn wrote:
>
> Hi,
>
> This is a more directed followup to an earlier message.  Three specific
> questions:
>
> * How should I interpret the error message  ":debug:archivefetch Fetching
> archive failed: The requested URL returned error: 403 OK”, which appears in
> the logfile for the installation of gettext?
> - Further context: this error message occurs for all gettext servers on
> two different networks (one a university network, one a home network) on
> two different systems, over several days.
> * Is anyone else seeing a similar or related problems? Please share
> details: it will help me decide if this is somehow a local problem
> (although it is happening on two independently maintained systems on two
> different networks), or a macports problem for which a bug report should be
> filed.
>
>
> The web server appeared to return the response "403 OK". This is a
> nonsensical response, since http standards tell us that "403" actually
> means "Forbidden", while "200 OK" is the response you would get for a
> normal successful file transfer. Since you get the same nonsensical
> response from many servers managed by different organizations, it's logical
> to conclude that the response is not actually coming from those servers but
> from something intercepting the traffic between you and the servers -- such
> as a badly-configured proxy managed by your network administrator, or
> perhaps badly-written antivirus software installed on your computers which
> is hooking itself into your network stream in an effort to protect you from
> malicious content, or it could even be malware trying to modify your
> network traffic for some nefarious purpose. Usually a workaround for
> circumventing network interference is to use https, since man-in-the-middle
> content modification is not possible with an encrypted data stream, but
> your error messages in your previous message showed that even https traffic
> was being modified; in the https cases, though, the modifications were
> being detected as a bad ssl stream. The problem is unique to your computers
> and/or your networks and you'll have to figure out what is modifying your
> network traffic and how to stop it; there's nothing we can change in
> MacPorts to fix this.
>
> * “sudo port diagnose” reports "Error: currently installed version of
> Xcode, 10.2, is not supported by MacPorts.  For your currently installed
> system, only the following versions of Xcode are supported:  10.1 10.0”.
> Trac #58260 suggests that this is a build problem; i.e., that it occurs
> after a successful fetch step. Is this understanding correct?
>
> Other information:
> MacPorts 2.5.4
> Mac OS 10.4.4
> xCode 10.2
> H/W: iMac Pro, MacBook Pro.
>
>
> Xcode 10.2 was released recently and we had not yet added it to the list
> of approved Xcode versions. Josh has since added it. It's usually fine to
> use new Xcode versions. As you found in #58260, sometimes new versions of
> Xcode cause build failures in some ports. As with any bug, these need to be
> identified and addressed on a case by case basis.
>
>

Re: Mirror unpacks distfile before sending

[Dave Allured - NOAA Affiliate via macports-users]

On Thu, Apr 4, 2019 at 11:27 AM Bill Cole <
macportsusers-20171...@billmail.scconsult.com> wrote:

> On 4 Apr 2019, at 12:45, Dave Allured - NOAA Affiliate via
> macports-users wrote:
>
> > On Wed, Apr 3, 2019 at 11:11 PM Mojca Miklavec 
> > wrote:
> >
> >> On Thu, 4 Apr 2019 at 06:34,  wrote:
> >>>
> >>> it's wierd. i'm seeing the same Content-Encoding header
> >>> but curl doesn't un-gzip the download for me. neither
> >>> /usr/bin/curl (7.43.0) nor /opt/local/bin/curl (7.64.1).
> >>> neither does wget. i wonder what the difference is.
> >>
> >> Probably not relevant for this, but some time ago I also had the same
> >> issue of auto-extracting tarballs; I thought it was the firewall
> >> (some
> >> content / antivirus checking software there) as I only had this
> >> problem in my office; everywhere else it worked as expected.
> >>
> >> Mojca
> >>
> >
> > That *is* relevant.  My Mac is behind an institutional firewall, so
> > this
> > might be aggravating the problem.  Also I am not able to duplicate the
> > headers as Ryan showed using curl -I, not with the facebook.net URL.
> > I
> > will ask our network admins about this.
> >
> > It sounds like Raf and Mojca are reporting correct, compressed
> > downloads
> > from this site, and I am the only one so far that has actually
> > reported
> > incorrect, uncompressed downloads.  (I checked; my mac gets the same
> > malfunction with all .tar.gz files from facebook.net, not just the
> > groff
> > file.)  Does anyone else here get the incorrect, uncompressed result,
> > which
> > is 17 Mb rather than the expected 4 Mb?
>
> Nope.
>
> Does ~/.curlrc exist? If so, what's in it?
> I can reproduce the behavior with the "--compress" option on the command
> line or in the .curlrc file.
>

Bill, thanks for these hints.  I do not have any ~/.curlrc.  On my mac, the
behavior was not affected in any way by --compress, --compressed,
--compressed-ssh, or --tr-encoding (two different curl versions).  This was
true for both the misbehaving mirror.facebook.net, as well as for a normal
mirror site.  It was as if our gateway was disabling or bypassing all of
these command line options, regardless of the target website.

Re: Mirror unpacks distfile before sending

[Dave Allured - NOAA Affiliate via macports-users]

On Thu, Apr 4, 2019 at 2:23 PM Ryan Schmidt  wrote:

>
> On Apr 4, 2019, at 11:45, Dave Allured wrote:
>
> > That *is* relevant.  My Mac is behind an institutional firewall, so this
> might be aggravating the problem.  Also I am not able to duplicate the
> headers as Ryan showed using curl -I, not with the facebook.net URL.  I
> will ask our network admins about this.
>
> What headers are you seeing then? Sounds like your corporate
> firewall/proxy may be rewriting headers and content. This of course is one
> of the reasons why so many sites are switching to https -- to prevent such
> often broken rewriting from taking place.
>

I learned that we have a corporate gateway in addition to a local
firewall.  It looks like this problem is boiling down to the combination of
a misconfiguration on mirror.facebook.net, and unexpected content
processing with possible misconfiguration on our gateway.  This explains
why all client software, users, and OS types inside our local network get
unavoidable unwanted decompression, yet nobody outside sees the problem.
My network expert agrees, https rather than http would likely prevent this.

Here are the requested headers as seen by curl on my local mac.  These have
obviously been altered somewhere in transit, compared to what Ryan reported
earlier:

> curl -I http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gz
HTTP/1.1 200 OK
Via: 1.1 137.75.75.19 (McAfee Web Gateway 7.7.2.13.0.25943)
Date: Thu, 04 Apr 2019 22:00:32 GMT
Server: Apache
Connection: Keep-Alive
Content-Type: application/x-gzip
Accept-Ranges: bytes
Last-Modified: Sun, 23 Dec 2018 15:06:58 GMT

I still think there is a misconfiguration of the facebook.net mirror. It is
> sending the "Content-Encoding: x-gzip" header. That means the server is
> claiming it has gzipped the content prior to sending it and the client
> should un-gzip the content upon receiving it. So one of two things happened:
>

Ryan, I think you are right on about the invalid Content-Encoding header.
This was a key observation that helped our diagnosis.


> either 1. Facebook gzipped a gzip file, sent it, and the client should
> remove the outer gzipping it to leave you with a gzip file. If this is
> what's happening, it's stupid because there's no reason to gzip an
> already-compressed file; Facebook should stop doing that. Perhaps your
> firewall/proxy is misinterpreting this situation and it is removing all
> layers of gzip compression, not just the first one.
>
> or 2. Facebook is transferring the original gzip file to you but claiming
> that it compressed it and that the client should ungzip it. If this is
> what's happening, it's lying, and I would expect any client to
> (undesirably, in this case) decompress it before saving it. I can confirm
> that curl does decompress it before saving it if the --compressed flag is
> used; I guess curl doesn't react to the Content-Encoding header unless it
> requested a compressed response in the first place. Since your client (not
> your your firewall/proxy) made the original request, maybe the
> firewall/proxy doesn't know (or doesn't keep track of) whether the request
> was for a compressed or uncompressed resource, and it just looks at the
> Content-Encoding header to decide, which seems like a reasonable decision.
> It points out an additional misconfiguration of the facebook.net server:
> they're sending (or claiming to send) a compressed response even when the
> client did not request it; Facebook should stop doing that and should send
> what the client asked it to send.
>

We can access tar.gz files on other mirror sites without problem.  This
enhances the case for misconfiguration on mirror.facebook.net.  But I still
wonder whether there is a possible fix for our local gateway software.  I
will follow through with both our corporate network admins, and facebook
support.

Here is one more curiosity.  It is only *.gz files that are mishandled.
Other compressed types such as *.xz and *.rpm are downloaded correctly.

Re: Mirror unpacks distfile before sending

[Dave Allured - NOAA Affiliate via macports-users]

On Wed, Apr 3, 2019 at 11:11 PM Mojca Miklavec  wrote:

> On Thu, 4 Apr 2019 at 06:34,  wrote:
> >
> > it's wierd. i'm seeing the same Content-Encoding header
> > but curl doesn't un-gzip the download for me. neither
> > /usr/bin/curl (7.43.0) nor /opt/local/bin/curl (7.64.1).
> > neither does wget. i wonder what the difference is.
>
> Probably not relevant for this, but some time ago I also had the same
> issue of auto-extracting tarballs; I thought it was the firewall (some
> content / antivirus checking software there) as I only had this
> problem in my office; everywhere else it worked as expected.
>
> Mojca
>

That *is* relevant.  My Mac is behind an institutional firewall, so this
might be aggravating the problem.  Also I am not able to duplicate the
headers as Ryan showed using curl -I, not with the facebook.net URL.  I
will ask our network admins about this.

It sounds like Raf and Mojca are reporting correct, compressed downloads
from this site, and I am the only one so far that has actually reported
incorrect, uncompressed downloads.  (I checked; my mac gets the same
malfunction with all .tar.gz files from facebook.net, not just the groff
file.)  Does anyone else here get the incorrect, uncompressed result, which
is 17 Mb rather than the expected 4 Mb?

Reminder:  curl -O -R
http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gz

--Dave

Re: Mirror unpacks distfile before sending

[Dave Allured - NOAA Affiliate via macports-users]

On Tue, Apr 2, 2019 at 10:38 PM Ryan Schmidt 
wrote:

> On Apr 2, 2019, at 23:21, Bill Cole wrote:
>
> > On 2 Apr 2019, at 23:45, Dave Allured - NOAA Affiliate wrote:
> >
> > [snip]
> >>
> >> I have never before seen this sort of fradulent behavior, silent
> unpacking,
> >> from either an http hosted data site, or the curl command.  Can anyone
> else
> >> confirm this weird download behavior from that facebook.net mirror?  Is
> >> there an alternate explanation?
> >
> > Yes.
> >
> > It sounds like the mirror may have a wrong-ish implementation of HTTP
> Compression. (See https://en.wikipedia.org/wiki/HTTP_compression) I've
> seen similar oddness dependent on the client request headers.
> >
> > This might be something to bring to the attention of Facebook or GNU,
> since that's a GNU mirror.
>
> I agree, it is a misconfiguration of the Facebook mirror server. Dave,
> could you please report it to them?
>
> Here is what the headers should look like, from ftp.gnu.org:
>
> $ curl -I https://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz
> HTTP/1.1 200 OK
> Date: Wed, 03 Apr 2019 04:32:52 GMT
> Server: Apache/2.4.7 (Trisquel_GNU/Linux)
> Strict-Transport-Security: max-age=63072000
> Last-Modified: Sun, 23 Dec 2018 15:06:58 GMT
> ETag: "3f2208-57db1d4efd451"
> Accept-Ranges: bytes
> Content-Length: 4137480
> Content-Security-Policy: default-src 'self'; img-src 'self'
> https://static.fsf.org https://gnu.org; object-src 'none';
> frame-ancestors 'none'; child-src 'self' https://static.gnu.org
> https://static1p.gnu.org https://static1p.fsf.org
> X-Frame-Options: DENY
> X-Content-Type-Options: nosniff
> Content-Type: application/x-gzip
>
> Here are the headers Facebook's mirror is sending:
>
> $ curl -I http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gz
> HTTP/1.1
>  200 OK
> Date: Wed, 03 Apr 2019 04:33:02 GMT
> Server: Apache
> Last-Modified: Sun, 23 Dec 2018 15:06:58 GMT
> Accept-Ranges: bytes
> Content-Length: 4137480
> Connection: close
> Content-Type: application/x-gzip
> Content-Encoding: x-gzip
>
> Note the incorrect "Content-Encoding: x-gzip". That header means that the
> data has been gzip-compressed for transmission by the server, and the
> client should un-gzip it before presenting it to the user. But that is not
> what anybody wants here. We want the client to receive the original
> unmodified .tar.gz file.
>

Bill and Ryan,

Thanks for the expert diagnosis.  I will report this.  Can anyone recommend
optimal bug reporting channels for facebook.net and GNU, without requiring
a Facebook account?

Mirror unpacks distfile before sending

[Dave Allured - NOAA Affiliate via macports-users]

I'm new to this mailing list.  I ran into a strange problem tonight with
one of the mirror sites.  While running a port update on a different port,
I got a checksum error on this distfile:

http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gz

I tried manually downloading using curl, from both this site and a
different mirror.  The other site provided a correct version with two
correct checksums and a correct size match, when compared with expected
checksums in the current groff port file.

Here is the weird part.  It seems like the facebook.net mirror (or perhaps
my curl command) was silently un-gzipping the tar file before delivery to
my local disk, and without removing the ".gz" extension.  When I gunzipped
the "legitimate" tar file from the other mirror, it was bit identical with
the supposedly packed tar file from the facebook mirror.  I tested this
several times and always got the same strange result.

Reference mirror and gunzipped contents:
-rw-r--r--  14137480 Jan 26 14:37:23 2019 1/groff-1.22.4.tar.gz
-rw-r--r--  1   17827840 Jan 26 14:37:23 2019 1/gunzip/groff-1.22.4.tar

Facebook.net mirror:
-rw-r--r--  1   17827840 Dec 23 08:06:58 2018 3/groff-1.22.4.tar.gz

> diff -qs 1/gunzip/groff-1.22.4.tar 3/groff-1.22.4.tar.gz
Files 1/gunzip/groff-1.22.4.tar and 3/groff-1.22.4.tar.gz are identical

There was nothing else weird that I could see with my repeated curl command
attempts.  It looks like facebook.net wants to "magically" unpack the
requested tar.gz file before sending.  This results in checksum breakage
during port update.

I have never before seen this sort of fradulent behavior, silent unpacking,
from either an http hosted data site, or the curl command.  Can anyone else
confirm this weird download behavior from that facebook.net mirror?  Is
there an alternate explanation?  Thanks for taking a look at this.

--Dave