IIRC, there is some way to override this path, either at build time or
run time or both. I will look into it and see if I can build the DRI
library into the distribution. I didn't really care about it because I
always just use VirtualGL, but the software renderer really should work
for the purpos
I had the same problem in similar testing I have done. OpenSSH does
not return an error code for port bind failures. If someone knows
of a way to do this without opening ssh in a pipe and parsing the
output, I would like to hear it too This was my main reason in
s
On 2/14/11 4:02 PM, Eric Stadtherr wrote:
> Do you know of a way to check for the successful bind? One of the
> behaviors that drove me down the libssh path was that /usr/bin/ssh
> happily continues running despite failing to bind to the local port.
> Therefore there is no exit status to interrogat
This is an annoying problem I ran into when I was building and
distributing to a couple of machines. Using the build-xorg scripts,
it leaves the path hard set to the location of the xorg
libraries/modules instead of setting a path and installing them to
it with the main
On Mon, 14 Feb 2011 14:07:17 -0600, DRC wrote:
> On 2/14/11 5:42
AM, Adam Tkac wrote:
>>> I see a couple problems with this solution:
>>>
>>> 1. This method still closes the socket after identifying a
port,
>>> which would allow the port to be allocated again before
>>>
/usr/bin/ssh finally
On Mon, Feb 14, 2011 at 02:35:42PM -0600, DRC wrote:
> On 2/14/11 2:25 AM, Martin Koegler wrote:
> I disagree. I think there is something system-specific that is
> occurring and that you would be observing this problem very plainly if
> you were using my system. Others on different systems may ru
On 2/14/11 2:25 AM, Martin Koegler wrote:
> The performance problems are triggered by running running high
> performance applications like virtualgl, which is not part of any
> major distribution]. So any user of default installation of a major
> linux distribution has either an Xvnc without 3D sup
On 2/14/11 5:42 AM, Adam Tkac wrote:
>> I see a couple problems with this solution:
>>
>> 1. This method still closes the socket after identifying a port,
>> which would allow the port to be allocated again before
>> /usr/bin/ssh finally gets around to opening the forwarding channel
>>
On 2/14/11 4:52 AM, Adam Tkac wrote:
> I successfully use CMake & Visual Studio 2008 Express to build all
> Windows stuff with all features. And I'm also using MS VStudio for
> debugging & testing on Windows. I will extend BUILDING.txt with
> information how to build GNUTLS support on Windows.
>
>
Bug Tracker item #3178498, was opened at 2011-02-11 19:06
Message generated for change (Settings changed) made by atkac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3178498&group_id=254363
Please note that this message will contain a full copy of the
Bug Tracker item #3178498, was opened at 2011-02-11 19:06
Message generated for change (Comment added) made by atkac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3178498&group_id=254363
Please note that this message will contain a full copy of the com
Bug Tracker item #3178498, was opened at 2011-02-11 19:06
Message generated for change (Settings changed) made by atkac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3178498&group_id=254363
Please note that this message will contain a full copy of the
On Fri, Feb 11, 2011 at 08:16:17PM -0700, Eric Stadtherr wrote:
> On 02/11/2011 12:15 PM, DRC wrote:
> >On 2/11/11 12:06 PM, Eric Stadtherr wrote:
> >>The port conflict arises when you start two vncviewers with the "-via"
> >>flag back-to-back pointed to two different servers. In lockstep, both
> >
On Sat, Feb 12, 2011 at 02:22:41AM -0600, DRC wrote:
> I am going to suggest strongly that, in conjunction with moving to a
> unified CMake system, we remove our in-tree version of libjpeg-turbo and
> start sourcing LJT from upstream (or, in the case of Fedora, simply
> building against the system
On Sun, Feb 13, 2011 at 04:32:46PM -0600, DRC wrote:
> So what exactly is a "default" Linux installation? I don't think anyone
> can reasonably conclude that what is true for their Linux installation
> is true for all Linux installations.
The performance problems are triggered by running running
15 matches
Mail list logo
