Also to add: We have another listing now. No package will disappear and is either added, removed as being not possible or added for later research.

https://git.hyperbola.info:50100/~team/ … d-later.md

Depends: Most the time - besides really little packages and libraries - I'll use first the 32bit for the first compilation, afterwards 64bit on X220 for the second and another test with librechroot on 32bit before a commit, therefore VLC is the next to do. Finished right now with both, but waiting for librechroot.

Yes, real hardware most the time, so I can also do a first QA-session (Quality-Assurance). But that is for sure not final. When we are finished with the list, we will proceed therefore also with runit and therefore both 32bit (X60s) and 64bit (X220) will be reinstalled with the INIT-system in conclusion. But that's only my conclusion to do: Any kind of VM is also working. So next also virt-manager or something to compare to manage that.

I was frustrated already with seeing enlightenment being that kind of a problem. But well? Using many Linux-only frameworks right now it would be more or less a coming problem for the future. So the best option is to get that aside as environment! Just to mention: We have nice looking window-managers and Lumina. Most of them can use compositing with xcompmgr or picom. First mentioned is running right now here on the 32bit-environment without having that issues on performance. We have lost nothing from my point of view when enlightenment is not added. Perhaps use e16 with the next install and QA for runit?

I'll focus later onto xfig so most graphic-software is ready for testing and usage. If there are some issues with sndio not solved, please also add them as soon as possible for us to review them - especially with packages - addressed to all reading and testing already. Next on the listing:

xfig
simpleburn
vlc (as mentioned already, but waiting for libraries to be added within repositories)
gigamesh

I think: runit does not need dbus to run, so the problem is at other parts. Same with pinentry back then before solved. Yes, dbus is part for many things but it stays at the desktop most. So poweroff and reboot to test from the console. Suspend is just a way other topic for both. But therefore is uswsusp within the repositories and to combine that with some key-combinations also to look. Especially that: Is this functional on Void Linux for example? Because when testing here at my local installation this does not work either with key-combination "FN + F4". So I cannot test your usecase!

Okay, I think I've got it: You mean suspend to disk with the key-combination? Well, that will be not possible with version 0.4. I can't do it even on the test-systems using HyperRC right now. If you want to suspend, you have alternatives added and can use that on other ways. Again the recommendation for uswsusp for suspending. This was added already and is available within the repositories.

Doing that perhaps with some modifications onto keymapping, but in general there is no way to know that Fn was pressed and the scancode and the keycode of key-combinations including Fn depends on the individual keyboard design. More or less I'd say this part won't be onto focus, is for sure not an error and won't work with version 0.4 and later. You can create own alternatives for sure, perhaps when we add antimicro later as one possibility to execute a script or concrete commands.

Not an important one. If wmctrl isn't in the repo there, do you think it is necessary?

• wmctrl: https://git.hostux.net/HarvettFox96/hyp … 96/wmctrl/

Here to help and yes, there is a way to use this method as user. I'll write more about that later within a seperated thread as the kernel-module is more or less not that complicated to be used further. For a start: https://wiki.archlinux.org/title/Uswsusp

Yes you can modify your doas-configuration. For example to execute poweroff or reboot:

permit nopass USERNAME as root cmd /sbin/poweroff
permit nopass USERNAME as root cmd /sbin/reboot

Of course USERNAME is your correct username on the system. Afterwards you can use the command like this:

doas /sbin/poweroff

And same for the usage for suspending through the kernel-module.

And you can use also:

permit nopass USERNAME as root cmd /usr/bin/s2ram

Please have in mind that a GNU-systems invites you for experimenting with the configuration and tryout. That's not bad, in fact it is your freedom to do what you want with your system. So with above configuration you can afterwards use:

doas /usr/bin/s2ram

Proposal: I'll have here a system most fresh installed and within need for suspend also. IceWM as my favorite window-manager is installed and configured. So I have to do the same as this system has no dbus and 0.3.1. I'll share my part and configuration later.

Sorry, don't want to be rude or unfriendly: You have installed dbus on the system? The problem is: dbus left some rest onto it. System-configurations within home-folder, settings and more. Better to get rid of all as otherwise the test is more or less becoming even more complex to find out. I can for sure say: No function-key with HyperRC (openrc) on 0.4. Also on 0.3.1 when I build the system from the ground without dbus (and blacklisting dbus afterwards). And I think we both have comparable setup:

Build-system 1 (local): ThinkPad X60s 32bit-only
Build-system 2 (chroot): ThinkPad X60s 32bit-only
Build-system 3 (chroot): ThinkPad X220 64bit-only

Productive (0.3.1, multilib): ThinkPad X200 and X220

No system with dbus left.
Not meant to draw any line, just to make the testing-scenarios way easier. A system without dbus do behave for sure not like a system with dbus. For calling that: Even the service itself consume much more power, right from startup. And dbus itself brings more complexity with. Removing it leaves a rest! I have no way to test FN + F4 for example: It just don't work, also with HyperRC / OpenRC.

Sorry when I've got you wrong. Thanks for more information to clarify. Was not sure how you migrated towards 0.4 as I'm now only with testing-systems and my production here. Have also the chance used to get another X220 for testing-purpose. I can understand also the opposite as 32bit-systems are way more complicated to get these days for example, a problem of the industry and behaviour itself (by manufacturing, marketing and more).

EDIT: I have changed this post, my bad for posting the wrong stuff here,

I apologize for being lazy and posting my error reports here, I wasn't thinking at all.

Thanks for correcting me.

I have put them on the issue trackers, aka, the sndio bug and hplip request...