Messages

Another solution for anyone encountering this and wanting to prevent the warnings: disable this repository except when you are actively using it.  Given that the binary files are unlikely to ever change again, there really is no need to regularly check for updates after setting up working drivers, except possibly around the major updates of your Linux distro.  For context, there has not been an update to most driver packages in over 4 years, and it is entirely possible that there will never be another major change to most of them.

Thanks for the quick response!
But is it really necessary to leave the old key, since repository users will automatically update to the new keyring package by merely using the repository?

Yes, the old key has to remain for a while.  The key is used to sign the information about available packages, which is read before updates happen.  If the existing key on someone's system does not match the signature, the update to the new key will not be allowed automatically.  So I have to temporarily sign the package list with both keys, so that everyone can update without having to manually install the new key.  And many people do not run updates every day, so it can take a while before the large majority of users have installed the new key.

The reason revoking the old key does not help is that the warning is not actually about the key.  It is a warning about the signature in the package file, which still refers to the old key whether or not the key is trusted by your system.  I am not familiar enough with Sequioa (the new PGP system replacing GPG in Debian) to know if there is a way to suppress the warning during this transition.  If the package sqv is not installed (and gpg still is), there is no warning, although that is not an elegant solution or consistent with the direction Debian is moving in.

Thanks for the alert.  Apparently the key was one caught in a long-standing bug that is now being exposed as Debian changes over their default GPG tool.  I have added a new key that does not trigger the warning.  You may still see the warning for the existing key until I remove it, but I will allow a few months before doing so to give repository users time to update to the new keyring package.

Thank you for sharing this fix.

Update: there is no reason to keep the repository enabled on your system after installing the desired packages, as there are unlikely to be any future updates.  See this announcement:
https://www.bchemnet.com/suldr/forum/index.php?topic=406.0

Summary: starting in a year or two, the vast majority of Samsung-branded printers will no longer be able to print when using a version of Linux incorporating CUPS 3.0 or higher.

When CUPS 3.0 is released, printer drivers will no longer function.  The only printing methods supported by CUPS will be driverless options listed here:
https://openprinting.github.io/driverless/

Most Samsung printers do not support any of these options (although some later models do apparently work with IPP, possibly with a reduced feature set).  While the CUPS team has provided a limited mechanism for driver-mandatory printers to still function the 3.0 series, that mechanism is not applicable to the Samsung driver.  The CUPS team has effectively declared that these older printers are simply to not be supported.  I do not have any information to help you determine if your printer is an impacted one or not, other than to suggest that you try installing it using IPP instead of the driver (which can be done with existing CUPS versions) and see if it works.

As of May 2024, the planned release of CUPS 3.0 is "mid-2025".  It has been pushed back several times already, so it may be later.  And your particular distro may not incorporate CUPS 3.0 until significantly later still.  But once 3.0 is on your system, the Samsung (or HP version) drivers will cease to function.

Note that all the packages will still be installable, as I have no plan to make them explicitly conflict with CUPS 3.0, and I will continue to provide the Samsung installers as well.  There are two reasons for that: (1) the scanning functions of the drivers will still likely be useful to some people even when the printing drivers do not work, and (2) I do not want to cripple any possibility of a future work-around that allows these drivers to continue working, though I view that as extremely unlikely.

Use of this repository has slowly been declining since Samsung sold off their printer business, and HP sold only a couple of models that used the same driver system.  I anticipate a significantly greater rate of decline over the next few years, but I intend to leave this resource in place as long as there are a significant number of people apparently benefitting from its availability.

At this time, I do not anticipate any future updates to the packages or content.  Therefore, there is no reason to leave the repository enabled on computers once the desired packages have been installed.

There have been previous reports that this behavior sometimes happens with the automatically installed/detected printer.  You can try deleting the installed printer and then adding it again manually.

If that does not help, apparently certain models also benefit from the following to address what might be a name coding error for certain printers:

Code Select Expand

cd /usr/lib/cups/filter/
sudo ln -s rastertospl rastertosplc

The 1.00.39hp driver might also work.

The three approaches can tried in combination as well.

You can try adding

Code Select Expand

deb http://deb.debian.org/debian bookworm main to your sources.  I am not familiar with what Raspbian provides directly, but it should be compatible with the main Debian repository ("universe").  Certainly that repository has the packages that are being reported missing.

Try without the amd64.  So either make sure all your sources are "armhf" rather than "amd64", or try

Code Select Expand

apt-get install suld-driver2-100.39hp:armhf

The "hp" version of the driver should work without any of the amd64 tricks.  If it does not, then you can try the amd64 version, in which case you probably need to make sure that you have amd64 in the sources for some of the raspbian respositories.

The raspbian server does not provide the "-updates", "-security", or "-backports" sections, which is why you are getting the errors.  The main "bookworm" lines are okay, though.  But to use that solution, you also need to enable multi-arch:amd64.  It is simpler to try this, which needs only the bchemnet repository:

Code Select Expand

apt-get install suld-driver2-1.00.39hp
The "hp" on the end is important to be able to pull the armhf version.

I have not tried that version myself (no appropriate hardware), but it will probably work to install the printer and scanner drivers.

Have you tried following the steps here to set up the repository:
https://www.bchemnet.com/suldr/
Then installing version 1.00.39hp?

Alternatively, another way is given here: https://www.bchemnet.com/suldr/forum/index.php?msg=1717.

The Xerox drivers appear to be equivalent to version 1.00.25, which means the ARM is probably armel rather than armhf and therefore useless to anyone trying to use this on a Raspberry Pi - which as far as I know is the only reason anyone is trying to run ARM drivers.

If you can verify that the ARM drivers in that download are instead armhf and therefore potentially useful, I can work on packaging them.

A driver that nominally works for arm64 is now avialable for experimenting through the repository, but it is untested.

Experimental packages for arm64 are now available.

Packages posted and some web content updated, with the caveat that I have done zero testing.

I have posted version 1.00.39hp.  These are the latest (I think) HP-released drivers based on the Samsung technology.  These are experimental and 100% untested with any Samsung-branded printer (as far as I know), but it appears they will probably work.

Perhaps most importantly, these also provide ARM64 (and MIPS64) support.  Again completely untested.

Feedback is welcome, but I make no promises anything will work, now or in the future.

Yes, it does look that way.  I will build packages in the near future for testing.  Unfortunately I no longer have access to any relevant hardware so cannot test myself.

Thanks for sharing the solution.  Your error log seems to have not have had anything obvious in it, but clearly the job was being lost somewhere.  Fortunately that sounds like it is no longer a problem.

I suggest trying this (all will require sudo/root):
1. edit in /etc/cups/cupsd.conf to change the "LogLevel" line to "debug" instead of "warn"
2. restart the cups service
3. see what you get in /var/log/cups/error_log after a job that disappears without printing

Then post the error log output, if you cannot make progress yourself from what it says.

Just a thought: have you tried a different USB cable?  Very occasionally a cable will start to fail and cause connect/disconnect cycles such as this.

Unfortunately I do not have any hardware I can use to provide further insight, but perhaps someone else does and will.

Thanks for sharing.  I have added a link on the main pages to this post as an alternative driver option.

Whichever driver version you are using, I first recommend trying a different one.  This printer is supported by a wide range of options, and that may solve the problem.

If not, this sounds like an issue with CUPS.  The latest versions of CUPS are much slower under some circumstances and with some printers (brand-independent), but I have not worked out when or why.

The forum has undergone a major upgrade.  If you run into technical issues that seem related, let me know.

You are welcome.  I am glad it helped to keep old hardware working.

There is no development on any part of this project.  The Qt interface development was actually discontinued 9 years ago, well before Samsung sold their printer business to HP in 2016.  HP has not shown any interest in developing the driver (the last true update was nearly 6 years ago), let alone reviving that interface.  And there is no practical way to get Qt4 working in the latest Debian-based distributions due to some severe security issues that were discovered after Qt4 development ended.

However, you should be able to use system-config-printer to set up the printer.

I think you have two options.  One is to follow this thread, but use one of the version 3.xx drivers that support that printer instead of the latest package:
https://www.bchemnet.com/suldr/forum/index.php?topic=386.0

The other option is to set the printer to be a "generic postscript" as the printer type.  I seem to recall that works okay with that model, although not quite as well as the dedicated driver.

I have no way of testing or improving this, but will pin the thread so it is easily discoverable.

This feature may just be lost now.  I never provided the Printer Settings utility because it was separate from the driver, and it seems that Samsung had pretty much dropped it before selling their business to HP.  HP has completely dropped everything except the latest driver, which never worked with that utility.  So neither HP or Samsung is providing the Printer Settings utility either.  It is possible that you may be able to find a copy of the utility somewhere on the web, but you will have to dig fairly deep to find it.

Presumably the Windows driver or software still provides some way to do this.  Other than that, I do not have any solution for you.

I cannot your answer you question about M_PDF, but perhaps someone else will respond.

That said, even a limited function script may be of interest, so I encourage you to share what you have.  You might want to do so in a new thread, though.

suld-driver2-1.00.39:i386 : Depends: libxml2:i386 but it is not going to be installed
                             Depends: libstdc++6:i386 but it is not going to be installed
                             Depends: libusb-0.1-4:i386 but it is not going to be installed
                             Depends: libcupsimage2:i386 but it is not going to be installed

Those are all standard Debian packages, so perhaps you do not have the Debian main repository enabled, or the equivalent for a different distribution?  It is the universe repository for Ubuntu and derivatives, but I'm not sure how Raspberry-specific distributions are configured.