As the title suggests I cannot print to a remote printer. I can print just fine with the same printer connected via USB cable.

I have an HP DeskJet 880C connected by USB cable to a particular computer running Devuan Jessie and CUPS 1.7.5. Then I try to set up remote printing from a laptop running BLFS 7.9 (and CUPS 2.1.3) using ipp. When I try printing from this laptop, the printer is apparently detected properly, nothing happens and the status reads "Sending data to printer." It never seems to time out. When I log into the web interface of the other computer to which the printer is connected, the status of the particular job reads "No pages were found." I must add that this identical setup works without issue on another laptop running BLFS 7.5, so I suspect something changed with the stack on BLFS 7.9.

This happens whether I use hpcups or Gutenprint. Does anyone else have this problem, and are there any workarounds? Thanks.

Have you checked all of the system logs on the print server for issues with either authentication or daemon/app erros? How about its firewall settings?

I have. The error log did not have anything that jumped out at me, at least not until I enabled the verbose logging - which is VERY verbose indeed. Then I can see that the filter "rastertohp" exited with status 1. Again this really doesn't explain what happened, but in reading up on some similar problems, there were some changes with ghostscript and poppler which this filter apparently uses.

Apparently, I can print using the USB cable with BLFS-7.9 because I am using the hplip filters, but am using the generic hpcups on the remote server. Whatever ghostscript is with BLFS-7.5 apparently produces usable output but the newer one does not. I have not yet tested using the hplip packages on Devuan because I'm keeping my server minimal, and hplip wants to pull in dbus and about 53 other packages that seem frivolous. I built hplip for BLFS-7.9 and disabled a bunch of options during the configure stage, and I built cups and all related printing things before dbus or any desktop environment, so I know it's possible. But building anything on the server (a small armv5 box) is going to take ages.

Troubleshooting the rastertohp error seems a bit out of my expertise, but if there are any suggestions I will surely give them a try.

Packages might "seem frivolous" and indeed, they are sometimes. But, unless you know exactly what functions they're providing, you cannot be sure of that. Perhaps you could build it as recommended, then rebuild it disabling one thing at a time until you see exactly what is causing the problem. Finally, packages and their dependencies change over time. Perhaps something didn't need dbus before but, what if it decided to drop the SUID from an executable and use Polkit instead?

Heck, I'm still using UDisks-2.6.5 because of what the merger of libblockdev did to its dependencies.