Bug#376868: dpkg-dev: dpkg-source exits with error 13
Hi, some months ago, on Tue, Aug 22, 2006 at 03:54:13PM -0400, Jamin W. Collins wrote: I tested a few more versions of the libnss-ldap package: 238-1.1 - worked 238-1.2 - worked 251-1 - broken So, it seems the problem was introduced between 238-1.2 and 251-1. I did some tests today. The problem was still here (and systematic when TLS is enabled) with 251-5.1 and seems to be resolved with 251-5.2. Can you confirm? Cheers, -- Prof -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376868: dpkg-dev: dpkg-source exits with error 13
On Mon, Aug 21, 2006 at 03:12:56PM -0400, Jamin W. Collins wrote:
I also appear to be bitten by this one. My user accounts are also stored
in LDAP.
Does anybody know why we use LOGNAME (in /usr/lib/dpkg/controllib.pl)?
I could find this in the ChangeLog:
dpkg (1.4.0.9) unstable; urgency=low
[...]
* Changed controllib.pl to use $ENV{LOGNAME}, getlogin(), and $
(in that order) to determine the intended ownership of
debian/{files,substvars}, (fixes #7324, #6823, #5659, #5965, #5929,
#9239, #5366).
[...]
-- Klee Dienes [EMAIL PROTECTED] Mon, 17 Mar 1997 16:11:24 -0500
(And I can't find these bug reports; BTW does anybody have an archive of them)
If we could remove the usage of LOGNAME (and getlogin), and only keep $ and
$(, I think it would be fine (in that case, there is no need to call getpwnam).
A patch is attached, but it assumes these bugs do not apply anymore ;(
Kind Regards,
--
Nekral
Index: scripts/controllib.pl
===
--- scripts/controllib.pl (révision 510)
+++ scripts/controllib.pl (copie de travail)
@@ -35,43 +35,8 @@
$progname= $0; $progname= $ if $progname =~ m,[^/]+$,;
-$getlogin = getlogin();
-if(!defined($getlogin)) {
- open(SAVEIN, STDIN);
- close(STDIN);
- open(STDIN, STDERR);
[EMAIL PROTECTED] = ( $, $( );
- $getlogin = getlogin();
-
- close(STDIN);
- open(STDIN, SAVEIN);
- close(SAVEIN);
-}
-if(!defined($getlogin)) {
- open(SAVEIN, STDIN);
- close(STDIN);
- open(STDIN, STDOUT);
-
- $getlogin = getlogin();
-
- close(STDIN);
- open(STDIN, SAVEIN);
- close(SAVEIN);
-}
-
-if (defined ($ENV{'LOGNAME'})) {
-@fowner = getpwnam ($ENV{'LOGNAME'});
-if (! @fowner) { die (sprintf (_g('unable to get login information for
username %s'), $ENV{'LOGNAME'})); }
-} elsif (defined ($getlogin)) {
-@fowner = getpwnam ($getlogin);
-if (! @fowner) { die (sprintf (_g('unable to get login information for
username %s'), $getlogin)); }
-} else {
-warn (sprintf (_g('no utmp entry available and LOGNAME not defined; using
uid of process (%d)'), $));
-@fowner = getpwuid ($);
-if (! @fowner) { die (sprintf (_g('unable to get login information for uid
%d'), $)); }
-}
[EMAIL PROTECTED] = @fowner[2,3];
-
sub capit {
my @pieces = map { ucfirst(lc) } split /-/, $_[0];
return join '-', @pieces;
Bug#376868: dpkg-dev: dpkg-source exits with error 13
On Mon, Aug 21, 2006 at 11:23:39PM -0400, Jamin W. Collins wrote: It might also be worth noting that this same configuration was not a problem under sarge. The problem did not occur until I upgraded my system from sarge to etch on Sunday. Then the boot process broke due to the libnss-ldap changes (ldap then compat no longer worked in /etc/nsswitch.conf, but that's a different bug report). Once /etc/nsswitch.conf was changed to files then ldap the boot process at least continued. Then I found this problem. It seems that some change with libnss-ldap between sarge and etch is wreaking havoc on configurations that have thus far been working fine. I know of breakage within at least three different locations related to the changes (boot, dbus/hal, and now this). My opinion is that there is a SIGPIPE which is not catched at one of these levels: libnss-ldap, libc, or perl. This could be related to the bug 190072 (libnss-ldap: Processes may receive SIGPIPE from LDAP session timeouts), but this bug was present in Sarge. Also, it could be interresting to test with the previous versions of libnss-ldap to see when the problem appeared, or with the patch attached to 190072. I have no LDAP box, so I can't test. I would appreciate if you could. You can test with the single perl command sent in the previous messages to this bug. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376868: dpkg-dev: dpkg-source exits with error 13
Nicolas François wrote:
My opinion is that there is a SIGPIPE which is not catched at one of these
levels: libnss-ldap, libc, or perl.
This could be related to the bug 190072 (libnss-ldap: Processes may
receive SIGPIPE from LDAP session timeouts), but this bug was present in
Sarge.
Also, it could be interresting to test with the previous versions of
libnss-ldap to see when the problem appeared, or with the patch attached
to 190072.
I have no LDAP box, so I can't test. I would appreciate if you could.
You can test with the single perl command sent in the previous messages to
this bug.
I've done some further testing. As with the other reports many dpkg
related items fail, but this appears to be due to libnss-ldap:
[EMAIL PROTECTED]:~$ dpkg-architecture
DEB_BUILD_ARCH=
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=
DEB_BUILD_GNU_CPU=
DEB_BUILD_GNU_SYSTEM=
DEB_BUILD_GNU_TYPE=
DEB_HOST_ARCH=
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=
DEB_HOST_GNU_CPU=
DEB_HOST_GNU_SYSTEM=
DEB_HOST_GNU_TYPE=
[EMAIL PROTECTED]:~$ dpkg --print-architecture
i386
[EMAIL PROTECTED]:~$ ${CC:-gcc} -dumpmachine
i486-linux-gnu
[EMAIL PROTECTED]:~/tmp/src/vino-2.13.5$ perl -e '@foo=getpwnam
($ENV{'LOGNAME'});
open(STDIN, debian/changelog) || die error1;
open(P,tail -n 40 |) || die error2;
print status1: $?\n;
close(P); print status2: $?\n'
status1: 0
status2: 13
By simply downgrading libnss-ldap to 238-1 (sarge's version) they once
again work fine as a normal user:
[EMAIL PROTECTED]:~$ dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i486-linux-gnu
I tested a few more versions of the libnss-ldap package:
238-1.1 - worked
238-1.2 - worked
251-1 - broken
So, it seems the problem was introduced between 238-1.2 and 251-1.
--
Jamin W. Collins
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376868: dpkg-dev: dpkg-source exits with error 13
Package: dpkg-dev Version: 1.13.21 Followup-For: Bug #376868 I also appear to be bitten by this one. My user accounts are also stored in LDAP. :~/tmp/src$ sudo /etc/init.d/nscd status Status of Name Service Cache Daemon service: running. :~/tmp/src$ sudo /etc/init.d/nscd restart Restarting Name Service Cache Daemon: nscd. :~/tmp/src$ dpkg-source -x vin*dsc dpkg-source: failure: md5sum vino_2.13.5.orig.tar.gz died from signal 13 :~/tmp/src$ sudo dpkg-source -x vin*dsc gpg: fatal: can't create directory `/home/jcollins/.gnupg': File exists secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 dpkg-source: extracting vino in vino-2.13.5 dpkg-source: unpacking vino_2.13.5.orig.tar.gz dpkg-source: applying ./vino_2.13.5-3.diff.gz -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (400, 'stable'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-ar-k7-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages dpkg-dev depends on: ii binutils 2.17-2 The GNU assembler, linker and bina ii cpio 2.6-17 GNU cpio -- a program to manage ar ii dpkg 1.13.21package maintenance system for Deb ii make 3.81-2 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-6.1 Larry Wall's Practical Extraction ii perl-modules 5.8.8-6.1 Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-3high-quality block-sorting file co ii gcc [c-compiler] 4:4.1.1-5 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-13 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-1The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-5The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376868: dpkg-dev: dpkg-source exits with error 13
Nicolas François wrote:
On Mon, Aug 21, 2006 at 03:12:56PM -0400, Jamin W. Collins wrote:
I also appear to be bitten by this one. My user accounts are also stored
in LDAP.
Does anybody know why we use LOGNAME (in /usr/lib/dpkg/controllib.pl)?
I could find this in the ChangeLog:
dpkg (1.4.0.9) unstable; urgency=low
[...]
* Changed controllib.pl to use $ENV{LOGNAME}, getlogin(), and $
(in that order) to determine the intended ownership of
debian/{files,substvars}, (fixes #7324, #6823, #5659, #5965, #5929,
#9239, #5366).
[...]
-- Klee Dienes [EMAIL PROTECTED] Mon, 17 Mar 1997 16:11:24 -0500
(And I can't find these bug reports; BTW does anybody have an archive of them)
If we could remove the usage of LOGNAME (and getlogin), and only keep $ and
$(, I think it would be fine (in that case, there is no need to call getpwnam).
A patch is attached, but it assumes these bugs do not apply anymore ;(
It might also be worth noting that this same configuration was not a
problem under sarge. The problem did not occur until I upgraded my
system from sarge to etch on Sunday. Then the boot process broke due to
the libnss-ldap changes (ldap then compat no longer worked in
/etc/nsswitch.conf, but that's a different bug report). Once
/etc/nsswitch.conf was changed to files then ldap the boot process at
least continued. Then I found this problem.
It seems that some change with libnss-ldap between sarge and etch is
wreaking havoc on configurations that have thus far been working fine.
I know of breakage within at least three different locations related to
the changes (boot, dbus/hal, and now this).
--
Jamin W. Collins
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
