You are not logged in.
At https://ido.rrq.id.au/download there is an initial collection of trial installer ISOs that need to be tested in a range of settings.
Everyone here who doesn't devalue themselves with the label "just a Devuan user" should grab at least one of them and run it through a number of variations, and then report on it, maybe as an email to me. Refer to usecases.html for the primary use case division. VM trials as well as bare-metal trials are good.
EDIT: my alternate email is rrq at rrq dot id dot au
Thanks for your work, Ralph
is hk the person giving this conference?
Get your decentralized project some EU funding
There is also KatolaZ' setnet which I understand works quite well too.
Yes. Although I used setnet in devuan jessie, I didn't mention it because I can't remember whether it depended on ifupdown. On the other hand, I can't find the packages in chimaera.
Simple-netaid uses ifupdown.
I fixed aitor's link and it works now.
Thanks ![]()
There were other excellent critiques written at the time. I remember one by Jude Nelson in particular but it all fell on deaf ears.
This one:
Systemd: The Biggest Fallacies (by Jude C. Nelson)
I see there's a new version of GNUinos ISO's posted to the Chimaera live mirror today, both 32-bit (PAE and non-PAE) and 64-bit, with XFCE or openbox. https://www.gnuinos.org/mirror/chimaera/live/
I've tried the XFCE version, think I'll have a look at the openbox version this time.
Yes, I've fixed some issues related to Hopman.
On the other hand, I'm also looking at the following plugin for SpaceFM, the file manager included in the openbox version:
https://github.com/jpfleury/corbeille-spacefm
because it doesn't send files to the trash bin when you hit delete in the right click popup menu.
If you decide to install another file manager, you must indicate it in the files below:
~/.xmenurx
~/.hopmanrc
If they don't exist, you can create them and copy the content of the respective files located in /etc/default, modifying them for matching your installed programs.
My beloved transparent gkrellm skin is failing on chimaera with this error:
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
(Details: serial 5672 error_code 4 request_code 56 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)It does run with the one and only "default" skin which is incredibly fugly.
Here's a tar.gz of the skin that I tweaked many years ago.
My now officially 80 year old brain is way beyond being able to sort this. I'm hoping the collective brain power on this forum might be able to pinpoint the problem. My eyes would be eternally grateful and others may enjoy it too!
Did you uncompress the tarball in your ~/.gkrellm2/themes/ ?
I know there are Xfce wallpapers at /usr/share/backgrounds/xfce. I can't find the Devuan ones, however. Any help? (I'm using Devuan 4 Chimaera Xfce.)
You can find them at /usr/share/images/desktop-base
I forgot: xmenu-cacherc has been renamed to xmenurc, and I did change it in my previous posts.
I' ve fixed a bug when running execv in xmenu-cache.c, and I'm rebuilding the iso images of gnuinos openbox.
Done. I've built the images mirroring from deb.devuan.org without issues:
https://www.gnuinos.org/mirror/chimaera/live/
Now you can give a try to the xmenu downloading the ob images.
aitor wrote:I replaced deb.devuan.org with pkgmaster.devuan.org a few days ago in my amprolla config files, and everything is working as expected since then.
Doing that works for you but will slow down the syncing of our mirrors and cause more timeouts for everyone else.
There are also some changes that are in the process of being sorted.
I'm trying again with deb.devuan.org
I' ve fixed a bug when running execv in xmenu-cache.c, and I'm rebuilding the iso images of gnuinos openbox.
xinomilo wrote:there's also rofi, dmenu replacement ...
Seems that this app (just from reading about it) suffers from what I have seen in many other applications: feature creep.
Why can't things go back to the tried and true do one thing and do it well and just not complicate things?I like how obmenu works and not getting it in chimaera is yet another reason to keep using beowulf with a backported kernel.
Recently I developed a dynamic cache for xmenu called xmenu-cache. It monitors /usr/share/applications keeping the content of xmenu up-to-date. The local directory /usr/local/share/applications should be added to the watching directories of inotify as well, but this directory is used only in some exotic cases, so I decided to leave the program as simple as possible so far. I included a built-in *.svg -> *.png conversor, because icons in .svg format weren't displayed by xmenu. You can test the menu running the new images of gnuinos-openbox (chimaera):
https://www.gnuinos.org/mirror/chimaera/live/
Alternatively, you can also install both xmenu and xmenu-cache from the package mirror in your current system:
http://packages.gnuinos.org/gnuinos/pool/main/x/xmenu/
http://packages.gnuinos.org/gnuinos/poo … enu-cache/
Once you have installed the packages, you need to follow the steps below:
Add a new line xmenu-cache & to your ~/.config/openbox/autostart in order to start the monitoring tool
Replace the default menu of openbox with xmenu.sh in your ~/.config/openbox/rc.xml
If you want to customize the static part of the menu (header plus footer), copy the content of /etc/default/xmenurc to ~/.xmenurc and modify the key-value pairs to suit your needs better. By default:
#===== Configuration file for xmenu-cache =====
ApplicationLauncher = gmrun
TerminalEmulator = sakura
FileManager = spacefm
TextEditor = geany
WebBrowser = icecat
Logout = logoutBear in mind that this is a work in progress, and it has nothing to do with my previous popupmenu in Gtk. It's faster and requires X11 instead, and neither does it depend on libmenu-cache. Only on lxmenu-data, because it requires some .desktop files in /usr/share/desktop-directories to classify the applications by categories.
Here you are a screenshot:

golinux wrote:deb http://pkgmaster.devuan.org/* is the source for all the round-robin mirrors accessed via deb http://deb.devuan.org/*. Please use deb http://deb.devuan.org/* in your sources.list to save bandwidth for the mirrors that are trying to sync to deb http://pkgmaster.devuan.org/*,
Done. Thank you very much for the quick help.
I replaced deb.devuan.org with pkgmaster.devuan.org a few days ago in my amprolla config files, and everything is working as expected since then.
Not quite sure about the openbox themerc. I asked for testers but no one ever responded . . .
It's the first I have heard of this. I installed the Clearlooks-Phenix-Deepsea-theme and the openbox themerc looks homogeneous and accords with the gtk theme.
I really like the latter. Thanks for all the work you do!
I also like that one. Thanks golinux!
Is it possible to run commands or program that converts Dev1 into Gnuinos
without a complete reinstall
No, such script doesn't exist. It might be a good idea to write something like this.
is the difference between dev1 and Gnuinos just the kernel being libre
or other stuff needed to change ?
No. There are other differences besides the kernel, e.g. eudev, runit, initramfs, to name a few. So, whereas transitions from devuan to gnuinos should happen smoothly, doing things the other way around isn't so trivial. On the one hand, some packages like dbus need to be downgraded because keeping the versions of gnuinos may be problematic depending on the init system you are using; on the other hand, if you convert gnuinos into devuan from vdev, you'll break the system for sure. This conversion must be done always from eudev.
Maybe, i'll write a how-to soon. Thanks for your interest ![]()
davidb wrote:Just tried to access the GNUinOS website. "Site Unavailable" and currently suspended? Anyone else seeing this?
It'll be available in a few minutes, thanks.
Done ![]()
Just tried to access the GNUinOS website. "Site Unavailable" and currently suspended? Anyone else seeing this?
It'll be available in a few minutes, thanks.
Did you try apt --fix-broken install?
the automatically connect option of simple-netaid is still a work in progress.
To automatically connect eth0 i have both:
auto eth0
allow-hotplug eth0
.......in my /etc/network/interfaces, and there is no need for ifplugd, no need for netplug. Hence, the automatically connect option of simple-netaid will involve only wireless interfaces.
I did another important change in the daemon. In relatively old hardware, i noticed a random behavior during the boot process which often crashed upon unsuccesful attempts trying to register the netlink kernel socket. Appearently, the origin of this failure was in the fact that the networking script of ifupdown was still running when snetaid started. The daemon of simple-netaid forks an asynchronous child, resulting on a couple of process IDs: on the one hand the ubus loop waiting for requests in the client side (parent), and the netlink monitor on the other hand (child). I solved the problem above mentioned by adding a routine called wait_on_ifupdown() before trying to bind the netlink socket in the child process.
Let's clarify further that this issue was a side-effect of handling both ifupdown and simple-netaid with runit, and i think that this wouldn't occur in the case of sysvinit. It happened that i migrated the networking script of ifupdown from /etc/init.d/networking to /etc/sv/networking/run and this approach seems to bring a definitive end to the problem of the slow boot waiting for network when the ethernet cable is unpluged, caused by stanzas like auto eth0 and allow-hotplug eth0 in /etc/network/interfaces.
You can verify this fact in the live images of gnuinos chimaera, but i need testers to confirm this point ![]()
My wifi connection attempts are failing under 32 bits, and i still don't know why... I wonder if anyone is experiencing something similar
I solved this issue yesterday night. I did a mistake in the format of one of the functions used in policy.c (snetaid) that affected only to 32 bit binaries. I've just uploaded the new packages, and updated the isos as well:
My wifi connection attempts are failing under 32 bits, and i still don't know why... I wonder if anyone is experiencing something similar