Bug 227418
Summary: | rpm-spec-mode's compilation buffer is read only | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ville Skyttä <ville.skytta> | ||||||||||
Component: | emacs | Assignee: | Daniel Novotny <dnovotny> | ||||||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | high | ||||||||||||
Version: | 9 | CC: | enpontus, jrowens.fedora, laurent.rineau__fedora, me, mtasaka, ndbecker2 | ||||||||||
Target Milestone: | --- | Keywords: | Patch | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2009-07-15 08:20:59 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 249532 | ||||||||||||
Attachments: |
|
Description
Ville Skyttä
2007-02-05 21:19:07 UTC
Created attachment 147407 [details]
Allow rpmbuild to write to compilation buffer
Still this problem exits on F-7 emacs-22.0.990-2.fc7 . Ok i tried above patch but had to change this line in the patch: + (setq buffer-read-only nil))) to + (setq buffer-read-only nil)) (i.e. remove a right parenthesis) after that though it works due to lack of hackery knopwledge i do not dare to submit an updated patch *** Bug 254561 has been marked as a duplicate of this bug. *** (In reply to comment #3) > Ok i tried above patch but had to change this line in the patch: > > + (setq buffer-read-only nil))) > > to > > + (setq buffer-read-only nil)) > > (i.e. remove a right parenthesis) It worked as-is for me, and trying it without the parenthesis broke the build for me, while compiling the elc. It makes sense too: count the parentheses. The removed line had one left, two right parentheses; the inserted lines have three left, four right parentheses. Bug 249532 is somewhat vague, but covers the read-only problem, too, as well as the ignore-errors problem (bug 306841). *** Bug 249532 has been marked as a duplicate of this bug. *** Chip, I am using your attachment #191641 [details], attached to bug #249532, for a few weeks (...say two). It works great and solves both bugs, as far as I have seen. Created attachment 277611 [details]
Updated Fedora 8 patch
I just updated the patch to apply to the increased line numbers in Fedora 8's
rpm-spec-mode.el, that's all.
(In reply to comment #9) > Created an attachment (id=277611) [edit] > Updated Fedora 8 patch > > I just updated the patch to apply to the increased line numbers in Fedora 8's > rpm-spec-mode.el, that's all. Ummm, this is a completely different patch and does not reflect the approach I am proposing (that we use a real compilation mode, "rpmbuild-mode"). Chip Sorry, I should have been clearer, my updated patch above was based on Ville Skyttä's patch in comment #1. But then, that is the one that's actually attached to this bug report itself. (In reply to comment #11) > Sorry, I should have been clearer, my updated patch above was based on Ville > Skyttä's patch in comment #1. But then, that is the one that's actually > attached to this bug report itself. I see. Would you be willing to try the other rpm-spec-mode.el from attachment #191641 [details] ? Chip It doesn't really apply to attachment #191641 [details]. That's an entire replacement for
the file. All I did was update the little patch to reflect the changed line
numbers. If your replacement needs any updating to work with Fedora 8, it's way
beyond me; I don't know lisp at all, just how to find similar points in
different versions of a program. But I doubt it needs updating for F8; elisp
hasn't changed that much in the past half year or so!
(In reply to comment #13) > It doesn't really apply to attachment #191641 [details] [edit]. That's an entire replacement for > the file. All I did was update the little patch to reflect the changed line > numbers. If your replacement needs any updating to work with Fedora 8, it's way > beyond me; I don't know lisp at all, just how to find similar points in > different versions of a program. But I doubt it needs updating for F8; elisp > hasn't changed that much in the past half year or so! Actually, that was the wrong attachment. Please try attachment 271411 [details]; it's a drop-in replacement for rpm-spec-mode.el that uses a real compilation mode for rpmbuild, instead of trying to allocate a process buffer itself. You don't have to patch it; just drop it in your site-lisp (or load it manually) and let us know if it works. Thanks, Chip Chip: The same still applies to that patch, though. I'm not up to fixing a whole elisp program replacement. Just renumbering patch files. Anyone could do that, I just happened to be the first that did it here. If you just want me to test it a bit, I'd be willing enough, but only temporarily; I like signing my RPMs. :) (In reply to comment #14) > Please try attachment 271411 [details] [edit]; it's a > drop-in replacement for rpm-spec-mode.el that uses a real compilation mode for > rpmbuild, instead of trying to allocate a process buffer itself. I haven't actually tried it, but looked at the code. It looks to me that this implementation drops at least some of the functionality related to signing packages as part of the build (passphrase entry without echoing it on the console, caching of entered GPG passphrases), is that correct and intentional? Ah, I see John already commented about the signing feature. (In reply to comment #17) > Ah, I see John already commented about the signing feature. Yes, the signing feature needs to be added back. I'm thinking of this "rpmbuild-mode as a compiliation mode" version rpm-spec-mode as a proof of concept for right now. I think in the long run it will be more maintainable, because we can remove the process buffer infrastructure from rpm-spec-mode and hopefully upstream will maintain compilation-mode (which right now has only one other consumer, namely grep-mode). Chip Sounds good. By the way, the current code won't work in XEmacs - XEmacs doesn't have compilation-start. compile-internal appears to serve a similar purpose there. (In reply to comment #19) > Sounds good. By the way, the current code won't work in XEmacs - XEmacs doesn't > have compilation-start. compile-internal appears to serve a similar purpose there. Interesting. compilation-start is also used by grep-mode in GNU Emacs. Does XEmacs also allocate a process buffer for grep-mode? Chip There's no grep-mode in XEmacs either. Created attachment 303198 [details]
Use a real compilation mode
Personally, I think this is a better fix. Instead of papering over the
problem, let's use a real compilation mode.
This patch also adds two features:
1. rpm-spec-smp-mflags for building on multi-cpu systems
2. detect if we are in an .../SPECS directory, and if so, define _topdir
I find both of those features very convenient.
Chip
FWIW, personally I wouldn't like either of the new features much; I think it's just fine to set them in ~/.rpmmacros. If these are going in, in particular, defining _topdir and thus possibly (it might not have any real effect) overriding my ~/.rpmmacros dir structure settings should be an opt-in feature, not something always silently done, and not even on by default if you ask me. Looks like the rpm-increase-release-tag improvements requested in bug 432209 were not applied yet, here's a direct link: http://cvs.xemacs.org/viewcvs.cgi/XEmacs/packages/xemacs-packages/prog-modes/rpm-spec-mode.el.diff?r1=1.25&r2=1.26&diff_format=u Was dropping "(provide 'rpm-spec-mode)" intentional BTW? (In reply to comment #22) > > 2. detect if we are in an .../SPECS directory, and if so, define _topdir > > I find both of those features very convenient. (In reply to comment #23) > FWIW, personally I wouldn't like either of the new features much; I think it's > just fine to set them in ~/.rpmmacros. Now, how do you accomplish #2 with a setting in ~/.rpmmacros? Suppose I have two buffers open in emacs: a/rpm/SPECS/a.spec b/rpm/SPECS/b.spec I want to build the "a" package under the "a" directory tree, and the "b" package under the "b" directory tree. Is there a way to write an rpm macro that accomplishes this? Chip (In reply to comment #23) > FWIW, personally I wouldn't like either of the new features much; I think it's > just fine to set them in ~/.rpmmacros. If these are going in, in particular, > defining _topdir and thus possibly (it might not have any real effect) > overriding my ~/.rpmmacros dir structure settings should be an opt-in feature, > not something always silently done, and not even on by default if you ask me. OK, I have modified the patch so that it doesn't set _smp_mflags at all, and doesn't set _topdir unless you set a customization boolean to true (default false). That should prevent surprises. > Looks like the rpm-increase-release-tag improvements requested in bug 432209 > were not applied yet, here's a direct link: > http://cvs.xemacs.org/viewcvs.cgi/XEmacs/packages/xemacs-packages/prog-modes/rpm-spec-mode.el.diff?r1=1.25&r2=1.26&diff_format=u I put that change in. > Was dropping "(provide 'rpm-spec-mode)" intentional BTW? No. Ooops. Chip Created attachment 303316 [details]
Use a real compilation mode for rpmbuild
RE: XEmacs compatibility C-h f "compilation-mode" shows that compilation-mode exists in XEmacs, but diverges. I tried loading the latest rpm-spec-mode attached and get "Symbol's function is void: define-compilation-mode". (In reply to comment #24) > Now, how do you accomplish #2 with a setting in ~/.rpmmacros? I don't know, but I've never found myself in a situation where I'd want that behaviour. (In reply to comment #25) > OK, I have modified the patch so that it doesn't set _smp_mflags at all, and > doesn't set _topdir unless you set a customization boolean to true (default > false). That should prevent surprises. That looks better to me. (In reply to comment #27) > C-h f "compilation-mode" shows that compilation-mode exists in XEmacs, but > diverges. I tried loading the latest rpm-spec-mode attached and get "Symbol's > function is void: define-compilation-mode". I suppose this is intentional per comments here and in bug 432209 - the forked rpm-spec-mode.el makes no effort to be compatible with XEmacs. Thus it can't be used with XEmacs or merged into XEmacs CVS at the moment (until reworked to work with XEmacs' compilation-mode.el or until XEmacs' compilation-mode.el is synced with GNU Emacs) but that's not too big a deal as XEmacs does not suffer from the problem that this patch addresses for GNU Emacs. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping emacs-22.1-12.fc8 has been submitted as an update for Fedora 8 emacs-22.1-12.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update emacs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-4535 This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |