Bug 165328

Summary:	Samsung ML-1710 no longer appearing in print queue on hotplug
Product:	[Fedora] Fedora	Reporter:	Rodd Clarkson <rodd>
Component:	system-config-printer	Assignee:	Tim Waugh <twaugh>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	paul, tagoh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	0.6.140-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-08-11 11:25:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rodd Clarkson 2005-08-08 01:13:05 UTC

Description of problem:

Up until a few days ago (so August 3) when I plugged the USB cable for my
Samsung ML-1710 into my laptop, a print queue was created to which I could
print.  Sometimes this involved restarting the applications to see the printer,
and sometimes it involved editing the created print queue in s-c-p, but it was
always visible in s-c-p.

Today when I plug in this printer (I have no other printers to test if it's
specific to this model or not) I no longer see the printer in s-c-p.

lshal shows that printer has been detected, but it's not showing up as a print
queue.

Version-Release number of selected component (if applicable):

system-config-printer-0.6.139-1


How reproducible:

Very


Steps to Reproduce:
1. Turn on ML-1710 and plug in USB cable.
2. ML-1710 is detected by hal

  
Actual results:

No print queue appears in the s-c-p


Expected results:

A print queue should appear.  Apps that are already open should be able to print
to this printer.  If the printer has been declared the default printer before it
should become the default printer again. (I know the last two aren't really
related, but I thought it worth mentioning them)

Additional info:

The first of the above has worked in the past, but no longer does.  The middle
one is sporadic, the later unlikely to happen.

Comment 1 Tim Waugh 2005-08-08 14:22:05 UTC

When you run system-config-printer and go to add a new printer, is the correct
model selected from the list automatically?

Comment 2 Rodd Clarkson 2005-08-08 21:20:42 UTC

When I run s-c-p and click the New icon, the window greys and the mouse throbs
and not a lot else happens.

This I can reproduce each time.

If I run from the command line then this is what I get.  The stuff after '[1]
10290' is the result of clicking the 'New' icon.

[root@localhost ~]# system-config-printer &
[1] 10290
[root@localhost ~]# No match for USB device:
  mfr "Samsung"
  model "ML-1710"
  desc ""
  cmdset "GDI"
Please report this message in Bugzilla:
  https://bugzilla.redhat.com/bugzilla
Choose 'foomatic' as the component.
Traceback (most recent call last):
  File "/usr/share/printconf/util/queueTree.py", line 581, in new_button_clicked
   self.addQueue.addQueueDruid ()
  File "/usr/share/printconf/util/addQueue.py", line 277, in addQueueDruid
    window = self.window.window)
  File "/usr/share/printconf/util/queueTree.py", line 910, in populate_model_store
    models = self.conf.foomatic.make_model_dict_dict[mfr].keys ()
KeyError: 'Generic'


I'm going to move this bug to foomatic (as described in the output) as it seems
pretty clear that this is where the bug lies (given the 'No match for USB
device' line at the top)

Comment 3 Tim Waugh 2005-08-09 10:26:01 UTC

The problem turned out to be more fundamental than that: I'd broken the parser
altogether.

Fixed in 0.6.140-1.

Comment 4 Tim Waugh 2005-08-10 08:40:08 UTC

*** Bug 165512 has been marked as a duplicate of this bug. ***

Comment 5 Tim Waugh 2005-08-10 14:40:56 UTC

*** Bug 165556 has been marked as a duplicate of this bug. ***

Comment 6 Akira TAGOH 2005-08-11 11:16:11 UTC

As I described which version I saw this problem on, 0.6.140-1 didn't help me at all.

Comment 7 Tim Waugh 2005-08-11 11:25:30 UTC

Oops: separate bug (now bug #165556) is that the foomatic cache is not cleared
when system-config-printer is updated, so the bad parse data was still around.