Puppy developer news: from 4.00alpha7 to 4.00beta

Older news

Later news

Puppy 4.00beta1 available

April 5, 2008

I put in the pupdial fix and rebuilt the iso file. 'puppy-3.98-seamonkey.iso' is just 83.3MB. get it from ibiblio:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.00beta/

I have also uploaded the 'devx' file to ibiblio.

The release notes are here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.00beta/release-4.00b.htm

Fix for dialup name resolution

April 4, 2008

Ok, I found the problem. Fairly recently, I noticed that the 'wvdialconf' utility, which is executed as 'wvdialconf /etc/wvdial.conf', output a message that /etc/ppp/options may conflict with /etc/wvdial.conf. So, I made a small but fatal change in the pupdial script, I renamed /etc/ppp/options to something else before executing wvdial, then renamed it back afterward.

Now, looking in /etc/ppp/options, it has some interesting things, particularly "usepeerdns". Now, it's my guess that the pppd daemon reads that file and if it doesn't exist then doesn't fetch the DNS from the ISP.

/etc/ppp/options is a file that I have always had in Puppy, it's not part of any particular package. It goes right back to the very early days pre-0.1 when I was first trying to get dialup to work. We need to study the relationship between this file and wvdial and pppd, but for now I have just fixed it by leaving /etc/ppp/options alone.

Interesting, this also fixes the problem I had in alpha7 in which /etc/ppp/chap-secrets and pap-secrets was not getting written to, so I have removed that "fix" from pupdial also.

Domain resolution on the way to being fixed

April 4, 2008

Actually, it's 1.30 am on April 5, I've been putting an earlier post date as most readers are in the US and I'm about 12 hours ahead. I just got it working in beta1, but I'm not quite sure why. But my eyes are heavy so I'll work on it tomorrow. Looks like I will have to stay in Perth a trifle longer than planned.

Domain name resolution not working for dialup

April 3, 2008

4.00beta1 is ready to be uploaded. I'm staying at a relative's place in Perth, but her broadband is down. Her ISP does have an emergency dialup number, so I took that as an opportunity to test 4.00beta1 dialup with my PCMCIA modem.

Yes, it dialed ok, connected. It all looked fine, except that SeaMonkey could not access any URLs. I tested pinging an IP address, that worked. So, I strained my brain to recall (it's late, I've had a long day) ...ah yes, /etc/resolv.conf ...which is empty.

I tested Puppy 3.01, yep works fine, writes to /etc/resolv.conf. I'm running 3.01 right now.

Now, what is it that actually writes to /etc/resolv.conf? pppd? We already have one very peculiar thing that we fixed just this week -- wvdial was not writing to /etc/ppp/chap-secrets and /etc/ppp/pap-secrets -- so I wrote to them manually in the pupdial script.

/var/log/messages has this (running 3.01):
daemon.notice pppd[7975]: local  IP address <DELETED>
daemon.notice pppd[7975]: remote IP address 203.59.14.16
daemon.notice pppd[7975]: primary   DNS address 203.0.178.191

...oh, I don't recall seeing that last message when I was testing 4.00beta1. Groan.

I did have some feedback that dialup was working in alpha7, after the last fix. But, did you go as far as testing with an actual domain name in the browser? I don't recall anyone, in any of the alpha tests, reporting this problem.

Well, I have to upload beta1 in the morning, when I go to my daughter's place. Because after that I'm going home. This dialup problem will have to be solved afterward.

Autoconnect upgraded, Dingo beta finalised

April 3, 2008

Forum member Urban Soul has created a wireless auto-connect application, and version 0.3 was in Dingo alpha7. I have upgraded that to the latest, v0.4.

I have to draw a line at this point for Dingo 4.00beta. I'll build it and do some testing, then probably upload it in another day or two. I'm going to Perth tomorrow afternoon and will have access to fast upload.

There are probably a few things that I have left out, that some guys have been workng on. Well, I'm sure we'll find bugs in the beta. So I intend there will be a beta2, then probably the final release.

Glipper is in, autocutsel out

April 3, 2008

Due to demand, this is now in Dingo ...well, I can't recall if it was just one person mentioning how desirable glipper is many times in the forum, or more than one person. I think it was a few people. Feedback is that Glipper from Puppy3 works fine, so I have put it straight in.

Glipper is small, only about 60KB so no problem to include. I did consider Parcellite, which does the same thing (apparently), but I have just compiled it and the executable is 382KB. Maybe its really lovely, I don't know, but I went no further as Glipper does the job.

One thing, I do need to reconsider whether we still need that 'autocutsel' utility, which is a daemon that always runs in the background and synchronises the selection-buffer with the clipboard. I forget the details, but I think it automatically copies a selection (highlighted text) into the clipboard, which is handy for copying and pasting from/to the rxvt terminal. I do wonder whether we really need it though. I think, if I recall correctly, Dougal took it out of 2.14-Revisited.

Autocutsel is small, but it is one more daemon running in the background and adding to the resources-load. Note, you may have noticed a tiny square in bottom right of the screen when X starts up -- that's the Autocutsel daemon running. Yeah, throw that out too!

Wvdial version rollback, libstdc++ v5 removed

April 3, 2008

This is a space-saving exercise. Puppy 2.17 and 3.01 both use wvdial version 1.41, that was patched to compile, and was compiled mid-2007. Dingo has been using wvdial version 1.53, that was compiled back in 2003 and uses an older libstdc++ library, version 5.0.6 (whereas Dingo's current libstdc++ library is 6.0.9).

Wvdial is notoriously difficult to compile. Even though the developers helped me to get 1.41 to compile in Puppy2, it no longer compiles in Puppy4. Nor does v1.53. These are both old versions of Wvdial, so why don't I use the very latest? Simply because it grows in size in leaps and bounds with each new version. The reason for this is that Wvdial itself is a legacy application and the developers focus their attention on the Wvstreams library which is used for many other applications than Wvdial. It is this library that grows and grows. Even if I compile Wvstreams statically into Wvdial it is still enormous. There is a lot of history of me messing around here.

The old Wvdial 1.41 does the job and as far as we can determine does not have any shortcomings for dialup. However, although v1.53 is more than twice the size, I chose it for Dingo as the PPP-Gnome dialup application needs the later version. However, PPP-Gnome is broken, so Dingo is only using PupDial (my script) now. Hencewe can fall back to Wvdial 1.41.

This leads to another question: why leave the old 'libstdc++-5.0.6' package in Dingo? Puppy2 and Puppy3 have this, for the sake of running older C++ applications. However with Dingo I am supposed to be doing a clean sweep, and I really do think that this old library can be "put out to pasture" as a PET package. It is 721KB uncompressed, so it is significant... yeah, out she goes!

Encrypted pup_save now mounts

April 3, 2008

Ahem, reading through my last post, I can see that I should have realised immediately that losetup is to blame, not mount. Anyway, I meandered along and got there.

It seems that losetup somehow thinks the default input filedescriptor is closed and defaults to assuming an empty password string. So it would seem that something in the initial ramdisk environment is causing this problem. The solution is to use the '-p' option, which can specify stdin and then the password can be piped in. The problem is though, losetup does not accept the '-p' option for XOR encryption -- I had a brief look at the source code and yes indeed XOR input is handled differently. Perhaps there is some historical reason for that.

Well, we have two options, either hack the source so that input for XOR is the same as AES and the rest, or dump XOR encryption.

Note, I had to upgrade to the latest losetup, from the util-linux package version 2.13pre7. I compiled it statically with uClibc.

The same problem exists in rc.shutdown and if you choose XOR (light) encryption you get asked the password three times because of this inability to pipe-in. With AES however it can be done like this:

echo 'mypassword' | losetup -p 0 -e aes /dev/loop1 pup_save_crypta.2fs

Anyway, we are basically in business again. Now, I need a break.

Cannot mount encrypted pup_save

April 2, 2008

This problem keeps cropping up on a regular basis. It reminds me of a quote in one of my developer news posts in 2007, here.

It was reported that pup_save encryption is not working for 4.00alpha7. I added an option in the 'init' script so that if the pup_save fails to mount you can drop out to the commandline in the initial ramdisk and try to find out what is wrong ...which I did, and dmesg reported:

EXT2-fs: loop1: couldn't mount because of unsupported optional features (31796d61)

I did some googling around to try and find out more, and it is quite a common problem. It seems to have something to do with the fact that the 'mke2fs' utility was compiled for a later kernel. But in my case mke2fs was compiled in T2 with the 2.6.21.7 kernel ...unless there was some different configuration of the kernel than the one I'm using.

Anyway, I'm mystified. mke2fs runs at shutdown when creating the pup_save file, and a normal unencrypted pup_save mounts fine. An encrypted pup_saveis a different issue, nothing to do with the ext2 filesystem. At bootup, losetup is used to associate the pup_save with a loop device, then the loop device looks like a normal unencrypted ext2 filesystem. I can't see any logical reason why the first case mounts, the second doesn't.

Default optional features are defined in /etc/mke2fs.conf, but that file is the same in Dingo as in Puppy 3.01.

So, what to do? I edited /etc/rc.d/rc.shutdown and for the case of creating an encrypted pup_save I added the extra option '-O none' to mke2fs. This disables all optional features. Does this fix it? Nup.

Then, I was testing from the commandline in the initial ramdisk and discovered something: losetup does not ask for a password. After Puppy has booted, I can open a terminal and run losetup and it does ask for a password, and mounting does work. But not inside the initial ramdisk. Yet, this did work before. It works in 3.01, and I think it was working earlier in Dingo with the 2.6.24 kernel.

So, I compiled losetup statically, later version than that previously in the initial ramdisk (from util-linux 2.13-pre7). Same thing, doesn't ask for a password. The line in question is this:

losetup -E 1 /dev/loop1 /mnt/dev_save/pup_save_cryptx.2fs

where the parameter is '-E 1' for xor encryption or '-e aes' for aes encryption.
For both cases, losetup does not wait for a password and returns with value zero to indicate success. Then typing 'losetup /dev/loop1' shows that it is associated with the file and the appropriate xor or aes is applied. Except that losetup has totally bypassed the password.

So, I went and did a bit of a google again, and found that pizzasgood has already narrowed the problem down to losetup, testing on Puppy 3.01 ...so the problem is not just with Dingo. Appropriate Puppy forum thread:
http://murga-linux.com/puppy/viewtopic.php?t=24792

I have experimented some more. Tried 3.01, yep, same problem. It seems to have something to do with booting from USB, but I can't see the connection. I tried various extra parameters for losetup -- one thing I do recall, losetup's handling of i/o is peculiar -- in the rc.shutdown script back when I was working on Puppy3, I found that it did not seem to obey its own '-p' parameter which is supposed to select a specific file descriptor. What next, do we hack the source?

Servage again

April 2, 2008

I wonder how many customers of Servage have been hacked but don't know it? Considering that the most recent compromise is just to insert porno etc links into a web page that don't show up on the web page but are visible to search engines.

Anyway, yesterday I sent an email to my daughter and partner, telling them about my Servage experience. They also have an account with Servage. This is her reply:


That's now five accounts that I know of personally. This is really bad. It must be pervasive throughout Servage. It is a wonder that it hasn't become a major news item.

Announcement/release-notes written

April 2, 2008

Gosh, that took me all morning! Just writing the release notes for 4.00. Although it is only the 4.00beta coming soon, I wanted to get the release notes written. What took so long is I went through all my developer news since the release of 3.01, and many items worth mentioning in the release notes also have "read more" links back into my developer news.

After all, 3.01 was released mid-October 2007, almost 6 months ago, so I have written a lot in the developer news since then -- an incredible lot of stuff to wade through. Looking back over it, a lot has happened, which I only fully realised after creating the summary in the release notes.

More web pages updated

April 1, 2008

A few of the "technical" pages at the new puppylinux.com site needed to be updated, which I have now done. They are the main index page (hit the "technical and developer" icon), my project-statement (which outlines how the Puppy project is managed, or rather isn't managed) and the page on how dialup-internet works since v2.17.

Choosing themes for 4.00beta

April 1, 2008

I had recently worked on a new GTK/JWM/icon theme for Dingo 4.00beta, but after a few days of playing I had not settled on anything. Today I had to make decisions, and primarily I am going for a fairly plain look that hopefully is pleasing or at least satisfactory and doesn't distract in any way from using Puppy. Generally the mild blue/grey themes fall into this category.

I have designed "Gradient-grey" themes for GTK and JWM, and went for zigbert's selection of Stardust icons. What still remains is choice of a desktop background image -- always a very difficult choice. I found one lovely nature scene, then saw that it is 1.1MB -- unfortunately when such stunnng images are made smaller by cutting down the JPG "quality factor" then the picture starts to loose the original appeal. Anyway, I will decide today.

puppylinux.com moved to Hostgator

March 31, 2008

If you are reading this, then it has already happened! At the time of writing, I am just about to logon to my domain name registrar and change the DNS info. Then wait awhile for it to propogate through the DNS name servers.

Be mentally prepared! I have a strong minimalist tendency in just about everything I do, and this is reflected in the new design for the web pages. I consider most web pages these days to be too cluttered up, too many choices, unclear what is clickable and what is not. I have gone to the opposite extreme.

Already got a problem with Hostgator!

March 31, 2008

Hah hah, Hostgator gave me a URL to access my website: http://<ip address>/~<myusername> and http://<ip address>/cpanel. The cpanel one works, but the first one is weird... my browser displays at the bottom of the window "Looking up allkonki.ru..." then times out and says cannot access address http://allkonki.ru/~<myusername>. So, I raised a ticket with Hostgator and they advised to put a slash on the end: http://<ip address>/~<myusername>/ ...which works!

So, I replied to them, that is not very satisfactory. They replied that it works for them without the trailing slash also, and advised me to clear my browser cache. Hmmm, I had already told them that I double-checked by booting a pristine live-CD to make sure no history of any kind could be causing this. Needless to say, clearing my browser cache made no difference. I also used Turma to do a search of all my files looking for the string "allkonki" -- just to be absolutely certain -- nup, nothing.

Anyone got any idea what could cause this phenomenon?

Bugfix for Ayttm

March 31, 2008

Great, Siddhesh Poyarekar has fixed the bug that caused a channel not to logon. I have compiled from CVS, can't test it right now though as my satellite Internet is down. The 'sync' light on the satellite interface box has been flashing for the last hour. The remains of a cyclone is still off the coast and today there are high winds -- perhaps the gusts are upsetting the satellite dish. Anyway, it's good news.

There were some dribbles of rain today, but the ground soon dried. In this arid region the wind whips up dust. It is quite beautiful, to look outside and see the deep color of the sky with dust in it. Hmm, there's a film of dust over everything in the house too, including this computer.

UPDATE:
I now have Internet access, testing Ayttm. Great, it now comes up with a window advising that downloading the channel list. Yep, working!

Signed up with Hostgator

March 31, 2008

Okay, I've signed up with hostgator.com. My domain puppylinux.com is the primary domain for the Hostgator account, and I'll be moving over from Servage soon.

Forum member WhoDo has also signed up with Hostgator, and puppylinux.org will be moved there. Thanks for your generosity WhoDo. See forum thread where this move is being discussed:
http://murga-linux.com/puppy/viewtopic.php?t=26942

Hey guys, my primary domain is pointing to directory 'public_html', but do you know if it is possible to change that? In Cpanel, I see that additional domains can be set to a particular directory, but there does not seem to be any way to change the directory of the primary domain.
Probably it doesn't matter really, as I suppose the directories of additional domains can be alongside 'public_html', not in it, so there should be no interference ...well, I hope so.
I have posted this question at the above URL.

I've signed up for the 'baby' account, but I notice the next one up, 'swamp', has unlimited downloads ...can that really be true?

pStopWatch and Ptimer

March 31, 2008

Zigbert has done it again, with more great little apps for Dingo (and earlier pups).

pStopWatch version 0.5 is a simple go-stop stopwatch. See forum thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=27342

Ptimer uses pStopWatch and adds extra GUI functionality. Forum thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=27496

Ayttm and Jasper

March 30, 2008

I mentioned recently that I have been working with the developers of Ayttm to fix bugs. There is still one outstanding bug, being that after logging onto the irc.freenode.net IRC server, when I connect to a channel it comes up with an empty window, that is, not connected to the channel. I have some feedback on this and it seems that Ayttm is still downloading the list of channels in the background, which can take a long time, and while still doing this fails to connect to a channel. The workaround is just to wait a bit, say one minute, before trying to connect to a channel. The developers have not fixed this problem yet, but it can be avoided so I have made Ayttm into a PET package and it will be in the Dingo beta. As soon as a fix becomes available I will upgrade. The version I am using is 0.5.0-35 from CVS on March 22.

I have also included the Jasper package, that Ayttm uses to support Yahoo Webcam.

Now, it is interesting to compare size with Pidgin, our previous multiprotocol chat client. I created a PET package for Pidgin 2.2.1 by cutting the original down considerably. For example, I hacked into the emoticons, drastically reducing the selection. I removed the Perl scripting. I ended up with a package that 'du' shows occupies 4316K, or as a compressed PET package, 1534K. (note, this particular package isn't working properly in Dingo)

For my Ayttm package, 'du' shows 1920K and as a PET package, 691K. Jasper is 368K and as a PET is 152K. Yeah, that knocks a bit off the size of the live-CD. Fine, as long as Ayttm does what we want... which is yet to be determined as I have only tested IRC. When you guys get hold of Dingo 4.00beta, put Ayttm through its paces!

I subscribe to the Ayttm mail list, and there was an interesting post today. Someone asked if it is possible to connect to Google Talk, and the reply was yes, via Jabber. Hmm, thought I saved the post. Oh well, go to the mail archive at the Ayttm site to find the instructions.

UPDATE: Here it is, how to connect to Google Talk, posted by Philip Tellis:

>   Is there a way to use AYTTM to connect to Google Talk?

1. Add a new jabber account
- Screen name: your gmail (or googlemail) account including @gmail.com
- Service type: Jabber

2. Edit | Preferences | Select the jabber account associated with your
gmail address
- Set Connect Server to: talk.google.com
- Select Use SSL
- Port: 5222
- SSL Port: 5223

3. Click Ok

4. Connect

PCMCIA fix, Xorg Wizard fix

March 30, 2008

Rerwin has fixed a problem with PCMCIA, as per his post here, March 26:
http://www.murga-linux.com/puppy/viewtopic.php?t=26985&start=90

This is a further modification to /etc/rc.d/rc.modules, in addition to that in my previous post, regarding modem dialup.

Rerwin also posted a fix for the Xorg Wizard on March 10. I applied the fix to /usr/sbin/xorgwizard at that time, forgot to mention it on my News page. The forum post is here:
http://www.murga-linux.com/puppy/viewtopic.php?t=26985&start=15

Dialup modem improvements

March 30, 2008

Forum member rerwin has done a lot of work on this. I am implementing the improvements that he posted to this forum thread on March 24:
http://www.murga-linux.com/puppy/viewtopic.php?t=26985&start=90

Some minor notes about this:

1. The file /lib/modules/firmware.dep.2.6.21.7 no longer has the lists of files in each firmware package. This is due to my recent redesign of the format of the zdrv file.
2. Rerwin has modified the files MODULESCONFIG, rc.local0, rc.modem and rc.modules in /etc/rc.d.
3. Rerwin has modified/created Cdcacm, ess, intel536ep, intel537ep, ltmodem, mwaved, pctel, Pl2303 and slmodem scripts in /etc/init.d. Note that these are not actually all in /etc/init.d but are in their respective firmware packages in the 'zdrv' file. When a modem kernel module loads, if it has an associated firmware package then that gets installed. So for example, /lib/modules/firmware.dep.2.6.21.7 has the entry 'cdcacm:cdc-acm.ko' which associates the firmware package 'cdcacm' with the module 'cdc-acm.ko' -- the cdcacm firmware package has /etc/init.d/Cdcacm which gets installed.
4. Note, as announced earlier, the 'zdrv' file is reorganised for 4.00beta, so if you look in the 'zdrv' file you would find all the firmware packages in directory /lib/all-firmware.
5. Dingo 4.00beta will be using the 2.6.21.7 kernel, so I modified the files in step-3 in the firmware packages for that kernel. However, Puppy Unleashed is able to build with other kernels, such as 2.6.18.8 and 2.6.24 so I upgraded the firmware scripts for those too. When I move on to 2.6.25.x, I will be using the firmware packages from 2.6.24 as the basis.
   
6. Note to rerwin: while I think of it, is there any particular reason why you capitalised the first letter in 'Cdcacm' and 'Pl2303' when they weren't before?
7. Rerwin, thanks again for creating those diff files --helps enormously.

The end result of this work is we want those on analog dialup to the Internet to have the most pleasant experience with Puppy. Of course we can't support all software modems, but we are doing the best we can, and we are trying to automate the detection and setup as much as possible. When Dingo 4.00beta is released, please test!

UPDATE 31 MARCH: Rerwin has replied to point-6:

gtk1-compat package

March 29, 2008

Thanks to the person who told me about this package. It is a compatibility library that is supposed to make it easier to compile GTK1 apps against the GTK2 libraries.

Well, I tested it on a whole heap of GK1 apps, and had no luck. I only managed to get some small apps to compile. Gxset included, but it still has the same crashing bug. I tried lots of packages. It is possible that for some of them the problems preventing a compile could be fixed, but I do not have the time for that.

More on auto-centering in browser window

March 28, 2008

This URL has useful cross-browser information:
http://css-discuss.incutio.com/?page=CenteringBlockElement

A quote from the above:

Er, what is "standard compliant" mode? The "IE6 CSS enhancements" link has this:
Most of my web pages have the first !DOCTYPE declaration, so it seems that this is the fix I need.

Limited Internet access

March 28, 2008

Please note, the last few days I have had very patchy Internet access. A cyclone about 800km off the coast of Western Australia is causing scattered small storms that have knocked out the power a few times. Then my satellite connection has problems, connecting to sites has been like watching grass grow. I didn't bother contacting my ISP, figured they were working on it, and yes, today the speed has picked up. At least I am staying connected recently -- up until a couple of weeks ago I was having trouble with the satellite sync "dropping out" at seemingly random times, then I would have to wait from 5 to 30 minutes for it to re-sync.

Note to rerwin: I've got your files, will get onto it soon. After I have fixed my web pages, and hopefully solved the IE6 problem!

Non-standard behaviour of IE6

March 28, 2008
@#$%^&*! I have started to learn a little CSS, aiming at improving my web pages at puppylinux.com. One thing I want is to centre text and images with 700 pixels width and equal margins on each side in the browser window. I found a nice simple solution, a bit of CSS:

#wrapper {
    margin: 0 auto;
    width: 700px;
}
#content {
    width: 100%;
}

And in a HTML page:

<body>
<div id="wrapper">
<div id="content">
content in here
</div>
</div>
</body>

Works beautifully in SeaMonkey/Firefox, so I was merrily implementing it in all my web pages. Then just now I thought that I had better check it in Internet Explorer, so did... curses, I get the 700 pixels ok, but it's all on the left side of the browser window.

Also the transparent backgrounds of the PNG images do not render as transparent, instead with an opaque light-pink colour.

Both of these factors totally spoil the rendering.

Developer News now in one place

March 26, 2008

It has taken me five or six days of solid work, and I'm feeling a bit burnt-out.

I have been maintaining a daily Developer News log since June 18, 2003 when Puppy Linux version 0.1 was released. However, this log is scattered around. Up until mid-2006 it was just static HTML pages. Then I setup a Simplephpblog at my host netfirms.com, later moving to ibiblio.org. In late 2007 I setup a WordPress blog at my host servage.net. Right now, I have static HTML pages at various locations, a read-only blog at ibiblio.org and a disabled WordPress blog at servage.net.

All of this historical information needs to be kept, and needs to be readily accessable. It is a record of important decisions, technical details, and has many invaluable links. Many older versions of Puppy are still "alive and kicking" so the "historical record" is still current news for those versions. There are many other reasons why you might want to look back into this record.

So, as I am moving to a new host soon I decided that I had to get my Developer News organised. I have put it all in one place, as static HTML pages. I do not know of any tools to extract the Simplephpblog and WordPress databases as static HTML pages, so I did it manually. Then I had to go through and reformat it all into a consistent layout, fix links, smilies, etc., etc. Groan, I realised what a huge job it was after a few days of solid work.  Wow, I just did 'du' in the directory with all the HTML files and it is 5MB!

Anyway, it's mostly done. The "front door" is an index page which is still a work-in-progress and will have more links to specific information, maybe also a local search engine. Most of the web pages are by version number than by year, making it easy to find out what happened between specific versions, for example between 2.01 and 2.02.

Current Developer News is this static web page that you are now reading, however when I move to my new host I may setup a blog again. It certainly is helpful to have immediate feedback, and the feedback is also a plus for the historical record of what we are doing and why. However, if I do setup a blog I would really like to be able to archive older news as static HTML and would like to find a blog that can do that.

Refinement to battery applet

March 24, 2008

Dougal as modified the battery tray applet so that it fits better if we want the tray height to be less than 28 pixels:
http://murga-linux.com/puppy/viewtopic.php?t=25812&start=15

Problems with Pburn

March 24, 2008

Today I have been testing Pburn and there are some fundamental issues that need to be addressed. See my post in the forum:
http://murga-linux.com/puppy/viewtopic.php?t=23881&start=180

...a challenge for the Pburn developers! It seems like the method of intermediate hierarchy of symlinks in /tmp/pburn will have to be abandoned, in favour of graft-points.

Bugfix for PETget, file not installed

March 23, 2008

Forum member 'win2000' reported this bug:
http://murga-linux.com/puppy/viewtopic.php?t=27339

Win2000 is installing a file to /etc/gtk/etc-gtk.xpm and also to /usr/etc/gtk/usr-etc-gtk.xpm. The latter file did not get installed.

I looked in the 'petget' script and found a line that goes back to when /etc was a symlink into /root/.etc. This is from the old days of Puppy version 1.x. I removed that line, but it isn't contributing to the problem.

The fundamental problem here is that Puppy already has /usr/etc/gtk as a symlink to /etc/gtk. The 'cp' program hiccups at this and gives an error message about not being able to overwrite a non-directory -- but /usr/etc/gtk is a symlink to a real directory so I don't know why 'cp' objects.
The options used in the script for the 'cp' command are '-a --remove-destination'. You will find this at about line 338. I experimented with some replacements for '-a' but that upset other things. I finally devised some extra code to work around the problem. We had the same problem back in Puppy1 when /etc was a symlink, and in that situation I just added an extra line 'cp -a --remove-destination /etc/* /etc/' -- just putting the '/' after the symlink and 'cp' is happy. This is the basis of my new code which is a generic fix for this situation.
You will be able to find this code in 'petget' by searching for the string 'v3.98' -- it's around about line 338.

I tested the fixed petget with win2000's example 'test-1.0.pet' and it worked. The thing is though, as /usr/etc/gtk is a symlink to /etc/gtk, both of the files end up in /etc/gtk, which is the correct behaviour.

I just remembered something, that I will comment on. There has been some discussion in the forum about the need to redesign PETget, perhaps modularise the code as the 'petget' script has grown rather large. There was also a comment about a need to install a PET package from a script without any dialog boxes popping up. The petget script can be run with the name of a package to either install or remove, but in the case of installing it pops up various dialog boxes. Note however, if petget is run with the name of a package to install on the commandline, if X is not running then the install is done quietly, no popups. So, the mechanism is already there and perhaps a '--quiet' on the commandline to make petget install quietly even when X is running. I can probably easily implement that.

Discussion on networking setup

March 23, 2008

Rarsa has kicked off a new thread to discuss this, in response to my previous post:
http://murga-linux.com/puppy/viewtopic.php?t=27486

This is great. If you have any thoughts about this topic, feel welcome to post at that thread. See my post below, that started this:

Autoconnect to wireless network

March 23, 2008

Forum member 'urban soul', formerly known as 'fudgy', has contributed an application to automatically connect to a wireless network. See forum announcement:
http://murga-linux.com/puppy/viewtopic.php?t=26935

I have put this into Dingo for testng in the upcoming beta release. It is selected by entry 'Autoconnect wireless network' in the 'Network' menu, though as urban soul has commented it might go nicely in the Startup folder, or a button on the desktop.

Urban soul also contributed a bugfix for the Network Wizard recently that I applied, and that is announced earlier in this News page.

I wrote the original Network Wizard, but that was back when wireless had not really become popular, and since then I haven't had much input to the Wizard, just applying whatever fixes/improvements that you guys come up with. The Network Wizard is actually package 'net_setup' and there has been considerable input from ...let me think back... GuestToo, Rarsa, Dougal, rerwin. I think pizzasgood contributed something also. Recently plinej developed 'Pwireless', a wireless scanner application.

Personally, I still plugin to an ethernet cable, so I'm not being forced to test and debug all these wireless developments. I am relying on you guys to keep the ball rolling in that field and to fix all problems.

I have a thought, that I request be considered when the Dingo beta is released. It would be nice if someone or a small group could take a fresh look at all these tools and consider the overall integration and usability. The basic questions:

1. When a newbie starts up Puppy and wants to connect to a WLAN, is it straightforward or is there some possible confusion in the steps? Does the choice of different tools itself cause confusion?
2. After establishing a WLAN connection, are the settings saved so that reconnection happens on next boot? The Network Wizard is supposed to do that automatically, but there has been some forum feedback that this is not happening properly.
3. What about people who use both Ethernet-wired and wireless connection? Maybe they have a laptop and sometimes have to use one, not the other. I'm not sure, but it seems that this situation is not being handled gracefully. Perhaps device drivers are conflicting?
   

Anyway, these are my thoughts. We have some great tools for networking, also for dialup -- as rerwin commented recently, the major distros are neglecting dialup, but not Puppy.

Rerwin has recently been contributing to dialup, which is great (I still haven't looked at your latest contribution for rc.modem rerwin, will do that soon). One thing I was wondering about. We have the password for the ISP in plain text in /etc/ppp/pap-secrets and /etc/ppp/chap-secrets and in /etc/wvdial.conf. Should we encrypt these files? The PupDial script could encrypt /etc/wvdial.conf and require a master password to unencrypt it prior to dialup then reencrypt it. The pppd daemon needs pap-secrets and chap-secrets though. Hey, why not keep the password or passwords (if two accounts) in a separate file, and this can be inserted into wvdial.conf, pap-secrets and chap-secrets only when needed (so those files do not have to be encrypted), immediately removed after being needed. PupDial would always have the extra step of asking for a master password, but a small price to pay for those paranoid about security ...as we are all becoming these days.

Any feedback please to the alpha7 thread:
http://murga-linux.com/puppy/viewtopic.php?t=27098 

Refined handling of power failure

March 23, 2008

Thanks to pizzasgood for this. He responded recently in the forum to a question about improving the handling of a power failure. In a region with frequent power failures, the next time that Puppy comes back up there is an automatic drop-out to the commandline. Well, that's ok, as there is an instruction to type 'xwin' to start X.

Pizzasgood's refinement is a dialog box where the person can choose to drop to the commandline, within 15 seconds, or choose to start X. The important point here is that the default behaviour after a 15 second timeout is to start X.

I have put pizzasgood's code modification into /usr/X11R7/bin/xwin.

Ayttm bug fixed

March 23, 2008

On March 21st I reported that there was a bug in Ayttm. I have been communicating with the developers, especially Siddhesh Poyarekar who has been extremely helpful. He has fixed the problem with IRC, and I have been chatting with the guys at #puppylinux.

I have also compiled the Jasper package, which enables Ayttm to support Yahoo Webcam. Ayttm is multiprotocol, handles IRC, ICQ, Jabber, MSN and Yahoo, but I have only tested IRC.

I expect that Ayttm will be in Dingo beta, although there is one little bug. The first time I join a channel, it doesn't seem to connect, not always. I have to close the window then rejoin. I've asked the Ayttm developers about that.

No 'cron' in Dingo

March 22, 2008

Oh yeah, one potential problem. I haven't yet used Gadmin-Rsync, so I'm speculating. The docs state that it can make use of cron. Now, Puppy only has the Busybox 'crond' and 'crontab', whereas the full cron package has 'crontab', 'cron' and 'cron.run' executables -- and strangely no 'crond'.

Will I be needing the full cron package? (note, it's very small). If you know something about cron (and what is that Busybox 'crond' thing?) and/or rsync, kindly respond to the Dingo alpha7 feedback thread:
http://murga-linux.com/puppy/viewtopic.php?t=27098

Gadmin-Rsync and rsync now in Dingo

March 22, 2008

The application that needs the full 'df' (as mentioned below) is 'gadmin-rsync'.

I am very interested in having remote file synchronisation tools in Puppy, motivated partly by security needs. The 'rsync' utility is in the 'devx' file, however I decided to place it in the live-CD. This is package 'rsync-2.6.9'.

I only have basic notions about what rsync does, and no knowledge how to use it. I thought it would be a good move to have a GUI frontend (which might help me to ease into using rsync), and I found two that use GTK2. One of them, I forget its name right now, seems to be only good for local backups, so I chose 'Gadmin-Rsync'. This is package 'gadmin-rsync-0.0.9' and it will be in Dingo beta.

Here is the developer's webpage for Gadmin-Rsync:
http://85.214.17.244/gadmintools/index.php?option=com_content&task=view&id=51&Itemid=38

The rsync home page is here, and this also has tutorials:
http://rsync.samba.org/

Full 'df' now in Dingo

March 22, 2008

I have an application that I want to put into Puppy. Unfortunately, it calls 'df' with the '-P' option, not supported by the Busybox 'df' applet. So, should I substitute it for the full df from the 'coreutils' package? Well, testing each of them:

# ./df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                  759208      4544    754664   1% /
/dev/sda1              1913244    296056   1520000  17% /initrd/mnt/dev_save
/dev/loop1              126931     16902    110029  14% /initrd/pup_ro1
tmpfs                   759208      4544    754664   1% /initrd/pup_rw
tmpfs                    64692     63692      1000  99% /initrd/mnt/tmpfs
/dev/loop0               63744     63744         0 100% /initrd/pup_ro2
/dev/loop3               77568     77568         0 100% /initrd/pup_ro3
unionfs                 759208      4544    754664   1% /
/dev/hda3             33452832  30508304   1585108  96% /mnt/hda3

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda1              1913244    296056   1520000  16% /initrd/mnt/dev_save
/dev/loop1              126931     16902    110029  13% /initrd/pup_ro1
tmpfs                   759208      4544    754664   1% /initrd/pup_rw
tmpfs                    64692     63692      1000  98% /initrd/mnt/tmpfs
/dev/loop0               63744     63744         0 100% /initrd/pup_ro2
/dev/loop3               77568     77568         0 100% /initrd/pup_ro3
unionfs                 759208      4544    754664   1% /
/dev/hda3             33452832  30508304   1585108  95% /mnt/hda3

See, the difference? The first case is the full 'df', which has two entries for '/'. This could break many scripts.

I had a similar problem when moving fom the Busybox 'ps' to the full version, where just executing 'ps' without any parameters returns difference results, which would break some scripts. I "solved" that by creating a script named 'ps' that calls the Busybox ps applet if there are no parameters, the full ps otherwise.

So, I have done much the same for df. If it is called with no parameters or just '-h', '-m' or '-k' then the Busybox applet is called, otherwise the full one.

These workarounds are not very healthy, and eventually the work will have to be put in to remove the need for the Busybox ps and df applets.

Ayttm crash fixed, but another bug

March 21, 2008

I'm working with the developers of Ayttm to fix bugs. As reported recently in this page, Ayttm was crashing in Puppy. The main developer has now fixed that, but when I joined #puppylinux at irc.freenode.net, I found that Ayttm can post but not receive messages. Displays info about people joining and leaving, it is just messages that aren't being received. I tested with Xchat, and dialog with 'wolf_pup', to confirm this.

I have reported this to the developers. I'm greatly hoping they can fix this bug, as I like Ayttm.

One question, for anyone into using Yahoo. Well, as this is not a blog, please reply to the forum, maybe in the Dingo 4.00 apha7 feedback thread. There is a configure option for Ayttm for Yahoo Webcam support, but it needs a package named 'jasper'. Would this feature be useful to you?

Pburn updated March 21, 2008 Zigbert and others are doing wonders with Pburn, our home-grown CD/DVD/Blue-ray burner application. It is shaping up to be as good as or even better than the heavyweight burner apps out there -- and far smaller. Well, there is a bit of a jump in size with this version, a move from 1.2.2 used in alpha7 up to 1.3.0, due to the introduction of themes. But still relatively small.

Improved volume control tray applet March 21, 2008 Forum member HairyWill developed the volume control tray applet that is currently in the Dingo alphas. It is fairly basic, and he did have another more sophisticated one that I chose at the time to not use. HiairyWill has worked on some issues, and has developed a new version that is looking very nice. It is discussed in this thread: http://www.murga-linux.com/puppy/viewtopic.php?t=27356 This will be in Dingo beta. So, when is this 'beta' going to make its appearance? I will have to schedule the upload for my next trip to Perth, when I get access to ADSL2. Actually, my daughter now has something called "naked ADSL" from iinet, which has no monthly line rental and all local and national phone calls free, for a total price of $50 per month. I think it's fast, but I don't know the specs. Anyway, about 8 -9 days from now.

Font bug fixed March 20, 2008 See the previous post, which introduces this bug. I thought some more about the origin of the URW Type1 fonts used in Puppy. They don't come from the T2 ghostscript-plugins-8.11 package, it goes back further. I dug out Puppy Unleashed 1.07, and it has the same fonts, but a complete set (in /usr/share/fonts/default/Type1. In a version of Puppy after 1.07, I cutdown that directory, but I cut it down too much. So, I have now created a new Type1 directory for Dingo, not quite so cutdown, and it has the missing Nimbus Roman No9 L bold-regular, plus a few others. The directory has grown from 1606K to 2576K uncompressed. The 'mkfontscale' and 'mkfontdir' utilities work fine with these original URW fonts from Puppy 1.07. I don't remember where they came from before that. The utilities do not work properly with the URW Type1 fonts supplied with ghostscript-fonts-8.11 package. I don't know why, but anyway I have resolved the problem and I'll leave it at that. I still haven't fixed the problem of some fonts not displaying properly in Abiword 2.6.0. These are 'fixed', 'dingbats' and 'standard symbols'. Strangely though, they do display fine in the font-preview when choosing a font. If I leave 2.6.0 out of Dingo beta, it will still be an official PET package, along with English dictionary and plugins packages. And the dependencies 'wv' and 'enchant'.

Abiword 2.6.0, font bug found March 20, 2008 The Dingo alphas have Abiword 2.4.6. I have compiled 2.6.0, but it is considerably bigger. The 'abiword' executable is 6748K whereas for v2.4.6 it is 4619K -- also the latter has the 'libwv' library statically linked whereas the latest Abiword has it as a separate 321K library. Oh, yes, the 2.4.6 package also includes the plugins, whereas for 2.6.0 it is a separate 2172K package. What all this means is that the total size of 2.6.0 is about twice that of 2.4.6. Ok, there are some extra plugins, like OpenDocument import/export, but is it worth it? For my standard Puppy live-CD anyway, I'm inclined to just stick with 2.4.6. I had trouble with getting various components in 2.6.0 to compile. I ended up with this configuration that worked: # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-printing \  --enable-threads --disable-gucharmap --disable-scripting --without-ImageMagick and for the plugins package: # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu \  --with-abiword=../abiword-2.6.0 --without-boost --without-abicollab --without-abigrammar \  --without-OpenXML I had to disable scripting as the Perl scripting interface would not compile. I had to disable some plugins as they would not compile. Unfortunately that includes 'abigrammar', even though I had compiled and installed 'Link Grammar'. I had to turn off 'abicollab' as it wants 'boost' installed even though I configured without boost -- all the other plugins were happy without boost. When Abiword 2.6.0 starts up, it looks the same as 2.4.6. I opened a test .doc file, ok. I started a new document, then I noticed that the 'Dingbats' font does not display -- it does in 2.4.6 -- instead it displays as the substitute rectangles that are used to indicate the font character cannot be found. Then I noticed something very interesting, a bug that is in both versions. The default font in a new document is 'Nimbus Roman No 9 L', and the system maps 'Times New Roman' to that font also. When I chose bold text, it did not display as bold. This bug must be in all prior puppies -- yep, I just checked Puppy 3.01, and reading /usr/share/fonts/default/Type1/fonts.dir shows that the Nimbus Roman No9 L bold font is missing. There are normal-regular, normal-italic, italic and bold-italic, but no plain bold. Something is very wrong with the Nimbus Roman No9 L font. I looked at the fonts directory in the Ghostscript-fonts 8.11 package (provided with the T2 build) and the Nimbus Roman No9 L bold-regular is there (as shown in 'fonts.scale' and 'fonts.dir'). Fine, but when I run 'mkfontscale' and 'mkfontdir' in that directory, the 'fonts.scale' and 'fonts.dir' files generated in the directory are wrong -- the bold-regular font has disappeared and has been replaced with duplicate medium-regular and medium-italic entries. The other fonts are alright. I need to download a later set of URW Type1 fonts.

SD card not working in Dingo alpha7 March 20, 2008 This problem will also apply to Puppy 3.02. The major device number used for the SD/MMC drives in /dev/mmc* was not standardised in the 2.6.21.7 kernel. It got fixed later, at 179. In Puppy 3.01 we used 253, and the 'mmc_block'  kernel  driver was loaded  with the parameter 'mmc_block major=253'. Note, the 2.6.24 and later kernels do not accept that 'major=' parameter, as the major number has been officially set at 179. If you look in Puppy 3.01, you will see that /etc/modprobe.conf has this: install sdhci /sbin/modprobe mmc_block major=253 ; /sbin/modprobe --ignore-install sdhci remove sdhci /sbin/modprobe -r --ignore-remove sdhci ; /sbin/modprobe -r mmc_block install tifm_7xx1 /sbin/modprobe --ignore-install tifm_7xx1 ; /sbin/modprobe mmc_block major=253 ; /sbin/modprobe tifm_sd For Puppy 3.02 and Dingo alpha7 (which has same 2.6.21.7 kernel) it has to be changed to: install sdhci /sbin/modprobe mmc_block major=179 ; /sbin/modprobe --ignore-install sdhci remove sdhci /sbin/modprobe -r --ignore-remove sdhci ; /sbin/modprobe -r mmc_block install tifm_7xx1 /sbin/modprobe --ignore-install tifm_7xx1 ; /sbin/modprobe mmc_block major=179 ; /sbin/modprobe tifm_sd For Dingo, I have put a hack into the 'createpuppy' script which inserts 'major=179' if the kernel version is less than 2.6.24. Note, 'major=' parameter cannot be used in the 2.6.24 kernel, it prevents the driver from loading. Puppy 3.02 developers can simple edit /etc/modprobe.conf and insert "maor=179" in the two places.

Busy designing themes March 17-19, 2008 Sheesh, what a way to waste lots of time! I have been playing with JWM and GTK themes for a couple of days. Trying to develop that elusive "perfect" theme for Dingo beta. Then yesterday I drove to Perth, needed to pickup some things, and basically that's an entire day lost. Furthermore, I drew a book of science fiction short stories out of the local library and last night settled down for a read. Good stories, written by Ted Chiang. Anyway, today I'm back in business working on Puppy, determined to make much progress.

Monkey web browser March 17, 2008 Kirk has updated the 'Monkey' web server package, originally created by GuestToo, with the latest version 0.9.2 compiled in Dingo. I have made this into an official PET package.

Gxset crashes March 17, 2008 Well that's unfortunate. This has been reported in the Dingo alpha7 forum feedback thread. Gxset is a frontend for the 'xset' utility. It is really a GTK1 application, but has been compiled against the GTK2 libraries. Debian and Ubuntu have it as one of their maintained packages, compiled against GTK2. However, it is unusable. We could write our own GUI for xset. But, for now I have no choice but to withdraw Gxset from Dingo. I searched, cannot find a replacement.

Compiling Mozilla source from CVS March 16, 2008 I'm doing something that I have wanted to try for a long time. Back-stepping slightly though, I was prompted to try SeaMonkey 2.0alpha1 due to the 'Print preview' bug in SeaMonkey 1.1.6 and 1.1.8 running in Dingo. Then I remembered what I had wanted to try for a long time -- get the core Mozilla source code, that can be used to build SeaMonkey, Firefox, Thunderbird, Minimo -- whatever you choose. All of the Mozilla projects use one code base, and I learnt how to get it all from CVS. My thought was, if I can build Firefox, then say Thunderbird, as standalone packages, as they are all built from the same source they would also have a lot of files in common. If I can determine those common files, then I can create a Puppy with the perceived advantages of the standalone apps, but smaller (I emphasise "perceived", as I personally like the suite best). Well, that was my reasoning. We shall see. Right now I'm doing a SeaMonkey build, with just the Navigator (browser) and Composer modules, plus all the extensions like IRC chat (as I was unable to select a subset as I have done in earlier SeaMonkey builds). One thing, it requires an unstable version of 'cairo' -- at least 1.5.2 and I installed the latest unstable release, 1.5.12. UPDATE: Well, I tested the SeaMonkey build. 'Print preview' works! However, in Composer the web pages open and display but actual editing is totally disabled. So, win one, lose one. So, I downloaded a prebuilt SeaMonkey 2.0a1pre binary tarball, but it has the same problem with Composer. Apart from that small detail of Composer being totally unusable, the browser looks ok. Anyone who wants to test SeaMonkey2 and Firefox2 though, will need to be aware of the issue with the 'cairo' package. Running 'ldd' on the browser executable shows that it needs 'libcairo.so.2', and you will have that, however the actual version of cairo that you have in all current puppies is too old. This may cause instability. I'm going to build Dingo beta with cairo 1.5.12, the latest. Note also, Cairo 1.5.x has an extra dependency, the 'pixman' package, and I have version 0.9.6.

waitmax: exec with timeout March 15, 2008 Ah, I've been wanting this for sometime. This utility executes an application in another process and will kill the process if it exceeds a certain time limit. In Bash, I achieve the same by running a wait loop that examines the process pid and has a loop counter, and kills the process when the count reaches a certain limit. However it is neater and more flexible to have a utility for this purpose. Waitmax compiles by default with Dietlibc (which is in Dingo's devx file) so it is a static excutable, just 16KB. I have put this into /bin and also into the initial ramdisk -- not that I'm using it in the initial ramdisk but I reckon that I will want to. The author is Mathias Kettner and his project page is: http://mathias-kettner.de/waitmax.html

Improvement in zdrv file March 15, 2008 I've been wanting to do this for sometime, but put it off in case there were complications. But now I have done it, and it was quite simple to implement. There is a fundamental problem with the firmware in the 'zdrv' file. In Unleashed, each firmware "package" is in its own directory. This is not just firmware but also anything else that a module might need, such as executables, and script that has to execute at bootup. The 'createpuppy' script copies all of these firmware packages to target installed locations in the zdrv file, and records a list of all the directories and files of each firmware package in /lib/modules/firmware.dep.<kernel-version>. However, this is unecessary complication and it imposes a big restriction. The restriction is that the zdrv file cannot be mounted as a normal SFS file in the Unionfs layers. The reason for this is that every single firmware package is installed in its target location in the zdrv file. For example, the Smartlink modem firmware package for the 2.6.21.7 kernel is 'slmodem-2.9.11-20070505' and it has these directories and files: etc/init.d/zzslmodem var/lib/slmodem usr/share/doc/slmodem.txt usr/sbin/slmodemd pinstall.slmodem-2.9.11-20070505.sh Note, the last file is a script that is executed once-off by 'modprobe' when the firmware package is installed. If you were to mount the zdrv file as a Unionfs layer, then all of these files would be present, and the 'zzslmodem' startup script would execute regardless of whether the appropriate Smartlink kernel module is loaded. The solution is simple. In the 'createpuppy' script, the firmware packages are copied to the zdrv file at /lib/all-firmware directory. For example the Smartlink firmware will be a directoy /lib/all-firmware/slmodem-2.9.11-20070505. The zdrv file can be mounted as a Unionfs layer and all firmware is out of the way until needed. The script /sbin/modprobe takes care of installing the firmware for a module. It checks /lib/modules/fimware.dep.<kernel version> which matches a firmware package to a particular module. If there is a match, the firmware package is copied out of /lib/all-firmware to its target locations. This improvement will be in Dingo beta. I have yet to explore the possibilities, but it does have great promise. The zdrv file could be mounted at '/' in the Unionfs layers and then run depmod (or even just copy all the file that depmod generates to the top, as they already exist in the zdrv layer), then all modules are present and nothing has to be fetched from the zdrv file. The zdrv file does not have to stay loaded. Anyway, I have put the improved format of the zdrv file in place, and we shall see what can be implemented in the future. To implement the above, I modified 'createpuppy' script in Unleashed and /sbin/modprobe script in the '0rootfs_skeleton-4.00' PET package in Unleashed.

Full hard drive install fixed March 14, 2008 Forum member 'Sage' reported that full hd install in Dingo alpha7 does not work. This is a victim of the backporting of /usr/sbin/puppyinstaller from the unified /dev/sd* drive notation to supporting the /dev/hd* notation required for the 2.6.21.7 kernel used in alpha7. The fix is simple. Line 1138 in 'puppyinstaller' needs to have 'idehd' and 'satahd' options added to it, as shown:  scsihd|atahd|idehd|satahd) #internal media, boot with boot-disk or grub. #v3.98 Alpha7 testers can easily do this. Note for Puppy 3.02 developers, you also need to apply this fix.

Do you hate the Citrus theme? March 14, 2008 Dingo alpha releases have the 'Citrus-cut' GTK2 theme, which has drawn mixed reactions, mostly negative. When I designed Puppy 3.02alpha1, I chose different themes for JWM (Black-vg) and GTK2 (Stardust) plus uniform grey background, and these have had a much more positive reception. So, now that I'm planning for Dingo beta, I should settle on a final theme. Dingo has the same theme as used in 3.02alpha1 just not set as default. Should I make it the default, or keep Citrus-cut as the default? Citrus-cut does make a "bold statement", which was kind of my rationale for choosing it. If you have a thought on this, kindly vote at the alpha7 feedback thread: http://murga-linux.com/puppy/viewtopic.php?t=27098 CORRECTION: No, I think the GTK2 theme used in 3.02alpha1 is 'Phacile_blue'. It's an official PET package.

Network Wizard bugfix March 14, 2008 Thanks to 'urban soul' who posted a bugfix. I found the post in a Puppy 3.02 forum thread, and replied there: http://murga-linux.com/puppy/viewtopic.php?p=181534#181534

Dialup improved March 13, 2008 As I have been on satelite broadband for sometime, I am neglecting the needs of dialup users. Some issues have been reported for Dingo alpha7. Fortunately, a couple of guys are solving these problems. Forum member rerwin has tackled a couple of problems, and has modified /etc/rc.d/rc.modem, a script that executes at bootup. Here is the comment that rerwin has placed in rc.modem: #v3.98 RE 12mar2008: synchronized modem setup to actual hardware, so that only serial modems retain their setup if modem is turned off at bootup time; added detection of LT modems that do not identify themselves; changed temporary use of underscore to avoid corrupting username (rerwin). Forum member zygo had the problem of a connection disconnecting after 2 seconds. By manually entering username and password into /etc/ppp/chap-secrets and /etc/ppp/pap-secrets, the problem was fixed. However, this is a mystery, as the wvdial.txt documentation file states this: /etc/ppp/{pap,chap}-secrets Contains a list of usernames and passwords used  by pppd  for authentication.  wvdial  maintains this list automatically. So, what is going on here? Dingo has wvdial version 1.53, whereas Puppy 3.01 has wvdial 1.41. So I tried 1.41, but still the same thing. wvdial is not writing to chap-secrets and pap-secrets. I could put code into the pupdial script to write to these files, but it still doesn't solve the mystery. I just noticed something else. My memory was jogged that Gnome-ppp has this problem of premature disconnect. I looked at the gnome-ppp package in the Dingo PET repository and I see that it is missing the startup wrapper 'gnomepppshell' that was in the package in Puppy3. I have put it in, and set the menu to run that wrapper. But anyway, I think the problems with Gnome-ppp go back to Puppy3 and earlier. Anyway, I have modified the 'pupdial' script to write explicitly to /etc/ppp/chap-secrets and pap-secrets before calling wvdial. This is a workaround, and really we should look at the source code for wvdial and find out what has gone wrong -- which will probably never happen if the workaround works ok. Probably Gnome-ppp would also suffer from this problem, which is not so easy to workaround as it is a compiled application. I'll post this modified pupdial script to the alpha7 feedback thread: http://murga-linux.com/puppy/viewtopic.php?t=26985

Clicking on an image in ROX-Filer March 13, 2008 When a raster image is clicked on in ROX-Filer, mtPaint opens. ROX file association for images is /usr/local/bin/defaultpaint, which in turn executes mtPaint. This has sometimes been criticised however, with the suggestion that clicking on an image should bring up the image in a simple viewer, not a full-blown image editor. In forum feedback for alpha7, it has been suggested that images should open in Fotox, due to its sizing/rotating/slideshow capabilities. /usr/local/defaultimageviewer is currently set to Gview, which is a super simple image viewer. Gview just displays an image, that's it, although it does have some keyboard actions, but you wouldn't know about those unless you read the docs. ROX is also set to open SVG images with InkscapeLite, but again that could be changed to Gview. Strangely, Gview displays SVG images ok, Fotox does not. From my personal point of view, usually when I click on an image it is because I want to edit it. So, I am quite happy with it opening in mtPaint. I need feedback on this, what is the majority opinion? Gview, Fotox or mtPaint? If you would like to submit an opinion on this, kindly post to this alpha7 feedback thread: http://murga-linux.com/puppy/viewtopic.php?t=27098 Of course, ROX has 'Open with...' so that we can choose alternatives to the default action.

PcurlFtp updated March 13, 2008 Forum member kirk has been extremely creative with this application. It is a very simple mechanism for file sharing over a network, great for a local network of Puppy PCs. In Dingo alpha7 it is to be found in the Network menu, as 'PcurlFtp file sharing', but you can also just click on /root/File-Sharing directory in ROX-Filer. Then just follow the simple steps. Kirk has updated the package on Feb. 13, and I have updated the official PET package, now named 'file_sharing-curlftpfs-mpscan-0.2-0.9.1-0.1.0' (the 0.2 was previously 0.1) -- it's a long-winded name as the package also includes curlftpfs version 0.9.1 and mpscan version 0.1.0. Find out more in the forum thread: http://murga-linux.com/puppy/viewtopic.php?t=25537

Mut2 engine for Pmount March 13, 2008 Jesse Liley is actively developing the next generation of his MUT drive prober/mounter application. The version in current and earlier puppies is a Tcl/Tk script, whereas the core of 'mut2' is a binary excutable written in C. Jesse has also written a Tcl/Tk GUI for it. The new 'mut' binary executable is multifunction and among other things can perform the equivalent of the 'probedisk' and 'probepart' scripts that are called by Pmount to probe drives (Pmount is the drive mounter GUI application in Dingo). In other words, the underlying engine of Pmount can be setup to be either the probedisk/probepart utilities or mut. I have modified Pmount (usr/sbin/pmount) so there is a checkbox that enables switching between the two engines. So, if you think that the default display of Pmount is not showing your drives correctly, you can switch to the mut engine, and vice-versa. I currently have Jesse's mut version 1.0.0.115 in Dingo, and it is at /usr/sbin/mut.

HotPup for Dingo March 13, 2008 Due to popular demand HotPup will be in Dingo beta. In the long term I plan to implement udev in Dingo, which would be a different way of managing drives and hotplug events (uvents). However, for now HotPup is a superb solution. HotPup was created by forum member 'Dougal' and is to be found in the revamped Puppy 2.14R created by Dougal and Pakt. HotPup is also in the alpha releases of Puppy 3.02 being developed by tronkel and others. The version of HotPup that I have had one problem. The output of 'xrandr' in Xorg 7.3 is different from earlier puppies. I put a test in the script, not for xrandr version but for Puppy version -- 390 or later is assumed to have the xrandr with the new output format. I created a PET package for Unleashed, 'hotpup-20080313'.

More bugfixes for Dingo March 12, 2008 The original thread created to provide feedback on alpha7 is here: http://murga-linux.com/puppy/viewtopic.php?t=26985 However, another has been created here: http://murga-linux.com/puppy/viewtopic.php?t=27098 In both of these I have responded with some bugfixes, that have not been explicitly mentioned on this blog. For example, in the second thread I have notified that there was a bug for drives /dev/sdg and greater not being recognised, now fixed.

SeaMonkey upgraded March 12, 2008 There is feedback that 'Print preview' in SeaMonkey, Puppy Dingo alpha7, causes SeaMonkey to crash. It does for me to, so I have upgraded from version 1.1.6 to 1.1.8. Unfortunately it still crashes. I'll check the bug reports at SeaMonkey bugzilla and make a report if necessary. UPDATE: I can't see where to post a SeaMonkey-specific bug report. There are some bug reports about Print Preview crashing in Firefox -- some opened as early as 2004 and still open, one of them even marked "critical". There is a newsgroup for SeaMonkey developers, perhaps I'll post there, or maybe I can't be bothered right now, seeing what a low priority the existing "Print Preview" open bugs seem to be getting. UPDATE: Well, it isn't nice, but I have removed "File -> Print preview" from the menu. As it doesn't work, there's no point in having it, and no point in having SeaMonkey crash unexpectedly. For the record, I commented out line 360 in /usr/lib/seamonkey-1.1.8/chrome/comm/content/navigator/navigatorOverlay.xul

guess_fstype utility fixed March 12, 2008 I reported about a week ago that guess_fstype failed to determine the filesystem type of a partition created with the makebootfat utility. Jesse has now fixed it. The PET package is now 'guess_fs-20080312' and will be uploaded to ibiblio soon. I also compiled 'guess_fstype' statically with uClibc as it is required in the initial ramdisk. The source package is 'guess_fs-20080312.tar.gz' and I'll upload to puptrix.org (our Puppy source repository).

Xchat IRC client, Lirc ICQ client March 11, 2008 I have compiled Xchat, version 2.8.4. Works well. I joined #puppylinux, and there was wolf_pup. Wolf_pup suggested that I checkout Instantbird. Anyway, I've made Xchat into an official PET package. LICQ has a Qt GUI, but the GUI is in the form of a plugin and others are available. There is a GTK2 plugin available separately, named 'icqnd'. I compiled LICQ and icqnd and it started up ok. It has to be invoke from the commandline with '# licq -p icqnd' otherwise it tries to load the default Qt plugin. I then tried to create a new account, and it got to asking me to verify a security image, and is stuck at that point. Seems to be waiting for something ...maybe the ICQ server is to busy? Whatever, I'm unable to verify that it is functional. I don't know anything about ICQ. I wonder if there is any demand for it amongst Puppy users?

Altenatives to Pidgin March 11, 2008 I need to upgrade Pidgin in Dingo, as there is something wrong with the version in alpha7. But, Pidgin is so big, adds about 2MB to the live-CD iso file, even after I have hacked it right down. So, I decided to take another look at lighter alternatives, and first stop was 'Ayttm'. This is a very small multiprotocol instant messenger, handling IRC, ICQ, MSN, Yahoo and Jabber. I have been on the Ayttm mail list for a couple of years, watching progress. Nothing much seemed to be happening for awhile, but the lead developer Colin Leroy and helpers are still working on it, which is great. I managed to login to IRC channel #puppylinux and posted messages. There were others online but noone replied. Then the program crashed with a signal 11. I found that it consistently crashes after running a few minutes. That's a great shame, as Ayttm i really small. I have posted a bug report, and hopefully it can be fixed. Note, I also got it out of CVS, version 0.5.0-32, still crashes.

The latest response from Servage March 10, 2008 Is this finally an admission? Hello Barry We are very sorry for this incident happened. We are working on making the server security more improved and tighten. Meanwhile we would like to request you to change the file permission to 755 and please change control panel password. Thanks for your consideration. Kind regards, Julie, Support Team Member Servage Hosting What do you reckon about her advice to change file permissions to 755! My files are already 644. And I'm not going to change the control panel password again. Another little note to throw in, re thinking about the pros and cons of Servage. Servage is blacklisted by at least one of the online blacklist databases, and as I use Servage webmail for my bkaulerATgooseeDOTcom, I sometimes get email bouncing when I post to an email address that uses that online blacklist service.

A bit more info about Servage March 10th, 2008 I was thinking that Servage admin could examine their logs to find out more about how my site has been compromised, but it seems that they don't keep any logs: http://www.opendesigns.org/forum/discussion/1773/can-you-give-me-a-security-check/ The control panel does have some record of who logged in, but it's hardly any information. Oh man, I have just run across some customer feedback on Servage: http://hostjury.com/reviews/Servage

The Servage saga continues March 10th, 2008 A few hours ago I posted this to Servage: Well, that's it, my site has been compromised again. I did a very quick check and it seems to be only one file: http://www.puppylinux.com/index.html Please read through this ticket. I have done it before, but I went through all the steps again, reuploading files, removing all scripts, checking all permissions, changing control panel and ftp passwords. Then I waited, now a file has been compromised. This means that without any doubt Servage has a security problem. Perhaps caused by another client on my cluster? Anyway, enough delay, you have to forward this to someone who can investigate and fix it. And soon, I'm getting really tired of this. I'm not going to leave the hacked file up there very long. I'll wait 3 - 4 hours then fix it. So, if you want to see the hacked file, look at it quickly. Note, I checked Account Security, no one else has logged in. And I received this reply from Servage: Hello Barry I must say that there must be some insecure script is running for you, so that other person can enter. So, please check once again all the thing at your end. As we can not find any security issue at our end and neither any other client has nay sort of problems with the security. Thanks for your understanding and co-operation! Kind regards, Steven, Support Servage Hosting Well, for a start, what a lie to state that "neither any other client has nay sort of problems with the security". Puppy Linux forum member 'proxy' has reported the same intrusion that I have experienced, and guess what Servage told him, that no one else had reported this problem. See his blog: http://www.proxyutza.com/2008/03/07/exploit-iframe-trojan-infection/ and our on-going discussion of this: http://murga-linux.com/puppy/viewtopic.php?t=26767 I don't have any scripts left. Well, not exactly, WordPress is still there, I just renamed the directory to something no one will guess. Anyway, I shall reply to their reply. Oh yeah, I've cleaned up my site, yet again.

PETget dependency checking fixed March 10th, 2008 As reported in the previous post, when I installed Gxine PET package, the package manager reported that 'xine-lib' was missing. I have fixed that. The problem has to do with the '-' delemiter, where petget was thinking of '-' as the delimiter between the name of the package and its version number. But of course 'xine-lib-1.1.8' is an example where that is not true. Another bug surfaced when I installed Xfmedia. I have known about this one for a long time, now have finally fixed it. When PETget installed Xfmedia, it reported that the following dependencies are missing: libexo_lib, libxfce4util and libxfcegui4. The package manager then queued them to be downloaded and installed, however when it asked me which repository I wanted to download from, I hit the 'ABORT' button. The problem is though, that the petget script had already changed the entries of the dependencies in /root/.packages/livepackages.txt from 'off' to 'on'. So, next time I ran PETget, it thought those dependencies where already installed when I clicked on them to try and install them. I have fixed this -- obviously livepackages.txt should only be updated after a package has successfully installed.

Back to Gxine March 9th, 2008 Those who have been following the Dingo saga will know that it has been difficult to find a media player that is truly satisfactory. Alpha7 has Xine-ui, however I am not at all happy with it. Today I have been playing with Gxine, and running on the 2.6.21.7 kernel it runs ok. Regarding the full-screen problem, as long as you remember to maximise the window first, then it goes into full-screen (has anyone told the developers about that?). I don't know why the kernel would make any difference, and I can't recall what the problems were but I think running on the 2.6.23.x and 2.6.24.x kernels Gxine has some extra problems. But, for the 2.6.21.7 kernel it's fine. So, the beta release of Dingo is going to have Gxine, as of now that's version 0.5.11. I also played wih Xfmedia, but got really put off when I selected to play a CD and it froze for awhile. Gxine also has a delay before starting to play the CD, at least on my laptop which does have a troublesome CD/DVD drive, but at least Gxine displayed a message that it was loading the CD, so I knew something was happening. Xfmedia has extra library overheads and there is nothing that stands out to warrant choosing it. For anyone testing alpha7, Gxine is a PET package. Gxine installs its own browser plugin, into /usr/lib/mozilla/plugins, so you might want to delete 'xineplugin.la' and 'xineplugin.so'. Hey, there's a bug in the Gxine package -- the Gxine plugin 'gxineplugin.so' is at /usr/lib/mozilla instead of /usr/lib/mozilla/plugins, so you will have to move it. I'll fix the original package right now. I installed Gxine just by clicking on the PET package and after installing it reported 'xine-lib' dependency is missing, which is wrong. Another 'petget' bug. I'll fix that right now.

petget bugfix March 9th, 2008 I haven't got going yet on overhauling 'petget', the PET package manager, but I was installing Qt in alpha7 and found a couple of bugs, so fixed those. One bug was that it tried to install Gpicview but I had already installed it earlier before upgrading from alph6. Fixed. There was another bug. It seems that the dependency-list for the Qt entry in /root/.packages/package.txt was too long.

/etc/TZ is history? March 9th, 2008 'mikeb' has modified /usr/sbin/timezone-set script in Puppy2 so that /etc/TZ has 'utc' in it rather than 'pup'. The reason I put 'pup' is because I read the specs paper on /etc/TZ which stated that the first three characters do not matter. However, some apps like Xfce expect 'utc' or something more normal. Puppy3 and Puppy4 do not have /etc/TZ at all. From what I was lead to believe after some study, it isn't needed anymore. The /usr/sbin/timzone-set no longer creates this file. However, /etc/profile does export the TZ variable: TZ="`readlink /etc/localtime | sed -e 's%/usr/share/zoneinfo/%%'`" #v3.02 export TZ ...but only for Puppy 3.02 and 4. Puppy 3.01 does not even export that variable. I read this somewhere, that the TZ variable these days can just be set to same as what /etc/localtime points to. If anyone has any suggestions, please post them. Not here, as this is not a proper blog right now, but to the forum, maybe in the alpha7-feedback thread so I'll be sure to see it. Or, post to the thread that 'mikeb' has started: http://murga-linux.com/puppy/viewtopic.php?t=26931

Pburn upgraded March 8th, 2008 Zigbert has upgraded Pburn to version 1.2.2 and Pfilesearch to version 1.1. The latter is a support package for Pfind and Pburn. A note to 'GrumpyWolfe' who is testing Dingo alpha7 and reported that when using the Universal Installer to install to USB, the 'pup_save' file got deleted. I just looked t the code in /usr/sbin/puppyinstaller: echo "No, press ENTER only to not wipe all files, or" echo -n "Yes, press any alpha or numeric char then ENTER to wipe all files: " read WIPEALL if [ "$WIPEALL" != "" ];then  echo  echo "Deleting everything in /mnt/data..."  rm -rf /mnt/data/* else  #well, minimum to get rid of...  rm -f /mnt/data/image.gz 2> /dev/null  rm -f /mnt/data/usr_cram.fs 2> /dev/null  rm -f /mnt/data/pup_*.sfs #v2.11  rm -f /mnt/data/devx_*.sfs #v2.11  rm -f /mnt/data/zdrv_*.sfs #v2.16 fi ...that seems okay.

GTK theme customised for an application March 8th, 2008 Thanks to Zigbert and MU who have been discussing this topic in this thread: http://murga-linux.com/puppy/viewtopic.php?t=22127 I did not know about that variable, so that's great thanks, I have applied it to two of my own scripts. Please note though, that Puppy 3.02 and Puppy 4 use the GTK2 theme at /root/.gtkrc-2.0, not at /etc/gtk-2.0/gtkrc. The default behaviour is that GTK looks at the later location first, then the former, so you can have a gtkrc at the latter location, but it will get overridden by whatever is in the former. This is what I have put in my scripts, /usr/sbin/pupscan and /usr/sbin/pupdial: echo 'style "specialmono" {   font_name="Mono 12" } class "GtkText*" style "specialmono"' > /tmp/gtkrc_mono export GTK2_RC_FILES=/tmp/gtkrc_mono:/root/.gtkrc-2.0 RETSTRING="`gtkdialog3 --program=MAINDIALOG`" But, if you want compatibility with Puppy 3.01 and earlier, you could first test if /etc/gtk-2.0/gtkrc exists, if not then it must be Puppy 3.02 or later.

Another brain-dead reply from Servage March 7th, 2008 I posted their first reply below. I replied to that, explaining that I have already done everything, more than once, and this is their second reply: Hello Barry Dear sir sorry to hear about your hacking issue again. Kindly remove all the file contents in your account, change all the passwords, re-upload all the contents. Make sure that you are not using any insecure script in your account. May be this is happening for any insecure script. Thank You Have a nice Time:) Kind regards, Shelly, Servage - Support Servage Hosting It doesn't seem to matter how many times I tell them there are no scripts, not even any embeded Javascript. I have cleaned up my site this morning. I wen through and reuploaded all html files. Then I noticed something which damns Servage perhaps, and I after posting a reply to the above, I also posted this: I can prove that something is wrong with your hosting. The directory /www on my site does not have a domain pointing to it, but I have a index.html file in it that has also been hacked. I have just been through my site reuploading all html files and I removed that particular file. As none of my domains point to that directory, it is a top level directory that none of them can access and there is no way any hacked script in any of my web pages could access /www. It has to be a security fault at the server level. My site has a directory for puppylinux.com and alongside that at the same level is /www. Can anyone tell me how an interloper can go one-up from the root directory of the domain? I have three domain names, all pointing to their own directory, none point to /www. Some discussion about my hacked site is going on here: http://murga-linux.com/puppy/viewtopic.php?t=26767

(c) Copyright Barry Kauler 2008. All rights reserved. http://puppylinux.com