[mysql57] build error on 10.6 Snow Leopard i386
info:build make[2]: *** No rule to make target `archive_output_directory/libmysqlclient.a', needed by `client/mysqlbinlog'. Stop. :info:build make[2]: *** Waiting for unfinished jobs :info:build [ 76%] Building CXX object client/CMakeFiles/mysqlbinlog.dir/mysqlbinlog.cc.o :info:build make[2]: *** No rule to make target `archive_output_directory/libmysqlclient.a', needed by `rapid/plugin/x/mysqlxtest'. Stop. :info:build make[2]: *** Waiting for unfinished jobs :info:build [ 77%] Building CXX object rapid/plugin/x/CMakeFiles/mysqlxtest.dir/generated/protobuf/mysqlx_resultset.pb.cc.o see : https://macports.mathiesen.info/10.6-i386/mysql57-main.log bug ? can I fix it myself ? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø MacOS X 10.11 El Capitan ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
[mysql8] build error on 10.6 Snow Leopard i386
:info:build [ 43%] Built target perfschema
:info:build make[1]: Leaving directory
`/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory
`/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build'
:info:build Command failed: cd
"/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build"
&& /usr/bin/make -j2 -w all VERBOSE=ON
:info:build Exit code: 2
:error:build Failed to build mysql8: command execution failed
:debug:build Error code: CHILDSTATUS 13266 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec build"
:debug:build (procedure "portbuild::build_main" line 8)
:debug:build invoked from within
:debug:build "$procedure $targetname"
see : https://macports.mathiesen.info/10.6-i386/mysql8-main.log
bug ? can I fix it myself ?
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
MacOS X 10.11 El Capitan ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [mysql8] build error on 10.6 Snow Leopard i386
Thank you for your response / feedback / analysis [thumbsUP]
Christopher Jones wrote:
>
> Hi,
>
> You missed the important errors in that log
>
> /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libclientlib.a(libmysql.cc.o)
> malformed object (unknown load command 2)
> :info:build /usr/bin/libtool: object:
>
> /usr/bin/libtool will be the system one, which on your ancient system
> will be very very out of date.
>
> The cctools port should be providing a more up to date alternative. Do
> you have cctools installed ? If so, what variants etc. ? Try installing
> it with the default variants, if you don’t already have it, and then try
> again.
#=> port installed name:^{cctools,libtool}
The following ports are currently installed:
cctools @921_3+llvm80 (active)
libtool @2.4.6_6 (active)
So, for some reaon, the build process is looking outside the macports
framework for libtool; even though it shouldn't
possible solutions
1) rename /usr/bin/libtool
2) symlink /usr/bin/libtool -> /macports/bin/libtool
3) enable macports trace mode
I'll try them in order and see, what happens [nerd]
>
> Chris
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: Problems With Mysql57
Ryan Schmidt wrote:
> Looking at the port select code, it just tries to create each symlink in
> turn. There isn't any special error handling code to deal with the case that
> a symlink can't be created; if that happens, an error will occur and MacPorts
> will exit. Any symlinks that were already successfully created will remain on
> disk. This would leave you with an incomplete or possibly even inconsistent
> set of symlinks.
>
> Somebody should fix the bug in the mysql57 port. If you'd like to do so, you
> can submit a pull request in macports-ports.
Until it's fixed, this bash script ought to fix this issue :
#!/bin/bash
# this goes through alle the installed mysql versions
# and removes all links
while read -u 9 portName isActive
do
while read -u 8 fileName
do
link=$( echo "${fileName}" \
| sed -E -e 's/lib\///' -e "s/${portName}\///" )
[[ -L "${link}" ]] && rm "${link}"
done 8< <( port contents ${portName} )
done 9< \
<(port -q select --list mysql \
| grep -v -F 'none' )
# this creates the links for a mysql version given in ${1}
while read -u 8 fileName
do
link=$( echo "${fileName}" \
| sed -E -e 's/lib\///' -e "s/${portName}\///" )
ln -s "${fileName}" "${link}"
done 8< <( port contents ${1} )
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [mysql57 & mysql8] build error on 10.6 Snow Leopard i386
I've now tried theese in order & Im still getting build errors possible solutions tried 1) rename /usr/bin/libtool 2) symlink /usr/bin/libtool -> /macports/bin/libtool 3) enable macports trace mode see : https://macports.mathiesen.info/10.6-i386/mysql57-main.log see : https://macports.mathiesen.info/10.6-i386/mysql8-main.log I don't know enough about the complie process to be able to analyze theese logs trace mode apparently didn't work, as /usr/bin/libtool is still called; but that should't be an issue any longer due t0 (2) => port clean --work mysql57 mysql8 ---> Cleaning mysql57 ---> Cleaning mysql8 => port -upN install mysql57-server mysql8-server Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option ---> Computing dependencies for mysql57-server ---> Dependencies to be installed: mysql57 ---> Fetching distfiles for mysql57 ---> Attempting to fetch mysql-5.7.27.tar.gz from http://artfiles.org/mysql/Downloads/MySQL-5.7 ---> Attempting to fetch boost_1_59_0.tar.gz from https://distfiles.macports.org/mysql57 ---> Verifying checksums for mysql57 ---> Extracting mysql57 ---> Applying patches to mysql57 ---> Configuring mysql57 ---> Building mysql57 Error: Failed to build mysql57: command execution failed Error: See /macports/var/macports/logs/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql57/mysql57/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port mysql57-server failed Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option ---> Computing dependencies for mysql8-server ---> Dependencies to be installed: mysql8 ---> Fetching distfiles for mysql8 ---> Verifying checksums for mysql8 ---> Extracting mysql8 ---> Applying patches to mysql8 ---> Configuring mysql8 ---> Building mysql8 Error: Failed to build mysql8: command execution failed Error: See /macports/var/macports/logs/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port mysql8-server failed -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
[mariadb-10.1] missing file in installation
I've just installed mariadb-10.1-server It fails on starting the server with : => cd '/macports' ; /macports/lib/mariadb-10.1/bin/mysqld_safe --datadir='/Volumes/BrugerData/MaraiDB/' #=> tail /Volumes/BrugerData/MaraiDB//0125000629.4.fullrate.ninja.err 190818 08:13:50 mysqld_safe Starting mysqld daemon with databases from /Volumes/BrugerData/MaraiDB/ 2019-08-18 8:13:50 2697692480 [Note] /macports/lib/mariadb-10.1/bin/mysqld (mysqld 10.1.41-MariaDB) starting as process 101 ... 2019-08-18 8:13:50 2697692480 [ERROR] Can't find messagefile '/macports/lib/mariadb-10.1/share/mariadb-10.1/errmsg.sys' 2019-08-18 8:13:50 2697692480 [ERROR] Aborting 190818 08:13:50 mysqld_safe mysqld from pid file /Volumes/BrugerData/MaraiDB//0125000629.4.fullrate.ninja.pid ended => ls -l /macports/lib/mariadb-10.1/share/mariadb-10.1/errmsg.sys ls: /macports/lib/mariadb-10.1/share/mariadb-10.1/errmsg.sys: No such file or directory This file is missing in the installation on three different computers. It's also not present in mariadb-10.0 How do I fix this ? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
[libgcc8] compile failure on i386 on 10.6 Snow
Any pointers as to what I can do to fix this ? :-) see : https://macports.mathiesen.info/logs/libgcc8_main.log the failure seems to be this : /macports/bin/clang++-mp-8.0 -arch i386 -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -L/macports/lib -Wl,-headerpad_max_install_names -no-pie -o build/gengenrtl \ build/gengenrtl.o build/errors.o ../build-i386-apple-darwin10/libiberty/libiberty.a clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] ld: illegal text-relocation to '___stdoutp' in /usr/lib/libSystem.dylib from '_main' in build/gengenrtl.o for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/gengenrtl] Error 1 I've got this in my macports.conf : (cf https://trac.macports.org/wiki/LibcxxOnOlderSystems ) cxx_stdlib libc++ buildfromsourcealways default_compilers macports-clang-8.0 macports-clang-7.0 macports-clang-3.9 macports-clang-3.7 gcc-4.2 apple-gcc-4.2 gcc-4.0 #=> port installed *gcc* clang* llvm* The following ports are currently installed: clang-3.7 @3.7.1_5+analyzer (active) clang-3.9 @3.9.1_9+analyzer+libstdcxx (active) clang-7.0 @7.0.1_1+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) clang-8.0 @8.0.0_0+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) clang_select @2_0 (active) gcc6 @6.1.0_0 (active) gcc_select @0.1_8 (active) libgcc @6.1.0_0 (active) llvm-3.5 @3.5.2_9 (active) llvm-3.7 @3.7.1_4 (active) llvm-3.9 @3.9.1_5 (active) llvm-7.0 @7.0.1_1+emulated_tls (active) llvm-8.0 @8.0.0_0+emulated_tls (active) llvm_select @2_0 (active) #=> port outdated *gcc* The following installed ports are outdated: gcc6 6.1.0_0 < 6.5.0_4 libgcc 6.1.0_0 < 2.0_2 (epoch 2 < 3) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
[cxx_stdlib] libc++ setting not respected
I've got this in macports.conf : cxx_stdlib libc++ buildfromsourcealways default_compilers macports-clang-8.0 macports-clang-7.0 macports-clang-3.9 macports-clang-3.7 gcc-4.2 apple-gcc-4.2 gcc-4.0 but gperf @3.1+universal ncurses @6.1+universal gettext @0.19.8.1+universal don't respect this and still uses libstdc++ which lead to them to always show up in "port rev-ugrade" trying to re-compile which is a PITA when compiling another port This is seen on 10.6 Snow on both i386 and x86_64 Any ideas on how to fix this ? :-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [libgcc8] compile failure on i386 on 10.6 Snow
Chris Jones wrote: > > > On 27/08/2019 1:31 pm, Ken Cunningham wrote: >> that is a 32 bit error that is usually suppressed by passing >> "-read_only_relocs suppress"' to the linker, IIRC. >> >> Why are you seeing it, though, I wonder? >> >> I don't think anyone has likely tried to build libgcc8 32bit on 10.6.8 >> with clang-8.0... > > My guess is the use of clang 8.0 is something new, and probably related > to the recent changes to support libc++ etc. in base 2.6.0... the libgcc 6.1.0_0 < 2.0_2 (epoch 2 < 3) has libgcc @2.0_2 (lang) Variants: universal Description: Provides the appropriate gcc runtime. Picks the version to use based on macOS version. Homepage: https://www.macports.org/ Build Dependencies: clang-8.0 Library Dependencies: libgcc8 on my i386 MacMini > >> Why don't you try it with clang-3.9 I've updated "default_compilers" whenever macports installed a new clang. > > Certainly interesting to know if that (still) works, but ultimately this > compiler will be removed (it already was, but temporarily put back > pending the new base release). So longer term the issues with the new > clang needs to be resolved. > > Chris > This is a very very old installation with all types of cruff ... Generally, I've just done, what macports has told me to do during it's lifetime ;-) Presently, I'm in the process of upgrading to x86_64 (I've got two of those old MacMini things - one with an i386 and one with an x86_64) so presently, I'm migrating the installation on i386 -> x86_64, but untill that's successfully done, I still do want my old i386 to stay as up-to-date as possible. Presently, I'm getting issues with ports that are x86_64 only so it's high time for me to take the jump ;-) :-D And I've got a replacement x86_64 CPU for the i386 MacMini so long term it's not an issue any longer for me [thumbs_up]. I'm administering them headless through ssh et al & Remote Desktop; and I find, that Exposé and Spaces are much nicer to work with in Remote Desktop under 10.6 than the later incarnation in 10.7 & 10.8 ;-) And 10.8 is the absolute max (through a hack) this old HardWare can handle ... but they are still going strong 2x[thumbs_up] -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [cxx_stdlib] libc++ setting not respected
Ken Cunningham wrote: > I have this exact setup and this is not happening to me, so it's fixable... > > are you running macports 2.5.4 ? yes > > If so. post a log ( clean them all, then sudo port -d rev-upgrade) and we'll > see what shakes out... > > Ken > It seems to have resolved itself through a "port -dN selfupdate" Somebody has made some changes to these port ... #=> port -v rev-upgrade ---> Scanning binaries for linking errors ---> Found 14 broken files, matching files to ports gperf is using libstdc++ (this installation is configured to use libc++) ncurses is using libstdc++ (this installation is configured to use libc++) gettext is using libstdc++ (this installation is configured to use libc++) ---> Found 4 broken ports, determining rebuild order You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: gperf @3.1+universal ncurses @6.1+universal gcc6 @6.1.0 gettext @0.19.8.1+universal Continue? [Y/n]: -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [libgcc8] compile failure on i386 on 10.6 Snow
Ken Cunningham wrote: >> On 27 Aug 2019, at 15:28, Ken Cunningham wrote: >> >> >/Luckily, we'll always have clang-3.7, / >> That seems like an oxymoron... >> >> Is there really no hope of ever getting away from needing such an old >> version? > > Practically, no, not on MacPorts for bootstrapping anyway. clang-3.4 > cannot build a working compiler newer than clang-3.7, so we need that > stepping stone. > > Our current pathway on 10.5 and 10.6 is this: > > clang-3.4 -> cctools and ld64 and libcxx and clang-3.7 -> clang-5.0 > +emulatedtls -> rebuild libcxx +emulatedtls I've taken a new look at https://trac.macports.org/wiki/LibcxxOnOlderSystems and I have some trouble understanding the current instructions Bootstrapping 3: (5) & (7) : the instructions state +llvm39 ; but shouldn't it be +llwm37 ?!? (10) : according to your procedure at described above, it shold be clang-5.0 instead of clang-3.9 ?!? somebody noted somewhere that clang-3.9 is drepreceated (11) : in lieu of (12) shouldn't clang-3.4 be removed here ?!? and how about clang-3.7 and the others if clang-(3.9|5.0) has been installed ?!? And Bill Cole seems to have clang-8.0 running and no clang-3.(7|9) (Why does everything now want ncurses-bootstrap, which doesn't build???) And your note about re-building libcxx +emulatedtls isn't mentioned ! And should the instructions reflect the variants Bill Cole has ?!? Now, I know that 10.6 - 10.8 is only relevant on _!very!_ old HardWare, so : how many of us do actually have such old HW ;-) ??? > > > Now -- if you want to get funky about it, gcc5+ can build > llvm/libcxx/clang just fine. I use that approach on 10.5 PPC. > > But you'll never sell that to MacPorts, nor should you, as the one I > outlined is a well trodden path. > > Ken Presently, I've ripped the whole toolchain out and have started from scratch on my i386 MacMini in order to try to fix as many of my issues as possible. And I'm doing a totally clean install on a x86_64 10.6 MacMini, so I'm able to experiment a bit ;-) :-D -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [libgcc8] compile failure on i386 on 10.6 Snow
Further notes regarding LibcxxOnOlderSystems : (12) : mentions ripping clang-3.4 out ; but isn't it enough to remove it from default_compilers ?!? so that one still has it in case of an emergency ?!? alternatively, can one use eg "port (pkg|dmg) (clang|llvm)-x.y" to store the versions of (clang|llvm) one doesn't use presently ?!? Bill Cole mentions doing a "port upgrade --force clang-8.0" Is it a good idea to do this after having installed a new version of clang ?!? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [libgcc8] compile failure on i386 on 10.6 Snow
OK ! There have been some major changes in a lot of PortFile recently ! Ive just had to do this : #=> port -vN install libcxx ---> Computing dependencies for libcxx ---> Dependencies to be installed: clang-3.4 cctools libunwind-headers xz-bootstrap gettext-bootstrap libiconv-bootstrap gperf-bootstrap ncurses-bootstrap llvm-3.7 libcxx libedit libffi llvm_select zlib clang_select ld64 ld64-latest clang-5.0 clang-3.7 libxml2 icu pkgconfig xz perl5 perl5.28 db48 gdbm readline python27 bzip2 expat openssl python2_select python_select sqlite3 cmake curl curl-ca-bundle libidn2 autoconf automake libtool libunistring texinfo help2man p5.28-locale-gettext libpsl glib2 pcre python37 python3_select legacy-support libarchive lz4 lzo2 zstd libuv libomp llvm-5.0 xar libmacho-headers libxml2-bootstrap icu-bootstrap pkgconfig-bootstrap llvm-3.4 python27-bootstrap So, what we have discussed in this thread & what's described on the LibcxxOnOlderSystems wiki has now been automated ! :-) :-D As I always say : If you have to do the same thing more than twice, you have the basis for a program ;) :-D I'll let you know how it turns out when all of this has finished installing i a day or two :-D ;-) :-D -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: [libgcc8] compile failure on i386 on 10.6 Snow
Ken Cunningham wrote: >> Bootstrapping 3: >> (5) & (7) : >> the instructions state +llvm39 ; >> but shouldn't it be +llwm37 ?!? > > The instructions state +llvm50 (I changed them from llvm39 about a week ago, > in anticipation of llvm-3.9 being retired) > My bad ;-) I've just had the page open in a tab for the last week or so while I played around, so I hadn't seen your recent changes ;-) :-P -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Ken Cunningham wrote: >> I'll let you know how it turns out when all of this has finished >> installing i a day or two :-D ;-) :-D >> >> -- > Please do. I'm very glad you have taken the interest and time to try it out > -- that is exactly why we have spent so much time trying to fix it for people > like you. > > But if something breaks, don't be frustrated. This process is literally one > week old, and I don't know if anyone ever tried it on MacPorts 2.5.4, so you > are an intrepid explorer in an uncharted wilderness right now... > > Best, > Ken Presently, it fails at this point : x ./macports/libexec/libcxx-bootstrap/Applications/Python 2.7/IDLE.app/Contents/Resources/idlemain.py x ./macports/libexec/libcxx-bootstrap/Applications/Python 2.7/IDLE.app/Contents/MacOS/IDLE x ./macports/libexec/libcxx-bootstrap/Applications/Python 2.7/IDLE.app/Contents/MacOS/Python ---> Cleaning python27-bootstrap ---> Removing work directory for python27-bootstrap Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port libcxx failed ---> Some of the ports you installed have notes: after having installed these ports : #=> port installed The following ports are currently installed: autoconf @2.69_5 (active) automake @1.16.1_1 (active) bzip2 @1.0.8_0 (active) clang_select @2_0 (active) curl @7.65.3_0+ssl (active) curl-ca-bundle @7.65.3_0 (active) db48 @4.8.30_4+java (active) expat @2.2.7_0 (active) gdbm @1.18.1_1 (active) gettext @0.19.8.1_2 (active) gettext-bootstrap @0.19.8.1_2 (active) glib2 @2.58.3_0+x11 (active) gperf @3.1_0 (active) gperf-bootstrap @3.1_0 (active) help2man @1.47.11_0 (active) icu @58.2_2 (active) icu-bootstrap @58.2_0 (active) legacy-support @0.11.1_0 (active) libarchive @3.3.3_1 (active) libedit @20190324-3.1_0 (active) libffi @3.2.1_0 (active) libiconv @1.16_0 (active) libiconv-bootstrap @1.16_0 (active) libidn2 @2.2.0_0 (active) libmacho-headers @921_0 (active) libpsl @0.21.0-20190419_0 (active) libtool @2.4.6_6 (active) libunistring @0.9.10_0 (active) libunwind-headers @5.0.1_0 (active) libuv @1.30.0_0 (active) libxml2 @2.9.9_2 (active) libxml2-bootstrap @2.9.9_2 (active) llvm-3.4 @3.4.2_12 (active) llvm_select @2_0 (active) lz4 @1.9.1_0 (active) lzo2 @2.10_0 (active) ncurses @6.1_0 (active) ncurses-bootstrap @6.1_0 (active) openssl @1.0.2s_0 (active) p5.28-locale-gettext @1.70.0_0 (active) pcre @8.43_0 (active) perl5 @5.26.1_0+perl5_28 (active) perl5.28 @5.28.2_0 (active) pkgconfig @0.29.2_0 (active) pkgconfig-bootstrap @0.29.2_0 (active) python2_select @0.0_3 (active) python3_select @0.0_1 (active) python27 @2.7.16_1 (active) python27-bootstrap @2.7.16_1 (active) python37 @3.7.4_0 (active) python_select @0.3_8 (active) readline @8.0.000_0 (active) sqlite3 @3.29.0_0 (active) texinfo @6.6_0 (active) xar @1.6.1_0 (active) xz @5.2.4_0 (active) xz-bootstrap @5.2.4_0 (active) zlib @1.2.11_0 (active) zstd @1.4.3_0 (active) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
And : #=> port clean --work libcxx ---> Cleaning libcxx root@0125000629 22:41:36 /macports/etc/macports #=> port -vN install libcxx ---> Computing dependencies for libcxx... ---> Dependencies to be installed: clang-3.4 cctools llvm-3.7 libcxx ld64 ld64-latest clang-5.0 clang-3.7 cmake libomp llvm-5.0 Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port libcxx failed --- Now, how do I switch this automatic process off ? I really need to get my system into a working condition ;-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Ken Cunningham wrote: >> --- >> Now, how do I switch this automatic process off ? >> I really need to get my system into a working condition ;-) >> > I think if you start over, uninstall all ports, and then set your > macports.conf back to the way it was at birth (comment out all your > additions, so it's pristine, or use the default one and copy it over as > yours) you should be OK. > > I suspect your troubles are coming from the changed libc++ setting and the > default_compilers setting you added. I only had the libc++ setting when I started. > > For bootstrapping LibcxxOnOlderSystems, you can't have those in macports.conf > until the proper stage of bootstrapping, as per the instructions when it says > to add the changes to macports.conf step by step along the way. I went back to a pristine macports.conf > > You can why Josh has been working so nicely to automate it. He'll get it -- > always does. But there may be differences between 2.6 and 2.5.4 that mean > it'll only work on macports 2.6 Not sure about that yet. > > Ken > Now, at present i get : macOS 10.6.8 10K549 Xcode 3.2.6 DevToolsSupport-1806.0 10M2518 #=> system_profiler -detailLevel mini SPHardwareDataType Hardware: Hardware Overview: Model Name: Mac mini Model Identifier: Macmini2,1 Processor Name: Intel Core 2 Duo Processor Speed: 2 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 4 MB Memory: 4 GB Bus Speed: 667 MHz Boot ROM Version: MM21.009A.B00 SMC Version (system): 1.19f2 x ./macports/bin/llvm-tblgen-mp-3.4 x ./macports/bin/macho-dump-mp-3.4 x ./macports/bin/opt-mp-3.4 ---> Cleaning llvm-3.4 ---> Removing work directory for llvm-3.4 Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port libcxx failed ---> Some of the ports you installed have notes: So it get's a bit further now It has removed the work directory for llvm-3.4 : root@0125000629 00:48:37 /macports/var/macports/build #=> ls -l total 0 drwxr-xr-x 3 root admin 102 29 Aug 00:53 _macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libcxx According to my i386 installation : #=> port installed name:cxx The following ports are currently installed: libcxx @5.0.1_4+universal (active) #=> port contents libcxx Port libcxx contains: /macports/var/system_roots/libcxx-5.0.1-4.tgz But this isn't present yet on the x86_64 : #=> ls -l total 0 drwxr-xr-x 3 root admin 102 29 Aug 00:53 _macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libcxx root@0125000629 11:52:30 /macports/var/macports/build #=> find . -name 'libcxx-5.0.1-4.tgz' root@0125000629 11:52:42 /macports/var/macports/build #=> ls -l /macports/var/ total 0 drwxr-xr-x 3 root admin 102 2 Okt 2011 cache drwxr-xr-x 11 root admin 374 20 Aug 00:21 db drwxr-xr-x 4 root admin 136 15 Aug 12:35 lib drwxr-xr-x 6 root admin 204 23 Aug 23:36 log drwxr-xr-x@ 11 root admin 510 14 Aug 13:59 macports drwxr-xr-x 3 root admin 102 15 Aug 12:45 net-snmp drwxr-xr-x 7 root admin 272 27 Aug 14:06 run drwxr-xr-x 3 root admin 102 4 Jan 2012 spool drwxr-xr-x 2 root admin 68 23 Aug 2016 tmp It's impossible to install the remaining ports one-by-one as they all depend on each other : #=> port install cctools ---> Computing dependencies for cctools The following dependencies will be installed: cctools clang-3.4 clang-3.7 clang-5.0 cmake ld64 ld64-latest libcxx libomp llvm-3.7 llvm-5.0 Continue? [Y/n]: n ---> Scanning binaries for linking errors ---> No broken files found. ---> No broken ports found. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Joshua Root wrote: > On 2019-8-29 20:04 , Bjarne D Mathiesen wrote: >> It's impossible to install the remaining ports one-by-one as they all >> depend on each other : >> >> #=> port install cctools >> ---> Computing dependencies for cctools >> The following dependencies will be installed: >> cctools >> clang-3.4 >> clang-3.7 >> clang-5.0 >> cmake >> ld64 >> ld64-latest >> libcxx >> libomp >> llvm-3.7 >> llvm-5.0 >> Continue? [Y/n]: n >> ---> Scanning binaries for linking errors >> ---> No broken files found. >> ---> No broken ports found. > > What does 'port deps' say for clang-3.4, ld64 and cctools? Those > shouldn't have any dependencies in that set. Also curious why ld64 isn't > using ld64-127 for you. > > - Josh > #=> port deps clang-3.4 Full Name: clang-3.4 @3.4.2_12+analyzer Build Dependencies: cctools Library Dependencies: libxml2, llvm-3.4, python27, libffi, ncurses, zlib Runtime Dependencies: clang_select, ld64, perl5 root@0125000629 13:14:32 /macports/etc/macports #=> port deps ld64 Full Name: ld64 @3_1 Runtime Dependencies: ld64-latest root@0125000629 13:15:24 /macports/etc/macports #=> port deps cctools Full Name: cctools @921_3+llvm37 Build Dependencies: libunwind-headers Library Dependencies: llvm-3.7 root@0125000629 13:15:56 /macports/etc/macports #=> port install ld64 ---> Computing dependencies for ld64 The following dependencies will be installed: cctools clang-3.4 clang-3.7 clang-5.0 cmake ld64 ld64-latest libcxx libomp llvm-3.7 llvm-5.0 Continue? [Y/n]: n -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Joshua Root wrote: > On 2019-8-29 21:21 , Bjarne D Mathiesen wrote: >> >> #=> port deps clang-3.4 >> Full Name: clang-3.4 @3.4.2_12+analyzer >> Build Dependencies: cctools >> Library Dependencies: libxml2, llvm-3.4, python27, libffi, ncurses, zlib >> Runtime Dependencies: clang_select, ld64, perl5 > > I guess you don't have cxx_stdlib set to libc++ then? > >> root@0125000629 13:14:32 /macports/etc/macports >> #=> port deps ld64 >> Full Name: ld64 @3_1 >> Runtime Dependencies: ld64-latest >> root@0125000629 13:15:24 /macports/etc/macports >> #=> port deps cctools >> Full Name: cctools @921_3+llvm37 >> Build Dependencies: libunwind-headers >> Library Dependencies: llvm-3.7 >> root@0125000629 13:15:56 /macports/etc/macports > > I would expect ld64 to be defaulting to +ld64_127 and cctools to be > defaulting to +llvm34. > > - Josh > with : buildfromsourcealways cxx_stdlib libc++ default_compilers macports-clang-5.0 macports-clang-3.7 gcc-4.2 apple-gcc-4.2 macports-clang-3.4 #=> port deps cctools Full Name: cctools @921_3+llvm37 Build Dependencies: libunwind-headers, clang-5.0 Library Dependencies: llvm-3.7 #=> port deps ld64 Full Name: ld64 @3_1 Build Dependencies: clang-5.0 Runtime Dependencies: ld64-latest #=> port deps llvm-3.7 Full Name: llvm-3.7 @3.7.1_4 Extract Dependencies: xz Build Dependencies: cctools, clang-3.4 Library Dependencies: libedit, libffi, ncurses, zlib, libcxx Runtime Dependencies: perl5, llvm_select #=> port install ld64 ---> Computing dependencies for ld64 The following dependencies will be installed: cctools clang-3.4 clang-3.7 clang-5.0 cmake ld64 ld64-latest libcxx libomp llvm-3.7 llvm-5.0 Continue? [Y/n]: n ---> Scanning binaries for linking errors ---> No broken files found. ---> Found 7 broken ports, determining rebuild order You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: gperf @3.1 icu @58.2 db48 @4.8.30+java ncurses @6.1 gettext @0.19.8.1 llvm-3.4 @3.4.2 pcre @8.43 Continue? [Y/n]: Y so ... I've set it to do this ... this will take some hours barring any errors ;-) :-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Bjarne D Mathiesen wrote: > ---> Scanning binaries for linking errors > ---> No broken files found. > ---> Found 7 broken ports, determining rebuild order > You can always run 'port rev-upgrade' again to fix errors. > The following ports will be rebuilt: > gperf @3.1 > icu @58.2 > db48 @4.8.30+java > ncurses @6.1 > gettext @0.19.8.1 > llvm-3.4 @3.4.2 > pcre @8.43 > Continue? [Y/n]: Y > > so ... I've set it to do this ... this will take some hours barring any > errors ;-) :-) > > Error: rev-upgrade failed: Error rebuilding gperf I think, I might have to rip everything out once more ;-) [nerd] ;-P -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
I 1) uninstalled all installed ports 2) manually cleared the build directory for cruft now, "port -vN install libcxx" with buildfromsourcealways cxx_stdlib libc++ default_compilers macports-clang-5.0 macports-clang-3.7 gcc-4.2 apple-gcc-4.2 macports-clang-3.4 #=> port -vN install libcxx ---> Computing dependencies for libcxx... ---> Dependencies to be installed: clang-3.4 cctools clang-5.0 clang-3.7 clang_select ld64 ld64-latest libcxx xz gettext libiconv gperf ncurses libmacho-headers llvm-3.7 libedit libffi llvm_select zlib libxml2 icu pkgconfig perl5 perl5.28 db48 gdbm readline python27 bzip2 expat openssl python2_select python_select sqlite3 cmake curl curl-ca-bundle libidn2 autoconf automake libtool libunistring texinfo help2man p5.28-locale-gettext libpsl glib2 pcre python37 python3_select legacy-support libarchive lz4 lzo2 zstd libuv libomp llvm-5.0 xar libunwind-headers llvm-3.4 ---> Fetching distfiles for libffi ---> Verifying checksums for libffi ---> Checksumming libffi-3.2.1.tar.gz ... x ./macports/lib/pkgconfig/ x ./macports/lib/pkgconfig/libffi.pc x ./macports/lib/libffi-3.2.1/include/ x ./macports/lib/libffi-3.2.1/include/ffi.h x ./macports/lib/libffi-3.2.1/include/ffitarget.h ---> Cleaning libffi ---> Removing work directory for libffi Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port libcxx failed So ... 👎🏻 it fails already after the first port has been installed 👎🏻 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
Re: LibcxxOnOlderSystems
Bjarne D Mathiesen wrote: >> --- >> Now, how do I switch this automatic process off ? >> I really need to get my system into a working condition ;-) >> I suppose I could "git clone macports-ports" and go back in time untill I get to a point, where the LibcxxOnOlderSystems instructions for doing this stuff manually works ;-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [libgcc8] compile failure on i386 on 10.6 Snow
OK - I've re-installed the toolchain so presently I've got : #=> port installed name:^clang name:^llvm name:*gcc* The following ports are currently installed: clang-3.4 @3.4.2_12 clang-3.7 @3.7.1_5+analyzer (active) clang-5.0 @5.0.2_3+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) clang-8.0 @8.0.0_0+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) clang_select @2_0 (active) llvm-3.4 @3.4.2_12 llvm-3.7 @3.7.1_4 (active) llvm-5.0 @5.0.2_0 (active) llvm-8.0 @8.0.0_0+emulated_tls (active) llvm_select @2_0 (active) buildfromsourcealways cxx_stdlib libc++ default_compilers macports-clang-5.0 macports-clang-3.7 gcc-4.2 apple-gcc-4.2 macports-clang-3.4 And I'm getting : /macports/bin/clang++-mp-5.0 -arch i386 -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -L/macports/lib -Wl,-headerpad_max_install_names -no-pie -o build/gengenrtl \ build/gengenrtl.o build/errors.o ../build-i386-apple-darwin10/libiberty/libiberty.a clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] ld: illegal text-relocation to '___stdoutp' in /usr/lib/libSystem.dylib from '_main' in build/gengenrtl.o for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/gengenrtl] Error 1 Now, Ken Cunningham wrote : that is a 32 bit error that is usually suppressed by passing "-read_only_relocs suppress"' to the linker, IIRC. Is there a way in which I can apply that setting ?!? Should I file a bug for this issue ??? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: LibcxxOnOlderSystems
Bill Cole wrote: > > I successfully re-ran the LibcxxOnOlderSystems procedure last weekend > and have what seems to be a working setup on an original Intel Core Duo > iMac running 10.6.8. I've also just done that on mine during the last two days. !!!EXECPT!!! that I didn't re-install libcxx ! port -f uninstall ld64* clang* llvm* *gcc* port -f uninstall cctools port -vN install clang-3.4 ld64 cctools libcxx port -vN install clang-3.7 port -v -n upgrade --force --enforce-variants cctools -llvm34 +llvm37 port -v -n upgrade --force --enforce-variants ld64 -llvm34 +llvm37 port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_236 port deactivate ld64 @3_1 port deactivate ld64-127 @127.2_14+llvm34 port -vN install clang-5.0 port -v -n upgrade --force --enforce-variants cctools -llvm37 +llvm50 port uninstall ld64 @3_1+ld64_127 ld64-127 @127.2_14+llvm34 port -v -n upgrade --force --enforce-variants \ ld64-latest -llvm37 +llvm50 #=> port -v installed name:^clang name:^llvm name:*gcc* name:libcxx The following ports are currently installed: clang-3.4 @3.4.2_12 platform='darwin 10' archs='i386' date='2019-08-29T02:10:33+0200' clang-3.7 @3.7.1_5+analyzer (active) platform='darwin 10' archs='i386' date='2019-08-28T13:31:20+0200' clang-5.0 @5.0.2_3+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) platform='darwin 10' archs='i386' date='2019-08-28T20:04:16+0200' clang-8.0 @8.0.0_0+analyzer+defaultlibcxx+emulated_tls+libstdcxx (active) platform='darwin 10' archs='i386' date='2019-08-29T18:36:30+0200' clang_select @2_0 (active) platform='darwin 10' archs='noarch' date='2019-08-28T05:45:06+0200' libcxx <-- @5.0.1_4+universal (active) <-- platform='darwin 10' archs='i386 x86_64'<-- date='2019-08-08T15:35:51+0200' <-- llvm-3.4 @3.4.2_12 platform='darwin 10' archs='i386' date='2019-08-29T00:15:35+0200' llvm-3.7 @3.7.1_4 (active) platform='darwin 10' archs='i386' date='2019-08-28T10:32:52+0200' llvm-5.0 @5.0.2_0 (active) platform='darwin 10' archs='i386' date='2019-08-28T16:11:21+0200' llvm-8.0 @8.0.0_0+emulated_tls (active) platform='darwin 10' archs='i386' date='2019-08-29T12:12:41+0200' llvm_select @2_0 (active) platform='darwin 10' archs='noarch' date='2019-08-27T20:19:37+0200' To me, it looks as if you have installed (at least) libcxx, you can start over again with the rest of the toolchain. But a completely fresh install messes up. Another thing I could do was re-compile the toolchain as universal on the i386 and then just copy it over to the x86_64 system. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [libgcc8] compile failure on i386 on 10.6 Snow
I tried editing the libgcc8 Portfile "configure.cxxflags-append -Wl,-read_only_relocs,suppress" has no influence and just gives the original error. "configure.ldflags-append -read_only_relocs suppress" gives : #=> port -v install libgcc ---> Computing dependencies for libgcc.. The following dependencies will be installed: libgcc8 Continue? [Y/n]: ---> Fetching distfiles for libgcc8 ---> Verifying checksums for libgcc8 ---> Checksumming gcc-8.3.0.tar.xz ---> Extracting libgcc8 ---> Extracting gcc-8.3.0.tar.xz Executing: cd "/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc8/work" && /macports/bin/xz -dc '/macports/var/macports/distfiles/gcc8/gcc-8.3.0.tar.xz' | /usr/bin/gnutar --no-same-owner -xf - ---> Configuring libgcc8 Executing: cd "/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc8/work/build" && /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.3.0/configure --prefix=/macports --build=i386-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/macports/lib/libgcc --includedir=/macports/include/gcc --infodir=/macports/share/info --mandir=/macports/share/man --datarootdir=/macports/share/gcc-8 --with-local-prefix=/macports --with-system-zlib --disable-nls --program-suffix=-mp-8 --with-gxx-include-dir=/macports/include/gcc/c++/ --with-gmp=/macports --with-mpfr=/macports --with-mpc=/macports --with-isl=/macports --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/macports/bin/as --with-ld=/macports/bin/ld --with-ar=/macports/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls -read_only_relocs suppress --with-pkgversion="MacPorts gcc8 8.3.0_5" configure: error: unrecognized option: `-read_only_relocs' -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
corrupt PortIndex file
Whenever I do something like this #=> port installed name:^clang name:^llvm name:*gcc* name:libcxx I get this : Warning: It looks like your PortIndex file for rsync://rsync.macports.org/release/tarballs/ports.tar may be corrupt. Warning: Can't open index file for source: rsync://rsync.macports.org/release/tarballs/ports.tar I do have some somewhat crazy user:group settings on root@0125000629 01:34:31 /macports/var/macports/sources/rsync.macports.org/release/tarballs #=> ls -l total 327904 -rw-r--r-- 1 root admin 12762967 29 Aug 20:30 PortIndex -rw-r--r-- 1 root admin 512 29 Aug 20:44 PortIndex.rmd160 drwxr-xr-x 10 root postgres 1156 5 Mar 2017 base -rw-r--r-- 1 root admin 85764608 26 Feb 2017 base.tar -rw-r--r-- 1 root admin 512 26 Feb 2017 base.tar.rmd160 drwxr-xr-x 53 ldap postgres 2108 30 Aug 01:38 ports -rw-r--r-- 1 root admin 69342720 29 Aug 23:36 ports.tar -rw-r--r-- 1 root admin 512 29 Aug 23:36 ports.tar.rmd160 Any pointers as to how I can fix this issue ?!? :-) :-D -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [libgcc8] compile failure on i386 on 10.6 Snow
Ken Cunningham wrote:
> FOR NOW:
>
> libgcc8 does build just fine on 10.6.8 32 bit using apple’s /usr/bin/gcc-4.2,
> however, so I suggest you just use that. Because you now have settings in
> your default compilers that will change what MacPorts would have set up by
> itself in the past, you now have to force it to use the old gcc-4.2 compiler
> it was using all these past many years:
>
> sudo port -v install libgcc8 configure.compiler=gcc-4.2
I'll try that :-)
Presently, I've set the poor i386 MacMini on a major task :
rebuilding the whole toolchain +universal :
while read -u 9 macport
do
portinfo=( $( port -q installed ${macport} ) )
port -cuN -n upgrade --enforce-variants \
${portinfo[0]} ${portinfo[1]}+universal
done 9< <( port -q rdeps clang-8.0 | sort )
so I can rsync it over to my x86_64 MacMini
>
> should get it done for you. I hope!
>
> gcc8/libgcc8 already clears the value for configure.cxx_stdlib, so you should
> not see any stdlib conflicts.
>
> Best, Ken
>
:-) :-) :-)
!!! Thank you for your help !!!
:-) :-) :-)
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: LibcxxOnOlderSystems
Joshua Root wrote: > On 2019-8-30 00:53 , Bjarne D Mathiesen wrote: >> I >> 1) uninstalled all installed ports >> 2) manually cleared the build directory for cruft > > What about variants.conf? Makes no difference 👎🏻 > >> So ... 👎🏻 it fails already after the first port has been installed 👎🏻 > > Yeah, there's no getting around the fact that +llvm37 isn't going to > work for bootstrapping cctools, because it requires clang-3.4 which > requires cctools. You could script it instead of having things depend on each other recursively ... I could take a look at doing than in bash if you are interested ?!? My recent excursion into re-installing the toolchain on my i386 has more-or-less given me 90 % of what needs to be done ;-) :-D > > - Josh > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Virtual Machines & Binary Compatibilty
Q : Will this scenario work ?!? If i create a VM of 10.6.8 in VirtualBox on my 2012 MacPro w/ Xeon CPUs, can I then rsync my macports installation to a Core 2 Duo based Mac Mini without any problems ?!? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: Virtual Machines & Binary Compatibilty
Richard L. Hamilton wrote: > I don't know how it is now, but macOS/OS X clients on VirtualBox used to be a > real pain to set up, starting with an ancient version of OS X and then > updating to the desired level, with fingers crossed. Parallels (yearly > subscription fee) is much better, but I know it does enforce the Server > requirement (see next paragraph). I've done a clean install from scratch of 10.13.x in VirtualBox. The only limitation is, that you'll have to hard-code the screen-size. It's also possible to port this to a WinTel 10 machine. The reason I'm interested in using a VM for 10.3.6 is, that I'm currently making my toolchain universal on a 32 bit Core Duo in order to be able to rsync this to my 64 bit Core 2 Duo because LibcxxOnOlderSystems currently is sevely broken ... and it's taking 🤬ages🤬. Also, the MacPro has 12 CPU cores / 24 threads, and it's blisteringly fast when compiling clang & llvm et al. Alternatively, I could use my Core i7 MacBook Pro if that's a better choice CPU vise ?!? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: Virtual Machines & Binary Compatibilty
Richard L. Hamilton wrote: > Curious what you mean by "hard-code the screen size" for macOS/OSX on > VirtualBox (not looking for Hackintosh, would be running on a macOS Mojave or > later host). Here are the links I collected when I VMed 10.13 https://tobiwashere.de/2017/10/virtualbox-how-to-create-a-macos-high-sierra-vm-to-run-on-a-mac-host-system/ https://www.howtogeek.com/289594/how-to-install-macos-sierra-in-virtualbox-on-windows-10/ You can do the CPU stuff on a Mac before transferring to WinTel https://forums.virtualbox.org/viewtopic.php?f=8&t=85084#p404335 https://www.dedoimedo.com/computers/virtualbox-network-sharing.html https://saintlad.com/install-macos-sierra-in-virtualbox-on-windows-10/ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[?bug?] PortGroup python 1.0
I've got this : file:///Volumes/Bjarne/WebServer/MacPorts/newPorts rsync://rsync.macports.org/release/tarballs/ports.tar [default] in my sources.conf Now, if I put my py-acme Portfile https://macports.mathiesen.info/portfiles/python/py-acme/Portfile into my own port tree, I get this : #=> port -d sync [standard stuff]... Failed to parse file python/py-acme/Portfile: can't read "python.version": no such variable Total number of ports parsed: 1 Ports successfully parsed: 0 Ports failed: 1 Up-to-date ports skipped: 17 +++ I've "rsync -a" the '_resources' directory into my ports tree. I have to explicitly set "python.version 37" in the Portfile in order for macports to accept it. Am I doing something wrong here ?!? The original macports portfile doesn't explicitly set this value. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [?bug?] PortGroup python 1.0
Christopher Jones wrote:
> Hi,
>
> Your port file is incorrectly set up. Compare to the original
>
> https://github.com/macports/macports-ports/blob/master/python/py-acme/Portfile
>
> you are missing the subport bits. This part is not optional, its part of
> how the python PG works. ${python.version} is only defined within each
> subport the PG sets up.
Adding
if {${name} ne ${subport}} {
...
}
fixed it 👍🏻😃
>
> Chris
>
🤓👍🏻 thanks 👍🏻🤓
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [?bug?] PortGroup python 1.0
Christopher Jones wrote: > > b.t.w. its also far from obvious (to me at least) why you have altered > the port file in the way you have ? Whats you aim here… ? It's because pypi i broken for 0.37.2 Also, to bring it in line with the newest version of certbot see the threads "[certbot] failure to download distfiles" "[certbot] port upgrade fails" & https://github.com/Schamschula/macports/commit/2c9091b91e0980aeeb8f88faa00f118726bdc593#diff-86385aebec34f64191005da068e6ce83 > > Chris > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re:[sources.conf] new macports default URL
Ryan Schmidt wrote: > > On Sep 2, 2019, at 15:10, Bjarne D Mathiesen wrote: > >> I've got this : >> >> file:///Volumes/Bjarne/WebServer/MacPorts/newPorts >> rsync://rsync.macports.org/release/tarballs/ports.tar [default] >> >> in my sources.conf > > Please change the rsync line to: > > rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default] > > The old URL without the "macports" top-level directory is deprecated and > will be removed in the future. Done ! :-) Thanks :-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [certbot,py-acme] Converting port to subport
Marius Schamschula wrote: > Hi all, > > I’m trying to fold py-acme, certbot-apache and certbot-nginx into the > certbot Portfile. This will simplify maintenance as they always get > updated together, and share the same source tarball. If I understands things correctly, then py-acme is a general package, that others might also use in their project Thus, it should be kept as a separate module In eg dovecot2 & dovecot2-sieve, there're notes about keeping these synced, so you might do something similar. If you do fold it into certbot, you'll have to make sure, it is *always* selected, and *can't* be de-selected. certbot-apache , certbot-nginx are plugins to certbot, thus it makes sense to have these as subports, as it doesn't make sense to have these without cerbot > > Bjarne Mathiesen has created several additional subports which will also > be available with the next release. Thanks for the credit :-) <3 > > After adding these sub-ports to the certbot Portfile, disabling the old > certbot-apache and certbot-nginx, and running portindex I get an error > that the Portfile for certbot-apache cannot be found. port is still > looking for the old Portfile in my local tree. > > Yet the old Portfile exists in macports-ports, but is also ignored. I don't get that kind of problems with all the plugins folded into certbot $=> port info certbot certbot @0.38.0_1 (security) Sub-ports: certbot-apache, certbot-nginx, ... Variants: python27, (+)python37, universal Description: An ACME Let's Encrypt client that can obtain certs and extensibly update server configurations. Homepage: https://github.com/certbot/certbot Build Dependencies: ... $=> port info certbot-apache certbot-apache @0.38.0_1 (security) Variants: python27, (+)python37, universal Description: The Apache plugin currently supports modern OSes based on ... Homepage: https://github.com/certbot/certbot Build Dependencies: ... $=> port file certbot /Volumes/Bjarne/WebServer/MacPorts/newPorts/security/certbot/Portfile $=> port file certbot-apache /Volumes/Bjarne/WebServer/MacPorts/newPorts/security/certbot/Portfile bjarne@Pro17 09:41:07 ~/Sites/NewStuff/spfengine > > Do I need to use the obsolete portgroup? I do think you'll have to do this for the exiting certbot-apache , certbot-nginx but you might get away with setting an early expiration date ;-) > > This counterintuitive, as the subport has the same name as the port it > is replacing. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[port sync] syncing only one tree
I've got these in my sources.conf : file:///Volumes/Bjarne/WebServer/MacPorts/newPorts rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default] where the file:///... (of course) is my development/testing tree, which I have to sync very regularly. Now, is it somehow possible to only do the "port -d sync" on this tree ?!? There's no reason for me to also sync [default] each and every time. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: Mail server install questions
Bill Cole wrote: > The dovecot2 port does have less active maintenance than it should, but > the broader (predominantly Linux) community is huge, the official wiki > (https://wiki.dovecot.org) is reasonably complete and up-to-date, and > development is robustly led by a going commercial entity: Open-Xchange. > The port needs a maintainer, but the software is far from dead. see : https://github.com/macports/macports-ports/pull/5236 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[portgroups] Python
Which versions of Python do macports still officially support ?!? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Christopher Jones wrote: > > Depends what you are thinking of by ‘officially support’. > > We have ports for > > python26 @2.6.9_7 (lang) > python27 @2.7.16_2 (lang) > > python32 @3.2.6_8 (lang) > python33 @3.3.7_3 (lang) > python34 @3.4.10_2 (lang) > python35 @3.5.7_1 (lang) > python36 @3.6.9_1 (lang) > python37 @3.7.4_1 (lang) > > However, that does not mean each of the various ‘py’ ports support all of the > above.. I know that. I'm limiting myself to only bothering with python27 & python37 I could possibly without any problems just plug the rest in with a good chance of success; but one of the python program I've made as Portfile for says : 3.3 and above >> On 12 Sep 2019, at 9:09 pm, Bjarne D Mathiesen >> wrote: >> >> Which versions of Python do macports still officially support ?!? >> I've had a bit of discussion about supporting python27 in https://github.com/macports/macports-ports/pull/5256 and took at look at the python-1.0.tcl file Now, python-1.0.tcl - sets python27 as the default with IMHO is a bad idea as it's been on the death-bed for several years now; and is being EOLed in 2020 - there's still a lot of py24 & py25 cruft in there so I was thinking about 1 setting python37 as the default 2 removing all the py24 & py25 stuff Possibly, also EOL / obsolete python3[2-5] & python26 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Richard L. Hamilton wrote:
> One might wonder at the number of python version ports. I suspect a couple
> of things that I don't know without a lot of digging would provide some
> perspective:
> * the OS version of python on the earliest OS MacPorts supports, and on each
> subsequent OS version
I've got both py27 & py37 running on 10.6.8 {i386,x86_64} so the OS is
not a problem
> * the python versions specifically required by various other ports (not just
> x.y or later, and esp. not just 2.y or 3.y)
> and maybe
> * the degree of change policy for python minor versions (impacting not only
> the previous point, but and non-MacPorts software that might be dependent on
> a particular version)> (as the recent openssl switchover showed, some
> software has backwards
compatibility issues with what are supposedly minor version changes)
In my experience with python3 then if it works in python3x then it also
works in python3x++
The big transitions were
python25 -> python26
python31 -> python32
and python27 is fundamentally incompatible with python37; eg the support
for utf-8
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Richard L. Hamilton wrote:
> Depending on the results, with some effort, it might be possible to drop some
> of the intermediate versions. But only if a later suitable (for everything
> dependent on it) version is possible on every supported OS. And it would mean
> bumping portfiles, and rebuilding everything depending on dropped versions.
> It probably wouldn't be worth the bother, and given all the constraints,
> might only get rid of a few versions.
>
so we've got 2 issues here :
- which pythonXY the pyXY-{name} support
and whether theese can be brought up to python37
- whether any Portfile that demands a pythonXY that isn't python37
can be updated to depend on python37 instead
We'll need some statistict / overview on this matter.
I'll look into this.
It's also a question about keeping the macports infrastructure up-to-date.
I've eg somehow gotten libsvm installed, and it has :
Variants: [+]java, [+]python27, python34, [+]tools, universal
as well as being seriously out-of-date:
libsvm @3.20_2 -> Version 3.24, September 2019
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Bjarne D Mathiesen wrote:
> Richard L. Hamilton wrote:
>> Depending on the results, with some effort, it might be possible to drop
>> some of the intermediate versions. But only if a later suitable (for
>> everything dependent on it) version is possible on every supported OS. And
>> it would mean bumping portfiles, and rebuilding everything depending on
>> dropped versions. It probably wouldn't be worth the bother, and given all
>> the constraints, might only get rid of a few versions.
>>
>
> so we've got 2 issues here :
> - which pythonXY the pyXY-{name} support
> and whether theese can be brought up to python37
> - whether any Portfile that demands a pythonXY that isn't python37
> can be updated to depend on python37 instead
>
> We'll need some statistict / overview on this matter.
> I'll look into this.
This ;-) nasty ;-) piece of bash scripting will give an oversigt of all
the pyXY-{name} ports and which versions of python they claim to support
I'll post a file on my website, when it has finished running :-)
--- begin bash script ---
declare -a pyVersions=( 26 27 32 33 34 35 36 37 )
pyPorts=( $( \
(
for V in ${pyVersions[@]}
do
port -q search --name py${V} | sed -E -e "s/${V}//"
done
) | sort -u ) )
maxLetters=$( \
for (( i=0 ; i<${#pyPorts[@]} ; i++ ))
do
echo ${#pyPorts[${i}]}
done | sort -u -n | tail -1 )
(( maxLetters+=5 ))
for pyPort in ${pyPorts[@]}
do
printf "%-${maxLetters}s" ${pyPort}
for V in ${pyVersions[@]}
do
isPort=$( port -q search ${pyPort/-/${V}-} )
if [[ -z "${isPort}" ]]
then
echo -n " "
else
echo -n "${V} "
fi
done
echo
done
--- end bash script ---
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
raf wrote: > > i hope python27 wont't go away. > > cheers, > raf https://pythonclock.org/ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
python26 @2.6.9_7 (lang) EOL python27 @2.7.16_2 (lang) EOL 2020-01-01 https://www.python.org/dev/peps/pep-0373/ python32 @3.2.6_8 (lang) EOL python33 @3.3.7_3 (lang) EOL 2017-09-19 python34 @3.4.10_2 (lang) EOL 2019-03-18 https://www.python.org/dev/peps/pep-0429/ python35 @3.5.7_1 (lang) CURRENT https://www.python.org/dev/peps/pep-0478/ python36 @3.6.9_1 (lang) CURRENT https://www.python.org/dev/peps/pep-0494/ python37 @3.7.4_1 (lang) CURRENT https://www.python.org/dev/peps/pep-0537/ python38 @3.8.0b4 (lang) FUTURE https://www.python.org/dev/peps/pep-0569/ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Mojca Miklavec wrote:
> On Fri, 13 Sep 2019 at 03:51, Bjarne D Mathiesen wrote:
>>
>> Richard L. Hamilton wrote:
>>> Depending on the results, with some effort, it might be possible to drop
>>> some of the intermediate versions. But only if a later suitable (for
>>> everything dependent on it) version is possible on every supported OS. And
>>> it would mean bumping portfiles, and rebuilding everything depending on
>>> dropped versions. It probably wouldn't be worth the bother, and given all
>>> the constraints, might only get rid of a few versions.
>>>
>>
>> so we've got 2 issues here :
>> - which pythonXY the pyXY-{name} support
>> and whether theese can be brought up to python37
>> - whether any Portfile that demands a pythonXY that isn't python37
>> can be updated to depend on python37 instead
>>
>> We'll need some statistict / overview on this matter.
>> I'll look into this.
>>
>> It's also a question about keeping the macports infrastructure up-to-date.
>>
>> I've eg somehow gotten libsvm installed, and it has :
>> Variants: [+]java, [+]python27, python34, [+]tools, universal
>> as well as being seriously out-of-date:
>> libsvm @3.20_2 -> Version 3.24, September 2019
>
> This looks like an obvious example of a port that simply no-one
> touched for years and should probably be easy to update, replace
> python34 with python37 (as well as make that one default if it works
> as expected).
I could realitively easily do the upgrade - I've already taken a look at
it. Problem is, it's not something I think I've ever used (it was
something I installed because of a College Course but they told us to
use Anaconda instead) so I'll have no way of testing it in production.
$=> port dependents libsvm
py37-pymvpa depends on libsvm
$=> port info py-pymvpa
py-pymvpa @2.6.5_1 (python, science, math)
Sub-ports: py27-pymvpa,
py34-pymvpa, py35-pymvpa, py36-pymvpa, py37-pymvpa
maintainers {stromnov @stromnov} openmaintainer
So, I'ld say, it's the responsibility of the maintainer of py-pymvpa to
also maintain libsvm.
>
> In general updating from 2.7 to 3.7 is not always possible, in
> particular we still don't have the port for wxWidgets (Phoenix), and
> software needs to be rewritten to use that one as well.
I know that. It's eg a major problem if you want/need to use utf-8.
>
> I would say that we'll need to keep 2.7 around, but of course switch
> to 3.7 as much as possible.
!!! EVERYBODY !!! is in process of switching over to 3.7 :
https://python3statement.org/
and ending support for their 2.7 versions on 2020-01-01
>
> Personally I don't mind if we remove all traces of Python 2.4-2.6
> which should be very easy. Almost nothing depends on that, it's just
> there if someone would want to some extent still run the older python.
I've taken the 1st step in that process :
https://github.com/macports/macports-ports/pull/5265
>
> Removing any traces of 3.x up to 3.6 should be straightforward, but
> requiring quite a bit of (tedious) work.
I'm willing to undertake that piece of clean-up ;-)
Are you of the opinion, that removing 3.5 too will be a good idea ?!?
>
> Mojca
>
> PS: just removing the numbers from portgroup is not sufficient. All
> ports that don't specify the default version need to be revbumped and
> checked that they are compatible with python 3.7 at least, or at least
> those should specify the default python version.
> n
As I've stated in a previous post, the 1st order of the day is to get
some stats on the size of the problem.
There'll also be the problem of transitioning to 3.8.0 that according to
the schedule should have 3.8.0 final: Monday, 2019-10-21 , so IMHO it
would be a good idea to plan for that already now.
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Bjarne D Mathiesen wrote:
> Richard L. Hamilton wrote:
>> Depending on the results, with some effort, it might be possible to drop
>> some of the intermediate versions. But only if a later suitable (for
>> everything dependent on it) version is possible on every supported OS. And
>> it would mean bumping portfiles, and rebuilding everything depending on
>> dropped versions. It probably wouldn't be worth the bother, and given all
>> the constraints, might only get rid of a few versions.
>>
>
> so we've got 2 issues here :
> - which pythonXY the pyXY-{name} support
> and whether theese can be brought up to python37
> - whether any Portfile that demands a pythonXY that isn't python37
> can be updated to depend on python37 instead
>
> We'll need some statistict / overview on this matter.
> I'll look into this.
This ;-) nasty ;-) piece of bash scripting will give an oversigt of all
the pyXY-{name} ports and which versions of python they claim to support
I'll post a file on my website, when it has finished running :-)
Finished : https://macports.mathiesen.info/portfiles/python/pyPorts.txt
Optimised/revised script ; runs 9 times faster than the original
--- begin bash script ---
#!/macports/bin/bash
declare -a pyVersions=( 26 27 32 33 34 35 36 37 )
declare -a pyPorts=( $( port -q search --name py- \
| sed -E -e '/^py-/!d' ) )
maxLetters=$( \
for (( i=0 ; i<${#pyPorts[@]} ; i++ ))
do
echo ${#pyPorts[${i}]}
done | sort -u -n | tail -1 )
(( maxLetters+=5 ))
for pyPort in ${pyPorts[@]}
do
printf "%-${maxLetters}s" ${pyPort}
subPorts=$( port info --subports --maintainer ${pyPort} )
for V in ${pyVersions[@]}
do
subCount=$( echo "${subPorts}" | fgrep -c "${V}" )
if [[ "${subCount}" -eq 0 ]]
then
echo -n " "
else
echo -n "${V} "
fi
done
echo $( echo ${subPorts} \
| sed -E -e 's/^.*://' -e 's/.* ([^ ]*\@[^ ,]*).*$/\1/' )
done
--- end bash script ---
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: [portgroups] Python
Mojca Miklavec wrote: > Removing any traces of 3.x up to 3.6 should be straightforward, but > requiring quite a bit of (tedious) work. > > Mojca > > PS: just removing the numbers from portgroup is not sufficient. All > ports that don't specify the default version need to be revbumped and > checked that they are compatible with python 3.7 at least, or at least > those should specify the default python version. I've taken the 1st steps : https://trac.macports.org/ticket/59029 https://trac.macports.org/ticket/59030 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: Virtual Machines & Binary Compatibilty
Ryan Schmidt wrote: > > On Aug 31, 2019, at 14:32, Richard L. Hamilton wrote: > >> Also, for Snow Leopard, the OS license requires that OS and client both be >> OS X Server, and virtualization software will probably enforce that >> regarding the client (although by creating the right file in the image, it >> might be possible to fake having Server). Good luck getting media for that. > > I have copies of Snow Leopard Server available for sale if anyone still needs > it. What's the price & delivery costs ?!? :-) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[mysql56] compile failure on 10.6.8 x86_64
version:1
:debug:sysinfo Mac OS X 10.6 (darwin/10.8.0) arch i386
:debug:sysinfo MacPorts 2.6.0
:debug:sysinfo Xcode 3.2.6
:debug:sysinfo SDK 10.6
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.6
[ 92%] Linking CXX static library libsql.a
cd /macports/var/macports/build/.../mysql56/work/build/sql &&
/macports/bin/cmake -P CMakeFiles/sql.dir/cmake_clean_target.cmake
cd /macports/var/macports/build/.../mysql56/work/build/sql &&
/macports/bin/cmake -E cmake_link_script CMakeFiles/sql.dir/link.txt
--verbose=ON
/macports/bin/ar qc libsql.a ... lots of CMakeFiles/sql.dir/{name}.cc.o ...
/macports/bin/ranlib: file: libsql.a(debug_sync.cc.o) has no symbols
/macports/bin/ranlib libsql.a
/macports/bin/ranlib: file: libsql.a(debug_sync.cc.o) has no symbols
make[2]: Leaving directory
`/macports/var/macports/build/.../mysql56/work/build'
[ 92%] Built target sql
make[1]: Leaving directory
`/macports/var/macports/build/.../mysql56/work/build'
make: *** [all] Error 2
make: Leaving directory
`/macports/var/macports/build/.../mysql56/work/build'
Command failed: cd
"/macports/var/macports/build/.../mysql56/work/build" &&
/Developer/usr/bin/make -j2 -w all VERBOSE=ON
Exit code: 2
Error: Failed to build mysql56: command execution failed
main.log here :
https://macports.mathiesen.info/logs/databases/mysql56/main.log
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[mysql57] compile failure on 10.6.8 x86_64
version:1 :debug:sysinfo Mac OS X 10.6 (darwin/10.8.0) arch i386 :debug:sysinfo MacPorts 2.6.0 :debug:sysinfo Xcode 3.2.6 :debug:sysinfo SDK 10.6 :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.6 [ 77%] Building CXX object rapid/plugin/x/CMakeFiles/mysqlxtest.dir/generated/protobuf/mysqlx_notice.pb.cc.o ... make[2]: *** No rule to make target `archive_output_directory/libmysqlclient.a', needed by `rapid/plugin/x/mysqlxtest'. Stop. make[2]: *** Waiting for unfinished jobs [ 77%] Building CXX object rapid/plugin/x/CMakeFiles/mysqlxtest.dir/generated/protobuf/mysqlx_resultset.pb.cc.o ... make[2]: Leaving directory `/macports/var/macports/build/.../mysql57/work/build' make[1]: *** [rapid/plugin/x/CMakeFiles/mysqlxtest.dir/all] Error 2 make[1]: Leaving directory `/macports/var/macports/build/.../mysql57/work/build' make: *** [all] Error 2 make: Leaving directory `/macports/var/macports/build/.../mysql57/work/build' Command failed: cd "/macports/var/macports/build/.../mysql57/work/build" && /Developer/usr/bin/make -j2 -w all VERBOSE=ON Exit code: 2 Error: Failed to build mysql57: command execution failed main.log here : https://macports.mathiesen.info/logs/databases/mysql57/main.log -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et (næsten) M$-frit miljø MacOS X 10.13.6 High Sierra : 17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3 2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB MacOS X 10.6.8 Snow Leopard : Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
[mysql8] compile failure on 10.6.8 x86_64
version:1
:debug:sysinfo Mac OS X 10.6 (darwin/10.8.0) arch i386
:debug:sysinfo MacPorts 2.6.0
:debug:sysinfo Xcode 3.2.6
:debug:sysinfo SDK 10.6
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.6
[ 43%] Linking CXX static library libperfschema.a
cd /macports/var/macports/build/.../mysql8/work/build/storage/perfschema
&& /macports/bin/cmake -P CMakeFiles/perfschema.dir/cmake_clean_target.cmake
cd /macports/var/macports/build/.../mysql8/work/build/storage/perfschema
&& /macports/bin/cmake -E cmake_link_script
CMakeFiles/perfschema.dir/link.txt --verbose=ON
/macports/bin/ar qc libperfschema.a ... lots of
CMakeFiles/perfschema.dir/{name}.cc.o ...
/macports/bin/ranlib libperfschema.a
make[2]: Leaving directory
`/macports/var/macports/build/.../mysql8/work/build'
[ 43%] Built target perfschema
make[1]: Leaving directory
`/macports/var/macports/build/.../mysql8/work/build'
make: *** [all] Error 2
make: Leaving directory `/macports/var/macports/build/.../mysql8/work/build'
Command failed: cd "/macports/var/macports/build/.../work/build" &&
/Developer/usr/bin/make -j2 -w all VERBOSE=ON
Exit code: 2
Error: Failed to build mysql8: command execution failed
main.log here :
https://macports.mathiesen.info/logs/databases/mysql8/main.log
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et (næsten) M$-frit miljø
MacOS X 10.13.6 High Sierra :
17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
MacOS X 10.6.8 Snow Leopard :
Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
Re: old Macbook Pro
Dave Horsfall wrote: > an oldish MacBook Pro (13", Mid 2010) running > Sierra 10.12.6 (I've been told by the dealer that it cannot run High > Sierra, and when I tried it on an older MacBook it was a disaster). Apple states that it can run 10.13.6 (see MacTracker app) That one !is! able to run macOS 10.15.7 Cataina :-) I've got a comrade who's got the same model, and it works perfectly :-) http://dosdude1.com/catalina/ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.15.7 Cataina 2 x 3,46 GHz 6-Core Intel Xeon ; 112 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
[workaround] 10.6.8 & mysql57
According to https://ports.macports.org/port/mysql57/summary mysql57
fails to build on 10.6.
!!!BUT!!! using some "sleigh-of-hand", it's possible to get it to
install :-) You'll have to implement the workaround from
https://trac.macports.org/ticket/59072#comment:1
declare usrBin='/usr/bin'
declare devBin="/Developer${usrBin}"
while read -u 9 cctool
do
theTool=$( basename ${cctool} )
echo ${theTool}
for binDir in "${usrBin}" "${devBin}"
do
mv -n "${binDir}/${theTool}" "${binDir}/${theTool}.orig"
rm "${binDir}/${theTool}"
ln -h "${cctool}" "${binDir}/${theTool}"
done
done 9< <( port contents cctools | fgrep /bin/ )
At present I've got mysql57 running on two old 10.6.8 systems :-D
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
macOS 10.15.7 Cataina
2 x 3,46 GHz 6-Core Intel Xeon ; 112 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB
Re: [workaround] 10.6.8 & mysql57
So. Let me start by reverting my changes :
#=> cat libtoolRevert
#!/opt/local/bin/bash
declare usrBin='/usr/bin'
declare devBin="/Developer${usrBin}"
while read -u 9 cctool
do
theTool=$( basename ${cctool} )
echo ${theTool}
for binDir in "${usrBin}" "${devBin}"
do
rm "${binDir}/${theTool}"
done
done 9< <( port contents cctools | fgrep /bin/ )
for binDir in "${usrBin}" "${devBin}"
do
while read -u 9 orig
do
mv -v "${orig}" "${binDir}/$( basename "${orig}" ".orig" )"
done 9< <( find "${binDir}" -name '*.orig' )
done
The mysql57 Portfile is modified in a private repostitory:
namemysql57
set name_mysql ${name}
version 5.7.33
set boost_version 1.59.0
# Set revision_client and revision_server to 0 on version bump.
set revision_client 1
set revision_server 1
set version_branch [join [lrange [split ${version} .] 0 1] .]
categories databases
reinplace "s|@PREFIX@|${prefix}|g" \
${cmake.build_dir}/macports/macports-default.cnf \
${cmake.build_dir}/macports/my.cnf
# don't force /usr/bin/libtool -- allow cctools' version to be used
reinplace "s|/usr/bin/libtool|libtool|g" \
${worksrcpath}/cmake/libutils.cmake
}
configure.args-delete \
-DCMAKE_INSTALL_NAME_DIR=${prefix}/lib
configure.args-append \
-DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/${name_mysql}/mysql \
And I get :
#=> port outdated
The following installed ports are outdated:
mysql575.7.32_0 < 5.7.33_1
mysql57-server 5.7.32_0 < 5.7.33_1
#=> port -cuNp upgrade mysql57-server
Portfile changed since last build; discarding previous state.
---> Computing dependencies for mysql57
---> Fetching distfiles for mysql57
---> Attempting to fetch mysql-5.7.33.tar.gz from
https://cdn.mysql.com/Downloads/MySQL-5.7
---> Verifying checksums for mysql57
---> Extracting mysql57
---> Applying patches to mysql57
Warning: reinplace
s|@WORKSRCPATH@|/opt/local/var/macports/build/_Volumes_Bjarne_WebServer_MacPorts_newPorts_databases_mysql57/mysql57/work/mysql-5.7.33|g
didn't change anything in
/opt/local/var/macports/build/_Volumes_Bjarne_WebServer_MacPorts_newPorts_databases_mysql57/mysql57/work/mysql-5.7.33/cmake/install_layout.cmake
Warning: reinplace s|/usr/bin/libtool|libtool|g didn't change anything
in
/opt/local/var/macports/build/_Volumes_Bjarne_WebServer_MacPorts_newPorts_databases_mysql57/mysql57/work/mysql-5.7.33/cmake/libutils.cmake
---> Configuring mysql57
---> Building mysql57
Error: Failed to build mysql57: command execution failed
Error: See
/opt/local/var/macports/logs/_Volumes_Bjarne_WebServer_MacPorts_newPorts_databases_mysql57/mysql57/main.log
for details.
Keeepint my original workaround still works
Ken Cunningham wrote:
> Hey, I fixed that properly here
> <https://github.com/macports/macports-ports/commit/711eff230811974a2b995dd598a7af9a2ed1e9fc>
>
> if it doesn’t work for you, let me know.
>
> no need to overwrite all your /usr/bin stuff and cause who-knows-what damage…
>
> Ken
>
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
macOS 10.15.7 Cataina
2 x 3,46 GHz 6-Core Intel Xeon ; 112 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB
Re: MacPorts bash on Big Sur as default shell
I'd recommend the following which is part of my standard config: cd /private/etc cp paths paths.d/999-macOS mv paths paths.orig echo "/opt/local/bin" > paths echo "/opt/local/sbin" >> paths echo "/opt/local/bin/bash" >> shells echo "/opt/local/bin/zsh" >> shells you can now do "chsh -s /opt/local/bin/bash [user] -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.15.7 Cataina 2 x 3,46 GHz 6-Core Intel Xeon ; 112 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Replacing system sudo with MacPorts sudo?
has just released updates for this : https://support.apple.com/kb/HT212177 Sudo Available for: macOS Big Sur 11.2, macOS Catalina 10.15.7, macOS Mojave 10.14.6 Impact: A local attacker may be able to elevate their privileges Description: This issue was addressed by updating to sudo version 1.9.5p2. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.15.7 Cataina 2 x 3,46 GHz 6-Core Intel Xeon ; 112 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Build servers offline due to failed SSD
Further discussions : https://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ https://arstechnica.com/gadgets/2015/03/consumer-ssds-benchmarked-to-death-and-last-far-longer-than-rated/ https://arstechnica.com/gadgets/2020/05/zfs-versus-raid-eight-ironwolf-disks-two-filesystems-one-winner/ Lothar Haeger wrote: > Here‘s an in depth discussion on SSD reliability, a little more detailed > than „(not) recommended“ from someone with a lot of first hand > experience, it seems: https://www.backblaze.com/blog/how-reliable-are-ssds/ > > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.15.7 Cataina 2 x 3,46 GHz 6-Core Intel Xeon ; 128 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Build servers offline due to failed SSD
Have you looked at something like this for fast storage/cache : https://eshop.macsales.com/item/OWC/SSDACL4M20GB/ https://www.amazon.de/ASRock-Ultra-Quad-Controller-Karte-PCI-Express/dp/B079TQ9C6Q/ref=sr_1_6 Setting these up in RAID-0 (with proper backup) ought to be the fastest storage solution With OpenCore it might also be possible to get to 384 MB RAM -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Cataina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 128 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Using RAM instead of disk for build servers
Steven Smith wrote: > SSD RAID offers speed and fault tolerance. > > Simple options that are tolerant to a single disk failure are: > > * Free/one extra SSD: Use macOS Disk Utility to RAID 1 together two > smaller, inexpensive SSD drives for 100% redundancy. > * OWC ThunderBay 4 Mini, $279: Use macOS Disk Utility to RAID 1 > together four smaller, inexpensive SSD drives for 100% redundancy > and larger capacity. > * OWC ThunderBay 4 Mini with SoftRAID, $379: Use SoftRAID to RAID > 4 together four smaller, inexpensive SSD drives for 100% redundancy > and even larger capacity. (Caveats: no encryption, no boot volumes.) OWC ThunderBay is a bad solution for the hardware specified unless one is able to get - OpenCore - GigaByte Titan Ridge to work https://www.youtube.com/results?search_query=gigabyte+gc-titan+ridge+mac+pro+5+1+ The xServe only has - USB 480 MBit - FireWire 800 MBit which is far slower than the internal bays I'm presently trying to get this to work on my MacPro 2010. As to SoftRaid I simply can't recommend it. I've bought a full license, and after trying it out, I've had to un-install it again, as it made my whole system x10 slower when accessing my existing disks. SoftRaid 1) is fundamentally incompatible with any usage of APFS I had 2 x 18 TB HDs in AppleRAID-1 with APFS and several sub-volumes After installing SoftRaid, the read/write speed was reduced by a factor 10 2) only supports HFS+ according to my correspondance with OWC, they've no present plans for supporting APFS Presently, I'm using OpenZFS on Mac on 4 x 6 TB HDs in RAIDZ-1 #=> cat createZFS diskutil unmountdisk force disk4 diskutil unmountdisk force disk5 diskutil unmountdisk force disk6 diskutil unmountdisk force disk7 # set ashift to 13 when using SSD zpool create \ -f \ -o ashift=12 \ -O casesensitivity=sensitive \ -O normalization=formD \ -O compression=lz4 \ BjarneZFS raidz1 \ /dev/disk3 /dev/disk4 /dev/disk5 /dev/disk6 zpool set feature@encryption=enabled BjarneZFS zfs create \ -o encryption=on \ -o keylocation=prompt \ -o keyformat=passphrase \ BjarneZFS/MesterD zfs create BjarneZFS/BDMdata zfs create BjarneZFS/Bjarne zfs create BjarneZFS/EyeTV zfs create BjarneZFS/HomeMesterD zfs set quota=1G BjarneZFS/HomeMesterD # this is for the Guest account # you'll have to modify the Guest user using dscl zfs create BjarneZFS/HomeGuest zfs set quota=1G BjarneZFS/HomeGuest zfs create \ -o recordsize=16k \ BjarneZFS/MySQL8 OpenZFS has a better read cache than macOS : https://en.wikipedia.org/wiki/Adaptive_replacement_cache I've got 2 x 4 TB HDs in the DVD-bays /dev/disk2 & /dev/disk3 (internal, physical): #: TYPE NAMESIZE IDENTIFIER 0: GUID_partition_scheme *4.0 TB disk2 1: EFI EFI 209.7 MB disk2s1 2:Apple_APFS Container disk10 500.0 GB disk2s2 3:Apple_RAID 3.5 TB disk2s3 4:Apple_Boot Boot OS X 134.2 MB disk2s4 /dev/disk10 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0:APFS Container Scheme - +500.0 GB disk10 Physical Store disk2s2 1: APFS Volume Mojave 001 91.0 GB disk10s1 2: APFS Volume Catalina 011 - Data 88.7 GB disk10s2 3: APFS Volume Catalina 01112.6 GB disk10s3 4: APFS Volume Preboot 182.3 MB disk10s4 5: APFS Volume Recovery1.6 GBdisk10s5 6: APFS Volume VM 1.1 MBdisk10s6 7: APFS Volume Big Sur - Data 86.0 GB disk10s7 8: APFS Volume Big Sur 12.5 GB disk10s8 /dev/disk7 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_APFS +3.5 TB disk7 /dev/disk11 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0:APFS Container Scheme - +3.5 TB disk11 Physical Store disk7 1: APFS Volume VMs 2.1 TB disk11s1 2: APFS Volume NyProg 148.8 GB disk11s2 3: APFS Volume Buffer 197.7 MB disk11s3 I haven't trid zvol + APFS, but I might try that at a later date I've got 4 x original MiniStack, that at present has 2.5" 250 GB HDs that I'll upgrade to 1 TB HDs. When I get these, I'll try to see what happens with zvol + APFS -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCor
cMP w/ 256 GB RAM
>> With OpenCore it might also be possible to get to 384 MB RAM Currently, my setup is : OpenCore + macOS 10.15.7 Catalina MacPro 2010 (flashed to 5.1) 2 x 3,46 GHz 6-Core Intel Xeon 256 GB 1333 MHz DDR3 ECC 2 x 4 TB HDs in DVD bay - 3.5 GB of which is in AppleRAID-1 4 x 6 TB HDs in the trays - OpenZFS RAIDZ1 ATI Radeon RX 590 8 GB w/ 4 x 1080p I haven't upgraded to macOS 11 Big Sur yet as OpenZFS on macOS isn't available yet - we are awating a stable v. 2.0 information here : https://forums.macrumors.com/threads/activate-amd-hardware-acceleration.2180095/page-53?post=28255048#post-28255048 https://forums.macrumors.com/threads/crazy-idea-32gb-ram-modules-in-a-cmp-anyone-tried-this.2046693/page-7 I need those 256 GB because I'm virtualising whole server clusters for testing - both Windows and Linux -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: cMP w/ 256 GB RAM
Ken Cunningham wrote: > My own pair of classic MacPros are set up in a similar way. I find it a very > impressive and flexible setup indeed. > > I have the MacPros running the current BigSur, and they can multi-boot to > 10.15, 10.14, 10.6, and 10.5. The more powerful system also boots into > Windows10, where the new FlightSim 2020 rules. I've got the primary 10.15 on a PCIe SSD The OpenCore EFI is also on the PCIe SSD The 500 GB parts of the 4 TB HDs contain copies of both 10.15 & 10.14 (latest supported by Apple). I'm using CarbonCopyCloner to backup the SSD 10.15 to the two 4 TB HDs. Problem with OpenCore & Metal GPUs is if something goes seriously wrong, you have to : - replace the RAM modules with some macOS likes (eg 16 GB to each CPU) - re-insert the original GPU - pull the RAIDZ1 HDs (partially) out - boot from the external FireWire HD Actually, at present I've only got 1 x 4 TB HD in the DVD tray bay: the second one crashed even though it is younger than the active one. So my RAID-1 & duplicate copies has shown their value. > > I run Parallels in one of the installations, and have all the systems 10.5 to > 11.3 installed that way, (and WIndows 95, 98, 2000, and Ubuntu 2020.04). I've got a LaCie Rugged FireWire w/ 750 GB 2.5" HD with all macOS 10.5 - 10.15 on separate partitions both in bootable form as well as the latest installer. > > VirtualBox runs Tiger Intel and i386 Snow Leopard. What're your settings for i386 Snow Leopard ? I've tried to get it to work in VirtualBox, but the VM keeps crashing. My idea was to test / install / etc MacPorts in a VBox VM and then use lighttpd to update my 2 x 10.6 MacMini (Early 2006 & Mid 2007) servers. My MacMini servers have had their CPUs upgraded and max RAM. They've both 2 x external original MiniStack in AppleRAID-1. I've also got an original MacMini G4 (mac 10.5 PPC) that I had considered using as a firewall / proxy server; but I've had to give up on that idea as I've recently got 1000/100 cable internet installed & the ethernet ports simply can't handle that. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Reclaim was not 'safe'
Daniel J. Luke wrote:
> On May 9, 2021, at 12:20 PM, Gerben Wierda via macports-users
> wrote:
>> Anyway, the hard lesson was: reclaim is not ’safe’. I thought, reclaim
>> would only remove inactive installs, but it removed active ones as well.
>>
>> It is not possible for me to retrace what went wrong exactly, sadly.
>
> The first thing reclaim does is this:
>
> ---> Checking for unnecessary unrequested ports
> Unrequested ports without requested dependents found:
>
> If you (like me) have an MacPorts install that pre-dates the requested flag,
> you'll have a bunch of ports in that list that you don't actually want
> uninstalled. For reclaim to work best, you need to do `port setrequested` on
> the ports you want to always keep - then the list of ports you see there will
> be stuff that got installed that you no longer need. (You can also mark
> things 'unrequested', see the port manpage - so you can fix things up if you
> mistakenly mark something requested that you don't want).
>
> Or, you can just hit 'n' for the first prompt.
>
so, doing something like this :
port -q installed \
| awk '{print $1}' \
| xargs -n1 port setrequested
before the first use of 'port reclaim' would be advisable
I (luckily) didn't get burned, but I deemed 'port reclaim' to be unsafe
in automatic update scripts. In my case eg git was set up for reclaim.
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
I'm getting this on 10.6.8 Joshua Root wrote: > The MacPorts Project is happy to announce that the 2.7.0 version has now > been released. It is available via the usual methods: > > - selfupdate if you already have MacPorts installed Installing new MacPorts release in /opt/local as root:admin; permissions 0755 DEBUG: system -W /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base: CC=/usr/bin/cc ./configure --prefix=/opt/local --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline && make SELFUPDATING=1 && make install SELFUPDATING=1 checking build system type... x86_64-apple-darwin10.8.0 checking host system type... x86_64-apple-darwin10.8.0 checking target system type... x86_64-apple-darwin10.8.0 checking MacPorts version... 2.7.0 checking for sw_vers... /usr/bin/sw_vers checking for defaults... /usr/bin/defaults checking for xcode-select... /usr/bin/xcode-select checking macOS version... 10.6.8 checking Xcode location... /Developer checking Xcode version... 4.0.1 checking whether the C compiler works... no configure: error: in `/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base': configure: error: C compiler cannot create executables See `config.log' for more details Command failed: CC=/usr/bin/cc ./configure --prefix=/opt/local --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline && make SELFUPDATING=1 && make install SELFUPDATING=1 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
OK - on 10.6.8 I get : #=> ls -l /usr/bin/cc lrwxr-xr-x 1 root wheel 32 4 Jan 14:50 /usr/bin/cc -> ../llvm-gcc-4.2/bin/llvm-gcc-4.2 #=> ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -rwxrwxr-x 1 root admin 116992 12 Feb 2011 /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 on 10.15.7 I get : #=> ls -l /usr/bin/cc lrwxr-xr-x 1 root wheel 5 1 Mar 13:06 /usr/bin/cc -> clang #=> ll /usr/bin/clang -rwxr-xr-x 1 root wheel 31488 21 Sep 2020 /usr/bin/clang So the (temporary) fix for me on 10.6.8 is : #=> which clang /opt/local/bin/clang #=> mv /usr/bin/cc /usr/bin/cc.apple #=> ln -s $( which clang ) /usr/bin/cc #=> ll /usr/bin/cc lrwxr-xr-x 1 root wheel 20 19 Maj 15:53 /usr/bin/cc -> /opt/local/bin/clang -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
Chris Jones wrote: > See `config.log' for more details > > We need to see what is in this file… (from the messages you posted below). > re-instaling from source with : ./configure --prefix=/opt/local make make install gives : checking build system type... x86_64-apple-darwin10.8.0 checking host system type... x86_64-apple-darwin10.8.0 checking target system type... x86_64-apple-darwin10.8.0 checking MacPorts version... 2.7.0 checking for sw_vers... /usr/bin/sw_vers checking for defaults... /usr/bin/defaults checking for xcode-select... /usr/bin/xcode-select checking macOS version... 10.6.8 checking Xcode location... /Developer checking Xcode version... 4.0.1 checking for clang... clang & no problems [thumbsup] but emulating the selfupdate process with CC=/usr/bin/cc ./configure \ --prefix=/opt/local \ --with-install-user=root \ --with-install-group=admin \ --with-directory-mode=0755 \ --enable-readline \ && make SELFUPDATING=1 \ && make install SELFUPDATING=1 gives the following log : https://macports.mathiesen.info/logs/MacPorts-2.7.0/config.log -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
OK - I can see what the problem is : It can't find at valid assembler - and checking I get : root@MiniWeb 18:10:20 /usr #=> find . -name 'as.*' ./bin/as.orig ./share/aclocal-1.10/as.m4 ./share/man/man1/as.1 so at some point in time I've moved the Apple assembler aside to solve a MacPorts problem [thinking] - in particular I think it's this : https://trac.macports.org/ticket/59072#comment:1 It was discussed in the thread '[workaround] 10.6.8 & mysql57' on 28/01/2021 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
Ken Cunningham wrote: > I seem to remember something about a bunch of symlinks you made from cctools > things into macports cctools in the past (perhaps I recall wrong). You were recalling partially correctly : I didn't symlink cctools into /usr/bin - I pushed the Apple stuff common with cctools aside in order to be able to compile mysql57 : * https://trac.macports.org/ticket/59072#comment:1 * '[workaround] 10.6.8 & mysql57' The promised forwardported fix from mysql56 -> mysql57 never seemed to materialise itself [thinking] But I think I'll (also) keep my : /usr/bin/cc.apple -> ../llvm-gcc-4.2/bin/llvm-gcc-4.2 /usr/bin/cc -> /opt/local/bin/clang fix -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: MacPorts 2.7.0 has been released
Ryan Schmidt wrote:
> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
> earlier versions, a different method is used:
>
> What version of SQLite does your version of macOS have? Run:
>
> /usr/bin/sqlite3 --version
>
> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.
Qs:
1) does MacPorts !explicitly! request /usr/bin/sqlite3
-or- does MacPorts use the one found in ${PATH}
2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
eg for 10.6.8 I've got :
#=> /usr/bin/sqlite3 --version
3.6.12
#=> which sqlite3
/opt/local/bin/sqlite3
#=> sqlite3 --version
3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB
Warning: -Wimplicit-function-declaration
MacPorts 2.7.0 I've just done my usual : port -dN selfupdate port outdated port clean --all outdated port -upN upgrade outdated port -pN clean --work installed & I got this : ---> Configuring snort Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: pcap_lex_destroy: found in snort-2.9.17.1/config.log ---> Building snort ---> Configuring wget Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: MIN: found in wget-1.21.1/config.log strchr: found in wget-1.21.1/config.log ---> Building wget I've never seen this before !?! Is it something I have to worry about ?!? And if so : how do I fix it ?!? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Telnet not in Inetutils
Christoph Kukulies wrote: > No, of course I didn’t read the port notes since I don’t know where one can > find them after having done a > port install. You can simply do : #=> port notes Inetutils ---> inetutils has the following notes: All clients are now installed with the "g" prefix. If you want to see which binaries a port has installed, you can do : #=> port contents gsed | fgrep '/bin/' /opt/local/bin/gsed > Why did they do that (prefixing the utils with a „g“). Is it now a GNU thing? Because there're differences between the BSD versions & the Linux versions. (slightly off-topic) Eg BDS sed can't handle newlines in substitute strings which Linux sed (gsed) can : https://stackoverflow.com/questions/1251999/how-can-i-replace-a-newline-n-using-sed https://www.linuxquestions.org/questions/linux-software-2/sed-insert-a-newline-why-does-not-it-work-158806/ Eg whsn I'm monitoring my postfix log, I'm doing this: #=> cat ./showLog tail -40f mail.log \ | gsed -E -e 's/((:|;|,|>)) /\1\n\t/g' in order to get a more readable output -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø OpenCore + macOS 10.15.7 Catalina MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC ATI Radeon RX 590 8 GB
Re: Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration
See the thread : Warning: -Wimplicit-function-declaration from 20/05-2021 -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: mysql8 data dir owner and permissions?
Bill Cole wrote:
> On 2021-06-18 at 12:40:30 UTC-0400 (Fri, 18 Jun 2021 12:40:30 -0400)
> Murray Eisenberg
> is rumored to have said:
>
>> I have a non-default location for the data dir with mysql8, namely, as
>> specified in my.cnf:
>>
>> datadir = /Users/me/Databases/mysql/data
>>
>> What should the ownership of that directory, and its subdirectories
>> and files, be? And with what permissions?
>
> The owner needs to be whatever user runs the mysqld process, which
> creates, deletes, reads, and writes files there as a necessary part of
> its operation. That's probably _mysql. That user ALSO needs a path up to
> the root of the filesystem that it can traverse, i.e. that it has search
> permission for. Assuming this 'me' is the same as that for your httpd
> issue, you already have that for /Users and /Users/me.
>
> No other user needs any access except for whatever is doing your
> backups, which need read access on files & directories and search
> (execute) on directories. That is usually going to be root, so you don't
> need to be concerned about group ownership or other permissions.
>
>> At the moment, for reasons I do not know, I have:
>>
>> ls -ld /Users/me/Databases/mysql/data
>> drwxr-x--- 91 me staff 2912 Jun 18 10:18
>> /Users/me/Databases/mysql/data
The reason is probably, that you created this directory as the 'me' user
in order to later use it for your MySQL data. MySQL is on itself unable
to modify the permissions on exiting directories -or- create the needed
ones if the permissions on the enclosing directory is too strong.
>
> So, 'chown -R _mysql /Users/me/Databases' should do the trick.
>
I'd do
sudo chown -R _mysql:_mysql /Users/me/Databases/mysql/data
sudo find -type f /Users/me/Databases/mysql/data -exec 660 {} \;
sudo find -type d /Users/me/Databases/mysql/data -exec 770 {} \;
sudo chown o+x /Users /Users/me /Users/me/Databases
/Users/me/Databases/mysql
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
ATI Radeon RX 590 8 GB
Re: apache doc folder permissions problem
Bill Cole wrote: > On 2021-06-18 at 14:33:43 UTC-0400 (Fri, 18 Jun 2021 14:33:43 -0400) > Murray Eisenberg >> With macOS 11.4 at least, the command >> >> chmod a-r /Users >> >> and even >> >> sudo chmod a-r /Users >> >> gives error "chmod: Unable to change file mode on /Users: Operation >> not permitted”. > > Which indicates that Apple has decided to add /Users to the creeping > expanse of files and directories behind the Iron Curtain of SIP. > Consider yourself Protected. > >> (By contrast, making the change for /Users/me and /Users/me/Sites is OK.) > > I guess they are waiting for OS 12 to lock those down... > You can get around this problem by moving the user out from /Users In DiskUtil you can create a new unit in the APFS container for the user (me) . Then do : sudo chown me:staff /Volumes/me sudo chown 0751 /Volume/me sudo rsync -avH /Users/me/ /Volumes/me sudo rm -rf /Users/me sudo dscl . -create Users/me NFSHomeDirectory /Volumes/me Personally, I don't have any users in /Users - they all have their own /Volumes/ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes
Tabitha McNerney wrote: > Hi all, > > I haven't installed a fresh MacPorts system in quite some time but will > soon be doing so on a few Macs one running Catalina and the other Big > Sur. Starting with Catalina, the root volume / is read-only so how do > the MacPorts package installers set things up such that /opt/local can > remain the default path to MacPorts for both read and write > functionality on Catalina and Big Sur? /opt is one of the directories Apple defines at the / level as part of the Data Volume > Do the MacPorts package > installers make use of Apple's new bi-directional firmlinks capability > defined in /etc/synthetic.conf as also described on this page? > > https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/ No. That's not necessary as /opt transparently exists and is writable. > > Thank you. > > -TM In depth explanations are here : https://arstechnica.com/gadgets/2019/10/macos-10-15-catalina-the-ars-technica-review/11/#h1 https://arstechnica.com/gadgets/2020/11/macos-11-0-big-sur-the-ars-technica-review/11/#h1 So, If you go to /System/Volumes/Data in Terminal & do 'ls -l' you'll see the opt directory. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: Apache httpd 2.4.49 port will not launch on ElCap
Bill Cole wrote: > I'm wondering if anyone else has encountered this and if anyone has a sense > of whether this is really a MacPorts-specific problem or if it is (as I > suspect but have not been able to confirm) a problem with httpd. I'm running apache 2.4.49 on * 10.6.8 * 10.15.7 without any issues -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: XCode reinstall command-line tools
I'm just using this : # https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt touch /tmp/.com.apple.dt.CommandLineTools.installondemand.in-progress softwareupdate -ia rm /tmp/.com.apple.dt.CommandLineTools.installondemand.in-progress I've scripted it as part of my routine : https://trac.macports.org/wiki/howto/AdvancedDailyAdm -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: What version of Xcode for which macOS ?
This thread led me to search for the relationships between * Xcode version * macOS / OS X version and I couldn't find a table with these So far, I've come up with Mac OS X / mac OS | Xcode | 10.4Tiger | 2.4.1 10.5Leopard | 3.0 10.6Snow Leopard| 3.2.2 10.7Lion| 4.3.3 10.8Mountain Lion | 5.1.1 10.9Maverics| 6.2 10.10 Yosemite| 7 10.11 El Capitan | 8.2 10.12 Sierra | 9.2 10.13 High Sierra | 10.1 10.14 Mojave | 10.3 10.15 Catalina| 12.4 11 Big Sur | 13 12 Montery | Supplements / correction etc are more than welcome I do think we really need to have this listed explicitly somewhere -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: Does MacPorts need ALL of Xcode?
I usually install MacPorts from the tarball. In my experience, in order for macports itself to compile, you'll have to 1) install Xcode 2) install the Command Line Tools 3) open Xcode and let it install it's components otherwise, you'll get the error, that the c-compiler can't create an executable -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: Specify UserID and GroupID for MacPorts users, how can I do that?
FritzS GMX wrote: > Which users (and their groups) are created by MacPorts and how can they be > created during a new installation so that they get a UID (also GroupID) > previously defined by me. > Is there possibly a script suggestion that could be used before the MacPorts > installation? > > I want to achieve UID's & GroupID's starting from 530. > > I want to install MacPorts on my new M1 MacMini with Monterey. > > From my old Mac with ElCapitan > # _messagebus 512 > # avahi 511 > # ldap 500 > # macports 506 > # messagebus 508 > # named 509 > # pulse 510 > you've got three (3) Terminal commands to manage users directly # dscl # dsexport # dsimport so for your case something like : dsexport export.out \ /local/Default \ dsRecTypeStandard:Users \ -r _messagebus,...,pulse -u admin -p password ought to work -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: What is up with perl5.26 on Snow Leo?
This looks as the same problem we have with MySQL57, where it's using
the system cctools instaead of the more modern cctools from macports.
The fix is described here :
https://trac.macports.org/ticket/59072#comment:1
declare usrBin='/usr/bin'
declare devBin="/Developer${usrBin}"
while read -u 9 cctool
do
theTool=$( basename ${cctool} )
echo ${theTool}
for binDir in "${usrBin}" "${devBin}"
do
mv -n "${binDir}/${theTool}" "${binDir}/${theTool}.orig"
rm "${binDir}/${theTool}"
ln -s "${cctool}" "${binDir}/${theTool}"
done
done 9< <( port contents cctools | fgrep /bin/ )
On my 2 x 10.6.8 I've got :
#=> port installed perl*
The following ports are currently installed:
perl5 @5.28.3_0+perl5_30 (active)
perl5.30 @5.30.3_3 (active)
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
ATI Radeon RX 590 8 GB
ssh & ssh-agent conflict
Recently, I've gotten the exact same problem as described here : https://apple.stackexchange.com/questions/277479/openssh-hangs-at-rekey-after-134217728-blocks https://itectec.com/askdifferent/openssh-hangs-at-rekey-after-134217728-blocks/ and the work-around of setting SSH_AUTH_SOCK='ssh g...@github.com' works as described BUT I'm at a loss as to which process messes ssh up :-( I don't have any running ssh-agent.plist anywhere I'm having this problem on both of my macmini1,1 10.6.8 macmini2,1 10.6.8 but not my MacPro5,1 They've all got openssh @8.8p1_2+kerberos5+xauth Any ideas as to how I can trouble-shoot this further ??? thanks, -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: ssh & ssh-agent conflict
OK - I've gotten a bit further : When I took a look at env variables, I saw this: SSH_AUTH_SOCK=/tmp/launch-Mnqkqu/Listener #=> ls -l /tmp/launch-Mnqkqu/Listeners srwx-- 1 root wheel 0 20 Dec 03:11 launch-Mnqkqu/Listeners Any tips regarding how I can find out who has set this ? Q: does the MacPorts OpenSSH try to start an ssh-agent ? -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: ssh & ssh-agent conflict
further dectective work has given me : root@MiniWeb 22:41:05 /tmp #=> lsof | sed -En -e '1,1p' -e '/launch-Mnqkqu/p' COMMAND launchd PID 136 USER root FD 11u TYPE unix DEVICE 0x04fc6dd0 SIZE/OFF 0t0 NODE NAME /tmp/launch-Mnqkqu/Listeners so, it's something started by launchctl #=> launchctl list | grep 136 136 - com.apple.launchd.peruser.0 and it's apparently from LaunchAgents somewhere OK - /System/Library/LaunchAgents & org.openbsd.ssh-agent.plist & Console shows that it's trying to start it every 10 sec but it seems as if I can only get rid of it after re-login [thinking] because as the service isn't actually running it can't be administered #=> ll /usr/bin/ssh-agent ls: /usr/bin/ssh-agent: No such file or directory So, at some time this ssh-agent existed, but now it's disappeared somehow mysteriously ... kill -9 136 got rid of the re-spawning, but the SSH_AUTH_SOCK env variable is still set when opening a Terminal window/tab Seems as if I'll have to do an unset SSH_AUTH_SOCK whenever I'll use ssh until reboot and I've changed /usr/bin/ssh-agent to /opt/local/bin/ssh-agent in org.openbsd.ssh-agent.plist ++ | SOLVED | ++ -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: ssh & ssh-agent conflict
So, one reboot later; & I've got : #=> ps axu | sed -En -e '1,1p' -e '/ssh/p' USER PID %CPU %MEM VSZRSS TT STAT STARTED TIME COMMAND root 110 0,0 0,0 2442336372 ?? Ss7:58am 0:00.00 sshd: /opt/local/sbin/sshd [listener] 0 of 10-100 startups root 255 0,0 0,1 2450756 2584 ?? S 8:06am 0:00.02 /opt/local/bin/ssh-agent -l & no issues -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
Re: Running a mail server via MacPorts on macOS Monterey
I'm running a mail server setup on 10.6.8 * postfix * dovecot * mysql * sqlgrey Gerben Wierda via macports-users wrote: > Apart from Steven Smith, are there other users here that run a mail > server setup via MacPorts? And is already someone else running on Monterey? > > I am and I’d like to link up to compare the situations, issues, etc. > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa --- denne besked er skrevet i et totalt M$-frit miljø MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM ATI Radeon RX 590 8 GB
configure error in php apache2handler
I'm seeing this for both php55-apache2handler php71-apache2handler Does anybody have any idea as to what's going on how to solve this ??? MacPro: root# port -f clean --all php71-apache2handler ---> Cleaning php71-apache2handler MacPro: root# port upgrade php71-apache2handler ---> Computing dependencies for php71-apache2handler ---> Fetching distfiles for php71-apache2handler ---> Attempting to fetch php-7.1.11.tar.xz from http://pl.php.net/get/php-7.1.11.tar.xz/from/this/mirror?dummy= ---> Verifying checksums for php71-apache2handler ---> Extracting php71-apache2handler ---> Applying patches to php71-apache2handler ---> Configuring php71-apache2handler Error: Failed to configure php71-apache2handler, consult /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php71-apache2handler/work/php-7.1.11/config.log Error: Failed to configure php71-apache2handler: configure failure: command execution failed Error: See /macports/var/macports/logs/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php71-apache2handler/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. MacPro: root# grep 'fatal error' /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php71-apache2handler/work/php-7.1.11/config.log conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found conftest.c:52:10: fatal error: 'minix/config.h' file not found conftest.c:19:10: fatal error: 'minix/config.h' file not found -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.12.6 Sierra (16G29) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
10.13.2 supplemental update & root account
!!! WARNING !!! The 10.13.2 supplemental update in-activates the root account if enabled Luckily, on the machines I've updated, I also had a normal admin account, so no big deal ; but I also have a machine with no normal admin account, so if it does that on that one also, it'll be a hell of a problem getting an admin account again (I do know how to do it) -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
/usr/libexec/path_helper problem
I'm having problems with /usr/libexec/path_helper on some of my machines
& I've been completely unable to discover what it is that's going wrong :-(
Now, as part of my install process of MacPorts I'm doing this :
# setup the system paths
('paths')
mkdir -p /etc/paths.d
cp-np /etc/paths /etc/paths.orig
mv-n /etc/paths /etc/paths.d/999macosx
touch /etc/paths
echo "${prefix}/bin"> /etc/paths.d/000macports
echo "${prefix}/sbin" >> /etc/paths.d/000macports
echo "/Applications/Xcode.app/Contents/Developer/usr/bin" >
/etc/paths.d/888developer
I waited until 10.13.2 was released before upgrading from 10.12
I've got 4 computers with 10.13.2
On two of these I get the correct result from running
#=> /usr/libexec/path_helper
PATH="/macports/bin:/macports/sbin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin";
export PATH;
On the other two I get this :
#=> /usr/libexec/path_helper
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/macports/bin:/macports/sbin:/Applications/Xcode.app/Contents/Developer/usr/bin";
export PATH;
No matter what I've tried I get an incorrect ${PATH} value :-(
Under 10.12 & before I had no problems at all !
OK - there was once under 10.5 that path_helper was buggy for some time
I've tried diff on the binaries, but they seem to be identical.
On the affected machines, I solved this by installing an old scripted
version of path_helper from 10.5 - that I had lying around - under
/usr/local/bin & modifying /private/etc/profile to point to this instead
Anybody else seeing this kind of problem ???
--
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
macOS 10.13.2 High Sierra (17C205)
2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC
ATI Radeon HD 5770 1024 MB
Re: /usr/libexec/path_helper problem
It suddenly struck me what the difference between the systems are : The two computers with the problems have SSDs and Apple_APFS without any issues have "Spinning Rust" and Apple_HFS -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
Jan Stary wrote: > I don't get it. 10.13.2 does _not_ have a root account by default? Why? > And if it does, how is that a problem? It's UNIX, of course there is > a 'root' account. macOS out-of-the-box has a de-activated root account; eg you can't log in as root or ssh into the box as root. The root account exists but in a dormant state and is accessed though sudo from admin accounts. One of the things I do on my boxes is activating the root account; and in some cases removing the other admin accounts, so I've only got root and users. Now, if the root account is de-activated you have no way of administering the box - even with sudo at normal user accounts can't use sudo. Also if you have scrips that eg ssh into the box from the outside, this will completely thow off your setup. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
Jan Stary wrote: > On Jan 15 10:21:05, macint...@mathiesen.info wrote: >> One of the things I do on my boxes is activating the root account; > > Meaning that you can now do what? > Login as root on a console? > Login as root via ssh? > >> and in some cases removing the other admin accounts, > > Why? When root is activated, there's no need for a normal admin account > >> so I've only got root and users. > > Meaning: users that can't su to root? correct > >> Now, if the root account is de-activated > > Is _that_ the problem you are talking about? > i.e. Apple 'disables' the root account with the udate? yes > >> you have no way of administering the box >> - even with sudo at normal user accounts can't use sudo. > > Well, keep yourself being admin then. why ? Apple shouldn't disable the root account through a supplementary update when I've chosen to activate it. They have _never_ done this before ! > >> Also if you have scrips that eg ssh into the box from the outside, >> this will completely thow off your setup. > > You have scripts that remotely log in as root? presently no but I ssh into my boxes as root in order to admin them there's stuff I can only access as root - eg the postfix and dovecot logs -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
William H. Magill wrote: > As I understood the description of the patch/update — the Root Account is > only de-activated if it has no password. > Making it just like all previous releases of OSX. It wasn't an issue of having an _active_ root account The root account wasn't active; but you could still use it in System Preferences > Users & Groups ; and because it wasn't active, it had no password - leading to the security blunder and a local exploit > > If you have activated the Root Account and supplied a password, then nothing > happens. Nope - 16 character long non-obvious strong password still de-activated :-( I only installed 10.13 when 10.13.2 was released and my root accounts 'survived' that update from 10.12 without any problems at all But the 10.13.2 supplementary update de-activates the root account And that update should only have something to do with Spectre and Safari/WebKit > > Read Mac Rumors description: > https://www.macrumors.com/2017/11/29/apple-fixes-root-password-bug-security-update/ > > The original bug description: > https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-admin-access/ > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
Ryan Schmidt wrote: > > Using the root account is not recommended; you should use an admin account > instead. > > If you must use the root account, and you have no admin account with which to > enable it the normal way, you can apparently enable it in single user mode: > > http://sachinparmarblog.com/enable-root-user-password-in-single-user-mode/ The issue is not whether or not I'm using the root account or not ; neither how and why I'm using it on my boxes - that's purely my own business ; and -frankly- please stay out of that ! So far, none of you have netiher referenced or nor commented on the _REAL_ issue which is Apple de-activating the root account in a supplementary update when they -in my opinion- shouldn't do that :-( -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
