The gimp-gutenprint plugin package has apparently disappeared from Excalibur.  Has anyone here investigated whether the latest plugin can be compiled from source and used with Gimp 3.0?  Or, has the jump from Gimp 2.10.34 to 3.0 made the plugin completely incompatible?

I'm seeing a repeatable problem when installing devuan excalibur aka 6 on libvirt.  The first problematic symptom is a hang for more than 30 minutes with the install UI saying "Finishing the installation" and "Running late-install-stage2..."  This problem appears to be similar to this topic: https://dev1galaxy.org/viewtopic.php?id=7521

Going to vt4 to see the installer's syslog, it appears the installer unmounts and ejects /dev/sr0, then runs script 18-late-install-stage2, which tries to install a few new packages: libestr0 libfastjson4 liblognorm5 rsyslog

Activating vt2, the 'ps' command shows the two last non-kworker, non-ps processes as follows:
- apt-get -y reinstall rsyslog
- /usr/lib/apt/methods/cdrom

My first hunch is that the cdrom got unmounted too early, and that's causing the apt-get package [re]installation to hang.  I'd love to supply screenshots, but I haven't seen how to add an image.

Running Devuan Daedalus and apt-cacher-ng, I'm not able to install 32-bit library packages (libx11-6:i586 for example).

Doing "dpkg --print-architecture" returns
amd64

Doing "dpkg --print-foreign-architectures" returns
i386
i586

These are the non-comment lines in /etc/apt/sources.list:
deb http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus main contrib non-free non-free-firmware
deb http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus-security main contrib non-free non-free-firmware
deb http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus-updates main contrib non-free non-free-firmware
deb http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus-backports main contrib non-free non-free-firmware

Doing "apt-get update" returns
Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' doesn't support architecture 'i586'
N: Skipping acquire of configured file 'contrib/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' doesn't support architecture 'i586'
N: Skipping acquire of configured file 'contrib/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' doesn't support architecture 'i586'
N: Skipping acquire of configured file 'non-free/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' doesn't support architecture 'i586'
doesn't support architecture 'i586'
N: Skipping acquire of configured file 'non-free/binary-i586/Packages' as repository 'http://127.0.0.1:3142/us.deb.devuan.org/merged daedalus InRelease' doesn't support architecture 'i586'
...

Any suggestions?  Thanks in advance.

Since switching from Chimaera to Daedalus ~10 days ago, ntpsec shows it's contacting the servers, but the offset grows by a fraction of a second per day.  It appears it's contacting the servers but not managing the drift, not controlling the clock.

The only changes I made from the Daedalus factory-supplied /etc/ntpsec/ntp.conf file is to comment out the pool entries and add two server entries in order to have consistency from one boot to the next.  These are my server entries:

server time.cloudflare.com nts
server oregon.time.system76.com nts

Doing "ntpq -p" shows this about 3 days after running "ntpdig -S" and restarting ntpsec::

     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
+time.cloudflare 10.119.8.155     3 8   33   64  377  10.5348 623.7458   0.5835
+oregon.time.sys 128.138.141.177  2 8   17   64  377  15.7338 627.3030   0.7425

Any suggestions to get ntpsec to put its hands on the steering wheel and drive?

In daedalus, with util-linux 2.38.1, /bin/more with no options initially clears the screen before starting to print text.  Based on over 40 years of using 'more', that is incorrect behavior--unless the -p or -c options had been supplied.  If the binary is called as 'page' or if the -p option is supplied, it's supposed to clear the screen.  In comparison, in chimaera, with util-linux 2.36.1, /bin/more with no options behaves correctly and does not initially clear the screen.  A web search did not reveal any discussion of how to work around this broken behavior.

Is there an (undocumented) option to nix the initial clearing of the screen?

As a side note, there's also a bug introduced probably over a decade ago now where 'more' quit showing one overlapping line of text.  If the binary is called as 'page', it's supposed to initially clear the screen and show zero overlap.  If the binary is called as 'more' with no options, it is supposed to _NOT_ initially clear the screen and is supposed to show one line of overlap as it scrolls.