Bug 227418 - rpm-spec-mode's compilation buffer is read only
rpm-spec-mode's compilation buffer is read only
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
9
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Novotny
: Patch
: 249532 254561 (view as bug list)
Depends On:
Blocks: 249532
  Show dependency treegraph
 
Reported: 2007-02-05 16:19 EST by Ville Skyttä
Modified: 2009-07-15 04:20 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:20:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Allow rpmbuild to write to compilation buffer (498 bytes, patch)
2007-02-05 16:19 EST, Ville Skyttä
no flags Details | Diff
Updated Fedora 8 patch (517 bytes, patch)
2007-12-05 00:12 EST, J. Randall Owens
no flags Details | Diff
Use a real compilation mode (3.29 KB, patch)
2008-04-21 16:12 EDT, Chip Coldwell
no flags Details | Diff
Use a real compilation mode for rpmbuild (4.40 KB, patch)
2008-04-22 10:36 EDT, Chip Coldwell
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2007-02-05 16:19:07 EST
rpm-build-* commands can't write their output to the compilation buffer, because
it's read only.

To reproduce, make sure that rpm-spec-use-compilation-mode is true, load a
specfile, and do eg. "C-c C-b s", get an error:

error in process filter: Buffer is read-only: #<buffer *rpmbuild -bs foo.spec*>

Fix attached, although this is not that elegant since it leaves the compilation
buffer in read write mode.  A better one would be such that it'd keep the buffer
read only but let the rpmbuild command write to it - but this is good enough for
me for now :)
Comment 1 Ville Skyttä 2007-02-05 16:19:07 EST
Created attachment 147407 [details]
Allow rpmbuild to write to compilation buffer
Comment 2 Mamoru TASAKA 2007-06-04 02:01:22 EDT
Still this problem exits on F-7 emacs-22.0.990-2.fc7 .
Comment 3 Pontus Enhager 2007-08-21 16:41:44 EDT
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
Comment 4 J. Randall Owens 2007-08-26 02:15:03 EDT
*** Bug 254561 has been marked as a duplicate of this bug. ***
Comment 5 J. Randall Owens 2007-08-27 04:58:18 EDT
(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.
Comment 6 Michael Schwendt 2007-10-02 08:06:52 EDT
Bug 249532 is somewhat vague, but covers the read-only problem,
too, as well as the ignore-errors problem (bug 306841).
Comment 7 Chip Coldwell 2007-11-28 08:49:24 EST
*** Bug 249532 has been marked as a duplicate of this bug. ***
Comment 8 Laurent Rineau 2007-11-28 09:02:23 EST
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.
Comment 9 J. Randall Owens 2007-12-05 00:12:47 EST
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.
Comment 10 Chip Coldwell 2007-12-05 10:33:06 EST
(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
Comment 11 J. Randall Owens 2007-12-05 13:47:32 EST
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.
Comment 12 Chip Coldwell 2007-12-06 13:38:26 EST
(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


Comment 13 J. Randall Owens 2007-12-06 14:05:53 EST
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!
Comment 14 Chip Coldwell 2007-12-06 14:09:19 EST
(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
Comment 15 J. Randall Owens 2007-12-06 14:48:37 EST
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. :)
Comment 16 Ville Skyttä 2007-12-06 14:57:57 EST
(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?
Comment 17 Ville Skyttä 2007-12-06 15:03:35 EST
Ah, I see John already commented about the signing feature.
Comment 18 Chip Coldwell 2007-12-06 16:13:02 EST
(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
Comment 19 Ville Skyttä 2007-12-06 17:07:41 EST
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.
Comment 20 Chip Coldwell 2007-12-07 10:27:12 EST
(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

Comment 21 Ville Skyttä 2007-12-07 10:37:25 EST
There's no grep-mode in XEmacs either.
Comment 22 Chip Coldwell 2008-04-21 16:12:27 EDT
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
Comment 23 Ville Skyttä 2008-04-22 02:08:17 EDT
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?
Comment 24 Chip Coldwell 2008-04-22 09:44:05 EDT
(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
Comment 25 Chip Coldwell 2008-04-22 10:33:57 EDT
(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

Comment 26 Chip Coldwell 2008-04-22 10:36:45 EDT
Created attachment 303316 [details]
Use a real compilation mode for rpmbuild
Comment 27 Brad Walker 2008-04-22 19:49:42 EDT
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".
Comment 28 Ville Skyttä 2008-04-26 07:26:47 EDT
(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.
Comment 29 Bug Zapper 2008-05-13 22:35:24 EDT
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
Comment 30 Fedora Update System 2008-05-23 12:27:42 EDT
emacs-22.1-12.fc8 has been submitted as an update for Fedora 8
Comment 31 Fedora Update System 2008-05-28 22:44:12 EDT
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
Comment 33 Bug Zapper 2009-06-09 18:26:18 EDT
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
Comment 34 Bug Zapper 2009-07-15 04:20:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.