You are not logged in.

#1 2019-07-19 05:32:09

JeanLucJ
Member
Registered: 2019-03-08
Posts: 30

[REQUEST] xpuz

Hello,

I made a package for xpuz, a nice puzzle game that is not ported in Arch.
I intend to publish it to AUR.

I checked https://wiki.archlinux.org/index.php/Ar … guidelines and related articles, the package compiles and installs, the game runs fine, I used a arch chroot to check deps...
Could you please confirm that there is nothing wrong ? It's my first package so I prefer to double check...

PKGBUILD :

# Maintainer: Jean-Luc Juganniere <jljug@hotmail.com>
pkgname=xpuz-arch
_pkgname=xpuz-arch
pkgver=2.5
pkgrel=1
pkgdesc="This is a is a fork of xjig 2.5, the jigsaw puzzle."
arch=('x86_64')
url=" https://sourceforge.net/projects/xpuz/"
license=('GPL')
makedepends=('git' 'libx11' 'libjpeg-turbo')
depends=('libx11' 'libjpeg-turbo')
source=("$pkgname::git+https://github.com/JeanLucJFr/$_pkgname.git")
md5sums=(SKIP)

build() {
	cd "$srcdir/$pkgname"
	make
}

package() {
	cd "$srcdir/$pkgname"
	make DESTDIR="$pkgdir/" install
}

Regards

Offline

#2 2019-07-19 10:42:05

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 7,135

Re: [REQUEST] xpuz

On xjigsaw site there's a link to a source download for xpuz 2.6.5 .
That suggests xpuz development may have gone somewhere else then sourceforge.
Maybe xjigsaw devs can help you to make contact with xpuz developers.


license=('GPL')

Looks like that is incorrect , Check https://wiki.archlinux.org/index.php/PKGBUILD#license


Multi-init booting with apg Openrc and systemd coexisting
Automounting : not needed, i prefer pmount
Aur helpers : makepkg + my own local repo === rarely need them

Offline

#3 2019-07-19 10:59:44

progandy
Member
Registered: 2012-05-17
Posts: 3,459

Re: [REQUEST] xpuz

You use a git repository without a fixed tag, so either change that or add -git to the package name and a pkgver function.

By the way, it would be cleaner to import the original source in one commit and then commit your changes afterwards. If you don't have any, then use the original source when possible.

Last edited by progandy (2019-07-19 11:05:02)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#4 2019-07-19 13:30:43

JeanLucJ
Member
Registered: 2019-03-08
Posts: 30

Re: [REQUEST] xpuz

Thx for the feedback.

I did not change the code, but I did the makefile from scratch because :
- It was not working out of the box, the link to library were broken
- It is shipping with an Imakefile to compile under various environnements, which make the compile process cumbersome
- The remade makefile is very simple smile

I have two questions :
- Should the tag fit the current xpuz version, or should it be anything (like 1.0) ?
- The licence is GPL3. Is that what you mean? I'm not expert to making a difference between GPL and GPL V3, but checking licences, there is actually this difference

I'll try to get in touch with the devs, but the last version dates from 2014, and the diff between 2.5 and 2.6 is trivial, so I'm pretty sure it's not living anymore. I never had a crash in its current state, so I don't think it's a problem.

Offline

#5 2019-07-19 13:39:24

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 21,899
Website

Re: [REQUEST] xpuz

Packages in depends should not also be in makedepends as the latter is for packages that are only needed during the build process.  All depends are installed before the build.

The package description has a typo/copy-paste error.  It also is a bit verbose: it doesn't need to be a full sentence.  "This is a" is not needed.  The current description could easily be shortened to "a fork of xjig 2.5, the jigsaw puzzle."

The license issue is that "GPL" implies GPL 2 or later, if the license is actually GPL3 then this is incorrect and the license field should specify GPL3.

There is no need for "-arch" in the package name.  You are packaging it for arch linux, that's a given.  The package is just xpuz - and if you use git as a source it should be xpuz-git as noted above.

Last edited by Trilby (2019-07-19 13:40:47)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2019-07-19 13:51:20

ayekat
Member
Registered: 2011-01-17
Posts: 1,342
Website

Re: [REQUEST] xpuz

JeanLucJ wrote:

I'll try to get in touch with the devs, but the last version dates from 2014, and the diff between 2.5 and 2.6 is trivial, so I'm pretty sure it's not living anymore. I never had a crash in its current state, so I don't think it's a problem.

But then why not simply package 2.6.3 instead of an older version?

I did not change the code, but I did the makefile from scratch because :
- It was not working out of the box, the link to library were broken
- It is shipping with an Imakefile to compile under various environnements, which make the compile process cumbersome
- The remade makefile is very simple

It would be more transparent if that Makefile was provided alongside the PKGBUILD, so that users can see the difference, and then you point to the original sources.

- Should the tag fit the current xpuz version, or should it be anything (like 1.0) ?

If you fetch the sources from your personal git repository (which currently doesn't have any versioned release), don't just set a random version number for the package. See https://wiki.archlinux.org/index.php/VC … guidelines for more information about packages built from the latest commit in a git repository.

Then again, as mentioned before, it's probably better to use the original sources, and so you'd end up setting a correct version number.

Alternatively, if you want to stay with your own fork, I'd change at least the URL accordingly. Otherwise it's just misleading, since you make the user believe they're using one version of xpuz, while they're really using another one.


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#7 2019-07-19 14:03:38

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 21,899
Website

Re: [REQUEST] xpuz

ayekat wrote:

It would be more transparent if that Makefile was provided alongside the PKGBUILD, so that users can see the difference, and then you point to the original sources.

Agreed.  Also note that your replacement Makefile could be simplified.  Your explicitly write out several rules that are just duplicates of implicit rules.  Let make use it's defaults wherever appropriate and only override where necessary.  Also append to or conditionally set variables that may be inherited from the environment otherwise you'll override the user's makepkg.conf settings.  Lastly, LDFLAGS != LDLIBS.  Here is a simpler and corrected makefile:

PREFIX  ?= /usr
LDLIBS   = -lX11 -ljpeg -lm
SRC      = $(wildcard *.cpp)
LINK.o   = $(LINK.cc)

xpuz : $(SRC:.cpp=.o)

clean :
	@rm -rf *.o

install :
	install -Dm755 xpuz $(DESTDIR)$(PREFIX)/bin/xpuz
	install -Dm755 xpuz.6.gz $(DESTDIR)$(PREFIX)/man/man6/xpuz.6.gz

Strictly speaking, the 'clean' directive is also not needed as it would never be used in the makepkg process.

Last edited by Trilby (2019-07-19 14:04:50)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2019-07-21 12:54:00

JeanLucJ
Member
Registered: 2019-03-08
Posts: 30

Re: [REQUEST] xpuz

Trilby wrote:
ayekat wrote:

It would be more transparent if that Makefile was provided alongside the PKGBUILD, so that users can see the difference, and then you point to the original sources.

Agreed.

What would be the best way to do that?
Unless I'm mistaken, in an AUR repository, you can provide PKGBUILD, .SRCINFO, and maybe a patch file (I saw no definite and clear instruction in the wiki about that).
I can make a patch that removes around 200 lines of original Makefile and replace them with 15 lines, although it seems to me to be streching the idea of a patch to the extreme... or I can provide only a Makefile in my own Github, and modify the PKGBUILD to point to the original source. Is that what you mean?

I saw before a suggestion to commit the original source code, then commit a new Makefile, but I don't think it's what you mean.

Thanks for all the answers anyway!

Last edited by JeanLucJ (2019-07-21 12:55:04)

Offline

#9 2019-07-21 13:09:00

ayekat
Member
Registered: 2011-01-17
Posts: 1,342
Website

Re: [REQUEST] xpuz

JeanLucJ wrote:

Unless I'm mistaken, in an AUR repository, you can provide PKGBUILD, .SRCINFO, and maybe a patch file (I saw no definite and clear instruction in the wiki about that).

No, there are no limitations. T there are some limitations (there may be some git post-transaction hooks on the AUR that perform some sanity checks), but it's not uncommon for packagers to provide additional files like systemd/tmpfiles.d/sysusers.d files or pacman hooks or default configuration (ugh) or anything else that might be required to integrate some software into the system, for either runtime or buildtime (such as in your case a Makefile). See the files for systemd, for an example.

--edit: fixed, thanks for pointing out, progandy

Last edited by ayekat (2019-07-21 13:49:05)


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#10 2019-07-21 13:38:35

progandy
Member
Registered: 2012-05-17
Posts: 3,459

Re: [REQUEST] xpuz

ayekat wrote:
JeanLucJ wrote:

Unless I'm mistaken, in an AUR repository, you can provide PKGBUILD, .SRCINFO, and maybe a patch file (I saw no definite and clear instruction in the wiki about that).

No, there are no limitations.

There are a few hardcoded limitations. The repository must not contain subdirectories and files (blobs) must nod exceed 250kB..
https://git.archlinux.org/aurweb.git/co … 941b5d29ee

@JeanLucJ: It is frowned upon to inlude the complete source code and such packages might be deleted when they are discovered. There is no problem with a few patches or build instructions (the Makefile only contains build instructions), though.

Last edited by progandy (2019-07-21 13:42:26)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#11 2019-07-24 14:28:17

JeanLucJ
Member
Registered: 2019-03-08
Posts: 30

Re: [REQUEST] xpuz

Thx all.
I took all your advices, and just pushed xpuz.

Btw, it's quite enjoyable, it turns any image into a puzzle with many custom options (number of pieces, double sided or not).
Great to spend time while waiting smile

Regards,

Offline

Board footer

Powered by FluxBB