Bug#1063753: systemd: IFB network devices are no longer autocreated when ifb module is loaded

[Andreas Sundstrom]

Ok, then I will stick with my workaround.

Although I don't think defaults like this really should change within a 
stable release, and certainly not without a notice about in in the 
changelog or NEWS file.


/Andreas

Bug#1063753: systemd: IFB network devices are no longer autocreated when ifb module is loaded

[Andreas Sundstrom]

Package: systemd
Version: 252.22-1~deb12u1
Severity: important
X-Debbugs-Cc: sunkan+debian.b...@zappa.cx

Dear Maintainer,

After upgrading systemd from 252.19-1~deb12u1 to 252.22-1~deb12u1
(Bookworm 12.4 to 12.5) the IFB network devices are no longer
automatically created when loading the `ifb` module. This is a
regression since previous releases as there is nothing mentioned about
this in the changelog.

It seems the root cause is that the following has been added to
/lib/modprobe.d/systemd.conf

[part of .../systemd.conf]
# Do the same for ifb0.

options ifb numifbs=0
[end]

How this will affect your system depends a lot on what you use the IFB
device(s) for. In my case it is used in combination with a QoS
scheduling/shaping setup.

For now I have worked around this change by adding the IFB device I
needed manually with the command `ip link add ifb0 numtxqueues 8 type
ifb`. And from what I can tell the kernel default setting is
`numifbs=2`.

Bug#1024426:

[Andreas Sundstrom]

I have had the same problem as Roland for a long time and today I finally 
decided to troubleshoot it.

Quickly came to the conclusion that notify-send was the culprit.

Through trial and error I added this to my 400-notify-send script to get it 
working:
export XDG_RUNTIME_DIR=$(sed -z -n s/^XDG_RUNTIME_DIR=//p 
"/proc/$NR_SESSPPID/environ")

Then I found this bug and I tried Rolands solution and it also works for me.
I have no idea which solution may be more appropriate or not.

I run KDE and this is Debian Bullseye (currently Debian stable) but the 
400-notify-script
has not changed between the releases (except whitespace and comments).

Regards
Andreas

Bug#930764: cyrus-common 3.0.8-6 fails to configure package due to "unknown type of DB: BACKUP" on upgrade-db

[Andreas Sundstrom]

Package: cyrus-common
Version: 3.0.8-6+deb10u1
Followup-For: Bug #930764

Dear Maintainer,

The problem is also present in 3.0.8-6+deb10u1.
So when upgrading from 3.0.8-6 to that (through proposed-updates) the 
cyrus-common package
postinst fails and the package is left in a "failed" state.

Output from retrying the configuration of the package:

root@matrix:/usr/share/doc/cyrus-common# dpkg --configure --pending 
Setting up cyrus-common (3.0.8-6+deb10u1) ...
Creating/updating cyrus user account...
The user `cyrus' is already a member of `sasl'.
/usr/lib/cyrus/bin/upgrade-db: Unknown type of DB: BACKUP
dpkg: error processing package cyrus-common (--configure):
 installed cyrus-common package post-installation script subprocess returned 
error exit status 1
dpkg: dependency problems prevent configuration of cyrus-clients:
 cyrus-clients depends on cyrus-common (>= 3.0.8); however:
  Package cyrus-common is not configured yet.

dpkg: error processing package cyrus-clients (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of cyrus-admin:
 cyrus-admin depends on cyrus-common; however:
  Package cyrus-common is not configured yet.

dpkg: error processing package cyrus-admin (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of cyrus-imapd:
 cyrus-imapd depends on cyrus-common (= 3.0.8-6+deb10u1); however:
  Package cyrus-common is not configured yet.

dpkg: error processing package cyrus-imapd (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 cyrus-common
 cyrus-clients
 cyrus-admin
 cyrus-imapd

Bug#942244: xen-tools: xen-create-image does not work with lvm_thin

[Andreas Sundstrom]

Package: xen-tools
Version: 4.8-1
Severity: normal
Tags: patch

Dear Maintainer,

I have been using xen-create-image and LVM as the backing for the
disks for a long time. Now I have made a LVM ThinPool and was glad to
find support for that in xen-tools. However it fails to work due to
the name of the VG is specifed on the cmd-line for the lvcreate
command and it should not be that way when a ThinPool is used.

I have fixed the xen-create-image command on my machine and it works
with both regular LVM and LVM with ThinPool on my setup. See the patch
included in this report for the details on what I did.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xen-tools depends on:
ii  debootstrap   1.0.114
ii  libconfig-inifiles-perl   3.01-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.27-1
ii  libdata-validate-uri-perl 0.07-1
ii  libfile-slurp-perl.26-1
ii  libfile-which-perl1.23-1
ii  libsort-versions-perl 1.62-1
ii  libterm-ui-perl   0.46-1
ii  libtext-template-perl 1.55-1
ii  openssh-client1:7.9p1-10+deb10u1
ii  perl  5.28.1-6

Versions of packages xen-tools recommends:
ii  debian-archive-keyring  2019.1
ii  e2fsprogs   1.44.5-1+deb10u2
pn  libexpect-perl  
ii  lvm22.03.02-3
pn  rinse   
ii  ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5
ii  xen-hypervisor-4.11-amd64 [xen-hypervisor]  4.11.1+92-g6c33308a8d-2
ii  xen-utils-4.11 [xen-utils]  4.11.1+92-g6c33308a8d-2

Versions of packages xen-tools suggests:
pn  btrfs-progs | btrfs-tools  
pn  cfengine2  
ii  grub-xen-host  2.02+dfsg1-20
pn  reiserfsprogs  
pn  xfsprogs   

-- Configuration Files:
/etc/xen-tools/xen-tools.conf changed [not included]
/etc/xen-tools/xm.tmpl changed [not included]

-- no debconf information
--- /usr/bin/xen-create-image~  2019-02-09 01:56:51.0 +0100
+++ /usr/bin/xen-create-image   2019-10-12 21:33:07.0 +0200
@@ -3224,12 +3224,11 @@
 # The commands to create the volume.
 #
 my $disk_cmd =
-  "lvcreate $CONFIG{'lvm'} ".
-  ($lvm_needs_yes ? '--yes' : '').
-  ' '.
+  "lvcreate ".
+  ($lvm_needs_yes ? '--yes ' : '').
   ($CONFIG{ 'lvm_thin' } ?
"-T $CONFIG{'lvm'}/$CONFIG{'lvm_thin'} -V" :
-   '-L').
+   "$CONFIG{'lvm'} -L").
   " $partition->{'size'} -n $disk";
 
 #

Bug#808374: linux-image-3.16.0-4-686-pae: FreeRADIUS EAP-TLS stopped working when kernel was updated

[Andreas Sundstrom]

Package: src:linux
Version: 3.16.7-ckt20-1+deb8u1
Severity: important

Dear Maintainer,

After updating the kernel with the latest security release FreeRADIUS
seem to be unable to process the UDP packets it is receiving.  As you
can see in this strace there's some error occuring with the recvfrom()
that is triggered by the incoming packet.  Downgrading the kernel to
linux-image-3.16.0-4-686-pae:i386 3.16.7-ckt11-1+deb8u6 makes it work
again.

This is a i686 domU on a X86_64 XEN host if that matters.


When using current kernel:

execve("/usr/sbin/freeradius", ["freeradius", "-s"], [/* 21 vars */]) = 0
brk(0)  = 0x9e47000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb77c5000
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb77c2000
[...]
select(10, [4 6 7 8 9], NULL, NULL, NULL) = 1 (in [6])
recvfrom(6, 0xbf9909c8, 4, 2, 0xbf990948, 0xbf990944) = -1 EAGAIN
(Resource temporarily unavailable)
select(10, [4 6 7 8 9], NULL, NULL, NULL) = 1 (in [6])
recvfrom(6, 0xbf9909c8, 4, 2, 0xbf990948, 0xbf990944) = -1 EAGAIN
(Resource temporarily unavailable)
select(10, [4 6 7 8 9], NULL, NULL, NULL) = 1 (in [6])
recvfrom(6, 0xbf9909c8, 4, 2, 0xbf990948, 0xbf990944) = -1 EAGAIN
(Resource temporarily unavailable)
select(10, [4 6 7 8 9], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be
restarted if no handler)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL,
si_value={int=1851877730, ptr=0x6e616962}} ---
exit_group(2)   = ?
+++ exited with 2 +++

When using the linux-image-3.16.0-4-686-pae:i386 3.16.7-ckt11-1+deb8u6
kernel - which is working:

select(10, [4 6 7 8 9], NULL, NULL, NULL) = 1 (in [6])
recvfrom(6, "\1\f\0\244", 4, MSG_PEEK, {sa_family=AF_INET,
sin_port=htons(39163), sin_addr=inet_addr("192.168.20.25")}, [16]) = 4
getsockname(6, {sa_family=AF_INET, sin_port=htons(1812),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
recvfrom(6, "\1\f\0\244", 4, MSG_PEEK, {sa_family=AF_INET,
sin_port=htons(39163), sin_addr=inet_addr("192.168.20.25")}, [16]) = 4
getsockname(6, {sa_family=AF_INET, sin_port=htons(1812),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
recvmsg(6, {msg_name(16)={sa_family=AF_INET, sin_port=htons(39163),
sin_addr=inet_addr("192.168.20.25")},
msg_iov(1)=[{"\1\f\0\244_\7\317Y\232\343U\306\6
\\\312\31\2775\315\1\10nobody\4\6\300\250"..., 164}], msg_controllen=24,
{cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 164

I don't have any clue as to what change has caused the problem though..

/Andreas Sundstrom


-- Package-specific info:
** Version:
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u1
(2015-12-14)

** Command line:
root=UUID=4692e988-b453-4884-bbf0-43c29565b821 ro  quiet

** Not tainted

** Kernel log:
[1.558784] xenbus_probe_frontend: Device with no driver:
device/vbd/51760
[1.558785] xenbus_probe_frontend: Device with no driver:
device/vbd/51776
[1.558786] xenbus_probe_frontend: Device with no driver:
device/vbd/51792
[1.558787] xenbus_probe_frontend: Device with no driver:
device/vbd/51808
[1.558788] xenbus_probe_frontend: Device with no driver:
device/vbd/51824
[1.558789] xenbus_probe_frontend: Device with no driver:
device/vbd/51840
[1.558790] xenbus_probe_frontend: Device with no driver:
device/vbd/51856
[1.558791] xenbus_probe_frontend: Device with no driver: device/vif/0
[1.558871] rtc_hctosys: unable to open rtc device (rtc0)
[1.558896] PM: Hibernation image not present or could not be loaded.
[1.559264] Freeing unused kernel memory: 656K (c1671000 - c1715000)
[1.560167] Write protecting the kernel text: 4612k
[1.560455] Write protecting the kernel read-only data: 1456k
[1.560457] NX-protecting the kernel data: 3580k
[1.579136] systemd-udevd[63]: starting version 215
[1.579513] random: systemd-udevd urandom read with 16 bits of
entropy available
[1.591625] xen_netfront: Initialising Xen virtual ethernet driver
[1.615196] blkfront: xvda: barrier or flush: disabled; persistent
grants: enabled; indirect descriptors: enabled;
[1.617050]  xvda: unknown partition table
[1.629571] blkfront: xvdc: barrier or flush: disabled; persistent
grants: enabled; indirect descriptors: enabled;
[1.678369]  xvdc: unknown partition table
[1.696112] blkfront: xvdd: barrier or flush: disabled; persistent
grants: enabled; indirect descriptors: enabled;
[1.704598]  xvdd: unknown partition table
[1.705035] Setting capacity to 2097152
[1.705039] xvdc: detected capacity change from 0 to 1073741824
[1.711299] blkfront: xvde: barrier or flush: disabled; persistent
grants: enabled; indirect descriptors: enabled;

Bug#799480: grub-xen-host: XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

Citerar Ian Campbell :


Actually, I just spotted:
(XEN) domain_crash_sync called from entry.S: fault at  
82d08021feb0 compat_create_bounce_frame+0xc6/0xde


where compat == 32-bit, so that bit is correct.

So I think the large register values are a red-herring.

I think it would be worth reporting this to upstream (both Xen and Grub),
would you mind doing so?


Ok, I will try my best.

/Andreas

Bug#799583: graphdefang.cgi is not working with current perl CGI version

[Andreas Sundstrom]

Package: graphdefang
Version: 2.75-1
Severity: important
Tags: patch

Dear Maintainer,

Trying to use graphdefang.cgi from browser gives error message:
Undefined subroutine ::startform called at 
/usr/lib/cgi-bin/graphdefang.cgi line 116.

According to http://perldoc.perl.org/CGI.html startform()/endform() are
now called start_form()/end_form()

I tried just to change this and it works after that.
Including a small patch to show what I did to make it work

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (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
Init: systemd (via /run/systemd/system)

Versions of packages graphdefang depends on:
ii  libfile-readbackwards-perl  1.05-1
ii  libgd-graph-perl1.48-2
ii  libgd-text-perl 0.86-9
ii  libmldbm-perl   2.05-1
ii  libtimedate-perl2.3000-2
ii  perl [libstorable-perl] 5.20.2-3+deb8u1

Versions of packages graphdefang recommends:
ii  php5  5.6.13+dfsg-0+deb8u1

Versions of packages graphdefang suggests:
ii  mimedefang  2.75-1

-- Configuration Files:
/etc/graphdefang/graphdefang-config changed [not included]

-- no debconf information

/Andreas
--- /usr/lib/cgi-bin/graphdefang.cgi~	2014-10-13 15:47:58.0 +0200
+++ /usr/lib/cgi-bin/graphdefang.cgi	2015-09-20 17:16:42.393846554 +0200
@@ -113,7 +113,7 @@
 		 -expires=>'now');
 	print start_html(-title=>'GraphDefang CGI Interface');
 	print h2('Select graph attributes and click the Submit button');
-	print startform();
+	print start_form();
 	print "\n";
 	print "  \n";
 	print "Data Types\n";
@@ -198,7 +198,7 @@
 	print "\n";
 	print submit(-value=>'Submit');
 	print hidden(-name=>'submit', 'default'=>['1']);
-	print endform();
+	print end_form();
 	print "\n" if (param('submit') && !$error);
 	if ($error) {
 		print "$error";

Bug#799480: grub-xen-host: XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

On 2015-09-20 18:51, Ian Campbell wrote:
> On Sat, 2015-09-19 at 18:49 +0200, Andreas Sundstrom wrote:
>> Package: grub-xen-host
>> Version: 2.02~beta2-22
>> Severity: important
>>
>> Dear Maintainer,
>>
>> Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
>> fail when chainloading the domU's grub. 64-bit domU seem to work 100%
>> of the time.
> Which grub are you starting with from dom0?
>
> If you want to boot a 32-bit guest (which includes chainloading a 32
> -bit grub) then you must start with the 32-bit grub-i386-xen.bin grub
> binary to create a 32-bit guest.
>
> kexecing from 64-bit to 32-bit is not possible in the general case. In
> fact I thought it was _impossible_ in all cases and would have ruled it
> out as something you might be doing, except some of these registers
> look like 64-bit values:

As you say it has not been possible at any time to use 64-bit grub from
dom0 and then load either 32-bit grub or linux kernel from domU.

I am using /usr/lib/grub-xen/grub-i386-xen.bin when I start my i386 domU's

Thanks for your great blog entry about this by the way:
https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/
I have used it to get a better understanding of the whole process.
>> (XEN) rax:    rbx:    rcx:
> 
>> (XEN) rdx:    rsi: 00499000   rdi: 0080
>> (XEN) rbp: 000a   rsp: 005a5ff0   r8:  
>> (XEN) r9:     r10: 83023e9b9000   r11: 83023e9b9000
>> (XEN) r12: 033f3d335bfb   r13: 82d080300800   r14: 82d0802ea940
>> (XEN) r15: 83005e819000   cr0: 8005003b   cr4: 000506f0
>> (XEN) cr3: 000200b7a000   cr2: 
Well I don't know but I guess the XEN hypervisor is always running in
64-bit mode yes?
I suppose that maybe even if the domU is 32-bit any errors showing up in
"xl dmesg"
reflects the mode that the hypervisor is run in?

/Andreas

Bug#799480: grub-xen-host: XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

Package: grub-xen-host
Version: 2.02~beta2-22
Severity: important

Dear Maintainer,

Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
fail when chainloading the domU's grub. 64-bit domU seem to work 100%
of the time.

My understanding of the process:
* dom0 launches domU with grub that is loaded from dom0's disk.
* Grub reads config file from memdisk, and then looks for grub binary
  in domU filesystem.
* If grub is found in domU it then chainloads (multiboot) that grub
  binary and the domU grub reads grub.cfg and continue booting.
* If grub is _not_ found in domU it reads grub.cfg and continues with
  boot.

It fails at step 3 in my list of the boot process, but sometimes it
does work so it may be something like a race condition that causes the
problem?

A workaround is to not install or rename /boot/xen in domU so that the
first grub that is loaded from dom0's disk will not find the grub
binary in the domU filesystem and hence continues to read grub.cfg and
boot. The drawback of this is of course that the two versions can't
differ too much as there are different setups creating grub.cfg and
then reading/parsing it at boot time.

I am not sure at this point whether this is a problem in XEN or a
problem in grub but I compiled the legacy pvgrub that uses some minios
from XEN (don't really know much more about it) and when that legacy
pvgrub chainloads the domU grub it seems to work 100% of the time. Now
the legace pvgrub is not a real alternative as it's not packaged for
Debian though.

When it fails "xl create vm -c" outputs this:
Parsing config from /etc/xen/vm
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain type for 
domid=16
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] 
exited with error status 1

And "xl dmesg" shows errors like this:
(XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from 
0x to 0x.
(XEN) d16:v0: unhandled page fault (ec=0010)
(XEN) Pagetable walk from :
(XEN)  L4[0x000] = 000200256027 049c
(XEN)  L3[0x000] = 000200255027 049d
(XEN)  L2[0x000] = 000200251023 04a1
(XEN)  L1[0x000] =  
(XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0 
compat_create_bounce_frame+0xc6/0xde
(XEN) Domain 16 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.4.1  x86_64  debug=n  Not tainted ]
(XEN) CPU:0
(XEN) RIP:e019:[<>]
(XEN) RFLAGS: 0246   EM: 1   CONTEXT: pv guest
(XEN) rax:    rbx:    rcx: 
(XEN) rdx:    rsi: 00499000   rdi: 0080
(XEN) rbp: 000a   rsp: 005a5ff0   r8:  
(XEN) r9:     r10: 83023e9b9000   r11: 83023e9b9000
(XEN) r12: 033f3d335bfb   r13: 82d080300800   r14: 82d0802ea940
(XEN) r15: 83005e819000   cr0: 8005003b   cr4: 000506f0
(XEN) cr3: 000200b7a000   cr2: 
(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
(XEN) Guest stack trace from esp=005a5ff0:
(XEN)   0010  0001e019 00010046 0016b38b 0016b38a 0016b389 0016b388
(XEN)   0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381 0016b380
(XEN)   0016b37f 0016b37e 0016b37d 0016b37c 0016b37b 0016b37a 0016b379 0016b378
(XEN)   0016b377 0016b376 0016b375 0016b374 0016b373 0016b372 0016b371 0016b370
(XEN)   0016b36f 0016b36e 0016b36d 0016b36c 0016b36b 0016b36a 0016b369 0016b368
(XEN)   0016b367 0016b366 0016b365 0016b364 0016b363 0016b362 0016b361 0016b360
(XEN)   0016b35f 0016b35e 0016b35d 0016b35c 0016b35b 0016b35a 0016b359 0016b358
(XEN)   0016b357 0016b356 0016b355 0016b354 0016b353 0016b352 0016b351 0016b350
(XEN)   0016b34f 0016b34e 0016b34d 0016b34c 0016b34b 0016b34a 0016b349 0016b348
(XEN)   0016b347 0016b346 0016b345 0016b344 0016b343 0016b342 0016b341 0016b340
(XEN)   0016b33f 0016b33e 0016b33d 0016b33c 0016b33b 0016b33a 0016b339 0016b338
(XEN)   0016b337 0016b336 0016b335 0016b334 0016b333 0016b332 0016b331 0016b330
(XEN)   0016b32f 0016b32e 0016b32d 0016b32c 0016b32b 0016b32a 0016b329 0016b328
(XEN)   0016b327 0016b326 0016b325 0016b324 0016b323 0016b322 0016b321 0016b320
(XEN)   0016b31f 0016b31e 0016b31d 0016b31c 0016b31b 0016b31a 0016b319 0016b318
(XEN)   0016b317 0016b316 0016b315 0016b314 0016b313 0016b312 0016b311 0016b310
(XEN)   0016b30f 0016b30e 0016b30d 0016b30c 0016b30b 0016b30a 0016b309 0016b308
(XEN)   0016b307 0016b306 0016b305 0016b304 0016b303 0016b302 0016b301 0016b300
(XEN)   0016b2ff 0016b2fe 0016b2fd 0016b2fc 0016b2fb 0016b2fa 0016b2f9 0016b2f8
(XEN)   0016b2f7 0016b2f6 0016b2f5 0016b2f4 0016b2f3 0016b2f2 0016b2f1 0016b2f0

An easy way to find out which grub you are in if the machine boots is
to hit 'c' and type 'ls', only the grub from dom0 will know about
(memdisk). So when trying to 

Bug#762547: oss-compat: Upgrade to compat_2+deb7u1 fails during configure

[Andreas Sundstrom]

Package: oss-compat
Version: 2+deb7u1
Severity: serious
Justification: Policy 6.1

Dear Maintainer,
I just upgraded my machine and that included oss-compat.
During the dpkg configuration phase it failed.

Here's the output from the session:
(Reading database ... 271246 files and directories currently installed.)
Preparing to replace libsnmp-base 5.4.3~dfsg-2.8 (using 
.../libsnmp-base_5.4.3~dfsg-2.8+deb7u1_all.deb) ...
Unpacking replacement libsnmp-base ...
Preparing to replace libsnmp-dev 5.4.3~dfsg-2.8 (using 
.../libsnmp-dev_5.4.3~dfsg-2.8+deb7u1_amd64.deb) ...
Unpacking replacement libsnmp-dev ...
Preparing to replace libsnmp-perl 5.4.3~dfsg-2.8 (using 
.../libsnmp-perl_5.4.3~dfsg-2.8+deb7u1_amd64.deb) ...
Unpacking replacement libsnmp-perl ...
Preparing to replace libsnmp15 5.4.3~dfsg-2.8 (using 
.../libsnmp15_5.4.3~dfsg-2.8+deb7u1_amd64.deb) ...
Unpacking replacement libsnmp15 ...
Preparing to replace snmp 5.4.3~dfsg-2.8 (using 
.../snmp_5.4.3~dfsg-2.8+deb7u1_amd64.deb) ...
Unpacking replacement snmp ...
Preparing to replace oss-compat 2 (using .../oss-compat_2+deb7u1_amd64.deb) ...
Unpacking replacement oss-compat ...
Processing triggers for man-db ...
Setting up libsnmp-base (5.4.3~dfsg-2.8+deb7u1) ...
Setting up libsnmp15 (5.4.3~dfsg-2.8+deb7u1) ...
Setting up libsnmp-perl (5.4.3~dfsg-2.8+deb7u1) ...
Setting up libsnmp-dev (5.4.3~dfsg-2.8+deb7u1) ...
Setting up snmp (5.4.3~dfsg-2.8+deb7u1) ...
Setting up oss-compat (2+deb7u1) ...
cp: missing destination file operand after `/lib/oss-compat/linux'
Try `cp --help' for more information.
dpkg: error processing oss-compat (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 oss-compat
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up oss-compat (2+deb7u1) ...
cp: missing destination file operand after `/lib/oss-compat/linux'
Try `cp --help' for more information.
dpkg: error processing oss-compat (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 oss-compat


My guess is that the problem is in:
/var/lib/dpkg/info/oss-compat.postinst

On line 36:
[ -f ${curconffile} ]  [ $(md5sum ${curconffile} | cut -d\  -f1) = 
88222606b0a3ba8b0825c5000c754e6f ]  cp /lib/oss-compat/linux ${conffile}

${conffile} is not mentioned in any other places in that script, so if it's not 
being set somewhere else that would be the reason for the cp command to fail.

I have not yet tried to fix the issue but I suspect that a purge/re-install 
would to the trick..


-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages oss-compat depends on:
ii  kmod  9-3

oss-compat recommends no packages.

oss-compat 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#726798: amanda-server: amcheck -M email does not work

[Andreas Sundstrom]

Package: amanda-server
Version: 1:3.3.1-4
Severity: normal
Tags: patch

amcheck -M email conf does not work.
It spawns a mail process but fail to provide the email on the arg list

I have found the issue and a patch is attached..

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
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 amanda-server depends on:
pn  amanda-common  none
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1
ii  libc6  2.13-38
ii  libcomerr2 1.42.5-1.1
ii  libcurl3   7.26.0-1+wheezy4
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
ii  libk5crypto3   1.10.1+dfsg-5+deb7u1
ii  libkrb5-3  1.10.1+dfsg-5+deb7u1
ii  libkrb5support01.10.1+dfsg-5+deb7u1
ii  libssl1.0.01.0.1e-2

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
pn  amanda-client  none
ii  cpio   2.11+dfsg-0.1
pn  gnuplotnone
ii  mt-st  1.1-4
ii  perl [perl5]   5.14.2-21+deb7u1

-- no debconf information
Description: Fix amcheck -M

--- amanda-3.3.1.orig/server-src/amcheck.c
+++ amanda-3.3.1/server-src/amcheck.c
@@ -448,8 +448,8 @@ main(
 	}
 	if(mailto) {
 	a = (char **) g_new0(char *, 2);
-	a[1] = stralloc(mailto);
-	a[2] = NULL;
+	a[0] = stralloc(mailto);
+	a[1] = NULL;
 	} else {
 	/* (note that validate_mailto doesn't allow any quotes, so this
 	 * is really just splitting regular old strings) */

Bug#723656: xen-hypervisor-4.1-amd64: IPMI serial console hangs

[Andreas Sundstrom]

Package: xen-hypervisor-4.1-amd64
Version: 4.1.4-3+deb7u1
Severity: important

Dear Maintainer,

Just upgraded a Supermicro server (X9SCM-F motherboard) from Squeeze
to Wheezy. And now the IPMI serial console no longer work as it used
to.

It hangs like this:
[...]
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  - Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(

Xen cmdline:
placeholder dom0_max_vcpus=2 dom0_vcpus_pin dom0_mem=2048M 
com1=115200,8n1,0x3e8,4 console=com1,vga

Linux cmdline:
placeholder root=/dev/mapper/vg01-root ro console=hvc0 earlyprintk=xen quiet


It looks very similar to this, not sure if they are the same though..
http://old-list-archives.xenproject.org/archives/html/xen-devel/2010-01/msg00773.html


-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
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

xen-hypervisor-4.1-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.1-amd64 recommends:
ii  xen-utils-4.1  4.1.4-3+deb7u1

Versions of packages xen-hypervisor-4.1-amd64 suggests:
ii  xen-docs-4.1  4.1.4-3+deb7u1

-- 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#702046: [Pkg-xen-devel] Bug#702046: xen-utils-4.0: PyGrub VM Boot fails after xen-utils 4.0.1-5.6 - 4.0.1-5.7 Update

[Andreas Sundstrom]

Patch works for me as well.

/Andreas


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

Bug#695944: centerim-utf8: crash when signing in to MSN

[Andreas Sundstrom]

Package: centerim-utf8
Version: 4.22.10-1
Severity: important
Tags: patch

When I sign in to MSN centerim often segfaults.
After looking into the issue it seems to be due to a missing field in a
response from the MSN server.

args[5] here from notificationserver.cpp line ~200 will be undefined since
the vector only has 5 entries:
this-myNotificationServer()-externalCallbacks.gotNewReverseListEntry(this, \
args[4], decodeURL(args[5]));

This is because the MSN server is sometimes sending:
ADD 0 RL 0 user.n...@example.com 

Instead of this:
ADD 0 RL 0 user.n...@example.com User%20Name

So my quick fix to this (without any knowledge on the MSN protocol) was to
copy user.n...@example.com to args[5] and that way avoiding the segfault.

I'm attaching an patch that shows how I solved my issue.

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages centerim-utf8 depends on:
ii  centerim-common  4.22.10-1   A text-mode multi-protocol instant
ii  libc62.11.3-4Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls  7.21.0-2.1+squeeze2 Multi-protocol file transfer libra
ii  libgcc1  1:4.4.5-8   GCC support library
ii  libgnutls26  2.8.6-1+squeeze2the GNU TLS library - runtime libr
ii  libgpg-error01.6-1   library for common error values an
ii  libgpgme11   1.2.0-1.2   GPGME - GnuPG Made Easy
ii  libncursesw5 5.7+20100313-5  shared libraries for terminal hand
ii  libstdc++6   4.4.5-8 The GNU Standard C++ Library v3

Versions of packages centerim-utf8 recommends:
ii  lynx-cur [www-browser]  2.8.8dev.5-1 Text-mode WWW Browser with NLS sup
pn  sox none   (no description available)
ii  w3m [www-browser]   0.5.2-9  WWW browsable pager with excellent

centerim-utf8 suggests no packages.

-- no debconf information
--- tmp/centerim-4.22.10/libmsn/msn/notificationserver.cpp  2010-10-26 
19:19:06.0 +0200
+++ centerim-4.22.10/libmsn/msn/notificationserver.cpp  2012-12-13 
23:13:09.0 +0100
@@ -191,9 +191,14 @@
 
 void NotificationServerConnection::handle_ADD(std::vectorstd::string  
args)
 {
+   //std::cerr  DEBUG handle_ADD size:   args.size()  std::endl;
 this-assertConnectionStateIsAtLeast(NS_CONNECTED);
 if (args[2] == RL)
 {
+   if (args.size() == 5)
+   {
+   args.push_back(args[4]);
+   }
 
this-myNotificationServer()-externalCallbacks.gotNewReverseListEntry(this, 
args[4], decodeURL(args[5]));
 }
 else

Bug#619315: linux-image-2.6.32-5-686: Mouse pointer invisible with new kernel (intel graphics)

[Andreas Sundstrom]

Package: linux-2.6
Version: 2.6.32-31
Severity: important


With kernel version 2.6.32-30 mouse pointer works as normal.
With the newer kernel 2.6.32-31 the mouse pointer is not visible.

I can see that the pointer is there by 'hovering' above buttons that change 
colour
when 'hovering' above them. It's just not visible.

Reverting to 2.6.32-30 fixes the problem.

I see in the changelog that some changes relate to the i915 driver, so my guess
would be that some change there is the cause for the problem.

-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-31) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Mar 8 21:36:00 UTC 2011

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-5-686 root=/dev/mapper/swe248_deb-root ro quiet

** Not tainted

** Kernel log:
[9.386596] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing 
generic driver
[9.386787] Console: switching to colour dummy device 80x25
[9.388057] Console: switching to colour frame buffer device 128x48
[9.393611] phy0: Selected rate control algorithm 'minstrel'
[9.394673] ath5k phy0: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
[9.394678] ath5k phy0: RF5111 5GHz radio found (0x17)
[9.394681] ath5k phy0: RF2111 2GHz radio found (0x23)
[9.394776] cfg80211: Calling CRDA for country: US
[9.395174] yenta_cardbus :01:0a.0: CardBus bridge found [10cf:10e6]
[9.395195] yenta_cardbus :01:0a.0: O2: res at 0x94/0xD4: ea/00
[9.395198] yenta_cardbus :01:0a.0: Yenta O2: old bridge, disabling read 
prefetch/write burst
[9.443757] fb0: inteldrmfb frame buffer device
[9.443761] registered panic notifier
[9.443852] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[9.512663] Intel ICH :00:1f.5: PCI INT B - Link[LNKB] - GSI 11 
(level, low) - IRQ 11
[9.512699] Intel ICH :00:1f.5: setting latency timer to 64
[9.521337] yenta_cardbus :01:0a.0: ISA IRQ mask 0x0438, PCI irq 11
[9.521342] yenta_cardbus :01:0a.0: Socket status: 3006
[9.521353] yenta_cardbus :01:0a.0: pcmcia: parent PCI bridge I/O 
window: 0x2000 - 0x2fff
[9.521359] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x2000-0x2fff: 
clean.
[9.521674] yenta_cardbus :01:0a.0: pcmcia: parent PCI bridge Memory 
window: 0xd020 - 0xd02f
[9.521679] yenta_cardbus :01:0a.0: pcmcia: parent PCI bridge Memory 
window: 0x3000 - 0x37ff
[9.522209] yenta_cardbus :01:0a.1: CardBus bridge found [10cf:10e6]
[9.648972] yenta_cardbus :01:0a.1: ISA IRQ mask 0x0438, PCI irq 11
[9.648976] yenta_cardbus :01:0a.1: Socket status: 3006
[9.648981] pci_bus :01: Raising subordinate bus# of parent bus (#01) 
from #03 to #06
[9.648990] yenta_cardbus :01:0a.1: pcmcia: parent PCI bridge I/O 
window: 0x2000 - 0x2fff
[9.648995] pcmcia_socket pcmcia_socket1: cs: IO port probe 0x2000-0x2fff: 
clean.
[9.649310] yenta_cardbus :01:0a.1: pcmcia: parent PCI bridge Memory 
window: 0xd020 - 0xd02f
[9.649315] yenta_cardbus :01:0a.1: pcmcia: parent PCI bridge Memory 
window: 0x3000 - 0x37ff
[9.764686] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: 
clean.
[9.766307] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: 
excluding 0x400-0x407
[9.766985] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: 
clean.
[9.767577] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: 
clean.
[9.768385] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: 
clean.
[   10.185284] pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3af: 
clean.
[   10.186904] pcmcia_socket pcmcia_socket1: cs: IO port probe 0x3e0-0x4ff: 
excluding 0x400-0x407
[   10.187582] pcmcia_socket pcmcia_socket1: cs: IO port probe 0x820-0x8ff: 
clean.
[   10.188413] pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcf7: 
clean.
[   10.189191] pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: 
clean.
[   10.340045] intel8x0_measure_ac97_clock: measured 55284 usecs (2664 samples)
[   10.340050] intel8x0: clocking to 48000
[   11.391412] EXT3 FS on dm-0, internal journal
[   11.722613] loop: module loaded
[   13.034848] Adding 1454072k swap on /dev/mapper/swe248_deb-swap_1.  
Priority:-1 extents:1 across:1454072k 
[   14.873922] kjournald starting.  Commit interval 5 seconds
[   14.874296] EXT3 FS on dm-5, internal journal
[   14.874303] EXT3-fs: mounted filesystem with ordered data mode.
[   14.927376] kjournald starting.  Commit interval 5 seconds
[   14.927721] EXT3 FS on dm-4, internal journal
[   14.927728] EXT3-fs: mounted filesystem with ordered data mode.
[   14.988190] kjournald starting.  Commit interval 5 seconds
[   14.988557] EXT3 FS on dm-1, internal journal
[   14.988561] EXT3-fs: mounted filesystem with ordered data mode.
[   15.052177] kjournald starting.  Commit interval 5 seconds
[   15.052558] EXT3 

Bug#610910: grub-pc: LC_MESSAGES env value is not used

[Andreas Sundstrom]

Package: grub-pc
Version: 1.98+20100804-13
Severity: minor
Tags: patch l10n

grub.cfg takes it lang setting from the LANG variable even if an
overriding value has been set with LC_MESSAGES.
People like me that want's the system to talk english but handle
swedish dates etc. may use settings like this:
$ cat /etc/default/locale
LANG=sv_SE.UTF-8
LC_MESSAGES=en_US.UTF-8

Currently update-grub will set lang to 'sv' instead of 'en' in this
case.
In my opinion grub should use the same language as other commands in
the same installation.

I have attached a patch that I use to change the behavior.

/Andreas

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

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

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]   1.5.36   Debian configuration management sy
ii  grub-common 1.98+20100804-13 GRand Unified Bootloader, version 
ii  libc6   2.11.2-9 Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1  2:1.02.48-4  The Linux Kernel Device Mapper use
ii  ucf 3.0025+nmu1  Update Configuration File: preserv

grub-pc recommends no packages.

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

-- debconf information:
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline:
  grub-pc/install_devices_empty: false
  grub-pc/install_devices_failed: false
* grub-pc/chainload_from_menu.lst: true
  grub-pc/kopt_extracted: true
* grub-pc/install_devices: /dev/disk/by-id/ata-IC25N020ATDA04-0_63A630B8868
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_disks_changed:
  grub2/linux_cmdline_default: quiet
  grub-pc/mixed_legacy_and_grub2: true
--- etc/grub.d/00_header~   2011-01-04 15:33:02.0 +0100
+++ etc/grub.d/00_header2011-01-23 22:13:52.0 +0100
@@ -23,7 +23,11 @@
 exec_prefix=${prefix}
 libdir=${exec_prefix}/lib
 locale_dir=`echo ${GRUB_PREFIX}/locale | sed ${transform}`
-grub_lang=`echo $LANG | cut -d _ -f 1`
+if [ ! -z $LC_MESSAGES ]; then
+grub_lang=`echo $LC_MESSAGES | cut -d _ -f 1`
+else
+grub_lang=`echo $LANG | cut -d _ -f 1`
+fi
 
 . ${libdir}/grub/grub-mkconfig_lib
 
@@ -206,7 +210,7 @@
 fi
 
 # Gettext variables and module
-if [ x${LANG} != xC ]  [ -d ${locale_dir} ] ; then
+if [ x${grub_lang} != xC ]  [ -d ${locale_dir} ] ; then
 prepare_grub_to_access_device $(${grub_probe} --target=device 
${locale_dir})
   cat  EOF
 set locale_dir=(\$root)$(make_system_path_relative_to_its_root ${locale_dir})

Bug#436912: -s option reset pwgen_flags if entered after another option

[Andreas Sundstrom]

Package: pwgen
Version: 2.06-1
Severity: normal
Tags: patch


When using the -s option it can nullify other options if it is entered 
after the other named option.


Try for example -y -s and -s -y they are not the same.

Here is the fix (I think):
--- pwgen-2.06.orig/pwgen.c
+++ pwgen-2.06/pwgen.c
@@ -138,7 +138,7 @@
   break;
   case 's':
   pwgen = pw_rand;
-   pwgen_flags = PW_DIGITS | PW_UPPERS;
+   pwgen_flags |= PW_DIGITS | PW_UPPERS;
   break;
   case 'C':
   do_columns = 1;


I use this command often and it's a great help for my daily work, so 
thanks for writing it.


/Andreas Sundstrom



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

Bug#360555: tinyca: Revoke certificate doesn't really work

[Andreas Sundstrom]

The following patch fixes it for me.
I found the fix on upstreams CVS:
http://tinyca.dyndns.org/cvs-bin/viewcvs.cgi/lib/OpenSSL.pm.diff?r1=1.7r2=1.9diff_format=hcvsroot=TinyCA2

diff -u -r1.7 -r1.9
--- lib/OpenSSL.pm2006/02/16 21:18:431.7
+++ lib/OpenSSL.pm2006/04/13 14:14:401.9
@@ -1,6 +1,6 @@
# Copyright (c) Stephan Martin [EMAIL PROTECTED]
#
-# $Id: OpenSSL.pm,v 1.7 2006/02/16 21:18:43 sm Exp $
+# $Id: OpenSSL.pm,v 1.9 2006/04/13 14:14:40 sm Exp $
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -41,18 +41,16 @@
   my $v = TEST;
   close(TEST);

-   if($v =~ /0.9.6/) {
-  $self-{'version'} = 0.9.6;
-   } elsif ($v =~ /0.9.7/) {
-  $self-{'version'} = 0.9.7;
-   } elsif ($v =~ /0.9.8/) {
-  $self-{'version'} = 0.9.8;
+   # set version (format: e.g. 0.9.7 or 0.9.7a)
+   if($v =~ /\b(0\.9\.[678][a-z]?)\b/) {
+  $self-{'version'} = $1;
   }

-   if($v =~ /0.9.7f/ || $v =~ /0.9.7g/ || $v =~ /0.9.7h/)  {
-  $self-{'broken'} = 0;
-   } else {
-  $self-{'broken'} = 1;
+   # CRL output was broken before openssl 0.9.7f  
+   if($v =~ /\b0\.9\.[0-6][a-z]?\b/ || $v =~ /\b0\.9\.7[a-e]?\b/)  {

+  $self-{'broken'} = 1;
+   } else {
+  $self-{'broken'} = 0;
   }

   bless($self, $class);

/Andreas Sundstrom


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

Bug#348436: Fixed upstream

[Andreas Sundstrom]

This is apparantly fixed in the new upstream version (2.0.10)

bug #1349326 ulogd option does not work. There was a typo in the class
iptAdvancedDialog ( 'useULOG' instead of 'use_ULOG' )

/Andreas


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

Bug#348436: fwbuilder: Can't set logging to ULOG

[Andreas Sundstrom]

Package: fwbuilder
Version: 2.0.9-1+b1
Severity: important

The GUI seems to set the ULOG parameter wrong in the .fwb file
If I set it to use ULOG this gets set:
Option name=useULOGTrue/Option

I had a look at an older .fwb file and found out that it should be
Option name=use_ULOGTrue/Option

Notice the underscore _

My guess is that it's a typo 

A workaround is to manually set it with an underscore in the .fwb file
Adding/removing normal rules doesn't seem to change it back.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1
Locale: LANG=sv_SE.ISO-8859-1, LC_CTYPE=sv_SE.ISO-8859-1 (charmap=ISO-8859-1)

Versions of packages fwbuilder depends on:
ii  fwbuilder-common 2.0.9-1 Firewall administration tool GUI (
ii  fwbuilder-linux [fwbuild 2.0.9-1+b1  Firewall Builder policy compiler(s
ii  libc62.3.5-8 GNU C Library: Shared libraries an
ii  libfwbuilder6c2a 2.0.9-3.2   Firewall Builder API library
ii  libgcc1  1:4.0.2-5   GCC support library
ii  libqt3-mt3:3.3.5-3   Qt GUI Library (Threaded runtime v
ii  libsnmp9 5.2.1.2-4   NET SNMP (Simple Network Managemen
ii  libssl0.9.8  0.9.8a-5SSL shared libraries
ii  libstdc++6   4.0.2-5 The GNU Standard C++ Library v3
ii  libwrap0 7.6.dbs-8   Wietse Venema's TCP wrappers libra
ii  libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li
ii  libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte
ii  libxml2  2.6.23-1.1  GNOME XML library
ii  libxslt1.1   1.1.15-2XSLT processing library - runtime 
ii  zlib1g   1:1.2.3-9   compression library - runtime

fwbuilder recommends no packages.

-- no debconf information


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

Bug#343671: udev: LVM snapshots don't work

[Andreas Sundstrom]

Marco d'Itri wrote:
 On Dec 17, Andreas Sundstrom [EMAIL PROTECTED] wrote:
 
 
matrix:/home/sunkan# /sbin/lvm lvcreate -s -L 1G -n var_s /dev/3ware/var
  LV 3ware/var_s in use: not removing
 
 Find why it's in use then.
 

It's not that simple unfortunately.. It's not created when I run that
command. Everything is 100% reproducible for me here.. I've tried it
numerous times before submitting the bug.

Any ideas on how to diagnose the problem?


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

Bug#343671: udev: LVM snapshots don't work

[Andreas Sundstrom]

Marco d'Itri wrote:
 On Dec 17, Andreas Sundstrom [EMAIL PROTECTED] wrote:
 
 
matrix:/home/sunkan# /sbin/lvm lvcreate -s -L 1G -n var_s /dev/3ware/var
  LV 3ware/var_s in use: not removing
 
 Find why it's in use then.
 

After a quick test it seems that reverting this change back to how it
was in 0.071 fixes it.

matrix:/# diff -u /etc/udev/udev.rules~ /etc/udev/udev.rules
--- /etc/udev/udev.rules~   2005-12-17 02:13:53.0 +0100
+++ /etc/udev/udev.rules2005-12-17 11:08:03.0 +0100
@@ -93,6 +93,6 @@
 SUBSYSTEM==aoe, KERNEL==interfaces,NAME=etherd/%k

 # device mapper creates its own device nodes, so ignore these
-KERNEL==dm-[0-9]*,   NAME=
+KERNEL==dm-[0-9]*,   OPTIONS+=ignore_device
 KERNEL==device-mapper,   NAME=mapper/control

Do you know the background to why this has changed?
I can't notice any other change in behaviour except that snapshotting
fails for some reason I don't quite understand.


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

Bug#343671: udev: LVM snapshots don't work

[Andreas Sundstrom]

Package: udev
Version: 0.076-6
Severity: normal

with newest udev from testing I get the following error when trying to do an 
LVM snapshot:

matrix:/home/sunkan# /sbin/lvm lvcreate -s -L 1G -n var_s /dev/3ware/var
  LV 3ware/var_s in use: not removing
  Couldn't deactivate new snapshot.

It works if I go back to 0.071-1 which is what I was using earlier.

I'm running on a sarge system but with a kernel I have compiled myself and udev 
recompiled from testing


-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 0
lrwxrwxrwx  1 root root 20 2005-09-24 17:48 020_permissions.rules - 
../permissions.rules
lrwxrwxrwx  1 root root 19 2005-09-24 17:48 cd-aliases.rules - 
../cd-aliases.rules
lrwxrwxrwx  1 root root 13 2005-09-24 17:48 udev.rules - ../udev.rules
lrwxrwxrwx  1 root root 19 2005-09-26 20:21 z20_persistent.rules - 
../persistent.rules
lrwxrwxrwx  1 root root 12 2005-09-24 17:48 z50_run.rules - ../run.rules
lrwxrwxrwx  1 root root 16 2005-11-12 14:54 z55_hotplug.rules - 
../hotplug.rules
lrwxrwxrwx  1 root root 17 2005-09-24 17:48 z70_hotplugd.rules - 
../hotplugd.rules

-- /sys/:
/sys/block/dm-0/dev
/sys/block/dm-10/dev
/sys/block/dm-1/dev
/sys/block/dm-2/dev
/sys/block/dm-3/dev
/sys/block/dm-4/dev
/sys/block/dm-5/dev
/sys/block/dm-6/dev
/sys/block/dm-7/dev
/sys/block/dm-8/dev
/sys/block/dm-9/dev
/sys/block/fd0/dev
/sys/block/hda/dev
/sys/block/loop0/dev
/sys/block/loop1/dev
/sys/block/loop2/dev
/sys/block/loop3/dev
/sys/block/loop4/dev
/sys/block/loop5/dev
/sys/block/loop6/dev
/sys/block/loop7/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/class/input/event0/dev
/sys/class/input/mice/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/hpet/dev
/sys/class/misc/rtc/dev
/sys/class/misc/tun/dev
/sys/class/misc/watchdog/dev
/sys/class/scsi_generic/sg0/dev
/sys/class/scsi_generic/sg1/dev
/sys/class/scsi_tape/nst0a/dev
/sys/class/scsi_tape/nst0/dev
/sys/class/scsi_tape/nst0l/dev
/sys/class/scsi_tape/nst0m/dev
/sys/class/scsi_tape/st0a/dev
/sys/class/scsi_tape/st0/dev
/sys/class/scsi_tape/st0l/dev
/sys/class/scsi_tape/st0m/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev2.1/dev
/sys/class/usb_device/usbdev3.1/dev
/sys/class/usb_device/usbdev4.1/dev
/sys/class/usb_device/usbdev5.1/dev

-- Kernel configuration:
 isapnp_init not present.


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.14.4
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages udev depends on:
ii  initscripts 2.86.ds1-1   Standard scripts needed for bootin
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libselinux1 1.22-1   SELinux shared libraries
ii  lsb-base3.0-11   Linux Standard Base 3.0 init scrip
ii  makedev 2.3.1-77 creates device files in /dev
ii  sed 4.1.2-8  The GNU sed stream editor

-- no debconf information


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

Bug#341926: libpam-krb5: ccache parameter is being ignored

[Andreas Sundstrom]

Package: libpam-krb5
Version: 1.2.0-1
Severity: important

Since the update to 1.2.0-1 went into testing I cannot authenticate to NFS 
anymore.
This is due to the fact that even thought common-auth has the following line:
auth sufficient pam_krb5.o ccache=/tmp/krb5cc_%u ignore_root

klist shows that the Ticket cache is in /tmp/krb5cc_1000_XX

The version of rpc.gssd that I am using cannot find this and authentication 
then fails

I saw the author had removed support for the ccache parameter.
But your reimplementiation doesnt work for me.

/Andreas Sundstrom

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (430, 'stable'), (400, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.3
Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)

Versions of packages libpam-krb5 depends on:
ii  libc6 2.3.5-8GNU C Library: Shared libraries an
ii  libcomerr21.38-2 common error description library
ii  libkrb53  1.3.6-5MIT Kerberos runtime libraries
ii  libpam0g  0.79-3 Pluggable Authentication Modules l

libpam-krb5 recommends no packages.

-- no debconf information


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

Bug#341926: libpam-krb5: ccache parameter is being ignored

[Andreas Sundstrom]

Russ Allbery wrote:
 Andreas Sundstrom [EMAIL PROTECTED] writes:
 
 
Package: libpam-krb5
Version: 1.2.0-1
Severity: important
 
 
Since the update to 1.2.0-1 went into testing I cannot authenticate to
NFS anymore.  This is due to the fact that even thought common-auth has
the following line:
 
 
auth sufficient pam_krb5.o ccache=/tmp/krb5cc_%u ignore_root
 
 
 You have to specify ccache in the session line in common-session.  I'm
 guessing that's the problem.  (In the new version of pam_krb5,
 responsibility for establishing the final user ticket cache is the
 province of the session module.)
 
 I'll put a NEWS entry into the next release so that people will hopefully
 be aware of that.
 
 Let me know if that fixes the problem.
 

It works.
Thanks for the help.

/Andreas



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

Bug#334426: tar incorrectly handles sparse archives, upstream patch available, or downgrade is fix...

[Andreas Sundstrom]

 On Mon, 2005-10-17 at 14:36 -0600, Michael Loftis wrote:
 Package: tar
 Version: 1.14-2
 Severity: important
 
 ...
 ./htdocs/nationwide/themes/templates/
 ./htdocs/nationwide/themes/templates/old_files/
 ./htdocs/nationwide/untitled/
 tar: ./htdocs/class1/test/RoomSchedSymbols.fla: invalid sparse archive
 member
 tar: Skipping to next header
 
 Is this still a problem with tar 1.15.1-2, currently in unstable?
 

No, upgrading to 1.15.1-2 fixes it.

I hope the following makes it easy for you to reproduce

$ cat test.sh
#!/bin/bash

echo   aoeu
dd if=/dev/zero of=sparse seek=10 count=1 bs=1M
echo   zaoeu

tar -cSf sparse.tar aoeu sparse zaoeu

tar -tvf sparse.tar aoeu
echo Error level: $?

tar -cf sparse.tar aoeu sparse zaoeu

tar -tvf sparse.tar aoeu
echo Error level: $?

-

[EMAIL PROTECTED]:/tmp/tar-test$ sh test.sh
1+0 records in
1+0 records out
1048576 bytes transferred in 0,003606 seconds (290781099 bytes/sec)
-rw-r--r-- sunkan/sunkan 9 2005-10-19 11:15:29 aoeu
tar: sparse: invalid sparse archive member
tar: Skipping to next header
tar: Error exit delayed from previous errors
Error level: 2
-rw-r--r-- sunkan/sunkan 9 2005-10-19 11:15:29 aoeu
Error level: 0
[EMAIL PROTECTED]:/tmp/tar-test$ su
Password:
sunkan:/tmp/tar-test# aptitude
(Reading database ... 85530 files and directories currently installed.)
Preparing to replace tar 1.14-2 (using
.../archives/tar_1.15.1-2_i386.deb) ...
Unpacking replacement tar ...
Setting up tar (1.15.1-2) ...

Press return to continue.

sunkan:/tmp/tar-test# exit
[EMAIL PROTECTED]:/tmp/tar-test$ sh test.sh
1+0 records in
1+0 records out
1048576 bytes transferred in 0,003398 seconds (308596321 bytes/sec)
-rw-r--r-- sunkan/sunkan 9 2005-10-19 11:16:54 aoeu
Error level: 0
-rw-r--r-- sunkan/sunkan 9 2005-10-19 11:16:54 aoeu
Error level: 0
[EMAIL PROTECTED]:/tmp/tar-test$

/Andreas Sundstrom


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