Nixpkgs: mozo (menu editor) does not work in MATE

Created on 10 Jan 2019  路  11Comments  路  Source: NixOS/nixpkgs

Issue description

Traceback (most recent call last):
  File "/nix/store/rz5acy470hvp9pp8wyl0hgmyqrmrfzra-mozo-1.20.1/bin/.mozo-wrapped", line 23, in <module>
    from Mozo.MainWindow import MainWindow
  File "/nix/store/rz5acy470hvp9pp8wyl0hgmyqrmrfzra-mozo-1.20.1/lib/python2.7/site-packages/Mozo/MainWindow.py", line 19, in <module>
    import matemenu
ImportError: No module named matemenu

Steps to reproduce

Install mozo and try to run it.

Technical details

  • system: "x86_64-linux"
  • host os: Linux 4.19.13, NixOS, 19.03.git.acd2756 (Koi)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.1.3
  • channels(shane): ""
  • channels(root): "nixos-19.03pre165037.eebd1a92637"
  • nixpkgs: /pkgs/nixpkgs

Most helpful comment

Honestly none of the mate software in nixpkgs should be at 1.21 since that's a development release.

@r-ryantm strikes again! @ryantm does it support even-number-is-stable versioning?

I've reported this to ryantm and they were kind enough to blacklist mate in https://github.com/ryantm/nixpkgs-update/commit/102a469d94b5b4efcfa7768b191ebcf2322c94f8

If we could add support for this type of versioning it would help.
Though the update script we have currently is functional.

An aside, should we downgrade back to the stable release? I'm not sure how far off 1.22 is from our next stable release, but having unstable mate in 19.03 wouldn't be so great :smile:

All 11 comments

The python binidngs of mate-menus aren't getting built. I'm comparing the Nix derivation to the Debian package, the main difference seems to be that Debian does NOCONFIGURE=1 ./autogen.sh in what would be our preConfigure phase. But I get errors about missing m4 macros when I do this, even though they are there.

./autogen.sh by the way pretty much just calls mate-autogen, which has a check_m4macros function, which maybe is doing something stupid.

I think it's a red herring actually. If I get rid of ./autogen.sh from the debian/rules file and use Debian's built-in autoconf machinery it still generates the python bindings. Our ./configure script isn't even looking for Python.

Okay, it looks like the issue is that mate-menus dropped python2.7 support, but the version in Debian still has it.

I've fixed this on my system with an overlay for mozo-1.21.0. I'm not sure how to make a pull request for something this, I'm also confused if I need both wrapGAppsHook (because it uses gobject-introspection now instead of a direct binding) and wrapPython. If someone wants to give me some guidance, I can make the pull request myself, but for the record, upgrading to mozo-1.21.0 (and switching from Python2 to Python3) would fix this.

I've fixed this on my system with an overlay for mozo-1.21.0. I'm not sure how to make a pull request for something this, I'm also confused if I need both wrapGAppsHook (because it uses gobject-introspection now instead of a direct binding) and wrapPython. If someone wants to give me some guidance, I can make the pull request myself, but for the record, upgrading to mozo-1.21.0 (and switching from Python2 to Python3) would fix this.

Honestly none of the mate software in nixpkgs should be at 1.21 since that's a development release. That's why Debian has the older version.

And if you look at their roadmap the things they've completed so far is:

  • mozo: move to GI package of mate-menus
  • mate-menus: port to Python 3 and gobject-introspection

So this breakage makes sense because we're mixing a newer mate-menus.

Honestly none of the mate software in nixpkgs should be at 1.21 since that's a development release.

@r-ryantm strikes again! @ryantm does it support even-number-is-stable versioning?

Honestly none of the mate software in nixpkgs should be at 1.21 since that's a development release.

@r-ryantm strikes again! @ryantm does it support even-number-is-stable versioning?

I've reported this to ryantm and they were kind enough to blacklist mate in https://github.com/ryantm/nixpkgs-update/commit/102a469d94b5b4efcfa7768b191ebcf2322c94f8

If we could add support for this type of versioning it would help.
Though the update script we have currently is functional.

An aside, should we downgrade back to the stable release? I'm not sure how far off 1.22 is from our next stable release, but having unstable mate in 19.03 wouldn't be so great :smile:

Yes, I'd say just revert the update commits.

The packages should be marked unstable on repology.

Looks like Repology took care of this 4 months ago: https://github.com/repology/repology-rules/issues/75

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  3Comments

matthiasbeyer picture matthiasbeyer  路  3Comments

copumpkin picture copumpkin  路  3Comments

ayyess picture ayyess  路  3Comments

grahamc picture grahamc  路  3Comments