(old)Puppy Linux Discussion Forum

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...

session wrote: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...

I have now two frugals of wary 5.5: one with glibc upgrade and firefox 19.0 from which I'm writing. I use to install mozilla browsers from:

http://releases.mozilla.org/pub/mozilla ... /releases/

and

http://releases.mozilla.org/pub/mozilla ... /releases/

My frugal with firefox works fine on my new hardware, a laptop with celeron and 2 Gb RAM. My old desktop is gone. From this frugal with glibc upgrade, if you install the original glibc from repository by PPM, you can obtain the same of the original wary where I run seamonkey 2.16. It works fine, too.

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.

Bonjour à toutes et tous,

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

Cordialement

esmourguit wrote:I noticed this problem with Puppy Podcast Grabber. What to do to change this erratic behavior?

You need to replace every instance of "2>&1" with "2>&1 | tail -n1".

This should do it:

Bonjour à toutes et tous,

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

Cordialement

James C wrote:FWIW, Opera 12.14 works fine too.

How do you install Operal 12.14?
Where do you get it?

Bill

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

Where do you get it?

Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Sage wrote:

Where do you get it?

Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Yes, but this is something I have yet to learn, which distribution, which package model...

I was hoping for some helpful guidance.

So... Other (DEB) and Debian package?

Well... I will try that, thank you.

Bill

broomdodger wrote:

Sage wrote:

Where do you get it?

Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Yes, but this is something I have yet to learn, which distribution, which package model...

I was hoping for some helpful guidance.

So... Other (DEB) and Debian package?

Well... I will try that, thank you.

Bill

ok,, downloaded:
Other (DEB)
Debian package
double clicked
Opera 12.14 is installed and runs great, seems more memory efficient than Seamonkey
--and--
The screen scaled nicely for this Asus 701 Eee PC with 800x480 display!
That was (too) easy.
Thank you for the nudge.
Bill

broomdodger wrote:

broomdodger wrote:

Sage wrote: Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Yes, but this is something I have yet to learn, which distribution, which package model...

I was hoping for some helpful guidance.

So... Other (DEB) and Debian package?

Well... I will try that, thank you.

Bill

ok,, downloaded:
Other (DEB)
Debian package
double clicked
Opera 12.14 is installed and runs great, seems more memory efficient than Seamonkey
--and--
The screen scaled nicely for this Asus 701 Eee PC with 800x480 display!
That was (too) easy.
Thank you for the nudge.
Bill

Sage covered it for me........ sometimes the easy way actually works.

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.

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

Monsie wrote: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

It also affects Slacko and is incredibly stupid, annoying, and
disgusting.

Interesting - yet to try - however, opinion from user “Croc Ddee

Also yet to try, but I agree it is less than professional. The following might suffice.
http://www.soundsnap.com/tags/dustbin_lid

Downloading Racy 55 now. This should be interesting -- I've got this one system that won't play nice with any puppy that has a 2.6.x.x kernel. I've yet to try a 3.x.x.x kernel on it because it's a Celeron M board (processor soldered down, it's a very strange board indeed!) and I can't find anything that's both 3.x.x.x and non-PAE.

Does anyone know whether Racy 55 uses aufs or UnionFS? I know Racy 53 uses UnionFS --it's in the release notes-- but I'm not sure about Racy 55. This *might* be good to know, for my board.

Just in brief: what happens is, right after "recognizing media devices" and right before xorgwizard kicks in, something goes horribly wrong and I get this massive wall of text that I really don't understand. It's a little different each time, too. I've a thread on the subject here --> http://murga-linux.com/puppy/viewtopic.php?t=84108

I know Racy 53 uses UnionFS

Racy-5.2.2 uses unionfs, racy-5.3 aufs.

Whoops

OK then, anyone know of a non-PAE variant of Racy 522?