-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snap packages #388
Comments
You may check the Snap version if you like. It's work-in-progress though. |
Ah; I'm not on Ubuntu. But that is nice. |
It should work on any distribution actually. |
Personally I do not nor time, nor interest in maintaining of such builds. If anyone will be able able to maintain such packages in long-term basis we may upload them to SF or add related link to README.
Hmm, could you give examples of GNU/Linux distributions which do not have eiskaltdcpp packages? |
Please remind me when it will be ready for usage and I will add it to README. |
@tehnick I'm using Archlinux, and it doesn't officially package it. The following is a nice resource to track who packages it and who doesn't: @dennwc Yes, I technically can, but I'll first have to build the whole snap environment also, because Arch does not have that either. The Flatpak framework exists in it's official repos, and I have used AppImages, so those work too. |
I configured the automated build for Snap: Here is the package page with some stats as well: Still, I have to manually click "build" from time to time, because I have no permissions to setup webhooks for this repo. But if @tehnick is okay with me maintaining this file in the main repository, we can even get official nightly builds working. |
Sorry for delay with reply.
Great!
Hmm, why only amd64? How hard is to add support of more architectures?
I know nothing about snapcraft.io service and about ways of its integration with GitHub. Could you describe briefly describe it here?
Even if I'll give you developer access to this git repo you will not be able to setup webhooks because only repository owner can do such changes in repository settings. So just write me that should be added there. My contact information (email, jid, telegram) may be found via my GitHub profile.
Ok, lets clear this... Is storing of snap configuration files in main repo is more preferable/convenient than in a separate repo (like https://github.com/eiskaltdcpp/eiskaltdcpp-snap)? Why? Is the path |
BTW, why the name of this snap is so strange? name: eiskaltdcpp-dc |
It should not be hard, but I haven't tested it yet. It can also build for ARM, but again, haven't tested it yet.
I was wrong actually. Turned out Snapcraft automatically watches the This image is pushed to the So it works perfectly fine with a third-party repository, it seems. Regarding the configuration, it's very simple - you need to commit This is how the tracks panel looks like: And it also provides some metrics to see the version distribution in the wild:
Seems like everything works as-is right now, so I guess no action is needed. Unless we can pull the snapcraft config to the main repo, that is.
The only reason to do so is that I users will be able to clone the official repository, make some changes, build snap locally and test it. With a third-party repository, I have to clone both and change source paths in snapcraft config.
It's a default path, but I'm sure there is an option to override this on build. With a default path, it works as a single
Snapcraft is partially curated, so you cannot just register a To register So if it is accepted to the main repository, we may proceed and register the correct name. Names with suffixes, like |
Forgot to mention, this actually means that |
Ok, next question: are projects on
The chances that regular users will update the snap are near zero. From other side I prefer to keep scripts for GNU/Linux packages with eiskaltdcpp out of main repo. (As well as developers of GNU/Linux distros and *BSD systems BTW.) And I do not see enough reasons to make exception for snap, flatpak and AppImage yet. But how about moving of git repo https://github.com/direct-connect/eiskaltdcpp-snap to https://github.com/eiskaltdcpp/eiskaltdcpp-snap? This way it will become more visible for users and potential contributors. And I'll give you write access to this repo of course.
I did not mean that this name in incorrect, but just was curious about it.
Ok, I see. Now you may use the link to this issue as a proof. =) Or I may register on that website and we will register |
Checked this, more than one user can administer a snap.
Totally agree, let's transfer ownership. It will probably break the current build process though because access token will most likely expire.
Sorry, not "incorrect", I meant something like "canonical" :)
Sounds like a plan :) Let me transfer the repository then. Should I transfer it to the org directly, or to your account first? |
Great!
Directly to |
Unable to transfer to org:
Transferred to your account instead. |
It emerged that this service uses Ubuntu One for developers authorization, so I am already registered there... |
Hmm, do you think that transferring to other user will work? Lets try this. |
It is done. I gave you admin level of access to this repo. Hope this will be enough. |
Thanks, will try to switch the build to the new repository. |
Caused by canonical-web-and-design/build.snapcraft.io#1176. We can probably remove the old repository and make a new one with a correct name instead. Should be faster than waiting for them to fix Launchpad issue. |
Awesome! Can you please configure it from your side? I can also contact you in Telegram to setup it quickly. |
Ok. |
https://snapcraft.io/eiskaltdcpp is ready for usage. |
I have opened new task (#402) for AppImage images and Flatpak packages, because this issue is too flooded by discussion of Snap packaging. |
Have you guys considered making an AppImage or Flatpak package? It would be useful for users of linux distributions that do not have an official package.
The text was updated successfully, but these errors were encountered: