Arch Linux User Repository

@redfish

I ran again namcap with current version (0.11.5.r27984.5541e2e3f-1). Below part of the result:

[...]

gnunet-git W: Referenced library 'openrc-run' is an uninstalled dependency

[...]

gnunet-git E: Dependency gst-plugins-base-libs detected and not included (libraries ['usr/lib/libgstapp-1.0.so.0', 'usr/lib/libgstaudio-1.0.so.0'] needed in files ['usr/lib/gnunet/libexec/gnunet-helper-audio-record'])
gnunet-git W: Dependency gmp included but already satisfied
gnunet-git W: Dependency libgcrypt included but already satisfied
gnunet-git W: Dependency libunistring included but already satisfied

Hi MrCue! We need a magic number (any number) because we need to synchronize the $_gnunet_guid and $_gnunetdns_gid variables in PKGBUILD with the same variables in gnunet.install. I am open to suggestions though!

--grufo

@grufo: Thanks for you AUR

A minor question for the PKGBUILD, why we have the guid as the 714 magic number? It blocks the building in my machine. After I change the guid to the one(619) in my machine, it builds happily.

package() {
    local _gnunet_guid=714                                                                                                                                                                
    local _gnunetdns_gid=715 
    ...
    if ! getent group gnunet > /dev/null || ! getent passwd gnunet > /dev/null || ! getent group gnunetdns > /dev/null || [[ $(stat -c %u "${pkgdir}/var/lib/gnunet") -ne ${_gnunet_guid}     ]]; then
    ...

@redfish

Thanks for removing the “already satisfied” deps and for adding zbar.

As for the “maybe optional” ones, it's hard to decide what to do. The official Arch package lists them as optional as well. On the one hand Arch developers might be wrong as anyone else, but on the other hand that means that likely no one has ever reported any crash concerning missing deps. I would keep things as they are, but I wouldn't bet it's the right choice.

About the version, I am not completely sure. Sometimes we might want to “force” users to perform an uptdate if a git revision solves important security bugs. We could do this also through pkgrel, but this in my opinion would not be semantically the right way.

@grufo: Good catch. Those are transitive deps (via libmicrohttpd->gnutls->nettle, etc). I removed them.

Re optional vs non-optional: maybe we should make those deps required if gnunet will really crash if you try to use that functionality but didn't install those packages.

Btw, gnunet-qr needs zbar. I added it (as optional, but perhaps it should be required since gnunet-qr is installed by default). zbar is only available for python 2 so I switched the whole build to python 2.

Re version: what I do for other packages is keep the version clean without the hash/revision, and bump the version only every time upstream release happens. So users will be notified of an update when release updates, but they always can rebuild the package to get latest master whenever they want. When committing, I just make sure to exclude the change to the version from PKGBUILD and .SRCINFO.

@redfish

I just launched namcap and, among other things, this is what I got:

gnunet-git W: Dependency python detected but optional (programs ['python'] needed in scripts ['usr/bin/gnunet-qr'])
gnunet-git W: Dependency libpulse detected but optional (libraries ['usr/lib/libpulse.so.0'] needed in files ['usr/lib/gnunet/libexec/gnunet-helper-audio-record'])
gnunet-git W: Dependency opus detected but optional (libraries ['usr/lib/libopus.so.0'] needed in files ['usr/lib/gnunet/libexec/gnunet-helper-audio-record'])
gnunet-git W: Dependency gmp included but already satisfied
gnunet-git W: Dependency libgcrypt included but already satisfied
gnunet-git W: Dependency libunistring included but already satisfied
gnunet-git W: Dependency libidn included but already satisfied

It seems to suggest to move python, libpulse and opus from optdepends to depends, and moreover it shows a weird message concerning gmp, libgcrypt, libunistring, libidn (“Dependency included but already satisfied”).

Any idea?

@redfish

Thank you very much for your help! Yes, this package had been removed and I used the official gnunet package as a new starting base. After your suggestions I fixed everything and I think that the gnunet user issue might be solvable by using fakeuser (https://aur.archlinux.org/packages/fakeuser-git/). I am going to send you an email with the updates for a test/review.

--grufo

The defaults.conf is out-of-date (for example, USE_LOCALADDR is no longer a valid option) and this file should be removed from the package, because the default configs are automatically installed into /usr/share/gnunet/config.d/*.conf. If the user wants to change the defaults, he should create a /etc/gnunetd.conf and define only the options he wants to override. (Similar usage model as systemd config files.) It's not good to have all defaults in this .conf in the package, because it will fall out of sync with upstream.

Option --with-nssdir no longer exists. Remove it, please.

Remove this too, these files are no longer installed: rm -rf "${pkgdir}/usr/include/libltdl" "${pkgdir}/usr/lib/libltdl".* "${pkgdir}/usr/include/ltdl.h"

The package version should still contain the major.minor.build version in addition to VCS revision height and commit hash, like so: 0.11.0.r123.gaabbccddeeff. Here is a corrected pkgver():

    local _ver=$(grep 'AC_INIT' configure.ac | grep -o '[0-9]\(\.[0-9]\+\)\+')
    printf "'${_ver}.r%s.g%s'" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

The recommendation printed by the configure script is to create a dedicated 'gnunet' user and a 'gnunetdns' group. It's not good to run as nobody because gnunet creates files, so those files should be owned by gnunet user. So, please add an install file to the package that will create the user, the gnunetdns group, and the /var/lib/gnunet. Also, then, add under [PATHS] one option SERVICEHOME = /var/lib/gnunet to the gnunet.conf in this package. Also, at the time of running 'make install' the group gnunetdns must exist, otherwise the permissions/ownership on some service executables are not going to be correct and they will fail to start. I am not sure what is the best way to do this, because creating the group in package() seems not conventional. If not that, then a alternative would be to patch up the ownership with chmod in .install, the disadvantage is that it duplicates upstream commands and will go out of sync with upstream.

Add shutdown command to .service and and add this to avoid issue with child process detection (I had some issue):

ExecStop=/usr/bin/gnunet-arm -e -c /etc/gnunetd.conf
GuessMainPID=no

I can provide a diff, if you prefer.

Btw, why was this package re-created and re-uploade? As a result the AUR comments were lost. Also it might be good to credit the original uploader in the contributors list: kertase kertase at gmail com