Commit Graph

71 Commits

Author SHA1 Message Date
Andrei Smirnov 691795c644 Testing changes suggested in PR 2021-09-16 16:50:28 -04:00
Andrei Smirnov 343f4ffee3 Fixed output archive path 2021-09-16 16:50:28 -04:00
Andrei Smirnov fce910bd4a Added ENV: STATUS_CLIENT_7Z 2021-09-16 16:50:28 -04:00
Andrei Smirnov d4da9b75f0 feat(@desktop/windows): produce 7z archive when packaging 2021-09-16 16:50:28 -04:00
B.Melnik 12eecd3195 fix(Makefile): fix bottles order 2021-09-16 16:23:46 -04:00
Richard Ramos 03eed589a9 feat: display logs in node management section 2021-09-15 16:04:28 -04:00
B.Melnik d3c9564d91 feat(Spellchecking): Add bottle for spellchecking
Usage:

```qml

SpellChecker {
   id: spellchecker
   lang: "en"
}

```

Closes: #3442
2021-09-15 15:04:26 -04:00
Andrei Smirnov 6e0d8437d4 fix(@desktop/windows): installer to include cacert.pem 2021-09-06 14:47:18 -04:00
Richard Ramos db3b7ecfd9 feat: Version Updating
Fixes #1290
2021-08-24 16:56:55 -04:00
Anthony Laibe 3fdd593f0f feat(@desktop/internal): Specific logfile per app start
fixes #3146
2021-08-19 10:53:43 -04:00
Jakub Sokołowski 2df6def7f9 ci: add scripts/sign-linux-tarball.sh for GPG signing
Adds `scripts/sign-linux-file.sh` which expectes the following variables set:

* `LINUX_GPG_PRIVATE_KEY_FILE` - Path to the GPG export of private key.
* `LINUX_GPG_PRIVATE_KEY_PASS` - Password necessary to use the private key.

Given a file it creates a file with a `.asc` suffix containing the signature:
```
 > wget -q https://status-im-prs.ams3.digitaloceanspaces.com/StatusIm-210809-104514-156806-pr.tar.gz

 > tar xvf StatusIm-210809-104514-156806-pr.tar.gz
StatusIm-210809-104514-156806-pr.AppImage
StatusIm-210809-104514-156806-pr.AppImage.asc

 > gpg --verify StatusIm-210809-104514-156806-pr.AppImage.asc
gpg: assuming signed data in 'StatusIm-210809-104514-156806-pr.AppImage'
gpg: Signature made Mon 09 Aug 2021 12:54:49 PM CEST using RSA key ID E20B4DFD
gpg: Good signature from "Status.im Devel Signing (GPG key for signing Status.im development builds.) <devel@status.im>" [ultimate]
Primary key fingerprint: BBF0 5F92 536B ED19 30A9  FD44 009F B3BF E20B 4DFD
```

Issue: https://github.com/status-im/infra-ci/issues/25
Requires: https://github.com/status-im/status-jenkins-lib/pull/32

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-08-16 11:21:36 -04:00
Anthony Laibe 58506fbd97 feat(@desktop/chat): Display gif popup next to emoji 2021-07-23 15:27:56 -04:00
B.Melnik f0b7eb6789 feat(widnows-installer): Add compilation windows installer build step
Closes: #2223
2021-07-19 13:46:19 -04:00
B.Melnik 116a6f3e0c WIP 2021-07-19 13:46:19 -04:00
Sale Djenic abf89fa399 chore(@desktop/general): use different icons for Windows/Linux and MacOS
Icons are updated, mac uses rounded rect log, win and linux circle logo.

Fixes: #2833
2021-07-19 13:37:56 -04:00
Andrei Smirnov 4031db9bf1 perf(@desktop): "make run" boost and build correct qrc 2021-07-19 13:01:53 -04:00
Richard Ramos 5001f36e86 chore: add chronicles configuration to output logs to a file 2021-07-02 08:58:17 -04:00
Michael Bradley, Jr a564b48f61 build: on Linux use tar+gzip to preserve +x attribute of .AppImage
We create a separate make target to avoid tarballing every time.
This is really useful only for releases we upload for users.

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-06-07 14:26:28 -04:00
Jakub Sokołowski af2ec66e0c ci: implement MacOS notarization using xcrun altool
This introduces an automated MacOS notarization process for Jenkins CI.

The process involves:

* Uploading the signed DMG file to the notary service
* Checking periodically if the scanning process has completed
* Stapling the successful scan ticket to the DMG file

This is done by the `scripts/notarize-macos-pkg.sh` via the `make notarize-macos` target.
The whole process is described in more details in `docs/macos_notarization.md`.

Depends on: https://github.com/status-im/status-jenkins-lib/pull/27
Resolves: https://github.com/status-im/status-desktop/issues/2169

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-06-01 09:50:13 -04:00
Michael Bradley, Jr 4e477a5b64 build: bump vendor/DOtherSide
Fix a typo in a recently added header file in DOtherSide that causes problems
on case-sensitive filesystems, e.g. on Linux.

Also unify the build command for DOtherSide across platforms.
2021-05-27 18:25:26 -05:00
Michael Bradley, Jr 89e42f960d build: modify run logic for macOS dev builds so notifications work 2021-05-03 14:06:14 -04:00
Jakub Sokołowski 089ee7ee80 ci: scripts/sign-windows-bin.sh for signing Windows binaries
This introduces the `scripts/sign-windows-bin.sh` script which is used
by the `Makefile` to sign application libraries and executables. It also
implements the logic necessary to distinguish between different types of
builds: release and non-release builds.

Some other changes:

* Refactore the `Makefile` target that creates the Windows ZIP to make less verbose.
* Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component
* Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-28 18:19:17 +02:00
Michael Bradley, Jr 02b26f3c28 build: launch nim_status_client directly in packaged builds for macOS
Remove the `nim_status_client.sh` launcher script and make related changes.
2021-04-28 07:15:44 -05:00
Michael Bradley, Jr 37c51cc25f build: use same container as Jenkins CI for local packaged builds on Linux
Make the docker-related logic for doing a local packaged build on Linux match
with the Jenkins CI build for Linux.

Also fix the problems with packaged builds for Linux (local or CI) where
gstreamer errors were displayed in the terminal shortly after app start/login
and there was no sound output.
2021-04-27 13:49:46 -05:00
Michael Bradley, Jr c03a086c01 feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:

nim_status_client [OPTIONS]...

The following options are available:

 -d, --dataDir      Status Desktop data directory.
```

**Using the option**

```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```

The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.

Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.

The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.

It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```

**Windows**

It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.

For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.

**Linux**

The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:

```
$ Status.AppImage --dataDir:/path/to/wherever
```

For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.

---

BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:

```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```

Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.

At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.

---

Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).

The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.

A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).

Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.

This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.

The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.

---

**NOTES**

More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.

In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.

---

Closes #2268

[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-26 09:40:58 -05:00
Michael Bradley, Jr 7eda54a141 fix: don't run scripts/fetch-brew-bottle.sh in parallel
It's not supported to run `brew update` multiple times simultaenously. A better
fix for this can be implemented, but for now in the Makefile have target
`bottles/pcre` depend on target `bottles/openssl` so that they run serially
when `-jN` is passed to `make`.

I was originally going to change `brew update >/dev/null` to
`brew update >/dev/null || true` but decided the Makefile change provides a
better guarantee that simultaenous `brew` commands won't interfere with each
other. In the process, I revised some of the script's `echo` output just a bit.
2021-04-16 13:16:44 -05:00
Michael Bradley, Jr c5f74ac2c0 build: use GitHub credentials when downloading bottles for macOS
Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-16 10:52:06 -05:00
Michael Bradley, Jr 0832cef36b build: fetch macOS Homebrew bottles from GitHub Packages instead of bintray
bintray (for open source) is shutting down permanently on May 1:

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

At this time downloading from GitHub Packages requires specifying a username
and personal acccess token, but it seems they don't have to be valid. For
example, in the changes to the Makefile I specified `_:_` as the username and
token.

Also, change the minimum macOS version from 10.13 to 10.14 since Homebrew
bottles are no longer built for 10.13 (High Sierra):

https://github.com/Homebrew/discussions/discussions/1264#discussioncomment-601544

Closes #1851
2021-04-14 15:37:53 -04:00
Michael Bradley, Jr 0a77bedb15 chore: revise how dev version of app icon is set on macOS during `make run`
The way it was done previously didn't always produce the intended result (for
unknown reasons), i.e. the dev app would sometimes launch with a transparent
blank square appearing in place of the expected icon.
2021-01-21 15:36:32 -06:00
Michael Bradley, Jr 05f38fa966 chore: refactor prod/dev app icon and related logic for macOS 2021-01-15 19:12:42 -05:00
Michael Bradley, Jr 13daa540e4 build: use a different colored app icon and a non-default STATUS_PORT for dev builds
By default the desktop app uses port 30305, unless a value is specifically set
in environment variable `STATUS_PORT`. For convenience of those developing the
app and running development builds, while simultaneously running production
builds (a.k.a. packaged builds, whether built locally or in CI), have `make
run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can
still be overriden by manually invoking `make run` with a different value,
e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both
valid and achieve the same effect. NOTE: the port "sticks" in the database
after the first clean run, so when changing ports developers will need to
delete the data dir within their local repository, else the existing database
for dev builds will be stuck using whatever port was used previously. In the
future, we can figure out a means to always update the port setting in the
database just after the login event (but see #1505).

Also, for development builds use an icon (for the running app) that is
orangered (`#ff4500`) instead of the official blue color. This makes it much
easier to select between a running production instance and development instance
when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open
applications. Not all icons displayed at runtime have been changed in this
manner for development builds, just the main application icon, and that seems
to be sufficient to achieve the desired effect; though in the future we could
do similar for notification icon, menu bar icon, etc.
2020-12-18 15:37:06 -05:00
Michael Bradley, Jr 8de3a3f48f refactor: in Windows packaged build fleets.json should be in resources/
In the context of Windows packaged builds, this is consistent with other
resources needed by the application; organizing them in this way keeps the
top-level directory of Windows packaged builds clear of files that most users
should never have to see or think about.
2020-12-10 12:03:39 -06:00
Michael Bradley, Jr 10d82124fe refactor: embed Infura key at compile time
Allow environmental override at runtime. Also, in the Makefile set a free-tier
default token so that setting up an Infura account isn't strictly necessary for
community contributors to build the app, even though in our docs it should be
recommended they do so.

Core contributors should setup their own free-tier Infura account, create a
key, and set it in the environment variable INFURA_TOKEN in their environment
used to build the desktop app locally.

There is one aspect of this work that is incomplete. Ideally, in the handler
for the `login` event the relevant settings in the database should always be
updated with the resolved Infura key. However, when calling
`getSetting[string](Setting.Networks_Networks)` in the handler it causes a
segfault every time. Neither the reason for the crash nor a workaround have
been worked out at this time.
2020-12-09 12:10:12 -06:00
Jonathan Rainville 0e874d8745 fix: fix fleets.json file wrongly placed in Windows builds 2020-11-26 11:45:25 -05:00
Jacek Sieka fa3aa77ee5 rcc: single dash options
According to help, options are single-dash - in fact, the default `rcc`
on fedora doesn't accept double-dash.
2020-11-26 11:17:47 -05:00
Richard Ramos cd8f49921f Update docker linux version 2020-11-06 16:22:07 -05:00
Richard Ramos aec77b65df feat: use fleets.json to set the node config 2020-11-05 10:52:56 -05:00
Richard Ramos 48fed85121 test: copying nss libs 2020-10-20 14:42:36 -04:00
Michael Bradley, Jr e985e99f36 feat: reintroduce the dapp browser 2020-10-20 14:42:36 -04:00
Jakub Sokołowski e7c428d3e2 makefile: fix filename of resulting windows zip
Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-09-29 15:11:27 +02:00
Michael Bradley, Jr f6b1f31326 build: don't swallow error when make fails to build bin/nim_status_client 2020-09-03 11:27:25 -05:00
Michael Bradley, Jr 507f510c62 build: dynamically link to status-go built as a shared library 2020-08-28 12:32:49 -04:00
Jonathan Rainville 72af6adb69 feat: get and display emoji reactions in chat 2020-08-27 16:34:35 -04:00
Michael Bradley, Jr c08767c74b build: remove dapp browser 2020-08-17 14:01:26 -04:00
Jonathan Rainville 9466714d90 change path to resources 2020-08-11 17:51:35 -04:00
Jonathan Rainville 24ddb7852c fix Mac i18n location 2020-08-11 17:51:35 -04:00
Jonathan Rainville acc067d536 fix: make packaged translations work 2020-08-11 17:51:35 -04:00
Michael Bradley, Jr e0852d2f73 build: implement code signing step for the Windows build
Add a code signing step to the `pkg-windows` target. If the environment
variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is
skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not
set then a verified timestamp will not be included in the signature. Both
variables should be set in production/CI builds.

Signing is performed with Window's [SignTool][signtool]. There is a helpful
[Stack Overflow answer][soa] which explains how to easily setup a self-signed
CA and code signing certificate and then use them with `signtool`, which is how
I tested these changes on my local Windows machine.

Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally
running other installations of those executables than the ones that ship with
Git Bash. I was experiencing mysterious failures in the sequence of commands
and then noticed that e.g. `which xargs` was resolving to an executable in
`${HOME}/scoop/shims`.

I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and
Windows 10.

For CI builds Status will need to acquire a signing certificate from
e.g. DigiCert. There will be a yearly renewal cost.

In researching what files should be signed, I concluded that it only makes
sense to sign `.dll` and `.exe` files. It's possible to generate signatures for
other file types but the signatures would have to be stored apart from those
files, unlike `.dll` and `.exe` where the signature is embedded in the
executable. Also, it doesn't seem to be possible to embed a signature in a
`.zip` file, though it would be possible to sign the compressed package if we
chose to build and distribute a self-extracting `Status.exe` instead of
`Status.zip`.

If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe
sign` is not invoked on that file.

Closes #288.

[signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool
[soa]: https://stackoverflow.com/a/201277
2020-07-22 10:37:57 -04:00
Michael Bradley, Jr 29e74b6b3f build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.

Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.

`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.

Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.

A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget

The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.

**Why not build an installer?**

When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.

I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.

In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!

[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-17 13:57:32 -05:00
Michael Bradley, Jr b22b500d4f refactor: store data folder in OS appropriate location
If the environment variable `NIM_STATUS_CLIENT_DEV` is not empty then the
`./data` dir is created/used relative to the current working directory, as was
always the case prior to the changes introduced in this commit.

`NIM_STATUS_CLIENT_DEV` is set to `t` when doing `make run`. To get the
production behavior in development do:

```
$ NIM_STATUS_CLIENT_DEV="" make run
```
or on Windows in a Bash shell:
```
$ NIM_STATUS_CLIENT_DEV="" mingw32-make run
```

Closes #391
2020-07-10 16:15:37 -04:00