booman |
Sunday 28 April 2013 at 19:10
|
booman
|
yeah, me either... guess I'll have to do some research on ptrace_scope
|
petch |
Monday 29 April 2013 at 0:01
|
petch
|
ptrace() is a system call that allows a process to "control" another one (http://en.wikipedia.org/wiki/Ptrace). This is a feature mainly aimed at debuggers, but historically has been widely available: any process of one user could control any other process of the same user. There has been some abuse of this feature in the wild by malwares, so a kernel patch has been proposed, and later incorporated in the official sources in kernel 3.4, to disable or restrict the availability of ptrace(), so that for example a process could only be ptrace()d by one of its parent processes, which is usually the case if it's under debugging. Now, why some Windows programs need more than that when run under Wine, I don't exactly know, I suppose Wine needs ptrace() to emulate some Windows calls...
|
booman |
Wednesday 1 May 2013 at 4:00
|
booman
|
I guess it worked. Terminal printed: 0 thats all.... Then again I did type "echo"
|
Ronin DUSETTE |
Wednesday 1 May 2013 at 4:04
|
Ronin DUSETTE
|
Whatever output came out, thats what was put into that file. :)
|
booman |
Wednesday 1 May 2013 at 9:07
|
booman
|
Then it worked, I'll leave it as "solved"
|
petch |
Wednesday 1 May 2013 at 9:43
|
petch
|
I opened a bug report so we can think of ways to make this message more obvious. http://www.playonmac.com/en/issue-2186.html
|
booman |
Wednesday 1 May 2013 at 19:43
|
booman
|
Cool, thank you. Like I said before... not sure why I got the error in the first place. I have been installing dotnet30 for months and never got the error. I havn't updated for at least a month either.
|
petch |
Wednesday 1 May 2013 at 20:42
|
petch
|
Nothing mysterious, that's because GNU_Raziel recently updated the dotnet* install scripts and added a test for this condition in POL_Install_dotnet30: http://www.playonmac.com/en/changelog-563-POL_Install_dotnet30.html
|
booman |
Wednesday 1 May 2013 at 20:43
|
booman
|
ah, now it makes sense... I was still using the old one cached on my machine. I'll download the newer dotnet
|
petch |
Wednesday 1 May 2013 at 21:41
|
petch
|
Install scripts are never cached but always downloaded directly from the server. The files they use are cached, but validated using a hash. There should be no caching issues.
|
booman |
Wednesday 1 May 2013 at 21:45
|
booman
|
I've always kept all of my librariesm, components, packages in the /home/booman/.PlayOnLinux/resources directory and have backed them up. I do a lot of manual installations, so if the dotnet download is already in the resources folder, won't PlayOnLinux install it from there instead of downloading again? My goal is to keep the most commonly used libraries, packages, components on the local computer so I don't have to download them each time I install a game.
|
petch |
Wednesday 1 May 2013 at 23:16
|
petch
|
What you're tailking about are not install scripts, you're missing a huge piece of the puzzle.
|
booman |
Wednesday 1 May 2013 at 23:20
|
booman
|
nope, I was doing a manual install and went to install dotnet30. That is when I got the initial error. Sorry I didn't mention that earlier...
|
petch |
Wednesday 1 May 2013 at 23:38
|
petch
|
And if you think dotnet30 is dotnetfx3.exe, I urge you to try installing .NET 3.0 by running dotnetfx3.exe directly. Edited by petch
|
booman |
Wednesday 1 May 2013 at 23:54
|
booman
|
Actually NetFx20SPx86.exe & dotnetfx3.exe only appeared after I deleted the dotnet30 folder in my resources directory and tried to download/install again in PlayOnLinux. This is why I was confused. Lets just start over. If I need to install dotnet30 in a manual installation I should select: POL_Install_dotnet30 correct?
|