CUPS IPP print to Novell servers error since 11.10 upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cups (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Oneiric |
Fix Released
|
High
|
Unassigned |
Bug Description
We have multiple reports of printing errors around our campus since upgrading to 11.10. The error message is: 'cups-ipp-
Our advised setup for Ubuntu users has been to print to queues on a Novell server via IPP. This worked fine and without error in previous ubuntu versions. The problem appears to be the addition of a compliance test between CUPS 1.4.6 and 1.5.0 (/backend/ipp.c revs 9490 9759). The validation fails to non-CUPS IPP servers since Validate-Job is a CUPS extension to IPP.
$ apt-cache policy cups
cups:
Installed: 1.5.0-8ubuntu3
Candidate: 1.5.0-8ubuntu3
Version table:
*** 1.5.0-8ubuntu3 0
500 http://
100 /var/lib/
1.5.0-8 0
500 http://
Robert Bradley (robert-bradley1) wrote : | #1 |
Till Kamppeter (till-kamppeter) wrote : | #2 |
Can you provide a simple patch which works around the bug? We could solve the problem for Oneiric then.
Independent of this, can you post a bug to CUPS upstream on
Thanks.
Changed in cups (Ubuntu): | |
status: | New → Incomplete |
GALLINARI (jean-louis-gallinari) wrote : | #3 |
I've got excatly the same problem with a HP PSC 1510 which however is absolutely recognized.
It's possible to print when it's directly connected to the PC.
On the other hand, when it's connected on the network using my LiveBox2 I get the message "cups-ipp-
I'd like to indicate I'm not alone as this can show it
ThierryM (thierry-munoz) wrote : | #4 |
Hi,
Like GALLINARI, I confirm this bug under 11.10 with a Canon Pixma iP4500 connected by USB to a Livebox2 (modem router ADSL). Under 10.10 and 11.04 there wasn't any problem : I could print using IPP. But since I upgraded to 11.10 it's impossible. I can print if I connect directly my printer to my laptop via USB.
Robert Bradley (robert-bradley1) wrote : | #5 |
Quick update:
The bug is now filed upstream as requested (http://
(I should also apologise at this point, since on re-reading http://
Robert Bradley (robert-bradley1) wrote : | #6 |
- Patch: replaces backend/ipp.c with the 1.4.x version (branches/1.4.x/backend/ipp.c r8950) Edit (94.0 KiB, text/plain)
OK, as a quick fix, I have effectively replaced backend/ipp.c with the 1.4.x version (branches/
-------
--- ipp-1.4x.c 2011-10-27 16:50:04.000000000 +0100
+++ ipp.c 2011-10-27 16:37:46.000000000 +0100
@@ -428,7 +428,7 @@
if ((fd = cupsTempFd(
{
- _cupsLangPrintE
+ _cupsLangPrintE
return (CUPS_BACKEND_
}
-------
I would not trust this without a lot more testing, but this worked for me just now.
ThierryM (thierry-munoz) wrote : | #7 |
Thank you very much Robert,
Your patch works fine for me : now I can print like under 10.10 and 11.04.
Besides I learned how patching : I had never made this before
For those who would try this you can download the source of cups here : http://
Robert Bradley (robert-bradley1) wrote : | #8 |
It's easier to use "apt-get source cups" to fetch the source code, since then you get the latest source code with the Ubuntu/Debian patches applied too. The orig.tar.bz2 file is actually the unaltered CUPS source.
At the risk of being slightly off-topic, these instructions should work for building and replacing the ipp backend manually:
* Download the patch file in my previous comment.
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory, then run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Run "./configure"
Normally you would do "make && sudo make install", compiling the entirety of CUPS (you'll need the po4a package installed first). We have CUPS installed already though, so to save time we can just compile the contents of the "backend" directory on their own:
* "cd backend && make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
- "sudo cp /usr/lib/
- "sudo cp ./ipp /usr/lib/
ThierryM (thierry-munoz) wrote : | #9 |
Thanks for yours intructions in order to patch correctly.
For me you aren't at all off-topic : I had to find myself how to patch and there aren't much informations that explain how to make it properly.
So I'm going to translate in french yours advices to help others users.
Regards
Till Kamppeter (till-kamppeter) wrote : | #10 |
Setting to "Confirmed" as a working solution is presented here. Not yet "Triaged" as it needs to be discussed whether this solution should really get applied. Downgrading the backend from 1.5.0 to 1.4.x is a rather big patch and probably pulls out many features, not only the feature which caused the regression. What we need, especially for an SRU in Oneiric, is to really find out what caused the regression and pull out only that feature or better fix it.
Changed in cups (Ubuntu): | |
status: | Incomplete → Confirmed |
ThierryM (thierry-munoz) wrote : | #11 |
For those who want explanations in french, you can find them here : http://
Robert Bradley (robert-bradley1) wrote : | #12 |
- Patch to backend/ipp.c - sets document_format to NULL if no suitable document-format can be matched. Edit (746 bytes, text/plain)
Another update:
First, for the instructions I posted yesterday, you do in fact need to build the whole of CUPS for them to work.
Secondly, I did a bit of digging through Wireshark dumps last night, and found out that the Validate-Job calls were not the whole story. It turns out that CUPS 1.5 adds a document-format attribute to its print jobs. It appears to dig through the server response for supported types, and if it does not match a MIME type to that of the document, it assumed "application/
The patch attached here replaces that assumed value with NULL, which results in the attribute being skipped. This replicates the 1.4 behaviour, although we still get the complaints over IPP compliance. I also added a bit of debug-level logging around the document-format discovery area of the code.
ThierryM: would you be willing to try this new version and see if it prints for you?
Till Kamppeter (till-kamppeter) wrote : | #13 |
Robert, does applying only the patch attached to your comment #12 fix the problem? It is a simple small patch which we could easily make available to our users as a Stable Release Update (SRU) for Oneiric. If additional patches are needed, please tell me the minimum set of patches needed to solve the problem. Thanks in advance.
Robert Bradley (robert-bradley1) wrote : | #14 |
Till: yes, applying just the patch from comment 12 fixes the problem for me. I do not feel that any additional patches are needed, simply because the new patch behaves in the same way as the code from 1.4.6, and that appears to work fine for everyone. So, if the comment #12 patch also works for ThierryM, I would suggest using that patch as-is.
The missing-
Till Kamppeter (till-kamppeter) wrote : | #15 |
Robert, thank you very much.
Till Kamppeter (till-kamppeter) wrote : | #16 |
ThierryM, can you please apply Robert's patch from comment #12 to the original Ubuntu package of CUPS, and no other patches. Can you test whether only this change is enough in Oneiric's CUPS to solve your problem? Thanks in advance.
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #17 |
The attachment "Patch: replaces backend/ipp.c with the 1.4.x version (branches/
[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]
tags: | added: patch |
ThierryM (thierry-munoz) wrote : | #18 |
Hi,
I tested the patch #12 alone (I desinstalled CUPS, downloaded the source package, I patched with the patch #12) and it doesn't solve my problem : the bug seems the same.
Robert Bradley (robert-bradley1) wrote : | #19 |
Thierry,
I would be interested in seeing what CUPS is sending to the print server. Would you be willing to submit a debug log and the results of "tcpdump -i eth0 -p port 631 > packetlog" showing an attempt at printing the Ubuntu test page?
Thanks in advance,
Robert
Robert Bradley (robert-bradley1) wrote : | #20 |
Better make that "sudo tcpdump -i eth0 -p -w packetlog port 631" (or alternatively, use Wireshark with capture filter "port 631").
Robert Bradley (robert-bradley1) wrote : | #21 |
One final point: if you are happy to collect the IPP packets, it would be very useful if I looked at logs/packet dumps for both the new (broken) patch, and the previous one which worked for you. That way, I ought to be able to see just what is different between the two versions! Either emailing them to me or attaching them is fine from my point of view.
ThierryM (thierry-munoz) wrote : | #22 |
- Result of "sudo tcpdump -i wlan0 -p -w packetlog port 631" Edit (1.1 MiB, application/octet-stream)
Hi Robert,
Like I print from my laptop via wifi I did : "sudo tcpdump -i wlan0 -p -w packetlog port 631". I hope I did right.
I join the packetlog.
ThierryM (thierry-munoz) wrote : | #23 |
The previous "packetlog" was obtained with the first patch that's working. Do you want an other packetlog with the broken patch ?
Robert Bradley (robert-bradley1) wrote : | #24 |
Hi Thierry,
Yes, please! :)
ThierryM (thierry-munoz) wrote : | #25 |
- Result2 of "sudo tcpdump -i wlan0 -p -w packetlog port 631" with the broken patch Edit (99.7 KiB, application/octet-stream)
So, there's the packetlog2 with the broken patch.
Robert Bradley (robert-bradley1) wrote : | #26 |
- Full patch for CUPS 1.5.0 with auto-downgrade (untested) + missing-document-type fixes Edit (1.7 KiB, text/plain)
Hi Thierry,
Thanks for the packet logs - they were very interesting! It looks to me as if CUPS is continually trying to talk to your print server using IPP/2.0, which it does not appear to support. With the present code, CUPS expects it to return an error of IPP_VERSION_
Would you mind applying the following inline patch to the existing version from comment #12 and seeing if that helps?
=== modified file 'backend/ipp.c'
--- old/backend/ipp.c 2011-10-28 09:12:41 +0000
+++ new/backend/ipp.c 2011-10-29 00:11:43 +0000
@@ -247,6 +247,7 @@
ppd_file_t *ppd; /* PPD file */
_ppd_cache_t *pc; /* PPD cache and mapping data */
fd_set input; /* Input set for select() */
+ int server_ipp_version;
/*
@@ -830,6 +831,18 @@
supported = cupsDoRequest(http, request, resource);
ipp_status = cupsLastError();
+
+ /* Extract server IPP version, and use this to downgrade */
+ server_ipp_version = supported-
+ server_ipp_version += supported-
+ if (version > server_ipp_version)
+ {
+ fprintf(stderr, "INFO: Server responded to our IPP/%d.%d request ",
+ version / 10, version % 10);
+ fprintf(stderr, "with an IPP/%d.%d response - downgrading!\n",
+ server_ipp_version / 10, server_ipp_version % 10);
+ version = server_ipp_version;
+ }
fprintf(
Robert Bradley (robert-bradley1) wrote : | #27 |
Actually, before testing the patch in my previous comment, try changing your printer URI to "ipp://
I also think it might be worth me repositioning the code within that patch so that it is only called if the existing downgrade code finds nothing wrong. (Otherwise, we may end up downgrading further than we have to.)
ThierryM (thierry-munoz) wrote : | #28 |
- Result3 of "sudo tcpdump -i wlan0 -p -w packetlog port 631" with the broken patch Edit (99.5 KiB, application/octet-stream)
Hi Robert,
I have applied the last patch over CUPS yet patched with the patch in the message #6 but the problem still exists : thre's no amelioration.
I join the packetlog3 to look it.
ThierryM (thierry-munoz) wrote : | #29 |
Sorry but I posted my previous message without reading the message #27.
But when I use "ipp://
ThierryM (thierry-munoz) wrote : | #30 |
Sorry again but in my message #28 it's not the patch in message #6 : I made a mistake when I wrote, I used CUPS patched with the patch in the message #12 to do the test.
Robert Bradley (robert-bradley1) wrote : | #31 |
Thierry,
The packetlog3 file was interesting because it looks like it's downgrading to IPP/1.0 fine now! So, time for me to figure out why you're getting HTTP 400 (Bad Request) errors from it...
This looks like it is a separate bug from the original bug reported here, which comment #12 seems to fix well enough. Perhaps we should get this split out into its own bug report and continue working on this there?
ThierryM (thierry-munoz) wrote : | #32 |
Robert,
For me, I'm not capable to distinct that there is 2 différents bugs :-) : so do what you think fair or more efficient. If you split, could you indicate the new number of the bug ?
Thank you for your job because now with the first patch I can again print through the network.
Regards
Robert Bradley (robert-bradley1) wrote : | #33 |
- Cumulative patch fixing the missing document-format issue, auto-downgrade and the first attempt at forcing HTTP/1.0-style document submission. Edit (3.7 KiB, text/plain)
Thanks for your patience with this, Thierry, it's much appreciated! I'll leave the bug splitting decision to Till, I think. In the meantime, I have another full patch to try. This one is inspired by the fact that the old version never tried to use the "Expects: 100-continue" header - instead, it just sent the whole file straight away. You get a new IPP option "nohttpcontinue
Till Kamppeter (till-kamppeter) wrote : | #34 |
Robert, I think a second bug report is not needed. As soon as you have solved the problem with Thierry, I will apply the complete set of patches (and also forward it upstream).
ThierryM (thierry-munoz) wrote : | #35 |
- Result4 of "sudo tcpdump -i wlan0 -p -w packetlog4 port 631" with the cumulative patch Edit (48.5 KiB, application/octet-stream)
I patched the original CUPS with the last cumulative patch but it doesn't work.
Here the log package4.
Robert Bradley (robert-bradley1) wrote : | #36 |
Is that with or without the nohttpcontinue option (URI ipp://192.
ThierryM (thierry-munoz) wrote : | #37 |
With the 2 URI "ipp://
Robert Bradley (robert-bradley1) wrote : | #38 |
Thanks - now it's time for me to figure out why nothing changed!
Luigi (b-luigi) wrote : | #39 |
Hi, I'm using Kubuntu 11.10 and I have the same issue with a
U.S. Robotics Wireless MAXg ADSL Gateway
with a HP Laserjet 6L connected through the usb connection (using a paraller to USB connector)
The patch at #12 worked for me and just to recap I followed the following steps:
* install with synaptic or other package manager "po4a"
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory, then run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Download the patch file in comment #12
* Run "./configure"
* Run "make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
- "sudo cp /usr/lib/
- "sudo cp ./ipp /usr/lib/
Thanks all for the help on this!
Note: if I try to install the patched version on its own the KDE printing doesn't work.
Luigi (b-luigi) wrote : | #40 |
Sorry, I try again:
* install with synaptic or other package manager "po4a"
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory,
* Download the patch file in comment #12
* Run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Run "./configure"
* Run "make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
- "sudo cp /usr/lib/
- "sudo cp ./ipp /usr/lib/
Robert Bradley (robert-bradley1) wrote : | #41 |
The latest update on the upstream bug is that it is the Novell (and Livebox2) servers at fault, and not CUPS. The bug has been "Closed w/o Resolution". I have no idea where this leaves us long-term - presumably trying to write our own patch to successfully disable chunking (fixing the Livebox2 issue?), and using the existing patch from #12 to work around the Novell issue.
ThierryM (thierry-munoz) wrote : | #42 |
Hi Robert,
Thanks for your information. But I don't understand why the Livebox2 worked fine before with the older CUPS ? And why the Livebox2 works under Windows ?
I regret my upgrade to Oneiric : Maverick 10.10 worked much better for printer (USB detection doesn't work too for my printers MP240 and iP4500).
Other solution, It's possible to downgrade CUPS ?
Anyway thank you for your patch very usefull.
Regards
Robert Bradley (robert-bradley1) wrote : | #43 |
I've not tried it, but Windows probably works fine because it avoids HTTP chunked transfers, like CUPS 1.4 does.
I've no idea if it would work or not, but you could try removing the CUPS packages, and then playing with apt pinning to force those to be reinstalled from the Lucid repositories. I have no idea if that would work well, and it's not an ideal solution in any case, but may be the only option.
Luigi (b-luigi) wrote : | #44 |
I have the following server:
U.S. Robotics Wireless MAXg ADSL Gateway
So, it sounds strange that Novell, Livebox 2 and MAXg are faulty, after CUPS update.
Also in my case, Windows XP, Windows 7 and Kubuntu 11.04 worked totally fine with the same configuration...
Robert Bradley (robert-bradley1) wrote : | #45 |
- Cumulative patch fixing the missing document-format issue, HTTP-style auto-downgrade of IPP, and adding the nohttpchunking option for forcing HTTP/1.0-style document submission. Edit (4.4 KiB, text/plain)
OK, I think I might finally have this HTTP chunking issue sorted, at least partially. In the case where only one job is sent at one (so IPP's Print-Job is used instead of Create-Job), the attached patch prevents the use of HTTP chunking for me.
This needs to be enabled by setting your printer URI to "ipp://
Notes:
1. I still get the Expect: 100-continue header for some reason, regardless of my attempts to disable it, so I gave up there.
2. The Novell servers I have access to work regardless - they only require the document-format patch in comment 12.
Robert Bradley (robert-bradley1) wrote : | #46 |
- Cumulative patch, including the data-loss patch for non-chunked output. Edit (4.9 KiB, text/plain)
As it turned out, whilst the previous patch works, there was one issue: part of the data stream from the printer driver was lost! This only occurs when using the Content-Length fallback code, which I force on with the previous patch.
Gory details:
For the fallback, the IPP backend copies the data to a temporary file, and fetches the file size (using backendRunLoop). Unfortunately, earlier on in the code, it reads from stdin to a buffer, which is forgotten about in the fallback case! The end result was corruption of printouts using PCL drivers.
I have now added yet another fix to the IPP backend to write this initial data out to the temporary file and update the length accordingly. This version now prints correctly, as confirmed with hard copy.
ThierryM and others with Livebox2 routers: could you please check that this prints when nohttpchunking is enabled as above?
mavosaure (mavosaure) wrote : | #47 |
Hi,
I also experiment the same issue since I updated to Oneiric. My ADSL/modem "BBox2" router is branded by another french provider "Bouygues", but it's in fact the same device : SAGEM f@st 3504.
I'll try you patch and give you some news.
Thxs for all
mavosaure (mavosaure) wrote : | #48 |
Great : using patch of comment #46, it works for me but with two visible non-fatal errors :
cups-ipp-
spool-area-full
Notice that I had to create a "new" printer using the new URI "ipp://
I apologize, but I didn't succeed in looging a tcpdump, i got only empty files (after changing the network device).
Robert Bradley (robert-bradley1) wrote : | #49 |
Mavosaure, thanks for testing the patch for me. There is no need to worry about the tcpdumps, given it worked as expected, but don't let that stop you! It may help me with the two messages you saw, which I am a little surprised by. You can try clearing out /var/spool/cups to see if that sorts out the "spool area full" message (but I expect this is server-side). The missing-job-history message is most likely another cosmetic complaint about IPP specification compliance. It can also apparently occur if the job disappears from the print server. It seems to be working though, which is better than last week!
ThierryM (thierry-munoz) wrote : | #50 |
- Result5 of "sudo tcpdump -i wlan0 -p -w packetlog5 port 631" with the cumulative patch #46 Edit (4.9 MiB, application/octet-stream)
Hi,
I tried the last patch #46 and it's working but I have first this message : "spool-area-full" before the printing succeed.
The URI printer is "ipp://
I join the result of the command "tcpdump -i wlan0 -p -w packetlog5 port 631".
Regards
Robert Bradley (robert-bradley1) wrote : | #51 |
- Cumulative patch minus auto-downgrade. Edit (4.0 KiB, text/plain)
Hi all,
This is just a guess, but one thing you could try is setting the IPP version. The patch here removes my auto-downgrade code, so you should be able to test using the following URIs:
ipp://192.
ipp://192.
ipp://192.
I don't know if this will fix this spool-area-full message, but it can't hurt trying it. Version 1.1 ought to match CUPS 1.4.6.
Thanks again for your patience everyone!
ThierryM (thierry-munoz) wrote : | #52 |
I patched directly with the minus auto-downgrade. I obtain the same results with the 3 URIs.
But I noticed (and perhaps with the patch #46 too) that I can print the first page diretly but after I had to push the button on the printer to feed paper in order to print.
I have always the "spoll-area-full" message and an other (until I push the button) that says "copying print data".
Robert Bradley (robert-bradley1) wrote : | #53 |
The "Copying print data" message is safe enough - that's generated when the fallback code copies the print job to disk. The spool-area-full part seems to be the server's fault, and appears during the processing stage (we seem to get multiple connections too). Your CUPS 1.4.6 logs don't show any requests for printer state during printing, which might explain why it's started appearing now!
What's interesting here is that this pausing behaviour sounds very similar to this bug:
https:/
Could we be hitting this same bug somehow? With misleading status messages, it's entirely possible...
Thomas Kluyver (takluyver) wrote : | #54 |
Since my uni uses Novell infrastructure, I tried Robert's patch from comment #12, and that seems to solve the problem for me.
Changed in cups (Ubuntu): | |
status: | Confirmed → Fix Committed |
Changed in cups (Ubuntu Oneiric): | |
status: | New → Fix Committed |
Changed in cups (Ubuntu): | |
importance: | Undecided → High |
Changed in cups (Ubuntu Oneiric): | |
importance: | Undecided → High |
milestone: | none → oneiric-updates |
Till Kamppeter (till-kamppeter) wrote : | #55 |
- cups_1.5.0-8ubuntu5_1.5.0-8ubuntu6.debdiff Edit (106.7 KiB, text/plain)
IPP backend reverted to the version of CUPS 1.4.x to fix bug 881843, bug 877958, bug 879625, and bug 883585 for the time being until the backend gets fixed upstream. Applied this to the Debian BZR repository of CUPS so that the fix will appear in the next CUPS package for Precise and also applied to a Stable Release Update (SRU) CUPS package for Oneiric which I have uploaded to -proposed. As soon as this package gets approved and ready for testing on Oneiric, a separate comment with testing instructions will get posted here. Please test the package then and report back here, so that we can make it an official update.
A debdiff of the SRU for Oneiric is attached.
Robert Bradley, thank you for all the work on these bugs and the downgrade patch for the IPP backend.
Launchpad Janitor (janitor) wrote : | #56 |
This bug was fixed in the package cups - 1.5.0-13
---------------
cups (1.5.0-13) unstable; urgency=low
[ Till Kamppeter ]
* debian/
of CUPS 1.4.x, as the 1.5.x versiuon has major regressions (LP: #877958,
LP: #879625, LP: #881843, LP: #883585, Closes: #638521, CUPS STR #3966,
CUPS STR #3967). This patch will get removed as soon as upstream has fixed
all these regressions. As upstream did not announce any new features for
the IPP backend in the release notes for 1.5.x, we assume that with this
step no features will get lost.
* debian/
notifications with too few parameters when there are parameters which
cannot be added to the D-Bus request, especially invalid UTF-8 strings.
This made gnome-session-
* debian/
printers and for drivers with PPDs which are not PDF-aware) did not
recognize the duplex setting correctly, making duplex not working on
many common printers (LP: #897723).
* debian/
[ Martin-Éric Racine ]
* [cups.postrm]: purge /etc/cups/
[ Martin Pitt ]
* debian/compat: Bump from 5 to 9, this apparently was forgotten in the
Multi-Arch transition.
-- Martin Pitt <email address hidden> Fri, 02 Dec 2011 11:05:51 +0100
Changed in cups (Ubuntu): | |
status: | Fix Committed → Fix Released |
Martin Pitt (pitti) wrote : Please test proposed package | #57 |
Hello Tim, or anyone else affected,
Accepted cups into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
tags: | added: verification-needed |
mavosaure (mavosaure) wrote : Re: [Bug 881843] Re: CUPS IPP print to Novell servers error since 11.10 upgrade | #58 |
For me it's OK : applying the package-update cups - 1.5.0-13 (from the
proposed repository) make my printer work again.
Good job!
Thanks!
Le 05/12/2011 07:15, Martin Pitt a écrit :
> Hello Tim, or anyone else affected,
>
> Accepted cups into oneiric-proposed, the package will build now and be
> available in a few hours. Please test and give feedback here. See
> https:/
> enable and use -proposed. Thank you in advance!
>
> ** Tags added: verification-needed
>
Till Kamppeter (till-kamppeter) wrote : | #59 |
mavosaure, thank you very much for testing. Marking the bug as verified.
tags: |
added: verification-done removed: verification-needed |
ThierryM (thierry-munoz) wrote : | #60 |
Hi,
I tested the new package-update of cups for my Canon MP240 plugged on a Linksys Switch Print Server PSUS4. And it works perfectly : until now, I hadn't succeeded to print with any earlier version of Ubuntu (the first page stayed blocked).
So for me, now it's an improvement (no more regression like until now).
I'm going to test at home with my Livebox and my Canon iP4500 and I tell you if it works too.
Robert Bradley (robert-bradley1) wrote : | #61 |
I have filed three new bugs upstream now for these issues. This is deliberate since I know upstream are reluctant to work around every possible print server bug from last time.
http://
This is the original bug regarding Novell print servers, and the patch is the same as in comment #12 here.
http://
This covers the remainder of the patches here, and attempts to sort out the Livebox2 issues. As disabling chunking is seen as a large change to work around one printer server's bugs, this is unlikely to be accepted upstream unfortunately. Does anyone know if OS X Lion compatibility has been filed as an issue with Orange France or Sagem?
http://
This is the bug where print data can be lost if the print server does not support HTTP 1.1 (fixed in comment #46 here). I separated this bug out since this is a true (if rarely triggered) bug in upstream, as opposed to a workaround for print server bugs. This may well get fixed, but will achieve nothing for Livebox2 users without the chunking patches being included too.
ThierryM (thierry-munoz) wrote : | #62 |
Hi,
I tested the new package-update of cups with my Canon Pixma iP4500 plugged on the Livebox2 router. And now, I can print via wifi like before under Ubuntu 10.10 .
So for me, the bug is fixed.
I thank everybody especially Robert Bradley for this patience and perseverance.
Regards
Till Kamppeter (till-kamppeter) wrote : | #63 |
Thierry, also thank you for doing all the testing and supplying all the information for working on this bug.
Launchpad Janitor (janitor) wrote : | #64 |
This bug was fixed in the package cups - 1.5.0-8ubuntu6
---------------
cups (1.5.0-8ubuntu6) oneiric-proposed; urgency=low
* debian/
of CUPS 1.4.x, as the 1.5.x versiuon has major regressions (LP: #877958,
LP: #879625, LP: #881843, LP: #883585, Closes: #638521, CUPS STR #3966,
CUPS STR #3967). This patch will get removed as soon as upstream has fixed
all these regressions. As upstream did not announce any new features for
the IPP backend in the release notes for 1.5.x, we assume that with this
step no features will get lost.
* debian/
notifications with too few parameters when there are parameters which
cannot be added to the D-Bus request, especially invalid UTF-8 strings.
This made gnome-session-
* debian/
printers and for drivers with PPDs which are not PDF-aware) did not
recognize the duplex setting correctly, making duplex not working on
many common printers (LP: #897723).
* debian/
-- Till Kamppeter <email address hidden> Tue, 29 Nov 2011 21:49:41 +0100
Changed in cups (Ubuntu Oneiric): | |
status: | Fix Committed → Fix Released |
Moreau (serge-moreau) wrote : | #65 |
I had the same problem on suse 12.1.
I installed cups 1.5.2 but tht did not resolved the problem.
I was using a livebox with ipp://192.
printfile was not accepted.
I expected that the new cups version take into account the patch. Must i wait for another cups update ?
many thanks
Till Kamppeter (till-kamppeter) wrote : | #66 |
Moreau, please report your problem at SUSE then.
Moreau (serge-moreau) wrote : | #67 |
Yes already done, they sent me to cups, i want to mentioned that apparently CUPS 1.5.2 did not incorporate the patch discussed here.
Thanks for your remark
Moreau (serge-moreau) wrote : | #68 |
I collected this report on cups.org :
http://
I am not sure to clearly understand, but does that mean that they wont take into account that problem ?
Many thanks for your advices
SM
tags: | added: quantal |
I have attached an example CUPS log to this comment to demonstrate the problem.
Looking at the source more closely, it appears that the initial test for Validate-Job succeeds, but actually using it before printing fails. One very quick way to test this would be to find the line "while( !job_canceled && validate_job)" (1229 upstream), and simply put "validate_job = 0" on the line above this. That should skip the attempt to use Validate-Job. Longer term, this might have to become a configurable option, either globally or per IPP printer.