Hello Alad, Hello Dan Thank you very much for your ideas. I just pushed a new version of the PKGBUILD here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qjournalctl Are there further improvements? The point with the substitutions of $pkgver seems very handy to me! Thank you! Dan B via aur-general <aur-general@archlinux.org> schrieb am Sa., 13. Aug. 2016 um 21:58 Uhr:

Remove the "make -j 9" line. I'll review the rest in a sec

On Aug 13, 2016 2:47 PM, "Patrick Eigensatz via aur-general" < aur-general@archlinux.org> wrote:

...

Hello folks!

I am a beginner in Arch packaging but I just came to a stable point writing my small systemd journal analyzer and beeing a Arch user for some years now I thought it would be a good exercise for me to write a PKGBUILD for my program and try to upload it to the AUR.

It is now online @ https://aur.archlinux.org/packages/qjournalctl/

I followed the wiki guidelines @ https://wiki.archlinux.org/index.php/Arch_User_ Repository#Submitting_packages

I read myself into the @ https://wiki.archlinux.org/index.php/Arch_packaging_standards and into @ https://wiki.archlinux.org/index.php/PKGBUILD

and I tried to follow all the suggestions there and I kept my PKGBUILD as tiny as possible.

I also runned namcap to check my PKGBUILD respectively the generated package. As I had some dependencies (namely qt5-base and gcc-multilibs) I listed them in the PKGBUILD.

I tried to have a look at other PKGBUILDs as well and to compare it to mine but I could not find something which would really differ from my first trial.

Then I read I could ask here for suggestions and improvements. Is there something I didn't do which is e.g. a good habit? Or did I something that I shouldn't have done?

I hope some experienced AUR packagers / TUs can give me a few points I can work on. Feel free to give me feedback on my program as well! ;)

Thank you very much! Patrick

* Patrick Eigensatz via aur-general <aur-general@archlinux.org> [2016-08-13 20:18:05 +0000]:

Thank you very much for your ideas. I just pushed a new version of the PKGBUILD here:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qjournalctl

Are there further improvements? The point with the substitutions of $pkgver seems very handy to me!

Why do you have both md5sums and sha256sums set? One of them should suffice ;) Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

Op 13.08.2016 om 22:39 schreef Patrick Eigensatz via aur-general:

@Alad:

Thanks, I changed this as well!

@Florian: I thought if there was a variable for both I'd set both :) Should I remove the md5sum? Is there a guarantee every Archsystem has the md5sum and/or the sha256 command available?

Another question just popped in my mind: How does namcap find dependencies of my package? How I can I be sure it discovered all and I didn't forget one? md5sum and sha256sum are owned by the same package. You can check this by specifying their path to "pacman -Qo".

If you want to know how likely it is that users have certain package installed, you can check the statistics. https://www.archlinux.de/?page=PackageStatistics Regarding dependencies and namcap, this should be the relevant code: https://git.archlinux.org/namcap.git/tree/Namcap/rules/sodepends.py https://git.archlinux.org/namcap.git/tree/Namcap/rules/shebangdepends.py P.S. If you plan on posting more regularly to these lists, you should change your mail client settings to "bottom post". For Thunderbird, this is explained here: https://support.mozilla.org/en-US/kb/reply-above-or-below-quoted-text

Am 15.08.2016 02:57 schrieb "Eli Schwartz via aur-general" < aur-general@archlinux.org>:

On 08/13/2016 03:47 PM, Patrick Eigensatz via aur-general wrote:

...

Then I read I could ask here for suggestions and improvements. Is there something I didn't do which is e.g. a good habit? Or did I something that I shouldn't have done?

Including the feedback you have already received, it looks pretty good

now.

But I would note a couple additional things:

gcc-libs is part of the base group, and gcc is part of base-devel. Neither should ever be listed as depends (or makedepends, respectively), since it is assumed all users have gcc-libs installed and gcc is a prerequisite to running makepkg.

I don't usually see people running shellscripts using `sh $shellscript` -- it is usually `./$shellscript`. It really makes no difference (practical or otherwise) except for looking odd...

As Florian Bruhnin said, md5sums is not needed, you only need one checksum validation. The tools for every validation method (or anything else built into makepkg itself) will always be required for makepkg via the base/base-devel or pacman dependencies. In addition to the most common build tools like gcc/make/patch/autotools/libtool. sha256sums is always superior to legacy md5sums so stick with that.

If you want to further variableize your PKGBUILD, you can use $pkgname in the url as well, I usually do. (Sometimes this will allow a lot more copy-pasting of existing PKGBUILDs, the rest of the time it just highlights the relationship between the pkgname and the upstream url.) This really is just a style preference though.

-- Eli Schwartz

@Eli Thank you for explaining this to me! namcap showed gcc-libs-multilib as a dependency. I chose to add gcc-libs but I did not know it would already be installed as a prerequisite. Maybe this is something in namcap we could improve then? I'll remove the md5sums soon, so I'll stick to sha256. Also I'll try to variableize the url etc. as well - seems legit to me to take this PKGBUILD as a template for further projects. I usually do run my shellscripts via ./ too, but when I experimented with makepkg I experienced some errors and I wasn't sure if makepkg would know how to interpret ./ so I wrote sh. I'll change this back soon. @Christoph Indeed, although my autogen script is so simple it probably wouldn't even matter if you run it with bash or only sh. If extracted correctly out of the source .tar.gz the executable bit should already have been set. -- Patrick

Eli Schwartz via aur-general <aur-general@archlinux.org> schrieb am Di., 16. Aug. 2016, 15:10:

On 08/16/2016 06:54 AM, Patrick Eigensatz via aur-general wrote:

...

I usually do run my shellscripts via ./ too, but when I experimented with makepkg I experienced some errors and I wasn't sure if makepkg would know how to interpret ./ so I wrote sh. I'll change this back soon.

What kind of errors? Since the two formats should be exactly the same unless the shellscript is not marked as executable... This may just be a style nit, but mysterious errors aren't a style nit -- they are something you should understand, rather than simply avoid.

Oh, another "good practice" suggestion:

For the source array, use source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")

This will rename the source tarball so it won't clash with other downloads, since GitHub uses the same style of pkgver-based url locations (with content-disposition, which makepkg doesn't respect, to rename it properly).

Why does this matter? Only because if someone uses a common $SRCDEST (see `man makepkg.conf`) they might have a different file with the same name which makepkg will assume is the file it wants (then fail the integrity check).

-- Eli Schwartz

No, the errors I experienced were all PKGBUILD syntax related mistakes; also I didn't know I could use full bash syntax in the PKGSRC file this is why I "extended" ./ to sh to eliminate possible error causes I would not have been aware of. Yes, indeed the github downloads all look the same. I'll implement your suggestion soon, thank you! -- Patrick

Eli Schwartz via aur-general <aur-general@archlinux.org> schrieb am Di., 16. Aug. 2016, 19:24:

On 08/16/2016 01:12 PM, Patrick Eigensatz wrote:

...

No, the errors I experienced were all PKGBUILD syntax related mistakes; also I didn't know I could use full bash syntax in the PKGSRC file this is why I "extended" ./ to sh to eliminate possible error causes I would not have been aware of.

Well, if it helps your understanding... :)

makepkg is written in pure bash, and will source the PKGBUILD then use the bash variables and functions defined in the PKGBUILD in order to build the package. So yes, anything bash will work.

(You are also guaranteed that anything defined in libmakepkg is available for you to use.)

Granted, makepkg will run additional checks to make sure that the makepkg-specific variables/functions conform to what makepkg expects. eg. checking that things which need to be arrays aren't (lazily) strings instead.

-- Eli Schwartz

Thank you very much for your explanation! I'll try to improve things as soon as I've got some time. (Fortunately I received a pull request for some code in my program which I was quite happy about - although I'm currently a bit "out of time" so I'm very grateful for your patience and feedback!) -- Patrick