From owner-freebsd-arch@freebsd.org Tue Oct 20 04:47:08 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DEF7244548A for ; Tue, 20 Oct 2020 04:47:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFh1S0W4mz3WFk for ; Tue, 20 Oct 2020 04:47:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id f21so528650qko.5 for ; Mon, 19 Oct 2020 21:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BT/4IaHVkPSs3EBgxtyczKm7vOSKUp4NMKpVcZgsj/M=; b=aliKHL9MKUjF6R46Yk8npbQ62OFFOnq4bb31LUdEACF89QZ63T6ymiL3nnqIUOm6ON lvnSfU8vvHDMYnCKi2xZuqYPJHFjsZtQjMB1hsTmKZ7p7b0Rsqmj5qKgxWtK/sjrJfs8 1vJP3ZOQ2RP3vbJkYAa5q+z6tL0aysHYkFJ/PKnDIKPvDvfWcLQm1GMvmINJ09mwcx31 8a4pzz9EQGR+bp0MzboOutnF4XWsyc+3ivoWDM2pNNCr4W6/21P5O6FE/NuKc5B578AQ sG9yPIfdgmRkJEmaBgn7iAKiVtxHzYFk1irvb0gVPDptyW1nQkM2PkBfcKD2JvYKxe1s I+AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BT/4IaHVkPSs3EBgxtyczKm7vOSKUp4NMKpVcZgsj/M=; b=Z/aQOgYU4+y9AfDX9c/qZZHp0jUhfvGBAuzHo1p9Rmur9O4/HD7Acaie3HQY99hiDM XFhLkpKeutm58sytBN92FSYdEhHmABUHlEvVKJzgNyKOx/UsBbMB5XFKW6oHblKk05eU Ewj01RJCOqRkfvD2oltMvvpp6EJMLlkT1n7cDC+1GmLUuswG91s8V6s5ut0ILlD26OMo WExslkG2gBlYMgHMAksDPNGqA2cQU+vu6DGChSscw7Mtk8gkLudNmvoGMIcBU3vlpzTd wScnZ0MopY/EcOarmOjvKhFQxpdYkyFKb/jKYollSIxLhEeJhsuiaT94WCMVKJvMjrt9 p6wA== X-Gm-Message-State: AOAM531CbMOunuWxQqb+TR1cKRA6tXP/r6rWtL2p2lskCJePXSXzugF0 EnqObNh6+49ygHapd24m/QNn4VcqLMTW/qC3WcaS7g== X-Google-Smtp-Source: ABdhPJxd0Syx14Dpr6y7rxdKzG50AKPNIzk4e7vRvz3pH7oJYxSY41ODbAPVF/pB4MJoEczxowEp9/4Ub97uC/PXqpY= X-Received: by 2002:a37:5ca:: with SMTP id 193mr1151348qkf.44.1603169226766; Mon, 19 Oct 2020 21:47:06 -0700 (PDT) MIME-Version: 1.0 References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> In-Reply-To: <20201020035420.GA59361@eureka.lemis.com> From: Warner Losh Date: Mon, 19 Oct 2020 22:46:56 -0600 Message-ID: Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: "Greg 'groggy' Lehey" Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 4CFh1S0W4mz3WFk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=aliKHL9M; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.956]; NEURAL_HAM_LONG(-1.00)[-1.002]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; NEURAL_HAM_SHORT(-0.82)[-0.819]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arch] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 04:47:08 -0000 On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey wrote: > This discussion, from a month ago, seems to have died a death. First I'll > summarize what imp@ says: > > On Wednesday, 23 September 2020 at 9:18:27 -0600, Warner Losh wrote: > > > > 1. I'll do for calendar what I did for CTM. We'll split it out into its > own > > git repo. git filter-patch is straight-forward to use, but has a number > of > > caveats with the imperfect github mirror we have. I'll do it against the > > beta cgit mirror and write up the process since I'm pretty sure people > will > > want to replicate it in the future. > > 2. Delete the contentious bits (details to follow) > > 3. Adjust the build (since calendar uses cpp to build up its databases) > > 4. Prune the new repo to just the contentious bits into that repo (likely > > under github.com/freebsd/calendar, like we've done for CTM and other > things) > > 5. Create a port you can optionally install > > 6. Adjust calendar to work when things are there (or not there) > > 7. Remove the contentious bits from FreeBSD... > > This shows the procedural approach. But what do we really want? I > think that we should agree that we don't want to remove functionality, > just bring things into the 21st century. As I see it, there are three > approaches: > > 1. Nobody cares enough about it, so leave it as it is. > > Given the lack of input on the subject, this might be the best > choice. It's certainly the easiest. But it leaves a lot of dead > wood and unbalanced and incorrect content. > Nah, people want the crusty old files of it gone. Trust me. > 2. Move the non-FreeBSD related stuff into a port. This is imp@'s > approach above. As you can see, it's rather involved, and it seems > to me that we shouldn't be doing this sort of thing until we've > moved the project to git and the dust has settled. It also > complicates maintenance, and it doesn't address the dead wood and > dubious content. > It's actually not all that involved. I've done it before for CTM and it's about 1/2 hour of work to pull all the history along. 0 hours of work if you don't care about the history. It actually goes hand in hand with #3 below. > 3. Create a separate port that sucks in and maintains suitable > calendar entries from *somewhere* and maintain a directory > hierarchy, say /usr/local/calendar, in the same form as the current > /usr/share/calendar. Modify the calendar(1) in the tree to look at > this hierarchy as well. /usr/share/calendar should remain for the > few FreeBSD-related files (as far as I can tell, only > calendar.freebsd). > Yea, I think you're right. The FreeBSD one is the interesting bit to the project, and there's enough people that have .calendar files to make it interesting to stay in base. Were it not for this FreeBSD connection, maybe it could just live entirely in ports. Calendar has been around since 7th Edition Unix, so there's history there as well, though that seems less important these days. The calendar.usholiday isn't too bad. It could remain too. It's super short and the only tweaking needed would be when the times change. It might make sense to do one for eu and asia too that list the major holidays elsewhere given how connected the world is. Then again, that may be a bit beyond the remit of the current system too, but we're a world-wide group that could easily crowd source this. The current calendar.holiday is way too obscure and bizarre, though some people like it. > This would be my preferred approach. The issue is identifying > *somewhere*. I've done a bit of searching on the web, and I've > found lots of "on this day" sites, but nothing that would easily > lend itself to conversion to calendar(1) files of the kind I'm > looking for. Input here would be welcome. > Ah, that's a second problem. But let's not get bogged down in solving that and then fail to do the split properly. Let's get things split, let's move the database to ports. Unless it's really so awful as to not be worth the move. Then this whole problem boils down to just removing usr.bin/calendar/calendars (except for calendar.freebsd), and then working offline on pulling stuff in via the net somehow. Warner