NEW: hplip @3.11.5

[okmacports@…]

This replaces ticket #7201

This port of HPLIP provides scanner support of HP all-in-one (HPAIO) printers, particularly intended to be used with SANE. (Note that it works under the MacPorts versions of xsane and saned, not the OS X versions.)

The official project page is ​http://hplipopensource.com/. It's a project, funded by HP, that creates open-source drivers for HP's printers/scanners.

While the intent of this port is to provide scanning support (because CUPS already supports printing to HP all-in-one printers under OS X), the port also provides printing support, so your HPAIO printers may appear duplicated.

Known issues: HPLIP requires Python 2.6 and net-snmp 5.6.1, neither of which is the most current version.

[okmacports@…]

Usage notes:

• to use across a network, start saned with the -a option. Make sure you've edited saned.conf in /opt/local/etc/sane.d/ to allow access from local IP addresses (such as by uncommenting the line 192.168.0.1/29).
• the script automatically appends "hpaio" to the dll.conf file. This approach is now deprecated, because you'll need to re-add the line if you do a fresh install of HPLIP. Someday I'll fix the Portfile to use the preferred new method, which creates a dll.d subdirectory and stores additional files (like one containing just the line hpaio) there.
• I'm investigating the net-snmp problem. For now, my workaround is to activate net-snmp @5.6.1.1, copy all the libnet* files, then activate net-snmp @5.7 and copy back all the libnet* files. The problem is that version 5.7 renames the lib files 30, while HPLIP is expecting files named 25.
• as noted repeatedly at the SANE project, run saned behind a firewall and don't run it as root!
• make sure you activate the launchctl daemon and client items (client being the same user that runs saned) as noted in the installation log

[okmacports@…]

####################################################################
You will get the following error if you have not properly set up dbus: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

To repair this, you must launch the dbus daemon systemwide:

sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist

Then for EACH user who wants access, the user must launch the dbus agent:

launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist

############################################################################

[icaines77@…]

Cc Me!

[tristan.klocke@…]

Cc Me!

[tristan.klocke@…]

Cc Me!

[okmacports@…]

I just noticed that if you don't activate the dbus LaunchAgent as root, the remote (network access) xsane clients will ask for a password. On the server (that is, the machine with the scanner attached), you'll get an error in the system log indicating insufficient memory to run dbus. That seems right to me, as dbus should have root access.

In theory -- and I haven't tried this -- you should be able to create a saned user, and launch the dbus LaunchAgent as saned (and ditto for the saned LaunchAgent). That would require modifying the plist file that the Portfile creates, and I leave that as a project for the student. :)

[tristan.klocke@…]

build error on lion (10.7)

[tristan.klocke@…]

Doesnt build on Mac OS X Lion (10.7). The mainlog is in the attachment.

:info:build make: Leaving directory `/opt/local/var/macports/build/_Users_tristank_.macports_local_print_hplip/hplip/work/hplip-3.11.5'
:info:build shell command " cd "/opt/local/var/macports/build/_Users_tristank_.macports_local_print_hplip/hplip/work/hplip-3.11.5" && /usr/bin/make -j2 -w all " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for hplip): org.macports.activate org.macports.build org.macports.destroot org.macports.install

[okmacports@…]

Are you using cups 1.5? There appears to be an issue there:

​http://www.gossamer-threads.com/lists/gentoo/user/232805?do=post_view_threaded#232805

You can (a) try the patch listed there (it seems to work), (b) downgrade to cups 1.4, or (c) wait for a new HPLIP.

Let me know.

Replying to tristan.klocke@…:

Doesnt build on Mac OS X Lion (10.7). The mainlog is in the attachment.

:info:build make: Leaving directory `/opt/local/var/macports/build/_Users_tristank_.macports_local_print_hplip/hplip/work/hplip-3.11.5'
:info:build shell command " cd "/opt/local/var/macports/build/_Users_tristank_.macports_local_print_hplip/hplip/work/hplip-3.11.5" && /usr/bin/make -j2 -w all " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for hplip): org.macports.activate org.macports.build org.macports.destroot org.macports.install

[tristan.klocke@…]

Thanks for getting back this quick. Would love to try the patch but I dont know how? The other patchfiles end with cpp, this one with "patch". I'm no developer.

[okmacports@…]

No problem, I'll upload a new Portfile soon with it. I was hoping you could tell me if it works BEFORE I did that :)

[tristan.klocke@…]

Thanks. Right now it doesnt work and I'm using CUPS 1.5.

[okmacports@…]

OK, I've uploaded the latest Portfile. I have also updated the original because it hasn't yet been accepted in the official list, it seems.

[jmroot (Joshua Root)]

First of all:

% port lint    
--->  Verifying Portfile for hplip
Error: Missing required variable: homepage
Warning: Variant gui does not have a description
Warning: Maintainer email address should be obfuscated as johnfreed.com:okmacports
Warning: no license set
--->  1 errors and 3 warnings found.

Other comments on the portfile:

• Revision should start at 0 (this is the default value).
• configure.ldflags already contains the value that is being appended.
• -I flags should normally go in configure.cppflags, unless the build system ignores the CPPFLAGS variable. configure.cppflags contains -I${prefix}/include by default.
• The gui variant depends on a nonexistent port "PyQt". It also depends on py-readline and py-reportlab, which are for python 2.4, whereas the python_version variable and the dbus-python27 dependency from earlier indicate that 2.7 is intended to be used. Using /usr/bin/env pythonw in the scripts is also incorrect as the first pythonw in the user's PATH has no guarantee of being the one in which the dependencies are installed.
• You can pass multiple files to a single reinplace call.
• Editing config files isn't something ports normally do, since not all users will want it. If it should happen in this case, it should probably happen in post-activate.
• Creating symlinks directly in the installed location in post-install is incorrect, as they won't be removed when the port is uninstalled. If you can't install to the correct location in the first place, create the symlinks in the destroot.

[okmacports@…]

Woohoo! Finally, a reply after nine months!

I'd be happy to devote some more time to this if you will actually accept this as part of macports. Otherwise, I am wasting my time. The current version worked as of nine months ago, when there apparently was, among other things, a "PyQt" port.

Replying to jmr@…:

First of all:

% port lint    
--->  Verifying Portfile for hplip
Error: Missing required variable: homepage
Warning: Variant gui does not have a description
Warning: Maintainer email address should be obfuscated as johnfreed.com:okmacports
Warning: no license set
--->  1 errors and 3 warnings found.

Other comments on the portfile:

• Revision should start at 0 (this is the default value).
• configure.ldflags already contains the value that is being appended.
• -I flags should normally go in configure.cppflags, unless the build system ignores the CPPFLAGS variable. configure.cppflags contains -I${prefix}/include by default.
• The gui variant depends on a nonexistent port "PyQt". It also depends on py-readline and py-reportlab, which are for python 2.4, whereas the python_version variable and the dbus-python27 dependency from earlier indicate that 2.7 is intended to be used. Using /usr/bin/env pythonw in the scripts is also incorrect as the first pythonw in the user's PATH has no guarantee of being the one in which the dependencies are installed.
• You can pass multiple files to a single reinplace call.
• Editing config files isn't something ports normally do, since not all users will want it. If it should happen in this case, it should probably happen in post-activate.
• Creating symlinks directly in the installed location in post-install is incorrect, as they won't be removed when the port is uninstalled. If you can't install to the correct location in the first place, create the symlinks in the destroot.

[mf2k (Frank Schima)]

Replying to okmacports@…:

I'd be happy to devote some more time to this if you will actually accept this as part of macports. Otherwise, I am wasting my time. The current version worked as of nine months ago, when there apparently was, among other things, a "PyQt" port.

Sorry to nitpick, but there never was a "pyqt" port. It has always been py*-pyqt{3-4} to specify a version of python. E.g. py27-pyqt4. Ideally this port should have python variants to allow for different versions of python.

[okmacports@…]

I accept your nitpick and this raises additional issues. As I said, I would be happy to devote time to this port and even maintain it, but it strikes me that creating variants for every possible combination of Qt and Python is, well, counterproductive, especially if there is no indication whatsoever that even if I did the work it would be accepted.

Also, revision number does not start at 0 because there are people actually using this port, so using a revision of 0 would stomp on their current (working) version.

Replying to macsforever2000@…:

Replying to okmacports@…:

I'd be happy to devote some more time to this if you will actually accept this as part of macports. Otherwise, I am wasting my time. The current version worked as of nine months ago, when there apparently was, among other things, a "PyQt" port.

Sorry to nitpick, but there never was a "pyqt" port. It has always been py*-pyqt{3-4} to specify a version of python. E.g. py27-pyqt4. Ideally this port should have python variants to allow for different versions of python.

[mf2k (Frank Schima)]

Sorry, revisions for new ports always start at zero. We obviously cannot support local installs. Your local users can uninstall their local version and install the proper Macports one when it is in the repository. Then their revisions will be aligned with everyone else.

As for your other comment. There is only one version of Qt to support and that is Qt4. The py*-pyqt3 port(s) should probably be removed. You only need to support python26, python27 and maybe python32. Lots of other ports support multiple versions of python and it is very easy to do.

[icaines77@…]

I'm glad to see this port getting worked on.

I noticed a problem with the port when using the included hp-setup script to install a new printer: hp-setup failed trying to download and installed a required plugin for the printer. The problem seems to be that the installation script (which is included with the plugin) looks for hplip.conf in the hardcoded directory /etc/hp. Not sure if it would be acceptable to put a link to the real hplip.conf in /etc/hp?

(even after doing this I still wasn't able to get the printer working but I haven't been able to pin down the further problems)

[okmacports@…]

Sorry I hadn't seem comments 17 and 18. Coming back to this because I see that HP has released software for Mac that supports the 1300 and 1400 series PSC but not the 1310, sigh. I will try to redo this to conform to the remarks in comment 17. I will write directly to icaines77 and also see if this works under Mavericks.

It would be a big help if macsforever2000 could provide an example (just one, not "lots of others") of a port that supports python26, 27 and 32.

[mf2k (Frank Schima)]

xorg-libxcb

[raimue (Rainer Müller)]

Superseded by #42776.