A new version of wmlive based on Debian/Bookworm 12.12 was released yesterday. Apart from improvements over the previous 12.8, it contains quite a few software updates. I've attached the file describing the major new features.
See wmlive.sourceforge.net (https://wmlive.sourceforge.net) for further details.
Yes, it's not based on the brand new Debian/Trixie yet because I preferred to create a final version with all the updates available to date. With all the packages from the backports, wmlive 12.12 is not that far from Trixie as one might expect.
Above all, I wanted to make sure that the latest 32-bit variant is as up-to-date as possible because there will be no other from now on.
When I have recovered from the hustle and bustle related to this version, I will start working on the next one, this time based on Trixie.
----------------8<---------------
WHAT IS NEW IN RELEASE 12.12?
This release is based on stable Debian/Bookworm release 12.12 and
contains the backported Linux kernel version 6.12.38 for the amd64
variant.
The i386 variant stays on backported kernel 6.10.11 as last official
i386 kernel provided by Debian.
Due to Debian's deprecation of the 32bit CPU architecture starting
with Debian/trixie this will likely be the last wmlive release
capable to run on Intel compatible 32bit processors.
Apart from the usual Debian package updates following components
were updated with newer release versions: palemoon-33.8.2,
emacs-gnustep-30.1, previous-3.9. The transmision bittorrent client
was replaced by qbittorrent. Additionally, the VPN client riseup-vpn
was added as a new component.
Notable package updates originating from Debian's backports
channel contain amd64-microcode (3.20240820.1 => 3.20250311.1),
claws-mail (4.3.0 => 4.3.1), curl (8.10.1 => 8.14.1), emacs
(29.4 => 30.1), handbrake (1.9.1 => 1.9.2), intel-microcode
(3.20240910.1 => 3.20250512.1), libvirt-daemon-system (9.0.0 =>
11.3.0), linux-image-amd64 (6.11.5 => 6.12.38), pipewire (1.2.5 =>
1.4.2), qemu-system (9.1.2 => 10.0.2), and systemd (254.16 => 254.26).
The separate inclusion of duplicate firmware packages on the
ISO image has been dropped in order to reduce it's overall size.
Since the live system image already contains all available firmwares
installed there is no functional difference from the user perspective.
Installed systems with space constraints always can later be trimmed
from huge unnecessary firmware packages using the dpigs command to
find out the largest disk space consumers.
This will be the last wmlive release still based on Debian/Bookworm.
@wmlive thanks so much for sharing. I really want to use this for my 1 use-case where I am currently using Linux.
I run a Debian 13 VM on my Apple Silicon Mac to run a video streaming server with FFMPEG. Why Debian 13? I tried Debian 12 and had lots of audio issues. Popping and clicking audio that only works for about 10 minutes before going fully silent. I looked into this and I thought it might be because Debian 12 has an extremely old version of Pipewire. So I tried 13 and that fixed it! I was so excited.
https://repology.org/project/pipewire/versions
But I really do want to use WindowMaker because I think it looks great. I installed WindowMaker on my Debian 13 install via Apt. I could log in but it just did not look anything like the screenshot you posted. So I imagine there is extra magic in WMLive to make WindowMaker work more like NeXTSTEP?
Anyway, it looks like Debian 12 can run the newer version of pipewire 1.4.2 via Backports. So maybe I can run Debian 12 and install pipewire via backports. But then the problem remains, WMLive does not have an ARM64 ISO image.
So yeah, not expecting my strange use case to be supported, but I thought I would share what is preventing me from using WMLive to see your thoughts. I am not a Linux expert by any means... and you clearly are so I would like to get your opinion.
Thanks so much,
Jeff
Quote from: jeffburg on Sep 09, 2025, 02:20 AMBut I really do want to use WindowMaker because I think it looks great. I installed WindowMaker on my Debian 13 install via Apt. I could log in but it just did not look anything like the screenshot you posted. So I imagine there is extra magic in WMLive to make WindowMaker work more like NeXTSTEP?
Indeed, wmlive contains a whole lot of preconfigurations and a few additional packages that are missing in Debian proper.
The related packages are all available at https://wmlive.rumbero.org/repo/ and, if you add it to your sources.list as outlined there, you should be able to add the missing packages containing the necessary preconfigurations. To begin with, the most important package is wmlive-base as it includes the needed /etc/skel/ containing the modified configuration files. Then there are some theme components for gtk+ and qt5/6 to get the basic NeXT looks in the packages wmlive-pixmaps, wmlive-theme-onestepback, wmlive-theme-twostepsback, wmudmount, qt6gtk2, etc.
I have never tried converting a basic bookworm installation into something more akin to wmlive by using these external packages. So you'd need to try on your own.
By the way, wmlive always already has all latest backport packages installed, including pipewire-audio 1.4.2.
Quote from: jeffburg on Sep 09, 2025, 02:20 AMBut then the problem remains, WMLive does not have an ARM64 ISO image.
The source tree to build the ISO images already has the capability to create ARM64 images and it is possible to somewhat use these ISO in qemu. But this is where the chaotic world of ARM64 boot mechanisms and loaders rears its ugly head: There is no way to create a single ARM64 ISO matching all different ARM64 platforms out there. There really needs to be something like a unified UEFI or BIOS to remove this pain.
The only ARM64 machine i own is a Pinebook Pro, and i gave up trying to figure out how to make it boot any wmlive ISO. A few people requested a version for raspberry pi but i don't own one and therefore can't even try to get this done. This is a problem someone else with better knowledge and access to suitable ARM64 target platforms needs to solve.
@wmlive this is great to hear (about the back port packages)! now I really want to try! Uh, as far as the ARM64 build. Is there a link? And as far as boot loaders go, since it was based on Debian, and just assumed you used the same boot loader. The Debian ARM64 ISO image worked absolutely fine for me.
But I also do understand the frustration of not having a unified boot process. That's like super annoying. I mean, I have been a Mac user with old world rom, new world rom, and then intel EFI (stripped down to the bone on purpose by apple) and now Apple silicon which is like basically not a boot loader lol. So yeah, it would be nice if Microsoft or someone could define an EFI like standard for booting ARM systems.
Quote from: jeffburg on Sep 09, 2025, 03:43 AM@wmlive this is great to hear (about the back port packages)! now I really want to try! Uh, as far as the ARM64 build. Is there a link? And as far as boot loaders go, since it was based on Debian, and just assumed you used the same boot loader. The Debian ARM64 ISO image worked absolutely fine for me.
I have created an ARM64 build just for testing purposes to verify if it actually builds. But as i basically have no real hardware to test it on, besides the awkward Pinebook Pro where i don't succeed booting it via u-boot, i prefer to not release any ARM64 ISO variant of dubious quality just wasting the potential downloader's and also my own limited time.
When i read "works for me" this lets me assume in your case that this applies to an Apple silicon machine. This hardware is unknown to me and therefore i can't help any further. Generally, i know Macs only from hearsay and have never ever owned or even only used one of these in my 30 year IT career stumble.
Out of curiosity i once succeeded hackintoshing an old Thinkpad T60 with Snow Leopard last year but haven't been using it any further than that. Running OPENSTEP on the same machine proved to be much more rewarding.
You might easily try building an ARM64 ISO by yourself, leveraging your existing Debian installation, from the supplied sources. The sources of the wmlive build tree are located on the ISO in sources/wmlive-bookworm-12.12.tar.xz and only need to be unpacked somewhere safe with about 15 GB free disk space inside your existing Debian system. Make sure to have the live-build and apt-cacher-ng packages installed, and then switch into the unpacked build tree folder and just run the following command:
# ./mkwmlive arm64 | tee ../wmlive-build_$(today).log 2>&1The wmlive repo mentioned in my former reply has ARM64 versions of the packages required to build an ISO and will be automatically used during the build process.
The apt-cacher-ng is needed to avoid downloading packages repeatedly when running the ISO build multiple times. This also requires at least 2 GB of free disk space under /var for the package caching with apt-cacher-ng. If the build routine complains about inconsistent proxy settings, ensure to have following line in your Debian system's /etc/apt/apt.conf.d/02_apt-cacher-ng file:
Acquire::http { Proxy "http://127.0.0.1:3142"; };and then reload the service with
# systemctl restart apt-cacher-ngIf the build succeeds, i'm almost certain there will still be some issues preventing the ISO from working as intended. But maybe we can work this out together?
Any other issue you might stumble over, just let me know.
Quote from: jeffburg on Sep 09, 2025, 03:43 AMBut I also do understand the frustration of not having a unified boot process. That's like super annoying. [...]
So yeah, it would be nice if Microsoft or someone could define an EFI like standard for booting ARM systems.
The worst part is the amount of time to invest without any success or return whatsoever trying to get this working. My personal resources regarding time (and finances) are very limited and i really have to choose where to concentrate on.
"EFI like standard"? Reminds me of https://xkcd.wtf/927/ :)
Quote from: wmlive on Sep 09, 2025, 10:54 AMYou might easily try building an ARM64 ISO by yourself, leveraging your existing Debian installation, from the supplied sources. The sources of the wmlive build tree are located on the ISO in sources/wmlive-bookworm-12.12.tar.xz and [...]
Of course, if you haven't downloaded the ISO yet and want to avoid wasting 3 GB's worth of bandwith, just fetch the separate source package https://sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/wmlive-bookworm-12.12.tar.xz from the sourcforge site. No need to waste precious bandwith, time, or disk space.
EDIT: It's a pity the quick edit button disappears after only a too short while after posting. This time frame should be more generous, like an hour or so?
hey
@wmlive thanks so much for the thoughtful reply. I totally understand about limited resources. I think I gave you the same response about building MathEdit for GNUstep. And yeah, my use case is definitely super niche.
If it's as easy as you say to compile it from source I may give it a shot. If I get time and if it compiles, I will let you know if it boots on QEMU on my Apple Silicon Mac. I still think thats a long shot from supporting real hardware, but it's something.
Thanks again!
- Jeff
Quote from: jeffburg on Sep 09, 2025, 01:45 PMIf it's as easy as you say to compile it from source I may give it a shot. If I get time and if it compiles, I will let you know if it boots on QEMU on my Apple Silicon Mac. I still think thats a long shot from supporting real hardware, but it's something.
The interest you are showing managed to further pique my curiosity and i've had yet another closer look at an ARM64 build suitable for at least qemu. Once i get the build into a sufficiently satisfying state for 3rd party scrutinising i will provide you with a private download link. If it turns out to be suitable for your needs then maybe i'll publish it officially as an experimental build.
OMG. that would be amazing!
Hey
@jeffburg, have a look at sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/aarch64_experimental/ (https://sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/aarch64_experimental/) for an ARM64 wmlive ISO.
Unlike Debian/Trixie's, the ARM64 variant of the debian-installer for Debian/Bookworm doesn't offer a graphical installation frontend. Instead, there is only support for a very similar text based installation frontend. To add insult to injury, this text based frontend runs only on the serial console of the system, which is rather a hassle to access on real hardware. Luckily, in QEMU ist is pretty easy to switch between the graphical console and the serial console.
Here are the contents of the accompanying README:
----------------snip--------------
WARNING!
This is a strictly experimental build of wmlive for aarch64/arm64. It has not
been tested or even verified to function on any real world bare metal system.
There are no guarantees or any promise whatsoever for proper functionality.
If you are curious, try this on your own risk and be prepared for failure.
The ISO is configured to boot on UEFI using grub. There is no u-boot support.
It boots and appears to work as expected within a QEMU virtual machine
environment, including installation to (virtual) disk.
The aarch64/arm64 bookworm debian-installer does not feature a graphical
installation frontend but only allows text based installation via the serial
console.
The archive wmlive-bookworm_12.12-arm64.tar.xz contains a copy of the build
tree which was used to create this exact ISO image. Use ist to create a build
according to your own ideas.
Good luck!
@wmlive so awesome! I am going to try it! It's downloading now. I have never tried to access to the serial console in QEMU so we shall see how it goes.
@wmlive its working. I was able to boot to the live desktop. Now I am doing the install via the serial console.
It worked. I will have to see if I can get my streaming setup working now. Thanks so much!
Hey
@wmlive thanks again so much for going the extra mile for us weird ARM64 people. I updated the guide for my streaming setup, but unfortunately I went with Debian 12 and installing Backports. I was going through the process to set up the WMLive you gave me, but unfortunately, I ran into a problem that I couldn't get around even with the help of ChatGPT. I am not sure if I just made an error or if this is something you know about/a deliberate choice.
But for some reason, WMLive was not resolving "local" hostnames. Apple calls this Bonjour but I am not sure what the open source community calls it. But it works totally fine in Debian. I can ping "My-Other-Computer-Name.local" and it resolves the DNS name and pings it. Vice versa, I can ping "My-Debian-VM.local" and then it resolves and pings. But with WMLive, I was not able to ping other devices on the network.
And again, I am not asking for tech support, or for you to fix my bug. Not at all. I am just telling you the reason I was unable to proceed using WMLive :-/
If you're curious in seeing the full guide I created using Debian, you can go here
https://github.com/jeffreybergier/Retro-Stream-Tutorial
Quote from: jeffburg on Sep 16, 2025, 04:08 AMBut for some reason, WMLive was not resolving "local" hostnames. Apple calls this Bonjour but I am not sure what the open source community calls it. But it works totally fine in Debian. I can ping "My-Other-Computer-Name.local" and it resolves the DNS name and pings it. Vice versa, I can ping "My-Debian-VM.local" and then it resolves and pings. But with WMLive, I was not able to ping other devices on the network.
If pinging the IP addresses of devices on the local network works, which i'd expect to within a properly configured local network, then it would suffice to add the hostname/ip-address combination to the Linux host's /etc/hosts file and do a "systemctl daemon-reload" afterwards. I'd have to see how this is done in Debian proper and i fear it will be yet another systemd appropriation of UNIX ways.
Personally, i am fine with the manual old-school approach of editing configuration files with vim.
Yeah, pinging the IP's manually works. So it's just a hostname resolution issue. I want this guide to broadly usable on "normal" networks which have dynamic IP's so hardcoding them isn't an option in my use case. Again, totally fine to make an opinionated choice here. Things don't need to work for my weird use case.
I looked and it looks like Debian and Ubuntu use avahi-daemon to do this
https://avahi.org
Quote from: jeffburg on Sep 16, 2025, 06:52 AMI looked and it looks like Debian and Ubuntu use avahi-daemon to do this
Which, of course, is included with wmlive:
# grep avahi wmlive-bookworm_12.12-arm64.list
avahi-daemon 0.8-10+deb12u1
avahi-utils 0.8-10+deb12u1
libavahi-client3:arm64 0.8-10+deb12u1
libavahi-common-data:arm64 0.8-10+deb12u1
libavahi-common3:arm64 0.8-10+deb12u1
libavahi-core7:arm64 0.8-10+deb12u1
libavahi-glib1:arm64 0.8-10+deb12u1
libavahi-ui-gtk3-0:arm64 0.8-10+deb12u1
Of course, this begs the question why it doesn't work as expected in wmlive...
Now you gave me another incentive to look into how this works. Thanks!
Quote from: wmlive on Sep 16, 2025, 07:50 AMQuote from: jeffburg on Sep 16, 2025, 06:52 AMI looked and it looks like Debian and Ubuntu use avahi-daemon to do this
Now you gave me another incentive to look into how this works. Thanks!
Apparently, a few more avahi-related packages need to be installed:
# apt-get -m -t bookworm-backports install avahi-discover avahi-dnsconfd avahi-ui-utilsWould something like what is shown on the attached screenshot be more to your liking?
avahi-discover.png
EDIT: replaced the screenshot with a better one
It is cool that Avahi includes that GUI for listing all of its discovered services. Let me fire up WMLive again when I get home and I will see if I can get it working. Maybe QEMU just had a networking glitch at the time... unfortunately it's not uncommon.
But I bet you it was installing these 2 that fixed the problem
apt-get -m -t bookworm-backports install avahi-discover avahi-dnsconfd
Quote from: jeffburg on Sep 16, 2025, 08:53 AMBut I bet you it was installing these 2 that fixed the problem
apt-get -m -t bookworm-backports install avahi-discover avahi-dnsconfd
Yes, that was most probably the missing link.
If you find more stuff failing or not working in wmlive, please let me know.
Contrary to common belief, the best feedback are complaints about broken things as this helps fixing stuff for future releases.
Thanks so much for bearing with me. I installed the extra utilities you shared. And now the discover UI shows my devices, but DNS still does not resolve them. Take a look at this example where I can ping my device called Lamps-Plus.local with IP 192.168.0.98 but if I use its hostname, it does not resolve. And yes, I restarted after installing just in case.
Quote from: jeffburg on Sep 16, 2025, 12:36 PMThanks so much for bearing with me.
I have to rather thank you for bearing with me. ;)
Quote from: jeffburg on Sep 16, 2025, 12:36 PMTake a look at this example where I can ping my device called Lamps-Plus.local with IP 192.168.0.98 but if I use its hostname, it does not resolve. And yes, I restarted after installing just in case.
Does the same happen when you ping just Lamps-Plus (without .local)?
I just tried it and yes, ping Lamps-Plus gives the same error
Quote from: jeffburg on Sep 16, 2025, 10:24 PMI just tried it and yes, ping Lamps-Plus gives the same error
Ah, the convoluted joys of network configuration! :(
Thes reason i asked is that i noted on my own system that some hosts were not pingable when adding the .local domain extension to the bare hostname, or the reverse, while others worked both ways. And i still can't see any reason or pattern explaining this due to lack of prior experience with things avahi.
So, for the time being, no further questions asked from my side.
Neither can i provide any useful answer.
While we are at it, please also make sure to have installed following three packages:
# apt-get -m -t bookworm-backports install avahi-autoipd libnss-mdns mdns-scanNo promises this makes a difference in your specific case, but we've seen before how missing components negatively affect function.
@wmlive those extra packages did it! thanks!
Quote from: jeffburg on Sep 19, 2025, 12:42 PM@wmlive those extra packages did it! thanks!
Thanks for the confirmation and for helping to sort this out!
In the meantime i found out how to force using the graphical installer frontend also on the ARM64 variant of the wmlive ISO. This finally removes the need for bothering with a serial console.
A new ISO including the complete range of avahi packages has been built and currently undergoes some testing. If successful, it will be uploaded to replace the currently available experimental ARM64 ISO on sourceforge.
That would be awesome! I will try the new installer and let you know how it goes!
There is one more thing that is not working. Which is copy and paste (and possibly other QEMU VM services). This works on this preconfigured UTM Debian download. That said, I am not sure how they got it to work because when I use a fresh VM and install Debian manually it does not work for me. But if I keep reusing this VM config and just reinstall fresh debian it does work so I am not sure what magic is going on to make that work.
https://mac.getutm.app/gallery/debian-12
Quote from: jeffburg on Sep 19, 2025, 01:52 PMThere is one more thing that is not working. Which is copy and paste (and possibly other QEMU VM services).
Please define what context for "copy and paste" is meant. Copying a text selection and pasting it to another writable location (editor, terminal)? Using the mouse or keyboard shortcuts? Restricted to within the VM environment or rather between the VM and your host system?
Apparently you are referring to something that might be obvious to you but not necessarily for me. Therefore i need a more explicit description to enable me to reproduce it.
ah sorry. I mean copying and pasting between the QEMU virtual machine and host machine.
Quote from: jeffburg on Sep 19, 2025, 02:34 PMah sorry. I mean copying and pasting between the QEMU virtual machine and host machine.
I fear there is nothing i could do about this as this is outside of wmlive's scope.
I assume this to be rather a matter of the underlying virtualization environment.
Yeah, I think it's pretty optional because it's a niche use case. But I mention it because in normal debian it works out of the box. It appears that its related to this package
https://packages.debian.org/bookworm/qemu-guest-agent
Quote from: jeffburg on Sep 20, 2025, 01:52 AMYeah, I think it's pretty optional because it's a niche use case. But I mention it because in normal debian it works out of the box. It appears that its related to this package
https://packages.debian.org/bookworm/qemu-guest-agent
The qemu-guest-agent package is usually always included with any wmlive release and doesn't appear to provide any kind of copy/paste functionality between guest and host.
Further investigation shows that another package named spice-vdagent provides this missing functionality when installed within the guest:
# apt-get -m -t bookworm-backports install spice-vdagentTo make it actually work after installation, it is required to add a channel in the host's virtmanger to the guest VM as follows:
vdagent.png
If com.redhat.spice.0 is already in use, just increment its number to com.redhat.spice.1 to use it with qemu-vdagent. Maybe an equivalent configuration needs to be performed in the UTM qemu frontend?
While it seems possible to paste from host to guest by simply choosing a listing entry in the parcellite clipboard application, the usual keyboard combinations don't seem to have any effect. Also, i was unable so far to figure out the reverse copy/paste direction from guest to host.
In any case, that's an interesting approach i wasn't aware of before! Usually i apply a shared screen session to exchange copy and paste data, since i typically access guest hosts via ssh connection. So i was not even missing this specific functionality before.
Thanks again, Jeffrey! You particular perspective helps a lot broadening wmlive's scope! Keep it coming if you are not already tired of it. ;)
As a non-linux user, I am happy to provide uninformed opinions 🥴
An updated ARM64 ISO containing a few improvements and corrections (with special thanks to
@jeffburg) has been uploaded to sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/aarch64_experimental/ (https://sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/aarch64_experimental/), replacing the earlier version.
Nevertheless, the graphical installer must be dispensed with until further notice. As it turned out, when the graphical installer was forced to activate using the kernel parameter DEBIAN_FRONTEND=gtk, this unexpectedly causes the carefully configured preseed configuration to be simply ignored.
Unfortunately, this is fatal for our purposes, as it means that an absolutely essential comprehensive custom script cannot be executed at the very end of the installation before the first boot.
This certainly warrants opening a bug report at Debian.
Other than that, installation via serial console functions as designed and both the live session and installed system works as normal as can be expected.
Has anyone (apart from
@jeffburg) already been able to test the previous ARM64 version and would like to share their thoughts? I am mostly aiming at (preferably negative) feedback from third parties providing a different user perspective than my own.