Bug 18940

Assigning to all packagers collectively, since there is no maintainer for this package.

CC'ing some committers

CC: (none) => jani.valimaa, luigiwalser, mageia, mageia, mageia, makowski.mageia, marja11, pterjan, thierry.vignaud
Assignee: bugsquad => pkg-bugs
Source RPM: system-config-printer-1.5.7-3.mga6.src.rpm => system-config-printer-1.5.7-3.mga6

I submitted system-config-printer-1.5.7-4.mga6 in cauldron/testing to rely on packagekit only
please try and report issues here.
Take it as work in progress, I'm really interested in report.

CC: (none) => ngompa13

Not much success:

Action 1:
---------
1. added my MFP with system-config-printer-1.5.7-3 - OK like always
2. installed system-config-printer-1.5.7-4.mga6 from updates_testing
3. did scanimage -L to get the precise device-name
4. did scanimage -d 'hpaio:/net/HP_LaserJet_Pro_MFP_M225dw?ip=192.168.0.12' > out.pnm

Result: failure precisely as described in the problem description

Action2 :
---------
1. Deleted the MFP
2. Tried to add the MFP with system-config-printer-1.5.7-4.mga6
  a) without explicitely specifying the ip of the MFP
      the MFP was not detected (verified with ping 192.168.0.12)
      (with 1.5.7-3 the printer is automatically detected, no need

  b) after specifying the ip

Sorry, the comment got sent accidentally before completion

     (with 1.5.7-3 the printer is automatically detected, no need
     to specify the ip address)

  b) after specifying the ip: loops on error message

(In reply to Juergen Harms from comment #3)
> 2. installed system-config-printer-1.5.7-4.mga6 from updates_testing

This simple step will do nothing
system-config-printer is their to help to configure your printer, so you need to launch it an re configure your printer to see if this change something or not.

>  a) without explicitely specifying the ip of the MFP
>      the MFP was not detected (verified with ping 192.168.0.12)
>      (with 1.5.7-3 the printer is automatically detected, no need

yes, seems the relying on packagekit only create this situation, out of the box, it seems the s-c-p is not good at detecting network printer

I submitted system-config-printer-1.5.7-5.mga6 in cauldron/testing
this version rely on packagekit and mga_custom
trying to get the best of the two worlds

(In reply to Juergen Harms from comment #4)
> b) after specifying the ip: loops on error message
in the future, try to give more details, thanks

> This simple step will do nothing
> system-config-printer is their to help to configure your printer, so you need > to launch it an re configure your printer to see if this change something or not.

Right, just mentioned it to document at what moment I did the update to 1.7.5-4 (and no, I do not believe in black magic )

> in the future, try to give more details, thanks

in the past too - there is something wrong with my keyboard shortcuts, with
the result that also the continuation comment "went away" a second time without my wanting it - I had then to run away.

Here are the details that got lost:

Detail 1 = snippet from the looping message (embedded in non-significant text):

.....
Traceback (most recent call last):
  File "/usr/share/system-config-printer/newprinter.py", line 3171, in found_network_printer_callback
    def found_network_printer_callback (self, new_device):
KeyboardInterrupt
pr8
'\x00'
pr9
'\x00'
pr10
.....

Detail 2 = message after launching command-line system-config-printer 1.5.7-4 that might be of interest to you:

/usr/share/system-config-printer/system-config-printer.py:31: PyGIWarning: Polkit was imported without specifying a version first. Use gi.require_version('Polkit', '1.0') before import to ensure that the right version gets loaded.
  from gi.repository import Polkit

Detail 3 = The main window of system-config-printer, while searching for the
printer, does not display a spinner icon (whereas the main window of system-config-printer 1.5.7-3 does)


system-config-printer 1.5.7-5 has not yet arrived in the mirror I use, I guess you want me to test that

At second thought, I started doubting whether this bug is really a bug on system-config-printer:

- system-config-printer, in fact, has done its job as soon as the MFP has been installed as a printer (and system-config-printer correctly does this job), and then will go away (without having loaded the plug-in, which also is correct).

- the driver for then scanner function should be loaded when scanner action is requested (scanimage)

- the program to be launched for loading the scanner driver is hp-setup (more precisely, as I now have learned, hp-plugin)

- I guess it is the task of scanimage to launch hp-plugin - which it does not, or not correctly.

Therefore the bug is probably a bug on scanimage (i.e. sane-backends -  sane-1.0.25-2.mga6.src.rpm)

Playing with scanimage (after having reverted to system-config-printer 1.5.7-3) appears to confirm this hypothesis:

- scanimage -d <device-name> > <output-file> :
	aborts with an error message on failed I/O without having loaded the plugin

- scanimage --help 
	prints the help text and then - correctly now - pops up the window that had been missing and that offers to download or install the driver plug-in.

The most adequate work-around therefore is, after having configured the MFP, either
 - to do command-line "hp-plugin" or
 - to do command-line "scanimage --help
immediately after having installed the printer.

Sorry for having initially got this wrong. Can the target of this bug be modified to sane, or shall I close it as invalid and open a new bug on sane?

I have a problem with a Brother MFC scanner.  It may be related to this bug, maybe not.  I will file a separate bug if it helps.

In my case, xsane worked until a couple of months ago.  Then after downloading some updates, it refused to detect the scanner, whether run as root or not.

As I write, the scanner opens normally in Cauldron, but is still not detected in Official.  Originally, it seemed to extend into other distros, so I filed a report with Brother, and attached the output of strace.  I am waiting to hear back from them.

CC: (none) => laidlaws

Probably better have 2 separate bugs: the present report is on a problem that exclusively concerns cauldron, no problem on Mageia-5 official. For the Brother MFC scanner it is the other way round.

Duplicate of bug 16253?

Try adding your user to groups 'lp' and 'scanner', re-log, and see if the scanner can then be added.

CC: (none) => jdchoate

I must get off the CC for this bug.  Mine is a Brother.  I will add a cross-ref in due course.

Should I open a bug at all?  My scanner works O.K. under Cauldron.  After updating my default Official to Cauldron, the problem was back. I ran Brother's installation script again.  That fixed it.  Any bug in 5 will soon be history.

In reply to comment 11:

After adding myself to the lp group (automagically I was already member of the scanner group), the scanner got successfully configured (in spite of a thunderstorm of messages re failing scanner initialisation).

I cannot formally attribute this to adapting the group membership: the successful configuration was on a newly generated cauldron system - success may be due to group affiliation, and just as well to the numerous updates of cauldron packages that have happened since the bug was filed.

(In reply to Frédéric Buclin from comment #10)
> Duplicate of bug 16253?

Very probably.  If xsane can't see the scanner, it means that the ID under which it is running doesn't have write access to the scanner device.  What needs to be corrected is whatever dbus or udevd creation magic assigns permissions to these devices.

CC: (none) => ftg

After some more digging the situation (talking about the originally submitted bug, not the additional issues) looks quite clear:

1. In Mga5 (hplip-3.14.6, system-config-printer-1.5.5) system-config-printer automagically installs the proprietary hp plugin when necessary after installing an hp MFP printer - without calling the hp-plugin utility and without any user intervention (in fact, in Mga5 hp-plugin refuses to be run as root).

2. In cauldron (hplip-3-16.10, system-config-printer-1.5.7) system-config-printer simply does not install the plugin any more. This deficiency does not become evident until the scanner of the MFP printer is effectively put to use (for instance when xsane calls scan-image) and results in the scanning to fail with an error message.

3. System-config-printer evidently expects an explicit command-line invocation of hp-plugin (with the -g, -i or -u option) to be made for installing the plugin. Probably this is due to hp wanting the user to see and reply to all the legal stuff displayed by hp-plugin (and hplip-3-16.10 now allows to be launched by root).

4. I see 2 possible solutions:
  a. Accept and live with this situation. But this requires (1) the user to be made aware that he needs to load the plugin, and (2) that xsane does not simply blow up with an (for the user) obscure error message when this has not been done.
  b. Fix system-config-printer that it detects the need to install the plugin and launches hp-plugin. This is beyond the scope of a Mageia bug-fix.

A possible quick-and-dirty fix - rather than properly correcting system-config-printer - could be to simply add a wart to system-config-printer before it exits - the wart would have to check the list of installed hp MFP printers and verify whether the hp plugin is installed; it could either immediately launch the hp-plugin utility or issue an appropriate warning. Probably not more than wishful thinking.

My suggestion: Add an item to the release notes of Mga6 that explains the error message issued by xsane when an hp MFP printer is used for scanning without having installed the plugin. Tell the user that this plugin must be explicitely installed by a "hp-plugin -u" command-line call from a user-terminal. This can be done after system install as soon as hplip has been installed. To verify whether this must be repeated whenever an update of hplip is installed. 

It would be nice to add a temporary patch in xsane that would wrap the error message into something more user friendly and providing constructive info, but that is probably not realistic.

Good news: in Comment 16, enumeration-item (1) I have made a mistake: it is not correct that Mga5 does the installation automagically and without user involvement (when I tried this, I had not properly removed the previously installed hp plugin). Both systems contain code in hplip (ui4, resp. ui5/plugindialog_base.py) that is meant to launch the "Driver Plug-in Installation is required" popup when xsane is launched (xsane probably calls the scan support procedures in hplip, which does the necessary checking).

The question is why hplip-3.14.6 correctly does the triggering, but not hplip 3-16.10. I did some more checking:

- launching xsane creates an entry in /var/log/syslog:

Nov 29 22:57:23 pcjuergen xsane: common/utils.c 188: unable to load library libm.so: /lib64/libm.so: invalid ELF header

  which may indicate a packaging problem, but does not appear to have negative
  consequences

- running hp-check for doing configuration sanity check claims missing packages
  (python3-pyqt4, python3-pyqt4-dbus, python3-notify2, and avahi-utils

I started by installing avahi and libavahi-core7 as the most likely trouble makers - that and seems to solve the problem: cauldron now behaves like Mga5 and correctly launches the popup that sollicits the user to install the driver.

However, I still have to verify what needs to be done to revert to the original (faulty) state to verify that this is reproducible - since I have installed avahi the original problem cannot be reproduced, even if I un-install avahi; maybe I need a boot. But it is time to finish for today.

I have now verified this bug against STA2 on 2 machines
- a Dell Optiplex 990 desktop with kernel-server: OK no problem
- a Dell Latitude E6530 laptop with kernel-desktop: bug still present, the driver does not install automatically.

The 2 systems are installed as similar as possible - both systems are generated with custom package selection, graphic desktop = XFCE - no packages explicitely selected at install, all required additional packages post-installed (same script on both systems) once the system is up. 

STA2 with minimal default package selection (XFCE) on the laptop does not install some of the packages needed for correct printer configuratio, in particular hplip-gui - which makes even the work-around with command-line "hp-plugin -u" impossible - and reduces the incidence of the bug to some quite specific situations.

So, the fundamental problem is very probably a question of the choice of packages installed by default - hpcheck does some ranting that should be clarified. I will pick this up once I have more time.

I have now figured out how to revert the desktop to the original faulty situation (after having installed hplip-gui and manually having loaded the driver) without doing a fresh system install : uninstall all hplip relevant packages and lib64sane-hpaio1 packages (I guess a subset would also do).

(In reply to Juergen Harms from comment #18)
> I have now verified this bug against STA2 on 2 machines
> - a Dell Optiplex 990 desktop with kernel-server: OK no problem
> - a Dell Latitude E6530 laptop with kernel-desktop: bug still present, the
> driver does not install automatically.
> 
> The 2 systems are installed as similar as possible - both systems are
> generated with custom package selection, graphic desktop = XFCE - no
> packages explicitely selected at install, all required additional packages
> post-installed (same script on both systems) once the system is up. 
> 
> STA2 with minimal default package selection (XFCE) on the laptop does not
> install some of the packages needed for correct printer configuratio, in
> particular hplip-gui - which makes even the work-around with command-line
> "hp-plugin -u" impossible - and reduces the incidence of the bug to some
> quite specific situations.
> 
> So, the fundamental problem is very probably a question of the choice of
> packages installed by default - hpcheck does some ranting that should be
> clarified. I will pick this up once I have more time.
> 
> I have now figured out how to revert the desktop to the original faulty
> situation (after having installed hplip-gui and manually having loaded the
> driver) without doing a fresh system install : uninstall all hplip relevant
> packages and lib64sane-hpaio1 packages (I guess a subset would also do).

CC'ing wally and the isobuilders

CC: (none) => isobuild, jani.valimaa

> CC'ing wally and the isobuilders

Thanks, it is motivating to get this kind of reply. In the meantime, I have compared the list of packages documented in /root/drakx between the two systems: both list are very similar (except some additional packages on the laptop due to wifi support), nothing that could explain discrepancies in packages for printer handling.

The difference must therefore have been caused during my post-loading. I therefore did a fresh install and customisation: that new system had all the required packages, and the automatic configuration for the scanner works as it should.

So: the bug has been resolved - sorry for my mis-leading comment #19

(In reply to Juergen Harms from comment #20)

> 
> So: the bug has been resolved - sorry for my mis-leading comment #19

No problem, thanks for telling us instead of hiding :-)

Status: NEW => RESOLVED
Resolution: (none) => FIXED