DistributionNotFound error on Arch

Upgraded Syu and started receiving errors; umonitor no longer runs.

This is

Name            : python-umonitor-git
Version         : r90.6175f3f-1
Build Date      : Mon 01 Jul 2019 04:44:20 PM CDT
Install Date    : Sat 23 Nov 2019 06:54:16 AM CST

and the error received for any execution (any arguments) is:

➜  ~ umonitor -a
Traceback (most recent call last):
  File "/usr/bin/umonitor", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'umonitor==20181018' distribution was not found and is required by the application

I also tried the umonitor-git package, which is:

Name            : umonitor-git
Version         : r180.0591487-1
AUR URL         : https://aur.archlinux.org/packages/umonitor-git
First Submitted : Sat 27 May 2017 06:33:32 PM CDT
Last Modified   : Thu 18 Oct 2018 10:27:42 PM CDT

but this version either complains about the config file:

➜  ~ umonitor --verbose --load .config/umon/umon.conf
Connected to server
Configuration file not found.

or segfaults:

➜  ~ umonitor -n --daemonize --verbose
[1]    2688712 segmentation fault (core dumped)  umonitor -n --daemonize --verbose

At the time I'm posting this, AUR is down for maintenance, or I'd report the package; maybe some of the dependency libraries were missed. In any case, reporting here for for posterity.

Update: got it working by installing from sources. I'm not a Python developer, but this is what worked for me.

Since I didn't want to pollute the global libraries, I tried installing it just for my user; python setup.py install doesn't take any arguments for setting the installation directory, but after some research I learned that easy_install can be used in this situation. The command I used was:

easy_install-3.8 --install-dir ~/.local/lib/python3.8/site-packages .

from the git clone directory, of course. Then I had to symlink the executable, which easy_install creates in the site-packages directory, to my ~/.local/bin. So, for anyone who, like me, tries to avoid Python as much as possible, the copy/paste commands are below; look in ~/.local/lib and pick a python version to use and change PYTHON_HERE appropriately; I just picked the latest version.

export PYTHON_HERE=~/.local/lib/python3.8
git clone https://github.com/rliou92/python-umonitor
cd python-umonitor
easy_install-3.8 --install-dir $PYTHON_HERE/site-packages .
ln -s $PYTHON_HERE/site-packages/umonitor ~/.local/bin/umonitor

umonitor is suddenly (and without any changes to the package) segfaulting again :-/

➜  ~ umonitor -a
[1]    3653911 segmentation fault (core dumped)  umonitor -a

I performed a git pull (no upstream changes), ran a python setup.py clean --all and re-installed it. Same output. With verbose:

➜  ~ umonitor --no_exec --verbose
INFO:root:Connected to X11 server.
INFO:root:Output name b'eDP1'
INFO:root:Finished edid_to_string on output b'AUO unknown'
INFO:root:Output name b'DP1-1'
INFO:root:Finished edid_to_string on output b'SAM SME2420L'
INFO:root:Output name b'DP1-2'
INFO:root:Finished edid_to_string on output b'SAM SME2420L'
INFO:root:Output name b'VIRTUAL1'
INFO:root:Finished edid_to_string on output b'N/A unknown'
[1]    3655071 segmentation fault (core dumped)  umonitor --no_exec --verbose

Valgrind reports the following (trimmed for brevity):

INFO:root:Output name b'DP1-1'
INFO:root:Finished edid_to_string on output b'SAM SME2420L'
INFO:root:Output name b'DP1-2'
INFO:root:Finished edid_to_string on output b'SAM SME2420L'
INFO:root:Output name b'VIRTUAL1'
INFO:root:Finished edid_to_string on output b'N/A unknown'
==3656598== Invalid read of size 1
==3656598==    at 0x483BC82: strlen (vg_replace_strmem.c:461)
==3656598==    by 0x7681DEB: __pyx_pf_8umonitor_6screen_6Screen_12_get_output_info (screen.c:2485)
==3656598==    by 0x7681DEB: __pyx_pw_8umonitor_6screen_6Screen_13_get_output_info (screen.c:2257)
==3656598==    by 0x7674257: __Pyx_PyObject_CallMethO (screen.c:7850)
==3656598==    by 0x7674257: __Pyx_PyObject_CallNoArg (screen.c:7876)
==3656598==    by 0x7674257: __pyx_pf_8umonitor_6screen_6Screen_30get_setup_info (screen.c:6716)
==3656598==    by 0x7674257: __pyx_pw_8umonitor_6screen_6Screen_31get_setup_info (screen.c:6626)
==3656598==    by 0x4B97CCF: ??? (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE561B: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB51E9: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.8.so.1.0)
==3656598==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3656598==
==3656598==
==3656598== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==3656598==  Access not within mapped region at address 0x0
==3656598==    at 0x483BC82: strlen (vg_replace_strmem.c:461)
==3656598==    by 0x7681DEB: __pyx_pf_8umonitor_6screen_6Screen_12_get_output_info (screen.c:2485)
==3656598==    by 0x7681DEB: __pyx_pw_8umonitor_6screen_6Screen_13_get_output_info (screen.c:2257)
==3656598==    by 0x7674257: __Pyx_PyObject_CallMethO (screen.c:7850)
==3656598==    by 0x7674257: __Pyx_PyObject_CallNoArg (screen.c:7876)
==3656598==    by 0x7674257: __pyx_pf_8umonitor_6screen_6Screen_30get_setup_info (screen.c:6716)
==3656598==    by 0x7674257: __pyx_pw_8umonitor_6screen_6Screen_31get_setup_info (screen.c:6626)
==3656598==    by 0x4B97CCF: ??? (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE5A10: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB5F0A: _PyFunction_Vectorcall (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BE561B: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.8.so.1.0)
==3656598==    by 0x4BB51E9: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.8.so.1.0)
==3656598==  If you believe this happened as a result of a stack
==3656598==  overflow in your program's main thread (unlikely but
==3656598==  possible), you can try to increase the size of the
==3656598==  main thread stack using the --main-stacksize= flag.
==3656598==  The main thread stack size used in this run was 8388608.
==3656598==
==3656598== HEAP SUMMARY:
==3656598==     in use at exit: 3,407,404 bytes in 2,297 blocks
==3656598==   total heap usage: 26,946 allocs, 24,649 frees, 61,208,746 bytes allocated
==3656598==
==3656598== LEAK SUMMARY:
==3656598==    definitely lost: 60 bytes in 1 blocks
==3656598==    indirectly lost: 0 bytes in 0 blocks
==3656598==      possibly lost: 145,160 bytes in 228 blocks
==3656598==    still reachable: 3,262,184 bytes in 2,068 blocks
==3656598==         suppressed: 0 bytes in 0 blocks
==3656598== Rerun with --leak-check=full to see details of leaked memory
==3656598==
==3656598== Use --track-origins=yes to see where uninitialised values come from
==3656598== For lists of detected and suppressed errors, rerun with: -s
==3656598== ERROR SUMMARY: 14346 errors from 190 contexts (suppressed: 0 from 0)
[1]    3656598 segmentation fault (core dumped)  valgrind umonitor --no_exec --verbose

Moved the config file out of the way (~/.config/umon is now empty), positioned everything with xrandr and ran umonitor --save. Got another segfault, and valgrind reports:

==3667865== HEAP SUMMARY:
==3667865==     in use at exit: 1,017,488 bytes in 479 blocks
==3667865==   total heap usage: 26,909 allocs, 26,430 frees, 61,204,540 bytes allocated
==3667865==
==3667865== LEAK SUMMARY:
==3667865==    definitely lost: 0 bytes in 0 blocks
==3667865==    indirectly lost: 0 bytes in 0 blocks
==3667865==      possibly lost: 18,896 bytes in 30 blocks
==3667865==    still reachable: 998,592 bytes in 449 blocks
==3667865==         suppressed: 0 bytes in 0 blocks
==3667865== Rerun with --leak-check=full to see details of leaked memory
==3667865==
==3667865== Use --track-origins=yes to see where uninitialised values come from
==3667865== For lists of detected and suppressed errors, rerun with: -s
==3667865== ERROR SUMMARY: 15643 errors from 210 contexts (suppressed: 0 from 0)

If the ERROR SUMMARY says 15,643 errors, is umonitor "valgrind clean?"

[rliou92]

Hmm let me look into this. Normally umonitor is valgrind clean.