Bug 227418

Summary: rpm-spec-mode's compilation buffer is read only
Product: [Fedora] Fedora Reporter: Ville Skyttä <ville.skytta>
Component: emacsAssignee: Daniel Novotny <dnovotny>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 9CC: 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 Flags
Allow rpmbuild to write to compilation buffer
none
Updated Fedora 8 patch
none
Use a real compilation mode
none
Use a real compilation mode for rpmbuild none

Description Ville Skyttä 2007-02-05 21:19:07 UTC
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 21:19:07 UTC
Created attachment 147407 [details]
Allow rpmbuild to write to compilation buffer

Comment 2 Mamoru TASAKA 2007-06-04 06:01:22 UTC
Still this problem exits on F-7 emacs-22.0.990-2.fc7 .

Comment 3 Pontus Enhager 2007-08-21 20:41:44 UTC
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 06:15:03 UTC
*** Bug 254561 has been marked as a duplicate of this bug. ***

Comment 5 J. Randall Owens 2007-08-27 08:58:18 UTC
(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 12:06:52 UTC
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 13:49:24 UTC
*** Bug 249532 has been marked as a duplicate of this bug. ***

Comment 8 Laurent Rineau 2007-11-28 14:02:23 UTC
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 05:12:47 UTC
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 15:33:06 UTC
(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 18:47:32 UTC
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 18:38:26 UTC
(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 19:05:53 UTC
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 19:09:19 UTC
(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 19:48:37 UTC
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 19:57:57 UTC
(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 20:03:35 UTC
Ah, I see John already commented about the signing feature.

Comment 18 Chip Coldwell 2007-12-06 21:13:02 UTC
(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 22:07:41 UTC
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 15:27:12 UTC
(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 15:37:25 UTC
There's no grep-mode in XEmacs either.

Comment 22 Chip Coldwell 2008-04-21 20:12:27 UTC
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 06:08:17 UTC
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 13:44:05 UTC
(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 14:33:57 UTC
(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 14:36:45 UTC
Created attachment 303316 [details]
Use a real compilation mode for rpmbuild

Comment 27 Brad Walker 2008-04-22 23:49:42 UTC
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 11:26:47 UTC
(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-14 02:35:24 UTC
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 16:27:42 UTC
emacs-22.1-12.fc8 has been submitted as an update for Fedora 8

Comment 31 Fedora Update System 2008-05-29 02:44:12 UTC
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 22:26:18 UTC
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 08:20:59 UTC
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.