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.
The proposed 4.2 team
I am very uncomfortable that I am forced into the role of assessing people for roles in the future 4.2 team.
I have posted some thoughts in the previous blog post, and Lobster has reflected some of this in the wiki:
http://www.puppylinux.org/wiki/archives/old-wikka-wikki/categorycommunity/puppy-42-deep-thought
However, I am not the one to decide who leads the team, as I am supposed to have stepped back from any leadership role. So, I have made some preliminary recommendations only.
The list of interested parties can firm up over the next week, perhaps even those concerned can have some private dialog and come to a consensus. Then a forum thread can be started to seek a consensus from the wider Puppy community.
Regarding building a Slackware-based 4.3, or anything else for that matter, it is the kind of thing that someone can "just do". Perhaps check that two people aren't going to do the same thing first though. If someone just presented it completed, done, built from 4.1, then it immediately becomes a prime contender for the basis of 4.3. It would have to be a Unleashed build system, with packages rebuilt from Slackware packages, not a remaster. The 'devx' component also!
The way ahead for Puppy is for individuals (or very small group) to "take the bull by the horns", get stuck in and do something. Then present the result.
Partial report on what I have read
This is going to be one of my aggravated posts, that I am sometimes prone to.
I have read part-way through the discussion on post-4.1, and a few things are emerging. Firstly, regarding tuuxx -- I do not want to target anyone, but ttuuxx has repeatedly posted comments that are incredibly superficial. For example:
"The 3 series just worked for myself better than any 4 series, I dislike the new pmount and shoving the floppy as default on my pc, which I haven't used the floppy since I made this pc around 12 months back, an extra click about 50 times a day, or the crappy clipboard downgrade on the 4.0 series that drives package producers like myself nuts. Really to tell you the the truth the only good thing on series 4 over 3 is is the default jwm theme. But I instally replace that anyways with Icewm."
Firstly, the Pmount in 4.1 can readily be configured without tabs, just hit the 'preferences' button. Secondly, the clipboard sync program used in earlier puppies was removed for good reason, but it is a PET package and can easily be installed -- without it, the clipboard works as per all other Linuxes/Unixes and just needs to be understood. If there is a majory wish, then it could be put back as default in 4.2.
All of the above has been explained to ttuuxx before, but he remains stuck with the same mantra. The assessment based on these comments that Puppy3 is better, is so incredibly superficial.
Then there is the issue that Puppy 2 or 3 works on some hardware whereas 4 doesn't. Yeah, well, it works both ways. This is basically a kernel version issue, not a Puppy version issue. There are so many posts that Puppy 4.x works properly for the first time, compared with versions prior to 4.x. Many recent posts about how fast 4.1 is also. 4.1 also has by far the best hardware detection.
Then there is the much-praised Slackware compatibility of 3.x. Well, someone can rebuild 4.1 with the latest Slackware packages if they want. It is a straightforward process, just very time consuming. 3.x is based on Slackware 12 packages, so is getting a bit long in the tooth. If someone wants to rebuild Unleashed 4.1 with the latest Slackware packages, then call it 5.0, why not? Go for it.
ttuuxx has asked can he coordinate the next Puppy3? Why not? I'm not stopping you, go for it.
There is also the comment from ttuuxx that I am maintaining control over everything, while at the same time retiring:
"Last I read Barry wants to keep just about everything puppy related in his name other than releasing newer versions"
Huh? I want to keep the "Puppy Linux" name, so what? To whom should I give it? The domain names puppylinux.org and puppylinux.com are registered by me, which means that I do have some veto power. Again, so what? Isn't this a valid safeguard?
So ttuuxx, I've had a go at you. Take it on the chin. You have also posted heaps of great stuff, and great packages. It's just that I am being bombarded with people asking me to make some kind of comments about what seems to be a lot of dissension on the forum ...well, I am now responding, and stepping on one or two toes in the process. Ttuuxx, it may turn out that you are the best guy to coordinate 4.2.
I have only read partway through the links, and so far I'm not impressed. Some people are asking for guidance, but what is to stop a small group getting together and work on 4.2? Nothing. Lobster is trying to coordinate something, but I am seeing a lot of arguing only from the contributors.
Meanwhile, the developers are continuing to work quietly. Regarding who should coordinate, by that I mean be in charge of using Unleashed to actually build it, and work on the core scripts, there are very few people to choose from. Other people can certainly play managerial and testing roles, but to actually build future Puppies...
Personally I think Dougal is the best choice, but he is working on 2.x. Probably Dougal would not want to take on such a heavy duty anyway. Who else is there that understands what is going on under-the-hood? Kirk? Rerwin is pretty good at coding and is learning about Puppy's boot scripts. MU also, but he has Muppy. Nathan also, but he has Grafpup, and also seems to have gone again. There are some other guys, like tempestuous, zigbert and HairyWill who have the technical ability, but again they would have to get up to speed with the boot scripts etc.
A side comment: many of the guys are "nice guys", approachable, friendly, helpful. Zigbert for example. One reason I favour Dougal is because he has a certain toughness and is less likely to bow to everyone's wishes. That's just my personal assessment.
There is some infrastructure in place for building Puppy, at Sourceforge, and I would like to thank cb88 for that. The thread started by cb88 had some good practical discussion.
4.2 is not going to be revolutionary, just refinements of 4.1. Fix some rough edges, update some packages, new themes. This can be done, just like 2.15CE was done. It just needs someone competent to step forward and do it. For 2.15CE, WhoDo offered to do it and we accepted, and he did a very good job. WhoDo, are you interested in a new project?....
I think the way forward needs to be along the lines of a Community Edition, like 2.15CE, which will get a group working together and build confidence, and will also help to clarify what should happen after 4.2. Other inftrastructure things like subversion control hosting, T2-rebuild or move to Slackware compatibility, and any formal foundation are not so urgent (and can continue to be developed/planned in the background). Also, the coordinator for 4.2 does not need to be a programmer, but should have good technical ability and be competent with using Unleashed -- my preference for someone who is a programmer and understands all of puppy's internals (like Dougal) and who also can take on a managerial role is the ideal though, for the longer term.
Plans for the future of Puppy
Since I announced that I was taking a back seat, effective from release of 4.1 (well, 4.1.1 actually), there has been a lot of discussion and planning. I have not been following any of this, but now have some time to read through it. First step is to collect all the links, and here is what I found:
Puppy 4.2 - desktop and artwork
zigbert
http://murga-linux.com/puppy/viewtopic.php?t=34331
4.2 meeting - here
Lobster
http://murga-linux.com/puppy/viewtopic.php?t=34201
Establishing a formal community
tombh
http://murga-linux.com/puppy/viewtopic.php?t=34134
Puppy Community
Lobster
http://puppylinux.org/wiki/archives/old-wikka-wikki/categorycommunity/puppy-community
PuppyCommunity
Lobster
http://tmxxine.com/wik/wikka.php?wakka=PuppyCommunity
Puppy's future
Bruce B
http://www.murga-linux.com/puppy/viewtopic.php?t=32169
Puppy 4.2
Lobster
http://www.murga-linux.com/puppy/viewtopic.php?t=33454
Barry's retirement from Puppy
tronkel
http://www.murga-linux.com/puppy/viewtopic.php?t=32078
How should Puppy be developed when Barry steps down?
disciple
http://murga-linux.com/puppy/viewtopic.php?t=32192
DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)
ttuuxx http://murga-linux.com/puppy/viewtopic.php?t=33484
Puppy Community Register
mysticmarks
http://murga-linux.com/puppy/viewtopic.php?t=32183
Puppy Linux community repo is active on sourceforge
cb88
http://www.murga-linux.com/puppy/viewtopic.php?t=32215
...I am now in the process of reading through all these links.
regarding numbering of versions, my plan was that the numbering would go back to having a dot between each digit:
4.1 is our current release.
4.1.1 is going to be a bugfix release, that I intend to bring out.
4.1.n these are either bugfixes or alphas or betas.
4.2 the next official 'final' release.
As I am targeting 4.1.1 for the near future, and want to move on to my UniPup work, I doubt that I will work on 4.2, so that's for you guys.
Comment posting initialised
There was a problem upgrading PPLOG from 1.1 to 1.1b, when posting a comment, the old passwords were no longer accepted. Posters had to create a new username and password.
However, I have cleared all usernames and passwords, so it is like a new installation of PPLOG. When posting a comment, choose whatever username and password you want.
UniPup boots faster
I have built UniPup 410 and compared the boot time from CD with the official Puppy 4.1.
UniPup: 46 seconds
4.1: 53 seconds
The main reason UniPup is faster is because it doesn't have an 'init' script. Just like a full-hd installation of Puppy, the first script that executes is 'rc.sysinit'.
However, UniPup is slowed by the loading time of the bigger 'initrd.gz' file. I have built this UniPup with a separate 'usr_410.sfs', but intitrd.gz has everything else, including all the kernel modules. I intend to cut down the modules somewhat.
I am aiming for 30 seconds boot time ...we shall see how close I can get to that.
Blog upgraded to v1.1b
The "b" does not mean beta, it is a later version than 1.1.
The main thing is now you have a menu when posting a comment. Do note that you can also post code with the 'code' '/code' tags in square brackets.
Changelog for 1.1b:
* BBCODE bug on comments, fixed thanks to СеÑгей
* RSS Links fixed, thanks to Matthew Everitt
* Some Grammar Corrected, thanks to Irmela
* Added an option to allow HTML on new entry pages
* Added an option to allow only numbers on CAPTCHA
* Fixed old captcha so there is no confusion (ALL CAPS LETTERS)
* Added an option to modify the CAPTCHA lenght
* Added an option to allow WYSIWYG instead of BBCODE (Smilies dont work with WYSIWYG)
Planning SP1
Each time I add something to the Service Pack, I'll post to this blog with "(SP1)" in the title, so everyone will know exactly what is going into it.
(SP1) Ndiswrapper bugfix
Thanks to MU, a PET package for the updated Network Wizard that fixes ndiswrapper:
http://murga-linux.com/puppy/viewtopic.php?p=238917#238917
EDIT:
No, from further feedback to above forum thread, it still isn't fixed.
(SP1) prism54 fix
Thanks to tempestuous, I have modified PREFLIST variable in /etc/rc.d/MODULESCONFIG:
#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 ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci martian_dev:ltserial bcm43xx:ssb prism54:p54pci '
See forum:
http://murga-linux.com/puppy/viewtopic.php?p=238917#238917
Ndiswrapper bug
The version of Network Wizard used in 4.1 has a bug. grab an update, see this thread:
http://murga-linux.com/puppy/viewtopic.php?t=31522
...someone should make that into a PET package, for those who don't know how to install from a .tar.gz.
It looks like we will have to bring out a Service Pack for 4.1, and another release, 4.1.1, with the Service Pack included.
Are there any other fixes for the Service Pack? (don't reply with bug reports here, I only want to know if anyone has fixed something and would like to see it in the SP1).
Kernel SFS files uploaded
As described in recent blog posts, here they are:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/sfs_modules-4/
These are for 4.1 and 4.1retro.
Firmware installation problem
There is a problem with how 4.1 installs a firmware tarball. It only affects the 'dvb-usb.ko' module. At the 12th hour, just before releasing 4.1, I threw in some firmware for this module, but we have now found that the firmware tarball does not install when the dvb-usb.ko module loads for the first time.
The firmware tarball is located at /lib/modules/all-firmware/dvb-usb-firmware.tar.gz, and you will have to install it manually. Expand the tarball anywhere, and copy the firmware files to /lib/firmware.
The reason the the firmware tarball does not install is because of the way I have setup firmware-tarball installation. The /etc/rc.d/rc.sysinit boot script iterates through the "modalias" files in /sys, causing the kernel to generate uevents, which in turn 'udevd' processes. The udevd daemon gets its rules from /etc/udev/rules.d, and for any case in which a module is being loaded, udevd will run /sbin/pup_event_backend_modprobe script, and one function of this script is to see if the firmware tarball is installed and if not then install it (from /lib/modules/all-firmware to /lib/firmware).
However, dvb-usb.ko does not have a modalias file under /sys, so is not loaded. It has to be loaded manually, or as a dependency of some other DVB USB related module. The way things should really be setup is for the firmware tarball to be associated with those DVB USB modules that do have a modalias entry (that is, have an 'alias' entry when you run modinfo, so it is a module for some specific hardware), and this association would be in /etc/modules/firmware.dep.2.6.25.16.
So, if someone can provide me with a list of all the hardware-specific DVB USB modules, I can fix the firmware.dep.2.6.25.16 file.
Note, in some earlier puppies, 'modprobe' is a script, but in 4.1 'modprobe' is the actual executable. When 'modprobe' was a script, firmware installation could be handled for every module.
Kernel SFS files
I have created 2.6.25.16 and 2.7.21.7 kernel SFS files for Puppy 4.1, but cannot upload them until the end of this week.
Note, they are in my Unleashed CD, which I'll be posting tomorrow.
How to recompile the kernel
If you want to recompile the 2.6.25.16 kernel with some goodies like tickless and SMP support, I recommend that you do a full hard drive install of Puppy 4.1 (not frugal).
You will need to install the 'devx_410.sfs' file also (C/C++ compiler support), as explained here:
http://puppylinux.com/hard-puppy.htm
Then download the patched kernel source from here:
http://puptrix.org/sources/kernel-2.6.25.16/
and expand it at /usr/src/linux-2.6.25.16.
...also download everything else.
Then follow the instructions given in the .txt files.
After compiling your new kernel, you can test it in the full installation.
To build a new Puppy with your kernel, you need Puppy Unleashed:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/puppy-unleashed-core-4.1.tar.gz
Instructions are at:
http://puppylinux.com/development/puppy-unleashed.htm
In puppy-unleashed/kernels directory you will find '2.6.21.7' and '2.6.25.16' directories. In the latter, substitute your new 'vmlinuz' and kernel modules.
If you are moving up to the 2.6.26.x kernel, make a copy of the '2.6.25.16' with the appropriate new version number, and make appropriate substitutions inside (kernel, modules, and replace DOTconfig-K2.6.25.16, and rename firmware.dep.2.6.25.16).
For compiling the 2.6.26 kernel, kirk, MU and others have posted some instructions:
http://www.murga-linux.com/puppy/viewtopic.php?t=33461
4.1 CD orders
I have a backlog of several CD orders, and I notified by email that I was holding orders pending the imminent arrival of 4.1final.
Right now I'm preparing the Users and Unleashed CDs and intend to post them tomorrow.
I don't have the SFS files for the kernel source, will have a go at creating them today, as they have to go into the CDs.
Extra drivers for 4.1
Tempestuous has posted extra drivers for 4.1 here:
http://murga-linux.com/puppy/viewtopic.php?t=34159
Tempestuous has the solution for wireless network connectivity if you have a EeePC.
Puppy 4.1 released
This exciting new Puppy can be downloaded from Ibiblio:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/
The 'devx_410.sfs' file (for C/C++ compiling) is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/sfs_modules-4/
The full announcement and release notes are here:
http://puppylinux.com/download/release-4.1.htm
...please read this, to decide whether you want to download the build with 2.6.21.7 (4.1retro) or 2.6.25.16 kernel. Most people will probably go for the later kernel, unless you have old hardware.
If you are upgrading from 4.00, at first you may feel underwhelmed, as the default theme, including desktop background, is unchanged. However, major changes have taken place "under the hood", greatly improving Puppy's hardware compatibility and support for hotplugging. Also, there are some very significant new applications -- read the release notes!
For those wanting Puppy Unleashed, the file 'puppy-unleashed-core-4.1.tar.gz' is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/
And the PET packages are here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-4/
DVB-USB firmware
After feedback from tempestuous and linuxcbon, I have included some firmware for DVB-USB devices.
Ok, there is probably a lot of hardware that won't be covered, but perhaps some coverage is better than none, and they are quite small files. The one common factor is that the 'dvb-usb.ko' module is required, so I have created a "firmware tarball" for this module, with these firmware files (in /lib/firmware):
Note that Pup 4.1 should create any devnodes automatically, as this pup uses udevd.
Here are some info links that linuxcbon provided:
http://www.linuxtv.org/downloads/firmware/
http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices
Countdown to 4.1final
I intend to build 4.1 final about 10 hours from now, then do several hours of testing on my PCs. If all looks ok, I will release it.
So, if there is anything urgent that you need to sneak in, kindly do so within the next 10 hours.
DVB-USB firmware
Forum member 'linuxcbon' has requested a particular firmware file for DVB-USB be included in Puppy. There is a website with more information on this:
http://www.wi-bw.tfh-wildau.de/~pboettch/home/index.php
Now this is interesting, an online script that will extract the firmware file from the Windows driver:
http://www.wi-bw.tfh-wildau.de/~pboettch/home/index.php?site=dvb-usb-firmware
As far as including firmware files in Puppy, I would need to know what files are required for each module. There is a 'dvb-usb'ko' module, but I presume many more for particular hardware.
Tabs wrong in Pmount
Rerwin reported that when no CD/DVD discs were plugged in, but a USB drive was plugged in, Pmount showed the USB drive under the 'optical' tab, when it should have been under the 'usbdrv' tab. In fact, Pmount should not have had an 'optical' tab at all.
I have implemented a generic fix to this, as it could conceivably happen for other categories than optical.
Playing WAV files
There are some complaints that when click on a .wav audio file in ROX, it doesn't stop playing. It seems that the 'wavplay' executable has this problem on some hardware.
I can't set the player to 'defaultmediaplayer' (which is Gxine) as Xine does not play WAV files properly on my laptop. So, I have set the player to 'pmusic', so you get a nice GUI -- this solution was suggested by forum member 'capoverde'.
ChmSee bug fix
Thanks to forum member 'liberomureddu' who reported this bug. File->Open in ChmSee (Microsoft CHM help viewer) did not work when run from the menu, but did when 'chmsee' run directly in a terminal. Fixed.
Limit of 2 extra sfs files
Thanks to forum member 'Béèm' who reported this.
I had introduced an option for the 'zdrv' sfs file to load as a layer, and the 'createpuppy' script is able to build Puppy with a separate zdrv file that will load inthis way -- however 4.1 is built with no zdrv, all modules built-in to the main sfs file. When I coded this in the /init script in the initrd, it introduced a bug, only allowing two extra sfs files to load(should be three).
Béèm tried to load OpenOffice, Filezilla and Wine sfs files, and although the BootManager was able to select all three, only the first two actaully loaded. Fixed.
JWM configuration bugfix
Forum member 'Kal' reported that there is a commented-out section at the beginning of /root/.jwmrc-tray, that upsets the JWM configuration application.
Ideally, we should fix the JWM config application, but I have applied the quick fix and removed the commented-out section. Note, the problem is due to there being two 'tray' tags -- although one is commented-out, the JWM config scripts do not understand this.
Pburn, Pfind
I have updated Zigbert's Pburn to version 2.0.9 and Pfind to version 4.4-1.
Network Wizard
I have updated to Dougal's latest, dated October 1st.
Abiword spellcheck fix
Thanks to forum member 'gray' for this one. Gray posted a fix here (which also applies to Puppy 4.00):
http://murga-linux.com/puppy/viewtopic.php?t=28643&start=213
bcm43xx module preference
After discussion in the Network Wizard forum thread, I have added a preference for the 'ssb' module when it and the 'bcm43xx' module are claiming the same hardware. The PREFLIST variable is in /etc/rc.d/MODULESCONFIG:
Further refinement to desktop drive icons
Rerwin has further refined the 'clean_desk_icons' script, and I made a further little tweak.
Today is Sunday 5th October, and my Perth Royal Show job has finished, so today I am spending most of the day on the Puppy project.
Amended retirement statement
Those who have tested 4.1rc may have noticed that the release notes have an amended "retirement" statement:
I have decided to bow out from my position as leader (also known as "Benevolent Dictator") of the Puppy Linux Project (held since I released v0.1 in mid-2003), and take a back seat. Version 4.1 is my final release as leader. A small group of trusted developers will take over, although the details are still to be worked out -- there are a couple of threads on the forum discussing this.
I won't be going away totally, and plan to focus on a "puplet" (derivative of Puppy) based on my "UniPup" concept and targeting specific hardware, probably one or more of the baby laptops. This will be a more part-time project than the hectic full-time pace that I have maintained over the last couple of years.
It is likely that I will keep working on some aspects of the "core" or "base" Puppy, primarily for my puplet but that will be useful for the mainstream Puppy.
Also, I will retain whatever copyright/trademark rights I currently have and continue with ownership of the puppylinux.com and puppylinux.org domain names. Plus, I will provide input to how and who takes over, hopefully without interfering too much. I see this as providing a kind of safeguard function -- I am mindful of other distros that have languished after the Benevolent Dictator left. Monitor my blog for updates on the transitional phase as I progressively retire.
I think this is a great opportunity, and Puppy will become better and better!
I have modified it in response to feedback sentiments and concerns expressed by many.
Bashdiff with GTK widgets
This is something we should checkout:
http://home.eol.ca/~parkw/index.html#gtk
Desktop drive icon improvements
With help from rerwin, who also discovered this bug, we have a fix for a CD/DVD icon remaining on the desktop although the disc is removed. This affects /sbin/clean_desk_icons and /sbin/pup_event_frontend_d scripts.
I have also improved the collision-avoidance code in pup_event_frontend_d, so that drive icons cannot be drawn almost exactly on top of each other.
Puppy 4.1rc
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1rc/
Note that this has Dougal's latest Network Wizard, dated September 25.
915resolution, mut2/Pmount, Pburn
Tempestuous has patched 915resolution again, dated September 25.
Jesse has provided a patch for Pmount, that fixes floppy drive detection when using his mut2 engine.
Zigbert's Pburn updated to version 2.0.6.
The PREFLIST variable in /etc/rc.d/MODULESCONFIG now gives preference to the ltmodem driver rather than the martian driver:
PREFLIST=' rt2500usb:rt73usb ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci martian_dev:ltserial '
Note, things are moving slowly, 4.1rc has fallen back another day.
Update on 4.1 schedule
I'm doing some testing tonight. As I'm currently working all day, I can only put in 2 - 3 hours in the evening. I anticipate uploading 4.1rc tomorrow evening (about 24 hours from now).
Note that with 4.1beta, everything is frozen except for fixing bugs. No upgrades of packages, unless they have a fix of a critical bug.
So, when I get home from work tomorrow evening, I will check the forum and my blog, in case anyone has posted some critical bugfix, then I'll build 4.1rc, do a bit of a test of it, then upload it.
Probably.
Regarding upgrades of packages, including Xorg 7.4, ALSA, SANE, XINE, etc. ... well, perhaps that will be done for 4.2!
Pbackup, Pburn, Pmusic
Pbackup is now version 3.1.4.
Pburn is now version 2.0.4.
Pmusic is now version 0.3.2.
Ayttm 0.5.0-81
Siddhesh sure is busy improving Ayttm! Upgraded only yesterday. Well, I reckon 0.5.0-81 will be the one that goes into 4.1rc.
Here is the recent changelog:
Sat Sep 20 2008 19:55 UTC [siddheshp] 0.5.0-81
- ChangeLog, configure.ac, src/chat_room.c:
Need to be more careful with my commits -- autocomplete for nicknames is
finally fixed.
Sat Sep 20 2008 19:00 UTC [siddheshp] 0.5.0-80
- ChangeLog, configure.ac, src/chat_room.c:
* Previous commit b0rked autocomplete for buddy nicknames
* Trying to delete from list even when a valid entry was not found in the chat
room
Sat Sep 20 2008 14:25 UTC [siddheshp] 0.5.0-79
- ChangeLog, configure.ac, modules/irc/irc.c, src/auto_complete.c,
src/chat_room.c, src/chat_room.h, src/chat_window.c,
src/gtk/html_text_buffer.c:
* Sort Chat room buddy list alphabetically
* Replaced strlen() with g_utf8_strlen() in autocomplete to cater for UTF-8
characters. We might need to look at this in other modules as well.
* Removed calls to strlen("literal") with the just actual length of the
literal
* Put autocomplete changes in chat_window.c in chat_room.c as well
* Linkify 3rd person messages as well
* Made chat window entry to be the same as chat room entry
Wed Sep 17 2008 19:38 UTC [siddheshp] 0.5.0-78
- ChangeLog, configure.ac, src/status.c:
Sort contacts and groups alphabetically
Pschedule bugfix
A problem with Pschedule was reported here:
http://www.murga-linux.com/puppy/viewtopic.php?t=22166&start=15
Pschedule uses 'crontab' (which is a Busybox applet), which stores information at /var/spool/cron/. However, when Puppy is installed to a USB drive, /var is not saved, so the crontab information does not survive a reboot.
I think that my original reason for not saving /var was to save space. Some stuff can accumulate in /var that does not need to survive a reboot. Also, sometimes some files are better off not surviving as they may interfere with correct operation at the next boot.
However, this behaviour is inconsistent, as the live-CD (with session saved to hard-drive) and frugal install do save /var.
I have modified /usr/sbin/snapmergepuppy so that /var is saved whenever a session is saved. This affects saving to any Flash drive.
Gparted bugfix
ext3 partition creation failure
In the Puppy 4.1beta feedback there was a report that Gparted failed to create a ext3 partition, but did succeed in creating a ext2 partition. I have confirmed this bug.
The problem is the content of /etc/mtab, that Gparted objects to, claiming that it was unable to determine whether the partition that is to be made into an ext3 f.s. is mounted or not. The content of /etc/mtab looked fine to me, however I do know how to fix this problem -- by not having an /etc/mtab file at all and instead just make it a symlink to /proc/mounts.
The "mtab problem" goes back to some fundamental mismatches, that probably in the long term will have to be solved. Firstly, Busybox is configured to not use /etc/mtab (for historical reasons, back when I did configure it to use mtab, thngs went very wrong) for its 'mount' and 'umount' applets.
Secondly, I configured 'ntfs-3g' not to use /etc/mtab, as I use the same binary in the initial ramdisk (which has the Busybox mount and umount).
However, the full 'mount' and 'umount' programs do use /etc/mtab, and also some utilities (such as 'eject' and 'mke2fs' reference /etc/mtab).
In Puppy, /bin/mount and /bin/umount are scripts, so I was able to juggle the above conflicts. My scripts write to /etc/mtab and everything seemed to work okay ...except now we have Gparted unhappy with what it is finding in /etc/mtab for some reason.
In the initrd /etc/mtab is a symlink to /proc/mounts, as this works for the various utilities (eject, mke2fs, etc.). I have now done this for the main Puppy filesystem.
To implement this, I have modified /etc/rc.d/rc.sysinit, /bin/mount and /bin/umount.
This is a small but fundamental change, that could have subtle or not-so-subtle ramifications. Or it might just fix the Gparted bug and have no other negative repercussions (I am inclined to this view). I am reluctant to make this kind of fundamental change at this stage, but it is necessary to fix the bug. I will do extensive testing before releasing the 4.1-release-candidate.
Slow startup
There is something else that we should do. Gparted can be very very slow to startup on some PCs that have a floppy drive interface on the motherboard but no actual floppy drive. Gparted does a scan at startup and gets stuck on the floppy probe, but does eventually timeout. What we need is a little wrapper, call it 'gpartedwrapper', that runs 'probedisk2' and puts up a little GUI that asks which drive you want to work on, then executes Gparted like this:
gparted /dev/sda
...which constrains the startup scan to only that drive.
Would anyone like to whip up such a little GUI?
Pmusic 0.3.1
I have upgraded Pmusic to version 0.3.1. Note, Pup 3.1beta has 0.3.0.
Network Wizard Sept. 18
I have upgraded the Network Wizard to the version dated September 18. Note, Pup 4.1beta has September 4.
Ayttm 0.5.0-78
I have upgraded Ayttm multi-protocol chat client to version 0.5.0-78. Pup 4.1beta has 0.5.0-77.
Incorrect f.s. info
Zigbert has described this problem here:
http://murga-linux.com/puppy/viewtopic.php?t=32882&start=30
He burns to a CD in multisession mode, then burns another track, but after mounting the CD the 'ls' command shows the old contents. The CD has to be physically ejected then reinserted then mounted to force the system to update the f.s. info.
I think this problem is only with the new libata PATA/SATA drivers, not with the old IDE drivers, so you won't have it on the 4.1retro Puppy.
I have just been sitting here for a few hours, trying all sorts of things to try to force a refresh without having to eject the CD, but no-go. This is a fundamental problem with the kernel and libata, and yet another thing they need to address.
ICS and PPPOE
Pup 4.1beta has both the 'Roaring Penguin' and the 'Pppoeconf' applications for PPPOE connection to the Internet. I put in both as it is still not determined how well, or even if at all, Pppoeconf works.
However, the Internet Connection Wizard main dialog, that comes up when you click the 'connect' icon on the desktop, was a bit confusing as it did not clearly offer the two alternative PPPOE applications. I have remedied that.
Firmware loading fixed
With help from 'Minnesota' on the Network Wizard forum thread, we identified and fixed this bug.
I have various network devices that require firmware to be loaded, but the firmware files are located in /lib/firmware. However, Minnesota and some others have hardware that has firmware in a subdirectory, like this:
/lib/firmware//
This firmware was not getting loaded. I have fixed the script /sbin/pup_event_backend_firmware, which is what udevd calls when firmware is to be loaded.
Xsane and SCSI
Xsane is a bit 'insane' when detecting a SCSI scanner.
I have added a 'SCSI' button to the initial orange dialog box, which loads the 'sg' module then starts xsane.
The dialog box also has some suggestions to work around the insanity of Xsane's autodetection.
SM Print Preview crash
I recall now. Pup 4.00 has SM 1.1.8 and that has the same bug. So, I applied this workaround:
Well, it isn't nice, but I have removed "File -> Print preview" from the menu. As it doesn't work, there's no point in having it, and no point in having SeaMonkey crash unexpectedly. For the record, I commented out line 360 in /usr/lib/seamonkey-1.1.8/chrome/comm/content/navigator/navigatorOverlay.xul
This is documented in my blog:
http://www.puppylinux.com/news/news400a7-400b.htm
I also wrote that Print Preview does work in SM 2.0alpha1, so we do have something to look forward to!
Anyway, I have also disabled Print Preview in SM 1.1.11 in Pup 4.1.
4.1 release schedule
Zigbert is doing some mods to some of his apps and asked about getting enough time to do it for 4.1-final. I had previously mentioned September 21 as the final release date, as my Royal Show job starts on the 22nd.
However, that date can fall back. I can still put in two or three hours on Puppy in the evenings. When it looks like everything is mostly ready, probably sometime after the 21st, I'll upload a "rc" (release candidate) for anyone who wants to do a quick sanity check, then the final soon after.
Rerwin has reported the SeaMonkey crashes on Print Preview. I seem to recall that happening in an earlier version of Puppy also, and upgrading SM fixed it ...I think. Now we have it back again. Well, I'll look into it, but can't guarantee anything.
snapmergepuppy bugfix
Federikson posted a report about a bug in /usr/sbin/snapmergepuppy, but that is in 4.00 and is fixed in the 4.1 alphas and betas.
However, while I was examining the script I noticed another bug. The script tests if 'pup_eventd' is running then decides if X is running, but that was relevant back in the early alphas and now the test should be for 'pup_event_frontend_d'. Fixed.
Puppy 4.1beta
This is the 'standard' Puppy, version 4.1beta with 2.6.25.16 kernel. Updated release notes are in the live-CD. Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1-beta/
Note, due to the roll-back of ffmpeg and xine-lib, the devx_408.sfs is different from devx_407.sfs.
If you have tested 4.1retro-beta, beware that Puppy will have copied pup_408.sfs to the hard drive (even if you declined when asked about that at shutdown), so you have to delete that file first -- otherwise you'll get a kernel panic.
wpa_supplicant
Tempestuous has compiled a more recent version of wpa_supplcant, quoting from his post in the Network Wizard thread in the forum:
Well I don't have firm answers, just suggestions.
It seems that generally the new rt73usb doesn't like hidden SSID's.
I think it's time to upgrade wpa_supplicant. The latest stable version now attached.
This package contains only the application files, and does not overwrite any configuration scripts.
I have enabled the "ipw" -D parameter for compatibility with the new Realtek rtl8180 and rtl8187 drivers. Of course, 99% of modern Linux wifi drivers use the standard "wext" -D parameter.
DON'T use this version of wpa_supplicant in versions of Puppy older than about 4.1alpha5, because this new versions lacks the "Ralink" -D parameter necessary for the old rt61 and rt73 drivers.
I have built 4.1beta (with 2.6.25.16 kernel) using tempestuous's wpa_supplicant v0.5.10. The 4.1retro will continue to use the older wpa_supplicant.
Guy-on-the-bike?
I will not be designing a new theme for 4.1, nor using anyone else's theme. However, Lobster has suggested that there should be some differentiation from 4.00, and he suggested the guy-on-the-bike background instead of the Antartctic/Arctic scene.
Here it is:
...what do you reckon? Down to /usr/share/backgrounds then try it. Should I use that for 4.1?
ffmpeg/xine-lib roll-back
I have decided to be extremely cautious and conservative for 4.1.
There is something not quite right about the latest builds of ffmpeg and/or xine-lib in the recent alphas. Playing a RealMedia video on my laptop, sound is jumbled, whereas it plays fine in pup 4.00.
Zigbert has also reported a problem with mp3 conversion.
So, I have rolled back to ffmpeg/xine-lib used in pup 4.00. It knocks about 1MB off the live-CD, as the faac, faad2, x264, and xvidcore packages are not needed. People can add enhancement PET packages afterward for extra libraries support.
I want a small Puppy, that satisfies most people, and the ffmpeg/xine from 4.00 is the best compromise I think.
mp3lame
Zigbert reported that ffmpeg does not seem to be configured with --mp3lame, however, this is how it was configured:
# ./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
Actually, I am seriously thinking of rolling back to the ffmpeg package used in pup 4.00. I think that is a good compromise, small yet covers most video/audio formats. I was listening to many people who said they wanted this or wanted that, and the latest ffmpeg is very bloated -- and I don't even think it works as well.
4.1retro-beta uploaded
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1retro-beta/
This has the 2.6.21.7 kernel, and is conservatively configured for maximum compatibility on old hardware.
I did not put in the i810_drv.so from Puppy 3.01, as that is Xorg 7.2, whereas Puppy4 has Xorg 7.3, and the intel_drv.so is supposed, it seems, to superceed the i810_drv.so module. All my hardware works fine with the intel_drv module, so I'm reluctant to put in an older driver.
I have put in both Pppoeconf and Roaring Penguin PPPOE. But possibly only one will remain in the final. Ideally, I would like to get Pppoeconf debugged.
The devx_407.sfs will work, just rename it to devx_408.sfs.
Module preferences list
Tempestuous posted this to the Network Wizard thread on the forum:
Dougal :
Turns out there is also overlap between orinoco_nortel and hostap_plx, orinoco_plx and hostap_plx, orinoco_pci and hostap_pci, and orinoco_tmd and hostap_plx! Tempestuous, where art thou?
It seems the hostap drivers have been updated more recently, so maybe they are the better ones?
I have a new job, so I only have enough time to quickly scan the forum these days.
Yes, that overlap is because the Intersil Prism2 chipset is quite similar to the earlier Orinoco chipset. So some (not all) Orinoco-based devices will work with the hostap family of drivers. Certainly the hostap drivers are more advanced, but I can't say for sure whether they work better. If the answer is yes, then we need to ask Barry to change the PREFLIST line in /etc/rc.d/MODULESCONFIG as such:
:
PREFLIST=' rt2500usb:rt73usb orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci '
I have tentatively implemented this. /etc/rc.d/MODULESCONFIG now has this:
PupDial
Rerwin submitted a fix for PupDial after erasing a previous modem selection. I have applied the fixes to /usr/sbin/pupdial and /usr/sbin/modemtest.
Missing Xorg modules
HairyWill reported that Xorg reported these missing modules: sil164.so, ch7xxx.so, ivch.so, tfp410.so.
Xorg in Puppy is cutdown and some X servers are missing. The above though are very small, so I have put them in. The relevantpackage is 'xorg_xorg_servers-7.3-2'.
HairyWill, would you mind testing 4.1retro-beta, which will have these, and check that it now works -- it is possible that after those modules have loaded there may be an attempt to load more.
I'll probably upload 4.1retro-beta within 24 hours of now, the 'normal' 4.1 with later kernel toward the end of the week.
Lucent modem device, prism54 firmware, pppoe
I'm confused. The docs in the source state that the correct device name is /dev/ttyLTM0 for the 2.6.kernel. For the old 2.4 kernel it is /dev/ttyLT0, but the makefile allowed ttyLT0 to be retained for the 2.6 kernel -- but that required an edit of 'Makefile' and I have not done this when building the module for 4.1.
But, rerwin says that the driver asks udevd to create /dev/ttySLTM0 ...very odd. Anyway, assuming that to be so, I have made relevant changes to the 'firmware tarball'.
As tempestuous has advised, I have modified a line in 'firmware.dep.2.6.25.16' to 'prism54_firmware:prism54.ko,p54pci.ko,p54usb.ko'. Note that I did not apply this modification to the 4.1retro build with the 2.6.21.7 kernel.
A note about PPPOE. This is still up in the air. The people who have tested this in an earlier alpha and reported problems, did not stay around to help with bugfixing. The latest 'Pppoeconf' package, launched via the desktop 'connect' icon, is in alpha7 but has not been tested. If noone tests it, how can I fix it? If it doesn't work, or noone verifies that it works, I may revert to the Roaring Penguin solution in 4.00 -- which has a more primitive GUI.
4.1beta
Lots of delays... probably it should be out later in the week, maybe Friday.
Battery monitor, Pburn, Network Wizard, Trash
One thing that was missing from the 4.1 boot scripts was code to explicitly load the battery, ac, thermal and fan modules. Kirk provided this code, that was included in 4.00 (in /etc/rc.d/rc.modules2), and I have copied this into /etc/rc.d/rc.sysinit in 4.1. Now, running 4.1retro, I get the battery monitor when running on my laptop.
Zigbert's Pburn has been upgraded to version 2.0.3.
Dougal's Network Wizard has been upgraded to version 20080904.
The Trash applet is updated by disciple to version 0.3.2.
2.6.21.7 SCSI kernels
I have compiled the SCSI kernels for 4.1retro. You can find them here:
http://puptrix.org/sources/kernel-2.6.21.7-pup4.1retro/scsi/
There are three kernels, with different groups of SCSI drivers built-in (the rest as modules). Built-in makes it easier to boot from a SCSI drive.
If you want to know more about the history of this, type "SCSI" into the search box at left side of this blog.
Pmount fixed
Thanks to information provided by eprv, I was able to fix a bug in Pmount.
Eprv has a CF card with only a single Linux swap partition, and this caused Pmount to crash. In fact, Pmount will crash for any drive without a usable partition or "superfloppy" filesystem.
I put in a check for this condition, and verified it works by creating a USB drive with only a swap partition.
2.6.21.7 patched source
I have uploaded the patched source for the 2.6.21.7 kernel used in 4.1retro, as well as all the 3rd-party drivers, Ted Dog's puptrix site:
http://puptrix.org/sources/kernel-2.6.21.7-pup4.1retro/
I cannot guarantee that kernel modules compiled for Puppy 3.01 and 4.00 will work with 4.1retro, as there are slight differences in the kernel configuration, as explained in this earlier blog post:
http://puppylinux.com/blog/?viewDetailed=00338
Ayttm
I have upgraded from version 0.5.0-74 (in 4.1alpha7) to 0.5.0-77. The main thing is that Siddhesh has fixed Yahoo file transfer. I think it was mentioned in the forum that there is still some problem with MSN, but overall Ayttm is looking good.
xfs partition trouble
eprv, I looked at the gtkdialog file, there is an empty frame:
Pmount was unable to fill this with the correct information. I don't know why. Too difficult for now to figure it out theoretically. I would have to create an xfs partition to test on, and I have no knowledge of xfs at all.
Dialup deliberations
I have started to look at some suggestions from rerwin, posted Aug 30:
1.
'cd /sbin' near end of pup_event_backend_modprobe. I have done it, although I don't understand it.
5.
'rm -f /dev/ttyS_ESS0 /dev/ttySLT0 /dev/ttyS_PCTEL0 /dev/ttyLTM0' is now in /usr/sbin/modemprobe_erase
Rerwin also posted about the dgcmodem, Sept 2. Ok, I have put in the "firmware tarball". Rerwin, one thing I notice, you advise 'Dgcmodem:dgcusbdcp.ko' but the firmware directory is 'dgcmodem' -- do you want it to be an upper-case 'D'?
Some of the other points raised by rerwin I will look into, but dialup will still be a work-in-progress when 4.1final comes out. What needs to happen I think is that Unleashed needs to be setup in a revision control system (CVS/SVN/GIT) and the "trusted core developers" need direct access. These developers are competent guys and should be able to modify directly without going through me. One thing that I'm acutely aware of sometimes -- I am jumping from topic to topic, and sometimes my assessment may be shallow or miss some point. For example, I was busy this morning rewriting /sbin/pup_event_frontend_d, after that did a few other small things, then just now got into vetting rerwin's recent contributions and ideas. Then I have to move on, have something else to test tonight. I reckon in the future, those guys who really know what's going on inside Puppy, who have a good knowledge of scripting and a track record of excellent contributions, should be rewarded and allowed to have more direct power.
After 4.1final is out, go for it guys! I know there is a thread discussing how to set things up after I have "retired", but I haven't read it yet -- I decided to wait awhile, give it time to see if any firm ideas/strategies have emerged and read the whole thread in one go. Then maybe throw in my 2 cents worth of opinion (in addition to the above!).
Hotplug fix
There was a report that plugging in two USB drives simultaneously they did not appear on the desktop. So, I examined /sbin/pup_event_frontend_d, the daemon script that detects when block devices (that is, drives) are added or removed and updates the desktop drive icons. I ended up giving it a complete overhaul.
I had also discovered a problem with the 2.6.21.7 kernel. I had udev rules so that 'udevd' would signal pup_event_frontend_d whenever a block device is added or removed. However, as the 2.6.21.7 kernel uevents do not set the DEVTYPE variable, I cannot specify that in the rules, which resulted in multiple signals being sent to pup_event_frontend_d, which confuses the script.
On top of that, pup_event_frontend_d has a complex structure. It has to wait on block events from udevd, but it also has to have its own four-second loop as some devices (ex., CD/DVD media) need to be polled periodically. For sometime now I have realised that it would be better to abandon some of the sophistication and just have a simple polling loop. That is, uedevd no longer has rules to signal pup_event_frontend_d. The script is just in a simple two-second loop monitoring /sys/block for changes, and also performing four-second probes.
This has greatly simplified the script, and it now handles multiple simultaneous hotplug events. I think that I may have fixed other potential anomalies also.
So, score a point for the old-fashioned way of doing things. Primitive and simple. I don't think that it uses much more system resources either.
Pbackup, Pburn, Network Wizard
Zigbert's app's updated:
pbackup-3.1.3
pburn-2.0.2
Dougal has updated the Network Wizard:
net_setup-20080831
/etc/rc.d/rc.network
Dialup disconnects
Zygo has reported this for 4.1alpha7, and reports that /etc/ppp/chap-secrets and /etc/ppp/pap-secrets has to be manually created, otherwise 'ppp' will disconnect after a few seconds.
This is an old bug, and was fixed. I have hunted back through my blog, and at:
http://puppylinux.com/news/news400a7-400b.htm
found where I had reported the solution.
Quoting from that page, April 4, 2008:
Ok, I found the problem. Fairly recently, I noticed that the 'wvdialconf' utility, which is executed as 'wvdialconf /etc/wvdial.conf', output a message that /etc/ppp/options may conflict with /etc/wvdial.conf. So, I made a small but fatal change in the pupdial script, I renamed /etc/ppp/options to something else before executing wvdial, then renamed it back afterward.
Now, looking in /etc/ppp/options, it has some interesting things, particularly "usepeerdns". Now, it's my guess that the pppd daemon reads that file and if it doesn't exist then doesn't fetch the DNS from the ISP.
/etc/ppp/options is a file that I have always had in Puppy, it's not part of any particular package. It goes right back to the very early days pre-0.1 when I was first trying to get dialup to work. We need to study the relationship between this file and wvdial and pppd, but for now I have just fixed it by leaving /etc/ppp/options alone.
Interesting, this also fixes the problem I had in (400) alpha7 in which /etc/ppp/chap-secrets and pap-secrets was not getting written to, so I have removed that "fix" from pupdial also.
So, if zygo and others have this bug still, it would seem that you are not using a pristine 4.1alpha7? You need to examine my blog and find out what has one wrong in your case.
Meet Sally
My daughter's two little dogs, April and Vincent, have already featured on this blog. Here they are again:
They have had offspring, born 10th August, five little pups. With the unknown genetic heritage, there are some interesting variations. Here are four of the pups:
Two are black, two white, one is light brown. The biggest black, a boy, the smallest is also black, a girl. I have taken a liking to the smallest, in the above photo and have already started calling her "Sally".
Both the large black and the brown one have pronounced wrinkles on the nose -- you can make that out in the pup on the right in the above photo.
I have been offered one, and at this stage it looks like I will be getting Sally. Mum and Dad will be "fixed" soon, and I guess Sally will get fixed also. Anyone know the optimum age for getting that done?
Misc. fixes, questions
4.1alpha7 has ntfs-3g (NTFS filesystem driver) version 1.2812, however there is still an older version in the initial ramdisk (well, not that old, it was upgraded in April this year). I have now upgraded the static 'ntfs-3g' driver in the initial ramdisk to version 1.2812. This will have an effect if you are booting from NTFS or have a pup_save in an NTFS partition.
I'll post the following to the forum 4.1alpha7 bugs thread also:
eprv has reported difficulty with the 'xfs' filesystem and Pmount. I have looked through Pmount theoretically, cannot see any problem. It seems that gtkdialog3 has a problem. eprv, you need to send me the content of /tmp/pmountdlg.txt_${MYPID}, where ${MYPID} will be some number. You could gzip it and post it to the forum.
zygo, reporting on PupDial, wrote this:
Once I enter the isp settings it also needs chap-secrets & pap-secrets setting to make ppp last more than a second.
What does that mean?
zigbert has reported a strange problem:
The CD must be ejected and reloaded before before mounting shows recent burnt datas.
There is a problem, or so it seems, with old information being retained when it should have upated. You have done an 'eject'. However, after burning, and before mounting the drive, use 'dd' to read from the drive -- that might force the directory/file information to update:
ALSA fix
I have been haunted with ongoing trouble with ALSA on my laptop. The problem I have had with ALSA version 1.0.16 is that on first boot sound is muted (and cannot be un-muted with a mixer). I have to run the ALSA Wizard, then sound works on subsequent boots.
I did report this awhile back on my blog. The Wizard has a function, set_mixers(), that is the key to get sound to un-mute on my laptop. I have this function extracted to /etc/rc.d/functions4puppy4.
However, I have still been having problems. Someone on the forum posted recently that sometimes not executing 'rc.alsa' at bootup fixes the problem (tempestuous?). I currently have this in /etc/rc.d/rc.services:
I'm not excuting rc.alsa. Works fine on my laptop, will test on other PCs.
Note, /etc/rc.d/rc.shutdown runs 'alsactl store' to save settings to /etc/asound.state.
4.1 release schedule
4.1beta should be out by this coming Saturday or Sunday (6th, 7th September).
I start work at the Royal Show on 22nd, and would really like the final to be out by then. So I will set the 4.1final release date for 21st September.
There will be two live-CD iso's, 4.1retro with 2.6.21.7 kernel and 4.1 "normal" with 2.6.25.16 kernel.
Madwifi and 4.1retro
I got a very odd bug with Madwifi. I don't know if this only applies to 4.1retro and the 2.6.21.7 kernel.
I earlier reported that my PCMCIA-USB adapter card works fine in 4.1retro. That was the first build, and I only had the modules that came with the kernel, no 3rd-party modules.
Yesterday I compiled all the 3rd-party modules, Madwifi included, and built 4.1retro again. Booted it, this time my PCMCIA-USB card did not work. Nor did my SD card. I tested with 'hotplug2stdout' and found that these interfaces were dead, no kernel uvents generated.
I traced it down to the Madwifi 'ath_pci.ko' module. If I blacklist it, then load it manually later, then my PCMCIA card and SD card work. Weird, as far as I can make out, ath_pci is grabbing control of PCI hardware interfaces and preventing the other interfaces from working.
I tested this hypothesis by putting a hack into /sbin/pup_event_backend_modprobe. This is the script that 'udevd' calls everytime it wants to load a module. The hack is that if the module is 'ath_pci' then 'sleep 5'.
This does not slow down bootup because of the way udevd works. The udevd daemon spawns multiple modprobe executions, attempting to boot as fast as possible, so the "modprobe ath_pci" is just one parallel process.
Anyway, the hack worked, so I have put it in as a permanent feature. It seems likely that this bug applies to later kernels also.
Just a reminder though, our 2.6.25 and later kernels have 'ath5k' which replaces Madwifi, but 4.1 has Madwifi as a throwback in case ath5k does not work (you will need to make some changes in the BootManager to disable ath5k and enable Madwifi).
HSF modem drivers for 4.1retro
I have compiled these and intend to include them in the 4.1retro.
There were eight modules, but I had to remove 'hsfhda.ko' as it requires 'snd-hda-codec.ko', but this is only available in an older version of ALSA. The hsfmodem package did compile a 'snd-hda-codec.ko' module but it is incompatible with the version of ALSA in Puppy (1.0.16) and has an undefined symbol.
Retro 4.1 works
Well, almost. I built 4.1 with the 2.6.21.7 kernel and it booted up nicely, got the desktop. Only two things seemed to be wrong -- sound and desktop drive icons.
The sound problem I think I can fix. The kernel has ALSA version 1.0.14 modules, whereas 4.1 expects 1.0.16. So, next job is to update the modules.
The main thing that I got stuck at before when I tried the 2.6.21.7 kernel, is the desktop drive icons do not respond to hotplugging.
I plugged in a PCMCIA card with two USB sockets on it, and the card was recognised, the two USB ports were recognised ...great so far.
I then plugged in a USB pen drive and it was also recognised, but it's icon did not show up on the desktop.
I tracked down the problem. The 2.6.21.7 kernel does not set the 'DEVTYPE' variable inits uevents. I have a udev rule in /etc/udev/rules.d/50-udev-puppy-basic.rules that expects this to be set to 'disk' and also /sbin/pup_event_frontend_d expects it to be set.
I have implemented a workaround.
I'm running the retro right now!
Later I have to go and compile the ALSA 1.0.16 and 3rd-party modules, then do another build and test that. Need to test wireless to -- currently just using ethernet cable.
My intention is, if 4.00 works for you then 4.1retro will to. In fact, I'm wondering about something -- there were some people who could not upgrade from Puppy2 because the 2.6.21.7 kernel did not work on their hardware -- I wonder if that is because of tickless being enabled? Anyway, it is now off, so that's one less compatibility problem.
Retro kernel for 4.1
Awhile back I tested the 2.6.21.7 kernel with 4.1alpha, but there were some problems, I don't recall exactly what.
Anyway, today I decided to give it another go. My intention is to build a 4.1 "retro" with the 2.6.21.7 kernel, which will be configured almost the same as in 3.01 and 4.00. Then, the "standard" 4.1 can be the latest 2.6.25.x with some goodies like libata-PATA and SMP turned on.
I have embarked on this. I have made these changes to the kernel configuration compared with that used in 4.00:
Regarding tickless, both pup 3.01 and 4.00 have this enabled, but after recent research I think it better disabled for a "retro" kernel.
Note also, I patched the kernel source with Squashfs 3.3 and Unionfs 2.4. There were also some patches required for Aufs and for Lloyd's Multitech GPRS.
t2-to-puppy support scripts
As kirk and others are interested in the T2-route for creating Puppy, I am making available some scripts that I whipped up back when I used T2 to build all the base packages for Puppy 4.00.
I have created a thread on the forum and uploaded the scripts there -- or rather, I'm trying to. First try, I got "400 bad request" -- so trying again.... nup, now get "page load error". Oh well...
UPDATE: The forum started working again, this also now in forum thread:
http://murga-linux.com/puppy/viewtopic.php?t=32972
I have uploaded the scripts, here, as 't2-to-puppy-scripts.tar.gz':
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/t2-dingo/
And here is the content of the README file in that tarball:
b43legacy module
You can try this module if the newer b43 or the older bcm43xx modules do not work.
However, the b43legacy module is not listed in /etc/networkmodules and hence not listed in the Network Wizard. I have fixed that.
However, for now, probably you can try the b43legacy module by choosing it in the BootManager and blacklisting the others.
Binary compatibility with a major distro
I'm thinking that after 4.1 and 4.2, it might be wise to move back to binary compatibility with one of the major distros. It is so incredibly time consuming compiling packages. And, you have probably noticed how many times I am recompiling the 2.6.25.x kernel. It is better to leverage off all the hard work that goes into a major distro I think.
After releasing 4.1 and shifting one step closer to retirement, I will be working on my own puplet that targets one or more of the baby laptops. I might reconstruct Unleashed and the 'devx' based on packages from a major distro -- but not necessarily Slackware, perhaps the upcoming Ubuntu 8.10 'Intrepid'. What do you think about choice of distro?
If I do rebuild Unleashed and devx, I'll make it available of course, if the main Puppy developers want to adopt it.
SCSI scanner problem
dogone has tested a SCSI scanner with 4.1alpha7, detected but unusable.
Question: is the 'sg' module loaded?
Run 'lsmod' in a terminal to find out.
I have never tried this, but it seems that you can start xsane specifying what device to use, for example:
# xsane microtek2:/dev/sg3
I think to, you can link /dev/scanner to the device you want to use. Perhaps try this one first:
# ln -sf /dev/sg3 /dev/scanner
then start xsane:
# xsane
xsaneshell missing
Raffy reported that Xsane does not start from the menu in 4.1alpha7, due to missing /usr/bin/xsaneshell. Fixed.
If you are testing 4.1alpha7 and want to test Xsane, just open a terminal window and type 'xsane'.
Also, the menu entry had moved from Graphic to Multimedia, so I have moved it back.
libavformat.so.51
I have just had a quick look at the feedback thread for 4.1alpha7. /usr/lib/libavformat.so.51 is missing, needed by Mplayer PET package.
To fix this, go to /usr/lib (using Rox) and make a copy of libavformat.so.52, named libavformat.so.51.
Puppy 4.1alpha7
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha7/
The 2.6.25.16 kernel is configured as what I will call a "compromise kernel". What I am particularly interested in, is those people who tested the "normal" and "conservative" kernels in alpha6 and experienced that their computer only booted or shutdown with the conservative kernel -- how will you fare with this compromise kernel? I would prefer to release 4.1 with just the one kernel (plus some SCSI kernels for those who need to boot from a SCSI drive), but if it turns out that we do have to offer the conservative kernel as well, then so be it.
Kernel drivers updated
When I compiled the 2.6.25.16 kernel, I updated these:
aufs 20080825
ntfs-3g 1.2812
martian 20080625
Zigbert's apps
I have updated zigbert's applications:
Pbackup 3.1.2
Pburn 2.0.1
Pfilesearch 1.9
Pfind 4.3
Pmusic 0.3.0
2.6.25.16 kernel
The patched source and 3rd-party sources are here:
http://puptrix.org/sources/kernel-2.6.25.16/
I have also partially updated the package source repo at:
http://puptrix.org/sources/alphabetical/
mmmumph...
If any of my replies over the next few days are a bit grumpy, you'll know why.
This afternoon I had two teeth extracted. Quite traumatic. They were two back teeth, one had four roots. I've got a fairly small mouth, the dentist has big fat fingers, so he was muttering all the way through. My heart sank when I heard the "snap" -- both teeth broke when pulled, so he had to dig the roots out.
I've got prescriptions for antibiotics and painkiller. He said it will be a bit uncomfortable for a few days -- which may be an understatement, as the chemist told me the painkiller (Panadeine Forte) is extra strong.
How on earth am I supposed to eat anything? I have a bowl of rice and lentils sitting in front of me, not game to tackle it yet.
2.6.25.16 kernel
I mentioned recently that I downloaded about half a dozen kernel SMP .config files, and found that none of them had "tickless" enabled. Today I did a search for "config_nohz" (UPDATE: that should have been 'CONFIG_NO_HZ') and found this:
June 27, 2007:
Dave mentioned that Fedora Core 7 32-bit is now shipping with
CONFIG_NOHZ=y and CONFIG_HZ=1000.
CONFIG_NOHZ is known to break suspend and resume on some machines. These
problems are being fixed over time, but that's a risky decision for a
distribution to switch it on by default.
The 2.6.25.16 kernel is out, and reading the changelog there are important bugfixes. A couple are to do with hanging at bootup, another is to do with a bug in "jiffies" -- which I know nothing about but I do know that it is a key part of some modem drivers such as ltserial.
So, today I will go through the entire exercise again, all the 3rd party drivers also, this time with tickless disabled. I might bring out just the one kernel this time, for alpha7.
Pmetatagger
Plinej has released a upgrade to Pmetatagger, now at version 2.0:
http://murga-linux.com/puppy/viewtopic.php?t=24291
Puppy GPRS
Lloyd has generalised his GPRS internet connection package to work with GPRS hardware other than the Multitech modem.
He created it as a PET package, posted here:
http://murga-linux.com/puppy/viewtopic.php?t=32710
I have converted this into a "firmware tarball", which will install if the 'ti_usb_3410_5052.ko' module loads. However, other hardware situations may not use this module, so I have created /usr/sbin/pgprs-shell that is launched when 'GPRS Setup' is chosen in the Internet Connection Wizard -- this shell script will install the firmware package if not already, then run /usr/bin/pgprs-setup.
I decided against having the pgprs "firmware tarball" pre-installed, as it has scripts in /etc/ppp/peers that may interfere with analog dialup.
See my original blog post:
http://puppylinux.com/blog/?viewDetailed=00229
Pburn, Pfind, Pmusic
These are all zigbert's applications:
Pburn upgraded to v 2.0.0.
Pfind upgraded to v4.2.
Pmusic upgraded to v0.2.2.
Ayttm
I have upgraded to version 0.5.0-74, dated Aug 19. I think there are still some outstanding issues with Yahoo and MSN, but I read in one of the forum threads that Siddhesh is a bit busy with his regular job right now.
Network Wizard
Dougal has been steadily improving this. I have put the latest, dated August 23rd, into Puppy.
If you wish to test the latest, here is the thread:
http://murga-linux.com/puppy/viewtopic.php?t=31522
Dougal also created an improved frontend for the desktop 'connect' icon (dated Aug 17). This is a script that resides at /usr/local/apps/Connect. I have also put this into Puppy.
Scanner works
I was lacking a scanner to test with. I have an old parallel-port Genius ColorPage VividPro II, but it seems to have given up the ghost.
But, I do have a couple of USB multifunction printers that were given to me because they no longer print. I was cleaning up the place a bit a few weeks ago and put one of these on the verandah, intending to throw it out. It's an Epson Stylus CX5100. I brought it back inside, and 'sane-find-scanner' recognised it.
But Xsane (v0.995) gave a segmentation fault, just like Raffy reported. I tried the old Xsane v0.991 out of Pup 2.17, and it works. So I compiled v0.994, and yay that works.
Scanner test
Is there anyone who has a working scanner in 4.1alpah6?
There was one report of a USB scanner not working. Did it work with earlier puppies? Is it supposed to work with Sane?
If you have a USB scanner that should work but doesn't -- and this is important, it is no good reporting that your scanner does not work in 4.1alpha6 when it is not supported by Sane -- could you try this utility:
# sane-find-scanner
Here is the man page for this utility:
http://www.sane-project.org/man/sane-find-scanner.1.html
Note, there are still some unresolved issues, so it looks like the next release will be 4.1alpha7.
Theme for 4.1
I have decided to leave it the same as 4.00. Coming up with a theme that looks as nice is no mean feat, so instead I am treating it as the "Puppy4 signature theme". After all, it is really the newcomers that we want to give a good initial impression to, and they will not have seen 4.00.
ltserial modem driver
Rerwin reported this:
5. Lucent modem with ltserial sriver: Some success! The ltserial modem will work only in the conservative/uniprocessor iso. In the SMP iso, even with the nosmp parameter, probing and connecting to internet causes Puppy to freeze, necessitating a "reset".
I wonder if it is because the SMP kernel is configured with the "tickless" option? But then so is the 2.6.21.7 kernel used in 4.00. Rerwin, does the 'ltserial' module work in 4.00?
SCSI scanners
Dogone reports that Microtek E6 and HP PhotoSmart C5100A SCSI scanners do not work in Puppy "since 4.0".
The initial dialog /usr/bin/xsaneshell only asks if you have a USB or parallel-port scanner, as back then I thought that SCSI scanners were as scarce as hen's teeth. Anyway, you can press either button, they don't do much, just start /usr/bin/xsane.
So, the real problem is, why doesn't Xsane find dogone's scanners? -- it reports "no devices found". 4.1 does not include SCSI modules, so you have to use one of the SCSI kernels. If you are running Puppy with a SCSI kernel, then I have no idea what the problem is.
Quite a long time since I tested a scanner in Puppy, haven't done so for any of the 4.1alphax series. Anyone else tried 4.1alpha6 with a USB or parallel-port scanner?
Ethtool
Dougal has requested ethtool be in Puppy. Ok, it will be in 4.1beta, coming soon.
Man page:
http://gd.tuwien.ac.at/linuxcommand.org/man_pages/ethtool8.html
915resolution patched
I had patched the source of 915resolution 0.5.3 to support 1024x600 (945GM chipset) in the Acer Aspire One laptop. This is in 4.1alpha5 and 4.1alpha6.
Tempestuous has further patched the source to support the G33 (GMA3100) Intel chipset, device id 29c0:8086.
This latest patched version will be in the next Puppy (4.1beta).
You can try it now, tempestuous has posted it in this thread:
http://murga-linux.com/puppy/viewtopic.php?t=32462
Note, I plan to upload 4.1beta sometime around the middle of next week, 27th-28th.
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
UPDATE: rarsa
...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 pulle
Barry's Blog
The proposed 4.2 teamI am very uncomfortable that I am forced into the role of assessing people for roles in the future 4.2 team.
I have posted some thoughts in the previous blog post, and Lobster has reflected some of this in the wiki:
http://www.puppylinux.org/wiki/archives/old-wikka-wikki/categorycommunity/puppy-42-deep-thought
However, I am not the one to decide who leads the team, as I am supposed to have stepped back from any leadership role. So, I have made some preliminary recommendations only.
The list of interested parties can firm up over the next week, perhaps even those concerned can have some private dialog and come to a consensus. Then a forum thread can be started to seek a consensus from the wider Puppy community.
Regarding building a Slackware-based 4.3, or anything else for that matter, it is the kind of thing that someone can "just do". Perhaps check that two people aren't going to do the same thing first though. If someone just presented it completed, done, built from 4.1, then it immediately becomes a prime contender for the basis of 4.3. It would have to be a Unleashed build system, with packages rebuilt from Slackware packages, not a remaster. The 'devx' component also!
The way ahead for Puppy is for individuals (or very small group) to "take the bull by the horns", get stuck in and do something. Then present the result.
Partial report on what I have read
This is going to be one of my aggravated posts, that I am sometimes prone to.
I have read part-way through the discussion on post-4.1, and a few things are emerging. Firstly, regarding tuuxx -- I do not want to target anyone, but ttuuxx has repeatedly posted comments that are incredibly superficial. For example:
"The 3 series just worked for myself better than any 4 series, I dislike the new pmount and shoving the floppy as default on my pc, which I haven't used the floppy since I made this pc around 12 months back, an extra click about 50 times a day, or the crappy clipboard downgrade on the 4.0 series that drives package producers like myself nuts. Really to tell you the the truth the only good thing on series 4 over 3 is is the default jwm theme. But I instally replace that anyways with Icewm."
Firstly, the Pmount in 4.1 can readily be configured without tabs, just hit the 'preferences' button. Secondly, the clipboard sync program used in earlier puppies was removed for good reason, but it is a PET package and can easily be installed -- without it, the clipboard works as per all other Linuxes/Unixes and just needs to be understood. If there is a majory wish, then it could be put back as default in 4.2.
All of the above has been explained to ttuuxx before, but he remains stuck with the same mantra. The assessment based on these comments that Puppy3 is better, is so incredibly superficial.
Then there is the issue that Puppy 2 or 3 works on some hardware whereas 4 doesn't. Yeah, well, it works both ways. This is basically a kernel version issue, not a Puppy version issue. There are so many posts that Puppy 4.x works properly for the first time, compared with versions prior to 4.x. Many recent posts about how fast 4.1 is also. 4.1 also has by far the best hardware detection.
Then there is the much-praised Slackware compatibility of 3.x. Well, someone can rebuild 4.1 with the latest Slackware packages if they want. It is a straightforward process, just very time consuming. 3.x is based on Slackware 12 packages, so is getting a bit long in the tooth. If someone wants to rebuild Unleashed 4.1 with the latest Slackware packages, then call it 5.0, why not? Go for it.
ttuuxx has asked can he coordinate the next Puppy3? Why not? I'm not stopping you, go for it.
There is also the comment from ttuuxx that I am maintaining control over everything, while at the same time retiring:
"Last I read Barry wants to keep just about everything puppy related in his name other than releasing newer versions"
Huh? I want to keep the "Puppy Linux" name, so what? To whom should I give it? The domain names puppylinux.org and puppylinux.com are registered by me, which means that I do have some veto power. Again, so what? Isn't this a valid safeguard?
So ttuuxx, I've had a go at you. Take it on the chin. You have also posted heaps of great stuff, and great packages. It's just that I am being bombarded with people asking me to make some kind of comments about what seems to be a lot of dissension on the forum ...well, I am now responding, and stepping on one or two toes in the process. Ttuuxx, it may turn out that you are the best guy to coordinate 4.2.
I have only read partway through the links, and so far I'm not impressed. Some people are asking for guidance, but what is to stop a small group getting together and work on 4.2? Nothing. Lobster is trying to coordinate something, but I am seeing a lot of arguing only from the contributors.
Meanwhile, the developers are continuing to work quietly. Regarding who should coordinate, by that I mean be in charge of using Unleashed to actually build it, and work on the core scripts, there are very few people to choose from. Other people can certainly play managerial and testing roles, but to actually build future Puppies...
Personally I think Dougal is the best choice, but he is working on 2.x. Probably Dougal would not want to take on such a heavy duty anyway. Who else is there that understands what is going on under-the-hood? Kirk? Rerwin is pretty good at coding and is learning about Puppy's boot scripts. MU also, but he has Muppy. Nathan also, but he has Grafpup, and also seems to have gone again. There are some other guys, like tempestuous, zigbert and HairyWill who have the technical ability, but again they would have to get up to speed with the boot scripts etc.
A side comment: many of the guys are "nice guys", approachable, friendly, helpful. Zigbert for example. One reason I favour Dougal is because he has a certain toughness and is less likely to bow to everyone's wishes. That's just my personal assessment.
There is some infrastructure in place for building Puppy, at Sourceforge, and I would like to thank cb88 for that. The thread started by cb88 had some good practical discussion.
4.2 is not going to be revolutionary, just refinements of 4.1. Fix some rough edges, update some packages, new themes. This can be done, just like 2.15CE was done. It just needs someone competent to step forward and do it. For 2.15CE, WhoDo offered to do it and we accepted, and he did a very good job. WhoDo, are you interested in a new project?....
I think the way forward needs to be along the lines of a Community Edition, like 2.15CE, which will get a group working together and build confidence, and will also help to clarify what should happen after 4.2. Other inftrastructure things like subversion control hosting, T2-rebuild or move to Slackware compatibility, and any formal foundation are not so urgent (and can continue to be developed/planned in the background). Also, the coordinator for 4.2 does not need to be a programmer, but should have good technical ability and be competent with using Unleashed -- my preference for someone who is a programmer and understands all of puppy's internals (like Dougal) and who also can take on a managerial role is the ideal though, for the longer term.
Plans for the future of Puppy
Since I announced that I was taking a back seat, effective from release of 4.1 (well, 4.1.1 actually), there has been a lot of discussion and planning. I have not been following any of this, but now have some time to read through it. First step is to collect all the links, and here is what I found:
Puppy 4.2 - desktop and artwork
zigbert
http://murga-linux.com/puppy/viewtopic.php?t=34331
4.2 meeting - here
Lobster
http://murga-linux.com/puppy/viewtopic.php?t=34201
Establishing a formal community
tombh
http://murga-linux.com/puppy/viewtopic.php?t=34134
Puppy Community
Lobster
http://puppylinux.org/wiki/archives/old-wikka-wikki/categorycommunity/puppy-community
PuppyCommunity
Lobster
http://tmxxine.com/wik/wikka.php?wakka=PuppyCommunity
Puppy's future
Bruce B
http://www.murga-linux.com/puppy/viewtopic.php?t=32169
Puppy 4.2
Lobster
http://www.murga-linux.com/puppy/viewtopic.php?t=33454
Barry's retirement from Puppy
tronkel
http://www.murga-linux.com/puppy/viewtopic.php?t=32078
How should Puppy be developed when Barry steps down?
disciple
http://murga-linux.com/puppy/viewtopic.php?t=32192
DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)
ttuuxx http://murga-linux.com/puppy/viewtopic.php?t=33484
Puppy Community Register
mysticmarks
http://murga-linux.com/puppy/viewtopic.php?t=32183
Puppy Linux community repo is active on sourceforge
cb88
http://www.murga-linux.com/puppy/viewtopic.php?t=32215
...I am now in the process of reading through all these links.
regarding numbering of versions, my plan was that the numbering would go back to having a dot between each digit:
4.1 is our current release.
4.1.1 is going to be a bugfix release, that I intend to bring out.
4.1.n these are either bugfixes or alphas or betas.
4.2 the next official 'final' release.
As I am targeting 4.1.1 for the near future, and want to move on to my UniPup work, I doubt that I will work on 4.2, so that's for you guys.
Comment posting initialised
There was a problem upgrading PPLOG from 1.1 to 1.1b, when posting a comment, the old passwords were no longer accepted. Posters had to create a new username and password.
However, I have cleared all usernames and passwords, so it is like a new installation of PPLOG. When posting a comment, choose whatever username and password you want.
UniPup boots faster
I have built UniPup 410 and compared the boot time from CD with the official Puppy 4.1.
UniPup: 46 seconds
4.1: 53 seconds
The main reason UniPup is faster is because it doesn't have an 'init' script. Just like a full-hd installation of Puppy, the first script that executes is 'rc.sysinit'.
However, UniPup is slowed by the loading time of the bigger 'initrd.gz' file. I have built this UniPup with a separate 'usr_410.sfs', but intitrd.gz has everything else, including all the kernel modules. I intend to cut down the modules somewhat.
I am aiming for 30 seconds boot time ...we shall see how close I can get to that.
Blog upgraded to v1.1b
The "b" does not mean beta, it is a later version than 1.1.
The main thing is now you have a menu when posting a comment. Do note that you can also post code with the 'code' '/code' tags in square brackets.
Changelog for 1.1b:
* BBCODE bug on comments, fixed thanks to СеÑгей
* RSS Links fixed, thanks to Matthew Everitt
* Some Grammar Corrected, thanks to Irmela
* Added an option to allow HTML on new entry pages
* Added an option to allow only numbers on CAPTCHA
* Fixed old captcha so there is no confusion (ALL CAPS LETTERS)
* Added an option to modify the CAPTCHA lenght
* Added an option to allow WYSIWYG instead of BBCODE (Smilies dont work with WYSIWYG)
Planning SP1
Each time I add something to the Service Pack, I'll post to this blog with "(SP1)" in the title, so everyone will know exactly what is going into it.
(SP1) Ndiswrapper bugfix
Thanks to MU, a PET package for the updated Network Wizard that fixes ndiswrapper:
http://murga-linux.com/puppy/viewtopic.php?p=238917#238917
EDIT:
No, from further feedback to above forum thread, it still isn't fixed.
(SP1) prism54 fix
Thanks to tempestuous, I have modified PREFLIST variable in /etc/rc.d/MODULESCONFIG:
#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 ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci martian_dev:ltserial bcm43xx:ssb prism54:p54pci '
See forum:
http://murga-linux.com/puppy/viewtopic.php?p=238917#238917
Ndiswrapper bug
The version of Network Wizard used in 4.1 has a bug. grab an update, see this thread:
http://murga-linux.com/puppy/viewtopic.php?t=31522
...someone should make that into a PET package, for those who don't know how to install from a .tar.gz.
It looks like we will have to bring out a Service Pack for 4.1, and another release, 4.1.1, with the Service Pack included.
Are there any other fixes for the Service Pack? (don't reply with bug reports here, I only want to know if anyone has fixed something and would like to see it in the SP1).
Kernel SFS files uploaded
As described in recent blog posts, here they are:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/sfs_modules-4/
These are for 4.1 and 4.1retro.
Firmware installation problem
There is a problem with how 4.1 installs a firmware tarball. It only affects the 'dvb-usb.ko' module. At the 12th hour, just before releasing 4.1, I threw in some firmware for this module, but we have now found that the firmware tarball does not install when the dvb-usb.ko module loads for the first time.
The firmware tarball is located at /lib/modules/all-firmware/dvb-usb-firmware.tar.gz, and you will have to install it manually. Expand the tarball anywhere, and copy the firmware files to /lib/firmware.
The reason the the firmware tarball does not install is because of the way I have setup firmware-tarball installation. The /etc/rc.d/rc.sysinit boot script iterates through the "modalias" files in /sys, causing the kernel to generate uevents, which in turn 'udevd' processes. The udevd daemon gets its rules from /etc/udev/rules.d, and for any case in which a module is being loaded, udevd will run /sbin/pup_event_backend_modprobe script, and one function of this script is to see if the firmware tarball is installed and if not then install it (from /lib/modules/all-firmware to /lib/firmware).
However, dvb-usb.ko does not have a modalias file under /sys, so is not loaded. It has to be loaded manually, or as a dependency of some other DVB USB related module. The way things should really be setup is for the firmware tarball to be associated with those DVB USB modules that do have a modalias entry (that is, have an 'alias' entry when you run modinfo, so it is a module for some specific hardware), and this association would be in /etc/modules/firmware.dep.2.6.25.16.
So, if someone can provide me with a list of all the hardware-specific DVB USB modules, I can fix the firmware.dep.2.6.25.16 file.
Note, in some earlier puppies, 'modprobe' is a script, but in 4.1 'modprobe' is the actual executable. When 'modprobe' was a script, firmware installation could be handled for every module.
Kernel SFS files
I have created 2.6.25.16 and 2.7.21.7 kernel SFS files for Puppy 4.1, but cannot upload them until the end of this week.
Note, they are in my Unleashed CD, which I'll be posting tomorrow.
How to recompile the kernel
If you want to recompile the 2.6.25.16 kernel with some goodies like tickless and SMP support, I recommend that you do a full hard drive install of Puppy 4.1 (not frugal).
You will need to install the 'devx_410.sfs' file also (C/C++ compiler support), as explained here:
http://puppylinux.com/hard-puppy.htm
Then download the patched kernel source from here:
http://puptrix.org/sources/kernel-2.6.25.16/
and expand it at /usr/src/linux-2.6.25.16.
...also download everything else.
Then follow the instructions given in the .txt files.
After compiling your new kernel, you can test it in the full installation.
To build a new Puppy with your kernel, you need Puppy Unleashed:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/puppy-unleashed-core-4.1.tar.gz
Instructions are at:
http://puppylinux.com/development/puppy-unleashed.htm
In puppy-unleashed/kernels directory you will find '2.6.21.7' and '2.6.25.16' directories. In the latter, substitute your new 'vmlinuz' and kernel modules.
If you are moving up to the 2.6.26.x kernel, make a copy of the '2.6.25.16' with the appropriate new version number, and make appropriate substitutions inside (kernel, modules, and replace DOTconfig-K2.6.25.16, and rename firmware.dep.2.6.25.16).
For compiling the 2.6.26 kernel, kirk, MU and others have posted some instructions:
http://www.murga-linux.com/puppy/viewtopic.php?t=33461
4.1 CD orders
I have a backlog of several CD orders, and I notified by email that I was holding orders pending the imminent arrival of 4.1final.
Right now I'm preparing the Users and Unleashed CDs and intend to post them tomorrow.
I don't have the SFS files for the kernel source, will have a go at creating them today, as they have to go into the CDs.
Extra drivers for 4.1
Tempestuous has posted extra drivers for 4.1 here:
http://murga-linux.com/puppy/viewtopic.php?t=34159
Tempestuous has the solution for wireless network connectivity if you have a EeePC.
Puppy 4.1 released
This exciting new Puppy can be downloaded from Ibiblio:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/
The 'devx_410.sfs' file (for C/C++ compiling) is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/sfs_modules-4/
The full announcement and release notes are here:
http://puppylinux.com/download/release-4.1.htm
...please read this, to decide whether you want to download the build with 2.6.21.7 (4.1retro) or 2.6.25.16 kernel. Most people will probably go for the later kernel, unless you have old hardware.
If you are upgrading from 4.00, at first you may feel underwhelmed, as the default theme, including desktop background, is unchanged. However, major changes have taken place "under the hood", greatly improving Puppy's hardware compatibility and support for hotplugging. Also, there are some very significant new applications -- read the release notes!
For those wanting Puppy Unleashed, the file 'puppy-unleashed-core-4.1.tar.gz' is here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/
And the PET packages are here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-4/
DVB-USB firmware
After feedback from tempestuous and linuxcbon, I have included some firmware for DVB-USB devices.
Ok, there is probably a lot of hardware that won't be covered, but perhaps some coverage is better than none, and they are quite small files. The one common factor is that the 'dvb-usb.ko' module is required, so I have created a "firmware tarball" for this module, with these firmware files (in /lib/firmware):
af9005.fw
dvb-usb-af9015.fw
dvb-usb-bluebird-01.fw
dvb-usb-dib0700-1.10.fw
dvb-usb-dibusb-5.0.0.11.fw
dvb-usb-dibusb-6.0.0.8.fw
dvb-usb-dtt200u-01.fw
dvb-usb-umt-010-02.fw
dvb-usb-vp702x-01.fw
dvb-usb-vp7045-01.fw
dvb-usb-wt220u-01.fw
dvb-usb-wt220u-02.fw
Note that Pup 4.1 should create any devnodes automatically, as this pup uses udevd.
Here are some info links that linuxcbon provided:
http://www.linuxtv.org/downloads/firmware/
http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices
Countdown to 4.1final
I intend to build 4.1 final about 10 hours from now, then do several hours of testing on my PCs. If all looks ok, I will release it.
So, if there is anything urgent that you need to sneak in, kindly do so within the next 10 hours.
DVB-USB firmware
Forum member 'linuxcbon' has requested a particular firmware file for DVB-USB be included in Puppy. There is a website with more information on this:
http://www.wi-bw.tfh-wildau.de/~pboettch/home/index.php
Now this is interesting, an online script that will extract the firmware file from the Windows driver:
http://www.wi-bw.tfh-wildau.de/~pboettch/home/index.php?site=dvb-usb-firmware
As far as including firmware files in Puppy, I would need to know what files are required for each module. There is a 'dvb-usb'ko' module, but I presume many more for particular hardware.
Tabs wrong in Pmount
Rerwin reported that when no CD/DVD discs were plugged in, but a USB drive was plugged in, Pmount showed the USB drive under the 'optical' tab, when it should have been under the 'usbdrv' tab. In fact, Pmount should not have had an 'optical' tab at all.
I have implemented a generic fix to this, as it could conceivably happen for other categories than optical.
Playing WAV files
There are some complaints that when click on a .wav audio file in ROX, it doesn't stop playing. It seems that the 'wavplay' executable has this problem on some hardware.
I can't set the player to 'defaultmediaplayer' (which is Gxine) as Xine does not play WAV files properly on my laptop. So, I have set the player to 'pmusic', so you get a nice GUI -- this solution was suggested by forum member 'capoverde'.
ChmSee bug fix
Thanks to forum member 'liberomureddu' who reported this bug. File->Open in ChmSee (Microsoft CHM help viewer) did not work when run from the menu, but did when 'chmsee' run directly in a terminal. Fixed.
Limit of 2 extra sfs files
Thanks to forum member 'Béèm' who reported this.
I had introduced an option for the 'zdrv' sfs file to load as a layer, and the 'createpuppy' script is able to build Puppy with a separate zdrv file that will load inthis way -- however 4.1 is built with no zdrv, all modules built-in to the main sfs file. When I coded this in the /init script in the initrd, it introduced a bug, only allowing two extra sfs files to load(should be three).
Béèm tried to load OpenOffice, Filezilla and Wine sfs files, and although the BootManager was able to select all three, only the first two actaully loaded. Fixed.
JWM configuration bugfix
Forum member 'Kal' reported that there is a commented-out section at the beginning of /root/.jwmrc-tray, that upsets the JWM configuration application.
Ideally, we should fix the JWM config application, but I have applied the quick fix and removed the commented-out section. Note, the problem is due to there being two 'tray' tags -- although one is commented-out, the JWM config scripts do not understand this.
Pburn, Pfind
I have updated Zigbert's Pburn to version 2.0.9 and Pfind to version 4.4-1.
Network Wizard
I have updated to Dougal's latest, dated October 1st.
Abiword spellcheck fix
Thanks to forum member 'gray' for this one. Gray posted a fix here (which also applies to Puppy 4.00):
http://murga-linux.com/puppy/viewtopic.php?t=28643&start=213
bcm43xx module preference
After discussion in the Network Wizard forum thread, I have added a preference for the 'ssb' module when it and the 'bcm43xx' module are claiming the same hardware. The PREFLIST variable is in /etc/rc.d/MODULESCONFIG:
#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 ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci martian_dev:ltserial bcm43xx:ssb '
Further refinement to desktop drive icons
Rerwin has further refined the 'clean_desk_icons' script, and I made a further little tweak.
Today is Sunday 5th October, and my Perth Royal Show job has finished, so today I am spending most of the day on the Puppy project.
Amended retirement statement
Those who have tested 4.1rc may have noticed that the release notes have an amended "retirement" statement:
I have decided to bow out from my position as leader (also known as "Benevolent Dictator") of the Puppy Linux Project (held since I released v0.1 in mid-2003), and take a back seat. Version 4.1 is my final release as leader. A small group of trusted developers will take over, although the details are still to be worked out -- there are a couple of threads on the forum discussing this.
I won't be going away totally, and plan to focus on a "puplet" (derivative of Puppy) based on my "UniPup" concept and targeting specific hardware, probably one or more of the baby laptops. This will be a more part-time project than the hectic full-time pace that I have maintained over the last couple of years.
It is likely that I will keep working on some aspects of the "core" or "base" Puppy, primarily for my puplet but that will be useful for the mainstream Puppy.
Also, I will retain whatever copyright/trademark rights I currently have and continue with ownership of the puppylinux.com and puppylinux.org domain names. Plus, I will provide input to how and who takes over, hopefully without interfering too much. I see this as providing a kind of safeguard function -- I am mindful of other distros that have languished after the Benevolent Dictator left. Monitor my blog for updates on the transitional phase as I progressively retire.
I think this is a great opportunity, and Puppy will become better and better!
I have modified it in response to feedback sentiments and concerns expressed by many.
Bashdiff with GTK widgets
This is something we should checkout:
http://home.eol.ca/~parkw/index.html#gtk
Desktop drive icon improvements
With help from rerwin, who also discovered this bug, we have a fix for a CD/DVD icon remaining on the desktop although the disc is removed. This affects /sbin/clean_desk_icons and /sbin/pup_event_frontend_d scripts.
I have also improved the collision-avoidance code in pup_event_frontend_d, so that drive icons cannot be drawn almost exactly on top of each other.
Puppy 4.1rc
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1rc/
Note that this has Dougal's latest Network Wizard, dated September 25.
915resolution, mut2/Pmount, Pburn
Tempestuous has patched 915resolution again, dated September 25.
Jesse has provided a patch for Pmount, that fixes floppy drive detection when using his mut2 engine.
Zigbert's Pburn updated to version 2.0.6.
The PREFLIST variable in /etc/rc.d/MODULESCONFIG now gives preference to the ltmodem driver rather than the martian driver:
PREFLIST=' rt2500usb:rt73usb ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci martian_dev:ltserial '
Note, things are moving slowly, 4.1rc has fallen back another day.
Update on 4.1 schedule
I'm doing some testing tonight. As I'm currently working all day, I can only put in 2 - 3 hours in the evening. I anticipate uploading 4.1rc tomorrow evening (about 24 hours from now).
Note that with 4.1beta, everything is frozen except for fixing bugs. No upgrades of packages, unless they have a fix of a critical bug.
So, when I get home from work tomorrow evening, I will check the forum and my blog, in case anyone has posted some critical bugfix, then I'll build 4.1rc, do a bit of a test of it, then upload it.
Probably.
Regarding upgrades of packages, including Xorg 7.4, ALSA, SANE, XINE, etc. ... well, perhaps that will be done for 4.2!
Pbackup, Pburn, Pmusic
Pbackup is now version 3.1.4.
Pburn is now version 2.0.4.
Pmusic is now version 0.3.2.
Ayttm 0.5.0-81
Siddhesh sure is busy improving Ayttm! Upgraded only yesterday. Well, I reckon 0.5.0-81 will be the one that goes into 4.1rc.
Here is the recent changelog:
Sat Sep 20 2008 19:55 UTC [siddheshp] 0.5.0-81
- ChangeLog, configure.ac, src/chat_room.c:
Need to be more careful with my commits -- autocomplete for nicknames is
finally fixed.
Sat Sep 20 2008 19:00 UTC [siddheshp] 0.5.0-80
- ChangeLog, configure.ac, src/chat_room.c:
* Previous commit b0rked autocomplete for buddy nicknames
* Trying to delete from list even when a valid entry was not found in the chat
room
Sat Sep 20 2008 14:25 UTC [siddheshp] 0.5.0-79
- ChangeLog, configure.ac, modules/irc/irc.c, src/auto_complete.c,
src/chat_room.c, src/chat_room.h, src/chat_window.c,
src/gtk/html_text_buffer.c:
* Sort Chat room buddy list alphabetically
* Replaced strlen() with g_utf8_strlen() in autocomplete to cater for UTF-8
characters. We might need to look at this in other modules as well.
* Removed calls to strlen("literal") with the just actual length of the
literal
* Put autocomplete changes in chat_window.c in chat_room.c as well
* Linkify 3rd person messages as well
* Made chat window entry to be the same as chat room entry
Wed Sep 17 2008 19:38 UTC [siddheshp] 0.5.0-78
- ChangeLog, configure.ac, src/status.c:
Sort contacts and groups alphabetically
Pschedule bugfix
A problem with Pschedule was reported here:
http://www.murga-linux.com/puppy/viewtopic.php?t=22166&start=15
Pschedule uses 'crontab' (which is a Busybox applet), which stores information at /var/spool/cron/. However, when Puppy is installed to a USB drive, /var is not saved, so the crontab information does not survive a reboot.
I think that my original reason for not saving /var was to save space. Some stuff can accumulate in /var that does not need to survive a reboot. Also, sometimes some files are better off not surviving as they may interfere with correct operation at the next boot.
However, this behaviour is inconsistent, as the live-CD (with session saved to hard-drive) and frugal install do save /var.
I have modified /usr/sbin/snapmergepuppy so that /var is saved whenever a session is saved. This affects saving to any Flash drive.
Gparted bugfix
ext3 partition creation failure
In the Puppy 4.1beta feedback there was a report that Gparted failed to create a ext3 partition, but did succeed in creating a ext2 partition. I have confirmed this bug.
The problem is the content of /etc/mtab, that Gparted objects to, claiming that it was unable to determine whether the partition that is to be made into an ext3 f.s. is mounted or not. The content of /etc/mtab looked fine to me, however I do know how to fix this problem -- by not having an /etc/mtab file at all and instead just make it a symlink to /proc/mounts.
The "mtab problem" goes back to some fundamental mismatches, that probably in the long term will have to be solved. Firstly, Busybox is configured to not use /etc/mtab (for historical reasons, back when I did configure it to use mtab, thngs went very wrong) for its 'mount' and 'umount' applets.
Secondly, I configured 'ntfs-3g' not to use /etc/mtab, as I use the same binary in the initial ramdisk (which has the Busybox mount and umount).
However, the full 'mount' and 'umount' programs do use /etc/mtab, and also some utilities (such as 'eject' and 'mke2fs' reference /etc/mtab).
In Puppy, /bin/mount and /bin/umount are scripts, so I was able to juggle the above conflicts. My scripts write to /etc/mtab and everything seemed to work okay ...except now we have Gparted unhappy with what it is finding in /etc/mtab for some reason.
In the initrd /etc/mtab is a symlink to /proc/mounts, as this works for the various utilities (eject, mke2fs, etc.). I have now done this for the main Puppy filesystem.
To implement this, I have modified /etc/rc.d/rc.sysinit, /bin/mount and /bin/umount.
This is a small but fundamental change, that could have subtle or not-so-subtle ramifications. Or it might just fix the Gparted bug and have no other negative repercussions (I am inclined to this view). I am reluctant to make this kind of fundamental change at this stage, but it is necessary to fix the bug. I will do extensive testing before releasing the 4.1-release-candidate.
Slow startup
There is something else that we should do. Gparted can be very very slow to startup on some PCs that have a floppy drive interface on the motherboard but no actual floppy drive. Gparted does a scan at startup and gets stuck on the floppy probe, but does eventually timeout. What we need is a little wrapper, call it 'gpartedwrapper', that runs 'probedisk2' and puts up a little GUI that asks which drive you want to work on, then executes Gparted like this:
gparted /dev/sda
...which constrains the startup scan to only that drive.
Would anyone like to whip up such a little GUI?
Pmusic 0.3.1
I have upgraded Pmusic to version 0.3.1. Note, Pup 3.1beta has 0.3.0.
Network Wizard Sept. 18
I have upgraded the Network Wizard to the version dated September 18. Note, Pup 4.1beta has September 4.
Ayttm 0.5.0-78
I have upgraded Ayttm multi-protocol chat client to version 0.5.0-78. Pup 4.1beta has 0.5.0-77.
Incorrect f.s. info
Zigbert has described this problem here:
http://murga-linux.com/puppy/viewtopic.php?t=32882&start=30
He burns to a CD in multisession mode, then burns another track, but after mounting the CD the 'ls' command shows the old contents. The CD has to be physically ejected then reinserted then mounted to force the system to update the f.s. info.
I think this problem is only with the new libata PATA/SATA drivers, not with the old IDE drivers, so you won't have it on the 4.1retro Puppy.
I have just been sitting here for a few hours, trying all sorts of things to try to force a refresh without having to eject the CD, but no-go. This is a fundamental problem with the kernel and libata, and yet another thing they need to address.
ICS and PPPOE
Pup 4.1beta has both the 'Roaring Penguin' and the 'Pppoeconf' applications for PPPOE connection to the Internet. I put in both as it is still not determined how well, or even if at all, Pppoeconf works.
However, the Internet Connection Wizard main dialog, that comes up when you click the 'connect' icon on the desktop, was a bit confusing as it did not clearly offer the two alternative PPPOE applications. I have remedied that.
Firmware loading fixed
With help from 'Minnesota' on the Network Wizard forum thread, we identified and fixed this bug.
I have various network devices that require firmware to be loaded, but the firmware files are located in /lib/firmware. However, Minnesota and some others have hardware that has firmware in a subdirectory, like this:
/lib/firmware/
This firmware was not getting loaded. I have fixed the script /sbin/pup_event_backend_firmware, which is what udevd calls when firmware is to be loaded.
Xsane and SCSI
Xsane is a bit 'insane' when detecting a SCSI scanner.
I have added a 'SCSI' button to the initial orange dialog box, which loads the 'sg' module then starts xsane.
The dialog box also has some suggestions to work around the insanity of Xsane's autodetection.
SM Print Preview crash
I recall now. Pup 4.00 has SM 1.1.8 and that has the same bug. So, I applied this workaround:
Well, it isn't nice, but I have removed "File -> Print preview" from the menu. As it doesn't work, there's no point in having it, and no point in having SeaMonkey crash unexpectedly. For the record, I commented out line 360 in /usr/lib/seamonkey-1.1.8/chrome/comm/content/navigator/navigatorOverlay.xul
This is documented in my blog:
http://www.puppylinux.com/news/news400a7-400b.htm
I also wrote that Print Preview does work in SM 2.0alpha1, so we do have something to look forward to!
Anyway, I have also disabled Print Preview in SM 1.1.11 in Pup 4.1.
4.1 release schedule
Zigbert is doing some mods to some of his apps and asked about getting enough time to do it for 4.1-final. I had previously mentioned September 21 as the final release date, as my Royal Show job starts on the 22nd.
However, that date can fall back. I can still put in two or three hours on Puppy in the evenings. When it looks like everything is mostly ready, probably sometime after the 21st, I'll upload a "rc" (release candidate) for anyone who wants to do a quick sanity check, then the final soon after.
Rerwin has reported the SeaMonkey crashes on Print Preview. I seem to recall that happening in an earlier version of Puppy also, and upgrading SM fixed it ...I think. Now we have it back again. Well, I'll look into it, but can't guarantee anything.
snapmergepuppy bugfix
Federikson posted a report about a bug in /usr/sbin/snapmergepuppy, but that is in 4.00 and is fixed in the 4.1 alphas and betas.
However, while I was examining the script I noticed another bug. The script tests if 'pup_eventd' is running then decides if X is running, but that was relevant back in the early alphas and now the test should be for 'pup_event_frontend_d'. Fixed.
Puppy 4.1beta
This is the 'standard' Puppy, version 4.1beta with 2.6.25.16 kernel. Updated release notes are in the live-CD. Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1-beta/
Note, due to the roll-back of ffmpeg and xine-lib, the devx_408.sfs is different from devx_407.sfs.
If you have tested 4.1retro-beta, beware that Puppy will have copied pup_408.sfs to the hard drive (even if you declined when asked about that at shutdown), so you have to delete that file first -- otherwise you'll get a kernel panic.
wpa_supplicant
Tempestuous has compiled a more recent version of wpa_supplcant, quoting from his post in the Network Wizard thread in the forum:
Well I don't have firm answers, just suggestions.
It seems that generally the new rt73usb doesn't like hidden SSID's.
I think it's time to upgrade wpa_supplicant. The latest stable version now attached.
This package contains only the application files, and does not overwrite any configuration scripts.
I have enabled the "ipw" -D parameter for compatibility with the new Realtek rtl8180 and rtl8187 drivers. Of course, 99% of modern Linux wifi drivers use the standard "wext" -D parameter.
DON'T use this version of wpa_supplicant in versions of Puppy older than about 4.1alpha5, because this new versions lacks the "Ralink" -D parameter necessary for the old rt61 and rt73 drivers.
I have built 4.1beta (with 2.6.25.16 kernel) using tempestuous's wpa_supplicant v0.5.10. The 4.1retro will continue to use the older wpa_supplicant.
Guy-on-the-bike?
I will not be designing a new theme for 4.1, nor using anyone else's theme. However, Lobster has suggested that there should be some differentiation from 4.00, and he suggested the guy-on-the-bike background instead of the Antartctic/Arctic scene.
Here it is:
...what do you reckon? Down to /usr/share/backgrounds then try it. Should I use that for 4.1?
ffmpeg/xine-lib roll-back
I have decided to be extremely cautious and conservative for 4.1.
There is something not quite right about the latest builds of ffmpeg and/or xine-lib in the recent alphas. Playing a RealMedia video on my laptop, sound is jumbled, whereas it plays fine in pup 4.00.
Zigbert has also reported a problem with mp3 conversion.
So, I have rolled back to ffmpeg/xine-lib used in pup 4.00. It knocks about 1MB off the live-CD, as the faac, faad2, x264, and xvidcore packages are not needed. People can add enhancement PET packages afterward for extra libraries support.
I want a small Puppy, that satisfies most people, and the ffmpeg/xine from 4.00 is the best compromise I think.
mp3lame
Zigbert reported that ffmpeg does not seem to be configured with --mp3lame, however, this is how it was configured:
# ./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
Actually, I am seriously thinking of rolling back to the ffmpeg package used in pup 4.00. I think that is a good compromise, small yet covers most video/audio formats. I was listening to many people who said they wanted this or wanted that, and the latest ffmpeg is very bloated -- and I don't even think it works as well.
4.1retro-beta uploaded
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1retro-beta/
This has the 2.6.21.7 kernel, and is conservatively configured for maximum compatibility on old hardware.
I did not put in the i810_drv.so from Puppy 3.01, as that is Xorg 7.2, whereas Puppy4 has Xorg 7.3, and the intel_drv.so is supposed, it seems, to superceed the i810_drv.so module. All my hardware works fine with the intel_drv module, so I'm reluctant to put in an older driver.
I have put in both Pppoeconf and Roaring Penguin PPPOE. But possibly only one will remain in the final. Ideally, I would like to get Pppoeconf debugged.
The devx_407.sfs will work, just rename it to devx_408.sfs.
Module preferences list
Tempestuous posted this to the Network Wizard thread on the forum:
Dougal :
Turns out there is also overlap between orinoco_nortel and hostap_plx, orinoco_plx and hostap_plx, orinoco_pci and hostap_pci, and orinoco_tmd and hostap_plx! Tempestuous, where art thou?
It seems the hostap drivers have been updated more recently, so maybe they are the better ones?
I have a new job, so I only have enough time to quickly scan the forum these days.
Yes, that overlap is because the Intersil Prism2 chipset is quite similar to the earlier Orinoco chipset. So some (not all) Orinoco-based devices will work with the hostap family of drivers. Certainly the hostap drivers are more advanced, but I can't say for sure whether they work better. If the answer is yes, then we need to ask Barry to change the PREFLIST line in /etc/rc.d/MODULESCONFIG as such:
:
PREFLIST=' rt2500usb:rt73usb orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci '
I have tentatively implemented this. /etc/rc.d/MODULESCONFIG now has this:
#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 ath_pci:ath5k orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci '
PupDial
Rerwin submitted a fix for PupDial after erasing a previous modem selection. I have applied the fixes to /usr/sbin/pupdial and /usr/sbin/modemtest.
Missing Xorg modules
HairyWill reported that Xorg reported these missing modules: sil164.so, ch7xxx.so, ivch.so, tfp410.so.
Xorg in Puppy is cutdown and some X servers are missing. The above though are very small, so I have put them in. The relevantpackage is 'xorg_xorg_servers-7.3-2'.
HairyWill, would you mind testing 4.1retro-beta, which will have these, and check that it now works -- it is possible that after those modules have loaded there may be an attempt to load more.
I'll probably upload 4.1retro-beta within 24 hours of now, the 'normal' 4.1 with later kernel toward the end of the week.
Lucent modem device, prism54 firmware, pppoe
I'm confused. The docs in the source state that the correct device name is /dev/ttyLTM0 for the 2.6.kernel. For the old 2.4 kernel it is /dev/ttyLT0, but the makefile allowed ttyLT0 to be retained for the 2.6 kernel -- but that required an edit of 'Makefile' and I have not done this when building the module for 4.1.
But, rerwin says that the driver asks udevd to create /dev/ttySLTM0 ...very odd. Anyway, assuming that to be so, I have made relevant changes to the 'firmware tarball'.
As tempestuous has advised, I have modified a line in 'firmware.dep.2.6.25.16' to 'prism54_firmware:prism54.ko,p54pci.ko,p54usb.ko'. Note that I did not apply this modification to the 4.1retro build with the 2.6.21.7 kernel.
A note about PPPOE. This is still up in the air. The people who have tested this in an earlier alpha and reported problems, did not stay around to help with bugfixing. The latest 'Pppoeconf' package, launched via the desktop 'connect' icon, is in alpha7 but has not been tested. If noone tests it, how can I fix it? If it doesn't work, or noone verifies that it works, I may revert to the Roaring Penguin solution in 4.00 -- which has a more primitive GUI.
4.1beta
Lots of delays... probably it should be out later in the week, maybe Friday.
Battery monitor, Pburn, Network Wizard, Trash
One thing that was missing from the 4.1 boot scripts was code to explicitly load the battery, ac, thermal and fan modules. Kirk provided this code, that was included in 4.00 (in /etc/rc.d/rc.modules2), and I have copied this into /etc/rc.d/rc.sysinit in 4.1. Now, running 4.1retro, I get the battery monitor when running on my laptop.
Zigbert's Pburn has been upgraded to version 2.0.3.
Dougal's Network Wizard has been upgraded to version 20080904.
The Trash applet is updated by disciple to version 0.3.2.
2.6.21.7 SCSI kernels
I have compiled the SCSI kernels for 4.1retro. You can find them here:
http://puptrix.org/sources/kernel-2.6.21.7-pup4.1retro/scsi/
There are three kernels, with different groups of SCSI drivers built-in (the rest as modules). Built-in makes it easier to boot from a SCSI drive.
If you want to know more about the history of this, type "SCSI" into the search box at left side of this blog.
Pmount fixed
Thanks to information provided by eprv, I was able to fix a bug in Pmount.
Eprv has a CF card with only a single Linux swap partition, and this caused Pmount to crash. In fact, Pmount will crash for any drive without a usable partition or "superfloppy" filesystem.
I put in a check for this condition, and verified it works by creating a USB drive with only a swap partition.
2.6.21.7 patched source
I have uploaded the patched source for the 2.6.21.7 kernel used in 4.1retro, as well as all the 3rd-party drivers, Ted Dog's puptrix site:
http://puptrix.org/sources/kernel-2.6.21.7-pup4.1retro/
I cannot guarantee that kernel modules compiled for Puppy 3.01 and 4.00 will work with 4.1retro, as there are slight differences in the kernel configuration, as explained in this earlier blog post:
http://puppylinux.com/blog/?viewDetailed=00338
Ayttm
I have upgraded from version 0.5.0-74 (in 4.1alpha7) to 0.5.0-77. The main thing is that Siddhesh has fixed Yahoo file transfer. I think it was mentioned in the forum that there is still some problem with MSN, but overall Ayttm is looking good.
xfs partition trouble
eprv, I looked at the gtkdialog file, there is an empty frame:
Pmount was unable to fill this with the correct information. I don't know why. Too difficult for now to figure it out theoretically. I would have to create an xfs partition to test on, and I have no knowledge of xfs at all.
Dialup deliberations
I have started to look at some suggestions from rerwin, posted Aug 30:
1.
'cd /sbin' near end of pup_event_backend_modprobe. I have done it, although I don't understand it.
5.
'rm -f /dev/ttyS_ESS0 /dev/ttySLT0 /dev/ttyS_PCTEL0 /dev/ttyLTM0' is now in /usr/sbin/modemprobe_erase
Rerwin also posted about the dgcmodem, Sept 2. Ok, I have put in the "firmware tarball". Rerwin, one thing I notice, you advise 'Dgcmodem:dgcusbdcp.ko' but the firmware directory is 'dgcmodem' -- do you want it to be an upper-case 'D'?
Some of the other points raised by rerwin I will look into, but dialup will still be a work-in-progress when 4.1final comes out. What needs to happen I think is that Unleashed needs to be setup in a revision control system (CVS/SVN/GIT) and the "trusted core developers" need direct access. These developers are competent guys and should be able to modify directly without going through me. One thing that I'm acutely aware of sometimes -- I am jumping from topic to topic, and sometimes my assessment may be shallow or miss some point. For example, I was busy this morning rewriting /sbin/pup_event_frontend_d, after that did a few other small things, then just now got into vetting rerwin's recent contributions and ideas. Then I have to move on, have something else to test tonight. I reckon in the future, those guys who really know what's going on inside Puppy, who have a good knowledge of scripting and a track record of excellent contributions, should be rewarded and allowed to have more direct power.
After 4.1final is out, go for it guys! I know there is a thread discussing how to set things up after I have "retired", but I haven't read it yet -- I decided to wait awhile, give it time to see if any firm ideas/strategies have emerged and read the whole thread in one go. Then maybe throw in my 2 cents worth of opinion (in addition to the above!).
Hotplug fix
There was a report that plugging in two USB drives simultaneously they did not appear on the desktop. So, I examined /sbin/pup_event_frontend_d, the daemon script that detects when block devices (that is, drives) are added or removed and updates the desktop drive icons. I ended up giving it a complete overhaul.
I had also discovered a problem with the 2.6.21.7 kernel. I had udev rules so that 'udevd' would signal pup_event_frontend_d whenever a block device is added or removed. However, as the 2.6.21.7 kernel uevents do not set the DEVTYPE variable, I cannot specify that in the rules, which resulted in multiple signals being sent to pup_event_frontend_d, which confuses the script.
On top of that, pup_event_frontend_d has a complex structure. It has to wait on block events from udevd, but it also has to have its own four-second loop as some devices (ex., CD/DVD media) need to be polled periodically. For sometime now I have realised that it would be better to abandon some of the sophistication and just have a simple polling loop. That is, uedevd no longer has rules to signal pup_event_frontend_d. The script is just in a simple two-second loop monitoring /sys/block for changes, and also performing four-second probes.
This has greatly simplified the script, and it now handles multiple simultaneous hotplug events. I think that I may have fixed other potential anomalies also.
So, score a point for the old-fashioned way of doing things. Primitive and simple. I don't think that it uses much more system resources either.
Pbackup, Pburn, Network Wizard
Zigbert's app's updated:
pbackup-3.1.3
pburn-2.0.2
Dougal has updated the Network Wizard:
net_setup-20080831
/etc/rc.d/rc.network
Dialup disconnects
Zygo has reported this for 4.1alpha7, and reports that /etc/ppp/chap-secrets and /etc/ppp/pap-secrets has to be manually created, otherwise 'ppp' will disconnect after a few seconds.
This is an old bug, and was fixed. I have hunted back through my blog, and at:
http://puppylinux.com/news/news400a7-400b.htm
found where I had reported the solution.
Quoting from that page, April 4, 2008:
Ok, I found the problem. Fairly recently, I noticed that the 'wvdialconf' utility, which is executed as 'wvdialconf /etc/wvdial.conf', output a message that /etc/ppp/options may conflict with /etc/wvdial.conf. So, I made a small but fatal change in the pupdial script, I renamed /etc/ppp/options to something else before executing wvdial, then renamed it back afterward.
Now, looking in /etc/ppp/options, it has some interesting things, particularly "usepeerdns". Now, it's my guess that the pppd daemon reads that file and if it doesn't exist then doesn't fetch the DNS from the ISP.
/etc/ppp/options is a file that I have always had in Puppy, it's not part of any particular package. It goes right back to the very early days pre-0.1 when I was first trying to get dialup to work. We need to study the relationship between this file and wvdial and pppd, but for now I have just fixed it by leaving /etc/ppp/options alone.
Interesting, this also fixes the problem I had in (400) alpha7 in which /etc/ppp/chap-secrets and pap-secrets was not getting written to, so I have removed that "fix" from pupdial also.
So, if zygo and others have this bug still, it would seem that you are not using a pristine 4.1alpha7? You need to examine my blog and find out what has one wrong in your case.
Meet Sally
My daughter's two little dogs, April and Vincent, have already featured on this blog. Here they are again:
They have had offspring, born 10th August, five little pups. With the unknown genetic heritage, there are some interesting variations. Here are four of the pups:
Two are black, two white, one is light brown. The biggest black, a boy, the smallest is also black, a girl. I have taken a liking to the smallest, in the above photo and have already started calling her "Sally".
Both the large black and the brown one have pronounced wrinkles on the nose -- you can make that out in the pup on the right in the above photo.
I have been offered one, and at this stage it looks like I will be getting Sally. Mum and Dad will be "fixed" soon, and I guess Sally will get fixed also. Anyone know the optimum age for getting that done?
Misc. fixes, questions
4.1alpha7 has ntfs-3g (NTFS filesystem driver) version 1.2812, however there is still an older version in the initial ramdisk (well, not that old, it was upgraded in April this year). I have now upgraded the static 'ntfs-3g' driver in the initial ramdisk to version 1.2812. This will have an effect if you are booting from NTFS or have a pup_save in an NTFS partition.
I'll post the following to the forum 4.1alpha7 bugs thread also:
eprv has reported difficulty with the 'xfs' filesystem and Pmount. I have looked through Pmount theoretically, cannot see any problem. It seems that gtkdialog3 has a problem. eprv, you need to send me the content of /tmp/pmountdlg.txt_${MYPID}, where ${MYPID} will be some number. You could gzip it and post it to the forum.
zygo, reporting on PupDial, wrote this:
Once I enter the isp settings it also needs chap-secrets & pap-secrets setting to make ppp last more than a second.
What does that mean?
zigbert has reported a strange problem:
The CD must be ejected and reloaded before before mounting shows recent burnt datas.
There is a problem, or so it seems, with old information being retained when it should have upated. You have done an 'eject'. However, after burning, and before mounting the drive, use 'dd' to read from the drive -- that might force the directory/file information to update:
# wodim ....stuff...
# dd if=/dev/sr0 of=/dev/null bs=1024 count=1
# mount -t iso9660 /dev/sr0 /mnt/sr0
# ls /mnt/sr0
ALSA fix
I have been haunted with ongoing trouble with ALSA on my laptop. The problem I have had with ALSA version 1.0.16 is that on first boot sound is muted (and cannot be un-muted with a mixer). I have to run the ALSA Wizard, then sound works on subsequent boots.
I did report this awhile back on my blog. The Wizard has a function, set_mixers(), that is the key to get sound to un-mute on my laptop. I have this function extracted to /etc/rc.d/functions4puppy4.
However, I have still been having problems. Someone on the forum posted recently that sometimes not executing 'rc.alsa' at bootup fixes the problem (tempestuous?). I currently have this in /etc/rc.d/rc.services:
if [ "`lsmod | grep '^snd_'`" != "" ];then
rm -f /var/lock/subsys/alsasound 2> /dev/null #or alsa will not start.
#v405 snd-mixer-oss loads but the other 2 don't, needed...
#v406 comment out, have restored aliases in /etc/modprobe.conf... v407 back in...
modprobe -n snd-mixer-oss
modprobe -n snd-seq-oss
modprobe -n snd-pcm-oss
#v408 comment-out...
#/etc/rc.d/rc.alsa start
#v408 my laptop needs this hack to get sound to start...
if [ ! -f /etc/asound.state ];then
set_mixers #in functions4puppy4
else
alsactl restore
fi
fi
I'm not excuting rc.alsa. Works fine on my laptop, will test on other PCs.
Note, /etc/rc.d/rc.shutdown runs 'alsactl store' to save settings to /etc/asound.state.
4.1 release schedule
4.1beta should be out by this coming Saturday or Sunday (6th, 7th September).
I start work at the Royal Show on 22nd, and would really like the final to be out by then. So I will set the 4.1final release date for 21st September.
There will be two live-CD iso's, 4.1retro with 2.6.21.7 kernel and 4.1 "normal" with 2.6.25.16 kernel.
Madwifi and 4.1retro
I got a very odd bug with Madwifi. I don't know if this only applies to 4.1retro and the 2.6.21.7 kernel.
I earlier reported that my PCMCIA-USB adapter card works fine in 4.1retro. That was the first build, and I only had the modules that came with the kernel, no 3rd-party modules.
Yesterday I compiled all the 3rd-party modules, Madwifi included, and built 4.1retro again. Booted it, this time my PCMCIA-USB card did not work. Nor did my SD card. I tested with 'hotplug2stdout' and found that these interfaces were dead, no kernel uvents generated.
I traced it down to the Madwifi 'ath_pci.ko' module. If I blacklist it, then load it manually later, then my PCMCIA card and SD card work. Weird, as far as I can make out, ath_pci is grabbing control of PCI hardware interfaces and preventing the other interfaces from working.
I tested this hypothesis by putting a hack into /sbin/pup_event_backend_modprobe. This is the script that 'udevd' calls everytime it wants to load a module. The hack is that if the module is 'ath_pci' then 'sleep 5'.
This does not slow down bootup because of the way udevd works. The udevd daemon spawns multiple modprobe executions, attempting to boot as fast as possible, so the "modprobe ath_pci" is just one parallel process.
Anyway, the hack worked, so I have put it in as a permanent feature. It seems likely that this bug applies to later kernels also.
Just a reminder though, our 2.6.25 and later kernels have 'ath5k' which replaces Madwifi, but 4.1 has Madwifi as a throwback in case ath5k does not work (you will need to make some changes in the BootManager to disable ath5k and enable Madwifi).
HSF modem drivers for 4.1retro
I have compiled these and intend to include them in the 4.1retro.
There were eight modules, but I had to remove 'hsfhda.ko' as it requires 'snd-hda-codec.ko', but this is only available in an older version of ALSA. The hsfmodem package did compile a 'snd-hda-codec.ko' module but it is incompatible with the version of ALSA in Puppy (1.0.16) and has an undefined symbol.
Retro 4.1 works
Well, almost. I built 4.1 with the 2.6.21.7 kernel and it booted up nicely, got the desktop. Only two things seemed to be wrong -- sound and desktop drive icons.
The sound problem I think I can fix. The kernel has ALSA version 1.0.14 modules, whereas 4.1 expects 1.0.16. So, next job is to update the modules.
The main thing that I got stuck at before when I tried the 2.6.21.7 kernel, is the desktop drive icons do not respond to hotplugging.
I plugged in a PCMCIA card with two USB sockets on it, and the card was recognised, the two USB ports were recognised ...great so far.
I then plugged in a USB pen drive and it was also recognised, but it's icon did not show up on the desktop.
I tracked down the problem. The 2.6.21.7 kernel does not set the 'DEVTYPE' variable inits uevents. I have a udev rule in /etc/udev/rules.d/50-udev-puppy-basic.rules that expects this to be set to 'disk' and also /sbin/pup_event_frontend_d expects it to be set.
I have implemented a workaround.
I'm running the retro right now!
Later I have to go and compile the ALSA 1.0.16 and 3rd-party modules, then do another build and test that. Need to test wireless to -- currently just using ethernet cable.
My intention is, if 4.00 works for you then 4.1retro will to. In fact, I'm wondering about something -- there were some people who could not upgrade from Puppy2 because the 2.6.21.7 kernel did not work on their hardware -- I wonder if that is because of tickless being enabled? Anyway, it is now off, so that's one less compatibility problem.
Retro kernel for 4.1
Awhile back I tested the 2.6.21.7 kernel with 4.1alpha, but there were some problems, I don't recall exactly what.
Anyway, today I decided to give it another go. My intention is to build a 4.1 "retro" with the 2.6.21.7 kernel, which will be configured almost the same as in 3.01 and 4.00. Then, the "standard" 4.1 can be the latest 2.6.25.x with some goodies like libata-PATA and SMP turned on.
I have embarked on this. I have made these changes to the kernel configuration compared with that used in 4.00:
General setup:
[ ] Create deprecated sysfs files
Processor type and features:
[ ] Tickless system
Pccard support:
[*] Load CIS updates from userspace
[ ] PCMCIA control ioctl
Block devices:
< > Low performance USB block driver
Instrumentation support:
[*] Profiling support
[*] 0Profile support
Regarding tickless, both pup 3.01 and 4.00 have this enabled, but after recent research I think it better disabled for a "retro" kernel.
Note also, I patched the kernel source with Squashfs 3.3 and Unionfs 2.4. There were also some patches required for Aufs and for Lloyd's Multitech GPRS.
t2-to-puppy support scripts
As kirk and others are interested in the T2-route for creating Puppy, I am making available some scripts that I whipped up back when I used T2 to build all the base packages for Puppy 4.00.
I have created a thread on the forum and uploaded the scripts there -- or rather, I'm trying to. First try, I got "400 bad request" -- so trying again.... nup, now get "page load error". Oh well...
UPDATE: The forum started working again, this also now in forum thread:
http://murga-linux.com/puppy/viewtopic.php?t=32972
I have uploaded the scripts, here, as 't2-to-puppy-scripts.tar.gz':
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/t2-dingo/
And here is the content of the README file in that tarball:
These scripts with '0' to '3' prefix, I wrote back when I compiled T2 and
created the first build that was to become Puppy 4.00.
It has been awhile since I have looked at these scripts, and they will
definitely need improving/updating.
For a start, you will have to change the paths to suit your setup.
I now favour a different way of creating the 'puppy-devx' folder:
I think it is better for the scripts to create all the split packages
in puppy-unleashed/packages, for example:
abiword-1.2.3
abiword_DEV-1.2.3
abiword_NLS-1.2.3
abiword_DOC-1.2.3
However, for those cases where a package will go totally into the
'puppy-devx', then just have the entire package named appropriately,
for example:
automake_DEV-1.2.3
puppy-unleashed/createpuppy script already has the mechanism to aid with
building the 'puppy-devx' from the _DEV packages:
'on' _DEV packages, or any 'on' normal package that also has a _DEV package,
are copied to puppy-unleashed/devx-extra.
The script 'create-devx_xxx.sfs.sh' copies the contents of puppy-unleashed/devx-extra into puppy-devx, then builds the devx_xxx.sfs.
In my system, the layout is:
puppy-development/
create-devx_xxx.sfs.sh puppy-devx/ puppy-unleashed/
Barry Kauler
August 2008
b43legacy module
You can try this module if the newer b43 or the older bcm43xx modules do not work.
However, the b43legacy module is not listed in /etc/networkmodules and hence not listed in the Network Wizard. I have fixed that.
However, for now, probably you can try the b43legacy module by choosing it in the BootManager and blacklisting the others.
Binary compatibility with a major distro
I'm thinking that after 4.1 and 4.2, it might be wise to move back to binary compatibility with one of the major distros. It is so incredibly time consuming compiling packages. And, you have probably noticed how many times I am recompiling the 2.6.25.x kernel. It is better to leverage off all the hard work that goes into a major distro I think.
After releasing 4.1 and shifting one step closer to retirement, I will be working on my own puplet that targets one or more of the baby laptops. I might reconstruct Unleashed and the 'devx' based on packages from a major distro -- but not necessarily Slackware, perhaps the upcoming Ubuntu 8.10 'Intrepid'. What do you think about choice of distro?
If I do rebuild Unleashed and devx, I'll make it available of course, if the main Puppy developers want to adopt it.
SCSI scanner problem
dogone has tested a SCSI scanner with 4.1alpha7, detected but unusable.
Question: is the 'sg' module loaded?
Run 'lsmod' in a terminal to find out.
I have never tried this, but it seems that you can start xsane specifying what device to use, for example:
# xsane microtek2:/dev/sg3
I think to, you can link /dev/scanner to the device you want to use. Perhaps try this one first:
# ln -sf /dev/sg3 /dev/scanner
then start xsane:
# xsane
xsaneshell missing
Raffy reported that Xsane does not start from the menu in 4.1alpha7, due to missing /usr/bin/xsaneshell. Fixed.
If you are testing 4.1alpha7 and want to test Xsane, just open a terminal window and type 'xsane'.
Also, the menu entry had moved from Graphic to Multimedia, so I have moved it back.
libavformat.so.51
I have just had a quick look at the feedback thread for 4.1alpha7. /usr/lib/libavformat.so.51 is missing, needed by Mplayer PET package.
To fix this, go to /usr/lib (using Rox) and make a copy of libavformat.so.52, named libavformat.so.51.
Puppy 4.1alpha7
Get it from here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.1alpha7/
The 2.6.25.16 kernel is configured as what I will call a "compromise kernel". What I am particularly interested in, is those people who tested the "normal" and "conservative" kernels in alpha6 and experienced that their computer only booted or shutdown with the conservative kernel -- how will you fare with this compromise kernel? I would prefer to release 4.1 with just the one kernel (plus some SCSI kernels for those who need to boot from a SCSI drive), but if it turns out that we do have to offer the conservative kernel as well, then so be it.
Kernel drivers updated
When I compiled the 2.6.25.16 kernel, I updated these:
aufs 20080825
ntfs-3g 1.2812
martian 20080625
Zigbert's apps
I have updated zigbert's applications:
Pbackup 3.1.2
Pburn 2.0.1
Pfilesearch 1.9
Pfind 4.3
Pmusic 0.3.0
2.6.25.16 kernel
The patched source and 3rd-party sources are here:
http://puptrix.org/sources/kernel-2.6.25.16/
I have also partially updated the package source repo at:
http://puptrix.org/sources/alphabetical/
mmmumph...
If any of my replies over the next few days are a bit grumpy, you'll know why.
This afternoon I had two teeth extracted. Quite traumatic. They were two back teeth, one had four roots. I've got a fairly small mouth, the dentist has big fat fingers, so he was muttering all the way through. My heart sank when I heard the "snap" -- both teeth broke when pulled, so he had to dig the roots out.
I've got prescriptions for antibiotics and painkiller. He said it will be a bit uncomfortable for a few days -- which may be an understatement, as the chemist told me the painkiller (Panadeine Forte) is extra strong.
How on earth am I supposed to eat anything? I have a bowl of rice and lentils sitting in front of me, not game to tackle it yet.
2.6.25.16 kernel
I mentioned recently that I downloaded about half a dozen kernel SMP .config files, and found that none of them had "tickless" enabled. Today I did a search for "config_nohz" (UPDATE: that should have been 'CONFIG_NO_HZ') and found this:
June 27, 2007:
Dave mentioned that Fedora Core 7 32-bit is now shipping with
CONFIG_NOHZ=y and CONFIG_HZ=1000.
CONFIG_NOHZ is known to break suspend and resume on some machines. These
problems are being fixed over time, but that's a risky decision for a
distribution to switch it on by default.
The 2.6.25.16 kernel is out, and reading the changelog there are important bugfixes. A couple are to do with hanging at bootup, another is to do with a bug in "jiffies" -- which I know nothing about but I do know that it is a key part of some modem drivers such as ltserial.
So, today I will go through the entire exercise again, all the 3rd party drivers also, this time with tickless disabled. I might bring out just the one kernel this time, for alpha7.
Pmetatagger
Plinej has released a upgrade to Pmetatagger, now at version 2.0:
http://murga-linux.com/puppy/viewtopic.php?t=24291
Puppy GPRS
Lloyd has generalised his GPRS internet connection package to work with GPRS hardware other than the Multitech modem.
He created it as a PET package, posted here:
http://murga-linux.com/puppy/viewtopic.php?t=32710
I have converted this into a "firmware tarball", which will install if the 'ti_usb_3410_5052.ko' module loads. However, other hardware situations may not use this module, so I have created /usr/sbin/pgprs-shell that is launched when 'GPRS Setup' is chosen in the Internet Connection Wizard -- this shell script will install the firmware package if not already, then run /usr/bin/pgprs-setup.
I decided against having the pgprs "firmware tarball" pre-installed, as it has scripts in /etc/ppp/peers that may interfere with analog dialup.
See my original blog post:
http://puppylinux.com/blog/?viewDetailed=00229
Pburn, Pfind, Pmusic
These are all zigbert's applications:
Pburn upgraded to v 2.0.0.
Pfind upgraded to v4.2.
Pmusic upgraded to v0.2.2.
Ayttm
I have upgraded to version 0.5.0-74, dated Aug 19. I think there are still some outstanding issues with Yahoo and MSN, but I read in one of the forum threads that Siddhesh is a bit busy with his regular job right now.
Network Wizard
Dougal has been steadily improving this. I have put the latest, dated August 23rd, into Puppy.
If you wish to test the latest, here is the thread:
http://murga-linux.com/puppy/viewtopic.php?t=31522
Dougal also created an improved frontend for the desktop 'connect' icon (dated Aug 17). This is a script that resides at /usr/local/apps/Connect. I have also put this into Puppy.
Scanner works
I was lacking a scanner to test with. I have an old parallel-port Genius ColorPage VividPro II, but it seems to have given up the ghost.
But, I do have a couple of USB multifunction printers that were given to me because they no longer print. I was cleaning up the place a bit a few weeks ago and put one of these on the verandah, intending to throw it out. It's an Epson Stylus CX5100. I brought it back inside, and 'sane-find-scanner' recognised it.
But Xsane (v0.995) gave a segmentation fault, just like Raffy reported. I tried the old Xsane v0.991 out of Pup 2.17, and it works. So I compiled v0.994, and yay that works.
Scanner test
Is there anyone who has a working scanner in 4.1alpah6?
There was one report of a USB scanner not working. Did it work with earlier puppies? Is it supposed to work with Sane?
If you have a USB scanner that should work but doesn't -- and this is important, it is no good reporting that your scanner does not work in 4.1alpha6 when it is not supported by Sane -- could you try this utility:
# sane-find-scanner
Here is the man page for this utility:
http://www.sane-project.org/man/sane-find-scanner.1.html
Note, there are still some unresolved issues, so it looks like the next release will be 4.1alpha7.
Theme for 4.1
I have decided to leave it the same as 4.00. Coming up with a theme that looks as nice is no mean feat, so instead I am treating it as the "Puppy4 signature theme". After all, it is really the newcomers that we want to give a good initial impression to, and they will not have seen 4.00.
ltserial modem driver
Rerwin reported this:
5. Lucent modem with ltserial sriver: Some success! The ltserial modem will work only in the conservative/uniprocessor iso. In the SMP iso, even with the nosmp parameter, probing and connecting to internet causes Puppy to freeze, necessitating a "reset".
I wonder if it is because the SMP kernel is configured with the "tickless" option? But then so is the 2.6.21.7 kernel used in 4.00. Rerwin, does the 'ltserial' module work in 4.00?
SCSI scanners
Dogone reports that Microtek E6 and HP PhotoSmart C5100A SCSI scanners do not work in Puppy "since 4.0".
The initial dialog /usr/bin/xsaneshell only asks if you have a USB or parallel-port scanner, as back then I thought that SCSI scanners were as scarce as hen's teeth. Anyway, you can press either button, they don't do much, just start /usr/bin/xsane.
So, the real problem is, why doesn't Xsane find dogone's scanners? -- it reports "no devices found". 4.1 does not include SCSI modules, so you have to use one of the SCSI kernels. If you are running Puppy with a SCSI kernel, then I have no idea what the problem is.
Quite a long time since I tested a scanner in Puppy, haven't done so for any of the 4.1alphax series. Anyone else tried 4.1alpha6 with a USB or parallel-port scanner?
Ethtool
Dougal has requested ethtool be in Puppy. Ok, it will be in 4.1beta, coming soon.
Man page:
http://gd.tuwien.ac.at/linuxcommand.org/man_pages/ethtool8.html
915resolution patched
I had patched the source of 915resolution 0.5.3 to support 1024x600 (945GM chipset) in the Acer Aspire One laptop. This is in 4.1alpha5 and 4.1alpha6.
Tempestuous has further patched the source to support the G33 (GMA3100) Intel chipset, device id 29c0:8086.
This latest patched version will be in the next Puppy (4.1beta).
You can try it now, tempestuous has posted it in this thread:
http://murga-linux.com/puppy/viewtopic.php?t=32462
Note, I plan to upload 4.1beta sometime around the middle of next week, 27th-28th.
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:
# 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
UPDATE: rarsa
...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 pulle