maintainer(s) needed: MH-E, Gnus

[Mike Kupfer]

I'm afraid I no longer have the time to maintain either the MH-E or Gnus
packages for XEmacs. If anyone is interested in taking over one or both
packages, please let me know; I'll be happy to help you get started.

cheers,
mike

[Henry S. Thompson]

I don't currently maintain anything, although I'm part of the informal
effort to get XEmacs working on x86_64. I have used gnus forever, so
I suppose I should give maintaining it a try.

BTW, in that connection, could we get a release of the current tip, as
the digit-char-p bug just bit me again after an upgrade wiped out my
local patch.

ht

[Raymond Toy]

Henry> I don't currently maintain anything, although I'm part of
Henry> the informal effort to get XEmacs working on x86_64. I

In what way does XEmacs not work on x86_64?

--
Ray

[Henry S. Thompson]

Post by Raymond Toy
Henry> I don't currently maintain anything, although I'm part of
Henry> the informal effort to get XEmacs working on x86_64. I
In what way does XEmacs not work on x86_64?

I should have been more precise. As of a few months ago, I can build
a 64-bit XEmacs using gcc and Cygwin. What is _not_ currently
possible is building with Visual Studio, something which _does_ still
work for 32-bit. Details in threads on this list with subjects such
as
Installing XEmacs under Cygwin
Compiling xemacs with Visual Studio 2015 Community ('free') edition
ht

[Raymond Toy]

Henry> I don't currently maintain anything, although I'm part of
Henry> the informal effort to get XEmacs working on x86_64. I

Post by Raymond Toy
In what way does XEmacs not work on x86_64?

Henry> I should have been more precise. As of a few months ago, I
Henry> can build a 64-bit XEmacs using gcc and Cygwin. What is
Henry> _not_ currently possible is building with Visual Studio,
Henry> something which _does_ still work for 32-bit. Details in

Ah, ok. I build xemacs on x86_64 all the time, but have never tried
on windows. I just use some precompiled package because I don't use
windows very often. So I'm grateful to whoever makes these.

--
Ray

[Stephen J. Turnbull]

Post by Henry S. Thompson
BTW, in that connection, could we get a release of the current tip,

Tip of what?

[Henry S. Thompson]

Post by Henry S. Thompson
BTW, in that connection, could we get a release of the current tip,

Packages, I meant. gnus, in particular.

Or maybe I just don't understand the packages sub-repository
architecture. As a result of a forced repartition/rebuild from
scratch of my Linux (SL7 now) environment, I cloned, built and
installed xemacs-packages from scratch. This caused a local reversion
to the digit-char-p problem. To fix this, I had to drop down into
xemacs-packages/gnus and build and install _there_.

As far as I can make sense of things, that's because the top-level
repo tip is at 17 May, but gnus itself is at 27 June, when the
relevant patch came in.

ht

[Mike Kupfer]

Post by Henry S. Thompson
As far as I can make sense of things, that's because the top-level
repo tip is at 17 May, but gnus itself is at 27 June, when the
relevant patch came in.

Yes, that's what I see, too.

Norbert, can you fix the top-level packages repo, please?

thanks,
mike

[Henry S. Thompson]

Post by Mike Kupfer

Post by Henry S. Thompson
As far as I can make sense of things, that's because the top-level
repo tip is at 17 May, but gnus itself is at 27 June, when the
relevant patch came in.

Yes, that's what I see, too.
Norbert, can you fix the top-level packages repo, please?

Is this related to the following, which I see when I pull and then
update at the top of the xemacs-packages tree:

subrepository sources for xemacs-packages/gnus differ (in checked out version)
use (l)ocal source (45540f5758d2) or (r)emote source (de9ea3b04d44)?

What should I answer?

ht

[Mike Kupfer]

Post by Henry S. Thompson

Post by Mike Kupfer

Post by Henry S. Thompson
As far as I can make sense of things, that's because the top-level
repo tip is at 17 May, but gnus itself is at 27 June, when the
relevant patch came in.

Yes, that's what I see, too.
Norbert, can you fix the top-level packages repo, please?

Is this related to the following, which I see when I pull and then
subrepository sources for xemacs-packages/gnus differ (in checked out version)
use (l)ocal source (45540f5758d2) or (r)emote source (de9ea3b04d44)?
What should I answer?

Yes, this is from fixing the top-level repo and from generating a
package tarball for gnus with the digit-char-p fix. I saw the same
thing when I pulled from Bitbucket.

In this case, you should answer "r". This is because de9ea3b04d44 is
just 45540f5758d2 plus 2 changesets that get automatically generated
when Norbert builds a new package tarball.

$ hg log -G -l 3
@ changeset: 306:de9ea3b04d44
| tag: tip
| user: Norbert Koch <***@xemacs.org>
| date: Fri Sep 18 22:22:00 2015 +0200
| summary: Added tag gnus-2_02 for changeset c347d2ce5863
|
o changeset: 305:c347d2ce5863
| tag: gnus-2_02
| user: Norbert Koch <***@xemacs.org>
| date: Fri Sep 18 22:22:00 2015 +0200
| summary: XEmacs Package Release 2.02
|
o changeset: 304:45540f5758d2
| user: Mike Sperber <***@deinprogramm.de>
| date: Sat Jun 27 09:08:12 2015 +0200
| summary: Redefine `digit-char-p' only conditionally.
|
$

mike