Bug 213639 – net-nntp/slrn live SVN ebuild

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description mren 2008-03-17 00:25:28 UTC]

slrn is actively developed (again). It now supports utf-8.

For this ebuild I modified the existing one.

Reproducible: Always

[Comment 1 mren 2008-03-17 00:25:56 UTC]

Created attachment 146355 [details]
slrn-9999.ebuild

[Comment 2 mren 2008-03-17 00:27:17 UTC]

Created attachment 146357 [details, diff]
minimal-multipart_0.9.9-87.patch

This patch adds minimal mine support to slrn. The patch is taken from http://www.foory.de/thw/slrn/

[Comment 3 mren 2008-03-17 00:28:45 UTC]

Created attachment 146359 [details, diff]
us-ascii_override_0.9.9-87.patch

This patch will allow slrn to override the charset value "us-ascii" declared in
postings with the value of the fallback charset. This might be useful to handle
google postings I sometimes ran across, which claimed to be "us-ascii" but had 8
bit characters inside. This can be done by adding

| set usascii_override 1

to the .slrnrc.

This patch is also taken from http://www.foory.de/thw/slrn/

[Comment 4 mren 2008-03-17 00:29:38 UTC]

Created attachment 146361 [details]
slrnrd.vim

the optional vim syntax file, also taken from http://www.foory.de/thw/slrn/

[Comment 5 mren 2008-03-17 00:31:14 UTC]

Some more info's on the minimal-mime patch:

From http://www.foory.de/thw/slrn/

This adds minimal multipart support to slrn. Text type parts are displayed correctly binary and other unsupported parts are hidden. Don't expect it to read html postings or to save binary attachments, it just helps to ease the pain when reading pgp/mime signed postings or postings created by pine. You can disable this patch by adding | set minimal_multipart 0 to the slrnrc. Thanks to Christian Ebert. He helped a lot to debug this patch, thus you could call it now quite stable. If you like to have real mime-support I suggest you try out his python based slrnmime extensions 

[Comment 6 Michael Palimaka (kensington) 2013-02-06 07:32:58 UTC]

Upstream SVN seems untouched in a couple of years, so there's no point adding this. (In any case, we do prefer to avoid live ebuilds in the main tree where possible.)