Puppy Linux Discussion Forum

[session]

OK, I see now what was meant, Watchdog was trying to run a Precise (or other puppy) build. So, yeah, vanilla builds are your answer.

In any case, I still recommend Seamonkey over Firefox because vanilla Firefox is noticeably slower on my modest machine...

[watchdog]

[rcrsn51]

Grub Legacy Bootloader Config is broken in Wary 5.5. The problem is with Xdialog and GTK, specifically the menubox widget. It is now throwing an error message into 2>/tmp/xxx. So grubconfig cannot parse the results.

This is patchable. However, fans of Legacy GRUB may prefer to use the light-weight replacement here. It will appear in the System menu as Legacy GRUB Config 2013.

FYI, I have searched for other apps that may be affected by this bug. The only one I could find is the podcast grabber.

[esmourguit]

Bonjour à toutes et tous,

I noticed this problem with Puppy Podcast Grabber.
What to do to change this erratic behavior?
Thank you.

Cordialement

[rcrsn51]

[esmourguit]

Bonjour à toutes et tous,

@ rcrsn51,
A thousand thank you Bill, it works perfectly.

Cordialement

[broomdodger]

[broomdodger]

racy 5.5
wary 5.5

Both work well on an old 2001 Asus 701 Eee PC, 4 GB SSD, 512 MB RAM.

The original Linux would not boot. The SSD had 4 partitions. I booted from an external CD, GParted to one partition ext2, manual frugal install, grub4dos, now happy as a clam (shell).

Wireless is better than some larger laptops.
2.5 hours battery life, it was 'stored' for 2+ years!

Compiled Sylpheed 3.4.0beta2 works great.
Compiled vim 7.3.843 also works great.

Bill

[Sage]

[broomdodger]

[broomdodger]

[James C]

[npierce]

Assuming that a user understands the information requested by remasterpup2 dialogs, and so provides the correct information, this bug would not ever be seen. As the saying goes, "garbage in equals garbage out". Applications don't always do what the user wants, only what the user tells them to.

If this bug only resulted in remasterpup2 failing to produce the desired remaster because the user supplied the wrong information, it might not be worth mentioning. But since the consequences of this bug are a bit severe, I thought it should be reported.

This bug is not the result of recent changes to remasterpup2. This bug has appeared because of a change in behaviour of the fuser utility. The same code worked fine with the fuser supplied with Puppy 4.3.1.


Steps to reproduce - - -

WARNING: Don't try this at home!!!
(at least not unless you have saved everything you are working on to physical media)

1. Mount a non-Puppy virtual CD or real CD/DVD, preferably non-writable. (Actually, the program should never get as far as writing -- but it doesn't hurt to be safe.)

2. Run remasterpup2.

3. Forget that you have a non-Puppy CD in the drive and select it when prompted to "Choose the CD/DVD drive...".

Expected results: remasterpup2 gives an error message and exits.

Actual results: X and sometimes other processes are killed, sometimes enough to bring Puppy down.


Here's what's happening - - -

After the user selects the CD or virtual CD, remasterpup2 checks to be sure it has the initrd.gz file. If it doesn't, it is not the proper CD, so remasterpup2 unmounts it, after killing any process that was using it.

That behaviour goes back to the days when the user was only asked to identify the CD/DVD drive. I guess the idea was to automatically eject a CD/DVD that was obviously not the one needed, so that the user could then mount the proper CD. Nowadays the user is asked to mount a virtual CD or put the proper CD in the drive before this dialog appears.

In the days of Puppy 4.3.1 this might cause a few surprises, such as killing ROX-Filer if it had a window open for the mount point, but it didn't crash Puppy.

Here is what changed: remasterpup2 uses the fuser utility to determine what processes are using the device, and to kill those processes before unmounting the CD. It seems that the old fuser utility (fuser (PSmisc) 22.5, as in Puppy 4.3.1) didn't list any processes for block devices unless the device was mounted and the mount point was in use. The newer fuser utility (fuser (PSmisc) 22.14, as in Puppy Racy 5.2.2 and 5.4.91) doesn't treat block devices specially, and so lists a ton of processes using them, whether the mount point is in use or not. When it starts killing them, things are not pretty.


Here is a suggested solution - - -

Rather than modify the existing test to work with the new version of the fuser utility, I decided to try a new test that takes place before the user is asked to choose the CD or virtual CD. This way the user can't choose a CD without initrd.gz, so there is no need to unmount such a CD, or kill any processes.

I've also included a suggested fix for another minor bug. In recent versions of remasterpup2, the CD drive began showing up in the $VIRTUALCD list, so appeared twice in the list of choices in the dialog.

A modified version of remasterpup2 (based on the 2013-Mar-07 version in Woof) is attached.

I've also attached a diff file. The "@@ . . . @@" numbers in the following explanation identify the related code blocks in the diff file.


@@ -85,6 +86,27 @@

This block of code has been added to the choice_cdd function. If the function is passed "filter" as an argument, this code filters out any mounted device that doesn't contain the files initrd.gz and $PUPPYSFS in its top directory. By filtering out any mounted device that doesn't have initrd.gz, the user is never given the opportunity to choose that device, and so the code that checked after the user chose the device (and the troublesome call to fuser in that code) never executes.

It also filters out any mounted device that doesn't have the proper $PUPPYSFS file (e.g., puppy_racy_5.4.91.sfs). This was not checked by the code before, but one of the message boxes displayed a WARNING to the user to be sure that the CD or virtual CD is correct for the currently running Puppy, and suggested to the user that it can be checked by ensuring that the CD or virtual CD has the proper $PUPPYSFS file. Now that is double-checked by this code.

If there is some legitimate reason that a user would have to ignore that warning, and use a CD without the proper $PUPPYSFS file (although I can't think of such a reason), then this check for the proper $PUPPYSFS should not be implemented.

Also, if the check for the proper $PUPPYSFS is implemented, perhaps the check for initrd.gz is now unnecessary (although I suppose that someone might have a CD that isn't a Puppy Live-CD, but just happened to have the proper $PUPPYSFS file in its top directory).


@@ -369,7 +391,7 @@

This corrects another bug. Previously the CD drive was being added to VIRTUALCD.


@@ -380,12 +402,12 @@

The first call to the choice_cdd function now passes the "filter" argument so that the filtering will be done. (The second call, which only executes if the user is using a virtual CD and so hasn't yet selected a CD drive, is unchanged, so doesn't pass any argument, and no filtering will be done.)

The final change is to the first line in the obsolete code that previously checked the user's choice of CD or virtual CD to be sure that it contained initrd.gz, and unmounted it if it did not (after killing all processes that were using it). I've only added a comment to this line, but the if/fi block could certainly be eliminated, since in theory it should never execute any more.

[Monsie]

Hi all,

I was somewhat surprised and somewhat taken aback when I discovered the sound byte associated with using the trash: namely a loud belching or burping noise. I'm hoping this is a mistake of some sort and not an attempt at humor... I am only one voice, so I would ask the Community to consider if this is how we want to present Puppy Linux to the rest of the world...

Respectfully,
Monsie

[rjbrewer]