mcomix3: init at 20201123

[con-f-use]

Motivation for this change

The original mcomix used to be in nixpkgs, but became unmaintained and is not Python 3 compatible. It was subsequently removed. Debian, Archlinux, Fedora and others have switched to it's actively maintained Python 3 fork, mcomix3. This PR packages mcomix3 for nixpkgs.

It is @con-f-use first contribution to nixpkgs, so apologies for any errors or breach of protocol.

Closes #75028.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/packaging-mcomix3-python-gtk-missing-gsettings-schemas-issue/10190/4

[SuperSandro2000]

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

1 package built:

• mcomix3

[SuperSandro2000]

Result of nixpkgs-review pr 104908 run on x86_64-darwin 1

1 package built:

• mcomix3

[AndersonTorres]

Now squash all those small commits to a single commit.

Or, more accurately, two:

• the first including yourself in the maintainers list
• the other including all else, namely, the package expression.

[con-f-use]

Okay, little help with that please, because if I do git branch --set-upstream-to=origin/master; git rebase -i, there is 2000+ commits in that interactive rebase and hundreds of merge conflicts to resolve.

Edit: I think I managed. It was git rebase -i 327338c74a3; git pull; git push -f. Where 327338c74a3 is the last commit before I branched of. I hope that did the trick.

[AndersonTorres]

Usually I just

• fetch upstream;
• rebase upstream/master

After this, the branch is on par with upstream Nixpkgs.

[jtojnar]

But just adding it to buildInputs will not be sufficient. That will only cause it to be on PATH during the build. If you want it to be available at runtime as well, you will need to use wrappers.

…

On Wed, Nov 25, 2020 at 16:09, Ryan Mulligan ***@***.***> wrote: @ryantm commented on this pull request. In pkgs/applications/graphics/mcomix3/default.nix: > + ''; + + # The tests seem to be broken upstream + #checkInputs = [ python3Packages.pytest ]; + #checkPhase = '' + # HOME=$TMPDIR pytest + #''; + # pythonImportsCheck = [ "mcomix" ]; + doCheck = false; + + meta = with stdenv.lib; { + description = "Comic book reader and image viewer; python3 fork of mcomix"; + longDescription = "User-friendly, customizable image viewer, specifically designed to handle comic books and manga supporting a variety of container formats (including CBR, CBZ, CB7, CBT, LHA and PDF)"; + homepage = "https://github.com/multiSnow/mcomix3"; + changelog = "https://github.com/multiSnow/mcomix3/blob/gtk3/ChangeLog"; + license = licenses.gpl2Plus; @SuperSandro2000 Right, they won't be able to build this. @con-f-use If unrar is critical to how it works, I'd say leave it how it is. If not, then your unrarSupport change sounds good. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[con-f-use]

Okay, I'll look into wrapping. Is there a good way, so it doesn't interfere with the wrapping from buildPythonApplication and wrapGAppsHook?

Edit: So, what I'm planing to do is just add wrapProgram "$out/bin/${pname}" --prefix PATH : ${lib.makeBinPath ([ p7zip lhasa mupdf ] ++ lib.optional (unrarSupport) unrar)} to postInstall and taking the respective packages out of the buildInputs.

which results in wrapping all the things:

-r-xr-xr-x 2 root root 2.0K Jan  1  1970 .comicthump-wrapped
-r-xr-xr-x 2 root root 2.4K Jan  1  1970 .mcomix3-wrapped
-r-xr-xr-x 2 root root  391 Jan  1  1970 .mcomix3-wrapped_
-r-xr-xr-x 2 root root 3.1K Jan  1  1970 ..comicthump-wrapped-wrapped
-r-xr-xr-x 2 root root 2.0K Jan  1  1970 ..mcomix3-wrapped-wrapped
-r-xr-xr-x 2 root root 1.8K Jan  1  1970 ...mcomix3-wrapped-wrapped-wrapped
-r-xr-xr-x 2 root root 2.4K Jan  1  1970 comicthump
-r-xr-xr-x 2 root root 2.4K Jan  1  1970 mcomix3

Is that okay? @jtojnar

[AndersonTorres]

I think you will need to wrap the things manually. First, dontWrapGApps = true;

nixpkgs/pkgs/applications/misc/genxword/default.nix

Lines 39 to 45 in ad8238c

	# to prevent double wrapping
	dontWrapGApps = true;
	preFixup = ''
	makeWrapperArgs+=("''${gappsWrapperArgs[@]}")
	'';
	# there are no tests

[con-f-use]

Well, I don't seem to need to, because multiple layers of wrapping are working, the environment variables are all there, once I get to the actual mcomix3 executable, but it would be nicer.

[jtojnar]

You can just add stuff to makeWrapperArgs, which will be picked up by the Python wrapper. If you combine it with #104908 (comment), the python wrapper will also take the data from wrapGAppsHook so you will end up with just a single wrapper.

But yeah, it is a trade off between having nested wrappers and slightly more complicated package expressions.

[con-f-use]

  dontWrapGApps = true;
  preFixup = ''
    makeWrapperArgs+=(
      "''${gappsWrapperArgs[@]}"
      "--prefix" "PATH" ":" "${lib.makeBinPath ([ p7zip lhasa mupdf ] ++ lib.optional (unrarSupport) unrar)}" 
    )
  '';

The --prefix part doesn't seem to work with the python wrapper. And when I set the attribute directly in the nix expression like so:

   makeWrapperArgs = [ "--prefix PATH : ${lib.makeBinPath ([ p7zip lhasa mupdf ] ++ lib.optional (unrarSupport) unrar)}" ];

Then the arguments from wrapGAppsHook don't get passed anymore. Any pointers here?

[jtojnar]

You cannot set makeWrapperArgs in Nix directly, it will get mangled when serialized for bash.

What do you mean the prefix does not work? Is it not appearing in the created wrapper?

[con-f-use]

Nevermind, I think, I'm finally there. Thanks for your insight!

[con-f-use]

Okay, I think I have followed all the suggestions. @jtojnar , please tell me if you now think it's ready to be merged, then I'll squash the commits again, and hopefully be done.

[jtojnar]

Yes it looks okay to me now. Thanks.

[con-f-use]

Okay, commits are squashed, what needs to happen now to get this thing merged?

[jtojnar]

I can merge this once CI finishes. Thanks.

[con-f-use]

Thank you, I learned a lot. CI seems finished...

[jtojnar]

Thanks.