Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

[Jonathan Nieder]

Hi Salvatore,

Salvatore Bonaccorso wrote:
> On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:

>> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
>> uploaded it to DELAYED/2. Please feel free to tell me if I
>> should delay it longer.
>
> I noted that the last uploads done by Sebastian were NMUs, so hope it
> is uncontroversial that I rescheduled the fix to delayed/0 and direct
> upload tonight. There is not particular reason for the urgency, it's
> more that I would like to base the bullseye-security just on top of
> the 5.2.5-2.1 versioned 5.2.5-2.1~deb11u1 and have additionally the
> fix first exposed in unstable enough as well for regression testing.

No problem at all.  Thanks for your work!  (And I'd be happy to have
a new maintainer or co-maintainer if you're interested. :))

Thanks,
Jonathan

Bug#985416: Bug#986565: unusable with current git

[Jonathan Nieder]

Hi,

>> On Wed, 21 Apr 2021 10:12:03 + Damyan Ivanov  wrote:

>>> Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.

Why sigh?

Directories such as /usr/lib/git-core and /usr/libexec/git-core are
internal to git.  Other packages should not install to either
directory.  This is not a new thing: the standard way to contribute
new git subcommands has been to install them to $PATH from the start.

Version 2.31.0-1 of Debian's Git package changed an internal directory
from /usr/lib/git-core to /usr/libexec/git-core.  That caused problems
for people, so 2.31.1-1 reverted the change.  See
https://bugs.debian.org/985416 for more details, including

  these should install to /usr/bin/ instead.  The exact
location where git stores its commands is an implementation detail
that packages are not meant to rely on.

If I had known about these callers, then I would have filed some
preparatory bugs instead of making that change in 2.31.0-1.  The
change was in experimental for a long time before then, so one way to
prevent future such issues is to test against git from experimental.

If git-flow wants to depend on Git internals, contacting the git
package maintainers is appreciated.  That is especially true when the
internal details you're depending on are changing.

Thanks and hope that helps,
Jonathan

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Jonathan Nieder]

Hi!

Guillem Jover wrote:

> The latest version in sid, breaks user code sourcing the git-sh-prompt
> shell library as it moved from /usr/lib/ to /usr/libexec, even though
> I see the comment there says to copy it, but that means no automatic
> upgrades. :/
>
> Could you perhaps add a backwards compatibility symlink for the time
> being? Or when using bash, perhaps even a warning based on the
> “caller” builtin if using the old pathname?

Yeah, I don't advocate copying.  Probably we should patch those
instructions at installation time to recommend sourcing in place
instead.

The git-sh-setup(1) manpage recommends

. "$(git --exec-path)/git-sh-setup"

but there is no corresponding git-sh-prompt(1) manpage --- yikes.
Ideas:

 a. We could add a NEWS.Debian entry to help people see that the path
changed and recommend using the $(git --exec-path) based incantation

 b. We could move $(git --exec-path) back to /usr/lib/git-core.  After
all, while the FHS _allows_ libexec nowadays, it does not require
it.

 c. As you suggest, we could have a compatibility forwarding script
that warns to help people update their prompt configuration.

I think I prefer (a) over (c), and that (b) might be best of all.
What do you think?

Thanks,
Jonathan

Bug#972871: git-el: .el files not installed / byte-compiled

[Jonathan Nieder]

tags 972871 + patch pending
quit

Jonathan Nieder wrote:

> Thanks for reporting.
>
> Strangely, debian-emacs-policy doesn't appear to be in the
> emacsen-common package any more.  Fortunately, it's in
> https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.
>
> It looks like we can remove the '"$FLAVOR" != emacs' check because
> Debian no longer provides multiple co-installable versions of emacs
> (good!).  I think if we remove the check this will simply do the
> right thing.
>
> Emacsen team: would a Breaks against emacsen-common (<< 3.0.0~)
> be sufficient for ensuring we have a new enough version of emacs
> for this to be safe?

More concretely: how about this patch?

-- 8< --
Subject: debian/git-el: do not exclude "emacs" from the flavors to
 install for

As Zack Weinberg noticed, the git-el package has not installed any
elisp for emacs for the last two years, producing a warning at
startup instead:

  git removed but not purged, skipping setup

That is because "emacs" switched from being a virtual package to
being the only flavor of standard emacs installed.  Update the
installation scripts to reflect this.

Even after this patch, the elisp installed does not do anything other
than point the user to magit and emacs's built in vc-git support.  A
followup change may remove the package.

Fixes: https://bugs.debian.org/972871
Signed-off-by: Jonathan Nieder 
---
 debian/changelog  | 5 -
 debian/control| 1 +
 debian/git-el.emacsen-install | 6 --
 debian/git-el.emacsen-remove  | 1 -
 4 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 96d06fcaff4..657218ad785 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,8 +5,11 @@ git (1:2.29.1-0.1) unstable; urgency=low
   * debian/control: Build-Depends: debhelper-compat (= 10)
 * debian/rules: run "dh --without autoreconf" to speed up build,
   since we don't use the autotools-generated configure script.
+  * git-el: install elisp for the "emacs" flavor, too (thx Zack Weinberg;
+closes: #972871).  Breaks: emacsen-common (<< 3.0.0~) to avoid
+triggering on older systems where "emacs" was a virtual package.
 
- -- Jonathan Nieder   Mon, 26 Oct 2020 15:44:15 -0700
+ -- Jonathan Nieder   Mon, 26 Oct 2020 16:22:41 -0700
 
 git (1:2.28.0-1) unstable; urgency=low
 
diff --git a/debian/control b/debian/control
index e3edda4cf85..25c5b83f45d 100644
--- a/debian/control
+++ b/debian/control
@@ -278,6 +278,7 @@ Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, git (>= 1:1.7.4.1-2~), emacs | emacsen
 Recommends: elpa-magit
+Breaks: emacsen-common (<< 3.0.0~)
 Replaces: git (<< 1:1.7.4.1-2~)
 Breaks: git (<< 1:1.7.4.1-2~)
 Description: fast, scalable, distributed revision control system (emacs 
support)
diff --git a/debian/git-el.emacsen-install b/debian/git-el.emacsen-install
index da35fdb0c59..4b02513a5ae 100755
--- a/debian/git-el.emacsen-install
+++ b/debian/git-el.emacsen-install
@@ -12,12 +12,6 @@ el_files="git.el git-blame.el"
 el_dir=/usr/share/git-core/emacs
 elc_dir=/usr/share/$FLAVOR/site-lisp/git
 
-# The emacs startup file looks for these files in
-# /usr/share/${debian-emacs-flavor}/site-lisp/git.
-# Installing to the generic /usr/share/emacs/site-list/git would be
-# pointless.
-[ "$FLAVOR" != emacs ] || exit 0
-
 printf 'install/git: Handling install of emacsen flavor %s\n' "$FLAVOR"
 [ -d "$elc_dir" ] || mkdir "$elc_dir"
 (
diff --git a/debian/git-el.emacsen-remove b/debian/git-el.emacsen-remove
index 5d345e1ff84..81408b0b32e 100755
--- a/debian/git-el.emacsen-remove
+++ b/debian/git-el.emacsen-remove
@@ -8,7 +8,6 @@ el_files="git.el git-blame.el"
 elc_files="git.elc git-blame.elc"
 elc_dir=/usr/share/$FLAVOR/site-lisp/git
 
-[ "$FLAVOR" != emacs ] || exit 0
 printf 'remove/git: Handling removal of emacsen flavor %s\n' "$FLAVOR"
 [ -d "$elc_dir" ] || exit 0
 (cd "$elc_dir"; rm -f $elc_files $el_files)
-- 
2.29.0.rc2.309.g374f81d7ae

Bug#972871: git-el: .el files not installed / byte-compiled

[Jonathan Nieder]

Hi,

Zack Weinberg wrote:

> While updating my emacs configuration for 27.1 (now in unstable)
> I noticed that /etc/emacs/site-start.d/50git-core.el prints
>
> git removed but not purged, skipping setup
>
> and does not autoload either git.el or git-blame.el.  This appears to
> be because /usr/lib/emacsen-common/packages/install/git does nothing
> when $FLAVOR is “emacs”:
>
> | # The emacs startup file looks for these files in
> | # /usr/share/${debian-emacs-flavor}/site-lisp/git.
> | # Installing to the generic /usr/share/emacs/site-list/git would be
> | # pointless.
> | [ "$FLAVOR" != emacs ] || exit 0
>
> This has been incorrect for quite some time - I’m not sure how long
> ago it was that (symbol-name debian-emacs-flavor) was changed to
> evaluate to “emacs” for the ordinary packages of GNU Emacs, but
> probably more than one release by now.
>
> I think a sufficient fix is to remove the above quoted lines from
> /usr/lib/emacsen-common/packages/install/git.

Thanks for reporting.

Strangely, debian-emacs-policy doesn't appear to be in the
emacsen-common package any more.  Fortunately, it's in
https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.

It looks like we can remove the '"$FLAVOR" != emacs' check because
Debian no longer provides multiple co-installable versions of emacs
(good!).  I think if we remove the check this will simply do the
right thing.

Emacsen team: would a Breaks against emacsen-common (<< 3.0.0~)
be sufficient for ensuring we have a new enough version of emacs
for this to be safe?

Thanks,
Jonathan

Bug#965350: kgb-bot: autopkgtest makes assumption about exact merge commit message

[Jonathan Nieder]

Source: kgb-bot
Version: 1.56-1
Tags: upstream
Severity: serious
Justification: tests fail with up-to-date Git
Affects: src:git

>From 
>https://ci.debian.net/data/autopkgtest/testing/amd64/k/kgb-bot/6323993/log.gz:

| not ok 71
|
| #   Failed test at t/52-client-git.t line 393.
| #  got: 'Merge branch 'allnew' into master'
| # expected: 'Merge branch 'allnew''

Can the test change to avoid hard-coding the merge commit message?  By
relaxing that test, it would be more likely to continue working as Git
evolves over time.

Relevant Git change: v2.28.0-rc0~15^2~9 (489947cee50, "fmt-merge-msg:
stop treating `master` specially", 2020-06-23).

Thanks,
Jonathan

Bug#961702: git breaks fdroidserver autopkgtest: Failed to parse line: ' git config pull.rebase false

[Jonathan Nieder]

reassign 961702 python3-git 3.1.1-1
affects 961702 git
quit

Hi,

Hans-Christoph Steiner wrote:

> I can't find any possible reference in fdroidserver, or in python3-git
> for that matter.  My guess is that the issue is caused by python3-git
> failing to parse something that was added in the most recent git.  So
> I'm reassigning this to python3-git since the stacktrace shows the issue
> happening pretty deep inside python3-git, and the fdroidserver code does
> not call `git config` in anyway that I can figure out.

Yes, it looks like python3-git is parsing output meant for human
consumption.  It should not do that.

Thanks,
Jonathan

Bug#955152: git-rebase ignores or squashes GIT_REFLOG_ACTION

[Jonathan Nieder]

Hi,

Ian Jackson wrote[1]:

> [ some git-debrebase invocation etc. ]
> + git reflog
> + egrep 'debrebase new-upstream.*checkout'
> + rc=1
>
> I have looked at the log and repro'd the bug.
>
> git-debrebase (which lives in src:dgit but does not depend on dgit)
> must invoke git-rebase.  It sets GIT_REFLOG_ACTION so that the reflog
> is comprehensible to the user.  In previous versions of git this works
> as expected.  In 2.26.0-1 it does not.
>
> This is easy to reproduce by running
>   GIT_REFLOG_ACTION='zeeks!' git rebase --onto  
> with arguments implying a nontrivial rebase.
>
> The test suite in src:dgit, which is the checks that its
> GIT_REFLOG_ACTION manipulation is effective, and it is this test which
> has now failed and which is blocking the migration of git.
>
> git-rebrebase in sid produces quite different looking reflog entries.
> I guess the code for generating the messages has changed and that
> git-rebase is now *setting* GIT_REFLOG_ACTION (or the equivalent
> internal variable) rather than adding to it.
>
> ISTM that to preserve the documented semantics, it is basically always
> wrong of anything to unconditionally set GIT_REFLOG_ACTION.  In
> src:dgit I have a small bit of code to arrange to always *add* to
> GIT_REFLOG_ACTION, if it is already set.  There might be several
> precise ways to add to GIT_REFLOG_ACTION but the failing test case
> here should be happy with any reasonable choice.

Thanks for reporting.

The main relevant change is that "git rebase" switched its default
backend from "apply" to "merge".  This makes it more robust by using
three-way merges in a similar way to "git cherry-pick".  The "merge"
backend was historically already used for interactive rebases.

I believe some reflog behavior changes were noticed in

 commit 980b482d28482c307648c3abbcb16ae60843c7ae
 Author: Elijah Newren 
 Date:   Sat Feb 15 21:36:37 2020 +

 rebase tests: mark tests specific to the am-backend with --am

but we didn't investigate at the time (shame on me).  Anyway, we have
a chance to improve things now.

My first thought is to look at when rebase prepares its msg, in
builtin/rebase.c#set_reflog_action:

if (!is_merge(options))
return;

env = getenv(GIT_REFLOG_ACTION_ENVIRONMENT);
if (env && strcmp("rebase", env))
return; /* only override it if it is "rebase" */

strbuf_addf(, "rebase (%s)", options->action);
setenv(GIT_REFLOG_ACTION_ENVIRONMENT, buf.buf, 1);
strbuf_release();

In the --am case, is_merge is false and this code isn't run.  But in
our case, GIT_REFLOG_ACTION is not rebase, so this code still
shouldn't be run.

My next thought is to look at when this function was changed:

 commit c2417d3af7574adc1fb14f7df31b862aa9551e2e
 Author: Elijah Newren 
 Date:   Sat Feb 15 21:36:36 2020 +

 rebase: drop '-i' from the reflog for interactive-based rebases

If I am reading

 commit 13a5a9f0fdcf36270dcc2dcb7752c281bbea06f1
 Author: Johannes Schindelin 
 Date:   Thu Nov 29 11:09:21 2018 -0800

 rebase: fix GIT_REFLOG_ACTION regression

correctly, then dgit requires that to be '-i' for interactive rebases.
Are we sure that that's not the issue here?

Thanks,
Jonathan

[1] https://bugs.debian.org/955152

Bug#949454: libctf-nobfd0: missing Breaks+Replaces against libbinutils versions with the same files

[Jonathan Nieder]

Package: libctf-nobfd0
Version: 2.33.50.20200115-2
Severity: serious
Rationale: breaks upgrades

libctf-nobfd0 takes over the file libctf-nobfd.so.0.0.0 from libbinutils
but is missing a Breaks + Replaces declaring so:

 Unpacking libctf-nobfd0:amd64 (2.33.50.20200115-2) ...
 dpkg: error processing archive 
/tmp/apt-dpkg-install-YXR1z2/3-libctf-nobfd0_2.33.50.20200115-2_amd64.deb 
(--unpack):
  trying to overwrite '/usr/lib/x86_64-linux-gnu/libctf-nobfd.so.0.0.0', which 
is also in package libbinutils:amd64 2.33.50.20191121-2

Could it have

 Breaks: libbinutils (<< 2.33.50.20191128-1~)
 Replaces: libbinutils (<< 2.33.50.20191128-1~)

to address that?

Thanks,
Jonathan

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Jonathan Nieder]

Hi,

Sebastian Andrzej Siewior wrote:

> I don't know what changed but I think it is debhelper. We have now:
>
> |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act
> |   debian/rules install
> |   dh_installdeb
> |   dh_gencontrol
> |   dh_md5sums
> |   dh_builddeb
>
> and that "debian/rules build" gets inlined we skip to install. This was
> once
>
> |(buster)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act
> |   debian/rules install
> |   debian/rules binary-arch
> |   debian/rules binary-indep
>
> The install rule used to expand to other targets, to build the package
> but not anymore.

Good sleuthing.  If someone has time to bisect to find the problematic
debhelper change, that would be helpful.

I can easily believe there is an intentional change involved, but I
don't think this is intentional when trying to build an existing
package without bumping the compat version.

Thus:

[...]
> xz has this line in its rule file:
>
> | #!/usr/bin/make -f
> |
> | build clean install binary-arch binary-indep binary:
> | +dh $@ --parallel $(opt_no_act)
>
> and if I replace it with
> | #!/usr/bin/make -f
> |
> | %:
> | dh $@ --parallel $(opt_no_act)
>
> then it builds again.
>
> Should the rules be adjusted for xz?

Let's track down the cause first, before pursuing workarounds.

Thanks much,
Jonathan

Bug#942353: python-evtx: ImportError: No module named hexdump

[Jonathan Nieder]

Package: python-evtx
Version: 0.6.1-1
Severity: serious
Justification: missing dependency

$ evtx_dump.py
Traceback (most recent call last):
  File "/usr/bin/evtx_dump.py", line 20, in 
import Evtx.Evtx as evtx
  File "/usr/local/buildtools/current/sitecustomize/sitecustomize.py", line 
152, in SetupPathsAndImport
return real_import(name, globals, locals, fromlist, level)
  File "/usr/lib/python2.7/dist-packages/Evtx/Evtx.py", line 28, in 
import Evtx.Views as e_views
  File "/usr/lib/python2.7/dist-packages/Evtx/Views.py", line 25, in 
import Evtx.Nodes as e_nodes
  File "/usr/lib/python2.7/dist-packages/Evtx/Nodes.py", line 25, in 
import hexdump
ImportError: No module named hexdump

Looks similar to https://bugs.debian.org/851056. The fix there doesn't
seem to help here: there is a /usr/lib/python2.7/dist-packages/Evtx/hexdump.py
file, but "import hexdump" doesn't import it (should it be "import
Evtx.hexdump" instead?).

Thanks for packaging the evtx package!

Bug#915426: git breaks git-remote-hg autopkgtest

[Jonathan Nieder]

Hi again,

On 25 January 2019, Jonathan McCrohan wrote:

> I am happy to work on fixing up the FTBFS, but
> because I am not a DD, I would need a sponsor to upload for me.

I'm happy to sponsor an upload, especially if this is a first step
toward team maintenance with Jonas (who I can speak from experience in
saying is a very pleasant person to collaborate with) and that upload
removes me from Uploaders.  It's the least I can do. :)

If you run into any trouble, just ask.

Thanks,
Jonathan

Bug#915426: git breaks git-remote-hg autopkgtest

[Jonathan Nieder]

Hi Jonas,

Jonas Smedegaard wrote:

> I can do yet another NMU to fix this, but am hesitating as I worry if
> that will masquerade a lack of responsive maintenance.
>
> Please tell if it is sensible that I take over maintenance of this
> package, or join as co-maintainer, or however is appreciated.

I'd be happy if you take over as maintainer.  Sorry for the slow
reply.

When the package was first uploaded, I agreed to be a co-maintainer as
a way to notice issues with Git's remote helper infrastructure.  It
was a bad idea --- I should have just subscribed through the PTS
without being a co-maintainer.

Please feel free to take the package as new sole maintainer, with my
blessing (or even better, to set up a team list to maintain it with
you).

Sincerely,
Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

Dmitry Bogatov wrote:
>> Jonathan Nieder wrote:

>>> +  * git-daemon-run: pre-create supervise directory so that postinst
>>> +can start the service (thx Celejar and Dmitry Bogatov; closes:
>>> +#919296).
[...]
> Wierd. It should work. /etc/sv/git-daemon/supervise is not dangling, is
> it? Tell me which git commit I should build and test, in effort to help
> debugging?

It's not dangling.

I tested with the debian-sid branch, with the patch in the message I
sent applied on top.  That said:

[...]
> It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4,
> which was expected by git-daemon-run.
>
> Today runit packaging underwent quite a rework, and packages, providing
> runscripts are encouraged to use dh_runit(1). It manages creation of
> apporiate directories and symbolic links. If you have any issues, do not
> hezitate to ask -- runit is my top priority.

Thanks, these are two good starting points.  I'll take a look at the
2.1.2-4 changes and into whether it's simple to use dh_runit.  Hopefully
the latter will take care of everything. :)

Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

tags 919296 - patch pending
quit

Jonathan Nieder wrote:

> For "buster", I prefer a minimal fix within the framework of the
> current packages, along the lines you suggested upthread:
>
> diff --git i/debian/changelog w/debian/changelog
> index ef513b2e1d..fb996c91f4 100644
> --- i/debian/changelog
> +++ w/debian/changelog
> @@ -3,6 +3,9 @@ git (1:2.20.1-1.1) unstable; urgency=low
>* package git-gui: actually Suggests: meld for mergetool support;
>  describe what meld is used for in package description (thx Jens
>  Reyer; closes: #707790).
> +  * git-daemon-run: pre-create supervise directory so that postinst
> +can start the service (thx Celejar and Dmitry Bogatov; closes:
> +#919296).
>  
>   -- Jonathan Nieder   Mon, 21 Jan 2019 19:36:25 -0800
>  
> diff --git i/debian/git-daemon-run.dirs w/debian/git-daemon-run.dirs
> index 7847e85525..0e62ab6ac0 100644
> --- i/debian/git-daemon-run.dirs
> +++ w/debian/git-daemon-run.dirs
> @@ -1 +1,2 @@
>  etc/sv/git-daemon/log
> +var/lib/supervise/git-daemon

Unfortunately, this doesn't work.  /var/lib/supervise/git-daemon ought
to contain a definition of a supervise service, whereas this produces
an empty directory so it still fails.

Do you have more details?  Why was this approach expected to work, and
where can I read more about what changed in runit and how to
appropriately adjust this package to handle the changes?

Thanks,
Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

found 919296 git/1:2.20.1-1
tags 919296 + patch pending
quit

Hi Dmitry,

Dmitry Bogatov wrote:
> [2019-01-16 14:49] Dmitry Bogatov 

>> So, should I propose you patch (in 7 days), that merges
>> bin:git-daemon-run into bin:git-daemon, would you be able to review
>> and apply/upload it before hard freeze?
>
> Probably, even better would be to merge `git-daemon-run' and
> `git-daemon-sysvinit'. What do you think?

For "buster", I prefer a minimal fix within the framework of the
current packages, along the lines you suggested upthread:

diff --git i/debian/changelog w/debian/changelog
index ef513b2e1d..fb996c91f4 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -3,6 +3,9 @@ git (1:2.20.1-1.1) unstable; urgency=low
   * package git-gui: actually Suggests: meld for mergetool support;
 describe what meld is used for in package description (thx Jens
 Reyer; closes: #707790).
+  * git-daemon-run: pre-create supervise directory so that postinst
+can start the service (thx Celejar and Dmitry Bogatov; closes:
+#919296).
 
  -- Jonathan Nieder   Mon, 21 Jan 2019 19:36:25 -0800
 
diff --git i/debian/git-daemon-run.dirs w/debian/git-daemon-run.dirs
index 7847e85525..0e62ab6ac0 100644
--- i/debian/git-daemon-run.dirs
+++ w/debian/git-daemon-run.dirs
@@ -1 +1,2 @@
 etc/sv/git-daemon/log
+var/lib/supervise/git-daemon

By the way, was there a change in runit precipitating this regression?
I'm wondering so that we can set up the right dependencies (e.g. a
versioned Breaks from runit) to ensure upgrades proceed smoothly.

This way, the same behavior as the previous release will persist for
users expecting it (in particular, allowing users to easily decide
which configuration will control their running daemon --- see [1] for
more context).  That said, I'm happy to pursue a merge of the packages
into a git-daemon package in experimental in preparation for buster+1,
especially if there's a standard for runit service packaging that we
can follow there.

Thanks again for your help.

[1] http://bugs.debian.org/422139#121

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

# missing Depends
severity 919296 serious
quit

Celejar wrote:
>> Celejar wrote:

>>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
>>> README.debian) fails with:
>>>
>>> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> ii  runit  2.1.2-22 amd64system-wide service supervision
> ii  runit-helper   2.7.3all  dh-sysuser implementation detail
> un  runit-init   (no description available)
> un  runit-systemd(no description available)
> un  runit-sysv   (no description available)
>
> I don't install recommends by default, and I do run into trouble
> sometimes because of that ;). Should I try installing one of them to see
> if that solves the problem?

Yes, please.  Please install runit-systemd and then run
"dpkg-reconfigure git-daemon-run".

If I'm lucky then that will get it working.  I'll try to reproduce it
here and set the right dependencies.

It appears that runit-sysv depends on sysvinit-core, which conflicts
with systemd-sysv, so adding a Depends by git-daemon-run on
'runit-init | runit-systemd | runit-sysv' should do the trick.  I'll
experiment.

Thanks,
Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

Hi again,

Celejar wrote:
> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> Versions of packages git-daemon-run depends on:
> ii  adduser  3.118
> ii  git  1:2.20.1-1
> ii  runit2.1.2-22

What is the output of "dpkg -l runit*"?  In particular, do you have
runit-sysv or runit-systemd installed?

Thanks,
Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

Hi,

Celejar wrote:

> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
>
> I see that there's an old, archived bug about this:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570094
>
> But I'm getting the same thing on my uptodate Sid system (and even on
> another Sid system with the version of the package from experimental
> installed).
>
> I know nothing about runit, so perhaps I'm doing something obvious
> wrong, but I'm just trying to follow the directions from the README, and
> getting this.

Thanks for reporting.  I'm cc-ing Debian's runit maintainers, who may
be able to help us track this down.

I haven't tried reproducing this yet, but I will try soon (some time
this week).

Sincerely,
Jonathan

Bug#915426: git breaks git-remote-hg autopkgtest

[Jonathan Nieder]

Paul Gevers wrote:

> https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-remote-hg/1428119/log.gz
>
> not ok 32 - pull tags

The package ought to run "make TEST_OPTS=-v" to produce a more useful
log[*].

Bisects to the following Git change:

e198b3a740409fabe5ba774c5f1255b55fdd21c1 is the first bad commit
commit e198b3a740409fabe5ba774c5f1255b55fdd21c1
Author: Junio C Hamano 
Date:   Tue Sep 25 13:25:04 2018 -0700

fetch: replace string-list used as a look-up table with a hashmap

In find_non_local_tags() helper function (used to implement the
"follow tags"), we use string_list_has_string() on two string lists
as a way to see if a refname has already been processed, etc.

All this code predates more modern in-core lookup API like hashmap;
replace them with two hashmaps and one string list---the hashmaps
are used for look-ups and the string list is to keep the order of
items in the returned result stable (which is the only single thing
hashmap does worse than lookups on string-list).

Similarly, get_ref_map() uses another string-list as a look-up table
for existing refs.  Replace it with a hashmap.

Signed-off-by: Junio C Hamano 

[*]
expecting success:
test_when_finished "rm -rf hgrepo gitrepo" &&

(
hg init hgrepo &&
cd hgrepo &&
echo one > content &&
hg add content &&
hg commit -m one
) &&

git clone "hg::hgrepo" gitrepo &&

(cd hgrepo && hg tag v1.0) &&
(cd gitrepo && git pull) &&

echo "v1.0" > expected &&
git --git-dir=gitrepo/.git tag > actual &&
test_cmp expected actual

Cloning into 'gitrepo'...
WARNING: capability_push is disabled, only do so when really sure
WARNING: various enhanced features might fail in subtle ways
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets 50e85c807eb0
progress revision walk 'bookmarks/master' (0/0)
progress revision 0 'master' (0/1)
WARNING: capability_push is disabled, only do so when really sure
WARNING: various enhanced features might fail in subtle ways
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets ff570a4c8fa2
progress revision 1 'default' (0/1)
>From hg::/src/git-remote-hg/test/trash directory.main/tmp/hgrepo
   5ac88dd..82ef3dd  master   -> origin/master
   5ac88dd..82ef3dd  branches/default -> origin/branches/default
Updating 5ac88dd..82ef3dd
Fast-forward
 .hgtags | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .hgtags
--- expected2018-12-05 06:36:57.995012275 +
+++ actual  2018-12-05 06:36:57.995012275 +
@@ -1 +0,0 @@
-v1.0
not ok 32 - pull tags

Bug#914695: dgit autopkgtest breaks with git 2.20

[Jonathan Nieder]

Hi Ian,

Ian Jackson wrote:

> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/1382882/log.gz
[...]
> Looking at the test log did not immediately suggest a cause to me.
> But it is probably much easier for me to (at least initially)
> investigate this, since I will hopefully understand what the test case
> was trying to do.

Very much appreciated.

[...]
> To the git maintainers: please let me know if this update was urgent
> so that I can prioritise appropriately.

The main source of urgency is that this could help shed light on
whether the rewrite of "git rebase" in C is not ready for prime time,
so we can make an appropriate choice for the imminent Git 2.20 release
about whether to use it by default.

In other words, we're trying to decide whether to apply
https://public-inbox.org/git/xmqq36roz7ve.fsf...@gitster-ct.c.googlers.com/.

The test log says

 + git reflog
 + egrep 'debrebase new-upstream.*checkout'
 + test 1 = 0
 + t-report-failure
 + set +x
 TEST FAILED
 cwd: /tmp/autopkgtest-lxc.q9szjzqq/downtmp/autopkgtest_tmp/example
 funcs: t-report-failure main
 lines: 1 0
 files: tests/lib 
/tmp/autopkgtest-lxc.q9szjzqq/downtmp/build.sQK/src/tests/tests/gdr-newupstream
 gzip: warning: GZIP environment variable is deprecated; use an alias or script
  81.2%
 autopkgtest [04:30:20]: test gdr-newupstream: ---]
 autopkgtest [04:30:20]: test gdr-newupstream:  - - - - - - - - - - results - - 
- - - - - - - -
 gdr-newupstream  FAIL non-zero exit status 16

The relevant part of the test script says

   t-gdr-good laundered
   git reflog | egrep 'debrebase new-upstream.*checkout'

which I admit is a bit inscrutable to me.  So a reduced testcase would
be very welcome.

Thanks, sincerely,
Jonathan

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Jonathan Nieder]

Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 5:57 PM Jonathan Nieder  wrote:

>>> There is no reason this functionality cannot be offered in Debian. We
>>> got complaints when we supported other browsers but not Google Chrome.
>>
>> Since Google Chrome is not part of Debian, shouldn't this
>> functionality be offered in contrib, not Debian?
>
> No. Despite its name, chrome-gnome-shell also supports Chromium and
> Firefox, both of which are in main.

Then I'm confused.  Why are browsers in main unable to support a
location other than /etc/opt for this?

Could there be a package in contrib that installs a symlink to
/etc/opt, with the rest of the functionality in main?

Thanks,
Jonathan

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Jonathan Nieder]

Hi,

Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila  wrote:

>> What I said is that no sane package in Debian/main should need to put
>> files directly in /etc/opt. That's an oddity, a very unorthodox thing,
>> it would be like a Debian package in main putting stuff directly in /opt.
>
> chrome-gnome-shell (in this case) is an addon for the Google Chrome
> web browser. Since Chrome installs to /opt/ (which is encouraged by
> FHS), /etc/opt/ is the only standards-compliant location for
> chrome-gnome-shell to ship the configuration files it needs to provide
> its core functionality.
>
> There is no reason this functionality cannot be offered in Debian. We
> got complaints when we supported other browsers but not Google Chrome.

Since Google Chrome is not part of Debian, shouldn't this
functionality be offered in contrib, not Debian?

[...]
>  But if
> that can't be done, I think we would be happy enough to apply a patch
> to implement the trigger workaround.

For what it's worth (especially since this is about integrating with a
non-Debian package), makes sense to me.

Thanks,
Jonathan

Bug#901900: dgit in stretch-backports

[Jonathan Nieder]

Hi Sean,

Sean Whitton wrote:
> On Fri, Jun 22 2018, Jonathan Nieder wrote:

>> Is there somewhere I can read more about that policy?  Not that I'm
>> complaining :)
>
> https://backports.debian.org/Contribute/
>
> "... you have to ... update your backport when a new version enters
> testing ..."

Thanks again for this pointer.  dgit 5.2 has now hit testing.  If
there is anything I can do to help with getting it into
stretch-backports, please don't hesitate to let me know.

Sincerely,
Jonathan

Bug#901897: closed by Jonathan Nieder (Bug#901897: fixed in git 1:2.18.0~rc2-2)

[Jonathan Nieder]

Hi,

Ian Jackson wrote:
> Paul Gevers writes ("Re: Bug#901897 closed by Jonathan Nieder 
>  (Bug#901897: fixed in git 1:2.18.0~rc2-2)"):

>> And I just helped the test for git a bit as due to bug 896023 in
>> autopkgtest it didn't use the right autopkgtest from dgit.

Thanks!  I had been wondering what I should do to poke it.

[...]
> It's not clear to me exactly what needed fixing.  Can you send me urls
> to the bad run which prompted your intervention, and the good run
> which resulted ?
>
> Looking here
>   https://qa.debian.org/excuses.php?package=git
> I see a migration test for git 1:2.18.0-1 which used dgit 5.1,
> despite the fact that dgit 5.1 is not in testing yet.

Looks like this was answered and the conversation continued at
https://bugs.debian.org/896023#26.

Jonathan

Bug#901900: dgit in stretch-backports

[Jonathan Nieder]

Sean Whitton wrote:

> (B) We don't do anything special, wait for something in the 5.x series
> to hit testing in the normal way, and then update the dgit and git
> backports.
[...]
> In any case, since everyone is happy with (B) for at least a week, we
> can do (B) for at least a week.

Sorry for the lack of clarity.  I think (B) is the right choice, and
without any special delays.  My previous reply was just about how we
would get testing in a good state without blocking Git updates if the
dgit 5.x issues Ian mentioned were release-critical, but I don't think
that's the situation we're in.

> On Fri, Jun 22 2018, Jonathan Nieder wrote:

>> Is there somewhere I can read more about that policy?  Not that I'm
>> complaining :)
>
> https://backports.debian.org/Contribute/
>
> "... you have to ... update your backport when a new version enters
> testing ..."

Ah, lovely. Thank you.

Jonathan

Bug#901900: dgit in stretch-backports

[Jonathan Nieder]

Hi Sean,

Sean Whitton wrote:
> On Fri, Jun 22 2018, Jonathan Nieder wrote:

>> Do you plan to update dgit in backports once it hits testing?
>
> Yes.

Excellent, thank you.

[...]
>> Is there anything I can do to help?  For example, should I prepare an
>> upload for 4.4 while we wait for 5.1 to migrate to testing?
>
> So far as I can tell from this bug's metadata 4.4 will not help you?
> (I'll push 4.4 to stretch-backports soon in order to comply with
> backports policy, anyway.)

Is there somewhere I can read more about that policy?  Not that I'm
complaining :).

[...]
> On Fri, Jun 22 2018, Ian Jackson wrote:

>> However, we have just released a major new feature and there are
>> inevitble bugs in it.  My current wip branch[1] has fixes for that but
>> also fixes for other bugs, some of which may themselves cause further
>> bugs.
[...]
> The only way to delay
> updating the backport is to keep making releases to unstable ;)

Or in other words, users of the backport are not promised any better
stabilization than testing.  If you're concerned about the stability
of the package, I recommend sorting it out in testing too, as
mentioned in my previous reply.

Thanks much,
Jonathan

Bug#901900: dgit in stretch-backports

[Jonathan Nieder]

Ian Jackson wrote:
> Jonathan Nieder writes ("Bug#901900: dgit in stretch-backports"):

>> Once git 2.18.0 is in testing, I want to update the git package in
>> stable-backports.  This would require updating dgit as well to a
>> version that supports the working-tree-encoding attribute
>> (https://bugs.debian.org/901900).
[...]
> Sean has mostly been managing the backports of dgit.  I think
> backports of both git and dgit would be good things.

Thanks.  I figured Sean was the one to ask.

> However, we have just released a major new feature and there are
> inevitble bugs in it.  My current wip branch[1] has fixes for that but
> also fixes for other bugs, some of which may themselves cause further
> bugs.
>
> What kind of timescale are you thinking about here ?  If you are
> willing to wait a couple of weeks, I think sid/testing's dgit will
> have settled down.

My usual practice has been to backport git versions as soon as they
hit testing.  I'd be happy to settle for waiting a week after that.
Two weeks feels a bit too long.

If the version in sid right now isn't suitable yet for a wider
audience, then there are a few (not mutually exclusive) options:

 1. file an RC bug to prevent it from migrating to testing.

 2. revert the feature that is not ready for wide release from
unstable and upload it to experimental to get the exposure it
currently needs.

 3. upload a more targeted fix for bug#901900 to
testing-proposed-updates[*].

To me, 1+2 seems a little simpler than 3, but that's a hunch based on
limited context.

On the other hand, if the bugs are not serious enough to warrant that,
then I'm happy to delay a little (e.g. 1 week) but would prefer not to
wait longer than that after testing migration.  Rationale: we can
trust users of the backport to have a similar risk tolerance to users
of testing.

Separately from that, my offer of preparing an upload of 4.4 for
backports still stands.

Thoughts?

Jonathan

[*] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u

Bug#901900: dgit in stretch-backports

[Jonathan Nieder]

Hi Sean et al,

Once git 2.18.0 is in testing, I want to update the git package in
stable-backports.  This would require updating dgit as well to a
version supports the working-tree-encoding attribute
(https://bugs.debian.org/901900).

Do you plan to update dgit in backports once it hits testing?  Is
there anything I can do to help?  For example, should I prepare an
upload for 4.4 while we wait for 5.1 to migrate to testing?

Thanks,
Jonathan

Bug#901900: git introduces new hazardous working-tree-encoding attribute

[Jonathan Nieder]

Ian Jackson wrote:

> 5.1 is ready and has passed all its tests.  It works fine with the git
> in sid.  I am not able to upload it right now, but this will happen
> later today.

Thanks.

 $ git ls-remote git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

Is there an alternate URL that I can use to get these changes?

Jonathan

Bug#901897: git introduces new hazardous working-tree-encoding attribute

[Jonathan Nieder]

Hi Ian,

My mail host appears to be blacklisted on your end:

> There was a problem delivering your message to
> ijack...@chiark.greenend.org.uk. See the technical details below, or
> try resending in a few minutes.
>
> The response was:
> 550 Blacklisted site `[74.125.83.53]' [Irritated]

What is the best way to reply to your bug reports?

Thanks,
Jonathan

Bug#901897: git introduces new hazardous working-tree-encoding attribute

[Jonathan Nieder]

severity 851679 wishlist
tags 851679 + upstream
clone 901897 -1
retitle -1 dgit fails autopkgtest: true/false are no valid 
working-tree-encodings
reassign -1 dgit 5.0
retitle 901897 git needs Breaks against dgit versions without 
working-tree-encoding support
block 901897 by -1
quit

Hi Ian,

Ian Jackson wrote:

> Subject: git introduces new hazardous working-tree-encoding attribute

This title doesn't describe a bug.  On first reading, I thought you
were saying that some working-tree-encoding related feature was
behaving incorrectly, but it doesn't appear to be so.  (I was trying
to understand so that I could forward this report upstream.)

By the way, is there a way to trigger these autopkgtests automatically
with git from experimental as well?  That way, I'd get earlier notice
about these issues.

> So, on to the actual problem:
>
> Looking at the manpage for gitattributes(7) it mentions a new
> attribute
>working-tree-encoding
> which affects the way files are checked in and out.
>
> dgit and similar workflows need to disable this attribute, because
> they require that git trees and source packages correspond, which
> cannot be achieved if working trees made from source packages are not
> identical to git trees once committed.

I think you're saying that attributes like "text" are forbidden in
dgit packages because dgit wants to compare the content of the working
directory to the tracked content without using Git for that.  Am I
understanding correctly?

Git has a notion of "smudge" and "clean" attributes.  The idea is that
to get the content for the worktree, you use "smudge".  To get the
checked-in content, you use "clean".  Would dgit be able to
interoperate with that?

In the dgit(7) manpage, you write:

These transformations are context-sensitive and not, in
general, reversible

Strictly speaking, since users can configure filters that run
arbitrary commands (see "filter" in gitattributes(5)), that's true,
but the transformations are meant to produce a canonical "smudged"
form in the worktree and a canonical "clean" form in the repository.

Sorry I missed bug#851679 before.  We can discuss this more there.
Perhaps some command like "git archive" would work better than "git
checkout" for this use.

> In #851679 I requested a way to disable all checkout-affecting
> gitattributes.  This has not yet been done AFAICT.
>
> In lieu of that, dgit's test suite has a specific test to spot when
> new attributes are introduced.  It tries enabling them and seeing if
> things go wrong.  And indeed, that test has now tripped.  (It failed,
> in fact, simply because some of the values it attempted to set the
> unknown working-tree-encoding attribute to were invalid, but IMO the
> test has done its job.)
>
> I think at the very least I will need to update dgit to disable
> working-tree-encoding as well.  I think the new git should probably
> have a Breaks against the older dgit.

Happy to add a Breaks.  Do you know what version of dgit will have the
fix?

Thanks,
Jonathan

Bug#901185: Checkbashisms

[Jonathan Nieder]

Hi,

積丹尼 wrote:

Be sure the package passes Checkbashisms!
>

Which package? Is there a particular bashism you noticed?

Please keep in mind that these reports appear as emails in a crowded inbox,
where a little context in the subject line can go a long way.

Thanks,
Jonathan

>

Bug#900393: runit 2.1.2-14 breaks git-daemon-run

[Jonathan Nieder]

Package: runit
Version: 2.1.2-14
Severity: serious
Justification: breaks upgrades

The changelog to runit 2.1.2-14 explains:

   * Do not install `update-service' script.

but it doesn't give any more context than that.  This breaks the
git-daemon-run package, as noticed e.g. by piuparts:

  https://piuparts.debian.org/sid/fail/git-daemon-run_1:2.17.1-1.log

Moreover, debian/runit.NEWS doesn't say anything about the change.
https://codesearch.debian.net/search?q=update-service=1 finds
some other callers.  Where can I read more about how to handle this,
and can you roll back the change for now to unblock updates?

Thanks,
Jonathan

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

[Jonathan Nieder]

reassign 895446 libfontconfig1 2.13.0-2
severity 895470 serious
retitle 895470 fontconfig-2.13.0 globally sets the locale from the environment
forcemerge 895470 895446
affects 895470 + gitk
tags 895470 + patch fixed-upstream
quit

Jonathan Nieder wrote:
> Michael Biebl wrote:

>> gitk no longer successfully starts here. When I run it from a terminal,
>> I get
>>
>> $ gitk
>> Error in startup script: bad screen distance "4.5"
>> while executing
>> "$canv conf -scrollregion [list 0 0 $canvxmax $ymax]"
>> (procedure "setcanvscroll" line 6)
>> invoked from within
>> "setcanvscroll"
>> (procedure "initlayout" line 17)
>> invoked from within
>> "initlayout"
>> (procedure "getcommits" line 4)
>> invoked from within
>> "getcommits {}"
>> (file "/usr/bin/gitk" line 12613)
>> $ echo $?
>> 1
>
> I'm not yet able to reproduce this.  The package works fine for me.

Ah, I figured it out.  It's from libfontconfig's new setlocale() call.
I wasn't able to reproduce it because my locale uses a different decimal
separator.

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

[Jonathan Nieder]

tags 895446 + moreinfo
quit

Hi Michael,

Michael Biebl wrote:

> gitk no longer successfully starts here. When I run it from a terminal,
> I get
>
> $ gitk
> Error in startup script: bad screen distance "4.5"
> while executing
> "$canv conf -scrollregion [list 0 0 $canvxmax $ymax]"
> (procedure "setcanvscroll" line 6)
> invoked from within
> "setcanvscroll"
> (procedure "initlayout" line 17)
> invoked from within
> "initlayout"
> (procedure "getcommits" line 4)
> invoked from within
> "getcommits {}"
> (file "/usr/bin/gitk" line 12613)
> $ echo $?
> 1

I'm not yet able to reproduce this.  The package works fine for me.

Torbjörn Andersson suggests that it may be related to the fontconfig
version; can you confirm?  E.g. did the problem start for you at the
same time as a fontconfig update?

Can you try running gitk from testing or stable to see if they behave
differently?

Part of the reason I ask these questions is that gitk hasn't had any
recent changes.

Thanks,
Jonathan

Bug#892488: pcre2: FTBFS on mips* - test failures

[Jonathan Nieder]

Hi,

Matthew Vernon wrote:
> On 09/03/18 15:20, James Cowgill wrote:

>> Source: pcre2
>> Version: 10.31-1
>> Severity: serious
[...]
>> pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
>> like the JIT is bust.
>>
>> I forwarded the log upstream to the above address. I'll try to take a
>> look at what's causing this.
>
> Thanks for the bug report, and the forwarding upstream. Do you want me to
> remove "mips mipsel mips64el" from the list of arches with JIT enabled and
> do a new upload? Or leave it broken now and see what upstream say?

This is blocking git updates from migrating to testing
(https://qa.debian.org/excuses.php?package=git), so my preference
would be removing "mips mipsel mips64el" from the list of JIT arches
for now as a stopgap.

Thanks,
Jonathan

Bug#884038: [git] 2.15.x fails to fetch remote repository

[Jonathan Nieder]

# regression but not reproducible
severity 884038 important
tags 884038 + upstream unreproducible
quit

Hi,

mirq-debo...@rere.qmqm.pl wrote:

> git 2.15.x from testing can't properly fetch from remote repository:
>
> $ git fetch --all
> Fetching origin
> remote: Counting objects: 752, done.
> remote: Total 752 (delta 578), reused 578 (delta 578), pack-reused 174
> Receiving objects: 100% (752/752), 244.37 KiB | 1.89 MiB/s, done.
> Resolving deltas: 100% (619/619), completed with 214 local objects.
> fatal: bad object HEAD
> error: https://github.com/torvalds/linux.git did not send all necessary 
> objects
>
> error: Could not fetch origin 
>
> Downgrading to 2.14.2-1~bpo9+1 from stretch-backports fixes the issue.
> Both current 2.15.1-1 and previous 2.15.0-1 in testing are affected.

Very strange.  I can't reproduce this --- any hints about what I am
doing differently from you?

Can you give commands starting with the initial "git clone" I can use to
reproduce this?

If there's no way to reproduce it from scratch, can you tar up your
.git directory and send it to me somehow to allow me to reproduce it?

Thanks,
Jonathan

Bug#871570: git FTBFS on i386: t7006-pager.sh test failure

[Jonathan Nieder]

found 871570 git/1:2.13.2-3
tags 871570 + upstream
quit

Hi,

Adrian Bunk wrote:

> https://buildd.debian.org/status/fetch.php?pkg=git=i386=1%3A2.14.0-1=1502132890=0
>
> ...
> expecting success: 
>   (
>   sane_unset LESS LV &&
>   PAGER="env >pager-env.out; wc" &&
>   export PAGER &&
>   PATH="$(git --exec-path):$PATH" &&
>   export PATH &&
>   test_terminal sh -c ". git-sh-setup && git_pager"
>   ) &&
>   grep ^LESS= pager-env.out &&
>   grep ^LV= pager-env.out
> 
> wc: 'standard input': Input/output error
>   0   0   0
> not ok 6 - LESS and LV envvars set by git-sh-setup

Thanks for reporting.  I think I know what is happening here.  It is
not 100% reproducible.  It isn't a regression.  I'll send a patch
upstream.

Thanks,
Jonathan

Bug#868738: git FTBFS on several architectures: not ok 134 - --dump-aliases must be used alone

[Jonathan Nieder]

Hi,

Adrian Bunk wrote:

> https://buildd.debian.org/status/package.php?p=git=sid
>
> expecting success: 
>   test_must_fail git send-email --dump-aliases --to=jan...@example.com -1 
> refs/heads/accounting
>
> --dump-aliases incompatible with other options
> test_must_fail: command not found: git send-email --dump-aliases 
> --to=jan...@example.com -1 refs/heads/accounting
> not ok 134 - --dump-aliases must be used alone

Thanks for reporting.  The relevant code is

die __("--dump-aliases incompatible with other options\n")
if !$help and $dump_aliases and @ARGV;

test_must_fail prints the "command not found" message if and only if
the status code was 127.  I would have expected it to be 1 or 128
here.

"man perlfunc" says

If the exception is outside of all enclosing "eval"s, then
the uncaught exception prints LIST to "STDERR" and exits with a
non-zero value.  If you need to exit the process with a specific
exit code, see "exit".

That doesn't tell me what the status code will be.  Peeking at the source,
I find

int exitstatus;
if (errno & 255)
STATUS_UNIX_SET(errno);
else {
exitstatus = STATUS_UNIX >> 8;
if (exitstatus & 255)
STATUS_UNIX_SET(exitstatus);
else
STATUS_UNIX_SET(255);
}

which seems risky (there are many functions that could set errno, so
this is prone to spooky action at a distance if any caller forgets to
set it explicitly).  Looking for errno values that could be 127 in
glibc and linux using "git grep --cached -e '#.*define.*E.*127'", I
find

 linux:arch/alpha/include/uapi/asm/errno.h:#define ERESTART127
 linux:arch/mips/include/uapi/asm/errno.h:#define ENETDOWN 127
 linux:arch/sparc/include/uapi/asm/errno.h:#define ECANCELED   127
 linux:include/uapi/asm-generic/errno.h:#defineEKEYEXPIRED 127

so that doesn't look likely to be the cause.

Next step is to ssh into porterboxes and get the output of

perl -e 'die "testing"'; echo $?"

Bug#860774: openldap on armhf and armel needs bootstrapping

[Jonathan Nieder]

Ryan Tandy wrote:
> Debian Bug Tracking System wrote:

>> Bug #860774 [libldap-2.4-2] relax dependency on libldap-common
>> Added indication that 860774 affects src:git, src:heimdal, and src:subversion
>
> It will be a few more hours before I can get to an upload, so if
> this is blocking others' work, feel free to NMU.

I can wait. :)

Thanks for your work on openldap!

Jonathan

Bug#866059: Please remove the git-arch package

[Jonathan Nieder]

severity 866059 important
tags 866059 + pending
quit

Hi Adrian,

Adrian Bunk wrote:

> Severity: serious

Why?

> Already for a couple of years, the only realistic usecase
> for the tla package in Debian was to allow git-arch to
> migrate repositories to git.
>
> The final release of GNU Arch was in 2006,
> and buster is scheduled to be released in 2019.
>
> It is very unlikely that there will be unconverted GNU Arch
> repositories left that people will want to convert to git
> in 2019 or later.
>
> git-all depends on git-arch and "arch" sounds like "architecture",
> therefore what popcon says about git-arch and tla is irrelevant.
>
> Please remove the git-arch package, so that tla can get removed.

Happy to.  Thanks for reporting.

Regards,
Jonathan

Bug#818318: git: CVE-2016-2324 and CVE-2016-2315 (currently unpublished) server and client RCE

[Jonathan Nieder]

On Thu, Mar 17, 2016 at 12:37:27AM +, Ben Hutchings wrote:
> On Wed, 2016-03-16 at 17:16 -0700, Jonathan Nieder wrote:
>> Ben Hutchings wrote:

>>> I intend to NMU git to fix these bugs in unstable, as they make most of
>>> my development activity unsafe.
>>>
>>> git maintainers, please let me know if you're already preparing an
>>> update.
>>
>> I'm already preparing an update.
>
> Thanks.  For what it's worth, I'm attaching my minimal fix for
> CVE-2016-2324.  All existing tests pass, but I don't have a reproducer
> for the security issue so I can't be certain it's fixed.

More patches are needed.  See 
https://git.kernel.org/cgit/git/git.git/log/?h=maint
(I mention this mostly for the sake of people backporting to stable,
testing, or oldstable.)

Bug#818318: git: CVE-2016-2324 and CVE-2016-2315 (currently unpublished) server and client RCE

[Jonathan Nieder]

Ben Hutchings wrote:

> I intend to NMU git to fix these bugs in unstable, as they make most of
> my development activity unsafe.
>
> git maintainers, please let me know if you're already preparing an
> update.

I'm already preparing an update.

Jonathan

Bug#801046: git: "Out of memory, malloc failed" cloning certain repos

[Jonathan Nieder]

tags 801046 + moreinfo
quit

Hi Lenz,

PICCORO McKAY Lenz wrote:

> Version: 1:1.7.10.4-1+wheezy1
> Severity: grave

I am able to use git.  Are you sure the package is actually unusable?
For example, do commands like "git init" work?

[...]
> Current version of git for wheeze and squeeze are unusable, does not
> work as normal user for make it work user must know the root
> password and swicht, sudo does not work!

Thanks for reporting.  I'm having some trouble understanding the exact
problem.

Does version 2.x have this problem as well?  There was a change
upstream mentioning http.pushbuffer but I am not sure if it is
related.

commit c80d96ca0c3cf948c5062bf6591a46c625620b6d (tags/v1.9-rc0~97^2)
Author: Brian M. Carlson 
Date:   Thu Oct 31 02:36:51 2013 -0400

remote-curl: fix large pushes with GSSAPI

Due to an interaction between the way libcurl handles GSSAPI
authentication over HTTP and the way git uses libcurl, large
pushes (those over http.postBuffer bytes) would fail due to
an authentication failure requiring a rewind of the curl
buffer.  Such a rewind was not possible because the data did
not fit into the entire buffer.

Enable the use of the Expect: 100-continue header for large
requests where the server offers GSSAPI authentication to
avoid this issue, since the request would otherwise fail.
This allows git to get the authentication data right before
sending the pack contents.  Existing cases where pushes
would succeed, including small requests using GSSAPI, still
disable the use of 100 Continue, as it causes problems for
some remote HTTP implementations (servers and proxies).

Signed-off-by: Brian M. Carlson 
Signed-off-by: Jeff King 

Thanks and hope that helps,
Jonathan

Bug#774607: git: diff for NMU version 1:2.1.4-2.1

[Jonathan Nieder]

Niels Thykier wrote:

 I've prepared an NMU for git (versioned as 1:2.1.4-2.1) and
 uploaded it to DELAYED/2.

Thanks.  Could you bump it to DELAYED/0?

Regards,
Jonathan


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

Bug#774607: gitweb breaks apache upgrade

[Jonathan Nieder]

(dpkg - bcc)
Niels Thykier wrote:

 Any updates on this bug?  The gitweb trigger cycle is currently the last
 trigger cycle left[1].

It should be interest-noawait.  I was preparing an upload to do that,
but other things preempted that :/.  I will try to make the upload
tonight and don't mind if someone else makes an NMU with that change.

Thanks,
Jonathan


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

Bug#774607: gitweb breaks apache upgrade

[Jonathan Nieder]

Guillem Jover wrote:

 In this case though, it seems switching to interest-noawait is the
 correct fix, because gitweb just wants to be notified when the
 apache2-maintscript-helper program appears to be able to configure
 itself, but apache does not care and does not need to await the
 trigger processing from gitweb for itself to be operational.

Is there a way to tell the packaging system that gitweb is not
operational until the trigger runs, without implying that apache2 is
not operational until the trigger runs?

Thanks,
Jonathan


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

Bug#774803: gitweb: dpkg trigger cycle via apache2

[Jonathan Nieder]

Hi Niels,

Niels Thykier wrote:

 Debian `dpkg' package management program version 1.17.23 (amd64).
[...]
  chain of packages whose triggers are or may be responsible:
   gitweb - gitweb
  packages' pending triggers which are or may be unresolvable:
   gitweb: /usr/share/apache2/apache2-maintscript-helper
[...]
 This simulates an upgrade scenario, where apache2 might be
 temporarily deconfigured while gitweb remains configured.  If this
 happens, dpkg is unable to recover as the cycle due to await trigger
 AND the dependency requires both packages to be configured.

Puzzling.  What prevents the following upgrade path?

 1. deconfigure gitweb
 2. configure apache2
 3. configure gitweb

I'm probably missing something obvious, I'm confused at where the
cycle is here.  It seems like gitweb depends on apache2 but not vice
versa.

Thanks,
Jonathan


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

Bug#774607: gitweb breaks apache upgrade

[Jonathan Nieder]

Hi dpkg maintainers,

Erwan David wrote[1]:

 Package: gitweb
 Version: 1:2.1.4-2
 Severity: normal

 When upgrading apache and gitweb I get :

 dpkg: cycle found while processing triggers:
  chain of packages whose triggers are or may be responsible:
   gitweb - gitweb
  packages' pending triggers which are or may be unresolvable:
   gitweb: /usr/share/apache2/apache2-maintscript-helper
 dpkg: error processing package gitweb (--configure):
  triggers looping, abandoned

gitweb does not contain a /usr/share/apache2/apache2-maintscript-helper
file.

What's going on?

Puzzled,
Jonathan

[1] http://bugs.debian.org/774607


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

Bug#774607: gitweb breaks apache upgrade

[Jonathan Nieder]

reassign 774607 dpkg 1.7.22
affects 774607 + gitweb src:git
forcemerge 771730 774607
quit

Jonathan Nieder wrote:
 Erwan David wrote[1]:

 dpkg: cycle found while processing triggers:
  chain of packages whose triggers are or may be responsible:
   gitweb - gitweb
  packages' pending triggers which are or may be unresolvable:
   gitweb: /usr/share/apache2/apache2-maintscript-helper
 dpkg: error processing package gitweb (--configure):
  triggers looping, abandoned

 gitweb does not contain a /usr/share/apache2/apache2-maintscript-helper
 file.

 What's going on?
[...]
 ii  dpkg 1.17.22

Ah, sounds like http://bugs.debian.org/771730.  Merging optimisticly.

Thanks,
Jonathan

 [1] http://bugs.debian.org/774607


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

Bug#770655: git FTBFS: failure in t9500-gitweb-standalone-no-errors.sh

[Jonathan Nieder]

Reiner Herrmann wrote:

 --- /dev/null
 +++ b/debian/patches/gitweb_cgi_param.patch

Patches go in debian/diff/.  I can take care of an upload to fix this
bug and #768795 this week.

Advice on #669292 would be welcome.  Currently the gitweb package is
essentially useless.  gitweb itself is part of the main git package
(for the sake of git instaweb) --- the gitweb package is supposed to
configure it and get it running.

Thanks,
Jonathan


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

Bug#765525: gitweb broken by libcgi-pm-perl 4.06-1

[Jonathan Nieder]

Jonathan Nieder wrote:

  * gitweb: use start_form instead of startform for compatibility
with CGI.pm 4.04 and newer (thx Roland Max; closes: #765525).

Gah.  I've fixed the spelling in this changelog entry in the
development repo, so it should be back to sanity in the next upload
(2.1.3-2).

Thanks again for the quick fix.


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

Bug#767960: gitweb: no longer works: Undefined subroutine CGI::startform

[Jonathan Nieder]

# regression
severity 767960 important
reassign 765525 gitweb 1:2.1.1-1
severity 765525 grave
tags 765525 + fixed-upstream
block 767960 by 765525
reassign 767960 libcgi-pm-perl 4.06-1
tags 767960 + patch
quit

Thorsten Glaser wrote:

 gitweb no longer works. When I call /usr/share/gitweb/index.cgi
 manually from the shell, I get:
[...]
 Undefined subroutine CGI::startform
  at /usr/share/gitweb/index.cgi line 5513.

Thanks for reporting.  gitweb uses start_form starting in version 2.1.3.
libcgi-pm-perl will need a Breaks for smooth upgrades.

diff --git i/debian/changelog w/debian/changelog
index e2cf1d9..1e527d2 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,10 @@
+libcgi-pm-perl (4.09-1.1) local; urgency=low
+
+  * Add Breaks against versions of git in which gitweb and 'git instaweb'
+use the startform function.
+
+ -- Jonathan Nieder jrnie...@gmail.com  Mon, 03 Nov 2014 15:07:40 -0800
+
 libcgi-pm-perl (4.09-1) unstable; urgency=medium
 
   * Import upstream version 4.09
diff --git i/debian/control w/debian/control
index 5242c9b..dcac525 100644
--- i/debian/control
+++ w/debian/control
@@ -24,7 +24,7 @@ Architecture: all
 Depends: ${misc:Depends},
  ${perl:Depends}
 Recommends: libcgi-fast-perl (= 1:2.01)
-Breaks: libcgi-fast-perl ( 1:2)
+Breaks: libcgi-fast-perl ( 1:2), git ( 1:2.1.3)
 Description: module for Common Gateway Interface applications
  CGI.pm is a Perl module that provides classes useful for creating Web forms
  and for parsing their contents. It defines CGI objects, entities that contain


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

Bug#758675: metis: GKlib/random.c is missing license grant

[Jonathan Nieder]

Source: metis
Version: 5.1.0.dfsg-3
Severity: serious
Justification: undistributable
Tags: upstream

Hi Anton et al,

The copyright file of metis says the following is the license for
GKlib/random.c:

Copyright 2004, Makoto Matsumoto and Takuji Nishimura

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

That's a warranty disclaimer --- it doesn't say anything about how
people can use, modify, or distribute this software.

For comparison, 
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c
has the same code (for the Mersenne-Twister part) and says

Copyright (C) 2004, Makoto Matsumoto and Takuji Nishimura,
All rights reserved.  

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

  1. Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the 
distribution.

  3. The names of its contributors may not be used to endorse or 
promote 
 products derived from this software without specific prior written 
 permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Could GKlib/random.c and debian/copyright use that license?  Or
alternatively, could metis use another copy of mersenne twister, e.g.
from libgmp if it has one?

Thanks,
Jonathan


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

Bug#538822: dash fails to upgrade if /bin/sh is locally diverted

[Jonathan Nieder]

reopen 538822
# difficult, invasive
severity 538822 wishlist
tags 538822 =
quit

Hi,

Niels Thykier wrote:

 I am taking the liberty of closing this bug, because:
  1) there is no sign of progress in this bug for the past 1-and-a-half
  2) there is no sign of desire/need for being able to locally divert sh
 - at least not to the point where they bothered commenting on this
   bug.

Thanks for looking into it.  Reopening, lowering severity.  (I'm aware
of at least one user that was relying on this and has been working
around the lack with every upgrade, and I believe fixing it would be
good for the maintainability of the package anyway.)

Regards,
Jonathan


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

Bug#750687: git status becomes fork-bomb under some circumstances

[Jonathan Nieder]

Hi,

Axel Beckert wrote:

 10/0/0 root@acromantula:pts/4 18:53:47 [~] # ps auxwwwf | fgrep git
 abe  11352 77.1  0.0   4552   596 pts/2R+   18:53   0:10  |   
 |   \_ strace -f -e fork git status
 abe  11353  6.3  0.1  24632  6848 pts/2S+   18:53   0:00  |   
 |   \_ git status
 abe  11354  7.3  0.1  24632  6856 pts/2S+   18:53   0:00  |   
 |   \_ git status --porcelain
 abe  11355  8.0  0.1  24632  6856 pts/2S+   18:53   0:00  |   
 |   \_ git status --porcelain
 abe  11358  9.8  0.1  24632  6852 pts/2S+   18:53   0:00  |   
 |   \_ git status --porcelain

Yeah, this is a submodule issue.  What is the output of

git ls-files -s | grep ^16 | cut -d$'\t' -f2 | xargs ls -ld

?

[...]
 So this issue has quite some potential to bring down a system within
 minutes and trigger an OOM condition.

That's a general feature of fork bombs.  I think we should try to
figure out why git is recursing into the same repository again and
again --- the fork bomb mitigation aspect is less interesting to me
(though certainly a worthwhile thing to work on for kernel hackers
or people coming up with default rlimits).

Thanks,
Jonathan


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

Bug#750687: git status becomes fork-bomb if a submodule's .git directory is not accessible

[Jonathan Nieder]

severity 750687 important
quit

Hi,

Axel Beckert wrote:
 Axel Beckert wrote:

 I couldn't willingly reproduce it yet outside the setup where I ran
 into that issue, 

 Here's how to reproduce:

Yay!  Thanks for this.

[...]
 Control: severity -1 grave
[...]
 Since I consider such a setup not too seldom (especially with
 etckeeper and some shell prompt using git status to show some
 information), I'm raising the severity to grave.

That's way overinflated (it would not be worth blocking a release of
Debian).  But thanks much for tracking it down.

Jonathan


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

Bug#748387: liblockfile: missing debian/copyright

[Jonathan Nieder]

Source: liblockfile
Version: 1.09-6
Severity: serious
Justification: policy 4.5

In liblockfile 1.09-6:

 $ ls debian/
 changelog
 control
 liblockfile-bin.overrides
 patches
 postinst
 postrm
 rules
 shlibs
 source
 $ tar -tf ../liblockfile_1.09-6.debian.tar.bz2
 debian/
 debian/control
 debian/source/
 debian/source/options
 debian/source/format
 debian/rules
 debian/patches/
 debian/patches/series
 debian/patches/fix-buffer-overflows.patch
 debian/patches/688074-Makefile.in-NVER.patch
 debian/patches/Makefile.in.patch
 debian/liblockfile-bin.overrides
 debian/shlibs
 debian/changelog
 debian/postrm
 debian/postinst

The copyright file appears to be missing.

Thanks,
Jonathan


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

Bug#748387: liblockfile: missing debian/copyright

[Jonathan Nieder]

severity 748387 important
quit

Cyril Brulebois wrote:
 Jonathan Nieder jrnie...@gmail.com (2014-05-16):

 Source: liblockfile
 Version: 1.09-6
 Severity: serious
 Justification: policy 4.5

 What you're talking about is a 'should' in Policy 12.5; doesn't look
 like a serious bug to me.

Good catch.

I noticed it while trying to read the copyright file through
packages.qa.debian.org.  Looks like the binary packages are okay, and
the information's there in the source package --- the path is just
wrong.

Thanks,
Jonathan


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

Bug#745646: chromium: certificate revocation is not checked

[Jonathan Nieder]

Hi,

Giuseppe Iuculano wrote:
 On 30/04/2014 19:49, Vincent Lefevre wrote:

 Bug 745646 is a different bug, specifically about the CRLSet system,
 which is very broken.

 What you write is not a bug, if you want to do revocation check you must
 enable it in settings.

However Vincent is right that the CRLSets[1] are a different mechanism
than OCSP revocation checking and that CRLSet checking is enabled by
default.  If it is broken then that would indeed be a serious bug.

Hope that helps,
Jonathan

[1] http://dev.chromium.org/Home/chromium-security/crlsets


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

Bug#669292: RFH: updating gitweb packaging for Apache 2.4

[Jonathan Nieder]

Hi,

With Apache 2.2, the gitweb package worked out of the box.  With
Apache 2.4, it doesn't.  http://bugs.debian.org/669292 tracks this
problem.

Last year, I tried to fix it --- patch at
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292

But I ran into several problems[*] around the upgrade path and
uninstallation procedure.  I think I understood how packaging for
apache 2.2 worked, and I just don't understand how packaging for
apache 2.4 works.

[*] https://lists.debian.org/debian-webapps/2013/12/msg0.html

In particular:

 * It's not clear when to run apache2_invoke enconf gitweb for a
   package like gitweb that does not have a Depends against apache
   2.4.  If I run it conditionally based on the Apache version, then
   gitweb will still be broken when the user upgrades apache, unless
   gitweb happens to be upgraded later in the same upgrade run.

 * It's not clear when to run apache2_invoke disconf gitweb.  At
   remove and purge time doesn't seem to be enough.

Until this is fixed, installing the gitweb package does not give the
user a usable installation of gitweb, meaning I've been sitting with
an RC bug for a long time.

Help?

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-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-rc-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 jrnie...@gmail.com  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#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 jrnie...@gmail.com  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-rc-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 jrnie...@gmail.com  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#735336: git-svn fails 'tempfile' can't be called as a method at /usr/share/perl5/Git.pm line 1042.

[Jonathan Nieder]

James Michael DuPont wrote:

 This is with : Gerrit Code Review http://code.google.com/p/gerrit/ (2.7)
 No shallow clones. Using git review to make the most basic changes.
 It seems to be all the time when I want to update an existing changes.
 Yes, I am able to build native version, debs and apply patches for sure.

Excellent.  I'd be interested in results from the following
experiment.

apt-get build-dep git; # as root

git clone https://kernel.googlesource.com/pub/scm/git/git
cd git
echo NO_OPENSSL=YesPlease config.mak
make -j8
PATH=$(pwd)/bin-wrappers:$PATH

... reproduce the bug

cd path/to/git
git revert --no-edit v1.8.4.2~10^2~1
make -j8

... see if the bug reproduces again

Thanks again, and sorry for the slow response.
Jonathan


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

Bug#735336: git-svn fails 'tempfile' can't be called as a method at /usr/share/perl5/Git.pm line 1042.

[Jonathan Nieder]

James Michael DuPont wrote:

 Using the freshly built version the problem does not occur :
 git version 1.8.5.3.321.g14598b9

Weird.  I don't think there's been a change that should
have fixed it.

Does 1.8.5.2 from testing or sid (putting /usr/bin earlier
in $PATH again) still reproduce the problem?

Puzzled,
Jonathan


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

Bug#735336: git-svn fails 'tempfile' can't be called as a method at /usr/share/perl5/Git.pm line 1042.

[Jonathan Nieder]

James Michael DuPont wrote:

 Well I started to use gerrit and got this problem, using the newest version
 of git 1.8 something that is why i had to downgrade.

What Gerrit version?

Does it happen only some of the time, or 100% of the time when you try
to push changes of a certain kind?

Are you using a shallow clone?

Part of what I'm puzzled about is that some people seem to have
similar symptoms with older versions of git, too.  For some reason
there are more reports of it recently (even though 1.8.4.2 which
introduced the most obvious potentially relevant change has been out
since November).

https://code.google.com/p/gerrit/issues/detail?id=1582
https://code.google.com/p/gerrit/issues/detail?id=1600
https://code.google.com/p/gerrit/issues/detail?id=2296

It sounds like the underlying problem is

https://bugs.eclipse.org/bugs/show_bug.cgi?id=422988

We may need to back out

 v1.8.4.2~10^2~1 (list-objects: mark more commits as edges in
 mark_edges_uninteresting, 2013-08-16)

for now to work around it.  If I provide a patched build or
instructions to patch and build your own, would you be able to test
such a workaround?

Thanks,
Jonathan


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

Bug#735336: git-svn fails 'tempfile' can't be called as a method at /usr/share/perl5/Git.pm line 1042.

[Jonathan Nieder]

Jonathan Nieder wrote:
 James Michael DuPont wrote:

 I am forced to use an older version of git because of the problems with
 gerrit.
 http://stackoverflow.com/questions/16586642/git-unpack-error-on-push-to-gerrit

 That is why I instlled the older version of git.

 Let's start with that.  Can you provide a simple recipe to reproduce
 the problem?

Also, when did you start experiencing the problem?  Did it coincide with
a git upgrade?

Curious,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-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 jrnie...@gmail.com
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 jrnie...@gmail.com
---
 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 jrnie...@gmail.com  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 21
-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/ ] 
+  [ ! -L /etc/apache2/conf.d/gitweb.conf ]
+then
+  ln -s ../conf-available/gitweb.conf /etc/apache2/conf.d/gitweb.conf
+fi
+  fi
+
+  if [ -x /etc

Bug#709947: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#708307: fixed in e2fsprogs 1.42.8-1)

[Jonathan Nieder]

Hi,

Theodore Ts'o wrote:

 We have a minor problem with uploading a fix.  E2fsprogs currently
 FTBFS on stable, due to bug #707996, whose root cause is #708061.  

 Personally, I blame glibc (#708061) for once again making a
 library-visible API change.  (If they didn't want programs to use
 __secure_getenv, they shouldn't have made it visible.)

Odd --- wouldn't building e2fsprogs in a wheezy chroot avoid trouble,
since libc in wheezy doesn't have that bug?

Thanks,
Jonathan


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

Bug#718654: [kfreebsd] git grep often segfaults

[Jonathan Nieder]

Package: git
Version: 1:1.8.3~rc3-1
Severity: serious
Justification: build failure

Hi,

A test failure story.  git grep compiles a bunch of copies of a
regex and then executes them in different threads.

Git 1:1.8.3~rc3-1 failed to build on both 32-bit and 64-bit GNU/kFreeBSD.
1:1.8.3~rc2-1 built fine.  The error, on the 32-bit system (finzi):

 Segmentation fault (core dumped)
 not ok 109 - grep from a subdirectory to search wider area (1)
 #
 #  mkdir -p s 
 #  (
 #  cd s  git grep x x x ..
 #  )
 #

On the 64-bit system (fano):

 Segmentation fault (core dumped)
 not ok 104 - grep -p with userdiff
 #
 #  git config diff.custom.funcname ^# 
 #  echo hello.c diff=custom .gitattributes 
 #  git grep -p return actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault (core dumped)
 not ok 109 - grep from a subdirectory to search wider area (1)
 #
 #  mkdir -p s 
 #  (
 #  cd s  git grep x x x ..
 #  )
 #

Same story with 1:1.8.3-1.  On 32-bit finzi:

 Segmentation fault
 not ok 79 - grep -C1 hunk mark between files
 #
 #  git grep -C1 ^[yz] actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 106 - grep -p -B5
 #
 #  git grep -p -B5 return actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 108 - grep -W with userdiff
 #
 #  test_when_finished rm -f .gitattributes 
 #  git config diff.custom.xfuncname (printf.*|})$ 
 #  echo hello.c diff=custom .gitattributes 
 #  git grep -W return actual 
 #  test_cmp expected actual
 #
[...]
 ../x:x x xx x
 Segmentation fault
 not ok 109 - grep from a subdirectory to search wider area (1)
 #
 #  mkdir -p s 
 #  (
 #  cd s  git grep x x x ..
 #  )
 #
[...]
 Segmentation fault
 --- expected   2013-05-31 04:16:24.0 +
 +++ actual 2013-05-31 04:16:25.0 +
 @@ -1,6 +1,3 @@
  BOLD;GREENhello.cRESET
  2:int main(int argc, const BLACK;BYELLOWcharRESET **argv)
  6:/* BLACK;BYELLOWcharRESET ?? */
 -
 -BOLD;GREENhello_worldRESET
 -3:HelBLACK;BYELLOWlo_wRESETorld
 not ok 150 - mimic ack-grep --group
 #
 #  test_config color.grep.context  normal 
 #  test_config color.grep.filename bold green 
 #  test_config color.grep.function normal 
 #  test_config color.grep.linenumber   normal 
 #  test_config color.grep.matchblack yellow 
 #  test_config color.grep.selected normal 
 #  test_config color.grep.separatornormal 
 #
 #  git grep --break --heading -n --color \
 #  -e char -e lo_w hello.c hello_world |
 #  test_decode_color actual 
 #  test_cmp expected actual
 #

On 64-bit fasch:

 Segmentation fault
 test_must_fail: died by signal: git grep -n -w -e ^w
 not ok 6 - grep -w HEAD (w)
 #
 #  : expected 
 #  test_must_fail git grep -n -w -e ^w actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 34 - grep -w in working tree
 #
 #  {
 #  echo ${HC}file:1:foo mmap bar
 #  echo ${HC}file:3:foo_mmap bar mmap
 #  echo ${HC}file:4:foo mmap bar_mmap
 #  echo ${HC}file:5:foo_mmap bar mmap baz
 #  } expected 
 #  git -c grep.linenumber=false grep -n -w -e mmap $H 
actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 42 - grep in working tree (t-1)
 #
 #  echo ${HC}t/t:1:test expected 
 #  git grep -n -e test $H actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 48 - grep --max-depth 0 -- '*' in working tree
 #
 #  {
 #  echo ${HC}t/a/v:1:vvv
 #  echo ${HC}t/v:1:vvv
 #  echo ${HC}v:1:vvv
 #  } expected 
 #  git grep --max-depth 0 -n -e vvv $H -- * actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 65 - grep -l -C
 #
 #  git grep -l -C1 foo actual 
 #  test_cmp expected actual
 #
[...]
 Segmentation fault
 not ok 67 - grep -L -C
[...]
 Segmentation fault
 not ok 69 - grep ( -e A --or -e B ) --and -e B
[...]
 Segmentation fault
 not ok 70 - grep -e A --and --not -e B
[...]
 Segmentation fault
 not ok 75 - grep, multiple patterns
[...]
 Segmentation fault
 not ok 78 - grep -q, silently report matches
[...]
 Segmentation fault
 not 

Bug#718655: [kfreebsd] git FTBFS: hang in tests

[Jonathan Nieder]

Source: git
Version: 1:1.8.4~rc1-1
Severity: serious
Justification: build failure

From the build log on fano (kfreebsd-amd64):

 ok 16 - push --no-progress suppresses progress
 not ok 17 - quiet push
 #
 #  ensure_fresh_upstream 
 #
 #  test_terminal git push --quiet --no-progress upstream master 
21 | tee output 
 #  test_cmp /dev/null output
 #
 # failed 1 among 17 test(s)
 1..17
 make[3]: *** [t5523-push-upstream.sh] Error 1
 make[3]: *** Waiting for unfinished jobs
 E: Caught signal ‘Terminated’: terminating immediately
 make[3]: *** [t0021-conversion.sh] Terminated
 make: *** [build-arch-stamp] Terminated
 make[2]: *** [test] Terminated
 make[1]: *** [test] Terminated
 Build killed with signal TERM after 150 minutes of inactivity

Likewise on finzi (kfreebsd-i386):

 *** t5709-clone-refspec.sh ***
 ok 1 - setup
 ok 2 - by default all branches will be kept updated
 ok 3 - by default no tags will be kept updated
 ok 4 - --single-branch while HEAD pointing at master
 E: Caught signal ‘Terminated’: terminating immediately
 wait: Interrupted system call.  Stop.
 make[3]: *** Waiting for unfinished jobs
 make[3]: *** [t5709-clone-refspec.sh] Terminated
 make[3]: *** [t0021-conversion.sh] Terminated
 make: *** [build-arch-stamp] Terminated
 make[2]: *** [test] Error 2
 make[1]: *** [test] Terminated
 make[3]: Leaving directory `/«PKGBUILDDIR»/t'
 Build killed with signal TERM after 150 minutes of inactivity

Other arches run the test suite without trouble.


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

Bug#718655: [kfreebsd] git FTBFS: hang in tests

[Jonathan Nieder]

tags 718655 + unreproducible
quit

Jonathan Nieder wrote:

 From the build log on fano (kfreebsd-amd64):
[...]
  make[3]: *** [t5523-push-upstream.sh] Error 1
  make[3]: *** Waiting for unfinished jobs
  E: Caught signal ‘Terminated’: terminating immediately
  make[3]: *** [t0021-conversion.sh] Terminated
  make: *** [build-arch-stamp] Terminated
  make[2]: *** [test] Terminated
  make[1]: *** [test] Terminated
  Build killed with signal TERM after 150 minutes of inactivity

 Likewise on finzi (kfreebsd-i386):
[...]
  E: Caught signal ‘Terminated’: terminating immediately
  wait: Interrupted system call.  Stop.
  make[3]: *** Waiting for unfinished jobs
  make[3]: *** [t5709-clone-refspec.sh] Terminated
  make[3]: *** [t0021-conversion.sh] Terminated
  make: *** [build-arch-stamp] Terminated
[...]
  Build killed with signal TERM after 150 minutes of inactivity

Building git with plain dpkg-buildpackage in a sid schroot on falla
worked fine and passed all tests.

Is it possible fano and finzi are just overloaded and the inactivity
timer triggered due to a test taking too long?  I've uploaded the
binary package built on falla, but it would be nice to know what was
going on for next time.

Thanks,
Jonathan


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

Bug#692884: guilt conflicts with git 1.8

[Jonathan Nieder]

tags 692884 + upstream fixed-upstream
quit

Axel Beckert wrote:
 Thomas Koch wrote:

 I'm not aware of any changes in Git 1.8 that could make guilt
 incompatible.
[...]
 I intend to NMU this issue via the DELAYED/N queue. Patch will be
 based on Jonathan Nieder's suggestion in http://bugs.debian.org/589708

Thanks!  FWIW this is also fixed upstream, as you probably noticed.

Regards,
Jonathan


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

Bug#709382: Built-Using, libgcc, and libc_nonshared

[Jonathan Nieder]

Russ Allbery wrote:

mksh-static of
 course links statically and therefore pulls in substantial portions of
 library source, but there are parts of libgcc and possibly libc that are
 always incorporated into binaries, even ones that are dynamically linked.

Are those parts that are incorporated when dynamically linking
substantial enough to be relevant for copyright law?

If so, the gcc runtime license is problematic, since it would render all
GPLv2-only programs nondistributable by Debian dstributors because the
clause unless that component itself accompanies the executable would
take effect.  So I think we would need to get clarification from the
gcc runtime authors in that case.

Thanks,
Jonathan


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

Bug#707306: libc6: unable to upgrade to 2.17 getting errors while configuring

[Jonathan Nieder]

Hi,

shirish शिरीष wrote:

 A copy of the C library was found in an unexpected directory:
   '/lib/libdl-2.11.2.so'
[...]
 I removed the offending library copy as well as the original, quite a
 few of them before I was able to correctly install it without any
 errors :-

Where did these files come from?


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

Bug#706400: git: FTBFS on some arches: t4205 fails

[Jonathan Nieder]

Source: git
Version: 1:1.8.3~rc0-1
Severity: serious
Justification: ftbfs
Tags: upstream patch
Control: forwarded -1 
http://thread.gmane.org/gmane.comp.version-control.git/222680

From https://buildd.debian.org/status/logs.php?pkg=gitver=1%3A1.8.3~rc0-1:

| expecting success: 
|   git log --pretty=format:%(10,trunc)%s actual 
|   # complete the incomplete line at the end
|   echo actual 
|   qz_to_tab_space \EOF expected 
| message ..
| message ..
| add bar  Z
| initial  Z
| EOF
|   test_cmp expected actual
| 
| --- expected  2013-04-29 09:40:01.162652311 +
| +++ actual2013-04-29 09:40:01.158641606 +
| @@ -1,4 +1,4 @@
| -message ..
| -message ..
| +
| +
|  add bar   
|  initial   
| not ok 18 - left alignment formatting with trunc
| # 
| # git log --pretty=format:%(10,trunc)%s actual 
| # # complete the incomplete line at the end
| # echo actual 
| # qz_to_tab_space \EOF expected 
| # message ..
| # message ..
| # add bar  Z
| # initial  Z
| # EOF
| # test_cmp expected actual
| # 

The cause is undefined behavior (different orders of evaluation of
arguments to a function call can be convenient on different arches).
Patch at the link above.

Regards,
Jonathan


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

Bug#703092: dpkg --set-selections ignores available packages never installed or removed by dpkg

[Jonathan Nieder]

severity 703092 important
quit

Hi,

Norbert Preining wrote:

 [Subject: setting this to critical]

Please keep in mind that these appear as emails in a crowded inbox,
where a subject line can provide valuable context.

 It might look harmless, but we do *NOT* want to release Debian
 with a dpkg that is broken with respect to all the descriptions
 floating around how to clone a system.

I agree that this is a problem, but I cannot convince myself it breaks
the entire system.  Therefore I'm lowering the severity.

Presumably this is due to

  1.16.2~15 dpkg: Only allow setting selections for known packages,
2012-03-17

It is a shame the impact of that commit on existing workflows was not
noticed until a year later.  Guillem, can you say a little about the
motivation behind the change?  Would it be safe to revert it?

Thanks,
Jonathan


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

Bug#704498: git: FTBFS on a random selection of arches

[Jonathan Nieder]

Source: git
Version: 1:1.8.2-1
Severity: serious
Justification: ftbfs
Tags: patch

Hi,

Based on https://buildd.debian.org/status/logs.php?pkg=gitver=1%3A1.8.2-1,
it seems that the git 1:1.8.2-1 build is unreliable.  The most
relevant seeming recent change was enabling parallel build.  Here's a
patch to undo that.

Thanks,
Jonathan

diff --git i/debian/rules w/debian/rules
index a761bd2..0146af7 100755
--- i/debian/rules
+++ w/debian/rules
@@ -27,10 +27,6 @@ endif
 ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
   TEST =
 endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-  NUMJOBS = $(patsubst parallel=%,%,$(filter PARALLEL=%,$(DEB_BUILD_OPTIONS)))
-  MAKEFLAGS += -j$(NUMJOBS)
-endif
 
 PKG_INDEP =
 PKG_INDEP += git-doc


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

Bug#704498: git: FTBFS on a random selection of arches

[Jonathan Nieder]

Jonathan Nieder wrote:

 Based on https://buildd.debian.org/status/logs.php?pkg=gitver=1%3A1.8.2-1,
 it seems that the git 1:1.8.2-1 build is unreliable.

hurd-i386:

*** t5500-fetch-pack.sh ***
ok 1 - setup
ok 2 - 1st pull
ok 3 - post 1st pull setup
ok 4 - 2nd pull
make[3]: *** [t5500-fetch-pack.sh] Terminated
make: *** [build-arch-stamp] Terminated
make[2]: *** [test] Terminated
make[1]: *** [test] Terminated
Build killed with signal TERM after 233 minutes of inactivity

kfreebsd-amd64:

not ok 4 - gc: implicit prune --expire
...
make[3]: *** [t5304-prune.sh] Error 1
make[3]: *** Waiting for unfinished jobs

s390:

make: *** [git.deb-DEBIAN-md5sums] Error 1
make: *** Waiting for unfinished jobs

s390x:

make: *** [git.deb-DEBIAN-md5sums] Error 1
make: *** Waiting for unfinished jobs

sparc:

not ok 4 - gc: implicit prune --expire
...
make[3]: *** [t5304-prune.sh] Error 1
make[3]: *** Waiting for unfinished jobs


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

Bug#703468: [3.2.35-2 - 3.2.39-1 regression] fails to boot on apple iMac

[Jonathan Nieder]

found 703468 linux/3.2.41-2
quit

Jonathan Nieder wrote:

 I think a good place to start would be to try 3.2.41-2 from unstable,
 since it includes some i915 fixes.

Ah, looking back over the log I see that's been tried.  So:

 A good next step would be to try 3.8.y from experimental.  If it
 works, we can try to find what is missing in the 3.4.y driver
 backport.  If it doesn't work, we can get help from upstream.

Jonathan


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

Bug#703468: [3.2.35-2 - 3.2.39-1 regression] fails to boot on apple iMac

[Jonathan Nieder]

Hi,

Michael Gilbert wrote:

 The following string is still recognizable:
 i915_gem_init_ppgtt+0x93/0x16c [i915]

 This is going to take some work on your end to get fixed.  3.2.39-1
 included backported patches from aspects of the i915 driver.

I think a good place to start would be to try 3.2.41-2 from unstable,
since it includes some i915 fixes.

A good next step would be to try 3.8.y from experimental.  If it
works, we can try to find what is missing in the 3.4.y driver
backport.  If it doesn't work, we can get help from upstream.

[...]
 You can find what has changed between 3.2.35 and 3.2.39 by using
 debdiff from the devscripts package

Unfortunately that range includes a pretty major change:

  * Backport drm and agp subsystems from Linux 3.4.29 (closes: #687442)

Hope that helps,
Jonathan


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

Bug#699937: [wheezy] crash caused by disconnecting usb audio device

[Jonathan Nieder]

forcemerge 696321 699937
quit

Hi Mark,

Mark A. Hershberger wrote:

 If I remove the USB headset while sound is playing, the screen goes
 blank and a kernel trace is displayed.

Please attach a photograph of the kernel trace.

Thanks for writing and sorry for the trouble,
Jonathan


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

Bug#699218: procps: FTBFS with test suite error: testsuite/lib.test/fileutils_badfd.sh missing

[Jonathan Nieder]

Hi,

Craig Small wrote:
 On Tue, Jan 29, 2013 at 09:22:59AM +0100, Sascha Silbe wrote:

 ERROR: couldn't execute 
 /home/sascha.silbe/src/deb/procps-3.3.3/testsuite/lib.test/fileutils_badfd.sh:
  no such file or directory

 This file now appears in procps 3.3.6 I'm not sure why you triggered
 that and i didn't as make check is run each time.

Would you mind uploading 3.3.6 to experimental to make it easier for
people like me to play with it without interfering with release
preparations?

Thanks,
Jonathan


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

Bug#699177: Wrong sorting in pathname expansion

[Jonathan Nieder]

retitle 699177 dash ignores locale
tags 699177 + upstream
# standards compliance, i18n
severity 699177 important
quit

Hi Alexander,

Alexander Gerasiov wrote:

 If the pattern matches any existing filenames or pathnames, the pattern
 shall be replaced with those filenames and pathnames, sorted according to the
 collating sequence in effect in the current locale.

Yes, that's true.

Actually dash doesn't respect locales at all.

Standards-compliance bugs in dash generally are important (and not
necessarily serious).  In this case it is more complicated --- calling
'setlocale(LC_ALL, )' would require reexamining every
locale-dependent library call dash makes and would hurt
backward-compatibility.  Help analyzing calls to mitigate the damage
would be much appreciated.

In the meantime, we should at least document it better in the manpage.
Any ideas for wording?

Thanks for reporting and hope that helps,
Jonathan


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

Bug#691180: connman: Connman won't run due to missing libxtables.so.7

[Jonathan Nieder]

reassign 691180 iptables 1.4.14-3
affects 691180 + connman
quit

Hi Julien,

Julien Cristau wrote:
 On Thu, Jan 24, 2013 at 01:22:21 -0800, Jonathan Nieder wrote:

 In wheezy, there is instead an unversioned dependency on iptables,
 which is not enough to ensure the correct shared library is present:
[...]
 NAK.  iptables in sid needs to add Breaks on the packages in wheezy that
 want libxtables.so.7.  And 691180 should be reassigned to iptables.

Huh?  Changing iptables in sid would fix squeeze-to-wheezy upgrades
how, exactly?

To recap, iptables in squeeze and wheezy contain a shared library
(libxtables) used by other packages.  The version in squeeze is

/lib/libxtables.so.4

The version in wheezy is

/lib/libxtables.so.7

This produces upgrade problems.


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

Bug#691180: connman: Connman won't run due to missing libxtables.so.7

[Jonathan Nieder]

Julien Cristau wrote:
 On Sat, Jan 26, 2013 at 07:04:16 -0800, Jonathan Nieder wrote:
 Julien Cristau wrote:

 NAK.  iptables in sid needs to add Breaks on the packages in wheezy that
 want libxtables.so.7.  And 691180 should be reassigned to iptables.
[...]
 To recap, iptables in squeeze and wheezy contain a shared library
 (libxtables) used by other packages.  The version in squeeze is

  /lib/libxtables.so.4

 The version in wheezy is

  /lib/libxtables.so.7

 This produces upgrade problems.

 Well then iptables in wheezy should have breaks on the packages in
 squeeze that link against libxtables.so.4, too...

What package expression can iptables/sid use to represent packages
using libxtables built against iptables/wheezy?  Dependencies like

Breaks: connman ( 1.0-1.2)

become useless as soon as a newer version of connman is in
wheezy-backports.

I don't know what constraint makes introducing a libxtables7 package a
bad thing to do, so I don't know how to avoid it when coming up with
an appropriate fix.  One possibility would be to make iptables
'Provides: libxtables7' and to make shlibs create dependencies on
that.

That said, here's a patch adding appropriate Breaks for
squeeze-wheezy upgrades.  Luckily not every package with a build-time
dependency on iptables-dev uses libxtables.

diff --git i/debian/changelog w/debian/changelog
index 6e7f55c2..eaf24993 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,11 @@
+iptables (1.4.14-3.1) testing; urgency=low
+
+  * Non-maintainer upload.
+  * Add Breaks against iproute and xtables-addons-common versions
+that relied on libxtables4. Closes: #691180
+
+ -- Jonathan Nieder jrnie...@gmail.com  Sat, 26 Jan 2013 08:31:40 -0800
+
 iptables (1.4.14-3) unstable; urgency=low
 
   * Fixes iptables comment output error reported by Christoph Anton
diff --git i/debian/control w/debian/control
index 1e9d513c..32e26642 100644
--- i/debian/control
+++ w/debian/control
@@ -9,6 +9,7 @@ Homepage: http://www.netfilter.org/
 Package: iptables
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: iproute ( 20120521-3), xtables-addons-common ( 1.42-2)
 Description: administration tools for packet filtering and NAT
  These are the user-space administration tools for the Linux
  kernel's netfilter and iptables. netfilter and iptables provide


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

Bug#691180: connman: Connman won't run due to missing libxtables.so.7

[Jonathan Nieder]

found 691180 connman/1.0-1.1+wheezy1
fixed 691180 connman/1.0-1.2
quit

Hi Adrian,

John Paul Adrian Glaubitz wrote:

 close 691180
 thanks

 Hi,

 there have been new uploads of connman both into testing and unstable,
 the issue has been resolved as the package has been rebuilt in both
 cases.

This has been fixed in sid but not in wheezy. :(

In sid, the dependency on libxtables9 avoids trouble:

 $ cupt show connman/sid | egrep 'Version|Depends|Conflicts|Breaks'
 Version: 1.0-1.2
 Depends: libc6 (= 2.9), libdbus-1-3 (= 1.1.1), libglib2.0-0 (= 2.28.0), 
libgnutls26 (= 2.12.17-0), libxtables9, dbus, lsb-base

In wheezy, there is instead an unversioned dependency on iptables,
which is not enough to ensure the correct shared library is present:

 $ cupt show connman/wheezy | egrep 'Version|Depends|Conflicts|Breaks'
 Version: 1.0-1.1+wheezy1
 Depends: iptables, libc6 (= 2.9), libdbus-1-3 (= 1.1.1), libglib2.0-0 (= 
2.28.0), libgnutls26 (= 2.12.17-0), dbus, lsb-base

Fixing this properly would presumably require an iptables update in
testing (either bumping shlibs or, better, backporting the
introduction of a separate libxtables9 package from sid) followed by a
binnmu.

Hope that helps,
Jonathan


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

Bug#691180: connman: Connman won't run due to missing libxtables.so.7

[Jonathan Nieder]

Adam D. Barratt wrote:
 On 24.01.2013 09:22, Jonathan Nieder wrote:

 Fixing this properly would presumably require an iptables update in
 testing (either bumping shlibs or, better, backporting the
 introduction of a separate libxtables9 package from sid) followed by a
 binnmu.

 Introducing new binary packages via tpu at this stage of a freeze doesn't
 immediately meet my definition of better, fwiw...

Sure.  It's better because without a separate package the upgrade path
is complicated.  With a separate package:

install libxtables9
upgrade packages that use libxtables
upgrade iptables

Without a separate package:

deconfigure packages that use libxtables
upgrade iptables
upgrade packages that use libxtables

In other words, having a separate package allows both versions of
the library to coexist on the filesystem.

Here are the Reverse-build-dependencies of iptables-dev: collectd,
connman, iproute, linux-igd, nufw, perlipq, shaperd, west-chamber,
xtables-addons.

Of those, only connman and xtables-addons declare a dependency on
libxtables9.  It looks like the transition wasn't finished in sid. :(


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

Bug#697085: qemu-system: tries to overwrite doc/qemu/qemu-doc.html from qemu (missing Breaks+Replaces?)

[Jonathan Nieder]

Michael Tokarev wrote:

 We believe that the bug you reported is fixed in the latest version of
 qemu, which is due to be installed in the Debian FTP archive.

Thanks.

[...]
  qemu (1.3.0+dfsg-2exp) experimental; urgency=low
[...]
* move vde2 from Recommends to Suggests, since it isn't
  used often

Nice.

[...]
* add qemu-kvm package (transitional, depends on qemu-system),
  and add /usr/bin/kvm wrapper that calls qemu-system-x86_64
  with some arguments to match original qemu-kvm behavour.
  (Closes: #560853)

Oh, excellent!

Exciting times.  Thanks for your work.
Jonathan


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

Bug#698259: guilt: Maintainer address does not accept mail

[Jonathan Nieder]

Source: guilt
Version: 0.35-1
Severity: serious
Justification: policy 3.3

Hi,

The address iul...@linux.com seems to be out of date.  Do you happen to
know a more recent one?

Thanks,
Jonathan
---BeginMessage---
Delivery to the following recipient failed permanently:

 iul...@linux.com

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the recipient 
domain. We recommend contacting the other email provider for further 
information about the cause of this error. The error that the other server 
returned was: 550 550 5.1.1 iul...@linux.com: Recipient address rejected: 
User unknown in virtual alias table (state 13).

- Original message -

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
 :mime-version:content-type:content-disposition:in-reply-to
 :user-agent;
bh=5R77SXo5cl/kTRPyQ+w6XB9KL6CyQ3iNYS4jGh5viJI=;
b=sCTr9rFLYRw1/L0/c1tcb5qtrMYE/l9WJHx7ciNzSwpVx4ZUroI+HyL887JaTIh6AI
 KVH3FXascYIJkFgnHKxQIxcLSFEnQY5zwCMJ2P6UKUD9VMWp2iCJljuXRtqI6PdR4N7t
 MetjkGv2tbkxAOx/YU0M5rNFVkiPP5ovS0uyy/TB8UydlICHr7QUtI6EedYUdg7VrXac
 b+SGtfW3NXpQbcwiChYpeLU/1mx7dvcI4PWRUwH7/0dV4bYEdi+vvl2blMOLbRyBf8kq
 bfG5MEI+ijyReqNnRFoxUWvgpP2ZoFhlMdif5I5hodj8dInXZwBgLP0vupdL8e9kwvJT
 +uMw==
X-Received: by 10.68.226.71 with SMTP id rq7mr270522746pbc.60.1358303508667;
Tue, 15 Jan 2013 18:31:48 -0800 (PST)
Return-Path: jrnie...@gmail.com
Received: from google.com ([2620:0:1000:5b00:b6b5:2fff:fec3:b50d])
by mx.google.com with ESMTPS id gj1sm11299307pbc.11.2013.01.15.18.31.46
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Tue, 15 Jan 2013 18:31:47 -0800 (PST)
Date: Tue, 15 Jan 2013 18:31:44 -0800
From: Jonathan Nieder jrnie...@gmail.com
To: Josef 'Jeff' Sipek jef...@josefsipek.net
Cc: g...@vger.kernel.org, Per Cederqvist ced...@opera.com,
Theodore Ts'o ty...@mit.edu, Iulian Udrea iul...@linux.com,
Axel Beckert a...@deuxchevaux.org
Subject: [GUILT]  [PATCH 7/7] Drop unneeded git version check.
Message-ID: 20130116023144.gp12...@google.com
References: 20130116022606.gi12...@google.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 20130116022606.gi12...@google.com
User-Agent: Mutt/1.5.21 (2010-09-15)

Git's compatibility record is pretty good, so there's no need to worry
that newer versions of git will break the git config command.

Without this change, guilt errors out for git 1.8.  With it, all tests
pass.

Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading.

 guilt | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/guilt b/guilt
index 66a671a..6cb43e3 100755
--- a/guilt
+++ b/guilt
@@ -26,17 +26,6 @@ SUBDIRECTORY_OK=1
 . $(git --exec-path)/git-sh-setup
 
 #
-# Git version check
-#
-gitver=`git --version | cut -d' ' -f3 | sed -e 's/^debian\.//'`
-case $gitver in
-   1.5.*)  ;; # git config
-   1.6.*)  ;; # git config
-   1.7.*)  ;; # git config
-   *)  die Unsupported version of git ($gitver) ;;
-esac
-
-#
 # Shell library
 #
 usage()
-- 
1.8.1

---End Message---

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Jonathan Nieder]

Hi Paul,

Paul C wrote:

 I think I am having the same issue here with Ivy Bridge.
[...]
 I've followed this thread through trying out various different options with
 boot parameters (mtrr) and also have now got the system on the Liquorix
 3.7.x kernel. Same crashes.

That doesn't match Per's experience --- he found that 3.5.5 already
worked fine.

Would you mind filing a new bug?  We can always merge them later if
they turn out to have the same cause.

Thanks,
Jonathan


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

Bug#696909: chromium segfaults on startup on armhf

[Jonathan Nieder]

Hi Peter,

peter green wrote:

 Patch to make the package use bfd rather than gold on armel and armhf is
 attached. I may or may not upload this as a NMU.

If you'll have time to continue working on chromium:arm in the future,
it would probably be better to just add yourself to pkg-chromium on
alioth.

Thanks for your work,
Jonathan


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

Bug#697085: qemu-system: tries to overwrite doc/qemu/qemu-doc.html from qemu (missing Breaks+Replaces?)

[Jonathan Nieder]

Package: qemu-system
Version: 1.3.0+dfsg-1~exp1
Severity: serious
Justification: failed upgrade

From today's upgrade:

| Preparing to replace qemu-system 1.3.0+dfsg-1~exp1 (using 
.../qemu-system_1.3.0+dfsg-1~exp3_amd64.deb) ...
| Unpacking replacement qemu-system ...
| dpkg: error processing 
//var/cache/apt/archives/qemu-system_1.3.0+dfsg-1~exp3_amd64.deb (--install):
|  trying to overwrite '/usr/share/doc/qemu/qemu-doc.html', which is also in 
package qemu 1.3.0+dfsg-1~exp1
| dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

Known problem?

Thanks,
Jonathan


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

Bug#697085: qemu-system: tries to overwrite doc/qemu/qemu-doc.html from qemu (missing Breaks+Replaces?)

[Jonathan Nieder]

# uninstallable
severity 697085 grave
quit

Jonathan Nieder wrote:

 | Preparing to replace qemu-system 1.3.0+dfsg-1~exp1 (using 
 .../qemu-system_1.3.0+dfsg-1~exp3_amd64.deb) ...
 | Unpacking replacement qemu-system ...
 | dpkg: error processing 
 //var/cache/apt/archives/qemu-system_1.3.0+dfsg-1~exp3_amd64.deb (--install):
 |  trying to overwrite '/usr/share/doc/qemu/qemu-doc.html', which is also in 
 package qemu 1.3.0+dfsg-1~exp1

Quick update: qemu 1.3.0+dfsg-1~exp3 contains the same file, which
means qemu in experimental cannot be installed.


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

Bug#686502: pxz produces archives broken for busybox's unxz

[Jonathan Nieder]

Abou Al Montacir wrote:

 Hover, I assume we can save this extra code as soon as we don't loose
 data.

That's fine with me.  All you'd need to do is error out if there is
anything after the first stream.  That would make it a conformant
decoder and prevent silent data loss, though it would mean busybox
couldn't read the XZ files pxz produces.

(Context: the spec permits single-stream decoders because there are
decoders in the wild that need to be very simple, like the one built
into the Linux kernel that unpacks the kernel and initramfs.)

On the other hand, if busybox is to start decoding concatenated
streams (imitating the standard xz command), then the spec requires
also correctly implementing padding.  This might sound rigid, but it
is important for interoperability --- without such requirements,
whenever you share XZ files there would be a lot of confusion about
whether it is valid and which implementations can and can't decode it.

I think busybox upstream would agree that the spec shouldn't just be
ignored.

Hoping that clarifies,
Jonathan


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

Bug#686502: pxz produces archives broken for busybox's unxz

[Jonathan Nieder]

Abou Al Montacir wrote:
 On Sat, 2012-12-22 at 10:21 -0800, Jonathan Nieder wrote:

 What happens if a stream ends at a buffer boundary, followed by
 padding?  Or if padding doesn't fit in the buffer, for that
 matter?
[...]
 Please find attached new debdiff with fix of above mentioned issues.

Getting closer.  Does this correctly handle the case of a file with
zero streams?  (It should error out.)  How about a file with leading
NUL bytes, which is also invalid?

Does this implementation meet the following requirement (from the
spec)?

| Stream Padding MUST contain only null bytes. To preserve the
| four-byte alignment of consecutive Streams, the size of Stream
| Padding MUST be a multiple of four bytes. Empty Stream Padding
| is allowed. If these requirements are not met, the decoder MUST
| indicate an error.

Thanks for your patient work.
Jonathan


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

Bug#686502: pxz produces archives broken for busybox's unxz

[Jonathan Nieder]

Abou Al Montacir wrote:

 +--- busybox-1.20.0~/archival/libarchive/decompress_unxz.c2012-12-20 
 21:51:04.0 +0100
  busybox-1.20.0/archival/libarchive/decompress_unxz.c 2012-12-20 
 21:49:11.0 +0100
 +@@ -87,7 +87,17 @@ unpack_xz_stream(transformer_aux_data_t *aux, int src_fd, 
 int dst_fd)
 + iobuf.out_pos = 0;
 + }
 + if (r == XZ_STREAM_END) {
 +-break;
 ++if (iobuf.in_pos != iobuf.in_size) {
[...]
 ++}
 ++// Look for other streams
 ++continue;

What happens if a stream ends at a buffer boundary, followed by
padding?  Or if padding doesn't fit in the buffer, for that
matter?

Hope that helps,
Jonathan


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