Announcing Movuan

lxb · 2025-03-01 19:48:11

Dear possible future friends,

If I may, would like to introduce a new Devuan derived distribution for Mobile Phones - Movuan.
Release v0.0.0.1 comes for the fist time with an attached image that can be burned to your bootable SD card straight for the PinePhone.
If you would like to test/use it in a VM, on a laptop, or on other compatible phones, you will however have to build it yourselves.

https://gitlab.com/l2385/movuan/movuan- … -/releases

Check out project details at:
https://gitlab.com/l2385/movuan/movuan-recipes

Find out more details about PinePhone at: https://pine64.org/devices/pinephone/

To avoid describing the actual state and to make it more interesting to read, let me to start with a bit of history instead.

My preferences run towards software freedom (as only found in GPL), minimalism, respecting privacy and allowing freedom of speech. I prefer text email and tend to download it with fetchmail and display it in a text console like pine. Also use links2 browser in text mode but sometimes ungoogled-chromium in graphical mode, as rarely as possible.

Do not use any kind of social media, just to mention - not f'd. If I need to see an instructional or informative video, have to download it first.

Please check out the Viewable with any browser campain: http://www.anybrowser.org/campaign/ and the FSF "Why you should #DeleteFacebook"; "You won't find me on Facebook" on https://www.fsf.org/facebook.

Started over a 1200 Baud modem and used Kermit with CP/M many years ago. Still mind my bandwidth when connected over GSM technology based networks, just because you cannot have any privacy unless you control every single connection your computer (and your browser) makes to the outside world. Prefer wired connections, but appreciate the mobility of cellphones. Do not use or like location services, although getting a GPS fix obtained from the console is not completely out of the question.

Had been using G1 Android with tethering in 2008 and a few years later. Actually waited overnight to be the first customer to get the first "Linux" based widely available phone back then (before the G1 I had an Agenda VR3 and a Sharp Zaurus with Angstrom but did not get a CF GSM card). Promoted avidly and admired Google technologies until I learned about their opening of a Seattle based office and strengthening of their relations with MS. How could a company use the moto "Don't be evil" when they are openly friends with another company that prides itself to be repeatedly perceived as the eternal evil? Nokia's cooperation with MS was similarly disappointing.

On my personal computers and whatever is used by my direct family, Linux is installed exclusively since about 2003 although I had to use MS based OSes for brief, short couple of weeks periods, in 2006, 2009 and again in 2019 for items where free software was being sabotaged. Distributions ranged from RedHat, from version 4.5 (before EL renumbering), Slackware, Mandrake, Knoppix, but also Ubuntu (until they started messing up with the deb packaging) and of course Debian. Yet there was always some distrust in my mind against any MS funded trojan horses that may get their way into linux distros.

So I started using Devuan since Beowulf, but only since about 2020 I kicked out completely almost all the other distros from all VMs (except temporary software evaluations).

By this time you probably realized that I had been maintaining scripts that allowed me to set up my machines quickly the way I liked them. A few things covered in the https://gitlab.com/l2385/movuan/customi … t-mounting script:
- privoxy to allow dynamic modification of web pages in order to remove items that invade privacy or use excessive bandwidth.
- It is my belief that the only way to effectively guarantee browser access limitations is outside of the browser code itself.
- this may be controversial with others as it breaks the end to end encryption, yet I strongly believe it gives better privacy and avoids the non-deniability https trap.
- chain through squid for local caching to avoid repeated downloads of the same items
- help install the ungoogled version of the chromium browser
- create bwrap based ephemeral launchers for various browsers and set size limitations on downloaded pictures and videos
- install a pdnsd -> named -> stubby chain of dns services to allow disk caching of ip addresses for a period longer than typically allowed by the RFC in order to avoid unnecessarily repeating queries. Use encryption but control which dns servers the browser is allowed to connect to.
- pdnsd had been unmaintained for over 10 years, was not even compiling on modern systems anymore - had to revive it.
- add a iptables based firewall to actually control access (allows NAT by default to allow use of unproxyed browsers if so desired)

Ordered the PinePhone as one of the first devices designed the way I like, as soon as it was available. Would have preferred an open device made in USA or Europe instead, but none seemed to be available at the time. Used it with Mobian and custom scripts from the beginning, although decided to publish such a script only when Movuan came into picture. Wrote a program to allow me to import my old (many years) Android address book, call and SMS messaging history https://gitlab.com/l2385/AndroidImpEx. And then suddenly realized this could be Devuan based intead, to avoid sytemd and related stuff.

While Mobian is an awesome system and worked for me very well for a couple of years, it wasn't as easy as expected to convert the build system. It allows to choose your prefered mirror (you could use devuan) and they state their target is to render temselves obsolete by integrating all their functionality directly into main Debian, so this --it seems -- could trickle down to Devuan soon. Yet I had to work for a few months to get a functional version.

- Had to figure out how to build on a Devuan system (this is not necessary but did not want to use a different os for building)
- Had to add service startup scripts for any services that were not having devuan defaults
- To be able to fork with packet list changes, the dependencies had to be tracked manually at first and tested. This is to change soon.
- Had to troubleshoot the default login phog and graphical interface phosh as they had launch issues without wayland
- Reorganized the build process to separate standard stuff that is present in Debian and Devuan versus Mobian based custom configurations
- Troubleshooting building process for Chimaera/Daedalus/Excalibur (You need a different Mobian build system version for each Debian version)
- Troubleshooting build target for Raspberry PI systems
- Added systematic build for all platforms in a single command for troubleshooting purposes
- Set additional systematic logging of builds for various platforms

Do not remember at the moment everything else that had to be tweaked, but hope the above description will be enough to at least peak your interest and make you try it.

If you like Movuan, you may also want to take a look at https://github.com/the-modem-distro/pinephone_modem_sdk. It integrates well with Movuan – keep in mind though that legislation in different countries may not endorse in particular this project.

A couple of additional notes:
I had been exclusively using Movuan as the only gateway to 4G networks during the last year and Mobian for the same function before. There is currently a 10G high speed limit per each prepaid card after which it becomes slow enough to be interesting only for plain text connections. All my business as well as uploading the Movuan images was performed over it since before 2020. No other connection to any Internet or any other network. Don't expect me to answer emails before couple of days - fidonet style. No instant messaging.

The code should however be very self explanatory. If I was able to understand the Mobian build system by reading their code, you should be encouraged to try as well. And by extenso, the Mobian based Movuan build system is very similar.

On gitlab they have limited free storage space, hence providing a single image in a split zip archive. They also have free compute minutes monthly, that are ---almost--- enough to build one Movuan image monthly. When all your projects are GPL - they provide more disk space and more minutes, but it is not an automated anonymous process, you have to actually request it from your email manually and they want additional details. I would appreciate alternative suggestions for storing git, images and processing build remotely (they have to respect software freedom, privacy and freedom of speech).

Anybody is welcome to fork this project, or use it in any GPL compliant way. Use a different name though and change the logo, and notify me back to review if it can be incorporated back. If you want to just mirror the code and provide additional pre-built images on a different server, there is no need to change the logo/name. Just make sure to prominently point to the original location.

This project has never received any monetary contributions of any kind, from any party. It was all developed in my own free time and fully with my own resources. I consider it as my contribution/donation to the free software movement. Hope to be useful. Performed a reasonable effort to clarify licensing for every sub-project and to link only GPL/OpenSource licensed software, yet if you plan to distribute you should research licensing individually for every sub-project.

Thank you for your time and interest!
lxb1@yahoo.com

Last edited by lxb (2025-03-01 20:07:25)

greenjeans · 2025-03-01 19:58:41

More choices are always good, welcome to the forum!

rayburn · 2025-03-01 21:54:52

Welcome and well done. You are providing more choice for those who want to retain their privacy. Thank you for your efforts!

golinux · 2025-03-01 23:35:09

Happy to see you got this together, lxb. Way to go!

fsmithred · 2025-03-02 14:33:52

Is there a way to boot the image in qemu or virtualbox? I tried but failed - what is the correct cpu type to use? pine64.org mentions Cortex A53, Allwinner A64/R18 but I don't see those in the qemu list of supported devices.

So instead, I mounted the image file and chrooted into it, installed xserver-xephyr and jwm, and I can get a graphical session. I also tried installing xfce4, but I couldn't get that to run. I also couldn't get gnome to run, but I don't know the command to start it.

I wish I had a pine phone to try it for real (and for other reasons). The mobian site talks about dd'ing the image to usb and booting it on x86 hardware. Is this possible with the movuan image? I did put it on a usb stick, but when I plug it into the laptop, fdisk doesn't see it. Syslog shows usb device, but it doesn't get a block device name. Is there some package I can install that will recognize the partitions on the usb?

git.devuan.org is free. You could put the code there. I don't know if there are any space constraints that would prevent storing images there, and I don't think you can build there.

lxb · 2025-03-02 17:36:41

Awesome fsmithred!

In a round-about way the answer is yes, I use it quite often in qemu/kvm to test sub-items in this project
(like the https://gitlab.com/l2385/movuan/resize_ … home_part)

However there are limitations and difficulties:

1.- use the uploaded image with KVM/qemu on a pc - it is for an arm cpu.
- you need qemu-arm. I use:
<model fallback='allow'>cortex-a57</model>
- it takes about 4 times as much to boot in simulation
- the video did not initialize for me in the last version tried - used ssh instead (possible qemu-arm issue with vitio video)
- you need to use external kernel you can retrieve from the experimental devuan-arm
<kernel>/var/lib/libvirt/images/rpi/vmlinuz-6.1.0-x-arm64</kernel>
<initrd>/var/lib/libvirt/images/rpi/initrd.img-6.1.0-x-arm64</initrd>
- you need special linux command line like
<cmdline>root=/dev/vda2 console=serial0,115200 console=tty1 consoleblank=0 video=360x720 loglevel=7 rw nosplash rootfstype=ext4 fsck.repair=y plymouth.ignore-serial-consoles vt.global_cursor_default=0 init 5</cmdline>
- there was an issue regarding the size of the firmware that needed to be exactly 64k.

2.- use the uploaded image in qemu on a Raspberry PI - it is a similar arm cpu, works much better then first alternative
- decent speed
- still needs external kernel and special linux command line
- i don't remember if video was still a problem, you can deffinitely run well the experimental devuan-arm with video image so it should not be a problem
- why not use special rpi Movuan image instead?
- i do not currently upload one althought it works well
- you have to either build it yourself following the steps in the README or hope another viewer of this post decides to host a pre-built image

3. - use the special AMD64 Movuan image instead
- i do not currently upload one although it works well both in qemu/kvm as well as boot straight on a pc
- you have to either build it yourself following the steps in the README or hope another viewer of this post decides to host a pre-built image

4. - use chroot instead as you already did.

If you decide to go with options 1 or 2, I can post my full kvm config file and possibly help with more qemu/kvm arm details.

Hope others may help figuring out if qemu-arm issue with vitio video may not be a problem anymore.

If we could get this fully working, it would allow much more general simulation of Android phones and of the devuan-arm experimental.

The current image partitioning should be visible with fdisk, when put on an usb drive. Not sure what the probelm may be there. The https://gitlab.com/l2385/movuan/customi … type=heads does exactly something like you describe -look around line 90.

I will get an account on git.devuan.org and let you know.

Last edited by lxb (2025-03-02 17:44:05)

lxb · 2025-03-02 20:19:10

@greenjeans - thank you, will take a look at your project soon!
For the moment sourceforge.net through their use of cloudflare.com considers me subhuman.... hmmmmm...

@rayburn and @golinux - thank you!

Last edited by lxb (2025-03-02 20:25:09)

fsmithred · 2025-03-02 22:59:23

There's no problem with fdisk reading the image file. The problem occurs if I dd the image to a usb stick and try to boot that on amd64 hardware. The kernel sees the usb stick when it's plugged in, but it doesn't recognize a block device.

Uh-oh. I just plugged it in again and it did get a device name. But the system is complaining about GPT header and said to fix it with parted. I did that, and now fdisk can read the partitions on the usb. It doesn't boot on my hardware.

semil · 2025-03-03 00:08:31

Very interesting!

How does this contrast with Maemo Leste?

lxb · 2025-03-03 04:34:03

@fsmithred - it is an arm image with a specific kernel for pinephone. I do not UPLOAD the AMD64 image due to storage limits on gitlab. Yet I would love to help any reader follow the instructions from: https://gitlab.com/l2385/movuan/movuan- … type=heads

This will allow building for AMD64 or one of the other buildable platforms: pinephonepro, pinetab, sunxi, pinetab2, librem5, sdm845, sm7225, rpi4. I tried to make that process easy and if I did not make it easy enough, i will try to help. Whoever gets it done first has my blessings to publish pre-built images for any platform he can test with.

Edit - I am building and testing myself AMD64 and Raspberry PI 4 every time and they both work good. Just didn't plan to upload them in gitlab at the moment. The other platforms I do not possesm so I cannot test. Note that most network functionality revolves around the EG25 4g modem that is built into the Pinephone and you will not have that in a VM unless you hook up one externally over usb https://wiki.pine64.org/wiki/PineModems. For this modem there is also an almost free firmware mentioned above (all GPL except the regulatory mandated Hexagon GSM binary).

Last edited by lxb (2025-03-03 05:08:41)

lxb · 2025-03-03 04:43:07

@semil - thank you for your time! Just off the top of my head:

1. I think maemo-leste builds on chimaera only and i had trouble rebuilding myself.
Movuan currently builds on daedalus (and chimaera but I did not test it in a while). The Excalibur version does not get the polished "phosh" interface that I like, can only be used with "sway".

2. I found "phosh" to be very intuitive for a phone and very easy to use.

3. There are a number of internal differences like maemo-leste uses ophono while Movuan uses ModemManager

fsmithred · 2025-03-03 11:33:26

lxb, I'd like to try your amd64 build. I don't have time to build my own right now. I'll send you an email.

lxb · 2025-03-03 17:51:17

Gentlemen,

A few clarifications seem necessary for those who are not that familliar with phone distributions yet.

1. Movuan as a Devuan based clone of Mobian can be built alternatively with 3 different interfaces:
- phosh
- plasma-mobile
- sway

If you want to see how any of these would look on your pc or vm, using Movuan would be unnecessary overkill. You can just add them to your normal Devaun installation with apt-get. They are not impressive on a big screen, yet they work well on a 360x720 or 720x1440 small phone portrait-mode touch-creen. Use one of the commands below:
- apt-get install phosh-phone
- apt-get install plasma-mobile

2. If you want to see how an actual phone looks and behaves in a VM and you don't mind it being Debian based instead of Devuan, you can download the Mobian image that I attempted to clone on Devuan as close as possible.
https://images.mobian.org/amd64/

3. If you like the privacy customizations from https://gitlab.com/l2385/movuan/customi … t-mounting, it is just a bash script that can run with Mobian, or be split into smaller components and run basically onto any apt based distribution.

4. In case one of you would like to try the build process, it may be as simple as:
-----------------------------------------------------------------------------------
1. set up an AMD64 DevuanDaedalus VM with at least 2 cores and as much memory you can afford
2. sudo apt-get install docker.io apt-cacher-ng
3. git clone http://gitlab.com/l2385/movuan-recipes
4. cd movuan-recipes/build-tools
5. edit ./build_all_missing_platform_images.sh on line 17 in order to produce only desired platforms
devices="amd64-free rpi4"
6. sudo sh ./build_all_missing_platform_images.sh
7. wait for it unsupervised (over an hour for each platform) in order to produce the images

Other possible build targets may be pinephonepro, pinetab, pinetab2, librem5, sdm845, sm7225. I do not have any of these devices to test Movuan, so it may be better to test Mobian for those, at least initially.

Let me know if you run into any trouble - i will attempt to help. You can email me directly, but please be patient.

Very kindly fsmithred offerred to host pre-built images, you might want to check with him - thank you very much fsmithred!

Last edited by lxb (2025-03-03 18:15:42)

greenjeans · 2025-03-03 20:27:52

For the moment sourceforge.net through their use of cloudflare.com considers me subhuman.... hmmmmm...

Arrgh...I hate that stupid cloudflare challenge, it's buggy too and can be picky about what browser you're using, have seen multiple instances of it failing repeatedly and tons of complaints from folks. They must be singling out other countries with it right now, as i'm not getting it when I log-in to sourceforge.

If you can't access it but would like some of your images available there, i'd be happy to help in any way I could, can set up another project under my account with your name and content on it if nothing else.

lxb · 2025-03-03 23:55:22

Thanks greenjeans - I think I know how to workaround their challenge (it checks the exact computer time/timezone but if that is set as they expect it, it works further with Firefox). However I need a few days off to muster some new energy before I can actually take a look at other projects.

greenjeans · 2025-03-04 18:42:44

Thanks greenjeans - I think I know how to workaround their challenge (it checks the exact computer time/timezone but if that is set as they expect it, it works further with Firefox). However I need a few days off to muster some new energy before I can actually take a look at other projects.

Oh no, you misunderstand me, I wasn't suggesting a workaround so you could look at my silly stuff, was suggesting a way for you to be able to host your Movuan images on sourceforge, as it's free and you get a large amount of storage.

lxb · 2025-03-04 20:09:17

@greenjeans Got it, thanks! I am fammiliar with Sourceforge, they deffinitely are a contender for alternative storage.

@fsmithred and @greenjeans

While my project can build for AMD64 and an AMD64 image could be construed as a help for others to get an idea what does it do without having to have specialized hardware, it seems to dilute the main purpose for the first release v.0.0.0.1.

If I would be advertising the Pinephone, or at least the customizing-movuan-under-host-mounting script, it would make sense to show a qemu demo and then tell all to go and buy a PinePhone.

But my purpose is to use Devuan to get a usable (daily driver) phone distribution on available hardware. I have a Pinephone and am extremely enchanted by what I was able to achieve. If readers have Pinephone - great. If not maybe one of them may have a Fairphone instead or a Google Pixel 3A or a Nokia N900 and may be willing to put the effort for tweaking and testing.

For PC, I may upload an image or a qcow demo in the customizing-movuan-under-host-mounting project when it will be ready for release to others. That is not however going to be today and seems illogical to upload a 1Gb image whne the whole script that generates it is only about 1k. If we find a user with a steam-deck and an external, usb connected, EG25 modem would convince me immediately to spend resources on it.

Last edited by lxb (2025-03-04 20:18:25)

lxb · 2025-03-04 20:28:15

@fsmithred - when you dd a small image on a larger disk and run parted, it always complains that the GPT header is not set to use the whole disk space and asks to fix it.

That is not a problem and is automatically taken care of during first boot by https://gitlab.com/l2385/movuan/resize_ … _home_part.

As you were running in chroot the resize_or_create_home_part did not get a chance to run. I think this was the problem you were describing.

bai4Iej2need · 2025-03-05 11:49:46

I still run my Fairphone 2, which is out of software support since 2 years now. Is there a chance to adopt movuan for the FP2 ?

lxb · 2025-03-05 14:37:29

I think it may be possible to build an image based on Movuan, yet it would be deffinitely quite an involved process.

If you desire an updated image look at postmarketOS which seems to be at the moment the most advanced into supporting it https://wiki.postmarketos.org/wiki/Fair … phone-fp2).

I observered with sadness that PostmarketOS has recently caved to using systemd.

If postmarketos works for you and you accept the limitations shown for the kernel and still want to perform signifficant work to be able to use it based on Devuan instead, send me a private email afterwards.

Last edited by lxb (2025-03-05 15:01:29)

merom · 2025-03-16 23:45:39

.
Hi. I tried this Movuan and it works overall. However, I experienced problems when the system is triggered.
It is probably due to the fact, that I have installed Tow-Boot. When the system is started, it ended in 2/3 of the cases, as in the pictures.
.

pinephone-keyboard
.
.
.

or press Control-D to continue
.
.
.
If someone has the same problem, it is necessary to keep the Volume-Down key pressed longer at the start. In my case up to about 15 seconds to start the system.
Thank you for trying this alternative to Mobian. It's interesting.

.

lxb · 2025-03-17 01:46:21

Thank you for the feedback merom !!!
Awesome to see people using it. Keep us posted further, please.

You are probably correct - investigating.
Might be worthwhile to add an incident in gitlab.

Edit << Preliminary: The issue may be /etc/fstab entry for /home where field 6 is currently 2 and could be changed to 0 instead, in order to avoid failure if pinephone shuffles /dev/mmcblk# during TowBoot.

The entry should be changed to reference UUID (as reported by blkid) instead of /dev/mmcblk1p3. This is resulting from execution of ResizeOrCreateHomePartition https://gitlab.com/l2385/movuan/resize_ … _home_part during first boot.

It was just added a couple of weeks ago as it seemed a mandatory requirement for the release to allow people to use their whole SD without having to fiddle with partitioning and /etc/fstab.

Well, ... it seems you still have to fiddle with it ... >>

As a side note: did not realize, possibly due to my recent use of the physical keyboard. Just started using the pine keyboard again. It was fully discharged and did not want to charge back at all. Opened the case, took out the battery, removed a couple of adessive tapes and was able to access the actual battery terminals. Jumpstarting it with a car 6v agm charger worked. Sill not easy to use, but check https://gitlab.com/l2385/movuan/runscri … type=heads in case you have one of these.

Last edited by lxb (2025-03-17 17:37:06)

merom · 2025-03-18 18:16:34

The situation in the first picture occurred even though I don't have a keyboard. That's why I was amazed that it is written about Pinephone-Keyboard.

Preliminary: The issue may be /etc/fstab entry for /home where field 6 is currently 2 and could be changed to 0 instead, in order to avoid failure if pinephone shuffles /dev/mmcblk# during TowBoot.
The entry should be changed to reference UUID (as reported by blkid) instead of /dev/mmcblk1p3.

At the moment I have been uptime 3 days, but Mobian has not tried for a long time. Inside on the device is installed one still from 2022. Now I can't compare with the current mobian. I will look at the one /etc /fstab and let know if something has changed.

Last edited by merom (2025-03-18 18:22:42)

lxb · 2025-03-18 18:51:38

Sorry Merom if my post was confusing. No it is not about the keyboard, it happens both with as well as without keyboard.

Your suggestion to "keep the Volume-Down key pressed longer" is probably ok and allows people to try it thanks again! It however cannot be considered a permanent solution as it does not take advantage of the newly created home partition and it does not use the rest of the sd drive (uses only 7GB out of it).

To resolve the situation without a new release, you can follow the steps:
1. use a cmd prompt to become root (you can do "sudo bash")
2. run blkid and obtain the UUID for the home partition.
it should have the format xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
3. edit /etc/fstab (you can use mcedit for a wysiwyg experience)
4. observe the last line starting with /dev/mmcblk1p3 which gets mounted under /home
5. replace /dev/mmcblk1p3 with UUID=xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx as obtained before.

It is really umpleasant to do this on such a small screen, but it should resolve the boot issue in a permanent way and also give you access to the whole drive. Per my tests it seems to resolve the problem.

As you reported the issue when I was not even aware of it, I would thank you very much if you would be able to try and maybe to confirm no more "press CTRL-D" prompt after fixing fstab.

Last edited by lxb (2025-03-18 19:00:49)

merom · 2025-03-19 00:27:02

It however cannot be considered a permanent solution as it does not take advantage of the newly created home partition and it does not use the rest of the sd drive (uses only 7GB out of it).

I agree and thank you for your support. I can't mark the copy text in Console. So I made a

sudo blkid > blkid-movuan.txt

After turning off the PP, I chose the SD card and put it in a notebook where I made the proposed UUID modification. Then the system starts earlier and the text "or press Control-D to continue" has not appeared. So it really helped.

I was intrigued that now the names of mmcblk1 are mmcblk2 and vice versa.

:-)

Last edited by merom (2025-03-19 01:25:42)

The officially official Devuan Forum!

#1 2025-03-01 19:48:11

Announcing Movuan

#2 2025-03-01 19:58:41

Re: Announcing Movuan

#3 2025-03-01 21:54:52

Re: Announcing Movuan

#4 2025-03-01 23:35:09

Re: Announcing Movuan

#5 2025-03-02 14:33:52

Re: Announcing Movuan

#6 2025-03-02 17:36:41

Re: Announcing Movuan

#7 2025-03-02 20:19:10

Re: Announcing Movuan

#8 2025-03-02 22:59:23

Re: Announcing Movuan

#9 2025-03-03 00:08:31

Re: Announcing Movuan

#10 2025-03-03 04:34:03

Re: Announcing Movuan

#11 2025-03-03 04:43:07

Re: Announcing Movuan

#12 2025-03-03 11:33:26

Re: Announcing Movuan

#13 2025-03-03 17:51:17

Re: Announcing Movuan

#14 2025-03-03 20:27:52

Re: Announcing Movuan

#15 2025-03-03 23:55:22

Re: Announcing Movuan

#16 2025-03-04 18:42:44

Re: Announcing Movuan

#17 2025-03-04 20:09:17

Re: Announcing Movuan

#18 2025-03-04 20:28:15

Re: Announcing Movuan

#19 2025-03-05 11:49:46

Re: Announcing Movuan

#20 2025-03-05 14:37:29

Re: Announcing Movuan

#21 2025-03-16 23:45:39

Re: Announcing Movuan

#22 2025-03-17 01:46:21

Re: Announcing Movuan

#23 2025-03-18 18:16:34

Re: Announcing Movuan

#24 2025-03-18 18:51:38

Re: Announcing Movuan

#25 2025-03-19 00:27:02

Re: Announcing Movuan

Board footer