Greetings, I'm a gentoo user since 4 years. I don't say everything within it is perfect, but the printing system, one of the things I use less often, every time I have the misfortune to touch it, it has problem. I use the printer once every 6 months, but I've always have to hack, search forums, hack, hack again for 2 days before being able to print a single page correctly. Everything gets screwed up at the next emerge world. Shameful. * once pstops failed * once pstoraster failed * once I get a 100% black page instead of a photograph * once libpng 1.4 breaks. Remerging 1.2 works for a few weeks, then breaks again. * once ghostscript-gpl 8.71 is broken. I re-emerge ghostscript-gpl-8.70-r1, even patch the ebuild manually, but it's the same * some times I got no message at all, and I have to debug, over and over again. Tons of ink, paper and time wasted This both applies to x86, and ~x86 trees. I don't know what else to do. Please, consider taking some action. Select a STABLE configuration for the printing system, and KEEP IT, along with the proper dependencies. If you know it's BROKEN, or you know almost nothing about it, please mask it out from portage, mark it as ALPHA, and don't even keep in in the testing tree. Doesn't this make sense? Is this a too big request? Packages (also the unstable ones!) like Java, Apache, MySql, Bind, with few exceptions have all been working ***reliably*** for years, with very few maintenance needed! Why are the printing packages so problematic, unstable, unreliable, unusable, every time?! Regards, Skaumo Reproducible: Sometimes
skaumo, to me, printing has been a pain in the neck in general (not just in Gentoo). I stay away from it when possible, and am thus not part of the gentoo printing team, so I can't totally speak for them, but I have some suspicions on why there are common problems. The diversity of printers is a big burden on developers -- it can make it so hard to reproduce bug reports. I have written custom printer drivers for embedded devices, and it is amazing how completely different printers from the same manufacturer can be. Aside from maintainers trying to reproduce bugs, those new printer series need new drivers which causes upstream driver churn. This creates pressure against keeping the same stable ghostscript version for too long, since a stable ghostscript that doesn't support a year-old printer would be pretty disappointing too. Libraries like libpng need to keep moving forwards in versions as well -- printing is only one among many uses of libpng. Who knows how many different printing setups were tested when libpng was being stabled -- it belongs to the base-system team, who have plenty of things to do other than test every graphics library with a wide range of printer setups. I really don't know the solution to your problem of printing instability; my best suggestion is that you get involved with the printing team by volunteering to test printing-related package with your setup when they are candidates to become stable. If we had a team of users who tested against a variety of setups, then we might actually get somewhere in printing quality control. However, given that you normally only print once every 6 months, that may not sound very appealing to you... if you can't think of something else specific to help the printing team manage this difficult task better, we'll have to close this bug as "can't fix". You are still welcome to post to their mailing list to try to brainstorm on ways to improve stability, but if so I recommend taking a positive approach rather than coming across as only negative (for instance don't imply they are less competent than the apache maintainers -- it really is a lot easier to get a web server stable than the whole printing stack for N different popular brands of printer).
I didn't find any useful information in this bug, sorry. If you have specific problems to report, then provide the proper logs, and steps to reproduce. One bug per one package.
