Bug#612620: rxvt-unicode-ml: backspace doesn't work in mutt any more
Excerpts from Samuel Thibault's message of Wed Feb 09 10:50:15 -0500 2011: On upgrade from 9.07-2+b1 to 9.09-3, the backspace key stopped working in mutt. Downgrading again makes it work again. I guess that is related with the switch between rxvt-unicode and rxvt-256color, as these are really far appart, actually... 9.09-5 (unstable) should fix this. On upgrade you will be transitioned from rxvt-unicode-ml to rxvt-unicode (same as the old -ml package), if you want to deal with the 256-color mess there is rxvt-unicode-256color. If this does not go smoothly for you please open another bug. (If you know anyone who wants to adopt rxvt-unicode, I'm about to send a message to -devel. I'm not going to touch the other thread.) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564160: 3.2.0
Excerpts from Clint Adams's message of Wed Dec 22 14:53:23 -0500 2010: Is updating to 3.2.0 a better solution? Looks like it. I'll run some tests and see if there's any problematic changes in 3.0.8 (code diff from 3.0.8.1 to 3.2.0 is minimal.) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605951: rxvt-unicode: colors are totally fucked up
Excerpts from Marc Lehmann's message of Thu Dec 09 06:30:03 -0500 2010: The original urxvt uses rxvt-unicode and rxvt-unicode-256color TERM values, respectively, which are the correct values, and portable. By respectively, what are you referring to? as added benefit debian wouldn't be needlessly incompatible to the rest of the world (which uses the correct terminfo files). There is no rxvt-unicode-256color terminfo entry in Debian or the rxvt-unicode distribution that I can see, but (see above) I don't know exactly what you mean here. it would be preferable if debian clearly marked their version of rxvt-unicode as completely incompatible to upstream and other distributions I'm sorry. I don't *want* us to be incompatible, or to break anything. I am trying to deal with a longstanding user request (for something I don't even use), and make it actually possible to use that feature. I really don't know if it's going to work. It may not make it from unstable into a distribution. (or alternatively maybe consider not continuously and deliberately breaking it...) What else do you still consider *deliberately* broken? I would like to address it. (For other issues, it's not necessary to reply to this bug. Comment on another one, flame me privately, whatever.) If debian really insuist on doing their own incompatible patches, This is not our own patch. I am trying to use it because you for whatever reason deemed it worth including (not applied) in the upstream distribution (9.09). it would be far better to rename the package to something like debian-rxvt, and certainly set the TERM values to something like debianurxvt or so, as opposed to introducing more subtle bugs and giving users a chance to install the correct debian-specific terminfo on remote systems. A distro-specific terminfo entry is the last thing I want. Really. Users need to log in to other systems. That is why we are right now, as you say, fucked. (*) debian has a long tradition of non-communication with upstream OK, I think I must be frank here. I'm not going to randomly send stupid questions to an upstream that without fail has been abusive to every rxvt-unicode Debian maintainer that I can remember. Sorry. and deliberate bug-introducing patches, Really, which do you think is the simpler explanation here? - You disagree with us on X, Y, and Z, and people make mistakes - I am the last in a long line of maintainers who have all independently come up with a sinister plot to undermine you by deliberately making our own users unhappy even going as far as removing our request to report bugs in the debian version to debian only from the FAQ section, as we are not responsible for their bugs. This is simply not true. I undid the relevant diff over two years ago. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600973: mpc: No numbers on playlist
Excerpts from Keelan's message of Thu Oct 21 20:36:54 -0400 2010: The mpc version in squeeze 0.19-2 does not have playlist numbers when listing the playlist with mpc playlist You now need to use either %position% or %id% in your format string explicitly. I believe this is intentional on the part of upstream. The problem (as this is a behavior change) is that it is not documented anywhere... I will see if that can be remedied. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Excerpts from Jérémy Lal's message of Sat Aug 21 08:16:08 -0400 2010: Which python version is installed ? 2.6.5-13. it seems you installed nodejs in debian lenny ? No, I'm just using a internet-connected machine to run reportbug. Behind a firewall here and I don't have a solution set up yet for tunneling outgoing email. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Excerpts from Jérémy Lal's message of Sat Aug 21 09:13:04 -0400 2010: i need some more info, because i can't reproduce that bug. Which module were you trying to run nodejs-waf with ? Does the error happens if you run nodejs-waf outside any module tree ? I tried in a checkout of node-sqlite, and got the same error when outside of any module tree. What is the intended way for the node-waf script to add /usr/share/nodejs/wafadmin/ to python's module path? Have you tried using python-support? -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Excerpts from Jérémy Lal's message of Sat Aug 21 13:06:41 -0400 2010: In fact nodejs-waf script adds /usr/share/nodejs/wafadmin and Tools/ to sys.path before importing Scripting module. That might be screwed by setting PREFIX_NODE environment variable. Is that the case for you ? Nope, not set. I took a look at the script, and it is prepending the following to sys.path: ['/usr/bin/../lib/node/wafadmin', '/usr/bin/../lib/node/wafadmin/Tools'] these should have 'share/nodejs', not 'lib/node'. (Maybe you have a manually installed copy still in /usr/lib?) I did not try using python-support, could you point me in the right direction for doing that properly ? See http://wiki.debian.org/Python/Policy . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Excerpts from Jérémy Lal's message of Sat Aug 21 14:31:20 -0400 2010: Nope, i tested on my own i386 laptop and on a amd64 server, same results. This is strange. Are you sure you don't have a /usr/lib/node on these systems? If you step through nodejs-waf up to the import, what do you get in sys.path? Could you test with nodejs 0.2.0 ? I don't see 0.2.0 as being packaged for Debian? At any rate, the script looks the same on master: http://github.com/ry/node/blob/master/bin/node-waf#L8 That line needs to be changed, or else the wafadmin stuff should be installed somewhere in the system path. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Excerpts from Decklin Foster's message of Sat Aug 21 16:44:18 -0400 2010: Sorry, I was going by http://packages.debian.org/search?keywords=nodejs, which as of 20:40 UTC is still not updated. I'm installing 0.2.0 now. OK, this seems to have fixed it. Sorry for the trouble. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593761: nodejs: node-waf fails to start
Package: nodejs Version: 0.1.104-1 Severity: normal $ nodejs-waf Traceback (most recent call last): File /usr/bin/nodejs-waf, line 14, in module import Scripting ImportError: No module named Scripting $ dpkg -S Scripting.py nodejs-dev: /usr/share/nodejs/wafadmin/Scripting.py -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32.16-linode28 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593088: nodejs: New upstream version available
Package: nodejs
Version: 0.1.102
Severity: wishlist
0.1.104 is now available. I have attached the changes I had to make to
get it to build.
-- System Information:
Debian Release: 5.0.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32.16-linode28 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -ur nodejs-0.1.102/debian/changelog nodejs-0.1.104/debian/changelog
--- nodejs-0.1.102/debian/changelog 2010-07-26 02:47:34.0 -0400
+++ nodejs-0.1.104/debian/changelog 2010-08-15 08:21:14.023264152 -0400
@@ -1,3 +1,9 @@
+nodejs (0.1.104-1) unstable; urgency=low
+
+ * New upstream release
+
+ -- Decklin Foster deck...@red-bean.com Sun, 15 Aug 2010 08:21:14 -0400
+
nodejs (0.1.102-1) unstable; urgency=low
* New upstream release
Only in nodejs-0.1.104/debian: files
Only in nodejs-0.1.104/debian: nodejs
Only in nodejs-0.1.104/debian: nodejs-dbg
Only in nodejs-0.1.104/debian: nodejs-dbg.debhelper.log
Only in nodejs-0.1.104/debian: nodejs-dbg.substvars
Only in nodejs-0.1.104/debian: nodejs-dev
Only in nodejs-0.1.104/debian: nodejs-dev.debhelper.log
Only in nodejs-0.1.104/debian: nodejs-dev.substvars
Only in nodejs-0.1.104/debian: nodejs.debhelper.log
Only in nodejs-0.1.104/debian: nodejs.substvars
Only in nodejs-0.1.104/debian/patches: debian-changes-0.1.104-1
diff -ur nodejs-0.1.102/debian/patches/no-v8-debug-lib.patch nodejs-0.1.104/debian/patches/no-v8-debug-lib.patch
--- nodejs-0.1.102/debian/patches/no-v8-debug-lib.patch 2010-07-14 08:40:50.0 -0400
+++ nodejs-0.1.104/debian/patches/no-v8-debug-lib.patch 2010-08-15 08:21:22.378312467 -0400
@@ -4,9 +4,11 @@
Author: Jérémy Lal kapo...@melix.org
a/wscript
-+++ b/wscript
-@@ -209,7 +209,7 @@
+Index: nodejs-0.1.104/wscript
+===
+--- nodejs-0.1.104.orig/wscript 2010-08-15 07:53:13.367264069 -0400
nodejs-0.1.104/wscript 2010-08-15 08:03:20.447264248 -0400
+@@ -205,7 +205,7 @@
conf.fatal(Cannot find v8)
if o.debug:
diff -ur nodejs-0.1.102/debian/patches/nodejs-waf-and-node_path.patch nodejs-0.1.104/debian/patches/nodejs-waf-and-node_path.patch
--- nodejs-0.1.102/debian/patches/nodejs-waf-and-node_path.patch 2010-07-26 02:47:54.0 -0400
+++ nodejs-0.1.104/debian/patches/nodejs-waf-and-node_path.patch 2010-08-15 08:21:22.378312467 -0400
@@ -1,35 +1,20 @@
a/bin/node-waf
-+++ b/bin/node-waf
-@@ -1,11 +1,12 @@
- #!/usr/bin/env python
- import os, sys
-
--
- join = os.path.join
--bindir = os.path.dirname(os.path.realpath(__file__))
--prefix = join(bindir, ..)
--wafdir = join(prefix, lib, node)
-+if os.environ.has_key('PREFIX_NODE'):
-+ prefix = os.environ['PREFIX_NODE']
-+else:
-+ prefix = /usr
-+wafdir = join(prefix, share, nodejs)
-
- w = join(wafdir, 'wafadmin')
- t = join(w, 'Tools')
a/lib/module.js
-+++ b/lib/module.js
-@@ -94,7 +94,7 @@
-
-
-
--var modulePaths = [path.join(process.execPath, .., .., lib, node)];
-+var modulePaths = [path.join(process.execPath, .., .., lib, nodejs)];
-
- if (process.env[HOME]) {
- modulePaths.unshift(path.join(process.env[HOME], .node_libraries));
a/src/node_config.h.in
-+++ b/src/node_config.h.in
+Index: nodejs-0.1.104/src/node.js
+===
+--- nodejs-0.1.104.orig/src/node.js 2010-08-13 12:02:10.0 -0400
nodejs-0.1.104/src/node.js 2010-08-15 08:03:06.379264196 -0400
+@@ -138,7 +138,7 @@
+ var pathModule = createInternalModule('path', pathFn);
+ var path = pathModule.exports;
+
+- var modulePaths = [path.join(process.execPath, .., .., lib, node)];
++ var modulePaths = [path.join(process.execPath, .., .., lib, nodejs)];
+
+ if (process.env[HOME]) {
+ modulePaths.unshift(path.join(process.env[HOME], .node_libraries));
+Index: nodejs-0.1.104/src/node_config.h.in
+===
+--- nodejs-0.1.104.orig/src/node_config.h.in 2010-08-15 08:01:18.482301727 -0400
nodejs-0.1.104/src/node_config.h.in 2010-08-15 08:03:06.379264196 -0400
@@ -1,7 +1,7 @@
#ifndef NODE_CONFIG_H
#define NODE_CONFIG_H
diff -ur nodejs-0.1.102/debian/patches/series nodejs-0.1.104/debian/patches/series
--- nodejs-0.1.102/debian/patches/series 2010-06-14 10:44:07.0 -0400
+++ nodejs-0.1.104/debian/patches/series 2010-08-15 08:22:48.614264064 -0400
@@ -3,3 +3,4 @@
install-man-nodejs.patch
nodejs-waf-and-node_path.patch
no-v8-debug-lib.patch
+debian-changes-0.1.104-1
diff -ur nodejs-0.1.102/debian/rules nodejs-0.1.104/debian/rules
--- nodejs-0.1.102/debian/rules 2010-07-13 15:15:17.0 -0400
+++ nodejs-0.1.104/debian/rules 2010-08-15 08:22:41.154308095 -0400
@@ -10,7 +10,7 @@
build-stamp: config.status
dh_testdir
- $(MAKE)
+ $(MAKE) all doc
clean:
rm -f node
Bug#588860: netcat: -q option has gratuitously incompatible default value
Excerpts from David Caldwell's message of Mon Jul 12 16:30:58 -0400 2010: Debian netcat has an extra -q option. This is not a problem except that the default for the -q option (o_quit in the source) makes netcat behave differently on Debian than on other systems. This causes portability problems in scripts--you can even see the effects in Debian packages: libvirt and virt-manager This has been addressed in netcat-openbsd, which I thought libvirt had been updated to depend on by now. Is there some other package you specifically need to use netcat-traditional in? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564160: python-beautifulsoup: Consider permanently downgrading to 3.0.8
Excerpts from Roderik Muit's message of Thu May 27 15:18:11 -0400 2010: I 'third' this idea. Yeah, I think I'm going to do this. I was just looking at the problem earlier today (wanted to write some new BeautifulSoup-using code), and it's not as if Debian is going to completely switch over to Python 3 anytime soon... I'll do a 1:3.0.whatever before the freeze. I'm not sure yet if a separate 3.1 package is warranted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple, programs to share audio output via ALSA
Excerpts from Max Kellermann's message of Fri Apr 23 02:52:13 -0400 2010: On my card, hw:0,0 isn't the PCM channel, so this results in mpd fiddling a different volume knob than the one it's playing through. Commenting these lines back out, or replacing hw:0,0 with default, made it work. That used to be the default, but it caused so many headaches and support nightmares, it was changed. In addition to actual problems, dmix works only for the same uid, severely degrades the sound quality and increases CPU usage. You're free to activate it if you wish. What do you think about leaving the device at hw:0,0 as it is but allowing the mixer to be determined automatically (i.e. just comment out PCM in the config file I ship)? I agree about dmix but maybe that would be a good compromise. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570689: rxvt-unicode: diff for NMU version 9.07-1.1
Excerpts from Jakub Wilk's message of Sun Apr 18 20:14:18 -0400 2010: I've prepared an NMU for rxvt-unicode (versioned as 9.07-1.1) and uploaded it to DELAYED/3. Please feel free to tell me if I should delay it longer. Thanks! I was just now about to work on some other rxvt-unicode stuff so I will just roll this in and credit you in the changelog. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564034: Bug#45675: netcat: -q flag causes non-standard behaviour
Excerpts from Benedikt Spranger's message of Wed Apr 07 11:35:53 -0400 2010: The -q flag introduced by Debian is completely superfluous and harmful. It causes a lot of trouble in a cross platform environment. Furthermore the implementation changes netcat to a non standard behaviour. I've corrected this in netcat-openbsd (1.89-4). After reviewing the source in both packages and testing versions with the -q patch removed entirely, I've determined that the default behaviors in *hobbit*'s netcat and OpenBSD netcat are not the same (OpenBSD normally quits on EOF, *hobbit*'s does not unless you add and use a -q flag). At this point, I believe that anyone who has chosen to keep Debian's netcat-traditional installed instead of upgrading probably depends on its warts and quirks, so I'd prefer to only fix netcat-openbsd to make it work as people expect and not the (arguably broken) traditional way. Let me know if using netcat-openbsd is an acceptable solution for you. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571678: pandoc: should suggest or recommend texlive-latex-recommended
Package: pandoc Version: 0.46+2+b2 Severity: normal markdown2pdf requires ucs.sty. Unfortunately, at some point texlive moved this file from -recommended to -extra. If you only install pandoc and its Recommends, you get this: $ markdown2pdf foo.text markdown2pdf: pdfLaTeX failed with error code 1 markdown2pdf: error context: ! LaTeX Error: File `ucs.sty' not found. ! Emergency stop. read * ! == Fatal error occurred, no output PDF file produced! markdown2pdf: Please install the 'unicode' package from CTAN: http://www.ctan.org/tex-archive/macros/latex/contrib/unicode/ My ideal resolution to this problem would be that the texlive maintainers are persuaded to move UTF-8 support back to -recommended, so I guess I'll file another bug for that. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30.5-linode20 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pandoc depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library pandoc recommends no packages. Versions of packages pandoc suggests: pn texlive-latex-recommende none (no description available) ii tidy 20080116cvs-2 HTML syntax checker and reformatte ii w3m 0.5.2-2+b1 WWW browsable pager with excellent ii wget 1.11.4-2+lenny1 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571679: texlive-latex-recommended: should include ucs.sty
Package: texlive-latex-recommended Severity: normal Somewhere between Lenny and now, ucs.sty was moved from -recommended to -extra. As UTF-8 support is (I believe) a release goal, I would really like to be able to use it without installing all of -extra (which is not itself large, but with Recommends/Depends requires a 227(!) MB download to install). In particular, this move prevents pandoc from working out of the box, which I have filed separately as #571678 in case you think ucs.sty really ought to be kept in -extra. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30.5-linode20 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages texlive-latex-recommended depends on: pn tex-commonnone (no description available) pn texlive-commonnone (no description available) pn texlive-latex-basenone (no description available) Versions of packages texlive-latex-recommended recommends: pn latex-beamer none (no description available) pn latex-xcolor none (no description available) pn prosper none (no description available) pn texlive-latex-recommended-doc none (no description available) texlive-latex-recommended suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569039: xserver-xorg-video-radeonhd: overscan at 1920x1080
Package: xserver-xorg-video-radeonhd Version: 1.3.0-2 Severity: important Since upgrading to 1.3.0, I am experiencing overscan on the HDMI output at 1920x1080 (native resolution of my TV -- there is no overscan at lower resolutions). It it probably not more that 25 pixels, but causes scaling artifacts. (I don't understand how you can even have overscan with a digital output, but that's what it looks like.) I believe that I had this problem with 1.2.0, and 1.2.5 fixed it, and now it is broken again, but 1.2.5 has been removed from the archive and snapshot.debian.net appears to not mirrored anything for the past 10 months so I am unable to locate packages to roll everything back and test this. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30.5-linode20 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xserver-xorg-video-radeonhd depends on: ii libc6 2.7-18 GNU C Library: Shared libraries pn libpci3 none (no description available) pn xserver-xorg-core none (no description available) xserver-xorg-video-radeonhd recommends no packages. xserver-xorg-video-radeonhd suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556964: Fixed?
Our mpd runs on a host with both an IPv4 and an IPv6 address. My workstation only has an IPv4 address (but does have the ipv6 kernel module loaded as per Debian default). This makes mpc fail with Network is unreachable. This should have been fixed around 0.15 or so. Could you confirm if the problem still exists with the current version 0.19 in testing? Thanks. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550611: please use libbsd instead of glib for strlcpy
Excerpts from Guillem Jover's message of Mon Jan 11 18:00:23 -0500 2010: tag 550611 patch Wonderful, thanks. I'll apply this. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559933: mpd: mp3 support for shout not available
Excerpts from TC M.'s message of Mon Dec 07 16:05:03 -0500 2009: Regardless, it appears that mpd does not require lame libraries as a dependency, and neither option allows mpd to start: Lame is not in Debian due to patent issues. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544520: new upstream version since a while
Excerpts from Gregory Colpart's message of Thu Nov 26 15:02:26 -0500 2009: On Thu, Nov 26, 2009 at 12:06:12PM -0600, Sukant Hajra wrote: Just a note, to help highlight priority -- Twirssi (the Twitter script I use with Irssi), now has a hard depedency on v3 of Net::Twitter. Until this library is updated I'm stuck on an older version of Twirssi (v2.3). Same here. Do you want some help for maintaining this package? Yes. Are you or Sukant interested in adopting it? I apologize for not having time to address this issue. If you want to upload the new version please go ahead. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555515: sup-mail: Missing dependency on libxapian-ruby1.8
Excerpts from Micah Anderson's message of Mon Nov 09 23:49:32 -0500 2009: The new sup provides a new experimental Xapian backend to replace Ferret, as detailed in the release announcement[0]. Unfortunately, the sup-mail package doesn't depend in any way on libxapian-ruby1.8, so you end up with a backtrace if you try to use it: Do you think it would be acceptable if this were a Recommends or Suggests? the Xapian backend is still experimental and switching is a little complicated (as described in the announcement). I have only played with it, not converted my real mail stores. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555310: Upgrade of rxvt-unicode messes with my alternative installation
Excerpts from Patrick Schoenfeld's message of Mon Nov 09 05:28:40 -0500 2009: (Basically this is the german translation of removing manually selected alternative - switching x-t-e to auto mode and using /usr/bin/gnome-terminal.wrapper to provide /usr/bin/x-terminal-emulator (x-terminal-emulator) in auto mode) This was done to fix #481123. urxvtcd, which I assume you had selected, is not suitable for x-terminal-emulator (since it always immediately returns instead of running until the terminal closes, which I agree is a major problem), so I decided that the alternative should be removed entirely on upgrade. The priority for /usr/bin/urxvt is pretty low since users who don't know what they're installing probably want the more standard xterm or gnome-terminal. Thus, reverting to auto mode did not give you urxvt. (If you did not have urxvtcd selected, or no longer have an alternative for urxvt, then I have horribly messed something else up.) I see two solutions here: (1) update-alternatives is extended in some way to let you rank all alternatives, or save a stack of selections, or prioritize other alternatives from the same package on removal, or (2) I add a special case here to manually force the selection to urxvt if urxvtcd was selected. (I guess there is also (3) increase /usr/bin/urxvt's alternative priority on the assumption that only users who know they want it are going to install rxvt-unicode... but it's hard to say that about a package that's not Priority: extra.) Severity is kind of a stretch. Basically I'm not sure if /etc/alternatives are to be considered configuration files, but as they reflect local configuration choices I consider it to be a policy violation to mess with them, because Debian policy 10.7.3 should apply to those links to follow the policies spirit. I am, however, not sure weither the bug is in rxvt-unicode or not, so please feel free to reassign it if needed. If you think (1) is best I guess this could be wishlist on dpkg. I'm not sure; I don't know if anything will ever get done about it in that case, but (2) feels much more against the spirit of not messing with the user's /etc than deferring to update-alternatives. (N.b. currently, rxvt-unicode has been dropped from testing since the other bug was raised to RC and I didn't deal with it in time. This bug being RC will continue to keep it out. I'd like to avoid that.) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555310: Upgrade of rxvt-unicode messes with my alternative installation
Excerpts from Patrick Schoenfeld's message of Mon Nov 09 14:47:01 -0500 2009: 3) Well, your package already has the wrong configuration (according to policy it should have 20) but increasing it wouldn't help much. Hm. I'm not sure why the priority was originally lower that what's currently specified in policy; I'll fix it. /usr/bin/urxvt doesn't fail any of the requirements (IMO the problem with urxvtc falls under in the manner that xterm does). IME the change should be to: 1. Not remove the alternative if its set to urxvtcd 2. Add a note to NEWS.Debian, telling about the problem and all its consequences Yes, this is probably the least-disruptive thing. I'll just put a conditional on the update-alternatives call and write up a note. I can understand you in that point. But as long as there is a bug about messing with admins configuration without at least a note about this, the package /should not/ migrate to testing again. OK, just wanted to be sure of your opinion. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481123: breaks x-terminal-emulator interface
severity 481123 wishlist thanks Excerpts from Andreas Amann's message of Mon Oct 26 07:51:55 -0400 2009: This seems not justified, and the better solution is in my opinion to simply not offer urxvtcd as x-terminal-emulator alternative. I think you're right -- I was trying to implement Martin's suggestion, but it seems like (a) I don't have the libev-fu to hack it (b) it would be hairy enough (touching the rxvt_term class, not just the daemon) that our notoriously prickly upstream would never accept a patch. I've removed the alternative for 9.06-2 (uploading). It would still be nice to be able to put it back, I guess, so I'll leave this open as wishlist if someone else wants to try. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545543: change Audio Output section in default /etc/mpd.conf
Excerpts from Michel Lavie's message of Mon Sep 07 20:00:21 -0400 2009: But I think it's well worth the trade off, and better for new users to have those commented out by default. Yes, I think this is probably a good idea. Thanks. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545559: Init script: Cannot _stop_ mpd when START_MPD is set to false.
Excerpts from Florian Forster's message of Tue Sep 08 02:20:24 -0400 2009: The value of “START_MPD” should not effect the shutdown behavior. Otherwise mpd may not be shut down gracefully when the system is stopped. I'm not sure exactly what you want this to do. Are you starting MPD at some point after boot as it is configured in the package, or are you running it from a user account? What is the issue with starting mpd on boot? It seems like if we can fix that, the root of the problem would be solved. For extra credit it'd be nice to be able to disable automatic start of the daemon on system startup yet be able to start the daemon “by hand” at a later point (without changing /etc/default/mpd back and forth). The init system just runs the script. If there's a proper way to detect by hand invocation I am unaware of it. (Of course, /etc/default/mpd is sourced by the shell. You're allowed to kludge it there with something like test -f /etc/nologin START_MPD=false...) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542102: mpd: audio skips once per second
Excerpts from Peter Colberg's message of Tue Aug 18 13:45:00 -0400 2009: On Tue, Aug 18, 2009 at 06:43:56AM +0200, Max Kellermann wrote: On 2009/08/18 01:51, Peter Colberg pe...@colberg.org wrote: Reverting commit 7133f56 fixes the audio skips :-). Can you confirm if this is fixed in 0.15.3-1? Thanks. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538200: Pressing 'L' causes sup-mail to crash with 'symbol lookup error'
Excerpts from Amit Uttamchandani's message of Thu Jul 23 18:13:31 -0400 2009: Pressing 'L' for sup-mail should do a quick label search. However, as soon as 'L' is presses, sup-mail crashes and the following error is displayed: ruby: symbol lookup error: /usr/lib/ruby/1.8/i486-linux/ncurses_bin.so: undefined symbol: funcall This is #529188. I rebuilt ncurses-ruby here: http://apt.rupamsunyata.org/sup/ I'll just leave this bug here instead of reassigning/merging it so that it shows up for anyone else checking for existing bug reports. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529188: sup-mail: ncurses-ruby1.8 upgrade breaks search
severity 529188 important reassign 529188 libncurses-ruby1.8 merge 532431 529188 thanks Excerpts from Jack Hill's message of Sun May 17 18:06:15 -0400 2009: When libncurses-ruby1.8 was upgraded from version 1.1-3 to 1.2.2-1 search (via \ from within sup) breaks. Instead of providing a search prompt sup crashes with the error ruby: symbol lookup error: /usr/lib/ruby/1.8/x86_64-linux/ncurses_bin.so: undefined symbol: funcall Manualy downgrading libncurses-ruby1.8 to version 1.1-3 fixes the problem. This appears to be an issue in ncurses-ruby; until it is updated, I've placed updated packages at http://apt.rupamsunyata.org/sup/ (0.1 is just the new, fixed upstream version; 0.2 also uses ncursesw). -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520374: still broken
block 520374 by 477366 thanks Until this is resolved (see much discussion in #477366), the packages I am using are in http://apt.rupamsunyata.org/sup/ (and are currently necessary to work around other ncurses-ruby breakage in #529188). -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477366: Fixed patch
I just figured out that the original patch here is incorrect. have_header(form.h) will fail on a system (such as a pbuilder) with only ncursesw and not ncurses. We need to call find_header to ensure that /usr/include/ncursesw is added to the include path, HAVE_FORM_H is defined, etc. Attached is a diff of what I'm using at http://apt.rupamsunyata.org/sup/. With it, sup works. Without it, it doesn't (#520374). -- things change. deck...@red-bean.com ncurses-ruby-ncursesw.diff Description: Binary data
Bug#535634: sup-mail: New upstream version available
Excerpts from Asheesh Laroia's message of Fri Jul 03 17:15:26 -0400 2009: If you want help updating the package, just ask! I'm relatively free this weekend. Could you test what I've got here? (Particularly interaction with ncurses) http://apt.rupamsunyata.org/sup/ Thanks! (I just finally got around to this today...) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527253: libnet-twitter-perl: please also mention identi.ca support
Excerpts from Gerfried Fuchs's message of Wed May 06 08:02:21 -0400 2009: As the package also contains Net::Identica it would be great to have that mentioned in the package description, too - especially given that identi.ca is a FLOSS version of twitter, which is much more in the spirit of Debian, don't you agree? :) I agree this would be a good idea. Do you have a suggestion for an improved description? I was kind of at a loss what to put and just copied some text from the module rather than inventing one. It's not great. Thanks. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476377: marked as done (Please port to new libmpcdec API)
Excerpts from owner's message of Wed Apr 15 05:03:20 -0400 2009: The mpd package in experimental was build against libmpcdec3, though. Um. In the future could you please tag bugs fixed-in-experimental when applicable instead of closing them? Thanks. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523490: diakonos: contains --uninstall option
Package: diakonos Version: 0.8.8-4 Severity: normal `diakonos --uninstall' is not useful on Debian and potentially dangerous. It should either be disabled, or installation.rb should be hacked such that no files are considered to be manually installed (which would be true, since dpkg is keeping track of them). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) 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 diakonos depends on: ii ruby 4.2An interpreter of object-oriented diakonos recommends no packages. diakonos suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523491: diakonos: installs online help files in /usr/share/doc
Package: diakonos Version: 0.8.8-4 Severity: serious Justification: Policy 12.3 Diakonos's online help files are installed in /usr/share/doc/diakonos/help. According to Policy, The system administrator should be able to delete files in /usr/share/doc/ without causing any programs to break. These files should be placed in e.g. /usr/share/diakonos/help. install.rb does not currently have a --help-dir option. I will see if I can get in a patch upstream for this. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) 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 diakonos depends on: ii ruby 4.2An interpreter of object-oriented diakonos recommends no packages. diakonos suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523011: diakonos: fails to start
Package: diakonos Version: 0.8.8-1 Severity: grave Justification: renders package unusable I installed this package, closed my network connection, and then tried to run it: $ diakonos grep: help/*: No such file or directory diakonos.conf not found in any of: . /home/decklin/.diakonos At least one configuration file must exist. Would you like to download one right now from the Diakonos repository? (y/n)n Terminating due to lack of configuration file. ...and it quits. (I'll assume the help/* bit is a separate bug.) Just for illustration, here's what happens if I try to download the file anyway: $ diakonos grep: help/*: No such file or directory diakonos.conf not found in any of: . /home/decklin/.diakonos At least one configuration file must exist. Would you like to download one right now from the Diakonos repository? (y/n)y Fetching configuration from v0.8.8... /usr/lib/ruby/1.8/net/http.rb:560:in `initialize': getaddrinfo: Temporary failure in name resolution (SocketError) from /usr/lib/ruby/1.8/net/http.rb:560:in `open' from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout' from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout' from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start' from /usr/lib/ruby/1.8/net/http.rb:542:in `start' from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http' from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open' from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch' from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri' from /usr/lib/ruby/1.8/open-uri.rb:518:in `open' from /usr/lib/ruby/1.8/open-uri.rb:30:in `open' from /usr/lib/ruby/1.8/diakonos/config.rb:22:in `fetch_conf' from /usr/lib/ruby/1.8/diakonos/config.rb:70:in `loadConfiguration' from /usr/lib/ruby/1.8/diakonos.rb:122:in `initialize' from /usr/bin/diakonos:5:in `new' from /usr/bin/diakonos:5 This is totally nuts. The package includes a /etc/diakonos.conf, which looks like a perfectly reasonable configuration file. The program should use this file for defaults, then override them with any settings in the user's personal dotfile, if that file exists, like most *nix programs. If it is impossible to implement that for now, then /etc/diakonos.conf should silently be copied to ~/.diakonos on startup if the latter does not exist. End-users should never have to pull fresh configuration files from a development repository, even from a tag; they should use the stable one shipped with the package. (If I understand the goal of this package correctly, a sizable segment of its target audience shouldn't be pestered about configuring anything at all. I don't, however, feel it's as much of a problem if users who *do* wish to configure their editor need to copy the whole default file to their ~/.diakonos before tweaking it; they presumably know what they're getting into.) This does not only make the package unusable for one user if their network is down, but also for everyone if the development host (I assume it's fetching this directly from Github) has an outage for any reason. The package should be self-contained (it already has the file in question, anyway). So, I'm marking this as grave. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29 (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 diakonos depends on: ii ruby 4.2An interpreter of object-oriented diakonos recommends no packages. diakonos suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523011: diakonos: fails to start
Excerpts from Decklin Foster's message of Tue Apr 07 16:40:18 -0400 2009: diakonos.conf not found in any of: . /home/decklin/.diakonos At least one configuration file must exist. Upon reading the code, it appears that the first entry (current directory) is taken from an installation-wide conf_dir setting. These settings are defined in /usr/lib/ruby/1.8/diakonos/installation.rb. This file should definitely be customized for Debian; it looks like it has been left with the default settings for running diakonos out of a working copy. Something like: :prefix = '/usr', :bin_dir = '/usr/bin', :doc_dir = '/usr/share/doc/diakonos', :help_dir = '/usr/share/diakonos/help', :conf_dir = '/etc', :lib_dir = '/usr/lib/ruby/1.8/diakonos', Note that the help files are not currently installed by the package and I don't really know what it needs doc for (it may not have anything to do with /usr/share/doc). Anyway, with these values corrected, diakonos sanely offers to copy the config file from /etc rather than downloading one. This might not be optimal, but it allows the program to run. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520382: missing libmpd1: This is still a bug...
Excerpts from Vincent Fourmond's message of Sat Mar 21 10:55:37 -0400 2009: I must say that I strongly disagree with this statement: every package must be built against packages found in unstable. Not with the personal packages you built on your computer, *even if they are in NEW* ! So this package is broken, and it shouldn't be. Please, pretty please, don't upload broken software to unstable ! Use a chroot to build the packages you upload - or, if you have depend on the newer libmpd, wait before uploading. No. This is *why* testing and the buildds exist -- we can track whether or not packages are buildable and installable with *software*. You are asking me to do it by hand. Unstable does not exist so that you can carelessly get the latest and greatest software; it exists so that we can break it. Use testing. BTW, this is really annoying because aptitude, seeing that it cannot fulfil dependencies for an updated version, proposes a removal. (I know aptitude is stupid on this, but nevertheless, this situation should not be). If you want to fix this, please do. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520382: missing libmpd1: This is still a bug...
Excerpts from Vincent Fourmond's message of Sat Mar 21 12:18:14 -0400 2009: Sometimes, unstable gets broken because of transitions. But in this case, this is just carelessness from your side: you should not build-depend on a library not in unstable, and upload the resulting package. As a side effect, buildds are choking on the package. They are not here to choke on careless build-deps, but to build the archive. Sometimes, often, they do choke for *real* porting problems. But that isn't the case here. You're imposing an extra load on the buildds for something you *know* won't work. If choke is a description of an actual problem, and not just your rhetoric about how you think things should be done, then propose a fix. There is nothing technically intractable about how you seem to think unstable should work. Personally, I don't see the point. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518180: ITP: tircd -- ircd proxy to the twitter API
Package: wnpp Severity: wishlist Owner: Decklin Foster deck...@red-bean.com * Package name: tircd Version : 0.7 Upstream Author : Chris Nelson cnel...@crazybrain.org * URL : http://code.google.com/p/tircd/ * License : Artistic/GPL Programming Lang: Perl Description : ircd proxy to the twitter API tircd presents Twitter as an IRC channel. You can connect to tircd with any IRC client, and Twitter as if you were on IRC. To update your status on Twitter, send a message to the #twitter channel. When users you follow update their status, tircd will be sent to the channel as a message from them. Other actions are similarly mapped to the equivalent IRC commands and events. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518181: ITP: libnet-twitter-perl -- Perl interface to twitter.com
Package: wnpp Severity: wishlist Owner: Decklin Foster deck...@red-bean.com (This is a dependency of tircd, #518180.) * Package name: libnet-twitter-perl Version : 2.10 Upstream Author : Chris Thompson c...@cthompson.com * URL : http://search.cpan.org/~cthom/Net-Twitter/ * License : Artistic/GPL Programming Lang: Perl Description : Perl interface to twitter.com Twitter.com provides a web 2.0 type of ubiquitous presence. This module allows you to set your status, as well as review the statuses of your friends. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512557: lastmp: Will not install unless mpd is a system-wide service
Excerpts from Jason Riedy's message of Wed Jan 21 13:40:33 -0500 2009: I have mpd set *not* to run system-wide, and I've removed the service from /etc/rc*.d by insserv -r /etc/init.d/mpd. You should disable it by editing /etc/default/mpd. This is documented in README.Debian, and would cause MPD's init script to be a no-op. I'm open to changing the blessed way to do this from a cruddy text file to insserv, but only when Policy changes such that I am required to have it on my machine... currently, I do not, and am only putting in the LSB crud because users have requested it. lastmp is still perfectly usable per-user without running system-wide, so it would be nice if the installation worked... Of course, you are right. I will move mpd to Should-Start: (and Should-Stop:) in the LSB block so that it works when MPD is not installed on the same host. I think this will fix your particular problem, depending on how the LSB init stuff handles the case of installed-but-not-in-any-runlevel, but consider that a felicitous side effect. :-) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510675: mod support disabled in 0.14-1?
block 510675 by 476339 block 510675 by 461519 thanks I'm deferring to upstream's judgement here. Excerpts from Max Kellermann's message of Sun Jan 04 05:32:26 -0500 2009: We (upstream authors) decided to disable mikmod by default, because libmikmod contains critical security bugs, which are not fixed after a very long time, not even in Debian. It is up to Decklin to explicitly re-enable it. See: http://git.musicpd.org/cgit/master/mpd.git/commit/?id=7950a6d612a0eef6595cfd8319 12db592c4f5ad3 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461519 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476339 -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510822: mpd: Would like to have song rating field and 'not yet rated flag'
You should probably file this upstream at http://musicpd.org/mantis/. I don't see anything currently in the feature category that looks like it. Excerpts from Daniel Dickinson's message of Sun Jan 04 23:18:40 -0500 2009: Package: mpd Severity: wishlist It'd be nice if mpd could store song ratings (preferably per-user) so that one could quickly select only favourites for a playlist, or to be able to listen to many hours of okay music instead of too many repeats of the favourites. A 'not yet rated' flag would be helpful so that you could easily find songs not yet rated. Alternatively, using playlists of, say favourites and okay, and having a 'new' flag that one could remove when when has decided what playlist (if any) new songs belong in, would be nice. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510262: watch file uses old location
Excerpts from Michal Čihař's message of Tue Dec 30 17:16:09 -0500 2008: http://sf.net/musicpd/mpd-([0-9.]*).tar.gz Thanks. Also 0.14 version is available ;-). Should be making its way to your mirror as we speak :) -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495430: requesting status on this bug
Despite the fact that this bug has been already corrected upstream, and that a patch has been provided quite a long time ago, it is not fixed yet in lenny. Shell I prepare an NMU? I will upload this to unstable (should have been in already, my fault). Unless you already have. I think this issue is related to other reports I have recieved (and may solve them without much more work) so I'd like to investigate and get a solid fix for inclusion in lenny. Thanks. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508160: mpd doesn't play ogg files on armel (Openmoko FreeRunner)
Excerpts from Gilles Filippini's message of Mon Dec 08 12:20:52 -0500 2008: (gdb) run Starting program: /usr/bin/mpd --no-daemon --stdout Thanks for this. I have recently acquired some armel hardware so I can debug this sort of thing; I'll see what the deal is with libflac on there. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502622: [mpd] Problem to play 24 Bit flac files
Were you able to verify that this support worked for you in the 0.14 beta? Thanks. Excerpts from eric's message of Mon Dec 08 06:08:43 -0500 2008: 24 bit support has been added to MPD 0.14. Max Thankz -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506411: gmpc: Would like to be able to play web radio (http streams)
Excerpts from Daniel Dickinson's message of Fri Nov 21 04:13:53 -0500 2008: I've been comparing different mpd clients and unfortunately non of them have all the features of the others. gmpc for example is missing the ability to play web radio (http streams) that ario has (but has better playlist editing capabilities). It's Option - Add URL in 0.16. Is this missing in 0.15? (I assume you mean *add* a stream to the playlist; playing them is a feature of MPD, not of any client.) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506062: yeahconsole: does not recognize Shift, Meta, or Super
Package: yeahconsole Version: does not recognize Shift, Meta, or Super Severity: normal yeahconsole does not allow for a Shift modifier. Also, it only accepts Alt for mod1 and Win for mod4, which are rather PC-centric. This patch adds Shift and allows the names Meta and Super for mod1/mod4. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-linode13 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages yeahconsole depends on: ii libc6 2.7-15 GNU C Library: Shared libraries pn libx11-6 none (no description available) pn xterm | rxvt-unicode | rxvt-u none (no description available) yeahconsole recommends no packages. yeahconsole suggests no packages. --- yeahconsole.c.orig 2008-11-17 21:05:24.0 -0500 +++ yeahconsole.c 2008-11-17 21:07:15.0 -0500 @@ -293,9 +293,11 @@ if (strstr(opt, Control)) modmask = modmask | ControlMask; -if (strstr(opt, Alt)) +if (strstr(opt, Shift)) + modmask = modmask | ShiftMask; +if (strstr(opt, Meta) || strstr(opt, Alt)) modmask = modmask | Mod1Mask; -if (strstr(opt, Win)) +if (strstr(opt, Super) || strstr(opt, Win)) modmask = modmask | Mod4Mask; if (strstr(opt, None)) modmask = 0;
Bug#504817: rxvt-unicode: please document perl urxvt:: functions
Excerpts from Gerfried Fuchs's message of Fri Nov 07 10:46:43 -0500 2008: Alright, after some more fiddling around with it I found perldoc /usr/lib/urxvt/urxvt.pm. This should be installed as urxvtperl(3). Does this not work for you? Should the section be changed? I tried RS_Uline, RS_ULine, RS_uline, RS_ULINE, all of them did produce me a failure. What am I doing wrong here? Unfortunately, I have no idea. However, this definitely should be added to the docs. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504609: mpd: init.d should read MPD user from mpd.conf
Excerpts from David Futcher's message of Wed Nov 05 11:31:14 -0500 2008: Forwarding a patch from Ubuntu, mpd's init.d file should read the mpd user from mpd.conf, instead of assuming the username is 'mpd'. What is the problem that this solves? Why does it require awk? Why is it looking at audio_output? I very much dislike the idea of people running mpd under random accounts, because there's no way I can support someone who thinks they know what they're doing and breaks their setup in some strange, account-dependent way when they should just be using the defaults (#mpd is *full* of these kids). I will have to tell them to come back when they can produce the problem using the mpd user, which is a PITA for everyone involved. I'm really not happy that Ubuntu is doing this, but I guess it's up to them. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503137: Bumping severity
Excerpts from Daniel Moerner's message of Sat Oct 25 14:49:14 -0400 2008: Hi, I am bumping this to grave because it can break unrelated packages--e.g., nothing in the Debian menu that relies on x-terminal-emulator works as a result of this bug if you have set urxvtcd as the default alternative and then remove it. Good point. I'll get the fix uploaded ASAP. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503142: usage description and man page show command 'sup' instead of 'sup-mail'
Excerpts from Martin Michlmayr's message of Thu Oct 23 02:59:29 -0400 2008: Copying the maintainer since the package is still in NEW. Thanks. (Has this always been the case? A quick search of the bugs.debian.org metapackage doesn't seem to show anything filed about bugs not going to maintainers for still-NEW packages.) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499410: cannot properly read from stdin
tags 499410 +patch thanks Here is a patch to solve the issue. (I was a bit shocked to not be able to just run pastebinit and paste something in...) It makes pastebinit behave in a more standard manner: no filename is equivalent to -, not an error. I have had to adjust some of the messages (as slightly as possible), so the translations will need updating. -- things change. [EMAIL PROTECTED] pbstdin.diff Description: Binary data
Bug#502875: returns wrong version number
Excerpts from W. Martin Borgert's message of Mon Oct 20 10:58:47 -0400 2008: mpd returns '0.13.0' instead of '0.13.2'. I installed python-mpd and typed in python: I have indeed noticed this writing Njiiri, it does look pretty silly :-) Next upstream release will fix this; since it's cosmetic I don't think I should bother patching 0.13.2 in the meantime. Thanks though. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488877: ITP: libtrollop-ruby -- command-line argument processing library
Uhm, sorry. Apparently this was overlooked in the round of library uploads for sup-mail. Uploading now. Excerpts from Daniel Watkins's message of Sun Oct 19 10:17:29 -0400 2008: owner 488877 [EMAIL PROTECTED] thanks Hi Decklin, Excerpts from daniel's message of Sat Oct 11 06:11:21 -0400 2008: Just dropping a note to ask if you're getting anywhere on packaging Trollop? I have made a package, in the apparent absence of activity on your end, so I'll take over this ITP and get it uploaded 1 week from now if I don't hear anything further from you. Yes, I have it packaged and am planning on finally uploading everything this week. If you will need it for some other package, are you interested in co-maintainership? As there hasn't been any apparent uploading on your side, I'm going to go ahead and get my package uploaded. We can talk more once it's in NEW about how maintainance will work going forward, but I don't want to wait on this any more. Regards, Dan -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457174: FD_SETSIZE
Excerpts from Samuel Tardieu's message of Mon Oct 13 04:29:55 -0400 2008: Loic's patch is not so about the *number* of file descriptors but about the *largest* file descriptor that can be used in netcat. Yes, I know how select(2) works; since its usage was fixed in the other patch, I don't see why this check should be changed to some just-as-arbitrary number rather than simply eliminated. If I don't get an explanation from Loic, I'm just going to remove it at some point. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457174: FD_SETSIZE
Excerpts from Samuel Tardieu's message of Mon Oct 13 18:13:08 -0400 2008: Agreed, it should be eliminated and the system default should be kept. Anyway, I withdraw my request, we switched to socat today after I had a look at the netcat code, and it fits its job perfectly, so we won't be using netcat anymore. No problem. If you have any issues with socat's interface being different, I'd recommend netcat-openbsd over sticking with netcat. The code is much improved. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488877: ITP: libtrollop-ruby -- command-line argument processing library
Excerpts from daniel's message of Sat Oct 11 06:11:21 -0400 2008: Just dropping a note to ask if you're getting anywhere on packaging Trollop? I have made a package, in the apparent absence of activity on your end, so I'll take over this ITP and get it uploaded 1 week from now if I don't hear anything further from you. Yes, I have it packaged and am planning on finally uploading everything this week. If you will need it for some other package, are you interested in co-maintainership? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432731: gmpc gives the same error (about new libmpd) after latest upgrade
Eran writes: Trying to run gmpc with a wrong libmpd version. This will be fixed (properly) with the next libmpd. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491367: Patch for the l10n upload of lastfmsubmitd
Thanks. I'll be uploading in a few hours (sorry, forgot you were in +0200 and might not see this until tomorrow.) Christian Perrier writes: diff -Nru lastfmsubmitd-0.37.old/debian/changelog lastfmsubmitd-0.37/debian/changelog --- lastfmsubmitd-0.37.old/debian/changelog 2008-09-28 08:06:37.493209997 +0200 +++ lastfmsubmitd-0.37/debian/changelog 2008-10-04 17:04:49.457713391 +0200 snip -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500703: urxvtcd: increments $SHLVL for daemon process
martin f krafft writes: Anyway, I am not sure at this moment whether my patch is actually the right thing to do, so give me a few days to make sure it is actually doing the right thing. I am now starting to think that a terminal emulator should always start shells with SHLVL=0... Well, upstream doesn't seem to like it: http://lists.schmorp.de/pipermail/rxvt-unicode/2008q4/000721.html I realize I should have pointed out (to you) that urxvtc does send its environment to the new terminal that urxvtd creates. That may or may not be useful. (OK not really, what we would like here is for urxvtcd to Just Work out-of-the-box...) Ultimately I think using a login shell for this (as mentioned in the thread) would be the way to go. Since not all users want every terminal to be a login shell (I don't), I'd have to leave the default as off, and make it a FAQ... and then we'd have to ensure that bash and zsh correctly set SHLVL to some known value for login shells (which seems like what one wants here) -- it seems to me that they should anyway. You want to count the number of shells from the login shell, right? (OTOH, if Debian's /etc/bashrc fixes this up and other distributions don't... meh.) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500703: urxvtcd: increments $SHLVL for daemon process
martin f krafft writes: Anyway, I am not sure at this moment whether my patch is actually the right thing to do, so give me a few days to make sure it is actually doing the right thing. I am now starting to think that a terminal emulator should always start shells with SHLVL=0... I think that might be a good idea. Not sure how upstream would feel, but I could check. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500703: urxvtcd: increments $SHLVL for daemon process
martin f krafft writes: Since /usr/bin/urxvtcd is a shell script, it will increase $SHLVL for urxvtd's environment Well, only if /bin/sh is bash. What is the problem caused by increasing $SHLVL? What is $SHLVL good for? (I don't use bash.) According to the documentation, it is incremented by each bash process, so if urxvtd is in fact started by a bash process, this seems like a correct reflection of what happened. If you're going to use a shell that sets SHLVL and need it to start at a known value in each terminal window, I would suggest creating a wrapper for urxvtd that initializes it. urxvtcd could of course be replaced with a tiny C program but I'm just not sure why it would be necessary. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500703: urxvtcd: increments $SHLVL for daemon process
martin f krafft writes: Well, only if /bin/sh is bash. No, also with dash and zsh. And for the cases where $SHLVL is not set, my patch will just no-op. I tested dash here and it didn't (the man page also makes no mention of SHLVL either). Are you sure? As for zsh, I suppose I should have assumed it has everything ;-) I guess my point was just that if it says #!/bin/sh it's a script for any POSIX shell and this is a workaround for a feature in shells that are a superset of POSIX. I'd like to see dash as the default /bin/sh sooner rather than later so that things like this don't come up. Well, yes and no. I use SHLVL to tell make my $PS1 tell me when I am in a subshell. I don't care that there are already two shells involved just to get the terminal (xsession (where I reset SHLVL myself) + urxvtcd). I'm not *strongly* opposed to doing something in rxvt-unicode, but I do think this (I mean, SHLVL itself) is an ugly hack. Isn't what you actually want here counting *interactive* shells? From a little googling it seems that what people want SHLVL for is displaying something in PS1 or otherwise modifying interactive behavior. For this purpose I think something like case $- in *i*) ishlvl=$(($ishlvl+1));; esac would be more useful (do normal programs, as opposed to shell init scripts, ever consult SHLVL?). As you said, the value SHLVL normally starts at sitting in front of an X session is totally arbitrary and useless. I'd really prefer to discourage its use. Plus, the shell that spawns urxvtcd or urxvtd will not be around anymore when the terminal is spawned: Right, but the definition of SHLVL doesn't say anything about this. So, if bash runs my ~/.xsession, the SHLVL in the environment is still incremented when that shell disappears by exec-ing the session manager. Sure, but let me ask you the opposite, in the face of the aforementioned the shell that spawns urxvtcd or urxvtd will not be around anymore: why should $SHLVL be incremented at all? Well, I also think this is dumb, but only because I think SHLVL itself is dumb. :-) It seems to be the natural consequence of the design -- if some random thing happened to be invoked by a shell, SHLVL is incremented, whether we care about it in the real world or not. Adding a workaround here is possible, but won't fix that broken design for other programs. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498911: fixed in mpd 0.13.2-2
Julien Cristau writes: Well that's not quite correct. If start-stop-daemon fails, the init script is supposed to fail if mpd isn't running after start, or it's still running after stop... Adding '|| true' to s-s-d invocations is wrong, IMHO. You're right. Since #478018 was fixed by fixing this anyway, I shouldn't have used the hack there (as you can see from the suggested patch gdm apparently does it with `set +e' but that's the same thing, just... uglier). I'll strip this out for the next revision. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493480: excessive dependencies in rxvt-unicode-lite
Hans Ekbrand writes: This seems like a mistake, since the description of the package has not changed, and explictly says that the lite version is built without freetype support. Someone requested Xft, I believe, but I have no idea why GTK is in there; that is definitely a mistake. (I don't use -lite myself.) I've been considering just building two packages, one with all useful options and one ideally pared down to close to where we were in etch. There's not much meaningful difference between rxvt-unicode and rxvt-unicode-ml anymore. Do you think this would be good? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500049: ITP: ears -- collection of MPD/Last.fm clients
Package: wnpp Severity: wishlist * Package name: ears Version : 1.0.0 Upstream Author : Decklin Foster [EMAIL PROTECTED] * URL : http://www.red-bean.com/decklin/ears/ * License : MIT Description : Last.fm plugin for MPD and CD ripper Ears contains a number of scripts originally distributed with lastfmsubmitd: - lastmp, an MPD player plugin that uses lastfmsubmitd - peel, a CD ripper that optionally uses lastfmsubmitd - several MusicBrainz tools to facilitate getting data in or out of either program This package replaces the standalone lastmp package that used to be part of lastfmsubmitd. However, if you don't use MPD, you can still install this package and use peel to rip CDs. No, the world certainly does not need another CD ripper[1], but it, along with lastmp etc, weren't doing much good sitting in lastfmsubmitd and muddying the purpose of that package. So I've split them out. There's absolutely no new code in this version. MPD users (who still need something to send data to Last.fm; this is the important one) will get the usual transitional package. Basically any other random music tool that speaks lastfmsubmitd-ish YAML would be welcome here (maybe a tag editor?). This should make it less painful for other player plugins[2] to depend on lastfmsubmitd. (and lastmp won't be an entire binary package for a less-than-250-line script...) As far as I can tell this name is so dumb that there is little chance of it getting confused with some other package, generic as it may be. [1] it was a proof-of-concept for the spool format, I swear. [2] this is their term, which is why it's in the long description even though it's technically incorrect. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358619: please prefetch the buffer for the next track
martin f krafft writes: I am sure it didn't at the time, so please close the bug with the appropriate version number; I don't use mpd anymore. Will do. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495066: rxvt-unicode: embedding perl needs PERL_SYS_INIT3()
Niko Tyni writes: As described in the 'perlembed' document, programs embedding Perl must use the PERL_SYS_INIT3() and PERL_SYS_TERM() macros to provide system-specific tune up of the C runtime environment necessary to run Perl interpreters. I'd like to do this, but I'm currently getting: panic: MUTEX_LOCK (22) [regcomp.c:9317] during global destruction. when I call PERL_SYS_TERM. I'm not able to dig deeper into this right now (our initialization is a little convoluted; I just hacked it into main()). If you know what I might be doing wrong or could just point me to another perl-embedding bug with the same issue that would be a great help. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489353: failure to start causes failure to install/upgrade
Ulrich Eckhardt writes: However, while upgrading, mpd tries to start, too, which fails and subsequently the whole installation fails. There are two things here I consider wrong: This is definitely wrong; I thought I fixed it several releases back, and it WFM at the time, but it doesn't look right to me now. Should be easy to fix properly when I have a chance to do more testing. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489059: ITP: mnemosyne-blog -- Maildir-to-blog compiler with XML templating and Python extensions
Robert Collins writes: I think it would be better to have the description text disambiguate somehow, or folk may read one, install the other, and thus be confused. This seems reasonable. I'll think of something unobtrusive to add to the description. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489059: ITP: mnemosyne-blog -- Maildir-to-blog compiler with XML templating and Python extensions
Package: wnpp Severity: wishlist Owner: Decklin Foster [EMAIL PROTECTED] * Package name: mnemosyne-blog Version : 0.9 Upstream Author : Decklin Foster [EMAIL PROTECTED] * URL : http://www.red-bean.com/~decklin/mnemosyne/ * License : ISC Programming Lang: Python Description : Maildir-to-blog compiler with XML templating and Python extensions Mnemosyne is a simple blogging system which generates static files. Instead of using a database or filesystem hierarchy, you store your entries in a Maildir. Writing a blog entry is thus as easy as sending an email, and rebuilding the blog can be automated with mail filters, cron, etc. . XHTML and XML are generated with Kid templates; a bare-bones web view and an Atom feed are included as examples. Mnemosyne is extensible in Python to add features such as input preprocessing (reStructuredText is used by default), metadata (tags are standard) and filtering entries for custom feeds. Yes, yet another static intarblog thing. I have found some interest in blogging again, and would like to get it in better shape (almost everything that should be added can be done as an extension, but the extension interface is somewhat incomprehensible). As far as I know the Maildir design is unique. I wrote this ages ago, and in the meantime another package was renamed to mnemosyne, so in the tradition of epiphany-browser (and sup-mail, which I am presently packaging) I'm going with mnemosyne-blog and renaming things out of the way appropriately. The short description starts with a capital letter only because Maildir is spelled with an M. Note: license in the released version is still MIT, but I'm transitioning most of my non-GPL code. Before this goes in I will probably roll 0.9.1. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.25.6 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#488856: ITP: libferret-ruby -- search engine derived from Lucene
Package: wnpp Owner: Decklin Foster [EMAIL PROTECTED] Severity: wishlist This is one of a series of ITPs for Ruby libraries (gems) required for the packaging of sup-mail; see #450602. If anyone at all is interested in stepping in to maintain one or more of these libraries, please let me know. I am not using them for anything else (other than research into improving the .gem - .deb process). * Package name: libferret-ruby Version : 0.11.6 Upstream Author : David Balmain [EMAIL PROTECTED] * URL : http://ferret.davebalmain.com/ * License : X/MIT Programming Lang: Ruby Description : search engine derived from Lucene Ferret is a high-performance, full-featured text search engine library written for Ruby. It is inspired by Apache Lucene Java project. In the same way as Lucene, it is not a standalone application, but a library you can use to index documents and search for things in them later. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (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/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488855: ITP: libchronic-ruby -- natural language date parser
Package: wnpp Owner: Decklin Foster [EMAIL PROTECTED] Severity: wishlist This is one of a series of ITPs for Ruby libraries (gems) required for the packaging of sup-mail; see #450602. If anyone at all is interested in stepping in to maintain one or more of these libraries, please let me know. I am not using them for anything else (other than research into improving the .gem - .deb process). * Package name: libchronic-ruby Version : 0.2.3 Upstream Author : Tom Preston-Werner [EMAIL PROTECTED] * URL : http://chronic.rubyforge.org/ * License : X/MIT Programming Lang: Ruby Description : natural language date parser Chronic is a natural language date/time parser written in pure Ruby. Chronic can parse a huge variety of date and time formats. Parsing is case insensitive and will handle common abbreviations and misspellings. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (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/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488873: ITP: libmime-types-ruby -- guess MIME type of files
Package: wnpp Owner: Decklin Foster [EMAIL PROTECTED] Severity: wishlist This is one of a series of ITPs for Ruby libraries (gems) required for the packaging of sup-mail; see #450602. If anyone at all is interested in stepping in to maintain one or more of these libraries, please let me know. I am not using them for anything else (other than research into improving the .gem - .deb process). * Package name: libmime-types-ruby Version : 1.15 Upstream Author : Austin Ziegler [EMAIL PROTECTED] * URL : http://mime-types.rubyforge.org/ * License : Ruby/Artistic/GPL2+ Programming Lang: Ruby Description : guess MIME type of files This library allows for the identification of a file's likely MIME content type. The identification of MIME content type is based on a file's filename extensions. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (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/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488872: ITP: liblockfile-ruby -- create NFS-safe lockfiles
Package: wnpp Owner: Decklin Foster [EMAIL PROTECTED] Severity: wishlist This is one of a series of ITPs for Ruby libraries (gems) required for the packaging of sup-mail; see #450602. If anyone at all is interested in stepping in to maintain one or more of these libraries, please let me know. I am not using them for anything else (other than research into improving the .gem - .deb process). * Package name: liblockfile-ruby Version : 1.4.3 Upstream Author : Ara T. Howard [EMAIL PROTECTED] * URL : http://rubyforge.org/projects/codeforpeople/ * License : Ruby Programming Lang: Ruby Description : create NFS-safe lockfiles lockfile is a ruby library for creating NFS safe lockfiles. A command-line tool which uses this library is also included. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (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/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488877: ITP: libtrollop-ruby -- command-line argument processing library
Package: wnpp Owner: Decklin Foster [EMAIL PROTECTED] Severity: wishlist This is one of a series of ITPs for Ruby libraries (gems) required for the packaging of sup-mail; see #450602. If anyone at all is interested in stepping in to maintain one or more of these libraries, please let me know. I am not using them for anything else (other than research into improving the .gem - .deb process). * Package name: libtrollop-ruby Version : 1.8.2 Upstream Author : William Morgan [EMAIL PROTECTED] * URL : http://trollop.rubyforge.org/ * License : Ruby Programming Lang: Ruby Description : command-line argument processing library Trollop is YAFCLAP -- yet another fine commandline argument processor for Ruby. Trollop is designed to provide the maximal amount of GNU-style argument processing in the minimum number of lines of code (for you, the programmer). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (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/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486807: since upgrade urxvtcd does not start anymore
Patrick Schoenfeld writes: BTW. note that it states it would be 9.02 if launched via urxvtcd. Thats strange, because urxvtcd and rxvt-unicode both state that its version is 9.05, only the urxvtc binary says it is 9.02. So it seems your package does not install a new version of this binary. That is... extremely strange. urxvtc has not gone anywhere (I'm using it right now, albeit on amd64). You can see for yourself at: http://packages.debian.org/sid/i386/rxvt-unicode/filelist Does your output of `dpkg -L rxvt-unicode` match that? Are you maybe still running the urxvtd shipped with 9.02? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486807: since upgrade urxvtcd does not start anymore
Patrick Schoenfeld writes: It now works. However I think that its more then suboptimal if an upgrade makes running sessions impossible to use. Isn't there a better way to handle the client-server connections between urxvtc and urxvtcd? It would be nice, but I don't know of any sensible way to replace the running daemon -- if some random user is even running one. It would be kind of like restarting xdm on every upgrade. Incompatible upgrades are at least very rare. I agree that they should not happen in point releases, FWIW. I could put a message in the postinst reminding people to restart but (a) relying on being able to print stuff there is bad (b) most users probably don't care about urxvtd (c) the ones that do are probably aware of this issue (d) every time I see that message from Iceweasel I roll my eyes and ask what operating system this is again. So, I don't know. If you have any ideas I'm open to them. (Ccing the bug, even though it's closed, for the sake of future travelers) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485178: netcat: FTBFS when converted to new source format 3.0 (quilt): patches modify files in debian directory
Raphael Hertzog writes: That's fine, but if you consider those as patchs to the upstream source ready to be merged, place your added manual page in the upstream hierarchy and not inside debian. I guess this makes sense. I'll do it in the meantime. However I hope that by then we'll have examples of tools to generate 3.0 (quilt) source packages directly from a git repository. Cool. I was hoping this would be the case, but I gave up on following the discussion very closely once people started arguing about which VCS was better :-) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450602: Taking up ITP for sup
retitle 450602 ITP: sup-mail -- console based email client with tagging and fast search owner 450602 [EMAIL PROTECTED] block 450604 by 450602 kthxbye I am interested in packaging sup for Debian. I plan on packaging all the required libraries for non-gem installation (ITPs to follow)[1]. I currently have a package that works, but only if the gems are already installed. I can throw this on git.debian.org if anyone is interested in testing or helping out. I have changed the name here to sup-mail, but might consider sup-mailer. William, I would appreciate your opinion here (sup in Debian is taken by some unrelated program). The two other packages I use with this problem, git-core and epiphany-browser, both use a dash (and I am about to ITP mnemosyne-blog, so there you go). Also, I plan on providing a sup-next package for experimental, so this would be more consistent. [1] Nothing wrong with gems per se, they just aren't useful here. Users need to be able to type apt-get install sup-mail and that requires using our system, just like how we don't use CPAN or eggs. Perhaps when I'm done with this I'll have something that makes it easier to make a .deb out of a gem. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485160: Bug#485178: netcat: FTBFS when converted to new source format 3.0 (quilt): patches modify files in debian directory
Raphael Hertzog writes: In the case of netcat, the quilt series contains patches that modify files in the debian directory. You shouldn't have to dynamically patch the files in the debian directory since its content is provided by the .diff.gz (or the new .debian.tar.gz in the new format). The reasoning for this was that - The manual page (nc.1) was added by Debian - a couple of the quilt patches add new options which are logically separate from those in other patches So, additions to nc.1 were placed in whichever patch added the documented feature. I am in the process of converting everything to git-buildpackage, so this problem will go away. For lenny, I'd like to keep the format as it is so that the patch series for -openbsd (new) can be compared to the existing one in -traditional. Immediately after that I will start uploading from git (AIUI, until we can really upload 3.0 source packages, this will result in a big ugly .diff.gz, which I would not consider fit for release in the case of such a heavily modified package as netcat). I'll close these bugs whenever that is. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477621: dadadodo: diff for NMU version 1.04-3.1
Chris Lamb writes: The attached file is the diff for my dadadodo 1.04-3.1 NMU. The associated changelog entry is: Thanks. Are you interested in adopting it, or just doing a sweep of old bashism bugs? I don't think I've actually used the program in a while. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458375: Sponsorship
Daniel Kahn Gillmor writes: my latest efforts at packaging it rely instead on the new debian/rules minimization that's possible with debhelper 7, which addresses many of the concerns (and more) in a standardized way. Great; that's what I was going to suggest. (Gotta love that rules file...) The main outstanding issue that i haven't dealt with is the set of warnings that come up when compiling with -Wall -- i'll work on that when i get a bit more free time, since i'd like to be able to offer a changeset upstream instead of just a nag. How do you plan on managing patches, and the packaging in general? I could help with this particular issue, but it'd be more convenient if your SVN repo looked like a standard svn-buildpackage layout (with upstream on a branch). The latest version is 20071230-2, published in the usual place: Have you asked upstream if they plan to do a real version number? My personal preference is to do something ugly like 0~20071230 now rather than be stuck with 1:1.0 and so on later. (This is opinion, you can ignore it :)) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458375: Sponsorship
I'd like to sponsor this package. Daniel, have you looked at any of Jörg's suggestions? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479574: Window shifts when executing font-change via escape sequence
martin f krafft writes: echo -en \033]50;-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-1\007 changes the font used by the XTerm. It also causes the rxvt-unicode window to shift +1+1, which it shouldn't. Just out of curiosity, what WM are you running? It appears that urxvt doesn't adjust the ResizeInc hints on the window, either, which makes aewm fail rather glaringly. I'd like to recover from that better. As for the bug, it should be sufficient to have urxvt not set the flags for X and Y position when it reconfigures the window -- only the width and height are important. This is (at a very cursory check) what XTerm does, and XTerm works for me. (The resize-hint thing is a property change and will probably require adding code. Feel free to open a bug on that.) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479424: mpd fails to start sometimes due to an error in /etc/init.d/mpd
gustavo panizzo writes: Package: mpd Version: 0.12.1-1.1 Severity: important Tags: patch mpd start stop script don't create /var/run/mpd, so if you have /var/run mounted over tmpfs, mpd will fails to start. This is fixed in testing. Could you please try 0.13.1-3? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473540: mpd starts too soon (before mountall.sh has run)
Dennis Kaarsemaker writes: Please change the default start later in the boot sequence, specifically after S35mountall.sh, so it will work on nfs mounts or dmraid as well. see also: https://bugs.edge.launchpad.net/ubuntu/+source/mpd/+bug/141425 Huh? mountall.sh runs in level S, mpd runs in level 2. Ubuntu's problem may be related to upstart. The current package has dependency-based init info, if it uses that. I can't figure out from that Ubuntu page how to Cc the bug. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471111: mpd_stop should preferentially invoke mpd --kill
Nick Black writes: Per the man page, mpd --kill is the proper way to shut down mpd. I'm not sure this is implied by the wording. Regardless, --kill functions by reading the pid_file and sending a SIGTERM to the mpd process. start-stop-daemon (as called by our init script) sends SIGTERM, waits 5 seconds, then sends SIGKILL. If your system is extremely loaded, perhaps MPD does not respond to the SIGTERM within 5 seconds. Try changing the value given for --retry. If this solves a reproducible problem for you, I'll consider increasing it. However, if your system seems fine otherwise, it would be helpful if you could examine closely what is going on during the timeout. It may be a sign of some other problem. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469690: lastmp: Crashes when song title contains non-ascii characters
Joris van Rooij writes: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 63: ordinal not in range(128) Can you tell me what happens if you don't run it in this locale? Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Thanks. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469690: lastmp: Crashes when song title contains non-ascii characters
Joris van Rooij writes: Plus, the lastfm user has it's shell set to /bin/false and it's home dir does not exist. That pretty much keeps it from using any env variable I have changed anywhere, right? Should be using /etc/environment, I believe. I have LANG set there to en_US.UTF-8. While something like this has been working[1] for most people, it's not great. The problem is that the locale I want for my environment doesn't really have anything to do with the encoding I use for my tags; they're just hopefully the same if I keep things organized. But then a tag may have invalid UTF-8. It really should be fixed in MPD; I haven't looked too closely at what it does. It looks like this could be improved a lot, though, by doing more guessing on the input end and only considering the system locale for output purposes. You would end up seeing 'ignore' or 'replace' encoded stuff in your log file, which might be disconcerting, but... not a show-stopper. I'll see what I can do. [1] Let's try it now with some valid UTF-8: 2008-03-06 17:29:22,489 lastmp[2455] INFO: New song: Björk - Jóga [5:06] So yeah. But that works for you too if I understand correctly. -- things change. [EMAIL PROTECTED]
Bug#469435: lastmp: only handles a single mpd
Paul Collins writes: I have a bunch of mpds installed around the place (two on this machine alone), and it would be nice if a single lastmp could talk to all of them, whether by direct support or by starting one per mpd. It should be possible for any number of lastmp processes (this would have to be one per MPD) write to the same lastfmsubmitd spool. Would a --config option make this easier? Not sure what your setup looks like. last.fm's spam protection would probably trigger if I played music with more than one mpd at a time, but that would be my problem. I hear they relaxed this. (But I am very behind on updating protocol stuff...) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467505: does not provide /bin/nc without netcat-traditional
martin f krafft writes: I need to install netcat-traditional to make it work. Thanks; this was due to netcat-traditional removing the wrong path after the package name was changed, so if you don't want to install/uninstall again (-37 will work properly), you can remove it from the database by hand: update-alternatives --remove nc /bin/nc.traditional update-alternatives --set nc /bin/nc.openbsd Sorry for the inconvenience. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463901: mpd needs 'shout' audio output plugin compiled in package - Lenny
Brian Millan writes: Supported outputs: alsa ao oss pulse jack Hmm. Unfortunately, this is not surprising. See #453746; we don't build with libvorbis on arm, but rather libvorbisidec (Tremor, the integer decoder); e.g. the NSLU2 doesn't have a FPU so regular libvorbis is unacceptably slow. libvorbisidec, is, however, just a decoder; Shout needs to encode to Vorbis as well, and so depends on libvorbis (floating-point). Therefore if MPD is configured --with-tremor shout output is disabled. It *might* be possible to hack things up to use Tremor for decoding but still link against libvorbis for shout outputs, but this would probably be ugly and you'd still end up with poor performance. There doesn't seem to be a good answer here; sorry. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
