Version: (using KDE KDE 3.4.2) Installed from: Fedora RPMs Compiler: GCC 4.0.1 OS: Linux KDE is unable to connect to cupsd using the new domain socket supported by CUPS 1.2, returning instead an error message that the printing system is broken. In looking at the kdeprint code, it appears that you are not using the CUPS API and thus are missing out on the automatic support for new CUPS features as they become available. Aside from missing domain socket and (I'm guessing) IPv6 support, you also don't seem to support collection attributes which will be necessary to support the new per-page option support... Anyways, you need to add domain socket support to kdeprint in order to stay compatible with CUPS.
On 7 November 2005 22:00, Michael Sweet wrote: > In looking at the kdeprint code, it appears that you are not using the CUPS > API and thus are missing out on the automatic support for new CUPS features > as they become available. I am aware. This is one of the first items in my work plan. It will require some time though. Thanks for reporting.
Note that the normal way of doing is through the use of httpConnect() from CUPS, but I introduced a pre-connection through the use of KDE framework. The problem was that I got a lot of bug reports of GUI freezing: the freeze occured in httpConnect, which probably was waiting for some network timeout instead of returning NULL directly. As the CUPS calls are done synchronously, it froze the interface. After getting a lot of complained, I introduced this ugly hack using asynchronous KDE network API. After this pre-connection has been done, normally all other connections are done through regular CUPS API. Michael.
There are several other options (background worker threads, alarm(), etc.) that will also work. Anyways, if you try to initialize the http_t structure yourself, you WILL be incompatible with CUPS 1.2 (and in fact any update to CUPS which changes the size of the http_t structure)... I'd much rather provide an asynchronous API in CUPS or have you use a worker thread than use private interfaces and backdoors to get things working the way you want...
Hi, don't know if this is related, but in order to be able to compile kdeprint (from kde 3.5 rc2 sources) against cups 1.2 (1.0190 precisely), I had to modify the file cups-util.c, line 445 replace: if (ntohl(*(int*)&http->hostaddr.sin_addr) != 0x7f000001 && with: if (ntohl(*(int*)&http->_hostaddr.sin_addr) != 0x7f000001 && since cups has changed the http_t structure... David
It is not related directly, however it is another piece of KDE code that uses private CUPS state data. None of the KDE code should be making any assumptions about the address used to connect to the CUPS server, as that breaks network independence...
Concerning the file cups-util.c, at the time that code was written, it was not possible to request/send the CUPS configuration file through regular CUPS API, which is the reason of the existence of that code. Now I guess this is possible so the cupsGetConf() and cupsPutConf() could probably re-written in terms of current CUPS API. Michael.
commit fix with revision 529105
Now I will say, it is mostly way to make the things better. But not a finally fix. Sorry. new domain socket support will follow. Reporter, can you please point me in rigth direction. How to configure CUPS connection over domain socket?
Pass the domain socket path as the server name, e.g. "/var/run/cups/cupsd.sock".
Hello, i think such assumption is not good; in "http-addrlist.c:httpAddrGetList(..." if (hostname && hostname[0] == '/') { /* * Domain socket address... */ For ignoring of port parameter I must duplicate this code at any point, where I handle with host addres. As developer I would prefer presence of function looks like int httpAddrLocalhost(...). Let name it int httpAddrUNIXDomainSocket(...) Regards Alex
Hi, for info. Error is causing by not using of CUPS services to ping a server, but QSocket btw. KExtendedSocket. At GUI side UI manager always adds default CUPS port 631 to any host address without port value. Solution introduces const QString CupsInfos::hostaddr() const in cupsinfos.cpp. This metode will be used, where "host:port" or "host" should be visible or passed as params. This is the only place, where I assume string[0] == '/' >> "UNIX domain socket". This should be updated, if CUPS will extend the API. Ping a server is changed to use httpConnect() directly. Fixes are committed to trunk. Port to kde3 is ready but I would like to wait for responce about current solution. Regards Alex
I need a more sleep ;-( It's committed now to snapshot of trunk/KDE/kdelibs. Would it be erased by next sync? Please drop me a mail
httpAddrLocalHost will crash if the http->hostaddr passed to it is null (as seems to be the case for domain sockets), maybe this would work: if ((http->hostaddr && !httpAddrLocalhost(http->hostaddr)) || http->hostname[0] != '/') Alex, do you have an idea why the code duplicates cupsys/cups/auth.[ch]? Maybe it would be better to reimplement it in terms of this cups API to be more future-proof?
It is in my eyes one more vote for introduce of int httpAddrUNIXDomainSocket(const http_t *http) { return (http->hostname && http->hostname[0] == '/')?1:0; } That we can do if (!(httpAddrUNIXDomainSocket(http) || httpAddrLocalhost(http->hostaddr))) ... One more question, Michael, why an user of interface, should know, that http->hostaddr is NULL for domain socket? Would interface like "httpAddrLocalhost(const http_t *http)" to be more user friendly and internal API changes proof?
(not sure why, but I don't see my previous post to this bug report - short summary is you should be using cupsDoAuthentication() and not rolling your own, as otherwise you will not work when CUPS changes under the covers, like it did in 1.2) First, a httpAddr*() function will only take http_addr_t arguments, not http_t. Second, why do you even need to know the type of socket, once connected? Third, the existing httpGetHostname() API allows you to get the hostname (or IP address, or domain socket filename) associated with a http_t connection. From there you can look to see if the hostname starts with a /. Finally, current CUPS code has explicit checks for NULL http_addr_t * arguments and "does the right thing" with httpAddrLocalhost().
Ok, i will look over cupsDoAuthentication(). httpAddr*(http_addr_t) makes sence. Thanks. > why do you even need to know the type of socket, once connected? Application does not know nothing about socket or not socket. All what I have is a string with server address and int with port number. And I should decide: create a visible string(GUI) or argument for extern applications(cupsdoprint) like "server:port" or "server". cupsdoprint for example refuses to accept "/var/run/cups/cupsd.sock:0" as valid address. And does not look smarter too.
Well, if you use "cupsSetServer()", then "host-or-ip", "host-or-ip:port", and "/path/to/domain/socket" will all work automatically - cupsSetServer() calls ippSetPort() as needed... As for the UI, IMHO you should just accept hostname or IP address and a port - if blank, it should use the default (nornally a domain socket, but sometimes localhost on port 631) - it is unlikely that you'd use more than one domain socket on a system, and if you did the CUPS_SERVER environment variable could be used to pass the default domain socket while your UI could be used to talk directly to different print servers rather than the default/local print server.
Suggestion for CUPS: store the Unix address in the service/port variable and keep hostname == NULL or empty to indicate localhost. This is how KDE and glibc (getaddrinfo) work.
I've compared the current KDE code to cupsDoAuthentication() and it looks like the KDE code is an almost exact copy of it. It would make bugfixing and maintenance easier if the current authorization code in cups-util.c (cupsGet/PutConf, cups_local_auth) could be replaced by the cups one. Maybe someone knows why the KDE code was copied and used instead?
Yes, I have sorted it already out. I will commit today.
Here's the current set of patches used by Kubuntu and done by Michael Hofmann http://kubuntu.org/~jriddell/kdeprint/
I've got bug in IPrint in kdeprint/cups/ipprequest.cpp. My workaround for this is - sed -i 's/_ipp_free_attr(attr2);/delete attr2;/' /cups/ipprequest.cpp. This not correct but works . Possible suggestion is to use extern void ippDeleteAttribute(ipp_t *ipp, ipp_attribute_t *attr); from <cups/ipp.h> rather than _ipp_free_attr.
This has been fixed for a month now.
I still get this from branches/3.5 as of today when using cups 1.2.0: """ Unable to retrieve the printer list. Error message received from manager: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: connection refused """ The "kcmshell Printers" dialog displays a rather strange address for the server: /var/run/cups/cups.sock:631 It can connect to the server on both /var/run/cups/cups.sock (without the :631, obviously) or alternatively on 127.0.0.1:631 -- a hacked telnet command that connects to unix sockets as well as normal ones shows the expected cups output from both telnet localhost 127.0.0.1 631 and telnet /var/run/cups/cups.sock
using kde-3.5.3 built from source with cups-1.2.1, the problem still exists Control centre reports: Unable to retrieve the printer list. Error message received from manager: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: host not found Server=/var/run/cups/cups.sock:631
I can confirm the exact same error on ArchLinux with kde-3.5.3 and cups-1.2.1.
Saw this blog: http://www.kdedevelopers.org/node/1901 So is this problem being worked on?
@ commentator #24, #25 and #26: ------------------------------- Please check your server's cupsd.conf.... What's the output of grep -v ^# /etc/cups/cupsd.conf | grep -v ^$ when run on the CUPS server? Do you have 2 different "Listen" (or "Port") statements included there, where one is naming a Unix Domain Socket (file), the other one a TCP/IP socket? [Hint: domain socket support was newly introduced with CUPS 1.2.0, and was unknown to KDE/KDEPrint until very recently...] Try to move the domain socket line *below* all other "Listen" or "Port" statements in cupsd.conf. Does that help? [ I'm sorry, I can't even try to reproduce this problem currently; at the moment I've no Linux or KDE system I could use for this (notebook was stolen, and a lottery win for me is just not happening) -- so what I say is just from my fading memory.... ] Cheers, Kurt
SVN commit 586782 by mueller: CUPS 1.2.x unix socket support (BNC #204453) BUG: 115891 M +39 -19 kmcupsmanager.cpp M +5 -2 kmcupsmanager.h M +1 -1 kmcupsuimanager.cpp --- branches/KDE/3.5/kdelibs/kdeprint/cups/kmcupsmanager.cpp #586781:586782 @@ -45,12 +45,14 @@ #include <klocale.h> #include <kconfig.h> #include <kstandarddirs.h> +#include <ksocketbase.h> #include <klibloader.h> #include <kmessagebox.h> #include <kaction.h> #include <kdialogbase.h> #include <kextendedsocket.h> #include <kprocess.h> +#include <kbufferedsocket.h> #include <kfilterdev.h> #include <cups/cups.h> #include <cups/ppd.h> @@ -88,7 +90,7 @@ KMCupsManager::~KMCupsManager() { - //delete m_socket; + delete m_socket; } QString KMCupsManager::driverDbCreationProgram() @@ -135,7 +137,8 @@ { req.setOperation(CUPS_ADD_CLASS); QStringList members = p->members(), uris; - QString s = QString::fromLocal8Bit("ipp://%1:%2/printers/").arg(CupsInfos::self()->host()).arg(CupsInfos::self()->port()); + QString s; + s = QString::fromLocal8Bit("ipp://%1/printers/").arg(CupsInfos::self()->hostaddr()); for (QStringList::ConstIterator it=members.begin(); it!=members.end(); ++it) uris.append(s+(*it)); req.addURI(IPP_TAG_PRINTER,"member-uris",uris); @@ -907,25 +910,23 @@ QString KMCupsManager::stateInformation() { - return QString("%1: %2:%3") + return QString("%1: %2") .arg(i18n("Server")) - .arg(CupsInfos::self()->host()) - .arg(CupsInfos::self()->port()); + .arg(CupsInfos::self()->hostaddr()); } void KMCupsManager::checkUpdatePossibleInternal() { kdDebug(500) << "Checking for update possible" << endl; delete m_socket; - /*m_socket = new KExtendedSocket( CupsInfos::self()->host(), CupsInfos::self()->port() ); - connect( m_socket, SIGNAL( connectionSuccess() ), SLOT( slotConnectionSuccess() ) ); - connect( m_socket, SIGNAL( connectionFailed( int ) ), SLOT( slotConnectionFailed( int ) ) ); - m_socket->setTimeout( 1 );*/ - m_socket = new QSocket( this ); - connect( m_socket, SIGNAL( connected() ), SLOT( slotConnectionSuccess() ) ); - connect( m_socket, SIGNAL( error( int ) ), SLOT( slotConnectionFailed( int ) ) ); - trials = 5; - QTimer::singleShot( 1, this, SLOT( slotAsyncConnect() ) ); + m_socket = new KNetwork::KBufferedSocket; + m_socket->setTimeout( 1 ); + connect( m_socket, SIGNAL( connected(const KResolverEntry&) ), + SLOT( slotConnectionSuccess() ) ); + connect( m_socket, SIGNAL( gotError( int ) ), SLOT( slotConnectionFailed( int ) ) ); + + trials = 5; + QTimer::singleShot( 1, this, SLOT( slotAsyncConnect() ) ); } void KMCupsManager::slotConnectionSuccess() @@ -959,7 +960,10 @@ { kdDebug(500) << "Starting async connect" << endl; //m_socket->startAsyncConnect(); - m_socket->connectToHost( CupsInfos::self()->host(), CupsInfos::self()->port() ); + if (CupsInfos::self()->host().startsWith("/")) + m_socket->connect( QString(), CupsInfos::self()->host()); + else + m_socket->connectToHost( CupsInfos::self()->host(), CupsInfos::self()->port() ); } void KMCupsManager::slotConnectionFailed( int errcode ) @@ -975,9 +979,25 @@ return; } - setErrorMsg( i18n( "Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. " - "Error: %1." ).arg( errcode == QSocket::ErrConnectionRefused ? i18n( "connection refused" ) : i18n( "host not found" ) ) ); - setUpdatePossible( false ); + QString einfo; + + switch (errcode) { + case KNetwork::KSocketBase::ConnectionRefused: + case KNetwork::KSocketBase::ConnectionTimedOut: + einfo = i18n("connection refused") + QString(" (%1)").arg(errcode); + break; + case KNetwork::KSocketBase::LookupFailure: + einfo = i18n("host not found") + QString(" (%1)").arg(errcode); + break; + case KNetwork::KSocketBase::WouldBlock: + default: + einfo = i18n("read failed (%1)").arg(errcode); + break; + } + + setErrorMsg( i18n( "Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. " + "Error: %2: %1." ).arg( einfo, CupsInfos::self()->host())); + setUpdatePossible( false ); } void KMCupsManager::hostPingSlot() { @@ -1014,7 +1034,7 @@ if (use && !p->uri().isEmpty()) uri = p->uri().prettyURL(); else - uri = QString("ipp://%1:%2/%4/%3").arg(CupsInfos::self()->host()).arg(CupsInfos::self()->port()).arg(p->printerName()).arg((p->isClass(false) ? "classes" : "printers")); + uri = QString("ipp://%1/%3/%2").arg(CupsInfos::self()->hostaddr()).arg(p->printerName()).arg((p->isClass(false) ? "classes" : "printers")); return uri; } --- branches/KDE/3.5/kdelibs/kdeprint/cups/kmcupsmanager.h #586781:586782 @@ -25,8 +25,11 @@ class IppRequest; class KLibrary; class KExtendedSocket; -class QSocket; +namespace KNetwork { + class KStreamSocket; +} + class KMCupsManager : public KMManager { friend class KMWIppPrinter; @@ -95,7 +98,7 @@ private: KLibrary *m_cupsdconf; KMPrinter *m_currentprinter; - QSocket *m_socket; + KNetwork::KStreamSocket *m_socket; bool m_hostSuccess; bool m_lookupDone; }; --- branches/KDE/3.5/kdelibs/kdeprint/cups/kmcupsuimanager.cpp #586781:586782 @@ -135,7 +135,7 @@ QString uri; req.setOperation(CUPS_GET_DEVICES); - uri = QString::fromLocal8Bit("ipp://%1:%2/printers/").arg(CupsInfos::self()->host()).arg(CupsInfos::self()->port()); + uri = QString::fromLocal8Bit("ipp://%1/printers/").arg(CupsInfos::self()->hostaddr()); req.addURI(IPP_TAG_OPERATION,"printer-uri",uri); if (req.doRequest("/"))
Still broken here (cups 1.2.4; tried 3.5.5 w/ timeout fix and SVN 596534). The error message with current SVN is "Unable to retrieve the printer list. Error message received from manager: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: the IPP request failed for an unknown reason." This happens regardless of whether CUPS is listening on a TCP socket, a Unix socket, or both. Using the http://localhost:631 interface, CUPS 1.2.4 is working fine. I've tried running everything as root to exclude the possibility of something stupid (wrong permissions on a socket or the likes) happening, same error.
The problem occurs only when no printer is configured -- ignoring the error and setting up a printer makes it go away. The unknown error seems to be an empty printer list.
it does not work here with non-empty list of printers it was working with cups 1.2.4 on kde 3.5.4 but it is not anymore since i switch to kde 3.5.5 the error is: Impossible d'extraire la liste des imprimantes. Message d'erreur renvoyé par le gestionnaire : Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: localhost: read failed (15). of course cups is running. i can access it through http://localhost:631
3.5.5 regression should be fixed: http://lists.kde.org/?l=kde-commits&m=116048370018140&w=2 http://lists.kde.org/?l=kde-core-devel&m=116133577102517&w=2
The bit about kdeprint not talking to cups 1.2 when the printer list is empty still needs fixing.
Created attachment 18204 [details] Detect no printers case Can people please test this patch, and maybe original reporter can comment but looking at Java/Perl bindings for CUPS 0x406 means no printers.
> Can people please test this patch, and maybe original reporter can comment but > looking at Java/Perl bindings for CUPS 0x406 means no printers. I can confirm this patch solves "no printer" exists issues. But trying to add a printer gaves "client-error-bad-request" errors (with todays KDELIBS branch update), cups log follows; D [26/Oct/2006:23:58:32 +0300] CUPS-Get-Devices D [26/Oct/2006:23:58:32 +0300] CGI /usr/lib/cups/daemon/cups-deviced started - PID = 28114 I [26/Oct/2006:23:58:32 +0300] Started "/usr/lib/cups/daemon/cups-deviced" (pid=28114) D [26/Oct/2006:23:58:32 +0300] cupsdSendCommand: 8 file=9 D [26/Oct/2006:23:58:32 +0300] [cups-deviced] Added device "ipp"... D [26/Oct/2006:23:58:32 +0300] [cups-deviced] Added device "scsi"... D [26/Oct/2006:23:58:32 +0300] [cups-deviced] Added device "socket"... D [26/Oct/2006:23:58:32 +0300] [cups-deviced] Added device "lpd"... D [26/Oct/2006:23:58:35 +0300] [cups-deviced] Added device "http"... D [26/Oct/2006:23:58:36 +0300] [cups-deviced] Added device "smb"... D [26/Oct/2006:23:58:36 +0300] [cups-deviced] Added device "beh"... D [26/Oct/2006:23:58:36 +0300] [cups-deviced] Added device "bluetooth"... D [26/Oct/2006:23:58:36 +0300] PID 28114 (/usr/lib/cups/daemon/cups-deviced) exited with no errors. D [26/Oct/2006:23:58:36 +0300] cupsdCloseClient: 8 D [26/Oct/2006:23:58:48 +0300] cupsdAcceptClient: 8 from localhost (Domain) D [26/Oct/2006:23:58:48 +0300] cupsdReadClient: 8 POST /admin/ HTTP/1.1 D [26/Oct/2006:23:58:48 +0300] cupsdAuthorize: No authentication data provided. D [26/Oct/2006:23:58:48 +0300] CUPS-Add-Modify-Printer ipp:///var/run/cups/cups.sock/printers/a D [26/Oct/2006:23:58:48 +0300] CUPS-Add-Modify-Printer client-error-bad-request: The printer-uri must be of the form "ipp://HOSTNAME/printers/PRINTERNAME". D [26/Oct/2006:23:58:48 +0300] cupsdProcessIPPRequest: 8 status_code=400 (client-error-bad-request) D [26/Oct/2006:23:58:48 +0300] cupsdCloseClient: 8
Created attachment 18278 [details] cups1_2.patch Attached patch is a mixture of Jonathan Riddell's and Ismail Dönmez's patches which solves empty printer list issue and printer adding problem, tested with cups-1.2.{45}
In my opinion, the last hunk of the patch in #comment 37 is too hackish. Yes, it works, but it's overkill to connect to CUPS just to get the hostname (and there are other issues too). I've prepared a cleaner solution. I'll post a patch later today.
Created attachment 18358 [details] Empty printer list fix The same as http://bugs.kde.org/attachment.cgi?id=18278&action=view but without the last hunk (which is superseded by my next patch). Fix various failures with CUPS 1.2 when there are no printers.
Created attachment 18359 [details] Rework & unify IPP URI generation. Support UNIX socket properly Ensure proper IPP URI generation when CUPS is accessed via a UNIX socket. Replace all manual ipp:// URI construction with a new method. Tested with CUPS 1.2, NOT tested with CUPS 1.1
> Created an attachment (id=18358) > Empty printer list fix > Created an attachment (id=18359) > Rework & unify IPP URI generation. Support UNIX socket properly Both works without a problem for us (we already included these in to our packages)
Ping? This bug is still valid for vanilla KDE
I think Dirk fixed this bug with his latest commit to kdeprint, CC'ing him.
Concluding from reading all the dissonant and cacophonic comments above I have a strong feeling that this issue is still not resolved in a clean way. (I have no access to the source code now to compile and do various tests, and I wouldn't understand the source code anyway..) Questions: Do we now make a full use of the official CUPS API (like Mike had suggested with cupsSetServer() and cupsDoAuthentication)?? Do we have changes in the GUI that allow for Unix domain as well as IP sockets?? Or are we (again/still) using our private hacks to "make it work"??
We have support for unix sockets as well as tcp communication in latest 3.5 and in 4.0 tree. attachment 18359 [details] is obsolete, I don't understand the other patch. What is it good for? when do you get an empty printer list.
> What is it good for? when do you get an empty printer list. To reproduce the problem remove your /etc/cups/printers.conf and try to add a printer, kprint will gives a "no printer exists" error (or something like that, i cant reproduce cause we are using patched kde) attachment 18358 [details] solves that issue. And other problem is described in Comment #36 with log.
And for reference, problem is same with https://bugzilla.novell.com/show_bug.cgi?id=222938 :)
yes, and that was fixed by http://websvn.kde.org/?rev=612792&view=rev
how do you add a printer? via kaddprinterwizard? is there a problem after you include above patch?
> yes, and that was fixed by http://websvn.kde.org/?rev=612792&view=rev > how do you add a printer? via kaddprinterwizard? > is there a problem after you include above patch? I'm trying with via kcontrol so yes kaddprinterwizard :), will try that revision.
> will try that revision. attachment 18358 [details] still needed with your patch or kcontrol/printer still gaves "Unable to retrieve the printer list. Error message received from manager: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: the IPP request failed for an unknown reason." as reported in #comment 30, 31, 32
ok, thanks, then I commit this patch as well and then all should be good - finally.
SVN commit 622014 by mueller: CCBUG:115891 avoid error message on empty configured printer list M +4 -0 ipprequest.cpp M +2 -2 kmcupsmanager.cpp --- branches/KDE/3.5/kdelibs/kdeprint/cups/ipprequest.cpp #622013:622014 @@ -329,6 +329,10 @@ dumpRequest(request_, true); } + /* No printers found */ + if ( request_ && request_->request.status.status_code == 0x406 ) + return true; + if (!request_ || request_->state == IPP_ERROR || (request_->request.status.status_code & 0x0F00)) return false; --- branches/KDE/3.5/kdelibs/kdeprint/cups/kmcupsmanager.cpp #622013:622014 @@ -61,7 +61,7 @@ #define ppdi18n(s) i18n(QString::fromLocal8Bit(s).utf8()) static void extractMaticData(QString& buf, const QString& filename); -static QString printerURI(KMPrinter *p, bool useExistingURI = false); +static QString printerURI(KMPrinter *p, bool useExistingURI); static QString downloadDriver(KMPrinter *p); static int trials = 5; @@ -218,7 +218,7 @@ QString uri; req.setOperation(state); - uri = printerURI(p); + uri = printerURI(p, true); req.addURI(IPP_TAG_OPERATION,"printer-uri",uri); if (req.doRequest("/admin/")) return true;
SVN commit 622015 by mueller: fix handling of empty printer list with cups 1.2.x BUG: 115891 M +4 -0 ipprequest.cpp M +2 -2 kmcupsmanager.cpp --- trunk/KDE/kdelibs/kdeprint/cups/ipprequest.cpp #622014:622015 @@ -329,6 +329,10 @@ dumpRequest(request_, true); } + /* No printers found */ + if ( request_ && request_->request.status.status_code == 0x406 ) + return true; + if (!request_ || request_->state == IPP_ERROR || (request_->request.status.status_code & 0x0F00)) return false; --- trunk/KDE/kdelibs/kdeprint/cups/kmcupsmanager.cpp #622014:622015 @@ -62,7 +62,7 @@ #define ppdi18n(s) i18n(QString::fromLocal8Bit(s).toUtf8()) static void extractMaticData(QString& buf, const QString& filename); -static QString printerURI(KMPrinter *p, bool useExistingURI = false); +static QString printerURI(KMPrinter *p, bool useExistingURI); static QString downloadDriver(KMPrinter *p); static int trials = 5; @@ -217,7 +217,7 @@ QString uri; req.setOperation(state); - uri = printerURI(p); + uri = printerURI(p, true); req.addURI(IPP_TAG_OPERATION,"printer-uri",uri); if (req.doRequest("/admin/")) return true;
Closing old Resolved status bug.