Re: [aur-general] rfc: pkgbuild for prospect releng-tool
On March 6, 2019 12:24:08 AM CST, James Knight via aur-general
wrote:
>Hello -- new user to AUR and hoping if anyone is willing to review a
>PKGBUILD [1] definition for me. I have been reading PKGBUILD [2] and
>"AUR - Submitting packages" [3] documents, which the latter document
>suggests to "... submit the PKGBUILD to the AUR mailing list ... for
>public review before adding it to the AUR".
>
Welcome!
>The following is my prospect PKGBUILD definition if anyone has time to
>make comments/suggestions:
>
>---
># Maintainer: James Knight
>
>pkgname=releng-tool
Python 2/3?
https://wiki.archlinux.org/index.php/Python_package_guidelines
>pkgver=0.1
>pkgrel=1
>pkgdesc='tool to assist in the release engineering of a project'
>url='https://releng.io/'
>arch=('any')
>license=('BSD')
>makedepends=(
> 'python'
>)
Use depends here, makedepends implicitly includes depends.
>source=("$pkgname-$pkgver::git+https://github.com/releng-tool/releng-tool.git#tag=v$pkgver";)
>sha512sums=('SKIP')
>
If you intend to use a version string and not a specific git commit, then get
the versioned tarball from
https://github.com/releng-tool/releng-tool/archive/v0.1/releng-tool.tar.gz and
provide the sums. Also, since you are the developer, sig? You can add it, as
well as other compression formats as part of the release process on GitHub. I
think it's add resources, or similar, been a bit.
>build() {
> cd "$pkgname-$pkgver"
> python setup.py build
>}
>
>check() {
> cd "$pkgname-$pkgver"
> python setup.py test
>}
>
>package() {
> depends=('python')
> cd "$pkgname-$pkgver"
> python setup.py install --root="$pkgdir" --optimize=1
>
> install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
> install -dm 755 "$pkgdir/usr/share/bash-completion/completions"
> install -m644 scripts/releng-tool-completion
>"$pkgdir/usr/share/bash-completion/completions/releng-tool"
>}
Personal preference, and likely not very useful here, but use -v for install
commands, it could save you some time if something breaks in the future.
HTH
--DJ
Re: [aur-general] amiwm PKGBUILD file
On 01/23/2018 04:15 PM, DJ Lucas wrote:
On January 23, 2018 3:59:24 PM CST, Panayotis Katsaloulis via aur-general
wrote:
Hello all
This is my first attempt to create a valid PKGBUILD file for Arch
Linux.
It is about the missing amiwm window manager.
Please tell me what you think
# Maintainer: Panayotis Katsaloulis
pkgname=amiwm
pkgver=0.21pl2
pkgrel=1
pkgdesc="An X window manager that tries to make your display look and
feel like an Amiga® Workbench® screen"
arch=('x86_64' 'i686')
url="https://www.lysator.liu.se/~marcus/amiwm.html";
license=('FREEWARE')
source=('ftp://ftp.lysator.liu.se/pub/X11/wm/amiwm/amiwm0.21pl2.tar.gz')
md5sums=('3a47e88e2be2978363220cf815ef')
build() {
cd "$pkgname$pkgver"
./configure --prefix=/usr
make
}
package() {
cd "$pkgname$pkgver"
make prefix="$pkgdir/usr" install
rm $pkgdir/usr/bin/requestchoice
install -Dm644 LICENSE "$pkgdir"/usr/share/licenses/$pkgname/LICENSE
}
License should be custom, you should use $pkgver in the URL (will save you a
step when you update it), and you need to provide dependency info (at very
least Xorg, but most likely more).
HTH
Also, having built it, it looks like the smallest inclusive dependency
is just libxmu by itself. Finally, the manuals should be installed in
/usr/share/man, not /usr/man. Append the following:
mv -v "${pkgdir}/usr/man" "${pkgdir}/usr/share"
Use of curly braces (unnecessary in this case) and placement of the
quote marks above are to taste. Another thing, again only to taste, is
always using '-v' in mv, cp, ln, and install commands (probably others),
but if something goes wrong, it gives the user more to go on and shows
up in the build log.
--DJ
Re: [aur-general] amiwm PKGBUILD file
On January 23, 2018 3:59:24 PM CST, Panayotis Katsaloulis via aur-general
wrote:
>Hello all
>
>This is my first attempt to create a valid PKGBUILD file for Arch
>Linux.
>It is about the missing amiwm window manager.
>
>Please tell me what you think
>
>
>
># Maintainer: Panayotis Katsaloulis
>pkgname=amiwm
>pkgver=0.21pl2
>pkgrel=1
>pkgdesc="An X window manager that tries to make your display look and
>feel like an Amiga® Workbench® screen"
>arch=('x86_64' 'i686')
>url="https://www.lysator.liu.se/~marcus/amiwm.html";
>license=('FREEWARE')
>source=('ftp://ftp.lysator.liu.se/pub/X11/wm/amiwm/amiwm0.21pl2.tar.gz')
>md5sums=('3a47e88e2be2978363220cf815ef')
>
>build() {
>cd "$pkgname$pkgver"
>./configure --prefix=/usr
>make
>}
>
>package() {
>cd "$pkgname$pkgver"
>make prefix="$pkgdir/usr" install
>rm $pkgdir/usr/bin/requestchoice
> install -Dm644 LICENSE "$pkgdir"/usr/share/licenses/$pkgname/LICENSE
>}
License should be custom, you should use $pkgver in the URL (will save you a
step when you update it), and you need to provide dependency info (at very
least Xorg, but most likely more).
HTH
--DJ
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [aur-general] "pepper-flash" naming?
On 11/13/2016 02:57 AM, Ralf Mardorf wrote: IMO it would be better to drop all flashplayer related packages from AUR, as well as from the official repositories. While I agree with you on principal, it's an unrealistic expectation. You can't expect a small business, who paid $1000s to a developer to have a web application made, one that still works well BTW, to again pay $$ to migrate this to html5 with no perceived benefit as flash player is still available and supported. When it finally breaks, sure. Unfortunately, (un)certain inevitability is a hard sell to the brass. --DJ
Re: [aur-general] "pepper-flash" naming?
On 11/13/2016 02:33 AM, Det via aur-general wrote: I decided it would be good to ask the mailing list directly, should "pepper-flash" [1] be renamed to e.g. "flashplugin-ppapi"? No. That has historically been the name. Anyone who is already familiar with flash on Liunx is likely to use "pepper" as a search term. Coincidentally, searching for "chromium-pepper-flash" (provides) using a keyword search in AUR Web does not give any results. I would have suggested requesting another provides as a compromise, but it seems that doesn't work as expected. Should it? --DJ
Re: [aur-general] Package merge on aur4
On 07/17/2015 08:29 PM, DJ Lucas wrote: Hi, I am adopting the sogo package, and already had the sogo-openchange and sogo-activesync packages. Nothing has been pushed in sogo-openchange nor sogo-activesync (nor sogo yet, though commit is ready to push). I'll be merging these three packages into a single split package. When trying to push to sogo, getting an error message: remote: error: cannot overwrite package: sogo-openchange In true SWAG form, I tried to "adopt" from their pages on the aur4 host with no change. :-) So, I'm stuck. Help? Please ignore this. I just found the previous thread on this topic, and requested a merge from the web form. Sorry for the noise. --DJ Lucas
[aur-general] Package merge on aur4
Hi, I am adopting the sogo package, and already had the sogo-openchange and sogo-activesync packages. Nothing has been pushed in sogo-openchange nor sogo-activesync (nor sogo yet, though commit is ready to push). I'll be merging these three packages into a single split package. When trying to push to sogo, getting an error message: remote: error: cannot overwrite package: sogo-openchange In true SWAG form, I tried to "adopt" from their pages on the aur4 host with no change. :-) So, I'm stuck. Help? Thanks in advance. --DJ
