Bug#972898: hplip: no network scanner detection with 3.20.9

2020-10-25 Thread Ahzo
Package: hplip
Version: 3.20.9+dfsg0-4
Severity: important
Tags: patch

Dear Maintainer,

hplip version 3.20.9 replaced the custom mDNS implementation for scanner 
discovery (protocol/discovery/mdns.c) with using avahi 
(protocol/discovery/avahiDiscovery.c).
While this is a welcome change in principle, unfortunately the new code does 
not work.

The main problem is that it does not wait until all callbacks are called before 
stopping via avahi_simple_poll_quit.
Thus there is a 50/50 chance whether the '_scanner._tcp.local' or the 
'_uscan._tcp.local' mDNS reply gets processed (in the browse_callback) and it 
is practically impossible that any scanner gets processed (in the 
resolve_callback), because avahi_simple_poll_quit is called when the first mDNS 
reply has been processed.
It seems like this code was never really tested with an actual scanner on the 
network.

Attached is a patch fixing this by implementing a check_terminate function 
similar to the one used by avahi-browse.

The second problem is that the code expects the 'ty' part of the mDNS reply, 
which contains the device name, to start with 'HP'. However this is not always 
the case.
Previous versions of hplip would simply remove the first three letters of the 
scanner name and continue, which could be worked around by also removing these 
three letters in the models.dat. That issue has been reported two years ago 
upstream without response from HP. (see: 
https://bugs.launchpad.net/hplip/+bug/1797501)
The new code however  discards the scanner if its 'ty' name does not start with 
'HP', breaking that workaround.
Fortunately, since the new code now uses avahi, a proper fix is relatively 
simple: If the 'ty' part of the mDNS response does not start with 'HP', check 
whether the 'mfg' part does.

The second attached patch implements this fix.

While debugging this I also noticed that the log level for one message is 
wrong, causing spurious errors to be reported.

The third attached patch changes the log level for this message from BUG to DBG 
to fix this.

I hope HP solves this eventually, but until then please include these patches 
in the Debian package, so that scanner detection works again.

Thanks in advance,
Ahzo

PS: I tried to report this upstream, but my Launchpad login attempts always 
fail, because "something just went wrong in Launchpad".

>From 67dbad25f503e1d8c6794efba3f17718c77848ea Mon Sep 17 00:00:00 2001
From: Ahzo 
Date: Sun, 25 Oct 2020 22:17:04 +0100
Subject: [PATCH 1/3] avahiDiscovery: wait for all callbacks

When calling avahi_simple_poll_quit too early, not all callbacks will be called.
---
 protocol/discovery/avahiDiscovery.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/protocol/discovery/avahiDiscovery.c b/protocol/discovery/avahiDiscovery.c
index 8d325ffc0..395aec088 100644
--- a/protocol/discovery/avahiDiscovery.c
+++ b/protocol/discovery/avahiDiscovery.c
@@ -28,6 +28,7 @@ char ipAddressBuff[MAX_IP_ADDR_LEN]={'\0'};
 static int aBytesRead = 0;
 static AvahiSimplePoll *aSimplePoll = NULL;
 static int aMemAllocated = 0;
+static int n_all_for_now = 0, n_resolving = 0;
 
 /*
 This function will fill the dictionary arguments for the dbus function call
@@ -237,6 +238,15 @@ static bool getHPScannerModel(AvahiStringList *iStrList, const char *ikey,char *
 return aValueFound;  
 }
 
+static void check_terminate() {
+
+assert(n_all_for_now >= 0);
+assert(n_resolving >= 0);
+
+if (n_all_for_now <= 0 && n_resolving <= 0)
+avahi_simple_poll_quit(aSimplePoll);
+}
+
 /*
 This function will gets called whenever a service has been resolved successfully or timed out
 */
@@ -300,6 +310,9 @@ static void resolve_callback(
 }
 }
 //avahi_service_resolver_free(r);
+assert(n_resolving > 0);
+n_resolving--;
+check_terminate();
 }
 /* Called whenever a new services becomes available on the LAN or is removed from the LAN */
 static void browse_callback(
@@ -337,11 +350,14 @@ static void browse_callback(
 
 if (!(avahi_service_resolver_new(c, interface, protocol, name, type, domain, AVAHI_PROTO_INET, (AvahiLookupFlags)0, resolve_callback, c)))
 BUG( "Failed to resolve service '%s': %s\n", name, avahi_strerror(avahi_client_errno(c)));
+else
+n_resolving++;
 
 break;
 
 case AVAHI_BROWSER_ALL_FOR_NOW:
- avahi_simple_poll_quit(aSimplePoll);
+ n_all_for_now--;
+ check_terminate();
  break;
 }
 }
@@ -444,6 +460,7 @@ static void avahi_setup(const int iCommandType, const char* iHostName)
 goto fail;
 }
}
+   n_all_for_now++;
 
/* Create the service browser */
if (!(sb = avahi_service_browser_new(client, AVAHI_IF_UNSPEC, AVAHI_PROTO_INET, "_scanner._tcp", NULL, (AvahiLookupFlags)0, browse_callback, client))) 
@@ -451,6 +468,7 @@ static void avahi_setup(const int 

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

2020-10-25 Thread Jonas Smedegaard
Quoting Fabian Greffrath (2020-10-25 21:58:30)
> the fonts-urw-base35 is currently stuck in unstable and not allowed to 
> migrate to testing because the ghostscript package currently suffers 
> from a completely unrelated RC bug. This is because the libgs9-common 
> package has an overly strict dependecy on fonts-urw-base35:
> 
> Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1)
> 
> Thus, the font package is punished for a bug in ghostscript that's not
> even related to the font at all. Please relax the dependency to just
> the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of
> the font than the one the ghostscript package was built with are
> allowed to migrate to testing.

It seems to me that the concrete delay is caused by ghostscript in 
_testing_ having tight dependency on the font, and that it therefore 
cannot be solved by an upload to unstable - only by ghostscript 
migrating to testing (or ghostscript getting kicked out of testing).  
That said, relaxing the dependency would avoid similar delays in the 
future.

Regardless of what exactly is fixed when, I am not convinced that it is 
wise to relax the dependency:

The reason for the tight dependency is to ensure the integrity of the 
symlinking between the font package and Ghostscript.  It is resolved by 
dh_linktree which explains it like this in its man page:

> Since symlink trees are created statically at build-time, they are not 
> very future-proof and have a risk to miss some files introduced by a 
> newer version of the package providing the file tree which is 
> duplicated. That's why the generated dependencies generally ensure 
> that the same upstream version be used at run-time than at build-time.


Sorry, I do understand how it is frustrating for the font to be held 
ransom by another package like this.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

2020-10-25 Thread Fabian Greffrath
Package: libgs9-common
Version: 9.52.1~dfsg-1
Severity: important

Hi there,

the fonts-urw-base35 is currently stuck in unstable and not allowed to
migrate to testing because the ghostscript package currently suffers
from a completely unrelated RC bug. This is because the libgs9-common
package has an overly strict dependecy on fonts-urw-base35:

Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1)

Thus, the font package is punished for a bug in ghostscript that's not
even related to the font at all. Please relax the dependency to just
the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of
the font than the one the ghostscript package was built with are
allowed to migrate to testing.

Thanks!

 - Fabian


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), 
(500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgs9-common depends on:
ii  fonts-urw-base35  20170801.1-3

Versions of packages libgs9-common recommends:
ii  fonts-droid-fallback  1:6.0.1r16-1.1

libgs9-common suggests no packages.

-- no debconf information