Posted: Mon 06 Feb 2012, 12:52
Ahh. I have been so accustomed to .xz compression support...long time now...that I had forgot that not all Puppies have it. Good to know. Thanks 01micko.
READ-ONLY Archive
https://oldforum.puppylinux.com/
Does that mean that wen 8-bit use lucid puppy to bild then it fails but ifAt the moment it's able to produce a concept distro called "Subito", for the x86_64 processor architecture, which consists of Slackware 13.37 and Puppy packages, just like Slacko
So how do I add, say .xz compression support to a puppy version?pemasu wrote:Ahh. I have been so accustomed to .xz compression support...long time now...that I had forgot that not all Puppies have it. Good to know. Thanks 01micko.
Code: Select all
#yes|python|python|exe>dev,dev,doc,nls
yes|python|python|exe,dev,doc,nls
Code: Select all
file -bi -
Code: Select all
python-2.6.6|python|2.6.6|1|BuildingBlock|71410K|slackware/d|python-2.6.6-i486-1.txz||object-oriented interpreted programming language|slackware|13.37|official
Code: Select all
yes|dietlibc||exe,dev,doc,nls
Code: Select all
# diff support/functions ../roar-ng-001_org/support/functions
117c117
< enabled_sub_packages="$enabled_sub_packages ${sub_package%>*}"
---
> enabled_sub_packages="$enabled_sub_packages $sub_package"
124c124
< for sub_package in $enabled_sub_packages
---
> for sub_package in $sub_packages
#
And strippkg thinks file-names like e.g. these in slackware-13.37(32-bit) python-2.6.6-i486-1.txz are abominable -> it hangs, with no return# diff 3builddistro ../roar-ng-001_org/3builddistro
19,20c19
< # MKSQUASHFS_OPTIONS="-comp xz -Xbcj x86" #MHHP
< MKSQUASHFS_OPTIONS="" <<< yeah, I know ..............
---
> MKSQUASHFS_OPTIONS="-comp xz -Xbcj x86"
61,62c60
< # if [ -d processed-packages/$package ] # MHHP
< if [ -d processed-packages/$package ] && [[ -n `ls -A processed-packages/$package` ]]
---
> if [ -d processed-packages/$package ]
69,70c67
< # if [ -d processed-packages/${package}_DEV ] # MHHP
< if [ -d processed-packages/${package}_DEV ] && [[ -n `ls -A processed-packages/${package}_DEV` ]]
---
> if [ -d processed-packages/${package}_DEV ]
79,80c76
< # if [ -d processed-packages/${package}$suffix ] # MHHP
< if [ -d processed-packages/${package}$suffix ] && [[ -n `ls -A processed-packages/${package}$suffix` ]]
---
> if [ -d processed-packages/${package}$suffix ]
#
Code: Select all
./usr/doc/python-2.6.6/Misc/TextMate/Python-Dev.tmbundle/Snippets/2 to 3 - Module Deletion (docs).tmSnippet
./usr/doc/python-2.6.6/Misc/TextMate/Python-Dev.tmbundle/info.plist
./usr/doc/python-2.6.6/Misc/TextMate/Python-Dev.tmbundle/Commands/Go to Issue.tmCommand
./usr/doc/python-2.6.6/Misc/TextMate/Python-Dev.tmbundle/Commands/2 to 3 - Module Deletion.tmCommand
Code: Select all
# diff support/strippkg ../roar-ng-001_org/support/strippkg
51c51
< for file in "$(find "$1" -type f)"
---
> for file in $(find "$1" -type f)
76c76
< case "$(file -bi "$file")" in
---
> case "$(file -bi $file)" in
#
Code: Select all
# cat skeleton/distro_skeleton/etc/passwd
root:x:0:0:root:/root:/bin/sh
messagebus:x:503:503:D-Bus User,,,:/tmp:/bin/sh
#
# cat skeleton/distro_skeleton/etc/shadow
root::10933:0:99999:7:::
messagebus:!:0:99999:7:::
#
# cat sandbox3/rootfs-complete/etc/passwd
sshd:x:33:33:sshd:/:
#
# cat sandbox3/rootfs-complete/etc/shadow
sshd:*:9797:0:::::
#
Code: Select all
# If the sshd user/group/shadow don't exist, add them:
if ! grep -q "^sshd:" etc/passwd ; then
echo "sshd:x:33:33:sshd:/:" >> etc/passwd
fi
if ! grep -q "^sshd:" etc/group ; then
echo "sshd::33:sshd" >> etc/group
fi
if ! grep -q "^sshd:" etc/shadow ; then
echo "sshd:*:9797:0:::::" >> etc/shadow
fi
Don't take this as a negative response because its NOT. But, for what its worth, 98% of the worlds computers, understand, use, and are capable of understanding filenames with spaces. For the past 42 years the industry has been using long filenames (with/without spaces). We should respect that as an obligation to be consistent and not do a "nose up" at this in our industry.I'm currently working on new splitting and stripping scripts, with emphasis on better performance and the ability to work with files that contain spaces in their paths, which is something that shouldn't appear on a good UNIX-like system.
Intel eh? I guess that happens in standard slacko or latest slacko beta? They seem to have fixed it for nouveau and radeon in 3.1x kernels, and all my intels work ok too (eee-701SD, compaq-evo-500 w/brookdale, HP on son's lappy, forget chipset atm)Iguleder wrote: - KMS still makes my screen black
Iguleder wrote: Viva la revoluciĆ³n!
Is ntfs-3g included so it can create these save files even on NTFS?Once the system is booted and the "home=partition" boot code is specified,
the init script attempts to create a save file on the specified partition and
continues to boot into a persistent session
No, for two reasons:nooby wrote:Is ntfs-3g included so it can create these save files even on NTFS?
Yeah, any distro built using roar-ng can boot in two modes - either "live" or "frugal", in Puppy terms. Support for "full" installation is not provided because it makes the boot process much more complex and introduces many questions.nooby wrote:And can the OS Subito or others created by your program boot frugally?
Subito comes with syslinux, but you can add any boot loader you wish. Boot loader support has nothing to do with the distro itself.nooby wrote:Isolinux or grub4dos or grub2? or all of them?
Filesystem in Userspace (FUSE) is a loadable kernel module for Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a "bridge" to the actual kernel interfaces.
...
FUSE is particularly useful for writing virtual file systems. Unlike traditional file systems that essentially save data to and retrieve data from disk, virtual filesystems do not actually store data themselves. They act as a view or translation of an existing file system or storage device.