Skip to content
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

Closed
physkets opened this issue Jan 28, 2019 · 28 comments
Closed

Snap packages #388

physkets opened this issue Jan 28, 2019 · 28 comments

Comments

@physkets
Copy link

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.

@dennwc
Copy link
Contributor

dennwc commented Feb 5, 2019

You may check the Snap version if you like. It's work-in-progress though.

@physkets
Copy link
Author

physkets commented Feb 7, 2019

Ah; I'm not on Ubuntu. But that is nice.

@dennwc
Copy link
Contributor

dennwc commented Feb 7, 2019

It should work on any distribution actually.

@tehnick
Copy link
Member

tehnick commented Feb 7, 2019

Have you guys considered making an AppImage or Flatpak package?

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.

It would be useful for users of linux distributions that do not have an official package.

Hmm, could you give examples of GNU/Linux distributions which do not have eiskaltdcpp packages?

@tehnick
Copy link
Member

tehnick commented Feb 7, 2019

You may check the Snap version if you like. It's work-in-progress though.

Please remind me when it will be ready for usage and I will add it to README.

@tehnick tehnick changed the title Alternative packaging AppImage images and Flatpak packages Feb 7, 2019
@physkets
Copy link
Author

physkets commented Feb 7, 2019

@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:
https://repology.org/metapackage/eiskaltdcpp/versions

@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.

@dennwc
Copy link
Contributor

dennwc commented Feb 7, 2019

@physkets Sorry, I'm not a Arch user, but it seems that Snap package is available on AUR.

@physkets
Copy link
Author

physkets commented Feb 7, 2019

@dennwc There is an eiskaltdcpp AUR package too. But the AUR is not a package repository; it is more of a collection of build-scripts tailored to Arch. So that is the same as building it myself.

@dennwc
Copy link
Contributor

dennwc commented Apr 15, 2019

I configured the automated build for Snap:
https://github.com/direct-connect/eiskaltdcpp-snap

Here is the package page with some stats as well:
https://snapcraft.io/eiskaltdcpp-dc

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.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Sorry for delay with reply.

I configured the automated build for Snap:
https://github.com/direct-connect/eiskaltdcpp-snap

Great!

Here is the package page with some stats as well:
https://snapcraft.io/eiskaltdcpp-dc

Hmm, why only amd64? How hard is to add support of more architectures?

Still, I have to manually click "build" from time to time,

I know nothing about snapcraft.io service and about ways of its integration with GitHub. Could you describe briefly describe it here?

because I have no permissions to setup webhooks for this repo.

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.

But if @tehnick is okay with me maintaining this file in the main repository, we can even get official nightly builds working.

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 snap/snapcraft.yaml the only one allowed path to this config or can it be placed to another place?

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

BTW, why the name of this snap is so strange?

name: eiskaltdcpp-dc

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Hmm, why only amd64? How hard is to add support of more architectures?

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.

Still, I have to manually click "build" from time to time,

I know nothing about snapcraft.io service and about ways of its integration with GitHub. Could you describe briefly describe it here?

I was wrong actually. Turned out Snapcraft automatically watches the github.com/eiskaltdcpp/eiskaltdcpp repository (since it's specified as a source in the script) and runs the build automatically.

This image is pushed to the edge channel and can be manually promoted to beta/candidate/stable.

So it works perfectly fine with a third-party repository, it seems.

Regarding the configuration, it's very simple - you need to commit snapcraft.yml, then authorize the repository on build.snapcraft.io and it will build everything automatically. Then the beta/candidate/stable version is ready, you can promote any revision from edge to it.

This is how the tracks panel looks like:

image

And it also provides some metrics to see the version distribution in the wild:

image

... just write me that should be added there.

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.

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?

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.

Is the path snap/snapcraft.yaml the only one allowed path to this config or can it be placed to another place?

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 command that builds everything.

BTW, why the name of this snap is so strange?

Snapcraft is partially curated, so you cannot just register a eiskaltdcpp package since the same one exists in Debian. By checking against Debian, they know which packages should be checked more carefully.

To register eiskaltdcpp name, it is necessary to fill the online form and specify who is the maintainer and some other details. I intentionally haven't made such request, because I'm not the maintainer, and cannot prove that I even have any significant contributions to the project.

So if it is accepted to the main repository, we may proceed and register the correct name.

Names with suffixes, like eiskaltdcpp-dc are allowed, so I use the -dc suffix for now.

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Forgot to mention, this actually means that eiskaltdcpp-dc snap already provides nightly builds right now :)

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Regarding the configuration, it's very simple - you need to commit snapcraft.yml, then authorize the repository on build.snapcraft.io and it will build everything automatically. Then the beta/candidate/stable version is ready, you can promote any revision from edge to it.

Ok, next question: are projects on snapcraft.io attached to specific website user or they may maintained by few users on equal basis?

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.

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.

So if it is accepted to the main repository, we may proceed and register the correct name.

I did not mean that this name in incorrect, but just was curious about it.

To register eiskaltdcpp name, it is necessary to fill the online form and specify who is the maintainer and some other details. I intentionally haven't made such request, because I'm not the maintainer, and cannot prove that I even have any significant contributions to the project.

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 eiskaltdcpp project for you and me if this is possible there.

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Ok, next question: are projects on snapcraft.io attached to specific website user or they may maintained by few users on equal basis?

Checked this, more than one user can administer a snap.

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.

Totally agree, let's transfer ownership. It will probably break the current build process though because access token will most likely expire.

I did not mean that this name in incorrect, but just was curious about it.

Sorry, not "incorrect", I meant something like "canonical" :)

Or I may register on that website and we will register eiskaltdcpp project for you and me if this is possible there.

Sounds like a plan :) Let me transfer the repository then. Should I transfer it to the org directly, or to your account first?

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Checked this, more than one user can administer a snap.

Great!

Or I may register on that website and we will register eiskaltdcpp project for you and me if this is possible there.

Sounds like a plan :) Let me transfer the repository then. Should I transfer it to the org directly, or to your account first?

Directly to eiskaltdcpp organization.

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Unable to transfer to org:

You don’t have the permission to create repositories on eiskaltdcpp

Transferred to your account instead.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Or I may register on that website

It emerged that this service uses Ubuntu One for developers authorization, so I am already registered there...

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Unable to transfer to org:

Hmm, do you think that transferring to other user will work? Lets try this.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

@dennwc

https://github.com/eiskaltdcpp/eiskaltdcpp-snap

It is done. I gave you admin level of access to this repo. Hope this will be enough.

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Thanks, will try to switch the build to the new repository.

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Was unable to do so. It doesn't show up in the list of available repositories for some reason.

Also, I cannot delete an old one from the list of builds.

@tehnick Can you please check if you see it in this list?

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

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.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Can you please check if you see it in this list?

Screenshot_20190424_190138

@dennwc
Copy link
Contributor

dennwc commented Apr 24, 2019

Awesome! Can you please configure it from your side? I can also contact you in Telegram to setup it quickly.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

Ok.

@tehnick
Copy link
Member

tehnick commented Apr 24, 2019

https://snapcraft.io/eiskaltdcpp is ready for usage.

@tehnick tehnick changed the title AppImage images and Flatpak packages Snap packages Apr 25, 2019
@tehnick
Copy link
Member

tehnick commented Apr 25, 2019

I have opened new task (#402) for AppImage images and Flatpak packages, because this issue is too flooded by discussion of Snap packaging.

@tehnick tehnick closed this as completed Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants