Hey Snapcraft Community, after learning from the upside down experience with Thonny DBUS Request today i would like to request dbus access and thus the manual review for snap transmission-community, here is the screenshot of snappy debug validating my claim and necessity --:
Hey @alexmurray can you please take out time to review this, i also need to conduct tests to pass it to stable and yes there are more snap projects in line so please consider to review this ASAP, Thanks.
Hey @roadmr @jamesh if you are there please take out time to review this, i need to do further testing of the snap, waiting for a whole day just for dbus access is really not motivating for someone wishing to contribute to snap development etc. , please review this as soon as possible. I think Alex is busy currently, so i request you to please do the review, thanks
I granted the original name you requested last week - but it looks like you updated it to use a different dbus name since then - I have been on leave the last couple days but I have now just granted this one as well.
1 Like
is there reason why i still get --> âââFailed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection â:1.122â is not allowed to own the service"com.transmissionbt.transmission_2051_7733555" due to AppArmor policyâââ
hey @alexmurray i have registered with a new dbus name so as to prevent the error, please review it as per convenience
The issue is that now the snap seems to be generating a random dbus name - instead it should use a fixed name like com.transmissionbt.transmission or similar.
Hey there the latest revision is having --> com.transmissionbt.Transmission, will it work ??
Why do you keep changing the dbus name this snap is using? It has now been granted 3 separate names - and you now want a fourth one - as such I have gone and revoked the other 3 - please settle on a single name, then we can grant this to your snap.
the others wont work, this one is the same as upstream and maybe the solution as i told the snap wont work with the old dbus id
if possible suggest me something thats assured to workâŚ
the dbus ids that i gave earlier wont work, i beleive the fourth one should work, if possible you yourself suggest a dbus name that will work, i just want the snap to work and the dbus id i am implementing wont work reason i have mentioned earlierâŚ
Hi Sam,
There was some discussion in another thread that youâd benefit greatly from being able to build snaps locally; as I recall, youâd have some issues with the local build process which is why youâre making use of the Snapcraft Build Service.
Iâm wondering, seeing as youâre already employing Github; whether using Github Actions to build your snap might be more appropriate instead.
The significant majority of stuff that requires snap-declarations from the store/reviewers, can still be tested without them, through using snap alias for aliases, snap connect for slots, etc. Thereâs very few situations packagers will run into where they cannot test permissions locally without a declaration.
The main friction right now seems to be the store itself rejecting your builds and then the time taken for someone to authorise the release. Would it make sense instead then, to build on Github, download the .snap from the Github build, and then test it locally with the --dangerous flag? That way you can skip the store-request until you know youâve got the right definitions.
Itâs easy to do too, youâd just add a file in your Github repo, e.g
.github/workflows/build.yaml
name: Build snap
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: snapcore/action-build@v1
id: build
- uses: actions/upload-artifact@v3
with:
name: my.snap
path: ${{ steps.build.outputs.snap}}
And thatâs that; everytime you push a commit or propose a PR, youâd get a snap file you can access via the Github UI, download, and install locally with sudo snap install my.snap --dangerous. This then skips the review process letting you test locally. Once it works locally, you could submit a request when trying to push to the store knowing it would be appropriate in advance.
It feels to me this would really increase your development rate, and lower the burden on the review team at the same time; whilst keeping the builds remote. (Github actions are entirely free on public repoâs, and thereâs a generous free tier for private repoâs too!).
1 Like
Thanks for the info, this itself is the problem when i use my snap builds from launchpad in dangerous mode it works absolutely fine with my dbus ids but when i try it to use from edge channel in confined way, it always spits error saying apparmor policy restricts owning the dbus id etc. , so i need some specification about whats wrong and why does the snap dont use my dbus id, this is not a problem when running unconfined, it works well, and also push my atril snap atleast as its working fine and i have implemented the dbus id as suggested by your side, i will surely check out your suggestion, but my problem is not what you are mentioning
The exact problem with this snap with regards to this thread is that itâs generating a random DBus name each run. The solution to make the sandbox happy is to make it not generate a random DBus name and instead pick a consistent name that matches the slot. Achieving this is the difficult part, and the answer may end up being that you need to patch the source code so that it picks a static name consistently.
Thereâs nothing that can be done on the store side to make the snap pick a consistent name. The sandbox limits the names you can use, but it doesnât play a part in deciding the names that are used, thatâs entirely on the program itself.
But, between this snap and the other snaps youâve tried recently, I do feel that going the Github Actions route will benefit you hugely in being able to test changes quicker and without someone having to manually allow it everytime.
Thanks for the info please look into my other snap waiting for review, i will try to implement the flatpak transmission patch here
Any tips or idea you can give for the patch, the flatpak builds too use some patches regarding dbus but implementing it in snap i will need some help, so any suggestions ?? Here is there patch, -->
store reviewers are not really equipped to advise on such issues - I am reassigning this to the snap category where you should be able to get more help. Once the snap is working locally, then we can look at granting the appropriate dbus rule within the store.
Hey @alexmurray , first of all i understand that you have a lot of obligations, so cutting short i want you to give dbus access to the latest revision under process with the dbus id : com.transmissionbt.transmission, as @James-Carroll suggested i used github actions to build a snap locally and after downloading the zip from github installed it with snap install tc.snap --dangerous, renamed the downloaded file to tc and suprisingly it worked absolutely fine with the dbus id: com.transmissionbt.transmission, so please check this again, i seeked support from transmission community too, they referred me to some related issues --> https://github.com/transmission/transmission/issues/5237 , so as asked by both of you i did try to run locally and it worked, so please check it as per convenience
This is now done (ie I granted the use of com.transmissionbt.transmission)