Hello:

I guess it was bound to happen to Devuan, sooner or later.

Sometime ago (last year?) I read about the huge backlash to the new path Xfce was taking as it moved forward to v. 4.16.
If I remember correctly, it was mainly about Client Side Decorations. 

See:
https://forum.xfce.org/viewtopic.php?pid=56141#p56141
https://forum.xfce.org/viewtopic.php?pid=56143#p56143
https://forum.xfce.org/viewtopic.php?pid=56144#p56144

I then thought it over and decided to stay with the version I have (4.12) as long as I can so as to give me time to consider something else altogether.
I was never too happy with how Xfce worked and this sort of set a limit. 

No need (for me), I won't continue past Xfce 4.12.

Q: which would be the safest and most foolproof/bulletproof way to keep Xfce from upgrading anything from now on?

Thanks in advance.

Best,

A.

Hello:

For what it may be worth, I sit sort of in the middle with respect to how pragmatic I'll willing to be.
Call it pragmatic but only up to a point.

ie:
I can, if the advantages are relevant, accept to have proprietary code within my installation if I can trust the origin and some of my hardware (WiFi, video card) needs it to work.
But I would not be willing to accept proprietary code if it is required for the OS itself to work.

A.

Hello:

Right ....

Let's try doing this:

~# apt install icedtea-netx-common  --dry-run

This should tell us if it will fix part/all of the dependency issues as it should drag in updated versions of openjdk-6-jre and openjdk-6-jre-headless.

Please post the output.

Best,

A.

Hello:

No ...

It was because it was late and I did not test the stanza first.
Command line stanzas must use the correct syntax to work.

The correct one is this:

~$ apt-cache depends icedtea-netx

It will get you the package's dependencies.

Then this one will get you the package's dependencies as well as the dependencies of the dependencies.
ie: the dependency tree.

~$ apt-cache rdepends icedtea-netx

My apologies for the slip.
Please run those and post the result.

root@nautilus:~# apt list | grep installed | grep icedtea

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

icedtea-8-plugin/now 1.6.2-3.1 amd64 [installed,local]
icedtea-netx-common/oldstable,now 1.6.2-3.1+deb9u1 all [installed,automatic]

--> There's no need for root for these. <--

BTW: you are using 'quote" instead of "code".

Best,

A.

Hello:

Sorry ...
My bad.

Yes it does.

root@nautilus:/# apt upgrade --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  linux-image-4.9.0-14-amd64
Use 'apt autoremove' to remove it.

The following packages have been kept back: <---- | x |
  icedtea-netx                              <---- | x |

0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

From what I see, the package icedtea-netx has been kept back and when a package is kept back it is because there is a dependency problem.

Open a terminal and do:

~$ apt list | grep installed | grep icedtea

This will tell you which icedtea-netx version is installed.

Then do:

apt-cache rdepends --installed $icedtea-netx

This will tell you which package is asking for icedtea-netx.

Best,

A.

Hello:

Not necessarily.

Please open a terminal, do ~$ uname -a and post the result.
That will tell us exactly what kernel version you are booting from.

Best,

A.

Thank you.
+1

A.

Hello:

Good luck finding getting any one of the existing/surviving motherboard OEMs to put out a properly oufitted motherboard with provision for an ARM CPU instead of an amd64 one.

Never heard  of the WinTel racket?

I would be (very) and much more so if it did not cost 3x or 4x the amd64 equivalent.

A.

Hello:

Just did my weekly apt update && apt upgrade.
Besides getting apparmor yet again* (like a very persistent case of the clap) got linux-image-4.19.0-17-686-pae.

Boots and loads desktop without issues.

A.

* Happens with every #%&" kernel update, in spite of apparmor not being installed in my system and having apparmor=0 in my kernel command line.
Is there no remedy for this?

Hello:

Should not be a problem.
I run ascii 4.19.0-16-686-pae on an Asus 1000HE 2Gb.
ie: SMP Debian 4.19.181-1 (2021-03-19) i686 GNU/Linux.

Unless I'm mistaken, the unmet dependecies warning is for your actual ie: working kernel, not the one you are updating to.

Open a terminal and (as root) do:

apt autoclean

Then do:

apt install -f 

Please post the output of this.
It will have information needed to find out what is going on.

Best,

A.

Hello:

I was convinced I had tried it with and without that -e there, so I checked again.
I was/was not mistaken: the catch is that xterm will open only if there's unread mail.

Clicking on the application icon when it shows mailbox flag in the 'down' position will not open xterm. 

So ...

coolmail -v -e "xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T 'System mail notification' -geometry 120x15-300+150 -e mail"

... works as expected.

I had spent a whole afternoon atempting various combinations, I actually got it to work ...
... but not with mail.

I opened up the configuration file /etc/X11/app-defaults/Coolmail and edited some of the default settings to be able to simplify the command stanza.

groucho@devuan:~$ cat /etc/X11/app-defaults/Coolmail
! Coolmail Application Defaults
!
coolmail.soundFile: /usr/local/bin/sounds/ding.au
!coolmail.frameCount: 10
!coolmail.inbox: /var/spool/mail/username
coolmail.mailCommand: xterm -geometry 120x15-300+150 -e mutt
coolmail.monochrome: False
coolmail*geometry: 76x84-1875+350
coolmail.volume: 100
groucho@devuan:~$ 

With that configuration file I can start up Coolmail in a terminal with :~$coolmail -v.
The application's icon shows up as expected and ~30s after I send myself mail from another terminal, the icon changes.

Clicking on the icon opens up xterm with mutt and I can process the new mail.
Problem is I really don't like mutt and (for the time being), I only need to read my system mail.
I won't be sending mail to anyone, so a terminal with mail is quite enough.

With your heads up, I edited the configuration file to coolmail.mailCommand: xterm -geometry 120x15-300+150 -e mail and now I can say it works.
I worked before but I assumed it did not. 

As expected, I get an xterm window, with the mail label which will do well enough.   
Thanks for that, it did not occurr to me there could be a different behaviour when clicking on the application's icon.

As the system beep set at 100 by coolmail.volume is not loud enough and also confusing, I tried using a *.wav file but I got a "Problem opening/dev/audio" error.
I looked for /dev/audio but it is not there.

groucho@devuan:~$ ls -l /dev/audio
ls: cannot access '/dev/audio': No such file or directory
groucho@devuan:~$

I then converted the file to *.au but got the same result.

The thing is that this really cool application is quite dated.
It was copyrighted back in 1994, so it uses OSS drivers which were dropped from the Linux kernel not too long ago (4.15?).

So I installed the aoss package. https://alsa.opensrc.org/Aoss

With that package installed, starting the application with aoss would solve the sound issue.
But no ...

groucho@devuan:~$ aoss coolmail -v
Coolmail 1.3 watching file: /var/spool/mail/groucho
Coolmail: Error writing to /dev/audio.
groucho@devuan:~$ 

Now, instead of not being able to open /dev/audio it cannot write to /dev/audio.
Thank you for helping me make some headway here.

The only thing pending is getting some audio output from Coolmail.

Best,

A.

A quotable quote if there ever was one.