Add DataZen

[probonopd]

Repository: https://github.com/flyxl/datazen

Lightweight GPL-3.0 desktop database client (PostgreSQL / MySQL / SQLite / Redis). Built with Tauri + Rust, under 15MB.

• Stars: 100
• Latest release: v0.2.2 (2026-09-27T07:44:15Z)
• AppImage asset: DataZen-0.2.2-linux-x64.AppImage
• License: GPL-3.0

Found by .github/workflows/discover-apps.yml, which looks for GitHub
repositories that publish AppImages but are not in the catalog yet. This
entry was not tested by a human; please review it before merging.

[github-actions]

❌ Test failure

@flyxl: this pull request adds the AppImage from your GitHub repository to the AppImage catalog; the test reports the following. Could you have a look?

Names:

WARNING: AppImage name 'DataZen-0.2.2-linux-x64.AppImage': should not contain 'Linux', since all AppImages are for Linux (e.g. 'App-1.0-x86_64.AppImage', not 'App-1.0-linux-x86_64.AppImage')

• Please check the remarks about the names below.
• The AppImage is missing a required file (see below). See https://docs.appimage.org/reference/appdir.html for what an AppImage must contain.

First error in the log:

FATAL: .DirIcon is missing in /tmp/.mount_runtimdCdCIm

Commit 1d6b5e7. Full log

[flyxl]

Hi @probonopd — thank you for the report. Both issues are fixed and shipped in the new DataZen v0.2.3 release:

1. Name — the Linux AppImage is now named DataZen-0.2.3-x86_64.AppImage (no "linux" segment, arch spelled x86_64), following the AppImage naming convention.

2. .DirIcon missing — root cause was in our build pipeline: tauri-bundler creates .DirIcon in the AppDir, but the pinned linuxdeploy strips it while repacking the squashfs. The release workflow now re-injects .DirIcon, the root icon and the root .desktop entry after the build, repacks with appimagetool, and re-signs the updater artifact. The v0.2.3 AppImage contains .DirIcon pointing to a PNG, a single root DataZen.desktop, and an executable AppRun (verified by desktop-file-validate).

Could you please re-run the test when you get a chance? Thanks!

[github-actions]

❌ Test failure

Compatibility: not self-contained: uses the C library of the system; references glibc 2.35

• A file inside the AppImage is not executable. Please check the file permissions before packaging the AppImage.
• The application quit or crashed right after starting. The error below usually shows why.

First error in the log:

/bin/bash: line 1: /run/firejail/appimage/AppRun: Permission denied

The application showed no window, but may be a system tray application (usr/lib/libayatana-appindicator3.so.1: libayatana-appindicator3.so.1); running it again with a system tray
/bin/bash: line 1: /run/firejail/appimage/AppRun: Permission denied
No icon appeared in the system tray either
ERROR: The application exited within 11 seconds instead of showing a window

What next: once the AppImage is fixed (e.g. in a new release), comment /retest here to test it again. If it should not be in the catalog after all, close this pull request; an app that is already in the catalog can be removed by a maintainer with /remove.

Commit 1d6b5e7. Full log

[flyxl]

An update on the re-test (run #36683843278):

The previously reported AppImage structure issues are now fixed and verified — the test got past all of them:

• No more name warning (names.txt was empty — DataZen-0.2.3-x86_64.AppImage passes check-name.sh)
• .DirIcon, AppRun, the single root .desktop and the icon lookup all passed (the image mounted successfully and desktop-file-validate is clean)

The remaining failure is now in the final "run the app under Xvfb/firejail and screenshot" step:

ERROR: The application exited within 11 seconds instead of showing a window
worker.sh exited with a non-zero code: 1

DataZen is a Tauri/WebKitGTK app — worker.sh already notes that "WebKitGTK-based apps (Tauri, ...) render a blank white window when their GPU-accelerated compositing fails". Under headless Xvfb (no GPU) the WebKit compositor fails and the process exits; the app also bundles libayatana-appindicator3 so it was retried as a tray app, which also showed no window.

This looks like the known headless-WebKitGTK screenshot limitation rather than a defect in the AppImage (the app runs fine on a real desktop). Could you confirm if there is a standard workaround for Tauri/WebKitGTK apps in the test harness (e.g. disabling GPU compositing / software rendering for the screenshot step)? Happy to adjust the app if a specific environment variable or launch flag would let it render under Xvfb.

Thanks!

[github-actions]

❌ Test failure

Compatibility: not self-contained: uses the C library of the system; references glibc 2.35

• A file inside the AppImage is not executable. Please check the file permissions before packaging the AppImage.
• The application quit or crashed right after starting. The error below usually shows why.

First error in the log:

/bin/bash: line 1: /run/firejail/appimage/AppRun: Permission denied

The application showed no window, but may be a system tray application (usr/lib/libayatana-appindicator3.so.1: libayatana-appindicator3.so.1); running it again with a system tray
/bin/bash: line 1: /run/firejail/appimage/AppRun: Permission denied
No icon appeared in the system tray either
ERROR: The application exited within 11 seconds instead of showing a window

What next: once the AppImage is fixed (e.g. in a new release), comment /retest here to test it again. If it should not be in the catalog after all, close this pull request; an app that is already in the catalog can be removed by a maintainer with /remove.

Commit 1d6b5e7. Full log