Request: Auto-connections for lxi-tools


I would like to request the following plug auto-connections for lxi-tools:

lxi-tools:avahi-control     (required for lxi-tools' mDNS instrument search feature)
lxi-tools:process-control   (snappy-debug recommends it, sched affinity etc. stuff)

Additionally, I would like to have the following manual review issues resolved/accepted:

human review required due to 'deny-connection' constraint (interface attributes) declaration-snap-v2_slots_connection (dbus-slot-freedesktop, dbus)
human review required due to 'deny-connection' constraint (interface attributes) declaration-snap-v2_slots_connection (dbus-slot-gtk, dbus)
human review required due to 'deny-connection' constraint (interface attributes) declaration-snap-v2_slots_connection (dbus-slot-lxi-tools, dbus)

All the dbus slots have been added according to snappy-debug.

Link to lxi-tools snapcraft definition:

Snap store:


Hi, can you explain why you snap is slotting the org.freedesktop.DBus and org.gtk DBus names? This implies your snap would provide the DBus interface names however these are system-wide names and so your snap should not be trying to slot these. The io.github.lxi-tools name however is appropriately namedspaced to your snap and hence this is fine to slot and use by the snap. I have granted this. Please remove the slots for the other 2 dbus names and the snap should pass automated review.

Regarding the auto-connection request for avahi-control - is the mDNS search feature a core/primary feature of the snap that most users would expect to use?

For process-control does the snap function correctly without this? Since sched_set_affinity etc are usually more like nice-to-have than must-haves for an application, and process-control grants a reasonable amount of authority to the snap (say it can kill other processes run by your user etc) so I do not think this would be appropriate in general.


I understand. I have removed the 2 dbus slots - I only added those in a desperate attempt to silence snappy-debug.

Regarding avahi-control and mDNS - yes, it is a core feature because my application uses it to communicate with test instruments according to the LXI standard.

I’ve also removed the process-control plug. I added that one because snappy-debug recommended it. My application uses GTK4 which spawns a lot of render threads. It may be trying to optimize their performance by manipulating the sched affinity. However, in case of my application, I don’t detect any immediate negative performance effects by disabling the plug.

Excellent - thanks, I see the snap has now passed automated review. Regarding avahi-control, +1 from me for auto-connect of this for lxi-tools since this is a core function of the snap - in this case though, can you please update the description of the snap to mention that it can automatically detect network attached instruments or similar? Thanks.

Sure. I’ve updated the description to reflect your suggestion. Thanks.

Ping - I only need one more +1 for avahi-control. Thanks. :slight_smile:

Please, I need one more +1 for avahi-control. Thanks.

Only need one more vote…

Ping @review-team , please review. Thank you.

@alexmurray Do you have any idea how I get another vote on this?

Hey @lundmar, apologize for the delay.

I am +1 as well for auto-connect avahi-control since its clearly required for the snap to properly operate. +2 votes for, 0 votes against, granting auto-connect of avahi-control to lxi-tools. This is now live.

@lundmar since avahi-control is in fact avahi-observe + control I have removed the originally granted avahi-observe interface declaration (which I also see the latest revision does not specify it anymore).

1 Like

Great, thank you both!

1 Like