Bug 858735 - Revert timezone file every glibc-common update
Summary: Revert timezone file every glibc-common update
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-19 14:22 UTC by Bastien Nocera
Modified: 2012-10-07 22:50 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-10-07 22:50:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Bastien Nocera 2012-09-19 14:22:35 UTC
glibc-common-2.16-15.fc18.x86_64
systemd-188-3.fc18.x86_64

glibc-common references /etc/sysconfig/clock in its post installation script[1], but systemd's timedated mechanism uses /etc/timezone.

[1]: http://pkgs.fedoraproject.org/cgit/glibc.git/tree/glibc.spec#n1176

This means that changing the timezone through GNOME System Settings' will update /etc/timezone and /etc/localtime correctly, but glibc-common will overwrite /etc/localtime according to /etc/sysconfig/clock on every upgrade.

For example, on this system installed with the Europe/London timezone, later changed to Europe/Paris through GNOME's systems settings (so through timedated):

$ cat /etc/sysconfig/clock 
# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.
ZONE="Europe/London"

$ cat /etc/timezone 
Europe/Paris

$ ls -l /etc/localtime 
0 lrwxrwxrwx. 1 root root 32 Sep 19 13:55 /etc/localtime -> /usr/share/zoneinfo/Europe/Paris

$ sudo yum -y reinstall glibc-common
Plugins carregados: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Resolvendo dependências
--> Executando verificação da transação
---> O pacote glibc-common.x86_64 0:2.16-15.fc18 será Reinstalado
--> Resolução de dependências finalizada
<snip>
Instalados:
  glibc-common.x86_64 0:2.16-15.fc18                                                                                                                   

Concluído!

$ ls -l /etc/localtime 
0 lrwxrwxrwx. 1 root root 33 Sep 19 15:08 /etc/localtime -> /usr/share/zoneinfo/Europe/London

Comment 1 Jakub Jelinek 2012-09-19 14:28:27 UTC
Sounds like systemd screwup to me.

Comment 2 Jeff Law 2012-09-19 15:35:11 UTC
/etc/localtime is owned by glibc and shouldn't be modified by other utilities.  The right file for them to be updating is /etc/sysconfig/clock.

Comment 3 Bastien Nocera 2012-09-19 17:12:12 UTC
(In reply to comment #2)
> /etc/localtime is owned by glibc and shouldn't be modified by other
> utilities.  The right file for them to be updating is /etc/sysconfig/clock.

And what will update /etc/localtime once I've changed /etc/sysconfig/clock?

Comment 4 Lennart Poettering 2012-09-19 17:52:30 UTC
I was not aware that glibc is fiddling with /etc/localtime. 

We are trying to move everything over to use /etc/localtime now, and read /etc/sysconfig/clock only for compat reasons, but never update it.

Jakub, can I convince you to drop the code %post code that overwrites the /etc/localtime symlink?

Comment 5 Jeff Law 2012-09-19 18:33:25 UTC
Lennart,

If y'all want systemd to own /etc/localtime, that's fine with me.  It's a bit of a PITA anyway and I'm happy to drop it out of glibc.

Let me know when you've updated systemd to own that file and I'll update glibc appropriately.

jeff

Comment 6 Jakub Jelinek 2012-09-19 18:38:06 UTC
But note that you'll then need to deal with the upgrade consequences thereof, e.g. from the long times when /etc/localtime was a file copy instead of a symlink, so some %post needs to convert it from a file copy into a symlink depending on /etc/sysconfig/clock.  And tools that change only /etc/localtime and not /etc/sysconfig/clock should be fixed anyway.

Comment 7 Bastien Nocera 2012-09-19 21:07:39 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > /etc/localtime is owned by glibc and shouldn't be modified by other
> > utilities.  The right file for them to be updating is /etc/sysconfig/clock.
> 
> And what will update /etc/localtime once I've changed /etc/sysconfig/clock?

I'm guessing that the answer is "reinstall glibc-common" after having changed /etc/sysconfig/clock. Those who live in glasshouses shouldn't be throwing stones.

Comment 8 Lennart Poettering 2012-09-20 19:49:12 UTC
(In reply to comment #5)
> Lennart,
> 
> If y'all want systemd to own /etc/localtime, that's fine with me.  It's a
> bit of a PITA anyway and I'm happy to drop it out of glibc.
> 
> Let me know when you've updated systemd to own that file and I'll update
> glibc appropriately.

I have now updated the RPM to take possession of /etc/localtime and to implement the symlink migration logic. It's in bodhi for F18 (systemd-190).

Comment 9 Fedora Update System 2012-09-20 19:57:16 UTC
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18

Comment 10 Lennart Poettering 2012-09-20 19:59:22 UTC
I have also filed bugs against system-config-date and anaconda to stop creating /etc/sysconfig/clock.

Comment 11 Jeff Law 2012-09-20 21:01:32 UTC
Excellent.  From looking at the glibc.spec file something should own updating /var/spool/postfix/etc/localtime as well, presumably systemd.  As far as I can tell, it should be a copy of /etc/localtime.

I've got fresh glibc builds spinning.

Comment 12 Bastien Nocera 2012-09-20 22:08:21 UTC
(In reply to comment #11)
> Excellent.  From looking at the glibc.spec file something should own
> updating /var/spool/postfix/etc/localtime as well, presumably systemd.  As
> far as I can tell, it should be a copy of /etc/localtime.
> 
> I've got fresh glibc builds spinning.

Should probably be in the same update as systemd.

Comment 13 Jeff Law 2012-09-21 20:16:01 UTC
Agreed.  I've never had to issue an update with multiple packages.  Do we just tack it on as another build to Lennart's existing update?  If so, the right build is glibc-2.16-17.fc18.

Comment 14 Fedora Update System 2012-09-22 06:38:20 UTC
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).

Comment 15 Lennart Poettering 2012-09-24 13:08:39 UTC
Added the glibc update to the bodhi ticket!

Thanks everybody!

Comment 16 Fedora Update System 2012-09-28 00:18:54 UTC
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2012-10-01 20:11:53 UTC
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).


Note You need to log in before you can comment on or make changes to this bug.