Linux builds, please?

[extrawurst]

Linux builds, please?

[extrawurst]

Ok then tarball'd binary for musl it is! :)

[extrawurst]

Hi @dufferzafar thanks for your interest in the project. I am currently setting up continuous deployment for macos builds since this is my home platform. I want to look into linux/windows builds after that, but maybe you can shed a light what the right approach to deal with Linux is, simply providing a ubuntu build binary or is there a package manager that I should focus on?
any interest in helping out with this?

[dufferzafar]

So, I feel like you should just try to mimic how other "popular" rust tools do this. Like ripgrep, fd, exa etc. I think having a .deb file, a .rpm file and a .tar.gz file containing a static binary should be enough for just about everyone.

I've never used the rust tool chain myself. But I've been meaning to for some time now, so sure I'd try to see how it all works.

And yeah, we'd have them automated by GitHub actions so that whenever a tag is released. The corresponding binaries go up.

[extrawurst]

So I added GitHub Actions to automate deployment of Mac builds, I will look at linux next and mimic procs (https://github.com/dalance/procs) and start with a rpm package. is that a format that you could test then?

[dufferzafar]

No, sorry, I use ArchLinux and won't be able to test rpm easily. Or debs for that matter. For me, the best format would be a statically linked executable. Packaged in a tarball.

Like this one for ripgrep: https://github.com/BurntSushi/ripgrep/releases/download/12.0.1/ripgrep-12.0.1-x86_64-unknown-linux-musl.tar.gz

or this for procs: https://github.com/dalance/procs/releases/download/v0.9.20/procs-v0.9.20-x86_64-lnx.zip

[extrawurst]

@dufferzafar would non-musl x86_64-unknown-linux-gnu also work? I cannot seem to make it work with musl :(

[dufferzafar]

Yeah. Non Musl will work for me as well.

[extrawurst]

@dufferzafar can you please checkout the first try releasing a linux build: https://github.com/extrawurst/gitui/releases/tag/v0.1.8

[dufferzafar]

gitui: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

╰─❯ ldd `which gitui`
        linux-vdso.so.1 =>  (0x00007ffc2ef9c000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcf8028a000)
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcf80086000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcf7fe7e000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcf7fc61000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcf7fa4b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf7f681000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcf807ee000)

[dufferzafar]

Doing the same with lazygit:

╰─❯ ldd `which lazygit`
        not a dynamic executable

[dufferzafar]

So I think we want statically linked binaries for linux.

[extrawurst]

ok next try, can you look at the artifact here: https://github.com/extrawurst/gitui/actions/runs/79754750

[dufferzafar]

Yeap, that worked!

[extrawurst]

ok great 👍

[extrawurst]

should be integrated in next version then

[extrawurst]

as of v0.1.9 linux builds are part of the deployment pipeline: https://github.com/extrawurst/gitui/releases/tag/v0.1.9

[yermulnik]

Apologies for resurrecting this issue but I've got an issue with latest gitui-linux-musl.tar.gz (v0.10.0):

> /tmp/yz/gitui
bash: /tmp/yz/gitui: No such file or directory

> strace /tmp/yz/gitui
execve("/tmp/yz/gitui", ["/tmp/yz/gitui"], [/* 108 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1)                           = ?
+++ exited with 1 +++

v0.9.1 works just fine.

I'm on Linux Mint 18.3 Sylvia x86_64 which is based on Ubuntu 16.04.

Also .deb would be super useful and I think I can volunteer to test it if any.

[jugglerchris]

@yermulnik Does /tmp/yz/gitui actually exist?

Are you able to show the output of ls -l /tmp/yz/gitui, ldd /tmp/yz/gitui and file /tmp/yz/gitui please?

[jugglerchris]

This sounds like #259 too.

[jugglerchris]

I can reproduce this - I'll put the answers to the above on #259.

[yermulnik]

@jugglerchris

> ls -l /tmp/yz/gitui
-rwxr-xr-x 1 yz docker 2277240 Aug 29 20:35 /tmp/yz/gitui

> ldd /tmp/yz/gitui
        linux-vdso.so.1 =>  (0x00007ffc7094d000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1166c1a000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1166a16000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1166810000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1166446000)
        /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f1166e3c000)

> file /tmp/yz/gitui
/tmp/yz/gitui: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, BuildID[sha1]=0ead58df2438331cfba31c46d33722915f567768, stripped

I can reproduce this - I'll put the answers to the above on #259.

Thank you. I'll take a look.