Hey, I’m the author of the SyncTERM BBS terminal software, and I’m getting ready to release a new version. Since one of you previously offered a Haiku package (Hi @arfonzo!) I figured I would make the support official and be sure it sucks the least amount possible for Haiku users.
Currently, I’ve got it building and running well on Haiku R1/beta5 installed in a VM, and am working on the .PackageInfo file, but there’s a couple issues I’m unsure of or unable to fix.
The first issue was that there isn’t a “Downloads” folder in Haiku, so I have SyncTERM defaulting to save downloaded files to the desktop, which feels messy to me.
The second (and bigger) issue is that I’m not an artist. I hacked together a simple and ugly icon as a .png file that’s served me well over the years, but Haiku doesn’t really want raster icons, and Haiku icons have a distinctive look that my hacked together icon doesn’t come close to matching. It was suggested in IRC that I ask in here for help, so if you are interested in helping improve SyncTERM on Haiku, and have the skills to design an icon, I would really appreciate the help!
I tracked down the icon @arfonzo created in 2012 and added it… it’s mostly the same as the PNG icon from the package, so it’s not ideal, but at least now the need isn’t as dire.
You may want to consider creating a haikuporter recipe . That would allow rebuilding when needed without you having to do it manually if anyone reported a problem that could be easily solved by a rebuild. If you submit it to haikuports, the package would also automatically appear in HaikuDepot.
Agreed. Best solution IMO is to provide the user a setting within your app to choose a download location.
My skills in that department are hit and miss…
If you posted the icon, people (hopefully more skilled than me) could give it a try.
You may want to consider creating a haikuporter recipe
I did, but it seems like it’s much more complicated than simply writing a script that shuffles the files into an appropriate directory then runs the package tool.
Generally speaking, I don’t submit port-like things to OSs that I don’t run… I figure that someone who actually runs the OS will do a much better job than me, and I don’t need to go chasing all the Linux distros down myself every time I do a release.
I have SyncTERM defaulting to save downloaded files to the desktop, which feels messy to me.
Agreed. Best solution IMO is to provide the user a setting within your app to choose a download location.
Yeah, that’s what it does, but the default location is the desktop.
If you posted the icon, people (hopefully more skilled than me) could give it a try.
I mean… I’m certainly not married to the current look of the icon, I’s just something I whipped up in five minutes because I needed one, but I’ll attach it here if I can figure out how.
As I mentioned though, @arfonzo created one a long time ago, so I’ve managed to find it and keep using it (in the package now).
I’ve uploaded the .hpkg to SourceForge now, so you can see the package in all its glory.
Usually when I do releases, I only pre-build binaries for macOS and Windows with the assumption that every other OS will build from source and have their own packaging thing. I’ll likely leave Haiku to build from source for future releases, but since 1.2 will be the first one with official Haiku support, I figured could whip up a package.
Fair. Also, from your package it should be a quite simple recipe. There’s only the binary and its dependence on sdl2. @Begasus should be able to whip one up while his dog crams for the next exam in doggie-sunday-school…
Good enough in my book. If the users get annoyed by files downloaded to the Desktop they’ll change it.
So interestingly, there is not stable a source archive for Haiku yet… the rc2 source archive on SourceForge does not have the latest CMake/code changes for Haiku, and rc3 won’t be released until this weekend.
The nightly source archive can be found here, but it changes every night so isn’t a good thing to use for a port, but maybe it’s enough to get the port written and ready for the release (likely two weeks from now, now that I need to do an RC3).
The git repo it lives in has a syncterm-1.2 branch which will become the release once it’s done, but there’s two issues with that… first, the tag doesn’t exist since 1.2 isn’t released yet, and second, the git repo has way too much extra stuff in it… the source tarball will be what you want to use for the port for sure because it only has what you need.
There’s only the binary and its dependence on sdl2.
It would maybe be nice to include the PDF manual as well if threre’s a place people would know to look for it, but the asciidoctor-pdf Ruby gem doesn’t seem to exist in ports, so it can’t be easily built on a Haiku system (didn’t look if Ruby has been ported).
PackageInfo(.in) should only be used while doing manual packaging, if you would like it to end up in a recipe it’s useless (it contains almost the same things as in the recipe to build the package with haikuporter).
EDIT: with haikuporter creating the package it will also include this file (you can see this if you extrack a *.hpkg file with Expander).
There is a hrev file in the source, probably done on the prior packaging, using that and a bit of adjusting it looks not that bad. PS, today’s nigtly archive worked out ok and I did a first draft of packaging it with haikuporter.
I don’t know the details on how to use it so maybe I could upload the package somewhere so you could check it out and comment if anything is missing?
Next, the license is incorrect. The program is being distributed under the GLPv2 license. While the Sleepycat license is available for the Cryptlib library, due to the combination with other licenses, the work as a whole can only be distributed under GPLv2, the additional Sleepycat terms cannot be used.
Finally, I’m unable to actually install the package presumably because I don’t know Haiku well enough… it says it needs to upgrade the haiku and haiku_devel packages, but it fails to download them. I assume that’s just a problem with me running the current release and needing to upgrade my install or something.
Those are always the tricky ones when not stated elsewhere, so I checked the LICENSE file and the copyright, indeed one was for cryptlib (but that’s included/used) that is included in the source?
Hence I wrote wip very early stage and comments on those are appreciated but someone knowing all about the matter. (this counts for COPYRIGHT and LICENSE).
I’ve build this on R1B5 with latest updates installed, there is an issue with a checksum error on latest updating for that (guess I got lucky on that). if you can install/use a nightly the hrev shouldn’t be a problem.
Yeah, the COPYING file in src/syncterm describes the work as a whole (ie: can be copyied/modified under GPLv2, some parts are LGPL, and cryptlib is Sleepycat).
I’ll see about getting the right hrev installed over the weekend and get back to you about proper functioning.
