Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole

[Gerben Wierda]

I’m running unbound. If I use file logging, it neatly ends up in the file I 
want. If I set syslog in the conf file (this is standard in macports unbound by 
the way) I get nothing. Logging disappears into a black hole, probably the same 
black hole where mail logging from postfix disappears in on High Sierra Server.

   use-syslog: 
  Sets unbound to send log messages to  the  syslogd,  using  sys-
  log(3).   The  log  facility  LOG_DAEMON  is used, with identity
  "unbound".  The logfile setting is overridden when use-syslog is
  turned on.  The default is to log to syslog.

How do I make sure that I get to see the syslog messages. Probably by adapting 
/etc/asl.conf and /etc/syslog.conf? Or is it a matter of ASL hiding these kinds 
of messages from ordinary users? Is there a way to tell asl/syslog to put the 
logging output of unbound into a (log rotated) file in e.g. /var/log?


PS. Apple is apparently playing around with unbound too:

luna:~ gerben$ ls -l /usr/share/man/man8/unbound.8 
-rw-r--r--  1 root  wheel  2342 Aug 23  2018 /usr/share/man/man8/unbound.8

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Riccardo Mottola via macports-users]

Hi all,

On 8/14/19 4:58 PM, Kenneth F. Cunningham wrote:

On 2019-08-14, at 7:52 AM, Kenneth F. Cunningham wrote:


/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46:
error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),

I have fixed this error on several occasions previously -- I believe by adding 
"-fpermissive" as it suggests in the error.

I thought I had that committed somewhere in my LeopardPorts repo, but 
apparently not. I know I have it somewhere, probably on my 10.5 Intel VM.



Ah yes -- I put the info here (and a lot more harfbuzz analysis as well):





I finally managed to avoid this problem because I was able to build 
clang 5.0 and then built harfbuzz with clang 5.0 and this worked fine.


Could we add -fpermissive only when using gcc? is the compiler type 
available? maybe something like compiler + mac version.


Since PPC does not have clang, it will be bitten by this issue.

Riccardo

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Riccardo Mottola via macports-users]

Hi,

On 8/14/19 3:05 PM, Ryan Schmidt wrote:

I tried building with clang-3.7 but it doesn't work, because the port wants 
then to issue -stdlib=macports-libstdc++, which clang 3.7 does not understand.

We didn't backport that feature to clang-3.7? I wonder why we didn't.



Clang-3.9 is no more and I am unable to get clang 5.0 on 10.5, but that is a 
different issue, I suppose and will report it separately.



3.7 can't handle that, the solution for me was to get 5.0 up and running 
- so no urgency. But enabling the -fpermissive flag for GCC only could 
be an interesting thing in the Portfile and avoid future headaches.



Riccardo

poppler and leopard - LegacySupport issues

[Riccardo Mottola via macports-users]

Hi!


now that I unblocked cmake and clang-5.0, I continue installing 
dependencies for gimp2!


Poppler is on the way, I get the error below. It is already building 
with clang 5.0 and the issue appears to be LegacySupport itself.



[  1%] Building CXX object CMakeFiles/poppler.dir/goo/gbasename.cc.o
/opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler 
-I/opt/local/include -I/opt/local/include/freetype2 
-I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
-Wno-unused-parameter -Wcast-align -Wformat-security 
-Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
-Woverloaded-virtual -Wmissing-declarations -Wundef 
-Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
-D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
-I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
CMakeFiles/poppler.dir/goo/gbasename.cc.o -c 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc
/opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler 
-I/opt/local/include -I/opt/local/include/freetype2 
-I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
-Wno-unused-parameter -Wcast-align -Wformat-security 
-Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
-Woverloaded-virtual -Wmissing-declarations -Wundef 
-Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
-D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
-I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
CMakeFiles/poppler.dir/goo/gbase64.cc.o -c 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbase64.cc
In file included from 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc:46:
/opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm 
label

extern char *realpath(const char * __restrict, char * __restrict)
 ^
/usr/include/stdlib.h:226:60: note: previous declaration is here
char    *realpath(const char * __restrict, char * __restrict) 
__DARWIN_EXTSN(realpath);

  ^
/usr/include/sys/cdefs.h:365:36: note: expanded from macro '__DARWIN_EXTSN'
#define __DARWIN_EXTSN(sym) __asm("_" __STRING(sym) 
__DARWIN_SUF_EXTSN)

  ^
1 error generated.
make[2]: *** [CMakeFiles/poppler.dir/goo/gbasename.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs


Am I missing some other "trick" ?


Thank you,

Riccardo

libuv fails to build on 10.8.5

[Dmitri Zaitsev]

Please let me know if anyone has an idea how to fix this problem.

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

Cheers,
Dmitri.

sudo port install libuv
--->  Computing dependencies for libuv
--->  Fetching distfiles for libuv
--->  Verifying checksums for libuv
--->  Extracting libuv
--->  Applying patches to libuv
--->  Configuring libuv
--->  Building libuv
Error: Failed to build libuv: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libuv/libuv/main.log
for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port libuv failed



-- 
Dmitri Zaitsev
School of Mathematics
Trinity College Dublin

WWW:  http://www.maths.tcd.ie/~zaitsev/

Re: poppler and leopard - LegacySupport issues

[Kenneth F. Cunningham]

> [  1%] Building CXX object CMakeFiles/poppler.dir/goo/gbasename.cc.o
> /opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler
>  
> -I/opt/local/include -I/opt/local/include/freetype2 
> -I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
> -Wno-unused-parameter -Wcast-align -Wformat-security 
> -Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
> -Woverloaded-virtual -Wmissing-declarations -Wundef 
> -Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
> -D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
> -I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
> x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
> CMakeFiles/poppler.dir/goo/gbasename.cc.o -c 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc
> /opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler
>  
> -I/opt/local/include -I/opt/local/include/freetype2 
> -I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
> -Wno-unused-parameter -Wcast-align -Wformat-security 
> -Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
> -Woverloaded-virtual -Wmissing-declarations -Wundef 
> -Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
> -D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
> -I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
> x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
> CMakeFiles/poppler.dir/goo/gbase64.cc.o -c 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbase64.cc
> In file included from 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc:46:
> /opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm 
> label
> extern char *realpath(const char * __restrict, char * __restrict)
>   ^
> /usr/include/stdlib.h:226:60: note: previous declaration is here
> char*realpath(const char * __restrict, char * __restrict) 
> __DARWIN_EXTSN(realpath);
>^
> /usr/include/sys/cdefs.h:365:36: note: expanded from macro '__DARWIN_EXTSN'
> #define __DARWIN_EXTSN(sym) __asm("_" __STRING(sym) 
> __DARWIN_SUF_EXTSN)
>^
> 1 error generated.
> make[2]: *** [CMakeFiles/poppler.dir/goo/gbasename.cc.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> 
> 
> Am I missing some other "trick" ?
> 
> 
> Thank you,
> 
> Riccardo

Ah, this looks similar to  the error you reported for cmake, now.

I think you are seeing this because you are trying to build poppler as 64bit on 
10.5 Intel. 

You are quite possibly the only one

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> Since PPC does not have clang, it will be bitten by this issue.

PPC does not have this issue. Many details in the referenced harfbuzz ticket.

Ken

Re: Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole

[Daniel J. Luke]

High Sierra switched the way syslog works on Mac OS (see 
https://developer.apple.com/documentation/os/logging). This replaced the ASL 
(and syslog) stuff.

you can use the 'log' command line utility to view the logs.

[I am not a fan of the way this stuff works now]

> On Aug 15, 2019, at 3:46 AM, Gerben Wierda  wrote:
> 
> I’m running unbound. If I use file logging, it neatly ends up in the file I 
> want. If I set syslog in the conf file (this is standard in macports unbound 
> by the way) I get nothing. Logging disappears into a black hole, probably the 
> same black hole where mail logging from postfix disappears in on High Sierra 
> Server.
> 
>use-syslog: 
>   Sets unbound to send log messages to  the  syslogd,  using  sys-
>   log(3).   The  log  facility  LOG_DAEMON  is used, with identity
>   "unbound".  The logfile setting is overridden when use-syslog is
>   turned on.  The default is to log to syslog.
> 
> How do I make sure that I get to see the syslog messages. Probably by 
> adapting /etc/asl.conf and /etc/syslog.conf? Or is it a matter of ASL hiding 
> these kinds of messages from ordinary users? Is there a way to tell 
> asl/syslog to put the logging output of unbound into a (log rotated) file in 
> e.g. /var/log?
> 
> PS. Apple is apparently playing around with unbound too:
> 
> luna:~ gerben$ ls -l /usr/share/man/man8/unbound.8 
> -rw-r--r--  1 root  wheel  2342 Aug 23  2018 /usr/share/man/man8/unbound.8

-- 
Daniel J. Luke

Mojave and MacPorts update

[Bill Stackhouse]

I've used MacPorts often prior to upgrading to 10.14, and today for the first 
time tried running ports update. It fails with the following log entries. I 
have added terminal to "Full Disk Access".

Any suggestions for fixing the problem?
Thanks
Bill


sudo port upgrade outdated

Log entries --

:debug:sysinfo macOS 10.14 (darwin/18.2.0) arch i386
:debug:sysinfo MacPorts 2.5.4
:debug:sysinfo Xcode 10.3
:debug:sysinfo SDK 10.14
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.14
:debug:main apr has no conflicts
:debug:main Executing org.macports.main (apr)
:debug:main dropping privileges: euid changed to 502, egid changed to 500.
:debug:main Skipping completed org.macports.archivefetch (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.fetch (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.checksum (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.extract (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.patch (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.configure (apr)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:build build phase started at Thu Aug 15 10:27:04 PDT 2019
:notice:build --->  Building apr
:debug:build Executing org.macports.build (apr)
:debug:build Environment: 
:debug:build CC_PRINT_OPTIONS='YES'
:debug:build 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/.CC_PRINT_OPTIONS'
:debug:build CPATH='/opt/local/include'
:debug:build LIBRARY_PATH='/opt/local/lib'
:debug:build MACOSX_DEPLOYMENT_TARGET='10.14'
:info:build Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0"
 && /usr/bin/make -j4 -w all 
:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0"
 && /usr/bin/make -j4 -w all 
:info:build make: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0'
:info:build make[1]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0'
:info:build /bin/sh 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/libtool
 --silent --mode=link /usr/bin/clang   -pipe -Os 
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
 -arch x86_64 -DHAVE_CONFIG_H  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK 
-DDARWIN_10  -I/opt/local/include 
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
 -I./include 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/include/arch/unix
 -I./include/arch/unix 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/include/arch/unix
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/include
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/include/private
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_apr/apr/work/apr-1.7.0/include/private
   -version-info 7:0:7   -L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
 -arch x86_64 -o libapr-1.la -rpath /opt/local/lib encoding/apr_encode.lo 
encoding/apr_escape.lo passwd/apr_getpass.lo strings/apr_cpystrn.lo 
strings/apr_cstr.lo strings/apr_fnmatch.lo strings/apr_snprintf.lo 
strings/apr_strings.lo strings/apr_strnatcmp.lo strings/apr_strtok.lo 
tables/apr_hash.lo tables/apr_skiplist.lo tables/apr_tables.lo 
atomic/unix/builtins.lo atomic/unix/builtins64.lo atomic/unix/ia32.lo 
atomic/unix/mutex.lo atomic/unix/mutex64.lo atomic/unix/ppc.lo 
atomic/unix/s390.lo atomic/unix/solaris.lo dso/unix/dso.lo 
file_io/unix/buffer.lo file_io/unix/copy.lo file_io/unix/dir.lo 
file_io/unix/fileacc.lo file_io/unix/filedup.lo file_io/unix/filepath.lo 
file_io/unix/filepath_util.lo file_io/unix/filestat.lo file_io/unix/flock.lo 
file_io/unix/fullrw.lo file_io/unix/m

Re: Mojave and MacPorts update

[Ryan Schmidt]

On Aug 15, 2019, at 12:36, Bill Stackhouse wrote:
> 
> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) 
> malformed object (unknown load command 1)

This means your cctools port is too old to understand what's coming out of the 
compiler. Try reinstalling the cctools port with the +xcode variant. 

Re: Mojave and MacPorts update

[Bill Stackhouse]

Thanks Ryan. That solved the problem.
Bill

> On Aug 15, 2019, at 10:44 AM, Ryan Schmidt  wrote:
> 
> 
> 
> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote:
>> 
>> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) 
>> malformed object (unknown load command 1)
> 
> This means your cctools port is too old to understand what's coming out of 
> the compiler. Try reinstalling the cctools port with the +xcode variant. 

Re: Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole

[Gerben Wierda]

> On 15 Aug 2019, at 17:48, Daniel J. Luke  wrote:
> 
> High Sierra switched the way syslog works on Mac OS (see 
> https://developer.apple.com/documentation/os/logging 
> ). This replaced the 
> ASL (and syslog) stuff.

I first thought: that can’t be right, can it? ASL is still there, /etc/asl and 
/etc/.asl.conf is still there. Man pages are still there. syslogd runs in the 
background. Console and log work against the ASL infrastructure. asl.conf 
contains all this information (as described in the man page for asl.conf).

A command like logger still works (produces syslog messages).

But then I found 
https://eclecticlight.co/2018/03/19/macos-unified-log-1-why-what-and-how/ 


Now, that says that syslog messages also end up in Unified Logging. What it 
doesn’t say how for instance old style messages for facility mail with level 
notice end up there. Or with facility daemon with level info. So, how to get 
these out is still a riddle.

I have found a GUI app: 
https://eclecticlight.co/consolation-t2m2-and-log-utilities/ 


So, I’m going to try that.

Or I’m going to live with the fact that unbound and nsd write logs in the 
chroot-ed /opt/local/etc/{nsd,unbound} and figure out how to get log rotation 
working for these while unbound and nsd keep running.

Why did Apple leave all the ASL stuff in place if it isn’t functional anymore? 
It’s still there in Mojave. Why did they not offer a decent compatibility? 
Afraid people would not move to OS-specific log commands? Sigh.

G

> 
> you can use the 'log' command line utility to view the logs.
> 
> [I am not a fan of the way this stuff works now]
> 
>> On Aug 15, 2019, at 3:46 AM, Gerben Wierda  wrote:
>> 
>> I’m running unbound. If I use file logging, it neatly ends up in the file I 
>> want. If I set syslog in the conf file (this is standard in macports unbound 
>> by the way) I get nothing. Logging disappears into a black hole, probably 
>> the same black hole where mail logging from postfix disappears in on High 
>> Sierra Server.
>> 
>>   use-syslog: 
>>  Sets unbound to send log messages to  the  syslogd,  using  sys-
>>  log(3).   The  log  facility  LOG_DAEMON  is used, with identity
>>  "unbound".  The logfile setting is overridden when use-syslog is
>>  turned on.  The default is to log to syslog.
>> 
>> How do I make sure that I get to see the syslog messages. Probably by 
>> adapting /etc/asl.conf and /etc/syslog.conf? Or is it a matter of ASL hiding 
>> these kinds of messages from ordinary users? Is there a way to tell 
>> asl/syslog to put the logging output of unbound into a (log rotated) file in 
>> e.g. /var/log?
>> 
>> PS. Apple is apparently playing around with unbound too:
>> 
>> luna:~ gerben$ ls -l /usr/share/man/man8/unbound.8 
>> -rw-r--r--  1 root  wheel  2342 Aug 23  2018 /usr/share/man/man8/unbound.8
> 
> -- 
> Daniel J. Luke

Re: Mojave and MacPorts update

[Chris Jones]

> On 15 Aug 2019, at 6:44 pm, Ryan Schmidt  wrote:
> 
> 
> 
>> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote:
>> 
>> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) 
>> malformed object (unknown load command 1)
> 
> This means your cctools port is too old to understand what's coming out of 
> the compiler. Try reinstalling the cctools port with the +xcode variant. 

 Note that the xcode variant is no longer the default. i would recommend 
instead just using the current defaults of cctools.

Chris

How to import opencv4 in python?

[Zhong Ren]

I have just installed the port opencv4.  But how do I import it in python?  I 
used to “import cv2” with opencv 3.4.3.  Thanks.

Zhong

Re: Mojave and MacPorts update

[Ryan Schmidt]

On Aug 15, 2019, at 14:05, Chris Jones wrote:

> On 15 Aug 2019, at 6:44 pm, Ryan Schmidt wrote:
> 
>>> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote:
>>> 
>>> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) 
>>> malformed object (unknown load command 1)
>> 
>> This means your cctools port is too old to understand what's coming out of 
>> the compiler. Try reinstalling the cctools port with the +xcode variant. 
> 
> Note that the xcode variant is no longer the default. i would recommend 
> instead just using the current defaults of cctools.

If that works, sure.

But the xcode variant is the only variant that effectively changes the version 
of the software provided. Without the xcode variant, the port builds a cctools 
version comparable to that shipped with Xcode 10.0. If the code produced by the 
compilers in the current more-recent version of Xcode is no longer compatible 
with the cctools software from Xcode 10.0, then using default variants will not 
work, and the xcode variant will have to be used, until such a time as Apple 
releases a newer version of the cctools source code and the cctools port is 
updated to that version.

Or you could be right. It could be that it's the llvm version that matters, and 
building cctools with an older llvm variant will not work with the object files 
produced by newer Xcode's compilers. If that's the case, then just using a 
newer llvm variant is the solution.

Re: libuv fails to build on 10.8.5

[Ryan Schmidt]

On Aug 15, 2019, at 07:49, Dmitri Zaitsev wrote:

> Please let me know if anyone has an idea how to fix this problem.
> 
> https://trac.macports.org/ticket/58840
> 
> Cheers, 
> Dmitri.
> 
> sudo port install libuv
> --->  Computing dependencies for libuv
> --->  Fetching distfiles for libuv
> --->  Verifying checksums for libuv
> --->  Extracting libuv
> --->  Applying patches to libuv
> --->  Configuring libuv
> --->  Building libuv
> Error: Failed to build libuv: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libuv/libuv/main.log
>  for details.
> Error: Follow 
> https://guide.macports.org/#project.tickets
>  to report a bug.
> Error: Processing of port libuv failed

Just to provide closure for this thread, the ticket has been resolved via a 
change to macports-legacy-support.

Re: Is it possible to influence at what UID MacPorts start to create users?

[Ryan Schmidt]

On Aug 14, 2019, at 17:49, Gerben Wierda wrote:

> If this is a bug, I suggest using 600, not 500 for the fix.100 local users on 
> a mac seems adequate (like 640kB…) and server starts at 1025, so ample room 
> for services.

As I said, I believe our intention was to use the same range of UIDs and GIDs 
that Apple used to create normal user accounts. If Apple starts at 501, it was 
a bug for us to start at 500, and the fix for the bug would be to start at 501.

Note that we also create a "macports" user and group at MacPorts installation 
time. The code for that is separate from the code that creates users and groups 
for ports. There are two copies of the "macports" user/group creation code: one 
in Makefile.in for users who build from source, and one in the Installer 
package, the source for which is in portmgr/dmg/postflight.in. Both of these 
search for an empty UID starting at 501, not 500. And they don't specify what 
range to use for group IDs; they just ask the system for the next free GID.

If you want our range not to overlap Apple's range, that's a separate feature 
request that we could certainly consider. Off the top of my head I can't think 
of any problems with that but I don't know why it was originally chosen to 
overlap Apple's range.

Note that our user handling originates from an old version of Mac OS X in which 
Apple created both a UID and a GID for each user. (Tiger and earlier maybe?) 
Current versions of macOS no longer do that; for example my main user is not a 
member of its own group, but rather of the group "staff". I don't know if it 
still makes sense for us to create a separate group for each user that we 
create, but I suppose that's another separate issue.

Re: How to import opencv4 in python?

[Chris Jones]

Hi,

Whilst the opencv (3.x) port has variants to enable python support, these 
appear to be missing currently in the opencv4 port.

https://github.com/macports/macports-ports/blob/master/graphics/opencv/Portfile

https://github.com/macports/macports-ports/blob/master/graphics/opencv4/Portfile

If you wish these to be added, you should either file a trac ticket requesting 
the addition,

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

Or, even better, submit your open github pr implementing support at

https://guide.macports.org/chunked/project.github.html

Chris

> On 15 Aug 2019, at 10:36 pm, Zhong Ren  wrote:
> 
> I have just installed the port opencv4.  But how do I import it in python?  I 
> used to “import cv2” with opencv 3.4.3.  Thanks.
> 
> Zhong

Re: Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole

[Daniel J. Luke]

On Aug 15, 2019, at 2:53 PM, Gerben Wierda  wrote:
> Now, that says that syslog messages also end up in Unified Logging. What it 
> doesn’t say how for instance old style messages for facility mail with level 
> notice end up there. Or with facility daemon with level info. So, how to get 
> these out is still a riddle.

They show up in unified logging. I found reading through the various manpages 
to be helpful - and there's an old WWDC video that you might find interesting: 
https://developer.apple.com/videos/play/wwdc2016/721/ 

> Why did Apple leave all the ASL stuff in place if it isn’t functional 
> anymore? It’s still there in Mojave. Why did they not offer a decent 
> compatibility? Afraid people would not move to OS-specific log commands? Sigh.

Stuff compiled against previous versions of Mac OS X continues to work using 
the 'old' stuff (ie, if you built your own postfix and then upgraded your OS - 
it would still log the way it had done previously). I had a bunch of 
syslog.conf stuff that I moved to asl.conf that I now just don't have (or have 
half-replaced with use of the 'log' command). I find using 'log' to find logs 
much worse than using text-processing tools on text files - but we have to work 
with what we get from Apple.

-- 
Daniel J. Luke

Re: Is it possible to influence at what UID MacPorts start to create users?

[Gerben Wierda]

> On 16 Aug 2019, at 01:13, Ryan Schmidt  wrote:
> 
> 
> 
> On Aug 14, 2019, at 17:49, Gerben Wierda wrote:
> 
>> If this is a bug, I suggest using 600, not 500 for the fix.100 local users 
>> on a mac seems adequate (like 640kB…) and server starts at 1025, so ample 
>> room for services.
> 
> As I said, I believe our intention was to use the same range of UIDs and GIDs 
> that Apple used to create normal user accounts. If Apple starts at 501, it 
> was a bug for us to start at 500, and the fix for the bug would be to start 
> at 501.
> 
> Note that we also create a "macports" user and group at MacPorts installation 
> time. The code for that is separate from the code that creates users and 
> groups for ports. There are two copies of the "macports" user/group creation 
> code: one in Makefile.in for users who build from source, and one in the 
> Installer package, the source for which is in portmgr/dmg/postflight.in. Both 
> of these search for an empty UID starting at 501, not 500. And they don't 
> specify what range to use for group IDs; they just ask the system for the 
> next free GID.
> 
> If you want our range not to overlap Apple's range, that's a separate feature 
> request that we could certainly consider. Off the top of my head I can't 
> think of any problems with that but I don't know why it was originally chosen 
> to overlap Apple's range.
> 
> Note that our user handling originates from an old version of Mac OS X in 
> which Apple created both a UID and a GID for each user. (Tiger and earlier 
> maybe?) Current versions of macOS no longer do that; for example my main user 
> is not a member of its own group, but rather of the group "staff". I don't 
> know if it still makes sense for us to create a separate group for each user 
> that we create, but I suppose that's another separate issue.

I know that latter. For services and daemons, Apple still creates user/groups 
with identical separate names. And these are what the MacPorts generally need. 
For actual users, even in the NeXT days if I recall correctly, it was multiple 
users in a group like staff/admin/wheel (very early, the latter two for admin 
users), but I might be wrong here.

luna:~ gerben$ dscl . -list /Users
_amavisd
_analyticsd
_appleevents
_applepay
_appowner
_appserver
_appstore
etc

luna:~ gerben$ dscl . -list /Groups
_amavisd
_analyticsd
_analyticsusers
_appleevents
_applepay
_appowner
_appserveradm
_appserverusr
_appstore
etc

If you have multiple Macs and you want to have the same uid for users on them, 
you create them in the same order. Now, normally you do that at the start 
before you get to do things like MacPorts, but in this case I did not.

So, what I need is build macports from source if I want to change this 
behaviour? 

G

Re: firefox

[Dave Horsfall]

On Thu, 15 Aug 2019, Jack L. wrote:

My experience with firefox is it gets slower and slower and slower until 
it's practically unusable until it's restarted (even having only the 
gmail tab open for days)


That used to happen to me with some older versions; no problems with 
68.0.1 (on Sierra).


-- Dave