Re: Virtual Machines & Binary Compatibilty

[Richard L. Hamilton]

I'm also interested, if you'd prefer to reply off-list.

> On Sep 13, 2019, at 19:33, Bjarne D Mathiesen  
> wrote:
> 
> 
> 
> 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
> 

Re: Virtual Machines & Binary Compatibilty

[Bjarne D Mathiesen]

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

Re: [portgroups] Python

[Bjarne D Mathiesen]

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: [portgroups] Python

[Bjarne D Mathiesen]

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: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

[Steven Smith]

This should just work building ghc from source. Did it? Does it install the pdf 
GHC User Guide?

This is an outstanding ticket issue, so we’d like to wrap this up with a fix.

It’s not clear to me if the ghc build wasn’t working your you (bad), or a 
one-time LaTeX compilation wasn’t working (much less bad).

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


>> This issue is supposed to be fixed in these lines:
> 
> Those lines did fix it, thank you. I was working on something parallel and 
> ran into the DejaVu font issue. I thought my latex configuration was wrong in 
> some way. Then I saw the workaround you put into the portfile. Changing the 
> fontspec did work.
> Googling this same error shows it comes up in other software sometimes.
> 
> Is it a Mac thing? Why do we need to do this change, but the rest of the 
> planet does not? Rather than fix ports, I wonder if we're supposed to fix our 
> fonts...

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

[Ken Cunningham]

> This issue is supposed to be fixed in these lines:

Those lines did fix it, thank you. I was working on something parallel and ran 
into the DejaVu font issue. I thought my latex configuration was wrong in some 
way. Then I saw the workaround you put into the portfile. Changing the fontspec 
did work.
Googling this same error shows it comes up in other software sometimes.

Is it a Mac thing? Why do we need to do this change, but the rest of the planet 
does not? Rather than fix ports, I wonder if we're supposed to fix our fonts...

Ken

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

[Steven Smith]

Here’s the ports I have on a working system that provide the DejaVu fonts:

> locate DejaVuSansMono.ttf | egrep -e '^/opt/local' | xargs port provides | 
> sed -E -e 's/^[^:]+:[[:space:]]//' | uniq
> py37-matplotlib
> dejavu-fonts
> texlive-fonts-extra

The port texlive-fonts-extra should install this file, and everything should 
work:

/opt/local/share/texmf-texlive/fonts/truetype/public/dejavu/DejaVuSansMono.ttf

The other two ports should be irrelevant.

The reinplace lines in the Portfile (below) should have removed all the spaces 
from this font name in the LaTeX file and added a “.ttf” to the find 
specification.

Did this happen? It doesn’t look like it from your LaTeX logs. Why isn’t there 
a .ttf? Which files are those? What happens if you go to ${worksrcpath}, edit 
the offending .tex file, and compile it by hand?


> This issue is supposed to be fixed in these lines:
> https://github.com/macports/macports-ports/blob/2c234633658e98876b28b4cdf07852a2eff07b86/lang/ghc/Portfile#L183-L194

Re: [portgroups] Python

[Ralph Seichter]

* raf:

> i hope python27 wont't go away.

Would you mind stepping a bit further away? Thanks. :-)

-Ralph

Re: rspamd binaries fail with illegal instruction 4:

[Steven Smith]

I’m not an expert either, but it looks like it’s related to hyperscan 
(“ue2::hs_compile_multi_int”).

Possibly related: https://github.com/intel/hyperscan/issues/133

I suggest two paths:

1. Poke at hyperscan and see if that’s the problem on this specific 
architecture.

2. That’s exactly the information the upstream author needs to pinpoint the 
problem. Please open an issue at https://github.com/rspamd/rspamd/issues and 
post that very same lldb output, along with the error message, and ask for help 
there. He’ll probably send you along to hyperscan, but would also have insight 
if it’s something rspamd-specific.

> I was finally able to run a test on the failing rspamd, I am not familiar 
> with reading this core dumps and followed the instructions given in the URL, 
> i got following from lldb:
> 
> 
> lldb `which /opt/local/bin/rspamd` -c /cores/core.89034 
> (lldb) target create "/opt/local/bin/rspamd" --core "/cores/core.89034"
> Core file '/cores/core.89034' (x86_64) was loaded.
> (lldb) bt all
> * thread #1, stop reason = signal SIGSTOP
>   * frame #0: 0x0f4c74b1 
> librspamd-server.dylib`ue2::hs_compile_multi_int(char const* const*, unsigned 
> int const*, unsigned int const*, hs_expr_ext const* const*, unsigned int, 
> unsigned int, hs_platform_info const*, hs_database**, hs_compile_error**, 
> ue2::Grey const&) + 513
> frame #1: 0x0f4c7c40 librspamd-server.dylib`hs_compile_multi + 96
> frame #2: 0x0f2daff5 
> librspamd-server.dylib`rspamd_multipattern_compile + 370
> frame #3: 0x0f376b70 
> librspamd-server.dylib`rspamd_language_detector_init + 5664
> frame #4: 0x0f31d570 librspamd-server.dylib`rspamd_config_read + 
> 1262
> frame #5: 0x00010d479de8 rspamd`load_rspamd_config + 107
> frame #6: 0x00010d479499 rspamd`main + 1373
> frame #7: 0x7fff55d0f015 libdyld.dylib`start + 1
> (lldb) 
> 
> It created two core dumps every minute until I unloaded rspamd.
> 
> Regards,
> Horst
> 
>>> On 10 Sep 2019, at 11:40, Steven Smith  wrote:
>>> 
>>> AVX was just a guess. Based in the above it could be sse 4.2 that is the 
>>> issue. The machine that is failing lacks this (which actually makes that 
>>> cpu pretty old I would guess)
>> 
>> A core dump is the most efficient diagnostic. It’s fast and easy. The modern 
>> macOS instructions are here: 
>> https://rspamd.com/doc/faq.html#how-to-figure-out-why-rspamd-process-crashed
> 

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

[Steven Smith]

This issue is supposed to be fixed in these lines:
https://github.com/macports/macports-ports/blob/2c234633658e98876b28b4cdf07852a2eff07b86/lang/ghc/Portfile#L183-L194
https://github.com/macports/macports-ports/blob/2c234633658e98876b28b4cdf07852a2eff07b86/lang/ghc/Portfile#L183

But obviously there’s still some issue. See:
* https://trac.macports.org/ticket/59018
* https://github.com/macports/macports-ports/pull/5049

The good news is that this works nicely if the correct dependencies are 
installed. The bad new is that I don’t know that dependency. When I have access 
to “port provides” on the right box I’ll try to figure that out.

In the meantime, it would be helpful and appreciated if you could track down 
the necessary port so that we can fix the Portfile and get the GHC User’s Guide 
up and running.

> I'm working on making a newer bootstrap version of ghc for SnowLeopard.
> 
> The ghc 8.0.1 build finishes on 10.6.8, but it wants to build the PDF 
> documentation next, and texlive is erroring building the PDF.
> 
> I know nothing about texlive. I know I might turn off the docs, but -- it 
> took many hours to build ghc, and I would like to fix texlive.
> …
> \usepackage{fontspec}
> \usepackage{makeidx}
> \setsansfont{DejaVu Sans}
> \setromanfont{DejaVu Serif}
> \setmonofont{DejaVu Sans Mono}
> ''',
> }
> =
> 
> and that generates this bit in the generated tex file:
> 
> ==
> \usepackage{fontspec}
> \usepackage{makeidx}
> \setsansfont{DejaVuSans}
> \setromanfont{DejaVuSerif}
> \setmonofont{DejaVuSansMono}
> …
> (/opt/local/share/texmf-texlive/tex/latex/base/tuenc.def))
> (/opt/local/share/texmf-texlive/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
>  Invalid filename `DejaVu Sans', contains ' '
> 
> 
> ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

Re: [portgroups] Python

[Bjarne D Mathiesen]

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]

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