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
<griff_>
I just did a little test with sandstorm running in a docker container and having owntracks-recorder built in another container and calling spk dev and while /opt/sandstorm is shared between the two container so the unix socket is available spk dev checks for the sandstorm pid (which is in another namespace) so it doesn’t work
<griff_>
Oh! There is a —pid option for docker run that controls pid namespace. So now it works.
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 265 seconds]
frigginglorious1 is now known as frigginglorious
_whitelogger has joined #sandstorm
frigginglorious has quit [Read error: Connection reset by peer]
_whitelogger has joined #sandstorm
griff_ has quit [Quit: griff_]
_whitelogger has joined #sandstorm
_whitelogger has joined #sandstorm
griff_ has joined #sandstorm
griff_ has quit [Ping timeout: 240 seconds]
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
_736b has joined #sandstorm
<_736b>
Hi #sandstorm :)
<abliss>
Hi!
<_736b>
It's been a few months since I looked at sandstorm, anyone working on adding Matrix server?
<abliss>
I was working on a Synapse port for a while.
<abliss>
We never quite figured out how federation was going to work, and the more I learned about the synapse codebase the less I liked it, so I shelved the project for a while. I'd be very interested in collaborating on another attempt (especially if it's based on a different backend than synapse).
<abliss>
_736b ^^
<_736b>
Heh @ the more I learned about the synapse codebase the less I liked it
<_736b>
That's pretty much the reason why I'm here again! Matrix hurts so very much
<abliss>
I saw someone was working on a golang backend, but it still seemed pretty early last i looked (a couple months back)
<abliss>
I was also musing about writing my own atop Cloudflare Workers , but Kenton persuaded me to wait until the next release which may include some kind of interworker messaging support.
<_736b>
Go should be fine, right? Last I remember there were Hugo updates on Sandstorm
<abliss>
Most golang apps work fine in Sandstorm, if that's what you're asking.
<_736b>
Yeah
<abliss>
But there's still some uncertainty about how Matrix would work
<abliss>
if you wanted to interact outside the sandstorm host.
<abliss>
(a) a sandstorm grain can only expose an HTTP api through a long randomly-generated subdomain, so you wouldn't be able to have a catchy @-handle
<_736b>
I probably would want to interact outside my host
<abliss>
(b) a sandstorm grain can only make outgoing http calls if granted permission to the domain through a powerbox request. so each time one of the grain's users wanted to send a message (or join a room) on another host, there'd have to be some interaction through the sandstorm UI
<_736b>
I thought powerbox was solved with things like TinyRSS
<_736b>
Well, "solved"
<JacobWeisz[m]>
The new TTRSS actually does use the Powerbox! But the version currently in the market uses a hole in the sandbox.
<_736b>
Oh, interesting
<JacobWeisz[m]>
Blog post about that hopefully may be published this weekend.
<_736b>
Cool, I will read it with interesty :) Are you on Mastodon?
<_736b>
-y
<JacobWeisz[m]>
But basically any time you need outside network access, you have to have Sandstorm permit the connection, hence the interaction Adam mentions.
<JacobWeisz[m]>
I have Mastodon but have barely used it in the last year or so.
<JacobWeisz[m]>
I used to be active on it for a while. ocdtrekkie@mastodon.social
<_736b>
I meant more like, does Sandstorm have Mastodon. Devs are fine, too, though
<JacobWeisz[m]>
It mostly has the same issue: Very complicated to get federation working because near arbitrary network access is expected.
<abliss>
I'm interested in mastodon in sandstorm too but it has very similar challenges. No work has been done on it afaik.
<JacobWeisz[m]>
At the very least you'd need to use an unsupported Sandstorm feature to get a mildly usable server address for a federated app.
<_736b>
Yeah, running everything in Sandstorm would be great ... my Mastodon instance runs outside of it right now
<JacobWeisz[m]>
Yeah, I don't have the patience to selfhost many apps, I selfhost Sandstorm and that's it.
<_736b>
I feel you. Luckily, Mastodon is pretty easy to maintain
<_736b>
Wouldn't do it otherwise either .. I'm only running that and Nextcloud on this VM
<JacobWeisz[m]>
I have a theory that TwTxt would be the easiest to package for Sandstorm as far as federated social goes, but again, you'd still need that unsupported feature to make it have a cleanish URL.
<JacobWeisz[m]>
prologic/twtxt is the one I am looking at
<JacobWeisz[m]>
Client wise
<abliss>
which unsupported feature are you thinking of Jacob Weisz ?
<JacobWeisz[m]>
Standalone domains
<abliss>
as currently implemented, i don't think standalone grains help with that.
<JacobWeisz[m]>
TwTxt could maybe use static web publishing, mind you
<abliss>
they just give you a web page that wraps the grain in an iframe. you can't access the HTTP API through the short domain.
<JacobWeisz[m]>
Mmm, that's right
<blowfist>
JacobWeisz[m]: a hole left in the sandbox as a feature or a vulnerability?
<JacobWeisz[m]>
blowfist: As an explicitly defined feature, you'd have to write code to use it explicity.
<abliss>
(and the hole is documented)
<blowfist>
abliss: if you could find the link, I'd be quite interested :)
<_736b>
You know what also would be cool?
<_736b>
It'd be really cool if I could use Freenet to store data
<abliss>
issue (c) with matrix: the matrix spec recommends using the http Authorization header for auth but sandstorm's public http api needs to use that header. Matrix does provide an alternative of putting credentials in the url params, but it's deprecated and many clients don't seem to support it without a patch.
<_736b>
Ahh.. so it boils down to Matrix sucks. I figured as much :/
<blowfist>
an irc client/bouncer would be nice too
<abliss>
Ian Denhardt has an irc bouncer in progress i believe.
<_736b>
Oh yeah, ZNC would rock
<abliss>
_736b i'm not clear that the matrix spec itself sucks. recommending use of the authorization header isn't unresaonable by itself. it just may make it a little hard to shoehorn it into a sandstorm deploy.
<blowfist>
maybe it would be better to make a matrixlike project specifically for sandstorm and then maybe have glues to interface with the other ones existing (as a side project)
<blowfist>
it would be quite interesting to use webkeys to connect remote servers together
<abliss>
yeah, blowfist that was sorta my conclusion after messing with synapse. though Ian Denhardt also gave me some hope that using mattermost as an alternate base might be better.
<_736b>
I mean, you may be right, but.. at the same time, apparently I'm too dumb to get a Synapse server running, and it really shouldn't be that hard, I think
<abliss>
synapse is not easy to set up, I think. and I wouldn't trust it to run outside a sandbox.
<abliss>
I would love to talk about how sandstorm's capability-based approach could model a federated social/chat app.
<_736b>
Yes
<abliss>
I have a vague notion that it might even be possible to coerce sandstorm's own http api into something resembling a matrix protocol.
<abliss>
where each room maps onto a grain.
<abliss>
but i need someone to think through it with me, because i don't seem to be smart enough to figure it out on my own.
abliss_ has joined #sandstorm
<blowfist>
I've been pondering the idea of making a sandstorm app for my password derivation project : https://xroutine.net/passDeriv/
<abliss_>
oh, there's also issue (d), which is that desktop notifications don't really work right from inside an iframe, so some hacking would need to be done to integrate the web app with sandstorm's notification system (which itself may still be somewhat half-baked)
<JacobWeisz[m]>
blowfist: It doesn't store any data server-side?
<blowfist>
JacobWeisz[m]: no, all on the client side
<blowfist>
JacobWeisz[m]: it uses localstorage and I recently also added the ability to import and export the content
<JacobWeisz[m]>
I mean, the only perk for Sandstorm use then is knowing you aren't getting the client from a hostile server. localStorage will not work though.
<JacobWeisz[m]>
Anything localStorage on a Sandstorm grain gets effectively lost.
<blowfist>
JacobWeisz[m]: right, for sandstorm, I'd need to use an actual server side database
<blowfist>
JacobWeisz[m]: I've been pondering about using davros as a pseudo database :D
<JacobWeisz[m]>
But yeah, I'm not big on password managers, a derived method might be interesting though.
<JacobWeisz[m]>
blowfist: Davros doesn't implement it, but Ian wrote a file system interface for grains to use other grains as file storage.
<blowfist>
I agree and technically, you shouldn't actually *need* to store your accounts list, but it's damn convenient :)
<JacobWeisz[m]>
I think I would rather password thing be self-contained to a single grain though.
<blowfist>
JacobWeisz[m]: I've been working on a simple webDAV client for davros, so far I wrote a shell scripts client for it (so I can access the files from the command line) and currently working on a javascript version
<blowfist>
JacobWeisz[m]: you're right, a self contained base version would be the best. I'd need to write a simple server side interface maybe in python to implement this quickly
<blowfist>
is there a "free" database in sandstorm (like mongodb) or each app really have to provide their own?
<abliss_>
_x736b: one approach that i've been consideriding, to easily(?) shim my sandstorm synapse server into the matrix federation space, is to use something like Cloudflare Workers to provide a short catchy url, and rewrite urls and headers into a format that would work with sandstorm. And now that isd has a working http proxy for doing outgoing http through the sandstorm, it might be pretty tractable.
<abliss_>
alternately, a sufficiently advanced apache/nginx config might be able to do it
<abliss_>
blowfist: each app has to provide its own; the mongod is only for sandstorm itself to use
<blowfist>
abliss_: thanks for the link :)
<abliss_>
sandstorm gives you a filesystem, which for many uses may be enough, since an individual grain isn't expected to scale to very high usage. But most apps which are pre-written for other platforms do get bundled with a database (often sqlite)
<isd>
blowfist: apps bundle their own dbms; there's no shared db server available. We generally recommend SQLite or something similarly lightweight where possible
<isd>
Derp, thought I'd finished scrolling own.
<abliss_>
isd: would you have any objection if I pull master of powerbox-http-proxy into my synapse port and see if I can get it to work for outgoing federation?
<isd>
Note that for anything but the simplest access patterns you should use a db that supports transactions (even if you don't want a full RDBMS; there's stuff like lmdb), as there's a risk of data loss if it gets shut down at the wrong time otherwise
<isd>
...and sandstorm SIGKILLs apps when idle, so this is likely to happen (this is intentional; we can't protect apps from this, so this way bugs are likely to get caught sooner).
<isd>
abliss: why would I object?
<abliss_>
just wondering if there's any reason to hold off or if it's considered good enough to play with.
<abliss_>
also, what's the websocket for?
<isd>
I'd say it's ready
<isd>
abliss: powerbox requests can only be made by the client. So there's a little script that's included that connects to the websocket, and then the server forwards any powerbox requests it wants to make to the client, which then makes them and hands them back.
<abliss_>
ah, i see
<abliss_>
i may have already asked this, but is there a good reason the backend can't trigger the display of a powerbox request by a message to the sandstorm-api socket?
<abliss_>
seems kinda silly to bounce it off the client, but maybe it's necessary to figure out which set of eyeballs is in front of the page?
<isd>
No reason it couldn't; there's even a method spec'd out for it (SessionContext.request in grain.capnp iirc?), but it's not implemented
<isd>
But yes, it does need a user session to make the request with. But the server method above accounts for that by being a method on the SessionContext
<isd>
Re: IRC bouncers, at some point I want to resurrect irc-idler and/or sandstorm-znc, others are also welcome to play with them/send patches.
<blowfist>
isd: well if abliss_ manages to fully implement his matrix app, we'd get an IRC bouncer for free :)
<abliss_>
that was my original plan, but i'm less than optimistic now.
<isd>
Both had problems with connections randomly dropping after a long period of time and I never quite figured out why, but I half suspect it's go-capnproto's fault; the v2 branch's rpc implementation is a little dodgy in places. The v3 branch is a bit better, so it would make sense to update the app(s) to that.
<abliss_>
the synapse plugin story isn't pretty, and the powerbox proxy only supports outgoing HTTP/HTTPS calls, so it couldn't connect directly to irc
<blowfist>
abliss_: I've been headbutting on the CORS headers too as I was implementing my javascript webDAV interface for davros... took me quite a while to figure it out
<isd>
...there's a lot in the backlog to respond to. But I have to eat. back later.
<abliss_>
bon appetit :)
<blowfist>
you wrote that pretty well, do you speak french abliss_?
<blowfist>
(usually people write "bon appetite" which is not correct)
<abliss_>
seulment un petit peu.
<blowfist>
un peu de beaucoup est bien :D
<blowfist>
nice work on your matrix prototype btw, I haven't tried to connect but it looks great
<abliss_>
it's hard if not impossible to connect to it with an unpatched client. the bundled riot.im impl has the necessary patches. I also have a patchset somewhere for one of the commandline clients
<abliss_>
cd ..
<abliss_>
ls
<abliss_>
oops wrong window dang :)
<blowfist>
ah so it doesn't work with a sandstorm user?
<blowfist>
I'm not sure going sandstorm users would be the right way to do this
<abliss_>
it does use your sandstorm user as your login .
<abliss_>
so you probably need to create an account on my host in order to use the grain. i don't recall whether it does something sensible with anonymous users.
<blowfist>
s/going/using
<blowfist>
it gives an error as anonymous, let me try it again so I can paste it
<abliss_>
yeah, i'm pretty unsure as well. especially since incoming server-to-server sync happens by anonymous(?) http puts.
<abliss_>
at the front page you have to click "sign in" and not "create account"
<blowfist>
Error: Problem communicating with the given homeserver. (HTTP 400)
<abliss_>
hm, let me see, one moment
<abliss_>
i see it too. "User ID can only contain characters a-z, 0-9, or '=_-./'"
<abliss_>
possibly it's trying to use sandstorm's auto-generated anonymous id and it doesn't confrom to the regex
<abliss_>
maybe if you try again approximately 2^31 times you may get lucky enough to generate a valid id :)
<abliss_>
ah, no, it's my bad, I have it using "UnknownHandle" in the code, which is both stupid and wrong. I can fix it easily, but first I need to get my dev environment for this app back up and running from its mothballed state.
<blowfist>
I see, well running a server in sandstorm would already be quite a step
<abliss_>
yeah, if you create an account on the host (glissando only supports google at the moment), you should be able to chat with other sandstorm users on the same host pretty well. (no desktop notifications though)
<abliss_>
(it doesn't have any of the plugins installed, and it isn't possible to install them yourself. I have some ideas about how to fix that.)
<abliss>
though i worry that as such a decentralized movement, lots of duplicate effort is being wasted on similar but competing products, which just increases the megacorps' lead :(
<JacobWeisz[m]>
Decentralization is mostly pointless if everyone is using the same platform.
<JacobWeisz[m]>
We should want multiple healthy options such that we aren't up a creek if one turns evil or dies out.
<abliss>
diversity of platforms does have some nice side effects, but i still think there would be much gained if everyone used the same platform but hosted it themselves.
<JacobWeisz[m]>
I definitely still think Sandstorm is the "best approach", but I'd be very worried if it was the only approach, given the bus factor right now.
<abliss>
well, part of what i'm saying is that there are a lot of people interested in Redentralizing, and if we could get them all unified behind any one approach, that approach would have much more labor behind it :)
<abliss>
* well, part of what i'm saying is that there are a lot of people interested in Redecentralizing, and if we could get them all unified behind any one approach, that approach would have much more labor behind it :)
<JacobWeisz[m]>
Fair. But for instance, Chromium moves the entire internet in harmful ways. A lot of labor behind an open source solution can still be huge problem.
<JacobWeisz[m]>
I would definitely like to get more people interested in the Sandstorm way of doing things though, so we have more contributors.
<abliss>
oh yeah, i'd much rather have robust open protocols than a single monocultered program. but to me, the threats of megacorp hosting are much more dire.
<abliss>
* oh yeah, i'd much rather have robust open protocols than a single monocultured program. but to me, the threats of megacorp hosting are much more dire.
<simpson>
There's a tension between metis, the local and parochial knowledge which shields people from corporate/state influence; and interoperability and legibility between distant corners of society.
<abliss>
(It's pretty unfortunate that getting involved in sandstorm kinda requires buying into several of kenton's ideas all at once. if any one of them is a turn-off to someone, it'll be a major impediment. I wonder if there's some way to pull out the core idea of capability-based sandboxes, and turn it into a protocol with multiple implementations. Probably not with our current resources.)
<JacobWeisz[m]>
I think the well known subdomain problem is really the only huge turn-off I've seen.
<JacobWeisz[m]>
If we solved that much earlier I think Sandstorm would have a lot more users, even if they weren't all using it the way we considered ideal.
<simpson>
For those of us not fans of the Web, it would be nice to do ocap work without having to use a Web browser and all that.
<abliss>
the random-subdomain hack is a clever way to try to co-opt the domain-based sandboxing model implemented by web browsers (which itself is in large part a product of Google's pressures) into something closer to what Sandstorm wants to implement. I would love to see a list of proposals from Sandstorm for a sensibly-designed client sandbox model.
<JacobWeisz[m]>
I suppose the "everything must be doable from a web browser" is also an opinionated choice. Though a web app platform needing the web seems hard to dodge.
<abliss>
Sandstorm could Chromium/Blink and publish its own client app, but of course this would be a further impediment to adoption. which is exactly how the megacorps tighten the shackles.
<abliss>
(other opinionated choices include capnp, c++, kj, mongo)
<JacobWeisz[m]>
mongo is less a choice than a "Meteor makes us do it"
<JacobWeisz[m]>
I know Ian would like to get away from it someday.
<abliss>
The breakage of localStorage is particularly unfortunate. (Can someone remind me why the subdomain has to be rerandomized on each session? why couldn't it be, like, a hash of the grain id and the user's id?)
<JacobWeisz[m]>
Honestly I hate localStorage with a passion so I'm glad it doesn't work. If you're not storing server side your stuff doesn't get backed up when you back up your server and you lose cross-device usefulness.
<abliss>
maybe i backup my client?
<blowfist>
and localStorage doesn't work that great in the tor browser bundle
<JacobWeisz[m]>
But if we had an easy/automatic way to patch it to server side storage it'd make a lot more apps available to us with a much easier packaging method.
<abliss>
maybe, in fact, i trust my os's ability to snapshot+sync+restore my localStorage more than I trust your server to do it.
<JacobWeisz[m]>
Well, it'd be your server in Sandstorm's case.
<kentonv>
abliss, I think you're in a small minority there
<kentonv>
(I mean trusting your local machine to do backups more than a server)
<JacobWeisz[m]>
But it feels like a side channel attack that websites can just inject stuff invisibly into my browser, and it doesn't even have to ask permission to do so.
<JacobWeisz[m]>
I get why web app devs like it: It works like magic and it costs them nothing to implement.
<abliss>
really? woudln't you say more people have a macbook and a time machine than own a linux server that can run sandstorm?
<abliss>
(i've never actually used a macbook or time machine, but i hear they do a good job of user-friendly backups)
<JacobWeisz[m]>
If it wasn't so hidden it might bug me less. Knock Internet Explorer all you want, but it stored it's bookmarks in a normal file folder in your personal drive, and as far as local storage of browser data, everything has gone downhill from there from a maintenance and transparency standpoint.
<isd>
re: localStorage, apps really shouldn't rely on it as more than a cache; browsers don't give you big "you might unrecoverably lose data" warnings when you clear cookies and such, so it results in a fragile situation.
<isd>
IIRC the hostname is per (grain, session) pair. The idea is if you log out the grain shouldn't be able to track you.
<kentonv>
abliss, DigitalOcean does a pretty good job of auto-snapshots, no action required.
<isd>
Also, re: opinionated choices: really capnp is the only one of those that is imposed on app developers; Sandstorm is language agnostic and mongo isn't app facing (unless they separately choose to use it)
<isd>
I think "federated capnp" or something like it is a foundational technology that would be well worth coming to some broader agreement on.
<isd>
Agoric and Chris Lemmer Webber are both working on what are more or less the same thing as capnp rpc; we should see if we can coordinate on interoperability.
<abliss>
"the gran shouldn't be able to track you" across different sessions of the same user and same grain? doesn't sadnstorm give it a user id header it can use for that?
<kentonv>
isd, Agoric is Mark Miller's company... to be fair, Cap'n Proto is based on his stuff. :)
<isd>
Only if you actually give the grain your identity; if you're logged in and visit a sharing link you'll get this "reveal my identity" button that you can not click to avoid letting the grain know who you are.
<kentonv>
Mark is a big fan of capnp, though, so if they aren't using it, there is probably a good reason...
<abliss>
right, sure, anonymously-visited grains should have a new random subdomain for each visit. but what about a logged-in user?
<isd>
kentonv: I'm aware; didn't mean to imply capnp came first or anything -- just "these are very similar"
<isd>
It is of course not a coincidence
<isd>
I know chris has been wanting to see about arranging interop between their stuff and agoric's.
<blowfist>
abliss: works well
<isd>
I should send a thing to the cap-talk list about this. There may indeed be a reason Agoric isn't just using capnp, but at the very least we should learn what that reason is.
<abliss>
blowfist: obviously, don't use it for anything real / sensitive / important.
<blowfist>
abliss: yeah, it's only a prototype
<blowfist>
abliss: still I think it would be worth venturing in the server <-> server sharing of a special webKey
<blowfist>
abliss: it would obviously not be trivial to implement as we'd need a glue for it
<blowfist>
and my server I mean apps on sandstorm instances
<blowfist>
s/my/by
<isd>
Project up for grabs if anyone is interested: try packaging an xmpp server (maybe prosody) and set rig it up with BOSH. maybe skip federation in the short term but it would be a neat way to get a basic chat server with client support up and running quickly.
<abliss>
it isn't clear to me why the matrix folks decided, when they set out to build a modern federated chat platform, not to start with xmpp. i think there's a faq about it somewhere. .i suspect it may have been for good reason.
<abliss>
i have no opinion personally, but i really want to get some kind of federated chat/social platform working inside sandstorm.
<isd>
Next office hours let's do a brainstorming session on that. I feel like this is an issue that's kinda floating in the back of people's minds indefinitely and I want to make sure we're actually spending some active brain cycles on it, rather than collectively waiting for an aha moment.
<JacobWeisz[m]>
That'd be tomorrow
<isd>
Yep.
* isd
goes to make sure the wiki is up to date.
<abliss>
i'm particularly interested in hearing why the subdomain can't be a hash of the userid + grain id, since i'm sure there's a good reason and it'll teach me something important.
<isd>
They're also randomized as a CSRF mitigation
mnutt has joined #sandstorm
<abliss>
is that threat model spelled out somewhere?
<blowfist>
hey mnutt did you push davros with a fix for the upload button issue?
<mnutt>
working on that right now :)
<blowfist>
great :)
<isd>
Yeah, I agree we should add a reference to some rationale to that section.
<isd>
I don't know off-hand where the best docs on that are; at this point it's just in my head as something I learned at some point, maybe just from having asked questions once upon a tie.
<isd>
time
<blowfist>
mnutt: I wrote a small shell script to interface with davros btw
<isd>
+1 for writing stuff down.
<mnutt>
running into issues with packaging, seems to be related to the debian upgrade: sandstorm/sandstorm-http-bridge.c++:2878: failed: execvp(argvp[0], argvp): No such file or directory; argvp[0] = /opt/app/.sandstorm/launcher.sh
<mnutt>
(app works fine running in dev mode, but packaged up it cannot start)
<blowfist>
(the ability to list, download and upload files to davros from the command line is pretty handy)
<isd>
mnutt: did launcher.sh end up in the package?
<mnutt>
yes
<isd>
is it executable?
<mnutt>
yes
<isd>
Do you have a built spk somewhere I can inspect?
<abliss>
does its shebang line point to /bin/bash, and is that in the package?
<mnutt>
actually, while launcher.sh is listed in .sandstorm/sandstorm-files.list, let me make sure it actually made its way into the package
<abliss>
iirc i had some problem related to debian's symlinking /usr/bin to /bin
<mnutt>
I'm also seeing sandstorm adding directories to .sandstorm/sandstorm-files.list whereas it didn't before, is that intentional or indicative of some issue?
<mnutt>
or related to symlinking you mentioned?
<isd>
I don't think the tooling's behavior has changed.
<abliss>
the problem i had, iirc, was that e.g. /bin was ending up in the list, where it wasn't before, and then it was failing to get packed, and so /bin/bash didn't exist (because it was really at /usr/bin/bash, which changed in the debian upgrade)
<abliss>
but i thought that was failing at spk pack time, not at runtime.
<mnutt>
ah, you know, I ended up removing the bin line, and a few others. that probably is causing the problem given it's a symlink
<abliss>
and i think i worked around that by manually removing /bin and some others from the file list.
<abliss>
but maybe this is all a red herring and maybe the problem is really that your pkgdef isn't mounting the app at /opt/app but rather at / or somewhere else?
<mnutt>
I removed the entire file list and am going to selectively take changes and try repacking
<mnutt>
alright we're in business
<mnutt>
I had mistakenly removed the `bin` line and left the other `bin/bash` etc lines (repeated for a few other directories)
<JacobWeisz[m]>
Make sure you're testing every feature in dev mode if you clear out the file list.
<mnutt>
yeah I was mostly doing it just to confirm which bin lines should be kept/removed, I tested features and diffed against previous sandstorm-files just to be sure
<mnutt>
And Davros 0.26 is submitted. Sorry about the long delay and huge thanks to griff for all of the fixes.
<isd>
I thought I'd clicked through from experimental. Let me try again.
<isd>
Ah, the 'demo' link _doesn't_ keep the experimental flag
<JacobWeisz[m]>
The experimental market is very barely a thing that works, we probably should improve it a little at some point.
<isd>
It did work when I tried it with vagrant-spk dev the other day.
<JacobWeisz[m]>
Buttons work for me.
<JacobWeisz[m]>
mnutt: Can you push your final sandstorm-files update and such, if there were any changes?
<JacobWeisz[m]>
Just want to make sure nobody's retreading that troubleshooting if they work on it later.
<blowfist>
mnutt: the upload button works on my end too
xet7 has quit [Quit: Leaving]
<JacobWeisz[m]>
Ian, when should we publish the TTRSS package?
<isd>
I figure pull the trigger on that and the blog post at roughly the same time.
* isd
checks email
<isd>
So now I guess?
<JacobWeisz[m]>
Okay, question first though
<JacobWeisz[m]>
What happened to the package size?
<JacobWeisz[m]>
Legacy version 10 is 22 MB, 11 is 50 MB, which is fair, 12 jumps to 100 MB, and then... 13 is 400 MB.
<JacobWeisz[m]>
Is there any chance you are alwaysIncluding SPKs you built or something strange?
<JacobWeisz[m]>
(Archiving all the SPKs personally may be a tedious habit but I occasionally notice interesting things.)
<isd>
Ok, that's a bug then, I'll look into it.
<isd>
That definitely sounds like "accidentally including the old package in the new package" or something.
<isd>
Yes, that is exactly what's happening; I alwaysIncluded the src repo so it would grab all of the php files, but then it also grabbed the old spks.
<isd>
I'll build an up to date one that doesn't have those.
<JacobWeisz[m]>
Awesome
<isd>
I assume I would have noticed it myself in a couple more releases at most :P
<JacobWeisz[m]>
"Why is TTRSS bigger than a Windows 10 DVD?"
<JacobWeisz[m]>
400 MB isn't the largest SPK, I think. But the trend seemed indicative of an oddity.
<isd>
Can confirm my working tree had an intermediate build I must not have spk-publish'd that's 200MiB
<isd>
Anyway, just pushed another one that's back down to 50MiB. Should otherwise be the same a the most recent one; give it a spin.
<isd>
I didn't bother to bump appVersion
<JacobWeisz[m]>
Seems alright so far.
<kentonv>
I think you really do need to bump the app version if the previous version was published...
<isd>
Even if it was never approved?
<kentonv>
maybe not. By "published" I meant approved
<isd>
yeah, they've just been sitting in experimental.
<JacobWeisz[m]>
The only potential peeve is people who might've installed from experimental won't see an update.
<JacobWeisz[m]>
Mostly that's Adam and me probably though.
<isd>
I might as well bump it
<isd>
one sec.
<isd>
Ok, pushed appVersion = 14
<JacobWeisz[m]>
Is everyone happy with the Davros update?
<blowfist>
JacobWeisz[m]: seems good on my end
<JacobWeisz[m]>
I still don't think I can upload on 0.26
_736b has quit [Ping timeout: 244 seconds]
<blowfist>
JacobWeisz[m]: no? It clearly didn't work for me in version 0.25 but now it does, make sure to create a new davros grain and test there
<JacobWeisz[m]>
It should work with upgraded grains too though, I imagine?
<blowfist>
I didn't try that actually, let me try
<blowfist>
oh we have to upgrade all grains at once?
<JacobWeisz[m]>
Yeah
<blowfist>
yeah it worked
<blowfist>
I tested the grain, the upload button didn't work, updated all grains and then it started working
<blowfist>
(had to restart the app)
<JacobWeisz[m]>
Hmmm... both servers I have my Davros grains on I upgraded all grains, and it didn't work.
<JacobWeisz[m]>
Let me do some more testing.
<blowfist>
now that I think about it, I may have an older sandstorm version installed
<blowfist>
0.261
<JacobWeisz[m]>
That sounds current. Shouldn't matter though, mostly. Sandstorm platform hasn't changed in a way that should impact Davros working or not.
<isd>
Can confirm it works for me too, both upgrading and with new grains
<isd>
(Though drag & drop is still broken, but that's not surprising)
<isd>
Current is 0.269
<isd>
0.261 is from march
<isd>
But I tried it on a recent master and it was fine, and I agree with ocdtrekkie, there's nothing that's changed that seems like it would be relevant.
<blowfist>
would be fantastic if we could debug roundcube too
gptix has quit [Ping timeout: 260 seconds]
<blowfist>
sending a single email works, but sending more than one gives a server error
<blowfist>
the bug may be in the underlying smtp support
<blowfist>
hmm I thought I added the bug report to roundcube's issues page
<JacobWeisz[m]>
I can reproduce my bug in a new Davros grain.
<JacobWeisz[m]>
Create a folder inside the grain and try to upload into THAT.
<JacobWeisz[m]>
Most of my Davros grains have some semblance of folder structure... but when testing I usually don't bother.
<blowfist>
hmm seems like I get a bug too in that case, but the button does work, it shows the dialog to choose a file
<blowfist>
so I get a dialog but the file doesn't get uploaded... or is it, let me try to reenter the subdirectory
<JacobWeisz[m]>
Yeah, 0.26 is definitely less broken than the last release.
<blowfist>
nope, you're right JacobWeisz[m], uploading just doesn't work in subdirectories
<blowfist>
totally different bug than before though
<JacobWeisz[m]>
I think I hit this bug on the previous release too but since I didn't understand it, I grouped it with the other bug.
<blowfist>
JacobWeisz[m]: want me to fill the bug report or you do it?
<JacobWeisz[m]>
On 0.25 drag/drop upload still worked I think, but I was trying to upload to a subdirectory so I thought it was also broken.
<JacobWeisz[m]>
I already opened it on the davros repo.
<JacobWeisz[m]>
I think I will still approve 0.26 as a less broken thing, but we should try to get that fixed ASAP.