Posted on 28 Sep 2012, 8:21 - Category: Woof - Comments - href="?edit=03012">Edit - Delete
Posted on 27 Sep 2012, 10:50 - Category: Woof - Comments - href="?edit=03010">Edit - Delete
Previously, only the 'Name' field was translated, I have now added the 'Comment' field.
A langpack PET created by MoManager has /usr/share/applications.in, which is a collection of .desktop files with the appropriate translated 'Name' and 'Comment' fields.
Refer to /usr/sbin/momanager to see how this directory is created, and /usr/share/doc/langpack-template/pinstall.sh for the langpack post-install script (which will perform the translations on /usr/share/applications).
I have extended this so that the Puppy Package Manager will recognise if /usr/share/applications.in exists (meaning a langpack installed) and will apply a translation if a matching .desktop file exists in /usr/share/applications.in when a package is installed.
Refer to script /usr/local/petget/installpkg.sh.
I think that L18L and others were modifying 'pinstall.sh' in their langpacks, but now need to consider return to the official pinstall.sh script.
Posted on 26 Sep 2012, 9:43 - Category: Woof - Comments - href="?edit=03007">Edit - Delete
The DejaVu home page gives an overview of the languages supported:
To localise to Chinese or Japanese, a special font package is required to be installed. To get applications such as JWM (window manager) to use it, their config files must replace "DejaVu Sans" with just "Sans".
If the system recognises "Sans" as mapping to the new Chinese/Japanese font set, then it will work.
Actually, in theory the fontconfig mapping could remap "DejaVu Sans" to the new Chinese/Japanese font set, but it seems that no one has figured out how to do that. It would be the simplest solution though.
Anyway, I have modified two scripts to replace all occurrences of "DejaVu Sans" with just "Sans".
This file is read by MoManager and becomes the post-install script for a langpack.
There is no Chinese or Japanese langpack yet (there is one for some older 4.x and early 5.x puppies but that is not compatible with recent pups). When someone uses MoManager to create a Chinese/Japanese langpack, it will have this new pinstall.sh in it.
This takes care of replacing "DejaVu Sans" with "Sans" when certain packages are installed by the user.
Note, it is not just JWM that has this "DejaVu problem". There are various JWM and GTK theme PETs, and other PETs such as openbox, seamonkey, firefox.
You can find the updated scripts here:
Posted on 24 Sep 2012, 22:59 - Category: Woof - Comments - href="?edit=03006">Edit - Delete
Posted on 23 Sep 2012, 9:11 - Category: Woof - Comments - href="?edit=03001">Edit - Delete
I have implemented these changes in Woof.
However, these "firmware directories" have been taken out of Woof, now separate PETs:
b43, b43legacy, brcm, dgcmodem, hsfmodem, wl
Here are the PETs:
Posted on 20 Sep 2012, 10:55 - Category: Woof - Comments - href="?edit=02995">Edit - Delete
Except that I stopped making them into tarballs, left them as directories, as the SFS file compressed everything anyway.
These "firmware tarballs" are more than just firmware. They may contain data files, scripts, binary executables, anything needed to get the modem working. Take the case of the 'dgcmodem' -- the 'dgcmodem' directory would get installed if Puppy detected the presence of such a modem. Otherwise, the files are kept out of the way in the 'all-firmware' directory, so as not to interfere with the system.
These firmware tarballs used to be kept in kernel PETs, but I had a problem with maintaining all the different versions. So I moved them into Woof, even though some of these "firmware" directories also contain binary executables.
Moving to the present, rerwin is taking a new direction, starting with 'dgcmodem' and 'hsfmodem'. These are deleted from Woof, although I have left empty /lib/modules/all-firmware/dgcmodem and hsfmodem directories in Woof. These two are now separate PETs.
It is good I think that these are out of Woof. But, any puppy build that has a kernel with dgcmodem and/or hsfmodem modules, will have to also build the pup with these corresponding "firmware" PETs.
Here is where rerwin has posted these PETS:
I have uploaded them (28KB, 88KB):
Posted on 18 Sep 2012, 22:07 - Category: Woof - Comments - href="?edit=02993">Edit - Delete
However, the filesystem-check at startup for a full-hd installation, fails. The reason is that the ramdisk size is 16MB, which is no longer big enough -- a small Linux is created on this on-the-fly at startup, and the main hd f.s. is unmounted and a f.s. check performed.
I have now set the ramdisk size at 32MB.
3.2.29 PET (23.4MB):
Posted on 14 Sep 2012, 24:27 - Category: Woof - Comments - href="?edit=02991">Edit - Delete
Posted on 11 Sep 2012, 8:08 - Category: Woof - Comments - href="?edit=02989">Edit - Delete
I have put hacks into Woof to fix this. The FIXUPHACK in vlc template applies the fix if a pup is built with vlc. The script /usr/local/petget/hacks-postinstall.sh applies the fix if vlc is installed in a running pup.
Posted on 7 Sep 2012, 17:24 - Category: Woof - Comments - href="?edit=02986">Edit - Delete