Barry Kauler is the creator and developer of Puppy Linux. At his official website, www.puppylinux.com, he maintains a blog of news and thoughts concerning the development of Puppy. This page tracks the latest activity there, but you can also subscribe to his RSS feed by clicking on the orange RSS icon below.
FireFTP, SQLiteManager, ZombieKeys
This is exciting stuff! Kirk sent me a pm with links to these addons for SeaMonkey. He told me about FireFTP and a couple of others, but when I looked on the web I found more, and SQLiteManager is particularly nice.
FireFTP and SQLiteManager, once installed, appear in the 'Tools' menu in SeaMonkey, and start in a new tab. But, they can also be made to start as standalone applications. They are also quite small.
The problem with FireFTP though is it does not work quite right when run standalone -- the version that kirk sent me runs except that the Account management menu doesn't, rendering it useless. So, I tested an older version of FireFTP (0.64.4-mod), and the Account management menu did work, but then the Preferences menu didn't -- weird.
SQLIteManager on the other hand, seems to work well standalone, but then I don't know anything about SQL. The menus seem functional anyway.
I have put these into Puppy, also ZombieKeys, which supports the Microsoft keyboard shortcuts for entering accented and other weird international characters when you only have an English keyboard. These shortcuts are mostly easy to remember, but I have also created /usr/share/doc/keyshortcuts.htm and a link to it in the main Help page.
Given the state of FireFTP, only really able to work fully as a tab inside SeaMonkey, I won't abandon gFTP yet. Puppy 4.1beta will have both.
Here is where we got the addons from, you don't have to wait until the next release of Puppy!:
http://xsidebar.mozdev.org/modifiedmisc.html
One way to install these, is just download a .xpi file, start SeaMonkey, select File -> Open, then just click the OK button each time you are asked a question. You will find FireFTP and SQLiteManager in the Tool menu. Note that FireFTP version 0.97.1-mod needs the xSidebar addon installed, but 0.96.4-mod does not.
The way you can run these apps standalone is quit SeaMonkey, open a terminal and type this:
...if you know something about SQL databases, try the latter, let me know if it is worthy for inclusion in Puppy -- it sure would fill a gap in our application suite!
Sound setup maybe fixed
Testing 4.1alpha6, prehistoric reported that has to run the ALSA Wizard at every boot. I think that is fixed. Also the volume control problem.
New theme for 4.1?
I wasn't going to bother, just have a different background -- maybe that guy on the bike. I did design a new 'Gradient-brown' GTK theme and 'Gradient-brown' JWM theme, that you will find in 4.1alpha6.
However, Lobster has suggested why not use those two Gradient-brown themes, with the 'Original' desktop icons (not in alpha6). I did also design 'Browndust' desktop icons, based on Stardust, but didn't think they looked nice -- they are available in alpha6 though.
So, what do you think about Lobster's suggestion? Of course, those who don't like brown themes won't like it.
Pixmaps, floppy icon fixed, keyboard trouble
Zigbert reported that the FPM and Gwhere pixmaps are not 16x16 in the menu. Fixed.
Linuxcbon reported that some icons are missing from the 'Chat' and 'Edit' menus in Ayttm. Fixed.
Flapdoodle reported that the desktop floppy icon changed to a hd icon. Fixed.
Keyboard trouble
smokey01 has reported that the ps/2 keyboard does not work on his PC. The kernel has the ps/2 driver builtin and it should work. Your HardInfo reports this:
When you boot from live-CD, does the keyboard work at the boot prompt? That is controlled by Syslinux, not Puppy. If not, you are in trouble. If yes, try "puppy loglevel=7" and watch for any error messages.
Another thing to try: Run PupScan, find out what one of the vendor:chip IDs is mostly likely concerned with the keyboard (or just run 'scanpci' in a terminal), then google to try and find out if there are any known issues with this glue-chip and recent Linux kernels.
Flash video
Zigbert recommended that .flv files need to have a file association so that Gxine will play them. At first I thought, no, Gxine cannot play a Flash Video, but this overview page has corrected me:
http://en.wikipedia.org/wiki/Flash_Video
Where to get some FLV files to play with? I found this:
http://www.mediacollege.com/adobe/flash/video/tutorial/example-flv.html
The required mime-type is 'video/x-flv', and I presume that zigbert has requested that this be setup so that Gxine plays when a .flv file is clicked on in ROX-Filer. But, if I try to open a .flv file in SeaMonkey, SeaMonkey does not know what to do with it either.
I got that mime-type after a bit of research on the Internet (also given in the wikipedia page), however ROX-Filer thinks the mime-type for .flv files is 'application/x-flash-video'.
To fix SeaMonkey (and Firefox and many other apps), I added entries to /etc/mailcap and /etc/mime.types (using video/x-flv mime-type).
To fix Rox, I created /root/Choices/MIME-types/application_x-flash-video.
Wallpaper Setter fixed
There was a bug report for 4.1alpha6 that Nathan's Wallpaper Setter does not work. I found the reason, the absence of 'fotox'. The image viewer is now named 'fotoxx'. I created a symlink, fotox to fotoxx, and that fixed the Wallpaper Setter.
Retirement, some thoughts
Timeline
Right now I'm going ahead full steam on 4.1, and will see that through to 4.1-final. if it turns out that we need another bug-fix release soon after, then I will definitely keep going to create 4.2. I may even feel motivated to do 4.2 anyway. Basically, I'm thinking of retirement at about the end of this year.
I have been offered work at the Perth Royal Show again this year, from 22nd September to 4th October, so will have much reduced input to the Puppy project in this interval. 4.1-final should be out before then, so there will be a lull anyway.
Not that I'm really going to retire of course -- I'm too darn enthused by Puppy, even after all these years. But, I'll be developing my puplet, at a slower pace and with less community interaction, just tinkering, doing my own thing.
There is one thing that I would like to see, that is the systems-level developer guys getting more direct control in what happens to Puppy. Up until now, everything gets channelled through me and I decided what's in and what's out, and I modify what others have done. There are those who have wanted more control so they forked their own projects, and Nathan's Grafpup and MU's Muppy are good examples -- those guys have a lot of initiative and also the dedication to create and manage their own distro.
But many other developer guys would prefer to remain part of the team. Besides, "Puppy Linux" is the distro that most people are drawn to, it has the name, the reputation, the widespread presence in the web and various publications. So staying and supporting the main Puppy Linux makes sense.
Guys we trust
I started to think of some of the core systems developers who I think should have more direct control of Puppy:
temptestuous
rerwin
kirk
Dougal
WhoDo
HairyWill
Raffy
UPDATE: John Murga
There are lots of other guys who are probably more on the application development side:
ttuuxx
economoney
disciple
plinej
zigbert
MU
pakt
...but some of those may also fall into the first category.
Those lists are not complete, just some names I thought of in about 5 minutes. They are guys who have been with us for some time so have proved themselves. We can trust them with the "keys" to Puppy. It's a starting point, more names can be suggested.
Of course there are some, like Raffy, who are probably more in the 'management' category rather than core-developer or application-developer.
Probably an SVN/CVS system, as has already been created for souceforge.org, would be what is needed for these guys to be able to have more direct control of Puppy.
This blog
One little implementation detail. I want to keep my blog going. This is primarily "Barry's blog" and will continue with news about my puplet and other stuff, perhaps some mainline Puppy Linux news too.
The problem with that though, is the URL, puppylinux.com/blog. If I change to another URL, that is going to break a lot of links, which I don't want to do. Perhaps if I give puppylinux.com domain to the puppylinux.org guys, they can put a redirect into puppylinux.com/blog to my new URL? -- can that be done in your Hostgator site?
These are just some thoughts. I have created a "Retirement" category in my blog, so that posts and comments can be viewed separately from the other "Puppy" and "General" categories.
Encrypted pup_save fixed
Forum member 'MattN' reported that 'heavy' encryption of the pup_save file does not work in 4.1alpha6.
Indeed it doesn't. It turns out that two kernel modules have had a name-change. aes.ko has become aes_generic.ko and blkcipher.ko has become crypto_blkcipher.ko. So, I have fixed it -- needed mods to 'init', 'rc.shutdown' and 'createpuppy' scripts.
Request for info: domain registrar
Anyone reading this who has a positive experience with a cheap domain name registrar that accepts PayPal?
I want to register another domain name, but my regular registrar, that I have been with for many years, has been gradually becoming too expensive. They want AU$19.95 per year for a .com domain (that's planetdomain.com.au).
I did a bit of a search and found this one:
http://www.cheapnames.com/
...very cheap.
Hotplug zip/ls120, /dev/hd* optical
I have now got nice hotplugging of the desktop icons. When I insert a LS120 or CD disc, the desktop icon appears. Eject it and the icon disappears.
For optical drives, this hotplugging was working, but only for /dev/sr* drives. I have now extended that support to /dev/hd* optical drives (the old IDE drivers, as used in the "conservative" kernel).
I found out how to detect if a LS120 diskette is inserted, but only when /proc/ide exists. That is, only when the old IDE driver is used, not the new PATA driver. I haven't tested on a Zip drive yet. This detection is only for internal IDE "floppy" drives.
Note, I can check /proc/partitions to see when a LS120/Zip inserted, but only if it has a partition. My test LS120 diskette is a "superfloppy", and my code examines /proc/ide//identify to detect an insertion or removal. However, the code can use /proc/partitions as a fallback for /dev/sd* LS120/Zip drives -- after all, nearly all Zip drives will have a partition.
LS120 support underway
I finally got around to installing a LS120 drive onto one of my PCs. I had the drive but no diskette, but otropogo kindly posted one to me.
The main problem, from the point of view of the desktop icons, is that insertion an removal of diskettes is not treated as a hotplug event by the kernel.
I had the same problem with the floppy drive, and could not find any fast/eficient code that would probe for an insterted diskette, without starting the motor. I think Jesse also tried to do this sometime ago. So I had to settle for keeping a floppy icon permanently on the desktop regardless whether a diskette is inserted or not.
It is more complicated for LS120 and Zip as these can have partitions, or could be super-floppies. So, we can't have a desktop icon named 'hdd4' for a zip drive before the diskette is actually inserted, as we don't know whether it is going to be 'hdd1', 'hdd4' or 'hdd' (superfloppy).
Right now I'm trying to find if there's any way to detect a LS120 or Zip disketter inserted, without starting the motor.
So, it's a work-in-progress...
Puppy 4.1alpha6 (406)
I had great difficulty uploading to ibiblio. gFTP crashed twice, the connection timed-out once, twice gFTP reported that the file upload was complete when in fact only part of the file was uploaded. Each time I selected to 'resume' and eventually got there. I downloaded the files afterward to confirm the md5sums. I have done this from my relative's high-speed ADSL2 connection.
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6/
Although mut has been fixed, there is still a bug in Pmount. You have to modify lines 55 and 56 of /usr/sbin/pmount to this:
There are two iso files, and I think most people can use the "normal" one, 'puppy-4.1alpha6-seamonkey.iso'. For anyone with shutdown or modem problems, try 'puppy-4.1alpha6-uniproc-ide-conservative-seamonkey.iso'. However, you do need to be extremely careful of "cross pollution". This pollution problem also exists if you have tested one of the earlier version '406' iso files that I released recently for crash-testing.
The cross pollution problem is that when you save a pup_save to hard drive, pup_406.sfs is also saved to hard drive. Later testing a variant of Puppy with the same '406' version number, Puppy will find the older pup_406.sfs file and use that. This has caught me out a couple of times tonight, so beware. Best if you boot with 'pfix=ram', and if you do want to use a pup_save, first look at the hard drive partitions to make sure there is no older pup_406.sfs.
You may also run into cross pollution with the pup_save file, if testing multiple variants with the same version number. Either create a fresh pup_save for each one, or boot with 'pfix=clean'.
I would like to determine if we really do need two completely separate builds. As has been discussed recently in this blog, it may turn out that something simple like disabling "tickless" in our normal kernel build will fix some modem problems ...I don't know, just guessing.
I have been asked recently, what are the main new features of 4.1 compared with 4.00? That has prompted me to put together a preliminary release announcement for 4.1:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6/release-4.1.htm
If you want to boot from a SCSI hard drive, see recent blog posts, also a link in the above release announcement page. You need one of these SCSI kernels:
http://puptrix.org/sources/kernel-2.6.25.15/scsi/
However, do note that the compatible set of modules are in the pup_406.sfs and initrd.gz of the "normal" live-CD, not in the "conservative" build.
Mut2, slmodem fixes
Jesse has tracked down the bug in mut and posted an update. Thread here:
http://www.murga-linux.com/puppy/viewtopic.php?t=32028
Rerwin posted various modem patches, including patches to /etc/init.d/slmodem in the Smartlink "firmware tarball". I reported in my previous post that I had to roll that script back, but it turns out that I did not implement rerwin's changes completetely. The problem was that rerwin posted the fixes here:
http://murga-linux.com/puppy/viewtopic.php?t=31931&start=90
but was not able to upload the firmware tarballs. I implemented the changes from the new slmodem script and the diff files, but did not examine the slmodem script closely enough to realise that two symlinks are required -- I have now put those in.
Today I was winding things up, to get 4.1alpha6 out. I have put in the above two fixes and will upload soon.
Conservative kernel, modem fixes
I have compiled the "conservative" kernel and all 3rd-party modules and put it into Unleashed. This is for experimenting. We have a problem with one or more modem drivers with our latest kernel, so we shall find out if the conservative kernel fixes them. It may just be the tickless option though, in which case could go back to one kernel, with SMP enabled and tickless disabled. Anyway, we will narrow the problem down.
Unfortunately the latest /etc/init.d/slmodem script failed to detect my on-board ALSA modem so /dev/modem did not get set. So, I rolled back to the script from alpha5, which works.
In 4.1alpha5 it was reported that the 'Stupid Mode' checkbox setting in PupDial could not be saved. Fixed.
Extra drivers compiled
Ok, I have compiled all of rerwin's extra drivers and put them into Puppy, with firmware where required.
Tonight I want to go through the entire exercise again, recompile the kernel and all 3rd-party drivers, this time with the "conservative" kernel.
Today I tested the Lucent modem on my Dad's laptop... not so good. Got strange error messages with the Martian driver. The Lucent ltserial module is blacklisted in 4.1alpha5, so I un-blacklisted and tested it -- great, Puppy was able to communicate with it (now at /dev/ttySLTM0) and get a init string, but when I chose to dialout, Puppy froze.
I wonder if the conservative kernel will fix that ...I think that rerwin indicated that might do it.
Extra drivers
Tempestuous has found extra drivers, that were compiled and tested in 4.1alpha5. Tempestuous has now collected the source packages together, with compile instructions, and I have uploaded them to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/new-drivers-Aug13-2008/
Note that I am planning to build a "conservative" alternative kernel for 4.1, see my previous blog post:
http://puppylinux.com/blog/?viewDetailed=00290
Trash
I have upgraded to disciple's latest improvement of the trashcan application, dated 9th August.
Pburn, Pmusic, Psip updated
These are Puppy in-house projects...
Pburn, CD/DVD burner app., upgraded to 1.9.8.
Pmusic audio player, upgraded to 0.2.0.
Psip VOIP + IM client, upgraded to 0.12.
Reckon I'll have a cup of coffee tonight and work late, try and knock this pup into shape and get alpha6 out. Tomorrow I'm going to my Dad's place to test Puppy on his PCs. One of his laptops (Thinkpad) has a Lucent modem and I want to find out what is going on with the Martian driver -- rerwin has reported some problems with it, that seem to be related to the kernel.
Mut has a showstopper bug, that Jesse is working on.
I'll plough through all the remaining bug reports for alpha5, maybe even fix some of them.
So, alpha6 is still another day or two away.
Ayttm updated
Siddhesh is continuing to rapidly improve Ayttm, our light-weight multi-protocol chat client alternative to Pidgin.
I have compiled the latest from CVS, version 0.5.0-72.
SCSI and IDE kernels
I have compiled the SCSI1, SCSI2, SCSI3 and IDE variants of the 2.6.25.15 kernel.
The "IDE" variant uses the older IDE drivers instead of the PATA drivers, and the device nodes are /dev/hd*.
All source files uploaded to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/
Modem fixes
Rerwin has tested 4.1alpha5 and applied some fixes for the modem scripts.
I changed the goal-posts with 4.1, removing auto-probing of serial modems, and rerwin has very patiently examined the latests scripts and tested on various modems, and devised new patches. In particular, a problem with the 'modemprobe' script has been solved.
Rerwin also has some patches for the 'init.d' scripts, but I have only partially applied these. A couple of things that I do not want to do -- automatic deletion of a devnode and of /dev/modem. I do not want boot scripts to delete /dev/modem under any circumstances. I would rather leave it up to PupDial to make any devnode and /dev/modem corrections. Basically, I want the setting to stay in-place regardless whether the modem is present or not, and any change has to be done by running PupDial.
ndiswrapper updated
Ndiswrapper enables Puppy to use MS Windows wireless drivers. I have upgraded to version 1.53. This includes a module for the 2.6.25.15 kernel and "userland" executables.
ntfs-3g updated
I have upgraded to version 1.2712. This has some important bug fixes. If you have trouble with Puppy using your NTFS partition, this may have fixed it. This will be in 4.1alpha6, due out in a few days.
2.6.25.15 kernel
I have patched and compiled this kernel, plus all the 3rd-party modules.
I did start off trying to compile the 2.6.26.2 kernel, however the lzma patch and one of Lloyd's Multitech patches failed. As dogone said, the temptation is to put one's hand into the lolly jar, but in this case I got stopped right at the start. I then decided to back off from the bleeding edge.
This kernel has the patches as before: loglevel, squashfs, unionfs, aufs, lzma and multitech-gprs (in total, 10 patches).
All source files uploaded to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/
I have not yet compiled the SCSI and IDE kernels. I first want to bring out 4.1alpha6 and make sure that the kernel is basically ok, then I will compile the other variants. Temptestuous also will have to recompile the extra modules that he created for the 2.6.25.11 kernel -- thanks for your patience on that, tempestuous.
nosmp, font size, slusb delay
I have added the "nosmp" boot parameter as default, into 'createpuppy' and 'puppyinstaller' scripts.
Kj reported that changing the global font size does not work. I just tried it, works fine for me.
Rerwin reported a problem with the /etc/init.d/slmodem script running before the 'slusb' module has properly loaded, I presume that is causing a failure of the 'slmodemd' daemon. Rerwin fixed it with a 'sleep 3' at the beginning of the script.
I don't have anything better at this stage. rc.network and rc.services both run as separate parallel processes launched from rc.sysinit. rc.network does have a method of waiting for network interfaces to become available, but I can't think how to do it for the modems. So, for now I have just applied the very gross fix of a 'sleep 3' at the beginning of rc.services. That does not slow down bootup speed at all, that is, the time taken for the desktop to appear.
I do have a thought how I might be able to apply a more accurate wait for the modem interfaces to become ready, but I'm not sure so will put that one on hold until sometime later.
Optical drive now released
4.1-testers reported that when upgrading from an earlier pup_save file, the CD/DVD drive remained mounted.
This is actually a bug from 4.00. When you boot Puppy from CD for the very first time, or boot with "pfix=ram", at shutdown you are asked if you want to copy the 'pup_xxx.sfs' file from CD to the same place as the pup_save file, and normally you would reply yes. Then at next bootup Puppy will find the pup_xxx.sfs file on the hard drive and use that.
However, when upgrading a pup_save, the CD has a later pup_xxx.sfs file, let's say 'pup_406.sfs' and this is only on the CD. If Puppy decides not to copy it to RAM then it is mounted from where it is, thus leaving the optical drive mounted.
I have fixed this. The 'init' script detects this situation and copies the pup_xxx.sfs to the same place as the pup_save, thus freeing up the optical drive.
Floppy desktop icon fixed
In 4.1alpha5, if you clicked on the floppy drive icon, it mounted okay, but if you then unmounted it, the icon stayed with the "green ball" indicating it to still be mounted. Fixed.
Wind generator tower, stage 2
Heh heh, here it is:
Put together from water pipe that I had lying around. Four pipes up to about halfway, then three pipes all the way up to 5.5 metres above ground. The turbine itself will be about 6.5 metres above ground.
The individual pipes are not strong, but they will be strapped together. I might use predrilled galvanised steel strap and tek screws. I might also put in guy wires to about halfway, just in case.
The wind generator kit has its own tower with hinged base and that will be used. The idea is, it will be hinged at just above the level of the shed roof, so I can assemble the wind generator on the roof, then rotate it up vertically! A pulley mounted on the top of the pipes will be used for winching. Alternatively, 3 or 4 blokes could probably lift it up. After it is vertical, some bolts can go through the pipes to lock it all together.
The basic idea is that it is serviceable. I can winch it down at any time, without having to hire a crane.
My original "stage 1" post:
http://puppylinux.com/blog/?viewDetailed=00070
Fotoxx upgraded
Fotoxx (previously called Fotox) upgraded to version 5.0.1. Among other things, it now has a full-screen slide-show mode. Fotoxx no longer has a PDF User Manual, it is now HTML and uses 'xdg-open' to find the most appropriate viewer.
Have created /usr/local/bin/xdg-open as a symlink to /usr/local/bin/defaulthandler.
New source repo for Puppy
Forum member cb88 is to be congratulated on this initiative:
http://murga-linux.com/puppy/viewtopic.php?t=32215
Mountain bike electric conversion
I am thinking of transferring the electrics from my electric bike to my new mountain bike -- a very interesting project, I reckon!
The electric bike is an el-cheapo from Kmart, AU$399, that I purchased about a year ago. In Australia, a power-assisted bicycle can be a maximum of 200 watts. Same in the UK. The European Union has settled on 250 watts.
The motor on my bike has a "200 watt" sticker on it, but I think it's the same one as the top pics at this site:
http://www.users.bigpond.com/solarbbq/cheapdiybike.htm
(the motor with the ribbing around the circumference)
That does 250 watts. I have read that the Chinese manufacturer just puts the appropriate sticker on it as per the target Government legislation requirements.
Anyway, what has intrigued me about that above url is the option of mounting the motor at the other end, that is, onto one of the sprockets at the human-driven-pedals-end. On my electric bike, the motor is mounted beside the rear wheel, with a small chain driving the real wheel, on the opposite side to the derailleur gears. Moving the motor to the front is an interesting alternative, but note the author's negative comments near the bottom of the page.
'nosmp' boot parameter
Well, we have lobbed the ball back into Lobster's court. Lobster, can you grab a 4.1alpha5 live-CD and boot it with 'puppy nosmp pfix=ram' -- if that runs stable then we have the best solution.
Next: choose a kernel
Lobster has reported the non-SMP kernel works, so unless he gives an update that it crashed a bit later, it looks like we will have to stay with the uniprocessor kernel for Puppy. The problem is, I can't just provide an alternative SMP kernel, as all the modules have to be recompiled also -- so I would have to provide two ISO live-CD files to cater for both groups.
For now I am tending toward staying with the 2.6.25.x series, but the 2.6.26.x sure looks interesting:
http://kernelnewbies.org/LinuxChanges
Special test Puppy for Lobster
Here it is, the file is 'puppy-406-unicpu-crashtestonly.iso':
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6-temp/
This is not for general testing, has a few things missing. Lobster, start it with the usual 'puppy pfix=ram'.
SMP kernel the problem?
I suddenly had a thought. Perhaps the lockup problem experienced by Lobster and one or two other testers is due to the SMP kernel. The 2.6.21.7 kernel in 4.00 is configured as a "uniprocessor kernel", it is only when I went up to the 2.6.23 and later that I configured for multiprocessor (SMP) kernel.
Note that the reason I was somewhat slow to move up to a SMP kernel is that the docs supplied with the kernel source state that it may not work on all uniprocessor systems. Perhaps Lobster is one of those unlucky ones.
So, I have compiled a 2.6.25.14 uniprocessor kernel, but found that none of the previous modules work -- too much of a fundamental change to the kernel architecture. So rigt now I'm recompiling the modules.
So Lobster, if you will be so kind as to help out yet again, I'll upload another Puppy soon, with the uniprocessor kernel, and you can find out if that locks up.
2.6.26.x
The latest 2.6.25.15 and 2.6.26.2 were released at the same time, and their changelogs are identical. So, it looks like bug fixes are getting applied to both. Even so, the 2.6.26.x series has architectural differences from the 2.6.25.x series and should be considered as less mature. But then, some Puppy-enthusiasts are keen on the new OLPC support in 2.6.26.x.
We shall see, firstly, let's find out if the SMP-enabled kernel is the cause of our troubles.
My new bike
I'm going green! Just bought myself a bike. No, staring at that guy-on-the-bike in the Aussie Outback did not have a subliminal affect on me, the interest was there from before. Here's my new bike:
I own an electric bicycle, purchased from K-Mart, but I never ride it. The main reason is that I find it to be very uncomfortable -- I have a degenerated back, the lowest vertebra easily gets out of position and pinches the nerves -- then I'm in trouble. The road outside my place is gravel, unpaved, and a normal bike is just too hard on my back.
So, for sometime I reckoned what I need is a dual-suspension mountain bike, but they are too expensive. Then yesterday -- now don't laugh -- I happened to be in Toys-R-Us and found a boys 24-inch dual-suspension mountain bike, for just AU$69.99, discounted from AU$169.99. Yay, that's in my price bracket! So I bought it.
It's a delight to ride on the gravel roads here, except for the hard saddle. No problem that it's a "boys" bike, as the seat and handlebars are fully adjustable to suit my height. Besides, I prefer the slightly smaller wheels as it just fits inside my car.
I looked online at what's available in wide comfy saddles -- some of them cost more than my bike!
Man oh man, this thing has 18-speed gears! All I need is slow, medium, fast. Anyone reading this who is into bicycles? -- is it easy to modify/simplify the gears?
Guy on a bike
For you guys who read this blog and haven't tested 4.1alpha5 and are wondering about our reference to the "guy on a bike", it's the background image used in alpha5, and here it is:
This is somewhere in the vast Australian Outback, I don't know specifically where, nor do I know who the person is. Ted Dog suggested it is Gilligan.
2.6.25.14 crash test
Ok, I have patched and compiled the 2.6.25.14 kernel and built Puppy with it. The only third-party drivers included are squashfs, unionfs and aufs.
The purpose of this built is to do a crash-test. Those people who have tested an earlier 4.1 alpha and it locked up, please give this one a go. Two or three people I think, are in this category, who were testing 4.1alpha5. For example, Lobster.
I have set this build to version number '406', as I think some earlier testing is giving inaccurate results due to conflicts with earlier builds. For example, you tested '405' (4.1alpah5) with the normal PATA kernel, then later the variant with the "IDE kernel", it is possible that either the previous pup_save or the pup_405.sfs may have interfered -- as the pup_405.sfs may have got copied to hd when the pup_save was created.
Upping the version number fixes the problem of Puppy finding and using an old pup_406.sfs, but still, be sure to boot with 'puppy pfix=ram' so as not to use an old pup_save file.
Anyway guys, if you are in the "it crashes" category, kindly give this one a go. If still no good, I do have one more card up my sleeve, and will build another kernel -- I'll try the .config file from one of the othe distros, such as Slackware.
Get the 2.6.25.14 crash-test Puppy from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6-temp/
2.6.25.14 kernel
2.6.21.7
Last night I recompiled the 2.6.21.7 kernel, had to do that to enable the new PCMCIA mechanism. Most of the old modules still work, just had to substitute the newly-compiled PCMCIA-bridge modules (like yenta_socket). Also had to compile the 1.0.16 ALSA drivers, as the 2.6.21.7 kernel had the 1.0.14 drivers. Also needed the squashfs 3.3 module, as the original patched kernel source has a 3.2 patch.
But, testing it, there is some kind of incompatibility. Plugging and unplugging a PCMCIA card did not generate any hotplug uevents.
So, that one is on hold.
4.1alpha5 feedback
I have just read through all the bug reports, to get an overall impression of the major problems. There is a problem with locking up -- for example, Lobster reporting the USB mouse and the system freezing after a few minutes.
Curious, that time variability, so I did some reading of changelogs...
2.6.25.12-14
Now that is interesting -- the changelog for 2.6.25.12 fixes a USB-related bug that causes "random lockups", due to shared interrupts conflicting. This is only on some hardware.
I am quite surprised (and alarmed) at how rapidly the updates are appearing for the 2.6.25.x series. The latest is 2.6.25.14.
It is Tuesday 8.55am right now. I am away from home, will drive home this afternoon and this evening build a new kernel, using 2.6.25.14 -- unless there is yet another release in the meantime!
I will build Puppy with that and you guys with crashing/lockup problem can try it out. I will do it quickly, so it will not have all the 3rd party drivers.
2.6.21.7 kernel for 4.1
Feedback so far on the 2.6.25.11 "IDE kernel" doesn't show any particular advantage.
However, there is no reason why I can't release 4.1 with the 2.6.21.7 kernel, same as used in 4.00.
Will have to release two flavours, the main one will have the 2.6.25.11 kernel, and for people who experience trouble with that can use the alternative build with 2.6.21.7 kernel.
Not very satisfactory is it? The amount of time that we spend trying to fix things because of the changing kernel.... stop Barry, don't get going on that!
"IDE kernel"
Some people testing 4.1alpha5 have reported bootup/instability/shutdown problems. I want to find out if any of this is related to the PATA drivers. Lobster for example, reports that it hangs after a few minutes use -- I don't see how that is anything to do with the hard drive driver, but you never know.
So, if Puppy 4.00 worked for you but 4.1alpha has this kind of problem, try this new build with "IDE kernel" -- this has the older IDE drivers instead of the PATA drivers. Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha5/
It is named 'puppy-4.0.5-ide_kernel.iso'
Conversely, if 4.1alpha1 did work for you, we should find out if this IDE kernel does too. Otherwise, we might solve someone's problem but create one for someone else.
If you have tested alpha5 already, it would be best to boot this new one with 'pfix=ram' to avoid any conflict, or if you have a pup_save file then boot with 'pfix=clean' to simulate a version upgrade.
Testing Xfprot
There was a report that clicking the close-box prior to downloading the F-prot antivirus signature package, it went ahead anyway. Fixed.
There was another report, from otropogo, that after downloading, it did not work:
http://murga-linux.com/puppy/viewtopic.php?t=32076
Fixed that too.
xine-lib
As ffmpeg has been upgraded, it is wise also to upgrade xine. I will get onto upgrading the apps that are dependent on xine-lib, but for now, have just upgraded xine-lib, to version 1.1.14. Here are my notes:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --with-external-ffmpeg --disable-dxr3 --disable-glu --disable-gnomevfs --disable-samba --enable-antialiasing --without-xcb --without-sdl --without-imagemagick --with-freetype --with-fontconfig --without-esound --without-jack --with-libflac
had to copy postprocess.h and avcodec.h from src pkg to /usr/include/...
# make
# new2dir make install
Note, Puppy 4.00 achieved the best-yet video and audio support, but I thought why not go just a bit better? So, the aim of 4.1 will be a new peak of audio/video performance built-in, nothing to add.
faac, faad, x264, xvidcore, ffmpeg
I have been inspired by plinej, who has recently been through this exercise. Earlier, there have been requests to support faac, faad, x264 and xvidcore codecs, so here it is -- these are all dependencies of ffmpeg.
For the record, here are my compile notes:
faac-1.26
----------------------
# ./bootstrap
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
# new2dir make install
faad2-2.6.1
-------------
# ./bootstrap
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
# new2dir make install
yasm-0.7.1
--------------
x264 needs this to compile.
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --build=i486-t2-linux-gnu --disable-python --disable-debug
# make
# new2dir make install
x264-20080731-2245
---------------------------
tricky, installs to /usr/local, have edited 'configure', changed prefix='/usr'
# ./configure --enable-gtk --enable-shared --host=i486-t2-linux-gnu
# make
# new2dir make install
...note, the executables got linked statically with the libx264 library, so have removed them from the PET package, just kept the shared lib as that is what ffmpeg needs.
xvidcore-1.1.3
------------------
# cd build/generic
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
need some trickery...
# cd ..
# ln -s generic xvidcore-1.1.3
# cd xvidcore-1.1.3
# new2dir make install
now we have all the dependencies....
ffmpeg-20080731
----------------------
problem, needs a utility called 'pr' -- I got it out of coreutils, put permanently into Puppy.
problem, busybox 'od' utility, missing option '-A' -- coreutils again, permanently into Puppy.
# ./configure --prefix=/usr --cpu=i486 --enable-libmp3lame --enable-liba52 --enable-libxvid --enable-libx264 --enable-libfaac --enable-libfaad --enable-pthreads --enable-small --enable-libvorbis --enable-gpl --enable-shared --disable-static --enable-swscale --enable-postproc --disable-debug
# make
# new2dir make install
Retirement pre-announcement
From the Puppy project, that is. I have been thinking about this for sometime, it is just a question of when.
I had previously hinted that I would do so early in 2010, however I will probably bring that forward.
Reasons for retiring earlier
One of them is that I would like to move to developing an application, in particular I am interested in porting my EVE vector editor to Linux, running with one of the native GUI libraries such as GTK.
Also, I would like to do other things. The Puppy Project takes up all my time, I don't even have a part-time job anymore so income is too low. I intend to do some regular part-time work and make more time for other activities that I keep postponing.
Being "Commander in Chief" of the Puppy Project is something that I have never been comfortable with.
Implementation
I will register another domain name for my site, and most likely hand over puppylinux.com for the guys who currently run puppylinux.org to also manage. I say "most likely" because this is undecided.
I will keep playing with a Puppy-derivative, with a different name. This will not be designed to work with a huge range of hardware necessarily, it will just be something that I tinker with sometimes. It will have a different name.
I may even focus on a niche derivative that runs optimised on one of the baby laptops, as some other Puppy-enthusiasts are doing.
I will probably turn over the keys to the ibiblio.org download site. I do not yet know who will get that responsibility.
Timeline
I am not going to suddenly pull out. That is why I am posting this advance notice, so that everyone knows it is is going to happen. Also, it is an opportunity if someone wants to advise me how best to streamline the transition (preferably by forum PM).
I certainly intend to keep going full-steam on version 4.1. It is shaping up well.
I will give a ball-park retirement date probably in a month or two.
IDE kernel
I have recompiled the 2.6.25.11 kernel with support for /proc/ide and /dev/hd* drives. Using it right now.
To reiterate the background on this, the 2.6 kernel has new drivers called PATA drivers for the IDE internal drives in a PC. The main difference from the older IDE drivers is that they use a SCSI-emulation layer and all drive device nodes are /dev/sd* for hard drives, /dev/sr* for optical drives. This is identical naming to other drives that use the SCSI-emulation layer, USB and SATA, as well as real SCSI drives.
The old notion of distinguishing IDE drives by their /dev/hd* device node name is gone, but then it is nice that all optical drives have the same /dev/sr* naming.
Anyway, I thought that the PATA support in the 2.6.25.11 kernel had matured enough and finally we could use it. The Puppy 4.1 alpha series has used this new PATA system, and it seems fine on all the PCs that I have tested on. However, some Puppy-testers do have some mysterious problems, such as Lobster reporting Puppy seizing up after a few minutes on one PC. Also some shutdown issues. Now, it could be that these are due to something else in this new kernel, but we need to go through a process of elimination.
Hence, I have recompiled the kernel with PATA drivers tuned off and the old IDE drivers turned on. In both cases these drivers are built-in to the kernel, not modules, and testing the "IDE kernel" so far all the old modules still work -- in other words, all the current modules and those compiled by tempestuous and anyone else for the 2.6.25.11 kernel should still work.
I am going to upload Puppy 4.1alpha5-with-IDE-kernel tomorrow, and would appreciate if everyone who has tested earlier 4.1's could also give this one a spin. I think everyone should be in this -- after all, if Lobster finds that it fixes his PC, but someone else who previously had no trouble suddenly finds trouble with the IDE kernel, then it's a case of one step forward and one step back.
I will upload tomorrow, approx. 24 hours from now, as have to fix a couple of scripts that I wrote assuming the new PATA devnode naming. Also, I'll be back in Perth, with fast ADSL2 access.
Note, I have added this IDE kernel to the others in Unleashed, so Puppy can be built with quite a choice now.
Unionfs 2.4 released
The Unionfs developers have just released a major upgrade. They have also admitted ignoring bug reports for version 2.3.3 for the last three months.
It is very nice to have a brand new version, except that in the meantime they have lost more customers, including us.
I may reconsider Unionfs again sometime, but I'm not going to rush in now and patch and recompile the kernel.
SCSI booting works!
Forum member Sit Heal Speak is dancing in the clouds right now, as he has got Puppy booting off a SCSI drive:
http://murga-linux.com/puppy/viewtopic.php?t=31930
All it needed was the kernel compiled with drivers built-in, and we are now in business!
And I haven't even put my own SCSI hardware together yet. Sit Heal Speak has mentioned a couple of little oddities, so perhaps a little howto on the puppylinux.org wiki would be good. Especially for me, some notes about gotchas and oddities to watch out for would be helpful.
Gtklogfileviewer removed
While I'm on the attack, I will add this one. I had a problem with this utility not working correctly, also there have been reports on the forum. I reported this to MU and he did ask me to supply more details about my particular problem (the newly-appended lines were not displaying properly) but I don't have that info anymore. MU thought that certain characters in the file may have been upsetting gtklogfileviewer -- probably that is the case. As I recall though, it was a pretty ordinary plain text file -- and at the time I fell back to using 'tail -f' which worked perfectly.
Anyway, I have to move on, and have fixed it the quickest way that I can. I have removed it and wrote a simple script using Xdialog that completely replaces gtklogfileviewer -- this is needed, as Pburn uses it.
Pburn does not work
This is so frustrating... why, whenever I test Pburn, it does not work correctly? This is version 1.9.6.
I selected a directory that I wanted to archive, which showed "Minimum disk size: 1294Mb". I clicked "Burn" button then chose DVD, on-the-fly, close session (note, starting Pburn afterward, it does remember those settings, but not the "DVD" selection -- goes back to "CD" -- with gtkdialog3 you have to reorder the list with the default one at the top).
However, it was unable to burn to my DVD-R, came up with a window:
"Unknown error -- see log for further information"
What log? There is nothing anywhere for opening any log file.
However, I had run pburn from a terminal, so I was able to see error messages, and there were heaps of them, mostly looking like this:
/usr/local/pburn/func_build_command: line 3: /root/.pburn/tmp/pburn-exec: No space left on device
...which makes no sense at all, as there is plenty of space. Believe me, in all respects, RAM, partititons, tmpfs's, there is plenty of space.
I looked in /root/.pburn, 'du' shows it has 64MB of stuff in there ...yikes! I am doing on-the-fly burning, so it's all heaps and heaps of symlinks. Anyway, the filesystem that /root is in is far from full -- it's the pup_save file and has 240MB free.
Note, if I chose a smaller directory, it does work. The directory that I wanted to burn, 'du' shows it to occupy 1566MB, which Pburn estimates needs media space on the DVD of 1294MB. Whatever, there should not be any problem with burning that on-the-fly.
Changing the subject, but only slightly, earlier I was using Pfind and Pfilesearch hung on me. I was running that from a terminal and did CTRL-C to kill it, but that left a couple of processes running, and had to use 'kill' on those. I rebooted after that, so that problem has no relationship with the Pburn problem.
Changing back to DVD-burning, I have a regular need to burn directores to DVD, and it is so darn simple to do, basically just one line. For my own use anyway, I am going to be forced to write a little GUI for doing that one job, just so that I have confidence that it is going to work right.
I am sorry to be so harsh, but this as been an ongoing thing, and I have been expecting Pburn to have reached the stage of extreme reliability. I don't care about the bells and whistles that keep getting added, I just want it to work.
UDF filesystem
In earlier puppies, the UFS filesystem was not supported. The ufs.ko module was screened out as too "exotic" by the createpuppy script in Unleashed. As there is demand for UFS, it is now in 4.1alpha5.
However, Alex has now complained that the UDF filesystem is also screened out as "too exotic and unlikely to be used", but it is needed.
So, I have now allowed udf.ko and that will be in 4.1alpha6.
Geany scrolls past end of file
The version of Geany in 4.1alpha5 is 0.13 and it has a feature that annoys me so much, I reported it to the Geany bugzilla as a bug. It is the feature that Geany will scroll an entire window past the last line.
The author responded (and closed the bug):
You can easily disable by setting the hidden preference
"scroll_stop_at_last_line" to true.
For details, see the documentation at
http://geany.uvena.de/manual/index.html#hidden-preferences.
This is also mentioned in the FAQs,
http://geany.uvena.de/Documentation/FAQ#QQuestions8.
So, how do we disable this permanently? Unless the majority actually like this feature!
I also made a suggestion about navigating wrapped lines:
http://sourceforge.net/tracker/index.php?func=detail&aid=2030918&group_id=153444&atid=787794
...but the author didn't think much of it.
Ayttm launch fix
GeoW reported that starting Ayttm from the desktop 'chat' icon is different from when started from the menu. In the latter case, it does an auto-login to IRC #puppylinux, a script courtesy of Wolf Pup.
I have changed the 'chat' icon to also run the auto-login script.
Puppy 4.1alpha5
I have uploaded this to:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha5/
The background photo is the Australian "outback" and the guy on the bike is not me! (looks like a great way for a relaxed holiday, hey -- and environmentally friendly)
Fix for USB analog modems
There is a problem that has been discussed here:
http://murga-linux.com/puppy/viewtopic.php?t=29291
What I have done is followed the advice in the forum thread and created symlinks of /dev/ttyUSB0 to /dev/usb/ttyUSB0. Also for /dev/ttyUSB1.
Then I went through the relevant "firmware tarballs" packages (well, that's only the pl2303 pkg, isn't it?) and changed the symlink /dev/modem to /dev/ttyUSB0.
Then I noticed that the 'cdcacm' firmware package has the same problem, with /dev/modem a link to /dev/input/ttyACM0, so I have employed the same solution.
In fact, we probably don't need symlinks, could just move those devnodes out of /dev/usb and /dev/input.
Psip upgraded
Now at version 0.11, which has a better layout for smaller screens.
Network Wizard upgraded
I have tested Dougal's improved Network Wizard, dated July 28th, and it is looking real good. It fixes some serious problem areas in the old Wizard.
For building Puppy in Unleashed, I made it into a PET package named 'net_setup-20080728'. I took out the rc.network script and put that in the 'rootfs_skeleton-405' package.
The only change that I made in the scripts is the clash with Debian/Ubuntu directories and files in /etc. We do need to think ahead that we may want to put in other Debian/Ubuntu packages (of which Pppoeconf is one), maybe also in the case of the forgotten "underdog" layer f.s. configuration.
I could not think of elegant names to change /etc/network and /etc/wireless to, so just used /etc/wizard_network and /etc/wizard_wireless. That can of course be changed.
I have still got some stuff to do. probably 4.1alpha5 is about 24 hours away.
Ayttm upgraded
Now at version 0.5.0-62.
Pfind
I have upgraded Zigbert's Pfind from version 3.4 to 4.1.
Why do I bother?
Why do I even bother to request feedback?
Someone posted that they would like to test Pppoeconf, so I uploaded a tarball. No feedback.
A couple of people complained about no sound in Aspire One and Eeepc so I post responses asking for feedback, no response:
http://murga-linux.com/puppy/viewtopic.php?search_id=2112803361&t=31298&start=15
http://murga-linux.com/puppy/viewtopic.php?search_id=2112803361&t=31669
SCSI kernels uploaded
As announced recently, I have compiled three kernels with different sets of SCSI drivers built-in. Today I recompiled the 'SCSI3' kernel, reducing the selection as it overlapped what is in the 'SCSI2' kernel.
Get them from here:
http://puptrix.org/sources/kernel-2.6.25.11/scsi/
PPLOG fix
I noticed that a link does not work when PPLOG is run. When you start PPLOG in 4.1alpha4, there is a first-post made by me which contains a welcome message plus some web links. It also has a link to a local 'hiawatha.htm' manual page, except that the link does not work. I have edited the page so it now looks like this and the link works:
Puppy has local documentation on Hiawatha here (note: actual location is /root/httpd/hiawatha/hiawatha.htm):
http://127.0.0.1/hiawatha.htm
Note, I moved 'hiawatha.htm' from /usr/share/doc, as Hiawatha cannot "see" files outside its webrootdir.
Home page updated
When the web browser is first started, it comes up with a home page, located at /usr/share/doc/home.htm, titled "Puppy's jumping off page".
A couple of links in this page are getting a bit dated. There was a link to the wikka latest news, which I have updated to
http://www.puppylinux.org/home/latest-news
There was a link to video tutorials at rhinoweb.org, but my understanding is that this has become outdated, so I have changed to the User Manuals:
http://www.puppylinux.org/manual
I left in Lobster's slideshow intro., as that is amusing.
Improving Network Wizard
I have just started to look at Dougal's improvements to the Network Wizard. I have come to a stop for now as there are a few issues.
1. /etc/network/interfaces
This one is easily fixable.
Dougal would not have know about this problem, as it is so recent. I recently modified the Pppoeconf package to give it some infrastructure so that hopefully it will work. This infrastructure is directories and files out of Ubuntu. One of those is a file /etc/network/interfaces, which clashes with what Dougal has created.
An extra note, the Pppoeconf package also has directory /etc/wpa_supplicant, with a couple of files in it that the pppoeconf script uses.
2. sleep 10
The boot scripts in 4.1alpha4 avoid the need for big sleeps. In the case of rc.network, it has this code in the same place where the 'sleep 10' is located in Dougal's rc.network:
3. lsusb, lspci
Pup 4.1 does not have lsusb, that Dougal uses in net-setup.sh. 4.1 does have lspci but does not have /usr/share/pci-usb-pcmcia.ids.
4.1 does not have any '.ids' files, as I consider them to be redundant, not worth the space they take up, due to the amount of information packed into 2.6-kernel modules.
Event Manager tweaks
There was a little bug, when the choice was made to not show any drive icons on the desktop (just a single 'drives' icon to represent everything), the optical drive icon still showed up. Fixed.
I have been testing the checkboxes in the Event Manager. I was prompted to look at this as a couple of people reported that it is complicated to use. I carefully studied it, and actually it is all dead-simple. Perhaps the desktop icon 'handler' tab could have some clearer explanation, so I have made it a bit more wordy.
I also added a "Desktop drive icons manager" into the "Desktop" menu, which launches a cutdown version of the Event manager, only showing what is related to management of the desktop drive icons. Although it was unnecessary to dumb it down that much.
Now, launched from the Desktop, the drive icons manager looks like this:
...note the 'Legacy' tab. That is to manage the floppy disk icon ...I know it annoys sage.
Acpitool
hey, isn't this just crying out to have a GUI frontend made for it?!
http://freeunix.dyndns.org:8088/site2/acpitool.shtml
muggins found acpitool, and posted a PET to the forum:
http://murga-linux.com/puppy/viewtopic.php?t=31753
4.1alpha5 checklist
I am planning to upload this in a couple of days. There will still be more things to fix, but I have made up a shortlist of things to do before the upload:
1. Look at Dougal's latest Network Wizard.
2. Examine some issues with Pmount not refreshing.
3. A bit more thought on copy-to-ram of pup_xxx.sfs.
4. xse or xautomation to raise/lower Pmount when click icons?
5. Check PETget package downloading.
6. Recompile scsi3 kernel -- had some drivers already in scsi1 and scsi2.
7. GeorgeR reported that his USB keyboard does not work when there are multiple 'pup_save' files to choose from at bootup. I cannot reproduce that bug, but I'll try my USB keyboard on a couple more PCs.
Internet Connection Wizard
This is what runs when you click the 'connect' icon on the desktop.
I am trying to add more useful functionality to it, without cluttering it up too much. Here is the latest:
(note, if you read this blog sometime in the future, this image may have got updated).
I still don't know if the new Pppoeconf package works. I uploaded a tarball, announced here:
http://puppylinux.com/blog/?viewDetailed=00238
...but nobody has.
Never mind, it will be in 4.1alpha5.
The thing is, even if it works, I don't know how it saves its settings and gets re-connected at future boots. Will have to sort that out. Perhaps in the above picture, there will need to be a radiobutton for PPPOE-Connect.
For the GPRS entries in the picture, they only appear if Puppy has found suitable hardware.
One thing that may need more work. I kept the wording minimal, but "Connect to Internet by network or wireless LAN" may not be adequate. Someone who just plugs their Ethernet cable into a ADSL modem or a modem/router, or has a wireless modem/router, may not realise that they should click that particular button.
wvdialconf bug workaround
Rerwin found another strange bug when using 'wvdialconf' to probe for modems. The 'Modem' entry in /etc/wvdial.conf can get set to '/dev/modem', but /dev/modem is a symlink to 'modem', that is, to itself. Peculiar situation.
I have modified /usr/sbin/modemprobe to workaround that problem.
However, /dev/modem should never be a symlink to itself, and I think that I have fixed where that was happening. I also put in a test in rc.sysinit to catch that invalid link.
setserial bugfix
Rerwin reported in the 4.1alpha4 forum feedback thread that setserial can crash if applied to other than serial modems.
I have applied the fix to /etc/rc.d/rc.sysinit and also to /usr/sbin/modemtest.
The setserial utility is supposed to configure the modem so that it can be used. For example, it can be made to automatically select the correct IRQ line. I don't know what the story is with other than serial hardware modems, but anyway the above scripts are now limited to only running setserial for /dev/ttyS0 - ttyS4 devices.
What are phy drivers?
I noticed recently in dmesg that a driver was registering something called 'phy0', and this seems to have something to do with ethernet.
So, when I compiled the 2.6.25.11 kernel, I enabled "PHY device support and infrastructure" as a module. This was in the "Network device support" section.
This has resulted in some more modules, but they don't have any modalias entries so I don't know what would cause them to load, if anything.
I have googled around, found plenty of references to phy devices but nothing that tells me what they are. Anyone got a clue or two about this?
Modem detection progress
Analog dialup modem detection is somewhat broken in 4.1alpha4, due to the lack of automatic detection of serial hardware modems at bootup.
I have fixed it all, and added more probing functionality to PupDial. It just remains to do some more testing, to catch any stray bugs.
Osmo not upgraded
Pup 4.x has Osmo 0.2.0, the latest is 0.2.2 which now unfortunately has a dependency on libnotify which has a dependency on dbus.
I am not "ready" to put dbus into 4.1. It may happen sometime, but I need to study it thoroughly first, especially reports that it slows things down.
uvcvideo driver
See the previous post. This is the Linux-uvc driver, module uvcvideo.ko. It does not seem to clash with any other driver, so I have put it in.
The related modules that also load for that hardware are:
v4l1-compat, videodev, compat-iotl32 and usbcore.
uvcvideo itself does not have any dependencies, so I am just assuming that the loading of those extra modules does not cause a clash.
atl2 Ethernet driver
Another bug report for 4.1alpha4 was that the 'atl2' Ethernet driver is missing, required for the Eeepc laptop. I have now compiled that driver.
I was looking at a forum thread on the Eeepc and there is mention of a 'Linux-uvc' or 'uvcvideo' driver being needed. However, when I went to the linux-uvc website there was no source available.
http://linux-uvc.berlios.de/
The site said to get it from SVN, but there was nothing there. I found an older version, 'linux-uvc-0.1.0-e', at the T2-project repository but that does not compile.
So, has this become part of the mainline kernel source? -- the linux-uvc site doesn't say that. The 2.6.25.11 kernel does not have any driver with "uvc" name in it. There are lots of V4L2 USB drivers though.
Update: I browsed linux-uvc SVN and the files are there, then I found that the URL given to fetch from SVN is incorrect. The correct command is:
svn checkout http://svn.berlios.de/svnroot/repos/linux-uvc/linux-uvc/trunk
...I had to insert a second "linux-uvc" into the path.
pppoeconf for testing
Dougal suggested that I should upload the amended Ppppoeconf package for testing. Okay, it is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha4/
This should add the extra infrastructure to 4.1alpha4 so that the pppoeconf script will work. Perhaps it will work in earlier puppies also. This is supposed to work with the ppp package only, and does not need the Roaring Penguin rp-pppoe package.
One other thing that you will probably have to do. It requires the group "dip", so append this line to /etc/group:
dip:x:30:
And append this line to /etc/gshadow:
dip:::
Run 'pppoeconf' in a terminal so that you can see any error messages and report back here.
Note, for troubleshooting, an earlier post to this blog has two very useful links on "kernel-mode-pppoe" (which is what pppoeconf is using):
http://puppylinux.com/blog/?viewDetailed=00062
Pnethood, Geany again
HairyWill's Pnethood upgraded to 0.65.
There is one thing that I dislike about Geany 0.13 -- scrolling down to the end of the document I am able to scroll a complete window past the last line, so I just see a blank window. I dislike that so much, I'm even tempted to rollback to 0.12.
Xlock fixed
One feedback report on 4.1alpha4 is that when click on the 'lock' icon on the desktop, nothing happens. Xlock was upgraded by Nathan, with a nice menu entry and international language support, but the bug is not Nathan's fault, it's mine.
Previously, /usr/X11R7/bin/xterm was a symlink to /usr/bin/rxvt, but I replaced the former with a script. The reason for this was that Xf-prot requires the '-hold' option for xterm, which rxvt does not have, so the script was a workaround. Anyway, my xterm script had a little bug which crashed Xlock, now fixed.
While I as looking into xterm and rxvt, I thought of going over to Urxvt, as it supports more options including '-hold' and also has special support for unicode so is good for internationalisation. Urxvt is very big, but the 'mp' text editor would not run in it -- probably that could be sorted out, but I couldn't see how so just left it at that and decided to stay with rxvt.
Every now and again I checkout alternatives to rxvt, but always there is some little thing that stops me from changing over. I think that rxvt can be compiled against the libncursesw library (it is currently using libncurses) which will give it better international support ...I might grab the latest rxvt and look at the compile options.
Pppoeconf maybe fixed
I have been running Ubuntu 8.04, examining the environment that Pppoeconf needs to work properly. I have imported various directories and files into Puppy that will hopefully provide the necessary infrastructure. I can't test it though.
libgphoto2, gphoto2
Puppy 4.00 has libgphoto2 version 2.4.1. I have now upgraded to 2.4.2, for Puppy 4.1.
There is currently some discussion on the forum about problems with Gtkam (a GUI for libgphoto2) and using the commandline utility gphoto2, and the possibility of developing our own GUI that is a frontend to gphoto2.
However, it was then noticed that Puppy 4.00 does not have gphoto2, so I have also compiled that, version 2.4.2, for Puppy 4.1.
I also recompiled Gtkam against the new version of libgphoto2, on the off-chance that it might improve the stability of Gtkam -- but, no it doesn't.
Aspire One video support
I have added support for the 1024x600 LCD screen in the Acer Aspire One.
This required patching the source of the '915resolution' package, version 0.5.3, as described here by timothyli:
http://murga-linux.com/puppy/viewtopic.php?t=31298
...the forum thread has a link to a site with the complete patch. This is for the Intel 965GM graphics chip.
I then modified /usr/sbin/xorgwizard so that Xorg supports 1024x600, and modified /usr/X11R7/bin/xwin for Xvesa.
Geany, Pburn, Pmusic, Pnethood updated
Geany version 0.13. This has support for printing.
Pburn 1.9.6.
Pmusic 0.1.4
Pnethood 0.64
Ayttm updated, Geany not updated
I have updated Ayttm with the latest from CVS, version 0.5.0-59.
I had hoped to update Geany to version 0.14, as it now supports printing. However, it won't even start, get a "Segmentation fault". I'll go back to their site, see if there's a fix.
SCSI kernels
I went to a Slackware download site to obtain kernel .config files for Slackware's "SCSI kernels". Surprise, Slackware stopped providing these at version 11.0. Up to and including 11.0, Slackware provided four kernels, named "adaptec", "scsi", "scsi1" and "scsi2", with different groups of SCSI drivers built in. There are various reasons for this:
1. Having SCSI drivers builtin rather than modules makes it easier to boot from a SCSI drive.
2. All SCSI drives are not builtin to one kernel as the kernel can become confused at bootup and there will be a "kernel panic".
3. All SCSI drives are not builtin to one kernel as the kernel would become very big.
Anyway, I have created three SCSI kernels for Puppy 4.1, with the 2.6.25.11 kernel. I have named them "scsi1", "scsi2" and "scsi3". The first is almost the same as the Slackware "adaptec" kernel, the second close to the Slackware "scsi" kernel, and all left-over SCSI drivers are in my "scsi3" kernel.
The idea is that when I or someone else wants to boot Puppy off a SCSI drive, you just pop in the right kernel.
So, I had better document how each is configured:
SCSI1
CONFIG_SCSI_AHA152X=y
CONFIG_SCSI_AHA1542=y
CONFIG_SCSI_AHA1740=y
CONFIG_SCSI_AACRAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_SCSI_AIC79XX=y
CONFIG_SCSI_AIC94XX=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_NCR53C406A=y
SCSI2
CONFIG_SCSI_EATA=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_INITIO=y
CONFIG_SCSI_INIA100=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_QLOGIC_FAS=y
CONFIG_SCSI_QLOGIC_1280=y
CONFIG_SCSI_QLA_FC=y
CONFIG_SCSI_QLA_ISCSI=y
CONFIG_SCSI_SIM710=y
SCSI3
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_7000FASST=y
CONFIG_SCSI_ACARD=y
CONFIG_SCSI_ADVANSYS=y
CONFIG_SCSI_IN2000=y
CONFIG_SCSI_ARCMSR=y
CONFIG_SCSI_HPTIOP=y
CONFIG_SCSI_BUSLOGIC=y
CONFIG_SCSI_DMX3191D=y
CONFIG_SCSI_DTC3280=y
CONFIG_SCSI_FUTURE_DOMAIN=y
CONFIG_SCSI_GDTH=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_IPS=y
CONFIG_SCSI_INITIO=y
CONFIG_SCSI_INIA100=y
CONFIG_SCSI_NCR53C406A=y
CONFIG_SCSI_STEX=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_PAS16=y
CONFIG_SCSI_SIM710=y
CONFIG_SCSI_SYM53C416=y
CONFIG_SCSI_DC395x=y
CONFIG_SCSI_DC390T=y
CONFIG_SCSI_T128=y
CONFIG_SCSI_U14_34F=y
CONFIG_SCSI_ULTRASTOR=y
CONFIG_SCSI_NSP32=y
Multitech GPRS modem
Lloyd has done a lot of work, see this thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=31224
Quoting:
I am pleased to announce the first release of a patched driver for the USB-connected Multitech Multimodem GPRS/EDGE/CDMA modems. Multitech makes what are probably the best GPRS modems in the world. (GPRS is a wireless Internet technology, running on top of a GSM cellular phone connection. It provides very cheap Internet access throughout Costa Rica, and is is popular in several European countries.)
To my knowledge this is the only working driver package available for a modern Linux distro (aside from my Debian Etch solution at http://voluntary-simplicity.org/linux, which is not nearly as nice as this). In other words, no other current Linux distro (kernel version 2.6x) has a driver package that works with these modems. It is tested only for GPRS.
I am looking how his PET package can become a "firmware tarball" in Puppy 4.1. That is, it will be built-in, located at /lib/modules/firmware/multitech-1.2.tar.gz, and will install automatically if the ti_usb_3401_5052.ko module loads.
I have created an entry in /etc/modules/firmware.dep.2.6.25.11, which establishes this relationship between module and firmware package:
multitech-1.2:ti_usb_3410_5052.ko
Puppy 4.1 will automatically load usbserial.ko and ti_usb_3401_5052.ko and in the correct order, so I don't think Lloyd's 'pinstall.sh' file is needed. Um, no, have retained just this:
#make symlink if /dev/ttyUSB0 not already a special device file
if [ "`file ./dev/ttyUSB0 | grep 'character special'`" = "" ];then
rm -f ./dev/ttyUSB0
ln -s /dev/usb/ttyUSB0 ./dev/ttyUSB0
fi
/usr/sbin/fixmenus
I added the last line, as Lloyd has .desktop files, so the JWM menu will need to be updated.
I need to liaise with Lloyd on this find out if I've done this right. Note, 4.1alpha5 is expected to come out real soon, so we can test this, or rather Lloyd will as he has the hardware. Lloyd has stated that other brands of GPRS modem may also work.
What is supposed to happen here, is if you boot Puppy with the appropriate hardware for the ti_usb_3401_5052.ko module (or hotplug it), then the firmware package will automatically install and menu entries will magically appear. There will be nothing separate to install to get it going.
2.6.25.11 kernel compiled
I applied ten patches:
1. loglevel patch.
2. patch -p1 < ../4300_squashfs-3.3.patch
3. patch -p0 < ../splice-2.6.23.patch #for aufs
4. patch -p1 < ../fsync_super-2.6.19.patch #for aufs
5. patch -p1 < ../deny_write_access.patch #for aufs
6. patch -p1 < ../linux-lzma-2.6.25.5.u
cd /
7. patch -p0 < usr/src/multitech/ti_fw_3410.h.diff
8. patch -p0 < usr/src/multitech/ti_fw_5052.h.diff
9. patch -p0 < usr/src/multitech/ti_usb_3410_5052.diff
10. patch -p0 < usr/src/multitech/ti_usb_3410_5052.h.diff
Note that I did not apply the Unionfs patch, given its current instability.
Patches 7 - 10 were supplied to me by forum member rstandish (Lloyd). These are patches to the ti_usb_3410_5052 module. See this forum thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=31224
The patched kernel source, plus sources for 3rd party drivers, has been uploaded to Ted Dog's site:
http://puptrix.org/sources/kernel-2.6.25.11/
The madwifi drivers are included. I created an entry in the PREFLIST variable in /etc/rc.d/MODULESCONFIG:
PREFLIST=' rt2500usb:rt73usb ath_pci:ath5k '
So the ath5k module will get preference. If you want to use the Madwifi module then you would need to run the BootManager and remove the 'ath_pci:ath5k' entry (or just edit /ec/rc.d/MODULESCONFIG).
New Network Wizard
Dougal has done something very ambitious, to overhaul the Network Wizard. Go to the forum thread to find out more:
http://murga-linux.com/puppy/viewtopic.php?t=31522
Testers are needed!
Autologin for Ayttm
Someone posted a report to Ayttm bugzilla that it crashes in 4.1alpha4 when trying to login to IRC, so I tried it myself, it works fine for me. Perhaps Unionfs again? (I'm running Aufs now).
Anyway, while logged in I had a chat with wolf_pup and he has done something great (I suppose that you are a "he", wolf_pup?). Wolf_pup has made available the latest Ayttm for Puppy 3.01 and later users, and has recently added autologin. He has adapted the original Pidgin autologin script.
Wolf_pup's Ayttm forum post is here:
http://murga-linux.com/puppy/viewtopic.php?t=31185
Of course, I have taken the login script for my Ayttm package and that will be in 4.1alpha5(or beta).
PUPMODEs 6 and 7
I have tidied this up in the 'init' script. The default is now not to copy the 'pup_xxx.sfs' to RAM unless the 'pfix=copy' boot parameter is given.
However, there are conditions in which this must be overriden. Here is the actual code in 'init':
#v405 decide whether to copy sfs's to ram...
COPY2RAM=""
COPYMSG='\\033[1;35mcopying to ram\\033[0;39m' #purple
#v4.00 lowered rom 230000 to 220000... v403 added PUPSFSDEVMNTPT test... v404 explicit PCOPY needed...
[ $PUPMODE -eq 5 ] && PCOPY="yes" #well, override on first boot.
#v404 absolutely must copy to ram, otherwise layerfs conflict...
[ $PUPMODE -eq 6 -o $PUPMODE -eq 7 ] && COPY2RAM="yes"
[ "$COPY2RAM" = "yes" ] && COPYMSG='\\033[1;35mforced copying to ram\\033[0;39m' #purple
[ $RAMSIZE -gt 220000 -a "$PCOPY" = "yes" ] && COPY2RAM="yes" #256MB system. note, only checking physical ram.
The SFS is copied to RAM on the first boot, if there is enough RAM, as that is what the first boot is all about, running totally in RAM.
PUPMODEs 6 and 7 are cases that I have recently mentioned. Frugal installation but using the entire partition to save, instead of a "pup_save" file. There is a conflict that causes Unionfs to potentially crash and Aufs to not start. File pup_xxx.sfs, in fact all SFSs that are to be loaded as a layer, must be copied to RAM ...oh dear.
Oh dear, because currently the 'init' script does not copy any additional SFS files, for example 'devx_xxx.sfs', to RAM.
Um, I think that I will withdraw support for PUPMODEs 6 and 7 totally. Unless I also add code to copy all SFSs to RAM ...yuck.
Note, sometime ago I was using PUPMODE 6 and 7 quite happily, with Unionfs. Perhaps that was the less ambitious v1.x series. These days, in both Aufs and Unionfs there is an emphasis on supporting direct writing to the layers, and I suspect this is what is causing the conflict.
Has anyone else used PUPMODEs 6 or 7 with success?
Sound, front sockets not working
Does anyone reading this have any experience with getting the front sound sockets to work?
On my laptop, if I plugin the headset, the inbuilt loudspeaker cuts out, and Alsamixer now has a "headphone" entry, however it's volume cannot be raised.
However, the microphone does work.
On my desktop PC, the front sockets don't work at all, have to plug the headset into the rear sockets.
ALSA fixed
Sound is a bit broken in 4.1alpha4. Previously, there was some code at bootup that appended some lines to /etc/modprobe.conf, like this:
alias snd-card-0 snd_hda_intel
alias sound-slot-0 snd_hda_intel
4.1alpha4 does not have that code, and I have found that it breaks /etc/rc.d/rc.alsa, which is run (with the 'start' parameter) at bootup. If you run the ALSA Wizard (Setup menu) it will create those lines. That's the first bug, now the second...
Experimenting on my laptop, I found that it likes the following modules to be loaded:
snd-mixer-oss
snd-seq-oss
snd-pcm-oss
4.1alpha4 loads the first one only, but my microphone doesn't work. Previous puppies had explicit code in the boot scripts to load all three, but now that 4.1 is relying on the uevent mechanism there are much less explicit modprobe's in the boot scripts.
I didn't think those modules mattered anyway, as I thought that they had something to do with the old OSS-compatibility. But they are needed -- or perhaps their dependencies are needed. Anyway, I have now reinstated modprobe's to load them.
What started me off on fixing sound is today I purchased a headset. The brand is OfficeOne, from Kmart and it cost AU$19.95 (with the dropping US Dollar, the Australian dollar is almost on a par, and that would be about US$19.30). looks well made, Chinese of course.
Booting with Aufs
If you are testing 4.1alpha4 and have any trouble with crashing, try using Aufs rather than Unionfs. The way you do this is to boot with the 'layerfs=aufs' kernel boot parameter.
If booting from CD, at the prompt in the 5-second boot screen, type this:
puppy layerfs=aufs
If Puppy is installed to Flash, then you most likely have a isolinux.cfg or extlinux.cfg file on the Flash drive. Open that in an editor and append:
layerfs=aufs
If you are using GRUB then you should be able to figure out where to append this parameter.
Due to the many outstanding bug reports posted to the Unionfs bugzilla and lack of response from them, it looks like we will be going over to Aufs. I'm using Aufs right now. I need to do some checking that it runs right, as there are some assumptions made in 'petget' about how the layers can be written directly into, and elsewhere such as rc.update there is some management of whiteout files -- which are slightly different in Aufs.
SeaMonkey mailto fix
I fixed a bug in the new 1.1.11 SeaMonkey. The file /root/.mozilla ... prefs.js was setup for an external mailto handler. See last three lines of that file -- I have removed those lines.
Event management pages updated
I have updated the "Kernel module loading" and "Puppy event management" web pages:
http://www.puppylinux.com/technical/module-loading.htm
http://www.puppylinux.com/technical/event-management.htm
Puppy 4.1alpha4 released
I drove to Perth last night, partly because I get access to ADSL2 high speed Internet at my relative's place. I am typing this using a nice keyboard on my desktop PC that I brought along!
The iso's are uploaded to here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha4/
There is some uncertainty about whether the 'evdev' module is stuffing up the mouse on some hardware. So, I have created an alternate iso which has 'evdev' blacklisted. So, Lobster and others, try that one.
Why do we need 'evdev' anyway? We never had it before, and my computer works fine without it. Is it like the 'ub' module, a "Swiss Army knife" that tries to do everything, but not very well? ...heh, heh, don't mind me, I'm just being deliberately provocative.
If you want to see how fast 4.1alpha4 boots, time the third boot. The reason is, the first boot is your PUPMODE 5, with no save-file, then you shutdown and create a save-file, but on the second boot the 'rc.update' script takes awhile as it analyses the Unionfs layers for correctness -- I need to look at this script and see if I can streamline that, or at least put a little message "checking layered f.s., next boot will be faster!".
Still stuck on the 2.6.25.9 kernel. The next release should have the 2.6.25.11 kernel, which I intend to stay with for a long time.
I need to update the Event Management web page, as now using the 'udevd' daemon. I'll see if I can do that later today.
So, what's special about this latest pup?
1. Much faster boot.
2. Udevd with my custom backend scripts for module loading/hotplugging.
3. Event manager frontend, including desktop drive icons.
4. SeaMonkey full suite.
5. Pmusic audio player.
6. Psip VOIP and IM client.
7. Pppoeconf, new setup GUI tool -- nobody responded to my request to test.
8. Ayttm replaces Pidgin.
9. PPLOG personal blog.
10. Xfprot virus scanner.
All of the above need testing! This release is pretty solid, at least it is on my PCs, so this time I welcome lots of feedback, extensive testing. If it turns out there are lots of bugs, then the next release will be 4.1alpha5, otherwise it will be 4.1beta.
Psip
I have upgraded Psip to 0.9.13.
SeaMonkey, evdev
SeaMonkey version 1.1.11 will be in 4.1alpha4, and this is the full-blown suite with Mail, News and Addressbook modules.
Lobster, and I think at least one other person, has reported mouse trouble with the 4.1alphas.
I'm wondering if it has anything to do with the 'evdev' module.
Lobster, in your Puppy-with-working-mouse, which I presume is 4.00, is 'evdev' loaded? (run 'lsmod' in a terminal).
p.s. does anyone else hate their laptop keyboard? I have to punch the keys hard on my Acer, and so often I hit the space-bar a bit off-centre and it doesn't register. I always have to read what I typed very carefully, as characters regularly get missed -- certain keys in particular, if I hit them a bit too lightly they don't register. I miss the positive action of a quality keyboard, actually, even a fairly cheap normal keyboard is way better. Or, is it just the way I type, and no one else has a problem?
Pmusic, Pburn, Psip
Pmusic upgraded to 0.1.3. Well, Pmusic is actually a newcomer, making its debut in 4.1alpha4.
Pburn to 1.9.5.
Psip 0.9.12, another newcomer.
Psip: wow! If you want to know more, here are some forum threads:
http://murga-linux.com/puppy/viewtopic.php?t=31061
http://murga-linux.com/puppy/viewtopic.php?t=30322
The project coordinator for Psip has been Lobster, and HairyWill has done a lot of the heavy background work -- and has got some premature grey hairs -- a special thanks to you guys. Thanks to Evil20071, smokey01, charnisingh, Caneri, puppyluvr, prit1, gazb, John_Doe and peppyy for pitching-in and helping with testing.
UPDATE: Once I start listing names, I had better get it right. I also wish to add a thanks to CEL and Aitch for helping with testing, and jebajQ8 for the icons!
I'll put 0.9.12 into 4.1alpha4 (unless another version comes out pretty soon) and we can do some wider testing.
PUPMODE fix for Classmate
There are various ways that you can install Puppy to a baby laptop with internal Flash memory.
1. Full "hard drive" installation.
2. Frugal, with a "pup_save" file.
3. Frugal, saving to entire partition (if it is a Linux partition).
I recently reported some trouble with option 3, that is, Aufs not starting and Unionfs (latest version) crashing, unless 'pup_xxx.sfs' is copied to RAM.
There has been an on-going issue with option 2, testers have reported that it is running in PUPMODE 12, whereas to preserve the life of the Flash memory it should preferably be 13 (tmpfs top layer in RAM, with periodic or manual saves to the pup_save.2fs file).
I have fixed this -- the init script now detects the boot parameter 'pmedia=usbflash' and changes PUPMODE from 12 to 13.
Note that with option 1, a full conventional installation, this is PUPMODE 2 and there is no buffering with a tmpfs, so no preserving of the Flash memory. Note however, that it is theoretically possible to boot a full installation in PUPMODE 3, which does have a layered f.s. with tmpfs RAM layer on top.
I haven't tried it, but if you place the initrd.gz file on the hd partition and setup to boot from that rather than the partition itself, then it should come up in PUPMODE 3 ....but, as I say, not tested.
BootManager changes
I have removed the checkboxes for doing a serial probe at bootup and for "fast boot". The serial probe is no longer done, and "fast boot" is now unecessary considering how fast boot has become anyway.
I have added support for the new preferred-module PREFLIST variable in /etc/rc.d/MODULESCONFIG. Now there is a simple GUI for choosing a preferred module (see previous blog post).
Note, I think I'm on-track to upload 4.1alpha4 in another day or two.
No fsck at bootup
Continuing to work on fast booting. The filesystem check of the "pup_save" file gets slower as there are more files in it. Although the "pup_save" file does not shutdown cleanly, it's integrity is not compromised and there is no need to do a f.s. check and repair at every bootup.
So, I have now made it the default not to. However, the 'init' will still do so if the "pup_save" file refuses to load.
Also, I have introduced "pfix=fsck" to manually ask for a f.s. check.
If the "pup_save" was on a ext2 partition then that was also checked at every boot, and that could be very slow. Again, that is now only done if "pfix=fsck".
Cause of Unionfs/Aufs failure
Over the years I have played with both of these. Originally Puppy used Unionfs, then I went over to Aufs, then back to Unionfs.
The reason that I went back to Unionfs is I had a situation where Aufs refused to create the layers, whereas Unionfs did and worked. Well, I conducted some experiments today and perhaps it is just luck the Unionfs worked under that situation, or maybe the older version worked.
A configuration that Aufs refuses to deal with is when I had a frugal install to the Classmate and chose the "pup_save" to be the entire partition. Puppy will then boot in PUMODE 6 or 7, the latter looking like this:
tmpfs top layer
sda1 "pup_save" is entire partition
pup_404.sfs mounted by loop device
These are the layers. This worked okay before, but now Unionfs crashes and Aufs is intelligent enough to detect a conflict. The reason it worked before Puppy 4.1alpha4 is that the default was to copy the pup_404.sfs to RAM first -- well, it was only copied if there was enough RAM.
The situation now is that the default is it is not copied. The 'pup_404.sfs' is located in /dev/sda1, and that is the conflict. Aufs sees that the same file is in two layers, Unionfs dumbly goes ahead but then may or may not crash.
Perhaps Unionfs and Aufs could be made to handle this situation, but anyway what I have done is put in a fix that forces 'pup_404.sfs' to be copied to RAM if PUPMODE is 6 or 7. This will happen regardless of the amount of RAM.
"Fun" with my Classmate
Oh dear, this must rate as a fatal design flaw
I was testing the latest Puppy on the Classmate, did an install to the internal Flash memory, booted, worked, then chose to save to the entire partition (it is ext2). Upon reboot, the mouse cursor appeared on a black screen and the system froze.
I rebooted with pfix=nox and got to a prompt ok. Attempting start X had the same problem, but this time it responded to CTRL-ALT-BACKSPACE and I saw a kernel dump and frozen again -- I see on the screen the word "unionfs" amongst the crash dump.
So I decided to boot with 'layerfs=aufs', but aufs was unable to mount the layered f.s. with an error message "/pup_ro2 is overlapped", then I got a kernel panic.
That's when things got nasty. Normally, if there is a kernel panic, I can hold down the power button for 4 seconds and the system will power-off. Not this time. There is no hard-reset button. I was unable to turn off the laptop. Closing the lid did not work. The fan was not working and I could feel the CPU getting hotter.
So, had to get out a miniature screwdriver and remove the battery. I'm going to let our Intel engineer know about this. If someone did not have such a screwdriver, they would have to sit there and watch the laptop destroy itself.
Ayttm
Ayttm is a multi-protocol chat client. I have compiled the latest Ayttm out of CVS. Siddhesh is the current most active devloper (see my blog post a couple of days ago) and his latest code is in the 'libirc-mod' branch. For the record, this is how I got it:
# cvs -d:pserver:anonymous@ayttm.cvs.sourceforge.net:/cvsroot/ayttm login
CVS password: [just press Enter]
# cvs -z3 -d:pserver:anonymous@ayttm.cvs.sourceforge.net:/cvsroot/ayttm -r checkout -r libirc-mod ayttm
# ./gen
# make
I already had the Jasper package installed, which Ayttm uses to provide support for Yahoo webcam. Then to compile and install Ayttm:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --disable-esd --disable-arts --enable-webcam
# make
# make install
This will be in 4.1alpha4 instead of Pidgin.
Preferred module
Dougal raised the problem of rt2500usb and rt73usb, and the lack of any Udev rule capability to adequately deal with choosing the correct one.
The problem occurs on the Classmate laptop, where rt2500usb.ko an rt73usb.ko are both detected as eligible for the wireless network interface. If 'modinfo' is executed on each of these, and the 'alias' lines examined, it can be seen that at least two are the same.
Of course, Puppy does have a blacklist capability (see the BootManager) but that does require some knowledge on the part of the user, to know that rt2500usb needs to be blacklisted to allow only rt73usb to load.
Instead, I have implemented a 'PREFLIST', which is in /etc/rc.d/MODULESCONFIG. Here is what is currently in there:
#PREFLIST: sometimes there are two hits, that is, two modules match the same
#'modalias'. In such a case, here we can specify a preference. Each entry
#here is of the form 'module1:module2' where module2 is the preferred choice.
PREFLIST=' rt2500usb:rt73usb '
There is a script, /sbin/pup_event_backend_modprobe, that udevd calls when it has a modalias. This script does various pre-processing, mostly processing entries in /etc/rc.d/MODULESCONFIG, then loads the module.
I have now added code that reads the PREFLIST variable and if there is a matching entry, then finds out whether the candidate-replacement also matches the modalias, if so then uses it.
I don't think this is perfect, as there may be cases where on one particular hardware it is required to use rt73usb rather than rt2500usb, but in some other hardware it is not so.
Faster boot times
The new faster boot scripts for the 'standard' Puppy do make a difference.
I have only tested booting from live-CD so far. I recently reported 36 seconds booting UniPup live-CD on my desktop PC, running Xvesa. This time does not include the 5 second pause at the initial boot screen, and is the time from the moment the kernel starts to load until the desktop fully loaded. So, how does the 'standard' pup compare...
On my laptop, which has a 1.5GHz Mobile Celeron CPU, 512MB RAM, the second boot, with only one 'pup_save' file so it doesn't stop and ask me which one I want, boot time is 39 seconds. But, that is to Xorg, and Xorg is painful to watch when you are timing it -- the screen flickers and contorts for many seconds before the desktop finally appears.
I also had my slow-to-initialise PCMCIA modem card plugged in prior to bootup, and checked after bootup that it was working.
Then I tested on my main desktop PC, with 2GHz Celeron CPU and 512MB RAM. This time I chose Xvesa, and the boot time is 29 seconds ...not bad!
So, I wonder what it will be booting from a hard drive?
Unionfs problem
What to do about Unionfs? Version 2.3.3 is the latest, but myself and others have submitted bug reports:
https://bugzilla.filesystems.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=2.3.3
I first reported this to their mail-list, then to Bugzilla on the 20th June. Nothing has been done so far. A couple of other guys have had the same non-response.
Today I want to build the 2.6.25.11 kernel, and I wanted this to be the build that we stick with for a long time. Because of this Unionfs issue, I have been delaying...
Well, I suppose that I can stay with the 2.6.25.9 kernel for 4.1alpha4.
I notice also the Squashfs developer has been tardy. The latest is version 3.3, released November 2007, but that does not compile with the 2.6.25 kernel. I had to get a fixed patch from the Ubuntu developers.
Are these guys losing interest in their projects?
Udev rules fix, Rox rollback
Udev rules
Ah, I figured it out. This is the corrected rule, that previously was not working quite right:
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo ACTION=$ACTION SUBSYSTEM=$SUBSYSTEM DEVTYPE=$DEVTYPE DEVPATH=$DEVPATH > /tmp/pup_event_backend_s'"
I previously had DEVTYPE=="disk" but DEVTYPE is an environment variable, not a key word. I previously got confused about this, as SUBSYSTEM and ACTION are both key words and environment variables.
Rox rollback
A couple of people reported a problem with ROX-Filer when testing 4.1alpha3. There was no desktop background, no icons, but restarting X fixed it. I got this just once. Rox is failing to start -- there is an error message, which I do not understand.
4.1alpha3 has ROX-Filer version 2.8, so I have rolled back to version 2.6.1 (as used in Puppy 3.01 and 4.00). We shall see if the problem still occurs.
Xfprot fixed
The first time Xfrot is started in 4.1alpha3, it attempts to download the f-prot package, which has the signature file and a scanner executable. There was a bug in my download script, that caused it to hang, now fixed.
PPLOG fix, faster boot
PPLOG fix
I built the latest Puppy and installed to USB Flash. Booted, then tested PPLOG, but got a "500 internal server error". I found that PPLOG needs the 'CGI' Perl module -- the reason PPLOG worked before is because I had the 'devx' file loaded, which has the complete Perl, whereas the 'pup_xxx.sfs' has a cutdown Perl PET package (perl-5.8.8tiny). I added the CGI module and PPLOG worked -- that adds about 400KB uncompressed to the cutdown Perl package, but I reckon it is worth it (it jumps from 2600KB to 3000KB according to 'du').
Hmmm, now that we have a web server in the 'standard' Puppy build, I wonder what other little Perl CGI program gems are out there...
Faster boot
One thing that has been most impressive with UniPup is the fast boot. This has brought home to me that as Puppy has progressed, boot times have got gradually longer. 4.1alpha3 is the worst. It is time for a clean sweep, and to make some tough decisions.
I have applied the fast boot code developed for UniPup to the mainstream "normal" Puppy. Some notes on this:
1.
rc.local0 is eliminated (it has a lot of historical, very tangled code), there is now just rc.sysinit, which calls rc.update, rc.network, rc.country and rc.services.
2.
There is no probing of serial devices, nor any autodetection of modems (except of course udevd will autoload any appropriate module it finds a match for). Instead, the intention now is to do the probing after bootup, when the user runs PupDial. The user will also have to manually choose a serial mouse.
3.
By default, pup_xxx.sfs is not copied into RAM, regardless how much RAM there is, unless 'pfix=copy' is specified.
4.
Refined code from the rc.sysinit used in UniPup, to wait for slow hardware without gross 'sleep' lines inserted.
The "normal" Puppy cannot boot quite as fast as UniPup, due to the initrd step of the former -- the init script waits for USB storage to become available, then after the switch_root the modules for some other slow hardware may get loaded (for example PCMCIA) and there may have to be a wait again -- whereas in UniPup the usb-storage driver would be loaded concurrently with the drivers for other slow hardware. However, a full hd intall will get the same fast boot as UniPup.
Anyway, I think any potential slower boot of the "normal" Puppy will only be a few seconds.
A comment on point-2. In many cases a module for a modem will be detected and loaded, and its firmware package loaded, and any install script executed. So, it may be that the modem is still fully autodetected and ready to go. However, true hardware serial modems will not be autodetected, but the "probe" button in PupDial will find it, and set /dev/modem to point to the required device. Some details may need to be worked out though!
A comment on point-3. When boot from a live-CD, the normal thing is to create a save-file at first shutdown, then the 'pup_xxx.sfs' also gets copied to the hard-drive. On subsequent boots, although the pup_xxx.sfs' is not copied to RAM, I found performance to still be good, due to intelligent buffering of memory-reads in RAM by the kernel -- after the first read, the kernel keeps as much in RAM buffer as it can.
I suppose I could make one small concession -- on first boot, PUPMODE=5, if there is lots of RAM then do copy pup_xxx.sfs off the CD, but only for PUPMODE=5. I think that some people like to boot in PUPMODE 5 often, and would like the optical drive to be freed up.
PPLOG in Puppy
I have created PET packages for Hiawatha web server version 6.7 and PPLOG blog version 1.1.
I finally got rid of /root/ghttp directory, as that was setup for nullhttpd and Quisp.
Hiawatha and PPLOG now use /root/httpd/hiawatha directory. This is the root web path when Hiawatha server is started, configurable from /etc/hiawatha/httpd.conf.
PPLOG is located at /root/httpd/hiawatha/blog directory.
I also created a menu entry for PPLOG, in the 'Personal' category, with a little GUI to start/stop the web server as well as launch PPLOG. The GUI script launches /usr/local/bin/defaulthtmlviewer http://127.0.0.1/blog/pup_pplog.pl to run PPLOG -- I have not yet figured out how to setup URL redirection to enable "pup_pplog.pl" to be left out of the URL.
Posts and comments are plain text files and are stored in /root/httpd/hiawatha/blog/posts and /root/httpd/hiawatha/blog/comments directories.
Note, I setup hiawatha to drop to nobody:nobody when running, and all files/directories in the blog are root:nobody. The hiawatha executable does not have suid bit set. I still need to run the Perl script with '-U' option.
Hiawatha web server
So far I am impressed. Hiawatha is small, with many features and was very easy to get going. It has SSL support and URL-rewriting. The author guarantees it to be secure! Here is the home page:
http://hiawatha.leisink.org/
Here is how I compiled and installed it:
# export webrootdir=/root/spot/hiawatha
UPDATE: now export webrootdir=/root/httpd/hiawatha
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --enable-xslt
# make
# new2dir make install
Then, set the 'suid' permission on /usr/sbin/hiawatha
# su spot
# hiawatha
# mozilla http://27.0.0.1:80/
# killall hiawatha
# exit
This also works:
# su -c '/usr/sbin/hiawatha -d' - spot &
However, I am very uncertain about the best way to set it up, for the security. Forgetting about that 'su' stuff, if I just execute 'hiawatha' it automatically runs as user 'nobody' -- which is good enough isn't it? So, there's no real need to have the 'webrootdir' inside /spot? -- so maybe I'll change webrootdir to /root/httpd/hiawatha.
Regarding PPLOG, yes, it works! It worked right off, well I had to edit a few lines in /etc/hiawatha/httpd.conf. I was able to post a comment, but when I wanted to edit the comment, I got an error message:
Insecure in open while running setuid at /root/spot/hiawatha/blog/pplog.pl line 901
...I messed around with file permissions, but no go. The problem is the first post is a file, created at /root/spot/hiawatha/blog/posts/00000.ppl, and this file is the problem --it was created ok but Hiawatha will not allow to open and edit it.
....so close!
Anyone skilled at this security/permissions side of things who can comment about the best way to setup the installation of Hiawatha?
Udev fixed, inotify 0.5
There were some problems with udev in Puppy, now fixed I think.
Udev rule problem
One problem was this udev rule:
ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="disk", RUN+="/bin/sh -c 'echo ACTION=$ACTION SUBSYSTEM=$SUBSYSTEM DEVTYPE=$DEVTYPE DEVPATH=$DEVPATH > /tmp/pup_event_backend_s'"
This rule is how udevd notifies my frontend daemon, pup_event_frontend_d, when a drive is inserted. However, I was getting strange behaviour, and I eventually discovered that udevd was also writing to /tmp/pup_event_backend_s when:
ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="partition"
which caused two (or more) messages when my frontend script was only expecting one.
It seems that udevd is trying to be clever and has ignored the explicit instructions in the rule (unless I have misunderstood the rules syntax, which wouldn't surpr
Barry's Blog
FireFTP, SQLiteManager, ZombieKeysThis is exciting stuff! Kirk sent me a pm with links to these addons for SeaMonkey. He told me about FireFTP and a couple of others, but when I looked on the web I found more, and SQLiteManager is particularly nice.
FireFTP and SQLiteManager, once installed, appear in the 'Tools' menu in SeaMonkey, and start in a new tab. But, they can also be made to start as standalone applications. They are also quite small.
The problem with FireFTP though is it does not work quite right when run standalone -- the version that kirk sent me runs except that the Account management menu doesn't, rendering it useless. So, I tested an older version of FireFTP (0.64.4-mod), and the Account management menu did work, but then the Preferences menu didn't -- weird.
SQLIteManager on the other hand, seems to work well standalone, but then I don't know anything about SQL. The menus seem functional anyway.
I have put these into Puppy, also ZombieKeys, which supports the Microsoft keyboard shortcuts for entering accented and other weird international characters when you only have an English keyboard. These shortcuts are mostly easy to remember, but I have also created /usr/share/doc/keyshortcuts.htm and a link to it in the main Help page.
Given the state of FireFTP, only really able to work fully as a tab inside SeaMonkey, I won't abandon gFTP yet. Puppy 4.1beta will have both.
Here is where we got the addons from, you don't have to wait until the next release of Puppy!:
http://xsidebar.mozdev.org/modifiedmisc.html
One way to install these, is just download a .xpi file, start SeaMonkey, select File -> Open, then just click the OK button each time you are asked a question. You will find FireFTP and SQLiteManager in the Tool menu. Note that FireFTP version 0.97.1-mod needs the xSidebar addon installed, but 0.96.4-mod does not.
The way you can run these apps standalone is quit SeaMonkey, open a terminal and type this:
# seamonkey -chrome chrome://fireftp/content/
# seamonkey -chrome chrome://sqlitemanager/content/
...if you know something about SQL databases, try the latter, let me know if it is worthy for inclusion in Puppy -- it sure would fill a gap in our application suite!
Sound setup maybe fixed
Testing 4.1alpha6, prehistoric reported that has to run the ALSA Wizard at every boot. I think that is fixed. Also the volume control problem.
New theme for 4.1?
I wasn't going to bother, just have a different background -- maybe that guy on the bike. I did design a new 'Gradient-brown' GTK theme and 'Gradient-brown' JWM theme, that you will find in 4.1alpha6.
However, Lobster has suggested why not use those two Gradient-brown themes, with the 'Original' desktop icons (not in alpha6). I did also design 'Browndust' desktop icons, based on Stardust, but didn't think they looked nice -- they are available in alpha6 though.
So, what do you think about Lobster's suggestion? Of course, those who don't like brown themes won't like it.
Pixmaps, floppy icon fixed, keyboard trouble
Zigbert reported that the FPM and Gwhere pixmaps are not 16x16 in the menu. Fixed.
Linuxcbon reported that some icons are missing from the 'Chat' and 'Edit' menus in Ayttm. Fixed.
Flapdoodle reported that the desktop floppy icon changed to a hd icon. Fixed.
Keyboard trouble
smokey01 has reported that the ps/2 keyboard does not work on his PC. The kernel has the ps/2 driver builtin and it should work. Your HardInfo reports this:
Class 0600 1106:3205
Class 0604 1106:b198
Class 0280 104c:9066
Class 0c03 1106:3038
Class 0c03 1106:3038
Class 0c03 1106:3038
Class 0c03 1106:3104
Class 0601 1106:3177
Class 0101 1106:0571
Class 0401 1106:3059
Class 0200 1106:3065
Class 0300 1106:7205
When you boot from live-CD, does the keyboard work at the boot prompt? That is controlled by Syslinux, not Puppy. If not, you are in trouble. If yes, try "puppy loglevel=7" and watch for any error messages.
Another thing to try: Run PupScan, find out what one of the vendor:chip IDs is mostly likely concerned with the keyboard (or just run 'scanpci' in a terminal), then google to try and find out if there are any known issues with this glue-chip and recent Linux kernels.
Flash video
Zigbert recommended that .flv files need to have a file association so that Gxine will play them. At first I thought, no, Gxine cannot play a Flash Video, but this overview page has corrected me:
http://en.wikipedia.org/wiki/Flash_Video
Where to get some FLV files to play with? I found this:
http://www.mediacollege.com/adobe/flash/video/tutorial/example-flv.html
The required mime-type is 'video/x-flv', and I presume that zigbert has requested that this be setup so that Gxine plays when a .flv file is clicked on in ROX-Filer. But, if I try to open a .flv file in SeaMonkey, SeaMonkey does not know what to do with it either.
I got that mime-type after a bit of research on the Internet (also given in the wikipedia page), however ROX-Filer thinks the mime-type for .flv files is 'application/x-flash-video'.
To fix SeaMonkey (and Firefox and many other apps), I added entries to /etc/mailcap and /etc/mime.types (using video/x-flv mime-type).
To fix Rox, I created /root/Choices/MIME-types/application_x-flash-video.
Wallpaper Setter fixed
There was a bug report for 4.1alpha6 that Nathan's Wallpaper Setter does not work. I found the reason, the absence of 'fotox'. The image viewer is now named 'fotoxx'. I created a symlink, fotox to fotoxx, and that fixed the Wallpaper Setter.
Retirement, some thoughts
Timeline
Right now I'm going ahead full steam on 4.1, and will see that through to 4.1-final. if it turns out that we need another bug-fix release soon after, then I will definitely keep going to create 4.2. I may even feel motivated to do 4.2 anyway. Basically, I'm thinking of retirement at about the end of this year.
I have been offered work at the Perth Royal Show again this year, from 22nd September to 4th October, so will have much reduced input to the Puppy project in this interval. 4.1-final should be out before then, so there will be a lull anyway.
Not that I'm really going to retire of course -- I'm too darn enthused by Puppy, even after all these years. But, I'll be developing my puplet, at a slower pace and with less community interaction, just tinkering, doing my own thing.
There is one thing that I would like to see, that is the systems-level developer guys getting more direct control in what happens to Puppy. Up until now, everything gets channelled through me and I decided what's in and what's out, and I modify what others have done. There are those who have wanted more control so they forked their own projects, and Nathan's Grafpup and MU's Muppy are good examples -- those guys have a lot of initiative and also the dedication to create and manage their own distro.
But many other developer guys would prefer to remain part of the team. Besides, "Puppy Linux" is the distro that most people are drawn to, it has the name, the reputation, the widespread presence in the web and various publications. So staying and supporting the main Puppy Linux makes sense.
Guys we trust
I started to think of some of the core systems developers who I think should have more direct control of Puppy:
temptestuous
rerwin
kirk
Dougal
WhoDo
HairyWill
Raffy
UPDATE: John Murga
There are lots of other guys who are probably more on the application development side:
ttuuxx
economoney
disciple
plinej
zigbert
MU
pakt
...but some of those may also fall into the first category.
Those lists are not complete, just some names I thought of in about 5 minutes. They are guys who have been with us for some time so have proved themselves. We can trust them with the "keys" to Puppy. It's a starting point, more names can be suggested.
Of course there are some, like Raffy, who are probably more in the 'management' category rather than core-developer or application-developer.
Probably an SVN/CVS system, as has already been created for souceforge.org, would be what is needed for these guys to be able to have more direct control of Puppy.
This blog
One little implementation detail. I want to keep my blog going. This is primarily "Barry's blog" and will continue with news about my puplet and other stuff, perhaps some mainline Puppy Linux news too.
The problem with that though, is the URL, puppylinux.com/blog. If I change to another URL, that is going to break a lot of links, which I don't want to do. Perhaps if I give puppylinux.com domain to the puppylinux.org guys, they can put a redirect into puppylinux.com/blog to my new URL? -- can that be done in your Hostgator site?
These are just some thoughts. I have created a "Retirement" category in my blog, so that posts and comments can be viewed separately from the other "Puppy" and "General" categories.
Encrypted pup_save fixed
Forum member 'MattN' reported that 'heavy' encryption of the pup_save file does not work in 4.1alpha6.
Indeed it doesn't. It turns out that two kernel modules have had a name-change. aes.ko has become aes_generic.ko and blkcipher.ko has become crypto_blkcipher.ko. So, I have fixed it -- needed mods to 'init', 'rc.shutdown' and 'createpuppy' scripts.
Request for info: domain registrar
Anyone reading this who has a positive experience with a cheap domain name registrar that accepts PayPal?
I want to register another domain name, but my regular registrar, that I have been with for many years, has been gradually becoming too expensive. They want AU$19.95 per year for a .com domain (that's planetdomain.com.au).
I did a bit of a search and found this one:
http://www.cheapnames.com/
...very cheap.
Hotplug zip/ls120, /dev/hd* optical
I have now got nice hotplugging of the desktop icons. When I insert a LS120 or CD disc, the desktop icon appears. Eject it and the icon disappears.
For optical drives, this hotplugging was working, but only for /dev/sr* drives. I have now extended that support to /dev/hd* optical drives (the old IDE drivers, as used in the "conservative" kernel).
I found out how to detect if a LS120 diskette is inserted, but only when /proc/ide exists. That is, only when the old IDE driver is used, not the new PATA driver. I haven't tested on a Zip drive yet. This detection is only for internal IDE "floppy" drives.
Note, I can check /proc/partitions to see when a LS120/Zip inserted, but only if it has a partition. My test LS120 diskette is a "superfloppy", and my code examines /proc/ide/
LS120 support underway
I finally got around to installing a LS120 drive onto one of my PCs. I had the drive but no diskette, but otropogo kindly posted one to me.
The main problem, from the point of view of the desktop icons, is that insertion an removal of diskettes is not treated as a hotplug event by the kernel.
I had the same problem with the floppy drive, and could not find any fast/eficient code that would probe for an insterted diskette, without starting the motor. I think Jesse also tried to do this sometime ago. So I had to settle for keeping a floppy icon permanently on the desktop regardless whether a diskette is inserted or not.
It is more complicated for LS120 and Zip as these can have partitions, or could be super-floppies. So, we can't have a desktop icon named 'hdd4' for a zip drive before the diskette is actually inserted, as we don't know whether it is going to be 'hdd1', 'hdd4' or 'hdd' (superfloppy).
Right now I'm trying to find if there's any way to detect a LS120 or Zip disketter inserted, without starting the motor.
So, it's a work-in-progress...
Puppy 4.1alpha6 (406)
I had great difficulty uploading to ibiblio. gFTP crashed twice, the connection timed-out once, twice gFTP reported that the file upload was complete when in fact only part of the file was uploaded. Each time I selected to 'resume' and eventually got there. I downloaded the files afterward to confirm the md5sums. I have done this from my relative's high-speed ADSL2 connection.
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6/
Although mut has been fixed, there is still a bug in Pmount. You have to modify lines 55 and 56 of /usr/sbin/pmount to this:
PROBEPART='mut --noserv probepart' #v407
PROBEDISK='mut --noserv probedisk2' #v407
There are two iso files, and I think most people can use the "normal" one, 'puppy-4.1alpha6-seamonkey.iso'. For anyone with shutdown or modem problems, try 'puppy-4.1alpha6-uniproc-ide-conservative-seamonkey.iso'. However, you do need to be extremely careful of "cross pollution". This pollution problem also exists if you have tested one of the earlier version '406' iso files that I released recently for crash-testing.
The cross pollution problem is that when you save a pup_save to hard drive, pup_406.sfs is also saved to hard drive. Later testing a variant of Puppy with the same '406' version number, Puppy will find the older pup_406.sfs file and use that. This has caught me out a couple of times tonight, so beware. Best if you boot with 'pfix=ram', and if you do want to use a pup_save, first look at the hard drive partitions to make sure there is no older pup_406.sfs.
You may also run into cross pollution with the pup_save file, if testing multiple variants with the same version number. Either create a fresh pup_save for each one, or boot with 'pfix=clean'.
I would like to determine if we really do need two completely separate builds. As has been discussed recently in this blog, it may turn out that something simple like disabling "tickless" in our normal kernel build will fix some modem problems ...I don't know, just guessing.
I have been asked recently, what are the main new features of 4.1 compared with 4.00? That has prompted me to put together a preliminary release announcement for 4.1:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6/release-4.1.htm
If you want to boot from a SCSI hard drive, see recent blog posts, also a link in the above release announcement page. You need one of these SCSI kernels:
http://puptrix.org/sources/kernel-2.6.25.15/scsi/
However, do note that the compatible set of modules are in the pup_406.sfs and initrd.gz of the "normal" live-CD, not in the "conservative" build.
Mut2, slmodem fixes
Jesse has tracked down the bug in mut and posted an update. Thread here:
http://www.murga-linux.com/puppy/viewtopic.php?t=32028
Rerwin posted various modem patches, including patches to /etc/init.d/slmodem in the Smartlink "firmware tarball". I reported in my previous post that I had to roll that script back, but it turns out that I did not implement rerwin's changes completetely. The problem was that rerwin posted the fixes here:
http://murga-linux.com/puppy/viewtopic.php?t=31931&start=90
but was not able to upload the firmware tarballs. I implemented the changes from the new slmodem script and the diff files, but did not examine the slmodem script closely enough to realise that two symlinks are required -- I have now put those in.
Today I was winding things up, to get 4.1alpha6 out. I have put in the above two fixes and will upload soon.
Conservative kernel, modem fixes
I have compiled the "conservative" kernel and all 3rd-party modules and put it into Unleashed. This is for experimenting. We have a problem with one or more modem drivers with our latest kernel, so we shall find out if the conservative kernel fixes them. It may just be the tickless option though, in which case could go back to one kernel, with SMP enabled and tickless disabled. Anyway, we will narrow the problem down.
Unfortunately the latest /etc/init.d/slmodem script failed to detect my on-board ALSA modem so /dev/modem did not get set. So, I rolled back to the script from alpha5, which works.
In 4.1alpha5 it was reported that the 'Stupid Mode' checkbox setting in PupDial could not be saved. Fixed.
Extra drivers compiled
Ok, I have compiled all of rerwin's extra drivers and put them into Puppy, with firmware where required.
Tonight I want to go through the entire exercise again, recompile the kernel and all 3rd-party drivers, this time with the "conservative" kernel.
Today I tested the Lucent modem on my Dad's laptop... not so good. Got strange error messages with the Martian driver. The Lucent ltserial module is blacklisted in 4.1alpha5, so I un-blacklisted and tested it -- great, Puppy was able to communicate with it (now at /dev/ttySLTM0) and get a init string, but when I chose to dialout, Puppy froze.
I wonder if the conservative kernel will fix that ...I think that rerwin indicated that might do it.
Extra drivers
Tempestuous has found extra drivers, that were compiled and tested in 4.1alpha5. Tempestuous has now collected the source packages together, with compile instructions, and I have uploaded them to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/new-drivers-Aug13-2008/
Note that I am planning to build a "conservative" alternative kernel for 4.1, see my previous blog post:
http://puppylinux.com/blog/?viewDetailed=00290
Trash
I have upgraded to disciple's latest improvement of the trashcan application, dated 9th August.
Pburn, Pmusic, Psip updated
These are Puppy in-house projects...
Pburn, CD/DVD burner app., upgraded to 1.9.8.
Pmusic audio player, upgraded to 0.2.0.
Psip VOIP + IM client, upgraded to 0.12.
Reckon I'll have a cup of coffee tonight and work late, try and knock this pup into shape and get alpha6 out. Tomorrow I'm going to my Dad's place to test Puppy on his PCs. One of his laptops (Thinkpad) has a Lucent modem and I want to find out what is going on with the Martian driver -- rerwin has reported some problems with it, that seem to be related to the kernel.
Mut has a showstopper bug, that Jesse is working on.
I'll plough through all the remaining bug reports for alpha5, maybe even fix some of them.
So, alpha6 is still another day or two away.
Ayttm updated
Siddhesh is continuing to rapidly improve Ayttm, our light-weight multi-protocol chat client alternative to Pidgin.
I have compiled the latest from CVS, version 0.5.0-72.
SCSI and IDE kernels
I have compiled the SCSI1, SCSI2, SCSI3 and IDE variants of the 2.6.25.15 kernel.
The "IDE" variant uses the older IDE drivers instead of the PATA drivers, and the device nodes are /dev/hd*.
All source files uploaded to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/
Modem fixes
Rerwin has tested 4.1alpha5 and applied some fixes for the modem scripts.
I changed the goal-posts with 4.1, removing auto-probing of serial modems, and rerwin has very patiently examined the latests scripts and tested on various modems, and devised new patches. In particular, a problem with the 'modemprobe' script has been solved.
Rerwin also has some patches for the 'init.d' scripts, but I have only partially applied these. A couple of things that I do not want to do -- automatic deletion of a devnode and of /dev/modem. I do not want boot scripts to delete /dev/modem under any circumstances. I would rather leave it up to PupDial to make any devnode and /dev/modem corrections. Basically, I want the setting to stay in-place regardless whether the modem is present or not, and any change has to be done by running PupDial.
ndiswrapper updated
Ndiswrapper enables Puppy to use MS Windows wireless drivers. I have upgraded to version 1.53. This includes a module for the 2.6.25.15 kernel and "userland" executables.
ntfs-3g updated
I have upgraded to version 1.2712. This has some important bug fixes. If you have trouble with Puppy using your NTFS partition, this may have fixed it. This will be in 4.1alpha6, due out in a few days.
2.6.25.15 kernel
I have patched and compiled this kernel, plus all the 3rd-party modules.
I did start off trying to compile the 2.6.26.2 kernel, however the lzma patch and one of Lloyd's Multitech patches failed. As dogone said, the temptation is to put one's hand into the lolly jar, but in this case I got stopped right at the start. I then decided to back off from the bleeding edge.
This kernel has the patches as before: loglevel, squashfs, unionfs, aufs, lzma and multitech-gprs (in total, 10 patches).
All source files uploaded to Ted Dog's repo:
http://puptrix.org/sources/kernel-2.6.25.15/
I have not yet compiled the SCSI and IDE kernels. I first want to bring out 4.1alpha6 and make sure that the kernel is basically ok, then I will compile the other variants. Temptestuous also will have to recompile the extra modules that he created for the 2.6.25.11 kernel -- thanks for your patience on that, tempestuous.
nosmp, font size, slusb delay
I have added the "nosmp" boot parameter as default, into 'createpuppy' and 'puppyinstaller' scripts.
Kj reported that changing the global font size does not work. I just tried it, works fine for me.
Rerwin reported a problem with the /etc/init.d/slmodem script running before the 'slusb' module has properly loaded, I presume that is causing a failure of the 'slmodemd' daemon. Rerwin fixed it with a 'sleep 3' at the beginning of the script.
I don't have anything better at this stage. rc.network and rc.services both run as separate parallel processes launched from rc.sysinit. rc.network does have a method of waiting for network interfaces to become available, but I can't think how to do it for the modems. So, for now I have just applied the very gross fix of a 'sleep 3' at the beginning of rc.services. That does not slow down bootup speed at all, that is, the time taken for the desktop to appear.
I do have a thought how I might be able to apply a more accurate wait for the modem interfaces to become ready, but I'm not sure so will put that one on hold until sometime later.
Optical drive now released
4.1-testers reported that when upgrading from an earlier pup_save file, the CD/DVD drive remained mounted.
This is actually a bug from 4.00. When you boot Puppy from CD for the very first time, or boot with "pfix=ram", at shutdown you are asked if you want to copy the 'pup_xxx.sfs' file from CD to the same place as the pup_save file, and normally you would reply yes. Then at next bootup Puppy will find the pup_xxx.sfs file on the hard drive and use that.
However, when upgrading a pup_save, the CD has a later pup_xxx.sfs file, let's say 'pup_406.sfs' and this is only on the CD. If Puppy decides not to copy it to RAM then it is mounted from where it is, thus leaving the optical drive mounted.
I have fixed this. The 'init' script detects this situation and copies the pup_xxx.sfs to the same place as the pup_save, thus freeing up the optical drive.
Floppy desktop icon fixed
In 4.1alpha5, if you clicked on the floppy drive icon, it mounted okay, but if you then unmounted it, the icon stayed with the "green ball" indicating it to still be mounted. Fixed.
Wind generator tower, stage 2
Heh heh, here it is:
Put together from water pipe that I had lying around. Four pipes up to about halfway, then three pipes all the way up to 5.5 metres above ground. The turbine itself will be about 6.5 metres above ground.
The individual pipes are not strong, but they will be strapped together. I might use predrilled galvanised steel strap and tek screws. I might also put in guy wires to about halfway, just in case.
The wind generator kit has its own tower with hinged base and that will be used. The idea is, it will be hinged at just above the level of the shed roof, so I can assemble the wind generator on the roof, then rotate it up vertically! A pulley mounted on the top of the pipes will be used for winching. Alternatively, 3 or 4 blokes could probably lift it up. After it is vertical, some bolts can go through the pipes to lock it all together.
The basic idea is that it is serviceable. I can winch it down at any time, without having to hire a crane.
My original "stage 1" post:
http://puppylinux.com/blog/?viewDetailed=00070
Fotoxx upgraded
Fotoxx (previously called Fotox) upgraded to version 5.0.1. Among other things, it now has a full-screen slide-show mode. Fotoxx no longer has a PDF User Manual, it is now HTML and uses 'xdg-open' to find the most appropriate viewer.
Have created /usr/local/bin/xdg-open as a symlink to /usr/local/bin/defaulthandler.
New source repo for Puppy
Forum member cb88 is to be congratulated on this initiative:
http://murga-linux.com/puppy/viewtopic.php?t=32215
Mountain bike electric conversion
I am thinking of transferring the electrics from my electric bike to my new mountain bike -- a very interesting project, I reckon!
The electric bike is an el-cheapo from Kmart, AU$399, that I purchased about a year ago. In Australia, a power-assisted bicycle can be a maximum of 200 watts. Same in the UK. The European Union has settled on 250 watts.
The motor on my bike has a "200 watt" sticker on it, but I think it's the same one as the top pics at this site:
http://www.users.bigpond.com/solarbbq/cheapdiybike.htm
(the motor with the ribbing around the circumference)
That does 250 watts. I have read that the Chinese manufacturer just puts the appropriate sticker on it as per the target Government legislation requirements.
Anyway, what has intrigued me about that above url is the option of mounting the motor at the other end, that is, onto one of the sprockets at the human-driven-pedals-end. On my electric bike, the motor is mounted beside the rear wheel, with a small chain driving the real wheel, on the opposite side to the derailleur gears. Moving the motor to the front is an interesting alternative, but note the author's negative comments near the bottom of the page.
'nosmp' boot parameter
Well, we have lobbed the ball back into Lobster's court. Lobster, can you grab a 4.1alpha5 live-CD and boot it with 'puppy nosmp pfix=ram' -- if that runs stable then we have the best solution.
Next: choose a kernel
Lobster has reported the non-SMP kernel works, so unless he gives an update that it crashed a bit later, it looks like we will have to stay with the uniprocessor kernel for Puppy. The problem is, I can't just provide an alternative SMP kernel, as all the modules have to be recompiled also -- so I would have to provide two ISO live-CD files to cater for both groups.
For now I am tending toward staying with the 2.6.25.x series, but the 2.6.26.x sure looks interesting:
http://kernelnewbies.org/LinuxChanges
Special test Puppy for Lobster
Here it is, the file is 'puppy-406-unicpu-crashtestonly.iso':
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6-temp/
This is not for general testing, has a few things missing. Lobster, start it with the usual 'puppy pfix=ram'.
SMP kernel the problem?
I suddenly had a thought. Perhaps the lockup problem experienced by Lobster and one or two other testers is due to the SMP kernel. The 2.6.21.7 kernel in 4.00 is configured as a "uniprocessor kernel", it is only when I went up to the 2.6.23 and later that I configured for multiprocessor (SMP) kernel.
Note that the reason I was somewhat slow to move up to a SMP kernel is that the docs supplied with the kernel source state that it may not work on all uniprocessor systems. Perhaps Lobster is one of those unlucky ones.
So, I have compiled a 2.6.25.14 uniprocessor kernel, but found that none of the previous modules work -- too much of a fundamental change to the kernel architecture. So rigt now I'm recompiling the modules.
So Lobster, if you will be so kind as to help out yet again, I'll upload another Puppy soon, with the uniprocessor kernel, and you can find out if that locks up.
2.6.26.x
The latest 2.6.25.15 and 2.6.26.2 were released at the same time, and their changelogs are identical. So, it looks like bug fixes are getting applied to both. Even so, the 2.6.26.x series has architectural differences from the 2.6.25.x series and should be considered as less mature. But then, some Puppy-enthusiasts are keen on the new OLPC support in 2.6.26.x.
We shall see, firstly, let's find out if the SMP-enabled kernel is the cause of our troubles.
My new bike
I'm going green! Just bought myself a bike. No, staring at that guy-on-the-bike in the Aussie Outback did not have a subliminal affect on me, the interest was there from before. Here's my new bike:
I own an electric bicycle, purchased from K-Mart, but I never ride it. The main reason is that I find it to be very uncomfortable -- I have a degenerated back, the lowest vertebra easily gets out of position and pinches the nerves -- then I'm in trouble. The road outside my place is gravel, unpaved, and a normal bike is just too hard on my back.
So, for sometime I reckoned what I need is a dual-suspension mountain bike, but they are too expensive. Then yesterday -- now don't laugh -- I happened to be in Toys-R-Us and found a boys 24-inch dual-suspension mountain bike, for just AU$69.99, discounted from AU$169.99. Yay, that's in my price bracket! So I bought it.
It's a delight to ride on the gravel roads here, except for the hard saddle. No problem that it's a "boys" bike, as the seat and handlebars are fully adjustable to suit my height. Besides, I prefer the slightly smaller wheels as it just fits inside my car.
I looked online at what's available in wide comfy saddles -- some of them cost more than my bike!
Man oh man, this thing has 18-speed gears! All I need is slow, medium, fast. Anyone reading this who is into bicycles? -- is it easy to modify/simplify the gears?
Guy on a bike
For you guys who read this blog and haven't tested 4.1alpha5 and are wondering about our reference to the "guy on a bike", it's the background image used in alpha5, and here it is:
This is somewhere in the vast Australian Outback, I don't know specifically where, nor do I know who the person is. Ted Dog suggested it is Gilligan.
2.6.25.14 crash test
Ok, I have patched and compiled the 2.6.25.14 kernel and built Puppy with it. The only third-party drivers included are squashfs, unionfs and aufs.
The purpose of this built is to do a crash-test. Those people who have tested an earlier 4.1 alpha and it locked up, please give this one a go. Two or three people I think, are in this category, who were testing 4.1alpha5. For example, Lobster.
I have set this build to version number '406', as I think some earlier testing is giving inaccurate results due to conflicts with earlier builds. For example, you tested '405' (4.1alpah5) with the normal PATA kernel, then later the variant with the "IDE kernel", it is possible that either the previous pup_save or the pup_405.sfs may have interfered -- as the pup_405.sfs may have got copied to hd when the pup_save was created.
Upping the version number fixes the problem of Puppy finding and using an old pup_406.sfs, but still, be sure to boot with 'puppy pfix=ram' so as not to use an old pup_save file.
Anyway guys, if you are in the "it crashes" category, kindly give this one a go. If still no good, I do have one more card up my sleeve, and will build another kernel -- I'll try the .config file from one of the othe distros, such as Slackware.
Get the 2.6.25.14 crash-test Puppy from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha6-temp/
2.6.25.14 kernel
2.6.21.7
Last night I recompiled the 2.6.21.7 kernel, had to do that to enable the new PCMCIA mechanism. Most of the old modules still work, just had to substitute the newly-compiled PCMCIA-bridge modules (like yenta_socket). Also had to compile the 1.0.16 ALSA drivers, as the 2.6.21.7 kernel had the 1.0.14 drivers. Also needed the squashfs 3.3 module, as the original patched kernel source has a 3.2 patch.
But, testing it, there is some kind of incompatibility. Plugging and unplugging a PCMCIA card did not generate any hotplug uevents.
So, that one is on hold.
4.1alpha5 feedback
I have just read through all the bug reports, to get an overall impression of the major problems. There is a problem with locking up -- for example, Lobster reporting the USB mouse and the system freezing after a few minutes.
Curious, that time variability, so I did some reading of changelogs...
2.6.25.12-14
Now that is interesting -- the changelog for 2.6.25.12 fixes a USB-related bug that causes "random lockups", due to shared interrupts conflicting. This is only on some hardware.
I am quite surprised (and alarmed) at how rapidly the updates are appearing for the 2.6.25.x series. The latest is 2.6.25.14.
It is Tuesday 8.55am right now. I am away from home, will drive home this afternoon and this evening build a new kernel, using 2.6.25.14 -- unless there is yet another release in the meantime!
I will build Puppy with that and you guys with crashing/lockup problem can try it out. I will do it quickly, so it will not have all the 3rd party drivers.
2.6.21.7 kernel for 4.1
Feedback so far on the 2.6.25.11 "IDE kernel" doesn't show any particular advantage.
However, there is no reason why I can't release 4.1 with the 2.6.21.7 kernel, same as used in 4.00.
Will have to release two flavours, the main one will have the 2.6.25.11 kernel, and for people who experience trouble with that can use the alternative build with 2.6.21.7 kernel.
Not very satisfactory is it? The amount of time that we spend trying to fix things because of the changing kernel.... stop Barry, don't get going on that!
"IDE kernel"
Some people testing 4.1alpha5 have reported bootup/instability/shutdown problems. I want to find out if any of this is related to the PATA drivers. Lobster for example, reports that it hangs after a few minutes use -- I don't see how that is anything to do with the hard drive driver, but you never know.
So, if Puppy 4.00 worked for you but 4.1alpha has this kind of problem, try this new build with "IDE kernel" -- this has the older IDE drivers instead of the PATA drivers. Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha5/
It is named 'puppy-4.0.5-ide_kernel.iso'
Conversely, if 4.1alpha1 did work for you, we should find out if this IDE kernel does too. Otherwise, we might solve someone's problem but create one for someone else.
If you have tested alpha5 already, it would be best to boot this new one with 'pfix=ram' to avoid any conflict, or if you have a pup_save file then boot with 'pfix=clean' to simulate a version upgrade.
Testing Xfprot
There was a report that clicking the close-box prior to downloading the F-prot antivirus signature package, it went ahead anyway. Fixed.
There was another report, from otropogo, that after downloading, it did not work:
http://murga-linux.com/puppy/viewtopic.php?t=32076
Fixed that too.
xine-lib
As ffmpeg has been upgraded, it is wise also to upgrade xine. I will get onto upgrading the apps that are dependent on xine-lib, but for now, have just upgraded xine-lib, to version 1.1.14. Here are my notes:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --with-external-ffmpeg --disable-dxr3 --disable-glu --disable-gnomevfs --disable-samba --enable-antialiasing --without-xcb --without-sdl --without-imagemagick --with-freetype --with-fontconfig --without-esound --without-jack --with-libflac
had to copy postprocess.h and avcodec.h from src pkg to /usr/include/...
# make
# new2dir make install
Note, Puppy 4.00 achieved the best-yet video and audio support, but I thought why not go just a bit better? So, the aim of 4.1 will be a new peak of audio/video performance built-in, nothing to add.
faac, faad, x264, xvidcore, ffmpeg
I have been inspired by plinej, who has recently been through this exercise. Earlier, there have been requests to support faac, faad, x264 and xvidcore codecs, so here it is -- these are all dependencies of ffmpeg.
For the record, here are my compile notes:
faac-1.26
----------------------
# ./bootstrap
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
# new2dir make install
faad2-2.6.1
-------------
# ./bootstrap
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
# new2dir make install
yasm-0.7.1
--------------
x264 needs this to compile.
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --build=i486-t2-linux-gnu --disable-python --disable-debug
# make
# new2dir make install
x264-20080731-2245
---------------------------
tricky, installs to /usr/local, have edited 'configure', changed prefix='/usr'
# ./configure --enable-gtk --enable-shared --host=i486-t2-linux-gnu
# make
# new2dir make install
...note, the executables got linked statically with the libx264 library, so have removed them from the PET package, just kept the shared lib as that is what ffmpeg needs.
xvidcore-1.1.3
------------------
# cd build/generic
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu
# make
need some trickery...
# cd ..
# ln -s generic xvidcore-1.1.3
# cd xvidcore-1.1.3
# new2dir make install
now we have all the dependencies....
ffmpeg-20080731
----------------------
problem, needs a utility called 'pr' -- I got it out of coreutils, put permanently into Puppy.
problem, busybox 'od' utility, missing option '-A' -- coreutils again, permanently into Puppy.
# ./configure --prefix=/usr --cpu=i486 --enable-libmp3lame --enable-liba52 --enable-libxvid --enable-libx264 --enable-libfaac --enable-libfaad --enable-pthreads --enable-small --enable-libvorbis --enable-gpl --enable-shared --disable-static --enable-swscale --enable-postproc --disable-debug
# make
# new2dir make install
Retirement pre-announcement
From the Puppy project, that is. I have been thinking about this for sometime, it is just a question of when.
I had previously hinted that I would do so early in 2010, however I will probably bring that forward.
Reasons for retiring earlier
One of them is that I would like to move to developing an application, in particular I am interested in porting my EVE vector editor to Linux, running with one of the native GUI libraries such as GTK.
Also, I would like to do other things. The Puppy Project takes up all my time, I don't even have a part-time job anymore so income is too low. I intend to do some regular part-time work and make more time for other activities that I keep postponing.
Being "Commander in Chief" of the Puppy Project is something that I have never been comfortable with.
Implementation
I will register another domain name for my site, and most likely hand over puppylinux.com for the guys who currently run puppylinux.org to also manage. I say "most likely" because this is undecided.
I will keep playing with a Puppy-derivative, with a different name. This will not be designed to work with a huge range of hardware necessarily, it will just be something that I tinker with sometimes. It will have a different name.
I may even focus on a niche derivative that runs optimised on one of the baby laptops, as some other Puppy-enthusiasts are doing.
I will probably turn over the keys to the ibiblio.org download site. I do not yet know who will get that responsibility.
Timeline
I am not going to suddenly pull out. That is why I am posting this advance notice, so that everyone knows it is is going to happen. Also, it is an opportunity if someone wants to advise me how best to streamline the transition (preferably by forum PM).
I certainly intend to keep going full-steam on version 4.1. It is shaping up well.
I will give a ball-park retirement date probably in a month or two.
IDE kernel
I have recompiled the 2.6.25.11 kernel with support for /proc/ide and /dev/hd* drives. Using it right now.
To reiterate the background on this, the 2.6 kernel has new drivers called PATA drivers for the IDE internal drives in a PC. The main difference from the older IDE drivers is that they use a SCSI-emulation layer and all drive device nodes are /dev/sd* for hard drives, /dev/sr* for optical drives. This is identical naming to other drives that use the SCSI-emulation layer, USB and SATA, as well as real SCSI drives.
The old notion of distinguishing IDE drives by their /dev/hd* device node name is gone, but then it is nice that all optical drives have the same /dev/sr* naming.
Anyway, I thought that the PATA support in the 2.6.25.11 kernel had matured enough and finally we could use it. The Puppy 4.1 alpha series has used this new PATA system, and it seems fine on all the PCs that I have tested on. However, some Puppy-testers do have some mysterious problems, such as Lobster reporting Puppy seizing up after a few minutes on one PC. Also some shutdown issues. Now, it could be that these are due to something else in this new kernel, but we need to go through a process of elimination.
Hence, I have recompiled the kernel with PATA drivers tuned off and the old IDE drivers turned on. In both cases these drivers are built-in to the kernel, not modules, and testing the "IDE kernel" so far all the old modules still work -- in other words, all the current modules and those compiled by tempestuous and anyone else for the 2.6.25.11 kernel should still work.
I am going to upload Puppy 4.1alpha5-with-IDE-kernel tomorrow, and would appreciate if everyone who has tested earlier 4.1's could also give this one a spin. I think everyone should be in this -- after all, if Lobster finds that it fixes his PC, but someone else who previously had no trouble suddenly finds trouble with the IDE kernel, then it's a case of one step forward and one step back.
I will upload tomorrow, approx. 24 hours from now, as have to fix a couple of scripts that I wrote assuming the new PATA devnode naming. Also, I'll be back in Perth, with fast ADSL2 access.
Note, I have added this IDE kernel to the others in Unleashed, so Puppy can be built with quite a choice now.
Unionfs 2.4 released
The Unionfs developers have just released a major upgrade. They have also admitted ignoring bug reports for version 2.3.3 for the last three months.
It is very nice to have a brand new version, except that in the meantime they have lost more customers, including us.
I may reconsider Unionfs again sometime, but I'm not going to rush in now and patch and recompile the kernel.
SCSI booting works!
Forum member Sit Heal Speak is dancing in the clouds right now, as he has got Puppy booting off a SCSI drive:
http://murga-linux.com/puppy/viewtopic.php?t=31930
All it needed was the kernel compiled with drivers built-in, and we are now in business!
And I haven't even put my own SCSI hardware together yet. Sit Heal Speak has mentioned a couple of little oddities, so perhaps a little howto on the puppylinux.org wiki would be good. Especially for me, some notes about gotchas and oddities to watch out for would be helpful.
Gtklogfileviewer removed
While I'm on the attack, I will add this one. I had a problem with this utility not working correctly, also there have been reports on the forum. I reported this to MU and he did ask me to supply more details about my particular problem (the newly-appended lines were not displaying properly) but I don't have that info anymore. MU thought that certain characters in the file may have been upsetting gtklogfileviewer -- probably that is the case. As I recall though, it was a pretty ordinary plain text file -- and at the time I fell back to using 'tail -f' which worked perfectly.
Anyway, I have to move on, and have fixed it the quickest way that I can. I have removed it and wrote a simple script using Xdialog that completely replaces gtklogfileviewer -- this is needed, as Pburn uses it.
Pburn does not work
This is so frustrating... why, whenever I test Pburn, it does not work correctly? This is version 1.9.6.
I selected a directory that I wanted to archive, which showed "Minimum disk size: 1294Mb". I clicked "Burn" button then chose DVD, on-the-fly, close session (note, starting Pburn afterward, it does remember those settings, but not the "DVD" selection -- goes back to "CD" -- with gtkdialog3 you have to reorder the list with the default one at the top).
However, it was unable to burn to my DVD-R, came up with a window:
"Unknown error -- see log for further information"
What log? There is nothing anywhere for opening any log file.
However, I had run pburn from a terminal, so I was able to see error messages, and there were heaps of them, mostly looking like this:
/usr/local/pburn/func_build_command: line 3: /root/.pburn/tmp/pburn-exec: No space left on device
...which makes no sense at all, as there is plenty of space. Believe me, in all respects, RAM, partititons, tmpfs's, there is plenty of space.
I looked in /root/.pburn, 'du' shows it has 64MB of stuff in there ...yikes! I am doing on-the-fly burning, so it's all heaps and heaps of symlinks. Anyway, the filesystem that /root is in is far from full -- it's the pup_save file and has 240MB free.
Note, if I chose a smaller directory, it does work. The directory that I wanted to burn, 'du' shows it to occupy 1566MB, which Pburn estimates needs media space on the DVD of 1294MB. Whatever, there should not be any problem with burning that on-the-fly.
Changing the subject, but only slightly, earlier I was using Pfind and Pfilesearch hung on me. I was running that from a terminal and did CTRL-C to kill it, but that left a couple of processes running, and had to use 'kill' on those. I rebooted after that, so that problem has no relationship with the Pburn problem.
Changing back to DVD-burning, I have a regular need to burn directores to DVD, and it is so darn simple to do, basically just one line. For my own use anyway, I am going to be forced to write a little GUI for doing that one job, just so that I have confidence that it is going to work right.
I am sorry to be so harsh, but this as been an ongoing thing, and I have been expecting Pburn to have reached the stage of extreme reliability. I don't care about the bells and whistles that keep getting added, I just want it to work.
UDF filesystem
In earlier puppies, the UFS filesystem was not supported. The ufs.ko module was screened out as too "exotic" by the createpuppy script in Unleashed. As there is demand for UFS, it is now in 4.1alpha5.
However, Alex has now complained that the UDF filesystem is also screened out as "too exotic and unlikely to be used", but it is needed.
So, I have now allowed udf.ko and that will be in 4.1alpha6.
Geany scrolls past end of file
The version of Geany in 4.1alpha5 is 0.13 and it has a feature that annoys me so much, I reported it to the Geany bugzilla as a bug. It is the feature that Geany will scroll an entire window past the last line.
The author responded (and closed the bug):
You can easily disable by setting the hidden preference
"scroll_stop_at_last_line" to true.
For details, see the documentation at
http://geany.uvena.de/manual/index.html#hidden-preferences.
This is also mentioned in the FAQs,
http://geany.uvena.de/Documentation/FAQ#QQuestions8.
So, how do we disable this permanently? Unless the majority actually like this feature!
I also made a suggestion about navigating wrapped lines:
http://sourceforge.net/tracker/index.php?func=detail&aid=2030918&group_id=153444&atid=787794
...but the author didn't think much of it.
Ayttm launch fix
GeoW reported that starting Ayttm from the desktop 'chat' icon is different from when started from the menu. In the latter case, it does an auto-login to IRC #puppylinux, a script courtesy of Wolf Pup.
I have changed the 'chat' icon to also run the auto-login script.
Puppy 4.1alpha5
I have uploaded this to:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha5/
The background photo is the Australian "outback" and the guy on the bike is not me! (looks like a great way for a relaxed holiday, hey -- and environmentally friendly)
Fix for USB analog modems
There is a problem that has been discussed here:
http://murga-linux.com/puppy/viewtopic.php?t=29291
What I have done is followed the advice in the forum thread and created symlinks of /dev/ttyUSB0 to /dev/usb/ttyUSB0. Also for /dev/ttyUSB1.
Then I went through the relevant "firmware tarballs" packages (well, that's only the pl2303 pkg, isn't it?) and changed the symlink /dev/modem to /dev/ttyUSB0.
Then I noticed that the 'cdcacm' firmware package has the same problem, with /dev/modem a link to /dev/input/ttyACM0, so I have employed the same solution.
In fact, we probably don't need symlinks, could just move those devnodes out of /dev/usb and /dev/input.
Psip upgraded
Now at version 0.11, which has a better layout for smaller screens.
Network Wizard upgraded
I have tested Dougal's improved Network Wizard, dated July 28th, and it is looking real good. It fixes some serious problem areas in the old Wizard.
For building Puppy in Unleashed, I made it into a PET package named 'net_setup-20080728'. I took out the rc.network script and put that in the 'rootfs_skeleton-405' package.
The only change that I made in the scripts is the clash with Debian/Ubuntu directories and files in /etc. We do need to think ahead that we may want to put in other Debian/Ubuntu packages (of which Pppoeconf is one), maybe also in the case of the forgotten "underdog" layer f.s. configuration.
I could not think of elegant names to change /etc/network and /etc/wireless to, so just used /etc/wizard_network and /etc/wizard_wireless. That can of course be changed.
I have still got some stuff to do. probably 4.1alpha5 is about 24 hours away.
Ayttm upgraded
Now at version 0.5.0-62.
Pfind
I have upgraded Zigbert's Pfind from version 3.4 to 4.1.
Why do I bother?
Why do I even bother to request feedback?
Someone posted that they would like to test Pppoeconf, so I uploaded a tarball. No feedback.
A couple of people complained about no sound in Aspire One and Eeepc so I post responses asking for feedback, no response:
http://murga-linux.com/puppy/viewtopic.php?search_id=2112803361&t=31298&start=15
http://murga-linux.com/puppy/viewtopic.php?search_id=2112803361&t=31669
SCSI kernels uploaded
As announced recently, I have compiled three kernels with different sets of SCSI drivers built-in. Today I recompiled the 'SCSI3' kernel, reducing the selection as it overlapped what is in the 'SCSI2' kernel.
Get them from here:
http://puptrix.org/sources/kernel-2.6.25.11/scsi/
PPLOG fix
I noticed that a link does not work when PPLOG is run. When you start PPLOG in 4.1alpha4, there is a first-post made by me which contains a welcome message plus some web links. It also has a link to a local 'hiawatha.htm' manual page, except that the link does not work. I have edited the page so it now looks like this and the link works:
Puppy has local documentation on Hiawatha here (note: actual location is /root/httpd/hiawatha/hiawatha.htm):
http://127.0.0.1/hiawatha.htm
Note, I moved 'hiawatha.htm' from /usr/share/doc, as Hiawatha cannot "see" files outside its webrootdir.
Home page updated
When the web browser is first started, it comes up with a home page, located at /usr/share/doc/home.htm, titled "Puppy's jumping off page".
A couple of links in this page are getting a bit dated. There was a link to the wikka latest news, which I have updated to
http://www.puppylinux.org/home/latest-news
There was a link to video tutorials at rhinoweb.org, but my understanding is that this has become outdated, so I have changed to the User Manuals:
http://www.puppylinux.org/manual
I left in Lobster's slideshow intro., as that is amusing.
Improving Network Wizard
I have just started to look at Dougal's improvements to the Network Wizard. I have come to a stop for now as there are a few issues.
1. /etc/network/interfaces
This one is easily fixable.
Dougal would not have know about this problem, as it is so recent. I recently modified the Pppoeconf package to give it some infrastructure so that hopefully it will work. This infrastructure is directories and files out of Ubuntu. One of those is a file /etc/network/interfaces, which clashes with what Dougal has created.
An extra note, the Pppoeconf package also has directory /etc/wpa_supplicant, with a couple of files in it that the pppoeconf script uses.
2. sleep 10
The boot scripts in 4.1alpha4 avoid the need for big sleeps. In the case of rc.network, it has this code in the same place where the 'sleep 10' is located in Dougal's rc.network:
#v403 wait for interfaces...
echo -n "Waiting for interfaces... "
sleep 2
YAFPID="";RETYAF=1
WAITCNT=2
INTERFACES="";WANTINTS=""
CHECKINTS="`ls -1 /etc/*[0-9]mode 2>/dev/null`" #ex: eth0mode, wlan0mode.
[ "$CHECKINTS" != "" ] && WANTINTS="`echo "$CHECKINTS" | sed -e 's%/etc/%%' | sed -e 's%mode%%'`"
for WANTONE in $WANTINTS
do
while [ $WAITCNT -lt 12 ];do
if [ $RETYAF -ne 0 ];then # -a $WAITCNT -gt 4
/usr/X11R7/bin/yaf-splash -display :0 -font "8x16" -outline 0 -margin 4 -bg orange -placement top -text "Negotiating network connection. Blinky will appear in tray if successful" &
RETYAF=$?
YAFPID=$!
fi
INTERFACES=" `ifconfig -a | grep 'Link encap:Ethernet' | cut -f 1 -d ' '`"
[ "`echo $INTERFACES | grep "$WANTONE"`" != "" ] && break
echo -n "$WAITCNT "
WAITCNT=`expr $WAITCNT + 2`
sleep 2
done
done
3. lsusb, lspci
Pup 4.1 does not have lsusb, that Dougal uses in net-setup.sh. 4.1 does have lspci but does not have /usr/share/pci-usb-pcmcia.ids.
4.1 does not have any '.ids' files, as I consider them to be redundant, not worth the space they take up, due to the amount of information packed into 2.6-kernel modules.
Event Manager tweaks
There was a little bug, when the choice was made to not show any drive icons on the desktop (just a single 'drives' icon to represent everything), the optical drive icon still showed up. Fixed.
I have been testing the checkboxes in the Event Manager. I was prompted to look at this as a couple of people reported that it is complicated to use. I carefully studied it, and actually it is all dead-simple. Perhaps the desktop icon 'handler' tab could have some clearer explanation, so I have made it a bit more wordy.
I also added a "Desktop drive icons manager" into the "Desktop" menu, which launches a cutdown version of the Event manager, only showing what is related to management of the desktop drive icons. Although it was unnecessary to dumb it down that much.
Now, launched from the Desktop, the drive icons manager looks like this:
...note the 'Legacy' tab. That is to manage the floppy disk icon ...I know it annoys sage.
Acpitool
hey, isn't this just crying out to have a GUI frontend made for it?!
http://freeunix.dyndns.org:8088/site2/acpitool.shtml
muggins found acpitool, and posted a PET to the forum:
http://murga-linux.com/puppy/viewtopic.php?t=31753
4.1alpha5 checklist
I am planning to upload this in a couple of days. There will still be more things to fix, but I have made up a shortlist of things to do before the upload:
1. Look at Dougal's latest Network Wizard.
2. Examine some issues with Pmount not refreshing.
3. A bit more thought on copy-to-ram of pup_xxx.sfs.
4. xse or xautomation to raise/lower Pmount when click icons?
5. Check PETget package downloading.
6. Recompile scsi3 kernel -- had some drivers already in scsi1 and scsi2.
7. GeorgeR reported that his USB keyboard does not work when there are multiple 'pup_save' files to choose from at bootup. I cannot reproduce that bug, but I'll try my USB keyboard on a couple more PCs.
Internet Connection Wizard
This is what runs when you click the 'connect' icon on the desktop.
I am trying to add more useful functionality to it, without cluttering it up too much. Here is the latest:
(note, if you read this blog sometime in the future, this image may have got updated).
I still don't know if the new Pppoeconf package works. I uploaded a tarball, announced here:
http://puppylinux.com/blog/?viewDetailed=00238
...but nobody has.
Never mind, it will be in 4.1alpha5.
The thing is, even if it works, I don't know how it saves its settings and gets re-connected at future boots. Will have to sort that out. Perhaps in the above picture, there will need to be a radiobutton for PPPOE-Connect.
For the GPRS entries in the picture, they only appear if Puppy has found suitable hardware.
One thing that may need more work. I kept the wording minimal, but "Connect to Internet by network or wireless LAN" may not be adequate. Someone who just plugs their Ethernet cable into a ADSL modem or a modem/router, or has a wireless modem/router, may not realise that they should click that particular button.
wvdialconf bug workaround
Rerwin found another strange bug when using 'wvdialconf' to probe for modems. The 'Modem' entry in /etc/wvdial.conf can get set to '/dev/modem', but /dev/modem is a symlink to 'modem', that is, to itself. Peculiar situation.
I have modified /usr/sbin/modemprobe to workaround that problem.
However, /dev/modem should never be a symlink to itself, and I think that I have fixed where that was happening. I also put in a test in rc.sysinit to catch that invalid link.
setserial bugfix
Rerwin reported in the 4.1alpha4 forum feedback thread that setserial can crash if applied to other than serial modems.
I have applied the fix to /etc/rc.d/rc.sysinit and also to /usr/sbin/modemtest.
The setserial utility is supposed to configure the modem so that it can be used. For example, it can be made to automatically select the correct IRQ line. I don't know what the story is with other than serial hardware modems, but anyway the above scripts are now limited to only running setserial for /dev/ttyS0 - ttyS4 devices.
What are phy drivers?
I noticed recently in dmesg that a driver was registering something called 'phy0', and this seems to have something to do with ethernet.
So, when I compiled the 2.6.25.11 kernel, I enabled "PHY device support and infrastructure" as a module. This was in the "Network device support" section.
This has resulted in some more modules, but they don't have any modalias entries so I don't know what would cause them to load, if anything.
I have googled around, found plenty of references to phy devices but nothing that tells me what they are. Anyone got a clue or two about this?
Modem detection progress
Analog dialup modem detection is somewhat broken in 4.1alpha4, due to the lack of automatic detection of serial hardware modems at bootup.
I have fixed it all, and added more probing functionality to PupDial. It just remains to do some more testing, to catch any stray bugs.
Osmo not upgraded
Pup 4.x has Osmo 0.2.0, the latest is 0.2.2 which now unfortunately has a dependency on libnotify which has a dependency on dbus.
I am not "ready" to put dbus into 4.1. It may happen sometime, but I need to study it thoroughly first, especially reports that it slows things down.
uvcvideo driver
See the previous post. This is the Linux-uvc driver, module uvcvideo.ko. It does not seem to clash with any other driver, so I have put it in.
The related modules that also load for that hardware are:
v4l1-compat, videodev, compat-iotl32 and usbcore.
uvcvideo itself does not have any dependencies, so I am just assuming that the loading of those extra modules does not cause a clash.
atl2 Ethernet driver
Another bug report for 4.1alpha4 was that the 'atl2' Ethernet driver is missing, required for the Eeepc laptop. I have now compiled that driver.
I was looking at a forum thread on the Eeepc and there is mention of a 'Linux-uvc' or 'uvcvideo' driver being needed. However, when I went to the linux-uvc website there was no source available.
http://linux-uvc.berlios.de/
The site said to get it from SVN, but there was nothing there. I found an older version, 'linux-uvc-0.1.0-e', at the T2-project repository but that does not compile.
So, has this become part of the mainline kernel source? -- the linux-uvc site doesn't say that. The 2.6.25.11 kernel does not have any driver with "uvc" name in it. There are lots of V4L2 USB drivers though.
Update: I browsed linux-uvc SVN and the files are there, then I found that the URL given to fetch from SVN is incorrect. The correct command is:
svn checkout http://svn.berlios.de/svnroot/repos/linux-uvc/linux-uvc/trunk
...I had to insert a second "linux-uvc" into the path.
pppoeconf for testing
Dougal suggested that I should upload the amended Ppppoeconf package for testing. Okay, it is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha4/
This should add the extra infrastructure to 4.1alpha4 so that the pppoeconf script will work. Perhaps it will work in earlier puppies also. This is supposed to work with the ppp package only, and does not need the Roaring Penguin rp-pppoe package.
One other thing that you will probably have to do. It requires the group "dip", so append this line to /etc/group:
dip:x:30:
And append this line to /etc/gshadow:
dip:::
Run 'pppoeconf' in a terminal so that you can see any error messages and report back here.
Note, for troubleshooting, an earlier post to this blog has two very useful links on "kernel-mode-pppoe" (which is what pppoeconf is using):
http://puppylinux.com/blog/?viewDetailed=00062
Pnethood, Geany again
HairyWill's Pnethood upgraded to 0.65.
There is one thing that I dislike about Geany 0.13 -- scrolling down to the end of the document I am able to scroll a complete window past the last line, so I just see a blank window. I dislike that so much, I'm even tempted to rollback to 0.12.
Xlock fixed
One feedback report on 4.1alpha4 is that when click on the 'lock' icon on the desktop, nothing happens. Xlock was upgraded by Nathan, with a nice menu entry and international language support, but the bug is not Nathan's fault, it's mine.
Previously, /usr/X11R7/bin/xterm was a symlink to /usr/bin/rxvt, but I replaced the former with a script. The reason for this was that Xf-prot requires the '-hold' option for xterm, which rxvt does not have, so the script was a workaround. Anyway, my xterm script had a little bug which crashed Xlock, now fixed.
While I as looking into xterm and rxvt, I thought of going over to Urxvt, as it supports more options including '-hold' and also has special support for unicode so is good for internationalisation. Urxvt is very big, but the 'mp' text editor would not run in it -- probably that could be sorted out, but I couldn't see how so just left it at that and decided to stay with rxvt.
Every now and again I checkout alternatives to rxvt, but always there is some little thing that stops me from changing over. I think that rxvt can be compiled against the libncursesw library (it is currently using libncurses) which will give it better international support ...I might grab the latest rxvt and look at the compile options.
Pppoeconf maybe fixed
I have been running Ubuntu 8.04, examining the environment that Pppoeconf needs to work properly. I have imported various directories and files into Puppy that will hopefully provide the necessary infrastructure. I can't test it though.
libgphoto2, gphoto2
Puppy 4.00 has libgphoto2 version 2.4.1. I have now upgraded to 2.4.2, for Puppy 4.1.
There is currently some discussion on the forum about problems with Gtkam (a GUI for libgphoto2) and using the commandline utility gphoto2, and the possibility of developing our own GUI that is a frontend to gphoto2.
However, it was then noticed that Puppy 4.00 does not have gphoto2, so I have also compiled that, version 2.4.2, for Puppy 4.1.
I also recompiled Gtkam against the new version of libgphoto2, on the off-chance that it might improve the stability of Gtkam -- but, no it doesn't.
Aspire One video support
I have added support for the 1024x600 LCD screen in the Acer Aspire One.
This required patching the source of the '915resolution' package, version 0.5.3, as described here by timothyli:
http://murga-linux.com/puppy/viewtopic.php?t=31298
...the forum thread has a link to a site with the complete patch. This is for the Intel 965GM graphics chip.
I then modified /usr/sbin/xorgwizard so that Xorg supports 1024x600, and modified /usr/X11R7/bin/xwin for Xvesa.
Geany, Pburn, Pmusic, Pnethood updated
Geany version 0.13. This has support for printing.
Pburn 1.9.6.
Pmusic 0.1.4
Pnethood 0.64
Ayttm updated, Geany not updated
I have updated Ayttm with the latest from CVS, version 0.5.0-59.
I had hoped to update Geany to version 0.14, as it now supports printing. However, it won't even start, get a "Segmentation fault". I'll go back to their site, see if there's a fix.
SCSI kernels
I went to a Slackware download site to obtain kernel .config files for Slackware's "SCSI kernels". Surprise, Slackware stopped providing these at version 11.0. Up to and including 11.0, Slackware provided four kernels, named "adaptec", "scsi", "scsi1" and "scsi2", with different groups of SCSI drivers built in. There are various reasons for this:
1. Having SCSI drivers builtin rather than modules makes it easier to boot from a SCSI drive.
2. All SCSI drives are not builtin to one kernel as the kernel can become confused at bootup and there will be a "kernel panic".
3. All SCSI drives are not builtin to one kernel as the kernel would become very big.
Anyway, I have created three SCSI kernels for Puppy 4.1, with the 2.6.25.11 kernel. I have named them "scsi1", "scsi2" and "scsi3". The first is almost the same as the Slackware "adaptec" kernel, the second close to the Slackware "scsi" kernel, and all left-over SCSI drivers are in my "scsi3" kernel.
The idea is that when I or someone else wants to boot Puppy off a SCSI drive, you just pop in the right kernel.
So, I had better document how each is configured:
SCSI1
CONFIG_SCSI_AHA152X=y
CONFIG_SCSI_AHA1542=y
CONFIG_SCSI_AHA1740=y
CONFIG_SCSI_AACRAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_SCSI_AIC79XX=y
CONFIG_SCSI_AIC94XX=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_NCR53C406A=y
SCSI2
CONFIG_SCSI_EATA=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_INITIO=y
CONFIG_SCSI_INIA100=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_QLOGIC_FAS=y
CONFIG_SCSI_QLOGIC_1280=y
CONFIG_SCSI_QLA_FC=y
CONFIG_SCSI_QLA_ISCSI=y
CONFIG_SCSI_SIM710=y
SCSI3
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_7000FASST=y
CONFIG_SCSI_ACARD=y
CONFIG_SCSI_ADVANSYS=y
CONFIG_SCSI_IN2000=y
CONFIG_SCSI_ARCMSR=y
CONFIG_SCSI_HPTIOP=y
CONFIG_SCSI_BUSLOGIC=y
CONFIG_SCSI_DMX3191D=y
CONFIG_SCSI_DTC3280=y
CONFIG_SCSI_FUTURE_DOMAIN=y
CONFIG_SCSI_GDTH=y
CONFIG_SCSI_GENERIC_NCR5380=y
CONFIG_SCSI_GENERIC_NCR5380_MMIO=y
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_IPS=y
CONFIG_SCSI_INITIO=y
CONFIG_SCSI_INIA100=y
CONFIG_SCSI_NCR53C406A=y
CONFIG_SCSI_STEX=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_PAS16=y
CONFIG_SCSI_SIM710=y
CONFIG_SCSI_SYM53C416=y
CONFIG_SCSI_DC395x=y
CONFIG_SCSI_DC390T=y
CONFIG_SCSI_T128=y
CONFIG_SCSI_U14_34F=y
CONFIG_SCSI_ULTRASTOR=y
CONFIG_SCSI_NSP32=y
Multitech GPRS modem
Lloyd has done a lot of work, see this thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=31224
Quoting:
I am pleased to announce the first release of a patched driver for the USB-connected Multitech Multimodem GPRS/EDGE/CDMA modems. Multitech makes what are probably the best GPRS modems in the world. (GPRS is a wireless Internet technology, running on top of a GSM cellular phone connection. It provides very cheap Internet access throughout Costa Rica, and is is popular in several European countries.)
To my knowledge this is the only working driver package available for a modern Linux distro (aside from my Debian Etch solution at http://voluntary-simplicity.org/linux, which is not nearly as nice as this). In other words, no other current Linux distro (kernel version 2.6x) has a driver package that works with these modems. It is tested only for GPRS.
I am looking how his PET package can become a "firmware tarball" in Puppy 4.1. That is, it will be built-in, located at /lib/modules/firmware/multitech-1.2.tar.gz, and will install automatically if the ti_usb_3401_5052.ko module loads.
I have created an entry in /etc/modules/firmware.dep.2.6.25.11, which establishes this relationship between module and firmware package:
multitech-1.2:ti_usb_3410_5052.ko
Puppy 4.1 will automatically load usbserial.ko and ti_usb_3401_5052.ko and in the correct order, so I don't think Lloyd's 'pinstall.sh' file is needed. Um, no, have retained just this:
#make symlink if /dev/ttyUSB0 not already a special device file
if [ "`file ./dev/ttyUSB0 | grep 'character special'`" = "" ];then
rm -f ./dev/ttyUSB0
ln -s /dev/usb/ttyUSB0 ./dev/ttyUSB0
fi
/usr/sbin/fixmenus
I added the last line, as Lloyd has .desktop files, so the JWM menu will need to be updated.
I need to liaise with Lloyd on this find out if I've done this right. Note, 4.1alpha5 is expected to come out real soon, so we can test this, or rather Lloyd will as he has the hardware. Lloyd has stated that other brands of GPRS modem may also work.
What is supposed to happen here, is if you boot Puppy with the appropriate hardware for the ti_usb_3401_5052.ko module (or hotplug it), then the firmware package will automatically install and menu entries will magically appear. There will be nothing separate to install to get it going.
2.6.25.11 kernel compiled
I applied ten patches:
1. loglevel patch.
2. patch -p1 < ../4300_squashfs-3.3.patch
3. patch -p0 < ../splice-2.6.23.patch #for aufs
4. patch -p1 < ../fsync_super-2.6.19.patch #for aufs
5. patch -p1 < ../deny_write_access.patch #for aufs
6. patch -p1 < ../linux-lzma-2.6.25.5.u
cd /
7. patch -p0 < usr/src/multitech/ti_fw_3410.h.diff
8. patch -p0 < usr/src/multitech/ti_fw_5052.h.diff
9. patch -p0 < usr/src/multitech/ti_usb_3410_5052.diff
10. patch -p0 < usr/src/multitech/ti_usb_3410_5052.h.diff
Note that I did not apply the Unionfs patch, given its current instability.
Patches 7 - 10 were supplied to me by forum member rstandish (Lloyd). These are patches to the ti_usb_3410_5052 module. See this forum thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=31224
The patched kernel source, plus sources for 3rd party drivers, has been uploaded to Ted Dog's site:
http://puptrix.org/sources/kernel-2.6.25.11/
The madwifi drivers are included. I created an entry in the PREFLIST variable in /etc/rc.d/MODULESCONFIG:
PREFLIST=' rt2500usb:rt73usb ath_pci:ath5k '
So the ath5k module will get preference. If you want to use the Madwifi module then you would need to run the BootManager and remove the 'ath_pci:ath5k' entry (or just edit /ec/rc.d/MODULESCONFIG).
New Network Wizard
Dougal has done something very ambitious, to overhaul the Network Wizard. Go to the forum thread to find out more:
http://murga-linux.com/puppy/viewtopic.php?t=31522
Testers are needed!
Autologin for Ayttm
Someone posted a report to Ayttm bugzilla that it crashes in 4.1alpha4 when trying to login to IRC, so I tried it myself, it works fine for me. Perhaps Unionfs again? (I'm running Aufs now).
Anyway, while logged in I had a chat with wolf_pup and he has done something great (I suppose that you are a "he", wolf_pup?). Wolf_pup has made available the latest Ayttm for Puppy 3.01 and later users, and has recently added autologin. He has adapted the original Pidgin autologin script.
Wolf_pup's Ayttm forum post is here:
http://murga-linux.com/puppy/viewtopic.php?t=31185
Of course, I have taken the login script for my Ayttm package and that will be in 4.1alpha5(or beta).
PUPMODEs 6 and 7
I have tidied this up in the 'init' script. The default is now not to copy the 'pup_xxx.sfs' to RAM unless the 'pfix=copy' boot parameter is given.
However, there are conditions in which this must be overriden. Here is the actual code in 'init':
#v405 decide whether to copy sfs's to ram...
COPY2RAM=""
COPYMSG='\\033[1;35mcopying to ram\\033[0;39m' #purple
#v4.00 lowered rom 230000 to 220000... v403 added PUPSFSDEVMNTPT test... v404 explicit PCOPY needed...
[ $PUPMODE -eq 5 ] && PCOPY="yes" #well, override on first boot.
#v404 absolutely must copy to ram, otherwise layerfs conflict...
[ $PUPMODE -eq 6 -o $PUPMODE -eq 7 ] && COPY2RAM="yes"
[ "$COPY2RAM" = "yes" ] && COPYMSG='\\033[1;35mforced copying to ram\\033[0;39m' #purple
[ $RAMSIZE -gt 220000 -a "$PCOPY" = "yes" ] && COPY2RAM="yes" #256MB system. note, only checking physical ram.
The SFS is copied to RAM on the first boot, if there is enough RAM, as that is what the first boot is all about, running totally in RAM.
PUPMODEs 6 and 7 are cases that I have recently mentioned. Frugal installation but using the entire partition to save, instead of a "pup_save" file. There is a conflict that causes Unionfs to potentially crash and Aufs to not start. File pup_xxx.sfs, in fact all SFSs that are to be loaded as a layer, must be copied to RAM ...oh dear.
Oh dear, because currently the 'init' script does not copy any additional SFS files, for example 'devx_xxx.sfs', to RAM.
Um, I think that I will withdraw support for PUPMODEs 6 and 7 totally. Unless I also add code to copy all SFSs to RAM ...yuck.
Note, sometime ago I was using PUPMODE 6 and 7 quite happily, with Unionfs. Perhaps that was the less ambitious v1.x series. These days, in both Aufs and Unionfs there is an emphasis on supporting direct writing to the layers, and I suspect this is what is causing the conflict.
Has anyone else used PUPMODEs 6 or 7 with success?
Sound, front sockets not working
Does anyone reading this have any experience with getting the front sound sockets to work?
On my laptop, if I plugin the headset, the inbuilt loudspeaker cuts out, and Alsamixer now has a "headphone" entry, however it's volume cannot be raised.
However, the microphone does work.
On my desktop PC, the front sockets don't work at all, have to plug the headset into the rear sockets.
ALSA fixed
Sound is a bit broken in 4.1alpha4. Previously, there was some code at bootup that appended some lines to /etc/modprobe.conf, like this:
alias snd-card-0 snd_hda_intel
alias sound-slot-0 snd_hda_intel
4.1alpha4 does not have that code, and I have found that it breaks /etc/rc.d/rc.alsa, which is run (with the 'start' parameter) at bootup. If you run the ALSA Wizard (Setup menu) it will create those lines. That's the first bug, now the second...
Experimenting on my laptop, I found that it likes the following modules to be loaded:
snd-mixer-oss
snd-seq-oss
snd-pcm-oss
4.1alpha4 loads the first one only, but my microphone doesn't work. Previous puppies had explicit code in the boot scripts to load all three, but now that 4.1 is relying on the uevent mechanism there are much less explicit modprobe's in the boot scripts.
I didn't think those modules mattered anyway, as I thought that they had something to do with the old OSS-compatibility. But they are needed -- or perhaps their dependencies are needed. Anyway, I have now reinstated modprobe's to load them.
What started me off on fixing sound is today I purchased a headset. The brand is OfficeOne, from Kmart and it cost AU$19.95 (with the dropping US Dollar, the Australian dollar is almost on a par, and that would be about US$19.30). looks well made, Chinese of course.
Booting with Aufs
If you are testing 4.1alpha4 and have any trouble with crashing, try using Aufs rather than Unionfs. The way you do this is to boot with the 'layerfs=aufs' kernel boot parameter.
If booting from CD, at the prompt in the 5-second boot screen, type this:
puppy layerfs=aufs
If Puppy is installed to Flash, then you most likely have a isolinux.cfg or extlinux.cfg file on the Flash drive. Open that in an editor and append:
layerfs=aufs
If you are using GRUB then you should be able to figure out where to append this parameter.
Due to the many outstanding bug reports posted to the Unionfs bugzilla and lack of response from them, it looks like we will be going over to Aufs. I'm using Aufs right now. I need to do some checking that it runs right, as there are some assumptions made in 'petget' about how the layers can be written directly into, and elsewhere such as rc.update there is some management of whiteout files -- which are slightly different in Aufs.
SeaMonkey mailto fix
I fixed a bug in the new 1.1.11 SeaMonkey. The file /root/.mozilla ... prefs.js was setup for an external mailto handler. See last three lines of that file -- I have removed those lines.
Event management pages updated
I have updated the "Kernel module loading" and "Puppy event management" web pages:
http://www.puppylinux.com/technical/module-loading.htm
http://www.puppylinux.com/technical/event-management.htm
Puppy 4.1alpha4 released
I drove to Perth last night, partly because I get access to ADSL2 high speed Internet at my relative's place. I am typing this using a nice keyboard on my desktop PC that I brought along!
The iso's are uploaded to here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha4/
There is some uncertainty about whether the 'evdev' module is stuffing up the mouse on some hardware. So, I have created an alternate iso which has 'evdev' blacklisted. So, Lobster and others, try that one.
Why do we need 'evdev' anyway? We never had it before, and my computer works fine without it. Is it like the 'ub' module, a "Swiss Army knife" that tries to do everything, but not very well? ...heh, heh, don't mind me, I'm just being deliberately provocative.
If you want to see how fast 4.1alpha4 boots, time the third boot. The reason is, the first boot is your PUPMODE 5, with no save-file, then you shutdown and create a save-file, but on the second boot the 'rc.update' script takes awhile as it analyses the Unionfs layers for correctness -- I need to look at this script and see if I can streamline that, or at least put a little message "checking layered f.s., next boot will be faster!".
Still stuck on the 2.6.25.9 kernel. The next release should have the 2.6.25.11 kernel, which I intend to stay with for a long time.
I need to update the Event Management web page, as now using the 'udevd' daemon. I'll see if I can do that later today.
So, what's special about this latest pup?
1. Much faster boot.
2. Udevd with my custom backend scripts for module loading/hotplugging.
3. Event manager frontend, including desktop drive icons.
4. SeaMonkey full suite.
5. Pmusic audio player.
6. Psip VOIP and IM client.
7. Pppoeconf, new setup GUI tool -- nobody responded to my request to test.
8. Ayttm replaces Pidgin.
9. PPLOG personal blog.
10. Xfprot virus scanner.
All of the above need testing! This release is pretty solid, at least it is on my PCs, so this time I welcome lots of feedback, extensive testing. If it turns out there are lots of bugs, then the next release will be 4.1alpha5, otherwise it will be 4.1beta.
Psip
I have upgraded Psip to 0.9.13.
SeaMonkey, evdev
SeaMonkey version 1.1.11 will be in 4.1alpha4, and this is the full-blown suite with Mail, News and Addressbook modules.
Lobster, and I think at least one other person, has reported mouse trouble with the 4.1alphas.
I'm wondering if it has anything to do with the 'evdev' module.
Lobster, in your Puppy-with-working-mouse, which I presume is 4.00, is 'evdev' loaded? (run 'lsmod' in a terminal).
p.s. does anyone else hate their laptop keyboard? I have to punch the keys hard on my Acer, and so often I hit the space-bar a bit off-centre and it doesn't register. I always have to read what I typed very carefully, as characters regularly get missed -- certain keys in particular, if I hit them a bit too lightly they don't register. I miss the positive action of a quality keyboard, actually, even a fairly cheap normal keyboard is way better. Or, is it just the way I type, and no one else has a problem?
Pmusic, Pburn, Psip
Pmusic upgraded to 0.1.3. Well, Pmusic is actually a newcomer, making its debut in 4.1alpha4.
Pburn to 1.9.5.
Psip 0.9.12, another newcomer.
Psip: wow! If you want to know more, here are some forum threads:
http://murga-linux.com/puppy/viewtopic.php?t=31061
http://murga-linux.com/puppy/viewtopic.php?t=30322
The project coordinator for Psip has been Lobster, and HairyWill has done a lot of the heavy background work -- and has got some premature grey hairs -- a special thanks to you guys. Thanks to Evil20071, smokey01, charnisingh, Caneri, puppyluvr, prit1, gazb, John_Doe and peppyy for pitching-in and helping with testing.
UPDATE: Once I start listing names, I had better get it right. I also wish to add a thanks to CEL and Aitch for helping with testing, and jebajQ8 for the icons!
I'll put 0.9.12 into 4.1alpha4 (unless another version comes out pretty soon) and we can do some wider testing.
PUPMODE fix for Classmate
There are various ways that you can install Puppy to a baby laptop with internal Flash memory.
1. Full "hard drive" installation.
2. Frugal, with a "pup_save" file.
3. Frugal, saving to entire partition (if it is a Linux partition).
I recently reported some trouble with option 3, that is, Aufs not starting and Unionfs (latest version) crashing, unless 'pup_xxx.sfs' is copied to RAM.
There has been an on-going issue with option 2, testers have reported that it is running in PUPMODE 12, whereas to preserve the life of the Flash memory it should preferably be 13 (tmpfs top layer in RAM, with periodic or manual saves to the pup_save.2fs file).
I have fixed this -- the init script now detects the boot parameter 'pmedia=usbflash' and changes PUPMODE from 12 to 13.
Note that with option 1, a full conventional installation, this is PUPMODE 2 and there is no buffering with a tmpfs, so no preserving of the Flash memory. Note however, that it is theoretically possible to boot a full installation in PUPMODE 3, which does have a layered f.s. with tmpfs RAM layer on top.
I haven't tried it, but if you place the initrd.gz file on the hd partition and setup to boot from that rather than the partition itself, then it should come up in PUPMODE 3 ....but, as I say, not tested.
BootManager changes
I have removed the checkboxes for doing a serial probe at bootup and for "fast boot". The serial probe is no longer done, and "fast boot" is now unecessary considering how fast boot has become anyway.
I have added support for the new preferred-module PREFLIST variable in /etc/rc.d/MODULESCONFIG. Now there is a simple GUI for choosing a preferred module (see previous blog post).
Note, I think I'm on-track to upload 4.1alpha4 in another day or two.
No fsck at bootup
Continuing to work on fast booting. The filesystem check of the "pup_save" file gets slower as there are more files in it. Although the "pup_save" file does not shutdown cleanly, it's integrity is not compromised and there is no need to do a f.s. check and repair at every bootup.
So, I have now made it the default not to. However, the 'init' will still do so if the "pup_save" file refuses to load.
Also, I have introduced "pfix=fsck" to manually ask for a f.s. check.
If the "pup_save" was on a ext2 partition then that was also checked at every boot, and that could be very slow. Again, that is now only done if "pfix=fsck".
Cause of Unionfs/Aufs failure
Over the years I have played with both of these. Originally Puppy used Unionfs, then I went over to Aufs, then back to Unionfs.
The reason that I went back to Unionfs is I had a situation where Aufs refused to create the layers, whereas Unionfs did and worked. Well, I conducted some experiments today and perhaps it is just luck the Unionfs worked under that situation, or maybe the older version worked.
A configuration that Aufs refuses to deal with is when I had a frugal install to the Classmate and chose the "pup_save" to be the entire partition. Puppy will then boot in PUMODE 6 or 7, the latter looking like this:
tmpfs top layer
sda1 "pup_save" is entire partition
pup_404.sfs mounted by loop device
These are the layers. This worked okay before, but now Unionfs crashes and Aufs is intelligent enough to detect a conflict. The reason it worked before Puppy 4.1alpha4 is that the default was to copy the pup_404.sfs to RAM first -- well, it was only copied if there was enough RAM.
The situation now is that the default is it is not copied. The 'pup_404.sfs' is located in /dev/sda1, and that is the conflict. Aufs sees that the same file is in two layers, Unionfs dumbly goes ahead but then may or may not crash.
Perhaps Unionfs and Aufs could be made to handle this situation, but anyway what I have done is put in a fix that forces 'pup_404.sfs' to be copied to RAM if PUPMODE is 6 or 7. This will happen regardless of the amount of RAM.
"Fun" with my Classmate
Oh dear, this must rate as a fatal design flaw
I was testing the latest Puppy on the Classmate, did an install to the internal Flash memory, booted, worked, then chose to save to the entire partition (it is ext2). Upon reboot, the mouse cursor appeared on a black screen and the system froze.
I rebooted with pfix=nox and got to a prompt ok. Attempting start X had the same problem, but this time it responded to CTRL-ALT-BACKSPACE and I saw a kernel dump and frozen again -- I see on the screen the word "unionfs" amongst the crash dump.
So I decided to boot with 'layerfs=aufs', but aufs was unable to mount the layered f.s. with an error message "/pup_ro2 is overlapped", then I got a kernel panic.
That's when things got nasty. Normally, if there is a kernel panic, I can hold down the power button for 4 seconds and the system will power-off. Not this time. There is no hard-reset button. I was unable to turn off the laptop. Closing the lid did not work. The fan was not working and I could feel the CPU getting hotter.
So, had to get out a miniature screwdriver and remove the battery. I'm going to let our Intel engineer know about this. If someone did not have such a screwdriver, they would have to sit there and watch the laptop destroy itself.
Ayttm
Ayttm is a multi-protocol chat client. I have compiled the latest Ayttm out of CVS. Siddhesh is the current most active devloper (see my blog post a couple of days ago) and his latest code is in the 'libirc-mod' branch. For the record, this is how I got it:
# cvs -d:pserver:anonymous@ayttm.cvs.sourceforge.net:/cvsroot/ayttm login
CVS password: [just press Enter]
# cvs -z3 -d:pserver:anonymous@ayttm.cvs.sourceforge.net:/cvsroot/ayttm -r checkout -r libirc-mod ayttm
# ./gen
# make
I already had the Jasper package installed, which Ayttm uses to provide support for Yahoo webcam. Then to compile and install Ayttm:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --disable-esd --disable-arts --enable-webcam
# make
# make install
This will be in 4.1alpha4 instead of Pidgin.
Preferred module
Dougal raised the problem of rt2500usb and rt73usb, and the lack of any Udev rule capability to adequately deal with choosing the correct one.
The problem occurs on the Classmate laptop, where rt2500usb.ko an rt73usb.ko are both detected as eligible for the wireless network interface. If 'modinfo' is executed on each of these, and the 'alias' lines examined, it can be seen that at least two are the same.
Of course, Puppy does have a blacklist capability (see the BootManager) but that does require some knowledge on the part of the user, to know that rt2500usb needs to be blacklisted to allow only rt73usb to load.
Instead, I have implemented a 'PREFLIST', which is in /etc/rc.d/MODULESCONFIG. Here is what is currently in there:
#PREFLIST: sometimes there are two hits, that is, two modules match the same
#'modalias'. In such a case, here we can specify a preference. Each entry
#here is of the form 'module1:module2' where module2 is the preferred choice.
PREFLIST=' rt2500usb:rt73usb '
There is a script, /sbin/pup_event_backend_modprobe, that udevd calls when it has a modalias. This script does various pre-processing, mostly processing entries in /etc/rc.d/MODULESCONFIG, then loads the module.
I have now added code that reads the PREFLIST variable and if there is a matching entry, then finds out whether the candidate-replacement also matches the modalias, if so then uses it.
I don't think this is perfect, as there may be cases where on one particular hardware it is required to use rt73usb rather than rt2500usb, but in some other hardware it is not so.
Faster boot times
The new faster boot scripts for the 'standard' Puppy do make a difference.
I have only tested booting from live-CD so far. I recently reported 36 seconds booting UniPup live-CD on my desktop PC, running Xvesa. This time does not include the 5 second pause at the initial boot screen, and is the time from the moment the kernel starts to load until the desktop fully loaded. So, how does the 'standard' pup compare...
On my laptop, which has a 1.5GHz Mobile Celeron CPU, 512MB RAM, the second boot, with only one 'pup_save' file so it doesn't stop and ask me which one I want, boot time is 39 seconds. But, that is to Xorg, and Xorg is painful to watch when you are timing it -- the screen flickers and contorts for many seconds before the desktop finally appears.
I also had my slow-to-initialise PCMCIA modem card plugged in prior to bootup, and checked after bootup that it was working.
Then I tested on my main desktop PC, with 2GHz Celeron CPU and 512MB RAM. This time I chose Xvesa, and the boot time is 29 seconds ...not bad!
So, I wonder what it will be booting from a hard drive?
Unionfs problem
What to do about Unionfs? Version 2.3.3 is the latest, but myself and others have submitted bug reports:
https://bugzilla.filesystems.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=2.3.3
I first reported this to their mail-list, then to Bugzilla on the 20th June. Nothing has been done so far. A couple of other guys have had the same non-response.
Today I want to build the 2.6.25.11 kernel, and I wanted this to be the build that we stick with for a long time. Because of this Unionfs issue, I have been delaying...
Well, I suppose that I can stay with the 2.6.25.9 kernel for 4.1alpha4.
I notice also the Squashfs developer has been tardy. The latest is version 3.3, released November 2007, but that does not compile with the 2.6.25 kernel. I had to get a fixed patch from the Ubuntu developers.
Are these guys losing interest in their projects?
Udev rules fix, Rox rollback
Udev rules
Ah, I figured it out. This is the corrected rule, that previously was not working quite right:
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo ACTION=$ACTION SUBSYSTEM=$SUBSYSTEM DEVTYPE=$DEVTYPE DEVPATH=$DEVPATH > /tmp/pup_event_backend_s'"
I previously had DEVTYPE=="disk" but DEVTYPE is an environment variable, not a key word. I previously got confused about this, as SUBSYSTEM and ACTION are both key words and environment variables.
Rox rollback
A couple of people reported a problem with ROX-Filer when testing 4.1alpha3. There was no desktop background, no icons, but restarting X fixed it. I got this just once. Rox is failing to start -- there is an error message, which I do not understand.
4.1alpha3 has ROX-Filer version 2.8, so I have rolled back to version 2.6.1 (as used in Puppy 3.01 and 4.00). We shall see if the problem still occurs.
Xfprot fixed
The first time Xfrot is started in 4.1alpha3, it attempts to download the f-prot package, which has the signature file and a scanner executable. There was a bug in my download script, that caused it to hang, now fixed.
PPLOG fix, faster boot
PPLOG fix
I built the latest Puppy and installed to USB Flash. Booted, then tested PPLOG, but got a "500 internal server error". I found that PPLOG needs the 'CGI' Perl module -- the reason PPLOG worked before is because I had the 'devx' file loaded, which has the complete Perl, whereas the 'pup_xxx.sfs' has a cutdown Perl PET package (perl-5.8.8tiny). I added the CGI module and PPLOG worked -- that adds about 400KB uncompressed to the cutdown Perl package, but I reckon it is worth it (it jumps from 2600KB to 3000KB according to 'du').
Hmmm, now that we have a web server in the 'standard' Puppy build, I wonder what other little Perl CGI program gems are out there...
Faster boot
One thing that has been most impressive with UniPup is the fast boot. This has brought home to me that as Puppy has progressed, boot times have got gradually longer. 4.1alpha3 is the worst. It is time for a clean sweep, and to make some tough decisions.
I have applied the fast boot code developed for UniPup to the mainstream "normal" Puppy. Some notes on this:
1.
rc.local0 is eliminated (it has a lot of historical, very tangled code), there is now just rc.sysinit, which calls rc.update, rc.network, rc.country and rc.services.
2.
There is no probing of serial devices, nor any autodetection of modems (except of course udevd will autoload any appropriate module it finds a match for). Instead, the intention now is to do the probing after bootup, when the user runs PupDial. The user will also have to manually choose a serial mouse.
3.
By default, pup_xxx.sfs is not copied into RAM, regardless how much RAM there is, unless 'pfix=copy' is specified.
4.
Refined code from the rc.sysinit used in UniPup, to wait for slow hardware without gross 'sleep' lines inserted.
The "normal" Puppy cannot boot quite as fast as UniPup, due to the initrd step of the former -- the init script waits for USB storage to become available, then after the switch_root the modules for some other slow hardware may get loaded (for example PCMCIA) and there may have to be a wait again -- whereas in UniPup the usb-storage driver would be loaded concurrently with the drivers for other slow hardware. However, a full hd intall will get the same fast boot as UniPup.
Anyway, I think any potential slower boot of the "normal" Puppy will only be a few seconds.
A comment on point-2. In many cases a module for a modem will be detected and loaded, and its firmware package loaded, and any install script executed. So, it may be that the modem is still fully autodetected and ready to go. However, true hardware serial modems will not be autodetected, but the "probe" button in PupDial will find it, and set /dev/modem to point to the required device. Some details may need to be worked out though!
A comment on point-3. When boot from a live-CD, the normal thing is to create a save-file at first shutdown, then the 'pup_xxx.sfs' also gets copied to the hard-drive. On subsequent boots, although the pup_xxx.sfs' is not copied to RAM, I found performance to still be good, due to intelligent buffering of memory-reads in RAM by the kernel -- after the first read, the kernel keeps as much in RAM buffer as it can.
I suppose I could make one small concession -- on first boot, PUPMODE=5, if there is lots of RAM then do copy pup_xxx.sfs off the CD, but only for PUPMODE=5. I think that some people like to boot in PUPMODE 5 often, and would like the optical drive to be freed up.
PPLOG in Puppy
I have created PET packages for Hiawatha web server version 6.7 and PPLOG blog version 1.1.
I finally got rid of /root/ghttp directory, as that was setup for nullhttpd and Quisp.
Hiawatha and PPLOG now use /root/httpd/hiawatha directory. This is the root web path when Hiawatha server is started, configurable from /etc/hiawatha/httpd.conf.
PPLOG is located at /root/httpd/hiawatha/blog directory.
I also created a menu entry for PPLOG, in the 'Personal' category, with a little GUI to start/stop the web server as well as launch PPLOG. The GUI script launches /usr/local/bin/defaulthtmlviewer http://127.0.0.1/blog/pup_pplog.pl to run PPLOG -- I have not yet figured out how to setup URL redirection to enable "pup_pplog.pl" to be left out of the URL.
Posts and comments are plain text files and are stored in /root/httpd/hiawatha/blog/posts and /root/httpd/hiawatha/blog/comments directories.
Note, I setup hiawatha to drop to nobody:nobody when running, and all files/directories in the blog are root:nobody. The hiawatha executable does not have suid bit set. I still need to run the Perl script with '-U' option.
Hiawatha web server
So far I am impressed. Hiawatha is small, with many features and was very easy to get going. It has SSL support and URL-rewriting. The author guarantees it to be secure! Here is the home page:
http://hiawatha.leisink.org/
Here is how I compiled and installed it:
# export webrootdir=/root/spot/hiawatha
UPDATE: now export webrootdir=/root/httpd/hiawatha
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --enable-xslt
# make
# new2dir make install
Then, set the 'suid' permission on /usr/sbin/hiawatha
# su spot
# hiawatha
# mozilla http://27.0.0.1:80/
# killall hiawatha
# exit
This also works:
# su -c '/usr/sbin/hiawatha -d' - spot &
However, I am very uncertain about the best way to set it up, for the security. Forgetting about that 'su' stuff, if I just execute 'hiawatha' it automatically runs as user 'nobody' -- which is good enough isn't it? So, there's no real need to have the 'webrootdir' inside /spot? -- so maybe I'll change webrootdir to /root/httpd/hiawatha.
Regarding PPLOG, yes, it works! It worked right off, well I had to edit a few lines in /etc/hiawatha/httpd.conf. I was able to post a comment, but when I wanted to edit the comment, I got an error message:
Insecure in open while running setuid at /root/spot/hiawatha/blog/pplog.pl line 901
...I messed around with file permissions, but no go. The problem is the first post is a file, created at /root/spot/hiawatha/blog/posts/00000.ppl, and this file is the problem --it was created ok but Hiawatha will not allow to open and edit it.
....so close!
Anyone skilled at this security/permissions side of things who can comment about the best way to setup the installation of Hiawatha?
Udev fixed, inotify 0.5
There were some problems with udev in Puppy, now fixed I think.
Udev rule problem
One problem was this udev rule:
ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="disk", RUN+="/bin/sh -c 'echo ACTION=$ACTION SUBSYSTEM=$SUBSYSTEM DEVTYPE=$DEVTYPE DEVPATH=$DEVPATH > /tmp/pup_event_backend_s'"
This rule is how udevd notifies my frontend daemon, pup_event_frontend_d, when a drive is inserted. However, I was getting strange behaviour, and I eventually discovered that udevd was also writing to /tmp/pup_event_backend_s when:
ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="partition"
which caused two (or more) messages when my frontend script was only expecting one.
It seems that udevd is trying to be clever and has ignored the explicit instructions in the rule (unless I have misunderstood the rules syntax, which wouldn't surpr