Vula #96
Comments
fricklerhandwerk
added
program
|
Thanks for helping to package vula! Last week we tagged a new vula release that could be packaged immediately. However we're also working on a major upgrade that will change a key dependency by replacing We expect to have |
|
In my initial attempt I quickly found out that the dependencies "sibc" and "ggwave" appear to not be packaged in Nixpkgs. Since @ioerror commented that "sibc" might be replaced by another dependency in a newer version soon, I suggest to postpone further work until a version that does not depend on "sibc" is released. See #97 |
|
We'll need to package |
|
Understood. I was about to ask about ggwave: A PEP 631 Optional Dependency or rather PEP 621 Optional Dependency would be nice 😸 |
|
We'd prefer to only have packages that include For the next vula release tag, we'll look carefully at PEP 621/631 to see if anything could be made optional in addition to those three packages. |
|
Sweet. I think none of the NGIpkgs contributors would object to packaging vula, even if it unconditionally depends on ggwave. It's more of a comment/wish than a requirement, really, so don't let it slow you down. Nix does support having two flavours of the package (say, one for "headless" operation, that depends on ggwave, and one for "desktop" operation, that does not depend on ggwave) and most people like to keep things slim. Scenarios would be installing vula on a small home server, Raspberry Pi, etc. |
|
The new |
|
We have tagged and released new versions of https://codeberg.org/vula/vula/releases/tag/v0.2.2023112400 |
|
We have now tagged a new https://codeberg.org/vula/vula/releases/tag/v0.2.2023112801 The respective pypi releases are also now available: https://pypi.org/project/vula/0.2.2023112801/ The https://codeberg.org/vula/vula_libnss/releases/tag/0.0.2023112400 These should be suitable for testing and packaging. |
|
@fricklerhandwerk I packaged |
|
@fricklerhandwerk I improved the Investigating...systemd[1]: vula-discover.service: Scheduled restart job, restart counter is at 16. systemd[1]: Starting vula service discovery daemon... vula[1106]: Traceback (most recent call last): vula[1106]: File "/nix/store/…-vula-0.2.2023112801/bin/.vula-wrapped", line 9, in vula[1106]: sys.exit(main()) vula[1106]: ^^^^^^ vula[1106]: File "/nix/store/…-python3.11-click-8.1.7/lib/python3.11/site-packages/click/core.py", line 1157, in __call__ vula[1106]: return self.main(*args, **kwargs) vula[1106]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-python3.11-click-8.1.7/lib/python3.11/site-packages/click/core.py", line 1078, in main vula[1106]: rv = self.invoke(ctx) vula[1106]: ^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-vula-0.2.2023112801/lib/python3.11/site-packages/vula/notclick.py", line 124, in invoke vula[1106]: raise ex vula[1106]: File "/nix/store/…-vula-0.2.2023112801/lib/python3.11/site-packages/vula/notclick.py", line 103, in invoke vula[1106]: return super(Debuggable, self).invoke(ctx) vula[1106]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-python3.11-click-8.1.7/lib/python3.11/site-packages/click/core.py", line 1688, in invoke vula[1106]: return _process_result(sub_ctx.command.invoke(sub_ctx)) vula[1106]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-python3.11-click-8.1.7/lib/python3.11/site-packages/click/core.py", line 1434, in invoke vula[1106]: return ctx.invoke(self.callback, **ctx.params) vula[1106]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-python3.11-click-8.1.7/lib/python3.11/site-packages/click/core.py", line 783, in invoke vula[1106]: return __callback(*args, **kwargs) vula[1106]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-vula-0.2.2023112801/lib/python3.11/site-packages/vula/discover.py", line 232, in main vula[1106]: Discover.daemon(**kwargs) vula[1106]: File "/nix/store/…-vula-0.2.2023112801/lib/python3.11/site-packages/vula/discover.py", line 186, in daemon vula[1106]: process = system_bus.get( vula[1106]: ^^^^^^^^^^^^^^^ vula[1106]: File "/nix/store/…-python3.11-pydbus-0.6.0/lib/python3.11/site-packages/pydbus/proxy.py", line 44, in get vula[1106]: ret = self.con.call_sync( vula[1106]: ^^^^^^^^^^^^^^^^^^^ vula[1106]: gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name local.vula.organize was not provided by any .service files (2) systemd[1]: vula-discover.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: vula-discover.service: Failed with result 'exit-code'. systemd[1]: Failed to start vula service discovery daemon. |
|
@lorenzleutgeb is this closed by #97? |
|
No, see #97 (comment) |
|
@lorenzleutgeb Are the patches to systemd service files something that we should consider for merging upstream? |
|
@ioerror The patches we do apply so far are quite "mild" and mostly related to NixOS. But I'll keep in mind to notify you in case we have something to upstream. Just for reference:
|
|
@ngi-nix/magic filed an issue upstream: https://codeberg.org/vula/vula/issues/49 |
|
We, the maintenance mobs Magic and Cake have been working on this.
Most of the above issues have been resolved. Here is a snapshot of the known remaining tasks:
|
|
@A-jay98 it's good that you are improving on the current state. Thanks!
Please elaborate. I believe that you are mistaken, see ad2e9a5#r142089207
What makes you think that? There is no explicit configuration, but they are loaded directly from the configuration provided by upstream, which you can then customize/override using Upstream files are registered here: ngipkgs/projects/Vula/service.nix Line 73 in 17c5cb6 You might have broken this mechanism, see (again) ad2e9a5#r142089207 |
|
The |
|
Wanted to update the team regarding where @GetPsyched and I left things today while wrapping up pairing with @ioerror: Running the vula nixosTest: Resulted in output from vula regarding an invalid descriptor: Even though checking the SchemaError value of There were concerns around the python schema package version differences but the version of nixpkgs and vula are the same version We turned to enabling the full unittest suite of vula by passing pytest In @ioerror here is the command that I was running from https://github.com/ngi-nix/ngipkgs/tree/mob/vula-test branch to build the vula package and run the tests: Additional Note: after installing nix make sure to enable flakes since they are needed to use this ngi repo but are experimental: |
|
Also here is a way to get the versions of the dependencies that we are using for vula: |
|
I believe the patch is the culprit for the error there; it misses restoring the original intend, which was to Using diff --git a/vula/discover.py b/vula/discover.py
index 08235d9..3fe41f7 100644
--- a/vula/discover.py
+++ b/vula/discover.py
@@ -68,7 +68,10 @@ class WireGuardServiceListener(ServiceListener):
info: Optional[ServiceInfo] = zeroconf.get_service_info(s_type, name)
if info is None:
return
- data = {k.decode(): v.decode() for k, v in info.properties.items()}
+
+ data = dict()
+ for k, v in info.properties.items():
+ data[k.decode()] = v.decode() if v is not None else ''
try:
desc = Descriptor(data)With the new patch (which is still needed btw) I have peers running during an interactive shell |
|
@adfaure Would you open a pull request on vula for that fix? |
|
Looking at https://github.com/python-zeroconf/python-zeroconf/blob/9d8dd27c75768663319c0ee610ba9d274799e32c/src/zeroconf/_services/info.py#L271 - Returning None is intentional, especially if we look at the internal mutation functions. |
|
We designed our |
|
Hi @ioerror, it looks like the issue is deeper than the patch. Do you still need my pull request ? |
We would be happy to review a pull request, and we will also work on solving the other issues in parallel. |
|
I attempted to follow the instructions to reproduce this and was surprised that installing nix failed with the linked instructions when using a POWER9 machine ( |
We have now solved the issue (using nix on x86_64). We have confirmed that the fix works in nix if the We will release a new version of vula. In our release commit, we would like to credit everyone here for their help in finding this bug and for helping create a nix package for vula. Please let us know if you would like to be credited. Is there a standard way for the CI (e.g.: GHA or gitlab) to test building the nix vula package with an updated vula as we continue to improve vula? We would be happy to run such a test to ensure that vula is always ready for inclusion into an updated nix package. We would also be interested to include documentation to encourage people to consider using vula with nix once we have analyzed the properties of the nix environment. |
Confirming that vula now builds and pass all the test against the latest commit https://codeberg.org/vula/vula/commit/b82933c2d45496afb91727e7ce3dff61ae262473:
Fantastic @ioerror ! I'd be happy to be included.
Definitely doable. I think the easiest way to do this would be to refer to the vula pkg from ngipkgs (once its merged) then override the source to be the updated vula sources instead of a specific version. Happy to discuss other ideas with the wider team. |
Thank you, we don't remember why we thought that
Sorry, what we meant is that they are not configured to start. That was resolved (in |
|
@ioerror mentioning us and possibly our sponsors and the NixOS Foundation would be appreciated, but perhaps after the package is released? We will let you know when that happens. And then we'd also help you integrate testing this package into your CI. |
Yes, please do let us know. We'd be happy to do that in both projects (vula and highctidh) at the very minimum. Thank you again for all of your work on these packages, and thank you for taking the time to include us in your working process. |
The text was updated successfully, but these errors were encountered: