cups-browsed 1.24 regression - driverless printing no longer works with legacy printers #163
Comments
|
Tested 1.25.6 - still the same error. |
|
Fixed in commit 9415fde. Thank you for the bug report. |
|
Just tested it. Now I'm getting this instead of the interface -1: |
|
This is not an error and nothing to worry about. It is absolutely correct and telling that Avahi has completed reporting all events which happened before starting cups-browsed and so Avahi and cups-browsed are in sync now. You see this message also when using the |
|
Printing still doesn't work, I guess it's because of: This as also in the above full errorlog. |
|
This looks like another bug @deepak0405 is working on. Could you test https://github.com/deepak0405/cups-filters/tree/solve-assertion-error |
|
@logTom I will make a new commit today for the issue, @tillkamppeter The above branch doesn't contain the solution for this problem. Looking at the log I think, it is because of the IPP version, may be the remote cups queue supports 1.1 and we are doing request using IPP 2.0. |
|
@logTom I want to try whether the print job completes, if we do a IPP1.1 request. Can you please send me the output when cups-browsed is run using this branch. |
|
@deepak0405 Here is the full log https://pastebin.com/9DEVe5uN. |
|
@tillkamppeter Right now the job is not getting completed, because the IPP request is returning an empty
|
|
Yes, let us do the fallback to IPP 1.1 when an attempt with 2.0 fails. I think this is the best solution to get maximum functionality and compatibility with old servers. |
|
@logTom |
|
@deepak0405 Is it because of this:? Here is the full log: |
|
Please do not provide relevant data for your issue report on external (commercial, full of ads) services. We have enough space to accommodate that info and it is much easier to read when embedded in the thread. It also stays available and does not expire or get removed after a certain time. |
|
@logTom, the previous error probably was masking the current result. |
|
@logTom @tillkamppeter Right now, we don't need a longer log. I wrote the fallback logic, that if the IPP2.0 request doesn't work, we should do a IPP1.1 request, but the logic is not working, after IPP2.0, there was no call made with IPP1.1 request. If the fallback logic works, most probably in this case, the printing will start working. |
|
@deepak0405, could you try to fix this today or tomorrow morning? Then I could still get it into Ubuntu Eoan. Thanks. |
|
Can we get this issue reopened or should I create a new one? |
|
Hi, Printing still doesn't work, I guess because of "No destination found for job 4 to KONICA_MINOLTA_bizhub_C253_5E_92_C6". Here is the full log: |
|
@logTom, I have committed a possible fix, please test the current state of the GIT. |
|
@tillkamppeter Now it says the job is printed and the print queue is empty, but it isn't actually printed. |
|
@logTom Can you also please send the cups error_log ? |
|
@deepak0405 Sure. Here the full file Also here the access_log of today - at the end there is "client-error-not-found". |
|
@logTom, We need the log of job 5 and later. Then remove all pending or stale jobs Save date and time, this is the time from when on the error_log will get relevant: and print a job. should not list your job any more. |
|
Does this look right? |
|
Sorry I forgot some of the beginning - it was in error_log.O file. |
|
@deepak0405, in the implicitclass backend, when you created the arg_nt[] argument list for the filters and the backend, did you set arg_nt[0] to the URI of the destination printer? |
Ok, I'll backport it too, thank you for letting me know. |
|
Best is to take the current GIT snapshot of cups-filters, build it and install cups-browsed, implicitclass, and libcupsfilters of it. |
|
I have found a bug in implicitclass, where the output of the filters is passed over to the IPP CUPS backend for sending off to the server. I have fixed this now in commit db3e46d. Please test. |
|
To solve issue #181 I have done several fixes and improvements on the implicitclass backend. Please re-test to see whether this also solves this bug. |
|
@tillkamppeter Hi, I tried it with the current master. It still doesn't work. Here is the output of cups-filters: |
|
@tillkamppeter Shouldn't @logTom have ipp:// in device uri instead of implicitclass://? IIUC He has the printer in his local network, not remote cups queue. |
|
@logTom, @zdohnal, I have now spotted what got wrong here. The get_printer_attributes() function is always checking whether the answer from the printer fullfills the requirements for a request with attributes "all" and optionally "media-col-database" (for generating a PPD file) but when printing a job, cups-browsed does a get-printer-attributes request to find out whether the destination printer is busy. This request fails the checks and so the answer gets suppressed, making cups-browsed giving up on the job. |
|
@logTom, @zdohnal, I have now restructured the get_printer_attributes() function of cups-browsed and moved it into libcupsfilters, to share it with the |
|
@logTom, please check also in the CUPS web interface or in a printer setup tool whether your Konica printer gets discovered and listed with a "driveless" model/driver option. Please try creating a queue selecting this option and try out whether you can print through it. |
|
@tillkamppeter |
|
Here are screenshots from the webinterface. I can see driverless listed here. I don't exactly know where I should create a queue. Is it under /jobs?
|
|
Your cups-browsed is not of the current GIT snapshot. If it was, the log would contain messages like: Please make sure to update your repo or clone the current GIT, build it, and install it, or at least copy the executables cups-browsed, driverless, and the library libcupsfilters.so.1.0.0 into the right places of your system, and then restart cups-browsed. |
|
I'm sorry, you are right. I forgot executing make install. |
|
According to the screenshots you are in the part for browsing existing queus, and you see the queue created by cups-browsed. |
|
Now the printer is assigned to the job at least. Next step is job execution by CUPS. clear the queues print a job and wait for it to fail (according to the cups-browsed and CUPS logs). |
|
Could you also attach the PPD file of your cups-browsed-generated print queue? It should be in To attach it here, rename it to have a |
|
Pleae also update to commit 6184b98. It is a small fix on implicitclass. Without it implicitclass at least sometimes fails. |
|
@logTom you can attach the logs as .txt too, it just need to rename the file, clicking on 'Attach files by dragging...' etc. and then find the file on your system. |
|
@tillkamppeter I pulled the latest master, but still no printing. I attached the cups error and ppd file as requested. |
|
Thank you. Could you run the command and post the output here? |
|
@tillkamppeter |
|
These permissions are wrong. On my Ubuntu 19.10 I have So please run Then try to print again. |
|
That fixed it! Printing now works. Thank you very much! |
|
I looked further into this. Ubuntu applies a distro specific patch for 755. I created a pull request for cups to fix this upstream. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm separating this issue because it seems different now than #124 .
Debug output from cups-filters 1.25.5:
The text was updated successfully, but these errors were encountered: