[INFO] Arch Linux AUR package

[frostworx]

Thank you very much for maintaining the project! I discovered just a few days ago and did not even know that the original project was killed silently (imho the project page should at least be set to read-only and point to this project).

For the Arch Linux users here, I just created a release package in AUR which uses this active fork

https://aur.archlinux.org/packages/neolink

(added a conflict with the old "-git" package, which uses the dead project as source)

Any comments/suggestions/contributions welcome.

[QuantumEntangledAndy]

It would be nice to add an archive and a link to the main page but ThirtyThreeForty hasne't respond to my last few attempts to contact him.

The next release will likely add a few more dependencies during build including the proto buffer compiler and openssl.

Neolink will also not run very well without the extra gstreamer plugins. I'm not sure how much of those plugins are pulled in with the gst-rtsp-server you've added. But for debian you will need the ones listed in the readme

[QuantumEntangledAndy]

Any chance we could integrate the AUR package into the realease build action with something like this

[frostworx]

Thanks for the prompt reply and the suggestions. Will take a look into it in a few days when I return from a short trip.

[QuantumEntangledAndy]

Maybe we should also contact @zhulic from the original PR too https://github.com/thirtythreeforty/neolink/pull/168

[frostworx]

I already did on his git package, but nice to see him here as well :)

[frostworx]

Just bumped the deps. Can't tell if and when I find the time to look into the aur-release stuff mentioned above

[QuantumEntangledAndy]

Could you send me a copy of the PKGBUILD you use and then maybe I can have a go at it

[QuantumEntangledAndy]

If possible I'd like to adopt neolink and neolink-git directly into this repo so that versions are updated automatically when a new release gets made

[frostworx]

The PKGBUILD can be found on the top right of the corresponding package page below Package Actions.

When dependencies do not change, -git packages usually do not have to be touched at all to stay functional, and for release packages it is as easy as adjusting the version number. I am uncertain if it is worth the time to work on an automation for this simple task.

[QuantumEntangledAndy]

It is not about the time required. Overall an automation will reduce time, it is about keeping things up to date

[QuantumEntangledAndy]

I've flagged neolink-git as out of date and I'll see if I can pick it up

[frostworx]

Previous maintainer orphaned the git aur package. I took over and just bumped a new version pointing to this project.

[mothdotmonster]

Both packages appear to be broken, at least for me.

neolink almost manages to build, but gives an error of /usr/bin/ld: final link failed: bad value neolink-git doesn't even download, saying ERROR: Integrity checks (sha256) differ in size from the source array.

[QuantumEntangledAndy]

I think there's a couple of missing packages that are needed. OpenSSL and protobuf

[QuantumEntangledAndy]

@frostworx do you have time to look into this?

[QuantumEntangledAndy]

I think these are needed as they are what I have on my arch and the neolink AUR build fine there

• openssl-1.1
• protobuf

[frostworx]

@QuantumEntangledAndy I'll try to check it shortly. Thanks for the dep pointers!

(I don't use neolink anymore though, so might orphan the pkgbuilds midterm)

@mothdotmonster stable is still on 0.6.2, which built fine last time I tried. Is your problem reproducible in a clean chroot?

[QuantumEntangledAndy]

If you want to transfer ownership of the AUR please transfer it to QuantumEntangled https://aur.archlinux.org/account/QuantumEntangled

[frostworx]

• just pushed a new neolink-git pkgbuild edit: ~(I was able to reproduce the sha256 issue reported above) can't test it, as it is not yet available yet~ the bump is available and I can still reproduce the issue -> not fixed yet

• I was a able to successfully build the stable neolink package (without a chroot), so I suggest to test it again and provide some logs when it fails - ideally on the AUR url and not here

• protobuf might be a useful/required dependency missing in the PKGBUILD, but are you sure openssl-1.1is? seems like a barely used fallback openssl installation

• always a good choice when upstream maintains their project on their favorite distri. I'm not sure if I can transfer the packages directly to you, but I'll let you know when I orphan them, so you can adopt them afterwards.

[frostworx]

@QuantumEntangledAndy just added you as co-maintainer for both packages. I'd guess you'd automatically become maintainer when I'd drop them.

[frostworx]

just pushed another neolink-git update. should work please test and report back when package 0.6.3.rc.1.r34.gd354b90-3 has landed - needs some time to distribute

edit: the change just landed and built fine for me

$ /usr/bin/neolink -V
[2024-04-16T14:31:16Z INFO  neolink] Neolink v0.6.3.rc.1-34-gd354b90 release
neolink 0.6.3-rc.2

[QuantumEntangledAndy]

• are you sure openssl-1.1is? seems like a barely used fallback openssl installation

Fairly sure since we need 1.1 not 3. We depend on fcm-push-listener for a push notifications server, that depends on ece for push message formats, which depends on OpenSSL 1.1 as their backend. So although I'd like to use v3 it's not in my control as it's upstream.

[QuantumEntangledAndy]

What's the plan for versioning the AUR. neolink is binaries, neolink-git to the last rc release? Pointing to HEAD is not always a good idea as the tip of the branch is sometimes a little buggy until I can test thing out.

[QuantumEntangledAndy]

Also I notice you have the ARCH as x86_64 but we should be good for arm too

[frostworx]

What's the plan for versioning the AUR. neolink is binaries, neolink-git to the last rc release? Pointing to HEAD is not always a good idea as the tip of the branch is sometimes a little buggy until I can test thing out.

No,

• neolink should be that last stable release (built from source)
• precompiled binaries should be offered in a separate neolink-bin package if really required
• neolink-git is meant to build from latest git master source (when installing git packages the user has to be aware of instable, incomplete, broken builds can be possible anytime - there is no $guarantee that a git package always builds correctly - it is no upstream issue at all, only particularly a package maintainer issue for example when the PKGBUILD needs updates or a valid bug/issue was reported)

release candidates historically are not covered via package management at all, no idea though if this still is $best_practice

Also I notice you have the ARCH as x86_64 but we should be good for arm too

yeah, I only added x86_64, because it was the only platform where I tested the build. this happens pretty often in (community driven) packages distri-independant.

Feel free to add armv7 (or whatever string is used currently, I don't have productive Arch arm systems currently) and also openssl-1.1 for both packages (thanks for the heads-up above regarding 1.1)