[gentoo-amd64] CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[gentoo-amd64] CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Mark Knecht]

After doing some updates which I think included CUPS my printer is no
longer working. I tried deleting the printer and asked CUPS to find
new printers. It found the printer and then after a second or two said
it had installed what needed to be installed. However when I try to
print a test page it fails and I see this message in the CUPS web
interface:

"/usr/libexec/cups/filter/foomatic-rip failed"

Of course revdep-rebuild wants to rebuild lots and lots of stuff - far
too much for just fixing this so I'll attack that issue later this
evening:

emerge --oneshot -p =media-libs/gst-plugins-base-0.10.14
=media-libs/gstreamer-0.10.14 =gnome-base/libgnomeprint-2.18.3
=app-text/ghostscript-esp-8.15.4-r1
=gnome-extra/evolution-webcal-2.12.0 =gnome-extra/gnome-media-2.20.1
=gnome-extra/libgsf-1.14.7 =gnome-extra/bug-buddy-2.20.1
=gnome-extra/evolution-data-server-1.12.3 =net-libs/libsoup-2.2.104
=net-print/libgnomecups-0.2.2 =net-print/gnome-cups-manager-0.31-r2
=net-fs/samba-3.0.28 =kde-base/kdelibs-3.5.8-r3 =media-gfx/gimp-2.2.17
=mail-client/evolution-2.12.3-r1

Since I have foomatic-filters installed I tried emerging it and
restarting CUPS but I'm still getting the same error message.

Anyone have any knowledge about this sort of failure?

The CUPS interface is currently showing this:

Description: HP PSC 1600 series
Location: Local Printer
Printer Driver: HP PSC 1600 Foomatic/hpijs (recommended)
Printer State: idle, accepting jobs, published.
Device URI: usb://HP/PSC%201600%20series?serial=MY583F32PDL0

hpijs isn't a package:

lightning ~ # eix hpijs
No matches found.
lightning ~ #

but I found something not installed, and I don't think ever installed,
called hplip, which says it contains hpijs:

lightning ~ # eix hplip
* net-print/hplip
     Available versions:  2.7.10 ~2.7.12 ~2.7.12-r1 {X doc fax minimal
parport ppds scanner snmp}
     Homepage:            http://hplip.sourceforge.net/
     Description:         HP Linux Imaging and Printing System.
Includes net-print/hpijs, scanner drivers and service tools.

Inside of CUPS it's telling me it's using Foomatic/hpijs (en) so I
thought it was doing what it's supposed to do but it isn't working.

Has there been some sort of printer driver changes in portage that has
caught me off guard? I need to get this working ASAP of kids and
homework.

Thanks in advance,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Mark Knecht]

On Mon, Mar 24, 2008 at 4:25 PM, Mark Knecht <markknecht@gmail.com> wrote:
> After doing some updates which I think included CUPS my printer is no
>  longer working. I tried deleting the printer and asked CUPS to find
>  new printers. It found the printer and then after a second or two said
>  it had installed what needed to be installed. However when I try to
>  print a test page it fails and I see this message in the CUPS web
>  interface:
>
>  "/usr/libexec/cups/filter/foomatic-rip failed"
>
>  Of course revdep-rebuild wants to rebuild lots and lots of stuff - far
>  too much for just fixing this so I'll attack that issue later this
>  evening:
>

Solved by, I think, emerging Ghostscript. Anyway, it's working now.

Sorry for the noise.

Cheers,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0803241822v267dcacl64108b01cf53b3b4@mail.gmail.com, excerpted
below, on  Mon, 24 Mar 2008 18:22:20 -0700:

>>  Of course revdep-rebuild wants to rebuild lots and lots of stuff

I see you solved the original problem, but this bit worries me.

You used "of course", which makes it sound as if it's "natural" to you to 
have revdep-rebuild want to rebuild "lots and lots of stuff".  I can 
assure you that's NOT the case here, and I don't believe it should EVER 
be the NORMAL case on a well maintained Gentoo system.  Once in a very 
long time, there may be individual upgrade cases where it happens because 
half the system depends on the upgraded library and the upgrade changed 
the ABI, the upgrade to expat-2 I believe it was comes to mind, but once 
that rebuild is done (and I'd say two weeks is plenty of time for that), 
it should be months, likely years, before any more more than perhaps a 
half dozen to a dozen packages (max) ever appear together at once on a 
revdep-rebuild.  I think it has been since that expat upgrade that I've 
ever had a half dozen items listed at once in revdep-rebuild here, and I 
even doubled that above, to a dozen, for those that run a bit sloppier 
installation than I.

I'd recommend that people do a world upgrade every couple of weeks 
minimum (noting that if you do it every week or every few days, you'll 
have less to upgrade all at once), always do an etc-update (or equivalent 
if using a different tool) after merging anything, just to be sure, and 
do a revdep-rebuild also at least every couple weeks, again noting that 
doing it more often means less stuff at once to worry about.  That, plus 
a regular (say once a month or so minimum) emerge --newuse, revdep-
rebuild, emerge --depclean, and another revdep-rebuild just to be sure 
after the depclean, will help keep the system clean and well maintained, 
and that "Of course revdep-rebuild wants to rebuild lots and lots of 
stuff" problem should become a thing of the past. =8^)

Of course, don't forget the --pretend first, especially on --depclean, 
but really on all the above, so you have some idea of what it's going to 
do and can add packages to your world file or whatever if necessary.  And 
again, those are what I'd recommend as minimums.  Remember that if you do 
it more frequently, you have far less to deal with at once, making the 
job far easier. =8^)  

It's just that "revdep rebuild wants to rebuild lots and lots of stuff" 
should be a very unusual event, not EVER an "of course" event  If that's 
NOT the case, if it HAS become an "of course" event, it's simply because 
someone has been slacking.  While it'll only mean minor stuff broken on a 
day to day basis, sooner or later it'll catch up to you, either with a 
compound failure so large it's difficult to recover from (a broken gcc 
making it impossible to recompile anything to fix it, for instance, or a 
broken python making it impossible to emerge anything), or with an old 
and stale package you've forgotten about getting a security vuln that 
someone takes advantage of, and you get cracked.

(Yeah, I know that some folks don't upgrade for six months or more at a 
time...  I never really understood why these folks bother to run Gentoo, 
as at that point, it's likely going to be easier doing the binary 
distribution update thing, with upgrades coming out about every six 
months, than trying to do an upgrade a piece at a time on Gentoo, without 
breaking anything vital in the process.  Yes, it's possible to do six 
month upgrades on Gentoo, just like it's possible to only install the 
binary packages on the release and package media and never compile 
anything, but it's really not /designed/ for that, and there are other 
distributions that handle those usage cases rather better, so Gentoo's a 
rather poor choice for them.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Mark Knecht]

Hi Duncan

On Mon, Mar 24, 2008 at 8:52 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Mark Knecht" <markknecht@gmail.com> posted
>  5bdc1c8b0803241822v267dcacl64108b01cf53b3b4@mail.gmail.com, excerpted
>  below, on  Mon, 24 Mar 2008 18:22:20 -0700:
>
>
>  >>  Of course revdep-rebuild wants to rebuild lots and lots of stuff
>
>  I see you solved the original problem, but this bit worries me.
>
>  You used "of course", which makes it sound as if it's "natural" to you to
>  have revdep-rebuild want to rebuild "lots and lots of stuff".  I can
>  assure you that's NOT the case here, and I don't believe it should EVER
>  be the NORMAL case on a well maintained Gentoo system.

Well, my experience is a bit different than yours. I'm sure the way I
maintain my systems, reading between your lines, is almost certainly
more lax than you care for. I do an emerge -DuN system in general
about once a week, but emerge -DuN world isn't going to happen any
more often than once every 6-8 weeks here. I don't have time to deal
with the issues that come up with all this stuff to do it more than
maybe 5-6 times per year. Even that often is pushing it, but it's
about what I do.

In general I look at emerge -DuN world once a week and see what's up.
Typically I'll take one major app and let everything in its dependency
tree get updated, but not the complete system. If I'm lucky, when I do
finally get to the emerge -DuN world I've already done a major app, or
maybe Gnome, so there isn't all that much to do.

While I'm sure we probably have different ideas of 'lots and lots of
stuff' I'm pretty clear that it's generally too much for me to deal
with in one step. I have work to do here and the machine is busy. My
experience with revdep-rebuild is that it wants to build some old
things, but then these things have been removed from portage and it
cannot, so I have to start looking for solutions. That requires
reading and thinking so it gets put on the back burner.

The other reason I'll almost NEVER do a real emerge -DuN world is that
we use MythTV here. We have 5 machines that run Myth, either as front
ends or back ends. Unfortunately, with Myth if you update the server
you have to update every machine on the network which causes problems
for the family so I don't do it.

Now, it's also possible to start masking things to hide some of these
issues. I'll do that with something like Myth for 2-3 months, maybe
longer, and then finally have to spend a few days updating all the
machines.

revdep-rebuild today wanted to rebuild 16 apps. To me that's lots and
lots. Maybe not to you.

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0803242145le54b0c9we8ba99a79c5c9f9@mail.gmail.com, excerpted
below, on  Mon, 24 Mar 2008 21:45:30 -0700:

> Well, my experience is a bit different than yours. I'm sure the way I
> maintain my systems, reading between your lines, is almost certainly
> more lax than you care for. I do an emerge -DuN system in general about
> once a week, but emerge -DuN world isn't going to happen any more often
> than once every 6-8 weeks here. I don't have time to deal with the
> issues that come up with all this stuff to do it more than maybe 5-6
> times per year. Even that often is pushing it, but it's about what I do.

Well, if you note, I didn't push the --deep (= -D).  That'll save you 
some, but at the expense of rather more pain (including a longer revdep-
rebuild list since you'll likely have every dependency on the library 
listed by then, instead of just a couple) when you /do/ eventually update 
those deep dependencies.

I'd say do the system once a week, do the world every couple weeks, 
always do a revdep-rebuild after the world and keep your --depclean up to 
date so the revdep-rebuild isn't rebuilding dependencies you don't even 
need any more, but don't worry too much about --deep, especially on 
primarily stable systems (like the myth boxes you mention).  

Also, there's certainly less reason to worry about updates on machines 
that don't do Internet and/or don't hold private data (as may be the case 
with some of your myth boxes) anyway.  Six weeks or two months is still 
pushing it and may lead to a lot of pain when you /do/ upgrade such 
internal boxes, but there's no urgency other than that.

> My experience with revdep-rebuild is that it wants to build some old
> things, but then these things have been removed from portage and it
> cannot, so I have to start looking for solutions. That requires reading
> and thinking so it gets put on the back burner.

That's really part of the pain of not upgrading frequently enough.  As 
such, it's avoidable.  Upgrade before something is removed, and you won't 
have that problem.  Of course, there's a trade-off here between --deep 
and this pain, as well.  If you don't use --deep, you'll encounter this 
problem relatively more frequently.  However, it's a trade-off that's up 
to you.

> The other reason I'll almost NEVER do a real emerge -DuN world is that
> we use MythTV here. We have 5 machines that run Myth, either as front
> ends or back ends. Unfortunately, with Myth if you update the server you
> have to update every machine on the network which causes problems for
> the family so I don't do it.

You have multiple machines.  Are you making use of binary packages?  
Assuming you use portage, FEATURES=buildpkg on your first upgraded 
machine, with all machines set to use the same PKGDIR and using emerge 
--usepkgonly (-K) on everything but the first one (at least where USE 
flags are the same, and assuming compatible machine and instruction 
types) should be a real boon to you.

IOW, if you are recompiling the package for each machine it's deployed 
on, you are wasting way more time and energy on that than you are saving 
by updating so infrequently.  If it's possible to do the build once and 
use it on multiple machines, it's very likely worth doing so, even if it 
means modifying USE flags and CFLAGS/CXXFLAGS a bit so you /can/ use a 
common binary.  That could just make the upgrades on those myth machines 
much less trouble for you.

Even if my "big" machine was amd64 and the others were x86, as just might 
be your case, I'd still consider FEATURES=buildpkg, and either decide to 
run the big machine at 32-bit, or run it 64-bit but with a 32-bit chroot, 
so it could still could build the binaries for the others.  (Of course, 
for same machine arch, you could also run distcc if desired, but that's 
getting to be less of an advantage as quad-core multi-gig memory machines 
work their way into the mainline.)

> revdep-rebuild today wanted to rebuild 16 apps. To me that's lots and
> lots. Maybe not to you.

Well, I'd call that "lots", but not "lots and lots". =8^)  "Lots and 
lots" would to me start at say a couple dozen, so 24, maybe 30.  
Certainly, a KDE upgrade, typically 90-120 packages on my machine, would 
qualify for three "lots", tho I'd more likely term it "a hundredish" 
packages.

Interesting how such words mean slightly different things to different 
people, isn't it?  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Duncan]

Duncan <1i5t5.duncan@cox.net> posted pan.2008.03.25.11.05.06@cox.net,
excerpted below, on  Tue, 25 Mar 2008 11:05:07 +0000:

> You have multiple machines.  Are you making use of binary packages?
> Assuming you use portage, FEATURES=buildpkg on your first upgraded
> machine, with all machines set to use the same PKGDIR and using emerge
> --usepkgonly (-K) on everything but the first one (at least where USE
> flags are the same, and assuming compatible machine and instruction
> types) should be a real boon to you.

This one's probably worth pointing out by itself.  With multiple 
machines, particularly all those myth client machines likely configured 
virtually identically, you really /are/ wasting time if you are 
rebuilding from source for each one.  That's what Features=buildpkg, the 
PKGDIR var, and --usepkgonly are for, after all. =8^)  (I assume the 
other-than-portage package managers have similar binary package features, 
but wouldn't know the settings or how to invoke them.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list