date:20140312

Bug#741402: [bash] Shell functions definitions may require parentheses despite function keyword

2014-03-12 Thread Filipus Klutiero


Package: bash
Version: 4.3-2
Severity: minor
X-Debbugs-Cc: bug-b...@gnu.org

According to the manual, either the function keyword or parentheses should be 
sufficient to define a function:


Shell Function Definitions


 A shell function is an object that is called like a simple command and 
executes a compound command with a new set of positional parameters. Shell 
functions are declared as follows:
name () compound-command [redirection]
function name [()] compound-command [redirection]
 This defines a function named name. The reserved word function is optional. If 
the function reserved word is supplied, the parentheses are optional. The body 
of the function is the compound command compound-command  (see Compound 
Commands above). That command is usually a list of commands between { and }, 
but may be any command listed under Compound Commands above. compound-command 
is executed whenever name is specified as the name of a simple command. When in 
posix mode, name may not be the name of one of the POSIX special builtins. Any 
redirections (see REDIRECTION below) specified when a function is defined are 
performed when the function is executed. The exit status of a function 
definition is zero unless a syntax error occurs or a readonly function with the 
same name already exists. When executed, the exit status of a function is the 
exit status of the last command executed in the body. (See FUNCTIONS   below.)


The following definition should therefore be valid:

$ function bar (echo x)


...but it's not:

bash: syntax error near unexpected token `echo'


However, an identical function can be defined with the following definition:


$ function bar () (echo x)


I suspect this is an upstream bug.

--- System information. ---
Architecture: i386
Kernel: Linux 3.12-1-amd64

Debian Release: jessie/sid
990 testing debian.mirror.iweb.ca
500 unstable debian.mirror.iweb.ca
1 experimental ftp3.nrc.ca

--- Package information. ---
Depends (Version) | Installed
===-+-
base-files (= 2.1.12) | 7.2
debianutils (= 2.15) | 4.4


Recommends (Version) | Installed
===-+-
bash-completion (= 20060301-0) | 1:2.1-2


Suggests (Version) | Installed
===-+-===
bash-doc | 4.3-2

--
Filipus Klutiero
http://www.philippecloutier.com


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

Bug#680389: gvfsd-afp consumes lot of cpu

2014-03-12 Thread Dan DeVoto

Package: gvfs
Version: 1.16.3-2
Followup-For: Bug #680389

Dear Maintainer,

Same bug in Jessie: gvfsd-afp-browse shoots to 100% cpu on the client side 
(iBook G3) when I disconnect the afp server on my OS X Tiger machine.  
Additionally, when I have an afp volume mounted on the client side, both 
gvfsd-afp and gvfsd-afp-browse shoot to maximum cpu after disconnecting the afp 
server.

Regards,

Dan


-- System Information:
Debian Release: jessie/sid
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.12-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gvfs depends on:
ii  gvfs-common   1.16.3-2
ii  gvfs-daemons  1.16.3-2
ii  gvfs-libs 1.16.3-2
ii  libc6 2.17-97
ii  libglib2.0-0  2.38.2-5
ii  libudev1  204-7

gvfs recommends no packages.

Versions of packages gvfs suggests:
ii  gvfs-backends  1.16.3-2

-- no debconf information


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

Bug#741402: Parentheses

2014-03-12 Thread Filipus Klutiero


Sorry, I forgot to mention explicitly that the compound command's form 
determines whether this will happen or not. The issue happens with

(list)

but not, for example, with

{ list; }


I did not test other forms, but I suppose only (list) is affected. The error 
message strongly suggests that the parser simply expects that an opening parenthesis will 
be directly followed by a closing parenthesis.

--
Filipus Klutiero
http://www.philippecloutier.com


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

Bug#741403: ircd-hybrid: [INTL:fr] French debconf templates translation update

2014-03-12 Thread Christian Perrier

Package: ircd-hybrid
Version: N/A
Severity: wishlist
Tags: patch l10n

Please find attached the french debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Thanks for taking care of warning translators before uploading a new
version with string changes. It's highly appreciated.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
# Translators, if you are not familiar with the PO format, gettext
# documentation is worth reading, especially sections dedicated to
# this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
# Some information specific to po-debconf are available at
# /usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
# Developers do not need to manually edit POT or PO files.
#
# Christian Perrier bubu...@debian.org, 2013, 2014.
msgid 
msgstr 
Project-Id-Version: ircd-hybrid 1:7.0-5\n
Report-Msgid-Bugs-To: ircd-hyb...@packages.debian.org\n
POT-Creation-Date: 2014-03-07 22:09+\n
PO-Revision-Date: 2014-03-08 08:09+0100\n
Last-Translator: Christian Perrier bubu...@debian.org\n
Language-Team: French debian-l10n-fre...@lists.debian.org\n
Language: fr\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n  1);\n
X-Generator: Lokalize 1.5\n

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid Restart ircd-hybrid on each upgrade?
msgstr Faut-il redémarrer ircd-hybrid à chaque mise à niveau ?

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid 
Please choose whether the ircd-hybrid daemon should be restarted every time 
a new version of this package is installed.
msgstr 
Veuillez choisir si le démon ircd-hybrid doit être redémarré à chaque 
installation d'une nouvelle version de ce paquet.

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid 
Automatic restarts may be problematic if, for instance, the server is 
running with manually loaded modules, which will need to be reloaded after 
the restart.
msgstr 
De tels redémarrages peuvent poser problème si, par exemple, le serveur 
utilise des modules chargés manuellement. Ces modules doivent alors être 
relancés après le redémarrage.

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid 
If you reject this option, you will have to restart ircd-hybrid via 
\service ircd-hybrid restart\ when needed.
msgstr 
Si vous refusez cette option, vous devrez redémarrer vous-même ircd-hybrid 
après une mise à jour, en utilisant la commande « service ircd-hybrid 
restart ».

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid Upgrade ircd-hybrid to version without cryptlink support?
msgstr 
Faut-il mettre à jour ircd-hybrid avec une version sans gestion de 
« cryptlink » ?

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid 
The 8.x version of ircd-hybrid includes a change to the way secure server 
links are implemented, which is not backwards-compatible with ircd-hybrid 7.
x, from which you are upgrading.
msgstr 
La version 8.x de ircd-hybrid modifie la gestion des liens sécurisés vers le 
serveur. Ce fonctionnement n'est pas compatible avec la version 7.x qui est 
en train d'être mise à jour.

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid 
If you have any secure server links (cryptlinks) configured with this 
server, you should plan to either upgrade all servers in lock-step, or 
temporarily configure non-cryptlink server links, to ensure the continuity 
of your IRC links.
msgstr 
Si vous utilisez des liens serveur sécurisés (« cryptlinks »), vous devriez 
prévoir de mettre tous les serveurs à jour en mode verrouillé (« lock-
step ») ou de temporairement configurer des liens non sécurisés, afin de 
garantir la continuité de service entre les liens IRC.

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:4001
msgid Upgrade ircd-hybrid to version without compatible services?
msgstr Faut-il mettre à jour ircd-hybrid avec des services incompatibles ?

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:4001
msgid 
The 8.x version of ircd-hybrid includes a change to the way services are 
supported, losing compatibility with hybserv.
msgstr 
La version 8.x d'ircd-hybrid modifie le mode de gestion des services et 
n'est plus compatible avec hybserv.

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:4001
msgid 
The recommended services daemon for Hybrid 8 is Anope, for which no package 
is available yet, although one is planned.
msgstr 
Le démon de gestion de services recommandé avec Hybrid 8 est Anope. Il 
n'existe pas encore de paquet pour ce démon.

#. Type:

Bug#741390: [coreutils] cp does not copy directories by default

2014-03-12 Thread Bob Proulx

Hi Filipus,

Filipus Klutiero wrote:
 Right. It could be
 
 cp [-R|-a|-r] [OPTION]... FILE... DIRECTORY
 cp [OPTION]... REGULAR-FILE... DIRECTORY
 
 But then, there are more file types than regular files and
 directories, so that probably wouldn't be perfect.

I think keeping it generic with simply SOURCE or FILE is better.
(Noting that directories are files too.)

The behavior of cp on whatever source file is going to be whatever is
allowed on the original file.  Whether that is a regular file, a
pipe, a character device, a block device or whatever.  Directories are
the most special because you can't open(2) them.  (And the same for
unix domain sockets.)

If cp can open the file then it will read the contents then it will
write the contents out.  Trying to individually document what happens
with various input files types means that if the kernel adds a new
type of file that the cp documentation is immediately out of date.
Better to avoid that and simply say it copies from the source file to
the destination.

Whatever the source file type I expect that if the kernel allows me to
open the file and read it then I expect cp to do so and to read the
source file and to copy it to the destination file.  Whether this is
successful completely depends upon the file type and the kernel and
not cp.

 I didn't mean to blame the synopsis, it was just part of the
 relevant part of the manpage. The problematic parts are the NAME
 section (copy files*and directories*) and the description Copy
 SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

Hmm...  Interesting.  So if it didn't say and directories it would
be better?  I note that BSD and SunOS don't say that.  But HP-UX
does.  And the old V7 just said copy and nothing more.  I think the
addition are trying to make things better but perhaps they do say too
much.

 The challenge for the 'cp --help' online documentation is to keep them
 short and concise yet accurately display the required information.
 This is then turned into the man page.
 
 I understand the resources challenge. Sometimes vagueness is the
 only solution.

Yep!

 In the end, we know that most people will use the manpage. cp's
 manpage may be incomplete or vague, but it can't afford to mislead
 readers on a behavior as fundamental as the treatment of
 directories.

But if and directories doesn't appear in the synopsis then it won't
appear in an apropos ('man -k') keyword search.  And 'cp' will copy
directories with the right options.  However the kitchen sink of
file copying tools is 'rsync'.  'rsync' never met an option that it
couldn't incorporate!  The rsync synopsis doesn't mention directories
so that must be okay.  Maybe the and directories should simply be
dropped.

 Note here is the POSIX online documentation on the cp command.
 
http://pubs.opengroup.org/onlinepubs/009695399/utilities/cp.html
 
 Thanks, this is very interesting. First, the NAME just says copy
 files rather than copy files and directories. Some may equate
 copy files with copy all files, but I do not consider the POSIX
 NAME misleading.

V7 just says copy.  BSD says copy files.  HP-UX says copy file
and directory subtrees.

 Then, the synopsis treats -R as a different form, as you
 discussed. This has the advantage of allowing a separate description
 for the 2 forms.

There can always be description even with one synopsis.

 I have no strong opinion on which approach is preferable. Either 2
 forms and 2 descriptions or keeping 1 form with a different
 description. As long as 1 - we don't say that cp copies SOURCE to
 DEST, when SOURCE can't be a directory without options, or 2 - we
 add right after a big warning about directories like the info
 documentation's.

I think it would be defendable to request upstream to change to:

-Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.\n\
+Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY,\n\
+or optionally recursively directory SOURCES(s) to DIRECTORY.\n\

Bob


signature.asc
Description: Digital signature

Bug#741293: git over https fails with gnutls_handshake() failed: A record packet with illegal version was received.

2014-03-12 Thread Andras Korn

On Tue, Mar 11, 2014 at 11:27:24PM +0100, Alessandro Ghedini wrote:

So, the problem is not gnutls (or not *just* gnutls), but the fact that the
server doesn't seem to support TLSv1,

That is likely related to this Apache config setting:

# Work around SSL negotiation failed: SSL error: parse tlsext; see e.g.
#
http://serverfault.com/questions/44470/ssl-error-parse-tlsext-on-large-commit-to-svn-via-apache-gentoo
SSLProtocol -ALL +SSLv3

Unfortunately I can't lose this altogether because I have to support old
clients that seem to need it.

However, I confirm that disabling this setting works around the
git/curl/gnutls problem.

and that for some reason the TLS renegotiation fails.

I can reproduce this with OpenSSL too, by forcing TLSv1:

% openssl s_client -host host -port 443 -tls1
CONNECTED(0003)
139971996092048:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:

And gnutls-cli:

% gnutls-cli host -p 443 --priority
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:%COMPAT
[...]
*** Fatal error: A record packet with illegal version was received.
*** Handshake has failed
GnuTLS error: A record packet with illegal version was received.

Now, why does libcurl fails while gnutls-cli (built against libgnutls26) does
not (not by default, anyway)? That may be a bug in libcurl, I'll look into
this
later.

1 2 3 >

1 - 100 of 263 matches

Mail list logo