> Michal Čihař writes:
Hi Michal,
> I have no clue right, but anything what works on Fedora should also
> work with Debian packaged rpm. If you used different rpm branch (eg.
> Mandriva or SUSE one), it is possible that it has different behavior.
It works on Scientific Linux, which is a r
Package: rpm
Version: 4.7.1-10
Severity: normal
Hi,
I'm trying to get an RPM build to work on Debian that works OK on a
RedHat system. The build process writes in the current working
directory
(/home/mph45/svn/pscsg/gridservices/FTS/tier1-fts-config/trunk) an
rpmconfig file:
macrofiles:
> Kevin Ryde writes:
> But I couldn't test on xemacs, it seems to take ages building the
> package lists (without me doing anything to it yet :-), 20 minutes
> and still going. I suspect split-string is taking quadratic time
> somehow. If true it's xemacs's problem, though you might cons
> Peter Galbraith writes:
> > I meant that the test-completion built-in function is apparently
> > only available in GNU Emacs 22.
> Sorry, you can tell that I haven't been following closely. Would
> something like a (functionp 'test-completion) condition enable you
> to use it when ava
> Peter Galbraith writes:
> > This seems to work OK, but test-completion isn't available for
> > XEmacs 21 or GNU Emacs 21, and I'd prefer things to work with
> > both these releases.
> I'm missing something. Do you mean that you don't have these
> installed to test?
I meant that the t
> Kevin Ryde writes:
> > Unless I've botched that handler...
> Ah, which was indeed the case ...
This seems to work OK, but test-completion isn't available for XEmacs
21 or GNU Emacs 21, and I'd prefer things to work with both these
releases.
Thanks,
Matt
--
To UNSUBSCRIBE, email to [
> Kevin Ryde <[EMAIL PROTECTED]> wrote:
>
> > It'd be nice if M-x apt-utils-show-package, when it prompts for a
> > package name, didn't build the list of possible names until you
> > hit tab or whatever to try to complete from among them. The
> > apt-cache program, or whatever builds the l
Package: emacs-goodies-el
Version: 26.4-1
Severity: normal
The defcustom for home-end-enable binds [end] to end-of-line and
[home] to beginning-of-line when home-end-enable is nil. This matters
for the emacs-snapshot package where the default bindings are to
move-end-of-line and move-beginning-of
> Debian System writes:
>* Remove Copyright: from generated alien spec file since for
> some reason rpm has obsoleted and begun falling over on that
> line. (Inert profanity here.) Closes: #337028
It now fails due to lack of License field:
$ sudo alien --to-rpm alien_8.58_all.deb
Package: emacs-wiki
Version: 2.70-3
Severity: normal
With the following minimal configuration:
(progn
(require 'emacs-wiki)
(setq emacs-wiki-projects '(("Test"))
emacs-wiki-directories '("/tmp/Wiki")
emacs-wiki-publishing-directory "/tmp/WebWiki"))
a Wiki page containing:
Pa
Package: alien
Version: 8.56
Severity: normal
Alien apparently generates a spec file that makes rpm fall over:
--
$ sudo apt-get source -b alien
Reading package lists... Done
Building dependency tree... Done
Need
Package: ripperx
Version: 2.6.6-1
Severity: normal
Under some circumstances, playlist (.m3u) files don't get written. My
guess is that this is when the length of the path to the playlist file
for a given CD is shorter than the previous one, and some string
doesn't get terminated correctly.
The p
> Igor B. Poretsky writes:
> May be it pretends that Emacs 21.4 can do something that it
> actually can't? Placing into ~/.emacs or /etc/emacs/default.el the
> next form solves the problem:
These checks are now done correctly (checking features rather than
version numbers). This is fixed
> Karl Hegbloom writes:
> This works with GNU Emacs. It implements the XEmacs minibuffer
> behavior for C-x C-f and other file name reading actions. When you
> type "//", it clears the minibuffer back to the start, leaving only
> a single "/". When you type a "~", it does the similar, l
>>>>> Matt Hodges writes:
> Peter, can you include the latest apt-utils.el source in the next
> release of debian-el? Should be safe to close the bug after that.
A later version is now available at:
https://alioth.debian.org/download.php/1048/apt-utils-2.4.0.tar.g
> Peter S Galbraith writes:
> > I'm getting the following error with two different machines
> > running Sarge. The error occurs upon doing "M-x
> > apt-utils-show-package TAB" or after typing the package name and
> > pressing Enter. Tested with "emacs21 -q" with the same results.
> Somet
> Michael Olson writes:
> Thanks for the report! I think I've fixed this in the development
> version. A release should be on the way next week. In the
> meantime, can you copy the following two functions to the *scratch*
> buffer, hit M-C-x on each one, and see if the problem goes away
Package: emacs-wiki
Version: 2.66-1
Severity: normal
Suppose I write a link [[foo][bar]] and move to it with
emacs-wiki-next-reference. When I try and edit it with
emacs-wiki-edit-link-at-point, in the edit process the link is
presented as "[[foo][bar]]", and the text as "[bar]", rather than
"foo
18 matches
Mail list logo
