Bug#553164: rpm: macrofiles ignored in rpmconfig.
> 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 recompile of RHEL. > Was rpmconfig file processed at all? The rpmconfig file is opened, and the contents are read. The rpmmacros file is not read. Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553164: rpm: macrofiles ignored in rpmconfig.
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:
/usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:/etc/rpm/macros.specspo:/etc/rpm/macros.prelink:/etc/rpm/macros.solve:/etc/rpm/macros.up2date:/etc/rpm/macros:/etc/rpm/%{_target}/macros:/home/mph45/svn/pscsg/gridservices/FTS/tier1-fts-config/trunk/rpmmacros
and an rpmmacros file:
%_topdir
/home/mph45/svn/pscsg/gridservices/FTS/tier1-fts-config/trunk
%_sourcedir %{_topdir}/src
%_specdir %{_topdir}
%_srcrpmdir %{_topdir}/rpm
%_rpmdir %{_topdir}/rpm
It then runs rpmbuild like:
rpmbuild -ba \
--rcfile=/usr/lib/rpm/rpmrc:/home/mph45/svn/pscsg/gridservices/FTS/tier1-fts-config/trunk/rpmconfig
\
tier1-fts-config.spec
However, despite being listed in the rpmconfig the generated rpmmacros
file isn't read, and the build fails. If I copy this rpmmacros file to
~/.rpmmacros, the build process works fine.
Is macrofiles not supported?
Thanks,
Matt
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.25 (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages rpm depends on:
ii debconf [debconf-2.0] 1.5.27Debian configuration management sy
ii libc6 2.9-27GNU C Library: Shared libraries
ii libelf10.143-1 library to read and write ELF file
ii libnss3-1d 3.12.4-1 Network Security Service libraries
ii libpopt0 1.15-1lib for parsing cmdline parameters
ii librpm04.7.1-10 RPM shared library
ii librpmbuild0 4.7.0-9 RPM build shared library
ii librpmio0 4.7.1-10 RPM IO shared library
ii perl 5.10.1-5 Larry Wall's Practical Extraction
ii rpm-common 4.7.1-10 common files for RPM
ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime
Versions of packages rpm recommends:
ii rpm2cpio 4.7.1-10 tool to convert RPM package to CPI
Versions of packages rpm suggests:
ii alien 8.78 convert and install rpm and other
pn elfutils (no description available)
pn rpm-i18n (no description available)
-- debconf information:
rpm/upgrade-failed:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#442425: debian-el: suggest apt-utils-show-package defer package name completions
> 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 consider > having apt-utils-build-completion-table directly build a list > instead of going through a buffer (there's other split-strings, so > that isn't a complete fix). Hi Kevin, Thanks for the updated patch. Looks good with initial testing. I'll check it into CVS in a couple of days. I can't remember why split-string is used in apt-utils-build-completion-table; maybe there is no good reason. The problem remains with the use of split-string in apt-utils-build-package-list, with quadratic time, or whatever the dependence is, is confined to mule variants IIRC, the nomule variants working OK. Thanks, Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442425: debian-el: suggest apt-utils-show-package defer package name completions
> 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 available to defer building the list? Yes, it can be tested for, but equivalent (or at least reasonable) behaviour should be expected where it isn't supported. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442425: debian-el: suggest apt-utils-show-package defer package name completions
> 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 test-completion built-in function is apparently only available in GNU Emacs 22. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442425: debian-el: suggest apt-utils-show-package defer package name completions
> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442425: debian-el: suggest apt-utils-show-package defer package name completions
> 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 list, is very slow on
> > my system and it's good to get the prompt without doing that,
> > since of course you can type a package name without using the
> > completions. The few lines below work for me, using a
> > completions handler function.
> Peter Galbraith writes:
> I don't know whether you are subscribed to the package to receive
> bug emails, but this is interesting.
Hi Peter,
I'm not opposed to something like the above, but it only delays the
pain of building the package lists until the package name is entered.
However, I notice at least two problems with the patch as it stands:
(1) Entering an invalid package name for which there is a valid
completion, e.g., M-x apt-utils-show-package RET foo RET results in
a message to rebuild the package lists.
(2) If the package lists become outdated (maybe an `apt-get update'
has been run; simulate by touching apt-utils-timestamped-file,
/var/cache/apt/pkgcache.bin), then apt-utils-show-package leads to
an error like:
Debugger entered--Lisp error: (error "Command attempted to use minibuffer
while in minibuffer")
yes-or-no-p("APT package lists may be out of date. Update them? ")
(if apt-utils-automatic-update-asked nil (setq
apt-utils-automatic-update-asked t) (yes-or-no-p "APT package lists may be out
of date. Update them? "))
(unless apt-utils-automatic-update-asked (setq
apt-utils-automatic-update-asked t) (yes-or-no-p "APT package lists may be out
of date. Update them? "))
(cond ((eq apt-utils-automatic-update t)) ((eq apt-utils-automatic-update
...) (unless apt-utils-automatic-update-asked ... ...)))
(and (apt-utils-packages-needs-update) apt-utils-automatic-update (cond
(...) (... ...)))
(cond ((null apt-utils-package-list-built)
(apt-utils-build-package-list)) ((and ... apt-utils-automatic-update ...)
(apt-utils-build-package-list t)))
apt-utils-check-package-lists()
Thanks,
Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340694: emacs-goodies-el: home-end-enable defcustom clobbers bindings.
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-line. Perhaps the values of (key-binding [end]) and (key-binding [home]) should be stored and used for the nil home-end-enable case? Thanks, Matt -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages emacs-goodies-el depends on: ii bash3.0-17 The GNU Bourne Again SHell ii emacs-snapshot-gtk [emacsen 1:20051117-1 The GNU Emacs editor (with GTK+ 2. ii emacs21 [emacsen] 21.4a-3 The GNU Emacs editor ii xemacs21-nomule [emacsen] 21.4.17-2highly customizable text editor -- Versions of packages emacs-goodies-el recommends: ii dict 1.9.15-1 Dictionary Client ii perl-doc 5.8.7-8Perl documentation ii wget 1.10.2-1 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337028: acknowledged by developer (Bug#337028: fixed in alien 8.58)
> 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 build failed. Here's the log of the command (cd alien-8.58; rpmbuild -bb --target noarch alien-8.58-2.spec): error: License field must be present in package: (main package) Building target platforms: noarch Building for target noarch Thanks, Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337224: emacs-wiki: enumerated list when a number ends a sentence.
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:
Paragraphs that contain a number at the end of a sentence like this
2005. Apparently look like a list has started?
is interpreted as the second line starting an enumerated list. The
generated HTML includes:
Paragraphs that contain a number at the end of a sentence like this
Apparently look like a list has started?
Can this situation be protected against somehow?
Thanks,
Matt
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages emacs-wiki depends on:
ii emacs21 [emacsen] 21.4a-3The GNU Emacs editor
ii xemacs21 21.4.17-2 highly customizable text editor
ii xemacs21-nomule [xemacs21]21.4.17-2 highly customizable text editor --
emacs-wiki recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337028: alien: generates unsupported rpm syntax in spec file.
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 to get 74.1kB of source archives.
Get:1 http://mirror.ox.ac.uk unstable/main alien 8.56 (dsc) [494B]
Get:2 http://mirror.ox.ac.uk unstable/main alien 8.56 (tar) [73.6kB]
Fetched 2B in 0s (72B/s)
dpkg-source: extracting alien in alien-8.56
dpkg-source: unpacking alien_8.56.tar.gz
[...]
dpkg-deb: building package `alien' in `../alien_8.56_all.deb'.
dpkg-genchanges -b
dpkg-genchanges: binary-only upload - not including any source code
dpkg-buildpackage: binary only upload (no source included)
$ sudo alien --to-rpm --verbose alien_8.56_all.deb
dpkg-deb --info alien_8.56_all.deb control 2>/dev/null
dpkg-deb --info alien_8.56_all.deb control 2>/dev/null
dpkg-deb --info alien_8.56_all.deb conffiles 2>/dev/null
dpkg-deb --fsys-tarfile alien_8.56_all.deb | tar tf -
dpkg-deb --info alien_8.56_all.deb postinst 2>/dev/null
dpkg-deb --info alien_8.56_all.deb postrm 2>/dev/null
dpkg-deb --info alien_8.56_all.deb preinst 2>/dev/null
dpkg-deb --info alien_8.56_all.deb prerm 2>/dev/null
mkdir alien-8.56
mkdir: cannot create directory `alien-8.56': File exists
chmod 755 alien-8.56
dpkg-deb -x alien_8.56_all.deb alien-8.56
rpm --showrc
cd alien-8.56; rpmbuild -bb --target noarch alien-8.56-2.spec 2>&1
Package build failed. Here's the log of the command (cd alien-8.56;
rpmbuild -bb --target noarch alien-8.56-2.spec):
error: Legacy syntax is unsupported: copyright
error: line 6: Unknown tag: Copyright: see /usr/share/doc/alien/copyright
Building target platforms: noarch
Building for target noarch
find alien-8.56 -type d -exec chmod 755 {} ;
rm -rf alien-8.56
--
The change appears deliberate; from /usr/share/doc/rpm/changelog.gz:
- obsolete Serial:, Copyright:, and RHNPlatform: syntax in spec files.
Thanks.
Matt
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages alien depends on:
ii cpio 2.6-9 GNU cpio -- a program to manage ar
ii debhelper 4.9.15 helper programs for debian/rules
ii dpkg-dev 1.13.11package building tools for Debian
ii make 3.80-11The GNU version of the "make" util
ii perl 5.8.7-7Larry Wall's Practical Extraction
ii rpm 4.4.1-4Red Hat package manager
alien recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329792: ripperx: Error writing playlists.
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 problem can be seen in the following, when writing the playlist
for the fourth album (Parallel Lines):
$ strace ripperx 2>&1 |grep playlist.m3u
open("/scratch/matt/mp3s/Kate Bush/Hounds of Love/playlist.m3u",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 12
open("/scratch/matt/mp3s/Suzanne Vega/Nine Objects Of Desire/playlist.m3u",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 15
open("/scratch/matt/mp3s/Tanya Donelly/Lovesongs For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 20
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
open("/scratch/matt/mp3s/Blondie/Parallel Liness For
Underdogs/playlist.m3u", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such
file or directory)
My config is:
,[ ~/.ripperXrc ]
| //
| // ~/.ripperXrc
| // This is the resource file for ripperX.
| // If you edit this file with an editor, you must leave all
| // parameters in the order in which they appear. Also note
| // that this file is overwritten each time ripperX is run.
| //
| // You can configure everything in the config menu within ripperX.
| //
|
| //-V 2.6.6
|
| General::WavRatio = 0.005043
| General::Mp3Ratio = 0.001945
| General::ShellForExecution = /bin/sh
| General::WavPath = /scratch/matt/mp3s
| General::Mp3Path = /scratch/matt/mp3s
| General::CDDBPath = ./.cddbslave
| General::WavFileNameFormat = track%
| General::Mp3FileNameFormat = track%
| General::PrependChar = _
| General::MakeMp3FromExistingWav = 0
| General::AskWhenFileExists = 1
| General::AutoAppendExtension = 1
| General::KeepWav = 0
| Ripper::Ripper = cdparanoia
| Ripper::Plugin = ripperX_plugin-cdparanoia
| Encoder::Encoder = lame
| Encoder::Bitrate = 128
| Encoder::VarBitrate = 1
| Encoder::VBRQual = 4
| Encoder::Priority = 10
| Encoder::HighQual = 1
| Encoder::useCRC = 0
| Encoder::extraOptions =
| Encoder::fullCommand = lame -b 128 --nohist -v -h -V 4
| Encoder::Plugin = ripperX_plugin-lame
| CdPlayer::Play_command = cdplay play %
| CdPlayer::Stop_command = cdplay stop
| WavPlayer::Command = splay %
| Mp3Player::Command = mpg123 %
| CDDBConfig::Server = www.freedb.org/cgi-bin/cddb.cgi
| CDDBConfig::Port = 80
| CDDBConfig::UseHttp = 1
| CDDBConfig::ProxyServer = wwwcache.rl.ac.uk
| CDDBConfig::ProxyPort = 8080
| CDDBConfig::ConvertSpaces = 0
| CDDBConfig::MakeDirectories = 1
| CDDBConfig::CreateID3 = 1
| CDDBConfig::CreatePlaylist = 1
| CDDBConfig::AutoLookup = 0
| CDDBConfig::FormatString = %s
| CDDBConfig::DirFormatString = %a/%v
`
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages ripperx depends on:
ii cdparanoia3a9.8-11 An audio extraction tool for sampl
ii libc6 2.3.5-6GNU C Library: Shared libraries an
ii libglib1.21.2.10-10 The GLib library of C routines
ii libgtk1.2
Bug#325317: debian-el: Interactive call to "apt-utils-show-package" doesn't work
> 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 in the 24.11-1 release of debian-el (in testing and unstable). Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317566: [New file] minibuf-electric.el
> 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, leaving > only "~/". This is nicer than having to explicitly erase the > contents of the minibuffer. In the next GNU Emacs release, the following will achieve this: (setq file-name-shadow-tty-properties '(invisible t)) (file-name-shadow-mode 1) so adding rfn-eshadow.el from the CVS repository to emacs-goodies-el is another possibility. (When Emacs 22 is packaged, I guess you may have to think about which should come first in the load-path; other packages that will be distributed with Emacs 22 and are already in emacs-goodies-el include table and wdired. Maybe this is already sorted -- I didn't look.) Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302888: debian-el: apt-utils-show-package is broken
>>>>> 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.gz> I believe this is suitable for inclusion in the next release of debian-el. Thanks, Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302888: debian-el: apt-utils-show-package is broken
> 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. > Something for you to look into... Thanks for bringing this to my attention. The unexpected release of 21.4 messed up some tests for available features. With the current code, and GNU Emacs 21.4, you need to evaluate (or temporarily add to your .emacs): (setq apt-utils-completing-read-hashtable-p nil apt-utils-face-property 'face) and it should then work. This is fixed in the latest code, where the checks for these features are more robust, and don't rely on the version number of Emacs. This is available at: https://alioth.debian.org/download.php/1014/apt-utils-2.2.0.tar.gz. (Alioth also hosts the CVS repository.) 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. Thanks, Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290091: emacs-wiki: problem editing links.
> 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 for > the current Emacs session? Thanks. This appears to have fixed the problem. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290091: emacs-wiki: problem editing links.
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" and "bar", respectively. This is the result of the expression: (looking-at emacs-wiki-url-or-name-regexp))) in emacs-wiki-link-at-point, such that: (match-string-no-properties 1) "[[foo][bar]]" (match-string-no-properties 2) "foo" (match-string-no-properties 3) "[bar]" (match-string-no-properties 4) "bar" and in emacs-wiki-edit-link-at-point matches 1 and 3 are presented. In fact, the behaviour is sensitive to the position of point within the invisible text; if I use emacs-wiki-next-reference and forward-char before trying to edit the link, then emacs-wiki-link-at-point returns nil, and an error is flagged. As far as I have tested, the behaviour is as expected as long as point isn't on one of the first two [ characters at the beginning of the invisible link text. I think it's important that this feature should work when a link is moved to with emacs-wiki-next-reference, and the behaviour should probably be the same regardless of where point is within the link, especially since the text isn't opened (made visible) when moving through it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages emacs-wiki depends on: ii emacs21 21.3+1-8 The GNU Emacs editor ii xemacs21 21.4.16-1 Editor and kitchen sink ii xemacs21-nomule [xemacs21]21.4.16-1 Editor and kitchen sink -- Non-mul -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
