Clock Icon

[Mick Ab]

I have a clock icon on my desktop PC which opens on reboot and then remains
on the top right of the screen all the time.

However, for some reason it has moved (not sure how this happened) and is
now in the middle of the screen under my browser windows (so not visible).

I would like to move the clock, but can't seem to move it with my mouse -
none of the buttons when pressed and held down move it and right clicking
doesn't do anything either.

Can anyone help, please ?

[OT] your clock, was Re: Verify a mirror?

[David Wright]

Your clock appears to be fast by the precise number of seconds it took
for your post to leave your computer and reach my mail server.

  Arrived: Tue, 20 Sep 2022 19:16:05 +0100 (BST)
  Posted:  Tue, 20 Sep 2022 20:16:05 +0200

That's the output of a tiny script that I was just tweaking, that
uses sed to extract the times from the first Received: header and
the Date: one.

I have mutt keys that print the UTC or Local (mine) post time, but
was just adding one to measure the transit time for tardy postings.
I tested it on a random post (yours—it's short), and was worried
for a moment that it was matching the wrong lines. But no, it's
your clock.

sed -n -e '/^[[:space:]]\+for <.*lionunicorn.co.uk>;/{s/.*; /Arrived: 
/;p};/^Date: /{s/Date: /Poste\
d:  /;p}'

for anyone who's wondering.

Cheers,
David.

Re: Setting system/ rtc clock

[Curt]

On 2022-09-18, Richard Schires  wrote:
> The problem that I am trying to resolve is getting the
> system clock and CMOS clock to match.

Why is that a problem? 

Re: Setting system/ rtc clock

[David]

On Mon, 19 Sept 2022 at 13:14, David Wright  wrote:
> On Mon 19 Sep 2022 at 13:05:34 (+1000), David wrote:
> > On Mon, 19 Sept 2022 at 06:47, Richard Schires  wrote:

> > > I've been searching for an answer and keep going in a circle.
> >
> > Are there any other operating systems or virtual machines active
> > on this machine? That can get tricky.
> >
> > If there is only one, then it sounds like your timezone isn't
> > matching your expectations.
> >
> > The easiest method is to configure hardware clock as UTC
> > and specify your timezone, because that avoids messing
> > around with the hardware clock every time that daylight saving
> > changes localtime changes, and avoids invalid/duplicate
> > timestamps.
> >
> > The docs I would read to guide investigating this are
> >   'man 8 hwclock'
> > and
> >   https://wiki.archlinux.org/title/System_time
> >
> > I would start by reading
> >   https://wiki.debian.org/DateTime
> > but you might need more detail than it provides.
>
> The OP's timezone is correct, -0500 currently, as provided by
> America/Chicago. The disagreement is on whether the RTC is
> running UTC or LOCAL. Currently, it's set to UTC. The critical
> lines are:
>
> > > > I can get the system clock set through the date command;
> > > > sudo date -s "D M Y H:M:S"
> > > > Problem is that resets the CMOS time way off.
>
> So it comes down to persuading the OP that the CMOS time being
> "way off", ie five hours ahead, is in fact sensible, correct,
> and easier to live with. (The OP has not mentioned any other
> OS as being installed, but that's not a showstopper either.)

Agree 100%. That's what my paragraph "The
easiest method .." was suggesting, and the remainder of my
message was links, because they said they had been
searching without success, so I offered what I would use
as reference docs.

If I had written "understanding" instead of "investigating"
in the next para then that might have been clearer.

Cheers.

Re: Setting system/ rtc clock

[David Wright]

On Mon 19 Sep 2022 at 13:05:34 (+1000), David wrote:
> On Mon, 19 Sept 2022 at 06:47, Richard Schires  wrote:
> 
> > I've been searching for an answer and keep going in a circle.
> 
> Are there any other operating systems or virtual machines active
> on this machine? That can get tricky.
> 
> If there is only one, then it sounds like your timezone isn't
> matching your expectations.
> 
> The easiest method is to configure hardware clock as UTC
> and specify your timezone, because that avoids messing
> around with the hardware clock every time that daylight saving
> changes localtime changes, and avoids invalid/duplicate
> timestamps.
> 
> The docs I would read to guide investigating this are
>   'man 8 hwclock'
> and
>   https://wiki.archlinux.org/title/System_time
> 
> I would start by reading
>   https://wiki.debian.org/DateTime
> but you might need more detail than it provides.

The OP's timezone is correct, -0500 currently, as provided by
America/Chicago. The disagreement is on whether the RTC is
running UTC or LOCAL. Currently, it's set to UTC. The critical
lines are:

> > > I can get the system clock set through the date command;
> > > sudo date -s "D M Y H:M:S"
> > > Problem is that resets the CMOS time way off.

So it comes down to persuading the OP that the CMOS time being
"way off", ie five hours ahead, is in fact sensible, correct,
and easier to live with. (The OP has not mentioned any other
OS as being installed, but that's not a showstopper either.)

Cheers,
David.

Re: Setting system/ rtc clock

[David]

On Mon, 19 Sept 2022 at 06:47, Richard Schires  wrote:

> I've been searching for an answer and keep going in a circle.

Hi,

Are there any other operating systems or virtual machines active
on this machine? That can get tricky.

If there is only one, then it sounds like your timezone isn't
matching your expectations.

The easiest method is to configure hardware clock as UTC
and specify your timezone, because that avoids messing
around with the hardware clock every time that daylight saving
changes localtime changes, and avoids invalid/duplicate
timestamps.

The docs I would read to guide investigating this are
  'man 8 hwclock'
and
  https://wiki.archlinux.org/title/System_time

I would start by reading
  https://wiki.debian.org/DateTime
but you might need more detail than it provides.

Re: Setting system/ rtc clock

[Rodrigo Cunha]

Set the other timezone, in debian.
https://linuxize.com/post/how-to-set-or-change-timezone-on-debian-10/
Or set the timezone in the hp system, to your localtime.

On Sun, Sep 18, 2022 at 6:05 PM David Wright 
wrote:

> On Sun 18 Sep 2022 at 15:31:49 (-0500), Richard Schires wrote:
> > I've been searching for an answer and keep going in a circle.
> > I hope you can help or direct me to someone who can. I am new to Linux.
> > I am using an HP ML150 G2 to run a tabletop CNC mill. The software is
> > LinuxCNC on Debian. The problem that I am trying to resolve is getting
> the
> > system clock and CMOS clock to match.
> > If I set the time in the CMOS, reboot, the system time is five hours off.
> > I can get the system clock set through the date command;
> > sudo date -s "D M Y H:M:S"
> > Problem is that resets the CMOS time way off.
>
> Yes, it sets it to UTC. If you can persuade yourself that running
> the CMOS clock on UTC is sensible, then just stick with that.
> It makes life a lot simpler (no clock changes in spring and fall).
>
> > I've tried using hwclock -w to write the system time to CMOS but doesn't
> > work.
> > I know I could just keep the system time and ignore the CMOS time but
> > should be able to get the two to match.
> > Would appreciate your help or direction.
>
> Or you might want to explain why the CMOS time needs to be Local time,
> which gets adjusted whenever the clocks change or you travel.
>
> Cheers,
> David.
>
>

-- 
Atenciosamente,
Rodrigo da Silva Cunha
São Gonçalo, RJ - Brasil

Re: Setting system/ rtc clock

[David Wright]

On Sun 18 Sep 2022 at 15:31:49 (-0500), Richard Schires wrote:
> I've been searching for an answer and keep going in a circle.
> I hope you can help or direct me to someone who can. I am new to Linux.
> I am using an HP ML150 G2 to run a tabletop CNC mill. The software is
> LinuxCNC on Debian. The problem that I am trying to resolve is getting the
> system clock and CMOS clock to match.
> If I set the time in the CMOS, reboot, the system time is five hours off.
> I can get the system clock set through the date command;
> sudo date -s "D M Y H:M:S"
> Problem is that resets the CMOS time way off.

Yes, it sets it to UTC. If you can persuade yourself that running
the CMOS clock on UTC is sensible, then just stick with that.
It makes life a lot simpler (no clock changes in spring and fall).

> I've tried using hwclock -w to write the system time to CMOS but doesn't
> work.
> I know I could just keep the system time and ignore the CMOS time but
> should be able to get the two to match.
> Would appreciate your help or direction.

Or you might want to explain why the CMOS time needs to be Local time,
which gets adjusted whenever the clocks change or you travel.

Cheers,
David.

Setting system/ rtc clock

[Richard Schires]

I've been searching for an answer and keep going in a circle.
I hope you can help or direct me to someone who can. I am new to Linux.
I am using an HP ML150 G2 to run a tabletop CNC mill. The software is
LinuxCNC on Debian. The problem that I am trying to resolve is getting the
system clock and CMOS clock to match.
If I set the time in the CMOS, reboot, the system time is five hours off.
I can get the system clock set through the date command;
sudo date -s "D M Y H:M:S"
Problem is that resets the CMOS time way off.
I've tried using hwclock -w to write the system time to CMOS but doesn't
work.
I know I could just keep the system time and ignore the CMOS time but
should be able to get the two to match.
Would appreciate your help or direction.

Re: CMOS clock (was: Changing from Debian 9.13 to Debian 11.3)

[tomas]

On Thu, Apr 21, 2022 at 05:21:56PM -0400, Stefan Monnier wrote:
> > (When switching between Unix and Windows, I need t adjust the CMOS clock on
> > the next boot.)
> 
> Side note: You could presumably skip this by configuring your Windows
> installs to use UTC for the CMOS clock.  See e.g.:
> 
> https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows

Anecdote: there was a time where Microsoft hadn't yet understood the
concept of a time-zone independent system time which was then translated
to a more user-facing local time. UNIX was already happy doing that.

I was working back then for a software shop doing C development for DOS
(ick...), then Windows.

Timestamps for files under Windows were, of course, local time too.
Imagine Make's confusion (which relies on comparing file time stamps)
the "Day After", especially when files were copied over from a sane
Unix-y box (we had Coherent, then, yes, Linux).

We decided to put all Windows boxes in a time zone which was
"naturally" GMT and had no DST changes. I remember all our Windows
boxes lived in Liberia/Monrovia. Make was happy.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CMOS clock (was: Changing from Debian 9.13 to Debian 11.3)

[David Christensen]

On 4/21/22 14:21, Stefan Monnier wrote:

(When switching between Unix and Windows, I need t adjust the CMOS clock on
the next boot.)


Side note: You could presumably skip this by configuring your Windows
installs to use UTC for the CMOS clock.  See e.g.:

 https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows



Yes, others have suggested that.  I prefer to keep the habit -- for when 
I use a live Debian USB stick to mess with other Windows computers.



David

Re: simple talking clock / reminder for when monitor is off and it is dark

[Samuel Wales]

thanks very much to all.

i almst missed this as it didn't show uyp in my inbox.

it sounds like there exist things that say the time or can be made to.
then i can use cron to run it or at for a one-off.

i have beep turned off [and currently pulseaudio purged] but videos
play sound with no problem so great.


On 3/22/22, Will Mengarini  wrote:
> * Samuel Wales  [22-03/20=Su 23:03 -0700]:
>> [...] i want debian to tell me the time at certain times.
>
> Nobody has yet mentioned the festival package, which is a full
> text-to-speech system.  Once you have that installed, you can use
> cron or at jobs to speak whatever you want at specific times.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: simple talking clock / reminder for when monitor is off and it is dark

[Will Mengarini]

* Samuel Wales  [22-03/20=Su 23:03 -0700]:
> [...] i want debian to tell me the time at certain times.

Nobody has yet mentioned the festival package, which is a full
text-to-speech system.  Once you have that installed, you can use
cron or at jobs to speak whatever you want at specific times.

Re: simple talking clock / reminder for when monitor is off and it is dark

[Geoff Shang]

On Sun, 20 Mar 2022, Samuel Wales wrote:


i want debian to tell me the time at certain times.  for example
tonight i have to take medicine at 2:40 am.


I second the suggestions of at and cron.

If you want a one-off reminder, use at.

If you want a regular reminder use cron.  Cron has a lot of flexibility in 
its scheduling.


For the actual saying of the time, you could use the saytime package.

I've not used it in many, many years, but I see that it's still in Debian 
and it uses sox so it should still work.


HTH,
Geoff.

Re: simple talking clock / reminder for when monitor is off and it is dark

[Charles Curley]

On Sun, 20 Mar 2022 23:03:52 -0700
Samuel Wales  wrote:

> i use slock and turn off monitor with ddccontrol.

I use the monitors attached to my desktop for sound. I find that when
they are shut off, either manually or by the computer's power management
software, sound ceases to work (unlike my laptops). You might be
affected by this.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: simple talking clock / reminder for when monitor is off and it is dark

[Greg Wooledge]

On Mon, Mar 21, 2022 at 01:21:19PM -0300, Chris Mitchell wrote:
> Personally, I would use a custom systemd timer unit for this. Systemd
> is already running most of your system, and it offers a scheduling
> syntax that is (AFAIK) more flexible than cron's, and (IMHO) much
> easier to read. For example "Every day, once an hour, on the hour, but
> only between midnight and 07:00 (inclusive)" would be:
>   OnCalendar=00..07:00

In crontab(5), that would be:

0 0-7 * * * /your/command

I'm not familiar with systemd timers, so maybe what you say is true,
about them being more flexible, but in this specific example, crontab
is perfectly capable of doing the job.

The biggest thing to be aware of with crontab/at jobs, and I would
presume with systemd timer jobs as well, is that the commands are
run in a minimalist environment inherited from the cron daemon (or,
I assume, from systemd).  Some of the things you're accustomed to having
in your interactive environment won't be available.  Jobs won't run with
a controlling terminal, nor with an X $DISPLAY variable.  Make sure
you write your scripts/commands with those limitations in mind.

For the OP's question, what's really needed is access to the sound system.
I'm not sure what happens if a job fires after you've booted but before
you've ever logged in, or after you've logged in and then logged out.  Do
you still have access to the sound system without an active login session?
These are the kinds of things you'd either need to test, or research.

Re: simple talking clock / reminder for when monitor is off and it is dark

[Chris Mitchell]

On Sun, 20 Mar 2022 23:03:52 -0700
Samuel Wales  wrote:

> i have to have all lights and monitors off at night.  but i have to
> know the time so i can take medicine.
> 
> i use slock and turn off monitor with ddccontrol.  this might turn off
> mouse and keyboard; i wouild have to check.
> 
> i want debian to tell me the time at certain times.  for example
> tonight i have to take medicine at 2:40 am.
> 
> here are ideas:
> 
> - tell me time when i right click [kb much less accessible]
> - tell me at a prespecified time like 2.40 am
> - tell me the following hours: midnight, 1 am, 2am
> 
> any would be ok i think.

There are a number of ways you could approach this, depending largely
on whether you want the simplest way to get a reminder at one specific
time vs a flexible talking reminder system.

Personally, I would use a custom systemd timer unit for this. Systemd
is already running most of your system, and it offers a scheduling
syntax that is (AFAIK) more flexible than cron's, and (IMHO) much
easier to read. For example "Every day, once an hour, on the hour, but
only between midnight and 07:00 (inclusive)" would be:
  OnCalendar=00..07:00

The timer unit in turn triggers a service unit, which can run a command
such as `aplay /home/sam/medicine.wav` like Dan's example, if you want
a single-purpose pre-recorded message. Or you could use a command like
`espeak-ng "It is now $(date +%R)"` so it'll simply announce the
current time whenever it's triggered, thus giving you a general-purpose
talking clock.

Note that if you make the timer/service unit pair "system" units (in
/etc/systemd/system), they'll run (as root) as long as the machine is
up and running. If you make them "user" units (in
~/.config/systemd/user/), by default they'll run only when you're
logged in. If you want to have user units run when the user is not
logged in, the systemd terminology for that is "enable lingering".

If you're not familiar with the syntax of systemd unit files, there is
a bit of a learning curve, but I'd bet that if you can script in
Bash, it won't take you long to get to the point where you can write a
minimal timer and service unit pair for a job like this.

Cheers!
 -Chris

Re: simple talking clock / reminder for when monitor is off and it is dark

[Dan Ritter]

Samuel Wales wrote: 
> i have to have all lights and monitors off at night.  but i have to
> know the time so i can take medicine.
> 
> i want debian to tell me the time at certain times.  for example
> tonight i have to take medicine at 2:40 am.
> 
> here are ideas:
> 
> - tell me time when i right click [kb much less accessible]
> - tell me at a prespecified time like 2.40 am
> - tell me the following hours: midnight, 1 am, 2am
> 
> any would be ok i think.
> 
> ideas please?  i am not going to be able to do anything particularly
> complex, buyt i can script bash.

The at command does exactly what you want. Record a sound file
of your medicine alarm and...

 $ sudo apt install at

 $ at 0240
 warning: commands will be executed using /bin/sh
 at> aplay /home/sam/medicine.wav
 at> ^D
 job 1 at Wed Mar 22 02:40:00 2022

Enter commands to be run at the particular time, and finish with
a control-D (end of file). at will acknowledge with the job
number and the time it will be run.

Feel free to test with 'at now +2m' 

You can use atq to show you the queue of at jobs, and atrm to
remove one.

Now, if the alarm happens more often than that on a regular
basis, you could use cron instead. cron is a little more
complicated, but can handle things like "every Tuesday, on hours
divisible by 4".

-dsr-

simple talking clock / reminder for when monitor is off and it is dark

[Samuel Wales]

i have to have all lights and monitors off at night.  but i have to
know the time so i can take medicine.

i use slock and turn off monitor with ddccontrol.  this might turn off
mouse and keyboard; i wouild have to check.

i want debian to tell me the time at certain times.  for example
tonight i have to take medicine at 2:40 am.

here are ideas:

- tell me time when i right click [kb much less accessible]
- tell me at a prespecified time like 2.40 am
- tell me the following hours: midnight, 1 am, 2am

any would be ok i think.

beeping would be ok too, such as the ship's bell's system or just 1
extra beep added to the time for those 3 times.

ideas please?  i am not going to be able to do anything particularly
complex, buyt i can script bash.

[if aboe not possible this would be off topic but if anybody has off
list a settable alarm or soething with a red light to see the time
[blue or white no good and pwm no good], that would be a lasst resort.
i don't hae a digita watch or cell phon e.]

Re: /etc/adjtime (setting the hardware clock to local time on Debian 11)

[Cindy Sue Causey]

On 2/11/22, Anssi Saari  wrote:
> José Luis González  writes:
>
>> According to
>>
>> https://wiki.debian.org/DateTime
>>
>> There should be an /etc/adjtime file to configure the timezone for the
>> hardware clock. I have no such file in my Debian 11 laptop. May I know
>> if the file was removed and what was it replaced with?
>
> >From what I can tell, it's created by hwclock. If you run hwclock --set
> it should be created. Possibly you can also run
>
> timedatectl set-local-rtc 0
>
> but I don't know if that works if the file doesn't exist.
>
>> I just want to set the hardware clock to local time since this machine
>> is shared with Windows and the clock is actually local time.
>
> You might consider telling Windows to use UTC as well. For example here:
> https://feldspaten.org/2019/11/03/windows-10-clock-in-utc/


I debootstrap** Debian for those times I need a new installation.
These were the instructions I'd been using up until last time (maybe a
year ago):

https://www.debian.org/releases/stretch/amd64/apds03.html.en#idm4468

Basically that says;

=== BEGIN SNIPPET

# editor /etc/adjtime

Populate that with:

0.0 0 0.0
0
UTC

To configure timezone;

# dpkg-reconfigure tzdata

=== END SNIPPET

During debootstrap, the /etc/adjtime file doesn't exist until that
step is run, but it's also a brand new install that hasn't been booted
a first time yet.

That manually created file then works flawlessly for me here, but my
needs are simple. I think the hardware clock is set to UTC, by the
way.

Cindy :)

** N.B. Debootstrap was priceless as a method of installing Linux on
dialup Internet connections.. in case that still helps anyone else.
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: /etc/adjtime (setting the hardware clock to local time on Debian 11)

[Greg Wooledge]

CC'ing back to the list.

On Fri, Feb 11, 2022 at 03:34:35PM +0100, José Luis González wrote:
> Would creating an /etc/adjtime as done by the postinst script be fine?

As far as I know, yes.  Try it and see.  The worst that can happen is
your clock will be wrong, but that's already the case, right?

Re: /etc/adjtime (setting the hardware clock to local time on Debian 11)

[Anssi Saari]

José Luis González  writes:

> According to
>
> https://wiki.debian.org/DateTime
>
> There should be an /etc/adjtime file to configure the timezone for the
> hardware clock. I have no such file in my Debian 11 laptop. May I know
> if the file was removed and what was it replaced with?

>From what I can tell, it's created by hwclock. If you run hwclock --set
it should be created. Possibly you can also run

timedatectl set-local-rtc 0 

but I don't know if that works if the file doesn't exist.

> I just want to set the hardware clock to local time since this machine
> is shared with Windows and the clock is actually local time.

You might consider telling Windows to use UTC as well. For example here:
https://feldspaten.org/2019/11/03/windows-10-clock-in-utc/

Re: /etc/adjtime (setting the hardware clock to local time on Debian 11)

[Greg Wooledge]

On Fri, Feb 11, 2022 at 12:54:01PM +0100, José Luis González wrote:
> According to
> 
> https://wiki.debian.org/DateTime
> 
> There should be an /etc/adjtime file to configure the timezone for the
> hardware clock.

That's... not how I'd describe that file, but I suppose "telling whether
the HW clock is on UTC or not" is indeed one of its features.

> I have no such file in my Debian 11 laptop. May I know
> if the file was removed and what was it replaced with?

unicorn:~$ ls -l /etc/adjtime 
-rw-r--r-- 1 root root 46 Jan 11  2018 /etc/adjtime
unicorn:~$ cat /etc/adjtime 
0.00 1515718148 0.00
1515718148
LOCAL
unicorn:~$ dpkg -S /etc/adjtime
dpkg-query: no path found matching pattern /etc/adjtime
unicorn:~$ grep adjtime /var/lib/dpkg/info/*.postinst
/var/lib/dpkg/info/systemd.postinst:if [ "$UTC" = "no" ] && [ ! -e 
/etc/adjtime ]; then
/var/lib/dpkg/info/systemd.postinst:printf "0.0 0 0.0\n0\nLOCAL\n" > 
/etc/adjtime

Are you running systemd, or some other init system?

/etc/adjtime (setting the hardware clock to local time on Debian 11)

[José Luis González]

According to

https://wiki.debian.org/DateTime

There should be an /etc/adjtime file to configure the timezone for the
hardware clock. I have no such file in my Debian 11 laptop. May I know
if the file was removed and what was it replaced with?

I just want to set the hardware clock to local time since this machine is 
shared with Windows and the clock is actually local time.

Thanks in advance, and best regards.

Re: Bug? Can not set clock in plasma5

[andreimpopescu]

On Mi, 01 mai 19, 11:33:23, Hans wrote:
> Hi folks,
> 
> I am running into the little issue, that I can not set the clock in plasma5 
> (KDE). Neither as a normal user nor as root.
> 
> I want to set the clock using systemd to set the time automatically, but when 
> ever I want set the hook and confirmed the correct password of root, the 
> settting is not saved.
 
Not sure what "hook" you mean, but systemd should automatically set the 
time at boot. What does

systemctl status systemd-timesyncd

say?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug? Can not set clock in plasma5

[Hans]

Hi folks,

I am running into the little issue, that I can not set the clock in plasma5 
(KDE). Neither as a normal user nor as root.

I want to set the clock using systemd to set the time automatically, but when 
ever I want set the hook and confirmed the correct password of root, the 
settting is not saved.

This appears also, when running plasma5 as root, except that it does (of 
course) not ask for the root password.

It looks like a bug for me. 

I believe, that maybe the setting may be also done in the command line with a 
systemd-command, but I am not sure about this.

Before I make noise: Is this already known? Is this normal or should I file a 
bugreport?

Thanks for any hints.

Best regards

Hans

signature.asc
Description: This is a digitally signed message part.

Re: Slow clock on Xen 4.8 after upgrade

[Mike]

On Thu, Jun 07, 2018 at 11:06:12PM +0300, Abdullah Ramazanoğlu wrote:
> On Thu, 7 Jun 2018 19:32:35 +0100 Mike said:
> 
> [--8<--]
> 
> > In the end I used adjtimex -t 10065 -f 3058784 to speed the clock up a
> > bit and that has allowed NTP to be able to keep it under control.
> > 
> > So the issue with the slow clock appears to have been compenstated for
> > but I'd be intersted to know what actually caused it.  I've drawn a bit
> > of a blank on that one and would be grateful if anyone could offer any
> > thoughts?
> 
> Could there be a race condition between hwclock(8) and adjtimex?
> 
> IOW, there is a possibility that perhaps there was a drift rate set by hwclock
> and this was the cause of excessive drift. Now that adjtimex counter balances
> hwclock by an opposite drift rate, it can result in hwclock and adjtimex
> fighting against each other. Just a possibility.
> 
> I would have checked /etc/adjtime to ensure that no drift ratio set by 
> hwclock.
> More info about hwclock drift setting and /etc/adjtime format in hwclock man
> page.
>

Thanks for the reply.

I did do some fiddling in /etc/adjtime (setting the drift ratio to 0 to
see if that resolved the issue, although it was unclear to me from the
docs I read how and when this file gets read (I believe it's hwclock
that reads it but when, other than on boot?)  I did keep  a copy of the
original before I fiddled with it:

3.619663 1452036888 0.00
1452036888
UTC

I believe this means that it hasn't been updated since the begining of
time and that there's a drift of 3s a day between the hardware and
system clocks?  I assume this should not account for the ~15 mins a day
drift I was seeing?

Regards,
Mike. 


signature.asc
Description: PGP signature

Slow clock on Xen 4.8 after upgrade

[Mike]

Folks,

I've been running a Debian Xen server for a while now.  It was upgraded
to Stretch upon its release and has (I think) ran like that since.  It's
been regularly updated but never rebooted until this weekend which saw
it go from a 4.9.0-3 kernel to 4.9.0-6 and what looks from the apt
history like a few upgrades to the Hypervisor.

Long story short, having ran without issue for around 330 days,
following the reboot, I noticed that the time on the Dom0 and DomUs was
drifting.  After investigating, I noticed that the NTP daemon was
rejecting all of its upstream servers as they were failing sanity.
After a restart and resync of the NTP daemon, the same thing was
happening, after about five minutes, all of the servers would fail
sanity and get rejected.

Upon further investigation, I noticed that the system time was drifting
away from the hardware clock at a fairly alarming rate.  It was
something like 15 minutes a day.

I did take a look at
/sys/devices/system/clocksource/clocksource0/current_clocksource which
was listing tsc.  I understand that can be a little flaky with vCPUS
(although had worked for the past 330 days), so I changed it to xen.
This made no difference at all.  Further investigations led me to: xl
dmesg | grep time which revealed: (XEN) Platform timer is 14.318MHz HPET
but again, something which has worked perfectly well for 330 days.

In the end I used adjtimex -t 10065 -f 3058784 to speed the clock up a
bit and that has allowed NTP to be able to keep it under control.

So the issue with the slow clock appears to have been compenstated for
but I'd be intersted to know what actually caused it.  I've drawn a bit
of a blank on that one and would be grateful if anyone could offer any
thoughts?

Mike.


signature.asc
Description: PGP signature

Re: Correct: System Thinks Hardware Clock is UTC

[Felix Miata]

Michael Stone composed on 2018-05-21 10:05 (UTC-0400):

> On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:

>>OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and 
>>UTC
>>isn't fun, especially with one or more that can't not, which is what I have 
>>with
>>a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
>>option. 

> I'm afraid I don't understand how things like old standalone boxes 
> impact what makes sense going forward. You do understand that there's no 
> relationship between the RTC clock and the displayed time? (That is, you 
> can set the RTC to UTC and still interact with the system in local 
> time.)

Typically, I record on a STB that has no support for /etc/adjtime or
/etc/localtime and see via FTP login the new recording's timestamp is tomorrow
until I wait several hours, and then see it was "recorded" hours after the
program guide and my clock said it aired. I live in today, not tomorrow, and
have no interest in clock time outside an hour or two's drive from home.
Different timestamps across the LAN interfere with evaluation which files of
same name are the newer when choosing, copying, backing up or restoring.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Mon, 21 May 2018 09:03:47 -0400 Greg Wooledge <wool...@eeg.ccf.org>
wrote:

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > > Haven't
> > > > installed any other OS on this system since Wheezy 5 years ago.
> 
> Oh, good, then you can simply set the hardware cl--

I did so.  And everything is fixed as far as I can tell. But had to
reboot Stretch install a couple times before it took. Although, I'm
thinking now I should just reinstall. It's still only a Base
Terminal only system so far. I've yet to flesh it out.  So, no great
loss.

> > Unfortunately, I have other OSes on this system and they are
> > configured for the hardware clock set to local time. I need to keep
> > it that way.
> 
> Um... OK.  This sudden reversal is confusing to me, but if you've got
> it dual-booting between Windows and Linux, then setting the HW clock
> to local time may be your simplest option.

Sorry for the confusion.  I guess my initial post wasn't detailed
enough.

> In past versions of Debian, this was done by editing
> the /etc/default/rcS file.  But that's not true in stretch.

I looked into that as well since I converted Stretch init to sysvinit 

> If I'm reading the man pages and the /etc/init.d/* scripts correctly
> (as you said you're using sysv-rc rather than systemd), it looks like
> the setting for HW clock to UTC or local is in the /etc/adjtime file
> now.  There's no separate man page for it.  The documentation for
> /etc/adjtime appears to be in the hwclock(8) man page, under the
> section header "The Adjtime File".

Read that, too.  And tried changing UTC to LOCAL. No effect even after a
reboot.  Later discovered that /etc/adjtime is only accessed when the
hardware clock is reset.  FWIW, if that file doesn't exist, the default
is UTC.

Thanks for your input.

B

Re: Correct: System Thinks Hardware Clock is UTC

[Michael Stone]

On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:

OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
isn't fun, especially with one or more that can't not, which is what I have with
a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
option. 


I'm afraid I don't understand how things like old standalone boxes 
impact what makes sense going forward. You do understand that there's no 
relationship between the RTC clock and the displayed time? (That is, you 
can set the RTC to UTC and still interact with the system in local 
time.)


Mike Stone

Re: Correct: System Thinks Hardware Clock is UTC

[Felix Miata]

Michael Stone composed on 2018-05-21 09:10 (UTC-0400):

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:

>>Unfortunately, I have other OSes on this system and they are configured
>>for the hardware clock set to local time. I need to keep it that way.

> For what it's worth, you'll have less long term pain if you also 
> configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
> decide they need to reset the local time for DST changes...

> It's good that MS did eventually figure this out, and provide a 
> mechanism to specify that the HW clock is UTC.

OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
isn't fun, especially with one or more that can't not, which is what I have with
a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
option. So I keep most on LOCAL, and reboot those that would otherwise be online
as close as I can following each change hour. Those with Windows installed I
configure to not mess with the hardware clock at change times, leaving Linux to
do the deed.

Last fresh installation that got time out of sync with hardware clock was fixed
simply with a change of /etc/adjtime from UTC to LOCAL followed by reboot.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Correct: System Thinks Hardware Clock is UTC

[Michael Stone]

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:

Unfortunately, I have other OSes on this system and they are configured
for the hardware clock set to local time. I need to keep it that way.


For what it's worth, you'll have less long term pain if you also 
configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
decide they need to reset the local time for DST changes...


It's good that MS did eventually figure this out, and provide a 
mechanism to specify that the HW clock is UTC.


Mike Stone

Re: Correct: System Thinks Hardware Clock is UTC

[Greg Wooledge]

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > Haven't
> > > installed any other OS on this system since Wheezy 5 years ago.

Oh, good, then you can simply set the hardware cl--

> Unfortunately, I have other OSes on this system and they are configured
> for the hardware clock set to local time. I need to keep it that way.

Um... OK.  This sudden reversal is confusing to me, but if you've got
it dual-booting between Windows and Linux, then setting the HW clock to
local time may be your simplest option.

In past versions of Debian, this was done by editing the /etc/default/rcS
file.  But that's not true in stretch.

If I'm reading the man pages and the /etc/init.d/* scripts correctly
(as you said you're using sysv-rc rather than systemd), it looks like
the setting for HW clock to UTC or local is in the /etc/adjtime file
now.  There's no separate man page for it.  The documentation for
/etc/adjtime appears to be in the hwclock(8) man page, under the section
header "The Adjtime File".

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Sun, 20 May 2018 22:42:24 +0300 Abdullah Ramazanoğlu
<ar...@yahoo.com> wrote:

> On Sun, 20 May 2018 12:10:01 -0700 Patrick Bartek said:
> 
> > On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
> > <ar...@yahoo.com> wrote:
> > 
> > > On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> > >   
> > > > I could use hwclock --set --date= with the
> > > > --localtime option, etc., to correct this but is there an
> > > > easier way?  
> > > 
> > > # dpkg-reconfigure tzdata
> > > 
> > > should do it, I think.  
> > 
> > tzdata sets the local time zone. Mine is correctly set  The
> > problem is the system "thinks" the hardware clock is set to UTC when
> > It's really set to local time. So, the time shown for my local time
> > zone is incorrect.
> > 
> > Anyway, thanks for your suggestion.
> 
> You are welcome. :)
> 
> So, your original idea of using "hwclock --set --date --localtime"
> seems to be the best way.

Simpliest fix.

> Alternatively, you might try replaying the question-answer sequence
> regarding RTC at install time.

Considered this, but just using hwclock was easier.

> ~$ dpkg -S /sbin/hwclock
> util-linux: /sbin/hwclock
> 
> Perhaps "dpkg-reconfigure util-linux" might cause the same
> install-time question be asked again (presumably along with other
> questions).

Thanks

B

Re: Correct: System Thinks Hardware Clock is UTC

[Steve McIntyre]

Patrick Bartek wrote:
>On Fri, 18 May 2018 20:59:25 -0500 David Wright
><deb...@lionunicorn.co.uk> wrote:
>
>> On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
>> > Okay, it's my fault: I admit it. During the Base Only, Terminal-only
>> > install of Stretch, I clicked UTC instead of Local for the hardware
>> > clock time. Honestly, I thought the clock was set to UTC. Haven't
>> > installed any other OS on this system since Wheezy 5 years ago. So,
>> > now system time on Stretch is 7 hours earlier than it should be --
>> > difference between my time zone and Greenwich.
>> 
>> You could reboot and set the hardware clock in the CMOS/BIOS
>> to UTC time (coming up to 02:00 Saturday as I send this).
>
>Unfortunately, I have other OSes on this system and they are configured
>for the hardware clock set to local time. I need to keep it that way.
>
>Thanks, anyway.

The code in the Debian installer that deals with this [1] is:

---
# Update target system configuration for utc/localtime selection
utcfile=/target/etc/default/rcS

db_get clock-setup/utc
if [ "$RET" = true ]; then
if [ -e $utcfile ]; then
sed -i -e 's:^UTC="no":UTC="yes":' -e 's:^UTC=no:UTC=yes:' 
$utcfile
fi
if [ -e /target/etc/adjtime ]; then
sed -i -e 's:^LOCAL$:UTC:' /target/etc/adjtime
fi
OPT="--utc"
else
if [ -e $utcfile ]; then
sed -i -e 's:^UTC="yes":UTC="no":' -e 's:^UTC=yes:UTC=no:' 
$utcfile
fi
if [ -e /target/etc/adjtime ]; then
sed -i -e 's:^UTC$:LOCAL:' /target/etc/adjtime
fi
OPT="--localtime"
fi
---

If you're using systemd, then /etc/default/rcS is not likely to do
much. However, you may want to check in /etc/adjtime. My machine has
the following:

0.00 1521991744 0.00
1521991744
UTC

If yours is saying "UTC" there, then try "LOCAL" instead.

HTH!

[1] 
https://salsa.debian.org/installer-team/clock-setup/blob/master/finish-install.d/10clock-setup#L118

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: Correct: System Thinks Hardware Clock is UTC

[Abdullah Ramazanoğlu]

On Sun, 20 May 2018 12:10:01 -0700 Patrick Bartek said:

> On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
> <ar...@yahoo.com> wrote:
> 
> > On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> >   
> > > I could use hwclock --set --date= with the --localtime
> > > option, etc., to correct this but is there an easier way?  
> > 
> > # dpkg-reconfigure tzdata
> > 
> > should do it, I think.  
> 
> tzdata sets the local time zone. Mine is correctly set  The
> problem is the system "thinks" the hardware clock is set to UTC when
> It's really set to local time. So, the time shown for my local time
> zone is incorrect.
> 
> Anyway, thanks for your suggestion.

You are welcome. :)

So, your original idea of using "hwclock --set --date --localtime" seems to be
the best way.

Alternatively, you might try replaying the question-answer sequence regarding
RTC at install time.

~$ dpkg -S /sbin/hwclock
util-linux: /sbin/hwclock

Perhaps "dpkg-reconfigure util-linux" might cause the same install-time
question be asked again (presumably along with other questions).

Regards
-- 
Abdullah Ramazanoğlu

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Sat, 19 May 2018 10:37:39 +1000 Ben Finney <bign...@debian.org>
wrote:

> Patrick Bartek <nemomm...@gmail.com> writes:
> 
> > I could use hwclock --set --date= with the --localtime
> > option, etc., to correct this but is there an easier way?
> 
> There is only one clock involved in this: the hardware clock.
> 
> By telling the operating system that your hardware clock is set to
> UTC, you have told the operating system how to *render* the hardware
> clock's time for your local time zone.
> 
> Setting the clock will set the hardware clock. By using a “set the
> clock” tool, you will set the hardware clock — but the clock-setting
> tool will take care of converting the time zone correctly.
>
> I think the generally-applicable advice is correct: tell the OS that
> your clock is set to UTC, and leave it to the operating system to
> figure out the weirdness of time zones.

Actually, the hardware clock has always been set to local time.  Had
to: Used to have Windows XP installed (this box is 11+ years old) as a
multi-boot with Linux, and as you know Windows needs the hardware
clock set to local to work correctly.  I've just keep it that way. .  

> So I think you've done the right thing: tell the OS to keep the
> hardware clock at UTC. Now you just need to tell it what the time
> is :-)

Actually, it's the other way around. hardware clock is local time, but
Stretch thinks it's UTC. (I have Wheezy on here to, but it's configured
correctly.)

Just going to use hwclock and the --localtime option to reset it.
Haven't been able to find any other way to do so.

> Assuming your machine is internet-connected, tell the operating system
> to keep your hardware clock in sync with the Network Time Protocol, by
> installing an NTP server. I can't recall what the default is; I use
> the ‘chrony’ package.

I alway install ntp, but I want everything timewise configured
appropriately before I do so.

Thanks for you advice.

B

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Fri, 18 May 2018 20:59:25 -0500 David Wright
<deb...@lionunicorn.co.uk> wrote:

> On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
> > Okay, it's my fault: I admit it. During the Base Only, Terminal-only
> > install of Stretch, I clicked UTC instead of Local for the hardware
> > clock time. Honestly, I thought the clock was set to UTC. Haven't
> > installed any other OS on this system since Wheezy 5 years ago. So,
> > now system time on Stretch is 7 hours earlier than it should be --
> > difference between my time zone and Greenwich.
> 
> You could reboot and set the hardware clock in the CMOS/BIOS
> to UTC time (coming up to 02:00 Saturday as I send this).

Unfortunately, I have other OSes on this system and they are configured
for the hardware clock set to local time. I need to keep it that way.

Thanks, anyway.

B

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
<ar...@yahoo.com> wrote:

> On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> 
> > I could use hwclock --set --date= with the --localtime
> > option, etc., to correct this but is there an easier way?
> 
> # dpkg-reconfigure tzdata
> 
> should do it, I think.

tzdata sets the local time zone. Mine is correctly set  The
problem is the system "thinks" the hardware clock is set to UTC when
It's really set to local time. So, the time shown for my local time
zone is incorrect.

Anyway, thanks for your suggestion.

B

Re: Correct: System Thinks Hardware Clock is UTC

[David Wright]

On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
> Okay, it's my fault: I admit it. During the Base Only, Terminal-only
> install of Stretch, I clicked UTC instead of Local for the hardware
> clock time. Honestly, I thought the clock was set to UTC. Haven't
> installed any other OS on this system since Wheezy 5 years ago. So, now
> system time on Stretch is 7 hours earlier than it should be --
> difference between my time zone and Greenwich.

You could reboot and set the hardware clock in the CMOS/BIOS
to UTC time (coming up to 02:00 Saturday as I send this).

Cheers,
David.

Re: Correct: System Thinks Hardware Clock is UTC

[Ben Finney]

Patrick Bartek <nemomm...@gmail.com> writes:

> I could use hwclock --set --date= with the --localtime
> option, etc., to correct this but is there an easier way?

There is only one clock involved in this: the hardware clock.

By telling the operating system that your hardware clock is set to UTC,
you have told the operating system how to *render* the hardware clock's
time for your local time zone.

Setting the clock will set the hardware clock. By using a “set the
clock” tool, you will set the hardware clock — but the clock-setting
tool will take care of converting the time zone correctly.

I think the generally-applicable advice is correct: tell the OS that
your clock is set to UTC, and leave it to the operating system to figure
out the weirdness of time zones.

So I think you've done the right thing: tell the OS to keep the hardware
clock at UTC. Now you just need to tell it what the time is :-)

Assuming your machine is internet-connected, tell the operating system
to keep your hardware clock in sync with the Network Time Protocol, by
installing an NTP server. I can't recall what the default is; I use the
‘chrony’ package.

-- 
 \   “If you do not trust the source do not use this program.” |
  `\—Microsoft Vista security dialogue |
_o__)  |
Ben Finney

Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

Okay, it's my fault: I admit it. During the Base Only, Terminal-only
install of Stretch, I clicked UTC instead of Local for the hardware
clock time. Honestly, I thought the clock was set to UTC. Haven't
installed any other OS on this system since Wheezy 5 years ago. So, now
system time on Stretch is 7 hours earlier than it should be --
difference between my time zone and Greenwich.

I could use hwclock --set --date= with the --localtime
option, etc., to correct this but is there an easier way?

NOTE: I've already replace systemd as the init with sysvinit.  So, I
don't think systemd commands are appropriate. I've not installed ntp as
yet either.

Thanks

B

Re: Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

On 08/11/17 04:57, John Ratliff wrote:



On Wed, Aug 09, 2017 at 05:13:55PM -0700, David Christensen wrote:

 Time Settings
   Timezone PST8PDT
 Appearance
   Layout   Digital
   Tooltip format   Wednesday 09 August 2017
 Clock Options
   Format   05:04:55 PM

Once I have made the above settings, but before choosing "Close", the
current time is displayed at the proper location in the Xfce panel. This
is
what I want.

- But when I click "Close", the current time disappears from the panel
--
e.g. Clock breaks.


Does the space for the clock disappear, or go blank?

If it's going blank, I suggest you look at color settings for
the clock -- you may have accidentally selected 100% transparent
text, or the same color as the background.

-dsr-




This is a known bug in the clock applet for Xfce. Last I checked the bug
tracker upstream, it hadn't been fixed. I have the same issue. You can't
adjust the clock settings without it erasing your format string and making
the clock blank. 


https://bugzilla.xfce.org/show_bug.cgi?id=11527



My workaround is to use the orange date/time panel item
instead.


I thought about that -- might as well until the Xfce clock gets fixed.


David

Re: Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

On 08/10/17 06:52, Charlie Kravetz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 9 Aug 2017 22:48:37 -0700
David Christensen <dpchr...@holgerdanske.com> wrote:


On 08/09/17 21:47, Charlie Kravetz wrote:


It almost sounds like the panel is too long for the monitor. The clock
is disappearing off the end of the panel. Is the clock the last thing
in panel? Try moving it to the other of the panel, and see if it still
disappears.


Clock is neither the first nor last item in the panel.


Clock works fine on Xfce on Debian Wheezy, Debian Jesse, FreeBSD 11.0,
and possibly others.


I'm looking for an error message from Xfce panel, or a way to obtain
error/ debug messages.


David



The only way I know to do that, if nothing shows up in
~/.xsession-errors, 



2017-08-11 21:46:11 dpchrist@tinkywinky ~
$ grep -i clock .xsession-errors

2017-08-11 21:46:15 dpchrist@tinkywinky ~
$ grep -i panel .xsession-errors

2017-08-11 21:46:23 dpchrist@tinkywinky ~
$ grep -i xfce .xsession-errors
dbus-update-activation-environment: setting 
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/

xfce4-session-Message: SSH authentication agent is already running
(xfce4-session:5464): xfce4-session-WARNING **: gpg-agent returned no 
PID in the variables
(xfce4-terminal:5560): Gtk-WARNING **: Allocating size to GtkScrollbar 
0x55b9781683d0 without calling gtk_widget_get_preferred_width/height(). 
How does the code know the size to allocate?
(xfce4-terminal:5560): Gtk-WARNING **: Allocating size to GtkScrollbar 
0x55b9781687d0 without calling gtk_widget_get_preferred_width/height(). 
How does the code know the size to allocate?




is to run debug.

https://docs.xfce.org/xfce/xfce4-panel/debugging



Maybe later.


David

Re: Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

On 08/10/17 11:51, Ralph Katz wrote:


On 08/09/2017 06:13 PM, David Christensen wrote:

debian-user:

I have a Dell Inspiron E1505 laptop with an Intel Core Duo T7400
CPU, 2 GB RAM, 16 GB SSD, and a fresh install of
debian-9.1.0-amd64-xfce-CD-1.iso, with all updates and upgrades as
of now:

2017-08-09 16:59:07 root@tinkywinky ~ # cat /etc/debian_version
9.1

2017-08-09 16:59:18 root@tinkywinky ~ # uname -a Linux tinkywinky
4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64
GNU/Linux

2017-08-09 16:59:22 root@tinkywinky ~ # dpkg-query --show xfce4
xfce44.12.3


I would like to use the Xfce panel "clock" item.  Unfortunately, it
is broken:

- If I right-click on the Xfce panel and choose "Panel
Preferences...", the "Panel" dialog appears.

- Selecting Panel -> Items tab, "Clock" appears in the list of
panel items.

- If I select Panel -> Items -> Clock and click the "Edit the
currently selected item" button, the "Clock" dialog appears.

- I then configure Clock as follows:

Time Settings TimezonePST8PDT Appearance Layout
Digital Tooltip formatWednesday 09 August 2017 Clock Options
Format05:04:55 PM

Once I have made the above settings, but before choosing "Close",
the current time is displayed at the proper location in the Xfce
panel. This is what I want.

- But when I click "Close", the current time disappears from the
panel -- e.g. Clock breaks.


Mine works, but settings look different.  I made no changes to clock
properties, 


When I open Panel Preferences -> Items -> Clock -> Edit the currently 
selected item, the defaults are:


  Time Settings
Timezone    
  Appearance
Layout  Digital
Tooltip format  Custom Format
  Clock Options
Format  Custom Format



yet my field Timezone is blank.  Maybe try that?


Failure is the same.



There is an .xfce4-session.verbose-log , though I don't know what
you'll find.


Nothing:

2017-08-11 21:43:27 dpchrist@tinkywinky ~
$ find . -name .xfce4-session.verbose-log
./.xfce4-session.verbose-log

2017-08-11 21:43:34 dpchrist@tinkywinky ~
$ grep -i clock .xfce4-session.verbose-log



David

Re: Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

On 08/11/17 03:39, Dan Ritter wrote:

On Wed, Aug 09, 2017 at 05:13:55PM -0700, David Christensen wrote:

 Time Settings
   Timezone PST8PDT
 Appearance
   Layout   Digital
   Tooltip format   Wednesday 09 August 2017
 Clock Options
   Format   05:04:55 PM

Once I have made the above settings, but before choosing "Close", the
current time is displayed at the proper location in the Xfce panel. This is
what I want.

- But when I click "Close", the current time disappears from the panel --
e.g. Clock breaks.


Does the space for the clock disappear, or go blank?


The clock disappears (all the other items on the panel rearrange to fill 
the void).



David

Re: Debian 9.1 amd64 Xfce panel clock broken

[John Ratliff]

> On Wed, Aug 09, 2017 at 05:13:55PM -0700, David Christensen wrote:
>> Time Settings
>>   Timezone   PST8PDT
>> Appearance
>>   Layout Digital
>>   Tooltip format Wednesday 09 August 2017
>> Clock Options
>>   Format 05:04:55 PM
>>
>> Once I have made the above settings, but before choosing "Close", the
>> current time is displayed at the proper location in the Xfce panel. This
>> is
>> what I want.
>>
>> - But when I click "Close", the current time disappears from the panel
>> --
>> e.g. Clock breaks.
>
> Does the space for the clock disappear, or go blank?
>
> If it's going blank, I suggest you look at color settings for
> the clock -- you may have accidentally selected 100% transparent
> text, or the same color as the background.
>
> -dsr-
>
>

This is a known bug in the clock applet for Xfce. Last I checked the bug
tracker upstream, it hadn't been fixed. I have the same issue. You can't
adjust the clock settings without it erasing your format string and making
the clock blank. My workaround is to use the orange date/time panel item
instead.

--John

Re: Debian 9.1 amd64 Xfce panel clock broken

[Dan Ritter]

On Wed, Aug 09, 2017 at 05:13:55PM -0700, David Christensen wrote:
> Time Settings
>   TimezonePST8PDT
> Appearance
>   Layout  Digital
>   Tooltip format  Wednesday 09 August 2017
> Clock Options
>   Format  05:04:55 PM
> 
> Once I have made the above settings, but before choosing "Close", the
> current time is displayed at the proper location in the Xfce panel. This is
> what I want.
> 
> - But when I click "Close", the current time disappears from the panel --
> e.g. Clock breaks.

Does the space for the clock disappear, or go blank?

If it's going blank, I suggest you look at color settings for
the clock -- you may have accidentally selected 100% transparent
text, or the same color as the background.

-dsr-

Re: Debian 9.1 amd64 Xfce panel clock broken

[Ralph Katz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/09/2017 06:13 PM, David Christensen wrote:
> debian-user:
> 
> I have a Dell Inspiron E1505 laptop with an Intel Core Duo T7400
> CPU, 2 GB RAM, 16 GB SSD, and a fresh install of 
> debian-9.1.0-amd64-xfce-CD-1.iso, with all updates and upgrades as
> of now:
> 
> 2017-08-09 16:59:07 root@tinkywinky ~ # cat /etc/debian_version 
> 9.1
> 
> 2017-08-09 16:59:18 root@tinkywinky ~ # uname -a Linux tinkywinky
> 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64
> GNU/Linux
> 
> 2017-08-09 16:59:22 root@tinkywinky ~ # dpkg-query --show xfce4 
> xfce44.12.3
> 
> 
> I would like to use the Xfce panel "clock" item.  Unfortunately, it
> is broken:
> 
> - If I right-click on the Xfce panel and choose "Panel
> Preferences...", the "Panel" dialog appears.
> 
> - Selecting Panel -> Items tab, "Clock" appears in the list of
> panel items.
> 
> - If I select Panel -> Items -> Clock and click the "Edit the
> currently selected item" button, the "Clock" dialog appears.
> 
> - I then configure Clock as follows:
> 
> Time Settings TimezonePST8PDT Appearance Layout
> Digital Tooltip formatWednesday 09 August 2017 Clock Options 
> Format05:04:55 PM
> 
> Once I have made the above settings, but before choosing "Close",
> the current time is displayed at the proper location in the Xfce
> panel. This is what I want.
> 
> - But when I click "Close", the current time disappears from the
> panel -- e.g. Clock breaks.
> 
> 
> Looking in /var/log and dmesg, I don't see any clues.
> 
> 
> Any suggestions for figuring out why Clock is broken and how to fix
> it?
> 
> 
> David

Mine works, but settings look different.  I made no changes to clock
properties, yet my field Timezone is blank.  Maybe try that?

There is an .xfce4-session.verbose-log , though I don't know what
you'll find.

Good luck!

Ralph


-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIyBAEBCgAdFiEEJQZ8vK6BnmDiW8fZyAJ5DhtfJxAFAlmMqysACgkQyAJ5Dhtf
JxBh8w/2JtkmMRJCoEYqXZ5vQiNiPKKJyShhFXIoRpb2h7Ieih5Uk5Q0nlKnYSo5
7Ym21L98yAZVTq9+cFpfjWHwQhtDqrNdxwZj88IhPnXghO42GZ6gjxeYBbe9NjR8
ZR/hl9Hih8C71tFVg2qwkqJcyHxL6c96yk8lqwv2ts1QpavUr0oo3Nf94okSqc4T
SXPVn+fRv/MowjeZmFave9MFrXALoG/hfj3rRdfwSgSGAj0HegciHFd/1moeQbdd
f/Ay4+YS7BiLF6Jk5KRIxawJvAnEoasoVlhw37xkl6nsWw5wCi/HXLukXLqI1des
LDvTKnrkY8sqBl9EVvxLpGRgehEhTtnwJrlt6WrarhBF7JlWcEZ9Npc0yAOzOs1G
c4GWko8iGTk/yu4Ug03Urdu068/lM3nRqrpPdQyWrTkwag2yhehixWvq48YTFp81
O7dpdVR9ygl8lQGQdbqgtpK9IBTvqaia6+GqA0A1JXcadZk3v5nqazQvzZ9YW7dl
jgzRDZIGM3p22adxPqRTF17/v+izisJdfuVqrcSAPsf/6uE4lhkow+TXcZa04ALd
i7AoK+uF9Z3Sn/lzUcsXyE7CMobUXacHc9F6MnNy2IPSW6RtW7u1QTBUbBJOXLd7
pKsrWFIyYGkzlUyLmaGFsgiUtXY1aChNebyUcdK9usdr5RSSzw==
=JIy6
-END PGP SIGNATURE-

Re: Debian 9.1 amd64 Xfce panel clock broken

[Charlie Kravetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 9 Aug 2017 22:48:37 -0700
David Christensen <dpchr...@holgerdanske.com> wrote:

>On 08/09/17 21:47, Charlie Kravetz wrote:
>> 
>> It almost sounds like the panel is too long for the monitor. The clock
>> is disappearing off the end of the panel. Is the clock the last thing
>> in panel? Try moving it to the other of the panel, and see if it still
>> disappears.  
>
>Clock is neither the first nor last item in the panel.
>
>
>Clock works fine on Xfce on Debian Wheezy, Debian Jesse, FreeBSD 11.0, 
>and possibly others.
>
>
>I'm looking for an error message from Xfce panel, or a way to obtain 
>error/ debug messages.
>
>
>David
>

The only way I know to do that, if nothing shows up in
~/.xsession-errors, is to run debug.

https://docs.xfce.org/xfce/xfce4-panel/debugging


- -- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEG5QK93YKrQMH22ZTiq6LjqbJ0IAFAlmMZQEACgkQiq6LjqbJ
0IAEHwf9Fmts6Pu8dGu+8Hk1uBeDK8TCb08Imf0ZadNEXzMPTDv61Bj22+QL7fQl
qndLXFTctZ2n610ZVEzUhZT5Ss3c5m/nauGrBY+ymhpOs7VG8AO76bOgohsx7ptB
dt0VLZ8EzBCP5s3rvLIZdgfNNJSoz/L3IGm/mJXPjai3sXtAkSh3bvldMQsYpHPv
09pEISqz/EzlQhYMZo6HdOrRloQ+692pHvMoNLgMaCB22vAZZ/AD426ODrwbIZWx
YC18ukMcPazk4LiHhcv2PPvAi1qumz/f/xEfw/g53Br+M6K4kSOnndqZ8Klfc7Hh
nDE68LObxRPbgQ0ZwA1QL4uE8a5PkQ==
=SLQ/
-END PGP SIGNATURE-

Re: Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

On 08/09/17 21:47, Charlie Kravetz wrote:


It almost sounds like the panel is too long for the monitor. The clock
is disappearing off the end of the panel. Is the clock the last thing
in panel? Try moving it to the other of the panel, and see if it still
disappears.


Clock is neither the first nor last item in the panel.


Clock works fine on Xfce on Debian Wheezy, Debian Jesse, FreeBSD 11.0, 
and possibly others.



I'm looking for an error message from Xfce panel, or a way to obtain 
error/ debug messages.



David

Re: Debian 9.1 amd64 Xfce panel clock broken

[Charlie Kravetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 9 Aug 2017 17:13:55 -0700
David Christensen <dpchr...@holgerdanske.com> wrote:

>debian-user:
>
>I have a Dell Inspiron E1505 laptop with an Intel Core Duo T7400 CPU, 2 
>GB RAM, 16 GB SSD, and a fresh install of 
>debian-9.1.0-amd64-xfce-CD-1.iso, with all updates and upgrades as of now:
>
>2017-08-09 16:59:07 root@tinkywinky ~
># cat /etc/debian_version
>9.1
>
>2017-08-09 16:59:18 root@tinkywinky ~
># uname -a
>Linux tinkywinky 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 
>(2017-08-06) x86_64 GNU/Linux
>
>2017-08-09 16:59:22 root@tinkywinky ~
># dpkg-query --show xfce4
>xfce4  4.12.3
>
>
>I would like to use the Xfce panel "clock" item.  Unfortunately, it is 
>broken:
>
>- If I right-click on the Xfce panel and choose "Panel Preferences...", 
>the "Panel" dialog appears.
>
>- Selecting Panel -> Items tab, "Clock" appears in the list of panel items.
>
>- If I select Panel -> Items -> Clock and click the "Edit the currently 
>selected item" button, the "Clock" dialog appears.
>
>- I then configure Clock as follows:
>
> Time Settings
>   TimezonePST8PDT
> Appearance
>   Layout  Digital
>   Tooltip format  Wednesday 09 August 2017
> Clock Options
>   Format  05:04:55 PM
>
>Once I have made the above settings, but before choosing "Close", the 
>current time is displayed at the proper location in the Xfce panel. 
>This is what I want.
>
>- But when I click "Close", the current time disappears from the panel 
>-- e.g. Clock breaks.
>
>
>Looking in /var/log and dmesg, I don't see any clues.
>
>
>Any suggestions for figuring out why Clock is broken and how to fix it?
>
>
>David
>

It almost sounds like the panel is too long for the monitor. The clock
is disappearing off the end of the panel. Is the clock the last thing
in panel? Try moving it to the other of the panel, and see if it still
disappears.

- -- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEG5QK93YKrQMH22ZTiq6LjqbJ0IAFAlmL5WUACgkQiq6LjqbJ
0IDebAf/UDM+FUUFMDHiu9qkqaIq7fMSNr/KghoKRHcM62V3AmAa0Pad0UeNz9/d
h7in3Y5hJ87tybWufZn6YkU6+so4d7Nyz7VxIA16ELAHFPzvlmVLAGMkMEVKG0y2
3cl/ynWx3wjaA5TXn3nQRdVbcIo03ftcO7E9lFOB8auToAJex7CxBoGaH3Ikjnrn
TsoRHWSJLR1x00vX958gFcyIpd39dQGmQ9HvijqtlBO4m/17DWmIiotGhjHhuMpm
TL5vCsoZVx7k5IOZZGjxBzIz6AR+GgtUuPYgc6780LPme2cNwB/k7xYk2q8oBpkG
v05M+WlNytS5pSY7hv+ZeXAVJVnqjg==
=BpKy
-END PGP SIGNATURE-

Debian 9.1 amd64 Xfce panel clock broken

[David Christensen]

debian-user:

I have a Dell Inspiron E1505 laptop with an Intel Core Duo T7400 CPU, 2 
GB RAM, 16 GB SSD, and a fresh install of 
debian-9.1.0-amd64-xfce-CD-1.iso, with all updates and upgrades as of now:


2017-08-09 16:59:07 root@tinkywinky ~
# cat /etc/debian_version
9.1

2017-08-09 16:59:18 root@tinkywinky ~
# uname -a
Linux tinkywinky 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 
(2017-08-06) x86_64 GNU/Linux


2017-08-09 16:59:22 root@tinkywinky ~
# dpkg-query --show xfce4
xfce4   4.12.3


I would like to use the Xfce panel "clock" item.  Unfortunately, it is 
broken:


- If I right-click on the Xfce panel and choose "Panel Preferences...", 
the "Panel" dialog appears.


- Selecting Panel -> Items tab, "Clock" appears in the list of panel items.

- If I select Panel -> Items -> Clock and click the "Edit the currently 
selected item" button, the "Clock" dialog appears.


- I then configure Clock as follows:

Time Settings
  Timezone  PST8PDT
Appearance
  Layout    Digital
  Tooltip formatWednesday 09 August 2017
Clock Options
  Format05:04:55 PM

Once I have made the above settings, but before choosing "Close", the 
current time is displayed at the proper location in the Xfce panel. 
This is what I want.


- But when I click "Close", the current time disappears from the panel 
-- e.g. Clock breaks.



Looking in /var/log and dmesg, I don't see any clues.


Any suggestions for figuring out why Clock is broken and how to fix it?


David

debian stretch preseed tasksel and clock-setup not working

[Mimiko]

Hello.

I use in preseed.cfg the following:

tasksel tasksel/first multiselect standard
tasksel tasksel/first seen false
d-i clock-setup/utc boolean false
d-i clock-setup/utc seen false

I set seen as false to view the value that was selected. Nor tasksel, nor clock-setup/utc does not set I specify. Inseed tasksel/first have default 
selections and clock-setup/utc is set to true.


debconf-get tasksel/first - gives me standard
debconf-get clock-setup/utc - gives false

So seems debconf ignores this two parameters. How to specify needed?

Re: Clock

[Johann Klammer]

On 06/14/2016 06:40 AM, Richard Barmann wrote:
> About once a week when I boot up I find the clock is exactly 4 hours slow. I 
> am using Kubuntu 16.04. If I am asking the question in the wrong place please 
> send me to the correct forum.
> Thank you.
Try changing /etc/adjtime to have LOCAL at the third line(instead of UTC). 
also 
man hwclock

Re: Clock

[Lisi Reisz]

On Tuesday 14 June 2016 07:20:28 Jörg-Volker Peetz wrote:
> Richard Barmann wrote on 06/14/16 05:36:
> > About once a week when I boot up I find the clock is exactly 4 hours
> > slow. I am using Kubuntu 16.04. If I am asking the question in the wrong
> > place please send me to the correct forum.
> > Thank you.
>
> The four hours seem to be related to your time zone.
> Is this a multi-boot system?
> Did you boot another OS before the clock shift?

Richard is located at GMT -4.  (KMail-Trinity gives me that information!!)  He 
probably boots Another OS, which resets the hardware clock to local time.  So 
Kubuntu sees hardware clock equals  e.g. 10:00, Hardware clock must be in 
UTC, I am at UTC -4, sets local clock to 6:00, clock is four hours slow.

One can set Kubuntu to know that the hardware clock is in local time, but I 
don't know how.

Lisi

Re: Clock

[Cindy-Sue Causey]

On 6/14/16, Jörg-Volker Peetz <jvpe...@web.de> wrote:
> Richard Barmann wrote on 06/14/16 05:36:
>> About once a week when I boot up I find the clock is exactly 4 hours slow.
>> I am
>> using Kubuntu 16.04. If I am asking the question in the wrong place please
>> send
>> me to the correct forum.
>> Thank you.
>>
>
> The four hours seem to be related to your time zone.
> Is this a multi-boot system?
> Did you boot another OS before the clock shift?


I was thinking the same thing, too. I ran into something similar
occasionally (FREQUENTLY) until somewhere I stumbled upon a/the tip
about I THINK it was setting the clock via BIOS as universal time
(UTC). You then set the [operating system] clock per installed
package's features based on one's personal needs.

As soon as I did that on my own system, I never ran into the problem
again. I just tried a similar search to verify before sending this
out, and that *is* what I'm seeing reflected back as one
"recommendation" without even going to any of the websites returned in
the search. It's that [operating systems] expect to find time set as
UTC in our BIOS, and the problem comes up when it's set to our local
times.

And it *was* the same situation for me as I think more on it as I
write this up. The clock was inconsistently sometimes correct,
sometimes wrong with no predictable pattern until I made that BIOS
adjustment .

Just thinking out loud... again :)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with plastic sporks *

Re: Clock

[Jörg-Volker Peetz]

Richard Barmann wrote on 06/14/16 05:36:
> About once a week when I boot up I find the clock is exactly 4 hours slow. I 
> am
> using Kubuntu 16.04. If I am asking the question in the wrong place please 
> send
> me to the correct forum.
> Thank you.
> 

The four hours seem to be related to your time zone.
Is this a multi-boot system?
Did you boot another OS before the clock shift?

Regards,
jvp.

Re: Clock

[Felix Miata]

Richard Barmann composed on 2016-06-13 23:36 (UTC-0400):


About once a week when I boot up I find the clock is exactly 4 hours
slow. I am using Kubuntu 16.04. If I am asking the question in the wrong
place please send me to the correct forum.


Kubuntu is not Debian, but is heavily Debian based, so it may be a matter of 
opinion whether this is "a" right place or not. There is a mailing list made 
specifically for Kubuntu users: kubuntu-us...@lists.ubuntu.com


The 4 hour difference looks possibly to be an inconsistent loading of the 
content of /etc/adjtime during the boot process. When did you do your 16.04 
installation? If it was recently, maybe the problem would clear up just by 
doing ordinary updates, or a rebuilding of /boot/initrd.img-4.4*? Have you 
searched on https://bugs.launchpad.net/ubuntu to see if there is a bug 
addressing your problem? Another place to look is: 
http://askubuntu.com/questions/

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Clock

[Francesco Ariis]

On Mon, Jun 13, 2016 at 11:36:59PM -0400, Richard Barmann wrote:
> About once a week when I boot up I find the clock is exactly 4 hours slow. I
> am using Kubuntu 16.04. If I am asking the question in the wrong place
> please send me to the correct forum.
> Thank you.

Kubuntu has its own community, they could probably help you better
than we could

http://kubuntu.org/community

Clock

[Richard Barmann]

About once a week when I boot up I find the clock is exactly 4 hours 
slow. I am using Kubuntu 16.04. If I am asking the question in the wrong 
place please send me to the correct forum.

Thank you.

Re: Gnome top bar clock

[Stephen Allen]

On Mon, May 30, 2016 at 07:07:03AM +, Curt wrote:
> On 2016-05-29, Stephen Allen <marathon.duran...@gmail.com> wrote:
> > On Fri, May 27, 2016 at 03:16:50PM +0200, Hársfalvi Gábor wrote:
> >> Hi!
> >> 
> >> Is there any way to move the clock on the bar top on the screen? For 
> >> example
> >> from center to left side.
> >> 
> >> Thanks.
> >
> > If you look on extensions.gnome.org you might find an extension to do
> > this. I'm not sure. The Gnome UI is mostly CSS and javascript FWIU
> > however I have no idea of which property to alter. Gnome has an email
> > list might find some pointers there, if no extension can be found.
> >
> >
> 
> https://extensions.gnome.org/extension/2/move-clock/
> 
> seems to fit the bill (though I believe Sven already mentioned this).

Yes he did, unfortunately didn't read his reply prior to responding.

Re: Gnome top bar clock

[Lisi Reisz]

On Friday 27 May 2016 14:24:31 Lisi Reisz wrote:
> On Friday 27 May 2016 14:16:50 Hársfalvi Gábor wrote:
> > Hi!
> >
> > Is there any way to move the clock on the bar top on the screen? For
> > example from center to left side.
>
> What desktop??  Or is it a window manager?  I seem to remember that you are
> running Gnome3 on Jessie, but you really need to say so when you ask this
> type of question.
>
> In TDE 3.5.13.2 on Wheezy, and TDE 14.0.4 on Jessie, you click just to the
> left of the clock applet to bring up a small window which offers, among
> other things, to move the clock.  You choose "move the clock" and move it.
>
> Lisi

MEA CULPA. "Re: Gnome top bar clock"

Lisi

Re: Gnome top bar clock

[Curt]

On 2016-05-29, Stephen Allen <marathon.duran...@gmail.com> wrote:
> On Fri, May 27, 2016 at 03:16:50PM +0200, Hársfalvi Gábor wrote:
>> Hi!
>> 
>> Is there any way to move the clock on the bar top on the screen? For example
>> from center to left side.
>> 
>> Thanks.
>
> If you look on extensions.gnome.org you might find an extension to do
> this. I'm not sure. The Gnome UI is mostly CSS and javascript FWIU
> however I have no idea of which property to alter. Gnome has an email
> list might find some pointers there, if no extension can be found.
>
>

https://extensions.gnome.org/extension/2/move-clock/

seems to fit the bill (though I believe Sven already mentioned this).

-- 
Hypertext--or should I say the ideology of hypertext?--is ultrademocratic and
so entirely in harmony with the demagogic appeals to cultural democracy that
accompany (and distract one’s attention from) the ever-tightening grip of 
plutocratic capitalism. - Susan Sontag

Re: Gnome top bar clock

[Stephen Allen]

On Fri, May 27, 2016 at 03:16:50PM +0200, Hársfalvi Gábor wrote:
> Hi!
> 
> Is there any way to move the clock on the bar top on the screen? For example
> from center to left side.
> 
> Thanks.

If you look on extensions.gnome.org you might find an extension to do
this. I'm not sure. The Gnome UI is mostly CSS and javascript FWIU
however I have no idea of which property to alter. Gnome has an email
list might find some pointers there, if no extension can be found.

ASPM: Could not configure common clock

[Chris Joysn]

Hello,

i installed Debian testing from the netinst iso onto a Lenovo W530 laptop.
When booting the machine when it is attached to its docking station with
closed display, i very often get the kernel message

ASPM: Could not configure common clock

and then the boot process hangs.
When i reboot with the opened display but still connected to the docking
station, it boots successfully more often. And i never experienced this
message and a hung boot process when the laptop is not attached to the
docking station.

kernel: Linux laptop 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16)
x86_64 GNU/Linux

I also tried the stable dist which has a 3.16 kernel (iirc), but then the
boot process hung after the following message:

thinkpad_acpi: unsupported brighten interface, please contaxt
ibm-acpi-de...@sf.net

I think it is not the common clock which is the problem, but how can i find
out what is really the problem?

Thanks in advance
Joysn

Re: Gnome top bar clock

[Sven Arvidsson]

On Fri, 2016-05-27 at 15:16 +0200, Hársfalvi Gábor wrote:
> Hi!
> 
> Is there any way to move the clock on the bar top on the screen? For 
> example from center to left side.

You need to use extensions for that
https://extensions.gnome.org/extension/2/move-clock/

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5



signature.asc
Description: This is a digitally signed message part

Re: Gnome top bar clock

[Lisi Reisz]

On Friday 27 May 2016 14:24:31 Lisi Reisz wrote:
> In TDE 3.5.13.2 on Wheezy, and TDE 14.0.4 on Jessie, you click just to the
> left of the clock applet to bring up a small window which offers, among
> other things, to move the clock.  You choose "move the clock" and move it.

Sorry, you RIGHT click etc.

Lisi

Re: Gnome top bar clock

[Lisi Reisz]

On Friday 27 May 2016 14:16:50 Hársfalvi Gábor wrote:
> Hi!
>
> Is there any way to move the clock on the bar top on the screen? For
> example from center to left side.

What desktop??  Or is it a window manager?  I seem to remember that you are 
running Gnome3 on Jessie, but you really need to say so when you ask this 
type of question.

In TDE 3.5.13.2 on Wheezy, and TDE 14.0.4 on Jessie, you click just to the 
left of the clock applet to bring up a small window which offers, among other 
things, to move the clock.  You choose "move the clock" and move it.

Lisi

Gnome top bar clock

[Hársfalvi Gábor]

Hi!

Is there any way to move the clock on the bar top on the screen? For 
example from center to left side.


Thanks.

Re: Odd messages booting Cubox-i4 Pro "imx-gpc 20dc000.gpc: failed to get pu regulator: -517" and "ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)"

[Nigel Sollars]

Hello,

There seems to be a good explanation here,

https://lists.debian.org/debian-arm/2013/12/msg00038.html

Regards

On Wed, Feb 3, 2016 at 12:56 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> Does anyone know what the error messages
>
> Does anybody know what is causing the subject error messages?
>
> It almost looks like the DTB is claiming a couple of devices that don't
> exist on this hardware... But I don't understand enough of that process to
> be sure.
>
> Anybody got some clues?
>
> I've attached the first several lines of the boot log, up-to and including
> the error messages, in hopes that they may have some information about the
> hardware.
>
> Thanks!
> Rick
>
> > U-Boot 2015.10+dfsg1-3 (Nov 24 2015 - 22:14:29 +)
> >
> > CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> > CPU:   Extended Commercial temperature grade (-20C to 105C) at 29C
> > Reset cause: WDOG
> > Board: MX6 Cubox-i
> > DRAM:  2 GiB
> > MMC:   FSL_SDHC: 0
> > No panel detected: default to HDMI
> > Display: HDMI (1024x768)
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   FEC
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc0 is current device
> > Scanning mmc 0:1...
> > Found U-Boot script /boot.scr
> > 1474 bytes read in 32 ms (44.9 KiB/s)
> > ## Executing script at 1200
> > 3415976 bytes read in 371 ms (8.8 MiB/s)
> > 33984 bytes read in 98 ms (337.9 KiB/s)
> > 17496691 bytes read in 1231 ms (13.6 MiB/s)
> > Booting Debian 4.3.0-1-armmp from mmc 0:1...
> > Kernel image @ 0x1200 [ 0x00 - 0x341fa8 ]
> > ## Flattened Device Tree blob at 1800
> >Booting using the fdt blob at 0x1800
> >Using Device Tree in place at 1800, end 1800b4bf
> >
> > Starting kernel ...
> >
> > [0.098389] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> >
> > [1.485042] imx-sdma 20ec000.sdma: firmware: failed to load
> imx/sdma/sdma-imx6q.bin (-2)
> > [1.544474] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> > [1.551844] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> > Loading, please wait...
> > [2.221380] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> > [2.257486] ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)
> >
>
>


-- 
“Science is a differential equation. Religion is a boundary condition.”

  Alan Turing

Re: Odd messages booting Cubox-i4 Pro "imx-gpc 20dc000.gpc: failed to get pu regulator: -517" and "ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)"

[John Holland]

> On 04.02.2016, at 14:04, Nigel Sollars  wrote:
> 
> There seems to be a good explanation here,
> 
> https://lists.debian.org/debian-arm/2013/12/msg00038.html
> 
>> On Wed, Feb 3, 2016 at 12:56 PM, Rick Thomas  wrote:
>> Does anyone know what the error messages
>> 
>> Does anybody know what is causing the subject error messages?
>> ...
>> > [0.098389] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
Personally, I'm more worried about this,
>> >
>> > [1.485042] imx-sdma 20ec000.sdma: firmware: failed to load 
>> > imx/sdma/sdma-imx6q.bin (-2)
Then this.

Odd messages booting Cubox-i4 Pro "imx-gpc 20dc000.gpc: failed to get pu regulator: -517" and "ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)"

[Rick Thomas]

Does anyone know what the error messages 

Does anybody know what is causing the subject error messages?

It almost looks like the DTB is claiming a couple of devices that don't exist 
on this hardware... But I don't understand enough of that process to be sure.

Anybody got some clues?

I've attached the first several lines of the boot log, up-to and including the 
error messages, in hopes that they may have some information about the hardware.

Thanks!
Rick

> U-Boot 2015.10+dfsg1-3 (Nov 24 2015 - 22:14:29 +)
> 
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 29C
> Reset cause: WDOG
> Board: MX6 Cubox-i
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 1474 bytes read in 32 ms (44.9 KiB/s)
> ## Executing script at 1200
> 3415976 bytes read in 371 ms (8.8 MiB/s)
> 33984 bytes read in 98 ms (337.9 KiB/s)
> 17496691 bytes read in 1231 ms (13.6 MiB/s)
> Booting Debian 4.3.0-1-armmp from mmc 0:1...
> Kernel image @ 0x1200 [ 0x00 - 0x341fa8 ]
> ## Flattened Device Tree blob at 1800
>Booting using the fdt blob at 0x1800
>Using Device Tree in place at 1800, end 1800b4bf
> 
> Starting kernel ...
> 
> [0.098389] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> 
> [1.485042] imx-sdma 20ec000.sdma: firmware: failed to load 
> imx/sdma/sdma-imx6q.bin (-2)
> [1.544474] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> [1.551844] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> Loading, please wait...
> [2.221380] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> [2.257486] ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)
> 

RE: clock losing time after a reboot with HP ZBook G2

[Arno Schuring]

 Date: Fri, 3 Jul 2015 15:07:34 +0200
 From: vinc...@vinc17.net

 When I run hwclock --systohc manually before the reboot, the clock
 is OK after reboot. So, this seems to be a systemd bug. I've reported:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

Michael, since I've seen you reply on this list as well, could you
please provide a little more rationale than we intentionally broke
your system when closing a bug?


Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w162461707e12e0b2036d5fb8...@phx.gbl

Re: clock losing time after a reboot with HP ZBook G2

[Michael Biebl]

Am 03.07.2015 um 15:18 schrieb Arno Schuring:
 
 Date: Fri, 3 Jul 2015 15:07:34 +0200
 From: vinc...@vinc17.net

 When I run hwclock --systohc manually before the reboot, the clock
 is OK after reboot. So, this seems to be a systemd bug. I've reported:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
 
 Michael, since I've seen you reply on this list as well, could you
 please provide a little more rationale than we intentionally broke
 your system when closing a bug?

I didn't say we intentionally broke your system, I said we intentionally
removed the hwclock-save units. That's a difference.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722 if you want
some background.

In short, your ntp client should ensure that the clock is synced to RTC
(google for ntp 11 min mode sync if you want to know more). For that
we enable timesyncd by default in systemd.
If you choose to disable timesyncd and/or use another NTP client, then
this is not a bug in systemd.

Thanks.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

RE: clock losing time after a reboot with HP ZBook G2

[Arno Schuring]

 Date: Fri, 3 Jul 2015 15:38:02 +0200
 From: bi...@debian.org

 Am 03.07.2015 um 15:18 schrieb Arno Schuring:

 Date: Fri, 3 Jul 2015 15:07:34 +0200
 From: vinc...@vinc17.net

 When I run hwclock --systohc manually before the reboot, the clock
 is OK after reboot. So, this seems to be a systemd bug. I've reported:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

 Michael, since I've seen you reply on this list as well, could you
 please provide a little more rationale than we intentionally broke
 your system when closing a bug?

 I didn't say we intentionally broke your system, I said we intentionally
 removed the hwclock-save units. That's a difference.

Without further explanation, there is no difference to the casual
observer. Thank you for the pointer to the rationale. I just wish you
would have included that link in your closing message.


Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w35e610d6fef357015ddf1b8...@phx.gbl

Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-07-01 02:24:14 +0200, Vincent Lefevre wrote:
 On 2015-06-30 18:15:18 -0400, Gary Dale wrote:
  Is your cmos battery still providing power?
 
 The machine is new, so it should. The machine was also constantly on
 AC power.
 
  Either that or your hardware clock could be broken or very
  inaccurate.
 
 If it loses 15 seconds just the time of a reboot, it's more than an
 inaccuracy.

When I run hwclock --systohc manually before the reboot, the clock
is OK after reboot. So, this seems to be a systemd bug. I've reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150703130734.ga31...@ypig.lip.ens-lyon.fr

Re: clock losing time after a reboot with HP ZBook G2

[Lisi Reisz]

On Friday 03 July 2015 14:18:50 Arno Schuring wrote:
  Date: Fri, 3 Jul 2015 15:07:34 +0200
  From: vinc...@vinc17.net
 
  When I run hwclock --systohc manually before the reboot, the clock
  is OK after reboot. So, this seems to be a systemd bug. I've reported:
 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

 Michael, since I've seen you reply on this list as well, could you
 please provide a little more rationale than we intentionally broke
 your system when closing a bug?

quote
That's intentional. We removed the hwclock-save units.
/quote

Why???

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201507031435.59708.lisi.re...@gmail.com

Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-07-03 15:38:02 +0200, Michael Biebl wrote:
 In short, your ntp client should ensure that the clock is synced to RTC
 (google for ntp 11 min mode sync if you want to know more). For that
 we enable timesyncd by default in systemd.

Thanks for the information, but the documentation shouldn't be in the
official documentation (man pages...), not on the web.

 If you choose to disable timesyncd and/or use another NTP client, then
 this is not a bug in systemd.

The clock was inaccurate before I installed another NTP client.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150703143550.ga8...@ypig.lip.ens-lyon.fr

Re: clock losing time after a reboot with HP ZBook G2

[Lisi Reisz]

On Friday 03 July 2015 14:38:02 Michael Biebl wrote:
 Am 03.07.2015 um 15:18 schrieb Arno Schuring:
  Date: Fri, 3 Jul 2015 15:07:34 +0200
  From: vinc...@vinc17.net
 
  When I run hwclock --systohc manually before the reboot, the clock
  is OK after reboot. So, this seems to be a systemd bug. I've reported:
 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
 
  Michael, since I've seen you reply on this list as well, could you
  please provide a little more rationale than we intentionally broke
  your system when closing a bug?

 I didn't say we intentionally broke your system, I said we intentionally
 removed the hwclock-save units. That's a difference.

 See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722 if you want
 some background.

 In short, your ntp client should ensure that the clock is synced to RTC
 (google for ntp 11 min mode sync if you want to know more). For that
 we enable timesyncd by default in systemd.
 If you choose to disable timesyncd and/or use another NTP client, then
 this is not a bug in systemd.

 Thanks.

So the answer to my question is that the clock is synced to UTC at start-up, 
so it doesn't need to remember where it was at shut-down.  Is that correct?

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201507031457.16081.lisi.re...@gmail.com

Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-06-30 18:15:18 -0400, Gary Dale wrote:
 Is your cmos battery still providing power?

The machine is new, so it should. The machine was also constantly on
AC power.

 Either that or your hardware clock could be broken or very
 inaccurate.

If it loses 15 seconds just the time of a reboot, it's more than an
inaccuracy.

 The NTP daemon keeps the system time in sync with whatever time
 source you are using but the hardware clock only gets set when you
 shut down unless you run something to set it more often.

Could there be a bug here?

Note that I do not get always ntp engine exiting / Terminating
messages in the log. So, there may something broken in the shutdown
procedure. What do you think?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150701002414.ga17...@xvii.vinc17.org

Re: clock losing time after a reboot with HP ZBook G2

[Gary Dale]

On 30/06/15 05:52 PM, Vincent Lefevre wrote:

I've noticed that with my new HP ZBook G2, the clock loses time after
a reboot. Below is the openntpd log without the peer messages (ntp
engine ready means that this is just after a reboot). What is the
cause? Which part of the software is responsible to sync the RTC?

Jun 29 17:25:43 zira ntpd[846]: ntp engine ready
Jun 29 17:25:43 zira kernel: [   36.730060] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:27:04 zira ntpd[837]: adjusting local clock by 13.466645s
Jun 29 17:29:18 zira ntpd[837]: adjusting local clock by 13.399644s
Jun 29 17:33:04 zira ntpd[837]: adjusting local clock by 13.286723s
Jun 29 17:36:48 zira ntpd[837]: adjusting local clock by 13.174479s
Jun 29 17:37:21 zira ntpd[837]: adjusting local clock by 13.157979s
Jun 29 17:39:55 zira ntpd[837]: adjusting local clock by 13.080871s
Jun 29 17:44:07 zira ntpd[837]: adjusting local clock by 12.954863s
Jun 29 17:46:49 zira ntpd[837]: adjusting local clock by 12.873868s
Jun 29 17:46:51 zira ntpd[846]: ntp engine exiting
Jun 29 17:46:51 zira ntpd[837]: Terminating
Jun 29 17:47:38 zira ntpd[871]: constraint certificate verification turned off
Jun 29 17:47:38 zira ntpd[871]: ntp engine ready
Jun 29 17:47:38 zira kernel: [   31.495426] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:48:57 zira ntpd[846]: adjusting local clock by 13.645922s
Jun 29 17:52:05 zira ntpd[846]: adjusting local clock by 13.551856s
Jun 29 17:54:48 zira ntpd[846]: adjusting local clock by 13.470787s
Jun 29 17:57:32 zira ntpd[846]: adjusting local clock by 13.388841s
Jun 29 17:59:40 zira ntpd[846]: adjusting local clock by 13.324690s
Jun 29 18:01:13 zira ntpd[846]: adjusting local clock by 13.277861s
Jun 29 18:05:35 zira ntpd[846]: adjusting local clock by 13.146952s
Jun 29 18:09:56 zira ntpd[846]: adjusting local clock by 13.016189s
Jun 29 18:12:04 zira ntpd[846]: adjusting local clock by 12.952223s
Jun 29 18:13:11 zira ntpd[846]: adjusting local clock by 12.918980s
[...]
Jun 30 01:17:06 zira ntpd[846]: adjusting local clock by 0.198699s
Jun 30 01:21:28 zira ntpd[846]: adjusting local clock by 0.067428s
Jun 30 01:22:00 zira ntpd[846]: adjusting local clock by 0.051427s
Jun 30 01:22:31 zira ntpd[846]: adjusting local clock by 0.035614s
Jun 30 01:25:14 zira ntpd[871]: clock is now synced
Jun 30 01:48:24 zira ntpd[846]: adjusting clock frequency by -0.050992 to 
-21.227978ppm
Jun 30 02:09:09 zira ntpd[846]: adjusting clock frequency by -0.269145 to 
-21.497112ppm
Jun 30 02:25:43 zira ntpd[846]: adjusting clock frequency by -0.635475 to 
-22.132576ppm
Jun 30 10:52:13 zira ntpd[846]: adjusting clock frequency by 0.833955 to 
-21.298614ppm
Jun 30 14:12:02 zira ntpd[871]: ntp engine exiting
Jun 30 14:12:02 zira ntpd[846]: Terminating
Jun 30 14:12:35 zira ntpd[801]: constraint certificate verification turned off
Jun 30 14:12:35 zira ntpd[801]: ntp engine ready
Jun 30 14:12:35 zira kernel: [   35.718822] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:12:35 zira ntpd[801]: reply from 37.187.56.220: not synced (alarm), 
next query 3166s
Jun 30 14:13:54 zira ntpd[790]: adjusting local clock by 15.278347s
Jun 30 14:15:00 zira ntpd[790]: adjusting local clock by 15.245347s
Jun 30 14:15:25 zira ntpd[801]: ntp engine exiting
Jun 30 14:15:25 zira ntpd[790]: Terminating
Jun 30 14:16:06 zira ntpd[862]: constraint certificate verification turned off
Jun 30 14:16:06 zira ntpd[862]: ntp engine ready
Jun 30 14:16:06 zira kernel: [   28.588667] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:16:06 zira ntpd[862]: reply from 37.187.56.220: not synced (alarm), 
next query 3234s
Jun 30 14:17:28 zira ntpd[845]: adjusting local clock by 15.567251s
Jun 30 14:21:45 zira ntpd[845]: adjusting local clock by 15.439340s
Jun 30 14:22:36 zira ntpd[845]: adjusting local clock by 15.413840s
Jun 30 14:24:12 zira ntpd[845]: adjusting local clock by 15.365855s
Jun 30 14:26:53 zira ntpd[845]: adjusting local clock by 15.285121s
Jun 30 14:29:00 zira ntpd[845]: adjusting local clock by 15.221573s
Jun 30 14:31:42 zira ntpd[845]: adjusting local clock by 15.140805s
Jun 30 14:32:49 zira ntpd[845]: adjusting local clock by 15.106892s
Jun 30 14:36:57 zira ntpd[845]: adjusting local clock by 14.982979s
Jun 30 14:38:36 zira ntpd[845]: adjusting local clock by 14.933478s
Jun 30 14:42:16 zira ntpd[845]: adjusting local clock by 14.823588s
Jun 30 14:46:31 zira ntpd[845]: adjusting local clock by 14.695910s
Jun 30 14:50:12 zira ntpd[845]: adjusting local clock by 14.585502s
Jun 30 14:54:01 zira ntpd[845]: adjusting local clock by 14.470910s
Jun 30 14:55:33 zira ntpd[845]: adjusting local clock by 14.425103s
Jun 30 14:58:44 zira ntpd[845]: adjusting local clock by 14.329479s
Jun 30 15:00:54 zira ntpd[845]: adjusting local clock by 14.264600s
Jun 30 15:01:28 zira ntpd[845]: adjusting local clock by 14.247518s
Jun 30 15:02:38 zira

clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

I've noticed that with my new HP ZBook G2, the clock loses time after
a reboot. Below is the openntpd log without the peer messages (ntp
engine ready means that this is just after a reboot). What is the
cause? Which part of the software is responsible to sync the RTC?

Jun 29 17:25:43 zira ntpd[846]: ntp engine ready
Jun 29 17:25:43 zira kernel: [   36.730060] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:27:04 zira ntpd[837]: adjusting local clock by 13.466645s
Jun 29 17:29:18 zira ntpd[837]: adjusting local clock by 13.399644s
Jun 29 17:33:04 zira ntpd[837]: adjusting local clock by 13.286723s
Jun 29 17:36:48 zira ntpd[837]: adjusting local clock by 13.174479s
Jun 29 17:37:21 zira ntpd[837]: adjusting local clock by 13.157979s
Jun 29 17:39:55 zira ntpd[837]: adjusting local clock by 13.080871s
Jun 29 17:44:07 zira ntpd[837]: adjusting local clock by 12.954863s
Jun 29 17:46:49 zira ntpd[837]: adjusting local clock by 12.873868s
Jun 29 17:46:51 zira ntpd[846]: ntp engine exiting
Jun 29 17:46:51 zira ntpd[837]: Terminating
Jun 29 17:47:38 zira ntpd[871]: constraint certificate verification turned off
Jun 29 17:47:38 zira ntpd[871]: ntp engine ready
Jun 29 17:47:38 zira kernel: [   31.495426] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:48:57 zira ntpd[846]: adjusting local clock by 13.645922s
Jun 29 17:52:05 zira ntpd[846]: adjusting local clock by 13.551856s
Jun 29 17:54:48 zira ntpd[846]: adjusting local clock by 13.470787s
Jun 29 17:57:32 zira ntpd[846]: adjusting local clock by 13.388841s
Jun 29 17:59:40 zira ntpd[846]: adjusting local clock by 13.324690s
Jun 29 18:01:13 zira ntpd[846]: adjusting local clock by 13.277861s
Jun 29 18:05:35 zira ntpd[846]: adjusting local clock by 13.146952s
Jun 29 18:09:56 zira ntpd[846]: adjusting local clock by 13.016189s
Jun 29 18:12:04 zira ntpd[846]: adjusting local clock by 12.952223s
Jun 29 18:13:11 zira ntpd[846]: adjusting local clock by 12.918980s
[...]
Jun 30 01:17:06 zira ntpd[846]: adjusting local clock by 0.198699s
Jun 30 01:21:28 zira ntpd[846]: adjusting local clock by 0.067428s
Jun 30 01:22:00 zira ntpd[846]: adjusting local clock by 0.051427s
Jun 30 01:22:31 zira ntpd[846]: adjusting local clock by 0.035614s
Jun 30 01:25:14 zira ntpd[871]: clock is now synced
Jun 30 01:48:24 zira ntpd[846]: adjusting clock frequency by -0.050992 to 
-21.227978ppm
Jun 30 02:09:09 zira ntpd[846]: adjusting clock frequency by -0.269145 to 
-21.497112ppm
Jun 30 02:25:43 zira ntpd[846]: adjusting clock frequency by -0.635475 to 
-22.132576ppm
Jun 30 10:52:13 zira ntpd[846]: adjusting clock frequency by 0.833955 to 
-21.298614ppm
Jun 30 14:12:02 zira ntpd[871]: ntp engine exiting
Jun 30 14:12:02 zira ntpd[846]: Terminating
Jun 30 14:12:35 zira ntpd[801]: constraint certificate verification turned off
Jun 30 14:12:35 zira ntpd[801]: ntp engine ready
Jun 30 14:12:35 zira kernel: [   35.718822] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:12:35 zira ntpd[801]: reply from 37.187.56.220: not synced (alarm), 
next query 3166s
Jun 30 14:13:54 zira ntpd[790]: adjusting local clock by 15.278347s
Jun 30 14:15:00 zira ntpd[790]: adjusting local clock by 15.245347s
Jun 30 14:15:25 zira ntpd[801]: ntp engine exiting
Jun 30 14:15:25 zira ntpd[790]: Terminating
Jun 30 14:16:06 zira ntpd[862]: constraint certificate verification turned off
Jun 30 14:16:06 zira ntpd[862]: ntp engine ready
Jun 30 14:16:06 zira kernel: [   28.588667] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:16:06 zira ntpd[862]: reply from 37.187.56.220: not synced (alarm), 
next query 3234s
Jun 30 14:17:28 zira ntpd[845]: adjusting local clock by 15.567251s
Jun 30 14:21:45 zira ntpd[845]: adjusting local clock by 15.439340s
Jun 30 14:22:36 zira ntpd[845]: adjusting local clock by 15.413840s
Jun 30 14:24:12 zira ntpd[845]: adjusting local clock by 15.365855s
Jun 30 14:26:53 zira ntpd[845]: adjusting local clock by 15.285121s
Jun 30 14:29:00 zira ntpd[845]: adjusting local clock by 15.221573s
Jun 30 14:31:42 zira ntpd[845]: adjusting local clock by 15.140805s
Jun 30 14:32:49 zira ntpd[845]: adjusting local clock by 15.106892s
Jun 30 14:36:57 zira ntpd[845]: adjusting local clock by 14.982979s
Jun 30 14:38:36 zira ntpd[845]: adjusting local clock by 14.933478s
Jun 30 14:42:16 zira ntpd[845]: adjusting local clock by 14.823588s
Jun 30 14:46:31 zira ntpd[845]: adjusting local clock by 14.695910s
Jun 30 14:50:12 zira ntpd[845]: adjusting local clock by 14.585502s
Jun 30 14:54:01 zira ntpd[845]: adjusting local clock by 14.470910s
Jun 30 14:55:33 zira ntpd[845]: adjusting local clock by 14.425103s
Jun 30 14:58:44 zira ntpd[845]: adjusting local clock by 14.329479s
Jun 30 15:00:54 zira ntpd[845]: adjusting local clock by 14.264600s
Jun 30 15:01:28 zira ntpd[845]: adjusting local clock by 14.247518s
Jun 30 15:02:38 zira ntpd[862]: constraint certificate verification

i18n issue in GNOME Classic re. modifying date format of Clock Applet

[Alexis]

Hi all,

Context: Wheezy x86_64 fresh install, plus all available updates, 
plus systemd-sysv from wheezy-backports.


Is it possible to change the date format used by the GNOME Classic 
Clock Applet? It seems nothing i do will get it change from the US 
month-before-day format.


In GNOME System Settings - Region and Language, the 'Formats' tab 
correctly shows the Region set to 'Australia', and correctly 
displays dates formatted in the standard date component order used 
here in Australia:


   Tuesday 17 March 2015
   17 March 2015
   17 Mar 2015
   17/03/15

Using `dconf Editor`, i found that the value of the 'region' key 
of org.gnome.system.locale was empty, but setting it to 
en_AU.utf8, logging out of the desktop, then logging back in 
again, also made no difference to the date component ordering in 
the applet.


i can confirm that right-clicking on the Clock Applet, selecting 
Preferences, then un-checking/re-checking items like 'Show the 
date' /do/ actually affect the applet.


localectl(1) reports:

  System Locale: LANG=en_GB.utf8 
 LC_NUMERIC=en_AU.utf8 LC_TIME=en_AU.utf8 
 LC_MONETARY=en_AU.utf8 LC_MEASUREMENT=en_AU.utf8 

Since this is basic internationalisation functionality, i assume 
that i'm probably missing some setting. i have no problem 
modifying a strftime(3)-format string somewhere if necessary.


Any suggestions, please?


Alexis.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/87ioe0t39y@gmail.com

buici-clock problems

[Frank McCormick]

I have been fooling around with buici-clock on Debian Sid.
I was running it on the desktop at 100x100 with the appropriate
x and y offsets.
It was being called from the Fluxbox startup file.
I then modifed the file to enlarge the clock to 150x150 and
lowered the x and y offsets. What happens now is the new larger
clock pops up where it is supposed to, then a second later moves to the 
old offsets.

Can anyone explain what's going on here?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/52ab5653.60...@videotron.ca

NFS, Nautilus, D-Bus and clock settings

[Iuri Guilherme dos Santos Martins]

I have around ten computers in a properly configured network all
running Debian Wheezy.

After I installed task-file-server in all of them I have been able to
share the 'Public' folder of every machine and transfer files within
the network.

It seems that now everytime I try to open the remote folders on
Nautilus I just recieve the DBus error
org.freedesktop.DBus.Error.NoReply: Message did not receive a reply
(timeout by message bus).

One thing that I am aware of and no it can't be solved is that the
clocks can't work correctly. The machines don't have good battery and
the clocks are not working well, resulting in machines with wrong time
settings and not all machines on the network having the same clock
settings.

I have tried dpkg-reconfigure for nfs-kernel-server, nfs-common,
nautilus and tzdata in all machines with no luck.

Could it be the clock settings the ONLY issue?

On dmesg I keep receiving this kind of thing:

[  135.896580] gvfsd-dav[3597]: segfault at 0 ip b717fbeb sp bfca73dc
error 4 in libc-2.13.so[b705f000+15c000]
[  140.372132] gvfsd-dav[3603]: segfault at 0 ip b7212beb sp bf8fb3dc
error 4 in libc-2.13.so[b70f2000+15c000]
[  147.000184] gvfsd-dav[3609]: segfault at 0 ip b725abeb sp bf8d663c
error 4 in libc-2.13.so[b713a000+15c000]
[  175.100971] gvfsd-dav[3633]: segfault at 0 ip b7224beb sp bfadedcc
error 4 in libc-2.13.so[b7104000+15c000]
[  184.828316] gvfsd-dav[3644]: segfault at 0 ip b71d0beb sp bfc9734c
error 4 in libc-2.13.so[b70b+15c000]
[  614.228416] gvfsd-dav[5499]: segfault at 0 ip b721cbeb sp bfa7691c
error 4 in libc-2.13.so[b70fc000+15c000]
[  628.202003] gvfsd-dav[5507]: segfault at 0 ip b71dfbeb sp bfdc718c
error 4 in libc-2.13.so[b70bf000+15c000]
[  680.223327] gvfsd-dav[5518]: segfault at 0 ip b71c3beb sp bfd1468c
error 4 in libc-2.13.so[b70a3000+15c000]
[  838.858258] gvfsd-dav[5549]: segfault at 0 ip b7205beb sp bfef70fc
error 4 in libc-2.13.so[b70e5000+15c000]
[  843.297597] gvfsd-dav[]: segfault at 0 ip b7220beb sp bffca22c
error 4 in libc-2.13.so[b710+15c000]
[ 1481.384276] gvfsd-dav[5663]: segfault at 0 ip b71f2beb sp bffc31dc
error 4 in libc-2.13.so[b70d2000+15c000]
[ 2007.550403] gvfsd-dav[5709]: segfault at 0 ip b7267beb sp bfa196dc
error 4 in libc-2.13.so[b7147000+15c000]

-- 
http://iuri.neocities.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAF0bz4RKK2TWOa_qGfk12emjB+ONxBr=g10oyzjsdp01bqu...@mail.gmail.com

Re: NFS, Nautilus, D-Bus and clock settings

[Bob Proulx]

Iuri Guilherme dos Santos Martins wrote:
 It seems that now everytime I try to open the remote folders on
 Nautilus I just recieve the DBus error
 org.freedesktop.DBus.Error.NoReply: Message did not receive a reply
 (timeout by message bus).

I don't know about this message.

 One thing that I am aware of and no it can't be solved is that the
 clocks can't work correctly. The machines don't have good battery and
 the clocks are not working well, resulting in machines with wrong time
 settings and not all machines on the network having the same clock
 settings.

You have known clock problems?  The time is not in sync across your
collection of hosts?  That is bad by itself.

You should definitely take care that your clocks are updated.  The
dead battery should make no difference.  All that means is that the
system can't get the time at boot from the hardware clock.  Instead
the system will need to get the time from the network at boot time.
That is okay.  That is quite normal.

 I have tried dpkg-reconfigure for nfs-kernel-server, nfs-common,
 nautilus and tzdata in all machines with no luck.
 
 Could it be the clock settings the ONLY issue?

Regardless of whether it is the only issue, it should be the first
issue you fix.  Then if the other problem you are having is still a
problem then you can worry about it.  First thing to do is fix the
clocks.

  # apt-get install ntp

The defaults are okay for single standalone machines.  Doing the above
on any random machine should be enough.  If the time is really wrong
then you should reboot so that all processes are restarted and the
configuration can get the time from the network at boot time.

Optimization Details:

You said you have ten machines.  Definitely for you I would configure
the local systems to peer time with each other.  If you only have
ten and they are all the same, say all desktops, then I would have all
of them peer with all of them.  This is not elegant and uses more
force than needed but works.

File /etc/ntp.conf entries:
  server 0.debian.pool.ntp.org iburst
  server 1.debian.pool.ntp.org iburst
  server 2.debian.pool.ntp.org iburst
  server 3.debian.pool.ntp.org iburst
  peer desktop1 iburst
  peer desktop2 iburst
  peer desktop3 iburst
  peer ...
  peer desktop10 iburst

The above would be okay if you have a small network of ten machines.
The peering allows them to share time with each other.  That is a
good thing to do.  The result will be much better than if they can
only get the time from the WAN due to WAN glitches.  The LAN is more
reliable and allows the sum to be much better than the parts.

More optimization is possible.  If two or three of those machines are
top level machines on your network and there is some hierarchy then
I would embrace that hierarchy.  It is a burden on the networked time
servers to be serving so many machines from a single local site.  I
would set up the top level machines to get time from the network.  The
upstream ntp docs recommend four local timeservers.  I have found
three to be quite good.  That way the network time servers only see
two, three, or four at max sytems loading them from your site.  Then
have all of the rest of the machines get time from your site
timeservers.

Your two or three top level machines:
  server 0.debian.pool.ntp.org iburst
  server 1.debian.pool.ntp.org iburst
  server 2.debian.pool.ntp.org iburst
  server 3.debian.pool.ntp.org iburst
  peer topserver1 iburst
  peer topserver2 iburst
  peer topserver3 iburst

The rest of your systems:
  server topserver1 iburst
  server topserver2 iburst
  server topserver3 iburst

The ntpd knows its own name.  It is okay to have its own hostname in
the file on that host.  That makes it easy to have the same file on
multiple machines including machines where it is serving or peering
time itself.

With any of the three config cases above your machines should all now
be very closely in time sync with each other.  Hopefully any time
problems you have having should go away.

Hint: Check the ntpd status using 'ntpq -p'.  I can say more about
debugging those later if you need.

 On dmesg I keep receiving this kind of thing:
 
 [  135.896580] gvfsd-dav[3597]: segfault at 0 ip b717fbeb sp bfca73dc
 error 4 in libc-2.13.so[b705f000+15c000]

segfault is completely different from time problems and from NFS and
SAMBA problems. segfault means that a process had a segmentation
fault.  That is most often due to program bugs.  (If you access an
array so far out of bounds that it is outside your program memory
space for example.)  Often due to shared library version mismatches.
Double check that your system is up to date.

Sometimes this will be due to faulty ram causing memory errors.  If
this is on one machine only then I would suspect ram.  If this is
across several machines then I would suspect a software shared library
problem.

If this is one program then I suspect a program bug.  Since this
seemed to have been gvfsd-dav only then I suspect either a bug

filesystem clock is behind system clock

[Raphael Bauduin]

Bonjour,

J'ai ces messages chaque jour vers minuit:

Aug 27 00:13:47 host postfix/cleanup[2739]: warning: file system clock is
139 seconds behind local clock
Aug 27 00:13:47 host postfix/cleanup[2756]: warning: file system clock is
127 seconds behind local clock
Aug 27 00:13:47 host postfix/cleanup[2684]: warning: file system clock is
166 seconds behind local clock

L'heure du serveur est maintenue avec ntp, et je ne constate pas de
différence d'heure par rapport à d'autres systèmes. Je ne vois aucun log de
mise à jour de l'heure à ce moment-là.

Je trouve aussi bizarre que à la même heure, des écarts différents sont
rapportés. à 00:13:47, les écarts sont simultanément de 127, 139 et 166
secondes.

Quelqu'un aurait-il une explication ou des suggestions de résolution?

Merci!

Raph

Re: filesystem clock is behind system clock

[julien]

Le 2013-08-27 08:44, Raphael Bauduin a écrit :

Bonjour,

J'ai ces messages chaque jour vers minuit:

Aug 27 00:13:47 host postfix/cleanup[2739]: warning: file system
clock is 139 seconds behind local clock
 Aug 27 00:13:47 host postfix/cleanup[2756]: warning: file system
clock is 127 seconds behind local clock
 Aug 27 00:13:47 host postfix/cleanup[2684]: warning: file system
clock is 166 seconds behind local clock

L'heure du serveur est maintenue avec ntp, et je ne constate pas de
différence d'heure par rapport à d'autres systèmes. Je ne vois aucun
log de mise à jour de l'heure à ce moment-là.

Je trouve aussi bizarre que à la même heure, des écarts différents
sont rapportés. à 00:13:47, les écarts sont simultanément de 127, 139
et 166 secondes.

Quelqu'un aurait-il une explication ou des suggestions de résolution?


Moi j'ai des questions est-ce que ça marche ?

Quel type de FS utilises tu ?
Tu as plusieurs serveurs ?
Ils sont tous sur debian ?
As-tu installé NTP sur chaque serveur ?

Il n'y a pas d'horloge dans un système de fichiers, le message 
d'avertissement indique, pour moi, un fichier dont la date est supérieur 
à la date système.


Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/67e14d67bc293d950a91de225a3da...@127.0.0.1nura.eu

Re: filesystem clock is behind system clock

[Gaëtan PERRIER]

Le Tue, 27 Aug 2013 08:44:11 +0200
Raphael Bauduin rbli...@gmail.com a écrit:

 Bonjour,
 
 J'ai ces messages chaque jour vers minuit:
 
 Aug 27 00:13:47 host postfix/cleanup[2739]: warning: file system
 clock is 139 seconds behind local clock
 Aug 27 00:13:47 host postfix/cleanup[2756]: warning: file system
 clock is 127 seconds behind local clock
 Aug 27 00:13:47 host postfix/cleanup[2684]: warning: file system
 clock is 166 seconds behind local clock
 
 L'heure du serveur est maintenue avec ntp, et je ne constate pas de
 différence d'heure par rapport à d'autres systèmes. Je ne vois aucun
 log de mise à jour de l'heure à ce moment-là.
 
 Je trouve aussi bizarre que à la même heure, des écarts différents
 sont rapportés. à 00:13:47, les écarts sont simultanément de 127, 139
 et 166 secondes.
 
 Quelqu'un aurait-il une explication ou des suggestions de résolution?
 
 Merci!
 
 Raph

Je ne sais pas si j'ai ces messages mais je confirme qu'il y a un
problème actuellement avec ntp car sur mon portable en testing l'heure
affichée à 3 à 4 minutes d'avance ...

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130827130250.7338d6be41cce29522c7f...@neuf.fr

Re: KDE digital clock NTP server time adjust.

[Franco Martelli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 29/06/2013 20:24, Bob Proulx ha scritto:
 Franco Martelli wrote:
 I installed both ntpdate and rdate packages but automatic date
 and time update of KDE digital clock on the desktop doesn't
 work. Do I need package like kdesudo in order to make things
 working?
 
 No.  Your choice of packages is unfortunate.  A mistake.  Instead 
 install 'ntp'.
 

But I used strings command to looking for in kcm_clock.so (for
investigation) and its output suggest me to install ntpdate or rdate
in order to obtain digital clock automatically updated.

# strings /usr/lib/kde4/kcm_clock.so|sort|less

then hit / to enter in search mode and type ntpdate less will
point to the following string:

No NTP utility has been found. Install 'ntpdate' or 'rdate' command to
enable automatic updating of date and time.
...

Should I ask to KDE or QT related mailing list?
Thanks in advance for any answer.

Regards.
- -- 
Franco Martelli.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR0EELAAoJEFM/ma7n+T+7pHUIAImoQfDr8diTdxp+NOmFG+DJ
jCkSIxLpD+ePdMfLBInMUeGXbr80QTohT88vSX7w1gno7cd+LYnCA9M3B8cLHKKz
FgRxxgY2LPod8TyXXF5+TybSVIdT72SLMTIaxucspjENY25KXZS3DY5V51qmMfjG
ELyX/EeWLvv3i8rcxBMr4YpMIXMG4ypisjOuiROXqermftuMTI7FTJQUNfLL5e0W
x48G+QMPd4hE8eNN9WUw+06FF93y936MjzOUpfvEv6Jhbl31EQbL2PZfFmu2fBGi
LBgPaT+MNH6Ur40rOrpndDOGfw7gSN/cHsxAmGkfk2/OXTclHBNun+uWfdT+nFI=
=YNMF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d0410c.4000...@gmail.com

Re: KDE digital clock NTP server time adjust.

[Bob Proulx]

Franco Martelli wrote:
 Bob Proulx ha scritto:
  Franco Martelli wrote:
  I installed both ntpdate and rdate packages but automatic date
  and time update of KDE digital clock on the desktop doesn't
  work. Do I need package like kdesudo in order to make things
  working?
  
  No.  Your choice of packages is unfortunate.  A mistake.  Instead 
  install 'ntp'.
 
 But I used strings command to looking for in kcm_clock.so (for
 investigation) and its output suggest me to install ntpdate or rdate
 in order to obtain digital clock automatically updated.
 
 # strings /usr/lib/kde4/kcm_clock.so|sort|less
 
 then hit / to enter in search mode and type ntpdate less will
 point to the following string:
 
 No NTP utility has been found. Install 'ntpdate' or 'rdate' command to
 enable automatic updating of date and time.

I am impressed that you used strings to find the text notes in that
library!  Very clever.  However those are just hints left there by the
programmer of that library.  And those are notes that are buried quite
deep.  They won't have had as much review.

 Should I ask to KDE or QT related mailing list?

I would file a bug against that library asking that the hints included
in it be updated.  The hints are providing bad advice.  Because
stepping the clock is never desirable.

However the way you found that hint is unusual.  I don't know how that
hint would be shown to the user normally.  It might never be shown to
the user.  In which case it would be hard to call that a bug.

 Thanks in advance for any answer.

In my not so humble opinion the hint advice offered by kcm_clock.so is
bad advice.  It advises to install programs that are designed to step
the clock.  Stepping the clock during normal runtime operation of the
system is bad and causes other problems.

I think it should advise correcting the clock more generically.
Because any specific advise today may be stale and obsolete in the
future.  Packages change and technologies move forward.  Embedding
high level system advise in a low level library seems prone to
becoming out of sync.

I would purge rdate and ntpdate and install ntp as I recommended in
the previous email.

  # apt-get purge ntpdate rdate
  # apt-get install ntp

Bob


signature.asc
Description: Digital signature

KDE digital clock NTP server time adjust.

[Franco Martelli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I,m on Wheezy amd64 port.
I installed both ntpdate and rdate packages but automatic date and
time update of KDE digital clock on the desktop doesn't work.
Do I need package like kdesudo in order to make things working?

Trying with rdate I got:

$ rdate europe.pool.ntp.org
rdate: Could not connect socket: Connection refused
$ rdate -ncv europe.pool.ntp.org
rdate: Could not set time of day: Operation not permitted

Please, any hint that help me to solve this situation would be really
appreciated, thanks in advance.

- -- 
Franco Martelli.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRzuZvAAoJEFM/ma7n+T+7V2UH/267jQsKiv6/qMUyiizTjY/I
yPzIqybCBwuwAMhRZ0I+yGayds9c821eSVF4nxz7oMu7gAhdTLNFnum9whX9LNHm
4svHXs7F2LYDZ2n5F54NwG30flKx/N8Y4sFfyfeznDNyGVjiSjLC7SBl3l5g3YHK
rKxe5C4fZoSjYSLbTxVj8nNluo9AGh5Vxg4A7iGJgaaJukD5kAeYQ/Fgp6DSaTJV
doKKffJa6QlIxgBTCwR/SRz0fV/CutvtIHV1KJ6f9G5mg16zlCtI8jaXbo647tCe
hoM0NjEj/sPzRaoTJkm8ZaTSgSu1Fue1RbUCfmGFfoOZ39Yc7YmPRHMU1grrMjQ=
=8TM7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51cee66f.3090...@gmail.com

Re: KDE digital clock NTP server time adjust.

[Erwan David]

Le 29/06/2013 15:51, Franco Martelli a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I,m on Wheezy amd64 port.
I installed both ntpdate and rdate packages but automatic date and
time update of KDE digital clock on the desktop doesn't work.
Do I need package like kdesudo in order to make things working?

Trying with rdate I got:

$ rdate europe.pool.ntp.org
rdate: Could not connect socket: Connection refused
$ rdate -ncv europe.pool.ntp.org
rdate: Could not set time of day: Operation not permitted

Please, any hint that help me to solve this situation would be really
appreciated, thanks in advance.

- -- 
 Franco Martelli.


1) rdate is not ntp related so the first answer is normal

2) ntpdate is to be used by root, however it should not be used for 
automatic update except at boot. You should install the ntp package 
which works continuously by adapting clock speed, and is the best way to 
get and keep a correct time.


The default configuration should work without problem for a client machine.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/51cf1caa.8020...@rail.eu.org

Re: KDE digital clock NTP server time adjust.

[Bob Proulx]

Franco Martelli wrote:
 I installed both ntpdate and rdate packages but automatic date and
 time update of KDE digital clock on the desktop doesn't work.
 Do I need package like kdesudo in order to make things working?

No.  Your choice of packages is unfortunate.  A mistake.  Instead
install 'ntp'.

  # apt-get purge ntpdate rdate

Then install the ntp package.

  # apt-get install ntp

More information about NTP can be found on the wiki.

  http://wiki.debian.org/NTP

The above must be done as root as indicated by the '#' prompt.  Use
either 'su' or 'sudo'.

  $ su
  # apt-get install ntp

Or if you have sudo installed and configured then you can use sudo in
one step.

  $ sudo apt-get install ntp

I always recommend configuring sudo.  You can do it this way:

  # apt-get install sudo
  # adduser yourusername sudo

Then log out and log back in again so that your group will be set at
login time to the sudo group.  More information about sudo is
available on the wiki.

  http://wiki.debian.org/sudo

 Trying with rdate I got:
 
 $ rdate europe.pool.ntp.org
 rdate: Could not connect socket: Connection refused

Your prompt indicates that you are not root.  Therefore it cannot
function.

 $ rdate -ncv europe.pool.ntp.org
 rdate: Could not set time of day: Operation not permitted

Same thing.  You were not root and therefore it cannot function.

 Please, any hint that help me to solve this situation would be really
 appreciated, thanks in advance.

Using ntp is the better solution over using rdate.  You don't want to
step the clock all of the time.  In the random hit cases where the
stepping happens at a bad moment then it will cause problems.  Cron
tasks may run twice or not at all.  Better to use a tool like ntp that
adjusts the clock so that every second is seen and never skipped.

Bob


signature.asc
Description: Digital signature

Gnome Clock

[cletusjenkins]

The gnome clock applet's weather fuction is currently showing the temperature 
in Orlando, FL (OIA) is 84F. Outside my house the thermometer says it is 60F. 
The weather channel is reporting 59F. The gnome weather applet is reporting 61F.

-- clet
debian is my main squeeze



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/699307818.20718.1365253862329.JavaMail.sas@[172.29.244.248]

Re: clock source 25 is not valid, cannot use

[d4n1]

Daniel Melo d4n1 :
On Jan 24, 2013 11:33 PM, Azuki a.tmp.em...@email.com wrote:

 When I use linux-image-3.2.0-0.bpo.4-rt-amd64, An error of a large
 quantity of clock source occurs at the boot time when I connect
 usb-sound-card AS372(chip:CM6620).
 There is not the problem with the stability of the system, but these
 errors fill up the log.
 When I used kernel 2.6.32, this error was not displayed because
 usb-sound-card did not recognize.
 I do not know it whether that this error is the problem of the kernel or a
 problem of alsa.
 How can I fix it?

 -- System Information:
 Debian Release: 6.0.6
   APT prefers stable
   APT policy: (500, 'stable')
 Architecture: amd64 (x86_64)

 ** Kernel log:
 [   69.568042] 2:4:2: clock source 25 is not valid, cannot use
 [   69.570406] 2:4:2: clock source 25 is not valid, cannot use
 [   69.570907] 2:4:2: clock source 25 is not valid, cannot use
 [   69.571531] 2:4:2: clock source 25 is not valid, cannot use
 [   69.572798] 2:4:2: clock source 25 is not valid, cannot use
 [   69.573935] 2:4:2: clock source 25 is not valid, cannot use
 [   69.576163] 2:4:2: clock source 25 is not valid, cannot use
 [   69.576660] 2:4:2: clock source 25 is not valid, cannot use
 [   69.577282] 2:4:2: clock source 25 is not valid, cannot use
 [   69.578426] 2:4:2: clock source 25 is not valid, cannot use
 [   69.579551] 2:4:2: clock source 25 is not valid, cannot use
 [   69.582158] 2:4:2: clock source 25 is not valid, cannot use
 [   69.582658] 2:4:2: clock source 25 is not valid, cannot use
 [   69.583283] 2:4:2: clock source 25 is not valid, cannot use
 [   69.584321] 2:4:2: clock source 25 is not valid, cannot use
 [   69.585442] 2:4:2: clock source 25 is not valid, cannot use
 [   69.587907] 2:4:2: clock source 25 is not valid, cannot use
 [   69.588538] 2:4:2: clock source 25 is not valid, cannot use
 [   69.589033] 2:4:2: clock source 25 is not valid, cannot use
 [   69.590055] 2:4:2: clock source 25 is not valid, cannot use
 [   69.591177] 2:4:2: clock source 25 is not valid, cannot use
 [   69.593908] 2:4:2: clock source 25 is not valid, cannot use
 [   69.594533] 2:4:2: clock source 25 is not valid, cannot use
 [   69.595158] 2:4:2: clock source 25 is not valid, cannot use
 [   69.596183] 2:4:2: clock source 25 is not valid, cannot use
 [   69.597442] 2:4:2: clock source 25 is not valid, cannot use
 [   69.600077] 2:4:2: clock source 25 is not valid, cannot use
 [   69.600793] 2:4:2: clock source 25 is not valid, cannot use
 [   69.601411] 2:4:2: clock source 25 is not valid, cannot use
 [   69.602440] 2:4:2: clock source 25 is not valid, cannot use
 [   69.603559] 2:4:2: clock source 25 is not valid, cannot use
 [   69.626664] 2:4:2: clock source 25 is not valid, cannot use
 [   69.627288] 2:4:2: clock source 25 is not valid, cannot use
 [   69.627913] 2:4:2: clock source 25 is not valid, cannot use
 [   69.629064] 2:4:2: clock source 25 is not valid, cannot use
 [   69.630184] 2:4:2: clock source 25 is not valid, cannot use
 [   69.632418] 2:4:2: clock source 25 is not valid, cannot use
 [   69.632914] 2:4:2: clock source 25 is not valid, cannot use
 [   69.633414] 2:4:2: clock source 25 is not valid, cannot use
 [   69.634439] 2:4:2: clock source 25 is not valid, cannot use
 [   69.635437] 2:4:2: clock source 25 is not valid, cannot use
 [   69.638039] 2:4:2: clock source 25 is not valid, cannot use
 [   69.638540] 2:4:2: clock source 25 is not valid, cannot use
 [   69.639165] 2:4:2: clock source 25 is not valid, cannot use
 [   69.640303] 2:4:2: clock source 25 is not valid, cannot use
 [   69.641443] 2:4:2: clock source 25 is not valid, cannot use
 [   69.644079] 2:4:2: clock source 25 is not valid, cannot use
 [   69.644798] 2:4:2: clock source 25 is not valid, cannot use
 [   69.645416] 2:4:2: clock source 25 is not valid, cannot use
 [   69.646566] 2:4:2: clock source 25 is not valid, cannot use
 [   69.647815] 2:4:2: clock source 25 is not valid, cannot use
 [   69.650041] 2:4:2: clock source 25 is not valid, cannot use
 [   69.650666] 2:4:2: clock source 25 is not valid, cannot use
 [   69.651291] 2:4:2: clock source 25 is not valid, cannot use
 [   69.652309] 2:4:2: clock source 25 is not valid, cannot use
 [   69.653442] 2:4:2: clock source 25 is not valid, cannot use
 [   69.655541] 2:4:2: clock source 25 is not valid, cannot use
 [   69.656081] 2:4:2: clock source 25 is not valid, cannot use
 [   69.656798] 2:4:2: clock source 25 is not valid, cannot use
 [   69.657693] 2:4:2: clock source 25 is not valid, cannot use
 [   69.658818] 2:4:2: clock source 25 is not valid, cannot use
 [   69.661292] 2:4:2: clock source 25 is not valid, cannot use
 [   69.661918] 2:4:2: clock source 25 is not valid, cannot use
 [   69.662543] 2:4:2: clock source 25 is not valid, cannot use
 [   69.663567] 2:4:2: clock source 25 is not valid, cannot use
 [   69.664933] 2:4:2: clock source 25 is not valid, cannot use
 [   69.667418] 2:4:2: clock source 25 is not valid, cannot use

clock source 25 is not valid, cannot use

[Azuki]

When I use linux-image-3.2.0-0.bpo.4-rt-amd64, An error of a large quantity of 
clock source occurs at the boot time when I connect usb-sound-card 
AS372(chip:CM6620).
There is not the problem with the stability of the system, but these errors 
fill up the log.
When I used kernel 2.6.32, this error was not displayed because usb-sound-card 
did not recognize.
I do not know it whether that this error is the problem of the kernel or a 
problem of alsa.
How can I fix it?

-- System Information:
Debian Release: 6.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

** Kernel log:
[   69.568042] 2:4:2: clock source 25 is not valid, cannot use
[   69.570406] 2:4:2: clock source 25 is not valid, cannot use
[   69.570907] 2:4:2: clock source 25 is not valid, cannot use
[   69.571531] 2:4:2: clock source 25 is not valid, cannot use
[   69.572798] 2:4:2: clock source 25 is not valid, cannot use
[   69.573935] 2:4:2: clock source 25 is not valid, cannot use
[   69.576163] 2:4:2: clock source 25 is not valid, cannot use
[   69.576660] 2:4:2: clock source 25 is not valid, cannot use
[   69.577282] 2:4:2: clock source 25 is not valid, cannot use
[   69.578426] 2:4:2: clock source 25 is not valid, cannot use
[   69.579551] 2:4:2: clock source 25 is not valid, cannot use
[   69.582158] 2:4:2: clock source 25 is not valid, cannot use
[   69.582658] 2:4:2: clock source 25 is not valid, cannot use
[   69.583283] 2:4:2: clock source 25 is not valid, cannot use
[   69.584321] 2:4:2: clock source 25 is not valid, cannot use
[   69.585442] 2:4:2: clock source 25 is not valid, cannot use
[   69.587907] 2:4:2: clock source 25 is not valid, cannot use
[   69.588538] 2:4:2: clock source 25 is not valid, cannot use
[   69.589033] 2:4:2: clock source 25 is not valid, cannot use
[   69.590055] 2:4:2: clock source 25 is not valid, cannot use
[   69.591177] 2:4:2: clock source 25 is not valid, cannot use
[   69.593908] 2:4:2: clock source 25 is not valid, cannot use
[   69.594533] 2:4:2: clock source 25 is not valid, cannot use
[   69.595158] 2:4:2: clock source 25 is not valid, cannot use
[   69.596183] 2:4:2: clock source 25 is not valid, cannot use
[   69.597442] 2:4:2: clock source 25 is not valid, cannot use
[   69.600077] 2:4:2: clock source 25 is not valid, cannot use
[   69.600793] 2:4:2: clock source 25 is not valid, cannot use
[   69.601411] 2:4:2: clock source 25 is not valid, cannot use
[   69.602440] 2:4:2: clock source 25 is not valid, cannot use
[   69.603559] 2:4:2: clock source 25 is not valid, cannot use
[   69.626664] 2:4:2: clock source 25 is not valid, cannot use
[   69.627288] 2:4:2: clock source 25 is not valid, cannot use
[   69.627913] 2:4:2: clock source 25 is not valid, cannot use
[   69.629064] 2:4:2: clock source 25 is not valid, cannot use
[   69.630184] 2:4:2: clock source 25 is not valid, cannot use
[   69.632418] 2:4:2: clock source 25 is not valid, cannot use
[   69.632914] 2:4:2: clock source 25 is not valid, cannot use
[   69.633414] 2:4:2: clock source 25 is not valid, cannot use
[   69.634439] 2:4:2: clock source 25 is not valid, cannot use
[   69.635437] 2:4:2: clock source 25 is not valid, cannot use
[   69.638039] 2:4:2: clock source 25 is not valid, cannot use
[   69.638540] 2:4:2: clock source 25 is not valid, cannot use
[   69.639165] 2:4:2: clock source 25 is not valid, cannot use
[   69.640303] 2:4:2: clock source 25 is not valid, cannot use
[   69.641443] 2:4:2: clock source 25 is not valid, cannot use
[   69.644079] 2:4:2: clock source 25 is not valid, cannot use
[   69.644798] 2:4:2: clock source 25 is not valid, cannot use
[   69.645416] 2:4:2: clock source 25 is not valid, cannot use
[   69.646566] 2:4:2: clock source 25 is not valid, cannot use
[   69.647815] 2:4:2: clock source 25 is not valid, cannot use
[   69.650041] 2:4:2: clock source 25 is not valid, cannot use
[   69.650666] 2:4:2: clock source 25 is not valid, cannot use
[   69.651291] 2:4:2: clock source 25 is not valid, cannot use
[   69.652309] 2:4:2: clock source 25 is not valid, cannot use
[   69.653442] 2:4:2: clock source 25 is not valid, cannot use
[   69.655541] 2:4:2: clock source 25 is not valid, cannot use
[   69.656081] 2:4:2: clock source 25 is not valid, cannot use
[   69.656798] 2:4:2: clock source 25 is not valid, cannot use
[   69.657693] 2:4:2: clock source 25 is not valid, cannot use
[   69.658818] 2:4:2: clock source 25 is not valid, cannot use
[   69.661292] 2:4:2: clock source 25 is not valid, cannot use
[   69.661918] 2:4:2: clock source 25 is not valid, cannot use
[   69.662543] 2:4:2: clock source 25 is not valid, cannot use
[   69.663567] 2:4:2: clock source 25 is not valid, cannot use
[   69.664933] 2:4:2: clock source 25 is not valid, cannot use
[   69.667418] 2:4:2: clock source 25 is not valid, cannot use
[   69.668154] 2:4:2: clock source 25 is not valid, cannot use
[   69.668675] 2:4:2: clock source 25 is not valid, cannot use
[   69.669695] 2:4:2: clock source 25

Re: Re (2): Default sound for alarm-clock 0.3.1 in Squeeze.

[Camaleón]

On Wed, 06 Jun 2012 10:42:11 -0800, peter wrote:

 From: Camaleon noela...@gmail.com
 Date: Wed, 6 Jun 2012 16:32:44 + (UTC)
 There's a ring.wav file under /usr/share/alarmclock folder :-?
 
 Our folders are different.
 
 peter@dalton:~$ ls -dl /usr/share/alar* 
 drwxr-xr-x 2 root root 4096 Jun 1 11:20 /usr/share/alarm-clock-applet
 
 No sounds in mine.

 peter@dalton:~$ ls -dl /usr/share/alar*/* 
 -rw-r--r-- 1 root root 64492 May 28  2010 
 /usr/share/alarm-clock-applet/alarm-cl ock.ui

Mmm... I didn't install the application but looked inside the deb package 
which seems to contain the wav file:

http://packages.debian.org/squeeze/amd64/alarm-clock/filelist

***
/usr/share/alarmclock/ring.wav
***

 ... sound files ... usually under /usr/share/sounds ...
 
 OK, this should work.
 
 peter@dalton:~$ ls /usr/share/sounds/freedesktop/stereo/bell*
 /usr/share/sounds/freedesktop/stereo/bell.oga

Ah, good.

Just ensure the application can manage that kind of .oga audio files.

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jqqd45$dr8$6...@dough.gmane.org