Bug#341333: mplayerplug-in: Missing watch file
Package: mplayerplug-in Severity: minor In the latest upload, you mentioned that the watch file was removed because Sourceforge links are not supported. This is untrue. According to the manpage: # If your package is located on sourceforge, use the following format # to automatically use the qa.debian.org redirector, avoiding SF's # difficult mirror system. http://sf.net/aa-project/aalib-(.*)\.tar\.gz This has been supported since the 2.9 version of devscripts. The following format should work for mplayerplug-in: http://sf.net/mplayerplug-in/mplayerplug-in-(\d+\.\d+)\.tar\.gz -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#342794: break-thread is not persistent when changing folders/restarting mutt-ng
Package: mutt-ng Version: 0.0+20051125-1 Severity: normal Tags: experimental If I break a thread, change to a different folder, change back to the previous folder, the thread is no longer broken. Ditto if I break a thread and then restart mutt-ng. If I use mutt to break the thread, everything works as expected. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages mutt-ng depends on: ii libc62.3.5-8.1 GNU C Library: Shared libraries an ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error01.1-4 library for common error values an ii libgpgme11 1.1.0-1 GPGME - GnuPG Made Easy ii libidn11 0.5.18-1GNU libidn library, implementation ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libqdbm111.8.33-2QDBM Database Libraries [runtime] ii libsasl2 2.1.19-1.7 Authentication abstraction library ii postfix [mail-transport-agen 2.2.4-1.0.1 A high-performance mail transport mutt-ng recommends no packages. -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#342511: fish: hangs/blocks when starting
On Thu, Dec 08, 2005 at 06:58:52PM +1100, Michael Wardle wrote: > When running "fish" from within my login shell (zsh), it hangs > indefinitely before even showing a prompt. The only way to use it is > to press Ctrl-C which interrupts it. This is also how I start fish and I'm unable to reproduce the problem. Your other email implied that it might be a fishd issue. There's been some work on the interaction between fish and fishd in newer releases. I'll be uploading the latest upstream version this weekend. Hopefully that will fix the problems you're seeing. If not, Axel is pretty responsive with bug reports so I'll ping him to see if he has any idea what might be happening. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgp6uufqAj7ak.pgp Description: PGP signature
Bug#338557: Not fixed ; actually worse
tag 338557 + pending thanks On Tue, Dec 13, 2005 at 04:22:09PM +0100, Mike Hommey wrote: > This bug is not fixed. It's actually worse now. The whole urgency string > is highlighted red, now. Yes, this was a mistake on my part. We've already applied the patch from #343136 and it will be fully fixed in the next upload. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpMyQtVejfiB.pgp Description: PGP signature
Bug#337716: abcde: man page typo
Package: abcde Version: 2.3.99-1 Severity: minor The description for the '-B' option says 'vatiable' instead of 'variable'. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages abcde depends on: ii cd-discid 0.9-1 CDDB DiscID utility ii cdparanoia3a9.8-11 An audio extraction tool for sampl ii flac 1.1.2-3Free Lossless Audio Codec - comman ii vorbis-tools 1.0.1-1.5 Several Ogg Vorbis Tools ii wget 1.10.2-1 retrieves files from the web abcde recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336081: pbuilder: pdebuild creates incorrect diff.gz files
Package: pbuilder Version: 0.136 Severity: normal The diff.gz built during a pdebuild run is incorrect as it ends up diffing a warning message from dpkg-architecture against each file. This causes a later dpkg-source -x to fail since the patch expects every file in the diff to start off as a single line file containing the warning. I've attached a sample diff.gz as an example. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-debil Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages pbuilder depends on: ii cdebootstrap 0.3.9 Bootstrap a Debian system ii coreutils 5.2.1-2.1 The GNU core utilities ii debianutils 2.15 Miscellaneous utilities specific t ii gcc 4:4.0.2-1 The GNU C compiler ii wget 1.10.2-1 retrieves files from the web Versions of packages pbuilder recommends: ii devscripts2.9.8 Scripts to make the life of a Debi ii fakeroot 1.5.4 Gives a fake root environment ii sudo 1.6.8p9-3 Provide limited super user privile -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> fish_1.16.1-1.diff.gz Description: Binary data signature.asc Description: Digital signature
Bug#336327: dbp-importdsc: Hangs while attempting to pull the latest upstream from .upstream directory
Package: darcs-buildpackage Version: 0.5.5 Severity: important As the subject says, dbp-importdsc just hangs when trying to pull from the latest upstream version from the .upstream local repo. [ [EMAIL PROTECTED] (2.4G free) % dbp-importdsc fish_1.16.1-1.dsc Not importing orig; version 1.16.1 already exists in repository. Pulling from "/home/jamessan/Code/Debian/debdarcs/fish.upstream"... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-debil Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages darcs-buildpackage depends on: ii darcs 1.0.3-2an advanced revision control syste ii darcs-load-dirs 1.0.28 Import upstream archives into darc ii devscripts2.9.8 Scripts to make the life of a Debi ii dpkg-dev 1.13.11package building tools for Debian darcs-buildpackage recommends no packages. -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#336081: [Pbuilder-maint] Bug#336081: pbuilder: pdebuild creates incorrect diff.gz files
On Mon, Oct 31, 2005 at 08:50:10PM +0900, Junichi Uekawa wrote: > > Package: pbuilder > > Version: 0.136 > > Severity: normal > > > > The diff.gz built during a pdebuild run is incorrect as it ends up > > diffing a warning message from dpkg-architecture against each file. > > This causes a later dpkg-source -x to fail since the patch expects every > > file in the diff to start off as a single line file containing the > > warning. I've attached a sample diff.gz as an example. > > What's your command-line ? pdebuild --buildresult .. -- --basetgz /var/cache/pbuilder/sid.tgz > I'm assuming you are using pdebuild-internal, and somehow have > stderr redirected to stdout. This email is the first time I've heard of pdebuild-internal. > Are you using some weird setup for uml or some sort? No, it's just a normal sid pbuilder environment. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpaB3y6ANrey.pgp Description: PGP signature
Bug#336327: dbp-importdsc: Hangs while attempting to pull the latest upstream from .upstream directory
On Sat, Oct 29, 2005 at 10:26:17AM -0500, John Goerzen wrote: > On Sat, Oct 29, 2005 at 10:28:28AM -0400, James Vega wrote: > > Package: darcs-buildpackage > > Version: 0.5.5 > > Severity: important > > > > As the subject says, dbp-importdsc just hangs when trying to pull from > > the latest upstream version from the .upstream local repo. > > Are you absolutely sure this is darcs-buildpackage and not darcs > itself? % ps afx | egrep "darcs|dbp" 17228 pts/14 R+ 0:00 | \_ grep -E darcs|dbp 17217 pts/16 S+ 0:00 \_ dbp-importdsc fish_1.16.1-1.dsc 17226 pts/16 R+ 0:13 \_ darcs pull --set-scripts-executable --no-set-default -a --tags=^UPSTREAM_fish_1\.16\.1$ /home/jamessan/Code/Debian/debdarcs/fish.upstream Looks like it is Darcs. > This sounds like the known darcs bug where if, say, you deleted a file > in your repo that was modified by the patches you are trying to pull, > darcs could spin for days. As far as I recall, I hadn't made any changes to the package repo. "darcs changes" and "darcs whatsnew" don't show any modifications except the normal logs from performing a dbp-importdsc. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgp7atoSzx9uY.pgp Description: PGP signature
Bug#336327: dbp-importdsc: Hangs while attempting to pull the latest upstream from .upstream directory
On Mon, Oct 31, 2005 at 08:16:13AM -0600, John Goerzen wrote: > On Mon, Oct 31, 2005 at 08:03:47AM -0500, James Vega wrote: > > > This sounds like the known darcs bug where if, say, you deleted a file > > > in your repo that was modified by the patches you are trying to pull, > > > darcs could spin for days. > > > > As far as I recall, I hadn't made any changes to the package repo. > > "darcs changes" and "darcs whatsnew" don't show any modifications except > > the normal logs from performing a dbp-importdsc. > > Can you make your repositories available somewhere for us to examine? darcs get http://jamessan.com/~jamessan/fish/fish/ darcs get http://jamessan.com/~jamessan/fish/fish.upstream/ The dsc, diff.gz, and orig.tar.gz are also in the top-level fish directory. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpKN3lGppvOC.pgp Description: PGP signature
Bug#336081: [Pbuilder-maint] Bug#336081: pbuilder: pdebuild creates incorrect diff.gz files
On Tue, Nov 01, 2005 at 09:12:51AM +0900, Junichi Uekawa wrote: > > > What's your command-line ? > > > > pdebuild --buildresult .. -- --basetgz /var/cache/pbuilder/sid.tgz > > > > > I'm assuming you are using pdebuild-internal, and somehow have > > > stderr redirected to stdout. > > > > This email is the first time I've heard of pdebuild-internal. > > > > > Are you using some weird setup for uml or some sort? > > > > No, it's just a normal sid pbuilder environment. > > I cannot reproduce your problem here. > Other questions: > > Do you happen to have dpkg-cross inside your pbuilder chroot? Not unless it's part of a standard buildd variant. > Are you running pdebuild inside a pbuilder session? No. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpSKJKNJVWWv.pgp Description: PGP signature
Bug#337344: aptitude: First character after bullet item in long description is ignored
Package: aptitude Version: 0.3.5.1-2 Severity: normal Tags: experimental patch As seen when looking at the pkg info page for 'comix', the character immediately after the bullet item character is skipped over. This should instead check whether the character is a space. Attached patch should address the problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3 0.6.42.1exp1 Advanced front-end for dpkg ii libc6 2.3.5-7 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-3GCC support library ii libncursesw55.5-1Shared libraries for terminal hand ii libsigc++-2.0-0c2 2.0.16-1 type-safe Signal Framework for C++ ii libstdc++6 4.0.2-3 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.3.5.1-2 English manual for aptitude, a ter -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> --- desc_parse.cc 2005-10-05 02:55:21.0 -0400 +++ desc_parse.cc.new 2005-11-03 19:38:10.0 -0500 @@ -127,7 +127,12 @@ wstring bullet; bullet+=(L"*+-"[level%3]); - start=loc2+2; + loc2++; + while(loc2 signature.asc Description: Digital signature
Bug#336081: [Pbuilder-maint] Bug#336081: pbuilder: pdebuild creates incorrect diff.gz files
On Sun, Nov 13, 2005 at 12:29:09PM +0900, Junichi Uekawa wrote:
> I did investigate but so far no luck.
> Is it still happening?
Yes, it is. I don't think I mentioned this before, but it only happens
with pdebuild. If I use "pbuilder login" and run things inside of that
environment, everything works as expected.
> The message is generated in controllib.pl:
> &warn (sprintf ('no utmp entry available and LOGNAME not defined; using
> uid of process (%d)', $<));
>
> This is a minimal test which does work as expected (i.e. output is given to
> stderr and not to file):
It worked as expected here, too.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
pgpaBlpZBGBMB.pgp
Description: PGP signature
Bug#336081: Clean pbuilder environment
I just tried this with a cleanly created pbuilder environment and the diffs are being properly created. So, it seems that the cause of the problem is in the basetgz that I've been using. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpBdjMD6e9S6.pgp Description: PGP signature
Bug#340172: manpages-dev: strftime(3) refers to an unknown conversion type character
Package: manpages-dev Version: 2.08-1 Severity: normal The manpage lists the following conversion character: %+ The date and time in date(1) format. (TZ) Yet, when trying to compile a simple test program that uses that, I get the following warning: warning: unknown conversion type character ‘+’ in format James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages manpages-dev depends on: ii manpages 2.08-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#314309: Vim does not recognize .plx as perl script
On Wed, Jun 15, 2005 at 07:02:30PM +0200, Nicolas George wrote: > .plx is the author-recommanded extension for perl scripts (see _Programming > Perl, third edition, chapter 30). The syntax highlight system of perl > recognizes .pl files as perl, but not .plx files. It isn't necessary for Vim to define all possible file extensions that may be used for a specific language. The user can tell Vim to recognize less frequently used extensions they come across. :help new-filetype I'll also submit a patch to Bram for recognizing .plx as a Perl file. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#311582: load-dirs-common: TypeError in wc.addTag
Package: load-dirs-common Version: 1.0.22 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A TypeError is raised when calling the addTag method of a wc object (in tla_wc.py). This is from trying to concatenate a list and a string. Attached patch fixes the problem. James - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkKeYvcACgkQDb3UpmEybUAtHwCbBLCCvVRPcXxbSpbAAaKB4G65 MF0AoJN9g1O7atDzbMRLn12jX6YAdBTC =7lDK -END PGP SIGNATURE- diff -ur tla-load-dirs-1.0.22.orig/tla_support/tla_wc.py tla-load-dirs-1.0.22/tla_support/tla_wc.py --- tla-load-dirs-1.0.22.orig/tla_support/tla_wc.py 2005-05-31 12:14:57.0 -0400 +++ tla-load-dirs-1.0.22/tla_support/tla_wc.py 2005-06-01 21:25:16.0 -0400 @@ -68,7 +68,7 @@ raise file = self.slashstrip(file) util.chdircmd(self.wcpath, util.safeexec, tlacmd, - cmd().add + file) + cmd().add.append(file)) def movetag(self, src, dest): if self.verb:
Bug#310019: ITP: fish -- a friendly interactive shell
Package: wnpp Severity: wishlist Owner: James Vega <[EMAIL PROTECTED]> * Package name: fish Version : 1.9.1 Upstream Author : Axel Liljencrantz <[EMAIL PROTECTED]> * URL : http://roo.no-ip.org/fish/ * License : GPL Description : a friendly interactive shell Fish is a shell geared towards interactive use. Its features are focused on user friendliness and discoverability. The language syntax is simple but incompatible with other shell languages. Fish also includes some code which falls under the following licenses: License for wcslcat and wcslcpy fish also contains small amounts of code under the BSD license, namely versions of the two functions strlcat and strlcpy, modified for use with wide character strings. This code is copyrighted by Todd C. Miller. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. License for XSel The XSel command, written and copyrighted by Conrad Parker, is distributed together with fish. It is Copyright (C) 2001 Conrad Parker <[EMAIL PROTECTED]> Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308182: debhelper: 'man dh_desktop' type: "fragements"
Package: debhelper Version: 4.2.35 Severity: minor Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Found a type in '/usr/share/man/man1/dh_desktop.1.gz', see attached patch. James - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-debil-3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages debhelper depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii debconf-utils 1.4.49 debconf utilities ii dpkg-dev 1.10.27Package building tools for Debian ii file 4.12-1 Determines file type using "magic" ii fileutils 5.2.1-2The GNU file management utilities ii html2text 1.3.2a-2 An advanced HTML to text converter ii perl 5.8.4-8Larry Wall's Practical Extraction ii po-debconf0.8.23 manage translated Debconf template - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkJ+QVgACgkQDb3UpmEybUC1lACgnu4DPJYf+qW3Sldw9iRiB9Fk TEsAmwSrp73U6EuKEbjQ+ChraoG09Cbu =B6xL -END PGP SIGNATURE- diff -ur debhelper-4.2.35.old/dh_desktop debhelper-4.2.35/dh_desktop --- debhelper-4.2.35.old/dh_desktop 2004-12-09 14:32:28.0 -0500 +++ debhelper-4.2.35/dh_desktop 2005-05-08 12:31:13.216212768 -0400 @@ -18,7 +18,7 @@ dh_desktop is a debhelper program that registers .desktop files. Currently this program does not handle installation of the files, though it may do so at a later date. It takes care of adding maintainer script -fragements to call F. +fragments to call F. =cut
Bug#319104: xfree86-common is unpurgeable since /etc/init.d/xfree86-common is not removed
Package: xfree86-common Version: 6.8.2.dfsg.1-3 Severity: normal During purge, postrm attempts to run "update-rc.d xfree86-common remove", but that fails due to /etc/init.d/xfree86-common existing. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-debil Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#334375: O: juke -- A curses-based jukebox program
Package: wnpp Severity: normal I intend to orphan the juke package. The package description is: Juke is a simple curses/ ncurses based juke box program for Unix computers. It uses command line based players to play all kinds of music format. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-debil Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334442: vim: hardcopy does not work
tags 334442 + moreinfo unreproducible thanks On Mon, Oct 17, 2005 at 11:55:11PM +0200, Jan Christoph Uhde wrote: > using :ha fails with the following error: > E456: Can't find PostScript resource file "prolog.ps" This file is located at /usr/share/vim/vim64/print/prolog.ps and is installed by vim-common (which vim depends upon). I've just installed vim in an unstable chroot and everything worked as expected. > here is sombody else with the same problem > http://lists.debian.org/debian-user/2003/10/msg05621.html This post is close to two years old. Much has changed since then. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpGnlnagafUj.pgp Description: PGP signature
Bug#326058: piuparts: Incorrect version number reported
Package: piuparts Version: 0.8-1 Severity: minor Piuparts is still reporting that it is at version 0.7 instead of 0.8. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-debil Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages piuparts depends on: ii apt 0.6.39 Advanced front-end for dpkg ii debootstrap 0.3.1.5Bootstrap a basic Debian system ii python2.3.5-3An interactive high-level object-o piuparts recommends no packages. -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#404825: vim: "-b" option does not work
tag 404825 moreinfo thanks On Thu, Dec 28, 2006 at 10:00:15PM +0900, Sugano Yoshihisa(E) wrote: > from vim(1) >-b Binary mode. A few options will be set that makes it >possible to edit a binary or executable file. > > But it does not work. What doesn't work about it? You haven't provided much information for me to see why you think it is not acting as intended. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#403967: no idea
On Mon, Jan 01, 2007 at 11:01:59PM +0100, Willi Mann wrote: > Hi! > > Removing /usr/bin/vim in postinst before dpkg-divert did not help. What > surprises me most is that the diversion is not removed from > /var/.../diversions, so dpkg-divert is either not even called or returns > 0 despite taking no action (otherwise apt-get would interrupt). Yeah, I've been able to reproduce this since your last email. I tried to look into it a little but have been busy with the holidays. I should have some more time to see what's happening now that those are over. Hopefully I'll be able to figure this out soon. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#403967: no idea
On Tue, Jan 02, 2007 at 12:28:08PM +0100, Willi Mann wrote: > > > Yeah, I've been able to reproduce this since your last email. I tried > > to look into it a little but have been busy with the holidays. I should > > have some more time to see what's happening now that those are over. > > Hopefully I'll be able to figure this out soon. > > I think I have the explanation: > (I've added echo's to the postinst script for that and saw that the > dpkg-divert is not called so ->). Yeah, I mean I'll hopefully be able to resolve the issue soon. :) James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#405497: /usr/sbin/cowbuilder: Update with --override-config and --mirror leaves behind build directory
Package: cowdancer Version: 0.25 Severity: normal File: /usr/sbin/cowbuilder "cowbuilder --update --override-config --mirror $mirror" fails as expected (since --distribution isn't specified) but it then fails to cleanup the build directory. Both the /proc and /dev/pts bind mounts are left in tact preventing the removal of the build directory. James -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cowdancer depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries Versions of packages cowdancer recommends: ii pbuilder 0.162 personal package builder for Debia -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401000: vim: Vim not handling .gz files anymore
On Tue, Dec 05, 2006 at 09:23:43AM -0500, James Vega wrote: > On Mon, Dec 04, 2006 at 04:31:18PM -0500, James Vega wrote: > > Ah, you're right. The /usr/bin/vim binary you have is probably a > > version of Vim 6.3 so it'll be looking for /usr/share/vim/vim63. The > > URL you posted in a previous email isn't working, but I'll give try a > > stable -> etch upgrade in the next couple days and see if I can > > reproduce your problem. > > Ok, after taking a look at this, sarge -> etch upgrades work fine. It > seems like your series of updates happened to include our initial switch > to alternatives (1:6.4-001+1) which had some problems cleaning up the > old diversions. I'll setup another sandbox and try upgrading from sarge > to that version and see what goes wrong from there to the current > version in etch. I just tried upgrading from sarge -> 1:6.4-001+2 -> 1:6.4-006+2 -> 1:7.0-122+1 which seems to follow what your logs show. I'm not sure what version you upgraded to 1:6.4-001+2 from but I was unable to reproduce this bug with that series of upgrades. I'm running out of options for reproducing this to debug what went wrong but hopefully my previous emails gave you the information you need to fix your setup. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#402691: vim.full refuses to turn syntax highlighting off
tag 402691 unreproducible moreinfo thanks On Mon, Dec 11, 2006 at 11:21:00PM -0500, Brad Barnett wrote: > For some reason, syntax highlighting is now on by default with vim. That's not the case as evidenced by the lack of syntax highlighting when starting Vim as "vim -u /etc/vim/vimrc -N". > Fair enough, perhaps enough people prefer it... > > However, I am unable to turn off syntax highlighting at all. Editing > /etc/vim/vimrc, and uncommenting: > > "syntax on > > and changing it to: > > syntax off > > does not work. Further, ":syntax off" inside of vim does not work either. It works fine for me. Can you try reproducing this via the above suggested command line? If that works as expected, the problem is likely in your ~/.vimrc or ~/.vim/. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#403967: sarge->etc: ended up with /usr/bin/vim binary from 1.5 years ago
severity 401000 important merge 401000 403967 thanks On Thu, Dec 21, 2006 at 12:12:23AM +0100, Willi Mann wrote: > Important because the behaviour is confusing and the way to resolve it is > by no means on the hand. Maybe even RC as it could it hurt the reputation of > debian as the "Upgrades-Always-Work" distribution. > [snip dpkg -l] > but: > > $ dpkg -S /usr/bin/vim.org > Umleitung durch vim-gtk von: /usr/bin/vim > Umleitung durch vim-gtk zu: /usr/bin/vim.org > $ ls -l /usr/bin/vim > -rwxr-xr-x 1 root root 1411096 2005-07-30 12:45 /usr/bin/vim > > after some guessing I removed vim-gtk, removed vim and installed vim. > Then I got: > > $ ls -l /usr/bin/vim > lrwxrwxrwx 1 root root 21 2006-12-20 23:56 /usr/bin/vim -> > /etc/alternatives/vim > > and vim works as before. I guess there's something wrong with the > alternatives handling. > > I have a typescript from my apt-get dist-upgrade run. I could look for > relevant output of the vim upgrade if you like. I've attempted to reproduce this (as noted in #401000) but haven't had much luck. I can take another look at this after the holidays. Maybe your log will point out something that I missed before. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#391641: hwinfo detects wrong monitor modes when machine is booted with usplash
On Sat, Oct 07, 2006 at 08:00:35PM +0200, Ronny Aasen wrote: > Background information: > I am testing network bootable machines using the ltsp package from sid. > Part of the ltsp client uses xdebconfigurator to automaticaly detect a > X11 configuration during boot. xdebconfigurator uses hwinfo to detect > monitor modes. > The problem is that hwinfo --monitor detects wrong monitor settings > when usplash is enabeled. > when usplash it not enabeled, it gives no output at all. Something that > is much better then wrong output. I just uploaded a new version (13.11-3) which had some changes regarding monitor detection. Could you give that a try to see if it works any better? I'm working on getting my laptop setup with usplash to see if I can reproduce the problem in case the new version is still buggy. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Wed, Nov 29, 2006 at 04:59:45PM -0800, Peter Eckersley wrote:
> After a recent upgrade (to version 7+), vim on my system stopped decompressing
> .gz files automatically. This looks a bit like #348661.
>
> vim.{full,gnome,gtk,basic} all handle the .gz files correctly. It
> looks like /usr/bin/vim is some weird file that's been left lying
> around...
>
> I have dpkg 1.3.22.
Could you tell us which version you were upgrading from? We haven't
used diversions for vim in a long time.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#401488: FTBFS: Aap: Recipe file "/tmp/vsf/vim-spellfiles-20060604/upstream/vim-runtime-spell/af/main.aap" not found
On Sun, Dec 03, 2006 at 08:59:51PM -0500, Anthony DeRobertis wrote: > Package: vim-spellfiles > Version: 20060604-1 > Severity: serious > Justification: fails to build from source Thanks for filing this bug as it reminds me I need to take a look at vim-spellfiles again. The original pacakge was uploaded mainly as proof of concept and so people could try out the package, but it was known there were problems with the build process (hence uploading to experimental). Last time I tried, my computer couldn't handle building the actual spellfiles so I haven't had a chance to try cleaning up the build. I try to take a look at things again and get the build running (if my computer can handle it now). James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#400771: vim-gtk loops in syntax_start()
On Tue, Nov 28, 2006 at 05:27:15PM +0100, Carlo Wood wrote: > vim uses 100% cpu while scrolling up (starting in a given state) > the attached file. > > How to reproduce: > [snipped] Thanks for the detailed steps to reproduce and debugging, unfortunately I'm unable to reproduce the bug in unstable or testing. Are you able to reproduce this if you start vim as "vim -u /etc/vim/vimrc -N", ":syntax on" and then follow the steps you listed? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Wed, Nov 29, 2006 at 04:59:45PM -0800, Peter Eckersley wrote: > After a recent upgrade (to version 7+), vim on my system stopped decompressing > .gz files automatically. This looks a bit like #348661. If this is the same problem as #348661, then you chose not to accept the maintainer version (or perform a merge) of /etc/vim/vimrc when upgrading. Running ":set runtimepath?" in vim will likely have /usr/share/vim/vim64 (or vim63 depending on what you upgraded from) instead of /usr/share/vim/vim70. You'll probably also have an /etc/vim/vimrc.dpkg-new or .dpkg-dist which is the newer maintainer version of the file. Also, you can check /var/log/dpkg.log to see from which version you upgraded. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#379839: vim: Bogus color schema
On Mon, Dec 04, 2006 at 01:40:59PM +0100, Jens Seidel wrote: > On Tue, Jul 25, 2006 at 09:50:24PM +0200, Jens Seidel wrote: > > Hi, I noticed that the default color schema of vimdiff is wrong, since > > added lines in one of the files are not visible because foreground and > > background color are identical. > > Since these stupid color schemes make vimdiff nearly unusable I increase > the severity of this bug to normal. Please try to fix it for Etch. > > Maybe you can just reuse the old files? Manual setting :colorscheme has > no positive effect. All styles (not only the default one) are unusable! This depends on the colorscheme. The default colorscheme does make Comment that are part of a DiffAdd hard to read. Although, in my case it was because the 'background' option was set to 'light' when I had a dark background on my terminal. Setting 'background' to 'dark' fixed the problem. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Mon, Dec 04, 2006 at 01:01:29PM -0800, Peter Eckersley wrote: > On 04/12/06, James Vega <[EMAIL PROTECTED]> wrote: > > > > > >That's odd because the first thing /etc/vim/vimrc does is to source > >/usr/share/vim/vim70/debian.vim and that sets the proper 'runtimepath'. > >Do you not have a /usr/share/vim/vim70/debian.vim? > > > Well yes /etc/vim/vimrc runs > runtime! debian.vim > > and I have a file > /usr/share/vim/vim70/debian.vim > that would set rtp correctly > > but I don't think the vim binary knows to look in /usr/share/vim/vim70 for > debian.vim Ah, you're right. The /usr/bin/vim binary you have is probably a version of Vim 6.3 so it'll be looking for /usr/share/vim/vim63. The URL you posted in a previous email isn't working, but I'll give try a stable -> etch upgrade in the next couple days and see if I can reproduce your problem. To get your setup in working order, you should be able to simply "dpkg-divert --remove /usr/bin/vim" and re-install your vim binary packages (vim, vim-gtk, vim-gnome, vim-full) to setup the alternatives. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Mon, Dec 04, 2006 at 12:08:07PM -0800, Peter Eckersley wrote: > On 04/12/06, James Vega <[EMAIL PROTECTED]> wrote: > > > >On Wed, Nov 29, 2006 at 04:59:45PM -0800, Peter Eckersley wrote: > >> After a recent upgrade (to version 7+), vim on my system stopped > >decompressing > >> .gz files automatically. This looks a bit like #348661. > > > >If this is the same problem as #348661, then you chose not to accept the > >maintainer version (or perform a merge) of /etc/vim/vimrc when > >upgrading. Running ":set runtimepath?" in vim will likely have > >/usr/share/vim/vim64 (or vim63 depending on what you upgraded from) > >instead of /usr/share/vim/vim70. > > You'll probably also have an > >/etc/vim/vimrc.dpkg-new or .dpkg-dist which is the newer maintainer > >version of the file. > > > Nope, it isn't that -- I think I have the latest /etc/vim/vimrc (no -new or > -dist versions, just -old) > > md5sum /etc/vim/vimrc > 080bf1170946fa1c181ba69a74522435 That's the correct md5sum. > My runtime path is pretty weird: > > runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim,/usr/share/vim/vimfiles/after,~/.vim/after > > I guess that's being set by the old binary that's in /usr/bin/vim Or you're setting it in ~/.vimrc. ":verbose set runtimepath" will tell you what is setting the option. Sounds like there's a "set rtp&" or some such in one of your user's vim scripts. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Mon, Dec 04, 2006 at 12:43:27PM -0800, Peter Eckersley wrote: > On 04/12/06, James Vega <[EMAIL PROTECTED]> wrote: > > > > > >> My runtime path is pretty weird: > >> > >> > >runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim,/usr/share/vim/vimfiles/after,~/.vim/after > >> > >> I guess that's being set by the old binary that's in /usr/bin/vim > > > >Or you're setting it in ~/.vimrc. ":verbose set runtimepath" will tell > >you what is setting the option. Sounds like there's a "set rtp&" or > >some such in one of your user's vim scripts. > > > I'd already looked. Nothing in ~/.vimrc (or indeed ~/.??* ), or in > /etc/vim. > > :verbose set runtimepath gives the same output as :set runtimepath , so it > looks like it's coming straight from the binary. That's odd because the first thing /etc/vim/vimrc does is to source /usr/share/vim/vim70/debian.vim and that sets the proper 'runtimepath'. Do you not have a /usr/share/vim/vim70/debian.vim? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#379839: vim: Bogus color schema
tag 379839 wontfix thanks On Mon, Dec 04, 2006 at 11:35:47PM +0100, Jens Seidel wrote: > On Mon, Dec 04, 2006 at 09:03:24AM -0500, James Vega wrote: > > On Mon, Dec 04, 2006 at 01:40:59PM +0100, Jens Seidel wrote: > > > On Tue, Jul 25, 2006 at 09:50:24PM +0200, Jens Seidel wrote: > > > > Hi, I noticed that the default color schema of vimdiff is wrong, since > > > > added lines in one of the files are not visible because foreground and > > > > background color are identical. > > > > This depends on the colorscheme. The default colorscheme does make > > Comment that are part of a DiffAdd hard to read. Although, in my case > > it was because the 'background' option was set to 'light' when I had a > > dark background on my terminal. Setting 'background' to 'dark' fixed > > the problem. > > Indeed, using :set background=dark (in a bright *and* dark terminal) > improves the situation. Please note that I tried all colorschemes also > in an inversed terminal (but without background=dark). > > The contrast is nevertheless bad. Bright blue on blue or pink on red are > not optimal. The older settings where better. I agree that the contrast is bad, but there's only so much you can do with the limited color set available in a terminal. More syntax elements were introduced in vim7 so it's harder to avoid less-than-ideal highlighting scenarios. I'm tagging this as wontfix since there's not much to do about it even though I agree that it can be problematic. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#401000: vim: Vim not handling .gz files anymore
On Mon, Dec 04, 2006 at 04:31:18PM -0500, James Vega wrote: > Ah, you're right. The /usr/bin/vim binary you have is probably a > version of Vim 6.3 so it'll be looking for /usr/share/vim/vim63. The > URL you posted in a previous email isn't working, but I'll give try a > stable -> etch upgrade in the next couple days and see if I can > reproduce your problem. Ok, after taking a look at this, sarge -> etch upgrades work fine. It seems like your series of updates happened to include our initial switch to alternatives (1:6.4-001+1) which had some problems cleaning up the old diversions. I'll setup another sandbox and try upgrading from sarge to that version and see what goes wrong from there to the current version in etch. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#400206: removing package vimacs makes things normal
reassign 400206 vimacs forcemerge 177316 400206 thanks On Tue, Nov 28, 2006 at 09:49:25AM +0100, Konstantin Kletschke wrote: > Today I tried to investigate this in detail. > On every other machine my setup and this particular vim version works > well. > I had vimacs (vimacs_0.95-1.3_all.deb) installed but did nothing with > it. Only removing it solves the issue though. Thanks for digging into the issue and figuring out the problem. > So, in the end this bug should moved to vimacs package as a duplicate to > #177316 extending the issue from finnish/swedidh to german users :-/ Done. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#396705: fish: Major new upstream version 1.22.0
On Thu, Nov 02, 2006 at 12:43:39PM +, Reuben Thomas wrote: > Please package 1.22.0! (I know, it was only released yesterday, this > is just in case you haven't seen it.) It has some important bug and > documentation fixes. Don't worry, I'll get it out soon. :) I want to get some good testing of the config file transition and I need to look into a build problem. Hopefully I'll have it uploaded this weekend. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#396785: vim-scripts: Package does not install all required scripts from source
Package: vim-scripts Version: 7-2 Severity: important Tags: patch The install file does not list the macros and autoload directories. The macros directory isn't that important, but the autoload directory breaks plugins that use autoloaded functions (such as Align). The attached patch adds the necessary lines to debian/install to fix the problem. James -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) vim-scripts depends on no packages. Versions of packages vim-scripts recommends: ii vim 1:7.0-152+1 Vi IMproved - enhanced vi editor ii vim-gnome [gvim] 1:7.0-152+1 Vi IMproved - enhanced vi editor - ii vim-perl [gvim] 1:7.0-152+1 Vi IMproved - enhanced vi editor - ii vim-python [gvim]1:7.0-152+1 Vi IMproved - enhanced vi editor - -- no debconf information install.dpatch Description: application/shellscript
Bug#396705: fish: Major new upstream version 1.22.0
On Thu, Nov 02, 2006 at 09:41:14AM -0500, James Vega wrote: > On Thu, Nov 02, 2006 at 12:43:39PM +, Reuben Thomas wrote: > > Please package 1.22.0! (I know, it was only released yesterday, this > > is just in case you haven't seen it.) It has some important bug and > > documentation fixes. > > Don't worry, I'll get it out soon. :) I want to get some good testing of > the config file transition and I need to look into a build problem. > Hopefully I'll have it uploaded this weekend. I have 1.22.1 ready aside from deciding whether (and how) to patch delete-or-exit.fish so it works with a pre-1.22.X binary and a post-1.22.0 function or just to add a note saying that one has to use the exit command to exit old shells. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#398721: fish: FTBFS: tries to write in $HOME
severity 398721 minor retitle 398721 Re-add upstream's tests as part of build process thanks On Wed, Nov 15, 2006 at 10:53:10AM +0100, Julien Danjou wrote: > Package: fish > Version: 1.22.1-1 > Severity: serious > > This error is triggered because it probably tries to write to user's > $HOME, which does not exists on this buildd. > You should explain to it that it don't want to do this, and use the > build directory as scratch directory. Version 1.22.1-2 was uploaded yesterday as well to work around this problem. The tests are currently disabled and I've talked with upstream. He's working on making fish better behaved when it is unable to write to $HOME. I'm going to downgrade this for now since the package is building and leave it open as a reminder to me to re-add running upstream's test suite in a later upload. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#399024: vim: Upgrade fails because of missing man page directory
On Fri, Nov 17, 2006 at 11:11:50AM -0700, Larry Lade wrote: > Package: vim > Version: 1:7.0-164+1 > Followup-For: Bug #399024 > > > Confirmed. > > This bug appears in packages vim, vim-gnome, and vim-gtk. > > Note this bug also occurs when trying to REMOVE the packages in question. > > --Begin output-- > > Setting up vim (7.0-164+1) ... > update-alternatives: unable to make > /usr/share/man/ru.UTF-8/man1/editor.1.gz.dpkg-tmp a symlink to > /etc/alternatives/editor.ru.UTF-8.1.gz: No such file or directory > dpkg: error processing vim (--configure): > subprocess post-installation script returned error exit status 2 This is interesting since the postinst script for 1:7.0-164+1 doesn't have ru.UTF-8 anywhere in it. I'm guessing this is because the previous versions did and we're only removing alternatives on "prerm remove" not "prerm upgrade". I'll confirm this and should be able to get a new upload which fixes it this weekend. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#399024: vim: Upgrade fails because of missing man page directory
On Fri, Nov 17, 2006 at 02:40:46PM -0500, James Vega wrote: > On Fri, Nov 17, 2006 at 11:11:50AM -0700, Larry Lade wrote: > > Package: vim > > Version: 1:7.0-164+1 > > Followup-For: Bug #399024 > > > > > > Confirmed. > > > > This bug appears in packages vim, vim-gnome, and vim-gtk. > > > > Note this bug also occurs when trying to REMOVE the packages in question. > > > > --Begin output-- > > > > Setting up vim (7.0-164+1) ... > > update-alternatives: unable to make > > /usr/share/man/ru.UTF-8/man1/editor.1.gz.dpkg-tmp a symlink to > > /etc/alternatives/editor.ru.UTF-8.1.gz: No such file or directory > > dpkg: error processing vim (--configure): > > subprocess post-installation script returned error exit status 2 > > This is interesting since the postinst script for 1:7.0-164+1 doesn't > have ru.UTF-8 anywhere in it. I'm guessing this is because the previous > versions did and we're only removing alternatives on "prerm remove" not > "prerm upgrade". I'll confirm this and should be able to get a new > upload which fixes it this weekend. I'm unable to reproduce this problem. I've tried through both an "aptitude upgrade" and "apt-get upgrade" from 1:7.0-158+1 to 1:7.0-164+1. Do you know which version you were upgrading from when this happened? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#399024: vim: Upgrade fails because of missing man page directory
On Sat, Nov 18, 2006 at 02:03:43PM -0700, Larry Lade wrote:
> According to dpkg.log packages vim, vim-common, vim-runtime, vim-tiny,
> vim-gtk, vim-gnome, vim-gui-common from 1:7.0-094+1 to 1:7.0-122+1, to 1:
> 7.0-152+1, to 1:7.0-158+1, to 1:7.0-164+1. The error messages about the
> Russian manpage do not appear in that log. I can attach the log if you think
> it would be useful.
The portion about upgrading to 1:7.0-164+1 may be, but I'm not very
hopeful.
> Synaptic's History tool oddly records no activity on these packages since 26
> October (122 -> 152 upgrade).
>
> I'm starting to suspect this is cruft introduced by some other package some
> time ago. I'm still perplexed where "/usr/share/man/ru.UTF-8/" is coming
> from, since I don't even have such a directory on my filesystem.
Up until 1:7.0-164+1, Vim (vim-common specifically) shipped man pages in
that directory. Every vim variant also setup alternatives links in the
various man page directories. In 1:7.0-164+1, we stopped shipping man
pages in /usr/share/man/ru.{UTF-8,KOI8-R}/man1 and moved the KOI8-R man
pages to /usr/share/man/ru/man1 based on another bug report that had
been filed against Vim a while ago.
What I suspected was happening was that when we setup the alternatives in
vim-$variant's postinst, it had problems with the ru.KOI8-R and ru.UTF-8
no longer being shipped. That doesn't seem to be the case though, at
least when I perform an upgrade. I'll try it in a fresh chroot later to
see if something about my normal environment is making things work when
they shouldn't. Otherwise, I'm at a loss as to why it's working for me
and not for other people.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#409981: bzr-builddeb: builddir is named using full version instead of upstream version
Package: bzr-builddeb Version: 0.14 Severity: normal When exporting the directory to perform a build, bzr-builddeb uses incorrect version information for non-native packages. For example, attempting to build fish 1-22.2-1 should create the directory fish-1.22.2. Instead, it creates fish-1.22.2-1 which causes issues with dpkg-source: dpkg-source -b fish-1.22.2-1 dpkg-source: warning: source directory `./fish-1.22.2-1' is not - `fish-1.22.2' dpkg-source: warning: .orig directory name fish-1.22.2-1.orig is not - (wanted fish-1.22.2.orig) James -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages bzr-builddeb depends on: ii bzr 0.14-1 bazaar-ng, the next-generation dis ii dpkg-dev 1.13.25package building tools for Debian ii fakeroot 1.5.12 Gives a fake root environment ii python2.4.4-2An interactive high-level object-o ii python-central0.5.12 register and build utility for Pyt ii python-deb822 0.2Read and manipulate RFC822-like fi ii python-debian 0.1.1 python modules to work with Debian bzr-builddeb recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412462: Acknowledgement (hwinfo locks up whole system at stage: > parallel.5: ppa mod)
severity 412462 important thanks On Sun, Mar 04, 2007 at 10:05:24PM +0100, Pieter Roodnat wrote: > Hello Debian BTS administrator(s), BTS admins don't generally monitor package bugs as far as I know. You could contact them at <[EMAIL PROTECTED]>. > I have two questions about the bug report that filed (reply attached below): > > 1. Is it really necessary to make my private e-mail public? > I have not been warned or asked for that and would have chosen not to file > the bug if I was. All bug reports are posted publically on the bug tracking system so that others know the state of the packages they're installing as well as being able to help triage bugs. I'm curious as to why you wouldn't have filed the bug had you known it would be publically archived. There is no sensitive information in your bug report and not reporting it prevents a possible bug in the software from being fixed. > 2. I used the example on http://www.debian.org/Bugs/Reporting as template > for my e-mail. > As the example, my mail did not contain "severity: ...", but I now wonder if > it should have, since others seem to have it. > Because simply starting the application of the package leads to a full > system crash I think a severity of "Serious" would be appropriate. It's possible to adjust the serverity after the fact (as I've done with this email), so it's not necessarily a problem that it wasn't set during the initial bug filing. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#412637: RFA: hwinfo -- Hardware identification system
On Mon, Mar 05, 2007 at 05:24:52PM +0100, Michelle Konzack wrote: > Hello James, > > I like to adopt this Package if it not already taken... It is still up for adoption. > How dificult/easy is it to maintain? The packaging is fairly simple. The main reason I'm giving it up is simply lack of time for Debian and this is the package I maintain which interests me the least. As for the upstream code, knowledge of C and possibly some assembly (e.g., #412713 is a problem with some assembly on s390) would be needed. It would also be useful to have a variety of hardware to test hwinfo's reports. It's also worth noting that hwinfo is developed for SuSE which specifically patches their kernel to include some code which was dropped from the official Linux kernel some time ago. This is the reason for the kbd.c-tiocgdev_undefined patch in the Debian packaging. I'm not sure if there are other kernel patches SuSE uses which may cause further problems down the line. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#368175: Seems like the problem's still there
On Fri, Mar 23, 2007 at 05:36:54PM +0100, Durk Strooisma wrote: > Hi, > > Yesterday I upgraded my etch install. The vim packages got upgraded from > version 7.0-122+1 to 1:7.0-122+1etch2. > > Unfortunately I lost my manual settings. Before the upgrade the editor > alternative was forced to /usr/bin/vim.basic, but after the upgrade the > alternative was set to auto (which implies nano). To prove: This is specifically related to an upgrade from a package that had multiple encodings of the Russian manpages to one that had a single encoding for the Russian manpages (see #408753). I'm not sure of a way around this but it is probably something that should be looked into in case we end up making a similar transition with some other translation of the manpages. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#354047: /etc/email-addresses?
tag 354047 wontfix thanks On Sun, Mar 05, 2006 at 11:37:57AM +0100, Bas Wijnen wrote: > So I change this feature request into: Please make dch throw out a warning > when that fallback is used. Something like: > > Guessing your e-mail address. This is probably wrong. Please set the > DEBEMAIL and DEBFULLNAME environment variables. > > Anyone using dch should know how to set variables, or read a man page, so it > doesn't have to be too verbose, I think. This is exactly the reasoning I think we don't need to emit such a warning. If the script can guess correctly, then it's not a big deal. If the script doesn't guess correctly, the user should be able to check the dch manpage and see that exporting DEBEMAIL fixes the issue. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#416827: bts: doesn't pay attention to usertags commands
On Fri, Mar 30, 2007 at 05:16:25PM +0100, Julian Gilbey wrote: > Or should we modify bts to use $DEBEMAIL or $EMAIL as the default user > if none is specified? I think in the case of bts, where you don't see the message before it's sent, we should require an explicit email address. Users can always create a shell alias/script if they frequently use bts usertags with a specific email address. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#416827: bts: doesn't pay attention to usertags commands
On Fri, Mar 30, 2007 at 07:26:08PM +0100, Adam D. Barratt wrote: > On Fri, 2007-03-30 at 14:05 -0400, James Vega wrote: > > On Fri, Mar 30, 2007 at 05:16:25PM +0100, Julian Gilbey wrote: > > > Or should we modify bts to use $DEBEMAIL or $EMAIL as the default user > > > if none is specified? > > > > I think in the case of bts, where you don't see the message before it's > > sent, we should require an explicit email address. Users can always > > create a shell alias/script if they frequently use bts usertags with a > > specific email address. > > We already fallback to $DEBEMAIL and $EMAIL for subscribe and > unsubscribe, and $DEBMAIL and $USER for the new claim / unclaim, fwiw. Yeah, I read the question as whether or not to guess what the email was a la debchange instead of just falling back to environment variables the user has to set. Using $DEBEMAIL or $EMAIL seems fine. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#412514: linux-patch-exec-shield should depend on dctrl-tools
Package: linux-patch-exec-shield Version: 1:2.6.20-1 Severity: minor This package currently depends on grep-dctrl which is simply a dummy package to help people transition from Sarge to Etch. The actual package is dctrl-tools. James -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-patch-exec-shield depends on: ii bash 3.1dfsg-8 The GNU Bourne Again SHell ii grep-dctrl2.9.3 Grep Debian package information - ii patch 2.5.9-4Apply a diff file to an original linux-patch-exec-shield recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392464: linux-patch-exec-shield: exec-shield patch is out of sync again
Package: linux-patch-exec-shield Version: 1:2.6.20-1 Followup-For: Bug #392464 This patch is failing with the current 2.6.18 kernel on mm/mprotect.c. The last two hunks for this file fail. It looks like there's a new version on Ingo's site that fixes this. James -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-patch-exec-shield depends on: ii bash 3.1dfsg-8 The GNU Bourne Again SHell ii grep-dctrl2.9.3 Grep Debian package information - ii patch 2.5.9-4Apply a diff file to an original linux-patch-exec-shield recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412637: RFA: hwinfo -- Hardware identification system
Package: wnpp Severity: normal I request an adopter for the hwinfo package. I have neither the time nor the resources to properly test and maintain this package. The package description is: hwinfo is the hardware detection tool used in SuSE Linux. . In Debian-Edu (Skolelinux) hwinfo has shown better results than discover when detecting mouse, keyboard and monitor. . hwinfo collects information about the hardware installed on a system. Among others, libhd contains information about cdrom, zip, floppy, disks and partitions, network card, graphics card, monitor, camera, mouse, sound, pppoe, isdn, modem, printer, scanner, bios, cpu, usb, memory and smp. . This package does not include the binaries hwscan, hwscand and hwscanqueue. If you think one or more of these should be included in the package, please contact the maintainer at [EMAIL PROTECTED] -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413674: fails to attach/find old screens after update
On Tue, Mar 06, 2007 at 03:06:41PM -0800, Steve Langasek wrote: > I can confirm this bug; I can further confirm that the problem is specific > to the i386 build of 4.0.3-0.3, and that a rebuild of the package in my > environment fixes the problem. This bug was reported last September (#387156) with a patch that at least fixed the problem when I attempted to build screen. Never saw a response from the maintainer though. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#397354: debian/watch file and berlios
On Mon, Mar 19, 2007 at 11:41:56PM -0400, Yaroslav Halchenko wrote:
> I am sorry if I am trying to wake up a dead issue, but
>
> On Thu, 23 Nov 2006, Julian Gilbey wrote:
> > On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote:
> > > I think there are 2 problems:
> > > - Berlios apparently rejects based on User-Agent.
> > Fixed in 2.9.24, I believe.
>
> Indeed there is a changelog entry:
> * uscan: set HTTP user agent name (Closes: #397354)
>
> and current 2.9.27 version of uscan has:
>
> $user_agent->agent('Debian uscan 2.9.27');
>
> and my uscan fails with:
>
> ,---
> | -- In debian/watch, processing watchfile line:
> |opts=downloadurlmangle=s/prdownload/download/
> http://developer.berlios.de/project/showfiles.php?group_id=7729
> http://prdownload.berlios.de/keyjnotegui/keyjnotegui-(.*).tar.bz2
> | uscan warning: In watchfile debian/watch, reading webpage
> | http://developer.berlios.de/project/showfiles.php?group_id=7729 failed:
> 403 Forbidden
> `---
>
> so imho issue persists since berlios seems to don't allow uscan as the
> agent effectively bringing #397354 back alive:
Has anyone tried contacting people at Berlios to see if they would be
averse to allowing devscripts to connect?
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#136455: wrong Perl here-document highlighting
tags 136455 wontfix thanks On Tue, Mar 13, 2007 at 11:29:07PM +0100, Nick Hibma wrote: > > Due to the 'auto-extending nature' of regions this is impossible to fix. > Of course, if someone proves me wrong with a reasonably simple solution, > I will include it, but unless that happens, it won't be fixed. Thanks for clarifying the situation. I had the same impression when I took a look at providing a patch. I'll go ahead and mark the bug accordingly. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#407364: issue editing Gujarati unicode characters
On Wed, Jan 17, 2007 at 05:01:22PM -0500, Joey Hess wrote: > If I edit the attached gu.po, No attachment. > go to a line containing Gujarati, and go > to the end of the line, the cursor doesn't end up beyond the last > character, but somewhere in the middle of the line as displayed. I thought I remembered hearing about some work done with multibyte display on the vim-dev list. I'll give this a better look over after clearing up the current issues wrt Etch. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#418411: reportbug: urwid interface dies if user selects 'Cancel' at tag selection screen
Package: reportbug
Version: 3.35
Severity: normal
The urwid interface dies with the following traceback if the user
selects 'Cancel' from the tag (i10n, patch, etc) selection screen.
Traceback (most recent call last):
File "/usr/bin/reportbug", line 1750, in ?
main()
File "/usr/bin/reportbug", line 783, in main
return iface.user_interface()
File "/usr/bin/reportbug", line 1594, in user_interface
patch = ('patch' in taglist)
TypeError: iterable argument required
James
-- Package-specific info:
** Environment settings:
DEBEMAIL="[EMAIL PROTECTED]"
DEBFULLNAME="James Vega"
INTERFACE="text"
** /home/jamessan/.reportbugrc:
reportbug_version "3.17"
mode standard
ui text
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (499, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-debil-2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages reportbug depends on:
ii apt 0.6.46.4-0.1 Advanced front-end for dpkg
ii python 2.4.4-2 An interactive high-level object-o
ii python-central 0.5.13-0.1 register and build utility for Pyt
reportbug recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420029: vim-addon-manager: vim-addons does not handle unrecognized options gracefully
Package: vim-addon-manager Version: 0.1 Severity: normal Using unrecognized options causes vim-addons to quit with a backtrace instead of informing the user how vim-addons can be invoked. [EMAIL PROTECTED]:0 /t/svnside % vim-addons --list /usr/bin/vim-addons: unrecognized option `--list' /usr/lib/ruby/1.8/getoptlong.rb:403:in `set_error': unrecognized option `--list' (GetoptLong::InvalidOption) from /usr/lib/ruby/1.8/getoptlong.rb:510:in `get_option' from /usr/lib/ruby/1.8/getoptlong.rb:611:in `each' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `loop' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `each' from /usr/bin/vim-addons:180:in `parse_cmdline' from /usr/bin/vim-addons:205 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-debil-2 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim-addon-manager depends on: ii ruby 1.8.2-1An interpreter of object-oriented Versions of packages vim-addon-manager recommends: ii vim 1:7.0-219+1 Vi IMproved - enhanced vi editor ii vim-full [gvim] 1:7.0-219+1 Vi IMproved - enhanced vi editor - ii vim-gtk [gvim] 1:7.0-219+1 Vi IMproved - enhanced vi editor - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378721: vim-lesstif: gvim always crashes during startup
unblock 378721 by 379011 thanks On Sun, Aug 27, 2006 at 03:41:35AM +0100, Ben Hutchings wrote: > XmEnhancedButton doesn't initially have an XmPrimitiveClassExtRec of its > own (primitive_class.extension is NULL) so I'm not sure how it gets one. > Using a copy of the record from XmPushButton works around the bug in > vim: Thanks for the patch. I'm currently building Vim to verify the fix. If that's successful, we'll probably upload in the next couple days. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#384019: manual-copyright clarification
On Mon, Aug 28, 2006 at 11:25:00PM +0200, Bram Moolenaar wrote: > > * The debian-legal as determined it as non DFSG-free (see > > > > http://wiki.debian.org/DFSGLicenses#head-add2e754f3a906f07e4ff1c050a2548f04ef4cbe) > > Debian people tend to spend more time on splitting hairs than others. For what it's worth, the debian-legal summary doesn't appear to be very solid. As suggested by Anthony Towns[1], I've asked Joerg to take a look at the license/bug report and give his opinion. > > While I think (but this is a personal opinion) that the minor points > > could be ignored for inclusion of the vim documentation in the debian > > distribution, I don't think the latter aspect could be. We would > > probably be forced to remove the vim documentation from the debian > > distribution, moving it to non-free :-((( > > I think that's your problem. Requiring authors to use exactly the > license you approve of is actually close to dictatorial behavior. > Please consider losing the rules a bit, so that you can actually claim > to have a "free" operating system. We don't require authors to use any license. We like to suggest that they relicense (or dual license if possible) if their current license doesn't meet Debian's Free Software Guidelines[2]. If that isn't acceptable/possible, in many cases (such as this one) we can still provide the documentation to the end user but it requires an extra step on their end. > > Since I don't want that ... while on the Debian side I'm trying to get > > comments from the people responsible of accepting stuff into the archive > > ... on the "Bram" side I would like to know how hard it would be to > > relicense the manual under a different license. > > > > Could you please comment on that? > > In my opinion the docs go under a free license, I don't see a reason to > change it. And I actually can't change it, since I used text from Steve > Oualline's book in the user manual, and that text uses this license. Ideally, a re-examination of the license on Debian's side will determine that it does meet our guidelines. Thank you for taking the time to respond to our questions. James [1] - http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/2006-August/003211.html [2] - http://www.debian.org/social_contract#guidelines -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#384019: Open Publication License DFSG-freeness
Joerg, As mentioned on -devel/-legal[1] recently and seen in #384019, the license[2] of Vim's user/reference manual is one that has previously been suggested to be non-free. Anthony Towns doubted the voracity of those claims[3] and suggested we contact you to provide another opinion on the matter. As stated in the bug, the manual makes no use of the more problematic License Options. Could you provide your take on the matter? Is Vim's manual distributable in main or do we need to move it to non-free? The license URL in Vim's help is incorrect and has been brought to the attention of upstream. The URL in footnote 2 is the correct URL. Thanks, James [1] - http://lists.debian.org/debian-legal/2006/08/msg00134.html [2] - http://www.opencontent.org/openpub/ [3] - http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/2006-August/003211.html -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#388164: java-gcj-compat: Missing manpages for registered alternatives
found 388164 1.0.65-3 thanks On Mon, Sep 18, 2006 at 06:08:46PM -0400, James Vega wrote: > java-gcj-compat attempts to register manpages for jar, java, keytool, > and rmiregistry. Of these, only jar, java, and rmiregistry have > symlinks in $jdkhome (as defined in the postinst) and only the jar.1.gz > symlink actually points to an existing man page. The keytool alternative was removed as noted in the changelog for 1.0.65-3, but the java.1.gz & rmiregistry.1.gz alternatives are still bogus. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#390151: vim-ruby doesn't support cursor arrows in insert mode
tag 390151 + moreinfo unreproducible thanks On Fri, Sep 29, 2006 at 04:00:24PM +0200, Maurizio Lemmo (Tannoiser) wrote: > Hi, > > Since vim7 coming out, seems that the cursor arrows key works strange. I > have no problem in command mode, but in insert mode they spit me out > this chars: > > A for the up key > B for the down key > C for the right key > D for the left key > > instead of moving the cursor. > > I always test this with "vim -u NONE" start command. I tested different > flavor of LANG variables (C, en_US...), but no luck. Invoking vim as "vim -u NONE" will always cause this behavior since Vim is in vi-compatible mode. If you still see the problem when invoking VIm as "vim -u NONE -N", then there is a problem. I was unable to reproduce this using "vim -u NONE -N" with vim-ruby. -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#381125: quilt: buildd messages still exist in manpage
Package: quilt Version: 0.45-4 Followup-For: Bug #381125 The quilt manpage still contains the buildd lines as noted in the original report. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages quilt depends on: ii bzip2 1.0.3-6high-quality block-sorting file co ii diffstat 1.43-1 produces graph of changes introduc ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii gettext 0.15-2 GNU Internationalization utilities ii patch 2.5.9-4Apply a diff file to an original quilt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384019: manual-copyright clarification
Bram, In the manual-copyright help toic, the text states that the user manual and reference manual are licensed under the Open Publication License[0] (which is also referred to in the subsequent frombook topic). The URL[1] listed under manual-copyright points to the Open Content License (which confusingly uses the same OPL acronym as the Open Publication License). Could you clarify which license was the intended license for the user and reference manual? Thanks, James [0] - http://www.opencontent.org/openpub/ [1] - http://www.opencontent.org/opl.shtml -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#384699: aptitude is difficult to read in 256 color terms
Package: aptitude Version: 0.4.2-1 Severity: normal As the attached screenshot shows, the colors aptitude uses in 256 color terminals (xterm-256color and putty-256color are ones I've tried) make it quite difficult to read. This is probably related to the fix put in for #337689. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3. 0.6.45 Advanced front-end for dpkg ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-11 GCC support library ii libncursesw5 5.5-2 Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.16-3type-safe Signal Framework for C++ ii libstdc++6 4.1.1-11The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.2-1English manual for aptitude, a ter -- no debconf information aptitude.png Description: PNG image
Bug#342845: vim-gtk: Inconsistent operation (menu vs. command line) for :close
On Sun, Dec 11, 2005 at 09:10:55AM +0100, Helge Kreutzmann wrote: > The following two sequences behave differently, although they should > not: > > a) echo "Hello" > /tmp/tfile >gvim /tmp/tfile >:close > > a) echo "Hello" > /tmp/tfile >gvim /tmp/tfile >File->Close > > In the first case, an error message is printed: > E444: Cannot close last window > and the file remains in the window. > > In the second case, the window is closed (but not gvim!) as expected, > without any error message. The reason you're seeing the different behavior is because File->Close does more than just :close. It checks to see whether there is more than one window open or not. In your scenario (only one window), it actually performs ":confirm enew" since :close will always fail if there is only one window open (as noted in the help). James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#343492: vim-full: gvim complains on startup about loading configuration info
On Thu, Dec 15, 2005 at 11:39:50AM -0500, James Aspnes wrote: > On starting gvim, I get a gnome-style error popup that says > > An error occurred while loading or saving configuration information for > vim. Some of your configuration settings may not work properly. Are you still able to reproduce this? I tried with the current vim7 packages and did not see this behavior. I'll close this bug in a week or so if I do not hear back from you. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#343118: LANG=pl_PL.UTF-8 vimtutor doesn't guess encoding correctly
On Mon, Dec 12, 2005 at 09:44:58PM +, Colin Watson wrote: > In the pl_PL.UTF-8 locale, vimtutor displays corrupted text. This is > because it attempts to load tutor.pl which is encoded in ISO-8859-2 but > with no encoding declaration in a modeline or anything like that, and > vim's normal encoding fallback tries to interpret it as ISO-8859-1. > > Either a UTF-8 variant of the Polish tutorial needs to be provided, or > the encoding of the document needs to be declared in a modeline or > similar (if possible; my efforts to do this failed). Can you verify whether this is still the case with the vim7 packages? It looks fine to me, but I don't understand Polish. :) James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#361378: does not show german uppercase umlauts correctly (UTF-8)
On Sat, Apr 08, 2006 at 10:23:44AM +, W. Borgert wrote: > Lowercase umlauts are shown correctly: <ä> <ö> <ü>. > Uppercase umlauts and sharp s are not: <Ä> <Ö> <Ü> <ß>. > My .vimrc contains only one line: set encoding=utf-8 > more, less, nano show all umlauts correctly. I tested > on console, xfce4-terminal, and rxvt-unicode-lite. The fact that the lowercase umlauts are being shown correctly is probably just luck. vim-tiny is built without multi-byte support. I'm not sure why we decided to do that? Vim maintainers, was there a specific reason vim-tiny is built without multi-byte support or should we start building vim-tiny with that? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#374853: Error message related to menu.vim when runing vim-gtk
tag 374853 moreinfo unreproducible thanks On Wed, Jun 21, 2006 at 08:19:08PM +0200, Nicolas wrote: > Since a few weeks, I got an error message when running vim-gtk. The > message is displayed in a window. Here is its contents : > Error deteced while processing /usr/share/vim/vim70/menu.vim: > line 150: > E121: Undefined variable: paste#paste_cmd > E15: Invalid expression: 'vnoremenu
Bug#375721: vim can't handle file://
tag 375721 unreproducible moreinfo thanks On Wed, Jun 28, 2006 at 03:01:28AM +0800, LI Daobing wrote: > Hello, > > when I run 'vim file://etc/bash.bashrc', I got an error message[1]. > > This cause thunar can't open file with gvim[2][3]. > > [1] > Error detected while processing BufReadCmd Auto commands for "file://*": > E37: No write since last change (add ! to override) > Press ENTER or type command to continue Can you still reproduce this? This works fine for me. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#375400: vim: error message when editing .muttngrc
tags 375400 unreproducible moreinfo thanks On Sun, Jun 25, 2006 at 08:45:25PM +0200, Wolf Wiegand wrote: > Hi, > > when trying to edit .muttngrc, I get the following error message: > > ".muttngrc" 262L, 8193C > --- Syntax items --- > Error detected while processing /usr/share/vim/vim70/syntax/muttrc.vim: > line 152: > E28: No such highlight group name: ~ keyword muttrcVarBool^Icontained > invcrypt_use_gpgme invdelete_ untag invdigest_collapse invduplicate_threads > Keywordxxx links to Statement > muttrcVarBool xxx contained invcollapse_unread markers noreverse_name > envelope_from nopipe_split >contained invbeep pipe_decode metoo noresolve meta_key > nossl_use_tlsv1 > [many more 'contained ...' lines snipped] > E28: No such highlight group name: contained invcrypt_use_gpgme > invdelete_untag invdigest_collapse > invduplicate_threads > E28: No such highlight group name: invcrypt_use_gpgme invdelete_untag > invdigest_collapse invduplicate_threads > E28: No such highlight group name: invdelete_untag invdigest_collapse > invduplicate_threads > E28: No such highlight group name: invdigest_collapse invduplicate_threads > E28: No such highlight group name: invduplicate_threads > > After confirming this message with ENTER, the file can be edited. Please > contact me if you need the .muttngrc-file as well. Are you still experiencing these problems? If so, check whether you have a stale /etc/vim/vimrc or /etv/vim/gvimrc. There would likely be a vimrc.dpkg-new or vimrc.dpkg-dist (same with gvimrc) in /etc/vim. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#375721: vim can't handle file://
On Mon, Oct 09, 2006 at 08:53:55AM +0800, LI Daobing wrote: > On 10/9/06, James Vega <[EMAIL PROTECTED]> wrote: > >On Wed, Jun 28, 2006 at 03:01:28AM +0800, LI Daobing wrote: > >> Hello, > >> > >> when I run 'vim file://etc/bash.bashrc', I got an error message[1]. > >> > >> This cause thunar can't open file with gvim[2][3]. > >> > >> [1] > >> Error detected while processing BufReadCmd Auto commands for "file://*": > >> E37: No write since last change (add ! to override) > >> Press ENTER or type command to continue > > > >Can you still reproduce this? This works fine for me. > > > Yes I still can reproduce this 'vim -u /etc/vim/vimrc file:///etc/bash.bashrc' works here. If that works and normal 'vim file:///etc/bash.bashrc' doesn't, it's likely a problem in your ~/.vimrc or ~/.vim/*. If that doesn't work, could you purge and reinstall your vim packages to ensure the system-wide config files are in their correct state? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#388342: fish: implicit pointer conversions
On Tue, Sep 19, 2006 at 06:39:58PM -0600, dann frazier wrote: > Our automated buildd log filter[1] detected a problem that will cause > your package to segfault on architectures where the size of a pointer > is greater than the size of an integer, such as ia64 and amd64. > > fish is built with the -c99 compiler flag, which conflicts with the > use of the strdup() definition in string.h. The easiest fix here is > probably to remove that compiler flag. Fish uses features that are specific to c99 which is why upstream uses the -std=c99 compiler flag. I've been unable to reproduce this build failure on ia64/amd64 systems I have access to (merulo and pergolesi). I've nudged upstream to see what his preferred solution would be. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#388342: fish: implicit pointer conversions
On Mon, Oct 09, 2006 at 01:13:23PM -0600, dann frazier wrote: > On Mon, Oct 09, 2006 at 11:08:11AM -0400, James Vega wrote: > > Fish uses features that are specific to c99 which is why upstream uses > > the -std=c99 compiler flag. I've been unable to reproduce this build > > failure on ia64/amd64 systems I have access to (merulo and > > pergolesi). > > To be clear, this isn't a *build* failure, its a build warning that > will result in a runtime failure (segfault). Yeah, I understand that. I've mistyped that a couple of times recently. :) The build process runs a testsuite though that runs fish. On the buildd (caballero) the testsuite does segfault but I can't reproduce the segfault on the other machines I have access to. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#392044: cmake: Unnecessary Recommends on emacs*
Package: cmake Version: 2.4.3-1 Severity: normal Currently cmake Recommends having some variant of emacs installed. It appears that this Recommends is solely because an emacs cmake mode is installed. This use of Recommends is overkill considering that tools like aptitude normally auto-install recommended packages. I'd even be wary of having cmake Suggest emacs since there's really no tie between the two packages. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386035: RFA: hwinfo -- Hardware identification system
retitle 386035 ITA: hwinfo -- Hardware identification system owner 386035 ! thanks On Mon, Sep 04, 2006 at 10:07:44PM +0200, Morten Werner Olsen wrote: > Due to lack of time and C-programming skills, I guess it would be best > if someone with both could adopt the hwinfo package. I could always step > in as co-maintainer, but hwinfo stronly needs someone with more C skills > than me. :) I'd be glad to co-maintain the package with you. I've been working on packaging the latest upstream release. Should have it ready in the next couple days, time permitting. > I consider hwinfo to be in rather good shape, with one bug that I'm not > able to find myself: #381387: hwinfo --pci under ISDN Adapter invasion. The latest upstream fixes this. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#386202: New upstream ported to use pilot-link 0.12.x
gnome-pilot-* 2.0.14 has been ported to use pilot-link 0.12.x. Any chance of getting the new upstream uploaded so these two RC bugs can be closed? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#387794: vim-gui-common: bad /usr/share/doc symlink (missing dep?)
On Sat, Sep 16, 2006 at 11:31:51PM +0200, Pierre Habouzit wrote: > you are supposed to pull vim, or one of its variant, that is explicitely > depending on vim-common (for all of them) *AND* from vim-gui-common if > the variant supports gvim. > > so basically, there is no bug. we could maybe add a dep vim-gui-common > on vim-common, but I think I recall there was a problem with that. I'll > try to figure out which one it was... This change happened when I updated the dependencies so the Vim packages are binNMU safe. Since vim-gui-common is arch: all, adding a dependency on vim-common would prevent that. We can just change the packaging so /u/s/d/vim-gui-common is a directory with the same same contents as vim-common (or just the minimum required by policy). James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#320251: Test with new hwinfo version
hwinfo 13.3-2 should be hitting the archives today. Could you test whether that version fixes your bug? I don't have any PCIe hardware to check. Thanks, James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#388164: java-gcj-compat: Missing manpages for registered alternatives
Package: java-gcj-compat Version: 1.0.65-2 Severity: normal java-gcj-compat attempts to register manpages for jar, java, keytool, and rmiregistry. Of these, only jar, java, and rmiregistry have symlinks in $jdkhome (as defined in the postinst) and only the jar.1.gz symlink actually points to an existing man page. The other symlinks point to files that don't exist in any package in the archive. Also, there is a gcj-dbtool.1.gz symlink in $jdkhome which doesn't point to an existing file and isn't referenced by any alternative. James -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-debil-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages java-gcj-compat depends on: ii fastjar 1:4.1.1-13 Jar creation utility ii gij-4.1 4.1.1-13 The GNU Java bytecode interpreter ii java-common 0.25 Base of all Java packages ii libgcj7-jar 4.1.1-13 Java runtime library for use with Versions of packages java-gcj-compat recommends: pn libgcj7-src(no description available) -- no debconf information -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#388488: vim-gnome: gvim complains on startup processing /usr/share/vim/vim70/menu.vim
On Wed, Sep 20, 2006 at 07:31:55PM +0200, Antonio-Miguel Corbi Bellot wrote: > *** Please type your report below this line *** > When starting gvim (either from vim-gnome or from vim-gtk) I get > this > error: > Error detected while processing /usr/share/vim/vim70/menu.vim: > line 150: > E121: Undefined variable: paste#paste_cmd > E15: Invalid expression: 'vnoremenu
Bug#389367: fish: built-in "open" command does not work
retitle 389367 Support searching /usr/share/mime/packages for mime info
severity 389367 wishlist
thanks
On Mon, Sep 25, 2006 at 05:11:20AM -0500, nate moseman wrote:
> Fish is a attempt at a intellegent shell. One of the features that it
> has is the ability to detect the mime types of files and then launch the
> user's prefered application to open that file. It does this with the
> 'open' built-in command. Also there is a tool called 'mimedb' that is
> supplied with the the fish package that you can use to see how files are
> handled by the shell.
>
> To do all this correctly it follows the Freedesktop.org convention of
> the '.desktop' files and their mimetype database. This stuff is
> supported by Debian and should work more-or-less.
Based on my reading of Freedesktop's site, mimedb is behaving as it
should be. If there is no $XDG_DATA_DIRS environment variable, it looks
through /usr{,/local}/share to find the mime type. If it finds the
mime type (as it does in your case), it then looks through
$XDG_DATA_DIRS for an applications/defaults.list file that instructs it
as to which application to use. If that application is found, mimedb
then checks /usr{,/local}/share/applications/$app.desktop (which is
determined from defaults.list) for the Exec= line to see how to invoke
the program.
Where this falls apart is that there is no
/usr{,/local}/share/applications/defaults.list. That seems to be stowed
away under DE-specific directories such as
/usr/share/gnome/applications/defaults.list. At the same time, it
doesn't make sense for Debian to ship
/usr/share/applications/defaults.list because its contents would depend
on what packages are installed.
For the time being, I can propose that upstream improves mimedb to
search $XDG_DATA_DIRS/packages/$package.xml to see if any of those files
advertise being able to edit the given mimetype. If so, then it could
find $package.desktop like normal. It doesn't look like many packages
utilize $XDG_DATA_DIRS/packages though. I currently only have one
application listed there. packages.debian.org only lists 36
applications registered in this manner.
> So I have a plain text file I should be able to go:
> open suchandsuch.txt
>
> But nothing happens.
> With mimedb you can go:
> mimedb suchandsuch.txt
>
> and it will return:
> plain/text
>
> but if you go
> mimedb -a suchandsuch.txt
> (a for action for the open command)
>
> It will return nothing.
>
> To get it to work you have to go in through nautilus and go through the
> right-click preferences dialog and select the program you want to use.
> Then it will work.
It sounds like this is modifying something in $XDG_DATA_DIRS that fish
can see. Maybe another application is setting $XDG_DATA_DIRS to
encompass more than just /usr{,/local}/share.
> What should happen is that it will choose the same generic commands that
> nautilus (or whatever Debian has by default) to open files when you
> double click them. You shouldn't have to select a action manually for
> each file type.
As mentioned above, part of the reason Nautilus knows what to do is
because Gnome has stuff squirrelled away in /usr/share/gnome/.
> How to fix it.. I don't know. You would have to choose actions based on
> desktop environment.
>
> Probably a nice fix would be a command used to assign programs to be
> launched or a error message explaining that it doesn't know and you
> have to assign a action via nautilus or whatnot so your personal
> ..desktop preferences are known. Something like that.
>
> How exactly fish is to know if your running KDE vs Gnome or what to do
> when your running something like Fluxbox or Ion3 I don't know.
This is also something that's been discussed on fdo's mailing lists.
There hasn't been a conclusion yet and the mime work seems to be on hold
for right now.
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#389367: seems be worse of a problem on my other machine.
On Mon, Sep 25, 2006 at 01:50:12PM -0500, linlamer wrote: > That bug report was for powerpc Debian unstable.. > > But on my x86 machine I can't get 'open' command to work at all. Mimedb > correctly identifies the files, but the "mimedb -a filename" completely > fails to return anything even after I select a specific program in nautilus. > > So I guess my problem is just plain buggy behavior with fish. As explained in my previous email, I think this is more a lack of information for fish than fish behaving improperly. > Not sure what is going on. > > Also on unrelated side note when trying to use tab completion if you try > to tab complete on a letter that doesn't have a match it will write out > spurious information to the terminal. > > For instance: > ls z > > and there is no file beginning with z > > if you hit tab then it will look like: > ~> ls z$<100/> I'm unable to reproduce this. If you can still reproduce this after moving ~/.fish and ~/.fish.d out of the way, please open a separate bug report and I'll follow up. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#389598: ITP: xpbiff -- animated mail monitor on X with popup notification
On Tue, Sep 26, 2006 at 07:29:05PM +0200, Gernot Salzer wrote: > Copyright: > > * xpbiff - popup biff for X > * > * Author: Kazuhiko Shutoh, 1993 > * > * Permission to use, copy, modify and distribute without charge this > software, Doesn't the 'without charge' bit violate DFSG #1? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#389367: fish: built-in "open" command does not work
On Tue, Sep 26, 2006 at 08:09:22PM -0500, linlamer wrote:
>
> Ok.. Making a bit more sense to me now.
>
> >It sounds like this is modifying something in $XDG_DATA_DIRS that fish
> >can see. Maybe another application is setting $XDG_DATA_DIRS to
> >encompass more than just /usr{,/local}/share.
>
> There is no XDG_DATA_DIRS set in my shell apparently
>
> echo $XDG_DATA_DIRS
>
> returns nothing.
>
> I think what is happening is that it's looking into
> ~/.local/share/applications
Yes, fish looks at $XDG_HOME_DIR/.local/share. If $XDG_HOME_DIR isn't
set, $HOME is used.
> and finding the defaults.list that is apparently being generated by
> nautilus. When I delete that file then it 'open' stops working.
>
> Also nautilus then 'forgets' my application preference and opens up with
> the default gnome stuff.
>
> Right now I have one defaults.list available on my system. It's located
> in /etc/gnome-vfs-2.0/defaults.list. (and there is a symbolic link
> /usr/share/gnome/applications/defaults.list that points to that location)
>
> But I can't quite figure out how to make XDG_DATA_DIRS to work right.
> I tried:
> set XDG_DATA_DIRS /etc/gnome-vfs-2.0/
> set XDG_DATA_DIRS /etc/gnome-vfs-2.0/defaults.list
> set XDG_DATA_DIRS /usr/share/gnome/applications
> set XDG_DATA_DIRS /usr/share/gnome/
"set -x XDG_DATA_DIRS /usr/share/gnome/" worked fine for me.
XDG_DATA_DIRS should be a : separated list of directories which are
one-level above the applications/ or mime/ directory. Lacking the -x
may have been the problem.
> If I copy /etc/gnome-vfs-2.0/defaults.list to
> ~/.local/share/applications/ then everything works fine. Which suites me
> fine right now.
Good. :) I'll suggest the $XDG_DATA_DIRS/packages check to Axel (with a
patch if I get time) and see what he thinks. I'll close this bug when I
get a response from him on the issue.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#389777: ITP: cruisecontrol -- CruiseControl is a java-based framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source co
On Wed, Sep 27, 2006 at 01:23:18PM -0300, Rodrigo Lemos wrote: > Package: wnpp > Severity: wishlist > Owner: Rodrigo Lemos <[EMAIL PROTECTED]> > > > * Package name: cruisecontrol > Version : 2.5 > Upstream Author : ThoughtWorks, Inc > * URL : http://cruisecontrol.sourceforge.net > * License : BSD-style > Programming Lang: Java > Description : CruiseControl is a java-based framework for a continuous > build process. It includes, but is not limited to, plugins for email > notification, Ant, and various source control tools. A web interface is > provided to view the details of the current and previous builds. The short description should be much shorter. Simply "a java-based framework for a continuous build process" would probably do the job. The rest should be moved into the long description. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#376835: Patch to fix version compare
The attached patch fixed the version compare in print_version to make
use of AptPkg instead of performing a string equality.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
diff -Naur apt-show-versions-0.09.orig/apt-show-versions
apt-show-versions-0.09/apt-show-versions
--- apt-show-versions-0.09.orig/apt-show-versions 2005-07-28
10:19:08.0 -0400
+++ apt-show-versions-0.09/apt-show-versions2006-08-08 09:56:08.0
-0400
@@ -241,7 +241,7 @@
? " upgradeable from $iversion to $aversion\n"
: "\n");
return 1;
-} elsif ((defined $aversion) and ($iversion eq $aversion)) {
+} elsif ((defined $aversion) and ($vs->compare($aversion, $iversion) ==
0)) {
print "$package/$archiv"
. (!defined($opts{'brief'})
? " uptodate $iversion\n"
signature.asc
Description: Digital signature
Bug#337329: block accepts negative bug numbers but handles them incorrectly
As #378721 demonstrates, 'block by' now recognizes negative bug numbers from a previous clone command but it is not correctly interpreting them as the cloned bug. Instead, the bug becomes blocked by bug #-1 (which is an invalid bug number). This cannot be fixed via unblock because -1 is then recognized as not being a valid bug number. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#382541: please add rest2web filetype detection
On Fri, Aug 11, 2006 at 07:14:23PM +0100, martin f krafft wrote: > Please add > > " Rest2web source file > elseif s:line1.s:line2.s:line3.s:line4.s:line5 =~ '^restindex' > set ft=rst > > somewhere into the giant if/elseif construct in scripts.vim As discussed on IRC, we'll model this after the entry for virata instead. I'll add the patch and forward the request to Bram later today. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#383268: xmms2-core: GLib-WARNING when xmms2d is run with no startup.d or shutdown.d directories
Package: xmms2-core
Version: 0.2DrFeelgood-1
Severity: normal
If no startup.d or shutdown.d directories exist (e.g.,
~/.xmms2/{startup,shutdown}.d), the following messages are emitted:
[EMAIL PROTECTED]:0 ~ % xmms2d
INFO: src/xmms/log.c:35: Initialized logging system :)
INFO: src/xmms/main.c:443: Using output plugin: alsa
INFO: src/xmms/main.c:299: Installing scripts from
/usr/share/xmms2/scripts/startup.d
(xmms2d:11720): GLib-WARNING **: GError set over the top of a previous GError
or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Error opening directory
'/usr/share/xmms2/scripts/startup.d': No such file or directory
ERROR: src/xmms/main.c:302: Global script directory not found
INFO: src/xmms/unixsignal.c:54: Got SIGINT!
INFO: src/xmms/main.c:299: Installing scripts from
/usr/share/xmms2/scripts/shutdown.d
(xmms2d:11720): GLib-WARNING **: GError set over the top of a previous GError
or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Error opening directory
'/usr/share/xmms2/scripts/shutdown.d': No such file or directory
ERROR: src/xmms/main.c:302: Global script directory not found
INFO: src/xmms/log.c:42: Logging says bye bye :)
This only happens the first time xmms2d is run, but the messages seem to
indicate it is something that should be looked into.
James
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (499, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-debil-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages xmms2-core depends on:
ii libc62.3.6-19GNU C Library: Shared libraries
ii libglib2.0-0 2.10.3-3The GLib library of C routines
ii libsqlite3-0 3.3.5-0.2+b1SQLite 3 shared library
ii xmms2-plugin-alsa0.2DrFeelgood-1 XMMS2 - ALSA output
xmms2-core recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395413: vim-full: Infinite loop when setting foldnestmax to -1 with foldmethod syntax
On Thu, Oct 26, 2006 at 10:44:33PM +0200, Markus Koller wrote: > Well, the subject pretty much says it all, if you start vim, set foldmethod > to syntax and then set foldnestmax to -1, vim freezes and the CPU goes to > 100%. Happens both in vim and gvim, and is probably related to #367566. #367566 was actually specific to the debchangelog ftplugin and has ben fixed. This problem occurs with any filetype that has syntax-based folding. I'm working on a patch now. Thanks for the report, James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
