Messages

Make sure your current terminal directory is the same as where you downloaded.  You might need to

Code Select Expand


cd ~/Downloads

or similar to depending on where your downloads are saved, before trying the dpkg command.

You need to install the suldr-keyring package first to set up the secure package system.  If you are unable to do so from the repository by explicitly specifying it, then download it from https://www.bchemnet.com/suldr/pool/debian/extra/su/suldr-keyring_2_all.deb and then

Code Select Expand


sudo dpkg -i suldr-keyring_2_all.deb


I have not worked with this particular printer, but I think the ppd explicitly depends on some of the Samsung binaries such as rastertospl.  So perhaps when you did this before, you also extracted those or had them installed from a previous attempt at setting up the driver.

It appears you do not have any of the packages from this repository installed, nor the driver using the Samsung installer.  You probably need to configure this repository and then install suld-driver2-1.00.39.

I am not sure why setting up the printer worked to select a driver that is not installed on your system, but that seems to be your situation.

Please post the output of the following two terminal commands:

Code Select Expand


apt list suld*

and

Code Select Expand


ls -l /usr/lib/cups/filter/raster*


Any idea what changed?

No.  Nothing in these packages has changed, unless you manually updated to a different driver version.  I suggest using

Code Select Expand


apt list --installed > ~/installedpackages.txt


on both your desktop and laptop, then using diff to identify what Ubuntu-provided packages may have been updated on one but not the other.

Is the issue fixed by reverting back to 1.00.29?  If not, my recommendation would be to completely uninstall all the packages and the printer, restart cups or reboot, and then re-install everything.

1.00.39 version doesn't work for me - it prints just completely black pages!

In the error log I can see:
D [13/Jul/2021:11:15:40 +0200] [Job 231] free(): invalid pointer
D [13/Jul/2021:11:15:40 +0200] [Job 231] PID 14518 (/usr/lib/cups/filter/rastertospl) crashed on signal 6.

The same issue is discussed here, but I didn't find a way how to fix it.
https://aur.archlinux.org/packages/samsung-unified-driver-common/

My interpretation of that thread is that solving the issue requires updating the driver, removing the existing printer installation, restarting (the system or just cupsd), and then adding the printer as a new printer.  So you might want to try that first (obviously you have done the first step).

So could you place 1.00.29 back into the repo, please? Thank you.

In the event you do not want to try the above sequence or it does not work, 1.00.29 should be available now if you refresh the repository listing.

Is driver2 version 1.00.29 deb package available for manual download anywhere?

I'm using it for my printer (SCX-3405W) now, so I'd like to have a chance to revert in case of any issues after upgrade to 1.00.39 version.

The deb for 1.00.29 is not currently available, but can be if there is a need.  So if you decide to upgrade to 1.00.39 and run into trouble, I can make it possible to revert back.

That said, there is no reason for you to do anything if 1.00.29 is working for you.  The fact that the 1.00.29 package is no longer available does not mean you must change to 1.00.39, or that there is any advantage to doing so.  I simplified the offerings because I did not perceive any dis-advantages - but for everyone with a working installation, leaving things as they are is perfectly fine.

Thank you for sharing.  I have made this sticky and linked to it from the web pages.

Note that the steps for modifying and overriding packages should not be necessary with the most recent update to the repository (eliminating most of the steps in the middle).  Also note that version 1.00.36 is no longer available and 1.00.39 should be used.

Minor update to a few packages to allow for installation on ARM systems (Raspberry Pi in particular) via emulation.

I have removed many packages that were of little or no use to anyone, based on multiple years of download data:
  * The "armel" packages that were never of much use (and whatever use they had is obseleted by the ability to emulate amd64 on ARM).
  * The Qt3 version of the Configurator and all associated old library files, which have been out of date for nearly a decade.
  * Driver versions 3.00.90, 4.00.35, and 4.00.36.  Use driver version 4.00.39 instead (or, if your printer is supported, 4.01.17 or driver2 1.00.39).
  * Driver2 versions 1.00.06, 1.00.27, 1.00.29, 1.00.35, and 1.00.36.  Use driver2 version 1.00.39 instead.
  * ppd-3 (was only required by driver2 1.00.06).

I have not created transitional packages of the eliminated versions, so users who have the old versions installed are free to continue using or to move to the later version.  However, it is no longer possible to install the versions listead above using the repository.  None of those versions are essential for any particular printer (as far as I know).  If for some reason you still need to do a fresh install of one of those versions, the installers from Samsung are still available for download.  You can also post to the forum and I will consider restoring a deleted package if there is a clear use case that requires it.

I did not remove driver version 3.00.37 because it still sees a surprisingly high use, but there really should not be any need for that version.  For a couple of printers, the limit is 3.00.65 (still available), and everyone else using 3.00.37 should really move to 4.00.39, 4.01.17, or driver2 1.00.39 if they support your printer.  I may eliminate it in a year or so.

See also the previous announcement about the limitations for the Qt4 version of the Configurator.  That version is not installable in any recent (mid-2020 or later) distro version, and insecure in any installation.  I expect I will remove those packages entirely in approximately 1 year.

This is done for the common & ppd packages.  (Based on my reading of Debian's package guidelines, adding the Multi-Arch line is not appropriate for the other "all" packages in this repository.  However, I do not think any of those packages are relevant for this purpose.)

Please let me know if it works for you without having to manually edit the packages.

You can find every Debian package ever released here:
https://snapshot.debian.org/

You would need to download the 2.2.12-2 packages for whichever cups* packages that you have installed, then dpkg -i *.deb.  Note that because 2.2.12 was never released for Debian 10 (it only briefly existed in unstable/testing), there may have been a dependency change that will cause problems.  If that occurs, you are probably better off downgrading to 2.2.10-3 using the same process, then pinning those packages so they do not update.

It appears that the Debian CUPS team backported a problematic change introduced in CUPS 2.2.11 to 2.2.10 (-4 and later).  You are running into the issue from this bug:
https://github.com/apple/cups/issues/5562

The bug is fixed in 2.2.12 and 2.3.x, but that particular fix was not backported by Debian to 2.2.10.  You can try opening a bug against the Debian package and see if the relevant committ can be backported.  Otherwise you will need to revert to an earlier snapshot of CUPS (2.2.10-3 or earlier) or manually update to 2.2.12.

The Linux driver cannot read printer messages.  It is indeed a Windows only feature.  I believe that all the printers can print out a status page, and that is the official alternative method, but obviously that does not work if the printer will not print.  It appears that HP is starting to release new printers based on the Samsung technology, but they have not made any meaningful updates to the driver.

I am also not sure what the logical next step is.  I suggest seeking help through the Ubuntu resources on printer detection issues.

I am just left with the suggestion of an issue in CUPS, either a bug or a configuration/permissions problem.  Until the detection issue is resolved, the driver aspect is irrelevant.  I am sorry that I cannot be of more assistance.

CUPS should at least recognize a printer is there, even if it has no idea what to do with it.  This sounds like the problem might be hardware (connection or printer) rather than a driver issue.  Or possibly some sort of bug in CUPS, if you can verify independently that the hardware works.

You should be able to manually designate the printer as M2026 when installing/configuring the printer.  Alternatively, you can try downloading the driver package for the 107 from HP, extracting out the files /uld/noarch/share/ppd/HP_Laser_10x_Series.ppd & /uld/noarch/share/ppd/cms/10xsc.cts, and copying those to /usr/share/ppd/suld/ & /usr/share/ppd/suld/cms/ respectively (assuming you have driver2 v1.00.39 from the repository installed first).  That might work to select the HP 107 directly.

I cannot vouch for the fact that M2026 is the model that 107 is based on, but it does appear that HP has released 4 printers based on the Samsung technology and re-using the last version of the Samsung driver.  But I think there may actually be some changes to the driver despite the apparent re-use of the version number.  I will look into this some more, and hopefully be able to package up a version of the driver specific for the new HP models.  But it will likely be 2 months before I have time to spend on this - sometime around the middle of November is when I next expect to have a free day due to work demands.

It is certainly worth trying an older version - in a fair number of cases, newer is not necessarily better with these drivers.

No problem.

Have you tried the direct download and manual install approach?

http://www.bchemnet.com/suldr/pool/debian/extra/su/suldr-keyring_2_all.deb
terminal: sudo dpkg -i suldr-keyring_2_all.deb
refresh repository (apt-get update or equivalent)

Usually I recommend the most recent driver version that works with a printer, but in this case it might be worth trying 4.00.35 or 3.00.90 in case this is an obscure bug introduced in 4.00.39.  If not, and if this only happens with pdf files, another option might be to use a tool such as pdf2ps to convert the pdf to postscript before printing.  If neither of those helps, it may be a bug in the way the new CUPS is interacting with the driver.  In that case, your best bet is probably to just print 1 page at a time.

The only change was to add an explicit dependency on libcupsimage2, which would have no effect on a Buster system because that package was already a dependency of CUPS (but that was changed in the version of CUPS in testing/unstable, hence the need for the explicit dependency).

So I would not expect that those suldr package updates would have had any effect on your system.  The exception might be if you made a change to a configuration file that was overwritten by the default file when the package updated.  If so, the likely culprit is either /etc/sane.d/xerox_smfp.conf or /etc/sane.d/smfp.conf.

If not that, were there any other packages updated this month?

python-wcnk has been removed from Debian as part of the gradual removal of all python2 code.  I do not know if there is something that can replace it for python3.

I can change the dependency, but as far as I know the script does not work with pypdf2.  If you find otherwise, let me know.  However, given that Debian (hence Ubuntu, etc.) are in the process of removing python2 entirely from the distribution, I am not going to make changes to encourage use of pypdf itself via pip, or other python2 libraries.  All dependencies for this script should be changed to the python3 versions if it is going to remove useful, which requires rewriting the relevant portions of the code.

The utilities are python scripts, so the packages are their own sources.  You can manually download the packages if needed:
https://www.bchemnet.com/suldr/pool/debian/extra/su/suld-scantopc_0.4.5-5_all.deb
https://www.bchemnet.com/suldr/pool/debian/extra/su/suld-scantopc-gui_0.4.5-3_all.deb

Some Samsung (and other manufacturer) printers routinely print "black" by using color ink, if the job is color but converted to grayscale.  Other than the postscript option, I do not think there is anything you can do to change that behavior.  The only justification for printing black this way is to drive up sales of color ink.

I do not believe this is possible with that printer.  Some printers have an option to force grayscale at the printer level (i.e., by changing a setting on the printer itself) but the CLP-510 does not.  So grayscale would have to set on each device that sends a job, because I am unaware of any software way to modify the job request that an individual user sends when that job comes from a separate device.

You could set up the printer as a grayscale generic postscript printer rather than as the CLP-510 model (i.e., not using the Samsung driver at all).  That would universally prevent color from being an option, but might impact print quality.

All driver packages have been updated to include a dependency on libcupsimage2, to reflect a change in CUPS package structure start with CUPS 2.3.1.  This should prevent (or fix) issues with the printers that rely on the raster component of CUPS.

For those still using the Configurator, note that Debian has removed qt4 libraries entirely, so the Configurator is not installable with Debian testing, the next Debian Stable, or the latest Ubuntu (or other distributions) that pull from Debian testing/unstable.  Because of a major security issue a couple of years ago in openssl, after qt4 development was discontinued, one of the essential qt4 libraries for the Configurator is no longer functional.  Therefore, there is no secure way to keep the Configurator installed with a new distribution, and I am officially declaring my support for the Configurator ended.  I am leaving the packages in place for a while longer, but they will eventually disappear, likely along with many packages that are being utilized less than once a month on average (some driver versions, most i386 packages, and all armel packages).  I expect more compatibility issues to arise as CUPS evolves and these drivers continue to age, so I will need to prune the packages down to only those receiving significant use to match the effort I can invest in keeping any packages working.

I appreciate the thought, but no.  I am content knowing that I can make the world a little better than it otherwise would be for some people.