Bug#492545: pristine-tar: please make tar command configurable
Package: pristine-tar
Version: 0.17
Severity: wishlist
Tags: patch
On Mac OS X 10.3 with tar from MacPorts installed, /usr/bin/tar is GNU
tar 1.13.25 (from 2001) while /opt/local/bin/gnutar is GNU tar 1.20.
For some reason, I learned not to trust the old version of tar. Maybe
it doesn't like the pax header that git archive adds. So I wished
pristine-tar would use gnutar instead of tar.
I've attached a patch adding a variable $tarprog to specify a program to
use instead of tar. It would probably be better to add a configuration
file or environment variable so that the user doesn't have to modify
three different files, but this was enough to scratch my itch.
If you have ideas about how to do this better, I would be glad to try
them out and send another patch. Thanks for writing pristine-tar and
etckeeper - they have been incredibly helpful.
--- % cut here ---
Subject: make tar command configurable
On some systems, the tar program that appears first on the PATH
is buggy or old, so that users may want to use gnutar, gtar,
or /path/to/some/specific/tar instead.
With this patch applied, one can specify a program to use instead
of tar by modifying the 'my $tarprog = tar;' line in each
pristine-{tar,bz2,gz} script.
---
pristine-bz2 |5 +++--
pristine-gz |5 +++--
pristine-tar | 23 ---
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/pristine-bz2 b/pristine-bz2
index 212e350..1080917 100755
--- a/pristine-bz2
+++ b/pristine-bz2
@@ -86,6 +86,7 @@ my @supported_bzip2_programs = qw(bzip2 pbzip2);
my $verbose=0;
my $debug=0;
my $keep=0;
+my $tarprog=tar;
sub usage {
print STDERR Usage: pristine-bz2 [-vdk] genbz2 delta file\n;
@@ -221,7 +222,7 @@ sub genbz2 {
close OUT;
}
- doit(tar, xf, File::Spec-rel2abs($delta), -C, $tempdir);
+ doit($tarprog, xf, File::Spec-rel2abs($delta), -C, $tempdir);
if (! -e $tempdir/type) {
die failed to genbz2 delta $delta\n;
}
@@ -298,7 +299,7 @@ sub gendelta {
print OUT $program\n;
close OUT;
- doit(tar, czf, $delta, -C, $tempdir, @files);
+ doit($tarprog, czf, $delta, -C, $tempdir, @files);
if ($stdout) {
doit(cat, $delta);
diff --git a/pristine-gz b/pristine-gz
index b2ca53a..a89726b 100755
--- a/pristine-gz
+++ b/pristine-gz
@@ -118,6 +118,7 @@ use constant {
my $verbose=0;
my $debug=0;
my $keep=0;
+my $tarprog=tar;
sub usage {
print STDERR Usage: pristine-gz [-vdk] gengz delta file\n;
@@ -319,7 +320,7 @@ sub gengz {
close OUT;
}
- doit(tar, xf, File::Spec-rel2abs($delta), -C, $tempdir);
+ doit($tarprog, xf, File::Spec-rel2abs($delta), -C, $tempdir);
if (! -e $tempdir/type) {
die failed to gengz delta $delta\n;
}
@@ -410,7 +411,7 @@ sub gendelta {
print OUT $timestamp\n;
close OUT;
- doit(tar, czf, $delta, -C, $tempdir, @files);
+ doit($tarprog, czf, $delta, -C, $tempdir, @files);
if ($stdout) {
doit(cat, $delta);
diff --git a/pristine-tar b/pristine-tar
index 2837f48..c7b8d5a 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -139,7 +139,8 @@ my $verbose=0;
my $debug=0;
my $keep=0;
my $message;
-
+my $tarprog=tar;
+
# Force locale to C since tar may output utf-8 filenames differently
# depending on the locale.
$ENV{LANG}='C';
@@ -308,9 +309,9 @@ sub recreatetarball {
my $ret=$tempdir/recreatetarball;
- doit(tar, cf, $ret, --owner, 0, --group, 0,
+ doit($tarprog, cf, $ret, --owner, 0, --group, 0,
--numeric-owner, -C, $tempdir/workdir,
- --no-recursion, --mode, 0644,
+ --no-recursion, --mode, 0644,
--files-from, $tempdir/manifest);
return $ret;
@@ -332,7 +333,7 @@ sub gentar {
close OUT;
}
- doit(tar, xf, File::Spec-rel2abs($delta), -C, $tempdir);
+ doit($tarprog, xf, File::Spec-rel2abs($delta), -C, $tempdir);
if (! -e $tempdir/type) {
error failed to gentar delta $delta;
}
@@ -357,10 +358,10 @@ sub gentar {
doit(xdelta, patch, $tempdir/delta, $recreatetarball, $out);
if (-e $tempdir/wrapper) {
- my $type=`tar xOzf $tempdir/wrapper type`;
+ my $type=`$tarprog xOzf $tempdir/wrapper type`;
chomp $type;
if ($type eq 'gz') {
- doit(pristine-gz,
+ doit(pristine-gz,
($verbose ? -v : --no-verbose),
($debug ? -d : --no-debug),
($keep ? -k : --no-keep),
@@ -385,7 +386,7 @@ sub genmanifest {
my $tarball=shift;
my $manifest=shift;
- open(IN, tar tf $tarball |) || die tar tf: $!;
+ open(IN, $tarprog . tf $tarball |) || die $tarprog .
Bug#494505: [PATCH for git-core] fall back to 'editor', not 'vi', if EDITOR is unset
Package: git-core
Version: 1:1.5.6.3-1
Severity: minor
Here's a patch to (I hope) catch all the remaining situations in which
git falls back to vi rather than editor. I don't have access to a
Debian system on which I have permission to install packages any more,
so I have not been able to test the .debs it produces. But I think it
should be okay. I hope it is of some use.
Thanks,
Jonathan
-- snipsnip --
This patch takes care of those instances of hardcoded vi that
remain after the fix to bug #438793
Signed-off-by: Jonathan Nieder [EMAIL PROTECTED]
---
contrib/fast-import/git-p4 |2 +-
git-add--interactive.perl |2 +-
git-send-email.perl|3 ++-
git-sh-setup.sh|2 +-
git-svn.perl |2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6ae0429..3d2a491 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -651,7 +651,7 @@ class P4Submit(Command):
newdiff = newdiff.replace(\n, \r\n)
tmpFile.write(submitTemplate + separatorLine + diff + newdiff)
tmpFile.close()
-defaultEditor = vi
+defaultEditor = editor
if platform.system() == Windows:
defaultEditor = notepad
if os.environ.has_key(P4EDITOR):
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..020c7a3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -728,7 +728,7 @@ EOF
close $fh;
my $editor = $ENV{GIT_EDITOR} || $repo-config(core.editor)
- || $ENV{VISUAL} || $ENV{EDITOR} || vi;
+ || $ENV{VISUAL} || $ENV{EDITOR} || editor;
system('sh', '-c', $editor.' $@', $editor, $hunkfile);
open $fh, '', $hunkfile
diff --git a/git-send-email.perl b/git-send-email.perl
index d2fd899..dc0e335 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -530,7 +530,8 @@ GIT: for the patch you are writing.
EOT
close(C);
- my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, core.editor) ||
$ENV{VISUAL} || $ENV{EDITOR} || vi;
+ my $editor = $ENV{GIT_EDITOR} || Git::config(@repo,
+core.editor) || $ENV{VISUAL} || $ENV{EDITOR} || editor;
system('sh', '-c', $editor.' $@', $editor, $compose_filename);
open(C2,,$compose_filename . .final)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index d17b349..059e461 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -67,7 +67,7 @@ git_editor() {
case $GIT_EDITOR,$TERM in
,dumb)
echo 2 No editor specified in GIT_EDITOR, core.editor,
VISUAL,
- echo 2 or EDITOR. Tried to fall back to vi but terminal is
dumb.
+ echo 2 or EDITOR. Tried to fall back to editor but terminal
is dumb.
echo 2 Please set one of these variables to an appropriate
echo 2 editor or run $0 with options that will not cause an
echo 2 editor to be invoked (e.g., -m or -F for git-commit).
diff --git a/git-svn.perl b/git-svn.perl
index 0dbdec6..35419d9 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1052,7 +1052,7 @@ sub get_commit_entry {
close $log_fh or croak $!;
if ($_edit || ($type eq 'tree')) {
- my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
+ my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'editor';
# TODO: strip out spaces, comments, like git-commit.sh
system($editor, $commit_editmsg);
}
--
1.6.0.rc1.228.ge730
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458954: git-diff silently fails if not a git repo or .git is not readable
tags 458954 fixed-upstream thanks Joey Hess wrote: Version: 1:1.5.3.7-1 [...] [EMAIL PROTECTED]:/etc/splashygit diff [EMAIL PROTECTED]:/etc/splashy git diff should print an error and exit nonzero if it's not in a git repo or cannot read .git. The current behavior is indistingushable from being in a git repo with no changes. This was fixed upstream in commit 59b0c24a 'git-svn: detect and fail gracefully when dcommitting to a void' (really!) and the fix was included in v1.5.6-rc0. So I think the bug could be closed. ~$ git diff fatal: git diff [--no-index] takes two paths Regards, Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482138: Bug#479824: progress
If you could push your stuff to a non-bundle it would make life even easier Ack! Sorry I have been taking so long. I was bitten by the bug described at http://article.gmane.org/gmane.comp.version-control.git/83101 - serves me right for trying to get things done using a prerelease version of git. Anyway, please take a look at http://home.uchicago.edu/~jrnieder/gpm.git for-nico once you get a chance. The 'upstream' corresponds to gpm-1-stable from http://unix.schottelius.org/git/gpm. The for-nico branch contains changes that I think should be pushed upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476634: patch available for #476634
tags 476634 + patch thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476347: git-buildpackage: Should handle empty .orig.tar.gz gracefully
On Thurs, Apr 17, 2008 at 16:04:11 +0200, Guido Günther wrote: On Wed, Apr 16, 2008 at 08:55:27AM +0200, Christoph Biedl wrote: [problem importing the contents of an empty tarball with git add .] git-commit --allow-empty allows for an empty initial commit (which we'd need then too), the same option would be nice for git-add. Does git ls-files -o --exclude-standard -z | git update-index --add -z --stdin do what you are looking for? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478494: asciidoc: New upstream release
I am using the new upstream version. All that was needed was an update to the Debian changelog and the following change. (I mention this in the hope that it saves someone a few minutes.) Jonathan --- debian/patches/asciidoc-fix-python-path.patch.orig 2008-05-19 12:12:02.0 -0500 +++ debian/patches/asciidoc-fix-python-path.patch 2008-05-19 11:14:36.0 -0500 @@ -3,6 +3,6 @@ @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/python - ''' - asciidoc - converts an AsciiDoc text file to DocBook, HTML or LinuxDoc + + asciidoc - converts an AsciiDoc text file to DocBook, HTML or LinuxDoc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476634: git-core: wrongly escaped .ft in manpages
The following changes fix this for me: 1. Add docbook-xsl ( 1.72) to the Build-Depends field of debian/control 2. Add DOCBOOK_XSL_172=Yes to the parameters for $(MAKE) in the build-indep-stamp: rule from debian/rules. See Documentation/asciidoc.conf for a brief hint to what's going on. Hope this helps, Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476634: git-core: wrongly escaped .ft in manpages
I forgot to mention that in my local tree I have made some other changes to debian/rules: - the build-arch-stamp: patch-stamp line has become build-arch-stamp: build-indep-stamp patch-stamp - removed $(MAKE) -CDocumentation man ASCIIDOC8=YesPlease from the rules for build-arch-stamp - the build-indep-stamp: line has become build-indep-stamp: build-arch-stamp These changes have nothing to do with manpages being broken: they just prevent debian/rules uselessly building the manpages twice. But I mention these changes now because without them one has to add DOCBOOK_XSL_172=Yes to the line that begins $(MAKE) -CDocumentation under build-arch-stamp as well. Please let me know if I should file a separate bug for the manpages-building-twice issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479824: progress
I just fetched it, but have to go to sleep soon. Will have a look at it in the next days. Thank you, but note that it is a work in progress - I haven't looked over everything to make sure it makes sense yet. I hope to put something more reasonable out tonight. Which branch is designed for merge with upstream? jrnieder/upstream or jrnieder/upstream-patches? I guess the last one? Actually, jrnieder/my-patches. jrnieder/upstream-patches contains refreshed versions of the patches already in Debian that had not been applied upstream yet. Btw, I preferred git-remote add jrnieder /home/user/nico/projekte/gpm/git-bundles/jrnieder.bdl to be easier able to merge with you later on. I didn't realize you could do that. Thanks! If you could push your stuff to a non-bundle it would make life even easier for me :-) I was planning to make a patch series with format-patch, but because you ask I will make the changes available for http access as well :) Thanks again for all the suggestions. Until later, Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#522858: tar: causes dpkg-source extract failures
Hi, I wrote: Would it be possible to add a Breaks: dpkg ( 1.14.26) line to a future release? but I should have said Breaks: dpkg-dev ( 1.14.26). Sorry about that. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547802: lzma: coexist with xz-lzma
Package: lzma Version: 4.43-14 Severity: wishlist Hi, Background, for completeness: 1. The Debian lzma package consists of an lzmp command, which uses the LZMA SDK functions to handle .lzma files (i.e. lzma_alone format). 2. There is no upstream source for lzmp. The command is maintained in Debian in debian/patches. 3. Until recently, most other distributions’ lzma command came from LZMA Utils (which does have an upstream). If the Debian lzma package is to continue to be maintainable, it should probably be switched to that. 4. The XZ Utils package provides its own lzma command with the intention of superseding LZMA Utils. 5. The essential dpkg package depends on the lzma command so it can handle LZMA-compressed packages. This means that the lzma command always has to be usable, since a system with LZMA-compressed third-party packages might be relying on it. If the Debian archive starts accepting lzma-compressed packages, this will become even more important. It would be nice for Debian to gently migrate from lzmp to XZ Utils. For squeeze, current lzmp users would have the option to continue to use lzmp or something equally well tested (like lzma from LZMA Utils), or to switch to xz-lzma. For squeeze+1, if xz-lzma proved reliable enough in squeeze, it would supersede lzma. If dpkg did not pre-depend on lzma, this would be easy: just let lzma and xz-lzma conflict and let the user decide between them. Since lzma cannot be uninstalled, if lzma and xz-lzma conflict then xz-lzma is not installable. (See http://bugs.debian.org/542060.) If dpkg were always installed but not essential, this would still be easy: let lzma and xz-lzma both provide /usr/bin/lzma through the alternatives mechanism. This would leave lzma without the functionality dpkg depends on until lzma is configured, which is too late for a pseudo-essential package. Where should we go from here? a. Get dpkg to stop using lzma and use liblzma instead. Since dpkg is one of the first packages a user upgrades for a new version of Debian, this makes for an uncomplicated upgrade. lzma should probably conflict with xz-lzma, as except for during an upgrade there is no reason at all to have both installed. I think this is the most sane option. b. Rename /usr/bin/lzma to /usr/bin/lzmp and ship a symlink from /usr/bin/lzma to lzmp. Use diversions to make /usr/bin/lzma point to xz when xz-lzma is installed. This is messy, but I think it would work. I don’t want to try it. c. Stop shipping lzmp and rename xz-lzma to lzma. If a sysadmin was depending on some peculiarity of lzmp, he must force a downgrade to the older package (but security support through oldstable would still apply). The lzma source package would still be needed for lzma-alone and sqlzma. Thoughts? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548190: xz-utils: --force not compatible with gzip and bzip2
tags 548190 + upstream fixed-upstream pending thanks Hi, Francesco Potortì wrote: here is a pipeline that decompresses stdin be it compressed with gzip or bzip2, and leaves it untopuched if it is not compressed: bzip2 -cdfq | gzip -cdfq However, extending it to also decompress xz fails: bzip2 -cdfq | xz -cdfq | gzip -cdfq because xz does not let an unrecognised file pass through. Thanks for the report. This is fixed upstream by commit 18c10c3 (Make xz --decompress --stdout --force copy unrecognized files as is to standard output., 2009-07-04). If you’d like to try a newer version before it is uploaded to Debian, see the packages for testing at http://collab-maint.alioth.debian.org/xz-utils or the source repository http://git.debian.org/?p=collab-maint/xz.git. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547802: lzma: coexist with xz-lzma
tags 547802 + patch thanks So we'd have: lzma Pre-Depends: lzma-lzma | xz-lzma lzma-lzma Replaces: lzma ( 4.43-+) Pre-Depends: libc6 (= 2.7-1), libgcc1 (= 1:4.1.1), libstdc++6 (= 4.2.1) Conflicts: xz-lzma Okay, so I've tried this out and it seems to work. Patch is in branch dummy of http://git.debian.org/?p=collab-maint/lzma.git. Thanks again for the advice. Sincerely, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547802: lzma: coexist with xz-lzma
tags 547802 - patch thanks This is my last message for tonight, I promise. I wrote: lzma Pre-Depends: lzma-lzma | xz-lzma lzma-lzma Replaces: lzma ( 4.43-+) Pre-Depends: libc6 (= 2.7-1), libgcc1 (= 1:4.1.1), libstdc++6 (= 4.2.1) Conflicts: xz-lzma Okay, so I've tried this out and it seems to work. Seeming to work and working are unfortunately miles appart. In this setup, if one wants to switch between xz-lzma and lzma-lzma, one can't. To install xz-lzma, one needs to uninstall lzma-lzma first, but then there is no lzma command. It really does seem like short of diversions, there is no way to have two different implementations of an essential command and be able to switch between them. dash and bash use diversions to decide who provides /bin/sh. cron looks pretty basic and has multiple implementations, and it is only possible to switch between them because it is not actually essential. So the trick is to make lzma not essential any more. I’m working on that (see Bug#542160). In the meantime, it is probably best that xz-utils just not ship the lzma compatibility commands. Sorry for all the fuss. Good night, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604557: [PATCH 0/5] Re: RFS: aspell-id
Mahyuddin Susanto wrote: Third try, i've uploaded third times this package to mentors and fixing many typo and info for package Hi, some quick patches. Still untested, and unfortunately I do not have the expertise to help find a sponsor/maintain this. (Maybe someone at dictionaries-common-dev could help?) Jonathan Nieder (5): fix Vcs-Browser link provide aspell-dictionary virtual package remove build-time dependency on quilt Add upstream doc directory copyright: GPL-2+? debian/changelog |9 + debian/control |6 +- debian/copyright |7 +- doc/README_id_ID.txt | 452 ++ 4 files changed, 467 insertions(+), 7 deletions(-) create mode 100644 doc/README_id_ID.txt -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604557: [PATCH 1/5] fix Vcs-Browser link
Point to gitweb instead of the raw git repo, to make it easier for casual readers to browse changes. --- debian/changelog |6 ++ debian/control |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/debian/changelog b/debian/changelog index a094522..613128c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +aspell-id (1.2-0-3+) local; urgency=low + + * Vcs-Browser: point to gitweb, not raw repository. + + -- Jonathan Nieder jrnie...@gmail.com Thu, 02 Dec 2010 16:10:05 -0600 + aspell-id (1.2-0-3) unstable; urgency=low * Confirmed and tested in Ubuntu (Closes: LP:#63189) diff --git a/debian/control b/debian/control index 85cfe9e..508772b 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,7 @@ Build-Depends: debhelper (= 5), quilt Build-Depends-Indep: dictionaries-common-dev (= 0.9.1) Homepage: http://translationproject.org/team/id.html -Vcs-Browser: https://alioth.debian.org/anonscm/git/debian-id/aspell-id.git +Vcs-Browser: http://git.debian.org/?p=collab-maint/aspell-id.git Vcs-Git: git://git.debian.org/debian-id/aspell-id.git Standards-Version: 3.9.1 -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604557: [PATCH 2/5] provide aspell-dictionary virtual package
Acked-by: Brian Nelson nel...@bignachos.net
---
debian/changelog |1 +
debian/control |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 613128c..b77f00c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
aspell-id (1.2-0-3+) local; urgency=low
* Vcs-Browser: point to gitweb, not raw repository.
+ * provide aspell-dictionary virtual package.
-- Jonathan Nieder jrnie...@gmail.com Thu, 02 Dec 2010 16:10:05 -0600
diff --git a/debian/control b/debian/control
index 508772b..dd56dbd 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Architecture: all
Depends: ${misc:Depends},
aspell (= 0.60.3-2),
dictionaries-common (= 0.49.2)
+Provides: aspell-dictionary
Description: Indonesian (id) dictionary for GNU aspell
This package contains the required files to add support for the Indonesian
(id) language to the GNU Aspell spell checker.
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604557: [PATCH 3/5] remove build-time dependency on quilt
The 3.0 (quilt) format does not require quilt to work. --- debian/changelog |1 + debian/control |3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index b77f00c..db6d366 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ aspell-id (1.2-0-3+) local; urgency=low * Vcs-Browser: point to gitweb, not raw repository. * provide aspell-dictionary virtual package. + * remove unnecessary build-time dependency on quilt. -- Jonathan Nieder jrnie...@gmail.com Thu, 02 Dec 2010 16:10:05 -0600 diff --git a/debian/control b/debian/control index dd56dbd..0db3f74 100644 --- a/debian/control +++ b/debian/control @@ -4,8 +4,7 @@ Priority: optional Maintainer: Translation Team ID translation-team...@lists.sourceforge.net Uploaders: Mahyuddin Susanto udi...@gmail.com Build-Depends: debhelper (= 5), - cdbs (= 0.4.0), - quilt + cdbs (= 0.4.0) Build-Depends-Indep: dictionaries-common-dev (= 0.9.1) Homepage: http://translationproject.org/team/id.html Vcs-Browser: http://git.debian.org/?p=collab-maint/aspell-id.git -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604557: [PATCH 5/5] copyright: GPL-2+?
COPYING and the doc/ directory contain the GPL version 2. The Copyright file just says GPL. So it is not quite clear what version is meant. This patch assumes GPL-2+ to be generous and to match the existing text in debian/copyright. --- Maybe it would be possible to clarify what version is meant with upstream. That's the end of the series. Hope that helps. debian/changelog |1 + debian/copyright |7 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/debian/changelog b/debian/changelog index db6d366..41f4cd7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,6 +3,7 @@ aspell-id (1.2-0-3+) local; urgency=low * Vcs-Browser: point to gitweb, not raw repository. * provide aspell-dictionary virtual package. * remove unnecessary build-time dependency on quilt. + * copyright: update License line to match the text that follows it. -- Jonathan Nieder jrnie...@gmail.com Thu, 02 Dec 2010 16:10:05 -0600 diff --git a/debian/copyright b/debian/copyright index abeecb5..f22d93f 100644 --- a/debian/copyright +++ b/debian/copyright @@ -15,7 +15,7 @@ Upstream Authors: Benitius Brevoort benitius.brevo...@kapusin.org Files: * Copyright: © 2004, Benitius Brevoort benitius.brevo...@kapusin.org -License: GPL-3 +License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your @@ -30,6 +30,5 @@ License: GPL-3 with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . - On Debian systems, the complete text of the GNU General Public License can be - found in `/usr/share/common-licenses/GPL-2' and - `/usr/share/common-licenses/GPL-3'. + On Debian systems, the complete text of the GNU General Public License + version 2 can be found in '/usr/share/common-licenses/GPL-2'. -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601632: bash 4.0 breaks some completion scripts
Jonathan Nieder wrote: Bash 4.0 changed the rules for completion word splitting so that they are incompatible with 3.x. I think some Breaks: will be needed to ensure smooth upgrades. Just FYI: Ah, at last some clarity! From the bash 3 manual: COMP_WORDS An array variable (see Arrays below) consisting of the individual words in the current command line. The words are split on shell metacharacters as the shell parser would separate them. This variable is available only in shell functions invoked by the programmable completion facilities (see Programmable Completion below). From the bash 4 manual: COMP_WORDS An array variable (see Arrays below) consisting of the individual words in the current command line. The line is split into words as readline would split it, using COMP_WORDBREAKS as described above. This variable is available only in shell functions invoked by the programmable completion facilities (see Programmable Completion below). The workaround used by the bash-completion scripts is to paste words from COMP_WORDS together (in _get_comp_words_by_ref). If only the NEWS file had mentioned it. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605762: xz-utils: Incorrect czech (cs_CZ.utf8) long help translation
Hi Petr, Petr Hubený wrote: The --no-sparse explanation is mistranslated as do not create backup files when decompressing instead of do not create sparse files when decompressing Thanks for reporting. What should it be replaced with? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605770: git send-email -h does not dump usage
Package: git-email Version: 1:1.7.2.3-2.1 Severity: minor $ git send-email -h format-patch -o /tmp/FVcbDfKpbq -h: command returned error: 129 A usage message would be nicer and more consistent with other git commands. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605767: git-email: UTF-8 content in To: causes Subject: to also be RFC2047 encoded
Hi Sascha, Sascha Silbe wrote: If To: contains a non-ASCII character, the Subject: header is RFC2047 encoded even if it contains only ASCII characters: === Begin === From: Sascha Silbe sascha-...@silbe.org To: =?UTF-8?q?St=C3=A9phane=20Magnenat?= stephane.magne...@mavt.ethz.ch Subject: =?UTF-8?q?Patches=20for=20Osqoop?= $ git format-patch HEAD^..HEAD;# some plain ASCII patch $ git send-email --to='Jönäthän Nïëdër jrnie...@gmail.com' 0001* Who should the emails appear to be from? [Jonathan Nieder jrnie...@gmail.com] Emails will be sent from: Jonathan Nieder jrnie...@gmail.com Message-ID to be used as In-Reply-To for the first email? (mbox) Adding cc: Jonathan Nieder jrnie...@gmail.com from line 'From: Jonathan Nieder jrnie...@gmail.com' From: Jonathan Nieder jrnie...@gmail.com To: =?UTF-8?q?J=C3=B6n=C3=A4th=C3=A4n=20N=C3=AF=C3=ABd=C3=ABr?= jrnie...@gmail.com Cc: Jonathan Nieder jrnie...@gmail.com Subject: [PATCH] work around inability of patches to represent new directories Date: Fri, 3 Dec 2010 04:15:25 -0600 Message-Id: 1291371325-12369-1-git-send-email-jrnie...@gmail.com X-Mailer: git-send-email 1.7.2.4 The Cc list above has been expanded by additional addresses found in the patch commit message. By default send-email prompts before sending whenever this occurs. This behavior is controlled by the sendemail.confirm configuration setting. For additional information, run 'git send-email --help'. To retain the current behavior, but squelch this message, run 'git config --global sendemail.confirm auto'. Send this email? ([y]es|[n]o|[q]uit|[a]ll): q The subject seems to be ASCII. Ideas? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605540: chromium-browser: needlessly warns about unsafe PDFs
forcemerge 605540 605410 quit brian m. carlson wrote: When I attempted to download a PDF today, Chromium warned me that PDFs may be potentially unsafe. Yeah! Actually, it warns me whenever I try to download anything. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604114: dpkg: version '/usr/share/myspell/dicts' has bad syntax: invalid character in version number
reassign 604114 debconf 1.5.36
quit
Kurt Roeckx wrote:
it seems that
debconf is turning a triggered into a configure.
Yes. Maybe /usr/share/debconf/frontend near 69:
if ($ARGV[0] =~/^(.*[.\/])(?:postinst|preinst)$/) {
could be tweaked to check $ARGV[1], too?
Otherwise, /usr/share/debconf/confmodule or postgresql-common et al
themselves would need to guard against the $1 = triggered case
themselves.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606053: debcheckout: warning when run with perl 5.12 (Prototype after '@' for main::set_destdir)
Package: devscripts Version: 2.10.69 Severity: minor Justification: cosmetic $ debcheckout curl Prototype after '@' for main::set_destdir : @$$ at /usr/bin/debcheckout line 349. declared git repository at git://git.debian.org/collab-maint/curl.git [...] $ dpkg -l perl | tail -1 ii perl 5.12.2-2 Larry Wall's Practical Extraction and Report Language -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606054: debuild: warning when run with perl 5.12 (Name main::OLDOUT used only once: possible typo)
Package: devscripts Version: 2.10.69 Severity: minor Justification: cosmetic $ debuild -I -i -b Name main::OLDOUT used only once: possible typo at /usr/bin/debuild line 617. Name main::OLDERR used only once: possible typo at /usr/bin/debuild line 618. dpkg-buildpackage -rfakeroot -D -us -uc -I -i -b [...] $ dpkg -l perl | tail -1 ii perl 5.12.2-2 Larry Wall's Practical Extraction and Report Language $ sed -n '615,618 p' /usr/bin/debuild # Start by duping STDOUT and STDERR open OLDOUT, STDOUT or fatal can't dup stdout: $!\n; open OLDERR, STDERR or fatal can't dup stderr: $!\n; $ Ideas for suppressing this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606059: curl: please implement DEB_BUILD_OPTIONS=nocheck
Source: curl Version: 7.21.2-3 Severity: wishlist Justification: policy §4.9.1 Running tests while building curl from source takes a long time. As far as I can tell they can be disabled with DO_TEST=no; would it make sense to treat the usual nocheck option in DEB_BUILD_OPTIONS as a synonym? Thanks for keeping curl running well. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606078: ExtUtils::MakeMaker: generated makefile can't cope with perl upgrade
Package: perl-modules Version: 5.10.1-16 Tags: upstream Upgraded perl to 5.12.2-2 today. Works very well, generally; thanks! But: $ cd ~/src/git $ make -j2 SUBDIR git-gui SUBDIR gitk-git make[1]: Nothing to be done for `all'. SUBDIR perl make[2]: *** No rule to make target `/usr/lib/perl/5.10/Config.pm', needed by `perl.mak'. Stop. make[1]: *** [all] Error 2 make: *** [all] Error 2 Hmm, that's odd. $ make V=1 [...] make -f perl.mak all make[2]: Entering directory `/home/jrn/src/git/perl' make[2]: *** No rule to make target `/usr/lib/perl/5.10/Config.pm', needed by `perl.mak'. Stop. [...] $ cat perl/perl.mak # This Makefile is for the Git extension to perl. # # It was generated automatically by MakeMaker version # 6.55_02 (Revision: 65502) from the contents of # Makefile.PL. Don't edit this file, edit Makefile.PL instead. [...] # --- MakeMaker makefile section: # We take a very conservative approach here, but it's worth it. # We move Makefile to Makefile.old here to avoid gnu make looping. $(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP) $(NOECHO) $(ECHO) Makefile out-of-date with respect to $? $(NOECHO) $(ECHO) Cleaning current config before rebuilding Makefile... -$(NOECHO) $(RM_F) $(MAKEFILE_OLD) -$(NOECHO) $(MV) $(FIRST_MAKEFILE) $(MAKEFILE_OLD) - $(MAKE) $(USEMAKEFILE) $(MAKEFILE_OLD) clean $(DEV_NULL) $(PERLRUN) Makefile.PL PREFIX=/home/jrn INSTALL_BASE= $(NOECHO) $(ECHO) == Your Makefile has been rebuilt. == $(NOECHO) $(ECHO) == Please rerun the $(MAKE) command. == $(FALSE) Ah. Should be fixable by adding a dummy $(CONFIGDEP) : ; Thoughts? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606148: st: warnings on console at startup (missing fontset: JISX0201.1976-0)
Package: suckless-tools Version: 38-1 Severity: minor Justification: cosmetic When I start st: $ st st: missing fontset: JISX0201.1976-0 st: missing fontset: GB2312.1980-0 st: missing fontset: KSC5601.1987-0 st: missing fontset: JISX0208.1983-0 It seems to work okay, though. When I press the right control key: errkey: 65508 size /usr/bin/xterm /usr/bin/st tells a promising story. Thanks for working on it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606148: st: warning when control modifier pressed (errkey: 65508)
clone 606148 -1 retitle 606148 st: warning when control modifier pressed (errkey: 65508) quit Jonathan Nieder wrote: When I press the right control key: errkey: 65508 Cloning. Sorry, I should have filed that as a separate bug in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606150: st: leaves cursor as X shape
Package: suckless-tools Version: 38-1 Severity: wishlist Justification: usability It is hard to tell when text is going to be selected when clicking and dragging in 'st', since the cursor is a big X. Please consider changing the mouse cursor to the usual I-beam instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605039: apt-listbugs: scary message on interruption
Francesco Poli wrote:
On Sat, 27 Nov 2010 17:49:08 -0600 Jonathan Nieder wrote:
Francesco Poli wrote:
I have somewhat good news for you: I prepared a patch that moves the
trap instruction before everything else, in order to intercept early
SIGINTs too.
[...]
I've just pushed the commit to the
public git repository.
I think there is a ruby (documentation?) bug here: for example
-- 8 --
diff --git a/apt-listbugs b/apt-listbugs
index 2e4b5cb..d762cd5 100755
--- a/apt-listbugs
+++ b/apt-listbugs
@@ -235,7 +235,7 @@ apt.conf(5), sensible-browser(1), www-browser(1),
querybts(1)
# exit gracefully when user presses [Ctrl+C]
-Signal.trap(SIGINT) { $stderr.puts Interrupted; exit 130 }
+Kernel.trap(SIGINT, SIG_DFL)
if File.expand_path(__FILE__).match(/^\/usr\/s?bin\//)
-- 8 --
doesn't actually set the handling of SIGINT to SIG_DFL at all, but
makes it print a backtrace. Given that bug, your patch would seem to
be the best we can do. So I like it.
Thanks,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606163: Kernel.trap(..., SIG_DFL) prints a backtrace when triggered
Package: ruby1.8 Version: 1.8.7.302-2 Severity: minor Hi Lucas et al, a puzzle for you. Attempting Kernel.trap(SIGINT, SIG_DFL) doesn't actually set the handling of SIGINT to SIG_DFL at all, but makes the script print a backtrace on interruption. According to [1], with SIG_DFL the operating system's default handler will be invoked. I would interpret this as meaning the effect should be analogous to signal(SIGINT, SIG_DFL). Noticed while debugging apt-listbugs's handling of ^C. [2] Hints? Is this behavior intended? Jonathan [1] http://ruby-doc.org/core/classes/Kernel.html#M005975 [2] http://bugs.debian.org/605039 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606073: [qt4-doc] Doc formatting looks broken (no css used)
tags 606073 + upstream forwarded 606073 http://bugreports.qt.nokia.com/browse/QTBUG-13608 quit Romain Bossart wrote: qt assistant does not format the docs using css. The menus and generally the formating looks broken. Googling around gave a similar bug in ubuntu: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/624697 Thanks for a helpful pointer. From the upstream bug: Not sure how to handle that. Still the regression is based on the fact that we have changed the documentation stylesheet. If we would go and support QTextBrowser, we would need to include and fallback to the old classic stylesheet. Any ideas from the doc team here? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606180: assistant-qt4: prints warning to console at startup
Package: qt4-dev-tools Version: 4:4.7.1-1 Severity: minor Justification: cosmetic/warning $ assistant Object::connect: No such signal HelpViewer::printRequested() The assistant itself works fine (aside from bug#606073). Still, thought you might like to know. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462792: RFS: failmalloc
Hi Allesandro, Alessandro Ghedini wrote: * URL : http://www.nongnu.org/failmalloc [...] - dget http://mentors.debian.net/debian/pool/main/f/failmalloc/failmalloc_1.0-1.dsc Since I am not a Debian Developer, I cannot upload this. Some comments anyway. Package: libfailmalloc-dev Description: Memory allocation failure crash-test tool (development files) [...] This package provides the development files for the failmalloc library. Does failmalloc have a public API? Is it meant to be linked into programs without using the LD_PRELOAD mechanism? If not, what good is a development library for it? Package: libfailmalloc0 Description: Memory allocation failure crash-test tool I would suggest installing it to /usr/lib/libfailmalloc/libfailmalloc.so . That way, there is no temptation to link programs to it explicitly. Unversioned since there is no reason to install multiple versions at once. Since you are selling it as a tool rather than a preload library (reasonable enough), have you considered providing a /usr/bin/failmalloc script to do the LD_PRELOAD automatically? See fakeroot for inspiration. #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. It's not a sample any more, is it? I'd suggest removing the authorship notice. #!/usr/bin/make -f %: dh $@ is too simple to require the notice for moral reasons, I'd think. As legal reasons go, without restriction includes the ability to remove the blurb. Or you can copy from /usr/share/doc/debhelper/examples/rules.tiny by the same author which does not include that notice. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482194: bash: PS1 non-empty for non-interactive shells
tags 482194 + moreinfo quit Hi again, Jonathan Nieder wrote: I can't reproduce this, though I suppose that's not so surprising given that I'm trying bash 4.1-3. Can't reproduce with bash 3.2-4 from lenny, either. Given that /etc/skel/.bashrc relies on $PS1 being set or not set depending on interactive mode, I would expect this to be reported more if it were a widespread problem. Alas. Sorry we didn't get to it sooner. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544731: error: no such disk renders system unbootable
found 544731 grub2/1.97-1 tags 544731 - unreproducible quit Albin Tonnerre wrote: Alright, so this started happening again. I'm using the latest version from unstable, 1.97-1. I assume you can reproduce this reliably? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548545: bash: Bash does not autocomplete anything after a backslash on the command prompt
tags 548545 + moreinfo unreproducible quit Jonathan Nieder wrote: Can you still reproduce this problem (perhaps with bash from snapshot.debian.org)? Can't reproduce with bash 4.0-7 (on i386), either, alas. :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606369: bash: Put $HOME/bin to end of $PATH
severity 606369 wishlist retitle 606369 skel/.profile: put $HOME/bin at end of $PATH quit Justin B Rye wrote: If as an innocent newcomer to GNU/Linux I sort a set of downloaded scripts into one directory called keep and another called bin, that doesn't necessarily mean I intend the second set to receive a privileged position on my $PATH - on the contrary, it may mean I think they look suspicious and intend to throw them away. Sounds like a good reason to remove the special handling of ~/bin from the default skel/.profile altogether. If you are interested in that, please file a new bug (for example by cloning this one). I do not find it a good reason to keep ~/bin at the end of $PATH. The suspicious user can be tricked into saving a malicious script named sl to ~/bin. The next time she transposes the letters of ls on the command line, trouble. Similar is the possibility of programs in ~/bin being run by scripts. The following is not such an unusual pattern: for browser in mozilla netscape lynx do if type $browser /dev/null 21 then $browser $url return fi done echo 2 could not find web browser exit 1 A malicious script named 'netscape' in ~/bin could be run by such a non-Debian app with no typos involved. Likewise for many other utilities that may not already be available on the $PATH. Malice isn't the only thing we need security against; the reason I keep ~/bin at the *end* of my $PATH is for protection against my own foolish mistakes. Makes sense. I think you will find people wanting both variants, so I am happy this is a user-editable file. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#316213: bash confused by missing newline at end of script
tags 316213 + moreinfo tags 316213 - unreprocible quit Hi Martin, Martin Ziegler wrote: The script if /bin/false ; then echo hi fi prints hi, if there is NO NEWLINE at the end. Could you give a simple script to reproduce this? For example: cat -\EOF testme.sh if /bin/false ; then echo hi fi EOF head -c $(( $(wc -c testme.sh) - 1 )) testme.sh nonl.sh chmod +x nonl.sh bash ./nonl.sh does not print hi here. Thanks for reporting, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#318117: bash: signal handling or man page deficiency
retitle 318117 bash: prints Terminated for jobs killed by signal when noninteractive tags 318117 + upstream severity 318117 wishlist found 318117 bash/4.1-3 # [1] forwarded 318117 http://thread.gmane.org/gmane.comp.shells.bash.bugs/13711/focus=13741 quit Tim Connors wrote: cat bin/sig-test #!/bin/sh while echo loop ; do sleep 5 done shell1 sig-test sheel2 killall sleep loop bin/sig-test: line 6: 19448 Terminated sleep 5 loop bin/sig-test: line 6: 19458 Terminated sleep 5 loop Yes. Even set +m does not suppress this. Upstream does not seem inclined to change that; see [1] for some discussion and a workaround. I would be happy to have a patch fixing this, especially if you are willing to maintain it in the long term. That said, I am not the bash maintainer, so this is not meant to say anything about chance of such a patch being applied. Thanks for a clear report. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#318117: bash: signal handling or man page deficiency
[resending to more modern address for Tim. sorry for the noise] Tim Connors wrote: cat bin/sig-test #!/bin/sh while echo loop ; do sleep 5 done shell1 sig-test sheel2 killall sleep loop bin/sig-test: line 6: 19448 Terminated sleep 5 loop bin/sig-test: line 6: 19458 Terminated sleep 5 loop Yes. Even set +m does not suppress this. Upstream does not seem inclined to change that; see [1] for some discussion and a workaround. I would be happy to have a patch fixing this, especially if you are willing to maintain it in the long term. That said, I am not the bash maintainer, so this is not meant to say anything about chance of such a patch being applied. Thanks for a clear report. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462792: RFS: failmalloc
Alessandro Ghedini wrote: On Wed, Dec 08, 2010 at 01:14:03AM -0600, Jonathan Nieder wrote: Does failmalloc have a public API? Is it meant to be linked into programs without using the LD_PRELOAD mechanism? If not, what good is a development library for it? Quoting from the upstream site This software generates a shared library which can be loaded by LD_PRELOAD or linked at compilation time, so yes, it is also meant to be linked without LD_PRELOAD. Ah, ok. In this case, I would suggest: - library in package named libfailmalloc0 and installed to /usr/lib/libfailmalloc.so.0.0.0 - failmalloc program and bare /usr/lib/libfailmalloc.so symlink in a package named failmalloc. Since you are selling it as a tool rather than a preload library (reasonable enough), have you considered providing a /usr/bin/failmalloc script to do the LD_PRELOAD automatically? See fakeroot for inspiration. This is a great idea, I didn't thought about this. Should I rename the package, or just put that script in the libfailmalloc0? Thanks, glad you like it. :) That script cannot be included in the libfailmalloc0 package, since to do so would prevent libfailmalloc0 and a future libfailmalloc1 from being installed at the same time. See [1] for more on this. Thank you very much for the review and the great idea. No problem. Thanks for packaging failmalloc --- it looks like a lot of fun (and useful, of course) so I look forward to being able to install it from the Debian archive. Jonathan [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593560: chromium-browser: Unlike Chrome, custom google maps don't work properly
found 593560 chromium-browser/6.0.472.63~r59945-2 quit Bertrand Marc wrote: Le 09/11/2010 02:06, Jonathan Nieder a écrit : I wasn't able to reproduce this, unfortunately; the [P]s show up for me. [...] Sorry for the delay, but i don't have an internet connexion at home these days, so I couldn't try. Sadly it doesn't work any better, with Chromium 6.0.472.63 (59945) from Squeeze... No problem; thanks for checking. If you can find time to confirm the version in experimental works (or someone else can try both versions to confirm the fix), that would be great and I would be happy to figure out which patch fixed it. If the version in experimental does not work, that would be more surprising. In that case we should probably work on this upstream[1]. Regards, Jonathan [1] http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux and please send the issue number to the Debian bug report in that case so others can easily find it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599113: estimated download time always displayed as 'NaN'
# Christian Beier wrote: # # I tested with 6.0.472.63 from squeeze on i386: download time is indeed # displayed. So this seems to be a non-i386 issue at least, maybe it's # only 64bit systems affected... # # Turns out it has to do with comma as fraction separator. Who knew? tags 599113 + l10n -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Package: mksh Version: 39.3.20101101-1 Severity: wishlist Tags: upstream Hi Thorsten, Recently I found myself debugging a pipeline with tee. Unfortunately the logs grew large very quickly, so as a stopgap measure I used a compressor. mkfifo backflow ... backflow | tee (xz -1 log-one.xz) | ... | tee (xz -1 log-two.xz) | ... | tee (xz -1 log-three.xz) backflow This construct is also handy when one wants to update the current environment downstream from some other process. while read -r line do ... something interesting with line ... accum=$(updated result) done (upstream process) : print result printf %s\n $accum The semantics: ( ... )- runs ... in a subshell in the background, with its output connected to a pipe. The ( ... ) expression evaluates to a filename that can be opened to read from that pipe. ( ... )- runs ... in a subshell in the background, with its input connected to a pipe. The ( ... ) evaluates to a filename that can be opened to write to that pipe. On Linux and similar OSes this is typically implemented using /proc/fd. A more portable implementation would use FIFOs. What do you think? Is it worth implementing in mksh? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606825: dpkg: Please add mingw to ostable and triplettable.
Hi, Some uninformed reactions. Dmitrijs Ledkovs wrote: --- a/ostable +++ b/ostable @@ -31,3 +31,4 @@ bsd-openbsd openbsd openbsd[^-]* sysv-solaris solaris solaris[^-]* uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)? +w64-mingw32 w64-mingw32 mingw32[^-]* The ABI part (e.g., sysv-, gnu-, or bsd-) describes instruction set variant and conventions for function calls, dynamic linking, and program startup. That last part often depends on libc. In this case, it is mingw-w64, abbreviated as w64, I suppose. Why not plain mingw --- are programs built with mingw32 unable to safely use DLLs built with mingw64, for example? The OS part (e.g., -linux) represents the kernel and maybe the userland tools. Should it be winnt? What versions of Windows are being targeted? Functionally, the effect is to determine DEB_HOST_ARCH DEB_HOST_ARCH_OS DEB_HOST_GNU_TYPE for use by debian/rules when building packages targeted at that system. (I know you realize this, just reminding myself!) Gcc 4.5 and higher recognises -w64-mingw32 So the value in the GNU name column is correct. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606756: [PATCH dash/debian-sid] debian/preinst: Do not error out if files are missing
severity 606756 serious
tags 606756 + patch
quit
-- 8 --
Subject: debian/preinst: Do not error out if files are missing
Even if /bin/sh or its manpage is missing, dpkg -i dash.deb needs to
succeed. Currently it errors out because cp exits with nonzero status
when the file to be copied is missing.
This fixes a regression introduced in dash 0.5.5.1-2.2 (2009-07-22).
It unfortunately went unnoticed until Brian tried installing dash on a
thin client with manpages removed.
Reported-by: Brian Potkin claremont...@gmail.com
---
Brian Potkin wrote:
I have Lenny on a thin client with a limited amount of disk space. All
documentation has been removed. The upgrade to Squeeze stops with
cp: cannot stat '/usr/share/man/man1/sh.1.gz': No such file or directory
dpkg: error processing /var/cache/apt/archives/dash_0.5.5.1-7.3_i386.deb
(--unpack):
Thanks for reporting. This is a bad one.
debian/changelog|8
debian/dash.preinst |4 +++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 2ba356f..437f0de 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dash (0.5.5.1-7.4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * dash.preinst: Do not error out if /bin/sh or its manpage is
+not already present (thx Brian Potkin; closes: #606756).
+
+ -- Jonathan Nieder jrnie...@gmail.com Sat, 11 Dec 2010 22:15:46 -0600
+
dash (0.5.5.1-7.3) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/dash.preinst b/debian/dash.preinst
index 324ec85..5529af7 100644
--- a/debian/dash.preinst
+++ b/debian/dash.preinst
@@ -15,7 +15,9 @@ divert() {
# intermediate temporary file as ln -sf is not atomic.
# dpkg-divert's --rename direct equivalent would be:
# mv $dfile $distrib -- but we could end up without a symlink
- cp -dp $dfile $distrib
+ if [ -e $dfile ]; then
+ cp -dp $dfile $distrib
+ fi
ln -sf $ltarget $temp
mv -f $temp $dfile
dpkg-divert --package dash --divert $distrib --add $dfile
--
1.7.2.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606078: ExtUtils::MakeMaker: generated makefile can't cope with perl upgrade
Niko Tyni wrote: Yeah, that probably works. However, EU::MM upstream needs to be very careful about portability issues and the like. Looking at the FORCE target, I suspect $(CONFIGDEP) : $(NOECHO) $(NOOP) is the right way to do this. I'm generally not very enthusiastic about changing ExtUtils::MakeMaker; getting things upstreamed properly needs more portability care and testing than I'm comfortable with Thanks for a thorough response. I'll try to find time to pursue this upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606839: dpkg-buildflags: please provide a makefile snippet to set all build flags
Package: dpkg-dev Version: 1.15.9 Severity: wishlist Hi, As mentioned at [1], using dpkg-buildflags --export from a makefile is more trouble than one might like. It would be simpler to do something closer to the current thing: CFLAGS := $(shell dpkg-buildflags --get CFLAGS) CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) FFLAGS := $(shell dpkg-buildflags --get FFLAGS) LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS) export CFLAGS CPPFLAGS CXXFLAGS FFLAGS LDFLAGS except that the dpkg-buildflags documentation suggests this list is not necessarily exhaustive. Would it make sense to provide a /usr/share/dpkg/buildflags.mk for makefiles to include that would expand to incorporate whatever flags are supported at a given moment? This would be closer to the usability of the idea Manoj and some others advocated last year[2]. Jonathan [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=603435 [2] http://lists.debian.org/debian-devel/2009/05/msg00044.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608247: dpkg-architecture is slow
Package: dpkg-dev Version: 1.15.9 Severity: wishlist Thorsten Glaser wrote: dpkg-architecture appears to be called rather often. It’s slow though… r...@ara0:~/T # time dpkg-architecture DEB_BUILD_ARCH=m68k [...] 0m7.49s real 0m2.97s user 0m4.02s system The system is otherwise idle, and it’s the second call, so hot cache. r...@ara0:~/T # cat /proc/cpuinfo CPU:68040 [...] Debian unstable. Other tools might be similar. dpkg-parsechangelog is also about 3 seconds too slow in my experience. I am guessing (but have not checked) that most of the time is spent loading Dpkg::* modules. Any hints for diagnosing this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600566: Intent to NMU for v1.7.4-rc0
Sedat Dilek wrote: On Thu, Dec 30, 2010 at 1:16 PM, Jonathan Nieder jrnie...@gmail.com wrote: Let's try that again. Sorry about that. Is that the latest (fixed) version of git-1.7.4-rc0 in [1]? - Sedat - [1] http://mentors.debian.net/debian/pool/main/g/git/ Yes. The first diff I sent was broken (it just deleted the debian/ directory) but the package should be fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608449: grub-pc: infinite debconf prompt loop (10 which devices? 20 continue without installing? 30 goto 10)
Package: grub-pc
Version: 1.98+20100804-11
Severity: grave
Justification: breaks upgrade
Stock squeeze system. Upgrading grub-pc, I am asked:
| # You are using the editor-based debconf frontend to configure
| # your system. See the end of this document for detailed
| # instructions.
| ###
| # The grub-pc package is being upgraded. This menu allows you to
| # select which devices you'd like grub-install to be
| # automatically run for, if any.
[...]
| # (Choices: /dev/sda (6448 MB, WDC_WD64AA), - /dev/sda1 (254 MB,
| # /boot), /dev/dm-0 (5867 MB, copier-root))
| # (Enter zero or more items separated by a comma followed by a space
| # (', ').)
| # GRUB install devices:
| grub-pc/install_devices=
I answer /dev/sda (6448 MB, WDC_WD64AA) and receive an odd response:
| # You chose not to install GRUB to any devices.
[...]
| # (Choices: yes, no)
| # Continue without installing GRUB?
| grub-pc/install_devices_empty=no
Of course not. I don't want a broken system! And back to the first
question.
Problems:
- It looks like the splitting on comma for grub-pc/install_devices
is broken, at least with the debconf editor frontend. Maybe
another delimiter would work better?
old_devices=$(echo $RET | sed 's/, / /g')
- No error response for typos --- the malformed resulting old_devices
seems to just result in install_devices= or something.
- Infinite loop with no escape! What if I just want to use the old
version of grub-pc, which worked? I tried exiting vi with :cq but
that leaves me in the same loop.
Bugscript output attached.
Ideas?
Jonathan
/var/lib/x11/X.roster does not exist.
/var/lib/x11/X.md5sum does not exist.
X server symlink status:
lrwxrwxrwx 1 root root 13 Jun 10 10:56 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1733468 Nov 11 18:27 /usr/bin/Xorg
/var/lib/x11/xorg.conf.roster does not exist.
VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200
64M] (rev a1)
/var/lib/x11/xorg.conf.md5sum does not exist.
Xorg X server configuration file status:
-rw-rw-r-- 1 root root 93 Jun 13 12:11 /etc/X11/xorg.conf
Contents of /etc/X11/xorg.conf:
Section Device
Identifier geforce
Driver nouveau
# Driver nv
EndSection
Kernel version (/proc/version):
Linux version 2.6.37-rc3 (j...@burratino) (gcc version 4.5.1 (Debian 4.5.1-11)
) #5 SMP Tue Nov 23 16:16:04 CST 2010
Xorg X server log files on system:
-rw-r--r-- 1 root root 40807 Aug 12 18:50 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 26667 Nov 26 11:53 /var/log/Xorg.0.log
Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:
X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32.25-dsa-ia32 i686 Debian
Current Operating System: Linux burratino 2.6.37-rc3 #5 SMP Tue Nov 23 16:16:04
CST 2010 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37-rc3
root=/dev/mapper/data-rootfs ro quiet
Build Date: 12 November 2010 12:21:56AM
xorg-server 2:1.7.7-9 (Julien Cristau jcris...@debian.org)
Current version of pixman: 0.21.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Thu Nov 25 10:08:22 2010
(==) Using config file: /etc/X11/xorg.conf
(==) Using system config directory /usr/share/X11/xorg.conf.d
(==) No Layout section. Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |--Screen Default Screen Section (0)
(**) | |--Monitor default monitor
(==) No device specified for screen Default Screen Section.
Using the first device section listed.
(**) | |--Device geforce
(==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/75dpi does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
(==) ModulePath set to /usr/lib/xorg/modules
(II) The server relies on udev to provide the list of input devices.
If no devices become
Bug#608449: grub-pc: infinite debconf prompt loop (10 which devices? 20 continue without installing? 30 goto 10)
Jonathan Nieder wrote:
Bugscript output attached.
Not my best day for attachments. Here's the actual bugscript
result.
*** BEGIN /proc/mounts
/dev/mapper/copier-root / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-WDC_WD64AA_WD-WM6531015187
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod lvm
insmod part_msdos
insmod ext2
set root='(copier-root)'
search --no-floppy --fs-uuid --set 9cbd61d7-4435-42bb-aec7-d96b5549c552
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
set locale_dir=($root)/grub/locale
set lang=en
insmod gettext
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class debian --class
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.32-5-686 ...'
linux /vmlinuz-2.6.32-5-686 root=/dev/mapper/copier-root ro quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-686
}
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686 (recovery mode)' --class
debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.32-5-686 ...'
linux /vmlinuz-2.6.32-5-686 root=/dev/mapper/copier-root ro single
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-686
}
menuentry 'Debian GNU/Linux, with Linux 2.6.30-2-686' --class debian --class
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.30-2-686 ...'
linux /vmlinuz-2.6.30-2-686 root=/dev/mapper/copier-root ro quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.30-2-686
}
menuentry 'Debian GNU/Linux, with Linux 2.6.30-2-686 (recovery mode)' --class
debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.30-2-686 ...'
linux /vmlinuz-2.6.30-2-686 root=/dev/mapper/copier-root ro single
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.30-2-686
}
menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-686' --class debian --class
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.26-2-686 ...'
linux /vmlinuz-2.6.26-2-686 root=/dev/mapper/copier-root ro quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.26-2-686
}
menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-686 (recovery mode)' --class
debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set feff847d-60df-4d91-bd4b-e5dae4b2bb08
echo'Loading Linux 2.6.26-2-686 ...'
linux /vmlinuz-2.6.26-2-686 root=/dev/mapper/copier-root ro single
echo'Loading initial ramdisk ...'
initrd /initrd.img-2.6.26-2-686
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d
Bug#608449: grub-pc: infinite debconf prompt loop (10 which devices? 20 continue without installing? 30 goto 10)
found 608449 grub2/1.98+20100804-10 quit Jonathan Nieder wrote: Version: 1.98+20100804-11 [...] What if I just want to use the old version of grub-pc, which worked? Harder than it sounds. Symptoms are the same with 1.98+20100804-10 (even though I had successfully installed it before!). After downgrading lvm, libdevmapper, and grub-pc 1.98~20091210-1, I get: | /usr/sbin/grub-probe: error: cannot find a device for /. | | dpkg: error processing grub-pc (--configure): Even after a reboot grub-probe does not work. Rebuilding /boot/grub/device.map with grub-pc 1.98~20091210-1 gives (fd0) /dev/fd0 (hd0) /dev/sda Luckily grub-legacy is installed to /dev/sda and chainbooting works. I'm out of ideas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608022: [PATCH v2 0/2] Recommend against direct upgrades from releases older than lenny
Adam D. Barratt wrote: On Thu, 2010-12-30 at 20:35 +0100, Julien Cristau wrote: [Subject: Recommend against direct upgrades from releases older than lenny] Bug#608022 Thanks for this. For what it's worth, Acked-by: Jonathan Nieder jrnie...@gmail.com [...] --- a/en/upgrading.dbk +++ b/en/upgrading.dbk @@ -277,6 +277,12 @@ upgrade process, you may wish to remove third-party packages from your system before you begin upgrading. /para para +Direct upgrades from Debian releases older than oldrelease; are not supported. Do we want oldrelease; or oldreleasename; here? (Likewise below) I'd say 5.0 (lenny) here, 5.0 below. +Please follow the instructions in the ulink +url=http://www.debian.org/releases/oldreleasename;/releasenotes;Release +notes for debian; oldrelease;/ulink to upgrade to oldrelease; first. Release Notes. :-) Yes, good catch. A patch with that fix incorporated follows, followed by Osamu's suggestion for the chapter title. Jonathan Nieder (1): Clarify 'upgrading' chapter title Julien Cristau (1): Recommend against direct upgrades from releases older than lenny en/upgrading.dbk |9 - 1 files changed, 8 insertions(+), 1 deletions(-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608022: [PATCH v2 1/2] Recommend against direct upgrades from releases older than lenny
From: Julien Cristau jcris...@debian.org The introductory chapter already mentions that skipping a major release is not supported but it is easy to miss. Repeat the advice in the Upgrades chapter. Fixes: http://bugs.debian.org/608022 Requested-by: Witold Baryluk bary...@smp.if.uj.edu.pl Signed-off-by: Julien Cristau jcris...@debian.org Acked-by: Adam D. Barratt a...@adam-barratt.org.uk Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Adam, I carried over your ack; I hope that's okay. en/upgrading.dbk |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/en/upgrading.dbk b/en/upgrading.dbk index 06fc6a8..2f70883 100644 --- a/en/upgrading.dbk +++ b/en/upgrading.dbk @@ -277,6 +277,13 @@ upgrade process, you may wish to remove third-party packages from your system before you begin upgrading. /para +para +Direct upgrades from Debian releases older than oldrelease; (oldreleasename;) +are not supported. +Please follow the instructions in the ulink +url=http://www.debian.org/releases/oldreleasename;/releasenotes;Release +Notes for debian; oldrelease;/ulink to upgrade to oldrelease; first. +/para para This procedure also assumes your system has been updated to the latest point release of oldreleasename;. If you have not done this or are unsure, follow the instructions in xref linkend=old-upgrade/. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608022: [PATCH 2/2] Clarify 'upgrading' chapter title
This chapter is about upgrades from lenny, not from previous releases in general, Title suggested by Osamu Aoki os...@debian.org. Requested-by: Witold Baryluk bary...@smp.if.uj.edu.pl Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- en/upgrading.dbk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/en/upgrading.dbk b/en/upgrading.dbk index 2f70883..5146ff5 100644 --- a/en/upgrading.dbk +++ b/en/upgrading.dbk @@ -5,7 +5,7 @@ ] chapter id=ch-upgrading lang=en -titleUpgrades from previous releases/title +titleUpgrades from Debian oldrelease; (oldreleasename;)/title section id=backup titlePreparing for the upgrade/title para -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608471: www.debian.org: Installation Guide and d-i errata pages should be release-specific
Package: www.debian.org Version: 20101231 Severity: wishlist The intro to section 3 Installation system of the release notes contains cross references to the installation guide[1] and errata[2]: [1] http://www.debian.org/releases/stable/debian-installer/ [2] http://www.debian.org/releases/stable/debian-installer/index#errata URLs with releasename; instead of stable would be much better, especially to avoid confusion when release notes are used by testers before the release becomes stable. In that vein, would it be possible to put up the development version of the installation guide[1] and errata[2] up under releases/squeeze/? [1] http://d-i.alioth.debian.org/manual/ [2] http://www.debian.org/devel/debian-installer/errata Currently http://www.debian.org/releases/squeeze/debian-installer/ gives error 404. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608474: release-notes: Installation Guide and d-i errata links should be release-specific
Package: release-notes Severity: minor The intro to section 3 Installation system of the release notes contains cross references to the installation guide[1] and errata[2]: [1] http://www.debian.org/releases/stable/debian-installer/ [2] http://www.debian.org/releases/stable/debian-installer/index#errata URLs with releasename; instead of stable would be much better, especially to avoid confusion when release notes are used by testers before the release becomes stable. Well, that can't happen until [3] has content (see [4]). Please ignore this report until that happens. [3] http://www.debian.org/releases/squeeze/debian-installer/ [4] http://bugs.debian.org/608471 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515312: release-notes: Correct spelling of codename: lenny
Osamu Aoki wrote: I know it is correct to spell proper names capitalized as Lenny in the proper English grammar. But I still think Lenny in Release notes should have been lenny if we follow recent historic usages. Here is the fact about recent news: February 14th, 2009 Debian GNU/Linux version 5.0 (codenamed Lenny) April 8th, 2007 Debian GNU/Linux 4.0 (codename etch) June 6th, 2005 Debian GNU/Linux 3.1 (codename `sarge') July 19th, 2002 Debian GNU/Linux 3.0 (`woody') (Release Notes) August 15th, 2000 Debian GNU/Linux 2.2 (codename `potato') (Release Notes) December 15th, 1999 Debian GNU/Linux 2.1 release (aka slink) July 24th, 1998 Debian GNU/Linux 2.0 'Hamm' Released June 2nd, 1997 Debian 1.3 Released (no mention of bo in news) Only Hamm used capitalization! At http://www.debian.org/releases/lenny/i386/release-notes/ I see Release Notes for Debian GNU/Linux 5.0 (lenny), Intel x86 although throughout the release notes both lenny (releasename;) and Lenny (Releasename;) were used. In the trunk (squeeze) release notes I find: I. en/issues.dbk: -Due to an unfortunate interaction of a kernel fix with PCI Express :subsystem, Lenny default kernel will fail to boot on Sparc -workstations with PCI Express slots, like Ultra 25 and Ultra which is probably out of date; II. en/release-notes.dbk: - firstnameChristian/firstname - surnamePerrier/surname : contribLenny installation/contrib (and similar), which do not form part of the output; III. Nextreleasename; etc in some translations, which presumably have their own rules. Is there something left to fix? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608486: release notes §4.6.1 (expected removals): grub-legacy
Package: release-notes Tags: squeeze Hi grub maintainers, grub-pc 1.98+20100527-1 and later conflict with grub-legacy. grub 0.97-58 and later depend on grub-pc. Therefore upgrades from lenny with grub installed result in grub-legacy being removed, as planned. Is this worth a mention in the expected removals section[1] or obsolete packages section? Advice (precautions) for users upgrading? Pitfalls? [Thanks for keeping grub working well. I'm a big fan.] [1] http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.html#expected-removals -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499002: [PATCH git] debian: do not build documentation on buildds (Re: Intent to NMU for v1.7.4-rc0)
Thorsten Glaser wrote: I wonder though, why is the BUILD_DOCS, install-indep-real, etc. necessary, shouldn’t dpkg-buildpackage just call binary-arch and that be it? Background: see [1] [2] which seem to be blocked on [3]. sbuild and dpkg-buildpackage call 'debian/rules build', not 'debian/rules build-arch', for lack of a facility in 'make' to check if a target exists. Anyone who can nudge [3] along (by testing? by code review?) would be my hero. Well, that doesn't answer your question completely. Why doesn't sbuild just call binary-arch directly? To do so would be to run all build commands as (fake) root, which * is less robust (a broken build can wreak more havok) * can trigger bugs like [4] * is marginally slower in the fakeroot case git commit fb4f7069 (debian: do not build documentation on buildds, 2010-12-29) doesn't move documentation processing out of 'build' and into 'binary-indep' for similar reasons, plus * using a _minimal_ workaround like the current one makes it more likely that the package can return to sanity once [1] is fixed So much for BUILD_DOCS. install-indep-real, on the other hand, is just laziness on my part. After f9ddaa0d (debian/implicit: add proper dependencies to support 'parallel build' through make -j, 2007-11-07), the rules in debian/implicit include some dependencies on the 'install' target and I do not want to detangle them yet. I ought to have explained this in the commit log. Sorry about that. Jonathan [1] http://bugs.debian.org/478524 [2] http://bugs.debian.org/229357 [3] http://bugs.debian.org/598534 [4] http://bugs.debian.org/524309 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608449: grub-pc: infinite debconf prompt loop (10 which devices? 20 continue without installing? 30 goto 10)
Colin Watson wrote: Would it be possible to get a log with DEBCONF_DEBUG=developer set in the environment, to confirm exactly what's going on here? Gladly. | # cupt install grub-pc | Building the package cache... [done] | Initializing package resolver and worker... [done] | Scheduling requested actions... [done] | Resolving possible unmet dependencies... | The following 1 packages will be INSTALLED: | | grub-pc | | The following 1 packages will be REMOVED: | | grub-legacy | | Need to get 0B/996KiB of archives. After unpacking 1684KiB will be used. | Do you want to continue? [y/N/q] y | | Performing requested actions: | Preconfiguring packages ... | debconf (developer): starting /tmp/grub-pc.config.89471 configure | debconf (developer): -- SET grub2/linux_cmdline | debconf (developer): -- 0 value set | debconf (developer): -- SET grub2/linux_cmdline_default quiet | debconf (developer): -- 0 value set | debconf (developer): -- INPUT high grub2/linux_cmdline | debconf (developer): -- 30 question skipped | debconf (developer): -- INPUT medium grub2/linux_cmdline_default | debconf (developer): -- 30 question skipped | debconf (developer): -- GO | debconf (developer): -- 0 ok | (Reading database ... 54629 files and directories currently installed.) | Removing grub-legacy ... | Processing triggers for man-db ... | debconf (developer): frontend started | debconf (developer): frontend running, package name is man-db | debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man | debconf (developer): -- VERSION 2.0 | debconf (developer): -- 0 2.0 | debconf (developer): -- INPUT medium man-db/install-setuid | debconf (developer): -- 30 question skipped | debconf (developer): -- GO | debconf (developer): -- 0 ok | debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man | debconf (developer): -- VERSION 2.0 | debconf (developer): -- 0 2.0 | debconf (developer): -- GET man-db/auto-update | debconf (developer): -- 0 true | Selecting previously deselected package grub-pc. | (Reading database ... 54583 files and directories currently installed.) | Unpacking grub-pc (from .../grub-pc_1.98+20100804-11_i386.deb) ... | Processing triggers for man-db ... | debconf (developer): frontend started | debconf (developer): frontend running, package name is man-db | debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man | debconf (developer): -- VERSION 2.0 | debconf (developer): -- 0 2.0 | debconf (developer): -- INPUT medium man-db/install-setuid | debconf (developer): -- 30 question skipped | debconf (developer): -- GO | debconf (developer): -- 0 ok | debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man | debconf (developer): -- VERSION 2.0 | debconf (developer): -- 0 2.0 | debconf (developer): -- GET man-db/auto-update | debconf (developer): -- 0 true | Setting up grub-pc (1.98+20100804-11) ... | Installing new version of config file /etc/grub.d/05_debian_theme ... | debconf (developer): frontend started | debconf (developer): frontend running, package name is grub-pc | debconf (developer): starting /var/lib/dpkg/info/grub-pc.config configure 1.98+20100804-10 | debconf (developer): -- SET grub2/linux_cmdline | debconf (developer): -- 0 value set | debconf (developer): -- SET grub2/linux_cmdline_default quiet | debconf (developer): -- 0 value set | debconf (developer): -- INPUT high grub2/linux_cmdline | debconf (developer): -- 30 question skipped | debconf (developer): -- INPUT medium grub2/linux_cmdline_default | debconf (developer): -- 30 question skipped | debconf (developer): -- GO | debconf (developer): -- 0 ok | debconf (developer): starting /var/lib/dpkg/info/grub-pc.postinst configure 1.98+20100804-10 | debconf (developer): -- GET grub2/linux_cmdline | debconf (developer): -- 0 | debconf (developer): -- GET grub2/linux_cmdline_default | debconf (developer): -- 0 quiet | debconf (developer): -- X_LOADTEMPLATEFILE /var/lib/dpkg/info/ucf.templates ucf | debconf (developer): -- 0 | Replacing config file /etc/default/grub with new version | debconf (developer): -- GET grub-pc/install_devices | debconf (developer): -- 0 | debconf (developer): -- SUBST grub-pc/disk_description DEVICE /dev/sda | debconf (developer): -- 0 | debconf (developer): -- SUBST grub-pc/disk_description SIZE 6448 | debconf (developer): -- 0 | debconf (developer): -- SUBST grub-pc/disk_description MODEL WDC_WD64AA | debconf (developer): -- 0 | debconf (developer): -- METAGET grub-pc/disk_description description | debconf (developer): -- 0 /dev/sda (6448 MB, WDC_WD64AA) | debconf (developer): -- SUBST grub-pc/partition_description DEVICE /dev/sda1 | debconf (developer): -- 0 | debconf (developer): -- SUBST grub-pc/partition_description SIZE 254 | debconf (developer): -- 0 | debconf (developer): -- SUBST grub-pc/partition_description PATH /boot | debconf (developer): -- 0 | debconf (developer): --
Bug#608536: debconf: editor frontend silently omits invalid values
Package: debconf Version: 1.5.36 Severity: wishlist Colin Watson wrote: On Thu, Dec 30, 2010 at 05:48:53PM -0600, Jonathan Nieder wrote: - No error response for typos --- the malformed resulting old_devices seems to just result in install_devices= or something. That's a debconf bug (or missing feature). Debconf::Editor::Multiselect::value just greps out invalid values. Thanks. I agree, the debconf editor frontend could (and should) take care of reporting invalid values and asking the user to fix them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608539: clang -ftrapv: UNREACHABLE on 64-bit off_t addition
Package: clang
Version: 2.7-3
$ cat csum-file.c
#define _FILE_OFFSET_BITS 64
#include sys/types.h
extern ssize_t xwrite(void);
void flush(off_t *total)
{
*total += xwrite();
}
$ clang -c csum-file.c
$ clang -ftrapv -c csum-file.c
UNREACHABLE executed!
0 clang 0x08dc6ac8
Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -S
-disable-free -disable-llvm-verifier -main-file-name csum-file.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -resource-dir /usr/lib/clang/1.1 -fmessage-length 0 -ftrapv
-fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-4ZBHFy.s -x c csum-file.c
1. eof parser at end of file
2. Code generation
3. Running pass 'X86 DAG-DAG Instruction Selection' on function '@flush'
clang: error: compiler command failed due to signal 6 (use -v to see invocation)
Ideas?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608621: ogg123: Assertion 'p' failed at pulse/simple.c:384, function pa_simple_drain()
Package: vorbis-tools
Version: 1.4.0-1
Using ogg123 to play through pulseaudio consistently segfaults
for me.
$ gdb --args ogg123 -d pulse TWID_001.ogg; # This week in Debian, #1
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/ogg123...Reading symbols from
/usr/lib/debug/usr/bin/ogg123...done.
done.
(gdb) run
Starting program: /usr/bin/ogg123 -d pulse TWID_001.ogg
[Thread debugging using libthread_db enabled]
Audio Device: PulseAudio Output
[New Thread 0xb714fb70 (LWP 5986)]
Playing: TWID_001.ogg
Ogg Vorbis stream: 2 channel, 44100 Hz
Description: audiotest wave
[New Thread 0xb2946b70 (LWP 5987)]
[New Thread 0xb2145b70 (LWP 5988)]
[New Thread 0xb1944b70 (LWP 5989)]
[Thread 0xb2946b70 (LWP 5987) exited]
[Thread 0xb1944b70 (LWP 5989) exited]
[Thread 0xb2145b70 (LWP 5988) exited]
Assertion 'p' failed at pulse/simple.c:384, function pa_simple_drain().
Aborting.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb714fb70 (LWP 5986)]
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb7d6a751 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7d6db82 in abort () at abort.c:92
#3 0xb7fd5c87 in pa_simple_drain () from /usr/lib/libpulse-simple.so.0
#4 0xb7fd8b67 in ao_plugin_close () from /usr/lib/ao/plugins-4/libpulse.so
#5 0xb7f9b80c in ao_close () from /usr/lib/libao.so.4
#6 0xb7f9cd13 in ?? () from /usr/lib/libao.so.4
#7 0x0804ca47 in audio_reopen_action (buf=0xb7151008, arg=0x808cea8) at
callbacks.c:65
#8 0x0804b150 in execute_actions (buf=0xb7151008, action_list=0xb71510c4,
position=0) at buffer.c:154
#9 0x0804c3ef in buffer_thread_func (arg=0xb7151008) at buffer.c:237
#10 0xb7f1f955 in start_thread (arg=0xb714fb70) at pthread_create.c:300
#11 0xb7e0be7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) bt full
#0 0xb7fe2424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7d6a751 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = value optimized out
pid = -1209524236
selftid = 5986
#2 0xb7d6db82 in abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4},
sa_mask = {__val = {3071602712,
3084582028, 1633839468, 3087003636, 3086590748, 3, 3071602844,
3086925606, 3071602744, 3084595560,
134812416, 3071602831, 4, 3086620008, 1, 134812456, 3071603112,
3086590824, 3086989148, 3071602788,
1, 10, 3086591544, 134669604, 1174141162, 3071602831, 61,
3086622720, 0, 0, 5, 45}}, sa_flags = 0,
sa_restorer = 0xb7fa2000}
sigs = {__val = {32, 0 repeats 31 times}}
#3 0xb7fd5c87 in pa_simple_drain () from /usr/lib/libpulse-simple.so.0
No symbol table info available.
#4 0xb7fd8b67 in ao_plugin_close () from /usr/lib/ao/plugins-4/libpulse.so
No symbol table info available.
#5 0xb7f9b80c in ao_close () from /usr/lib/libao.so.4
No symbol table info available.
#6 0xb7f9cd13 in ?? () from /usr/lib/libao.so.4
No symbol table info available.
#7 0x0804ca47 in audio_reopen_action (buf=0xb7151008, arg=0x808cea8) at
callbacks.c:65
info = 0x0
current = 0xb7fda778
format = {bits = 16, rate = 44100, channels = 2, byte_format = 1,
matrix = 0x808ce98 L,R}
#8 0x0804b150 in execute_actions (buf=0xb7151008, action_list=0xb71510c4,
position=0) at buffer.c:154
No locals.
#9 0x0804c3ef in buffer_thread_func (arg=0xb7151008) at buffer.c:237
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {-1208811532,
-1223361680, 4001536, -1223363720,
-141991790, -672156180}, __mask_was_saved = 0}}, __pad =
{0xb714f434, 0x0, 0xb7f1c224, 0x16088}}
not_first_call = value optimized out
buf = 0xb7151008
write_amount = value optimized out
#10 0xb7f1f955 in start_thread (arg=0xb714fb70) at pthread_create.c:300
__res = value optimized out
__ignore1 = value optimized out
__ignore2 = value optimized out
pd = 0xb714fb70
now = value optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1208811532, 0, 4001536,
-1223363464, -141844334, 1033816723},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data =
{prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
---Type return to continue, or q return to quit---
not_first_call = value optimized out
freesize = value optimized out
__PRETTY_FUNCTION__ = start_thread
#11 0xb7e0be7e in clone () at
Bug#608624: testparm.samba3: unexplained warning rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Package: samba-common-bin Version: 2:3.5.6~dfsg-3 Severity: minor Justification: cosmetic Stock squeeze system. /etc/samba/smb.conf as below. Running testparm, I get a worrying message (the following is censored a bit): $ testparm Load smb config files from /etc/samba/smb.conf rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) Processing section [sharedfiles] Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions [global] workgroup = SOMETHINGINALLCAPS server string = Someone's Computer ; disable guest by mapping to nonexistent user. map to guest = Bad User syslog = 0 log file = /var/log/samba/log.machine max log size = 1000 panic action = /usr/share/samba/panic-action %d [sharedfiles] comment = Shared files path = /var/local/shared-files username = sharedfiles valid users = sharedfiles read only = No $ echo $? 0 Should one be worried about the rlimit_max comment? If there is anything I can do to help track this down, I'd be glad to hear it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608624: testparm.samba3: unexplained warning rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Christian PERRIER wrote: Quoting Jonathan Nieder (jrnie...@gmail.com): $ testparm Load smb config files from /etc/samba/smb.conf rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) [...] Should one be worried about the rlimit_max comment? If there is anything I can do to help track this down, I'd be glad to hear it. http://www.mail-archive.com/samba@lists.samba.org/msg105543.html Thanks! Here is the comment for reference: | It's a warning, you can safely ignore it. Windows 7 clients need to | have exactly the same number of open handles available as Windows | servers, else it fails in some file copy situations with a out of | handles message. Samba has taken care of it for you, but it's just | letting you know your fd limit is set a bit low. I believe this is at least a documentation bug, as evidenced by the countless worried questions you can find online. IMHO the warning should just be suppressed (or the default fd limit increased if it is actually something the user needs to worry about). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608624: testparm.samba3: unexplained warning rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
tags 608624 + upstream
quit
Christian PERRIER wrote:
Maybe...but that should rather be discussed directly with upstream,
imho. Not sure I'll have the motivation to play proxy, here..:)
I wrote the following to sa...@lists.samba.org as a reply to
20100125175026.gc23...@samba1. Copying here because I am not sure
if it was delivered correctly to that members-only list. I haven't
tried filing an upstream bug yet because as you noted it is not cut
and dried what the best fix is.
Jeremy Allison wrote:
On Mon, Jan 25, 2010 at 11:44:03AM +, Miguel Medalha wrote:
rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)
I searched Google for some answer but I couldn't find a satisfactory
one. What should I do to solve this?
[...]
It's a warning, you can safely ignore it. Windows 7 clients need to
have exactly the same number of open handles available as Windows
servers, else it fails in some file copy situations with a out of
handles message. Samba has taken care of it for you, but it's just
letting you know your fd limit is set a bit low.
Uninformed reaction: is it useful to let the user know? Does setting
the fd limit higher result in better behavior, or does the automatic
increase have results that would be counterintuitive if not mentioned?
If the former, maybe the default rlimit_max should be increased
(on Debian squeeze it seems to be 1024 fwiw). If the latter, I think
the message should say
rlimit_max: rlimit_max (8192) increased to minimum Windows limit (16384)
to be more informative and sound less like a warning. Like this,
maybe (untested).
-- 8 --
Subject: s3-param: Make rlimit_max below minimum Windows limit notification
less scary
The fix to bug #6837 results in messages from testparm that look
like a misconfiguration even though they aren't:
rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)
Apply a slight change in wording (increasing rlimit_max to minimum
Windows limit) to make it clearer that the user has done nothing
wrong. (Similarly for sysctl_max.)
Reported-by: Miguel Medalha miguelmeda...@sapo.pt
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
source3/param/loadparm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/source3/param/loadparm.c b/source3/param/loadparm.c
index 2f68f00..bda20d8 100644
--- a/source3/param/loadparm.c
+++ b/source3/param/loadparm.c
@@ -4898,7 +4898,7 @@ static int max_open_files(void)
#endif
if (sysctl_max MIN_OPEN_FILES_WINDOWS) {
- DEBUG(2,(max_open_files: sysctl_max (%d) below
+ DEBUG(2,(max_open_files: increasing sysctl_max (%d) to
minimum Windows limit (%d)\n,
sysctl_max,
MIN_OPEN_FILES_WINDOWS));
@@ -4906,7 +4906,7 @@ static int max_open_files(void)
}
if (rlimit_max MIN_OPEN_FILES_WINDOWS) {
- DEBUG(2,(rlimit_max: rlimit_max (%d) below
+ DEBUG(2,(rlimit_max: increasing rlimit_max (%d) to
minimum Windows limit (%d)\n,
rlimit_max,
MIN_OPEN_FILES_WINDOWS));
--
1.7.4.rc0
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607193: document various download options/locations for Squeeze CD images
Hi, Matthew Stitt wrote: Stefano Zacchiroli wrote: Starting with Debian Squeeze, there will be (more) download options/locations for CD images, be them netinst/complete/etc. In particular, users of specific pieces of hardware will be affected by the choice of images containing (or not) non-free firmware for the Linux kernel. We should document that on the website before the Squeeze release, obviously the prominent links should point to Debian images; links to non-free firmware images should be provided under big fat warnings that they are not part of Debian and supported only to the extent that not having their source code permits. Maybe, a link to the announcement text of today (http://www.debian.org/News/2010/20101215) can be provided too? I would like to help but don't know how to get started. Is there anything specific I could work on for the Squeeze team? I think http://www.debian.org/CD and particularly http://www.debian.org/CD/jigdo-cd/ would be the first pages that need updating. Perhaps someone on the debian-cd team (bcc-ed) would know where to find the images to link to? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608624: testparm.samba3: unexplained warning rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Steve Langasek wrote: At minimum, the debug message should be cleaned up to state *what* rlimit is too low; the current message mentions nothing about file descriptors. Unfortunately I am not familiar enough with the surrounding context to write something better. Otherwise, I'm not overly concerned about this. Nowadays, the default log level is '0', isn't it? So only users who have manually adjusted the smb.conf 'log level' setting would be seeing this warning. FWIW the smb.conf that prompted this report does not contain a 'log level' setting. # Run “testparm” to check for syntax erros. [global] workgroup = X netbios name = X server string = X security = user encrypt passwords = true passdb backend = tdbsam log file = /var/log/samba/log.machine max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d usershare max shares = 100 # printing = cups [onset] comment = X read only = no path = X guest ok = no username = X valid users = X ; preexec = /bin/mount XX ; postexec = /bin/umount X That's it (25 lines). smb.conf.ucf-dist does not seem to mention a log level, either. Maybe I have missed some other config file or that is the bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608624: testparm.samba3: unexplained warning rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
forwarded 608624 https://bugzilla.samba.org/show_bug.cgi?id=7898 quit Christian PERRIER wrote: Quoting Jonathan Nieder (jrnie...@gmail.com): I believe this is at least a documentation bug, as evidenced by the countless worried questions you can find online. IMHO the warning should just be suppressed (or the default fd limit increased if it is actually something the user needs to worry about). Maybe...but that should rather be discussed directly with upstream, Reported upstream. I suppose further discussion should happen there. Thanks again for the pointers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607988: python2.6: the latest update is totally broken and can't byte compile *modules*
severity 607988 grave retitle 607988 python: OSError: [Errno 2] byte-compiling packages on upgrade (dangling symlinks) quit dave b wrote: Setting up python (2.6.6-3+squeeze4) ... Linking and byte-compiling packages for runtime python2.6... Traceback (most recent call last): File /usr/bin/pycompile, line 314, in module main() File /usr/bin/pycompile, line 300, in main options.force, options.optimize, e_patterns) File /usr/bin/pycompile, line 196, in compile ftime = os.stat(fn).st_mtime OSError: [Errno 2] No such file or directory: '/usr/lib/python2.6/dist-packages/bzrlib/plugins/gtk/merge.py' Could you send the relevant portion of /var/log/dpkg.log*? More specifically, I am interested to know what version of python-central is installed when python's postinst runs. See also http://bugs.debian.org/552595 (python-central: please remove dangling symlinks at upgrade). Matthias, maybe something like Conflicts: python-central ( 0.6.15) is needed in the python2.[567]-minimal and python packages to ensure a smooth upgrade? Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608829: dpkg-dev - dpkg-source rejects valid patch files
Raphael Hertzog wrote: On Mon, 03 Jan 2011, Bastian Blank wrote: Unified diff files are applied from the start to the end, file by file. There is no notion of duplicate files in it. While such files are valid patch files, diff will never generate such a patch. So it's a sign either of a mistake or of a somewhat manually crafted diff.. I think it's best to be on the safe side and error out. Presumably in this case the patch was taken from upstream (which makes it easier to verify that it is well tested). I suppose that is not too important given tools like interdiff, though. This restriction exists since forever in dpkg-source, it was applied in .diff.gz files and it's thus now also applied on quilt patches. On the other hand, do these concatenated patches break anything? If not, I think it makes sense to accept them; if so, please keep rejecting them. :) Just my two cents. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552121: git-core: misleading error message when trying to push to read-only repo
severity 552121 important tags 552121 + patch quit Eugene V. Lyubimkin wrote: $ git push fatal: The remote end hung up unexpectedly Isn't helpful at all and made me think about server's problem. Sad story: a rough fix for this has been available for months[1] but I dropped the ball and didn't find time to write some test cases. Help would be appreciated. Adjusting severity to make sure this doesn't fall off the radar again. Thanks again for a thoughtful report. Regards, Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/145456/focus=145573 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607988: python2.6: the latest update is totally broken and can't byte compile *modules*
dave b wrote: well it was 1. reportlab and 2. bzr (gtk). Just to confirm, old python-central was not installed when you sent the report, right? What does zgrep 2010-12-2.*python-central /var/log/dpkg.log* say? ii python-central 0.6.16+nmu1 There goes that theory. Alternatively this could be a bug in packages that moved from dh_pycentral to dh_python2 as Sandro suggested. If so, does anyone have a pointer to a page describing what these packages should do to avoid the problem? Sorry for the noise. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608900: xz-utils: Typos in Hungarian package description
tags 608900 + pending quit Hi Gábor, Braun Gábor wrote: In the Hungarian package description please correct the following typos: replace 'tarttalmaz' with 'tartalmaz' in the sentence just before the feature list (a 't' is erronously doubled), replace 'flimseri' with 'felismeri' in the first feature. Fixed (also the list markup was broken). Not sure how long it will take to propagate to http://packages.debian.org/hu/sid/xz-utils and the Translations file. For the future, anyone can fix this kind of thing directly by visiting http://ddtp.debian.net/ddtss/index.cgi/hu Thanks. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608449: grub-pc: infinite debconf prompt loop (10 which devices? 20 continue without installing? 30 goto 10)
Debian Bug Tracking System wrote: * Use semicolons rather than commas to separate size from model in debconf disk and partition descriptions; commas are too easily confused with the multiselect choice separator, and in particular make it impossible to answer questions properly in the editor frontend (closes: #608449). Thanks! 1.98+20100804-13 is working well so far (and in particular configured without trouble). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609049: du: process_file: Assertion `level == prev_level - 1' failed
Package: coreutils Version: 8.5-1 Happy new year. Today I ran $ du -sk ~/* to see where all the space is going. The traversal almost certainly was in ~/src, and being bored, I suspended it to examine that directory: ^Z [1]+ Stopped du -sk ~/* In another terminal I ran cd ~/src du -sk *. ~/src/netbsd was very big, so I moved it (using chmod +w first) to ~/.cache on the same filesystem for future reference. And now time to resume the toplevel search: $ fg du -sk ~/* du: fts_read failed: No such file or directory du: du.c:583: process_file: Assertion `level == prev_level - 1' failed. Aborted (core dumped) Lacking debugging symbols, the core dump does not seem so useful, but I still have it. libc6 is 2.11.2-7, filesystem is ext4, and the kernel is 2.6.37-rc7-686. If there is additional information I could provide, just ask. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609128: git checkout branch behaves differently from what specified in man page
r.ductor wrote: man git-chechout states: Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch. git checkout [branch], git checkout -b new branch [start point] This form switches branches by updating the index, working tree, and HEAD to reflect the specified branch. The key is the meaning of to reflect: a normal (?) human being like me understands that git checkout branch will reset the contents of working directory, and index exactly equal to that of the head of the branch. As you might know this is not true (see example below). Please explain in the man page what checkout is exactly supposed to do. Thanks. Thanks for reporting. Let's take this upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576313: Is /usr/lib/mutt/mailto-mutt still useful?
Hi, Antonio Radici wrote: Wrapper and news entry to be added in mutt/1.5.21-2 (to go to experimental). For reference: | mailto-mutt has been replaced by a wrapper as per #576313, because mutt is now | able to handle the mailto: urls; additionally it will also do some checks on | attachments and it will allow us to be as close to upstream as possible Suppose I am a sysadmin on a large multiuser system out in the middle of nowhere (local network with no reliable Internet connectivity) and received this in my mailbox. What does this mean? /usr/lib/mutt/mailto-mutt was _already_ a wrapper (that's what a script is, right?). What am I supposed to tell my users? Of course that is the worst case and in better cases the user can check what the bug is about. So I assumed you meant: The /usr/lib/mutt/mailto-mutt script has been stripped down to a bare-bones wrapper. Please adjust your MAILER configuration to stop using it, because it will disappear in a later version of Debian. in which case, why use a NEWS entry at all? Usual Debian practice is to warn the sysadmin in release notes for the next release, not NEWS for the current one and to warn users through warnings to stderr. No, that's not it... Maybe: The /usr/lib/mutt/mailto-mutt script used to have a complex implementation but now it has been substantially simplified and rewritten to rely more on standard mutt facilities. Expect minor breakage; we'd be interested in any reports. Does that warrant a NEWS entry either? Now that I've read more carefully it seems what was actually mean is mutt version XYZ crippled its handling of mailto URLs for security reasons. Since /usr/lib/mutt/mailto-mutt is a bare-bones wrapper around mutt, this means that it too is crippled. Any attributes in mailto URLs except for subject and body that should be honored must be explicitly allowed using WXYZ configuration directive. Is that it? Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607498: lintian: detecting multiple lines in a single doc-base file entry
# cosmetic but obnoxious :)
found 607498 doc-base/0.9.5
quit
Russ Allbery wrote:
Aron Xu happyaron...@gmail.com writes:
For example, in fcitx 1:4.0.1-1, the doc-base entry must be like this:
Format: text
Files: /usr/share/doc/fcitx/Develop_Readme /usr/share/doc/fcitx/API.txt.gz
/usr/share/doc/fcitx/pinyin.txt
If I list all three files in three lines, it will result in an
installation error:
Format: text
Files: /usr/share/doc/fcitx/Develop_Readme
/usr/share/doc/fcitx/API.txt.gz
/usr/share/doc/fcitx/pinyin.txt
From perl/Debian/DocBase/Programs/Scrollkeeper.pm, around line 85:
if (defined $omf_category) {
for my $omf_format (@omf_formats) {
$format_data = $doc-GetFormat($omf_format);
next unless defined $format_data;
my $file = defined $$format_data{'index'} ? $$format_data{'index'} :
$$format_data{'files'};
next unless -f $file;
$omf_serial_id = $doc-GetStatus('Scrollkeeper-sid');
#chomp ($omf_serial_id = `$scrollkeeper_gen_seriesid`) unless defined
$omf_serial_id;
$omf_serial_id = _GetUUID() unless $omf_serial_id;
$new_omf_file = _WriteOmfFile($doc, $file,$omf_format,$omf_category,
$omf_serial_id);
$do_update = 1;
last; # register only the first format found
}
}
At this point, for
Files: /foo
/bar
/baz
$$format_data{'files'} would contain /foo\n/bar\n/baz. WriteOmfFile uses
$file
like so:
identifier url=$file/
The OMF documentation[1] explains identifier like so:
A specification of a unique ID by which the resource may be
identified and from which the resource may be retrieved.
(e.g. a URL or URN)
It is optional but presumably the scrollkeeper entry would not be very
useful for yelp without it. But wait --- do the graphical help tools
even use OMF any more? Perhaps we should be targetting rarian
directly?
Separate question: is Text documentation allowed to have an index?
If not, how should one get started in reading some text documentation
listed in /usr/share/doc-base?
Thanks,
Jonathan
[1] http://www.ibiblio.org/osrt/omf/omf_elements
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539855: Jonathan, your issue is #596062
Russell Coker wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596062 The above bug report has the issue that you described, and it's not related to this. So I'm reclosing this one. Thanks. Sorry I did not file a separate bug in the first place (and glad to see this moving forward). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609292: gitweb: http://localhost/w/repo.git/blob_plain/HEAD:path/to/file (PATH_INFO support)
Package: gitweb
Version: 1:1.7.2.3-2.2
Severity: wishlist
Files: /etc/apache2/conf.d/gitweb
Hi,
Ever since git 1.6.6.1, the gitweb package has provided a gitweb
instance at http://localhost/gitweb/ out of the box, which is great.
The URLs it makes are old fashioned, like this:
http://localhost/gitweb/?p=hello.git;a=summary
I would rather use the fancy questionmarkless URLs of the sort
repo.or.cz uses:
http://repo.or.cz/w/hello.git
So I tried by enabling that feature in /etc/gitweb.conf. gitweb's
README informs me that all I need to do is add
$feature{'pathinfo'}{'default'} = [1];
to my gitweb.conf, and if the web server is set up right, the
feature will kick in.
More precisely, setting this up right means
Directory /var/www/gitweb
Options ExecCGI
AddHandler cgi-script cgi
DirectoryIndex gitweb.cgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
/Directory
Would that be reasonable to do this out of the box, or would it break
the non-questionmarkless configuration somehow?
Any advice would be appreciated.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605912: runit: Upgrade failure lenny - squeeze
Adam D. Barratt wrote:
Thanks for looking at this bug. I think the patch you've suggested is
the wrong solution, however.
As runit-run no longer exists after lenny, I think removing the
entire block of code would be a better solution.
I agree.
In terms of the second part of the patch, the package's use of debconf
looks a little odd. There is one template, which says can I signal
init to restart?. Previously, the signalling was performed without
asking, which broke in environments where there was no such process,
such as vservers (see #542593). The implemented solution asks this
question at low priority if an init process is found, and high priority
if not; in both cases the default is yes, which does not seem to make
much sense in the case where it has already been determined that there
is no such process.
I think the idea was to allow installation without starting services
immediately, as requested in #453106. I agree that this is broken
somewhat:
- if debconf is not installed and no init process is present,
postinst fails;
- there should be no debconf prompt at all, not a high priority one,
when no init process is present (as you mentioned).
It's possible that I simply need more coffee, but it may make more sense
to simply rip the debconf use back out, and have the postinst signal
init based simply on the existence of an init process.
Here's a patch ignoring that issue, that just goes after the nominal
subject of the bug (the easy part). Untested.
-- 8 --
Subject: remove vestiges of the runit-run package
Upgrades from lenny are failing because of a missing template
from the runit-run package.
While fixing that, tweak the description, dependencies, and
README.Debian to stop mentioning that now nonexistent package (and use
a Homepage: field in debian/control instead of text pointing to the
web page for simplicity).
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
debian/changelog |7 +++
debian/control | 11 +--
debian/runit.README.Debian |2 +-
debian/runit.config|6 --
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 4c81a83..47130f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+runit (2.1.1-6.1.1) local; urgency=low
+
+ * debian/control, debian/runit.README.Debian, debian/runit.config:
+remove vestiges of the runit-run package (closes: #605912).
+
+ -- Jonathan Nieder jrnie...@gmail.com Sat, 08 Jan 2011 13:39:05 -0600
+
runit (2.1.1-6.1) unstable; urgency=low
* Non-Maintainer Upload.
diff --git a/debian/control b/debian/control
index 2098d2d..e64699c 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,13 @@ Priority: optional
Maintainer: Gerrit Pape p...@smarden.org
Build-Depends: dietlibc-dev ( 0.28-0) [alpha amd64 arm hppa i386 ia64 mips
mipsel powerpc ppc64 s390 sparc], po-debconf
Standards-Version: 3.8.0.1
+Homepage: http://smarden.org/runit/
Package: runit
Architecture: any
Depends: procps, ${shlibs:Depends}
Recommends: fgetty
-Suggests: runit-run, socklog-run
+Suggests: socklog-run
Description: system-wide service supervision
runit is a collection of tools to provide system-wide service supervision
and to manage services. Contrary to sysv init, it not only cares about
@@ -18,8 +19,6 @@ Description: system-wide service supervision
interface to send signals to service daemons without the need for pid-files,
and a log facility with automatic log file rotation and disk space limits.
.
- runit service supervision can run under sysv init, or replace the init
- system completely. Refer to the runit-run package for a complete init
- replacement.
- .
- See http://smarden.org/runit/ for more information.
+ runit service supervision can run under sysv init or replace the init
+ system completely. Complete init replacement requires some manual
+ configuration described in the supplied documentation.
diff --git a/debian/runit.README.Debian b/debian/runit.README.Debian
index 5ffb19e..6249aa9 100644
--- a/debian/runit.README.Debian
+++ b/debian/runit.README.Debian
@@ -7,7 +7,7 @@ service supervision on systems running sysvinit as init scheme.
The package does not replace the /sbin/init program, and so does not
enable runit to run as process no 1. To do so, you need to follow the
-documentation[0] or install the runit-run package.
+documentation[0].
runit's default directory for services is /etc/service/.
diff --git a/debian/runit.config b/debian/runit.config
index f23d62d..e6ed1ba 100644
--- a/debian/runit.config
+++ b/debian/runit.config
@@ -5,12 +5,6 @@ set -e
db_version 2.0
-if test $1 = configure test -n $2
- dpkg --compare-versions $2 le 2.0.0-1; then
- db_fset runit-run/install seen true
- exit 0
-fi
-
if which ps /dev/null 21; then
if ps -p 1 /dev/null; then
db_input low runit/signalinit || :
--
1.7.4.rc1
--
To UNSUBSCRIBE, email to debian
Bug#605912: runit: Upgrade failure lenny - squeeze
Jonathan Nieder wrote:
- if debconf is not installed and no init process is present,
postinst fails;
- there should be no debconf prompt at all, not a high priority one,
when no init process is present (as you mentioned).
... and here is a possible fix for that. postrm is still a bit broken
(it will print an error message if init is not running and does not
respect the user choice expressed in runit/signalinit).
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Still untested.
debian/changelog |2 ++
debian/runit.config |8 ++--
debian/runit.postinst | 14 --
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 47130f4..b478dfb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ runit (2.1.1-6.1.1) local; urgency=low
* debian/control, debian/runit.README.Debian, debian/runit.config:
remove vestiges of the runit-run package (closes: #605912).
+ * debian/runit.config, debian/runit.postinst: do not ask to signal
+init if init is not running.
-- Jonathan Nieder jrnie...@gmail.com Sat, 08 Jan 2011 13:39:05 -0600
diff --git a/debian/runit.config b/debian/runit.config
index e6ed1ba..2183213 100644
--- a/debian/runit.config
+++ b/debian/runit.config
@@ -5,11 +5,7 @@ set -e
db_version 2.0
-if which ps /dev/null 21; then
- if ps -p 1 /dev/null; then
-db_input low runit/signalinit || :
- else
-db_input high runit/signalinit || :
- fi
+if which ps /dev/null 21 ps -p 1 /dev/null; then
+ db_input low runit/signalinit || :
db_go || :
fi
diff --git a/debian/runit.postinst b/debian/runit.postinst
index 377c1ac..a78af57 100644
--- a/debian/runit.postinst
+++ b/debian/runit.postinst
@@ -44,10 +44,12 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
mv -f /etc/inittab'{new}' /etc/inittab
fi
-if test -r /usr/share/debconf/confmodule; then
- . /usr/share/debconf/confmodule
- db_get runit/signalinit
- test $RET = false || kill -s HUP 1
-else
- kill -s HUP 1
+if ps -p 1 /dev/null; then
+ if test -r /usr/share/debconf/confmodule; then
+. /usr/share/debconf/confmodule
+db_get runit/signalinit
+test $RET = false || kill -s HUP 1
+ else
+kill -s HUP 1
+ fi
fi
--
1.7.4.rc1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605912: runit: Upgrade failure lenny - squeeze
Jonathan Nieder wrote:
possible fix for that. postrm is still a bit broken
(it will print an error message if init is not running and does not
respect the user choice expressed in runit/signalinit).
... part 3 is to remove support for the runit/signalinit choice in
squeeze, since (1) it was added after lenny and (2) it is clearly not
cooked yet. If someone wants to revive and help maintain such support
for wheezy, I imagine that would be welcome and appreciated.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Still untested. But maybe it will work now. :)
debian/changelog | 14 ++
debian/control|2 +-
debian/rules | 13 -
debian/runit.config | 11 ---
debian/runit.postinst | 14 +++---
debian/runit.postrm |7 ++-
debian/runit.templates.in | 11 ---
7 files changed, 28 insertions(+), 44 deletions(-)
delete mode 100644 debian/runit.config
delete mode 100644 debian/runit.templates.in
diff --git a/debian/changelog b/debian/changelog
index b478dfb..18bd486 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,14 @@
runit (2.1.1-6.1.1) local; urgency=low
- * debian/control, debian/runit.README.Debian, debian/runit.config:
-remove vestiges of the runit-run package (closes: #605912).
- * debian/runit.config, debian/runit.postinst: do not ask to signal
-init if init is not running.
+ * remove option of suppressing HUP signal to process 1 (because it
+causes upgrade failures: closes: #605912, reopens: #453106).
+- debian/runit.config, debian/runit.templates.in: remove.
+- debian/runit.postinst, debian/runit.postrm: signal process 1 if
+ and only if it is running (thx Adam D. Barratt).
+- debian/rules: remove po-templates rules.
+- debian/control: no longer Build-Depends: po-debconf.
+ * debian/control, debian/runit.README.Debian: remove vestiges of
+the runit-run package.
-- Jonathan Nieder jrnie...@gmail.com Sat, 08 Jan 2011 13:39:05 -0600
diff --git a/debian/control b/debian/control
index e64699c..ef914ec 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: runit
Section: admin
Priority: optional
Maintainer: Gerrit Pape p...@smarden.org
-Build-Depends: dietlibc-dev ( 0.28-0) [alpha amd64 arm hppa i386 ia64 mips
mipsel powerpc ppc64 s390 sparc], po-debconf
+Build-Depends: dietlibc-dev ( 0.28-0) [alpha amd64 arm hppa i386 ia64 mips
mipsel powerpc ppc64 s390 sparc]
Standards-Version: 3.8.0.1
Homepage: http://smarden.org/runit/
diff --git a/debian/rules b/debian/rules
index c1f8c89..7a437c7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,18 +46,13 @@ build-stamp: patch-stamp
(cd runit/ package/compile package/check)
touch build-stamp
-po-templates: po-templates-stamp
-po-templates-stamp: deb-checkdir
- po2debconf debian/runit.templates.in debian/runit.templates
- touch po-templates-stamp
-
clean: deb-checkdir deb-checkuid
rm -rf runit/compile runit/command
test ! -e patch-stamp || \
for i in `ls -1r debian/diff/*.diff || :`; do patch -p1 -R $$i; done
- rm -f patch-stamp build-stamp po-templates-stamp
+ rm -f patch-stamp build-stamp
rm -rf '$(DIR)'
- rm -f debian/files debian/substvars changelog debian/runit.templates
+ rm -f debian/files debian/substvars changelog
test ! -r conf-cc'{orig}' || mv -f conf-cc'{orig}' runit/src/conf-cc
test ! -r conf-ld'{orig}' || mv -f conf-ld'{orig}' runit/src/conf-ld
rm -f runit
@@ -116,7 +111,7 @@ install: deb-checkdir deb-checkuid build-stamp
binary-indep:
-binary-arch: install po-templates runit.deb
+binary-arch: install runit.deb
test '$(CC)' != 'gcc' || \
dpkg-shlibdeps '$(DIR)'/usr/sbin/* '$(DIR)'/usr/bin/*
dpkg-gencontrol -isp -prunit -P'$(DIR)'
@@ -124,6 +119,6 @@ binary-arch: install po-templates runit.deb
binary: binary-indep binary-arch
-.PHONY: patch build po-templates clean install binary-indep binary-arch binary
+.PHONY: patch build clean install binary-indep binary-arch binary
include debian/implicit
diff --git a/debian/runit.config b/debian/runit.config
deleted file mode 100644
index 2183213..000
--- a/debian/runit.config
+++ /dev/null
@@ -1,11 +0,0 @@
-#!/bin/sh
-set -e
-
-. /usr/share/debconf/confmodule
-
-db_version 2.0
-
-if which ps /dev/null 21 ps -p 1 /dev/null; then
- db_input low runit/signalinit || :
- db_go || :
-fi
diff --git a/debian/runit.postinst b/debian/runit.postinst
index a78af57..05816dc 100644
--- a/debian/runit.postinst
+++ b/debian/runit.postinst
@@ -45,11 +45,11 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
fi
if ps -p 1 /dev/null; then
- if test -r /usr/share/debconf/confmodule; then
-. /usr/share/debconf/confmodule
-db_get runit/signalinit
-test $RET = false || kill -s HUP 1
- else
-kill -s HUP 1
- fi
+ kill -s HUP 1
fi
Bug#609405: git-daemon-run: sometimes binds to fewer addresses on restart (does not use SO_REUSEADDR)
Package: git-daemon-run Version: 1:1.7.2.3-2.2 Severity: important Justification: bad behavior, especially re ipv6 support Hi, Was playing around with git-daemon-run to compare it with the proposed sysvinit support. See [1] for the war story. Okay, finished? The upshot is, as ip(7) explains, A TCP local socket address that has been bound is unavailable for some time after closing, unless the SO_REUSEADDR flag has been set. Care should be taken when using this flag as it makes TCP less reliable. More precisely: 1. server closes connection, for example by exiting. 2. kernel places connection in TIME-WAIT state. The address is in use. 3. git-daemon gets EADDRINUSE when it tries to use that address, since the SO_REUSEADDR flag is not set. If all (usually meaning both) addresses to be bound to are in use, the daemon dies with fatal: unable to allocate any listen sockets on port 9418 and gets launched again by runit when an address is free. If only _some_ of the addresses to be bound to are in use in this way, the daemon does not get launched again, and it is bound only to the remaining ones. Analysis: - The ideal would be to disallow connections _from the same client address and port_ until the TIME-WAIT state ends. Is that easy to achieve? - A workaround, even though it violates the spirit of TCP, is to just forget about TIME-WAIT in the case of restarting the daemon. I _suspect_ that this is what the git daemon --reuseaddr flag does but of course it is hard to check. - The fourth best behavior would be to convince git daemon that EADDRINUSE is fatal so runit keeps on trying to relaunch the daemon until all its addresses are available. - Of course better is to run separate daemons for ipv4 and ipv6. Thoughts? Jonathan [1] In one terminal I start the daemon and clear its log: # sv stop git-daemon ok: down: git-daemon: 1s, normally up # sh -c '/var/log/git-daemon/current' # sv start git-daemon ok: run: git-daemon: (pid 6070) 0s Great. Now in another terminal I start a connection: $ git clone git://localhost/git/git.git Cloning into git... remote: Counting objects: 113028, done. Back in the first terminal, I brutally interrupt the daemon, to see how the supervision copes. # killall -9 git-daemon Great, it seems! The clone continues unhindered (I think the process actually transmitting data is git upload-pack). The log informs me that all is well. # cat /var/log/git-daemon/run 2011-01-09_06:29:43.06660 git-daemon starting. 2011-01-09_06:30:01.26329 [6074] Connection from [::1]:33407 2011-01-09_06:30:01.26340 [6074] Extended attributes (16 bytes) exist host=localhost 2011-01-09_06:30:01.26429 [6074] Request upload-pack for '/git/git.git' 2011-01-09_06:30:05.41074 git-daemon starting. Now again. $ rm -fr git; git clone git://localhost/git/git.git Cloning into git... localhost[0: ::1]: errno=Connection refused remote: Counting objects: 19469 Interrupting the daemon: # killall -9 git-daemon The clone continues unhindered. Log: # sudo cat /var/log/git-daemon/current 2011-01-09_06:29:43.06660 git-daemon starting. 2011-01-09_06:30:01.26329 [6074] Connection from [::1]:33407 2011-01-09_06:30:01.26340 [6074] Extended attributes (16 bytes) exist host=localhost 2011-01-09_06:30:01.26429 [6074] Request upload-pack for '/git/git.git' 2011-01-09_06:30:05.41074 git-daemon starting. 2011-01-09_06:31:19.83078 [6091] Connection from 127.0.0.1:39196 2011-01-09_06:31:19.83095 [6091] Extended attributes (16 bytes) exist host=localhost 2011-01-09_06:31:19.83206 [6091] Request upload-pack for '/git/git.git' 2011-01-09_06:31:29.42557 git-daemon starting. 2011-01-09_06:31:29.43869 fatal: unable to allocate any listen sockets on port 9418 2011-01-09_06:31:30.44277 git-daemon starting. 2011-01-09_06:31:30.44796 fatal: unable to allocate any listen sockets on port 9418 [3 more failures before it succeeds] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#455557: GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1
retitle 47 ghostscript: Error: /undefined in eartomark tags 47 + upstream patch fixed-upstream forwarded 47 http://bugs.ghostscript.com/show_bug.cgi?id=689577 fixed 47 ghostscript/8.71~dfsg-1 quit Daniel Leidert wrote: D [10/Dec/2007:22:13:28 +0100] [Job 531] foomatic-gswrapper: gs '-sstdout=%stderr' '@s400a1.upp' '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sOutputFile=%stdout' '-' D [10/Dec/2007:22:13:28 +0100] [Job 531] Copying page 2... D [10/Dec/2007:22:13:28 +0100] [Job 531] pagew = 595.0, pagel = 842.0 D [10/Dec/2007:22:13:28 +0100] [Job 531] bboxw = 595, bboxl = 842 D [10/Dec/2007:22:13:28 +0100] [Job 531] PageLeft = 0.0, PageRight = 595.0 D [10/Dec/2007:22:13:28 +0100] [Job 531] PageTop = 842.0, PageBottom = 0.0 D [10/Dec/2007:22:13:28 +0100] [Job 531] PageWidth = 595.0, PageLength = 842.0 D [10/Dec/2007:22:13:28 +0100] [Job 531] Error: /undefined in eartomark Fixed by r9989, I hope. commit 9e21729c4a5a5011bf6c4ec9d6680ee2c5907094 Author: Alex Cherepanov alex.cherepa...@artifex.com Date: Thu Aug 13 19:04:34 2009 + In hex form of eexec stream, break out of reading loop and try to interpret the accumulated data when a whitespace character is encountered. Skip whitespace characters when the control returns to /eexecDecode filter. Bug 689577. DETAILS: Normally, eexec stream is followed by a large number of 0's to compensate for read-ahead effects. The code fragment that Adobe Acrobat uses to prevent re-distilling of the file has no trailing 0's at all. This patch tries to guess the end of eexec stream after every whitespace character. DIFFERENCES: None. I get several errors (see the subject) at different locations: 1) running dhelps weekly cron-script: /etc/cron.weekly/dhelp: GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1 GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1 2) I also get these errors in CUPS, when I try to print one of the following PDFs: http://rcswww.urz.tu-dresden.de/~bornmann/material/study_text.pdf http://rcswww.urz.tu-dresden.de/~bornmann/material/tud.pdf If you have a chance to try, could you try again with current ghostscript and report back? Thanks for reporting, and sorry for the long delay in responding. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#343901: gs-esp's lx5000 driver runs into infinite loop with mozilla's postscript files
Hi Peter, I was trying to debug an old hang with ghostscript's lx5000 driver and am stuck. [1] has the original report and test file. Sebastian Schmidt wrote: gs produced 94MB output after 10 seconds or so, but what's notable about it is the following (hexdump -C): 05d13f70 00 02 02 00 18 00 ec 19 13 e8 00 00 00 00 2b 70 |..ì..è+p| 05d13f80 62 77 01 1b 2a 03 00 00 1b 2a 04 00 00 00 1a 00 |bw..**..| 05d13f90 02 02 00 18 00 ec 19 13 e8 00 00 00 00 2b 70 62 |.ì..è+pb| 05d13fa0 77 01 1b 2a 03 00 00 1b 2a 04 00 00 00 1a 00 02 |w..**...| 05d13fb0 02 00 18 00 ec 19 13 e8 00 00 00 00 2b 70 62 77 |ì..è+pbw| 05d13fc0 01 1b 2a 03 00 00 1b 2a 04 00 00 00 1a 00 02 02 |..**| 05d13fd0 00 18 00 ec 19 13 e8 00 00 00 00 2b 70 62 77 01 |...ì..è+pbw.| 05d13fe0 1b 2a 03 00 00 1b 2a 04 00 00 00 1a 00 02 02 00 |.**.| 05d13ff0 18 00 ec 19 13 e8 00 00 00 00 2b 70 62 77 01 1b |..ì..è+pbw..| [... and so on ...] This pattern gets repeated all the time. Using http://pbw.id.au/lexmark/protocol.html we can decode this. Starting at 05d13f83: VERTICAL MOVE (1b 2a 03) by 0 SWIPE PRINT (1b 2a 04) of length 26 (00 00 00 1a): unidirectional, 600x600 dpi (00 02) color (02 00) 192 nozzles (18) 00 padding 60441 columns (ec 19) first column = 5096 (13 e8) last column = 0 (00 00) --- huh? doesn't add up driver id = +pbw (2b 70 62 77) time for data (01) VERTICAL MOVE (1b 2a 03) by 0 SWIPE PRINT (1b 2a 04) of length 26 (00 00 00 1a): ... That's what FILL_SWIPE_HEADER writes (in contrib/gdevlx50.c), in printSwipe(). So printSwipe() is being called interspersed with feedPaper(), just as Sebastian described. The tried and true printf method reveals that nextLineToPrint very quickly gets the value of 16, which is much lower than 3300, and keeps that value. But at this point I'm stuck, since I'm not sure how this code is supposed to work. When is nextLineToPrint supposed to advance? It's also possible the postscript file is buggy, though it displays ok with the x11 driver, at least. The ps file came from an attempt to print something with a web browser. Ideas? Jonathan [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=343901 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610719: dpkg: [S-S-B] make start-stop-daemon find out the pid of forked processes
Hi,
First of all, thanks for sending this.
Peter Gyongyosi wrote:
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
[...]
@@ -361,6 +369,152 @@ pid_list_free(struct pid_list **list)
[...]
+static void
+start_trace(pid_t pid)
+{
+ wait(NULL);
+
+ int retries;
+ const int max_retries = 10;
+
+ for (retries = 0; retries max_retries; ++retries) {
+ if (ptrace (PTRACE_SETOPTIONS, pid, NULL,
+ PTRACE_O_TRACEFORK) = 0) {
+ ptrace(PTRACE_CONT, pid, NULL, 0);
+ return;
Yikes. upstart allows something similar (though it uses the simpler
TRACEME and only tries once). For reference, this is imitating the
EXPECT_DAEMON and EXPECT_FORK cases in init/job_process.c.
I guess start-stop-daemon is the right place to implement this kind of
hack, but I'd much rather see daemons providing either a --no-detach
or a --pidfile option. A serious problem with the ptrace approach is
making it impossible to debug the daemon with gdb -p (and that
downside ought to be mentioned in the documentation if this is
adopted).
For your particular application: is it possible to run each service in
a separate cgroup (like systemd does), maybe? (See
http://0pointer.de/blog/projects/systemd-for-admins-4.html for what
that looks like from the enduser pov.) What services use expect =
fork/daemon? Maybe they can be fixed (so strace and gdb -p can use
if for no other reason)?
+ // NOTE: we don't treat it as a fatal error as it could happen in some
race-y situations
+ warning(Error detaching from process: %s (pid: %d)\n,
strerror(errno), pid);
Hmm...
+static void
+trace_pid(char *startas, char **argv)
+{
+ pid_t pid, child_pid;
+ int num_of_forks = 0;
+
+ pid = fork();
+ if (pid 0) {
+ fatal(Unable to fork!\n);
+ }
+ if(pid == 0) {
+ ptrace(PTRACE_TRACEME, 0, NULL, NULL);
+ execvp(startas, argv);
+ }
+ else {
The nested ifs here are hard to read. It should be safe to drop the
else after handling execvp failure.
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610731: kbuildsycoca4(18315) VFolderMenu::loadDoc: Parse error in /home/[...]/xdg-desktop-menu-dummy.menu , line 1 , col 1 : unexpected end of file
Package: kde Version: kde4libs/4:4.4.5-2 Severity: minor Justification: cosmetic Hi, Stock experimental i386 system. I recently installed okular + all packages it recommends to check out a bug. Now in my latest dpkg run: | # cupt --no-auto-remove install iceweasel [...] | The following 1 packages will be INSTALLED: | | iceweasel | | Need to get 1071KiB/1071KiB of archives. After unpacking 4012KiB will be used. [...] | Setting up iceweasel (3.6.13-2) ... | update-alternatives: using /usr/bin/iceweasel to provide /usr/bin/x-www-browser (x-www-browser) in auto mode. | update-alternatives: using /usr/bin/iceweasel to provide /usr/bin/gnome-www-browser (gnome-www-browser) in auto mode. | Processing triggers for man-db ... | Processing triggers for hicolor-icon-theme ... | # kdeinit4: preparing to launch /usr/bin/kbuildsycoca4 | unknown program name(17509)/ KStartupInfo::createNewStartupId: creating: burratino;1295639098;73319;17509_TIME0 : unnamed app | kbuildsycoca4 running... | kbuildsycoca4(18315) VFolderMenu::loadDoc: Parse error in /home/jrn/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu , line 1 , col 1 : unexpected end of file Notice that kdeinit4 seems to be running as some background process, not necessarily related to dpkg. I do not remember editing anything in ~/.config/menus by hand. Ideas? $ ls -lR ~/.config/menus /home/jrn/.config/menus: total 12 drwx-- 2 jrn jrn 4096 Sep 30 22:09 applications-merged -rw-rw-r-- 1 jrn jrn 467 Jul 18 2010 gnome-applications.menu -rw-rw-r-- 1 jrn jrn 230 Jul 18 2010 gnome-settings.menu /home/jrn/.config/menus/applications-merged: total 0 -rw--- 1 jrn jrn 0 Sep 30 22:09 xdg-desktop-menu-dummy.menu $ ps ax | grep kde 17509 ?Ss 0:00 kdeinit4: kdeinit4 Running... 17512 ?S 0:00 kdeinit4: klauncher [kdeinit] --fd=8 17514 ?S 0:00 kdeinit4: kded4 [kdeinit] 17575 ?S 0:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-jrn/klauncherT17512.slave-socket local:/tmp/ksocket-jrn/okular 18391 pts/1S+ 0:00 /bin/bash -c (ps ax |grep kde) /tmp/vkzvCfy/0 21 18392 pts/1S+ 0:00 /bin/bash -c (ps ax |grep kde) /tmp/vkzvCfy/0 21 18394 pts/1S+ 0:00 grep kde $ dpkg-query -W 'k*' 'libk*' kaboom 1.1.2+nmu1 kbd 1.15.2-2 kbd-data kcachegrind kcontrol kde-icons-oxygen kdebase kdebase-bin kdebase-bin-kde3 kdebase-data kdebase-kio-plugins kdebase-runtime 4:4.4.5-1 kdebase-runtime-bin-kde4 kdebase-runtime-data4:4.4.5-1 kdebase-runtime-data-common kdebase-workspace-bin kdebase-workspace-data kdebase-workspace-dev kdebase-workspace-libs4+5 kdebluetooth kdegraphics-strigi-plugins kdelibs-bin 4:4.4.5-2 kdelibs-data kdelibs4-dev kdelibs5 kdelibs5-data 4:4.4.5-2 kdelibs5-dev4:4.4.5-2 kdelibs5-plugins4:4.4.5-2 kdepimlibs5-dev kdiff3 kdoctools 4:4.4.5-2 keyboard-configuration 1.68 keychain kjscmd klibc-utils 1.5.20-1 kmail konqueror krb5-doc krb5-multidev 1.9+dfsg~beta2-1 krb5-user ksh 93t+20100621-1 kttsd kvm libk5crypto31.9+dfsg~beta2-1 libkadm55 libkadm5clnt-mit7 1.8.3+dfsg-2 libkadm5clnt-mit8 1.9+dfsg~beta2-1 libkadm5srv-mit71.8.3+dfsg-2 libkadm5srv-mit81.9+dfsg~beta2-1 libkadm5srv6 libkdb5-4 1.8.3+dfsg-2 libkdb5-5 1.9+dfsg~beta2-1 libkde3support4 4:4.4.5-2 libkdecore5 4:4.4.5-2 libkdepim4 libkdesu5 4:4.4.5-2 libkdeui5 4:4.4.5-2 libkdewebkit5 4:4.4.5-2 libkdnssd4 4:4.4.5-2 libkeyutils11.4-2 libkfile4 4:4.4.5-2 libkhtml5 4:4.4.5-2 libkimproxy44:4.4.5-2 libkio5 4:4.4.5-2 libkjsapi4 4:4.4.5-2 libkjsembed-dev libkjsembed44:4.4.5-2 libklibc1.5.20-1 libklu1.1.0 1:3.4.0-2 libkmediaplayer44:4.4.5-2 libkms1 2.4.22-2 libknewstuff2-4 4:4.4.5-2 libknewstuff3-4 4:4.4.5-2 libknotifyconfig4 4:4.4.5-2 libkntlm4 4:4.4.5-2 libkparts4 4:4.4.5-2 libkpathsea52009-8 libkpty44:4.4.5-2 libkrb5-3 1.9+dfsg~beta2-1 libkrb5-dev 1.9+dfsg~beta2-1 libkrb53 libkrb5support0 1.9+dfsg~beta2-1 libkrosscore4 4:4.4.5-2 libkrossui4 4:4.4.5-2 libksba81.1.0-1 libktexteditor4 4:4.4.5-2 libkunitconversion4 4:4.4.5-2 libkutils4 4:4.4.5-2 libkwebkit-dev $
Bug#556867: cups-pdf: strong kerning errors
found 556867 cairo/1.10.2-1 quit Hi again, micu wrote: Bug Marked as fixed in versions cairo/1.10.2-1. Hmmm… I don't want to disappoint you: I wish this is (was?) the case. But actually, my test.ps was generated with Iceweasel 3.6.13-2 and libcairo2 1.10.2-1 from experimental :/. Weird. Have you looked over the samples I sent? When I try, I get GPL Ghostscript 8.71: Can't find initialization file gs_init.ps. fatal internal error -100okular(17504)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [1090x1410] I suspect that is a separate bug. Yeah, same error here. I guess it is the best if I report it to KDE upstream‽ It's Debian-specific; see http://bugs.debian.org/485621. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485621: libgs8 has no ghostscript dependancy
# insufficient dependencies; shared library policy
severity 485621 serious
retitle 485621 libgs8: undeclared dependency on ghostscript ( 8.71~),
ghostscript (= 8.71+)
affects 485621 + libspectre1
quit
Hi Jonas,
To the release team: I think a fix can wait for a point release.
Tom Parker wrote:
tparker@shostakovich:[~/src/bounding] evince cdf.eps
GPL Ghostscript 8.62: Can't find initialization file gs_init.ps.
fatal internal error -100GPL Ghostscript 8.62: Can't find
initialization file gs_init.ps.
fatal internal error -100
** (evince:18685): WARNING **: Error rendering thumbnail
apt-get install evince-gtk does not result in a working postscript
viewer. Workaround: install the ghostscript package, which has a
versioned dependency[1] to avoid mismatches with libgs.
libgs relies on the main ghostscript package for support files in the
/usr/share/ghostscript/8.71 directory. I ran into this because it
means that installing ghostscript 9 from experimental breaks
postscript support in evince and okular.
A proper fix would presumably be to move the /usr/share/ghostscript
files to libgs8 or a new libgs8-common package. The relevant
dependencies would be
ghostscript --- Depends: ${shlibs:Depends}
libgs8 --- Depends: libgs8-common (= ${source:Version})
Very simple.
Here's a more ugly and targetted fix. Thoughts?
-- 8 --
Subject: libgs8: Depends: ghostscript
libgs8 has an undeclared dependency on support files from
/usr/share/ghostscript/8.71 in the ghostscript package.
More precisely, current libgs8 requires ghostscript 8.71. Rather than
hard-coding that (making it easy to forget to update the dependencies
in a later update), this patch relies on the current versioned
dependency Depends: libgs8 (= ${binary:Version}) that was added to
ghostscript a couple of years ago to address the same problem
(Bug#470253).
Yes, after this patch ghostscript would once again have a circular
dependency.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Untested (testing with apt and aptitude of the upgrade path from
lenny would be especially welcome).
[1]
I did have ghostscript installed, but only version 8.15-something.
http://bugs.debian.org/470253
debian/changelog |6 ++
debian/control |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 5aea161..00af153 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ghostscript (8.71~dfsg2-6.1.1) local; urgency=low
+
+ * libgs8: Depends: ghostscript (closes: #485621, reopens: #519141).
+
+ -- Jonathan Nieder jrnie...@gmail.com Fri, 21 Jan 2011 17:28:46 -0600
+
ghostscript (8.71~dfsg2-6.1) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/control b/debian/control
index d2a0364..fa025fd 100644
--- a/debian/control
+++ b/debian/control
@@ -124,7 +124,7 @@ Description: The GPL Ghostscript PostScript/PDF interpreter
- Documentation
Package: libgs8
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ghostscript ( 9), ${shlibs:Depends}, ${misc:Depends}
Description: The Ghostscript PostScript/PDF interpreter Library
Ghostscript is used for PostScript/PDF preview and printing. Usually as
a back-end to a program such as ghostview, it can display PostScript and PDF
--
1.7.4.rc2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#314169: gs: gs -sDEVICE=ppmraw fails with unrecoverable error
retitle 314169 gs: unhelpful error when -sOutputFile missing (Error: /invalidfileaccess in --.outputpage--) severity 314169 normal tags 314169 - help tags 314169 + upstream quit Hi Uwe, Uwe Muench wrote: when calling gs with the option -sDEVICE=ppmraw, 36 gs -sDEVICE=ppmraw fax-eltern-1.ps it fails with this error message: Error: /invalidfileaccess in --.outputpage-- This error message means that ghostscript could not figure out where to write this output. Using gs -dSAFER -sDEVICE=ppmraw -sOutputFile=foo.ppm foo.ps works for me. I see two possible bugs here: - Is this an incompatible with older versions of ghostscript? - the error message is not very helpful. Information gathering and patches for either would be welcome. Thanks again. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#314169: gs: gs -sDEVICE=ppmraw fails with unrecoverable error
submitter 314169 ! severity 314169 wishlist quit Uwe Muench wrote: wow, that bug report is like 5 and a half years old... Sorry, I don't have that system or that file anymore... I only remember that 'xv' automatically created the 'gs' call and that it had worked with the older version (at that time) of gs. Sorry that I can't even test the problem anymore or give any more input... No problem. The problem is not file-specific, so it's just a question of whether it is feasible to keep support for the implicit output file behavior xv was relying on (or perhaps to improve the error message). If I find time for it, I'll check what xv does, see if any other programs are doing the same, and decide whether it is worth some backward-compatibility hack to keep them working. Claiming the bug so you won't have to get more mail about this. :) Cheers, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
