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 attachment 62520 [details] xemacs-21.4.17.ebuild new ebuild
Created attachment 62521 [details] 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 attachment 66480 [details] 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 attachment 88412 [details] 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 attachment 88641 [details] 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 attachment 88736 [details] 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 attachment 88737 [details] 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 attachment 88823 [details] emodules.texi patch obsoletes emodules.info patch
Created attachment 88824 [details] external-widget.texi patch fixes external-widget.info entry
Created attachment 88825 [details] 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 attachment 89082 [details] 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 attachment 89083 [details, diff] 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!
