Messages

The repository is not a PPA.  I'm not sure if under Ubuntu-based systems if there is a separate process for adding PPAs vs other repositories; I know in the past Ubuntu has added an extra interface that is not actually part of Synaptic and that can sometimes modify the information entered for a repository in unexpected ways.  I suggest just adding the deb line directly to /etc/apt/sources.list, which should avoid anything happening when adding through the graphical interface.

Either extract the files from what you downloaded and run uld/install.sh or follow the instructions for the repository setup:
http://www.bchemnet.com/suldr/index.html

Have you tried the solution in this and the following posts? http://www.bchemnet.com/suldr/forum/index.php?topic=35.msg140#msg140

Announced today is that HP is purchasing Samsung's printer business.  The deal may take a year yet to close, assuming no regulatory hurdles.  Presumably after that there will start to be significant changes in the distribution of printer drivers.  Historically HP printers have been well-supported on Linux, so I would guess that within 2-3 years there will be no need for this repository for new printers based on Samsung technology.  I have no idea how long support will be provided for existing printers through current drivers, or for how much longer (if at all) the Unified Linxu Drivers will continue to be updated by Samsung/HP.

I have no plans to change anything here, but will watch this development with interest.  Even if HP drops support for some existing models of Samsung printers, I can continue to provide drivers through this website for some time, at least until the drivers start to develop incompatibility with the latest Linux distributions or interest in obtaining the drivers drops off.

See the official press release here:
http://h30261.www3.hp.com/news-and-events/news-library/2016/09-12-2016.aspx

It is not just a matter of downloading a package.  You need to have a way to completely reset your device and install a new operating system (Linux kernel and associated base packages based on armel).  You would have to separately look up if anyone has done this with your device, it is not always possible.  If/once you have changed the core parts, then you can proceed as usual through the repository.

When armhf was relatively new, I know it was possible to replace all armhf-compiled packages with armel ones and run devices that way, although apparently slower.  I don't have any direct experience, but my understanding from what I have seen is that most new devices require armhf software only and don't support the armel type.

So at best you would have to completely wipe everything and start over as armel with an empty device, and that may not work anyway.

The driver does not work with any modern ARM-based devices.  Samsung has simply not compiled the driver to work with them.  Armhf is not quite the same hardware as arm (or armel), and requires a separate package to be prepared.

Samsung has finally released printers that actually depend on this version, so I have released updated an updated ppd package to allow for their use.  The driver itself is still 1.00.36 because I don't see any point in uploading identical binaries as a new release.

Thanks for catching that.  I've uploaded a corrected package.

My guess is that you are encountering a variation of the issue of crossing network address space, because Ubuntu thinks it has an IP address in 10.0.2.xxx space but you are asking it to find the scanner in 192.168.1.xxx space.  See http://www.bchemnet.com/suldr/scanning.html#6, even though it applies to the older drivers it is possible that the network work-arounds may provide some clues.

It may also be an issue with the network setup in Virtualbox.  Even though the printer works, the scanner mode has always been more sensitive to network quirks.  You could try setting up port forwarding (if you are configured as NAT) or using bridged networking.  I don't know if either would help.

Ubuntu 12.04 also has a history of network problems with the Samsung drivers that are solved by using any other release.  You could try setting up a new virtual machine with a different release and checking to see if it works.

Unfortunately, I am out of ideas.  It's possible that the issue is with SANE, as it certainly seems to do some sort of initial detection.  But I can't think of anything else specific for you to try.

SANE_DEFAULT_DEVICE is an environment variable.  So to temporarily set it, use (on a terminal):
export SANE_DEFAULT_DEVICE=smfp:net;IPaddress

Where IPaddress is the actual address.

To set it for the whole session, you can stick it in a file read at login, such as ~/.xsessionrc, and just leave out the export command.  Then it will be set on each login.

Based on the success with the IP address so far, I suggest trying the approach described in question 11 of the scanning questions: http://www.bchemnet.com/suldr/scanning.html

Okay, I think I understand your problem.  The printer is being detected, in that the printer setup can find it, but then not when you go to actually print.  Correct me if this is a bad summary.

Assuming the above is true, then what may be happening is that printer discovery service (the "dnssd" part of the URI) is not working correctly during the print process.  You may be able to address this by setting the printer to a static IP address, then using an ipp uri with the IP address.  To set the static IP address, the simplest way is probably to use the control panel on the printer.  If you activate the menu, there is probably a "network" menu that displays the current IP address and allows setting of a static one.  You may need to consult the printer manual for additional details.  If you set the static IP to the current IP address, then try to add the printer again by IP address using ipp (or lpd) as the protocol, instead of allowing the automatic discovery, it may work more reliably.  You may have to manually select the SCX 472x series driver when setting up this way.

If that's not it, I'm not sure what to suggest.  It seems that the computer can find the printer and recognize the appropriate driver.  Possibly try disabling the firewall temporarily to see if that has an effect?

It's possible there was an issue with CUPS (my best guess), if the issue is resolved because of the update.

If not and it relates to installing using the Samsung installer instead of the packages, let me know and I will investigate to see if something critical is getting lost during package generation.

suld-driver2-1.00.35 replaces suld-driver-4.01.17, so you would still have a driver.  So allowing the replacement is okay.

The newer driver might also help with detection of your networked printer.  If not, you may need to provide the IP address or network name of your printer when adding it to get the detection to work.

Can you try to refresh your repository now and let me know if you see the previously missing packages?

It appears that issue is a recent, undocumented change in the way apt-ftparchive creates repository files.  Previously "all" had both been its own section and duplicated within the other architectures.  Now it is only doing one or the other, depending on the configuration, and only one method generates files that work with older apt versions.

First, please refresh your repository and check if you can see the suld-ppd-1, etc. packages that were missing before.

Second, then try to install suld-driver2-1.00.35 and see if it allows you to install.  This is the version I would recommend.

Please refresh and check now.

I don't know what's causing this, because I can't reproduce it.  Here is the solution:

1. Download the suld-driver-common-1 and suld-ppd-2 packages directly from http://www.bchemnet.com/suldr/pool/debian/extra/su/ .
2. Install them using "sudo dpkg -i" followed by the name of the files (one at a time), in a terminal in the folder containing the downloaded files.
3. Install your desired driver.

So far this issue only seems to be occuring with Ubuntu 14.04 and Linux Mint 17.x (based on Ubuntu 14.04).

Glad to help, hopefully you won't run into this again.

It sounds like you are missing all the "architecure:all" packages.  I don't know how one could even create such a situation, because I don't know of any way to exclude those.  And that doesn't make sense given that the keyring package installed, but I don't see any other common feature.  I certainly can't reproduce the problem you are having on my system.

What happens if you download the common or ppd package directly from http://www.bchemnet.com/suldr/pool/debian/extra/su/ and then use dpkg -i to install those?

When I have seen something like this before, and it isn't a cache issue, then it has been a dependency problem.  For some reason apt almost never indicates what the actual missing package is unless the dependency chain is very short.

Can you install suld-driver-common-1 and suld-ppd-2 individually?  If yes, then try suld-network-2, then suld-driver-4.01.17.  Only the driver package itself has several dependencies, so I bet the others will install, and then maybe you will get an accurate error for the driver.

Try an apt-get update.  Some new packages have recently been added, and so the information on  your system may be out of date.

If that doesn't work, it may be due to the an authentication problem related to the new suldr-keyring package.  Try installing that first, then the driver.

It seems that Ubuntu has blocked all unathenticated repositories, which means you can't even set up one up to make it authenticated.

To work around, download the keyring package directly:
http://www.bchemnet.com/suldr/pool/debian/extra/su/suldr-keyring_1_all.deb

Then install with sudo dpkg -i suldr-keyring_1_all.deb and refresh apt.  Everything should work then.

Do this:
1. Remove the repository.
2. sudo apt update
3. Add the repository.
4. sudo apt update
5. Install suldr-keyring.
6. sudo apt update

suldr.gpg is no longer the active key.  This should be a one-time error that is cleared after suldr-keyring is installed.

This is resolved, and the hard-coded configuration files now installed in /opt/.  It appears that only the latest versions of the driver have this hard-coded, so it only relatively recently became an issue.

This is fixed.  The repository is now signed by the old and new key with appropriate hash.  The old key will be dropped in a few months once the new key is installed on users' systems via the new keyring package.

If you are configuring the printer manually and selecting the M2020 series driver, you only have 1 driver installed if you only see one option for that printer.

You can be even more certain by uninstalling all SULDR components and then trying to set up the printer again, and seeing if it finds an appropriate driver.

It appears that the 2026 is identical to the 2020, and the same as the 2022 except with a slower processor and less RAM.  So I continue to assume the 2020 driver is correct.

That leads me to think that one of the following is true:
1. The printer RAM is too low.  I've seen this with other Samsung models from Linux, where a small amount of printer RAM made it impossible to print anything other than very simple documents.
2. Despite all appearances, the printer isn't really the same as the 2020, and there isn't a driver for it in Linux.
3. Something is wrong with your printer.  The way to test this would be try to print from a Windows or Mac machine using those drivers.  A virtual machine would probably work if you have one handy.
4. There is some minor issue in the way the driver is packaged, and you should install the driver using the direct Samsung installer instead of the packages.

If you can't do #3 and/or it doesn't help, and #4 doesn't help, then you probably will have to contact Samsung or consider an alternate printer.