Arch Linux

rob-alexander

Member

Registered: 2015-10-16

Posts: 3

First PKGBUILD: mopidy-gmusic

Hey guys, just want some feedback before I submit to AUR for the first time. This is for a Google-Music plugin for Mopidy (an mpd (mostly) drop-in replacement).

# Maintainer: Rob Alexander <rob at robalexander dot me>

_pkgname=mopidy-gmusic
pkgname=$_pkgname-git
pkgver=r195.c84b62c
pkgrel=1
pkgdesc="Mopidy extension for playing music from Google Play Music"
arch=('any')
url="https://github.com/mopidy/mopidy-gmusic"
license=('APACHE')
depends=(
  'python2'
  'python2-requests>=2'
  'python2-pykka>=1.1'
#  'python2-gmusicapi>=6'
  'mopidy>=1.0'
)
makedepends=('python2-setuptools' 'git')
provides=($_pkgname)
conflicts=($_pkgname)
options=(!emptydirs)
source=("$_pkgname::git+https://github.com/mopidy/mopidy-gmusic.git")
md5sums=('SKIP')

pkgver() {
    cd "$srcdir/${_pkgname}"
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

build() {
    cd "$srcdir/${_pkgname}"

}

package() {
    cd "$srcdir/${_pkgname}"
    python2 setup.py install --root="$pkgdir" --optimize=1
    install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

# vim:set ts=2 sw=2 et:

I have the  'python2-gmusicapi>=6' line commented out as this is an AUR dependency. I assume I can just uncomment this before I submit? Is there a preferred way to test package installation with AUR deps? Also, is the LICENSE handled correctly?

Thanks for the help!

Last edited by rob-alexander (2015-10-16 13:59:54)

Scimmia

Fellow

Registered: 2012-09-01

Posts: 11,559

Re: First PKGBUILD: mopidy-gmusic

No reason to comment out AUR deps. As for the license, Apache is in the common licenses package, no need to install another copy.

The upstream git repo has tags, why aren't you using git describe in pkgver()?

No need for an empty build() function.

Pick one style of using variables and stick with it. Having some with braces and some without is bad styling (and a bit confusing).

Why do you have the version on most of the deps? Arch always assumes you have the latest release installed, so there's no need for versions unless you need an old version or something newer than the latest release.

rob-alexander

Member

Registered: 2015-10-16

Posts: 3

Re: First PKGBUILD: mopidy-gmusic

Thanks for the feedback!

Regarding the upstream tags, the latest one is for 0.3.0 (Jan 28, 2014) while his newest commit is 6 days ago. The tagged version doesn't work with the latest version of mopidy (crash) or python2-gmusicapi (login error).

# Maintainer: Rob Alexander <rob at robalexander dot me>

_pkgname=mopidy-gmusic
pkgname=${_pkgname}-git
pkgver=r195.c84b62c
pkgrel=1
pkgdesc="Mopidy extension for playing music from Google Play Music"
arch=('any')
url="https://github.com/mopidy/mopidy-gmusic"
license=('APACHE')
depends=(
  'python2'
  'python2-requests'
  'python2-pykka'
  'python2-gmusicapi'
  'mopidy'
)
makedepends=('python2-setuptools' 'git')
provides=(${_pkgname})
conflicts=(${_pkgname})
options=(!emptydirs)
source=("${_pkgname}::git+https://github.com/mopidy/mopidy-gmusic.git")
md5sums=('SKIP')

pkgver() {
    cd "${srcdir}/${_pkgname}"
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

package() {
    cd "${srcdir}/${_pkgname}"
    python2 setup.py install --root="${pkgdir}" --optimize=1
}

# vim:set ts=2 sw=2 et:

Also, when using makechrootpkg/makepkg, what's the best way to test packages that depend on AUR pkgs? It'll build, of course, if I comment out AUR dep. Or, what is the preferred way to test PKGBUILDs that rely on AUR pkgs in general?

progandy

Member

Registered: 2012-05-17

Posts: 5,193

Re: First PKGBUILD: mopidy-gmusic

No need for an empty build() function.

I think it is good practice to split the python setup in a build and an install step:

build() {
    cd "$srcdir/${_pkgname}"
    python2 setup.py build --optimize=1
}

package() {
    cd "$srcdir/${_pkgname}"
    python2 setup.py install --root="$pkgdir" --optimize=1
    install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

Regarding the upstream tags, the latest one is for 0.3.0 (Jan 28, 2014) while his newest commit is 6 days ago. The tagged version doesn't work with the latest version of mopidy (crash) or python2-gmusicapi (login error).

Still, use the tag to create the version. The result is then version+commits_since_tag+commitid

Also, when using makechrootpkg/makepkg, what's the best way to test packages that depend on AUR pkgs? It'll build, of course, if I comment out AUR dep. Or, what is the preferred way to test PKGBUILDs that rely on AUR pkgs in general?

Use a local repository where you add each successfully built package you need when you build in a clean chroot. If you use your (dirty) system, then simply install all AUR dependencies first. If you want you could use a local repository here, too.

Last edited by progandy (2015-10-16 14:38:03)

---

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

Scimmia

Fellow

Registered: 2012-09-01

Posts: 11,559

Re: First PKGBUILD: mopidy-gmusic

Regarding the upstream tags, the latest one is for 0.3.0 (Jan 28, 2014) while his newest commit is 6 days ago. The tagged version doesn't work with the latest version of mopidy (crash) or python2-gmusicapi (login error).

I'm not talking about building from the tag, just about using git describe so the tag is part of pkgver.

Also, when using makechrootpkg/makepkg, what's the best way to test packages that depend on AUR pkgs? It'll build, of course, if I comment out AUR dep. Or, what is the preferred way to test PKGBUILDs that rely on AUR pkgs in general?

With python packages, there's not really a good way to test any deps besides not having them installed and see what doesn't work. If you want to install it in a clean chroot, the simplest way is to use "-I <package>". That needs to be proceeded by "--" when calling some of the helper scripts like extra-x86_64-build, but I'm not sure if it does when calling makechrootpkg directly.

No need for an empty build() function.

I think it is good practice to split the python setup in a build and an install step:

That's true if it's building something. I didn't test this, but being an 'any' package, I figured it probably wasn't.

Last edited by Scimmia (2015-10-16 15:00:48)

rob-alexander

Member

Registered: 2015-10-16

Posts: 3

Re: First PKGBUILD: mopidy-gmusic

Thanks, schimma and progandy for the help!

I think it is good practice to split the python setup in a build and an install step:

Since we are compiling .pyc files for pacman to track, I agree with the logic, but setup.py build doesn't accept --optimize.

Still, use the tag to create the version. The result is then version+commits_since_tag+commitid

Ah, I understand now.

# Maintainer: Rob Alexander <rob at robalexander dot me>

_pkgname=mopidy-gmusic
pkgname=${_pkgname}-git
pkgver=r195.c84b62c
pkgrel=1
pkgdesc="Mopidy extension for playing music from Google Play Music"
arch=('any')
url="https://github.com/mopidy/mopidy-gmusic"
license=('APACHE')
depends=(
  'python2'
  'python2-requests'
  'python2-pykka'
  'python2-gmusicapi'
  'mopidy'
)
makedepends=('python2-setuptools' 'git')
provides=(${_pkgname})
conflicts=(${_pkgname})
options=(!emptydirs)
source=("${_pkgname}::git+https://github.com/mopidy/mopidy-gmusic.git")
md5sums=('SKIP')

pkgver() {
    cd "${srcdir}/${_pkgname}"
    git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

package() {
    cd "${srcdir}/${_pkgname}"
    python2 setup.py install --root="${pkgdir}" --optimize=1
}

# vim:set ts=2 sw=2 et:

progandy

Member

Registered: 2012-05-17

Posts: 5,193

Re: First PKGBUILD: mopidy-gmusic

Since we are compiling .pyc files for pacman to track, I agree with the logic, but setup.py build doesn't accept --optimize.

Right, I forgot. distutils is a bit inconsistent. You could use "build_py --compile --optimize 1". Still, if you only compile pyc files, the separation is not really necessary. The "compilation" is really fast.

Last edited by progandy (2015-10-16 17:46:32)

---

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