See docs/README.developers. We don't have a written convention for
when to use a branch, so it's a judgment call considering how
invasive the changes will be, duration, likelihood of success, and
whatever else. (I am planning to remove my old merged branches,
maybe after the release. We don't
Ralph wrote:
> Thanks, that helped quite a bit. I've pushed a trivial fix to master.
> If I've done anything wrong, e.g. not configured my ID properly, then
> let me know.
Looks fine.
One thing that we should add to README.developers, the buildbot results
are available at
Hi,
David wrote:
> See docs/README.developers.
Thanks, that helped quite a bit. I've pushed a trivial fix to master.
If I've done anything wrong, e.g. not configured my ID properly, then
let me know.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
>:-) Through a cunning bit of social engineering the other day, I did
>apparently gain access to nmh's git repository. Is there anything that
>documents conventions in using it for the project, e.g. whether to check
>in directly on master or use a branch?
I think David covered the (lack of
Ralph wrote:
> Hi David,
>
> :-) Through a cunning bit of social engineering the other day,
I don't want to know :-)
> I did apparently gain access to nmh's git repository. Is there
> anything that documents conventions in using it for the project,
> e.g. whether to check in directly on
Hi David,
> Great! We'll get you to the bleeding edge yet.
:-) Through a cunning bit of social engineering the other day, I did
apparently gain access to nmh's git repository. Is there anything that
documents conventions in using it for the project, e.g. whether to check
in directly on master
Ralph wrote:
> Hi David,
>
> > Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
> > this?
>
> Yes, indeed.
Great! We'll get you to the bleeding edge yet.
> IOW, it seeks to 4Ki and reads 4Ki - 1 so it's left in the right place
> to read the one byte, that we already have,
Hi David,
> Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
> this?
Yes, indeed. I get identical output from iconv(1) and mhshow(1) with
the function from
http://git.savannah.gnu.org/cgit/nmh.git/tree/uip/mhshowsbr.c.
> + if (errno == EINVAL) {
> + /*
>> 1.6's mhshow(1) says
>
>Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38
>have fixed this?
I think our generic assumption is that utf8 is the only multibyte sequence
we have to deal with. Although I guess that really only matters if we get
an EILSEQ and we're substituting a '?'.
Ralph wrote:
> > 1.6's mhshow(1) says
> >
> > mhshow: unable to convert character set to gb2312, continuing...
>
> I meant to draw attention to that. It was converting *from* gb2312 (to
> UTF-8).
Fixed, thanks.
David
___
Nmh-workers mailing list
Ralph wrote:
> 1.6's mhshow(1) says
Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38
have fixed this?
> I took a look at mhshowsbr.c's convert_charset() and I think it's
> failing to handle an EINVAL return.
That commit adds handling of EINVAL and EISLEQ, relevant portion of
the
Hi again,
> 1.6's mhshow(1) says
>
> mhshow: unable to convert character set to gb2312, continuing...
I meant to draw attention to that. It was converting *from* gb2312 (to
UTF-8).
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Hi,
I got an email recently, probably spam, its charset is gb2312.
$ mhlist
msg part type/subtype size description
8032 text/plain 10K
charset="gb2312"
$
1.6's mhshow(1) says
mhshow: unable to convert character set to
13 matches
Mail list logo
