Messages

Have you tried a newer driver, such as driver2-1.00.36?

I will look into this.  It probably won't be for a couple of weeks.

Thanks for sharing.  I will update the information for this printer.

Creating a proper package to maintain the key has been on my to-do list for a while, and will address this problem.

I will move it up in priority and get to it soon (maybe a week, maybe a month).

You do not need to manually launch the driver.  It will be invoked as needed after the printer is set up.

Samsung's license has no restrictions on use of the driver as long as the driver itself is not modified.

You should not need to add/remove any translation files in /var/lib/apt/lists/.  The necessary ones should be picked up automatically and the rest ignored.  You could try removing the three for suldr and seeing if they are automatically replaced to solve the connection problem.

I can't help with the smart panel.  I have never spent any time working with it because I never had a printer that supported it.  If you are installing one of the most recent (driver2) packages, it is reasonably safe to use the Samsung installer directly, especially if it improves features.

I think it is a configuration problem on your server, but I don't know why.  Another possibility is a bad cache of a route to bchemnet.com, which a server restart, network restart, and/or router restart may solve.

Nothing has changed about the server at my end, and I don't have any trouble connecting with apt.  It might relate to is the internationalization files, if the locale that you are using doesn't match something on the server.  What locale do you have set?

Have you tried resetting your network connection and/or restarting apt-cacher to see if forcing a fresh connection works?

I have been told the block is removed, so you should have access again.

I have not configured anything that would block this IP.  I have opened a ticket with my hosting company to see if they can resolve it.

You should contact Samsung and let them know this.  There seems to be enough interest for them to release an armhf driver, but I don't know if people are actually telling them.

In the meantime, I am not aware of any solution for that particular printer.  It does not seem to be supported by any of the alternate drivers.  You might have some luck trying to use it as a "generic" printer, but without any printer-specific features.  The only other option I can think of is to create an amd64 or i386 guest as a virtual machine installation (I think Xen can handle this with an armhf host?), install the driver in the guest, and run the printer that way.  But I can't be sure it will work at all, and it may be a considerable amount of effort.

This would have to be reported to Samsung, because I only have the binary files.

But if 1.00.29 works, there probably is no reason to move to a new version.  New versions often break things that work with prior versions, which is why I provide so many different ones as packages.

The answer is that yes, it is supported, but only if you configure the system correctly from the very beginning.

The issue has to do with "soft float" (armel) vs. "hard float" (armhf).  The difference is whether floating-point calculations are done by the processor (hard float) or software (soft float).  The original ARM processors, including the one that the first Raspberry Pi was built on, did not have a hardware floating point processor, and so were all "armel".  This is what Samsung released a driver for.  All current Raspberry Pi devices (I believe) can in fact run as armhf, and that is the version that is provided if you download an installation image from the Raspberry Pi foundation.  You cannot use the Samsung driver this version, and based on the "armhf" in your output, that is the version you are using.

It should (I think, not tested by me) be possible to download and install an older armel Raspbian installation from Raspbian.org, and that will work with the printer driver - at least for the versions that Samsung released an ARM-compiled version.  The downside to using armel when armhf works is that some processes will be slower and more energy-intensive, because software calculations are not as efficient as hardware ones.

So if you want to use the Samsung driver, you would need to download and install a fresh image of Raspbian that is armel instead of armhf.  There may also be a loss of access to some packages in other respositories as a consequence, I don't know how many other things are currently offered as both armel and armhf.

If the latest driver version (driver2-1.00.36) does not help, then those features probably just don't work.  Samsung rarely updates the driver to solve problems like this.

Sorry, no.  I suggest reporting the issue to Samsung.

Sorry, Ubuntu reference is obviously inappropriate, force of habit from the source of most questions.  Under Debian, you should have a Printing utility installed.  If not, install system-config-printer to get it.  Then manage the printer that way.

Try adding the printer using the default Ubuntu printer tool instead of the Configurator.  You do have the Samsung driver selected (the "series" in the name is usually the clue), but the Configurator is installing it as an mfp device which doesn't always work with new distributions.  The default tool should automatically detect it on a different connection, but may default to a different driver unless you manually select the Samsung one.

How are you setting up the printer?  Are you relying on automatic detection or manually selecting the driver?  In either case, do you know which driver is being selected?  There are two non-Samsung drivers (splix & fooqpdl) that partially support this printer, so it is possible one of these is being used and causing the issue.

The Samsung installer for driver version 1.00.37 (December) is available on the Samsung Installer page, but I do not plan to package it.  The only differences from 1.00.36 are the ppd files for the M301x, M306x, C3010, and C3060 series printers, none of which appear to be actually for sale yet.  The driver itself is identical to 1.00.36 (and therefore also 1.00.35).

Driver version 1.00.36 is now available.  The only significant changes are updates to many ppd files and a couple of minor fixes to the packages, together which should probably address many of the problems some people have had with the 1.00.35 driver.

I mean that in the list with drivers shown I scroll down (a lot) and I have a driver named exactly SCX-4216F. This is in Ubuntu Mate 15.10. For me SCX-4x16 does not work - printer starts to print and then it does not finish, not even get the paper from the tray.

That driver is provided by splix, and is not part of the Samsung packages.  So to see it, you would also need to install printer-driver-splix.

The drivers are both 32 and 64 bit.  The packages that it reports as failing don't exist, though - the "common" and "ppd" packages do not have architecture-specific binary files, and so it should be trying to pull those as architecture "all".

I think there is a problem with the way your system is handling multiarch.  However, Ubuntu doesn't seem to configure it the same way as the base Debian system, so I can't offer you an immediate suggestion.  I am sure that it has to do the way dpkg and apt are configured, and if you look for resources about installing multiarch packages under 64 bit for Ubuntu you can probably find a solution.  The errors you are getting are not specific to these packages.

Ubuntu seems to have removed that option from apt-get.  I have no idea why.

Try sudo apt-get install suld-driver-4.01.17:i386

If that also doesn't work, then perhaps Ubuntu has added some alternate way to force 32-bit installations.  But you would have to look at Ubuntu resources for that, I have not kept up with their changes to the underlying Debian system.

You might be best off installing the x32 version in the x64 system if that seems to be working.  Using the repository, you can do this by entering the following in a terminal:
sudo dpkg --add-architecture i386
apt-get -a=i386 install suld-driver-4.01.17

Replace "suld-driver-4.01.17" with whatever version of the driver you actually want if you prefer a different one.  It is likely, but not definite, that installing the x32 version of the smartpanel from Samsung will also result in a working program after this.

The files are additional binaries required for specific printers, that are called as needed by the universal Samsung driver.  For the most part I don't know what they do, but the errors are not themselves a problem: they are in fact not normal driver files, so it does not surprise me that CUPS complains about them, and the errors do not indicate anything is wrong with them.

Unfortunately I have no alternate ideas of what might be wrong based on your description.

I suspect this is a problem with CUPS rather than the printer driver.  You might try investigating if there CUPS bugs about this one or report it through Launchpad.

Is it just the smartpanel that fails?  My first guess is that the 64-bit version is incorrectly compiled, which you won't be able to fix.  That type of error has happened before with the files Samsung distributes, and I have no experience working with the smartpanel.

Thanks for sharing and pointing out the linking issue.  I will post updated packages when I have a chance, probably in a week or so, that address the file location issues, and I will note your experiences with this printer.

Even if the file netdiscovery is now in /opt/Samsung/mfp/bin-folder, it can not be recognized (no command found).

/opt is probably not in your path, which is why netdiscovery would report no command found.  That is normal, as the command is called by other driver components by the full path.  You should be able to get netdiscovery output if you execute "/opt/Samsung/mfp/bin/netdiscovery" instead of just "netdiscovery".

Could this also be the reason to that the network scanner can not be found and the Samsung Unified Driver Configurator crashes when trying to add a printer or a scanner. (The printer installation worked with Ubuntu System Settings.)

I don't think so.  A crashing Configurator sounds like a separate problem.  But the Configurator is not necessary if you have the printer working with the system settings approach.

(Should there be a file smfpnetdiscovery in folder /usr/lib/cups/backend?)

No, that is only for the driver2 versions.  You could try one of those versions, though.

The CUPS could not either find any network printers.
How could I fix this problem?

I'm confused by your statement that no network printers are found, because you started off by saying the printer worked.  However, the simplest thing is to try a different printer driver version.

Thanks for sharing.  I will include this printer's information into the repository when I next do an update.