Maemo-Leste pre-alpha announcement
 

Hi,

We're happy to let you know about the pre-alpha release of "Maemo Leste" - an attempt to port/run large parts/bits from Fremantle on the latest stable Devuan/Debian.

There are currently SD-card images of the pre-alpha version available for the N900, you can find them on our (temporary?) website: https://maemo-leste.github.io/pages/n900-status.html

You will need u-boot (bootmenu) from Pali: http://talk.maemo.org/showthread.php?t=81613

We also wrote our first "status update": https://maemo-leste.github.io/maemo-...of-giants.html - which also talks about other devices that are partially supported and could perhaps be used for development as well. Please check out this news post to see what the current status is.

https://maemo-leste.github.io/

The software is not ready for end users -- but we could REALLY use more developers! So if you're interested, but not sure how you could help out, please post here, or talk to us on #maemo or #maemo-leste on Freenode. Or file an issue on Github: https://github.com/maemo-leste/bugtracker/

Here are some additional photos and screenshot:

https://maemo-leste.github.io/images...h-d-n900-3.jpg
https://maemo-leste.github.io/images...h-d-n900-4.jpg

Re: Maemo-Leste pre-alpha announcement
 

Wow great work I will try the image in the next days. What kind of sdk or toolchain you suggesting to use for development?
Which qt version will be possible 4.7 from maemo or the newer from devuan.
Thanks for releasing this alpha.

Re: Maemo-Leste pre-alpha announcement
 

Wow. Porting Hildon to a newer Debian release. Way to go guys.

Re: Maemo-Leste pre-alpha announcement
 

I guess I found a way to re use the N900 once again. I will test it. Thank you very much for your support and your hard work!!!!

Re: Maemo-Leste pre-alpha announcement
 

This is the most exciting info I learned recently! The most!!

Re: Maemo-Leste pre-alpha announcement
 

Regarding an SDK, we usually just build natively on the arch we like to work on (amd64 for freemangordon, I usually work on armhf since my laptop in armhf)

Our Jenkins CI doesn't use qemu to build, I have an arm64 machine that we use for armel and armhf builds, an amd64 is done natively on the jenkins server.

We will have to take the cssu Qt build and see if we just build that, or go with the one from Debian/Devuan. See this issue: https://github.com/maemo-leste/bugtracker/issues/53

Re: Maemo-Leste pre-alpha announcement
 

Yay I got i booting through the flasher.
As freemangordon pointed out that zImage is needed for booting through the flasher and Wizzup gave the hint to read out the zImage from an uImage I got it running.

So take the uImage from the smaller partition of the sd card.

convert:
boot:
or

Re: Maemo-Leste pre-alpha announcement
 

It would be nice if they could co exists and maybe later porting qt-maemo stuff to qt5?
Yeah not all applications using gtk:).

Re: Maemo-Leste pre-alpha announcement
 

Do you have a virtual box image? Could be worthwhile to let people try it out or just have instructions to get people started.

One area that might need a little cosmetic work is osso-xterm settings. From when I played with it last the settings doesn't match the style of other apps. It's a bit cluttered.

Re: Maemo-Leste pre-alpha announcement
 

Not yet, but we should have one pretty soon: https://github.com/maemo-leste/bugtracker/issues/45

Re: Maemo-Leste pre-alpha announcement
 

Hi Wizzup_

For sometime I've been working of my own mobile OS, initially with Debian on the N900 but more recently I've been reworking these scripts (not yet public) to run with Devuan and to separate out device specific config to make them multi-device, initially with support the N900 and Droid 4, and support for N950 and N9 coming shortly after. Unfortunately in the last few months I've been too busy with work and haven't had enough time to complete them. My general idea was to make them as generic as possible in order to produce basic image builds for a variety of devices by just specifying a defconfig and dts already present in mainline Linux. The idea behind this was that by having basic images for a variety of devices, even if untested, it might encourage new developers to try them and start contributing further hardware adaptations (bootloader config and mainline Linux). I've been tracking devices with mainline support here and keeping it up to date, although I still need to check if anything interesting has gone in since the merge window opened for Linux 4.16.

I've known about Maemo Leste for while now and I've been meaning to contact you. I don't know if my scripts would be useful to you. I haven't yet looked into how your builds are produced but it shouldn't require much effort to adapt my scripts to produce Maemo Leste builds should you be interested.

By any means, you can count on me to help out with Maemo Leste. I certainly would like to contribute to it. I have my own ideas about how a free mobile operating system should be produced and Maemo Leste is the first effort I've seen that aligns with most of them. Given my limited free time, it makes sense to join forces rather than continue with my one man effort. I could probably help with producing images for N950 and N9 which have seen significant progress recently in mainline (although I don't yet have an N9 for testing).

I'll try to reach out to you on Freenode sometime this week to discuss how I might be able to contribute. Otherwise, feel free to respond in this thread or by PM.

Re: Maemo-Leste pre-alpha announcement
 

I've been thinking recently about how original N900 is, well, not so great because of bugs and lack of RAM. The alternative is to create new hardware (I know about Neo900...) and reducing bugs.

How far from here or fully ported maemo is to make it independent from omap architecture?

I would love to contribute but I don't know much about programming in Linux :(

Re: Maemo-Leste pre-alpha announcement
 

@wicket - We'll definitely appreciate your help, there are tasks that need more thinking than coding (fixing the spaghetti fremantle boot process is for example), so even if you lack time to do programming, your experience will help a lot.

Not sure what your vision about free mobile linux is, however what we aim is a device independent distro, to the extent that's possible given that usually each device needs it's own kernel. Though that seems to change with DT. And by device independent, we don't only aim ARM world - actually most of the development so far was done in amd64 VM that boots to hildon-desktop in exactly the same way n900 or allwinner does.

Having such a base we can strip lots of fat, in terms of scratchbox for example.

Wizzup can elaborate on the the build system (jenkins) , but I think it is more or less functional and stable.

So, please join ##fptf-private, at least to see how is the cooperation going on :) .

Re: Maemo-Leste pre-alpha announcement
 

In terms of getting a Virtualbox/VMWare image running, would I just do a minimal Devuan install and then add a custom repo to pull the packages or are they still only in git?

Re: Maemo-Leste pre-alpha announcement
 

The actual packages also work on Allwinner ARM devices (apart from some device specific features in mce, but those can be ported/fixed), so we are already not necessarily dependent on omap.

Re: Maemo-Leste pre-alpha announcement
 

Add the testing key from here: http://maedevu.maemo.org/

And then add the 'kawai' repo (we will soon rename that to leste again, we initially aimed for jessie with leste, and used kawai as temporary name for stretch/ascii, but now it's confusing).

Then install hildon-meta, but make sure that apt doesn't start services while installing (RUNLEVEL=1 apt-get install hildon-meta)

I think Parazyd is working on Vbox images, not sure how far he is, I think he is pretty close, he already has something that generates images for Devuan, so he just needs to add the Maemo Leste script(s).

Re: Maemo-Leste pre-alpha announcement
 

Cool, nice list of devices with mainline support, we could try to extend our support for some of those devices given time and demand. Freemangordon has hildon-desktop, mce, dsme and all the other things on an Allwinner A33 tablet - similar to Q8 tablets I think.

Parazyd is doing the actual image building (also for Devuan, he's a devuan dev), and I've worked with him in setting up the Jenkins (auto)building and repository generation. It would be useful to see your scripts and see if/how we can use them to extend our builds.

Would love to join forces. I don't have either a N9 or N950, so that'd be a great addition. I'm "Wizzup" on Freenode, but we're also in #maemo-leste and ##fptf-private - our dev channel (might move all of it to #maemo-leste or #maemo at some point, just takes time to sort these things :))

Re: Maemo-Leste pre-alpha announcement
 

Nice work! Would be great to see if you could work together with postmarketOS as well as they are moving in the same direction, and have a large list of ported devices.

Also, will maemo-leste support the existing applications on the community repository?

Re: Maemo-Leste pre-alpha announcement
 

Running an updated kernel, glibc etc it would be interesting to see if there are any performance gains over Fremantle. Due to current graphics stack Todo items and lack of some components like the telephony stack a benchmark test wouldn't be fair to either variant.

I've know Dosbox was a lot faster after making use of some newer arm instructions (armv6 iirc).

Re: Maemo-Leste pre-alpha announcement
 

We've been collaborating on some points - they actively watch our bugtracker, and we watch theirs (to some degree :)). Personally, I think the goals might be different - from my pespective they seem to work on a lot of devices and offer a lot of choice, while our goal is "more simple" (in some sense), we want to offer the Maemo experience, first on the N900, and then on some other devices.

Additionally, I'm personally not satisfied with older vendor kernels, so I'd really want to push for a 'mainline only' (or very close to) policy. I believe postmarketOS is also pushing for this, but they (AFAIK, could be wrong) also ship various devices with Android kernels, I believe.

But others know more about pmOS. Both projects exist, and I think it's important that we collaborate. But don't expect Maemo Leste to switch to KDE plasma any time soon, so to say.

Re: Maemo-Leste pre-alpha announcement
 

Virtual machine images are up (qemu and virtualbox). Also new N900 images (armhf and armel, armel is untested).

There are no changes on the N900 images, except that the repos now point to 'leste' and not 'kawai', since this rightfully confused some. ('kawai' is our name for testing, and no, it's not 'kawaii')

There's been some activity on the bugtracker, regarding gps, phone calls, and pulseaudio. I wonder what is the best way to coordinate between all interested parties. Maybe a mailing list?

http://maedevu.maemo.org/images/20180207/

Maybe someone can port and build 'extmou', so that cursors are visible in the virtual images: https://github.com/maemo-leste/bugtracker/issues/50

Re: Maemo-Leste pre-alpha announcement
 

Is it possible to run these images on (high end) smartphones?

Re: Maemo-Leste pre-alpha announcement
 

Sounds like the answer depends on: is that smartphone supported on mainline Linux ... So I guess quickest answer is No, at least not yet.
And of course the images provided are for specific devices, although you can build for other devices too

Re: Maemo-Leste pre-alpha announcement
 

This is not a good idea, extmou was an ugly hack I invented to overcome the way mouse cursor is hidden in fremantle (by using an empty cursor). if one wants cursor in the VM or on device, all she needs is to install (or link) to the appropriate cursor theme.

Re: Maemo-Leste pre-alpha announcement
 

With regards to extmou, would it be worth enumerating input devices in hildon-desktop and show/hide based on last input event?

Re: Maemo-Leste pre-alpha announcement
 

Or better - enumerate input devices on such device added/removed and show the cursor if there is at least one device of type mouse.

EDIT: I think they did something similar in cordia, we can just reuse it.

EDIT2: this

Re: Maemo-Leste pre-alpha announcement
 

Yeah, that's the one. Not 100% sure it worked correctly on my Cordia based port or if it made it in to the Fremantle-GTK3 version.

Re: Maemo-Leste pre-alpha announcement
 

but qemu is available for Android?
(Like Limbo https://limboemulator.weebly.com/)

Re: Maemo-Leste pre-alpha announcement
 

Oh wow! That I wasn't aware of. Probably might work :-)

Re: Maemo-Leste pre-alpha announcement
 

The Limbo app has even settings for the N800 and the N810 :p

Edit: There are a lot of settings to choose from, couldn't get it to work :(

Is there also a Kernel and Initrd available?

Edit2: Ok got it to work using the amd64 build
I hope to see some arm builds will show up :)

Re: Maemo-Leste pre-alpha announcement
 

Has anyone had any luck getting Virtualbox Guest Additions to work?

After installing the GA's it just goes to black screen. With 3D acceleration enabled in machine settings for the VM it spews out VERR_BUFFER_OVERFLOW message in another VT, without its just black.

Edit: reverted to stock image. First boot fails to start X, second seems to work ok. Not going to try GA's yet.

Re: Maemo-Leste pre-alpha announcement
 

Limbo....eh?
hm..
Wonder if this app is any relation at all to the programming language for Inferno os ...which also runs on the n8x0.
3rd step-cousin twice removed ?

Re: Maemo-Leste pre-alpha announcement
 

As you've probably already noticed, I've been adding comments to the GitHub issues where I feel I my input might be useful. The spaghetti Fremantle boot process might be interesting. I'll take a look at what Leste is currently doing to bring up Hildon and get back to you on that one.

My vision of free mobile Linux is to start off with a solid base. By this I mean build off mainline Linux and build on top of an existing mainstream distro. When starting out small, it's the only sustainable way of keeping it up to date and to ensure that security fixes are delivered in a timely manner. Leste is the first mobile Linux to get this right. postmarketOS half got it right but it's more focused on being an after-market OS for Android devices where mainline Linux is a secondary goal.

I'm actually less concerned about the GUI. Hildon is obviously a welcome addition. We need a GUI anyway.

I wanted to create a device independent mobile Linux base, based the above ideas. My plan was to create a free version and a non-free version. The non-free version would be something somewhat similar to Leste and would include blobs needed to make it as functional as possible. The free version would obviously be less functional but in the case of the N900 for example, all that would be missing would be video acceleration, Wi-Fi and Bluetooth.

I think there is a need for a mobile OS that can be 100% vetted and this can only be done with free software. The US has virtually complete control all mobile operating systems and I'm surprised this sits well with most countries. I often wonder what kind of mobile phones are issued by non-US governments to their officials. It seems that only the Russians were smart enough to realise the problem. They funded some ex-Nokia employees to make a certain OS well known to this forum ;). Unfortunately they don't want to share all of it with the rest of the world and most ports are stuck with Android kernel forks.

You've seen my list of mainline Linux devices. My next list will be of SoCs used in modern phones which already have mainline support but no device support other than dev/evaluation boards. A lot of people are unaware how much work has already been done in mainline. Like I said in my previous post, I want too try to encourage contributions and it might help if more people knew they would not need to start from scratch.

That's the basis of my vision. I could elaborate more but that's a discussion for another day. :)

I found the image-builder and jenkins-integration repos on GitHub so I'll see if I can figure it out.

I've not had a chance to talk on Freenode yet, I can probably get on there tomorrow.

Re: Maemo-Leste pre-alpha announcement
 

I'm looking forward to working together! Once I'm familiar with how your images are built, we can discuss what can be done to extend your builds. I think I covered the rest in my reply to freemangordon.

Re: Maemo-Leste pre-alpha announcement
 

So we can have a functional Maemo Leste with some blobs, and then with Maemo Libre™ being a deblobbed version of Maemo Leste? ;)

Agreed on the whole base discussion. We have similar ideas/thoughts.

Just to clarify -- we use Jenkins to build packages for the repo. I don't think it makes sense to for everyone to set up their own Jenkins instance. What I and freemangordon usually do is to develop on a amd64 VM or just on the device itself (this is what I do most of the time) and then build & test. When it's done, commit and have someone (currently, me or parazyd) rebuild the package in Jenkins.

We can definitely give some people access to Jenkins. From the UI one can rebuild packages easily.

Adding packages to Jenkins requires shell access to the jenkins account.

As for the building the image, I think it's completely separate -- I think it's a debootstrap on steriods + kernel building + other stacking scripts. You can just use our repos when doing that.

Right now most open tasks don't require one to set up their own Jenkins or build their own image, I think. When I help parazyd with debugging an image, I just test the image, fix that needs to be fixed (kernel params, packages missing, wrong versions, missing scripts, config) and then let him know. And then makes a new image - repeat.

Re: Maemo-Leste pre-alpha announcement
 

Messed around a bit with usb applet and battery applet.

Neither are functional yet, have to replace the hal parts, but getting there.

https://wizzup.org/n900-initial-battery.png
https://wizzup.org/initial-usb-applet.png

Re: Maemo-Leste pre-alpha announcement
 

Edits/updates in blue...

I finally got around to trying Leste last night. I tried the N900 armel build (maemo-leste-1.0-armel-n900-20180207.img.xz) and I have a few observations...

It failed to complete initialisation. Xorg failed to start and then it shut down the OS automatically. It looks like there are some missing shared libraries. Here's my Xorg.0.log:

Code:

---

[    62.738]                                                                                                                                                                                                                                                                                                          [3/504]
X.Org X Server 1.19.2
Release Date: 2017-03-02
[    62.752] X Protocol Version 11, Revision 0
[    62.757] Build Operating System: Linux 4.9.0-4-armmp-lpae armv7l Debian
[    62.762] Current Operating System: Linux devuan 4.15.0-rc6+ #1 PREEMPT Wed Feb 7 15:47:47 CET 2018 armv7l
[    62.763] Kernel command line: root=/dev/mmcblk0p6 rootwait ro console=tty0 vram=12M ubi.mtd=5
[    62.773] Build Date: 16 October 2017  09:52:58AM
[    62.778] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support)
[    62.783] Current version of pixman: 0.34.0
[    62.794]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[    62.794] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    62.813] (++) Log file: "/tmp/Xorg.0.log", Time: Thu Jan  1 00:01:02 1970
[    62.828] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    62.834] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    62.842] (==) No Layout section.  Using the first Screen section.
[    62.842] (==) No screen section available. Using defaults.
[    62.842] (**) |-->Screen "Default Screen Section" (0)
[    62.842] (**) |  |-->Monitor "<default monitor>"
[    62.851] (==) No monitor specified for screen "Default Screen Section".
        Using a default monitor configuration.
[    62.851] (==) Automatically adding devices
[    62.851] (==) Automatically enabling devices
[    62.851] (==) Automatically adding GPU devices
[    62.852] (==) Max clients allowed: 256, resource mask: 0x1fffff
[    62.874] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[    62.874]    Entry deleted from font path.
[    62.874] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[    62.875]    Entry deleted from font path.
[    62.875] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[    62.875]    Entry deleted from font path.
[    62.875] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[    62.875]    Entry deleted from font path.
[    62.875] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[    62.875]    Entry deleted from font path.
[    62.875] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[    62.876]    Entry deleted from font path.
[    62.876] (==) FontPath set to:
        /usr/share/fonts/X11/misc,
        built-ins
[    62.876] (==) ModulePath set to "/usr/lib/xorg/modules"
[    62.876] (II) The server relies on udev to provide the list of input devices.
        If no devices become available, reconfigure udev or disable AutoAddDevices.
[    62.886] (--) using VT number 2

[    62.887] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[    62.888] (II) no primary bus or device found
[    62.896] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    62.907] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: libGL.so.1: cannot open shared object file: No such file or directory
[    62.907] (II) Unloading glx
[    62.908] (EE) Failed to load module "glx" (loader failed, 7)
[    62.908] (==) Matched modesetting as autoconfigured driver 0
[    62.908] (==) Matched fbdev as autoconfigured driver 1
[    62.908] (==) Assigned the driver to the xf86ConfigLayout
[    62.911] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    62.919] (II) Module modesetting: vendor="X.Org Foundation"
[    62.919]    compiled for 1.19.2, module version = 1.19.2
[    62.921] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    62.935] (EE) Failed to load /usr/lib/xorg/modules/drivers/fbdev_drv.so: libpvr2d.so: cannot open shared object file: No such file or directory
[    62.935] (II) Unloading fbdev
[    62.936] (EE) Failed to load module "fbdev" (loader failed, 7)
[    62.936] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    62.936] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[    62.936] (WW) xf86OpenConsole: setsid failed: Operation not permitted
[    62.957] (WW) Falling back to old probe method for modesetting
[    62.958] (EE) open /dev/dri/card0: No such file or directory
[    62.958] (EE) No devices detected.
[    62.958] (EE)
Fatal server error:
[    62.959] (EE) no screens found(EE)
[    62.959] (EE)
Please consult the The X.Org Foundation support
        at http://wiki.x.org
 for help.
[    62.959] (EE) Please also check the log file at "/tmp/Xorg.0.log" for additional information.
[    62.960] (EE)
[    62.987] (EE) Server terminated with error (1). Closing log file.

---

As per fmg's recommendation, Hard FP works fine and boots into Hildon.

I haven't what looked to see what triggers the automatic shutdown but I think it would be better to roll back to the previous run level with a console login prompt instead completely shutting down.
There appears to be a bug (watchdog kicks in perhaps?) which causes a complete shutdown when switching run levels. Fremantle also had this quirk. I'll file this on the bug tracker soon, after I've done more testing.

I noticed that the image uses a separate vfat /boot slice. Is there any particular reason for using vfat? U-Boot can boot off ext4 directly without any issues. I frequently test on an SD card with multiple slices, each with a different OS install. To accommodate this, I had to manually copy the zImage and uImage to the root slice and edit /etc/fstab. I can see this becoming annoying if I have to do this every time I test an image. If there are no objections, I'd like to move it all to single ext4 slice. I don't mind fixing this myself.
Never mind about this. I found the tarball which is easy enough to unpack to a single slice. Although it still might be worth removing the /boot line from the fstab, at least for the tarball, as it's not needed.

I'm not sure why, but I couldn't mount the Leste ext4 slice on my SD card under Fremantle (kernel power). I've never had a problem with ext4 before and I can still mount other ext4 slices under Fremantle. The same slice mounts without any problems under Devuan on my N900. Not critical, just an observation. We can let this one go if you like.
Wizzup pointed out that this relates to new ext4 features. I guess these are incompatible with kernel-power's ext4 support.

This one's not a problem, I'm just curious. I noticed that it's running OpenRC. Is that something specific to Leste or is OpenRC now the default in Devuan Ascii (Devuan Jessie didn't use it)?
Found that the openrc package it explicitly added to the Leste image build. Good choice in my opinion. Also found out that is installable using the expert install path in Ascii.

In DebiaN900, I create a "run once" SysV init RC script which runs interactive commands to configure things like passwords, locale and timezone on first boot. Do we need something similar in Leste?
I'll probably integrate this soon. In the long term, we may want to set up these things in Hildon on its first run. Fremantle does something similar.

Re: Maemo-Leste pre-alpha announcement
 

@wicket - try armhf image, it should work

Re: Maemo-Leste pre-alpha announcement
 

Would be neat to be able to see cursor even if event comes from touchscreen. If multiple cursors are supported, such as finger at touchscreen and external mouse, at the same time, then different cursors (round circle for touch, usual arrow pointer for mouse)? If it is possible, of course. Makes for more interesting video screenshots if cursors can be seen.

Thank you. Best wishes.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...

Re: Maemo-Leste pre-alpha announcement
 

Taking the same code snippet from Cordia, you could check a setting for touchscreen cursor visibility and set it to selected cursor. Other than needing a section in Hildon control panel, pretty straightforward.

For screen recording, at least regarding N900, I would use a desktop and make use of the click animation in the desktop software, if it works with VMs. For that reason, I would leave the touch cursor for now.