Bug#673019: Support multiple ssh keys of same type

2012-05-15 Thread Cesar Mendoza
Hi,

This is weird and I don't think it's related to keychain. I'm able to load
multiple keys of the same type without issues. I don't have a sid
environment right now to see if I can reproduce the issue there. Can you
please verify that both RSA keys are different and not the same key with
different file names. Because in that case keychain will only load one.
I'll try to setup a SID environment to test there.

 * keychain 2.7.1 ~ http://www.funtoo.org
 * Found existing ssh-agent: 2880
 * ssh-agent: All identities removed.
 * Adding 4 ssh key(s): /home/paks/.ssh/id_dsa /home/paks/.ssh/id_rsa
/home/paks/.ssh/id_dsa2 /home/paks/.ssh/id_rsa2
Enter passphrase for /home/paks/.ssh/id_dsa:
 * ssh-add: Identities added: /home/paks/.ssh/id_dsa /home/paks/.ssh/id_rsa
/home/paks/.ssh/id_dsa2 /home/paks/.ssh/id_rsa2

ssh-add -l
1024 00:33:8d:a6:70:55:17:71:e8:82:82:e9:e8:76:b8:90 /home/paks/.ssh/id_dsa
(DSA)
1024 25:81:46:9e:cd:67:5a:99:94:9c:e8:ba:ef:26:65:a2 /home/paks/.ssh/id_rsa
(RSA)
1024 f3:37:ac:bf:e0:0d:c8:38:a0:49:97:db:25:4d:7f:02
/home/paks/.ssh/id_dsa2 (DSA)
2048 77:35:15:e1:f1:d8:0b:47:e2:42:95:57:f0:e4:66:24
/home/paks/.ssh/id_rsa2 (RSA)


Bye
Cesar
--


On Tue, May 15, 2012 at 8:13 AM, Ryan Kavanagh r...@debian.org wrote:

 Package: keychain
 Version: 2.7.1-1
 Severity: wishlist
 Tags: upstream

 Please support multiple RSA, ECDSA, etc. ssh keys. For example, I have
 two RSA keys, but keychain will only load the first. I then have to
 manually add the second with ssh-add. In my .zshrc:

keychain id_rsa id_rsa.lambda id_ecdsa
keychain -Q ${GPGKEY} ${GPGKEY1}
[ -z $HOSTNAME ]  HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] 
   . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] 
   . $HOME/.keychain/$HOSTNAME-sh-gpg

 on start (usually prompts for passphrase(s), but I don't want to ruin
 existing sessions by killing my agents to show the prompt):

  * keychain 2.7.1 ~ http://www.funtoo.org
  * Found existing ssh-agent: 3087
  * Found existing gpg-agent: 5435
  * Known ssh key: /home/ryan/.ssh/id_rsa
  * Known ssh key: /home/ryan/.ssh/id_ecdsa

 but then output of ssh-add -l:

 8192 ca:48:02:4a:2e:ee:2a:80:83:a9:fd:d6:a2:dd:5e:45
 /home/ryan/.ssh/id_rsa (RSA)
 521 8c:cd:93:ca:55:65:e0:48:bc:c8:3e:aa:f0:16:14:d0
 /home/ryan/.ssh/id_ecdsa (ECDSA)

 I have tried renaming id_rsa.lambda to id_lambda with no luck.

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

 Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores)
 Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) (ignored:
 LC_ALL set to es_ES.UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages keychain depends on:
 ii  grep 2.11-3
 ii  openssh-client [ssh-client]  1:5.9p1-5

 keychain recommends no packages.

 Versions of packages keychain suggests:
 ii  gnupg-agent2.0.19-1
 ii  ksshaskpass [ssh-askpass]  0.5.3-1+b1
 ii  kwalletcli [ssh-askpass]   2.11-2

 -- no debconf information



Bug#644710: keychain: New upstream version available (2.7.1)

2011-10-11 Thread Cesar Mendoza
Hi,

Thank you for the info. I just packaged the new version and uploaded it into
unstable.

Bye
Cesar
--


On Sat, Oct 8, 2011 at 7:34 AM, Ilya Barygin bary...@gmail.com wrote:

 Package: keychain
 Version: 2.6.8-2
 Severity: wishlist

 Hello,

 Several users of Ubuntu have requested update of keychain to a new upstream
 version, 2.7.1. Please consider packaging it.
 Ubuntu bug for this is https://launchpad.net/bugs/481191

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500,
 'natty-proposed'), (500, 'natty'), (100, 'natty-backports')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.38-11-generic (SMP w/2 CPU cores)
 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash





Bug#577246: keychain: update README.examples

2010-04-12 Thread Cesar Mendoza
Hi,

I'll update the readme file. Thank you for your contribution to Debian.

Bye
Cesar
--
Fiction is obliged to stick to possibilities. Truth isn't.
  --Samuel Clemens (Mark Twain) http://en.wikipedia.org/wiki/Mark_Twain

On Sat, Apr 10, 2010 at 1:06 PM, Éric Araujo mer...@netwok.org wrote:

 Package: keychain
 Version: 2.6.8-2
 Severity: minor

 Hello  keychain’s README.examples still says that the GPG part does not
 function, but #336480 is fixed now.  Regards


 -- System Information:
 Debian Release: squeeze
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages keychain depends on:
 ii  grep  2.5.4-4GNU grep, egrep and fgrep
 ii  openssh-client [ssh-client]   1:5.3p1-3  secure shell (SSH) client, for
 sec

 keychain recommends no packages.

 Versions of packages keychain suggests:
 ii  gnupg-agent   2.0.14-1   GNU privacy guard - password
 agent
 ii  gtk-led-askpass [ssh-askpass] 0.10-2 GTK+ password dialog suitable
 for

 -- no debconf information






Bug#435996: lists-archives: crontest failure chown: cannot access '/var/lib/lists-archives/glimpse': No such file or directory

2007-08-13 Thread Cesar Mendoza
Hi,

Thanks for the input. I'll check into the issue.

Bye
Cesar Mendoza
http://www.kitiara.org
--
Sólo la infancia es la época adecuada 
para sembrar la semilla de la fe.. 
  --Schopenhauer


On Sat, Aug 04, 2007 at 04:18:18PM +0200, Filippo Giunchedi wrote:
 Package: lists-archives
 Version: 200300506-1.1
 User: [EMAIL PROTECTED]
 Usertags: cron-qa-20070804
 
 Hi,
 it seems that lists-archives cron files are giving output when the package 
 itself is removed
 (REMOVE) or its dependencies (AUTOREMOVE).
 
 log available at:
 http://svn.debian.org/wsvn/collab-qa/crontest/2007-08-04/logs/lists-archives_200300506-1.1_sid.cronlog?op=file
 
 reported below:
 REMOVE CRON.DAILY [] [chown: cannot access 
 `/var/lib/lists-archives/glimpse': No such file or directory\n]
 AUTOREMOVE CRON.DAILY [] [chown: cannot access 
 `/var/lib/lists-archives/glimpse': No such file or directory\n]
 
 you should check that /var/lib/lists-archives/glimpse is there
 




Bug#366073: keychain: awk: warning: `IGNORECASE' is a gawk extension

2006-05-09 Thread Cesar Mendoza
Hi,

Thanks for your contribution to Debian. After checking the code, it
looks like the IGNORECASE setting is used to avoid problems when the
script is running under Cygwin. It looks like it would be safe to remove
the setting for Debian. I will do some testing to see if I can avoid
depending on gawk.

Bye
Cesar Mendoza
http://www.kitiara.org
--
Mi estrategia es / en cambio / más profunda y más / simple /
mi estrategia es / que un día cualquiera / no sé cómo
ni sé / con qué pretexto / por fin me necesites.
  -- Mario Benedetti, Táctica y Estrategia.


On Thu, May 04, 2006 at 09:02:51PM +, Brian M. Carlson wrote:
 Package: keychain
 Version: 2.5.5-5
 Severity: normal
 
 The stanza near line 480 (search for defunct) uses IGNORECASE, which is a
 gawk extension.  Additionally, this gawk extension is disabled if
 POSIXLY_CORRECT is set[0], which AIUI it is in newer versions of bash when
 invoked as /bin/sh.
 
 As a consequence, the match is not case-insensitive unless gawk is used and
 POSIX mode is disabled.  Therefore, you should either find some other way of
 removing that text (recommendation below) or Depend: gawk, use gawk instead of
 awk when invoking the program, and unset POSIXLY_CORRECT in the script.  If 
 you
 choose the latter option, please upgrade this bug to severity serious, since 
 the
 dependencies are incorrectly specified.
 
 I have created a testcase (test.sh) which I have attached.  It should be 
 invoked
 as ./test.sh, which will test this behavior with different combinations of the
 following parameters:
 * Uppercase/lowercase text as input to awk.
 * Uppercase/lowercase text as match for awk.
 * Setting/not setting IGNORECASE=1.
 * mawk/gawk.
 * Setting/not setting both POSIXLY_CORRECT=1 and _POSIX2_VERSION=200112.
 
 Additionally, if you set FORCE_CASE=1 when invoking test.sh, IGNORECASE=1 will
 never be set.  Only in this case will the test succeed.
 
 My recommendation is to remove the IGNORECASE=1 stanza and instead use the
 following construction:
 
 grep -vi 'defunct'
 
 Thank you for your time.
 
 [0] strings `which gawk` | grep -E '(POSIXLY_CORRECT|_POSIX2_VERSION)'
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers experimental
   APT policy: (500, 'experimental'), (500, 'unstable'), (500, 'testing'), 
 (500, 'stable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.16-1-k7
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_US.UTF-8)
 
 Versions of packages keychain depends on:
 ii  debconf [debconf-2.0]1.5.0   Debian configuration management 
 sy
 ii  grep 2.5.1.ds2-4 GNU grep, egrep and fgrep
 ii  openssh-client [ssh-client]  1:4.2p1-8   Secure shell client, an 
 rlogin/rsh
 
 keychain recommends no packages.
 
 -- no debconf information





Bug#336159: keychain should recommends gnupg-agent

2005-10-31 Thread Cesar Mendoza
Hi,

Thanks for your contribution to Debian. Do you think it's OK if I use Suggests
instead of Recommends? I think the definition of Suggests in the policy
manual fits better.

Bye
Cesar Mendoza
http://www.kitiara.org
--
First they tell you, you're wrong and they can prove it; 
then they tell you, you're right but it isn't important; 
then they tell you, it's important but they knew it all along.
 --Charles Kettering


On Fri, Oct 28, 2005 at 03:48:17PM +0800, LI Daobing wrote:
 Package: keychain
 Version: 2.5.5-4
 Severity: normal
 
 as the title
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.12-1-686-smp
 Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8)
 
 Versions of packages keychain depends on:
 ii  debconf [debconf-2.0]1.4.58  Debian configuration management 
 sy
 ii  grep 2.5.1.ds1-4 GNU grep, egrep and fgrep
 ii  openssh-client [ssh-client]  1:4.2p1-5   Secure shell client, an 
 rlogin/rsh
 
 keychain recommends no packages.
 
 -- debconf information:
 * keychain/upgrade:
 



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



Bug#325644: keychain error 'ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory'

2005-09-30 Thread Cesar Mendoza
Hi,

Can you please verify if after upgrading to openssh 1:4.1p1-7 keychain 
now works as expected without the --nogui option.

Bye
Cesar Mendoza
http://www.kitiara.org
--
Reality is that which refuses to go away 
when I stop believing in it.
  --Philip K. Dick

On Thu, Sep 29, 2005 at 09:40:51AM +0100, Colin Watson wrote:
 On Mon, Aug 29, 2005 at 07:53:02PM -0400, Barry Hawkins wrote:
   * Adding 2 ssh key(s)...
  ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
  ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
 
 I fixed this in openssh 1:4.1p1-7.
 
 openssh (1:4.1p1-7) unstable; urgency=low
 
   * Do the IDEA host key check on a temporary file to avoid altering
 /etc/ssh/ssh_host_key itself (closes: #312312).
   * Work around the ssh-askpass alternative somehow ending up in manual mode
 pointing to the obsolete /usr/lib/ssh/gnome-ssh-askpass.
   * Add GNU/kFreeBSD support (thanks, Aurelien Jarno; closes: #318113).
   * Fix XSIish uses of 'test' in openssh-server.preinst.
   * Policy version 3.6.2: no changes required.
 
  -- Colin Watson [EMAIL PROTECTED]  Fri,  2 Sep 2005 16:18:11 +0100
 
 Cheers,
 
 -- 
 Colin Watson   [EMAIL PROTECTED]
 



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



Bug#325644: keychain error 'ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory'

2005-08-31 Thread Cesar Mendoza
Hi,

Can you please send me the list of your environment variables when
keychain is running? 

Bye
Cesar Mendoza
http://www.kitiara.org
--
It is dangerous to be right when the government is wrong.
  -- Voltaire

On Tue, Aug 30, 2005 at 11:53:33PM -0400, Barry Hawkins wrote:
 Cesar Mendoza wrote:
  Hi,
  
  For now try the --nogui option on keychain. That should take care of
  your problem. Can you please tell me which version where you running
  before you upgraded? I would like to check why is the difference in
  behavior.
  
  Bye
  Cesar Mendoza
  http://www.kitiara.org
 [...]
 Adding the --nogui reference does indeed return the behavior to what I
 experienced prior to the upgrade to 2.5.5-3.  As far as my previous
 version, I run sid on i386, and update packages daily, so I am pretty
 sure I had 2.5.5-2 before that.  Sorry I haven't filed the gpg bug yet;
 will try to do that before I go to bed.  I have been working on some
 packages I really want to get released.
 
 Regards,
 --
 Barry Hawkins
 site: www.bytemason.org
 weblog: www.yepthatsme.com
 
 Registered Linux User #368650



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



Bug#325644: keychain error 'ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory'

2005-08-30 Thread Cesar Mendoza
Hi,


Thanks for your contribution to Debian. Can you please verify that
/usr/bin/ssh-askpass is not a dangling symlink? On Debian systems
/usr/bin/ssh-askpass points to /etc/alternatives/ssh-askpass which point
to the actual ssh-askpass software.

Bye
Cesar Mendoza
http://www.kitiara.org
--
All truth passes through three stages: first it is ridiculed,
then violently opposed and eventually, accepted as self-evident.
 -- Schopenhauer



On Mon, Aug 29, 2005 at 07:53:02PM -0400, Barry Hawkins wrote:
 Package: keychain
 Version: 2.5.5-3
 Severity: normal
 
 Thanks for packaging this most handy utility.  After upgrading to
 keychain 2.5.5-3, the following behavior was encountered when launching
 a login shell for the first time:
 
 *** Begin sample output ***
 KeyChain 2.5.5; http://www.gentoo.org/proj/en/keychain/
 Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL
 
  * Found existing ssh-agent (7473)
  * Found existing gpg-agent (7452)
  * Adding 2 ssh key(s)...
 ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
 ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
  * Error: Problem adding; giving up
 *** End sample output ***
 
 This behavior is repeatable and was tested several times.  Keychain is
 being invoked on the affected system via the user's .bash_profile as
 shown in the sample script block for bash and zsh in keychain(1):
 
 *** Begin .bash_profile excerpt ***
 # Keychain usage
 keychain id_rsa id_dsa 80B2D10A
 [[ -f $HOME/.keychain/$HOSTNAME-sh ]]  \
 source $HOME/.keychain/$HOSTNAME-sh
 [[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ]]  \
 source  $HOME/.keychain/$HOSTNAME-sh-gpg
 *** End .bash_profile excerpt ***
 
 In case it matters, SSH_ASKPASS is not being set in the .bash_profile
 script in question.  Manually calling ssh-add results in an appropriate
 password prompt and the reuse of known ssh keys.  If I can provide any
 further information or testing, please let me know.
 
 This seems like it may be related to the fix for the issue that was
 addressed in Bug #324950, though I have not played with the source
 package to test that theory.  Once keychain has the ssh keys, an issue
 with adding the GPG key is encountered, which I will report separately.
 
 Regards,
 --
 Barry Hawkins
 site: www.bytemason.org
 weblog: www.yepthatsme.com
 
 Registered Linux User #368650
 



pgpuei8GpA9rQ.pgp
Description: PGP signature


Bug#324950: keychain: only works when run from a terminal

2005-08-25 Thread Cesar Mendoza
Hi,

Thanks for your contributions to Debian. I created a new version with
your patch. Can you please test it?

You can download it at:
http://www.kitiara.net/~mendoza/keychain_2.5.5-3_all.deb

Thanks.

Bye
Cesar Mendoza
http://www.kitiara.org
--
Sólo la infancia es la época adecuada 
para sembrar la semilla de la fe.. 
  --Schopenhauer


On Thu, Aug 25, 2005 at 09:46:05AM +0800, Paul Wise wrote:
 Package: keychain
 Version: 2.5.5-2
 Severity: normal
 Tags: patch
 
 I have a button on my GNOME panel that simply runs keychain id_rsa,
 normally this runs ssh-add, which brings up a dialog to ask for my
 password. Since the recent upgrade, I see the following error in
 my .xsession-errors when I run keychain from my GNOME panel.
 
 KeyChain 2.5.5; http://www.gentoo.org/proj/en/keychain/
 Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL
 
  * Inheriting ssh-agent (6314)
  * Initializing /home/pabs/.keychain/chianamo-sh file...
  * Initializing /home/pabs/.keychain/chianamo-csh file...
  * Inheriting gpg-agent (6297)
  * Initializing /home/pabs/.keychain/chianamo-sh-gpg file...
  * Initializing /home/pabs/.keychain/chianamo-csh-gpg file...
  * Adding 1 ssh key(s)...
 Enter passphrase for /home/pabs/.ssh/id_rsa:  * Error: Problem adding; giving 
 up
 
 The strange thing is that just running ssh-add from the panel works
 fine, it brings up a dialog for my password just fine. Also running
 keychain id_rsa and just ssh-add from a terminal works fine too. The
 SSH_ASKPASS variable is not set. Looking at the code, it seems that the
 $noguiopt section is being entered in the following code:
 
 if $noguiopt || [ -z $SSH_ASKPASS -o -z $DISPLAY ]; then
 unset DISPLAY   # DISPLAY= can cause problems
 unset SSH_ASKPASS   # make sure ssh-add doesn't try SSH_ASKPASS
 sshout=`ssh-add ${ssh_timeout} $@`
 else
 sshout=`ssh-add ${ssh_timeout} $@ /dev/null`
 fi
 
 The solution on my system is to remove '-z $SSH_ASKPASS -o ' since on
 debian it is possible to use the alternatives system to set which
 SSH_ASKPASS program to use (this is what I use). I'm not sure if you
 want to use this for the general case, but it seems fine to me. I've
 attached a patch which fixes this more fully for multiple keys - DISPLAY
 is not reset after each key, resulting in the nogui option being used
 for the second and subsequent keys.
 
 -- System Information:
 Debian Release: unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.12-1-k7
 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
 
 Versions of packages keychain depends on:
 ii  debconf  1.4.57  Debian configuration management 
 sy
 ii  grep 2.5.1.ds1-5 GNU grep, egrep and fgrep
 ii  openssh-client [ssh-client]  1:4.1p1-6   Secure shell client, an 
 rlogin/rsh
 
 keychain recommends no packages.
 
 -- debconf information:
 * keychain/upgrade:
 
 -- 
 bye,
 pabs
 
 http://qa.debian.org/developer.php?login=Paul+Wisecomaint=yes

 diff -u keychain-2.5.5/debian/changelog keychain-2.5.5/debian/changelog
 --- keychain-2.5.5/debian/changelog
 +++ keychain-2.5.5/debian/changelog
 @@ -1,3 +1,9 @@
 +keychain (2.5.5-3) unstable; urgency=low
 +
 +  * Fix bugs in handling of DISPLAY and SSH_ASKPASS. Closes: #
 +
 + -- Cesar Mendoza [EMAIL PROTECTED]  Thu, 25 Aug 2005 09:39:52 +0800
 +
  keychain (2.5.5-2) unstable; urgency=low
  
* Now depends on openssh-client | ssh-client. Closes: #281106
 only in patch2:
 unchanged:
 --- keychain-2.5.5.orig/keychain
 +++ keychain-2.5.5/keychain
 @@ -1438,7 +1438,7 @@
  IFS=$old_IFS # restore IFS
  set +f # re-enable globbing
  
 -if $noguiopt || [ -z $SSH_ASKPASS -o -z $DISPLAY ]; then
 +if $noguiopt || [ -z $DISPLAY ]; then
  unset DISPLAY   # DISPLAY= can cause problems
  unset SSH_ASKPASS   # make sure ssh-add doesn't try SSH_ASKPASS
  sshout=`ssh-add ${ssh_timeout} $@`
 @@ -1460,9 +1460,10 @@
  
  # Decrement the countdown
  sshattempts=`expr $sshattempts - 1`
 -done
  
 -[ -n $savedisplay ]  DISPLAY=$savedisplay
 +# Reset DISPLAY
 +[ -n $savedisplay ]  DISPLAY=$savedisplay
 +done
  fi
  
  # Load gpg keys





pgpRkrt0JASjR.pgp
Description: PGP signature


Bug#281106: Package maintainer didn't care to read the bug report (Bug#281106: fixed in keychain 2.5.5-1)

2005-08-23 Thread Cesar Mendoza
Hi,

Sorry, I read the report wrong. I will reopen the bug and fix it.

Bye
Cesar Mendoza
http://www.kitiara.org
--
All truth passes through three stages: first it is ridiculed,
then violently opposed and eventually, accepted as self-evident.
 -- Schopenhauer

On Tue, Aug 23, 2005 at 08:06:19PM +0200, Matthias Klose wrote:
 reopen 281106
 thanks
 
 Debian Bug Tracking System writes:
  From: Cesar Mendoza [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
 
   keychain (2.5.5-1) unstable; urgency=low
   .
 * New upstream version. Closes: #305281
 * Now depends on ssh. Closes: #281106
 
 Did you even _read_ the bug report? Dude, you need nine months to come
 up with a null solution ... that's quality!
 



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



Bug#314534: lists-archives: Invoking pipes from /etc/aliases file is widely considered obsolete and deprecated.

2005-06-20 Thread Cesar Mendoza
Hi,

I use exim4 with mailman. Mailman requires pipes in the /etc/aliases to
work properly. One of the things that you can set on the exim
configuration file is what user and group to run the piped programs.

Here is what I use on my exim4 configuration file:

system_aliases:
debug_print = R: system_aliases for [EMAIL PROTECTED]
driver = redirect
domains = +local_domains
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
user = list
group = mail
file_transport = address_file
pipe_transport = address_pipe


Notice the lines user = list group= mail that is where I set the
user and group to run the piped programs.

Please let me kno if this helped you with your problem.

Bye
Cesar Mendoza
http://www.kitiara.org
--
All truth passes through three stages: first it is ridiculed,
then violently opposed and eventually, accepted as self-evident.
 -- Schopenhauer


On Fri, Jun 17, 2005 at 12:34:59AM +0200, Thomas Clavier wrote:
 Package: lists-archives
 Version: 200300506-1.1
 Severity: grave
 Justification: renders package unusable
 
 I use lists-archives width exim4 and in exim4 using pipes in the
 /etc/aliases file is disabled. Readme and other docs don't explain how to
 make a dedicated router/transport pair. 
 If i manualy activate pipe in /etc/alias ... all piped action are made whith
 the user : Debian-exim :-( and they don't have privilege to write in
 /var/lib/lists-archives ! Width this, i find all mail to lists-archives
 in /var/spool/mail/Debian-exim :-((
 
 -- System Information:
 Debian Release: 3.1
   APT prefers sarge
   APT policy: (900, 'stable'), (600, 'testing'), (300, 'unstable')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.8-2-k7
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
 
 Versions of packages lists-archives depends on:
 ii  mhonarc   2.6.10-1   Mail to HTML converter
 ii  perl [perl5]  5.8.4-8Larry Wall's Practical 
 Extraction 
 ii  procmail  3.22-11Versatile e-mail processor
 
 -- no debconf information
 



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



Bug#296382: keychain: confirm each use of added key (ssh-add -c)

2005-02-22 Thread Cesar Mendoza
Hi,

Thanks for your contribution to Debian. I will forward your request to
upstream to see if it gets incorporated to the next version.

Bye
Cesar Mendoza
http://www.kitiara.org
--
Thank you for the latest release of gradewrecker. 
My GPA just went in the corner and shot itself.
 -- USENET posting refering to 
the latest release of NetHack, author unknown 

On Tue, Feb 22, 2005 at 04:56:39AM +, Liyang HU wrote:
 Package: keychain
 Version: 2.5.1-1
 Severity: wishlist
 Tags: patch
 
 Hi,
 
 I usually invoke ssh-add with the -c flag so that I have to confirm each
 use of the key.
 



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