-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build and include notify_push for FreeBSD in every release too #153
Comments
I second this request. |
+1 |
For anyone interested how to setup notify_push under FreeBSD manually: Replace any NEXTCLOUD_ROOT with your own local path to Netxcloud. Requirements:
Instructions: nano /usr/local/etc/rc.d/nextcloud_notify_push
chmod +x /usr/local/etc/rc.d/nextcloud_notify_push Check if notify_push is running: Read how to setup reverse proxy (configure webserver): see section "Reserve proxy" for Apache and Nginx: su -m www -c "php occ app:enable notify_push" All green? Enjoy! See current metrics:
|
The best place for this request would actually be the FreeBSD project itself. By far the best home for binary builds for specific systems are the packaging systems of those distros. |
Curious, why isn't building for specific Linux distro's outsourced to the packaging systems of the Linux distro's? What is the harm in adding FreeBSD, while 3 Linux distro's are already compiled for?: With the above included, it would require zero effort after every Nextcloud upgrade. No action needed, because the compiled version for FreeBSD just exists, like it would for the Linux distro's. Wouldn't you agree @alerque? |
They should be. Indeed for many it already is: Arch Linux, Gentoo, LiGurOS, Parabola, Manjaro, and probably others. Notably OpenBSD packages this too.
Because cross compiling is full of pitfalls: it takes different expertise, different dependencies, and it doesn't integrate well with target OS release workflows. The OS has a better idea when something needs rebuilding (e.g. for glibc updates) than downstream projects like this. |
I contemplated the direction you're proposing. However, I see issues by not using the vanilla process with built-in NC updater, like troubleshooting. Likewise, the package has its own pitfalls: dependency conflicts to consider and manual checking of .htacess.dist with every upgrade. Still, notify_push is not included and needs to be built anyway. Also the backup from a non-standard webdata dir that the package uses needs consideration. And all FreeBSD users need to install and migrate to the new solution. So, after considering some examples, if I do as proposed: I keep my original issue, plus I get some extra issues. Concerning compiling: generically I understand, and from a C-perspective I understand, but with this use case with Rust, I don't. One compiler to rule all OSes. I fail to see the pitfalls, the needed expertise, the different dependencies and any integration issues in this Rust notify_push use case: Cross OS build and it works; the power of Rust. One build, help many. Where the Nextcloud release process itself knows when a new version is shipped. At least it would be helpful if a Nextcloud upgrade doesn't remove the current manual build of notify_push; prevents the need of rebuilding, at least keeps everything working. |
As someone who has been using benbenik's workaround for a while now, many thanks for the merge. I still have an issue, though: when I run occ:notify_push setup, the script reports "your system architecture(amd64) is not supported by the bundled binaries." FreeBSD reports its architecture as amd64 and not x86_64, which I guess is the issue here. |
Which NC version are you on? If the occ command gives you this error, maybe it need be handled within the NC codebase. Older versions did not gave this error that's for sure, but I used manual compiled binary. I'll need to do multiple NC version upgrades on servers, so I'll check the releases to find where(when actually) it is error rooted. |
I'm running 26.0.1 (26.0.2 hasn't hit the ports yet) on FreeBSD 13.2 (so, basically, the latest RELEASE and the CURRENT port). After some peering through, I think I get the problem. In Command/Setup, the line $output->writeln(" And pre-build binaries for x86_64, armv7 and aarch64 in the github actions."); (line 74) It should appear also between lines 105 and 106, and also mention the existence of the freebsd binary. I've created a pull request (PR #273 ). Note that this doesn't solve all the issues of using the setup wizard on FreeBSD as it then checks for Systemd, which is absent from FreeBSD. But once PR #256 is merged, this could be done |
I've checked #273 , it is handling the console outputs with additional text to include the FreeBSD (amd64) which is good to have. I think, what we need is to modify some functions in SetupWizard.php. At least hasBinary(), hasBundledBinaries(), which today directly sends the code to the "../bin/x86_64" directory. I believe we need to start from getArch(). I'll check the code, altought I'm not a coder for a living. Perhaps we can extend your PR to include the modified hasBundledBinaries() - the FreeBSD binary is under "../bin/fbsd_amd64" - , or at least my own previous builds were there. I'll crosscheck it |
I'll look into the code too. Thanks for checking. |
I have now updated getArch() and hasBundledBinaries() to report FreeBSD and find the binary under "../bin/fbsd_amd64". The next step for a fully working wizard would be to look into the systemd roadblock, but that depends on the merging of PR #256. |
Great, it seems to be good. Were you able to test it? |
I did test it. As mentioned, the setup daemon now fails with Anyhow, the weird thing is it went well, despite the typo, which has me puzzled. |
You're right, sorry. Good, I'm still working. I'll do test it too the weekend |
Note that it's unlikely that the release archives will include bsd binaries because the extra size that everyone will have to download doesn't seem worth it for the bsd install base. With updates to the setup wizard/instructions and pre-build binaries available for download it should still be doable to create a fairly fool proof experience. I also have no experience with any bsd (nor any desire to start), so while I'm open to merging bsd specific improvements I have no means of testing them. |
No worries, we'll cover the FreeBSD tests. Maybe this direction can be used to stip the actual release archive to have only one rust binary included (or none, it the setupwizard turns to be good enough for an included wget/curl step) |
@n-connect let me know if you want me to delve into the Setup wizard on my side. I haven't been touching it more for now as you said you'd delve into it, but I'm obviously happy to take my share. |
I've been working on changing the cross-compile setup used to build the binaries, can somebody verify that the freebsd binaries from https://github.com/nextcloud/notify_push/actions/runs/5377720649 work as expected |
It's starting and passing all tests in occ notify_push:self-test. Anything else to check? |
Nothing else, thanks for the verification |
Only asking just to make sure I am not doing sth wrong: the updated wizard is not yet available on the app store, is it? |
Sorry to bump, was just wandering if there is anything new....thank you very much for your work! |
First of, @n-connect: thank you for your effort! @thstyl2000 / @n-connect : I recently updated to Nextcloud 27 and have manually installed notify_push binary 0.6.6 ( notify_push-x86_64-unknown-freebsd ) from https://github.com/nextcloud/notify_push/releases after updating. The binary itself is working; great! I will in the future explicitly check whether notify_push binary remains after an update. However: Rescan did result in the same notice. I read about possibly including the /usr/local/rc.d/ service script in releases in issue #256 in the future: nice progress! |
I've updated the build setup which required some changes to how the FreeBSD binaries are built and would appreciate it if somebody can test the binaries from https://github.com/nextcloud/notify_push/actions/runs/9407127052?pr=466 |
It seems fine! Binary build is the same as previous using file, and runs:
Replacing the binary the service runs, it listening on the port:
Log before nextcloud app update:
After:
One question though: what to do, if I'm running the |
Is your feature request related to a problem? Please describe.
Nextcloud notify_push is great, but it is included for Linux aarch64, armv7 and x86_64 only. FreeBSD is missing, while it can easily be included in the Nextcloud release process. I feel a bit frustrated to build notify_push and testing with occ with every Netxcloud update myself; mundane work that can be automated to benefit all FreeBSD admins.
Describe the solution you'd like
Include fbsd_amd64 or fbsd_x86_64 in directory:
/NEXTCLOUD_ROOT/apps/notify_push/bin/
Execute in the release build process (generic FreeBSD fits-all):
cargo build --release --target=x86_64-unknown-freebsd
Describe alternatives you've considered
Manually running
cargo build --release --target=x86_64-unknown-freebsd
, moving compiled push_notify to correct location and re-running occ to check whether all is ok over-and-over again every update.Additional context
No other context. Except a "thank you" for considering!
The text was updated successfully, but these errors were encountered: