Package request: Maemo Leste (Maemo 7) / Hildon Desktop

[Kreyren]

Project description

Graphical user environment for handheld devices originally designed for Nokia N900 (RX-51) by Nokia (pre-microsoft), now actively maintained by the community and designed/works on:

• arm64-generic
• atrix2
• bionic
• droid3
• droid4
• mz617
• Nokia N9
• Nokia N950
• Olimex Lime 2
• Pinephone
• Pinephone-dontbeevil
• raspi2,3,4
• sunxi
• turbox-twisted
• Xt910
• xt912
• ...

Video Showcase: https://www.youtube.com/watch?v=M28Ojvg9i9Q

Metadata

• homepage URL: https://maemo-leste.github.io/
• source URL: https://github.com/maemo-leste
• license: gpl2
• platforms: unix

---

Add a 👍 reaction to issues you find important.

[Sigmanificient]

Did you meant https://github.com/maemo-leste/hildon-desktop for the source?

[Kreyren]

Did you meant maemo-leste/hildon-desktop for the source? -- @Sigmanificient (#328952 (comment))

Afaik that's only the backend? While maemo runs on top of it?

[Sigmanificient]

just to clarfy cause there is like 266 repos in that org 😅

[Kreyren]

just to clarfy cause there is like 266 repos 😅 -- @Sigmanificient (#328952 (comment))

tbh i have no idea how to piece it together it seems to be like somewhat like GNOME in terms of complexity without any available docs that i could find for the packaging

CC @MerlijnWajer @dderby @pali @parazyd (Maemo Leste Public GiHub Org Members) for packaging informations

[Sigmanificient]

base derivation would be

{
  lib,
  stdenv,
  fetchFromGitHub,
  autoconf,
  autoconf-archive,
  automake,
  pkg-config,
  glib,
  libtool,

  gnome2,
  dbus,
  xorg,
  libcanberra,
  gnome-menus,
  gdk-pixbuf-xlib,
  libmatchbox
}:

stdenv.mkDerivation (finalAttrs: {
  pname = "hildon-desktop";
  version = "2.2.194";

  src = fetchFromGitHub {
    owner = "maemo-leste";
    repo = "hildon-desktop";
    rev = "refs/tags/${finalAttrs.version}";
    hash = "sha256-86ilVylbRUnSkm2Ujm580g3IfTDlKvkNB2nq/6hCNHU=";
  };

  nativeBuildInputs = [
    autoconf
    autoconf-archive
    automake
    pkg-config
  ];

  buildInputs = [
    glib
    libtool
    # clutter # dont match clutter-0.8
    gnome2.GConf
    dbus
    libcanberra
    gnome-menus
    gdk-pixbuf-xlib
    libmatchbox
  ] ++ (with xorg; [
    libX11
    libXcomposite
    libXft
  ]);

  preConfigure = "./autogen.sh";

  meta = {
    maintainers = with lib.maintainers; [ simganificient ];
    license = lib.licenses.gpl2;
  };
})

But it s missing some deps. Real problem is mce which have some hard-coded path in its 'CMakeLists` that i am unsure how to deal with.

Here the starter derivation:

{
  lib,
  stdenv,
  fetchFromGitHub,
  cmake,
  pkg-config,

  dbus,
  dbus-glib,
  glib
}:

stdenv.mkDerivation (finalAttrs: {
  pname = "mce";
  version = "1.10.9";

  src = fetchFromGitHub {
    owner = "maemo-leste";
    repo = "mce";
    rev = "refs/tags/${finalAttrs.version}";
    hash = "sha256-W0seXFNlUq1+XtaeXQUzGXDnKgUQC45gryCF0wb9bBk=";
  };

  nativeBuildInputs = [
    cmake
    pkg-config
  ];

  buildInputs = [
    dbus
    dbus-glib
    glib
  ];

  meta = {
    maintainers = with lib.maintainers; [ simganificient ];
    license = lib.licenses.gpl2;
  };
})

[Kreyren]

You mean these?

https://github.com/maemo-leste/mce/blob/b54ad2ba4798b6d097675496f414ab05f6157412/CMakeLists.txt#L5-L11

If so then the NixOS-way would probably be to substitute them? Or could this be implemented upstream to not be so dependent on FHS 3.0?

[Sigmanificient]

You mean these?

maemo-leste/mce@b54ad2b/CMakeLists.txt#L5-L11

If so then the NixOS-way would probably be to substitute them? Or could this be implemented upstream to not be so dependent on FHS 3.0?

Yeah but the question is, fixing them with what

[Sigmanificient]

I've opened up a draft pr, will be continuing working tomorrow

[Kreyren]

set(MCE_CONF_DIR /etc/mce)
set(MCE_CONF_OVR_DIR mce.ini.d)
set(MCE_MODULE_DIR lib/mce/modules)
set(MCE_RUN_DIR /var/run/mce)
set(MCE_VAR_DIR /var/lib/mce)

These seem sane for a NixOS filesystem right?

set(MCE_GCONF_DIR /etc/gconf/schemas/)

Afaik this will have to point to a nix store like GTK is doing for lot of things

set(DBUS_CONF_DIR /etc/dbus-1/system.d)

No idea tbh..

Asked in Nix Devel for help

[Kreyren]

I've opened up a draft pr, will be continuing working tomorrow -- @Sigmanificient (#328952 (comment))

Oke, thanks for working on this! <3

[MerlijnWajer]

Hi - one of the Maemo Leste developers here - just to add some context, there are indeed a lot of repos. The "core" of Maemo Leste is about 287 packages, but this includes basically a fully fledged system.

You can get a pretty basic proof of concept going with way fewer packages of course (and I could provide some guidance on where to start), but the one thing that really should be mentioned is that we patch gtk2: https://github.com/maemo-leste/gtk/tree/maemo/chimaera/debian/patches

Since Maemo Leste is currently it's own debian-based distro we have no problems patching the system-wide gtk2, but I assume this might not be the case for NixOS.

I don't know enough about NixOS to suggest how this should or should not be handled. Please feel free to ask any questions here or elsewhere and I'll try to my best to answer.

[Kreyren]

Hi - one of the Maemo Leste developers here -- @MerlijnWajer (#328952 (comment))

Thank you for looking into this! Your input is very appreciated! <3

The "core" of Maemo Leste is about 287 packages, but this includes basically a fully fledged system. -- @MerlijnWajer (#328952 (comment))

A fully fledged system for e.g. NiXium's WIldBeast system which is my personal Nokia N900 is the projected end-goal of this issue.

Since Maemo Leste is currently it's own debian-based distro we have no problems patching the system-wide gtk2, but I assume this might not be the case for NixOS. [...] I don't know enough about NixOS to suggest how this should or should not be handled. -- @MerlijnWajer (#328952 (comment))

Simplified: Nix manages the issue of dependency hell by interpreting package instructions for building them from source in a reproducible environment with the runtime dependencies packed with the package that is provided through environmental variables and invidual library linking from a special file hierarchy management (the package manager interprets the building instructions as result and places them in a read-only directory that only nix is designed to write to from which they are linked).
So the system can without issues have multiple versions of gtk2 per package if the package requires it for various issues, though single version is preferred to avoid having this added complexity for nix to just re-use the dependency instead of making a special one.

So in practice we can just provide instructions for how to adjust the gtk2 and it won't interfiere with other packages same for other dependencies and we can skip the builds by using cache similar to how docker interprets dockerfiles.

Community member Chris McDonough made a quick video explaining the relevant Nix PhD Thesis if you want to know in detail how is this managed: https://youtu.be/usrdGqcq-Xc?t=34 (JumpCutter extension recommended as they do a lot of "ehh.." and have a long pauses between sentences)

You can get a pretty basic proof of concept going with way fewer packages of course (and I could provide some guidance on where to start), but the one thing that really should be mentioned is that we patch gtk2: maemo-leste/gtk@maemo/chimaera/debian/patches -- @MerlijnWajer (#328952 (comment))

Is there anything else that needs to be patched or needs a special treatment?

Ideally we need a list of packages that are expected to be packaged with what dependencies and how to process them e.g. what commands to use to configure, compile them and what to install to the filesystem

NOTE: NixOS uses bash internally so if you have some scripts that generate .deb for apt we can very easily adjust them for Nix which would make the packaging of all of the 287 repositories (assuming all of them are needed as packages) very resource efficient.

[emilazy]

This depends on GTK 2, which we’re trying to get rid of. We shouldn’t add a completely new set of desktop environment packages using a toolkit that has been out of support for many years. People who are interested can maintain it in another repository.

[Kreyren]

This depends on GTK 2, which we’re trying to get rid of. We shouldn’t add a completely new set of desktop environment packages using a toolkit that has been out of support for many years. People who are interested can maintain it in another repository. -- @emilazy (#328952 (comment))

Upstream said that they are working on migrating on GTK3+ or Qt, but it's a huge task that they lack resources to do so efficiently atm.. They said that they might be able to maintain gtk2 to apply security patches as extended support if that would help?

For context hildon-desktop was originally developed by Nokia and it has a lot of components where there isn't any GUI-based alternative for the kinda unique formfactor of Nokia N900 atm