mingw-w64-python-hyphothesis - 3.76.0 - Update to latest version
mingw-w64-ptyhon-jupyter-lient - 5.4 - Update to latest version
mingw-w64-python-upyter-core - 4.4 - fix startup script files to run from MSYS2 prompt
mingw-w64-python-path - 11/5 - Update to latest version, fix dependencies to match Archlinux
omgw=w64=[u[arsomg - 2.2.1 - Update to latest version, rework to conform to pattern I established to facilitate tests
mingw-w64-python2-importlib_resources 1.0.1 - New package required by python-importlib-metadata
mingw-w64-python-importlib-metadata - 0.6 - new package required by python-path
mingw-w64-python-jupyter-console - devide into separate PKGBUIL's so python2 version is 5.2.0 and python3 version is 6.0.0 - An upgrade - Jupyter-console is dropping python2 in latest version
According to bindtextdomain man passing NULL is allowed
and must be interpreted as current value request.
This behaviour is implemented in non-patched bindtextdomain version.
The relocatable bindtextdomain implementation crashed in strrchr()
call when dirname==NULL was passed: it tried to relocate
NULL dirname (and strdup(NULL) returns NULL).
This patch disables relocation attempt if dirname=NULL.
The user-visible problem that lead to the crash is NOT tightly-related.
I was using VERY experimental mingw64 location on win7: gedit.exe from
"D:\m\noshortname with spaces and non ascii абвг ææ\msys2\mingw64\bin\"
where "D:\m\noshortname with spaces and non ascii абвг ææ\msys2"
is a junction to the actual msys2 root D:\apps\msys2 and
"noshortname with spaces and non ascii абвг ææ" has no short 8.3-name.
Understanding that this is NOT very useful scenario,
I think that bindtextdomain should handle NULL value according to man
since it may lead to another problems in "normal" usages
if some app would call it with NULL (as allowed in the docs).
I didn't investigate why gtk passes NULL as a dirname in this setup,
but after this libintl fix - gedit.exe starts fine.
(even more - it started from link with non-BMP characters in its name)
