Bug#347801: vim-runtime: syntax highlighting for slrnrc doesn't know a few function names

[Frank Terbeck]

Package: vim-runtime
Version: 1:6.4-006+1
Severity: minor
Tags: patch

When I was reviewing my slrn configurationfile, I realized that vim did
not recognize all functions bindable with setkey.

The unknown functions were:
readline functions:
complete, cycle, delbol, delbow

article function:
toggle_sort

The fix is trivial:

--- slrnrc.vim.old  2006-01-12 19:18:30.0 +0100
+++ slrnrc.vim  2006-01-12 19:15:47.0 +0100
@@ -119,7 +119,7 @@
 syn keyword slrnrcFunArt   contained help hide_article locate_article 
mark_spot next next_high_score next_same_subject pipe post post_postponed 
previous print quit redraw
 syn keyword slrnrcFunArt   contained repeat_last_key reply request save 
show_spoilers shrink_article_window skip_quotes skip_to_next_group 
skip_to_previous_group
 syn keyword slrnrcFunArt   contained subject_search_backward 
subject_search_forward supersede suspend tag_header toggle_collapse_threads 
toggle_header_formats
-syn keyword slrnrcFunArt   contained toggle_header_tag toggle_headers 
toggle_pgpsignature toggle_quotes toggle_rot13 toggle_signature 
toggle_verbatim_marks
+syn keyword slrnrcFunArt   contained toggle_header_tag toggle_headers 
toggle_pgpsignature toggle_quotes toggle_rot13 toggle_signature 
toggle_verbatim_marks toggle_sort
 syn keyword slrnrcFunArt   contained toggle_verbatim_text uncatchup 
uncatchup_all undelete untag_headers view_scores wrap_article 
zoom_article_window
 
 " Listed for removal
@@ -136,7 +136,7 @@
 syn keyword slrnrcFunGroup contained down group_bob group_eob pagedown 
pageup toggle_group_display uncatch_up up
 
 " Functions in readline mode (actually from slang's slrline.c)
-syn keyword slrnrcFunRead  contained bdel bol del deleol down enter eol 
left quoted_insert right self_insert trim up
+syn keyword slrnrcFunRead  contained bdel bol complete cycle del delbol 
delbow deleol down enter eol left quoted_insert right self_insert trim up
 
 " Binding keys
 syn keyword slrnrcSetkeyObjcontained article group readline

Regards, Frank

-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim  1:6.4-006+1 Vi IMproved - enhanced vi editor

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405355: PATCH: _aptitude

[Frank Terbeck]

Clint Adams <[EMAIL PROTECTED]>:
> > +function _aptitude_release() {
> > +  #{{{
> > +  local expl releases
> > +  releases=(
> > +${${(M)${(f)"$( > +:#[ $'\t']#deb(|-src)*}/(#b)[ $'\t']#[^ $'\t']##[ $'\t']##[^ $'\t']##[ 
> > $'\t']##([^ $'\t']##)*/$match[1]}
> > +  )
> > +  _wanted list expl release compadd ${expl} - ${(u)releases}
> > +  #}}}
> > +}
> > +
> 
> Committing this, though this is not the same mechanism for completing
> releases as used in _apt.

True. But I currently don't see the actual benefit in parsing
'apt-cache dump' instead of reading 'sources.list'. Are there any
regular uses that would justify such an expensive action?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405355: zsh: updated _aptitude

[Frank Terbeck]

Package: zsh
Version: 4.3.2-25
Severity: wishlist
Tags: patch

Hi,
I submitted an update for _aptitude to zsh-workers in October of last
year, which has was ignored. I've been using this updated completion
since then without problems. So, I'm resubmitting the patch to you,
because I guess you are more or less responsible for debian specific
completions anyway.

If I'm trying something stupid, feel free to tell me. :-)

Regards, Frank

[snip]
--- _aptitude.orig  2007-01-02 21:35:47.0 +0100
+++ _aptitude   2007-01-02 21:32:47.0 +0100
@@ -2,6 +2,15 @@
 
 local curcontext="$curcontext" state line cmds ret=1
 
+function _aptitude_release() {
+  local expl releases
+  releases=(
+${${(M)${(f)"$(cmds' \
   '*: :->args' && ret=0
 
[snap]

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18.3suspend2+ipw2200
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages zsh depends on:
ii  debconf [debconf-2.0]1.5.11  Debian configuration management sy
ii  libc62.3.6.ds1-9 GNU C Library: Shared libraries
ii  libncurses5  5.5-5   Shared libraries for terminal hand

Versions of packages zsh recommends:
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libpcre3  6.7-1  Perl 5 Compatible Regular Expressi

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407294: cmus 2.1.0 available. Please update

[Frank Terbeck]

Package: cmus
Version: 2.0.4-1
Severity: wishlist

Version 2.1.0 of cmus is available¹.
Updating would fix #399965 as well as #378194. So, I guess that would be
a good idea.

Maybe you already know about this and just want to wait until after etch
is released. If so, feel free to ignore me. :-)

Regards, Frank

¹ 

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18.3suspend2+ipw2200
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Bug#400576: wyrd: respect setting of $VISUAL in default config

[Frank Terbeck]

Package: wyrd
Version: 1.4.1-2
Severity: minor
Tags: patch

The current default wyrdrc uses $EDITOR as its main source for
information about the desired editor. Many people set editor to a
line-oriented editor like 'ed' and $VISUAL to their prefered fullscreen
editor.

The included patch uses $VISUAL (if set and non-empty) and uses $EDITOR
as a fallback solution.

Regards, Frank

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.19-rc3suspend2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages wyrd depends on:
ii  less 394-4   Pager program similar to more
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libncurses5  5.5-5   Shared libraries for terminal hand
ii  remind   03.00.24-4  a sophisticated reminder service

wyrd recommends no packages.

-- no debconf information
--- wyrdrc.orig 2006-11-27 11:42:27.0 +0100
+++ wyrdrc  2006-11-27 11:42:35.0 +0100
@@ -5,11 +5,11 @@
 # the default reminder file to display
 set reminders_file="~/.reminders"
 # command for editing an old appointment, given a line number %line% and 
filename %file%
-set edit_old_command="$EDITOR +%line% %file%"
+set edit_old_command="${VISUAL:-$EDITOR} +%line% %file%"
 # command for editing a new appointment, given a filename %file%
-set edit_new_command="$EDITOR +99 %file%"
+set edit_new_command="${VISUAL:-$EDITOR} +99 %file%"
 # command for free editing of the reminders file, given a filename %file%
-set edit_any_command="$EDITOR %file%"
+set edit_any_command="${VISUAL:-$EDITOR} %file%"
 
 
 # templates for creating new appointments

Bug#419048: ITP: fdm -- fetching, filtering and delivering emails

[Frank Terbeck]

Package: wnpp
Severity: wishlist
Owner: Frank Terbeck <[EMAIL PROTECTED]>

* Package name: fdm
  Version : 1.1
  Upstream Author : Nicholas Marriott <[EMAIL PROTECTED]>
* URL : http://fdm.sf.net
* License : ISC
  Programming Lang: C
  Description : fetching, filtering and delivering emails

 fdm is a program to fetch mail and deliver it in various ways
 depending on as user-supplied ruleset. Mail may be fetched from
 stdin, IMAP or POP3 servers, or from local maildirs, and filtered
 based on whether it matches a regexp, its size or age, or the output
 of a shell command. It can be rewritten by an external process,
 dropped, left on the server or delivered into maildirs, mboxes, to a
 file or pipe, or any combination.
 .
 fdm is designed to be lightweight but powerful, with a compact but
 clear configuration syntax. It is primarily designed for single-user
 uses but may also be configured to deliver mail in a multi-user
 setup. In this case, it uses privilege separation to minimise the
 amount of code running as the root user.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.19.2-suspend2+ipw2200 (PREEMPT)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419089: groff -mdoc warns about unknown keyword '-ragged' in .Bd macro.

[Frank Terbeck]

Package: groff
Version: 1.18.1.1-12
Severity: normal

When packaging fdm¹, lintian told me about a warning in one of the
program's manpages:

[snip]
fdm: manpage-has-errors-from-man usr/share/man/man5/fdm.conf.5.gz Unknown 
keyword `-ragged' in .Bd macro (#590)
[snap]

I can reproduce this using both 'man' and 'groff':

[snip]
% man -l fdm-1.1/fdm.conf.5 > /dev/null
mdoc warning: Unknown keyword `-ragged' in .Bd macro (#590)
% groff -mdoc fdm-1.1/fdm.conf.5 > /dev/null
mdoc warning: Unknown keyword `-ragged' in .Bd macro (#590)
[snap]

Here is the offending part of fdm.conf.5²:

[snip]
Once defined, a macro may be used in any place a string or number is expected.
Macros may be embedded in strings by surrounding their name (after the $ or %)
with {}s, like so:
.Bd -ragged -offset indent
"abc ${mymacro} %{anothermacro} def"
.Ed
[snap]

I don't see why this is throwing a warning, as '-ragged' for '.Bd' is
documented in groff_mdoc(7):

[snip]
 .Bd  Begin display.  The '.Bd' display must be ended with the '.Ed'
   macro.  It has the following syntax:

 .Bd {-literal | -filled | -unfilled | -ragged | -centered}
  [-offset ] [-file ] [-compact]

   -ragged   Fill, but do not adjust the right margin (only
 left-justify).
[snap]

Any ideas/clues/fixes?

Regards, Frank

¹ 
² 

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.19.2-suspend2+ipw2200 (PREEMPT)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages groff depends on:
ii  groff-base  1.18.1.1-12  GNU troff text-formatting system (
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libgcc1 1:4.1.1-21   GCC support library
ii  libice6 1:1.0.3-2X11 Inter-Client Exchange library
ii  libsm6  1:1.0.1-3X11 Session Management library
ii  libstdc++6  4.1.1-21 The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxaw7 1:1.0.2-4X11 Athena Widget library
ii  libxext61:1.0.1-2X11 miscellaneous extension librar
ii  libxmu6 1:1.0.2-2X11 miscellaneous utility library
ii  libxpm4 1:3.5.5-2X11 pixmap library
ii  libxt6  1:1.0.2-2X11 toolkit intrinsics library

Versions of packages groff recommends:
ii  gs  8.54.dfsg.1-5Transitional package
ii  gs-gpl [gs] 8.54.dfsg.1-5The GPL Ghostscript PostScript int
ii  imagemagick 7:6.2.4.5.dfsg1-0.14 Image manipulation programs
ii  libpaper1   1.1.21   Library for handling paper charact
pn  netpbm (no description available)
pn  psutils(no description available)

-- no debconf information

Bug#394818: zsh: _tar_archive and GNU tar fails to complete uncompressed archives

[Frank Terbeck]

Package: zsh
Version: 4.3.2-21
Severity: normal

This bug was reported upstream in ZW#22584¹ and is fixed in the upstream
CVS. Please include the updated version in the debian package.

Regards, Frank

¹ 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18.1suspend2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages zsh depends on:
ii  debconf [debconf-2.0]1.5.6   Debian configuration management sy
ii  libc62.3.6.ds1-7 GNU C Library: Shared libraries
ii  libncurses5  5.5-5   Shared libraries for terminal hand

Versions of packages zsh recommends:
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libpcre3  6.7-1  Perl 5 Compatible Regular Expressi

-- no debconf information

Bug#733075: zsh: command completion not working after semicolon

[Frank Terbeck]

Hello Jay!

Jay Berkenbilt wrote:
> Usually when I type a command followed by ;, after the ;, zsh is back
> to a state where TAB should complete on commands again.  This is
> pretty basic completion behavior.  After I upgraded to 5.0.4-1, I
> observed that this was no longer working.  As soon as I type a ;,
> completion reverts to simple path completion.

Ungh. This is annoying. :-/

What version did you upgrade from? I'm seeing this behaviour in an older
development snapshot (zsh-5.0.2-174-g8a70a98) on my laptop as well. A
much older (4.3.10) version behaves properly.

> I observe this with my elaborate customizations and also with zsh -f.
> I have not looked into it, but it seems so fundamental, I thought it
> was worth reporting right away in case there's a real issue here.

I see. Same here.

Note however, that after "zsh -f" there is another completion system in
place (yes, zsh has two of them: compctl [the very old one] and compsys
[the slightly less old one]). To enable compsys in a plain "zsh -f"
instance, you can always run this:

  zsh% autoload -Uz compinit
  zsh% compinit

I wonder why compctl and compsys are both broken...


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925


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

Bug#733075: Bug#733075: zsh: command completion not working after semicolon

[Frank Terbeck]

Hey Richard!

Richard Hartmann wrote:
> Seems we worked in parallel here; I already confirmed and forwarded to
> zsh-workers.

Seems like it. :-)

> 5.0.2-6 was not affected.

I git-bisected this to:

[568e0db7a964feefa45061967d0c7079a0e59c1e]
  31611: attempt to fix crash completing redirection in do loop

The relevant zsh-workers thread is:
  http://www.zsh.org/mla/workers/2013/msg00652.html


This is in zle_tricky.c, so naturally I'm afraid to touch it. :)

Regards, Frank


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

Bug#418199: Fwd: Re: segfault with exceedingly long path [origin: schae...@brasslantern.com]

[Frank Terbeck]

Goswin von Brederlow wrote:
> On Sat, Jan 18, 2014 at 10:19:39AM +0100, Axel Beckert wrote:
[...]
>> upstream said, this is an issue which is "unlikely ever to be fixed".
>> Marking as such.
[...]
> From: Bart Schaefer :
>> [...]  Various parts
>> of the shell rely on system limits such as PATH_MAX which cannot be
>> dynamically changed.  There's a comment with some explanation around
>> lines 109-137 of Src/compat.c.
[...]
> Could you fix that in Debian even if upstream doesn't care? A segfault

Fixing it in debian and not upstream is very unlikely. It is not like
upstream doesn't care. It's much more that the underlying problem is
quite hard to fix correctly in the current code. If we had a proper fix,
they would take it faster than you can say "ouch, that was a segfault.".

> is never right. If zsh can't handle the long path then it must check

Yes, they are never right. Bart Schaefer from upstream (who said that is
unlikely to be fixed) knows that as well. He also send a patch that
should stop the shell from segfaulting in this particular case:

  http://www.zsh.org/mla/workers/2014/msg00085.html

But this is currently more like plucking holes than fixing the
underlying problem; i.e. the reliance on static system limits like
PATH_MAX.

> the length and give an error. Not fixing a segfault is imho
> unacceptable.

As always, send patches.

Regards, Frank


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

Bug#717002: zsh: Update for git-buildpackage completion

[Frank Terbeck]

Hey,

with my pkg-zsh hat on, here are some thoughts:

Guido Günther wrote:
> On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote:
>> On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat  wrote:
>> >  ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler  :
[...]
>> >> Unfortunately my completion foo is quite limited, so they are not as
>> >> good as they could be (multiple pq commands are allowed;
>> >> cannot detect when to require a dsc or a package name in import-dsc and
>> >> others).
>> >>
>> >> I still think the result is somewhat useful.
>> >
>> > It is working fine for me. Maybe this could be shipped with gbp instead?

The three options are: a) Shipping the completion separately (which is
the worst possible solution; b) have it shipped with gbp; and c) have it
shipped with zsh.

Upstream zsh welcomes additions to the pool of available completion
functions. Debian already has its own sub-directory within that pool, so
adding ‘_gbp’ to that pool would be a natural thing to do. The advantage
of that would be, that knowledgeable eyes at least scan the code you
submit. On the flip-side, you'd have to regularly sync your version of
the completion with zsh's repository, because nobody gains anything from
massively outdated completion functions.


>> GBP maintainers, would you mind adding this file to the gbp package?
>> It's a start for a zsh completion, but it is already useful.

If you choose to ship ‘_gbp’ with gbp itself, the advantage would be
that you'd ship a completion that always exactly matches the command
line interface of the software - if you keep the completion up to date.

Debian's zsh package provides an $fpath entry for other packages to drop
completion function files into. That entry was introduced to
specifically support completions that are shipped with the target
software rather than with upstream zsh. That directory would be:

  /usr/share/zsh/function/vendor-completions

For completeness, if you want to ship non-completion functions, the
directory to use would be:

  /usr/share/zsh/function/vendor-functions


> If somebody submits a patch I'd be happy to. I do wonder why you
> hardcode the options though instead of parsing it from the command's
> --help output?

The idea is usually to provide context-specific completion depending on
the option-set. That's why you often need to name the options anyway
since the following code-paths depend on them. By context-sensitive, I
mean for example, with git's completion, "git add " only shows
files that are not .gitignored and either not tracked yet or contain
changes. To identify that context, the completion needs to know about
‘add’.

Those are my 2¢.

Regards, Frank


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

Bug#727222: debian/patches/38-linux-3.11-sf.patch

[Frank Terbeck]

The fix James proposes does indeed fix the issue for me.

I'm attaching the patch-file I used as

  debian/patches/38-linux-3.11-sf.patch

for convenience.

Regards, FrankDescription: Import upstream fix for shared folders with linux 3.11

 Apparently, listing directories in shared folders with linux kernel
 version 3.11 causes the application requesting the directory list to
 enter a busy loop.  This is the indended fix from upstream's VCS.

Author: Virtualbox Upstream
Bug-Debian: http://bugs.debian.org/727222
Upstream-Fix-URL: https://www.virtualbox.org/changeset/48529/vbox

--- virtualbox-4.2.16-dfsg.orig/src/VBox/Additions/linux/sharedfolders/dirops.c
+++ virtualbox-4.2.16-dfsg/src/VBox/Additions/linux/sharedfolders/dirops.c
@@ -282,10 +282,13 @@ static int sf_dir_read(struct file *dir,
 }
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 11, 0)
-err = dir_emit(ctx, d_name, strlen(d_name), fake_ino, DT_UNKNOWN);
+if (!dir_emit(ctx, d_name, strlen(d_name), fake_ino, DT_UNKNOWN))
+{
+LogFunc(("dir_emit failed\n"));
+return 0;
+}
 #else
 err = filldir(opaque, d_name, strlen(d_name), dir->f_pos, fake_ino, DT_UNKNOWN);
-#endif
 if (err)
 {
 LogFunc(("filldir returned error %d\n", err));
@@ -293,6 +296,7 @@ static int sf_dir_read(struct file *dir,
only when it runs out of space in opaque */
 return 0;
 }
+#endif
 
 dir->f_pos += 1;
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 11, 0)

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Sorry for the delay; hardware died on me...

Robert Millan wrote:
> The rest of the blob is OK but mremap() is Linux-specific.

I'll take your word for it.

> Here's a fixed patch (tested and known to build).

Thanks, applied to .

> Btw, instead of shipping your own strlcat() / strlcpy() / strtonum()
> you could use the ones in libbsd and save some package size.

Yeah, I know. If upstream would move there, I'd obviously follow. But
just for fdm in debian, I don't think the small benefit is worth the
effort.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#692785: zsh: '.zprofice' typo in zshrc

[Frank Terbeck]

Michael Terry wrote:
> Package: zsh
> Version: 5.0.0-2
[...]
> Ubuntu user Logan Rosen provided the attached patch to fix a typo in
> debian/zshrc.  ".zprofice" should be ".zprofile".

Hey there,

this does not apply to the debian package, since we don't call
`compinit' under any circumstances in the global zshrc¹.

>  # If you don't want compinit called here, place the line
>  # skip_global_compinit=1
> -# in your $ZDOTDIR/.zshenv or $ZDOTDIR/.zprofice
> +# in your $ZDOTDIR/.zshenv or $ZDOTDIR/.zprofile

Also, the comment isn't quite right. I'd leave the mention of
`.zprofile' out entirely, because using it would only work for zsh
instances that are interactive shells AND login shells. If the shell
wouldn't be a login shell, setting something in that file doesn't have
any effect whatsoever.

Regards, Frank

¹ 
http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/zshrc;hb=HEAD


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

Bug#685511: zsh: /etc/zsh/zshrc brokes return on numpad

[Frank Terbeck]

sergio wrote:
[...]
> Version: 5.0.0-2
>
> After upgrade to 5.0 numpad return (KP_Enter) key doesn't work anymore.

Yes. This is due to our reimplementation of keyboard handling within the
global zshrc file of the 5.0.0 packages.

What we did is enable application mode in the terminal, when the line
editor is active. Doing that is the right thing, because only then are
the entries in `$terminfo' correct.

Now as for KP_Enter: The corresponding terminfo capability for that key
is `kent', so the  following will work:

  % bindkey "${terminfo[kent]}" accept-line

However, not all terminals include `kent' in their terminfo entries.
Notably, the `screen' entry (used by terminal multiplexers such as GNU
screen and tmux) does not. So it's hard to bind that key properly.

You could fallback to the value from the `xterm' entry and hope every
other terminal follows xterm's lead... but what are the changes of that
happening? Anyway, here's a snippet that might work in many cases (at
least for xterm and urxvt with or without screen/tmux running inside):

[snip]
if (( ${+terminfo[kent]} )); then
kent="${terminfo[kent]}"
else
kent=$(TERM=xterm echoti kent 2>/dev/null)
# If there is nothing in `$kent' yet, use "ESC O M", which is
# what xterm and urxvt use.
[[ -z "$kent" ]] && kent=$'\eOM'
fi
bindkey "$kent" accept-line
unset kent
[snap]

A little too hacky for debian's global zshrc, I think.

Regards, Frank


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

Bug#654444: zsh: `q' flag for paramater expansion does not work as advertised

[Frank Terbeck]

Samuel Bronson wrote:
> Frank Terbeck wrote:
>> Samuel Bronson wrote:
[...]
>>> | naesten@hydrogen:~/hacking/crawl/crawl-ref/source% echo -n ${(q)$(echo | 
>>> -e "\e")}|hd
>>> |   24 27 1b 27                                       |$'.'|
>>> | 0004
[...]
>> zsh% printf '%s\n' ${(q)$(echo -e "\e")}
>> $'\033'
>
> Oh, really? Leaves one wondering about the point of "echo -e"...

Not really. The problem is not the inner, but the outer echo. The inner
echo ($the >$(echo -e "\e")<)produces an actual escape character (0x1b).

The (q) produces an octal escape in $'...' quotes (0x1b == 033o). The
outer echo sees the octal escape and interprets it, producing a literal
ASCII escape character again.

Echo is like that - or not, depending on the shell in question. Even
POSIX says:

[SUSv3, echo]
  New applications are encouraged to use printf instead of echo.
[...]
  The echo utility has not been made obsolescent because of its
  extremely widespread use in historical applications. Conforming
  applications that wish to do prompting without s or that
  could possibly be expecting to echo a -n, should use the printf
  utility derived from the Ninth Edition system.
[/SUSv3]

In other words: `echo' is crap. We've just not removed it, because it's
in heavy use. If you want consistent predictable behaviour, use
`printf'.

If you're wondering why zsh's `echo' has the `-e' option at all,
although it interprets the escape sequences anyway, then the answer is:
Because zsh tries to please everyone. There is an `-E' option, that
disables the escape sequences effect. And there's a `BSD_ECHO' option,
that makes that behaviour the default for zsh's `echo'. In order to get
the interpreting behaviour with that option set, the `-e' option is
provided.

This is yet another reason not to use echo. Different shells have
annoyingly different echos and in zsh you can even alter its behaviour
by options.

I hope that clears things up.

Regards, Frank



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

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Just for the record: This issue is fixed upstream by now and will be in
the next version of the package.



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

Bug#463507: Triage

[Frank Terbeck]

A. Costa wrote:
[...]
> Still there in 'zsh' v4.3.15-1.  Example: I typed
> what's above the carets and the Tab key, then the line
> looks like:
>
>   ls -_main_complete:166: permission denied: 
>   

Please do this:

  % rm ~/.zcompdump
  % zsh -f
  (and in that new shell)
  % autoload -Uz compinit
  % compinit
  % ls -

That should work. Sometimes, when `~/.zcompdump' is outdated, weird
issues have been known to appear. If you can still reproduce the problem
with the above recipe, I'd be interested in how your system differs from
other people's systems.

If you cannot, your zsh setup is broken.

Needless to say, I can't reproduce the issue.

Regards, Frank



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

Bug#658223: zsh: 'man zshmisc' typo: "defintions"

[Frank Terbeck]

tags 658223 + fixed-upstream
thanks

A. Costa wrote:
[...]
> Found a typo in '/usr/share/man/man1/zshmisc.1.gz', see attached '.diff'.
> Hope this helps...
[...]
> --- zshmisc.1 2012-01-22 18:15:59.0 -0500
[...]


Thanks for noticing!

Zsh's manual is not in roff format, though. It's in yodl format, from
which all destination formats are generated. I've committed a fix to the
right files upstream¹, therefore it'll be in zsh's next version. Thanks
again.

Regards, Frank

¹ 




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

Bug#645112: Full error message and a patch from Ubuntu

[Frank Terbeck]

Sven Joachim wrote:
> | checking for library containing tigetflag... no
> | checking for library containing tgetent... no
[...]
> Ubuntu has hit this bug as well, see [1].  The attached patch against
> git is stolen from [2], with the commit message edited to close the
> Debian bug for your convenience.

Full service bug report. Thanks! ;)

> Note that libtinfo is only available since ncurses 5.9-2, so you should
> probably bump the libncursesw5-dev build-dependency.  Or come up with
> something more sophisticated if you want the package to build unmodified
> in Squeeze.
[...]
> -CONFIGFLAGS += --with-tcsetpgrp --with-term-lib="ncursesw"
> +CONFIGFLAGS += --with-tcsetpgrp --with-term-lib="ncursesw tinfo"

Actually, that's exactly the right thing to do. `--with-term-lib='
should test all listed libraries for the required functions, but it'll
stop as soon as it finds a library that satisfies the needs. And if
that's `ncursesw', then the build system will be happy.

FWIW, I tested building the package with the altered setting on one of
my stable systems and it builds fine.

Regards, Frank



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

Bug#176626: screen: mini-curses type of interface for screen -r w/ multiple screens?

[Frank Terbeck]

Axel Beckert wrote:
[...]
> zsh, at least with grml's zshrc, allows proper tab completion for
> screen sessions:

There is nothing special about this completion (because you mentioned a
certain setup file).



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

Bug#578466: Shouldn't correct to "rm" too easily

[Frank Terbeck]

A. N. Other wrote:
> You can use the variable CORRECT_IGNORE to exempt commands from
> correction. E.g.:
>
> CORRECT_IGNORE="_*|rm"

I'm firmly against doing such configuration in the global configuration
file (which is doing too much already - but that's another problem).

It is something the user should decide for her/himself.

Regards, Frank



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

Bug#631689: fdm: FTBFS with ld --as-needed

[Frank Terbeck]

Ilya Barygin wrote:
[...]
> The package fails to build when --as-needed linker option is enabled,
> because of incorrect order of parameters passed to ld. Here's a log of
> failed build in Ubuntu:
>
> https://launchpadlibrarian.net/71869810/buildlog_ubuntu-oneiric-i386.fdm_1.6-4build1_FAILEDTOBUILD.txt.gz
>
> See also
> http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
>
> The attached patch was used in Ubuntu to fix the problem.
> https://launchpad.net/ubuntu/+source/fdm/1.6-4ubuntu1

Oops. Sorry for taking forever. I was sure I already answered to this
one... Anyway, that patch looks right, and the upstream Makefile¹
handles it like that already.

I'll query upstream about a new release. ...the last one has been a
while. If that should not happen in due time, I'll include this patch in
the package.

Regards, Frank





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

Bug#639176: fdm: FTBFS: unsatisfiable build-dependency: tdb-dev (>= 1.1.1~svn26294-1.1) (versioned dep on a virtual pkg?)

[Frank Terbeck]

[...]
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-fdm-dummy : Depends: tdb-dev (>= 1.1.1~svn26294-1.1)

Right.

That should be replaced with "libtdb-dev" nowadays, I guess. I'll be
preparing an updated package as soon as spare time permits.

Regards, Frank



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

Bug#720707: RFP: grml-zsh-config -- zsh configuration that ships with the Debian-based grml distro

[Frank Terbeck]

Thomas Koch wrote:
> thank you very much for taking this! Your question about "how the zshrc will 
> be provided" is so common that I proposed a general solution:
>
> http://lists.alioth.debian.org/pipermail/soc-coordination/2012-February/001156.html
>
> In short and for the start I'd say: just put the files under /usr/share/grml-
> zsh-config and provide a shell script that adds the necessary symlinks from 
> my 
> current homedir. It's already a big improvement to have the files in the 
> archive and to get updates.

Yes, thank you! Not having the add-on configuration in /etc sounds like
the right thing to do, because then things can remain in the hands of
the package system.

> Once there is a canonical location for grml-zsh-config I already have my 
> first 
> wishlist items:
>
> - Integrate vcsh into the prompt

Grml's zsh setup uses a rather extensible prompt (since the last few
releases). Generally, I'd like to not include too many special purpose
code in grml's main configuration, because it is already quite large and
complex.

There are some facilities to implement special-purpose prompt support
with grml's new prompts, though. There is an example, that adds
virtual-env support:

  http://bewatermyfriend.org/p/2013/003/

Adding support for vcsh should be fairly straight forward. (Support for
it could also be done via vcs_info and its hook subsystem.)

> - make it configurable whether the name of the VCS is shown. I use git 
> exclusively so I'm just interested in the branch name.

Grml's VCS information is provided by zsh's vcs_info system. That system
is pretty configurable¹ and your wish is already easily solved. You just
need to acknowledge, that grml's setup uses two vcs_info formats: One
for its prompt and the other for setting titles in GNU screen and tmux
based on the currently checked out branch.

  zstyle ':vcs_info:*' formats '[%b] ' 'zsh: %r'
  zstyle ':vcs_info:*' actionformats '[%b|%a] ' 'zsh: %r'

Add colouring to your preference. ;)

Regards, Frank

¹ man zshcontrib | less -p GATHER


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

Bug#724721: zsh: Tab completion error with vi

[Frank Terbeck]

Hi Ludovic,

Ludovic Lebègue wrote:
[...]
> While using zsh shell trying to autocomplete with tab key display the 
> following
> message instead of showing the files in the current directory :
>
> ludo@leonardo ~ % vi
> _arguments:450: _vim_files: function definition file not found

Did this happen after updating zsh? What's the old zsh version?

In any case, what's the output of following?

  % head ~/.zcompdump


Problems like this are usually cause by that cache file being out of
date and something is keeping an automatic rebuild from happening.

If you remove the file and restart the shell, the problem should be
gone.

Regards, Frank


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

Bug#631689: Bug#639176: fdm: diff for NMU version 1.6-4.1

[Frank Terbeck]

gregor herrmann wrote:
> I've prepared an NMU for fdm (versioned as 1.6-4.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Hey gregor,

I actually got an updated package ready since about a month. I just
didn't get to asking my sponsor to upload it yet. The updated code is
here:

  

An appropriate .orig.tar.gz file is here:

  

All that is based on a CVS snapshot from upstream, which is very and
upstream could release as a new version. (I asked the developer about
this a while back, and he said that technically there's nothing that
would forbid releasing the code. He is just very busy and can't make
time ATM.) - Anyway, the updated package would address both bugs you're
addressing.


I'm unsure about what the procedure is now that you got an NMU in the
pipeline.

Regards, Frank



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

Bug#639176: Bug#631689: Bug#639176: fdm: diff for NMU version 1.6-4.1

[Frank Terbeck]

gregor herrmann wrote:
> On Wed, 09 Nov 2011 18:41:51 +0100, Frank Terbeck wrote:
[...]
>> I'm unsure about what the procedure is now that you got an NMU in the
>> pipeline.
[...]
> minor things I'd change (e.g. remove the quilt build-dep)
[...]

Yes, good point. I should have done that, when I removed the other
native-quilt stuff. That was kind of the point. ;)

> The package doesn't build twice. Output:
[...]
> dpkg-source: info: local changes detected, the modified files are:
>  fdm-1.6+cvs20111013/MANUAL
> dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/fdm_1.6+cvs20111013-1.diff.HRWH5Z
> dpkg-source: info: you can integrate the local changes with dpkg-source 
> --commit
> dpkg-buildpackage: error: dpkg-source -b fdm-1.6+cvs20111013 gave error exit 
> status 2
>
>
> Quick guess: MANUAL get's created during build, and it should be
> removed again in clean (or the upstream build system needs a patch to
> remove it during clean).

Yes, true again. And quite correctly guessed.

I'm doing most of my work on my laptop, where I'm running stable. The
dpkg-source there doesn't pass `--abort-on-upstream-changes' per
default, which is why I never saw this.

I added a "debian/source/local-options" file to add that option.

> Just decide which option you prefer :)

Well, I prefer whichever gets this over with the fastest. ;)

If you've got the time, I wouldn't mind if you'd just uploaded an
updated package. The github repo contains additional changes, which
addresses the issues you've raised.

If you see any other problems, shout. :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Hi there,

Christoph Egger wrote:
> Package: src:fdm
> Version: 1.6+cvs20111013-1
[...]
> Your package failed to build on the kfreebsd-* buildds:
[...]
> test -f config.mk || sh configure
> Unable to configure for GNU/kFreeBSD

Yeah well, `fdm' uses a simple configure script now to setup the build
for a number of known systems. The old system did have support for the
BSD flavours of debian.

I think the `Linux' setup should do the trick (that's what the old build
system did anyway). Could you try if the following patch makes the
package build again? (Also: Is there a still netbsd port? If not the
pattern I used could also be "Linux|GNU/kFreeBSD)").

Regards, Frank


diff --git a/configure b/configure
index 9d83f6b..812ba5b 100755
--- a/configure
+++ b/configure
@@ -26,7 +26,7 @@ EOF
 EOF
;;
 # 
--
-Linux)
+Linux|GNU/k*BSD)
cat <>$CONFIG_H
 #define HAVE_SETRESUID
 #define HAVE_SETRESGID



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

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Robert Millan wrote:
> 2011/11/9 Frank Terbeck :
>> +    Linux|GNU/k*BSD)
>
> Maybe better use:
>
> Linux|GNU|GNU/*)
>
> this way it works on GNU/Hurd and possibly other GNU-ish systems.

Fine by me. Do you happen to know whether this actually fixes the build
on kfreebsd? If it does I'll fix the package and forward a patch
upstream.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
> I could not get multibyte support to work in zsh, even if I had a, what
> seemed to me, perfectly working utf-8 environment. I then checked the
> output from the "locale" command and noticed that all my LC_.* variables
> were set to "da_DK.utf8" whereas the $LANG variable missed the "utf8"
> extension. As soon as I changed it to include this extension, then
> multibyte support worked. As noted, the lack of this setting has not
> affected me at all except in zsh (multibyte support worked fine in bash
> for instance). I believe that zsh should check both the values of the
> LC_CTYPE variable and the LANG variable.

Locale settings work like this: LC_* variables control the different
pieces of the puzzle, when one of those is not set `LANG' is used as a
fallback. `LC_ALL' is special, because it overrides all other LC_*
variables and `LANG' becomes meaningless.

[...]
> Locale: LANGÚ_DK.utf8, LC_CTYPEÚ_DK.utf8 (charmap=UTF-8) (ignored: LC_ALL set 
> to da_DK.utf8)

You're setting `LC_ALL'. So the setting of `LANG' shouldn't matter at
all.

I've got one system that only sets "LC_CTYPE=en_US.UTF8" to something
UTF-8-ish and that works for me (LC_* set to `POSIX' - LANG and LC_ALL
both unset).

I did take a quick look at the involved code and I didn't see anything
obviously wrong with it. `LANG' should *not* matter with `LC_ALL' set.
If it does, that's a bug.

Can you give a minimal zsh setup and a simple way to trigger the problem
you're seeing for further inspection?

Regards, Frank



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

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
> I attach my rather small zshrc.

Nothing in that file is relevant to this issue.

> ~/.zshenv is a symlink to ~/.environment
> which just set a lot of environment variables. It is there that I now
> specifiy the LANG variable which makes zsh behave correctly.

That would be relevant then. What are you doing in there? Are you
exporting the parameters you're setting or not? Which parameters are you
setting (only locale-related parameters matter)?

> zprofile and
> zlogin are empty. On a sidenote, I did specifiy LANG=da_DK.utf8 in
> /etc/default/locale along with LC_ALL=da_DK.utf8. This is supposedly the
> right way to set your locale in Debian, but only the first line with
> LC_ALL is read.

Doesn't the default setup only set `LANGUAGE' and `LANG'?

That would make sense. Because `LC_ALL' is a blunt instrument. If it's
set, you can't deviate from that setting. If you only set `LANG', then
that has the same effect as setting `LC_ALL' until you choose to modify
some aspect of your locale settings. You change `LC_COLLATE' or
`LC_MESSAGES' or whatever and only that setting is changed. All other
unset values default to the value of `LANG'.

> Maybe I should file a bug report for that against the
> locales package?

Don't think it's a bug in their package. (Well, yet, but I think it's
unlikely so far.)


Let's take a look first. I'm running the following in a "zsh -f" shell,
which means that there's so no setup except for the global zshenv file.
That file is empty in my case, so that is a shell with just defaults.

I am only defining the following function:

l() {
for i in ${${(f)"$(locale)"}%%\=*}; do
printf '%s (type: "%s"): "%s"\n' $i ${(Pt)i} ${(P)i}
done
}

That function prints *all* locale-variables with their respective type
(as far as zsh in concerned) and value, to be able to compare those
settings with the values from the `locale' command.

Zsh handles a few variables itself even if they are not exported into
the environment. As documented in zshparam(1).

So, what's going on when zsh is freshly started?

zsh% l 
LANG (type: "scalar-export-special"): "en_GB.UTF-8"
LANGUAGE (type: "scalar-export"): "en_GB:en"
LC_CTYPE (type: ""): ""
LC_NUMERIC (type: ""): ""
LC_TIME (type: ""): ""
LC_COLLATE (type: ""): ""
LC_MONETARY (type: ""): ""
LC_MESSAGES (type: ""): ""
LC_PAPER (type: ""): ""
LC_NAME (type: ""): ""
LC_ADDRESS (type: ""): ""
LC_TELEPHONE (type: ""): ""
LC_MEASUREMENT (type: ""): ""
LC_IDENTIFICATION (type: ""): ""
LC_ALL (type: ""): ""

zsh% locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

So there. `LANG' and `LANGUAGE' are defined and exported (as configured
in /etc/default/locale). `LANG' is "special" to the shell, as documented
in zshparam(1).

UTF-8 works like this. Now I do this:

zsh% LANG=POSIX

...which leads to:

zsh% l 
LANG (type: "scalar-export-special"): "POSIX"
LANGUAGE (type: "scalar-export"): "en_GB:en"
LC_CTYPE (type: ""): ""
LC_NUMERIC (type: ""): ""
LC_TIME (type: ""): ""
LC_COLLATE (type: ""): ""
LC_MONETARY (type: ""): ""
LC_MESSAGES (type: ""): ""
LC_PAPER (type: ""): ""
LC_NAME (type: ""): ""
LC_ADDRESS (type: ""): ""
LC_TELEPHONE (type: ""): ""
LC_MEASUREMENT (type: ""): ""
LC_IDENTIFICATION (type: ""): ""
LC_ALL (type: ""): ""

zsh% locale
LANG=POSIX
LANGUAGE=en_GB:en
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

See how all the values that defaulted to "en_GB.UTF-8" (the value of
`LANG') before now default to "POSIX" (the new value of `LANG').

UTF-8 stopps working now, because zsh rightfully thinks that it is not
in a unicode environment.

Let's experiment a bit:

Let's unset `LANG' to get closer to your setup:

zsh% unset LANG

Now we're getting this:

zsh% l
LANG (type: ""): ""
LANGUAGE (type: "scalar-export"): "en_GB:en"
LC_CTYPE (type: ""): ""
LC_NUMERIC (type: ""): ""
LC_TIME (type: ""): ""
LC_COLLATE (type: ""): ""
LC_MONETARY (type: ""): ""
LC_MESSAGES (type: ""): ""
LC_PAPER (type: ""): ""
LC_NAME (type: ""): ""
LC_ADDRESS (type: ""): ""
LC_TELEPHONE (type: ""): ""
LC_MEASUREMENT (type: ""): ""
LC_IDENTIFICATION (type: ""): ""
LC_ALL (type: ""): ""

zsh% locale
LANG=
LANGUAGE=en_GB:en
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Everything as expected. And UTF-8 does not work. Which is correct,
because - agai

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
> What you are missing is that you never once tried the combination setting
> I described as causing problem. Please try to set a non-utf8 _country_

I'd be surprised to see different results with `de_DE' and `POSIX'.

> locale for the LANG variable together with a utf8 locale for the LC_ALL
> variable. E.g. at your zsh prompt:
>
>export LANG=de_DE
>export LC_ALL=de_DE.utf8
>
> type in e.g. an umlaut character, type backspace to delete it and notice
> that it is deleted piecemeal by octet. It should happen to you too!

It doesn't. For me, zsh works as expected, even with that combination.

[...]
> This combination
>
>export LANG=
>export LC_ALL=da_DK.utf8
>
> is okay. So it is the specific combination of a non-utf8 country locale
> for LANG and a utf8 country locale for LC_ALL that is at fault.

I can't reproduce this yet. I'll try to replicate your system more
closely this afternoon...

Regards, Frank



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

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
>export LANG=de_DE
>export LC_ALL=de_DE.utf8
>
> type in e.g. an umlaut character, type backspace to delete it and notice
> that it is deleted piecemeal by octet. It should happen to you too!

Hum.

I can reproduce this right now. I'm unsure where I went wrong before.
But since mika couldn't get the problem triggered either, I don't feel
too bad. ;)

I'll look into it. Thanks for reporting. (It might take a while, unless
someone else from upstream jumps in.)

Regards, Frank

  For the record:

a) Start a blank shell (zsh -f)
b) export LANG=de_DE (*not* POSIX)
   export LC_ALL=de_DE.utf8
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check "locale -a" and
   update `/etc/locale.gen' and run `locale-gen' if needed.
c) Type two multibyte characters, like `ö' (o with diaeresis).
d) Type backspace four time.
e) See the cursor erase parts of your prompt.
f) Rant about locales in your native tongue.



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

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Frank Terbeck wrote:
[...]
> I can reproduce this right now. I'm unsure where I went wrong before.

Now I know.

The order in which you have to set LANG and LC_ALL is crucial to
reproduce the issue. And the order in my recipe from the last mail is
wrong:

[...]
> b) export LANG=de_DE (*not* POSIX)
>export LC_ALL=de_DE.utf8
[...]

It actually has to be the other way around. So:


b) export LC_ALL=de_DE.utf8
   export LANG=de_DE (*not* POSIX)
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check "locale -a" and
   update `/etc/locale.gen' and run `locale-gen' if needed.
c) Type two multibyte characters, like `ö' (o with diaeresis).
d) Type backspace four time.
e) See the cursor erase parts of your prompt.
f) Rant about locales in your native tongue.


Regards, Frank



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

Bug#654225: Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Michael Prokop wrote:
[...]
> I sadly still can't reproduce it yet, FTR.

Mika and I talked about this on IRC. Turns out he had `LC_CTYPE' in his
environment, which gets saved by zsh's handling, which prevents the
problem.

So, the real[tm] recipe is this:


a) Start a blank zsh (zsh -f)
b) unset LC_CTYPE
c) export LC_ALL=de_DE.utf8
   export LANG=de_DE (*not* POSIX)
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check "locale -a" and
   update `/etc/locale.gen' and run `locale-gen' if needed.
d) Type two multibyte characters, like `ö' (o with diaeresis).
e) Type backspace four time.
f) See the cursor erase parts of your prompt.


Regards, Frank



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

Bug#654225: PATCH: Restore `LC_ALL' when setting `LANG'

[Frank Terbeck]

(Cc:ing Upstream)

When setting LANG, zsh sets LC_ALL and then goes on to restore all
interesting LC_* values after that. Up to now, it did not restore LC_ALL
itself, though.

That could lead to trouble when setting LC_ALL=something-utf8-ish and
after that LANG=something-non-utf8.

This was reported in Debian bugreport #654225:

  

A recipe to reproduce the issue is here:

  

I think the patch below fixes the issue correctly, by restoring LC_ALL
from its parameter along the way with all the other LC_* values zsh
cares about.

(FWIW, the test-suite still passes with this change.)

Regards, Frank


---
 Src/params.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Src/params.c b/Src/params.c
index 446..6d98b8e 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -3780,6 +3780,9 @@ static struct localename {
 #ifdef LC_TIME
 {"LC_TIME", LC_TIME},
 #endif
+#ifdef LC_ALL
+{"LC_ALL", LC_ALL},
+#endif
 {NULL, 0}
 };
 
-- 
1.7.8.rc3.17.gf56ef1




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

Bug#654444: zsh: `q' flag for paramater expansion does not work as advertised

[Frank Terbeck]

Samuel Bronson wrote:
[...]
> ,
> | q
> |  Quote the resulting words with backslashes; unprintable or invalid
> |  characters are quoted using the $'\NNN' form, with separate quotes
> |  for each octet.  [...]
> `
>
> Unfortunately, the second clause seems to be only half correct;
> unprintable characters do get wrapped in $'...', but not \NNN escaped:
>
> ,
> | naesten@hydrogen:~/hacking/crawl/crawl-ref/source% echo -n ${(q)$(echo
> | -e "\e")}|hd
> |   24 27 1b 27   |$'.'|
> | 0004
> `
>
> Of course, what I'd *really* like would be for this to get escaped as
> \e, not \NNN, but I was at least expecting the documented behavior!

This is not a bug.  It's echo being echo (ie. a load of $swearword).

zsh% printf '%s\n' ${(q)$(echo -e "\e")}
$'\033'

Regards, Frank



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

Bug#663982: zsh: autocompletion does not work anymore after compinit

[Frank Terbeck]

Martin Steigerwald wrote:
> auto completion stopped worked since this week. This might be related
> to an upgrade of Z-Shell. It is related configuration, with an empty
> .zshrc it works. But with the recommended configuration from the
> system administrator it does not.
>
> I found it to stop working after compinit. With empty configuration:
>
> mango% cd Infrastruktur/ [aborted with Ctrl-C]
> mango% autoload -Uz compinit
> mango% cd Infrastruktur/ [aborted with Ctrl-C]

Before you're running `compinit', the function-based completion system
is *NOT* online yet. Zsh will fall back to the older compctl system.

> mango% compinit
> mango% cd In
>
> No reaction on tab anymore.

When you say "no reaction" do you mean that zsh eats up all CPU or does
it actually hang without and CPU utilisation at all?

> But this only happens for *one* user that uses a home directory on NFS.

If NFS is in play it could also be bad performance with certain options.
Does the shell hang or does completion just take a very very long time?
As in "minutes"?

> Neither with root nor with a local user I can reproduce this.
>
> Tab completion worked for the NFS user as well before. I can fix it by
> uncommenting compinit from his .zshrc.

Sounds weird. Can't identify a reason off hand.

> This is the .zshrc of the user, but as said it also does not work
> with the system admin recommended one.
[...]

There is nothing in there, that would cause that I think. The other
files (zshenv, zprofile, zlogin - global and user-only) are empty, I
presume?

[...]
> Even with this configuration auto completion does not work for the
> autocd case. But for the local test user it works also in the autocd
> case. For the local test user it also works when I navigate on the
> NFS export.

My *guess* is that something triggers user-name lookups which may take a
very long time with a lot of users in networked environments. But like I
said, it's a guess for now...

Sorry for taking so long. I'm pretty swamped with other work right now.
I hope the other guys from the maintenance team will chime in. ;-)

Regards, Frank



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

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
> /usr/share/zsh/4.3.17/scripts/newuser:6: zsh-newuser-install: function
> definition file not found
[...]
> autoload -U compinit
> compinit
[...]
> zsh: compinit: function definition file not found


This sounds like a severely broken installation. Debian's zsh packages
do not split the function files off of the main package (yet). So that
really shouldn't happen.

What is the output of this:

  print -l $fpath
  c=( ${^fpath}/compinit(N.) )
  (( $#c )) && ls -l $c[1] || echo compinit not found

The last command shouldn't come up with "compinit not found". If it does
the output from the first command is probably reflecting breakage.

In case it's broken try this:

  % zsh -f
  (and in that new shell)
  % autoload -Uz compinit
  % compinit
  % print ${#_comps}

The `compinit' call should *not* fail and the `print' call should return
an integer in the range of slightly above one thousand.

If this does not work, your installation is very likely broken (however
that happened...).

Regards, Frank



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

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
> On 03/29/2012 09:18 PM, Frank Terbeck wrote:
[...]
>>print -l $fpath
>>c=( ${^fpath}/compinit(N.) )
>>(( $#c ))&&  ls -l $c[1] || echo compinit not found
[...]
> It cames up with:
>
>   /opt/intel/composerxe-2011.5.220/mkl/include
>   compinit not found

I have no idea were this is coming from. Please do this:

  % zsh -f
  (and in that new shell)
  % print -l $fpath

If that yields "/opt/intel/composerxe-2011.5.220/mkl/include" then that
is not from our package. That would be completely broken.

>> In case it's broken try this:
>>
>>% zsh -f
>>(and in that new shell)
>>% autoload -Uz compinit
>>% compinit
>>% print ${#_comps}
>>
>> The `compinit' call should *not* fail and the `print' call should return
>> an integer in the range of slightly above one thousand.
>
> compinit fails, and the print gives 0.

This makes me think that your zsh is actually entire broken, what source
are you getting your package from? Do:

  % apt-cache policy zsh

The unchanged $fpath from a default zsh installation on a recent debian
sid system should look like this:

[snip]
/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
/usr/share/zsh/functions/Calendar
/usr/share/zsh/functions/Chpwd
/usr/share/zsh/functions/Completion
/usr/share/zsh/functions/Completion/AIX
/usr/share/zsh/functions/Completion/BSD
/usr/share/zsh/functions/Completion/Base
/usr/share/zsh/functions/Completion/Cygwin
/usr/share/zsh/functions/Completion/Darwin
/usr/share/zsh/functions/Completion/Debian
/usr/share/zsh/functions/Completion/Linux
/usr/share/zsh/functions/Completion/Mandriva
/usr/share/zsh/functions/Completion/Redhat
/usr/share/zsh/functions/Completion/Solaris
/usr/share/zsh/functions/Completion/Unix
/usr/share/zsh/functions/Completion/X
/usr/share/zsh/functions/Completion/Zsh
/usr/share/zsh/functions/Exceptions
/usr/share/zsh/functions/MIME
/usr/share/zsh/functions/Misc
/usr/share/zsh/functions/Newuser
/usr/share/zsh/functions/Prompts
/usr/share/zsh/functions/TCP
/usr/share/zsh/functions/VCS_Info
/usr/share/zsh/functions/VCS_Info/Backends
/usr/share/zsh/functions/Zftp
/usr/share/zsh/functions/Zle
[snap]

In particular, we do NOT have any /opt/intel/... paths in there.

Regards, Frank



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

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
> On Mar 29, 2012, at 21:59, Frank Terbeck  wrote:
[...]
>> In particular, we do NOT have any /opt/intel/... paths in there.
>> 
>
> I know what's going on here now: intel compiler init scripts change the fpath 
> variable.

Is that by chance the Intel Fortran Compiler? I'm just curious.

Regards, Frank



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

Bug#646046: manual page still refers to /etc/zshenv

[Frank Terbeck]

Norbert Kiesel wrote:
> "man zsh" says "Commands are first read from /etc/zshenv; this cannot be 
> overridden.",
> but this was changed to /etc/zsh/zshenv at some point.  Likewise for 
> zprofile, zlogin,
> and zshrc.

Hey Norbert,

This is actually a build-time option. `--enable-etcdir=' to be specific.

The manual used to present the wrong paths, since the package was build
from a release tarball, which had pre-built manual pages, so that people
didn't have to install yodl to build them for themselves.

I thought we started providing a tarball generated from upstream's
version control with the new package (starting from debian version
"4.3.12-1"). With that, the manuals are build when the package is built,
using the right values from the build-time options. That's why the new
package has a build-dependency on yodl now.

Upstream's build system is prepared to handle all of that automatically,
via the "Docs/version.yo" file, which is generated at build-time.

Since it's kind of hard to get a fixed up tarball onto the debian
servers, this will have to wait until upstream releases 4.3.13 - which
is not too far away, unless someone finds a grave bug in the current
code.

Thanks for reporting. Otherwise I may have never realised we were still
using release tarballs as the basis for the package, rather than
tarballs generated from the release's corresponding version control tag.

Regards, Frank



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

Bug#666755: [zsh] GnuPG2 completion

[Frank Terbeck]

Mika Suomalainen wrote:
> zsh is not automatically completing options for gpg2 (package gnupg).
> Many gpg2 command line flags are probably same as gpg ones.

If so, then the following may be a workaround for your configuration
until someone comes up with a full-featured gpg2 completion:

  compdef gpg2=gpg

Regards, Frank



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

Bug#843483: torsocks: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: torsocks
Version: 2.2.0-1
Severity: normal

Dear Maintainer,

Debian's zsh packages offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

Torsocks seems to use:

  /usr/share/zsh/functions/Completion/Unix/_torsocks

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages torsocks depends on:
ii  libc6  2.24-5

Versions of packages torsocks recommends:
ii  tor  0.2.8.9-1

torsocks suggests no packages.

-- no debconf information

Bug#843574: sup-mail: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: sup-mail
Version: 0.22.1-2
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

sup-mail seems to use:

  /usr/share/zsh/functions/Completion/Unix/_sup

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843577: nikola: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: nikola
Version: 7.6.4-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

nikola seems to use:

  /usr/share/zsh/functions/Completion/Linux/_nikola

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843579: python-doit: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: python-doit
Version: 0.28.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

python-doit seems to use:

  /usr/share/zsh/functions/Completion/Linux/_doit

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843578: dochelp: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: dochelp
Version: 0.1.3+b1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

dochelp seems to use:

  /usr/share/zsh/functions/Completion/Debian/_dochelp

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843573: herbstluftwm: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: herbstluftwm
Version: 0.7.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

herbstluftwm seems to use:

  /usr/share/zsh/functions/Completion/X/_herbstclient

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843581: python3-doit: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: python3-doit
Version: 0.28.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

python3-doit seems to use:

  /usr/share/zsh/functions/Completion/Linux/_doit3

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843580: autojump: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: autojump
Version: 22.5.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

autojump seems to use:

  /usr/share/zsh/functions/Completion/Unix/_j

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843575: ninja-build: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: ninja-build
Version: 1.7.1-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

ninja-build seems to use:

  /usr/share/zsh/functions/Completion/_ninja

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843576: taskwarrior: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: taskwarrior
Version: 2.5.1+dfsg-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

taskwarrior seems to use:

  /usr/share/zsh/functions/Completion/Unix/_task

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843582: 0xffff: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: 0x
Version: 0.6.1-3
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

0x seems to use:

  /usr/share/zsh/functions/Completion/Unix/_0x

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#756138: Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup

[Frank Terbeck]

Hi Carsten,

I looked through the suggestions from your last mail; comments inline.

Carsten Hey wrote:
[...]
> I think "#setopt no_beep" and "#stty -ixon" should also be added to

The latter might better be replaced by zsh's "no_flow_control" option.

[...]
> This prompt color-scheme-able via zstyle.  If the variabale TERM is set to
> 'dumb', colors are disabled, though.  You can invoke the prompt thus:
>
>   prompt debian
>   TERM=dumb prompt debian

You could also check something like a "blacklist" style, that could be a
list of term names (or better yet, patterns). That way you could
blacklist $TERMs like "emacs" for colours as well.

> To configure the prompt's colors, this command can be used (don't forget to
> run 'prompt debian' again to activate the changes):
>
>   zstyle ':prompt:debian:*' STYLE COLOR

Good! I like it when people refrain from polluting the global parameter
name space just for prompt colours. This is good. :-)

[...]
> Displaying version control information via vcs_info and displaying the name of
> a Debian chroot is supported by this prompt, but only the latter is enabled by
> default.  To enable vcs_info with the user-context 'prompt_debian', run:
>
>   add-zsh-hook precmd prompt_debian_precmd_vcsinfo

Makes sense.

[...]
>   PROMPT='%B!%!%b '"$PROMPT"
>   zstyle ':vcs_info:*' nvcsformats '%B%F{2}%(1j.j%j .)%(2L.L%L .)%b%f'

Maybe use a name rather than a number here: %F{green}

> EOF
> }
>
> prompt_debian_precmd_vcsinfo () {
> setopt localoptions noxtrace
> vcs_info prompt_debian || return $?
> }
>
> prompt_debian_setup () {
> prompt_opts=(cr subst percent)
>
> local 
> zstyle_pattern=":prompt:debian:${HOST:-unknown}:${USERNAME:-unknown}"
>
> local pwd_max_length=60
> local pwd_max_subdirs=5
> local wrap_at_char='-25'

Maybe make these configurable via styles?

>
> local p_exit='${${options[printexitvalue]#on}:+%0(?..%? )}'
> local p_pwd="%${pwd_max_length}<...<%$(( pwd_max_subdirs + 1
>   ))(~:.../:)%${pwd_max_subdirs}~%<<"
> local p_space_or_newline="%${wrap_at_char}(l: :${prompt_newline})"
> local p_vcsinfo='${vcs_info_msg_0_-}'
> local p_reset='%b%f%k'
> local p_2nd_newline="%1(l:%${wrap_at_char}(l..${prompt_newline}):)"

I think that looks reasonable.

> if [[ ${TERM-} == dumb ]]; then
> PROMPT="$p_exit\${debian_chroot:+(\$debian_chroot)}%n@%m $p_pwd"
> PROMPT+="$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%# "
> else
> # color config:
> local dircolor= usercolor= usercolor_root= exitcolor= exitcolor_root=
> zstyle -s "$zstyle_pattern" dircolor   dircolor
> zstyle -s "$zstyle_pattern" usercolor  usercolor
> zstyle -s "$zstyle_pattern" usercolor-root usercolor_root
> zstyle -s "$zstyle_pattern" exitcolor  exitcolor
> zstyle -s "$zstyle_pattern" exitcolor-root exitcolor_root
> : "${dircolor:=4}" "${usercolor:=2}" "${usercolor_root:=1}"
> : "${exitcolor:=1}" "${exitcolor_root:=2}"

To set defaults you can do:

  zstyle -s "$zstyle_pattern" dircolor dircolor || dircolor=4

And again, maybe rather use names instead of numbers:

  zstyle -s "$zstyle_pattern" dircolor dircolor || dircolor=blue

You also don't need to initialise to the empty string in the "local"
above.

>
> PROMPT="%B%{%0(#:%F{$exitcolor_root}:%F{$exitcolor})%}$p_exit"
> PROMPT+="%{%F{$dircolor}%}\${debian_chroot:+(}"
> 
> PROMPT+="%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}\${debian_chroot-}"
> PROMPT+="%{%F{$dircolor}%}\${debian_chroot:+)}"
> PROMPT+="%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}%n@%m "
> PROMPT+="%{%F{$dircolor}%}$p_pwd%b%f"
> PROMPT+="$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%B%#%b "

Assembling a non-trivial prompt like always looks unreadable. I've seen
worse than this.

> ##TODO uncomment if setopt transientrprompt works in a prompt function
> ## Ease copying multi-line commands with the mouse.
> ## 
> #local rps2color=$dircolor
> #setopt transient_rprompt

I don't understand this. "transientrprompt" can — and IMO should be —
set outside a prompt setup.

> #PS2='${${options[singlelinezle]#off}:+%_> }'

I'd do this in an "if ...; then...; fi" to improve readability.

> #RPS2=${RPS2:-"%B<%{%F{$rps2color}%}%^%f%b"}

[...]
> # Autoload and configure vcs_info:
> # The format strings 'formats' and 'actionformats' should end with a space
> # to fit into the prompt's design.
> # Colors: 1:=red, 2:=green, 3:=yellow, 4:=blue, 5:=magenta, 6:=cyan, ...

Again, you can use the colour names instead of the numbers instead.

[...]

The contents of the ".thisfiledoesnotexist" file seems very similar to
the one of the "prompt_debian_setup" file. Attached by mistake?


Regards, Frank

-- 
In protocol design, perfection h

Bug#794967: zsh: please enhance /etc/zshrc

[Frank Terbeck]

Carsten Hey wrote:
[...]
>  * Please add some additional keybindings, at least for the emacs keymap:
>
>- bind PageUp "${terminfo[kpp]}" to history-search-backward
>- bind PageDown "${terminfo[knp]}" to history-search-forward
>- bind BackTabKey "${terminfo[kcbt]}" to reverse-menu-complete

I firmly believe, that a vendor's *global* setup file should be as
minimal as possible, which is why I really don't want to add anything
that's more than making the zsh defaults behave more robustly across
multiple terminals or deal with stuff specific to Debian.

This is stuff for the recommended setup file.

>  In terminfo(5), the capname cbt is described as "back tab (P)"
>  and kcbt is described as "back-tab key", therefore the suggested
>  'BackTabKey' instead of 'BackTab' - even though grml confuses
>  people that know terminfo(5) by using 'BackTab' as name.

By that logic, kpp would need to be mapped to "PreviousPageKey". I think
the current naming is fine.

>- Maybe F1 could invoke run-help?  But then the output of run-help
>  w/o arguments should be more useful for new users.
>
>- Red Hat maps or mapped space to magic-space, I think Debian should
>  _not_ do this, but initially I thought that this would be a good
>  idea.

Again, this fits into the recommended setup file

>  * $key should be unset unless there is a reason for not doing so.

The reason I left it set, is because its layout matches the $key
dictionary, that zsh's "zkbd" function produces and can be used as a
drop-in replacement. I still think that's a reasonable idea, even though
it slightly violates the "A vendor's global setup needs to be minimal"
rule.

>  * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
>in rare cases, possibly involving zsh-static, there is a chance that
>this module is not loaded successfully, you should consider doing
>this instead to remove the alias w/o error message:
>
>  alias run-help=
>  unalias run-help

That's a good point. I think we can do it like this:

unhash -a -m 'run-help' || true

-a removes alias from its hash table. -m uses the argument as a pattern.
Since there's no character that's significant to pattern matching, this
will work. This way, there is no error message. The '|| true' is to make
sure the setup file exits with successful status.

We could also just do this:

unalias run-help 2>/dev/null || true

…if that's more straight-forward to read.


Regards, Frank


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

Bug#794968: zsh: please clear console on logout (if recommended config is used)

[Frank Terbeck]

Carsten Hey wrote:
> Please clear console on logout if the recommended config for new users
> is used.

I think this should be doable with a zshexit hook like this:

function debian_clear_upon_exit () {
clear
}
add-zsh-hook zshexit debian_clear_upon_exit

That hook could be installed in the recommended setup file.

Disclaimer: I didn't try this. :-)


Regards, Frank


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

Bug#794967: zsh: please enhance /etc/zshrc

[Frank Terbeck]

Hi!

Carsten Hey wrote:
> * Frank Terbeck [2015-08-08 23:46 +0200]:
[...]
>> I firmly believe, that a vendor's *global* setup file should be as
>> minimal as possible, which is why I really don't want to add anything
>> that's more than making the zsh defaults behave more robustly across
>> multiple terminals or deal with stuff specific to Debian.
>
> It looks like you changed your opinion since you wrote
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10


Heh. I honestly don't even remember sending those mails. I do remember
the issue (ie. the fact that Ubuntu does compinit in the global zshrc),
but I thought my reaction had matched my reaction right now.


For the record, let it be known that the statement from my previous mail
in *this* thread is indeed my actual position in the matter. And it has
been for a while. I'm sure there is evidence of that in threads of other
bug reports that would show that.

Today I wouldn't take that code snippet from my own mail to enter our
setup. It's the wrong thing to do. I think they still do that in Ubuntu,
which is another reason why "setopt no_global_rcs" is part of my
personal zsh setup in my "~/.zshenv" file.


Regards, Frank


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

Bug#823093: zsh-common: Zsh config files are stored in /etc/zsh instead of /etc/zsh.d, which is more expected by users

[Frank Terbeck]

Hi,

Christopher Slojkowski wrote:
> Zsh files are stored in /etc/zsh, they should be stored in /etc/zsh.d instead.
> This is more consitant with other directories. I included a patch which makes
> the new folder, moves, and creates a symlink. There is proabably a better
> solution, but I just created a quick hack.

I disagree. Usually, the use of .d directories signifies that all files
from such a directory are being loaded by an application. That is not at
all the case with /etc/zsh.

Also, this is longstanding behaviour with the debian package and, as
far as I am concerned, this is not going to change.


Regards, Frank

Bug#828180: zsh: $RANDOM number generator is not reset for subshells

[Frank Terbeck]

Ben Longbons wrote:
> Dear Maintainer,

Hi Ben,

> Zsh just repeats the same number when $RANDOM is requested in fresh
> subshells. In general, this sort of bug is a security vulnerability,
> though I'm not aware of anyone doing security-sensitive stuff in zsh.

This works exactly as documented and is therefore not a bug:

RANDOM 
A  pseudo-random  integer  from 0 to 32767, newly generated each
time this parameter is referenced.  The random number  generator
can be seeded by assigning a numeric value to RANDOM.

The   values   of   RANDOM   form   an  intentionally-repeatable
pseudo-random sequence; subshells  that  reference  RANDOM  will
result  in  identical  pseudo-random  values unless the value of
RANDOM is referenced or seeded in the parent  shell  in  between
subshell invocations.

This comes up on zsh's mailing list every once in a while. Here is a
recent-ish thread: http://www.zsh.org/mla/workers/2015/msg00549.html

> bash handles this correctly in variables.c by checking
> `subshell_environment && seeded_subshell != pid` on every call and
> reseeding then; it would also be possible to use `pthread_atfork` (or,
> since the forking is entirely within the main executable, just the
> manual equivalent at the call site).

There is no standard that mandates how $RANDOM should behave. So this
boils down to "zsh is no bash".


Regards, Frank

Bug#753296: Acknowledgement (mpv completion fails)

[Frank Terbeck]

Yuri D'Elia wrote:
> Ahh sorry, I noticed only now that the _mpv function is shipped with mpv
> itself.
>
> Could you reassign it to mpv?

The problem you're describing looks like a broken completions-cache
file. Before you proceed, try this:

  % rm ~/.zcompdump
  % exec zsh

And see if the problem persists.


Regards, Frank


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

Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Hey Tim,

Tim Booth wrote:
[...]
> This is a request on behalf of Bio-Linux and the Debian Med
> developers. The attached file shows the zshrc used on Bio-Linux, and
> the part we'd really like to see in the standard zsh-common package is
> support for a zprofile.d configuration directory[...]

Is there a specific problem you'd like to address? I'm not a big fan of
these kitchen sink directories everybody and their dog gets to dump
stuff into. Especially in “/etc” since it's kind of hard for a package
to remove stuff from there again.

> In Bio-Linux this is hooked from zshrc but actually a modified zprofile
> probably makes more sense.
>
> This is pretty trivial to implement, as far as I can see.  What do you think?
[...]
> for i in `( setopt null_glob ; echo -n /etc/zsh/zshrc.d/*.zsh )` ; do

Ungh... Don't do it like this! Just use globbing to create a list of
files. The idea about "null_glob" is sound in itself (even though in zsh
solvable differently, using the "N" glob qualifier). But since you do
this test in the loop:

> if [ -r $i ]; then
>   source $i

you don't need null_glob at all. Thus, I'd do this:

for i in /etc/zsh/zshrc.d/*.zsh; do
# I'm quoting the parameter, because someone might have
# set the SH_WORD_SPLIT option in, say "~/.zshenv".
if [ -r "$i" ]; then
source "$i"
fi
done


Regards, Frank


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

Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Frank Terbeck wrote:
[...]
> you don't need null_glob at all. Thus, I'd do this:
>
> for i in /etc/zsh/zshrc.d/*.zsh; do

Well, since zsh's default behaviour is to error out with non-matching
globs, using the qualifier is actually required:

for i in /etc/zsh/zshrc.d/*.zsh(N); do
> # I'm quoting the parameter, because someone might have
> # set the SH_WORD_SPLIT option in, say "~/.zshenv".
> if [ -r "$i" ]; then
> source "$i"
> fi
> done
>
>
> Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925


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

Bug#776663: Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Tach Axel,

Axel Beckert wrote:
> Hi Frank and Tim,
>
> Frank Terbeck wrote:
>> Tim Booth wrote:
>> > This is a request on behalf of Bio-Linux and the Debian Med
>> > developers. The attached file shows the zshrc used on Bio-Linux, and
>> > the part we'd really like to see in the standard zsh-common package is
>> > support for a zprofile.d configuration directory[...]
>> 
>> Is there a specific problem you'd like to address?
>
> I'd be curious about Tim's reason, too. I see, he (co-)maintains quite
> a lot of packages in Debian, but nothing which strikes me as
> zsh-related.
>
> Oh, and I'm glad we're having that discussion in a bug report! So I'm
> not the only one who thought about such a feature! ;-) (SCNR)

I actually though that this had been discussed before, but I couldn't
find a previous discussion. The instance I was recalling was a about
sourcing stuff from /etc/profile and /etc/profile.d/ itself (see below).


>> I'm not a big fan of these kitchen sink directories everybody and
>> their dog gets to dump stuff into.
>
> I'm actually quite a big fan of them (otherwise I probably never would
> have written Run::Parts[1]). They make packaging extensions, addons,
> plugins, etc. way easier as there's no need to modify the
> configuration files of other packages (which is forbidden by Debian's
> Policy).
>
>   [1] https://packages.qa.debian.org/libr/librun-parts-perl.html
>   https://metacpan.org/release/Run-Parts
>
> See e.g. /etc/apache2/*-enabled/, /etc/apt/apt.conf.d/ or
> /etc/bash_completion.d/ for examples used successfully by many
> packages. And I recently saw that /etc/apt/preferences.d/ is actively
> used by apt-listbugs to hold packages with RC bugs via pinning.

The bash_completions thing is only there because bash doesn't have sane
autoloadable functions. The apache directories I find rediculously
messy.

The apt-usecase seems legit.

With respect to shells, I usually find that applications, that need to
inject code into a user's shell to be by and large mis-designed.

Something that *might* make sense is to source stuff from /etc/profile
and “/etc/profile.d/” in POSIX-mode. See ¹, a mail about that from 2011.
Nobody cared enough to reply; which I guess that tells you something
about the urgency of the situation. ;-)

But like the mails says, even if we did that, it's hard to decide what
because it's not used for portable purposes alone. The bash completion
thing is sourced from there, which other POSIX shells will have a major
problem with.

I think the situation is messy and I'd like to not get my hands dirty.
This is, however, my personal opinion and does by no means reflect the
opinion of the rest of Debian's zsh packaging team. :-)


> Another nice example which would be much easier that way is the
> planned packaging grml's zshrc. (Which is still on my TODO list.)

Grml's zshrc could replace the existing configuration. It has everything
Debian's zshrc has and just piles up on that.


> As far as I know we already have /usr/share/zsh/vendor-functions and
> /usr/share/zsh/vendor-completions (of which only the latter is used so
> far), but that doesn't cover startup files like zshrc, zprofile,
> zshenv, etc.

Yeah, those are used for completely different purposes, though. And
adding them comes at virtually no additional costs.


>> Especially in “/etc” since it's kind of hard for a package to remove
>> stuff from there again.
>
> Huh? I'm sorry, but I have no idea what kind of issues you might refer
> to. If it's a "conffile" coming from a package, dpkg handles that
> well. If it's a generated file there's ucf to properly handle it. So
> I'd be happy if you could elaborate that issue a little bit as I'd be
> curious to learn about issues I'm not yet aware of.

(*puts on grml-zshrc hat*) As I recall, with grml's zsh configuration,
we had a ton of stuff in /etc/zsh/... and for some reason (I'm not
familiar with any particulars in the developer reference), we couldn't
just remove them in a maintainer script.

It was a huge pain in the ass and for quite a while we had code in the
setup that checked for the existence of old files in those directories,
asking the user to consider removing them. (*puts off hat again*)

To my understanding, stuff in /etc is considered a configuration file,
that might have been changed or added by the user and can therefore not
be removed by packages.  I could see using checksums to gauge whether or
not a file is still in mint condition. I don't know if that is being
done by dpkg these days.


> The common argument against .d directories with configuration snippets
> so far seemed per

Bug#776964: Headers installed by zsh-dev packages miss critical pieces

[Frank Terbeck]

Hey there!

ZyX wrote:
[...]
> To use zsh headers in some module at least `config.h` file is needed

Finally, someone who actually wants to use zsh's facilities to load
third party modules. Yay. ;)

> in addition to those already present in the package. `config.h` files
> contains defines guessed by ./configure script and including it prior
> to `zsh.h` is the only sane variant to include `zsh.h` (insane variant
> is using module’s own configure script which will create those
> defines). Without `config.h` including `zsh.h` will fail due to
> missing defines, and even if it was not failing it would make #include
>  do the wrong thing because of the bits like
[...]

I agree.

> (configure.h-driven definition of zlong and zulong which has the potential of 
> breaking ABI compatibility in some cases).
>
> In addition to this file it is good to have a patched `zsh.mdh` file
> which glues together all zsh includes and is a single entry point.
> Patch needed to include this file in the distribution may be performed
> with the following script:
>
>   for file in Src/{zsh.mdh,*.h} ; do

We'd probably want to do that in a POSIX compatible way, so we'd refrain
from using brace expansion but that's just cosmetics.

>   sed -i 's@\.\./config\.h@config.h@' "$file"
>   sed -i 's@#\(\s*\)include "\([^"]\+\)"@#\1include @' 
> "$file"

Sed's -i option requires GNU sed. But then, I don't know if debian even
ships another version of sed. ...I think it doesn't; but I also don't
know about the policy with respect to non-POSIX features in packaging.

>   done
>
> . I am doing this in a Gentoo ebuild and the result works just fine.

Yeah, I think this could work.

Do you think it would make sense to include the other header files with
zsh-dev as well? Like "zshterm.h" etc?


Regards, Frank


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

Bug#780531: zsh: tail -F does not complete file names

[Frank Terbeck]

Hello Sebastian,

Sebastian Ramacher wrote:
[...]
> The completion for "tail -f " correctly completes files, but it does not for
> "tail -F ". "tail -F " displays "completing -f" and and nothing else. I'd
> also expect to get "completing files" there.

Zsh does not supply a completion function for tail. Thus, it should fall
back to file-completion for programs it doesn't know for any better.

You can try this:

% zsh -f
% autoload -Uz compinit; compinit
% tail -F 

and try to reproduce the issue with a clean zsh instance with just the
completion system loaded. You'll see that you can't; because I can't.

My guess is, that you've got a completion handler configured for tail.

Like ‘_gnu_generic’. Try this (from a failing shell of yours):

% print ${_comps[tail]}

and that will most likely print ‘_gnu_generic’.


Long story short: This is not a bug in Debian's zsh package. But rather
in your configuration, since it assumes _gnu_generic can handle the
--help output of current GNU tail versions. Which it apparently can't.

You could argue, that this might be considered a bug in zsh's
_gnu_generic function; but really, that's a hack to try and parse
completion information from --help of any given command you assign to
it. If that output changes in an incompatible way, the function is
screwed. It's a best-guess solution rather than something sustainable.

I would suggest dropping the completion function assignment from your
configuration.


Regards, Frank


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

Bug#764650: zsh: FTBFS with noatime mounts

[Frank Terbeck]

Hi Thorsten!

Thorsten Glaser wrote:
> Justification: FTBFS, but maybe m68k are the only ones with noatime?
>
> http://buildd.debian-ports.org/status/fetch.php?pkg=zsh&arch=m68k&ver=5.0.6-3&stamp=1412524530
>
> ../../Test/C02cond.ztst: test failed.
> The following may (or may not) help identifying the cause:
>   This test can fail on NFS-mounted filesystems as the access and
>   modification times are not updated separately.  The test will fail
>   on HFS+ (Apple Mac OS X default) filesystems because access times
>   are not recorded.  Also, Linux ext3 filesystems may be mounted
>   with the noatime option which does not update access times.
>   Failures in these cases do not indicate a problem in the shell.
> […]

Hum. There are a few tests, that are supposed to detect systems that
don't support that test, like systems with noatime filesystems and skip
that particular test.

In particular for noatime:

  elif test -f /etc/mtab && { grep $(df . 2>/dev/null| tail -n1 | awk '{print 
$1}') /etc/mtab | grep -q noatime; }; then

...which doesn't catch the problem in the buildd, it would seem.

It does work on my laptop, but then, I have no clue about buildds. :)

Someone with a better, more portable version of that test around?


Regards, Frank


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

Bug#707760: zsh: Alternatives broken for long time during upgrade from zsh4 to zsh5

[Frank Terbeck]

Axel Beckert wrote:
> Sven Joachim wrote:
[...]
>> How about adding a symlink /bin/zsh4 -> zsh5 in the zsh package?  Not
>> extremely pretty, but it should work.
>
> What about putting a shell script at /bin/zsh4 which more or less
> looks this?
>
>   #!/bin/sh
>   
>   echo "$0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh" 1>&2
>   exec /bin/zsh5 "$@"

I think this is the way to go. Maybe even like this:

#!/bin/zsh -f

if [[ -o interactive ]]; then
echo "$0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh" 1>&2
echo "Use: chsh -s /bin/zsh" 1>&2
echo "This command ($0) will disappear eventually!" 1>&2
fi
exec /bin/zsh "$@"

> Or maybe even
>
>   #!/bin/sh
>   set -e
>   
>   echo "$0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh" 1>&2
>   /bin/zsh5 "$@"
>   exit 1

Too intrusive, IMHO.


Regards, Frank


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

Bug#764650: zsh: FTBFS with noatime mounts

[Frank Terbeck]

Thorsten Glaser wrote:
> Frank Terbeck dixit:
[...]
>>  elif test -f /etc/mtab && { grep $(df . 2>/dev/null| tail -n1 | awk '{print 
>> $1}') /etc/mtab | grep -q noatime; }; then
[...]
> Hm, I think this rings a bell. Didn’t we have this on another buildd
> already, years ago, because something like mtab wasn’t available or
> something? Will need to dig through mail/bts archives…

Axel hinted at that on IRC, as well. He thought that /proc/mounts should
be available, which I think has the same syntax. We could just double up
the test, once against /etc/mtab and then against /proc/mounts.

Would that help?


Regards, Frank


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

Bug#707760: zsh: Alternatives broken for long time during upgrade from zsh4 to zsh5

[Frank Terbeck]

Frank Terbeck wrote:
[...]
> #!/bin/zsh -f
>
> if [[ -o interactive ]]; then
[...]

This wasn't the smartest idea ever. Since this is a script, it's
obviously not interactive invocation, which means that the test always
fails. Oh well. I guess we can just warn upon every invocation
interactive or not.


Regards, Frank


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

Bug#720707: state of RFP: grml-zsh-config?

[Frank Terbeck]

Hi,

Disclaimer: Even though I am involved with grml's setup a great deal, I
never was a big fan of packaging it up for Debian. The reason for
that being mainly, that I am absolutely convinced that a vendor
should impose the least possible changes to a package as possible
and most certainly not impose a bunch of settings for every user on
a system.


Thomas Koch wrote:
> sorry, I wanted to ask you on Saturday: What's the state of the 
> grml-zsh-config 
> packaging for Debian? Could you provide a braindrop of the problems you're 
> aware of and what discussions have happened?

That being said, I just realised that there is actually nothing at all
missing for such a package. Zsh code like grml's setup doesn't belong to
/etc anyway. We could probably distribute it somewhere in /usr/share/zsh.

Then users who want the setup can just

  source /usr/share/zsh/cfg/grml-zshrc

and be done. We could even package a byte-compiled version of the setup.

I am still firmly against anything that would enable the setup per
default for everyone on a system.


Regards, Frank

Bug#790535: susv4: fails to install: post-installation script returned error exit status 1

[Frank Terbeck]

Hello maintainer!

I just tried to install the "susv4" package on my system and it revealed
the following issue, which I believe was mentioned in the bug id I am
reopening right now.

Note, that I tried to install "susv2" and "susv3" and neither of those
packages had any problems of that kind.


Regards, Frank


i-(6007)-~% apt-get install susv4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  susv4
0 upgraded, 1 newly installed, 0 to remove and 56 not upgraded.
Need to get 0 B/3,088 B of archives.
After this operation, 15.4 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package susv4.
(Reading database ... 319792 files and directories currently installed.)
Preparing to unpack .../susv4_7.20150719_all.deb ...
Unpacking susv4 (7.20150719) ...
Processing triggers for doc-base (0.10.6) ...
Processing 1 added doc-base file...
Error in `/usr/share/doc-base/susv4', line 9: all `Format' sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.
Setting up susv4 (7.20150719) ...
Fetching file...
--2016-01-06 14:06:16--  
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4tc1.tar.bz2
Resolving pubs.opengroup.org (pubs.opengroup.org)... 69.80.200.148
Connecting to pubs.opengroup.org (pubs.opengroup.org)|69.80.200.148|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3638538 (3.5M) [application/x-bzip2]
Saving to: ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’

susv4tc1.tar.bz2100%[=>]   3.47M  
56.7KB/sin 41s

2016-01-06 14:06:58 (87.2 KB/s) - ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’ saved 
[3638538/3638538]

Verifying SHA512 checksum...
dpkg: error processing package susv4 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 susv4
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Frank Terbeck]

Hey,

Martin Steigerwald wrote:
>> On a tangent: what do "nyae" mean?  I couldn't find the answer in the
>> manual.
>
> I thought about this as well.

This would be:

(Y)es, (N)o, (A)bort, (E)dit.


Regards, Frank

Bug#844095: fdm: please make the build reproducible

[Frank Terbeck]

Hi,

Reiner Herrmann wrote:
> While working on the "reproducible builds" effort [1], we have noticed
> that fdm could not be built reproducibly. It collects source files
> with "echo *.c", which varies with different locales. This causes a
> different order of objects during linking.

Thanks! Commendable effort, you guys are pursuing there. This is just to
let you know, I've seen the bug; but I won't be able to do anything
about it before the upcoming weekend. I well get to it eventually,
though.


Regards, Frank

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Frank Terbeck]

Hi,

Michael Biebl wrote:
[...]
 martin@merkaba:~> systemctl status

 ^[[0;1;31m●^[[0m merkaba

 State: ^[[0;1;31mdegraded^[[0m
 
  Jobs: 0 queued

Failed: 2 units

I can't reproduce this.

If zsh changed its terminal to behave like that, no coloured output
would work at all. This smells a lot like broken configuration.

Please provide a minimal example, that triggers the problem (freshly
started terminal, preferably xterm, and freshly started zsh, with only
as much configuration as to trigger the problem). If it is indeed a
problem, that zsh is responsible for, we can talk.


Regards, Frank

Bug#460302: usr/include/tdb.h uses sig_atomic_t without including signal.h

[Frank Terbeck]

Is this bug going to be dealt with anytime soon?

Regards, Frank



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#367823: zsh: segfault when completing arrays

[Frank Terbeck]

Package: zsh
Version: 4.3.2-8
Severity: normal

Howdy.
zsh 4.3.2 crashes with sig11 when doing the following:

[snip]
% zsh -f
% autoload compinit; compinit
% array=( 5 4 3 2 1 )
% print $array[4]
^- place your cursor here and hit 
[snap]

I've tested this on a sarge system with zsh 4.2.5 and that version is
not affected by this problem.

Regards, Frank

-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16.1
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages zsh depends on:
ii  debconf [debconf-2.0] 1.5.1  Debian configuration management sy
ii  libc6 2.3.6-7GNU C Library: Shared libraries
ii  libncurses5   5.5-2  Shared libraries for terminal hand

Versions of packages zsh recommends:
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libpcre3  6.4-2  Perl 5 Compatible Regular Expressi

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#367823: zsh: segfault when completing arrays

[Frank Terbeck]

Peter Stephenson <[EMAIL PROTECTED]>:
> Clint Adams wrote:
[...]
> > Should zlemetaline be 0 or should zleline + zlemetacs be non-zero?
> 
> I suspect it's just a typo...
>
> Index: Src/Zle/zle_params.c
[...]
> - return dupstrpfx((char *)zleline + zlemetacs, zlemetall - zlemetacs);
> + return dupstrpfx((char *)zlemetaline + zlemetacs, zlemetall - 
> zlemetacs);

That fixes the problem for me.

Regards, Frank



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#523673: fdm: new upstream release

[Frank Terbeck]

Ritesh Raj Sarraf :
[...]
> Even though fdm's popcon stats are very low, I gave it a shot.

Well, popcon is no real measurement. :)

> And must say, it is really a nice software.
> 
> Couldn't find any bugs in it, :-)

That sounds like you actually looked for bugs, which makes this even
better.

> so thought of why not filing a wishlist for the new release that's
> available.
> fdm 1.6 is available.

Yes, and it is for quite some time.
I was a little lazy about it, because 1.6 didn't bring too many new
stuff, it wouldn't have made it into the lenny release and the debian
package even had the one portability fix I was interested in, so the
fact that I didn't have enough time to package 1.6 in the past didn't
hurt too much.

I did find the time to package 1.6 a few days back and it'll
eventually get uploaded as soon as my sponsor looked at it and deems
it ready for upload (which I suspect it is).

Regards, Frank



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

Bug#525121: fdm: leave mail on server

[Frank Terbeck]

Ccing the fdm-users mailing list, for additional input on the 'only'
option, which I have no real experience with; and maybe inside about a
possible new upstream release.

Please reply to all addresses in To: and Cc: in order to keep all
involved parties and the debian BTS in the loop.


Here is the conversation on debian bug #525121 so far:

Ritesh Raj Sarraf :
> My email account is on an exchange server that I access through
> IMAP. I also download a copy of the emails from the exachange server
> using POP3, for backup purpose.
> 
> With fdm, when I pull the emails through POP3, it downloads emails,
> and then deletes them on the server.

You can always use the 'keep' option to accounts or the action of the
same name for individual rules.

> I somehow was able to restore my inbox folder on the exchange
> server.
> But then, on next fetch, it again attempts to download all the
> messages that it already had downloaded previously.
> Shouldn't fdm be keeping track of already downloaded messages?

In fdm's CVS version (not yet released), there is an option called
'only', which can do what you're looking for, AFAICS.

I would have to investigate if it is possible to backport that feature
to the 1.6 package, which is available. Otherwise the only options
here are waiting for upstream to do a new stable release or packaging
a CVS snapshot. I'd be very much in favour of an upstream release
here.

> And how do I tell fdm to leave a copy of the message that it is
> downloading ?

As mentioned above the 'keep' keyword in various places can do what
you are looking for. See the fdm.conf(5) manpage for this.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#525121: fdm: leave mail on server

[Frank Terbeck]

Nicholas Marriott :
> fdm doesn't keep track of mail it has seen unless you tell it to. Due
> to limitations in POP3 it requires a separate cache file (IMAP does
> not require one). Look for new-only and old-only in the manual, IIRC
> they have been there since about 1.4... I've been slacking on fdm
> recently so they certainly haven't been added after the latest
> release.

*sigh* - I searched for 'only-new' in 1.6's manpage to check if it
had that feature already. That should have been 'new-only' of course.
That's what I get for doing things in a hurry...

Thanks for putting that straight.

Regards, Frank



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

Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

[ Ccing the fdm-users mailing list. Please reply to all addresses in ]
[ To: and Cc: in order to keep all involved parties and the debian   ]
[ BTS in the loop.   ]

Ian Zimmerman :
> Package: fdm
> Version: 1.5-3
> Severity: normal
> 
> I tried to make fdm deliver directly to sendmail (exim actually) with a config
> line like this:
> 
> action "default" pipe "/usr/sbin/sendmail -oi -odi i...@localhost"
> match all action "default"
> 
> but i get this in the log:
> 
> May  2 00:35:01 matica fdm[7686]: fatal: cmd_start: kill: Operation not 
> permitted
> May  2 00:35:02 matica fdm[7675]: fatal: main: child socket closed
> May  2 00:35:02 matica fdm[7676]: fatal: fetch_poll: parent socket closed
> May  2 00:35:07 matica fdm[7678]: fatal: child_deliver: privsep_send error
> 
> and .fdm.lock stays around :-(
> 
> I reverted to the grotty fetchmail way (SMTP to localhost) and that works.
> Maybe it has something to do with exim being setuid root?

Since I don't use any pipe actions myself, I'm clueless here.

Is this something that was addressed since fdm 1.5 was released? Are
there any workarounds?

Regards, Frank



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

Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

Nicholas Marriott :
> Yes, it is probably because it is setuid. fdm calls kill(pid, 0) to see if the
> process has actually started. This isn't actually needed, it is a debugging
> aid. In any case, if it gets EPERM it is probably safe to assume the process
> does exist. Please try this diff:

Ian, since I didn't hear from you again I suppose you require
assistance in trying the diff Nicholas provided.

See .

There's a link to an extended debian patch against
fdm_1.5.orig.tar.gz, which is also available from there.

Which those you can build a debian package that includes said patch.

Since (from your initial report) you seem to be on a i386 machine, you
can also use the .deb provided there, here is a quick link:
  

Note, that this a not a properly updated package yet. It currently
only includes the new patch in addition to the old package. No updated
documentation, no nothing. We need to make sure it fixes the problem
and doesn't break anything before attempting to touch 'stable'.

Please try it and report back.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

I will _not_ go ahead and ask for an upload to stable without this
patch being tested. And since the original reporter backed out before
doing that...

Anyway, I'll attach the patch provided by Nicholas - tweaked a little
to work with quilt - to this message. Anyone who wants to test it, is
welcome to do so. Instructions on how to use additional patches with
the debian fdm package can be found here:
http://ft.bewatermyfriend.org/fdm/trypatches.html

Regards, Frank
Fix a problem when checking if a setuid program is running using kill().
See #526614 for details.

Index: fdm-1.5/command.c
===
--- fdm-1.5.orig/command.c	2009-05-08 10:42:41.0 +0200
+++ fdm-1.5/command.c	2009-05-08 10:44:47.0 +0200
@@ -134,9 +134,10 @@
 
 	/* XXX Check if the child has actually started. */
 	if (kill(cmd->pid, 0) != 0) {
-		if (errno != ESRCH)
+		if (errno == ESRCH)
+			CMD_DEBUG(cmd, "child not running");
+		else if (errno != EPERM)
 			fatal("kill");
-		CMD_DEBUG(cmd, "child not running");
 	}
 
 	/* Parent. */

Bug#531690: fdm: duplicate messages delivery to the actual mailbox fails sometimes

[Frank Terbeck]

Ritesh Raj Sarraf :
> I have discussed this issue with upstream and we believe there is a bug
> in fdm when delivering acutal messages to mailboxes for which, in its
> cache, it detects that it is a duplicate. This issue is intermittent and
> hard to reproduce.

Since the discussion about that problem wasn't public, I know nothing
about it.

I trust you will inform me of the progress.
If the problem will be fixed in a future release or by any other
means, I'll happily update the package.

Regards, Frank



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

Bug#538194: fdm doesn't handle EXDEV when linking files.

[Frank Terbeck]

[ Ccing the fdm-users mailing list. Please reply to all addresses in ]
[ To: and Cc: in order to keep all involved parties and the debian   ]
[ BTS in the loop.   ]

A new bug report via the debian BTS, which includes a suggestion for a
fix.

The referenced bug #352589 can be found here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352589

Regards, Frank

Louis Opter :
> Package: fdm
> Version: 1.5-3
> Severity: important
> Tags: patch
> 
> Dear maintainer,
> 
> link() fails with EXDEV when you try to link files accross file systems.
> 
> On the AFS file system, this also occurs between directories :
> http://docs.openafs.org/AdminGuide/ch02.html#HDRWQ32
> 
> This special case breaks fdm when using maildirs on OpenAFS.
> 
> I suggest a patch which workaround EXDEV by using stat() and rename().
> 
> I haven't run fdm's regressions tests on it. I have just checked it on
> AFS and ext3.
> 
> A similar issue has been fixed in openssh (see #352589).
> 
> The same bug certainly exists in other parts of fdm.
> 
> Here is the code :
> 
--- fdm-1.5.orig/deliver-maildir.c  2008-03-06 10:25:32.0 +0100
+++ fdm-1.5-3.debian.louis/deliver-maildir.c2009-07-23 21:28:34.418851829 
+0200
@@ -146,6 +146,7 @@
char src[MAXPATHLEN], dst[MAXPATHLEN];
int  fd;
ssize_t  n;
+   struct stat  sb;
 
name = NULL;
fd = -1;
@@ -195,28 +196,52 @@
fd = -1;
 
/*
-* Create the new path and attempt to link it. A failed link jumps
-* back to find another name in the tmp directory.
+* Create the new path and attempt to link it. A failed link on EEXIST
+* jumps back to find another name in the tmp directory.
 */
if (ppath(dst, sizeof dst, "%s/new/%s", path, name) != 0)
goto error_unlink;
log_debug2(
"%s: linking .../tmp/%s to .../new/%s", a->name, name, name);
if (link(src, dst) != 0) {
-   if (errno == EEXIST) {
-   log_debug2("%s: %s: link failed", a->name, src);
+   log_debug2("%s: %s: link failed", a->name, src);
+   /*
+* EXDEV must also be handled, especially for the AFS filesystem
+* where hardlinks can't traverse directories :
+* http://docs.openafs.org/AdminGuide/ch02.html#HDRWQ32
+*/
+   if (errno == EXDEV) {
+   log_debug2("%s: renaming .../tmp/%s to .../new/%s",
+   a->name, name, name);
+   /*
+* But stat + rename can be racy.
+*/
+   if (stat(dst, &sb) == -1) {
+   if (errno != ENOENT || rename(src, dst) != 0) {
+   log_debug2("%s: %s: rename failed",
+   a->name, src);
+   goto error_cleanup;
+   }
+   } else { /* EEXIST */
+   if (unlink(src) != 0)
+   fatal("unlink failed");
+   cleanup_deregister(src);
+   goto restart;
+   }
+   } else if (errno == EEXIST) {
if (unlink(src) != 0)
fatal("unlink failed");
cleanup_deregister(src);
goto restart;
-   }
-   goto error_unlink;
+   } else /* Dot it only if we are not on EXDEV */
+   goto error_unlink;
+   } else {
+   /* Unlink the original tmp file. */
+   log_debug2("%s: unlinking .../tmp/%s", a->name, name);
+   if (unlink(src) != 0)
+   goto error_unlink;
}
 
-   /* Unlink the original tmp file. */
-   log_debug2("%s: unlinking .../tmp/%s", a->name, name);
-   if (unlink(src) != 0)
-   goto error_unlink;
cleanup_deregister(src);
 
/* Save the mail file as a tag. */
@@ -229,6 +254,7 @@
 error_unlink:
if (unlink(src) != 0)
fatal("unlink failed");
+error_cleanup:
cleanup_deregister(src);
 
 error_log:




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

Bug#497663: Tab completion for vim is broken

[Frank Terbeck]

Clint Adams <[EMAIL PROTECTED]>:
> On Thu, Sep 04, 2008 at 12:05:05PM +0300, Arto Jantunen wrote:
> > >> Typing vim and pressing tab produces the following output:
> > >> 
> > >> _vim:31: unmatched '
> > >> 
> > >> Commenting out lines 31-40 in
> > >> /usr/share/zsh/functions/Completion/Unix/_vim fixes the problem. Should
> > >> be trivial to fix properly for someone who understands zsh's compeltion
> > >> syntax (I don't).
> > >
> > > I can't reproduce this and I don't see what the problem might be.
> > > Is this consistent for you?
> > 
> > Hmm. Apparently it depends on "emulate csh" being used. I can't
> > reproduce with a .zshrc of only
> > 
> > autoload -U compinit
> > compinit
> > 
> > But can after adding emulate csh above those lines.
> 
> Anyone know which option might be the culprit here?

Yes, 'csh_junkie_quotes'.

The problem will vanish, if you unset that option after your 'emulate
csh' call.

However, I thought 'setopt no_csh_junkie_quotes' or 'emulate -L' at
the start of the file would be enough. But apparently it isn't...

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#456871: fdm: diff for NMU version 1.4-1.1

[Frank Terbeck]

[EMAIL PROTECTED]:
> The following is the diff for my fdm 1.4-1.1 NMU.

Okay, but see below

> The fixed tdb-dev has just been uploaded.

I know, I was subscribed to that bug.

> --- fdm-1.4/debian/control
> +++ fdm-1.4/debian/control
[...]
> -Build-Depends: debhelper (>= 5), libssl-dev, zlib1g-dev, libpcre3-dev, 
> tdb-dev, bison, flex, dpatch
> +Build-Depends: debhelper (>= 5), libssl-dev, zlib1g-dev, libpcre3-dev, 
> tdb-dev (>= 1.1.1~svn26294-1.1), bison, flex, dpatch
[...]

There has been a new upstream release recently, for which I got an
appropriate package which includes exactly the same fix for #456871.

The new package is ready and I will ask my mentor to upload it as soon
as the fixed tdb-dev package hits the mirrors and I can run some
tests.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#456871: fdm: diff for NMU version 1.4-1.1

[Frank Terbeck]

Thomas Viehmann <[EMAIL PROTECTED]>:
> On 2008-03-09 16:02:37.00 Frank Terbeck <[EMAIL PROTECTED]> wrote:
[...]
>> The new package is ready and I will ask my mentor to upload it as soon
>> as the fixed tdb-dev package hits the mirrors and I can run some
>> tests.
>
> It would be helpful if you could keep the bug logs updated with you
> progress, in particular for release relevant (RC and goals) bugs that
> people are bound to look at.

Yeah, I'll be sure to do that in the future. However, for such a
trivial bug, stating "Yes, I will increase the required version once
the fixed builddep is out." seems utterly useless. Because its trivial
and therefore goes without saying, IMNSHO.

Also, dropping a short question, if this bus has been dealt with would
have been an option, too; (no offence intended, of course).

Anyway, I'll just stick small notes to bugs I can't solve right away
because something blocks me from doing so, in the future to prevent
such unnecessary work once and for all.

Regards, Frank



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#595057: Denial of service on systems running fdm

[Frank Terbeck]

Hubert Kario wrote:
> Package: fdm
> Version: 1.5-3
> Severity: critical
> Justification: breaks unrelated software
>
> When recieving e-mail with attachments sent from my ISP webmail fdm
> starts eating all avaiable memory.
>
> Just after 10 seconds it allocates over 300MiB, when over 5GB are
> allocated system starts swapping.  As a result, the system is unusable
> until OOM killer kicks in.

Hubert reported the bug upstream, too, where it has started being
discussed. I'll see what comes off of that before moving forward.

Regards, Frank



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

Bug#611175: zsh: VCS_INFO wrongly detects svn repositories

[Frank Terbeck]

Lennart Weller wrote:
> Currently zshs VCS_INFO function wrongly detects svn repositories if
> an .svn directory exists in the current path. Which also applies to
> home directories containing for example a ~/.svn/authors file.

That's a good point...

> Instead of checking only for the directory it would be smarter to
> check for an important svn repository file.  Like .svn/entries. Which
> is done through my patch.

That sounds reasonable. Do you know how stable the "entries" file is
within the .svn directories with respect to versions? Ie. Does it exist
in old versions as well as in recent ones? (My knowledge of subversion's
directory contents are rather limited.)

> I suggest to check the other revison control systems as well.

The other backends should not suffer from this problems. All others that
look for a directory to detect a VCS already look for a file in addition
to the directory. I don't remember why we didn't do this for svn
earlier, too. Probably because nobody complained. :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



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

Bug#611175: zsh: VCS_INFO wrongly detects svn repositories

[Frank Terbeck]

Lennart Weller wrote:
> On 27.01.2011 16:58, Frank Terbeck wrote:
>> That sounds reasonable. Do you know how stable the "entries" file is
>> within the .svn directories with respect to versions? Ie. Does it exist
>> in old versions as well as in recent ones? (My knowledge of subversion's
>> directory contents are rather limited.)
>> 
> I don't use svn frequently either but I just happend to have a
> ~/.svn/authors file which caused the bug. I found this:
> http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version
>
> So checking:
> [[ -f ".svn/entries" || -f ".svn/format" ]] && return 0
> should be sufficient for all versions.

Great. I'll commit this upstream as soon as I can. Thanks.

I suggest, debian does the same (maybe you could update your patch for
debian's convenience).

One nit: you reported this against version 4.3.6-6; however vcs_info was
shipped with zsh 4.3.7 for the first time. ...so unless debian's 4.3.6-6
package ships it on its own, I doubt that's correct. :)

Anyway, debian's maintainers will know how to handle this.

Regards, Frank



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

Bug#611175: PATCH: Fix for vcs_info's svn detection

[Frank Terbeck]

Let's try this again, shall we? Apparently, it's harder to use an email
client than it looks. Also, as Mikael informs me on IRC, I screwed up
the patch in the first mail... *sigh*

...now that CVS is back...

Here's a fix for an issue with vcs_info's subversion detection, which
was reported in the debian BTS (issue #611175¹).

The fix was suggested by Lennart Weller.

¹ 

Regards, Frank


Index: Functions/VCS_Info/Backends/VCS_INFO_detect_svn
===
RCS file: /cvsroot/zsh/zsh/Functions/VCS_Info/Backends/VCS_INFO_detect_svn,v
retrieving revision 1.2
diff -u -r1.2 VCS_INFO_detect_svn
--- Functions/VCS_Info/Backends/VCS_INFO_detect_svn 11 Dec 2008 09:53:13 
-  1.2
+++ Functions/VCS_Info/Backends/VCS_INFO_detect_svn 11 Feb 2011 06:44:51 
-
@@ -7,5 +7,5 @@
 [[ $1 == '--flavours' ]] && return 1
 
 VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
-[[ -d ".svn" ]] && return 0
+{ [[ -f ".svn/entries" ]] || [[ -f ".svn/format" ]] } && return 0
 return 1



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

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
> $ autoload -U colors
> $ colors
> colors:89: bad set of key/value pairs for associative array
>
> Commenting out the following line helps:
>
> /usr/share/zsh/functions/Misc/colors
>  89 colour=(${(kv)color}) # A case where ksh namerefs would be useful ...
>
> Any idea why this fails?

That should only happen if ${#color} is an odd number, which for an
associative array, shouldn't be possible. So, after running your "fixed"
function, do this:

% print ${(t)color}
% print ${#color}

The first command should print `association', the second should print
an *even* number (`76' for me). Also, a trace might be helpful:

% (set -x; colors;) 2>&1 | cat -v

Regards, Frank



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

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
[...]
> (dedeibel@jet)(262/pts)(14:25:13.02.11)-
> (%:~)- print ${#color}
> 4

Yeah. I was a little quick about this. This only prints the number of
key-value pairs in the associative array. What we're actually looking
for is this:

% print ${#${(kv)color}}

In any case, `4' is too low a value. what does this print?

% printf '%s = '\''%s'\''\n' ${(kv)color} | sort

>
> (dedeibel@jet)(263/pts)(14:25:13.02.11)-
> (%:~)- (set -x; colors;) 2>&1 | cat -v
> +/bin/zsh:3> colors
> +colors:4> typeset -Ag color colour
> +colors:6> color=( 00 none 01 bold 02 faint 22 normal 03 standout 23
> no-standout 04 underline 24 no-underline 05 blink 25 no-blink 07
> reverse 27 no-reverse 08 conceal 28 no-conceal 30 black 40 bg-black 31
> red 41 bg-red 32 green 42 bg-green 33 yellow 43 bg-yellow 34 blue 44
> bg-blue 35 magenta 45 bg-magenta 36 cyan 46 bg-cyan 37 white 47
> bg-white 39 default 49 bg-default )
[...]
> Does this tell you anything?

Thanks, I'll take a look at it when I'm on the train.

> What exactly does ${(kv)color} access? Is kv a value?

Those flags are used to access the keys and values of an associative
array:

% foo=( bar baz beer booze zack zonk )
% print ${foo[zack]}
zonk
% print ${(k)foo}
zack bar beer
% print ${(v)foo}
zonk baz booze
% print ${(kv)foo}
zack zonk bar baz beer booze


The latter is used to initialise $colour (British) with the same values
as in $color (American).

Regards, Frank



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

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
[...]
> (%:~)- (set -x; colors;) 2>&1 | cat -v
> +/bin/zsh:3> colors
> +colors:4> typeset -Ag color colour
> +colors:6> color=( 00 none 01 bold 02 faint 22 normal 03 standout 23
> no-standout 04 underline 24 no-underline 05 blink 25 no-blink 07
> reverse 27 no-reverse 08 conceal 28 no-conceal 30 black 40 bg-black 31
> red 41 bg-red 32 green 42 bg-green 33 yellow 43 bg-yellow 34 blue 44
> bg-blue 35 magenta 45 bg-magenta 36 cyan 46 bg-cyan 37 white 47
> bg-white 39 default 49 bg-default )

Initialisation looks good.

> +colors:74> local k
> +colors:75> k=bg-blue
> +colors:75> color[${color[$k]}]=bg-blue

This looks wrong already. The actual code is this:

for k in ${(k)color}; do
color[${color[$k]}]=$k
done

So this should iterate over all keys in `$color'. Those should be 00,
01, 02, etc. And not even "bg-blue", which is the *value* to the key 44.

> +colors:79> k=30
> +colors:79> color[fg-${color[$k]}]=30
> +colors:79> k=31
> +colors:79> color[fg-${color[$k]}]=31
> +colors:79> k=32
> +colors:79> color[fg-${color[$k]}]=32
> +colors:79> k=33
> +colors:79> color[fg-${color[$k]}]=33
> +colors:79> k=34
> +colors:79> color[fg-${color[$k]}]=34
> +colors:79> k=35
> +colors:79> color[fg-${color[$k]}]=35
> +colors:79> k=36
> +colors:79> color[fg-${color[$k]}]=36
> +colors:79> k=37
> +colors:79> color[fg-${color[$k]}]=37
> +colors:79> k=39
> +colors:79> color[fg-${color[$k]}]=39

This is this loop:

for k in ${color[(I)3?]}; do
color[fg-${color[$k]}]=$k
done

Looks good.

> +colors:83> color[grey]=''
> +colors:84> color[fg-grey]=''
> +colors:85> color[bg-grey]=''

Just a few assignments.

After this, the colours= assignment follows, which is missing in here as
expected, since you commented to out..

> +colors:95> local 'lc=^[[' 'rc=m'
> +colors:97> typeset -Hg reset_color bold_color
> +colors:98> reset_color='^[[m'
> +colors:99> bold_color='^[[m'
> +colors:103> typeset -AHg fg fg_bold fg_no_bold

A few more assignments.

[...]

What follows is the construction of the `$fg[]' and `$bg[]' associative
arrays (and friends). It looks correct but a little short, which I blame
on the first loop from above screwing up.

My suspicion is that this is an effect of an option. Could it be, that
you're setting the `ksharrays' option? I strongly suspect that you do.

[[ -o ksharrays ]] && print option set || print option unset

If you do, a workaround would be to set the ksharrays option *after*
you're running the `colors' function.

A fix would be to either locally unset the `ksharrays' option in this
function, or to use an array expansion, that works independently of this
particular setting. Could you try if this patch fixes the issue even if
`ksharrays' is set?


diff --git a/Functions/Misc/colors b/Functions/Misc/colors
index bef93c8..dfa169a 100644
--- a/Functions/Misc/colors
+++ b/Functions/Misc/colors
@@ -72,7 +72,7 @@ color=(
 # but it's clearer to include them all both ways.
 
 local k
-for k in ${(k)color}; do color[${color[$k]}]=$k; done
+for k in "${(k)color[@]}"; do color[${color[$k]}]=$k; done
 
 # Add "fg-" keys for all the text colors, for clarity.
 
@@ -86,7 +86,7 @@ color[bg-grey]=${color[bg-black]}
 
 # Assistance for the color-blind.
 
-colour=(${(kv)color})  # A case where ksh namerefs would be useful ...
+colour=( "${(kv)color[@]}" )   # A case where ksh namerefs would be useful ...
 
 # The following are terminal escape sequences used by colored prompt themes.
 


I think that should fix the issue. However, the simpler fix is to just
say this in the first line of code in the `colors' file:

setopt localoption no_ksharrays

If you could verify my suspicion, that'd be swell.

Regards, Frank



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

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
> On 02/13/2011 04:50 PM, Frank Terbeck wrote:
[...]
>> % printf '%s = '\''%s'\''\n' ${(kv)color} | sort
>>
>
> Not sure if this does what it was inteded to.
>
> $ printf '%s = '\''%s'\''\n' ${(kv)color} | sort
>  = ''''''
> ' ${(kv)color} | sortnone = ''

Yes, for you it doesn't, pretty much because of the ksh_arrays option I
mentioned in the other mail.

> When I just do the following I get
>
> $ print ${(kv)color}
> none
>
> But I think I figured what you wanted.
>
> Maybe this?
>
> printf '%s = %s\n' ${(kv)color[*]} | sort

Actually, I wanted @ and double-quotes rather than *, but for the
involved values, it doesn't make a difference. :)

> Anyway. I tried to to do some kind of single step printf debugging
> after your printf hints and added the files as an attachement.[...]
[...]

Thanks, I'm pretty sure I found the underlying cause by looking at the
xtrace you provided earlier today. See if my ideas around ksh_arrays
help with the problem (I'm fairly sure they will).

Regards, Frank



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

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Frank Terbeck wrote:
[...]
> My suspicion is that this is an effect of an option. Could it be, that
> you're setting the `ksharrays' option? I strongly suspect that you do.
[...]

This supports my claim:

zsh% zsh -fc 'autoload -U colors; colors'
zsh% zsh -f -o ksh_arrays -c 'autoload -U colors; colors'
colors:89: bad set of key/value pairs for associative array
zsh% _


Regards, Frank



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