Bug#873520: Check for bad distribution in d/changelog only when changes file is signed

[Felix Lechner]

Hi,

> However, ... this would mean that every time you built a package
> locally as part of regular development it would emit this tag.

Would it be acceptable to generate the tag for bad distribution in
d/changelog only when the *.changes file is signed (if it is present)?
That should bypass interim packages produced locally but catch those
intended for upload.

Kind regards,
Felix

Bug#933923: src:valinor: Incompatible with safe load changes in new pyyaml

[Scott Kitterman]

Package: src:valinor
Version: 1.1.0-1
Severity: grave
Justification: renders package unusable

FAIL: testARMNoneEABIGDB (test.test_outputdir.TestCLIOutputDirectory)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.eh9dq_op/downtmp/autopkgtest_tmp/test/test_outputdir.py", 
line 48, in testARMNoneEABIGDB
runWithDir()
  File 
"/tmp/autopkgtest-lxc.eh9dq_op/downtmp/autopkgtest_tmp/test/test_outputdir.py", 
line 46, in runWithDir
out = self.runCheck(args)
  File 
"/tmp/autopkgtest-lxc.eh9dq_op/downtmp/autopkgtest_tmp/test/test_outputdir.py", 
line 33, in runCheck
self.assertEqual(status, 0)
AssertionError: 1 != 0
 >> begin captured stdout << -

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/share/valinor/valinor/main.py", line 36, in main
version=pkg_resources.require("valinor")[0].version,
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 791, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (PyYAML 5.1.2 
(/usr/lib/python3/dist-packages), Requirement.parse('pyyaml<4,>=3'), 
{'valinor'})

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

That's likely the change that caused upstream to have <4 for the pyyaml
version.  You ought to be able to fix it pretty easily and then remove
the upper version constraint, assuming there's no upstream fix yet.

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933924: cl-asdf: doc-base merge error: format html already defined

[David Nebauer]

Package: cl-asdf
Version: 2:3.3.3-1
Severity: normal

Dear Maintainer,

On update the following error occurs:

Error while merging /usr/share/doc-base/cl-asdf-asdf with 
/usr/share/doc-base/cl-asdf-uiop: format html already defined.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

cl-asdf depends on no packages.

Versions of packages cl-asdf recommends:
ii  clisp [lisp-compiler]  1:2.49.20180218+really2.49.92-3+b2
ii  ecl [lisp-compiler]16.1.3+ds-2

Versions of packages cl-asdf suggests:
ii  cl-launch  4.1.4-1

-- no debconf information

Bug#933922: src:salt: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:salt
Version: 2018.3.4+dfsg1-6
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933921: src:python-tablib: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:python-tablib
Version: 0.12.1-2
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933920: src:python-markdown: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:python-markdown
Version: 3.0.1-3
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933919: src:lavacli: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:lavacli
Version: 0.9.7-1
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933918: src:lava: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:lava
Version: 2019.01-5
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933917: src:knot: Unsafe use of yaml.load()

[Scott Kitterman]

Package: src:knot
Version: 2.7.6-2
Severity: grave
Tags: security
Justification: user security hole

The new version of pyyaml no longer allows use of yaml.load() without a
loader being specifed.  This raises a deprecation warning which has
caused and autopkgtest failure on this package.  These are generally
trivial to fix, see the upstream guidance [1].

Scott K

[1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

Bug#933916: IO hang on guest after stop / cont commands to monitor

[Michael Stroucken]

Package: qemu-system-x86
Version: 1:2.8+dfsg-6+deb9u7
Severity: important

I have VM servers that are running Jessie. On testing a migration of one
to stretch, I noticed that one of the VMs was getting stuck on IO.

I have noticed that this happens when guest is performing IO, and the
system issues a "stop" command via the monitor followed by a "cont"
command. The system does this to allow for guest filesystem
snapshotting. Only the virtual disk that was being accessed will remain
stuck.

The kernel of the system is linux-image-4.9.0-9-amd64 4.9.168-1+deb9u4
Linux HOST 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19)
x86_64 GNU/Linux

The problem does not occur with the jessie version of qemu running on
the stretch kernel (qemu-system-x86 1:2.1+dfsg-12+deb8u11).

Conversely, the problem does occur with the stretch version of qemu
running on the jessie kernel (linux-image-3.16.0-10-amd64 3.16.70-1).

The command line of the guest is as follows:
qemu-system-x86_64 -enable-kvm -enable-kvm -cpu qemu64,+x2apic
-daemonize -pidfile /guest/run/GUEST.pid -name GUEST,process=GUEST -m
128 -nodefaults -monitor unix:/guest/run/GUEST.mon,server,nowait -vga
cirrus -rtc base=utc -balloon virtio -vnc 127.0.0.1:20 -smp 4 -m 22528
-netdev
type=tap,id=GUEST0,ifname=GUEST0,script=/guest/net/local/ifup,downscript=/guest/net/local/ifdown
-device virtio-net-pci,netdev=GUEST0,mac=52:54:01:23:45:67 -drive
if=virtio,aio=native,cache=none,media=disk,file=disk0.img -drive
if=virtio,format=raw,aio=native,cache=none,media=disk,file=/dev/lvm/venti

The issue happened regardless of whether aio was native or threads.

The host looks idle during the occurrence of the problem.

On the guest, top will reflect 25% iowait (there are four processors
assigned). iostat -xk 1 will show 0 for all values except 100% on %util.

Future accesses to that storage unit will also hang, raising the load
average.

I have not been able to duplicate the problem with IO loads like dd, but
have been constantly successful in doing so with plan9port's venti.

This is a blocker for me to move to stretch, but I can return to jessie
for now, hoping that this bug will be fixed in future. The host and
guest are large and in production, so unless I can set up a test system,
my ability to run further tests here will be limited.

Following is information collected on the system during the issue.

strace from venti around the time of a stop / cont:
2807  pread64(5,
"r\220\37\37g\223(\2046\364l8=\10\203\336\362v\305e\250\320\201
\362\317\327\376:\177L\201\305"..., 8192, 103062593536) = 8192
2807  fadvise64(5, 103062593536, 8192, POSIX_FADV_DONTNEED) = 0
2807  futex(0x215a994, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x215a990,
FUTEX_OP_SET<<28|
0<<12|FUTEX_OP_CMP_GT<<24|0x1 
2814  <... futex resumed> ) = 0
2814  futex(0x215a900, FUTEX_WAIT_PRIVATE, 2, NULL 
2807  <... futex resumed> ) = 1
2807  futex(0x215a900, FUTEX_WAKE_PRIVATE, 1 
2814  <... futex resumed> ) = 0
2814  futex(0x215a900, FUTEX_WAKE_PRIVATE, 1) = 0
2814  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2814  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2814  futex(0x215a994, FUTEX_WAIT_PRIVATE, 1, NULL 
2807  <... futex resumed> ) = 1
2807  futex(0x215a994, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x215a990,
FUTEX_OP_SET<<28|
0<<12|FUTEX_OP_CMP_GT<<24|0x1 
2814  <... futex resumed> ) = 0
2814  futex(0x215a900, FUTEX_WAIT_PRIVATE, 2, NULL 
2807  <... futex resumed> ) = 1
2807  futex(0x215a900, FUTEX_WAKE_PRIVATE, 1 
2814  <... futex resumed> ) = 0
2814  futex(0x215a900, FUTEX_WAKE_PRIVATE, 1) = 0
2814  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2814  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2814  futex(0x215a994, FUTEX_WAIT_PRIVATE, 1, NULL 
2807  <... futex resumed> ) = 1
2807  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2807  rt_sigprocmask(SIG_SETMASK, [CHLD], [CHLD], 8) = 0
2807  pread64(5,  
2808  <... select resumed> )= 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
2808  select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)

The program will make no further progress.

Bug#933913: No sound with pulseaudio 12.2-5

[Arnaldo Pirrone]

Please close this,
there is no bug, there was no sound because no audio devices were selected
in cinnamon-settings (audio), which is currently affected by bug #931777.
I'm sorry for taking your time.

Il giorno lun 5 ago 2019 alle ore 05:03 Arnaldo Pirrone 
ha scritto:

> Package: pulseaudio
> Version: 12.2-4
> Severity: important
>
> The sound is gone after upgrading the system, may be pulseaudio.
> Conversely jack2 is working
>
>
>
> -- Package-specific info:
> File '/etc/default/pulseaudio' does not exist
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.2.0-5.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages pulseaudio depends on:
> ii  adduser  3.118
> ii  libasound2   1.1.8-1
> ii  libasound2-plugins   1.1.8-1
> ii  libc62.28-10
> ii  libcap2  1:2.25-2
> ii  libdbus-1-3  1.12.16-1
> ii  libgcc1  1:9.1.0-10
> ii  libice6  2:1.0.9-2
> ii  libltdl7 2.4.6-10
> ii  liborc-0.4-0 1:0.4.28-3.1
> ii  libpulse012.2-4
> ii  libsm6   2:1.2.3-1
> ii  libsndfile1  1.0.28-6
> ii  libsoxr0 0.1.2-3
> ii  libspeexdsp1 1.2~rc1.2-1+b2
> ii  libstdc++6   9.1.0-10
> ii  libsystemd0  241-7
> ii  libtdb1  1.3.16-2+b1
> ii  libudev1 241-7
> ii  libwebrtc-audio-processing1  0.3-1+b1
> ii  libx11-6 2:1.6.7-1
> ii  libx11-xcb1  2:1.6.7-1
> ii  libxcb1  1.13.1-2
> ii  libxtst6 2:1.2.3-1
> ii  lsb-base 10.2019051400
> ii  pulseaudio-utils 12.2-4
>
> Versions of packages pulseaudio recommends:
> ii  dbus-user-session  1.12.16-1
> ii  libpam-systemd 241-7
> ii  rtkit  0.12-4
>
> Versions of packages pulseaudio suggests:
> pn  paman
> pn  paprefs  
> pn  pavucontrol  
> pn  pavumeter
> ii  udev 241-7
>
> -- Configuration Files:
> /etc/pulse/daemon.conf changed [not included]
>
> -- no debconf information
>

Bug#933915: linux-image-4.19.0-5-686: Regression from 9.6.x : Booting on Intel GM965 S-video port init attempt timeouts repeatedly

[Fernando Cassia]

Package: src:linux
Version: 4.19.37-5
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   Previous Debian versions before 9.6 booted slowly on systems with Intel 
   GM965 graphics because of timeouts attempting to init the s-video port.
   Debian 9.6.x fixed it. On debian 10 the previous behaviour (timeouts 
   during boot) reappeared.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Booted the Debian 9.6 x86 LiveCD
   * What was the outcome of this action?
   Boot time measured in over two minutes, vs 40 secons without the svideo 
timeouts
   * What outcome did you expect instead?
   Booting without timeouts and pauses between repeated attempts to init the 
svideo port.



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

** Command line:
BOOT_IMAGE=/live/vmlinuz-4.19.0-5-686 initrd=/live/initrd.img-4.19.0-5-686 
boot=live components splash quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 5958.186477] WARNING: CPU: 1 PID: 1359 at drivers/gpu/drm/drm_vblank.c:1084 
drm_wait_one_vblank+0x1c6/0x1e0 [drm]
[ 5958.186479] Modules linked in: arc4 uvcvideo videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev ath5k ath media 
mac80211 coretemp joydev hp_wmi wmi_bmof serio_raw sparse_keymap pcspkr 
snd_hda_codec_conexant snd_hda_codec_generic sg snd_hda_intel snd_hda_codec 
cfg80211 iTCO_wdt iTCO_vendor_support snd_hda_core snd_hwdep snd_pcm snd_timer 
rfkill snd evdev soundcore battery ac pcc_cpufreq acpi_cpufreq ip_tables 
x_tables autofs4 squashfs zstd_decompress xxhash loop overlay isofs sr_mod 
cdrom ata_generic sd_mod ums_realtek uas usb_storage i915 ahci ata_piix libahci 
i2c_algo_bit libata drm_kms_helper psmouse ehci_pci syscopyarea sysfillrect 
uhci_hcd i2c_i801 scsi_mod sysimgblt ehci_hcd fb_sys_fops drm 8139too 8139cp 
lpc_ich mii usbcore usb_common thermal wmi video button
[ 5958.186623] CPU: 1 PID: 1359 Comm: Xorg Tainted: GW 
4.19.0-5-686 #1 Debian 4.19.37-5
[ 5958.186626] Hardware name: Hewlett-Packard Compaq Presario C700 Notebook 
PC/30D9, BIOS F.33 04/29/2008
[ 5958.186649] EIP: drm_wait_one_vblank+0x1c6/0x1e0 [drm]
[ 5958.186655] Code: 00 00 00 00 e9 c6 fe ff ff 8d 76 00 8b 45 cc 8d 55 dc e8 
ad 97 98 ca 85 ff 0f 85 dd fe ff ff 56 68 38 0c 73 f7 e8 1e 80 94 ca <0f> 0b 58 
5a e9 c9 fe ff ff e8 1c 7d 94 ca 8d b4 26 00 00 00 00 8d
[ 5958.186659] EAX: 001f EBX: f2bb8000 ECX: f395dcac EDX: 0007
[ 5958.186662] ESI:  EDI:  EBP: f36dbbc8 ESP: f36dbb8c
[ 5958.186667] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210296
[ 5958.186670] CR0: 80050033 CR2: 018ce6e0 CR3: 31dad000 CR4: 06d0
[ 5958.186674] Call Trace:
[ 5958.186688]  ? finish_wait+0x70/0x70
[ 5958.186759]  intel_get_load_detect_pipe+0x3b1/0x3e0 [i915]
[ 5958.186820]  intel_tv_detect+0x10b/0x480 [i915]
[ 5958.186887]  ? intel_tv_get_modes+0x1f0/0x1f0 [i915]
[ 5958.186900]  drm_helper_probe_detect+0x45/0x90 [drm_kms_helper]
[ 5958.186912]  drm_helper_probe_single_connector_modes+0xbc/0x5f0 
[drm_kms_helper]
[ 5958.186925]  ? drm_helper_probe_detect+0x90/0x90 [drm_kms_helper]
[ 5958.186951]  drm_mode_getconnector+0x395/0x3d0 [drm]
[ 5958.186980]  ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
[ 5958.186999]  drm_ioctl_kernel+0x88/0xd0 [drm]
[ 5958.187020]  drm_ioctl+0x21d/0x390 [drm]
[ 5958.187044]  ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
[ 5958.187056]  ? new_sync_write+0xdf/0x150
[ 5958.187076]  ? drm_version+0x80/0x80 [drm]
[ 5958.187082]  do_vfs_ioctl+0x9a/0x6c0
[ 5958.187090]  ? vfs_write+0x173/0x1b0
[ 5958.187096]  ksys_ioctl+0x56/0x80
[ 5958.187101]  sys_ioctl+0x16/0x20
[ 5958.187107]  do_fast_syscall_32+0x81/0x1a0
[ 5958.187114]  entry_SYSENTER_32+0x6b/0xbe
[ 5958.187118] EIP: 0xb7f35d41
[ 5958.187123] Code: f6 ff ff 55 89 e5 8b 55 08 8b 80 5c cd ff ff 85 d2 74 02 
89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 
c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 5958.187126] EAX: ffda EBX: 000e ECX: c05064a7 EDX: bff26098
[ 5958.187130] ESI: 0001 EDI: c05064a7 EBP: 000e ESP: bff26018
[ 5958.187134] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 3296
[ 5958.187139] ---[ end trace d8f48489b338b794 ]---
[ 5968.318398] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CRTC:34:pipe A] flip_done timed out
[ 5978.562416] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CONNECTOR:50:SVIDEO-1] flip_done timed out
[ 6014.914418] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] 
*ERROR* [CRTC:41:pipe B] flip_done timed out
[ 6015.019984] [ cut here ]
[ 6015.019989] vblank wait timed out on crtc 1
[ 6015.020076] WARNING: CPU: 1 PID: 

Bug#933914: python3-pytest: pytest v4 breaks existing tests

[Drew Parsons]

Package: python3-pytest
Version: 4.6.4-1
Severity: serious
Justification: breaks autopkgtest tests
Control: affects -1 + src:apipkg src:betamax src:ccdproc src:chardet
Control: affects -1 + src:dask src:django-axes src:doit src:drms
Control: affects -1 + src:fiat src:mpi4py src:pandas src:pygalmesh
Control: affects -1 + src:pyjwt src:pytest-sugar src:pytest-xdist
Control: affects -1 + src:pytest-xvfb src:python-dbfread
Control: affects -1 + src:python-dugong src:python-graphviz
Control: affects -1 + src:python-hypothesis src:python-parameterized
Control: affects -1 + src:python-transliterate src:setuptools-scm
Control: affects -1 + src:spyder-line-profiler src:spyder-reports
Control: affects -1 + src:spyder-unittest src:sudsy 


python3-pytest v4 has changed the pytest API, causing many existing
tests to fail.

This upgrade should be treated as a Transition, uploading the package to
experimental first.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pytest depends on:
ii  python3 3.7.3-1
ii  python3-atomicwrites1.1.5-2
ii  python3-attr18.2.0-1
ii  python3-importlib-metadata  0.18-2
ii  python3-more-itertools  4.2.0-1
ii  python3-packaging   19.0-1
ii  python3-pkg-resources   41.0.1-1
ii  python3-pluggy  0.12.0-1
ii  python3-py  1.8.0-1
ii  python3-six 1.12.0-1
ii  python3-wcwidth 0.1.7+dfsg1-6

python3-pytest recommends no packages.

python3-pytest suggests no packages.

-- no debconf information

Bug#933913: No sound with pulseaudio 12.2-5

[Arnaldo Pirrone]

Package: pulseaudio
Version: 12.2-4
Severity: important

The sound is gone after upgrading the system, may be pulseaudio.
Conversely jack2 is working



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.2.0-5.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.8-1
ii  libasound2-plugins   1.1.8-1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libdbus-1-3  1.12.16-1
ii  libgcc1  1:9.1.0-10
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-10
ii  liborc-0.4-0 1:0.4.28-3.1
ii  libpulse012.2-4
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   9.1.0-10
ii  libsystemd0  241-7
ii  libtdb1  1.3.16-2+b1
ii  libudev1 241-7
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 10.2019051400
ii  pulseaudio-utils 12.2-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 241-7
ii  rtkit  0.12-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 241-7

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

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = 

Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Thu, Aug 01, 2019 at 05:53:40PM +0200, Tobias Frost wrote:
> On Wed, Jul 31, 2019 at 02:32:00PM -0400, Scott Talbert wrote:
> > On Wed, 31 Jul 2019, Tobias Frost wrote:
> > 
> > > A quick Thought: Would there be a possiblity to have at least an message
> > > printed out on wayland before crashing emitted from wxwidgets? like a
> > > warning "you are using GLCanvas under wayland, this app will crash!"
> > 
> > Yes, in fact, I've upstreamed such a fix.  I thought I had included that
> > patch in Debian, but it appears that I have not.  We can definitely do that.
> 
> Cool. That would definitly help the users, especially if we can give
> them a pointer how to get it working.

I've just uploaded wxwidgets3.0 3.0.4+dfsg-9 which backports all
relevant fixes from the upstream WX_3_0_BRANCH including this patch.
So you should now get a message which says:

| wxGLCanvas is only supported on X11 currently.  You may be able to
| work around this by setting environment variable GDK_BACKEND=x11 before
| starting your program.

I suspect this upload doesn't fix your hidpi problem, but it would be
useful to check this and any other outstanding wx issues to make sure
we aren't wasting time on issue upstream already fixed but just didn't
get around to releasing.

Cheers,
Olly

Bug#933912: RFA: cppo -- cpp for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: normal

Hello,

Currently, cppo has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Stéphane

Bug#441287: texlive-latex-base: wish "man latex" mentioned the -help option

[Ryo Furue]

Hi Hilmar,

Thank you for your response.

On Sun, Aug 4, 2019 at 10:01 PM Hilmar Preuße  wrote:

> Am 08.09.2007 um 10:26 teilte Ryo Furue mit:
>
> Hi Ryo,
>
> > Hi, I thought it would be helpful if the manpage of latex mentioned
> > that "latex -help" will give a list of command line options.  Better
> > still, it would be nice if the list itself is found in the manpage.
> >
> > Experienced Unix/Linux users expect to find, at the very least,
> > command line options in the manpage.
> >
> Please note the sentence right at the top of the page:
>
> DESCRIPTION
>This manual page is a mere skeleton.
>

I would think that this statement is too vague to the user.   Where can the
user find the details of the "latex" command such as command line options?



>
> Further below we have:
>
> SEE ALSO
>amstex(1), luatex(1), pdftex(1), ptex(1), tex(1), xetex(1).
>
> , where luatex(1) & pdftex(1) contain an extensive listing of all
> possible options.


I see.  In that case, I suggest including THIS information (that "luatex(1)
and pdftex(1) contain an extensive listing of all possible options") in the
manpage of the "latex" command.  Mentioning the "-help" option would be
nice, too, I would think.


> I don't really intend to duplicate them in latex(1).
> Experienced users will be able to see the "SEE ALSO" section and look at
> the manual pages of the other commands.
>

But, there doesn't seem to be information that the same options apply to
the "latex" command as to luatex and pdftex .

I suggest to close the issue as "solved elsewehere". What do you think?
>

I would think that the problem is that the user cannot know what she will
find in the documents of the commands listed under "SEE ALSO".

Cheers,
Ryo

Bug#932584: Epydoc and Pydoctor

[Jelmer Vernooij]

Hi Kenneth, Ian,

On Wed, Jul 31, 2019 at 08:45:54PM -0500, Kenneth Pronovici wrote:
> On Wed, Jul 31, 2019 at 10:46 AM Ian Jackson
>  wrote:
> > > Otherwise, I will see if I can determine how well the package works
> > > without epydoc installed.  If it works (i.e. doesn't blow up) and I
> > > don't hear back with other instructions, I will eventually NMU my
> > > changes to remove the epydoc dependency.   Given that I haven't gotten
> > > any replies for more than 18 months now, I won't wait that long before
> > > doing this NMU.
> >
> > That sounds really good to me for now.  I think you can do this NMU
> > whenever you like.
> 
> I tested pydoctor against my own cedar-backup2 code, which I never converted
> away from Epydoc since it's Python 2-only.   It seems to work fine:
> 
> mars:~/projects/dev/software/cedar-backup2> pydoctor CedarBackup2/
> adding directory 
> /home/pronovic/projects/dev/software/cedar-backup2/CedarBackup2
> 41/41 modules processed 0 warnings
> WARNING: guessing CedarBackup2 for project name
> writing html to apidocs using pydoctor.templatewriter.writer.TemplateWriter
> starting ModuleIndexPage ...
> Error trying to import 'epytext' parser:
> 
> ImportError: No module named epydoc.markup.epytext
> 
> Using plain text formatting only.
> took 0.006452s
> starting ClassIndexPage ... took 0.011512s
> starting IndexPage ... took 0.002281s
> starting NameIndexPage ... took 0.079562s
> starting UndocumentedSummaryPage ... took 0.004314s
> 125/125 pages written
> Generating objects inventory at apidocs/objects.inv
> 
> The generated HTML documentation is legible, if not as pretty as it
> would have been before.  Given that it works, I am going to NMU the
> version of the package that doesn't depend on epydoc.  I'll also
> create a PR on salsa.  On salsa, master has diverged from the released
> package, but I am *not* going to integrate those changes, because I
> don't want to take responsibility for them.

Sorry for the delayed reply and thanks for working on Pydoctor without epydoc.
I'm happy for you to NMU a new version, but can also merge a patch and do an
upload - as you prefer.

As far as I know pydoctor upstream is pretty dormant, but not completely
inactive. Pull requests do get looked at and there is the occasional fix to
keep it running, but that's about it.

Cheers,

Jelmer

Bug#932584: Epydoc and Pydoctor

[Kenneth Pronovici]

I decided to NMU and uploaded a few days ago, so things are in good shape
now, I think.  You can integrate my changes whenever you have time.  Thanks
for confirming that your ok with the NMU.  I was hoping you would be.

KEN

Bug#933910: rasdaemon.service: sometimes terminates when started at boot

[Rob Leslie]

Package: rasdaemon
Version: 0.6.0-1.2
Severity: important
File: /lib/systemd/system/rasdaemon.service
Tags: patch

Dear Maintainer,

I often found rasdaemon.service inactive (exited) after a fresh boot.
There were no obvious errors, except this:

Aug 04 17:04:13 host rasdaemon[549]: rasdaemon: Can't open trace_clock
Aug 04 17:04:13 host rasdaemon[549]: rasdaemon: Can't select a timestamp for 
tracing

After some digging, I found that /sys/kernel/debug/tracing was not yet
mounted at the time rasdaemon.service was started, and rasdaemon needs
this to function.

Please find attached a patch to correct this situation.


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

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

Versions of packages rasdaemon depends on:
ii  libc62.28-10
ii  libdbd-sqlite3-perl  1.62-3
ii  libsqlite3-0 3.27.2-3
ii  perl 5.28.1-6
ii  sqlite3  3.27.2-3
ii  systemd  241-5

rasdaemon recommends no packages.

rasdaemon suggests no packages.

-- no debconf information
--- /lib/systemd/system/rasdaemon.service   2018-05-09 07:46:47.0 
-0700
+++ rasdaemon.service   2019-08-04 17:15:26.336126160 -0700
@@ -1,5 +1,6 @@
 [Unit]
 Description=RAS daemon to log the RAS events
+RequiresMountsFor=/sys/kernel/debug/tracing
 
 [Service]
 ExecStart=/usr/sbin/rasdaemon -f -r

Bug#933911: buster-pu: package pulseaudio

[Felipe Sateler]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

There is a bug affecting pulseaudio users: #913102. This bug causes the
mute state to be incorrectly restored. Some users have asked for the fix
(which is now on unstable), to be backported to buster given that GDM is
affected by this bug. The upstream patch fixing this issue is very
small[1].

The full diff is attached.

[1] 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/105/diffs?commit_id=7fb85e0a5bfdec339fda9f7584f65cf9ddbd50a1

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 02916c2a1..1b9633855 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pulseaudio (12.2-5) unstable; urgency=medium
+
+  * Pick upstream patch fixing mute state restoring (Closes: #913102)
+
+ -- Felipe Sateler   Sun, 04 Aug 2019 21:18:02 -0400
+
 pulseaudio (12.2-4) unstable; urgency=medium
 
   [ Jan Graichen ]
diff --git a/debian/patches/series b/debian/patches/series
index 3e43a7538..37a72b94f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ volume-test.patch
 alsa-mixer-Update-to-support-Arctis-Pro-Wireless-headset.patch
 alsa-mixer-Add-support-for-2018-Arctis-7.patch
 Don-t-compile-with-ffast-math.patch
+sink-source-Don-t-change-suspend-cause-when-unlinking.patch
diff --git 
a/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch 
b/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
new file mode 100644
index 0..efa780834
--- /dev/null
+++ b/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
@@ -0,0 +1,47 @@
+From: Tanu Kaskinen 
+Date: Mon, 10 Jun 2019 14:18:47 +0300
+Subject: sink, source: Don't change suspend cause when unlinking
+
+See the added comments for why this is necessary.
+
+Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667
+(cherry picked from commit 7fb85e0a5bfdec339fda9f7584f65cf9ddbd50a1)
+---
+ src/pulsecore/sink.c   | 6 +-
+ src/pulsecore/source.c | 6 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
+index 38e8e50..4a0 100644
+--- a/src/pulsecore/sink.c
 b/src/pulsecore/sink.c
+@@ -760,7 +760,11 @@ void pa_sink_unlink(pa_sink* s) {
+ }
+ 
+ if (linked)
+-sink_set_state(s, PA_SINK_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa sink
++ * will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++sink_set_state(s, PA_SINK_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SINK_UNLINKED;
+ 
+diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
+index 02ae87a..c11d89b 100644
+--- a/src/pulsecore/source.c
 b/src/pulsecore/source.c
+@@ -702,7 +702,11 @@ void pa_source_unlink(pa_source *s) {
+ }
+ 
+ if (linked)
+-source_set_state(s, PA_SOURCE_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa
++ * source will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++source_set_state(s, PA_SOURCE_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SOURCE_UNLINKED;
+ 

Bug#933909: subdownloader: CLI broken

[Jan Braun]

Package: subdownloader
Version: 2.1.0~rc4-1
Severity: normal

Dear Maintainer,
I just tried the subdownloader version in experimental.

Sadly, I couldn't get it to do anything useful.

Previously, I would call subdownloader as
| subdownloader -c --rename-subs -l en -V .
, and it would automatically download english subs for all movies in the
current directory. :)

Now, it just dumps me at a poorly documented interactive prompt:
| $ subdownloader -c --rename-video -l en -V .
| SubDownloader 2.1.0rc4
| Type "help" for more information.
| >>>

I managed to use "filescan" to get it to scan the videos in the current
directory, and "login" and "vidsearch" to possibly search for something.
I'm unable to figure out how to download subtitles, because there are
"Number of subs to download: 0" according to "viddownload" , and
"vidselect" just complains about "Value out of range." for every index I
can think of.
Log attached.

Filed as "normal" because I might be dense and there's a simple fix, but
otherwise this should probably be RC.

In any case, however, users shouldn't have to fiddle around on an
interactive prompt just to get subdownloader to do the only thing it
could sensibly do. :(

Thank you for maintaining subdownloader,
Jan

P.S.: Changing the option which names the newly downloaded subs
according to the video filename from "--rename-subs" to
"--rename-video" seems *really* unfortunate.
P.P.S.: The manpage is missing a leading "-" for all the options at the
start of a line.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (650, 'testing-debug'), (550, 
'unstable-debug'), (550, 'unstable'), (10, 'experimental-debug'), (10, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages subdownloader depends on:
ii  python3  3.7.3-1
ii  python3-argcomplete  1.8.1-1
ii  python3-langdetect   1.0.7-3
ii  python3-progressbar  2.5-1
ii  python3-pymediainfo  3.0-2

Versions of packages subdownloader recommends:
ii  python3-pyqt5  5.11.3+dfsg-1+b3

subdownloader suggests no packages.

-- debconf-show failed
$ `which subdownloader` -c -l en -V . --debug
[2019-08-05 03:11:43,486] DEBUG: subdownloader.modules.metadata # Importing 
metadata parsing module ...
[2019-08-05 03:11:43,486] DEBUG: subdownloader.modules.metadata # Trying 
PyMediaInfoParser ...
[2019-08-05 03:11:43,504] DEBUG: subdownloader.modules.metadata # ... Succeeded
[2019-08-05 03:11:43,504] DEBUG: subdownloader.modules.metadata # Trying 
PyMediaInfoParser ...
[2019-08-05 03:11:43,505] DEBUG: subdownloader.modules.metadata # ... Succeeded
[2019-08-05 03:11:43,505] DEBUG: subdownloader.modules.metadata # ... Importing 
metadata parsing module finished
[2019-08-05 03:11:43,506] DEBUG: subdownloader.client.configuration # 
User-specific system configuration folder="/home/jani/.config"
[2019-08-05 03:11:43,506] DEBUG: subdownloader.client.configuration # 
User-specific SubDownloader configuration 
folder="/home/jani/.config/SubDownloader"
[2019-08-05 03:11:43,507] DEBUG: subdownloader.provider.factory # Attempting to 
import "subdownloader.provider.opensubtitles"...
[2019-08-05 03:11:43,507] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,507] DEBUG: subdownloader.provider.factory # Attempting to 
get "providers" from module...
[2019-08-05 03:11:43,507] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,507] DEBUG: subdownloader.provider.factory # Checking 
provider types:
[2019-08-05 03:11:43,508] DEBUG: subdownloader.provider.factory # - :
[2019-08-05 03:11:43,508] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,508] DEBUG: subdownloader.provider.factory # Attempting to 
import "subdownloader.provider.provider"...
[2019-08-05 03:11:43,508] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,508] DEBUG: subdownloader.provider.factory # Attempting to 
get "providers" from module...
[2019-08-05 03:11:43,509] DEBUG: subdownloader.provider.factory # ... FAILED
[2019-08-05 03:11:43,509] DEBUG: subdownloader.provider.factory # Attempting to 
import "subdownloader.provider.SDService"...
[2019-08-05 03:11:43,515] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,515] DEBUG: subdownloader.provider.factory # Attempting to 
get "providers" from module...
[2019-08-05 03:11:43,516] DEBUG: subdownloader.provider.factory # ... OK
[2019-08-05 03:11:43,516] DEBUG: subdownloader.provider.factory # Checking 
provider types:
[2019-08-05 03:11:43,516] DEBUG: subdownloader.provider.factory # - :
[2019-08-05 03:11:43,516] DEBUG: subdownloader.provider.factory # ... FAILED: 
not a SubtitleProvider
[2019-08-05 03:11:43,516] DEBUG: subdownloader.provider.factory # 

Bug#933908: bitcoind: symbol lookup error: bitcoind: undefined symbol: _ZN7leveldb4port5Mutex4LockEv

[Bug Report]

Package: bitcoind
Version: 0.18.0~dfsg-1
Severity: important

Dear Maintainer,

after apt upgrade this week, bitcoin-qt does not start anymore.
It fails with both of this errors message:

bitcoind: symbol lookup error: bitcoind: undefined symbol:
_ZN7leveldb4port5Mutex4LockEv

bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol:
_ZN7leveldb4port5Mutex6UnlockEv

Also reported by: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933311

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

Kernel: Linux 4.17.5 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bitcoin-qt depends on:
ii  libboost-chrono1.67.0  1.67.0-13
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libboost-thread1.67.0  1.67.0-13
ii  libc6  2.28-10
ii  libdb5.3++ 5.3.28+dfsg1-0.6
ii  libevent-2.1-6 2.1.8-stable-4
ii  libevent-pthreads-2.1-62.1.8-stable-4
ii  libgcc11:9.1.0-10
ii  libleveldb1d   1.22-3
ii  libminiupnpc17 2.1-1+b1
ii  libprotobuf17  3.6.1.3-2
ii  libqrencode4   4.0.2-1
ii  libqt5core5a   5.11.3+dfsg1-2
ii  libqt5dbus55.11.3+dfsg1-2
ii  libqt5gui5 5.11.3+dfsg1-2
ii  libqt5network5 5.11.3+dfsg1-2
ii  libqt5widgets5 5.11.3+dfsg1-2
ii  libsecp256k1-0 0.1~20170810-2
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 9.1.0-10
ii  libunivalue0   1.0.4-2
ii  libzmq54.3.2-1

bitcoin-qt recommends no packages.

bitcoin-qt suggests no packages.

-- no debconf information

Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities

[Daniel Richard G.]

On Sun, 2019 Aug  4 03:20-04:00, Salvatore Bonaccorso wrote:
>
> Sure it might have been overlooked, but pinging the existing bug would
> have been less overhead to now as well start tracking this one as well
> adjusting metadata etc. But no worries.

Just so that I understand, there was an existing bug? I checked the open
bugs before filing this one, but didn't see anything relating to those
CVEs. Do you mean something with the security tracker?

> CVSS severity scores are really very dependent and who assess it. I
> guess you are refering to the ones as assessed by NVD. Agreed though
> that Felix Wilhelm has provided a nice exploiting vector example in
> the upstream issue for local file access depending on context of how
> libxslt would be used.

And I figure LibXSLT is used in a number of ways that may result in
security exposure, not just within Debian itself, but also user
applications built on top of it.

> Anyway I prepared a non-maintainer upload for libxslt adressing all
> three CVEs in unstable and uploaded it to DELAYED/2 and create a merge
> request on salsa.

Thank you, I will watch for it in sid :)

Bug#931707: linux: HW_RANDOM_OMAP disabled for arm64 --> please enable

[Ben Hutchings]

On Tue, 2019-07-09 at 12:43 +, Josua Mayer wrote:
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
> While testing Debian 10 on a Marvell 8040 SoC I found that the rng and SSH 
> were
> coming up extremely slow, taking over a minute to start.
> 
> This is caused by somebody disabling the rng driver for arm64 kernels a long 
> time ago:
> linux (4.14.13-1) unstable; urgency=medium
> ...
>   [ Riku Voipio ]
>   * [arm64] disable CONFIG_HW_RANDOM_OMAP until the IRQ storm bug is fixed
> 
> What is this IRQ storm bug? Has it been fixed? Can we re-enable this driver?

Riku, what do you think?  I see that the MacchiatoBin has an Armada 8K
SoC, and there was an upstream commit in February 2018 that could be a
relevant fix:

commit b166be0044913a4ce03564e7c81f172025d78867
Author: Gregory CLEMENT 
Date:   Wed Feb 28 15:27:23 2018 +0100

hwrng: omap - Fix clock resource by adding a register clock

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein




signature.asc
Description: This is a digitally signed message part

Bug#933867: axmail: please use /var/ax25 not /var/lib/ax25

[Hibby]

This bug has been on my peripheral vision for a wee while, I’ll have a prod at 
it tomorrow night and get it uploaded. At least now I don’t need to check 
uronode too!

Cheers,
—
Hibby
MM3ZRZ

> On 4 Aug 2019, at 18:33, Iain Learmonth  wrote:
> 
> Hi,
> 
>> On 04/08/2019 16:59, Christoph Berg wrote:
>> Isn't that moving into the wrong direction, FHS-wise?
> 
> Yes, but I think that if someone really disagrees here then I would want
> tech-ctte to rule on it or something.
> 
> Changing all the other packages is going to use up a lot of time that
> could be used instead for improving the technical quality of the
> packages through testing, bug squashing and documentation instead of
> chasing down bugs triggered by moving the whole folder structure.
> 
> All the other packages use /var/ax25 and have for *decades*. Custom
> software people build is expecting /var/ax25.
> 
>> But judging from the file names, these look like they should be in
>> /usr/share instead.
> 
> The goal of the bug is to remove the last of /var/lib/ax25 from the
> archive, if the files move to /usr/share then that is also fine with me.
> (It does look to be a better place for them, but I don't know what they
> do or why they are there, maybe there is good reason.)
> 
> Thanks,
> Iain.
> 

Bug#933907: ITP: erlang-mimerl -- Erlang library to handle mimetypes

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 

* Package name: erlang-mimerl
  Version : 1.2.0
  Upstream Author : Benoit Chesneau 
* URL : https://github.com/benoitc/mimerl
* License : Expat
  Programming Lang: Erlang
  Description : Erlang library to handle mimetypes

Parse IANA media types (formerly known as MIME types). mimerl provides
functions to transform file extension to mimetype, web extension to
mimetype, filename to mimetype, web path to mimetype, and to return
the list of extensions for a mimetype.

This is a dependency of pleroma (#895050) (via erlang-hackney and
elixir-swoosh). I plan to maintain this package in erlang-team.

Bug#933791: gnupg: please document the consequences of not accepting third-party certifications from keyservers

[Georg Faerber]

Hi,

Just a short note on the following:

On 19-08-03 16:13:04, Francesco Poli (wintermute) wrote:
> Moreover, the usual recommendation after an identity and key
> fingerprint verification (at a key signing party or otherwise), is to
> sign Bob's key and then send the signed key to the Bob's e-mail
> address, in an encrypted message: Bob will send the signature to the
> keyserver network, only if he is in control of the secret key and if
> he actually wants the new signature to be disclosed to the public.
> This is the default procedure implemented in caff, isn't it?

FWIW, caff provides an option which might help with this, in case the
above does relate to the question "how does one keep track of which
signatures were made, given the current situation with keyservers and
distribution of signatures":

  also-lsign-in-gnupghome [auto|ask|no]

Whether to locally sign the UIDs in the user's GnuPGHOME, in
addition to caff's signatures in its own GnuPGHOME. Such signatures
are not exportable. This can be useful when the recipient forgets to
upload the signatures caff sent (or if they are non-exportable as
well), as it gives a way to keep track of which UIDs were verified.
However, note that local signatures will not be deleted once the
recipient does the upload and the signer refreshes her keyring.

[...]

(Sorry for the noise in case I'm off track.)

Cheers,
georg

Bug#933710: crosshurd: fails to download any packages

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Wojciech Aniszewski, le ven. 02 août 2019 11:57:34 +0200, a ecrit:
>crosshurd breaks citing the lack of i386 architecture.

Yes.

> |N: Skipping acquire of configured file 'main/binary-hurd-i386/Packages' 
> as repository 'http://httpredir.debian.org/debian unstable InRelease' doesn't 
> support architecture 'hurd-i386'

That repository doesn't support hurd-i386 any more indeed.

> It seems this program is abandonware, and the repos it points to don't exist.

It's not abandonware. It's just part of the so many dozens of places
which need updating now that ftpmaster has removed hurd from
the main archive.

Samuel

Bug#929411: dstat: upstream discontinued due to reimplementation by RedHat

[Andrew Pollock]

On Sun, Aug 04, 2019 at 07:20:37PM +0200, Emanuele Rocca wrote:
> Hi,
> 
> On 04/08 05:50, Otto Kekäläinen wrote:
> > There is however work now being done by Emmanuel Rocca at
> > https://salsa.debian.org/debian/dstat/commits/master
> > 
> > I have adopted rdiff-backup now, so I don't have interest in taking on any
> > new packages atm, so please Emmanuel continue the good work!
> 
> The package is now on salsa as you pointed out, so yeah feel free to
> help co-maintaining it anytime!
> 
> I've sent an email to the current maintainer of dstat, Andrew Pollock,
> asking whether he's still interested in working on the package. Waiting
> a few days for a reply before starting the MIA procedure.
> 
> Otto: can this bug be closed or is there any action required?
> 

Heya,

I'm around, but my email is totally out of control due to spam + lack of
time. I need to repoint it somewhere more manageable.

Let me go digging for the mail in question and reply...

regards

Andrew


signature.asc
Description: Digital signature

Bug#892102: Watchdog timeout expiring

[sixerjman]

I'll give it a whirl in a likely scenario (i.e. resume from suspend).

On Sun, Aug 4, 2019 at 5:02 PM Marco d'Itri  wrote:

> On Aug 04, Bálint Réczey  wrote:
>
> > This seems to be an issue in inetd's watchdog handling. What do you
> think?
> I suspect that the watchdog is being triggered because at that point the
> internal state of libevent is broken.
>
> It is implemented here, and there is not much that could go wrong unless
> you can spot any misuse on libevent on my part:
>
>
> https://salsa.debian.org/md/openbsd-inetd/blob/master/debian/patches/sd_daemon#L38
>
> sixerjman: can you still reproduce this bug? If you can then please try
> running inetd in valgrind.
>
> --
> ciao,
> Marco
>

Bug#933837: Info received (Bug#933837: mmark: upgrade to version 2)

[Dawid Dziurla]

Just take a look at hugo's source. It's still using mmark.

We could although make a new Debian package, since the import path and API 
changed for newer mmark.
Of course if there is a demand for it.

On August 4, 2019 3:55:36 PM GMT+02:00, Reto Kromer  wrote:
>Additional information received from the Hugo people:
>
>>I suppose that you are referring to building Hugo from source
>>since the binaries have no dependencies.
>>
>>However as far as I know upgrading mmark is not an easy thing
>>to do since it no longer uses
>>https://github.com/russross/blackfriday which is the Markdown
>>engine that Hugo uses.
>>
>>There is a long story about this, if you want to read it please
>>visit: https://github.com/gohugoio/hugo/issues/5124
>
>If I understand carefully, hugo uses currently blackfriday and
>not longer mmark, therefore there is no reason for not upgrading
>mmark in Debian. Or am I missing something?

Bug#933905: gnunet: erroneous patch introduces bashism

[Marcos Marado]

Package: gnunet
Version: 0.11.0-1
Severity: normal

Dear Maintainer,

Taking a look into the debianization of GNUnet, I realized that there is a
patch being applied that is intended fix bashisms, but, instead, seems to be
introducing one.

The culprit[1] patch is actually doing the opposite of what it initially did
when it was first introduced. During one of the version updates, a revert must
have caused this. The actual moment when the patch stopped doing what it was
supposed to, to do the opposite instead, can be seen here[2].

The fix is simple (just remove the patch), but if it is useful, here is a patch
providing the fix[3].

[1] 
https://salsa.debian.org/debian/gnunet/blob/experimental/debian/patches/fix-bashism.patch
[2] 
https://salsa.debian.org/debian/gnunet/commit/078e0f6d640e8e76347317a594778e7264639d62?view=parallel#0b9c97552d404c78fa9130139fa8f102743b8591_15_12
[3] 
https://github.com/marado/debian-gnunet/commit/427dff7a65a16135e393e46704f3d8db12b8

Best regards,
Marcos Marado

-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500,
'disco'), (100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-21-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnunet depends on:
ii  adduser3.118ubuntu1
ii  debconf [debconf-2.0]  1.5.71ubuntu1
ii  libatomic1 9.1.0-2ubuntu2~19.04
ii  libc6  2.29-0ubuntu2
ii  libcurl3-gnutls7.64.0-2ubuntu1.1
ii  libextractor3  1:1.8-2
ii  libgcrypt201.8.4-3ubuntu1
ii  libgnutls-dane03.6.8-1
ii  libgnutls303.6.8-1
ii  libidn2-0  2.0.5-1
ii  libjansson42.12-1build1
ii  libltdl7   2.4.6-10
ii  libmariadb31:10.3.13-2
ii  libmicrohttpd120.9.62-1
ii  libogg01.3.2-1
ii  libopus0   1.3-1
ii  libpq5 11.4-0ubuntu0.19.04.1
ii  libpulse0  1:12.2-2ubuntu3
ii  libsqlite3-0   3.27.2-2ubuntu0.1
ii  libunistring2  0.9.10-1ubuntu2
ii  lsb-base   10.2019031300ubuntu1
ii  netbase5.6
ii  zlib1g 1:1.2.11.dfsg-1ubuntu2

Versions of packages gnunet recommends:
ii  libnss3-tools  2:3.44.0-1
ii  openssl1.1.1b-1ubuntu2.1

Versions of packages gnunet suggests:
pn  miniupnpc
ii  python   2.7.16-1
pn  python-zbar  
pn  texlive  

-- debconf information:
  gnunet-server/groupname: gnunet
  gnunet-server/autostart: true
  gnunet-server/username: gnunet

Bug#933904: RFS: gnss-sdr/0.0.11-1

[Carles Fernandez]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "gnss-sdr"

 * Package name: gnss-sdr
   Version : 0.0.11-1
   Upstream Author : Carles Fernandez  carles.fernan...@cttc.es
 * URL :  https://gnss-sdr.org
 * License : GPL v3
   Section : hamradio

  It builds those binary packages:

gnss-sdr - Global navigation satellite systems software defined receiver

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gnss-sdr


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/gnss-sdr/gnss-sdr_0.0.11-1.dsc

  More information about gnss-sdr can be obtained from https://gnss-sdr.org.

  Changes since the last upload:

  * First release of upstream version 0.0.11
  * Standards-Version updated to 4.4.0.0
  * Removed debian/compat file, added debhelper-compat (= 12) in control file
  * Update copyright file with new code additions and copyright years
  * Add Protocol Buffers dependencies (libprotobuf-dev, protobuf-compiler)


  Regards,
   Carles Fernandez



-- 

Dr. Carles Fernández Prades
Senior Researcher
Head of Statistical Inference for Comm. & Positioning Dept.
Communication Systems Division

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Address: Parc Mediterrani de la Tecnologia
  Av. Carl Friedrich Gauss, 7
  08860 Castelldefels, Barcelona, Spain.
Phone: +34 936452900Fax: +34 936452901
http://www.cttc.es/people/cfernandez/  

Bug#803894: localepurge: locale tt not purged

[Miguel Figueiredo]

Package: localepurge
tags: patch

Using ? instead of * will match 1 time only.

-echo $(grep --invert-match --extended-regexp '^[ \t]*(#|$)' 
$NOPURGECONF)
+echo $(grep --invert-match --extended-regexp '^[ \t]?(#|$)' 
$NOPURGECONF)



-localelist=$(grep --invert-match --extended-regexp '^[ \t]*(#|$)' 
$LOCALELIST)
+localelist=$(grep --invert-match --extended-regexp '^[ \t]?(#|$)' 
$LOCALELIST)


--
Best regards / Melhores cumprimentos,

Miguel Figueiredo

Bug#930679: Please add overridable tag for not using dh sequencer

[Mattia Rizzolo]

On Sun, Aug 04, 2019 at 11:05:23PM +0100, Chris Lamb wrote:
> Somewhat related, but if we introduce this mooted "package-does-not-
> use- dh-sequencer" we need to work out what to do with:
> 
>   https://lintian.debian.org/tags/package-does-not-use-debhelper-or-cdbs.html
> 
> One thing we can probably all agree with is that the severity of
> package-does-not-use-debhelper-or-cdbs should be equal to or exceed
> the severity of package-does-not-use-dh-sequencer as one is a logical
> subset of another.

I just reported 3 bugs (#933901, #933902, #933903) with false positives
of that tag.  I just looked a bunch of them and couldn't find a single
true positive, so I think that tag should be reviewed before bumping its
severity.

I think those bugs should be squashed, reviewed, and then bumped to W.
Only once there are very few packages with that should
package-goes-not-use-dh-sequencer be bumped to W as well.
(note that package-does-not-)se-debhelper-or-cdbs does not emit for
classic-style debhelper rules files.)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#933802: /usr/bin/mandb: SIGSEGV, Segmentation fault on updating database.

[Colin Watson]

Control: severity -1 serious
Control: tag -1 fixed-upstream

On Sat, Aug 03, 2019 at 01:28:25PM -0400, Daniel Serpell wrote:
> After today update, man-db segfaults when rebuilding database.

Oops, thanks.  Should be fixed upstream now:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=1332c29200c1770deef23b355f3589de924dfcb4

I'll do a bit more testing and then upload a bug-fix release.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#933903: lintian: false positives for package-does-not-use-debhelper-or-cdbs

[Mattia Rizzolo]

Package: lintian
Version: 2.16.0

A couple more false positives:

python-pbcommand/1.1.1-1
this actually uses dh

steptalk/0.10.0-6
this really usese cdbs

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#933902: lintian: false positive for package-does-not-use-debhelper-or-cdbs

[Mattia Rizzolo]

Package: lintian
Version: 2.16.0

Similarly to the last bug, java packages using javahelper (see for
example src:jesd, version 0.0.7-4) use cdbs as their "backend".
See /usr/share/cdbs/1/class/javahelper.mk

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#933901: lintian: false positive for package-does-not-use-debhelper-or-cdbs

[Mattia Rizzolo]

Package: lintian
Version: 2.16.0

I went looking to the tag page of this after your message in #930679,
and I noticed a number of qt-kde packages, like akonadi-calendar version
418.08.3-1.

Those packages using
/usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk are false
positives, as they (eventually) call `dh` I'm not sure how to properly
categorize them, if using `dh` or their own buildsystem, but they
shouldn't emit this tag.
In particular, I didn't check what classification tag they emit.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#933685: transition: http-parser

[Christoph Biedl]

Jonathan Wiltshire wrote...

> Control: tag -1 confirmed
> 
> On Thu, Aug 01, 2019 at 10:12:08PM +0200, Christoph Biedl wrote:
> > following the procedures as written in the Debian wiki, I am requesting
> > a transition slot for the http-parser library 2.9.2, accepted in
> > experimental earlier today.
> 
> Please go ahead in unstable.

Thanks, now uploaded to unstable.

Christoph


signature.asc
Description: PGP signature

Bug#930679: Please add overridable tag for not using dh sequencer

[Chris Lamb]

tags 930679 + moreinfo
thanks

Chris Lamb wrote:

> Can you elaborate why you think it would not make a lot of sense? Tags
> with "I:"-level severity get a lot of visibility and people make
> substantive changes if they see them. And, sardonically-speaking, the
> Lintian maintainers get reports close to flames for pedantic
> level... :)

Somewhat related, but if we introduce this mooted "package-does-not-
use- dh-sequencer" we need to work out what to do with:

  https://lintian.debian.org/tags/package-does-not-use-debhelper-or-cdbs.html

One thing we can probably all agree with is that the severity of
package-does-not-use-debhelper-or-cdbs should be equal to or exceed
the severity of package-does-not-use-dh-sequencer as one is a logical
subset of another. Thus either we introduce package-does-not-use-dh-
sequencer as a pedantic level (-1 on this here...) or we bump both of
them higher to possibly-varying degrees.

(Tagging moreinfo as appropriate.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#933879: cups: Samsung CLP315 fails after update from Stretch to Buster

[Brian Potkin]

On Sun 04 Aug 2019 at 22:50:26 +0200, Rudolf Polzer wrote:

> > Which driver package are you using?
> 
> I am not sure what you mean by driver package.
> In the cups web interface, I select
> - USB connection
> - Samsung
> - Samsung CL-310 Series (SPL-C) (en)

You will have a PPD for the printer in /etc/cups/ppd/. What does the
*NickName line in it say?

-- 
Brian.

Bug#721626: texlive-base: .pfm files really needed?

[Norbert Preining]

On Sun, 04 Aug 2019, Hilmar Preuße wrote:
> hille@debian-amd64-sid:~$ apt-file search .pfm|grep texlive|wc -l
> 567
> 
> Need help here? Simply blacklisting in
> texlive-nonbin/all/debian/tpm2deb.cfg ?

Yes, that should be fine. Probably some patterns would be nice.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#933900: $KOPANO_USERSCRIPT_LOCALE doesn't have impact on store language

[Martin Wolf]

Package: kopano-server
Version: 8.7.0-3

It seems like $KOPANO_USERSCRIPT_LOCALE doesn't have any impact on the
store language anymore: Setting

> KOPANO_USERSCRIPT_LOCALE="de_DE.UTF-8"

in /etc/default/kopano should lead to German folder names in newly
created users (with fresh stores). However it doesn't, even when the
locale de_DE.UTF-8 is available.

When looking to /usr/lib/kopano/userscripts/createuser.d/00createstore
the parameter for passing the locale during store creation is missing,
likely an upstream issue:

https://stash.kopano.io/projects/KC/repos/kopanocore/commits/e3ca620ca41a955668654f8d0e71532650bbfcef#installer/userscripts/createuser.d/00createstore

Restoring the old behaviour by using

> exec kopano-storeadm -Cn "$KOPANO_USER" -l "${KOPANO_USERSCRIPT_LOCALE}"

instead still does not work, because $KOPANO_USERSCRIPT_LOCALE doesn't
seem to be passed through to the userscript. Replacing
$KOPANO_USERSCRIPT_LOCALE by a hardcoded "de_DE.UTF-8" (directly in the
userscript) leads to the desired result.

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64
GNU/Linux

Bug#933899: buster-pu: package devscripts/2.19.5+deb10u1

[Mattia Rizzolo]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster

Dear SRM,

I'm proposing the attached update to devscripts, with the only change
being the update to the default target for `dch --bpo` (and
`dch --stable`, but nobody uses that :P).

I have already uplodaded it to buster, please consider this update in
the upcoming point release.

TIA.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for devscripts-2.19.5 devscripts-2.19.5+deb10u1

 debian/changelog   |8 
 po4a/po/de.po  |6 +++---
 po4a/po/devscripts.pot |4 ++--
 po4a/po/fr.po  |6 +++---
 scripts/debchange.1|2 +-
 scripts/debchange.pl   |6 +++---
 test/test_debchange|8 
 7 files changed, 24 insertions(+), 16 deletions(-)

diff -Nru devscripts-2.19.5/debian/changelog devscripts-2.19.5+deb10u1/debian/changelog
--- devscripts-2.19.5/debian/changelog	2019-05-09 17:01:29.0 +0200
+++ devscripts-2.19.5+deb10u1/debian/changelog	2019-08-04 23:15:44.0 +0200
@@ -1,3 +1,11 @@
+devscripts (2.19.5+deb10u1) buster; urgency=medium
+
+  [ Thomas Goirand ]
+  * debchange:
++ Target buster-backports with --bpo.  Closes: #931614
+
+ -- Mattia Rizzolo   Sun, 04 Aug 2019 23:15:44 +0200
+
 devscripts (2.19.5) unstable; urgency=medium
 
   [ Topi Miettinen ]
diff -Nru devscripts-2.19.5/po4a/po/de.po devscripts-2.19.5+deb10u1/po4a/po/de.po
--- devscripts-2.19.5/po4a/po/de.po	2019-05-09 16:52:23.0 +0200
+++ devscripts-2.19.5+deb10u1/po4a/po/de.po	2019-08-04 23:15:42.0 +0200
@@ -7,7 +7,7 @@
 msgstr ""
 "Project-Id-Version: devscripts 2.18.9\n"
 "Report-Msgid-Bugs-To: devscri...@packages.debian.org\n"
-"POT-Creation-Date: 2019-04-28 16:23+0200\n"
+"POT-Creation-Date: 2019-07-09 11:23+0200\n"
 "PO-Revision-Date: 2019-01-27 10:18+0200\n"
 "Last-Translator: Chris Leick \n"
 "Language-Team: de \n"
@@ -7368,10 +7368,10 @@
 #. type: Plain text
 #: ../scripts/debchange.1:264
 msgid ""
-"Increment the Debian release number for an upload to stretch-backports, and "
+"Increment the Debian release number for an upload to buster-backports, and "
 "add a backport upload changelog comment."
 msgstr ""
-"erhöht die Debian-Veröffentlichungsnummer für ein Hochladen nach stretch-"
+"erhöht die Debian-Veröffentlichungsnummer für ein Hochladen nach buster-"
 "backports und fügt einen Changelog-Kommentar »backport upload« hinzu."
 
 #. type: TP
diff -Nru devscripts-2.19.5/po4a/po/devscripts.pot devscripts-2.19.5+deb10u1/po4a/po/devscripts.pot
--- devscripts-2.19.5/po4a/po/devscripts.pot	2019-05-09 17:01:29.0 +0200
+++ devscripts-2.19.5+deb10u1/po4a/po/devscripts.pot	2019-08-04 23:15:44.0 +0200
@@ -7,7 +7,7 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2019-04-28 16:23+0200\n"
+"POT-Creation-Date: 2019-07-09 11:23+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
@@ -5590,7 +5590,7 @@
 #. type: Plain text
 #: ../scripts/debchange.1:264
 msgid ""
-"Increment the Debian release number for an upload to stretch-backports, and "
+"Increment the Debian release number for an upload to buster-backports, and "
 "add a backport upload changelog comment."
 msgstr ""
 
diff -Nru devscripts-2.19.5/po4a/po/fr.po devscripts-2.19.5+deb10u1/po4a/po/fr.po
--- devscripts-2.19.5/po4a/po/fr.po	2019-05-09 16:52:23.0 +0200
+++ devscripts-2.19.5+deb10u1/po4a/po/fr.po	2019-08-04 23:15:42.0 +0200
@@ -14,7 +14,7 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: devscripts\n"
-"POT-Creation-Date: 2019-04-28 16:23+0200\n"
+"POT-Creation-Date: 2019-07-09 11:23+0200\n"
 "PO-Revision-Date: 2019-04-28 16:32+0200\n"
 "Last-Translator: Xavier Guimard \n"
 "Language-Team: French \n"
@@ -7386,10 +7386,10 @@
 #. type: Plain text
 #: ../scripts/debchange.1:264
 msgid ""
-"Increment the Debian release number for an upload to stretch-backports, and "
+"Increment the Debian release number for an upload to buster-backports, and "
 "add a backport upload changelog comment."
 msgstr ""
-"Incrémenter le numéro de publication de Debian pour un envoi dans stretch-"
+"Incrémenter le numéro de publication de Debian pour un envoi dans buster-"
 "backports, et ajouter un commentaire pour l'envoi du rétroportage dans le "
 "journal des modifications."
 
diff -Nru devscripts-2.19.5/scripts/debchange.1 devscripts-2.19.5+deb10u1/scripts/debchange.1
--- devscripts-2.19.5/scripts/debchange.1	2019-03-01 10:39:51.0 +0100
+++ devscripts-2.19.5+deb10u1/scripts/debchange.1	2019-07-09 14:20:55.0 +0200
@@ -259,7 +259,7 @@
 distribution. Increment the Debian version.
 .TP
 .B 

Bug#933897: RM: ruby-fog-cloudatcost/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#772928: [pdftex] Add option -synctex to pdftex(1)

[Karl Berry]

Subject: [pdftex] Add option -synctex to pdftex(1)

I applied this patch (and made some other updates at the same time).
TL r51815. Thanks. -k

Bug#933896: RM: tabmixplus/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933894: RM: open-infrastructure-system-images/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933898: RM: flif/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933895: RM: open-infrastructure-system-build/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933892: RM: targetcli/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933893: RM: pybliographer/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933890: RM: libjs-handlebars.runtime/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933888: RM: dh-haskell/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933889: qbittorrent: new upstream 4.1.7

[Jonatan Nyberg]

Package: qbittorrent
Version: 4.1.7

Please consider to upgrade to the current upstream version (4.1.7).

Regards
Jonatan

Bug#933887: Default userscripts try to execute relocated kscriptrun

[Martin Wolf]

Package: kopano-server
Version: 8.7.0-3

The default userscript for adding new users in
/usr/lib/kopano/userscripts/createuser tries to execute kscriptrun, but
fails, because it has been relocated (moved).

As of writing, the /usr/lib/kopano/userscripts/createuser contains as
last line:

> exec "/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/createuser.d
/etc/kopano/userscripts/createuser.d

However due to kscriptrun relocation, it should be instead:

> exec "/usr/lib/x86_64-linux-gnu/kopano/kscriptrun"
/usr/lib/kopano/userscripts/createuser.d
/etc/kopano/userscripts/createuser.d

Note that this indeed affects all userscripts which breaks all
administrative user/group/company interactions:

$ grep -r kscriptrun /usr/lib/kopano/userscripts/
/usr/lib/kopano/userscripts/deletegroup:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/deletegroup.d
/etc/kopano/userscripts/deletegroup.d
/usr/lib/kopano/userscripts/createuser:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/createuser.d
/etc/kopano/userscripts/createuser.d
/usr/lib/kopano/userscripts/createcompany:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/createcompany.d
/etc/kopano/userscripts/createcompany.d
/usr/lib/kopano/userscripts/creategroup:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/creategroup.d
/etc/kopano/userscripts/creategroup.d
/usr/lib/kopano/userscripts/deleteuser:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/deleteuser.d
/etc/kopano/userscripts/deleteuser.d
/usr/lib/kopano/userscripts/deletecompany:exec
"/usr/libexec/kopano/kscriptrun"
/usr/lib/kopano/userscripts/deletecompany.d
/etc/kopano/userscripts/deletecompany.d
$

I guess the relocation happened because Debian doesn't populate
/usr/libexec directory.

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64
GNU/Linux

Bug#933891: RM: configshell/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#932943: Missing SHA512 and gpg signature

[Chris Boot]

On 04/08/2019 17:29, Bastian Blank wrote:
> On Sat, Aug 03, 2019 at 03:06:39PM +0100, Chris Boot wrote:
>> - Which checksums should we include? Our Apt repos use MD5 and SHA-256,
>> and our ISOs use MD5, SHA-1, SHA-256 and SHA-512. I'd be inclined to
>> suggest SHA-256 and SHA-512 only, personally.
> 
> Only one of them.  And I would go directly to SHA3 for new stuff.

Buster doesn't have any SHA3 tools in coreutils. While I don't have
anything against calculating such checksums in addition to the usual
suspects, I want to make sure people with current distros can easily
check them.

>> 1. Add labels of the form "checksum.cloud.debian.org/${ALGO}" under
>> metadata.labels, for example "checksum.cloud.debian.org/sha256".
> 
> Labels are to search for stuff, not describe the content.

That seems like a good enough reason.

>> 3. Add a new mapping within the "data" mapping called "checksums" with
>> keys for each algorithm, e.g. "data.checksums.sha256".
> 
> The usual way would be something like this:
> 
> | data:
> |   verify:
> |   - name: sha3_256
> | content: ABC=
> |   - name: gpg
> | content: AAA=

That kind of structure works for me. That way we *can*[1] have checksums
for multiple image formats and multiple algorithms, e.g. the raw image,
qcow2, compressed tarball, or whatever.

1. I carefully chose that word. I don't wish to imply that we should,
necessarily, I would just like to keep the options open.

>> In each case I expect the values to be hex strings, effectively the same
>> as the first column of the output from sha1sum, sha256sum, sha512sum,
>> etc... from coreutils.
> 
> No, don't.  Use base64 like everyone else.

I strongly disagree with this. Practically everyone else uses
hexadecimal for plain checksums. A GPG signature is its own thing but is
(generally) plaintext (I'm assuming clearsign). This is what we (as in
the project) use for the archive and for ISOs.

Kubernetes does usually Base64 encode data in Secret resources (though
stringData seems to be a well-kept, um, secret) and I don't really
understand where that came from. I'm not convinced that by itself is a
good example to follow.

Cheers,
Chris

-- 
Chris Boot
bo...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#892102: Watchdog timeout expiring

[Marco d'Itri]

On Aug 04, Bálint Réczey  wrote:

> This seems to be an issue in inetd's watchdog handling. What do you think?
I suspect that the watchdog is being triggered because at that point the 
internal state of libevent is broken.

It is implemented here, and there is not much that could go wrong unless 
you can spot any misuse on libevent on my part:

https://salsa.debian.org/md/openbsd-inetd/blob/master/debian/patches/sd_daemon#L38

sixerjman: can you still reproduce this bug? If you can then please try 
running inetd in valgrind.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#933886: AppArmor configuration doesn't cover userscripts

[Martin Wolf]

Package: kopano-server
Version: 8.7.0-3

The default AppArmor configuration file
/etc/apparmor.d/usr.sbin.kopano-server doesn't cover the default
userscripts in /usr/lib/kopano/userscripts/*, which are required to e.g.
create or delete a new user (or a company/tenancy), thus basically
everything. The AppArmor configuration however covers individual
userscripts in /etc/kopano/userscripts/* somehow, while
/etc/kopano/userscripts/* doesn't exist by default and
/usr/lib/kopano/userscripts/* is referenced in /etc/kopano/server.cfg as
default.

Adding "  /usr/lib/kopano/userscripts/* Cxr -> kopano_userscripts," to
/etc/apparmor.d/usr.sbin.kopano-server seems to help.

Error without the modified AppArmor policy:

Aug  4 22:48:45 kernel: [ 1294.408531] audit: type=1400
audit(1564951725.740:75): apparmor="DENIED" operation="exec"
profile="/usr/sbin/kopano-server"
name="/usr/lib/kopano/userscripts/createcompany" pid=2333
comm=7A2D733A20 requested_mask="x" denied_mask="x" fsuid=110 ouid=0
Aug  4 22:48:45 kernel: [ 1294.460467] audit: type=1400
audit(1564951725.792:76): apparmor="DENIED" operation="exec"
profile="/usr/sbin/kopano-server"
name="/usr/lib/kopano/userscripts/createuser" pid=2335 comm=7A2D733A20
requested_mask="x" denied_mask="x" fsuid=110 ouid=0

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64
GNU/Linux

Bug#933885: ITP: GNU Health - a hospital information system

[Mathias Behrle]

Am 4. August 2019 22:44:51 MESZ schrieb Sakirnth Nagarasa :
>Package: gnuhealth
>Owner: sakir...@gmail.com
>
>* Package name: gnuhealth
>  Upstream Author : GNU Health contributors
>* License : GPL-3+
>  Description : GNU Health is a Free/Libre project for health
>practitioners, health institutions and governments. It provides the
>functionality of Electronic Medical Record (EMR), Hospital Management
>(HMIS) and Health Information System (HIS).
>
>Its modular design allows to be deployed in many different scenarios:
>from small private offices, to large, national public health systems.
>
>Greetings,
>
>Sakirnth (Saki)

Dear Sakirnth,

thanks a lot that you want to bring GNU Health nearer to Debian Users.

There are many implications to solve to interact correctly with the Tryton 
suite in which GNU Health is based. Are you aware of the efforts already done 
in Debian and on debian.tryton.org.

Cheers
Mathias

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6

Bug#933879: cups: Samsung CLP315 fails after update from Stretch to Buster

[Rudolf Polzer]

Which driver package are you using?


I am not sure what you mean by driver package.
In the cups web interface, I select
- USB connection
- Samsung
- Samsung CL-310 Series (SPL-C) (en)

Regards,
Rudolf

Bug#933885: ITP: GNU Health - a hospital information system

[andreimpopescu]

Control: reassign -1 wnpp

On Du, 04 aug 19, 22:44:51, Sakirnth Nagarasa wrote:
> Package: gnuhealth
> Owner: sakir...@gmail.com
> 
> * Package name: gnuhealth
>   Upstream Author : GNU Health contributors
> * License : GPL-3+
>   Description : GNU Health is a Free/Libre project for health
> practitioners, health institutions and governments. It provides the
> functionality of Electronic Medical Record (EMR), Hospital Management
> (HMIS) and Health Information System (HIS).
> 
> Its modular design allows to be deployed in many different scenarios:
> from small private offices, to large, national public health systems.
> 
> Greetings,
> 
> Sakirnth (Saki)

-- 
Looking after bugs reported against inexistent or removed packages


signature.asc
Description: PGP signature

Bug#933885: ITP: GNU Health - a hospital information system

[Sakirnth Nagarasa]

Package: gnuhealth
Owner: sakir...@gmail.com

* Package name: gnuhealth
  Upstream Author : GNU Health contributors
* License : GPL-3+
  Description : GNU Health is a Free/Libre project for health
practitioners, health institutions and governments. It provides the
functionality of Electronic Medical Record (EMR), Hospital Management
(HMIS) and Health Information System (HIS).

Its modular design allows to be deployed in many different scenarios:
from small private offices, to large, national public health systems.

Greetings,

Sakirnth (Saki)

Bug#933685: transition: http-parser

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Aug 01, 2019 at 10:12:08PM +0200, Christoph Biedl wrote:
> following the procedures as written in the Debian wiki, I am requesting
> a transition slot for the http-parser library 2.9.2, accepted in
> experimental earlier today.

Please go ahead in unstable.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#933645: transition: libvpx

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Aug 01, 2019 at 01:38:40PM +0200, Ondřej Nový wrote:
> libvpx6 is ABI incompatible with libvpx5. libvpx6 is ready in experimental.
> 
> Thanks for transition.

Please go ahead in unstable.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#933884: CVE-2019-14541 CVE-2019-14528 CVE-2019-14486 CVE-2019-14468

[Moritz Muehlenhoff]

Source: gnucobol
Severity: important
Tags: security

There have been a few CVE assignments for some fuzzing done on GNU Cobol:

CVE-2019-14541:
https://sourceforge.net/p/open-cobol/bugs/584/

CVE-2019-14528:
https://sourceforge.net/p/open-cobol/bugs/583/

CVE-2019-14486:
https://sourceforge.net/p/open-cobol/bugs/582/

CVE-2019-14468:
https://sourceforge.net/p/open-cobol/bugs/581/

Cheers,
Moritz
 

Bug#561453: xdvi: scroll behaviour inconsistent

[Hilmar Preuße]

Hi Joachim,

> in xdvi, if you zoom into the page (e.g. to have the text fill the whole
> width, and not was space for the margin), moving around with PgDwn or
> PgUp keeps this horizontal factor in tact, e.g on other page the text
> sill stay centered. But if I use Space or Del to go to another page, the
> zoom factor is retained, but the horizontal positioning is reset, e.g. I
> see the very left of the page. This is surprising and not helpful.
> 
About ten years later...

I'm failing to reproduce. Currently the behaviour seems be consistent.
xdvi jumps back to the left border in case xdvi.keepPosition is not set,
but keeps the position if it is. This works w/
///.

Is the issue solved?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933881: RM: libswe-doc -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove libswe-doc. It's unmaintained (last upload in 2013) and FTBFS 
since
2015 (#783936) and thus missed two stable releases already.

Cheers,
Moritz

Bug#933882: Should percona-xtrabackup be removed?

[Moritz Muehlenhoff]

Source: percona-xtrabackup
Severity: serious

Should percona-xtrabackup be removed?

- Unmaintained (last maintainer upload in 2014)
- FTBFS with GCC 6 and later (#811896) and #917583
- Missed two stable releases because of that
- Broken with current Mariadb (#903043)
- Replacement exists (mariabackup)

Cheers,
Moritz

Bug#933883: Should zope2.13 be removed?

[Moritz Muehlenhoff]

Source: zope2.13
Severity: serious

Should zope2.13 be removed?

- Unmaintained (last upload in 2014)
- FTBFS for a long time, missed two stable releases

Cheers,
Moritz

Bug#932948: transition: double-conversion

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jul 24, 2019 at 06:57:38PM -0700, Mo Zhou wrote:
> Upstream had already bumped their SOVERSION to 3
> long time ago. We didn't bump it in the past
> because the ABI is actually compatible.
> According to the previous discussion on -devel,
> I'd better bump it to 3 following upstream.

Please go ahead in unstable.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#919659: (no subject)

[Kunal Nagar]

Is there an update on this bug? I'm running live build using Travis and 
Docker to build a custom Debian re-spin and facing this exact same issue.

Bug#933879: cups: Samsung CLP315 fails after update from Stretch to Buster

[Brian Potkin]

On Sun 04 Aug 2019 at 19:59:10 +0200, Rudolf Polzer wrote:

> Subject: cups: Samsung CLP315 fails after update from Stretch to Buster
> Package: cups
> Version: 2.2.10-6
> Severity: normal

[...]

> The printer worked with Stretch.
> With Buster, the printer prints the following text for any printed page:
> 
> SPL-C ERROR - please use the proper driver
>   POSITION : 0x0 (0)
>   SYSTEM   : src/xl_image
>   LINE : 606
>   VERSION  : SPL-C 5.35 11-20-2007
> 
> I have already tried within the cups web interface to change the printer
> setup and tried to delete the printer and then reassign connection and ppd
> file - but that did not make any change.

Thank you for your report, Rudolf.

Which driver package are you using?

-- 
Brian.

Bug#933379: backup-manager 0.7.14-1+deb10u1 flagged for acceptance

[Jonathan Wiltshire]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: backup-manager
Version: 0.7.14-1+deb10u1

Explanation: fix purging of remote archives via FTP or SSH

Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc

[Hilmar Preuße]

Am 28.09.2010 um 14:30 teilte Eugen Dedu mit:

Hi,

Does this address work?

> I have an error when using lmodern fonts together with T1 fontenc (as
> required by French babel to have correct hyphenation on accentuated
> characters).  When using pdflatex or latex on the following text:
> 
It is still unclear why the mf files from the EC fonts are used, when
lmodern fonts are requested. I forwarded the question to tex.sx.

https://tex.stackexchange.com/questions/502820/lmodern-latex-tries-to-create-tfm-files-for-ec-fonts

Hilmar
-- 
sigfault
#206401 http://counter.li.org





signature.asc
Description: OpenPGP digital signature

Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc

[Hilmar Preuße]

Am 28.09.2010 um 14:30 teilte Eugen Dedu mit:

Hi,

> I have an error when using lmodern fonts together with T1 fontenc (as
> required by French babel to have correct hyphenation on accentuated
> characters).  When using pdflatex or latex on the following text:
> 
It is still unclear why the mf files from the EC fonts are used, when
lmodern fonts are requested. I forwarded the question to tex.sx.

https://tex.stackexchange.com/questions/502820/lmodern-latex-tries-to-create-tfm-files-for-ec-fonts

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#930000: Proton Verification Code

[ProtonMail]

Your Proton verification code is:
957968

Bug#932943: Missing SHA512 and gpg signature

[Steve McIntyre]

On Sun, Aug 04, 2019 at 08:38:38PM +0200, Thomas Lange wrote:
>> On Sun, 4 Aug 2019 18:29:30 +0200, Bastian Blank  said:
>
>>> In each case I expect the values to be hex strings, effectively the same
>>> as the first column of the output from sha1sum, sha256sum, sha512sum,
>>> etc... from coreutils.
>
>> No, don't.  Use base64 like everyone else.
>Can you explain why we should use base64? On cdimages.d.o we also use
>the plain output of the shaXXXsums commands.

+1. It's what we have all over the place.

Ditto for having sha256 and sha512.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   https://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#932755: sdl-image1.2: multiple security issues

[Salvatore Bonaccorso]

Hi

FTR, there are new CVEs which appeared for TALOS-2019-0841
TALOS-2019-0842, TALOS-2019-0843 and TALOS-2019-0844.

It is unfortunate that Cisco Talos project is a bit intransparent on
referencing the respecitve upstream fixes after disclosure :(

Regards,
Salvatore

Bug#933147: buster-pu: package libsdl2-image/2.0.4+dfsg1+deb10u1

[Salvatore Bonaccorso]

Hi Hugo,

Maybe I'm missing something but but please double check. Can it be
that the stretch-pu upload contains the fix
https://hg.libsdl.org/SDL_image/rev/b1a80aec2b10 for TALOS-2019-0842
but the buster-pu one missed it? (Note this has a new CVE assigned
CVE-2019-5058, the change afaics is included in your stretch-pu
debdiff, is this right? but not in the buster-pu one?)

Would be great if you can re-check if the above is correct.

Regards,
Salvatore

Bug#618033: AW: Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads to files not opening (x86 /32bit)

[Schnizer, Pierre]

Agreed!

-Ursprüngliche Nachricht-
Von: Hilmar Preuße [mailto:hill...@web.de]
Gesendet: Sonntag, 4. August 2019 20:55
An: Schnizer, Pierre 
Cc: 618...@bugs.debian.org; Pierre SCHNIZER 
Betreff: Re: Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads 
to files not opening (x86 /32bit)

Am 04.08.2019 um 19:53 teilte Schnizer, Pierre mit:

Hi,

> Sorry I  do not know if that bug still exists.  I am not using a cifs
> mounted file system any more.
>
Neither do I. So probably there is no use case any more.

OK to close?

Hilmar
--
sigfault
#206401 http://counter.li.org




Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta 
Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas 
Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

Bug#931800: Bug 931800: mark as pending (MR merged)

[Boyuan Yang]

Control: tags -1 + pending

I've merged it in the git packaging repo. Thanks!

Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#933842: crashes when switching monitor input under wayland

[Stéphane Glondu]

Le 04/08/2019 à 14:23, Simon McVittie a écrit :
>> Since recently, gnome-shell on wayland crashes when I switch the input
>> of my monitor. This is a regression. And I don't observe the bug on
>> X11.
> 
> Please try upgrading libmutter-3-0 and gir1.2-mutter-3 to 3.30.2-8
> from unstable, then reboot (or at least log out from GNOME and back in)
> to make sure that GNOME Shell is using the upgraded libraries.

I also had to upgrade mutter-common to same version. The problem seems
to have disappeared.


Cheers,

-- 
Stéphane

Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads to files not opening (x86 /32bit)

[Hilmar Preuße]

Am 04.08.2019 um 19:53 teilte Schnizer, Pierre mit:

Hi,

> Sorry I  do not know if that bug still exists.  I am not using a cifs
> mounted file system any more.
> 
Neither do I. So probably there is no use case any more.

OK to close?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#721626: texlive-base: .pfm files really needed?

[Hilmar Preuße]

Am 02.09.2013 um 16:36 teilte Norbert Preining mit:
> On Mo, 02 Sep 2013, Fabian Greffrath wrote:

Hi Norbert,

>> Debian system that contain .pfm files.
> 
> Can be trashed according to all knowledge I have.
> 
hille@debian-amd64-sid:~$ apt-file search .pfm|grep texlive|wc -l
567

Need help here? Simply blacklisting in
texlive-nonbin/all/debian/tpm2deb.cfg ?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#932499: tigervnc-standalone-server: does not start in buster on arm64

[Bernhard Übelacker]

Control: fixed -1 tigervnc/1.9.0+dfsg-1


Dear Maintainer,
I tried to have another look at it and collected some more details.

I found version 1.9.0+dfsg-1 did not suffer from this crash
(and had no dependency to libunwind8).

I wondered how there the exception handling worked there and found
that e.g. _Unwind_RaiseException is supplied from libgcc_s.so.1,
while in the crashing process it is called in libunwind8.

Therefore another workaround is by forcing the load of libgcc_s.so.1
before libunwind8 by using LD_PRELOAD.

   LD_PRELOAD=/lib/aarch64-linux-gnu/libgcc_s.so.1 /usr/bin/Xtigervnc :1 
-desktop debian:1 -auth /home/benutzer/.Xauthority -geometry 1024x600 -depth 16 
-rfbwait 3 -rfbauth /home/benutzer/.vnc/passwd -rfbport 5901 -pn -localhost 
-SecurityTypes VncAuth

Before I had experimented with the git version of libunwind and
pointing LD_LIBRARY_PATH to it. This did also not crash as long as
libunwind got configured without the switch --enable-cxx-exceptions.
Without that switch the resulting library has no _Unwind_RaiseException,
therefore also the function from libgcc_s.so.1 is used.

In the end I still think libunwind8 is causing this,
but until this is fixed, tigervnc might consider dropping the
dependency at aarch64 and configure with --disable-libunwind.

Kind regards,
Bernhard

Bug#932943: Missing SHA512 and gpg signature

[Thomas Lange]

> On Sun, 4 Aug 2019 18:29:30 +0200, Bastian Blank  said:

>> In each case I expect the values to be hex strings, effectively the same
>> as the first column of the output from sha1sum, sha256sum, sha512sum,
>> etc... from coreutils.

> No, don't.  Use base64 like everyone else.
Can you explain why we should use base64? On cdimages.d.o we also use
the plain output of the shaXXXsums commands.
-- 
regards Thomas

Bug#933880: khal aborts when piping an ics file from another program, such as mutt

[Scott Barker]

Package: khal
Version: 1:0.9.10-1.1
Severity: normal

The problem is due to a test done against /dev/tty

Please consider cherry-picking https://github.com/pimutils/khal/pull/861 for 
inclusion in the Debian package, as it fixes the issue.

Thank you.

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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages khal depends on:
ii  python33.5.3-1
ii  python3-atomicwrites   1.1.5-1
ii  python3-click  6.6-1
ii  python3-configobj  5.0.6-2
ii  python3-dateutil   2.5.3-2
ii  python3-icalendar  4.0.3-2
ii  python3-pkg-resources  33.1.1-1
ii  python3-tz 2016.7-0.3
ii  python3-tzlocal1.3-1
ii  python3-urwid  1.3.1-2+b1
ii  python3-xdg0.25-4

Versions of packages khal recommends:
pn  python3-setproctitle  

Versions of packages khal suggests:
pn  khal-doc  

-- debconf-show failed

Bug#915219: ITP: python-sybil -- Automated testing for the examples in your documentation

[Andrey Rahmatullin]

Control: owner -1 !

As agreed on IRC, I'll work on this ITP. I'm almost finished already.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#933859: apt-cudf doesn't work with "apt install ./*.deb"

[Johannes Schauer]

Hi,

Quoting Simon McVittie (2019-08-04 15:38:57)
> I tried to solve 
> by configuring piuparts to be willing to take the versioned dependencies
> of the package under test from experimental, by configuring apt in the
> piuparts chroot to use apt-cudf and aspcud, but I was not successful.
> 
> Steps to reproduce outside piuparts (I used a sid VM):
> 
> * Have sid and experimental apt sources
> * sudo apt install apt-cudf aspcud
> * Have a .deb whose dependencies cannot be satisfied in sid, for example
>   gnome-shell 3.32.2-2 as of today:
>   apt-get -t experimental download gnome-shell
> * Configure aspcud resolver with the same setup as official Debian
>   experimental buildds:
>   
> ()
> 
> sudo tee /etc/apt/apt.conf.d/aspcud < APT::Solver "aspcud";
> APT::Solver::Strict-Pinning "no";
> APT::Solver::aspcud::Preferences 
> "-removed,-changed,-new,-count(solution,APT-Release:=/experimental/)";
> EOF
> 
> * sudo apt install ./gnome-shell_3.32.2-2_amd64.deb
> 
> Expected result:
> 
> apt-cudf selects gnome-shell's dependency libmutter-4-0 (and probably
> others) from experimental
> 
> Actual result:
> 
> > Fatal error: exception Common.Format822.ParseError(_, "Provides", "Field 
> > Provides has a wrong value (character 0-1: character 0-1: Unexpected token 
> > : '.'.. (vpkglist)): './gnome-shell_3.32.2-2_amd64.deb (= 3.32.2-2), 
> > polkit-1-auth-agent, notification-daemon'")
> 
> I'm not sure whether this is an apt bug (giving wrong data to apt-cudf)
> or an apt-cudf bug (not accepting valid data from apt). Any ideas?

here are some further observations.

It is not necessary to pick a package whose dependencies cannot be satisfied in
sid. This problem also happens with packages that apt can resolve just fine.

To see what the problem is, just switch the solver from "aspcud" to "dump" like
so:

APT_EDSP_DUMP_FILENAME=/tmp/out.edsp apt-get --simulate install --solver dump 
-o APT::Solver::Strict-Pinning=false ./gnome-shell_3.32.2-2_amd64.deb

Using apt's -o options it is also not necessary to write to
/etc/apt/apt.conf.d/aspcud. Using the "dump" solver is helpful because it
allows us to look into the data that apt-cudf receives from apt. In
/tmp/out.edsp we then see this:

Package: gnome-shell
Architecture: amd64
Version: 3.32.2-2
APT-ID: 781
Source: gnome-shell
Source-Version: 3.32.2-2
Priority: optional
Section: gnome
APT-Release:
 a=local-deb
 o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
APT-Pin: 500
APT-Candidate: yes
Depends: [...]
[...dependencies snipped for brevity...]
Provides: ./gnome-shell_3.32.2-2_amd64.deb (= 3.32.2-2), polkit-1-auth-agent, 
notification-daemon

Have a look at the last line. This is where apt-cudf chokes. Because what apt
chose as a package name is not a legal package name according to Debian policy
so apt-cudf throws the fatal error you see above.

I suggest that apt fixes their EDSP output. Then this will work again.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#933860: pango1.0: CVE-2019-1010238

[Simon McVittie]

https://gitlab.gnome.org/GNOME/pango/issues/342 has now been unembargoed.

On Sun, 04 Aug 2019 at 19:21:29 +0200, Salvatore Bonaccorso wrote:
> Is there some indication which upstream code change introduced
> hte issue so we can try to narrow this down?

Not as far as I can see, but I am not a Pango expert. Perhaps someone
else in the GNOME team has some insight here?

> Re the no-dsa/dsa question, the added severity does not necessarly
> imply that, actually to be on safe side I should have choosen grave
> (which then can be lowered if not appropriate). The problem was simply
> I cannot determine good enough the impact and exploiting/attack
> scenarios.
> 
> Does the upstream bug give more details which can help on that?

The upstream bug reporter writes:

[The segfault] happens because g_utf8_strlen("\xf8")
is zero, so n_chars will be zero at this point:

https://gitlab.gnome.org/GNOME/pango/blob/eb2c647ff693bf3218fd1772f11a008bfbc975e7/pango/pango-bidi-type.c#L173

But because length = 1, the loop at

https://gitlab.gnome.org/GNOME/pango/blob/eb2c647ff693bf3218fd1772f11a008bfbc975e7/pango/pango-bidi-type.c#L181
still executes at least one time, leading to a NULL pointer
dereference (g_new(.., 0) = NULL)).

In general, this issue leads to an out-of-bounds heap write and can
be triggered via pango_itemize if the bytes passed to pango_itemize
are user-controlled.

I hope that's helpful.

Sorry, I don't know enough about Pango to know whether it's reasonable
to pass malformed UTF-8 to pango_itemize(), or whether this can happen in
practice in (for example) web browsers.

smcv

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Otto Kekäläinen]

For some strange reason page https://tracker.debian.org/pkg/mariadb-10.3
still says "Updating mariadb-10.3 introduces new bugs: #910902".

Do you Sandro have any ideas why that is?

Bug#618033: AW: Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads to files not opening (x86 /32bit)

[Schnizer, Pierre]

Dear Hilmar,

Sorry I  do not know if that bug still exists.  I am not using a cifs 
mounted file system any more.

Sincerely yours
Pierre


-Ursprüngliche Nachricht-
Von: Hilmar Preuße [mailto:hill...@web.de]
Gesendet: Samstag, 3. August 2019 22:22
An: Pierre SCHNIZER 
Cc: 618...@bugs.debian.org
Betreff: Re: Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads 
to files not opening (x86 /32bit)

Am 13.03.2011 um 17:14 teilte Pierre SCHNIZER  mit:

Hi Pierre,

I'm going through some old bugs, checking for validity.

https://bugs.debian.org/618033

We did some efforts on x86 back in 2011, but later we found out that TeX Live 
is not ready for LFS support on 32bit. Is this bug still valid or has it gone 
obsolete by phasing out 32bit architecture on PC market?

Hilmar

> thank you for all the effort putting a distriubtion together.
>
> After upgrading to the lastly relased stable, I found that pdflatex
> would not find (and therefore compile) the files given on the command
> line, which were mounted by CIFS.
>
> The error occurs in the kpathsea library (texk/kpathsea/readable.c),
> where the stat fails with the errno set to EOVERFLOW. It fails because
> the offset is to large. After I added manually -D_FILE_OFFSET_BITS=64
> (following the stat 2 man page), kpathsea/pdflatex finds the file and
> compiles it happily. I added "a patch", which illustrates my hack to
> find and circumvent the problem.
>
> Could that be that AC_SYS_LARGEFILE is missing in configure.ac while
> it is listed in common.ac.orig?
>

--
sigfault
#206401 http://counter.li.org




Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta 
Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas 
Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

Bug#933879: cups: Samsung CLP315 fails after update from Stretch to Buster

[Rudolf Polzer]

Subject: cups: Samsung CLP315 fails after update from Stretch to Buster
Package: cups
Version: 2.2.10-6
Severity: normal



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.2.10-6
ii  cups-common2.2.10-6
ii  cups-core-drivers  2.2.10-6
ii  cups-daemon2.2.10-6
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.2.10-6
ii  cups-server-common 2.2.10-6
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2   2.2.10-6
ii  libcupsimage2  2.2.10-6
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.71.0-5
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4+b1
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5
ii  printer-driver-gutenprint5.3.1-7

Versions of packages cups suggests:
ii  cups-bsd   2.2.10-6
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  hplip  
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-5
pn  printer-driver-hpcups  
ii  smbclient  2:4.9.5+dfsg-5
ii  udev   241-5

-- Configuration Files:
/etc/default/cups changed:


-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true


The printer worked with Stretch.
With Buster, the printer prints the following text for any printed page:

SPL-C ERROR - please use the proper driver
  POSITION : 0x0 (0)
  SYSTEM   : src/xl_image
  LINE : 606
  VERSION  : SPL-C 5.35 11-20-2007

I have already tried within the cups web interface to change the printer 
setup and tried to delete the printer and then reassign connection and 
ppd file - but that did not make any change.


Regards
Rudolf

Bug#933878: tesseract: training files are split across libtesseract-dev and tesseract-ocr

[Julian Gilbey]

Package: libtesseract-dev
Version: 4.0.0-2
Severity: normal

Hi!

Thanks for packaging tesseract!

I was looking for the training scripts and found them in
libtesseract-dev, which doesn't quite make sense to me: they are not
library headers or include files.  (I am referring to the three
scripts in /usr/share/tesseract-ocr, namely language-specific.sh,
tesstrain.sh and tesstrain_utils.sh.)

At the same time, the training binaries are in tesseract-ocr, such as
classifier_tester, lstmtraining and so on.  Would it not make more
sense to have *only* /usr/bin/tesseract in tesseract-ocr, and all of
the other binaries, along with the shell scripts noted above, in a
separate package called something like tesseract-training?  Few people
will be interested in these training scripts, and those who are will
probably want the tesstrain.sh script as well.

Note, though, that the shell scripts tesstrain_utils.sh and
language-specific.sh) are called from tesstrain.sh using $(dirname
$0); that could be fixed by putting tesstrain.sh as /usr/bin/tesstrain
and changing the references to the subscripts to explicitly refer to
/usr/share/tesseract-ocr/.

Best wishes,

   Julian

Bug#933835: Info received (Bug#933835: libreoffice not start with fatal exception signal 11)

[sanskryt]

OK the problem was solved by today's upgrade.
In it were upgraded cpid gir1.2-atk-1.0 gpicview libarmadillo9
libatk1.0-0 libatk1.0-0:i386 libatk1.0-data libatk1.0-dev libatk1.0-doc 
liblockfile-bin liblockfile1 libreoffice-mysql-connector wget.

In effect libreoffice starts again in new version so the bug can be
closed in my humble oppinion.

sanskryt

On Sun, 2019-08-04 at 16:39 +, Debian Bug Tracking System wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian LibreOffice Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 933...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#933877: glib2.0: Suspected memory leak in jessie-lts backport of fix for CVE-2019-13012

[Simon McVittie]

Source: glib2.0
Version: 2.42.1-1+deb8u2
Severity: normal
Tags: jessie

(This is only from source code inspection, not tested in real use -
I don't use jessie any more.)

While looking into a possible stretch update for CVE-2018-16429,
CVE-2019-12450, CVE-2018-16428 and CVE-2019-13012, I compared my backports
of the fixes for those vulnerabilities with the ones in jessie-lts to try
to double-check that I had done them right.

The upstream fix for CVE-2019-13012 included this change:

- g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+ g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);

However, g_file_peek_path() was only introduced in GLib 2.56, so that
won't work for stretch or jessie. The backport in the jessie-lts package
has this instead:

- g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+ g_mkdir_with_parents (g_file_get_path (kfsb->dir), 0700);

This is not equivalent. The difference between g_file_peek_path() and the
older g_file_get_path() is that g_file_get_path() makes a copy, which must
be freed with g_free() after use. As a result, there is now a memory leak.

A non-leaky backport would look something like this, which is what I've
done in a proposed backport for Debian 9 'stretch' at
:

+ char *dir;
...
- g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+ dir = g_file_get_path (kfsb->dir);
+ g_mkdir_with_parents (dir, 0700);
+ g_free (dir);

The Ubuntu xenial update appears to have the same bug:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1838890

Regards,
smcv