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)
If you are feeling bored [ ], 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 ).
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.
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.
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.
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..?
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?
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.
Hmm, but it also happens while transferring from NTFS to NTFS (the very same sda1).
Is it ok?
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,
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.
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
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64