Re: [hpoj-devel] hpo bug (sane 1.0.4)

[Obi-Wan <bv...@in...>]

>> Both ptal-mcld and ptal-print dump copious amounts of debugging info
>> to the shell, even with the stock install (./configure --without-usb).
>
> Is there any reason why you used the "--without-usb" switch?  There's nothing
> wrong with using it, of course, but if you found a build problem that needs
> it as a workaround then I'd like to fix it.

My old box doesn't have USB support.  I conjectured that using that flag
might make my compiles faster and/or my binary smaller.

BTW, for you Debian types out there, I had to make one little hack to
make hpoj recognize the QT stuff.  The deb for QT puts the includes
in /usr/include/qt (not a bad idea, since there are dozens of them),
but the libs & binaries in /usr/lib & /usr/bin.  The hpoj configure
script expects all three subdirs to be under the same parent dir.  I
had to create a new directory named /usr/qt and inside that create
symlinks to /usr/bin, /usr/lib, and /usr/include/qt for the bin, lib,
and include subdirs, respectively.  The stock hpoj configure script
now finds /usr/qt all on its own, and compiles in support for it.

   # mkdir /usr/qt
   # cd /usr/qt
   # ln -s /usr/bin
   # ln -s /usr/lib
   # ln -s /usr/include/qt include

>> So much so that it overflowed my scrollback buffer.  Before I send
>> thousands of lines of useless stuff to the list, is there anything
>> in particular that you'd like to see?
>
> Well, not knowing what's on the menu, it's hard to know what to order.  :-)
> For starters, you could run the "script" command and invoke ptal-mlcd and
> ptal-printd (after making sure any old instances are killed off).  Then try
> printing something that causes the error messages to spew.  Once it has
> quieted down, you can exit the shell spawned by script and send the
> resulting "typescript" file.  If it's really big you can send it just to me
> (both to dav...@hp... and pa...@rc...), but other than that we
> can keep this discussion on the mailing list.

I had the foresight to leave my PSC 500 on when I came to work today,
so I tried to scan something just now.  I was fiddling with rc scripts,
so I killed & restarted ptal-mlcd & ptal-printd numerous times this
morning.  Here's what's currently running:

   > psg ptal
   root     12720  0.0  2.4  1768  740 pts/15   S    11:18   0:00 /usr/local/sbin/ptal-mlcd par:psc500 -alias mlcpp0
   root     12722  0.0  1.2  1244  392 pts/15   S    11:18   0:00 /usr/local/sbin/ptal-printd mlc:par:psc500 -like /dev/lp0

I redirected output to a log file when I launched them.  When I run
   scanimage -d hp:mlc:par:psc500 --test
I get this to stdout from scanimage:

   > scanimage -d hp:mlc:par:psc500 --test
   ptalChannelOpen(chan=0x08054678): provider failed open!
   ptalChannelOpen(chan=0x08054678): provider failed open!
   scanimage: open of device hp:mlc:par:psc500 failed: Error during device I/O

and this in the ptal-mlcd log file:

---------
   ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:psc500>, pid=12720, errno=11
   Reply timer popped on port=0, count=1!

   ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=12720, errno=11
   exClose(reason=0x3002)
---------

Curiously, ptal-devid also fails now.  It worked last night:

   > ptal-devid mlc:par:psc500
   ptalMlcDeviceGetDeviceIDString(dev=par:psc500): unsuccessful status=13!
   ptalDeviceGetDeviceIDString(dev=mlc:par:psc500) failed!

The same errors are dumped to the ptal-mlcd log file.

I can't power cycle my PSC or restart my computer remotely (won't boot
automatically at the moment), so who knows what state either of them
is really in right now.  I'll try more from home some evening soon.

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins