Re: [aur-general] PKGBUILD review request
Thanks for all the suggestions. I will update all my packages accordingly :) Josef Miegl
Re: [aur-general] PKGBUILD review request
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
On 2/7/19 5:38 PM, Levente Polyak via aur-general wrote:
> 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
I would like to add to this, that in addition, there is no need to use:
echo $(git describe ... | sed ...)
since it is literally the same thing as not using the echo and simply using:
git describe ... | sed ...
Except not using the echo is
a) faster
b) as a general scripting practice, advisable due to not reparsing the
string, thus introducing modification of whitespace. If you're going to
use echo $() then at least quote the "$()". Failure to quote the $()
means that echo treats each whitespace-separated string as a separate
argument to echo, even if they are separated by multiple spaces, or
tabs. Of course, for PKGBUILDs, whitespace is forbidden in pkgver() output.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] PKGBUILD review request
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
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
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
> The reason I'm using the RPM package is because the source doesn't> build and
> I don't have the skills to pull apart the cmake files to
> figure out why.
Then you should consider either backtracking from this task or learn.
You _have_ to understand how the underlying buildsystem works to be able
to correctly adopt the package for AUR.
First and foremost, get familiar with CMake on a basic level.
Second, look through project's set()s and option()s. By the time step
one is completed, you will have understood, why. They'll point you at
required changes that have to be done against the default configuration.
Third, use official repository or AUR packages to provide dependencies.
Not bundled ones.
Good luck.
On 19.10.2017 16:34, Garrett Battaglia via aur-general wrote:
> On Wed, Oct 18, 2017 at 10:18 PM, Eli Schwartz
> wrote:
>> On 10/18/2017 06:13 PM, Garrett Battaglia via aur-general wrote:
>>> This is the first time I am packaging for the AUR I would like someone
>>> to look over my PKGBUILD below.
>>>
>>> Thanks,
>>> Garrett
>>>
>>> #Maintainer: Garrett Battaglia
>>> pkgname=sysdig-falco
>>> pkgver=0.8.1
>>> _sysdigver=0.19.1
>>> pkgrel=1
>>> pkgdesc="Behavioral Activity Monitoring With Container Support"
>>> arch=('x86_64')
>>
>> Why x86_64 only? It is available for both, even the prebuilt binaries.
>>
>>> url=https://github.com/draios/falco
>>> license=('GPL')
>>> depends=('dkms')
>>> makedepends=('git' 'cmake' 'linux-headers')
>>> provides=('sysdig-falco')
>>>
>>> source=(
>>> "http://download.draios.com/stable/rpm/${arch}/falco-${pkgver}-${arch}.rpm";
>>> "https://github.com/draios/falco/archive/${pkgver}.tar.gz";
>>> "https://github.com/draios/sysdig/archive/${_sysdigver}.tar.gz";
>>> "sysdig-falco.install"
>>> "sysdig-falco.service")
>>>
>>> install=$pkgname.install
>>
>> You haven't shown us the install file or the service file. install files
>> are not supposed to be listed in source=()
>>
>> More than that, files named eg. 0.8.1.tar.gz should be renamed, by
>> listing the source as e.g.
>> "${pkgname}-${pkgver}.tar.gz::http://github.com/draios/falco/archive/${pkgver}.tar.gz";
>>
>> Why on earth are you downloading an rpm for a package that has source
>> code available in git?
>>
>> If for some reason you desperately have to, DO NOT use ${arch} in the
>> filename, it doesn't do what you think it does and only worked through
>> sheer accident. That gets you the first array element of arch=() which
>> only works as intended when there is ONLY one element and is not
>> documented for use, it also breaks sane handling of multi-arch sources. Use:
>> source_i686=("http://download.draios.com/stable/rpm/i386/falco-${pkgver}-i686.rpm";)
>> source_x86_64=("http://download.draios.com/stable/rpm/x86_64/falco-${pkgver}-x86_64.rpm";)
>>
>>> md5sums=(
>>> '5e017c747184101a0cc93ffc5b19ca47'
>>> 'f3c654ded00f3186f3ff92320204a747'
>>> '6ad8b4a7d1b0aa10cd62397318117a67'
>>> '8bdb4c61dadd116f4901fa15c20da728'
>>> '58fe0d406874c6f565f648d3b10da62a')
>>>
>>> prepare() {
>>> cd ${srcdir}
>>> mv sysdig-${_sysdigver} sysdig
>>> mv falco-${pkgver} falco
>>> rm -rf ./etc/rc.d
>>> cd ./falco
>>> mkdir build
>>>
>>> }
>>
>> All this moving around is ugly, if upstream depends on out-of-tree
>> sources from another repo you should probably either clone a git tag or
>> perhaps more ideally `ln -sf sysdig-${_sysdigver} sysdig`.
>>
>> Currently building a new version without clearing the old version will
>> break, while that maybe shouldn't be done at all, it is always nice to
>> do things in a way that plays nicely anyway.
>>
>>> build() {
>>> cd $srcdir/falco/build
>>> cmake ..
>>> make driver
>>> }
>>>
>>> package() {
>>>
>>> cd $srcdir
>>> mkdir $pkgdir/usr
>>> cp -r ./usr/* $pkgdir/usr/
>>> mkdir $pkgdir/etc
>>> cp -r ./etc/* $pkgdir/etc/
>>> mkdir -p "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/"
>>> cp "$srcdir/falco/build/driver/falco-probe.ko"
>>> "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/falco-probe.ko"
>>> mkdir -p $pkgdir/usr/lib/systemd/system/
>>> cp sysdig-falco.service $pkgdir/usr/lib/systemd/system/
>>> }
>>
>> If I read this correctly, the only thing you ever did here was build a
>> copy of sysdig-probe.ko (provided by the sysdig package via dkms) named
>> falco-probe.ko, and then use the prebuilt binary artifacts from some rpm.
>>
>> This should be built properly, against system libraries. Either that or
>> name this package "sysdig-falco-bin" to indicate it is a package
>> containing prebuilt binaries, and to clear the namespace for someone
>> else to upload a proper built-from-source package.
>>
>> Also you repeatedly fail to quote $srcdir and $pkgdir, which means your
>> PKGBUILD will fail to compile if built from a directory with spaces e.g.
>> "~/AUR packages/".
>> And on a stylistic level, you erratically switch from $variable to
>> ${variable}, please choose one style and stick to it.
>>
>> --
>> Eli Schwartz
>>
>
> I have updated my PKGBUILD. Thank
Re: [aur-general] PKGBUILD review
On Wed, Oct 18, 2017 at 10:18 PM, Eli Schwartz wrote:
> On 10/18/2017 06:13 PM, Garrett Battaglia via aur-general wrote:
>> This is the first time I am packaging for the AUR I would like someone
>> to look over my PKGBUILD below.
>>
>> Thanks,
>> Garrett
>>
>> #Maintainer: Garrett Battaglia
>> pkgname=sysdig-falco
>> pkgver=0.8.1
>> _sysdigver=0.19.1
>> pkgrel=1
>> pkgdesc="Behavioral Activity Monitoring With Container Support"
>> arch=('x86_64')
>
> Why x86_64 only? It is available for both, even the prebuilt binaries.
>
>> url=https://github.com/draios/falco
>> license=('GPL')
>> depends=('dkms')
>> makedepends=('git' 'cmake' 'linux-headers')
>> provides=('sysdig-falco')
>>
>> source=(
>> "http://download.draios.com/stable/rpm/${arch}/falco-${pkgver}-${arch}.rpm";
>> "https://github.com/draios/falco/archive/${pkgver}.tar.gz";
>> "https://github.com/draios/sysdig/archive/${_sysdigver}.tar.gz";
>> "sysdig-falco.install"
>> "sysdig-falco.service")
>>
>> install=$pkgname.install
>
> You haven't shown us the install file or the service file. install files
> are not supposed to be listed in source=()
>
> More than that, files named eg. 0.8.1.tar.gz should be renamed, by
> listing the source as e.g.
> "${pkgname}-${pkgver}.tar.gz::http://github.com/draios/falco/archive/${pkgver}.tar.gz";
>
> Why on earth are you downloading an rpm for a package that has source
> code available in git?
>
> If for some reason you desperately have to, DO NOT use ${arch} in the
> filename, it doesn't do what you think it does and only worked through
> sheer accident. That gets you the first array element of arch=() which
> only works as intended when there is ONLY one element and is not
> documented for use, it also breaks sane handling of multi-arch sources. Use:
> source_i686=("http://download.draios.com/stable/rpm/i386/falco-${pkgver}-i686.rpm";)
> source_x86_64=("http://download.draios.com/stable/rpm/x86_64/falco-${pkgver}-x86_64.rpm";)
>
>> md5sums=(
>> '5e017c747184101a0cc93ffc5b19ca47'
>> 'f3c654ded00f3186f3ff92320204a747'
>> '6ad8b4a7d1b0aa10cd62397318117a67'
>> '8bdb4c61dadd116f4901fa15c20da728'
>> '58fe0d406874c6f565f648d3b10da62a')
>>
>> prepare() {
>> cd ${srcdir}
>> mv sysdig-${_sysdigver} sysdig
>> mv falco-${pkgver} falco
>> rm -rf ./etc/rc.d
>> cd ./falco
>> mkdir build
>>
>> }
>
> All this moving around is ugly, if upstream depends on out-of-tree
> sources from another repo you should probably either clone a git tag or
> perhaps more ideally `ln -sf sysdig-${_sysdigver} sysdig`.
>
> Currently building a new version without clearing the old version will
> break, while that maybe shouldn't be done at all, it is always nice to
> do things in a way that plays nicely anyway.
>
>> build() {
>> cd $srcdir/falco/build
>> cmake ..
>> make driver
>> }
>>
>> package() {
>>
>> cd $srcdir
>> mkdir $pkgdir/usr
>> cp -r ./usr/* $pkgdir/usr/
>> mkdir $pkgdir/etc
>> cp -r ./etc/* $pkgdir/etc/
>> mkdir -p "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/"
>> cp "$srcdir/falco/build/driver/falco-probe.ko"
>> "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/falco-probe.ko"
>> mkdir -p $pkgdir/usr/lib/systemd/system/
>> cp sysdig-falco.service $pkgdir/usr/lib/systemd/system/
>> }
>
> If I read this correctly, the only thing you ever did here was build a
> copy of sysdig-probe.ko (provided by the sysdig package via dkms) named
> falco-probe.ko, and then use the prebuilt binary artifacts from some rpm.
>
> This should be built properly, against system libraries. Either that or
> name this package "sysdig-falco-bin" to indicate it is a package
> containing prebuilt binaries, and to clear the namespace for someone
> else to upload a proper built-from-source package.
>
> Also you repeatedly fail to quote $srcdir and $pkgdir, which means your
> PKGBUILD will fail to compile if built from a directory with spaces e.g.
> "~/AUR packages/".
> And on a stylistic level, you erratically switch from $variable to
> ${variable}, please choose one style and stick to it.
>
> --
> Eli Schwartz
>
I have updated my PKGBUILD. Thanks for the corrections. The reason I'm
using the RPM package is because the source doesn't build and I don't
have the skills to pull apart the cmake files to figure out why. The
best I can tell is it pulls in the src for all it's dependencies and
builds them when it builds JQ for static linking it fails and I don't
know how to fix the error. As for cleaning, would deleting the srcdir
be appropriate. Below are PKGBUILD, .install and service files.
Garrett Battaglia
PKGBUILD:
#Maintainer: Garrett Battaglia
pkgname=sysdig-falco-bin
pkgver=0.8.1
_sysdigver=0.19.1
pkgrel=1
pkgdesc="Behavioral Activity Monitoring With Container Support"
arch=('x86_64' 'i686')
url=https://github.com/draios/falco
license=('GPL')
depends=('dkms')
makedepends=('cmake' 'linux-headers')
provides=('sysdig-falco')
source_i686=(http://download.draios.com/stable/rpm/i386/falco-${pkgver}-i686.rpm)
source_x86_64=("http://dow
Re: [aur-general] PKGBUILD review
On 10/18/2017 06:13 PM, Garrett Battaglia via aur-general wrote:
> This is the first time I am packaging for the AUR I would like someone
> to look over my PKGBUILD below.
>
> Thanks,
> Garrett
>
> #Maintainer: Garrett Battaglia
> pkgname=sysdig-falco
> pkgver=0.8.1
> _sysdigver=0.19.1
> pkgrel=1
> pkgdesc="Behavioral Activity Monitoring With Container Support"
> arch=('x86_64')
Why x86_64 only? It is available for both, even the prebuilt binaries.
> url=https://github.com/draios/falco
> license=('GPL')
> depends=('dkms')
> makedepends=('git' 'cmake' 'linux-headers')
> provides=('sysdig-falco')
>
> source=(
> "http://download.draios.com/stable/rpm/${arch}/falco-${pkgver}-${arch}.rpm";
> "https://github.com/draios/falco/archive/${pkgver}.tar.gz";
> "https://github.com/draios/sysdig/archive/${_sysdigver}.tar.gz";
> "sysdig-falco.install"
> "sysdig-falco.service")
>
> install=$pkgname.install
You haven't shown us the install file or the service file. install files
are not supposed to be listed in source=()
More than that, files named eg. 0.8.1.tar.gz should be renamed, by
listing the source as e.g.
"${pkgname}-${pkgver}.tar.gz::http://github.com/draios/falco/archive/${pkgver}.tar.gz";
Why on earth are you downloading an rpm for a package that has source
code available in git?
If for some reason you desperately have to, DO NOT use ${arch} in the
filename, it doesn't do what you think it does and only worked through
sheer accident. That gets you the first array element of arch=() which
only works as intended when there is ONLY one element and is not
documented for use, it also breaks sane handling of multi-arch sources. Use:
source_i686=("http://download.draios.com/stable/rpm/i386/falco-${pkgver}-i686.rpm";)
source_x86_64=("http://download.draios.com/stable/rpm/x86_64/falco-${pkgver}-x86_64.rpm";)
> md5sums=(
> '5e017c747184101a0cc93ffc5b19ca47'
> 'f3c654ded00f3186f3ff92320204a747'
> '6ad8b4a7d1b0aa10cd62397318117a67'
> '8bdb4c61dadd116f4901fa15c20da728'
> '58fe0d406874c6f565f648d3b10da62a')
>
> prepare() {
> cd ${srcdir}
> mv sysdig-${_sysdigver} sysdig
> mv falco-${pkgver} falco
> rm -rf ./etc/rc.d
> cd ./falco
> mkdir build
>
> }
All this moving around is ugly, if upstream depends on out-of-tree
sources from another repo you should probably either clone a git tag or
perhaps more ideally `ln -sf sysdig-${_sysdigver} sysdig`.
Currently building a new version without clearing the old version will
break, while that maybe shouldn't be done at all, it is always nice to
do things in a way that plays nicely anyway.
> build() {
> cd $srcdir/falco/build
> cmake ..
> make driver
> }
>
> package() {
>
> cd $srcdir
> mkdir $pkgdir/usr
> cp -r ./usr/* $pkgdir/usr/
> mkdir $pkgdir/etc
> cp -r ./etc/* $pkgdir/etc/
> mkdir -p "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/"
> cp "$srcdir/falco/build/driver/falco-probe.ko"
> "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/falco-probe.ko"
> mkdir -p $pkgdir/usr/lib/systemd/system/
> cp sysdig-falco.service $pkgdir/usr/lib/systemd/system/
> }
If I read this correctly, the only thing you ever did here was build a
copy of sysdig-probe.ko (provided by the sysdig package via dkms) named
falco-probe.ko, and then use the prebuilt binary artifacts from some rpm.
This should be built properly, against system libraries. Either that or
name this package "sysdig-falco-bin" to indicate it is a package
containing prebuilt binaries, and to clear the namespace for someone
else to upload a proper built-from-source package.
Also you repeatedly fail to quote $srcdir and $pkgdir, which means your
PKGBUILD will fail to compile if built from a directory with spaces e.g.
"~/AUR packages/".
And on a stylistic level, you erratically switch from $variable to
${variable}, please choose one style and stick to it.
--
Eli Schwartz
signature.asc
Description: OpenPGP digital signature
[aur-general] PKGBUILD review
This is the first time I am packaging for the AUR I would like someone
to look over my PKGBUILD below.
Thanks,
Garrett
#Maintainer: Garrett Battaglia
pkgname=sysdig-falco
pkgver=0.8.1
_sysdigver=0.19.1
pkgrel=1
pkgdesc="Behavioral Activity Monitoring With Container Support"
arch=('x86_64')
url=https://github.com/draios/falco
license=('GPL')
depends=('dkms')
makedepends=('git' 'cmake' 'linux-headers')
provides=('sysdig-falco')
source=(
"http://download.draios.com/stable/rpm/${arch}/falco-${pkgver}-${arch}.rpm";
"https://github.com/draios/falco/archive/${pkgver}.tar.gz";
"https://github.com/draios/sysdig/archive/${_sysdigver}.tar.gz";
"sysdig-falco.install"
"sysdig-falco.service")
install=$pkgname.install
md5sums=(
'5e017c747184101a0cc93ffc5b19ca47'
'f3c654ded00f3186f3ff92320204a747'
'6ad8b4a7d1b0aa10cd62397318117a67'
'8bdb4c61dadd116f4901fa15c20da728'
'58fe0d406874c6f565f648d3b10da62a')
prepare() {
cd ${srcdir}
mv sysdig-${_sysdigver} sysdig
mv falco-${pkgver} falco
rm -rf ./etc/rc.d
cd ./falco
mkdir build
}
build() {
cd $srcdir/falco/build
cmake ..
make driver
}
package() {
cd $srcdir
mkdir $pkgdir/usr
cp -r ./usr/* $pkgdir/usr/
mkdir $pkgdir/etc
cp -r ./etc/* $pkgdir/etc/
mkdir -p "$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/"
cp "$srcdir/falco/build/driver/falco-probe.ko"
"$pkgdir/var/lib/dkms/falco/${pkgver}/${kernelVer}/${arch}/module/falco-probe.ko"
mkdir -p $pkgdir/usr/lib/systemd/system/
cp sysdig-falco.service $pkgdir/usr/lib/systemd/system/
}
Re: [aur-general] PKGBUILD review request: libdime-hg
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
Re: [aur-general] PKGBUILD review request: libdime-hg
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
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
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
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
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
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
thanks for your response __ Persian web-based mail | MihanMail.Com
Re: [aur-general] PKGBUILD Review Request: syncevolution
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
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
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
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
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
Re: [aur-general] PKGBUILD review request: understand-bin
> What's with the "scitools" variable? Doesn't seem to do anything useful. Deleted. > source and checksum arrays support architecture specific arrays now. Check the > man page/wiki page. I known about it, but I think that it will be shorter. > You shouldn't be changing anything in $srcdir in the package function. What > happens when someone runs makepkg --repackage? Corrected. > There's really no reason to change the name of the license file. Corrected. > "install -d "$pkgdir/usr/bin"" doesn't really do anything since you're using > the -D option on the next line. That will create the dir. Corrected. > You should be consistent with how you use variables. Sometimes you have them > in > braces and sometimes you don't, even in the same path. Corrected. I can share my PKGBUILD now? P.S. I have not received a reply. I waited digest and copied ID message to In-Reply-To. I hope this will works. So it should be? And sorry for my EnGlIsH.
Re: [aur-general] PKGBUILD review request: understand-bin
On Mon, 13 Jun 2016 14:14:00 +0300 Alex Sarum via aur-general wrote: > 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 What's with the "scitools" variable? Doesn't seem to do anything useful. source and checksum arrays support architecture specific arrays now. Check the man page/wiki page. You shouldn't be changing anything in $srcdir in the package function. What happens when someone runs makepkg --repackage? There's really no reason to change the name of the license file. "install -d "$pkgdir/usr/bin"" doesn't really do anything since you're using the -D option on the next line. That will create the dir. You should be consistent with how you use variables. Sometimes you have them in braces and sometimes you don't, even in the same path.
[aur-general] PKGBUILD review request: understand-bin
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
Re: [aur-general] PKGBUILD review
This is actually compiling export templates. After making your game, you export to your desired platform. To that, you have to use these templates in the export menu. If you want to export to Windows, you have to build that template. I completely forgot about the _Arch comment from the last time I submitted. I'll fix that. On Feb 5, 2016 1:30 AM, "Justin Dray" wrote: > You've still got references to OS X and windows installs > > Also instead of > > if test _arch == '32'; then > scons -j $cores platform=server target=release_debug tools=no bits=32 > else > scons -j $cores platform=server target=release_debug tools=no bits=64 > fi > > you can just do > > scons -j $cores platform=server target=release_debug tools=no bits=$_arch > > You're setting _arch in 3 places even though it can only have 2 values; > it's also in an array for no apparent reason, you can shorten it to > _arch=32 > [[ $CARCH == x86_64 ]] && _arch=64 > > Or some such variation. > > The same goes in the install, you have a bunch of 'if _arch == 32' and then > using 32 twice in a string; just substitute that with the variable. > > Regards, > Justin >
Re: [aur-general] PKGBUILD review
This is actually compiling export templates. After making your game, you
export to your desired platform. To that, you have to use these templates
in the export menu.
On Feb 5, 2016 12:46 PM, "Mark Weiman" wrote:
> Can you explain further what this PKGBUILD is for and what it
> accomplishes? Also how does this differ from the godot package. I'm
> having a really hard time understanding what this actually does.
>
> That said, you should also remove any parts that do not apply to Arch
> Linux. This means any Windows parts, any Android parts, any Windows
> parts, etc.
>
> Mark Weiman
>
> On Fri, 2016-02-05 at 00:33 -0500, Ryan Whited wrote:
> > Couldn't figure out how to reply from digest (turned that off now) so
> > I guess I'm starting a new thread. I've completely overhauled the
> > PKGBUILD taking in critiques that I've received and some things I've
> > learned on my own.
> >
> > As before, you can view the PKGBUILD at
> > https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-expor
> > t
> >
> >
> > # Maintainer: Ryan Whited
> > @god_of_grunts
> >
> > pkgname=godot-export
> > _rname=godot
> > pkgver=1.1
> > pkgrel=1
> > pkgdesc="Export templates for the stable release of the Godot engine
> > 1.1"
> > url="http://www.godotengine.org";
> > license=('MIT')
> > arch=('i686' 'x86_64')
> > makedepends=('scons' 'mingw-w64-binutils' 'mingw-w64-crt'
> > 'mingw-w64-gcc' 'mingw-w64-headers' 'mingw-w64-headers-bootstrap'
> > 'mingw-w64-winpthreads' 'upx') #'emscripten'
> > depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2' 'mesa')
> > optdepends=('godot: Cannot export without it')
> > conflicts=('godot-export-git' 'godot-git')
> > install=$pkgname.install
> > _arch=''
> > if test "$CARCH" == x86_64; then
> > _arch=('64')
> > else
> > _arch=('32')
> > fi
> >
> > source=("https://github.com/godotengine/godot/archive/${pkgver}-stabl
> > e.tar.gz")
> > md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
> >
> > build() {
> > export MINGW64_PREFIX="x86_64-w64-mingw32-"
> > export MINGW32_PREFIX="i686-w64-mingw32-"
> > #export EMSCRIPTEN_ROOT=/usr/lib/emscripten
> > cores=$(nproc)
> >
> > cd "${srcdir}"/${_rname}-${pkgver}-stable
> >
> > #linux
> > if test _arch == '32'; then
> > scons -j $cores platform=x11 tools=no target=release bits=32
> > #linux_x11_32_release
> > scons -j $cores platform=x11 tools=no target=release_debug
> > bits=32 #linux_x11_32_debug
> > else
> > scons -j $cores platform=x11 tools=no target=release bits=64
> > #linux_x11_64_release
> > scons -j $cores platform=x11 tools=no target=release_debug
> > bits=64 #linux_x11_64_debug
> > fi
> >
> > #linux-server
> > if test _arch == '32'; then
> > scons -j $cores platform=server target=release_debug tools=no
> > bits=32
> > else
> > scons -j $cores platform=server target=release_debug tools=no
> > bits=64
> > fi
> >
> > #Windows
> > export MINGW32_PREFIX="i686-w64-mingw32-"
> > export MINGW64_PREFIX="x86_64-w64-mingw32-"
> >
> > scons -j $cores platform=windows tools=no target=release bits=32
> > #windows_32_release.exe
> > scons -j $cores platform=windows tools=no target=release_debug
> > bits=32 #windows_32_debug.exe
> > scons -j $cores platform=windows tools=no target=release bits=64
> > #windows_64_release.exe
> > scons -j $cores platform=windows tools=no target=release_debug
> > bits=64 #windows_64_debug.exe
> >
> > #OS X
> > #I'll put code here when
> > https://github.com/godotengine/godot/wiki/compiling_osx is updated
> >
> > #Android
> > #Probably should do this yourself, I'm not about to mess with
> > your
> > Android SDK
> > #https://github.com/godotengine/godot/wiki/export_android
> >
> > #WinRT
> > #Can't do this on Linux sorry
> >
> > #Blackberry 10
> > #Currently disabled by Godot
> >
> > #HTML5
> > #Currently broken per https://github.com/godotengine/godot/issues
> > /3510
> > #scons -j $cores platform=javascript tools=no target=release
> > #scons -j $cores platform=javascript tools=no
> > target=release_debug
> >
> > }
> >
> > package() {
> >
> > install -D -m644 "${srcdir}"/${_rname}-${pkgver}-
> > stable/LICENSE.md
> > "${pkgdir}/usr/share/licenses/${_rname}/LICENSE"
> >
> > #Linux
> > if test _arch == '32'; then
> > install -D -m755
> > "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.32
> > ${pkgdir}/usr/lib/godot/linux_x11_32_release
> > install -D -m755
> > "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.debug.32
> > ${pkgdir}/usr/lib/godot/linux_x11_32_debug
> > upx ${pkgdir}/usr/lib/godot/linux_x11_32_release
> > upx ${pkgdir}/usr/lib/godot/linux_x11_32_debug
> > else
> > install -D -m755
> > "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.64
> > ${pkgdir}/usr/lib/godot/linux_x11_64_release
> > install -D -m755
Re: [aur-general] PKGBUILD review
Can you explain further what this PKGBUILD is for and what it
accomplishes? Also how does this differ from the godot package. I'm
having a really hard time understanding what this actually does.
That said, you should also remove any parts that do not apply to Arch
Linux. This means any Windows parts, any Android parts, any Windows
parts, etc.
Mark Weiman
On Fri, 2016-02-05 at 00:33 -0500, Ryan Whited wrote:
> Couldn't figure out how to reply from digest (turned that off now) so
> I guess I'm starting a new thread. I've completely overhauled the
> PKGBUILD taking in critiques that I've received and some things I've
> learned on my own.
>
> As before, you can view the PKGBUILD at
> https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-expor
> t
>
>
> # Maintainer: Ryan Whited
> @god_of_grunts
>
> pkgname=godot-export
> _rname=godot
> pkgver=1.1
> pkgrel=1
> pkgdesc="Export templates for the stable release of the Godot engine
> 1.1"
> url="http://www.godotengine.org";
> license=('MIT')
> arch=('i686' 'x86_64')
> makedepends=('scons' 'mingw-w64-binutils' 'mingw-w64-crt'
> 'mingw-w64-gcc' 'mingw-w64-headers' 'mingw-w64-headers-bootstrap'
> 'mingw-w64-winpthreads' 'upx') #'emscripten'
> depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2' 'mesa')
> optdepends=('godot: Cannot export without it')
> conflicts=('godot-export-git' 'godot-git')
> install=$pkgname.install
> _arch=''
> if test "$CARCH" == x86_64; then
> _arch=('64')
> else
> _arch=('32')
> fi
>
> source=("https://github.com/godotengine/godot/archive/${pkgver}-stabl
> e.tar.gz")
> md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
>
> build() {
> export MINGW64_PREFIX="x86_64-w64-mingw32-"
> export MINGW32_PREFIX="i686-w64-mingw32-"
> #export EMSCRIPTEN_ROOT=/usr/lib/emscripten
> cores=$(nproc)
>
> cd "${srcdir}"/${_rname}-${pkgver}-stable
>
> #linux
> if test _arch == '32'; then
> scons -j $cores platform=x11 tools=no target=release bits=32
> #linux_x11_32_release
> scons -j $cores platform=x11 tools=no target=release_debug
> bits=32 #linux_x11_32_debug
> else
> scons -j $cores platform=x11 tools=no target=release bits=64
> #linux_x11_64_release
> scons -j $cores platform=x11 tools=no target=release_debug
> bits=64 #linux_x11_64_debug
> fi
>
> #linux-server
> if test _arch == '32'; then
> scons -j $cores platform=server target=release_debug tools=no
> bits=32
> else
> scons -j $cores platform=server target=release_debug tools=no
> bits=64
> fi
>
> #Windows
> export MINGW32_PREFIX="i686-w64-mingw32-"
> export MINGW64_PREFIX="x86_64-w64-mingw32-"
>
> scons -j $cores platform=windows tools=no target=release bits=32
> #windows_32_release.exe
> scons -j $cores platform=windows tools=no target=release_debug
> bits=32 #windows_32_debug.exe
> scons -j $cores platform=windows tools=no target=release bits=64
> #windows_64_release.exe
> scons -j $cores platform=windows tools=no target=release_debug
> bits=64 #windows_64_debug.exe
>
> #OS X
> #I'll put code here when
> https://github.com/godotengine/godot/wiki/compiling_osx is updated
>
> #Android
> #Probably should do this yourself, I'm not about to mess with
> your
> Android SDK
> #https://github.com/godotengine/godot/wiki/export_android
>
> #WinRT
> #Can't do this on Linux sorry
>
> #Blackberry 10
> #Currently disabled by Godot
>
> #HTML5
> #Currently broken per https://github.com/godotengine/godot/issues
> /3510
> #scons -j $cores platform=javascript tools=no target=release
> #scons -j $cores platform=javascript tools=no
> target=release_debug
>
> }
>
> package() {
>
> install -D -m644 "${srcdir}"/${_rname}-${pkgver}-
> stable/LICENSE.md
> "${pkgdir}/usr/share/licenses/${_rname}/LICENSE"
>
> #Linux
> if test _arch == '32'; then
> install -D -m755
> "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.32
> ${pkgdir}/usr/lib/godot/linux_x11_32_release
> install -D -m755
> "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.debug.32
> ${pkgdir}/usr/lib/godot/linux_x11_32_debug
> upx ${pkgdir}/usr/lib/godot/linux_x11_32_release
> upx ${pkgdir}/usr/lib/godot/linux_x11_32_debug
> else
> install -D -m755
> "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.64
> ${pkgdir}/usr/lib/godot/linux_x11_64_release
> install -D -m755
> "${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.debug.64
> ${pkgdir}/usr/lib/godot/linux_x11_64_debug
> upx ${pkgdir}/usr/lib/godot/linux_x11_64_release
> upx ${pkgdir}/usr/lib/godot/linux_x11_64_debug
> fi
>
> #Linux Server
> if test _arch == '32'; then
> install -D -m755
> "${srcdir}"/${_rname}-${pkgver}-
> stable/bin/godot_server.server.opt.debug.32
> ${pkgdir}/usr/lib/godot/linux_server_32
> upx ${pkgdir}/usr
Re: [aur-general] PKGBUILD review
mingw-w64-gcc is the only mingw-w64 package you want to makedepend on, maybe consider to depend on mingw-w64-crt. > From: jus...@dray.be > Date: Fri, 5 Feb 2016 06:30:32 + > To: aur-general@archlinux.org > Subject: Re: [aur-general] PKGBUILD review > > You've still got references to OS X and windows installs > > Also instead of > > if test _arch == '32'; then > scons -j $cores platform=server target=release_debug tools=no bits=32 > else > scons -j $cores platform=server target=release_debug tools=no bits=64 > fi > > you can just do > > scons -j $cores platform=server target=release_debug tools=no bits=$_arch > > You're setting _arch in 3 places even though it can only have 2 values; > it's also in an array for no apparent reason, you can shorten it to > _arch=32 > [[ $CARCH == x86_64 ]] && _arch=64 > > Or some such variation. > > The same goes in the install, you have a bunch of 'if _arch == 32' and then > using 32 twice in a string; just substitute that with the variable. > > Regards, > Justin
Re: [aur-general] PKGBUILD review
You've still got references to OS X and windows installs Also instead of if test _arch == '32'; then scons -j $cores platform=server target=release_debug tools=no bits=32 else scons -j $cores platform=server target=release_debug tools=no bits=64 fi you can just do scons -j $cores platform=server target=release_debug tools=no bits=$_arch You're setting _arch in 3 places even though it can only have 2 values; it's also in an array for no apparent reason, you can shorten it to _arch=32 [[ $CARCH == x86_64 ]] && _arch=64 Or some such variation. The same goes in the install, you have a bunch of 'if _arch == 32' and then using 32 twice in a string; just substitute that with the variable. Regards, Justin
[aur-general] PKGBUILD review
Couldn't figure out how to reply from digest (turned that off now) so
I guess I'm starting a new thread. I've completely overhauled the
PKGBUILD taking in critiques that I've received and some things I've
learned on my own.
As before, you can view the PKGBUILD at
https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-export
# Maintainer: Ryan Whited @god_of_grunts
pkgname=godot-export
_rname=godot
pkgver=1.1
pkgrel=1
pkgdesc="Export templates for the stable release of the Godot engine 1.1"
url="http://www.godotengine.org";
license=('MIT')
arch=('i686' 'x86_64')
makedepends=('scons' 'mingw-w64-binutils' 'mingw-w64-crt'
'mingw-w64-gcc' 'mingw-w64-headers' 'mingw-w64-headers-bootstrap'
'mingw-w64-winpthreads' 'upx') #'emscripten'
depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2' 'mesa')
optdepends=('godot: Cannot export without it')
conflicts=('godot-export-git' 'godot-git')
install=$pkgname.install
_arch=''
if test "$CARCH" == x86_64; then
_arch=('64')
else
_arch=('32')
fi
source=("https://github.com/godotengine/godot/archive/${pkgver}-stable.tar.gz";)
md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
build() {
export MINGW64_PREFIX="x86_64-w64-mingw32-"
export MINGW32_PREFIX="i686-w64-mingw32-"
#export EMSCRIPTEN_ROOT=/usr/lib/emscripten
cores=$(nproc)
cd "${srcdir}"/${_rname}-${pkgver}-stable
#linux
if test _arch == '32'; then
scons -j $cores platform=x11 tools=no target=release bits=32
#linux_x11_32_release
scons -j $cores platform=x11 tools=no target=release_debug
bits=32 #linux_x11_32_debug
else
scons -j $cores platform=x11 tools=no target=release bits=64
#linux_x11_64_release
scons -j $cores platform=x11 tools=no target=release_debug
bits=64 #linux_x11_64_debug
fi
#linux-server
if test _arch == '32'; then
scons -j $cores platform=server target=release_debug tools=no bits=32
else
scons -j $cores platform=server target=release_debug tools=no bits=64
fi
#Windows
export MINGW32_PREFIX="i686-w64-mingw32-"
export MINGW64_PREFIX="x86_64-w64-mingw32-"
scons -j $cores platform=windows tools=no target=release bits=32
#windows_32_release.exe
scons -j $cores platform=windows tools=no target=release_debug
bits=32 #windows_32_debug.exe
scons -j $cores platform=windows tools=no target=release bits=64
#windows_64_release.exe
scons -j $cores platform=windows tools=no target=release_debug
bits=64 #windows_64_debug.exe
#OS X
#I'll put code here when
https://github.com/godotengine/godot/wiki/compiling_osx is updated
#Android
#Probably should do this yourself, I'm not about to mess with your
Android SDK
#https://github.com/godotengine/godot/wiki/export_android
#WinRT
#Can't do this on Linux sorry
#Blackberry 10
#Currently disabled by Godot
#HTML5
#Currently broken per https://github.com/godotengine/godot/issues/3510
#scons -j $cores platform=javascript tools=no target=release
#scons -j $cores platform=javascript tools=no target=release_debug
}
package() {
install -D -m644 "${srcdir}"/${_rname}-${pkgver}-stable/LICENSE.md
"${pkgdir}/usr/share/licenses/${_rname}/LICENSE"
#Linux
if test _arch == '32'; then
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.32
${pkgdir}/usr/lib/godot/linux_x11_32_release
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.debug.32
${pkgdir}/usr/lib/godot/linux_x11_32_debug
upx ${pkgdir}/usr/lib/godot/linux_x11_32_release
upx ${pkgdir}/usr/lib/godot/linux_x11_32_debug
else
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.64
${pkgdir}/usr/lib/godot/linux_x11_64_release
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.x11.opt.debug.64
${pkgdir}/usr/lib/godot/linux_x11_64_debug
upx ${pkgdir}/usr/lib/godot/linux_x11_64_release
upx ${pkgdir}/usr/lib/godot/linux_x11_64_debug
fi
#Linux Server
if test _arch == '32'; then
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot_server.server.opt.debug.32
${pkgdir}/usr/lib/godot/linux_server_32
upx ${pkgdir}/usr/lib/godot/linux_server_32
else
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot_server.server.opt.debug.64
${pkgdir}/usr/lib/godot/linux_server_64
upx ${pkgdir}/usr/lib/godot/linux_server_64
fi
#Windows
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.windows.opt.64.exe
${pkgdir}/usr/lib/godot/windows_64_release.exe
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.windows.opt.debug.64.exe
${pkgdir}/usr/lib/godot/windows_64_debug.exe
install -D -m755
"${srcdir}"/${_rname}-${pkgver}-stable/bin/godot.windows.opt.32.exe
${pkgdir}/usr/lib/godot/windows_32_release.exe
install -D -m755
"${srcdir}"/${_rnam
Re: [aur-general] PKGBUILD review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I agree with you.
Plus, I don't understand why you need to test the arch :
if test _arch == '32';
is not needed as you can do :
scons -j $cores platform=x11 tools=no target=release bits=$_arch
Le 31/01/2016 17:36, Mark Weiman a écrit :
> My main concern about this PKGBUILD other than it using directories
> in the user's home folder is why are you putting compilation
> commands for other operating systems in there? This should just be
> for Arch Linux as a PKGBUILD is only used for use with pacman.
>
> Mark Weiman
>
> On Fri, 2016-01-29 at 16:53 -0500, Ryan Whited wrote:
>> Greetings,
>>
>> I've written my first PKGBUILD that I think is acceptable to
>> submit and while I tried to make sure I followed the guidelines,
>> I wanted to submit it for review here. You can view it online at
>> https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-expor
>>
>>
t
>> if it's easier than email.
>>
>> # Maintainer: Ryan Whited
>> @god_of_grunts
>>
>> pkgname=godot-export _rname=godot pkgver=1.1 pkgrel=1
>> pkgdesc="Export templates for the stable release of the Godot
>> engine 1.1" url="http://www.godotengine.org"; license=('MIT')
>> arch=('i686' 'x86_64') makedepends=('scons' 'mingw-w64-binutils'
>> 'mingw-w64-crt' 'mingw-w64-gcc' 'mingw-w64-headers'
>> 'mingw-w64-headers-bootstrap' 'mingw-w64-winpthreads' 'upx')
>> #'emscripten' depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2'
>> 'mesa') optdepends=('godot: Cannot export without it')
>> conflicts=('godot-export-git' 'godot-git') _arch='' if test
>> "$CARCH" == x86_64; then _arch=('64') else _arch=('32') fi
>>
>> tempdir="/home/$USER/.godot/templates/"
>>
>> source=(
>> "https://github.com/godotengine/godot/archive/${pkgver}-stable.tar.gz
>>
>>
"
>> ) md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
>>
>> build() { export MINGW64_PREFIX="x86_64-w64-mingw32-" export
>> MINGW32_PREFIX="i686-w64-mingw32-"
>>
>> cd "${srcdir}"/${_rname}-${pkgver}-stable
>>
>> sed -n '/\/* Copyright/,/IN THE SOFTWARE./p' main/main.cpp | sed
>> 's/\/\*//' | sed 's/\*\///' > LICENSE
>>
>> cores=$(nproc)
>> bindir=("${srcdir}"/${_rname}-${pkgver}-stable/bin)
>> tooldir=("${srcdir}"/${_rname}-${pkgver}-stable/tools)
>>
>> mkdir $tempdir || echo $tempdir does not need to be made
>>
>> #linux if test _arch == '32'; then scons -j $cores platform=x11
>> tools=no target=release bits=32 #linux_x11_32_release scons -j
>> $cores platform=x11 tools=no target=release_debug bits=32
>> #linux_x11_32_debug cp $bindir/godot.x11.opt.32
>> $tempdir/linux_x11_32_release cp $bindir/godot.x11.opt.debug.32
>> $tempdir/linux_x11_32_debug else scons -j $cores platform=x11
>> tools=no target=release bits=64 #linux_x11_64_release scons -j
>> $cores platform=x11 tools=no target=release_debug bits=64
>> #linux_x11_64_debug cp $bindir/godot.x11.opt.64
>> $tempdir/linux_x11_64_release cp $bindir/godot.x11.opt.debug.64
>> $tempdir/linux_x11_64_debug fi
>>
>> #linux-server if test _arch == '32'; then scons -j $cores
>> platform=server target=release_debug tools=no bits=32 cp
>> $bindir/godot_server.server.opt.debug.32
>> $tempdir/linux_server_32 else scons -j $cores platform=server
>> target=release_debug tools=no bits=64 cp
>> $bindir/godot_server.server.opt.debug.64
>> $tempdir/linux_server_64 fi
>>
>> #Windows export MINGW32_PREFIX="i686-w64-mingw32-" export
>> MINGW64_PREFIX="x86_64-w64-mingw32-"
>>
>> scons -j $cores platform=windows tools=no target=release bits=32
>> #windows_32_release.exe scons -j $cores platform=windows tools=no
>> target=release_debug bits=32 #windows_32_debug.exe scons -j
>> $cores platform=windows tools=no target=release bits=64
>> #windows_64_release.exe scons -j $cores platform=windows tools=no
>> target=release_debug bits=64 #windows_64_debug.exe
>>
>> cp $bindir/godot.windows.opt.64.exe
>> $tempdir/windows_64_release.exe cp
>> $bindir/godot.windows.opt.debug.64.exe
>> $tempdir/windows_64_debug.exe cp
>> $bindir/godot.windows.opt.32.exe $tempdir/windows_32_release.exe
>> cp $bindir/godot.windows.opt.debug.32.exe
>> $tempdir/windows_32_debug.exe
>>
>> x86_64-w64-mingw32-strip $tempdir/windows_64_release.exe
>> x86_64-w64-mingw32-strip $tempdir/windows_64_debug.exe upx
>> $tempdir/windows_32_debug.exe upx
>> $tempdir/windows_32_release.exe
>>
>> #OS X #I'll put code here when
>> https://github.com/godotengine/godot/wiki/compiling_osx is
>> updated
>>
>> #Android #Probably should do this yourself, I'm not about to mess
>> with your Android SDK
>> #https://github.com/godotengine/godot/wiki/export_android
>>
>> #WinRT #Can't do this on Linux sorry
>>
>> #Blackberry 10 #Currently disabled by Godot
>>
>> #HTML5 #Currently broken per
>> https://github.com/godotengine/godot/issues /3510
>>
>> #export EMSCRIPTEN_ROOT=/usr/lib/emscripten
>>
>> #scons -j $cores platform=javascript tools=no target=release
>> #scons -j $cores platform=javascript tools=no
>> target=release_debug
>>
>>
Re: [aur-general] PKGBUILD review
My main concern about this PKGBUILD other than it using directories in
the user's home folder is why are you putting compilation commands for
other operating systems in there? This should just be for Arch Linux as
a PKGBUILD is only used for use with pacman.
Mark Weiman
On Fri, 2016-01-29 at 16:53 -0500, Ryan Whited wrote:
> Greetings,
>
> I've written my first PKGBUILD that I think is acceptable to submit
> and while I tried to make sure I followed the guidelines, I wanted to
> submit it for review here. You can view it online at
> https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-expor
> t
> if it's easier than email.
>
> # Maintainer: Ryan Whited
> @god_of_grunts
>
> pkgname=godot-export
> _rname=godot
> pkgver=1.1
> pkgrel=1
> pkgdesc="Export templates for the stable release of the Godot engine
> 1.1"
> url="http://www.godotengine.org";
> license=('MIT')
> arch=('i686' 'x86_64')
> makedepends=('scons' 'mingw-w64-binutils' 'mingw-w64-crt'
> 'mingw-w64-gcc' 'mingw-w64-headers' 'mingw-w64-headers-bootstrap'
> 'mingw-w64-winpthreads' 'upx') #'emscripten'
> depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2' 'mesa')
> optdepends=('godot: Cannot export without it')
> conflicts=('godot-export-git' 'godot-git')
> _arch=''
> if test "$CARCH" == x86_64; then
> _arch=('64')
> else
> _arch=('32')
> fi
>
> tempdir="/home/$USER/.godot/templates/"
>
> source=(
> "https://github.com/godotengine/godot/archive/${pkgver}-stable.tar.gz
> "
> )
> md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
>
> build() {
> export MINGW64_PREFIX="x86_64-w64-mingw32-"
> export MINGW32_PREFIX="i686-w64-mingw32-"
>
> cd "${srcdir}"/${_rname}-${pkgver}-stable
>
> sed -n '/\/* Copyright/,/IN THE SOFTWARE./p' main/main.cpp | sed
> 's/\/\*//' | sed 's/\*\///' > LICENSE
>
> cores=$(nproc)
> bindir=("${srcdir}"/${_rname}-${pkgver}-stable/bin)
> tooldir=("${srcdir}"/${_rname}-${pkgver}-stable/tools)
>
> mkdir $tempdir || echo $tempdir does not need to be made
>
> #linux
> if test _arch == '32'; then
> scons -j $cores platform=x11 tools=no target=release bits=32
> #linux_x11_32_release
> scons -j $cores platform=x11 tools=no target=release_debug
> bits=32 #linux_x11_32_debug
> cp $bindir/godot.x11.opt.32 $tempdir/linux_x11_32_release
> cp $bindir/godot.x11.opt.debug.32 $tempdir/linux_x11_32_debug
> else
> scons -j $cores platform=x11 tools=no target=release bits=64
> #linux_x11_64_release
> scons -j $cores platform=x11 tools=no target=release_debug
> bits=64 #linux_x11_64_debug
> cp $bindir/godot.x11.opt.64 $tempdir/linux_x11_64_release
> cp $bindir/godot.x11.opt.debug.64 $tempdir/linux_x11_64_debug
> fi
>
> #linux-server
> if test _arch == '32'; then
> scons -j $cores platform=server target=release_debug tools=no
> bits=32
> cp $bindir/godot_server.server.opt.debug.32
> $tempdir/linux_server_32
> else
> scons -j $cores platform=server target=release_debug tools=no
> bits=64
> cp $bindir/godot_server.server.opt.debug.64
> $tempdir/linux_server_64
> fi
>
> #Windows
> export MINGW32_PREFIX="i686-w64-mingw32-"
> export MINGW64_PREFIX="x86_64-w64-mingw32-"
>
> scons -j $cores platform=windows tools=no target=release bits=32
> #windows_32_release.exe
> scons -j $cores platform=windows tools=no target=release_debug
> bits=32 #windows_32_debug.exe
> scons -j $cores platform=windows tools=no target=release bits=64
> #windows_64_release.exe
> scons -j $cores platform=windows tools=no target=release_debug
> bits=64 #windows_64_debug.exe
>
> cp $bindir/godot.windows.opt.64.exe
> $tempdir/windows_64_release.exe
> cp $bindir/godot.windows.opt.debug.64.exe
> $tempdir/windows_64_debug.exe
> cp $bindir/godot.windows.opt.32.exe
> $tempdir/windows_32_release.exe
> cp $bindir/godot.windows.opt.debug.32.exe
> $tempdir/windows_32_debug.exe
>
> x86_64-w64-mingw32-strip $tempdir/windows_64_release.exe
> x86_64-w64-mingw32-strip $tempdir/windows_64_debug.exe
> upx $tempdir/windows_32_debug.exe
> upx $tempdir/windows_32_release.exe
>
> #OS X
> #I'll put code here when
> https://github.com/godotengine/godot/wiki/compiling_osx is updated
>
> #Android
> #Probably should do this yourself, I'm not about to mess with
> your
> Android SDK
> #https://github.com/godotengine/godot/wiki/export_android
>
> #WinRT
> #Can't do this on Linux sorry
>
> #Blackberry 10
> #Currently disabled by Godot
>
> #HTML5
> #Currently broken per https://github.com/godotengine/godot/issues
> /3510
>
> #export EMSCRIPTEN_ROOT=/usr/lib/emscripten
>
> #scons -j $cores platform=javascript tools=no target=release
> #scons -j $cores platform=javascript tools=no
> target=release_debug
>
> #cp $bindir/godot.javascript.opt.html $bindir/godot.
Re: [aur-general] PKGBUILD review
On 30.01.2016 00:53, Ryan Whited wrote:
Greetings,
I've written my first PKGBUILD that I think is acceptable to submit
and while I tried to make sure I followed the guidelines, I wanted to
submit it for review here.
Sorry, but this PKGBUILD looks unacceptable to me.
Quotes are from
https://wiki.archlinux.org/index.php/Arch_packaging_standards
Packages should not contain any of the following directories:
...
/home
You shouldn't install anything in home directories, install it in
/usr/share/${pkgname} or /opt/${pkgname} instead
All important messages should be echoed during install using an
.install file. For example, if a package needs extra setup to work,
directions should be included.
If you need to copy files to /home/$USER/.godot/templates/ for programs
to work correctly put message about it in the .install file.
Do not introduce new variables into PKGBUILD build scripts, unless
the package cannot be built without doing so, as these could possibly
conflict with variables used in makepkg itself. If a new variable is
absolutely required, prefix the variable name with an underscore (_).
You create LICENSE file by copying part of main/main.cpp but you
probably should just use LICENSE.md included in the archive. Also you
don't copy it anywhere.
The license file(s) should be included in /usr/share/licenses/$pkgname/
e.g. /usr/share/licenses/dibfoo/LICENSE. One good way to do this is
by using:
install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
In conclusion, you made big mistakes in this PKGBUILD. I think you
should probably rewrite most of it after reading ArchWiki packaging
guidelines carefully.
Regards,
Victor
[aur-general] PKGBUILD review
Greetings,
I've written my first PKGBUILD that I think is acceptable to submit
and while I tried to make sure I followed the guidelines, I wanted to
submit it for review here. You can view it online at
https://github.com/godofgrunts/arch-PKGBUILDs/blob/master/godot-export
if it's easier than email.
# Maintainer: Ryan Whited
@god_of_grunts
pkgname=godot-export
_rname=godot
pkgver=1.1
pkgrel=1
pkgdesc="Export templates for the stable release of the Godot engine 1.1"
url="http://www.godotengine.org";
license=('MIT')
arch=('i686' 'x86_64')
makedepends=('scons' 'mingw-w64-binutils' 'mingw-w64-crt'
'mingw-w64-gcc' 'mingw-w64-headers' 'mingw-w64-headers-bootstrap'
'mingw-w64-winpthreads' 'upx') #'emscripten'
depends=('glu' 'libxcursor' 'alsa-lib' 'freetype2' 'mesa')
optdepends=('godot: Cannot export without it')
conflicts=('godot-export-git' 'godot-git')
_arch=''
if test "$CARCH" == x86_64; then
_arch=('64')
else
_arch=('32')
fi
tempdir="/home/$USER/.godot/templates/"
source=(
"https://github.com/godotengine/godot/archive/${pkgver}-stable.tar.gz";
)
md5sums=('87eb2fc3518ce7a27957fada1ba003e9')
build() {
export MINGW64_PREFIX="x86_64-w64-mingw32-"
export MINGW32_PREFIX="i686-w64-mingw32-"
cd "${srcdir}"/${_rname}-${pkgver}-stable
sed -n '/\/* Copyright/,/IN THE SOFTWARE./p' main/main.cpp | sed
's/\/\*//' | sed 's/\*\///' > LICENSE
cores=$(nproc)
bindir=("${srcdir}"/${_rname}-${pkgver}-stable/bin)
tooldir=("${srcdir}"/${_rname}-${pkgver}-stable/tools)
mkdir $tempdir || echo $tempdir does not need to be made
#linux
if test _arch == '32'; then
scons -j $cores platform=x11 tools=no target=release bits=32
#linux_x11_32_release
scons -j $cores platform=x11 tools=no target=release_debug
bits=32 #linux_x11_32_debug
cp $bindir/godot.x11.opt.32 $tempdir/linux_x11_32_release
cp $bindir/godot.x11.opt.debug.32 $tempdir/linux_x11_32_debug
else
scons -j $cores platform=x11 tools=no target=release bits=64
#linux_x11_64_release
scons -j $cores platform=x11 tools=no target=release_debug
bits=64 #linux_x11_64_debug
cp $bindir/godot.x11.opt.64 $tempdir/linux_x11_64_release
cp $bindir/godot.x11.opt.debug.64 $tempdir/linux_x11_64_debug
fi
#linux-server
if test _arch == '32'; then
scons -j $cores platform=server target=release_debug tools=no
bits=32
cp $bindir/godot_server.server.opt.debug.32 $tempdir/linux_server_32
else
scons -j $cores platform=server target=release_debug tools=no
bits=64
cp $bindir/godot_server.server.opt.debug.64 $tempdir/linux_server_64
fi
#Windows
export MINGW32_PREFIX="i686-w64-mingw32-"
export MINGW64_PREFIX="x86_64-w64-mingw32-"
scons -j $cores platform=windows tools=no target=release bits=32
#windows_32_release.exe
scons -j $cores platform=windows tools=no target=release_debug
bits=32 #windows_32_debug.exe
scons -j $cores platform=windows tools=no target=release bits=64
#windows_64_release.exe
scons -j $cores platform=windows tools=no target=release_debug
bits=64 #windows_64_debug.exe
cp $bindir/godot.windows.opt.64.exe $tempdir/windows_64_release.exe
cp $bindir/godot.windows.opt.debug.64.exe $tempdir/windows_64_debug.exe
cp $bindir/godot.windows.opt.32.exe $tempdir/windows_32_release.exe
cp $bindir/godot.windows.opt.debug.32.exe $tempdir/windows_32_debug.exe
x86_64-w64-mingw32-strip $tempdir/windows_64_release.exe
x86_64-w64-mingw32-strip $tempdir/windows_64_debug.exe
upx $tempdir/windows_32_debug.exe
upx $tempdir/windows_32_release.exe
#OS X
#I'll put code here when
https://github.com/godotengine/godot/wiki/compiling_osx is updated
#Android
#Probably should do this yourself, I'm not about to mess with your
Android SDK
#https://github.com/godotengine/godot/wiki/export_android
#WinRT
#Can't do this on Linux sorry
#Blackberry 10
#Currently disabled by Godot
#HTML5
#Currently broken per https://github.com/godotengine/godot/issues/3510
#export EMSCRIPTEN_ROOT=/usr/lib/emscripten
#scons -j $cores platform=javascript tools=no target=release
#scons -j $cores platform=javascript tools=no target=release_debug
#cp $bindir/godot.javascript.opt.html $bindir/godot.html
#cp $bindir/godot.javascript.opt.js $bindir/godot.js
#cp $tooldir/html_fs/filesystem.js $bindir/filesystem.js
#zip $tempdir/javascript_release.zip $bindir/godot.html
$bindir/godot.js $bindir/filesystem.js
#cp $bindir/godot.javascript.opt.debug.html $bindir/godot.html
#cp $bindir/godot.javascript.opt.debug.js $bindir/godot.js
#zip $tempdir/javascript_debug.zip $bindir/godot.html
$bindir/godot.js $bindir/filesystem.js
}
package() {
#Linux
if test _arch == '32'; then
upx $tempdir/linux_x11_32_release
upx $tempdir/linux_x11_32_debug
else
Re: [aur-general] PKGBUILD review request
I created a pull request on GitHub. See: https://github.com/dobyrch/termboy-go/pull/1 --Jeremy
Re: [aur-general] PKGBUILD review request
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 > wrote: > > 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
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 wrote: > 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
Re: [aur-general] PKGBUILD review request
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
Hi On Fri, Jan 10, 2014 at 4:32 PM, Jason St. John 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
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
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
On Fri, Jan 10, 2014 at 6:59 PM, Douglas Christman
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
[aur-general] PKGBUILD review request
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
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
Re: [aur-general] PKGBUILD review request
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
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
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
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 > > >
[aur-general] PKGBUILD review request
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
