FWD: Re: svn commit: r365984 - head/usr.bin/calendar/calendars

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

FWD: Re: svn commit: r365984 - head/usr.bin/calendar/calendars

Shawn Webb-3
Forwarding to [hidden email] per Scott Long's request.

----- Forwarded message from Shawn Webb <[hidden email]> -----

Date: Tue, 22 Sep 2020 15:24:24 -0400
From: Shawn Webb <[hidden email]>
To: Gordon Bergling <[hidden email]>
Cc: Andriy Gapon <[hidden email]>, [hidden email], Cy Schubert
 <[hidden email]>, src-committers <[hidden email]>,
 svn-src-all <[hidden email]>, svn-src-head
 <[hidden email]>
Subject: Re: svn commit: r365984 - head/usr.bin/calendar/calendars

On Tue, Sep 22, 2020 at 09:18:43PM +0200, Gordon Bergling wrote:

> On Tue, Sep 22, 2020 at 09:01:46PM +0300, Andriy Gapon wrote:
> > On 22/09/2020 06:06, Conrad Meyer wrote:
> > > Big ol plus one from me.
> > >
> > > On Mon, Sep 21, 2020 at 4:16 PM Cy Schubert <[hidden email]> wrote:
> > >>
> > >> In message <[hidden email]>, Greg Lehey
> > >> writes:
> > >>> Author: grog
> > >>> Date: Mon Sep 21 22:55:51 2020
> > >>> New Revision: 365984
> > >>> URL: https://svnweb.freebsd.org/changeset/base/365984
> > >>>
> > >>> Log:
> > >>>   Remove claim that Allied Forces created "West Germany" in 1953.  I can
> > >>>   find no historic substantiation for such a claim.  The Federal
> > >>>   Republic of Germany was created by Germans on 23 May 1949, as also
> > >>>   noted in this file.
> > >>>
> > >>> Modified:
> > >>>   head/usr.bin/calendar/calendars/calendar.history
> > >>>
> > >>> Modified: head/usr.bin/calendar/calendars/calendar.history
> > >>> =============================================================================
> > >>> =
> > >>> --- head/usr.bin/calendar/calendars/calendar.history  Mon Sep 21 22:52:57 202
> > >>> 0     (r365983)
> > >>> +++ head/usr.bin/calendar/calendars/calendar.history  Mon Sep 21 22:55:51 202
> > >>> 0     (r365984)
> > >>> @@ -521,7 +521,6 @@
> > >>>  09/20        Magellan leaves Spain on the first Round the World passage, 151
> > >>> 9
> > >>>  09/20        The Roxy Theater opens in Hollywood, 1973
> > >>>  09/21        J. R. R. Tolkien's The Hobbit is published, 1937
> > >>> -09/22        Allied forces form the independent nation West Germany, 1953
> > >>>  09/22        US President Lincoln issues the Emancipation Proclamation, 1862
> > >>>  09/22        Special prosecutor Leon Jeworski subpoenas US President Nixon,
> > >>> 1974
> > >>>  09/22        The first Soviet atomic bomb explodes, 1949
> > >>>
> > >>
> > >> Does this file still need to be in FreeBSD? It may have been a novelty back
> > >> in the day but IMO calendar.history has nothing to do with BSD, computers
> > >> or anything else of interest to FreeBSD. At the very least this file should
> > >> be moved to ports or better yet, removed entirely. I simply don't see the
> > >> point of it being in the tree and distributed with an O/S, any O/S.
>
> We already had a similar discussion in march 2020 after r358561 [1].
>
> In the short, the calendar utility has it's historic place, even it's
> just more a kind of tradition, like adding yourself as a FreeBSD committer
> to calendar.freebsd.
>
> [1] https://lists.freebsd.org/pipermail/svn-src-all/2020-March/thread.html
Would it make sense to prune calendar entries to only BSD-related
entries?

----- End forwarded message -----

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: svn commit: r365984 - head/usr.bin/calendar/calendars

Warner Losh
On Wed, Sep 23, 2020 at 7:43 AM Shawn Webb <[hidden email]>
wrote:

> Forwarding to [hidden email] per Scott Long's request.
>
> ----- Forwarded message from Shawn Webb <[hidden email]> -----
>
> Date: Tue, 22 Sep 2020 15:24:24 -0400
> From: Shawn Webb <[hidden email]>
> To: Gordon Bergling <[hidden email]>
> Cc: Andriy Gapon <[hidden email]>, [hidden email], Cy Schubert
>  <[hidden email]>, src-committers <[hidden email]>,
>  svn-src-all <[hidden email]>, svn-src-head
>  <[hidden email]>
> Subject: Re: svn commit: r365984 - head/usr.bin/calendar/calendars
>
> On Tue, Sep 22, 2020 at 09:18:43PM +0200, Gordon Bergling wrote:
> > On Tue, Sep 22, 2020 at 09:01:46PM +0300, Andriy Gapon wrote:
> > > On 22/09/2020 06:06, Conrad Meyer wrote:
> > > > Big ol plus one from me.
> > > >
> > > > On Mon, Sep 21, 2020 at 4:16 PM Cy Schubert <
> [hidden email]> wrote:
> > > >>
> > > >> In message <[hidden email]>, Greg
> Lehey
> > > >> writes:
> > > >>> Author: grog
> > > >>> Date: Mon Sep 21 22:55:51 2020
> > > >>> New Revision: 365984
> > > >>> URL: https://svnweb.freebsd.org/changeset/base/365984
> > > >>>
> > > >>> Log:
> > > >>>   Remove claim that Allied Forces created "West Germany" in 1953.
> I can
> > > >>>   find no historic substantiation for such a claim.  The Federal
> > > >>>   Republic of Germany was created by Germans on 23 May 1949, as
> also
> > > >>>   noted in this file.
> > > >>>
> > > >>> Modified:
> > > >>>   head/usr.bin/calendar/calendars/calendar.history
> > > >>>
> > > >>> Modified: head/usr.bin/calendar/calendars/calendar.history
> > > >>>
> =============================================================================
> > > >>> =
> > > >>> --- head/usr.bin/calendar/calendars/calendar.history  Mon Sep 21
> 22:52:57 202
> > > >>> 0     (r365983)
> > > >>> +++ head/usr.bin/calendar/calendars/calendar.history  Mon Sep 21
> 22:55:51 202
> > > >>> 0     (r365984)
> > > >>> @@ -521,7 +521,6 @@
> > > >>>  09/20        Magellan leaves Spain on the first Round the World
> passage, 151
> > > >>> 9
> > > >>>  09/20        The Roxy Theater opens in Hollywood, 1973
> > > >>>  09/21        J. R. R. Tolkien's The Hobbit is published, 1937
> > > >>> -09/22        Allied forces form the independent nation West
> Germany, 1953
> > > >>>  09/22        US President Lincoln issues the Emancipation
> Proclamation, 1862
> > > >>>  09/22        Special prosecutor Leon Jeworski subpoenas US
> President Nixon,
> > > >>> 1974
> > > >>>  09/22        The first Soviet atomic bomb explodes, 1949
> > > >>>
> > > >>
> > > >> Does this file still need to be in FreeBSD? It may have been a
> novelty back
> > > >> in the day but IMO calendar.history has nothing to do with BSD,
> computers
> > > >> or anything else of interest to FreeBSD. At the very least this
> file should
> > > >> be moved to ports or better yet, removed entirely. I simply don't
> see the
> > > >> point of it being in the tree and distributed with an O/S, any O/S.
> >
> > We already had a similar discussion in march 2020 after r358561 [1].
> >
> > In the short, the calendar utility has it's historic place, even it's
> > just more a kind of tradition, like adding yourself as a FreeBSD
> committer
> > to calendar.freebsd.
> >
> > [1]
> https://lists.freebsd.org/pipermail/svn-src-all/2020-March/thread.html
>
> Would it make sense to prune calendar entries to only BSD-related
> entries?
>

First off, thanks for sending this. It gets the ball rolling...

However, this really isn't an actionable proposal. You can't just svn rm
some of the files, that will break things. Also, which files should you
remove? Without a concrete plan and someone signed up to do it, nothing is
going to happen, even if there's a dozen +1's here.

Fortunately, I have already contacted grog@ directly. He was quite
receptive to my email suggesting something be done. After a couple of
rounds, there's the rough plan we're talking about. Briefly:

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

So, it's just an outline at this time, which is why I hadn't sent a
concrete proposal here just yet. Wanted to at least get a list of the files
that would remain so we can have an intelligent discussion about those, but
since this showed up I thought I'd send a heads up so people know what's
going on.

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

Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg 'groggy' Lehey-3
[Trimmed]

People, please adjust your posts.  It's hard fighting your way through
a lot of expired verbiage.

On Wednesday, 23 September 2020 at  9:18:27 -0600, Warner Losh wrote:

> On Wed, Sep 23, 2020 at 7:43 AM Shawn Webb <[hidden email]>
> wrote:
>
>> Would it make sense to prune calendar entries to only BSD-related
>> entries?
>
> Fortunately, I have already contacted grog@ directly. He was quite
> receptive to my email suggesting something be done. After a couple of
> rounds, there's the rough plan we're talking about. Briefly:
>
> 1. ...
>
> So, it's just an outline at this time, which is why I hadn't sent a
> concrete proposal here just yet. Wanted to at least get a list of
> the files that would remain so we can have an intelligent discussion
> about those, but since this showed up I thought I'd send a heads up
> so people know what's going on.
The real issue is: what do we remove?  Summarizing imp@'s points, I
think that the base functionality of calendar(1) should stay, and so
should the FreeBSD-related calendar files.  There's really a question
as to whether the non-FreeBSD related ones should remain anywhere
(including as a port).  As somebody said, they're a relict of a bygone
day, and some are very inaccurate.  I seem to be the only one
maintaining them, and even that is not without criticism.  It might be
a better idea to write a completely new port that sucks in calendar
entries from *somewhere* and makes BSD-compliant calendar files out of
them.  So, as imp@ says, it would be good to discuss which files
should go and which should remain.

While I have your attention, does anybody think that the -a option of
calendar(1) is worth keeping?  It goes through *all* calendar files on
a system and mails them to the owner.  It has the interesting side
effect (we wouldn't want to call it a bug) that root gets three copies
(one each for root, toor and daemon).  I can't see anything useful
there that a per-user cron job can't do.

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

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Rodney W. Grimes-6
-- Start of PGP signed section.

> [Trimmed]
>
> People, please adjust your posts.  It's hard fighting your way through
> a lot of expired verbiage.
>
> On Wednesday, 23 September 2020 at  9:18:27 -0600, Warner Losh wrote:
> > On Wed, Sep 23, 2020 at 7:43 AM Shawn Webb <[hidden email]>
> > wrote:
> >
> >> Would it make sense to prune calendar entries to only BSD-related
> >> entries?
> >
> > Fortunately, I have already contacted grog@ directly. He was quite
> > receptive to my email suggesting something be done. After a couple of
> > rounds, there's the rough plan we're talking about. Briefly:
> >
> > 1. ...
> >
> > So, it's just an outline at this time, which is why I hadn't sent a
> > concrete proposal here just yet. Wanted to at least get a list of
> > the files that would remain so we can have an intelligent discussion
> > about those, but since this showed up I thought I'd send a heads up
> > so people know what's going on.
>
> The real issue is: what do we remove?  Summarizing imp@'s points, I
> think that the base functionality of calendar(1) should stay, and so
> should the FreeBSD-related calendar files.  There's really a question
> as to whether the non-FreeBSD related ones should remain anywhere
> (including as a port).  As somebody said, they're a relict of a bygone
> day, and some are very inaccurate.  I seem to be the only one
> maintaining them, and even that is not without criticism.  It might be
> a better idea to write a completely new port that sucks in calendar
> entries from *somewhere* and makes BSD-compliant calendar files out of
> them.  So, as imp@ says, it would be good to discuss which files
> should go and which should remain.
>
> While I have your attention, does anybody think that the -a option of
> calendar(1) is worth keeping?  It goes through *all* calendar files on
> a system and mails them to the owner.  It has the interesting side
> effect (we wouldn't want to call it a bug) that root gets three copies
> (one each for root, toor and daemon).  I can't see anything useful
> there that a per-user cron job can't do.

What the per-user cron job does is create a larger workload for
systems that are expecting all users to be running calendar, as
possible in an acedemic system which each student has a login.

One may even setup systems that pre-populate account calendar
files with such data.  Though this is also probably a "long gone"
era, I would not rule out that someone may be doing this.

And as I have stated in other threads on the -a option, it
is totally valid that a site may seperate root and toor, infact
I do that on 2 of my systems.  And the daemon thing is, well,
easily fixed if one is annoyed by it to change to /etc/alias
entry to dump daemon mail to /dev/null.  And IMHO it is just
kinda "wrong" for root to have a .calendar file anyway, that
is using root for things you probably should not be doing.

> 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
-- End of PGP section, PGP failed!

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

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Cy Schubert-4
In message <[hidden email]>, "Rodney W.
Grimes"
writes:

> -- Start of PGP signed section.
> > [Trimmed]
> >
> > People, please adjust your posts.  It's hard fighting your way through
> > a lot of expired verbiage.
> >
> > On Wednesday, 23 September 2020 at  9:18:27 -0600, Warner Losh wrote:
> > > On Wed, Sep 23, 2020 at 7:43 AM Shawn Webb <[hidden email]>
> > > wrote:
> > >
> > >> Would it make sense to prune calendar entries to only BSD-related
> > >> entries?
> > >
> > > Fortunately, I have already contacted grog@ directly. He was quite
> > > receptive to my email suggesting something be done. After a couple of
> > > rounds, there's the rough plan we're talking about. Briefly:
> > >
> > > 1. ...
> > >
> > > So, it's just an outline at this time, which is why I hadn't sent a
> > > concrete proposal here just yet. Wanted to at least get a list of
> > > the files that would remain so we can have an intelligent discussion
> > > about those, but since this showed up I thought I'd send a heads up
> > > so people know what's going on.
> >
> > The real issue is: what do we remove?  Summarizing imp@'s points, I
> > think that the base functionality of calendar(1) should stay, and so
> > should the FreeBSD-related calendar files.  There's really a question
> > as to whether the non-FreeBSD related ones should remain anywhere
> > (including as a port).  As somebody said, they're a relict of a bygone
> > day, and some are very inaccurate.  I seem to be the only one
> > maintaining them, and even that is not without criticism.  It might be
> > a better idea to write a completely new port that sucks in calendar
> > entries from *somewhere* and makes BSD-compliant calendar files out of
> > them.  So, as imp@ says, it would be good to discuss which files
> > should go and which should remain.
> >
> > While I have your attention, does anybody think that the -a option of
> > calendar(1) is worth keeping?  It goes through *all* calendar files on
> > a system and mails them to the owner.  It has the interesting side
> > effect (we wouldn't want to call it a bug) that root gets three copies
> > (one each for root, toor and daemon).  I can't see anything useful
> > there that a per-user cron job can't do.
>
> What the per-user cron job does is create a larger workload for
> systems that are expecting all users to be running calendar, as
> possible in an acedemic system which each student has a login.

Have it use libxo might be a good exercise for someone wanting to get back
into it after a while, or a student.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  https://FreeBSD.org
NTP:           <[hidden email]>    Web:  https://nwtime.org

        The need of the many outweighs the greed of the few.


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

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg 'groggy' Lehey-3
On Thursday, 24 September 2020 at 14:35:10 -0700, Cy Schubert wrote:
> In message <[hidden email]>, "Rodney W.
> Grimes"
> writes:
>> -- Start of PGP signed section.
>>> [Trimmed]
>>>
>>> People, please adjust your posts.  It's hard fighting your way through
>>> a lot of expired verbiage.

Thanks for the trimming.

>>> While I have your attention, does anybody think that the -a option of
>>> calendar(1) is worth keeping?  It goes through *all* calendar files on
>>> a system and mails them to the owner.  It has the interesting side
>>> effect (we wouldn't want to call it a bug) that root gets three copies
>>> (one each for root, toor and daemon).  I can't see anything useful
>>> there that a per-user cron job can't do.
>>
>> What the per-user cron job does is create a larger workload for
>> systems that are expecting all users to be running calendar, as
>> possible in an acedemic system which each student has a login.
>
> Have it use libxo might be a good exercise for someone wanting to get back
> into it after a while, or a student.
How would that address the issue?

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

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Cy Schubert-4
In message <[hidden email]>, "Greg 'groggy' Lehey"
wri
tes:

>
>
> --xXmbgvnjoT4axfJE
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thursday, 24 September 2020 at 14:35:10 -0700, Cy Schubert wrote:
> > In message <[hidden email]>, "Rodney W.
> > Grimes"
> > writes:
> >> -- Start of PGP signed section.
> >>> [Trimmed]
> >>>
> >>> People, please adjust your posts.  It's hard fighting your way through
> >>> a lot of expired verbiage.
>
> Thanks for the trimming.
>
> >>> While I have your attention, does anybody think that the -a option of
> >>> calendar(1) is worth keeping?  It goes through *all* calendar files on
> >>> a system and mails them to the owner.  It has the interesting side
> >>> effect (we wouldn't want to call it a bug) that root gets three copies
> >>> (one each for root, toor and daemon).  I can't see anything useful
> >>> there that a per-user cron job can't do.
> >>
> >> What the per-user cron job does is create a larger workload for
> >> systems that are expecting all users to be running calendar, as
> >> possible in an acedemic system which each student has a login.
> >
> > Have it use libxo might be a good exercise for someone wanting to get back
> > into it after a while, or a student.
>
> How would that address the issue?

Adding libxo will allow it to be used for some kitschy website. That
coupled with a port generating a file, a person may have something.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  https://FreeBSD.org
NTP:           <[hidden email]>    Web:  https://nwtime.org

        The need of the many outweighs the greed of the few.


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

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg Balfour
In reply to this post by Greg 'groggy' Lehey-3
On Thu, Sep 24, 2020 at 09:07:08AM +1000, Greg 'groggy' Lehey wrote:
>
> While I have your attention, does anybody think that the -a option of
> calendar(1) is worth keeping?  It goes through *all* calendar files on
> a system and mails them to the owner.  It has the interesting side
> effect (we wouldn't want to call it a bug) that root gets three copies
> (one each for root, toor and daemon).  I can't see anything useful
> there that a per-user cron job can't do.

I actually use the -a option.  But it hasn't fully worked since 10.0-RELEASE.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580
Still present in 12.2-BETA2.

I maintain a local set of patches that solves this bug, but it requires the
installation of the tradcpp port/package so I've never shared them, but
would if someone wants them.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg Balfour
In reply to this post by Greg 'groggy' Lehey-3
On Thu, Sep 24, 2020 at 09:07:08AM +1000, Greg 'groggy' Lehey wrote:
>
> While I have your attention, does anybody think that the -a option of
> calendar(1) is worth keeping?  It goes through *all* calendar files on
> a system and mails them to the owner.  It has the interesting side
> effect (we wouldn't want to call it a bug) that root gets three copies
> (one each for root, toor and daemon).  I can't see anything useful
> there that a per-user cron job can't do.

I actually use the -a option.  But it hasn't fully worked since 10.0-RELEASE.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580
Still present in 12.2-BETA2.

I maintain a local set of patches that solves this bug, but it requires the
installation of the tradcpp port/package so I've never shared them, but
would if someone wants them.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg 'groggy' Lehey-3
On Sunday, 27 September 2020 at 23:25:20 -0500, Greg Balfour wrote:

> On Thu, Sep 24, 2020 at 09:07:08AM +1000, Greg 'groggy' Lehey wrote:
>>
>> While I have your attention, does anybody think that the -a option of
>> calendar(1) is worth keeping?  It goes through *all* calendar files on
>> a system and mails them to the owner.  It has the interesting side
>> effect (we wouldn't want to call it a bug) that root gets three copies
>> (one each for root, toor and daemon).  I can't see anything useful
>> there that a per-user cron job can't do.
>
> I actually use the -a option.  But it hasn't fully worked since 10.0-RELEASE.
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580
> Still present in 12.2-BETA2.
Interesting.

> I maintain a local set of patches that solves this bug, but it
> requires the installation of the tradcpp port/package so I've never
> shared them, but would if someone wants them.

You could add them to the bug report; arguably they would point to a
way to fix it without tradcpp.  But my real concern is described in
bug 246943, and so far I don't see a clean solution for that.

Does root have a calendar file on your systems?  If so, how do you
handle the multiple emails?  Your input on 246943 would be
interesting.

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

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg Balfour
On Sun, Sep 27, 2020 at 11:57 PM Greg 'groggy' Lehey <[hidden email]> wrote:

>
> On Sunday, 27 September 2020 at 23:25:20 -0500, Greg Balfour wrote:
> > On Thu, Sep 24, 2020 at 09:07:08AM +1000, Greg 'groggy' Lehey wrote:
> >>
> >> While I have your attention, does anybody think that the -a option of
> >> calendar(1) is worth keeping?  It goes through *all* calendar files on
> >> a system and mails them to the owner.  It has the interesting side
> >> effect (we wouldn't want to call it a bug) that root gets three copies
> >> (one each for root, toor and daemon).  I can't see anything useful
> >> there that a per-user cron job can't do.
> >
> > I actually use the -a option.  But it hasn't fully worked since 10.0-RELEASE.
> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580
> > Still present in 12.2-BETA2.
>
> Interesting.
>
> > I maintain a local set of patches that solves this bug, but it
> > requires the installation of the tradcpp port/package so I've never
> > shared them, but would if someone wants them.
>
> You could add them to the bug report; arguably they would point to a
> way to fix it without tradcpp.  But my real concern is described in
> bug 246943, and so far I don't see a clean solution for that.
>
> Does root have a calendar file on your systems?  If so, how do you
> handle the multiple emails?  Your input on 246943 would be
> interesting.

I've added my patch to bug 205580.

As fas as bug 246943 goes, I've never had a .calendar in root so
I've never had to consider this issue.  But I would agree with
comment #4 in the report.  For a fix, I think adding a knob in
calendar files per comment #13 is the best solution.

However I would not be against removing the -a flag.  I would just
refactor my use case of calendar(1).  I'm tired of keeping my patch
up to date so I may just go that route anyway.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg 'groggy' Lehey-3
In reply to this post by Warner Losh
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Warner Losh
On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey <[hidden email]>
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Shawn Webb-3
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 <[hidden email]>
> 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."

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Warner Losh
On Tue, Oct 20, 2020, 6:28 AM Shawn Webb <[hidden email]> 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 <[hidden email]>
> > 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
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Shawn Webb-3
On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote:

> On Tue, Oct 20, 2020, 6:28 AM Shawn Webb <[hidden email]> 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 <[hidden email]>
> > > 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.
Yup yup. Agreed on all parts. :)

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Gordon Bergling-4
In reply to this post by Warner Losh
On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote:

> On Tue, Oct 20, 2020, 6:28 AM Shawn Webb <[hidden email]> 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 <[hidden email]>
> > > 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
Very well written! Thank you!

--Gordon

signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Greg 'groggy' Lehey-3
In reply to this post by Warner Losh
[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 <[hidden email]> 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

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Stefan Esser-3
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.
>
> 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
===================================================================
--- io.c (Revision 366901)
+++ io.c (Arbeitskopie)
@@ -71,7 +71,7 @@
  };

  const char *calendarFile = "calendar"; /* default calendar file */
-static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /*
HOME */
+static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE,
_PATH_INCLUDE_LOCAL}; /* HOME */
  static const char *calendarNoMail = "nomail";/* don't sent mail if
file exist */

  static char path[MAXPATHLEN];
Index: pathnames.h
===================================================================
--- pathnames.h (Revision 366901)
+++ pathnames.h (Arbeitskopie)
@@ -34,4 +34,9 @@

  #include <paths.h>

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

OpenPGP_signature (505 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

Stefan Esser-3
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

OpenPGP_signature (505 bytes) Download Attachment
12