From owner-freebsd-arch@freebsd.org Tue Oct 20 03:54:28 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 70E7F444544 for ; Tue, 20 Oct 2020 03:54:28 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFfrg4s8Wz3THg for ; Tue, 20 Oct 2020 03:54:27 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 43D8928118 for ; Tue, 20 Oct 2020 03:54:21 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 8F10326359C; Tue, 20 Oct 2020 14:54:20 +1100 (AEDT) Date: Tue, 20 Oct 2020 14:54:20 +1100 From: Greg 'groggy' Lehey To: "freebsd-arch@freebsd.org" Subject: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020035420.GA59361@eureka.lemis.com> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CFfrg4s8Wz3THg X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [1.85 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.42)[-0.418]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(0.84)[0.841]; NEURAL_SPAM_SHORT(0.12)[0.125]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US] 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 03:54:28 -0000 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. 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. 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). 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. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA 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 From owner-freebsd-arch@freebsd.org Tue Oct 20 12:28:48 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 8C1744302DB for ; Tue, 20 Oct 2020 12:28:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 4CFtG73wmRz4GST for ; Tue, 20 Oct 2020 12:28:47 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-il1-x141.google.com with SMTP id g7so1910718ilr.12 for ; Tue, 20 Oct 2020 05:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TWDfq81tH3uIJim+rDYqmyaFF2Tefgqd9WtaYxBBNok=; b=OCLy9+iHEsSbL4xr3k7DFFE4CNc3VtljWhV+VV83WpLKumejU0wo24zLtD6Ifepxns yNfbF5AzC3yeNZMIQTErKKbgRl7J1yBgOt7/AIr6VAO2XQHIB9OrmAqUaehIOM6IC/bv aTmW0AGElIdgChsz+QxyHv6Atnuau21dV6fCdyeo3M27+nUZhQd3AXKE8iWbzL2+3uta Nu3xafgLLEWBy1CYEo6Yr7J1iTR3l/a5si/lUDyscWkPwiTvcD4ORkOvZUhruNQkYLsP qQf7X8OzZ3Z3Utfah6c/zuOYpx+Qjtx5Y/9Pj2j+y5JLLgom4ufHpI+AZ+fXoUvRks4R B17Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TWDfq81tH3uIJim+rDYqmyaFF2Tefgqd9WtaYxBBNok=; b=S5qctIYX8j0fmY07nvil3OyANga/1/fCwCZOS2UFEiahTvA6lROsP3LBUWeRAtGSfY WVq2UMlzuMOO2IeX1aAYRSOVBJnErZwnb2qQBgGPGuM+/vjVJikZ6ORcNXKkuG91szC+ fl3tjP9itjCU8qOTDv39Mul/wfBSXYfe6/BR4MWvE7f4nI64fTvfxlP8xQpsvmB2LyrF psA2a3yDvyZxHJGWt3kETAYFPHuBtuLhd9yBtB3e+plgROoRjxI6b6WYAJCQ8lThqWlV OpbdsS86P7gWFuHj6ivfcGZZwglBQJok+tbk0VqcX1RdoYQ61Mcqp1VMd/viyc4RSyEq Ktrw== X-Gm-Message-State: AOAM531N1rigPMPsqhfgneQOW9+eM0l8y2t85IlJEMQwxuylueACl2gp Mw0ynliSvJaTOxzbR+TZvbRcuP/OcgPu1eLK X-Google-Smtp-Source: ABdhPJzqutqGKuwfJNF6pa4Hw8ny4qNSCqEu5G4LaWXFWpzIo0uVHflW4RTBDSUXDOy/3n9BhznRwg== X-Received: by 2002:a92:d84a:: with SMTP id h10mr1820926ilq.39.1603196926422; Tue, 20 Oct 2020 05:28:46 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-222-53.bltmmd.fios.verizon.net. [100.16.222.53]) by smtp.gmail.com with ESMTPSA id y26sm1521436iol.24.2020.10.20.05.28.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 05:28:45 -0700 (PDT) Date: Tue, 20 Oct 2020 08:28:44 -0400 From: Shawn Webb To: Warner Losh Cc: Greg 'groggy' Lehey , "freebsd-arch@freebsd.org" Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yd7muuql7o5fjjq2" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4CFtG73wmRz4GST X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=OCLy9+iH; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::141 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.83 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.73)[-0.728]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.222.53:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::141:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] 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 12:28:48 -0000 --yd7muuql7o5fjjq2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 19, 2020 at 10:46:56PM -0600, Warner Losh wrote: > On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey > wrote: >=20 > > 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 i= ts > > own > > > git repo. git filter-patch is straight-forward to use, but has a numb= er > > 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 database= s) > > > 4. Prune the new repo to just the contentious bits into that repo (li= kely > > > 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. > > >=20 > Nah, people want the crusty old files of it gone. Trust me. >=20 >=20 > > 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. > > >=20 > 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. >=20 >=20 > > 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). > > >=20 > 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, may= be > 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. Note that the history of the calendar files is retained in the src repo, so nothing there is lost with regards to tracing the history to "back in old country." Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --yd7muuql7o5fjjq2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl+O1/oACgkQ/y5nonf4 4fo9gBAAhlfN572B2QO9v1uqUgLfl1Wr4ZaxEFlna2d9okzGWSZp48iehJjRz37E t3/l1vL9kOonqXVyfdIuEHYevMW8T6+/i7xydLMv+3fE5PNl7PQbonTrBD/qxmq3 Y7fnZoOCSCoxltk1qX5iD2ASMgTdirJjOV4aQ+8LmMFgBJaC8uN9gMsBF88JUy4x OjdnrLX5P0n7RoSHlELTRkMYOc7aSPDhS9kyPiLA1Yr52DYtKvr5v68VUh1XQjAK RdIOo4XAROD6dS7Qow+ouLhkQA0FYLGWv2zeBUoO0dU60WMfge4vpIuh247v5NLi /6VzpzREe6+y1gfJHPtIS9hsw/Z8ScIaGATDoar7hxCUOjrFRVR8P2306DuDqR5t rjSA9FzTpHQo2FDn4sBE7X5+wq9SRdurN6n8aKzyXAB7DCl0xdyt6XYn1Zql8CyZ kMov26XJtaGtmLMaFO6LbDjL4gdJZczRSjCn/M/7BObvpElTaXeznbh0SiHe+WBC GHbxbhWOGs90bTeTavmrvFN0+RRfDfGEg5/J9ldkWUW1b8or0LnXzDQlG2VuIfut 5Lrxob6RHPAp/T3MjkJ5Y3ELhSAaLZdCT9rfN+YtD96NnIglXGKFbZvDTNQ9awVF sF/bzSbiW497DX+QPUwVoEirqXk5rtl8wXRKhLUk+eilI9dqvaw= =TkkW -----END PGP SIGNATURE----- --yd7muuql7o5fjjq2-- From owner-freebsd-arch@freebsd.org Tue Oct 20 16:00:20 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 5C5144347BC for ; Tue, 20 Oct 2020 16:00:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 4CFyyC4XbNz4SJQ for ; Tue, 20 Oct 2020 16:00:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf33.google.com with SMTP id w5so1065541qvn.12 for ; Tue, 20 Oct 2020 09:00:19 -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=DirKVVmq5lPJtBfEvb2sAD2bPCdOWVAHZpJ7yz93GEo=; b=zrLyvjLEegKU79mptdaIXa+gtwIJt3NKzrX/m0n8RPnGriQ4j+HoBJRkMfGgwcbMpv O5H65vt3uCpoB72umytPajV13ejVBd7gPL4jDTrfGHeDT/gcRj7Eeb3WkB4AeZLYo690 fUTaAZ6/IVX/Xmca3tM9X8Znrhz+z0nRRBvfiDFAqHTaSMx5/6FajmzDzNt5Fhwmmiix Wh0jo+/d6BzsFLAsDcmuIK123hG4H+wZSmBoH40bF6Zmh19GHhF/zs6F7oYf+nkhWOWq CKPhlvKJoRiX9LTA17GQDZs1m0T58Lbjs7OciaUGfftgirNH56RcTfuxrEe/CmVJSheS 8zDA== 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=DirKVVmq5lPJtBfEvb2sAD2bPCdOWVAHZpJ7yz93GEo=; b=YQa6NUUyUqtp240imZKcJ2nlAFt/nY3HLu7d/h729QKLFtWwmMf25m3ZLdao5o7HIl g2B3JVlUEOejgPGDK7KQ1rqMAw3duCogltYZty/kUXvEFWLeNOJeErLecUBQZyNYYSd9 yllBPNiWSnvioVuYqZ8nUazdTKbZfal/zy5BlQYlkKu46WZPZDJgrAIkov/mKyLdxh3T edrjGTYxDKBtvjduwzqFfjJKktCZIxD0EwK1zRf6gXRSEeIaVioaMGeov9P0TaN8J9at PtC9qayMSoeYrII/HYOZ4uB++yeRVCfAqL1e6NGdlbD0M5HBSiiJTZaF7rByPWA9Y9zY UP9w== X-Gm-Message-State: AOAM533DOTacf9k1xHqNmbICL4mJ6ae7ZMPUwNSUdFObOybr7Dnayf2c Hg2L/bV0n9vWXJdjXsHHkYM47aZUPV4gzn7N+1xbKA== X-Google-Smtp-Source: ABdhPJzuLHPAgcBy9lFCxB5aYBMjiBd2YiEcJqRbGSpZfKqzgxQWTQnZ0hHwfhfhb0I+47TRVHYmEkonI3g0qVlch0Y= X-Received: by 2002:a0c:e403:: with SMTP id o3mr3954470qvl.23.1603209618131; Tue, 20 Oct 2020 09:00:18 -0700 (PDT) MIME-Version: 1.0 References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> In-Reply-To: <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> From: Warner Losh Date: Tue, 20 Oct 2020 10:00:06 -0600 Message-ID: Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: Shawn Webb Cc: "Greg 'groggy' Lehey" , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 4CFyyC4XbNz4SJQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=zrLyvjLE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.89)[-0.886]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.003]; 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:+]; NEURAL_HAM_SHORT(-0.06)[-0.061]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f33:from]; 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:~]; 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]; RCVD_COUNT_TWO(0.00)[2] 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 16:00:20 -0000 On Tue, Oct 20, 2020, 6:28 AM Shawn Webb wrote: > On Mon, Oct 19, 2020 at 10:46:56PM -0600, Warner Losh wrote: > > 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. > > Note that the history of the calendar files is retained in the src > repo, so nothing there is lost with regards to tracing the history > to "back in old country." > It's trivial to extract, though... so there's no need to argue to have the best of both worlds. But the bigger point I'm making is that the calendar.freebsd file is more central to the project and there has been a large desire expressed to keep that bit in base. Warner Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > From owner-freebsd-arch@freebsd.org Tue Oct 20 16:03:04 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 5CBB9434A08 for ; Tue, 20 Oct 2020 16:03:04 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 4CFz1M2RpLz4SkQ for ; Tue, 20 Oct 2020 16:03:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-il1-x143.google.com with SMTP id n5so2956271ile.7 for ; Tue, 20 Oct 2020 09:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gL8y1j++KyKtUKGk4c6jh0qEka86CRQVfmHi7ZJi8II=; b=KMD/cshBjtDMJcOrfXl3ravitvMrp3Y4lQEcVLWIk19ZhhVvW0Di1ddfFb66u9XbSs l5XRmB/cjYOeJVDvdtWeRgWxnLo9BSDAHhl45BzLEj9v/8SODSC9kO+ycU/1VPE9DL+F z3i1jgz/F7EIblp9lBrTeyRty7L7GHIW6T4udQO6yPhmdNv0QJpd3CA/JAMzZGhBleSi Dr1wZCAZWgDLwBw4Dmi/KDbcOgqX2sFwxUvWGOqWlMtZ6rfz3emEikGH/fPbuOdE4/v0 LbbDZnYSniwG+xXwtQCU5ehuwgFb37P/mnpqDiIIF9RFFEvs/5Kbiun/alXFhLl6QAhJ muqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gL8y1j++KyKtUKGk4c6jh0qEka86CRQVfmHi7ZJi8II=; b=Y0a352ohUhjg6vqODEsf0j0IvG4tD6bQd+cBYwwDkHwaWHB5262dr7a3R4+3VczR3w zBqvMDaDYBpjj/eKXzV9B6zfMLiulGz2xD7BTUeuFt76raTLBx12I0SNYboGsOdY4BMy /MvtPd8IqkaL9d9+Uct4k0Aq/MkWjqPhgejtquuWt6mErmjRrSK1NN8WveIPUDFKlvaa MACg51xx2IPqNDer3WQco68tGyb71p5rGg/euy4lopb1Uh/y4gM+gkQpriJSrU0P+304 xnFOj+/x9VnV5d7RJe1VPEbMPb0DjYKpMqBBuz7ti5z3eL00tL5IIcwzzw5ievb+MnHi 8wXA== X-Gm-Message-State: AOAM531Cnt6dNr4Y67djOKYCwRa+RU14SmeNy1AQXsLCYIcryhGailzl p+gKOHxI4CW7GN+hjBg3PG2ESw== X-Google-Smtp-Source: ABdhPJzthRna1qM7WZhfiCimy2Ki1Bhv6B4YePsGKzuBuX9JYS6sW0v+yU+BdZvL97coNwPDoDXusg== X-Received: by 2002:a92:3650:: with SMTP id d16mr2520832ilf.29.1603209781977; Tue, 20 Oct 2020 09:03:01 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-222-53.bltmmd.fios.verizon.net. [100.16.222.53]) by smtp.gmail.com with ESMTPSA id u8sm2385588ilc.59.2020.10.20.09.03.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 09:03:00 -0700 (PDT) Date: Tue, 20 Oct 2020 12:02:59 -0400 From: Shawn Webb To: Warner Losh Cc: Greg 'groggy' Lehey , freebsd-arch@freebsd.org Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020160259.aha7xzw73ipndgco@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="siqln3ognil72mfm" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4CFz1M2RpLz4SkQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=KMD/cshB; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::143 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.32 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.001]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.22)[-0.219]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::143:from]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.222.53:received] 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 16:03:04 -0000 --siqln3ognil72mfm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote: > On Tue, Oct 20, 2020, 6:28 AM Shawn Webb wro= te: >=20 > > On Mon, Oct 19, 2020 at 10:46:56PM -0600, Warner Losh wrote: > > > 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. Fir= st > > I'll > > > > summarize what imp@ says: > > > > > > > > On Wednesday, 23 September 2020 at 9:18:27 -0600, Warner Losh wrot= e: > > > > > > > > > > 1. I'll do for calendar what I did for CTM. We'll split it out in= to > > 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 agai= nst > > 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 ot= her > > > > 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 functionali= ty, > > > > just bring things into the 21st century. As I see it, there are th= ree > > > > 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 se= ems > > > > 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 curr= ent > > > > /usr/share/calendar. Modify the calendar(1) in the tree to look= at > > > > this hierarchy as well. /usr/share/calendar should remain for t= he > > > > 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. > > > > Note that the history of the calendar files is retained in the src > > repo, so nothing there is lost with regards to tracing the history > > to "back in old country." > > >=20 > It's trivial to extract, though... so there's no need to argue to have the > best of both worlds. >=20 > But the bigger point I'm making is that the calendar.freebsd file is more > central to the project and there has been a large desire expressed to keep > that bit in base. Yup yup. Agreed on all parts. :) --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --siqln3ognil72mfm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl+PCi8ACgkQ/y5nonf4 4fqX+Q//cBE3WeR9ZKBAlGpUHn2qdmhd3HIOq4LYjWmOHm1yq73dXcjtHkBlt8CR RDY43ynLb0IGGNxWhQUwuaWwNTgJfsy32uapZODyR45trR8nstAgQKXPq0gieLk9 ZJE6h3B2GvAijnpJtywqZ7X7mOm4Ux6e+NiVeDQkGAuFdJO0Wp534Wfe1Le6fRPo PL2b8pMrmG0AeSkukx1WAuaOwuGl0WB8Ysez1rbi1Md0NLycJgufcqIPesWCqYUJ 34JeSpbYSONsqz6C+Jxpqdh4e75jZG8yW3YQHCp9awdzi5BtenUzPDbd8jHaVJ3x uqM7tcGuMC1DlbPwBfE3LyAdFXSTK9sZVSJG4sFNJzrb67P//AH4w77ws1KoCel6 pV6haDgmROAUqblcv9yqrKP8YswQQF6jJUQBPAANMyA/dvEUjI7knQqpSxNzGyDn qEaNVrWGvLzdW3gutAZ+fsuPiMpRqfhy9zr62PPQdV+1ySnPksiDGrdgX4UW4B+7 j4Hj7UnVa+SXlNX0MG0vYps+ZRkHQ7TRS6WqJjSxg0h+XNnV+Vy+qlFgZG9MnhGr 5kLgEnysXPPAsfuBWAKlGlChrhSgEpJBMzT9801vbmMUgAkGvx26qJo4uGMDTO/N QJk04C1F4kHzPSNSQHHNWjj/4pndy/wNK9z75cQ8S9z39PXdFfg= =Hucw -----END PGP SIGNATURE----- --siqln3ognil72mfm-- From owner-freebsd-arch@freebsd.org Tue Oct 20 16:06:53 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 E227D4343EA for ; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFz5n5lswz4Shd; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p4fd3a1f5.dip0.t-ipconnect.de [79.211.161.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 22B0C23C7E; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Tue, 20 Oct 2020 18:06:52 +0200 From: Gordon Bergling To: Warner Losh Cc: Shawn Webb , Greg 'groggy' Lehey , freebsd-arch@freebsd.org Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020160652.GA42096@lion.0xfce3.net> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: X-Url: X-Operating-System: FreeBSD 12.2-STABLE amd64 X-Host-Uptime: 6:03PM up 5 days, 23:52, 5 users, load averages: 0.27, 0.21, 0.22 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 16:06:54 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote: > On Tue, Oct 20, 2020, 6:28 AM Shawn Webb wro= te: >=20 > > On Mon, Oct 19, 2020 at 10:46:56PM -0600, Warner Losh wrote: > > > 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. Fir= st > > I'll > > > > summarize what imp@ says: > > > > > > > > On Wednesday, 23 September 2020 at 9:18:27 -0600, Warner Losh wrot= e: > > > > > > > > > > 1. I'll do for calendar what I did for CTM. We'll split it out in= to > > 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 agai= nst > > 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 ot= her > > > > 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 functionali= ty, > > > > just bring things into the 21st century. As I see it, there are th= ree > > > > 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 se= ems > > > > 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 curr= ent > > > > /usr/share/calendar. Modify the calendar(1) in the tree to look= at > > > > this hierarchy as well. /usr/share/calendar should remain for t= he > > > > 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. > > > > Note that the history of the calendar files is retained in the src > > repo, so nothing there is lost with regards to tracing the history > > to "back in old country." > > >=20 > It's trivial to extract, though... so there's no need to argue to have the > best of both worlds. >=20 > But the bigger point I'm making is that the calendar.freebsd file is more > central to the project and there has been a large desire expressed to keep > that bit in base. >=20 > Warner Very well written! Thank you! --Gordon --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAl+PCv5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09y5BQf9Fo1fQheCdccnE5QvoxgJQDSxsVHBYYZE9L1sG21OsmeepGvfsaMAKm+b dJamD0xt824/aYN6n5EAwxLp2Ijwu+o5sH+/ESknZfRH5DZ4I/9e+2SCXakhLQJR kmDpE2eHLBzUs0QllK9/bUljUtZ/skh4o8UsqgIYjw4ukK+iPHMhusGGPeaVpxbw gYSwuBKpl+JgoxjTJyvKa5oZjTfAMRF9sYsI1bSa+TXmDQRo/HnBBDuPXwZy61uY pNRzMRLsENWbJ1q49Z8vYpwM1i4LffujUqcwMBUWyt1QLs+4N5Vax1q6U6Q2RqZG RPQBJUEPYiqlfNBYjYBz2MiJdg8gFA== =SYr8 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-arch@freebsd.org Wed Oct 21 01:23:26 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 CF1C443FAE0 for ; Wed, 21 Oct 2020 01:23:26 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGCRx71qBz3TZZ for ; Wed, 21 Oct 2020 01:23:25 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 422A627FF9; Wed, 21 Oct 2020 01:23:24 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 67C1C26359C; Wed, 21 Oct 2020 12:23:23 +1100 (AEDT) Date: Wed, 21 Oct 2020 12:23:23 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201021012323.GA59592@eureka.lemis.com> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CGCRx71qBz3TZZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.20 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.913]; NEURAL_HAM_LONG(-1.01)[-1.009]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.473]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] 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: Wed, 21 Oct 2020 01:23:26 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Irrelevant quotations trimmed] On Monday, 19 October 2020 at 22:46:56 -0600, Warner Losh wrote: > On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey wrote: >> 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. It seems that I'll have to. Nobody else has mentioned this recently, and we don't have enough clarity on what "crusty old files" means. > ... > >> 3. Create a separate port that sucks in and maintains suitable >> calendar entries from *somewhere* and maintain a directory >> hierarchy, say /usr/local/calendar, /usr/local/share/calendar, of course, as you mentioned elsewhere. >> 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). > > 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. That's the thin edge of the wedge. US holidays are of interest to a group that only partially overlaps with the FreeBSD community. > It might make sense to do one for eu and asia too that list the > major holidays elsewhere given how connected the world is. And forget Africa, most of America and Australia? > 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. That's the whole point. Where do we draw the line? Given that these holidays interest more people outside the project than in, I'd think that they should all go into the port. And the whole idea of alternative 3 is that the maintenance should be automatic and external, so updating holidays should no longer be our concern. >> 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. I don't understand your haste in wanting to do this. Until we don't know what we're going to do, we can't do the split properly. We've had calendar since the beginning of time, and suddenly it seems to need changing. Let's agree on what we want to do first. In the meantime, though, something else has occurred to me: at least get buy-in from the other BSD projects. I've just checked NetBSD, OpenBSD, Mac OS and Ubuntu (I think) Linux, and they all have the same structure. They also all have the same error that I fixed in FreeBSD a couple of days ago. I'm pretty sure that they're in the base system for the first three, since they're from a virgin installation. My guess is that they're also in the base system for Ubuntu, or whatever version I have access to. This issue is not important enough to take a knee-jerk approach. I'd rather see something that all the projects can use. In this connection, of course, GitHub sounds like a good potential start, but would the OpenBSD project (for example) buy in to it? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+PjYsACgkQIubykFB6QiMcOwCeL06XCLo+Cl4lGVrTbZsShN/Y OYMAnA3hy0hwHCixJ3MFA6MEXhP0IDaD =UXEC -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-arch@freebsd.org Wed Oct 21 07:15:17 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 CF76C444F23 for ; Wed, 21 Oct 2020 07:15:17 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGMFx4cPtz3ykt; Wed, 21 Oct 2020 07:15:17 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc00bd2cdc3f15d2339b.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:bd2c:dc3f:15d2:339b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 040262A7AA; Wed, 21 Oct 2020 07:15:16 +0000 (UTC) (envelope-from se@freebsd.org) To: Greg 'groggy' Lehey , Warner Losh Cc: "freebsd-arch@freebsd.org" References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> From: Stefan Esser Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: Date: Wed, 21 Oct 2020 09:15:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: <20201021012323.GA59592@eureka.lemis.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aqyVWFurCt4cScpmMPidwmoQxg2SPWDDu" 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: Wed, 21 Oct 2020 07:15:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aqyVWFurCt4cScpmMPidwmoQxg2SPWDDu Content-Type: multipart/mixed; boundary="KXx56s0PRmfaCWy4zWIYBcZnSbzb3mbP7"; protected-headers="v1" From: Stefan Esser To: Greg 'groggy' Lehey , Warner Losh Cc: "freebsd-arch@freebsd.org" Message-ID: Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> In-Reply-To: <20201021012323.GA59592@eureka.lemis.com> --KXx56s0PRmfaCWy4zWIYBcZnSbzb3mbP7 Content-Type: multipart/mixed; boundary="------------996947E6B6CBAEB587AF6DE6" Content-Language: de-DE This is a multi-part message in MIME format. --------------996947E6B6CBAEB587AF6DE6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: [...] > That's the whole point. Where do we draw the line? Given that these > holidays interest more people outside the project than in, I'd think > that they should all go into the port. And the whole idea of > alternative 3 is that the maintenance should be automatic and > external, so updating holidays should no longer be our concern. Are we taling about the calendar binary or the calendar files? IMHO, the calendar binary could stay in base but be modified to scan directories in e.g. /usr/local/share/calendar/ and ports could provide these calendar files. A trivial patch is included below that allows for just this change to become effective, and I'd like to commit it to -CURRENT. >>> 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. >=20 > I don't understand your haste in wanting to do this. Until we don't > know what we're going to do, we can't do the split properly. We've > had calendar since the beginning of time, and suddenly it seems to > need changing. Let's agree on what we want to do first. We could easily create a port containing all the files from src/usr.bin/calendar/calendars except for calendar.freebsd (and perhaps calendar.computer ?), which could remain in base together with the binary. I'd be willing to prepare a port that provides these calendar files (with config options to select indiviual calendars, if found useful). > In the meantime, though, something else has occurred to me: at least > get buy-in from the other BSD projects. I've just checked NetBSD, > OpenBSD, Mac OS and Ubuntu (I think) Linux, and they all have the same > structure. They also all have the same error that I fixed in FreeBSD > a couple of days ago. I'm pretty sure that they're in the base system > for the first three, since they're from a virgin installation. My > guess is that they're also in the base system for Ubuntu, or whatever > version I have access to. If the calendar binary remains in base, there is no need to check with other projects. In fact, they might find it easier to follow us and provide separately maintained calendar files that are not bound to a distribution or single project, too. > This issue is not important enough to take a knee-jerk approach. I'd > rather see something that all the projects can use. In this > connection, of course, GitHub sounds like a good potential start, but > would the OpenBSD project (for example) buy in to it? The hosting of calendar files and the method used to let the community contribute to them are technical details. If there are no strong objections, I'd want to apply the following change to usr.bin/calendar: Index: io.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- io.c (Revision 366901) +++ io.c (Arbeitskopie) @@ -71,7 +71,7 @@ }; const char *calendarFile =3D "calendar"; /* default calendar file */ -static const char *calendarHomes[] =3D {".calendar", _PATH_INCLUDE}; /* = HOME */ +static const char *calendarHomes[] =3D {".calendar", _PATH_INCLUDE,=20 _PATH_INCLUDE_LOCAL}; /* HOME */ static const char *calendarNoMail =3D "nomail";/* don't sent mail if=20 file exist */ static char path[MAXPATHLEN]; Index: pathnames.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- pathnames.h (Revision 366901) +++ pathnames.h (Arbeitskopie) @@ -34,4 +34,9 @@ #include +#ifndef _PATH_LOCALBASE +#define _PATH_LOCALBASE "/usr/local" +#endif + #define _PATH_INCLUDE "/usr/share/calendar" +#define _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar" The definition of _PATH_LOCALBASE should go into /usr/include/paths.h and it could also be used in the definition of _PATH_DEFPATH (which currently contains a verbatim "/usr/local" in two path elements) in that file. The above patch is sufficient to let a port provide the identical calendar files currently installed in base (and I have prepared a port that does exactly this except for calendar.freebsd) - but obviously no commit is planned without the above shown extension to the binary to check for the additional path in LOCALBASE. Regards, STefan --------------996947E6B6CBAEB587AF6DE6-- --KXx56s0PRmfaCWy4zWIYBcZnSbzb3mbP7-- --aqyVWFurCt4cScpmMPidwmoQxg2SPWDDu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl+P3/8FAwAAAAAACgkQR+u171r99URV 2QgAiiNup21dSsH1bIu6HXbQtUqsrqIMPcJMsQDVJ4eRtJ4c94NqN3w7t5iOfLxEXIukn6DREahV gidg+1rxnWD5KRngTNxNW+wil2eG5E+gIC7XUnkm1+KmPkH3nK96pgX89fzfJihBsi9ueGbym6qd NLZeaXCLuYbyGfUkT+u79WLRWA+mirWiN6AOYRpUug+silDABUNYQDKgQao+io8K3gEYOpLMiJQu WRr7bbgQCGPx2g8oQKCcNCtr+ZDaYwHg3k3SFirB0/caVP29obaesjfuBqE4aAYUi7ca7Coh5Q3Z kYnsuqGfmCp4XM/krn9vO07GQL/5HeXLCIRYjLGi7A== =jYSd -----END PGP SIGNATURE----- --aqyVWFurCt4cScpmMPidwmoQxg2SPWDDu-- From owner-freebsd-arch@freebsd.org Wed Oct 21 10:03:36 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 2EDE0448073 for ; Wed, 21 Oct 2020 10:03:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGR080R22z478b; Wed, 21 Oct 2020 10:03:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc00bd2cdc3f15d2339b.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:bd2c:dc3f:15d2:339b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6ADE32BCF7; Wed, 21 Oct 2020 10:03:35 +0000 (UTC) (envelope-from se@freebsd.org) From: Stefan Esser To: Greg 'groggy' Lehey , Warner Losh Cc: "freebsd-arch@freebsd.org" References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> Subject: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> Date: Wed, 21 Oct 2020 12:03:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zMJ7asWTleOv4KkjwDERox9qUdiWFAlg4" 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: Wed, 21 Oct 2020 10:03:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zMJ7asWTleOv4KkjwDERox9qUdiWFAlg4 Content-Type: multipart/mixed; boundary="jdDLJT8BjcAgZG2m9tzBSygcHVyf7mR92"; protected-headers="v1" From: Stefan Esser To: Greg 'groggy' Lehey , Warner Losh Cc: "freebsd-arch@freebsd.org" Message-ID: <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> Subject: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> In-Reply-To: --jdDLJT8BjcAgZG2m9tzBSygcHVyf7mR92 Content-Type: multipart/mixed; boundary="------------99B2B8B71E5893FF61DA973D" Content-Language: en-US This is a multi-part message in MIME format. --------------99B2B8B71E5893FF61DA973D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 21.10.20 um 09:15 schrieb Stefan Esser: > Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: > [...] >> That's the whole point.=A0 Where do we draw the line?=A0 Given that th= ese >> holidays interest more people outside the project than in, I'd think >> that they should all go into the port.=A0 And the whole idea of >> alternative 3 is that the maintenance should be automatic and >> external, so updating holidays should no longer be our concern. >=20 > Are we taling about the calendar binary or the calendar files? >=20 > IMHO, the calendar binary could stay in base but be modified to > scan directories in e.g. /usr/local/share/calendar/ and ports > could provide these calendar files. I have created a Phabricator review for the proposed change: https://reviews.freebsd.org/D26882 This is just an enabler for calendar files in a directory that can be maintained by means of a port. A suggested port has been made available for review, too: https://reviews.freebsd.org/D26883 --------------99B2B8B71E5893FF61DA973D-- --jdDLJT8BjcAgZG2m9tzBSygcHVyf7mR92-- --zMJ7asWTleOv4KkjwDERox9qUdiWFAlg4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl+QB3UFAwAAAAAACgkQR+u171r99UST lwgAp/y1j50OiOUUGvLx6oqez++Z74XDnskvtJz3betGCME/DsotwbCjTJywiXt9Uvi3T1/AZy4f 87zZI3a1wxWzOhSsG1tAOnLNdH/Uyn/N1n3tOmdQiEHHm8D6u+w/CWfDbZ16LpVr/RCVXK4SYzYg fvzVXdPReH0l2muZeLzSFn5uq/RBPpTvtRfW8nziFa3yndA76XFZbhZfUUhDZFAOtkadGkgsl8rt ikPagYR3QfysDAxzYgy/2Crg4UPI34oQKTTlPvMp/oY79VSb98/9D7XxCMyX1DdY0E3J1ts5m42j p45KizVy7cIII7SsE707RAZwuX9+zjk0g1eR+1MQeQ== =pTwi -----END PGP SIGNATURE----- --zMJ7asWTleOv4KkjwDERox9qUdiWFAlg4-- From owner-freebsd-arch@freebsd.org Wed Oct 21 17:56:05 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 A7877429166 for ; Wed, 21 Oct 2020 17:56:05 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 4CGdTJ6DNvz4ZbZ for ; Wed, 21 Oct 2020 17:56:04 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: by mail-lf1-x141.google.com with SMTP id l28so4180458lfp.10 for ; Wed, 21 Oct 2020 10:56:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1GYGs8ywY0g4gK3CnwPi8iLbW/qz3DcGD7caPmQxcK8=; b=BOm2YM/t6IzL5jM/GaGYQHXN6xecIXfMfuE2J3em8I4JBqHQToxvfT+dZ6M5KK3GVf lpklGQmS/DnbBu6IFEI0O7xoV0P/cPI0u7UO01/YQeHmM/Mo9kGwQkPozIpbpQQTxjHQ J/qvGlqFUK/yAdvKNKjU/0HzYCuWbDeqBU0OTeKsqsbfaQMm+dstfU5scGAl+K3ca5lV XJdISf7GMM+H+p9KfjXB7vhH9bSJmnh7ahEIRBN8Esf4ZCjj7/f6XDkfbVhKe0tksnxP fCuniBrGx357v2cnkKwfdTi4QUSTLXFbI9fWYizQstZybLQHn55ky6uG/U9N/SWgeVRk O8HQ== X-Gm-Message-State: AOAM5315j3vYiagxKQeUTKmEb+2aeep0RJoFFnIhAGqo3rfdGtoRxPMB HHYQNifDDRmLzDvwJfLzTpHMRc6ilEf2agjUleuu3pvGYNpAEfiX X-Google-Smtp-Source: ABdhPJyczP1GVp8w7x5JpfJynsMuulBtTIMQZd+ujCBj9QFEfUB5ENA98q9VBeeeu8IhQ14Zka7jLV7KcoJu1FNT5fg= X-Received: by 2002:a19:804d:: with SMTP id b74mr1605809lfd.55.1603302962389; Wed, 21 Oct 2020 10:56:02 -0700 (PDT) MIME-Version: 1.0 From: Ka Ho Ng Date: Thu, 22 Oct 2020 01:55:51 +0800 Message-ID: Subject: Draft IOCTL commands on sndstat To: freebsd-arch@freebsd.org Cc: hselasky@freebsd.org, lwhsu@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4CGdTJ6DNvz4ZbZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.002]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_POLICY_ALLOW(-0.50)[freebsdfoundation.org,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::141:from]; NEURAL_HAM_SHORT(-0.97)[-0.972]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Wed, 21 Oct 2020 17:56:05 -0000 Hi all, I have proposed a set of IOCTLs on sndstat. The IOCTLs are nvlist-based, and the goal of these IOCTLs aims at eliminating text parsing as a generic user space API. Here is the link to the differential: https://reviews.freebsd.org/D26884. A piece of sample code is also provided to demonstrate the usage of the IOCTLs. Regards, Ka Ho From owner-freebsd-arch@freebsd.org Wed Oct 21 17:29:59 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 07157428B17 for ; Wed, 21 Oct 2020 17:29:59 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 4CGcvB2Pk2z4YfB for ; Wed, 21 Oct 2020 17:29:58 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: by mail-lf1-x132.google.com with SMTP id d24so4107387lfa.8 for ; Wed, 21 Oct 2020 10:29:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/QPATkfuhiJSNGIHFIvEsoDS9O7mg+HUlbRMHEPtc3c=; b=MmmvJUCeSIfV57o+LKClW7i/N31/O2+DWnh3RV3YSa+lGIkY20ypbcd64k4+QbchW/ Mdl007aPol6EXcqSwvFwOTSNbpKddK+xb1v641YYxROXzdiXV10rR73jH0cuwXNdwyOa B+wS4RF/3UzxTQ8jOecipaODlsyKZvs+hzwT39mEyP7TkvsmljZ/WsbJTeJoA0toZAhE VLd/nwHOF6qaE/Gk7I3S6X1Xsjmln6XrWDHuPXbUN0+SF2vsTcF35bcjFrnjkJ8qiuo8 Cn5P4Qpci5VnB3YDgchcFqom6868nDpJOcWkdzpXhdV9i9xQesCVO3KUn/lA/JhCnzcN Gy1A== X-Gm-Message-State: AOAM531VdmAZHoUHF4NB7ugi1AcxNiqbXZkqUNzHfJuf/JWrIq72C+D/ Pvo0cFCb9FRM/aOy8pEJurKfq8MuH35j0mqSSgitSWz7Xl1ENr2R X-Google-Smtp-Source: ABdhPJzxlxzn1ZidXcwOvjl6blHDoIkU+LPz4elU/ijiAgrI4RU/L4V6kekbYLA2BOAG0q6wSxlWZNoHUtdmMAMdi+U= X-Received: by 2002:a19:c3cf:: with SMTP id t198mr1507934lff.461.1603301395606; Wed, 21 Oct 2020 10:29:55 -0700 (PDT) MIME-Version: 1.0 From: Ka Ho Ng Date: Thu, 22 Oct 2020 01:29:43 +0800 Message-ID: Subject: A draft API on sndstat IOCTLs To: freebsd-arch@freebsd.org Cc: hselasky@freebsd.org, lwhsu@freebsd.org X-Rspamd-Queue-Id: 4CGcvB2Pk2z4YfB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_POLICY_ALLOW(-0.50)[freebsdfoundation.org,quarantine]; NEURAL_HAM_SHORT(-0.41)[-0.411]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.01)[-1.007]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-Mailman-Approved-At: Wed, 21 Oct 2020 17:56:58 +0000 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: Wed, 21 Oct 2020 17:29:59 -0000 Hi all, I have proposed a draft API on sndstat IOCTLs. The IOCTL commands are nvlist-based, and the goal of these IOCTLs aims at eliminating text parsing as a generic user space API. Here is the link to the differential: https://reviews.freebsd.org/D26884. A piece of sample code is also provided to demonstrate the usage of the IOCTLs. Regards, Ka Ho From owner-freebsd-arch@freebsd.org Wed Oct 21 17:59:42 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 02AA24297C3 for ; Wed, 21 Oct 2020 17:59:42 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 4CGdYT2HCVz4ZvD for ; Wed, 21 Oct 2020 17:59:40 +0000 (UTC) (envelope-from khng@freebsdfoundation.org) Received: by mail-lj1-x244.google.com with SMTP id m20so3592795ljj.5 for ; Wed, 21 Oct 2020 10:59:40 -0700 (PDT) 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; bh=rR8KSgNf/uRKAIN0DssN3Xir3V3a8rrFrR0F7nrGzu4=; b=V+iNaMqNztbcj+BEJnU6D5KrrtEnZECXqmVtvvDVkCc30wBPHo+IWr3PIIf6etVyWK 0IX0BbPYHoEi1wRJjyVCjjR/s0u4GbeOGXug45+/fGr83kdyxEpoThL25phT7SxrXUot qS0H14i7GKeN15BfL/ka9diDzs8XU4XrjhlDhDYhIy8V/K+AvY1BDyOODFF13yVSPhCz LtD5SYMdLeCZegcoWLcaBjAtoWWc46LVUkFcZIAHqtY73/4zkqACXmHNne03e10i+cWe 4JyL01N3GZUUbd8RcaR/pdxed0ek8KCR0vMKd1he9sryI87sJbqE28s1r9PU9EJVt3Nc alHg== X-Gm-Message-State: AOAM532TVpb5Lq44JRgN4S1fFFZrm+TAqgkrwVaItoeWapnx/BPfrN2p WaCK1FEloYTmfDYddcS9cv3BMLGp0yMc4m2LrL09MtPXgIf4nA== X-Google-Smtp-Source: ABdhPJz/+9nTi/YKcFbx1gVCrns5r7syud0S2v4VZswecmJi8OMH5FsfJcsynlbbL8w7qMb8CgXT+nQrPgOJiCwGhh4= X-Received: by 2002:a2e:a376:: with SMTP id i22mr1961726ljn.325.1603303178968; Wed, 21 Oct 2020 10:59:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ka Ho Ng Date: Thu, 22 Oct 2020 01:59:27 +0800 Message-ID: Subject: Re: A draft API on sndstat IOCTLs To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4CGdYT2HCVz4ZvD X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.63 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_POLICY_ALLOW(-0.50)[freebsdfoundation.org,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::244:from]; NEURAL_HAM_SHORT(-0.63)[-0.625]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Wed, 21 Oct 2020 17:59:42 -0000 Oops, please refer to https://lists.freebsd.org/pipermail/freebsd-arch/2020-October/020108.html instead for further replies. Ka Ho On Thu, Oct 22, 2020 at 1:29 AM Ka Ho Ng wrote: > > Hi all, > > I have proposed a draft API on sndstat IOCTLs. The IOCTL commands are nvlist-based, > and the goal of these IOCTLs aims at eliminating text parsing as a generic user space API. > Here is the link to the differential: https://reviews.freebsd.org/D26884. A piece of sample code > is also provided to demonstrate the usage of the IOCTLs. > > Regards, > Ka Ho From owner-freebsd-arch@freebsd.org Thu Oct 22 01:48:45 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 71E0E439809 for ; Thu, 22 Oct 2020 01:48:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 4CGqyh4vSCz47lv for ; Thu, 22 Oct 2020 01:48:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2e.google.com with SMTP id bl9so141946qvb.10 for ; Wed, 21 Oct 2020 18:48:44 -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=2dD/PaigPgkG+LLO3Xd68ydoUqZcJZzye/XW9B7oDMM=; b=MMwuDX76XYEBxoEJC5n2TNa0Q4ZGk65EnWJxZ+L4ALpjVhlVJdAWuBgVJJ3dLR4OsH 2CiV5V1RbwniLXuqvo/cPMx6MKavICiZB8VF8jmxhpmyrV4TE+pPadzex0I1bM4U1Bkg aLRxKlpxCFC/0b+JBxN5IZjApwv3dW2GxF48HKpL77J5GUf+sxfIM9oJxR8svohWWTCe 4N3B7NyFBsvmi/ztSYsqxtf2z3xj4H5kFX5iuEtvXHXf3MAcUlcJG9H1nkntczAh8ex9 x5hq5Qq4Trim56qV5zUz9kF7d0pGkq98Dp8FuW+98Ue09spxsZWUTAgSEi09zccqAxDd rnUA== 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=2dD/PaigPgkG+LLO3Xd68ydoUqZcJZzye/XW9B7oDMM=; b=A2RSkt1zACAjyieXBLg/Ls9F1igHsQdblBltlUUi0d0ShA1o1sGKvXKRoCuN0Kj9VM CaUO/9YeA2qlQkknYeDK+EGY0Bsp1p9n78McV98WRmZxL+DjYk4Pnjxb1Jg85rrl95Wk /bXsHcUd7IaGvSdJyXIikV9950HHWxY9jEFDJRcitll0GfO/wjnse57L5I6ORoz2IN6Z +86np2XSV4r59U1r/kW9kRnXUeBbl3h/NSa1HSpeopsSY37tmX9+14UC4CFqGikt77hz 6gClms9qf/h4ciB3HWXGHYXyEn5+cndmt3TqGR9RMd/2IWnxvVMfzTlt4bl9QqnPTQlf KZvA== X-Gm-Message-State: AOAM533vqmNsv1RLM8P6b8eaAO5yTX4u40nqWANkQhevwjoGlQ4OVz4o 6EpCMxA7v+wxKC0oXJD6c6Ry2R/uguJcG79vadMPXA== X-Google-Smtp-Source: ABdhPJya1jsDsUzrJVxNEOHYP/vdRpHrEmnJT40rHeCsfX/DAcpv2bymhqUzI6Ith44PRggVy4ldQ6agTDsbM4iEsyU= X-Received: by 2002:a0c:aa1e:: with SMTP id d30mr311477qvb.24.1603331323366; Wed, 21 Oct 2020 18:48:43 -0700 (PDT) MIME-Version: 1.0 References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> In-Reply-To: <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> From: Warner Losh Date: Wed, 21 Oct 2020 19:48:31 -0600 Message-ID: Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: Stefan Esser Cc: "Greg 'groggy' Lehey" , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 4CGqyh4vSCz47lv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=MMwuDX76; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.67 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.92)[-0.919]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.931]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_SHORT(0.18)[0.178]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2e:from]; 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]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] 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: Thu, 22 Oct 2020 01:48:45 -0000 Modulo the stuff I left on the reviews.... I love it. I can also extract history from FreeBSDs repo. Warner On Wed, Oct 21, 2020, 4:03 AM Stefan Esser wrote: > Am 21.10.20 um 09:15 schrieb Stefan Esser: > > Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: > > [...] > >> That's the whole point. Where do we draw the line? Given that these > >> holidays interest more people outside the project than in, I'd think > >> that they should all go into the port. And the whole idea of > >> alternative 3 is that the maintenance should be automatic and > >> external, so updating holidays should no longer be our concern. > > > > Are we taling about the calendar binary or the calendar files? > > > > IMHO, the calendar binary could stay in base but be modified to > > scan directories in e.g. /usr/local/share/calendar/ and ports > > could provide these calendar files. > > I have created a Phabricator review for the proposed change: > > https://reviews.freebsd.org/D26882 > > This is just an enabler for calendar files in a directory that > can be maintained by means of a port. > > A suggested port has been made available for review, too: > > https://reviews.freebsd.org/D26883 > From owner-freebsd-arch@freebsd.org Thu Oct 22 04:12:15 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 EBC0843D4AC for ; Thu, 22 Oct 2020 04:12:15 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGv8H19Q1z4JhB; Thu, 22 Oct 2020 04:12:14 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id B573C280AF; Thu, 22 Oct 2020 04:12:13 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 0365A26359C; Thu, 22 Oct 2020 15:12:13 +1100 (AEDT) Date: Thu, 22 Oct 2020 15:12:12 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: Stefan Esser , freebsd-arch@freebsd.org Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022041212.GE59592@eureka.lemis.com> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CGv8H19Q1z4JhB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-2.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.807]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.923]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.41)[0.413]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 04:12:16 -0000 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 21 October 2020 at 19:48:31 -0600, Warner Losh wrote: > On Wed, Oct 21, 2020, 4:03 AM Stefan Esser wrote: > >> Am 21.10.20 um 09:15 schrieb Stefan Esser: >>> Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: >>> [...] >>>> That's the whole point. Where do we draw the line? Given that these >>>> holidays interest more people outside the project than in, I'd think >>>> that they should all go into the port. And the whole idea of >>>> alternative 3 is that the maintenance should be automatic and >>>> external, so updating holidays should no longer be our concern. >>> >>> Are we taling about the calendar binary or the calendar files? >>> >>> IMHO, the calendar binary could stay in base but be modified to >>> scan directories in e.g. /usr/local/share/calendar/ and ports >>> could provide these calendar files. >> >> I have created a Phabricator review for the proposed change: >> >> https://reviews.freebsd.org/D26882 >> >> This is just an enabler for calendar files in a directory that >> can be maintained by means of a port. >> >> A suggested port has been made available for review, too: >> >> https://reviews.freebsd.org/D26883 > > Modulo the stuff I left on the reviews.... I love it. I can also > extract history from FreeBSDs repo. The change to calendar(1) looks fine, but I have my issues with the port. It seems that we're not alone. On the one hand, both Apple and Linux have used our data files for their packages, so removing the data files would violate POLA. On the other hand, Apple, Linux, NetBSD and OpenBSD are maintaining their own versions of these files, along with calendar(1). My guess is that Linux has them hidden on GitHub. I'm trying to find out where they maintain the files (can any Linuxheads help?), so that we can come to a general agreement about how to maintain them. This could include removing calendar(1) from the tree entirely and installing from a port. Once again I'm concerned about jumping the gun. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+RBpwACgkQIubykFB6QiMRVACgl5WvMRAGU11PbeYWrtMTBrs/ gzsAmgM3D/OtnbW+Vi7qZCBb7rMsysT5 =XUQH -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From owner-freebsd-arch@freebsd.org Thu Oct 22 04:23:23 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 6890643D7A0 for ; Thu, 22 Oct 2020 04:23:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) (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 4CGvP63Ft3z4K3R for ; Thu, 22 Oct 2020 04:23:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf41.google.com with SMTP id h11so274209qvq.7 for ; Wed, 21 Oct 2020 21:23:22 -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=Mc6EbVbLbaZ8xfMPBbdsLf68ooeN8MSrhG1VqQZ2XkM=; b=FnrI0gAU/kChbyZOLfiDP21o1GBD2Hoc35oSUn7tVzsvC+TVTsSR17l5ndC+ORVXhV j0XP4D1wMhMHDTr/m8ftNBBYCeCVqMPGuYBKHAqgn+LHw/PosVVySDNOckEHIXI1dNTA oO94zuRH7PsLWSpp26qGgYRCOO3sW507TVlPTyQwZUiTrL+/0YgX5MNzTBOHYHpfWGJu ZFRKgeFa+OeThP5Wq3hAaMG865OKm5kWCOKoTeShNfEFFJNu+xXjARAV5UyrKzClwCfn bU1xaXRfd9aTch68Vj6XODFsoFXHAcEfDe6Djm5C75j475BnQErrNZLlYC7N9PM6VL1g Lsuw== 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=Mc6EbVbLbaZ8xfMPBbdsLf68ooeN8MSrhG1VqQZ2XkM=; b=F+lowT4SKf3c+uH2drElg3fr/7gcjZ5HJpzc374FnquvSsVgUXzWOJtCTFObJVgFyt 2qmiesWYNeSv4cqp/FBtsJQXDDV5Kn6kSdd27/DulfTBe9Ag2MIY/5sW/n9Zg8WoRg4X ebNAtDGYYw/ghcEJisomBiL4thbZJY7e9Dh4h5hNSYdDi7h/Mdxex6F1nf4K0x239to2 lPnICmZEjk7U++5mee4wZEycJZBU1Acc/DAq+Ckpyl8jqP6jD6xmH1C9HsDR+C35XnFB tfOx+oEC+sJiGZ2ln01VT2Du1uKzVcVLvEjAB0hvK5uIYVsyrNzN4nnnC0MjkLv5Tye2 /2yg== X-Gm-Message-State: AOAM532qQEbiCtazmcI8noQt9fpzosHWqH1Url+TIj0v7746eS8JUxSB l7F1NmcLlFFZSbkEXiCx4SqZsGFbX7SxGV8wFSN7UA== X-Google-Smtp-Source: ABdhPJw0pUwr4AFAhOLetA7RT0e60yQ5HlyXXAF4upTRokk72JTBKiCZW/hUE4uiZfaz+FLIrLVRY0ivDuS9mKEQClo= X-Received: by 2002:a05:6214:10c4:: with SMTP id r4mr687795qvs.62.1603340601359; Wed, 21 Oct 2020 21:23:21 -0700 (PDT) MIME-Version: 1.0 References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> In-Reply-To: <20201022041212.GE59592@eureka.lemis.com> From: Warner Losh Date: Wed, 21 Oct 2020 22:23:08 -0600 Message-ID: Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: "Greg 'groggy' Lehey" Cc: Stefan Esser , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 4CGvP63Ft3z4K3R X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=FnrI0gAU; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f41) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.26 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.92)[-0.918]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.932]; 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:+]; NEURAL_HAM_SHORT(-0.41)[-0.408]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f41:from]; 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]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] 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: Thu, 22 Oct 2020 04:23:23 -0000 On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey wrote: > On Wednesday, 21 October 2020 at 19:48:31 -0600, Warner Losh wrote: > > On Wed, Oct 21, 2020, 4:03 AM Stefan Esser wrote: > > > >> Am 21.10.20 um 09:15 schrieb Stefan Esser: > >>> Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: > >>> [...] > >>>> That's the whole point. Where do we draw the line? Given that these > >>>> holidays interest more people outside the project than in, I'd think > >>>> that they should all go into the port. And the whole idea of > >>>> alternative 3 is that the maintenance should be automatic and > >>>> external, so updating holidays should no longer be our concern. > >>> > >>> Are we taling about the calendar binary or the calendar files? > >>> > >>> IMHO, the calendar binary could stay in base but be modified to > >>> scan directories in e.g. /usr/local/share/calendar/ and ports > >>> could provide these calendar files. > >> > >> I have created a Phabricator review for the proposed change: > >> > >> https://reviews.freebsd.org/D26882 > >> > >> This is just an enabler for calendar files in a directory that > >> can be maintained by means of a port. > >> > >> A suggested port has been made available for review, too: > >> > >> https://reviews.freebsd.org/D26883 > > > > Modulo the stuff I left on the reviews.... I love it. I can also > > extract history from FreeBSDs repo. > > The change to calendar(1) looks fine, but I have my issues with the > port. It seems that we're not alone. On the one hand, both Apple and > Linux have used our data files for their packages, so removing the > data files would violate POLA. On the other hand, Apple, Linux, > NetBSD and OpenBSD are maintaining their own versions of these files, > along with calendar(1). My guess is that Linux has them hidden on > GitHub. I'm trying to find out where they maintain the files (can any > Linuxheads help?), so that we can come to a general agreement about > how to maintain them. This could include removing calendar(1) from > the tree entirely and installing from a port. Once again I'm > concerned about jumping the gun. > Where we pull them from doesn't affect that. They can pull from github easily enough. And our users can install a port easily enough. It's done all the time, so wouldn't be that surprising even from that perspective. This issue has been simmering for years, but has flared up in the last 6 months. In that time no progress has been made. And it has no impact on the data source issue: that can be handled at whatever pace other groups want to come together. Finally, it's my firm belief that the majority of developer opinion is that this would be better served with this split. It's been that way for years. Until recently, though, the commit rate has been so low that people shrugged. Now, there have been enough that it's my view that the community is jelled behind the split and are growing inpatient for its resolution. So, unless you have a competing plan, with a firm timeline, I think we should allow se@ to proceed as he proposes. It is time limited, concrete, simple to execute and in line with other times we've done similar. Warner Greg > -- > Sent from my desktop computer. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > From owner-freebsd-arch@freebsd.org Thu Oct 22 04:49:32 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 A147A43DBDE for ; Thu, 22 Oct 2020 04:49:32 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGvzJ0bFsz4Kqq; Thu, 22 Oct 2020 04:49:31 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 01312280AD; Thu, 22 Oct 2020 04:49:31 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 4F68126359C; Thu, 22 Oct 2020 15:49:30 +1100 (AEDT) Date: Thu, 22 Oct 2020 15:49:30 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: Stefan Esser , freebsd-arch@freebsd.org Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022044930.GF59592@eureka.lemis.com> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CGvzJ0bFsz4Kqq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.807]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.923]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.87)[-0.873]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 04:49:32 -0000 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote: > On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey wrote: > >> On Wednesday, 21 October 2020 at 19:48:31 -0600, Warner Losh wrote: >>> On Wed, Oct 21, 2020, 4:03 AM Stefan Esser wrote: >>> >>>> Am 21.10.20 um 09:15 schrieb Stefan Esser: >>>>> Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: >>>> A suggested port has been made available for review, too: >>>> >>>> https://reviews.freebsd.org/D26883 >>> >>> Modulo the stuff I left on the reviews.... I love it. I can also >>> extract history from FreeBSDs repo. >> >> The change to calendar(1) looks fine, but I have my issues with the >> port. It seems that we're not alone. On the one hand, both Apple and >> Linux have used our data files for their packages, so removing the >> data files would violate POLA. On the other hand, Apple, Linux, >> NetBSD and OpenBSD are maintaining their own versions of these files, >> along with calendar(1). My guess is that Linux has them hidden on >> GitHub. I'm trying to find out where they maintain the files (can any >> Linuxheads help?), so that we can come to a general agreement about >> how to maintain them. This could include removing calendar(1) from >> the tree entirely and installing from a port. Once again I'm >> concerned about jumping the gun. > > Where we pull them from doesn't affect that. But where other people pull them from *is* relevant. > They can pull from github easily enough. Once they know, yes. But maybe they already have it on GitHub. > And our users can install a port easily enough. It's done all the > time, so wouldn't be that surprising even from that perspective. First they need to know that they have to install a port to get what they got automatically in the past. > This issue has been simmering for years, but has flared up in the > last 6 months. I haven't seen any flare. > Finally, it's my firm belief that the majority of developer opinion > is that this would be better served with this split. It's been that > way for years. Until recently, though, the commit rate has been so > low that people shrugged. Now, there have been enough that it's my > view that the community is jelled behind the split and are growing > inpatient for its resolution. Again, what I see is more shrugging than impatience. So far I have seen you pushing, and one or two asking for action (and that a while back). Those one or two have not responded to this thread, suggesting that they're not overly impatient. > So, unless you have a competing plan, Sorry, I thought I had explained that. > with a firm timeline, I don't think that's important. > I think we should allow se@ to proceed as he proposes. It is time > limited, concrete, simple to execute and in line with other times > we've done similar. The only argument in favour is that it's relatively simple to migrate further. But once it's done, there's a great danger that things will stay that way, and we'll just have one more wrinkle in the history. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+RD1oACgkQIubykFB6QiPACACgrDHfxEyzplqC3VYOiZ++j3EH 9ccAoIbNuVw6kkr/z0BIJoBnhFYfVQNa =PK/t -----END PGP SIGNATURE----- --6v9BRtpmy+umdQlo-- From owner-freebsd-arch@freebsd.org Thu Oct 22 04:54:53 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 8787A43D7F1 for ; Thu, 22 Oct 2020 04:54:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 4CGw5S5x43z4L77 for ; Thu, 22 Oct 2020 04:54:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2a.google.com with SMTP id s17so288245qvr.11 for ; Wed, 21 Oct 2020 21:54:52 -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=dnKEpMRqkYM7h1KhAwKDPOQrTdyh652ufHnsL5ON5GQ=; b=FMdLvSyd92Vx6ns54yGox6tgVdddGj0cGy3CSLm88cnVur6g39a/tq4uVFpN3lTUFq ENcFggDgDmiFWGqxA24eZZn0nnWL54GiNfYbexbEcb9KA3VwTddlOxgx/ky/WyLZjvxQ b0MM8PAsB5BD632j6bbCdHZYTLFOUKb+O93OIVUTrHPBMCo9aBhhDZdv5TwQXkNVfXd7 83cErJK4u7sIYGkpbOFZ67MWT8I6WZl1aZRjjHr3agDGBObVVseM7fZVoH96/iZDdxQj wT3G3jLhmKjws/oWqNSjGcLBFa6wuwI/vqEXop3cTXnjZdTP8xEU0W5E85j73fv/udvg sn7A== 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=dnKEpMRqkYM7h1KhAwKDPOQrTdyh652ufHnsL5ON5GQ=; b=SNPzjyA74K+RpKy+Jqd7gZJz29ebeDGXyHJQW9KrfqL8sTEDFXdTMPKjpPrMhGAKbR mS/xzlN7aTk+V69G2t5zhZc4cUsOTkYr0FIaMOl7cBFD9BnGe+ffRCAW9GR1a1Og40sq ykOnB7yWc72vCZ/ZDfo2ItlCxl1ce69v2O6i9SP6RSHqfgJBeVsmdBOI5vAk+1ELfwTZ GNnWYZksArmFatTlbMFQHRB7Ji028KrbVfpOaaRdW5gsXLcZBiWCfVcHP9EjIUke+NEL pKEEp/BxO1XY1w6h065jE+1XspDx+BDWZhZHH8qJ4mkpKRdrwsjcNqpg+B4e/B2Jay58 /5aw== X-Gm-Message-State: AOAM5313vdHBUK0OpXy+KmKFKg+dfI5VmgJluM7DShgqPqRAFyT1xNRI hkOQqv3tfePeLsbIMrqNiOorqyItO3HF90y9gZCWOw== X-Google-Smtp-Source: ABdhPJyFoX3sWZSXItNpn3956RzqM349DX7FPgU3XlaW+g+bJUqEqXgc4VrciktWpH4bbMTkBbZKuWgjKzpumKB3O9w= X-Received: by 2002:a0c:82c4:: with SMTP id i62mr650952qva.28.1603342491355; Wed, 21 Oct 2020 21:54:51 -0700 (PDT) MIME-Version: 1.0 References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> <20201022044930.GF59592@eureka.lemis.com> In-Reply-To: <20201022044930.GF59592@eureka.lemis.com> From: Warner Losh Date: Wed, 21 Oct 2020 22:54:39 -0600 Message-ID: Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: "Greg 'groggy' Lehey" Cc: Stefan Esser , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 4CGw5S5x43z4L77 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=FMdLvSyd; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.26 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.92)[-0.918]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.932]; 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:+]; NEURAL_HAM_SHORT(-0.41)[-0.412]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from]; 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:~]; 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]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 04:54:53 -0000 On Wed, Oct 21, 2020, 10:49 PM Greg 'groggy' Lehey wrote: > On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote: > > On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey > wrote: > > > >> On Wednesday, 21 October 2020 at 19:48:31 -0600, Warner Losh wrote: > >>> On Wed, Oct 21, 2020, 4:03 AM Stefan Esser wrote: > >>> > >>>> Am 21.10.20 um 09:15 schrieb Stefan Esser: > >>>>> Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: > >>>> A suggested port has been made available for review, too: > >>>> > >>>> https://reviews.freebsd.org/D26883 > >>> > >>> Modulo the stuff I left on the reviews.... I love it. I can also > >>> extract history from FreeBSDs repo. > >> > >> The change to calendar(1) looks fine, but I have my issues with the > >> port. It seems that we're not alone. On the one hand, both Apple and > >> Linux have used our data files for their packages, so removing the > >> data files would violate POLA. On the other hand, Apple, Linux, > >> NetBSD and OpenBSD are maintaining their own versions of these files, > >> along with calendar(1). My guess is that Linux has them hidden on > >> GitHub. I'm trying to find out where they maintain the files (can any > >> Linuxheads help?), so that we can come to a general agreement about > >> how to maintain them. This could include removing calendar(1) from > >> the tree entirely and installing from a port. Once again I'm > >> concerned about jumping the gun. > > > > Where we pull them from doesn't affect that. > > But where other people pull them from *is* relevant. > > > They can pull from github easily enough. > > Once they know, yes. But maybe they already have it on GitHub. > > > And our users can install a port easily enough. It's done all the > > time, so wouldn't be that surprising even from that perspective. > > First they need to know that they have to install a port to get what > they got automatically in the past. > > > This issue has been simmering for years, but has flared up in the > > last 6 months. > > I haven't seen any flare. > Then you've not been paying attention. > Finally, it's my firm belief that the majority of developer opinion > > is that this would be better served with this split. It's been that > > way for years. Until recently, though, the commit rate has been so > > low that people shrugged. Now, there have been enough that it's my > > view that the community is jelled behind the split and are growing > > inpatient for its resolution. > > Again, what I see is more shrugging than impatience. So far I have > seen you pushing, and one or two asking for action (and that a while > back). Those one or two have not responded to this thread, suggesting > that they're not overly impatient. > > > So, unless you have a competing plan, > > Sorry, I thought I had explained that. > It seemed less a firm plan than a sketch. > with a firm timeline, > > I don't think that's important. > And that is the problem. > I think we should allow se@ to proceed as he proposes. It is time > > limited, concrete, simple to execute and in line with other times > > we've done similar. > > The only argument in favour is that it's relatively simple to migrate > further. But once it's done, there's a great danger that things will > stay that way, and we'll just have one more wrinkle in the history. > Well, on github, you can push changes there and accept pull requests too... Warner Greg > -- > Sent from my desktop computer. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > From owner-freebsd-arch@freebsd.org Thu Oct 22 06:35:40 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 18DB0440044 for ; Thu, 22 Oct 2020 06:35:40 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGyKk5fvvz4RVM; Thu, 22 Oct 2020 06:35:38 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 2CCC427313; Thu, 22 Oct 2020 06:35:37 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 7871E26359C; Thu, 22 Oct 2020 17:35:36 +1100 (AEDT) Date: Thu, 22 Oct 2020 17:35:36 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: Stefan Esser , freebsd-arch@freebsd.org Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022063536.GG59592@eureka.lemis.com> References: <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> <20201022044930.GF59592@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="64j1qyTOoGvYcHb1" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CGyKk5fvvz4RVM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.810]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.921]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.82)[-0.816]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 06:35:40 -0000 --64j1qyTOoGvYcHb1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 21 October 2020 at 22:54:39 -0600, Warner Losh wrote: > On Wed, Oct 21, 2020, 10:49 PM Greg 'groggy' Lehey wrote: > >> On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote: >>> On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey wrote: >>> >>>> The change to calendar(1) looks fine, but I have my issues with the >>>> port. It seems that we're not alone. On the one hand, both Apple and >>>> Linux have used our data files for their packages, so removing the >>>> data files would violate POLA. On the other hand, Apple, Linux, >>>> NetBSD and OpenBSD are maintaining their own versions of these files, >>>> along with calendar(1). My guess is that Linux has them hidden on >>>> GitHub. I'm trying to find out where they maintain the files (can any >>>> Linuxheads help?), so that we can come to a general agreement about >>>> how to maintain them. This could include removing calendar(1) from >>>> the tree entirely and installing from a port. Once again I'm >>>> concerned about jumping the gun. >>> >>> Where we pull them from doesn't affect that. >> >> But where other people pull them from *is* relevant. >> >>> They can pull from github easily enough. >> >> Once they know, yes. But maybe they already have it on GitHub. >> >>> And our users can install a port easily enough. It's done all the >>> time, so wouldn't be that surprising even from that perspective. >> >> First they need to know that they have to install a port to get what >> they got automatically in the past. >> >>> This issue has been simmering for years, but has flared up in the >>> last 6 months. >> >> I haven't seen any flare. > > Then you've not been paying attention. > >>> So, unless you have a competing plan, >> >> Sorry, I thought I had explained that. > > It seemed less a firm plan than a sketch. > >> with a firm timeline, >> >> I don't think that's important. > > And that is the problem. What I see is a somewhat emotional response without clear reasoning. FWIW, yes, I've been paying attention, and saving all relevant emails. My proposal is about as good as it goes without input from other projects. And nobody has explained why 24 years is OK, but suddenly 6 months is too long. In principle se@'s proposal is good. But my concern is that then the matter will be forgotten, and the problem will be left half fixed. Let's summarize: 1. We have an program from 4BSD with old, mouldy data files that have outlived their purpose. 2. But we can't just discard them without finding a better alternative. 3. Not just FreeBSD, but also Linux and Mac OS use these files, and they appear to get them from us. NetBSD and OpenBSD also have variants on these files, including errors that I've fixed over the years. 4. Unnamed people in the FreeBSD project are upset about the continuing presence of our version of these files in the FreeBSD tree. 5. There are claims that it has to be fixed Right Now, with no delay. 6. The "fix" involves moving the files somewhere else, without fixing them. What I see is an opportunity. We should get the other projects on board and agree on a central repository for all projects. Probably this would be GitHub, as you have suggested. But maybe there's one there already, and if we want to get the other projects on board, we should discuss it with them. So why not just accept se@'s proposal? It has the obvious advantages of making sense and silencing the spirits which are tormenting you. My concern is that it will then be forgotten, and we will miss the opportunity to unify the data. So: a concrete proposal. 1. We accept se@'s split as a first step. 2. You personally agree to follow up with the other projects and ensure that the data will end up on an OS-neutral platform from which all projects can draw their data. 3. You agree to do this with a firm timeline. Since it seems that 6 months is too long, how about by the end of 2020? You're still involved with NetBSD and OpenBSD, right? That should make things easier. I'll happily chase up the Linux people, and presumably there are people here who can get Apple involved, if they're still interested. How does that sound? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --64j1qyTOoGvYcHb1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+RKDgACgkQIubykFB6QiMHLwCeITKTdCSvx53Q2Gvt7zLqrLCl XVEAoJqb5HrtidqkYSDxmGA/zWPA1olh =i3rb -----END PGP SIGNATURE----- --64j1qyTOoGvYcHb1-- From owner-freebsd-arch@freebsd.org Thu Oct 22 13:57:10 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 7A478449A92 for ; Thu, 22 Oct 2020 13:57:10 +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 4CH87945M2z3fbm for ; Thu, 22 Oct 2020 13:57:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id x20so1508456qkn.1 for ; Thu, 22 Oct 2020 06:57:09 -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=LONNrz8KbxZnPZb1e0qE4MVswlCyydJ8exck+29+uJU=; b=kEkU1hINGA7n8IRNyeoYOv7kYr3hNwk9a84qd+7MhiYjgmKj8W/HqqbEgkGnpW1pP2 9yJ47zuNWwk1VjlCx6LIuN9t+qpyGfa9EEtmmZMV5dCeEv6lFCn0rK+0+dTZsDhrlfQK XknVPEbmU5gerqDtS9P1+Za+OCMWYAyisrGKUHbafayL4LWLT3eq6ki67ZdAHZLugwMk 5EFtGV5CoVD7ZK08WBJLJfhKoGLRk5KiW6BHTD5L0OVODr7JfqpdmsolQX60RKtwF40X YOMwQ0doT/tuWS6F1aTh6UCtkJQFsdX+do9PbeTwGSaFGWalu+VhxxmZqPm37jwyM/Dr jnSg== 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=LONNrz8KbxZnPZb1e0qE4MVswlCyydJ8exck+29+uJU=; b=uJTdU1+5s7puqEdtMuCVcDQdqi38y+ntaOeRyUCFuWpQtq1vg4F8Tz5+grgqWeSG2q XnrFS9b41c5QR2dU/wt/ed3KwxglTUk0QSxSNqvewJ92Wv9RkQbjJgk423IJdoLXzd5k n53duwW4+qdy0rDkEEClqrLwSbZEt3J6Qtx1mhlKTuh1MIJPLUViKHSa5fBt9w7ciVni uKky8a+dE7xcy2ZennRBgtOi7JA94zfVtqSnfXdIAQwyag6Q+ZfwbYTT9Sk5URfUHHuf PoXLMvtHVv+lLAd6twhSdrSZk2FDwUBYrFqgQmefgHkfEM1iU1C9xZLg9bPlt7c9kuji 4thw== X-Gm-Message-State: AOAM531wuMOj9OBD+g+66cwuZjq4FwTgNpH5uh7dJQ+yHVDlabck+cWX yDSIC5q9uJXcL45bqLY7ZXR6YEXFEeE9iL3JHVtFWJAf+tXHxw== X-Google-Smtp-Source: ABdhPJy+Y6TFhJXfp4Pc+cTaDqEfoWJmq7zIl9+UzcU2m8ydoClAcro3ehmT0Qw1rWHVnfs6zsjDpwfHQLM8uGtTz7Y= X-Received: by 2002:a05:620a:15a9:: with SMTP id f9mr1000285qkk.359.1603375028231; Thu, 22 Oct 2020 06:57:08 -0700 (PDT) MIME-Version: 1.0 References: <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> <20201022044930.GF59592@eureka.lemis.com> <20201022063536.GG59592@eureka.lemis.com> In-Reply-To: <20201022063536.GG59592@eureka.lemis.com> From: Warner Losh Date: Thu, 22 Oct 2020 07:56:57 -0600 Message-ID: Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) To: "Greg 'groggy' Lehey" Cc: Stefan Esser , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 4CH87945M2z3fbm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=kEkU1hIN; 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 [-1.99 / 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)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.978]; 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:+]; NEURAL_HAM_SHORT(-0.07)[-0.071]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; 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:~]; 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]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 13:57:10 -0000 On Thu, Oct 22, 2020 at 12:35 AM Greg 'groggy' Lehey wrote: > On Wednesday, 21 October 2020 at 22:54:39 -0600, Warner Losh wrote: > > On Wed, Oct 21, 2020, 10:49 PM Greg 'groggy' Lehey > wrote: > > > >> On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote: > >>> On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey > wrote: > >>> > >>>> The change to calendar(1) looks fine, but I have my issues with the > >>>> port. It seems that we're not alone. On the one hand, both Apple and > >>>> Linux have used our data files for their packages, so removing the > >>>> data files would violate POLA. On the other hand, Apple, Linux, > >>>> NetBSD and OpenBSD are maintaining their own versions of these files, > >>>> along with calendar(1). My guess is that Linux has them hidden on > >>>> GitHub. I'm trying to find out where they maintain the files (can any > >>>> Linuxheads help?), so that we can come to a general agreement about > >>>> how to maintain them. This could include removing calendar(1) from > >>>> the tree entirely and installing from a port. Once again I'm > >>>> concerned about jumping the gun. > >>> > >>> Where we pull them from doesn't affect that. > >> > >> But where other people pull them from *is* relevant. > >> > >>> They can pull from github easily enough. > >> > >> Once they know, yes. But maybe they already have it on GitHub. > >> > >>> And our users can install a port easily enough. It's done all the > >>> time, so wouldn't be that surprising even from that perspective. > >> > >> First they need to know that they have to install a port to get what > >> they got automatically in the past. > >> > >>> This issue has been simmering for years, but has flared up in the > >>> last 6 months. > >> > >> I haven't seen any flare. > > > > Then you've not been paying attention. > > > >>> So, unless you have a competing plan, > >> > >> Sorry, I thought I had explained that. > > > > It seemed less a firm plan than a sketch. > > > >> with a firm timeline, > >> > >> I don't think that's important. > > > > And that is the problem. > > What I see is a somewhat emotional response without clear reasoning. > FWIW, yes, I've been paying attention, and saving all relevant emails. > My proposal is about as good as it goes without input from other > projects. And nobody has explained why 24 years is OK, but suddenly 6 > months is too long. > It's decayed for 24 years. The issue has actually been a lack of curating for about 5 years when the rumblings started now with no motion in 6 months on the problem. The lack of urgency on your part doesn't make it any less a problem. Calling it emotional on my part is a way to deflect from the issue: these files are badly curated and should be discarded or modernized or something in between. The fact that this issue has been brought up many times, only to have it ignored is what's getting people upset. The fact that there's no firm timeline to a fix is also troubling. > In principle se@'s proposal is good. But my concern is > that then the matter will be forgotten, and the problem will be left > half fixed. > Then undertake the time to fix them if you are worried. Let's summarize: > > 1. We have an program from 4BSD with old, mouldy data files that have > outlived their purpose. > > 2. But we can't just discard them without finding a better > alternative. > We can, actually. We do it all the time for stuff whose maintenance exceeds its benefit. > 3. Not just FreeBSD, but also Linux and Mac OS use these files, and > they appear to get them from us. NetBSD and OpenBSD also have > variants on these files, including errors that I've fixed over the > years. > Sounds like the perfect project to cleave off to allow all groups to contribute without it becoming a partisan 'which os' affair. > 4. Unnamed people in the FreeBSD project are upset about the > continuing presence of our version of these files in the FreeBSD > tree. > > 5. There are claims that it has to be fixed Right Now, with no delay. > The claim is that you've been ignoring concerns that have been raised going back years, and that you seem poised to continue to do so since there's no articulated timeline. > 6. The "fix" involves moving the files somewhere else, without fixing > them. > The "fix" is to create a centralized location for all groups to contribute and curate rather than to continue to have the efforts diluted by segregation. > What I see is an opportunity. We should get the other projects on > board and agree on a central repository for all projects. Probably > this would be GitHub, as you have suggested. But maybe there's one > there already, and if we want to get the other projects on board, we > should discuss it with them. > > So why not just accept se@'s proposal? It has the obvious advantages > of making sense and silencing the spirits which are tormenting you. > My concern is that it will then be forgotten, and we will miss the > opportunity to unify the data. > I wouldn't say so much tormenting as a recognition that the current structure provides too much friction to fix things. Other groups that just take from us do not create an obligation for the project to do anything in particular. It's the nice thing to do to help them out, but it's really the wrong mindset and structure. We learned from the 'tar' rewrite that it's sometimes better to locate bits of the project outside the project to give them a life of their own. In so doing, libarchive grew up to be a widely deployed thing, with bug fixes coming in from all over making it better than it would have been had it remained inside the project. Same with jemalloc. > So: a concrete proposal. > > 1. We accept se@'s split as a first step. > > 2. You personally agree to follow up with the other projects and > ensure that the data will end up on an OS-neutral platform from > which all projects can draw their data. > So your proposal is for me to do more work? I'll setup the github repo, give people permissions to do the work. Others will need to do the work. > 3. You agree to do this with a firm timeline. Since it seems that 6 > months is too long, how about by the end of 2020? > So now your timeline is for me to do more work? That sounds like my timeline, not yours. > You're still involved with NetBSD and OpenBSD, right? That should > make things easier. I'll happily chase up the Linux people, and > presumably there are people here who can get Apple involved, if > they're still interested. > Or we could just create a github repo, publicize it and see what happens? I'm not so involved in OpenBSD and NetBSD these days, so can't help much there. > How does that sound? > I think it sounds lousy, honestly. It's a lot of bother that you're trying to stick me with when you've held yourself out as the maintainer of this software. Warner From owner-freebsd-arch@freebsd.org Thu Oct 22 15:15:05 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 0A69644ADFE for ; Thu, 22 Oct 2020 15:15:05 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CH9s34pZvz41lZ for ; Thu, 22 Oct 2020 15:15:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fc4cc8e.dip0.t-ipconnect.de [79.196.204.142]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 09MFEuMJ033116 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Oct 2020 17:15:00 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 09MFEt4Q038317 for ; Thu, 22 Oct 2020 17:14:55 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 09MFEjop026359 for ; Thu, 22 Oct 2020 17:14:55 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202010221514.09MFEjop026359@fire.js.berklix.net> To: "freebsd-arch@freebsd.org" Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Wed, 21 Oct 2020 12:23:23 +1100." <20201021012323.GA59592@eureka.lemis.com> Date: Thu, 22 Oct 2020 17:14:45 +0200 X-Rspamd-Queue-Id: 4CH9s34pZvz41lZ X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [2.16 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; URI_HIDDEN_PATH(1.00)[http://berklix.com/~jhs/bin/.csh/customise]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-0.33)[-0.333]; NEURAL_HAM_SHORT(-0.18)[-0.181]; NEURAL_SPAM_LONG(0.78)[0.779]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; RECEIVED_SPAMHAUS_PBL(0.00)[79.196.204.142:received] 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: Thu, 22 Oct 2020 15:15:05 -0000 Sorry for coming late to thread, I've been travelling then catching up. "Greg 'groggy' Lehey" wrote: Wed, 21 Oct 2020 12:23:23 +1100 > On Monday, 19 October 2020 at 22:46:56 -0600, Warner Losh wrote: > > On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey wrote: > >> 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. > > It seems that I'll have to. Nobody else has mentioned this recently, > and we don't have enough clarity on what "crusty old files" means. Some errors include: - mixing up religious days versus state defined public holidays in wrong files - failing to explicitly state if just religios or guaranteed day of work (locals may know, but visitors planning ahead to another country may not) - some holiday only valid within parts of a country eg in some German regions), - spurious listing of obscure american events in international, - uneven priority of major & minor events, - insufficient skeletal structure to move stuff & include extra by country/region/city/interest_eg_tech_arts I submitted & got a few fixes commited (eg wrong definition of easter or some easter related in Austria not Germany I recall, was one) but many remain. A lot of the calendars failed in many ways for years, but it'd have been like kicking a dead whale up a beach to find & convince others who have commit bits to tackle the un-inspiring job of loads of commits to regularise & correct & update many calendar files. Years ago I started my own tree of diffs & new files which I auto. apply to src/ of each new release since I started, using my own customise shell http://berklix.com/~jhs/bin/.csh/customise but of course one can hand apply any diff. http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/ Makefile.REL=10.3-RELEASE.diff Makefile.REL=10.3-STABLE.diff Makefile.REL=10.4-RELEASE.diff Makefile.REL=11.2-RELEASE.diff Makefile.REL=12.1-RELEASE.diff Makefile.REL=12.2-STABLE.diff Makefile.REL=7.4-RELEASE.diff Makefile.REL=8.4-RELEASE.diff Makefile.REL=9.2-RELEASE.diff Makefile.REL=9.3-RELEASE.diff Makefile.REL=CURRENT.diff README.JHS calendar.1.REL=ALL.diff calendar.1.dir.REL=9.1-RELEASE.diff calendar.c.JJLATER calendars calendars/calendar.all.REL=10.3-RELEASE.diff calendars/calendar.all.REL=10.3-STABLE.diff calendars/calendar.all.REL=10.4-RELEASE.diff calendars/calendar.all.REL=11.2-RELEASE.diff calendars/calendar.all.REL=12.1-RELEASE.diff calendars/calendar.all.REL=12.2-STABLE.diff calendars/calendar.all.REL=7.4-RELEASE.diff calendars/calendar.all.REL=8.4-RELEASE.diff calendars/calendar.all.REL=9.2-RELEASE.diff calendars/calendar.all.REL=9.3-RELEASE.diff calendars/calendar.all.REL=CURRENT.diff calendars/calendar.british calendars/calendar.history calendars/calendar.holiday calendars/calendar.holiday.send-pr calendars/de_AT.ISO_8859-15 calendars/de_AT.ISO_8859-15/calendar.feiertag.REL=10.4-RELEASE.diff calendars/de_AT.ISO_8859-15/calendar.feiertag.REL=11.2-RELEASE.diff calendars/de_AT.ISO_8859-15/calendar.feiertag.REL=8.4-RELEASE.diff calendars/de_AT.ISO_8859-15/calendar.feiertag.REL=9.2-RELEASE.diff calendars/de_AT.ISO_8859-15/calendar.feiertag.REL=9.3-RELEASE.diff calendars/de_DE.ISO8859-1 calendars/de_DE.ISO8859-1/README calendars/de_DE.ISO8859-1/bavaria calendars/de_DE.ISO8859-1/bavaria/README calendars/de_DE.ISO8859-1/bavaria/calendar.holidays calendars/de_DE.ISO8859-1/bavaria/calendar.other calendars/de_DE.ISO8859-1/bavaria/muenchen calendars/de_DE.ISO8859-1/bavaria/munich calendars/de_DE.ISO8859-1/bavaria/munich/README calendars/de_DE.ISO8859-1/bavaria/munich/calendar.andere calendars/de_DE.ISO8859-1/bavaria/munich/calendar.other calendars/de_DE.ISO8859-1/bavaria/munich/calendar.technical calendars/de_DE.ISO8859-1/bavaria/munich/calendar.technik calendars/de_DE.ISO8859-1/bayern calendars/de_DE.ISO8859-1/calendar.feiertag calendars/de_DE.ISO8859-1/nrw calendars/de_DE.ISO8859-1/nrw/README calendars/de_DE.ISO8859-1/nrw/aachen calendars/de_DE.ISO8859-1/nrw/aachen/calendar.technical calendars/de_DE.ISO8859-1/nrw/calendar.feiertage calendars/de_DE.ISO8859-1/nrw/calendar.holidays calendars/en_UK.ISO8859-1 calendars/en_UK.ISO8859-1/README calendars/en_UK.ISO8859-1/calendar.all calendars/en_UK.ISO8859-1/calendar.events calendars/en_UK.ISO8859-1/calendar.finance calendars/en_UK.ISO8859-1/calendar.history calendars/en_UK.ISO8859-1/calendar.holidays calendars/en_UK.ISO8859-1/calendar.other calendars/en_UK.ISO8859-1/calendar.religious calendars/fr_FR.ISO8859-1 calendars/fr_FR.ISO8859-1/calendar.jferies.REL=ALL.diff Cheers, -- Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ Crash Brexit profits financial speculators in cabinet damaging Britain. UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.uk From owner-freebsd-arch@freebsd.org Thu Oct 22 17:08:41 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 1E1A144DA48 for ; Thu, 22 Oct 2020 17:08:41 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 4CHDN82fcxz49LK for ; Thu, 22 Oct 2020 17:08:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x844.google.com with SMTP id c15so1676352qtc.2 for ; Thu, 22 Oct 2020 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6AB2TxJmg38ZyINsqq2W6in96HvC1Eb9bqK+iW01csc=; b=kZb/F5mvP41SJviqJpQFUubVuwpAuF4578B5RKuOEasHjJjgXrQpd1HYPCdtTlaEAc suVi4hbRUxcEcq3Nvf/lvO93pStz+FzxADUq6qcAAm+x0/c9cw0KboSW+fzpG3Lr+5l7 x65vDhHsFGOF5sCaLHnLCmPVJh3x6Q1u7Pn5lSHOf22buA6gLd6t4rYLEXybysZ/83o6 F5BtSlmIHHq0tuI02fo3u3UwaNAem8Fxi7rLdS/mrOGxcR8FddMMhDKKmiFjHxHymdrP NdlI4cjPBmWJNY0kOyiSuFtFNUMd32i4T3lzco8ON2obPr7Ho7yRZ00kfdcneuMGEpRq HhxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6AB2TxJmg38ZyINsqq2W6in96HvC1Eb9bqK+iW01csc=; b=XjuKE0oHtbLikkTa798ecETrXSw5OVTtHv4iv7NbIGha69dFYcC1s9OhZpqVRxiIxz K2+pWWNMpmUrhOUU+puZUju5FzOyJyZhge1hyIvKJ/kxsPIsujuTk7KDWzuuxijcK89v q2wqZnGBNJIwKNsNrhuNMOF8Nv+DBZUH76NV3bkpgGbgd24/vEX8Hx2SSL8QL5hQ/qlt PBvn5j3YKtYoP7h44BVyjWyfOCEcIEeQjkphBhe2aWMaySe6K+4JZLneay/UquNv75Zg J5aHXEzIaZwwxOe4Mk0kYdekMVSx/VVyI+3zFLmUTAxlUizOUaNwhE8TanU26esKNFUJ 30sw== X-Gm-Message-State: AOAM531IgVN86xWyVbY01pn12CXLpXDQQqG1ykpkwsTGi7KbzLI8Cgwr 91x4H5FKj8FE+iylPykUJ7RqdA== X-Google-Smtp-Source: ABdhPJw/VdSi8/VxwVP3+oMpXLi2ynGllYp3d56smVRxa35df/ZNR9D+T8P7hUqv9m65Xcxx3TEktw== X-Received: by 2002:ac8:5315:: with SMTP id t21mr2973052qtn.64.1603386519421; Thu, 22 Oct 2020 10:08:39 -0700 (PDT) Received: from mutt-hbsd ([38.140.209.220]) by smtp.gmail.com with ESMTPSA id y77sm1382922qkb.57.2020.10.22.10.08.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 10:08:38 -0700 (PDT) Date: Thu, 22 Oct 2020 13:08:38 -0400 From: Shawn Webb To: Stefan Esser Cc: Greg 'groggy' Lehey , Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022170838.2lludopafqsnsf62@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="igqshryntf6qvzjw" Content-Disposition: inline In-Reply-To: <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> X-Rspamd-Queue-Id: 4CHDN82fcxz49LK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=kZb/F5mv; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::844 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_HAM_LONG(-1.01)[-1.010]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.44)[-0.441]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::844:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Thu, 22 Oct 2020 17:08:41 -0000 --igqshryntf6qvzjw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 21, 2020 at 12:03:33PM +0200, Stefan Esser wrote: > Am 21.10.20 um 09:15 schrieb Stefan Esser: > > Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey: > > [...] > > > That's the whole point.? Where do we draw the line?? Given that these > > > holidays interest more people outside the project than in, I'd think > > > that they should all go into the port.? And the whole idea of > > > alternative 3 is that the maintenance should be automatic and > > > external, so updating holidays should no longer be our concern. > >=20 > > Are we taling about the calendar binary or the calendar files? > >=20 > > IMHO, the calendar binary could stay in base but be modified to > > scan directories in e.g. /usr/local/share/calendar/ and ports > > could provide these calendar files. >=20 > I have created a Phabricator review for the proposed change: >=20 > https://reviews.freebsd.org/D26882 >=20 > This is just an enabler for calendar files in a directory that > can be maintained by means of a port. >=20 > A suggested port has been made available for review, too: >=20 > https://reviews.freebsd.org/D26883 https://git-01.md.hardenedbsd.org/HardenedBSD/HardenedBSD/commit/4055c7d50e= c5389715206ab800fc88d25c55fcaa Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --igqshryntf6qvzjw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl+RvJMACgkQ/y5nonf4 4foIsg//c39Y+8nvmlOO3I6gZVhHv9Y2Zpn81nY9CYwGaM0doLezI5qGg7AaLYbi yRHXyyhKBlWfPLx+2OjnZgM+nfVl0YvNhBl4aF0+fohxUY+WgzxvHxDVqIC4Pg83 H7tHo2zq8px6oN2nnGUJEX26TeGOLciiQ6bf1FxBq6aYyzDlbS3raiZRf6tgfS+p GWGdraDkuH+0u5TnBbgB0JKJtV0wcQnOT0B5R21xheIJ51q+ktH1dy9uTR6k0frb D3b2grMqrMEt7rVcfW8HxwWHKGQJuRGItWMPJ8ROdunayG4H1kgTN2SUaZQgec32 iKH3O0dDPxsrH90/KwtbtxW9f3pFJ1OwVBAU/QV+SrO4yc5NQ5L2eQsnssnaQnTd BaXmtcEwlMwTt0jRai487PmgC5sLKN+Zv3snsnWYCSZjOiyUs2bmJVnRAl/3Zn+X 8VXJYQNyv/FQrkmOwrbJ/KLWYoQqoVuZQ2kk8p07zAWMUQ4kE81qqsxa+MrUzadX SSxE6bhA5MmYi+k/xAxoVSHPaa+WWvCur3Fti1zhmMc8wEcA9OsRTbkGddTwlzxE QvJ2TXQImaxLmxzLa/Xy2bL824w9ytvb2sws2TPZajyXRob6d2MOlfWrNtycz5Sa YpA5mij+SQwGyyq8GuY3NQAlTqNRKEtYdYZ6hJDXSkq5yBQyr2Y= =GXfC -----END PGP SIGNATURE----- --igqshryntf6qvzjw-- From owner-freebsd-arch@freebsd.org Thu Oct 22 22:12:13 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 F0D3E42C726 for ; Thu, 22 Oct 2020 22:12:13 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CHM6N4vYGz4Yk5; Thu, 22 Oct 2020 22:12:12 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id B293D280AF; Thu, 22 Oct 2020 22:12:05 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 09E4B26359C; Fri, 23 Oct 2020 09:12:05 +1100 (AEDT) Date: Fri, 23 Oct 2020 09:12:05 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: Stefan Esser , "freebsd-arch@freebsd.org" Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022221205.GJ59592@eureka.lemis.com> References: <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> <20201022044930.GF59592@eureka.lemis.com> <20201022063536.GG59592@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BEa57a89OpeoUzGD" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CHM6N4vYGz4Yk5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-2.43 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.975]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.23)[0.234]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.888]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 22 Oct 2020 22:12:14 -0000 --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 22 October 2020 at 7:56:57 -0600, Warner Losh wrote: > On Thu, Oct 22, 2020 at 12:35 AM Greg 'groggy' Lehey wrote: >> What I see is a somewhat emotional response without clear reasoning. >> FWIW, yes, I've been paying attention, and saving all relevant emails. >> My proposal is about as good as it goes without input from other >> projects. And nobody has explained why 24 years is OK, but suddenly 6 >> months is too long. > > It's decayed for 24 years. The issue has actually been a lack of curating > for about 5 years when the rumblings started now with no motion in 6 months > on the problem. The lack of urgency on your part doesn't make it any less a > problem. It doesn't seem to be a problem in any other project. > Calling it emotional on my part is a way to deflect from the issue: No, you're really getting yourself worked up. Sorry about that. It wasn't my intention. > these files are badly curated and should be discarded or modernized > or something in between. On which we're agreed. When you first contacted me on the subject a month ago, I wrote: On Wednesday, 23 September 2020 at 11:53:16 +1000, Greg 'groggy' Lehey wrote: > Yes, I have been thinking about it. There are arguments on both > sides. As you say, "the contentious bits". As others say, the > non-FreeBSD files are an ananchronism. They're also seriously out > of date. On the other hand, there's interesting FreeBSD stuff there > too, and I think that belongs there. Certainly calendar(1) should > stay. I wouldn't want to see FreeBSD fragment the way most Linux > distros do. (end quote) > The fact that this issue has been brought up many times, only to > have it ignored is what's getting people upset. And you still haven't produced any evidence for this. > The fact that there's no firm timeline to a fix is also troubling. To you? Or to whom? >> In principle se@'s proposal is good. But my concern is >> that then the matter will be forgotten, and the problem will be left >> half fixed. > > Then undertake the time to fix them if you are worried. I would do so, but you're hurrying. > Let's summarize: >> >> 1. We have an program from 4BSD with old, mouldy data files that have >> outlived their purpose. >> >> 2. But we can't just discard them without finding a better >> alternative. > > We can, actually. We do it all the time for stuff whose maintenance exceeds > its benefit. But there's almost no maintenance. That's the issue. And Apple seems to be happy enough to use versions of the data files that are well over 10 years out of date. >> 3. Not just FreeBSD, but also Linux and Mac OS use these files, and >> they appear to get them from us. NetBSD and OpenBSD also have >> variants on these files, including errors that I've fixed over the >> years. > > Sounds like the perfect project to cleave off to allow all groups to > contribute without it becoming a partisan 'which os' affair. Exactly. That was part of my proposal. >> 4. Unnamed people in the FreeBSD project are upset about the >> continuing presence of our version of these files in the FreeBSD >> tree. >> >> 5. There are claims that it has to be fixed Right Now, with no delay. > > The claim is that you've been ignoring concerns that have been > raised going back years, The first time I saw this mentioned was a month ago (see quote above). > and that you seem poised to continue to do so since there's no > articulated timeline. I thought I had been pretty active in the discussion. And I haven't seen any such claims. Who made them, and why aren't they involved in this discussion? But what does this have to do with me? I'm not the maintainer, though you've made that claim in the past. I simply update obviously wrong entries when I see them. So do other people, though admittedly not as often. >> 6. The "fix" involves moving the files somewhere else, without fixing >> them. > > The "fix" is to create a centralized location for all groups to > contribute and curate rather than to continue to have the efforts > diluted by segregation. That was my suggestion, but it's not the one on the table. You apparently haven't checked whether such a location doesn't already exist. I've "checked" (sent email to people I thought might be able to help), but not received a reply yet. But that's what I wrote below: >> What I see is an opportunity. We should get the other projects on >> board and agree on a central repository for all projects. Probably >> this would be GitHub, as you have suggested. But maybe there's one >> there already, and if we want to get the other projects on board, we >> should discuss it with them. >> >> So why not just accept se@'s proposal? It has the obvious advantages >> of making sense and silencing the spirits which are tormenting you. >> My concern is that it will then be forgotten, and we will miss the >> opportunity to unify the data. >> >> So: a concrete proposal. >> >> 1. We accept se@'s split as a first step. >> >> 2. You personally agree to follow up with the other projects and >> ensure that the data will end up on an OS-neutral platform from >> which all projects can draw their data. > > So your proposal is for me to do more work? You're the person who's in such a hurry. It reflects your proposal for *me* to do more work. > I'll setup the github repo, give people permissions to do the > work. Others will need to do the work. Why set up a repo until you know it's needed? >> 3. You agree to do this with a firm timeline. Since it seems that 6 >> months is too long, how about by the end of 2020? > > So now your timeline is for me to do more work? That sounds like my > timeline, not yours. Exactly. I was just turning things around. You don't like it either, and I can understand that. But suddenly the urgency seems to have gone. >> How does that sound? > > I think it sounds lousy, honestly. It's a lot of bother that you're > trying to stick me with when you've held yourself out as the > maintainer of this software. Yes, it's a lot of bother, and you've been trying to stick me with it. But I'm not the maintainer, and I never have been. The only person who has ever claimed that I'm the maintainer is you, four months ago. Even then you used the term "informal maintainer". So, where do we go from here? If, understandably, you don't want to do the work, let's try to contact the other projects (notably Linux) and find out if they already have a repository with some version of the data files. Then we could make a meta-port that installs them. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --BEa57a89OpeoUzGD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+SA7UACgkQIubykFB6QiNPqQCdE888j3qVM3hPDRwV7PDvGzuT rKwAn1dUWH66LrkikFF1JjzY9Hp1/HHr =ZPT3 -----END PGP SIGNATURE----- --BEa57a89OpeoUzGD--