Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer
Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800): > However, I don't see how "-f batch-byte-compile" can be used when > the .elc file must be created in a directory separate from the one > containing the .el file. I meant, instead of reinventing the wheel with this part: --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))" Example: mkdir /tmp/foo /tmp/bar echo '(message "hi")' > /tmp/foo/foo.el emacs --batch \ --eval '(setq byte-compile-dest-file-function (lambda (x) "/tmp/bar/foo.elc"))' \ -f batch-byte-compile /tmp/foo/foo.el -> generates /tmp/bar/foo.elc batch-byte-compile exists since forever. > I think automake generates code the way it does because GNU coding > standards mandate that one be able to build from a read-only > hierarchy of sources (think read-only media). Again, not something Emacs itself supports for its own Lisp files.
Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer
The obsolete bytecomp feature is back as of Emacs 9964db4. BTW, why doesn't lisp.am use the standard "-f batch-byte-compile" method of producing .elc files? Your two issues that affected only automake illustrate that the way automake generates .elc files is different to the vast majority of Emacs projects.
Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer
Jim Meyering wrote: > Remember: this arises only in a non-srcdir build. That means build > artifacts end up being written into the mostly-empty current directory > hierarchy, which does not have copies of the sources. Installation > processes will continue to copy both .el and .elc files into place. Oh, so you only split .el and .elc up while building, but they get installed into the same place? That's not so bad, though it is, eg, not something that Emacs supports in its own build process (in non-srcdir builds, .elc still get written into srcdir). BTW: ELCFLAGS=-lbytecomp is presumably another way to solve your issue, for any version of Emacs and automake (once bytecomp is loaded you can redefine functions as you wish).
Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer
Jim Meyering wrote: > In May of 2017, support for using the long-deprecated > byte-compile-dest-file function was removed, and that removal broke > automake's elisp-compiling rule for any .el file not in the current > directory. In general, Emacs expects .el and .elc to be found in the same directory. Not adhering to this convention will likely break various Emacs features. Is this really something automake needs to enable at all?
bug#14059: broken link in autotools doku (sent to gnu webmasters and autotools developers)
It seems you sent this bug report to bug-automake by bcc. This confuses debbugs.gnu.org, which has no idea which package the report should be associated with. Hence your message ended up on the help-debbugs mailing list. I have assigned your report to automake, so that this message and any future ones should go to the right list (bug-automake). http://debbugs.gnu.org/14059 Arne Babenhauserheide (IMK) wrote: Dear GNU Hackers, The dependencies page¹ of autotools links to a non-existing page²: ¹: http://www.gnu.org/software/automake/manual/html_node/Dependencies.html#Dependencies ²: http://www.gnu.org/software/automake/manual/automake-history/Dependency-Tracking-Evolution.html#Dependency-Tracking-Evolution (I just hit that broken link while searching for solutions and thought that it's best to report it) Best wishes, Arne
bug#10248: Broken link to sources.redhat.com in the web page of the automake mailing list
Hi, You change this by going to the administrative interface in mailman https://lists.gnu.org/mailman/admin/automake Then in the General Options page, edit the introductory description section and then press submit. Changes should be instantaneous.
Re: debbugs, and a FAQ, for Autotools
However, my biggest concern is that right now, I filter both autoconf and automake messages into the same mail folder, but debbugs anonymizes which list a bug is being reported against (that is, the To: is rewritten as ###@debbugs.gnu.org, so there is no longer any mention of 'automake' in any of the normal mail headers). There is an X-GNU-PR-Package: header that you can filter on, or configure your mail client to display by default. Or, you will still receive the messages via the appropriate mailing list, so there will be the standard List-Id etc headers. But no, there is no indication that is visible by default if you have chosen to put two mailing lists into the same folder. Maybe you could turn on the Mailman subject_prefix option for your lists? (It was a deliberate change to make it rewrite the To: header. After about a year of using it for Emacs without that change, it was a frequent occurence that people were either replying to both ###@debbugs and bug-gnu-emacs, thus creating a bunch of pointless duplicate mails, or replying to just bug-gnu-emacs, and somehow creating a new bug report, which was even more annoying.)
Re: debbugs, and a FAQ, for Autotools
Glenn Morris wrote (on Mon, 21 Feb 2011 at 16:08 -0500): Maybe you could turn on the Mailman subject_prefix option for your lists? Actually, that might interfere with how debbugs recognizes replies to existing bug reports that get sent to eg bug-automake rather than ###@debbugs. It might cause these to generate new bug reports.
Re: debbugs and (was: slow make clean)
Ralf Wildenhues wrote (on Mon, 14 Feb 2011 at 22:02 +0100): Here's a Debian PR with discussion, and a patch and description: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34071#62 Does that help any (haven't looked closely)? No, that is the initial implementation of the feature that we have and that as I describe in bug#5439 doesn't work. From the close message of #34071 * Added per bug subscription support to debbugs, which relies on an external MLM to actually deal with the requests; currently works with eoc and sends messages to bugnum\@$gListDomain. (closes: #34071) eoc = Enemies of Carlotta No use at all for GNU Mailman lists.
Re: debbugs and (was: slow make clean)
Ralf Wildenhues wrote (on Sun, 13 Feb 2011 at 19:01 +0100): I glanced over the debbugs documentation at debbugs.gnu.org now, but couldn't find a place that said something about subscribing to individual bugs. Glen, do you happen to know more about this? I know that it doesn't work, and personally I don't know how to implement it. :( http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
Actually, that was probably too glib a response. The version number information is probably used in other places, and needs to be sortable so that the fixed/found commands can work. So I don't think arbitrary version strings can work. You could use the date of a commit perhaps.
bug#7333: [PATCH] {maint} Fix a bug in variable concatanation with `+='.
Ralf Wildenhues wrote (on Mon, 8 Nov 2010 at 22:46 +0100): BTW, Ouch! I see that my previous reply presenting the patch has erroneously opended a new, spurious bug report (#7345) in the tracker! Ralf, could you please you close that report as invalid? Not sure how that happened, probably the Subject: change. It was a combination of changing the subject plus cc'ing bug-automake. bug-automake is basically an alias for sub...@debbugs now. Anything sent there that is not obviously replying to an existing report creates a new bug. There is no need to cc bug-automake on replies to reports; #...@debbugs can be thought of as an alias for that. The only time to use the bug-automake address now is in new bug reports. Sending to both just creates duplicates. The commands above (Bcc:ed to control at debbugs) should merge and close both bugs. The (first) close didn't work, I think it was because your version number started with a `v', not a digit. The second close worked.
Re: [coreutils] debbugs
1) Change the automake maintainer to bug-automake 2) Activate a router rule for bug-automake, that would redirect messages to debbugs.gnu.org. This should happen automatically once I add an entry to the appropriate config file on debbugs.gnu.org (has not been tested yet, but should work). Please do that. Thanks! OK, done. In theory the router rule should take effect in the next hour.
Re: [coreutils] debbugs
1) Change the automake maintainer to bug-automake 2) Activate a router rule for bug-automake, that would redirect messages to debbugs.gnu.org. This should happen automatically once I add an entry to the appropriate config file on debbugs.gnu.org (has not been tested yet, but should work). Please do that. Thanks! OK, done. In theory the router rule should take effect in the next hour.
Re: [coreutils] debbugs
Hi,
Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):
Thank you for this writeup, also for the other documentation accessible
from the toplevel and http://debbugs.gnu.org/Developer.html.
Most of that is generic Debbugs documentation, by the way.
There is one question I haven't seen addressed yet, that I think should
be documented: is it possible to easily export the bug database to some
other format? Are there maybe any converters that do this already?
(I'm thinking that it should be possible, but if one has to completely
invent it anew, that would at least be some work.)
Hmm. I don't know - there might be some Debian tools to do that?
The bugs can be retrieved as mbox folders via the web-interface, eg:
http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209
Internally, they are all stored as basically mbox mail folders with
some extra sections inbetween the messages. There are two extra files
that summarize the status. Everything is plain text.
Then, if there is an importer, we might want to consider importing the
old Gnats database bugs. I don't even know whether exporting from
Gnats is possible, though.
Again, I am not aware of any importer, but there might be one. If not,
it's probably doable, but I not sure how much work it would be.
I think we want this. Does bug-coreutils operate in Exclusive mode?
Yes, it does. By the way, that is just a term I made up. :)
I think that is what would be easiest for bug-automake as well.
I agree.
You can use my email address as maintainer and debbugs-submit moderator
for now.
Done. automake exists as a package now, and I filed a test bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7209
You should get a mail about it. You can play around with replying,
setting severity, closing, etc.
The bug-automake list is known under its name only, as far as I know.
OK.
When you are ready to go ahead, the final steps would be to:
1) Change the automake maintainer to bug-automake
2) Activate a router rule for bug-automake, that would redirect
messages to debbugs.gnu.org. This should happen automatically once I
add an entry to the appropriate config file on debbugs.gnu.org (has not
been tested yet, but should work).
My current plan is to apply the patch below to the tree, create the HTML
page from it and upload it to
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html
(where it will appear for the next release anyway), so you could use
that as Specific help link on http://debbugs.gnu.org/.
+...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
+bug tracker}.
May be better to simply use http://debbugs.gnu.org/automake there.
Re: [coreutils] debbugs
Hi, With that in mind, I'm looking for something that can keep things in order in some way, be that things added by users or ourselves. Who do we talk to if we want to try it out? Glenn Morris is the guy. He set up the emacs one and then made it so that with almost no work we could use it for coreutils, too. You are very welcome to try it out, and you prompted me to create a web-page explaining how it works: http://debbugs.gnu.org/Using.html Let me know if you have any questions.
