Unionfs letting us down?

I used Unionfs in the kernels in Wary and Racy 5.2.2, and I thought that all was well.

However, Forum member vicmz reported a mysterious problem with the desktop drive icons. For example, with 'sda1' icon, click on it and sometimes an error message came up that /root/.pup_event/drive_sda1/AppRun is missing.

It took me several hours, but I eventually traced the original cause of the problem. /sbin/clean_desk_icons runs this line:

rm -rf /root/.pup_event/drive_* 2>/dev/null

However, a test line inserted immediately after;

ls -1 /root/.pup_event

...sometimes, lists the drive_* folders as still present. They are still present later, in the /sbin/pup_event_frontend_d script, and their presence, when they shouldn't be there, upsets the script very much.

Most of the time those folders do get deleted, just sometimes they do not. This is a gross failure, and the only thing that I can think of is Unionfs.

I am running Wary, with 2.6.32.55 uniprocessor kernel, booting off a USB stick. Vicmz has also reported the problem with Racy. I think that vicmz is also using a USB stick for the savefile.

I have been using Wary and Racy for many months without any problems, but most of that time it has been a frugal installation on hard drive.
The USB case would have the top layer of Unionfs in RAM, I don't know why that would make any difference.

Anyway, tonight I will recompile the kernels with Aufs.

Read more...

Wary/Racy 5.2.91 (5.3RC2)

This is the announcement for 5.2.90 (5.3RC1):
http://bkhome.org/archive/blog2/201203/waryracy-5290-53rc.html

Download 5.3RC2 from here:
http://distro.ibiblio.org/quirky/test/wary-5.2.91-5.3RC2/
http://distro.ibiblio.org/quirky/test/racy-5.2.91-5.3RC2/

The only known issue for now is ffmpeg. It was reported that ffmpeg lacked network support, which is needed under certain circumstances by Pmusic, so I recompiled it and that was in 5.3RC1. However, then someone reported that ffmpeg did not work for X11-grab (although it was compiled with that enabled) -- I asked that person to install the older ffmpeg to confirm that X11-grab worked with that. However, that person did not respond in time, so I have reverted ffmpeg anyway. That is, 5.3RC2 has the older compile of ffmpeg.

Forum thread for feedback (page 14 of thread):
http://murga-linux.com/puppy/viewtopic.php?p=615981#615981

Everything has to be pretty much frozen at this point. Essential bug fixes only.
I know that language translation can be taken up a notch, however consider the current situation as frozen, until after 5.3-final.

Read more...

Wary/Racy 5.2.90 (5.3RC)

I have been minding someone's place for a few days, and they have a fast Internet connection, with high monthly transfer allowance. They will be home this evening, so I decided to go for it and upload Release Candidate 1 of Wary and Racy 5.3.

You can download from here:
http://distro.ibiblio.org/quirky/test/wary-5.2.90-5.3RC/
http://distro.ibiblio.org/quirky/test/racy-5.2.90-5.3RC/

There are delta files to upgrade from the previous beta releases, also from the previous official 5.2.2 releases.

Relative to 5.2.2, there are many bug fixes and incremental improvements. There is one major structural change, and that is massive non-English support, in the form of "langpacks".

Langpacks are to be found in the Puppy Package Manager, in the "puppy-noarch" repository in the "Setup" category. Some of them are still being added to and should be ready by the time 5.3-final is released.

When I refer to non-English support as a "major structural change", I mean that it is a complete solution in Woof. It will even be possible to use Woof to build an "out of the box" variant of any Puppy for a specific language.

One thing that I think is a bit awkward, is the replacement of 'xmessage' with 'gxmessage', as the latter is required to display non-English text. However, in my opinion, the gxmessage windows look awful. I do intend to replace use of xmessage with pupdialog in many Woof scripts, but not sure how far I will get with that before 5.3-final.

There is no Release Notes page yet. To find out what has happened since 5.2.2, scan my blog posts.

Still the same old theme as used since version 5.2! It takes me a long time to come up with a new theme that I like, so I am hanging onto this one a bit longer. Probably the ARM-Puppy will get a new theme though.

Read more...

ffmpeg 20111002svn recompiled

There was a report, if I can recall it right, that ffmpeg does not work properly with Pmusic as network support is disabled.

Hmmm, there is a '--enable-network' configure option, but it seems to be the default. But, the 'ffserver' executable is not in the PET package.

Anyway, I have recompiled with that option, this time have put 'ffserver' into the PET. Interesting, the PET is a bit smaller this time.

PETs (2.5MB, 2.9MB):
http://distro.ibiblio.org/quirky/pet_packages-wary5/ffmpeg-20111002-1-w5c.pet
http://distro.ibiblio.org/quirky/pet_packages-wary5/ffmpeg_DEV-20111002-1-w5c.pet

These will be in the upcoming Wary/Racy 5.3 Release Candidate 1.

Read more...

Acrobat Reader SFS

Forum member sszindian reported that the Acrobat Reader (PDF reader) from the Lucid repo on ibblio.org works fine in Racy. It will probably work in Wary too, so I have uploaded it to the Wary/Racy SFS repo.

Or rather sszindian tested the PET on the Lucid repo, but they also have a SFS file, so I got the latter.

Here it is (61MB):
http://distro.ibiblio.org/quirky/sfs/Acrobat_Reader-9.3.3-Lucid.sfs

One area where you would want this rather than the ePDFView Poppler-based viewer, is for editable PDF files, those that have fields that can be filled in.

Read more...

Sylpheed_portable 3.1.3

I posted yesterday about compiling Cryptofs:
http://bkhome.org/archive/blog2/201203/cryptofs-060.html

And the day before that about the need for a "portable" email client:
http://bkhome.org/archive/blog2/201203/truly-portable-sylpheed.html

Well, I was up to 3am working on it, but the sylpheed_portable PET has arrived (1MB):
http://distro.ibiblio.org/quirky/pet_packages-wary5/sylpheed_portable-3.1.3-cryptofs0.6.0-bogofilter1.2.2-w5c.pet

To make it completely self-sufficient, requiring no dependencies, it has Cryptofs and Bogofilter inside it. The only deps are 'fuse' and 'sqlite3', that all puppies have. I haven't tested Bogofilter.

When you install this PET, it installs to /usr/local/sylpheed_portable, but doesn't actually run from there. When you run it, it asks to be copied to a partition, from whence it can be run into the future. Any partition, USB Flash drives also.

The reason that it installs first into /usr/local/sylpheed_portable is so that Woof-built-puppies can have it in their package list. It will be there, looking like any normal Sylpheed, runnable via the menu or the 'email' desktop icon, but the first time you run it, it gets relocated wherever you want it.

When it is finally installed in a mounted partition, it is just a RoxApp that you click to run. All configuration files and downloaded email are encrypted, and when you run Sylpheed you are asked for a password. Everything gets decrypted for the duration that you are using Sylpheed, then locked up again when you quit Sylpheed.

I'm using it with all the emails that I downloaded from Gmail, all 6,500 of them. Strangely, it seems faster accessing them via cryptofs than before.

Can we give the same "portable" treatment to Thunderbird/SeaMonkey-Mail? I don't know, will have to experiment -- sometime, don't know when.

Today will take some time off for family stuff -- someone's birthday, plus the old folks like to be visited.

Read more...

cryptofs 0.6.0

I posted yesterday about creating a portable Sylpheed. But, the issue was raised that the email login passwords are stored in plain text.

Well, so are all the emails. I was thinking, what if someone stole my laptop? This got me thinking that I could implement an encrypted filesystem inside the Sylpheed installation.

Toward that end, I have compiled Cryptofs, which can encrypt an entire directory.

Here is the PET (230KB):
http://distro.ibiblio.org/quirky/pet_packages-wary5/cryptofs-0.6.0-w5c.pet

The only dependency is libfuse, which is in all puppies. Cryptofs does require libgpg-error and libgcrypt, however I linked those statically into the 'cryptofs' executable.

Cryptofs home:
http://reboot78.re.funpic.de/cryptofs/

Read more...

glew, llvm, clang, libxml++, xulrunner

I have compiled these in Wary and created PETs:

glew-1.7.0 OpenGL Extension Wrangler Library
llvm-2.8 Low Level Virtual Machine
clang-2.8 C/C++ compiler
libxml++-2.35.1 C++ interface to XML files
xulrunner-10.0.2 Embed Mozilla technologies into apps

http://glew.sourceforge.net/
http://llvm.org/
http://clang.llvm.org/
http://libxmlplusplus.sourceforge.net/
https://developer.mozilla.org/en/XULRunner

The PETs:
http://distro.ibiblio.org/quirky/pet_packages-wary5/

Wary has all the dependencies, except libxml++ needs glibmm.

Now that might seem like a strange combination of PETs to create! I was compiling the dependencies for Lightspark, an open source Flash player. Then I found that Lightspark needs gcc 4.4+, whereas Wary has 4.3.4 -- so I compiled 4.4.6. However, Lightspark still needs Boost -- I installed libboost DEBs from Debian Lenny, but Lightspark compile failed, doesn't seem to like that version of Boost.

Read more...