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
Install mozo and try to run it.
"x86_64-linux"Linux 4.19.13, NixOS, 19.03.git.acd2756 (Koi)yesyesnix-env (Nix) 2.1.3"""nixos-19.03pre165037.eebd1a92637"/pkgs/nixpkgsThe 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 usesgobject-introspectionnow instead of a direct binding) andwrapPython. 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:
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
Most helpful comment
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: