Description of problem:

lpstat -p always reports the current job as job id zero.

Version-Release number of selected component (if applicable):

cups-1.4.2-16.el6

How reproducible:

always

Steps to Reproduce:
1. lp -d someprinter somefile.txt
2. lpstat -p 
  
Actual results:

   $ lp -d someprinter somefile.txt
   request id is someprinter-29 (1 file(s))
   $ ./lpstat -p
   printer someprinter now printing someprinter-0.  enabled since Tue 13 Jul 2010 01:53:25 PM CEST

(Notice the job is "someprinter-29" whereas lpstat reports "someprinter-0" as being printed)

Expected results:

   $ lp -d someprinter somefile.txt
   request id is someprinter-30 (1 file(s))
   $ ./lpstat -p
   printer someprinter now printing someprinter-30.  enabled since Tue 13 Jul 2010 01:53:25 PM CEST

Additional info:

This is caused by SVN revision 7620 upstream to fix STR #2845

Reverting that patch does list the correct job id (but obviously reintroduces the bug for 2845 so this is not the solution).

In lpstat.c:


 if ((jobs = cupsDoRequest(CUPS_HTTP_DEFAULT, request, "/")) != NULL)
 {
  /*
   * Get the current active job on this queue...
   */

   ipp_jstate_t jobstate = IPP_JOB_PENDING;
   jobid = 0;

   for (jobattr = jobs->attrs; jobattr; jobattr = jobattr->next)
   {
     if (!jobattr->name)
     {
       if (jobstate == IPP_JOB_PROCESSING)
         break;
       else
         continue;
     }

     if (!strcmp(jobattr->name, "job-id") &&
         jobattr->value_tag == IPP_TAG_INTEGER)
       jobid = jobattr->values[0].integer;
     else if (!strcmp(jobattr->name, "job-state") &&
              jobattr->value_tag == IPP_TAG_ENUM)
       jobstate = jobattr->values[0].integer;
   }

   if (jobstate != IPP_JOB_PROCESSING)
     jobid = 0;

   ippDelete(jobs);
 } 

The problem is that the jobstate is never IPP_JOB_PROCESSING apparently.

I tried running lpstat in a loop while printing a file and did not get a single correct output.

Yet I guess it's correct for lpstat to assume that if the printer is in state processing, then at least one job in the list in also in state processing, so I wonder if this is a bug in lpstat or in the scheduler.

I am escalating this to bugzilla although I do not have a patch yet, the reason for this being that our partner has reported this issue as severity high.