Bug#733175: git show-ref: (optionally) list symrefs without dereferencing them

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20131217-1
Severity: wishlist
Tags: upstream

grokmirror  uses output from
"git show-ref | sha1sum" as a caching key to decide whether mirrors
need to be updated.  That has two problems:

 1. The default pattern used by show-ref doesn't include HEAD, so if
HEAD moves without any other branches being updated, grokmirror
thinks the repository is unchanged.

This could be fixed on the grokmirror side by passing --head to
show-ref.

 2. Even with --head, show-ref just lists the object pointed to by each
ref.  If HEAD switches from one branch to another but both branches
have the same tip commit, grokmirror won't notice.

If show-ref had an option to show symrefs as-is instead of resolving
them, that could be used to solve (2).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733251: 'git commit' should catch files needing update due to new attributes

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20131217-1
Severity: wishlist
Tags: upstream

Suppose I add the following line to .gitattributes:

*.java text

Meanwhile, the repo has had one .java file with CRLF line endings for
a while (a mistake, but it happens).  Because the 'text' attribute
promises that the file should have LF endings when checked in, unless
I update that file, anyone cloning the repository on Windows will
see it as modified --- if they were to add the unchanged file with
"git add" and commit then the line endings would be fixed.

Best for me to fix the line ending now in the same commit as I add
.gitattributes.  Unfortunately (especially if I do not use Windows) it
is likely I will not notice.  Could "git commit" help?

I'm imagining an error when attempting to commit an attribute change
that promises files will only contain LF endings and they don't.  It
would still be possible to commit such a change by running git commit
again with --force.

Noticed in the context of https://github.com/MovingBlocks/Terasology's
engine/src/main/java/org/terasology/math/Matrix4i.java by Mike
Kienenberger on #git.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#726073: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3

[Jonathan Nieder]

block 726073 by 726116
quit
(culling cc list)

Hi,

Alessandro Ghedini wrote:
> On ven, dic 27, 2013 at 11:24:11 +, Debian Bug Tracking System wrote:
>> Processing commands for cont...@bugs.debian.org:

>>> affects 726073 + git src:git
>> Bug #726073 [libcurl3-nss] libcurl3-nss: tries to use libnsspem, which is 
>> not provided by libnss3
>> Added indication that 726073 affects git and src:git
>
> Care to explain how this affects git, considering that it uses 
> libcurl3-gnutls?

Time permitting, I'd like to switch git to using libcurl3-gnutls (for a
few different reasons --- sidestepping the libgmp licensing issue is
one, and the possibility of better interoperability with some broken
servers is another).  Using "affects" makes it easier for me to track
this bug when working on the git package.

> Also, there's not much I can do about this (except maybe dropping libcurl3-nss
> altogether), and since we have #726116 tracking this now, I'm inclined to 
> close
> this report.

Could we keep it open?  It's the only report that tracks the symptom
instead of that specific proposed fix --- e.g., if libcurl could use the
shared nssdb instead of PEM certificates when using the NSS backend,
that would be a fine way to solve this.

If you don't want to keep track of it, I can reassign to git.  And if
you want to drop libcurl3-nss until libnsspem gets packaged, that
would be another fine way of closing this and I wouldn't mind.

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#669292: Packaging webapps to work with both Apache 2.2 and 2.4

[Jonathan Nieder]

Hi,

I'm trying to follow the directions at

 https://lists.debian.org/debian-webapps/2012/03/msg7.html
 
https://wiki.debian.org/Apache/PackagingFor24#Making_web_applications_compatible_to_both.2C_Apache_2.2_and_2.4

(late, I know) and ran into some questions about edge cases.

1. Suppose someone installs my webapp and then deconfigures (for
   example using "dpkg -B -i" on a package with Breaks) but does not
   remove it.  In this case, policy tells me that prerm is called with
   deconfigure and postrm is not called.

   If the system uses apache 2.2, what happens?  What stops the
   configuration in /etc/apache2/conf.d from taking effect in this
   case?

   If the system uses apache 2.4, what happens?  Should I call
   "apache2_invoke disconf mywebapp" in prerm when $1 != upgrade to
   avoid trouble?

2. Suppose someone installs my webapp while apache2.2 is installed.
   It works (yay!).  Then they upgrade to apache2.4

   Is the webapp broken until they "dpkg-reconfigure mywebapp"?

   Will the now unneeded symlink in /etc/apache2/conf.d/ stay
   around forever?  Why is the postrm snippet to remove the symlink
   guarded by [ "$COMMON_STATE" = installed ] || [ "$COMMON_STATE =
   unpacked ]?

The package in question is often used on old Debian releases (both
through backports.debian.org and people's private backports), which
is why I want to get it working with both apache versions.  But it's
tempting to include a Breaks to force the apache upgrade, in which
case there would only be need for an answer to (1) and not (2).

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#733746: dpkg-source - can't build with source format '3.0 (quilt)' when version number is 1.0.0

[Jonathan Nieder]

forcemerge 733746 719348
# confusing error message
severity 733746 minor
quit

Hi,

Thomas Mayer wrote:

> pd-purest-json (1.0.0) UNRELEASED; urgency=low

Is this a native package?  (See [1] for what I mean.)

Curious,
Jonathan

[1] 
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#sourcelayout


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#669292: gitweb: automatic configuration breaks with apache2 2.4

[Jonathan Nieder]

Jonathan Nieder wrote:

> As described at [1], apache's scheme for supporting webapps has
> changed a little.  [2] describes what we need to do.

Here's a start.  Thoughts welcome, as always.
From: Jonathan Nieder 
Date: Thu, 2 Jan 2014 16:22:17 -0800
Subject: debian/gitweb: adapt packaging for apache 2.4

Try to support both apache 2.2 and 2.4, following advice from

 https://lists.debian.org/debian-devel-announce/2012/03/msg00013.html
 https://lists.debian.org/debian-webapps/2012/03/msg7.html

NEEDSWORK:
 - prerm deconfigure does not clean up as much as it should
 - needs triggers to reconfigure when apache is updated?
 - untested

Signed-off-by: Jonathan Nieder 
---
 debian/changelog| 29 +++
 debian/control  |  1 +
 debian/gitweb.conffiles |  2 +-
 debian/gitweb.postinst  | 53 +++--
 debian/gitweb.postrm| 21 
 debian/gitweb.preinst   |  6 ++
 debian/rules|  4 ++--
 7 files changed, 94 insertions(+), 22 deletions(-)
 create mode 100644 debian/gitweb.postrm
 create mode 100644 debian/gitweb.preinst

diff --git a/debian/changelog b/debian/changelog
index 4ffa62c..2c2004f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,32 @@
+git (1:1.8.5.2-1.1) unstable; urgency=low
+
+  * update gitweb configuration packaging for apache 2.4
+(closes: #669292).
+* rules, gitweb.conffiles: gitweb's Apache settings go in
+  /etc/apache2/conf-available, with .conf extension.
+* gitweb.preinst, gitweb.postinst, gitweb.postrm: use
+  dpkg-maintscript-helper to rename
+  /etc/apache2/conf.d/gitweb -> conf-available/gitweb.conf,
+  preserving local changes.
+* control: Pre-Depends: dpkg (>= 1.15.8) for
+  dpkg-maintscript-helper.
+* gitweb.postinst configure: use apache2-maintscript-helper
+  if present to enable gitweb configuration.  If
+  apache2-maintscript-helper is not available and
+  apache2.2-common is unpacked, install a symlink
+  conf.d/gitweb.conf -> ../conf-available/gitweb.conf for use
+  by apache 2.2.
+* gitweb.postinst configure: only use the apache2 init script
+  to reload configuration when apache2-maintscript-helper is
+  unavailable (otherwise, "apache2_invoke enconf gitweb"
+  takes care of that).
+* gitweb.postrm remove, purge: use apache2-maintscript-helper
+  if present to disable gitweb configuration.
+* gitweb.postrm remove, purge: remove conf.d/gitweb.conf ->
+  ../conf-available/gitweb.conf symlink if still present.
+
+ -- Jonathan Nieder   Thu, 02 Jan 2014 16:22:12 -0800
+
 git (1:1.8.5.2-1) unstable; urgency=low
 
   * new upstream point release.
diff --git a/debian/control b/debian/control
index aa180bb..da95ec3 100644
--- a/debian/control
+++ b/debian/control
@@ -353,6 +353,7 @@ Architecture: all
 Multi-Arch: foreign
 Depends: git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.),
  perl, apache2 | httpd | lynx-cur
+Pre-Depends: dpkg (>= 1.15.8~)
 Recommends: libhttp-date-perl | libtime-modules-perl
 Suggests: httpd-cgi | libcgi-fast-perl, git-doc
 Description: fast, scalable, distributed revision control system (web 
interface)
diff --git a/debian/gitweb.conffiles b/debian/gitweb.conffiles
index 27a8287..8947bf6 100644
--- a/debian/gitweb.conffiles
+++ b/debian/gitweb.conffiles
@@ -1,2 +1,2 @@
 /etc/gitweb.conf
-/etc/apache2/conf.d/gitweb
+/etc/apache2/conf-available/gitweb.conf
diff --git a/debian/gitweb.postinst b/debian/gitweb.postinst
index b51381b..35f082a 100755
--- a/debian/gitweb.postinst
+++ b/debian/gitweb.postinst
@@ -1,24 +1,39 @@
 #!/bin/sh
 set -e
 
-case "$1" in
-configure)
-if [ -x /etc/init.d/apache2 ]
-then
-if which /usr/sbin/invoke-rc.d >/dev/null 2>&1
-then
-invoke-rc.d apache2 reload || true
-else
-/etc/init.d/apache2 reload || true
-fi
-fi
-;;
+dpkg-maintscript-helper mv_conffile \
+  /etc/apache2/conf.d/gitweb /etc/apache2/conf-available/gitweb.conf \
+  1:1.8.5.2-1.1~ -- "$@"
 
-abort-upgrade|abort-remove|abort-deconfigure)
-;;
+test "$1" = configure || exit 0
 
-*)
-echo "postinst called with unknown argument \`$1'" >&2
-exit 1
-;;
-esac
+# <4f6ef77f.6080...@toell.net>
+if [ -e /usr/share/apache2/apache2-maintscript-helper ]
+then
+  . /usr/share/apache2/apache2-maintscript-helper
+  apache2_invoke enconf gitweb || exit
+else
+  apache2_common_state=$(
+dpkg-query -f '${Status}' -W apache2.2-common 2>/dev/null |
+awk '{print $3}' || true
+  )
+  if [ "$apache2_common_state" = installed ] ||
+[ "$apache2_common_state" = unpacked ]
+  then
+if [ -d /etc/apache2/conf.d/ ] &&
+  [ ! -

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

[Jonathan Nieder]

Hi Sten,

Sten Heinze wrote:

> Running 'git svn fetch' or 'git svn rebase' results in the git-svn crashing 
> with the
> following: error: git-svn died of signal 11.

Yeah, that's no good.  Is this reproducible?

Please attach .git/config after censoring whatever seems appropriate.

[...]
> To obtain more details, I ran:
>   GIT_TRACE=1 git svn rebase
> and:
>   PERLDB_OPTS="NonStop frame=5" perl -d $(git --exec-path)/git-svn svn rebase
> and attached the output. I'm unsure about what to take from these, so any 
> information
> on how to interpret them is welcome.

I think you forgot to attach these.

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#734097: git: set OPTS to un-break Dyson build

[Jonathan Nieder]

tags 734097 + patch
quit

Hi Игорь,

Игорь Пашев wrote:

> Please, add the following lines to the "OPTS" variable in debian/rules:
>   LIBC_CONTAINS_LIBINTL=1 \
>   TAR=tar \
>   INSTALL=/usr/bin/install \
>
> This will allow building git package without changes for Dyson [1]
> By default git build system sets them as
> LIBC_CONTAINS_LIBINTL=, TAR=gtar,  INSTALL=/usr/ucb/install

I assume that means on Dyson 'uname -s' prints 'SunOS'.  Does 'uname
-o' print SunOS, too?  Is there some simple way the upstream makefile
could use to autodetect that this is the Illumos kernel with a GNU
userland, or will the distro packaging have to permanently include
these settings (which would be fine, too)?

For comparison, git's config.uname.uname treats the kfreebsd port
separately from standard FreeBSD so everything works automagically
there.

In the meantime, how about this patch?

Thanks,
Jonathan

diff --git i/debian/changelog w/debian/changelog
index 5a8f9a0..40e 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,6 +1,9 @@
 git (1:2.0~next.20131217-1.1) experimental; urgency=low
 
   * debian/rules: drop obsolete THREADED_DELTA_SEARCH setting.
+  * debian/rules: add SANE_TOOL_PATH= INSTALL=install TAR=tar to
+OPTS to fix the Dyson build (thx Игорь Пашев; closes:
+#734097).
 
  -- Jonathan Nieder   Fri, 03 Jan 2014 11:54:44 -0800
 
diff --git i/debian/rules w/debian/rules
index 37e71a7..221fb58 100755
--- i/debian/rules
+++ w/debian/rules
@@ -14,6 +14,7 @@ OPTS =NO_OPENSSL=1 prefix=/usr gitexecdir=/usr/lib/git-core \
   NO_PYTHON=1 \
   USE_SRV_RR=1 \
   USE_LIBPCRE=1 \
+  SANE_TOOL_PATH= INSTALL=install TAR=tar \
   NO_CROSS_DIRECTORY_HARDLINKS=1 NO_INSTALL_HARDLINKS=1 \
   DEFAULT_PAGER=pager DEFAULT_EDITOR=editor \
   CC='$(CC)' CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)'


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734097: git: set OPTS to un-break Dyson build

[Jonathan Nieder]

Игорь Пашев wrote:

> I don't see  LIBC_CONTAINS_LIBINTL=1 in your patch, but since
> there are few other packages which unconditionally link to libintl,
> I will make a dummy library.

Oops, I can do that, too.  What libc does Dyson use?

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#726116: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3

[Jonathan Nieder]

(dropping cc to bug#726073)
Hi Bastien,

Bastien ROUCARIES wrote:
> On Sat, Dec 28, 2013 at 2:09 PM, Alessandro Ghedini  wrote:

>> Btw, Bastien ROUCARIES (CCed) mentioned something about what looks like the
>> libnsspem.so we are interested in [0] (that is [1]), though I'm afraid it'll
>> need NSS maintainers support to get packaged. Bastien, do you have any news
>> about this?
>
> I volontuer to package it, but I need mentoring (I am not a dd).

Yay!  I'm happy to review patches or packages and upload when ready.  Do
you have work in progress I can look at somewhere?

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#734223: git: missing Breaks against git-buildpackage (<< 0.6.5)

[Jonathan Nieder]

Package: git
Version: 1:1.8.5~rc0-1
Severity: important
Tags: patch

git v1.8.5-rc0~101^2~3 (status: disable display of '#' comment prefix by
default, 2013-09-06) broke git-buildpackage:

  $ git import-dsc ../dash_0.5.7-3+nmu1.dsc
  gbp:error: Repository has uncommitted changes, commit these first: 
  gbp:error: On branch debian-sid
  Your branch is up-to-date with 'debian/debian-sid'.
  nothing to commit, working directory clean

(That's with git-buildpackage 0.5.32.)  git-buildpackage 0.6.5~3 (Be
more robust about git status output changes, 2013-10-16) fixes it.

How about this patch?

diff --git i/debian/changelog w/debian/changelog
index 71a50df..cca04c7 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -3,6 +3,9 @@ git (1:1.8.5.2-1.1) unstable; urgency=low
   * /etc/bash_completion.d/git-prompt: check for git-sh-prompt
 and do not source it if git is removed but not purged (thx
 Craig Small; closes: #726669).
+  * debian/control: package git Breaks: git-buildpackage versions
+that rely on output from 'git status' without the --porcelain
+flag (see #726260).
 
  -- Jonathan Nieder   Fri, 03 Jan 2014 15:44:36 -0800
 
diff --git i/debian/control w/debian/control
index aa180bb..a36aaa6 100644
--- i/debian/control
+++ w/debian/control
@@ -30,6 +30,7 @@ Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
 Replaces: gitweb (<< 1:1.7.4~rc1),
  git-core (<< 1:1.7.0.4-1.)
 Breaks: bash-completion (<< 1:1.90-1), gitweb (<< 1:1.7.4~rc1),
+ git-buildpackage (<< 0.6.5),
  cogito (<= 0.18.2+),
  stgit (<< 0.15), stgit-contrib (<< 0.15), gitpkg (<< 0.15),
  guilt (<< 0.33), gitosis (<< 0.2+20090917-7),


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604241: dpkg complains on missing architecture entries for removed packages of oldoldoldstable

[Jonathan Nieder]

Raphael Hertzog wrote:
> On Sun, 21 Nov 2010, Juergen Kosel wrote:

>> yesterday I have upgraded an old computer from Lenny to Squeeze.
>> This machine has a long history. Debian Woody was installed on it 2005.
>> 
>> Now dpkg gives the following complaints on packages which were installed 
>> long ago:
>
> Yes, and?
>
> We have added those warnings, it's not to drop them when someone sees
> them. :-)

It does sound like a bug to me.  Would it make sense to automatically update
the available file somehow on upgrade?

> I understand they are left-over from very long ago, you should simply
> run "dpkg --clear-avail" to get rid of them.

This sounds like a workaround. :)

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#592300: freeze exception: xz-utils 5.0.0

[Jonathan Nieder]

user release.debian@packages.debian.org
usertags 592300 unblock
retitle 592300 unblock: xz-utils/5.0.0-2
thanks

Julien Cristau wrote:
> On Mon, Oct 25, 2010 at 12:00:00 -0500, Jonathan Nieder wrote:

>> 5.0.0 was released at last.  Relative to xz-utils in testing, it
>> brings the following major changes:
>
> Please upload to unstable.  Sorry for the delay.

Thank you.  Done and reached its 10 days.  (More time cooking in
unstable may or may not be appropriate depending on your preference).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#539374: RFP: rsvndump -- Performs a remote dump of a subversion repository

[Jonathan Nieder]

Hi Mathieu,

Mathieu Malaterre wrote:

> Using svnsync did work for me and is clearly documented to allow a
> rsvndump operation using svnsync + svnadmin.

I am tempted to tag this RFP wontfix given that Subversion trunk[1]
includes an svnrdump utility.

What do you think?  Does Debian need two implementations of that
functionality?

Jonathan

[1] Shameless plug: you can find a backport of svnrdump to svn 1.6 at
. :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#539374: RFP: rsvndump -- Performs a remote dump of a subversion repository

[Jonathan Nieder]

tags 539374 + wontfix
thanks

Mathieu Malaterre wrote:
> On Mon, Nov 22, 2010 at 12:22 PM, Jonathan Nieder  wrote:

>> I am tempted to tag this RFP wontfix given that Subversion trunk[1]
>> includes an svnrdump utility.
>>
>> What do you think?  Does Debian need two implementations of that
>> functionality?
>
> Completely agree with that !

Done.  Thanks for the quick feedback.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604543: cupt: doesn't notice Release file expiry

[Jonathan Nieder]

Package: cupt
Version: 1.5.14.1
Severity: wishlist

For the past few days, cupt has not been getting any updates:

 # cupt update
 Get:1 http://mirrors2.kernel.org/debian sid Release
 Get:2 http://mirrors2.kernel.org/debian experimental Release
 Get:3 http://mirrors2.kernel.org/debian testing Release
 Get:4 http://mirrors2.kernel.org/debian experimental Release.gpg
 Get:5 http://mirrors2.kernel.org/debian sid Release.gpg
 Get:6 http://mirrors2.kernel.org/debian testing Release.gpg
 Fetched 292KiB in 7s.
 # cupt full-upgrade
 Building the package cache... [done]
 Initializing package resolver and worker... [done]
 Scheduling requested actions... [done]
 Resolving possible unmet dependencies...

 Performing requested actions:
 
So I tried apt today.

 # apt-get update
 Hit http://mirrors2.kernel.org sid Release.gpg
 Ign http://mirrors2.kernel.org/debian/ sid/main Translation-en
 Ign http://mirrors2.kernel.org/debian/ sid/main Translation-en_US
 Get:1 http://mirrors2.kernel.org/debian/ sid/main Translation-fr [568 kB]
 Hit http://mirrors2.kernel.org experimental Release.gpg
 Ign http://mirrors2.kernel.org/debian/ experimental/main Translation-en
 Ign http://mirrors2.kernel.org/debian/ experimental/main Translation-en_US
 Ign http://mirrors2.kernel.org/debian/ experimental/main Translation-fr
 Hit http://mirrors2.kernel.org testing Release.gpg
 Hit http://mirrors2.kernel.org sid Release
 E: Release file expired, ignoring 
http://mirrors2.kernel.org/debian/dists/sid/Release (invalid since 1d 22h 12min 
8s)

Oh!  Could cupt add a similar message?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604557: RFS: aspell-id

[Jonathan Nieder]

Hi,

Mahyuddin Susanto wrote:

> * URL : ftp://ftp.gnu.org/gnu/aspell/dict/id
[...]
> - dget 
> http://mentors.debian.net/debian/pool/main/a/aspell-id/aspell-id_0.1-2.dsc

The .orig.tar.gz seems to be a git clone of
, though the files match
aspell5-id-1.2-0.tar.bz2.  I would suggest:

- setting the version number in debian/changelog based on the
  upstream version:

  aspell-id (1.2-0-1) unstable; urgency=low

* Initial package for Debian (Closes: #604557).
* Add simple rules file (using cdbs, based on such-and-such
documentation), a control file describing the binary package,
  and an appropriate compat file.

   -- Mahyuddin Susanto   ... whenever ...

- putting a copy of aspell5-id-1.2-0.tar.bz2 named
  aspell-id_1.2-0.orig.tar.bz2 in the parent directory to your
  build dir when building the package.

Perhaps this package should Provides: aspell-dictionary?  Brian
Nelson might have more advice; cc-ing him.

> My motivation for maintaining this package is: learning packaging from
> debian mentors

Mm, that's a lousy reason to introduce a new package.  Better to
improve the existing ones.

>packaging localization

But this is a very good reason to introduce a package.

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#604168: RFS: ramond

[Jonathan Nieder]

Hi Nicolas,

Nicolas Dandrimont wrote:

> We've been using this software on our network for a few months now and
> it has proven very useful in killing off the rogue IPv6 routes and
> notifying our users of their configuration problem. I think including
> it into Debian would be worthwile.

Sounds interesting.

> This is the first package I intend
> for inclusion into the main Debian repositories, so there may be some
> kinks to work out.
[...]
> - dget http://mentors.debian.net/debian/pool/main/r/ramond/ramond_0.4-1.dsc

FWIW, I am not a DD, so you have no hope of having this uploaded by me. :)
I also do not have an IPv6 network to test it on.

Quick tips:

. did you know about dh_installexamples?

. it might be nice to strip the outdated "Installation" section from
  the README at build time, like this:

   sed '/Installation/, /textproc/ d' README >debian/README
   dh_installdocs debian/README

. is it important to say

This manual page was written for the Debian
distribution because the original program does not
have a manual page.

  so early in the ramond.8 page?  If it were me, I'd not mention it
  at all; the COPYRIGHT section already says this was written for
  Debian.

The packaging is very clean.  Thanks for a pleasant read.

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#603842: RFS: triggerhappy

[Jonathan Nieder]

Hi Stefan,

Stefan Tomanek wrote:

> * URL : https://github.com/wertarbyte/triggerhappy
[...]
> My motivation for maintaining this package is: I've written this small
> program to fill a need not covered by any existing program, so I think
> having it in Debian and making it available to others is a good thing.
> 
> Currently, there is no practical way to configure global hotkeys that act
> independent from a user and/or X11 session. Buttons like Suspend or Volume
> Control should be handeled without requiring a user to log into their desktop
> environment

How does this compare to Rick van Rein's funkey[1]?

It might make sense to add your app to Andries Brouwer (cc'd)'s keyboard
and console HOWTO, though the latter is sadly a bit dated by now.

Regards,
Jonathan

[1] http://rick.vanrein.org/linux/funkey/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#579040: RFS: zsnes (updated package - ITA)

[Jonathan Nieder]

Hi Etienne,

Etienne Millon wrote:

> I have been using this package for years and it seems to need love.
> As I am learning how to maintain package, this seems a perfect
> candidate for adoption. I am preparing an upload fixing a few bugs,
> and will close this ITA when it's done.

These are words I like to hear.

> - dget http://mentors.debian.net/debian/pool/main/z/zsnes/zsnes_1.510-3.dsc

I am not a DD so there is no hope for an upload from me. :)
Quick thoughts:

> +  * Remove useless build-deps on xlibmesa-gl-dev and xutils (Closes: #579040)

Are you sure the build-deps were useless?  It could be that some of
them are still needed but were brought in accidentally via libsdl-dev,
for example.  (See )

$ apt-cache show xutils xlibmesa-gl-dev

x11-xfs-utils, x11-utils, x11-xserver-utils, x11-session-utils,
xfonts-utils, libgl1-mesa-dev

would be a conservative replacement.  (Of course, some subset of
that, perhaps the empty one, would be the correct replacement.)

> +  * Add debian/README.source to document dpatch.

I would have used a symlink or text pointing to
/usr/share/doc/dpatch/README.source.gz for easier maintenance.

> +  * Add debian/watch file.

Hoorah. :)

I haven't checked the build-deps.  Everything else looks good.

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#579040: RFS: zsnes (updated package - ITA)

[Jonathan Nieder]

Etienne Millon wrote:

> The package builds in a clean chroot, so I thought this was "good
> enough". If this is bad practice I will have another look at it.

Yes, best practice is to explicitly declare all build-time
dependencies that are not build-essential.  So for example if
the code uses Xlib calls directly, it is not enough to build-depend
on libsdl-dev that depends on X, because libsdl-dev could be made
not to depend on the backend some day.

Though since the package builds in a clean chroot, it is at least
likely to build correctly on buildds today.  So it is not critical
or anything.

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#603842: RFS: triggerhappy

[Jonathan Nieder]

Stefan Tomanek wrote:
> Dies schrieb Jonathan Nieder (jrnie...@gmail.com):

>> How does this compare to Rick van Rein's funkey[1]?
>
> Hm, funkey does require a kernel patch und looks quite dated?
>
> "Funky Daemon which demonstrates how to parse the /dev/funkey character 
> device."

Thanks for a quick response.  Sorry, I did not read the following
carefully enough:

This patch is not being actively maintained, unlike my
BadRAM patch.  There is an alternative[1] that is said to
work without kernel patching on current Linux systems.
We keep this page around for historic service,
especially because the information about keyboard
modes is still useful.

[1] http://www.burghardt.pl/wiki/software/esekeyd

How does triggerhappy compare to Krzysztof Burghardt's esekeyd?

> As I said, triggerhappy uses the /dev/input/eventX files, anything that fires
> SW_, KEY_ or BTN_ events can be used t launch programs.

That sounds like very useful information for the package description.
Currently it says:

| Description: global, user and session independent hotkey daemon
|  Triggerhappy observes all connected input devices and launches
|  configured commands when certain keys are pressed. The daemon
|  works as a system wide service and is independent of any user
|  session.

To nitpick (please don't take this the wrong way --- when a person
spends time on things like this, that usually means she thinks your
package is valuable):

It is easy to misunderstand the short description.  I think it is
meant to say that that the hotkey daemon is not tied to a user
session, but now it conjures up images of "user-independent hotkeys".
Maybe:

 Description: hotkey daemon for Linux
  Triggerhappy watches connected input devices for certain key presses
  (like Suspend and Volume Control) and runs administrator-configured
  commands when they are pressed. Unlike , it runs as a
  persistent, systemwide service and therefore can be used even
  outside the context of a user or X11 session.
  .
  It can also handle remote controls, as they are presented as
  keyboards. No kernel patch is required. The daemon is a userspace
  program that polls the /dev/input/event? interfaces for incoming key
  presses.
  .
  For example, this package might be useful on a headless system to
  use input events generated by a remote control to control an
  mpd server.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#603842: esekeyd and triggerhappy (Re: RFS: triggerhappy)

[Jonathan Nieder]

Hi Krzysztof and Stefan,

Stefan Tomanek wrote:

> I think esekeyd can only handle KEY events, while triggerhappy can also 
> process
> Switch and button events. I am also unsure whether esekeyd support the
> hotplugging of input devices (done in triggerhappy by a udev script) or daemon
> control via socket. From what I see, esekeyd also lacks the support for 
> "modes",
> which can modify the button assignment depending on the state the daemon is 
> in.

Thanks, that helps.  Next comes a question that might sound off-topic.
Would it be easy and would it be sensible to teach esekeyd these
features?

To be clear, I am not a DD, so please do not feel obligated to answer
me as a hoop before getting triggerhappy uploaded.  It won't help. :)

What I am trying to figure out is whether esekeyd and triggerhappy
occupy different niches or if it is an accident of history that you
are not already working on the same codebase.  IIUC triggerhappy is
very young so there might be a chance to merge or make the user
interfaces compatible before users grow irrationally attached to the
quirks of one or the other.

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#603842: esekeyd and triggerhappy (Re: RFS: triggerhappy)

[Jonathan Nieder]

Stefan Tomanek wrote:

> I think
> merging the two programs would be difficult. Although young, triggerhappy
> has accumulated quite a few features that would require a redesigning many
> aspects of esekeyd (multiple devices, command socket, multiple config files).

This information could be useful for both package descriptions.
(Maybe, for triggerhappy:

That is, this is similar to esekeyd but it also supports
, allowing you to .

and for esekeyd:

This package does not do ; for that, see
triggerhappy.  In the simple situations it does handle,
esekeyd is {simpler to configure | compatible with the
old funkey daemon | more conservative in its use of
resources | providing a different interface that existing
users might be used to | whatever}.

)  As you can see, there are some placeholders because I do not know
the packages; I am just saying it would be nice to provide the
sysadmin with advice of some sort to choose between them.

Both sound very useful to me.  Thanks to you both.

Ciao,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604749: libbfd: no stable ABI

[Jonathan Nieder]

Package: binutils
Version: 2.20.90.20101121-1
Severity: wishlist
Tags: upstream

Nowadays perf (like oprofile) links against libbfd, which again
reminds me that I wish it had a stable ABI[1].

Actually an unstable ABI is fine with me, as long as the ABI version
is not bumped with every release.  For example, I'd be fine with an
unversioned shared library and Breaks for each ABI break, or I'd be
happy to maintain a version number that only increases with
incompatible ABI changes.

Thoughts?  Has this idea been raised upstream before?

[1] I'll file a separate bug to request that perf be linked
statically, but it would be better to avoid that.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604750: perf: rigid binutils dependency

[Jonathan Nieder]

Package: linux-tools-2.6.36
Version: 2.6.36-1~experimental.1
Severity: wishlist

perf from experimental conflicts with binutils from experimental
because of Bug#604749.

But why does perf need to link to shared libbfd anyway?  Please
consider setting HAVE_CPLUS_DEMANGLE=1 in MAKE_PERF_VARS so it
can link [statically] to libiberty instead.

Thanks for packaging perf!
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604755: perf timechart: segfault in perf_session__process_events

[Jonathan Nieder]

Package: linux-tools-2.6.36
Version: 2.6.36-1~experimental.1
Tags: upstream

Can't seem to get "perf timechart" working.

  $ uname -r
  2.6.36-trunk-686
  # perf timechart record echo hi
  hi
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.079 MB perf.data (~3471 samples) ]
  # chmod a+r perf.data
  $ gdb --args perf_2.6.36 timechart
[...]
  (gdb) run
  Starting program: /usr/bin/perf_2.6.36 timechart
  [Thread debugging using libthread_db enabled]

  Program received signal SIGSEGV, Segmentation fault.
  0x08061969 in ?? ()
  (gdb) bt
  #0  0x08061969 in ?? ()
  #1  0x0808998e in ?? ()
  #2  0x080888a6 in ?? ()
  #3  0x080894b8 in __perf_session__process_events ()
  #4  0x08089890 in perf_session__process_events ()
  #5  0x08060041 in cmd_timechart ()
  #6  0x0805210e in ?? ()
  #7  0x080527cd in main ()

Also was reproducible with upstream linux and perf 2.6.37-rc3.
Valgrind trace (source line numbers refer to v2.6.37-rc3):

Invalid read of size 4
   at 0x805B5C1: process_sample_event (builtin-timechart.c:505)
   by 0x808654D: process_finished_round (session.c:410)
   by 0x8085CF5: perf_session__process_event (session.c:633)
   by 0x808732F: __perf_session__process_events (session.c:827)
   by 0x80875CF: perf_session__process_events (session.c:867)
   by 0x805BDE0: cmd_timechart (builtin-timechart.c:949)
   by 0x804CCED: run_builtin (perf.c:286)
   by 0x804D47E: main (perf.c:357)
 Address 0x5416558 is 8 bytes after a block of size 72 alloc'd
   at 0x4023F50: malloc (vg_replace_malloc.c:236)
   by 0x8085EFA: perf_session__process_event (session.c:553)
   by 0x808732F: __perf_session__process_events (session.c:827)
   by 0x80875CF: perf_session__process_events (session.c:867)
   by 0x805BDE0: cmd_timechart (builtin-timechart.c:949)
   by 0x804CCED: run_builtin (perf.c:286)
   by 0x804D47E: main (perf.c:357)

Is this a known problem?  Where should it be reported?

(Ooh, this time it wrote a timechart before segfaulting!  Apparently
v2.6.37-rc3 userspace + debian 2.6.36 kernel is the recipe for
success...)

Ciao,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

[Jonathan Nieder]

Hi,

Simon Richter wrote:

> The problem at hand is the proposed (and implemented) solution for
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 .
[lxterm having higher priority than konsole on KDE systems]
>
> I'm unconvinced that bumping the priority on the other terminal
> emulators is an adequate solution, hence I'm opening this "general" bug
> for discussion on how to reflect individual users' choices properly.
>
> It has been suggested on #debian-devel that maybe creating a per-user
> ~/bin with its own alternatives links might be an option, however there
> needs to be a fallback mechanism in case the currently selected option
> goes away.

To make this concrete:

. unlike browsers with $BROWSER and desktop-specific settings, there
  is no standard, cross-distro way to make a user-specific choice of
  terminal

. apps integrated into Debian can and should be using
  x-terminal-emulator, without an explicit "/usr/bin/", as hinted at
  by policy §6.1 "Introduction to package maintainer scripts"

. therefore users can put a script implementing whatever policy they
  choose in ~/bin/x-terminal-emulator, but:

   1. that requires more know-how than many users have
   2. applications not integrated into Debian would just use xterm
  anyway, which is not so great.

To solve (1): an interested person could make an app that installs an
easily configurable ~/bin/x-terminal-emulator script.  This seems
like a rfp rather than a general bug, if anything.

To solve (2): one could introduce a TERMINAL environment variable
analogous to MAILER and implement xdg-terminal that reads it.  Please
clone this bug and assign to xdg-utils if interested.

Sensible?
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#567560: new versions on experimental?

[Jonathan Nieder]

Hi Harald,

Harald Dunkel wrote:

> What I meant was that the "unstable" version is a little bit too
> "experimental" for me. Recovery from a broken grub2 upgrade can be
> _pretty_ difficult. This means there is a high risk for doing
> grub2 upgrades, even if the code itself is very stable.
> 
> IMHO the high risk should be reduced by better testing in the
> "experimental" branch, before a new version is promoted to
> "unstable".

How do you feel about this today?  Probably for your needs pinning
grub to "testing" might be a little better, but regardless, I've found
the level of scary much lower lately.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#229357: dpkg: Please add support for build-arch and build-indep targets

[Jonathan Nieder]

Hi Roger,

Roger Leigh wrote:

> I don't see why we can't just mandate it in Policy, and then
> enable it unconditionally if the Standards-Version is >= that
> policy version.

It seems that a summary of the previous discussion is in order.

dpkg 1.10.11~9 (In dpkg-buildpackage, call debian/rules -qn
build-arch, 2003-09-15) includes logic to check for the build-arch
target and use it if present.  Unfortunately that logic was wrong.
Adam reasonably concluded (6acb249):

It is *not* possible *at all* to detect available targets
in a rules file.  Period.

However, a couple of months ago, some code to do exactly that[1]
was written.  So we can have a transitionless utopia, provided
this works. :)

Meanwhile there has been a lot of discussion of workarounds.

One is to use Standards-Version to indicate use of build-arch.
This seems to me like a terrible precedent to set: once you have
two features enabled this way, the transitions to use them
become coupled.  Russ discussed[2] that in more detail recently;
many others have discussed it before[3].

Another is to introduce Build-options[3] to advertise support for
optional features like this (also DEB_BUILD_OPTIONS=parallel).  Of
course, there is some relucance to do that when it is not clear it
is necessary.

Hope that helps.
Jonathan

[1] http://bugs.debian.org/598534
[2] http://lists.debian.org/debian-devel/2010/09/msg00648.html
[3] http://bugs.debian.org/218893



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#508001: git-cvsimport connect error: Network is unreachable

[Jonathan Nieder]

reassign 508001 cvsps 2.1-4
unarchive 489219
forcemerge 489219 508001
thanks

Hi Luca,

Luca Bruno wrote:

> when issueing git-cvsimport I always get:
> Initialized empty Git repository in /media/common/projects/MODULE/.git/
> connect error: Network is unreachable
> cvs rlog: Logging MODULE
> ...
> 
> Eventhough connects to the server and fetches the code.

FYI: http://thread.gmane.org/gmane.comp.version-control.git/20255/focus=20261

The message comes from cvsps.  It seems to be a 64-bit safety bug,
which is probably why I can't reproduce it on this i386.

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#348775: general: terminal emulators' alternatives settings' priorities annoy users

[Jonathan Nieder]

clone 348775 -1
reassign -1 xdg-utils 1.0.2+cvs20100307-3
retitle xdg-utils please introduce (sane) xdg-terminal
tags -1 + upstream
quit

Paul Wise wrote:

> In xdg-utils CVS there is an xdg-terminal script, not sure why that
> isn't available in Debian yet:

When no desktop is in use, it uses $TERM to choose a terminal,
so on this machine it would end up trying to run 'linux'. :)
Using $TERMINAL would fix that, I think.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604993: dash as /bin/sh causes $PPID to be wrong in child when invoked via system() call

[Jonathan Nieder]

severity 604993 normal
quit

Hi Tim,

Tim Connors wrote:

> When /bin/sh is linked to dash, if  is a shell script (/bin/sh
> or /bin/bash), that shell script sees $PPID as being the "sh -c" process.

Could you give an example?  I tried:

$ sh -c 'echo $PPID; echo $$'
18562
18564
$ python -c 'import os; os.system("echo $PPID; echo $$");'
18577
18578

so I suspect I am missing something.

> I have marked this as "grave", because it breaks unrelated parts of
> the system

No.  

>   Never mind the fact that I didn't actively install
> dash - it came in with dependencies and eventually decided to ignore
> my choice for /bin/sh to be manually linked to bash after several
> upgrades where it obeyed me).

Please feel free to file a bug if you have ideas for improving this.
At the very least, I imagine the release notes (package release-notes)
could use some improvement.

Thanks for reporting.

Happy thanksgiving,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#604993: dash as /bin/sh causes $PPID to be wrong in child when invoked via system() call

[Jonathan Nieder]

forcemerge 436466 604993 
tags 436466 + upstream
quit

Tim Connors wrote:

> 75428,46> /bin/bash -c "bash -c \"echo \\\$PPID ; ps \\\$PPID\""

Ah, I get it now.  This is Bug #436466 (dash: Please optimise single
command given to -c to exec it).

It falls cleanly into the "patches welcome" category[1].

> It causes the PPid line in /proc/$pid/status to be WRONG for any program
> or script if it was executed by the system() routine provided in libc

Survey of existing behavior:

$ for shell in dash ksh93 bash mksh pdksh
> do
>   $shell -c 'printf "%s " $$; bash -c "echo \$\$"'
> done
18832 18833
18834 18834
18835 18836
18837 18838
18839 18841
$ for shell in dash ksh93 bash mksh pdksh
> do
>   $shell -c 'bash -c "readlink /proc/\$PPID/exe"'
> done
/bin/dash
/bin/bash
/bin/bash
/bin/mksh
/bin/pdksh

POSIX and tradition do not require the bash/ksh behavior.  (See
http://austingroupbugs.net/ if you would like to change that.)

Have you tried "dpkg-reconfigure -plow dash"?  That should allow your
apps to continue working...

Regards,
Jonathan

[1] If you'd like to work on this, that would be excellent.  Please
feel free to email d...@vger.kernel.org with any work in progress.  No
subscription required, since the convention is to always cc all
participants.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#436466: dash: Please optimise single command given to -c to exec it

[Jonathan Nieder]

Hi Drake,

Drake Wilson wrote:

> Depending on how it's implemented, this can also cause a sort of
> inconsistency fault line.
[...]
> Inserting, say, a
> debugging echo before the actual command is virtually guaranteed to
> not exec the final command directly.

How do you like the ksh93 behavior?

Actually, let me take that back.  If you actually want a guarantee
that future versions of dash will have or lack this feature, you
can work with upstream[1] or the Austin common standards revision
group[2].

Hints:
. Since ksh93 (like ksh88, iirc) and bash already support this
  optimization and, well, it's been good for them, POSIX is not likely
  to change to forbid it.

. Goals for dash include code size, speed, POSIX conformance,
  simplicity, compatibility.  Patches with clear justification are
  much better received than arguments without patches (though bug
  reports are always appreciated).

Needless to say, a change in behavior is not going to happen in time
for squeeze regardless.

Thanks for your interest,
Jonathan

[1] d...@vger.kernel.org
[2] http://www.opengroup.org/austin/



-- 
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

[Jonathan Nieder]

Package: apt-listbugs
Version: 0.1.3
Severity: minor

 [...]
 Fetched 679KiB in 5s.
 ^C/usr/sbin/apt-listbugs:228:in ``': Interrupt
 from /usr/sbin/apt-listbugs:228
 E: dpkg 'pre' action '/usr/sbin/apt-listbugs apt || exit 10' returned non-zero 
status: 2
 E: error performing command 'full-upgrade'
 $

Listing full paths and line numbers like this gives a feeling that
something dangerous has happened.  Would it make sense to silently
accept the SIGINT, allowing cupt or apt to explain it (with exit
status 130)?

Alternatively, if status reporting is important for debugging reasons,
a message like the following would at least be less scary.

 apt-listbugs: received signal SIGINT on line 228
 E: dpkg 'pre' action '/usr/sbin/apt-listbugs apt || exit 10' returned non-zero
 [...]

Thanks for apt-listbugs.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605045: stuck modifier keys

[Jonathan Nieder]

Package: libx11-6
Version: 2:1.3.3-4
Severity: minor

1. Run xkbwatch.
2. Press and hold:
right shift
right control
fn
left alt
left shift
3. Release:
right shift
right control
fn
left alt
left shift

I expect no "LEDs" to remain on.  Instead, the first and third from
the right in the first, fourth, and fifth groups of LEDs remain on.

 [ ][ ][ ][ ][ ][#][ ][#]
[ ][ ][ ][ ][ ][ ][ ][ ] \
[ ][ ][ ][ ][ ][ ][ ][ ] \
[ ][ ][ ][ ][ ][#][ ][#] \
[ ][ ][ ][ ][ ][#][ ][#]

Tapping various modifiers eventually clears the LEDs.

Reproducible with xev so I suppose it is not an Xt bug.  I doubt this
is a libx11 bug, either, but one has to start somewhere.  I don't
think this is a regression, since it's been happening for a while.

Ideas?

Hardware:
Thinkpad G41.
Keyboard configuration:
XKBMODEL="thinkpad"
XKBLAYOUT="us"
XKBVARIANT="altgr-intl"
XKBOPTIONS="lv3:ralt_switch,terminate:ctrl_alt_bksp"
X server:
xserver-xorg-core   2:1.7.7-9
xserver-xorg-input-evdev 1:2.3.2-6
Kernel:
Linux 2.6.37-rc3

CONFIG_RFKILL_INPUT=y
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605045: stuck modifier keys

[Jonathan Nieder]

Jonathan Nieder wrote:

> 1. Run xkbwatch.
> 2. Press and hold:
>   right shift
>   right control
>   fn
>   left alt
>   left shift
> 3. Release:
>   right shift
>   right control
>   fn
>   left alt
>   left shift
> 
> I expect no "LEDs" to remain on.  Instead, the first and third from
> the right in the first, fourth, and fifth groups of LEDs remain on.

xserver-xorg-input-evdev bugscript output attached.
/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 ) 
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 ""
(==) 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 available, reconfigure udev or disable 
AutoAddDevices.
(II) Loader magic: 0x81ecca0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 6.0
X.Org XInput driver : 7.0
X.Org Server Extension : 2.0
(--) using VT number 7

(--) PCI:*(0:1:0:0) 10de:0324:1014:0571 nVidia Corporation NV34M [GeForce FX 
Go5200 64M] rev 161, Mem @ 0xc100/16777216, 0xe000/268435456
(II) Open ACPI successful (/var/run/acpid.socket)
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension SELinux
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extens

Bug#605041: git-gui: commit message box doesn't respond to enter (only return)

[Jonathan Nieder]

tags 605041 + upstream
quit

Hi David,

David Laban wrote:

> If I click into the messagebox and hit enter, nothing happens.
> 
> This is annoying because if I'm adding a new paragraph to my commit message, 
> I will often do   
> 
> Don't ask me why I do this. I think enter is a lighter/easier to press
> key than return, and is also on the path that my hand takes between the mouse
> and the rest of the keyboard.

Reported upstream; let's see what happens.

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#605039: apt-listbugs: scary message on interruption

[Jonathan Nieder]

Francesco Poli wrote:

> Hi Jonathan and thanks for your bug report!   ;-)

That was fast. :)

> Maybe the trap instruction should be moved before everything else:
> I have to think about it...

Maybe it is a ruby bug, then (the default signal handler), though that
is harder to say.

> And maybe the exit status should be turned into 130 ...
>
> I don't know when I can manage to find the time to do that.
> Anyway, Debian testing is currently in deep freeze, so *don't* expect to
> see this modification hit testing or unstable soon.

Yes, I don't expect a quick change; mostly wanted to record it in case
I find time to look at this later.

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#605041: git-gui: commit message box doesn't respond to enter (only return)

[Jonathan Nieder]

# [1]
forwarded 605041 
http://sf.net/tracker/?func=detail&aid=3119824&group_id=12997&atid=112997
reassign 605041 tk8.5 8.5.9-1
quit

Hi Sergei,

Konstantin Khomoutov wrote:

> I've tested it on Debian Squeeze and added another comment on the
> upstream bug report. In short: KP_Enter is not bound to any action in
> Tk text widgets in X11, at least in 8.5.9.

As [1] mentions, this means the behavior is inconsistent between X11
and Windows (in addition to being surprising).

> But git-gui can be trivially patched to support this; that would be a
> one-lineer. So if it is desired and will be accepted, I could prepare a
> patch.

That might make sense to do in git-gui upstream.  For Debian, let's
track the tk bug. :)

Thanks for looking into this.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605009: serious performance regression with ext4

[Jonathan Nieder]

Hi Ted,

Ted Ts'o wrote:

> 1) Suppose package contains files "a", "b", and "c".  Which are you
> doing?
> 
> a)  extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a);
> extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b);
> extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c);
> 
> or
> 
> b)  extract a.dpkg-new ; fsync(a.dpkg-new);
> extract b.dpkg-new ; fsync(b.dpkg-new);
> extract c.dpkg-new ; fsync(c.dpkg-new);
> rename(a.dpkg-new, a);
> rename(b.dpkg-new, b);
> rename(c.dpkg-new, c);
> 
> or
> 
> c)  extract(a.dpkg-new);
> extract(b.dpkg-new);
> extract(c.dpkg-new);
> fsync(a.dpkg-new);
> fsync(b.dpkg-new);
> fsync(c.dpkg-new);
> rename(a.dpkg-new, a);
> rename(b.dpkg-new, b);
> rename(c.dpkg-new, c);
> 
> 
> (c) will perform the best for most file systems, including ext4.
[...]
> I am guessing you are doing (a) today --- am I right?  (c) or (d)
> would be best.

We are doing (c) today.

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#605039: apt-listbugs: scary message on interruption

[Jonathan Nieder]

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.

Good to hear.  If you let me know when you push, I can look it over.

Thanks,
Jonathan
who is happy to get a chance to learn a little ruby



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605217: gitweb: false base href sent when integrated via reverse proxy and path_info is active

[Jonathan Nieder]

severity 605217 wishlist
tags 605217 + upstream
quit

Hi Daniel,

Daniel Reichelt wrote:

> I just noticed that integrating gitweb via reverse proxy is
> impossible when path_info is enabled in gitweb.conf. The base href
> sent on gitweb.cgi:3427 contains the "internal" URL called by the
> reverse proxy mechanism, not the original one called by the user
> agent which makes it impossible for the client to display CSS,
> images, etc...
> 
> I suggest an additional config variable, e.g.
> $feature{'pathinfo'}{'basehrefoverride'} which could override the
> base href tag determinted by the cgi script

Thanks for the suggestion.  Let's discuss it upstream.

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#556796: Please make a symbolic link /usr/bin/git-svn to /usr/lib/git-core/git-svn

[Jonathan Nieder]

# there are no plans to move the git-svn script or add a symlink.
tags 556796 + wontfix
thanks

Hi again,

Guillaume Yziquel wrote:

> git-svn should be available from /usr/bin, or at least from a place available
> in a sensible, usual, common $PATH. Moreover, as git svn tries to launch
> git-svn, git svn fails when $PATH is not set up with a /usr/lib/git-core
> location.

Still not sure how this could happen.  Given the lack of response, I'm
assuming it is not reproducible?  A more precise description of the
problem would still be very helpful.

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#469298: git-svn: option to update svn properties on old revisions

[Jonathan Nieder]

tags 469298 + upstream
quit

Hi Paul,

Paul Wise wrote:

> SVN supports updating the svn:log property (and others) on old revisions
> if there is a certain hook set. It would be nice if git could update
> these and rewrite the git commit logs to match the svn ones.

Yes, I agree.  Unfortunately I am not sure if this could be implemented as
transparently as I'd like.

svnsync has a copy-revprops subcommand to explicitly reexamine revision
properties for a collection of old revisions.  Does the svn protocol provide
a way to list revisions with changed properties after a certain moment, or
is this explicit reexamination always necessary?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#501761: git-svn --tags should at least /try/ to handle tags as tags

[Jonathan Nieder]

Hi,

Sorry for the long silence.

sean finney wrote:

> tagging the known working cases and leaving the rest of them as branches
> would work, but would leave you with a slightly inconsistant result (i.e.
> you'd also probably want to warn the user that they're missing some tags).
> 
> here's a few more alternatives for consideration:
[...]
> do the same as the previous suggestion, but instead of "leave as branch",
> tag the head (instead of the parent), and leave it as a headless commit.
[...]
> rename the tags branches as "svn-tags" and tag the heads of the branches
> as tags
[...]
> basically option 1 plus some git vodoo to prevent the ancestry
> history of the otherwise headless commit from being lost.

The problem with all these choices is that git (by design) does not
make changing tags easy.  While your local version of the tag would
advance as that tag-branch advances, others who fetch from you would
not notice.

Even worse, in the solutions that involve just deleting a tag, others
who fetch from you would keep the old tag but get the new branch, too,
so the result of

git log v9.29.3

would be missing recent revisions but "git log origin/v9.29.3" would
not.  Confusing.

Musings:

. Any change would be confusing. :)  If this gets implemented in
  git svn, it should be enabled by an option.

. The ideal would be to (1) _always_ fetch tags as tags and
  (2) disallow tag fixup revs altogether, unless some sort of --force
  option is used.  This would more closely match current git practice
  (see "On Re-tagging" in the "git tag" manual).

Thoughts on this would be very helpful because the same questions come
up in implementing "native" svn support for 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#605217: gitweb: false base href sent when integrated via reverse proxy and path_info is active

[Jonathan Nieder]

retitle 605217 gitweb.conf has no manual page
severity 605217 minor
quit

Daniel Reichelt wrote:

> I suggest an additional config variable, e.g.
> $feature{'pathinfo'}{'basehrefoverride'} which could override the
> base href tag determinted by the cgi script (or disable sending a
> base href tag at all - at least I was able to achieve my desired
> setup by adjusting the URLs for CSS etc in gitweb.conf to fitting
> absolute URLs).

It seems you're looking for $base_url.  Thanks for reporting (and
thanks to Jakub and Giuseppe for explaining).

I'm hijacking this bug to request a better manual page. :)
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#577471: git-core: git-blame.el require 'format-spec

[Jonathan Nieder]

tags 577471 + upstream fixed-upstream
quit

Hi Kevin,

Kevin Ryde wrote:

> M-x git-blame-mode
>
> gets an error
>
> error in process filter: Symbol's function definition is void: format-spec

Fixed by 0cb3f80 (git-blame.el: Add (require 'format-spec), 2010-05-25)
from 'maint', thus probably part of v1.7.3.3 when it comes out.

Thanks again for your help.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605217: gitweb: false base href sent when integrated via reverse proxy and path_info is active

[Jonathan Nieder]

clone 605217 -1
retitle -1 gitweb: $base_url configuration not respected
severity -1 important
close -1 git/1:1.7.2.3-2.1
quit

Daniel Reichelt wrote:

> Fine with me, thx. Cya upstream...

Mm, bookkeeping sometimes seems more trouble than it's worth.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605320: cupt: confusion about "hold" and source packages

[Jonathan Nieder]

Package: libcupt-perl
Version: 1.5.14.1

Hi Eugene et al, a mystery for you.

Hoping to test the latest libwww-curl-perl.  So:

 # cupt build-dep libwww-curl-perl
 Building the package cache... [done]
 Initializing package resolver and worker... [done]
 Scheduling requested actions... Can't locate object method "is_installed" via 
package "Cupt::Cache::SourceVersion" at /usr/share/perl5/Cupt/Cache.pm line 
415, <$fh> line 16006.
  at /usr/share/perl5/Cupt/Cache.pm line 415
 Cupt::Cache::get_pin('Cupt::Cache=ARRAY(0x95feff8)', 
'Cupt::Cache::SourceVersion=ARRAY(0x9294b80)') called at 
/usr/share/perl5/Cupt/Cache.pm line 506
 
Cupt::Cache::get_sorted_pinned_versions('Cupt::Cache=ARRAY(0x95feff8)', 
'Cupt::Cache::Package=ARRAY(0x9294bd0)') called at 
/usr/share/perl5/Cupt/Cache.pm line 537
 Cupt::Cache::get_policy_version('Cupt::Cache=ARRAY(0x95feff8)', 
'Cupt::Cache::Package=ARRAY(0x9294bd0)') called at /usr/bin/cupt line 284
 main::select_package_version('libwww-curl-perl', 'CODE(0x95548e0)', 0) 
called at /usr/bin/cupt line 304
 main::select_source_package_version('libwww-curl-perl', 1) called at 
/usr/bin/cupt line 1666
 main::manage_packages('build-depends') called at /usr/bin/cupt line 140
 main::__ANON__() called at /usr/bin/cupt line 152
 eval {...} called at /usr/bin/cupt line 151
 main::main() called at /usr/bin/cupt line 166
  at /usr/share/perl5/Cupt/Core.pm line 103
 Cupt::Core::mycatch() called at /usr/bin/cupt line 154
 main::main() called at /usr/bin/cupt line 166

/usr/share/perl5/Cupt/Cache.pm says:

sub get_pin ($$) {
[...]
# discourage downgrading 
# downgradings will usually have pin <= 0
if (defined $self->_system_state) { # for example, for source 
versions will return false...
[...]
if ($installed_info->{'want'} eq 'hold' 
&& $version->is_installed()) {
$result += 
$self->_config->get_number('cupt::cache::obey-hold');
}

Line 415 is the "if ($installed_info->..." line.  Also probably relevant:

$ dpkg --get-selections | grep hold
ifupdownhold
libwww-curl-perlhold

Taking the package off hold fixes it, so no harm done.

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#601694: WWW::Curl 4.15 uploaded

[Jonathan Nieder]

Salvatore Bonaccorso wrote:

> I just uploaded new version of libwww-curl-perl 4.15-1. Could you
> please try if the problem is solved for you as, when the new package
> enters the archive?

Yes, it works now.

Eugene, if you don't plan to add a temporary versioned dependency to
help the Ubuntu people :) (and other derivatives), please feel free to
close the bug.

Thanks, Bálint, James, and Salvatore.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605330: xserver-xorg: cupt full-upgrade pulls in xserver-xorg-input-wacom

[Jonathan Nieder]

Package: cupt
Version: 1.5.14.1
Severity: wishlist

Hi,

xserver-xorg has dependencies

 Depends:
xserver-xorg-core (>= 2:1.9.0.901),
xserver-xorg-video-all | xorg-driver-video,
xserver-xorg-input-all | xorg-driver-input,
xserver-xorg-input-evdev,
libc6 (>= 2.7),
xkb-data (>= 1.4),
x11-xkb-utils

I have already chosen which input drivers I want (synaptics and evdev)
and which video drivers I want (nouveau).  So the dependencies are
satisfied by the second alternative (xorg-driver-video / xorg-driver-input).

Unfortunately "cupt full-upgrade" doesn't realize this until I say "no"
a few times.

Questions:

 . cupt is happy about the lack of video drivers but not the input
   drivers.  Is that because of the extra ...-input-evdev dependency?

 . can I specify my preference on the command line instead of saying
   "no, no, no"?  e.g.,

cupt full-upgrade --without=xserver-xorg-input-all

   would be convenient.

 . even better, would it make sense to allow such rich information
   to be provided instead of "yes/no" in response to the suggested list
   of packages?

I imagine it could be useful to clone this bug for whichever
suggestions make sense and then close 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#604166: unblock: tap-plugins/0.7.1-1

[Jonathan Nieder]

Hi,

Alessio Treglia wrote:

> Please unblock tap-plugins 0.7.1-1

Here are the obvious reactions. :)

 - new upstream point release.  previous version is from 5 years ago,
   before the PTS learned about testing migration.
 - the proposed version has been in sid for about seven months
 - no open bugs
 - popcon vote: 473.  seems like a sizable, growing user base.

 - the new upstream version:
   + addresses some bugs:
 . 64-bit cleanliness
 . floating-point underflow handling
 . uninitialized values
 . dangerous typo in Makefile
   + adds a new and very simple stereophonic-to-binaural plugin
   + I haven't read the diff in detail, but it seems small and reviewable
 - the packaging changes are bigger than ideal for this moment in the
   freeze --- in particular, a debian/rules rewrite.  Do they fix a bug?

Maybe a more minimal update is possible?

Of course I am not a member of the release team, so if that seems like
a lot of trouble, it is probably best to ping them first.

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#501761: git-svn --tags should at least /try/ to handle tags as tags

[Jonathan Nieder]

Paul Wise wrote:
> On Sun, 2010-11-28 at 12:03 -0600, Jonathan Nieder wrote:

>> Thoughts on this would be very helpful because the same questions come
>> up in implementing "native" svn support for git.
>
> At the very least git svn --convert should do these:
> 
>  1. SVN tags that are actually tags in SVN (ie dir copies with no
> non-copy commits) are converted to git tags.
>  2. SVN tags that are actually branches in SVN despite being labeled
> tags (these exist unfortunately) are left as branches.

... and what happens when a tag changes from (1) to (2)?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605009: serious performance regression with ext4

[Jonathan Nieder]

(pruned cc list)

Guillem Jover wrote:

> Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> instead, skimming over the kernel source seems to indicate it might
> end up doing more or less the same thing but in a portable way?

Probably a silly question, but what does "The specified data will not
be accessed in the near future" have to do with preventing delayed
allocation?

Put another way: if this works now, is it likely to continue to work?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605009: serious performance regression with ext4

[Jonathan Nieder]

Hi Guillem,

Guillem Jover wrote:

> Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> instead, skimming over the kernel source seems to indicate it might
> end up doing more or less the same thing but in a portable way?
> 
> Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch
> against dpkg?

ext4: yes, this brings the running time down from 34sec to 10.5sec,
just like sync_file_range with SYNC_FILE_RANGE_WRITE does.

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#605009: serious performance regression with ext4

[Jonathan Nieder]

Ted Ts'o wrote:
> On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:

>> It means we don't need to keep it in RAM since we're not going to
>> read/modifiy it again in the near future. Thus the writeback can be
>> started right now since delaying it will not save us anything.
>>
>> At least that's the way I understand the situation.
>
> Yes, that's correct.  The fadvise() will do two things; it will start
> the writeback, and also make these memory pages be the most likely to
> be discarded.

That explanation helps a lot.  Thanks, both.  (Guillem, I like your
patch very much then.  Most files being unpacked in a dpkg run aren't
going to be read back again soon.  Perhaps some other kernels will
also interpret it as a hint to start writeback.)

> The reason why I suggested using sync_file_range() is because it is
> very specifically directed at forcing the writeback to happen, which
> is not quite the same thrust as posix_fadvise().

I suppose a patch to adopt the optimization you suggested ought to
also do the sync_file_range() directly to be explicit.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605009: When to use POSIX_FADV_DONTNEED (Re: Bug#605009: serious performance regression with ext4)

[Jonathan Nieder]

Ted Ts'o wrote:

> Most files won't, but consider a postinstall script which needs to
> scan/index a documentation file, or simply run one or more binaries
> that was just installed.  I can definitely imagine situations where
> using POSIX_FADV_DONTNEED could actually hurt performance.

Hmm.  Maybe file triggers could suppress DONTNEED.  A nice side-effect
might be to encourage use of file triggers. :)

> If you are only installing a one or a few packages, and/or you can
> somehow divine the user's intention that they will very shortly use
> the file --- for example, if dpkg is being launched via packagekit to
> install some font or codec, then using POSIX_FADV_DONTNEED is probably
> the wrong answer.

Even then, documentation extracted to /usr/share/doc doesn't need to
be cached.  I suppose some timing and tweaking would be needed.

The cases to optimize most for imho are

 1) initial installation (would use --force-unsafe-io)
 2) apt-get dist-upgrade; xterm
 3) apt-get install openoffice.org; oowriter
 4) apt-get build-dep ; dpkg-buildpackage

since these are the most painful when they are slow.

So I agree, this is not cut and dry.  But being able to use the same
function and have it (hopefully) do something roughly sane on a
variety of kernels is very appealing.

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605410: chromium-browser: spurious "dangerous download" prompt for PDFs

[Jonathan Nieder]

Package: chromium-browser
Version: 9.0.587.0~r66374-1
Severity: minor
Tags: upstream
Forwarded: http://crbug.com/9044

Every time I click on a PDF, chromium "cries wolf" by telling me it
would be unsafe to open it.

I do not have mozplugger installed.  This is the usual file download
prompt in the lower-left hand corner.  Luckily upstream seems to be on
the case. :)

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#605330: xserver-xorg: cupt full-upgrade pulls in xserver-xorg-input-wacom

[Jonathan Nieder]

clone 605330 -1 -2
retitle -1 cupt.1: making management modifiers more discoverable
owner -1 !
retitle -2 cupt: "Do you want to continue?" "Yes, but without such-and-such 
package."
quit

Eugene V. Lyubimkin wrote:
> On 2010-11-28 16:28, Jonathan Nieder wrote:

>>  . cupt is happy about the lack of video drivers but not the input
>>drivers.  Is that because of the extra ...-input-evdev dependency?
>
> Maybe. Debug resolver log (-o debug::resolver=1) is needed to (dis)prove
> that.

Attached.

>>  cupt full-upgrade --without=xserver-xorg-input-all
>>
>>would be convenient.
>
> At least for this case, yes. 'cupt full-upgrade
> xserver-xorg-input-all-'. It's documented in cupt(1) in subsection
> 'management modifiers'.

I tried "-xserver-xorg-input-all". :)

> Patches how to make them more visible are
> welcome :)

Will look into it.

>>  . even better, would it make sense to allow such rich information
>>to be provided instead of "yes/no" in response to the suggested list
>>of packages?
>
> Umm, I didn't understand this one. Could you please explain by example?

$ cupt full-upgrade
Building the package cache... [done]
Initializing package resolver and worker... [done]
Scheduling requested actions... [done]
Resolving possible unmet dependencies... 
The following 2 packages will be INSTALLED:

xserver-xorg-input-all xserver-xorg-input-wacom 

The following 5 packages will be REMOVED:

libbz2-dev libncursesw5-dev libselinux1-dev libsepol1-dev po4a 

Need to get 0B/95.0KiB of archives. After unpacking 6644KiB will be 
freed.
==> Do you want to continue? [y/N/q] xserver-xorg-input-all-
Scheduling requested actions... [done]
Resolving possible unmet dependencies...

The following 5 packages will be REMOVED:

libbz2-dev libncursesw5-dev libselinux1-dev libsepol1-dev po4a
Do you want to continue? [y/N/q] YES, why yes I do.
D: install package 'xserver-xorg', version '1:7.6~2'
D: install package 'xserver-xorg-input-synaptics', version '1.3.0-1'
D: install package 'perl-base', version '5.12.2-2'
D: install package 'libsoup2.4-1', version '2.31.2-1'
D: install package 'xserver-xorg-input-evdev', version '1:2.5.99.901-1'
D: install package 'perl-modules', version '5.12.2-2'
D: install package 'xserver-xorg-core', version '2:1.9.2-1'
D: install package 'perl-debug', version '5.12.2-2'
D: install package 'perl', version '5.12.2-2'
D: install package 'perl-doc', version '5.12.2-2'
D: started resolving
D: (0:0.0) problem: package 'liblocale-gettext-perl': unsatisfied pre_depends 
'perlapi-5.10.0'
D: (0:0.0) -> (1,Δ:-4209.0,qΔ:+50.0) trying: package 'liblocale-gettext-perl': 
'1.05-6' -> ''
D: (0:0.0) -> (2,Δ:-4900.0,qΔ:+50.0) trying: package 'perl-base': '5.12.2-2' -> 
'5.10.1-16'
D:  (1:-4159.0) problem: package 'debconf-i18n': unsatisfied depends 
'liblocale-gettext-perl'
D:  (1:-4159.0) -> (1,Δ:-3005.6,qΔ:+46.7) trying: package 'debconf-i18n': 
'1.5.36' -> ''
D:   (1:-7117.9) problem: package 'libapt-pkg-perl': unsatisfied depends 
'perlapi-5.10.1'
D:   (1:-7117.9) -> (1,Δ:-3767.6,qΔ:+44.8) trying: package 'libapt-pkg-perl': 
'0.1.24build1' -> ''
D:(1:-10840.8) problem: package 'libcrypt-ssleay-perl': unsatisfied depends 
'perlapi-5.10.0'
D:(1:-10840.8) -> (1,Δ:-350.3,qΔ:+43.5) trying: package 
'libcrypt-ssleay-perl': '0.57-2' -> ''
D: (1:-11147.5) problem: package 'libdbd-sqlite3-perl': unsatisfied depends 
'perlapi-5.10.1'
D: (1:-11147.5) -> (1,Δ:-350.3,qΔ:+42.6) trying: package 
'libdbd-sqlite3-perl': '1.29-3' -> ''
D:  (1:-11455.3) problem: package 'libdbi-perl': unsatisfied depends 
'perlapi-5.10.1'
D:  (1:-11455.3) -> (1,Δ:-350.3,qΔ:+41.8) trying: package 'libdbi-perl': 
'1.612-1' -> ''
D:   (1:-11763.8) problem: package 'libfcgi-perl': unsatisfied depends 
'perlapi-5.10.1'
D:   (1:-11763.8) -> (1,Δ:-350.3,qΔ:+41.2) trying: package 'libfcgi-perl': 
'0.71-1' -> ''
D:(1:-12072.9) problem: package 'libhtml-parser-perl': unsatisfied 
depends 'perlapi-5.10.1'
D:(1:-12072.9) -> (1,Δ:-350.3,qΔ:+40.6) trying: package 
'libhtml-pars

Bug#605330: xserver-xorg: cupt full-upgrade pulls in xserver-xorg-input-wacom

[Jonathan Nieder]

Eugene V. Lyubimkin wrote:

> Ok, looked. No, -input-evdev is unrelated here, the problem is located
> deeper in resolver's algorithm. Need to think about problem's roots more
> and what can I do with it (so let's keep this bug open, at least for
> now). 

The log says:

. We'd like to upgrade perl to v5.12 and X to v7.6 from experimental
  (because that's the policy), and that upgrade seems good to go.
  But:

. liblocale-gettext-perl requires v5.10.  Uninstall it.
. Alternatively, we could downgrade perl-base.
. Uninstalling liblocale-gettext-perl means:
  ... many bad things ...
. Okay, how about downgrading perl?  Next problem:
  . X 7.6 broke ABI, so we wouldn't be able to use nouveau any more.
Solution: downgrade X core or uninstall nouveau.
. How about downgrading X core?  Next problems:
  . perl, perl-debug, perl-doc, perl-modules, and perl-base versions tied.
Solution: downgrade.  Next problem:
. X metapackage version tied to X core version.
  Solution: downgrade.  Next problem:
  . X metapackage requires xserver-xorg-input-7.
Don't have that.  So we take the default (...-input-all).

Conclusions:

 . Proximate cause: nouveau in experimental has not been updated for
   the new video ABI, so cupt needs to back out the X upgrade.

 . Underlying cause: the old-style xorg packaging gets dependencies
   backwards.  See [1].

 . How cupt could help: use the list of previously installed packages
   when picking between alternatives to satisfy a dependency.

[1] http://blog.ikibiki.org/2010/11/10/XServer_1.9/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#469298: git-svn: option to update svn properties on old revisions

[Jonathan Nieder]

clone 469298 -1
retitle -1 subversion: please add an RA call to list revprop edits (for svnsync 
and friends)
reassign -1 subversion 1.6.12dfsg-2
tags -1 + upstream
submitter -1 !
quit

Peter Samuelson wrote:
> [Jonathan Nieder]

>> svnsync has a copy-revprops subcommand to explicitly reexamine
>> revision properties for a collection of old revisions.  Does the svn
>> protocol provide a way to list revisions with changed properties
>> after a certain moment, or is this explicit reexamination always
>> necessary?
>
> Pretty sure there is no such API.

Admins that want to encourage casual copying of full history might
benefit from one.  (Mentioned recently at [1].)  Recording the bug
so I don't forget.

Thanks, that was helpful.
Jonathan

[1] 
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122840/focus=122944



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#548971: ifupdown: Does not work with isa dhcp 4.0 client

[Jonathan Nieder]

forcemerge 544371 548971
quit

Dean Menezes wrote:

> DHCP is not configured with my connection -- instead, I have to
> manually type in:
> 
> sudo dhclient wlan0
> 
> However, I have "inet dhcp" in my config file.  Here is the contents
> of /etc/network/interfaces:

See http://bugs.debian.org/544371 for analysis and a patch.

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#546931: /var/run/dhclient.eth0.pid: interface name too long (is 26)

[Jonathan Nieder]

forcemerge 544371 546931
quit

Cade Robinson wrote:

> dhclient provided with isc-dhcp-client 4.1.0-1 can't handle the default
> pid file name used when using ifup.
[...]
> ii  ifupdown0.7~alpha3   high level tools to configure 
> netw

See http://bugs.debian.org/544371 for analysis and a patch.

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#583693: .git/info/sparse-checkout syntax is finicky for directories

[Jonathan Nieder]

# [1]
forwarded 583693 http://thread.gmane.org/gmane.comp.version-control.git/162265
tags 583693 + patch
quit

Hi Frédéric,

Nguyen Thai Ngoc Duy wrote:

> I'm sorry too for not fixing this for so long :) The defect is known
> (test "match directories without trailing slash", t1011). The reason
> is known, as Jonathan pointed out, index does not have "directories".
> A fix is not easy though.

Now there is a fix to play with.

Please feel free to try it out, kick the tires, read it to see if
it makes any sense.  Patches are at [1].

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#515793: RFP: cgit -- C-code Web Front-end to GIT

[Jonathan Nieder]

Hi,

YAEGASHI Takeshi wrote:

> I know such a package is undesirable, but I wonder if it's completely
> unacceptable for the Debian distribution.

As mentioned a few times before, I think it would be simplest to just
add cgit to the git package.  If someone using cgit wants to be a
co-maintainer I'm happy to let them maintain the cgit packaging
however they like.

I can write a patch demonstrating what I mean making use of your
packaging from http://git.keshi.org/debian/cgit.git if you like.  What
do you think?

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#739655: libcommons-compress-java: TarArchiveInputStream copes poorly with short reads from underlying stream

[Jonathan Nieder]

Package: libcommons-compress-java
Version: 1.6-1
Tags: upstream patch fixed-upstream
Severity: important
Justification: regression
Control: forwarded -1 https://issues.apache.org/jira/browse/COMPRESS-245

Hi,

>From upstream issue COMPRESS-245:

The attached archive decompressed with 1.6 only extracts part
of the archive. This does not happen with version 1.5

FileInputStream fin = new FileInputStream("exampletar.tar.gz");
GZIPInputStream gin = new GZIPInputStream(fin);
TarArchiveInputStream tin = new TarArchiveInputStream(gin);
TarArchiveEntry entry;
while ((entry = tin.getNextTarEntry()) != null) {

Fixed by r1548380 "COMPRESS-245 TarArchiveInputStream might fail to
read a stream if a single call to read() returns less than a full
record":

--- 
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStream.java
  (revision 1548379)
+++ 
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStream.java
  (revision 1548380)
@@ -385,7 +385,7 @@
 
 byte[] record = new byte[recordSize];
 
-int readNow = is.read(record);
+int readNow = IOUtils.readFully(is, record);
 count(readNow);
 if (readNow != recordSize) {
 return null;

r1548388 "testcase for COMPRESS-245 provided by Andreas Aronsson"
has a test.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#739991: GIT_CURL_VERBOSE=1 logs too much

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20140214-1
Severity: important
Tags: upstream

Output from using GIT_CURL_VERBOSE=1 to debug git-over-http includes
unredacted Cookie and Authorization header fields.  People trying to
debug therefore leak their credentials too easily.

It would be better to

 (a) leave out the Cookie and Authorization headers completely, or

 (b) censor them (e.g., apply a custom regex substitution to Cookie
 fields; redact whatever comes after 'Basic' for Authorization
 fields)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#726004: Please make remote-helper accessible in the standard path

[Jonathan Nieder]

reassign 726004 src:git 1:1.8.4~rc3-1
merge 703864 726004
quit

Hi,

Thomas Goirand wrote:

> Currently, the Git package provides git-remote-bzr and git-remote-hg in
> /usr/share/doc/git/contrib/remote-helpers. However, these are only helpful
> if they are accessible in the standard path.

See http://bugs.debian.org/702697 and http://bugs.debian.org/703864.

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#736144: python-webm: needs update for libwebp5

[Jonathan Nieder]

tags 736144 + pending
quit

Hi Dmitry,

Julien Cristau wrote:

> libwebp changed SONAMEs again, libwebp4 is being replaced by libwebp5,
> so python-webm needs a rebuild (and possibly an update to take the ABI
> changes into account).

I've rebuilt python-webm and uploaded to DELAYED/5 to fix this.  If I
should cancel the upload or push to collab-maint and move it to
DELAYED/0, please don't hesitate to let me know.

Thanks,
Jonathan
diff -Nru python-webm-0.2.2/debian/changelog python-webm-0.2.2/debian/changelog
--- python-webm-0.2.2/debian/changelog  2013-08-23 22:40:30.0 -0700
+++ python-webm-0.2.2/debian/changelog  2014-01-23 16:36:25.0 -0800
@@ -1,3 +1,10 @@
+python-webm (0.2.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for libwebp transition (Closes: #736144)
+
+ -- Jonathan Nieder   Thu, 23 Jan 2014 16:36:23 -0800
+
 python-webm (0.2.2-2) unstable; urgency=low
 
   * Added support for loseless modes using patch from Antoine Martin;

Bug#735746: pillow: FTBFS: _imagingtk.cpython-33m.so not found

[Jonathan Nieder]

merge 735746 735803
block 731168 by 735746
tags 735746 + patch
quit

Hi Matthias,

Roland Stigge wrote:

> pillow FTBFS like this:
[...]
> abitag=.$(python3.3 -c "import sysconfig; 
> print(sysconfig.get_config_var('SOABI'))"); \
>   dh_movefiles -ppython3-pil.imagetk \
>   --sourcedir=debian/python3-pil \
>   usr/lib/python3/$(basename $(_py_=3.3; python${_py_#python*} -c 
> 'from distutils import sysconfig; 
> print(sysconfig.get_python_lib())'))/PIL/_imagingtk$abitag.so \
>   usr/lib/python3/$(basename $(_py_=3.3; python${_py_#python*} -c 
> 'from distutils import sysconfig; 
> print(sysconfig.get_python_lib())'))/PIL/ImageTk.py
> dh_movefiles: 
> debian/python3-pil/usr/lib/python3/dist-packages/PIL/_imagingtk.cpython-33m.so
>  not found (supposed to put it in python3-pil.imagetk)
> make: *** [install3-python3.3] Error 1

Yes, I can reproduce this.  Some files that do exist:


debian/python3-pil/usr/lib/python3/dist-packages/PIL/_imagingtk.cpython-33m-x86_64-linux-gnu.so
build/lib.linux-x86_64-3.3/PIL/_imagingtk.cpython-33m.so

This is fallout from the python 3.3.3-5 update ("On installation with
--install-layout=deb, rename extensions to include the multiarch
tag").  This patch fixes it.
---
Thoughts?

Thanks,
Jonathan

 debian/changelog | 8 
 debian/control   | 2 +-
 debian/rules | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f921140..e16d960 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pillow (2.2.1-3.1) local; urgency=medium
+
+  * Adjust installation rules for python3 extensions to include multiarch
+tag. Closes: #735746.
+  * Build-conflict on python3.3 (<< 3.3.3-5).
+
+ -- Jonathan Nieder   Fri, 24 Jan 2014 14:45:35 -0800
+
 pillow (2.2.1-3) unstable; urgency=low
 
   * Add PngImagePlugin.py to PILcompat directory.
diff --git a/debian/control b/debian/control
index 8ddd2e7..5b9f8d2 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper, tk8.5-dev, dpkg-dev (>= 1.16.1~),
   python-tk, python-tk-dbg, python3-tk, python3-tk-dbg (>= 3.3),
   libsane-dev, libfreetype6-dev, libjpeg8-dev, zlib1g-dev, liblcms2-dev,
   libwebp-dev
-Build-Conflicts: python-numarray
+Build-Conflicts: python-numarray, python3.3 (<< 3.3.3-5)
 Standards-Version: 3.9.5
 XS-Testsuite: autopkgtest
 
diff --git a/debian/rules b/debian/rules
index f7eb159..8bd84e6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -145,6 +145,7 @@ install3-python%:
debian/python3-pil/$$incdir
 
abitag=.$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('SOABI'))"); \
+   abitag=$$abitag-$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('MULTIARCH'))"); \
dh_movefiles -ppython3-pil.imagetk \
--sourcedir=debian/python3-pil \
usr/lib/python3/$(call py_sitename_sh, 
$*)/PIL/_imagingtk$$abitag.so \
@@ -169,6 +170,7 @@ install3-python%:
find debian/python3-pil*-dbg -depth -empty -exec rmdir {} \;
 
abitag=.$$(python$*-dbg -c "import sysconfig; 
print(sysconfig.get_config_var('SOABI'))"); \
+   abitag=$$abitag-$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('MULTIARCH'))"); \
dh_movefiles -ppython3-pil.imagetk-dbg \
--sourcedir=debian/python3-pil-dbg \
usr/lib/python3/$(call py_sitename_sh, 
$*)/PIL/_imagingtk$$abitag.so
-- 
1.8.5.3


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736568: git makes it too hard to understand corrupted git almost-repos

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20140117-1
Severity: wishlist
Tags: upstream

Corrupting a repository sometimes makes it essentially invisible as
far as commands like "git rev-parse --git-dir" care, for example if
the refs/ subdir of a .git dir was removed.  Worse, git doesn't
diagnose the problem except by saying it couldn't find a git
repository.

Potential fixes:

 1. A new command 'git rev-parse --why-u-no-git-dir '
(or an option to fsck?) could try each test for a git repository
in turn and figure out which ones failed.

 2. Code that looks for a git repository could warn when it both
(a) failed to find a git repository and (b) found something that
was almost a git repository and then automatically use the code
from (1) to help the caller diagnose the problem.

Noticed by Cristian Ciupitu during the conversation surrounding
http://colabti.org/irclogger/irclogger_log/git?date=2014-01-25#l96


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735746: pillow: FTBFS: _imagingtk.cpython-33m.so not found

[Jonathan Nieder]

tags 735746 + pending
quit

Hi Matthias,

Jonathan Nieder wrote:

> +  * Adjust installation rules for python3 extensions to include multiarch
> +tag. Closes: #735746.
> +  * Build-conflict on python3.3 (<< 3.3.3-5).

I've uploaded this fix to DELAYED/2.  If I should cancel the upload or
move it to DELAYED/0, please don't hesitate to let me know.

Thanks,
Jonathan
diff -Nru pillow-2.2.1/debian/changelog pillow-2.2.1/debian/changelog
--- pillow-2.2.1/debian/changelog   2013-12-16 04:07:11.0 -0800
+++ pillow-2.2.1/debian/changelog   2014-01-26 14:39:11.0 -0800
@@ -1,3 +1,12 @@
+pillow (2.2.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adjust installation rules for python3 extensions to include multiarch
+tag. Closes: #735746.
+  * Build-conflict on python3.3 (<< 3.3.3-5).
+
+ -- Jonathan Nieder   Sun, 26 Jan 2014 14:39:10 -0800
+
 pillow (2.2.1-3) unstable; urgency=low
 
   * Add PngImagePlugin.py to PILcompat directory.
diff -Nru pillow-2.2.1/debian/control pillow-2.2.1/debian/control
--- pillow-2.2.1/debian/control 2013-12-16 04:08:46.0 -0800
+++ pillow-2.2.1/debian/control 2014-01-26 14:34:29.0 -0800
@@ -8,7 +8,7 @@
   python-tk, python-tk-dbg, python3-tk, python3-tk-dbg (>= 3.3),
   libsane-dev, libfreetype6-dev, libjpeg8-dev, zlib1g-dev, liblcms2-dev,
   libwebp-dev
-Build-Conflicts: python-numarray
+Build-Conflicts: python-numarray, python3.3 (<< 3.3.3-5)
 Standards-Version: 3.9.5
 XS-Testsuite: autopkgtest
 
diff -Nru pillow-2.2.1/debian/rules pillow-2.2.1/debian/rules
--- pillow-2.2.1/debian/rules   2013-11-11 16:13:43.0 -0800
+++ pillow-2.2.1/debian/rules   2014-01-26 14:34:29.0 -0800
@@ -145,6 +145,7 @@
debian/python3-pil/$$incdir
 
abitag=.$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('SOABI'))"); \
+   abitag=$$abitag-$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('MULTIARCH'))"); \
dh_movefiles -ppython3-pil.imagetk \
--sourcedir=debian/python3-pil \
usr/lib/python3/$(call py_sitename_sh, 
$*)/PIL/_imagingtk$$abitag.so \
@@ -169,6 +170,7 @@
find debian/python3-pil*-dbg -depth -empty -exec rmdir {} \;
 
abitag=.$$(python$*-dbg -c "import sysconfig; 
print(sysconfig.get_config_var('SOABI'))"); \
+   abitag=$$abitag-$$(python$* -c "import sysconfig; 
print(sysconfig.get_config_var('MULTIARCH'))"); \
dh_movefiles -ppython3-pil.imagetk-dbg \
--sourcedir=debian/python3-pil-dbg \
usr/lib/python3/$(call py_sitename_sh, 
$*)/PIL/_imagingtk$$abitag.so

Bug#735509: transition: leptonlib

[Jonathan Nieder]

block 735509 by 731168
quit

Hi,

Jeff Breidenbach wrote:

> Leptonica upstream is releasing a new version that will
> have an increased soname (liblept3 -> liblept4). No exotic
> challenges expected.

This is a tiny transition: the only source package that will need
rebuilding is tesseract.

 $ grep-dctrl -FBuild-Depends libleptonica-dev -sPackage *
 Package: tesseract

Based on a quick test, tesseract builds and runs ok against leptonlib
from experimental.

'ben' parameters:

Affected: .build-depends ~ /libleptonica-dev/
Good: .depends ~ /liblept4/
Bad: .depends ~ /liblept3/

It should presumably wait for the libwebp transition due to the
overlap.  


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#628515: recommending verbose build logs

[Jonathan Nieder]

Hi,

Matthias Klose wrote:

> This issue is now again silent for eight months.  Is there anything missing, 
> or
> any other reason why the issue doesn't see any progress?

I believe there is a consensus that packages should produce verbose
build logs by default and can optionally produce terse logs with
DEB_BUILD_OPTIONS=terse and this is just waiting on someone to propose
wording in policy to that effect.

A patch against git://git.debian.org/dbnpolicy/policy.git is best, but
rough proposed wording ("in section x, add: ...") is also fine.

Thanks for poking.

Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737174: gitolite 2 is broken by git 1.9-rc0 and newer

[Jonathan Nieder]

Package: gitolite
Version: 2.3-1
Severity: important
Tags: upstream patch

gl-compile-conf breaks with git 1.9-rc0 and newer ("* AAARGH! *
your git version is older than 1.6.6").  Luckily Debian package
dependencies mean we don't need a version check at all, so how about
this patch?

Suggested by sitaramc[1].

[1] http://thread.gmane.org/gmane.comp.version-control.git/241151/focus=241284
---
Thanks,
Jonathan

 src/gl-compile-conf | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/src/gl-compile-conf b/src/gl-compile-conf
index f497ae5..eb96d95 100755
--- a/src/gl-compile-conf
+++ b/src/gl-compile-conf
@@ -382,29 +382,6 @@ parse_conf_file($GL_CONF, 'master');
 # 
 
 # 
-#   what's the git version?
-# 
-
-# we don't like stuff older than 1.6.6
-
-my $git_version = `git --version`;
-die "
-*** ERROR ***
-did not get a proper version number.  Please see if git is in the PATH on
-the server.  If it is not, please edit ~/.gitolite.rc on the server and
-set the \$GIT_PATH variable to the correct value\n
-" unless $git_version;
-my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version 
(\d+)\.(\d+)\.(\d+)/);
-die "$ABRT I can't understand $git_version\n" unless ($gv_maj >= 1);
-$git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel;  # now it's 
"normalised"
-
-die "\n\t\t* AAARGH! *\n" .
-"\tyour git version is older than 1.6.6\n" .
-"\tsince that is now more than one year old, and gitolite needs some of\n" 
.
-"\tthe newer features, please upgrade.\n"
-if $git_version < 10606; # that's 1.6.6 to you
-
-# 
 # most of the rest of this program can be "switched off"; see
 # doc/big-config.mkd for details.
 # 
-- 
1.9.rc1.175.g0b1dcb5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737232: git upgrade breaks gitolite 2

[Jonathan Nieder]

Package: git
Version: 1:1.9~rc1-1
Severity: serious
Justification: broken upgrade
Control: block -1 by 737174

In the 1.9-rc series, Git has a 2-component instead of 3-component
version number for the first time, breaking gitolite 2 (but not
gitolite 3).  http://bugs.debian.org/737174 has details.

A Breaks against unfixed versions of gitolite is needed to make sure
upgrades happen in the right order.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735509: transition: leptonlib

[Jonathan Nieder]

Hi,

Jonathan Nieder wrote:
> Jeff Breidenbach wrote:

>> Leptonica upstream is releasing a new version that will
>> have an increased soname (liblept3 -> liblept4). No exotic
>> challenges expected.
>
> This is a tiny transition: the only source package that will need
> rebuilding is tesseract.
>
>  $ grep-dctrl -FBuild-Depends libleptonica-dev -sPackage *
>  Package: tesseract
>
> Based on a quick test, tesseract builds and runs ok against leptonlib
> from experimental.
>
> 'ben' parameters:
>
> Affected: .build-depends ~ /libleptonica-dev/
> Good: .depends ~ /liblept4/
> Bad: .depends ~ /liblept3/
>
> It should presumably wait for the libwebp transition due to the
> overlap.  

... and the libwebp transition is now done.

Ok to go ahead and upload leptonlib to unstable?

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#737559: copyright-format: author != copyright, add an author field?

[Jonathan Nieder]

severity 737559 wishlist
user debian-pol...@packages.debian.org
usertags 737559 = normative issue
quit

Hi Daniel,

Daniel Pocock wrote:

> Author and copyright holder are not always the same person/entity.
[...]
> License: GPL2
> Copyright: 2014, Acme, Inc http://acme.example.org
> Author: Bob, http://example.org/bob

Sure.  A few thoughts:

 - I don't think debian/copyright needs to list everyone who
   contributed to the code --- to me, the copyright holders and some
   contact information for upstream seem more important, and the
   detailed authorship information can go elsewhere (e.g., a README or
   THANKS file, or the changelog).  But policy's more ambiguous about
   that.  See http://bugs.debian.org/678607.

 - The above is already valid syntax, since custom fields can be added
   to any paragraph.  Feel free to try it and let us know how it goes.
   (copyright-format sayeth:

No prefixing is necessary or desired, but please avoid names
similar to standard ones so that mistakes are easier to catch.
Future versions of the debian/copyright specification will
attempt to avoid conflicting specifications for widely used
extra fields.

   )

 - Response when this last came up[1]:

This is nice in spirit, but I would personnally not feel like
maintaining a contributor list, because there is mostly only
blame to get in case it is inaccurate, so I would only use the
field to point at a contributors file.

This is the kind of field that I would prefer to see tested in
real life before being standardised in DEP-5.

So, I think this is a reasonable idea, and if more than two or so
packages start using the field then it's probably worth documenting in
policy to allow tools to start to consume it if they like.

Thanks,
Jonathan

[1] https://lists.debian.org/debian-project/2010/07/msg00088.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737559: copyright-format: author != copyright, add an author field?

[Jonathan Nieder]

Daniel Pocock wrote:

> Just to clarify, I do not believe that maintaining this field should be
> obligatory
>
> It should be an optional field
>
> Defining it formally in the standard and having some examples will help
> emphasize the difference between what people should put in the Copyright
> field and what should not be there.
>
> If a maintainer feels that some author is particularly noteworthy or
> deserving, then they can put that author's name in the field even if the
> author has no entitlement to appear in the copyright field.

Yes, I understood that.  Which is why I wrote

> On 03/02/14 20:17, Jonathan Nieder wrote:

>> So, I think this is a reasonable idea, and if more than two or so
>> packages start using the field then it's probably worth documenting in
>> policy to allow tools to start to consume it if they like.

Do you think this should be documented before people try it out and
figure out what kind of values make sense for the field?

I would be less excited about that, but I'm not opposed to it.  My
thoughts would then be

 - If possible, please find someone else to weigh in on how this is
   useful to them (e.g., do they have an example copyright file which
   it makes cleaner?).

 - I suspect 'Authors' is not a good name for this field.  The word
   is too tightly tied to copyright, 'rights of the author', legal
   authorship, and so on.  Something like 'Contributors' should be
   fine, though.

 - Have you been using this field in your packages?  If not, is policy
   getting in the way of that?  (That would be a more serious bug and
   worth addressing first as a stopgap.)

Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737559: copyright-format: author != copyright, add an author field?

[Jonathan Nieder]

Daniel Pocock wrote:

> I've only come across one package which included public-domain material
> so far.  In this case, I put a note about the author in the comments.

Yep - that works, too.

[...]
> One risk of not having this extra field is that we could accumulate
> excessive things in the Copyright field.  E.g. some packagers may be
> including the names of contributors as if they are copyright holders
> because they are afraid their package will be queried (and subsequently
> delayed) by the FTP masters if they left something out by mistake.

Hm.  copyright-format already says

one or more free-form copyright statements.
[...]
The Copyright field collects all relevant copyright notices
for the files of this paragraph.

It doesn't say anything about listing authors.  It actually looks
pretty clear.

Maybe some ftp-master related documentation needs an update (e.g.,
perhaps the chain of links

https://ftp-master.debian.org/
-> REJECT-FAQ
   -> "this mail" <87u09lawkj@vorlon.ganneff.de>

has been misleading people).  In that case, I suspect a fix to
bug#678607 (clarifying that there is no need for debian/copyright to
list who wrote each line of code) would help.  I don't think adding
extra fields would save people from this source of worry.

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#694883: copyright-format: author != copyright, add an author field?

[Jonathan Nieder]

Just forwarding to bug#694883 ("please clarify the recommended form for
public domain files") for easy reference.

Thanks,
Jonathan
--- Begin Message ---


On 03/02/14 20:55, Jonathan Nieder wrote:
> Daniel Pocock wrote:
> 
>> I've only come across one package which included public-domain material
>> so far.  In this case, I put a note about the author in the comments.
> 
> Yep - that works, too.
> 
> [...]
>> One risk of not having this extra field is that we could accumulate
>> excessive things in the Copyright field.  E.g. some packagers may be
>> including the names of contributors as if they are copyright holders
>> because they are afraid their package will be queried (and subsequently
>> delayed) by the FTP masters if they left something out by mistake.
> 
> Hm.  copyright-format already says
> 
>   one or more free-form copyright statements.
> [...]
>   The Copyright field collects all relevant copyright notices
>   for the files of this paragraph.
> 
> It doesn't say anything about listing authors.  It actually looks
> pretty clear.

I agree it is reasonably clear

While it is not Debian's fault and there is nothing we can do about it,
there are upstreams who mix and match authors and copyright holders in
their notices and there are others who consistently include the correct
copyright notice in every file.

Sometimes they distribute an AUTHORS file and in some cases, the people
named in that file are entitled to be named in the Copyright field.  In
other cases, the people in the AUTHORS file or whatever have waived or
assigned their rights.  In the best cases these things are explained.

The paragraph you quote above could well go on to say "Not every author
or contributor is a copyright holder.  Only those listed in a Copyright
line in the source should be included in the Copyright field.  Names
mentioned in an authors or contributors file or committers on the
repository may not be copyright holders if there is an explicit
copyright statement present.  In the absence of an explicit copyright
statement, those alternative mechanisms may be useful for ascertaining
copyright."

> Maybe some ftp-master related documentation needs an update (e.g.,
> perhaps the chain of links
> 
>   https://ftp-master.debian.org/
>   -> REJECT-FAQ
>  -> "this mail" <87u09lawkj@vorlon.ganneff.de>
> 
> has been misleading people).  In that case, I suspect a fix to
> bug#678607 (clarifying that there is no need for debian/copyright to
> list who wrote each line of code) would help.  I don't think adding
> extra fields would save people from this source of worry.

Adding the fields alone doesn't resolve the problem

It is a communication issue and little things like this can help - I
make no claim that this is some silver bullet and that if this field is
added every copyright listing will become perfect

There are cases where I would have used it and I believe that
recognising people's work (even if they have assigned their rights) is
an important way of showing our thanks and acknowledgment to those who
develop free software, and having a dedicated field makes them stand out
just that little bit more.

--- End Message ---

Bug#737667: git: switching branches in superproject can leave local submodule commits unreachable

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20140127-1
Severity: wishlist
Tags: upstream

Suppose I do:

git checkout -b topic
(
cd my/favorite/submodule
... hack hack hack ...
git commit
)
# in superproject
git commit -a

git checkout master
git submodule update --init

... wait for reflog entry to expire and gc --auto to trigger ...

git checkout topic
git submodule update

Expected result:

I'm back on topic and get back to work.

Actual result:

 fatal: reference is not a tree: ac0dfa5c9cb03b273798585ec8d08069f41fbac0
 Unable to checkout 'ac0dfa5c9cb03b273798585ec8d08069f41fbac0' in submodule 
path 'my/favorite/submodule'

Fixing this might involve submodule repositories containing some
pointer to their parent projects and 'git fsck' being slowed down.
Or something more hackish involving temporary refs that 'checkout
--recurse-submodules' knows to set up and later clear could work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737680: git: please ship git-subtree

[Jonathan Nieder]

reassign 737680 src:git 1:1.8.5.3-1
merge 704652 737680
quit

Hi,

Yann Dirson wrote:

> git-subtree is included in contrib/subtree/, it would be good to have
> it in one of the debs.

Agreed.  I'll play with the patch from http://bugs.debian.org/704652
tonight.  (It's missing rules to install the documentation and run
tests, so if someone else wants to get to that before me, even
better.)

Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737797: 'git log -S' misses change from evil merge

[Jonathan Nieder]

Package: git
Version: 1:2.0~next.20140127-1
Severity: wishlist
Tags: upstream
Control: forwarded -1 
http://thread.gmane.org/gmane.comp.version-control.git/241532

Suppose I create a history like this:

git init
echo hi >greeting
git add greeting
git commit -m base
echo more >>greeting
git add greeting
git commit -m A
git reset --keep HEAD^
echo something else >>greeting
git add greeting
git commit -m B
git merge HEAD@{2}
echo something else entirely >greeting
git add greeting
git commit -m 'evil merge'

That is:

base --- A --- evil merge
\ /
 B ---

where base, A, and B contain 'hi\n' but the evil merge removes it.

If I run

git log --oneline $'-Shi\n' greeting

to see what happened to 'hi\n', it correctly finds base but doesn't
notice the evil merge.  More generally, log -S without -c, --cc, or -m
never blames merges.

Normally -S works by comparing the count of occurences of a string to
the corresponding count from a parent.  Which parent should it use for
merges?

Possible start to an answer:

 * perform a naive merge in memory[1]

 * if the naive merge and actual merge have different numbers of
   occurences of the test string, blame the merge (it's an evil
   merge and the merge resolution is to blame)

 * if the naive merge and actual merge commit have the same number
   of occurences of the test string and that number is greater than
   the sum of the numbers of occurences in parents, blame the merge
   (the combination of the parents is to blame)

 * otherwise, ...

An appropriate rule for "..." is not obvious, unfortunately.

[1] this is Thomas Rast's "remerge diff"
http://thread.gmane.org/gmane.comp.version-control.git/241565


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#587916: asciidoc: option to split CSS and Javascript to separate file

[Jonathan Nieder]

tags 587916 =
notfound 587916 asciidoc/8.5.2-1
quit

Hi,

Joseph Herlant wrote:

> Bug #587916 was provided the solution (official documentation link
> because requested functionality already present in the software) few
> month ago.
> I suppose that the submitter had either the time to get the requested
> information or no more interest in it, so I close the bug.

For future reference, Debian's BTS doesn't automatically Cc submitters
when you write to a bug.  That lets maintainers have an in-depth
conversation about how to fix a bug without spamming submitters, but on
the other hand it can lead to confusion as in this case.  [1] has more
details.

It looks like :linkcss: already existed in the version where I filed the
bug, so marking so.  Thanks for your help.

Regards,
Jonathan

[1] https://www.debian.org/Bugs/Developer#followup


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#729941: apt-cacher-ng: fails on current experimental/non-free

[Jonathan Nieder]

clone 729941 -1
reassign -1 apt-cacher-ng 0.7.19-1
retitle 729941 liblzma5: returns LZMA_OK with avail_in == 0 before done
found 729941 xz-utils/5.1.1alpha+20120614-2
tags 729941 + moreinfo
quit

Hi Eduard,

Eduard Bloch wrote:

> Apparently, on the last cycle of lzma_code(&strm, LZMA_RUN) it does not
> return LZMA_STREAM_END but LZMA_OK although the strm.avail_in value
> is zero which means that there is no more data to be expected.

I'm puzzled: where in the documentation does it say that when
strm.avail_in is zero, that means there is no more output to be
expected?

Just like zlib, if lzma_code() returns LZMA_OK and strm.avail_in is 0,
decompression is not necessarily finished yet.  liblzma has internal
buffers, so output is potentially incomplete unless you keep running
lzma_code() until it returns LZMA_STREAM_END or LZMA_BUF_ERROR.

[...]
> The problematic file is also attached. I will a workaround for now to
> apt-cacher-ng.

Is the workaround as described above?  That's the intended API, so I
don't consider it a workaround.

Any idea how this could be documented better to help people running
into this in the future?

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#729941: apt-cacher-ng: fails on current experimental/non-free

[Jonathan Nieder]

tags 729941 + upstream - moreinfo
# documentation
severity 729941 minor
quit

Eduard Bloch wrote:

>As far as I remember, zlib always
> returned ..._END when the result stream was completely written into the
> output buffer. And I have seen liblzma behaving the same way but it's
> not the case for the mentioned file(s) according to gdb. Here, the
> returned data (n time return buffer size plus one incomplete buffer)
> summs up to the total size of the stream but in the last cycle lzma_code
> returns LZMA_OK and not LZMA_STREAM_END. Maybe it will become
> LZMA_STREAM_END the next time when lzma_code is called but why should we
> do the extra round?

Ah, so the confusing behavior is that an LZMA_OK result neither
guarantees that there's more output coming nor that there's no more
output coming?  Ok.

[...]
> * Jonathan Nieder [Mon, Dec 09 2013, 02:37:05PM]:

>> Any idea how this could be documented better to help people running
>> into this in the future?
>
> Maybe it should state that one has to wait for LZMA_STREAM_END to be
> returned (or any !=LZMA_OK for errors) and not to add other funny
> checks for input/output buffer state.

Makes sense.  Will think more and hopefully send a patch soon.

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#731968: "git notes log" to view the history of notes for a particular commit

[Jonathan Nieder]

Package: git
Version: 1:1.8.5.1-1
Severity: wishlist
Tags: upstream

"git notes add" records the history of note additions in
refs/notes/commits, but there's no convenient way to look back at
notes changes for a particular commit (as opposed to "git log
refs/notes/commits", which looks at all of them).

(In the same spirit, there's no way to override the "Notes added by
'git notes add'" message that git notes add uses.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#726669: git-core: bash_completion doesnt check for sourced file

[Jonathan Nieder]

severity 726669 important
quit

Hi Craig,

Craig Small wrote:

> For some reason on my new installation I had git installed but it got
> removed (but, importantly NOT purged).
>
> Now when I login to it I get this:
> -bash: /usr/lib/git-core/git-sh-prompt: No such file or directory
> -bash: /usr/lib/git-core/git-sh-prompt: No such file or directory
>
> The fix is to just check that file is there before its sourced in
> /etc/bash_completion.d/git-prompt

Yep.  Thanks for catching this.

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#664987: git rebase -i ignores core.abbrev=16

[Jonathan Nieder]

severity 664987 important
tags 664987 + upstream patch fixed-upstream
quit

Hi Trent,

Trent W. Buck wrote:

> While interactively rebasing, I have twice run into this (same repo,
> different rebase steps, different ambiguous hashes):
>
> [...]
> $ git commit -aC1dafcb6
> [detached HEAD 7caed94] .crawlrc: leverage settings/ from upstream.
>  Author: Trent W. Buck 
>  1 files changed, 26 insertions(+), 65 deletions(-)
> $ git show
> $ git rebase --continue
> [detached HEAD ebd32a8] .crawlrc: switch pickup logic from a whitelist to 
> a blacklist.
>  Author: Trent W. Buck 
>  1 files changed, 127 insertions(+), 34 deletions(-)
> error: short SHA1 dccb2c5 is ambiguous.
> fatal: Needed a single revision
> Invalid commit name: dccb2c5

Thanks for a pleasant report.

Fixed by 75c69766 (rebase -i: fix short SHA-1 collision, 2013-08-23).
The patch is in branch "master" and presumably will be part of git
1.8.5.

[...]
> Freenode's #git suggested I increase core.abbrev.  I did so in
> .gitconfig, and OTHER commands see that it is now 16, but rebase -i
> ignores me:

Fixed by 56895038 (rebase -i: respect core.abbrev, 2013-09-28), also
in "master".

Ciao,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727066: git add -p ignores diff.mnemonicprefix configuration

[Jonathan Nieder]

Package: git
Version: 1:1.8.4.1-1
Tags: upstream

I have the following in my ~/.gitconfig:

[diff]
mnemonicPrefix = true

That is supposed to make the a/ and b/ prefix on filenames be changed
to something that clarifies the context --- e.g., i/ and w/ when
comparing the index and worktree.

Alas, when I use "git add -p", "git reset -p", and similar commands, I
get a/ and b/ again.  This makes it harder to remember than it should
be what the hunks shown represent.

Reported by Maarten de Vries on #git.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728353: git does not install zsh completion script

[Jonathan Nieder]

Package: git
Version: 1:1.8.4.1-1
Control: submitter -1 Dave Borowitz 

Please install the completion script from
contrib/completions/git-completion.zsh somewhere so users can symlink
it into their fpath.

Putting it directly in /usr/share/zsh/site-functions would cause the
completion to be loaded automatically, which interferes with users that
were relying on zsh's own, different git completion.  So
/usr/share/git-core/contrib/completion is likely to work better.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

[Jonathan Nieder]

Hi,

Steve Langasek wrote:

> I believe we are at the point that we should be recommending a preference
> for the fdo MIME interfaces

Yep, and menus, too.

Do we have clear advice about

 (1) how to write a menu entry for my console app (or niche graphical
 app) without cluttering the menus used by the standard desktops

 (2) when, roughly, it is appropriate to use that facility to hide my
 menu entries

?

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#730527: git: auto colors broken with lv

[Jonathan Nieder]

found 730527 git/1:1.8.5.2-1
tags 730527 + upstream
quit

Hi,

Olaf Meeuwissen wrote:

> Since upstream has made color.ui=auto the default, my git experience has
> suffered.  I use lv as my preferred pager and somehow that doesn't jive
> with what the various git commands feed it.  Pagination itself works but
> instead of colors I get to see control codes like below (partial output
> of git diff):
>
>   ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m
>   ^[[1mindex aa4f0b2..17e113e 100644^[[m
>   ^[[1m--- a/.mailfilter^[[m
>   ^[[1m+++ b/.mailfilter^[[m
>   ^[[36m@@ -1,11 +1,58 @@^[[m
>
> Using GIT_PAGER=more or GIT_PAGER=less works fine and show paginated,
> colored output.

Sorry for the slow reply.  Yep, I can reproduce this.  Setting
GIT_PAGER='lv -c' (-c means "allow color") works as a workaround.

Questions:

1. Git exports LESS=FRSX (-FX = do not use alternate screen; quit if less than
   one screenful of output, -R = allow ANSI escape sequences through, -S = chop
   long lines) if the LESS environment variable is unset to allow less to work
   correctly by default without extra command-line arguments.
  
   Does lv have an environment variable to allow the caller to pass in default
   settings?

2. Does lv have options analagous to less -FX to avoid pagination when there is
   less than a screenful of output?  Without that setting, commands like "git
   log --oneline -3" and "git grep -e stringappearingnowhere" use the full
   screen instead of printing their output above the command prompt, making it
   harder to copy-and-paste tidbits from output into the next command.

3. lv allows some formatting through by default (^H-based bold and underlines)
   for the sake of the "man" command.  Would it make sense for 'lv' to enable -c
   by default?

4. Other ideas?

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#707851: Soften the the wording recommending menu files: let's do it in Jessie.

[Jonathan Nieder]

Charles Plessy wrote:

> On the other hand, it is the spirit of Debian to accept low-maintenance 
> patches
> (in that case, menu entries) when it can help other projects even if one does
> not care for it.  In that sense, if the Debian Menu has an active user base, 
> it
> would be counter-productive to kill it with a top-down decision.

I don't think no longer documenting the old Debian menu system (or
moving the documentation to an appendix) would kill it or be a
top-down decision.  After all, if policy does not say that I *should*
add a menu entry, that does not stop me from adding one if I want to.

Currently Debian has two menu systems.  The old Debian menu system is
nice because there is clear documentation about how to add your
program to it and as a result for a while it was a pretty complete
menu.

Alas, now that completeness is eroding and I don't see much reason to
recommend in policy to continue to add entries, unless we have clear
advice about when packagers should include an entry in it and when
they should add to the fdo menu instead.

As far as I can tell, the de facto policy is just to add to the fdo
menu when appropriate.  The documented policy is failing to describe
that actual practice.  Is there some subtlety I'm missing?

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#707851: Soften the the wording recommending menu files: let's do it in Jessie.

[Jonathan Nieder]

Hi,

Charles Plessy wrote:

> please, I would like to decouple two issues.
>
>  - Issue 1: the Debian menu is superseded in major destkotop environments, and
>the Policy should recognise that the Debian menu is not the lead mechanism
>for managing menus in Debian anymore.  Unfortutately we have two parallel
>systems at the moment. 
>
>  - Issue 2: deciding whether the Debian menu is actually obsolete and should 
> be
>removed from the Policy.

I don't understand the distinction.  If policy doesn't say I should
have debian-menu entries, then what is all this text in policy about
debian-menu for?

I'm not saying that the old Debian menu system should be removed from
the archive.  I'm saying that either

 (A) the recommendation to use it should be removed from where it
 currently is in policy, perhaps to be moved to an appendix, or

 (B) there should be clear advice about when a package should provide
 a Debian menu entry and when it should provide an fdo menu entry

Otherwise I, a packager, have no idea what policy is telling me about
how to correctly package software.

[...]
> If we tie Issue 1 to Issue 2, my gut feeling (not my wish) is that there is
> currently no way to conclude without going in front of the TC or having a GR,

I don't suspect that at all.  I like to think the policy process can
work, especially when I don't even see any major disagreement.  If
there is some disagreement, hearing where I have gone wrong above
would help me a lot, since then it becomes possible to see where the
policy can be clarified.

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#734869: dash should drop its privileges in setuid context and implement privileged mode support (-p)

[Jonathan Nieder]

tags 734869 + upstream
forwarded 734869 http://thread.gmane.org/gmane.comp.shells.dash/841
quit

Hi Raphaël,

Raphaël Hertzog wrote:

> I have been reading
> http://blog.cmpxchg8b.com/2013/08/security-debianisms.html and discovered
> that dash doesn't drop its privileges when run in a setuid context.

Agreed, this is an important and good change (both upstream and for
Debian).  Thanks for reporting.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735240: git-tag doc: "git tag" is not just for signed tags

[Jonathan Nieder]

Package: git-man
Version: 1:1.8.5.2-2
Severity: minor
Justification: documentation
Tags: upstream

git-man(1) sayeth:

git-tag - Create, list, delete or verify a tag object signed with GPG

But the 'git tag' command is not only (or even mainly) for working with
signed tags.  Probably the DESCRIPTION section needs a rewrite and then
a nicer oneliner would emerge.

Noticed while looking into a report by Leo R. Lundgren on #git:

also, what the heck to people write in annotated tags for version
numbers anyway?
but those should already be in some changelog or release file,
right?
trying it requires me to set up a remote repo somewhere
not the five second quick test
...
i am not entirely sure that lightweight tags are pushed as well
as annotated ones, i wouldnt want to take the chance of making a
tag that might not get pushed
...
a part of me would like the push man page to say that both types
of tags are pushed, but im not sure thats very practical. cnat
have every part of things elaborate on all the others too


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org