New test failures in latest release about tuigreet

[alerque]

https://gitlab.archlinux.org/archlinux/packaging/packages/greetd-tuigreet/-/commit/22d7a576974e29ce2419d1d88a2422380b350bed#9b9baac1eb9b72790eef5540a1685306fc43fd6c_38_37

[apognu]

Hi,

As far as I know, there shouldn't be any runtime dependency on anything other that on libc (through the uzers-rs crate).

The tests (and only the tests) that are behind the nsswrapper feature, on the other hand, use libnss_wrapper to mock responses from NSS (so we do not have to rely on actual users being present in the test environment).

You can see how it is being used here in the workflow.

I recognize, though, that I should update the README to reflect this information, which is not obvious at all. I apologize for this and will update it as soon as possible.

I remain available to help you through getting the tests to pass, in the meantime.

[apognu]

I added some instructions in the README as to how to run the whole test suite. Please keep me posted if they are enough of if you feel you need more information.

[alerque]

Thanks for the explanation and additional docs. So if I understand correctly this is only a testing dependency, not a run time dependency. Since we don't have libnss_wrapper packaged it isn't easy to run that test, but it seems like it's reasonably safe to skip it. Not 100% safe obviously but probably not a great loss on the packaging side since it isn't a true integration test anyway.

[apognu]

Indeed, it is only a test dependency.

Relatively safe, well that depends on the point of view, the feature calls into unsafe code (FFI to libc) on startup. So technically, it could segfault and prevent the program from working.

Now I do not know a perfect solution here, putting a precompiled shared library in the repository seems a bit shady, and I would prefer not to do that.