You are not logged in.
Thanks prospero, recently I fixed a bug related to the creation of symlinks at /dev/disk, as explained in the DNG mailing list:
Yes, the live-sdk
As for lxdm, I chosed it because it allows me to run a script that customizes the active plugins in xfce4-panel. I tried the same with other display managers, but I didn't succed.
different from the 32 bit version, with it the installation with the GNUinOS installer did work immediately (and the other way I did use in 32 bit starting from the iso live and installing after the installation from refractainstaller out the live started image would not start).
gnuinos live images contain the package nodm; and the removal of nodm during the preseed phase of the gnuinos-installer may lead to this matter
It seems to be parent with GNUinOS, perhaps is Refracta Linux the base of GNUinOS?
No, gnuinos isn't built upon refracta. Gnuinos modifies some packages taken from devuan and builds its own repository by adding a new level in the amprolla infrastructure.
Hence, the issue you are talking about, i.e. some input devices not processed by vdev has nothing to do with refracta. It happens, from my own experience, during live sessions under 32 bits. I'm fixing the problem right now (I've found the origin), and I'll update the iso images as you suggested. Thanks for your help
@golinux: the letter "C" doesn't exist. It would be Eskalibur
different from the 32 bit version, with it the installation with the GNUinOS installer did work immediately (and the other way I did use in 32 bit starting from the iso live and installing after the installation from refractainstaller out the live started image would not start).
So, the issue related to the 32bit installer happens with your refracta snapshot of gnuinos?
probably are the problems in 32 bits from the same kind but have only not the same tragic consequence: it seems not to be a matter of rights but only from dysfunction of the input equipment. I will try it again on my other laptops in the next days (to much time invested for today! I am now in the hurry...) having only an usual keyboard and touchpad...
Gnuinos uses vdev by default. Is the whole xinput equipment listed in /dev/metadata/udev/input file? What init system are you using?
I'm building Gtk3 without dbus by defining a variable that allows to enable/disable the atk-bridge part at build time.
This variable is used in the file `gtk/a11y/accesibility.c` as a preprocessor directive. For example:
#ifdef HAVE_ATK_BRIDGE
#include <atk-bridge.h>
#endif
In doing so, it's possible to remove dbus from Gtk3. Gtk2 doesn't depend on it.
As for luks2..., no answer yet
Thanks for your work, greenjeans!
Live sessions in qemu take too long at me as well. However, I don't think that the start-up messages you are showing are the culprit. Runit run scripts exit if dependencies are not satisfied (i.e. if a service starts before another service the earlier depends on) throwing such messages and retrying afterwards until it succeeds. But I need further testing, of course. Thanks!
The following images worked for me in qemu:
https://www.gnuinos.org/mirror/daedalus/runit/
I'll update the repository tomorrow.
it's using the alsa backend to do that as well
Keeping the gui updated in real-time according to the current values given by the alsa backend without thereby freezing the interface wasn't that easy for me when I developed the amixer-gtk. Didn't you push the source to any git repository yet?
I'll test It again at home, thanks
It looks nice. Which toolkit are you using?
@zapper: I'm referring to Jude Nelson's device manager
@Prowler_Gr: vdev has been notably improved since my last post, and now it works fine with runit, sysvinit and openrc, whereas s6 is a work in progress.
I'm updating the repository in order to rebuild the iso images as soon as possible.
If I was interested in making an init-diversity spin of GNUinOS, which variant in your opinion would be the most popular to base this on?
Thanks a lot for your interest in gnuinos. Well..., I don't know which would be the most popular. You can email me in private.
Syslog isn't the culprit, but some of the changes I did in the daedalus version of vdev (chimaera images do work). So, I've found the solution to the problem (at least in qemu) by comparing both releases. Tested with qemu and only in one machine, though. Give me a couple of days and I'll update daedalus images.
Thanks again for your patience and your tests, prospero!
@prospero: the website will be available today, thanks
I'm working on that. I would like to be able to integrate vdev in other systems like Hyperbola, Guix, Void, Alpine...
Thanks a lot, Prowler_Gr, I'm downloading the images to give them a try.
Nowadays udev is a transitional dummy package that is present only for backwards compatibility. If someone needs to upgrade a system with the old udev, this one will be replaced with an empty package that depends on eudev. Once the system has been upgrade, the superfluous package can be removed afterwards, as you use to do.
I check off Openrc, I uncheck default desktop environment and check xfce4 desktop
Openrc + vdev is not tested. The best choice is runit.
If you are using dhcpcd5, you can disable ipv6 by adding the line below to /etc/dhcpcd.conf:
# Don't solicit or accept IPv6 Router Advertisements and DHCPv6
noipv6
What is /root/dev? Why is it trying to mount there?
Have a look at /usr/share/initramfs-tools/init, you'll find the following lines moving /run and the virtual filesystems /sys and /proc to the real system:
export rootmnt=/root
(...)
# Move /run to the root
mount -n -o move /run ${rootmnt}/run
# We expect udev's init-bottom script to move /dev to ${rootmnt}/dev
run_scripts /scripts/init-bottom
# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
mount -n -o move /proc ${rootmnt}/proc
Udev's /usr/share/initramfs-tools/scripts/init-bottom/udev script will move /dev to ${rootmnt}/dev, as its supposed to:
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev