Bug#122393: How's omni coming?
On Wed, 2002-08-21 at 17:41, David D. Kilzer wrote:
> Unless I misunderstood the Debian BTS, I only filed a request for
> package (RFP) for Omni, not a full-fledged intent to package (ITP).
No, you're right; I misread the bug report. Sorry about that.
I was inquiring because there is interest elsewhere for the Omni drivers
as well. I may ITP it.
> However, when I went to build Omni on my Debian Potato system, I ran
> into a gcc compiler bug.
>
> [ 487685 ] 0.5.1 fails to build w/link errors
> http://sourceforge.net/tracker/index.php?func=detail&aid=487685&group_id=18713&atid=118713
>
> trap when compiling file
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view+audit-trail&pr=6316
>
> This bug has since been fixed in gcc-3.1, but since I'm not using Woody
> yet at work (and I have a work-around for the Okidata ML-590 issue), I
> don't really have a need to build the package.
Not to mention that gcc 3.1 isn't in woody, so you'd still be stuck.
Unless the omni people did something to mitigate the problem, you'd
likely be forced to stick with sid.
OTOH, if I package it, I'll likely try to get it building for woody as
well as sid.
> Besides, I'm not sure how Omni would fit into the linux printing
> "architecture" as currently set up on Debian. I'm still trying to
> figure out what to use (lprng versus cups).
>From what I can tell, the omni people have CUPS hooks working fairly
well.
I'd recommend using CUPS, but as the maintainer for cupsys in Debian,
I'm biased. :-) I personally feel that the CUPS design is much better
than the old BSD or SysV designs. The only caveat I'd have is that CUPS
is still less mature than lprng; this is becoming less and less true
over time, however.
Reply to: