GNU bug report logs -
#37527
[PATCH] Install C source code for for debugging help
Previous Next
To reply to this bug, email your comments to 37527 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 26 Sep 2019 20:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 26 Sep 2019 20:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Without this change, on typical GNU/Linux distributions
like Debian, the first button of ‘C-h f car RET’ does not
work because the source code for ‘car’ is not installed.
Fix this by installing the (compressed) C source code along with
the (compressed) Lisp source code that is already installed.
This adds about 3 MB (about 2%) to the size of the installed files
on my platform.
* Makefile.in (install_srcdir, enable_install_srcdir):
New macros.
(epaths-force): Substitute PATH_SOURCE too.
(exp_sourcesrcdir): Install copy of C source code if
enable_install_srcdir says to.
* configure.ac (install_srcdir): New var.
Add support for --disable-install-srcdir (to disable installation
of source) and for --enable-install-srcdir='.' (to have Emacs
refer to its source dir).
* lisp/emacs-lisp/find-func.el (find-function-C-source):
Also look for gzipped source files.
* src/emacs.c (init_cmdargs): Set source-directory to
be the same as installation-directory when
running with an uninstalled Emacs.
* src/epaths.in (PATH_SOURCE): New macro.
* src/lread.c (syms_of_lread): When initializing
source-directory, use PATH_SOURCE as-is if it is absolute;
otherwise, use it relative to PATH_DUMPLOADSEARCH/.. as before.
---
Makefile.in | 25 +++++++++++++++++++++++++
configure.ac | 19 +++++++++++++++++++
etc/NEWS | 6 ++++++
lisp/emacs-lisp/find-func.el | 5 ++++-
src/emacs.c | 2 ++
src/epaths.in | 3 +++
src/lread.c | 8 ++++++--
7 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Makefile.in b/Makefile.in
index aa11e6b0b7..6ffb8eb747 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -266,6 +266,10 @@ etcdir=
# once.
archlibdir=@archlibdir@
+# Where to put installed source code, and whether to install it at all.
+install_srcdir=@install_srcdir@
+enable_install_srcdir=@enable_install_srcdir@
+
# Where to put the etc/DOC file.
etcdocdir=@etcdocdir@
@@ -374,6 +378,7 @@ epaths-force:
-e 's;\(#.*PATH_BITMAPS\).*$$;\1 "${bitmapdir}";' \
-e 's;\(#.*PATH_X_DEFAULTS\).*$$;\1 "${x_default_search_path}";' \
-e 's;\(#.*PATH_GAME\).*$$;\1 $(PATH_GAME);' \
+ -e 's;\(#.*PATH_SOURCE\).*$$;\1 "${install_srcdir}";' \
-e 's;\(#.*PATH_DOC\).*$$;\1 "${etcdocdir}";') && \
${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h
@@ -624,6 +629,26 @@ install-arch-indep:
done; \
${GZIP_PROG} -9n "../etc/publicsuffix.txt"; \
}
+ifneq ($(enable_install_srcdir),no)
+ -unset CDPATH; \
+ umask 022; $(MKDIR_P) "$(DESTDIR)$(install_srcdir)/src" && \
+ exp_sourcesrcdir=`cd "$(DESTDIR)$(install_srcdir)/src" && /bin/pwd` && \
+ [ "`cd $(srcdir)/src && /bin/pwd`" = "$$exp_sourcesrcdir" ] || { \
+ $(set_installuser); \
+ printf 'Copying compressed C sources to %s ...\n' \
+ "$(DESTDIR)$(install_srcdir)/src"; \
+ for file in `cd $(srcdir) && echo src/*.[cm]`; do \
+ installed_file="$(DESTDIR)$(install_srcdir)/$$file" && \
+ $(INSTALL_DATA) "$$file" "$$installed_file" && \
+ [ -z "$(GZIP_PROG)" ] || { \
+ rm -f "$$installed_file.gz" && \
+ $(GZIP_PROG) -9n "$$installed_file" && \
+ installed_file=$$installed_file.gz; \
+ } || exit; \
+ chown $$installuser "$$installed_file" || true; \
+ done; \
+ }
+endif
-chmod -R a+r "$(DESTDIR)${datadir}/emacs/${version}" ${COPYDESTS}
## The above chmods are needed because "umask 022; tar ..." is not
diff --git a/configure.ac b/configure.ac
index 7435f2e8da..ac50e6e297 100644
--- a/configure.ac
+++ b/configure.ac
@@ -194,6 +194,7 @@
lisppath='${locallisppath}:${standardlisppath}'
etcdir='${datadir}/emacs/${version}/etc'
archlibdir='${libexecdir}/emacs/${version}/${configuration}'
+install_srcdir='${datadir}/emacs/${version}'
etcdocdir='${datadir}/emacs/${version}/etc'
gamedir='${localstatedir}/games/emacs'
@@ -540,6 +541,21 @@ AC_DEFUN
locallisppath=${enableval} locallisppathset=yes
fi)
+AC_ARG_ENABLE([install-srcdir],
+ [AS_HELP_STRING([--disable-install-srcdir],
+ [do not install low-level Emacs source code useful for debugging.
+ Use '--enable-install-srcdir=.' to have Emacs refer to the
+ source directory it was configured from.])],
+ [],
+ [enable_install_srcdir=yes])
+case $enable_install_srcdir in
+ yes | no) ;;
+ .) install_srcdir=`cd "$srcdir" && /bin/pwd` ||
+ AC_MSG_ERROR([cannot get srcdir name])
+ enable_install_srcdir=no;;
+ *) AC_MSG_ERROR([invalid install-srcdir]);;
+esac
+
AC_ARG_ENABLE(checking,
[AS_HELP_STRING([--enable-checking@<:@=LIST@:>@],
[enable expensive checks. With LIST,
@@ -2061,6 +2077,7 @@ AC_DEFUN
dnl This one isn't really used, only archlibdir is.
libexecdir="\${ns_appbindir}/libexec"
archlibdir="\${ns_appbindir}/libexec"
+ install_srcdir="\${ns_appresdir}"
etcdocdir="\${ns_appresdir}/etc"
etcdir="\${ns_appresdir}/etc"
dnl FIXME maybe set datarootdir instead.
@@ -5211,6 +5228,8 @@ AC_DEFUN
AC_SUBST(x_default_search_path)
AC_SUBST(etcdir)
AC_SUBST(archlibdir)
+AC_SUBST([enable_install_srcdir])
+AC_SUBST([install_srcdir])
AC_SUBST(etcdocdir)
AC_SUBST(bitmapdir)
AC_SUBST(gamedir)
diff --git a/etc/NEWS b/etc/NEWS
index 0a4ada3cc6..7643905256 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -125,6 +125,12 @@ removed configure options.)
** The distribution tarball now has test cases; 'make check' runs them.
This is intended mostly to help developers.
+---
+** Emacs now installs a copy of its C source code, used for debugging help.
+For example, pressing the first button in the *Help* buffer generated
+by 'C-h f car RET' now takes you to a copy of the C-language
+implementation of the function 'car'.
+
---
** Emacs now requires GTK 2.24 and GTK 3.10 for the GTK 2 and GTK 3
builds respectively.
diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el
index 142c99edd4..2812ae6f22 100644
--- a/lisp/emacs-lisp/find-func.el
+++ b/lisp/emacs-lisp/find-func.el
@@ -245,7 +245,10 @@ find-function-C-source
(let ((dir (or find-function-C-source-directory
(read-directory-name "Emacs C source dir: " nil nil t))))
(setq file (expand-file-name file dir))
- (if (file-readable-p file)
+ (if (or (file-readable-p file)
+ (let ((file-gz (concat file ".gz")))
+ (and (file-readable-p file-gz)
+ (setq file file-gz))))
(if (null find-function-C-source-directory)
(setq find-function-C-source-directory dir))
(error "The C source file %s is not available"
diff --git a/src/emacs.c b/src/emacs.c
index 21a05d337e..fa547b59f5 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -522,6 +522,7 @@ init_cmdargs (int argc, char **argv, int skip_args, char const *original_pwd)
if (!NILP (etc_exists))
{
Vinstallation_directory = Ffile_name_as_directory (dir);
+ Vsource_directory = Vinstallation_directory;
break;
}
}
@@ -547,6 +548,7 @@ init_cmdargs (int argc, char **argv, int skip_args, char const *original_pwd)
{
tem = Fexpand_file_name (build_string (".."), dir);
Vinstallation_directory = Ffile_name_as_directory (tem);
+ Vsource_directory = Vinstallation_directory;
break;
}
}
diff --git a/src/epaths.in b/src/epaths.in
index 5fe35b64c8..4e15c3a3d6 100644
--- a/src/epaths.in
+++ b/src/epaths.in
@@ -73,5 +73,8 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
/* Where Emacs should store game score files. */
#define PATH_GAME "/usr/local/var/games/emacs"
+/* Where Emacs should look for installed sources. */
+#define PATH_SOURCE "/usr/local/share/emacs"
+
/* Where Emacs should look for the application default file. */
#define PATH_X_DEFAULTS "/usr/lib/X11/%L/%T/%N%C%S:/usr/lib/X11/%l/%T/%N%C%S:/usr/lib/X11/%T/%N%C%S:/usr/lib/X11/%L/%T/%N%S:/usr/lib/X11/%l/%T/%N%S:/usr/lib/X11/%T/%N%S"
diff --git a/src/lread.c b/src/lread.c
index 5000b38a01..849632a7ec 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4979,9 +4979,13 @@ syms_of_lread (void)
DEFVAR_LISP ("source-directory", Vsource_directory,
doc: /* Directory in which Emacs sources were found when Emacs was built.
You cannot count on them to still be there! */);
+ char const *path_source = PATH_SOURCE;
Vsource_directory
- = Fexpand_file_name (build_string ("../"),
- Fcar (decode_env_path (0, PATH_DUMPLOADSEARCH, 0)));
+ = (file_name_absolute_p (path_source)
+ ? build_string (path_source)
+ : Fexpand_file_name (build_string ("../" PATH_SOURCE),
+ Fcar (decode_env_path (0, PATH_DUMPLOADSEARCH,
+ false))));
DEFVAR_LISP ("preloaded-file-list", Vpreloaded_file_list,
doc: /* List of files that were preloaded (when dumping Emacs). */);
--
2.21.0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 05:10:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 26 Sep 2019 13:07:52 -0700
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>
>
> Without this change, on typical GNU/Linux distributions
> like Debian, the first button of ‘C-h f car RET’ does not
> work because the source code for ‘car’ is not installed.
It prompts for the source directory, doesn't it?
> Fix this by installing the (compressed) C source code along with
> the (compressed) Lisp source code that is already installed.
> This adds about 3 MB (about 2%) to the size of the installed files
> on my platform.
As mentioned on emacs-devel, if the consensus is to install this, I'd
like to postpone doing so until the emacs-27 branch is cut.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 06:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 9/26/19 10:09 PM, Eli Zaretskii wrote:
>> Without this change, on typical GNU/Linux distributions
>> like Debian, the first button of ‘C-h f car RET’ does not
>> work because the source code for ‘car’ is not installed.
>
> It prompts for the source directory, doesn't it?
Yes, but that's not really a solution. I may not have a copy of the correct
version of the source directory on my system, and it may take me some time to
figure out where to get it. It might not be available from gnu.org, for example,
because the downstream distributor may have modified the Emacs source.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 07:22:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 26 Sep 2019 23:24:13 -0700
>
> > It prompts for the source directory, doesn't it?
>
> Yes, but that's not really a solution. I may not have a copy of the correct
> version of the source directory on my system, and it may take me some time to
> figure out where to get it.
I thought major distros offered a source archive as well, as an
optional download, don't they?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 08:49:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On Sep 27 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Cc: 37527 <at> debbugs.gnu.org
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> Date: Thu, 26 Sep 2019 23:24:13 -0700
>>
>> > It prompts for the source directory, doesn't it?
>>
>> Yes, but that's not really a solution. I may not have a copy of the correct
>> version of the source directory on my system, and it may take me some time to
>> figure out where to get it.
>
> I thought major distros offered a source archive as well, as an
> optional download, don't they?
The sources are also part of the emacs-debugsource packages.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 08:59:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > It prompts for the source directory, doesn't it?
>>
>> Yes, but that's not really a solution. I may not have a copy of the correct
>> version of the source directory on my system, and it may take me some time to
>> figure out where to get it.
>
> I thought major distros offered a source archive as well, as an
> optional download, don't they?
They do. But we must document at least, how to make the source tree
visible for debug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 12:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 37527 <at> debbugs.gnu.org
> Date: Fri, 27 Sep 2019 10:58:11 +0200
>
> > I thought major distros offered a source archive as well, as an
> > optional download, don't they?
>
> They do. But we must document at least, how to make the source tree
> visible for debug.
I don't mind adding documentation, if it's missing, but what does it
mean "visible for debug"? What kind of debugging did you have in
mind?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 27 Sep 2019 20:00:04 GMT)
Full text and
rfc822 format available.
Message #26 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > I thought major distros offered a source archive as well, as an
>> > optional download, don't they?
>>
>> They do. But we must document at least, how to make the source tree
>> visible for debug.
>
> I don't mind adding documentation, if it's missing, but what does it
> mean "visible for debug"? What kind of debugging did you have in
> mind?
"Visible for debug" is misleading, because the source packages don't
seem to provide symbol tables etc pp. I've just realized.
But something like the following, which is very rough written, could be
added:
[Message part 2 (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 05:52:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 9/27/19 2:21 AM, Eli Zaretskii wrote:
> I thought major distros offered a source archive as well, as an
> optional download, don't they?
They have to; the GPL requires it. But there's no requirement that the
source be installed or conveniently reachable from the executable, and
in practice it typically isn't.
The patch I proposed would solve this problem. It's possible other
patches would also solve the problem on some platforms, if someone would
take the time to develop and debug them, and we could use them on
platforms where they work. However, I expect that something like the
proposed patch (or something like it) would be needed as a backstop
anyway, for platforms that don't have the debugging source packages that
people have mentioned. So we could start with the proposed patch and
mutate it or add fancier platform-specific support later if we have the
time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 05:56:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 9/27/19 2:59 PM, Michael Albinus wrote:
> But something like the following, which is very rough written, could be
> added:
Although documenting hacks to work around the problem would be better
than nothing, it would not address the problem well. Basically, it would
put into an obscure location vague instructions that would have to be
adapted by hand in a platform-dependent way, something that would be
tricky enough that most users would likely not bother or get wrong.
Better would be an approach that just works without additional user
effort, such as the approach in the proposed patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 06:02:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 37527 <at> debbugs.gnu.org
> Date: Fri, 27 Sep 2019 21:59:17 +0200
>
> +* GNU/Linux source packages
> +
> +Many GNU/Linux systems provide separate packages containing the
> +sources of Emacs. They are useful if you want to check the source
> +code of Emacs primitive functions, and alike.
I'd add here "or debug Emacs on the C level".
> +The names of the packages that you need varies according to the
> +GNU/Linux distribution that you use. On Debian-based systems, you can
> +install all the packages needed to build the installed version of
> +Emacs with a command like 'apt-get source' (on older systems, replace
> +'emacs' with eg 'emacs25'). On Red Hat-based systems, the
> +corresponding command is <tbd>.
Does this include the emacs-debugsource stuff mentioned by Andreas?
If not, I think we should add that.
Otherwise, this is fine with me, it can be installed on master right
now.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 07:30:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 28 Sep 2019 00:55:04 -0500
>
> On 9/27/19 2:59 PM, Michael Albinus wrote:
> > But something like the following, which is very rough written, could be
> > added:
>
> Although documenting hacks to work around the problem would be better
> than nothing, it would not address the problem well.
It will do for Emacs 27, because even if we agree to your proposal, it
most probably won't be in Emacs 27.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 07:55:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Hi Paul,
> Although documenting hacks to work around the problem would be better
> than nothing, it would not address the problem well. Basically, it
> would put into an obscure location vague instructions that would have
> to be adapted by hand in a platform-dependent way, something that
> would be tricky enough that most users would likely not bother or get
> wrong.
We might add support for this.
> Better would be an approach that just works without additional
> user effort, such as the approach in the proposed patch.
The major distributions have decided to separate source packages. Do you
believe they will change their approach, after your patch has been
applied?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 09:13:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> +* GNU/Linux source packages
>> +
>> +Many GNU/Linux systems provide separate packages containing the
>> +sources of Emacs. They are useful if you want to check the source
>> +code of Emacs primitive functions, and alike.
>
> I'd add here "or debug Emacs on the C level".
This would require also the debug package, see below.
>> +The names of the packages that you need varies according to the
>> +GNU/Linux distribution that you use. On Debian-based systems, you can
>> +install all the packages needed to build the installed version of
>> +Emacs with a command like 'apt-get source' (on older systems, replace
>> +'emacs' with eg 'emacs25'). On Red Hat-based systems, the
>> +corresponding command is <tbd>.
>
> Does this include the emacs-debugsource stuff mentioned by Andreas?
> If not, I think we should add that.
Not so simple. Debug symbols are packaged in a *-dbg
package. Unfortunately, this doesn't exist for every released Emacs
version.
On Ubuntu 19.04, which I am using, I cannot see any Emacs debug
package. On Ubuntu 18.04, the recent LTS version, there is emacs25-dbg
25.2+1-6 "Debugging symbols for emacs25".
With Debian, the situation is even worse. Debian 10 (buster) does not
offer any Emacs debug package yet. Debian 9 (stretch) offers emacs24-dbg
24.5+1-11+deb9u1 "Debugging symbols for emacs24".
Shall we add debug packages to our description, even with this limited
availability?
> Otherwise, this is fine with me, it can be installed on master right
> now.
I'll wait until Monday, then I'll have a Fedora machine @work. Good for
adding the Red Hat case.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 28 Sep 2019 09:44:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 37527 <at> debbugs.gnu.org
> Date: Sat, 28 Sep 2019 11:11:53 +0200
>
> > Does this include the emacs-debugsource stuff mentioned by Andreas?
> > If not, I think we should add that.
>
> Not so simple. Debug symbols are packaged in a *-dbg
> package. Unfortunately, this doesn't exist for every released Emacs
> version.
We could qualify by "if those exist for your Emacs distribution" or
somesuch.
> I'll wait until Monday, then I'll have a Fedora machine @work. Good for
> adding the Red Hat case.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 29 Sep 2019 07:10:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 9/28/19 2:54 AM, Michael Albinus wrote:
> The major distributions have decided to separate source packages. Do you
> believe they will change their approach, after your patch has been
> applied?
I hope they don't change their approaches, as that would likely be yet
another maintenance hassle for us. However, not every distribution has a
source-code package so we'll need a backstop approach anyway, and the
backstop can be what I suggested. We can also tune Emacs for the major
distributions that have such packages, if someone finds the time to do
that and if we're willing to maintain the resulting extra complexity;
but that won't avoid the need for the backstop.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 29 Sep 2019 15:48:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I just wanted to express support for this feature, as a regular user
who would have benefitted in the past. As an example, just recently my
setup did not work as expected because of a bug now fixed in master. I
was reluctant at first to recreate the source my distribution used to
build Emacs. Had `describe-function' worked immediately I would have
found the bug in two minutes; instead I ended up spending almost half
an hour in total.
Best wishes.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 03 Oct 2019 13:40:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I'll wait until Monday, then I'll have a Fedora machine @work. Good for
>> adding the Red Hat case.
Finally, I've written the following patch. Comments?
[Message part 2 (text/plain, inline)]
diff --git a/INSTALL b/INSTALL
index 86f9e0080c..efc60bf63d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -214,6 +214,33 @@ like 'apt-get build-dep emacs' (on older systems, replace 'emacs' with
eg 'emacs25'). On Red Hat-based systems, the corresponding command is
'dnf builddep emacs' (on older systems, use 'yum-builddep' instead).
+* GNU/Linux source and debug packages
+
+Many GNU/Linux systems provide separate packages containing the
+sources and debug symbols of Emacs. They are useful if you want to
+check the source code of Emacs primitive functions or debug Emacs on
+the C level.
+
+The names of the packages that you need varies according to the
+GNU/Linux distribution that you use. On Debian-based systems, you can
+install a source package of Emacs with a command like 'apt-get source
+emacs' (on older systems, replace 'emacs' with eg 'emacs25'). The
+target directory for unpacking the source tree is the current
+directory. On Red Hat-based systems, the corresponding command is
+'dnf debuginfo-install emacs', with target directory /usr/src/debug.
+
+Once you have installed the source package, for example at
+/path/to/emacs-26.1, add the following line to your startup file:
+
+ (setq source-directory "/path/to/emacs-26.1")
+
+Emacs debugging symbols are distributed by a debug package. It does
+not exists for every released Emacs package, this depends on the
+distribution. On Debian-based systems, you can install a debug
+package of Emacs with a command like 'apt-get install emacs-dbg' (on
+older systems, replace 'emacs' with eg 'emacs25'). On Red Hat-based
+systems, the corresponding command is 'dnf debuginfo-install emacs'.
+
DETAILED BUILDING AND INSTALLATION:
[Message part 3 (text/plain, inline)]
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 03 Oct 2019 16:28:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 37527 <at> debbugs.gnu.org
> Date: Thu, 03 Oct 2019 15:38:32 +0200
>
> Finally, I've written the following patch. Comments?
Thanks for working on this.
> +The names of the packages that you need varies according to the
^^^^^^
"vary", plural.
Otherwise, LGTM.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 03 Oct 2019 16:55:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Just one more minor thing:
Michael Albinus <michael.albinus <at> gmx.de> writes:
> +Emacs debugging symbols are distributed by a debug package. It does
> +not exists for every released Emacs package, this depends on the
^^^^^^
"exist"
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 03 Oct 2019 21:51:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 10/3/19 6:38 AM, Michael Albinus wrote:
> + (setq source-directory "/path/to/emacs-26.1")
On Fedora at least, the debug packages you mention do not contain all
the Emacs source code; they contain only the source useful for C-level
debugging. So the advice should recommend setting
find-function-C-source-directory, not source-directory. For example, on
Fedora 30 right now, one could put this this into ~/.config/init.el:
(setq find-function-C-source-directory
"/usr/src/debug/emacs-26.2-1.fc30.x86_64/src")
and you could give that as an example. Please also mention that one will
need to change init.el each time Fedora issues bugfixes and updates the
"-1", or comes out with a new release and updates the "fc30", and that
if you share your home directory with some system running some other
distro or a different Fedora release then you'll need to have
more-complicated code in init.el.
It's possible that some distros ship all the Emacs source in their debug
packages, in which case the advice should say so and should say what to
do in that case too.
> On Red Hat-based systems, the corresponding command is
> 'dnf debuginfo-install emacs', with target directory /usr/src/debug.
That command is intended for installing the emacs-debuginfo package,
which differs from the emacs-debugsource package that Emacs needs here.
The command installs emacs-debugsource only as a weak dependency and
settings in dnf.conf can prevent the command from installing
emacs-debugsource at all. It would be helpful to warn about this
possibility.
Also, on Fedora at least, the debugsource packages are regularly
out-of-sync with the main packages distributed by the Fedora servers, so
the suggested approach is unreliable when Emacs is patched. This is
worth mentioning as well.
I hope this email helps to explain further why patching INSTALL is
merely a stopgap, and why we need a better solution in the next Emacs
release.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 03 Oct 2019 22:33:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> I hope this email helps to explain further why patching INSTALL is
> merely a stopgap, and why we need a better solution in the next Emacs
> release.
IMO if you need to debug Emacs outside the lisp level, you should build
it and do so from the source directory. I see no need to start
distributing the C source in installations. If any serious debugging is
needed, people are usually advised to use unoptimized builds anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 04 Oct 2019 01:29:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 10/3/19 3:32 PM, Glenn Morris wrote:
> IMO if you need to debug Emacs outside the lisp level
But I don't normally use the feature to debug Emacs's C code. I use it
to understand what the C code will do if some Lisp code calls it, in
greater detail than if I just read the doc string. I use the feature in
the same way to understand Lisp-implemented functions, too. This aspect
of the feature is useful even in prepackaged Emacs distributions where I
don't plan to debug or change either the C or the Lisp code.
Of course this aspect of the feature is not useful for everybody.
However, it is useful for some people and that provides a case for
adding it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 04 Oct 2019 08:53:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> +The names of the packages that you need varies according to the
> ^^^^^^
> "vary", plural.
Fixed, thanks.
> Otherwise, LGTM.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 04 Oct 2019 08:55:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 37527 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>> +Emacs debugging symbols are distributed by a debug package. It does
>> +not exists for every released Emacs package, this depends on the
> ^^^^^^
> "exist"
Fixed, thanks.
> Thanks,
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 04 Oct 2019 08:58:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
Hi Glenn,
> IMO if you need to debug Emacs outside the lisp level, you should build
> it and do so from the source directory. I see no need to start
> distributing the C source in installations. If any serious debugging is
> needed, people are usually advised to use unoptimized builds anyway.
I agree with you, that Emacs debugging based on distribution source and
debug packages might be problematic. As Paul has explained, just the
source package is useful for checking the C source code.
I've added installation of debug packages because other people found it
useful.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Fri, 04 Oct 2019 09:21:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Hi Paul,
> On 10/3/19 6:38 AM, Michael Albinus wrote:
>> + (setq source-directory "/path/to/emacs-26.1")
>
> On Fedora at least, the debug packages you mention do not contain all
> the Emacs source code; they contain only the source useful for C-level
> debugging. So the advice should recommend setting
> find-function-C-source-directory, not source-directory. For example,
> on Fedora 30 right now, one could put this this into
> ~/.config/init.el:
>
> (setq find-function-C-source-directory
> "/usr/src/debug/emacs-26.2-1.fc30.x86_64/src")
Lisp sources are still found via load-path. So it doesn't hurt to set
source-directory. But you are right, we shall be precise, so I have
changed accordingly.
> and you could give that as an example. Please also mention that one
> will need to change init.el each time Fedora issues bugfixes and
> updates the "-1", or comes out with a new release and updates the
> "fc30", and that if you share your home directory with some system
> running some other distro or a different Fedora release then you'll
> need to have more-complicated code in init.el.
Yep. I've added
--8<---------------cut here---------------start------------->8---
The installation directory of the Emacs source package will contain
the exact package name and version number Emacs is installed on your
system. If a new Emacs package is installed, the source package must
be reinstalled as well, and the setting in your startup file must be
updated.
--8<---------------cut here---------------end--------------->8---
>> On Red Hat-based systems, the corresponding command is
>> 'dnf debuginfo-install emacs', with target directory /usr/src/debug.
>
> That command is intended for installing the emacs-debuginfo package,
> which differs from the emacs-debugsource package that Emacs needs
> here. The command installs emacs-debugsource only as a weak dependency
> and settings in dnf.conf can prevent the command from installing
> emacs-debugsource at all. It would be helpful to warn about this
> possibility.
I know that the command installs the emacs-debuginfo package. I haven't
found a command, which installs the emacs-debugsource package
only. Could you please help me here?
> Also, on Fedora at least, the debugsource packages are regularly
> out-of-sync with the main packages distributed by the Fedora servers,
> so the suggested approach is unreliable when Emacs is patched. This is
> worth mentioning as well.
That I don't understand completely. Aren't the debug* packages intended
to be realeased under the same name+version as the binary packages? And
shouldn't they be in sync then?
> I hope this email helps to explain further why patching INSTALL is
> merely a stopgap, and why we need a better solution in the next Emacs
> release.
The main intention of this discussion is to have access to Emacs C
sources via main distributions. Whatever we change in Emacs releases
doesn't matter; it counts only what the major distributions
offer. Shouldn't we contact them (at least Debian-based and Red
Hat-based distributions), and ask the maintainers what they would expect
from us to make access to the C sources more simple? And maybe they have
also descriptions, which fit better than what I have compiled.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 06 Oct 2019 07:49:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 10/4/19 2:20 AM, Michael Albinus wrote:
> I know that the command installs the emacs-debuginfo package. I haven't
> found a command, which installs the emacs-debugsource package
> only. Could you please help me here?
Sorry, as far as I know there isn't a convenient way to do it. Such a command
was suggested here:
https://bugzilla.redhat.com/1494628#c9
but as far as I know it was never implemented. Presumably one can do it by
installing the debugsource packages by hand (e.g., see
<https://fedoraproject.org/wiki/StackTraces> and look for "minimal set" and for
"manually") but I haven't done this.
>> Also, on Fedora at least, the debugsource packages are regularly
>> out-of-sync with the main packages distributed by the Fedora servers,
>> so the suggested approach is unreliable when Emacs is patched. This is
>> worth mentioning as well.
>
> That I don't understand completely. Aren't the debug* packages intended
> to be realeased under the same name+version as the binary packages? And
> shouldn't they be in sync then?
They should be in sync, but in practice for me they have not been. There can be
nontrivial delay between the installation of an executable package and the
installation of the corresponding debuginfo/debugsource packages. I don't know
why this is. Possibly it has something to do with the DNF configuration files (I
haven't changed mine, as far as I can recall). FWIW, I don't currently have a
mismatch now (I just checked).
I update by running the command 'dnf --enablerepo=updates-debuginfo update', by
the way. Which reminds me, we should put into our instructions that one must
enable the debuginfo repo, as that's not the default.
> The main intention of this discussion is to have access to Emacs C
> sources via main distributions. Whatever we change in Emacs releases
> doesn't matter; it counts only what the major distributions
> offer.
I don't follow this point. If we install a new file foo.el the major
distributions will pick that up automatically. They will also pick it up if we
install a new file foo.c. It's just a file.
> Shouldn't we contact them (at least Debian-based and Red
> Hat-based distributions), and ask the maintainers what they would expect
> from us to make access to the C sources more simple? And maybe they have
> also descriptions, which fit better than what I have compiled.
My impression is that it will be a hassle for us to track all the major
distributions and how they do it, since they don't do it in the same way and
they occasionally change what they do. Plus, we'll have to tell people to modify
their DNF configurations (or similar configurations for other distros). This
sounds like quite a pain for everyone concerned.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Mon, 07 Oct 2019 15:19:03 GMT)
Full text and
rfc822 format available.
Message #89 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Hi Paul,
> On 10/4/19 2:20 AM, Michael Albinus wrote:
>
>> I know that the command installs the emacs-debuginfo package. I haven't
>> found a command, which installs the emacs-debugsource package
>> only. Could you please help me here?
>
> Sorry, as far as I know there isn't a convenient way to do it. Such a
> command was suggested here:
>
> https://bugzilla.redhat.com/1494628#c9
>
> but as far as I know it was never implemented. Presumably one can do
> it by installing the debugsource packages by hand (e.g., see
> <https://fedoraproject.org/wiki/StackTraces> and look for "minimal
> set" and for "manually") but I haven't done this.
>
>>> Also, on Fedora at least, the debugsource packages are regularly
>>> out-of-sync with the main packages distributed by the Fedora servers,
>>> so the suggested approach is unreliable when Emacs is patched. This is
>>> worth mentioning as well.
>> That I don't understand completely. Aren't the debug* packages
>> intended
>> to be realeased under the same name+version as the binary packages? And
>> shouldn't they be in sync then?
>
> They should be in sync, but in practice for me they have not
> been. There can be nontrivial delay between the installation of an
> executable package and the installation of the corresponding
> debuginfo/debugsource packages. I don't know why this is. Possibly it
> has something to do with the DNF configuration files (I haven't
> changed mine, as far as I can recall). FWIW, I don't currently have a
> mismatch now (I just checked).
The text mentions now, that the installed Emacs and Emacs source package
shall run the same version.
> I update by running the command 'dnf --enablerepo=updates-debuginfo
> update', by the way. Which reminds me, we should put into our
> instructions that one must enable the debuginfo repo, as that's not
> the default.
Yes. Since people tend to forget this, it might be better to enable it
permanently via 'dnf config-manager --set-enabled updates-debuginfo'. And
then one could install the Emacs source package directly, as 'dnf
install emacs-debugsource'. I've adapted the text accordingly.
People who use the Emacs source package shall enable the debuginfo
repository anyway, to get the proper version during
>> The main intention of this discussion is to have access to Emacs C
>> sources via main distributions. Whatever we change in Emacs releases
>> doesn't matter; it counts only what the major distributions
>> offer.
>
> I don't follow this point. If we install a new file foo.el the major
> distributions will pick that up automatically. They will also pick it
> up if we install a new file foo.c. It's just a file.
Yes. But foo.c will go into the Emacs source package.
>> Shouldn't we contact them (at least Debian-based and Red
>> Hat-based distributions), and ask the maintainers what they would expect
>> from us to make access to the C sources more simple? And maybe they have
>> also descriptions, which fit better than what I have compiled.
>
> My impression is that it will be a hassle for us to track all the
> major distributions and how they do it, since they don't do it in the
> same way and they occasionally change what they do. Plus, we'll have
> to tell people to modify their DNF configurations (or similar
> configurations for other distros). This sounds like quite a pain for
> everyone concerned.
Again, I doubt that major distributions will provide C-source files
another way than via Emacs source packages. So we must describe how to
get them (that's this thread about), and maybe we could arrange with the
distoro's maintainers simper ways.
Attached the current version of my patch.
[Message part 2 (text/plain, inline)]
diff --git a/INSTALL b/INSTALL
index 86f9e0080c..d159f2ef9a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -206,7 +206,7 @@ need to compile it. For example, to compile Emacs with support for X
and graphics libraries, you may need to install the X development
package(s), and development versions of the jpeg, png, etc. packages.
-The names of the packages that you need varies according to the
+The names of the packages that you need vary according to the
GNU/Linux distribution that you use, and the options that you want to
configure Emacs with. On Debian-based systems, you can install all the
packages needed to build the installed version of Emacs with a command
@@ -214,6 +214,42 @@ like 'apt-get build-dep emacs' (on older systems, replace 'emacs' with
eg 'emacs25'). On Red Hat-based systems, the corresponding command is
'dnf builddep emacs' (on older systems, use 'yum-builddep' instead).
+* GNU/Linux source and debug packages
+
+Many GNU/Linux systems provide separate packages containing the
+sources and debug symbols of Emacs. They are useful if you want to
+check the source code of Emacs primitive functions or debug Emacs on
+the C level.
+
+The names of the packages that you need vary according to the
+GNU/Linux distribution that you use. On Debian-based systems, you can
+install a source package of Emacs with a command like 'apt-get source
+emacs' (on older systems, replace 'emacs' with eg 'emacs25'). The
+target directory for unpacking the source tree is the current
+directory. On Red Hat-based systems, the corresponding command is
+'dnf install emacs-debugsource', with target directory /usr/src/debug
+(this requires to add the *-debuginfo repositories first, via 'dnf
+config-manager --set-enabled fedora-debuginfo updates-debuginfo').
+
+Once you have installed the source package, for example at
+/path/to/emacs-26.1, add the following line to your startup file:
+
+ (setq find-function-C-source-directory
+ "/path/to/emacs-26.1/src")
+
+The installation directory of the Emacs source package will contain
+the exact package name and version number Emacs is installed on your
+system. If a new Emacs package is installed, the source package must
+be reinstalled as well, and the setting in your startup file must be
+updated.
+
+Emacs debugging symbols are distributed by a debug package. It does
+not exist for every released Emacs package, this depends on the
+distribution. On Debian-based systems, you can install a debug
+package of Emacs with a command like 'apt-get install emacs-dbg' (on
+older systems, replace 'emacs' with eg 'emacs25'). On Red Hat-based
+systems, the corresponding command is 'dnf debuginfo-install emacs'.
+
DETAILED BUILDING AND INSTALLATION:
[Message part 3 (text/plain, inline)]
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Mon, 07 Oct 2019 19:49:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 10/7/19 8:17 AM, Michael Albinus wrote:
> Attached the current version of my patch.
Thanks, that doc patch looks good as a stopgap, though I still want
something better after Emacs 27 comes out.
Is the emacs-26 branch still active and still being merged from? If so,
I suggest installing the patch into the emacs-26 branch, since the
patch's advice is also good for Emacs 26 and won't break anything.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 08 Oct 2019 07:48:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 37527 <at> debbugs.gnu.org,
> Glenn Morris <rgm <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 7 Oct 2019 12:48:45 -0700
>
> Is the emacs-26 branch still active and still being merged from?
It shouldn't be active, we should work only on master now. Although
if someone makes some doc change there by mistake, it isn't a
catastrophe, it just requires merges that otherwise wouldn't have been
necessary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 08 Oct 2019 09:55:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Is the emacs-26 branch still active and still being merged from?
>
> It shouldn't be active, we should work only on master now. Although
> if someone makes some doc change there by mistake, it isn't a
> catastrophe, it just requires merges that otherwise wouldn't have been
> necessary.
I've installed the patch in the master branch. I like also to close this
bug, since the proposed initial patch is not applied. Maybe it might
need more discussion for Emacs 28, but this shall happen in emacs-devel
I believe, in order to be visible for more people.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 08 Oct 2019 11:59:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 37527 <at> debbugs.gnu.org, rgm <at> gnu.org
> Date: Tue, 08 Oct 2019 11:54:04 +0200
>
> I like also to close this bug, since the proposed initial patch is
> not applied. Maybe it might need more discussion for Emacs 28, but
> this shall happen in emacs-devel I believe, in order to be visible
> for more people.
the proposed original patch is indeed not applied, but the issue
discussed here is not completely resolved. So we could leave the bug
open. However, if Paul would like to close it and later reopen or
open another one, I don't mind.
IOW, I'll leave it to Paul to decide whether to close this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Mon, 20 Jan 2020 19:13:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 37527 <at> debbugs.gnu.org, rgm <at> gnu.org
>> Date: Tue, 08 Oct 2019 11:54:04 +0200
>>
>> I like also to close this bug, since the proposed initial patch is
>> not applied. Maybe it might need more discussion for Emacs 28, but
>> this shall happen in emacs-devel I believe, in order to be visible
>> for more people.
>
> the proposed original patch is indeed not applied, but the issue
> discussed here is not completely resolved. So we could leave the bug
> open. However, if Paul would like to close it and later reopen or
> open another one, I don't mind.
>
> IOW, I'll leave it to Paul to decide whether to close this bug.
What is the status of this, given that the emacs-27 is now cut?
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 21 Jan 2020 09:15:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 1/20/20 11:12 AM, Stefan Kangas wrote:
> What is the status of this, given that the emacs-27 is now cut?
Thanks for reminding me of this problem. The stuff in INSTALL is not quite right
- at least, it didn't work for me in Ubuntu 18.04.3 (which is Debian based) due
to some problem in my sources.list (which I hadn't messed with, so I guess
Ubuntu must differ from Debian here). In contrast, INSTALL is overly complicated
for Fedora 31 since it gives a bunch of confusing instructions for sources and
debuginfo whereas all I needed to do was 'dnf debuginfo-install emacs' to get
all that stuff done.
More generally, even if we fix these INSTALL problems, INSTALL won't work for
other GNU/Linux distributions, or for non-GNU distributions for that matter. Nor
will it work when people install Emacs themselves. And the INSTALL instructions
will continue to be complicated and awkward, and will likely need to be
maintained as Debian and Red Hat evolve.
So we still need something better. I rebased and tweaked the proposed patch
(including a revamp of the INSTALL section to try to address some of the
abovementioned problems) and am attaching the updated version.
[0001-Install-C-source-code-for-C-h-f-etc.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 21 Jan 2020 17:03:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 21 Jan 2020 01:13:53 -0800
>
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -522,6 +522,7 @@ init_cmdargs (int argc, char **argv, int skip_args, char const *original_pwd)
> if (!NILP (etc_exists))
> {
> Vinstallation_directory = Ffile_name_as_directory (dir);
> + Vsource_directory = Vinstallation_directory;
> break;
> }
> }
> @@ -547,6 +548,7 @@ init_cmdargs (int argc, char **argv, int skip_args, char const *original_pwd)
> {
> tem = Fexpand_file_name (build_string (".."), dir);
> Vinstallation_directory = Ffile_name_as_directory (tem);
> + Vsource_directory = Vinstallation_directory;
> break;
> }
Bother. Should we really step on source-directory like that? What if
the original source tree still exists? Maybe it would be safer to
introduce a new variable, say, install-source-directory?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 21 Jan 2020 17:49:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/21/20 9:02 AM, Eli Zaretskii wrote:
> Should we really step on source-directory like that? What if
> the original source tree still exists?
Those assignments occur when you're running out of a just-built Emacs, and the
intent is that they set source-directory to the original source tree. They're
helpful in a typical just-built case when you haven't installed yet; if we
omitted the assignments, C-h f etc. wouldn't find the source code automatically.
> Maybe it would be safer to
> introduce a new variable, say, install-source-directory?
I don't offhand see why that'd be safer. It would be more complicated, and the
complexity would make it less safe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 21 Jan 2020 18:05:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 21 Jan 2020 09:48:39 -0800
>
> On 1/21/20 9:02 AM, Eli Zaretskii wrote:
> > Should we really step on source-directory like that? What if
> > the original source tree still exists?
>
> Those assignments occur when you're running out of a just-built Emacs, and the
> intent is that they set source-directory to the original source tree. They're
> helpful in a typical just-built case when you haven't installed yet; if we
> omitted the assignments, C-h f etc. wouldn't find the source code automatically.
>
> > Maybe it would be safer to
> > introduce a new variable, say, install-source-directory?
>
> I don't offhand see why that'd be safer. It would be more complicated, and the
> complexity would make it less safe.
Sorry, I'm probably confused. I thought your patch sets
source-directory to point to where the compressed sources will be
installed, is that not what it does? If I misunderstood, just ignore
that comment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Wed, 22 Jan 2020 00:28:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/21/20 10:04 AM, Eli Zaretskii wrote:
> I thought your patch sets
> source-directory to point to where the compressed sources will be
> installed, is that not what it does?
Yes, that's what the patch typically does. However, when Emacs is run
out of its original source tree the code snippets you cited override the
typical behavior, and set source-directory to be the original source
tree instead of to the place where the compressed sources will be installed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Wed, 22 Jan 2020 03:32:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 21 Jan 2020 16:27:41 -0800
>
> On 1/21/20 10:04 AM, Eli Zaretskii wrote:
> > I thought your patch sets
> > source-directory to point to where the compressed sources will be
> > installed, is that not what it does?
>
> Yes, that's what the patch typically does. However, when Emacs is run
> out of its original source tree the code snippets you cited override the
> typical behavior, and set source-directory to be the original source
> tree instead of to the place where the compressed sources will be installed.
Then I still think an additional variable might be a better solution,
because the original source tree might still exist, and so losing the
information about its location would be a disadvantage.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 23 Jan 2020 08:59:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/21/20 7:31 PM, Eli Zaretskii wrote:
> Then I still think an additional variable might be a better solution,
> because the original source tree might still exist, and so losing the
> information about its location would be a disadvantage.
? The code in question does not lose information about the location of the
original source tree. On the contrary, it supplies that information.
If you're suggesting that every installed Emacs should contain a string pointing
to where it was built, I'm not sure that's a good idea. Generally speaking,
builds should be reproducible and build products should not contain unimportant
information about the build (such as timestamps and whatnot) as that makes it
harder to reproduce them later.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 23 Jan 2020 14:24:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 23 Jan 2020 00:58:11 -0800
>
> On 1/21/20 7:31 PM, Eli Zaretskii wrote:
> > Then I still think an additional variable might be a better solution,
> > because the original source tree might still exist, and so losing the
> > information about its location would be a disadvantage.
>
> ? The code in question does not lose information about the location of the
> original source tree. On the contrary, it supplies that information.
If the source tree still exists, the information is already available,
it is recorded at build time.
> If you're suggesting that every installed Emacs should contain a string pointing
> to where it was built, I'm not sure that's a good idea. Generally speaking,
> builds should be reproducible and build products should not contain unimportant
> information about the build (such as timestamps and whatnot) as that makes it
> harder to reproduce them later.
Reproducible builds is a separate issue; in a reproducible build no
directories should be recorded at build time. Let's consider builds
that aren't meant to be reproducible.
Let me turn the table and ask: if Emacs was installed with the
sources, but the original source tree where it was built still exists,
where will source-directory point after your changes? Will it point
to the installed sources or to the original source tree?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 23 Jan 2020 17:43:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/23/20 6:23 AM, Eli Zaretskii wrote:
> if Emacs was installed with the
> sources, but the original source tree where it was built still exists,
> where will source-directory point after your changes?
It'll point to the original source tree if you're running Emacs out of
the build directory. If you're running Emacs out of the installed
directory, it will point to the installed source tree.
> Let's consider builds
> that aren't meant to be reproducible.
Although we can do that, generally speaking it's better when there's no
difference between reproducible and irreproducible builds, as that's one
less thing to worry about when maintaining and debugging.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Thu, 23 Jan 2020 18:25:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 23 Jan 2020 09:42:10 -0800
>
> On 1/23/20 6:23 AM, Eli Zaretskii wrote:
> > if Emacs was installed with the
> > sources, but the original source tree where it was built still exists,
> > where will source-directory point after your changes?
>
> It'll point to the original source tree if you're running Emacs out of
> the build directory. If you're running Emacs out of the installed
> directory, it will point to the installed source tree.
In that case, I will repeat my suggestion to have a separate variable
for the installed sources, because otherwise we are making an
incompatible behavior change.
> > Let's consider builds
> > that aren't meant to be reproducible.
>
> Although we can do that, generally speaking it's better when there's no
> difference between reproducible and irreproducible builds, as that's one
> less thing to worry about when maintaining and debugging.
All the rest being equal, yes. But all the rest is not equal in this
case, because your proposal changes a long-standing behavior in a very
reasonable use case.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 25 Jan 2020 00:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
bug acknowledged by developer.
(Sat, 25 Jan 2020 00:49:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 37527-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 1/23/20 10:24 AM, Eli Zaretskii wrote:
> In that case, I will repeat my suggestion to have a separate variable
> for the installed sources, because otherwise we are making an
> incompatible behavior change.
OK, I did it that way by installing the attached patch instead; the new
separate variable is 'emacs-source-directory'.
[0001-Install-C-source-code-for-C-h-f-etc.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sat, 25 Jan 2020 08:00:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527-done <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 24 Jan 2020 16:47:49 -0800
>
> OK, I did it that way by installing the attached patch instead; the new
> separate variable is 'emacs-source-directory'.
Thanks, but the name of this variable gives no clue about the sources
being installed as part of "make install", and neither does its
documentation. How about emacs-installed-source-directory?
> +DEBUGGING AN INSTALLED EMACS
> +
> +* Installed Emacs source code
> +
> +Emacs installs a compressed copy of much of its source code, to make
"optionally installs", right? This is an opt-in feature, right?
> @@ -374,6 +377,7 @@ epaths-force:
> -e 's;\(#.*PATH_BITMAPS\).*$$;\1 "${bitmapdir}";' \
> -e 's;\(#.*PATH_X_DEFAULTS\).*$$;\1 "${x_default_search_path}";' \
> -e 's;\(#.*PATH_GAME\).*$$;\1 $(PATH_GAME);' \
> + -e 's;\(#.*PATH_EMACS_SOURCE\).*$$;\1 "${emacs_srcdir}";' \
> -e 's;\(#.*PATH_DOC\).*$$;\1 "${etcdocdir}";') && \
> ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h
The epath-force-w32 part needs a similar change.
> +AC_ARG_ENABLE([install-srcdir],
> + [AS_HELP_STRING([--disable-install-srcdir],
> + [do not install low-level Emacs source code useful for debugging.])],
I don't think we agreed to make this on by default, did we?
> +** The new variable 'emacs-source-directory' gives the Emacs source
> +code location.
This should explain that this is a copy of the sources, different
from the original source tree where Emacs was built.
> (defvar find-function-C-source-directory
> - (let ((dir (expand-file-name "src" source-directory)))
> - (if (file-accessible-directory-p dir) dir))
> + (let ((dir (expand-file-name "src" emacs-source-directory)))
> + (if (file-accessible-directory-p dir) dir
> + (setq dir (expand-file-name "src" source-directory))
> + (if (file-accessible-directory-p dir) dir)))
This is backwards, IMO: it should first try the original source tree,
and only next the installed sources.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 09:01:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 37527 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 1/24/20 11:58 PM, Eli Zaretskii wrote:
> Thanks, but the name of this variable gives no clue about the sources
> being installed as part of "make install", and neither does its
> documentation. How about emacs-installed-source-directory?
We don't use 'installed-' in other names that have similar roles, e.g.,
'data-directory'. These variables and their uses don't care how the files got
there, and their names and documentation should focus on what the variables are
used for, not on the build process that set them up.
>> +Emacs installs a compressed copy of much of its source code, to make
>
> "optionally installs", right? This is an opt-in feature, right?
It's optional, but it's opt-out. I installed the attached patch, which changes
the wording to "typically installs". I thought it pretty clear during the
discussion that it would be opt-out; that's what my original patch proposed,
anyway. I don't see why we'd want it to be opt-in.
>> +** The new variable 'emacs-source-directory' gives the Emacs source
>> +code location.
>
> This should explain that this is a copy of the sources, different
> from the original source tree where Emacs was built.
Also done in the attached patch.
>> (defvar find-function-C-source-directory
>> - (let ((dir (expand-file-name "src" source-directory)))
>> - (if (file-accessible-directory-p dir) dir))
>> + (let ((dir (expand-file-name "src" emacs-source-directory)))
>> + (if (file-accessible-directory-p dir) dir
>> + (setq dir (expand-file-name "src" source-directory))
>> + (if (file-accessible-directory-p dir) dir)))
>
> This is backwards, IMO: it should first try the original source tree,
> and only next the installed sources.
The original source tree location is unreliable and is documented to be
unreliable, whereas the installed sources are supposed to match the Emacs you're
running and that is more useful for C-h f and friends. I'd rather try the
reliable copy first.
[0001-Improve-doc-for-emacs-source-directory-Bug-36527.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 26 Jan 2020 01:00:34 -0800
>
> Thanks, but the name of this variable gives no clue about the sources
> being installed as part of "make install", and neither does its
> documentation. How about emacs-installed-source-directory?
>
> We don't use 'installed-' in other names that have similar roles, e.g., 'data-directory'. These variables and their uses don't care how the files got there, and their names and documentation should focus on what the variables are used for, not on the build process that set them up.
The files in those directories are always installed, and we never
reference them in the original source tree, so this is different.
> I thought it pretty clear during the discussion that it would be opt-out; that's what my original patch proposed, anyway. I don't see why we'd want it to be opt-in.
The discussion back then indicates that this wasn't clear at all. I
suggested this to be off by default right at the beginning of the
discussion, and proposed to wait to hear user feedback first, see
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00581.html
Andreas said we should instead teach Emacs to look for the sources in
the debug source directory, see
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00584.html
Several other people opined that installing sources shouldn't be the
default, and some said right away that they will disable this if
installed.
Also, there was some kind of consensus that providing sources to be
installed by end-users is something the distros should do, and distros
don't need this turned on by default. By contrast, users who build
their own Emacs are not very likely to want the sources installed the
second time.
Therefore, it sounds like making this the default is premature, and we
should change it to be an opt-in feature.
> (defvar find-function-C-source-directory
> - (let ((dir (expand-file-name "src" source-directory)))
> - (if (file-accessible-directory-p dir) dir))
> + (let ((dir (expand-file-name "src" emacs-source-directory)))
> + (if (file-accessible-directory-p dir) dir
> + (setq dir (expand-file-name "src" source-directory))
> + (if (file-accessible-directory-p dir) dir)))
>
> This is backwards, IMO: it should first try the original source tree,
> and only next the installed sources.
>
> The original source tree location is unreliable and is documented to be unreliable, whereas the installed sources are supposed to match the Emacs you're running and that is more useful for C-h f and friends. I'd rather try the reliable copy first.
Which one is the reliable one depends on whether this option was
specified at configure time, and for users who install precompiled
distributions, also on whether they decide to install the sources. So
they are both unreliable, but Emacs developers are much more likely to
have source-directory populated, so we should start with that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 18:19:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/26/20 8:13 AM, Eli Zaretskii wrote:
> they are both unreliable
Only if we make them so. As things stand, emacs-source-directory is more
reliable than source-directory is, and if we remove the configure-time option to
omit installation of source code (a step I favor) we will make
emacs-source-directory even more reliable than it is now.
It's long past time that we stopped making Emacs source code a second-class
citizen. The GNU philosophy is that it should be easy to see the source, and we
should be guided by that philosophy here.
We cannot rely on distributors to make things easy here. Some distributors do
not install source; others install it in different places, only optionally, and
do so in obscure ways that most users don't know about. Distributors will follow
our lead if we install the source in a well-specified place. If we tried instead
to find the nook or cranny (if any) where the current distributor squirrels away
the Emacs source code, this problem would continue to be a maintenance headache
for us. It's not worth the hassle.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 19:25:01 GMT)
Full text and
rfc822 format available.
Message #154 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 26 Jan 2020 10:18:38 -0800
>
> On 1/26/20 8:13 AM, Eli Zaretskii wrote:
> > they are both unreliable
>
> Only if we make them so. As things stand, emacs-source-directory is more
> reliable than source-directory is, and if we remove the configure-time option to
> omit installation of source code (a step I favor) we will make
> emacs-source-directory even more reliable than it is now.
>
> It's long past time that we stopped making Emacs source code a second-class
> citizen. The GNU philosophy is that it should be easy to see the source, and we
> should be guided by that philosophy here.
>
> We cannot rely on distributors to make things easy here. Some distributors do
> not install source; others install it in different places, only optionally, and
> do so in obscure ways that most users don't know about. Distributors will follow
> our lead if we install the source in a well-specified place. If we tried instead
> to find the nook or cranny (if any) where the current distributor squirrels away
> the Emacs source code, this problem would continue to be a maintenance headache
> for us. It's not worth the hassle.
Sorry, I cannot be convinced by reiterating the same views and
high-level abstract ideas. We had a discussion, where no consensus
was reached about making this the default. I don't see why would you
decide to unilaterally override all those valid opinions to the
contrary. Please make this opt-in.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 20:08:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Distributors will follow our lead if we install the source in a
> well-specified place.
Have you asked them?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 20:10:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 37527 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Sorry, I cannot be convinced by reiterating the same views and
> high-level abstract ideas. We had a discussion, where no consensus
> was reached about making this the default.
FTR, I have been, and still am, with Eli here.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Sun, 26 Jan 2020 20:11:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, stefan <at> marxist.se, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2020 21:06:45 +0100
>
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
> > Distributors will follow our lead if we install the source in a
> > well-specified place.
>
> Have you asked them?
AFAIU, distributors already have their solution for this -- they
package the sources with the debug info distribution. Andreas
mentioned that in the discussion we had back then, but his suggestion
was ignored, which I think is a mistake.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Mon, 27 Jan 2020 21:18:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 37527 <at> debbugs.gnu.org (full text, mbox):
On 1/26/20 11:24 AM, Eli Zaretskii wrote:
> Please make this opt-in.
If that's the case, let's revert the patch. Later we could try something
fancier along the lines Andreas suggested, perhaps involving using
distributors' already-existing locations since that's more likely to
work (albeit not that likely, alas) than a build-time opt-in which is
pretty much a recipe for failure.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37527; Package
emacs.
(Tue, 28 Jan 2020 03:23:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 37527 <at> debbugs.gnu.org (full text, mbox):
> Cc: stefan <at> marxist.se, michael.albinus <at> gmx.de, rgm <at> gnu.org,
> 37527 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 27 Jan 2020 13:17:22 -0800
>
> On 1/26/20 11:24 AM, Eli Zaretskii wrote:
> > Please make this opt-in.
>
> If that's the case, let's revert the patch. Later we could try something
> fancier along the lines Andreas suggested, perhaps involving using
> distributors' already-existing locations
Fine with me, thanks.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 28 Jan 2020 19:58:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 27 Feb 2020 02:17:01 GMT)
Full text and
rfc822 format available.
Removed tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 09 Aug 2020 18:51:01 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.