upstream for contrib/tzcode/stdtme?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

upstream for contrib/tzcode/stdtme?

Eitan Adler-4
What's the upstream for contrib/tzcode/stdtme?

There are a couple of PRs for it and I'd like to either update, fix
upstream, or move to non-contrib & fix.

--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Pedro Giffuni-4
> What's the upstream for contrib/tzcode/stdtme?
>
> There are a couple of PRs for it and I'd like to either update, fix
> upstream, or move to non-contrib & fix.
>
> --
> Eitan Adler
Hi,

I think it's here

https://www.iana.org/time-zones

or here (depending on how much bleeding edge you want to go):

https://github.com/eggert/tz

I recall we have old versions of the same files in libc too, plus some
modifications we got from Apple and Illumos.

NetBSD also has some updates of their own.

Pedro..

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Warner Losh
On Sun, Jun 10, 2018, 8:05 PM Pedro Giffuni <[hidden email]> wrote:

> > What's the upstream for contrib/tzcode/stdtme?
> >
> > There are a couple of PRs for it and I'd like to either update, fix
> > upstream, or move to non-contrib & fix.
> >
> > --
> > Eitan Adler
> Hi,
>
> I think it's here
>
> https://www.iana.org/time-zones
>
> or here (depending on how much bleeding edge you want to go):
>
> https://github.com/eggert/tz
>
> I recall we have old versions of the same files in libc too, plus some
> modifications we got from Apple and Illumos.
>
> NetBSD also has some updates of their own.
>

Plus some fixes of our own...

Warner

Pedro..
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Mehmet Erol Sanliturk
In reply to this post by Pedro Giffuni-4
On Mon, Jun 11, 2018 at 5:04 AM, Pedro Giffuni <[hidden email]> wrote:

> What's the upstream for contrib/tzcode/stdtme?
>>
>> There are a couple of PRs for it and I'd like to either update, fix
>> upstream, or move to non-contrib & fix.
>>
>> --
>> Eitan Adler
>>
> Hi,
>
> I think it's here
>
> https://www.iana.org/time-zones
>
> or here (depending on how much bleeding edge you want to go):
>
> https://github.com/eggert/tz
>
> I recall we have old versions of the same files in libc too, plus some
> modifications we got from Apple and Illumos.
>
> NetBSD also has some updates of their own.
>
> Pedro..
>
> _______________________________________________
>
>


In page


https://data.iana.org/time-zones/tz-link.html
( Sources for time zone and daylight saving time data )


the following is written :


"
Changes to the tz database
The tz code and data are by no means authoritative.
If you find errors, please send changes to [hidden email], the time zone
mailing list.
You can also subscribe to it and browse the archive of old messages.

"


Mehmet Erol Sanliturk
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Philip Paeps
In reply to this post by Eitan Adler-4
On 2018-06-10 21:40:21 (+0200), Eitan Adler wrote:
> What's the upstream for contrib/tzcode/stdtme?

https://www.iana.org/time-zones (and https://github.com/eggert/tz).

> There are a couple of PRs for it and I'd like to either update, fix
> upstream, or move to non-contrib & fix.

I've started updating it several times but the rather awkward layout of
the vendor tree makes doing just about anything else more attractive. :)

More than happy to review an update if you actually manage to complete
one!

I wonder if we should just make the "moving around files" in the vendor
tree go away...

Many thanks!
Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

John Baldwin
On 6/15/18 7:28 AM, Philip Paeps wrote:

> On 2018-06-10 21:40:21 (+0200), Eitan Adler wrote:
>> What's the upstream for contrib/tzcode/stdtme?
>
> https://www.iana.org/time-zones (and https://github.com/eggert/tz).
>
>> There are a couple of PRs for it and I'd like to either update, fix
>> upstream, or move to non-contrib & fix.
>
> I've started updating it several times but the rather awkward layout of
> the vendor tree makes doing just about anything else more attractive. :)
>
> More than happy to review an update if you actually manage to complete
> one!
>
> I wonder if we should just make the "moving around files" in the vendor
> tree go away...

I do think we should perhaps import the vendor tree to contrib/stdtime or
some such and then apply our local patches from libc to there.  Alternatively,
we could move the the files from libc into suitable locations in contrib/stdtime
and then do an 'svn merge --record-only' to bootstrap the vendor mergeinfo
for the current version and use that as a basis for updating?

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Eitan Adler-4
On 15 June 2018 at 09:03, John Baldwin <[hidden email]> wrote:

> On 6/15/18 7:28 AM, Philip Paeps wrote:
>> On 2018-06-10 21:40:21 (+0200), Eitan Adler wrote:
>>> What's the upstream for contrib/tzcode/stdtme?
>>
>> https://www.iana.org/time-zones (and https://github.com/eggert/tz).
>>
>>> There are a couple of PRs for it and I'd like to either update, fix
>>> upstream, or move to non-contrib & fix.
>>
>> I've started updating it several times but the rather awkward layout of
>> the vendor tree makes doing just about anything else more attractive. :)
>>
>> More than happy to review an update if you actually manage to complete
>> one!

I'll attempt one this weekend. :)

>> I wonder if we should just make the "moving around files" in the vendor
>> tree go away...

+1

> I do think we should perhaps import the vendor tree to contrib/stdtime or
> some such and then apply our local patches from libc to there.

I'd like to do the following:

- identify what local patches we have and divide them into two parts:
(a) issues already fixed upstream (b) issues not already fixed [or
local changes]
- import the latest stdtime into vendor
- copy from vendor into our contrib/stdtime without flattening the structure
- reapply all (b) patches manually

This will make the mergeinfo correct and also make it clear what
patches are local and what are upstream

>  Alternatively,
> we could move the the files from libc into suitable locations in contrib/stdtime
> and then do an 'svn merge --record-only' to bootstrap the vendor mergeinfo
> for the current version and use that as a basis for updating?

Exactly.



--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

John Baldwin
On 6/15/18 10:46 AM, Eitan Adler wrote:

> On 15 June 2018 at 09:03, John Baldwin <[hidden email]> wrote:
>> On 6/15/18 7:28 AM, Philip Paeps wrote:
>>> On 2018-06-10 21:40:21 (+0200), Eitan Adler wrote:
>>>> What's the upstream for contrib/tzcode/stdtme?
>>>
>>> https://www.iana.org/time-zones (and https://github.com/eggert/tz).
>>>
>>>> There are a couple of PRs for it and I'd like to either update, fix
>>>> upstream, or move to non-contrib & fix.
>>>
>>> I've started updating it several times but the rather awkward layout of
>>> the vendor tree makes doing just about anything else more attractive. :)
>>>
>>> More than happy to review an update if you actually manage to complete
>>> one!
>
> I'll attempt one this weekend. :)
>
>>> I wonder if we should just make the "moving around files" in the vendor
>>> tree go away...
>
> +1
>
>> I do think we should perhaps import the vendor tree to contrib/stdtime or
>> some such and then apply our local patches from libc to there.
>
> I'd like to do the following:
>
> - identify what local patches we have and divide them into two parts:
> (a) issues already fixed upstream (b) issues not already fixed [or
> local changes]
> - import the latest stdtime into vendor
> - copy from vendor into our contrib/stdtime without flattening the structure
> - reapply all (b) patches manually
>
> This will make the mergeinfo correct and also make it clear what
> patches are local and what are upstream
>
>>  Alternatively,
>> we could move the the files from libc into suitable locations in contrib/stdtime
>> and then do an 'svn merge --record-only' to bootstrap the vendor mergeinfo
>> for the current version and use that as a basis for updating?
>
> Exactly.

I think this second approach is actually a better plan and is not quite what you
were suggesting.

That is, import the vendor bits corresponding to our existing code first into
the vendor area, then svn cp our existing files from libc, zic, etc. into the
contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only'
merge to initialize the vendor mergeinfo.  At that point you should be able to
svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local
changes we have and start to think about them.  It also means that svn merge will
consider them during your merge to the newer vendor sources without you have to
manually apply patches in (b) while also preserving the commit history of those
patches.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

Eitan Adler-4
On 15 June 2018 at 11:31, John Baldwin <[hidden email]> wrote:

> I think this second approach is actually a better plan and is not quite what you
> were suggesting.
>
> That is, import the vendor bits corresponding to our existing code first into
> the vendor area,

 > then svn cp our existing files from libc, zic, etc. into the
> contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only'
> merge to initialize the vendor mergeinfo.
> At that point you should be able to
> svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local
> changes we have and start to think about them.

At this point both vendor and contrib have the same files, same
layout, but possibly different content?

How do we do the update itself then? "svn merge" from the vendor area
into contrib?






--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: upstream for contrib/tzcode/stdtme?

John Baldwin
On 6/15/18 4:09 PM, Eitan Adler wrote:

> On 15 June 2018 at 11:31, John Baldwin <[hidden email]> wrote:
>
>> I think this second approach is actually a better plan and is not quite what you
>> were suggesting.
>>
>> That is, import the vendor bits corresponding to our existing code first into
>> the vendor area,
>
>  > then svn cp our existing files from libc, zic, etc. into the
>> contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only'
>> merge to initialize the vendor mergeinfo.
>> At that point you should be able to
>> svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local
>> changes we have and start to think about them.
>
> At this point both vendor and contrib have the same files, same
> layout, but possibly different content?

Yes.  The different content would be our local changes.

> How do we do the update itself then? "svn merge" from the vendor area
> into contrib?

Yes, just like a normal vendor update.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"