Precise Puppy 5.6.1-final, May 29, 2013

Please post any bugs you have found
Message
Author
nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#221 Post by nooby »

Thanks Sylvander, I updatet 5.6.1
but one need to write gnome-mplayer in set run action
in Lupu it is only mplayer so I had no clue :)
Thanks for caring about me.
I use Google Search on Puppy Forum
not an ideal solution though

User avatar
DaveS
Posts: 3685
Joined: Thu 09 Oct 2008, 16:01
Location: UK

#222 Post by DaveS »

5.6.1 menu>system>boot manager configure bootup> choose SFS file, and nothing happens. Surprised this has not been mentioned.
Spup Frugal HD and USB
Root forever!

Brown Mouse
Posts: 564
Joined: Tue 09 Jun 2009, 21:06

#223 Post by Brown Mouse »

DaveS wrote:5.6.1 menu>system>boot manager configure bootup> choose SFS file, and nothing happens. Surprised this has not been mentioned.
All seems to work as it should here.

ckl8r
Posts: 10
Joined: Sat 02 Jun 2012, 13:16

#224 Post by ckl8r »

bark_bark_bark wrote:just like 5.6, 5.6.1's ppm refuses to update the ubuntu repos.

the connection stops here:
That has happened to me before.
The way I got it to work was to use your browser to navigate to the parent web page that wget is trying to download from. Do this before you try to update. I don't know why it works. I may have a strange setup. (had to do this for Precise55 and previuos).

Hope it works for you.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Recent versions of hwclock are incompatible with Psync 2.8

#225 Post by npierce »

npierce wrote:And I think I see what caused Puppy to set the hardware clock incorrectly. But I'll need a little more time to write-up a fix to prevent that . . .
OK, I'm back on this.

The problem was caused by a change in the hwclock utility.

That utility (a part of the util-linux package), when passed either the -w or --systohc option, reads the system clock and writes it to the hardware clock (a.k.a. RTC). You can choose to have it set the hardware clock to local time or to UTC by using the --localtime or --utc options, and the utility will convert the system time accordingly, if necessary, before writing it to the hardware clock.

When hwclock sets the hardware clock, it also writes some data to the /etc/adjtime file, which includes the string "LOCAL" or "UTC" to indicate which time that clock is being set to. If the utility is run with either the -w or --systohc option, but no --localtime or --utc option, it looks at its adjtime file to see what was last used, and uses that again.

But if the adjtime file does not exist, such as when a new distro has just been installed, the utility can't look at the file so uses a default value that is hard-coded in the utility. Previously that default was local time. But since util-linux v2.20 (released 2011-Aug-29), the default is UTC.

The following two excerpts from a bash session will demonstrate.

First on an older Puppy from 2011, which has an older hwclock utility:

Code: Select all

# grep -E "DISTRO_NAME|DISTRO_VERSION" /etc/DISTRO_SPECS
DISTRO_NAME='Racy Puppy'
DISTRO_VERSION=5.2.2
# cat /etc/adjtime
cat: /etc/adjtime: No such file or directory
# hwclock --version
hwclock from util-linux-ng 2.18
# hwclock -w
# cat /etc/adjtime
0.000000 1370595842 0.000000
1370595842
LOCAL
# 
And now on a recent Puppy from May 2013, which has a newer hwclock utility:

Code: Select all

# grep -E "DISTRO_NAME|DISTRO_VERSION" /etc/DISTRO_SPECS
DISTRO_NAME='Precise Puppy'
DISTRO_VERSION=5.6
# cat /etc/adjtime
cat: /etc/adjtime: No such file or directory
# hwclock --version
hwclock from util-linux 2.21.2
# hwclock -w
# cat /etc/adjtime
0.000000 1370616415 0.000000
1370616415
UTC
# 
When tasmod wrote Psync Time Server Synchroniser, the default was local time.

Psync uses hwclock to set the hardware clock to either local time or UTC, depending upon whether or not the box for "Hardware clock set to UTC" was checked at first boot, or whenever quicksetup, quickcountry, countrywizard, or timezone-set was last run. When setting it to UTC, Psync passes the --utc option to hwclock. But when setting it to local time, Psync doesn't pass an option, allowing hwclock to use the default, which had always been local time, if there was no /etc/adjtime file.

The end result is that after installing a Puppy with the new version of hwclock, if the user runs Psync before any other utility that sets the hardware clock (like set-time-for-puppy, set_hwclock_type, or the hwclock utility itself), the hardware clock will always be set to UTC, even if that wasn't the user's choice. And once set to UTC, subsequent runs of Psync will also set it to UTC because it will now default to the value that hwclock stored in the adjtime file, "UTC".

Since this problem only happens when there is no adjtime file, running any utility that properly creates the adjtime file (like set-time-for-puppy, set_hwclock_type, or the hwclock utility itself) before running Psync, will eliminate the problem. There is only a problem when that file doesn't yet exist.

Of course, that also means that if a user boots a live CD or fugal installation with "pfix=ram", preventing the save file from being used, running Psync would then cause this problem, since there would be no adjtime file. But if the user didn't then create a new save file, the good adjtime file would still be in the old save file (if the hwclock was ever set with this Puppy), and available at next boot, at which time the user could run Psync again to correct the hardware clock.


Anyway, I have discussed this with Rob (tasmod), who has his hands full with other things at the moment, and has kindly agreed to let me poke around in his code.

Attached is a .pet that I hope will make Psync compatible with both the old and new versions of hwclock. I have bumped the version from 2.8 to 2.9.

Reference:
The commit for the change to hwclock:hwclock: make RTC default to UTC time

(Amusingly, the person who made the change to hwclock had this to say about it:
The user impact of this change should be minimal, as anyone who has run "hwclock --systohc" before will have their UTC/LOCAL choice already recorded in /etc/adjtime.
That is true, assuming that the the user never installs new distros. :) )
Attachments
psync-2.9.pet
Added support for hwclock >= 2.20
(6.25 KiB) Downloaded 421 times

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#226 Post by Sylvander »

Installed Psync-2.9.
Seems to be working OK.
How should I test it?

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Re: Recent versions of hwclock are incompatible with . . .

#227 Post by npierce »

Sylvander wrote:How should I test it?
1. Run this command and verify that the output is "HWCLOCKTIME=localtime":

Code: Select all

grep "^HWCLOCKTIME" /etc/clock
2. Run this command:

Code: Select all

rm /etc/adjtime
3. Run Psync and synchronise your clock.

4. Run this command and verify that the output is "LOCAL":

Code: Select all

tail -1 /etc/adjtime
If this test was run using Psync 2.8 on a recent Puppy, the output would be "UTC", which is wrong, and would cause the time problem you reported earlier.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#228 Post by Sylvander »

Completed items 1 through 4, and here's the results:

Code: Select all

# grep "^HWCLOCKTIME" /etc/clock
HWCLOCKTIME=localtime
# rm /etc/adjtime
# tail -1 /etc/adjtime
LOCAL
# 
All seems well to me. :D

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Re: Recent versions of hwclock are incompatible with . . .

#229 Post by npierce »

Great! Thanks for testing.

watchdog
Posts: 2021
Joined: Fri 28 Sep 2012, 18:04
Location: Italy

Scanned doc in 5.6.1 and internet fax

#230 Post by watchdog »

Scanned documents (pdf, jpeg in doc files,...) are not accepted in upload by my internet fax service. The same procedure has success in slacko 5.5. The error in precise is something of the kind "file empty (but it's not empty and I can open it with epdfview) or wrong MIME type".

EDIT: solved by:

Code: Select all

update-mime-database /usr/share/mime

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Drive icons may pile up when displayed at right edge.

#231 Post by npierce »

In 2009, shinobar solved a problem which caused the drive icons to pile up on top of each other at certain screen resolutions, such as 800x600, if ROX-Filer's grid step is set to Medium or Coarse. At that time drive icons were always displayed along the bottom edge of the pinboard.

Now drive icons may be displayed along any edge of the pinboard, and recently Ghost Dog ran into a problem when displaying icons along the right edge. (See forum thread: Drive Icons All Bunched Up In The Corner.)

Ghost Dog has since verified that the resolution of the screen that exhibited this problem was 1366x768. This indicated that the problem was similar to the problem shinobar solved for drive icons along the bottom at 800x600.

The problem happens only when the screen width is not an exact multiple of ROX-FIler's grid step (just like the 2009 problem only happened when the screen height was not an exact multiple of the grid step). For more details, see my attempt at an explanation posted here: http://www.murga-linux.com/puppy/viewto ... 520#705520

After Ghost Dog verified that this problem occurred on a 1366x768 screen, I was able to borrow a PC that supported that resolution and so test my theory. Now I have a suggested fix.

Actually, I am attaching four versions of pup_event_frontend_d that correct this problem. One is based on the single-script version of pup_event_frontend_d, as included with recent Puppies. But Barry has been busy and developed a new and improved modular version for use in future Puppies. So I also ported my changes to the appropriate modules of that version. Those two versions contain the fix (based on shinobar's code) as well as some other minor improvements (inspired partly by other contributors to the above thread). Then I decided to make a version of each of those which have just the minimal changes needed to fix the problem, without the minor improvements.


Attached are four versions of the daemon:

1. Drop-in replacement for Precise 5.5, 5.6, 5.6.1, Slacko 5.5, Racy 5.5.
Minimal changes.

2. Drop-in replacement for Precise 5.5, 5.6, 5.6.1, Slacko 5.5, Racy 5.5.
Some of the math moved out of free_coord().

3. Based on current Woof.
Minimal changes.

4. Based on current Woof.
Some of the math moved out of free_coord().

In #1 and #3 I simply added a few lines so that the X coordinates receive the same correction that the Y coordinates have received since shinobar fixed them in 2009.

In #2 and #4 I have added that correction but moved it and much of the related math out of the free_coord() function. This was inspired by posts from Karl Godt and MinHundHettePerro, both of whom pinpointed the problem, and suggested code to fix it which also moved needlessly repetitive code out of the function so that it wasn't repeated for every icon.

Among the stuff moved in #2 and #4, was the code that reads ROX-Filer's Options file. At first I wondered if that might be a bad thing since this daemon would no longer be aware of changes to "pinboard_grid_step", unless it was restarted. Looking closer I realised that this wasn't really a problem because it doesn't really matter if the daemon is aware of changes to "pinboard_grid_step" or not, since after that value is changed, correct icon placement cannot be guaranteed until the daemon is restarted (usually by restarting the X server).

Although there is no guarantee that icons will be placed correctly if "pinboard_grid_step" is changed unless this daemon is restarted, in most cases they will be placed properly. The only time they won't be is when the user wants the icons along the bottom edge of the pinboard (the default) and has a screen resolution with a height which isn't an exact multiple of 32, such as 800x600, or when the user wants the icons along the right edge of the pinboard and has a screen resolution with a width which isn't an exact multiple of 32, such as 1366x768.

In other words, since the daemon should be restarted anyway after changing "pinboard_grid_step" by any user who uses one of the screen resolutions just mentioned, the behavior that occurs if the daemon isn't restarted isn't really worth describing.

But I like to be complete, so will do so anyway. Feel free to skip this part.


(-- Start of exceedingly boring stuff --)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(The "pinboard_grid_step" values that I mention below are limited to the three values available through the ROX-Filer Options menu: 2 (Fine), 16 (Medium), and 32 (Coarse).)

Current daemon:
  • Height not a multiple of 32, and icons along bottom edge:
    • After changing "pinboard_grid_step", plugging in a new drive may cause its icon to appear on top of preexisting drive icons, but not on top of icons for other drives added since the grid step was changed.
  • Width not a multiple of 32, and icons along right edge:
    • This doesn't work at all with current daemon if grid step is changed from "fine" (the default) -- even if the daemon is restarted.
  • Any other combination:
    • Icons will be displayed correctly.

Daemons #1 or #3 above:
  • Height not a multiple of 32, and icons along bottom edge, or width not a multiple of 32 and icons along right edge:
    • After changing "pinboard_grid_step", plugging in a new drive may cause its icon to appear on top of preexisting drive icons, but not on top of icons for other drives added since the grid step was changed.
  • Any other combination:
    • Icons will be displayed correctly.

Daemons #2 or #4 above:
  • Height not a multiple of 32, and icons along bottom edge, or width not a multiple of 32 and icons along right edge:
    • After changing "pinboard_grid_step" to a larger value than it was when this daemon was started, plugging in a new drive may cause its icon to appear on top of other new drives that were added since the grid step was changed, but not on top of preexisting drive icons.

      After changing "pinboard_grid_step" to a smaller value than it was when this daemon was started, plugging in a new drive will cause its icon to be displayed correctly.
  • Any other combination:
    • Icons will be displayed correctly.
Again, it is important to remember that the above describes what could happen only if the daemon is not restarted after the grid step is changed. If it is restarted, daemons #1, #2, #3, and #4 will display the icons correctly in all cases, and the current daemon will also display the icons correctly in all cases except the one case where icons are on the right and the screen width is not a multiple of 32.

(Actually, I should point out that a screen height or width that is not a multiple of 32, but is a multiple of 16 will always work correctly with a grid step of 16 (Medium). But I have lumped 16 together with 32 in the above description because life is too short to spend trying to describe each possible case. Suffice it to say that in some cases above which cause incorrect icon placement when the grid step is 32, there would not be a problem with a grid step of 16, if the appropriate screen dimension was a multiple of 16. Note that neither height at 800x600, nor the width at 1366x768 is a multiple of 32 or 16, so in those cases it is appropriate to lump 32 and 16 together.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(-- End of exceedingly boring stuff --)

(Resumption of moderately boring stuff. :) )


In my #4 daemon, free_coord() SCRN_X and SCRN_Y are no longer used. They are still used in frontend_startup, but the only function currently using them is the first, unused definition of free_coord. If that unused definition was eliminated, there would probably no longer be a need to pass SCRN_X and SCRN_Y to the other scripts. But I've not tested that, so have left that as-is for now.

By the way, in the current Woof version, I noticed that frontend_change didn't source gettext.sh (needed for call to create_icon_func() ), so I've added that and defined TEXTDOMAIN and OUTPUT_CHARSET.

Please note that in the .tar.gz for the modular version, #3 and #4 below, I've only included the modules that I changed. The other modules are also needed for it to run (see Barry's blog: new pup_event_frontend).
Attachments
pup_event_frontend_d_1_onescript_min.tar.gz
Single script, minimal changes
(10.3 KiB) Downloaded 475 times
pup_event_frontend_d_2_onescript.tar.gz
Single script, repetitive code moved out of free_coord()
(10.48 KiB) Downloaded 457 times
pup_event_frontend_d_3_modular_min.tar.gz
Modular, minimal changes
(8.16 KiB) Downloaded 452 times
pup_event_frontend_d_4_modular.tar.gz
Modular, repetitive code moved out of free_coord()
(11.15 KiB) Downloaded 470 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#232 Post by BarryK »

npierce,
That's great, thanks for the in-depth analysis and solution.

Note, pup_event is currently under development in Woof, and the files are changing. The "modular" tarballs that npierce posted above are no longer applicable -- that is, they are modifications of older scripts, not the latest in Woof.

I have gone for no.3, as it is the simplest, and implemented it in Woof.

I will upload Woof tonight, also Raring Puppy (built from Ubuntu 13.04 DEBs) with all the latest goodies.
[url]https://bkhome.org/news/[/url]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#233 Post by npierce »

Barry,

You're welcome. Thanks for implementing this.

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#234 Post by Billtoo »

BarryK wrote:
I will upload Woof tonight, also Raring Puppy (built from Ubuntu 13.04 DEBs) with all the latest goodies.
Will you be starting a thread for feedback?
Last edited by Billtoo on Mon 17 Jun 2013, 11:20, edited 3 times in total.

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#235 Post by Sage »

You did better than me, Bill. Can't get any picture by any method, any driver [XP@3000/1Mb/Radeon7000-64]. This is particularly annoying because the 'Test now' always gives 'OK' whether I use 'unaccelerated', 'Radeon' or 'let it choose'. Sometimes can get back to a prompt but it doesn't help; sometimes just a flashing cursor.
Seem to remember issues with Rarin' previously. One step forward, two steps back is the strategy at Canonical?!

Later: stuck an nV MX440/128n card in. Interesting; picture came up at correct resolution then straightaway returned me to a prompt. Selected nouveau driver and came up with the wrong resolution! Unable to select another. Got the same PPM=prompt feature as Bill, supra.

This one has a very long way to go. Get the feeling that BK's skills would be best deployed on honing Precise, Wary and Racy - possibly ARMs ?

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#236 Post by anikin »

Moving this post to the Raring-5692 thread.

My apologies.
Last edited by anikin on Mon 17 Jun 2013, 16:19, edited 1 time in total.

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#237 Post by Billtoo »

. message offtopic - removed
Last edited by Billtoo on Mon 17 Jun 2013, 11:22, edited 2 times in total.

User avatar
OscarTalks
Posts: 2196
Joined: Mon 06 Feb 2012, 00:58
Location: London, England

#238 Post by OscarTalks »

I have moved this message to the new Raring Puppy 5.6.92 thread here:-

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

Apologies for any inconvenience.
Last edited by OscarTalks on Mon 17 Jun 2013, 14:49, edited 1 time in total.
Oscar in England
Image

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#239 Post by Billtoo »

message offtopic - removed
Last edited by Billtoo on Mon 17 Jun 2013, 11:23, edited 1 time in total.

Jasper

#240 Post by Jasper »

Though on 15th June 2013, on page 16 above, BarryK wrote
I will upload Woof tonight, also Raring Puppy (built from
Ubuntu 13.04 DEBs) with all the latest goodies.

this is still a Precise Puppy thread - so it seems wholly inappropriate to post Raring comments here?

Post Reply