Lifting the gotosocial amd64 restriction #143
Comments
|
I've followed that discussion, but didn't see that there's a go build-tag for that now. |
|
@daenney is the restriction limited to 64bits still, or what's the limitation now? |
|
The tag is now turned on as an option by default in the pkgsrc package, can be turned off in custom builds. |
|
It should be fine on 32-bit and 64-bit platforms currently. The wazero WASM runtime should be fine, and afaik there shouldn't be any issues with the SQLite driver either. So I would expect netbsd/386, netbsd/amd64, netbsd/arm and netbsd/arm64 to work. However, I don't think anyone's tested 32-bit GtS on anything other than Linux. It's the only platform we ship 32-bits builds for as well, and only on ARM. |
for more architecture support. # - wasmsqlite3: uses SQLite through WASM instead of the C-to-Go transpilation (experimental) #143: There was initially an issue with that driver on the BSD family but that was resolved in the driver before we cut this release. It's safe to use and expected to perform just fine. We're currently keeping it behind a go build tag, wasmsqlite3, and we do consider it slightly experimental. However, the plan is to switch to this Soon™ and a number of people including two of the maintainers run this build on their own instances without any issues.
This is a point release intended to clear up a couple of CVEs and apply point fixes that have been accumulating since 5.2.1 There are a few unresolved (but minor) memory leaks related to design issues in the API that still need to be resolved. Expect those fixes in the next release. Code Fixes ---------- * Fixes for CVE-2023-48161, CVE-2022-28506, * Address SF issue #138 Documentation for obsolete utilities still installed * Address SF issue #139: Typo in "LZW image data" page ("110_2 = 4_10") * Address SF issue #140: Typo in "LZW image data" page ("LWZ") * Address SF issue #141: Typo in "Bits and bytes" page ("filed") * Note as already fixed SF issue #143: cannot compile under mingw * Address SF issue #144: giflib-5.2.1 cannot be build on windows and other platforms using c89 * Address SF issue #145: Remove manual pages installation for binaries that are not installed too * Address SF issue #146: [PATCH] Limit installed man pages to binaries, move giflib to section 7 * Address SF issue #147 [PATCH] Fixes to doc/whatsinagif/ content * Address SF issue #148: heap Out of Bound Read in gif2rgb.c:298 DumpScreen2RGB * Declared no-info on SF issue #150: There is a denial of service vulnerability in GIFLIB 5.2.1 * Declared Won't-fix on SF issue 149: Out of source builds no longer possible * Address SF issue #151: A heap-buffer-overflow in gif2rgb.c:294:45 * Address SF issue #152: Fix some typos on the html documentation and man pages * Address SF issue #153: Fix segmentation faults due to non correct checking for args * Address SF issue #154: Recover the giffilter manual page * Address SF issue #155: Add gifsponge docs * Address SF issue #157: An OutofMemory-Exception or Memory Leak in gif2rgb * Address SF issue #158: There is a null pointer problem in gif2rgb * Address SF issue #159 A heap-buffer-overflow in GIFLIB5.2.1 DumpScreen2RGB() in gif2rgb.c:298:45 * Address SF issue #163: detected memory leaks in openbsd_reallocarray giflib/openbsd-reallocarray.c * Address SF issue #164: detected memory leaks in GifMakeMapObject giflib/gifalloc.c * Address SF issue #166: a read zero page leads segment fault in getarg.c and memory leaks in gif2rgb.c and gifmalloc.c * Address SF issue #167: Heap-Buffer Overflow during Image Saving in DumpScreen2RGB Function at Line 321 of gif2rgb.c
Since GtS 0.16.0 there is a way to build with a SQLite driver that we access through WASM, which would lift the amd64 restriction currently in place as a consequence of using the modernc transpiled driver:
pkgsrc/www/gotosocial/Makefile
Lines 69 to 78 in eaf7753
There was initially an issue with that driver on the BSD family but that was resolved in the driver before we cut this release. It's safe to use and expected to perform just fine.
We're currently keeping it behind a go build tag,
wasmsqlite3, and we do consider it slightly experimental. However, the plan is to switch to this Soon™ and a number of people including two of the maintainers run this build on their own instances without any issues.I'm not familiar enough with how pkgsrc works, but if there's some kind of way to give people the option to try it out if they want to run on aarch64, this could be a way of achieving that already before the next release.
Getting any feedback on whether this build works out well for folks running it on NetBSD would also be very helpful.
// cc @nikkicoon
The text was updated successfully, but these errors were encountered: