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--