install -- HP Laserjet Pro MFP M426fdw (03f0:5a2a)

Continuing to look to scan without lines. My CCD Epsons (V30, V370) both have faint vertical lines -- still great for documents, but unacceptable for photos. Buddy let me use this HP MFD, since its printer doesn't work anymore and that's all he used it for. All I need are scan functions. 2007 vintage. Unfortunately MFD HP's require installing the entire HP print kludge (CUPS and HPLIP) just to use the scanner.

hardware

Standard USB scanner cable and power cord.

$ lsusb 03f0:5a2a HP, Inc HP LaserJet MFP M426fdw

software - driver

I took out the V370 software to prevent conflicts and put in the HP bloatware.

# pacman -Rsn iscan-plugin-perfection-v370
Packages (4) iscan-2.30.4.2-3 iscan-data-1.39.2.1-1 libstdc++5-3.3.6-9 iscan-plugin-perfection-v370-2.30.4-1

Total Removed Size: 2.75 MiB

$ yay -Ss hp printer
aur/hpoj 0.91-21 (+91 0.00) (Out-of-date: 2020-07-28)
Hewlett-Packard OfficeJet, PSC, LaserJet, and PhotoSmart printer multi-function peripherals (MFPs) drivers
$ yay -S hpoj
Packages (13) foomatic-db-engine-4:20220521-1 hplip-1:3.22.10-3 perl-alien-build-2.77-1
perl-alien-libxml2-0.19-1 perl-capture-tiny-0.48-6 perl-dbi-1.643-4
perl-ffi-checklib-0.31-2 perl-file-chdir-0.1011-4 perl-path-tiny-0.144-1
perl-xml-libxml-2.0208-1 perl-xml-namespacesupport-1.12-5 perl-xml-sax-1.02-1
perl-xml-sax-base-1.09-5

Total Download Size: 22.82 MiB
Total Installed Size: 38.80 MiB

software - printer

Use whatever lsusb provides, in this case 1 and 4. It should install with some Qt5 errors. This AUR version still runs on Qt5, when Qt6 is the current release.

$ hp-setup -i --auto 001:004
error: No module named 'PyQt5.QtCore'
error: Unable to load Qt4/Qt5 support. Is it installed?

error: No module named 'PyQt5.QtWidgets'

# pacman -S python-pyqt5

software - proprietary

1) uninstall the printer and fax using lpadmin (lookup its name in CUPS). 2) reinstall it again using hp-setup. This should work b/c you've now got all the Qt in place. After hp-setup, then 3) click the HP prompt to download their proprietary scanning file.

# lpadmin -x HP_LaserJet_MFP_M426fdw
# lpadmin -x HP_LaserJet_MFP_M426fdw_fax
$ hp-setup -i --auto 001:004

It's possible we can get a list of the files at Alternatively go HP website, which will auto-detect the OS from the browser of course. SMH. Anyway, just select the model, in this case

...which will simply bounce to the HPLIP. This is their goal. And now they don't have HPLIP in the form of an unzippable file. Now its a script that has to download the file itself. Data gathering, see?

software - proprietary plugin

The first scan activation (eg with xsane), HP's national security features arise. There is no way to anonymously scan. HP downloads a proprietary file, otherwise the scanner will not operate. A watermark unavailable to the naked eye will be added to all scans and the installer does not reveal where it installed on the system. There's no getting around it, but this is how to navigate it, hopefully without breaking your pacman index, like any 3rd party installer will. It does not say where these files are.

...and then choose the option here.

colord - freedesktop.org severe device conflict (printer)

solution

NB: This takes the TN-630 toner cartridge.The TN-660 will work. If the entire drum is replaced, it's the DR-630.

Before describing the problem, here's a process for installing this (04f9:0092) Brother printer. This method is faster than the 3 days I spent understanding how colord had undermined the old reliable install method from a previous post. It's still an hour or two but compare that with salvaging configurations from older setups and losing days.

1. physically connect the printer and lsusb to verify detection.
2. pacman to install colord and cups. At the Brother site, download the RPM and xarchive to extract the PPD (and filter, if you want to go old skool).
3. if it won't archive the RPM, then be sure to install its software # pacman -S cpio.
4. new: $ yay -S brother-hll2315dw. This saves having to harvest, install and do permissions in several directories on executable scripts and data files. This is a 2 day time-saving driver.
5. can rename (or not rename) the PPD to anything "BrotherA.ppd" for example. Open it up and change the default size to 'letter' from 'A4' and/or any other such changes. Save, and put it into /usr/share/model/. Next, do either 6 or 7.
6. (CLI, more fun, less reliable)

   # lpadmin -p BrotherA -E -v [insert the USB URI from lpinfo -v] -m BrotherA.ppd

   The USB URI gained from lpinfo -v may be lengthy and will include a serial number.
7. (GUI, more reliable) Go into CUPS, http://localhost:631/, and "add printer"
   
8. inside the admin page, select "have PPD" and go to it in /usr/share/model to install the PPD from step 4 above.
9. still in the admin page, "maintenance" has the menu to set the device as the default printer.
10. # systemctl restart cups.service

---

the reason this conflict is a 3 day kludge

The solution is above, but here is the days-long struggle. We used to just install the printer with the CLI in about 10 minutes.

freedesktop: systemd and now colord

Freedesktop.org developed systemd of course. It's fairly comprehensive and complex, compared with the old Init.d flexibility of simple config files. Recently freedesktop began taking control of session color options too, and by device. Questionable. But in a horrible design decision, their colord daemon was given control not just of colors, but the DBus, apparently to make device queries/directives for color options. In practice, this means simple software conflicts about colors can lead to Dbus failures. Enter CUPS, attempting to set printer color profiles. Disaster.

CUPS circularity

It's a vicious circle. CUPS needs to write a PERL printer profile which contains (among many other settings) color settings. Meanwhile colord retains absolute control of color by controlling the DBus connection. When CUPS detects that colord has already created a device profile, it aborts its entire profile creation attempt, the one with all the settings for the printer. The result of no CUPS profile/filter is a half-installed printer. The printer doesn't print, and the error message "filter error" appears in the CUPS dashboard.

These errors can also be found in the error_log. If we attempt to install a printer, when colord is operating, we'll see the following:

$ cat /var/log/cups/error_log
W [16/Dec/2022:01:50:02 -0800] CreateProfile failed: org.freedesktop.ColorManager.AlreadyExists:profile id \'BrotherA-Gray..\' already exists

...and we can observe the details of the conflicting profile which colord had already installed...

$ colormgr get-devices
Object Path: /org/freedesktop/ColorManager/devices/cups_BrotherA
Owner: root
...
Colorspace: gray
Device ID: cups-BrotherA

colord's phony paths

It's hard to work with colord because it creates phony paths. The path above, /org/freedesktop/ColorManager/[etc], does not exist. No file is there. This is a "path" only in the sense of it being a line in an XML file or an ICC file. Colord knows how to evalute the line, but there's no file.

As for the XML files which contain the phony paths, these are apprently...

/usr/share/dbus-1/interfaces

... and two homes for the ICC files defining colors, for colord and ghostscript...

/usr/share/color/icc/colord
/usr/share/ghostscript/iccprofiles

order of operations circularity

When we install the printer, colord moves more quickly than CUPS. Colord detects the printer on the dbus and creates a device color profile faster than CUPS can write a CUPS filter. So, CUPS detects an already-made ICC colord color file, logs this color conflict as an error, and exits its entire filter creation. Accordingly we cannot fix the necessary filter later from some other CUPS process: it was never created and thus cannot be modified.

It seems we must either 1) remove colord, 2) configure colord not to create a profile for the printer, 3) modify CUPS to not to create its own color profile or to accept colord's profile, 4) modify the PPD (if possible) not to seek to create a color profile, or possibly to accept colord's profile, 5) place a filter in opt from a duplicate working setup. It might also require some combination. This is a kludge.

As a short preliminary to the 4th option, the simple act of commenting out a PPD's color settings doesn't stop the conflict.

1. remove colord

So let's pull colord, install the printer, then reinstall colord after CUPS has written a filter. It seems that we can do this: CUPS claims to only use colord ICC profiles "optionally".

# pacman -Rsn colord
checking dependencies...
:: cups optionally requires colord: for ICC color profile support

Packages (2) libgusb-0.4.2-1 colord-1.4.6-1

Total Removed Size: 8.49 MiB

:: Do you want to remove these packages? [Y/n]

...meaning CUPS should be able to install the printer without colord installed. Let's delete the error log, reinstall the printer and check for new errors...

# rm /var/log/cups/error_log
# lpadmin -p BrotherA -E -v usb:/dev/bus/usb/lp0 -m brother_HLL2315.ppd
lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.
$ cat /var/log/cups/error_log
cat: /var/log/cups/error_log: No such file or directory

No errors -- seems we're home free. Nope

colord/dbus integration overreach

The printer installed without errors, but attempts to print failed.

FindDeviceById failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files

Yes, CUPS apparently relied on color management from colord as "optional", however reliance on DBus is in no way optional for any application. And, since colord manages both colors and DBus connections to devices, if we take out color management, our printer loses DBus access. The printer cannot then communicate, eg print. A person with a similar problem seems to confirm this. Colord must apparently remain.

2. configure colord

I could find no colord configuration file. Using colormgr, we can delete a colord device profile. But... that's not the problem. The problem is when the color profile (ICC) is created -- which is conflicting with the printer installation. Again, the only time CUPS creates a print filter in /opt/ is its initial read of the PPD file.

3. configure CUPS

The /etc/cups folder has several configuration files.

• /etc/cups/printers.conf: don't edit when CUPS is running.
• /etc/cupsd.conf: I know this file is read during systemctl restart cups.service. I've changed log levels from Warn to Debug before and seen its effects inside /var/log/cups/error_log. It also has permissions. It does not look effective for device install conflicts.

4. modify the PPD

I could find no way to modify the PPD that solved the conflict and created a device. It *is* worthwile to go into the PPD and switch the defaults to "Letter" from "A4" if a person is in the US. Saves having to worry about updates to the device file later on which may disrupt other settings.

5. duplicate a filter

During install, the PPD wants to write a PERL filter to the directory specified in the wrapper shebang. This is the filter that is not written and which causes the print failure.

$ ls /opt/brother/Printers/HLL2315DW/cupswrapper
total 76
drwxr-xr-x 2 0 0 4096 May 24 2020 .
drwxr-xr-x 5 0 0 4096 May 24 2020 ..
-rw-r--r-- 1 0 0 18351 Apr 18 2020 Copying
-rw-r--r-- 1 0 0 15010 Apr 18 2020 brother-HLL2315DW-cups-en.ppd
-rwxr-xr-x 1 0 0 24436 Apr 18 2020 brother_lpdwrapper_HLL2315DW
-rwxr--r-- 1 0 0 7650 Apr 18 2020 paperconfigml1

We can see that the PPD copied itself over and that an executable (755) PERL script (brother_lpdwrapper_HLL2315DW) was written. "Copying" is a license but should also be copied. I put the entire HLL2315DW directory - as is - on a USB key and copied it to the non-printing system. I saved to my installation directory.

HL-L2315DW old-skool steps

Somewhere between my old post and the newest way at the top.

• install colord, cups, do all the download and xarchive of the PPD and filter from the Brother site, described in this post, repeated here in brief
• can rename (or not rename) the PPD to anything "BrotherA.ppd" for example, but the filter (must) keep its full given name. Its only content will be the shebang and the /opt location.
• Attempt to install the printer normally.

  # lpadmin -p BrotherA -E -v usb:/dev/bus/usb/lp0 -m brother2315.ppd

  But now the problem is the URI. This has become extremely finnicky with colord running the dbus. So instead of usb:/dev/[etc] above, use lpinfo -v to get a better USB descriptor. Copy and paste it into the command.
• install and unpack the entire HLL2315DW directory described above and set 755 permissions on appropriate files in the subdirectories lpd, inf, and cupswraper, as well as chown them to "0" (root). This is time consuming so for Arch users, the AUR package will handle this step

page size - chromium printing

Most federal and state tax instructions have, over the past 3 years, been transformed from PDF's into (unhelpful) web pages.

This means that citizen taxpayers must now themselves save instruction webpages to PDF. Once saved to PDF, citizens may again accomplish quick searches, print worksheets, or preserve the PDF as a record of the instructions they used that year.

Sounds quick, but not always: how the webpage is saved to PDF determines how it can be printed, and computer settings determine how the browser may save webpages. All together then, three additional failure possibilities have been added to tax preparation. Perhaps the idea is to encourage citizens to purchase parasitic 3rd party tax preparation.

chromium solution

Let's solve this browser PDF issue if we can, starting with Chromium. Chromium saves/converts webpages to PDF's in a default A4 paper size. But most US printers can only print to letter-size. Chromium, as installed, provides no method for changing the paper size of how a PDF is saved.

With a significant time investment, I was able to determine that Chromium relies upon the locale variable LC_PAPER for its PDF paper size setting. Now, locale variables are complicated multi-effect variables which one doesn't wish to risk modifying for a simple paper setting. I was unable to find any other way to proceed.

1a. in-session

The hack below has an immediate effect in Chromium, allowing one to select the type of paper on a drop-down, whereas there was previously no option to change paper.

# localectl set-locale LC_PAPER=en_US.UTF-8

1b. in-session

If the above doesn't work, it may be important to know that Chromium takes its settings from GTK2, variable GtkPaperSize, of which we would like to at least be able to change between letter and A4.

2. persistent configuration

In Arch, I found two files, depending on whether I wanted global settings or user settings. Both must be created and there's a skeleton in /etc/skel/.config/locale.conf

• user: ~/.config/locale.conf, which can be activated by logging out and then back in. However. whether or not Chromium bothers with user-level settings seems questionable.
• global: /etc/locale.conf.

good information on the subject.

• disable the LC_ALL and/or LC_CTYPE variables as they will override all subsequent individual variables such as paper size. But where? Arch prefers us to use locale-gen, which means uncommenting inside /etc/locale.gen. However, locale-gen sets monolithically: all variabless get the same value.

change what?

en_US

locale

Just as with the pernicious problem of pulseaudio, locale information is stored in several places and they need to be narrowed down to a single source. Further,they're exported to kernel as a group but we only want LC_PAPER to be corrected, otherwise we will have problems with fonts. Typically, they are held consistent across all variables.

/etc/locale /etc/profile.d/locale.sh
~/.config/locale.conf
/etc/environment (PAM only)
/

localectl

locale-gen

A worthless application. Causes problems familiar to the similarly abstracted GRUB configuration, once it began auto-generating. Locale-gen generates monolithic LC settings, not individual ones. No setting just one variable. Using # locale-gen after a user modifies /etc/locale.gen, it overwrites all the LC variables to one single language, so it's worthless attempting to just change paper size

Of particular note is users will be punished with A4 if they don't want to declare a locale, since declaring locales causes problems with various fonts..

[solved] Brother HL-L2315DW USB install ( 04f9:0092)

2022 update: due to evolving colord conflicts with CUPS color-setting, it's best to follow the instructions in my most recent post on this install. There's plenty of relevant older info below, but it probably depends on one's time and inclination whether to move onto the other post or start below.

---

Typical printing links and commands:

• http://localhost:631 CUPS admin page
• # lpadmin -x Brother remove a printer by its installed name, eg. "Brother"
• $ lpinfo -v get info on all connected printers
• # lpstat -o list all print jobs
• # cancel -a cancel all print jobs
• # systemctl [enable/disable/start/stop/restart] cups.service
• /var/log/cups/error_log CUPS error logs

---

The printers are priced $90 clearance (c. 2020) or sometimes $70 refurbished. Refurbished with 2-year warranty is best. Eg, "refurbished" from Wal-Mart ($70), with an Allstate 2 year plan ($6), costs less than a new model ($90) yet with deeper protections, such as free shipping for repairs.

Links: Openprinting.org database :: Brother L2315DW downloads page

---

solution

Go to the Brother L2315DW downloads page and select Linux -> RPM's. Note in the screenshot below that, even though they have three available downloads, both the PPD and LPD are contained in the single 0.2MB PPD download circled in red. The file is hll2315dwcupswrapper-3.2.1-1.i386.rpm.

Use xarchiver to open the RPM and extract its single folder, "opt" Inside opt, I continued drilling down into its subdirectories. I located both necessary files in /opt/brother/Printers/HLL2315DW/cupswrapper/. The CUPS PPD is named brother-HLL2315DW-cups-en.ppd, feel free to rename to [whatever].ppd. As for the LPD, it must retain its name, and you might want to save it (its a Perl script), but you could also just create the file, since its contents are just a single line (see further down).

owner and permission

Ownership will automatically become root b/c these can't be copied into their directories as user -- when you 'su'-up to copy them, they'll move over as owned by root. I have a working system with 755 on the filter but the instructions say it should 751.

• CUPS (PPD) 755 $ chmod 755 file
• LPD text file 751 $ chmod 751 file

locations

• CUPS (PPD) /usr/share/cups/model/foo.ppd
• LPD file /usr/lib/cups/filter/brother_lpdwrapper_HLL2315DW

LPD file

The ONLY way I could get to print was to use default options, which meant creating a custom brother_lpdwrapper_HLL2315DW file. Duplex printing -- an option physically available on the printer -- might be possible from some printer setting, but it cannot be accomplished in the CUPS software without errors that prevent printing altogether. Let the printer report its defaults to CUPS for successful printing. The file which makes CUPS adopt printer defaults is a single shebang line, with no line breaks (it is multiple line below due to column width word-wrapping). Don't forget permissions must be 751.

#! /opt/brother/Printers/HLL2315DW/cupswrapper/brother_lpdwrapper_HLL2315DW

PPD file

The PPD part is like years prior.

• assigned read/execute (5) permissions that have worked with prior PPD's... $ chmod 755 printer.ppd
• copied it to the Arch PPD directory... # cp printer.ppd /usr/share/cups/model/printer.ppd
• verify the USB-attached printer is detected $lsusb
• verify CUPS is running... # systemctl
• install the printer # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m printer.ppd
• alternatively, if having problems, you can use the bus ID's in lsusb and be more specific about the PPD locations as well (all one line):

  lpadmin -p Brother -E -v usb:/dev/bus/usb/lp0 -m printer.ppd

• check it in CUPS http://localhost:631, and verify or assign it default printer
• still in CUPS, verify the printer is awaiting print jobs and not paused
• print a test page
• copy the PPD to one's installation USB key so they needn't download it again for an OS/CUPS re-install

wifi install

Not worth it for a home-use stand-alone printer. It's too flaky. Eg, the next power outage, the WiFi router assigns the printer with a new DHCP address and one has to install the printer again.

somewhat common filter problem

There's a fail where the filter does not print over to the /opt directory.

$ ls/opt/brother/Printers': No such file or directory

The error log looks like this:

cat /var/log/cups/error_log W [14/Dec/2022:22:24:51 -0800] CreateProfile failed: org.freedesktop.ColorManager.AlreadyExists:profile id \'Brother-Gray..\' already exists

What has happened? The printer driver PPD attempted to create a settings file in /opt/brother/Printers/[model], but part of the PPD attempt included setting printer colors. The desktop ColorManager (ICC files) settings from free desktop (files are in /usr/share/dbus-1/interfaces) conflict with the PPD color. Due to the conflict, CUPS aborts creation of the printer configuration file in /opt and then fails to print based on lack of that filter.

These color manager related failures are based on colord ICC profiles for each device and are complex.

colormgr is the command line device for changing colord ICC files.

additional

There's been changes in CUPS, such as requiring the LPR translation file, and PPD's may disappear entirely at some point.

• cannot select Duplex and have it print. If I could, I'd want "DuplexNoTumble". Duplex with tumble inverts the top and bottom of the front/back of a page like for clipboard use. However, the printer only works in single page mode.
• after installation, it's efficient to set it as the default printer in case one has an application that sends to an LPR default, not to a printer name (eg. geeqie).
• Some failures require a CUPS restart...

  # systemctl restart cups.service

[solved] Xerox WorkCentre 5875 on network

This is an interesting case. The only PPD at the Xerox driver site seemed to be embedded in a Windows EXE file -- this may have been complicated to access via, say, Wine. However, I eventually Googled upon an Italian site which provided the generic 5875 PPD, xrx5875.ppd. This version is considered to have only basic functionality, and it was compressed into a ZIP. I was unable to find a full-feature PPD.

Pressing onward, 1) unzip the ZIP to extract the PPD, 2) put the PPD into /usr/share/cups/model, 3) walk to the Xerox and retrieve the machine's IP address from its printer menu (in this case, 192.168.1.101), then....

# cp xrx5875.ppd /usr/share/cups/model/xrx5875.ppd
# chmod 644 /usr/share/cups/model/xrx5875.ppd
# systemctl enable org.cups.cupsd.service
# systemctl start org.cups.cupsd.service
# lpadmin -p WorkCentre5875 -E -v socket://192.168.1.101 -m xrx5875.ppd

After this, if the 5875 is the main copy/printer a person uses at work, they might consider going back into CUPS (http://localhost:631) and setting the Xerox to be the default printer.

[solved] xsane detection of older or all-in-one HP printers

Sometimes you've got an old HP printer missing print heads or some such, but you still want to use it for scanning. Not all printers can be directly accessed using scanning software, such as SANE, unless the entire printer has been installed using printer software "drivers" (in Windows terms). This is often the case with HP's. To install HP printers, the standard "driver" package is HPLIP. HPLIP is available on Arch repos, however the Arch version of HPLIP doesn't include the specialized PPD's necessary for the printer. (See Section 3 below).

A recent encounter with a broken old HP OfficeJetPro L7590 was a case in point. I only needed this printer to scan. I turned the printer on, and connected the USB. My box detected the USB connection, but /etc/sane.d/dll.conf could not be modified for SANE to successfully communicate with the HP. The standard symptom of this existed: $ sane-find-scanner located the printer, but $ scanimage -L did not. So, good connection, but no scanning: I would have to install the printer driver. Here are the steps.

1. SANE

As just noted above, SANE was properly installed. That was simply:

# pacman -S xsane

Xsane pulls-in SANE software as dependencies, so no need to separately install SANE.

2. HPLIP

As also noted above, after we'd had SANE in, we'd connected everything (USB cable to scanner, powered on scanner) and attempted $ sane-find-scanner. This detected the printer, but $ scanimage -L did not. Since we were dealing with an HP, we needed the HP Linux printer driver set, HPLIP.

# pacman -S hplip

3. PPD

As noted at the outset, the Arch version of HPLIP does not include PPD's. PPD's are information files specific to each printer model. Both CUPS and HPLIP rely on them. Since the Arch version of HPLIP does not include them, the attempt to install an HP printer ($ hp-install -i) fails at the PPD step. Where to get the PPD for HP printers?

Go to the HP support website and download the tarball of the full version of HPLIP. Uncompress it. Enter the uncompressed folder and locate the "ppd" folder. Find the PPD for your model. After you unzip that PPD, put it anywhere you can easily remember, say your home folder. Now you are ready to complete the HPLIP printer driver installation.

4. Finally

Run $ sane-find-scanner again, and write down the USB number. In this case, let's say it was "002:003". Then we simply run...

$ hp-install -i 002:003

...and follow its prompts. At some point, the HP install dialog will prompt you for a path to the PPD. Provide the path to wherever you put it, eg. "/home/foo/hp_l500.ppd". The installation of the printer will finish normally¹.

After HPLIP and the proper PPD are present, and the scanner is connected, our last test is to $ scanimage -L . We should see the scanner:

$ scanimage -L
device `hpaio:/usb/Officejet_Pro_L7500?serial=MT97K251CP' is a Hewlett-Packard Officejet_Pro_L7500 all-in-one

Now we can fire-up Xsane and scan.

---

¹ If also needing to print with this printer, do a customary CUPS printer installation (after doing the steps above). Assuming the CUPS daemon is already running and permissions are correct, access the CUPS'administrative page at http://localhost:631 and add the printer to CUPS.

[solved] xsane fails to find WLAN Brother scanner

Over the holiday I visited a buddy who put me on his home WLAN, which included a Brother MFC-8840D printer. This printer also has scanning capacity. I added the printer via CUPS, and it printed. I hadn't network scanned previously, so I tried Xsane, hoping for the best. Xsane failed to detect the MFC-8840D. I was skeptical about going straight to port 6566, since forwarding runs the risk of compromising the firewall or causing other security problems, which are easy to do, apparently. So, what to do? Below, I'll describe my solution, and then some of the troubleshooting (6+ hours) that preceded it.

---

1. overview

Budget a half-hour to forty minutes to accomplish the connection if you already know the steps. Some of my learning steps: 1) SANE and CUPS are entirely different pathways; SANE does not require CUPS to be operating or enabled during scanning, at least on a Brother, 2) determine the correct backend software for your scanner and download (if necessary), 3) if using brscan-skey for special buttons (see below) start the necessary daemons with systemctl. I didn't need brscan-skey however, had I needed it, this step is important, 4) manually install the config file (after backend).

2. scanner backend

This took getting used to. USB scanners typically don't require drivers in Linux so for this WLAN scanner, I was thinking all the scanner would need was a network connection. Over a network, a driver is also needed. Brother has a site for LAN backends. Go there to determine which version you need for your Brother model. There two files:

• backend - for the older printer my buddy had it was "brscan". In the AUR, it says it's for USB scanners, but that's a misleading typo. Just download and install.
• scan key - pointless unless you want to use automated physical keys on the scanner such as "scan to fax", "scan to email", etc. Secondly, if you obtained "brscan" in step 1 above from the AUR, then scan-key is included and you don't need this step anyway.

Note: For those who want brscan-skey, documentation shows it's good to omit the "user" and "group" fields, and install the service file to /usr/lib/systemd/user/brscan-skey.service instead of /usr/lib/systemd/system/brscan-skey.service. That's so users can start (or enable) the brscan-skeydaemon as a regular user without sudo, eg:

$ systemctl --user start brscan-skey

If you don't do all those permission changes, you apparently will need the standard:

# systemctl start brscan-skey.service

As noted above, I didn't need brscan-skey, so I disabled it (I also stopped CUPS).

3. install the config file

The following application is supposed to do the installation:

# /usr/share/brother/sane/setupSaneScan -i

This didn't work for me. In other words, after this step, I looked for the scanner and was greeted with the following:

$ scanimage -L
bugchk_free(ptr=(nil))@brother_modelinf.c(467)
Aborted (core dumped)

Strace indicated scanimage failed when looking for "Brother.ini" at /usr/local/Brother/sane/Brsane.ini. The file does exist however, at /usr/share/brother/sane/Brsane.ini, so I created the directory in /usr/local , and copied the file to where it was looking.

# cp /usr/share/brother/sane/Brsane.ini /usr/local/Brother/sane/Brsane.ini

At this point, the program ran through but, as user, could not create a socket connection due to permissions (go figure).

$ scanimage -L
[bjnp] create_broadcast_socket: bind socket to local address failed - Cannot assign requested address

What's apparently happened here is setupSaneScan doesn't work very well. It might even be unnecessary to run. In my case, it certainly failed to write the file /usr/share/brother/sane/brsanenetdevice.cfg, or to install the scanner. This site has the few lines needed to nano into /usr/share/brother/sane/brsanenetdevice.cfg. For example:

# nano /usr/share/brother/sane/brsanenetdevice.cfg
DEVICE=MFC8840D , "MFC-8840D" , 0x4f9:0x160 , IP-ADDRESS=192.168.1.4

In summary:

• copy /usr/share/brother/sane/Brsane.ini to /usr/local/Brother/sane/Brsane.ini
• create and enter lines into /usr/share/brother/sane/brsanenetdevice.cfg

4. install the scanner driver

Following the hand-entries in /usr/share/brother/sane/brsanenetdevice.cfg, the printer/scanner still must be installed.

• unless desired, turn off CUPS and brscan-skey with systemctl

  # systemctl stop org.cups.cupsd.service
  # systemctl stop brscan-skey.service

• obtain the IP of the printer, you'll recognize it by its operating system

  # nmap -O 192.168.1.1/24 -oG

• obtain the exact model name for the printer from /usr/share/brother/sane/Brsane.ini
• let's say the printer IP was 192.168.1.4, and the model name was "MFC-8840D". Using these values, or the ones for your printer, enter /usr/share/brother/sane/brsaneconfig -a name="common name" model="model from INI" ip=xxx.xxx.xx.xx", eg,

  # /usr/share/brother/sane/brsaneconfig -a name=MFC8840D model=MFC-8840D ip=192.168.1.4

• verify this went through with "brsaneconfig -q", and "scanimage -L"

# /usr/share/brother/sane/brsaneconfig -q
Devices on network 0 MFC8840D MFC-8840D I:192.168.1.4
$ scanimage -L
device `brother:net1;dev0' is a Brother MFC-8840D MFC8840D

So, with scanimage -L showing detection, xsane can be initiated for scanning.

investigation leading to solution (6+ hrs)

This is not necessary to read; it's just crib notes (to save time in the future) of troubleshooting which eventually led to a solution.

To start with, I left the CUPS daemon on. I wasn't sure what might be necessary to detect the scanner. Further down here, I realize CUPS actually gets in the way of installation. Secondly, I read that scanner drivers expect "nobody" should be included in the "scanner" group. You can do this with, eg...

# usermod -a -G scanner nobody

... but I like to directly (not recommended) type into the /etc/group and /etc/passwd files: I added nobody to the scanner group in /etc/group. None of these changes had any effect, but YMMV. I then checked for scanners.

$ scanimage -L
[bjnp] create_broadcast_socket: bind socket to local address failed - Cannot assign requested address

Since BJNP is the Canon-specific CUPS back-end, and since my attempt to connect was to a Brother, the unsolicited appearance of BJNP, and causing scanimage to repeatedly fail, was... annoying.

A more powerful attempt to locate the fail...

# strace scanimage -L 2>&1 |tee bigfile.txt
# chown 500:500 bigfile.txt
$ grep socket bigfile.txt >bigfile2.txt

And here's the portion with the fail...

socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 132 setsockopt(132, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(132, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 bind(132, {sa_family=AF_INET6, sin6_port=htons(8612), inet_pton(AF_INET6, "fe80::b277:2173:31a6:e71", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=if_nametoindex("enp4s0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) fstat(2, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 write(2, "[bjnp] ", 7[bjnp] ) = 7 write(2, "create_broadcast_socket: bind so"..., 95create_broadcast_socket: bind socket to local address failed - Cannot assign requested address ) = 95 close(132)

Subroutine 132 is failing. The real fail was scanimage was demanding an IPV6 addresses, which of course is a too rigid restriction to place onto an older IPV4 scanner. Additionally, scanimage was soliciting via "enp4s0", the ethernet LAN NIC. This was a further problem because the LAN NIC was not connected, I was only connecting via my WiFi card. If scanimage demanded these to be present, nothing was going to work on the older Brother on a WAN.

To be sure I wasn't crazy, I nmap-ped the LAN ("nmap -O 192.168.1.1/24 -oG somefile.txt") , found the printer by the Brother OS, and made sure I was able to ping it successfully, using only the WiFi NIC, and leaving the LAN NIC disconnected. This was a success. But I never was able to eliminate the BJNP, IPV6, or LAN NIC failures with the CUPS daemon "on".

/etc/sane.d/saned.conf

Digging through some pages, it appeared the first effort should be to modify /etc/sane.d/saned.conf When I opened the file, all lines were commented, so I added two uncommented lines

localhost 192.168.1.0/24

/etc/saned.d/net.conf

According to http://wiki.archlinux.org/index.php/sane, the file /etc/sane.d/net.conf must be similarly modified.

localhost 192.168.1.0/24

to xinetd or not xinetd?

Xinetd is for allowing anyone on a LAN to use a hardwired (eg. by USB) scanner. My friend's Brother was sitting on a WLAN, independent of any system, so it should have been simpler. Still, after I installed xinetd (pacman), some tweaks were required. For example, in /etc/sane.d/saned.conf,these lines are at the bottom:

# NOTE: /etc/inetd.conf (or /etc/xinetd.conf) and # /etc/services must also be properly configured to start...

Well now. /etc/services is a listing of applications for each port, and sane-port was there at line 6566 for both UDP and TCP. This appeared OK. Next stop was /etc/xinetd.d/sane.

# cat /etc/xinetd.d/sane service sane-port { port = 6566 socket_type = stream wait = no user = nobody group = scanner server = /usr/bin/saned # disabled by default! disable = yes }

So there's nothing allowing LAN access. Using the site above, and this Slackware page, I changed the file by adding "tcp" capability (because WLAN):

# cat /etc/xinetd.d/sane service sane-port { port = 6566 socket_type = stream protocol = tcp wait = no user = nobody group = scanner server = /usr/bin/saned # disabled by default! disable = no }

check loopback

If you went the nuclear route and brought down your firewall during this, a good check to be sure it's re-established is to telnet into it. The connection should be refused.

telnet localhost [service port]

For example, xsane uses port 6566 so...

telnet localhost 6566

Try telnetting as both root and user; if groups are properly set-up, users should be able to telnet the port.

---

[solved] "disabled" printers in cups, "rendering complete" PT II

With an HP printer, if a person clicks "print", but left anything disconnected... they're going to get pissed. CUPS should simply print the job once the printer cable is reconnected. Yet instead of helpfully just printing later, CUPS is much more likely to invoke TWO horrible-to-undo problems... simultaneously.

1. CUPS invokes a "disabled" status for the printer and does not notify the user directly. When the printer is reconnected, the document does not print, but the CUPS icon will only (unhelpfully) indicate "rendering complete" with a green "pause" status for the printer.
2. A person thinks, "I just need to delete the document and try again now that the cable is connected". YES, you'll have to delete the document from the queue or the problem can't be fixed. (Use lpstat -o to get the job number and then cancel [job number] to eliminate it from the queue, or just cancel -a for all). NO, the problem is not yet fixed, and if you try to print again, you need to delete those attempts as well. I suggest cancel -a, then re-enable the printer using one of the two options below.
   

option 1 (5 minutes)

If a person is extremely fortunate, CUPS was installed with CUPS-specific permissions and group categories aligned. There are three layers to these, the first layer being correct permissions for loopback/localhost. Users can check this by attempting to access the CUPS browser-based administration page, running out of port 631, ie, http://localhost:631/. If that works, attempt to clear the disabled printer status as follows.

• Find your paused printer and click on it.
• Under the "maintenance" options for that printer, click on "resume". This is what re-enables the printer.
• Authenticate to activate changes. Typically the user is "root" and then root's password.

At this stage, printing should work again. If authentication failed, either skip to Option 2 below, or take the time* to untangle the group/member permissions (these are the second and third layers of CUPS configuration -- see "cups printer permissions" below) and then go back to the CUPS administration page, once complete.

*an entire afternoon

option 2 (15 minutes)

Remove and reinstall your printer, which hopefully is not an HP. Find your USB port for the printer (lsusb) and then, eg...

# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004

If not an HP printer, then you will likely never have this "disabled" printer problem, but if you do have to reinstall a non HP printer, then the easiest way I've found is, eg...

# lpadmin -x Brother # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd

summary

1. Cancel all print jobs. The fix might work without this, but it's unlikely. Find print job numbers using # lpstat -o and then # cancel [print number], one by one. You will see no change yet in the "rendering complete" status, but print jobs need to be cleared for the "rendering complete" status to subsequently be cleared.
2. "resume" the printer in the CUPS browser interface (if available), or remove and reinstall the printer using the terminal. Either way, "rendering complete" should disappear at this step.
3. Verify that CUPS changes have succeeded by attempting to print or, in a terminal, type "lpstat -p": the printer name should be there and have a status of "idle".

cups printer permissions (in progress)

Users will often only learn their CUPS configuration is misaligned when CUPS authentication fails at the final step of a long process that otherwise seemed to be successful. Any or all of the layers below can be the cause of the problem. Layer 1: loopback/localhost Sadly, CUPS is a network, not a standalone, print server. This means one must disable a percentage of their loopback protections if they want to use CUPS and the CUPS administration page. Outrageous, but true. Loopback is not dealt with on this page. Layer 2: groups

Layer 3: permissions Layer 4: /etc/cups/cups.conf (not always) Most times, nothing needs to be done to this file. When it does, the most typical adjustment involves.

[solved] (kinda) magical cups disappearance

Edit: I eventually rebooted after the CUPS reinstall and ran

# systemctl list-unit-files |grep cups

This time, and I'm not sure why, CUPS units appeared. One unit was org.cups.cupsd.service. Of course! A more complicated name for the service... how could I not guess this? So now, instead of the simpler...

# systemctl start cups

...we now have the impossible to remember...

# systemctl start org.cups.cupsd.service

...thanks a million, CUPS team. More keystrokes and slips of paper, perhaps that's the Linux legacy. At least this one is solved for now.

Edit 2: Evince not printing. Everything appears fine, but only blank pages result. Check it with a direct print. First command to get a list of the printer names, second command to directly print the file. In this case, suppose the name of the printer is "Foo", and the file to be printed is "somefile.pdf"...

# lpstat -p
# lp -d Foo somefile.pdf

If it prints this way, but not in Evince, it's got the f*cking bug.

---

I recently (12/5/2014) updated Arch and CUPS disappeared. It wasn't even there in the list of units. I ran...

# systemctl list-unit-files |grep -i cups
org.cups.cupsd.path

...which is just the CUPS scheduler, so no printers appeared. (The reason to use list-unit-files is it reveals any units, enabled or disabled). A check with

# pacman -Ss cups

showed cups was already installed. I reinstalled it, but still no appearance in the systemd list. Hmmm...

startup service

Then I recalled I'd made a custom startup service to remove the realtek module so it wouldn't continue sending errors. Could this be the problem?

# cat /etc/systemd/system/foostartup.service
[Unit]
Description=startup actions

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/sleep 10s
ExecStart=/usr/bin/rmmod ums_realtek

[Install]
WantedBy=multi-user.target

But no, there was nothing in there which would effect CUPS.

Brother HL-2275DW

Links: Arch instructions :: Brother Network Guide (PDF)

---

As always, handy commands:
LIST OF PENDING PRINT JOBS

# lpstat -o

CANCEL ALL PENDING PRINT JOBS

# cancel -a

Cancel -a sometimes doesn't work. In that case, one must individually cancel each named printjob, eg "cancel Brother-001", "cancel Brother-002", etc.

---

USB connection (10 minutes)

Connect a known-good printer using a USB cable. Turn on the printer. Next, go to this Arch page which lists the connection steps. Here is an abbreviated version, but note there are a few problems in 2015:

1. I have CUPS but a2ps is also needed: #pacman -S a2ps.
2. Reboot (or use systemctlto make sure CUPS daemon loads and is running. If users have good knowledge of systemctl command, check CUPS with systemclt or simply run any CUPS command and see what happens, eg...

   $ lpstat -p
   lpstat: Bad file descriptor
   

   ...indicates CUPS is not yet running.

   # systemctl list-unit-files |grep -i "cups"
   org.cups.cupsd.path enabled
   cups-browsed.service disabled
   org.cups.cups-lpd@.service static
   org.cups.cupsd.service enabled
   org.cups.cups-lpd.socket disabled
   org.cups.cupsd.socket enabled
   

   The lpd-socket is disabled, because I'm not on a network. It's not necessary. For normal stand-alone usage in this kludge, I only need cupsd.service. So I disable any lpd (network) services, browsed services, etc.

   # systemctl disable org.cups.cups-lpd@service
   # systemctl start org.cups.cupsd.service

   Now I can browse to the CUPS administration page (http://localhost:631). CUPS is running.
3. $ yaourt brother-hl2270dw
4. Navigate to CUPS: http://localhost:631.
5. Click the Administration tab then click the Add Printer button. The username is "root" and the password is the root password of the user's computer. Follow the steps.

USB connection [fail version (4 hrs)]

I went to openprinting.org, typically helpful with Brothers, but this time filled with gobbledy gook and an empty PPD. The order of installation was supposed to be the printer and then the cupswrapper.

1. Downloaded and unpacked the DEB's for the cupswrapper and the lprdriver. This was weird, since no "cupswrapper" is typically needed for a Brother, just a PPD.
2. Found the PPD in the kludge of unpacked folders, rooted up and copied the PPD as /usr/share/cups/model/brother.ppd, then chowned it to 0:0 and chmodded it to 755
3. # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd
4. restarted CUPS and attempted to print. At first it looked promising, but then it exited, unable to locate the file, "/usr/lib/cups/filter/brother_lpdwrapper_BrGenML1". That file was in the unpacked kludge and I copied it to /usr/lib/cups/filter/, and chowned it to 0:0. Restarted CUPS and tried another print but received "waiting for printer to become available" status message.
5. Verified the "Brother" entry generated during installation in /etc/cups/printers.conf looked normal. No obvious problems.
6. Forced a testprint... cat /etc/printcap |lp -d Brother. Not working, so lpadmin -x Brother

WiFi connection

Unattempted

[solved] yet another CUPS related failure -- interference with xsane.

We've all encountered the problem with Xsane where it fails to detect a properly attached USB scanner. Many times this is due to an error in permissions around the scanning group -- the scanner will only be detected as root. Here's a variant: a detection fail in both root or user modes due to CUPS. In my system, if CUPS is running, the scanner cannot be detected in user or root. No informative error message explaining this will be displayed.

There are many ways to determine if the CUPS daemon is running, most involving root. The fastest way is to remember "I just used the printer", but another way from user-space is:

$ lpstat
lpstat: Bad file descriptor

lpstat returns this message when CUPS is not running, and will return a blank line if CUPS is running.

Depending on one's distribution, disable CUPS with...

# systemctl stop cups

Once CUPS is deactivated, Xsane should again detect the scanner in user mode if permissions are properly set.

CUPS accesses stand-alone boxes through loopback privileges into localhost and the CUPS daemon runs under root. Looping-back has associated permission locks which apparently block USB detection, not sure. Anyway, turn CUPS off and scan normally.

---

Editorial: Since the majority of Linux users are stand-alone users with non-network printers, I consider it a conceit of CUPS developers not to have created a simple stand-alone variant which doesn't need the spaghetti or security issues of loopback privileges. When one considers that the CUPS code is 20 years mature, that its PPD's are actively updated by others, and that only a few lines of code are likely necessary to access USB ports, it becomes annoying. Currently, many CUPS installations require more manipulation of groups than most Linux users possess. More importantly are the security liabilities created by loopback access. Few advanced users, and probably no average users, possess the significant PAM, LDAP, port scrambling, ipchains, etc, knowledge to be certain they've closed less obvious loopback security holes. By the normal desire of Linux users to print, and the lack of any direct stand-alone solution, it's possible many of our systems are quietly compromised.

[solved] CUPS "rendering completed" errors PT I

Editorial: Stand alone systems with, say, a USB printer attached, are forced to behave like a network when printing with CUPS. This faux-network process on stand-alone systems is one of looping back ("loopback") to one's system ("localhost") -- occasionally a complicated process, depending on port set-up and permissions. Added to this are network security settings since one is opening one's ports "as if" on a network. Entire books are written about this -- it's way over the head of the average user to configure ipchains, LDAP, PAM, port scramblers, and so on properly. Long story short, conflicts are nearly certain on a simple stand-alone printing setup due to CUPS negligence of stand-alone users. I hope that someday, although it's already been 20 years, CUPS developers will humble themselves and address a direct printing solution (in addition to their excellent network solution). /end rant

---

At any rate, here is a recent fail. I attempted to print a document, but forgot to attach the printer first. CUPS often provides unhelpful or misleading error messages, but no error message was generated. Rather, CUPS continued to display normal status, with a message of "rendering completed". When the printer was attached, it never printed, and no additional documents could be printed. The message that rendering was completed continued to display.

Reinstall (10 minutes)

I verified there was still a PPD in /usr/share/cups/model, located the printer using $ lsusb (in my case 001:004). then...

# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004

Partway through installation is root authentication. The printer installs perfectly and is back to printing.

A tray icon is available as well, but it uses some RAM: /usr/bin/hp-devicesettings

SystemGroup (hours and hours)

CUPS makes a simple conceptual distinction between administrator and user. SystemGroup is a category of users with system-administrator CUPS privileges. Group refers to CUPS users with printing privileges. Although simple in concept and perhaps great on a network, CUPS permissions cause suffering for stand-alone Linux users. Linux systems already isolate administrator (root) and user (user) access. Adding an additional CUPS layer is both redundant and rife with permission overlap possibilities.

First, deal with Group -- add your username to group lp in the system's group administration file, /etc/group. This is a beneficial overlap between Linux and CUPS. CUPS simply looks to see if you're in lp, and you can print.

Now, the harder category, SystemGroup. At the top of /etc/cups/cups-files.conf are the default user settings (typically lp, as just noted). At the bottom of the file are the SystemGroup settings. These are finnicky.

# nano /etc/cups/cups-files.conf
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
User daemon
Group lp

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
SystemGroup sys root

# Do we allow file: device URIs other than to /dev/null? [No]
FileDevice Yes

You want the CUPS SystemGroup membership to be root, so it mirrors your Linux authentications for administration. But unlike the user (lp) level, you don't want a CUPS "SystemGroup" line in your Linux system. That is, don't add a "SystemGroup" group to /etc/group; lp -yes, SystemGroup - no. The latter is CUPS specific only. Confusing.

cups - hp office jet pro 8500a - 12 hours of fail in Lubuntu

Links: open printing.org   scroll down for tarball link   uninstall hplip   hp-setup options
Note this may also play HEAVILY into encountered problems with Ubuntu/Lubuntu printer addition: gnome keyring fiasco

---

So a year and a half ago, I added this printer in Minislack/Zenwalk. In 2013, I'm into Lubuntu, mostly for an updated set of libraries for the time being. I know Lubuntu (so far) uses usblp for usb printers so it should go OK. One thing, I'm expecting to compile my core applications as I've already noticed from Ubuntu/Lubuntu versions of avconv and ffmpeg, that they seem to be watered down. I suppose they have to be for such a popular distribution, so I keep my expectations for this distro to having a recent set of libraries for compiling. Back to our printer story... scroll down to Pt 3 for installation.

Pt 1 Groundwork

• HPLIP has apparently changed to where it must now be compiled to get the .ppd's out of the source? (Edit 2013-03-24 after unpacking the HPLIP source, the .ppd's are available, but in a compressed "gz"format, eg "hp-officejet_pro_8500_a910.ppd". Select and use as needed (chmod 644 the file) without proceeding further with HPLIP compilation. Save both "hpcups" and the "hpijs" versions, since hpcups is new, its rasterization is different, and YMMV. If one proceeds with the HPLIP installation, the gz'ed ppd's are also placed into /usr/share/ppd/HP
• Before doing so, use Synaptic to install developer versions of libjpeg, libcups, libusb1, and libsane to avoid ./configure fails. My final HPLIP configure line was $ ./configure --prefix=/usr --enable-lite-build --disable-network-build. I only needed scanning and printing, and via a USB connection.

Pt 2 errors

This make proceeded along for a while until exiting with

prnt/hpcups/CommonDefinitions.h:43:25: fatal error: cups/raster.h: No such file or directory

I installed apt-file (# apt-get apt-file find) and sought out the raster.h code. Sure enough, it was located:

$ apt-file search cups/raster.h
libcupsimage2-dev: /usr/include/cups/raster.h
lsb-build-base3: /usr/include/lsb3/cups/raster.h

So accordingly...

# apt-get install libcupsimage2-dev

...and back to the compiling. I have to hand it to whomever came up with the excellent idea of apt-file. The remainder, including # make install, appeared to go normally.

next errors

To check the installation...

$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Perhaps some library linking did not go well, $PATH was not updated, or files were installed into a non-standard location for the PATH or CUPS. The latter is what happened during a prior HPLIP install in 2011.

$ ls /usr/bin |grep hp
dvihp
hp-mkuri
php
php5
pitchplay

Not encouraging.

$ which hp-check
$

Not encouraging.

$ find -name hp-check
$

Not encouraging.

# service cups restart
cups stop/waiting
cups start/running, process 11411
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Not encouraging.

# reboot
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Not encouraging.

uninstalling HPLIP

Link: Uninstall instructions. From the installation directory...

# make uninstall
( cd '/usr/share/cups/drv/hp' && rm -f hpcups.drv )
( cd '/etc/cron.daily' && rm -f hplip_cron )
( cd '/usr/share/hal/fdi/preprobe/10osvendor' && rm -f 20-hplip-devices.fdi )
( cd '/usr/share/ppd/HP'...all ppds)
( cd '/etc/udev/rules.d' && rm -f 56-hpmud_support.rules 86-hpmud_plugin.rules 56-hpmud_add_printer.rules 55-hpmud.rules )
( cd '/usr/share/doc/...various docs.)
( cd '/usr/share/doc/hplip-3.13.3/styles' && rm -f css.css )
( cd '/usr/share/doc/hplip-3.13.3/images' && rm -f favicon.ico print.png toolbox_actions.png toolbox_fax.png toolbox_print_control.png toolbox_print_settings.png toolbox_status.png toolbox_supplies.png xsane.png )
( cd '/usr/share/doc/hplip-3.13.3' && rm -f COPYING copyright README_LIBJPG )
( cd '/usr/lib/cups/backend' && rm -f hp )
( cd '/usr/bin' && rm -f hp-mkuri )
( cd '/usr/lib/cups/filter' && rm -f hpcups )
( cd '/usr/lib/cups/filter' && rm -f hpcupsfax )
( cd '/etc/hp' && rm -f hplip.conf )

This is where HPLIP had been installed. I don't believe the HAL issue will be important, but we'll see. Additionally, from the uninstall, we have some idea what libraries were installed and why they might not have been located...

/bin/bash ./libtool --mode=uninstall rm -f usr/lib/libhpmud.la'
libtool: uninstall: rm -f /usr/lib/libhpmud.la /usr/lib/libhpmud.so.0.0.6 /usr/lib/libhpmud.so.0 /usr/lib/libhpmud.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/libhpip.la'
libtool: uninstall: rm -f /usr/lib/libhpip.la /usr/lib/libhpip.so.0.0.1 /usr/lib/libhpip.so.0 /usr/lib/libhpip.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/sane/libsane-hpaio.la'
libtool: uninstall: rm -f /usr/lib/sane/libsane-hpaio.la /usr/lib/sane/libsane-hpaio.so.1.0.0 /usr/lib/sane/libsane-hpaio.so.1 /usr/lib/sane/libsane-hpaio.so
( cd '/usr/lib/cups/filter' && rm -f pstotiff )

We'll see if we can get by without these libraries, eg, may not be able to do scanning. Still, simple printing, to start. A decent PPD should be sufficient.

Pt 3 Printer Installation (10 minute)

Note: "udevmonitor" is now "udevadm monitor".
1. Uncompress the ppd wherever you find it as a .ppd.gz from the HPLIP source (no need to compile HPLIP)
2. Copy it to where it can be found and chmod it.

# cp hp-officejet_pro_8500_a910.ppd /usr/share/cups/model/1sttry.ppd
# chmod 644 /usr/share/cups/model/1sttry.ppd

3. Verify you the user are in the groups lp and lpadmin, eg via "$ groups" or "# userconfig"
4. Verify the file /etc/cups/cupsd.conf has the line (or add it and restart CUPS):

FileDevice Yes

5. Run # udevadm monitor
6. Connect printer into USB, write-down dev address eg, usb:/dev/usb/lp0 that appears.
7. Be sure CUPS is running, eg # service cups restart
8. Add the printer to that USB address.

# lpadmin -p hp8500 -E -v usb:/dev/usb/lp0 -m 1sttry.ppd

9. Print, profit
10. If problems occur, see my post from 2011. You might have to uninstall the printer and try a different PPD or a different location for the PPD. The command to cancel current print jobs is # lprm -, the command to remove the printer (eg, named 'hp8500' above): # lpadmin -x hp8500. Also # lpstat -v is your friend.

One additional error

Uninstalling the HPLIP libraries earlier above did come back to bite. Everything installed properly, but when attempting to print, an error: "/usr/lib/cups/filter/hp/cups not available: No such file or directory". I then reinstalled HPLIP but installed PPD manually. Appeared all good, but print jobs gave error that printer was waiting to become available. Looked into /var/log/cups/error.log, and noted the following

The name org.freedesktop.ColorManager was not provided by any .service files

This appears to be a common error. By now, I also saw a lot others pissed off about the various security (non)interactions around loopback security and their distro. For example, this person's SuSE rant.

Incidentally, I noted that, in each case, a gnome keyring error appears, stopping communication with the printer. Apparently, a person has to hack their own laptop(!) for normal use if they use Ubuntu/Lubuntu. The roots of gnome-keyring persist into PAM, of course, and the LDAP abortion in their own system. To avoid contributing to my own productivity loss past the 12 hours already lost here, I eventually installed the HP5800a with "apt-get hplip". At some point, I will return to Slackware but, before doing so, I will attempt to euthanize gnome-keyring, PAM, and whatever other interconnected encryption garbage is in this distro when I have a few days to spare and see if a printer can be attached.

Again, adding a printer is typically a console job of 10 minutes, but I just gave up and let the immense Ubuntu RAM-killing daemon colluge do it for me after 12 lost hours. Google "cups pam" and you'll see why I gave up.

lpadmin

Lpadmin is part of CUPS and doesn't work when CUPS is not running.

GET A LIST OF PENDING PRINT JOBS BY INSTALLED PRINTER NAME

# lpstat

CANCEL ALL PENDING PRINT JOBS

# cancel -a

PRINT A TEST PAGE (eg, the man page for lpadmin)

# man lpadmin | lp -d HP8500

cups - hp office jet pro 8500a

Links: open printing.org   scroll down for tarball link   uninstall hplip   hp-setup options

---

Hey, I like printer installations the easy way, typically in about 10 minutes or less with lpadmin and CUPS from the command line. The 8500A, however, is an HP printer. HP documentation states that HP translation software (HPLIP), in addition to CUPS, is required for all HP printers operating with Linux. Nevertheless, many HP printers work without HPLIP, once the .ppd file can be installed. I attempted to install this HP8500A without HPLIP, and it worked. The description for the process is in Part 1 below. Parts 2 and 3 document the installation of the printer using HPLIP. Some steps in Parts 2 and 3 are repeats from Part 1.

Pt 1 What worked (w/out HP software)

short version

• Download the .ppd, even if it's inside a larger HPLIP release. Discard the remaining HPLIP software
• Put the .ppd into /usr/share/cups/model so lpadmin can locate it
• Add FileDevice Yes to /etc/cups/cupsd.conf if it's not already there and restart CUPS to read the change
• Add the user to group lp (or lpadmin -- check /etc/cups/cupsd.conf to verify the group), and be sure the system can see the printer in basic user mode, eg, the printer should be visible in $ lsusb
• Using ///dev/usb/lp0 seems to work better than usb:/dev/usb/lp0 in the installation line

long version

1. Download the latest HPLIP source tarball. Why? CUPS needs a .ppd (printer information) file for any printer it operates, HP or otherwise. However, the installation wizard is unnecessary. Only the source tarball is necessary. From the tarball, extract the relevant .ppd and discard the remaining 20MB. That is, after extracting the HP8500A ppd (hp-officejet_pro_8500_a910.ppd), discard the remaining HPLIP software.

Update 3/2013: The tarball appears to no longer be easily available. Substituted is the annoying "hplip-3.13.3.run (21.7 MB)", which most pages link to. I eventually located a tarball via this page, after scrolling down a bit.

2. During install, lpadmin searches for .ppd's in directory /usr/share/cups/model. Root up, copy the HP5800A .ppd to that directory (and chmod 644 the file) so it will be able to find it. Alternatively, in Ubuntu, these may be placed into /usr/share/ppd/cupsfilters.

3. In order to use lpadmin, activate CUPS...

# service start cups

...then fire-up udevmonitor, plug the printer in to the USB, note its /dev ID, and add the USB printer to that /dev address

# lpadmin -p hp8500 -E -v usb:/dev/usb/lp0 -m hp-officejet_pro_8500_a910.ppd

Or, if the printer is on a network, find its net address and then...

# lpadmin -p hp8500 -E -v socket://192.168.1.101/printer -m hp-officejet_pro_8500_a910.ppd

4. The above is all that is typically required. However, this printer was not detected by CUPS following installation. The HP printer apparently broadcasts in such a way that it does not allow detection without root. That is to say, if one runs $ lsusb , the HP is not found. The printer is found with # lsusb. This is a group permissions issue, so I ran $ groups and, sure enough, I was not a member of the lp group at the user level. Solution, uninstalled the printer...

# lpadmin -x HP8500A

...and added myself as a user to the lp group using the GUI invoked from

# userconfig

There's some file that can be sourced after that to update the system, but I just rebooted so save effort. I installed again and the printer was detected.

5. Attempting to print, however, the printer hung -- "processing" the file without printing it. I recalled I also had an installed USB Brother that had been working. A look at the list of the installed printers to see if there were differences revealed:

# lpstat -v
device for Brother: ///dev/usb/lp0
device for hp8500: usb://dev/usb/lp0

Note the Brother device shows a slightly different /dev URL than the HP. I uninstalled the HP again (lpadmin -x), and reinstalled using ///dev/usb/lp0. This led to an error

# lpadmin -p hp8500 -E -v ///dev/usb/lp0 -m hp8500a.ppd
lpadmin: File device URIs have been disabled! To enable, see the FileDevice directive in "/etc/cups/cupsd.conf".

Accordingly, opened the file /etc/cups/cupsd.conf
and added the line

FileDevice Yes

Restarted CUPS so the conf file would be read. Uninstalled the printer and installed it again

# lpadmin -p hp8500 -E -v ///dev/usb/lp0 -m hp8500a.ppd

Prints without problems.

Pt 2 What worked (HPLIP and other HP software)

First, proceed the first part of Part 3 below to make sure HPLIP is properly installed. This may be an extensive project requiring software updates and other bullsh*t.

Following HPLIP installation, you need to be certain the HP printer is detectable at the user level. Why? The program hp-install is necessary for installation and it must be run at the user level, not the root level. If hp-install cannot detect the printer, it cannot install it. But the HP printer broadcasts in such a way that it does not allow detection without group membership or root. That is to say, if one runs $ lsusb , the HP is not found, but it IS found with # lsusb. To correct the permission, run

# userconfig

to invoke the groups and users GUI. Add the user to the lp group and reboot. Check that the printer is detected at the user level:$ lsub If all is OK, note the USB address, which in this case was 002:003. Now you can install the printer:

$ hp-install -i --auto 002:003

Ater the installation, there is a short authentication step requiring root, but this is the final step. It should print.

Pt 3 What DIDN'T work (HPLIP and other HP software)

HPLIP v.3.11.7 goes inta...

Who knows? Some directories somewhere in my system. Did a standard configure, which dumped-out and told me I couldn't do a network build without SNMP installed. Annoying and unnecessarily prohibitive, since all an Ethernet printer needs is a TCP/IP stack, which was already there, and I wasn't going to rearrange my SNMP installation just for HPLIP requirements. But what could I do -- the HPLIP programmers had hard-coded the SNMP requirement? Ok then, decision made: forget networking. So, disabled network capability, then completed a standard make and # make-install. Again, no telling into which directories.

will HPLIP work?

Come on, you know it didn't. The first error looked like this

Filter "hpcups" for printer "HP8500A" not available: No such file or directory

A guy, ccin1492, on Linux Questions found that his similar problem was related to where HPLIP was putting its files:

It appears that HPLIP is putting stuff in one directory /usr/lib64/cups/filter, but CUPS is putting stuff in /usr/lib/cups/filter. So to fix my problem I linked the following files into /usr/lib/cups/filter so CUPS can see them.

hpcups*
hplipjs*
pstoraster*
pstopxl*

And so on. In my installation, it appeared that the HPLIP was putting stuff in to /usr/lib/cups/filter, but that's not where CUPS was looking. CUPS was looking for shiat where it usually does, in /usr/share/cups/model. So I made soft links to that directory but I still had no luck. Next thing, I ran hp-check. Here are the errors it located (leaving out the successes)

$ hp-check -t
Checking for dependency: CUPS DDK - CUPS driver development kit...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: libnetsnmp-devel - SNMP networking library development files...
error: NOT FOUND! This is a REQUIRED dependency. Please make sure that this dependency is installed before installing or running HPLIP.

Checking for dependency: PIL - Python Imaging Library (required for commandline scanning with hp-scan)...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: PolicyKit - Administrative policy framework...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: PyQt 4 DBus - DBus Support for PyQt4...
error: NOT FOUND! This is a REQUIRED/RUNTIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.

Checking for dependency: Reportlab - PDF library for Python...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

How wonderful to have HPLIP working for me, right?

removing HPLIP

Let's get this garbage out and try something else. To remove HPLIP, I first had to figure out where it was. Looking around (another half hour), the two main places appeared to be /usr/local/bin and /usr/local/share/hplip. Accordingly, I destroyed them.

# rm -r /usr/local/bin/hp*
# rm -r /usr/local/share/hplip
# rm -r /usr/local/share/cups/drv/*

I left hpcups, in case I needed that for the ppd I intended to retrieve from open printing.org. I knew some of the HP ppd's at OpenPrinting were standalone instead of HPLIP dependent. Digging into the OpenPrinting HP8500A documentation though, I was still eventually routed back to HPLIP. But I didn't give up. I figured that, if I could just edit an HP ppd enough to make it work with cupsd instead of requiring hpcups, I'd be set. And I would have been set, but no, inside the HP8500A ppd, it makes proprietary HP printer calls which CUPS does not independently recognize. Dang it, back to needing HPLIP or just getting a Brother printer (they all work like a charm with CUPS).

hplip again

By this point, I had wasted more than 12 man hours configuring the "free" HP8500A I had access to, when I could have instead bought a network compatible Brother HL-2270DW for $100. Really smart. Anyway, the first step to returning HPLIP was deleting my manual installation of the ppd

# lpadmin -x HP8500A

Next, recompiling. This time, I didn't bother with fax, scanner, copier, or network capability, hopefully to make it a simple HPLIP install for basic USB printing.

$ configure --disable-network-build --disable-hpijs-only-build --disable-qt4 --enable-qt3 --disable-fax-build

After installation, received errors

$ hp-setup
Traceback (most recent call last):
File "/usr/local/bin/hp-setup", line 45, in
from base import device, utils, tui, models, module
File "/usr/local/share/hplip/base/device.py", line 39, in
import status
File "/usr/local/share/hplip/base/status.py", line 45, in
import hpmudext
ImportError: No module named hpmudext

Look for hpmudext.

$ find -name hpmudext*
./usr/local/lib/python2.6/site-packages/hpmudext.so
./usr/local/lib/python2.6/site-packages/hpmudext.la

It's in there, so for some reason HPLIP can't find the directory or doesn't recognize the version. Check python version.

$ python -V
Python 2.6.1

Noting here, that Python 2.6.1 goes with HPLIP version 3.5.10-4 , but I have HPLIP version 3.11.7 compiled and installed. It might be advisable to remove the newer version of HPLIP I have installed and replace it by compiling and installing the older 3.5.10-4 version of HPLIP, but the printer (HP8500A) is a new model and there is no ppd support in the older 3.5 HPLIP. I'll need that newer HPLIP to interface with the printer. What to do? I could save the newer ppd and attempt to use it with the older HPLIP, I suppose. First lets make a soft link to where HPLIP is finding other modules and see if it can locate hpmudext.so there.

# ln -s /usr/local/lib/python2.6/site-packages/hpmudext.so /usr/lib/python2.6/hpmudext.so
# ln -s /usr/local/lib/python2.6/site-packages/hpmudext.la /usr/lib/python2.6/hpmudext.la

Better, but still errors.

$ hp-setup
warning: CUPSEXT could not be loaded. Please check HPLIP installation.

Look for cupsext.

$ find -name cupsext*
./usr/local/lib/python2.6/site-packages/cupsext.so
./usr/local/lib/python2.6/site-packages/cupsext.la

Appears same problem there as with hpmudext, so lets make softlinks for cupsext too.

# ln -s /usr/local/lib/python2.6/site-packages/cupsext.so /usr/lib/python2.6/cupsext.so
# ln -s /usr/local/lib/python2.6/site-packages/cupsext.la /usr/lib/python2.6/cupsext.la

Also made similar links to scanext and pcardext, to complete the four Python extension links. Now let's try to run hp-setup again.

$ hp-setup

HP Linux Imaging and Printing System (ver. 3.11.7)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-9 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

error: PyQt not installed. GUI not available. Exiting.
warning: Qt/PyQt 3 initialization failed.
error: hp-setup requires GUI support (try running with --qt4). Also, try using interactive (-i) mode.

Appears we have functionality using the softlink hack, but no GUI. We can live without a GUI: not into engineering a PyQt install. So let's attempt "interactive mode" for another half page printout of information.

$ hp-setup -i

HP Linux Imaging and Printing System (ver. 3.11.7)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-9 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

(Note: Defaults for each question are maked with a '*'. Press to accept the default.)


Using connection type: usb

error: No device selected/specified or that supports this functionality.

Have to read up on hp-setup command options apparently. Here's a good page for hp-setup commands that I'll also put above in the links. Meanwhile, let's go purchase a USB cable - getting close.

permissions

Along with its other problems, HPLIP brings a permission complication. The HP printer broadcasts in such a way that it does not allow detection without root. That is to say, if one runs $ lsusb , the HP is not found. The printer is found with # lsusb. But this means hp-install, which is run at the user level, cannot locate the printer and install it until this permission is addressed. I ran $ groups and noted I was not a member of the lp group.

# userconfig

Added the user to the lp group -- there's some file you can source after that to update it, but it's easier just to reboot. Following the reboot, the user level $ lsub found the printer at 002:003. At that point, I simply ran

$ hp-install -i --auto 002:003

This successfully added the printer, the only pause being to authenticate as root during the final step. I have a Brother also installed (CUPS only) and this is how the print options appeared when I selected "Print" in a document menu.

On the CUPS side, cupsd also apparently allowed HPLIP to write into the configuration file /etc/cups/printers.conf. The working configuration file (including the Brother):

# cat /etc/cups/printers.conf
Printer configuration file for CUPS v1.3.9
# Written by cupsd on 2011-09-10 15:16
<Printer Brother>
Info Brother
DeviceURI file:///dev/usb/lp0
State Idle
StateTime 1303970446
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
<Printer Officejet_Pro_8500_A910>
Info Automatically setup by HPLIP
Location
DeviceURI hp:/usb/Officejet_Pro_8500_A910?serial=3VN0DGP2XN
State Idle
StateTime 1315693016
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>