Package Details: snac 2.70-1

Git Clone URL: https://aur.archlinux.org/snac.git (read-only, click to copy)
Package Base: snac
Description: A simple, minimalistic ActivityPub instance
Upstream URL: https://codeberg.org/grunfink/snac2
Keywords: activitypub fediverse mastodon
Licenses: MIT
Submitter: ogarcia
Maintainer: ogarcia
Last Packager: ogarcia
Votes: 2
Popularity: 0.47
First Submitted: 2022-11-30 10:33 (UTC)
Last Updated: 2025-01-31 09:55 (UTC)

Dependencies (1)

Required by (0)

Sources (4)

Latest Comments

kseistrup commented on 2025-01-26 10:50 (UTC)

OK

ogarcia commented on 2025-01-26 09:24 (UTC)

Personally I don't want to change the build options because of the Arch Linux philosophy that says that the package should always be as faithful to the upstream as possible.

If the author of snac considers it best to compile by default with -DWITH_LINUX_SANDBOX then he will include this option in the makefile and this package will have that option (which I understand that right now it does not because, I quote specifically from the README: It's still a bit experimental).

kseistrup commented on 2025-01-26 08:39 (UTC)

@shtrophic Communication is hard, and I failed.

I copied the “v2.68+ and Linux kernels older than 5.13.0” from the README just to show that my suggestion would be valid here (since we had snac v2.68 and kernels older than 5.13.0). I should have taken the path of Python Zen: explicit is better than implicit. Mea culpa.

When I suggested that the -DWITH_LINUX_SANDBOX definition be added to $CFLAGS in the PKGBUILD, it was because the $CFLAGS is taken from /etc/makepkg.conf and not from the environment, and I feel it is wrong to add a package-specific option to the general compiler flags. I rarely install packages separately, and when I call yay it will upgrade ArchLinux proper and AUR packages in the same session, and so the -DWITH_LINUX_SANDBOX would be given to every AUR build. Imagine if we added specific options for all AUR packages to the global makepkg.conf, that would hardly end well.

Summary: We have alle the versions necessary for letting snac use Linux sandboxing, and it will hardly harm anyone to build snac with -DWITH_LINUX_SANDBOX as people can turn off sandboxing in the configuration file if they don't like it. The other situation, that sandboxing isn't compiled into the binary, makes sandboxing unavailable for everyone — whether they like it or not.

Arguing always makes me very tired, and I recognize the package maintainer's right to author the PKGBUILD file as they see fit, so rather than having a lengthy discussion here I preferred to just use my own local PKGBUILD file.

Cheers.

shtrophic commented on 2025-01-25 20:02 (UTC) (edited on 2025-01-25 20:03 (UTC) by shtrophic)

@kseistrup, @ogarcia

I think you misunderstand. A linux kernel >= 5.13.0 is required to have sandboxing. linux as well as linux-lts in the repos support this. Only kernels older than 5.13.0 cannot be compiled with landlock sandboxing. So it should be OK to add this flag.

kseistrup commented on 2025-01-24 12:10 (UTC)

@ogarcia Very well.

ogarcia commented on 2025-01-24 12:02 (UTC) (edited on 2025-01-24 12:20 (UTC) by ogarcia)

@kseistrup The kernel you are talking about is quite old and it does not make sense to set by default options that will not be used in standard Arch Linux installations (even using linux-lts).

Besides, you can do this export yourself if you have problems before calling makepkg.

kseistrup commented on 2025-01-24 11:30 (UTC)

@ogarcia

With snac v2.68+ and Linux kernels older than 5.13.0, could we have Linux sandboxing compiled into snac? It's as simple as changing the build() function slightly:

build() {
  cd "${pkgname}2"
  export CFLAGS="$CFLAGS -DWITH_LINUX_SANDBOX"  # Enable Linux sandboxing
  make
}

It can be controlled by disable_sandbox in the config, but I'm incompetent to read from C source if there is a default value or what will happen in that entry is missing from the config.

Cheers.

kseistrup commented on 2023-04-24 13:57 (UTC)

@ogarcia Thanks.

ogarcia commented on 2023-04-24 13:40 (UTC)

@kseistrup glibc, gcc-libs and openssl dependencies are implicitly satisfied by libcurl.so

kseistrup commented on 2023-04-24 13:16 (UTC)

The namcap tool seems to indicate that further dependencies are necessary: gcc-libs, glibc, and openssl.