Bugzilla Bug 97786

Please find attached an updated ebuild for the latest xemacs version.

Several changes c.f 21.4.15-r3

1) The emodules-info-21.4.8-gentoo.patch no longer seems necessary - I find the emodules entry in info fine without it. 

2) Updated gdbm patch to correspond track upstream changes of configure.in. The bug needs to be reported upstream (must check that it has/hasnt been)

3) The quick-fix.patch no longer seems to apply, so removed. I checked through the latest configure after ebuild xemacs-21.4.17 unpack and could not see anything relevant. Need powerpclinux person to verify patch is no longer necessary, i.e., ebuild works.

4) The patch for CAN-2005-0100 (movemail) is no longer necessary as a fix has been made upstream  http://list-archive.xemacs.org/cgi-bin/wilma_hiliter/xemacs-patches/200502/msg00082.html?line=319#hilite

New ebuild and gdbm patch attachments to come ...

Created an attachment (id=62520) [edit]
xemacs-21.4.17.ebuild

new ebuild

Created an attachment (id=62521) [edit]
updated gdbm patch

I have just submitted a bug report about gdbm upstream, including the patch.

The emodules-info-21.4.8-gentoo patch is still needed. The problem it fixes is
not that the file is not installed or found by info, but that it does not appear
in the right section and that it does not have a proper title.

The problem is really with the man/emodules.texi file in the original
distribution. This problem has been fixed in the 21.5 tree, so I have not
reported it to upstream. For 21.4 we simply keep this patch in.

Looks like Robert Coie - main Gentoo XEmacs person - is snowed under with work
committments according to the Gentoo developer web page 

http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml website

So just wondering who else can update XEmacs in portage?

Not that a minor bump in XEmacs is that important, but keeping up to date
generally is part of the Gentoo attraction :)

Oh, and I guess assuming that someone else has tested the ebuild.

I had a look at effect of the emodules patch. The reason I thought it was not
needed is that my emodules info entry appears in the same place with same
heading with or without it. On looking into it, it seems that is because
/usr/share/info/dir.gz does not get rebuilt. Not sure how a rebuild is
triggered, or whether it should be a part of the install.

Created an attachment (id=66480) [edit]
Revised ebuild for xemacs 21.4.17

I noticed I did not include my updated ebuild with this bug yet, so here it is.
I've been in contact with Torsten Veller about committing xemacs updates to
portage, so hopefully we can see things moving with xemacs some time soon. 

Hi,

thanks for providing this ebuild.  A few notes:

* There ist actually a good reason to install 21.4.17: it introduces the
function run-mode-hooks which is used by cc-mode.  Thus customized c/c++-coding
is only possible with this version (if you use a recent cc-mode).

* I just managed to install 21.4.17 using the revised ebuild, the emodules-patch
from /usr/portage/app/editors/xemacs/files and the gdbm-patch attached to this
bug.  For this I first followed the "ebuild: A Safer Approach" and when I passed
the ebuild ... install-command I simply emerged xemacs.

* Should I come across any problems with the ebuild I will post to this bug (I
am a heavy xemacs user)

Thanks and kind regards
Stefan Kamphausen

Hi, 
 
Many thanks for the ebuild.  I concur with the fact that introducing 21.4.17 is 
a necessity, at least because of that run-mode-hooks business. 
 
I just installed it successfully on an amd64 and so far all seems to be working 
fine.  If I find something that does not work, I'll report. 
 
Just a comment.  The ebuild still contains 21.4.15-r3, which obviously needs to 
be modified. 
 
Again, many thanks. 
 
Fred 
 

  Just a comment.  The ebuild still contains 21.4.15-r3, which obviously needs
to 
  be modified. 

You mean the comment in the ebuild? 

# $Header:
/var/cvsroot/gentoo-x86/app-editors/xemacs/xemacs-21.4.15-r3.ebuild,v
1.2 2005/06/12 22:50:02 solar Exp $

That would be updated by whoever does the checkin ..

Actually 21.4.18 is out now, so you probably want to update the ebuild to
install that.  It's definitely a higher priority because of the run-mode-hooks
issue.  I've had to install from source into /usr/local to get things to work.

The problem is that if you use the XEmacs package manager to update packages
inside XEmacs, you'll actually break cc-mode when running in 21.4.15.  I'll let
the cc-mode maintainers know about this, but still, Gentoo should be installing
21.4.18.

I'll second the request to upgrade to xemacs 21.4.18.  Since 21.4.15 there have
been a number of Gentoo friendly additions to xemacs including support for
building with make -j.

Just renaming the above ebuild to xemacs-21.4.18.ebuild
worked fine for me.  It also solved a lot of problems that I was having with
cc-mode, so thanks.

I've created an updated ebuild for xemacs 21.4.19 in my xemacs overlay. I'd be
happy to get feedback on it. The overlay can be found at
http://moving-innvations.com/svn/xemacs and it also contains bumps for a whole
set of xemacs packages.

Hans, seems cant access your overlay at the moment (cant find the ip address
for the website)

Simply copying the xemacs-21.4.17 ebuild in portage to xemacs-21.4.19 works for
me (either rename the gdbm patch or make a minor change to the ebuild). I've
attached the ebuild I used.

Use the 21.4.17 ebuild in portage as a base as it handles modular X
dependencies.

Created an attachment (id=88412) [edit]
xemacs-21.4.19.ebuild

D'oh. Perhaps the right URL to the repository will give more satisfactory
results... 

http://moving-innovations.com/svn/xemacs

And yes, I have used the 21.4.17.ebuild in portage as a base. I intend do some
more work on the ebuild to deal with some of the reported bugs on xemacs, and
to bring in some of the things that were included in earlier versions of the
ebuild (e.g. the desktop file so that XEmacs shows up in desktop menus).

Created an attachment (id=88641) [edit]
updated xemacs-21.4.19 ebuild


Slightly updated ebuild:

+ introduced gdbm flag, so berkdb or gdbm can be correctly chosen (see bug
102540)
+ only unpack NeXT_XEmacs.tar.gz if neXt set 
+ changed plain athena widgets to use xaw
+ included Hans' updates for the desktop changes (needs xemacs.desktop)

Hans, I havent tried your individual package updates, but the ones I had a look
at seem fine to me. 

I generally use the sumo package rollup for most of what I do, rather than
individual packages - except for a couple of packages I want to rev faster than
sumo (for example the Mew MUA).

New sumo out recently 2006.05.10, which works ok so far for the few things I've
tried (~x86). Just a rename of the ebuild (also see bug 116859)   

Created an attachment (id=88736) [edit]
updated xemacs-21.4.19 ebuild

Just a little more tweaking

+ add 'eolconv' use flag to enable setting of file-coding (\r\n,\n autodetect,
usually off in unix) see bug 62991
+ patch for external-widget.texinfo for external-widget.info entry
+ changed patch for emodules.info to patch emodules.texinfo
+ removed line to remove emodules.info~* as patching texinfo file instead
should not result in cruft from applying patch being installed 

Created an attachment (id=88737) [edit]
updated xemacs-21.4.19 ebuild

Just a little more tweaking

+ add 'eolconv' use flag to enable setting of file-coding (\r\n,\n autodetect,
usually off in unix) see bug 62991
+ patch for external-widget.texinfo for external-widget.info entry
+ changed patch for emodules.info to patch emodules.texinfo
+ removed line to remove emodules.info~* as patching texinfo file instead
should not result in cruft from applying patch being installed 

Created an attachment (id=88823) [edit]
emodules.texinfo patch

obsoletes emodules.info patch

Created an attachment (id=88824) [edit]
external-widget.texi patch

fixes external-widget.info entry

Created an attachment (id=88825) [edit]
xemacs.desktop (from Hans' overlay)

The database support in the latest uploaded ebuild does not work for me. My
nbdm.h file is located in /usr/include/gdbm/ndbm.h which is not where the
configure script looks for it (it only checks /usr/include/ndbm.h). 

For berkdb I have db 4.2 installed, but this version is not properly detected.
I'm currently testing a fix that I lifted from sxemacs configure, which seems
to be the only version that has fixed this. The problem is that db 4.2 maps
db_create to db_create_4002 (specific name depending on version), but configure
only checks for presence of db_create. As a consequence the library is not
added to the build because db_create is not in it, and the build fails while
linking.

Created an attachment (id=89082) [edit]
xemacs-21.4.19-r2.ebuild

New ebuild with improved database support. Both berkdb and gdbm can be set
resulting in support for both databases to be included. Also fixed compilation
with new gdbm support in Gentoo (with nbdm.h in /usr/include/gdbm only) and
newer (> 4.1) versions of berkdb.

Created an attachment (id=89083) [edit]
xemacs-21.4-db.patch

Patch for database support used by xemacs-21.4.19-r2.ebuild. 

All of the files are available as an overlay at
http://moving-innovations.com/svn/xemacs

I just noticed that xemacs in portage got bumped to 21.4.19, but without any of
the bug fixes included in this thread. I think this bug should remain opened
until these are also included in portage.

I tried the ebuild (with patches and desktop file) and it creates a menu entry
under kde as I had hoped.

(directed here from Bug#:   152968)

Thanks for the confirmation!

Hopefully this will end up in portage fairly soon (once the Gentoo recruiters
have approved my status as developer).

I am getting a lot of xemacs warnings:

 (error/warning) Error in process filter: (wrong-type-argument consp nil

is this related to any of the new patches here?

It's hard to tell from the little bit of information you are giving, but it may
be related to the eolconv flag, which determines how eol is handled. It it
disabled in earlier versions of xemacs currently in portage, so this would only
be a problem if you enabled this flag explicitly. The other patches only fix
compilation or configuration issues. 

ok, I just wanted to mention it; did not want to confuse different bugs.

I don't have eolconf enabled, so I guess it's something else.

Just a note that most of the changes attached to this bug have found their way
into portage now. As far as I can tell only the database patches are still
missing, but I hope to get to those shortly.

The database changes have now also been added to portage in xemacs 21.4.19-r2.
I believe that was the last of the pending changes reported in this bug. Please
let me know if I've missed anything.

Thanks everyone for the patches and feedback!