kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
frigginglorious has quit [Ping timeout: 268 seconds]
frigginglorious has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
<ocdtrekkie>
So yeah, that GitHub login issue sounds like it just needs Kenton to roll dependencies when the new package is released hopefully.
frigginglorious has quit [Quit: frigginglorious]
_whitelogger has joined #sandstorm
ocdtr_web has joined #sandstorm
<ocdtr_web>
Whitelogger is back! :D
<ocdtr_web>
Did I miss anything since I messaged on my alter ego?
larjona has joined #sandstorm
isd has joined #sandstorm
<ocdtr_web>
isd: Do you think your IRC app may ever return from the dead?
frigginglorious has joined #sandstorm
<isd>
If there's intrest.
<isd>
I wouldn't mind junking riot for IRC; my battery would be happy about having fewer electron apps to deal with.
<ocdtr_web>
Probably the biggest difference between when you were working on it and now is a bunch of us were on Oasis and couldn't run it.
<isd>
Yeah. and hopefull going forward even folks who are non admins will be able to just request irc.freenode.net:6697 from an admin in order to run it
<isd>
Right now it requests full network access, but it doesn't actually need that.
<ill_logic>
Y'all said that it would be valuable for me to figure out how to get Postgres started for my app, since other apps will use it.
<ill_logic>
I may have done it, and now I'm on to Apache, which may be harder. I'm curious if Apache has the same value?
<ill_logic>
I may have a workaround to avoid Apache for my app.
<ocdtr_web>
Biggest question I guess is how many apps specifically require Apache that we may want to package.
<isd>
I don't think apache is worth much. nginx is a well-trodden path and there's not much out there that needs apache.
<isd>
I'd say wait on bothering to work on that until we find something that we want that needs it.
<ocdtr_web>
I know Postgres has been the sole supported database for a bunch of apps people want in the future like Mastodon/Pleroma and the like.
<ocdtr_web>
Nginx is definitely the default way on existing vagrant-spk stacks.
<ill_logic>
I suppose if the number of apps that require Apache gets high enough someone will eventually figure it out.
<ill_logic>
The only reason Apahce is in the picture is something called mod_tile which is part of the "usual" openstreetmap tile server setup.
<isd>
Yeah, I'm sure it can be done, I just don't think it's that important.
<ill_logic>
There are alternatives, though the one I tried performed more shoddily. Maybe I could tune it though.
<ocdtr_web>
If you have Postgres figured out, I'd ideally love to figure out a good way to encapsulate that in a vagrant-spk stack.
<isd>
If you think it's going to be easier to get apache running than to get that working with something else, go for it.
<isd>
composable stacks would be a good thing.
<ocdtr_web>
(I think if people want to figure out how to make something work in a Sandstorm environment, vagrant-spk stacks are, at minimum, a good reference.)
<ill_logic>
Yeah, definitely the something else. Most of the docs that show how to run httpd without a supervisor say "BTW don't do this, just use a supervisor"
<abliss>
<isd "I wouldn't mind junking riot for"> There's a commnd-line matrix client (i think it's a weechat plugin). haven't tried it myself
<ill_logic>
Anyway, thanks. Moving on to the alternative then.
<isd>
np
<ocdtr_web>
isd: If we want to figure out what a composable stack should look like, we can always start building that alongside the existing setup. No need to move over all at once.
<isd>
agree.
<isd>
My first thought is to basically have mutiple setup.sh files (and friends), one for each component
<ocdtr_web>
Yeah, I agree. We can perhaps use a different folder or a prefix to the folders to indicate they are stack components rather than full stacks.
<ocdtr_web>
Then building a stack component is identical to building a stack. It's clean and understandable for people used to how vagrant-spk is built.
<ocdtr_web>
The biggest thing I am trying to wrap my head around is how to pull those in. How many components people should explicitly define.
<ocdtr_web>
Do we want to expect people asking for php+mysql to know they may also need to nginx+php+mysql?
<isd>
Maybe we could include meta-stacks that pull in more than one.
<ocdtr_web>
I mean presumably once this works well, we can still support setupvm lemp, but in the background it is doing nginx+php+mysql.
<isd>
yeah, that's my thinking.
<ocdtr_web>
I am probably mostly at the "I can maintain the general design/workings of vagrant-spk" level of proficiency, but I am a little scared about trying to rewrite how stacks are built. It might be beyond my level to assemble confidently.
<ocdtr_web>
So I am still trying to assemble "this is the exact itinerary of things vagrant-spk would need to do to do this" so I can determine whether or not I can figure out how to make it happen.
<ocdtr_web>
And as I noted on the issue, if ill_logic made a Postgres stack that just did Postgres with what he learned, that'd be pretty valuable. We could always convert it into a component once we have components.
<ocdtr_web>
Re: my comments on 3186, I can think of very few scenarios I've had a grain that just doesn't ever shutdown for really long periods of time. I'd love to implement backups when grains are not open.
ocdtr_web has quit [Remote host closed the connection]
<isd>
Agree.
<isd>
Though it would still be nice to fix the corruption bug.
<ocdtr_web>
isd: I think re: backups my primary concern is that if we do not have the resources to reinvent backup (which I'd argue we don't), we should pick a solution that is going to be most amicable to any number of external backup solutions.
<isd>
abliss: a newer version of Go should always work; they have an incredibly strict policy re: breaking changes (the policy is essentially "never").
<isd>
Can you point me to the exact commit it's trying to build?
<abliss>
yeah, looks like this weird message means the go install is messed up on the github worker. adding some diagnostics and running again...
<ocdtr_web>
When we're talking about app platform interaction, where the APIs we put in place are going to be potentially irreplaceable for years to come, I think it makes sense to ensure the design is very final. When it comes to things like making backups, I would much rather get a simple solution and we can always implement a better one later if we want to
<ocdtr_web>
write our own backup management features. I feel like shell features for Sandstorm moved extremely slowly for "the basics" even when Sandstorm had a full-time dev team.
<isd>
Yeah, +1 for starting with something simple.
<isd>
Ug, I've basically been fighting with tooling all afternoon. Making progress but getting the test app to actually import the right capnp files has been a bit of a nightmare.
<ocdtr_web>
abliss: Look at boringssl
<ocdtr_web>
Only thing that has Go, I think?
<abliss>
yeah it does appear to be during the boringssl build.
<ocdtr_web>
(I recall being peeved that Google decided their fork of a library not written in Go at all now depends on Go because they're Google and NIH.)
<ocdtr_web>
"The most recent stable version of Go is required. Note Go is exempt from the five year support window. If not found by CMake, the go executable may be configured explicitly by setting GO_EXECUTABLE."
<isd>
I mean, they do tell people explicitly that you probably shouldn't use boringssl, because they have no interest in making it suitable for outside users.
<ocdtr_web>
True
<isd>
I agree it seems kindof gratuitous, but I can also see the maintainability benefits vs. trying to put stuff together with C and shell scripts
<abliss>
so why does sandstorm?
<ocdtr_web>
What is Go's stable/unstable release policy?
<isd>
ocdtr_web: they never brake compatibility. ever.
<ocdtr_web>
abliss: Kenton was swayed by the significantly smaller threat footprint of BoringSSL, I believe.
<ocdtr_web>
Essentially, BoringSSL dumps all of the use cases Google doesn't want to support from OpenSSL, so a lot of potential vulnerabilities are deleted if BoringSSL meets your needs.
<isd>
Yeah. It's a bit of a pain to deal with stuff like the Go dep and the fact that they will remove stuff and break compatibility with no warning, but it's also much more secure than most other options.
<isd>
Despite the warnings, lots of organizations that have the resources to deal with the breakage use it anyway because of that.
<isd>
(including cloudflare)
<isd>
And they'll almost certainly never remove anything we actually *need*, since they're using it for web servers & browsers and our needs are pretty basic.
<abliss>
ugh, it's some weird mismatch of GOROOT and GOPATH and the versions of go installed on the runner by default
<isd>
Maybe uninstall the system Go before other stuff?
<isd>
Maybe easier to just set those variables explicitly.
<abliss>
GOROOT is probably my least favorite part of Golang. I've never, ever been able to understand what it does, why it's needed, or why it causes weird breakages all the time. i no of no such wart in any other language.
<abliss>
*know of
<abliss>
but yeah, it seems like `sudo apt-get install golang-go` breaks the (otherwise, seemingly functional) go install on the github runners. if I just remove that step, it gets past this blocker.
<isd>
Cool. Yeah, there's no real reason to bring in an extra toolchain
<ocdtr_web>
So is the solution to detect if go's installed before trying to install go?
<isd>
Yeah, that should do the trick. I'm sure it's possible to have both on the same system (as is the case on my laptop...), but there's no need for a system Go anyway
<abliss>
yeah, i'll use `which go || sudo apt-get install golang-go`
<isd>
abliss: do you need the conditional? seems like the build environment should be predictable wrt. what packages are installed.
<isd>
Also, I finally got the test app working with capnp. Christ that took longer than it should have.
<ocdtr_web>
My only thought was whether or not the build script is specific to Actions or not.
<isd>
I can die happy now.
<ocdtr_web>
I've already got one respondent from my mini-survey (disclaimer: I've sent it to two people so far) who specifically cited difficulty building Sandstorm automagically was a pain point.
<abliss>
i'd like to avoid baking assumptions about github's special brand of runner into the pipeline if possible.
<ocdtr_web>
That too.
<abliss>
it's kind of academic though, given that the pipeline is already encoded in github's special yml syntax.
<abliss>
and probably if someone else provides a compatible pipeline parsing environment, it'll probably have the same go setup.
<ocdtr_web>
I haven't looked into Actions much, but it seemed like the Docs yml was largely there to call the bash script. So my hope/impression was that getting building working on GitHub Actions would improve the experience for people building in general.
<isd>
I mean, in theory building should just be `make`, so I don't know if that's really going to help.
<isd>
But it would be really useful to get answers to where people got stuck.
<ocdtr_web>
I probably should try to build Sandstorm just to see what happens. Me being me, it's almost certain to end in disaster, but, you know, answers.
<ocdtr_web>
Temptation: Come up with some vagrant-spk-esque solution where we build Sandstorm in a VM we choose so we know it works for the purposes of people hacking on it.
<ocdtr_web>
Horrifying thought: Someone could hack on Sandstorm on Windows.
<isd>
There is a `Vagrantfile` in the root of the repo
<ocdtr_web>
So there is. It's not even that old, it's Stretch.
<isd>
Please do try to build sandstorm. If you get stuck, that will help us iron out some issues.
<isd>
I've hit problems using that as well, but in theory...
<ocdtr_web>
As a note: This Vagrantfile probably has a bug in it I fixed in vagrant-spk.
<ocdtr_web>
Is this Vagrantfile explicitly meant for using to build Sandstorm inside, or just install Sandstorm inside? ...Why is it here?
<abliss>
to build inside. see installing.md
<ocdtr_web>
Yup, it's got the same issue with Windows I fixed on vagrant-spk. I'll submit a PR.
<abliss>
i got one successful build to complete on the github runner (in 17m). now trying one with tests. also trying one with ccache enabled so repeated builds hopefully get faster.
<abliss>
my "make" prouced a file called `sandstorm-171.tar.xz`. anyone know where that 171 comes from? I tried to set it with `make BUILD=snapshot` but that didn't work