logseq_2: init at 2.0.1, logseq-og: rename from logseq, 0.10.15 -> 1.0.0-unstable-2026-05-28

[TomaSajt]

This is the new db based Logseq! I'm not sure how much issue it causes if you try this out but go back to using the old version.

Things have changed in the packaging since the last release.

First, we're using pnpm now, so the tooling had to be switched up. Using pnpm is a bit cleaner than yarn, but both have their pros and cons.

Second, the number of git repo based clojure dependencies have increased significantly, so instead of manually patching in each git repo source, I opted to dive into the source code of the clojure CLI to figure out how to trick it into using prefetched git dependencies.
The main trick was just letting it first clone everything into it's normal location and then strip down the bare repos into the smallest form that the CLI still thinks is valid.

Third, there is a new cli tool, which would be installed to the PATH upon running the desktop app, but I patched it out and added it into $out/bin. Though, this means that I had to rename the desktop app's executable name to something else.

This CLI app is generated from OCaml, so I had to add some unpackaged OCaml packages to passthru.

Electron 40+ support was fixed in logseq/logseq#12741

TODO: figure out how to circumvent the venv logic inside the package.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[brokenpip3]

based on the gh repo (logseq/logseq) the changes that you are making will build the db version, right? since now the markdown based one it's hosted at logseq/og

thanks for trying to build it btw!!

[TomaSajt]

Yes, this is the db version.
Should I still package the OG version?

[brokenpip3]

Should I still package the OG version?

Not at all, since the OG version is in "maintenance" mode, they will keep it alive but no more features, afaik.

[TomaSajt]

In theory, the OCaml packaging is done. I still have one TODO, but other than that, the PR is ready for review again.
Please try it out at leave a comment if everything's working okay or if it's broken in some way.

[TomaSajt]

@vbgl could you take a quick look at whether I'm doing the OCaml packaging correctly?

e.g. melange-fetch could be included in ocamlPackages, and I didn't place it there. Should I?

[amarshall]

logseq-og should be bin/logseq-og and also name in desktop file should be updated, so as to allow logseq and logseq-og installed simultaneously.

[amarshall]

Consider using latest from Git instead, since that has crucial fixes:

• electron_41 support
• fixes various uses of logseq instead of logseq-og

[TomaSajt]

Upstream did NOT fix Electron 39+ support, the commit you're talking about just bumps the Electron version used.
Upstream is not responding to the issue: logseq/og#32

(The thing that's broken is plugin loading, so if you're not using plugins, using newer electron is fine)

[TomaSajt]

I updated to the latest revision anyways, because they changed the internals a little bit to not conflict with the non-OG version.

[TomaSajt]

To the people, who are subscribed to this PR, have you had any issues with the logseq_2 package? Please also share if you have had no issues.

Also, if anyone's on aarch64-darwin could you try out whether semantic search is working for you? It's apparently a aarch64-darwin-only feature you can enable in the setting, but it tries to install some python packages via venv. I did not patch out this logic yet, as I have no way to test it currently, but I am interested if it works without any patches.

[TomaSajt]

Another thing: what do you guys think, should the old logseq name point to logseq_2, logseq-og or neither.
By neither I mean that if you try to use logseq it will give you an error saying that you need to choose between explicitly using logseq-og and logseq_2.

If we ever backport this (which might not happen, honestly), I'll keep the stable branch's logseq pointing to logseq-og.

[NectoT]

To the people, who are subscribed to this PR, have you had any issues with the logseq_2 package? Please also share if you have had no issues.

I was using the AppImage version, but this prompted me to finally check the PR package. I copied the two files for logseq_2 and built the package without issues on x86_64 linux, using the unstable channel.

So far everything works without issues, although I don't use Logseq too heavily..

[noahcout]

Another thing: what do you guys think, should the old logseq name point to logseq_2, logseq-og or neither.

Just going to say I believe logseq should point to the new logseq_2. If you look at this post they are basically saying that logseq-og will only be maintained and not receive newer features. I think future users wanting to start using logseq would likely want to get started with the version with all features.

[TomaSajt]

Pushed a commit adding the changes from logseq/og#50 allowing the usage of Electron 40+ for OG

I did not review everything, but to be safe and to save filesize, I removed the minified .js part that was included in the PR and regenerated it from the .ts files.

[MajorMajorMajorMajor]

Another thing: what do you guys think, should the old logseq name point to logseq_2, logseq-og or neither.

Just going to say I believe logseq should point to the new logseq_2. If you look at this post they are basically saying that logseq-og will only be maintained and not receive newer features. I think future users wanting to start using logseq would likely want to get started with the version with all features.

Unfortunately logseq_2 is packed with anti-features, especially the database backend. The .md file backend of the original logseq is its key distinguishing feature, which makes it easy trivially easy to sync and merge changes using any tool that supports text files. From my point of view, Logseq 2 is dead-on-arrival; I will never install it.

I am hoping that since logseq 1 is open source, there will be sufficient community support to keep it working smoothly. This was the entire premise of its original marketing as fully open source software: so that it would continue to work when it is inevitably abandoned or enshittificated by the developer (bringing us to today).

[codesalatdev]

Another thing: what do you guys think, should the old logseq name point to logseq_2, logseq-og or neither.

Just going to say I believe logseq should point to the new logseq_2. If you look at this post they are basically saying that logseq-og will only be maintained and not receive newer features. I think future users wanting to start using logseq would likely want to get started with the version with all features.

I second this. logseq should point to the DB version. MD (or OG) has abysmal performance for large graphs and should IMO not be relied on for as long as it's in maintenance mode.