Bug#1068804: ntpsec-ntpdate: starts ntpd if installed, leading to delayed boot

[Ingo Saitz]

Package: ntpsec-ntpdate
Version: 1.2.3+dfsg1-1
Severity: normal

Dear Maintainer,

I observed a 3 minute timeout on boot during "Starting NTP server: ntpd"
This can easily be reproduced on a running system by calling
"invoke-rc.d ntpsec start" again.

On sysvinit systems ifupdown usually runs before the ntpsec daemon gets
started (since ntpsec depends on $network). If it brings up a static
interface, the hook script /etc/network/if-up.d/ntpsec-ntpdate will run
ntpdate and then start the ntpsec deamon regardless whether it was
running or not. Later in the init process, the ntpsec init script is run
again with start. This causes the flock call to wait for 3 minutes,
since the lock is already taken by the demon started from
ntpsec-ntpdate.

Is the flock call in /etc/init.d/ntpsec really needed since
start-stop-daemon already guards the daemon with a pidfile? If it is, 3
minutes seem a long timeout especially during bootup, and when it fails
its return code is ignored and start-stop-daemon is called anyways.

My suggestion would be to remove the flock call in /etc/init.d/ntpsec
and only use start-stop-daemon to guard against multiple starts. Other
options would be:

- in /etc/network/if-up.d/ntpsec-ntpdate test if ntpsec already was
  running and only start it again in that case.

- rework /etc/init.d/ntpsec to actually fail in case the lock could not
  be acquired, and reduce the timeout to a few seconds, or run the part
  of that script in a background shell.

I am not sure about the appropriate serverity, but adding a 3 minute
delay to the boot process (on sysvinit systems with static network
interfaces) feels like a broken boot.

Thanks,

Ingo

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.9.0-rc3-spatz20240410 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ntpsec-ntpdate depends on:
ii  netbase6.4
pn  ntpsec-ntpdig  

ntpsec-ntpdate recommends no packages.

ntpsec-ntpdate suggests no packages.

Bug#1068796: ntpsec-netpdate: starts ntpd if installed, leading to delayed boot

[Ingo Saitz]

Package: ntpsec-netpdate
Version: 1.2.3+dfsg1-1
Severity: normal

Dear Maintainer,

I observed a 3 minute timeout on boot during "Starting NTP server: ntpd"
This can easily be reproduced on a running system by calling
"invoke-rc.d ntpsec start" again.

On sysvinit systems ifupdown usually runs before the ntpsec daemon gets
started (since ntpsec depends on $network). If it brings up a static
interface, the hook script /etc/network/if-up.d/ntpsec-ntpdate will run
ntpdate and then start the ntpsec deamon regardless whether it was
running or not. Later in the init process, the ntpsec init script is run
again with start. This causes the flock call to wait for 3 minutes,
since the lock is already taken by the demon started from
ntpsec-ntpdate.

Is the flock call in /etc/init.d/ntpsec really needed since
start-stop-daemon already guards the daemon with a pidfile? If it is, 3
minutes seem a long timeout especially during bootup, and when it fails
its return code is ignored and start-stop-daemon is called anyways.

My suggestion would be to remove the flock call in /etc/init.d/ntpsec
and only use start-stop-daemon to guard against multiple starts. Other
options would be:

- in /etc/network/if-up.d/ntpsec-ntpdate test if ntpsec already was
  running and only start it again in that case.

- rework /etc/init.d/ntpsec to actually fail in case the lock could not
  be acquired, and reduce the timeout to a few seconds, or run the part
  of that script in a background shell.

I am not sure about the appropriate serverity, but adding a 3 minute
delay to the boot process (on sysvinit systems with static network
interfaces) feels like a broken boot.

Thanks,

Ingo

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.9.0-rc3-spatz20240410 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Bug#1066989: atf: descriptions swapped on library packages

[Ingo Saitz]

Source: atf
Version: 0.21-6
Severity: minor

Dear Maintainer,

$ apt-cache search libatf-c
libatf-c++-2 - Automated Test Framework (shared C library)
libatf-c-1 - Automated Test Framework (shared C++ library)

This looks like the descriptions are swapped on these two packages. I
checked the contents of the included shared libraries and indeed only
libatf-c++-2 contains C++ symbols.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.7.6-spatz20240223 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Bug#1059163: cpio: Path traversal vulnerability

[Ingo Brückl]

On Fri, 22 Dec 2023 13:43:18 +1100, Aníbal Monsalve Salazar wrote:

> I have been working on a new Debian version of cpio for the last couple
> of days. I hope to upload it today. I will appreciate it very much if
> you could give it a try after uploading it.

It looks good to me.

Regards,

Ingo

Bug#1055881: virtualbox-dkms: Linux 6.7-rc1 throws "invalid opcode" during module loading

[Ingo Saitz]

retitle 1055881 Linux 6.7-rc1 / Linux 6.6.1 UBSan errors
forwarded 1055881 https://www.virtualbox.org/ticket/21877
thanks

I found the "invalid opcode" was caused by CONFIG_UBSAN_TRAP=y, that was
set by the hardening.config from linux 6.7-rc1. Using the same options I
can reproduce the bug on 6.6.1, too.

This is also reported upstream as https://www.virtualbox.org/ticket/21877

Changing CONFIG_UBSAN_TRAP to no shows these errors in the log (see
attachment.

Sorry for the wrong noise, but I suggest to keep this bug open, since
there is no similar bug reported.

Ingo
-- 
const_cast(Λ)
[   17.127943] vboxdrv: loading out-of-tree module taints kernel.
[   17.132074] vboxdrv: Found 2 processor cores/threads
[   17.133888] 

[   17.134091] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/common/log/log.c:1791:41
[   17.134304] index 1 is out of range for type 'uint32_t [1]'
[   17.134521] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.134755] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.135004] Call Trace:
[   17.135259]  
[   17.135516]  dump_stack_lvl+0x32/0x40
[   17.135782]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.136055]  VBoxHost_RTLogGroupSettings+0x472/0x490 [vboxdrv]
[   17.136347]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.136573]  VBoxHost_RTLogCreateExV+0x27a/0x480 [vboxdrv]
[   17.136800]  VBoxHost_RTLogCreate+0x6a/0x90 [vboxdrv]
[   17.137030]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.137263]  supdrvInitDevExt+0x54/0x320 [vboxdrv]
[   17.137498]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.137738]  ? 0xc05f5000
[   17.137962]  do_one_initcall+0x8e/0x2c0
[   17.138190]  do_init_module+0x7d/0x230
[   17.138423]  init_module_from_file+0x81/0xc0
[   17.138658]  idempotent_init_module+0x119/0x230
[   17.138897]  __x64_sys_finit_module+0x4d/0x80
[   17.139140]  do_syscall_64+0x56/0xb0
[   17.139385]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.139636] RIP: 0033:0x7fb8a591eee9
[   17.139888] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.140183] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.140496] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.140814] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.141137] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.141464] R10: 0038 R11: 0246 R12: 555e4d89598b
[   17.141794] R13: 0004 R14: 555e4ea0e680 R15: 
[   17.142130]  
[   17.142471] 

[   17.142843] 

[   17.143196] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:399:33
[   17.143561] index 1 is out of range for type 'page *[1]'
[   17.143933] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.144313] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.144703] Call Trace:
[   17.145097]  
[   17.145495]  dump_stack_lvl+0x32/0x40
[   17.145902]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.146311]  rtR0MemObjLinuxAllocPages+0x325/0x340 [vboxdrv]
[   17.146746]  rtR0MemObjNativeAllocCont+0x5a/0x110 [vboxdrv]
[   17.147183]  supdrvGipCreate+0x59/0xc30 [vboxdrv]
[   17.147623]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.148068]  supdrvInitDevExt+0x148/0x320 [vboxdrv]
[   17.148516]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.148966]  ? 0xc05f5000
[   17.149401]  do_one_initcall+0x8e/0x2c0
[   17.149839]  do_init_module+0x7d/0x230
[   17.150280]  init_module_from_file+0x81/0xc0
[   17.150725]  idempotent_init_module+0x119/0x230
[   17.151177]  __x64_sys_finit_module+0x4d/0x80
[   17.151621]  do_syscall_64+0x56/0xb0
[   17.152065]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.152510] RIP: 0033:0x7fb8a591eee9
[   17.152951] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.153431] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.153925] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.154416] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.154904] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.155388] R10: 0038

Bug#1055881: virtualbox-dkms: Linux 6.7-rc1 throws "invalid opcode" during module loading

[Ingo Saitz]

Package: virtualbox-dkms
Version: 7.0.12-dfsg-1
Severity: normal

On linux 6.7-rc1 the virtualbox kernelmodules do build without problem,
but during boot the kernel throws an "illegal instruction" while loading
vboxdrv:

[   18.036170] vboxdrv: loading out-of-tree module taints kernel.
[   18.039745] vboxdrv: Found 2 processor cores/threads
[   18.040619] invalid opcode:  [#1] SMP
[   18.040828] CPU: 0 PID: 1974 Comm: modprobe Tainted: G   O   
6.7.0-rc1-pinguin20231113 #1
[   18.041044] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   18.041272] RIP: 0010:VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.041546] Code: d0 0f 84 8d fe ff ff 89 c6 85 f6 74 e5 0f 0b 41 09 8c 80 
bc 00 00 00 48 83 c0 01 48 39 d0 0f 84 70 fe ff ff 89 c6 85 f6 74 e5 <0f> 0b b9 
11 00 00 00 eb a0 8b 05 db ed 02 00 85 c0 75 1a 4c 8b 05
[   18.041840] RSP: 0018:a9a2c1e77a68 EFLAGS: 00010202
[   18.042158] RAX: 0001 RBX: c0637424 RCX: 0011
[   18.042488] RDX: 019d RSI: 0001 RDI: 0003
[   18.042822] RBP: a9a2c1e77ac8 R08: 8ee544150010 R09: c062a7e0
[   18.043167] R10: 8ee544150010 R11: 000c R12: c0637427
[   18.043397] R13: 0740 R14: a9a2c1e77c20 R15: 
[   18.043635] FS:  7f04f5145040() GS:8ee84fe0() 
knlGS:
[   18.043879] CS:  0010 DS:  ES:  CR0: 80050033
[   18.044129] CR2: 555689427660 CR3: 00010929b005 CR4: 000706f0
[   18.044386] Call Trace:
[   18.044646]  
[   18.044909]  ? die+0x2d/0x80
[   18.045177]  ? do_trap+0xeb/0xf0
[   18.045444]  ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.045740]  ? do_error_trap+0x60/0x80
[   18.046019]  ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.046322]  ? exc_invalid_op+0x49/0x60
[   18.046611]  ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.046923]  ? asm_exc_invalid_op+0x16/0x20
[   18.047222]  ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.047544]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   18.047871]  VBoxHost_RTLogCreateExV+0x27b/0x470 [vboxdrv]
[   18.048203]  VBoxHost_RTLogCreate+0x6a/0x90 [vboxdrv]
[   18.048537]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   18.048875]  supdrvInitDevExt+0x54/0x320 [vboxdrv]
[   18.049216]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   18.049561]  ? 0xc05b7000
[   18.049891]  do_one_initcall+0x87/0x2a0
[   18.050223]  do_init_module+0x7d/0x230
[   18.050561]  init_module_from_file+0x81/0xc0
[   18.050901]  idempotent_init_module+0x119/0x230
[   18.051246]  __x64_sys_finit_module+0x4d/0x80
[   18.051592]  do_syscall_64+0x56/0x100
[   18.051944]  ? handle_mm_fault+0xe1/0x1c0
[   18.052298]  ? exc_page_fault+0x276/0x680
[   18.052655]  entry_SYSCALL_64_after_hwframe+0x46/0x4e
[   18.053017] RIP: 0033:0x7f04f4b1eee9
[   18.053381] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   18.053786] RSP: 002b:7ffe7c2cf7b8 EFLAGS: 0246 ORIG_RAX: 
0139
[   18.054207] RAX: ffda RBX: 556c56beb4e0 RCX: 7f04f4b1eee9
[   18.054635] RDX:  RSI: 556c54d7998b RDI: 0003
[   18.055069] RBP:  R08: 0060 R09: 556c56bec340
[   18.055508] R10: 0038 R11: 0246 R12: 556c54d7998b
[   18.055947] R13: 0004 R14: 556c56beb560 R15: 
[   18.056393]  
[   18.056842] Modules linked in: vboxdrv(O+) sha256_ssse3 sha1_ssse3 
sha1_generic
[   18.057310] ---[ end trace  ]---
[   18.057775] RIP: 0010:VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv]
[   18.058267] Code: d0 0f 84 8d fe ff ff 89 c6 85 f6 74 e5 0f 0b 41 09 8c 80 
bc 00 00 00 48 83 c0 01 48 39 d0 0f 84 70 fe ff ff 89 c6 85 f6 74 e5 <0f> 0b b9 
11 00 00 00 eb a0 8b 05 db ed 02 00 85 c0 75 1a 4c 8b 05
[   18.058773] RSP: 0018:a9a2c1e77a68 EFLAGS: 00010202
[   18.059290] RAX: 0001 RBX: c0637424 RCX: 0011
[   18.059809] RDX: 019d RSI: 0001 RDI: 0003
[   18.060328] RBP: a9a2c1e77ac8 R08: 8ee544150010 R09: c062a7e0
[   18.060852] R10: 8ee544150010 R11: 000c R12: c0637427
[   18.061373] R13: 0740 R14: a9a2c1e77c20 R15: 
[   18.061895] FS:  7f04f5145040() GS:8ee84fe0() 
knlGS:
[   18.062419] CS:  0010 DS:  ES:  CR0: 80050033
[   18.062939] CR2: 555689427660 CR3: 00010929b005 CR4: 000706f0




-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.1 

Bug#1054400: dracut: Microcode left out on Linux 6.6 x86

[Ingo Saitz]

Package: dracut
Version: 059-4
Severity: normal
Tags: patch

During installation of Linux 6.6-rc7 from upstream, dracut outputs:

dracut: Disabling early microcode, because kernel does not support it. 
CONFIG_MICROCODE_[AMD|INTEL]!=y

and the kernel does not have any microcode applied after booting. This
is due to CONFIG_MICROCODE_[AMD|INTEL] being hidden behind the
CONFIG_EXPERT option, which is not enabled by default, nor on my kernel:

$ grep CONFIG_\\\(MICROCODE\\\|EXPERT\\\) /boot/config-6.6.0-rc7
# CONFIG_EXPERT is not set
CONFIG_MICROCODE=y
# CONFIG_MICROCODE_LATE_LOADING is not set
$

Upstream already patched this in their git repository:

https://github.com/dracutdevs/dracut/commit/6c80408c8644a0add1907b0593eb83f90d6247b1

Thanks,
Ingo

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.0-rc7 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dracut depends on:
ii  dracut-core  059-4

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1050036: pmount: Can't mount anything since the recent update of libmount1

[Ingo Saitz]

This bug is also tracked as #1042714 in the util-linux package.

Ingo
-- 
const_cast(Λ)

Bug#1050036: #1042714 libmount1: fails to mount vfat filesystem on USB mass storage device with pmount

[Ingo Saitz]

This is due to pmount calling mount -o atime (among other options) to
mount a filesystem. But -o atime is broken on util-linux 2.39. This bug
is easily reproduceable with

# mount -o atime /dev/sdd1 /mnt
mount: /mnt: not mount point or bad option.
   dmesg(1) may have more information after failed mount system call.
# mount /dev/sdd1 /mnt
#

It just got fixed in the upstream repository, but is not included in the
2.39.2 release:

https://github.com/util-linux/util-linux/commit/2b99ee2526ae61be761b0e31c50e106dbec5e9e4

Ingo
-- 
const_cast(Λ)

Bug#1041204: dhcpcd-base: dhcpcd -T wlp3s0 produces Segmentation fault

[Ingo Wichmann]

forwarded 1041204 https://github.com/NetworkConfiguration/dhcpcd/issues/235

Bug#1042423: Acknowledgement (manpages-de still contains pages from new util-linux-locales)

[Ingo Saitz]

After installing all manpages-l10n packages from experimental, I found
more duplicate files, seems I also missed the -dev packages

/usr/share/man/de/man1/eject.1.gz
/usr/share/man/de/man1/lastb.1.gz
/usr/share/man/de/man3/libblkid.3.gz
/usr/share/man/de/man3/uuid.3.gz
/usr/share/man/de/man3/uuid_clear.3.gz
/usr/share/man/de/man3/uuid_compare.3.gz
/usr/share/man/de/man3/uuid_copy.3.gz
/usr/share/man/de/man3/uuid_generate.3.gz
/usr/share/man/de/man3/uuid_generate_random.3.gz
/usr/share/man/de/man3/uuid_generate_time.3.gz
/usr/share/man/de/man3/uuid_generate_time_safe.3.gz
/usr/share/man/de/man3/uuid_is_null.3.gz
/usr/share/man/de/man3/uuid_parse.3.gz
/usr/share/man/de/man3/uuid_time.3.gz
/usr/share/man/de/man3/uuid_unparse.3.gz
/usr/share/man/de/man8/swapoff.8.gz

/usr/share/man/es/man1/lastb.1.gz

/usr/share/man/fr/man1/lastb.1.gz
/usr/share/man/fr/man3/uuid.3.gz
/usr/share/man/fr/man3/uuid_clear.3.gz
/usr/share/man/fr/man3/uuid_compare.3.gz
/usr/share/man/fr/man3/uuid_copy.3.gz
/usr/share/man/fr/man3/uuid_generate.3.gz
/usr/share/man/fr/man3/uuid_generate_random.3.gz
/usr/share/man/fr/man3/uuid_generate_time.3.gz
/usr/share/man/fr/man3/uuid_generate_time_safe.3.gz
/usr/share/man/fr/man3/uuid_is_null.3.gz
/usr/share/man/fr/man3/uuid_parse.3.gz
/usr/share/man/fr/man3/uuid_time.3.gz
/usr/share/man/fr/man3/uuid_unparse.3.gz

/usr/share/man/uk/man1/lastb.1.gz
/usr/share/man/uk/man3/uuid.3.gz
/usr/share/man/uk/man3/uuid_clear.3.gz
/usr/share/man/uk/man3/uuid_compare.3.gz
/usr/share/man/uk/man3/uuid_copy.3.gz
/usr/share/man/uk/man3/uuid_generate.3.gz
/usr/share/man/uk/man3/uuid_generate_random.3.gz
/usr/share/man/uk/man3/uuid_generate_time.3.gz
/usr/share/man/uk/man3/uuid_generate_time_safe.3.gz
/usr/share/man/uk/man3/uuid_parse.3.gz
/usr/share/man/uk/man3/uuid_unparse.3.gz
/usr/share/man/uk/man8/swapoff.8.gz

dpkg log is attached

thx,
Ingo
-- 
const_cast(Λ)

Bug#1042423: Acknowledgement (manpages-de still contains pages from new util-linux-locales)

[Ingo Saitz]

forgot

> dpkg log is attached

    Ingo
-- 
const_cast(Λ)
Unpacking util-linux-locales (2.39.1-3) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man1/eject.1.gz', which 
is also in package manpages-de 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/libblkid.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid.3.gz', which is 
also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_clear.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_compare.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_copy.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_generate.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_is_null.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_parse.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_time.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man3/uuid_unparse.3.gz', 
which is also in package manpages-de-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid.3.gz', which is 
also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_clear.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_compare.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_copy.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_generate.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_is_null.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_parse.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_time.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/fr/man3/uuid_unparse.3.gz', 
which is also in package manpages-fr-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid.3.gz', which is 
also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid_clear.3.gz', 
which is also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid_compare.3.gz', 
which is also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid_copy.3.gz', 
which is also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid_generate.3.gz', 
which is also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/uk/man3/uuid_parse.3.gz', 
which is also in package manpages-uk-dev 4.19.0-4
dpkg: warning: overriding problem beca

Bug#1042423: manpages-de still contains pages from new util-linux-locales

[Ingo Saitz]

Package: manpages-de
Version: 4.19.0-4
Severity: normal

Dear Maintainer,

The experimental version of manpages-de still seems to contain manpages
which are shipped with util-linux 2.39.1-3, namely:

/usr/share/man/de/man1/eject.1.gz
/usr/share/man/de/man1/lastb.1.gz
/usr/share/man/de/man8/swapoff.8.gz

At least the last 2 seem to be missing from the list of new files in
bug #1037040

thx
Ingo

*** dpkg log:
Unpacking util-linux-locales (2.39.1-3) over (2.38.1-6) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man1/eject.1.gz', which 
is also in package manpages-de 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man1/lastb.1.gz', which 
is also in package manpages-de 4.19.0-4
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/share/man/de/man8/swapoff.8.gz', which 
is also in package manpages-de 4.19.0-4


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc3 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
ii  man-db [man-browser]  2.11.2-3
ii  manpages  6.03-2

-- no debconf information

Bug#1041204: dhcpcd-base: dhcpcd -T wlp3s0 produces Segmentation fault

[Ingo Wichmann]

Package: dhcpcd-base
Version: 9.4.1-22
Severity: normal
X-Debbugs-Cc: iw-deb...@linuxhotel.de

Dear Maintainer,

I tried out 
  dhcpcd -T wlp3s0
to fetch information from my local dhcp-server. After some lines of output the
programm stops with 'Segmentation fault'. 

Here is the output I get:

# dhcpcd -T wlp3s0
dhcpcd-9.4.1 starting
DUID 00:04:94:6e:66:81:53:aa:11:cb:b0:9f:c5:e1:3e:11:82:a0
wlp3s0: IAID 31:5f:29:a8
wlp3s0: soliciting an IPv6 router
wlp3s0: soliciting a DHCP lease
wlp3s0: offered 192.168.1.119 from 192.168.1.2
interface='wlp3s0'
pid='5687'
protocol='dhcp'
reason='TEST'
ifcarrier='up'
ifflags='69699'
ifmetric='3003'
ifmtu='1500'
ifssid='linuxhotel'
ifwireless='1'
new_broadcast_address='192.168.1.255'
new_dhcp_lease_time='1800'
new_dhcp_message_type='2'
new_dhcp_server_identifier='192.168.1.2'
new_domain_name='linuxhotel.de'
new_domain_name_servers='192.168.1.5'
new_ip_address='192.168.1.119'
new_network_number='192.168.1.0'
new_routers='192.168.1.5'
new_subnet_cidr='24'
new_subnet_mask='2

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024357 is a similar bug that 
has been closed upstream with 
https://github.com/NetworkConfiguration/dhcpcd/issues/156 and seems to have 
been fixed in testing or sid. 

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dhcpcd-base depends on:
ii  adduser   3.134
ii  libc6 2.36-9
ii  libudev1  252.6-1

Versions of packages dhcpcd-base recommends:
ii  wpasupplicant  2:2.10-12

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- no debconf information

Bug#1039064: binutils-msp430: file conflict with binutils-x86-64-linux-gnu

[Ingo Saitz]

Package: binutils-msp430
Version: 2.24~ti2
Severity: serious
Justification: Policy 7.6.1

libdeb.so is both in binutils-x86-64-linux-gnu and binutils-msp430 in
the same location. This was not the case in ~ti1, where libdeb.so was in
/usr/lib/bfd-plugins/libdep.so. Thus the upgrade fails:

Preparing to unpack .../binutils-msp430_2.24~ti2_amd64.deb ...
Unpacking binutils-msp430 (2.24~ti2) over (2.24~ti1) ...
dpkg: error processing archive 
/var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so', which 
is also in package binutils-x86-64-linux-gnu 2.40.50.20230622-1
Errors were encountered while processing:
 /var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-rc7 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages binutils-msp430 depends on:
ii  libc6  2.36-9
ii  libzstd1   1.5.5+dfsg2-1
ii  msp430mcu  20120406-2.3

binutils-msp430 recommends no packages.

binutils-msp430 suggests no packages.

-- no debconf information

Bug#1029586: apt: "apt-cache rdepends --installed" false positives

[Ingo Brückl]

On Wed, 25 Jan 2023 10:45:53 +0100, Julian wrote:

> The --installed flag here behaves exactly as it is documented. It
> filters the output list by packages that are installed; it doesn't
> say anything about restricting matching to installed versions only
> - matching always happens on all versions effectively.

Perhaps this should be documented more clearly. My reading of the option
was just as wrong as Vincent's.


1029586.patch
Description: Binary data

Bug#1032256: Additional information

[Ingo]

I found further information on my device (ear-buds) in
/var/lib/bluetooth/80:38:FB:D6:A7:62/3C:F8:A8:B9:CE:A1/info:

Name=Hama Freedom Light
Class=0x240404
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=110b--1000-8000-00805f9b34fb;110c--1000-8000-00805f9b34fb;110d--1000-8000-00805f9b34fb;110e--1000-8000-00805f9b34fb;111e--1000-8000-00805f9b34fb;1200--1000-8000-00805f9b34fb;

[DeviceID]
Source=1
Vendor=1494
Product=10
Version=576

[LinkKey]
Key=< 32 hex characters long, maybe secret? >
Type=4
PINLength=0

Bug#1027963: vmstat: does not update memory columns

[Ingo Saitz]

Package: procps
Version: 2:4.0.2-3
Severity: normal
Tags: patch

Dear Maintainer,

running vmstat to produce a continuous output (eg. "vmstat 3") does not
update the values in the memory columns any more. The "main loop" just
does not fetch those values.

The attached patch fixes the output by fetching the memory stats on the
main loop, too.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-spatz20221212 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages procps depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-7
ii  libncursesw6 6.4-1
ii  libproc2-0   2:4.0.2-3.~0ingo1
ii  libtinfo66.4-1

Versions of packages procps recommends:
ii  psmisc  23.6-1

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf changed [not included]

-- no debconf information
Description: vmstat: refresh memory display
 Update the memory columns on repeated outputs
Author: Ingo Saitz 
Bug: $this_one
Last-Update: 2023-01-05
Index: procps-4.0.2/src/vmstat.c
===
--- procps-4.0.2.orig/src/vmstat.c
+++ procps-4.0.2/src/vmstat.c
@@ -468,6 +468,9 @@ static void new_format(void)
 pswpin[tog] = VMSTAT_GET(vm_info, VMSTAT_PSWPIN, ul_int);
 pswpout[tog] = VMSTAT_GET(vm_info, VMSTAT_PSWPOUT, ul_int);
 
+if (!(mem_stack = procps_meminfo_select(mem_info, Mem_items, MAX_mem)))
+xerrx(EXIT_FAILURE, _("Unable to select memory information"));
+
 if (t_option) {
 (void) time( _time );
 tm_ptr = localtime( _time );

Bug#969264: Warning message still present in Bullseye 11.2

[Ingo]

On Sat, 9 Jul 2022 10:36:40 +0200 Marcin Juszkiewicz
 wrote:

On Sat, 11 Jun 2022 17:58:18 +0200 Diederik de Haas  >  wrote: 
>> On Sun, 9 Jan 2022 23:20:49 +0100

Frode Severin Hatlevik >>  wrote: >>> I just
updated my Debian amd64 system from Buster to Bullseye as >>> per >>>
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> >>> >>> >>> >>> >> I have to admit I cut some corners and enabled
backports and Fast >> Track and >>> did the update in one go. >>> >>>
All went well, short of the error discussed in this bug >>> appearing at
the boot console [ 20.208399] iwlwifi :02:00.0: >>> firmware: failed
to load iwl-debug-yoyo.bin (-2) >> >> With what kernel version did you
see that message? > 10:35 (314s) hrw@blossom:~$ uname -a Linux blossom >
5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1~bpo11+1 >
(2022-06-14) x86_64 GNU/Linux > > 10:35 (0s) hrw@blossom:~$ dmesg|grep
iwl-debug-yoyo.bin [sob lip 9 > 10:29:29 2022] iwlwifi :00:14.3:
firmware: failed to load > iwl-debug-yoyo.bin (-2) > > 10:35 (0s)
hrw@blossom:~$ > >

It's still seen here in kernel:

Linux xyz 5.19.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.6-1
(2022-09-01) x86_64 GNU/Linux

Hardware is Shuttle xpx With Alder Lake CPU and Intel AX200-NGW. WiFi
and BlueTooth. Both work flawlessly with latest Bluetooth Firmware

ibt-20-0-3.ddc + ibt-20-0-3.sfi symlinked  to corresponding 20-0.0
version which some piece of software  strictly requests (version 20-0.3
does not load otherwise).


WiFi uses firmware

iwlwifi-cc-a0-72.ucode from github - the only version which no longer
produces "failed to load ..." in dmesg.

Bug#1019713: gargoyle-free: trying to overwrite .../application-x-tads.png, which is also in package qtads

[Ingo Saitz]

Package: gargoyle-free
Version: 2022.1-1
Severity: serious
Justification: Policy 7.6.1

Unpacking gargoyle-free (2022.1-1) over (2019.1.1-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/gargoyle-free_2022.1-1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/hicolor/32x32/mimetypes/application-x-tads.png', which is 
also in package qtads 2.1.7-0.1+b1
Errors were encountered while processing:
 /var/cache/apt/archives/gargoyle-free_2022.1-1_amd64.deb

Both packages (qtads and the new gargoyle-free) provide the icon for .tads
files, so you probably need to set up alternatives. dpkg-divert would
only work until a 3rd package also tries to provide that icon.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-rc5-pinguin20220912 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gargoyle-free depends on:
ii  fonts-go  0~20170330-1
ii  fonts-liberation  1:1.07.4-11
ii  fonts-linuxlibertine  5.3.0-6
ii  fonts-noto-core   20201225-1
ii  libc6 2.34-8
ii  libfontconfig12.13.1-4.4
ii  libfreetype6  2.12.1+dfsg-3
ii  libgcc-s1 12.2.0-2
ii  libglib2.0-0  2.73.3-3
ii  libgtk2.0-0   2.24.33-2
ii  libjpeg62-turbo   1:2.1.2-1
ii  libpng16-16   1.6.37-5
ii  libsdl-mixer1.2   1.2.12-17+b1
ii  libsdl-sound1.2   1.0.3-9+b1
ii  libsdl1.2debian   1.2.15+dfsg2-8
ii  libstdc++612.2.0-2
ii  zlib1g1:1.2.11.dfsg-4.1

gargoyle-free recommends no packages.

gargoyle-free suggests no packages.

-- no debconf information

Bug#1017007: manpages-de: trying to overwrite .../ethers.5.gz, which is also in package net-tools

[Ingo Saitz]

Package: manpages-de
Version: 4.14.0-4
Severity: serious
Tags: l10n
Justification: Policy 7.6.1

Unpacking manpages-de (4.15.0-3) over (4.14.0-4) ...
dpkg: error processing archive 
/var/cache/apt/archives/manpages-de_4.15.0-3_all.deb (--unpack):
 trying to overwrite '/usr/share/man/de/man5/ethers.5.gz', which is also in 
package net-tools 1.60+git20181103.0eebece-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/manpages-de_4.15.0-3_all.deb


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-pinguin20220731 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
it  man-db [man-browser]  2.10.2-1
ii  manpages  5.13-1

-- no debconf information

Bug#1016527: rst2man: --date should be used to form the .TH title heading

[Ingo Schwarze]

Strictly speaking, the third argument of the man(7) .TH macro is supposed
to be the date when a human being last edited the content of the manual
page, or in case rst2man(1) is used, the date when a human being last
edited the content of the input '*.rst' file, *not* the date when
rst2man(1) did the format conversion.

That said, i am able to reproduce that the rst2man(1) program contained
in the py3-docutils-0.17.1 package on OpenBSD-current also puts the line
"Generated on: 2022\-08\-02." into the NAME section, which is indeed a
severe man(7) syntax error.  So the bug appears to be operating system
independent.

If the date of the last human edit is unknown, putting the date on
which rst2man(1) was run into the third argument of the .TH macro
is of course still better than putting it into a place where it
violates the syntax of the man(7) language.  On the other hand,
couldn't the correct time be found by inspecting the mtime of
the inode of the '*.rst' file?

Finally, "Generated on: 2022\-08\-02" also contains a typographic
error:  \- is a minus sign, and you are not doing any subtraction
here.  The character you want is a dash, so

  Generated on: 2022\(en08\(en02

would be correct typography if you want to put it somewhere in the
body of the manual page.  In the .TH macro, by contrast, the correct
format for the third argument would be "2022-08-02" with no
escaping, neither "2022\-08\-02" nor "2022\(en08\(en02".

Bug#539340: debfoster: please add multiarch support

[Ingo Saitz]

tag 539340 +patch
thanks

Here is a small patch for ignoring :any (and other arch specifications)
in the package names of dependencies. The correct solution would be to
track and compare the architecture in the pkg_version structure.

This should also fix #1001751 which I believe happenes because debfoster
ignores python3.10:any dependencies.

The second patch is a testcase. Although they don't seem to get run on
building the package.

Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393
>From 616b638fbf4b2a006c90d9954cce0956d7871eb9 Mon Sep 17 00:00:00 2001
From: Ingo Saitz 
Date: Wed, 11 May 2022 08:44:36 +0200
Subject: [PATCH 1/2] skip arch part of package, multiarch workaround

---
 src/vercmp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/vercmp.c b/src/vercmp.c
index 76bd94e..3fba5ca 100644
--- a/src/vercmp.c
+++ b/src/vercmp.c
@@ -168,7 +168,7 @@ const char *parsedependency(const char *string, struct pkg_version *pv, enum dep
 /* Extract package name. */
 {
   const char *namestart = p;
-  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|') {
+  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|' && *p != ':') {
 p++;
   }
 
@@ -179,6 +179,14 @@ const char *parsedependency(const char *string, struct pkg_version *pv, enum dep
 pv->name = NULL;
 }
 
+/* skip arch part */
+if (*p == ':') {
+  p++;
+  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|') {
+p++;
+  }
+}
+
 /* skip whitespace after packagename */
 while (cisspace(*p)) p++;
 if (*p == '(') {  /* if we have a versioned relation */
-- 
2.36.1

>From c40ed30af0f92522c4a6162d05b0e025a6ad4673 Mon Sep 17 00:00:00 2001
From: Ingo Saitz 
Date: Wed, 11 May 2022 09:06:27 +0200
Subject: [PATCH 2/2] simple multiarch testcase

does not test dependency on wrong arch
---
 tests/002/available |  0
 tests/002/exp   |  0
 tests/002/keepers   |  1 +
 tests/002/status| 21 +
 4 files changed, 22 insertions(+)
 create mode 100644 tests/002/available
 create mode 100644 tests/002/exp
 create mode 100644 tests/002/keepers
 create mode 100644 tests/002/status

diff --git a/tests/002/available b/tests/002/available
new file mode 100644
index 000..e69de29
diff --git a/tests/002/exp b/tests/002/exp
new file mode 100644
index 000..e69de29
diff --git a/tests/002/keepers b/tests/002/keepers
new file mode 100644
index 000..e542435
--- /dev/null
+++ b/tests/002/keepers
@@ -0,0 +1 @@
+depends_arch_any
diff --git a/tests/002/status b/tests/002/status
new file mode 100644
index 000..b4f5680
--- /dev/null
+++ b/tests/002/status
@@ -0,0 +1,21 @@
+Package: depends_arch_any
+Architecture: amd64
+Version: 1
+Depends: libc6 (>= 2.33), perl:any, ruby:any
+Status: install ok installed
+
+Package: libc6
+Architecture: amd64
+Version: 2.33-7
+Status: install ok installed
+
+Package: perl
+Architecture: i386
+Version: 5.34.0-4
+Status: install ok installed
+
+Package: ruby
+Architecture: amd64
+Version: 1:3.0+1
+Status: install ok installed
+
-- 
2.36.1

Bug#1008158: rspamd returns 404 error when mail already learned

[Ingo Juergensmann]

Package: rspamd
Version: 3.1-1~bpo11+1
Severity: normal

Dear Maintainer,

rspamc reports an HTTP 404 error when a mail has already been learnt: 

HTTP error: 404, all learn conditions denied learning spam in default classifier

See the discussion upstream here: 
https://github.com/rspamd/rspamd/issues/3956

... and the fix/patch can be found here: 
https://github.com/rspamd/rspamd/commit/58037bbffc0e3fd7873b6b411ea2c3aeb0f3ea91

It would be great if you could implement this fix in the next upload of rspamd, 
because apparently (and discussed upstream) this is not an error but either 
info/notify or warning level.
HTTP 404 is misleading the user to believe there is an error with the 
configuration like some webserver is not reachable or so. 

This happens also with version in bullseye itself, just used backports for 
counter-checking... 

Regards, 
Ingo 

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

Kernel: Linux 5.10.0-12-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DE:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rspamd depends on:
ii  adduser 3.118
ii  ca-certificates 20210119
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-2
ii  init-system-helpers 1.60
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libhyperscan5   5.4.0-2
ii  libicu6767.1-7
ii  libjs-bootstrap44.5.2+dfsg1-7
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-requirejs 2.3.6+ds-1
ii  libluajit-5.1-2 2.1.0~beta3+dfsg-5.3
ii  libpcre2-8-010.36-2
ii  libsodium23 1.0.18-1
ii  libsqlite3-03.34.1-3
ii  libssl1.1   1.1.1k-1+deb11u2
ii  libstdc++6  10.2.1-6
ii  libunwind8  1.3.2-2
ii  lsb-base11.1.0
ii  perl5.32.1-4+deb11u2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages rspamd recommends:
ii  redis-server  5:6.0.16-1+deb11u2

rspamd suggests no packages.

-- Configuration Files:
/etc/rspamd/rspamd.conf changed [not included]
/etc/rspamd/worker-controller.inc changed [not included]

-- no debconf information

Bug#1007711: reportbug: systemd --user: logoff and logon does not load new group memberships

[Ingo Wichmann]

Hi Michael,

I now dist-upgraded to bookworm/testing. I can't reproduce the issue 
there. On bookworm/testing, the old session is not reused.


So for bullseye/stable, possible workarounds are:
* reboot
* wait for the timeout to finish the session completely
* pkill -u $user (e.g. from a text-vt)

Am 15.03.22 um 13:50 schrieb Michael Biebl:

Am 15.03.22 um 13:36 schrieb Ingo Wichmann:


Which terminal emulator do you use? E.g gnome-terminal is implemented as 
a user service and might be affected.


Yes, gnome-terminal.

But looking at the Ubuntu machine where I first encountered the issue, 
the session stays alive for a few seconds even when I don't start 
gnome-terminal.



After logging out, how long did you wait before logging in again?
I vaguely remember that there is a timeout before an idle user session 
is terminated.


I didn't wait long.
And yes, the user session was still active. That's why I filed the bug 
against the systemd package.


Or do you have lingering enabled, so user sessions are deliberately not 
terminated?


No.

Feel free to ask, if you want me to provide more detail.

Ingo

Bug#1007711: reportbug: systemd --user: logoff and logon does not load new group memberships

[Ingo Wichmann]

Maybe this bug is related to
https://github.com/systemd/systemd/issues/8598

Bug#1007711: reportbug: systemd --user: logoff and logon does not load new group memberships

[Ingo Wichmann]

Package: systemd
Version: 247.3-6
Severity: normal
X-Debbugs-Cc: iw-deb...@linuxhotel.de

Dear Maintainer,

on a notebook running Debian 11 (tested with Ubuntu 20.04, too) with gnome
desktop I added my user to a new group:

  sudo groupadd docker
  sudo gpasswd -a nutzer36 docker

after that, I logged out and then on again. I expected that when I check with 
the id command, that my user would now belong to that group. But that's not the 
case.

I found out, that there are some processes left over from my last login:

  pgrep -lau nutzer36 | head
723 /lib/systemd/systemd --user
724 (sd-pam)
758 /usr/bin/pipewire
759 /usr/bin/pulseaudio --daemonize=no --log-target=journal
792 /usr/bin/pipewire-media-session
871 ssh-agent -D -a /run/user/1000/openssh_agent

all the current processes of my new desktop session are child
processes of that old systemd --user session

If I log out and terminate systemd --user, the session is closed and
after login I'm member of the group as expected.

login out using loginctl kill-session did not help


-- Package-specific info:

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-10
ii  libaudit11:3.0-2
ii  libblkid12.36.1-8+deb11u1
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libcryptsetup12  2:2.3.7-1+deb11u1
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.36.1-8+deb11u1
ii  libpam0g 1.4.0-9+deb11u1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-6
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.36.1-8+deb11u1
ii  systemd-timesyncd [time-daemon]  247.3-6
ii  util-linux   2.36.1-8+deb11u1

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31+deb11u1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- no debconf information

Bug#992323: binutils-common: many manpares are empty

[Ingo Saitz]

Package: binutils-common
Version: 2.37-4
Severity: normal

The manpages for many of the included tools are just copressed empty
files (the 20 bytes are the compression header), as dpkg-deb -c shows:

-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/addr2line.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/ar.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/as.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/c++filt.1.gz
-rw-r--r-- root/root   621 2021-08-15 16:51 ./usr/share/man/man1/dwp.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/elfedit.1.gz
-rw-r--r-- root/root  8923 2021-08-15 16:51 ./usr/share/man/man1/gprof.1.gz
-rw-r--r-- root/root 43184 2021-08-15 16:51 ./usr/share/man/man1/ld.bfd.1.gz
-rw-r--r-- root/root  6705 2021-08-15 16:51 
./usr/share/man/man1/ld.gold.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/nm.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/objcopy.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/objdump.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/ranlib.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/readelf.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/size.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/strings.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/strip.1.gz


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc4-pinguin20210802 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#992002: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml

[Ingo Schwarze]

Hi Nab,

Nab wrote on Tue, Aug 10, 2021 at 01:08:31AM +0200:
> On Mon, Aug 09, 2021 at 10:58:19AM +0200, Ingo Schwarze wrote:
>> Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:

>>> tbl's -Thtml ignores font requests;

>> Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
>> committed on May 16 earlier this year.

> Oh, indeed. I tested and based my patch on 1.14.5 from Debian,
> didn't realise that's almost two years old by now.
> Will use the CVS next time.

Note that so far, everybody who contributed code to mandoc provided
their first and last names.  I'm not sure it is strictly required in
the legal sense, but i do consider it beneficial both for authors
and for users.  The benefit for authors is that it makes it easier
for them to exercise their rights under the Berne Convention, in
particular their moral rights under that Convention, for example
to protect themselves if somebody abuses their contribution for
slander.  The benefit for users of knowing who the Copyright holders
are is also obvious, even if the code is BSD or ISC licensed:
It makes Copyright and license audits easier and reduces the risk
of suddenly being sued by parties the users didn't even know existed.

In this case, it isn't needed because by mere chance, even though
several of your ideas remained in the committed patch, none of your
code did, because i switched from TBL_CELL_BOLD and TBL_CELL_ITALIC
to ESCAPE_FONT*.  Ideas aren't subject to Copyright, only text is,
and for crediting a person who provided bug reports, feature requests,
and ideas, a pseudonym is sufficient.

>>> text
>>> text
>>> text

>> These become:
>>   text
>>   text

> This is great news! A bunch of my pages use C[BI] and the HTML renders
> look much better, thanks!

Note that i don't recommend using these fonts in manual pages.
Even with groff, typical installations don't prodide CB and CI
fonts for terminal output, which typically results in warnings
being thrown.  The details may vary among operating systems and
package managers even for the same version of groff.  Portability
to other formatters (like Heirloom, Plan 9, DWB, Solaris, neatroff)
is even more doubtful, but i don't know any details about that.

But as a rule, mandoc(1) even supports features if using them is
unwise, as long as that doesn't cause an undue burden.  One reason
to do so is making existing pages look better, no matter how good
or bad the style is that they are using.  Not supporting a feature
hurts end users - who aren't responsible for author's choices which
features to use.  But that a feature is supported by mandoc(1)
should not be misinterpreted by authors as a free pass to go on a
rampage and employ the most arcane and brittle features they manage
to find.

>>  * GNU tbl(1) appears to ignore space characters between the f
>>modifier and the font name, so "lf   B" is the same as "lfB".

> Huh, so it does! That's not explicitly mentioned by the manual and so
> I didn't think to test it.

No, i'm not even convinced it is intentional, and relying on it in
any document would be a thoroughly bad idea.  But mandoc(1) aims to
be bug-compatible with groff unless there is a good reason to differ.

>   Now, tbl(1) says
>   Key characters can be separated by spaces or tabs.
> so consider the following document:
> -- >8 --
> .TS
> lfBI  lf BI   lf  BI  .
> a b   c
> .TE
> -- >8 --
> (In order, none, space, tab follow 'f';
>  base64: LlRTCmxmQkkJbGYgQkkJbGYJQkkJLgphCWIJYwouVEUK)
> 
> groff renders it with a, b, and c as BI,
> but mandoc with your patch with a+b as BI and c as R, with -Tlint:
>   mandoc: ./q.1:2:14: WARNING: unknown font, \
>   skipping request: TS f  BI  .
> 
> If you change tbl_layout.c L171 to match L75:
> -- >8 --
> - while (p[*pos] == ' ')
> + while (p[*pos] == ' ' || p[*pos] == '\t')
> -- >8 --
> and L187:
> -- >8 --
> - if (strchr(" .", p[*pos + isz]) == NULL)
> + if (strchr(" \t.", p[*pos + isz]) == NULL)
> -- >8 --
> The document renders correctly.

Done in the commit cited below, thanks for pointing out that quirk.

>> Could you please check out from CVS (instead of the last release),
>> apply the following patch, and tell me whether it looks reasonable
>> and works for you?

> Yeah, save for the tab thing above, I haven't managed to fault it,
> in tests or real pages.

Thank you very much for testing.  That patch ended up growing
tentacles into quite a number of files, so the additional testing
is highly appreciated.

Here is the committed patch:

https://inbox.vuxu.org/mandoc-source/c2aa6365c21bf...@mandoc.bsd.lv/

Yours,
  Ingo

Bug#992002: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml

[Ingo Schwarze]

Hello Nab,

Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:

> tbl's -Thtml ignores font requests;

Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
committed on May 16 earlier this year.

> additionally, the tbl f-request
> parser only allows single-character fonts.

Yes, that is still a missing feature.

> Cf. the Debian bug
> (http://bugs.debian.org/992002) for additional context.
> 
> Please consider the following patch.

Thank you very much for sending quite a non-trivial patch.
That was very helpful in understanding what exactly is needed.

I started from your patch and changed a few aspects:

 * You couldn't possibly know that i'm trying to work towards a
   unified system for identifying fonts using the mandoc.h
   enum mandoc_esc ESCAPE_FONT* identifiers.  Having different
   font identifiers for each output module is not good.
   So i added ESCAPE_FONTCB and ESCAPE_FONTCI and used those.
   A nice side effect is that CB and CI now work in HTML
   for all of \f, .ft, and tbl(7) f and that tbl(7) fBI
   now also works for terminal output.
 * GNU tbl(1) appears to ignore space characters between the f
   modifier and the font name, so "lf   B" is the same as "lfB".

> With this patch, the following document:
> -- >8 --
> .Dd
> .Dt V 1
> .Os
> .
> \fBtext\fItext\f(BItext\f(CRtext\f(CBtext\f(CItext\fR
> .Pp
> .TS
> lfB lfI lfBI lb li lbi lfCR lfCB lfCI .
> text  texttexttexttexttexttexttexttext
> .TE
> -- >8 --
> 
> Renders to a teletype with the expected fonts:
>   b, ul, bul;  b, ul, bul;  normal, b, ul

Not quite.  The expected output for lbi is ul, not bul.
The i overrides the b rather than add to it.
So lbi is the same as lfI, not as lfBI.

> -Thtml -Ofragment yields, as expected:
> -- >8 --
[...]
> 
>   
> text
> text
> text
> text
> text
> text

Again, text with my version of the patch.

> text
> text
> text

These become:

  text
  text

Could you please check out from CVS (instead of the last release),
apply the following patch, and tell me whether it looks reasonable
and works for you?

When this gets committed, i will credit you for reporting the
missing feature.  Do i understand correctly that "Nabija" is your
first name and "Czleweli" your last name?

Thanks again,
  Ingo

-- 
Ingo Schwarze 
http://www.openbsd.org/   
http://mandoc.bsd.lv/ 


Index: html.c
===
RCS file: /home/cvs/mandoc/mandoc/html.c,v
retrieving revision 1.273
diff -u -p -r1.273 html.c
--- html.c  2 Jun 2021 17:51:38 -   1.273
+++ html.c  9 Aug 2021 07:50:02 -
@@ -1,7 +1,7 @@
 /* $Id: html.c,v 1.273 2021/06/02 17:51:38 schwarze Exp $ */
 /*
- * Copyright (c) 2011-2015, 2017-2020 Ingo Schwarze 
  * Copyright (c) 2008-2011, 2014 Kristaps Dzonsons 
+ * Copyright (c) 2011-2015, 2017-2021 Ingo Schwarze 
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -240,8 +240,10 @@ html_setfont(struct html *h, enum mandoc
case ESCAPE_FONTITALIC:
case ESCAPE_FONTBOLD:
case ESCAPE_FONTBI:
-   case ESCAPE_FONTCW:
case ESCAPE_FONTROMAN:
+   case ESCAPE_FONTCR:
+   case ESCAPE_FONTCB:
+   case ESCAPE_FONTCI:
break;
case ESCAPE_FONT:
font = ESCAPE_FONTROMAN;
@@ -272,9 +274,17 @@ print_metaf(struct html *h)
h->metaf = print_otag(h, TAG_B, "");
print_otag(h, TAG_I, "");
break;
-   case ESCAPE_FONTCW:
+   case ESCAPE_FONTCR:
h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
break;
+   case ESCAPE_FONTCB:
+   h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
+   print_otag(h, TAG_B, "");
+   break;
+   case ESCAPE_FONTCI:
+   h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
+   print_otag(h, TAG_I, "");
+   break;
default:
break;
}
@@ -503,8 +513,10 @@ print_encode(struct html *h, const char 
case ESCAPE_FONTBOLD:
case ESCAPE_FONTITALIC:
case ESCAPE_FONTBI:
-   case ESCAPE_FONTCW:
case ESCAPE_FONTROMAN:
+   case ESCAPE_FONTCR:
+   case ESCAPE_FONTCB:
+   case ESCAPE_FONTCI:
if (0 == norecurse) {
h->flags |= HTML_NOSPACE;
if (html_setfont(h, esc))
Index: man_validate.c
===

Bug#990906: Xarchiver Debian bug 990906

[Ingo Brückl]

Hi,

I believe that the bug you reported is fixed in the current master of
xarchiver:

https://github.com/ib/xarchiver/commit/949854e9a74489d8d977aac7a8428ecadd526ff1

Regards,

Ingo

Bug#990853: Problem with Directory directive

[Stadtsholte, Ingo]

Hi,

I figured out, that ProxyPassMatch causes my Problem. I changed the 
configuration to


SetHandler "proxy:fcgi://127.0.0.1:9000"


Now everything is fine

Thanks for supporting me. For me, you can close the ticket


Aktuelles finden Sie auch auf https://www.olb.de und 
https://www.facebook.com/olb.bank

Oldenburgische Landesbank AG
Vorsitzender des Aufsichtsrates: Axel Bartsch
Vorstand: Dr. Wolfgang Klein, Vorsitzender; Stefan Barth, stellv. Vorsitzender; 
Marc Ampaw; Peter Karst; Karin Katerbau; Dr. Rainer Polster
Sitz der Gesellschaft und Registergericht: Oldenburg (Oldb), HR-Nummer: HRB 3003


smime.p7s
Description: S/MIME cryptographic signature

Bug#990853: Problem with Directory directive

[Stadtsholte, Ingo]

Hi,

but it's curious, that 2 weeks earlier it run's like I expected; I could enable 
Auth through a Directory directive on special folders and all of it's content. 
The problem with  is, that I can not except single files with

Satisfy any



Aktuelles finden Sie auch auf https://www.olb.de und 
https://www.facebook.com/olb.bank

Oldenburgische Landesbank AG
Vorsitzender des Aufsichtsrates: Axel Bartsch
Vorstand: Dr. Wolfgang Klein, Vorsitzender; Stefan Barth, stellv. Vorsitzender; 
Marc Ampaw; Peter Karst; Karin Katerbau; Dr. Rainer Polster
Sitz der Gesellschaft und Registergericht: Oldenburg (Oldb), HR-Nummer: HRB 3003



>> Other problems I had after that update: I had to enable some modules via
>> a2enmod. 3 weeks earlier the modules were automatically enabled and the
>> AuthType works for the whole directory

>Could you give more details ?

2 weeks earlier, I just build my image with
From: ... debian:buster
Run apt-get install -y \
 apache2 \
 apache2-utils \
 libapache2-mod-auth-gssapi \
 libapache2-mod-authnz-external \
 libapache2-mod-fcgid

Now I had to add
run a2enmod session_cookie \
   && a2enmod rewrite \
   && a2enmod include
to get it to work

I just mentioned the problem with a2enmod as I thought there was a bigger 
change in apache2. My only real problem is to enable Auth only on some 
Directories.

thanks

smime.p7s
Description: S/MIME cryptographic signature

Bug#990853: Problem with Directory directive

[Stadtsholte, Ingo]

Package: apache2
Version: 2.4.38-3+deb10u4

After minor updating my Apache Installation to the above Version, AuthType in 
Directory directive only affects to DirectoryIndex, not to all other 
files/subdirectories


  AuthType GSSAPI
  require valid-user
  DirectoryIndex index.php


Authentication works when I call https://myserver/ but do not work anymore when 
I call https://myserver/index.php

Other problems I had after that update: I had to enable some modules via 
a2enmod. 3 weeks earlier the modules were automatically enabled and the 
AuthType works for the whole directory

Hope you can help


Aktuelles finden Sie auch auf https://www.olb.de und 
https://www.facebook.com/olb.bank

Oldenburgische Landesbank AG
Vorsitzender des Aufsichtsrates: Axel Bartsch
Vorstand: Dr. Wolfgang Klein, Vorsitzender; Stefan Barth, stellv. Vorsitzender; 
Marc Ampaw; Peter Karst; Karin Katerbau; Dr. Rainer Polster
Sitz der Gesellschaft und Registergericht: Oldenburg (Oldb), HR-Nummer: HRB 3003


smime.p7s
Description: S/MIME cryptographic signature

Bug#901636: mandoc: "mandoc -mdoc -T man" causes memory dump

[Ingo Schwarze]

I just fixed the assertion failure upstream at mandoc.bsd.lv,
see https://inbox.vuxu.org/mandoc-source/c2aa13aac88a7...@mandoc.bsd.lv/
and http://cvsweb.bsd.lv/mandoc/ .

Supporting tbl(7) and eqn(7) in -T man has been on the
http://cvsweb.bsd.lv/mandoc/TODO list for some time, but it causes
a non-trivial amount of work and is not particularly high priority
for the following reason: The main use case for -T man is that you
can maintain the documentation of your portable software project
in the mdoc(7) format and yet provide autogenerated man(7) versions
of your manual pages for the very few remaining operating systems
that still do not support mdoc(7).  If you care about that, embedding
tbl(7) or eqn(7) code in your manual pages is just a bad idea in
the first place.

Thanks to Nab for proposing patches, but these can't be committed
as-is because they consitute a layering violation.  The new code
is essentially a tbl-to-tbl output mode and would belong into a new
module tbl_tbl.c; it is misplaced in mdoc_man.c because it is neither
related to mdoc(7) input nor to man(7) output.  It appears setting
that up properly wouldn't be excessively difficult, but i don't
have the time to do so right now.  Besides, this would be the first
src_dst.c output module where src == dst, so some generic design
questions might need to be considered before commit.

Thanks to all of you for your input!
  Ingo

Bug#983788: Circular dependency

[Ingo Brückl]

Package: mplayer-gui
Version: 2:1.4+ds1-1

Since mplayer-skin-blue (1.13-2) there is a circular dependency.

mplayer-gui depends on mplayer-skin = mplayer-skin-blue which depends on
mplayer-gui.

Since the user should only install skins matching their mplayer-gui, it's
probably necessary to replace the dependency on mplayer-skin in mplayer-gui
with a recommendation, right?

So far, installing mplayer-gui without a skin resulted in an error message at
startup and the termination of mplayer-gui. So there was a dependency, but
the Subversion snapshot (and the next version) of the GUI has a built-in skin
that allows simple control and installing a skin is (just, but strongly)
advised.

Or is there another way to ensure the mutual dependency?

Ingo

Bug#981838: fixed in mplayer-blue 1.13-2

[Ingo Brückl]

>  mplayer-blue (1.13-2) unstable; urgency=medium
>
>* debian/control: Add missing dependency on mplayer-gui (Closes: #981838)

Is there a circular dependency now?

mplayer-gui depends on mplayer-skin = mplayer-skin-blue which depends on
mplayer-gui.

Since the user should only install skins matching their mplayer-gui, it's
probably necessary to replace the dependency on mplayer-skin in mplayer-gui
with a recommendation, right?

It is unpleasant that it is possible to install mplayer-gui without a skin
then (which gives a related error message at startup), but without the
dependency in mplayer-skin-blue the user does not know at all which skin
version is suitable for their mplayer-gui.

Or is there another way to ensure the mutual dependency?

Bug#981838: Missing dependency

[Ingo Brückl]

Package: mplayer-skin-blue
Version: 1.13-1

The skin requires mplayer-gui version >= 2:1.4.

Ingo

Bug#973598: closed by Michael Biebl (Re: network-manager-gnome: Shows icon nm-dev

[Ingo Brückl]

Michael Biebl wrote on Wed, 03 Feb 2021 14:39:07 +:

> This means you have a connection that is managed by ifupdown and active
> (see /etc/network/interfaces).
>
> My recommendation would be, to remove any entries from /e/n/i and
> managed everything with NetworkManager.

No.

I wrote: "in case all interfaces are managed by NetworkManager". This means
that there is no connection in /etc/network/interfaces.

Please read my bug report carefully and understand that the patch mentioned
there causes the bug.

Without any connection, nm-no-connection should be displayed - not
nm-device-wired.

Ingo

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Ingo Brückl]

Amy Kos wrote on Fri, 29 Jan 2021 19:20:57 +:

> @Ingo Brückl
> May I ask you to do a pull request for libfm-qt too?

Done: https://github.com/lxqt/libfm-qt/pull/621

Ingo

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Ingo Brückl]

On Tue, 12 Jan 2021 16:43:06 + "Amy Kos"  wrote:

> patch available on salsa, commit: 103c4695

Will this make it for bullseye in time? At the moment it seems still missing.

Ingo

Bug#979589: libfm-data: xarchiver command to create archives is wrong

[Ingo Brückl]

Package: libfm-data
Version: 1.3.1-1.1

The xarchiver command to create archives is wrong.
Rather than "--add-to", it must be "--compress".

The bug has been reported upstream (https://github.com/lxde/libfm/pull/69),
but I don't know whether it will be applied before the freeze for bullseye.

Debian GNU/Linux 10.0
Kernel 4.19.0-12-amd64

Bug#978004: authorized_keys: valid key types is missing sk-ssh-ed25519 and sk-ecdsa-sha2-nistp256

[Ingo Wichmann]

Package: ansible
Version: 2.9.6+dfsg-1~bpo10+1
Severity: normal

Dear Maintainer,

I use ansible to deploy authorized_keys files. If I deploy a key of the
new type sk-ecdsa-sha2-nistp...@openssh.com, I get an error message:
invalid key specified: sk-ecdsa-sha2-nistp...@openssh.com

I use the current versions of openssh and ansible from buster-backports.

This problem was fixed in current upstream versions of ansible:
https://github.com/ansible-collections/ansible.posix/pull/30/files

As a workaround I've edited VALID_SSH2_KEY_TYPES:
=== /usr/lib/python3/dist-packages/ansible/modules/system/authorized_key.py ===

VALID_SSH2_KEY_TYPES = [
'ssh-ed25519',
'ecdsa-sha2-nistp256',
'ecdsa-sha2-nistp384',
'ecdsa-sha2-nistp521',
'ssh-dss',
'ssh-rsa',
'sk-ecdsa-sha2-nistp...@openssh.com',
'sk-ssh-ed25...@openssh.com',
]
===

The current version of ansisible in testing/bullseye is 2.9.16+dfsg-1
and probably has the same problem. 

testing/bullseye comes with openssh >= 8.2, which supports these new
types.


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

Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ansible depends on:
ii  openssh-client1:8.4p1-2~bpo10+1
ii  python3   3.7.3-1
ii  python3-crypto2.6.1-9+b1
ii  python3-cryptography  2.6.1-3+deb10u2
ii  python3-distutils 3.7.3-1
ii  python3-dnspython 1.16.0-1
ii  python3-httplib2  0.11.3-2
ii  python3-jinja22.10-2
ii  python3-netaddr   0.7.19-1
ii  python3-yaml  3.13-2

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1
ii  python3-jmespath 0.9.4-1
ii  python3-kerberos 1.1.14-2
ii  python3-libcloud 2.4.0-1
ii  python3-selinux  2.8-1+b1
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.11.0-2

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-6
ii  sshpass  1.06-1

-- no debconf information

Bug#977971: openssh-client: ssh-keygen fails to create ed25519-sk

[Ingo Wichmann]

Package: openssh-client
Version: 1:8.4p1-2~bpo10+1
Severity: normal

Dear Maintainer,

I tried to create a ssh key pair with the command
ssh-keygen -t ed25519-sk

I got the following output:
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Key enrollment failed: invalid format

No key was created.

So I tried again, this time with
ssh-keygen -t ecdsa-sk

I got the following output:
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter file in which to save the key (/home/iw/.ssh/id_ecdsa_sk): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/iw/.ssh/id_ecdsa_sk
Your public key has been saved in /home/iw/.ssh/id_ecdsa_sk.pub

As you can see, a key was created.

I tried the same on another machine running Debian. And on a machine
runnig Ubuntu 20.04. They showed the same behavior.

Regards,

Ingo

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libedit2  3.1-20181209-1
ii  libfido2-11.5.0-2~bpo10+1
ii  libgssapi-krb5-2  1.17-3+deb10u1
ii  libselinux1   2.8-1+b1
ii  libssl1.1 1.1.1d-0+deb10u4
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
pn  libpam-ssh 
pn  monkeysphere   

-- no debconf information

Bug#284002: [PATCH] mdoc: Update operating system release numbers

[Ingo Schwarze]

Hi Colin and Branden,

Colin Watson wrote on Sun, Nov 22, 2020 at 06:18:48PM +:
> On Mon, Nov 23, 2020 at 03:02:49AM +1100, G. Branden Robinson wrote:
>> At 2020-11-22T16:08:56+0100, Ingo Schwarze wrote:

>>> Sure.  I dislike the concept of mdoc.local for more than one reason,
>>> but probably it is good enough for this purposes if there is no
>>> better way in Debian.  If mdoc.local gets automatically updated
>>> during system updates, the proposed string also seems fine.  If it
>>> is considered a user config file and does *not* get updated
>>> automatically, then something like just "Debian GNU/Linux" might
>>> be even better.

>> Hahaha. This is Debian...it's _both_ automatically updated during system
>> updates _and_ considered a user config file!
>> 
>>  https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
>> 
>> "conffiles" have been a dpkg feature for something like 25 years now.
>> Every Debian sysadmin is familiar with the dpkg conffile prompt.  :D

Oh, that concept exists in OpenBSD, too, though not for quite as long.

> [...]
>> I suspect most people don't touch mdoc.local, so it will be
>> automatically updated for them.

In that case, i would still recommend using a string that is constant
over time or putting it somewhere else if that is possible with little
inconvenience.

Yes, automatically updating unchanged user configuration files
works very reliably, and even automatically merging changed user
configuration files often works.  But that doesn't mean that it
should be relied on when there is little benefit, and showing the
operating system version in manual page footers is little benefit
indeed.  I doubt that is worth risking merging inconveniences for
some users.

>> Colin, what do you think?
> 
> Putting this in mdoc.local would more or less work, but if I had to do
> this then I'd lean slightly towards just patching mdoc itself to say the
> right thing for the operating system.

FWIW, that's what i'm doing in the OpenBSD port.

FreeBSD appears to have

  .ds doc-volume-operating-system FreeBSD

in mdoc.local, see

  https://svnweb.freebsd.org/ports/head/textproc/groff/files/mdoc.local

which is *not* a user configuration file in FreeBSD but a constant,
system-owned file.

NetBSD still appears to use the default

  .ds doc-volume-operating-system BSD

in

  
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl2/groff/dist/tmac/doc-common

but it appears NetBSD still uses groff-1.19.2, so that isn't a
particularly useful data point i guess.  In pkgsrc, they have
groff-1.22.4 and they seem to set

  .ds volume-operating-system @@VOLUME_OPERATING_SYSTEM@@

though i'm unsure whether and how that actually works.

It seems Colin has a point that this way is encouraging inconsistency.

> However, if that were the recommendation for distributors then it would
> seem likely to result in a lack of consistency.  Maybe it's worth having
> a little bit of explicit support in upstream groff for what distributors
> are supposed to do?  I'd suggest that groff's configure could gain a
> --with-os-name option whose argument becomes the default value of .Os;
> it can carry on defaulting to "BSD", or the output of uname(3), or
> whatever else as you see fit.  That would (gently) encourage
> distributors to set this in a systematic way.

FWIW, that is essentially what (portable) mandoc does.
It supports a variable OSNAME in ./configure.local .

A few operating systems use that:

  OSNAME="Void Linux"
  OSNAME="Debian"

Examples:
https://github.com/void-linux/void-packages/blob/master/srcpkgs/mdocml/template
https://salsa.debian.org/debian/mdocml/-/blob/master/debian/patches/configure.local.patch

More operating systems do not bother and simply rely on the default
mechanism of using uname(3), which is just fine, too:

Examples:
https://git.alpinelinux.org/aports/tree/main/mandoc/APKBUILD
https://src.fedoraproject.org/rpms/mandoc/blob/master/f/mandoc.spec
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/mandoc/mandoc-1.14.5.ebuild
https://aur.archlinux.org/cgit/aur.git/tree/configure.local?h=mandoc
https://github.com/Homebrew/homebrew-core/blob/master/Formula/mandoc.rb
https://github.com/macports/macports-ports/blob/master/textproc/mandoc/Portfile

Yours,
  Ingo

Bug#284002: [PATCH] mdoc: Update operating system release numbers

[Ingo Schwarze]

; Debian #284002 proposes overriding the "BSD" default with a
> distribution-specific string in the mdoc.local file, and that seems a
> resonable thing to do to me _as a fallback_ when there is no .Os in the
> first place,

Sure, that is one among the resonable options that operating systems have.

> and with the current mnemonic and documenttion, a portable
> GitHub project developer, for instance, has little reason to suspect
> they should use this macro.

Well, groff_mdoc(7) is already quite clear that the .Os macro itself
is mandatory, but the developer of some portable project would
probably see little reason to provide an argument.  That's not a
huge problem because providing arguments is optional, but nothing
is wrong to with providing arguments if desired.

> As far as I can tell, this is already designed for with the string
> "doc-default-operating-system".
> 
> So my proposal is twofold:
> 
> 1. Update groff_mdoc(7) as described above, to encourage mdoc(7) page
>authors to use this to record a package/project name and release.
> 2. Encourage Colin to add the following to mdoc.local:
> 
>   .ds doc-default-operating-system Debian 11 (bullseye)\"
> 
>or similar.
> 
> Thoughts?

Sure.  I dislike the concept of mdoc.local for more than one reason,
but probably it is good enough for this purposes if there is no
better way in Debian.  If mdoc.local gets automatically updated
during system updates, the proposed string also seems fine.  If it
is considered a user config file and does *not* get updated
automatically, then something like just "Debian GNU/Linux" might
be even better.

Yours,
  Ingo

-- 
Ingo Schwarze 
http://www.openbsd.org/   
http://mandoc.bsd.lv/ 

Bug#973598: network-manager-gnome: Shows icon nm-device-wired when being unconnected

[Ingo Brückl]

Package: network-manager-gnome
Version: 1.18.0-1

In case all interfaces are managed by NetworkManager and
no interface has a connection, the icon nm-device-wired
is displayed.

In this case the icon nm-no-connection should be displayed.

The wrong display is caused by the current Debian patch
force-online-state-with-unmanaged-devices. If you replace
nm-device-wired by nm-no-connection there, the applet behaves
as expected.

Debian GNU/Linux 10.0
Kernel 4.19.0-12-amd64

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Ingo Breßler]

Of course, the dmesg is attached.
Let me know if I can provide more info.

Am 25.03.20 um 22:50 schrieb Sudip Mukherjee:

Thanks for testing and debugging it.

Can you please send me your dmesg which shows the trace.

--
Regards
Sudip

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.19.97-v7l+ (dom@buildbot) (gcc version 4.9.3 
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1294 SMP Thu Jan 30 13:21:14 
GMT 2020
[0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[0.00] Memory policy: Data cache writealloc
[0.00] cma: Reserved 256 MiB at 0x1ec0
[0.00] On node 0 totalpages: 1012736
[0.00]   DMA zone: 1728 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 196608 pages, LIFO batch:63
[0.00]   HighMem zone: 816128 pages, LIFO batch:63
[0.00] random: get_random_bytes called from start_kernel+0xc0/0x4e8 
with crng_init=0
[0.00] percpu: Embedded 17 pages/cpu s36928 r8192 d24512 u69632
[0.00] pcpu-alloc: s36928 r8192 d24512 u69632 alloc=17*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 1011008
[0.00] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M 
cma=256M  smsc95xx.macaddr=DC:A6:32:03:DE:E6 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  dwc_otg.lpm_enable=0 console=ttyS0,115200 
console=tty1 root=PARTUUID=ccaf7f28-01 rootfstype=ext4 elevator=deadline 
fsck.repair=yes rootwait
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 3735564K/4050944K available (8192K kernel code, 687K 
rwdata, 2408K rodata, 2048K init, 850K bss, 53236K reserved, 262144K 
cma-reserved, 3264512K highmem)
[0.00] Virtual kernel memory layout:
   vector  : 0x - 0x1000   (   4 kB)
   fixmap  : 0xffc0 - 0xfff0   (3072 kB)
   vmalloc : 0xf080 - 0xff80   ( 240 MB)
   lowmem  : 0xc000 - 0xf000   ( 768 MB)
   pkmap   : 0xbfe0 - 0xc000   (   2 MB)
   modules : 0xbf00 - 0xbfe0   (  14 MB)
 .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
 .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
 .data : 0x(ptrval) - 0x(ptrval)   ( 688 kB)
  .bss : 0x(ptrval) - 0x(ptrval)   ( 851 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 28692 entries in 85 pages
[0.00] rcu: Hierarchical RCU implementation.
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[0.06] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 
4398046511102ns
[0.22] Switching to timer-based delay loop, resolution 18ns
[0.000250] Console: colour dummy device 80x30
[0.000703] console [tty1] enabled
[0.000758] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 108.00 BogoMIPS (lpj=54)
[0.000795] pid_max: default: 32768 minimum: 301
[0.001082] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001114] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001884] CPU: Testing write buffer coherency: ok
[0.002309] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.002969] Setting up static identity map for 0x20 - 0x20003c
[0.003143] rcu: Hierarchical SRCU implementation.
[0.004020] smp: Bringing up secondary CPUs ...
[0.004846] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.005787] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
[0.006687] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
[0.006824] smp: Brought up 1 node, 4 CPUs
[0.006892] SMP: Total of 4 processors activated (432.00 BogoMIPS).
[0.006915] CPU: All CPU(s) started in HYP mode.
[0.006935] CPU: Virtualization extensions available.
[0.007743] devtmpfs: initialized
[0.017953] VFP support v0.3: implementor 41 architecture 3 part 40 variant 
8 rev 0
[0.018185] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.018228] futex hash table entries: 1024 (order: 4, 65536 bytes)
[0.025736] pinctrl core: initialized pinctrl subsystem
[

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Ingo Breßler]

Investigating the error by building the packages of scanbd and libsane 
from source and adding some debugging output turned out that it is not 
an issue of scanbd. Thus, this bug can be closed.


This kernel Oops is triggered by the canon_pp backend of libsane. 
Disabling it in /etc/scanbd/dll.conf resolves the issue and scanbd works 
fine.


This Oops can be triggered directly by calling 'sane-find-scanner -p' 
which explicitly probes for parallel port scanners. Because the 
raspberrypi platform does not have a parallel port, it leads to the 
kernel Oops, I assume.


More specifically, the functions from ieee1284.h such as 
ieee1284_read_status() trigger this Oops. Therefore, it is also not an 
issue of libsane.


At this point, my research stopped and I can't tell if it is a bug of 
package libieee1284 or the kernel itself. Presumably, ieee1284 function 
should be no-op if there is no parallel port(?).


I hope this helps anyone running into this too.

Bug#725859: pdfchain: running the program fails with segmentation fault

[Ingo Wichmann]

I can confirm that this bug still open. pdfchain is unusable for me.

I'd prefer if this package would be removed from stable.

A fix would of course be welcome, too.

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Ingo Breßler]

Thanks for testing, I appreciate it very much!

I am interested which exact commands you were using for qemu?
I haven't used it for emulating the raspi yet and had some trouble finding 
useful/working settings.
The qemu model versatiblepb ('-M versatilepb') works for emulating the initial 
raspi1
and it provides networking. While the latest model I found working is '-M 
raspi3' 
with '-dtb bcm2710-rpi-3-b.dtb' from the raspbian image.
However, I did not get it running with raspi4 related settings
('-cpu cortex-a72' and '-dtb bcm2711-rpi-4-b.dtb' and 4G RAM).

I used the following script for raspi1 emulation and setting up the raspbian 
image
with networking for upgrading the system ('apt-get update && apt-get 
dist-upgrade')
and installing scanbd ('apt-get install scanbd'):

imgfn=2020-02-13-raspbian-buster-lite.img
offset="$(fdisk -l "$imgfn" | awk '/img2/ {print $2}')"
offset=$((offset*512))
mountp=/mnt/raspbian
sudo mkdir -p "$mountp"
sudo mount -v -o offset=$offset -t ext4 "$imgfn" "$mountp"
sudo sh -c "echo > $mountp/etc/ld.so.preload"
sudo umount "$mountp"
qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -serial stdio -audiodev 
none,id=none -drive format=raw,file="$imgfn" -kernel kernel-qemu-4.19.50-buster 
-dtb versatile-pb.dtb -append 'root=/dev/sda2 panic=1 rootfstype=ext4 rw' 
-no-reboot -nic user,model=virtio-net-pci,hostfwd=tcp::5022-:22

After these preparations, to emulate the raspi3 on aarch64, I used:

qemu-system-aarch64 -M raspi3 -cpu cortex-a53 -m 1024 -kernel kernel8.img 
-serial mon:stdio -nographic -audiodev none,id=none -drive 
format=raw,file="$imgfn" -dtb bcm2710-rpi-3-b.dtb -append 'console=ttyAMA0 
root=PARTUUID=738a4d67-02 rootwait rootfstype=ext4 rw' -no-reboot

Right after successful boot, I showed my that scanbd is defunct:

# ps ax | grep scanbd
  245 ?Zsl0:09 [scanbd] 
  422 ttyAMA0  S+ 0:00 grep scanbd

Killing that defunct process and restarting scanbd in foreground produced
an Oops as well (reproducible in this raspi3 qemu setting):

# kill -9 245
root@raspberrypi:~# ps ax | grep scanbd
  424 ttyAMA0  S+ 0:00 grep scanbd
root@raspberrypi:~# export SANE_CONFIG_DIR=/etc/scanbd
root@raspberrypi:~# scanbd -f -c /etc/scanbd/scanbd.conf
scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'
[  248.273492] Unable to handle kernel paging request at virtual address 
ffbefee003bd
[  248.276850] Mem abort info:
[  248.277181]   ESR = 0x9606
[  248.277520]   Exception class = DABT (current EL), IL = 32 bits
[  248.277979]   SET = 0, FnV = 0
[  248.278249]   EA = 0, S1PTW = 0
[  248.278618] Data abort info:
[  248.281919]   ISV = 0, ISS = 0x0006
[  248.282685]   CM = 0, WnR = 0
[  248.283296] swapper pgtable: 4k pages, 39-bit VAs, pgdp = 
17e1e18d
[  248.284288] [ffbefee003bd] pgd=00d66003, 
pud=00d66003, pmd=
[  248.287752] Internal error: Oops: 9606 [#2] PREEMPT SMP
[  248.288350] Modules linked in: sha256_generic cfg80211 rfkill 8021q garp 
stp llc raspberrypi_hwmon hwmon uio_pdrv_genirq uio ip_tables x_tables ipv6
[  248.290447] Process scanbd (pid: 432, stack limit = 0x5b20de07)
[  248.291505] CPU: 1 PID: 432 Comm: scanbd Tainted: G  D W 
4.19.97-v8+ #1294
[  248.291791] Hardware name: Raspberry Pi 3 Model B (DT)
[  248.292221] pstate: 4005 (nZcv daif -PAN -UAO)
[  248.293119] pc : read_port+0xa8/0x138
[  248.293338] lr : __vfs_read+0x60/0x178
[  248.293529] sp : ff800a513cc0
[  248.293709] x29: ff800a513cc0 x28: ffc034f71d00 
[  248.294015] x27:  x26:  
[  248.294281] x25: 4600 x24: 0011 
[  248.294650] x23: ffea3b23 x22: ff800a513e20 
[  248.294950] x21: ffea3b23 x20: ff800a513e20 
[  248.295227] x19: 0001 x18:  
[  248.295493] x17:  x16: 0001 
[  248.295740] x15:  x14:  
[  248.296279] x13:  x12:  
[  248.296943] x11: ffbefee0 x10:  
[  248.297399] x9 : ffea3b23 x8 :  
[  248.297889] x7 : ffc034f71d00 x6 : 03bd 
[  248.298162] x5 :  x4 : ffea3b23 
[  248.298652] x3 : 007f x2 : ffbefee003bd 
[  248.299031] x1 : ffea3b23 x0 : 007f 
[  248.299815] Call trace:
[  248.300313]  read_port+0xa8/0x138
[  248.300845]  __vfs_read+0x60/0x178
[  248.301218]  vfs_read+0x94/0x150
[  248.301902]  ksys_read+0x74/0xf0
[  248.302460]  __arm64_sys_read+0x24/0x30
[  248.304005]  el0_svc_common+0xf4/0x1c0
[  248.304744]  el0_svc_compat_handler+0x30/0x40
[  248.305163]  el0_svc_compat+0x8/0x18

Bug#952668: openjdk-11-jre-headless fails to install in buster, Fatal Error in Frame v ~StubRoutines::call_stub

[Ingo Wilmer]

1046524 kB
SwapFree:1036540 kB
Dirty:36 kB
Writeback: 0 kB
AnonPages:138376 kB
Mapped:56596 kB
Shmem:  6816 kB
Slab:  65092 kB
SReclaimable:  40940 kB
SUnreclaim:24152 kB
KernelStack:3296 kB
PageTables: 2768 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 1551568 kB
Committed_AS:1469420 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
Percpu:  348 kB
HardwareCorrupted: 0 kB
AnonHugePages: 69632 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:   67520 kB
DirectMap2M:  980992 kB


/proc/sys/kernel/threads-max (system-wide limit on the number of threads):
7659


/proc/sys/vm/max_map_count (maximum number of memory map areas a process may 
have):
65530


/proc/sys/kernel/pid_max (system-wide limit on number of process identifiers):
32768



container (cgroup) information:
container_type: cgroupv1
cpu_cpuset_cpus: 0
cpu_memory_nodes: 0
active_processor_count: 1
cpu_quota: -1
cpu_period: 10
cpu_shares: -1
memory_limit_in_bytes: -1
memory_and_swap_limit_in_bytes: -2
memory_soft_limit_in_bytes: -1
memory_usage_in_bytes: 575107072
memory_max_usage_in_bytes: 727941120

VMWare virtualization detected
Steal ticks since vm start: 0
Steal ticks percentage since vm start:  0.000

CPU:total 1 (initial active 1) (1 cores per cpu, 1 threads per core) family 6 
model 85 stepping 4, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, 
sse4.2, popcnt, aes, clmul, 3dnowpref, tsc, tscinvbit
CPU Model and flags from /proc/cpuinfo:
model name  : Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz
flags  : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts nopl tsc_reliable nonstop_tsc cpuid pni 
pclmulqdq ssse3 cx16 sse4_1 sse4_2 movbe popcnt aes hypervisor lahf_lm 
3dnowprefetch pti arat

Memory: 4k page, physical 1010088k(200264k free), swap 1046524k(1036540k free)

vm_info: OpenJDK 64-Bit Server VM (11.0.6+10-post-Debian-2) for linux-amd64 JRE 
(11.0.6+10-post-Debian-2), built on Feb 12 2020 07:40:22 by "unknown" with gcc 
9.2.1 20200203

END.
<<



Thank you in advance for any help
Ingo Wilmer




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

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

Versions of packages openjdk-11-jre-headless depends on:
ih  ca-certificates-java  20190405
ii  java-common   0.71
ii  libasound21.1.8-1
ii  libc6 2.29-10
ii  libcups2  2.2.10-6+deb10u2
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc-s1 10-20200222-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libnss3   2:3.42.1-1+deb10u2
ii  libpcsclite1  1.8.24-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  util-linux2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
pn  fonts-dejavu-extra 
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Ingo Breßler]

Package: scanbd
Version: 1.5.1-5
Severity: important

Dear Maintainer,

I installed the package *scanbd* on the current Raspbian buster on a
Raspberry Pi 4 (4GB).
The behaviour is identical regardless of version '1.5.1-5' or '1.5.1-4'.
The latter version works fine with a Raspberry Pi 2B and Raspbian stretch.

Running the program *scanbd* with default configuration causes a kernel Oops
even without any scanner attached (and with one attached which used
to work fine):

# export SANE_CONFIG_DIR=/etc/scanbd
# /usr/sbin/scanbd -f -c /etc/scanbd/scanbd.conf

Result:

root@rpi4:~# scanbd -f -c /etc/scanbd/scanbd.conf
scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.054930] Internal error: Oops: 206 [#4] SMP ARM

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.147131] Process scanbd (pid: 2082, stack limit = 0x35d03bc2)

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.150005] Stack: (0xd2581e88 to 0xd2582000)

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.152873] 1e80:   c1004d88 d262f300 fe52a6aa 
d2581f60 d2581f60 0001

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.155781] 1ea0: d2581f2c d2581eb0 c03d4f48 c06f1038 ef9c0a50 
0101 0002 07b8

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.158703] 1ec0:    d2581ed0 c0292810 
c03d235c  c09c996c

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.161640] 1ee0:  ef9c0ad0 d2581f04 d2581ef8 c09c996c 
c0292c68 d2581f1c fe52a6aa

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.164581] 1f00: c09cc028 0001 d262f300 beabdb8b d2581f60 
beabdb8b d258 0003

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.167521] 1f20: d2581f5c d2581f30 c03d5108 c03d4f0c c03f5be4 
c03f52b8 d262f300 c1004d88

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.170469] 1f40: d262f301 0001 beabdb8b d258 d2581f94 
d2581f60 c03d5750 c03d5078

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.173430] 1f60: 03bd  03bd fe52a6aa b6f17968 
0001 beabdb8b 000b

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.176395] 1f80: 0003 c02011c4 d2581fa4 d2581f98 c03d57dc 
c03d56e8  d2581fa8

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.179356] 1fa0: c0201000 c03d57d0 0001 beabdb8b 000b 
beabdb8b 0001 

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.182313] 1fc0: 0001 beabdb8b 000b 0003 b6f17968 
b4c32d08  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.182313] 1fc0: 0001 beabdb8b 000b 0003 b6f17968 
b4c32d08  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.185275] 1fe0: 0002 beabdb70  b6de3274 8010 
000b  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.214669] Code: 03a02000 e352 0a0c e2442612 (e5d22000)

It is expected to *not* lead to a kernel Oops and should detect when the 
scanner button was pressed instead.

It is a pity that it does not work as expected when moving to the recent rpi4.
I am investigating this further with the source code which will take some time.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.97-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_DIE, TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages scanbd depends on:
ii  init-system-helpers   1.56+nmu1
ii  libc6 2.28-10+rpi1
ii  libconfuse2   3.2.2+dfsg-1
ii  libdbus-1-3   1.12.16-1
ii  libsane   1.0.27-3.2
ii  libudev1  241-7~deb10u3+rpi1
ii  lsb-base  10.2019051400+rpi1
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  sane-utils1.0.27-3.2
ii  update-inetd  4.49

scanbd recommends no packages.

scanbd suggests no packages.

-- no debconf information

Bug#951536: Debian Bug Tracking System

[Ingo]

Package: nslcd
Version: 0.9.10-2
Severity: normal



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

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

Versions of packages nslcd depends on:
ii  adduser3.118
ii  ca-certificates20190110
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgssapi-krb5-2   1.17-3
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
ii  lsb-base   10.2019051400

Versions of packages nslcd recommends:
ii  bind9-host [host] 1:9.11.5.P4+dfsg-5.1
ii  ldap-utils2.4.47+dfsg-3+deb10u1
ii  libnss-ldapd [libnss-ldap]0.9.10-2
pn  libpam-ldapd | libpam-ldap | libpam-krb5 | libpam-he  
pn  nscd  
pn  nslcd-utils   

Versions of packages nslcd suggests:
ii  kstart  4.2-2

-- debconf information excluded


On first login after boot up on the linux console with a local user I have
to wait one minute to get a shell prompt. After first login I can logoff
and login as usual without delay.

The account is a local unix account with entries in /etc/passwd and
/etc/group and does not has a posixAccount on the ldap directory.
Authorization against the ldap server is done with SASL Proxy
Authorization.

The bug is only seen when quering for the group account. This can simply
verified with removing the 'ldap' postfix at the line
group:  files ldap
in /etc/nsswitch.conf. Without 'ldap' on that line I can first login after
boot up without delay.

If I use ssh or a serial console (on a virtual machine) then there is no
problem. In these cases LOGIN isn't involved so it seems only to be a
problem in conjunction with LOGIN.

As shown in the debug log below the dbus-daemon is timing out the attempt
of nslcd to connect to the ldap server. These are the important lines:

Feb 15 15:52:45 kawa dbus-daemon[345]: [system] Connection has not 
authenticated soon enough, closing it (auth_timeout=3ms, elapsed: 60015ms)
Feb 15 15:52:45 kawa nslcd[403]: [8b4567]  failed to bind 
to LDAP server ldap://kdc-master.home.hoeft-online.de: Can't contact LDAP 
server: Invalid argument

I have verified with tcpdump that nslcd does not output any ip packages
to the ldap server. It just do nothing on the network at this time. The
immediate next attempt of nslcd to connect to the ldap server succeded. 



Here are the configuration files

# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid nslcd

# Logging options, default is info
log syslog debug

# The location at which the LDAP server(s) should be reachable.
uri ldap://kdc-master.home.hoeft-online.de

# The search base that will be used for all queries.
base ou=home,dc=hoeft-online,dc=de

# The LDAP protocol version to use.
#ldap_version 3

# The DN to bind with for normal lookups.
binddn uid=anyuser,ou=people,ou=home,dc=hoeft-online,dc=de

# The DN used for password modifications by root.
#rootpwmoddn cn=admin,dc=example,dc=com

# SSL options
#ssl off
#tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

# SASL options
sasl_mech GSSAPI
krb5_ccname /run/nslcd/nslcd.tkt

# The search scope.
#scope sub



# /etc/nsswitch.conf
passwd: files ldap
group:  files ldap
shadow: files
gshadow:files

hosts:  files resolve [!UNAVAIL=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis



Debug log from the systemd journal
--
Feb 15 15:20:16 kawa systemd[1]: Started Wait for Network to be Configured.
Feb 15 15:20:16 kawa systemd[1]: Reached target Network is Online.
Feb 15 15:20:16 kawa systemd[1]: Starting LSB: LDAP connection daemon...
Feb 15 15:20:16 kawa systemd-timesyncd[260]: Synchronized to time server for 
the first time 178.63.9.212:123 (2.debian.pool.ntp.org).
Feb 15 15:20:19 kawa nslcd[373]: Starting Keep alive Kerberos ticket: k5start.
Feb 15 15:20:19 kawa sshd[384]: Server listening on 0.0.0.0 port 22.
Feb 15 15:20:19 kawa sshd[384]: Server listening on :: port 22.
Feb 15 15:20:19 kawa systemd[1]: Started OpenBSD Secure Shell server.
Feb 15 15:20:20 kawa lvm[234]: Monitoring snapshot 
vg1-deb10.2_recommended+ssh+resolve_no_krb5.lv.
Feb 15 15:20:20 kawa systemd[1]: Started LVM2 poll daemon.
Feb 15 15:20:21 kawa lvm[342]:   Background polling started for 1 logical 
volume(s) in volume group "vg1"
Feb 15 15:20:24 kawa lvm[342]:   5 logical volume(s) in volume group "vg1" 

Bug#867123: [PATCH] mdoc: Update operating system release numbers

[Ingo Schwarze]

Hi Colin,

Colin Watson wrote on Mon, Dec 23, 2019 at 10:37:09PM +:
> On Sat, Dec 21, 2019 at 02:51:23PM +0100, Ingo Schwarze wrote:

>> Consequently, i just pushed the patch to the upstream groff repository,
>> with the following tweaks:
>> 
>>  * I included the following versions which appeared to be missing:
>> - NetBSD 6.0.6 and 7.2
>> - DragonFly 3.0.2 and 3.2.2
>> 
>>  * I did *not* include the following releases because x.y.0 are not
>>included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0.
>>I'm not a DragonFly user and i'm not completely sure what would make
>>most sense for that system, so i just stuck to existing practice as
>>best i could.

> Thanks.  I have no complaints with these - I wasn't completely sure what
> I was doing and am happy for the corrections.

Thanks for checking!

> (There was a small typo, which I've fixed on master.  It's very easy for
> one's eyes to swim when dealing with these macros.)

Thanks for correcting that, and sorry for stealing your commit.
I somehow overlooked that you have upstream groff commit access, too
(which i should have known anyway).

Yours,
  Ingo

Bug#867123: [PATCH] mdoc: Update operating system release numbers

[Ingo Schwarze]

Hello Colin and Guillem,

Colin Watson wrote on Tue, Dec 17, 2019 at 01:15:30PM +:
> On Tue, Dec 17, 2019 at 01:14:06PM +, Colin Watson wrote:

>> Based on a patch from Guillem Jover .
>> 
>> * tmac/doc-common-u: Update NetBSD, OpenBSD, FreeBSD, Darwin, and
>> DragonFly version strings.
>> 
>> * tmac/groff_mdoc.7.man: Synchronize.

> Side note: I am not the biggest fan of this business of encoding a bunch
> of other projects' release history in groff, so please don't take me as
> an advocate of that.  However, I am generally an advocate of the
> position that if one is going to encode this sort of thing then it makes
> sense to keep it up to date.

I completely agree with all you are saying here.

Consequently, i just pushed the patch to the upstream groff repository,
with the following tweaks:

 * I included the following versions which appeared to be missing:
- NetBSD 6.0.6 and 7.2
- DragonFly 3.0.2 and 3.2.2

 * I did *not* include the following releases because x.y.0 are not
   included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0.
   I'm not a DragonFly user and i'm not completely sure what would make
   most sense for that system, so i just stuck to existing practice as
   best i could.

I do think that removing version verification and just printing
whatever the manual page author requests in the same way as mandoc(1)
is already doing it would be an improvement, but that should be discussed
separately, not in this ticket.

Thanks for your patch,
  Ingo

Bug#930337: linux-image-4.19.0-5-amd64: mount fails when deprecated 'nobarrier' option is used in fstab

[Ingo Juergensmann]

Package: src:linux
Version: 4.19.37-3
Severity: critical
Justification: breaks the whole system

Hi!

Just upgraded from stretch to buster to test the whole upgrade thing.

In stretch I was using "nobarrier" option to mount my XFS filesystems. As 
described in https://patchwork.kernel.org/patch/10487561/ (first hit on Google 
search for "xfs nobarrier deprecated") this option no longer exists in 
linux-image 4.19, thus failing the mount of those filesystems that have a 
nobarrier option set. If this option is being set on / it might render the 
system unusable, especially for not-so-experienced users. 
Even when not used on rootfs but only on other filesystems such /home, /var or 
whatever, you'll get dropped to maintenance shell during boot. 

>From my limited point of view it should be safe to remove that option from 
>/etc/fstab during upgrade automatically, but I can understand when you decide 
>to refrain from doing so, of course. But at least you should issue a clear and 
>prominent warning to the user during upgrade when there is a filesystem with 
>nobarrier option in /etc/fstab. 

Ingo

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/vg-sys ro 
matroxfb:mode=1024x768 cgroup_enable=memory swapaccount=1 matroxfb:mode=1024x768

** Not tainted

** Kernel log:
[   59.600616] Console: switching to colour dummy device 80x25
[   59.607426] [TTM] Zone  kernel: Available graphics memory: 12328272 kiB
[   59.607427] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   59.607428] [TTM] Initializing pool allocator
[   59.607432] [TTM] Initializing DMA pool allocator
[   59.618815] IPMI System Interface driver.
[   59.618831] ipmi_si dmi-ipmi-si.0: ipmi_platform: probing via SMBIOS
[   59.618832] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
[   59.618833] ipmi_si: Adding SMBIOS-specified kcs state machine
[   59.618850] ipmi_si IPI0001:00: ipmi_platform: probing via ACPI
[   59.618868] ipmi_si IPI0001:00: [io  0x0ca2] regsize 1 spacing 1 irq 0
[   59.618869] ipmi_si dmi-ipmi-si.0: Removing SMBIOS-specified kcs state 
machine in favor of ACPI
[   59.618869] ipmi_si: Adding ACPI-specified kcs state machine
[   59.618910] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 
0xca2, slave address 0x0, irq 0
[   59.635575] fbcon: mgadrmfb (fb0) is primary device
[   59.635631] Console: switching to colour frame buffer device 128x48
[   59.894060] ipmi_si IPI0001:00: The BMC does not support clearing the recv 
irq bit, compensating, but the BMC needs to be fixed.
[   59.943695] ipmi_si IPI0001:00: Found new BMC (man_id: 0x002a7c, prod_id: 
0x0631, dev_id: 0x20)
[   59.996027] ipmi_si IPI0001:00: IPMI kcs interface initialized
[   60.016048] IPMI SSIF Interface driver
[   60.080153] mgag200 :09:03.0: fb0: mgadrmfb frame buffer device
[   60.106126] [drm] Initialized mgag200 1.0.0 20110418 for :09:03.0 on 
minor 0
[   60.127799] intel_rapl: Found RAPL domain package
[   60.127801] intel_rapl: Found RAPL domain core
[   60.127804] intel_rapl: RAPL package 0 domain package locked by BIOS
[   60.648856] XFS (dm-1): Mounting V4 Filesystem
[   60.757000] XFS (dm-13): Mounting V5 Filesystem
[   60.827464] XFS (dm-2): Mounting V5 Filesystem
[   60.942871] XFS (dm-4): Mounting V5 Filesystem
[   61.226243] XFS (dm-9): Mounting V4 Filesystem
[   61.242370] XFS (dm-7): Mounting V5 Filesystem
[   61.748476] XFS (dm-6): Mounting V5 Filesystem
[   61.761966] XFS (dm-15): Mounting V5 Filesystem
[   61.849682] EXT4-fs (md0): mounting ext3 file system using the ext4 subsystem
[   61.871454] XFS (dm-2): Ending clean mount
[   61.903329] XFS (dm-11): Mounting V4 Filesystem
[   61.937097] XFS (dm-4): Ending clean mount
[   61.999635] XFS (dm-16): Mounting V5 Filesystem
[   62.133219] XFS (dm-7): Ending clean mount
[   62.136097] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
(null)
[   62.185194] XFS (dm-13): Ending clean mount
[   62.277427] XFS (dm-1): Ending clean mount
[   62.467263] XFS (dm-14): Mounting V5 Filesystem
[   62.557575] XFS (dm-15): Ending clean mount
[   62.577938] XFS (dm-6): Ending clean mount
[   62.616781] XFS (dm-9): Ending clean mount
[   63.004229] XFS (dm-16): Ending clean mount
[   63.198045] XFS (dm-14): Ending clean mount
[   63.401731] XFS (dm-11): Ending clean mount
[   63.548116] XFS (dm-3): Mounting V4 Filesystem
[   63.578569] systemd-journald[613]: Received request to flush runtime journal 
from PID 1
[   63.933853] XFS (dm-3): Ending clean mount
[   65.087518] tun: Universal TUN/TAP device driver, 1.6
[   65.372559] Process accounting resumed
[   66.151406] bridge: filtering via arp/ip/ip6tables is no longer available by 
default. Update your scripts to load br_netfilter if you need this.
[   66.187959] br0: 

Bug#927882: Kernel bug: Unable to handle kernel paging request

[Ingo Jauer]

Package: src:linux
Version: 3.16.64-2
Severity: important

Dear Maintainer,

I found a problem with current kernel 3.16.0-8-amd64 of Debian 8.11. 
Similar as described in bug report #927781 the kernel crashes with 
"unable to handle kernel paging request...". This occurs every time and 
immediately when I start the program GIMP from Debian package 'gimp 
2.8.14-1+deb8u2'. The graphical desktop is frozen and the system is 
completely unusable. This does not happen with the previous kernel 
3.16.0-7-amd64.


Kind regards,
Ingo Jauer

-- Package-specific info:
** Version:
Linux version 3.16.0-8-amd64 (debian-ker...@lists.debian.org) (gcc 
version 4.9.2 (Debian 4.9.2-10+deb8u2) ) #1 SMP Debian 3.16.64-2 
(2019-04-01)


** Command line:
root=/dev/sda3 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-8-amd64 
(debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 
4.9.2-10+deb8u2) ) #1 SMP Debian 3.16.64-2 (2019-04-01)

[0.00] Command line: root=/dev/sda3 ro quiet
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] 
reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] 
reserved

[0.00] BIOS-e820: [mem 0x0010-0xdd704fff] usable
[0.00] BIOS-e820: [mem 0xdd705000-0xdd905fff] 
reserved
[0.00] BIOS-e820: [mem 0xdd906000-0xdd916fff] 
ACPI data
[0.00] BIOS-e820: [mem 0xdd917000-0xdda3bfff] 
ACPI NVS
[0.00] BIOS-e820: [mem 0xdda3c000-0xde7d4fff] 
reserved

[0.00] BIOS-e820: [mem 0xde7d5000-0xde7d5fff] usable
[0.00] BIOS-e820: [mem 0xde7d6000-0xde818fff] 
ACPI NVS

[0.00] BIOS-e820: [mem 0xde819000-0xdec52fff] usable
[0.00] BIOS-e820: [mem 0xdec53000-0xdeff3fff] 
reserved

[0.00] BIOS-e820: [mem 0xdeff4000-0xdeff] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] 
reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] 
reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] 
reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] 
reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] 
reserved
[0.00] BIOS-e820: [mem 0xff00-0x] 
reserved

[0.00] BIOS-e820: [mem 0x0001-0x00081eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: System manufacturer System Product Name/P8H77-M PRO, 
BIOS 1505 10/17/2014

[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x81f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask 8 write-back
[0.00]   1 base 8 mask FF000 write-back
[0.00]   2 base 81000 mask FF800 write-back
[0.00]   3 base 81800 mask FFC00 write-back
[0.00]   4 base 81C00 mask FFE00 write-back
[0.00]   5 base 81E00 mask FFF00 write-back
[0.00]   6 base 0E000 mask FE000 uncachable
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
0x7010600070106

[0.00] e820: update [mem 0xe000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xdf000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fd760-0x000fd76f] mapped 
at [880fd760]

[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01b11000, 0x01b11fff] PGTABLE
[0.00] BRK [0x01b12000, 0x01b12fff] PGTABLE
[0.00] BRK [0x01b13000, 0x01b13fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x81ee0-0x81eff]
[0.00]  [mem 0x81ee0-0x81eff] page 2M
[0.00] BRK [0x01b1

Bug#920563: dracut: fails to boot with bash 5 as /bin/sh

[Ingo Saitz]

On Thu, Jan 31, 2019 at 02:24:40PM +0100, Thomas Lange wrote:
> >>>>> On Sun, 27 Jan 2019 02:27:08 +0100, Ingo Saitz  
> >>>>> said:
> 
> > When generating an initrd with bash 5.0-2 installed, the generated 
> initrd
> > fails to boot with the error message:
> I cannot confirm this bug. I have a VM installed with buster and bash
> 5.0-2. After generating a new initrd I can boot this VM without any
> problems. Inside the initrd /bin/sh is a symlink to bash.

This bug happenes during fsck'ing the root filesystem, so maybe your VM
skips this step for some reason? Either you don't have the fsck
utilities for yor system installed, or, looking at the code, if your
filesystem is xfs the fsck step also gets skipped. Or does your bootlog
(dracut adds those lines to dmesg) contain a successful fsck?

I have attached my rdsosreport.txt from a failed boot, maybe I missed
something else. I have split /usr on lvm (only reason for me to need an
initrd now), but it fails while checking / without touching /usr.

Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393
+ cat /lib/dracut/dracut-048+80-1-1
dracut-048+80-1-1
+ cat /proc/cmdline
+ sed -e 
's/\(ftp:\/\/.*\):.*@/\1:***@/g;s/\(cifs:\/\/.*\):.*@/\1:***@/g;s/cifspass=[^
 ]*/cifspass=***/g;s/iscsi:.*@/iscsi:**@/g;s/rd.iscsi.password=[^ 
]*/rd.iscsi.password=**/g;s/rd.iscsi.in.password=[^ 
]*/rd.iscsi.in.password=**/g'
BOOT_IMAGE=/boot/vmlinuz-4.19.18-echse20190126 
root=UUID=d7d9c7eb-fe1e-4cb2-8f04-99fbdbb09d56 ro rootfstype=ext4 
acpi_backlight=vendor slub_debug=P page_poisoning=1 vsyscall=none
+ '[' -f /etc/cmdline ']'
+ for _i in /etc/cmdline.d/*.conf
+ '[' -f /etc/cmdline.d/90lvm.conf ']'
+ echo /etc/cmdline.d/90lvm.conf
/etc/cmdline.d/90lvm.conf
+ cat /etc/cmdline.d/90lvm.conf
+ sed -e 
's/\(ftp:\/\/.*\):.*@/\1:***@/g;s/\(cifs:\/\/.*\):.*@/\1:***@/g;s/cifspass=[^
 ]*/cifspass=***/g;s/iscsi:.*@/iscsi:**@/g;s/rd.iscsi.password=[^ 
]*/rd.iscsi.password=**/g;s/rd.iscsi.in.password=[^ 
]*/rd.iscsi.in.password=**/g'
 rd.lvm.lv=vg_echse/usr 
+ for _i in /etc/cmdline.d/*.conf
+ '[' -f /etc/cmdline.d/95resume.conf ']'
+ echo /etc/cmdline.d/95resume.conf
/etc/cmdline.d/95resume.conf
+ cat /etc/cmdline.d/95resume.conf
+ sed -e 
's/\(ftp:\/\/.*\):.*@/\1:***@/g;s/\(cifs:\/\/.*\):.*@/\1:***@/g;s/cifspass=[^
 ]*/cifspass=***/g;s/iscsi:.*@/iscsi:**@/g;s/rd.iscsi.password=[^ 
]*/rd.iscsi.password=**/g;s/rd.iscsi.in.password=[^ 
]*/rd.iscsi.in.password=**/g'
 resume=UUID=ddd84602-8ad0-4af6-b82b-3aa2395acc10
+ for _i in /etc/cmdline.d/*.conf
+ '[' -f /etc/cmdline.d/95root-dev.conf ']'
+ echo /etc/cmdline.d/95root-dev.conf
/etc/cmdline.d/95root-dev.conf
+ cat /etc/cmdline.d/95root-dev.conf
+ sed -e 
's/\(ftp:\/\/.*\):.*@/\1:***@/g;s/\(cifs:\/\/.*\):.*@/\1:***@/g;s/cifspass=[^
 ]*/cifspass=***/g;s/iscsi:.*@/iscsi:**@/g;s/rd.iscsi.password=[^ 
]*/rd.iscsi.password=**/g;s/rd.iscsi.in.password=[^ 
]*/rd.iscsi.in.password=**/g'
 root=UUID=d7d9c7eb-fe1e-4cb2-8f04-99fbdbb09d56 rootfstype=ext4 
rootflags=rw,noatime
+ cat /proc/self/mountinfo
0 0 0:1 / / rw - rootfs rootfs rw
15 0 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
16 0 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
17 0 0:6 / /dev rw,nosuid,noexec - devtmpfs devtmpfs 
rw,size=1013000k,nr_inodes=253250,mode=755
18 17 0:16 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
19 0 0:17 / /run rw,nosuid,nodev,noexec - tmpfs tmpfs rw,mode=755
+ cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,noexec,size=1013000k,nr_inodes=253250,mode=755 
0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
+ blkid
/dev/sda1: LABEL="root" UUID="d7d9c7eb-fe1e-4cb2-8f04-99fbdbb09d56" TYPE="ext4"
/dev/sda2: UUID="ddd84602-8ad0-4af6-b82b-3aa2395acc10" TYPE="swap"
/dev/sda3: UUID="oCUHd1-CKj6-ZqyF-vAxO-eCx5-1O7n-DMyinG" TYPE="LVM2_member"
/dev/mapper/vg_echse-usr: LABEL="usr" 
UUID="4a46dffa-e0a6-4bda-b49a-40b644c0e7c3" TYPE="ext4"
+ blkid -o udev
ID_FS_LABEL=root
ID_FS_LABEL_ENC=root
ID_FS_UUID=d7d9c7eb-fe1e-4cb2-8f04-99fbdbb09d56
ID_FS_UUID_ENC=d7d9c7eb-fe1e-4cb2-8f04-99fbdbb09d56
ID_FS_TYPE=ext4

ID_FS_UUID=ddd84602-8ad0-4af6-b82b-3aa2395acc10
ID_FS_UUID_ENC=ddd84602-8ad0-4af6-b82b-3aa2395acc10
ID_FS_TYPE=swap

ID_FS_UUID=oCUHd1-CKj6-ZqyF-vAxO-eCx5-1O7n-DMyinG
ID_FS_UUID_ENC=oCUHd1-CKj6-ZqyF-vAxO-eCx5-1O7n-DMyinG
ID_FS_TYPE=LVM2_member

ID_FS_LABEL=usr
ID_FS_LABEL_ENC=usr
ID_FS_UUID=4a46dffa-e0a6-4bda-b49a-40b644c0e7c3

Bug#920563: dracut: fails to boot with bash 5 as /bin/sh

[Ingo Saitz]

Package: dracut
Version: 048+80-1
Severity: important

Dear Maintainer,

When generating an initrd with bash 5.0-2 installed, the generated initrd
fails to boot with the error message:

> /lib/fs-lib.sh: line 109: _drv=e2fsck fsck_drv_com

The behaviour of "local" declared variables in POSIX mode seems to have
changed, which does no longer allow them to be overwritten by eval. This
is only the case if bash is executed as /bin/sh. Since "local" is not a
part of POSIX, I consider this to be dracut's fault and not bash's.

I wrote a small shell script (a reduced version of fs-lib.sh) to
demonstrates the problem:

#!/bin/sh
fsck_drv_com() {
echo "issuing $_drv"
_out=$($_drv)
}
fsck_single() {
local _drv="_drv=true fsck_drv_com"
eval "$_drv"
}
fsck_single

This works with /bin/bash as interpreter, also with /bin/sh linked to
dash, and it used to work with bash 4.4.18-3.1. It also produces the
correct output without the "local" keyword:

> issuing true

When /bin/sh is a link to bash 5.0-2 the script fails with the following
output:

> issuing _drv=true fsck_drv_com
> /tmp/bash-error.sh: line 5: _drv=true: command not found

I can currently think of three options:

- either dracut has to be rewritten to be fully POSIX-compliant

- dracut has to rely on a shell, that guarantees to enhance POSIX with
  the local keyword

- dracut has to make sure /init is executed by /bin/bash when
  /bin/sh is a symlink to bash.

The 3rd option could be easily accomplished by adding the following line
to the top of /init (/usr/lib/dracut/modules.d/99base/init.sh) after the
initial comment block:

[ -f /bin/bash ] && [ "$BASH" = "/bin/sh" ] && exec /bin/bash /init

Ingo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.18-echse20190126 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dracut depends on:
ii  dracut-core  048+80-1

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Ingo Saitz]

On Fri, Jan 11, 2019 at 09:52:46PM -0500, Jo Shields wrote:
> Maybe a typo in debian/rules? I do my builds in a chroot, this kind of thing 
> shouldn't happen 

I just tried rebuilding mono 5.16.0.220+dfsg3-1 in a clean chroot, and
the dependencies look good:

Package: libmono-system4.0-cil
Source: mono
Version: 5.16.0.220+dfsg3-1
Architecture: all
Maintainer: Debian Mono Group 
Installed-Size: 3101
Depends: libc6 (>= 2.28) | libc6.1 (>= 2.28) | libc0.1 (>= 2.28), 
libmono-corlib4.5-cil (>= 5.16.0.220), libmono-security4.0-cil (>= 4.6.1.3), 
libmono-system-configuration4.0-cil (>= 4.0.0~alpha1), 
libmono-system-xml4.0-cil (>= 4.6.1.3), mono-runtime (>= 5.16.0.220), 
mono-runtime (<< 5.16.0.221)
Recommends: ca-certificates-mono (= 5.16.0.220+dfsg3-1)
Suggests: libasound2 (>> 1.0.18), libgamin0
Section: cli-mono
Priority: optional
Homepage: http://www.mono-project.com/
Description: Mono System libraries (for CLI 4.0)
 Mono is a platform for running and developing applications based on the
 ECMA/ISO Standards. Mono is an open source effort led by Xamarin.
 Mono provides a complete CLR (Common Language Runtime) including compiler and
 runtime, which can produce and execute CIL (Common Intermediate Language)
 bytecode (aka assemblies), and a class library.
 .
 This package contains the BCL (Base Class Libraries) of Mono for CLI 4.0.


I'll keep the buildroot around till this bug can be closed, just query
me if you want additional information about it.

Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Ingo Saitz]

Package: libmono-system4.0-cil
Version: 5.16.0.220+dfsg3-1
Severity: important

Dear Maintainer,

libmono-system4.0-cil contains in its dependencies on amd64 a dependency
on mono-runtime-common 5.18:

Depends: ..., mono-runtime (>= 5.16.0.220), mono-runtime-common (>= 
5.18.0.225), mono-runtime (<< 5.16.0.221)

This probably will never work, since mono-runtime depends on the exact
same version of mono-runtime-common. The dependency is not listed in
debian/control, so it seems it must have been introduced by
${misc:Depends} or ${cli:Depends} - was this package built on a system
with mono 5.18 packages installed?


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.12-echse-4.1920181222 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libmono-system4.0-cil depends on:
ii  libc62.28-4
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-2
ii  libmono-security4.0-cil  4.6.2.7+dfsg-2
ii  libmono-system-configuration4.0-cil  4.6.2.7+dfsg-2
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-2
ii  mono-runtime 4.6.2.7+dfsg-2

Versions of packages libmono-system4.0-cil recommends:
ii  ca-certificates-mono  4.6.2.7+dfsg-2

Versions of packages libmono-system4.0-cil suggests:
ii  libasound2  1.1.7-2
ii  libgamin0   0.1.10-5+b1

-- no debconf information

Bug#906119: Gratuitous sexual references

[Ingo Ruhnke]

Could anybody clarify the scope of these new censorship measurements?
Is it just $PATH that needs to be purged of forbidden words or is the
whole filesystem affected? The similar youtube-dl tool for example
contains plugins for Slutload and other porn sites:

/usr/lib/python3/dist-packages/youtube_dl/extractor/slutload.py

Bug#915582: Acknowledgement (Installs non-free binaries from cisco and google again)

[Ingo Saitz]

After setting the options in my previous mail to false i found
firefox still was downloading binaries of libgmpopenh264.so and
libwidevinecdm.so.

I looked into the firefox sources (64.0~b12-2), and the installation
seems to be done by
toolkit/mozapps/extensions/internal/ProductAddonChecker.jsm by
ProductAddonChecker.getProductAddonList(). There is a config option
GMPPrefs.KEY_UPDATE_ENABLED to disable this, which is defined in
toolkit/modules/GMPUtils.jsm line 118. Setting this to false seems to
disable the binary blob downloads.

So in /etc/firefox/firefox.js (debian/browser.js.in in the source), the
option

pref("media.gmp-gmpopenh264.enabled", false);

should be changed to

pref("media.gmp-manager.updateEnabled", false);

Users needing to enable the EME and OpenH264 binaries can still change
this option in about:config.

Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393

Bug#915582: Installs non-free binaries from cisco and google again

[Ingo Saitz]

Package: firefox
Version: 62.0.3-1
Severity: serious
Justification: Policy §2.2.1


Mozilla changed the config options for the openh264 codec. The option
listed in /etc/firefox/firefox.fs (media.gmp-gmpopenh264.enabled) seems
to be no longer in use, instead about:config now lists the options

media.gmp-provider.enabled
media.gmp.decoder.enabled
media.gmp-widevinecdm.enabled
media.gmp.trial-create.enabled

And in addition to libgmpopenh264.so it also downloads and installs into
~/.mozilla a libwidevinecdm.so binary. Its license (contained in the
zip-archive from which it gets installed) reads

> "Google Inc. and its affiliates ("Google") own all legal right, title and
> interest in and to the content decryption module software ("Software") and
> related documentation, including any intellectual property rights in the
> Software. You may not use, modify, sell, or otherwise distribute the Software
> without a separate license agreement with Google.  The Software is not open
> source software.
> 
> If you are interested in licensing the Software, please contact
> widev...@google.com.

Cf. bug #769716 i believe these automated downloads should be disabled by
default in debian packages.

Thx

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.4-echse20181124 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages firefox depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-2
ii  libasound21.1.7-1+b1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.28-1
ii  libcairo-gobject2 1.16.0-1
ii  libcairo2 1.16.0-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.2.0-10
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.1-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.40-1
ii  libpango-1.0-01.42.4-4
ii  libsqlite3-0  3.26.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-10
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-1
ii  libxcb1   1.13.1-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec58  7:4.0.3-1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-5
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16.1-1
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-2

-- no debconf information

-- debsums errors found:
debsums: package firefox is not installed

Bug#914790: fs-uae-launcher: Failure recompiling python module with python3.7

[Ingo Saitz]

Package: fs-uae-launcher
Version: 2.8.4+dfsg-1
Severity: important

Dear Maintainer,

On upgrading python from version 3.6 to 3.7, the installation fails on
fs-uae-launcher with the following error message:

Setting up python3 (3.7.1-2) ...
running python rtupdate hooks for python3.7...
  File "/usr/share/fs-uae-launcher/OpenGL/GL/SGIX/async.py", line 58
from OpenGL.raw.GL.SGIX.async import *
^
SyntaxError: invalid syntax

error running python rtupdate hook fs-uae-launcher

This is due to "async" becoming a reserved keyword in python3.7. The
pyopengl maintainer decided to rename the module to async_, see #903218.
Thus, changing "async" to "async_" in lines 58 and 59 allow python3 to
be configured properly while upgrading the system to python 3.7 or
installing fs-uae-launcher on a python 3.7 system.

After checking the source this does apply to the fs-uae-arcade package
too. Attached patch should fix the error in both packages. Though you
might want to add a versioned depends on python3-opengl (>= 3.1.0+dfsg-2)
to enable partial upgrades.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.2-echse20181115 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fs-uae-launcher depends on:
ii  fs-uae  2.8.4+dfsg-1
ih  python3 3.7.1-2
ii  python3-pyqt5   5.11.3+dfsg-1+b1
ii  python3-pyqt5.qtopengl  5.11.3+dfsg-1+b1
ii  python3-setuptools  40.5.0-1

fs-uae-launcher recommends no packages.

fs-uae-launcher suggests no packages.

-- no debconf information
Description: Change async module to async_
 This was done by pyopengl package (see #903218) since async
 became a reserved keyword in python 3.7

Index: fs-uae-2.8.4+dfsg/arcade/OpenGL/GL/SGIX/async.py
===
--- fs-uae-2.8.4+dfsg.orig/arcade/OpenGL/GL/SGIX/async.py
+++ fs-uae-2.8.4+dfsg/arcade/OpenGL/GL/SGIX/async.py
@@ -55,8 +55,8 @@ from OpenGL import platform, constant, a
 from OpenGL import extensions, wrapper
 import ctypes
 from OpenGL.raw.GL import _types, _glgets
-from OpenGL.raw.GL.SGIX.async import *
-from OpenGL.raw.GL.SGIX.async import _EXTENSION_NAME
+from OpenGL.raw.GL.SGIX.async_ import *
+from OpenGL.raw.GL.SGIX.async_ import _EXTENSION_NAME
 
 def glInitAsyncSGIX():
 '''Return boolean indicating whether this extension is available'''
Index: fs-uae-2.8.4+dfsg/launcher/OpenGL/GL/SGIX/async.py
===
--- fs-uae-2.8.4+dfsg.orig/launcher/OpenGL/GL/SGIX/async.py
+++ fs-uae-2.8.4+dfsg/launcher/OpenGL/GL/SGIX/async.py
@@ -55,8 +55,8 @@ from OpenGL import platform, constant, a
 from OpenGL import extensions, wrapper
 import ctypes
 from OpenGL.raw.GL import _types, _glgets
-from OpenGL.raw.GL.SGIX.async import *
-from OpenGL.raw.GL.SGIX.async import _EXTENSION_NAME
+from OpenGL.raw.GL.SGIX.async_ import *
+from OpenGL.raw.GL.SGIX.async_ import _EXTENSION_NAME
 
 def glInitAsyncSGIX():
 '''Return boolean indicating whether this extension is available'''

Bug#893444: mandoc.1: Some fixes in the manual

[Ingo Schwarze]

 by now.

> Test nr. 27:
> 
> Split lines longer than 80 characters into two or more
> lines.  Apropriate break points are the end of a sentence or subordinate
> clause.
> 
> mandoc.1: line 995length 95

Obviously a bogus report.  Such a line does not exist.

 $ grep -E '.{79}' mandoc.1 
 $ grep -E '.{78}' mandoc.1 
.D1 Nm Ns : Ar file : Ns Ar line : Ns Ar column : level : message : macro args
A table layout specification contains more than two consecutive vertical bars.
the characters following it are used as the arguments to the request or macro.

The longest lines are exactly 78 characters.

> --- mandoc.1  2017-09-18 14:10:53.0 +
> +++ mandoc.1.new  2018-03-18 19:28:01.0 +
> @@ -120,7 +120,7 @@ With
>  all input files are interpreted as
>  man(7).
>  By default, the input language is automatically detected for each file:
> -if the the first macro is
> +if the first macro is
>  \fB\\fR
>  or
>  \fB\\fR,

Fixed four months ago.

So, there is not a single valid point in this report.
I suggest to close it as invalid.

Yours,
  Ingo

Bug#887423: snmptrapd: Systemd service unit definition of snmptrapd ignoring settings in /etc/default/snmptrapd

[Ingo Rauschenberg]

Package: snmptrapd
Version: 5.7.3+dfsg-1.7
Severity: normal

Dear Maintainer,

I have to use the snmptrapd with some special mib-files from the
vendors of my hardware suppliers (like Dell, Brocate, Enterasys, Sun,
Rittal, ...).
Therefor I defined the MIBSDIR environment variable on my own in the
file /etc/default/snmptrapd.

With the introduction of systemd there is a systemd service unit file
provided in the package snmptrapd, located at
/lib/systemd/system/snmptrapd.service
Unfortunately this file contains the environment MIBSDIR hard coded.

Because I would prefer to change only files in /etc for configuration
issues I would ask, if you can change the systemd service unit file like
this:
---
[Unit]
Description=Simple Network Management Protocol (SNMP) Trap Daemon.
After=network.target
ConditionPathExists=/etc/snmp/snmptrapd.conf

[Service]
EnvironmentFile=/etc/default/snmptrapd
Type=simple
ExecStart=/usr/sbin/snmptrapd -f $TRAPDOPTS
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
---

With the parameter EnvironmentFile you can read the configuration from
/etc/default/snmptrapd and so you only have one file for the old and the
new init way.

I hope this helps and you can realize again the flexibility of the
configuration.

Best regards,
Ingo Rauschenberg





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

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages snmptrapd depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libmariadbclient18   10.1.26-0+deb9u1
ii  libsnmp305.7.3+dfsg-1.7
ii  libwrap0 7.6.q-26
ii  snmpd5.7.3+dfsg-1.7
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages snmptrapd recommends:
ii  perl  5.24.1-3+deb9u2

snmptrapd suggests no packages.

-- Configuration Files:
/etc/default/snmptrapd changed:
MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp:/etc/snmp/mibs/Dell:/etc/snmp/mibs/SUN:/etc/snmp/mibs/APC:/etc/snmp/mibs/SUN-MC:/etc/snmp/mibs/Brocade_Fabric_OS_v7.0.2d:/etc/snmp/mibs/Infortrend:/etc/snmp/mibs/Rittal:/etc/snmp/mibs/enterasys
MIBS=ALL
TRAPDRUN=yes
TRAPDOPTS="-Lsd -c /etc/snmp/snmptrapd.conf"

/etc/snmp/snmptrapd.conf changed:
disableAuthorization yes
traphandle default /usr/bin/perl /etc/a1-management/snmp/print_traps.pl


-- no debconf information

Bug#879458: inputlirc sends all keys as unknown keycodes (KEYCODE_xxx) instead of proper name to lirc socket.

[Ingo Schneider]

Package: inputlirc
Version: 23-2+b2
Severity: grave
Tags: patch
Justification: renders package unusable

Patch to fix:
--- Makefile.old    2017-10-21 19:59:32.0 +0200
+++ Makefile    2017-10-21 19:34:22.0 +0200
@@ -30 +30 @@
-names.h: /usr/include/linux/input.h gennames
+names.h: /usr/include/linux/input-event-codes.h gennames


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')

Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de:en_GB (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages inputlirc depends on:
ii  libc6  2.24-11+deb9u1

inputlirc recommends no packages.

Versions of packages inputlirc suggests:
ii  input-utils  1.0-1.1+b1
pn  lirc 

Bug#875436: libgnuradio-fcdproplus3.7.11: duplicate file with libgnuradio-fcdproplus3.7.10

[Ingo Saitz]

Package: libgnuradio-fcdproplus3.7.11
Version: 3.7.25.4b6464b-3
Severity: normal

Dear Maintainer,

Upgrading gnuradio packages fails with the following error:

Preparing to unpack .../libgnuradio-fcdproplus3.7.11_3.7.25.4b6464b-3_amd64.deb 
...
Unpacking libgnuradio-fcdproplus3.7.11 (3.7.25.4b6464b-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgnuradio-fcdproplus3.7.11_3.7.25.4b6464b-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/pkgconfig/gnuradio-fcdproplus.pc', which is also in 
package libgnuradio-fcdproplus3.7.10 3.7.25.4b6464b-2+b2
Preparing to unpack .../libgnuradio-iqbalance3.7.11_0.37.2-8_amd64.deb ...
Unpacking libgnuradio-iqbalance3.7.11 (0.37.2-8) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgnuradio-iqbalance3.7.11_0.37.2-8_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/pkgconfig/gnuradio-iqbalance.pc', which is also in 
package libgnuradio-iqbalance3.7.10 0.37.2-7+b2
Errors were encountered while processing:
 /var/cache/apt/archives/libgnuradio-fcdproplus3.7.11_3.7.25.4b6464b-3_amd64.deb
 /var/cache/apt/archives/libgnuradio-iqbalance3.7.11_0.37.2-8_amd64.deb

Seems like libgnuradio-fcdproplus3.7.11 is issing a Replaces: or
Conflicts: with libgnuradio-fcdproplus3.7.10. Same for
libgnuradio-fcdproplus3.7.11, though I think one bug report would
suffice.

Thanks, Ingo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.9-echse20170825 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libgnuradio-fcdproplus3.7.11 depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4+b1
ii  libboost-system1.62.0  1.62.0+dfsg-4+b1
ii  libc6  2.24-17
ii  libgcc11:7.2.0-4
ii  libgnuradio-audio3.7.113.7.11-1+b1
ii  libgnuradio-blocks3.7.11   3.7.11-1+b1
ii  libgnuradio-pmt3.7.11  3.7.11-1+b1
ii  libgnuradio-runtime3.7.11  3.7.11-1+b1
ii  libhidapi-libusb0  0.8.0~rc1+git20140818.d17db57+dfsg-1
ii  liblog4cpp5v5  1.1.1-3
ii  libstdc++6 7.2.0-4
ii  libusb-1.0-0   2:1.0.21-2

Versions of packages libgnuradio-fcdproplus3.7.11 recommends:
iu  gr-fcdproplus  3.7.25.4b6464b-3

libgnuradio-fcdproplus3.7.11 suggests no packages.

Bug#872507: Config option causes segfault

[Ingo Jürgensmann]

Hi Marco!

With the help of Kees in Linux echomail area I found out that the following 
config option causes the segfault: 

options(time Any-2359) NoHold

When commenting this out, ifcico is working as expected. As this is not an easy 
to find error, I’d like to recommend to change the default config accordingly. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#872507: [ifcico] ifcico segfaults when started

[Ingo Juergensmann]

r/lib/ifmail/ifcico

Program received signal SIGSEGV, Segmentation fault.
0xd493 in ?? ()
(gdb) bt
#0  0xd493 in ?? ()
#1  0xe5c9 in ?? ()
#2  0xeb19 in ?? ()
#3  0xfb0b in ?? ()
#4  0x00005556ccfc in ?? ()
#5  0xf997 in ?? ()
#6  0xb4ec in ?? ()
#7  0x778572b1 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#8  0xb83a in ?? ()
(gdb)

Do you have any idea what might be going on?

Ingo
2:2452/413 ;)

--- System information. ---
Architecture: Kernel:   Linux 4.9.0-3-amd64

Debian Release: buster/sid
  500 unstablewww.deb-multimedia.org   500 unstable
ftp.de.debian.org   500 unstabledownload.jitsi.org
--- Package information. ---
Depends   (Version) | Installed
===-+-===
libc6 (>= 2.14) | libgdbm3 (>= 1.8.3) |
ifmail  | openbsd-inetd   |  OR
inet-superserver|

Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Ciao...//  Fon: 0381-2744150
  Ingo   \X/   http://blog.windfluechter.net
Please don't share this address with Facebook or Google!
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

Bug#858495: glusterfs-client: glusterfs fails to mount storage

[Ingo Jürgensmann]

Hi!

I experienced issues with mounting glusterfs storage after I upgraded some 
clients from Jessie to Stretch, although I’m not using Infiniband at all: 

[2017-06-24 12:51:53.240389] I [MSGID: 100030] [glusterfsd.c:2454:main] 
0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.8.8 (args: 
/usr/sbin/glusterfs --read-only --fuse-mountopts=nodev,noexec 
--volfile-server=192.168.254.254 --volfile-id=/le --fuse-mountopts=nodev,noexec 
/etc/letsencrypt.sh/certs)
[2017-06-24 12:51:54.534826] E [mount.c:318:fuse_mount_sys] 0-glusterfs-fuse: 
ret = -1

[2017-06-24 12:51:54.534896] I [mount.c:365:gf_fuse_mount] 0-glusterfs-fuse: 
direct mount failed (Invalid argument) errno 22, retry to mount via fusermount
[2017-06-24 12:51:56.668254] I [MSGID: 101190] 
[event-epoll.c:628:event_dispatch_epoll_worker] 0-epoll: Started thread with 
index 1
[2017-06-24 12:51:56.671649] E [glusterfsd-mgmt.c:1590:mgmt_getspec_cbk] 
0-glusterfs: failed to get the 'volume file' from server
[2017-06-24 12:51:56.671669] E [glusterfsd-mgmt.c:1690:mgmt_getspec_cbk] 
0-mgmt: failed to fetch volume file (key:/le)
[2017-06-24 12:51:57.014502] W [glusterfsd.c:1327:cleanup_and_exit] 
(-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_handle_reply+0x90) 
[0x7fbea36c4a20] -->/usr/sbin/glusterfs(mgmt_getspec_cbk+0x494) 
[0x55fbbaed06f4] -->/usr/sbin/glusterfs(cleanup_and_exit+0x54) [0x55fbbaeca444] 
) 0-: received signum (0), shutting down
[2017-06-24 12:51:57.014564] I [fuse-bridge.c:5794:fini] 0-fuse: Unmounting 
'/etc/letsencrypt.sh/certs'.
[2017-06-24 16:44:45.501056] I [MSGID: 100030] [glusterfsd.c:2454:main] 
0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.8.8 (args: 
/usr/sbin/glusterfs --read-only --fuse-mountopts=nodev,noexec 
--volfile-server=192.168.254.254 --volfile-id=/le --fuse-mountopts=nodev,noexec 
/etc/letsencrypt.sh/certs)
[2017-06-24 16:44:45.504038] E [mount.c:318:fuse_mount_sys] 0-glusterfs-fuse: 
ret = -1

[2017-06-24 16:44:45.504084] I [mount.c:365:gf_fuse_mount] 0-glusterfs-fuse: 
direct mount failed (Invalid argument) errno 22, retry to mount via fusermount

I tried to find a solution using Google and such, but in the end I joined 
#gluster on Freenode and asked there. 

The answer was: 

> JoeJulian
> ij__: debian breaks apart ipv4 and ipv6. You'll need to remove the ipv6 ::1 
> address from localhost in /etc/hosts or recombine your ip stack (it's a 
> sysctl thing)
> JoeJulian
> It has to do with the decisions made by the debian distro designers. All 
> debian versions should have that problem. (yes, server side).

The tip with disabling ::1 in /etc/hosts worked for Jessie server and Stretch 
clients, but when the servers got upgraded to Stretch as well, this didn’t help 
anymore. 

What actually worked for me, was the tip in 
http://lists.gluster.org/pipermail/gluster-users/2017-February/029938.html to 
use "gluster volume set  transport.address-family inet“

I can’t comment on the statement that there’s something strange in Debian with 
IPv4 and IPv6 that needs to get „recombined“ in sysctl.conf. However, my 
findings do support that suspicion that the error is caused by IPv6 as it 
immediatedly worked when just using IPv4 in glusterfs. 

Would be nice if this issue could be fixed in Stretch. 


-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#864820: xul-ext-greasemonkey: userscripts no longer available with firefox 54

[Ingo Saitz]

Package: xul-ext-greasemonkey
Version: 3.8-1
Severity: important

Dear Maintainer,

After updating firefox to version 54.0, the list of userscripts in
about:addons is empty, and the installed scripts aren't applied to the
webpages anymore. This seems to be issue #2488 in greasemonkey, which is
solved in version 3.11 of greasemonkey.

https://github.com/greasemonkey/greasemonkey/issues/2488

When started from a terminal, firefox outputs the following error:

1497523208324   addons.manager  ERROR   Exception calling provider 
.getAddonsByTypes: TypeError: GM_util.getPreferredLocale is 
not a function (chrome://greasemonkey-modules/content/script.js:148:9) JS Stack 
trace: getbestlocalizat...@script.js:148:9 < 
script_getlocalizeddescript...@script.js:156:20 < scriptad...@addons4.js:98:3 < 
scriptaddonfactorybyscr...@addons4.js:74:28 < 
AddonProvider_getAddonsByTypes/<@addons4.js:50:27 < 
addonprovider_getaddonsbyty...@addons4.js:49:7 < 
callprovideras...@addonmanager.jsm:298:12 < 
promiseCallProvider/<@AddonManager.jsm:322:53 < 
prom...@promise-backend.js:390:5 < promisecallprovi...@addonmanager.jsm:321:10 
< getAddonsByTypes/<@AddonManager.jsm:2556:36

Also, setting intl.locale.matchOS to false does get the scripts working
again. But since the default in firefox is true, this should only be a
workaround an greasemonkey should be updated to a fixed version.

Thanks,
Salz

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-echse20170504 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xul-ext-greasemonkey depends on:
ii  firefox  54.0-1

xul-ext-greasemonkey recommends no packages.

xul-ext-greasemonkey suggests no packages.

-- no debconf information

Bug#864047: [mgetty] mgetty neither started from inttab nor systemd

[Ingo Juergensmann]

Package: mgetty
Version: 1.1.36-3+b1
Severity: normal

--- Please enter the report below this line. ---

Hi!

Current mgetty does not start from inittab as well as it is not started
by systemd (at least on my sid system).

According to
https://www.raspberrypi.org/forums/viewtopic.php?f=66=132542 there's
something missing for systemd. When I follow those instructions, mgetty
works for me.

I'm unsure if this qualifies for release-critical or not. At least it's
easy to fix...

Regards,
Ingo

--- System information. ---
Architecture: Kernel:   Linux 4.9.0-3-amd64

Debian Release: 9.0
  500 unstablewww.deb-multimedia.org   500 unstable
ftp.de.debian.org   500 unstabledownload.jitsi.org
--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6   (>= 2.14) | logrotate(>= 3.5.4-1) | dpkg
(>= 1.15.4)  |  OR install-info  |

Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
mgetty-fax|




-- 
Ciao...//  Fon: 0381-2744150
  Ingo   \X/   http://blog.windfluechter.net
Please don't share this address with Facebook or Google!
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

Bug#808261: nautilus refuses to connect to owncloud remote folder (unacceptable TLS certificate)

[Ingo Heinrich]

Just in case someone else happens to stumble across this ---

Add your owncloud ssl certificate to list of trusted certificates. Works
with self-signed certificates:
1. Save certificate to '/usr/local/share/ca-certificates'. PEM format
worked for me. Make sure your file has '.crt' suffix.
2. Execute 'sudo update-ca-certificates'.

Regards,
Ingo

Bug#851066: Latest checksums for Flash Plugin not available at https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/

[Ingo]

> The problem is not a technical one, but just a simple question of
maintenance of the site "debian.people.org/~bartm/..." in order to
follow the latest version from Adobe.

Thats right, seems Bart Marten no longer receives mail directed to his
debian account. I found another email address in the *.deb package,
probably he will react on mails to it:

ba...@knars.be

Bug#850769:

[Ingo Bauersachs]

tags 850769 patch

Attached patch is based on upstream diff [1], also available as a package on 
Mentors [2].

Ingo

[1] 
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libdbusmenu/trusty-updates/revision/51
[2] https://mentors.debian.net/package/libdbusmenu





replace-child-added-gtk3-debdiff.diff
Description: Binary data

Bug#850769: libdbusmenu-gtk4: Sends Ubuntu-specific signal child-added

[Ingo Bauersachs]

Package: libdbusmenu-gtk4
Version: 12.10.2-1
Severity: important
Tags: upstream

Dear Maintainer,

libdbusmenu sends the Gtk signal child-added to modify menus.
This signal is/was Ubuntu specific and should be replaced
with the insert signal. Sending child-added instead of
insert makes modifying menus of an AppIndicator tray icon
impossible, resulting in the following error message and
potentially segfaulting.

GLib-GObject-WARNING **:
/build/glib2.0-m2w47E/glib2.0-2.50.2/./gobject/gsignal.c:2523: signal 'child-
added' is invalid for instance '0x7f95243242c0' of type 'GtkMenu'

This has been fixed upstream. Please see Ubuntu bug
#1203888 for further information.

Bug #727533 is maybe related.



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

Kernel: Linux 4.8.0-1-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
Init: systemd (via /run/systemd/system)

Versions of packages libdbusmenu-gtk4 depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libdbusmenu-glib412.10.2-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libglib2.0-0 2.50.2-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  multiarch-support2.24-8

libdbusmenu-gtk4 recommends no packages.

libdbusmenu-gtk4 suggests no packages.

-- no debconf information

Bug#848881: [gpart] Floating point exception when scanning

[Ingo Jürgensmann]

Am 20.12.2016 um 18:24 schrieb Baruch Even <bar...@ev-en.org>:

> Can you please run it under gdb and capture the output of the command: 
> bt
> bt full

Reading symbols from /usr/sbin/gpart...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/sbin/gpart -f /dev/lv/Elite3

Program received signal SIGFPE, Arithmetic exception.
0x75f0 in ?? ()
(gdb) bt
#0  0x75f0 in ?? ()
#1  0x677c in ?? ()
#2  0x77a5c2b1 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x7409 in ?? ()
(gdb) bt full
#0  0x75f0 in ?? ()
No symbol table info available.
#1  0x677c in ?? ()
No symbol table info available.
#2  0x77a5c2b1 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x7409 in ?? ()
No symbol table info available.
(gdb)

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#848881: [gpart] Floating point exception when scanning

[Ingo Juergensmann]

Package: gpart
Version: 1:0.3-3
Severity: grave

--- Please enter the report below this line. ---
Hi!

When trying to examine a volume on LVM, I get a floating point exception
quite instantly:


# strace -f gpart -f /dev/lv/Elite3
execve("/usr/sbin/gpart", ["gpart", "-f", "/dev/lv/Elite3"], [/* 59 vars
*/]) = 0


brk(NULL)   = 0x5564d0c19000



access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
directory)


mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f959d326000


access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)


open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3



fstat(3, {st_mode=S_IFREG|0644, st_size=238540, ...}) = 0



mmap(NULL, 238540, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f959d2eb000



close(3)= 0



access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
directory)


open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3



read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\3\2\0\0\0\0\0"...,
832) = 832


fstat(3, {st_mode=S_IFREG|0755, st_size=1685264, ...}) = 0



mmap(NULL, 3791264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f959cd69000


mprotect(0x7f959cefe000, 2093056, PROT_NONE) = 0



mmap(0x7f959d0fd000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7f959d0fd000


mmap(0x7f959d103000, 14752, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f959d103000


close(3)= 0



mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f959d2e9000


arch_prctl(ARCH_SET_FS, 0x7f959d2e9700) = 0



mprotect(0x7f959d0fd000, 16384, PROT_READ) = 0



mprotect(0x5564d0783000, 4096, PROT_READ) = 0



mprotect(0x7f959d329000, 4096, PROT_READ) = 0



munmap(0x7f959d2eb000, 238540)  = 0



brk(NULL)   = 0x5564d0c19000



brk(0x5564d0c3a000) = 0x5564d0c3a000



sync()  = 0



open("/dev/lv/Elite3", O_RDONLY)= 3



lseek(3, 0, SEEK_SET)   = 0



read(3,
"\16\32R\275\217x\235v\376\377#\0\6/\0\177\377\377DDDE\35\360IHII\33\364GH"...,
512) = 512


lseek(3, 0, SEEK_SET)   = 0



read(3,
"\16\32R\275\217x\235v\376\377#\0\6/\0\177\377\377DDDE\35\360IHII\33\364GH"...,
512) = 512


stat("/dev/lv/Elite3", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 16),
...}) = 0


ioctl(3, HDIO_GETGEO, {heads=0, sectors=0, cylinders=0, start=0}) = 0



ioctl(3, BLKGETSIZE, [8388608]) = 0



--- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x5564d057d5f0}
---


+++ killed by SIGFPE +++



Gleitkomma-Ausnahme



--- System information. ---
Architecture: Kernel:   Linux 4.8.0-2-amd64

Debian Release: stretch/sid
  500 unstablewww.deb-multimedia.org   500 unstable
ftp.de.debian.org   500 unstabledownload.jitsi.org
--- Package information. ---
Depends  (Version) | Installed
==-+-===
libc6 (>= 2.4) |

Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Ciao...//  Fon: 0381-2744150
  Ingo   \X/   http://blog.windfluechter.net
Please don't share this address with Facebook or Google!
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

Bug#848501: ITP: jmork -- Mork database parser for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs <i...@jitsi.org>

* Package name: jmork
  Version : 1.0.5
  Upstream Author : Ingo Bauersachs <i...@jitsi.org>
* URL : https://github.com/ibauersachs/jmork
* License : EPL-v1.0
  Programming Lang: Java
  Description : Mork database parser for Java

Mork is the database format for the address book of Mozilla
Thunderbird. It contains the contacts details in a rather
weird and undocumented encoding format and parsing outside
of any Mozilla product is always on a best-effort basis.

jmork is a Java implementation of a Mork parser and an
experimental writer. It is being used by e.g. Jitsi to search
for contacts when creating a call.

Bug#848046: glances: upgrade fails when server is disabled

[Ingo Saitz]

On Tue, Dec 13, 2016 at 11:47:32AM -0500, Daniel Echeverry wrote:
> thanks for your report, Unfortunately I can't reproduce this issue,
> Could you confirm from which glances version are you trying to update?

>From /var/lib/dpkg.log:
2016-12-13 12:27:44 upgrade glances:all 2.6.2-2 2.7.1.1-1

So I was just upgrading from the previous glances version in unstable,
2.6.2-2. But I think the upgrade might be broken longer, Since this is
the first upgrade of this package on my system:

2016-11-12 14:49:01 install glances:all  2.6.2-2

Have you tried upgrading (using sysvinit as init) without running
glances server? The problem is, i believe, in the initscript, which gets
called as /etc/init.d/glances reload on upgrade, but exits with an error
code if the glances server is configured not to run. I have attached a
patch for the initscript, which fixes the return code from
/etc/init.d/glances reload by ignoring the failure to stop the glances
server, when none should be running.

Regards,
Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393
--- a/etc/init.d/glances	2016-12-14 11:14:04.0 +0100
+++ b/etc/init.d/glances	2016-12-14 11:13:43.0 +0100
@@ -118,7 +118,12 @@ case "$1" in
 ;;
   *)
 # Failed to stop
-log_end_msg 1
+if [ "$RUN" != "true" ]; then
+log_action_msg "disabled by /etc/default/$NAME"
+log_end_msg 0
+else
+log_end_msg 1
+fi
 ;;
 esac
 ;;

Bug#848046: glances: upgrade fails when server is disabled

[Ingo Saitz]

Package: glances
Version: 2.7.1.1-1
Severity: normal

Dear Maintainer,

upgrading glances fails in the postinst, if no start of the glances
server is configured:

Setting up glances (2.7.1.1-1) ...
[warn] Stopping Glances server: glances [] PID file not found ... (warning).
 failed!
invoke-rc.d: initscript glances, action "restart" failed.
dpkg: error processing package glances (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 glances

/etc/default/glances contains RUN="false".


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.12-echse20161207+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages glances depends on:
ii  adduser3.115
ii  libjs-angularjs1.5.9-1
ii  libjs-lodash   4.16.6+dfsg-1
ii  lsb-base   9.20161125
ii  python3-pkg-resources  28.7.1-1
ii  python3-psutil 5.0.0-1
pn  python3:any

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-52
pn  lm-sensors  
pn  python3-bottle  
pn  python3-docker  
pn  python3-influxdb
pn  python3-matplotlib  
pn  python3-netifaces   
pn  python3-pysnmp4 
pn  python3-pystache

glances suggests no packages.

-- no debconf information

Bug#847407: pius: Signing keys doesn't work due to KEY_CONSIDERED gpg response

[Ingo Bauersachs]

Package: pius
Version: 2.2.2-2
Severity: important
Tags: upstream

Dear Maintainer,

The upstream package v2.2.2 cannot deal with gpg's KEY_CONSIDERED responses.
This prevents key signing commands such as 'pius -s  '
from working and reporting 'ERROR: GnuPG reported an unknown error'.

Upstream has this bug fixed in Github pull request #44. Please consider
applying this patch (maybe even package the latest state from master).



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

Kernel: Linux 4.8.0-1-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
Init: systemd (via /run/systemd/system)

Versions of packages pius depends on:
ii  gnupg   2.1.16-3
ii  gnupg2  2.1.16-3
ii  python  2.7.11-2
pn  python:any  

pius recommends no packages.

pius suggests no packages.

-- no debconf information

Bug#846883: ITP: libsdp-api-java -- SDP API for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs <i...@jitsi.org>

* Package name: libsdp-api-java
  Version : 1.0
  Upstream Author : Daniel Pocock <dan...@pocock.pro>
* URL : https://github.com/opentelecoms-org/java-sdp-api
* License : Apache 2.0
  Programming Lang: Java
  Description : SDP API for Java

SDP API Specification of JSR 141

The SDP API is an extended Java API used by a couple of projects,
e.g. ice4j, Jitsi, Apache Camel and others.

The JSR hasn't been updated for many years and this package mostly consists
of interfaces, it won't involve much maintenance, if any.

Bug#846881: ITP: libsip-api-java -- SIP API for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs <i...@jitsi.org>

* Package name: libsip-api-java
  Version : 1.2
  Upstream Author : Daniel Pocock <dan...@pocock.pro>
* URL : https://github.com/opentelecoms-org/java-sip-api
* License : Apache 2.0
  Programming Lang: Java
  Description : SIP API for Java

SIP API Specification of JSR 32

The SIP API is an extended Java API used by a couple of projects,
e.g. ice4j, Jitsi, Apache Camel and others.

The JSR hasn't been updated for many years and this package mostly consists
of interfaces, it won't involve much maintenance, if any.

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Ingo Jürgensmann]

On 01.12.2016 14:26, Wei Liu wrote:


This is still the same kernel log that was sent some time ago.
So, if you have built Xen with debug=y, could you try to set Xen log
level to the highest and capture "xl dmesg" when guest crashes?


It's not the guest that crashes, it's dom0. So when the host crashes, 
I'm not able to issue any commands anymore.



But I think this is increasingly likely to be a Linux kernel issue
because you've tried multiple versions of xen. Maybe it is time to try
different versions of Dom0 kernels (sorry if you've tried that, I can't
remember all the details over so many moons).


Yes, indeed I have tried different kernels, but I can't remember details 
as well... ;/


--
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Ingo Jürgensmann]

Nov 14 09:19:52 31.172.31.251 [39677.029553] Call Trace:
Nov 14 09:19:52 31.172.31.251 [39677.029564]   
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251 [39677.029580]  [] ? 
ip6_forward+0x8dc/0x8f0
Nov 14 09:19:52 31.172.31.251 [39677.029604]  [] ? 
ip6_pol_route+0x720/0x720
Nov 14 09:19:52 31.172.31.251 [39677.029628]  [] ? 
ipv6_rcv+0x350/0x510
Nov 14 09:19:52 31.172.31.251 [39677.029650]  [] ? 
ip6_make_skb+0x1e0/0x1e0
Nov 14 09:19:52 31.172.31.251 [39677.029674]  [] ? 
__netif_receive_skb_core+0x2be/0xa50
Nov 14 09:19:52 31.172.31.251 [39677.030866]  [] ? 
br_dev_queue_push_xmit+0x75/0x130 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.032058]  [] ? 
br_forward_finish+0x3d/0xc0 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.033248]  [] ? 
nf_register_hooks+0x27/0x80
Nov 14 09:19:52 31.172.31.251 [39677.034426]  [] ? 
netif_receive_skb_internal+0x2f/0xa0
Nov 14 09:19:52 31.172.31.251 [39677.035594]  [] ? 
br_pass_frame_up+0xa6/0x150 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.036761]  [] ? 
br_port_flags_change+0x20/0x20 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.037977]  [] ? 
br_handle_frame_finish+0x1e7/0x4f0 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.039122]  [] ? 
nf_iterate+0x54/0x70
Nov 14 09:19:52 31.172.31.251 [39677.040244]  [] ? 
br_handle_frame+0x173/0x2d0 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.041350]  [] ? 
br_pass_frame_up+0x150/0x150 [bridge]
Nov 14 09:19:52 31.172.31.251 [39677.042424]  [] ? 
__netif_receive_skb_core+0x34b/0xa50
Nov 14 09:19:52 31.172.31.251 [39677.043486]  [] ? 
set_phys_to_machine+0x14/0x40
Nov 14 09:19:52 31.172.31.251 [39677.044520]  [] ? 
netif_receive_skb_internal+0x2f/0xa0
Nov 14 09:19:52 31.172.31.251 [39677.045536]  [] ? 
xenvif_tx_action+0x6cd/0x890 [xen_netback]
Nov 14 09:19:52 31.172.31.251 [39677.046543]  [] ? 
igb_poll+0x865/0xe80 [igb]
Nov 14 09:19:52 31.172.31.251 [39677.047523]  [] ? 
xenvif_poll+0x28/0x70 [xen_netback]
Nov 14 09:19:52 31.172.31.251 [39677.048524]  [] ? 
net_rx_action+0x238/0x370
Nov 14 09:19:52 31.172.31.251 [39677.049486]  [] ? 
__do_softirq+0x106/0x294
Nov 14 09:19:52 31.172.31.251 [39677.050394]  [] ? 
irq_exit+0x86/0x90
Nov 14 09:19:52 31.172.31.251 [39677.051269]  [] ? 
xen_evtchn_do_upcall+0x31/0x40
Nov 14 09:19:52 31.172.31.251 [39677.052125]  [] ? 
xen_do_hypervisor_callback+0x1e/0x40
Nov 14 09:19:52 31.172.31.251 [39677.052955]   
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251 [39677.052969]  [] ? 
xen_hypercall_sched_op+0xa/0x20
Nov 14 09:19:52 31.172.31.251 [39677.054544]  [] ? 
xen_hypercall_sched_op+0xa/0x20
Nov 14 09:19:52 31.172.31.251 [39677.055307]  [] ? 
xen_safe_halt+0xc/0x20
Nov 14 09:19:52 31.172.31.251 [39677.056044]  [] ? 
default_idle+0x18/0xc0
Nov 14 09:19:52 31.172.31.251 [39677.056761]  [] ? 
cpu_startup_entry+0x307/0x360
Nov 14 09:19:52 31.172.31.251 [39677.057464]  [] ? 
start_kernel+0x459/0x479
Nov 14 09:19:52 31.172.31.251 [39677.058210]  [] ? 
xen_start_kernel+0x522/0x52c
Nov 14 09:19:52 31.172.31.251 [39677.058926] Code: 
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251 [39677.060558] RIP 
Nov 14 09:19:52 31.172.31.251  [] 
ndisc_send_redirect+0x44c/0x4d0
Nov 14 09:19:52 31.172.31.251 [39677.061286]  RSP 
Nov 14 09:19:52 31.172.31.251 [39677.062003] CR2: 880002b4c06e
Nov 14 09:19:52 31.172.31.251 [39677.066328] ---[ end trace 98db42bf1a114a3d 
]---
Nov 14 09:19:52 31.172.31.251 [39677.070151] Kernel panic - not syncing: Fatal 
exception in interrupt
Nov 14 09:19:52 31.172.31.251 [39677.070892] Kernel Offset: disabled

If the log entries of the starting-up server is of interest as well, please 
shout! ;-) 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#845371: ITP: libdnssecjava-java -- A DNSSEC validating stub resolver for Java

[Ingo Bauersachs]

> Le 24/11/2016 à 23:37, Ingo Bauersachs a écrit :
>> Is there anything else that I'd need to do besides setting the maintainer
>> as follows?
> 
> Ideally the packaging repository should be in the pkg-java group on
> Alioth (this impacts the Vcs-* fields in debian/control). I created an
> empty Git repository for it:
> 
>ssh://git.debian.org/git/pkg-java/dnssecjava.git

I can change the Vcs-* fields, but how would the packaging code end up in this 
repo? I'm not a DD. And what's the advantage of having it there instead of in a 
branch on the source repo?

>> There's an initial upload at https://mentors.debian.net/package/dnssecjava
>> which needs some small Lintian fixes.
> 
> Do you want me to upload it when it's ready?

Thanks, that would be helpful. I've uploaded an update that addresses the 
Lintian warnings (it's in a queue ATM).

> I got a quick look, it
> seems it was generated with mh_make on Jessie, I'd recommended preparing
> new packages on Debian unstable instead. Fortunately it doesn't make a
> big difference for this package (debhelper 9 instead of 10 and CDBS
> instead of DH).

I can try that on the weekend, although I have no idea about the difference. 
I'm not a regular Debian user and the last time I tried to do something with 
unstable resulted in not being able to do anything.

> Emmanuel Bourg

Ingo

Bug#845371: ITP: libdnssecjava-java -- A DNSSEC validating stub resolver for Java

[Ingo Bauersachs]

Hey

> Considering that dnsjava is maintained by the Java team do you think
> this package could be brought there as well? We'll be happy to help you
> with its maintenance.

Thanks. Is there anything else that I'd need to do besides setting the 
maintainer as follows?

> Maintainer: Debian Java Maintainers 
> <pkg-java-maintain...@lists.alioth.debian.org>

There's an initial upload at https://mentors.debian.net/package/dnssecjava 
which needs some small Lintian fixes.

> Emmanuel Bourg

Ingo

Bug#845371: ITP: libdnssecjava-java -- A DNSSEC validating stub resolver for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs <i...@jitsi.org>

* Package name: libdnssecjava-java
  Version : 1.1.2
  Upstream Author : Ingo Bauersachs <i...@jitsi.org>
* URL : https://github.com/ibauersachs/dnssecjava
* License : EPL
  Programming Lang: Java
  Description : A DNSSEC validating stub resolver for Java

dnssecjava is a small library used as a resolver on top of
dnsjava (libdnsjava-java) to validate responses with DNSSEC.

It is a dependecy of Jitsi.

Bug#838897: jitsi: Replace the glassfish dependencies

[Ingo Bauersachs]

On Mon, 26 Sep 2016 10:43:42 +0200 Emmanuel Bourg <ebo...@apache.org> wrote:
> jitsi still depends on glassfish-activation and glassfish-mail which are
going
> to be removed. glassfish-activation can be safely removed (the API has
been
> integrated to the standard JDK) and glassfish-mail should be replaced by
libmail-java.

I'm not sure where these dependencies would come from. javax.activation is
nowhere to be found in the source code, and Jitsi doesn't send mails either.

Anyway if the Jitsi package poses a problem, please remove it from Debian.
It is unusable anyway as libjitsi is missing. Once I manage to get version
2.10 out, I'll try to continue packaging dependencies so it can come back to
Debian in a clean fashion.

> Thank you,
> Emmanuel Bourg

Ingo

Bug#835044: ITP: sdes4j -- SDES (RFC4568) implementation for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs <i...@jitsi.org>

* Package name: libsdes4j-java
  Version : 1.1.4
  Upstream Author : Ingo Bauersachs <i...@jitsi.org>
* URL : https://github.com/ibauersachs/sdes4j
* License : LGPL
  Programming Lang: Java
  Description : SDES (RFC4568) implementation for Java

sdes4j is a small Java library to parse and generate
Session Description Protocol (SDP) Security Descriptions
for Media Streams according to RFC4568.

It is a dependency of Jitsi and libjitsi (#757768).

Bug#828751: using mutt with gpg2 results in two password prompts - patch works for me

[Ingo Jürgensmann]

Hi!

Just wanted to give some feedback that the solution provided by Jan is
working for me. 

Thanks! :-) 

-- 
Ciao...//  Fon: 0381-2744150 
  Ingo   \X/   http://blog.windfluechter.net
Please don't share this address with Facebook or Google!
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

Bug#831228: closed by Bart Martens <ba...@debian.org> (flashplugin-nonfree: update-flashplugin-nonfree references wrong version)

[Ingo]

An alternative solution is to apply the patch locally:

1. get the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=831228;filename=flash.patch;msg=15

2. Copy it into the directory /var/cache/flashplugin-nonfree/

3. change to that directory and apply the patch by executing:
"patch get-upstream-version.pl flash.patch"

Bug#833500: kernel-package: CONFIG_STACK_VALIDATION needs tools/objtool/objtool along headers

[Ingo Saitz]

Package: kernel-package
Version: 13.018
Severity: normal

Package: kernel-package
Version: 13.018
Severity: normal

When building linux 4.7 with CONFIG_STACK_VALIDATION enabled and installing the
linux-image and linux-headers debs, building 3rd party modules fails.
make -d --trace shows it is looking for tools/objtool/objtool as prerequisite
to compile .c files.

I.e. building the virtualbox modules, the output reads (full make.log attached):

Considering target file 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o'.
 File '/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o' does not exist.
 Looking for an implicit rule for 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o'.
 Trying pattern rule with stem 'linux/SUPDrv-linux'.
 Trying implicit prerequisite 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.c'.
 Trying rule prerequisite 'tools/objtool/objtool'.
 Trying pattern rule with stem 'linux/SUPDrv-linux'.
 Trying implicit prerequisite 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.S'.
[...]
 No implicit rule found for 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o'.
 Finished prerequisites of target file 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o'.
Must remake target '/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o'.
make[2]: *** No rule to make target 
'/tmp/virtualbox-5.0.24/vboxdrv/linux/SUPDrv-linux.o', needed by 
'/tmp/virtualbox-5.0.24/vboxdrv/vboxdrv.o'.  Stop.

Copying the build objtool binary into /lib/modules/$(uname -r)/tools/objtool/
allows the build to succeed. So this binary should probably go into the
linux-headers package.

Attached builds of virtualbox-5.0.24 modules with
$ make -d --trace -C "/lib/modules/$(uname -r)/build" M="$(pwd)"

make.fail.log: without objdump binary
make.succ.log: with objdump binary in /lib/modules/$(uname -r)/tools/objtool/



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-pinguin20160805+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kernel-package depends on:
ii  bc   1.06.95-9+b1
ii  binutils 2.26.1-1
ii  build-essential  12.2
ii  bzip21.0.6-8
ii  dpkg-dev 1.18.10
ii  file 1:5.28-4
ii  gettext  0.19.8.1-1
ii  kmod 22-1.1
ii  lzma 9.22-2
ii  po-debconf   1.0.19
ii  xmlto0.0.28-0.1
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1

Versions of packages kernel-package recommends:
ii  cpio   2.11+dfsg-5
pn  docbook-utils  
ii  kernel-common  13.018
pn  uboot-mkimage  

Versions of packages kernel-package suggests:
ii  libncurses5-dev [libncurses-dev]  6.0+20160625-1
pn  linux-source  

-- no debconf information


make.fail.log.gz
Description: application/gzip


make.succ.log.gz
Description: application/gzip

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Ingo Jürgensmann]

On 02.08.2016 11:20, Wei Liu wrote:

On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote:
What is also interesting is that you seem to be running some sort of
ip accounting software (pmacctd) which also segfault'ed.


Yeah, it is segfaulting, because the database (in a domU VM) where it is 
storing the accounting is not yet available after the crash. When 
database is up, those segfaults go away.



Still not sure what to make of that though.


Me neither. ;-)

I already tried to get a core dump by setting ulimit -c unlimited, but 
that didn't work as well, which makes me believe that the crash happens 
in hypervisor not in dom0 kernel. When it's dom0 kernel I would expect 
dumping a core file should work.


--
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Am 01.08.2016 um 15:33 schrieb Andreas Henriksson:
> Hello again Ingo.
> 
> On Mon, Jul 25, 2016 at 10:13:29AM +0200, Ingo wrote:
>> Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>>>
>>> Are you sure this is the correct syntax? I would expect that you
>>> should specify the mountpoint (target directory) rather than the
>>> source of the mount. eg. mount /home/ingo/leo.Bilder
>>> Do using that still give you the same problem?
>>
>> Great, at least that works as expected if target directory is used.
>>
>> But "man mount" explicitely states:
> [...]
> 
> You're right, the manpage explicitly says in multiple places
> that what you're doing should work... I'm still thinking ...
... to adjust the manpages?
> using the mountpoint is always preferrable/recommended though. ;)
> 
> I got a chance to discuss this with upstream and I'll try to summarize
> some of the useful information here for the record (and as a personal
> reminder for the future):
> 

> 
> Despite knowing where we stumble, it's not easy to come up with a solution
> that suites both the people who wants to avoid path disclosure and your
> usecase. Given you now know about using the mountpoint (which also
> upstream said is really the way to go when specifying mounts, rather
> than the source) would you agree that this isn't strictly Release Critical
> severity anymore?

I do agree!
Thanks to your explanation I understand the background and will change
my habits.

> 
> Hopefully everything works as you expect it to when you mount as non-root
> using "mount /mountpoint" or did you see any additional problems with that?

No further problems here with NFSv4 mounts, I won't forget what I have
learned with this bug.

Regards,
Ingo

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Some additional Information which probably helps to find the root cause:

The very same beheaviour (as in Jessie) is still shown in Stretch.

I already tried to assign that bug to package "mount", but this was not
accepted. The corresponding bug report demonstrates some more
possibilities of "how you can workaroung" this faulty beheaviour.

See here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788547#12