sl sdk.install fails on linux

[syntroniks]

s@PF1AJJFF:~/path$ sl sdk.install
# sdk.install

## cloud.login
- uid: oN8ZhE2AVZMytXzVFwa51CWOlsS2

## output
- downloading: ##################################################
### external.begin

Archive:  /home/s/.sl/packager-1598365934343755500/compiler
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of /home/s/.sl/packager-1598365934343755500/compiler or
        /home/s/.sl/packager-1598365934343755500/compiler.zip, and cannot find /home/s/.sl/packager-1598365934343755500/compiler.ZIP, period.

### external.end

- result: success

s@PF1AJJFF:~/path$ sl --version
# about

## output
- publisher: Stratify Labs, Inc
- version: 0.68
- gitHash: 96773f1
- apiVersion: 3.20.3
- apiGitHash: fdf7be9
- sdk: /home/s/StratifyLabs-SDK
- system: linux_x86_64
- result: success

Older and newer SDKs that have been downloaded (newer was by sl 0.68 earlier today, older was by unknown earlier this month):

$ file /home/s/.sl/packager-1597232787562330600/compiler
/home/s/.sl/packager-1597232787562330600/compiler: Zip archive data, at least v1.0 to extract
$ file /home/s/.sl/packager-1598365934343755500/compiler
/home/s/.sl/packager-1598365934343755500/compiler: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=d7b8bc25fb9c6b8fc7d0f4f40c7939ea967da95d, stripped

[tyler-gilbert]

OK. The latest version of sl is 0.73. I removed the option to automatically check for updates so you need to do sl --update to check for updates.

I switched the SDKs from zip to 7z to reduce bandwidth. But you still need to use sl sdk.install sparingly because it uses up the firebase bandwidth very quickly.

[syntroniks]

s@PF1AJJFF:~/StratifyLabs-SDK$ curl -L -o ~/StratifyLabs-SDK/Tools/gcc/bin/sl $SL_LINK
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 2343k  100 2343k    0     0  2558k      0 --:--:-- --:--:-- --:--:-- 4541k
s@PF1AJJFF:~/StratifyLabs-SDK$ sl --version
# about

## output
- publisher: Stratify Labs, Inc
- version: 0.68
- gitHash: 96773f1
- apiVersion: 3.20.3
- apiGitHash: fdf7be9
- sdk: /home/s/StratifyLabs-SDK
- system: linux_x86_64
- result: success

I should maybe be using slu, but that (in Linux/WSL2) wants to fail or place things in /StratifyLabs-SDK (my bash profile roots the SDK in my home directory)

s@PF1AJJFF:~/StratifyLabs-SDK$ sudo ./Tools/gcc/bin/slu
# update
version: 0.56
info: updating sl
error: failed to update sl
warning: could not copy '/StratifyLabs-SDK/Tools/gcc/bin/slu' to '/StratifyLabs-SDK/Tools/gcc/bin/sl'
s@PF1AJJFF:~/StratifyLabs-SDK$ ./Tools/gcc/bin/slu
# update
version: 0.56
info: updating sl
error: failed to update sl
warning: could not copy '/StratifyLabs-SDK/Tools/gcc/bin/slu' to '/StratifyLabs-SDK/Tools/gcc/bin/sl'

[tyler-gilbert]

So slu is the sl image but it is downloaded as a different name. When you run slu it just copies itself (and overwrites), the existing version of sl. With the just from 0.56 to 0.68 which added support for running in different directories, it looks like there may have been a problem. You can re-download 0.68 using curl. Then do sl --update then manually rename slu to sl. Maybe that will get you on the right track. I am looking to see if there is some bigger problem.

[tyler-gilbert]

This worked for me after using curl to grab the linux image. I had to do sl --update twice. The first time it didn't download the image. I will look in to that.

ubuntu:~/git$ sl --update
# update

## cloud.login
- uid: xxx

## output
- status:  
   - system: linux_x86_64
   - currentVersion: 0.68
   - latestVersion: 0.73
- result: success

ubuntu:~/git$ sl --update
# update

## output
- check:  
   - currentVersion: 0.68
   - latestVersion: 0.73
   - system: linux_x86_64
   - downloading: ##################################################
   - update: use `slu` to apply the updated version of sl
- result: success

ubuntu:~/git$ slu
# update
version: 0.73
info: updating sl
ubuntu:~/git$ which sl
~/StratifyLabs-SDK/Tools/gcc/bin/sl
ubuntu:~/git$ sl --version
# about

## output
- publisher: Stratify Labs, Inc
- version: 0.73
- gitHash: 39f9e8e
- apiVersion: 3.22.1
- apiGitHash: 975a5c2
- system: linux_x86_64
- sdk: ~/StratifyLabs-SDK
- result: success

[syntroniks]

I am able to reproduce your exact output (2x invocation of update and slu success afterwards).

I have separate comments/thoughts on the SDK distro we may discuss in a separate thread to keep things compartmentalized.

Thanks for checking on this.

One interesting thing is that the first --update call spits out a cloud.login section, where the second does not. I think the only remaining COS for this issue is the double --update calls