client 1.2.0 to 1.1.2x server over IPP: client-error-bad-request
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cupsys (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
Dapper |
Fix Released
|
Undecided
|
Martin Pitt |
Bug Description
Hi,
Running Kubuntu Dapper updated as of today 02-05-2006. For the past week I have been unable to print to our ipp based cups server. Other systems are printing fine.
From the command line
lpr 1.ps returns
lpr: Bad Request
From System Settings/Printers
A Test Print returns
A print error occurred. Error message received from system:
cupsdoprint -P 'printer' -J 'KDE Print Test' -H 'lpd:631' -o ' multiple-
client-
(via knotify)
From OpenOffice
returns just "error while printing"
lpstat -t returns
scheduler is running
system default destination: printer
device for printer: lpd://printer/PASS
printer accepting requests since Thu 01 Jan 1970 10:00:00 EST
printer printer is idle. enabled since Thu 01 Jan 1970 10:00:00 EST
Data file sent successfully
But in Fact nothing was sent to the cups server.
I'm a little lost at what this error really is, up until a week ago when I notice cups upgraded, it was working fine.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #1 |
Geo_KM (keith-barnabasmusic) wrote : | #2 |
Hi,
There is only 1 entry in /var/log/
E [10/May/
So it seems no error is logged. Should I have cupsd start with some non standard logging level?
An interesting point, 3 of us (Me on Kubuntu and the others on Ubuntu (Dapper)) here are now experiencing this problem, although is has become a little more intermittent. That is, every 5-6 attempt to print does seem to get through..... Pretty frustrating, as you can imagine.
I upgreaded the Server machine to (Which is Debian Stable) to 1.1.23-10sarge1 and it has not helped. Meanwhile all the others here at ozlabs are using Debian Unstable and not having any printing problems.?? Weird.
Thanks for yor help.
sbothe (ubuntu-sbothe) wrote : | #3 |
Hi,
Using a new installation of Kubuntu dapper flight 7 and I have the same Problem described above. Other stations in Network running SuSE10 are not affected as well. Please let me know what information could be useful to track the problem.
Thanks for help
Manuel López-Ibáñez (manuellopezibanez) wrote : | #4 |
Could you tell me your current cupsys version ? (you may find it by writting " dpkg -l cupsys | awk '/^ii/{print $2" "$3}' " in a terminal.)
Thanks.
Ante Karamatić (ivoks) wrote : | #5 |
My guess is that you don't have default printer. Try:
lpq
and then
lpq -P [name-of-
This wouldn't be first time I see this.
sbothe (ubuntu-sbothe) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request | #6 |
Hi,
On Friday 12 May 2006 13:03, manu wrote:
> Could you tell me your current cupsys version ? (you may find it by
> writting " dpkg -l cupsys | awk '/^ii/{print $2" "$3}' " in a
> terminal.)
Of course, cupsys on the Priniting Server is
cupsys 1.1.23-15 (debian testing)
and the kubuntu cupsys (for the client maschine) is
cupsys 1.2.0-0ubuntu2
Thank you for your help!
>
> Thanks.
>
> --
> Trying to Print produces lpr: Bad Request
> https:/
sbothe (ubuntu-sbothe) wrote : | #7 |
Hi,
On Friday 12 May 2006 13:40, Ante Karamatić wrote:
> My guess is that you don't have default printer. Try:
>
> lpq
>
I added -h <print_server> because I only use the remote printer queue. There
are no local queues
# lpq -h artus
kyocera is ready
no entries
> and then
>
> lpq -P [name-of-
# lpq -h artus -P kyocera
kyocera is ready
no entries
>
> This wouldn't be first time I see this.
I don't think this is the problem, but thanks for your guess.
>
> --
> Trying to Print produces lpr: Bad Request
> https:/
>
>
sbothe (ubuntu-sbothe) wrote : Re: Trying to Print produces lpr: Bad Request | #8 |
Hi,
again - Playing around with the command line tools I found the following:
cupsdoprint -P <printer> -H <host> <file>
=> client-
swapping the options Printer and Host,
cupsdoprint -H <host> -P <printer> <file>
produces normal printout. Can anyone confirm? This seems to be very strange, but perhaps solves the problem.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #9 |
Are you sure about that? Does it work for the other people affected by this problem (using both Ubuntu and Kubuntu) ?
sbothe (ubuntu-sbothe) wrote : | #10 |
I'm very confused about that as well, but I tried several times and the behaviour does not change. Even when using lpq I get,
# lpq -h artus -P kyocera
kyocera is ready
no entries
# lpq -P kyocera -h artus
lpq: Unable to connect to server
Very strange..
Manuel López-Ibáñez (manuellopezibanez) wrote : | #11 |
Could you ask your colleagues using other distributions (Suse and Debian Unstable I think you mentioned) to try both commands and also which version of CUPS they are running ?
I am trying to figure out if this is just an Ubuntu issue and from which version of CUPS the problem originated.
Thanks.
sbothe (ubuntu-sbothe) wrote : | #12 |
Hi,
the SuSE Boxes use cups-client-
I took a closer look at what I did on the Kubuntu System and noticed I always executed those two commands in same sequence. What I was not able to see by doing so ist that executing the command twice produces output and is not dependend on argument order. Sorry about the misleading information.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #13 |
I am sorry, your last paragraph lost me completely... do you mean that if you execute "lpq -P kyocera -h artus" twice, the second time it works?
That would be too weird...
Manuel López-Ibáñez (manuellopezibanez) wrote : | #14 |
With respect to the other distribution, they are using an older version of cups (1.1) than dapper (1.2). Now the question is if the bug was introduced by Ubuntu or it is present in the original cups 1.2.0
Also, I made a little error before. Could you check /var/log/
sbothe (ubuntu-sbothe) wrote : | #15 |
Sorry for delaying, I left before I saw your last post- The Cups log on Server maschine says:
E [14/May/
Does this bring us any further? Would increasing log level be of interest?
Manuel López-Ibáñez (manuellopezibanez) wrote : | #16 |
Well, now we know that the client reaches the printer host. It must be some protocol problem between both. However it is kind of weird that repeating the command (or swaping the command options) works.
You may try to change the debug level in the server machine:
o Edit the file /etc/cups/
o Change the line LogLevel from "info" to "debug" .
o Restart cupsd: killall -HUP cupsd
Also, please do two trials in a row (you said that the first one doesn't print while the second one does...)
Martin Pitt (pitti) wrote : | #17 |
Please restart cups with
sudo /etc/init.d/cupsys restart
killall -HUP will most likely not work.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #18 |
Martin, the server is using Debian, which is the appropriate command to restart cupsd in Debian?
Ante Karamatić (ivoks) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request | #19 |
On Mon, 15 May 2006 09:27:43 -0000
manu <email address hidden> wrote:
> Martin, the server is using Debian, which is the appropriate command
> to restart cupsd in Debian?
/etc/init.d/cups* restart
--
Ante Karamatic | 0xD3BDA225 | 0x0A4A0161
<email address hidden> | <email address hidden> | ivoks.blogspot.com
"Tomorrow is my day off, so please stay off the powder!"
sbothe (ubuntu-sbothe) wrote : Re: Trying to Print produces lpr: Bad Request | #20 |
This is the server log generated while "processing" a print job from the kde print dialog. Result is no output. I will try to get a track of a successful print with repeated execution now, may take a moment..
Thanks for your help!
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
I [15/May/
I [15/May/
I [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
sbothe (ubuntu-sbothe) wrote : | #21 |
ok, here is a track of two times in row execution- To make more fun this time the first trial of "cupsdoprint -P kyocera -H artus print.ps" generated a printout and the second one not. I don't know what to say about this any further, the behavior seems to be some kind of undeterministic :-(
Perhaps you can figure out what goes wrong here, these are the entries in error_log..
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
I [15/May/
I [15/May/
I [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
Manuel López-Ibáñez (manuellopezibanez) wrote : | #22 |
Hmm, next time, please, put the log in a file and attach it.
The job in the first log fails from a problem in the postscript (I think). Relevant lines:
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
D [15/May/
The second job of the second log fails for an unknown reason:
D [15/May/
D [15/May/
E [15/May/
D [15/May/
D [15/May/
Both are the same postscript file, isn't it?
Perhaps relevant to this is bug 41593.
sbothe (ubuntu-sbothe) wrote : | #23 |
Sorry for the "bulk" data above, I posted through web interface, I'll use email with attachment next time.
The first log (single execution) is produced by print dialog of kde, trying to print first page of an pdf document. Second log (two executions) is generated by printing first page of the same pdf to a ps and using cupsdoprint from a console manually. The kdeprinting generates a temporary ps as well.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #24 |
You can attach files through the web interface (Menu on the top-left "Add attachment").
sbothe (ubuntu-sbothe) wrote : | #25 |
Hello again,
I can workaround with a local printer queue that points to the ipp printer on the printserver. - Only as a remark if someone reads this thread and needs a working printer soon..
Ulrich Lukas (ulrich-lukas) wrote : Re: Same problem, same behaviour | #26 |
Hi!
I can confirm this problem and the strange behaviour that it matters in which order the arguments are passed to "cupsdoprint".
"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps"
==> "client-
"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"
==> normal printout
I would consider this a serious bug, because printing is a very common task...
My CUPS-Version:
"cupsys 1.2.0-0ubuntu5"
My system ist Dapper Drake as at today, 29.05.2006.
Best wishes,
Ulrich
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request | #27 |
confirmed by several users
Changed in cupsys: | |
status: | Unconfirmed → Confirmed |
Manuel López-Ibáñez (manuellopezibanez) wrote : | #28 |
Ulrich, please, read the whole thread.
Do you get the same errors in the logs?
What is the version of your cups server?
The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?
Thanks.
blaise (blaise-vogel) wrote : | #29 |
I have the same bug.
1. First print order have the bug
2. Second print order is ok !!
Manuel López-Ibáñez (manuellopezibanez) wrote : | #30 |
blaise, please, could you read the whole thread and answer the following questions?
Do you get the same errors in the logs?
What is the version of your cups server?
The initial reporter said that executing the command twice produces output, is it the same for you?
Thanks.
blaise (blaise-vogel) wrote : | #31 |
client: kubuntu dapper up to date
server: debian sarge - cupsys 1.1.23-10sarge1
Same error in the log, executing the command twice produces output !
Manuel López-Ibáñez (manuellopezibanez) wrote : | #32 |
Thanks blaise, this seems to confirm that it is an interaction issue between cups client version 1.2 and cups server version 1.1
I am not sure if raising the severity level is proper, since there exists an obvious workaround. Also, it may not depend on Ubuntu but rather upstream to fix this bug.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #33 |
If someone has time, he/she could search upstream ( http://
Ulrich Lukas (ulrich-lukas) wrote : | #34 |
Hi,
manu wrote:
> > Do you get the same errors in the logs?
If I do a "cat /var/log/
file is empty.
The /var/log/
attachement of this posting. (Only the lower part of the file should be
of interest)
> > What is the version of your cups server?
The CUPS-Version on the server is:
cupsys 1.1.23-15 (Debian testing)
> > The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?
I tried it some more times, and in fact, it is a bit weird:
If I try to print with this commandline:
"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps",
it actually works after about five to ten invocations. It works one or
two times, and then again there is the message
"client-
If I use exactly this command:
"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"
Then it seems to always work.
YES, the file "n.ps" is listed two times! Maybe only that is the
important thing (sporadic error/timing problems...) and not the order.
HTH,
Ulrich
Ulrich Lukas (ulrich-lukas) wrote : | #35 |
Hi,
manu wrote:
> > Do you get the same errors in the logs?
If I do a "cat /var/log/
file is empty.
The /var/log/
> http://
(Only the lower part of the file should be of interest)
> > What is the version of your cups server?
The CUPS-Version on the server is:
cupsys 1.1.23-15 (Debian testing)
> > The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?
I tried it some more times, and in fact, it is a bit weird:
If I try to print with this commandline:
"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps",
it actually works after about five to ten invocations. It works one or
two times, and then again there is the message
"client-
If I use exactly this command:
"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"
Then it seems to always work.
YES, the file "n.ps" is listed two times! Maybe only that is the
important thing (sporadic error/timing problems...) and not the order.
HTH,
Ulrich
Manuel López-Ibáñez (manuellopezibanez) wrote : | #36 |
Ulrich, please, could you use the web interface to add the file as an attachment using the top-left menu. I hope you understand that external files have the bad habit of suddenly dissapearing. Thanks in advance.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #37 |
There is a patch here (found in bug 42802):
http://
This may or may not fix the issue. It seems this patch will be available in cups 1.2.1, not sure if it is already included in Ubuntu's version. If somebody can build an experimental deb package using this patch and attach it, others could test if it fixes the problem. Unfortunately, I have no experience building debian packages (yet).
Ulrich Lukas (ulrich-lukas) wrote : error_log | #38 |
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request | #39 |
As the current release cups 1.2.0-0ubuntu5, that patch has not been applied (see Changelog at:
http://
Manuel López-Ibáñez (manuellopezibanez) wrote : | #40 |
Thanks Ulrich, I am 99% sure that it is the same issue.
Tom Albers (tomalbers-deactivatedaccount) wrote : | #41 |
Ok, I'm no pro in building packages, but I've rebuild them with the patch on that url. Consider them experimental. I can only try them tomorrow, but here they are: http://
Again:unofficial, experimental.
Steffen Neumann (sneumann) wrote : | #42 |
Thanks Tom for the packages, they solved my problem printing from dapper cups-1.2 client to a cups-1.1.x server as well. Investigating my problem earlier I found a few bug reports in launchpad that sounded similar, so a fix for dapper (at least -updates) should have a high priority.
Yours,
Steffen
Tom Albers (tomalbers-deactivatedaccount) wrote : | #43 |
My packages dont work for me though. Changing the paramaters did not change anything either. Out of the ten tries, one succeeded:
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-
Manuel López-Ibáñez (manuellopezibanez) wrote : | #44 |
Geo_KM and Ulrich, could you test the packages kindly built by Tom? Test them for one or two days before reporting just to be sure that they fix the issue. Thanks.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #45 |
Oh, bad luck then. It is strange that they work for Steffen, though. And please, get out of your mind the crazy idea that the fix will make into Dapper. It is delusional. Not even the craziest maintainer will add stuff to his package one or two days before release. Moreover, when there is no confirmation at all that the stuff does fix anything. I hope you understand.
Ulrich Lukas (ulrich-lukas) wrote : | #46 |
I'm sorry, but the patched packages don't work for me, too.
The error message seems to be the same, basically. I've added the new error_log from the server machine.
Ulrich Lukas (ulrich-lukas) wrote : error_log | #47 |
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request | #48 |
Ulrich, next time please, use a different name for the file (for example, error_log_
Ulrich Lukas (ulrich-lukas) wrote : Bug report on www.cups.org | #49 |
This bug is already listet on www.cups.org under STR #1717.
> http://
(Btw.: http://
Manuel López-Ibáñez (manuellopezibanez) wrote : | #50 |
Another try, Ante Karamatić has packaged CUPS 1.2.1 for Dapper [*]. Again, this is *experimental*, install it *at your own risk*.
Ante Karamatić (ivoks) wrote : | #51 |
This packages shouldn't fix this issue. It's worth to try, but I don't guarantee anything. Anyway, report chagnes.
Tom Albers (tomalbers-deactivatedaccount) wrote : | #52 |
Packages at http://
Ante Karamatić (ivoks) wrote : | #53 |
That was expected. This packages weren't ment to resolve this bug. Upstream is aware of this problem and it's solution is pending, so best thing is to wait untill fix is released.
Claudio Bernardini (claudiob) wrote : | #54 |
I can confirm the bug as I upgraded all my clients machines from Breezy to Dapper. Now we cannot print anymore to a 1.1.2x cups server over IPP. I think our solution, while waiting for a fix, is to point directly to the printers from the clients.
Geo_KM (keith-barnabasmusic) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request | #55 |
Hi Sorry for the delay.
Yeah, these did not fix the problem for me either...... 8-(
On Wednesday 31 May 2006 18:07, manu wrote:
> Geo_KM and Ulrich, could you test the packages kindly built by Tom? Test
> them for one or two days before reporting just to be sure that they fix
> the issue. Thanks.
Ante Karamatić (ivoks) wrote : | #56 |
Please, take a look at bug 45099 and my comments for problems with printing to CUPS <1.2 servers.
Jordi Mallach (jordi) wrote : | #57 |
Claudio, what do you mean with "point directly to the printers"?
I'm having this problem at the office, have tried several changes to our ocnfig but no luck just yet.
Claudio Bernardini (claudiob) wrote : Re: [Bug 42513] Re: client 1.2.0 to 1.1.2x server over IPP: client-error-bad-request | #58 |
Il giorno mer, 05/07/2006 alle 12.29 +0000, Jordi Mallach ha scritto:
> Claudio, what do you mean with "point directly to the printers"?
>
> I'm having this problem at the office, have tried several changes to our
> ocnfig but no luck just yet.
I think I had a setting in /etc/cups/
jobs to a cups server (don't remember cups version... was on SuSE 8.2)
my ubuntu machines. I checked right now the man for cupsd but cannot'
find it. I removed the line pointing to the server and activated auto
finding of lan printers, everything then went ok and we could print
happily. May not be so helpful but I don't remeber more and far away to
check comments I left in the conf. Sorry.
Just it happened upgrading client machines from hoary to dapper.
Ante Karamatić (ivoks) wrote : | #59 |
@Claudio
Hoary -> Dapper isn't supported. The file you are talking about is /etc/cups/
ServerName IP_OF_YOUR_SERVER
Jordi Mallach (jordi) wrote : | #60 |
I have managed to make it work changing the DeviceURI of my printer to use http as a protocol.
DeviceURI http://
This works flawlessly.
Claudio Bernardini (claudiob) wrote : | #61 |
Il giorno gio, 06/07/2006 alle 06.42 +0000, Ante Karamatić ha scritto:
> @Claudio
>
> Hoary -> Dapper isn't supported. The file you are talking about is
> /etc/cups/
>
> ServerName IP_OF_YOUR_SERVER
Yes you are right, that was the file.
Sorry but I am away and could not check.
Claudio Bernardini (claudiob) wrote : | #62 |
Il giorno gio, 06/07/2006 alle 10.27 +0000, Jordi Mallach ha scritto:
> I have managed to make it work changing the DeviceURI of my printer to
> use http as a protocol.
>
> DeviceURI http://
>
> This works flawlessly.
After the upgrade of Dapper today I cannot print anymore on the cups
server from ubuntu dapper clients.
You mean you solved changing the DeviceURI of the printers automatically
discovered from the cups browser on the client side?
Thanks
--
Claudio Bernardini <email address hidden>
COMVERT
Ante Karamatić (ivoks) wrote : | #63 |
Claudio, check /var/log/
Claudio Bernardini (claudiob) wrote : | #64 |
Ante, I checked /var/log/
When I print the test page from the dapper client a blank page comes out of the printer.
Claudio Bernardini (claudiob) wrote : | #71 |
Sorry for the duplicate posts above (if someone with admin permission can remove them I am thankful).
The problem I was experiencing after last updates was definitely mine and NOT related to cups on Dapper. For me it is solved.
Fabien (fabien-ubuntu) wrote : | #72 |
Hi, I have exactly the same troubles (ubuntu cups 1.2 client trying to print on debian sarge 1.1 server).
Sending the same command will result in random errors (2 on 10 succeded).
Cups released a fix yesterday in their svn repository :
http://
<<
mike
13:57 Jul 18, 2006 Fixed in Subversion repository.
>>
Could we hope to get updated packages for that ?
Thanks.
Fabien (fabien-ubuntu) wrote : | #73 |
Finally, I decided to build myself the packages with the patch.
I installed them and it fixed the problems I had.
Here are the package files I built (they work for me, but no warranty !) :
http://
FYI, here's the patch :
--- cups-bogus/
+++ cups/cups/http.c
@@ -1809,6 +1809,16 @@
return (1);
/*
+ * Flush pending data, if any...
+ */
+
+ if (http->wused)
+ {
+ if (httpFlushWrite
+ return (0);
+ }
+
+ /*
* If not, check the SSL/TLS buffers and do a select() on the connection...
*/
Martin Pitt (pitti) wrote : | #74 |
Fabien, thanks for the link to the upstream fix. This looks appropriate for dapper-updates.
Changed in cupsys: | |
assignee: | nobody → pitti |
status: | Confirmed → In Progress |
assignee: | nobody → pitti |
status: | Unconfirmed → In Progress |
Martin Pitt (pitti) wrote : | #75 |
cupsys (1.2.2-0ubuntu1) edgy; urgency=low
.
* Merge to Debian unstable:
- This gets rid of /etc/cups/conf.d/ again and re-merges the separate
browsing and ports settings to /etc/cups/
was nice for preserving an unchanged conffile for the most important
settings, but it broke KDE and the web interface and generated way too
many bugs. Closes: LP#37892, LP#50804, LP#53582
* Update to new upstream version 1.2.2 (UVF exception granted by by Matt
Zimmerman):
- Fixes printing to 1.1.x servers. Closes: LP#42513, LP#42802
- Fixes parsing of some PostScript files which previously generated empty
pages. Closes: LP#51432
- Fixes parsing of network masks. Closes: LP#52390
- Lots of more fixes, see upstream changelog.
* debian/
Breezy->Dapper upgrade.
* debian/control: Add libdbus-1-dev build dependency to enable dbus support.
* debian/
them).
* cupsys.postinst: Fix permissions of cupsd.conf to be writable by user
cupsys world-readable.
* debian/
to new single configuration file format.
* debian/rules: Clean cups/raster.h symlink to unbreak source package build.
* Add debian/
default to avoid open port and stay compatible to previous releases.
Changed in cupsys: | |
status: | In Progress → Fix Released |
Martin Pitt (pitti) wrote : | #76 |
cupsys (1.2.2-
.
* New upstream bugfix release:
- Fixes printing to 1.1.x servers. Closes: LP#42513, LP#42802
- Fixes parsing of some PostScript files which previously generated empty
pages. Closes: LP#51432
- Fixes parsing of network masks. Closes: LP#52390
- Lots of more fixes, see upstream changelog.
* Dropped debian/
* debian/
debian/
version (taken from current edgy package).
Changed in cupsys: | |
status: | In Progress → Fix Released |
Could you check the differences in /var/log/ cups/error_ log before and after you do "lpr 1.ps returns" (wait until you get the error message) ? Thanks.