On Wed, 13 May 2020, Βασίλειος A. Ζοῦκος wrote:
I think that the problem has been solved and I would like to thank
all of you for your prompt responses.
I am glad to read the problem is solved, but I would like to encourage
Debian to not to do this kind of changes by default in its en
On Mon, 11 May 2020, Βασίλειος A. Ζοῦκος wrote:
Thanks for the informative responses.
More information on the subject:
1. The variable Encryption Protocol Range appears only in alpine
ver. 2.22 with the assignment:
Encryption Protocol Range =
Yes, and since you have not
On Sun, 3 May 2020, Unit 193 wrote:
Thank you for including logs! The important line from the latter is as
follows:
sslfailure: host=imap.otenet.gr reason=SSL negotiation failed
Unfortunately that's not a lot of detail, so it's useful to use testssl
or `openssl s_client` to check what's goi
On Wed, 10 Oct 2018, Antos Andras wrote:
Here Debian Alpine 2.20 does not core dump/segfault/crash, but the
password is still saved only if the passfile already exists (and same
with Alpine 2.21 in CentOS).
From the mail above, it seems this is intended, so rather a feature not a
bug, but this
On Tue, 21 Nov 2017, Helmut Grohne wrote:
On Tue, Nov 21, 2017 at 10:53:16AM -0700, Eduardo Chappa wrote:
[ I added Helmut Grohne to this communication]
Please do not forget to Cc the bug to capture this conversation.
Yes, thank you.
In
http://repo.or.cz/alpine.git/commitdiff
Dear Joey,
this is a problem in Alpine caused by Alpine calling a function that
should not be called during a signal call. Alpine was calling ctime,
received the signal and then called localtime. This causes the problem.
I will add code to Alpine to attempt to avoid this, but this is more
Thorsten,
Alpine converts the content of the attachment to UTF-8 before any
further processing. The newest alpha version 2.20.8 allows you to save a
text/* attachment in binary form, meaning that no transformation to UTF-8
will be made before any other filters is applied (e.g. user defined
Dear Joey,
I have just read your message, and I have a few comments. The fact that
the ssh command failed to work (and asked for a password) is likely an
indication of an error at the time of login in, this probably means that
there is an error in the ~/.bashrc file of the user using Alpine
On Sun, 7 Sep 2014, Asheesh Laroia wrote:
Eduardo -- I've made two small changes to Svante's patches, and I've
just uploaded that to Debian now. If the GNU Hurd build daemons like
this package, I'd love if you can take the two patches.
Dear Asheesh,
I've looked at the document that you sha
Thorsten,
The behavior that Alpine exhibits is documented in the help for the
option, so the subject is not quite correct, because this is intended
behavior (see x-alpine-help:h_config_post_char_set)
In regards to adding another configuration option. I see why you would
like to do this, but
On Thu, 31 Jul 2014, Asheesh Laroia wrote:
Hi Eduardo,
Here's another Debian bug that I wanted to get your input on
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532380 .
Do you think it makes sense for future Alpine editions to allow people
to "V"iew application/octet-stream attachment
On Thu, 31 Jul 2014, Asheesh Laroia wrote:
Hi Eduardo,
I know you've been working a lot on alpine lately, and I wanted to pass
this along.
I haven't dug into the source code, but one Debian user reports that the
-passfile option seems to have no effect.
Another reports that -passfile works
On Sun, 25 May 2014, Thorsten Glaser wrote:
No, using base64 there is perfectly reasonable, especially if you are
Asian and use UTF-8 encoding (much shorter), or use UTF-16 (the sheer
amount of NUL bytes is crazy even with ASCII), or if the eMail is
auto-generated and the script doing it went
On Sun, 25 May 2014, Thorsten Glaser wrote:
But the "h" command does not do that, that is, you should be able to
see
I should, right, but the UTF-16 eMail shows that this is only a should,
not an “is”. But since the other charsets are all supersets of ASCII,
this is never noticed otherwise.
On Sun, 25 May 2014, Thorsten Glaser wrote:
Sure: When you view a raw message using ‘h’, and the message was base64
content-transfer-encoded, you do *not* want this base64 to be
interpreted as if it were in the content-type/charset, because the
charset only applies to the message *after* base6
On Sun, 18 May 2014, Simon Fondrie-Teitler wrote:
I've tested the attached patch, and was able to apply it to the alpine
Debian package. I was also able to successfully apply the patches the
debdiff put into debian/patches/ to the alpha version of alpine. I've
attached both for convenience.
/alpine.html
--
Eduardo
http://patches dot freeiz dot com/alpine/
Sadly, Eduardo Chappa does not give us permission to share his work
under the terms of the Apache 2.0 License, so we can't include it.
If there is another way to improve the Debian package to have this bug
fixed, that'd be grea
:
> Dear Asheesh,
>
> I forward you an email from Eduardo Chappa. I tested his patch with
> alpine2.02. It resolves the issue.
Hi Martin,
That's great to know!
Mr. Chappa and the re-alpine team (and myself) seemed to experience a
disagreement over copyright licensing in
*** Asheesh Laroia ([EMAIL PROTECTED]) wrote today:
:) Eduardo, I see that you have an Alpine Maildir patch at
:) http://staff.washington.edu/chappa/alpine/info/maildir.html . Do you
:) have any comment as to if it's suitable to include it into the Debian
:) Alpine package?
Dear Assheesh,
19 matches
Mail list logo
