Re: [gentoo-user] cups and html
On Apr 8, 2015, at 18:27, hw h...@gartencenter-vaehning.de wrote: Hi, is there something special I need to do or to install to be able pipe html output from a cgi script to cups to have it printed as the output would be shown by a web browser? The output might differ some amount from the browser view. Is there a/another good way to print such output automatically without manually loading it into a web browser and printing it from there? Filter the file through html2ps. Ps-files can be natvely printed with CUPS. I think you can also insert such a filter to CUPS and then it will be able to print html natively -- -Matti
[gentoo-user] cups and html
Hi, is there something special I need to do or to install to be able pipe html output from a cgi script to cups to have it printed as the output would be shown by a web browser? Is there a/another good way to print such output automatically without manually loading it into a web browser and printing it from there?
Re: [gentoo-user] cups and html
On Wed, 08 Apr 2015 17:27:44 +0200, hw wrote: is there something special I need to do or to install to be able pipe html output from a cgi script to cups to have it printed as the output would be shown by a web browser? Pipe it through html2ps. -- Neil Bothwick Okay, I pulled the pin. Now what? Hey, where are you going? pgpJhgSj_RzmX.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Running gentoo ~amd64 as a virtualbox guest
On Wednesday, April 08, 2015 4:35:29 PM walt wrote: The problem is that Software Rasterizer is so slow and inefficient that the gnome3 shell specifically tests for it and refuses to start if it's found. Other guest linux distros report the Chromium rasterizer or maybe the llvmpipe rasterizer, both of which are fast enough to satisfy the gnome3 shell. What does eselect mesa list shows for Software Renderer? I think to use llvmpipe you'll need the llvm and gallium use flags for mesa and select the gallium renderer. -- Fernando Rodriguez
Re: [gentoo-user] Running gentoo ~amd64 as a virtualbox guest
On 04/08/2015 07:35 PM, walt wrote: I have a persistent problem (described below) with my ~amd64 guest machine and I can't figure it out. I run all the major linux distros as virtualbox guests so I can keep track of what's happening on planet non-gentoo, but only the ~amd64 gentoo guest machine is having this problem: Depending on what you are keeping track of, I would recommend using docker. It is far lighter-weight than a virtual machine in every respect - disk space, cpu utilization, etc. However, if you need to see graphical stuff (which it appears you do), then docker will not work. When I start an X session in the gentoo guest machine, the 3D video acceleration is emulated with the Software Rasterizer function of mesa, as shown below: # glxinfo | grep renderer OpenGL renderer string: Software Rasterizer The problem is that Software Rasterizer is so slow and inefficient that the gnome3 shell specifically tests for it and refuses to start if it's found. Have you tried setting VIDEO_CARD=virtualbox in make.conf and/or installing app-emulation/virtualbox-modules in your guest? Other guest linux distros report the Chromium rasterizer or maybe the llvmpipe rasterizer, both of which are fast enough to satisfy the gnome3 shell. So, could the problem be caused by the vbox package on my gentoo host machines? I don't know, but I can propose a test: If the other distros can detect a fast virtualized renderer, I doubt the host has a problem. That said, I have little virtualbox experience other than just playing around. Hope this helps, Alec
[gentoo-user] Running gentoo ~amd64 as a virtualbox guest
I have a persistent problem (described below) with my ~amd64 guest machine and I can't figure it out. I run all the major linux distros as virtualbox guests so I can keep track of what's happening on planet non-gentoo, but only the ~amd64 gentoo guest machine is having this problem: When I start an X session in the gentoo guest machine, the 3D video acceleration is emulated with the Software Rasterizer function of mesa, as shown below: # glxinfo | grep renderer OpenGL renderer string: Software Rasterizer The problem is that Software Rasterizer is so slow and inefficient that the gnome3 shell specifically tests for it and refuses to start if it's found. Other guest linux distros report the Chromium rasterizer or maybe the llvmpipe rasterizer, both of which are fast enough to satisfy the gnome3 shell. So, could the problem be caused by the vbox package on my gentoo host machines? I don't know, but I can propose a test: I know some of you have access to (real) machines that run non-gentoo distros (I'm too lazy to install a non-gentoo distro on my real boxes just to debug this silly problem) and so I thought maybe you could try the same test and report back your results :) Thanks!
