Bug#933684: python-httptools: Please adjust for http-parser 2.9

2019-08-04 Thread Christoph Biedl
Control: severity 933684 serious

Christoph Biedl wrote...

> the http-parser library version 2.9 was accepted to experimental today,
> and re-building all rdeps I noticed your package will fail to build in
> the future due to a failure in the test suite.

Now that http-parser 2.9 has hit unstable, your package no longer builds
from source, raising severity accordingly.

Christoph


signature.asc
Description: PGP signature


Bug#902878: pyyaml: CVE-2017-18342: still not completely fixed

2019-08-04 Thread Scott Kitterman
On Thu, 11 Jul 2019 10:16:48 +0300 mer...@debian.org wrote:
> Hello,
> 
> According to [1] the unsafe loader yaml.UnsafeLoader is still
> vulnerable, and could be used upon request. While strictly speaking the
> vulnerability is fixed by using safe reader by default, I assume
> complete safety can only be achieved by disabling the yaml.UnsafeLoader.
> 
> Best,
> Andrius
> 
> [1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

As far as I've checked, all yaml parsers have an unsafe option.  It's 
perfectly appropriate to use on sanitized input.  It's up to the calling 
library to do it correctly.  The change requires explicit selection of a 
loader, so any program using the unsafe loader will be doing it on purpose.  
If they do it well or poorly is up to the calling program, not pyyaml.

The fixed version, 5.1.2-1 is now in sid.  I just filed 7 RC bugs for packages 
I 
found that had been using the unsafe loader, so I really think this will do 
it.

Scott K



Bug#933927: src:python-torctl: Obsolete libs, please port to python3 or remove

2019-08-04 Thread Scott Kitterman
Package: src:python-torctl
Severity: important

This package looks pretty dead upstream.  It's currently blocking me
from dropping python-geoip as part of the python2 removal effort.

Please either port it to python3 or have it removed.  If you'd prefer to
have it removed, but don't have time to deal with it, please let me know
and I'll file the rm bug.

Scott K



Bug#933928: macsyfinder: Port to Python3 needed

2019-08-04 Thread Andreas Tille
Package: macsyfinder
Severity: normal

The code needs to be ported to Python3

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages macsyfinder depends on:
ii  hmmer 3.2.1+dfsg-1
ii  libjs-jquery  3.3.1~dfsg-3
ii  libjs-underscore  1.9.1~dfsg-1
ii  ncbi-blast+   2.8.1-1
ii  python2.7.16-1

macsyfinder recommends no packages.

macsyfinder suggests no packages.



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

2019-08-04 Thread Hugo Lefeuvre
Hi Salvatore,

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

Thanks for the information. I will update the testing NMU to address these
issues as well and perform some triage in the tracker (CVE-2019-5058 is the
same as CVE-2018-3977 and CVE-2019-5057 looks familiar as well).

regards,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature


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

2019-08-04 Thread Hugo Lefeuvre
Hi Salvatore,

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

Thanks for catching this. The situation is quite messy, so I will try to
summarize it in a few words.

CVE-2018-3977 is the actual buffer overflow in IMG_pcx.c. This
vulnerabilitity was "fixed" via [0], however the fix is broken (the check
should be done for y, not ty). Talos decided to report the remaining issue
as a separate vulnerability, TALOS-2019-0842, which was recently assigned
CVE-2019-5058. It was fixed via [1].

CVE-2019-5058/TALOS-2019-0842 is not a new vulnerability, it's just
CVE-2018-3977 which wasn't fixed properly.

Buster received [0] per 2.0.4+dfsg1-1, but not [1]. Even if I was aware
that the initial patch was broken (see stretch patch descriptions), I
failed to handle this properly in the buster version.

As far as I remember, I did not upload this diff yet. I'll just provide an
updated version asap. I will also update the testing NMU[2], which I
fortunately did not upload yet.

Thanks again!

regards,
Hugo

[0] https://hg.libsdl.org/SDL_image/rev/170d7d32e4a8
[1] https://hg.libsdl.org/SDL_image/rev/b1a80aec2b10
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932755

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature


Bug#933926: RM: python-logsparser -- RoQA; Unmaintained, RC buggy, obsolete libs

2019-08-04 Thread Scott Kitterman
Package: ftp.debian.org
Severity: normal

Python2 only and blocking other python-* removals.

Scott K



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

2019-08-04 Thread Niels Thykier
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.)
> 

The tag package-does-not-use-debhelper-or-cdbs would probably benefit
from using the same logic as debian-build-system, which tries to handle
some of these cases.  As I recall the %build_systems table holds exactly
this kind of information already.

Thanks,
~Niels



Bug#932347: kalarm: Multiple akonadi_kalarm_resource processes are spawned on kalarm start and consume lot of CPU

2019-08-04 Thread Richard Elias

Hi,
Thank you for the response, after removing duplicate calendars, the KAlarm 
does not spawn multiple akonadi processes and everything works nice.


RE



Bug#933925: Misspelling in Lintian UDD table

2019-08-04 Thread Felix Lechner
Package: lintian
Severity: minor

This bug probably belongs elsewhere, but I could not find a better place.

In the Lintian table in the UDD, the 'tag_type' for overridden tags is
misspelled as 'overriden'.

udd=> select package, tag_type, tag, information from public.lintian where
tag='spelling-error-in-readme-debian' and tag_type='overriden' and
information not like '%(duplicate word)%';
 package  | tag_type  |   tag   |
information
--+---+-+--
 liblorene-dev| overriden | spelling-error-in-readme-debian | Langage
Language
 liblorene-dev| overriden | spelling-error-in-readme-debian | Langage
Language
 lorene-codes-src | overriden | spelling-error-in-readme-debian | Langage
Language
(3 rows)


Bug#932335: buster-pu: package facter/3.11.0-2+deb10u1

2019-08-04 Thread Apollon Oikonomopoulos
On 16:20 Fri 26 Jul , Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2019-07-17 18:45, Apollon Oikonomopoulos wrote:
> > I would like to update facter in Buster to fix #918250, whereby facter
> > fails to parse routes with the `onlink' flag, producing a lot of noise
> > in the process and possibly acquiring a distorted view of the network.
> > ifupdown adds the `onlink' flag to gateway routes by default, so this
> > tends to affect a lot of systems.
> > 
> > The issue has been fixed upstream, and backporting the fix is trivial —
> > in fact I have already uploaded a fixed version in unstable. Full source
> > debdiff against buster attached.
> 
> Please go ahead; thanks.
> 
> Regards,

Uploaded, thanks!

Apollon



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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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()

2019-08-04 Thread 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()

2019-08-04 Thread 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()

2019-08-04 Thread 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()

2019-08-04 Thread 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()

2019-08-04 Thread 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()

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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: 818

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

2019-08-04 Thread 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

2019-08-04 Thread 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 = fal

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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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 # Attem

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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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&kfreebsd from
the main archive.

Samuel



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

2019-08-04 Thread 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

2019-08-04 Thread 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)

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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.

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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?

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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)

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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?

2019-08-04 Thread 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?

2019-08-04 Thread 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

2019-08-04 Thread 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)

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread ProtonMail
Your Proton verification code is:
957968

Bug#932943: Missing SHA512 and gpg signature

2019-08-04 Thread 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

2019-08-04 Thread 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

2019-08-04 Thread 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)

2019-08-04 Thread 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)

2019-08-04 Thread 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

2019-08-04 Thread 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)

2019-08-04 Thread 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?

2019-08-04 Thread 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

2019-08-04 Thread 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



  1   2   3   >