Bug#776174: git bash completion script missing

[Jonathan Nieder]

Hi Freddie,

Freddie Exall wrote:

 Git bash completion isn't working for me. I assume this is due to the
 lack of the /etc/bash_completion/git script.

Can you say more about what doesn't work?  Some context is in
/usr/share/doc/git/NEWS.Debian.gz:

|  Git's bash completion script is now loaded on the fly when tab
|  completion is attempted for the 'git' or 'gitk' command.  This
|  change involved moving the completion script.  If your ~/.bashrc
|  previously contained
|
|. /etc/bash_completion.d/git
|
|  then it should be corrected to
|
|if [ -e /usr/share/bash-completion/completions/git ]; then
|  . /usr/share/bash-completion/completions/git
|elif [ -e /etc/bash_completion.d/git ]; then
|  . /etc/bash_completion.d/git
|fi
|
|  or, better,
|
|. /etc/bash_completion
|
|  See /usr/share/doc/bash-completion/README.Debian for details.

Thanks,
Jonathan


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

Bug#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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775236: gitweb breaks apache2 configuration - Invalid command 'AddHandler'

[Jonathan Nieder]

Hi Uwe,

Uwe Storbeck wrote:

 the upgrade of gitweb from version 1:2.1.3-1 to 1:2.1.4-2 broke
 the apache2 configuration on my system:

   apache2_invoke: Enable configuration gitweb
   apache2_reload: Your configuration is broken. Not reloading Apache 2
   apache2_reload: AH00526: Syntax error on line 15 of 
 /etc/apache2/conf-enabled/gitweb.conf:
   apache2_reload: Invalid command 'AddHandler', perhaps misspelled or defined 
 by a module not included in the server configuration

 It looks like gitweb requires mod_mime to be enabled on the web
 server. At least my apache server starts again after enabling
 mod_mime.

I'll make the configuration conditional on mod_mime with the next
upload.

Sorry for the trouble,
Jonathan


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

Bug#773245: git-p4 contrib package

[Jonathan Nieder]

retitle 773245 ITP: git-p4 -- Perforce importer/exporter for git
severity 773245 wishlist
reassign 773245 wnpp
merge 715534 773245
quit

Hi Luke,

Luke Diamand wrote:

 I put in a patch to make a git-p4 package in contib last year.

Oh!  Nice.

I'm not sure if it's possible for a source package in 'main' to produce
a binary package in 'contrib'.  I'll ask on debian-mentors@.

If git-p4 needs to be a separate source package, I'll be happy to
sponsor it.

Thanks,
Jonathan


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

Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all

[Jonathan Nieder]

Hi,

Robert Luberda wrote:

 Please explicitly state in the Policy if linking
 /usr/share/doc/arch:any_package to ../arch:all_package 
 (where arch:any_package and arch:all_package come 
 from the same source package)  is allowed or not.

It currently is not allowed.

[...]
 In my opinion, as I wrote in #766711, footnote [116] allows such
 linking, as it seems to refer to source version of a package.

I agree that the text is confusing.  The reference to source
there is meant to refer to the source package, not to the source
package version.

Thanks and hope that helps,
Jonathan


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

Bug#773245: git-p4 package in contrib, how to proceed?

[Jonathan Nieder]

reassign 773245 src:git 1:2.1.3-1
quit

Vincent Cheng wrote:

 Yes, source packages in main can generate binary packages in contrib;
 Policy does not prevent this from happening, and there are existing
 source packages in main, in the archive, which generate binary
 packages in contrib. See e.g. src:nvidia-settings (and #747837 which
 was what prompted one of the binary packages built from it to be moved
 from contrib to main).

Thanks for looking into it.  I'll apply the patch for git in jessie+1.

Regards,
Jonathan


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

Bug#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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731634: xz-utils: new upstream version 5.2.1

[Jonathan Nieder]

severity 731634 wishlist
quit

Hi,

Riku Voipio wrote:

 New version with threaded compression support would really be appreceated.

Thanks for reporting.

[...]
 severity 731634 important

Why important, though?  Is there a package depending on this behavior,
a reason it is needed in stable, or an unreported important bug that
is fixed by the upgrade?

Thanks,
Jonathan


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

Bug#731634: xz-utils: new upstream version 5.2.1

[Jonathan Nieder]

Riku Voipio wrote:
 On Friday, March 27, 2015 7:32:26 PM EET, Jonathan Nieder wrote:

 Why important, though?
[...]
 Mostly because the other bug merged (#777267) was already important,
 and severities need to match when merging. My interest in the new
 version is the threaded compression support - with dpkg now using
 liblzma as backend this should save considerable amount of time
 currently spent waiting building big -dbg packages etc.

Got it.  Thanks for the quick answers.

I'd like to get this done in a coming weekend (perhaps this one,
perhaps in a couple of weeks).  I also don't mind if someone else
takes care of it for me and sends patches. ;-)

Regards,
Jonathan


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

Bug#783654: 'git clone -b' should accept bare SHA-1

[Jonathan Nieder]

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

A little known feature of 'git clone -b' is that its argument doesn't
need to be a branch name:

$ git clone -b v2.1.3 --depth=1 
https://kernel.googlesource.com/pub/scm/git/git 
Cloning into 'git'...
remote: Sending approximately 57.46 MiB ...
remote: Counting objects: 2797, done
remote: Finding sources: 100% (2797/2797)
remote: Total 2797 (delta 241), reused 1264 (delta 241)
Receiving objects: 100% (2797/2797), 5.43 MiB | 4.31 MiB/s, done.
Resolving deltas: 100% (241/241), done.
Checking connectivity... done.
Note: checking out '49c3e926349e964b311b46251bb2b97d3d669855'.

You are in 'detached HEAD' state. [...]

Alas, the syntax after -b is not as permissive as what git fetch
accepts:

$ git clone -b refs/tags/v2.1.3 --depth=1 
https://kernel.googlesource.com/pub/scm/git/git 
Cloning into 'git'...
warning: Could not find remote branch refs/tags/v2.1.3 to clone.
fatal: Remote branch refs/tags/v2.1.3 not found in upstream origin

In particular, while 'git fetch' has accepted a SHA-1 to mean fetch this 
commit,
and I don't care what branch it's on ever since v1.8.3-rc0~206^2 (2013-01-29),
'git clone -b' does not.  It would be helpful to.

$ git clone -b 49c3e926349e964b311b46251bb2b97d3d669855 --depth=1 
https://kernel.googlesource.com/pub/scm/git/git 
Cloning into 'git'...
warning: Could not find remote branch 
49c3e926349e964b311b46251bb2b97d3d669855 to clone.
fatal: Remote branch 49c3e926349e964b311b46251bb2b97d3d669855 not found 
in upstream origin


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

Bug#568374: debian-policy: section "8.4 Development files" not explicit enough regarding libraryname[soversion]-dev

[Jonathan Nieder]

Emilio Pozuelo Monfort wrote:
> On Tue, 27 Oct 2015 10:06:50 +0100 Ansgar Burchardt  wrote:

>> I suggest to change
>>
>> | If there are development files associated with a shared
>> | library, the source package needs to generate a binary
>> | development package named librarynamesoversion-dev, or if you
>> | prefer only to support one development version at a time,
>> | libraryname-dev.
>>
>> to
>>
>> | If there are development files associated with a shared
>> | library, the source package needs to generate a binary
>> | development package named libraryname-dev, or if you
>> | need to support multiple development versions at a time,
>> | librarynameAPIVERSION-dev.
>>
>> The changes are:
>>
>> Recommend unversioned -dev packages over versioned ones.
>>
>> For versioned -dev packages, use APIVERSION instead of SONAMEVERSION as
>> API and ABI can change independently.  This matches current practice: as
>> a random example: libgweather-3-dev + libgweather-3-6
>
> Seconded.

Seconded.

Thanks,
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#798602: [regression 2.5.0->2.5.1] git pull fails: "git upload-pack: git-pack-objects died with error"

[Jonathan Nieder]

# regression
severity 798602 important
tags 798602 + upstream fixed-upstream
quit

Hi,

Axel Beckert wrote:

> My coworker (who ran into this issue on MacOS X) finally found what
> triggers this issue. It's the following setting in our both's ~/.ssh/config:
>
>   SendEnv TERM GIT_*
>
> Intention of this is to forward variables like GIT_EDITOR,
> GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME and
> GIT_AUTHOR_EMAIL via SSH. Unfortunately git since 2.5.1 additionally
> seems to set GIT_WORK_TREE -- which gets forwarded that way, too.

Ah!  I had been wondering why this only started showing up recently.

> The fix is to change the according line in ~/.ssh/config to
>
>   SendEnv TERM GIT_EDITOR GIT_COMMITTER_* GIT_AUTHOR_*

There is a change on the "next" branch:

  aab40438 git_connect: clear GIT_* environment for ssh, 2015-09-04

It filters out the following variables:

  GIT_ALTERNATE_OBJECT_DIRECTORIES
  GIT_CONFIG
  GIT_CONFIG_PARAMETERS
  GIT_OBJECT_DIRECTORY
  GIT_DIR
  GIT_WORK_TREE
  GIT_IMPLICIT_WORK_TREE
  GIT_GRAFT_FILE
  GIT_INDEX_FILE
  GIT_NO_REPLACE_OBJECTS
  GIT_REPLACE_REF_BASE
  GIT_PREFIX
  GIT_SHALLOW_FILE
  GIT_COMMON_DIR

I think that should help.  It will probably land in 2.7.0, but I can
apply it earlier.

The GIT_CONFIG_PARAMETERS is particularly important: if the server
allows the environment variable through then arbitrary code execution
isn't hard.

Thanks,
Jonathan

Bug#827844: git: man git: dead link

[Jonathan Nieder]

tags 827844 + upstream patch
forwarded 827844 http://mid.gmane.org/20160622024151.ga20...@google.com
quit

Andrea Stacchiotti wrote:

> In the git manual (`man git`), the documentation link:
>> http://git-htmldocs.googlecode.com/git/git.html
> is broken.

Thanks for reporting.  Let's take this upstream.

Bug#813157: git: please default fsckobjects to true in transfer, fetch, and receive

[Jonathan Nieder]

Daniel Kahn Gillmor wrote:
> On Thu 2016-02-04 00:04:19 -0500, Mike Hommey wrote:

>> Git is, in fact, safe by default. See
>> https://news.ycombinator.com/item?id=11032094
>
> Thanks for the followup, Mike.

Yep, thanks for clarifying that.  I wanted to say the same but didn't
find time to explain it clearly and was happy you saved me the trouble.

[...]
> I'm not well-versed in the git internals or the git network protocol.
> When pulling or fetching cloning or doing "git remote update" or any
> other form of transfer, does git *always* pull a pack and then do a
> connectivity check,

Yes.  Moreover, the objects being transferred aren't marked with their
SHA-1: they are just compressed data, which the client has to inflate
and hash to name them.  The file that maps from SHA-1 to object data
is the idx file, which is not transferred over the wire.

> or are there circumstances/transport options
> available to a malicious server (or a malicious network in the case of
> cleartext git:// or http:// access) that would transmit the object
> directly, or would omit the connectivity check?

I think you're conflating two different aspects of transport.

 1. whether instead of the object names being transferred over the
wire and trusted, the client computing them itself (lacking this
would mean the client could get a misnamed object)

 2. whether the client performs a connectivity check (lacking this
would mean the client could get an incomplete history, causing
some commands that try to read the repository to error out)

I assume you're mostly interested in (1).

rsync:// transport lacks (1) --- it rsyncs in the objects/
directory as-is, including idx files.

"dumb" http transport, which is very rarely used (it's for when
people have http- or https-accessible storage where they are not
able to run the "smart" git server code), fetches the idx file
from the server under a temporary filename, verifies it by locally
computing SHA-1s, and then renames it into place.  So it has the
safety described at (1).

"smart" http, git protocol, git over ssh, and file:// transport
have (1).  They don't transfer the idx file at all.

If you run "git clone" with a local directory name and without
preceding it with the string "file://", it acts similarly to rsync://
transport and just hardlinks or copies files from the objects/
directory.  So clones from a local directory lack the safety feature
(1), unless you ask git to do extra work by preceding the pathname
with file:// (or passing the parameter --no-local to git clone).

The aspect (2) generally happens unless you are doing a "shallow"
(--depth=) clone.  I haven't checked the code paths as carefully
because I think it is not what your question was about --- e.g., I
wouldn't be surprised if rsync:// protocol skips it.

Hope that helps,
Jonathan

Bug#813157: git: please default fsckobjects to true in transfer, fetch, and receive

[Jonathan Nieder]

severity 813157 important
tags 813157 + upstream
quit

Hi Daniel,

Daniel Kahn Gillmor wrote:

>  transfer.fsckobjects
>  fetch.fsckobjects
>  receive.fsckobjects

I'd love to turn the first of these on by default.  It implies the other
two.  I'll bring this up upstream.

> Many users of git rely on commit IDs for integrity proof that they're
> working from the same point in the repository held by other developers
> (i've certainly told people that they can do this) without knowing that
> one pull from a malicious repo could tamper with the contents of a
> freshly-received object without noticing.

Are you referring to the possibility of SHA-1 collisions between
corrupt objects and clean ones?  I don't think anyone has produced
such a collision yet, but that's an interesting attack vector.  I'm
also interested in figuring out how to move to a more futureproof
object naming scheme in Git (the simplest approach to this I've heard
discussed is

 * extend git protocol to allow declaring a different hash function.
   Objects are named according to that hash function.

 * to switch hash functions for an existing repository:
   - rebuild all objects using the new hash
   - create a list mapping old object names (that used the old hash
 function) to new object names (using the new hash)
   - PGP-sign that list to avoid tampering and serve it.  Clients can
 then combine trusted lists to allow commands that refer to the
 old object name to continue to work.

 * regularly switch hash functions to the current best-practice hash

 * refuse to clone repositories that use a sufficiently old hash
   function without a --force option.

).

I think fsck-ing incoming objects has other useful security properties
in addition to the SHA-1 collision related problem you mentioned.
Objects that pass fsck are less likely to trigger bugs (both in git
itself and code that calls git).  Git and callers are not *supposed*
to do bad things when faced with malformed objects but there hasn't
been enough work using fuzzing tools to rule out problems.

Thanks,
Jonathan

Bug#731634: xz-utils: new upstream version 5.2.1

[Jonathan Nieder]

Hi Sebastian,

Sebastian Andrzej Siewior wrote:
> control: -1 retitle new upstream version: 5.2.2

> On 2015-03-27 11:47:23 [-0700], Jonathan Nieder wrote:
>> perhaps in a couple of weeks).  I also don't mind if someone else
>> takes care of it for me and sends patches. ;-)
>
> I package new upstream at 
>git://git.breakpoint.cc/bigeasy/xz-utils-debian.git

Beautiful.  I'll merge this and make an upload today.

Thanks,
Jonathan

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#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#849681: 'git ls-remote' from outside repository fails with 'fatal: BUG: setup_git_env called without repository'

[Jonathan Nieder]

Package: git
Version: 1:2.11.0+next.20161222-1
Severity: important
Justification: regression
Tags: upstream patch
Forwarded: http://public-inbox.org/git/20161122004421.ga12...@google.com/

 $ cd /tmp
 $ git ls-remote https://kernel.googlesource.com/pub/scm/git/git
 fatal: BUG: setup_git_env called without repository

This problem was introduced in b1ef400e (setup_git_env: avoid blind
fall-back to ".git", 2016-10-20).  There's a patch to fix it in the
above linked thread.

Thanks,
Jonathan

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[Jonathan Nieder]

Hi,

Alberto Garcia wrote:
> On Tue, Feb 16, 2016 at 01:51:07PM +0100, Sebastian Pipping wrote:

>> PS: Still occurring with Git 2.1.4 of jessie.
>
> I'm having this problem very often even with the latest git from
> unstable (1:2.11.0-2).

Thanks for writing. Please file a separate bug with details about what
steps you use to reproduce it and the exact output.  If you can get
output with the GIT_TRACE environment variable set to 1, that's even
better.

Please also check your syslog for instances of git segfaulting and
include that information in your bug report.

This is going to be hard to track down but it's worth the effort.  It
is unlikely that what you experienced has the same cause as what
Sebastian experienced. The error message means that git crashed and
was unable to clean up after itself --- it errors out instead of
continuing because it does not know whether the other git process is
still running.

As an aside, it's possible git should get smarter about this and use
similar locking logic to vim (check that the hostname in a lockfile
matches the current hostname and then check if the process that locked
the file is still running).  But that's a separate story.  The more
urgent thing is to figure out in what scenario you have been getting
git to crash.

Thank you,
Jonathan

Bug#872277: patched version needed to avoid fatal: Out of memory, getdelim failed crash

[Jonathan Nieder]

retitle 872277 git: spurious "fatal: Out of memory, getdelim failed"
forwarded 872277 
https://public-inbox.org/git/20170809173928.h2ylvg5tp2p5i...@hopa.kiewit.dartmouth.edu/#r
# bug introduced in v2.5.0-rc0~24^2~4 (strbuf_getwholeline: use getdelim
# if it is available, 2015-04-16)
found 872277 git/1:2.5.0-1
quit

Hi,

Yaroslav Halchenko wrote:

> Subject: patched version needed to avoid fatal: Out of memory, getdelim 
> failed crash

You could say that about all bugs.  A patched version is needed to fix
the bug. :)

[...]
> For a while this issue was haunting us in various deployments, in particular 
> - on NFS mounts
> - within standalone build of git-annex
> that many git commands could crash randomly at various points with
>
> fatal: Out of memory, getdelim failed
>
> message.  Recently upstream tracked it down, and offered a perspective patch
> (see attached, cherry-picked from git upstream repository) -- it is a very
> simple patch.  I have tested it on our deployments (as applied against
> 1:2.11.0-3 in stretch, but it is applicable to sid/experimental version as
> well)
>
> original report upstream and the thread with further discussion(s) on
> possible improvements to the patch:
> https://public-inbox.org/git/20170809173928.h2ylvg5tp2p5i...@hopa.kiewit.dartmouth.edu/
>
> Please please consider adapting this patch for the official packages of git in
> Debian sid, and ideally to the version in stretch.  This would be of great 
> help
> to avoid those problems on the NFS-mounts and to generate fixed standalone
> builds of git-annex (CCing git-annex author, Joey) which many users rely upon
> on various (even non-Debian) systems.

Thanks for writing.  Can you say more about the impact?  E.g. is there a
reproduction recipe I can use to experience this on stable?  How often
do people experience this, and do they have a workaround?

The patch also appeared to still be under discussion upstream.  Someone
investigating how the standard and various platforms handle errors from
getdelim would likely be appreciated there.

One possibility in the Debian packaging would be for us to pass
HAVE_GETDELIM= in our build flags to avoid using getdelim altogether.
That way, we get correct behavior while waiting for the upstream
discussion to settle.

Thanks,
Jonathan

Bug#871950: git: Please keep packaging git archimport

[Jonathan Nieder]

Hi Sergio,

Sergio Callegari wrote:

>   Initially, I thought that the archimport was something
> that needed git to be recompiled, while now I see that it is a
> script that I can simply drop somewhere and make accessible by git
> via an environment variable.
>
> For tla, my hope is that the tla deb from debian stretch or ubuntu
> xenial, zesty or artful can remain installable for a long time in
> future distros, since its dependencies seem to be rather minimal.
[...]
> Jonathan Nieder wrote:

>> If you would use it to recover tla data from backups,
>> why not convert that tla data to git format today
>
> Because backup contain very obsolete stuff, are messed and are used
> "lazily". Only when something requires the history of some old stuff
> to be checked to understand its genesis, and there is no git repo,
> one gets the courage to seek and extract the corresponding tla
> archive from the backup and convert it to git. Which is the reason
> why I have this stuff around so many years after something way
> better than tla came around.  Unfortunately, I understand that
> laziness is not a very nice explanation.

That makes sense.  I am going to try to move git-archimport.perl to
contrib/ upstream and package it in either /usr/share/doc/git/contrib/
or /usr/share/git-core/contrib/ like other contrib scripts.

I'll include instructions in /usr/share/doc/git/README.Debian for
using it.

Thanks for the patient explanations.

Sincerely,
Jonathan

Bug#871950: git: Please keep packaging git archimport

[Jonathan Nieder]

Hi Sergio,

Sergio wrote:

> please reconsider the decision in #866059 to stop packaging git-archimport.
>
> It makes it unnecessary cumbersome to recover tla data from backups
> and deprives git from one of the components that its upstream
> maintainers consider worthwhile distributing.
>
> Even if tla is not shipped in debian, I see no reason not to provide the
> archimport helper in git.

Thanks for writing.

I would agree with you if "git archimport" were a tool that can run
independently of tla.  For an example of that kind of tool, see the
vcs-svn/ directory in git's source: it works with an svn-format dump
file without requiring any part of subversion to be available on the
local machine.

Unfortunately, "git archimport" requires tla to function, in
fundamental ways.  As the script explains:

 # The basic idea is to walk the output of tla abrowse,
 # fetch the changesets and apply them.

Without the tla command, this script does not function at all.

[...]
> I think that, at most, the helper should be patched to not depend on tla and
> provide an informative notice if tla is not in the system.

That would make the package no longer suitable for Debian.  Debian
packages declare their dependencies and their dependencies must be
present in Debian.  That said, such a package could exist in contrib.

Packaging it that way is an interesting idea.  Can you say more about
how you would use it?  E.g. if you would install arch from source, why
wouldn't you be able to install the git-archimport.perl script from
source as well?  If you would use it to recover tla data from backups,
why not convert that tla data to git format today so that you can
restore it from backups using ordinary git?

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#871823: unblock: git/1:2.14.1-1

[Jonathan Nieder]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package git.

This update fixes CVE-2017-1000117 (arbitrary code execution issues via
URLs,
https://public-inbox.org/git/xmqqh8xf482j@gitster.mtv.corp.google.com/T/#u).
The issue was covered with DSA-3934-1 in jessie and stretch. Please allow
the fix to go quickly to buster.

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#569945: hercules: high pitched whine on old laptop drives

[Jonathan Nieder]

Hi Philipp,

Philipp Kern wrote:

> This bug report from 2010 feels pretty much obsolete. Even assuming that
> Hercules might cause a lot of random I/O the machine this was reported
> for was likely too small to run Debian on s390 meaningfully in it. Plus
> we have SSDs now.

Agreed.  If I end up trying again on more modern hardware and run into
trouble then I'll ask debian-user@ + hercu...@packages.debian.org for
help.  I don't think there's any obvious change to make (even in docs)
that would warrant tracking in a bug.

Thanks for your work,
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#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#860927: Tk applications segmentation fault when ibus-daemon IME is restarted

[Jonathan Nieder]

Package: tk8.6
Version: 8.6.1-3ubuntu2
Severity: important
Tags: upstream patch
Forwarded: http://core.tcl.tk/tk/tktview?name=7d967c68a0

Hi,

Steve Paik (cc-ed) reported that gitk is crashing periodically.  This
patch, from upstream tk, should fix it.

Thoughts?

Please forgive the whitespace damage.  Copy/paste was the simplest way
to get this here.

Thanks,
Jonathan

commit 0175bc1be685a5ce4a92f7c153eb12e28c28cb1d (origin/bug_7d967c68)
Author: jan.nijtmans 
Date:   Thu Dec 15 16:07:06 2016 +

Proposed fix for [7d967c68a09e07e355358af40f36dd5dd84c7022|7d967c68]: Tk 
applications segmentation fault when ibus-daemon IME is restarted

diff --git a/generic/tkEvent.c b/generic/tkEvent.c
index 95aeda1dd..d058e7cd6 100644
--- a/generic/tkEvent.c
+++ b/generic/tkEvent.c
@@ -356,6 +356,7 @@ CreateXIC(
/* XCreateIC failed. */
return;
 }
+winPtr->ximGeneration = dispPtr->ximGeneration;
 
 /*
  * Adjust the window's event mask if the IM requires it.
@@ -1288,6 +1289,14 @@ Tk_HandleEvent(
  */
 
 #ifdef TK_USE_INPUT_METHODS
+/*
+ * If the XIC has been invalidated, it must be recreated.
+ */
+if (winPtr->dispPtr->ximGeneration != winPtr->ximGeneration) {
+   winPtr->flags &= ~TK_CHECKED_IC;
+   winPtr->inputContext = NULL;
+}
+
 if ((winPtr->dispPtr->flags & TK_DISPLAY_USE_IM)) {
if (!(winPtr->flags & (TK_CHECKED_IC|TK_ALREADY_DEAD))) {
winPtr->flags |= TK_CHECKED_IC;
@@ -1295,7 +1304,9 @@ Tk_HandleEvent(
CreateXIC(winPtr);
}
}
-   if (eventPtr->type == FocusIn && winPtr->inputContext != NULL) {
+   if ((eventPtr->type == FocusIn) &&
+   (winPtr->dispPtr->inputMethod != NULL) &&
+   (winPtr->inputContext != NULL)) {
XSetICFocus(winPtr->inputContext);
}
 }

commit 596abb7b53897447dda6044725ea94a664dae64e
Author: jan.nijtmans 
Date:   Fri Feb 10 11:38:55 2017 +

Fix [7d967c68a09e07e355358af40f36dd5dd84c7022|7d967c68a0] follow-up: Tk 
applications segmentation fault when ibus-daemon IME is restarted. Patch by 
Brad Lanam.

diff --git a/generic/tkWindow.c b/generic/tkWindow.c
index e4d696bdd..690a8412d 100644
--- a/generic/tkWindow.c
+++ b/generic/tkWindow.c
@@ -475,9 +475,6 @@ GetScreen(
dispPtr->cursorFont = None;
dispPtr->warpWindow = NULL;
dispPtr->multipleAtom = None;
-#ifdef TK_USE_INPUT_METHODS
-   dispPtr->ximGeneration = 0;
-#endif /*TK_USE_INPUT_METHODS*/
 
/*
 * By default we do want to collapse motion events in
@@ -656,6 +653,7 @@ TkAllocWindow(
 winPtr->flags = 0;
 winPtr->handlerList = NULL;
 #ifdef TK_USE_INPUT_METHODS
+winPtr->ximGeneration = 0;
 winPtr->inputContext = NULL;
 #endif /* TK_USE_INPUT_METHODS */
 winPtr->tagPtr = NULL;

Bug#860927: Tk applications segmentation fault when ibus-daemon IME is restarted

[Jonathan Nieder]

debdiff attached.  Still untested.  Sorry for the broken partial patch before.

Thanks,
Jonathan
diff -Nru tk8.6-8.6.6/debian/changelog tk8.6-8.6.6/debian/changelog
--- tk8.6-8.6.6/debian/changelog2016-07-27 20:22:45.0 -0700
+++ tk8.6-8.6.6/debian/changelog2017-04-21 17:11:11.0 -0700
@@ -1,3 +1,10 @@
+tk8.6 (8.6.6-2) local; urgency=medium
+
+  * Added patch from upstream to fix crash when X input methods are
+restarted (closes: #860927).
+
+ -- Jonathan Nieder <jrnie...@gmail.com>  Fri, 21 Apr 2017 17:00:08 -0700
+
 tk8.6 (8.6.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru tk8.6-8.6.6/debian/patches/series tk8.6-8.6.6/debian/patches/series
--- tk8.6-8.6.6/debian/patches/series   2014-08-27 09:25:53.0 -0700
+++ tk8.6-8.6.6/debian/patches/series   2017-04-21 17:10:25.0 -0700
@@ -4,3 +4,4 @@
 non-linux.diff
 manpages.diff
 xft.diff
+ximgeneration.diff
diff -Nru tk8.6-8.6.6/debian/patches/ximgeneration.diff 
tk8.6-8.6.6/debian/patches/ximgeneration.diff
--- tk8.6-8.6.6/debian/patches/ximgeneration.diff   1969-12-31 
16:00:00.0 -0800
+++ tk8.6-8.6.6/debian/patches/ximgeneration.diff   2017-04-21 
17:13:54.0 -0700
@@ -0,0 +1,186 @@
+Patch by Brad Larson to handle an input method being restarted.
+http://core.tcl.tk/tk/tktview?name=7d967c68a0
+
+--- a/generic/tkEvent.c
 b/generic/tkEvent.c
+@@ -356,6 +356,7 @@ CreateXIC(
+   /* XCreateIC failed. */
+   return;
+ }
++winPtr->ximGeneration = dispPtr->ximGeneration;
+ 
+ /*
+  * Adjust the window's event mask if the IM requires it.
+@@ -1288,6 +1289,14 @@ Tk_HandleEvent(
+  */
+ 
+ #ifdef TK_USE_INPUT_METHODS
++/*
++ * If the XIC has been invalidated, it must be recreated.
++ */
++if (winPtr->dispPtr->ximGeneration != winPtr->ximGeneration) {
++  winPtr->flags &= ~TK_CHECKED_IC;
++  winPtr->inputContext = NULL;
++}
++
+ if ((winPtr->dispPtr->flags & TK_DISPLAY_USE_IM)) {
+   if (!(winPtr->flags & (TK_CHECKED_IC|TK_ALREADY_DEAD))) {
+   winPtr->flags |= TK_CHECKED_IC;
+@@ -1295,7 +1304,9 @@ Tk_HandleEvent(
+   CreateXIC(winPtr);
+   }
+   }
+-  if (eventPtr->type == FocusIn && winPtr->inputContext != NULL) {
++  if ((eventPtr->type == FocusIn) &&
++  (winPtr->dispPtr->inputMethod != NULL) &&
++  (winPtr->inputContext != NULL)) {
+   XSetICFocus(winPtr->inputContext);
+   }
+ }
+--- a/generic/tkInt.h
 b/generic/tkInt.h
+@@ -508,6 +508,9 @@ typedef struct TkDisplay {
+ 
+ int iconDataSize; /* Size of default iconphoto image data. */
+ unsigned char *iconDataPtr;   /* Default iconphoto image data, if 
set. */
++#ifdef TK_USE_INPUT_METHODS
++int ximGeneration;  /* Used to invalidate XIC */
++#endif /* TK_USE_INPUT_METHODS */
+ } TkDisplay;
+ 
+ /*
+@@ -809,6 +812,9 @@ typedef struct TkWindow {
+ int minReqWidth;  /* Minimum requested width. */
+ int minReqHeight; /* Minimum requested height. */
+ char *geometryMaster;
++#ifdef TK_USE_INPUT_METHODS
++int ximGeneration;  /* Used to invalidate XIC */
++#endif /* TK_USE_INPUT_METHODS */
+ } TkWindow;
+ 
+ /*
+--- a/generic/tkWindow.c
 b/generic/tkWindow.c
+@@ -355,6 +355,9 @@ CreateTopLevelWindow(
+  * Set the flags specified in the call.
+  */
+ 
++#ifdef TK_USE_INPUT_METHODS
++winPtr->ximGeneration = 0;
++#endif /*TK_USE_INPUT_METHODS*/
+ winPtr->flags |= flags;
+ 
+ /*
+@@ -650,6 +653,7 @@ TkAllocWindow(
+ winPtr->flags = 0;
+ winPtr->handlerList = NULL;
+ #ifdef TK_USE_INPUT_METHODS
++winPtr->ximGeneration = 0;
+ winPtr->inputContext = NULL;
+ #endif /* TK_USE_INPUT_METHODS */
+ winPtr->tagPtr = NULL;
+@@ -1442,10 +1446,11 @@ Tk_DestroyWindow(
+ UnlinkWindow(winPtr);
+ TkEventDeadWindow(winPtr);
+ #ifdef TK_USE_INPUT_METHODS
+-if (winPtr->inputContext != NULL) {
++if (winPtr->inputContext != NULL &&
++  winPtr->ximGeneration == winPtr->dispPtr->ximGeneration) {
+   XDestroyIC(winPtr->inputContext);
+-  winPtr->inputContext = NULL;
+ }
++winPtr->inputContext = NULL;
+ #endif /* TK_USE_INPUT_METHODS */
+ if (winPtr->tagPtr != NULL) {
+   TkFreeBindingTags(winPtr);
+--- a/unix/tkUnixEvent.c
 b/unix/tkUnixEvent.c
+@@ -38,6 +38,8 @@ static void  DisplayFileProc(ClientData clientData, 
int flags);
+ static void   DisplaySetupProc(ClientData clientData, int flags);
+ static void   TransferXEventsToTcl(Display *display);
+ #ifdef TK_USE_INPUT_METHODS
++static void   InstantiateIMCallback(Display *, XPointer client_data, 
XPointer call_data);
++static void   DestroyIMCallback(XIM im, XPointer client_data, 
XPointer cal

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Jonathan Nieder]

Hi,

Ansgar Burchardt wrote:

> as a more radical change one could also ask the question where to
> maintain the maintainer information.  Currently we handle this in the
> source package via the Maintainer and Uploaders field, and via team
> memberships.
>
> This has several limitations: for teams, Uploaders will often be
> useless (you don't want to list all team members in every team-
> maintained package).  The Maintainer field only really applies to
> Debian, in derivatives someone else should be contacted.  In stable
> releases, the field can often be outdated (it records who maintained
> the package some time ago, not who currently maintains it).
>
> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

This would make me pretty happy, for what it's worth.

Thanks,
Jonathan

> For legacy purposes, the Maintainer field would then list ${source}@tra
> cker.d.o and the Uploaders field could be removed.
>
> This would also address the fact that various bits of our
> infrastructure don't know about Uploaders (like bugs.d.o only
> contacting the Maintainer).
>
> Ansgar

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> How does this look to everyone?

Seconded, with or without the tweaks dkg suggested in
https://bugs.debian.org/732445#68

Thanks,
Jonathan

> --- a/policy.xml
> +++ b/policy.xml
> @@ -2556,11 +2556,28 @@ endif
>  
>
>  This is an optional, recommended configuration file for the
> -uscan utility which defines how to
> +uscan utility which defines how to
>  automatically scan ftp or http sites for newly available updates
>  of the package.  This is used Debian QA tools to help with quality
>  control and maintenance of the distribution as a whole.
>
> +  
> +If the upstream maintainer of the software provides PGP signatures
> +for new releases, including the information required for
> +uscan to verify signatures for new upstream
> +releases is also recommended.  To do this, use the
> +pgpsigurlmangle option in
> +debian/watch to specify the location of the
> +upstream signature, and include the key or keys used to sign
> +upstream releases in the Debian source package as
> +debian/upstream/signing-key.asc.
> +  
> +  
> +For more information about uscan and these
> +options, including how to generate the file containing upstream
> +signing keys, see
> +
> uscan1.
> +  
>  
>  
>  
> 

Bug#872956: [debian-policy] warn about danger of pipe in shell snippet of makefile

[Jonathan Nieder]

Hi,

Bastien ROUCARIÈS wrote:

> set -e is not suffisant to detect error in pipe context
>
> cat nonexistant | sed s/some//g will hapilly return 0 and do not fail
>
> exec 3>&1; s=$(exec 4>&1 >&3; { cat nonexistant ; echo $? >&4; } | sed 
> s/some//g ) && exit $s
>
> this could be simplified by using make function
> PIPESAFE=exec 3>&1; s=$$(exec 4>&1 >&3; { $(1) ; echo $$? >&4; } | $(2)) && 
> exit $$s
>
> Could deserve a footnote on 4.6. Error trapping in makefiles

I don't think this belongs in policy.  Maybe devref?

By the way, if you're using bash
(https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html),
you can use "set -o pipefail" to handle this kind of case.

Thanks,
Jonathan

Bug#872895: debian-policy: Split html for policy lost

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Tue, Aug 22 2017, Guillem Jover wrote:

>> This version has lost the distinction between a single policy html and
>> the one with different files per chapter. This will break links.
>
> This was intentional.  The single page output is much more useful to
> casual readers wanting to look something up.

I don't completely understand.  The old rendering had both single page
and multi-page versions.  If I understand what you're saying, it is a
reason that the single-page version is useful, but why does that
preclude also providing the multi-page rendering?

Thanks,
Jonathan

Bug#862525: unblock: git/1:2.11.0-3

[Jonathan Nieder]

Salvatore Bonaccorso wrote:

> Please unblock package git
>
> The update fixes CVE-2017-8386, which does not have a bug in the BTS.
> The issue was covered with DSA-3848-1 in jessie, so please allow the
> fix to go to stretch to avoid a regression.

Sorry I didn't request it before, and thanks much for taking care of
it.

Sincerely,
Jonathan

Bug#862435: git: Please fix 'Recommends: rsync'

[Jonathan Nieder]

Hi Alan,

Alan Jenkins wrote:

> The `git` package recommends the `rsync` package.
> I'm sure this is wrong, because git no longer supports rsync (2016 change).
>
> https://git.kernel.org/pub/scm/git/git.git/commit/?id=0d0bac67ce3b3f2301702573f6acc100798d7edd
>
> I checked the upstream source.  There are references to rsync in 
> git-archimport.
> However, git-archimport is split out into a separate package `git-arch`.
> The `git-arch` package should surely depend on (not just recommend) rsync,
> I think that should be fixed at the same time.

Good catch.  Thank you.

Patches welcome.  I also notice that the URL mentioned in README.source
uses a self-signed certificate --- I better fix that, too.  You can get
the source at git://repo.or.cz/git/debian.git, branch debian-sid.

If you don't provide a patch, that's fine and I'll still fix it --- a
patch is just faster. :)

Thanks,
Jonathan

Bug#757760: debian-policy: please document build profiles

[Jonathan Nieder]

Hi,

Johannes Schauer wrote:

> please document the new Build-Depends syntax and fields for build
> profiles. The current write-up of the new syntax and fields for build
> profiles lives at https://wiki.debian.org/BuildProfileSpec
>
> Please note, that the new Build-Depends syntax element is called
> "restriction list" and can be used for more than build profiles. So
> documenting the new restriction list syntax and how build profiles use
> it are probably two distinct topics to cover.
>
> Please help discussing this feature so that it can become policy.
>
> A list of software which implements it is listed in the wiki link above
> and they are all part of jessie/testing already.

I'd like to restart this discussion.  My understanding is that all the
relevant infrastructure for build profiles is in place, so what's left
is to add some text to policy documenting it.

Is my understanding correct?  Any thoughts before I (or someone else)
starts to port the change-based language from
https://wiki.debian.org/BuildProfileSpec to current-state based
language in policy?

Kernel team, any notes from your experience using build profiles?

Thanks,
Jonathan

Bug#865863: dgit clone dies with "setup_git_env called without repository"

[Jonathan Nieder]

Version: 1:2.13.2
severity 865863 serious
quit

Hi Ian,

Ian Jackson wrote:

> Control: clone -1 -2
> Control: reassign -2 git
> Control: severity -2 serious
> Control: retitle -2 git config --local in non-repo now bombs out
> Control: retitle -1 dgit 3.10 and earlier not compatible with git 2.12-ish

Please cc g...@packages.debian.org the next time you do this.  Otherwise
the message doesn't show up in mail.

> Hi.  We have tripped over an accidental and incompatible change in the
> behaviour of git config --local:
> 
> $ pwd
> /home/ian
> $ dpkg -s git | grep '^Version'
> Version: 1:2.13.1-1
> $ git config --local --get-regexp '.*'
> fatal: BUG: setup_git_env called without repository
> $ echo $?
> 128

Thanks for reporting.  This is fixed by v2.13.2~26^2~1:

commit 25cd291963e4b0fae0eabe7fe02be693702d79bb
Author: Jeff King 
Date:   Fri May 12 23:29:31 2017 -0400

config: complain about --local outside of a git repo

The "--local" option instructs git-config to read or modify
the repository-level config. This doesn't make any sense if
you're not actually in a repository.

Older versions of Git would blindly try to read or write
".git/config". For reading, this would result in a quiet
failure, since there was no config to read (and thus no
matching config value). Writing would generally fail
noisily, since ".git" was unlikely to exist. But since
b1ef400ee (setup_git_env: avoid blind fall-back to ".git",
2016-10-20), we catch this in the call to git_pathdup() and
die with an assertion.

Dying is the right thing to do, but we should catch the
problem early and give a more human-friendly error message.

Note that even without --local, git-config will sometimes
default to using local repository config (e.g., when
writing). These cases are already protected by similar
checks, and covered by a test in t1308.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano 

[...]
> Please would you consider returning to the previous behaviour, for
> compatibility with other existing callers of git.

I don't think that that is the right thing to do.  The old behavior
was accidental and broken.  If you simply omit the --local option then
I think that will give you the behavior you are looking for (if I
understand what you are looking for correctly).

That said, I am happy to add a 'Breaks' to ensure smooth upgrades.
Let me know what version to add a Breaks against and I'll add it.

Also, if you have ideas for clarifying the documentation then that
would also be welcome.

Thanks, sincerely,
Jonathan

Bug#758234: Allow packages to depend on packages of lower priority

[Jonathan Nieder]

Hi,

Adam Borowski wrote:

> What about this wording?:
>
> -  Packages must not depend on packages with lower priority values (excluding
> -  build-time dependencies). In order to ensure this, the priorities of one
> -  or more packages may need to be adjusted.
> +  Packages' priorities should depend solely on functionality they directly
> +  bring to the user; their priority should not be modified merely because
> +  another package makes use of them (this can be expressed via a
> +  dependency).  In particular, this means that C-like libraries almost never
> +  will have a priority above optional.
> +
> +  On the other hand, it is allowed to _move_ such elevation to a package
> +  that depends on the actual implementation: for example, if we ever declare
> +  postgresql-client to be important, it may be elevated despite being an
> +  empty package that merely depends on postgresql-client-9.6.

Seconded.

> Obviously, this also requires changing the "extra" priority; either by
> #759260 (complete removal) or at least:
>
> -  This contains all packages that conflict with others with
> -  required, important, standard or optional priorities, or are only
> -  likely to be useful if you already know what they are or have
> -  specialized requirements (such as packages containing only
> -  detached debugging symbols).
> +  This priority is deprecated, but may be used to denote packages
> +  that are unlikely to be useful even for most users interested
> +  in their general field.

Does this mean we're losing the requirement that two "optional" packages
are not permitted to conflict with one another?

In any event, that's probably better to discuss on bug#759260.

Thanks,
Jonathan

Bug#877697: ebian-policy: discourage using all 4 digits numbers in Standards-Version

[Jonathan Nieder]

Hi,

Mattia Rizzolo wrote:

> Policy § 5.6.11, after describing the meaning of the digits in the
> policy version, reads:
>
> | Thus only the first three components of the policy version are
> | significant in the Standards-Version control field, and so either
> | these three components or all four components may be specified. [5]
>
> Now, I've only got the impressions that packages should avoid using the
> 4th digit in their Standards-Version field, as that number has no
> meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
> of comments saying that the 4th digit should be avoided

I have been including the 4th component in packages I maintain.  I
don't know if that's a vote for or against this proposal.

I include it because it makes it unambiguous which version of policy
the team referred to when preparing the package.  Micro policy
releases are not supposed to change the normative stuff but sometimes
they clarify the text of normative sections and that context can be
useful for understanding whether a later clarification was taken into
account in the packaging.

My feeling is that this is fine and that those comments on IRC/MLs are
misguided.  But I could easily be persuaded otherwise.

Thanks and hope that helps,
Jonathan

Bug#877688: libdpkg-perl: dpkg-source requires git to use 3.0 (git) format

[Jonathan Nieder]

Hi,

Nicholas Brown wrote:

> /usr/share/perl5/Dpkg/Source/Package/V3/Git.pm regularly calls out to git 
> using
> "system('git'," yet libdpkg-perl does not Require or even Recommend that
> Git is installed.
>
> This makes using dpkg-source with the 3.0 (git) format fail, for example in a
> automatically build chroot created to build a source package in this format, 
> as
> git is missing to extract the package.
> It can be worked around by explcitly installing git in the build chroot.
>
> I'd guess the that libdpkg-perl should either Require or Recommend that git is
> installed.
>
> [5s] now finalizing build dir...
> [7s] dpkg-source: warning: extracting unsigned source package
> (/usr/src/packages/test-package_1.0.0.dsc)
> [7s] dpkg-source: info: extracting test-package in /usr/src/packages/BUILD
> [7s] dpkg-source: info: cloning test-package_1.0.0.git
> [7s] Can't exec "git": No such file or directory at
> /usr/share/perl5/Dpkg/Source/Package/V3/Git.pm line 246.
> [7s] dpkg-source: error: git bundle failed with unknown exit code -1

Interesting.

Since lidpkg-perl is a library that provides lots of useful
functionality without git, I think I would prefer that this be a
Suggests, not a Recommends.  I see that libdpkg-perl already has
"Recommends: xz-utils", so I may be fighting against the tide.  (Maybe
the Debian archive not accepting "3.0 (git)" packages changes the
calculus somehow.  Not sure.)

What tool do you use to generate a build chroot?  If nothing else, we
should look into improving that to install the packages needed to
extract a source package.

I also wonder if it's possible to improve the error message when git
is not installed.

Thoughts?
Jonathan

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

[Jonathan Nieder]

Toni Mueller wrote:
> Hi Jonathan,

>> Have you read https://bugs.debian.org/613892#10?  Would you be
>> interested in working on a patch for upstream Git to do that?  We can
>> make the error message printed when manpages are missing a value set
>> at compile time (see the Makefile for existing compile-time parameters
>> like DEFAULT_EDITOR).  I'm happy to give pointers, etc. to anyone
>> wanting to work on this.
>
> I actually followed a different route and created a patch which is
> Debian-specific. Please have a look - it is not yet polished in any way,
> esp. all the translations are missing. The patch is against git in
> unstable.

Thanks!  This is an excellent starting point.  I'll be happy to tweak
this to make it configurable enough for upstream.  I'll also look into
getting the Debian-specific text translated, which will be a new
adventure for me.

May I have your sign-off?  (See Documentation/SubmittingPatches
section 5 "Certify your work" for what this means.)

Thanks,
Jonathan

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

[Jonathan Nieder]

Hi,

Toni Mueller wrote:

> I can only agree with Nelson. These days, a lot of git installations are
> non-interactive to begin with, as part of some service or so. Nobody is
> ever going to read the manual pages in such use cases. It's just a waste
> - and if the packages are being generated separately, anyway, weakening
> the dependency seems to be just a logical consequence.

Have you read https://bugs.debian.org/613892#10?  Would you be
interested in working on a patch for upstream Git to do that?  We can
make the error message printed when manpages are missing a value set
at compile time (see the Makefile for existing compile-time parameters
like DEFAULT_EDITOR).  I'm happy to give pointers, etc. to anyone
wanting to work on this.

Sincerely,
Jonathan

Bug#878189: please drop transitional package git-core

[Jonathan Nieder]

tags 878189 + pending
quit

Hi,

Holger Levsen wrote:

> Please drop obsolete transitional package git-core for Buster, as it
> has been released with Wheezy already.

Good call.  Done for the next upload.

Thanks,
Jonathan

Bug#878800: jgit-cli: IllegalStateException: Cannot set value to a final field 'org.eclipse.jgit.pgm.Daemon.enable'

[Jonathan Nieder]

Package: jgit-cli
Version: 3.7.1-4
Tags: upstream patch fixed-upstream
Severity: important
Justification: renders feature unusable

Steps to reproduce:

 git clone https://kernel.googlesource.com/pub/scm/git/git
 cd git
 make -j8
 cd t
 ./t5512-ls-remote.sh -v -i

Expected result:
 test passes

Actual result:
 java.lang.IllegalStateException: Cannot set value to a final field 
'org.eclipse.jgit.pgm.Daemon.enable'.
at org.kohsuke.args4j.spi.Setters.create(Setters.java:32)
at org.kohsuke.args4j.ClassParser.parse(ClassParser.java:34)
at org.kohsuke.args4j.CmdLineParser.(CmdLineParser.java:96)
at org.kohsuke.args4j.CmdLineParser.(CmdLineParser.java:71)
at org.eclipse.jgit.pgm.opt.CmdLineParser.(CmdLineParser.java:119)
at org.eclipse.jgit.pgm.opt.CmdLineParser.(CmdLineParser.java:102)
at org.eclipse.jgit.pgm.TextBuiltin.parseArguments(TextBuiltin.java:224)
at org.eclipse.jgit.pgm.TextBuiltin.execute(TextBuiltin.java:208)
at org.eclipse.jgit.pgm.Main.execute(Main.java:223)
at org.eclipse.jgit.pgm.Main.run(Main.java:124)
at org.eclipse.jgit.pgm.Main.main(Main.java:98)

Fixed upstream by v4.9.0.201710071750-r~33 (Remove final modifier on args4j
option or argument fields, 2017-09-04, https://git.eclipse.org/r/104304).

I suspect this was triggered by an args4j update.  Once jgit is updated,
can args4j get a Breaks to force upgrades?

Thanks,
Jonathan

Bug#682347: mark 'editor' virtual package name as obsolete

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> +++ b/policy/ch-customized-programs.rst
> @@ -93,19 +93,21 @@ page.
[...]
> -It is not required for a package to depend on ``editor`` and ``pager``,
> -nor is it required for a package to provide such virtual
> -packages. [#]_
> +Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are
> +available as fallbacks without adding an explicit package dependency, and
> +may fail if they are not present.  There are no ``editor`` or ``pager``
> +virtual packages.

One change this patch makes is to talk about /usr/bin/editor and
/usr/bin/pager files instead of editor and pager files.  Is that
intentional?

E.g. git uses "editor" as its default editor, not /usr/bin/editor.

[...]
> @@ -572,10 +574,6 @@ installed in ``/usr/share/man/man6``.
> portion is handled internally by the package system based on the os
> and cpu.
>  
> -.. [#]
> -   The Debian base system already provides an editor and a pager
> -   program.
> -

What should packages do if an editor is configured and the "editor"
command is not available?

That's an existing issue but I had never thought about it before.  It
would be nice if policy could say something about it.

Thanks,
Jonathan

Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7

[Jonathan Nieder]

Sean Whitton wrote:
> On Wed, Aug 01, 2012 at 08:07:01AM +0900, Charles Plessy wrote:

>> Otherwise, how about something along these lines: [...]
>
> Commenting on Charles' patch, I think that it would be clearer to have
> the 'should' and 'must' requirements in separate sentences.
>
> Thus I am seeking seconds for the following patch:
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index f706a13..89b355a 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -99,10 +99,11 @@ later reconfigure the package without losing the changes 
> you made.
>  Debian changelog: ``debian/changelog``
>  --
>  
> -Changes in the Debian version of the package should be briefly explained
> -in the Debian changelog file ``debian/changelog``.  [#]_ This includes
> -modifications made in the Debian package compared to the upstream one as
> -well as other changes and updates to the package.  [#]_
> +Every source package must include the Debian changelog file,
> +``debian/changelog``.  Changes in the Debian version of the package
> +should be briefly explained in this file.  [#]_ This includes
> +modifications made in the Debian package compared to the upstream one
> +as well as other changes and updates to the package.  [#]_
> 
>  The format of the ``debian/changelog`` allows the package building tools
>  to discover which version of the package is being built and find out

Seconded.  Thanks for tying up this loose end.

Sincerely,
Jonathan

Bug#873424: git handling HTTPS proxy w/ password inappropriately

[Jonathan Nieder]

(cc-ing the git mailing list and some proxy specialists there)
yang wrote[1]:

> Version: 1:2.14.1-2
[...]
> When I tried to
>
> $ HTTPS_PROXY=http://username:password@proxy:80 git clone
> https://github.com/linuxdeepin/deepin-deb-installer.git
>
> I got
>
> 正克隆到 'deepin-deb-installer'...
> fatal: unable to access
> 'https://github.com/linuxdeepin/deepin-deb-installer.git/': Proxy
> CONNECT aborted
>
> Here is the HTTP session from Wireshark:
>
> CONNECT github.com:443 HTTP/1.1
> Host: github.com:443
> User-Agent: git/2.14.1
> Proxy-Connection: Keep-Alive
>
> HTTP/1.0 407 Proxy Authentication Required
> Server: squid/2.7.STABLE9
> Date: Sun, 27 Aug 2017 14:27:38 GMT
> Content-Type: text/html
> Content-Length: 1226
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: Basic realm="Proxy"
> X-Cache: MISS from inproxy2
> X-Cache-Lookup: NONE from inproxy2:8000
> Via: 1.0 inproxy2:8000 (squid/2.7.STABLE9)
> Connection: close
>
>  "http://www.w3.org/TR/html4/strict.dtd;>   http-equiv="Content-Type" content="text/html; charset=utf-8">
> ERROR: Cache Access Denied    
> ERROR Cache Access Denied. id="content"> The following error was encountered while trying to
> retrieve the URL: github.com:443
>  Cache Access Denied.
>   Sorry, you are not currently allowed to request
> github.com:443 from this cache until you have authenticated
> yourself.  Please contact the  href="mailto:webmaster%W;>cache administrator if you have
> difficulties authenticating yourself or  href="http://inproxy2/cgi-bin/chpasswd.cgi;>change your default
> password.Generated Sun,
> 27 Aug 2017 14:27:38 GMT by inproxy2 (squid/2.7.STABLE9)CONNECT
> github.com:443 HTTP/1.1
> Host: github.com:443
> Proxy-Authorization: Basic MYPASSWORD
> User-Agent: git/2.14.1
> Proxy-Connection: Keep-Alive
>
> It seems git doesn't properly open the proxy for some reasons.
>
> Most weird is that this problem may disappear for some tries.

Thanks for reporting.  Let's take this upstream.

Can you say more about this?  How is your proxy configured (e.g. can
you provide output from "git config -l")?  Did a previous version of
Git work better?  Any more details about the proxy setup that might
help track this down?

Thanks,
Jonathan

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

Bug#872829: git: package "smart http" server configuration

[Jonathan Nieder]

Source: git
Version: 1:2.14.1-2
Severity: wishlist

The git-http-backend(1) manpage explains how to set up "smart HTTP"
server in Apache or Lighttpd but Git's maintainer scripts are not set
up for that.  This bug is a request to create a package similar to the
gitweb package that sets up a smart HTTP server.

Bug#872808: [debian-policy] nocheck DEB_BUILD_OPTIONS DEB_BUILD_PROFILES

[Jonathan Nieder]

Hi Bastien,

Bastien ROUCARIÈS wrote:

> I think the following patch is needed even if profiles are not fully 
> specified.
> Maybe an example about nodoc and help2man will also help. The nocheck should
> check both BUILD_OPTIONS and BUILD_PROFILES. It will help when implementing as
> policy profiles
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index f706a13..d3d868c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -465,7 +465,8 @@ The meaning of the following tags has been standardized:
>  
>  ``nocheck``
>  This tag says to not run any build-time test suite provided by the
> -package.
> +package. This tag could be also specified using
> +   ``DEB_BUILD_PROFILES`` variable with nocheck flag
> 
>  ``nodoc``
>  This tag says to skip any build steps that only generate package
> @@ -531,7 +532,7 @@ order to make it work for your package.
> 
>  build:
>  # ...
> -ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS $DEB_BUILD_PROFILES)))
>  # Code to run the package test suite.
>  endif

I am all for starting small in documenting build profiles (perhaps by
documenting DEB_BUILD_PROFILES before the Build-Depends syntax) but it
is possible to go too small.  This patch doesn't give context for what
DEB_BUILD_PROFILES means and it makes policy harder to understand.

In other words, if a patch
- described what a build profile is
- explained the DEB_BUILD_PROFILES environment variable
- listed which values in that variable are required to be supported

then that would already be enough for me to second it.  This patch
doesn't do that.

Do you mind if I merge this with bug#757760?

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Sean Whitton  writes:
>> On Wed, Aug 23 2017, Russ Allbery wrote:

>>> --- a/policy/ch-controlfields.rst
>>> +++ b/policy/ch-controlfields.rst
>>> @@ -962,6 +962,10 @@ repository where the Debian source package is 
>>> developed.
>>> 
>>>  More than one different VCS may be specified for the same package.
>>> 
>>> +For both fields, any URLs given should use a scheme that provides
>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>>> +if the VCS repository supports it.
>>> +
>>>  .. _s-f-Package-List:
>>> 
>>>  ``Package-List``
[...]
> Maybe I should just say:
>
> a scheme that provides confidentiality and integrity protection

Seconded.

> I think I was over-thinking it.
>
> (That said, my understanding is that you don't get any meaningful
> integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

The ideal is to use signed tags and check them.  (Or even better, to
work with git upstream to get push certs distributed properly and
check those.)

It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Jonathan Nieder wrote:
> Russ Allbery wrote:
>>> On Wed, Aug 23 2017, Russ Allbery wrote:

>>>> --- a/policy/ch-controlfields.rst
>>>> +++ b/policy/ch-controlfields.rst
>>>> @@ -962,6 +962,10 @@ repository where the Debian source package is 
>>>> developed.
>>>> 
>>>>  More than one different VCS may be specified for the same package.
>>>> 
>>>> +For both fields, any URLs given should use a scheme that provides
>>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>>>> +if the VCS repository supports it.
>>>> +
>>>>  .. _s-f-Package-List:
[...]
>> Maybe I should just say:
>>
>> a scheme that provides confidentiality and integrity protection
>
> Seconded.
>
>> I think I was over-thinking it.
>>
>> (That said, my understanding is that you don't get any meaningful
>> integrity protection for Git from using https over http.)
>
> As discussed elsewhere in this thread, it depends on how much you
> trust (a) ca-certificates, versus (b) DNS.

Correction: even if you trust DNS, you also have to trust IP
infrastructure to ensure your traffic goes to the intended destination
without a MITM modifying it.  That means that even with trustworthy
DNS (e.g. using dnssec), if your ISP is compromised then you have
neither meaningful confidentiality protection nor meaningful integrity
protection over http, beyond what your version control system provides
at the application level.

A good VPN can improve on that, depending on the destination of your
traffic.  But given all the above, I have to say, https really does
seem like a meaningful improvement.

All that said, the other points still apply:

> The ideal is to use signed tags and check them.  (Or even better, to
> work with git upstream to get push certs distributed properly and
> check those.)

These two approaches can protect integrity but do not help with
confidentiality.

> It would be nice to get something like chromium's certificate pinning
> into curl, but that's a separate topic.

Something like this (or a revamping of ca-certificates) is needed for
confidentiality in the presence of a MITM.

And I agree with you that policy doesn't need to get into these details.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder <jrnie...@gmail.com> writes:
>> Russ Allbery wrote:

>>> (That said, my understanding is that you don't get any meaningful
>>> integrity protection for Git from using https over http.)
>>
>> As discussed elsewhere in this thread, it depends on how much you
>> trust (a) ca-certificates, versus (b) DNS.
>
> FWIW, we're talking about integrity protection at different levels here,
> which has made this a bit confusing.  You're talking about authentication
> of the remote server so that you don't get valid commits (in the sense
> that they fit into the Git hash tree) that aren't present in the real
> remote server.  I was talking about integrity protection at the wire
> protocol level (detection of bit flips in transit, that sort of thing),
> which Git will generally do for you regardless of transport by checking
> the hashes of objects, although I'm not sure if it does a full integrity
> check on all remote packs.

I replied privately in more detail (since this is mostly off-topic for
policy), but it's probably useful to clarify a few things publicly,
too.

Indeed, you're right that Git's application-level protocol protects
against cosmic rays and single-bit flips for all objects transfered.
In protocols like git:// and the CGI-based http:// support, this is
guaranteed by the way the protocol works.  If there are any holes in
this protection (e.g. the support for non-dynamic protocols like
ftp:// and static http:// used to have such a bug) then we consider
that a serious bug and would want to know about it so it can be fixed.
Feel free to contact me at g...@packages.debian.org for more details.

By integrity I was referring to something different: protection
against *malicious* manipulation of the response, by a MITM or other
hostile actor.  Git does not guarantee this unless one of the
following holds:

 A. You have learned the name of the commit or tag you are interested
in in a reliable way out-of-band.  That is, if you check out the
revision to be built by SHA-1 instead of by ref name, then Git
intends to guarantee that what you check out is reliably
determined by that SHA-1.

 B. You use signed tags or push certs to verify that you are checking
out what you intend.  E.g. you can do this by using "git tag -v"
to verify that the code you are checking out was (1) signed by
someone you trust and (2) actually refers to the version you want.
Make sure to pay attention to the output to avoid "replay" attacks
(i.e. trying to pass off an old vulnerable tagged version of a
package for a modern fixed version).  Or

 C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

If people are expecting Git to guarantee that the code you fetch is
what you intended to fetch without (A), (B), or (C), then we are doing
users a dangerous misservice.  I am concerned about where that
expectation comes from and want to do what I can to improve
documentation to avoid that.  Feel free to contact me at
g...@packages.debian.org to help.

> Protocol-level integrity protection doesn't help if you negotiate that
> protocol with the wrong peer, obviously, and preventing that is rather
> outside the scope of the text we're fiddling with here.

I disagree: one of the main goals of HTTPS and the basis for its
support for confidentiality and integrity is avoiding communicating
with the wrong peer.

> But this is all picking nits -- HTTPS provides both confidentiality and
> integrity protection as wire protocol features, so we can just say that
> the protocol should provide those things, regardless of the somewhat
> pedantic point about whether that integrity protection is meaningful for
> Git.

Agreed.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder <jrnie...@gmail.com> writes:

>>  C. You have transport-level integrity protection, e.g. by using a
>> protocol like https:// or ssh:// with proper PKI.
>
> I think it's worth being honest with ourselves here that the proper PKI
> part is not really happening with the Vcs-Git field (or Vcs-Browser for
> that matter) in normal usage in the context of Debian packages and random
> remote hosts.
>
> The bar to the attacker is not zero when https with normal public CAs is
> in use, but it's not very high.

There's no point in continuing to discuss this here.  I'll respond
privately in case you want to pursue it.

> I'm fine with including integrity protection in the protocol description
> anyway, but hopefully no one will think that it implies that https is
> providing strong authentication of the Git server here.  There's non-zero
> authentication, but it's pretty weak.

Without authentication, you don't have confidentiality either.  That's
how this comes up in the policy language: I don't understand why https
would be better or worse at providing confidentiality versus integrity.

One kind of authentication is that HTTPS protocol gives you some
assurance that the peer who first responded to is the same as the peer
for the rest of the connection.  That's enough to deter an unreliable
MITM or a passive MITM.

Jonathan

Bug#878905: debian-policy: Document installability recommendations for dependency alternatives

[Jonathan Nieder]

Hi,

Julian Andres Klode wrote:

> APT's solver is greedy and sometimes has a hard time to recover from paths 
> that
> don't work out in the end. We see this with opencv failing to build on 
> !linux-any
> because:
>
> (1) dconf-service depends default-dbus-session-bus | dbus-session-bus
> (2) default-dbus-session-bus is provided by an Architecture: all package, but
> depends on systemd
>
> APT refuses to install that.
>
> I think it makes sense to amend section 7.1 with the following information:

I agree with this goal.

> Packages on the left hand side of a pipe symbol should either be 
> installable
> or should not exist in the given situation (for example, because it is 
> linux-only
> and the package only exists on non-Linux platform).
>
> This would help reduce hard to solve situations for greedy algorithms.

I'm wondering how a packager would go about fulfilling this recommendation.
Should they audit their dependencies (and dependencies' dependencies, etc) for
installability?  Is there a reliable process they can follow for this?

This is made especially difficult because since policy 4.0.1.0 we are not able
to rely on 'priority: optional' packages being installable any more.

Without such advice, I don't think this makes sense to add as a normative change
to policy (or in other words a policy "should").  An informative note would
still be useful, though.

Thanks,
Jonathan

Bug#459427: changelog vs. NEWS handling

[Jonathan Nieder]

Hi,

gregor herrmann wrote:

> From the Perl world, looking at roughly ~3400 packages I have locally
> cloned:
>
> 28 have a NEWS file (most of them with a Gnome/GTK background), 1
> News, 1 news.
>
> 3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other
> variations like Change{s,Log}.{pod,ini,1,txt}); and those files are the
> manually created user-facing summaries of relevant changes of the
> release (in almost all cases).
>
> For 10 packages we have `dh_installchangelogs NEWS' in debian/rules.
>
>
> I'm all for installing NEWS if it's a summary in the GNU style; but
> assuming that ChangeLog etc. are detailed/auto-generated/boring
> doesn't reflect reality in the Perl universe.

Yes.

Some more questions from a policy pov:

 1. What to do with packages that make multiple per-release release
note files?  Should the packager concatenate them or is shipping
them as multiple files ok?  (E.g. see /usr/share/doc/git/RelNotes.)

 2. What about packages that prune old release notes from their source
tarball?  (E.g. Samba's WHATSNEW.TXT doesn't go back very far,
sometimes not even as far as the previous stable Debian release.)

Should packagers copy back in such archived release notes to make
the changelog usable to users?

 3. Any advice for packagers to make complying with the GPL section 5+6
straightforward?

  a) The work must carry prominent notices stating that you modified
  it, and giving a relevant date.

What about when Debian's upstream is downstream from someone else?

Thanks,
Jonathan

Bug#883179: dash: compiles in signals from build architecture when cross-compiled

[Jonathan Nieder]

Control: tags 883179 + upstream

Hi,

James Cowgill wrote:

> When cross-compiled, dash compiles in a list of signal names used for
> various purposes (eg kill -NAME). Unfortunately the signal names are
> generated by using the *build* compiler instead of the *host* compiler
> so the signals are incorrect when dash is actually run on the host machine.

Interesting!  I assume you're referring to src/mksignames.c.

I think this should be doable using preprocessor alone instead of
generated code.  Failing that, I think we can do something in
configure e.g. using the #warning trick.  Will look into it.

> I notice the signal generation code has been copied from bash. Newer
> versions of bash have a fix for this which initialized the list of
> signals at runtime when cross-compiled. Maybe you could copy the fix
> from bash?

I think that would go against dash's goal of being small and simple.
It might be possible to simplify the way the signal name table is used
to avoid the need for code generation altogether, though, which would
be even nicer.

Thanks,
Jonathan

Bug#459427: changelog vs. NEWS handling

[Jonathan Nieder]

Josh Triplett wrote:
> On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert  wrote:

>> The fact that some upstream do not bother to ship useful changelog does
>> not mean that all changelog are useless, and by removing them we
>> discourage upstream of producing useful changelog.
>
> I sincerely hope so.  Convincing upstreams to "git rm ChangeLog" becomes
> much easier the more widespread existing practice we can point to.
> Having a ChangeLog file in version control is actively detrimental.

I agree with you about GNU-style changelogs.  But I don't think I've
seen those much outside of GNU packages.

How do you feel about generated changelogs in release tarballs that
are generated by tools like "git log"?

> I would go so far as to say that I hope we one day stop shipping
> a non-generated debian/changelog in source packages, because it incurs
> all the same pain.

I've been trying to make debian/changelog in packages I work on
user-focused, and no one has complained yet.

I also use NEWS.Debian for notes about incompatibilities that will
affect sysadmins upgrading.

Thanks,
Jonathan

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu, Nov 30 2017, Simon McVittie wrote:

>> Other than that, seconded. I'm not sure whether this is necessarily
>> how the autobuilders *should* work, but there's value in documenting
>> how the autobuilders *do* work.
>
> Thank you for reviewing this bug.
>
> Since Sean's patch doesn't require anything of package maintainers, it's
> what we call "informative", and we don't need formal seconds.  So I'm
> going to go ahead and apply the patch.

Thanks.  As a followup, I'm a little confused at what I think is a
wording issue:

> +To avoid
> +   inconsistency between repeated builds of a package, the
> +   autobuilders will default to selecting the first alternative, after
> +   reducing any architecture-specific restrictions for the build
> +   architecture in question.  While this may limit the usefulness of
> +   alternatives in a single release, they can still be used to provide
> +   flexibility in building the same package across multiple
> +   distributions or releases, where a particular dependency is met by
> +   differently named packages.

This means if I write

Build-Depends: a | b

then it will always use 'a', regardless of the release, right?

What is the comment about providing flexibility talking about here?
Is it saying that I can use 'a | b' to provide flexibility for people
building outside an autobuilder environment?

To help backporters, I have used this functionality before and
backporters have uploaded the package as-is to a backports dist that
didn't include 'a'.  The package built against 'b'.  Was this an
autobuilder bug?

Thanks,
Jonathan

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Jonathan Nieder]

Bill Allombert wrote:
> On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote:
>> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
>>> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:

 I am seeking seconds for the following patch to close this bug, which I
 think is uncontroversial at this point.

> @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>
> -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
>
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``
>>>
>>> Seconded.
>>
>> Before we make it a must, is there a lintian test for it ?
>> How may packages need to be fixed ?
>
> Given Russ answer about the lintian test and result, I second this
> proposal.

Seconded as well. 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#883950: debian-policy: allow specifying common licenses with only the identifier

[Jonathan Nieder]

Hi Markus,

Markus Koschany wrote:
> Am 16.12.2017 um 15:55 schrieb Sean Whitton:
>> On Wed, Dec 13 2017, Markus Koschany wrote:

>>> If the Policy editors cannot make a decision with regards to
>>> debian/copyright then we should ask the DPL to seek legal advice and
>>> when necessary start a GR for reasons of legitimacy.
>>
>> If we think this issue is important enough to spend money on that.  I am
>> not convinced it is.
>
> Then we need a GR. Simply claiming that something violates the law
> without proof cannot be the right way for a large project like Debian.
> This is a very important topic because writing debian/copyright is not
> optional in Debian. I simply believe that most people appreciate doing
> something meaningful in their free time.

You are of course free to initiate a GR at any time.

I have no opinion about this particular proposal (allowing specifying
common licenses with only the identifier).  But I am worried at how
black and white you are describing the world to be.

Debian has long had a practice of being extra careful to respect the
wishes of free software authors as expressed in the licenses they
choose.  This goes beyond the minimum legal requirements of license
compliance.  It is not because the project is afraid of being sued but
because at least some in the project consider it to be the right thing
to do.

Here Sean pointed out that just a license name with too little
accompanying text does not appear to be particularly clear to end
users.  That means end users may not know what their rights are, so it
seems worth thinking about.  Fortunately DEP-5 copyright files contain

 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

so perhaps some information in the copyright-format would be good
enough to help those end users.  Perhaps not.  But I am puzzled that
you seem to think there is only one possible right answer and that it
should be obvious to everybody.

The way you describe the experience of writing a debian/copyright file
is foreign to my own experience.  It sounds like making the process of
generating /usr/share/doc/{package}/copyright using *automated tools*
in a smoother way will be a good avenue for addressing the developer
experience issues you are mentioning.  Then you'd be in a better
position to come up with what the appropriate content of that file
should be to serve end users.

Thanks and hope that helps,
Jonathan

Bug#884224: ebian-policy: please add CC-BY-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: CC-BY-3.0
> Source: https://creativecommons.org/licenses/by/3.0/
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_unported_.28CC-BY.29_v3.0

Seconded (for CC-SA-3.0 unported).  Seconded only for that license; I
don't mean this to imply that we have consensus to include the texts
of all Creative Commons licenses in base-files!

Thanks,
Jonathan

Bug#884225: debian-policy: please add CC-BY-4.0 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: CC-BY-4.0
> Source: https://creativecommons.org/licenses/by/4.0/
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_unported_.28CC-BY.29_v4.0

Seconded (for CC-BY-SA 4.0 unported, not other Creative Commons
licenses).

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:
> Am 13.12.2017 um 19:10 schrieb Jonathan Nieder:
>> Markus Koschany wrote:

>>> License: AGPL-3.0
>>> Source: https://www.gnu.org/licenses/agpl-3.0.de.html
>>> Example packages:
>>> https://wiki.debian.org/DFSGLicenses#GNU_AFFERO_GENERAL_PUBLIC_LICENSE_.28AGPL-3.29
>>
>> What commonly installed packages use this license?  Is ghostscript the
>> only one, or are there others?
>
> Actually my idea was not to distinguish between "commonly installed"
> packages and simply "used in packages" anymore. Maintainers will roughly
> save the same amount of time by not copying this license.

This seems odd to me.  Wouldn't copying upstream's LICENSE file
verbatim be the action that involves the least amount of time?  I have
always assumed common-licenses is about disk space and transfer time
savings, not maintainer time savings.

> Apart from my example packages you can find this license also in the
> following packages: Just go to codesearch.debian.net and use
>
>  AGPL path:debian/copyright
>
> as your search query. Notable packages are pulseaudio, debian-goodies,
> gnutls28, pelican, and many more. I expect that more network or web
> applications will use this license in the future.

Thanks.  The example in pulseaudio is the bug fixed upstream that I
mentioned before (src/utils/qpaeq had a different license from the
rest of the package; they've fixed it now).

I remain neutral on this change.  I'm not against it, but not
enthusiastic about it, and look forward to hearing others' thoughts on
it before seconding.

Sincerely,
Jonathan

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: OFL-1.1
> Source: https://opensource.org/licenses/OFL-1.1
> Example packages:
> https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

Seconded.

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884227: debian-policy: please add zlib to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> License: zlib
> Source: https://opensource.org/licenses/Zlib
> Example packages:
> https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29

Hm.  The license says

  3. This notice may not be removed or altered from any source distribution.

And part of 'This notice' is a copyright line that varies from package
to package.  Since the license text is very short, it seems simplest
for packages to keep reproducing the license text --- it's not too
painful disk space-wise and it is much clearer license-wise.

So I don't believe it belongs in common-licenses.

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> I would like to argue that disk space is no longer an issue in 2017 and
> people with special needs (embedded systems) will most likely remove
> /usr/share/common-licenses anyway.

I agree: space on installation media and network transfer time are more
important than disk space these days.


>Thus the more DFSG-licenses we
> install into /usr/share/common-licenses the more time can be saved for
> more important issues than quoting licenses.

I'm confused.  Can you explain your workflow a little more?

I wouldn't expect using upstream's LICENSE file to take significantly
more time than replacing it with a pointer to common-licenses.  I'd
actually expect it to take more time.

If all we care about is maintainer time spent, then we should
eliminate common-licenses.

Puzzled,
Jonathan

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: AGPL-3.0
> Source: https://www.gnu.org/licenses/agpl-3.0.de.html
> Example packages:
> https://wiki.debian.org/DFSGLicenses#GNU_AFFERO_GENERAL_PUBLIC_LICENSE_.28AGPL-3.29

What commonly installed packages use this license?  Is ghostscript the
only one, or are there others?

I'm neutral on this change.  ghostscript is installed on most
installations and uses this license and unfortunately pieces of it get
incorporated into other packages like poppler-data.  If it weren't for
ghostscript then I would be against this change.

(src/utils/qpaeq in pulseaudio is about to become a non-example, since
its licensing was simplified to LGPL upstream.)

Thanks and hope that helps,
Jonathan

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: EPL-1.0
> Source: https://www.eclipse.org/legal/epl-v10.html
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Eclipse_Public_License_-_1.0

I'm ambivalent on this one.  No strong objection but it seems likely
that small installations could benefit from not having to have this
license text.

I'm wondering if we should split some common licenses out of
base-files to avoid this kind of dilemma.  E.g. if there were some
base-files-eclipse package that provided the EPL-1.0 and we allowed
packages to depend on base-files-eclipse to avoid having to ship the
EPL in their own copyright file, then this dilemma wouldn't exist.
The hypothetical base-files-eclipse package might need to be marked in
some appropriate way to simplify following the spirit of licenses
(just like people know to treat base-files specially and distribute
the license texts from it alongside Debian source packages they
distribute).

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Hi again,

Markus Koschany wrote:

> Let me try to explain it this way: Take src:ufoai-data or src:netbeans
> for example. Both packages ship approximately a dozen different
> licenses. I can't simply copy the upstream license because I have
> to format it to make it copyright format 1.0 compliant.

Aha, that explains it.

Policy does not require using copyright format 1.0, but many packagers
choose to use it.  It sounds like we need better tools to help them.

But with a goal in mind of saving maintainer time, shouldn't we
discourage using copyright format 1.0 when the upstream LICENSE file
is clear?  (I personally think the maintainer time involved is very
little relative to the work of either manually or using tools
verifying that the license is correctly documented --- e.g. comparing
source file headers to the LICENSE file.  I'm just going along with
the saving time argument.  I suspect the best way forward will be to
improve tools.)

Thanks,
Jonathan

Bug#882351: 'no such function in map' from /etc/Muttrc.d/notmuch.rc

[Jonathan Nieder]

Package: mutt
Version: 1.9.1-1

Today I updated mutt to 1.9.1-1 (thanks!).  I expect this to be more
familiar to me since I used the mutt package instead of mutt-patched
in the past.

Now when I start mutt I am getting the following messages:

 $ mutt
 Press any key to continue...ch.rc, line 6: change-vfolder: no such function in 
map
 Error in /etc/Muttrc.d/notmuch.rc, line 9: entire-thread: no such function in 
map
 Error in /etc/Muttrc.d/notmuch.rc, line 12: modify-labels: no such function in 
map
 Error in /etc/Muttrc.d/notmuch.rc, line 15: vfolder-from-query: no such 
function in map
 Error in /usr/lib/mutt/source-muttrc.d|, line 5: source: errors in 
/etc/Muttrc.d/notmuch.rc
 Error in /etc/Muttrc, line 141: source: errors in 
/usr/lib/mutt/source-muttrc.d|
 source: errors in /etc/Muttrc

For reference, here are the relevant files. I don't believe I ever
edited them.

I don't use notmuch.rc, so I think I am going to remove that conffile
to work around this, but thought you'd like to know.

Thanks,
Jonathan

$ ls -l /etc/Muttrc /etc/Muttrc.d/
-rw-r--r-- 1 root root 4872 Nov 20 13:38 /etc/Muttrc

/etc/Muttrc.d/:
total 24
-rw-r--r-- 1 root root  410 Dec  9  2014 charset.rc
-rw-r--r-- 1 root root  612 Dec  9  2014 colors.rc
-rw-r--r-- 1 root root  427 Dec  9  2014 compressed-folders.rc
-rw-r--r-- 1 root root 3915 Nov 20 13:38 gpg.rc
-rw-r--r-- 1 root root  486 Jun 25 02:00 notmuch.rc
-rw-r--r-- 1 root root 3832 Jun 25 02:00 smime.rc
$ cat /etc/Muttrc.d/notmuch.rc 
# --
# FUNCTIONS - shown with an example mapping
# --
 
# open a different virtual folder
bind index,pager X change-vfolder
 
# read entire thread of the current message
bind index,pager + entire-thread
 
# modify (notmuch) tags
bind index,pager \` modify-labels
 
# generate virtual folder from query
bind index,pager \eX vfolder-from-query
$ sha256sum /etc/Muttrc
c9a79cb6e0136acf608bdf5c41e12f5e8b353d77c3c9dde0fe6cdce1074b  /etc/Muttrc
$ dpkg-query -S /etc/Muttrc.d/notmuch.rc 
mutt: /etc/Muttrc.d/notmuch.rc
$ dpkg-deb --fsys-tarfile mutt_1.9.1-1_amd64.deb | tar -tf - ./etc
./etc/
./etc/Muttrc
./etc/Muttrc.d/
./etc/Muttrc.d/charset.rc
./etc/Muttrc.d/colors.rc
./etc/Muttrc.d/compressed-folders.rc
./etc/Muttrc.d/gpg.rc
./etc/Muttrc.d/notmuch.rc
./etc/Muttrc.d/smime.rc
$ sudo dpkg -i --force-confask mutt_1.9.1-1_amd64.deb 
(Reading database ... 338154 files and directories currently installed.)
Preparing to unpack mutt_1.9.1-1_amd64.deb ...
Unpacking mutt (1.9.1-1) over (1.9.1-1) ...
Setting up mutt (1.9.1-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for gnome-menus (3.13.3-9) ...
Processing triggers for desktop-file-utils (0.23-2) ...
Processing triggers for doc-base (0.10.7) ...
Processing 1 changed doc-base file...
Processing triggers for man-db (2.7.6.1-2) ...

Bug#882389: Error in /etc/Muttrc.d/notmuch.rc

[Jonathan Nieder]

forcemerge 882320 882389
quit

Hi,

積丹尼 Dan Jacobson wrote:

> Package: mutt
> Version: 1.9.1-1
>
> $ mutt
> Error in /etc/Muttrc.d/notmuch.rc, line 6: change-vfolder: no such function 
> in map
> Error in /etc/Muttrc.d/notmuch.rc, line 9: entire-thread: no such function in 
> map
> Error in /etc/Muttrc.d/notmuch.rc, line 12: modify-labels: no such function 
> in map
> Error in /etc/Muttrc.d/notmuch.rc, line 15: vfolder-from-query: no such 
> function in map
> Error in /usr/lib/mutt/source-muttrc.d|, line 5: source: errors in 
> /etc/Muttrc.d/notmuch.rc
> Error in /etc/Muttrc, line 141: source: errors in 
> /usr/lib/mutt/source-muttrc.d|
> source: errors in /etc/Muttrc

This should be fixed in 1.9.1-2.

Thanks,
Jonathan

Bug#880992: debian-policy should not recommend running editor using absolute path

[Jonathan Nieder]

Package: debian-policy
Version: 4.1.0.0

Policy 11.4 sayeth:

11.4. Editors and pagers

Some programs have the ability to launch an editor or pager
program to edit or display a text document. Since there are
lots of different editors and pagers available in the Debian
distribution, the system administrator and each user should
have the possibility to choose their preferred editor and pager.

In addition, every program should choose a good default
editor/pager if none is selected by the user or system
administrator.

Thus, every program that launches an editor or pager must use
the EDITOR or PAGER environment variable to determine the
editor or pager the user wishes to use. If these variables are
not set, the programs /usr/bin/editor and /usr/bin/pager
should be used, respectively.

If read strictly, this says that I must use "/usr/bin/editor" instead
of invoking "editor" from the $PATH.  (I'm not sure I agree with that
interpretation, but it came up in https://bugs.debian.org/682347.)
Running "editor" from the $PATH instead of using that full path should
be perfectly acceptable and IMHO is a better behavior, since it allows
the user to put a custom editor in /usr/local/bin or $HOME/bin.

Could this say something like

not set, the commands "editor" and "pager" should be used,
respectively. These commands can be invoked explicitly (e.g.
as /usr/bin/editor), or through a $PATH search (e.g. as
editor).

?

Bug#880992: debian-policy should not recommend running editor using absolute path

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Nov 06 2017, Jonathan Nieder wrote:

>>  Thus, every program that launches an editor or pager must use
>>  the EDITOR or PAGER environment variable to determine the editor
>>  or pager the user wishes to use. If these variables are not set,
>>  the programs /usr/bin/editor and /usr/bin/pager should be used,
>>  respectively.
>>
>> If read strictly, this says that I must use "/usr/bin/editor" instead
>> of invoking "editor" from the $PATH.  (I'm not sure I agree with that
>> interpretation, but it came up in https://bugs.debian.org/682347.)
>> Running "editor" from the $PATH instead of using that full path should
>> be perfectly acceptable and IMHO is a better behavior, since it allows
>> the user to put a custom editor in /usr/local/bin or $HOME/bin.
>
> ISTM that the intention is for the user to set EDITOR and PAGER to
> select an editor or pager, rather than putting things called 'editor'
> and 'pager' into PATH.

I understand and agree, but that doesn't mean that packages should
invoke editor using an absolute path.

Policy describes package behavior, not user behavior.

Further, a sysadmin on a shared machine doesn't have a way to set
EDITOR for all users, but they can install an editor command to
/usr/local/bin/.  I've seen sysadmins at a university do something
similar for e.g. a custom build of gcc.  It would be more robust for
the sysadmin to use alternatives instead, but I'm just saying it's
more polite for a package to respect what the user was trying to do.

>This seems sensible because 'editor' and 'pager'
> are fairly generic terms and a user might have things in ~/bin/editor or
> ~/bin/pager that don't edit or page, respectively.

Really?  That would be a reason for the 'editor' and 'pager' commands
to be named something else.  But on the contrary, I find 'editor' and
'pager' to be pretty clear names for what they do.

Is there additional information or context I can provide to change
your mind?  Note that the change I am proposing is to allow packages
to invoke 'editor' from $PATH, not to require them to do so.  There
are existing packages (e.g., Git) that already do this.  This is
similar to upstream packages invoking "less" or "more" from the $PATH
instead of relying on it to be at a particular path.

Jonathan

Bug#898226: git: please transition from asciidoc to asciidoctor

[Jonathan Nieder]

tags 898226 + upstream
# asciidoc is not gone yet :)
severity 898226 wishlist
quit

Hi,

Nicholas D Steeves wrote:

> https://lists.debian.org/debian-backports/2018/05/msg00063.html
>
> src:git/1:2.17.0-1 Build-Depends on asciidoc (>= 8.6.10); however,
> in asciidoc/NEWS.Debian the following is advised:
>
>   asciidoc (8.6.10-1) unstable; urgency=low
>
> The version 8.6.10 has been marked as FINAL RELEASE by the upstream 
> maintainers.
> They advise their users to move to asciidoctor.
> See: https://github.com/asciidoc/asciidoc/releases

Thanks for writing.  If possible, I prefer to move to sphinx instead.
I'll start a conversation upstream.

[...]
> Consequently, to unblock an update of the existing stretch-backport of
> src:git it is preferable that src:git in sid transition to asciidoctor
> at this time, rather than creating a NEW stretch-backport of
> asciidoc/8.6.10-1.

Backports should not require this --- git has built fine with older
versions of asciidoc before.  I'm happy to work with anyone interested
in helping with the backport at g...@packages.debian.org.

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#901805: want option to git-rebase

[Jonathan Nieder]

severity 901805 wishlist
tags 901805 + upstream
retitle 901805 git rebase: allow calling scripts to customize reflog action
forwarded 901805 
https://public-inbox.org/git/20180619010655.ga173...@aiede.svl.corp.google.com/
quit

Hi,

Ian Jackson wrote:

> git-rebase leaves entries like this in the reflog:
>
>   c15f4d5391 HEAD@{33}: rebase: checkout 
> c15f4d5391ff07a718431aca68a73e672fe8870e
>
> It would be nice if there were an option to control this message.
> Particularly, when another tool invokes git-rebase, the other tool may
> specify an interesting --onto, and there is no way to record any
> information about that --onto commit.

Thanks for reporting.  Let's take this upstream.

Sincerely,
Jonathan

Bug#900377: git: Debian git package can now include git-p4 Perforce proxy

[Jonathan Nieder]

forcemerge 715534 900377
quit

Hi,

Luke Diamand wrote:

> Originally the Debian git package included this tool, but it was removed
> in 2014 because - at the time - the Perforce command-line tool was non-free:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10

To be clear, what the Debian git package included before was a script
of a few lines that said that git was built without support for
Python.

I don't believe the Debian git package ever included git-p4.

> However, later that year, Perforce actually open-sourced a good deal of
> their software, including the p4 command-line client which git-p4 relies
> on:
>
> https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools
>
> The source can currently be found here:
>
> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/
>
> and the license (as of the 2018-1 branch) is here:
>
> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE
>
> That appears to be a standard BSD license (2-part).

Cool!  Is there a bug open to package p4 in Debian?

> I found that I could build the code on a recent Debian install with a
> few small hacks (I think it assumes an older version of openssl than
> that shipped with current Debian).
>
> Given this, I think git could once again include the git-p4 package.
> That would be very useful for people in organizations where Perforce is
> in use for version control, but who would prefer to use the standard git
> frontend (and for whatever reason can't use Perforce's own git-fusion
> tool).

Thanks for the update.  Given this context, it certainly seems worth
adding git-p4 to contrib for now, and to the main Debian repository
once the perforce client is in Debian.  It's too bad the server isn't
also open source, but as long as the protocol spec is open and
implementable, that's not a reason not to include the client in
Debian.

I'll look into it this week.

Thanks for your kind and patient help,
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#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]

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]

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

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#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#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#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#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed, Apr 11 2018, Russ Allbery wrote:

>> I'm pretty reluctant to specify this sort of optional target that
>> works differently in every package that uses it back in Policy because
>> it's really not standardized, nor do I think it's possible to
>> standardize.  If we really want to write something down about the
>> target, maybe the Developer's Reference would be a better spot?  There
>> were a whole host of issues with having this in Policy that were
>> resolved by moving it outside the scope of Policy, such as how to
>> document dependencies required for running the get-orig-source target.
>
> The Developer's Reference seems like a more appropriate place for a
> convention that it is not possible to specify precisely.

I'm a bit confused: wasn't it already specified pretty precisely?

I would be in favor of adding the target back, with a description
along the lines of "If you provide a get-orig-source target, it should
satisfy .  If you provide neither a get-orig-source
target nor a debian/watch file and you do not use an archive from
upstream as-is, please include clear instructions in README.source to
allow a human to produce an upstream tarball."

Context: I have run into a few packages that used the +dfsg convention
without documenting what they removed from the tarball and I was not
able to locally update them. :(

Thanks,
Jonathan

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Jul 02 2018, Jonathan Nieder wrote:

>> I'm a bit confused: wasn't it already specified pretty precisely?
>
> Please take a look through the bug's discussion.  It's explained why the
> wording was not thought to be good enough.

Thanks.  This looks like a classic case of letting the perfect be the
enemy of the good (or perhaps, of not understanding the use case for
which the existing practice was good enough).  Some quotes from the
bug:

| According to codesearch.d.n, get-orig-source is implemented by less than
| 3000 source packages. This is not very low, but neither a high adoption
| rate. It certainly makes using get-orig-source somewhat useless on a
| distribution-scale.

Certainly it's even more useful to have a debian/watch file, but this
doesn't make it clear to me what I'm supposed to do with those 3,000
source packages now.

|  * The requirement that get-orig-source may be invoked from any
|directory is difficult to fulfil and often times not implemented. A

This hasn't been an obstacle to my use.  I can even try multiple
directories.  What's helpful for me is that it works from *somewhere*.

|  * It is not clear whether the most recent upstream version or the
|currently packaged version should be downloaded.

Likewise, either works fine for my use.

|  * It is not clear where required tools should be declared.

As long as the command prints an error about the required tool, I can
install it.

| We're just reducing
| the documented interfaces of packages a bit based on current trends,
| which is useful for newcomers to Debian.

What is a newcomer supposed to do now when they encounter a package
that does not provide an explanation of how to generate the upstream
tarball?

Jonathan

Bug#688251: Built-Using description too aggressive

[Jonathan Nieder]

Hi,

Sean Whitton wrote:

> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst @@ -598,17 +598,26 @@ earlier for
> binary packages) in order to invoke the targets in
>  Additional source packages used to build the binary - ``Built-Using``
>  -
> 
> -Some binary packages incorporate parts of other packages when built but
> -do not have to depend on those packages. Examples include linking with
> -static libraries or incorporating source code from another package
> -during the build. In this case, the source packages of those other
> -packages are a required part of the complete source (the binary package
> -is not reproducible without them).
> +Some binary packages incorporate parts of other packages when built
> +but do not have to depend on those packages. Examples include linking
> +with static libraries or incorporating source code from another
> +package during the build. In this case, the source packages of those
> +other packages are part of the complete source (the binary package is
> +not reproducible without them).

Is this part just a line-wrapping change?  If so, feel free to check it
in directly to make the normative diff easier to review.

> -A ``Built-Using`` field must list the corresponding source package for
> -any such binary package incorporated during the build, [#]_ including
> -an "exactly equal" ("=") version relation on the version that was used
> -to build that binary package.  [#]_
> +When the license of either the incorporated parts or the incorporating
> +binary package requires that the full source code of the incorporating
> +binary package be made available, the ``Built-Using`` field must list
> +the corresponding source package for any affected binary package
> +incorporated during the build, [#]_ including an "exactly equal" ("=")
> +version relation on the version that was used to build that version of
> +the incorporating binary package.  [#]_
> +
> +This causes the Debian archive to retain the versions of the source
> +packages that were actually incorporated.  In particular, if the
> +versions of the incorporated parts are updated but the incorporating
> +binary package is not rebuilt, the older versions of the incorporated
> +parts will remain in the archive in order to satisfy the license.

Sounds good.

[...]
> @@ -625,6 +634,11 @@ field in its control file:
> 
>  Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
> 
> +This field should not be used for purposes other than satisfying
> +license or DFSG requirements to provide full source code.  In
> +particular, it should not be used to enable finding packages that
> +should be rebuilt against newer versions of their build dependencies.

This feels overly aggressive to me: if the field is already set, why
wouldn't I use it to find packages to rebuild?  I think the intent is
something closer to "In particular, it should not be added solely to
enable finding packages that should be rebuilt [...]".

That said, seconded.

Thanks,
Jonathan

Bug#885219: /lib64 provision added in 9.1.1 prohibits multilib libc

[Jonathan Nieder]

Russ Allbery wrote:

> Allow libc to install files in /lib64
>
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d9e20a..d7c4956 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -35,7 +35,8 @@ Debian Policy. The following exceptions to the FHS apply:
>  character.
> 
>  3.  The requirement for amd64 to use ``/lib64`` for 64 bit binaries is
> -removed.  Only the dynamic linker is allowed to use this directory.
> +removed.  Only the dynamic linker and libc are allowed to use this
> +directory.
> 
>  4.  The requirement for object files, internal binaries, and libraries,
>  including ``libc.so.*``, to be located directly under ``/lib{,32}``

Seconded.

Thank you,
Jonathan

Bug#885166: instability with 4.14 regarding KVM virtualization

[Jonathan Nieder]

Marc Haber wrote:
> On Mon, Dec 25, 2017 at 10:02:48PM +, Ben Hutchings wrote:

>> Given that commit fb1522e099f0 was merged after -rc7 I assume it's an
>> important fix, though the commit message doesn't spell that out.  So I
>> think that whenever bisect asks you to test a version that doesn't
>> contain it, you should cherry-pick it first to avoid the other bug.  (I
>> think you will then need to use 'git bisect good|bad HEAD^' after
>> testing, rather than implicitly flagging the current head commit.)
>
> Would
>   git show fb1522e099f0 | patch -p1
>   build/test
>   git reset --hard
>   git bisect good|bad
> be the same thing? I would feel much more comfortable with that.

Yes.  (The main advantage of 'git cherry-pick' over that is that it
performs rename detection, but that shouldn't be relevant here.  You
can similarly do

git cherry-pick --no-commit fb1522e099f0
build/test
git reset --hard
git bisect good|bad

)

Thanks,
Jonathan

Bug#889680: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

[Jonathan Nieder]

+cc: upstream
Hi,

Salvatore Bonaccorso wrote[1]:

> the following vulnerability was published for git.
>
> CVE-2018-121[0]:
> |client prints server sent ANSI escape codes to the terminal, allowing
> |for unverified messages to potentially execute arbitrary commands
>
> Creating this bug to track the issue in the BTS. Apparently the CVE
> was sssigned without notifying/discussing it with upstream, at least
> according to [1].
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2018-121
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-121
> [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1

Thanks.  Upstream was notified about this and we dropped the ball on
passing it on to a more public forum.  Sorry about that.

I'd be interested in your advice on this.  There are cases where the
user may *want* ANSI escape codes to be passed through without change
and other cases where the user doesn't want that.  Commands like "git
diff" pass their output through a pager by default, which itself may
or may not sanitize the output.

In other words, there are multiple components at play:

 1. A terminal.  IMHO, it is completely inexcusable these days for a
terminal to allow arbitrary code execution by writing output to
it.  If bugs of that kind still exist, I think we should fix them
(and perhaps even make it a requirement in Debian policy to make
the expectations clear for new terminals).

That said, for defense in depth, it can be useful to also guard
against this kind of issue in other components.  In particular:

 2. A pager.  Are there clear guidelines for what it is safe and not
safe for a pager to write to a terminal?

"less -R" tries to only allow ANSI "color" escape sequences
through but I wouldn't be surprised if there are some cases it
misses.

 3. Output formats.  Some git commands are designed for scripting
and do not have a sensible way to sanitize their output without
breaking scripts.  Fortunately, in the case of "git diff", git
has a notion of a "binary patch" where everything is sanitized,
at the cost of the output being unreadable to a human (email-safe
characters but not something that a human can read at a glance).
So if we know what sequences to avoid writing to stdout, then we
can treat files with those sequences as binary.

Pointers welcome.

Thanks,
Jonathan

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