[Gutsy SRU request] Fax utility not adding files to job.

[Billy McCann]

HPLIP v. 2.7.7 does not add files to the fax task. When I press "Add Files" and then select and open the file, the file does not appear in the "Files to Fax" window.

TEST CASE:

Update: A dry test without having an actual HP MF device is possible. do

lpadmin -p fakefax -E -v hpfax:/net/HP_LaserJet_3390?ip=192.168.1.68 -m hpijs/HP/HP-Fax-hplip.ppd.gz
hp-sendfax

and follow the instructions below. Remove the fax queue with "lpadmin -x fakefax" afterwards.

For any fax-capable multi-function device start hp-sendfax and try to add a file to the list of files to be faxed. The tool will hang in an infinite loop. Faxing is not possible at all. Also files sent into a fax queue do not arrive in hp-sendfax' list.

[Till Kamppeter (till-kamppeter)]

Don, Dave, Raghu, the change of the architecture of HPLIP has broken the fax functionality completely. If i open hp-sendfax and try to add a plain text file to the list of documents to fax, the tool simply falls into an infinite loop ("Processing fax file" never disappears).

Can you please supply a patch with the fix as soon as possible, so that we can provide a fix for Gutsy next week? Thanks.

[Till Kamppeter (till-kamppeter)]

Billy McCann, as CUPS seems to be involved in converting files for faxes, can you try

sudo aa-complain cupsd

and see whether this solves your problem.

[Till Kamppeter (till-kamppeter)]

here we go, my error_log is below. It seems that a pointer with the path for the temporary file is NULL ("Unable to open Fax output file - (null)/hplipfax20071016171612.g3 for writing"). Perhaps I do not have some environment variable which one normally has with Red Hat/Fedora (I use Ubuntu).

In addition to fix this, I suggest also to do the following:

1. Let hp-sendfax observe the file conversion process, and report an error if the process dies, instead of falling into an infinite loop.

2. Check whether the system provides the "cupsfilter" command of CUPS 1.3.x. Then you can do the file conversion without involving CUPS, completely running as the calling user. This improves security a lot and keeps hp-sendfax with full control over the conversion process. But do not remove the old "send a CUPS job" method, to support the users of older CUPS versions. See "man cupsfilter" for more info.

----------
D [16/Oct/2007:17:16:12 +0100] [Job 7] foomatic-gswrapper: gs '-sstdout=%stderr'
 '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sDEVICE=ijs' '-sIjsServer=h
pijs' '-dDEVICEWIDTHPOINTS=595' '-dDEVICEHEIGHTPOINTS=842' '-r200x200' '-sIjsPar
ams=Quality:Quality=2,Quality:ColorMode=1,FaxEncoding=99' '-dIjsUseOutputFD' '-s
OutputFile=%stdout' '-'
D [16/Oct/2007:17:16:13 +0100] [Job 7]
D [16/Oct/2007:17:16:13 +0100] [Job 7] Closing renderer
D [16/Oct/2007:17:16:13 +0100] Discarding unused job-progress event...
D [16/Oct/2007:17:16:13 +0100] [Job 7] Unable to open Fax output file - (null)/hplipfax20071016171612.g3 for writing
D [16/Oct/2007:17:16:13 +0100] [Job 7] Error: /ioerror in --showpage--
D [16/Oct/2007:17:16:13 +0100] [Job 7] Operand stack:
D [16/Oct/2007:17:16:13 +0100] [Job 7] 1 true
D [16/Oct/2007:17:16:13 +0100] [Job 7] Execution stack:
D [16/Oct/2007:17:16:13 +0100] [Job 7] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1889 1 3 %oparray_pop 1888 1 3 %oparray_pop 1872 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1761 0 3 %oparray_pop --nostringval-- --nostringval--
D [16/Oct/2007:17:16:13 +0100] [Job 7] Dictionary stack:
D [16/Oct/2007:17:16:13 +0100] [Job 7] --dict:1158/1684(ro)(G)-- --dict:1/20(G:
)-- --dict:141/200(L)--
D [16/Oct/2007:17:16:13 +0100] [Job 7] Current allocation mode is local
D [16/Oct/2007:17:16:13 +0100] [Job 7] Last OS error: 32
D [16/Oct/2007:17:16:13 +0100] [Job 7] GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1
D [16/Oct/2007:17:16:13 +0100] [Job 7] renderer return value: 1
D [16/Oct/2007:17:16:13 +0100] [Job 7] renderer received signal: 1
D [16/Oct/2007:17:16:13 +0100] [Job 7] Process dying with "Possible error on renderer command line or PostScript error. Check options.", exit stat: 3
D [16/Oct/2007:17:16:13 +0100] [Job 7] error: Illegal seek (29)
D [16/Oct/2007:17:16:13 +0100] [Job 7] Possible error on renderer command line or PostScript error. Check options.
D [16/Oct/2007:...

[Till Kamppeter (till-kamppeter)]

The problem is for sure not an AppArmor problem, it occurs the same way after doing "sudo aa-complain cupsd".

If someone else has tried this, please get to the original state with

sudo aa-enforce cupsd

[Till Kamppeter (till-kamppeter)]

This is really strange, /usr/bin/hpijs is causing the error. See prnt/hpijs/hpijsfax.cpp. It tries to write the mentioned file into TMPDIR (environment variable set by CUPS according to error_log), but the getenv("TMPDIR") in line 300 of prnt/hpijs/hpijsfax.cpp returns NULL. Why does HPIJS write into a file? Is it not supposed to return its output to Ghostscript and the CUPS backend "hpfax" writing the file? What is hpfax good for then?

[Billy McCann (thebillywayne)]

>The problem is for sure not an AppArmor problem, it occurs the same way
>after doing "sudo aa-complain cupsd".

Same here. Not sure if it is related, but when I use the HP Toolbox to
check on the printer, printing a test page fails. But I can redirect stdout
to lpr and the printer works fine, just as it does from within the KDE
Kontrol Center.

[Till Kamppeter (till-kamppeter)]

Some additional info about the "cupsfilter" utility which I suggested to do file conversion for the hp-sendfax GUI tool. Unfortunately the tool does not (yet) support full filter chains including the printer driver specified in the PPD file ("*cupsFilter" line). See my feature request for CUPS: http://www.cups.org/str.php?L2562

[Till Kamppeter (till-kamppeter)]

Bug is fixed in HPLIP 2.7.10, so for Hardy the problem is solved. As it breaks an important feature a patch should be applied to fix HPLIP 2.7.7 in Gutsy.

[Till Kamppeter (till-kamppeter)]

Hardy packages for testing:

http://www.linux-foundation.org/~till/tmp/ubuntu/hardy/hplip/

[Till Kamppeter (till-kamppeter)]

Stable Release Update (SRU) Request -- for GUTSY

Impact of the bug

For all HP multi-function devices the functionality of sending documents from the PC as fax is supported by the HPLIP package. No other manufacturer offers this with free software.

Unfortunately, the version 2.7.7 of HPLIP which we ship with Gutsy has a bug in the fax part of the printer driver and therefore is not able to convert the input files into the format needed by the fax components of HP's multi-function devices. This makes the fax function of all multi-function devices from HP not working, and so a basic functionality gets lost in Ubuntu Gutsy

Fix of the bug

HP has fixed this problem in HPLIP 2.7.10 and comparing the source code showed that only a small fix in one source file is needed. The fixed packages which I am proposing here has a patch added to apply exactly this fix.

The debdiff

https://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/hplip_2.7.7.dfsg.1-0ubuntu5_2.7.7.dfsg.1-0ubuntu5.1.debdiff

shows the changes which only affect this one file of the fax part of the printer driver hpijs. What has changed is only the handling of temporary files. I have tested it with both HPLIP 2.7.7 and 2.7.10 and it works as expected. There are also no CUPS/AppArmor problems with the new handling of temporary files (I did "sudo aa-enforce cupsd" before testing).

Patch on the current stable release:

https://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/hplip_2.7.7.dfsg.1-0ubuntu5_2.7.7.dfsg.1-0ubuntu5.1.debdiff

Source packages are here:

https://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/

Everyone who is suffering this problem please test and report here. Thanks.

[Till Kamppeter (till-kamppeter)]

hplip (2.7.10-0ubuntu1) hardy; urgency=low

  * New upstream release
     o hp-setup capable of loading non-free driver extensions from the
       internet (usually from OpenPrinting)
     o hp-sendfax problem of not being able add files fixed upstream
       (LP: #153152)
     o New models supported: HP Officejet Pro K8600, Photosmart C4380 Series,
       LaserJet 1018, 1020, 1022, 1022n, 1022nw, Deskjet 550C
  * No modification of the upstream source tarball needed any more.
  * debian/patches/70_no_fail_on_bad_locales.dpatch: Removed, does not apply
    to current upstream source code any more.
  * debian/patches/90_subprocess_replacement.dpatch: Removed, fixed upstream.
  * debian/control: Let hpijs depend on hplip (LP: #149511).

 -- Till Kamppeter <email address hidden> Sat, 27 Oct 2007 14:34:49 +0100

[Martin Pitt (pitti)]

Accepted into gutsy-proposed, please test.

[Till Kamppeter (till-kamppeter)]

I have a suggesstion for improving this SRU:

We can fix bug 149511 for Gutsy with the same SRU, if we only add ", hplip (>= ${hplip:binary:Version})" to the end of the "Depends:" line of the hpijs package section in debian/control. WDYT?

[Martin Pitt (pitti)]

Till, bug 149511 does not stike me as very important, since *-desktop packages do depend on hplip, so it is installed by default. However, I don't object to sneaking in the dependency on the next SRU. Let's discuss it on that bug, though,

[Till Kamppeter (till-kamppeter)]

pitti, the problem is that the seeds only recommend hplip but do not require it. So hplip gets pulled in on live CD build or on Ubiquity or alternate installation. However, the user can uninstall hplip without breaking the dependencies of the installed *-desktop mea package. As hpijs really REQUIRES the libs which come with the hplip package hpijs MUST require hplip to be consistent. So please sneak into the SRU that hpijs requires hplip, as I have implemented in the Hardy package. This makes the next auto update of Gutsy installing hplip in the case where the user has manually uninstalled it earlier. No need to change the *-desktop package. Fix has to be done in Gutsy's hplip package.

[Martin Pitt (pitti)]

Till Kamppeter [2007-11-01 16:12 -0000]:
> MUST require hplip to be consistent. So please sneak into the SRU that
> hpijs requires hplip

Keep in mind that the current SRU is already uploaded, so it needs
another SRU (to be done in the other bug).

[Till Kamppeter (till-kamppeter)]

Billy, can you test the package in gutsy-proposed?

[Brian Murray (brian-murray)]

I have been unable to verify this fix on 2 Gutsy systems. I tried to send a fax with hp-sendfax and watched the tool hang with both hplip versions 2.7.7.dfsg.1-0ubuntu5 and 2.7.7.dfsg.1-0ubuntu5.1. I tried to look at the debdiff to ensure I had the correct changes but unfortunately that is no longer available.

[Till Kamppeter (till-kamppeter)]

Sorry, I accidentally deleted the files when I prepared another SRU for HPLIP (bug 149511). I have re-uploaded them, now all links here should work again.

Note that the fix is in the binary package hpijs. So make sure that you have also updated this package to version 2.7.7.dfsg.1-0ubuntu5.1.

[Till Kamppeter (till-kamppeter)]

As the fix of bug 149511 is trivial (added one dependency to debian/control) I suggest to fix both SRUs at once. debdiff for both is here:

https://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/hplip_2.7.7.dfsg.1-0ubuntu5_2.7.7.dfsg.1-0ubuntu5.2.debdiff

[Till Kamppeter (till-kamppeter)]

Please check with

dpkg -p hpijs

whether you have the correct version of hpijs installed.

[Till Kamppeter (till-kamppeter)]

The proposed fix works only with Hardy, in Gutsy the fax file seems to get created with the fix, too but when the creation of the file has completed, hp-sendfax crashes, probably this is a second, independent upstream bug.

The output on the console is

--------------------------------------------------
till@laptoptill:~/ubuntu/hplip/hplip-2.7.7.dfsg.1$
HP Linux Imaging and Printing System (ver. 2.7.7)
PC Sendfax Utility ver. 7.0

Copyright (c) 2001-7 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.

HP Linux Imaging and Printing System (ver. 2.7.7)
Services and Status Daemon ver. 9.2

Copyright (c) 2001-7 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.

warning: Inrecognized URI: cups-pdf:/
Using device: hpfax:/net/HP_LaserJet_3390?ip=192.168.1.66

fatal error: :hp-sendfax
Traceback (most recent call last):
  File "/usr/share/hplip/ui/scrollfax.py", line 216, in PeriodicCheck
    {"username": self.username}, None)
  File "/usr/share/hplip/base/msg.py", line 150, in xmitMessage
    raise Error(ERROR_INTERNAL)
base.g.Error: ('Unknown internal error', 99)
--------------------------------------------------

Here another run in debug mode:

--------------------------------------------------
till@laptoptill:~/ubuntu/hplip/hplip-2.7.7.dfsg.1$ hp-sendfax -ldebug

HP Linux Imaging and Printing System (ver. 2.7.7)
PC Sendfax Utility ver. 7.0

Copyright (c) 2001-7 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.

hp-sendfax[18735]: debug: Startup: Trying to connect to hpssd on localhost:2207
hp-sendfax[18735]: debug: Cannot connect to hpssd. Launching...

HP Linux Imaging and Printing System (ver. 2.7.7)
Services and Status Daemon ver. 9.2

Copyright (c) 2001-7 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.

hp-sendfax[18735]: debug: Connected to hpssd on localhost:2207
hp-sendfax[18735]: debug: Using system locale: en_US.UTF-8
hp-sendfax[18735]: debug: Trying to load .qm file for en_US.UTF-8 locale.
hp-sendfax[18735]: debug: Name of .qm file: hplip_en_US.UTF-8.qm
hp-sendfax[18735]: debug: Using default 'C' locale
hp-sendfax[18735]: debug: [<cupsext.Printer object at 0x871eb88>, <cupsext.Printer object at 0x871e9d0>]
hp-sendfax[18735]: debug: hpfax:/net/HP_LaserJet_3390?ip=192.168.1.66
: Fax
hp-sendfax[18735]: debug: Cache miss: hp_laserjet_3390
hp-sendfax[18735]: debug: Reading file: /usr/share/hplip/data/models/models.dat
hp-sendfax[18735]: debug: Searching for section [hp_laserjet_3390] in file /usr/share/hplip/data/models/models.dat
hp-sendfax[18735]: debug: Found section [hp_laserjet_3390] in file /usr/share/h...

[Till Kamppeter (till-kamppeter)]

Dave, Raghu, Don, if you fix this problem, please provide a patch, so that we can fix the released HPLIP package. We cannot replace the package by a completely new version of HPLIP.

[cappycaffeine (msarnov)]

Don't know if this will help with 2.7.7, but I ran the following to configure 2.7.10 that fixes the problem with the faxing.

Scanning and printing work as well. This has been tested via a networked HP Photosmart c6180 All-In-One.

I have created a debian package of my 2.7.10 install with checkinstall. It conflicts with hpijs, but I am afraid to remove the hpijs package since removing it also removes
ubuntu-desktop (??)

Anyways, I installed with make install, and then built the checkinstall package on my system, so if you would like to use the 2.7.10 debian package, you will probably need to force the install to overwrite the common files with the hpijs package.

Here's the link: http://sarnov.dnsdojo.com/utilities/hplip_2.7.10-1_i386.deb

Good luck!!

BTW: I take no responsibility if this package borks your system.. You have been warned!! ;)

Cappy

[cappycaffeine (msarnov)]

Ugh.. forgot to include the configure command I used when compiling from the 2.7.10 source tarball.. Wife was talking to me at the same time I was typing this note!!

./configure --prefix=/usr --with-hpppdir=/usr/share/ppd/hpijs/HP

Bye!

[Aaron Albright (albrigha-deactivatedaccount)]

Is this still a problem?

Thanks!

Aaron

[Till Kamppeter (till-kamppeter)]

Your original patch solved one problem and so the fax tool got working in Hardy. Unfortunately, in Gutsy another bug, this time in the fax tool itself occured. See

https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/153152/comments/22

So for Gutsy we still need a fix to get faxing to work.

[cappycaffeine (msarnov)]

I found a similar problem. I had thought that I fouled up CUPS with all
the make installs, make uninstalls, make cleans, etc.. so I ended up
reinstalling CUPS via Synaptic and then all was good.

If you can reproduce the fix, then maybe we have something. I wonder if
there is a problem with the CUPS backend getting borked with the HPLIP
install.

What do you think? After I reinstalled CUPS I was able to successfully
add a PDF file to the fax queue and fax it out successfully.

Mark

On Wed, 2007-12-19 at 22:16 +0000, Till Kamppeter wrote:
> Your original patch solved one problem and so the fax tool got working
> in Hardy. Unfortunately, in Gutsy another bug, this time in the fax tool
> itself occured. See
>
> https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/153152/comments/22
>
> So for Gutsy we still need a fix to get faxing to work.
>

[Wart (wart-redhat-bugs)]

Description of problem:
Can't add a file to the hp-sendfax interface. It opens up a dialog that says
"Processing fax file..." and hangs forever.

Version-Release number of selected component (if applicable):
hplip-2.7.7-6.fc8.x86_64

How reproducible:
Always

Additional info:
This is the same bug reported on the hplip forums. The attached patch was
extracted from this report, and fixes the problem on my system:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/153152

[Wart (wart-redhat-bugs)]

Created attachment 290483
Patch to set correct fax temp directory

[Wart (wart-redhat-bugs)]

Using this patch results in a few selinux avc denials that can be fixed by
adding these policy rules:

files_manage_generic_tmp_dirs(hplip_t)
files_manage_generic_tmp_files(hplip_t)

[Martin Pitt (pitti)]

Till, what is the status of this for gutsy?

[Till Kamppeter (till-kamppeter)]

Dave, Raghu, Don, have you anything done on fixing fax support for Gutsy? See

https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/153152/comments/22

[Aaron Albright (albrigha-deactivatedaccount)]

We've tested hplip 2.8.2 on hardy with faxing and it seems to be working correctly. Is this still a problem in gutsy? I think this has been resolved, I'm going to close as fix released for hplip, however please re-open if it's still a problem.

A

[Martin Pitt (pitti)]

Unless someone confirms that the version in -proposed does not have any regressions and helps to fix at least something, I'll remove this SRU next week.

[Martin Pitt (pitti)]

11:38:35 INFO hplip 2.7.7.dfsg.1-0ubuntu5.1 in gutsy
11:38:35 INFO Removed-by: Martin Pitt
11:38:35 INFO Comment: dead SRU
11:38:35 INFO 50 packages successfully removed.

[Oli (oli-redhat-bugs)]

I am experiencing this bug also and would be happy to assist with any testing
if/as required - let me know what needs to be done...

[Oli Wade (olithered)]

This is still broken for me on Hardy (2.8.2-0ubuntu8). The "Processing fax file" dialog takes forever.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Oli (oli-redhat-bugs)]

This problem is also affecting RHEL 5.2 (hplip-1.6.7-4.1.el5_2.4).

Can the product be changed to that instead, so the bug can remain open?

[Bug (bug-redhat-bugs)]

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Tim (tim-redhat-bugs)]

Well, if HPLIP is eliminated from the problem, it must be foo2zjs.

[Tim (tim-redhat-bugs)]

Comment #7 was intended for another bug -- please ignore.

[Oli (oli-redhat-bugs)]

RHEL bug #475181 (though the underlying cause seems to be different).

[Oli (oli-redhat-bugs)]

I've tried this now on Fedora 10 (hplip-2.8.12-6.fc10.x86_64) and the fax sending is still broken in the same way.

Can this bug be reopened/updated accordingly?

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.