From owner-freebsd-arch@freebsd.org Fri Jun 15 16:03:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC591010DA5 for ; Fri, 15 Jun 2018 16:03:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 555E2750F7 for ; Fri, 15 Jun 2018 16:03:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 7797510AFCD for ; Fri, 15 Jun 2018 12:03:27 -0400 (EDT) Subject: Re: upstream for contrib/tzcode/stdtme? To: freebsd-arch@freebsd.org References: From: John Baldwin Message-ID: Date: Fri, 15 Jun 2018 09:03:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 15 Jun 2018 12:03:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:03:28 -0000 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