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.
