Page 4 of 20

Posted: Wed 06 Feb 2013, 11:30
by zigbert
01micko wrote:-Sigmund, I remember your ATI card gives trouble since 431 IIRC, you included a special driver in Stardust puplet. Was that the radeon-hd xorg driver? If so I can compile it and put it in. I will message rurario (Norwegian Slacker, works at Opera) about the 16 bit colour bug in Opera. Also I'll post it in the Opera forum. Maybe it's an easy fix for them. You could also try opera-12.11 (pets @ ibiblio, nluug) and see if the issue is there. We are using now latest 12.13 (Feb 1 release).
Those days I ran Nvidia, and I always used Nvidia's driver to get 3D acceleration (Torcs)

I will test Opera/16bit...


Sigmund

Posted: Wed 06 Feb 2013, 11:49
by 01micko
zigbert wrote:My alternative pmount is updated
- to reflect the latest changes in woof-pmount.
- Fix correct size of used-space-bar


http://murga-linux.com/puppy/viewtopic. ... 166#619166
Thanks, got it.

If you are feeling bored [ :lol: ], do you want to take a look at /usr/sbin/partview gui? (strictly from 5.4.x). It has Barry's svg code but I took out the bold fonts and added the vscroll because I have 16 partitions and it went off screen. I know there is folks out there with more partitions (MHHP :wink: ).

Posted: Wed 06 Feb 2013, 11:53
by Billtoo
01micko wrote:
Sage wrote: ....hope that doesn't mean ferreting around to find another 'correct' FP, mick?!
No idea.. but if you can keep track of what works I'd be grateful for a list so I can patch GetFlash. Ta.
I have flashplayer installed that I downloaded from adobe.com, it's 17m in size (17410532bytes), works with the new opera pet at cnn and youtube.com

Posted: Wed 06 Feb 2013, 11:54
by zigbert
Mick
It is the partview code that is used in my alternative pmount.
Do we need both?


Sigmund

Posted: Wed 06 Feb 2013, 12:02
by 01micko
zigbert wrote:Mick
It is the partview code that is used in my alternative pmount.
Do we need both?


Sigmund
I guess I should just symlink it then eh? 8) (done)

Posted: Wed 06 Feb 2013, 12:05
by 01micko
billtoo
17410532bytes
:shock: .. compressed?

Does your VLC pet depend on LUA? Or is it part of the package? I see lots of LUA files in there.

Posted: Wed 06 Feb 2013, 12:08
by Billtoo
01micko wrote:billtoo
17410532bytes
:shock: .. compressed?

That's the size of the file in /usr/lib/mozilla/plugins

Does your VLC pet depend on LUA? Or is it part of the package? I see lots of LUA files in there.
No, it's part of the package.

Posted: Wed 06 Feb 2013, 12:17
by 01micko
Billtoo wrote:
01micko wrote:billtoo
17410532bytes
:shock: .. compressed?

That's the size of the file in /usr/lib/mozilla/plugins

Does your VLC pet depend on LUA? Or is it part of the package? I see lots of LUA files in there.
No, it's part of the package.
Ok, thanks for clarifying.

Now, is it the LUA built by CatDude? (which is in PPM)

If so (or even not) is it a different path from standard LUA? It's a bit of a dilemma if someone installs conky (depends LUA and drags it in) and then uninstalls conky it will berak your VLC, (or vice versa). If it has it's own unique install path from the original LUA then that's fine.

Posted: Wed 06 Feb 2013, 12:18
by zigbert
Confirming that Opera/Flash is working with 24bit colordepth.

Posted: Wed 06 Feb 2013, 12:24
by Billtoo
01micko wrote:
Billtoo wrote:
01micko wrote:billtoo :shock: .. compressed?

That's the size of the file in /usr/lib/mozilla/plugins

Does your VLC pet depend on LUA? Or is it part of the package? I see lots of LUA files in there.
No, it's part of the package.
Ok, thanks for clarifying.

Now, is it the LUA built by CatDude? (which is in PPM)

If so (or even not) is it a different path from standard LUA? It's a bit of a dilemma if someone installs conky (depends LUA and drags it in) and then uninstalls conky it will berak your VLC, (or vice versa). If it has it's own unique install path from the original LUA then that's fine.
I'll attach it to this message, I made the pet in slacko, it needed a change in the source code so it would work when compiling vlc, had to add -fPIC to a line in the source code.

Posted: Wed 06 Feb 2013, 12:35
by 01micko
billtoo, thanks for that, I see it's PREFIX=/usr/local, that's fine in this instance because CatDude's is PREFIX=/usr (and it's 5.1.5). Anyway, they shouldn't conflict.

It may have been better though to add LUA as a dep in the pet.specs, just FYI. Thanks. Uploading to ibiblio now.

copy / move errors ntfs?

Posted: Wed 06 Feb 2013, 15:02
by peebee
Further testing of my rox drag and drop copy errors on Slacko 5.4.0.2

Pristine, manual, frugal install on an ntfs formatted disk with an ext2 savefile.

Error occurs after savefile creation.

On Slacko get errors for BOTH copy and move.

(for Dpup Wheezy 3.5.2.3 errors only occur for copy - not move)

Tested using specially created new directories with 16 files - see screenie.

Cheers
peebee

copy / move errors ntfs?

Posted: Wed 06 Feb 2013, 17:08
by SFR
@Peebee & @Mick

Same here (ext2 on NTFS) and it also happens (what is logical) with cp -a:

Code: Select all

cp -a /root/somefile /mnt/home
cp: preserving permissions for `/mnt/home/somefile’: Operation not supported
Looks like it has something to do with newer initrd.gz/bin/ntfs-3g - I rudely replaced it with older one from 5.4 and errors have gone...

EDIT:
Another workaround:
http://linux.die.net/man/8/ntfs-3g wrote:no_def_opts
By default ntfs-3g acts as if "silent" (ignore errors on chmod and chown), "allow_other" (allow any user to access files) and "nonempty" (allow mounting on non-empty directories) were set, and "no_def_opts" cancels these default options.
Removing this option in init script (lines 239 & 249) disables these copy/move errors caused by newer ntfs-3g, but the question is - if that option is really needed for something or if it can be thrown away safely..?

Greetings!

Posted: Wed 06 Feb 2013, 21:17
by 01micko
peebee

You will notice something when you copy something to ntfs .Permissions do change. Everything turns to 777. The bug really is that the copy doesn't fail, but I like the warning that perms have changed. That's important. Changing a restricted file to 777 has security implications.

I would like to see rox patched to show the warning but the error (failed copy) fixed. I may contact npierce about this one. What say you SFR?

Posted: Wed 06 Feb 2013, 21:38
by SFR
01micko wrote:I would like to see rox patched to show the warning but the error (failed copy) fixed. I may contact npierce about this one. What say you SFR?
Since files are being copied correctly, why not?
Warning would be fine - always good to know more than less. :wink:

Hmm, but it also happens while transferring from NTFS to NTFS (the very same sda1). :?
Is it ok?

Greetings!

Re: copy / move errors ntfs?

Posted: Wed 06 Feb 2013, 21:42
by rcrsn51
SFR wrote:Another workaround:
http://linux.die.net/man/8/ntfs-3g wrote:no_def_opts
By default ntfs-3g acts as if "silent" (ignore errors on chmod and chown), "allow_other" (allow any user to access files) and "nonempty" (allow mounting on non-empty directories) were set, and "no_def_opts" cancels these default options.
Removing this option in init script (lines 239 & 249) disables these copy/move errors caused by newer ntfs-3g, but the question is - if that option is really needed for something or if it can be thrown away safely..?
I can confirm the problem in Slacko 5402 when copying to an NTFS-formatted /mnt/home. And I can confirm that putting the old ntfs-3g 2010.1.16 in the init fixes it.

However, if you copy to an external NTFS drive, there is no problem. In that scenario, you are now using the new /bin/ntfs-3g. If you check "mount", the NTFS partition has "allow_other". But /mnt/home has "default_permissions".

I'm guessing that the definition of "default_permissions" has changed in the new ntfs-3g,

Posted: Wed 06 Feb 2013, 21:55
by SFR
Yep, it seems that the problem concerns only .../dev_save
Just created small sda2 NTFS partition and no errors while copying files there...

Greetings!

Posted: Wed 06 Feb 2013, 22:08
by 01micko
Frankly, I don't care about the rox ntfs error. You install to ntfs at your peril. I don't do it, it's only a "warning" type error and the real fix is to patch rox. Removing "no_def_opts" shouldn't be a problem though.

I do realise rcrsn51, you use flash drives formatted as ntfs, in that case then I see an issue, but that's not supported in universal installer and hardly any "new user" would know about or do that.

Posted: Wed 06 Feb 2013, 22:17
by peebee
01micko wrote:Frankly, I don't care about the rox ntfs error.
Hi Mick

Surely many new Puppy users will be trying Puppy by doing frugal installs on top of and beside an existing Windows system with an ntfs formatted disk - that's certainly how I started.....

Having red fail errors popup when you move or copy files is likely to put new users off completely.

Cheers
peebee

Posted: Thu 07 Feb 2013, 07:15
by James C
The always enjoyable experience of Adobe Flash......... :lol:

No problems on this Athlon XP box with 10.3r183.

EDIT:
Just checked, I'm also using 10.3r183 on the install on the P4 with no problems.