mozc: init at unstable-2024-02-09, fcitx5-mozc: 2.26.4220.102 -> unstable-2024-02-09

[musjj]

Description of changes

This upgrades mozc to the latest version (the last version was over 2 years old and suffers from some issues). Consequently, with the deprecation of the GYP I chose to move to the new Bazel build system.

I'm really unfamiliar with Bazel, so I'd really appreciate it if anyone with experience can help check if everything's alright, especially in terms of reproducibility.

I also choose to modularize mozc as a library, so that other packagers can re-use it if they want to.

AUR packages I used for reference:

• https://aur.archlinux.org/packages/mozc-ut
• https://aur.archlinux.org/packages/fcitx5-mozc-ut

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[Vonfry]

I'm not use mozc. The fcitx5-mozc diff is LGTM.

[musjj]

I'm struggling to keep the dependency hash stable. I'm not really sure what's causing the inconsistency though.

I first thought it was caused by the zip code archives, so I mirrored the archive to a tracked git repository to ensure that it's reproducible, but it still breaks anyways.

Anyone have any ideas?
@abbradar Sorry for pinging, but I heard that you're good with Bazel :).

[carpinchomug]

Thank you for your effort to update mozc! I've been trying to do this myself as well, but couldn't figure out how to package a Bazel project.

Unfortunately, I'm not familiar enough with either bazel or mozc to offer help with the hash issue, but I do have a suggestion/request.

mozccan optionally be built with mozc_emacs_helper, which is a helper programs that enables integration of mozc with Emacs.

Currently, mozc_emacs_helper can be built and installed with ibus-engines.mozc. But now that you factored out mozc as a standalone package, I think it makes more sense for mozc_emacs_helper to be provided by this new mozc package rather than by ibus-engines.mozc after this PR is merged.

Reading the build instructions in the mozc repo, adding these lines should build mozc with mozc_emacs_helper. I tested this on my laptop and it seems to be working correctly.

What do you think of these changes?

PS: I have never submitted a review on GitHub before, I'm sorry if I'm not following the right format.

[carpinchomug]

Suggested change

	bazelTargets = [
	"server:mozc_server"
	"gui/tool:mozc_tool"
	];
	bazelTargets = [
	"server:mozc_server"
	"gui/tool:mozc_tool"
	"unix/emacs:mozc_emacs_helper"
	];

Add mozc_emacs_helper to build targets.

[carpinchomug]

Suggested change

	sed -ri -e "s|^(EMACS_MOZC_HELPER_DIR = ).+|\1\"$out/bin\"|" mozc/src/config.bzl

Fix the install path for mozc_emacs_helper.

[carpinchomug]

Suggested change

	mkdir -p $out/bin
	cp bazel-bin/unix/emacs/mozc_emacs_helper $out/bin/mozc_emacs_helper

Install mozc_emacs_helper.

[musjj]

@carpinchomug

Thanks for the suggestion, but I think this should be a separate package. The point of the mozc package is solely to provide the mozc_{server,tool} library for other packages.

If you're looking to make a package for this, you can look at fcitx5-mozc.nix in this PR and this AUR package for reference.

[h7x4]

Result of nixpkgs-review pr 251706 run on x86_64-linux 1

2 packages built:

• fcitx5-mozc
• mozc

[musjj]

I rebased and updated the packages. I also made a new repository to solve the jawiki issue: https://github.com/musjj/jawiki-archive.

@stephen-huan

Sorry for the late reply.

As suggested in #296035 (comment) I think it is cleaner to split the dictionary into a separate derivation (e.g. mozcdic-ut).

How would this work? Should it be split into 3 different packages like:

• mozcdic-ut
• mozc
• mozc-ut

What do you think?

I might wait out and see if @pineapplehunter's #314248 gets merged since it seems like it fulfills the concerns around modularity better.

[stephen-huan]

The split into mozcdic-ut, mozc, mozc-ut sounds good. #314248 is actually more fine-grain than that (it further splits mozcdic-ut into its requisite dictionaries, but this is mostly for ease of auto-update). I'm not sure whether it will be merged soon though, it's still marked as draft.

[h7x4]

@musjj Now that #314248 is merged, are you up to the task of rewriting this PR to have fcitx5-mozc use the newly added sources (or alternatively open new PR if you'd like)? I realize that I'm asking you for a whole new chunk of work, so feel free to say no if you don't want to :)

[musjj]

Yeah, I think it's better to open a new PR.

Closed in favor of: #346680