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.

Hello:

As you indicate, with the back-lash or with the single-quotes it worked.
I did have to move the last double quote to the end of the stanza. otherwise the -geometry bit ie: 120x15 would act upon the application's icon and reduce it to a slit with what would seem to be a 120x15 size ratio.

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

The ideal thing would be to have xterm execute mail/mailx as the window opens, but adding && mail does not work, whether I move the last double quote to the end or not.

More sorcery ... 8^|

How can I get that done?

Thanks a lot for your input.

Best,

A.

Hello:

What I already have installed: exim 4.94.2.  8^D
Sorry, I was not explicit enough about it.

If interested, you can read about my dealings with it here:   https://dev1galaxy.org/viewtopic.php?id=4379
The last post in the thread sums it up in tl;tr: style.

I don't need to forward local mail anywhere, just be notified when mail arrives in my /var/mail/user folder.
Not necessarily in real time (would be nice) just anytime I log in to my desktop.

My box in not up 24/7 and I boot 3 or 4 times a day, so anytime I log in should suffice.

Thanks for your input.

A.

Hello:

UPDATE
I was finally able to get to the bottom of all this exim4 hassle.

Please bear with me, I'll try to be as brief as possible.

When a number of important security failures (dubbed 21 Nails by the IT press) were discovered in exim4 earlier this year, the maintainers were very fast on their feet and an upgraded version 4.94.2 was released almost right away, albeit not without some uproar from the community as this new fixed version actually broke a lot of things for many a sysadmin, things that had been working perfectly well for years.

To the extent that a great many considered opting to downgrade or write risky workarounds.
I have written about this in previous posts, read and check the links if you need more info.

Bottom line?

exim 4.94.2 effectively broke any and all configurations that had been set up with previous versions, whether they used the default configuration ie: the non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file or the split configuration scheme used in more complex installations and which you can eventually opt for when installing Devuan or by running dpkg-reconfigure exim4-config later on.

As a result, from stand alone desktops to production environments to server farms, absolutely everyone updating to exim 4.94.2 was affected.

As mentioned, the default non-split configuration scheme, probably used by 99% of all Devuan/Debian desktops, uses the /etc/exim4/exim4.conf.template which is part of the exim-config package, in turn a dependency of the exim-base package.

The problem I have been bitching about all this time was generated when I updated to exim 4.94.2, something I expected to be a straightforward affaire, without any hassles.

And as (most) any other update, it was.

Half way through, the installer popped up a warning in my terminal informing me that the configuration file being installed ie: the previously mentioned exim4.conf.template was different to the one I had in place and prompted me to choose what to do:

1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences.

I chose the default option and in doing so broke my exim4 installation.

As a result my Devuan Beowulf ceased to have a working MTA, all system mail was being held back.
ie: not delivered to my /var/mail/user folder while /var/log/exim4/paniclog slowly grew in size.

I found out about the cause of all this rather by accident.
After not being able to find a solution and fed up with looking, I decided to downgrade exim4 to the previous version and just risk it.

Then, looking at the installed packages, I noticed a discrepancy in their versions ie: exim-config had the previous package version number.

I downloaded and installed the proper version and when the installer warning described above popped up in my terminal, I realised what had happened when I upgraded to 4.94.2.

exim4 is now working as before.

----

Now, after feeling like an idiot for a whole afternoon, I asked myself:

1.
Why would I not choose the default option offered by the installer?

After all, WTF do I know about exim4?
Save that it is the default MTA in Devuan and it keeps me informed as to what is going on via the system mails I get in my /var/mail/user folder, nothing much.

I am not running a mail server from my box and if I add another box to my ADSL router, I believe sending mails between the two boxes is a simple affaire.

Like probably 99% of the Devuan desktops out there, a working default MTA is all I need.

In any case and just like the people who run them, I am just an average user and as such have an inherent trust in everything I download and install from the Devuan repositories, so I had absolutely no reason to choose anything but the default option recommended by the installer.

If I did not have this trust, my box would have something else running inside.

2.
Taking into account that exim 4.94.2 breaks all configurations set up with previous versions of the package ...

rant --->
How is it possible that the exim 4.94.2 installer offers me (as the default and recommended option, no less) to keep a configuration file that, belonging to a previous version, will effectively break it and make it useless?
<--- /rant

From https://www.exim.org/docs.html

From https://git.exim.org/exim.git/blob/HEAD … E.UPDATING

The /etc/exim4/exim4.conf.template file has 2200 lines of code contains a number of $local_part and check_local_user bits.
Unfortunately, editing it by hand did not help me when I did it, so evidently something else was needed.

That's about it.

Best,

A.

Hello:

Done.

Best,

A.

Hello:

One at a time, please, there's room for everyone ...

I think that the problem may lie in the fact that (according to apt) the installed exim4 configuration package ie: exim4-config is not the same version as the rest of the exim4 files in the stable-backports repository:

groucho@devuan:~$ apt list | grep installed | grep exim4

exim4-base/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]  # <---  | X |    
exim4-daemon-light/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4/stable-backports,stable-backports,now 4.94.2-5~bpo10+1 all [installed]
groucho@devuan:~$ 

All files are 4.94.2-5~bpo10+1 with the exception of exim4-config which is 4.92-8+deb10u6.

It does not seem to be available:

groucho@devuan:~$ apt list | grep exim4-config
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]
groucho@devuan:~$ 

[root@devuan groucho]# apt install exim4-config
Reading package lists... Done
Building dependency tree       
Reading state information... Done
exim4-config is already the newest version (4.92-8+deb10u6).
exim4-config set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]# 

The strange thing is that version 4.94.2-5~bpo10+1 is available in http://deb.devuan.org/merged  beowulf-backports/main which is in my sources.list file.

groucho@devuan:~$ cat /etc/apt/sources.list
## package repositories
# Changed - 20210218 - upgrade to Beowulf

# beowulf stable
deb http://deb.devuan.org/merged/ beowulf main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-security main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-updates main contrib non-free 

# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/merged/ beowulf-backports non-free contrib main  

# virtual box repository x installation
# deb http://download.virtualbox.org/virtualbox/debian/ buster non-free contrib 
groucho@devuan:~$ 

Could anyone explain what's going on with my sources.list?

Thanks in advance,

A.