I should probably point out that this system was upgraded from Oneiric,
and that on first-boot, I had several problems with both Empathy's
account manager and colord crashing (both reported with apportd). In
the end, I had to selectively clear .folders (.gnome2, .local, .cache
and .gconf?) to fix
I also have this problem with gnome-terminal (Precise x64, Intel
graphics). I tested Unity 2D just now though, and that does not have
this problem. On logging back out and into standard Unity, the problem
seems to be fixed.
--
You received this bug notification because you are a member of Ubunt
I have filed this upstream at http://www.cups.org/str.php?L3985, so
hopefully we can get this fixed in CUPS 1.5 without having to downgrade
the IPP backend to 1.4.x (as the oneiric-proposed package does).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
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://www.cups.org/str.php?L3986:
This is the original bug regarding Novell print servers, and the patch
is the same a
For reference, this has been filed upstream at
http://www.cups.org/str.php?L3974.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/883585
Title:
Kubuntu 11.10 -- Network/Local Printers found but cannot
This has been filed upstream at http://www.cups.org/str.php?L3974, which
covers both this bug and #883585. Unlike bug #883585, the bug here
seems to be fixed by the IPP backend downgrade in 1.5.0-8ubuntu6.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Stefan: I don't know if this will help at all, but there's a suggestion
at http://www.makestuff.eu/wordpress/?p=1747 about blacklisting the
usblp module. Perhaps that might be worth trying?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Till: Wireshark will only be of use in the network printer case
(IPP/HTTP, LPR or SMB). Its value is in being able to see exactly what
is being transmitted and received from the print server. You can then
use that to get a better understanding of what is going on.
The way to use it is to start W
Duck Tayp: would it be possible for you to attach those wireshark logs
please? I'm wondering if there's something going on like an unsupported
authentication type (Digest authentication maybe?), in addition to the
issue the last patch covered.
--
You received this bug notification because you ar
The patch attached to this comment won't fix the problem, but will test
if there is an issue with URI assembly in CUPS 1.5. Could one of you
please try applying this and send the resulting CUPS debug logs from the
client?
** Patch added: "Add logging to httpSeparateURI and httpAssembleURI API cal
>From #10, it still looks like CUPS is sending a printer URI of
"http://192.168.1.7:631/Stylus_Photo"; to the NAS for some reason - but
only for the Get_Printer_Attributes call, *not* for Print_Job! If this
were not true, we should be seeing "print_job: resource name
'/Stylus_Photo' no good!" in y
So, what we seem to have here is essentially (Debian's?) CUPS 1.1.14 IPP
server breaking with 1.5 clients (or most likely vice versa). That
would make this bug far easier to reproduce, at least. In theory, I
could try setting up a Woody VM as a print server and play with that if
I can still find
Adding to my last comment, after Googling for a bit, there's also this:
http://www.livingonthecloud.net/2011/08/mac-os-x-lion-and-cups-
printing.html
The suggestion there seems to be that creating a class that contains
your printer *might* somehow help. I'm not convinced, personally, but
it's pr
There's a similar discussion about OS X Lion at the ReadyNAS forums, too
(http://www.readynas.com/forum/viewtopic.php?f=28&t=56877). The fix
there was also to use SMB instead of IPP.
The interesting thing though is that the ReadyNAS Duo apparently has
open-source firmware (http://www.readynas.com
David,
Having checked those packet logs again, I did notice one difference.
The requested URI for Oneiric appears to be "ipp://druckerraum-
laser1.ethz.ch:631/" and not "ipp://druckerraum-
laser1.ethz.ch:631/ipp/". Could you quickly check that it is set the
same as in Natty please?
Thanks in adv
If I'm not mistaken, using dpkg-buildpackage would give you a source
package that applies the patch, but you would still have to build the
source anyway.
The way I did it is by doing:
mkdir cups-source
cd cups-source
apt-get source cups
cd cups-1.5.0
patch -p1 < patchfile
./configure
make
sudo ma
Hi David,
Sorry about my recent silence. At the moment, I have not been able to
reproduce the error here (fortunately for me, unfortunately for everyone
else). There do seem to be a lot of similar sounding bugs around though
(TaffyDownUnder's bug, and the latest bug over at #881843), all
resulti
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 r
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.168.1.1:631/ipp/printer?nohttpchunking=yes
ipp://192.168.1.1:631/ipp/printer?nohttpchunking=yes&v
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 ou
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 dat
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
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 ha
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 is
Chris, would you be willing to test the attached patch on your system
and see if it works for you? In my test, test prints from the
"Printing" applet did not prompt for the username/password, but printing
from gedit etc. did prompt.
** Patch added: "Patch to set auth_info_required="username,passw
Thanks Chris - I haven't started looking yet, but I should be able to
recreate a similar setup here quite easily for testing (Lucid server,
Oneiric client). With no TLS, it will be straightforward to see what is
happening at the wire level too - but I don't expect that I will gain
much from that.
Dear David,
I did not see anything obviously different between the two TCP dumps,
unfortunately. I can't see what could cause the printer to stop
printing!
Regards,
Robert
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
Thanks - now it's time for me to figure out why nothing changed!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/881843
Title:
CUPS IPP print to Novell servers error since 11.10 upgrade
To manage not
Is that with or without the nohttpcontinue option (URI
ipp://192.168.1.1/ipp?nohttpcontinue=yes)? At the moment, it looks
near-identical to the previous log - the patches did nothing! :(
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
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
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
Actually, before testing the patch in my previous comment, try changing
your printer URI to "ipp://192.168.1.1:631/ipp?version=1.0" briefly, and
see if that works. If it does, then we know it's a protocol version
issue, and testing the patch would then make sense.
I also think it might be worth m
Does this happen if you use IPP without TLS too?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/879625
Title:
CUPS fails to request authentication when printing over IPP w/ TLS
To manage notificatio
I have no good ideas off-hand, but I might be able to get some hints
from tcpdump/Wireshark packet logs, as I did with bug 881843.
HPO/David: would either of you be willing/able to get packetlogs of the
IPP session (using "sudo tcpdump -i eth0 -p -w packetlog port 631")? I
would need one from the
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_NOT_SUPPORTED, which
is u
Hi Thierry,
Yes, please! :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/881843
Title:
CUPS IPP print to Novell servers error since 11.10 upgrade
To manage notifications about this bug go to:
htt
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 th
Better make that "sudo tcpdump -i eth0 -p -w packetlog port 631" (or
alternatively, use Wireshark with capture filter "port 631").
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/881843
Title:
CUPS IP
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
--
You received this bug no
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 T
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 add
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 buildin
OK, as a quick fix, I have effectively replaced backend/ipp.c with the
1.4.x version (branches/1.4.x/backend/ipp.c, r8950), with the patch
included below. One line was changed in order to get the code to
compile as part of 1.5:
--- ipp-1.4x.c 2011-10-27 16:50:04.
Quick update:
The bug is now filed upstream as requested
(http://www.cups.org/str.php?L3967+Qversion:1.5). I also attempted to
force validate_job to zero in backend/ipp.c, as I suggested earlier. So
far, however, the result of that was to get "server-error-service-
unavailable" errors when the a
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_cancel
45 matches
Mail list logo
