Package Details: aseprite-git v1.1.7.r29.gf97dc79-6

Git Clone URL: https://aur.archlinux.org/aseprite-git.git (read-only)
Package Base: aseprite-git
Description: Create animated sprites and pixel art
Upstream URL: http://www.aseprite.org/
Licenses: custom
Conflicts: aseprite, aseprite-gpl
Submitter: benob
Maintainer: benob
Last Packager: benob
Votes: 4
Popularity: 0.028312
First Submitted: 2012-10-10 08:10
Last Updated: 2016-09-12 17:05

Latest Comments

benob commented on 2016-09-12 17:05

Should be fixed in v6 of PKGBUILD

koushien commented on 2016-09-12 06:52

Makepkg aborts after the following error:
##
install: cannot create regular file /usr/share/licenses/aseprite/EULA.txt: Permission denied
##
Anything I should try?

benob commented on 2016-09-02 12:03

The new license [1] says:
- "You may not distribute copies of the SOFTWARE PRODUCT to third parties. Evaluation versions available for download from David Capello's websites may be freely distributed."
- "You may only compile and modify the source code of the SOFTWARE PRODUCT for your own personal purpose or to propose a contribution to the SOFTWARE PRODUCT."

SOFTWARE PRODUCT is defined as
"software product(s) identified above which may include associated software components, media, printed materials, and "online" or electronic documentation"

So, I am not a lawyer but I think that SOFTWARE PRODUCT does not include the source code (hence the name "source code of the SOFTWARE PRODUCT"), so the distribution restriction does not apply. In addition, when you use a PKGBUILD to compile software, you still compile the software yourself, so technically, distributing the PKGBUILD does not violate the compilation clause.

I will change the license in the PKGBUILD and I could force the user to accept it during compilation, but I am quite confident that we can continue to use the upstream code.
I have also created a PKGBUILD for the GPL version of the project called aseprite-gpl which ships version 1.7.1.

Anyone has lawyer connections who could shed light on the issue?

[1] https://raw.githubusercontent.com/aseprite/aseprite/master/EULA.txt

bobpaul commented on 2016-09-01 21:46

Project is no longer GPL. There's a GPL fork here: https://github.com/aseprite-gpl/aseprite

The new license allows individuals to compile their own copies, but would probably require a fetch restriction in the AUR (ie, don't provide a URL in the PKGBUILD and make the user download the archive manually.) I think if PKGBUILD downloads the files, that might violate the distribution requirements in the EULA.

benob commented on 2016-08-15 16:17

setting MAKEFLAGS in /etc/makepkg.cfg doesn't do the trick?

flurick commented on 2016-08-15 16:01

How about "make -j $(getconf _NPROCESSORS_ONLN)", it should speed up the building a bit for those machines with multiple CPU cores.

Viomi commented on 2016-02-29 14:21

PKGBUILD now works fine, thank you.

Keep up the good work @benob

Still waiting on decap to fix https://github.com/aseprite/aseprite/issues/971 but that should be done today. :)

benob commented on 2016-02-29 13:57

Could you try from scratch with the latest PKGBUILD? I synched it with the non-git pathway.

Viomi commented on 2016-02-29 12:44

I added "git submodule update --init --recursive" into the PKGBUILD, which got past the previous error.

However, one of these submodules it now successfully pulls fails to build. It throws this error:

CMake Error at third_party/freetype2/CMakeLists.txt:123 (message):


In-source builds are not permitted! Make a separate folder for building,
e.g.,

mkdir build; cd build; cmake ..

Before that, remove the files created by this failed run with

rm -rf CMakeCache.txt CMakeFiles


-- Configuring incomplete, errors occurred!

I tried making a third_party/freetype2/builds folder and moving the lists and stuff there, but nothing really seemed to work. I don't really know enough about cmake to do this correctly.

alloyed commented on 2015-12-08 19:51

Build currently fails: it uses submodules for dependency management that don't get pulled in.
To fix just stick a `git submodule update --init` in there, or however else Arch recommends you handle it.

All comments