Can you attach the output of lshal.  It looks like the USB device is
outputting hl-1440-series as the model whereas foomatic knows it as
hl-1440.  Funny that the driver dialog didn't popup to ask you to
select a driver.  Can you also do:

rpm -q foomatic
rpm -q desktop-printing
rpm -q hal-cups-utils

and get me the output of those commands?  Also check if eggcups is
running in your session.

I am using foomatic 3.0.1-11 and hal-cups-utils-0.5.2-1.  

I did not have desktop-printing installed, though I have now installed
0.10.2-2.  Should there be a dependency somewhere that brings in
desktop-printing automatically?  Or is it not a prerequisite for
hal-cups-utils?

I will send the output of lshal as soon as I have time and access to
the printer again.

hal-cups-utils is a dependency of desktop-printing.  desktop-printing
is not a dependency of any other component as I understand it.  It is
usualy installed by the Anaconda installer when you choose to install
Gnome.  How exactly did you install Fedora?  Was it an upgrade or did
you install from cd?  If it was an upgrade what version did you
upgrade from and how did you install that? Thanks.

I've been tracking Fedora Rawhide since the PowerPC packages have been
available.  I upgraded to Fedora Rawhide from Yellow Dog Linux.  I am
not a typical user as far as installation goes.

rpm -q --whatrequires desktop-printing does say "no package requires
desktop-printing."

These are just facts.  I'm not advocating creating an RPM dependency
or avoiding one.  Arguments can be made for both alternatives and
things boil down to Fedora's policy.

Ok, so the package wasn't pulled in when upgrading from YDL.  It is
really up to the maintainer of the desktop-printing package if he
wants to add it as a dependency to a package.  I'm going to close this
bug now but if you could, could you plug in your printer and get me
the output of lshal.  Just attach it to this bug.  Thanks.

Created attachment 103856 [details]
Output from lshal with USB Brother HL-1440 printer attached.

I am re-opening this bug because it is not yet resolved.  Though I
mentioned that I installed desktop-printing, doing this did not
resolve the issue.  I hope to investigate this more tonight.

I am reassigning this bug to the desktop-printing maintainer.  Basicly
this is a known bug.  Eggcups (which is installed by desktop-printing)
needs to be started in the session.  This happens fine when installed
from scratch but when upgrading from a previous version which did not
have eggcups in the default session, causes then new default session
to not be picked up if you have already modified your session.  A
solution to make eggcups always start up in the session is being
discussed.

It looks like eggcups is being started:

[mike@imp ~]$ ps aux | grep eggcups
mike      5064  0.0  3.1 43976 8012 ?        Ssl  18:03   0:00 eggcups
--sm-config-prefix /eggcups-ZD0Y6T/ --sm-client-id
117f000001000109521593400000049420002 --screen 0

But running hal_lpqadmin by hand says:

[root@imp capability.d]# /usr/sbin/hal_lpadmin -p
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
libhal.c 823 : Error sending msg: No property printer.description on
device with id
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
libhal.c 823 : Error sending msg: No property printer.serial on device
with id
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
An error occurred while calling printer_needs_config: Service
"com.redhat.PrintDriverSelection" does not exist

What version of eggcups?

As noted in comment #2, I now have desktop-printing 0.10.2-2 installed:

[mike@imp ~]$ eggcups --version
Gnome eggcups 0.10.2

Hm, I think we discovered that version alongside some paleolithic
dinosaur bones :)

Can you try this?
http://people.redhat.com/walters/desktop-printing-0.12-1.i386.rpm

The eggcups included in desktop-printing-0.12-1 crashes immediately
upon executing.  I should note that I am running Fedora Rawhide on
PowerPC.  The backtrace seems to indicate some type of memory corruption:

[mike@imp ~]$ gdb eggcups
GNU gdb Red Hat Linux (6.1post-1.20040607.28rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "ppc-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/eggcups
[Thread debugging using libthread_db enabled]
[New Thread 805422240 (LWP 5320)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805422240 (LWP 5320)]
0x001861c8 in ?? ()
(gdb) ba
#0  0x001861c8 in ?? ()
#1  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#2  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#3  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#4  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#5  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#6  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
Previous frame inner to this frame (corrupt stack?)

Hmmm.  

Can you recompile eggcups without optimzation and with debugging info?

Also do you have any i386 machines?  Can you try on them to see
whether this is really ppc-specific?

I built eggcups without optimization and it did NOT receive a SIGSEGV
signal.  Unfortunately, I don't have an x86 machine to test with. 
Could someone run eggcups through valgrind on x86 to look for memory
issues?

I have not yet been able to test the non-segfaulting eggcups fully
because I don't have access to the printer right now.  Hopefully, I
will be able to test this tonight.

We've been running eggcups through valgrind regularly, it is pretty clean.

So if you rebuild it with optimization, you get the problem?

I might have been premature in reporting the eggcups segfault.  I am
unable to reproduce it now.  So eggcups 0.12 seems to execute okay.  

The driver configuration dialog now pops up when I plug my printer in.
 When I select a driver, the following is entered into GConf's
/system/printing/user_drivers/brother_hl-1440_series:

<?xml version="1.0"?>
<gconf>
        <entry name="driver" mtime="1095474706" type="string">
                <stringvalue>ljet4</stringvalue>
        </entry>
        <entry name="model" mtime="1095474706" type="string">
                <stringvalue>HL-1440 series</stringvalue>
        </entry>
        <entry name="make" mtime="1095474706" type="string">
                <stringvalue>Brother</stringvalue>
        </entry>
</gconf>

This all looks reasonable.

However, the end result is still that my printer is not available to
libgnomeprint applications.  The printer is not available in the
application's print dialog.

One thing that strikes me as odd is that /etc/cups/printers.conf is
not updated at all.  Also, nothing for the printer is placed in
/etc/cups/ppd.  /etc/printcap is also empty.

Another issue is that the hotplug event that is associated with the
printer must be triggered while I am logged in.  In other words, if I
log in with the printer already plugged in then I must unplug it and
plug it back it to get the configuration dialog to pop up.

Hmmm.  As for updating printers.conf, it may be that cups makes the
change in memory but doesn't write it out until you restart the daemon.

As for printers not showing up - this is probably because of the
optimization I made recently to have cups broadcast on new printers
instead of polling.  That's only in cups 1:1.1.21-1.rc2.2.  What
version do you have?

cups should be restarted when the printer is configured.  We need to
handle the case where a user logs onto the desktop with the printer
plugged in.  Note that the dialog should only ever pop up once.  I'm
guessing we can do this with a scan of HAL when the session loads. 
CC'ing davidz on this.  David, how best should we handle this? 
Doesn't g-v-m handle this for drives?

Yes, when g-v-m starts (along with the session) it mounts all volumes
and when exiting (when the session ends) they are unmounted again. 

You should probably just ask hal for all the printers
(hal_find_device_by_capability) and check thist list against what you
have in gconf.

I still have all of the problems in comment #17 following an update to
the most recent Rawhide.  I deleted the printer entries in ~/.gconf to
cause the entire process to repeat.

Current versions:

cups-1.1.21-1.rc2.2
desktop-printing-0.13-1
hal-cups-utils-0.5.2-1
hal-0.2.98-4

There is still nothing in printers.conf after I restart the cups and
cups-config-daemon services.

I just uploaded desktop-printing-0.14, which has John's fixes for this.
Can you give that a try?

If that doesn't work do me a favor and rerun 

/usr/sbin/hal_lpadmin -p
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0

and post the output.

I just upgraded to the following packages:

desktop-printing-0.14-1
cups-1.1.21-2
hal-cups-utils-0.5.2-1

Eggcups is now crashing.  The backtrace is worthless because it looks
like the program's stack is corrupt.

Here is the output from /usr/sbin/hal_lpadmin:

[root@imp /]# /usr/sbin/hal_lpadmin -p
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
libhal.c 869 : Error sending msg: No property printer.description on
device with id
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
libhal.c 869 : Error sending msg: No property printer.serial on device
with id
/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0
An error occurred while calling printer_needs_config: Message did not
receive a reply

I just tried:

desktop-printing-0.15.2-1
cups-1.1.21-4
hal-cups-utils-0.5.2-3

Eggcups no longer crashes.  I am once again provided with the driver
selection interface when I plug my printer.  However, my printer is
still not available in applications' print dialog.  Nothing appears in
/etc/cups/printers.conf.

Ok, I found the bug and it is fixed in eggcups in CVS.  Basicly the
values put into gconf are the ones reported by hal and not the ones in
the database.  The only reason for the gconf keys is to map the hal
values to the database values.  If we are mapping hal to hal then you
can see why it quickly becomes useless ;-).

I'll note here when the fix is in rawhide.  When the next version
comes out can you update and run "gconftool-2 --recursive-unset
/system/printing" to unset the current values in gconf and then try
plugging your printer in again.

Thanks for for helping to get this resolved.

This has been updated in rawhide to desktop-printing-0.15.2-2.

The printer is now configured properly when I plug it in while logged
in.  I am prompted to choose a driver and the printer becomes
available in applications that use gnomeprint.  Very nice!

The only remaining issue is that the hotplug event must be generated
while the user is logged on.  See the last paragraph in comment #17. 
Comment #20 talks about one solution for the desktop-printing package  

This is a problem that other Fedora components have.  For issues
related to setting USB scanner permissions, see:

http://sourceforge.net/mailarchive/message.php?msg_id=8617034

eggcups will iterate over printers and configure them (if they were
not autoconfigured on hal startup) when the session starts.  As for
USB scanners have you tested it with recent builds?  I don't have a
scanner to test but there are a class of devices that should get
permissions set when a person logs into their session as the console
user.  If this is not the case please file a new bug.

Closing this bug.  Thanks for your help.

As I mentioned in comment #28, this bug was fixed.  However, after
some updates, something is wrong again.

cups-1.1.22-0.rc1.5
desktop-printing-0.17-2
hal-0.4.0-4
hal-cups-utils-0.5.2-6

I once again do not get a driver prompt when the printer is plugged
in.  Eggcups is running.  Running hal_lpadmin by hand also does not work:

[mike@imp ~]$ /usr/sbin/hal_lpadmin -p
/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0
libhal.c 911 : Error sending msg: No device with id
/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0

The printer is listed in the hal tree, though:

[mike@imp ~]$ lshal | grep
/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial
lshal version 0.4.0
udi = '/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0' (string)
  info.parent =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'  (string)
udi = '/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'  (string)

please upgrade to hal-cups-utils 0.5.2-7 and try again.  

Hmm, looks like 0.5.2-7 was not built into fc3.  I'm building it into
head right now and it may take time to propigate.

You can get packages to test at:
http://people.redhat.com/johnp/hal-cups-utils/

Using:

hal-cups-utils-0.5.2-8
desktop-printing-0.17-3

I still have no luck.  If I plug my printer in and watch things with
top, I can see usb.agent, princonf-tui, foomatic-config and
foomatic-combo-xml execute.  However, I am not prompted for a driver
and the printer does not get configured.

I thought it was strange that printconf-tui runs instead of printconf-gui.

Running hal_lpadmin by hand says:

# hal_lpadmin -p
/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0
libhal.c 911 : Error sending msg: No property info.capabilities on
device with id
/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0

printconf-tui has the automation code that is run as root.  The dialog
is a seperate userspace process.  The URI you are using looks wrong. 
That looks like the parent of the device.  It should be:

/org/freedesktop/Hal/devices/usb_usb_device_4f9_d_100_-1_noserial_0

Also run gconf-editor as your user and check the /system/printing keys.  

if there is anything in there please run:

gconftool-2 --recursive-unset /system/printing

Now unplug your printer and plug it back in.  You should get the dialog.

Created attachment 105768 [details]
Output from lshal with USB Brother HL-1440 printer attached

Still no dialog.  See comment #34.  I see all kinds of printer configuration
processes listed by top but no dialog.	Yes, I am clearing out gconf's
/system/printing.

Ah, for some reason your new lshal output is not detecting your
printer as having the capabilities of a printer (the old one did).  We
detect this using the /sys directory.  can you install the "tree"
program and attach the output of this command:

tree /sys

It looks like it might be a kernel problem.

Created attachment 105838 [details]
Output of tree /sys

Uh oh.	I use a custom-built kernel.  I have not changed my kernel config since
this worked, but I have moved on to a new version.  A quick look at Red Hat's
kernel patches did not reveal any USB printer-specific patches, though.

Did you load the usblp module?  Can you try booting a stock kernel and
see if the problem is fixed?  If that is the case we can at least
narrow it down to the kernel. 

This does NOT seem to be kernel related.  

I pulled in an update on Thursday that gets almost fixes this (NO
kernel changes).  I once again was prompted for a driver when I
plugged in my printer.  Selecting the proper driver updated
/etc/cups/printers.conf and /etc/cups/ppd/hl-1440-series-1.ppd. 
HOWEVER, I had to manually re-start cups in order to get applications
to notice the newly configured printer.

So we are almost back to the good state we were in at comment #28.

I don't know what package update fixed this.  Here is a list of the
packages updated since comment #34:

Oct 27 11:17:56 Installed: net-snmp-libs.ppc 5.1.2-11
Oct 27 11:18:03 Installed: net-snmp.ppc 5.1.2-11
Oct 27 11:18:40 Installed: ethereal.ppc 0.10.6-3
Oct 27 11:43:43 Installed: ethereal-gnome.ppc 0.10.6-3
Oct 28 11:35:50 Updated: libxml2.ppc 2.6.14-2
Oct 28 11:35:52 Updated: libgcc.ppc 3.4.2-6.fc3
Oct 28 11:36:30 Updated: python.ppc 2.3.4-11
Oct 28 11:36:51 Updated: hal.ppc 0.4.0-9
Oct 28 11:37:14 Updated: libgcj.ppc 3.4.2-6.fc3
Oct 28 11:37:16 Updated: libstdc++.ppc 3.4.2-6.fc3
Oct 28 11:37:18 Updated: cups-libs.ppc 1:1.1.22-0.rc1.8
Oct 28 11:37:21 Updated: libstdc++-devel.ppc 3.4.2-6.fc3
Oct 28 11:38:11 Updated: libgcj-devel.ppc 3.4.2-6.fc3
Oct 28 11:38:15 Updated: NetworkManager.ppc 0.3.1-2
Oct 28 11:38:23 Updated: initscripts.ppc 7.93.2-1
Oct 28 11:38:46 Updated: libgal2.ppc 2:2.2.3-3
Oct 28 11:38:49 Updated: cpp.ppc 3.4.2-6.fc3
Oct 28 11:38:58 Updated: gcc.ppc 3.4.2-6.fc3
Oct 28 11:39:03 Updated: lvm2.ppc 2.00.25-1.01
Oct 28 11:39:07 Updated: gcc-java.ppc 3.4.2-6.fc3
Oct 28 11:39:11 Updated: libxml2-python.ppc 2.6.14-2
Oct 28 11:39:24 Updated: python-devel.ppc 2.3.4-11
Oct 28 11:39:29 Updated: redhat-menus.noarch 1.13-1
Oct 28 11:39:48 Updated: cups.ppc 1:1.1.22-0.rc1.8
Oct 28 11:39:52 Updated: gcc-c++.ppc 3.4.2-6.fc3
Oct 28 11:39:55 Updated: hal-gnome.ppc 0.4.0-9
Oct 28 11:39:57 Updated: NetworkManager-gnome.ppc 0.3.1-2
Oct 28 11:40:08 Updated: libxml2-devel.ppc 2.6.14-2
Oct 28 11:40:10 Updated: hal-devel.ppc 0.4.0-9
Oct 28 11:40:12 Updated: cups-devel.ppc 1:1.1.22-0.rc1.8
Oct 28 11:40:15 Updated: fedora-logos.noarch 1.1.29-1

Do you have SE-Linux turned on?

SELinux is not enforcing its policy.  I have turned it off
semi-permanently as I work on bugs like this one.

I seriously doubt SELinux has anything to do with this, as none of the
daemons and programs in the code path (dbus, cups, user session) are
currently restricted by the targeted policy.

Do you see avc denials in /var/log/messages?  If not, it's
overwhelmingly likely the bug is elsewhere.  If you want to turn it
off temporarily, please use "setenforce 0".

Ok, the only other thing I can think of is the program you are using
does not listen to cups updates and only gets a list of printers when
it is started.  Have you tried plugging in the printer and then
starting the program?  Keep in mind it can take upwards of 30 seconds
for the configuration to catch (the app I use to test is gedit).  I'm
wondering if the codepath has some oddities on ppc also.  That is most
unlikely though.  Perhaps you can stop the cups-config-daemon and run
it by hand using --daemon=no and post that output.   Thanks for
helping test the code.

As I mentioned above, SELinux is not enforcing my policy.  I'm pretty
familiar with SELinux and I have it off for the purpose of performing
tests like these.

Here is some more information:

1.  Remove all references to the printer from configurations using
system-config-printer.

2.  gconftool-2 --recursive-unset /system/printing

3.  Plug in printer.

4.  I get prompted for a driver.

5.  Cups config is updated (/etc/cups/printers.conf,
/etc/cups/ppd/hl-1440-series-1.ppd, etc).  I visually confirm that
these configurations are correct at this point.

6.  I watch top until all of the configurations processes are done. 
Cups-config-daemon says:

[root@imp /]# cups-config-daemon --daemon=no
Now run printconf-backend (or restart lpd service).

7.  At this point I do NOT see the printer listed in abiword or
gnumeric's print dialogs.

8.  lpq says, "lpq: error - no default destination available."

9.  Restart cups with /etc/init.d/cups restart.

10. lpq now says, "hl-1440-series-1 is ready, no entries."

11. Printer shows up in abiword and gnumeric's interfaces.

Can you try again but instead of killing cupsd can you do a kill
-SIGHUP <cupsd's pid>.  That is what should be happening in
cups-config-daemon.  If that doesn't update your printer list then the
problem is in cupsd on ppc.

Manually executing "kill -SIGHUP <cupsd's pid>" DOES get the printer
to show up.

I have the same basic problem; I have an HP 2550Ln which I've connected via  
USB. I can see that /etc/cups/cupsd.conf has been updated, but I don't get  
access to the printer until I do "service cups reload".  
  
I'm using Fedora Core 4, with KDE, and all updates. SELinux is disabled. I 
don't have eggcups running (should I?). 

P.S. No kind of alerts or questions or notifications pop up on my desktop at 
all (should they?) 

I have not had a problem with this lately.  I will reopen this bug if it is
encountered again.