Please consider writing and installing an AppData file with the
application description and some screenshots, else xemacs looks really
bad in the GNOME and KDE Software Centers. We'd love to showcase more
applications, but without the extra data file we can't. See
http://people.freedesktop.org/~hughsient/appdata/ for details; thanks!
Richard
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi all. I've been a XEmacs zombie for too long, and Mats Lidell
recently found a problem in 'mail-lib' and asked me about status --
since I haven't used XEmacs in several years (sorry) it doesn't make
sense for me to be maintainer of that or any other XEmacs package. I'm
happy if Mats or someone else steps up and maintains these packages!
/Simon
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-05-13 - 2014-05-20)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
557 open ( +1) / 311 closed ( +0) / 868 total ( +1)
Open issues with patches: 13
Average duration of open issues: 1768 days.
Median duration of open issues: 1901 days.
Open Issues Breakdown
new 246 ( +1)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 147 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 16 ( +0)
Issues Created Or Reopened (1)
______________________________
Potential integer overflow bug at scan_lisp_file() 2014-05-20
http://tracker.xemacs.org/XEmacs/its/issue870 created Hao Sun
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
Didn't get any response to this posting but then I realized I sent it
of to black hole somewhere and not to the mailing list. :-(
Mean while, I think we have solved it to some extent in Gentoo by
setting EMACSLOADPATH during the compile phase and removed the
compression of the el-files. It is still not perfect but might work in
practice.
I include my original posting below. // Mats
------------------------------------------------------------
Hi,
Don't know if you remember this thread but I had an issue with that
the lisp files installed in "/usr/share/xemacs-21.5-b34/lisp" some how
managed to get there way into the xemacs dump due to that the load
path is changed when startup.el is loaded. This happens when you
rebuild xemacs, same version of course, for any reason.
This might be an obscure thing for someone installing xemacs from
sources. (In fact I haven't managed to recreate the problem when I
install from sources even if I set the prefix to /usr. Which makes
things even stranger.)
For the Linux distribution Gentoo where packages are installed from
building from sources rebuilding packages can happen. The fact that
files in /usr/share/xemacs-21.5-XXX is used within the build is not a
good thing.
What is worse is that if the el-files are gzipped, that is a target we
have to save some bytes on disc, the dump crasches because it can't
find the el-files. The crash happens just after loading, yes you
guessed it, startup.el because misc.el can't be found. It is now
compressed and dump does not know about compressed el-files, right?
It looks like this:
[...]
Loading modeline.el...
Loading cus-file.el...
Loading startup.el...
Load file misc: not found
Fatal error during load, aborting
make[1]: *** [NEEDTODUMP] Error 1
make[1]: Leaving directory `/var/tmp/portage/app-editors/xemacs-21.5.34-r3/work/xemacs-21.5.34/src'
make: *** [src] Error 2
* ERROR: app-editors/xemacs-21.5.34-r3::emacs failed (compile phase):
* emake failed
*
[...]
The best thing would of course be if there was some simple way to
invoked make so that this problem don't occur. But I don't know what
that would be. The load path stuff is deep within XEmacs as I get it.
I could delete the lisp files under /usr/share/xemacs-21.5-XXX before
building but that isn't ideal since that would ruin the current
install if the ongoing would fail for some reason. But at the moment
that seems to be my best option.
Ideas, suggestions are welcome.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
PATCH 21.5
On Thu, May 8, 2014 at 6:41 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
> This is the bug. I don't understand how this would happen. All
> objects passed to Ffc_* function should be created with one of the
> four functions calling fc_config_create_using in font-mgr.c. Perhaps
> fontconfig can return NULL in some cases, but it shouldn't unless
> maybe there's an ENOMEM in there?
>
> More than that I can't say for a few hours. I'll take a look at the
> backtrace and see if I can figure out how such a thing occurred.
Here is what happened. In fc_config_create_using, we wrap the
fc_config object as a Lisp object *twice*. One reference goes onto a
weak list and the other is returned. The next time we garbage
collect, the weak reference is collected, and the finalizer
(finalize_fc_config) is called, which sets fccfgPtr to NULL.
Meanwhile, the strong reference is still live....
The fix is to wrap the fc_config object once and use the same
reference everywhere, like so:
diff -r 2d20d57d4e7b src/ChangeLog
--- a/src/ChangeLog Wed May 07 13:33:50 2014 -0600
+++ b/src/ChangeLog Wed May 14 10:53:21 2014 -0600
@@ -1,3 +1,9 @@
+2014-05-14 Jerry James <james(a)xemacs.org>
+
+ * src/font-mgr.c (fc_config_create_using): wrap the fc_config
+ object as a Lisp object only once, so the strong and weak
+ references refer to the same object.
+
2014-01-27 Michael Sperber <mike(a)xemacs.org>
* symbols.c (Fdefine_function): Allow optional `docstring'
diff -r 2d20d57d4e7b src/font-mgr.c
--- a/src/font-mgr.c Wed May 07 13:33:50 2014 -0600
+++ b/src/font-mgr.c Wed May 14 10:53:21 2014 -0600
@@ -526,11 +526,13 @@
}
{
+ Lisp_Object cfg;
fc_config *fccfg = XFC_CONFIG (ALLOC_NORMAL_LISP_OBJECT (fc_config));
fccfg->fccfgPtr = fc;
- configs = Fcons (wrap_fc_config (fccfg), configs);
+ cfg = wrap_fc_config (fccfg);
+ configs = Fcons (cfg, configs);
XWEAK_LIST_LIST (Vfc_config_weak_list) = configs;
- return wrap_fc_config (fccfg);
+ return cfg;
}
}
Regards,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I'm looking at how to get readable output from texi2any --html, by
hooking iconv into the pipeline. We have some ... interesting ...
encoding situations. For example, in mule-packages/mule-base/texi, we
have several files encoded with ISO-2022-JP, but canna-jp.texi appears
to be encoded with EUC-JP, and languages.texi appears to contain
multiple encodings (e.g., ISO-2022-JP-2 on line 96, something I
haven't been able to figure out on line 97, ISO-2022-KR on lines
461-465, etc.).
I tried to look at some of the info files with XEmacs, and found that
the info files did not survive being processed by makeinfo. The texi
files show non-ASCII character okay when opened with XEmacs, but the
info files just show ASCII garbage. (Raw ISO-2022 sequences maybe?)
Do others of you see that? Try looking at the skk or mule-base info
files. I wonder if this is because modern Linux distributions default
to UTF-8 as the encoding for everything.
I'm not sure how to handle this. Any suggestions on how to proceed
would be much appreciated.
By the way, when I couldn't figure out an encoding, I did this:
for enc in $(iconv -l); do
echo -n "${enc%//}: "
sed -n 97 languages.texi | iconv -f ${enc%//} -t utf-8
done
and looked for output that didn't contain complaints about bad byte
sequences and that looked like it might reasonably be correct. (I
have unifont installed, so all valid Unicode characters should be
displayable, if ugly.) Even with this approach, line 97 of
mule-base/texi/langauges.texi remains a mystery to me.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
In the tracker Issue868 gives the message "You are not allowed to view
this page." Is it a bug or is it intentional because it is a security
issue?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
On Tue, May 13, 2014 at 1:47 PM, Jerry James <loganjerry(a)gmail.com> wrote:
> I'm going to push changes this afternoon to every package EXCEPT eicq,
> patcher, and ps-print-nomule, including a top-level change. This is
> necessary to convert .cvsignore files to .hgignore files. I'm also
> addressing a couple of other widespread problems at the same time to
> try to limit the churn. In any case, not too long from now, every
> package except those 3 is going to need an update. I'll send you an
> email when I'm done.
I'm done. All but the 3 packages indicated above have been updated,
as well as a top-level change.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta