On Thu, 12 Jan 2023 14:41:19 +0000 Gary Jennejohn <ga...@gmx.de> wrote:
> On Thu, 12 Jan 2023 03:44:03 -0800 > David Wolfskill <da...@catwhisker.org> wrote: > > > On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote: > > > looks like we may need another 'unclean' workaround for this? > > > > > > Warner > > > > > > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn <ga...@gmx.de> wrote: > > > ... > > > > I had this problem also. After deleting obj/usr the buildworld > > > > succeeded. > > > > > > > .... > > > > Empirically: > > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic > > > > got through the issue on my build machine. (I expect that it will also > > do so on the others where I track head, but they are presently building > > lang/rust.) > > > > Perhaps an UPDATING entry would suffice? > > > > Didn't work for me when I decided to update my laptop, which had rather > old /usr/src contents. I ended up deleting obj/usr again. > > I installed the new world on my tower this morning. Now I see a new > problem. > > I don't know whether this new problem is related to the new tzcode, but > apps like gkrellm2 and xclock now display the time one hour earlier > than the actual time output by date(1), e.g. 10AM rather than 11AM. > > I had to set my /etc/localtime to GMT+0 to get the correct time output > even though I live in Germany and the correct value would be either > Europe/Berlin or CET. > > My laptop, which still has the old tzcode installed, did not exhibit > that weird error. > > -- > Gary Jennejohn Do you have /etc/wall_cmos_clock? Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC. A blank file (just `touch`ed to create) is enough. IIUC, your laptop has it, but your tower has none. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
