[bug#28977] [PATCH] gnu: tzdata: Update to 2017c.

[bug#28977] [PATCH] gnu: tzdata: Update to 2017c.

[Leo Famulari]

* gnu/packages/base.scm (base)[tzdata): Update to 2017c.
---
 gnu/packages/base.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 9cb628d8d..87edfe1c6 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -1023,7 +1023,7 @@ command.")
 (define-public tzdata
   (package
     (name "tzdata")
-    (version "2017b")
+    (version "2017c")
     (source (origin
              (method url-fetch)
              (uri (string-append
@@ -1031,7 +1031,7 @@ command.")
                    version ".tar.gz"))
              (sha256
               (base32
-               "11l0s43vx33dcs78p80122i8s5s9l1sjwkzzwh66njd35r92l97q"))))
+               "02yrrfj0p7ar885ja41ylijzbr8wc6kz6kzlw8c670i9m693ym6n"))))
     (build-system gnu-build-system)
     (arguments
      '(#:tests? #f
@@ -1079,7 +1079,7 @@ command.")
                                 version ".tar.gz"))
                           (sha256
                            (base32
-                            "0h1d567gn8l3iqgyadcswwdy2yh07nhz3lfl8ds8saz2ajxka5sd"))))))
+                            "1dvrq0b2hz7cjqdyd7x21wpy4qcng3rvysr61ij0c2g64fyb9s41"))))))
     (home-page "https://www.iana.org/time-zones")
     (synopsis "Database of current and historical time zones")
     (description "The Time Zone Database (often called tz or zoneinfo)
-- 
2.14.3

[bug#28977] tzdata updates and package rebuilding guidelines

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

When splitting tzdata into two packages, one for "real" use and one for
test suites, I'd hoped it would allow us to update tzdata immediately
after new versions were released.

But, there are still way more than 300 packages depending on tzdata, so
it should be updated on a staging branch:

$ guix refresh -l -e '(@@ (gnu packages base) tzdata)'      
Building the following 335 packages would ensure 635 dependent packages are rebuilt ...

According to NEWS, if we don't update tzdata soon, some time zones will
first become incorrect in Northern Cyprus in 5 days.

"Northern Cyprus switches from +03 to +02/+03 on 2017-10-29"

Any advice? Should we do a staging build? Just be late (the old status
quo)? Something else?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#28977] tzdata updates and package rebuilding guidelines

[Ludovic Courtès]

Hi Leo!

Leo Famulari <leo@famulari.name> skribis:

> When splitting tzdata into two packages, one for "real" use and one for
> test suites, I'd hoped it would allow us to update tzdata immediately
> after new versions were released.
>
> But, there are still way more than 300 packages depending on tzdata, so
> it should be updated on a staging branch:
>
> $ guix refresh -l -e '(@@ (gnu packages base) tzdata)'      
> Building the following 335 packages would ensure 635 dependent packages are rebuilt ...
>
> According to NEWS, if we don't update tzdata soon, some time zones will
> first become incorrect in Northern Cyprus in 5 days.
>
> "Northern Cyprus switches from +03 to +02/+03 on 2017-10-29"

Interesting.

> Any advice? Should we do a staging build? Just be late (the old status
> quo)? Something else?

I think we should identify those packages that unduly refer to ‘tzdata’
instead of ‘tzdata-for-tests’ and incrementally fix them.

In the meantime, I think this patch can go to ‘staging’ and/or
‘core-updates’ (which we should try building anytime now!).

How does that sound?

Thank you,
Ludo’.

bug#28977: tzdata updates and package rebuilding guidelines

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Wed, Oct 25, 2017 at 10:12:08PM -0700, Ludovic Courtès wrote:
> I think we should identify those packages that unduly refer to ‘tzdata’
> instead of ‘tzdata-for-tests’ and incrementally fix them.

I think we've fixed all the improper uses of tzdata, although perhaps
some of the remaining users of 'tzdata' could find the time zone
database in the environment at run-time somehow.

Maybe we can revisit the rebuilding guidelines when the build farm is
more powerful for all architectures.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]