Re: nmh 1.8?
Ralph Corderoy wrote: > Hi Andy, >> > Has anyone had a chance to review my proposed changes to inc to be > >> able to handle long lines from POP sources? > Is the latest in Git? I see the ‘andy-long-line-patch’ at > http://git.savannah.nongnu.org/cgit/nmh.git/refs/ with one commit: > http://git.savannah.nongnu.org/cgit/nmh.git/commit/?h=andy-long-line-patch=08dffe5aba9563ff06e82d2a8e6a6d746223d10f I pushed that in, and it's not the latest patch, I don't think.
Re: [nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 1.8-RC1-9-g68228e3c
>Agreed, it doesn't. They arrive as valid UTF-8 here which show just >fine so I hadn't noticed a problem, but it's clearly wrong. I expect >it's a bug in the script but have forgotten where is it to be found. I believe it is under the control of savannah. I am not sure it is really worth doing anything about now. --Ken
Re: [nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 1.8-RC1-9-g68228e3c
Hi Ken, > man/burst.man: re-word to avoid ‘digestifying’, etc. ... > when the email is sent out about the change I get them a little > mangled because the script that notifies about changes doesn't mark > that email as UTF-8. Agreed, it doesn't. They arrive as valid UTF-8 here which show just fine so I hadn't noticed a problem, but it's clearly wrong. I expect it's a bug in the script but have forgotten where is it to be found. > It looks like you CAN mark the encoding of commits using the config > variable i18n.commitEncoding, although this suggests the default is > UTF-8 and when I look at all the commit encodings they are blank, so > maybe I don't quite understand it? git-commit(1) covers it. The default for the log message is UTF-8. If the i18n.commitEncoding you gave is set then its value is copied into the commit's header. If that header isn't present then the log message is UTF-8. > I don't know if that would change the encoding marked in the > notification email. I doubt it. I think the script probably pre-dates the popularity of UTF-8. :-) -- Cheers, Ralph.
Re: [nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 1.8-RC1-9-g68228e3c
Ralph, I've noticed recently that you've been putting UTF-8 characters in commit messages. E.g: man/burst.man: re-word to avoid ‘digestifying’, etc. I'm personally fine with that, but when the email is sent out about the change I get them a little mangled because the script that notifies about changes doesn't mark that email as UTF-8. It looks like you CAN mark the encoding of commits using the config variable i18n.commitEncoding, although this suggests the default is UTF-8 and when I look at all the commit encodings they are blank, so maybe I don't quite understand it? I used this as a reference: https://www.git-tower.com/help/guides/faq-and-tips/faq/encoding/windows I don't know if that would change the encoding marked in the notification email. I don't have any strong feelings about this; if we were picking one character set for commit messages it would obviously be UTF-8, but I don't know if we ever discussed that. --Ken
Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563
Hi David, > > I can see tag 1.8-branchpoint is the branch point for the > > 1.8-release branch, but why are 69027ab9, 760a6ba9, 5608cda8, which > > alter VERSION and DATE, on master rather than 1.8-release? > > Good question. When I did that I was thinking of where master is at > that point in time. Maybe it should just be 1.8+dev? Yes, I think so if all further 1.8 work happens on branch 1.8-release. I think that's what docs/README.developers suggests too, even before my recent commit. :-) -- Cheers, Ralph.
Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563
Ralph wrote: > I've pushed a few more trivial documentation things to master, which > don't have to make 1.8. Those will be in 1.8. > I can see tag 1.8-branchpoint is the branch point for the 1.8-release > branch, but why are 69027ab9, 760a6ba9, 5608cda8, which alter VERSION > and DATE, on master rather than 1.8-release? Good question. When I did that I was thinking of where master is at that point in time. Maybe it should just be 1.8+dev? David
Re: nmh 1.8?
Hi Andy, > > Has anyone had a chance to review my proposed changes to inc to be > > able to handle long lines from POP sources? Is the latest in Git? I see the ‘andy-long-line-patch’ at http://git.savannah.nongnu.org/cgit/nmh.git/refs/ with one commit: http://git.savannah.nongnu.org/cgit/nmh.git/commit/?h=andy-long-line-patch=08dffe5aba9563ff06e82d2a8e6a6d746223d10f -- Cheers, Ralph.
Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563
Hi David, > > Should I stop pushing commits now so as to not get in your way, or > > keep pottering them in as they may make it if there's an 1.8-RC2? > > I'd rather avoid code changes because, in theory, they'd require > complete re-testing. Agreed. > If you find a code change that really should go in, how about posting > it here for concurrence? Everything else should be easy to cherry > pick. I've pushed a few more trivial documentation things to master, which don't have to make 1.8. I'm not intending to post anything to branch 1.8-release, considering it your domain. I'm a bit puzzled by the tags and branches though. ┌ 68228e3c (origin/master, origin/HEAD) │ man/burst.man: re-word to avoid ‘digestifying’, etc. ⋮ ├ a3a23a66 man/*.man: fix options which didn't escape their hyphen. ├ 277347a4 NEWS: fix spelling of ‘MIME’. ├ f8fb242b NEWS: add a link to Norm's Wikipedia page. ├ 19d63f85 .gitignore: move ‘/configure~’ entry to correct section. ├ 5608cda8 Update for 1.8-RC1. │ ├ 760a6ba9 (tag: 1.8-RC1) │ Updates for 1.8 release. ├ 69027ab9 Update for 1.8 release. │ │ ┌ a60e1455 (origin/1.8-release) │ │ man/*.man: fix options which didn't escape their hyphen. │ ├ 8ec6dc0e NEWS: fix spelling of ‘MIME’. │ ├ 1f4822e8 NEWS: add a link to Norm's Wikipedia page. │ ├ 2e344864 .gitignore: move ‘/configure~’ entry to correct section. ├─┘ ├ 54434563 (tag: 1.8-branchpoint) Updates for 1.8 release. ├ bee25da0 Ignore configure tilde file ⋮ I can see tag 1.8-branchpoint is the branch point for the 1.8-release branch, but why are 69027ab9, 760a6ba9, 5608cda8, which alter VERSION and DATE, on master rather than 1.8-release? -- Cheers, Ralph.
Re: nmh 1.8?
Hi Kevin, > Is anyone here packaging nmh as part of a .deb file in the process of > testing? Alexander Zangerl is Debian's packager in the past; I'm CC-ing him. The end of docs/README.developers says Keep an eye on Debian's packaging, especially what patches they have to apply, and the results of their Lintian checker, which even includes spelling errors in man pages and binaries. https://sources.debian.net/src/nmh/1.6-16/debian/patches/ https://lintian.debian.org/full/a...@debian.org.html#nmh Perhaps some nmh developer that uses Debian, or Ubuntu?, could provide package-building commands, including lintian(1), for Makefile.am so Lintian's complaints are known before release. I assume if we grabbed the debian directory, e.g. https://sources.debian.org/src/nmh/1.7.1-12/debian/, then we could have a stab at building the .deb on a Debian machine; I have one to hand. I've had a look at the Lintian output and fixed a spelling mistake. It also says debian/control could do with a Homepage definition: Alexander, it's https://www.nongnu.org/nmh/ That README also mentions a quick overview of what's shipping what version: A useful overview of what third parties are shipping which release is available at https://repology.org/project/nmh/versions with a quick overview on the Badges tab which shows https://repology.org/badge/vertical-allrepos/nmh.svg. -- Cheers, Ralph.
Re: send(1) and Draft-Folder.
Hi David, > > Ralph wrote: > > > > Draft-Folder: To specify the default draftfolder > > > > > > > > Removing the hyphen from the second draft-folder helps associate > > > > it with the -draftfolder switch, I think. > > > > > > Is this equivalent? > > > > > > Draft-Folder: -draftfolder's default > > > > I don't like that, because then I have to figure out how -draftfolder > > fits in. > > I might have come across as harsh on that. I didn't find that. :-) I was just left a bit unclear on your point but I think it's that I might understand draft folders, from mh-draft(5), but not know about this command's -draftfolder, say, and so it adds another level of indirection to get to the answer. > In reality, I don't have a preference. Given its peers, e.g. whom(1)'s Path:To determine the user's nmh directory Draft-Folder:To specify the default draftfolder Aliasfile: For a default alias file postproc:Program to post the message it may as well be left alone. It looks like there could be a general sweep through them to make them more brief and simply refer to an option where applicable. So for those above, Path:The user's nmh directory Draft-Folder:-draftfolder's default Aliasfile: -alias's default postproc:A post(8)-like program which does the work This would make more sense if the man pages listed options rather than burying them in prose. -- Cheers, Ralph.
Re: Plans for distribution updates
On Sun, 01 Jan 2023 12:05:58 -0500, Ken Hornstein wrote: > Everyone, > > So now that we've started the release cycle process (thanks, David!) I > am wondering what the plans are for getting 1.8 packages into various > distributions. I did the Homebrew formula for MacOS X and I'm glad > to do it for 1.8. But I am wondering what other operating systems we > should target. Ones that come to mind are: > > - Various RPM-based distributions (Fedora, RedHat, CentOS, Rocky, and I am > sure others) > - Debian (and anything else that uses .deb files) > - FreeBSD/NetBSD/OpenBSD 'ports' systems As usual, I'll handle OpenBSD. > I am sure there are others. I guess I am wondering what needs to be done > to "turn the crank" so 1.8 makes it into the packaging distributions. > I know for Homebrew once the pull request is accepted all Homebrew users > should get the new version relatively quickly, and I think the ports systems > are similar but I don't know what needs to happen for the others. > > --Ken >
