[Resolved] AUR Packages are broken and we can't fix them. Here's what is going on.

[majestrate]

A while back, 2 separate members of the arch linux community packaged lokinet on the AUR which is great. Sadly both of these packages are broken but in different ways.
The lokinet aur package which builds from signed tarballs of tags sort of works except when it doesn't, we have some fixes we'd like to apply to that package but we can't as we have no way to suggest these changes to this packager. proppsed fixes are in this branch here: https://github.com/oxen-io/lokinet/tree/makepkg
The lokinet-bin package downloads static legacy builds meant for loki-launcher oxen-rancher, these static binaries exist for them and users are highly discouraged from using them for any reason. These builds do not have systemd enabled as that cannot be static.

update: lokinet package on aur looks like it is updated and working now. 🎉

[majestrate]

we have been granted co-authorship to the lokinet aur package. we are going to try to get lokinet into the main arch repos. i want to split the builds up so that oxenmq and oxenc are seperate so we can also package oxen-core. maybe we can also do session-desktop if we can contact the owner of that aur package.

update: the lokinet package will be updated for the 0.9.9 0.9.10 tag when it drops.

[peepo5]

progress?

[majestrate]

progress @jagerman ?

[jagerman]

It's on my list, but behind getting the current HF out and getting the new Lokinet GUI out on Linux/Windows/Mac.

[PixsaOJ]

So guys, can we fix PGP key issue on 0.9.9

[majestrate]

curl https://lokinet.io/jeff.asc | gpg --import

[majestrate]

also you can get the pubkey from github too, which is neato if you trust microsoft: curl https://github.com/majestrate.gpg | gpg --import

[Technetium1]

Chaotic-AUR has an open issue requesting this. When it's ready to build in a clean chroot, we would love to add it! chaotic-aur/packages#1515

[cathugger]

trivially fixiable
trivially fixable
i will look into this

i never said that it's not trivially fixable, just that it's a difference

signed tarball releases were only ever created to appease the aur pacakge that has been derelict for over a year now.

signed release tarballs are p much standard for other open-source linux software, though. you don't pull from git to build tor. nor you do that for i2p & i2pd. nor you do that for libsodium. nor openssh. why it's such a weird thing to have, and why did i even have to explicitly request it, and argument my position? makepkg needs to pull whole git history because it doesn't support shallow clones. it's unlikely you'd get into official repos with PKGBUILD that doesn't even lock sources to reproducible commit id. not to mention that it's useful for other distros, not only archlinux.
also [citation needed] for derelict for over a year now. there have been pauses but it's up to date now, and has been for a while. i'm doing it in my free time & when i feel like it. maybe it's the difference of understanding what a word derelict means for me & u.

username with a _ prefix is a debian-ism, not sure why one would want to do otherwise as it seems sensible to do so as to not conflict with possible local users.

out of all the packages i have installed with special users, none have _ prefix. I couldn't find anything in https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database with _ either. I can't see any specific written requirement anywhere that daemon users can't have _ prefix, but it appears that on archlinux none do.
I don't think it's a bad idea to use _ either tbh, but unless it's enforced across system it loses meaning and ends up as cognitive overhead only with no benefits.

we fixed that in something like the 0.9.6 tag at least which was over a year ago.

nah it wasn't detecting zeromq right up until 0.9.9 i think. iirc that wasn't an issue of lokinet, but of oxen-mq.

artifact of an older period in dev, fixing it is a one line patch and no reason to silo it off to just aur package. so much more on the table vs the little things like this that tend to pile up.

mhm.

we have yet to update the aur git repo to have the new files as for the longest of times we did not think we would be able to. this is easy to fix.

yeah i can be pain in the ass to deal with sometimes, but, like, you guys never displayed any hints that you'd do packaging for arch properly. I'm not even sure it was in your roadmap at all when i made that package. your attitude of "archlinux sucks" aint helping.

arch linux is lowest priority now because of the lack of ability to propagate fixes to current maintainers of that package. either we take it over so we can or we will be in an eternal stalemate.

it felt like it was lowest priority since forever, you just found more things to blame now i guess. AUR is user-contributed repo, but I'd like to believe that there are some standards for stuff I install, and I check before installing to ensure it's that way.
not pulling branches from git when there's no need to is one of them.
if you just want to make some stuff comfortable to install, please host archlinux repo.
it'll be way easier for users to add, they won't need to deal with AUR gpg mess. yes, it's a mess & user experience nightmare. I can probably disable checking of that tbh.
seriously, consider doing archlinux repo like you do for debian/ubuntus. users of that would need to install and research a lot less, and installation instructions would be as simple as:

# cat <<EOF >> /etc/pacman.conf

[oxen]
SigLevel = Optional TrustAll
Server = https://lokinet.org/arch/x86_64
EOF
# pacman -S lokinet

i have a very low opinion of the arch linux ecosystem as a result of this multi year saga.

i have a very low opinion of the lokinet/oxen project as a result of this multi year saga. see, i can do it too, say useless unproductive shit.

[majestrate]

I have no desire to interact further with arch linux users at this time. If you feel the same about lokinet please let us maintain it so you don't have to. I am tired of this being dragged out.

[majestrate]

arch linux users tend to go to the aur first so a broken aur package means arch linux users complaining to us that your package is broken. in order to provide "idiomatic" arch linux support, e.g. via a pacman repo this aur breakage needs to fixed. my frustration comes from the almost zero progress on this super basic fix for over a year. until this blocker is removed we cannot continue, i hope you understand this so we can fix this issue once and for all. in general, the prospects of going forward depend entirely on you @cathugger .

[cathugger]

please let us maintain it so you don't have to

i already gave maintainer role, but there was nothing done with it at all despite there being issues still, so i've fixed things when i saw them pointed out.
i try to maintain it still because i want it to succeed, that haven't changed.
i've just put out my reasoning for various fixations because i consider them important enough & in hopes that someone who is willing to help with maintenance will listen.
i'm tired of my shit being called broken when no issues are being pointed out, all i wanted with this package was to help the project, but i guess that's what i get when i try to isolate myself a bit because of too much crippling anxiety & depression.
guessing there's no forgiveness for being "arch linux user".

[jagerman]

Please, everyone, stop replying to this sub-thread; it has gotten out of hand and emotional and is not productive. We have the same goals here and can work towards improving the package.

I've started a new comment thread here to talk specifically about the packaging. Please leave baggage at the door.

[majestrate]

On Thu, 30 Jun 2022 20:11:32 -0700 Technetium1 ***@***.***> wrote: Due to limitations in the way we can package things, we have copied the pkgbuild here: https://github.com/chaotic-aur/pkgbuild-lokinet If there are ever any issues with anything please feel free to open an issue/PR there, or request it be updated on the packages repo: https://github.com/chaotic-aur/packages. For anyone else wanting this package you can find out more here: https://aur.chaotic.cx/

thank you, now if only we could propagate this to the main aur... that'd would fix the rest of our arch linux related issues.

[jagerman]

Re: @cathugger

seriously, consider doing archlinux repo like you do for debian/ubuntus. users of that would need to install and research a lot less, and installation instructions would be as simple as:

I had no idea such a thing existed. I'm not even understanding why people most people would muck around with AUR packages when proper repositories exist, and yet all I ever hear about Arch is that the AUR is the modern take on sliced bread. I think Jeff has a point, though: if people are coming to the package via AUR and find it, they're going to use that rather than go looking for Oxen's instructions on setting up a repo.

packaging in makepkg branch

For some perspective on our debian packaging, it lives in the debian/sid (and likewise for the other debian/ubuntu releases we build for, e.g. ubuntu/focal); those branches are managed with git-buildpackage, which manages patches, generates changelog entries from git history, etc., and is designed for just this sort of layout (with merges from tagged releases to make a new deb release). Since we're building those ourselves, it is easy to manage that way, but this isn't unique to us; git-buildpackage is used by a large number of git-based upstream debian packages, which is carefully designed to keep the packaging legit (e.g. it won't allow directly changes to anything outside of debian).

What this means is that the debian branches are always pointing at a release tag of the pristine sources + commits that add everything in the debian/ repository (and nothing else).

I have no idea if the AUR has anything like it; given how the actual AUR repository works (i.e. integrated into git), I suspect it does not. That's fine; I've no opposition to AUR lokinet packaging being in another repo distinct from the sources.

As to other questions/comments:

need to disable networking

What is requiring network access? If it's oxenmq then what is preventing it from picking up zeromq via pkg-config?

_lokinet

This is to comply with recommended Debian package practices; if that isn't common practice on platform x then we indeed shouldn't do it in packaging for platform x. As long as the user matches what is in the service and polkit files, it can be anything.

makepkg branch one doesn't include systemd as build dependency; apparently pkgconfig files for libsystemd aren't included in systemd-libs package (new name for former libsystemd package, it looks like) because archlinux maintainers are cursed or something probably idk idk

Where are they located then?

AUR PKGBUILD right now does sed -i 's/-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 //' CMakeLists.txt, because ...

Did you open an issue or contact someone about this so we could either address it, or explain why it's there? This particular case is probably not significant, but there are basically two things here: either 1) it is required for some reason, or 2) it is a bug. This is the kind of thing that really should have been filed as an upstream bug to avoid deviation between how it is packaged on different systems. E.g. if it's required then compiling without would break the package somehow; if it's not required, then we should fix it so that we aren't introducing subtle differences between linux distros.

Understand that, for an upstream dev, having packages built with significantly different compilation flags, or other substantial changes to how the package functions makes us more reluctant to support people on a modified platform.

Other things in the package (some of these apply to both versions):

• The systemd services are a bit strange here; it seems like several packaging tasks and commands are getting deferred out to a clutter of "services" that really aren't services, but are just package post-install steps:
  • the bootstrap service should go because it's really not a service: it's just deferring a packaging duty. We added the bootstrap file into the source as contrib/bootstrap/mainnet.signed, which should get installed with the package. Ideally it should go somewhere like /usr/share/lokinet/bootstrap.signed and lokinet should look there by default (currently it does not, but we want to change this for the 0.9.10 release).
  • the default config ought to be generated as part of a package build and then installed appropriately (into /etc). In the debian packages, we install the config to /etc/loki/lokinet.ini, and make /var/lib/lokinet/lokinet.ini a symlink to it. Thus the package manager properly deals with merging changes to this file with local system changes; the current AUR packaging approach is never going to update the file once it's created. All that said, we need (in lokinet) to better separate the config directory from the data directory, rather than the symlink hack currently used in the debian packages.
  • It looks to me like lokinet-resume.service is going to start lokinet after waking from sleep if it wasn't running before sleeping. Also doing this as a service seems a bit hacky; it would be better to drop a script into /usr/lib/systemd/system-sleep/ to record the status (e.g. touch /tmp/lokinet-was-active) when going to sleep, then start up (if it was running) when waking.
  • The lokinet-vpn@ template service is a bit weird from a user perspective, because it allows you to have multiple exit targets, but that won't really in any particular way (you'll end up just connected to the last one, despite all of them showing up as started). I'm not seeing how it makes a lot of sense to have a template service for this -- effectively the tool just becomes a wrapper around running lokinet-vpn yourself, but not in a way that adds much utility.
• Installing the .pkla file is almost certainly unnecessary on Arch; it's needed on Debian/Ubuntu because they are on a maintained fork of polkit 105 because of philosophical disagreement with putting Mozilla's fully fledged javascript interpreter into low-level system components (which happened in polkit 106). Technically we don't need the .rules file on Debian, but installing it anyway ought to be forward-compatible.

[jagerman]

/etc/loki/ is new config location? not /etc/oxen/ or /etc/lokinet/?

/etc/lokinet would be fine; we are mainly using /etc/loki for historic reasons and to avoid migration complications with existing deb updates.

bootstrap file is now embedded and basically whole service (and old bootstrap file) is unneeded, right?

Yes.

did you guys decide whether current lokinet-vpn is okay or you wanna change something

lokinet-vpn is still the current CLI tool for activating exit mode (aka "VPN" mode). We may change it at some point, but has not been changed for this release.

[cathugger]

lokinet-vpn is still the current CLI tool for activating exit mode (aka "VPN" mode). We may change it at some point, but has not been changed for this release.

eh the question was about lokinet-vpn service. whether it should take argument as config/env file or as %i. i didn't change anything from how it's packaged right now.

/etc/lokinet would be fine; we are mainly using /etc/loki for historic reasons and to avoid migration complications with existing deb updates.

ended up with /etc/loki as its short enough and comfy and doesn't clash with anything else and there will be less questions for people who are used to /etc/loki on other systems potentially.

[jagerman]

eh the question was about lokinet-vpn service. whether it should take argument as config/env file or as %i. i didn't change anything from how it's packaged right now.

Ah, I misunderstood. In Debian/Ubuntu packaging we don't have any separate service for vpn mode: rather you just run the lokinet-vpn command to control VPN mode from the CLI, or alternatively control it via the lokinet gui. Since lokinet's exit-connectivity is internal to the state of lokinet, it feels a bit weird to me to try to control it with an external service because of issues like the external service not being synced with the actual state of lokinet's exit connectivity.

That said, maybe there's a way to make that work better, i.e. by having the service be able to query lokinet to get the vpn connectivity?

If there is a service, I don't think it makes sense to have a @%i template because I don't see how you could reasonably have more than one %i value active at a time. If I started, say, [email protected] and then [email protected], what happens to the first one? These are a bit outside how I expect systemd templated services to work.

[cathugger]

other thread is gone or something, but i kinda wanna authoritative suggestion which one to use because https://github.com/oxen-io/lokinet/blob/makepkg/contrib/archlinux/lokinet-vpn%40.service is still doing %i so i'm just mimicing that one while waiting for confirmation as per #1823 (reply in thread)

I think we (i.e. lokinet team) probably need to think some more about how we want this to work, and then apply it in both this AUR & debian packaging.

[cathugger]

about what i think there: using %i allows easier way to use different exits, even if to start using different exit one needs to stop old service first, so there ARE some advantages compared to needing to edit config each time