Dear Maintainer,

Periodically, printing stops working for me. When this happens:

 * The job status is shown as "No destination host name supplied by cups-browsed for printer "stig_dawn", is cups-browsed running?"

 * cups_error.log shows:
   E [09/Jul/2026:08:14:23 +0100] [Job 121] No destination host name supplied by cups-browsed for printer \"stig_dawn\", is cups-browsed running?
   W [09/Jul/2026:08:14:23 +0100] [Job 121] Backend implicitclass returned status 4 (stop printer)

 * Cancelling all pending jobs, then restarting cups-browsed, fixes the problem.

I suspect that this is the same problem as upstream issue https://github.com/OpenPrinting/cups-browsed/issues/23. There is a fix to that linked from the issue, but as far as I know it has not been backported to cups-browsed v1. Please could you backport https://github.com/OpenPrinting/cups-browsed/commit/57d9351ea45f47b3bd185f263b1e37d276cf17b8 ?

Hi,

I can confirm this on Debian 13 (cups 2.4.10-3+deb13u2, cups-browsed
1.28.17-6+deb13u1) on two clients printing to a shared queue on a
Debian 13 CUPS server. With DebugLogging enabled, I can see how the
queue ends up unmanaged:

1. A job prints successfully but remains in the local queue
   ("job-printing"). The server's access_log shows the client sending
   Cancel-Job 35 seconds after Send-Document, which the server rejects
   because the job is already completed:

     23:33:34 "POST /printers/..." Send-Document successful-ok
     23:34:09 "POST /printers/..." Cancel-Job client-error-not-possible

   Client error_log: "[Job 2] Unable to cancel print job."
   I don't know why the client cancels the job.

2. When cups-browsed is stopped (restart or shutdown) while that job is
   still listed, it keeps the queue instead of removing it:

     Queue has still jobs or CUPS error!
     Disabled printer 'O_Brother_Where_Art_Thou_lalaserver'

3. The remaining queue has no "cups-browsed" option in printers.conf
   (only "DeviceURI implicitclass://..."). After the next start,
   cups-browsed no longer treats it as its own:

     Found CUPS queue/class: O_Brother_Where_Art_Thou on host lalaserver.local.
     Queue name O_Brother_Where_Art_Thou_lalaserver already taken.

   From then on every job fails with "No destination host name supplied
   by cups-browsed ..." until the queue is deleted manually.

Step 3 is what upstream commit 57d9351 addresses (implicitclass:// queues
are always treated as cups-browsed-controlled), so a backport to trixie
should prevent the permanent breakage.

Workaround in use here: cups-browsed masked, printing via CUPS' own
driverless DNS-SD destinations. That works reliably.

Thanks!