-
Notifications
You must be signed in to change notification settings - Fork 36
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
Make release tarballs more user-friendly/useful #312
Comments
This would be nice. I recently tried to build it on KDE and installing the dependencies was a bit of a hassle. I did have to install clang (or would gcc have worked?) which is not listed in the dependencies/install instructions. I don't know how this would affect distro/repo packagers, though, if they have their own build scripts and are expecting the release as it currently is (although I guess a dual-release would work in that situation?). Might be more of a question for them. |
@ochosi I made an issue about supporting HiDPI (#317). The solution requires moving to an SVG-installed theme which might change how to go about doing the Github action and releases. Either the PNG step would need to be optional or it could be eliminated completely. Not sure if that's the direction you all would like to go in, but in case it is I wanted to put it out there just in case it changed things here. |
In theory we could attach a source and a read-for-use tarball. Adding better hidpi support is definitely something I'd look forward to (even though I don't even have the hardware to test this myself), but let's discuss that in the other issue. |
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: build the tarball and keep the archive accessible in the associated GitHub Action.
On a pull request: build the tarball and add a comment to the PR with a link to the resource. On push to master: run the standard symlink check.
Currently our release tarballs are not very helpful. Downloading them is the same as checking out the git repository in a certain state.
What would be nice if a GitHub action (triggered on each new tag) would generate a useable tarball, i.e. one in which
make
has already run. I imagine that everything would already be in the right directory structure, ideally even with icon-caches pre-generated so that a user can simply download and untar the archive to their local icon theme directory.@newhoa thoughts?
The text was updated successfully, but these errors were encountered: