0.17.16: test suite is failing in `umockdev:fails-valgrind / umockdev.py` unit

[kloczek]

+ cd umockdev-0.17.16
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: no work to do.
ninja: Entering directory `/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/7 umockdev / ioctl-tree                     OK               0.03s
2/7 umockdev / static-code                    OK               0.11s
3/7 umockdev:fails-valgrind / umockdev.py     FAIL             0.11s   exit status 1
>>> TOP_SRCDIR=/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16 G_DEBUG=fatal-warnings,fatal-criticals,gc-friendly LD_LIBRARY_PATH=/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/x86_64-redhat-linux-gnu/:/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/x86_64-redhat-linux-gnu MALLOC_CHECK_=3 PATH=/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/x86_64-redhat-linux-gnu:/usr/bin:/usr/sbin:/usr/local/sbin MALLOC_PERTURB_=61 GI_TYPELIB_PATH=/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/x86_64-redhat-linux-gnu /home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/src/umockdev-wrapper /usr/bin/python3 -Wd -Werror::PendingDeprecationWarning -Werror::DeprecationWarning /home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/tests/test-umockdev.py
――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
stderr:
Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/umockdev-0.17.16/tests/test-umockdev.py", line 29, in <module>
    gi.require_version('GUdev', '1.0')
AttributeError: module 'gi' has no attribute 'require_version'
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

4/7 umockdev:fails-valgrind / umockdev-vala   OK               1.05s
5/7 umockdev / umockdev-run                   OK               1.79s
6/7 umockdev:fails-valgrind / umockdev-record OK               2.04s
7/7 umockdev / umockdev                       OK               3.94s

Summary of Failures:

3/7 umockdev:fails-valgrind / umockdev.py     FAIL             0.11s   exit status 1

Ok:                 6
Expected Fail:      0
Fail:               1
Unexpected Pass:    0
Skipped:            0
Timeout:            0

I'm using gobject-introspection 1.75.4.

[eli-schwartz]

You do not have pygobject (the gi module) installed as a test dependency.

[kloczek]

No I didn't. Just added pkgconfig pygobject-3.0 dependencoes to build env and loos like it solved the issue. I think that it would be good to add dependency('pygobject-3.0') to main meson.build.

[kloczek]

I think that it would be good to add dependency('pygobject-3.0') to main meson.build.

Actually no .. dependency('pygobject-3.0') it installs pygobject header files and in this case it is missing python module so probably better would be add something like import('python').find_installation('python', modules: ['pygobject'])).

[kloczek]

Yep .. just tested and add to build dependencies pygobject modules fixes the issue.

[eli-schwartz]

But it doesn't want the pkg-config file, which is the development component useful for compiling against the pygobject C header.

It just wants to be able to perform a runtime import (import gi), so you need the python3-gobject module, not the python3-gobject-devel development package.

[kloczek]

But it doesn't want the pkg-config file, which is the development component useful for compiling against the pygobject C header.

It just wants to be able to perform a runtime import (import gi), so you need the python3-gobject module, not the python3-gobject-devel development package.

Yep and that is why I've added that better would be add checking for pygobject python module (which provides gi drecrory).

[martinpitt]

I'm not sure what to do with this.. This sounds like a downstream packaging issue? It seems solved now? Or is there anything that needs to be done upstream? Thanks!

[kloczek]

I'm not sure what to do with this.. This sounds like a downstream packaging issue? It seems solved now? Or is there anything that needs to be done upstream? Thanks!

As I wrote looks like in meson it is missing cecking dependecy (depends() call) for pygobject .

[martinpitt]

Tricky.. one really doesn't need the pygobject .pc file, e.g. the Fedora and Debian packaging don't have this either. That kind of runtime dependency is not what dependency() is good at.

[eli-schwartz]

As I pointed out above, checking for a dependency() would unreasonably add an additional distro package to Debian/Fedora build dependencies.

[kloczek]

OK .. mesom provides python modules dependencies checking. Something like below should probably do what is needed here 🤔

py_deps = import('python').find_installation('python3', modules: ['pygobject'])

[eli-schwartz]

That's the distro package name, not the python module name.

And it's fairly common for gi to have overrides that cause import gi to work, but not provide anything. This is why packages need to explicitly depend on python3-gobject if they use it, in addition to whichever packages might happen to provide gi overrides.

So just checking for gi won't help anyway.

And either way it's still a packaging issue.

[benzea]

In some cases I added a

try:
    import ....
except Exception as e:
    print("Missing dependencies: %s" % str(e))
    sys.exit(77)

block. Then the test just skips, and things are "fine" in some way. Obviously, you should still pull in the runtime dependency. But it makes it clear that this is a problem for you to solve and you can ignore it if you chose to do so.

That said, one does not want to accept a skipped test like this in CI for example.

[kloczek]

That's the distro package name, not the python module name.

pip shows

$ pip show PyGObject
Name: PyGObject
Version: 3.43.1.dev0
Summary: Python bindings for GObject Introspection
Home-page: https://pygobject.readthedocs.io
Author: James Henstridge
Author-email: james@daa.com.au
License: GNU LGPL
Location: /usr/lib64/python3.8/site-packages
Requires:
Required-by:

so pygobject as checked module name should be OK.

[kloczek]

yep ..

$ pip show pygobject
Name: PyGObject
Version: 3.43.1.dev0
Summary: Python bindings for GObject Introspection
Home-page: https://pygobject.readthedocs.io
Author: James Henstridge
Author-email: james@daa.com.au
License: GNU LGPL
Location: /usr/lib64/python3.8/site-packages
Requires:
Required-by:

[eli-schwartz]

Pip shows the pip package name, not the python module name.

The pip package name is usually the same as the distro package name (or at least very similar, modulo prefixes indicating the relation to python).

The python ecosystem prefers to call the thing you're viewing a "distribution" name, though. ;)

...

The point is, that meson only provides functionality for verifying that a module is importable. It will test modules: ['pygobject'] by attempting to run import pygobject. And failing.

Please. Accept that I know what I'm talking about here. I am upstream for meson, I know how meson works.

[kloczek]

Pip shows the pip package name, not the python module name.

OK so .. py_deps = import('python').find_installation('python3', modules: ['gi'])

[eli-schwartz]

And it's fairly common for gi to have overrides that cause import gi to work, but not provide anything. This is why packages need to explicitly depend on python3-gobject if they use it, in addition to whichever packages might happen to provide gi overrides.

So just checking for gi won't help anyway.

[martinpitt]

At the moment, meson.build checks for python and g-ir-compiler, and if both are found, enables the test:

if python.found()    
if g_ir_compiler.found()    
  test('umockdev.py', python,    
    args: ['-Wd', '-Werror::PendingDeprecationWarning', '-Werror::DeprecationWarning',    
           testsdir / 'test-umockdev.py'],    
    depends: [preload_lib, umockdev_typelib],    
    suite: 'fails-valgrind')    
endif    
endif    

I suppose this could grow a test for the python gi module; this is enough, as Fedora's python3-gobject-base provides nothing aside the gi module, so I'm not entirely sure what @eli-schwartz really means with "So just checking for gi won't help anyway".

@kloczek perhaps you can send a PR with what you would like to see here? Thanks!

[eli-schwartz]

I already explained it, but maybe this will do a better job:

It's possible to install: gi.overrides.FooBar as a python module. If you do this, python will think gi is installed, but it might not be.

One way to work around this is to make four packages instead of two, so that FooBar is one package, gi.overrides.FooBar is a second package, gi is a third package, and python3-gobject is a fourth package.

This works as long as you step carefully, i.e. checking for gi is semantically incorrect even if it sometimes works by accident.

The correct way to check is, of course, to actually run some test code from the gi module to verify that it's in good working order. The modules: kwarg does not work for gi, and never will.

[martinpitt]

FTR: I'm not going to do anything about this myself. I don't understand what you mean/want in the above comments. I'll be happy to review a PR of course. Thanks!

[martinpitt]

See above -- this isn't actionable, at least from my side.