Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

2016-03-01 Thread Jort Koopmans
Hi Bob,

Great comment and recommendation. I was using SB04 and experienced the 90
second boot delay. Workaround was functioning as described before, however
udev rules might easily get overwritten so it's not an ideal solution.

I have a dual boot OS.
What I did:
Booted to windows and downloaded the SB07 firmware (auto-flashed from
executable).
Rebooted to linux (I'm running mint):

   - Reinstated the original line from
   /lib/udev/rules.d/60-persistent-storage.rules
   - update-initramfs -u
   - Reboot again and check boot time + dmesg.

It seems to have worked for me, I tried some other reboots to see whether I
could get it to break again without 'success'.

So it might be worth the one time effort for people to plug the drive to a
windows box and flash it, or boot to win OS.

Download link I used (official tsstodd):
http://www.tsstodd.com/TotalLib/popup/Download.asp?path=fwdownload=eng=SH-S223C_SB07.exe

Note that you should also be able to use MacOS with the separate TSDNMAC
firmware flash program and extracting the .bin from the windows download
above (it's just an archive).

Kind regards,

Jort


Bug#751137: postfix-policyd-spf-python: Empty regex line breaks logcheck filter

2014-06-10 Thread Jort Koopmans
Package: postfix-policyd-spf-python
Version: 1.0-2
Severity: normal

Dear Scott Kitterman,

Thanks for maintaining this package, I really like it and implemented it 
successfully.
However, I think I've found a minor glitch in the logcheck default filtering 
rule: The empty regex line (line2) is making the logcheck rule unusable (it is 
discarded by logcheck by default)

This concerns the file located at 
/etc/logcheck/ignore.d.server/postfix-policyd-spf-python.logcheck
or from the src: 
http://anonscm.debian.org/viewvc/python-apps/packages/pypolicyd-spf/trunk/debian/postfix-policyd-spf-python.logcheck?revision=8841view=markup

An empty line technically matches all the content from all the logfiles and 
would therefore break the logcheck entirely (not sending anything), therefore 
logcheck discards the configuration file you've carefully crafted.

Removing the empty line worked for me.

Kind regards,
Jort Koopmans


-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
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 postfix-policyd-spf-python depends on:
ii  adduser 3.113+nmu3
ii  postfix 2.9.6-2
ii  python  2.7.3-4+deb7u1
ii  python-spf  2.0.7-3
ii  python2.6   2.6.8-1.1
ii  python2.7   2.7.3-6+deb7u2

postfix-policyd-spf-python recommends no packages.

Versions of packages postfix-policyd-spf-python suggests:
ii  python-authres  0.402-1

-- Configuration Files:
/etc/logcheck/ignore.d.server/postfix-policyd-spf-python.logcheck changed:
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ policyd-spf\[[0-9]+\]: 
(Pass|Neutral|None|Softfail|Fail|Temperror|Permerror); 
identity=(helo|mailfrom); client-ip=[0-9a-f.:]+; helo=.*; envelope-from=.*; 
receiver=


-- 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#751137: Dot in logcheck-filter filename breaks filtering

2014-06-10 Thread Jort Koopmans

retitle 751137 Dot in logcheck-filter filename breaks filtering

Hi,

I stand corrected, due to my attempt in triaging this bug (using egrep 
instead of 'sudo -u logcheck logcheck -o -t' and using modified filter 
names), I failed to see the empty line is NOT the problem.


It seems the . (dot) in the filename of the filter breaks the setup. 
Moving the file from:

postfix-policyd-spf-python.logcheck
to:
postfix-policyd-spf-python-logcheck
fixes the problem.

My version of logcheck 1.3.15 (stable/wheezy)

Kind regards,
Jort Koopmans


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



Bug#710828: evolution: When gnome is running from remote client x2go, vnc etc, after upgrade to wheezy evolution not start

2014-04-29 Thread Jort Koopmans
Hi,

After upgrading to wheezy recently, and moving from NoMachine to X2Go, same
thing happened to me.
I don't think looking into VirtualGL when it only provides a partly
solution is making a lot of sense, who would accept an email client that
cannot compose a message?

If I can test anything, let me know, I really liked remote NX with Gnome in
the past.

Kind regards,
Jort


Bug#705959: Intel i210/i217 driver backport

2014-04-14 Thread Jort Koopmans
Hi,

The Intel i210 is becoming very common nowadays, with the 7.5 point
release coming up (26th of April), is this going to be included?

Kind regards,
Jort


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



Bug#658112: libvirt-bin: Virsh migrate fails with 'Migration unexpectedly failed'

2012-02-01 Thread Jort Koopmans
Ok, on box1 there are also problems creating new VM's

When doing:
virt-install --connect qemu:///system --virt-type kvm -n testVM -r 512
--disk path=/dev/vgbase/vmweb1 --vnc
--cdrom /media/installisos/debian-6.0.3-amd64-netinst.iso --os-variant
debiansqueeze --network=bridge=br0 --network=bridge=br1

The following error is displayed:
OnStarting install...
ERRORinternal error Timed out while reading console log output: 
Domain installation does not appear to have been
 successful.  If it was, you can restart your domain
 by running 'virsh start testVM'; otherwise, please
 restart your installation.
ERRORinternal error Timed out while reading console log output: 
Traceback (most recent call last):
  File /usr/bin/virt-install, line 1033, in module
main()
  File /usr/bin/virt-install, line 915, in main
start_time, guest.start_install)
  File /usr/bin/virt-install, line 957, in do_install
dom = install_func(conscb, progresscb, wait=(not wait))
  File /usr/lib/pymodules/python2.6/virtinst/Guest.py, line 973, in
start_install
return self._do_install(consolecb, meter, removeOld, wait)
  File /usr/lib/pymodules/python2.6/virtinst/Guest.py, line 1038, in
_do_install
install)
  File /usr/lib/pymodules/python2.6/virtinst/Guest.py, line 1009, in
_create_guest
dom = self.conn.createLinux(start_xml, 0)
  File /usr/lib/python2.6/dist-packages/libvirt.py, line 1277, in
createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: internal error Timed out while reading console log
output: 

I think it probably is related...nothing gets logged
in /var/log/libvirt/qemu/testVM.log (log_level = 1)
Any suggestions are appreciated :)

Best regards,
Jort Koopmans




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



Bug#658112: libvirt-bin: Virsh migrate fails with 'Migration unexpectedly failed'

2012-02-01 Thread Jort Koopmans
Hi Guido,

On Wed, 2012-02-01 at 18:31 +0100, Guido Günther wrote:
 On Wed, Feb 01, 2012 at 04:54:03PM +0100, Jort Koopmans wrote:
  Ok, on box1 there are also problems creating new VM's
  
  When doing:
  virt-install --connect qemu:///system --virt-type kvm -n testVM -r 512
  --disk path=/dev/vgbase/vmweb1 --vnc
  --cdrom /media/installisos/debian-6.0.3-amd64-netinst.iso --os-variant
  debiansqueeze --network=bridge=br0 --network=bridge=br1
 

I must correct this, it is possible to create vm's. Cause of this
failure was a flooded /var/log/ partition (libvirt_debug creates lots of
lines 3GB)


 Try getting KVM to run without libvirt. You can start by using a working
 configuration line from the other server. I'm tempted to close this
 issue since it very much looks like a configuration problem.

I hope the above correction changes your vision on the cause of this
problem. Virsh seems to be working well, except for migration. Running
kvm without libvirt is not something I have experience with and this is
a production server unfortunately, so this would be a last resort.
Is there any other log/data that I need to provide to get a grip on this
problem? If you think it might be a configuration problem (of
kvm-qemu?), where would I need to look? I can compare parameters to the
other box.

Best regards,
Jort Koopmans





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



Bug#658112: [Pkg-libvirt-maintainers] Bug#658112: libvirt-bin: Virsh migrate fails with 'Migration unexpectedly failed'

2012-01-31 Thread Jort Koopmans
On Tue, 2012-01-31 at 14:34 +0100, Guido Günther wrote:
[..]
  I have tested migration both ways though, all fail.
 Did you check the VMs log in /var/log/libvirt ?
  -- Guido

Thanks for fast response, yes the /var/log/libvirt/qemu/vmname1.log from
hostOS2 (migration target) is attached (also posted in my first
message). HostOS doesnt seem to log anything there.

Best regards,
Jort Koopmans

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name vmname1 -uuid 0f891712-aae3-b78e-5dcf-90c688df4326 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/vmname1.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/dev/vgbase/vm1ir,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:b8:12:f4,bus=pci.0,addr=0x3 -net tap,fd=54,vlan=0,name=hostnet0 -device virtio-net-pci,vlan=1,id=net1,mac=52:54:00:f4:2f:20,bus=pci.0,addr=0x4 -net tap,fd=55,vlan=1,name=hostnet1 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k en-us -vga cirrus -incoming tcp:0.0.0.0:49152 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 
14:06:30.575: debug : qemudInitCpuAffinity:2423 : Setting CPU affinity
14:06:30.576: debug : qemuSecurityDACSetProcessLabel:547 : Dropping privileges of VM to 106:107
char device redirected to /dev/pts/2


Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-24 Thread Jort Koopmans
On Sun, 2011-10-23 at 14:05 +0300, Touko Korpela wrote:
[..]
 madduck called testing for experimental version of mdadm. where it can be
 downloaded?

My bad, I missed the initscripts package from sid (instead of testing).
I must note that none of the involved packages are available in
experimental (and mdadm and debianutils are equal in testing and
unstable atm).

Upgraded initscripts;
initscripts [2.88dsf-13.11 - 2.88dsf-13.12]

Reinstalled mdadm (from sid, but same version), generated a new initrd
just to be safe.
But again that didnt fix the problem.

---
@Touko, you get packages from the repositories. Add the following lines
to /etc/apt/sources.list

deb http://ftp.debian.org/debian/ sid main contrib
deb-src http://ftp.debian.org/debian/ sid main contrib

then run;
apt-get update
apt-get -t unstable install packagename

I'd also suggest you look into apt-pinning to keep the rest of your
system at stable (or w/e your running).
---

Best regards,
Jort Koopmans








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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-24 Thread Jort Koopmans
On Mon, 2011-10-24 at 14:03 +0300, Touko Korpela wrote:
[..]
 
 I know difference between sid and experimental. Is there more recent version
 of mdadm available than is in sid now? (experimental suite doesn't have it)

Not that I know of. As you mention, experimental does not contain a
newer version atm.





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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-23 Thread Jort Koopmans
Is there anything else I can do to triage this bug? I'd be happy to try
any suggestions to get this bug solved (in a future release).
Waiting for any response,

Jort Koopmans




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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-13 Thread Jort Koopmans
Hi Martin,


First of all, thanks for helping me out.

On Thu, 2011-10-13 at 11:10 +0200, martin f krafft wrote:
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143
+0200]:
  Common guys...can somebody look at my bugreport?
 
 We have. Let me offer some suggestions:
 
   - two days in FLOSS time is not a long time, please be more
 patient. Or get involved!

Sorry for that, I'm trying to get involved though.

 
   - please try to properly format your e-mails to make lines no
 longer than 68 characters.
 

I've noticed the longer than 68 chars in my first msg, but it was
formatted by reportbug (?).

   - if you are criticising initramfs/mdadm, then it helps to
 reproduce the output you are seeing, ideally after set -x.
 

True, since this machine does not have a serial port I haven't been able
to log the output yet (but i'll look into that).

   - we are not common guys. I think you meant come on ;)

Roger that ;) 

On Thu, 2011-10-13 at 11:06 +0200, martin f krafft wrote:
 also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143 +0200]:
  In the mean while I've checked another solution; moving the call
  to the local-top scripts till after the ROOTDELAY loop (within the
  local file).
 
 init-top/udev also uses it.
 

Ok, so calling them twice in the local script wouldn't hurt then.

  This works in my config. But this would delay finding the ROOT dir
  in normal instances (where devices are quick enough)
 
 So?
 
 Instead of patching this here and there with band aids, I suggest
 that everyone with an interest instead invests time in testing
 mdadm/experimental, which provides event-based assembly, and helps
 porting the changes to current mdadm (since I don't have the time at
 the moment). And then, LVM is up next.
 

I agree that it is a little patchy this way, although the *right* way
you mention will take considerable amounts of time to complete (I
guess?).
I will have a look at mdadm experimental though and see if that works
(just installing experimental on this box and trying the original
initramfs scripts. Indeed LVM is needed too but that's the next stage
(I'd rather use experimental mdadm w/o LVM than a custom initramfs).

Best regards,
Jort Koopmans






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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-13 Thread Jort Koopmans
Hi Will,

Instead of patching this here and there with band aids, I suggest
that everyone with an interest instead invests time in testing
mdadm/experimental, which provides event-based assembly, 

I was wondering what documentation the reporter was following. 

I haven't seen RAID on USB supported in stable.

I've not followed any documentation, I was just hoping to get it working
since I assumed it would be possible. It was not aware of Raid 1 on USB
being explicitly not supported, if that's the case you can also consider
my report to be a feature request :), even though it applies to all
slowly initialized devices (not per definition USB devices).

Jort




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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

2011-10-12 Thread Jort Koopmans
Common guys...can somebody look at my bugreport?

In the mean while I've checked another solution; moving the call to the
local-top scripts till after the ROOTDELAY loop (within the local file).
This works in my config. But this would delay finding the ROOT dir in
normal instances (where devices are quick enough), so maybe we can call
the scripts again after the ROOTDELAY loop? I'm not sure if that would
break any setups out there (calling mdadm and lvm2 twice)?

I'd really like some replies or ideas on the whole subject...

Best regards,
Jort Koopmans




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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation

2011-10-10 Thread Jort Koopmans
Additional thoughts;

As I'm no expert on the whole initramfs boot sequence I'm unsure about
the total workings of timing of device scanning, mdadm + lvm2 routines
and rootdelay.

Imho it should be something like this;

init Device scanning 
|
some scanning delay parameter (for slow devices)
|
init Mdadm routine
|
some mdadm delay parameter? (see #633024)
|
LVM2 routine
|
Checking and setting ROOT

Again, I'm not too familiar with the current workings but I see these
steps are currently running in a more parallel way to speed up the boot
process, as the local-top init scripts are called right at the start of
the local script.
I've confirmed this by trying another method of fixing my problem,
instead of my previous fix;

Adding 'sleep 10' at the top of /scripts/local-top/mdadm also solves the
problem (mdadm is then performed after device scanning)

Is there a unifiable way of getting the timings right of all the scripts
and still maintaining a quick bootprocess? If not, is it possible to add
extra kernel boot options providing the delay options (avoiding manual
tampering with the initrd)?

Best regards,
Jort Koopmans




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



Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation

2011-10-09 Thread Jort Koopmans
Package: initramfs-tools
Version: 0.98.8
Severity: important


Dear kernelteam,

After installing a vanilla debian kernel (2.6.32-5-amd64) to 2 similar USB 
thumbdrives in software RAID1 and using LVM2 an error occurs at boot stating 
ROOT can not be found. In my case / is locted on an lv managed by lvm 
(/dev/mapper/vgbase-lvroot), of which the volume group is located on a raid1 
(using partitions from both usb drives)
The origin of the problem is the combination of late detection of the USB 
devices in combination with the bootsequence.

After some research it became clear to me that the mdadm and lvm routines 
(located in /scripts/local-top?) are performed before the rootdelay loop 
(located in /scripts/local).
On systems without a complex raid or lvm setup this poses no problem since the 
root will instantly be present when the slow device is recognised.

In my case adding a rootdelay=x does NOT solve the problem because when the USB 
drives become available there are still no started MD devices or LVM volumes.
The (quick and dirty) solution for me was adding 3 lines to the /scripts/local 
file after the rootdelay loop (ends at line 42);

/sbin/mdadm --assemble --scan
/sbin/lvm vgscan --ignorelockingfailure
/sbin/lvm vgchange --ignorelockingfailure -a y

In essence this repeats the mdadm and lvm2 routines but then without the nice 
checking of earlier mentioned scripts.

Of course it would be better to get the routines programmed nicely after the 
rootdelay parameter.
Is it possible to fix this? I am happy to assist in testing better solutions 
than the dirty one I proposed. Also I will try to answer any questions if the 
above is unclear or if more information is needed.

See also bug #433905 for a similar case (only first post applies).

Best regards,
Jort Koopmans


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 11M Oct  9 22:59 /boot/initrd.img-2.6.32-5-amd64
-rw-r--r-- 1 root root 11M Oct  9 11:57 /boot/initrd.img-2.6.32-5-amd64.bakorig
-rw-r--r-- 1 root root 11M Oct  9 15:22 /boot/initrd.img-2.6.32-5-amd64.bakworks
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vgbase-lvroot ro quiet

-- resume
RESUME=/dev/mapper/vgbase-lvswap
-- /proc/filesystems
ext3

-- lsmod
Module  Size  Used by
loop   11799  0 
evdev   7352  4 
pcspkr  1699  0 
i2c_i8017830  0 
i2c_core   15819  1 i2c_i801
snd_hda_intel  20035  0 
snd_hda_codec  54244  1 snd_hda_intel
snd_hwdep   5380  1 snd_hda_codec
snd_pcm60487  2 snd_hda_intel,snd_hda_codec
snd_timer  15598  1 snd_pcm
snd46526  5 
snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
soundcore   4598  1 snd
snd_page_alloc  6249  2 snd_hda_intel,snd_pcm
ioatdma34876  16 
dca 3761  1 ioatdma
button  4650  0 
processor  29935  8 
ext3  106710  3 
jbd37221  1 ext3
mbcache 5050  1 ext3
sd_mod 29921  6 
crc_t10dif  1276  1 sd_mod
dm_mod 53898  9 
raid1  18431  2 
md_mod 73872  3 raid1
usbhid 33292  0 
hid63257  1 usbhid
usb_storage40057  4 
uhci_hcd   18521  0 
ahci   32534  0 
libata133776  1 ahci
scsi_mod  126533  3 sd_mod,usb_storage,libata
ehci_hcd   32081  0 
e1000e124772  0 
usbcore   122674  5 usbhid,usb_storage,uhci_hcd,ehci_hcd
nls_base6377  1 usbcore
thermal11674  0 
thermal_sys11942  2 processor,thermal

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=
NFSROOT=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sda2[0] sdb2[1]
  15051704 blocks super 1.2 [2/2] [UU]
  
md0 : active raid1 sda1[0] sdb1[1]
  306164 blocks super 1.2 [2/2] [UU]
  
unused devices: none

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
busybox
dmsetup
keymap
klibc
lvm2
mdadm
thermal
udev


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

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
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 initramfs-tools depends on:
ii  cpio   2.11-4

Bug#609315: php5: Upstream bug CVE-2010-4645 / bug #53632, critical: conversion stringdouble might hang PHP interpreter

2011-01-08 Thread Jort Koopmans
Package: php5
Version: 5.2.6.dfsg.1-1+lenny9
Severity: critical


From upstream; http://bugs.php.net/bug.php?id=53632
followed by release 5.3.5 and 5.2.17: 
http://www.php.net/archive/2011.php#id2011-01-06-1

Short description;

Conversions from string to double might cause the PHP interpreter to 
hang on systems using x87 FPU registers.

The problem is known to only affect x86 32-bit PHP processes, regardless 
of whether the system hosting PHP is 32-bit or 64-bit.


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

Kernel: Linux 2.6.26-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 php5 depends on:
ii  libapache2-mod-php5   5.3.3-6server-side, HTML-embedded scripti
ii  php5-common   5.3.3-6Common files for packages built fr

php5 recommends no packages.

php5 suggests no packages.

-- 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#609315: Upstream bug CVE-2010-4645 / bug #53632, critical: conversion stringdouble might hang PHP interpreter

2011-01-08 Thread Jort Koopmans
Update:

My x64 testsystem running php5.2.6dfsg.1-1+lenny9 does not seem to be
affected when using this script from CLI:
http://www.php.net/distributions/test_bug53632.txt

but php -v shows:

/# php -v
PHP 5.3.3-6 with Suhosin-Patch (cli) (built: Dec  7 2010 12:47:03) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

while phpinfo displays 5.2.6

so probably this testsystem is no good for reproducing the bug since its
no vanilla install, and also a x64 build (which seems unaffected).




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



Bug#609315: php5: Upstream bug CVE-2010-4645 / bug #53632, critical: conversion stringdouble might hang PHP interpreter

2011-01-08 Thread Jort Koopmans
On Sat, 2011-01-08 at 16:31 +0100, Julien Cristau wrote:
[..]
 Did you actually reproduce this with php 5.2.6.dfsg.1-1+lenny9?  AFAIK
 people tried and couldn't.

As mentioned in my update I couldnt reproduce it, but the 64bit build of
php5 seems unaffected, so maybe users with a 32bit install should test
it? If I understand the upstream buginfo correctly, both lenny and
squeeze current releases (32bit) should be vulnerable to this bug. I'd
recommend getting in touch with the people from PHP (Pajoye).

Cheers,
Jort




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



Bug#603489: roundcube: BAD HEADER section by Amavis when using long mail subject

2010-11-14 Thread Jort Koopmans
Package: roundcube
Version: 0.3.1-6
Severity: minor


Hello again ;),
I've found a minor bug in the mail headers created by roundcube (or the 
handling of them by Amavis).
When using a long subject, roundcube cuts them up in two lines, breaking the 
handling by Amavis.

Example

Subject: test test test test test test test test test test test test test test 
test test
gives
X-Amavis-Alert: BAD HEADER SECTION, Improper use of control character (char 0D 
hex): Subject: ...test test test test test test test test\r\n test

I'm not sure if there are any standards (rfc's) needed to be considered for the 
mail-headers.

Best regards,
Jort Koopmans

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

Kernel: Linux 2.6.26-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 roundcube depends on:
ii  roundcube-core0.3.1-6skinnable AJAX based webmail solut

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  apache22.2.9-10+lenny8   Apache HTTP Server metapackage
ii  apache2-mpm-prefor 2.2.9-10+lenny8   Apache HTTP Server - traditional n
ii  dbconfig-common1.8.46common framework for packaging dat
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  libjs-jquery   1.4.2-2   JavaScript library for dynamic web
ii  libmagic1  4.26-1File type determination library us
ii  php-auth   1.6.2-1   PHP PEAR modules for creating an a
ii  php-mail-mime  1.8.0-2   PHP PEAR module for creating MIME 
ii  php-mdb2   2.5.0b2-1 PHP PEAR module to provide a commo
ii  php-net-smtp   1.3.1-1   PHP PEAR module implementing SMTP 
ii  php-net-socket 1.0.9-2   PHP PEAR Network Socket Interface 
ii  php5   5.2.6.dfsg.1-1+lenny9 server-side, HTML-embedded scripti
ii  php5-gd5.2.6.dfsg.1-1+lenny9 GD module for php5
ii  php5-mcrypt5.2.6.dfsg.1-1+lenny9 MCrypt module for php5
ii  php5-pspell5.2.6.dfsg.1-1+lenny9 pspell module for php5
ii  roundcube-mysql0.3.1-6   metapackage providing MySQL depend
ii  tinymce3.3.8-1   platform independent web based Jav
ii  ucf3.0016Update Configuration File: preserv

-- debconf information:
  roundcube/upgrade-error: abort
  roundcube/pgsql/authmethod-user: password
  roundcube/purge: false
* roundcube/dbconfig-install: true
  roundcube/db/dbname: roundcube
  roundcube/language: en_US
  roundcube/remote/newhost:
  roundcube/pgsql/changeconf: false
  roundcube/upgrade-backup: true
  roundcube/install-error: abort
  roundcube/mysql/admin-user: root
  roundcube/hosts:
  roundcube/pgsql/authmethod-admin: ident
  roundcube/dbconfig-remove:
  roundcube/pgsql/admin-user: postgres
  roundcube/internal/skip-preseed: false
  roundcube/db/app-user: roundcube
  roundcube/dbconfig-reinstall: false
  roundcube/mysql/method: unix socket
  roundcube/remove-error: abort
  roundcube/restart-webserver: true
  roundcube/dbconfig-upgrade: true
  roundcube/remote/port:
  roundcube/pgsql/method: unix socket
  roundcube/pgsql/manualconf:
  roundcube/db/basepath:
  roundcube/pgsql/no-empty-passwords:
  roundcube/passwords-do-not-match:
  roundcube/internal/reconfiguring: false
  roundcube/reconfigure-webserver: apache2, lighttpd
* roundcube/database-type: mysql
  roundcube/remote/host:
  roundcube/missing-db-package-error: abort



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



Bug#603489: RFC 2822

2010-11-14 Thread Jort Koopmans
Additional info; Amavis (Amavisd-new) header checking should be fully
RFC2822 compliant, hence I would recommend Roundcube to also comply to
this standard.
If you need any help or testing done, let me know.

Best regards,
Jort Koopmans




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



Bug#599586: BAD HEADER by amavisd-new when sending attachment from roundcube

2010-10-18 Thread Jort Koopmans
Hello Vincent,

On Mon, 2010-10-18 at 19:37 +0200, Vincent Bernat wrote:
 OoO Pendant  le temps de midi  du dimanche 10 octobre  2010, vers 12:46,
 Jort Koopmans jort.koopm...@gmail.com disait :
 
   I have  tested with  roundcube from squeeze  sending mail to  an amavisd
   from lenny. I do not get a BAD HEADER SECTION. However, the Content-Type
   header contains the boundary twice.  It think this may be related. Could
   you check what Content-Type do you get in your quarantined message?
  
 
  X-PHP-Originating-Script: 0:func.inc
  MIME-Version: 1.0
  Content-Type: multipart/mixed;
   boundary==_fce46910f3b128bcbbfed9efa85812c9;
   boundary==_fce46910f3b128bcbbfed9efa85812c9
 
  Thats a double indeed i'd say.
 
 Could you apply  the attached patch? It fixes the problem  for me. If it
 also fixes your problem, I will do an upload shortly.
 

Thanks for this patch, I've applied and tested it and it works! As far
as I understand whats going on, there is only 1 header written now for
the body of the message and attachments don't add to this (don't know if
thats a permanent fix, but hey it works for now).
Thanks again Vincent for your time and efforts resolving this problem!

Jort




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



Bug#599586: BAD HEADER by amavisd-new when sending attachment from roundcube

2010-10-10 Thread Jort Koopmans
On Sun, 2010-10-10 at 09:59 +0200, Vincent Bernat wrote:
 OoO  En cette  matinée ensoleillée  du  dimanche 10  octobre 2010,  vers
 09:51, je disais:
 
  - Debian Lenny for most part (php5, apache, postfix)
  - Amavisd-new from Squeeze (since they tend to have better filtering)
  - Roundcube with all needed updated dependencies
 
  I have  tested with  roundcube from squeeze  sending mail to  an amavisd
  from lenny. I do not get a BAD HEADER SECTION. However, the Content-Type
  header contains the boundary twice.  It think this may be related. Could
  you check what Content-Type do you get in your quarantined message?
 

X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary==_fce46910f3b128bcbbfed9efa85812c9;
 boundary==_fce46910f3b128bcbbfed9efa85812c9

Thats a double indeed i'd say.

 I have  tried with an older  version of php-mail-mime  and the duplicate
 boundary is gone.  Could you try to copy  mime.php and mimePart.php from
 php-mail-mime 1.5.3  to /usr/share/php/Mail and  try again if  you still
 get the message from Amavis?
 

Good news, indeed this fixes the problem! No more BAD HEADER section.
Reinstalling php-mail-mime brings it back to the bad headers, so these 2
files are indeed responsible. I dont have much time today anymore, but
will look into it further tomorrow! Let's find out whats changed from
1.5.3 to 1.8.0 in those files :)...

Cheers,
Jort




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



Bug#599586: BAD HEADER SECTION when sending attachment from roundcube, processed by amavisd-new (amavis)

2010-10-09 Thread Jort Koopmans
Hello Vincent,

On Sat, 2010-10-09 at 11:24 +0200, Vincent Bernat wrote:
 clone 595204 -1
 retitle -1 BAD HEADER SECTION with amavis
 reopen -1
 found -1 0.3.1-5
 thanks
 
 OoO En cette matinée pluvieuse  du vendredi 08 octobre 2010, vers
10:37,
 Jort Koopmans jort.koopm...@gmail.com disait :
 
   Delivered-To: bad-header-quarantine
 
   X-Envelope-From: emaila...@dom.com
   X-Envelope-To: emaila...@dom.com
   X-Envelope-To-Blocked: 
   X-Quarantine-ID: qr5mFt35ESxD
   X-Amavis-Alert: BAD HEADER SECTION Improper use of control
character
   (char 0D
hex): Content-Type: ...eb64d5fa4fdc3040d561170;\r\n
boundary==_4[...]
  
  In fact,  the ticket that you  mentionned previously was  not about
this
  bug. I think your bug is here:
  http://trac.roundcube.net/ticket/1486418
 
  The BAD HEADER SECTION is the same as I had from my first post and
does
  not look like the PHP bug, while that has X-PHP-Originating-Script:
  0:func.inc\r added (not in my case)
 
  I use PHP 5.2.6.dfsg.1-1+lenny9 (stable). Bug 1486418 seems related
to
  php 5.2.3, so not likely to be the cause. mail.add_x_header is not
  implemented in this version.
  Tested the proposed step at followup 11 
  ($headers['Subject'] = mb_encode_mimeheader($headers['Subject'],
  $message_charset, 'Q', $RCMAIL-config-header_delimiter(), 8);
  )
  No success unfortunately.
 
 OK.  This bug  seems quite  different from  the one  that  you
initially
 reported (which  was a  bad received  header and which  is fixed  by
the
 patch you have found). 

I agree, it was fixed by the patch. Something else is going wrong...

 I need to look a bit what is this new bug. It may
 have been introduced by the new dependency on php-mail-mime 1.7.0.
Which
 version of php-mail-mime do you have on your system?

On all systems I run version 1.8.0-2 (from squeeze repository).
Thanks again for all your efforts in troubleshooting this bug, if you
need any more info or I need to test some code for you, let me know,
i'll always help out. Have you been able to reproduce the problem or is
it just me? :P

Best regards,
Jort Koopmans




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



Bug#595204: Problem not solved in 0.3.1-5?

2010-10-08 Thread Jort Koopmans
On Fri, 2010-10-08 at 09:21 +0200, Vincent Bernat wrote:
 OoO En  cette nuit  striée d'éclairs du  vendredi 08 octobre  2010, vers
  ---
  Delivered-To: bad-header-quarantine
  X-Envelope-From: emaila...@dom.com
  X-Envelope-To: emaila...@dom.com
  X-Envelope-To-Blocked: 
  X-Quarantine-ID: qr5mFt35ESxD
  X-Amavis-Alert: BAD HEADER SECTION Improper use of control character
  (char 0D
  hex): Content-Type: ...eb64d5fa4fdc3040d561170;\r\n
  boundary==_4[...]
 
 In fact,  the ticket that you  mentionned previously was  not about this
 bug. I think your bug is here:
  http://trac.roundcube.net/ticket/1486418

The BAD HEADER SECTION is the same as I had from my first post and does
not look like the PHP bug, while that has X-PHP-Originating-Script:
0:func.inc\r added (not in my case)

I use PHP 5.2.6.dfsg.1-1+lenny9 (stable). Bug 1486418 seems related to
php 5.2.3, so not likely to be the cause. mail.add_x_header is not
implemented in this version.
Tested the proposed step at followup 11 
($headers['Subject'] = mb_encode_mimeheader($headers['Subject'],
$message_charset, 'Q', $RCMAIL-config-header_delimiter(), 8);
)
No success unfortunately.

Best regards,
Jort Koopmans




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



Bug#595204: Problem not solved in 0.3.1-5?

2010-10-08 Thread Jort Koopmans
On Fri, 2010-10-08 at 10:37 +0200, Jort Koopmans wrote:
 Bug 1486418 seems related to
 php 5.2.3, so not likely to be the cause. mail.add_x_header is not
 implemented in this version.

Typo; Bug 1486418 seems related to php 5.3.0, so not likely to be the
cause.




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



Bug#595204: Problem not solved in 0.3.1-5?

2010-10-06 Thread Jort Koopmans
Dear Vincent Bernat,

After updating to 0.3.1-5 the BAD HEADER messages returned (after my
manual fix). Is there something else changed within roundcube? I can
confirm that the /var/lib/roundcube/program/steps/mail/sendmail.inc does
contain the fix proposed from the trunk (see my first bugpost).
Have you tested 0.3.1-5 to work well with amavis/postfix?

To everybody else; can you confirm or deny correct header handling of
roundcube (when using attachments).

Thanks for your time and efforts in advance, keep up the good work!
Best regards,
Jort Koopmans
 




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



Bug#595204: roundcube: Mail headers of RC are filtered as BAD HEADER by SpamAssassin

2010-09-01 Thread Jort Koopmans
Package: roundcube
Version: 0.3.1-4
Severity: normal
Tags: patch


Hello,
After upgrade from roundcube 0.3.0 to 0.3.1 from de debian repo's, mail headers 
of mails with attachments and originating from RC are filtered as BAD-HEADER by 
SpamAssassin 
(Amavis). Mail is still passed on, though X-Amavis-Alert header-lines are 
added. Typical added header-lines look like;
X-Amavis-Alert: BAD HEADER SECTION Improper use of control character (char 0D
hex): Content-Type: ...MAILID;\r\n
boundary==_X[...]

This is caused by the change of the header format from 0.3.0 to 0.3.1 which 
enables SpamAssassin to read the headers in the first place, see 
http://trac.roundcube.net/ticket/1486513
Can this annoying behaviour be fixed (since it is a step back from 0.3.0 in 
some way), by;
1) Using the patch of changeset 3291 (http://trac.roundcube.net/changeset/3291)
2) Packaging 0.4.0 release version (changeset 3291 is applied in 0.4.0 beta), 
see wishlist item #592312

Best regards,
Jort Koopmans


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

Kernel: Linux 2.6.26-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 roundcube depends on:
ii  roundcube-core0.3.1-4skinnable AJAX based webmail solut

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  apache22.2.9-10+lenny8   Apache HTTP Server metapackage
ii  apache2-mpm-prefor 2.2.9-10+lenny8   Apache HTTP Server - traditional n
ii  dbconfig-common1.8.46common framework for packaging dat
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  libjs-jquery   1.4.2-2   JavaScript library for dynamic web
ii  libmagic1  4.26-1File type determination library us
ii  php-auth   1.6.2-1   PHP PEAR modules for creating an a
ii  php-mail-mime  1.8.0-1   PHP PEAR module for creating MIME 
ii  php-mdb2   2.5.0b2-1 PHP PEAR module to provide a commo
ii  php-net-smtp   1.3.1-1   PHP PEAR module implementing SMTP 
ii  php-net-socket 1.0.9-2   PHP PEAR Network Socket Interface 
ii  php5   5.2.6.dfsg.1-1+lenny9 server-side, HTML-embedded scripti
ii  php5-gd5.2.6.dfsg.1-1+lenny9 GD module for php5
ii  php5-mcrypt5.2.6.dfsg.1-1+lenny9 MCrypt module for php5
ii  php5-pspell5.2.6.dfsg.1-1+lenny9 pspell module for php5
ii  roundcube-mysql0.3.1-4   metapackage providing MySQL depend
ii  tinymce3.3.8-1   platform independent web based Jav
ii  ucf3.0016Update Configuration File: preserv

-- debconf information:
  roundcube/upgrade-error: abort
  roundcube/pgsql/authmethod-user: password
  roundcube/purge: false
* roundcube/dbconfig-install: true
  roundcube/db/dbname: roundcube
  roundcube/language: en_US
  roundcube/remote/newhost:
  roundcube/pgsql/changeconf: false
  roundcube/upgrade-backup: true
  roundcube/install-error: abort
  roundcube/mysql/admin-user: root
  roundcube/hosts:
  roundcube/pgsql/authmethod-admin: ident
  roundcube/dbconfig-remove:
  roundcube/pgsql/admin-user: postgres
  roundcube/internal/skip-preseed: false
  roundcube/db/app-user: roundcube
  roundcube/dbconfig-reinstall: false
  roundcube/mysql/method: unix socket
  roundcube/remove-error: abort
  roundcube/restart-webserver: true
  roundcube/dbconfig-upgrade: true
  roundcube/remote/port:
  roundcube/pgsql/method: unix socket
  roundcube/pgsql/manualconf:
  roundcube/db/basepath:
  roundcube/pgsql/no-empty-passwords:
  roundcube/passwords-do-not-match:
  roundcube/internal/reconfiguring: false
  roundcube/reconfigure-webserver: apache2, lighttpd
* roundcube/database-type: mysql
  roundcube/remote/host:
  roundcube/missing-db-package-error: abort
?php

/*
 +---+
 | program/steps/mail/sendmail.inc   |
 |   |
 | This file is part of the RoundCube Webmail client |
 | Copyright (C) 2005-2009, RoundCube Dev. - Switzerland |
 | Licensed under the GNU GPL|
 |   |
 | PURPOSE:  |
 |   Compose a new mail message with all headers and attachments |
 |   and send it using the PEAR::Net_SMTP class or with PHP mail

Bug#588295: roundcube: The mime_param_folding parameter is not working without PEAR Mail_Mime module (v1.6)

2010-07-06 Thread Jort Koopmans
Package: roundcube
Version: 0.3.1-3
Severity: normal


Symptoms: Attachments sent from Roundcube have a changed name, typically some 
ATT0xxx.extension name, when recieved on a Microsoft Outlook (2003 tested) mail 
client. This is due to 2 facts; (1) Microsoft uses the wrong and mixed 
RFC's for their mailclient and (2) the Rouncube directive 'mime_param_folding' 
is not obeyed or used in any way. (The mime_param_folding directive should work 
using option 1)

Proposed solution: Solved using http://trac.roundcube.net/ticket/1486025
To make Roundcube use the directive, the additional Pear module Mail_Mime must 
be installed (version 1.7.0 tested)

Please make the pear Mail_Mime module a dependency.


Best regards,
Jort Koopmans


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

Kernel: Linux 2.6.26-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 roundcube depends on:
ii  roundcube-core0.3.1-3skinnable AJAX based webmail solut

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  apache22.2.9-10+lenny8   Apache HTTP Server metapackage
ii  apache2-mpm-prefor 2.2.9-10+lenny8   Apache HTTP Server - traditional n
ii  dbconfig-common1.8.46common framework for packaging dat
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  libjs-jquery   1.4.2-2   JavaScript library for dynamic web
ii  libmagic1  4.26-1File type determination library us
ii  php-auth   1.6.2-1   PHP PEAR modules for creating an a
ii  php-mail-mime  1.5.3-0.1 PHP PEAR module for creating MIME 
ii  php-mdb2   2.5.0b2-1 PHP PEAR module to provide a commo
ii  php-net-smtp   1.3.1-1   PHP PEAR module implementing SMTP 
ii  php-net-socket 1.0.9-2   PHP PEAR Network Socket Interface 
ii  php5   5.2.6.dfsg.1-1+lenny8 server-side, HTML-embedded scripti
ii  php5-gd5.2.6.dfsg.1-1+lenny8 GD module for php5
ii  php5-mcrypt5.2.6.dfsg.1-1+lenny8 MCrypt module for php5
ii  php5-pspell5.2.6.dfsg.1-1+lenny8 pspell module for php5
ii  roundcube-mysql0.3.1-3   metapackage providing MySQL depend
ii  tinymce3.3.7-1   platform independent web based Jav
ii  ucf3.0016Update Configuration File: preserv

-- debconf information:
  roundcube/upgrade-error: abort
  roundcube/pgsql/authmethod-user: password
  roundcube/purge: false
* roundcube/dbconfig-install: true
  roundcube/db/dbname: roundcube
  roundcube/language: en_US
  roundcube/remote/newhost:
  roundcube/pgsql/changeconf: false
  roundcube/upgrade-backup: true
  roundcube/install-error: abort
  roundcube/mysql/admin-user: root
  roundcube/hosts:
  roundcube/pgsql/authmethod-admin: ident
  roundcube/dbconfig-remove:
  roundcube/pgsql/admin-user: postgres
  roundcube/internal/skip-preseed: false
  roundcube/db/app-user: roundcube
  roundcube/dbconfig-reinstall: false
  roundcube/mysql/method: unix socket
  roundcube/remove-error: abort
  roundcube/restart-webserver: true
  roundcube/dbconfig-upgrade: true
  roundcube/remote/port:
  roundcube/pgsql/method: unix socket
  roundcube/pgsql/manualconf:
  roundcube/db/basepath:
  roundcube/pgsql/no-empty-passwords:
  roundcube/passwords-do-not-match:
  roundcube/internal/reconfiguring: false
  roundcube/reconfigure-webserver: apache2, lighttpd
* roundcube/database-type: mysql
  roundcube/remote/host:
  roundcube/missing-db-package-error: abort



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



Bug#405919: the issue with mismatch_cnt

2010-02-07 Thread Jort Koopmans
Thanks for the explanation of this mismatch.
I agree it would be very useful to distinguish between these 'memory
mapped files' mismatches and true data mismatches.
In Etch this issue was not present if i'm correct, how was it working
there?

J. Koopmans




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



Bug#518477: libmysqlclient15off: Bug still existing in 5.0.51a-24+lenny2 (?)

2009-12-02 Thread Jort Koopmans
Package: libmysqlclient15off
Version: 5.0.51a-24+lenny2
Followup-For: Bug #518477


In Debian 2.6.26-2-amd64 with libmysqlclient15off 5.0.51a-24+lenny2 
this problem occurs as well. When using the patch provided here: 
http://people.debian.org/~seanius/mysql/513204/amd64/libmysqlclient15off_5.0.51a-24lenny1_amd64.deb
 
,basically the lenny1 version, the segfault problem is fixed. Trying to 
follow up the mf_pack.c replacement mentioned in this bug, but have not 
succeeded yet. I do have the empty $HOME somewhere though (tested that).

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

Kernel: Linux 2.6.26-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 libmysqlclient15off depends on:
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  mysql-common   5.0.51a-24+lenny2 MySQL database common files
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

libmysqlclient15off recommends no packages.

libmysqlclient15off suggests no packages.

-- 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#518477: libmysqlclient15off: supplemental info 5.0.51a-24+lenny2

2009-12-02 Thread Jort Koopmans
Package: libmysqlclient15off
Version: 5.0.51a-24+lenny2
Followup-For: Bug #518477


Done some further investigation, using this small shell script;


count=1
while true; do 
echo '?php echo toto tata \n;' | php; 
if [ $? -ne 0 ]; then   
echo died after ${i:-0};
break; 
else 
i=$(expr ${i:-0} + 1); 
shift
echo $i
fi; 
done


I used 2 machines with the same *updated* version of lenny (stable) x64, 
both get segmentation faults running the above script with the 
5.0.51a-24+lenny2 version of libmysqlclient15off (albeit at very 
different loop numbers). 
When replacing the package with a 5.0.51a-24lenny1 
version, provided by Sean: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493045#107 , the 
problem is instantly gone. However I've also tried to follow the 
(by Sven) suggested patch in this bugtracker, but have not succeeded 
because i can not find any 'mf_pack.c' file or 'tilde_expansion' 
function.

When I run:
echo SELECT 'mysql ok' | HOME='' mysql
it does give a 'Segmentation fault (core dumped)' message (therefore 
i'm posting this in this bugtracker)

For now i'm going to run the lenny1 version of this package, but 
hopefully someone can fix this problem...

Best regards,
Jort

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

Kernel: Linux 2.6.26-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 libmysqlclient15off depends on:
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  mysql-common   5.0.51a-24+lenny2 MySQL database common files
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

libmysqlclient15off recommends no packages.

libmysqlclient15off suggests no packages.

-- 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