Bug#578079: [Pkg-cups-devel] Bug#578079: I can see this bug too
For lpadmin commands it depends where -E is specified. -E before -p
enforces encryption, but -E after -p directly enables the queue.
So you have to take care that the command line arguments of lpadmin are
in the right order in the maintainer scripts.
We do not want to enforce encryption as it is not compatible with all
server configurations, but we want the newly created queue to be enabled
from the beginning on. With all this we want to assure that every user
gets a working queue, regardless of his configuration.
So make sure that the maintainer scripts do
lpadmin -p PDF -E ...
and never
lpadmin -E ...
With this fixed all should work well regardless of whether the ugly
"Upgrade required" error message in CUPS is fixed or not.
Till
On 01/11/2014 07:21 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
>
> Can you give your input here? I seem to remember some discussions about
> CUPS-PDF…
>
> Le vendredi, 10 janvier 2014, 17.55:29 Martin-Éric Racine a écrit :
>> 2014/1/10 Didier 'OdyX' Raboud <odyx@debian.org>:
>>> While hunting down old src:cups bugs, I stumbled upon #578079, which
>>> I think is not-a-bug, see below.
>>>
>>> Le jeudi, 28 avril 2011, 15.56:06 Martin-Éric Racine a écrit :
>>>> I'm starting to suspect that upstream made some
>>>> backward-incompatible
>>>> changes to the way queues are handled, because we get a similar
>>>> problem with CUPS-PDF, but only whenever the package gets upgraded;
>>>> if it's installed from scratch or purged then re-installed, it
>>>> works as it should.
>>>
>>> From the code:
>>>
>>> $ git grep -B1 'Upgrade Required' cups/
>>> cups/http-support.c- case HTTP_STATUS_UPGRADE_REQUIRED :
>>> cups/http-support.c: s = _("Upgrade Required");
>>> $ git grep 'HTTP_STATUS_UPGRADE_REQUIRED ' cups/http.h
>>> cups/http.h: HTTP_STATUS_UPGRADE_REQUIRED = 426,
>>>
>>> /* Upgrade to SSL/TLS required */
>>>
>>> … which means that the 'Upgrade Required' error is not a "Please
>>> upgrade your cups client to a more recent version because we broke
>>> backwards- compatibility"-error, but a "Hey client, please talk to
>>> me over SSL/TLS because I require it"-error. This can be enforced
>>> using the "Encryption">
>>> cups.conf statement:
>>> https://localhost:631/help/ref-cupsd-conf.html#Encryption
>>>
>>> I therefore propose to close this bug as it doesn't appear (to me)
>>> to be a bug but mostly a miscomprehension of the error message.
>>
>> Way back when people reported installation errors for CUPS-PDF, the
>> general concensus was that using the -E option to enable encryption
>> with 'lpadmin' was a source of problem, because the SSL certificates
>> needed by CUPS might not have been yet unpacked and configured on a
>> fresh install, so the option was removed from CUPS-PDF's maintainer
>> scripts.
>
> One possibility would be to hijack a ppd-updater trigger to setup this
> queue once cups is fully setup, see :
> http://sources.debian.net/src/cups/1.7.1-1/debian/cups.postinst#L167
> The trigger runs after CUPS is fully configured.
>
> Another possibility would be to pre-depend on CUPS but I think it's
> probably overkill.
>
>> Yet, according to the above, connections do require it. I'd really
>> appreciate more precise info for when it's required and when it's not.
>> Once I've received this, I can upgrade CUPS-PDF's maintainer scripts
>> to match.
>>
>> Still, TBH, the error message itself is a textbook example of
>> obfuscated code that provides misleading feedback to the user. *sigh*
>
> Yeah, I agree and therefore reported the upstream
> https://cups.org/str.php?L4333.
>
> Cheers,
> OdyX
>
Reply to: