I notice both of these snaps seem to be published under their own separate publisher accounts (with the same names as each of the snaps) - however, if they were published under the same account then the content interfaces would auto-connect automatically, without any need for this request - would it be possible to publish them both under the same account?
@alexmurray As these have different scope and are managed by different teams, our preference is to have these be separate accounts for maintenance.
deviceupdate-agent meant to be published in the global store? I ask since the snapd-control interface is primarily intended to be used by brand store owners instead.
Hi @alexmurray, I can also confirm that the single publisher account option was discussed and fully detailed with Microsoft by the Canonical Field team including this benefit during development. The decision for the multiple accounts being taken on the basis of their internal operational requirements.
+1 from me for auto-connect the requested content interfaces as explained. Can other @reviewers please vote?
Thanks for the updated information regarding the choice of using multiple publishing accounts - +1 from me too for auto-connect of the requested content interfaces between these two snaps.
I will be able to grant this connection once a revision of the
deviceupdate-agent snap is submitted to the store. Once this happens, the snap will be assigned a ID that we use in specifying the rules for auto-connecting to it.
Thanks @dclane. We will publish a revised snap ASAP.
hey @eshashah-msft, let us know once you’re done with publishing the revised snap
Hi @0xnishit, we had published our snap. It was rejected due to autoconnect to snapd interface. I have started the human review process for the same: Manage version 0.1 of “deviceupdate-agent” (snapcraft.io)
Please let me know if anything is needed from our end.
I just saw this arrive in the store but noticed it failed automated review with an additional issue:
found errors in file output: unusual mode 'r-sr-xr-x' for entry './usr/lib/adu/adu-shell' security-snap-v2_squashfs_files
ie. it is shipping a setuid-root binary - these are generally not allowed since they could present a security issue - is this required? Could it be removed from the snap?
@alexmurray: Yes. We will remove and update the snap.
I can see the latest revision has some further issues, we left you some comments there. Let us know if you need further assistance.
Hey @eshashah-msft , it’s been a while since the last activity on this thread. Let us know if you need help with this. Thanks
Hey @eshashah-msft , since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks.
Hi @sahnaseredini, we have addressed the errors from the automated review and published the snap here. Can the delivery optimization interfac connect be enabled now?
2 votes for, 0 against. Granting
content interfaces from
deliveryoptimization-agent). This is now live
In addition to the above interfaces, I would like to request autoconnect to deviceupdate-agent-downloads plug interface in the Device Update snap
This enables download and storing update payloads by the Delivery Optimization Snap.
I’ve marked this topic as solved and copied the new request into a new topic.