Bug#520939: Updated patch

2009-03-26 Thread Eric Anderson
Jordi Mallach writes:
  On Wed, Mar 25, 2009 at 11:58:48AM -0700, Eric Anderson wrote:
  Content-Description: message body text
   The previous patch incorrectly claimed that the first rule applied, it
   is actually the last rule, it just didn't look like it in the code.
   The attached patch fixes that, and adds debugging of upstream proxy
   determination.  It is cumulative with the previous patch.
  -Eric
  
  A single patch is a lot better than two cummulative patches.

Attached.

  Have you tried contacting upstream about these fixes?

No, my understanding was that the Debian maintainer did that.  If
that's wrong, I can contact upstream.
-Eric



cumulative.patch
Description: Binary data


Bug#520939: Updated patch

2009-03-25 Thread Eric Anderson
The previous patch incorrectly claimed that the first rule applied, it
is actually the last rule, it just didn't look like it in the code.
The attached patch fixes that, and adds debugging of upstream proxy
determination.  It is cumulative with the previous patch.
-Eric


patch.v2
Description: Binary data


Bug#520939: tinyproxy: Incorrect handling of IP mask rules

2009-03-23 Thread Eric Anderson
Subject: tinyproxy: Incorrect handling of IP mask rules
Package: tinyproxy
Version: 1.6.3-4
Severity: important
Tags: patch

*** Please type your report below this line ***

The 1.6.3-3.2 version of tinyproxy does not properly handle IP mask
rules:
  1) They are ignored for upstream rules entirely
  2) The hostname is not translated to an IP address before matching.

Therefore, a rule like: 
  upstream test-proxy:8088 127.0.0.0/8

will never take effect.

Also, the documentation says the last rule applies, while in the code,
the first rule applies.  The attached patch fixes all of these issues.
The installed version (1.6.3-4) is the version with the patch applied.
-Eric

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

Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tinyproxy depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  logrotate 3.7.1-5Log rotation utility

tinyproxy recommends no packages.

tinyproxy suggests no packages.

-- no debconf information


bugfix.patch
Description: Binary data


Bug#496820: grub-pc in current installer snapshot fails with separate boot partition

2008-08-29 Thread Eric Anderson
Felix Zielcke writes:
  Am Mittwoch, den 27.08.2008, 11:45 -0700 schrieb Eric Anderson:
   grub-pc fails to install as it is unable to read the file 
   /boot/grub/core.img
   when used with a separate /boot partition a machine with a  2TB disk.
  
  I just tried it out now myself in VMware with a default disk size of 8
  GiB.
  
  This seems to be related or maybe it is even the same as 489287

I suspect it's somehow different because the underlying grub-setup
message was succeeded in opening the core image but the data is
different in that one, and in mine, it was just that it couldn't even
find the file.  (I stuck a large number of debugging outputs into
grub-setup to track down the problem).

  I have used the current daily debian-testing-amd64-businesscard.iso
  from 29-Aug-2008 00:04
  and installed `testing' with a seperate /boot partition at the end of
  the disk.
  
  A `msdos' partition table is no problem at all with a seperate /boot.
  But `gpt', which has to be used for  2 TB, is the problem.

Interesting, I couldn't test this because it was on a real disk, so
gpt was the only option.  I wonder if it's some sort of what path
should I be looking for error with gpt partitions and not msdos ones?
-Eric




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



Bug#496820: grub-pc in current installer snapshot fails with separate boot partition

2008-08-27 Thread Eric Anderson
Package: grub-pc
Version: 1.96+20080724-8
Severity: important


grub-pc fails to install as it is unable to read the file /boot/grub/core.img
when used with a separate /boot partition a machine with a  2TB disk.

The problem appears to be that grub-setup is looking for the file 
/boot/grub/core.img, but since the filesystem is already /boot, it is unable 
to find it.

A workaround is to run ln -s . /target/boot/boot after the installer fails, 
or ln -s . /boot/boot in the chroot environment the grub-install script
runs in, but this is almost assuredly the wrong solution so I'm not 
making a patch to do this.

The install fails with either lvm or normal partitions, the machine as 
configured 
right now has lvm on it since that's what we wanted, but we tried both.
The underlying disk happens to be 4x750GB in hardware R5 mode, so the 
disk size seen by the os is ~2.1TB.

The test used the current lenny testing installer snapshot (2008-08-25 jigdo, 
67b34eb6c7c30b330df9d19d1686c03105ea3746  debian-testing-amd64-CD-1.iso)
The installer is properly choosing grub-pc for use on the large disk.

We have a spare machine with the same hardware configuration, so can
try an updated version of the packages to make sure they work.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/martenot-root / ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/cciss/c0d0p1 /boot ext3 rw,noatime,errors=continue,data=ordered 0 0
/dev/mapper/martenot-home /home xfs rw,noatime,attr2,nobarrier,noquota 0 0
/dev/mapper/martenot-tmp /tmp xfs rw,noatime,attr2,nobarrier,noquota 0 0
/dev/mapper/martenot-var /var xfs rw,noatime,attr2,nobarrier,noquota 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/cciss/c0d0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
insmod lvm
set root=(martenot-root)
search --fs-uuid --set 02f4ef63-c6b1-4507-b872-ee95730d004d
if font /usr/share/grub/ascii.pff ; then
  set gfxmode=640x480
  insmod gfxterm
  insmod vbe
  terminal gfxterm
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###

### BEGIN /etc/grub.d/10_linux ###
set root=(hd0,1)
search --fs-uuid --set 928fe409-4d19-48cf-b78a-de1b8146d891
menuentry Debian GNU/Linux, linux 2.6.25-2-amd64 {
linux   /vmlinuz-2.6.25-2-amd64 root=/dev/mapper/martenot-root ro  
initrd  /initrd.img-2.6.25-2-amd64
}
menuentry Debian GNU/Linux, linux 2.6.25-2-amd64 (single-user mode) {
linux   /vmlinuz-2.6.25-2-amd64 root=/dev/mapper/martenot-root ro 
single 
initrd  /initrd.img-2.6.25-2-amd64
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]1.5.22  Debian configuration management sy
ii  grub-common  1.96+20080724-8 GRand Unified Bootloader, version 
ii  libc62.7-13  GNU C Library: Shared libraries
ii  liblzo2-22.03-1  data compression library
ii  libncurses5  5.6+20080804-1  shared libraries for terminal hand

grub-pc recommends no packages.

Versions of packages grub-pc suggests:
pn  desktop-base  none (no description available)
pn  os-prober none (no description available)

-- debconf information:
  grub-pc/linux_cmdline: fillme
  grub-pc/chainload_from_menu.lst: true



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



Bug#323163: libvalidate-net-perl: Package dependency missing

2005-08-15 Thread Eric Anderson
Package: libvalidate-net-perl
Version: 0.5-1
Severity: grave
Justification: renders package unusable


The libvalidate-net-perl depends on the libclass-default-perl package
because of the line:

use base 'Class::Default';

in ../Validate/Net.pm

Without libclass-default-perl the module doesn't work, it reports:

Base class package Class::Default is empty.
(Perhaps you need to 'use' the module which defines that package first.)
 at /usr/share/perl5/Validate/Net.pm line 10
BEGIN failed--compilation aborted at /usr/share/perl5/Validate/Net.pm line 10.
...

I didn't bother to put in a patch because it would be more work to use
my patch than to extend the depends line in the control file.

-- System Information: Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libvalidate-net-perl depends on:
ii  perl  5.8.7-3Larry Wall's Practical Extraction 

-- no debconf information


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



Bug#306679: libexpect-perl: $expect-send_slow() goes into an infinite loop if the sub-process exits

2005-04-27 Thread Eric Anderson
Package: libexpect-perl
Version: 1.15-3
Severity: normal
Tags: patch


If you call $expect-send_slow() when the sub-process has exited, or
is exiting, it will go into an infinite loop printing out the last
output recieved.  The patch below fixes this problem.  Will you
forward it on to upstream, or should I do that?
-Eric

diff -c -r libexpect-perl-1.15-orig/Expect.pm libexpect-perl-1.15/Expect.pm
*** libexpect-perl-1.15-orig/Expect.pm  Wed Apr 27 09:13:08 2005
--- libexpect-perl-1.15/Expect.pm   Wed Apr 27 09:14:45 2005
***
*** 1256,1262 
# .01 sec granularity should work. If we miss something it will
# probably get flushed later, maybe in an expect call.
while (select($rmask,undef,undef,.01)) {
! sysread($self,${*$self}{exp_Pty_Buffer},1024);
  # Is this necessary to keep? Probably.. #
  # if you need to expect it later.
  ${*$self}{exp_Accum}.= ${*$self}{exp_Pty_Buffer};
--- 1256,1263 
# .01 sec granularity should work. If we miss something it will
# probably get flushed later, maybe in an expect call.
while (select($rmask,undef,undef,.01)) {
! my $amt = sysread($self,${*$self}{exp_Pty_Buffer},1024);
! last unless defined $amt  $amt  0; # subprocess went away
  # Is this necessary to keep? Probably.. #
  # if you need to expect it later.
  ${*$self}{exp_Accum}.= ${*$self}{exp_Pty_Buffer};

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (992, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.28
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libexpect-perl depends on:
ii  libio-pty-perl1:1.02-2   Perl module for pseudo tty IO
ii  libio-stty-perl   0.02-7 Interface to secure pseudo ttys
ii  perl  5.8.4-8Larry Wall's Practical Extraction 

-- no debconf information
diff -c -r libexpect-perl-1.15-orig/Expect.pm libexpect-perl-1.15/Expect.pm
*** libexpect-perl-1.15-orig/Expect.pm  Wed Apr 27 09:13:08 2005
--- libexpect-perl-1.15/Expect.pm   Wed Apr 27 09:14:45 2005
***
*** 1256,1262 
# .01 sec granularity should work. If we miss something it will
# probably get flushed later, maybe in an expect call.
while (select($rmask,undef,undef,.01)) {
! sysread($self,${*$self}{exp_Pty_Buffer},1024);
  # Is this necessary to keep? Probably.. #
  # if you need to expect it later.
  ${*$self}{exp_Accum}.= ${*$self}{exp_Pty_Buffer};
--- 1256,1263 
# .01 sec granularity should work. If we miss something it will
# probably get flushed later, maybe in an expect call.
while (select($rmask,undef,undef,.01)) {
! my $amt = sysread($self,${*$self}{exp_Pty_Buffer},1024);
! last unless defined $amt  $amt  0; # subprocess went away
  # Is this necessary to keep? Probably.. #
  # if you need to expect it later.
  ${*$self}{exp_Accum}.= ${*$self}{exp_Pty_Buffer};