Re: [aur-general] PKGBUILD review request

2019-02-10 Thread Josef Miegl
Thanks for all the suggestions. I will update all my packages
accordingly :)

Josef Miegl


Re: [aur-general] PKGBUILD review request

2019-02-08 Thread Lone_Wolf



On 07-02-2019 23:13, Josef Miegl wrote:

I've been trying to improve my AUR packages for the last few days. I'm
still a beginner in package maintaining so I would like to have some
feedback on some of my PKGBUILDs. I would love to hear everything that
is wrong about them. Thanks!


# Maintainer: Josef Miegl 

pkgname=osmo-bsc-git
pkgver=1.4.0.15.g7cfdbe727
pkgrel=1
pkgdesc="Open Source BSC (GSM Base Station Controller) with A-bis/IP and A/IP 
interface"
url="https://osmocom.org/projects/osmobsc;
arch=('i686' 'x86_64' 'aarch64' 'armv7h')
license=(GPL)
depends=('libosmocore' 'libosmo-abis' 'libosmo-sccp' 'osmo-mgw')
makedepends=('git' 'talloc')
provides=("${pkgname%-git}")
conflicts=("${pkgname%-git}")
backup=('etc/osmocom/osmo-bsc.cfg')
source=("git+https://git.osmocom.org/${pkgname%-git};)
sha256sums=('SKIP')

pkgver() {
   cd "${srcdir}/${pkgname%-git}"
   echo $(git describe --always | sed 's/-/./g')
}

build() {
   cd "${srcdir}/${pkgname%-git}"
   autoreconf -i
   ./configure --prefix=/usr --sysconfdir=/etc
   make
}


On archlinux we usually need to add the -f / --force option to autoreconf.

Also autoreconf does change source files. That should be done in 
prepare() function, not build() .


LW


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

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


Re: [aur-general] PKGBUILD review request

2019-02-07 Thread Levente Polyak via aur-general
Hey ho, 


On February 7, 2019 11:13:34 PM GMT+01:00, Josef Miegl  wrote:
>I've been trying to improve my AUR packages for the last few days. I'm
>still a beginner in package maintaining so I would like to have some
>feedback on some of my PKGBUILDs. I would love to hear everything that
>is wrong about them. Thanks!
>
>pkgver() {
>  cd "${srcdir}/${pkgname%-git}"
>  echo $(git describe --always | sed 's/-/./g')
>}
>

Please do not use pkgver functions like that, they
don't work in vercmp as you would assume.
If upstream releases with a fix up version release
you gonna end up with a epoch bump. 

You could do something like described in the wiki

sed 's/\([^-]*-g\)/r\1/;s/-/./g' }

This prefixes the revision count like:
2.0.r6.ga17a017

Which behaves properly. 

https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function


Re: [aur-general] PKGBUILD review request

2019-02-07 Thread alad via aur-general
Am 07.02.2019 um 23:13 schrieb Josef Miegl:
> I've been trying to improve my AUR packages for the last few days. I'm
> still a beginner in package maintaining so I would like to have some
> feedback on some of my PKGBUILDs. I would love to hear everything that
> is wrong about them. Thanks!

You don't need "$srcdir" (the build starts there), nor for loops with
install (use -t /some/directory).

I didn't check if the upstream Makefile respects CFLAGS etc., but you might.

Otherwise looks fine to me. Doesn't look like beginners' work at all.

Alad

>
>
> # Maintainer: Josef Miegl 
>
> pkgname=osmo-bsc-git
> pkgver=1.4.0.15.g7cfdbe727
> pkgrel=1
> pkgdesc="Open Source BSC (GSM Base Station Controller) with A-bis/IP and A/IP 
> interface"
> url="https://osmocom.org/projects/osmobsc;
> arch=('i686' 'x86_64' 'aarch64' 'armv7h')
> license=(GPL)
> depends=('libosmocore' 'libosmo-abis' 'libosmo-sccp' 'osmo-mgw')
> makedepends=('git' 'talloc')
> provides=("${pkgname%-git}")
> conflicts=("${pkgname%-git}")
> backup=('etc/osmocom/osmo-bsc.cfg')
> source=("git+https://git.osmocom.org/${pkgname%-git};)
> sha256sums=('SKIP')
>
> pkgver() {
>   cd "${srcdir}/${pkgname%-git}"
>   echo $(git describe --always | sed 's/-/./g')
> }
>
> build() {
>   cd "${srcdir}/${pkgname%-git}"
>   autoreconf -i
>   ./configure --prefix=/usr --sysconfdir=/etc
>   make
> }
>
> package() {
>   cd "${srcdir}/${pkgname%-git}"
>   make DESTDIR=${pkgdir} install
> }
>
> # vim:set ts=2 sw=2 et:
>
>
>
>
> # Maintainer: Josef Miegl 
> # Contributor: goll 
> # Contributor: Kosava 
>
> pkgname=butt
> pkgver=0.1.17
> pkgrel=1
> pkgdesc="Easy to use, multi OS streaming tool"
> arch=('i686' 'x86_64' 'aarch64' 'armv7h')
> license=('GPL2')
> url="http://butt.sourceforge.net/;
> depends=('fltk' 'libpng12' 'portaudio' 'libfdk-aac' 'libvorbis' 'libogg' 
> 'lame' 'flac' 'opus' 'libsamplerate')
> source=(${pkgname}-${pkgver}.tar.gz::"http://sourceforge.net/projects/${pkgname}/files/${pkgname}/${pkgname}-${pkgver}/${pkgname}-${pkgver}.tar.gz;)
> sha256sums=('afe9596b1d9ef38d2fde1f3255e5a3a12b206c73c8e6601e37cccb07e67ae33d')
>
> build() {
>   cd "${srcdir}/${pkgname}-${pkgver}"
>   ./configure --prefix=/usr
>   make
> }
>
> package() {
>   cd "${srcdir}/${pkgname}-${pkgver}"
>   make DESTDIR="${pkgdir}" install
>
>   # Desktop file
>   install -Dm644 "usr/share/applications/${pkgname}.desktop" 
> "${pkgdir}/usr/share/applications/${pkgname}.desktop"
>
>   # Icons
>   for size in 16 22 24 32 48 64 96 128 256 512; do
> format="${size}x${size}"
> install -Dm644 "icons/icon_${format}.png" 
> "${pkgdir}/usr/share/icons/hicolor/${format}/apps/${pkgname}.png"
>   done
>
>   install -Dm644 "icons/icon_scalable.svg" 
> "${pkgdir}/usr/share/icons/hicolor/scalable/apps/${pkgname}.svg"
>
>   # Documentation
>   for doc in AUTHORS ChangeLog KNOWN_BUGS NEWS README THANKS; do
> install -Dm644 "${doc}" "${pkgdir}/usr/share/doc/${pkgname}/${doc}"
>   done
>
>   # Pixmaps
>   for file in usr/share/pixmaps/"${pkgname}"*; do
> filename=`basename "${file}"`
> install -Dm644 "${file}" "${pkgdir}/usr/share/pixmaps/${filename}"
>   done
> }
>
> # vim:set ts=2 sw=2 et:


[aur-general] PKGBUILD review request

2019-02-07 Thread Josef Miegl
I've been trying to improve my AUR packages for the last few days. I'm
still a beginner in package maintaining so I would like to have some
feedback on some of my PKGBUILDs. I would love to hear everything that
is wrong about them. Thanks!


# Maintainer: Josef Miegl 

pkgname=osmo-bsc-git
pkgver=1.4.0.15.g7cfdbe727
pkgrel=1
pkgdesc="Open Source BSC (GSM Base Station Controller) with A-bis/IP and A/IP 
interface"
url="https://osmocom.org/projects/osmobsc;
arch=('i686' 'x86_64' 'aarch64' 'armv7h')
license=(GPL)
depends=('libosmocore' 'libosmo-abis' 'libosmo-sccp' 'osmo-mgw')
makedepends=('git' 'talloc')
provides=("${pkgname%-git}")
conflicts=("${pkgname%-git}")
backup=('etc/osmocom/osmo-bsc.cfg')
source=("git+https://git.osmocom.org/${pkgname%-git};)
sha256sums=('SKIP')

pkgver() {
  cd "${srcdir}/${pkgname%-git}"
  echo $(git describe --always | sed 's/-/./g')
}

build() {
  cd "${srcdir}/${pkgname%-git}"
  autoreconf -i
  ./configure --prefix=/usr --sysconfdir=/etc
  make
}

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

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




# Maintainer: Josef Miegl 
# Contributor: goll 
# Contributor: Kosava 

pkgname=butt
pkgver=0.1.17
pkgrel=1
pkgdesc="Easy to use, multi OS streaming tool"
arch=('i686' 'x86_64' 'aarch64' 'armv7h')
license=('GPL2')
url="http://butt.sourceforge.net/;
depends=('fltk' 'libpng12' 'portaudio' 'libfdk-aac' 'libvorbis' 'libogg' 'lame' 
'flac' 'opus' 'libsamplerate')
source=(${pkgname}-${pkgver}.tar.gz::"http://sourceforge.net/projects/${pkgname}/files/${pkgname}/${pkgname}-${pkgver}/${pkgname}-${pkgver}.tar.gz;)
sha256sums=('afe9596b1d9ef38d2fde1f3255e5a3a12b206c73c8e6601e37cccb07e67ae33d')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr
  make
}

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

  # Desktop file
  install -Dm644 "usr/share/applications/${pkgname}.desktop" 
"${pkgdir}/usr/share/applications/${pkgname}.desktop"

  # Icons
  for size in 16 22 24 32 48 64 96 128 256 512; do
format="${size}x${size}"
install -Dm644 "icons/icon_${format}.png" 
"${pkgdir}/usr/share/icons/hicolor/${format}/apps/${pkgname}.png"
  done

  install -Dm644 "icons/icon_scalable.svg" 
"${pkgdir}/usr/share/icons/hicolor/scalable/apps/${pkgname}.svg"

  # Documentation
  for doc in AUTHORS ChangeLog KNOWN_BUGS NEWS README THANKS; do
install -Dm644 "${doc}" "${pkgdir}/usr/share/doc/${pkgname}/${doc}"
  done

  # Pixmaps
  for file in usr/share/pixmaps/"${pkgname}"*; do
filename=`basename "${file}"`
install -Dm644 "${file}" "${pkgdir}/usr/share/pixmaps/${filename}"
  done
}

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


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-08-15 Thread Frederik “Freso” S . Olesen
Den 31-07-2016 kl. 04:22 skrev Eli Schwartz via aur-general:
> *-hg/*-git/*-svn packages do not mean the source was checked out using
> those protocols, they mean that the package builds from the latest
> development sources and that therefore the PKGBUILD will automatically
> build e.g. the latest revision (or the latest revision of a particular
> development branch, depending on your scenario).
> 
> Unless you actually mean to indicate that that package fundamentally
> builds the development version from hg "tip", please use the version
> tarballs available at
> https://bitbucket.org/${user}/${repo}/get/${revision}.tar.gz
> 
> In this case, there do not appear to be tags, so just go with the latest
> commit hash. But still, it is false to claim that it is a development
> version.
> I don't know how you would go about calculating the actual pkgver
> though, if the repository doesn't seem to have tagged releases or proper
> versioning.

https://wiki.archlinux.org/index.php/VCS_package_guidelines#Mercurial
has a recommended way/example of how to go about exactly this. I don't
see a reason why this version string wouldn't be okay to use/mirror for
a non-"-hg" package too, if there's not otherwise a good versioning
scheme in place.

This would also allow package versions to be directly comparable if a
-hg package should emerge at a later point.

-- 
Namasté,
Frederik “Freso” S. Olesen 
AUR: https://aur.archlinux.org/account/Freso
Wiki: https://wiki.archlinux.org/index.php/User:Freso
-- 
Namasté,
Frederik “Freso” S. Olesen 
AUR: https://aur.archlinux.org/account/Freso
Wiki: https://wiki.archlinux.org/index.php/User:Freso



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-08-01 Thread Alessandro Menti
I forgot to remove the (now) useless build dependency on mercurial -
sorry for the spam.

Cheers,
Alessandro Menti

- The PKGBUILD follows: 
# Maintainer: Alessandro Menti 

pkgname=libdime
pkgver=r187
_commit=7cd55bc6a6d0
pkgrel=1
pkgdesc="A DXF (Data eXchange Format) file format support library"
arch=('i686' 'x86_64')
url="https://bitbucket.org/Coin3D/dime;
license=('BSD')
makedepends=('doxygen')
source=("${url}/get/${_commit}.tar.gz")
sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')

build() {
cd "$srcdir/Coin3D-dime-${_commit}"
./configure --prefix=/usr --enable-html
make
}

package() {
cd "$srcdir/Coin3D-dime-${_commit}"
make DESTDIR="$pkgdir/" install
install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-08-01 Thread Alessandro Menti
Hi Eli,
I've fixed all the issues you found, the revised PKGBUILD is below.

>> depends=('gcc-libs')
> 
> gcc-libs is part of the base group, and therefore all Arch Linux systems
> are expected to have it installed. I am not sure why there are any
> packages that (seemingly unnecessarily, except in the case of e.g. gcc
> which *needs* to depend on the same ${pkgver}-${pkgrel}) depend on it,
> but surely that isn't an excuse to further clutter up the pacman
> database with unneeded dependency chains...
I did add it at first because, otherwise, if namcap is run on the created
package, it complains about the missing dependency on gcc-libs:

> libdime E: Dependency gcc-libs detected and not included (libraries 
> ['usr/lib/libgcc_s.so.1', 'usr/lib/libstdc++.so.6'] needed in files 
> ['usr/lib/libdime.so.1.0.0'])

Thanks again for the review,
Alessandro Menti

- The PKGBUILD follows: 
# Maintainer: Alessandro Menti 

pkgname=libdime
pkgver=r187
_commit=7cd55bc6a6d0
pkgrel=1
pkgdesc="A DXF (Data eXchange Format) file format support library"
arch=('i686' 'x86_64')
url="https://bitbucket.org/Coin3D/dime;
license=('BSD')
makedepends=('doxygen' 'mercurial')
source=("${url}/get/${_commit}.tar.gz")
sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')

build() {
cd "$srcdir/Coin3D-dime-${_commit}"
./configure --prefix=/usr --enable-html
make
}

package() {
cd "$srcdir/Coin3D-dime-${_commit}"
make DESTDIR="$pkgdir/" install
install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-07-31 Thread Eli Schwartz via aur-general
On 07/31/2016 02:52 AM, Alessandro Menti wrote:
> Hi Eli,
> thanks for the review.
> [...]
> which suggests the tarball originally released by the authors was a
> nightly release (incidentally, r187 corresponds to the current hg "tip").
> 
> Regarding the pkgver, I think using the ISO 8601 "reversed date" might be
> acceptable in this particular case.

It would be, but personally I prefer revision number, so I would use
"r187" myself. This tells the user how much has changed, rather than
when it changed (maybe more relevant in the context of
${tag}.r${revisions}.${_commit} as output by `git describe` for things
likely to get more commits, but I still like it regardless).

> I've attached the revised PKGBUILD below - let me know if you have any
> further observations.

I do have a couple last style nits.

> - The PKGBUILD follows: 
> # Maintainer: Alessandro Menti 
> pkgname=libdime

Most people put a line of whitespace separating the "# Maintainer:" line
from the main body of the PKGBUILD. In a similar way to separating the
variables from the pkgver/prepare/build/check/package functions (and the
functions from each other).

> pkgver=20111205

As I said above, by personal preference I would use "r187".

> depends=('gcc-libs')

gcc-libs is part of the base group, and therefore all Arch Linux systems
are expected to have it installed. I am not sure why there are any
packages that (seemingly unnecessarily, except in the case of e.g. gcc
which *needs* to depend on the same ${pkgver}-${pkgrel}) depend on it,
but surely that isn't an excuse to further clutter up the pacman
database with unneeded dependency chains...

> source=("https://bitbucket.org/Coin3D/dime/get/${_commit}.tar.gz;)

I usually reuse the ${url} variable here if possible, but that isn't
really terribly important. I think it looks nicer though, because it
highlights the relationship between the homepage and the source code
download location.

-- 
Eli Schwartz


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-07-31 Thread Alessandro Menti
Hi Eli,
thanks for the review.

> Unless you actually mean to indicate that that package fundamentally
> builds the development version from hg "tip", please use the version
> tarballs available at
> https://bitbucket.org/${user}/${repo}/get/${revision}.tar.gz
> 
> In this case, there do not appear to be tags, so just go with the latest
> commit hash. But still, it is false to claim that it is a development
> version.
> I don't know how you would go about calculating the actual pkgver
> though, if the repository doesn't seem to have tagged releases or proper
> versioning.
That's exactly the problem - there are neither tags nor proper
versioning. The only hint I've found is in the Debian copyright file [1]:

> Source:
>  hg clone https://bitbucket.org/Coin3D/dime
>  The upstream package source tarball was generated by:
>  hg archive -r 187 -p dime-0.20111205 ../../dime_0.20111205.orig.tar.bz2
> Comment:
>  first Debian packages by A. Maitland Bottoms  on
>  Fri, 11 Jan 2002 14:27:21 -0500.
>  first downloaded from ftp://ftp.sim.no/pub/snapshots/

which suggests the tarball originally released by the authors was a
nightly release (incidentally, r187 corresponds to the current hg "tip").

Regarding the pkgver, I think using the ISO 8601 "reversed date" might be
acceptable in this particular case.

I've attached the revised PKGBUILD below - let me know if you have any
further observations.

Thanks again,
Alessandro Menti

[1] 
http://metadata.ftp-master.debian.org/changelogs/main/d/dime/dime_0.20111205-2_copyright

- The PKGBUILD follows: 
# Maintainer: Alessandro Menti 
pkgname=libdime
pkgver=20111205
_commit=7cd55bc6a6d0
pkgrel=1
pkgdesc="A DXF (Data eXchange Format) file format support library"
arch=('i686' 'x86_64')
url="https://bitbucket.org/Coin3D/dime;
license=('BSD')
depends=('gcc-libs')
makedepends=('doxygen' 'mercurial')
source=("https://bitbucket.org/Coin3D/dime/get/${_commit}.tar.gz;)
sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')

build() {
cd "$srcdir/Coin3D-dime-${_commit}"
./configure --prefix=/usr --enable-html
make
}

package() {
cd "$srcdir/Coin3D-dime-${_commit}"
make DESTDIR="$pkgdir/" install
install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}


Re: [aur-general] PKGBUILD review request: libdime-hg

2016-07-30 Thread Eli Schwartz via aur-general
On 07/30/2016 11:56 AM, Alessandro Menti wrote:
> Hi everyone,
> I've just started writing some PKGBUILDs for some programs that are not
> present neither in the official package repository nor in the AUR.
> Specifically, I've packaged libdime [1] as a required dependency for the
> X-Plane developer tools [2].
> 
> I'm attaching the PKGBUILD below - if someone on this list could review
> it, that would be much appreciated. I've also got the following questions:
> 1) Is it correct to name the package "libdime-hg" only because its
>sources are checked out from a Mercurial repository (that's because
>no official tarballs exist any more - the Debian copyright file for
>the library [3] points to a now dismissed FTP site [4]), or should I
>just name it "libdime"?
> 2) On the same note, assuming that naming the package "libdime-hg" is
>correct, does it make sense to put
>provides=("${pkgname%-hg}")
>conflicts=("${pkgname%-hg}")
>in the PKGBUILD? I've thought to put these two lines as "safeguards"
>in case I need to distinguish between a libdime VCS and non-VCS package
>in the future.
> 
> Cheers and thanks in advance,
> Alessandro Menti

*-hg/*-git/*-svn packages do not mean the source was checked out using
those protocols, they mean that the package builds from the latest
development sources and that therefore the PKGBUILD will automatically
build e.g. the latest revision (or the latest revision of a particular
development branch, depending on your scenario).

Unless you actually mean to indicate that that package fundamentally
builds the development version from hg "tip", please use the version
tarballs available at
https://bitbucket.org/${user}/${repo}/get/${revision}.tar.gz

In this case, there do not appear to be tags, so just go with the latest
commit hash. But still, it is false to claim that it is a development
version.
I don't know how you would go about calculating the actual pkgver
though, if the repository doesn't seem to have tagged releases or proper
versioning.

-- 
Eli Schwartz


[aur-general] PKGBUILD review request: libdime-hg

2016-07-30 Thread Alessandro Menti
Hi everyone,
I've just started writing some PKGBUILDs for some programs that are not
present neither in the official package repository nor in the AUR.
Specifically, I've packaged libdime [1] as a required dependency for the
X-Plane developer tools [2].

I'm attaching the PKGBUILD below - if someone on this list could review
it, that would be much appreciated. I've also got the following questions:
1) Is it correct to name the package "libdime-hg" only because its
   sources are checked out from a Mercurial repository (that's because
   no official tarballs exist any more - the Debian copyright file for
   the library [3] points to a now dismissed FTP site [4]), or should I
   just name it "libdime"?
2) On the same note, assuming that naming the package "libdime-hg" is
   correct, does it make sense to put
   provides=("${pkgname%-hg}")
   conflicts=("${pkgname%-hg}")
   in the PKGBUILD? I've thought to put these two lines as "safeguards"
   in case I need to distinguish between a libdime VCS and non-VCS package
   in the future.

Cheers and thanks in advance,
Alessandro Menti

[1] https://bitbucket.org/Coin3D/dime
[2] http://developer.x-plane.com/tools/
[3] 
http://metadata.ftp-master.debian.org/changelogs/main/d/dime/dime_0.20111205-2_copyright
[4] ftp://ftp.sim.no/pub/snapshots/

- The PKGBUILD follows: 
# Maintainer: Alessandro Menti 
pkgname=libdime-hg
pkgver=r187.7cd55bc6a6d0
pkgrel=1
pkgdesc="A DXF (Data eXchange Format) file format support library"
arch=('i686' 'x86_64')
url="https://bitbucket.org/Coin3D/dime;
license=('BSD')
depends=('gcc-libs')
makedepends=('doxygen' 'mercurial')
provides=("${pkgname%-hg}")
conflicts=("${pkgname%-hg}")
source=("${pkgname%-hg}::hg+https://bitbucket.org/Coin3D/dime;)
sha256sums=('SKIP')

pkgver() {
cd "$srcdir/${pkgname%-hg}"
printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
}

build() {
cd "$srcdir/${pkgname%-hg}"
./configure --prefix=/usr --enable-html
make
}

package() {
cd "$srcdir/${pkgname%-hg}"
make DESTDIR="$pkgdir/" install
install -D -m644 COPYING 
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}


Re: [aur-general] PKGBUILD Review Request: syncevolution

2016-06-26 Thread hojat mombeini
thanks for your response

__
Persian web-based mail | MihanMail.Com


Re: [aur-general] PKGBUILD Review Request: syncevolution

2016-06-26 Thread Justus Piater
Thanks for the suggestions.  I implemented all but the -m755 as that's
the default anyway. If there are no more comments I'll upload to AUR.

Justus


# Maintainer: Justus Piater 
pkgname=('syncevolution' 'syncevolution-http')
pkgver=1.5.1
pkgrel=1
pkgdesc="Synchronize PIM data via various protocols"
arch=('i686' 'x86_64')
url="https://syncevolution.org/;
license=('LGPL')
depends=('evolution-data-server' 'neon' 'openobex' 'python2' 'libunique')
makedepends=('intltool' 'boost')
#changelog=
source=("https://download.01.org/syncevolution/syncevolution/sources/$pkgname-$pkgver.tar.gz;
"$pkgname-$pkgver-casts.patch"
"$pkgname-$pkgver-libical2.patch"
"$pkgname-$pkgver-python2.patch")
sha256sums=('39f52049006c4a703bfe4b7cea3bb3298fe61b4ba9a8dbc367492409e4091c70'
'c72fcc0f06d7958fbef98ffd379ebc95407d7bd29924e6ba63507ba7f82fcac6'
'e12fd70af74b2771c6a83a6f42cfd64a943e9e5d3db93624865b08476d4b8f2c'
'3ccb195d45de1c1ad87f76dfc5927997988afa7031feb9f335fab63d6a317910')

prepare() {
cd "$pkgname-$pkgver"
for patch in casts libical2 python2; do
  patch -p1 -i "$srcdir/$pkgname-$pkgver-$patch.patch"
done
}

build() {
cd "$pkgname-$pkgver"
export CXXFLAGS="$CXXFLAGS -std=gnu++98"
./configure --prefix=/usr\
--libexecdir=/usr/lib/syncevolution  \
--sysconfdir=/etc\
--enable-bluetooth   \
--enable-core\
--enable-dbus-service\
--enable-notify  \
--enable-notify-compatibility\
--enable-gui \
--enable-pbap\
--enable-dav
make
}

package_syncevolution() {
cd "$pkgbase-$pkgver"
make DESTDIR="$pkgdir/" install
rm -df "$pkgdir/usr/bin/syncevo-http-server" \
   "$pkgdir/usr/lib/syncevolution/test"
}

package_syncevolution-http() {
pkgdesc="Synchronize PIM data via various protocols (HTTP server)"
arch=('any')
depends=('syncevolution'
 'python2-dbus'
 'python2-twisted'
 'python2-gobject2'
 'python2-pyopenssl'
 'python2-service-identity')
#changelog=

/usr/bin/install -D "$pkgbase-$pkgver/test/syncevo-http-server.py" \
"$pkgdir/usr/bin/syncevo-http-server"
}


Re: [aur-general] PKGBUILD Review Request: syncevolution

2016-06-25 Thread Doug Newgard
On Sat, 25 Jun 2016 11:25:02 -0500
Doug Newgard  wrote:

> On Sat, 25 Jun 2016 08:46:05 +0200
> justus-...@piater.name wrote:
> 
> > I scratched an itch and would now like feedback on my first PKGBUILD. I
> > enabled the features I need (which are all basic), plus all those that
> > did not pull in too many additional dependencies and compiled without
> > fuss. I split out syncevo-http-server because it depends on many Python
> > packages, and many users won't need it.
> > 
> > The patch (not included) replaces python by python2, fixes two minor
> > compilation issues, and applies a hack to get it to work with libical2.
> > (Upstream is aware.)  
> 
> Sounds like it should be at least 3 separate patches.
> 
> > 
> > (There are obsolete syncevolution packages in the AUR Archive, but I
> > decided to start from scratch.)
> > 
> > Thanks,
> > Justus
> > 
> > 
> > 
> > # Maintainer: Justus Piater 
> > pkgname=('syncevolution' 'syncevolution-http')
> > pkgver=1.5.1
> > pkgrel=1
> > pkgdesc="Synchronize PIM data via various protocols"
> > arch=('i686' 'x86_64')
> > url="https://syncevolution.org/;
> > license=('LGPL')
> > depends=('evolution-data-server' 'neon' 'openobex' 'python2' 'libunique')
> > makedepends=('intltool' 'boost')
> > #changelog=
> > source=("https://download.01.org/syncevolution/syncevolution/sources/$pkgname-$pkgver.tar.gz;
> > "$pkgname-$pkgver.patch")
> > sha256sums=('39f52049006c4a703bfe4b7cea3bb3298fe61b4ba9a8dbc367492409e4091c70'
> > 
> > 'e8592cff59bc0ebc9bb2b35b63840d4207bb8bc321f244294122a40910b6aeb2')
> > 
> > prepare() {
> > cd "$pkgname-$pkgver"
> > patch -p1 -i "$srcdir/$pkgname-$pkgver.patch"
> > }
> > 
> > build() {
> > cd "$pkgname-$pkgver"
> > ./configure --prefix=/usr --libexecdir=/usr/lib/syncevolution 
> > --sysconfdir=/etc CXXFLAGS=-std=gnu++98 --enable-bluetooth --enable-core 
> > --enable-dbus-service --enable-notify --enable-notify-compatibility 
> > --enable-gui --enable-pbap --enable-dav  
> 
> The guidelines ask to limit lines to somewhere around 100 characters. Not
> required, but considered good form.

Another thing I noticed here, you don't want to completely override CXXFLAGS.
You should add the option to what is already set. I also wouldn't intermix that
in with the configure options.

> 
> > make
> > }
> > 
> > package_syncevolution() {
> > cd "$pkgbase-$pkgver"
> > make DESTDIR="$pkgdir/" install
> > rm -f $pkgdir/usr/bin/syncevo-http-server
> > rmdir $pkgdir/usr/lib/syncevolution/test  
> 
> Missing some quotes here. You don't know if $pkgdir contains a space or not.
> You could also combine these two into one command.
> 
> > }
> > 
> > package_syncevolution-http() {
> > pkgdesc="Synchronize PIM data via various protocols (HTTP server)"
> > arch=('any')
> > depends=('syncevolution'
> >  'python2-dbus'
> >  'python2-twisted'
> >  'python2-gobject2'
> >  'python2-pyopenssl'
> >  'python2-service-identity')
> > #changelog=
> > 
> > cd "$pkgbase-$pkgver"
> > mkdir -p $pkgdir/usr/bin
> > /usr/bin/install -c test/syncevo-http-server.py 
> > $pkgdir/usr/bin/syncevo-http-server  
> 
> More missing quotes. Not sure why you're specifying the full path for install,
> and you could use the -D switch to create the dir, so the preceding mkdir 
> isn't
> necessary. The -c switch does nothing. I'm assuming you want this to be
> executable, so adding -m755 would be a good idea as well.
> 
> > }  


Re: [aur-general] PKGBUILD Review Request: syncevolution

2016-06-25 Thread Doug Newgard
On Sat, 25 Jun 2016 08:46:05 +0200
justus-...@piater.name wrote:

> I scratched an itch and would now like feedback on my first PKGBUILD. I
> enabled the features I need (which are all basic), plus all those that
> did not pull in too many additional dependencies and compiled without
> fuss. I split out syncevo-http-server because it depends on many Python
> packages, and many users won't need it.
> 
> The patch (not included) replaces python by python2, fixes two minor
> compilation issues, and applies a hack to get it to work with libical2.
> (Upstream is aware.)

Sounds like it should be at least 3 separate patches.

> 
> (There are obsolete syncevolution packages in the AUR Archive, but I
> decided to start from scratch.)
> 
> Thanks,
> Justus
> 
> 
> 
> # Maintainer: Justus Piater 
> pkgname=('syncevolution' 'syncevolution-http')
> pkgver=1.5.1
> pkgrel=1
> pkgdesc="Synchronize PIM data via various protocols"
> arch=('i686' 'x86_64')
> url="https://syncevolution.org/;
> license=('LGPL')
> depends=('evolution-data-server' 'neon' 'openobex' 'python2' 'libunique')
> makedepends=('intltool' 'boost')
> #changelog=
> source=("https://download.01.org/syncevolution/syncevolution/sources/$pkgname-$pkgver.tar.gz;
> "$pkgname-$pkgver.patch")
> sha256sums=('39f52049006c4a703bfe4b7cea3bb3298fe61b4ba9a8dbc367492409e4091c70'
> 
> 'e8592cff59bc0ebc9bb2b35b63840d4207bb8bc321f244294122a40910b6aeb2')
> 
> prepare() {
> cd "$pkgname-$pkgver"
> patch -p1 -i "$srcdir/$pkgname-$pkgver.patch"
> }
> 
> build() {
> cd "$pkgname-$pkgver"
> ./configure --prefix=/usr --libexecdir=/usr/lib/syncevolution 
> --sysconfdir=/etc CXXFLAGS=-std=gnu++98 --enable-bluetooth --enable-core 
> --enable-dbus-service --enable-notify --enable-notify-compatibility 
> --enable-gui --enable-pbap --enable-dav

The guidelines ask to limit lines to somewhere around 100 characters. Not
required, but considered good form.

> make
> }
> 
> package_syncevolution() {
> cd "$pkgbase-$pkgver"
> make DESTDIR="$pkgdir/" install
> rm -f $pkgdir/usr/bin/syncevo-http-server
> rmdir $pkgdir/usr/lib/syncevolution/test

Missing some quotes here. You don't know if $pkgdir contains a space or not.
You could also combine these two into one command.

> }
> 
> package_syncevolution-http() {
> pkgdesc="Synchronize PIM data via various protocols (HTTP server)"
> arch=('any')
> depends=('syncevolution'
>'python2-dbus'
>'python2-twisted'
>'python2-gobject2'
>'python2-pyopenssl'
>'python2-service-identity')
> #changelog=
> 
> cd "$pkgbase-$pkgver"
> mkdir -p $pkgdir/usr/bin
> /usr/bin/install -c test/syncevo-http-server.py 
> $pkgdir/usr/bin/syncevo-http-server

More missing quotes. Not sure why you're specifying the full path for install,
and you could use the -D switch to create the dir, so the preceding mkdir isn't
necessary. The -c switch does nothing. I'm assuming you want this to be
executable, so adding -m755 would be a good idea as well.

> }


[aur-general] PKGBUILD Review Request: syncevolution

2016-06-25 Thread Justus-dev
I scratched an itch and would now like feedback on my first PKGBUILD. I
enabled the features I need (which are all basic), plus all those that
did not pull in too many additional dependencies and compiled without
fuss. I split out syncevo-http-server because it depends on many Python
packages, and many users won't need it.

The patch (not included) replaces python by python2, fixes two minor
compilation issues, and applies a hack to get it to work with libical2.
(Upstream is aware.)

(There are obsolete syncevolution packages in the AUR Archive, but I
decided to start from scratch.)

Thanks,
Justus



# Maintainer: Justus Piater 
pkgname=('syncevolution' 'syncevolution-http')
pkgver=1.5.1
pkgrel=1
pkgdesc="Synchronize PIM data via various protocols"
arch=('i686' 'x86_64')
url="https://syncevolution.org/;
license=('LGPL')
depends=('evolution-data-server' 'neon' 'openobex' 'python2' 'libunique')
makedepends=('intltool' 'boost')
#changelog=
source=("https://download.01.org/syncevolution/syncevolution/sources/$pkgname-$pkgver.tar.gz;
"$pkgname-$pkgver.patch")
sha256sums=('39f52049006c4a703bfe4b7cea3bb3298fe61b4ba9a8dbc367492409e4091c70'
'e8592cff59bc0ebc9bb2b35b63840d4207bb8bc321f244294122a40910b6aeb2')

prepare() {
cd "$pkgname-$pkgver"
patch -p1 -i "$srcdir/$pkgname-$pkgver.patch"
}

build() {
cd "$pkgname-$pkgver"
./configure --prefix=/usr --libexecdir=/usr/lib/syncevolution 
--sysconfdir=/etc CXXFLAGS=-std=gnu++98 --enable-bluetooth --enable-core 
--enable-dbus-service --enable-notify --enable-notify-compatibility 
--enable-gui --enable-pbap --enable-dav
make
}

package_syncevolution() {
cd "$pkgbase-$pkgver"
make DESTDIR="$pkgdir/" install
rm -f $pkgdir/usr/bin/syncevo-http-server
rmdir $pkgdir/usr/lib/syncevolution/test
}

package_syncevolution-http() {
pkgdesc="Synchronize PIM data via various protocols (HTTP server)"
arch=('any')
depends=('syncevolution'
 'python2-dbus'
 'python2-twisted'
 'python2-gobject2'
 'python2-pyopenssl'
 'python2-service-identity')
#changelog=

cd "$pkgbase-$pkgver"
mkdir -p $pkgdir/usr/bin
/usr/bin/install -c test/syncevo-http-server.py 
$pkgdir/usr/bin/syncevo-http-server
}


Re: [aur-general] PKGBUILD review request: understand-bin

2016-06-14 Thread Justin Dray
You can specify a general source array as well as architecture specific
ones, it adds them together. So you should put desktop and the /usr/bin
binary file in there instead of repeating it.

Otherwise it looks good to me now.

Regards,
Justin


[aur-general] PKGBUILD review request: understand-bin

2016-06-13 Thread Alex Sarum via aur-general
Hello,

This is my first PKGBUILD. If someone has time, I would like to get some reviews
from other archers.

https://gitlab.com/saruman9/pkgbuilds/tree/master/understand-bin

--
Alex


[aur-general] PKGBUILD review request

2014-01-10 Thread Douglas Christman
Hello,

This is my first attempt at creating a package so I'd appreciate any
feedback you have.
The PKGBUILD is avilable here:
https://raw.github.com/dobyrch/termboy-go/master/PKGBUILD

Thanks!


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Jason St. John
On Fri, Jan 10, 2014 at 6:59 PM, Douglas Christman
douglaschrist...@gmail.com wrote:
 Hello,

 This is my first attempt at creating a package so I'd appreciate any
 feedback you have.
 The PKGBUILD is avilable here:
 https://raw.github.com/dobyrch/termboy-go/master/PKGBUILD

 Thanks!

Hello,

You should quote the link in the source array and any string that
includes a Bash variable (e.g. use `install -Dm 755
$pkgname-go-$pkgver $pkgdir/usr/bin/$pkgname-go`).

You can remove the dependency on 'bash' because you shouldn't include
dependency information for any packages in the groups 'base' or
'base-devel'.

Unless this package will _only_ work for 64-bit systems, you should
change the arch array to the following:
arch=('i686' 'x86_64')

And this is a minor issue, but you should change the GitHub links to
use https:// so the source download will _always_ use HTTPS, even if
the http - https redirect that GitHub uses stops working for whatever
reason.

Jason


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Evgeniy Alekseev
Hi!

On Friday 10 January 2014 18:59:35 Douglas Christman wrote:
 This is my first attempt at creating a package so I'd appreciate any
 feedback you have.
 The PKGBUILD is avilable here:
 https://raw.github.com/dobyrch/termboy-go/master/PKGBUILD

--- it was written by Jason ---
1. It is highly recommended using double quotes for paths (to avoid problems 
with paths with spaces, for example).
2. What about i686 architecture? If it is supported it must be added to arch 
list.
3. Dependency 'bash' could be removed because it is in base group and several 
packages in base-devel group depend on it [1, see Warning message].
--- it was written by Jason ---

4. It has several errors during build (could not find packages 
github.com/dobyrch/*). I think you must fix it in the upstream =)

[1]. https://wiki.archlinux.org/index.php/AUR#Prerequisites
-- 
С уважением, Е.Алексеев.
Sincerely yours, E.Alekseev.

e-mail: darkarca...@mail.ru
ICQ: 407-398-235
Jabber: arca...@jabber.ru

signature.asc
Description: This is a digitally signed message part.


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Isaac Dupree

On 01/10/2014 07:32 PM, Jason St. John wrote:

Unless this package will _only_ work for 64-bit systems, you should
change the arch array to the following:
 arch=('i686' 'x86_64')


Should the documentation be updated?  [1] describes arch as An array 
of architectures that the PKGBUILD file is known to build and work on. 
 That description implies to me that if you haven't tested it on i686 
then you shouldn't list i686.  However, the actual AUR convention is, as 
you say, to include i686 and x86_64 unless you know it's nonportable.


[1] https://wiki.archlinux.org/index.php/PKGBUILD#arch


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Anatol Pomozov
Hi

On Fri, Jan 10, 2014 at 4:32 PM, Jason St. John jstj...@purdue.edu wrote:
 You should quote the link in the source array and any string that
 includes a Bash variable (e.g. use `install -Dm 755
 $pkgname-go-$pkgver $pkgdir/usr/bin/$pkgname-go`).

Could you please please explain it? Why bash variables need quotes?

Well, $srcdir/$destdir need double-quotes because they might contain
spaces (although creating dirs with white-spaces on UNIX is a dumb
idea). What about other variables like $pkgver? The same question
applied to other parts of PKGBUILD - why quotes are needed for
dependencies, license, arch, sources...?


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Sam Stuewe

On 2014-01-10 19:10, Anatol Pomozov wrote:

Well, $srcdir/$destdir need double-quotes because they might contain
spaces (although creating dirs with white-spaces on UNIX is a dumb
idea). What about other variables like $pkgver? The same question
applied to other parts of PKGBUILD - why quotes are needed for
dependencies, license, arch, sources...?


It's not actually required if you know that the variable won't expand 
incorrectly. However, it is good practice to do so. And, using 
double-quotes will ensure proper expansion. I tend to be incredibly 
verbose about this and even include braces for variables:


${pkgname}-${pkgver}.tar.gz

It looks cleanest to me this way, and I know that it will always expand 
the way I want it to. This is, however, a matter of style more than 
anything else.


--
All the best,
Sam Stuewe (HalosGhost)


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Evgeniy Alekseev
On Friday 10 January 2014 20:35:45 Douglas Christman wrote:
 It looks like GOPATH needed to be set for it to build correctly.  Would you
 mind testing out the changes I made to see if it fixes the problem?
 
 https://raw.github.com/dobyrch/termboy-go/master/PKGBUILD
 
 On Fri, Jan 10, 2014 at 7:36 PM, Evgeniy Alekseev 
 darkarca...@mail.ruwrote:
  4. It has several errors during build (could not find packages
  github.com/dobyrch/*). I think you must fix it in the upstream =)

Yes, now it builds normally. But anyway I think that patching of source files 
in the upstream (or creating a patch that does this in the prepare() function) 
will be better way than moving of sources to the correct path. But as you 
wish. And it is recommended using a patching/moving/etc in the prepare() 
function not build() or package().
BTW instead src/github.com/dobyrch will be better to use $srcdir variable 
(e.g. $srcdir/github.com/dobyrch).
-- 
С уважением, Е.Алексеев.
Sincerely yours, E.Alekseev.

e-mail: darkarca...@mail.ru
ICQ: 407-398-235
Jabber: arca...@jabber.ru

signature.asc
Description: This is a digitally signed message part.


Re: [aur-general] PKGBUILD review request

2014-01-10 Thread Jeremy Audet
I created a pull request on GitHub. See:
https://github.com/dobyrch/termboy-go/pull/1

--Jeremy


[aur-general] PKGBUILD review request

2012-04-30 Thread Bernhard D
Hi,

I wrote a PKGBUILD for the driver package from TBS (www.tbsdtv.com) for
their dvb cards. I split packaging for modules and firmware and patched
the sources to install the modules to /lib/modules/kernelversion/updates
and the firmware to /lib/firmware/updates to avoid overwriting existing
files. It's the first time I'm building kernel modules and there are
two things I'm not sure about:
- Are the files under /lib/firmware/updates found and do they have
precedence?
- Is depmod -a after install, upgrade and removal the right approach
to rebuild the module dependencies?

Regards,
Bernhard





Re: [aur-general] PKGBUILD review request

2012-04-30 Thread Bernhard D
I attached the file I got from makepkg --source to my first message,
but it seems that it had been dropped. Are attachements allowed?

Regards,
Bernhard


Am Montag, den 30.04.2012, 11:27 +0200 schrieb Bernhard D:
 Hi,
 
 I wrote a PKGBUILD for the driver package from TBS (www.tbsdtv.com) for
 their dvb cards. I split packaging for modules and firmware and patched
 the sources to install the modules to /lib/modules/kernelversion/updates
 and the firmware to /lib/firmware/updates to avoid overwriting existing
 files. It's the first time I'm building kernel modules and there are
 two things I'm not sure about:
 - Are the files under /lib/firmware/updates found and do they have
 precedence?
 - Is depmod -a after install, upgrade and removal the right approach
 to rebuild the module dependencies?
 
 Regards,
 Bernhard
 
 
 




Re: [aur-general] PKGBUILD review request

2012-04-30 Thread Jesse Juhani Jaara
ma, 2012-04-30 kello 14:40 +0200, Bernhard D kirjoitti:
 I attached the file I got from makepkg --source to my first message,
 but it seems that it had been dropped. Are attachments allowed?
No attachments are removed. Paste the PKGBUILD and .install file to some
pastebin service. (Don't use pastebin.com!) Also Please do not top post,
write your answer under the original message.

 I split packaging for modules and firmware and patched
 the sources to install the modules to /lib/modules/kernelversion/updates
That is a wring directory. Out-of-tree modules go to
/lib/modules/extramodules-$KERNEL_VERSION

 Are the files under /lib/firmware/updates found and do they have
 precedence?
I am not completely sure about this but, I am quite positive that it
doesn't matter in what directory the file is, as long it is in the
firmware directory. I myself would use /lib/firmware/tbs/ directory.

  - Is depmod -a after install, upgrade and removal the right approach
  to rebuild the module dependencies?
post_install()
post_upgrade()
and post_remove()
are needed as far as I understand
See the install file for vhba-module as reference
https://projects.archlinux.org/svntogit/community.git/tree/trunk/vhba-module.install?h=packages/vhba-module


signature.asc
Description: This is a digitally signed message part


Re: [aur-general] PKGBUILD review request

2012-04-30 Thread Dave Reisner
On Mon, Apr 30, 2012 at 11:27:54AM +0200, Bernhard D wrote:
 Hi,
 
 I wrote a PKGBUILD for the driver package from TBS (www.tbsdtv.com) for
 their dvb cards. I split packaging for modules and firmware and patched

No, please don't make this a split package. You need them both at the
same time, there's no reason to make a split package with a single file
in each.

 the sources to install the modules to /lib/modules/kernelversion/updates

This is wrong. updates/ are for... updates. It's admin territory for
overriding existing (in tree) kernel modules with backports and whatnot.

 and the firmware to /lib/firmware/updates to avoid overwriting existing
 files. It's the first time I'm building kernel modules and there are
 two things I'm not sure about:
 - Are the files under /lib/firmware/updates found and do they have
 precedence?

Yes they have precedence, but for the same reason as above you should
not be installing things here. Additionally, you must adhere to the path
that the module dictates for its firmware. radeon, for example, expects
firmware under radeon/. You can see exactly what it expects with
modinfo, e.g.

  $ modinfo -k 3.3.4-1-ARCH -F firmware radeon | sed 3q
  radeon/R520_cp.bin
  radeon/RS600_cp.bin
  radeon/RS690_cp.bin

So in this case, firmware is looked for in each of these base paths (in
order):

  /usr/lib/firmware/updates/$(uname -r)
  /usr/lib/firmware/updates/
  /lib/firmware/updates/$(uname -r)
  /lib/firmware/updates
  /usr/lib/firmware/$(uname -r)
  /usr/lib/firmware
  /lib/firmware/$(uname -r)
  /lib/firmware

The search stops as soon as udev finds a match.

 - Is depmod -a after install, upgrade and removal the right approach
 to rebuild the module dependencies?

No, this is overkill. You should know exactly what kernel you're
building against so only run depmod for that one kernel.

d


Re: [aur-general] PKGBUILD review request

2012-04-30 Thread Bernhard D
Am Montag, den 30.04.2012, 16:00 +0300 schrieb Jesse Juhani Jaara:
 ma, 2012-04-30 kello 14:40 +0200, Bernhard D kirjoitti:
  I attached the file I got from makepkg --source to my first message,
  but it seems that it had been dropped. Are attachments allowed?
 No attachments are removed. Paste the PKGBUILD and .install file to some
 pastebin service. (Don't use pastebin.com!) Also Please do not top post,
 write your answer under the original message.
 
  I split packaging for modules and firmware and patched
  the sources to install the modules to /lib/modules/kernelversion/updates
 That is a wring directory. Out-of-tree modules go to
 /lib/modules/extramodules-$KERNEL_VERSION
 
  Are the files under /lib/firmware/updates found and do they have
  precedence?
 I am not completely sure about this but, I am quite positive that it
 doesn't matter in what directory the file is, as long it is in the
 firmware directory. I myself would use /lib/firmware/tbs/ directory.
 
   - Is depmod -a after install, upgrade and removal the right approach
   to rebuild the module dependencies?
 post_install()
 post_upgrade()
 and post_remove()
 are needed as far as I understand
 See the install file for vhba-module as reference
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/vhba-module.install?h=packages/vhba-module

Thanks for your help. I have corrected the build process according to
your suggestions. The files can be found at:
https://gist.github.com/2558499

Regards,
Bernhard




Re: [aur-general] PKGBUILD review request

2012-04-30 Thread Jesse Juhani Jaara
ma, 2012-04-30 kello 15:55 +0200, Bernhard D kirjoitti:
 Tanks for your help. I have corrected the build process according to
 your suggestions. The files can be found at:
 https://gist.github.com/2558499
Looking the PKGBUILD I would propose changing that horrible to read case
clutter to few ifs like this. Out kernel's are all at version 3 so no
need for the 2.6 version eather:

 if [ $_dvbtype = c ]; then 
if [ $CARCH = i686 ]; then
  ./v4l/tbs-dvbc-x86_r3.sh
else
  ./v4l/tbs-dvbc-x86_64.sh
fi

  elif [ $_dvbtype = s2 ]; then
if [ $CARCH = i686 ];then
  ./v4l/tbs-x86_r3.sh
else
  ./v4l/tbs-x86_64.sh
fi
  fi

Also lookin  ath the make files and stuff reveal the horrifyingness and
idiotism of this drivers packager/writer. The whole linux v4l is
included in the tarball and build by default, not to mention that it is
installed too. Owerwriting our webcam and video capture card driver
stack from some random version of kernel it totally out of order. So
instead of doing make install, copy only the tbs drivers by hand from
there. Even better hack and slash the make files to not even build all
those 5 gazillion other drivers.


signature.asc
Description: This is a digitally signed message part