Uncaught exception with spk pack

[ankitmhn]

I'm running into a an error when trying to package an app. spk dev seems to work fine and I can interact with the app within my sandstorm environment but I get the following when I try to run the spk dev my-app.spk command:

*** Uncaught exception *** sandstorm/spk.c++:1171: failed: expected children.empty(); got symlink, expected directory; target = /lib stack: 61306d 61186a 61094e 61089c 662ce3 663246

[zenhack]

I feel like I saw this recently sometime too and was too tired or busy to remember to investigate it. Thanks for the report.

[zenhack]

Ok, yeah, I can reproduce this with the currrent master of https://github.com/zenhack/ttrss-sandstorm/. Notably, doing spk pack for Sandcal works fine. Sandcal doesn't use vagrant-spk. I don't have time to do a deep-dive debugging right now, will get back to it later, but some things worth looking into:

• Can others reproduce the failure with the ttrss repo? If not this means there's likely some local environment state that's off.
• Is this reproducible for fresh vagrant-spk projects?

@ankitmhn, am I reading correctly that you're running spk pack directly, i.e. not using vagrant-spk? Any additional info you can provide re: your dev environment and/or the app you're packaging might provide useful insight.

[ankitmhn]

That is right. I am running spk pack directly without vagrant-spk. This is on a fresh sandstorm install but the app that I am trying to package is one that I had written a year ago and it used to package just fine back then.

[zenhack]

Ok, I finally got around to digging into this one in order to ship a ttrss update. It looks like what happens is:

• Many distros (including debian) at some point made /bin a symlink to /usr/bin, and same for /lib, /lib64, and such.
• spk dev picks up the new files when scanning for use as normal, but doesn't delete old entries unless the files cannot be found.
• When it sees files in sandstorm-files.list, it expects their containing directories not to be symlinks.
• Because in a previous run, /bin, /lib etc. were not symlinks, and files under them were included, there are now stale entries in sandstorm-files.list that refer to things in directories that are actually symlinks.

I managed to work around this by just deleting all of the entries in my sandstorm-files.list that were underneath symlinks; the correct versions were already in the file.

Probably the right fix here is that spk should treat files in sandstom-files.list that are under symlinks as being "missing" and delete them as it does for other missing files.

[ocdtrekkie]

Was this also @orblivion's issue with Etherpad packaging?

[orblivion]

It's been a while but from my recollection I tried deleting those symlinks based on someone out there having figured that out before. However, I had other problems after. However I'll take a look tomorrow to confirm. I'll post whatever errors I see in case it's related to the OP's issue.

…

On Sat, Jan 1, 2022 at 1:13 AM Jacob Weisz ***@***.***> wrote: Was this also @orblivion <https://github.com/orblivion>'s issue with Etherpad packaging? — Reply to this email directly, view it on GitHub <#3535 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKH6CNOCLO7457NDF7ZWTUT2LQPANCNFSM47BKW3LA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[orblivion]

I had previously only tried deleting the symlinks (bin, lib, lib64) but not everything underneath them. I tried again, and none the less it doesn't work. Initially it complained that it couldn't find bin/bash, presumably because it's used my launcher.sh or sandstorm-pkgdef. I updated everything to refer explicitly to /usr/bin/bash. Now it says: ``` *** Uncaught exception *** sandstorm/sandstorm-http-bridge.c++:2889: failed: execvp(argvp[0], argvp): No such file or directory; argvp[0] = /usr/bin/bash ``` usr/bin/bash is in my sandstorm-files. Looking in the app directory under /opt/sandstorm after installing, indeed usr/bin/bash does exist and is an ELF. (in fact bin/bash likewise was an ELF before I switched to usr/bin/bash). Interestingly, this happened within the same OS that was used to generate the spk in the first place. I wonder what that says about the OS compatibility explanation? Since @zenhack got it to work I'm hoping there's just something simple I'm missing.

…

On Sat, Jan 1, 2022 at 2:11 PM Daniel Krol ***@***.***> wrote: It's been a while but from my recollection I tried deleting those symlinks based on someone out there having figured that out before. However, I had other problems after. However I'll take a look tomorrow to confirm. I'll post whatever errors I see in case it's related to the OP's issue. On Sat, Jan 1, 2022 at 1:13 AM Jacob Weisz ***@***.***> wrote: > Was this also @orblivion <https://github.com/orblivion>'s issue with > Etherpad packaging? > > — > Reply to this email directly, view it on GitHub > < #3535 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAAKH6CNOCLO7457NDF7ZWTUT2LQPANCNFSM47BKW3LA > > . > Triage notifications on the go with GitHub Mobile for iOS > < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 > > or Android > < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub >. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#3535 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKH6BZNOQQZZRVLO5EMTDUT5GWPANCNFSM47BKW3LA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zenhack]

Note that in this instance I was talking about ttrss; I'm having other problems with the etherpad build which are not resolved, but they seem unrelated.

[orblivion]

I just spent way too long figuring out behavior that seemed rather unpredictable to me. However most of it was related to a simple misunderstanding on my part of @zenhack's solution (which seems pretty dumb of me in retrospect). So, lest anybody else waste this time, I'll clarify:

In your sandstorm-files.list:

• do delete files under the symlink directories (bin/bash, lib/x86_64-linux-gnu/libc.so.6, etc)
• do not delete the symlinks themselves (bin, lib, lib64).

For entertainment's sake: If you do delete the symlinks, what will happen is that your spk will build. When you run it, you will find that not only can it not find anything under the bin directory, it can't find anything other than sandstorm-http-bridge. This is probably because the file system needs something under lib or lib64, the symlinks that you just deleted. You'll find that sandstorm-http-bridge can even be found if you move it to a different location within your app directory (and specify that location in sandstorm-pkgdef.capnp). But if you change the contents of sandstorm-http-bridge (to, let's say, the contents of /bin/ls) then it won't be able to find sandstorm-http-bridge anymore. Sheer madness, thankfully explained by a simple root cause.

---

There's still something I have to figure out related to generating sandstorm-files.list. Sometimes it actually doesn't include those files-under-symlinks and sometimes it does. I thought it was related to what directory I put sandstorm-pkgdef.capnp in and spk dev from, but I've realized that it doesn't seem to be consistent.

[ocdtrekkie]

I just hit this issue today, though I built on an older sandstorm-files list to start from and upgraded the base box. The old package didn't have the issue (and didn't have the bin symlink in it's files list before I started). My guess is that the symlink prevents the file watcher from removing these files that no longer exist from the list, because they are now found via the symlink, so it still thinks they exist, until it tries to grab them for packing.