Bug#1016759: easy-rsa: regression?: Conflicting 'vars' files found

[Daniel Shahaf]

Control: tags -1 fixed-upstream

Teco Boot wrote on Mon, 15 Aug 2022 14:59 +00:00:
> It is fixed upstream in Merge branch 'TinCanTech-fix-make-cadir' 
> 
> See 
> https://github.com/OpenVPN/easy-rsa/issues/633#issuecomment-1215108651 
> 

Thanks; metadata adjusted.

> Issue can be closed.

I assume this ticket will be closed by the next upload to the easy-rsa package, 
as per usual.

Thanks for your work!

Daniel

Bug#1016759: easy-rsa: regression?: Conflicting 'vars' files found

[Daniel Shahaf]

Package: easy-rsa
Version: 3.1.0-0.1
Severity: normal

Dear Maintainer,

Consider the following sequence of commands:

% make-cadir foo
% cd foo
% ./easyrsa init-pki
% ./easyrsa build-ca

In a fresh bullseye chroot (3.0.8-1), that sequence succeeds:

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
…/pki/ca.crt

In a sid chroot from today (3.1.0-0.1), that sequence fails with:

# ./easyrsa build-ca 
Found: …/pki/vars
Found: …/vars

Easy-RSA error:

Conflicting 'vars' files found.

Priority should be given to your PKI vars file:
* /root/sid/pki/vars

I don't use easy-rsa, but this seems like a regression.

HTH,

Daniel

P.S. The changelog of this version includes the item "autopkgtests: Remove
conflicting vars file", which may be related.

Bug#1014383: [Pkg-zsh-devel] Bug#1014383: zsh: "IOT instruction" on SIGABRT

[Daniel Shahaf]

Control: tags -1 upstream

Jakub Wilk wrote on Tue, 05 Jul 2022 08:40 +00:00:
> The message zsh prints when a process aborts is confusing:
>
>% perl -MPOSIX -e'abort()'
>zsh: IOT instruction  perl -MPOSIX -e'abort()'
>
> I happen to know that SIGIOT == SIGABRT on Linux, but I guess most 
> people don't.

If we'd like to fix this, see the handling of SIGPOLL/SIGIO at the top of 
Src/signames2.awk.

Cheers,

Daniel

Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Daniel Shahaf]

Control: clone 909124 -2
Control: severity -2 normal
Control: retitle -2 quilt: don't set QUILT_PAGER=less when $LESS is set
Control: tags -2 upstream
Control: found -2 0.66-2.1
Control: tags 909124 upstream patch
Control: found 909124 0.66-2.1
Control: severity 909124 minor

Trent W. Buck wrote on Thu, Mar 17, 2022 at 18:43:20 +1100:
> Trent W. Buck wrote:
> > +++ b/usr/share/quilt/scripts/patchfns
> > @@ -,7 +,7 @@ setup_pager()
> > -   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
> > +   QUILT_PAGER=${QUILT_PAGER:-${GIT_PAGER:-${PAGER:-less -R}}}

Thanks.  I'm posting a patch for this bug (#909124 == #-1), and bumping
it to "minor" after re-reviewing 
.

[[[
--- a/quilt/scripts/patchfns.in
+++ b/quilt/scripts/patchfns.in
@@ -,7 +,7 @@ setup_pager()
 
# QUILT_PAGER = QUILT_PAGER | GIT_PAGER | PAGER | less -R
# NOTE: QUILT_PAGER='' is significant
-   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
+   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-/usr/bin/sensible-pager}}}
 
[ -z "$QUILT_PAGER" -o "$QUILT_PAGER" = "cat" ]  && return 0
 
]]]

More below.

> FAILS:  env PAGER=cat quilt series
> WORKS:  env -u LESS PAGER=cat quilt series
> 
> 
> This is actually a separate but related bug in quilt.
> If $LESS is set, quilt ignores $PAGER and forces less.
> This is wrong.
⋮
> 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && QUILT_PAGER="less 
> -FRX"

Agreed.  If Alice normally uses «export PAGER=less LESS=S» and then sets
PAGER=foo, that's the pager quilt shoult use.

Cloned as -2.  The above patch does _not_ fix it.

> If quilt wants to override the user's requested $LESS,
> it should do so with "export LESS=FRX",
> entirely independent of $QUILT_PAGER'.

This particular approach would be lossy: it would overwrite the user's
value of $LESS.  Instead, quilt could _append_ to $LESS, or pass -R into
less(1)'s argv, or only use $LESS as a hint if PAGER and GIT_PAGER are
also unset and less(1) is installed, or document that the user should
configure their $PAGER / $LESS / $QUILT_PAGER envvars with -R, or…

Cheers,

Daniel

P.S. «sed -i s/Upstream-status/Forwarded/ debian/patches/check_SERIES_exists»
would make that patch's headers compatible with DEP-3 parsers.

> 18:32  And for comparison, "PAGER=cat git diff" *is* working for git in 
> the same environment.
> 18:32  I wonder if quilt is getting confused because $HOME doesn't exist?
> 18:33  Nope.  But "env -i PAGER=cat quilt series" behaves
> 18:34  Bizarre...
> 18:36  Get Fucked.
> 18:36  env -u LESS fixes it
> 18:36  But why?
> 18:37  because quilt is broken I guess
> 18:37  $LESS should be read by less(1), not by quilt(1)
> 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && QUILT_PAGER="less 
> -FRX"
> 18:38  Ugh.
> 18:39  "env" didn't show anything, because it wasn't exported. We 
> should have used "set" instead.
> 

Bug#1007188: [Pkg-zsh-devel] Bug#1007188: zsh: completion for "info -f" does not work

[Daniel Shahaf]

Control: forwarded -1 https://www.zsh.org/workers/49849

Vincent Lefevre wrote on Tue, Mar 15, 2022 at 18:33:27 +0100:
> Control: forwarded -1 https://www.zsh.org/mla/workers/2022/msg00179.html
> 
> This also occurs with zsh from upstream's Git repository.

Thanks, Vincent.

Daniel
(The link is to the same post.)

Bug#1007188: [Pkg-zsh-devel] Bug#1007188: zsh: completion for "info -f" does not work

[Daniel Shahaf]

Control: reassign -1 zsh-common 5.8.1-1
Control: tags -1 upstream

Could you please forward this upstream (and tag forwarded)?

Bug#1006345: postfix: fix configuration parameter name in README.Debian

[Daniel Shahaf]

Package: postfix
Version: 3.6.4-1
Severity: minor
Tags: patch
Control: found -1 3.4.14-0+deb10u1
Control: found -1 3.5.13-1

Dear Maintainer,

The name of a configuration parameter is misspelled:

[[[
diff --git a/debian/README.Debian b/debian/README.Debian
index a4a42884..7baf0c43 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -241,7 +241,7 @@ postmap /etc/postfix/generic_mapping
 
 and add the following line to main.cf:
 
-sender_generic_maps = hash:/etc/postfix/generic_mapping
+smtp_generic_maps = hash:/etc/postfix/generic_mapping
 
 One advantage to using generic over canonical mapping is that the latter will
 be applied to local mail as well. If the system will be configured to send all
]]]

Cheers,

Daniel

Bug#1006331: www.debian.org: please set charset=utf-8 for vote tally *.txt files

[Daniel Shahaf]

Package: www.debian.org
Severity: minor

Dear Maintainer,

 contains UTF-8 in
various DDs' names.

The file is served with "Content-Type: text/plain" and has no BOM, so
browsers have to guess the encoding.

Please consider serving the file as "Content-Type: text/plain; charset=UTF-8"
to ensure names are rendered correctly.

Cheers,

Daniel

Bug#1006235: stgit: please re-enable the interactive tests

[Daniel Shahaf]

Source: stgit
Version: 0.19-1
Severity: normal
Tags: patch

Dear Maintainer,

One of the Debian changes (debian/patches/*) disables part of the test
suite.

Please consider the following patch so the entire test suite runs.  It
deletes debian/patches/disable_interactive_test and extends
debian/patches/use_editor_as_default to also update the test suite as
needed.  The net result is that t3300-edit.sh now runs.

[[[
diff --git a/debian/patches/use_editor_as_default 
b/debian/patches/use_editor_as_default
index f941073..65d96cb 100644
--- a/debian/patches/use_editor_as_default
+++ b/debian/patches/use_editor_as_default
@@ -9,8 +9,6 @@ Last-Update: 2014-03-26
  stgit/utils.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/stgit/utils.py b/stgit/utils.py
-index cdcc4a9..fbd79a2 100644
 --- a/stgit/utils.py
 +++ b/stgit/utils.py
 @@ -176,7 +176,7 @@ def get_editor():
@@ -22,3 +20,38 @@ index cdcc4a9..fbd79a2 100644
  if editor:
  return editor
  
+--- a/t/t3300-edit.sh
 b/t/t3300-edit.sh
+@@ -87,7 +87,7 @@ test_expect_success 'Save template to st
+ #   3. core.editor
+ #   4. VISUAL
+ #   5. EDITOR
+-#   6. vi
++#   6. editor
+ 
+ mkeditor ()
+ {
+@@ -98,11 +98,11 @@ EOF
+ chmod a+x "$1"
+ }
+ 
+-mkeditor vi
+-test_expect_success 'Edit commit message interactively (vi)' '
++mkeditor editor
++test_expect_success 'Edit commit message interactively (editor)' '
+ m=$(msg HEAD) &&
+ PATH=.:$PATH stg edit p2 &&
+-test "$(msg HEAD)" = "$m/vi"
++test "$(msg HEAD)" = "$m/editor"
+ '
+ 
+ mkeditor e1
+@@ -143,7 +143,7 @@ test_expect_success 'Edit commit message
+ test "$(msg HEAD)" = "$m/e5"
+ '
+ 
+-rm -f vi e1 e2 e3 e4 e5
++rm -f editor e1 e2 e3 e4 e5
+ git config --unset core.editor
+ git config --unset stgit.editor
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 7b014e7..fd89c42 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,3 @@
 use_editor_as_default
 stg-gitk_bashism
-disable_interactive_test
 Avoid-the-git-error-messages-when-running-stg-outside-of-.patch
diff --git a/debian/patches/disable_interactive_test 
b/debian/patches/disable_interactive_test
deleted file mode 100644
index 12a6a5b..000
--- a/debian/patches/disable_interactive_test
+++ /dev/null
@@ -1,27 +0,0 @@
-From: Maximiliano Curia 
-Date: Sat, 2 Sep 2017 14:06:57 +0200
-Subject: Disable test calling editor
-
-Upstream uses vi as the default editor, while the debian packages default to
-the editor command, thus the different behavior.
-
-Author: Maximiliano Curia 
-Forwarded: not-needed
-Last-Update: 2014-03-26

- t/t3300-edit.sh | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/t/t3300-edit.sh b/t/t3300-edit.sh
-index 61baab8..392e1f3 100755
 a/t/t3300-edit.sh
-+++ b/t/t3300-edit.sh
-@@ -2,6 +2,8 @@
- test_description='Test "stg edit"'
- 
- . ./test-lib.sh
-+test_done
-+exit
- 
- test_expect_success 'Setup' '
- printf "000\n111\n222\n333\n" >> foo &&
]]]

Cheers,

Daniel

Bug#1004341: mercurial-common: please add contrib/zsh_completion to d/copyright

[Daniel Shahaf]

Package: mercurial-common
Version: 6.0.1-3
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please add contrib/zsh_completion's license (lines 19:34) to
debian/copyright.

Thanks,

Daniel

P.S.  I wasn't sure whether this is a wishlist bug (since the license
seems to be compatible with license in the «Files: *» section of
d/copyright) or an RC bug (a violation of the license or of Policy §2.3
point (1), as well as §4.5 and §12.5), so I'm filing this as wishlist and
Cc'ing -legal@ in case the severity should be bumped.

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Daniel Shahaf]

Axel Beckert wrote on Sun, Jan 09, 2022 at 08:52:04 +0100:
> Daniel Shahaf wrote:
> > […], or /etc/zsh/zshrc.d/ could be added (there's a separate ticket
> > for that but my quick grep didn't find it),
> 
> You probably had https://bugs.debian.org/776663 in mind which has been
> filed against zsh-common, not zsh (but src:zsh), so I suspect you
> haven't it found because of that.
> 

Indeed.  Thanks.  (I didn't pass «--source» to querybts(1).)

> I'd though would like to see a consensus inside the Debian Zsh team on
> how (and where) to go forward. I'd especially would be happy to hear
> about Frank's (Cc'ed) opinion as he and Daniel are those who are most
> clued about upstream things and especially upstream conventions. (And
> because I know that Frank has a quite clear opinion on #776663 — where
> I actually do have an opinion, too, albeit a different one than Frank.)

Well, if I were designing things from scratch, I'd probably go for
having packages in Debian install to /usr/share/zsh/foo whatever their
upstreams install by default to /usr/local/share/zsh/foo.  That'd be
exactly analogous to Debian's semantics of /usr/bin v. /usr/local/bin
("owned by packages" v. "owned by the local sysadmin") and would result
in short, readable package build scripts (basically just the equivalent
of «./configure --prefix=/usr»).

However, /usr/share/zsh/vendor-* exist, and I see no reason to break
working code.  I suppose we could deprecate these two dirs but not
actually drop support for them before zsh 6.0.  In lintian terms,
I suppose that means a ≤info lintian check for zsh 5.x and a ≥warning
lintian check for zsh 6.x.

And for upstreams… well, that's a discussion I'd rather have upstream.

Cheers,

Daniel

Bug#934926: update

[Daniel Shahaf]

Joey Hess wrote on Sat, Jan 08, 2022 at 16:27:53 -0400:
> The simple fact is that as an upstream author who used the debian
> locations because they were the ones that worked on my system, I get bug
> reports from users of other systems that it's not right for wider uses
> of zsh. And Debian seems to be leaving it up to me to deal with it,

The right thing to do *at this time* is fairly straightforward:

- Packages that are part of Debian should install to
  /usr/share/zsh/vendor-*.

- Upstream packages have three options:

  + Install to /usr/local/share/zsh/site-functions (regardless of their
own $PREFIX _and_ of zsh's $PREFIX)

  + Install to ${PREFIX of the zsh build}/share/zsh/site-functions

  + Install to some other place and use a post-install message to direct
the user to amend their $fpath manually.

That's not to say that things can't be improved going forward.  Of
course they can.  I'm just trying to document the best practice at this
time.

Going forward, perhaps the vendor-* convention could be upstreamed, or
upstream could make it easier to discover its prefix, or /etc/zsh/zshrc.d/
could be added (there's a separate ticket for that but my quick grep
didn't find it), or…

Indeed, this ticket seems a bit open-ended.  What's being asked here?
Just to add /usr/share/zsh/site-functions [sic] to Debian's zsh's
default $fpath?  Or something more general, e.g., "Ensure there are as
few obstacles as possible to developers of third-party autoloadable
functions"?

Cheers,

Daniel

Bug#941214: [Pkg-zsh-devel] Bug#941214: mutt zsh completion broken, -a does not take email address

[Daniel Shahaf]

martin f krafft wrote on Fri, Dec 31, 2021 at 15:26:24 +1300:
> Regarding the following, written by "Daniel Shahaf" on 2021-12-31 at 02:16 
> Uhr +:
> > The two consecutive colons on the -a line mean the -a option takes an
> > optional argument.
> 
> Herein lies the problem:
> 
> ```
>   -a  [...] --  attach file(s) to the message
>   the list of files must be terminated with the "--" sequence
> ```
> 
> So it's neither optional, nor even a single word by necessity.

Good catch.

I think it's possible to teach _mutt how to complete this in the general
case, but the details are better hashed out upstream (zsh-work...@zsh.org).

Cheers,

Daniel

Bug#941214: [Pkg-zsh-devel] Bug#941214: mutt zsh completion broken, -a does not take email address

[Daniel Shahaf]

David Bremner wrote on Sun, Dec 26, 2021 at 07:54:35 -0400:
> David Bremner  writes:
> 
> > martin f krafft  writes:
> >
> >> Package: notmuch
> >> Version: 0.29.1-2
> >> Severity: normal
> >> File: /usr/share/zsh/vendor-completions/_email-notmuch
> >>
> >> mutt has a command-line switch '-a' for attachments, and the Zsh 
> >> completer offers files and directories for its argument.
> >>
> >> As of late, _email-notmuch also adds all addresses into the mix:
> >>
> >> % mutt -a ^D
> >> directory
> >> […]
> >> file attachment
> >> […]
> >> email address (notmuch)
> >> […]
> >>
> >>
> >> In the context of '-a', no email addresses should be offered. Maybe 
> >> this is actually a problem with Zsh or Mutt, I can't figure it out. 
> >> But since I see mainly notmuch in the output, I am filing here…
> >
> > As far as I can tell, the whole point of _email-notmuch is to provide
> > addresses, so maybe it shouldn't be called there? To me that suggests
> > the bug should be reassigned to mutt. I am CCing the mutt maintainers,
> > in case they want to weigh in.
> >
> > d
> 
> My mistake, the mutt completion is actually shipped by zsh. I've
> attached _email-notmuch (installed by package notmuch) for feedback. If
> something looks wrong with it, please let me know. Otherwise I think I
> should reassign this bug to zsh, where it can at least get some more
> expert consideration.

By code inspection:

Email addresses are offered because the function _mutt (from the file of
the same name shipped by zsh-common) contains:
.
_arguments -s -S \
  '::recipient:_email_addresses -n mutt' \
  '*-a[attach file using MIME]::file attachment:_files' \
.
which is as self-explanatory as it gets, of course ☺

The two consecutive colons on the -a line mean the -a option takes an
optional argument.  Therefore, «mutt -a » completes both arguments
to -a, using _files, and email addresses, using «_email_addresses -n
mutt» (which presumably calls _email-notmuch along with other _email-*
functions).  Still by code inspection, if you remove one of the two
consecutive colons on the -a line, email addresses shouldn't be offered
any more.

If the above analysis is correct, this bug report belongs to zsh-common.

Furthermore, if invocations such as «mutt -a f...@example.com» and «mutt
-a» without further arguments are errors (they are in older mutts, but I
haven't tested in sid), then the report is valid and the fix would be to
drop the second consecutive colon from the -a line in _mutt.

Cheers,

Daniel

Bug#802872: graphicsmagick: SVG to PNG conversion omits circles

[Daniel Shahaf]

Control: forwarded -1 https://sourceforge.net/p/graphicsmagick/bugs/322/
Control: tags -1 fixed-upstream

Bob Friesenhahn wrote on Sat, Oct 24, 2015 at 12:11:42 -0500:
> GraphicsMagick bug 322 has been opened at SourceForge to track this issue.

And has been fixed in the meantime:

[quoting https://sourceforge.net/p/graphicsmagick/bugs/322/#9fb6]
This ticket has been fixed by change set 307b3c38b372, dated 4/30/18.

That changeset was first released in the upstream GraphicsMagick-1_3_30
tag (going by hg logs) and in version 1.3.29+hg15665-1 of the package
(going by package version numbers in `debsnap --list`).

However, upon converting the SVG file in the OP, I get "gm convert:
invalid primitive argument (-0.000393701)" in both buster 
(1.4+really1.3.35-1~deb10u1)
and current sid (1.4+really1.3.37-1).  I'm not sure whether that's
a different form of the same bug or a separate bug.

Cheers,

Daniel

Bug#1002469: graphicsmagick: convert: SVG->PNG conversion shifts image left mostly off canvas; possibly because of a 'rotate' transform?

[Daniel Shahaf]

Package: graphicsmagick
Version: 1.4+really1.3.37-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

% wget 
'https://salsa.debian.org/reproducible-builds/reproducible-website/-/raw/13974cb4b4fa5dcdb2add8d46886d42676597db2/images/logos/rb-logo-only.svg?inline=false'
 -O rb-logo-only.svg
% gm convert rb-logo-only.svg 1.png

   * What was the outcome of this action?

Only one circle and a corner of one arrow are visible in the PNG files.

   * What outcome did you expect instead?

I expected all elements of the logo (circles and polygons) to be visible
where they were.  That's what happens when another tool is used to do
the conversion (gimp 2.10.8-2).

   * Additional information

The resulting PNG looks as though the contents of the SVG file were all
shifted left by 82.8% of the width of the canvas and up by 4% of the
height of the canvas.  (Determined by comparing «gm convert -size 500x500
rb-logo-only.svg -resize 500x500 bar.png» to the SVG file at 500x500.)

If the second and third parameters of the «rotate» transformation are
deleted before calling convert(1), then the resulting PNG is identical
to the above PNG.  That is, it looks as though the second and third
parameters of «rotate» are treated as though they were absent.

If the «rotate» transformation is deleted entirely, then the SVG→PNG
transformation is correct.  (Some of the circles and polygons are
still off-canvas, but they are off-canvas both in the input SVG and
in the output PNG.)

Many thanks to Grzegorz (Cc'd) for the observations related to the
«rotate» transformation.

Cheers,

Daniel


-- System Information:
(fresh sid chroot from today)

Bug#999918: zsh: depends on obsolete pcre3 library

[Daniel Shahaf]

Control: tags -1 upstream

Good morning Matthew,

Matthew Vernon wrote on Thu, Nov 18, 2021 at 11:49:09 +:
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/

Is there a pcre1→pcre2 upgrade guide for library consumers?  I guess
there's more to the upgrade than s/pcre_foo/pcre2_foo/g in our code, or
they wouldn't have bumped the major version number.

Is there a summary of the regex syntax differences between pcre1 and
pcre2?

I couldn't find either of these anywhere.

Cheers,

Daniel

Bug#138691: zsh: completion for man should find filenames as well as man pages

[Daniel Shahaf]

Vincent Lefevre wrote on Sun, Aug 01, 2021 at 22:27:38 +0200:
> As this very old bug is still open...
> 
> On 2002-03-18 11:45:08 -0500, Matt Zimmerman wrote:
> > On Mon, Mar 18, 2002 at 11:06:15AM -0500, Clint Adams wrote:
> > 
> > > > When the -l option is given, man will open and display a man page
> > > > specified as a pathname (and not search manpath).  At least with
> > > > Debian's man, this also works if -l is not specified, though manpath is
> > > > searched first.
> > > 
> > > This doesn't work for me with man-db 2.3.20-15.  What am I doing wrong?
> > 
> > The fallback only seems to work if there is a '/' character in the argument:
> > 
> > poseidon:[~] ls man.1
> > man.1
> > poseidon:[~] man man.1
> > No manual entry for man.1
> > zsh: exit 16man man.1
> > poseidon:[~] man -l man.1
> > Reformatting man.1, please wait...
> > poseidon:[~] man ./man.1
> > Reformatting man.1, please wait...
> > poseidon:[~] 
> 
> With zsh 5.8-6+b2 on my machine, completion works as expected if there
> is a "/" character:
> 
> zira:~> man ./ma[Tab]
> 
> gives
> 
> zira:~> man ./man.1

Looks like this was first fixed in "28468: allow man page completion for
files when / is present" (e5ddd5b62f794e262119053c367ab66eca678475),
first released in zsh-4.3.10-test-3 and debian/4.3.11-4.  There were
later follow-ups, e.g., 45226 from 2020-01-05.

> Completion also works with -l, but also proposes files that are not
> man pages. I don't know whether such a difference is expected.

Shouldn't be hard to fix.  Here's a proof of concept; the $funcstack
check should be replaced by something else to decouple caller and
callee.

[[[
diff --git a/Completion/Unix/Command/_man b/Completion/Unix/Command/_man
index dba1d13dc..5c2d96c52 100644
--- a/Completion/Unix/Command/_man
+++ b/Completion/Unix/Command/_man
@@ -93,7 +93,7 @@ _man() {
   '(-i -I --ignore-case --match-case)'{-i,--ignore-case}'[search 
case-insensitively]'
   '(-i -I --ignore-case --match-case)'{-I,--match-case}'[search 
case-sensitively]'
   '(-L --locale)'{-L+,--locale=}'[specify locale]:locale:_locales'
-  "(${(j< >)modes})"{-l+,--local-file=}'[format and display specified 
file]:*:::manual file:_files'
+  "(${(j< >)modes})"{-l+,--local-file=}'[format and display specified 
file]:*:::manual file:_man_pages'
   "!(${(j< >)modes})"{--location,--location-cat}
   '--names-only[match only page names (with --regex or --wildcard)]'
   '(--nh --no-hyphenation)'{--nh,--no-hyphenation}'[disable hyphenation]'
@@ -139,7 +139,7 @@ _man() {
   '-S+[display only man pages with file names matching specified 
string]:search string'
 )
 [[ $variant == openbsd* ]] && args+=(
-  "(${(j< >)modes})-l+[format and display specified file]:*:::manual 
file:_files"
+  "(${(j< >)modes})-l+[format and display specified file]:*:::manual 
file:_man_pages"
   # @todo Could enumerate these
   '-S[search manual of specified architecture]:architecture'
 )
@@ -419,7 +419,7 @@ _man_pages() {
   # What files corresponding to manual pages can end in.
   local suf='.((?|<->*|ntcl)(|.gz|.bz2|.z|.Z|.lzma))'
 
-  if [[ $PREFIX$SUFFIX = */* ]]; then
+  if [[ $PREFIX$SUFFIX = */* || ${funcstack[2]} = '_arguments' ]]; then
 # Easy way to test for versions of man that allow file names.
 # This can't be a normal man page reference.
 # Try to complete by glob first.
]]]

Does it work as intended?

I don't intend to take this further; feel free to finish this yourself,
or to poke upstream in case someone there has time to finish this.

Cheers,

Daniel

Bug#986103: in package dpkg marked as pending

[Daniel Shahaf]

Guillem Jover wrote on Sun, May 16, 2021 at 02:33:43 +0200:
> scripts: Add zsh completions for dpkg-parsechangelog
> 
> [guil...@debian.org: Hook into build system. ]

Thanks, Guillem!

> Closes: #986103
> Signed-off-by: Guillem Jover 

Bug#986580: zsh-doc: Please install Misc/vcs_info-examples

[Daniel Shahaf]

Package: zsh-common
Version: 5.8-6
Severity: wishlist
Tags: upstream

Dear Maintainer,

As the subject says, please install Misc/vcs_info-examples as
documentation examples (presumably to /usr/share/doc/zsh/examples?).

Tagging this upstream in case this is better fixed in upstream's «make
install».  However, upstream's «make install» doesn't already install
something to /usr/share/doc, and to figure that out would spread me too
thin, so I'm filing this bug instead.

Cheers,

Daniel

Bug#986103: dpkg-parsechangelog: please add zsh completion

[Daniel Shahaf]

Package: dpkg-dev
Version: 1.20.8
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

   * What led up to the situation?

«dpkg-parsechangelog -S » and «dpkg-parsechangelog -F » don't
currently have zsh completion.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I wrote a completion function implementing this.

Please consider installing it to 
«/usr/share/zsh/vendor-completions/_dpkg-parsechangelog».

Thanks,

Daniel

[[[
#compdef dpkg-parsechangelog 

local -a args
args=(
  '(-l --file)'{-l+,--file=}'[specify path to d/changelog]: :_files'
  # Note: We have to use "= " since _perl_modules in zsh ≤5.8 assumes 
${words[1]} is a perl. (See workers/48321)
  '-F+[specify changelog format]:changelog format:= _perl_modules 
--strip-prefix --perl-hierarchy=Dpkg\:\:Changelog'
  '!-L+'
  '(-S --show-field)'{-S+,--show-field=}'[show only one field]:changelog 
field:(Source Version Distribution Urgency Maintainer Date Timestamp Closes 
Changelog)' 
  '(-)'{-\?,--help}'[show the usage message]'
  '(-)--version[show the version information]'
  '--format=[set the output format]:output format:((dpkg\:classic rfc822))'
  '(--all)--reverse[print all changes, oldest to newest]'
  '(--reverse)--all[print all changes, newest to oldest]'
  # TODO: all these should complete version numbers from 
${(Q)opt_args[-l]:-debian/changelog}
  '(-s --since -v)'{-s+,--since=,-v+}'[specify strict lower bound]:version 
number'
  '(-u --until)'{-u+,--until=}'[specify strict upper bound]:version number'
  '(-f --from)'{-f+,--from=}'[specify weak lower bound]:version number'
  '(-t --to)'{-t+,-to=}'[specify weak upper bound]:version number'
  '(-c --count -n)'{-c+,-n+,--count=}'[specify number of entries to 
print]:limit (integer)'
  '(-o --offset)'{-o+,--offset=}'[offset the number of entries to print]:offset 
(integer)'
)
_arguments : "${args[@]}"
]]]

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Daniel Shahaf]

Good morning Felix,

Felix Lechner wrote on Tue, Mar 23, 2021 at 14:16:26 -0700:
> Hi Daniel,
> 
> On Mon, Jul 13, 2020 at 8:27 AM Daniel Shahaf  wrote:
> >
> > a debian/upstream/signing-key.asc file
> > which contains an expired snapshot of upstream's signing key
> 
> Did uscan give you any trouble when trying to validate upstream's
> release signature?

In zsh-syntax-highlighting's packaging I don't use uscan(1).  I just
git-merge(1) the new upstream tag, and use git-archive(1) to fake
a .orig tarball.

According to comments in zsh-syntax-highlighting's debian/README.source
and debian/source/lintian-overrides, uscan(1) was avoided because
upstream produces signed tags but not signed tarballs, and no way was
identified to have uscan(1) verify them.  Thus, the automation that
calls git-archive(1) also handles verification manually.

In my specific case, I don't actually need the verification at all
because I happen to upstream's release manager and sign the tags myself
in that capacity, but the workflow doesn't depend on this.

Cheers,

Daniel

> Kind regards
> Felix Lechner
> 

Bug#970848: [Pkg-zsh-devel] Bug#970848: Problem with path to completion scripts

[Daniel Shahaf]

Frank Terbeck wrote on Fri, 25 Sep 2020 00:02 +0200:
> Georgy Komarov wrote:
> > I encountered with a problem, when trying to use custom zsh completions.  
> 
> As debian/README.Debian states:
> 
> Load-path for functions from other packages
> ---
> 
> In respsonse to #620452, the zsh-binary from Debian's zsh package started to
> provide two entries to $fpath (the search path for loadable functions) for
> other packages to drop function files into:
> 
>   - /usr/share/zsh/vendor-completions for functions that add functionality to
> zsh's function based completion system (compsys)
> 
>   - /usr/share/zsh/vendor-functions for all other functions
> 
> If you maintain another Debian package that wants to add functions to zsh's
> function load-path, please use the those conventions when installing function
> files.

These directories are added to $fpath near the start.  Therefore, files
dropped into them will override files provided further down $fpath,
which in particular includes completion functions shipped with zsh
upstream.  In particular, if [a file dropped into] vendor-completions
and zsh upstream both provide completion for /usr/bin/foo, then the
former will be used — even though it's not necessarily the better of
the two.

Recommend to review collisions on a case-by-case basis and resolve
duplications (between zsh on the one hand, and zsh-completions or other
upstreams on the other hand) as needed.

Note that to look for collisions, it's not sufficient to look for
filename collisions, since for a given external command (say,
systemctl(8)) zsh upstream and a third-party upstream might use
different filenames and function names (e.g., "_systemd" v.
"_systemctl").

Cheers,

Daniel

Bug#969305: [Pkg-zsh-devel] Bug#969305: Bug#969305: zsh: safe-rm needs to be added to the default path of interactive shells to work

[Daniel Shahaf]

Francois Marier wrote on Mon, 31 Aug 2020 12:04 -0700:
> On 2020-08-31 at 04:41:56, Daniel Shahaf wrote:
> > I guess it should be in the zprofile file, guarded by a [[ -o interactive 
> > ]] check.  
> 
> From the comment in /etc/zsh/zshrc:
> 
>   # This file is sourced only for interactive shells. It
>   # should contain commands to set up aliases, functions,
>   # options, key bindings, etc.
> 
> I thought it was a better fit, given that /etc/zsh/zprofile claims it's only
> for login shells:
> 
>   # This file is sourced only for login shells (i.e. shells
>   # invoked with "-" as the first character of argv[0], and
>   # shells invoked with the -l flag.)
> 
> Or maybe I got that wrong?
> 

You didn't get that wrong.  It's just that setting envvars is the job of
a login shell, not of shells spawned later on.  (That'd be analogous to
how safe-rm, as you said, drops code into /etc/profile.d/, rather than
into a (non-existent) /etc/bash.bashrc.d/.)  Thus, zprofile.

The [[ -o interactive ]] is to not apply to non-interactive login
shells.  (When do these happen, anyway?)

> > > However, I don't see a way for packages to do this. So I guess there would
> > > be two ways to make this possible:
> > > 
> > > 1. The main /etc/zsh/zshrc script could source all .sh files in a new
> > >/etc/zsh/zshrc.d/ directory.
> > > 2. The /etc/zsh/zshrc that ships in Debian could include the above.
> > > 
> > > Are either of these something you'd be willing to consider?  
> > 
> > I don't have an opinion one way or the other.
> > 
> > I do note that option #2 would cause a stat(2) call during shell startup
> > for everyone who _doesn't_ use safe-rm.  Would that be a problem?
> > (E.g., slower shell startup)  
> 
> Good point about the extra stat. I honestly don't know whether that kind of
> impact can even be reliably measured, but you're right that it would
> be unnecessary for non-users of safe-rm.
> 
> > Probably not what you had in mind, but my first instinct here is to
> > look for a shell-independent solution.  For example:  
> 
> Indeed, that's an excellent approach and is in fact where I started.
> 

Ah, I didn't know the background here.  Thanks for the detailed exposition.

> > 3. Get the OS to add /usr/share/safe-rm/bin to $PATH before the user's
> > shell is executed in the first place.  (On FreeBSD that'd be
> > login.conf(5), but I don't know what the Linux equivalent is.)  
> 
> That appears to be in /etc/login.defs, but without any way for a package to
> configure.
> 

I see.

> > 4. Use dpkg-divert(8) to replace /bin/rm with a wrapper that calls
> > either safe-rm or the diverted rm binary, depending on whether it's
> > interactive or not.  
> 
> That was my first attempt and it turned out to be extremely risky and hard
> to get right:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489690

That bug basically says that when /bin/rm is replaced, the process of
replacement must be atomic.

I don't see how a requirement for atomicity is intractable.  On the
contrary, I think it's a textbook problem with textbook solutions.  For
example, one standard and portable answer is to use rename(2)'s
atomicity guarantees.  That's exactly what dash's maintainer scripts,
that the above bugs point to, do: see replace_with_link(), and note how
it places the $temp in the same directory as $dfile.

More generally, «rm /bin/rm && ln -s foo /bin/rm» is like «ls "$@"» and
«date | grep -w Tue»: it's wrong; it's not _obviously_ wrong; code
review will spot the mistake easily; once the correct pattern is
learned, it'll be gotten right every time, automatically.

All the above being said, I wouldn't have been surprised if getting this
approach right were complicated by something else — say, dpkg-divert
uses in _other_ packages that need to be coëxisted with.

> > If you don't already know them, see RM_STAR_SILENT and RM_STAR_WAIT in
> > zshoptions(1).  
> 
> Oh, that's very cool! A very good complement to safe-rm in fact since
> that's not something safe-rm can do anything about since the shell expands
> these globs before passing the paths to the rm command.

Well, safe-rm _could_ check whether the arguments are all in the same
directory, sorted, and comprise all non-dotfiles (or all files,
including dotfiles — see the GLOB_DOTS option) in that directory.
However, whether that'd be practical and worth the costs (e.g., some
false positives, particularly after a user pressed 
to manually expand the glob for review) is beyond the scope of this bug
report.

> > P.S.  Compare #489646, about providing a directory for packages to drop
> > completion files into.  (That didn't involve reimplementing

Bug#969305: [Pkg-zsh-devel] Bug#969305: zsh: safe-rm needs to be added to the default path of interactive shells to work

[Daniel Shahaf]

Control: affects -1 safe-rm

Francois Marier wrote on Sun, Aug 30, 2020 at 19:50:10 -0700:
> This isn't really a bug in zsh, but rather I'd like to figure out how to
> best enable the safe-rm package for zsh users.

Thanks!

> As far as I can tell, the equivalent to protect zsh users who choose to
> install safe-rm would be to add the following to /etc/zhs/zshrc:
> 
>   if [[ -d "/usr/share/safe-rm/bin" ]]
>   then
> PATH="/usr/share/safe-rm/bin:$PATH"
> export PATH
>   fi

I guess it should be in the zprofile file, guarded by a [[ -o interactive ]] 
check.

> However, I don't see a way for packages to do this. So I guess there would
> be two ways to make this possible:
> 
> 1. The main /etc/zsh/zshrc script could source all .sh files in a new
>/etc/zsh/zshrc.d/ directory.
> 2. The /etc/zsh/zshrc that ships in Debian could include the above.
> 
> Are either of these something you'd be willing to consider?

I don't have an opinion one way or the other.

I do note that option #2 would cause a stat(2) call during shell startup
for everyone who _doesn't_ use safe-rm.  Would that be a problem?
(E.g., slower shell startup)

> Or is there another way to do this that I haven't seen?

Probably not what you had in mind, but my first instinct here is to look
for a shell-independent solution.  For example:

3. Get the OS to add /usr/share/safe-rm/bin to $PATH before the user's
shell is executed in the first place.  (On FreeBSD that'd be
login.conf(5), but I don't know what the Linux equivalent is.)

4. Use dpkg-divert(8) to replace /bin/rm with a wrapper that calls
either safe-rm or the diverted rm binary, depending on whether it's
interactive or not.

> I would really like to make it easy for zsh users to be as protected as
> bash/dash users (i.e. "apt install safe-rm" and you're done).

Thanks!

If you don't already know them, see RM_STAR_SILENT and RM_STAR_WAIT in
zshoptions(1).

Cheers,

Daniel

P.S.  Compare #489646, about providing a directory for packages to drop
completion files into.  (That didn't involve reimplementing
run-parts(1), though; it was just a matter of adding a directory to
a list of directories.)

Bug#963253: Processed: forcibly merging 963253 954772

[Daniel Shahaf]

Debian Bug Tracking System wrote on Sun, Aug 16, 2020 at 08:57:10 +:
> Processing commands for cont...@bugs.debian.org:
> 
> > forcemerge 963253 954772
> Bug #963253 [mercurial-common] mercurial-common: please install zsh 
> completion where zsh finds it
> Bug #963253 [mercurial-common] mercurial-common: please install zsh 
> completion where zsh finds it
> Marked as found in versions mercurial/5.3.1-1.
> Bug #954772 [mercurial-common] mercurial-common: Please install zsh 
> completion where zsh will find it

Oops, sorry for the duplicate!  I must've misspelled the filter pattern
in reportbug(1) when I submitted the second one.

Thanks for the fix ☺

Daniel

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Daniel Shahaf]

Package: lintian
Version: 2.83.0
Severity: wishlist
Tags: upstream

Dear Maintainer,

I noticed yesterday that the current source package of
zsh-syntax-highlighting contains a debian/upstream/signing-key.asc file
which contains an expired snapshot of upstream's signing key: the
snapshot gives the key's expiration date as 2018-06-28.¹

I then generated and built that package on a then-current sid chroot and
observed that no lintian warnings were logged about the expired key.
I invoked lintian as «lintian --display-info --display-experimental
--pedantic --color=always --no-tag-display-limit /build/*.changes
/build/*.dsc /build/*.deb».

I was wondering whether it would be a good idea for Lintian to add
a check for expired keys in debian/upstream/signing-key.asc.

Despite the name being in singular, signing-key.asc may contain multiple
keys, just like upstream tar.gz.asc files may contain multiple people's
signatures.

I am not sure what the semantics of the check should be when that file
contains multiple keys, only some of which are expired.  When upstream's
release manager (RM)'s identity changes, it can be useful to keep
carrying the outgoing RM's public key, in order to make it easier to
verify past and potential future upstream releases signed with that key.
However, someone who had stepped down from being RM might let their key
expire and not renew it until and unless they resume being the RM.

An alternative point of view is that signing-key.asc should contain only
keys that are currently in use, and older keys should be removed
(they'll still be available in archived sourced packages).  Under this
point of view, there might be room for an additional check that the keys
in signing-key.asc are indeed those keys used to sign the upstream
tarball.

Cheers,

Daniel

¹ In this particular case, upstream's key is my key, and that key has
been regularly extended (to 2020-07-01 and to 2021-12-31).  After
extending the key I re-pushed it to keyservers, but did not regenerate
the d/u/signing-key.asc export.  (I'd like to automate that regeneration,
since my key appears in multiple packages' signing-key.asc files, but
that's a question for another thread.)

Bug#960298: [Pkg-zsh-devel] Bug#960298: zsh-common: Please consider backporting new debsnap completion from upstream

[Daniel Shahaf]

Control: tags -1 pending

Daniel Shahaf wrote on Mon, 11 May 2020 15:58 +:
> It was posted in 45724, revised and committed in 45731, and has had an
> unposted followup afterwards.

I looked again and I can't find an unposted followup, so at Axel's
suggestion I pushed a backport of 45731 to the packaging repository.

Cheers,

Daniel

Bug#963253: mercurial-common: please install zsh completion where zsh finds it

[Daniel Shahaf]

Package: mercurial-common
Version: 5.4-2
Severity: wishlist
Control: affects -1 zsh-common

Dear Maintainer,

mercurial-common installs zsh completion to
/usr/share/doc/mercurial-common/examples/zsh_completion.gz.

Please install that file to /usr/share/zsh/vendor-completions/ instead,
named either "_mercurial" or "_hg", and not compressed.  This way zsh
will find it by default.

¹ The name "_mercurial" is what zsh's style guide recommends, but the
comment at the top of the file advises to name it "_hg".  It doesn't
make much difference one way or the other.)

That directory name is Debian specific.

Cheers,

Daniel

Bug#658198: Autocompletion: 'ls --n' first returns 'ls --n-g'.

[Daniel Shahaf]

A. Costa wrote on Tue, Jan 31, 2012 at 18:08:57 -0500:
> Package: zsh
> Version: 4.3.15-1
> Severity: minor
> 
> Dear Maintainer,
> 
> If I do:
> 
> ls --n
> 
> ...the first autocompletion from 'zsh' is:
> 
> ls --n-g
> 
> Of course 'ls' has no '--n-g' option.
> 

No, but it does have --no-group and --numeric-uid-gid.  It is ambiguous
which one was meant, so zsh completes the unambiguous parts and asks you
to type in the rest: that's why you get «--n-g» with the cursor
as shown.  At that point can type «o» to complete the former option
and either «u» or «-» to complete the latter.  This is due to
matchspecs, as described under the path-completion style but with
hyphens rather than slashes.  (The gory details are in the manual under
"Completion matching control".)

If anything, the bug here is that «--n-g» doesn't offer
--numeric-uid-gid, even though that option's existence was the reason
--no-group wasn't offered immediately.  However, I can't reproduce this
one when I set the «menu» style.

> A second  returns:
> 
> ls --no-group
> 
> ...which is a valid 'ls' option.

--no-group is a valid option today.

> I looked in '/usr/share/zsh/functions/Completion/Unix/_ls' for
> clues, but didn't notice anything obviously wrong.  But I'm not
> a 'zsh' expert.

_ls is fine.  The matchspecs are handled elsewhere.  (They're fetched from
a C struct by the «comparguments -M» call in _arguments.)

> Hope this helps...

It does.  Thanks for the report.

Daniel
(Better late than never…)

> 
> 
> PS: This is a spin-off bug from Bug#463507.

Bug#960298: [Pkg-zsh-devel] Bug#960298: Bug#960298: zsh-common: Please consider backporting new debsnap completion from upstream

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, 11 May 2020 16:07 +:
> Daniel Shahaf wrote on Mon, 11 May 2020 15:58 +:
> > On the heels of #953389, which added _dscverify, shall we backport the
> > newly-added _debsnap completion as well?
> > 
> > It was posted in 45724, revised and committed in 45731, and has had an
> > unposted followup afterwards.  
> 
> Current version:
> 
> https://github.com/zsh-users/zsh/blob/494f6bcb3ca00626ac66348c572a9a69d8b0af37/Completion/Debian/Command/_debsnap

Ping?

Would it help if I uploaded this to mentors.d.n?

Cheers,

Daniel

Bug#962133: [Pkg-zsh-devel] Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Daniel Shahaf]

Vincent Lefevre wrote on Thu, 04 Jun 2020 10:03 +0200:
> On 2020-06-04 03:32:49 +0000, Daniel Shahaf wrote:
> > Furthermore, I'd rather not remove code just because it's currently
> > unused in zsh.git.  The completion system — especially the Type/*
> > functions — is an API, not a blackbox.  Does the function proposed for
> > removal answer a useful question?  Might third party tools (or even
> > people's zshrc files) be using or in the future use that function?  The
> > function has already been written (and debugged, etc); how likely is it
> > that if we remove it, someone will have to reinvent the wheel?  
> 
> An issue is that deinstall can mean 2 things:
>   1. A package that has been uninstalled but not purged.
>   2. A package that is still installed but is selected for
>  deinstallation.
> 
> and that is not currently documented in _deb_packages_update_deinstalled.
> I fear that a tool that uses it is likely to be buggy.

Even so, I don't see how that's a reason to remove the function.  It's
quite common for maintainers of completion functions to have to be well
acquainted with uncommon functionalities of the tool they work on, and
"All packages that have been selected to be deinstalled" sounds (to this
not-familiar-with-dpkg(8)-internals reader) like a fair question to ask.
It might not be the _right_ question to ask in every case, but that's
a separate problem.

Note that alongside «_deb_packages deinstalled» there is also
«_deb_packages uninstalled».

It seems to me that some documentation is in order, to explain the
differences between those two functions and the related pitfalls.
While we're there, it would be nice to also explain what xinstalled does
(people shouldn't have to read the implementation of _deb_packages to
figure out the answer to that).

> > So, I agree with Axel about the _deb_packages part of the patch.
> > 
> > As to the _dpkg part of the patch, first of all, it's incomplete:
> > it removes the "listfiles" case but not the code that sets that value.  
> 
> It does not remove "listfiles", but moves it to use "xinstalled"
> instead of "installed" (perhaps I forgot to say I fixed that
> too).

My apologies.  I misread the diff.

> This listfiles command still makes sense for any package
> listed by "dpkg --get-selections", even if it has already been
> uninstalled (see above on openntpd).

So you're saying that «dpkg -L» should complete xinstalled rather than
deinstalled.  I don't know dpkg well enough to have an opinion one way
or the other.  What I will say is that if «dpkg -L foo» works, then
«dpkg -L » should offer «foo».

> > Once the latter is removed too, the function will then display a single
> > asterisk to the user instead of an actual description.  And with _that_
> > fixed, there'll still be the issue that, where possible, it's better to
> > generate completions than to just tell the user what type of thing they're
> > supposed to type in.  Incorrect or incomplete code should, if possible,
> > be corrected rather than axed.  
> 
> I don't understand what you mean.
> 

I don't understand what part you didn't understand, but in any case,
just ignore that paragraph; it was a consequent misunderstanding of my
misreading of the diff.

> > I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
> > semantics, but in general, completion should (1) offer everything that
> > the command would accept, (2) not offer things the command won't accept.  
> 
> This is what my patch corrects for the remove, status, listfiles and
> list commands.

That's great.

> > That's in descending order of priority: it's usually better to offer too
> > much than too little.  
> 
> Yes, remove, status and listfiles offered too little (only packages
> in the install or hold state). On the opposite, list offered too much
> (all packages known to apt), but for a package that is not listed by
> "dpkg --get-selections", i.e. for which no information is available
> for dpkg, I don't see how this can be useful: "dpkg --list foo",
> where foo is neither installed, nor uninstalled (but not purged),
> just returns an error.

Yes, if «dpkg -L foo» returns an error then «foo» shouldn't be
completed.

>

Axel, do you have any concerns about the _dpkg part of the patch?

Cheers,

Daniel

Bug#962133: [Pkg-zsh-devel] Bug#962133: Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, 03 Jun 2020 18:02 +0200:
> On 2020-06-03 17:45:11 +0200, Axel Beckert wrote:
> > Vincent Lefevre wrote:  
> > > Actually there's another one:
> > >   
> > > zira:~> dpkg -l | grep '^rc'  
> > > rc  openntpd   1:6.0p1-1  
> > >  amd64OpenBSD NTP daemon  
> > 
> > All packages shown as "rc" by dpkg on my system seem _not_ to be
> > installed but are usually removed, but not purged. Example:  
> 
> They are not installed, but are valid candidates for "dpkg -s"
> arguments.
> 
> > From the design of the current implementation (only show installed
> > packages for "dpkg -s" completion)  
> 
> Currently this is: installed and not marked to be uninstalled
> (or to be purged).
> 
> > it is correct that "dpkg -s" doesn't complete these packages.  
> 
> This is not correct.

Axel did not say that _dpkg's behaviour was correct.

Axel only said that _dpkg was behaving as designed.

Furthermore, in the snipped context Axel agreed that it would be
good to have _dpkg modified to behave as per your proposal.

> "dpkg -s" should complete to any valid
> argument, i.e. for which package information is available
> (thus this excludes purged packages). This is a real bug.

Bug#962133: [Pkg-zsh-devel] Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, 03 Jun 2020 21:14 +0200:
> On 2020-06-03 20:28:11 +0200, Axel Beckert wrote:
> > Daniel: Would you review it for upstream inclusion?

Sure.

> Note that this is not documented, so I thought that this was just
> internal, and 3rd party code should have its own functions.

As far as completion functions go, I'd err on the side of considering
the comment at the top of _deb_packages to be API documentation,
notwithstanding that it's only a top-of-file comment and not in the
manual.

Furthermore, I'd rather not remove code just because it's currently
unused in zsh.git.  The completion system — especially the Type/*
functions — is an API, not a blackbox.  Does the function proposed for
removal answer a useful question?  Might third party tools (or even
people's zshrc files) be using or in the future use that function?  The
function has already been written (and debugged, etc); how likely is it
that if we remove it, someone will have to reinvent the wheel?

So, I agree with Axel about the _deb_packages part of the patch.

As to the _dpkg part of the patch, first of all, it's incomplete:
it removes the "listfiles" case but not the code that sets that value.
Once the latter is removed too, the function will then display a single
asterisk to the user instead of an actual description.  And with _that_
fixed, there'll still be the issue that, where possible, it's better to
generate completions than to just tell the user what type of thing they're
supposed to type in.  Incorrect or incomplete code should, if possible,
be corrected rather than axed.

So I consider the _dpkg part of the patch a helpful debugging aid, but
I'm afraid I don't think it's ready to be merged as-is.

I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
semantics, but in general, completion should (1) offer everything that
the command would accept, (2) not offer things the command won't accept.
That's in descending order of priority: it's usually better to offer too
much than too little.

HTH.  Let me know if you have further questions ☺

Cheers,

Daniel
(no pun intended)

Bug#961757: zsh-doc: Please install the FAQ

[Daniel Shahaf]

Package: zsh-doc
Version: 5.8-4
Severity: wishlist

Dear Maintainer,

Please consider building and installing the upstream FAQ as well.

Currently, the following get installed:

usr/share/doc/zsh-common/html/The-Zsh-FAQ.html
usr/share/doc/zsh-common/META-FAQ

But neither of these is the FAQ.  The first one is a section in the
zsh(1) man page; the latter is the META-FAQ, generated from
Doc/META-FAQ.yo, as opposed to the FAQ, which is generated from,
Etc/FAQ.yo.

The following seems to do the trick, but I suspect a change to
debian/zsh-doc.doc-base is needed as well.

diff --git a/debian/rules b/debian/rules
index 557d0ee..a1b6bc3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ build-static:
 
 override_dh_auto_build-indep:
dh_auto_build -B obj -- pdf
+   $(MAKE) -C obj/Etc # FAQ
 
 override_dh_auto_test-arch:
if dpkg-architecture -qDEB_BUILD_ARCH_OS | grep -qv hurd; then \
diff --git a/debian/zsh-doc.docs b/debian/zsh-doc.docs
index 60cb238..1611c61 100644
--- a/debian/zsh-doc.docs
+++ b/debian/zsh-doc.docs
@@ -1 +1,2 @@
 obj/Doc/zsh.pdf
+obj/Etc/FAQ*

With this, the following are also built and installed:

usr/share/doc/zsh-common/FAQ06.html
usr/share/doc/zsh-common/FAQ05.html
usr/share/doc/zsh-common/FAQ04.html
usr/share/doc/zsh-common/FAQ03.html
usr/share/doc/zsh-common/FAQ02.html
usr/share/doc/zsh-common/FAQ01.html
usr/share/doc/zsh-common/FAQ.html
usr/share/doc/zsh-common/FAQ.gz

Cheers,

Daniel

Bug#954113: bug 954113 is forwarded to https://github.com/vim-perl/vim-perl/pull/286 ...

[Daniel Shahaf]

James McCoy wrote on Mon, May 11, 2020 at 22:39:14 -0400:
> forwarded 954113 https://github.com/vim-perl/vim-perl/pull/286
> forwarded 954016 https://github.com/vim-perl/vim-perl/pull/285

Thanks for extending #954113 into a proper ftplugin!  And for
upstreaming these two, of course ☺

> thanks
> 
> 

Bug#960298: [Pkg-zsh-devel] Bug#960298: zsh-common: Please consider backporting new debsnap completion from upstream

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, 11 May 2020 15:58 +:
> On the heels of #953389, which added _dscverify, shall we backport the
> newly-added _debsnap completion as well?
> 
> It was posted in 45724, revised and committed in 45731, and has had an
> unposted followup afterwards.

Current version:

https://github.com/zsh-users/zsh/blob/494f6bcb3ca00626ac66348c572a9a69d8b0af37/Completion/Debian/Command/_debsnap

Cheers,

Daniel

Bug#960298: zsh-common: Please consider backporting new debsnap completion from upstream

[Daniel Shahaf]

Package: zsh-common
Version: 5.8-4
Severity: wishlist
Tags: patch

Dear Maintainer,

On the heels of #953389, which added _dscverify, shall we backport the
newly-added _debsnap completion as well?

It was posted in 45724, revised and committed in 45731, and has had an
unposted followup afterwards.

Cheers,

Daniel

Bug#960282: [Pkg-zsh-devel] Bug#960282: Bug#960282: Bug#960282: zsh: completion error with non exsiting files since deca7c928520fba5a73383f1cac0b3ace8e0e45d

[Daniel Shahaf]

Axel Beckert wrote on Mon, 11 May 2020 17:01 +0200:
> Daniel Shahaf wrote:
> > Daniel Shahaf wrote on Mon, 11 May 2020 14:29 +:  
> > > using _arguments from git HEAD with zsh 5.8-4 [...] is not a
> > > supported use case.  
> 
> Is this something that might affect users when migrating from zsh 5.8
> to a potential 5.9, i.e. something we might need to put into NEWS.Debian?
> 

I don't think so, or I'd have added a note to the upstream README when
I committed the _arguments change upstream.  The interface between
_arguments and comparguments is an implementation detail with minimal
user-facing documentation.

> > Citation: workers/37986.  
> 
> Thanks! (see https://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=37986)
> 

Thanks for fully-fledging that link ☺

> Ok, this reads more that it is cared about backwards-compatiblity for
> 3rd party completion, but not about backwards-compatiblity to older
> zsh release for our own completions inside the zsh source, right?
> 

Correct.  The interface between completion functions and the completion
system (e.g., between _git or _curl on the one hand and _files or
_arguments on the other) _is_ an API with compatibility promises.
The interface between _arguments and comparguments, on the other hand,
is an implementation detail, so they should be upgraded in lockstep.

> (If that's right, we don't need to mention anything.)

+1

Cheers,

Daniel

Bug#960282: [Pkg-zsh-devel] Bug#960282: zsh: completion error with non exsiting files since deca7c928520fba5a73383f1cac0b3ace8e0e45d

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, 11 May 2020 14:29 +:
> using _arguments from git HEAD with zsh 5.8-4 [...] is not a
> supported use case.

Citation: workers/37986.

Cheers,

Daniel

Bug#960282: [Pkg-zsh-devel] Bug#960282: zsh: completion error with non exsiting files since deca7c928520fba5a73383f1cac0b3ace8e0e45d

[Daniel Shahaf]

> Version: 5.8-4
⋮
> _arguments:comparguments:393: too many arguments

In version 5.8-4, line 393 of _arguments doesn't call comparguments.

> after deleting $opt_args_use_NUL_separators from _arguments:

You seem to be using _arguments from git HEAD with zsh 5.8-4.  That is
not a supported use case.  Thus, either downgrade your _arguments, or
rebuild zsh (see git-archive(1) + uupdate(1)).

Not -close'ing this yet, in case I've overlooked something.

Cheers,

Daniel

Bug#956921: subversion: Debian patch last-changed-date-charset has an error leak

[Daniel Shahaf]

Source: subversion
Version: 1.13.0-3
Severity: normal
Tags: patch

Good morning James,

One of the Debian patches has a error leak:

[[[
--- debian/patches/last-changed-date-charset
+++ debian/patches/last-changed-date-charset
@@ -24,7 +24,7 @@ index c8c3018..b69f90a 100644
 +  {
 +  char *date_keyword;
 +  char *date_utf8 = svn_time_to_human_cstring (date, pool);
-+  svn_utf_cstring_from_utf8(_keyword, date_utf8, pool);
++  SVN_ERR(svn_utf_cstring_from_utf8(_keyword, date_utf8, 
pool));
 +  svn_stringbuf_appendcstr(value, date_keyword);
 +}
break;
]]]

Cheers,

Daniel

Bug#956497: ristretto: 25 seconds delay when org.Xfce.FileManager isn't available

[Daniel Shahaf]

Control: retitle -1 ristretto: 25 seconds delay when org.Xfce.FileManager isn't 
available

Daniel Shahaf wrote on Sun, Apr 12, 2020 at 03:59:07 +:
>   I captured a backtrace (from a different ristretto run, because lldb
>   failed to attached to the strace'd run):
> 
>   * thread #1, name = 'ristretto', stop reason = signal SIGSTOP
> * frame #0: 0x76ba0819 
> libc.so.6`__GI___poll(fds=0x55648720, nfds=1, timeout=25000) at 
> poll.c:29 
>
>   frame #1: 0x7762b136 
> libglib-2.0.so.0`___lldb_unnamed_symbol193$$libglib-2.0.so.0 + 374

Oops, I overlooked the library's dbgsym package.  Here's a more complete
backtrace:

* thread #1, name = 'ristretto', stop reason = signal SIGSTOP
  * frame #0: 0x76ba0819 libc.so.6`__GI___poll(fds=0x55646b30, 
nfds=1, timeout=25000) at poll.c:29
frame #1: 0x7762b136 libglib-2.0.so.0`g_main_context_iterate at 
gmain.c:4221
frame #2: 0x7762b110 
libglib-2.0.so.0`g_main_context_iterate(context=0x55647af0, 
block=, dispatch=1, self=) at gmain.c:3915
frame #3: 0x7762b4c2 
libglib-2.0.so.0`g_main_loop_run(loop=0x55647880) at gmain.c:4116
frame #4: 0x778a1b53 
libgio-2.0.so.0`initable_init(initable=0x5562a5f0, 
cancellable=0x, error=0x) at gdbusproxy.c:1950
frame #5: 0x778118c2 
libgio-2.0.so.0`g_initable_new_valist(object_type=, 
first_property_name="g-flags", var_args=0x7fffe180, 
cancellable=0x, error=0x) at ginitable.c:248
frame #6: 0x77811979 
libgio-2.0.so.0`g_initable_new(object_type=, 
cancellable=, error=, 
first_property_name=) at ginitable.c:162
frame #7: 0x778a34fc 
libgio-2.0.so.0`g_dbus_proxy_new_for_bus_sync(bus_type=G_BUS_TYPE_SESSION, 
flags=G_DBUS_PROXY_FLAGS_NONE, info=0x, 
name="org.xfce.FileManager", object_path="/org/xfce/FileManager", 
interface_name="org.xfce.FileManager", cancellable=0x, 
error=0x) at gdbusproxy.c:2257
frame #8: 0x55575ef5 
ristretto`rstto_main_window_init(window=0x555d9260) at main_window.c:809
frame #9: 0x77730107 
libgobject-2.0.so.0`g_type_create_instance(type=) at gtype.c:1864
frame #10: 0x77712548 
libgobject-2.0.so.0`g_object_new_internal(class=0x55627080, 
params=0x, n_params=0) at gobject.c:1805
frame #11: 0x77713cc5 
libgobject-2.0.so.0`g_object_new_with_properties(object_type=93824992996720, 
n_properties=0, names=0x, values=0x) at 
gobject.c:1973
frame #12: 0x77714731 
libgobject-2.0.so.0`g_object_new(object_type=, 
first_property_name=) at gobject.c:1645
frame #13: 0x55578f5a 
ristretto`rstto_main_window_new(image_list=0x555a95a0, fullscreen=0) at 
main_window.c:1263
frame #14: 0x55566c74 ristretto`main(argc=, 
argv=) at main.c:134
frame #15: 0x76ad609b 
libc.so.6`__libc_start_main(main=(ristretto`main at main.c:86), argc=1, 
argv=0x7fffe828, init=, fini=, 
rtld_fini=, stack_end=0x7fffe818) at libc-start.c:308
frame #16: 0x55566e0a ristretto`_start + 42

I used dbus-send(1) [1] to list the available DBus services.  The
"org.xfce.FileManager" service is available when I run ristretto under
xfce but not available when I run ristretto under openbox.  However, if
I use openbox and run —
.
% thunar&
[1] 8868
% ristretto
.
— in an empty directory, then ristretto starts with no delay.

I added «thunar --daemon &» to my .xinitrc and the delay does not occur
any more.

I suppose all that remains is to improve the startup behaviour when the
"org.xfce.FileManager" service isn't available — for example, by
shortening the delay, or adding a progress dialog, etc..

Thanks,

Daniel

[1] «dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus 
org.freedesktop.DBus.ListNames»

Bug#956497: ristretto: 25 seconds delay when starting under openbox

[Daniel Shahaf]

Package: ristretto
Version: 0.8.3-1
Severity: important

Dear Maintainer,

When I run «ristretto» under Openbox, there is a 25s delay before the
window opens.  That doesn't happen under XFCE.

- I tried to run ristretto with and without command-line arguments.
  That did not affect the outcome.  At the time, the current working
  directory contained one *.png file (sized 1.2MB) and nothing else.

- I timed the delay with a wallclock.  It was approximately 25 seconds.

- I ran «strace ristretto» (without any other arguments).  A delay
  occurs at this point:

  openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 10
  fstat(10, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
  fstat(10, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
  read(10, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 
4096) = 127
  lseek(10, -71, SEEK_CUR)= 56
  read(10, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 
4096) = 71
  close(10)   = 0
  brk(0x55fccb38d000) = 0x55fccb38d000
  brk(0x55fccb38c000) = 0x55fccb38c000
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb313320, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 10
  write(10, "\1\0\0\0\0\0\0\0", 8)= 8
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb313320, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  poll([{fd=10, events=POLLIN}], 1, 25000) = 1 ([{fd=10, revents=POLLIN}])
  read(10, "\1\0\0\0\0\0\0\0", 16)= 8
  poll([{fd=10, events=POLLIN}], 1, 25000^Cstrace: Process 4556 detached
   

  I captured a backtrace (from a different ristretto run, because lldb
  failed to attached to the strace'd run):

  * thread #1, name = 'ristretto', stop reason = signal SIGSTOP
* frame #0: 0x76ba0819 
libc.so.6`__GI___poll(fds=0x55648720, nfds=1, timeout=25000) at 
poll.c:29   
 
  frame #1: 0x7762b136 
libglib-2.0.so.0`___lldb_unnamed_symbol193$$libglib-2.0.so.0 + 374
  frame #2: 0x7762b4c2 libglib-2.0.so.0`g_main_loop_run + 178
  frame #3: 0x778a1b53 
libgio-2.0.so.0`___lldb_unnamed_symbol2705$$libgio-2.0.so.0 + 243
  frame #4: 0x778118c2 libgio-2.0.so.0`g_initable_new_valist + 146
  frame #5: 0x77811979 libgio-2.0.so.0`g_initable_new + 153
  frame #6: 0x778a34fc 
libgio-2.0.so.0`g_dbus_proxy_new_for_bus_sync + 236
  frame #7: 0x55575ef5 
ristretto`rstto_main_window_init(window=0x555d9260) at 
main_window.c:809   
  
  frame #8: 0x77730107 libgobject-2.0.so.0`g_type_create_instance + 
775
  frame #9: 0x77712548 
libgobject-2.0.so.0`___lldb_unnamed_symbol123$$libgobject-2.0.so.0 + 744
  frame #10: 0x77713cc5 
libgobject-2.0.so.0`g_object_new_with_properties + 757
  frame #11: 0x77714731 libgobject-2.0.so.0`g_object_new + 193
  frame #12: 0x55578f5a 
ristretto`rstto_main_window_new(image_list=0x555a95a0, fullscreen=0) at 
main_window.c:1263  

  frame #13: 0x55566c74 ristretto`main(argc=, 
argv=) at main.c:134
  frame #14: 0x76ad609b 
libc.so.6`__libc_start_main(main=(ristretto`main at main.c:86), argc=1, 
argv=0x7fffe6e8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6d8) at libc-start.c:308
  frame #15: 0x55566e0a ristretto`_start + 42

- The delay occurs when I run ristretto under Openbox (using «startx
  openbox» after logging in on a Ctrl+Alt+F tty, without a login
  manager), but does not occur when I run ristretto under XFCE.

- This used to work fine.  I don't remember when it last worked, but
  that may well have been on stretch.  (I'm currently on buster.)

- I have not tested 0.10.0-1, since I do not have a testing or sid
  headful VM.  However, I did check the bug trackers and changelogs,
  both Debian's and upstream's, and found no relevant matches.

It would seem that the last poll(2) call times out while reading from
the eventfd2() fd.

I would be grateful for a workaround for getting rid of the delay.

Cheers,

Daniel


-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: 

Bug#955186: pbuilder: please have --login run the default login shell, when not bash

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, Mar 28, 2020 at 01:50:38 +:
> Please execute the passwd(5)-specified login shell by default.
> 
> The following works for me, but please review.
> 

Need to set $SHELL too.  Revised patch:

[[[
diff --git a/pbuilder b/pbuilder
index ccd7cc0..3067656 100755
--- a/pbuilder
+++ b/pbuilder
@@ -74,7 +74,8 @@ case "$1" in
 fi
 
 executehooks "F"
-(${CHROOTEXEC} bash -c 'exec -a -bash bash')
+loginshell=$(${CHROOTEXEC} getent passwd root | cut -d: -f7)
+(${CHROOTEXEC} bash -c 'export SHELL="$1"; exec -a "-$1" "$1"' . 
"${loginshell}")
 RET=$?
 
 save_aptcache
]]]

Thanks,

Daniel

Bug#955186: pbuilder: please have --login run the default login shell, when not bash

[Daniel Shahaf]

Package: pbuilder
Version: 0.230.4
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

«pbuilder --login» is implemented as follows:

58  --login|login|l)
⋮
76  executehooks "F"
77  (${CHROOTEXEC} bash -c 'exec -a -bash bash')
78  RET=$?

This launches bash even if the chroot's /etc/passwd specifies another
shell.

Please execute the passwd(5)-specified login shell by default.

The following works for me, but please review.

[[[
diff --git a/pbuilder b/pbuilder
index ccd7cc0..3067656 100755
--- a/pbuilder
+++ b/pbuilder
@@ -74,7 +74,8 @@ case "$1" in
 fi
 
 executehooks "F"
-(${CHROOTEXEC} bash -c 'exec -a -bash bash')
+loginshell=$(${CHROOTEXEC} getent passwd root | cut -d: -f7)
+(${CHROOTEXEC} bash -c 'exec -a "-$1" "$1"' . "${loginshell}")
 RET=$?
 
 save_aptcache
]]]

Cheers,

Daniel

P.S. For completeness, my use-case: I have an F hook that chsh's to zsh
because I'd like --login sessions to use zsh by default.

Bug#954772: mercurial-common: Please install zsh completion where zsh will find it

[Daniel Shahaf]

Package: mercurial-common
Version: 5.3.1-1
Severity: normal
Control: affects -1 zsh-common

Dear Maintainer,

mercurial-common installs contrib/zsh_completion to 
/usr/share/doc/mercurial-common/examples/zsh_completion.gz.

Please install it to /usr/share/zsh/vendor-completions, uncompressed.
This way zsh will find it without any special configuration on the
user's part.

(That directory name is specific to Debian; it doesn't exist on other
distros.  Upstreams' build processes should install zsh completions to
/usr/local/share/zsh/site-functions by default.)

Cheers,

Daniel

Bug#954016: vim-runtime: tap.vim: Make "TODO" and "SKIP" case-insensitive

[Daniel Shahaf]

Daniel Shahaf wrote on Sun, Mar 15, 2020 at 18:59:29 +:
> P.S. I think there are at least two other bugs in tap.vim: (1) As
> mentioned above, TAP syntax is not highlighted unless there is an empty
> line above the plan line; (2) syntax/tap.vim sets various fold.* options
> globally, rather than locally and via an ftplugin.  However, let's keep
> this ticket about the skip case-sensitivity thing only.

For the curious, I worked around this by adding «autocmd FileType tap
syn clear tapTestInstructionsRegion tapTestRegion» to my .vimrc and
locally applying the patch from #954113.

> Please find attached a patch that lets those keywords be matched case
> insensitively:

That's still applicable.

Cheers,

Daniel

Bug#954113: vim-runtime: tap.vim: Don't clobber global settings of fold.* options

[Daniel Shahaf]

Package: vim
Version: 2:8.2.0368-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

syntax/tap.vim uses «:set foo» to set window-local options.

That changes the default setting of those options for new buffers.

Here is a patch to fix that:

[[[
diff --git a/runtime/syntax/tap.vim b/runtime/syntax/tap.vim
index db37bb8..b2f00ad 100644
--- a/runtime/syntax/tap.vim
+++ b/runtime/syntax/tap.vim
@@ -51,17 +51,17 @@ syn region tapTestResultsSummaryNotOK start=/TODO passed:/ 
end=/$/ contained
 
 syn region tapTestInstructionsRegion start=/\%1l/ end=/^$/
 
-set foldtext=TAPTestLine_foldtext()
+setl foldtext=TAPTestLine_foldtext()
 function! TAPTestLine_foldtext()
 let line = getline(v:foldstart)
 let sub = substitute(line, '/\*\|\*/\|{{{\d\=', '', 'g')
 return sub
 endfunction
 
-set foldminlines=5
-set foldcolumn=2
-set foldenable
-set foldmethod=syntax
+setl foldminlines=5
+setl foldcolumn=2
+setl foldenable
+setl foldmethod=syntax
 syn sync fromstart
 
 if !exists("did_tapverboseoutput_syntax_inits")
]]]

Cheers,

Daniel

Bug#954016: vim-runtime: tap.vim: Make "TODO" and "SKIP" case-insensitive

[Daniel Shahaf]

Package: vim
Version: 2:8.2.0368-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

   * What led up to the situation?

According to the TAP specification, the keywords "TODO" and "SKIP" are
case-insensitive:

https://testanything.org/tap-specification.html#directives
Directives are special notes that follow a # on the test line. Only
two are currently defined: TODO and SKIP. Note that these two
keywords are not case-sensitive.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Please find attached a patch that lets those keywords be matched case
insensitively:

[[[
diff --git a/runtime/syntax/tap.vim b/runtime/syntax/tap.vim
index db37bb8..10b1f1e 100644
--- a/runtime/syntax/tap.vim
+++ b/runtime/syntax/tap.vim
@@ -29,12 +29,12 @@ syn match tapTestStatusOK /ok/ contained
 syn match tapTestStatusNotOK /not ok/ contained
 
 " highlight todo tests
-syn match tapTestTodo /\(# TODO\|Failed (TODO)\) .*$/ contained 
contains=tapTestTodoRev
-syn match tapTestTodoRev /\/ contained
+syn match tapTestTodo /\c\(# TODO\|Failed (TODO)\) .*$/ contained 
contains=tapTestTodoRev
+syn match tapTestTodoRev /\c\/ contained
 
 " highlight skipped tests
-syn match tapTestSkip /# skip .*$/ contained contains=tapTestSkipTag
-syn match tapTestSkipTag /\(# \)\@<=skip\>/ contained
+syn match tapTestSkip /\c# skip .*$/ contained contains=tapTestSkipTag
+syn match tapTestSkipTag /\c\(# \)\@<=skip\>/ contained
 
 " look behind so "ok 123" and "not ok 124" match test number
 syn match tapTestNumber /\(ok \)\@<=\d\d*/ contained
]]]

Here is a test file where the behaviour change may be observed:

[[[
$ cat test.tap
# make sure to have an empty line above the plan line!

1..3
ok 1
ok 2 # TODO foo
ok 3 # SKIP bar
$ 
]]]

Thanks,

Daniel

P.S. I think there are at least two other bugs in tap.vim: (1) As
mentioned above, TAP syntax is not highlighted unless there is an empty
line above the plan line; (2) syntax/tap.vim sets various fold.* options
globally, rather than locally and via an ftplugin.  However, let's keep
this ticket about the skip case-sensitivity thing only.

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Guillem Jover wrote on Sat, 14 Mar 2020 22:51 +00:00:
> Hi!
> 
> On Sat, 2020-03-14 at 21:49:12 +0000, Daniel Shahaf wrote:
> > Sean Whitton wrote on Sat, 14 Mar 2020 20:39 +00:00:
> > > On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:
> > > > Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> > > >> -   ::
> > > >> -
> > > >> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> > > >> -
> > > >> +   All of the bug numbers listed must be given on the same physical 
> > > >> line
> > > >> +   as the word ``closes:``.
> > > >
> > > > Is this newly-added sentence correct?
> > > >
> > > > Whether it correctly states the semantics of the regexp depends on
> > > > whether the regexp is matched against the changelog entry as a single
> > > > multiline string or line-by-line.  In the former case, the list of bug
> > > > numbers would be allowed to span multiple lines, but in the latter case
> > > > it wouldn't.
> > > >
> > > > Currently, the patch assumes all bug numbers should be on the same line,
> > > > but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> > > > span multiple lines.  I'm guessing the syntax file is right and the 
> > > > patch should
> > > > be changed?
> > > 
> > > In PCREs \s matches the newline character so I believe your text is
> > > incorrect.
> > 
> > I agree that it is probably incorrect, but that doesn't follow from the
> > semantics of /\s/.  Even if /\s/ matched any single byte/character, the
> > semantics would still depend on what haystack the regexp is matched
> > against: the entire changelog entry, or one line thereof at a time.
> 
> It is definitely incorrect. The canonical implementation is currently
> in libdpkg-perl's Dpkg::Changelog::Entry::Debian::find_closes(), where
> the entire changelog entry is passed as a single string, so something
> like this is perfectly fine:
> 
> Closes:
>   #12345,
>   #67890,
>   #5
> 

Thanks for the review and the pointer to the source of truth!

> AFAIK, DAK only operates based on the Closes field in the .changes
> file. I'll clarify the regex also in the deb-changelog(5) man page.
> 
> Thanks,
> Guillem

Cheers,

Daniel

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Sean Whitton wrote on Sat, 14 Mar 2020 20:39 +00:00:
> Hello,
> 
> On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:
> 
> > Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> >> -   ::
> >> -
> >> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> >> -
> >> +   All of the bug numbers listed must be given on the same physical line
> >> +   as the word ``closes:``.
> >
> > Is this newly-added sentence correct?
> >
> > Whether it correctly states the semantics of the regexp depends on
> > whether the regexp is matched against the changelog entry as a single
> > multiline string or line-by-line.  In the former case, the list of bug
> > numbers would be allowed to span multiple lines, but in the latter case
> > it wouldn't.
> >
> > Currently, the patch assumes all bug numbers should be on the same line,
> > but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> > span multiple lines.  I'm guessing the syntax file is right and the patch 
> > should
> > be changed?
> 
> In PCREs \s matches the newline character so I believe your text is
> incorrect.

I agree that it is probably incorrect, but that doesn't follow from the
semantics of /\s/.  Even if /\s/ matched any single byte/character, the
semantics would still depend on what haystack the regexp is matched
against: the entire changelog entry, or one line thereof at a time.

Here's a revision of the patch incorporating the feedback so far:

[[[
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1d870d9..1c71525 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -151,9 +151,9 @@ used here to separate groups of changes, if desired.
 If this upload resolves bugs recorded in the Bug Tracking System (BTS),
 they may be automatically closed on the inclusion of this package into
 the Debian archive by including the string: ``closes:  Bug#n`` in
-the change details.  [#]_ This information is conveyed via the
-``Closes`` field in the ``.changes`` file (see
-:ref:`s-f-Closes`).
+the change details, where ``#n`` is the bug number.  [#]_ This
+information is conveyed via the ``Closes`` field in the ``.changes``
+file (see :ref:`s-f-Closes`).
 
 The maintainer name and email address used in the changelog should be
 the details of the person who prepared this release of the package. They
@@ -860,10 +860,19 @@ should not exist a file ``debian/patches/foo.series`` for 
any ``foo``.
 
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
 
-   Then all of the bug numbers listed will be closed by the archive
+   That is: The string should consist of the word ``closes:`` followed by
+   a comma-separated list of bug numbers. Bug numbers may be preceded by
+   the word ``bug`` and/or a ``#`` sign, as in
+   ``Closes: 42, bug#43, #44, bug 45``.
+   
+   The list of bug numbers may span multiple lines.
+
+   All of the bug numbers listed will be closed by the archive
maintenance software (``dak``) using the version of the changelog
entry.
 
+   The words ``closes:`` and ``bug`` are not case sensitive.
+
 .. [#]
In the case of a sponsored upload, the uploader signs the files, but
the changelog maintainer name and address are those of the person who
]]]

Cheers,

Daniel

Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 19:57 +00:00:
> ...

Sorry for the noise!  I typo'd the bug number in the To: header ☹

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> -   ::
> -
> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> -
> +   All of the bug numbers listed must be given on the same physical line
> +   as the word ``closes:``.

Is this newly-added sentence correct?

Whether it correctly states the semantics of the regexp depends on
whether the regexp is matched against the changelog entry as a single
multiline string or line-by-line.  In the former case, the list of bug
numbers would be allowed to span multiple lines, but in the latter case
it wouldn't.

Currently, the patch assumes all bug numbers should be on the same line,
but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
span multiple lines.  I'm guessing the syntax file is right and the patch should
be changed?

Cheers,

Daniel

Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> -   ::
> -
> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> -
> +   All of the bug numbers listed must be given on the same physical line
> +   as the word ``closes:``.

Is this newly-added sentence correct?

Whether it correctly states the semantics of the regexp depends on
whether the regexp is matched against the changelog entry as a single
multiline string or line-by-line.  In the former case, the list of bug
numbers would be allowed to span multiple lines, but in the latter case
it wouldn't.

Currently, the patch assumes all bug numbers should be on the same line,
but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
span multiple lines.  I'm guessing the syntax file is right and the patch should
be changed?

Cheers,

Daniel

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Sean Whitton wrote on Sat, 14 Mar 2020 19:06 +00:00:
> Hello Daniel,
> 
> On Sat 14 Mar 2020 at 06:14PM +00, Daniel Shahaf wrote:
> 
> > The documentation of the "Closes: #NN" changelog syntax describes
> > the syntax in terms of a Perl regular expression.  However, not all
> > readers know Perl.  I suggest to describe the semantics in English,
> > in addition to or instead of the description in Perl.
> 
> How about including both the Perl and the English, to make things easier
> for the maximum number of people?

Sure, we could do that.

What shape would this take?  Would the Perl definition be authoritative
and the English one informative, or vice versa?  (Or something else
altogether?)

I think both options are workable, and I have no preference between them.

Cheers,

Daniel

> Removing the Perl strikes me as deleting something which could be very
> useful to someone (e.g. if they're writing a script of some kind).

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Package: debian-policy
Version: 4.5.0.0
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

The documentation of the "Closes: #NN" changelog syntax describes
the syntax in terms of a Perl regular expression.  However, not all
readers know Perl.  I suggest to describe the semantics in English,
in addition to or instead of the description in Perl.

Cheers,

Daniel

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1d870d9..46fca24 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -151,9 +151,9 @@ used here to separate groups of changes, if desired.
 If this upload resolves bugs recorded in the Bug Tracking System (BTS),
 they may be automatically closed on the inclusion of this package into
 the Debian archive by including the string: ``closes:  Bug#n`` in
-the change details.  [#]_ This information is conveyed via the
-``Closes`` field in the ``.changes`` file (see
-:ref:`s-f-Closes`).
+the change details, where ``#n`` is the bug number.  [#]_ This
+information is conveyed via the ``Closes`` field in the ``.changes``
+file (see :ref:`s-f-Closes`).
 
 The maintainer name and email address used in the changelog should be
 the details of the person who prepared this release of the package. They
@@ -853,17 +853,21 @@ should not exist a file ``debian/patches/foo.series`` for 
any ``foo``.
maintain the package as a non-native package.
 
 .. [#]
-   To be precise, the string should match the following Perl regular
-   expression:
+   To be precise, the string should consist of the word ``closes:``
+   followed by a comma-separated list of bug numbers. Bug numbers
+   may be preceded by the word ``bug`` and/or a ``#`` sign, as in
+   ``Closes: 42, bug#43, #44, bug 45``.
 
-   ::
-
-   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
-
-   Then all of the bug numbers listed will be closed by the archive
+   All of the bug numbers listed will be closed by the archive
maintenance software (``dak``) using the version of the changelog
entry.
 
+   All of the bug numbers listed must be given on the same physical line
+   as the word ``closes:``. However, a single changelog entry may contain
+   multiple ``closes:`` directives.
+
+   The words ``closes:`` and ``bug`` are not case sensitive.
+
 .. [#]
In the case of a sponsored upload, the uploader signs the files, but
the changelog maintainer name and address are those of the person who

Bug#953805: zsh-syntax-highlighting: Please make another source-only upload to allow testing migration

[Daniel Shahaf]

Boyuan Yang wrote on Fri, 13 Mar 2020 13:55 -0400:
> Source: zsh-syntax-highlighting
> Version: 0.7.1-1
> Severity: important
> X-Debbugs-CC: danie...@apache.org
> 
> Dear zsh-syntax-highlighting maintainers,
> 
> The latest upload of your package was not a source-only upload. As a result,
> it will not migrate to Testing.
> 
> Please consider making another source-only upload to solve this problem, as
> suggested in https://wiki.debian.org/SourceOnlyUpload . Feel free to let me
> know if there's any questions.
> 

Should be fixed now.

Thanks for the report!

Daniel

Bug#953732: debian-security-support: revert unintentional output change in #951874 4/4

[Daniel Shahaf]

Package: debian-security-support
Version: 2020.03.05
Severity: minor
Tags: patch upstream

Dear Maintainer,

Commit df738471cce07f946671aea7ae72db74f28a2ee6 (bug #951874 patch 4/4)
caused an unintentional output change:

% dash -c 'echo "\n"' | xxd
: 0a0a ..
% dash -c 'echo ""' | xxd 
: 0a   .
% 

The following patch fixes the regression:

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>From 251a86c34a53fa22e8c05411354fed92ab7425d1 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Thu, 12 Mar 2020 16:58:04 +
Subject: [PATCH] Fix output regression: restore empty line inadvertently
 removed by #951874.

---
 check-support-status.in | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/check-support-status.in b/check-support-status.in
index f33f16e..c55bd46 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -297,30 +297,30 @@ if [ -z "$NOHEADING" ] ; then
 earlyend)
 gettext \
 "Future end of support for one or more packages"
-echo ""
+echo; echo
 gettext \
 "Unfortunately, it will be necessary to end security support for some packages 
before the end of the regular security maintenance life cycle." | $FOLD
-echo ""
+echo; echo
 gettext \
 "The following packages found on this system are affected by this:" ; echo
 ;;
 ended)
 gettext \
 "Ended security support for one or more packages"
-echo ""
+echo; echo
 gettext \
 "Unfortunately, it has been necessary to end security support for some 
packages before the end of the regular security maintenance life cycle." | $FOLD
-echo ""
+echo; echo
 gettext \
 "The following packages found on this system are affected by this:" ; echo
 ;;
 limited)
 gettext \
 "Limited security support for one or more packages"
-echo ""
+echo; echo
 gettext \
 "Unfortunately, it has been necessary to limit security support for some 
packages." | $FOLD
-echo ""
+echo; echo
 gettext \
 "The following packages found on this system are affected by this:" ; echo
 ;;

I note the test suite did not catch this regression.

Cheers,

Daniel

Bug#953389: [Pkg-zsh-devel] Processed: Fwd: [zsh:code] New commit [0d7f88] by Romain Porte

[Daniel Shahaf]

Debian Bug Tracking System wrote on Tue, 10 Mar 2020 15:48 +00:00:
> Processing commands for cont...@bugs.debian.org:
> > tag 953389 fixed-upstream
> Bug #953389 [zsh-common] zsh-common: completion for dscverify is missing
> Added tag(s) fixed-upstream.

The upstream commit hash was recorded in the message to control@ below
the «thanks» line:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953389;msg=38

Cheers,

Daniel

> > thanks
> Stopping processing here.
> > ⋮

Bug#953389: [Pkg-zsh-devel] Bug#953389: Bug#953389: zsh-common: completion for dscverify is missing

[Daniel Shahaf]

Control: forwarded -1 workers/45524

Romain Porte wrote on Mon, 09 Mar 2020 14:45 +00:00:
> 09/03/2020 15:04, Daniel Shahaf :
> >> +'*:dsc file:_files -g "*.{changes,dsc}(-.)"'
> > In this line —
> >
> > 1. You may need to change «{foo,bar}» to «(foo|bar)» to avoid NO_MATCH 
> > errors
> > when foo exists but bar doesn't.  (Once you do this, you may then need to
> > change «(-.)» to «(#q-.)».)
> Tried this change locally, and the completion was not working anymore.
> Back to the v2 version, when I "rm *.dsc" in a test directory so that
> only *.changes files are present, I did not get any NO_MATCH error. The
> completion just went fine on *.changes files. Maybe I am missing
> something, but this modification is not included in attached v3 patch
> (version I am sending to zsh-workers).

+1.  I think the reason it works with brace expansion is that compinit
sets the NULLGLOB option (in $_comp_options).  TIL :-)

I'll merge the patch upstream after giving -workers@ a chance to review.

Cheers,

Daniel

Bug#953389: [Pkg-zsh-devel] Bug#953389: Bug#953389: zsh-common: completion for dscverify is missing

[Daniel Shahaf]

Romain Porte wrote on Mon, Mar 09, 2020 at 10:33:29 +0100:
> Hello,
> 
> 09/03/2020 02:51, Daniel Shahaf :
> > Thanks.  Upstreaming would consist of emailing the patch to
> > zsh-work...@zsh.org and updating the metadata on this bug.  However,
> > have you considered proposing the completion for inclusion in
> > devscripts, alongside dscverify(1) and its bash completion?  devscripts
> > would just need to drop the completion file to 
> > /usr/share/zsh/vendor-completions/
> > when installing.
> 
> I have found that all the devscripts completion are coming from upstream
> directly, as you can check by inspecting the source package. I do not
> want to make an exception for dscverify completion to be shipped by
> devscripts while all other devscripts completions are coming from upstream.
> 
> This has its pros and cons. I think pro is everyone based on dpkg gets
> the completions even without devscripts installed (maybe Ubuntu and
> such?) but con is that the completions can get outdated quickly as they
> live outside of the devscripts source package. We can see this by the
> currently open bugs on zsh-common about outdated devscripts completions.
> 
> A debate can be made, but I think it is outside of the scope of this
> contribution. People from devscripts and upstream zsh should be involved
> in the discussion.

Well said, and I agree.

> All done, see attached v2 patch. You proposal for CURRENT == 2 worked
> fine, when I pass another option then the --no-conf suggestion
> disappears. Multiple keyring option seems possible, because according to
> strace each --keyring  is performing a fstat(file).
> 
> Thanks for your feedback and have a nice day,

Thanks, v2 looks good.  Would you please post it to zsh-work...@zsh.org?
I could just commit it upstream, but I'd like to have a second pair of eyes
over it.

> +'*:dsc file:_files -g "*.{changes,dsc}(-.)"'

In this line —

1. You may need to change «{foo,bar}» to «(foo|bar)» to avoid NO_MATCH errors
when foo exists but bar doesn't.  (Once you do this, you may then need to
change «(-.)» to «(#q-.)».)

2. Add "buildinfo" alongside "changes" and "dsc".

Sorry for not catching these before.

Thanks,

Daniel

Bug#953389: [Pkg-zsh-devel] Bug#953389: zsh-common: completion for dscverify is missing

[Daniel Shahaf]

Control: tags -1 confirmed
Control: affects -1 devscripts

Romain Porte wrote on Sun, 08 Mar 2020 21:50 +0100:
> I would be happy to help in the upstreaming process if you find it
> welcome. I prefer to create this bug first to avoid duplicate work
> and because this completion is Debian-specific, but I think it can
> be upstreamed easily given the other already-present completions.

Thanks.  Upstreaming would consist of emailing the patch to
zsh-work...@zsh.org and updating the metadata on this bug.  However,
have you considered proposing the completion for inclusion in
devscripts, alongside dscverify(1) and its bash completion?  devscripts
would just need to drop the completion file to 
/usr/share/zsh/vendor-completions/
when installing.

> diff -u -N --recursive ../zsh-5.8.orig/Completion/Debian/Command/_dscverify 
> ./Completion/Debian/Command/_dscverify
> --- ../zsh-5.8.orig/Completion/Debian/Command/_dscverify  1970-01-01 
> 01:00:00.0 +0100
> +++ ./Completion/Debian/Command/_dscverify2020-03-08 21:36:53.897794438 
> +0100
> @@ -0,0 +1,19 @@
> +#compdef dscverify
> +
> +_dscverify() {
> +  all_opts=(

Make the variable local.

> +'--help[show the help message and exit]'
> +'--version[show the version + copyright and exit]'
> +'--no-default-keyrings[do not check against de default keyrings]'

s/de/the/

> +'--keyring[Add keyring to the list of keyrings used]:keyring:_files -g 
> "*.{kbx,gpg}(-.)"'

s/Add/add/ (see Etc/completion-style-guide)

Change «--keyring» to «*--keyring» if the option can be specified
multiple times.

> +'(--nosigcheck --no-sig-check -u)'{--nosigcheck,--no-sig-check,-u}'[do 
> not verify the GPG signature]'
> +'(--no-conf --noconf)'{--no-conf,--noconf}'[do not read the devscripts 
> config file]'

According to the man page on stable, --no-conf "can only be used as the
first option on the command line".  Perhaps only add this variable to
$all_opts when «(( CURRENT == 2 ))»?  (Double-check me on this; I may be
misremembering the zshcompwid(1) variables' semantics.)

> +'--verbose[do not suppress GPG output]'
> +'*:dsc file:_files -g "*.{changes,dsc}(-.)"'
> +  )
> +
> +  _arguments \
> +"$all_opts[@]"
> +}
> +
> +_dscverify "$@"

If upstreaming this, could you state in a comment the version of
devscripts the completion was based on?  This is helpful when updating
completion functions down the road.

Thanks for the patch,

Daniel

Bug#952283: Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Pirate Praveen wrote on Mon, 24 Feb 2020 10:18 +0530:
> On Sun, 23 Feb 2020 18:03:30 +0000 Daniel Shahaf  wrote:
> > Holger Levsen wrote on Sun, 23 Feb 2020 16:21 +:  
> > > On Sun, Feb 23, 2020 at 03:51:58PM +0000, Daniel Shahaf wrote:  
> > > > Alternatively, how about deleting the «exit 0» line entirely?  That
> > > > would effectively downgrade the error message to a warning.
> > > 
> > > sounds better to me.  
> > 
> > Okay.  I've already filed #952283 (Cc'd) for this.
> 
> Seems you got the bug number wrong here.

Yeah, I meant #952383.  Sorry!

Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Daniel Shahaf wrote on Sun, 23 Feb 2020 18:03 +:
> Holger Levsen wrote on Sun, 23 Feb 2020 16:21 +:
> > On Sun, Feb 23, 2020 at 03:51:58PM +0000, Daniel Shahaf wrote:  
> > > Alternatively, how about deleting the «exit 0» line entirely?  That
> > > would effectively downgrade the error message to a warning.
> > 
> > sounds better to me.  
> 
> Okay.  I've already filed #952283 (Cc'd) for this.

Correction: #952383.

> What else needs to be done here, then?  I guess someone should audit
> the remainder of the script to make sure nothing will break when
> DEBIAN_VERSION isn't a recognized value?  That'd be above my
> paygrade, I'm afraid.  (I don't know what was assumed to be true due
> to the DEBIAN_VERSION check having succeeded.)
> 
> Cheers,
> 
> Daniel
> 

Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Holger Levsen wrote on Sun, 23 Feb 2020 16:21 +:
> On Sun, Feb 23, 2020 at 03:51:58PM +0000, Daniel Shahaf wrote:
> > Alternatively, how about deleting the «exit 0» line entirely?  That
> > would effectively downgrade the error message to a warning.  
> 
> sounds better to me.

Okay.  I've already filed #952283 (Cc'd) for this.  What else needs to
be done here, then?  I guess someone should audit the remainder of the
script to make sure nothing will break when DEBIAN_VERSION isn't
a recognized value?  That'd be above my paygrade, I'm afraid.  (I don't
know what was assumed to be true due to the DEBIAN_VERSION check having
succeeded.)

Cheers,

Daniel

Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Control: clone -1 -2
Control: retitle -2 debian-security-support: Returns EXIT_SUCCESS without doing 
any work when the DEBIAN_VERSION check fails (cloned from #951874)
Control: tags -1 +pending
Control: tags -2 -pending

Holger Levsen wrote on Sun, 23 Feb 2020 15:25 +:
> On Sat, Feb 22, 2020 at 03:38:15PM +0000, Daniel Shahaf wrote:
> > Following up on #951772, here are a few more bugfixes:
> > Subject: [PATCH 1/4] Clarify an error message
> > Subject: [PATCH 2/4] Fix --version output: used an undefined variable.
> > Subject: [PATCH 3/4] Print errors and warnings to stderr
> > In one case, fix the exit code.
> > Subject: [PATCH 4/4] Avoid implementation-defined behaviour  
> 
> all merged except that one case, fixing the error code.
> 

Thanks!

> For that, I'm not sure if this is really a good idea, as it might make stuff 
> fail
> if /etc/debian-version has been changed by a user or if in future sid will 
> get become
> version 99 or whatever.
> 
> If you think exiting with 1 is a good idea still, please open a new bug, so
> this change is properly tracked and documented. (Though I'm not sure I'll 
> merge
> it then...)

I still think it's better to «exit 1» than to «exit 0».  A unix program
should either do what it was supposed to do and exit 0, or otherwise
exit 1.  Since in this case we exit without checking whether any
installed packages are out of support, the exit code shouldn't be
zero.

Even if a user has edited /etc/debian_version, I think it's better to
exit non-zero to make them aware of the problem, than to silently
disable the "check for not-security-supported packages" functionality
by exiting zero.  (The message on stderr might be ignored by the caller
unless the error code is non-zero.)

If sid becomes v99, then the version check in this package will be able
to be updated to accommodate that.

For self-containedness, the option discussed above is:

[[[
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -24,7 +24,7 @@ if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ 
"$DEBIAN_VERSION" -gt "$D
 >&2 printf "%s: " "$NAME"
 >&2 eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values 
are from \$DEB_LOWEST_VER_ID to \$DEB_NEXT_VER_ID, inclusive."
 >&2 echo
-exit 0
+exit 1
 fi
 
 LIST=
]]]

Alternatively, how about deleting the «exit 0» line entirely?  That
would effectively downgrade the error message to a warning.

Cheers,

Daniel

P.S. Was I expected to include d/changelog hunks in the patch series?
Every package does this differently…

Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Package: debian-security-support
Version: 2020.02.21
Tags: upstream patch

Good morning Holger,

Following up on #951772, here are a few more bugfixes:

[[[
>From d96f69e8ed2eef988c4b2fab24dc43cc1fc672d3 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Sat, 22 Feb 2020 15:29:06 +
Subject: [PATCH 1/4] Clarify an error message

---
 check-support-status.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/check-support-status.in b/check-support-status.in
index b9f5263..5ac4274 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -21,7 +21,7 @@ if [ -z "$DEBIAN_VERSION" ] ; then
 fi
 
 if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt 
"$DEB_NEXT_VER_ID" ] ; then
-eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values from 
\$DEB_LOWEST_VER_ID and \$DEB_NEXT_VER_ID"; echo
+eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values are 
from \$DEB_LOWEST_VER_ID to \$DEB_NEXT_VER_ID, inclusive."; echo
 exit 0
 fi
 

>From c9e725c5c554e35ba03453fa56804b8c93f790eb Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Sat, 22 Feb 2020 15:29:53 +
Subject: [PATCH 2/4] Fix --version output: used an undefined variable.

---
 check-support-status.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/check-support-status.in b/check-support-status.in
index 5ac4274..5a2c500 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -68,7 +68,7 @@ eval set -- "$TEMP"
 while true ; do
 case "$1" in
 -V|--version|--Version)
-eval_gettext "\$name version \$VERSION"; echo
+eval_gettext "\$NAME version \$VERSION"; echo
 exit 0
     ;;
 -h|--help)

>From 5a5010c11a3fa3bb0f74d5c5d6ad319ef7e7badf Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Sat, 22 Feb 2020 15:30:39 +
Subject: [PATCH 3/4] Print errors and warnings to stderr

In one case, fix the exit code.
---
 check-support-status.in | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/check-support-status.in b/check-support-status.in
index 5a2c500..9aeb50c 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -21,8 +21,10 @@ if [ -z "$DEBIAN_VERSION" ] ; then
 fi
 
 if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt 
"$DEB_NEXT_VER_ID" ] ; then
-eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values are 
from \$DEB_LOWEST_VER_ID to \$DEB_NEXT_VER_ID, inclusive."; echo
-exit 0
+>&2 printf "%s: " "$NAME"
+>&2 eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values 
are from \$DEB_LOWEST_VER_ID to \$DEB_NEXT_VER_ID, inclusive."
+>&2 echo
+exit 1
 fi
 
 LIST=
@@ -59,7 +61,9 @@ Options:
 }
 
 if [ $? != 0 ] ; then
-gettext "Failed to parse the command line parameters"; echo
+>&2 printf "%s: " "$NAME"
+>&2 gettext "Failed to parse the command line parameters"
+>&2 echo
 exit 1
 fi
 
@@ -92,8 +96,9 @@ while true ; do
 EXCEPT="$2"
 case "$EXCEPT" in
 *:*)
-printf "%s: " "$NAME" &&
-gettext 'E: --except= does not allow : 
suffixes'; echo
+>&2 printf "%s: " "$NAME"
+>&2 gettext 'E: --except= does not allow 
: suffixes'
+>&2 echo
 exit 1
 ;;
 esac
@@ -108,8 +113,9 @@ while true ; do
 break
 ;;
 *)
-printf "%s: " "$NAME" &&
-gettext 'E: Internal error'; echo
+>&2 printf "%s: " "$NAME"
+>&2 gettext 'E: Internal error'
+>&2 echo
 exit 1
 ;;
 esac
@@ -131,8 +137,9 @@ case "$TYPE" in
 $0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
--except "$EXCEPT" $NOHEADING
 exit 0
 fi
-printf "%s: " "$NAME" &&
-gettext 'E: Need a --type if --list is given'; echo
+>&2 printf "%s: " "$NAME"
+>&2 gettext 'E: Need a --type if --list is given'
+>&2 echo
 exit 1
 ;;
 earlyend)
@@ -145,8 +152,9 @@ limited)
 [ "$LIST" ] || LIST=[% LIMITED %]
 ;;
 *)
-printf "%s: " "$NAME" &&
-eval_gettext "E: Unknown --type '\$TYPE'"; echo
+>&2 printf "%s: " "$NAME

Bug#951772: debian-security-support: Please sign error messages

[Daniel Shahaf]

Control: tags -1 patch

Holger Levsen wrote on Fri, Feb 21, 2020 at 15:38:38 +:
> Hi Daniel,
> 
> On Fri, Feb 21, 2020 at 03:25:34PM +0000, Daniel Shahaf wrote:
> > Please prefix "check-support-status: " to the error message.
> 
> Can I have a patch, please?

This?

diff --git a/check-support-status.in b/check-support-status.in
index 7296360..958c2f5 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -92,6 +92,7 @@ while true ; do
 EXCEPT="$2"
 case "$EXCEPT" in
 *:*)
+printf "%s: " "$NAME" &&
 gettext 'E: --except= does not allow : 
suffixes'; echo
 exit 1
 ;;
@@ -107,6 +108,7 @@ while true ; do
 break
 ;;
 *)
+printf "%s: " "$NAME" &&
 gettext 'E: Internal error'; echo
 exit 1
 ;;
@@ -129,6 +131,7 @@ case "$TYPE" in
 $0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
--except "$EXCEPT" $NOHEADING
 exit 0
 fi
+printf "%s: " "$NAME" &&
 gettext 'E: Need a --type if --list is given'; echo
 exit 1
 ;;
@@ -142,6 +145,7 @@ limited)
 [ "$LIST" ] || LIST=[% LIMITED %]
 ;;
 *)
+printf "%s: " "$NAME" &&
 eval_gettext "E: Unknown --type '\$TYPE'"; echo
 exit 1
 ;;
@@ -164,6 +168,7 @@ if [ "$DPKG_VERSION" ] && dpkg --compare-versions 
"$DPKG_VERSION" '<<' 1.16 ; th
 SHOWFORMAT='${Status}\t${Package}\t${Version}\t${Source}\n'
 else
 if [ -z "$DPKG_VERSION" ] ; then
+printf "%s: " "$NAME" &&
 gettext "E: Cannot detect dpkg version, assuming wheezy or newer"; echo
 fi
 SHOWFORMAT='${Status}\t${binary:Package}\t${Version}\t${Source}\n'

The trailing "&&" are meant to discourage code from being added between
the printf and the gettext.  I've considered several alernatives but
didn't come up with one that's significantly better.

Looks like these error messages should go to stderr, too — unless that'd
be an API change?

Cheers,

Daniel

Bug#951442: marked as pending in debian-security-support

[Daniel Shahaf]

Perhaps add a comment as well? —

--- a/check-support-status.in
+++ b/check-support-status.in
@@ -252,6 +252,7 @@ cat "$INTERSECTION_LIST" | while read SRC_NAME ; do
 
 [% AWK %] '($3=="'"$SRC_NAME"'"){print $1" "$2}' "$INSTALLED_LIST" | \
 while read BIN_NAME BIN_VERSION ; do
+# skip packages that were listed in --except
 case ",$EXCEPT," in
 *,"$BIN_NAME",*) # plain match (e.g., "binutils")
 continue

(Sorry for the extra round trip; I'd meant to add this before submitting
but forgot to.)

Cheers,

Daniel

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

Holger Levsen wrote on Fri, 21 Feb 2020 13:40 +00:00:
> On Fri, Feb 21, 2020 at 11:04:48AM +0000, Daniel Shahaf wrote:
> > Here you go:
> [...]
> 
> thanks, looks good to me now! 

Great, thanks for the quick turnaround!

I'm building this now for buster and will update my local scripts to use this :)

> > P.S. Separate issue: in cases such as —
> > % check-support-status --type foo 
> > E: Unknown --type 'foo'
> > %
> > — it would be nice to have "check-support-status: " prefixed to the
> > error message.  (Shall I open a separate bug for this?)
> 
> yes, please.

Done: #951722

Cheers,

Daniel

Bug#951772: debian-security-support: Please sign error messages

[Daniel Shahaf]

Package: debian-security-support
Version: 2019.12.12~deb10u1
Severity: minor
Tags: upstream confirmed
# Confirmed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951442#40

Dear Maintainer,

In the following case:

% check-support-status --type foo 
E: Unknown --type 'foo'
%

Please prefix "check-support-status: " to the error message.

Cheers,

Daniel

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

> > > > I'm not sure if the handling of the ":amd64" architecture suffixes is
> > > > ideal.  Thoughts?
> > Okay, so what would you prefer?  To have --except=foo match both
> > foo and foo:bar for any value of bar?  (and 'foo' documented as
> > a bare package name without a ":arch" suffix)
> 
> yes, that.

Here you go:

[[[
diff --git a/check-support-status.in b/check-support-status.in
index a5437c4..7296360 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -28,6 +28,7 @@ fi
 LIST=
 NOHEADING=
 STATUSDB_FILE=
+EXCEPT=
 TYPE=
 
 NAME="$(basename "$0")"
@@ -37,7 +38,7 @@ TODAY="$(date +"%Y%m%d")"
 TEMP=$( \
 getopt \
 --options h,V \
---long help,list:,no-heading,semaphore:,status-db:,type:,version,Version \
+--long 
help,list:,no-heading,semaphore:,status-db:,except:,type:,version,Version \
 -n "$NAME" \
 -- "$@"
 )
@@ -52,6 +53,7 @@ Options:
   --list FILE   database of packages under specific support 
conditions
   --no-heading  skips printing headlines
   --status-db FILE  database about already reported packages
+  --except PACKAGES exempt given binary packages (comma-separated 
list)
   --type SECURITY_SUPPORT_TYPE  earlyend, ended or limited
   -V, --version display version and exit"; echo
 }
@@ -86,6 +88,16 @@ while true ; do
 STATUSDB_FILE="$2"
 shift 2
 ;;
+--except)
+EXCEPT="$2"
+case "$EXCEPT" in
+*:*)
+gettext 'E: --except= does not allow : 
suffixes'; echo
+exit 1
+;;
+esac
+shift 2
+;;
 --type)
 TYPE="$2"
 shift 2
@@ -104,17 +116,17 @@ done
 case "$TYPE" in
 '')
 if [ -z "$LIST" ] ; then
-REPORT="$($0 --type ended --list [% ENDED %] --status-db 
"$STATUSDB_FILE" $NOHEADING)"
+REPORT="$($0 --type ended --list [% ENDED %] --status-db 
"$STATUSDB_FILE" --except "$EXCEPT" $NOHEADING)"
 if [ -n "$REPORT" ]  ; then
 echo "$REPORT"
 echo
 fi
-REPORT="$($0 --type limited --list [% LIMITED %] --status-db 
"$STATUSDB_FILE" $NOHEADING)"
+REPORT="$($0 --type limited --list [% LIMITED %] --status-db 
"$STATUSDB_FILE" --except "$EXCEPT" $NOHEADING)"
 if [ -n "$REPORT" ] ; then
 echo "$REPORT"
 echo
 fi
-$0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
$NOHEADING
+$0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
--except "$EXCEPT" $NOHEADING
 exit 0
 fi
 gettext 'E: Need a --type if --list is given'; echo
@@ -240,6 +252,14 @@ cat "$INTERSECTION_LIST" | while read SRC_NAME ; do
 
 [% AWK %] '($3=="'"$SRC_NAME"'"){print $1" "$2}' "$INSTALLED_LIST" | \
 while read BIN_NAME BIN_VERSION ; do
+case ",$EXCEPT," in
+*,"$BIN_NAME",*) # plain match (e.g., "binutils")
+continue
+;;
+*,"${BIN_NAME%:*}",*) # match with arch suffix (e.g., 
"libbinutils:amd64")
+continue
+;;
+esac
 # for earlyend and ended, check packages actually affected (if 
TMP_WHEN not null)
 if [ -n "$TMP_WHEN" ] || [ "$TYPE" = limited ] ; then
 if \
diff --git a/man/check-support-status.txt b/man/check-support-status.txt
index a16ef9a..066e042 100644
--- a/man/check-support-status.txt
+++ b/man/check-support-status.txt
@@ -83,6 +83,12 @@ reported only once.
 +
 Default: No records, any affected package will be reported every time.
 
+*--except* 'PACKAGES'::
+
+Do not alert for the given binary packages (comma-separated list).
++
+Default: Alert for all packages (no exceptions).
+
 *--type* 'TYPE'::
 
 One of the following:
diff --git a/t/check-support-status.t b/t/check-support-status.t
index 784d947..af7c082 100644
--- a/t/check-support-status.t
+++ b/t/check-support-status.t
@@ -855,6 +855,76 @@ __EOS__
 );
 }
 
+diag ('exempt packages from listing');
+
+foreach my $awk (@AWKs) {
+diag ("exempt ($awk)");
+
+my $tb = Testbed->new ($dpkg_version);
+my ($list_ended, $list_limited, $query_list, $statusdb_file) = $tb->files;
+my $exe = $tb->exe (
+$awk,
+[
+'--type', 'limited',
+'--no-heading',
+'--list', $list_limited,
+'--status-db', $statusdb_file,
+'--except', 'hello,binutils-common',
+],
+);
+
+write_file ($list_limited, <<__EOS__);
+binutilslorem ipsum dolor sit amet
+php5See README.Debian.security for the PHP security policy
+__EOS__
+mock_query_list (
+$query_list,
+[
+[ 'ioi', 'binutils', '2.34-2' ],
+[ 'ioi', 'binutils-common:amd64', '2.34-2', 'binutils' ],
+[ 'ioi', 'php5', '5.3.3-7+squeeze19' ],
+],
+);
+
+# 

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

Holger Levsen wrote on Fri, 21 Feb 2020 00:26 +00:00:
> On Sun, Feb 16, 2020 at 07:35:39PM +0000, Daniel Shahaf wrote:
> > > & patches welcome.
> > Here you go, against current git:
> 
> wheeehoo, very nice.
> 

Thanks for the review!

> just two comments:
>  
> > +write_file ($list_limited, <<__EOS__);
> > +php5See README.Debian.security for the PHP security policy
> > +__EOS__
> 
> why is php5 mentioned here?

I'm not sure I understand the question.

I based the new test on the existing "simple ($awk)" test.  That test
uses php5 as the example, so that carried over to the new test.

However, I suspect that doesn't answer your question.  Could you clarify
it, please?

> > % ./check-support-status 
> > --except=binutils,binutils-common:amd64,binutils-x86-64-linux-gnu,libbinutils:amd64,libctf0:amd64,libctf-nobfd0:amd64
> > I'm not sure if the handling of the ":amd64" architecture suffixes is
> > ideal.  Thoughts?
> 
> I'd rather not have this there:
> - it makes things complicated if I need to know if a package is 
> arch:all or the host binary arch
> - it's also redudant, if the system is amd64, all packages will be 
> amd64. (well, modulo multi-arch i guess)

Okay, so what would you prefer?  To have --except=foo match both
foo and foo:bar for any value of bar?  (and 'foo' documented as
a bare package name without a ":arch" suffix)

Cheers,

Daniel

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

Controls: tags -1 confirmed patch

Holger Levsen wrote on Sun, 16 Feb 2020 18:29 +:
> On Sun, Feb 16, 2020 at 04:12:46PM +0000, Daniel Shahaf wrote:
> > [...] Thus, in effect, it would let the admin "whitelist"
> > known issues, so only new ones would be printed.
> > 
> > Would this make sense?  
> 
> yes.

Thanks for the quick answer.

> & patches welcome.

Here you go, against current git:

[[[
diff --git a/check-support-status.in b/check-support-status.in
index a5437c4..685e5ac 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -28,6 +28,7 @@ fi
 LIST=
 NOHEADING=
 STATUSDB_FILE=
+EXCEPT=
 TYPE=
 
 NAME="$(basename "$0")"
@@ -37,7 +38,7 @@ TODAY="$(date +"%Y%m%d")"
 TEMP=$( \
 getopt \
 --options h,V \
---long help,list:,no-heading,semaphore:,status-db:,type:,version,Version \
+--long 
help,list:,no-heading,semaphore:,status-db:,except:,type:,version,Version \
 -n "$NAME" \
 -- "$@"
 )
@@ -52,6 +53,7 @@ Options:
   --list FILE   database of packages under specific support 
conditions
   --no-heading  skips printing headlines
   --status-db FILE  database about already reported packages
+  --except PACKAGES exempt given packages (comma-separated list)
   --type SECURITY_SUPPORT_TYPE  earlyend, ended or limited
   -V, --version display version and exit"; echo
 }
@@ -86,6 +88,10 @@ while true ; do
 STATUSDB_FILE="$2"
 shift 2
 ;;
+--except)
+EXCEPT="$2"
+shift 2
+;;
 --type)
 TYPE="$2"
 shift 2
@@ -104,17 +110,17 @@ done
 case "$TYPE" in
 '')
 if [ -z "$LIST" ] ; then
-REPORT="$($0 --type ended --list [% ENDED %] --status-db 
"$STATUSDB_FILE" $NOHEADING)"
+REPORT="$($0 --type ended --list [% ENDED %] --status-db 
"$STATUSDB_FILE" --except "$EXCEPT" $NOHEADING)"
 if [ -n "$REPORT" ]  ; then
 echo "$REPORT"
 echo
 fi
-REPORT="$($0 --type limited --list [% LIMITED %] --status-db 
"$STATUSDB_FILE" $NOHEADING)"
+REPORT="$($0 --type limited --list [% LIMITED %] --status-db 
"$STATUSDB_FILE" --except "$EXCEPT" $NOHEADING)"
 if [ -n "$REPORT" ] ; then
 echo "$REPORT"
 echo
 fi
-$0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
$NOHEADING
+$0 --type earlyend --list [% ENDED %] --status-db "$STATUSDB_FILE" 
--except "$EXCEPT" $NOHEADING
 exit 0
 fi
 gettext 'E: Need a --type if --list is given'; echo
@@ -240,6 +246,11 @@ cat "$INTERSECTION_LIST" | while read SRC_NAME ; do
 
 [% AWK %] '($3=="'"$SRC_NAME"'"){print $1" "$2}' "$INSTALLED_LIST" | \
 while read BIN_NAME BIN_VERSION ; do
+case ",$EXCEPT," in
+*,"$BIN_NAME",*)
+continue
+;;
+esac
 # for earlyend and ended, check packages actually affected (if 
TMP_WHEN not null)
 if [ -n "$TMP_WHEN" ] || [ "$TYPE" = limited ] ; then
 if \
diff --git a/man/check-support-status.txt b/man/check-support-status.txt
index a16ef9a..066e042 100644
--- a/man/check-support-status.txt
+++ b/man/check-support-status.txt
@@ -83,6 +83,12 @@ reported only once.
 +
 Default: No records, any affected package will be reported every time.
 
+*--except* 'PACKAGES'::
+
+Do not alert for the given binary packages (comma-separated list).
++
+Default: Alert for all packages (no exceptions).
+
 *--type* 'TYPE'::
 
 One of the following:
diff --git a/t/check-support-status.t b/t/check-support-status.t
index 784d947..dd9c54f 100644
--- a/t/check-support-status.t
+++ b/t/check-support-status.t
@@ -855,6 +855,50 @@ __EOS__
 );
 }
 
+diag ('exempt packages from listing');
+
+foreach my $awk (@AWKs) {
+diag ("exempt ($awk)");
+
+my $tb = Testbed->new ($dpkg_version);
+my ($list_ended, $list_limited, $query_list, $statusdb_file) = $tb->files;
+my $exe = $tb->exe (
+$awk,
+[
+'--type', 'limited',
+'--no-heading',
+'--list', $list_limited,
+'--status-db', $statusdb_file,
+'--except', 'hello,php5',
+],
+);
+
+write_file ($list_limited, <<__EOS__);
+php5See README.Debian.security for the PHP security policy
+__EOS__
+mock_query_list (
+$query_list,
+[
+[ 'ioi', 'php5', '5.3.3-7+squeeze19' ],
+],
+);
+
+# run a first tim

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

Package: debian-security-support
Version: 2019.12.12~deb10u1
Severity: wishlist
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

Two things:

1. I have installed binutils, which is Build-Essential and has limited
security support (#948634).

2. I use «chronic -e sh -c 'check-support-status >&2'» to check whether
any packages with limited security support are installed.

   * What was the outcome of this action?

Every time I run the command from (2), it exits non-zero, because
binutils is installed.

   * What outcome did you expect instead?

I'd like to be to have a way to run, say, «check-support-status
--dont-complain-about=binutils,binutils-common,libbinutils,binutils-x86-64-linux-gnu».
This command would skip the binary packages given on the command line
when looking for and listing installed binary packages with limited
support status.  Thus, in effect, it would let the admin "whitelist"
known issues, so only new ones would be printed.

Would this make sense?

Cheers,

Daniel


-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-security-support depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  gettext-base   0.19.8.1-9

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- debconf-show failed

Bug#948986: aptitude search: please allow searching by component (main/contrib/non-free)

[Daniel Shahaf]

Package: aptitude
Version: 0.8.12-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

Please add a search pattern ?component(…) that can be used as
?component(main), ?component(non-free), ?component(contrib).

Thanks,

Daniel

Bug#948634: debian-security-support: please elaborate on binutils' status

[Daniel Shahaf]

Good morning Salvatore,

Salvatore Bonaccorso wrote on Sat, Jan 11, 2020 at 09:07:30 +0100:
> Control: clone 948634 -1
> Control: reassign -1 src:binutils
> Control: retitle -1 binutils: Please add a README.Debian.security documenting 
> security support for binutils
> Control: blocked 948634 with -1
> 
> On Sat, Jan 11, 2020 at 02:28:14AM +, Daniel Shahaf wrote:
> > +++ b/security-support-limited
> > @@ -7,7 +7,7 @@
> > -binutilsNot covered by security support
> > +binutilsOnly suitable for trusted content; see 
> > https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
> >  ganglia See README.Debian.security, only supported behind an 
> > authenticated HTTP zone, #702775
> >  ganglia-web See README.Debian.security, only supported behind an 
> > authenticated HTTP zone, #702776
> >  glpiOnly supported behind an authenticated HTTP zone for 
> > trusted users
> > 
> > @Florian That linked message is yours; any objections from you?
> 
> yes we can add that, but OTOH we asked the binutils maintainer already
> when we decided to mark it as unsupported, to please add a
> README.Debian.security file shipped in the package with a explanation,
> similar to the above, that there is none covering binutils by security
> updates (including upstream!). That would then be a slightly better
> reference to add, so I would rather go with that.

Yes, this make sense: binutils would document its own support status and
security-support-limited would simply point to README.Debian.security, as
it does for some other packages.

> The README.Debian.security file could contain something along the
> following lines:
> 
> > binutils (the tools the included libraries like libbfd) are not
> > covered by security support, i.e. bugfixes are not backported to
> > stable releases and will only land in the next release.
> 
> Matthias, could you add this?

I suggest to state not only the negative promise ("no security support") but
also the positive one (e.g., "Only suitable for use on trusted content").

Nitpicking: Suggest to change "next release" either to "next release (bullseye)"
or to "next point release" to clarify the intended meaning.

Thanks for the quick answer,

Daniel

Bug#948634: debian-security-support: please elaborate on binutils' status

[Daniel Shahaf]

Package: debian-security-support
Version: 2019.06.13
Severity: important
Tags: patch
Control: affects -1 binutils

Dear Maintainer,

Now that binutils has limited security support, please elaborate on its
status.  Suggested patch (against current git):

--- a/security-support-limited
+++ b/security-support-limited
@@ -7,7 +7,7 @@
 #In the program's output, this is prefixed with "Details:"
 
 adnsStub resolver that should only be used with trusted recursors
-binutilsNot covered by security support
+binutilsOnly suitable for trusted content; see 
https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
 ganglia See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702776
 glpiOnly supported behind an authenticated HTTP zone for trusted 
users

@Florian That linked message is yours; any objections from you?

Thanks,

Daniel

P.S. Priority "important" since binutils' rdeps include dpkg-dev, gcc,
and clang, so I assume this is quite visible.

Bug#948629: rpcbind: please say that the -r flag is a Debian extension

[Daniel Shahaf]

Package: rpcbind
Version: 1.2.5-8
Severity: normal
Tags: patch

Dear Maintainer,

Since the -r flag is added as a Debian patch, please document that it's
a Debian extension.  Here's the patch against current git:

diff --git a/debian/patches/00-rmt-calls.patch 
b/debian/patches/00-rmt-calls.patch
index 0ed215f..592291e 100644
--- a/debian/patches/00-rmt-calls.patch
+++ b/debian/patches/00-rmt-calls.patch
@@ -99,7 +99,7 @@ Last-Update: 2019-09-17
 +Turn on remote calls. Cause
 +.Nm
 +to open up random listening ports. Note that rpcinfo need this feature turned 
on
-+for work properly.
++for work properly. (This flag is a Debian extension.)
  .El
  .Sh NOTES
  All RPC servers must be restarted if

Cheers,

Daniel

Bug#733573: ssh: Doesn't use the key from -i when using an agent.

[Daniel Shahaf]

Kurt Roeckx wrote on Mon, Dec 30, 2013 at 01:53:39 +0100:
> Package: openssh-client
> Version: 1:6.4p1-1
> 
> Hi,
> 
> When I use ssh with the -i option to use a different key, it seems
> to be offering my default key anyway.  It seems this is only the
> case when an ssh-agent is running.  The key that is given isn't
> added to the agent.
> 
> ssh -v shows:
> debug1: identity file other_key type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-4096
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-4096
> debug1: identity file other_key-cert type -1
> [...]
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /home/kurt/.ssh/id_rsa
> 
> When ssh doesn't know about my running ssh-agent, it will offer
> the key given with -i.

Looks like a duplicate of #203700 and #513235; a workaround is to set
IdentitiesOnly=yes in ssh_config(5).

Cheers,

Daniel

Bug#948445: release-notes: aptitude search for not-from-Debian package has false negatives

[Daniel Shahaf]

Justin B Rye wrote on Thu, Jan 09, 2020 at 12:02:19 +:
> Andrei POPESCU wrote:
> > The long form is quite self-explanatory, the short form is easier to 
> > type.
> > 
> > Maybe both should be mentioned?
> 
> Remember it's currently
> 
>   Below there are two methods for finding installed packages that did
>   not come from Debian, using either aptitude or apt-forktracer. Please
>   note that neither of them are 100% accurate (e.g. the aptitude example
>   will list packages that were once provided by Debian but no longer
>   are, such as old kernel packages).
> 
>   $ aptitude search '~i(!~ODebian)'
>   $ apt-forktracer | sort
> 
> Adding a second version of the aptitude search would mean breaking it
> up with a bit of extra explanation.  I'd stick to one version, but I
> don't know which I'd vote for.

If it's an either/or question, I'd vote for the long-hand spelling because it's
self-documenting.  Someone who doesn't know aptitude will understand the long 
form
but not the short form.  Someone who knows the short form will understand the 
long
form, but someone who doesn't know aptitude, or who only knows the long form, 
won't
understand the short form.

Furthermore, the docs could point to aptitude's manual, table 2.3 (in stretch;
it may have been renumbered since then).

> Incidentally, I've always been slightly annoyed by that claim that
> "aptitude search" isn't 100% accurate.  Given that the point of
> section 4.2 is to check that you're running pure Debian updated to the
> latest stable point release, the fact that it tells you about legacy
> kernels seems like a feature, not a bug.

I agree that it is a feature, but nevertheless I think it is worth clarifying
that the results list packages that are not *today* available for download from
deb.debian.org, even if they had been available in the past, otherwise new
sysadmins who read the upgrade notes might see the kernel package in the output
and wonder if they'd been running a third party kernel.

Cheers,

Daniel

Bug#948445: release-notes: aptitude search for not-from-Debian package has false negatives

[Daniel Shahaf]

Package: release-notes
Severity: normal
Tags: patch

Dear Maintainer,

§4.2 of the release notes¹ recommends to run «aptitude search '~i(!~ODebian)'».

I suggest to change the search pattern to «'?narrow(~i, (!~ODebian))'».

That will also catch packages that were backported directly from sid, or
packages that had been compiled with local patches (I have a few of
those), etc..

Cheers,

Daniel
(I couldn't find the repository so I'm not actually attaching a patch,
but I've set the label anyway since I'm proposing a specific change.)

¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

Bug#948291: dpkg-buildpackage: please support --hook-foo=bar=baz

[Daniel Shahaf]

Package: dpkg-dev
Version: 1.19.7
Severity: normal
Tags: patch

Dear Maintainer,

[tl;dr: dpkg-buildpackage --hook-init=foo=bar errors out; patch attached.]

   * What led up to the situation?

I was trying to build a package in a chroot and inject some additional
flags into CFLAGS.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I read the pdebuild(1) and dpkg-buildflags(1) manual pages and ran the
following command:

% pdebuild -- --debbuildopts "--hook-init='echo APPEND CFLAGS -std=c89 > 
/etc/dpkg/buildflags.conf'"

   * What was the outcome of this action?

[[[
I: Building the package
I: Running cd /build/zsh-syntax-highlighting-0.6.0/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc --source-option=--extend-diff-ignore=^tags$ --hook-init='echo APPEND CFLAGS 
-std=c89 > /etc/dpkg/buildflags.conf' -rfakeroot
dpkg-buildpackage: error: unknown hook name init=echo APPEND CFLAGS -std
]]]

(zsh-syntax-highlighting is just a random package that doesn't have any
source files in C; the error should be repeatable with any package.)

   * What outcome did you expect instead?

I expected the string «--hook-init='echo APPEND CFLAGS -std=c89 > 
/etc/dpkg/buildflags.conf'»
in argv to be taken as creating an «init» hook whose value is the shell
command «echo APPEND CFLAGS -std=c89 > /etc/dpkg/buildflags.conf».

I believe the following patch (against current git) should do the trick:

[[[
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 2c49738b5..1332ca716 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -238,7 +238,7 @@ while (@ARGV) {
$check_command = $1;
 } elsif (/^--check-option=(.*)$/) {
push @check_opts, $1;
-} elsif (/^--hook-(.+)=(.*)$/) {
+} elsif (/^--hook-(.+?)=(.*)$/) {
my ($hook_name, $hook_cmd) = ($1, $2);
usageerr(g_('unknown hook name %s'), $hook_name)
if not exists $hook{$hook_name};
]]]

Cheers,

Daniel

Bug#947120: vim-nox: :syn contains=TOP inside a :syn-include'd file refers to the outer file

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, Dec 21, 2019 at 11:09:39 +:
>* What was the outcome of this action?
> 
> When the file iota is viewed with «set filetype=foo», the words "lorem
> ipsum" on line 1 are not highlighted.
> 
>* What outcome did you expect instead?
> 
> I expected those two words on line 1 to be highlighted (via the chain
> TOP -> fooBlock -> @bar -> barBlock -> barKeyword).
> 
> I note that if contains=TOP is either removed, or changed to
> contains=@bar, then the words on line 1 do get highlighted.  However,
> either of these changes would break the highlighting of ft=bar files.

Changing contains=TOP to contains=barKeyword also causes the words on
line 1 to be highlighted.  Since «:help syn-contains» defines "TOP" as
"all groups that aren't 'contained'", and barKeyword isn't 'contained',
I would have expected contains=TOP to imply contains=barKeyword.

> It seems to me that when «contains=TOP» is encountered in a
> :syn-include'd file, it's taken as a reference to the actual top-level,
> i.e., the top of foo.vim, rather than as a reference to the top of the
> included syntax's scope, i.e., the syntax match or region that did
> «contains=@bar».

According to syntax.c:in_id_list(), "TOP" is indeed supposed to only
accept groups that are defined in the same file (i.e., bar.vim).

Cheers,

Daniel

Bug#947120: vim-nox: :syn contains=TOP inside a :syn-include'd file refers to the outer file

[Daniel Shahaf]

Package: vim-nox
Version: 2:8.1.2269-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

I wanted to write a custom syntax file that includes another syntax file.

(Specifically, I wanted to write a syntax filefor zsh's test suite, and
have it include the zsh syntax file shipped with Vim itself.  zsh's test
suite consists of test cases, that should be highlighted as zsh scripts,
plus metadata such as the expected exit code, which would be highlighted
by the custom syntax file I was writing.)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

To cut a long story short, here's a minimal example:

% head -999 .vim/syntax/foo.vim .vim/syntax/bar.vim iota
==> .vim/syntax/foo.vim <==
if exists("b:current_syntax")
  finish
endif

syntax clear
syntax include @bar :p:h/bar.vim
unlet b:current_syntax
syntax region fooBlock start=/^\s/ end=/$/ contains=@bar

let b:current_syntax = "foo"

==> .vim/syntax/bar.vim <==
if exists("b:current_syntax")
  finish
endif

syntax clear
syntax region barBlock matchgroup=barBraces start=+{+ end=+}+ 
transparent contains=TOP
syntax keyword barKeyword lorem ipsum

hi def link barBraces  Special
hi def link barKeyword Keyword

let b:current_syntax = "bar"

==> iota <==
  { lorem ipsum dolor sit amet }
  lorem ipsum dolor sit amet
% 

(For orientation, in this example foo.vim stands for my custom syntax,
bar.vim stands for $VIMRUNTIME/syntax/zsh.vim, barBlock corresponds to
zshBrackets, and barKeyword corresponds to the zsh.vim syntax rules
responsible for highlighting, say, the «cd» and «$0» in «{ cd $0 }».)

   * What was the outcome of this action?

When the file iota is viewed with «set filetype=foo», the words "lorem
ipsum" on line 1 are not highlighted.

   * What outcome did you expect instead?

I expected those two words on line 1 to be highlighted (via the chain
TOP -> fooBlock -> @bar -> barBlock -> barKeyword).

I note that if contains=TOP is either removed, or changed to
contains=@bar, then the words on line 1 do get highlighted.  However,
either of these changes would break the highlighting of ft=bar files.

It seems to me that when «contains=TOP» is encountered in a
:syn-include'd file, it's taken as a reference to the actual top-level,
i.e., the top of foo.vim, rather than as a reference to the top of the
included syntax's scope, i.e., the syntax match or region that did
«contains=@bar».

Cheers,

Daniel


-- Package-specific info:

(Freshly-created, up-to-date sid chroot with default settings.)

Bug#939194: [Pkg-zsh-devel] Bug#939194: zsh: git completion: does not know "git switch"

[Daniel Shahaf]

Control: tags -1 upstream

Vincent Lefevre wrote on Mon, 02 Sep 2019 07:43 +00:00:
> If I do "git sw[Tab]", zsh does not find any completion.
> It should complete to "git switch".

Please report this upstream if you haven't already.

Bug#934926: [Pkg-zsh-devel] Bug#934926: overridding of default fpath causes uncessary complexity and pain for software providing zsh completions

[Daniel Shahaf]

Joey Hess wrote on Fri, 16 Aug 2019 18:35 +00:00:
> By default zsh loads completions from /usr/share/zsh/site-functions
> and while the name of that is perhaps not great, as it's not
> site-specific[1], it's a standard location. Debian has overridden this,
> so zsh does not look there, but instead in
> /usr/share/zsh/vendor-functions and /usr/share/zsh/vendor-completions
...
> The rationalle for the change in #620452 seems too weak to justify this
> added complexity. zsh could at least continue looking in the default
> location as well as whatever other locations Debian wants to patch in.

Let's see:

$ /usr/bin/zsh -fc 'print -rl $fpath' | head -3 # that's the Debian 
package, 5.7.1-1
/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
$ /srv/zsh/bin/zsh -fc 'print -rl $fpath' | head -3 # that's zsh compiled from 
upstream with --prefix=/srv/zsh
/usr/local/share/zsh/site-functions
/srv/zsh/share/zsh/site-functions
/srv/zsh/share/zsh/5.6.2-test-2/functions
$ 

So /usr/local/share/zsh/site-functions is still there for stuff installed
by the administrator, and vendor-functions and vendor-completions are
added in there for stuff provided by other Debian packages.  Are you
just asking to re-add ${PREFIX:-/usr}/share/zsh/site-functions there,
presumably between the first and second elements?

On the one hand, it _would_ be consistent with upstream, but on the
other hand, nobody should be putting anything in a site-functions
directory under /usr/share (admins should be putting their
customizations in /usr/local/share; other Debian packages should be
putting their stuff in vendor-functions or vendor-completions).  I don't
have a strong opinion on this, so I'll defer to others to make the call.

I suppose that if we add this, we should also add
${PREFIX}/share/zsh/${ZSH_VERSION}/functions, shouldn't we?

Cheers,

Daniel

Bug#863045: at: interactively please print parsed time at start

[Daniel Shahaf]

Jose M Calhariz wrote on Wed, 17 Jul 2019 19:09 +00:00:
> as promised is here the patch.  This is a draft so you can look into
> the new message and say if you aprove it.  The code is not optimized,
> so I may change it a bit.
> 
> +++ b/at.c
> @@ -479,6 +479,11 @@ writefile(time_t runtimer, char queue)
>  
>  istty = isatty(fileno(stdin));
>  if (istty) {
> +   runtime = localtime();
> +
> +   strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
> +   fprintf(stderr, "at %s\n", timestr);
> +
> fprintf(stderr, "at> ");
> fflush(stderr);
>  }

Tested.  Looks good to me.  Thank you!

Bug#863045: at: interactively please print parsed time at start

[Daniel Shahaf]

Jose M Calhariz wrote on Wed, 17 Jul 2019 02:03 +00:00:
> I am working in a new release of at and I have a draft of this
> feature.  If you are interested in beta testing it, I can prepare a
> package for most releases of Debian on i386 ou amd64.

Thanks for looking into this and for offering to prepare a beta package!
There'll be no need for a beta package, however; a patch against the current
stretch or sid package will be sufficient.  I should be able to find time to 
build
it and give it a test drive.

Thanks again,

Daniel

Bug#846278: Fix or workaround for Debian #846278

[Daniel Shahaf]

Robert Micsutka wrote on Sun, 16 Jun 2019 11:00 +00:00:
> On Sat, 08 Jun 2019 10:21:31 +0000 "Daniel Shahaf"  
> wrote:
> > You might be able to get around this by using the 'equivs' package:
> 
> But after this you can not lock your screen anymore.
> The qucik workaroud here is to use a different lock screen, eg:

Yes, sorry, I thought that went without saying.  equivs simply allows
light-locker to be deinstalled while keeping xfce installed; one then
needs to install another screen locker to restore the functionality.

That's the workaround I used, anyway.  There may well be a
simpler one :)

Cheers,

Daniel

Bug#846278: Fix or workaround for Debian #846278

[Daniel Shahaf]

Brian Doherty wrote on Fri, 07 Jun 2019 19:45 +00:00:
> I don't have l3lock. If I try to purge light-locker, Lubuntu tries to 
> uninstall XFCE and install Gnome in its place :(

You might be able to get around this by using the 'equivs' package:

1. cd "$(mktemp -d)"
2. apt install equivs
3. equivs-control foo
4. perl -pi -e 's/.*/Provides: light-locker/ if /Provides:/' foo
5. equivs-build foo
6. sudo dpkg -i equivs-dummy*.deb
7. sudo apt-get purge light-locker

Cheers,

Daniel

Bug#924736: [Pkg-zsh-devel] Bug#924736: Bug#924736: zsh 5.7.1 segfaults when three setopt options are in play

[Daniel Shahaf]

wesl...@euronet.nl wrote on Sat, 23 Mar 2019 11:03 +00:00:
> upstream seem to have fixed this bug with commit 
> 73b29f079b50412700727e0f77991506c03d19fe

Thanks for the heads-up, Wesley.  Axel already had annotated this bug
with this information:

> # Commit 73b29f079b50412700727e0f77991506c03d19fe
> tags 924736 + fixed-upstream

Cheers,

Daniel

Bug#921236: [Pkg-zsh-devel] Bug#921236: Bug#921236: zsh: provide equivalent of dh_bash-completion

[Daniel Shahaf]

Dmitry Bogatov wrote on Tue, 05 Feb 2019 16:15 +:
> 
> [2019-02-03 13:39] Daniel Shahaf 
> > However, do note that some upstreams ship completion files that are
> > inferior to those that ship with zsh itself.  In such cases it would be
> > desirable *not* to install the upstream's completion into the default
> > fpath (`/usr/bin/zsh -fc 'typeset -p fpath'`).
> 
> If upstream provides {foo}.zsh_completion file, how can I compare it
> with zsh proper? Invoke `dpkg -L zsh-common|grep foo' and compare file
> length? Or something more elaborate?

That could be a first approximation.  However, the completion shipped
with zsh may be spread across multiple files (Command/_foo and
Types/_foo_thingies) or be in a differently-named file (the completion
for groupmod(8) is in _user_admin, the completion of latexmk(1) is in
tex(1), ...), and I haven't said a word yet about whether
{foo}.zsh_completion uses more advanced features such as tags,
descriptions, and matchspecs.

In short, I don't have a rule of thumb for you.  What I can say with certainty 
is
that if both zsh and foo upstream provide completion for foo, a bug report
against either or both would be worthwhile so as to reduce duplication of 
effort.

HTH,

Daniel

Bug#921236: [Pkg-zsh-devel] Bug#921236: zsh: provide equivalent of dh_bash-completion

[Daniel Shahaf]

Dmitry Bogatov wrote on Sun, 03 Feb 2019 12:58 +:
> Source: zsh
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please proived debhelper to install zsh completion scripts. Some of my
> upstreams provide zsh scripts, but I, as non-user of zsh, have no idea,
> how to install them properly.
> 

As a rule, completion functions (first line is "#compdef") should be
installed to /usr/share/zsh/vendor-completions and autoloadable
functions (first line is "#autoload") to /usr/share/zsh/vendor-functions;
both of these paths are Debian-specific.  I suggest that, at least for
now, you manually install the files to these paths.

However, do note that some upstreams ship completion files that are
inferior to those that ship with zsh itself.  In such cases it would be
desirable *not* to install the upstream's completion into the default
fpath (`/usr/bin/zsh -fc 'typeset -p fpath'`).

> In case of bash, dh_bash-completions ensures that everything is
> automatically done in policy-compliant way.

I'll leave it to others to comment on the idea of a dh_zsh-* helper.

Cheers,

Daniel

Bug#883453: xserver-xorg-input-libinput: xorg crash when waking-up from suspend to ram

[Daniel Shahaf]

Vincent Danjean wrote on Mon, Dec 04, 2017 at 09:40:55 +0100:
> Package: xserver-xorg-input-libinput
> Version: 0.26.0-1
> Severity: important
> 
>   Hi,
> 
>   When waking up from suspend to ram after several minutes, I get the unlock
> screen from xscreensaver (I'm under XFCE with xcreensaver). It often happens
> (but not always) that I need to tpye C-A-F1 and choose my user to get the
> unlock screen (without C-A-F1, the screen remains black).
>   Then, after typing my password, the xserver crash and I go back to the
> login screen (gdm3 for me). I can log, but all my previous working session
> is lost (hence the 'important' severity of this bug).

Some additional information:

I run into this bug somewhat regularly in slightly different
circumstances.

I run stretch.  I have multiple graphical logins on different virtual
terminals, and switch between them during the day.  (I disable the
default login manager on tty7; I login in text mode on each virtual
terminal and run 'startx' therein.)

At some point, when I switch from, say, tty7 to tty6, the tty6 Xorg
would segfault.  This seems to occur after ~3 weeks from the last reboot
(I hibernate at the end of each day).  Furthermore, once it happens in
say tty6, it would usually happen in the other tty's too not long after.

To be clear, to me the bug is *not* related to hibernate/suspend;
I usually run into it in the middle of the day.

I'm enclosing the log from today's instance of the crash (uptime
19 days).  Please let me know if there's any further information I can
provide.

Thanks to itd on #debian for his help debugging this.

Cheers,

Daniel

[[[
% tail -79 < ~/.local/share/xorg/Xorg.*.log
[675245.292] (II) AIGLX: Resuming AIGLX clients after VT switch
[675245.383] (II) modeset(0): EDID vendor "SAM", prod id 3256
[675245.383] (II) modeset(0): Using hsync ranges from config file
[675245.383] (II) modeset(0): Using vrefresh ranges from config file
[675245.383] (II) modeset(0): Printing DDC gathered Modelines:
[675245.383] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 
2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[675245.383] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 
1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[675245.383] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 
1980  720 725 730 750 +hsync +vsync (37.5 kHz e)
[675245.383] (II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  
576 581 586 625 -hsync -vsync (31.2 kHz e)
[675245.383] (II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  
480 489 495 525 -hsync -vsync (31.5 kHz e)
[675245.383] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz e)
[675245.383] (II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz e)
[675245.383] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  
480 481 484 500 -hsync -vsync (37.5 kHz e)
[675245.383] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  
480 489 492 520 -hsync -vsync (37.9 kHz e)
[675245.383] (II) modeset(0): Modeline "640x480"x0.0   30.24  640 704 768 864  
480 483 486 525 -hsync -vsync (35.0 kHz e)
[675245.383] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz e)
[675245.383] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  
400 412 414 449 -hsync +vsync (31.5 kHz e)
[675245.383] (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[675245.383] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[675245.383] (II) modeset(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[675245.383] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[675245.383] (II) modeset(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  
624 625 628 667 -hsync -vsync (49.7 kHz e)
[675245.383] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  
600 601 604 625 +hsync +vsync (46.9 kHz e)
[675245.383] (II) modeset(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  
600 637 643 666 +hsync +vsync (48.1 kHz e)
[675245.383] (II) modeset(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 
1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[675245.383] (II) modeset(0): Modeline "1280x720"x60.0   74.48  1280 1336 1472 
1664  720 721 724 746 -hsync +vsync (44.8 kHz e)
[675245.383] (II) modeset(0): Modeline "1280x800"x0.0   71.00  1280 1328 1360 
1440  800 803 809 823 +hsync -vsync (49.3 kHz e)
[675245.383] (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[675245.383] (II) modeset(0): Modeline "1440x900"x0.0   88.75  1440 1488 1520 
1600  900 903 

Bug#916021: [rb-general] Bug#916021: lintian: Please check for references to build directory

[Daniel Shahaf]

[fixing bug's address in Cc]

Dmitry Bogatov wrote on Mon, 10 Dec 2018 19:49 +:
> I believe, most of us keep repositories of git packages somewhere under
> ~/.  For example, for me, ucspi-tcp package is located at
> /home/iu/devel/salsa/ucspi-tcp.
> 
> So my workflow is following:
> 
>  $ cd /home/iu/devel/salsa/ucspi-tcp
>  $ dpkg-buildpackage -us -uc
>  $ lintian
> 
> And here lintian could check, that generated binary packages does not
> contains references to /home/iu/devel/salsa/ucspi-tcp.

So what's the rule?  Lintian should check that the current working
directory lintian runs from doesn't appear in the build output?

This will false positive if lintian is run from the root directory, and
also going to make lintian's own output dependent on the phase of the
moon, in that
.
% lintian ../build-outputs/foo.deb
.
and
.
% cd ../build-outputs
% lintian foo.deb
.
would produce different outputs.  I would say that's undesirable.

(This isn't a made-up example; 'pdebuild -- --buildresult=../build-outputs/'
— that's a verbatim dot-dot meaning the parent directory, not an
ellipsis — is part of my regular workflow.)

However, the buildinfo file already includes the build directory
in the Build-Path header.  Would it be sensible for Lintian to check
that the value of the buildinfo "Build-Path" header doesn't appear in
the .deb's?

Cheers,

Daniel

Bug#913862: vim-addon-manager: Add zsh completion

[Daniel Shahaf]

Package: vim-addon-manager
Version: 0.5.6
Severity: wishlist
Tags: patch upstream
Control: affects -1 zsh-common

Dear Maintainer,

Please add zsh completion to vim-addon-manager by having the package
install the following files:

To /usr/share/zsh/vendor-completions/_vam:
[[[
#compdef vam

# Last updated for vam 0.5.6

local -a args
args=(
'(-h --help)'{-h,--help}'[show this usage message and exit]'
'(-q --query)'{-q,--query}'[be quiet and make the output more 
parseable]'
'(-r --registry-dir)'{-r+,--registry-dir=}'[set the registry 
directory]:registry directory:_directories'
'(-s --source-dir)'{-s+,--source-dir=}'[set the addons source 
directory]:addons source directory:_directories'
'(-t --target-dir)'{-t+,--target-dir=}'[set the addons target 
directory]:addons target directory:_directories'
'(-v --verbose)'{-v,--verbose}'[increase verbosity]'
'(-z --silent)'{-z,--silent}'[silent mode: suppress most of the output]'
'(-y --system-dir)'{-y+,--system-dir=}'[set the system-wide target 
directory]:system-wide target directory:_directories'
'(-w --system-wide)'{-w,--system-wide}'[set target directory to the 
system-wide one]'
'1:subcommand:(list status install remove disable enable files show)'
'*: :_vam_plugins'
)

_arguments -s -S : "$args[@]"
}
]]]

To /usr/share/zsh/vendor-completions/_vam_plugins:
[[[
#autoload

local expl
_wanted vim-addons-manager-plugins expl 'vim plugins managed by 
vim-addons-manager' compadd - $(_call_program vam-list 'vam list --query 
--silent')
]]]

With these two files in place, «vam » completes subcommands,
options, and addons.

Cheers,

Daniel

Bug#913860: editorconfig-core: man page does not describe semantics

[Daniel Shahaf]

Package: editorconfig-core
Version: 0.12.1-1.1
Severity: minor
Tags: upstream

Dear Maintainer,

The editorconfig(1) man page describes the syntax of the command, but
not its semantics.

The man page does say that the positional argument are filenames and
that there must be at least one of them, and that the output is in ini
format; however, it does not say what the command does.  The man page
should state (at least briefly) what's the relation between the input
files and the output.  For example, compare the very first sentence of
the grep(1) man page:

   SYNOPSIS
  grep [OPTIONS] PATTERN [FILE...]
   
   DESCRIPTION
  grep searches the named input FILEs for lines containing a match 
to the
  given PATTERN.

Cheers,

Daniel

Bug#912756: diffoscope: Test failures with upcoming upstream file(1) version 5.35

[Daniel Shahaf]

Control: tags -1 patch

Christoph Biedl wrote on Sat, Nov 03, 2018 at 16:13:58 +0100:
> -diffoscope-104/tests/data/test2.pcap: tcpdump capture file (little-endian) - 
> version 2.4 (Ethernet, capture length 262144)
> +diffoscope-104/tests/data/test2.pcap: pcap capture file, microsecond ts 
> (little-endian) - version 2.4 (Ethernet, capture length 262144)

Untested patch:

diff -ru diffoscope-104/diffoscope/comparators/pcap.py 
diffoscope-104.new/diffoscope/comparators/pcap.py
--- diffoscope-104/diffoscope/comparators/pcap.py   2018-10-15 
10:09:05.0 +
+++ diffoscope-104.new/diffoscope/comparators/pcap.py   2018-11-03 
17:04:03.749507655 +
@@ -40,7 +40,9 @@
 
 class PcapFile(File):
 DESCRIPTION = "tcpdump capture files (.pcap)"
-FILE_TYPE_RE = re.compile(r'^tcpdump capture file\b')
+# The regexp covers both libmagic<5.35 and libmagic>=5.35.
+# See https://bugs.debian.org/912756
+FILE_TYPE_RE = re.compile(r'^(tcpdump|pcap) capture file\b')
 
 def compare_details(self, other, source=None):
 return [Difference.from_command(

Cheers,

Daniel