Forum member ‘JustGreg’ has been doing a lot of work investigating how to get USB pen drives to boot reliably. Here are some forum threads on this topic that he has contributed:

http://murga-linux.com/puppy/viewtopic.php?t=25676
http://murga-linux.com/puppy/viewtopic.php?t=25808
http://murga-linux.com/puppy/viewtopic.php?t=25872
http://murga-linux.com/puppy/viewtopic.php?t=26591

I was reading through JustGreg’s and others posts to get up to speed on the subject, when I suddenly remembered a utility that I had looked at ages ago, and I even remembered its name: ‘makebootfat’. This is a very interesting little program: it can create a kind of universal USB pen drive that can boot from any of the BIOS settings, USB-FLOPPY, USB-HDD or USB-ZIP. It can create a drive with a partition but which also appears to the BIOS as a superfloppy for old BIOSes that can only boot with USB-FLOPPY. I tested it, so far only on a 512MB Flash drive and it worked. Note, it uses some files from Syslinux.

Anyway, I ran into a problem: my ‘probepart’ script did not recognise the filesystem of the partition, and this traces back to Jese’s ‘guess_fstype’ returning “unknown” filesystem. However, ‘fdisk -l’ and ‘disktype’ both detect the filesystem ok (it was FAT16). Perhaps the fact that it looks like both a partition and a superfloppy confuses guess_fstype, as you can see from disktype:

# disktype /dev/sda
--- /dev/sda
Block device, size 490 MiB (513802240 bytes)
DOS/MBR partition map
Partition 1: 490.0 MiB (513785856 bytes, 1003488 sectors from 32, bootable)
  Type 0x06 (FAT16)
  FAT16 file system (hints score 4 of 5)
    Volume size 489.8 MiB (513638400 bytes, 62700 clusters of 8 KiB)
    Volume name ""
FAT16 file system (hints score 3 of 5)
  Volume size 489.8 MiB (513638400 bytes, 62700 clusters of 8 KiB)
  Volume name

Jesse will no doubt figure out what the problem is, but in the meantime I have put a workaround into my probepart script. If guess_fstype fails, the script falls back to trying ‘fdisk -l’, which solves my immediate need to detect FAT12, FAT16 and FAT32 filesystems created by the makebootfat utility.

This fixed probepart is now in Dingo, but Puppy 3.02 developers may want it also. I have uploaded it here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

There is a problem that affects Dingo built with the 2.6.21.7 kernel (same kernel as used in Puppy3). For the 2.6.24 kernel I used Squashfs version 3.3 — this includes a kernel patch for the ’squashfs.ko’ module and the ‘unsquashfs’ and ”mksquashfs’ utilities.

Puppy4 (Dingo) can be built with the older 2.6.21.7 kernel, but it’s squashfs.ko module is version 3.2r2. The problem is, if a .sfs file is created with the 3.3 version of ‘mksquashfs’ then the older kernel can’t open it. This situation has occurred with the “devx” file.

I have solved the problem by repatching and recompiling the 2.6.21.7 kernel with Squashfs 3.3.

What has surprised me is I recompiled the kernel in Dingo, but all the old modules still work and load without complaint, although they were compiled in Puppy3. Normally the kernel is very sensitive that kernel and modules be compiled with the same C compiler and glibc versions.
All I did was replace the old squashfs.ko with the new one, also replaced vmlinuz.

Squashfs 3.3 creates significantly smaller .sfs files. I built the Dingo .iso live-CD file with Squashfs 3.2, which has been the situation up until now, and it was 85.08MB. After replacing the kernel and squashfs.ko, I built the .iso file and it was 84.02MB.

This fix is for Dingo only, not required for Puppy3. Although, I suppose you could, as Squashfs 3.3 kernel module can open .sfs files created with an older ‘mksquashfs’.

I have uploaded the 2.6.21.7 kernel source patched with Squashfs 3.3 to here (courtesy of Ted Dog):

http://puptrix.org/sources/kernel-2.6.21.7-dingo/

I created ‘puppy-unleashed-3.02alpha1.tar.gz’ which is my first go at the successor to Puppy 3.01. This tarball is available from ibiblio. Forum member ‘tronkel’ has been working further on this and has recently uploaded 3.02alpha2, see this forum thread:

http://murga-linux.com/puppy/viewtopic.php?t=26517

I enquired as to how he would make available his latest Unleashed, and it was suggested that it would be nice if there is some way that he could just upload the changes only. That would mean he wouldn’t have to do a huge upload, with the problem of hosting it somewhere.

Ok, I had a go at writing a couple of scripts to do the job. The first is ‘diff-create’. Tronkel can use this to create a tarball that only has the differences between his ‘puppy-unleashed’ directory and my original ‘puppy-unleashed-3.02alpha1.tar.gz’. He can then upload this, and someone else can download my original tarball, expand it, then download Tronkel’s “difference-tarball” and then merge it — and I created ‘diff-merge’ to do that.

‘diff-create’ is pretty easy to use. You need to have your development ‘puppy-unleashed’ directory, my original tarball, and the script, all at the same place, that is in the same directory. Then you just execute:

# ./diff-create puppy-unleashed-3.02alpha1.tar.gz

Voila, you get a tarball with just the differences, and with appropriate naming, for example ‘puppy-unleashed-diff-3.02alpha1-3.02alpha3.tar.gz’.

Soneone else can download my ‘puppy-unleashed-3.02alpha1.tar.gz’, expand it (tar -zxf puppy-unleashed-3.02alpha1.tar.gz), which expands into a directory ‘puppy-unleashed’. Then download Tronkels “difference-tarball”, then execute:

# ./diff-merge puppy-unleashed-diff-3.02alpha1-3.02alpha3.tar.gz

Get these scripts from here:

ftp://ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

Note to Tronkel: backup ‘puppy-unleashed’ first, in case ‘diff-create’ has a bug! Also, you need a lot of free space in the partition, 5GB suggested.

I did the compile with T2 again. Previously, Xorg was compiled with DRI disabled, which causes a problem when we want to add a DRI PET package later. I enabled DRI and this required adding ‘xf86driproto’, ‘libdrm’ and ‘glproto’ packages to the T2 build.

I then updated the ‘xorg_base-7.3′ PET package with the recompiled files and renamed it to ‘xorg_base-7.3-1′. I then created a new package, ‘xorg_xorg_dri-7.3′ which (hopefully) has just enough extra files to add DRI and GL support. Kirk has previously created a package, ‘xorg_xorg_full_dri-7.3′ which adds DRI and GL but it also adds everything else, the full Xorg package, and is about 54MB uncompressed. The xorg_xorg_dri-7.3 package is 19MB uncompressed.

The development components of ‘xf86driproto’, ‘libdrm’ and ‘glproto’ were added to the ‘devx’ file.

I have not yet tested xorg_xorg_dri-7.3. Note that kirk also created ‘xorg_xorg_full_dri_DEV-7.3′ PET package, which can be installed to provide all the extra include/pkgconfig/la/a files needed to compile against the extra libraries provided in xorg_xorg_full_dri-7.3 (and xorg_xorg_dri-7.3). The ‘devx’ file just has the basic files for compiling against the xorg_xorg_base-7.3 package (which suits most applications).

When I backported the Dingo scripts to 3.02alpha1, I forgot about PCMCIA.

Puppy3 uses the 2.6.21.7 kernel which was configured not to support the new ‘pcmciautils’ system for handling PCMCIA and instead uses the old ‘pcmcia-cs’ package. The problem is that the bootup and shutdown scripts from Dingo did not recognise the old pcmcia-cs system. I have now fixed that.

I modified /etc/rc.d/rc.modules, /etc/rc.d/rc.shutdown and re-introduced /usr/share/pci-usb-pcmcia.ids. The first two are scriptsand these now seemlessly handle pcmcicautils or pcmcia-cs. If pcmcia-cs is used, then the pci-usb-pcmcia.ids database file is also required.

I have uploaded these files to:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

So, presuming that you have already downloaded and expanded the ‘puppy-unleashed-3.02lpha1′ tarball, which expands in a directory ‘puppy-unleashed’, replace the rc.modules, rc.shutdown and introduce pci-usb-pcmcia.ids in the puppy-unleashed/packages/0rootfs-skeleton-3.02 package.

Note that puppy-unleashed/packages.txt has both ‘pcmcia-cs’ and ‘pcmciautils’ packages selected, however I don’t think the latter should be, as it isn’t being used.

If you’re just coming into playing with the 3.02alpha1 Unleashed tarball, please note that I have made other fixes. Read back through this blog since the announcement of the 3.02alpha1 release. Various fixed files and packages have been uploaded to ibiblio, in that same directory as the above URL.

Note also, if you have played with the Dingo alpha6 that I built with the 2.6.21.7 kernel, it has the same problem. It also requires those 3 files.
Another problem with this build, as someone noted on the forum, is that the ‘devx_396.sfs’ file does not load. This is because the 2.6.21.7 kernel has an older squashfs module (v3.2r2) whereas the ‘mksqushfs’ tool used to create the sfs file is v3.3. V3.3 achieves greater compression but isn’t backwards compatible.

This is very interesting. When I setup my Classmate laptop at the “laptop counter” at the Singapore Budget Terminal, my USB optical mouse did not work at all. This mouse was brand-new, a Logitech mouse, and I was most surprised. This is the desk that I had setup on:

Do you know what was wrong? It’s the yellow color! When I moved to the grey desk surface, the mouse worked fine:

My mouse-saga does not end there. When I moved into my accomodation in India, there was a handy little desk that I setup my laptop, but the mouse barely worked –the cursor responded in half-hearted little jerks. Here is the setup:

The cause was the brown surface! I put the mouse on a piece of white paper and it then worked fine. So, there’s a bit of an education about colors that the mouse laser beam doesn’t like.

That room looks a bit like a jail cell! Where was I? Maybe I’ll post another snapshot that prit1 will recognise.

11 Responses to “Mousepad colors”

1. disciple Says:
   February 19th, 2008 at 4:33 pm

   Sorry - posted a question about where to feedback on the Dingo alphas to a January entry by mistake somehow…

2. BarryK Says:
   February 19th, 2008 at 4:50 pm

   Scroll down this blog to where the latest Dingo alpha is announced. It will also contain links (maybe in the comments) to relevant forum threads.

3. Sage Says:
   February 19th, 2008 at 5:50 pm

   I think this ‘feature’ of optical mice is well-known? I even had a tiny slip of paper which passes for a manual included with one mouse that I bought for a client which suggested the white paper solution you discovered.

4. disciple Says:
   February 19th, 2008 at 5:51 pm

   Thanks, but it seems Windows or something must be magically hiding it from me somehow.
   I found it with Google though
   http://murga-linux.com/puppy/viewtopic.php?p=174634&sid=05bd79a5dfcb32fbdf94c395ddc055c4

5. nic2109 Says:
   February 19th, 2008 at 8:04 pm

   Hi; I’ve not had trouble with colours but have had optical mouse issues where the surface has been reflective. A piece of paper or a thin book usually does the trick, as long as it doesn’t have a glossy finish. Colour sensitivity is a new one on me - I’m tempted to say “Trust Barry to find a bug in anything……”.

   Nick

6. raffy Says:
   February 20th, 2008 at 6:45 am

   Especially using the Japanese way of life for apartment space, that room is spacious.

7. brucehohl Says:
   February 20th, 2008 at 8:19 am

   Hmmm …. the “room looks a bit like a jail cell” … and “doors in India have sliding bolts, both on inside and outside” … might make one worry about getting locked in!

8. Subito Piano Says:
   February 20th, 2008 at 9:34 am

   yeah - i read once that optical mice need some sort of patterned surface underneath them to work correctly — hence a stained wood surface will work, but a plain-colored surface requires a mousepad under it — i think just the fabric on top of them provides enough irregularity for the mice to cooperate.

9. disciple Says:
   February 20th, 2008 at 12:38 pm

   In general, my observations line up with what Subito Piano says.
   I also have a MS intellimouse explorer that doesn’t work on the mousepad that came with our computer

10. sml Says:
    February 20th, 2008 at 4:08 pm

    There is a big difference between an OPTICAL mouse and a LASER mouse.

    Ditch the optical and get a laser.

11. prit1 Says:
    February 27th, 2008 at 9:20 am

    Barry .. did you happen to get the picture that you think I will recognize?

I have uploaded these files to ibiblio:

packages.txt.gz
glibc-2.5-1.tar.gz

To be found here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

I had to go through packages.txt in Unleashed to replace a ‘-’ with a space on every line, as this is now the required format:

Was: “atk-1.18.0″ “atk-1.18.0: atk: atk” on “SLACK12 116K” \
Now: “atk-1.18.0″ “atk 1.18.0: atk: atk” on “SLACK12 116K” \

The glibc package now has the ‘zoneinfo’ directory.

There have been reports about wpa_supplicant not working in Dingo. Forum member tempestuous compiled a special patched version of 0.5.8 back in Puppy 2.16 and we used this in 3.0x (and it’s still in 3.02alpha1). However Dingo has v0.6.0. So, I’ve rolled back to the older version and the package in Dingo is now ‘wpa_supplicant-0.5.8-rt73patch-1′. Read more here:

http://www.murga-linux.com/puppy/viewtopic.php?t=25893&start=45

I stated awhile back that I would not forget the Puppy3 series, so here is 3.02alpha1. It has many features of Dingo back-ported. I have very limited time right now as I have a lot of things to do prior to my holiday (starting this coming Tuesday) so alpha1 has had only basic testing and I have added a small selection of the latest packages. Get it from here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

Some notes:

1. I have not backported the Universal Installer, and it still has the same version as in 3.01. Will do that later.
2. It has the ‘Phacile Blue’ GTK theme and the ‘Black-vg’ JWM . However I think they don’t quite match, but probably some slight mods to the GTK theme, like a less-blue-more-grey background would improve it.
3. The ‘devx_302.sfs’ file is identical to the ‘devx_301.sfs’ file.
4. This is still all Slackware-12 compatible. Mostly I have upgraded scripts plus a few executables

If you find that it works and would like to work on it, with a view to a final release version, I propose that it be the basis of a Community Edition, with the versions 3.02 - 3.09 being alpha and beta releases, final being 3.10.
The problem for me is that I’m going on holiday for 4 weeks and will be narrowly focussed on a few things, like improving the PETget package manager. Also, the main focus of my attention will continue to be Dingo. So, if anyone wants bring 3.02 to a final release, you’re welcome.

What I can do is upload the complete Unleashed tarball that I used to build 3.02alpha1, but I only have two more days broadband access. Right now it’s Friday afternoon, and my broadband access will be until Sunday morning. So let me know promptly if you want it.

I know that there are proposals for the next CE to be built on other versions, so my offer is just a suggestion.

I have built Puppy “Dingo” 4.00 alpha6 with the 2.6.21.7 kernel, the same as used in Puppy 3.01. I mean exactly the same, not recompiled. This kernel supports the /dev/hd* notation for IDE drives. Get it from here:

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

If you had trouble with accessing IDE drives with the alpha6 build with 2.6.24 kernel, give this one ago. There were reports of trouble with wireless drivers with the 2.6.24 kernel, so again try this older kernel.

However, do be very cautious about one thing. As these are both the same version number, be sure that there is no pup_396.sfs or zdrv_396.sfs on the hard drive already — since they will have different kernel drivers in them. When you create a pup_save or do a frugal install, you can have these files on the hard drive, so get rid of them before testing this alternative build.

Get it from here:

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

Read my blog to find out changes since alpha5.

MU created a handy little utility for displaying a file tail in a window, named gtklogfileview. I have put this into alpha6.

Plinej has updated Pcdripper to v3.4 and Pmetatagger to v1.7. These will be in alpha6.

Muggins has compiled the latest Urlgfe file downloader and created a PET package. I have made this an official PET (not in alpha6 but easily installed).

Kirk has done a great job adapting ‘asapm’, a battery monitor applet, to work in Puppy, especially to fit into the limited height of the JWM tray. Read the forum discussion:

http://murga-linux.com/puppy/viewtopic.php?t=25812

I have modified /etc/rc.d/rc.modules2 and /root/.jwmrc-tray as per Kirk’s supplied files. Note that /root/.jwmrc-tray is in the ‘jwm2-2.0.1′ package.

I have created the ‘asapm-3.1.1′ PET package which has Kirk’s applet, /usr/sbin/asapm.

This is great, as we are embracing these baby laptops, which are all about computing on-the-go. I’m going to find this applet very useful when I tote my Classmate off to India!

I have uploaded the patched 2.6.24 kernel source to here:

http://puptrix.org/sources/kernel-2.6.24-dingo/

This kernel is being used in the upcoming Dingo alpha6.

I posted yesterday that I have rewritten the theme handling for JWM and have created just two themes, Original and Citrus-cut. The former is a reasonable match with the original GTK theme, and the latter with the Citrus-cut GTK theme.

I decided to add another JWM theme and chose the dark-grey theme created by forum member ‘vg1′ at the “JWM themes exchange” thread:

http://murga-linux.com/puppy/viewtopic.php?t=23260

I played with the fonts a bit and named it ‘Black-vg’. I also created a dark-grey background image. The Black-vg, dark-grey desktop background and zigbert’s Stardust desktop icons are a good combination. But, I don’t have a really nice matching GTK theme for that combo.

Hey, now it is working! Now “uevents” are occurring.

The pcmciautils package has various utilities, including ‘lspcmcia’ (a symlink to ‘pccardctl’) and ‘pcmcia-socket-startup’. I ran this:

# lspcmcia -vv
Socket 0 Bridge:        [yenta_cardbus]         (bus ID: 0000:0a:09.0)
Configuration:  state: on       ready: no
Available IRQs: 3, 4, 5, 6, 7, 10, 11
Available ioports:      –none–
Available iomem:        0xd0000000 - 0xd00fffff

I reckon that “ready: no” is significant, so I did this:

# pcmcia-socket-startup
# lspcmcia -vv
Socket 0 Bridge:        [yenta_cardbus]         (bus ID: 0000:0a:09.0)
Configuration:  state: on       ready: yes
Voltage: 5.0V Vcc: 5.0V Vpp: 5.0V
Available IRQs: 3, 5, 6, 10, 11
Available ioports:      0×00000100 - 0×000003af
0×000003e0 - 0×000004cf
0×000004d8 - 0×000004ff
0×00000820 - 0×000008ff
0×00000a00 - 0×00000aff
0×00000c00 - 0×00000cff
Available iomem:        0×000c0000 - 0×000fffff
0xd0020000 - 0xd00fffff
Socket 0 Device 0:      [– no driver –]       (bus ID: 0.0)
Configuration:  state: on
Product Name:   Xircom CreditCard Ethernet+Modem II CEM2 1.00
Identification: manf_id: 0×0105 card_id: 0×110a
function: 2 (serial)
prod_id(1): “Xircom” (0×2e3ee845)
prod_id(2): “CreditCard Ethernet+Modem II” (0xeca401bf)
prod_id(3): “CEM2″ (0×72f0d830)
prod_id(4): “1.00″ (0×83dbf271)

Yippee, now we’re cookin’!!!

It says “no driver” above because I have not yet loaded ‘xirc2ps_cs.ko’.

2 Responses to “PCMCIA - step forward again”

1. BarryK Says:
   January 28th, 2008 at 7:20 pm

   I’ve put together a script /etc/init.d/rc.pcmia that runs ‘pcmcia_socket_startup’ and takes care of loading the correct module, for example my ‘xirc2ps.ko’.

   However, there’s a catch-22 situation, as I start with an alias and I don’t have an accurate way of finding the real module to load — my script that I uploaded yesterday is slow and not so accurate. Actually, I think I can make it more accurate, but it’s still too slow.

   This:
   # modprobe –show-depends pcmcia:m0013c0000f02fn00pfn00pa0FFC50D8pb06A97DFDpc98C5B1DBpd01DB7106

   for example, supplied with an alias, will return the actual module name, but only after it is fetched from the ‘zdrv’ file. My modprobe script cannot translate that alias to the actual module name as the aliases in ‘modules.alias.2.6.24′ contain multiple wildcards.

   If you know what module is required, say xirc2ps_cs.ko, then just running this once would do the trick:
   # modprobe xirc2ps_cs
   as it would then be fetched from the zdrv file.
   In future, if this is executed:
   # modprobe pcmcia:m0013c0000f02fn00pfn00pa0FFC50D8pb06A97DFDpc98C5B1DBpd01DB7106
   it will work.

   I really need to redesign how the zdrv file works.

2. BarryK Says:
   January 29th, 2008 at 6:34 am

   I’ve done a temporary fix in /etc/init.d/rc.pcmcia. I got a database file out of the old ‘pcmcia-cs’ package, that matched the manufacturer and product name to the required driver. The card has to be plugged in at bootup for the correct driver to load.

   It’s not perfect but hopefully will give basic PCMCIA functionality. Later I think that I’ll migrate Puppy onto udev and also redesign how the ‘zdrv’ file works to overcome the alias-with-wildcards problem. That will be after Pup 4.00.

I have started to study udev. With the ‘udevd’ daemon I was able to monitor “uvents” (kernel hotplug events) as I plugged and unplugged a USB drive. I was starting to see the usefulness of this.

Then I plugged in my PCMCIA network card. Nothing. No “uevents”. Hmmm. I then looked at /sys/bus/pcmcia/devices and found that the kernel is not responding at all to plugging and unplugging my PCMCIA card.

The kernel was registering PCMCIA events before so what is different now? The 2.6.24 kernel. I checked the ‘.config’ file, all PCMCIA-related settings are the same as for the 2.6.23.12 kernel. I booted up older test CDs built with 2.6.24-rc4 and 2.6.24-rc8, all no go.

I am pretty sure everything is the same, just different kernels. The ‘.config’ files are almost identical. With the 2.6.24 kernel, PCMCIA seems to be dead on my laptop (Acer Aspire 3681WXMi).

Just when I was thinking how wonderful alpha6 is going to be, this one comes along. Well, I’m just about to go off to bugzilla.kernel.org and see if anyone has reported this problem.

Note, I reported a bug to bugzilla.kernel.org about a week ago, as I found a bug in the configuration selection, and I was somewhat disappointed that it did not get fixed before 2.6.24 came out. I get the feeling that the decision to bring out 2.6.24-final was rather sudden. Perhaps they want wider use to get more bug reports, then they’ll bring out 2.6.24.1.

The 2.6.24 has new network drivers, replacing third-party drivers.

‘iwlwifi’ has two modules, iwl3945.ko and iwl4965.ko. The ipw3945.ko module is now retired. I have updated the firmware.

‘rt2×00′ has  rt2×00pci.ko, rt2×00usb.ko, rt61pc.ko, rt73usb.ko, rt2400pci.ko, rt2500pci.ko and rt2500usb.ko, replacing rt61.ko, rt73.ko, rt2400.ko, rt2500.ko and rt2570.ko. I have updated the firmware.

The ‘rt2×00′ homepage has this statement:

two days ago, January 24th, Linux Kernel 2.6.24 was released. This is the first mainline kernel that includes (sadly a somewhat buggy) rt2×00 release.

…hmmm.

I was hoping to use only the automatic GTK-to-JWM theme converter, but when I tested on four or five GTK themes, JWM looked awful. So, I realised that choice of custom JWM themes must be retained, however I have totally rewritten that part of the JWM Configuration tool.

The new script is /usr/local/jwmconfig2/theme_switcher, called from the main GUI window in the JWM Config tool. The script scans the contents of /root/.jwm/themes and displays found themes.

Each theme in /root/.jwm/themes consists of 4 files. For example, I created a ‘Citrus-cut’ theme to match the GTK theme,and the files are ‘Citrus-cut-colors’, ‘Citrus-cut-jwmrc’, ‘Citrus-cut-tray.png’ and ‘Citrus-cut-window.png’. They are self-explanatory when you look at them. The two images are thumbnails of the theme and are displayed in the theme_selector GUI window.

It will be very easy for anyone to add more themes. Currently I only have ‘Citrus-cut’ and ‘Original’.

Some extra notes, for anyone wishng to add new themes to Dingo alpha6 (after it is released), is:

1. the GTK themes are at /usr/share/themes,
2. sets of desktop icons are at /usr/local/lib/X11/themes,
3. and desktop background images are at /usr/share/backgrounds

The menu ‘Menu -> Desktop’ has tools for setting all of these individually. There is currently no master-theme setter, but it is pretty easy to play with the individual tools and mix-and-match to suit ones taste.

One Response to “JWM theme selection rewritten”

1. disciple Says:
   February 19th, 2008 at 4:31 pm

   Barry, is there a forum thread or something you are watching for feedback on the Dingo alphas? I can’t see one… do you just want it here?

I tested ‘gCurl’ that is in Dingo alpha5 but it doesn’t seem to work, or at least it didn’t for me. Even if it can be made to work, it should be intuitive.

So, alpha6 will not have gCurl, instead it will have Lobster’s ‘Pwget’. See forum links:

http://murga-linux.com/puppy/viewtopic.php?t=25567
http://murga-linux.com/puppy/viewtopic.php?t=25183

I have updated these:

Pbackup 3.03 (zigbert)
Pburn 0.9.3 (zigbert)
Pmetatagger 1.4 (plinej)
Pwireless 0.8 (plinej)

I also ugraded Notecase to 1.7.7pre as it has an important bugfix (hyperlinks to URLs did not work). However I don’t have the source and have used a binary compiled by muggins in Puppy 2.16 — works fine in Dingo.

The 2.6 kernel has a new system for handling PCMCIA, but Puppy up until and including Puppy3 uses the old “2.4 kernel” system. The old system took care of loading the correct kernel modules.

The are two modules to be concerned about for a PCMCIA card. Firstly, there is the bridge, or interface between the PCI bus and the PCMCIA card, and these modules are easy to determine. An example is yenta_socket.ko.

Some PCMCIA cards require another specialised kernel module. For example, PCMCIA network cards. I have a Ethernet card that requires the xirc2ps_cs.ko module. It is this second group of modules that are more tricky to determine which to load.

The second group was taken care of by the older PCMCIA sytem, but in Dingo I have gone over to the new 2.6 ‘pcmciautils’ system. All Dingo alpha releases so far only load the PCI-PCMCIA bridge driver, not the second one.

I am seriously thinking of moving to udev, which I think will make selecting and loading the second driver easy. But, I need to learn all about udev first and it won’t be in Puppy 4.00. In the meantime I have written a script that hopefully succeeds in determing the appropriate driver to load. Well, it works for my card.

Do you have a PCMCIA network card? Try the attached script, let me know if it guesses right. I have only tested this script in Dingo.

The script is rather slow. I see it as a temporary solution only, but it really should be rewritten in C if I use it in Puppy 4.00.

I have started a forum thread with this script posted to it and for feedback:

http://www.murga-linux.com/puppy/viewtopic.php?t=25782

Barely two hours after it was announced by Linus, I was downloading it.

I patched it with the usual — loglevel, dpath, squashfs and unionfs.

This kernel has a lot of new wireless drivers, so there is less work for me to compile thrid-party drivers.

I did have a problem as most of the modem drivers would not compile. One problem was missing /usr/include/linux/config.h, which was a deprecated file backabout the 2.6.18 kernel — it doesn’t do any harm to put that in, so I’ll put it into the ‘devx’ file. The problem that caused a whole heap of third-party drivers not to compile is the /usr/src/linux-2.6.24/include/linux/interrupt.h file. There is a missing symbol, ‘SA_SHIRQ’. The initerupt.h file in the 2.6.23.12 kernel states that this is deprecated and will be removed by the end of 2007. Well, I just copied the symbol definition from the interrupt.h file in the2.6.23.12 kerneland inserted into the interrupt.h file in the 2.6.24 kernel. The drivers then compiled ok.

The modem drivers that I successfully compiled: 536, 537, ltmodem, pctel, slmodem, ungrab-winmodem.
The modem driver that I  failed to compile: ess.

The wireless driver that I successfully compiled: madwifi (atheros)
The wirelss driver that I failed to compile: acx

My operation on interrupt.h allowed the 537, ltmodem, pctel, slmodem and sis7019 drivers to compile. However, I don’t yet know whether these drivers will actually work! I’ll test on a Lucent modem, if it works then probably the others are ok.

Dougal reported recently that the ‘Citrus-cut’ GTK theme used in Dingo is noticeably slower on older PCs. I reported that in this blog and suggested that zigbert’s ‘Stardust’ theme could be used as the basis for creating a more cut-down Citrus theme. Okay, I’ve just done it.

Citrus-cut is based on a theme named ‘Citrus’, that I hacked into and made it much smaller. Now, it is hacked yet again and has about the same number of icons as zigbert’s Stardust theme, yet it looks pretty much the same as before. Running ‘du’, the previous Citrus-cut package took up 400KB, now it is 172KB.

I have incremented the version number of the PET package, it is now ‘gtk_theme_citrus_cut-1.1′.

I fixed an issue with installation to a laptop with internal USB Flash storage, that is, the Intel Classmate laptop. It was running in PUPMODE 6, without any tmpfs top layer on the unionfs. I’ve got Puppy installed on my Classmate in what we call a “frugal” installation, where ‘initrd.gz’ and ‘pup_xxx.sfs’ are on the target partition. The partition is ext2 and I chose the full partition to save to.
Anyway, I fixed it so that it comes up in PUPMODE 7, with tmpfs top layer.

Béèm (forum name) reported that Zfind (file search program) crashes in Dingo. I have used it okay, but perhaps it is a question of what type of searches are chosen. Anyway, Dingo also has zigbert’s Pfind and that is very good. I had put Zfind in in addition as I found it to be very simple, but on reconsideration Pfind is also quite easy to use. Therefore Dingo alpha6 will just have Pfind (Zfind is still a PET package though).

Ecomoney (forum name) requested that Puppy should create a swap file in NTFS partitions. When Puppy starts up in PUPMODE 12 (the normal mode when the pup_save file is on the internal fast hard drive) , Puppy will use any swap file found, or if not will create one - except for NTFS. I have removed the NTFS exception. The code for this is in /etc/rc.d/rc.sysinit.

I added the correct setting of the background color for ‘absvolume’, the volume control in the tray, when the current GTK theme is applied to JWM in the JWM configuration program. ‘absvolume’ does not need the ‘-bg’ parameter in earlier puppies but does in Dingo, probably due to the version of GTK (2.12.1).

Note,  HairyWill (forum name) developed absvolume for Puppy. It is not started in /root/.jwmrc-tray like other applets, instead is started in /root/.xinitrd. Will has a later version, that has an icon that changes with audio status, that I have not yet put into Dingo. The one I have currently just has a static “loudspeaker” icon.

PupDial and PupScan had a small bug. The results-box in both of these apps displays as a monospaced font, however after either of these programs has finished, the monospaced font remains applied to certain dialog boxes and text boxes in other GTK applications. The reason for this is that /etc/gtk-2.0/gtkrc gets altered when PupDial and PupScan startup,but gtkrc was not not getting restored to its prior status, thus affecting all later applications. Fixed.

Forum member raffy now has the master username and password for the servage.net account that hosts puppylinux.org and pupweb.org.

If you have any suggestions about the site, or problems with it, please contact raffy. If you would like to see pupweb.org changed in some way, we are open to suggestions.

Thanks to Chris (cthisbear on the forum) for the donation of fifty Australian dollars. Coming just before I leave, is that for spending money on the trip Chris?

Bob (he hasn’t explicitly given me permission to use his last name, and I don’t know his forum name) has been using Linux for 10 years and now uses Puppy. He just wanted to send me something a bit unusual, a token, to say thanks for the fun he has had. It sure is unusual — he has sent me a “Herkimer diamond”, a double-teminated quartz crystal. Sure looks nice. Here is a web page with info:

http://geology.com/articles/herkimer-diamonds.shtml

The free memory applet used in Dingo is different from that used in other puppies. This one uses the Xlib libraries only, the other uses GTK.

The applet was not displaying the correct size when booted from Flash, now fixed. The package is now ‘freememapplet_xlib-0.1.2′. I’ll upload the source to puptrix.org soon.

Rerwin has been working with various people, fixing the Xorg Wizard to work with some difficult video hardware. He has now added the Trident video BIOS dated 1997 as a special case. See forum thread, discussion with Barrington:

http://www.murga-linux.com/puppy/viewtopic.php?p=166725#166725

I have added this workaround to the Xorg Wizard.

See my recent blog post about the OLPC that has been donated to me.

After 5 or 6 hours of usage, I still don’t like the Sugar environment. It is slow and to me seems primitive. The argument that it’s for kids not adults is really weak. Kids really need all the same computing environment that adults use.

A reviewer suggested that it is slow due to the extensive use of Python. Maybe. In Puppy Linux we use Bash scripting, but we use it is a “glue language”, meaning that it glues compiled applications and utilities together. We have small GUI applications written in Bash that load and respond quickly as they adhere to this “glue” philosophy. Unfortunately there is a trend to write huge applications in Python, which also use share-library-binding packages also written in Python — result, bloat and slowness.

I have my Developer Key, and I have been following some instructions to boot from USB, and I have got as far as “Loading initial ramdisk…” at which point it hangs.

OFW… I don’t like that either. The reasoning for choosing it is here:
http://www.mail-archive.com/devel@laptop.org/msg01849.html

I think it’s a bad move going to Forth. I have a lot of Forth experience, a long time ago, but decided that it is a fundamentally flawed language. I was even a member of the Forth Users Group in the USA, and wrote an article about Forth programming for an Australian computer magazine. Faster? …hah, hah, hah.

Today I saw the Asus EeePC 4G in OfficeWorks here in Australia. What a lovely machine! Selling for AU 488 dollars. It was running and I had a peek at the user interface/environment — really nice — that’s what adults and kids really need. I mean, a nice user interface, all the powerful apps like OpenOffice. Nice keyboard.

Hmmm, yes, that’s a problem — the OLPC keyboard has keys that are designed for Sugar — which is annoying if we want to dump Sugar.

My assessment so far is that OLPC is not going to succeed. Intel will be bringing out a new Classmate soon, which “ups the ante”. With standard BIOS, standard keyboard (and nice keys), uDiskOnChip internal Flash …I don’t know if I am allowed to mention the new specs so won’t. But, basically, the Classmate (and EeePC) is all standard-PC and standard-Linux right through, so wide open for the legions of PC-hardware and Linux developer nerds.

I’m having a grumble in this post. If you like Forth, fine. If you like the Sugar interface, good on you. Maybe you think that my comment about the viability of the OLPC project is off — well maybe. This is just my feeling on it so far, and I may be convinced otherwise as I learn more.

Kirk has gone through the exercise of compiling the raw Dingo packages in T2, and has compiled the complete Xorg package with DRI enabled. I had compiled with DRI disabled, to reduce the size. Kirk has posted his PET packages here:

http://www.murga-linux.com/puppy/viewtopic.php?t=25348&start=60

I have repackaged them as official PETs, named ‘xorg_xorg_full_dri-7.3′ and ‘xorg_xorg_full_dri_DEV-7.3′ (note, I reduced the size of the former by moving all the .la, .a and .so-symlinks to the latter). The former is to be installed in addition to the base Xorg packages, and in some cases overwrites some non-DRI-enabled files. This package also has all the bells and whistles, libraries, plugins, left out of the base Dingo packages. If you want to compile any application against these extra libraries, you will need to install the latter package (as well as the ‘devx’ file).

Mark (’MU’ on the forum) has added language localisation support to the Network Wizard. Rerwin recently added some improvements to the Wizard, that are in Dingo alpha5, announce recently on this blog.

Rerwin and MU have been working together to synchronise integration with localisation support, see forum thread:

http://www.murga-linux.com/puppy/viewtopic.php?t=25098

I have used MU’s code posted on Jan 13 to upgrade the Wizard, and have created ‘net_setup-3.96-localised’. I have left ‘net_setup-3.96′ (not localised) in the official repository as I am thinking that might be most practical — that is, when I’m hacking on the script, I would work on the non-localised version, which can later be ported to the localised version when appropriate translaters are available. Well, we only have ‘en’ and ‘de’ so far.

Note, MU has localised some other scripts, but that is specifically for Puppy 3.01.

Forum member ‘ttuuxx’ posted a query about Skipstone in the forum:

http://www.murga-linux.com/puppy/viewtopic.php?t=25610

There is a new version out, 0.9.7. I’ve compiled it for Dingo and made a PET package. It is compiled against the SeaMonkey 1.1.6 libraries. Skipstone itself is quite small, the package uses 444K uncompressed. I wonder how much of SeaMonkey could be removed and Skipstone will still work…

I’m using Skipstone right now. https works, Flash player works. I modified one of the prefs.js files so DejaVu Sans is the default font — this is setup correctly in my PET file.

If you want to try compiling Skipstone yourself, I made some notes, but this of course applies to Dingo:

‘configure’ has to be edited. Comment out, line 1839:

# BK…
# if test -f $mozilla_libs/chrome/comm.jar ; then
MOZILLA_LIB_HOME=$mozilla_libs

# else
#    { { echo “$as_me:$LINENO: error: Cannot find mozilla libs - please use –with-mozilla-libs=path_to_mozilla_libs and specify a path” >&5
# echo “$as_me: error: Cannot find mozilla libs - please use –with-mozilla-libs=path_to_mozilla_libs and specify a path” >&2;}
#   { (exit 1); exit 1; }; }
# fi

# ./configure –prefix=/usr –sysconfdir=/etc –localstatedir=/var –with-mozilla-includes=/usr/include/seamonkey  –with-mozilla-libs=/usr/lib/seamonkey –enable-nls –disable-debug

make fails, have to remove ‘ja.po’, ‘ru.po’, ‘zh_TW.Gig5.po’ from locale directory.

# make
# new2dir make install

Yep, it has happened again. The top-level ‘index.html’ files in my puppylinux.com and goosee.com domains have been hacked into, links inserted. These files are 644 permissions and are static HTML.

Interesting, it seems to have coincided with me enabling comments on this blog, but they were never really turned off, as WordPress does not have a facility to globally turn off comments. Comments were only off for new posts, but I set older posts so that they all had to be approved by the administrator.

So, when I announced yesterday that comments are back on, that was just restoring the default to on for new comments. All comments still have to through the admin for approval.

One thing that is really crappy is that although I have the very latest version of WordPress, spam comments are still able to post without registering. This bug was there before, and it’s a pretty serious one. So, who knows what other big security holes there are!

But, I have to approve all comments, so no spam gets through anymore. So, how has my site been violated this time?

I’ve decided that when I go on holiday, my daughter and her partner will monitor my site. I will give them everything that they need to fix the site, including secure ftp access. I will also endeavour to monitor my site on a daily basis.

I had a go at it anyway, not yet tested. I stripped out all the themes and background image and profiling stuff.

Dougal took thoughtjourney’s original ‘gtk2jwm’ script that was in jwmConfigMgr package and rewrote and greatly enhanced it, and renamed it to ’setJWM’ — you’ll find it in Puppy 2.14R (Revisited). What this script does is convert the current GTK2 theme to a matching JWM theme.

So, I thought, yes, that’s much simpler than having separate themes for JWM. ’setJWM’ is now in the JWM Config package, and I named it back to ‘gtk2jwm’. I have created a new package, ‘jwmconfig2-20080120′.

A couple of people have recently approached me with ideas about how the project could be managed in the future.

I’m going to reflect on it while on holiday, and won’t make any premature statements here.

But, I would like to see the various efforts that are going on, like 2.14R and muppy, getting a bit more “frontal exposure”. Some of these can be presented as on-going official puppies, not just off-shoots. I was even thinking of handing over the “keys” of puppylinux.org to a small group — that is, the master username and password. One great thing is that puppylinux.org hosting is paid-up until 2012.

One question that arose recently about Dingo not having some things, like murgaLua, Tcl/Tk. I’m building a “lean and mean” new distro, but it can be seen as a starting point. There’s no reason why anything cannot be added. Just about every PET or PUP package from earlier puppies works. Quite likely, by the time Slackware 13/14 gets released, it’s package versions will be on a par with what Dingo is now, so there should be reasonable compatibility there to.

I’m thinking that over my holiday I’ll work on improving PETget, my package manager. One planned feature is support of more repositories, not just my official one at ibiblio. Support for a repository on CD too. Categorising the packages into groups would be nice also.

John Doe has added some refinements to his earlier work on the ‘jwmconfig’ package:

http://www.murga-linux.com/puppy/viewtopic.php?t=25348&start=45

I have named this package ‘jwmconfig-18jan08′.

John also discovered the /root/Startup directory. This is something that forum member ‘andrei’ suggested awhile back. It is code in /usr/sbin/delayedrun that will execute anything in /root/Startup. I modified that code so it will only execute files with the excute-flag set, and I followed John’s suggestion and created a README file, with this in it:

Any executable or scripts (or symlink to) placed in this directory
will be executed after the X desktop has loaded.

This is handy if you want something to run automatically.

You can easily create a “symlink” (symbolic link) to an executable.
For example, say that you wanted to run /usr/local/bin/rubix (a game)
everytime Puppy is started. Use ROX-Filer (the file manager) and open
two windows, one on /usr/local/bin, the other on /root/Startup.
Then just drag ‘rubix’ across and a menu will popup and ask if you want
to copy, move or link, and you choose to link.

Note, if you want to execute something at bootup and prior to X desktop
loading, edit /etc/rc.d/rc.local.

Dougal has reported that the Citrus theme used in Dingo alphas is slow. He reports that it is noticeable on older slower PCs.

The Citrus theme does have a rather large ‘gtkrc’ file and lots of graphics that have to be stretched to render in the windows. The accumulation must be slowing things down.

I think that Zigbert’s Stardust theme is compact and fast, while still havng the nice bitmap 3D buttons and highlighting. So, I suppose we could in theory just take Zigbert’s theme and change the colors and voila, we have Citrus?!

Anyone with an interest in GTK themes want to have a go at doing that?

Note, in Dingo, the GTK themes are to be found at /usr/share/themes, and Dingo has a GTK theme-switcher named ‘Chtheme’, which simply edits /root/.gtkrc-2.0 to use the chosen theme.

It’s interesting, Dingo testers are divided into those who like the Citrus theme and those who don’t — it doesn’t seem to invoke a neutral response. Probably those against are in the majority. Well, I wanted a bold statement for the first release of Dingo, and it is undeniably that. I think it looks good on the baby laptops, perhaps a bit overwhelming on big screens.

For feedback, please go to the ‘alpha5′ forum thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=25348

Kirk has devised a network file-sharing system that will be great between Puppy computers. The other approach that we are supporting in Puppy is using Samba, which is particularly suited to sharing with Windows computers. Kirk’s file-sharing uses Curl, pure-ftpd, mpscan and curlftpfs.

Kirk has upgraded Curl from version 7.16.3 to 7.17.1, as the former did not work quite right with the curlftpfs package.

Kirk has fixed a bug in the pure-ftpd package. I have fixed this and the PET package is now ‘pure_ftpd-1.0.22-1′.

Kirk has compiled curlftpfs and mpscan for Dingo. These are very small utilities. More info on these utilities here:
http://curlftpfs.sourceforge.net/
http://mpscan.sourceforge.net/

Kirk’s file-sharing package is introduced here:
http://www.murga-linux.com/puppy/viewtopic.php?t=25537

I have made this into an official PET package and it will be in the next release of Dingo. I renamed the PET package to ‘file_sharing-curlftpfs-mpscan-0.1-0.9.1-0.1.0′ to show that it has other packages in it. Kirk has designed it to work from Rox, by clicking on /root/File-Sharing, however I thought why not make a menu entry also, so I did …untested.

I would like to thank Mike (’mdd’ in the Puppy Forum) for sending me a OLPC XO laptop to get Puppy running on it. That is extremely generous, as Mike purchased it then sent it to me — actually, he bought 3, or was that 6 due to the buy-2 plan?. I have the green one:

Here is the forum thread where Mike and others have been discussing the OLPC. It is interesting to read of Mike’s kid’s reactions to the OLPC and Classmate:
http://www.murga-linux.com/puppy/viewtopic.php?t=22607

I received it a few days ago, and so far have only played with it for about 15 minutes. Interesting, I too was underwhelmed by the Sugar interface (of course, 15 minutes is hardly an indepth evaluation). Yeah, I reckon Puppy would be nice on it, but I’m not so sure how far I’ll get before my holiday, may have to get stuck into it upon return.

Here are some more forum threads on the OLPC:
http://www.murga-linux.com/puppy/viewtopic.php?t=24682
http://www.murga-linux.com/puppy/viewtopic.php?t=25142
http://www.murga-linux.com/puppy/viewtopic.php?t=23359

I have built Puppy Dingo with the 2.6.24-rc8 kernel, for restricted testing.

One thing I’m pleased about. The 2.6.23.12 kernel has a problem with /sys and /proc not getting updated when partitions in a USB drive were changed. For example, if I used GParted to change a partition from vfat to ext2, the information in /sys and /proc did not change to reflect this. Even accessing the partition in some way, like using ‘dd’ to read bytes from it, did not stimulate the kernel to update /sys and /proc. This problem has gone away with this new kernel.

What I need to know, is does this new kernel still have a problem with shutting down on some hardware, as was reported for Dingo alpha4 and alpha5. I think the EeePC was one example. Could testers who had that problem, please grab the iso that I have uploaded and see if it shuts down? The iso file is ‘puppy-3.95-k2.6.24-rc8-TEMPORARY.iso and it is here:

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

Please be sure to boot from CD with ‘puppy pfix=ram’ so Puppy won’t find any other ‘zdrv_395.sfs’ that may be on the computer somewhere. Of course you can boot from a USB pen drive, but be sure to get rid of any pup_save.2fs file.

Some people don’t know that to extract files from an iso file, to place in a USB pen drive for example, you don’t have to burn it to CD first, nor do you have to use Isomaster. In a Rox window, just click on it.

This iso is for limited testing as described above, everyone else please ignore it. The build has some modules missing.

As comments are still turned off for this blog, provide feedback to the alpha5 thread in the forum:

http://www.murga-linux.com/puppy/viewtopic.php?t=25348

A little while ago - Jan 5th I think - I fixed a problem with a USB drive getting mounted with Pmount, but the Rox window showing the content of the mount of the previous USB drive. The solution was to open a Rox window with the ‘-x’ option to cause Rox to rescan the directory.

Today I fixed another problem. In a full hard-drive installation of Puppy, the ‘mount’ command (without any parameters) returns ‘rootfs on / type rootfs (rw)’ even though there is a Linux partition mounted on ‘/’. The ‘df’ command however returns the correct information. I have fixed this, so that Pmount now shows the correct partition that is mounted.

John Doe has improved the JWM-config tool. When changing themes, not all colors in the taskbar change from the default, which John has fixed.

This is the forum thread where John Doe has posted the fix:
http://www.murga-linux.com/puppy/viewtopic.php?t=25348&start=15

This fix affects two packages, ‘jwmconfig-4nov07′ and ‘jwm2-2.0.1′. In the latter case, I edited /etc/xdg/templates/_root_.jwmrc, as this is the template file from which /root/.jwmrc is generated.

I have renamed these packages to ‘jwmconfig-16jan08′ and ‘jwm2-2.0.1-1′ and have uploaded them to ibiblio:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-4/

John commented that the background-setting is not changing when a JWM theme is changed, but I’m thinking that perhaps we should leave that out? Perhaps changing the JWM theme should be just that, the JWM theme. Dingo has a separate tool for setting the background image.

That leaves the tray applet backgrounds…

I reported earlier that Glade, the GTK GUI-builder, version 3.4.x, was unable to find its own icons. I experimented a bit more, and found that by moving its icons from /usr/share/glade3/pixmaps/hicolor (where ‘make install’ had placed them) to /usr/share/icons/hicolor, the ‘glade-3′ application was suddenly able to find them.

I found also that I had to install ‘hicolor-icon-theme-0.10′ which is only an empty directory hierarchy, although it does also install /usr/share/icons/hicolor/index.theme, which may be a needed file — it’s just a text file that lists all the directories under ‘hicolor’, plus a bit of other information. Just moving the icons as described above wasn’t enough for Glade to see them.

So, Glade version 3.4.1 is now in the ‘devx’ file.

There is feedback for alpha5 that booting from a PCMCIA CD drive does not work. That would be because the initial ramdisk currently does not have the ‘yenta-socket’ driver.

Dingo has changed to the ‘pcmciautils’ package, whereas earlier puppies used the ‘cardmgr’ package. The former is the intended successor for the 2.6 kernel.

I’m testing on my laptop. I’ve got a Xircom  “CreditCard Ethernet+Modem II” card. This has both a modem and an Ethernet interface, and I’m testing only the Ethernet component for now.

Running Puppy 3.01, the Ethernet interface is automatically recognised and the ‘xirc2ps_cs’ kernel module automatically loaded. It worked right away.

Running Dingo alpha5, I can see in /var/log/messages that the network interface got recognised, but the kernel module didn’t get loaded. I manually loaded ‘xirc2ps_cs’ and I was in business.

That’s the problem. The new pcmciautils system takes care of loading the core driver, for example ‘yenta-socket’, but not any required driver for the actual card, such as a network module. So, what to do? Puppy does not have UDEV, just hotplug.

The ‘pcmciautils-014′ package is online at ibiblio, if anyone wants to see what’s in it. It has a startup script at /etc/init.d and firmware at /lib/firmware. If anyone would like to comment on this, as I still have comments turned off, kindly respond to the alpha5 forum thread:

http://www.murga-linux.com/puppy/viewtopic.php?t=25348

I have fixed the full hard drive install for Dingo.

I did quite a lot of work on the Universal Installer, mostly tidying up dialog boxes and choices.

I added a choice whether to install/reinstall GRUB or just update an existing installation of GRUB.

There is a new problem with GRUB, as ‘fdisk -l’ may no longer be used to calculate the ‘hdx,x’ drive numbers for GRUB in a system with mixed IDE and SATA hard drives. It worked before, but now due to the IDE drives having /dev/sd* notation, ‘fdisk -l’ may “see” a SATA drive first, whereas GRUB at bootup will “see” a IDE drive first. I have put in a warning about this, with suggestion how to (manually) fix it.

I did a full install on a mixed IDE/SATA system, and had to change ‘hd1,0′ to ‘hd0,0′ in menu.lst, then it booted fine.

Except for that endless looping problem. I fixed that too.

Well, so far I have tested Dingo on 8 different PCs, and the IDE drives are recognised perfectly in all of them. ‘cfdisk’ works too. This is in reply to reports from sage.

This morning when I visited my blog, at www.puppylinux.com/blog/, I got redirected to another site. Also, the CPU became very busy, quickly making the mouse and keyboard unresponsive. I managed to kill SeaMonkey.

I FTP’d to my blog and found that ‘index.php’ and ‘wp-blog-header.php’ have been changed. I restored them to the originals. I have also turned off comments to this blog.

This is serious. How could anyone change those files? Is this yet another security flaw in WordPress?

UPDATE:
The security breach is being discussed here:
http://www.murga-linux.com/puppy/viewtopic.php?t=25382

I have updated one of our source repositories somewhat. This is provided courtesy of Ted Dog and is mostly for hosting source packages that aren’t hosted elsewhere, such as those created by Puppy-developers or some packages especially patched for Puppy.

http://puptrix.org/sources/alphabetical/

The official PET packages used to build Dingo alpha5 have been uploaded to:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-4/

Rerwin requested the latest Network Wizard package, and that is also uploaded, it is ‘net_setup-3.96′.

FreeBASIC compiler is in earlier puppies but not in the Dingo ‘devx’ file. So, I have put it in, version 0.18.3b. Here is an extract from my updated “HOWTO program” page:

If you want the simplicity of Basic and the efficiency of a compiler, then take a look at FreeBASIC. Unlike some other free compilers (such as FreePascal), FreeBASIC generates very small executables, on a par with those generated by C programming. You can also use all the shared libraries in Puppy, including the GTK libraries — and the the FreeBASIC package includes all the GTK tutorial examples taken from the online tutorial at www.gtk.org.

FreeBASIC is available in the ‘devx’ module, so install that as described above, and you’re in business!

After installing the ‘devx’ module, the FreeBASIC examples are to be found at /usr/share/doc/freebasic. Binaries and include files are to be found in /usr/share/freebasic. The compiler ‘fbc’ is in the path at /usr/bin/fbc.

All documentation for FreeBASIC is to be found online at: http://freebasic.net/, however the ‘devx’ module also has it as the User Manual as a CHM file (Microsoft Help format) and recent releases of Puppy have ‘ChmSee’, a reader for this file-format. The CHM help file is to be found at /usr/share/doc/freebasic.

The best editor for writing FreeBASIC programs is Geany (the default text editor in Puppy), as it has color syntax highlighting.

FreeBASIC can also use Glade XML files. There is an application ‘glade2bas’ that will generate a skeleton FreeBASIC application for a particular Glade XML file. A HOWTO is at /usr/share/doc/freebasic/howto_glade_freebasic.pdf. This is all provided in the ‘devx’ file.

Note however, that Glade is not yet in the Dingo devx file. The 3.4.x versions have a showstopper bug and I have emailed the developers. The bug is that the ‘glade-3′ application cannot find its own icons. I tested v3.2.2 but that –and this is odd indeed– lacks the facility to manually drag and resize widgets with the mouse , which is the mainstay of any GUI builder. I’ll put Glade in as soon as they fix it.

A comment: what really causes me extra frustration with Glade is that back in the 90’s I used MS Windows GUI-builder tools, so I have those to compare with. They just worked, intuitive, no hassles, no bugs even, or none that I noticed. They also created a highly efficient compiled resource file, miles faster than the XML system.