You are not logged in.
Hello:
Asked apt to update early today:
~$ sudo apt update
Hit:1 http://deb.devuan.org/merged daedalus InRelease
Hit:2 http://deb.devuan.org/merged daedalus-updates InRelease
Hit:3 http://deb.devuan.org/merged daedalus-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
89 packages can be upgraded. Run 'apt list --upgradable' to see them.
~$ 89 packages seemed rather a large number so I checked my /etc/apt/sources.list and asked again, with the same result.
--- snip ---
89 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 236 MB of archives.
After this operation, 470 MB of additional disk space will be used.
Do you want to continue? [Y/n] The three new packages are linux-headers-6.1.0-22-amd64, linux-headers-6.1.0-22-common and linux-image-6.1.0-22-amd64.
Watching the printout as it rolled on, I noticed multiple lines which started with a W:
--- snip ---
update-initramfs: Generating /boot/initrd.img-6.1.0-22-amd64
W: Possible missing firmware /lib/firmware/nvidia/gp100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp100/acr/bl.bin for module nouveau
--- snip ---
W: Possible missing firmware /lib/firmware/nvidia/tu102/sec2/image.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/tu102/sec2/desc.bin for module nouveau
--- snip ---It was a very long list of Possible missing firmware entries which I have shortened for clarity.
Everything else went on as expected and sudo apt install -f had nothing to say.
Anyone else see this?
Have not rebooted yet so I cannot say if there are any ill effects.
I will check the logs report later.
Thanks in advance.
Best,
A.
Hello:
Came across this article at The Regsiter this morning.
-------------------------------------------------------------
Windows: Insecure by design
Get your hands off my computer, Microsoft!
Steven Vaughan-Nichols - Fri 28 Jun 2024
-------------------------------------------------------------
https://www.theregister.com/2024/06/28/ … by_design/
Nothing new, of course.
Best,
A.
Hello:
Still trying to solve a relatively small but annoying tear/artifact in my xorg/nouveau setup in Dadedalus.
Like I posted here:
There is still the matter of some slight tearing which did not ocurr with the Nvidia drivers ...
... there may be some xorg.conf magic to be done as nouveau does not seem to use one by default.
I have managed to sort out an xorg.conf with just a Monitors section to exactly duplicate what xorg automagically does by itself without one for a three 19" monitor setup with two Nvidia FX580 cards and no Xinerama.
Not using Xinerama is a large bonus: now RandR can be used and other applicatons (such as Firefox) which use its output don't make a mess of the way the drop down menus work. ie: invading the next monitor's screen when deploying sideways.
~$ cat /etc/X11/xorg.conf
# xorg.test - started 20240618
# Layout for four screens - 4th. screen not connected
#
# (0,0)---------+(1280,0)------+(2560,0)------+
# 1 > | || || |(3840,256)---+
# 0 > | 1280x1024 || 1280x1024 || 1280x1024 || 1024x768 |< 7
# 2 > | DP-3 || DP-1-2 || DP-4 || DP-1-1 |< 6
# 4 > | SM940n || D1914S || SM940n || P150S |< 8
# +-------------++-------------++-------------++------------+
# |<--- 1280 ---|
# |<--------- 2560 --------->|
# |<----------------- 3840 ---------------->|
# |<------------------------ 4864 ----------------------->|
#
### <--- MONITORS ###
Section "Monitor"
Identifier "DP-3"
# Option "Primary" "true" # defined in Option "Position"
Option "DPMS" "0"
Option "PreferredMode" "1280x1024_75.00"
Option "Position" "0 0"
EndSection
Section "Monitor"
Identifier "DP-1-2"
# Option "LeftOf" "DP-4" # defined in Option "Position"
Option "DPMS" "0"
Option "PreferredMode" "1280x1024_75.00"
Option "Position" "1280 0"
EndSection
Section "Monitor"
Identifier "DP-4"
# Option "RightOf" "DP-1-2" # defined in Option "Position"
Option "DPMS" "0"
Option "PreferredMode" "1280x1024_75.00"
Option "Position" "2560 0"
EndSection
#####################################################################################
# Section "Monitor" # not connected
# Identifier "DP-4" # n/c check with monitor connected
# Option "RightOf" "DP-1-2" # defined in Option "Position"
# Option "DPMS" "0"
# Option "PreferredMode" "1024x768"
# Option "Position" "3840 256" # n/c check with monitor connected
# EndSection
######################################################################################
### MONITORS --> ###This makes for a 3840x1024 screen, which xrandr IDs as Screen0:
~$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1024, maximum 8192 x 8192
DVI-I-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mmUnfortunately, I have not been able to find out what settings I need for the ServerLayout, Device and Screen sections to be able to finish putting together a complete xorg.conf which I hope to be able to tweak so as to get the most of my twin card setup.
But I think I have found the origin of the diagonal tear at times present in the middle of my center monitor's screen (upper left down to lower right).
While trawling the web I came across this tidbit:
About not using Xinerama, I ran into a "BaseMosaic" option in the nvidia documentation somewhere in Appendix B:
--- snip ---
... Base Mosaic does not guarantee there will be no tearing between the display boundaries.
--- snip ---
Did not quite understand what it was about till I realised that I don't have three working 1280x1024 screens but one 3840x1024 screen driven by the combined output from the two cards, each card driving 50% of the whole screen.
And the display boundary mentioned in the cited post being the slight diagonal tear I see in the center of the 3840x1024 screen.
This is as far as I have been able to get.
Any ideas on how to continue?
I think there is room for improvement as I expect that whatever settings the xorg/nouveau combo is using are probably default/conservative.
Thanks in advance.
Best,
A.
Hello:
... driver and printer firmware that cups cannot install.
Quite so.
Like I explained in my OP, that would be the *.ppd file (Samsung_M2020_Series.ppd) extracted from the Linux driver uld_V1.00.39_01.17.tar.gz file which I obtained directly from HP.
As the use of *.ppd files will be deprecated by CUPS in a future release, I need to plan in advance.
I will keep looking to find out what will happen with my M2020W printer when that happens.
... your decisions ...
Indeed.
It happens that I have an innate distrust for any script coming from HP.
And a *.ppd is a plain text file I can open and look at.
Exotic?
Yes, I have to agree.
I think it would be rather difficult to find something more exotic than that. 8^)
Thank you for your input.
Best,
A.
Hello:
... as I understand it.
Yes, that is one way.
But you can forego the hplip part by installing CUPS and adding the local printer via the UI.
If the printer is connected (parallel, serial, USB), the system will see it and as a result, CUPS will find it.
To finish you only need to provide it with the printer's *.ppd file, at least that is how I recall having done it at the time.
As I mentioned in the OP, at some point in the future CUPS will no longer use *.ppd files.
It is not clear when that will happen but it has been talked about since 2021.
As a result of this change, it would seem that whatever printer you have installed will either work as usual or need some application from the OEM to work.
I do not expect Samsung/HP to provide any such thing.
It is still not clear to me if the M2020W will work or I will need to pin CUPS at the last working version which is why I asked.
Thanks for your input.
Best,
A.
Hello:
... indestructible LaserJet ...
Yes.
I still shed a tear when I remember all those LaserJet 4/5 sent to the landfill in early 2000 where I worked.
It was a very different Hewlett Packard back then.
... run the install.sh script in the uld folder.
Indeed ...
After having to wrangle (at that time) with this printer's installation in Linux, I resorted to CUPS, which worked from the get-go.
As it did a good job, I want to continue with CUPS instead of using the Samsung/HP ware and its install routine.
Besides, doing so is more akin to the Unix/Linux philosophy.
Thanks for your input.
Best,
A.
Hello:
After quite a bit of hassle, I was able to get CUPS working properly in my upgraded Daedalus installation.
It was working perfectly well in Beowulf but something happened on the way to Daedalus, so to speak and eventually had to resort to a complete purge of anything and everything CUPS related to then reinstall the application.
Doing things 'the Windows way' is not my idea of fixing things like these in a proper manner, but I was at my wits' end.
I have no idea why all this happened but now it seems to work properly.
As I do not print much, time will tell if it holds or not.
My printer is an inexpensive+basic Samsung / HP Xpress M2020W released ca. 2014, good enough* for what I need at home.
* no ethernet port, just WiFi (which I do not use) but given the price I paid for it cannot complain.
I managed to get it working by using the *.ppd file Samsung_M2020_Series.ppd extracted from a driver file named uld_V1.00.39_01.17.tar.gz downloaded directly from HP, which seems to be the last available version.
Note: it would seem that a file named rastertospl, located the uld/x86_64/ folder is also needed to get the printer working properly.
Otherwise you get an error message in the log which reads:
File "/usr/lib/cups/filter/rastertospl" not available: No such file or directoryIt does not seem to be available in any Linux package and the problem is solved by copying it to that directory as root.
Now, with CUPS working properly, at boot time my /var/log/cups/error_log reads:
~$ cat /var/log/cups/error_log
W [24/Jun/2024:07:37:19 -0300] Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
~$ The link in the terminal printout redirects to this webpage which started getting comments in 02/2021, over three years ago.
"Printer drivers are deprecated and will stop working" reads just as forboding as when Nvidia dropped their legacy 340.108 drivers.
Hopefully I am wrong.
The whole thread I linked to above is pretty much printer protocols/drivers specific and is way over my head.
So the question is:
Anyone here at Dev1 use one of these printers (or any other printer needing a *.ppd) with CUPS without resorting to specific printer drivers?
Thanks in advance.
Best,
A.
Hello:
Thank you ...
You're welcome.
... but what a process...
Indeed ...
But at least there is a solution to whatever is evidently wrong with that HW.
That said, I cannot imagine why it would be disabled in this manner, but then again ...
Cheaper this way for the OEM?
Please do let the forum know how you fared with this endeavour.
It will surely be useful to others in the same spot.
Best,
A.
Hello:
... anyone know what is missing?
Quite possibly (?) the correct firmware is missing/not being loaded.
Seems that hardware has a few issues:
... if you want to slowly drive yourself mad; and quietly pull all your hair out at home; all by yourself ...
See: https://forums.opensuse.org/t/gobi2000- … swer/71270
For the record:
Laptop is an Lenovo X201 12’ Notebook. It was sold with WWAN (generical, not bound to provider - at least sold like this) and sold without any O.S. (which made me avoid the MS tax. The unpacking of the latest driver was done with wine, The option choosen was to combine the firmware solution “6” and “UMTS”. I copied all 3 files in /lib/firware/gobi (after having compiled successfully Gobiloader 0.7 from the wesite of the project beforehand).
Watch out to position the sim with the “cut” side versus the outer border (direction of battery) of the notebook and contact plate vs the bottom. This seems to be a bit “counterintuitive” but gives the desired result.
The device mounts under /dev/ttsy/usb1 (and not /dev//usb0 or 2). The other two positons are also claimed, maybe that part is the GPS I guess.
If that does not work, check these other posts:
https://forums.linuxmint.com/viewtopic.php?t=202158
https://forums.centos.org/viewtopic.php?t=50599
One of them may be a lead to a solution, HTH.
Best,
A.
Hello:
... xserver-xorg-video-all: "It does not provide any drivers itself, an may be removed ...
Interesting ...
Maybe installing/reinstalling what I know I need ie: xserver-xorg-video-nouveau, xserver-xorg-video-vmware and maybe some other one/s (have to figure out which) will keep them in the system (as manually installed) when I get rid of the ones I don't need.
I'll see what gives in a few days' time.
Thank you for your input.
Best,
A.
Hello:
... have a look.
But I did, I did !!! 8^)
This page has a section for the Debian 12 "Bookworm" Nvidia driver Version 525.105.17.
Consequently, that same section has a link to an Nvidia webpage labelled Appendix A. Supported NVIDIA GPU Products, this list being basically divided in two important parts:
The first part is the list of current NVIDIA GPUs supported in the unified driver and the second part is the list of all the legacy NVIDIA GPUs which are no longer supported in the unified driver.
The second part is in turn divided into separate sections, according the the different unified driver versions and their supported GPUs.
If you open that page in your browser and search for Quadro FX 580 or for the card's PCI_ID, 0659, you will only find it under the heading that reads "The 340.xx driver supports the following set of GPUs:"
The 340.xx driver supports the following set of GPUs:
NVIDIA GPU product Device PCI ID* VDPAU features
GeForce 8800 GTX 0191 -
--- snip ---
Quadro FX 580 0659 A ###
--- snip ---
NVS 300 10D8 CWiki may also be wrong ...
Of course, shit happens all the time.
But the link is to an official Nvidia web page.
They most probably got it right.
Thanks for your efforts to help.
Best,
A.
Hello:
Debian 12 "Bookworm", Version 525.105.17, supported devices Quadro FX 580.
https://wiki.debian.org/NvidiaGraphicsDrivers
In repo Devuan v.525.147...
Hmm ...
Me thinks not.
This is what I get in my up-to-date box ...
~$ uname -a
Linux devuan 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux
~$ ... with nvidia-detect:
~$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96CGL [Quadro FX 580] [10de:0659] (rev a1)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96CGL [Quadro FX 580] [10de:0659] (rev a1)
Checking card: NVIDIA Corporation G96CGL [Quadro FX 580] (rev a1)
Your card is only supported by the 340 legacy drivers series, which is only available up to buster.
Checking card: NVIDIA Corporation G96CGL [Quadro FX 580] (rev a1)
Your card is only supported by the 340 legacy drivers series, which is only available up to buster.Unless I have missed something, the G96CGL/[Quadro FX 580 card (PCI ID:0659) needs the 390.xx driver but it is not available in the Bookworm/Deadalus repository.
~$ sudo lspci -nn | grep -e VGA
[sudo] password for groucho:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96CGL [Quadro FX 580] [10de:0659] (rev a1) # <-
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96CGL [Quadro FX 580] [10de:0659] (rev a1) # <-
~$Thanks for your input.
Best,
A.
Hello:
From what I have read, a working compton.conf ...
Not really ...
There are a set of deprecated entries which will prevent picom from starting when you test it from the terminal, but there is a warning to that effect with instructions.
Installing picom gets you a /usr/share/doc/picom/examples/picom.sample.conf file that has to be copied to ~/.config/picom/picom.conf after creating the destination directory.
I have purged compton and installed picom with no ill effects.
And after editing the *.conf file to get rid of all the shadows, fading, partial opacity, bluring and such I now have a snappy Linux desktop.
There is still the matter of some slight tearing which did not ocurr with the Nvidia drivers, but they are in the past now.
I'll have to make do with what is available, there may be some xorg.conf magic to be done as nouveau does not seem to use one by default.
Best,
A.
Hello:
After (more or less) getting my nouveau+compositor setup working, I set out to see about a bit of screen tearing I am still getting.
Not terrible ...
But it was not there when I used the (now unsupported) Nvidia drivers for my twin G96CGL / Quadro FX580 cards and would like to see if I can improve things.
While at that, I saw that the task-desktop package installs, besides the nouveau package, quite a few other xserver-xorg-video-* packages:
~$ apt list | grep installed | grep xorg-video
--- snip ---
xserver-xorg-video-all/stable,now 1:7.7+23 amd64 [installed,automatic]
xserver-xorg-video-amdgpu/stable,now 23.0.0-1 amd64 [installed,automatic]
xserver-xorg-video-ati/stable,now 1:19.1.0-3 amd64 [installed,automatic]
xserver-xorg-video-cirrus/stable,now 1:1.5.3-1+b5 amd64 [installed,automatic]
xserver-xorg-video-fbdev/stable,now 1:0.5.0-2 amd64 [installed,automatic]
xserver-xorg-video-nouveau/stable,now 1:1.0.17-2 amd64 [installed,automatic]
xserver-xorg-video-radeon/stable,now 1:19.1.0-3 amd64 [installed,automatic]
xserver-xorg-video-vesa/stable,now 1:2.5.0-1+b1 amd64 [installed,automatic]
xserver-xorg-video-vmware/stable,now 1:13.3.0-3.1+b1 amd64 [installed,automatic]
~$ All automatically installed.
Save some severe hardware problem or coming across a more interesting ie: better+free/very cheap video card alternative, I have no plans to make any changes, so the Nvidia hardware will stay where it is, works perfectly well.
That being the case, I was wondering how to safely get rid of the driver packages I am loading and will not ever load.
After all, as the sole user of this box, if I need drivers for a different video card, I will be quite aware of that.
There will be no surprises.
I asked aptitude about them all:
~$ aptitude why xserver-xorg-video-all
i task-desktop Depends xserver-xorg-video-all
~$ ~$ aptitude why xserver-xorg-video-amdgpu
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-amdgpu
~$ ~$ aptitude why xserver-xorg-video-ati
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-ati
~$ ~$ aptitude why xserver-xorg-video-cirrus
i task-desktop Depends xorg
i A xorg Depends xserver-xorg (>= 1:7.7+23)
i A xserver-xorg Depends xserver-xorg-video-all | xorg-driver-video
i A xserver-xorg-video-cirrus Provides xorg-driver-video
~$ ~$ aptitude why xserver-xorg-video-fbdev
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-fbdev
~$ ~$ aptitude why xserver-xorg-video-nouveau
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-nouveau
~$ ~$ aptitude why xserver-xorg-video-radeon
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-ati
i A xserver-xorg-video-ati Depends xserver-xorg-video-radeon
~$ ~$ aptitude why xserver-xorg-video-vesa
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-vesa
~$ ~$ aptitude why xserver-xorg-video-vmware
i task-desktop Depends xserver-xorg-video-all
i A xserver-xorg-video-all Depends xserver-xorg-video-vmware
~$ From what I can make out, xserver-xorg-video-all drags in the amdgpu, ati, fbdev, nouveau, vesa and vmware driver packages while the cirrus and radeon packages have different dependencies.
I guess that this is (?) because they are fallback/basic drivers required by xserver-xorg to make sure there is always a screen at boot time if X is being used.
Unless I have missed something and some other package needs to remain installed ...
What would the proper/safe method for removing the unused packages and keep only the nouveau package?
Thanks in advance.
Best,
A.
Hello:
A necessary heads up.
... because the repository was archived on 08/2023 and is considered to be deprecated.
It would seem that compton itself, although it has not been explicitly archived by the maintainer, would be at least in a pre-archived state as (apparently) they have had no activity there for the past five years.
ie: there are unassigned issues from as far back as 2019 with no input from them.
[rant]
Would it be too hard to at least say: "ain't doing no mo' maintaining, bitch!"
But in a timely fashion ...
[/rant]
An unanswered post post from 01/2022:
Since the development on compton has halted, this repository should advise to switch to picom (https://github.com/yshui/picom) at the top of the README. In addition, it should be archived to further make it clear that asking for support here is a waste of time.
This would clarify the status of the compton package with picom packages available for Ceres, Daedalus and Chimaera.
From what I have read, a working compton.conf file would work also with picom, but we'll have to see about that.
Best,
A.
Hello gl:
Thanks ...
You're welcome.
When I finally get to ...
Ahh ...
Good to see I was not the only one deferring a system upgrade. 8^)
Not looking forward to doing it again, I see that /usr merge looms in the horizon.
Who knows what else awaits my (ca. 2007 and perfectly working) non-UEFI box.
That said, it may be worth considering ie: packagers taking note, that the native Xfce compositor does not work properly while compton 1-1+deb12u1 does.
It is a sign of the times we live in that Xfce maintainers never bothered to fix the long standing (pre 2018) compositor issues they had and (surprise!) added native compositing. I wonder what else they will add in future versions, seeing that the 2020 row generated by pushing CSDs was not duly noted.
I did at one point try out compton-conf but did not manage to get things properly configured.
Probably because the repository was archived on 08/2023 and is considered to be deprecated.
Fortunately, I got a good result following the instructions in the link I posted, although there may still be some room for improvement.
Best,
A.
Hello:
... encountered the same problem ...
... could do nothing about it.
Well ...
There seems to be (and evidently still is) some sort of problem with Xfce+compton.
Previous versions of Xfce (4.10-4.16) had a problem if compton was installed/enabled: Firefox, Thunar (and other desktop applications) would crash if you tried to drag something with the mouse pointer. eg: move around shortcuts within menus in FF, drag folders in Thunar.
Being a common issue to both applications, it was obviously not a FF or Thunar issue so I posted a question to the forum in 2018 and again in 2021.
I also posted a bug.
The questions to the forum never got a reply and the bug report got one stating that it was an Nvidia/compton/unsupported Xfce 4.10 problem, to try with 4.12 ...
The same problem persisted till Xfce 4.18 when it got "solved" by adding a native compositor.
A compositor which does not work properly.
So ...
Where is the problem?
Moot point now.
Disabling the Xfce native compositor and installing compton seems to be what is needed.
Best,
A.
Hello:
... defies the idea of panel transparency ...
Right after posting my question I remembered a package called compton that had to do with transparency.
I saw that it in was the repository but was not installed (it was installed in ASCII and Beowulf), so I disabled compositing in Xfce and installed / enabled compton.
And that was that, problem solved.
The panel transparency works as before.
I am still getting a very faint diagonal tear I had across (upper left to lower right corners) in my centre monitor when scrolling and in every monitor when resizing windows by dragging with the mouse pointer.
I'll look into that in another thread.
Best,
A.
Hello:
After finally upgrading my box from Beowulf to Chimaera and then to Daedalus and having solved problems that arose with Wine and CUPS, I am now in the process of getting the desktop working as it did before the upgrades.
My original Xfce setup took me some time to get right but it worked: from Jesse to ASCII to Beowulf and I got used to it.
But now, with Xfce 4.18 I cannot get the panel transparency working properly.
ie: as it worked in the previous version of Xfce, with the panel itself totally transparent and the launcher icons / minimised windows completely opaque.
I have followed the instructions but have not been able to get it to work as before: now both the panel background and the launcher icons / minimised windows become transparent at the same time.
Sort of defies the idea of panel transparency ... 8^/
Does anyone have the same problem?
Thanks in advance.
Best,
A.
Hello:
... have to do any GPM configuration ...
Sorry, I misunderstood your question. ie: I thought the trackpad was not working at all.
I don't use GPM.
But from what I gather, it does need a bit of configuration to get it to work, albeit with varied results.
HTH.
Best,
A.
Hello:
... anyone have this working?
Yes, I don't like it so I don't use it much, but it works.
This on an Asus 1000HE running Devuan Beowulf on a backported kernel:
~$ uname -a
Linux eee-dev 5.10.0-0.deb10.16-686-pae #1 SMP Debian 5.10.127-2-bpo10+1 (2022-07-28) i686 GNU/LinuxMy dmesg printout says this:
~$ sudo dmesg | grep -i serio1
3 --- snip ---
4 [ 6.186975] psmouse serio1: elantech: assuming hardware version 2 (with firmware version 0x020030)
5 [ 6.285227] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x02, 0x64.
6 [ 6.371781] psmouse serio1: elantech: Elan sample query result 00, 03, 64
7 [ 6.595103] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input2
8 --- snip ---Run sudo dmesg | grep -i synaptics, sudo dmesg | grep -i elantech and see what you get in the printout.
You may also want to consider posting (some?) information about the hardware and Devuan release you are using so that you can get more help.
Best,
A.
Hello:
Welcome to Dev1. 8^)
... a computer with a processor 2015 year. It has 16 GB of RAM and an AMD processor with two cores and four threads.
Your 2015 hardware is less than 10 years old.
I use a ca. 2007 Sun Ultra24 workstation with an Intel Core 2 Quad Q9550 processor and 8.0Gb RAM.
The system boots from a 120Gb/SATA3 SSD drive, has four different sized SAS HDDs SAS drives running from a ca. 2012 LSI SAS1068E SAS controller for storage and such and two ca. 2009 Nvidia Quadro FX580/512Mb cards driving a pair of ca. 2012 Samsung SyncMaster 940n and a ca. 2015 Dell P1914s displays.
There's also a ca. 2000 Adaptec 2940U/UW Pro PCI controller to run a ca. 1995 Umax S6-E SCSI-2 scanner and an external DDS SCSI tape drive should ever need to do such a thing.
As you can see, all of the hardware I am listing is quite dated/has been discontinued, some of it for many years now.
Yet it all works wonderfully well with Devuan Linux Daedalus.
As for the desktop, Mate or XFCE will do fine.
I think you should have no issues with your box.
Best,
A.
Hello:
... probably be right to remove my simple comments from this thread ...
I beg to differ, it would not be right.
There is absolutely no need for that, please don't remove/delete anything.
We were simply exchanging opinions in a civilised manner, albeit drifing off topic.
Nothing nothing more / nothing less.
At worse, agreeing to disagree. 8^)
I do apologise if my tone/wording made you think otherwise.
Best,
A.
Hello:
This thread is/was about the Daedalus upgrade breaking my Wine installation but is drifting in another direction.
Taking that into account and having been labelled as [solved], I'll say no more than this:
... Richard Harris' Pegasus Mail.
Like I wrote: not any Win based email client.
... described as "one of the web's oldest and most respected email clients".
https://en.wikipedia.org/wiki/Pegasus_Mail#cite_note-4
Do not rely on Wine to magically protect you ...
Who could think this was even a remote possibility?
I have would not ever rely on Wine to protect me from malware or anything else.
I protect my system from malware by, first and foremost, not running Wine as root.
ie: release notes and FAQs are an important part of the documentation.
... NEVER run Wine as root! Doing so gives Windows programs (and viruses) full access to your computer and every piece of media attached to it.
https://wiki.winehq.org/FAQ#Should_I_run_Wine_as_root?
In all the years (~30) I have used Pegasus Mail, I have never (ever) had a problem with malware coming in via email.
This in both MS and Linux based systems.
Of course, and it goes without saying, I have never opened suspicious email attachments.
Nor did Pegasus Mail automatically/suicidally open them for me. 8^)
WINE itself takes up about the same amount of memory...
Not something I took or ever needed to take into consideration.
As a Linux user, my need was to find a Linux based email client that could match what Pegasus Mail offered.
I was never able to find such a thing, much less in Thunderbird which I tried many years ago and found to be lacking.
For the reasons given in my previous post and in spite of it being MS based and not open source, I have continued to use it in every Linux distribution I have gone through, without any issues.
Like I said, YMMV.
Thank you for your input.
Best,
A.
Hello:
Installing the libcupsimage2 instantly solved the problem.
I see that the CUPS package is maintained by the 'Debian Printing Team'.
This issue with (what seems to be) a dependency problem with libcupsimage2 ...
Who would have to take care of it? ie: CUPS, Debian, Devuan?
My uneducated guess would be that package dependencies are something that involves the developers.
ie: the list of dependencies is generated somewhere along the line and added to the source code so that when the package is compiled and 'made' by maintainers, the binary will install them all with the proper versions.
ie: maintainers would not add dependencies on their own.
Is this correct?
If not, who would have to take care of the problem with libcupsimage2?
~$ aptitude why libcupsimage2
i cups Suggests foomatic-db-compressed-ppds | foomatic-db
p foomatic-db Recommends printer-driver-all
p printer-driver-all Recommends printer-driver-splix
p printer-driver-splix Depends libcupsimage2 (>= 1.4.0)
~$ From what I can make of the above aptitude printout, cups suggests foomatic-db / foomatic-db-compressed-ppds which in turn recommends printer-driver-all.
In turn, printer-driver-all recommends printer-driver-splix but this last package depends on libcupsimage2.
Now, my system does not have the suggested packages foomatic-db-compressed-ppds / foomatic-db installed because I do not install suggested packages because of their suggested nature.
ie: they are not dependencies.
But this being so ended screwing up my printing because the cups-filters package will fail if the libcupsimage2 is not installed.
It seems that cups-filters depends on libcupsimage2 being present to work properly.
But there is no mention of that here.
I'd appreciate some input on this.
Thanks in advance.
Best,
A.