logoPuppy developer news:

from 2.13 to 2.14

left-arrow Older news

arrow-rightLater news

Puppy version 2.14 released 

This new Puppy has major improvements in the underlying architecture as well as the applications, and some new applets created by Puppy enthusiasts. Finally we have embraced the XDG menu system, our new PET package management system is further refined. New applets are Pfind (file finder), and Grafburn (CD/DVD burner). Upgrades are many, including Pupctorrent (torrent downloader client), Network Wizard, Pbcdripper (CD ripper), PuppyBackup, SoxGui (audio file "Swiss army knife"), mtPaint, elscpi. Plus lots more -- read the Release Notes!

Release notes here: http://www.puppylinux.com/download/release-2.14.htm
Download links: http://www.puppylinux.com/download/index.html

Oh my, so many news! Good work, keep going :)

where is the checksum file numbers

Md5sum file is on the ibiblio website, alongside the iso file. But, here it is also:
5012d1fd6d9bb5907ea358ecfd865153 puppy-2.14-seamonkey-fulldrivers.iso

I had a crazy idea to download it at home -- on dialup. It took six hours -- wget is brilliant. I'm also glad to see I downloaded the latest upload. I'm using it now.

Forum member "Previously known as guest" has kindly mirrored Puppy here:

Jason Pline 
Nice work Barry (and everyone else)! I was going to mention something about TKdvd before you put out 2.14 but I forgot. Maybe a note for 2.15 though. The main window needs to be enlarged to see the Burn button on the bottom and so the Excluded files button is scrunched and unreadable. There's a line that sets the window geometry in the TKdvd script.

wm geometry .

Should be set to 750x650 (I'm using a 1024x768 screen)

Also 4.0.5 is now out.

Thanks Barry I just burned it & it seems fine,I really like it.
My only slight hasle is sound,must modprobe sb in console, doesnt seem to have drivers for awe 32 or 64 like the version 1.0x did.
Also cant get wireless to see network, but using ethernet anyway.

Great job so far.

P/S after seeing the md5 number mine matched after all.

Keep up the good work you & your crew.

Looks good but neither of the remaster scripts will run for me. I get the first dialog box press okay and I then get a full screen with instructions on how to run xdialog.

everything else looks good.


Various firmwares for wifi drivers still didn't make it into 2.14.
But there's a need to make available additional/alternative wifi drivers anyway (especially Zydas) so I will put together a "wifi Service Pack" shortly.

Craing: are you running on a machine with only NTFS partitions? That could be the cause of the problem and the latest version of my script solves that (it's available on the community forum, on the last page of a thread named "Testing: improved remaster script").

Bill St. Clair (billstclair<at>gmail.com) 



This puppy is working almost flawlessly.

It's now booting in 30 seconds from a sata drive (starting up from the LiveCD) and is correctly setting mode 12. The 30 seconds include the wait time for WPA association!!! that is fast.

I've found a single issue with puppy (incorrectly?) associating the wireless card with the bcm43xx driver.


I've applied a workaround so my puppy 100% healty right now.

The remaster script from the forum worked great is there a reason it hasn't been included in 2.14?

Very very fine! Wpa, speed! Yet Avi in Gxine and support to Photosmart 7760. So Puppy would be all i need.


Craig, a few things got missed out, for one reason or another. We can put together a Service Pack with the fixes/improvements.

I propose that 2.15 be a "consolidation" release, especially to include the excellent work that Dougal and Rarsa have been doing with various scripts. In fact, instead of doing a 2.14CE, why not make it a 2.15CE and I'll host it on ibiblio, as well as all the required PET packages?
In other words, Dougal, Rarsa, Lobster, and anyone else who wants to be in it, get together and make 2.15 "your" release.

I want to go back to T2 and work on that, plan for Puppy 2.20 (but I think there will be a 2.15 and a 2.16 before that). I want to work on fully automating souce --> final-puppy-live-cd.

Just noticed something else. I cannot play a regular dvd in gxine. and strangely cannot get my dell broadcom wireless working with ndis wrapper If I use a vanilla 2.14. It says it loads the driver and then is unable to load ndiswrapper. It did work for me initially and continues to on that remaster so I am trying to figure out what I did different.


Craig, did you upgrade from 2.14alpha or beta? I tested Gxine in a pristine 2.14-final and it played a DVD okay.

How general might that last comment be, Barry? I am having a whole bunch of issues with 2.14 upgrades, including a serious network no-go which rarsa is helping me with, the 'missing icons syndrome' which is afflicting Henry from Oregon as well as myself, mouse freezing, and various other stuff reported elsewhere. If the upgrade is not working as it should at present, maybe this could be flagged more prominently until it's fixed?


I deleted my pup save file off the hd and burned a pristine 2.14
still no go. I also have trouble playing some avi's that I have burned to disk but I will try all of this on another machine first just to make sure it is not a machine specific anomaly. I will get back to you tommorow got to go to bed now.



Can't believe my eyes! I've been using cfdisk from a terminal ever since I discovered Puppy. This morning, I get "Opened disk read-only - you have no permission to write" !!! [After a week's discussion on the Forum about root/user protocols!] It then takes a few <Enter> keypresses to get to the partitioning screen, with a couple of pages of switches listed along with the author's name, but no indication that if you keep going you will get the set-up you might've needed (this only occurs at the first attempt). But when/if you get there, it shows the incorrect disc size and parameters, so the whole thing is useless. First time round I just deleted the terminal! One step forward, two steps back....
Fortunately, GPartEd came to the rescue, except it wanted to label the single HD as hdc ??
So is there any good news? Yes! Cleaning out the HD and doing a completely fresh install has solved my network connection issue (I'll advise rarsa), my mouse freezing issue, but, alas, not only are my d/l icons gone, but I've got to reinstall all the apps as well. That just leaves Craig's problem to sort out.
Sorry, Barry, just too many features turning up in 2.14.

..and the time-out for these comments is still too short if one needs to check stuff and write it in the box as one progresses (or regresses?!).

thanks....... I have Puppy 2.12 in my HD, how upgrade to 2.12?


  Sorry to 2.14..............

Congratulations to Barry and the many gifted and talented contributors in making this wonderful release possible. Puppy Linux 2.14 is truly remarkable. I am a newbie when it comes to using Linux, and have found Puppy Linux to be the most intuitive and easy to use Linux Live CD Distribution that I have used to date. The only difficulty I had was in setting up my HP Officejet 5610v All-in-One, but resolved the problem with installing the Dotpup for CUPS installation.

Thank you again for providing us Puppy Linux 2.14.

Sandwichbutton (sandwich<at>sandwichbutton.com) 
Hello Puppy Team!

Congratulations on what appears to be a very successful release! I have always defaulted to puppy because I can't find any other OS (including the Win9x and NT family) on my Dell Latitude C800 Laptop. Unfortunately this new release appears to have introduced several bugs to the hard drive install (via the IDE/ATA method 2). Following installation, when booting for the first time, the screen would fill with an input/output error when accessing line 70 of the keybdlist.txt file. I fixed that by control+c'ing my way to the root command line. where i deleted the contents of /tmp. Upon reboot I managed to boot into the graphical mode just fine.

Except the network driver for my wireless card was not loading like it had on the live cd. Well a quick glance at the dmesg output had more of the input/output errors encountered with problem #1. So I erase the contents of the /lib/modules/ directory. and copy the same folder from the live CD's ramdisc(or whatever its called when installed into volatile memory from cd) to the same folder i deleted the contents of. Yay! My ornioco_cs driver is loaded and i have wireless internet.

I then traveled to youtube.com to test the flashplayer installer from mozilla, and it worked first try, I WAS REALLY IMPRESSED! So without restarting my browser or anything I see a video play... but there is no sound. So I run alsamixer, because I'm certain the snd-maestro3 driver is loading into memory, it did on the live CD ("bark, bark"). Well apparently it didnt load the sound like it did on the live cd, dmesg gives me a bunch of snd_maestro3: Unkown symbol snd_ac97_write
or snd_maestro3: Unkown symbol snd_XXXXXXXXXX errors.

OK, so I reboot into the livecd and copy the sound drivers from the live cd onto the drive, because, on my cd sound works just fine. Booting from hda1 however, doesn't load the driver. Well after replacing the driver and booting back into my hard drive install, the exact same errors return.

Now I'm not complaining, I realize I have relatively obscur hardware, but given the fact that puppy had traditionally worked so well on my crap laptop, that this 'step forward' isn't quite so great for me. I really like the release, it is very fast. Had I not tried this and seen the same results over 3 consecutive clean installs, I would think this a fluke or a sign of hard drive corruption. Seeing as win98's scandisk utility, and debian 3.1 see no problems with the disk. You guys are doing great, but it might be time to slow down with the radical changes and focus a release on house cleaning.

Fantistic work, I really like Puppy which I have been playing around with for about a year now. Thanks to Barry and everyone contributing to this distribution.

I just wanted to mention two things I discovered concerning Puppy 2.14, as maybe I am not the only one:

I think it was mentioned before that the pfix=ram option doesn't prevent Puppy from mounting pup_save.2fs when booting from USB-stick. It is the same problem booting from harddisk. Is there a simple fix to that?

One reason I like Puppy is its small size, so that I can also run it on older hardware. Up to 2.13 it really worked fine. Since 2.14 I am not able to boot any more, it seems that vmlinuz interrupts boot process in a very early stage. Booting stops by rebooting without warnings immediately after grub writing some lines on the screen. I ran into the same problem 2 weeks ago using the latest mandriva live-cd. That's why I think, that the troubles are caused by the kernel. Any ideas?

I am really not complaining, as 2.13 works find and is ok for me. Maybe I could help i.e. by testing fixes (although my Linux and English knowledge is (very) limited).

Thanks again for sharing your work with others.

Cheers from Austria (yes, without "la")


WOW, looks Great! Big thanks Barry and the rest of the kennel. Extra thanks to Rarsa, network wizard is very nice now. I used it today to connect to a WPA network, easy. Sata drive boots up pupmode 12 too. Fonts look real sharp.

Okay more on my DVD playing problem. I was able to duplicate on another pc although it would play at least one dvd it would not play others. On the dell Laptop if I switched to the xvesa driver the dvd's would play but too jerky to watch. The dell is a 2 month old model with a gig of ram so i don't think it is a horsepower issue.

Any one else seeing an issue on laptops?



Craig, Hi

about the remaster script issue...are you running on a machine with pure NTFS partitions (W/o VFAT at all). If so it is a known problem (check the forum for script updates...) or plug in a USB flash and it should work...

remaster worked great with the script off the forum.

2.14 looks great. Everything that I've tried so far works.
Cosmetic issue: xorgwizard's test screen doesn't show the tiled shark image but the dialog asks if the image is OK. A new user might look at the grey background and say no.

Marion (mari.koch<at>web.de) 
Where is the MTools-File Manger in 2.14 ?
I can't find him, so I work with 2.12.

It seemed that nobody was using MToolsFM, so I removed it.

Marion (mari.koch<at>web.de) 
That's hard. I like MtoolsFm because my camera only work with windows, but with the MtoolsFM I can copy them to Linux.

Marion, the two mount applications MUT and Pmount will mount any msdos of windows partitionand Rox can access them. MToolsFM is not needed.

However, if you want MToolsFM, what's the problem? It's a PET package, just use the PETget package manager and install it.

Marion (mari.koch<at>web.de) 
Hi Barry, you're great, thanks a lot. sometimes it is easier than it seems to be.
I don't know very good Puppy because I'm a beginner and a german. So in English it's a little bit difficult. But I try the MUT and it works. Fantastic.
Only my printer with usb doesn't work. Maybe you have an idea.
It's Epson DX 4050.
Thank you very much, Puppy is great.

nforce2 ethernet no module ):

puppy 2.14beta works fine

Late news before 2.14 release 

I have updated the instructions for Puppy Unleashed at:

I have about half a dozen Unleashed CD orders, but holding them until Puppy 2.14 is released. Please excuse the delay, but it is better than receiving 2.13 CD in the mail just after 2.14 release is announced!

Dougal has done some very good work improving the 'init', 'xorgwizard' and 'rc.d' scripts, but this will be helod over for consideration for inclusion in 2.15. Preliminary feedback is that Dougal's xorgwizard is very fast.

Rarsa: Network Wizard upgraded to 2.14.8.

I have uploaded Puppy 2.14 to ibiblio, however just after doing so have received many upgrades from Rarsa and Nathan. Network Wizard to 2.14.9, Grafburn to 0.9 (fixes a critical bug in 0.8), a couple of invalid menu entries. As well a couple of other things that can be postponed.
Well, okay, I'll rebuild the iso and reupload it tonight. So, although 2.14 is currently at ibiblio (and the mirrors!), just ignore it. -- in fact, I'll delete it now, which will take awhile to ripple through to the mirrors.

Don't mean to stress you Barry, but the boot option 'pfix=ram' doesn't work when booting from a USB stick - pup_save.2fs loads anyway.


please include bug fix for Chooselocale script that now works properly, thanks to Pakt.


Edit /usr/sbin/chooselocale as follows:

on line 197, change

if [ "$LOCSRC" = "download" ];then


if [ "$LOCSRC" = "zdrv" ];then

Or perhaps that should be (on line 197):
[pre]if [ "$LOCSRC" = "download" -o "$LOCSRC" = "zdrv" ];then[/pre]
I've already re-uploaded Puppy 2.14, so this fix and any others will have to be a service pack.

Eric (caneri) (ericmulcaster<at>gmail.com) 
just installed the newest 2.14. Rarsa...your new wireless with wpa support is a think of beauty THANKS....worked and saved first shot on my HP nx9420 with Intal pro nic(ipw3945 driver). The pet package manager seems very fast now... I'll keep trying to break this version a call back later. Again thanks to the puppy people!!

Barry Kauler 
Eric, check that you got the right iso file, as the first one I uploaded to ibiblio was there for a couple of hours, then got removed, then later on replaced. The ibiblio mirrors may have also temporarily had the wrong one.
Md5sum is:
5012d1fd6d9bb5907ea358ecfd865153 puppy-2.14-seamonkey-fulldrivers.iso

bug in connection tkpppoe after use pet install tkpppoe not starting

Improved recognition: SATA at bootup, 1920x1080 HDTV 

Kirk reported that booting from a live-CD then create the pup_save.2fs file on a SATA hard drive, at subsequent bootups Puppy runs in PUPMODE=13. This works, but is not so good unless the PC has lots of RAM, as PUPMODE 13 is intended for media with limited write capability such as Flash. Puppy should be running in PUPMODE 12, as it is if the pup_save.2fs file is in a IDE hard drive. Fixed.

Forum member 'thegoldenstrand' requested support for 1920x1080 monitor, which is a HDTV LCD panel. I have put this into the Xorg Wizard.

Forum member 'mternus' reported that when 1680x1050 resolution was chosen in the Xorg Wizard, the color depth got set to '1200' in /etc/X11/xorg.conf, whereas it should be '16' or '24'. I examined the code but cannot see why this would occur. Anyone else get this behaviour?

As I already reported for Pup 2.14ALPHA Xorg Wizard still display only two resolutions available for ATI SAPPHIRE RADEON 9200SE ATLANTIS 128 MB graphics card and Sony SDM-M51, LCD, 15" monitor:



That was not the case prior to Puppy 2.13.

Leon, there is a problem with your monitor. The 'ddcprobe' program probes your monitor and it returns only those resolutions. Or, it could be a problem with 'ddcprobe'. You could try this alternative monitor probe (these progs are in Puppy):
[pre]# get-edid | parse-edid[/pre]
...see if that returns more sensible resolutions.

More bugs fixed in PETget package manager 

There were some problems. One of them was I chose to delete two packages, but only one got removed, although both got turned "off" in livepackages.txt. The 'petget' script had a fundamental weakness in this area, and I have rewritten some of the code to handle it correctly. A couple of other small problems were also fixed.

that's so great
i cant really wait to try this new release!!!
if 2.14 will work on my laptops it will became the principal OS in my home!! at now 2.11 is the most used in my home :D

Hi Barry,

I found whilst running Petget Manager that if i chose to install a local package and clicked on it the entire menu disapeared!.I`m wondering if this is what has been fixed.


Firmware added for zd1211rw module 

Puppy 2.14BETA has the zd1211rw wireless kernel module, but lacked the firmware to make it go. I have now added the zd1211_firmware-1.3 files to the 'zdrv' file. When the zd1211rw module is first loaded, the firmware will be fetched from the 'zdrv' file and installed in /lib/firmware/zd1211/.

I'm testing WPA with hidden ssid with the zd1211rw using a USB GigaFast WF748-CUI adapter and the zd1211rw seems flaky. Sometimes it starts, sometimes it does not. Sometimes after I cannot connect the only solution is to do a cold boot.

Using the alternative "older" driver seems to work better, comes up every time.

I wonder if we can put both drivers in there. Clumsy, but then users will have two shots at getting it running.

Does the firmware Barry mentions work with both drivers?

There are so many Zydas variants it gets confusing.
To clarify: the older (community) driver was already included in Puppy 2.12 ... but only the "A" version, not the "B" version. Summary -

Community version = zd1211 & zd1211b
From http://zd1211.ath.cx/download/
The "B" version requires a simple modification to the Makefile.
These 2 modules do not require separate firmware.
The zd1211 (but not zd1211b) was compiled by Barry and included in Puppy 2.12.

"rw" (rewrite) version = zd1211rw
Included in kernel source from 2.6.18.
Requires ieee80211softmac module.
Requires separate firmware in /lib/firmware/zd1211
This driver supports both A and B versions of the Zydas chipset.

There is also a vendor version, upon which the community version is based.

I've frozen 2.14. It only has the zd1211rw driver, which is the way to go, if it can be made to work properly. If anyone needs the other zd1211 driver, I suppose it can be supplied separately.

Gxine playing avi files 

There is feedback that videos that played okay in 2.13 and earlier, do not in 2.14BETA. I found the reason. Xine-lib is compiled against FFmpeg library, but FFmpeg has recently recompiled. So, I recompiled Xine and an AVI that previously did not play at all, now does. However, I got that warning about libavcodev being miscompiled and possibly causing a crash (see last thread). It turns out to be due to the '--enable-small' option used to configure the latest compile of FFmpeg. Unfortunately, removing that option makes the FFmpeg libraries about 1MB bigger.

Things keep changing all the time, I'll never get 2.14 released.... perhaps I'll just leave in the original Gxine 0.5.9, Xine_lib 1.1.1 and FFmpeg-2005-10. Recompiling a library in isolation has repercussions.
Soon I plan to revisit T2 and recompile everything anyway.

Thank you.

PrairieDog (janitorofgod<at>yahoo.com) 
  Many Thanks Here too!

Barry Kauler 
Well, the problem is that FFmpeg was recompiled for a reason, to add extra features that are being used by other applets. If I fall back to using the old FFmpeg for v2.14, will those other applets still be functional?

I don't wish to confuse the issue too much, but I have experienced problems with Gxine which I believe may be related to ffmpeg.
Using XvMC video output, for example, with an nVidia graphics card results in strange colours, but XvMC output is OK with VIA Unichrome graphics cards.
And I have also experienced extreme picture contrast, but again, only with certain graphics cards, and certain video out options.

The reason I suspect these problems relate to ffmpeg is that I have compiled MPlayer and VideoLAN in recent times, and discovered that trying to compile them against a shared ffmpeg library fails.
In fact, the semi-official build instructions for VideoLAN actually advise to compile VLC with ffmpeg configured statically.

So I would venture a guess that Gxine might behave better if compiled with internal ffmpeg.
Of course, this would make Puppy larger.

Jason Pline 
What will fail will be support with no add ons in PBcdripper & Grafburn for wma & ogg support. If you still have that old source of ffmpeg try to re-compile it with --enable-libogg=system so we can at least have ogg support (since Puppy already has libogg). Shouldn't make it that much bigger. Obviously the newer versions of ffmpeg have support for many other formats so everyday it'll probably get a little bigger. I could really care less about the wma support but ogg would be nice to have.

Jason Pline 
I should've mentioned in PBcdripper it will first look for oggenc to use as an ogg encoder since it does a better job than ffmpeg (you get to choose a bitrate other than a quality setting). I compiled a version of oggenc with no flac support and it works with the standard libogg already in Puppy. It's pretty small and would be nice to have in the base iso. That is if you don't want to re-compile ffmpeg and don't want to break PBcdripper.


Too late! V2.14 was dragging on too long, so I did some final tests than released it -- up on ibiblio now. using the original FFmpeg 2005-11 as used in Pup 2.13.
If necessary, a little PET or DotPup can be applied to add whatever extra Pbcdripper and the others need.

wolfie (valko<at>yotov.biz) 
Hi All,

maybe it worths to have a look at http://www.videolan.org/vlc/

it supports all the codecs and it will be the perfect solution for playing multimedia.

Gxine media-playing improved 

Eddie Maddox reported a problem playing a video file, see previous post. The media files are here:

To play the RealPlayer or Windows videos requires the 'xine_extra_codecs' PET package. This is a problem that comes up again and again, so I have modified the wrapper script /usr/local/bin/gxineshell that is used to launch Gxine, so that if a codec file fails to load, a message will come up recommending to install the 'xine_extra_codecs' PET package.

However, the RealPlayer file ( extension .ram) played with video only, no sound, whereas before installing the extra codecs it played with sound only!!!

The Windows video file (extension .asx) was not recognised by SeaMonkey, so I added the mime-type 'video/x-ms-asf' to /etc/mime.types and /etc/mailcap -- now SeaMonkey offers to launch Gxine to play it.
But, although the extra codecs are installed I only got video, no sound. I found out that the sound is encoded in WMA format instead of MP3, and requires another audio decoding file, 'divxa32.acm'. I downloaded this file and added it to 'xine_extra_codecs' package.
Now the Windows .asx video plays with video and sound!

The modified /etc/mailcap & mime.types will be in the 2.14-final, and I'll upload the improved xine_extra_codecs PET package later today.
The RealPlayer .ram file lack of audio remains unsolved.

Barry Kauler 
Okay, I've uploaded the new 'xine_extra_codecs' PET package to Ibiblio, that has the 'divxa32.acm' WMA audio decoder in it.

Eddie Maddox (greatnessguru<at>gmail.com) 
Barry, Good job. Good News!

I used the "PET install" PETget Package Mgr to install that new 'xine_extra_codecs' PET package. Then I tried SeaMonkey on the NASA-TV Media Channel Windows feed, which didn't know yet about the MIME-type, as you know already. So I "Choosed" /usr/local/bin/gxine.

It Works! My box is really not up to the job (but I do have DSL-512), so it was intermittent, but both video and audio were there, in short snatches.

I Quit gxine and used SeaMonkey again, this time to pick the NASA-TV Media Channel RealPlayer feed (my preference).

It Works, Too! Both video and audio. I Quit SeaMonkey to save cycles and RAM, and set View>WindowSize to 200%. Not Too Bad!

It says: "NASA-TV - Media Channel (NASA Headquarters)
Real 320x240 Real Video 4.0 117 kBit/s
22 kHz 32kBit/s Cook"

Thanks much, Barry!


Couldn't xine extra codecs go into the zdrv sfs?


The extra codecs if not loading is a great idea - could something similar be offered with the flash 9 final? I think Flash 7 is in SeaMonkey? There is a dotpup of 9

Unfortunately some of those codecs/demuxers may have licensing/copyright issues where they couldn't be included with Puppy but I don't think it'd be a prob if a disclaimer pops up along with installing the extra codecs package.

Also, for 2.15 could try again to upgrade xine-lib, gxine, & xine plugin to the latest [i]together[/i].

Am I the only one that has a problem with 2.14beta playing avi's using gxine. I get audio but no video.


> Am I the only one that has a problem with 2.14beta playing avi's using gxine. I get audio but no video.
> Craig

Gxine won't play my AVI files too.
It plays sound but no picture:

Error from the xine engine
Error loading libray:

This worked in Puppy prior to version 2.14a without the need to install additional codecs.

Reports about this problem:

The Gxine situation is not satisfactory. I've been communicating with one of the Gxine developers, trying various patches to try to get v0.5.11 to work, but no go so far. The suggestion that I upgrade to the latest xine libs may be worth trying.
Other than that, go for something else? ...MPlayer? ...not for 2.14 though.

I wonder how well the other xine-based players work? There's XFMedia, Xine-ui, ...and more.
Actually, I did compile XFmedia awhile back, it's a PET pkg.

Jason Pline 
The thing with various video not working properly is that there's too many formats that have no standards. Just because you can play one avi file doesn't mean you'll be able to play another. They could be encoded differently with different audio. If you want to play everything you'll need to install all those extra codecs. For your videos that don't play you could go to the command line and see what the audio/video codecs are for the file. For example:

sh-3.00# ffmpeg -i test.wmv
FFmpeg version SVN-r7400, Copyright (c) 2000-2006 Fabrice Bellard, et al.
configuration: --prefix=/usr --libdir=/usr/lib --mandir=/usr/man --disabl e-debug --enable-mp3lame --enable-a52 --enable-gpl --enable-shared --enable- pp --enable-libogg --disable-decoder=alac --disable-decoder=tta --disable-de coder=wv --disable-encoder=flac --disable-decoder=flac --disable-audio-beos --enable-small --enable-pthreads
libavutil version: 49.1.0
libavcodec version: 51.28.0
libavformat version: 51.7.0
built on Jan 3 2007 13:14:09, gcc: 3.4.4
Compiler did not align stack variables. Libavcodec has been miscompiled
and may be very slow or crash. This is not a bug in libavcodec,
but in the compiler. Do not report crashes to FFmpeg developers.

Seems stream 1 codec frame rate differs from container frame rate: 1000.00 ( 1000/1) -> 29.97 (30000/1001)
Input #0, asf, from 'test.wmv':
Duration: 00:39:20.1, start: 5.000000, bitrate: 496 kb/s
Stream #0.0: Audio: wmav2, 48000 Hz, stereo, 96 kb/s
Stream #0.1: Video: wmv2, yuv420p, 320x240, 29.97 fps(r)
Must supply at least one output file


As you can see this file has wma audio and wmv video. If ffmpeg recognizes the audio and video you could always re-encode to a format that should play in gxine.

sh-3.00# ffmpeg -i test.wmv test.mpg

That will re-encode to mpeg. I know that's not the best solution but you're always going to run into these problems unless you have all codecs installed.

Eddie Maddox (greatnessguru<at>gmail.com) 
Tried NASA-TV Public Channel "Watch with Quicktime":

"Choosed" /usr/local/bin/gxine

"The xine engine failed to start.
No input plugin was found.
Maybe the file does not exist or cannot be
accessed, or there is an error in the URL."


Puppy version 2.14BETA available 

This is not for general release. It is for our band of Puppy testers only. Download from here: http://www.puppylinux.com/test/
http://distro.ibiblio.org/pub/linux/dis ... inux/test/
Release notes: http://www.puppylinux.com/download/release-2.14.htm

Some extra notes:
Plinej: Pbcdripper upgraded to v2.1.
Jesse: elspci upgraded to v0.0.6.
jb4x4: told me about a bug installing Slackware pkgs converted to PETs. Fixed.
I removed MToolsFM from the 'standard' live-CD. Who uses it?

well, i can't download it

i don't use MToolsFM, but i seem to remember some program(s) use it for something ... i think Syslinux might need mtools ... maybe gparted, maybe others

I can't upload it either. Using wget, it is saying it is trying to connect to "media-nf.puppylinux.com"

Also cannot download it. Site seems to be down for some reason. Will try later.

Most of the files at http://www.puppylinux.com/test/ are being redirected to http://media-nf.puppylinux.com/test/ which isn't even ready/setup for use. I've just sent Barry a PM about this, also.

I've submitted a ticket to my host, netfirms.com.

In the meantime, I'm uploading to another site, will let you know when the upload has completed.

MToolsFM is a GUI for MTools. I have left MTools in Puppy.

Barry Kauler 
Okay, download from here:

My download was corrupt, only got 33 MB saved, don't know if problem was my end will wait a while before retrying.

2.14beta is working just great!

Thanks, Barry and congratulations.


Downloaded fine on 2nd attempt and running smooth. Font sizes in Seamonkey looking good apart from fields where you type in data like this comment being a little small.

Barry Kauler 
The files that can be used to customise stuff like font sizes are userChrome.css and userContent.css, to be found in the /root/.mozilla/ ... chrome/ directory.
I didn't find out how to make this form edit box text bigger though. There must be some setting for it. Perhaps the knowledge we seek is somewhere here: http://www.mozilla.org/unix/customizing.html

I welcome some new icons. "ok.xpm" and "error.xpm" are both small (around 3k), but "info.xpm" is huge (8k). I've tuned it down to same size as the others.http://www.murga-linux.com/puppy/viewto

I forgot the question icon. It is now also fixed to 6-bits colordepth.

Runs really slick, but I'll have to give it more of a test drive and then report. There's at least one thing I'm really pleased with, the package manager has sped up considerably. Seamonkey is also much faster now, usable with my 533mhz whereas before it was just too sluggish to bear.

it seems impossible to download the devx_214.sfs. Could you upload
it to the same folder as the new puppy 2.14?

Thanks in advance.

Hi, Barry -

Testing Out 2.14 beta - Gxine is not working I think, I got audio but no video when playing a .avi file. Probably testing 0.5.10 broke it?

BTW - how is the PEDV1 parameter supposed to work? I tried to run with PDEV1=hda8, but it still tried to update my puppy 2.11 in hda5. Is it _not_ supposed to do this?


Bill St. Clair (billstclair<at>gmail.com) 


I couldn't get the devx to download either.

Haven't tried it yet.

2.14beta works great so far from CF card on eBox-3851 thin client(800MHz VIA CPU). Xorg 'via' module, 'snd_via82xx' sound module and 'via_rhine' network module all loaded automatically.

Nice work, Barry & Co

JIm (lyons<at>canada.com) 
Downloaded fine and runs nicely EXCEPT that I still can't print properly on my HP 1610. Just as before it strta off printing well but ends up as though the ink had ran out on the cartridge. The same item prints perfectly under windows. Otherwise 14 Beta seems to work well and looks good though I haven't tried every last program

Eddie Maddox (greatnessguru<at>gmail.com) 
2.14.BETA problem: NASA-TV video

From SeaMonkey:
+ NASA Home > Multimedia > NASA TV
Media Channel:
+ Watch with RealPlayer

Error from the xine engine
Error loading library: drv4.so.6.0

No video. Audio may work. Not sure.

Public Channel:
+ Listen with RealAudio
Works just Fine.

Thank you,

Hello Barry,

Are you sure you included elspci 0.06, as you mentioned in the release notes?
I think the old version 0.0.3 is still in Puppy 2.14 beta, because it hangs at the same spot as where Puppy 2.13 hangs. Also, if I run elspci from the prompt (without the -l option) its mesage says that it is version 0.0.3.


Jozjl, it says ver 0.0.6 for me:
sh-3.00# elspci
pci module loading help - compiled on Feb 1 2007. Version 0.0.6
Written by Jesse.Liley for PuppyLinux

MooDog, hmmm, no it's not supposed to do that. What are you booting off?

Jozjl, oh dear, I made a mistake. I put in the 0.0.6 elspci then forgot to build the new 'inird.gz'. It is in the main part of Puppy, hence the conflicting reports. If you do "chroot /initrd" then try "elspci" (if you have a running Puppy) then you will see it is only v0.0.3 in the initrd.
I'll fix that, upload it again a bit later today.

Here is a forum thread for reporting bugs:

USB hotplugging is still broken in 2.14B :(

Bill St. Clair (billstclair<at>gmail.com) 
Working for me in a Parallels VM on my iMac. Had to run the ALSA sound wizard to get sound to work. This was not necessary in 2.12.

Can you give a specific example of the problem?

Hi Barry,

I had similar problems to this post ...

Truly was the slowest download of Puppy ever.
But the dog ran out of the kennel so quickly that I
got left at the GATES.

Brian (spiffytech<at>gmail.com) 
When I upgraded from 2.13, the menu didn't display properly. It only had the Shutdown and Help menu. The only thing above that are the two seperators that go between sections.

Also, it would be nice to have the bootloader tell me the partition-selection flag.

When I tried to connect to my WPA network, the connection failed the first time. I looked at the settings again (changed nothing), and then it connected. However, the time it takes to connect and then to activate DHCP is really slow.

Brian C (spiffytech<at>gmail.com) 
I've had several bouts of application instability with the 2.14 beta.

1) Firefox has closed on me twice while I'm browsing my Gmail account. This did nothappen in 2.13

2) The Network Setup wizard will occasionally refuse to connect to an access point, but will connect when I try a moment later. Also, I tried to save a profile, and it kept flashing "saving" with a progress bar. I had to restart X

Brian C (spiffytech<at>gmail.com) 
More stuff (I'm sure you're getting tired of it; I'm just making sure the next Puppy grows up strong!)

1) When installing the Python interpreter, the PETget manager stayed at "checking dependancies" for ~30-60 seconds. That's a lot longer than the other steps, and seems like it should be short. I don't know if it's a rea problem, though.

2) The dialog for PETget progress is kinda annoying in the middle of the screen. It would be nice if I could put other windows on top of it, or if it defaulted to one of the screen edges.

3) The "Advanced" settings button under the JWM configuration just puts an entry in the taskbar saying "Sorry...", with no window or anything.

Brian C (spiffytech<at>gmail.com) 
OK, firefox is crashing a lot. It usually happens when I open/close a tab. I know FF isn't a part of Puppy 2.14, but this didn't happen in 2.13. Could a change to Puppy have broken FF?

Barry, Opera 9.10 (from the site) works fine as it did in 2.13 -- without the need to install qt! Thanks.

Barry: Just reported serious mouse and apps issues with 2.14beta upgrade to full install over on your own Forum. Seems OK on liveCD.

Various upgrades and fixes 

I'm not sure if previously mentioned, mtPaint upgraded to v3.10.

2.14BETA will have TkDiff to play with, replacing Gtkdiff. I'm not sure if it's that much better, but will evaluate.

Rarsa has upgraded the Network Wizard to v2.14.5.

John Doe provided a fix for the 'alsaconf' script to handle usb sound.

Plinej has upgraded Pbcdripper to v2.0.

Zigbert has developed 'Pfind' a new simple file finder, v0.5.

Plinej has upgraded Pupctorrent to v0.4.

I've partially ported the 'init' script to new code for scanning drives, but for the 2.14BETA this is only done for booting from USB Flash, IDE Flash, and IDE HD.
Dougal has done some major rewriting of the 'init' script also and has created an alternative and smaller 'initrd.gz' file. I'll have a look at that after the BETA is released.

jozjl (joz<at>lycos.nl) 

Are you also going to put the newer version of elspci in Puppy 2.14?
See: http://www.puppylinux.com/forum/?1168632391


Jaon Pline 
I just updated PBcdripper to 2.1. This version will allow you to tag your mp3 files. If you have faac installed you can rip and tag m4a files. If you have oggenc installed you can tag your ogg files. I think I'm done with it for the time being unless someone finds a problem or asks for another format or feature to be included.


Jason Pline 
I lied, I just updated PBcdripper to 2.2. This time I added tagging abilities to wma and added support for ape and shn as long as mac and shorten are installed.

Dang it all Jason! I just upgraded my Grafpup package about six hours ago. I even went in and changed all the icons. Now I have to do it all over again:RASPBERRY

In all seriousness good work, and thanks for it.

How about PDEV1=none
(and pfix=noramsfs)

Sorry I just posted to the wrong thread somehow. 

'init' boot script currently being rewritten 

Well, partly anyway. I was testing a "frugal" hard drive installation and there was a bug at bootup in one of the tests, Puppy got the partitions confused. I have been aware for sometime that the code in the 'init' script that scans the drives for the various components of Puppy is messy and needs to be re-done. Myself, Dougal, rarsa and others have patched it, but it really needed to be rewritten.
So, although it means delaying the 2.14BETA a bit, last night I got stuck into the rewrite. This time, I am attempting to make the drives scan much more thorough and systematic. So far, so good. It is implemented in parallel with the old scan code, meaning that both sets of code are in the 'init' script, so I can port to the new code gradually. I have ported the boot from USB Flash drive, and that works fine. Next I'll port the boot from frugal h.d. installation, to fix the problems with that. Then perhaps will leave it as a mix of old and new and release 2.14BETA.

While testing a USB Flash install, I discovered another bug, now fixed. For a msdos filesystem, the pup_save.2fs file got created as PUP_SAVE.2FS, which wasn't recognised at bootup. I think someone mentioned this capitalisation problem on the forum, but I think it was in relation to NTFS and I fixed that one awhile back.

From the user's point of view, 2.14BETA should work as before, except the boot from USB Flash and from frugal h.d. install should both work properly.

Thanks for looking at this, Barry. A related discussion is here:

I wonder if you have an advise about this matter to users of version 2.02. Many "office pro" builds have used that version.

Thanks and regards.

menno (menno<at>fwn.rug.nl) 
"this capitalisation problem"
Mount a vfat with '-o shortname=mixed' .

Hoppfully you can also have a look at the problem with the Iomega zipdrives as mentioned here:


Thanks in advance

I read through the zip forum thread, but not logged in there right now, so posting a question here:
donald_duck and cdevidal, can you also report the result of running the 'test-eide' program.

To possibly assist in 'future' and 'on-going' fault-finding/fixing with the "init" boot script - may I suggest that you 'sectionise' (if that is a word) the main script areas - e.g.. script for locating & mounting any 'vfat' (msdos) partitions/drives be in 'separate' section to script for 'ext2/3' or script for 'ntfs' ... etc.... Also script for locating & 'writing' to such drives as separate to other script ....

Just my 2 c's worth towards making such tasks as "fault-finding" hopefully easier for all concerned ..

I've added support for the 'PDEV1' boot parameter. For example:
PMEDIA=idehd PDEV1=hda1
It is preferred to leave the PMEDIA there, but PDEV1 can tell Puppy to search only a particular drive or partition. This can speed things up during booting, maybe also avoid finding components of Puppy on other drives and partitions.

Would that include sda1 ?!

can you also modify the init script to search and load aditional .sfs files (like winexxx.sfs or officexx.sfs ) from same partition where main pupxxx.sfs and zdrvxx.sfs files are located (in frugal hd install)? these should also work (search&load additional sfs) in case we don't have pup_save.2fs file (we haven't created yet or we have in place of pup_save.2fs file an complete ext2 or ext3 partition) That should be great.... thanks

I actually rewrote the init script a week ago. I didn't modify the way it scans partitions too much, but have modified quite a few things.
I was actually wondering about the problem with upper-case names -- thought it might be best to do for vfat, too.

You can find it in my modified initrd.gz: (only 810k)

Another thing to consider is, even for SDA devices when booting from the live CD, if it finds the pup_xxx.sfs and the zdrv_xxx on the Hard drive where the pup_save.2fs file is, use them to boot and to find drivers respectivelly.

That is the way it works on HDA devices and I don't see a reason why it shouldn't be the same for SDA.

Boot times are dramatically improved by just kickstarting from the CD and continuing from the HDD.

Now I know if Puppy finds more than one personal storage file in the same directory then it'll prompt to pick which one to use, but does it or will you have Puppy look at all of them on all the different media types or just stop when it finds the first location? Same question probably applies for .SFS files as well.

Hi Barry,

as requested here the result of 'test-eide':

/dev/hdc - cdrom - 4x4x32
/dev/hda - floppy - IOMEGA ZIP 250 ATAPI


How about PDEV1=none
(and pfix=noramsfs)

Network Wizard now has WPA support, Grafburn upgrade, SeaMonkey font sizes fix 

Rarsa has upgraded the Network Wizard to support the WPA Supplicant. The Unleashed packages are net_setup-2.14.4 and wpa_supplicant-

NathanF has upgraded Grafburn, his simple CD/DVD burner, to version 0.8.

I have been experimenting with setting font sizes in SeaMonkey.
The menu font was a bit too big, causing the Edit -> Preferences dialog window to be too big for a 800x600 screen. I fixed that by editing /root/.mozilla ... chrome/userChrome.css.
Text in the Mail and News module was to small. I created chrome/userContent.css and was able to fix that.

Note, if all goes well, Puppy 2.14BETA will be released in a couple of days.


For the Beta please use the network wizard 2.14-5

2.14-4 was purely a test version and I found a really bad bug with scanning that rendered scanning useless.

I am quite comfortable with 2.14-5 to be a candidate for release.


For some reason, the "Find Text As You Type /" is disabled in SeaMonkey,
at least I was not able to turn it on. It is in the Edit menu, but I was not able to
activate it.
Perhaps, it is some sort of an extension which should be included at the
time of compilation? I found these links:


but I could not understand how it is supposed to work

andrei, it seems to be an extension, that was not compiled-in. I can't do anything about it for now, but I've made a note of it. Probably will upgrade SeaMonkey in Pup 2.15 and will see if I can compile it in then.

I had a problem with cookies in Seamonkey (Puppy 2.13). I could not erase them.

I wonder if we have room for Pfind ... (10k)

Qtwvdialer, Firelog, Inotify Tools, removing invalid shared-library symlinks 

Qtwvdialer version 0.4.4 is now an Unleashed package. This is a GUI frontend for wvdial.

NoobieDoobieDo (Forum name!) has created Firelog firewall monitor, version 1.1. Quite intriguing, I've put it into the live-CD for us to play with. Note, the v1.1 script had a small bug with the path to load the results page in the web browser.

Inotify Tools is a couple of utilities to enable the inotify feature of the kernel to be used scripts. I have created a Unleashed package with the 'inotifywait' utility in it.

Jesse suggested that as Puppy does not have 'ldconfig', it would be a good idea to add some code to the version update script to check for invalid shared library symlinks. Done. This is in /etc/rc.d/rc.update.

Various improvements, bugfixes, applets 

Unfortunately there are too many issues with SeaMonkey 1.1, so I have rolled back to 1.0.6. The Mail and News module (Thunderbird) in 1.1 is the main problem, too many bugs.

As requested, I have added 1680x1050 and 1360x768 LCD screen resolutions to the Xorg Wizard.

Billcnz reported a bug in the PETget package manager. When the dialog window displayed to choose an alien package and the 'Cancel' button was pressed, it didn't quit. Fixed.

I compiled Gxine 0.5.10, the latest. Unfortunately it did a segmentation fault as soon as it started. So, still on 0.5.9.

I compiled Ctorrent version dnh2.2 and this is now an Unleashed package. I will put it into the 2.14BETA live-CD.

Plinej (Jason) has written a GUI for Ctorrent, called Pupctorrent. The version is 0.4. Looks good, I'll put that into the live-CD also.
Note, Jason has also developed a torrent tracked GUI app called Puptracker -- see the forum.

The 'new2dir' script in PET-Tools had some problems. I found, when using it to create directories of the Pupctorrent and Puptracker DotPup installed files, that some files and directories got missed out. In particular, new empty directories got ignored. Fixed.

Rarsa has added another improvement to the 'rc.network' boot script, suggested by PaulBx1. See previous post.

With a Firefox front end, the calls for Firefox in Puppy might be lessened - see here

From a subjective point of view I have found the Navigator part of Seamonkey in Alpha (still using it) to be more stable than previously. Any chance of using Sylpheed but keeping the upgrade to the latest Seamonkey?

Perhaps more controversially going right back to Dillo with mods or Hv3
both with links to more advanced browsers.

Another thing is the flash 9 final is available and I hope can be included in the Seamonkey route

Barry Kauler 
SeaMonkey 1.1 was a big upgrade, so bound to have some issues. Probably the next release will be improved, and will reconsider for Puppy 2.15.

Eddie Maddox (greatnessguru<at>gmail.com) 
> ..SeaMonkey 1.1, so I have rolled back to 1.0.6.

SeaMonkey 1.0.7 is the latest in the 1.0 lineage...


did you try running the new Gxine from gdb? The fragmentation error can be something as simple as an image missing -- which it'll tell you.

Gxine 0.5.9 is very buggy in Puppy 2.13. Have you tried to compile the newest version 0.5.11 ?

Talking about Seamonkey, I notice that on a slow cpu the puppy build of SM-1.1 is still very slow to load long web pages compared with the official binary or firefox, which seemed strange since it's using firefox's engine. For example times for loading this developers blog page on a pentium 2 400 MHz:
Seamonkey-1.1 puppy-2.14alpha build: 35 seconds
Seamonkey-1.1 official binary: 9 seconds
firefox-2.0 8 seconds

Note: for a fair comparison I remastered using the official binary so they were both running from the sfs.
I did another comparison on a computer with a fast cpu and the difference is much less noticeable (down to a couple of seconds).


What issues do you have with SeaMonkey 1.1? Have you actually checked there are filed bugs? Why not post a list of them?

Bug reports, and some followup discussion, were posted on the SeaMonkey developer's and user's forums.

Improved network detection at bootup 

Rarsa has tweaked the /etc/rc.d/rc.network script to fix some timeout problems when connecting to Internet via LAN. I have placed this updated script into Puppy. Forum thread:


I've uploaded an improed version based on your suggestions and PaulBx1's suggestion.

Now the script only waits the minimum it needs to wait.

I would like to throw in another suggestion. 'joki' posted this:

That is, we background rc.network and keep booting.

I'm wondering though, if we would have to wait for rc.network to finish at the end of rc.local0, as perhaps user code in rc.local, or the firewall, would want the network to be up (?)
-- or, could we just ignore whether rc.network has completed or not, continue on and start X?

Please don't just background it. At the moment once X starts I know everything is running and I can use it. It really irritates me that you can never quite tell when XP has finished booting with loads of important things starting after the desktop has been made visible.

Once the user interface is there it should be useable, very often the first thing I do after booting is start my browser.

That being said sometimes I'm hunkered over my machine waiting to play a local mp3, being able to CHOOSE to background the dhcp call during boot would be fine. In that case I'd know I was starting without full network support.


Kernel recompiled, Wireless Tools upgraded 

I added one more small patch to the kernel source, to export the '__d_path' function. This is used by the Dazuko security monitor device driver. This is in addition to the previous patches for Squashfs and correct VIA-chip shutdown.

I then recompiled the source with these changes, as modules:
1. Bluetooth support
2. Software MAC addon to ieee80211 stack
3. Wireless bcm43xx, zd1211rw drivers

I did not turn on SMP support, as the docs warn that the kernel may not work with some uniprocessor PCs. For SMP, I will have to do a separate compile of the kernel and offer that as an alternative for those who create their own Puppies.

I also compiled the Dazuko device driver. This is used by some virus scanner and intrusion detection software, and the source package has examples that show how someone can write their own software to use it.
I configured with '--mapfile=/usr/src/linux- --enable-syscalls --disable-local-dpath' -- the latter option means that the device driver will use the '__d_path' function exported from the kernel rather than its own inbuilt function, which apparently is required for an SMP kernel (the inbuilt __d_path function is unsafe with a SMP kernel).

I have upgraded Wireless Tools to version 29.pre10, as this has improved WPA support. From comments on the forum and sent to me, it seems WPA is the way to go.

"That's the way to go".

I started this week implementing WPA support on the network wizard. I've finished the interface and with great support from Tempestuous I'm finding my way around all the options for WPA.

Just yesterday I was able to connect to my home network using WPA.

After the problem loading the configuration at boot, WPA was the next most requested feature for the network wizard.

Rarsa's on a roll!

I can't wait to give that a try...

Thanks for the BT drivers. Hope that I or someone else succeed with openobex. I am longing for the beta!

Ted Dog 
Darn, I should have spoke-up on the last of a few DVB modules left out of the mix.

& check

This is for a popular North American linux-only HD card, pchdtv hd3000.

Just watched the Superbowl on my puppy basic machine

Barry Kauler 
Ted Dog,
It's a lot of work recompiling the kernel, as I also compiled all the extra modules (just in case there's a symbols problem with the previous modules), and I have to manually reconstruct the Unleashed kernel hierarchy in Unleashed.
But, I've written down your request and will include those DVB modules next time round.

Ted Dog 
I found the kernel compile easy but long process, the repackaging of the modprobe, & all the rest, finding disappearing firmware directory, etc was difficult. It also needs firmware and /DEV changes. I'll package up all changes and give you a link. I have a package of very small HDTV tools, but am debugging a very small video recorder software which should be a good match with puppy before I post a testing iso.

I've just uploaded a test version of the network wizard with WPA support:


Locale files now in "zdrv" module 

Leon suggested this. The applet 'Chooselocale' (script /usr/sbin/chooselocale) offers to download further locales from a PupGet repository on the Internet. The standard live-CD build only has 'en_US' and 'en_AU'.
I have modified the 'createpuppy' build script to include the locales in the 'zdrv_xxx.sfs' file, and I modified 'chooselocale' to recognise this. That is, if the "zdrv" file is present, 'chooselocale' will fetch the locales from there. If not, the fallback is the Internet download.

What is the point of doing this? For one, locale can now be chosen without having Internet access. Which means that we could have it as one of the questions asked at first bootup -- currently Puppy only asks about keyboard layout, but the correct locale setting is also required to truly internationalise our Puppy.

We do want to minimize the questions asked at first boot. Most things are autodetected, but there is a dialog window that asks keyboard layout (country of keyboard) and at least two windows for setting up the X server. To keep it at the minimum, I was wondering if the keyboard layout and locale could be combined into one simple dialog window? I don't know if this is too difficult or not ...for example, a user could choose "French Canadian" from the dialog and from that we assign an appropriate locale and a keyboard layout.

I am wondering if there is a simple way of finding the keyboard. For example my UK keyboard has a £ above the 3
there is also a euro sign around the 4 . . . Can a keyboard be pinged?

I was kinda hoping that you would bring back the questions at boot-up.
Actually it would be nice if alsa ran by itself and auto-magically setup any cards/chips found w/out need for user input.

Is it at all possible that when the keyboard layout/country is selected that it could auto-magically "insert" the locale chosen for the same keyboard ? I hope that made sense...

Keep up the great work !

Lob: A keyboard is just a simple signaling device - it has no [i]a priori[/i] knowledge of what is written on the keys; that is down to SW interpretation once you have instructed it which look-up table to use. Indeed, you can remap any key to do just about anything you wish - useful if one key fails on your favourite keyboard.
As for establishing the locale, even (!) 'doze needs to have this input during installation - hence the world map and timezone selection options. For live-CD s, other than in multisession mode, it will always be necessary to re-enter this info each time, so it is entirely appropriate, albeit irksome, that this should appear in the boot sequence.

You can combine the two, but there will be the occasional case where locale and keyboard are not the same. Perhaps the keyboard question can be used to select the *default* locale in the next question, rather than giving the user no choice.

In most cases, it is no burden whatever to answer a few questions on first boot, because Puppy is still WAY more easy to "install" than windows or a big distro. And it's not done every day. The only case I can see where this is not true, is when someone has to manage multiple machines and uses Puppy for maintenance when Windows is broken. In that case, can a remaster cause those those questions like locale to be already set?

A little more irritating is when booting into ram only, which is occasionally done by many people even if it's on the same computer one always uses. Perhaps Puppy can look for a file on the hard drive called "puplocale" for keyboard, locale and monitor information (maybe just "xvesa" for that), in the case of not using a pupsave?


When using "load to RAM" my main intention always is NOT to use the HDD, so going to the HDD to load something is self defeating.

In case of a ram-loaded puppy, you could add an option on the boot command-line like locale=en_US or keyboard=it_IT, because you anyway also have to write "puppy pfix=ram" and it wouldn't add to the number of questions during the boot.

When choosing Slovenian locale all this settings could be set at once:

Locale: sl-SI
Keyboard: Slovenian
Timezone: GMT+1

Barry Kauler 
On most PCs Puppy does automatically detect and setup sound. It's just the odd one, notably isa-bus types, that need manual intervantion.
Yes, that's what I want to do, the user just has one dialog window, chooses the country or whatever, and keyboard layout, locale and timezone all get automatically assigned.

Hmm, as most people have Windows installed on the PC, or another Linux distro, I wonder if we could just pick up the information, then be truly automated. We would need someone with deep Windows know-how to find out how do that!

Not sure that 'most people have Windows installed on the PC, or another Linux distro'. Most users I know are using a second, or more probably an n th. machine! It would inadvisable to tangle with Windows for any reason whatsoever on account of excessive bloat and an unusually poorly shoehorned assemblage of OBEs rather than a coherently written OS. To extract info from another Linux distro already present might prove more of an intellectual exercise than a useful procedure to avoid one or two keypresses?

I agree with Sage that Puppy should *not* assume Windows or another Linux distro is present. This is bound to lead to complications

The best idea so far is PaulBx1's: "Perhaps the keyboard question can be used to select the *default* locale in the next question, rather than giving the user no choice."


Berry, would you please include East Asian locales as well?
Thanks in advance.

"When using "load to RAM" my main intention always is NOT to use the HDD, so going to the HDD to load something is self defeating."

Yeah, I kinda guessed something like that would be true. Just thought I'd throw that out there though, to see if it would get knocked down.

I once took on a task at work to read/write the Windows registry. It was one of the most disgusting bits of work I've done, and frustrating as hell. Don't mess with Windows unless you are a masochist.

The more I think about it, on this ram boot question, the more I think the policy should be "leave well enough alone" and "don't concern yourself about a question or two". I mean, add the locale as a separate question, who cares? It's just not that difficult or irritating to deal with.

I only use puppy on my hd.. I don't see why it cannot check for an existant pupfile or hd install of puppy and use the defaults for that.

As for using windows, I believe puppy can make use of windows fonts if windows exist on hd & not many people seem to mind that..

So long as puppy does not make use of the bad/ugly stuff installed on a windows box I see no troubles.

It would be nice to have the possibility to switch from one keybord-layout to another with a mouseclick working with a text editor/control.

2.14ALPHA HD frugal install bugfix 

Running Puppy from live-CD is the most popular choice. Probably second is a frugal hard drive installation, in which you just copy the Puppy files (vmlinuz, initrd.gz, pup_214.sfs, zdrv_214.sfs) to a hard drive partition then configure LILO or GRUB to boot it.

However at bootup Puppy was unable to find one of the files. The guys found that they had to shuffle files around in different partitions to get Puppy to find them. This problem did not exist in Puppy 2.13. Actually, there was a bug in 2.13 kind of similar, and Dougal fixed it, but now we have a new bug. Anyway, Dougal has now fixed that too.

Forum thread:
http://www.murga-linux.com/puppy/viewto ... 4488#94488

Unionfs "bug" workaround and filesystem purge 

This follows on from the previous post. The 'init' script now detects if a new .sfs file has been added (not just devx_xxx.sfs) by seeing if its file attributes are '744'. If so, a scan is made for any '.wh.__dir_opaque' files that will block directories in the new lower layer.
The .sfs has its attributes changed to 766 so will not trigger the scan at future boots. But, if the partition containing the .sfs file is mounted read-only then the scan will happen at every boot (normally extra .sfs files are in the same place as the pup_save.2fs file and the partition is mounted read-write, so this problem won't occur).

I have also added a new boot parameter, "pfix=purge", which is like "pfix=clean" (the simulated version upgrade) but more radical. The intention of this "purge" is to fix a system that is broken in some way. A normal version upgrade will make sure all 'official' files override any user-created files, but only if the official files have a newer modify date -- the purge option will override regardless, meaning that you will loose some customisations, like the desktop layout.
The purge also forces a total scan of .sfs files for bogus Unionfs whiteout files.
Basically, the idea of "purge" is to give your Puppy a good bath, get him back to a pristine (and functional) state.

I like this purge idea; I had been wondering how to get back to a standard Puppy after miscellaneous mods such as we often try from the forum.

Does your purge save the "purged" files in /tmp like the upgrade process does? That would seem to be a good idea.

Also, this raises the question, what files can we modify and not have them get purged? For example, is rc.local still safe from a purge? I'd like a list of files that are "user territory"...

BTW it occurred to me, after suggesting using the devx file permissions for a flag, that there is a slight risk that someone might change the permissions manually and inadvertently start a purge. The use of permissions for a flag is non-standard after all. The risk is pretty small though. If the purged files are saved, maybe it doesn't matter.

TazOC (can PM TazOC on either forum) 
Puppy developers are the best! It just keeps getting better and Puppy is my favorite distro.
The unionfs issues have crossed my mind often but for now I am content with GuestToo's idea. This may seem drastic but here's the workaround I've used successfully since at least Nov19. I created a script based on GuestToo's 2006.10.15 post on PuppyForum. I execute it at the start of rc.shutdown every time:
#========= /etc/rc.d/rm_un_wh =================
echo -ne "Executing /etc/rc.d/rm_un_wh... (clean up pup_rw 'wh.*' whiteout files)"
usleep 300000
# the following is all on one line:
#find /initrd/pup_rw -noleaf -name '.wh.__dir_opaque' > /tmp/wh.txt
find /initrd/pup_rw -noleaf -name '.wh.*' > /tmp/wh.txt
WH_CNT=` expr 0 `
cat /tmp/wh.txt | while read J
echo -en "."
WH_CNT=` expr $WH_CNT + 1 `
echo rm -f \"$J\" &>/dev/null
[ -r "$J" ] && rm -f "$J" &>/dev/null
echo $WH_CNT "files cleaned."
#========== end rm_un_wh =======================
I first tried G2's original which only rm'd '.wh.__dir_opaque' files, but still noticed odd things not working, files missing, but were in the .sfs. I've used this clean 'em all approach in Puppy 2.02, 2.12, Muppy05, Muppy06, JWM, IceWM, KDE full desktop (xwin startkde) both with and without mupp212.sfs, KDE355mini_212.sfs, OpenOffice-204_212.sfs and both frugal installed CD boot and Grub mbr boot on two PCs, one heavily used everyday. Also set up a friends HP Vectra PIII-500/128MB with Muppy06, (and rm_un_wh) in Dec.
My reasoning is this: I'd rather have a few extra files reappear after being deleted--generally system files from the orig .sfs's, than to have missing files or folders that should be there! I've only had two minor problems that may be related to cleaning all '.wh.*' files at every reboot. First MU's my-roxapps/autostarter-MU runs scripts in the folder /root/autostart. When I deleted a couple of his entries, they of course reappeared and were executed on reboot. So I just modified them with comments so that they would no longer execute as I want, in effect modifying instead of removing the files.
AFAIK the only other problem is that the rm_un_wh script above echoes a '.' for every deletion, often a screen full or more if Puppy's been running several hours, but my attempt at displaying a count always displays "0 files cleaned"! I think it's a usage/syntax error, I'm not experienced with this kind of script. The only other gotcha I can think of is the decidedly remote chance that a user's/apps' file happened to be named '.wh.my-important-file'... which would get deleted and have to be restored from a backup pup_save file. But there's probably a way to prevent that, or not?
P.S. Sorry for the long-winded post. If anyone can point me in the right direction to fix the zero count bug in my script, thank you in advance.
-- John (TazOC)

JohnMc (john.mcginnis<at>comcast.net) 
In keeping with the Puppy theme maybe the purge ought to be called a 'Dip'. Like what the vets do to get rid of all the fleas... :)

Yeah, Puppy Dip, I like that. :-) I renamed the shutdown .wh.* scan on my PC pup_dip instead of rm_un_wh. I also fixed the counter, refined the scan to exclude /tmp, ~/autostart directories and log all changes to /var/log/union/pup_dip.log.

It appears unionfs prevents user creation of files that begin with .wh.<anything>. Creating files or folders in rox and/or command line fails with "Operation not permitted." So I'm more confident this dip won't hurt Puppy!

Unionfs "bug" 

Someone on the Puppy Forum reported that they added the "devx" module (devx_213.sfs) but some parts of it were "missing" (they ran the 'configure' script of a source package, which reported various components like gcc were missing). That is, some parts of the lower "devx" layer of the union weren't visible at the top.

Actually, it isn't a bug, it's a "feature".
Let me quote from Unionfs docs (Aufs has this same "feature"):
Namespace unification requires that there is a way to mark a directory "opaque" - meaning that lookup/readdir should not merge the objects of this directory with those of a directory of a lower priority. When one creates a new, empty directory using mkdir, the new directory should be empty according to POSIX/UNIX. To prevent contents of directories on lower priority branches from appearing in this newly created directory, the directory is made opaque.

I tried an experiment. Without the "devx" module present, I installed the "qt" library package, which goes into /usr/lib/qt. It also created /usr/lib/qt/.wh.__dir_opaque and /usr/lib/qt/lib/.wh.__dir_opaque (in the top layer, these files cannot be seen at the merged "/").
This means that when I later added the "devx" module, which is a new bottom layer in the union, all of the directories and files that it has inside /usr/lib/qt are missing.

Back at Puppy v2.11, I did implement a fix for this, as reported here:
http://www.puppylinux.com/blog/comments.ph ... 011-062015
However, this only operates on the pup_xxx.sfs layer (the guts of Puppy) upward and makes sure that all of the directories and files in pup_xxx.sfs are visible at the top.

What I did not think about at v2.11 was the "devx" module. We can't delete whiteout files while,the union is running, as that can screw things up mightily, it has to be done at bootup in the 'init' script before the union of the layers is created. So, at this stage it looks like I will have to modify the 'init' script to detect if the "devx" module is present and perform an analysis to clear out any higher level whiteout "opaque" files that might block its visibility.
Puppy v2.11 and later only do this whiteout cleanup at a version upgrade, or for the boot parameter "pfix=clean" (a simulated version upgrade) as it takes some time to do.
Unfortunately, this means that if you add the "devx" module to your Puppy system then you will have to do the "pfix=clean" -- unless I can get the 'init' script to detect that "devx" has just arrived and not there before, then do a forced cleanup.

This is a progress report, to let you know of the issue and that I'm onto it. Note, I think that those "opaque" files get generated in other circumstances also that are unnecessary, and that really is a bug.

I've witnessed this behavior too, and am hoping there will be a fix for more than just the official pup_XXX contents and the devx module, but for other modules also. I've created several addon modules now and experienced the glitch under various circumstances.

More severe, I had a bit of a lockup on my computer recently and when I rebooted the entire /usr/X11R7 directory was gone. It turned out to be this same problem, unionfs created a whiteout file there in the top layer. This was Puppy-2.14 so apparently under certain conditions the bug still occurs on the 'official' Puppy files and directories.

"...unless I can get the 'init' script to detect that "devx" has just arrived and not there before, then do a forced cleanup."

This is easy to do, assuming you can create a file somewhere at this stage of the boot. At the end of the detection process, create the flag file. At the beginning of the detection process, look for devx and this flag file. If devx is there but not the flag file, it is the first time and cleanup is required. If both are there, then cleanup has already been done. Of course the flag file would have to be revision-specific, just like the devx file.

The "flag" could be something else too, like a change in the permissions of devx.

You probably have figured something like this out already. It is a common sort of thing in hardware design, detecting leading edges of signals.

Not to throw a wrench into the works, but from Linux Magazine, March issue, refering to Knoppix 5.1.0 with kernel

"The unionfs file system has given way to the newer aufs, an entirely redesigned and reimplemented unionfs. This provides Knoppix 5.1.0 greater stability and performance."

Would aufs help the situation with Puppy?


In the Aufs docs it states that it has the same behaviour, creating a "opaque" whiteout file when a new directory is created. So Aufs will have the same problem that I had in my experiment with the "Qt" package.
Other conditions in which Unionfs creates unnecessary "opaque" files may have been fixed in Aufs though -- but I'm speculating.

Paul, no, I hadn't got that far. The idea of changing the attributes of a file is good.
Nathan, yes, I think I know how to do it so that it will cleanup all mounted .sfs layers.
I was going to code a solution last night, but went off on a tangent investgiating 'inotify' and other systems that can notify whenever a file or directory has been created/accessed/changed/opened/closed/renamed or whatever -- I was thinking of another way to solve the "opaque" whiteouts problem, but it didn't work out. So I'm back on "Plan A" today.

I suggested an advanced SFS file that automatically adds/removes menu items & desktop icons when the SFS file is added/removed.

The basis of it's functioning was to copy up to the Save file all the
dirs. in the SFS file except the /usr dir, NO WHITE OUT PROBLEMS !!!

Unless the white out happens to the SFS files /usr dir.

Upon removal, the copied files are deleted from a list in the SFS file.

Now I know Puppy-2 can't add/remove SFS files while running like Puppy-1 can, but very soon we hope that this'll be fixed, & it will be.

A fix I suggested for Puppy-2 swapping SFS files made 2 unions, one for
the Save file that's unioned on / that never swaps, & another union
for the /usr dirs. inside all the SFS files that're unioned on /usr.
So the loop devices & SFS file mount points are outside the /usr union.
This should allow UnionFS to swap SFS files reliably in Puppy-2, & it wouldn't change the file system structure so installs etc. fail.

Network Wizard and 'createpuppy' bugfixes 

A bug in the Network Wizard in Puppy 2.14ALPHA was reported here:

I'm not sure if I fixed the particular reported bug, but what I did find is that /etc/networkmodules was missing. This file is a list of all available network modules and is read by the Network Wizard.
So, where did it disappear to? ...rarsa had such a file in his Network Wizard package, however I had deleted that before creating 2.14ALPHA, as the file gets auto-generated when the live-CD is created. I then discovered the autogeneration of networkmodules did not work properly, so we ended up with no networkmodules file.

So, first thing. Rarsa, remove /etc/networkmodules from your package, as it is autogenerated.

Secondly, I fixed the autogeneration. I have posted the correct 'networkmodules' file at the above forum thread. Just download, gunzip and place at /etc.

In Puppy Unleashed, the 'createpuppy' script builds the live-CD iso file. This script now correctly creates /etc/networkmodules in the iso file, or more exactly in the pup_214.sfs file.
Then I looked further at the 'createpuppy' script and found a related bug -- the script offers a choice to create a basic set of drivers built-in to pup_214.sfs rather than have the complete set in a separate zdrv_214.sfs file. The "built-in" option is the same as Puppies before we had the "zdrv" file. Anyway, the "built-in" choice wasn't working, all the supposedly built-in modules weren't there in the final pup_214.sfs. The cause of this was the same reason the 'networkmodules' got left out. So, it's fixed.


The Network wizard package I provided does not include that file. I don't even have that file in my development folder. I've always considered it part of the base puppy, not part of the network wizard. I've provided a dotpup of the package, maybe someone else included that file when converting to a pupget.

Do you want me to start providing the updates as petgets?

Barry Kauler 
rarsa, apologies. I had an old 'networkmodules' file in the Unleashed package that I had created from your latest DotPup, and I used an older Unleashed Network Wzard package as the template and accidentally left the file in -- so, it is my error.

For Network Wizard updates, if you want to cater for current Puppy users then probably stick with DotPups. Probably when 2.14 is released then we can standardise on releasing new packages as PETs.

Package and menu management improvements 

Various incremental improvements:

The technique I am using for generating the menu from XDG specification files (including the .desktop files) uses a script called 'fixmenus' that is called by petget, rc.update and createpuppy scripts, that is, whenever the menu configuration file needs to be updated.
I have now created separate template files that 'fixmenus' reads. These are located at /etc/xdg/templates/ and look very much like the configuration files that rarsa developed earlier.
For example, /etc/xdg/templates/_root_.jwmrc is the template file for /root/.jwmrc, the configuration file for JWM. Now, if anyone wants to directly edit this file, edit the template file as the actual .jwmrc configuration file gets autogenerated -- it's pretty straightforward as the template file looks very close to the final product, and you can easily see the bits of it that are going to get modified.

So far I have it setup so the the menu configuration files for JWM, Fvwm95 and IceWM are autogenerated.

Nathan gave me some advice about how to speedup /usr/sbin/indexgen.sh, the script that autogenerates the master help index. I have made it faster plus added a few extra features. basically what happens with this script is that if a package is installed (or removed), if it has any help files they are automatically added to (or removed from) the main help index page (the Help icon on the desktop or in the menu).

Nathan also suggested that if someone clicks on a PET package from ROX-Filer, there should be an initial confirmation window, rather than just install the package. I've implemented a basic window, and intend to add some bells and whistles to it later.

This is very good news because I was quite worried - my carefully hand crafted .jwmrc I was so happy about had already been killed once by the new scripts (luckily I had a copy).


Updated PETget for 2.14ALPHA 

See this forum thread:

Please also read the recent posts on this News Blog about PETget.

More updates 

Rarsa: Network Wizard updated to version 2.14.3.

Rarsa: remotedesktopclient updated to version 0.3.

NathanF: Grafburn updated to version 0.7.

Plinej: Soxgui updated to version 0.5

Rarsa: Mouse Wizard modified with option to choose left-hand mouse.

PETget package manager improved 

I waved the magic wand and PETget is now very fast!
Actually, it was some simple lateral thinking. Most of the stuff that was causing a big delay is something that only needs to be done once, at a version update, not everytime PETget is run. So, I moved some code over to the version upgrade script /etc/rc.d/rc.update. Viola, on my 2GHz PC the "Please wait..." window flashes up for a fraction of a second only.

I want to do a bit more work on the script, and will upload the latest /usr/sbin/petget in a day or two.

Lobster reported that he used PETget to install some packages but they didn't appear in the menu. The reason for that is that I have not yet uploaded the new official PET (PupGet) packages to ibiblio.org, and most of the old ones don't have .desktop files.
I'll probably do that for the beta release.

before uploading official package,only if you have the time , please verify why 'linphone' doesn't start (it apears in 'network' menu), maybe missing the graphical interface? (console 'linphonec' is running)....thanks

Yes, I only compiled the commandline version of Linphone. The GUI version has a [i]lot[/i] more dependencies.
Hey, there's an interesting project, a light-weight GUI for Linphone!

Yeah, that does sound like an interesting project. I already created a small gui for Eznet, I bet Linphone wouldn't be much harder. BUt I think I have too many side projects already.

In going through pkgtool to make sure it will work with PETget I had a look at indexgen.sh. It does the job, thoroughly, but I'm wondering if it might not be better to find a way to add just the installed package's help rather than recreating the index completely from scratch. This is an awful lot of code to get through just to add one package. Probably not too noticeable on a fast box but it takes a good two and a half minutes on my older one.

Here's my suggestion. First make the middleindex file persistent rather than temporary. Next, use find while the package is decompressed inside /root/.packages, echo the results along with the description from packages.tx onto the middleindex file, and then use sort to alphabetize it. That way you're only processing one or two files rather than the entire /usr/share/doc directory.

Ah, yes. I created the changes I mentioned above and added the code to pkgtool. Adding the helpfile entries happens quite fast now. If you're at all intested the code is in the subversion repository in the puppy-scripts directory.

Barry Kauler 
Nathan, what's the full svn url again? I know you've posted it somewhere, but I'm sitting here sliding around in my chair in 40 degree-celsius humid heat (104 Fahrenheit) here and don't want to think about much.

Barry Kauler 
Nathan, indexgen.sh has something odd -- the 'sort' is not quite right. It sorts the entries alphabetically, however some entries are out of order and I cannot understand why.

I noticed the issue with sort when I was playing with the code a bit. The thing was, it seemd a bit erratic in howit did so, which makes it hard to track down which strings are causing the problem. I'll do a bit more debugging on pkgtool tomorrow and maybe I can figure something out, or come up with another idea.

To checkout pkgtool from svn:
svn co http://svn2.cvsdude.com/puppylinux/pupp

The entire Puppy svn repo can be viewed online to get a feel for how it's organized at http://svn2.cvsdude.com/wsvn/puppylinux/.

Most of the code in pkgtool is actually yours, just rearranged a bit and modified to work in the console and go a bit faster. The section relevant to the help index starts around line 155. For uninstalling and removing the lines I take the filenames out of $APKGNAME.files and do a 'cat /usr/share/doc/index.html | grep -v [helpfiles]', where helpfiles are the ones specific to that package. I didn't get around to looking at how you did it.

OK, I can't seem to sleep anyway so let me elaborate on the sort issue. This bit of code - 'sort --field-separator='>' --key=2,3 --unique' is returning the results alphabetized by fields 2 and 3, meaning after the <li> tag and the actual title of the link, so if a document's url starts alphabetically sooner it will show up first. Two things that could be done. The first is change to '--key=2" and only sort by the actual program name. The second would be to add a 'name=${ONENAME}' in before the 'href=\"${ONEPKG}' (where it's actually writing the entry), and just use 'sort --unique', which means it would alphabetize by name, be simpler, and give a tooltip on each link. You could also extend the 'name=' element with the package description if you like. I'll play with a couple variations.

Puppy version 2.14ALPHA uploaded 

This is not for general use. It is for Puppy-testers only.
Release Notes: http://www.puppylinux.com/download/release-2.14.htm
Download: http://www.puppylinux.com/test/

More notes:
WhoDo created the background image, but I took the liberty of lightening it way up, so as the retain black text under the icons.

Looking good Barry. 2.13 pup_save.2fs upgraded without a glitch so I didn't have to tweak my xorg and was online straight away. Upgraded apps (that I've tried so far) seem to be performing well too. One minor issue with SeaMonkey mail & news; the window for account settings is to big for my resolution 1024x768 and I can't drag it down as the title bar is off the screen.

lobster (ed.jason<at>gmail.com) 

updated promo to explore whilst downloading

Thanks Barry

Jim Lyons (lyons<at>canada.com) 
Finally my printer works BUT  after printing a quarter of a page perfectly the remainder comes out like the print cartridge was running dry.

I went back to Windows and printing was as normal.

So someting is still wrong but it's almost there. Jim

PS Prrinter is the HP 1610 which uses a USB connection, computer is an old AMD 500 MHz K2 with 500 MB RAM

alienjeff (alienjeff<at>charter.net) 
In the interest of consolidation, where's the "official" 2.14-alpha bug report location?

"We learn from history that we do not learn from history." - Georg Friedrich Wilhelm Hegel

Bill St. Clair (billstclair<at>gmail.com) 
Mirrored at:


MD5 checked after download, but I'm still downloading to my PC from S3, so I haven't checked that it got there OK. Never failed yet.

Anxious to get home and test it!

I didn't see an announcement in the forum.

Lobster may have been to excited using this new Alpha.

Barry, would you please include the missing modules needed for bluetooth in zdrv_214 and following? Like l2cap and rfcomm.

Okay, bugs and other feedback can be posted here:

Mail and News Prefs not fit in 1024x768 ...surely no, don't you mean 800x600?

Bluetooth; just those two, l2cap and rfcomm?

GParted is missing from the "System" menu. The fix is here:

Bill (bill.christiansen at gmail.com) 
>Mail and News Prefs not fit in 1024x768 ...surely no, don't you mean 800x600?

Edit -> Prefs is OK but Edit -> Mail & Newsgroups Account Settings window is sitting a bit high so I loose the top 1/3rd and can't drag it down.

Lobster has created another bug-reporting thread on the main forum:

alienjeff (alienjeff<at>charter.net) 
So much for consolidation. With all due respect, the more bug report locations there are, the higher the likelihood of reports falling between the cracks and bugs persisting version after version.

Bluetooth: Barry, up to now I encountered only those, rfcomm and l2cap, but might be that going on in researching, or for machines other than mine, different modules are needed. Perhaps, if not too heavy, you could include all BT-related modules. Otherwise, if too much space & time are necessary, please stick to those for now.

Puppy is running fast bringing many new features and some new bugs.

Bug report:

Jim Lyons (lyons<at>canada.com) 
More on printing in 14 alpha: My Hp600 (parallel port) printer works fine. My HP 1610 (USB) printer works fine on plain text but when printing a crossword from the Glasgow Herald it acts up as described above. I'll try some more tests when time permits.


More updating, fixes 

There was a missing file that caused printing not to work.
/usr/share/gutenprint/5.0.0/xml/dither-matrix-1x1.xml added.

G2: hacked Turma. Unleashed pkg turma-0.1.pup1

plinej: ffmpeg recompiled with more features. Unleashed pkg ffmpeg-2007-01-02.

plinej: Soxgui updated to v0.4. Unleashed pkg soxgui-0.4.

I'm making a lot of use of this:
# new2dir dotpuprox.sh `pwd`/name-of-dotpup
One convenient thing, hit TAB key while starting to type the name of the DotPup and the `pwd` evaluates immediately:
# new2dir dotpuprox.sh /mnt/hda1/root/sources/sources044/soxgui-04/Soxgui-0.4.pup

A note about the 'new2dir' script. I originally intended this to be used when installing a source package, and the script looks at the current directory and creates the target directory one-up or two-up. For example, you are inside 'abiword-2.5.6' and the target directory will be 'abiword-2.5.6-i486' on the same level as the 'abiword-2.5.6' directory.

In the case of the Soxgui DotPup shown above, I first created a directory 'soxgui-0.4' then copied 'Soxgui-0.4.pup' into it, then ran the above. The script is then happy, see the parent 'soxgui-0.4' directory and creates 'soxgui-0.4.i486' alongside it.

Extra note on Soxgui: the red ball (mini-record.xpm) is a good thing to have always available, so I have put it permanently into /usr/local/lib/X11/mini-icons. The directory already has a 16x16 orange ball ...hmm, we probably need a green ball to round it out.

Of course I'm working on lots of things not documented explicitly. For example, have greatly improved the 'new2dir' script.

Jason Pline 
I should have an 0.5 soxgui out hopefully by tomorrow adding several sox sound effects to a gui. I'm working on it now. Just wanted to let you know for inclusion in 2.14 final.

Jason Pline 
Well 0.5 didn't take me that long to do so here it is:


Great upgrades for our Puppy apps! 

I'm getting ready to upload Puppy 2.14ALPHA in a day or two. So, I've been going through my checklist -- so much wonderful stuff created by Puppy enthusiasts:

Rarsa: mini-volume taskbar applet upgraded to v0.4. The Unleashed package is mini_volume-0.4.

Rarsa: Network Wizard upgraded to version 2.14.1. The Unleashed package is net_setup-2.14.1.

NathanF: Grafburn CD/DVD burner is a newcomer, very exciting devlopment. Unleashed package is grafburn-0.6.

Plinej: PBcdripper audio CD song ripper upgraded to version 1.9. Unleashed package is pbcdripper-1.9.

Zigbert: PuppyBackup is under very intense development, everytime I go to the forum there's a new version! Upgrade to 1.0.0, Unleashed package is puppybackup-1.0.0.

MU: Applied a bugfix for Puppybackground. The Unleashed package is now puppybackground-2.1.3.

Rarsa: Remotedesktopclient RDP GUI upgraded to version 2.14.1.

I might be offline for 3 month, so I have something to play with.

I think I'll try to add localization-routines to some of your wizards meanwhile.
Also will try a Muppy008 based on your Alphaversion.

Keep up the good work going :)

lobster (ed.jason<at>gmail.com) 
Would recommend this front end to SOX

Good luck with the new job Mark

Jason Pline 
Thanks Lobster, I was going to mention Soxgui is now at 0.4 which has a couple of newer features.

Jason Pline 
Barry, I think I mentioned possibly upgrading the puppy ffmpeg package to a newer package I compiled which has wma & ogg support as well as some others and is about the same size as the current package in puppy. It's at:


That way the ogg and wma options in PBcdripper will work.

Great Barry,

There are a few more changes in place and planned for the remotedesktop client. I'll keep updating the code contributions post so you can take a newer version for the next alpha or beta.

I'll be wandering around other scripts to see which ones are in need of a face lift. I am starting to like tcl/tk a lot. I'm just now realizing it is a first class language.

MUT seems to want some attention, rarsa. Not sure whether Jesse has that underway? No-one else seems keen to mix it with tcl/tk.

I'd like to second the vote for the recompiled ffmpeg. Personally I think ogg support is quite important, and a lot of other people would appreciate wma support as well. The binary is just barely larger, not enough to make a difference overall.

It would also make things a little less complicated in Grafburn, as right now I have to detect the output type and use sox rather than ffmpeg for ogg output when creating an audio cd.

I'm flattered to see Grafburn on this list, BTW. That makes me want to do a bit more work on it. Maybe later today

Is an upgrade to the current versions of the major applications planned for this year? I have a particular interest in Gnumeric which is currently at v1.7.6 while Puppy is providing v1.6.3 (May 2006).

Barry, is encryption for the pup_save not going to happen this time too? I mean kirk's version which is ready to go I think. Is there something that needs to be improved with it first? Please let us know...

Grafburn is updated to version 0.7, and since this fixes a potentially nasty bug I'd highly recommend upgrading it.

'fixmenus' script is back 

I'm running Puppy with the new XDG menu system, works fine. One thing though, a couple of times ROX froze at startup, restarted X and it was okay. Is this some weird interaction with the dynamic menu generation performed by JWM? ...don't see why.

Anyway, I thought that I might redesign the menu generation and not generate the menu dynamically every time the window manager is started.
So, I wrote a new 'fixmenus' script that generates a complete window manager config file. It does this when building the live-CD (running createpuppy), when install or uninstall a package (running petget) and when doing a version upgrade (running rc.update).

The advantage of doing it this way is that the JWM .jwmrc config file is perfectly normal with all menu entries as before.
Perhaps there will be a noticeable speed improvement starting X on old hardware also.
'fixmenus' currently build the config files for JWM, Fvwm95 and IceWM.

I'll see if the ROX freeze happens again.

We need to look at the JWMConfig program. With the previous XDG config files that got dynamically generated every startup, JWMConfig messes up the config file. With the system I am now using, JWMConfig will probably work okay, but the <inlude> line it inserted will not persiste beyond the next run of 'fixmenus' -- so maybe get JWMConfig to insert a <include> line into .jwm/jwm-personal instead.

for Rox 1.x, the -o option turns compatibility mode on ... Rox 2.5 ignores the -o option, compatibility mode is turned on in the options gui

i noticed that the compatibility mode is turned off in Puppy 213 ... JWM and Icewm do not need CM to prevent each desktop icon from having a button on the taskbar, but i think Rox still works a little better with Rox when the compatibility mode is enabled

for example, when X first starts, Icewm 1.2.28 shows a phantom flashing taskbar button (from starting the pinboard) which disappears if you click it ... the phantom task bar button does not appear when compatibility mode is enabled

there are also winoptions for Icewm listed in Rox's help file ... using those options does change the behaviour ... i think i prefer just turning on compatibility mode

i don't know if this has anything to do with Rox freezing or not

Okay, I've turned on compatibility mode.

I've been using the XDG menus in 2.13 and haven't found the problems you describe.

Could it be something else?

SeaMonkey updated to version 1.1 

The release announcement at http://www.mozilla.org/projects/seamonkey/:
SeaMonkey 1.1 is now available. Powered by the same engine as Firefox 2 and the upcoming Thunderbird 2, SeaMonkey 1.1 includes numerous enhancements including more visible security indicators in the browser and enhanced phishing detection for e-mail, a new tagging system for e-mail that supersedes labels, support for multi-line tooltips in web pages, and previews images in tab tooltips. Other changes include inline spell checking in the browser, an updated version of ChatZilla, and a significantly improved startup script on Linux.

I compiled it without Chatzilla though, as we have Gaim.
Due to the enhanced spell-checking features, I decided to leave the US dictionary in the Unleashed package.

Barry Kauler 
Something is odd about the font sizing in this new SeaMonkey. Some text is rendering too small. The edit box when typing in this comment for example.
Edit -> Preferences, set the minimum font size to something bigger, like 14, makes no difference. Huh? Is this some issue with Firefox2 that SeaMonkey has now inherited?

I'm using Firefox right now, and the text size is normal, so it's not that.

Eddie Maddox (greatnessguru<at>gmail.com) 
SeaMonkey updated to version 1.1
Tuesday, January 23, 2007, 05:43 AM
Barry Kauler
Tuesday, January 23, 2007, 09:00 PM
mozilla . dev . apps . seamonkey
> PuppyOS: SeaMonkey updated to version 1.1

A reply to Barry's comment has already been posted there, too.


There are issues with font sizes in Firefox 2, but they seem to be settled in the official binaries. I would have to go in and look at what I did to fix it. The issues only seem to come up with a self compiled package, I think there's some preference they set that messes fonts up with the default source installation.

One of the big headaches, if you compile Firefox 2 from source using gtk2, it does not respect global settings for gtk2 in relation to things like toolbar fonts. If I set my gtk2 font size to 14 I expect all of my apps to obey, but no, Firefox 2 uses something ridiculously small like 9 point. Once again, this only comes up with a self compiled package, not the official binaries. Personally I think it's a way of harrassing packagers into using the official binaries, but I may just be paranoid....

I posted a couple of replies to the SeaMonkey developer forum.
There are more issues than just the font size.
I plan to release Puppy 2.14ALPHA in a day or two (for Puppy developers only!) and I'll go back to SeaMonkey 1.0.6 for now I think.

DejaVu font fix, help index auto generation 

I sent an email to the DejaVu email list, and a couple of the developers very kindly replied. The problem, as reported on the forum, is that on some websites some characters are rendering overlapped.
Denis Jacquerye explained as follows:
This is a feature in DejaVu that triggers a bug in Mozilla's browsers
when they are using Pango. It only occurs with fonts that have
ligatures and in justified text. Mozilla miscalculates the width of
the ligature, that's why the ff and fi have the following character
bumping into them.

We had the feature off as soon as we learned about the bug, but it has
been the case for months. We turned the feature back on recently
because this bug should be fixed at the right place. There are other
fonts out ther with ligatures that people use or need.

To prevent the bug from being triggered by the fonts, simply remove
the ligatures lines from the sfd files before generating the fonts.
Since only the ligatures ff, fi, fl, ffi and ffl are affected by the
bug, the following command will do:
perl -i -ne "print if not (m/.*'liga' f .*/)" *.sfd

Until the bug is fixed in Mozilla, the other option is to use another
font without ligatures like DejaVu 2.11.

The latest version of DejaVu is v2.13, and I intend to apply the fix to that with the above Perl script.

Puppy developers may know about a script /usr/sbin/fixmenus, that was used to update menus when a package was installed and uninstalled. This script became almost redundant with the move to XDG, however there was still the problem of the master help index, /usr/share/doc/index.html -- this is the page that displays when you click on the "help" icon on the desktop or in the menu.
The fixmenus script also added or removed entries from this help file when a package was installed or removed.

Now, fixmenus is totally removed, as I wrote another script, /usr/sbin/indexgen.sh, that dynamically generates the help index based on what is actually in /usr/share/doc.
The 'createpuppy' script in Unleashed runs 'indexgen.sh' to generate index.html when building the live-CD, and it can also be called from PETget when a package is installed or removed.

The advantage of the new dynamically generated help menu from the user's point of view is that it is always correct. It only has entries for help files that exist, unlike the previous system that had some dud links.

I'm curious about something here, will the new indexgen.sh script handle alien packages in any way? Whenever I create a package for Puppy I try to make sure there is a help file included, but without doing some heavy editing right now there is no way to have it added to the index. Using the 'man' command works, of course.

Barry Kauler 
Yes, indexgen.sh scans /usr/share/doc, so place a help file or subdirectory in there, or a symlink to help if it is elsewhere, and it will get detected. help files must end with .htm, .html or .txt.
The script will also get a description from the .desktop file, but only looks in /usr/share/applications.

If there is no .desktop file, I am just about to add another feature to the script, to search alienpackages.txt and packages.txt for a description.

Okay, I applied the Perl patch to DejaVu sfd source v2.13, installed FontForge, then ran 'generate.sh' to generate the .ttf files. Placed them in Puppy, yep, fixes the problem.

PET package preliminary documentation 

I have created some reading material for those who would like to know a bit more about PET. The pages are preliminary and will change.
http://www.puppylinux.com/development/pack ... gement.htm

Barry - good to see these docs updated ..

Suggestion - with the PetGet package manager - if one already has the latest Unleashed CD - if during the package selection step in the PetGet manager - a step be allowed for to source the 'wanted' extra packages from the Unleashed CD instead of downloading them from the net - this would add another easy 'install' method to the overall setup - would make things simpler for us puppyites who are only on 56K dialup ..

I know that one could probably install these 'wanted' extra packages from the unleashed CD by using MU's Dotpup-Wizard to convert them to Pups then install them that way - but if it could be incorporated into the PetGet manager - it would all be under one roof ..

very good, thanks for this great documentation :)

Looks good to me, glad to see the docs updated and I'm really looking forward to the updates.

craftybytes, the CD is a problem, as Unleashed is a big tarball -- but I think it is possible to extract one file without expanding the entire tarball. ...okay, I'll think about it.

I think you will find that for those of us who purchased the Unleashed CD - to use the unleashed 'remastering' - we would have had to expand the tarball first - then run the 'createpuppy' script ...

So - the tarball expansion step would already be done - thus to then use the 'expanded' tarball packages for future installation either by MU's Dotpup-Wizard or by a 'selection' via the new PetGet package manager (T.B.D.) - would be doable ..

ferikenagy (ferikenagy<at>yahoo.com) 
sounds very good these package improvements, I presume after 2.14 release will start an major movement to remake all dotpus...to remake sfs files (Wine.sfs,office.sfs,muppy.sfs....).I knew is an big pressure
to release it as soon as possible, but maybe it is now the time to analize the opportunity of replacing (or not) 'unionfs' with 'aufs'.I remember there were some issues in the past with unionfs (maybe they are solved with 2.13 ? ). People with deep knowledge and experience in this (unionfs/aufs) may offer their help to make an good decission, maybe those experimenting with the new Knoppix (january release is with aufs ).

Pages updated.

The only oversight I see right now is the title tag on the package creation page. It still currently reads 'How to create a PupGet package', when 'How to create a PET package' would be more appropriate at this point.

new2dir script improved 

Wow, it sure is nice!
I've added the ability to automatically split the package into 'development', 'documentation' and 'international' components.
For example, I compiled and installed the 'Dia' vector editor, and in the final install step:
# new2dir make install
the script now asks if I want to split the package, and any one or more of the above components can be split off. You could for example choose to just split off the 'development' component, which would be necessary if the package has shared libraries -- which Dia does. If I choose to split out all the components, I get four directories, 'dia-0.95-i486', 'dia_DEV-0.95-i486', 'dia_DOC-0.95-i486' and 'dia_NLS-0.95-i486'.
Having created one or more directories, it is then just a matter of running the 'dir2pet' script on each to convert them to PET packages.

Another thing that I have added to 'new2dir' is automatic stripping, in case the installation Makefile doesn't do it.

What we now have is a remarkably easy way to create PET packages from a source package. Well, the 'new2dir' creates directories that can also be used to create other package types, such as DotPup.

John Roberts 
Sure sounds great!!!

Barry, you know what is said of dogs: their age represents equivalent human years multiplied by seven. I am starting to think that the same applies for Puppy. The speed by which its usability and usefulness increases comparing with other distros seems to be times seven as well...I was enjoying my self yesterday browsing through the openSUSE wiki...and their best intentions about openSUSE mini... why don't they realize? better to adopt a Puppy


I'd also like to complement you on your development of Puppy Linux.

I've just tried a few more distro claiming to be aimed to varying degrees to the old PCs -- just in the last couple of days I tried BeaFanatIX 2006.2, ZenLive 4.2, DSL 3.2, and in the past I've tried larger distros like DSL-N RC4, Ubuntu, Kubuntu (for PPC, in fact destroyed an old free iMac with it), etc....

Only DSL comes close to Puppy; however, with a modern kernel, NTSF filesystem support, better desktop applications, etc., Puppy 2.13 is clearly the better choice. I must admit I think of something Bill Gates is reported to have said of Linux, i.e., Linux stands in the way of progress of a better operating system --- because valuable talent is being consumed by Linux. I think Bill must have been talking about you. I hope those of the Linux world that are consumed with hate for Microsoft will not be too offended by that statement, and by my statement that Windows XP is clearly better than any of the Linux distributions I've tried. But still, for being a free Operating System, Puppy 2.13 is clearly packs more punch per MB and per CPU cycle. I think I see greater things on the horizon with your take on package management issues, this could be a really big deal for your implementation of Linux.

Keep up the good work!

Wow that sounds great. I wish I had these scripts the last couple weeks, so I could automate the process of compiling the apps for Grafpup.

Well, I couldn't wait for it so I've created my own little version in the meantime, probably not as advanced but it copies all the installed files into a subdirectory of the source tree and cleans up after me. Even being that primitive it's a huge improvement over my old method of 'hunt for the files'.

PETget improved, new scripts new2dir, dir2pet 

I am continuing to work on /usr/sbin/petget, the PETget package manager. They are murky technical details, but basically the handling of PET package installation, espcially unofficial PETs, is improved. Also, the installation of PETs that were converted from DotPups may have some quirks in them that are dealt with.

I have already written a script called 'pup2pet' that does what the name suggests, but yesterday I had a flurry of activity and created 'new2dir' and 'dir2pet'.

/usr/bin/new2dir is a wrapper around the 'installwatch' program. You use this when you are installing any source package, like this:
# new2dir make install
and it will automatically create a directory with all the installed files. It is very easy to use, asks some simple questions, then explains exactly how to do the next step, using 'dir2pet'.

/usr/bin/dir2pet is a commandline script that will convert any directory into a PET package. For example, if the above new2dir operation created a directory called 'abiword-0.5.6-i486' then you just do this:
# dir2pet abiword-0.5.6-i486
and it will ask some simple questions and create a PET package, abiword-0.5.6-i486.pet.
If there is already a .desktop file no problem, but if there isn't one then it is (optionally) created.

Pizzasgood pointed out that one advantage of DotPups is that if it is a patch or bugfix it does not want to be registered with PETget as it is not a thing to be uninstalled. Well, PETs now support installing without registering to PETget -- when you run dir2pet or pup2pet, you are asked this question.

PETs no longer need a top-level 'keyword' or icon files, but there is a new specification file, for example 'abiword-0.5.6-i486.pet.specs'. This has some basic information used by PETget when installing the package. I will document all of this soon.

These are all exciting developments - package creation made very very easy.

Now, there is another need by lesser able mortals (that's me): how to watch files being added by PET so that at the end, the user can optionally create an sfs file of the added packages? (OK, based on the notes above, I could do a series of pet2dir [if there is such a utility], and in the end I can combine all of them into one working directory then create an sfs.)

Hope that makes sense.

Ya beat me to it Raffy ..

I too am interested in this idea of making an .sfs file of ALL the downloaded Dotpups or PETS that I currently have in a couple of folders on my hard drive (taking up space) - would be nice to be able to just load them from the .sfs file instead of 'downloading' them each time ..

Maybe an extra script could be written to treat this '.sfs' file as a "repository" for PUPS & PETS files - adding newly downloaded ones to it or even deleting unneaded ones via relevant buttons ..etc..

Every little bit to help us internet 56K dialup 'slowbies' (is it even a word) would be much appreciated ..

The XDG-ification of Puppy progresses 

Whew, that was a long hard slog, putting XDG '.desktop' files into every Unleashed package! (NathanF has done that with his Grafpup packages, so will know how long it takes).

The next release of Puppy will use XDG for the application menus. Usually these menus are managed by the window manager, such as JWM, Fvwm95 or IceWM (JWM is used in the official Puppy).
I have designed a new menu structure/layout, different from that in Puppy 2.13 and earlier, but similar. Our brains recognise patterns, and I wanted a menu layout which will be familiar and easy to locate the desired application for those who have used Puppy before. I also wanted to make some improvements.
The menu layout could be changed to something else, it is a matter of editing the window manager configuration file and changing the '.menu' files in /etc/xdg/menus.

Converting Puppy to XDG has far-reaching repercussions. The previous technique of directly modifying the window manager configuration file is no longer required, and this affects some major scripts. For example, the 'createpuppy' script in the Unleashed package, and the 'petget' and 'rc.update' scripts. Some mechanisms are no longer needed, for example the keyword and '.keyword' file used in Unleashed/PET packages.

This is a work-in-progress. I have converted the menus. Thanks to the brilliant little applications that Raul (rarsa) wrote, it is very easy to dynamically generate the menus every time the window manager is started. I have put all of this in place, and have now started work on fixing the various scripts, starting with my 'pup2pet' script.

Note for the Puppy user: what all of this XDG stuff is about is a greatly streamlined and simplified menu system. When you install a package, of whatever type, DotPup or PET, or even some other kind, or compile and install a source package, if it contains a '.desktop' definition file then Puppy will automatically create an entry in the menu with the appropriate text, icon and placement/category. Uninstall a package, and the entry will be gone.

alienjeff (alienjeff<at>charter.net) 
Curious how this "greatly streamlined and simplified menu system" and all its hidden mechanisms is going to affect the overall size of the distro.

Suffice to say, v2.14-beta should probably have a testing, bug reporting, and patching timeframe somewhat (or significantly) longer than the "Evelyn Wood" method currently employed. There are more than a few folks still waiting for bkup2cd bugs dating back to at least v1.08 be fixed.

Nathan Fisher 
>(NathanF has done that with his Grafpup packages, so will know how long it takes).

And how. Glad someone else shares my pain now. But seriously, I applaud the move, Barry.It was one of the best things I ever did for Grafpup, and I think it will be the same for Puppy.

>Curious how this "greatly streamlined and simplified menu system" and all its hidden mechanisms is going to affect the overall size of the distro.

This is minimal impact in size, really no more than about 60k (give or take) for the .desktop and .directory files plus the menu parser. This is a good thing, really. No need to worry that it will have a negative impact.

XDG It will just slightly affect the size. And btw, there are no hidden mechanisms.

I don't understand why you think that bugfixing will take longer.
I don't understand why all "those folks" are still waiting. One of them could have looked at the source and figured out how to fix it. Have you contacted the developer? (Sigmund).

If we talk about the network wizard, for example, people reported some bugs long time ago and I just got around to fix them. I wish someone would have been willing to have a look at the code and send the fix. It wasn't that difficult after all. It just took me 9 straight hours (I hadn't had free straight hours in a long time). Additionally, I was only able to focus on those bugs because some people were patient enough to bear with me when I was asking them to test,

Yes, there is no reason why the bugfixing will take any longer. There may not be any bugs, it should just work, even after I modify all the associated scripts -- the reason is, it is a significant step toward simplicity.
Regarding 'bkup2cd', that has been replaced by zigbert's "PuppyBackup' in v2.13.

alienjeff (alienjeff<at>charter.net) 

I believe you missed my point. I suggested a longer beta testing, reporting and patching timeframe; [b]not[/b] merely longer time for patching. An abbreviated testing timeframe doth not make for an accurate reporting and compilation of known bugs. Version numbers appended with "r1" attest to that.

We all have our own indidual talent kits. I'm not a coder, though have fiddled around here and there with config files and some scripts. Not being afraid to use the command line puts me in the "knows just enough to be dangerous" category. I've b0rked more than few things in my foolish vain attempts at emulating The Leet. Some quests have been successful; others not. Sometimes lessons have even been learned. heh.

Some of we less-than-guru-status Puppy types best serve the distro in the capacity of testing beta releases and reporting bugs. This is how we help out in our own small way: end user guinea pigs. We anxiously anticipate new Puppies being born, enthusiastically run them through their paces and report real (and sometimes imagined) problems to The Gurus. This is our active contribution. For some of us, this is the best we can do. And we love being a part of the process; as small and relatively insignificant as that part of the overall project may seem. It's what we do ...

So when a valuable utility like bkup2cd "just doesn't work" in v1.08, was reported so and remains unpatched through v2.12, we mere beta testing, end user guinea pigs just might start to squeal in dissatisfaction. When we offer the suggestion of a slightly less maniacal new release cycle, we are often condescendingly poo-pooed for not having respect for "the goals" or appreciation of "the experiment."

And no, I didn't contact Sigmund, whoever Sigmund may be. I opened bkup2cd.sh and noted "#(c) Copyright Barry Kauler 2004,2005 www.goosee.com/puppy" on line three of the script. The script calls up cdrecord, which I found was written by one Jorg Schilling. A casual search for "Sigmund" on Murga's forum reveals forum user "zigbert" frequently making obscure reference to a "Sigmund." Another notation in bkup2cd on line 156 says "#Note,some of this based on bkup2cd by r.f.smith 2001 gpl".

I'm apparently missing something that's obvious to others, Rarsa. Care to enlighten me?

Huh Huh, here I am  - Sigmund, or zigbert (forum name) if you like.

No I'm not the developer of Bkup2cd, But as Barry tells, the creator of PuppyBackup. PuppyBackup is at the moment close to a stable release. I will upload version 0.9.3 tomorrow at Murgas forum. If there are things that should have been fixed or added, - The time is right. After the stable version 1.0 , development will continue with development releases until version 2.0, and that will take a while. There are some new features that will take a lot of work. If you have ideas that needs playing with the 'backup-engine', I guess it's best to head those for PuppyBackup 2.0.

There always is this problem of prioritys.
Adding a XDG system can help to save time in future.
Just think of the time we spent to backup menustructures, write converters and such.
So this has higher priority than a single utility.

Same was with the step to Gtk 2.8, or the new Kernel.

This shall not excuse bugs, but explain why some are not fixed quickly.

I also think, we have a change in the way Puppy may be seen.
Each Puppy implements new techniques, adding new bugs of course.
Someone who prefers a system with higher stability, might prefer a "puplet", a system based on Puppy.
These are usually a bit more conversative, using older libraries/programs that proved stability.
E.g. I think Muppy007 still will be based on 2.12, as I want to wait for 2.14 as a base, with the new XDG-menus, and some more bugfixes reported for 2.13.


ted dog 
Good work puppy team! I have been lurking on other distros for a bit (new knoppix with aufs nice!, and myth) and there is left over cufft and unfixed bits on each. The only one that correctly got my wireless net & keyboard working [microsoft wireless combo no less] out of the box was the latest release was ...... Puppy2.13.
With added DVB support (for hd3000:ATSC decoder card) to this version and the responsiveness gained by running from RAM was better than I hoped. Viewing two subchannels at the same time could not be done on my hardware any other way but only with Puppy! There is only very minor changes needed to kernel dot config, /DEV and /lib/firmware to get this to work

alienjeff, I am in much the same situation as you. I am not a coder, can fiddle with scripts some, mostly contribute by testing, and troubleshooting as far as I can go. I too am used to much longer release cycles, much heavier and more thorough testing before releases.

But, Puppy is not mine nor yours. All we can do is suggest. If Barry et. al. don't take all my suggestions, no big deal. They are doing a great job, and for my needs there is no real alternative out there - any thing other than Puppy I try will take a huge investment of my time with little likelihood of being better than Puppy.

Another thing, Puppy is free. It is better than free, it is a gift of hours of hard work by Barry and friends. Remember the old saying, "Don't look a gift horse in the mouth"? That applies here. This is not a paid-for product, so it cannot have the same constraints as a paid-for product.

Just take it as it is. Like Mark says, if it is too hot and heavy for you, try one of the puplets. Be content; I am. :-)

Forget about backup2cd, it's history. It was neglected for ages, then zigbert came along and now we have a great new product, with rapid depvelopment.

One thing you must always remember, I'm bombarded with suggestions (including complaints) from all sides. It's not just forum posts, I get emails and p.m.s every day. I have to weave my way through it all, doing what I think is best for Puppy, and I know I'm not going to please everyone -- in fact, it would be bad for the project if I tried to.
Longer release cycles? That will probably happen sometime. Every release of Puppy is really a beta, but then so is every other distro I've ever tested. But, I anticipate we will reach a certain plateau sometime, where we can just work on fixing bugs ...maybe.

Maybe we should remember and respect that this is Barry's project and he can do whatever he likes with it. He doesn't owe us anything, we owe him.

amish (emailoption<at>supposedly.com) 
that goes without saying artie. we're here because we care about barry's effort. we never forget that it's his creation. barry likes to focus more on coding than on everything else, and that's his style.

we know. and yet we do a lot of volunteering, we admit that on the whole, puppy is great. i personally think it's by far the greatest distro i've ever seen. so if something goes wrong, it's my own opinion that we owe barry not merely praise (which we give him a lot of, as his is due) but in general, honesty and attention to detail. but i think jeff put it better. barry, we've been as patient as we can manage, and you've returned the favor once again. thanks.

Barry Kauler 
The "PET packages" web page now has an introduction to XDG and some links:

why not gimp 2.3.15 development??

DotPups, PETs and XDG-menus 

For the last few days I have been thinking about package management. MU and NathanF in particular have done excellent work in this area and I have been thinking how the evolving PET package format can build upon this, rather than do something different.

So, I thought why not absorb DotPups into PETs? Thinking along those lines, I wrote a little script, 'pup2pet', that converts a DotPup to PET by just embedding the .pup file inside a .pet file, along with one or two special specification files.
I modified PETget (the PET package manager) to recognise this and to install the .pup as it would normally be installed. Well, almost normally. I did not want the DotPup to modify window manager menus, and to limit what it installs into /root/.packages/.
I then did a test, converted a .pup to a .pet, then clicked on it and it installed. PETget does not let the .pup create a /root/.packages/pkgname.files as PETget has its own method of monitoring installed files and creates the .files file itself. PETget also creates a pkgname.keyword file and creates an entry in alienpackages.txt.

The advantage of converting a .pup to .pet and then install with PETget is that the appropriate files are modified and created in /root/.packages/ for any DotPup, including those that don't themselves register with PETget (previously known as PupGet).

Thinking some more about the 'pup2pet' script, I realised that I will have to tackle the menu problem. Some DotPups create an entry in a special area of the window manager menu, but this is very window-manager specific. Anyway, PETget disables this. This is another "advantage", as I am now looking at expanding the 'pup2pet' converter to include a 'pkgname.desktop' even for DotPups that previously didn't have it. So, menu entries can be inserted anywhere in the menu structure.

The guys who have done a lot of work on XDG are MU and rarsa, and also NathanF I think. But I have found Raul's (rarsa's) work with the xdg Unleashed packages to be superb. I'm checking them out right now.

I have created a forum thread for us developers to discuss this further:

I did not much on XDG, I used Rarsas packages, too.
What I did was to write some converters, e.g. for icewm ultra, when I did not achive the results I wanted.
But it is possible, that I simply did not understand the original method correctly.
My method also allowed me to use either XDG or .jwmrc by simply changing a value in a configurationfile.
But my approach is a bit messy (though it works fine), and I would not recommend it for Puppy.

I think an official implementation of XDG in Puppy based on Rarsas work would make things easier, I really was hoping this would happen soon.


Why reinvent the wheel with package management? Are there not any other options that have already been developed and refined .. perhaps the Arch linux 'pacman'? Or any of the other numerous options.

I think what Barry is trying to achieve is a more streamlined method for what you dub 'package management' that is "specific" to Puppy ...
Yes, there are already package managers specific to other Linux distro's but because of the 'start from scratch' design approach of Puppy, I doubt that any of these other 'package managers' would work as successfully (without possible major reworking) in Puppy as the PSI / Dotpup / Dotpet script sets designed specifically to solve Puppy's unique requirements ..

And remember - the early 'package managers' were very basic to start with but they did the job intended at the time - but as us puppyites got more demanding thru each successive version of Puppy - correspondingly these 'package managers' were improved to keep up with our expectations - and I suggest that all the other Linux distro's went thru exactly the same "design, try, & improve" phases as Barry and the other core Puppy members have done over the past couple of years since Puppy first came into the Linux fold ..

The present 'package managers' (Dotpup / Dotpet / Pupget / Petget / PSI) on installing a software package into Puppy perform a check for any clashes with already installed 'sub-packages' and ask whether to overwrite or not - BUT - what this check does not indicate is if any of the "found" sub-packages are of a version earlier, the same, or newer than the one in the package currently being installed ..

I raise this point because of the many Dotpup / Dotpet packages or even 'alien' packages that are available for possible installation into Puppy that are similar or the same but may have differing 'versions' - one good example is MU's - DotPup-Wizard-MU06 - which is now at version 12 - but - if one has downloaded it several times and still has each download saved for installing - how does the user know which package is at what version when he/she does an install - the 'package manager' only checks and informs on clashing sub-packages only BUT not as to whether the 'version' of such sub-packages are older, the same, or newer then the one being installed ..

Can cause some heartache when one finds that a package suddenly is not working as expected only to find AFTER a lot of backtracking that the 'installed' package is three or four versions older than the 'required' one he/she "thought" they were installing ..

Just my 2 cents worth ..

I totally disagree with using another distro's package manager. To put it quite simply, Puppy has had it's own package format since around 1.0, and the current version is just a minor evolution of it. Most of the other package managers are coded right around .deb or .rpm, with a few being coded around .tgz (as in Slackware). I'd prefer not to get mixed up in rpm hell, it might encourage people to mix and match in dangerous ways for one thing. It's a support nightmare. I like that Puppy has it's own smaller subset of packages, but you know that the ones in pupget/PETget will pretty much always work.

On my Fedora installation a lot of things "just break", so I end up building from source anyway. Which means I have a lot of unmanaged software on the box anyway. I've tried using the inluded rpm utilities to create my own rpm's, but frankly they suck.

It would be too confusing to go with .deb, because then people would assume binary compatibility with Debian, and that's just not the case.

And really, we're not reinventing the wheel here. Pupget has been around for a pretty long time now, and PETget is just an evolution of it (I know I'm restating things).

Towards XDG: YES PLEASE!!!!11!111!1!1111

As for the "inner dotpup", would it also work with Unleashed? Otherwise I can't see it being a good thing. It would make it harder to tell which packages work with both and which don't.

Satellite Internet now installed 

I'm posting from my new satellite Internet connection! The installer came yesterday and put a dish on the roof and a "ViaSat LinkStar S2" box inside. Connected to that is a "Belkin Wireless 802.11g Router".

The dish and ViaSat unit and installation are paid for by a government subsidy to enable remote rural regions in Australia to get broadband Internet access -- it is as much as 3000 Dollars Australian apparently. I paid for the Belkin unit -- 150 Aud.
I have to pay 39.99 Aud per month, which is the intro package, shaped (capped) to dialup speed if/when I exceed the monthly bandwidth allowance.

Find out more here: http://www.bbnet.com.au/

Note, my dialup account with Dodo Internet is prepaid until August this year, so I can still keep developing the Modem Wizard and compatibility with modem cards.

With all this new-found speed and efficiency can we now expect a new version of Puppy every week? ;-)

Dear Barry,
I hope you enjoy, the new boradband. I would like your opinion
about a new puppy feature:

Could it be possible for the user, after the first boot, to run
a script and extract some files from the pup_save.2fs into some
other directory which would then be burned in the CD?

To be more precise, I would like, when puppy boots, to load in
RAM only the necessary and most frequently used files/executables.
Other programs like all the painting/drawing, the files in the
devx_213.sfs, features of the window manager, Internet and
game utilities e.t.c. could be in some different folder and
when they are needed they could be run from the CD. Puppy
internally could hold a database of the executables that are
used per month or 2 months and how frequently those are used
and upon request it remasters the pup_save.2fs such that the
user loads into RAM only the the files he uses in everyday basis.

This way you achieve 2 things.
1) faster boot times because the pup_save.2fs will be
much smaller,

2) more free memory, for memory intensive applications.

What do you think?
Is it doable?

Wow!!! Hold on to your horses there mate!!!

In order to have a new Puppy every week we have either to clone Barry and all the friends of the devel team in quadruple  or alternatively - ALL OF US - lend a helping hand as much as possible (far preferable... ).

Excellent. I'm a WA expat now living in the UK and I know how hot an sunny it can get in the outback. Now you just need to hookup some solar cells to your roof to power your Puppy!

Archwndas: it could be done but you are talking about modifying Puppy to fit your own needs… different people consider different apps as "most important". Besides, Puppy is small enough as it is and boasts loading **everything** into ram.

What you want can be done in a way by remastering Puppy -- I posted a howto a couple of months ago on the forum.


> Archwndas: it could be done but you are talking about modifying
> Puppy to fit your own needs&#8230;

No, I suggested a script, similar to the remaster script. This
will allow the users to modify as they wish. Why should we waste
80MBs of RAM if we need only 20MBs? I think such a script would
boost the popularity of puppy.

> What you want can be done in a way by remastering Puppy -- I
> posted a howto a couple of months ago on the forum

could you please give me a link ...


I am very pleased for you Barry. I wonder if it will change Puppy. I am sure it will. The weekly (or even nightly) upload is not possible - I believe the upload is still done via modem with a satellite link of this sort?

A new pizzapup Beta has just been released - gonna try that. Also I can hear cogs whirring from other Puplet creative types . . . A new Qemu released recently. Such fun and 2007 has barely begun

archwndas: I was seeking something simpler here
Puppy would run slowly but the freed RAM might be more valuable than speed.

Barry, congratulations. I hope the price comes down. I hope you wont abandon us dial up types though after August. Do you have local call rate numbers that provide pay as you go internet access in Australia?

Congrats! You'll burn through that 500mb download limit in about 3 days, unfortunately.


Great start to 2007 for you Barry.

Shawn, true, but at least I have done away with the 3 or 4 local calls I make each day! Note, here in Australia we have 0198 numbers which are untimed local calls from anywhere in Australia, and that's how I dial Dodo.

I know what's going to happen though. I'll be wanting more bandwidth, and the next step up is 2G per month at 59.99 Aud (about 47 US dollars).

Lobster, no, the telephone landline is not used. Older satellite technology used that method, one-way download from satellite, upload via the analog modem and landline.
The new technology is direct two-way connection to the satellite (which truly is amazing).

Jonan T 
QUOTE "zygo ... Barry, congratulations. I hope the price comes down."

Huh? Getting a $3k taxpayer-funded satellite dish & hardware for FREE sounds like a good deal to me! What is wrong with $39/mth?

Doesn't seem fair to me. People living in remote country towns get the benefits of much lower property prices and other freebies like this. If I choose to live in the city then maybe I should get taxpayer-funded property subsidies?

Congrats barry .. Hopefully your internet access will improve - I know that you said it costs 39.99 Aud per month and you'll probably find that your usage rate will end up that you'll be back to the dial-up speeds most probably well before the end of each month - so - even though it costs a fair bit more - the next plan up @ 2GB rates will very quickly become more attractive as time goes by ...

However if the thought of forking out 59.99 Aud per month is a bit hard on the wallet, maybe all us Puppyites could make a small 'few dollars' a month donation that specifically goes towards meeting the costs for the 59.99 Aud plan - COME ON PUPPY PEOPLES - PLEASE help out with this ..

I know that there are several hundred or more Puppy users out there because the numbers who frequent the Puppy forums on a daily basis suggests that we have a substantial number of users - WHO COULD HELP OUT WITH THIS "DONATION" ...

Even if 60 of us donated 2.00 dollars each every couple of months that would be sufficient to cover Barry's internet access costs maybe for a few months if Barry himself was to also put say a quarter of the cost into the kitty each month - combining this with the 'donations' one could expect maybe 3 - 4 months of very usefull internet access - REMEMBER ALL YOU PUPPY USERS - without Barry & his very valuable work - WE WOULD NOT HAVE PUPPY LINUX ...

I'm willing to kick off this 'donation' drive by sending him 10.00 Aud as a starter - so who's willing to take up this help-out to Barry ..?

Ted Dog 
what is the upload limit? te hee.

Ted Dog 
satellite link speeds up to 81 Mbps on the outbound channel and up to 4.2 Mbps on the inbound channels to the hub. With this high inbound channel capacity, remote sites can be server locations, content providers


iDirect satellite internet http://www.highspeedsat.com/idirect3000.htm
vs. Linkstar S2 http://www.highspeedsat.com/linkstar-s2.htm

Which one is better? What are the benefits of iDirect vs. DVB S2?
Did you test a VoIP on your new satellite internet system?

Ted Dog 
I do not think he has a choice tasha, I like the DVB versions since you can also watch broadcast DVB on the same satellite for free, or the many unscrambled radio feeds, The linux version DVB ( not compiled in puppy linux kernel ) supports most setups.
I dropped my DVB internet but still can hear about 80 channels of music and the NASA channel DVB feed.

Mr Doolie 
Congrats, Barry.

A download cap? OUCH! I hope it's very large. I have broadband and my daily downloads have been as much as 8+ gigs/day (downloading Linux DVD images) but at least 100 meg/day.

I don't know about that upload capacity. I only get 64K up. Look at the BBNet satellite page:
...to get 128K upload speed I would have to pay 79.95 AUD (about 63 USD) per month!

Regarding VOIP, I checked out some forums discussing that, and the general opinion is that it isn't feasible due to the transmission delay of about 1.2 - 1.5 seconds.
What was recommended is to use these people:
...I registered for free and I get 300 minutes free calls per week to landline phones in about a couple of dozen different countries. I have made some long distance calls here in Australia, and it works great, but there is a very noticeable transmission delay due I think to their operation center being in Europe.

The way it works is you enter your phone number and the number that you want to call, in international format:
00 country-code area-code phone-number
They will then dial your landline phone, you answer, then they dial the other end. The reason it is free is very simple -- both ends are just receiving a call!
I have been making many calls and I haven't paid a cent.

SouthPaws (jaguar1<at>netzero.net) 
Hey Barry...Have you heard about these guys?


Congratulations Barry,
The world gets smaller each day and you've helped a lot with that.

I finally broke down and ordered some sat internet myself (should be installed in the next week or so. 512/down 128/up $55/month, no specifically threatened cap, but others have told me they (xplornet) are pretty good that way.

For Canadian bushdwellers like me, who are interested, equipment = $400, install = $ 250, system access fee ranges between free and $299 depending on if you take a 3 or 2 year contract or none at all. Higher speeds are available up to 2.0 Mbps @ $179/mo.

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