Bug#944675: udev: Keyboard and mouse not working in X.org with udev 243-5

2019-11-16 Thread Peter Habcak

> Is the problem reproducible after the reboot or only directly after the
> upgrade?

Actually, everything was working fine after upgrade until reboot (I did 
reboot one day after upgrade). After reboot, the problem became visible 
(and it was not solved by many other reboots).


--
Peter



Bug#938464: send2trash: diff for NMU version 1.5.0-1.1

2019-11-16 Thread Julian Gilbey
On Sat, Nov 16, 2019 at 07:27:37PM -0500, Sandro Tosi wrote:
> Control: tags 938464 + patch
> Control: tags 938464 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for send2trash (versioned as 1.5.0-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Dear Sandro,

Thanks for preparing this patch.

But please delete this NMU from the upload queue and unmark the bug as
pending.  It is not appropriate at this time, as this is not a leaf
package.  This bug is blocked by bug #936775.  Once jupyter-notebook
is made python3-only, then I will upload a python3-only version of
send2trash.

Best wishes,

   Julian



Bug#888569: sysv startup script stumbles over smtpd running in a LXC container

2019-11-16 Thread Harald Dunkel

I'd love to help maintaining this package. Since this bug
is a show stopper for me I am running my own opensmtpd
package anyway. Not to mention it that I am using opensmtp
on OpenBSD, too.

Regards
Harri



Bug#944886: Please enable CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT

2019-11-16 Thread Michal Čihař
Package: src:linux
Version: 5.3.9-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have notebook with the digital microphone (DMIC) of Intel audio
controller [8086:9dc8] and to make that work,
CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT is needed (and some additional
firmware). Can you please enable that in the Debian kernel?

See kernel bugzilla for more info:
https://bugzilla.kernel.org/show_bug.cgi?id=201251

Thanks
- -- 
Michal Čihař | https://cihar.com/ | https://weblate.org/


- -- Package-specific info:
** Version:
Linux version 5.3.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-2 (2019-11-12)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-2-amd64 root=/dev/mapper/nutt--vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20QDS05900
product_version: ThinkPad X1 Carbon 7th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2HET40W (1.23 )
board_vendor: LENOVO
board_name: 20QDS05900
board_version: Not Defined

** Loaded modules:
i2c_dev
uinput
cdc_mbim
cdc_wdm
cdc_ncm
usbnet
mii
cdc_acm
acpi_call(OE)
msr
fuse
ctr
ccm
rfcomm
cmac
nf_tables
nfnetlink
bnep
btusb
btrtl
btbcm
btintel
bluetooth
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
drbg
videodev
ansi_cprng
ecdh_generic
mc
ecc
sof_pci_dev
snd_sof_intel_hda_common
snd_sof_intel_hda
snd_sof_intel_byt
snd_sof_intel_ipc
snd_sof
snd_sof_xtensa_dsp
snd_soc_skl
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_skl_ipc
snd_soc_sst_ipc
snd_hda_codec_hdmi
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
intel_rapl_msr
snd_soc_core
snd_hda_codec_realtek
x86_pkg_temp_thermal
intel_powerclamp
snd_hda_codec_generic
coretemp
snd_compress
kvm_intel
nls_ascii
snd_hda_intel
nls_cp437
kvm
irqbypass
intel_cstate
iwlmvm
snd_hda_codec
vfat
intel_uncore
efi_pstore
tpm_crb
mac80211
fat
intel_rapl_perf
snd_hda_core
pcspkr
libarc4
snd_hwdep
serio_raw
iTCO_wdt
efivars
snd_pcm
ucsi_acpi
mei_me
tpm_tis
iTCO_vendor_support
processor_thermal_device
iwlwifi
watchdog
mei
intel_wmi_thunderbolt
snd_timer
typec_ucsi
tpm_tis_core
intel_rapl_common
wmi_bmof
cfg80211
intel_soc_dts_iosf
thinkpad_acpi
intel_pch_thermal
tpm
typec
rng_core
nvram
ac
ledtrig_audio
snd
soundcore
rfkill
int3403_thermal
battery
int340x_thermal_zone
evdev
int3400_thermal
acpi_tad
acpi_thermal_rel
acpi_pad
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
i915
i2c_algo_bit
drm_kms_helper
aesni_intel
xhci_pci
xhci_hcd
e1000e
aes_x86_64
drm
crypto_simd
psmouse
usbcore
nvme
ptp
pps_core
thunderbolt
cryptd
i2c_i801
glue_helper
nvme_core
usb_common
wmi
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Coffee Lake HOST and DRAM 
Controller [8086:3e34] (rev 0c)
Subsystem: Lenovo Coffee Lake HOST and DRAM Controller [17aa:2292]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 
(Whiskey Lake) [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo UHD Graphics 620 (Whiskey Lake) [17aa:2292]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
Subsystem: Lenovo Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor 
Thermal Subsystem [17aa:2292]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
Subsystem: Lenovo Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core 
Processor Gaussian Mixture Model [17aa:2292]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Point-LP 
Thermal Controller [8086:9df9] (rev 11)

Bug#944885: Errors on initial use

2019-11-16 Thread 積丹尼 Dan Jacobson
Package: grass
Version: 7.8.1-1
Severity: minor

$ grass

GRASS 7.8.1 (newLocation):~ > Traceback (most recent call last):
  File "/usr/lib/grass78/scripts/g.extension", line 141, in 
from distutils.dir_util import copy_tree
ModuleNotFoundError: No module named 'distutils.dir_util'

(wxgui.py:3995): Gtk-CRITICAL **: 07:30:41.995: gtk_box_gadget_distribute: 
assertion 'size >= 0' failed in GtkScrollbar



Bug#936604: FYI: Python 3 migration of distributuion

2019-11-16 Thread Osamu Aoki
Hi,

On Wed, Nov 13, 2019 at 11:11:43AM -0600, Charles Cazabon wrote:
> Osamu Aoki  wrote:
> >
> > Currently, getmail is a candidate for removal from the upcoming Debian
> > release if it is not updated to support python 3 by someone (not
> > necessary by upstream).
>
> Thanks for the update, Osamu.  I have actually been playing with a prototype
> refactoring of getmail to not just support but require a recent Python 3.x
> version.  Such a project would give me the opportunity to remove a lot of
> historical cruft and backwards-compatibility code that getmail has accumulated
> over 20+ years.

That's great.  (I thought you rejected idea to move to 3.0.)

I tried to do it around getmail 5.5 days.  (I didn't finish it)

> Unfortunately, it's difficult to find the hours to devote to this task.  I
> don't know when, or even if, I could have a beta release ready.
>
> > If you convert python 2 code for 2.7 style, then we can support both
> > python 2 and 3.
>
> I'm not very interested in doing this, as it means not using a lot of 3.x
> features, or not using them in the most Pythonic way.  My thought was that
> this project would target at least Python 3.7; anyone who didn't want to run
> 3.7 could still run "legacy" getmail under Python 2.7.

I understand.  When I tried to convert this to Python3, the first thing
I did was clean out all backward compatibility codes, too.  It is too
much work to keep them.

Also if it is Python3 only, we don't need to add things like:

from __future__ import division
 from future import standard_library

If you have a public git repository, maybe some Debian developer may
help you.  If you want, I can set up one at salsa.debian.org (or
github.com) where ever you are comfortable.

At least, if we have a place to share work in progress, we don't
duplicate efforts.


Osamu



Bug#944884: [python-django-modelcluster]

2019-11-16 Thread agus said
Package: python-django-modelcluster
Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing
Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@da279c7
Severity: 
Tags: 
X-Debbugs-CC: 
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

* What led up to the situation?
* What exactly did you do (or not do) that was effective (orineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

*** End of the template - remove these lines ***


Bug#944414: no way to unbind keys

2019-11-16 Thread 積丹尼 Dan Jacobson
In https://github.com/bbidulock/icewm/issues/398#issuecomment-554676714
he says there is no way to unbind keys.



Bug#935772: libbsd0: lacks strnvisx

2019-11-16 Thread Guillem Jover
Hi!

On Mon, 2019-08-26 at 02:39:32 +, brian m. carlson wrote:
> Package: libbsd0
> Version: 0.10.0-1
> Severity: normal

> libbsd0 seems to have several of the vis(3) functions and documents
> strnvisx(3), but it isn't in the shared library:
> 
>   $ nm -D /usr/lib/x86_64-linux-gnu/libbsd.so.0 | grep strnvisx
> 
> This can easily be worked around by using strsnvisx(3) with an empty
> extra string, but since the function is documented, it probably makes
> sense to include it.

The function is actually included in the shared library, but it was
masked due to not being listed in the version script. I've fixed this
locally and will be included in the next upstream release, probably
tomorrow.

Thanks,
Guillem



Bug#937103: nagios-plugins-contrib: Python2 removal in sid/bullseye

2019-11-16 Thread Sandro Tosi
On Fri, 30 Aug 2019 07:27:38 + Matthias Klose  wrote:
> Package: src:nagios-plugins-contrib
> Version: 24.20190301
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

nagios-plugins-contrib is virtually the only rdep for python-pymongo,
and it looks like the code from the last update already supports
python3: could you change check_mongodb/check_mongodb.py shebang to
point to py3k and update the recommends to python3-pymongo? this way
we could drop the py2 support from src:pymongo. there's a percona
mongo check too, but tbh it hasnt been updated in 5 years upstream,
and python-pymongo is only a suggests there, so maybe we can ignore
it?

other checks depending on python2:

* check_graphite/check_graphite.py
  - very old check (upstream last change 8years ago)
  - does it even work anymore?
  - seems trivial to port to python3, a quick `2to3` reveals just some
very basic changes
* check_libs_ng/check_libs_ng
  - this looks almost ready to get its shebang switched to py3k, small
`2to3` fix to apply
* percona-nagios-plugins/nagios/bin/pmp-check-aws-rds.py
  - really old script, should be verified if it still works properly
  - `2to3` suggests really basic changes, maybe let's apply them?

please let me know what you think about this, definitely prioritizing
dropping python-pymongo would help a lot; i can help
preparing/committing the changes, but i wont be able to test them out
myself in real-world examples.

Regards,
Sandro



Bug#944083: libbsd-dev: Lacks user_from_uid() & uid_from_user() functions

2019-11-16 Thread Guillem Jover
Hi!

On Sun, 2019-11-03 at 23:37:39 +0100, Robert Luberda wrote:
> Package: libbsd-dev
> Version: 0.10.0-1
> Severity: wishlist

> I'm trying to prepare new version of bsd-mailx package from the OpenBSD
> repository, but it unfortunatelly fails to compile because they switched
> to using to user_from_uid() and uid_from_user(), see the links below.
>  Would it be possible to provide the functions in the libbsd package?

Yes! I've had these in my TODO list for a while. I've now merged them
locally and will be included in the next upstream release, perhaps
tomorrow or so.

Thanks,
Guillem



Bug#944883: Syntax error on Math::Complex man page

2019-11-16 Thread 積丹尼 Dan Jacobson
Package: perl-doc
Version: 5.30.0-9
Severity: minor
File: /usr/share/man/man3/Math::Complex.3perl.gz

   $j = ((root(1, 3))[1];

is a syntax error.



Bug#944621: RFS: logrotate/3.15.1-2 -- Log rotation utility

2019-11-16 Thread Adam Borowski
On Tue, Nov 12, 2019 at 08:40:52PM +0100, Christian Göttsche wrote:
>  * Package name: logrotate
>Version : 3.15.1-2

> Changes since the last upload:
> 
>* d/control: drop postgresql-common break
>* d/copyright: update for 2019
>* d/salsa-ci.yml: add standard salsa-ci configuration
>* d/tests: add additional small test script
>* d/patches: add testsuite patches to pass reprotest on salsa-ci
>* d/patches: tighten systemd service hardening
>* d/control: bump to std version 4.4.1 (no further changes)
>* d/source/lintian-overrides: ignore package-does-not-install-examples

Hi!
Thanks for maintaining such a vital package.

Alas, this upload, while it builds successfully for me, fails one of
autopkgtests:

autopkgtest [05:22:32]: test custom-run: [---
== run #1
Potentially dangerous mode on config: 0664
error: Ignoring config because it is writable by group or others.
Reading state from file: state
Allocating hash table for state file, size 64 entries
Creating new state

Handling 0 logs
Removing /tmp/autopkgtest.ZQUE0K/build.BFe/src/test.log from state file, 
because it does not exist and has not been rotated for one year
== checking test.log
== checking test.log.1
autopkgtest [05:22:33]: test custom-run: ---]
autopkgtest [05:22:33]: test custom-run:  - - - - - - - - - - results - - - - - 
- - - - -
custom-run   FAIL non-zero exit status 1


Full log attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl

+==+
| logrotate 3.15.1-2 (amd64)   Sun, 17 Nov 2019 04:22:03 + |
+==+

Package: logrotate
Version: 3.15.1-2
Source Version: 3.15.1-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-da072dba-dc6f-4111-8cd6-b41e4d597ece'
 with '<>'
I: NOTICE: Log filtering will replace 'build/logrotate-x0ZKSa/resolver-6hQIsn' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/kilobyte/tmp/pkg/logrotate_3.15.1-2.dsc exists in /home/kilobyte/tmp/pkg; 
copying to chroot
I: NOTICE: Log filtering will replace 'build/logrotate-x0ZKSa/logrotate-3.15.1' 
with '<>'
I: NOTICE: Log filtering will replace 'build/logrotate-x0ZKSa' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: libpopt-dev, debhelper-compat (= 12), libselinux1-dev, 
libacl1-dev, build-essential, fakeroot
Filtered Build-Depends: libpopt-dev, debhelper-compat (= 12), libselinux1-dev, 
libacl1-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [401 B]
Get:5 copy:/<>/apt_archive ./ Packages [475 B]
Fetched 1833 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libacl1-dev libattr1-dev libpcre2-16-0 libpcre2-32-0 libpcre2-dev
  libpcre2-posix0 libpopt-dev libpopt0 libselinux1-dev libsepol1-dev
The following NEW packages will be installed:
  libacl1-dev libattr1-dev libpcre2-16-0 libpcre2-32-0 libpcre2-dev
  

Bug#944357:

2019-11-16 Thread Emmanuel Arias
Hi,

I prepare a new upstream release on salsa repo [1]

I will need help to upload :D

cc: uploader

[1] https://salsa.debian.org/python-team/modules/python-elasticsearch


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com



Bug#944860: udevadm trigger fails in chroot

2019-11-16 Thread Michael Biebl
Control: retitle -1 udevadm trigger fails in containers with ro /sys

Am 17.11.19 um 02:43 schrieb Michael Biebl:
> Am 17.11.19 um 01:57 schrieb Jonah Brüchert:
>> After slightly looking into the debos source code it seems also possible
>> that it uses a systemd-spawn container in some cases
>> (https://github.com/go-debos/debos/blob/2764eed783b1b0ffb5d09f796338f09a4e2594b6/commands.go#L15)
> 
> Can you please verify, what exactly you are using:
> A container (systemd-nspawn,...), chroot or something else.
> If it's a chroot, it would be good to know how the chroot is setup,
> (e.g. which file systems are mounted into the chroot etc).

Assuming you do actually use systemd-nspawn, I think I found the commit
which changed the behaviour of udevadm:

> commit 97afc0351a96e0daa83964df33937967c75c644f (refs/bisect/bad)
> Author: Zbigniew J<99>drzejewski-Szmek 
> Date:   Wed Jun 5 09:54:54 2019 +0200
> 
> udevadm trigger: log errors and return first failure
> 
> When udevadm trigger is called, the list of devices to trigger is always
> generated through enumeration, and devices can come and go, so we should 
> not
> treat -ENOENT as a failure. But other types of failure should be logged.
> It seems they were logged until baa30fbc2c04b23209d0b8fb3c86cd15ef9ea81a.
> 
> Also, return the first error. (I'm not sure if there are other failure 
> modes
> which we want to ignore. If they are, they'll need to be whitelisted like
> -ENOENT.).

https://github.com/systemd/systemd/commit/97afc0351a96e0daa83964df33937967c75c644f

Whereas with v242 it would log only with debug level priority and return
0, with v243 it now logs with error level priority and returns 1.

I assume this change was deliberate.

This is unfortunate as we have quite a few packages calling "udevadm
trigger" in postinst [1].

So, I think "udevadm trigger" actually behaves properly in a chroot as
it becomes a nop there. In a container with a ro /sys it now fails.
I just checked and LXC containers are affected as well.

Retitling the bug report accordingly.



[1] https://codesearch.debian.net/search?q=udevadm+trigger=0
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#944812: interimap: uninitialized value

2019-11-16 Thread Guilhem Moulin
Control: severity -1 minor

On Sat, 16 Nov 2019 at 23:35:31 +0100, Jonas Smedegaard wrote:
> I guess you mean this:
> […]
> * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ()) 

> jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk 'doveadm -f flow fetch "uid 
> modseq flags" mailbox INBOX.olpc' | grep -w 97
> uid=97 modseq=1 flags=

Yup, sorry for the lack of clarity and thanks for reading between the
lines.  I'm lowering the severity of this bug to ‘minor’ now, because
AFAICT it's cosmetic at worst.

The above is consistent with the rest of this report, even though I
don't get why you receive a response with UID 97 when the FETCH command
spans over all UIDs, but not when limited to said UID.  Sounds like a
server issue to me, but I'd need to double check RFC 3501 to be sure.

We've already seen that FETCHing the BODY of UID 97 produces no
response.  Does it help to add “INTERNALDATE BODY.PEEK[]” to the
fetch-attr list?  I.e., replace the UID FETCH command with

b UID FETCH 1:* (MODSEQ FLAGS INTERNALDATE BODY.PEEK[])

That was the command used in the initial sync (the one producing the
warning about uninitialized value value).  If my theory is correct, the
response will be something like

* 3396 FETCH (UID 97 MODSEQ (1) FLAGS () … BODY[] NIL)

(That IMAP command will produce a lot of output on large mailboxes; you
might want to grep remotely if your connection to the server is slow or
unreliable.)  Or using doveadm:

$ doveadm -f flow fetch "uid modseq flags text" mailbox INBOX.olpc | grep 
-iE "(^| )uid=97( |$)"

Perhaps it's enough to dump UIDs 90 to 100 than the entire mailbox, I
don't know.  Hopefully your mailbox is not so large that dumping its
content DoS'es the server :-P

If these command do produce an untagged FETCh output, you could try to
add the GUID to the fetch-attr list (with doveadm and/or in the IMAP
session) to see if that message points anywhere at all.

b UID FETCH 1:* (MODSEQ X-GUID FLAGS INTERNALDATE BODY.PEEK[])

and

$ doveadm -f flow fetch "uid modseq guid flags text" mailbox INBOX.olpc | 
grep -iE "(^| )uid=97( |$)"

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#937536: pyside2: Python2 removal in sid/bullseye

2019-11-16 Thread Sandro Tosi
On Fri, 30 Aug 2019 07:35:29 + Matthias Klose  wrote:
> Package: src:pyside2
> Version: 5.11.2-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

version 5.13.2-1 changelog says "Remove almost all of Python 2 binary
packages" but i dont see any python2 packages left in pyside2: can we
close this bug then?



Bug#944765: duplicity: Python 3 SyntaxWarnings during package configuration

2019-11-16 Thread Alexander Zangerl
On Thu, 14 Nov 2019 23:51:03 +0100, Axel Beckert writes:
>Upgrading duplicity today threw the follwing SyntaxWarnings for me:

thanks for the note.

>Setting up duplicity (0.8.05-3) ...
>/usr/lib/python3/dist-packages/duplicity/selection.py:213: SyntaxWarning: "is" 
>with a literal. Did you mean "=="?
>  if result is 2:

this one will be fixed in the next uploadd of duplicity later today.

>Setting up python3-tasklib (1.2.1-2) ...
...

these need to be raised against the python3-tasklib package, not duplicity.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Recht:
 internet-freier Raum. -- Hartmut Pilch


signature.asc
Description: Digital Signature


Bug#916107: mongodb: MongoDB should not be part of a stable release

2019-11-16 Thread Sandro Tosi
On Mon, 10 Dec 2018 11:01:11 +0200 Apollon Oikonomopoulos
 wrote:
> Source: mongodb
> Version: 1:3.4.15-1
> Severity: serious
> Justification: Cannot be properly supported
>
> MongoDB should not be part of (at least) Buster for the following
> reasons:
>
>  - MongoDB 3.4 will be EOL by June 2019[1], which is way too soon for it
>to be included in Buster.
>
>  - MongoDB 3.6 and 4.0 will be supported longer, but upstream's switch
>to SSPLv1 complicates matters. As discussed in #915537, we will not
>be distributing any SSPL-licensed software, and keeping the last
>AGPL-licensed version (3.6.8 or 4.0.3) without the ability to
>cherry-pick upstream fixes is not a viable option. (I am currently
>not considering distributing mongodb in non-free.)
>
> I will not request removal immediately, to allow other packages time to
> adjust their dependencies, but eventually auto-removal will kick in.
>
> That said, MongoDB 3.4 will probably remain in sid for as long as it is
> AGPL-licensed and supported upstream.

is there a future for mongodb in Debian?

i'm looking it from the python2 removal side of things, and mongodb is
the last r-dep of python-mongodb. as this package is already RC buggy,
i may just go ahead and remove that package, that will make mongodb
unittest to fail.

but on a broader spectrum, how long do you want to keep this package
in debian, which is practically un-upgradable, with all the issue that
means?

Thanks,
Sandro



Bug#944860: udevadm trigger fails in chroot

2019-11-16 Thread Michael Biebl
Am 17.11.19 um 01:57 schrieb Jonah Brüchert:
> After slightly looking into the debos source code it seems also possible
> that it uses a systemd-spawn container in some cases
> (https://github.com/go-debos/debos/blob/2764eed783b1b0ffb5d09f796338f09a4e2594b6/commands.go#L15)

Can you please verify, what exactly you are using:
A container (systemd-nspawn,...), chroot or something else.
If it's a chroot, it would be good to know how the chroot is setup,
(e.g. which file systems are mounted into the chroot etc).

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#944860: udevadm trigger fails in chroot

2019-11-16 Thread Michael Biebl
Am 17.11.19 um 01:57 schrieb Jonah Brüchert:
> Thanks for looking into the issue.
> 
>> Can you be more specific how you setup your chroot so we have a chance
>> to reproduce the problem?

[..]

I guess you'll need to break that down to a more minimal test case for
me being able to reproduce the issue.

That said, udevadm trigger uses running_in_chroot()

https://github.com/systemd/systemd/blob/master/src/udev/udevadm-trigger.c#L177

That function has not changed between v242 and v243:
https://github.com/systemd/systemd/blob/master/src/basic/virt.c#L629

int running_in_chroot(void) {
int r;

if (getenv_bool("SYSTEMD_IGNORE_CHROOT") > 0)
return 0;

r = files_same("/proc/1/root", "/", 0);
if (r < 0)
return r;

return r == 0;
}



Is it possible that something in your test environment has actually
changed which now triggers the failure?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#943903: [Pkg-samba-maint] Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

2019-11-16 Thread Marvin Renich
Thanks for looking into this.

* Mathieu Parent  [191116 16:12]:
> Le jeu. 31 oct. 2019 à 17:03, Marvin Renich  a écrit :
> >
> > Package: samba
> > Version: 2:4.11.1+dfsg-1
> > Severity: normal
> >
> > After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
> > machine, mount.cifs from cifs-utils 2:6.9-1
> > on a different machine fails to connect with "mount error(13): Permission 
> > denied".  Subsequently upgrading samba to
> > 2:4.11.1+dfsg-1 did not help.
> 
> What is the kernel version on the client side?

$ uname -a
Linux basil 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 GNU/Linux

> 
> Try to force the CIFS version with vers= in the mount options.

At the time, I tried 1.0, 2.0, 2.1, 3.0, and 3.

If I remember correctly, 1.0 gave me a different error message, but
still failed to mount.  3.0 (I think) and 3 gave the error above.  I
don't remember which error I got for 2.[01], but it was one of the two.

If it would be useful, early next week I can try temporarily upgrading
samba on the server and running mount on the client with the --verbose
option.  If there is anything else I should try at that time, let me
know.

If it makes any difference (I don't think so), the version of samba on
my client is 2:4.11.1+dfsg-2, and  mount.cifs works correctly with the
older version of samba on the server.

...Marvin



Bug#944882: diffoscope: please (at least) include hint in html that text version has no max report size

2019-11-16 Thread Holger Levsen
Package: diffoscope
Version: 1.30
Severity: minor

Dear diffoscope maintainers,

(some aspects of) the current behavior of diffoscope and 'max report size' is
as:

- only considered for html output, but not for text (where it is unlimited),
  default is 400kb max.

I'd like to suggest:

- increase the default max to 1024kb or maybe 2mb? (actually, why not
  more? why a limited default?)
- include a hint in the html output that the text output is not limited
  in size. (if html hits the max. not sure if once or at every truncated
  occasion.)


Thanks for your considerations & all the shiny code!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature


Bug#944860: udevadm trigger fails in chroot

2019-11-16 Thread Jonah Brüchert

Thanks for looking into the issue.


Can you be more specific how you setup your chroot so we have a chance
to reproduce the problem?


The exact setup is a little more complicated.

The chroot is created using debos, which if I remember correctly uses a
chroot inside qemu if that's relevent.

The exact command is `./bin/debos-docker -t variant:plasma-mobile
halium.yml`, ran inside the following git repository:
https://gitlab.com/debian-pm/tools/rootfs-builder-debos.

Whether debos-docker or a normal debos package / binary is used should
not matter, since the build process always happens inside a virtual machine.

After slightly looking into the debos source code it seems also possible
that it uses a systemd-spawn container in some cases
(https://github.com/go-debos/debos/blob/2764eed783b1b0ffb5d09f796338f09a4e2594b6/commands.go#L15)

The ci log can be found here in case useful:
https://travis-ci.com/debian-pm-tools/rootfs-builder-debos/jobs/257249532#L7353.


As reduced test case the following debos recipe could be used to save
some time:

`debos testcase.yml --debug-shell`


testcase.yml:

```

architecture: amd64

actions:
  - action: debootstrap
    suite: unstable
    components:
  - main
    mirror: https://deb.debian.org/debian
    variant: minbase

  - action: apt
    packages: [ udisks2 ]

```



Bug#936914: libsass-python: diff for NMU version 0.17.0-1.1

2019-11-16 Thread Sandro Tosi
Control: tags 936914 + patch
Control: tags 936914 + pending


Dear maintainer,

I've prepared an NMU for libsass-python (versioned as 0.17.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru libsass-python-0.17.0/debian/changelog libsass-python-0.17.0/debian/changelog
--- libsass-python-0.17.0/debian/changelog	2019-01-11 06:28:55.0 -0500
+++ libsass-python-0.17.0/debian/changelog	2019-11-16 19:43:31.0 -0500
@@ -1,3 +1,10 @@
+libsass-python (0.17.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936914
+
+ -- Sandro Tosi   Sat, 16 Nov 2019 19:43:31 -0500
+
 libsass-python (0.17.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru libsass-python-0.17.0/debian/control libsass-python-0.17.0/debian/control
--- libsass-python-0.17.0/debian/control	2019-01-11 06:28:55.0 -0500
+++ libsass-python-0.17.0/debian/control	2019-11-16 19:41:23.0 -0500
@@ -4,30 +4,19 @@
 Priority: optional
 Build-Depends: debhelper (>= 12~),
  dh-python,
- python-all-dev, python3-all-dev,
- python-setuptools, python3-setuptools,
- python-six, python3-six,
- python-sphinx, python3-sphinx,
- python-werkzeug, python3-werkzeug,
- python-flake8, python3-flake8,
- python-pytest, python3-pytest,
+ python3-all-dev,
+ python3-setuptools,
+ python3-six,
+ python3-sphinx,
+ python3-werkzeug,
+ python3-flake8,
+ python3-pytest,
  libsass-dev (>= 3.5.4)
 Standards-Version: 4.3.0
 Homepage: https://hongminhee.org/libsass-python/
 Vcs-Git: https://salsa.debian.org/debian/libsass-python.git
 Vcs-Browser: https://salsa.debian.org/debian/libsass-python
 
-Package: python-libsass
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Description: SASS for Python: a straightforward binding of libsass for Python
- This package provides a simple Python extension module sass which is binding
- Libsass (written in C/C++ by Hampton Catlin and Aaron Leung). It's very
- straightforward and there isn't any headache related Python
- distribution/deployment.
- That means you can add just libsass into your setup.py's install_requires list
- or requirements.txt file. Need no Ruby nor Node.js.
-
 Package: python3-libsass
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
@@ -42,7 +31,7 @@
 Package: pysassc
 Section: web
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, python-libsass, python3-libsass
+Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, python3-libsass
 Description: SASS for Python: command line utility for libsass
  This package provides a simple Python script to access libsass
  functionnalities.
diff -Nru libsass-python-0.17.0/debian/python-libsass.install libsass-python-0.17.0/debian/python-libsass.install
--- libsass-python-0.17.0/debian/python-libsass.install	2019-01-11 06:28:55.0 -0500
+++ libsass-python-0.17.0/debian/python-libsass.install	1969-12-31 19:00:00.0 -0500
@@ -1,4 +0,0 @@
-usr/lib/python2*/*-packages/*.py
-usr/lib/python2*/*-packages/_sass*.so
-usr/lib/python2*/*-packages/*.egg-info/ 
-usr/lib/python2*/*-packages/sassutils/ 
diff -Nru libsass-python-0.17.0/debian/rules libsass-python-0.17.0/debian/rules
--- libsass-python-0.17.0/debian/rules	2019-01-11 06:28:55.0 -0500
+++ libsass-python-0.17.0/debian/rules	2019-11-16 19:42:58.0 -0500
@@ -6,10 +6,10 @@
 export SYSTEM_SASS = 1
 %:
 	dpkg-query -f '${Version}\n' -W libsass-dev|sed 's/-.*//' > .libsass-upstream-version
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_build:
-	pybuild --build -p "$(shell pyversions -vr; py3versions -vr)"
+	pybuild --build -p "$(shell py3versions -vr)"
 	# build doc once
 	pybuild -s custom --build -p $(shell py3versions -vd) \
 		--build-args="env PYTHONPATH={build_dir} python3 -m sphinx -N -bman docs/ build/man"
@@ -22,7 +22,7 @@
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-	pybuild -s custom --test -p "$(shell pyversions -vr; py3versions -vr)" \
+	pybuild -s custom --test -p "$(shell py3versions -vr)" \
 		--test-args="cp -fr test testpkg {build_dir}/; \
 		{interpreter} setup.py bdist_egg --dist-dir {build_dir}/testpkg/.eggs; \
 		cd {build_dir}; {interpreter} -m unittest sasstests"


Bug#938047: python-prometheus-client: diff for NMU version 0.7.1-1.1

2019-11-16 Thread Sandro Tosi
Control: tags 938047 + patch
Control: tags 938047 + pending


Dear maintainer,

I've prepared an NMU for python-prometheus-client (versioned as 0.7.1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-prometheus-client-0.7.1/debian/changelog python-prometheus-client-0.7.1/debian/changelog
--- python-prometheus-client-0.7.1/debian/changelog	2019-11-07 07:24:12.0 -0500
+++ python-prometheus-client-0.7.1/debian/changelog	2019-11-16 19:29:30.0 -0500
@@ -1,3 +1,10 @@
+python-prometheus-client (0.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * drop python2 support; Closes: #938047
+
+ -- Sandro Tosi   Sat, 16 Nov 2019 19:29:30 -0500
+
 python-prometheus-client (0.7.1-1) unstable; urgency=medium
 
   [ Martina Ferrari ]
diff -Nru python-prometheus-client-0.7.1/debian/control python-prometheus-client-0.7.1/debian/control
--- python-prometheus-client-0.7.1/debian/control	2019-11-07 07:24:12.0 -0500
+++ python-prometheus-client-0.7.1/debian/control	2019-11-16 19:29:12.0 -0500
@@ -6,11 +6,6 @@
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
 Build-Depends-Indep: dh-python,
- python-all,
- python-concurrent.futures,
- python-decorator (>= 4.0.10),
- python-pytest,
- python-setuptools,
  python3-all,
  python3-decorator (>= 4.0.10),
  python3-pytest,
@@ -20,27 +15,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-prometheus-client.git
 Homepage: https://github.com/prometheus/client_python
 
-Package: python-prometheus-client
-Architecture: all
-Depends: python-decorator (>= 4.0.10-1),
- ${misc:Depends},
- ${python:Depends},
-Description: Python 2 client for the Prometheus monitoring system
- This library provides an API for exporting metrics from a Python application.
- It provides classes for the metric types, and an HTTP server to expose the
- metrics to Prometheus.
- .
- When using Linux, the process CPU, RAM, file descriptor usage and start time
- will also be exported.
- .
- Along with the HTTP server to expose metrics, you can also write the metrics
- to a text file to be exported by the prometheus-node-exporter, or push them to
- the prometheus-pushgateway.
- .
- This library also includes support for re-exporting Graphite metrics to
- Prometheus, custom collectors to proxy metrics for other systems and a parser
- for the Prometheus text format.
-
 Package: python3-prometheus-client
 Architecture: all
 Depends: python3-decorator (>= 4.0.10-1),
diff -Nru python-prometheus-client-0.7.1/debian/python-prometheus-client.docs python-prometheus-client-0.7.1/debian/python-prometheus-client.docs
--- python-prometheus-client-0.7.1/debian/python-prometheus-client.docs	2019-11-07 07:24:12.0 -0500
+++ python-prometheus-client-0.7.1/debian/python-prometheus-client.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.md
diff -Nru python-prometheus-client-0.7.1/debian/rules python-prometheus-client-0.7.1/debian/rules
--- python-prometheus-client-0.7.1/debian/rules	2019-11-07 07:24:12.0 -0500
+++ python-prometheus-client-0.7.1/debian/rules	2019-11-16 19:29:19.0 -0500
@@ -8,7 +8,7 @@
 export https_proxy=
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean


Bug#943705: dh_installman: man-recode integration gets confused if both foo.1 and foo.1.gz exist

2019-11-16 Thread Santiago Vila
severity 943705 serious
affects 943705 src:bppphyview
affects 943705 src:bppsuite
affects 943705 src:collectl
affects 943705 src:curseofwar
affects 943705 src:edbrowse
affects 943705 src:horst
affects 943705 src:ipmiutil
affects 943705 src:librep
affects 943705 src:multipath-tools
affects 943705 src:pcal
affects 943705 src:sawfish
affects 943705 src:sciteproj
affects 943705 src:sloccount
affects 943705 src:sslh
affects 943705 src:wput
affects 943705 src:x2goclient
affects 943705 src:xca
thanks

On Mon, 28 Oct 2019, Colin Watson wrote:

>   dh_installman: mv debian/rumur/usr/share/man/man1/rumur.1.dh-new 
> debian/rumur/usr/share/man/man1/rumur.1: No such file or directory
>   dh_installman: Aborting due to earlier error

I've detected this "dh-new" pattern in a lot of other packages, for
example, this one:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/collectl_4.3.1-1.rbuild.log.gz

I'm raising this to serious because it breaks many other packages.
However, if the old behaviour will not come back, then please say so,
so that individual bugs can be filed instead.

Thanks.



Bug#938464: send2trash: diff for NMU version 1.5.0-1.1

2019-11-16 Thread Sandro Tosi
Control: tags 938464 + patch
Control: tags 938464 + pending


Dear maintainer,

I've prepared an NMU for send2trash (versioned as 1.5.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru send2trash-1.5.0/debian/changelog send2trash-1.5.0/debian/changelog
--- send2trash-1.5.0/debian/changelog	2019-02-14 15:34:58.0 -0500
+++ send2trash-1.5.0/debian/changelog	2019-11-16 19:23:08.0 -0500
@@ -1,3 +1,10 @@
+send2trash (1.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938464
+
+ -- Sandro Tosi   Sat, 16 Nov 2019 19:23:08 -0500
+
 send2trash (1.5.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru send2trash-1.5.0/debian/control send2trash-1.5.0/debian/control
--- send2trash-1.5.0/debian/control	2019-02-14 15:34:58.0 -0500
+++ send2trash-1.5.0/debian/control	2019-11-16 19:22:55.0 -0500
@@ -2,7 +2,7 @@
 Section: python
 Priority: optional
 Maintainer: Julian Gilbey 
-Build-Depends: debhelper (>= 11), dh-python, python-all, python-setuptools,
+Build-Depends: debhelper (>= 11), dh-python,
   python3-all, python3-setuptools
 Standards-Version: 4.3.0
 Homepage: https://github.com/hsoft/send2trash
@@ -10,17 +10,6 @@
 Vcs-Git: https://salsa.debian.org/debian/send2trash.git
 Testsuite: autopkgtest-pkg-python
 
-Package: python-send2trash
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Recommends: python-gi
-Description: Python module for sending file to trash natively
- This module sends a file to the trash using either the Glib system
- for handling a desktop trash file or its own home-grown system if
- python-gi is not installed.
- .
- This package installs the library for Python 2.
-
 Package: python3-send2trash
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru send2trash-1.5.0/debian/rules send2trash-1.5.0/debian/rules
--- send2trash-1.5.0/debian/rules	2019-02-14 15:34:58.0 -0500
+++ send2trash-1.5.0/debian/rules	2019-11-16 19:23:04.0 -0500
@@ -7,4 +7,4 @@
 export PYBUILD_DISABLE=test
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#919659: Your mail

2019-11-16 Thread Andreas Steinel
On Mon, 5 Aug 2019 01:28:58 +0530 Kunal Nagar  wrote:
> 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.

I just faced the same issue and monkey-patched it in my Dockerfile at build
time:

RUN sed -i '1161s%umount%#umount%' /usr/share/debootstrap/functions


Bug#943585: kwin-x11: kwin (?) causes extreme flickering and tear on login

2019-11-16 Thread Brendon Higgins
A followup: Just noticed I had a file in xorg.conf.d called 20-
intel.conf. Not sure where this file came from (it's quite possible I 
made it myself when trying to debug something since forgotten) and 
it seemed more-or-less empty; it's entire contents are:
Section "Device"
Identifier  "card0"
Driver  "intel"
#Option  "AccelMethod"  "uxa"
EndSection

Given those contents, I would've presumed there'd be no difference to 
the default settings. Yet if I remove that file from xorg.conf.d, the 
graphical issues that I was experiencing in kwin_x11 are gone!

Stefan, I don't suppose you might have something similar going on 
with your system?

Peace,
Brendon

On Sunday, October 27, 2019 12:06:25 P.M. EST Brendon Higgins 
wrote:
> Hi,
> 
> I've encountered similar behaviour: black/residual/flickering 
windows
> making the desktop unusable after login. I also noticed some minor 
(white)
> flickering in SDDM prior to login, although it was still quite usable at
> that point. I'm running a mixed testing/unstable system, and am 
also using
> an Intel display chip (Dell Latitude; only on-board, no discrete 
graphics
> chip).
> 
> I found disabling OpenGL compositing with ALT+SHIFT+F12 worked 
around
> it at first, as did downgrading KDE+QT packages back to testing. I'm 
just
> trying this now with unstable packages again, and running the 
suggestsed
> 'DRI_PRIME=1 kwin_x11 --replace'also seems to work - even as the 
new
> kwin_x11 instance brings OpenGL compositing back with it.
> 
> Peace,
> Brendon
> 
> On Sun, 27 Oct 2019 01:15:10 +0200 Stefan Schwarzer
> 
>  wrote:
> > Package: kwin-x11
> > Version: 4:5.14.5-1+b1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > I am following debian unstable, desktop X11/sddm/kde on a 
Lenovo laptop
> 
> T460p.
> 
> > The nvidia graphics on the laptop is disabled in favor of the chipset
> 
> graphics
> 
> > (Intel).
> > 
> > After the last upgrade (which was from testing to stable on the 
25th
> 
> October),
> 
> > I am experiencing a mostly unusable desktop. The login screen 
(sddm)
> 
> comes up
> 
> > as expected,
> > but right after login I get flickering black rectangles on the screen,
> > which may
> > cover up to 90% of its area. Windows mostly remain black or their 
content
> > suddenly
> > becomes visible he task bar remains black and I see other 
residuals of the
> 
> kde
> 
> > splash
> > screen where windows should be drawn or the background 
wallpaper be
> > restored. Swithing to a VT; all seems ok, kwin, the desktop and
> > applications are
> > running.
> > 
> > So far, my only clue as to what may be going on is a workaroud: if I 
start
> > a terminal
> > via keyboard shortcut and issue blindly
> > 
> > DRI_PRIME=1 kwin_x11 --replace
> > 
> > then afterwards things behave mostly normally (Sometimes 
window
> 
> contaent is
> 
> > still
> > not correctly updated). I just picked this line up from older bug 
reports
> > against kwin on the net without understanding what it does.
> > 
> > This is the output of kwin following this command in the hope that 
it
> > helps
> > 
> > OpenGL vendor string:   Intel Open Source Technology
> > Center
> > OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 
530
> > (Skylake GT2)
> > OpenGL version string:  4.5 (Core Profile) Mesa 19.2.1
> > OpenGL shading language version string: 4.50
> > Driver: Intel
> > GPU class:  Unknown
> > OpenGL version: 4.5
> > GLSL version:   4.50
> > Mesa version:   19.2.1
> > X server version:   1.20.4
> > Linux kernel version:   5.3
> > Requires strict binding:yes
> > GLSL shaders:   yes
> > Texture NPOT support:   yes
> > Virtual Machine:no
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> > 
> >   APT prefers unstable
> >   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 
> 'experimental')
> 
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386



Bug#944812: interimap: uninitialized value

2019-11-16 Thread Jonas Smedegaard
Quoting Guilhem Moulin (2019-11-16 22:00:24)
> On Sat, 16 Nov 2019 at 20:47:53 +0100, Jonas Smedegaard wrote:
> > Doesn't seem succesful (I creatively prepended "a EXAMINE INBOX.olpc", 
> > hope that is correct):
> 
> Yup, sorry for the incomplete commands ;-)
>  
> > a UID FETCH 97 MODSEQ
> > * OK [HIGHESTMODSEQ 17] Highest
> > a OK Fetch completed (0.001 + 0.000 secs).
> > b UID FETCH 97 FLAGS
> > b OK Fetch completed (0.001 + 0.000 secs).
> > c UID FETCH 97 INTERNALDATE
> > c OK Fetch completed (0.001 + 0.000 secs).
> > d UID FETCH 97 BODY.PEEK[]
> > d OK Fetch completed (0.001 + 0.000 secs).
> > e UID FETCH 97 ENVELOPE
> > e OK Fetch completed (0.001 + 0.000 secs).
> 
> OK, at least that is consistent with a lack of response for ‘UID FETCH
> 97 ($FETCH_ATTRS)’, but doesn't explain why that UID shows up when
> trying to repair.  In your debug log we see
> 
> | remote(INBOX.olpc): S: * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
> 
> AFAICT that untagged FETCH response comes from an ‘UID FETCH 1:* (MODSEQ
> FLAGS)’ (most likely prefixed with ‘C: 03’ in the debug log).  Could
> you try that command manually and double check that the same untagged
> line appears?  We can then narrow it down from there.
> 
> S: * PREAUTH [CAPABILITY …]
> C: a EXAMINE INBOX.olpc
> S: […]
> S: a OK [READ-ONLY] Examine completed
> C: b UID FETCH 1:* (MODSEQ FLAGS)
> S: […]
> S: b OK Fetch completed
> 
> (I don't need the full server response, just the line containig “UID
> 97”.

I guess you mean this:

jonas@auryn:~$ printf 'a EXAMINE INBOX.olpc\nb UID FETCH 1:* (MODSEQ FLAGS)\n' 
| ssh jonas-deb...@xayide.jones.dk "doveadm exec imap" | grep -w 97
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
imap(jonas-debian): Error: net_connect_unix() failed: Connection refused
* 97 FETCH (UID 3467 MODSEQ (2) FLAGS ())
* 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
imap(jonas-debian)<8014>: Info: Connection closed (UID 
FETCH finished 0.032 secs ago) in=52 out=201833 deleted=0 expunged=0 trashed=0 
hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0


>  Hopefully doveadm-fetch(1) agrees with that ouput as well:
> 
> doveadm -f flow fetch "uid modseq flags" mailbox INBOX.olpc

Not sure what you mean should match there.  This, perhaps?:

jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk 'doveadm -f flow fetch "uid 
modseq flags" mailbox INBOX.olpc' | grep -w 97
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
uid=97 modseq=1 flags=


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

2019-11-16 Thread gregor herrmann
On Sat, 16 Nov 2019 18:58:12 +0100, Holger Levsen wrote:

> > Additionally see the discussion in #747320, where Jakub Wilk does point
> > out that maintainer scripts may assume /usr is mounted, so I'm not sure
> > about this.
> how is it relevant if /usr is mounted? if its not, both 'which' and '-v' can
> fail...

`command' is a shell builtin (at least for dash, bash, zsh).

(Interestingly `which' seems to be a shell builtin in zsh; but not in
bash or dash where /usr/bin/which is used.)

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Donovan: Remember the Alamo


signature.asc
Description: Digital Signature


Bug#943903: [Pkg-samba-maint] Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

2019-11-16 Thread Mathieu Parent
Le jeu. 31 oct. 2019 à 17:03, Marvin Renich  a écrit :
>
> Package: samba
> Version: 2:4.11.1+dfsg-1
> Severity: normal
>
> I plan to clone this bug to cifs-utils, as it is unclear which package has 
> the bug.
>
> After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
> machine, mount.cifs from cifs-utils 2:6.9-1
> on a different machine fails to connect with "mount error(13): Permission 
> denied".  Subsequently upgrading samba to
> 2:4.11.1+dfsg-1 did not help.
>
> Downgrading samba to stable 2:4.9.5+dfsg-5+deb10u1 on the server fixes the 
> problem.  Adding a snapshot version to figure
> out what needed to be downgraded to get version 2:4.9.13+dfsg-1 was deemed 
> not worth the effort, as my daily backup on
> the client machine (which mounts the remote cifs share) was running fine when 
> the server had 2:4.9.13+dfsg-1.

What is the kernel version on the client side?

Try to force the CIFS version with vers= in the mount options.

> vers=arg
>   SMB protocol version. Allowed values are:
>
>   • 1.0 - The classic CIFS/SMBv1 protocol.
>
>   • 2.0  -  The  SMBv2.002 protocol. This was initially introduced in Windows 
> Vista Service Pack 1, and Windows Server 2008. Note that
> the initial release version of Windows Vista spoke a slightly different 
> dialect (2.000) that is not supported.
>
>   • 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and 
> Windows Server 2008R2.
>
>   • 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and 
> Windows Server 2012.
>
>   • 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft 
> Windows Server 2016.
>
>   Note too that while this option governs the protocol version used, not all 
> features of each version are available.
>
>   The default since v4.13.5 is for the client and server to negotiate the 
> highest possible version greater than or equal  to  2.1.  In
>   kernels prior to v4.13, the default was 1.0. For kernels between v4.13 and 
> v4.13.5 the default is 3.0.


Ref: https://manpages.debian.org/buster/cifs-utils/mount.cifs.8.en.html

Regards

-- 
Mathieu Parent



Bug#944881: kup-backup: please enable parallel building

2019-11-16 Thread Pino Toscano
Source: kup-backup
Version: 0.7.1+dfsg-1
Severity: wishlist
Tags: patch

Hi,

kup-backup seems to build fine with multiple build jobs when building.
Thus, my suggestion is to enable the parallel build (with the
--parallel option of dh) to speed up the compilation when requested
(see also Policy §4.9.1).

(An alternative is to bump the debhelper compatibility to >= 10,
however that requires checking for other changes due to the
compatibility bump.)

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh $@
+   dh $@ --parallel
 
 override_dh_auto_configure:
dh_auto_configure -- \


Bug#944812: interimap: uninitialized value

2019-11-16 Thread Guilhem Moulin
On Sat, 16 Nov 2019 at 20:47:53 +0100, Jonas Smedegaard wrote:
> Doesn't seem succesful (I creatively prepended "a EXAMINE INBOX.olpc", 
> hope that is correct):

Yup, sorry for the incomplete commands ;-)
 
> a UID FETCH 97 MODSEQ
> * OK [HIGHESTMODSEQ 17] Highest
> a OK Fetch completed (0.001 + 0.000 secs).
> b UID FETCH 97 FLAGS
> b OK Fetch completed (0.001 + 0.000 secs).
> c UID FETCH 97 INTERNALDATE
> c OK Fetch completed (0.001 + 0.000 secs).
> d UID FETCH 97 BODY.PEEK[]
> d OK Fetch completed (0.001 + 0.000 secs).
> e UID FETCH 97 ENVELOPE
> e OK Fetch completed (0.001 + 0.000 secs).

OK, at least that is consistent with a lack of response for ‘UID FETCH
97 ($FETCH_ATTRS)’, but doesn't explain why that UID shows up when
trying to repair.  In your debug log we see

| remote(INBOX.olpc): S: * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())

AFAICT that untagged FETCH response comes from an ‘UID FETCH 1:* (MODSEQ
FLAGS)’ (most likely prefixed with ‘C: 03’ in the debug log).  Could
you try that command manually and double check that the same untagged
line appears?  We can then narrow it down from there.

S: * PREAUTH [CAPABILITY …]
C: a EXAMINE INBOX.olpc
S: […]
S: a OK [READ-ONLY] Examine completed
C: b UID FETCH 1:* (MODSEQ FLAGS)
S: […]
S: b OK Fetch completed

(I don't need the full server response, just the line containig “UID
97”.  Hopefully doveadm-fetch(1) agrees with that ouput as well:

doveadm -f flow fetch "uid modseq flags" mailbox INBOX.olpc

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#935166: Re-instate Debian-9's remote CUPS queue naming model

2019-11-16 Thread Brian Potkin
On Tue 20 Aug 2019 at 10:58:46 +, Mike Gabriel wrote:

> Package: cups
> 
> on a Debian Edu setup that got upgraded from Debian 8 to Debian 10, I
> noticed today that remote CUPS queue naming is completely unusable on
> networks where different printer queues share the same driver (name).
> 
> I propose the following change to Debian's default cups-browsed.conf:
> 
> ```
> root@disklserver:/# diff -u /etc/cups/cups-browsed.conf.orig
> /etc/cups/cups-browsed.conf
> --- /etc/cups/cups-browsed.conf.orig  2019-08-20 12:53:43.619548720 +0200
> +++ /etc/cups/cups-browsed.conf   2019-08-20 12:53:48.687534966 +0200
> @@ -384,7 +384,7 @@
> 
>  # LocalQueueNamingRemoteCUPS DNS-SD
>  # LocalQueueNamingRemoteCUPS MakeModel
> -# LocalQueueNamingRemoteCUPS RemoteName
> +LocalQueueNamingRemoteCUPS RemoteName
>  # LocalQueueNamingIPPPrinter DNS-SD
>  # LocalQueueNamingIPPPrinter MakeModel
> ```
> 
> With this change (it should hit Debian buster, finally, IMHO), the queue
> naming style of remote CUPS queues gets changed back from
> 
>   DNS-SD style: _
> 
> to
> 
>   RemoteName style: 
> 
> Please consider enforcing this configuration default on Debian system's.
> Upstream's default is not really usable on big networks with many printers.

Thanks for your report, Mike. 

Please say what the LibreOffice print dialog shows you with

 * The default Debian installation.
 * The default Debian installation but cups-browsed is stopped.
 * LocalQueueNamingRemoteCUPS RemoteName is uncommented and cups-browsed
   is running.

On unstable would be good.

Cheers,

Brian.



Bug#944630: jumpnbump-levels: suggestions for an update of the packaging

2019-11-16 Thread Fabian Greffrath
Am Mittwoch, den 13.11.2019, 00:50 +0100 schrieb Nicolas Boulenguez:
> I can submit a merge request instead of a patch if you prefer.

Yes, please do so. Updating the entire debian/ directory with a single
patch is cumbersome if the packaging is already managed in GIT.

Thanks!

 - Fabian



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


Bug#941907: transition: ocaml

2019-11-16 Thread Paul Gevers
Hi,

On 14-11-2019 16:50, Paul Gevers wrote:
> Let's see where we are when all ages are fine.

I'm failing to (quickly) see why ocaml doesn't want to migrate. Does
anybody already have some foo laying around to see what the problem is?
I'm only seeing ocaml in the autohinter section, while I expected in the
regular section.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#944879: libmatemixer FTCBFS: fails building documentation

2019-11-16 Thread Helmut Grohne
Source: libmatemixer
Version: 1.22.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libmatemixer fails to cross build from source, because it fails building
the documentation with an Exec format error. This is common when using
gtk-doc. Fortunately, the documentation is split to an arch:all package,
so we can skip building it in an arch-only build and doing so makes a
cross build succeed. Please consider applying it.

Helmut
diff --minimal -Nru libmatemixer-1.22.0/debian/changelog 
libmatemixer-1.22.0/debian/changelog
--- libmatemixer-1.22.0/debian/changelog2019-07-10 13:37:35.0 
+0200
+++ libmatemixer-1.22.0/debian/changelog2019-11-16 20:46:04.0 
+0100
@@ -1,3 +1,10 @@
+libmatemixer (1.22.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: --disable-gtk-doc for arch-only builds. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 16 Nov 2019 20:46:04 +0100
+
 libmatemixer (1.22.0-1) unstable; urgency=medium
 
   [ Martin Wimpress ]
diff --minimal -Nru libmatemixer-1.22.0/debian/rules 
libmatemixer-1.22.0/debian/rules
--- libmatemixer-1.22.0/debian/rules2019-07-10 13:37:35.0 +0200
+++ libmatemixer-1.22.0/debian/rules2019-11-16 20:46:03.0 +0100
@@ -22,7 +22,7 @@
 override_dh_auto_configure:
NOCONFIGURE=1 ./autogen.sh
dh_auto_configure $(DHFLAGS) -- \
-   --enable-gtk-doc \
+   --$(if $(filter %-doc,$(shell 
dh_listpackages)),en,dis)able-gtk-doc \
--disable-static \
--disable-silent-rules \
$(NULL)


Bug#944812: interimap: uninitialized value

2019-11-16 Thread Jonas Smedegaard
Quoting Guilhem Moulin (2019-11-16 20:24:48)
> On Sat, 16 Nov 2019 at 18:19:37 +0100, Jonas Smedegaard wrote:
> > Seems I didn't get the expected response.  So does that indicate 
> > broken data at the server?
> 
> Not sure yet, but I'm leaning towards that conclusion.  What if you 
> query the attributes one at a time, does any of these IMAP commands 
> produce an untagged FETCH response?
> 
> a UID FETCH 97 MODSEQ
> b UID FETCH 97 FLAGS
> c UID FETCH 97 INTERNALDATE
> d UID FETCH 97 BODY.PEEK[]
> e UID FETCH 97 ENVELOPE

Doesn't seem succesful (I creatively prepended "a EXAMINE INBOX.olpc", 
hope that is correct):

jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk "doveadm exec imap"
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
imap(jonas-debian): Error: net_connect_unix() failed: Connection refused
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND 
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED 
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 
LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in as 
jonas-debian
a EXAMINE INBOX.olpc
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 4304 EXISTS
* 0 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1225292233] UIDs valid
* OK [UIDNEXT 12584] Predicted next UID
* OK [HIGHESTMODSEQ 17] Highest
a OK [READ-ONLY] Examine completed (0.002 + 0.000 + 0.001 secs).
a UID FETCH 97 MODSEQ
* OK [HIGHESTMODSEQ 17] Highest
a OK Fetch completed (0.001 + 0.000 secs).
b UID FETCH 97 FLAGS
b OK Fetch completed (0.001 + 0.000 secs).
c UID FETCH 97 INTERNALDATE
c OK Fetch completed (0.001 + 0.000 secs).
d UID FETCH 97 BODY.PEEK[]
d OK Fetch completed (0.001 + 0.000 secs).
e UID FETCH 97 ENVELOPE
e OK Fetch completed (0.001 + 0.000 secs).


> Do you have access to the server log?  If so, is there something
> appearing upon ‘b UID FETCH 97 BODY.PEEK[]’?

Nope.  Only notices about the manually-typing sessions taking
suspicously long.


> You could also try to dump the message using doveadm-fetch(1):
> 
> doveadm fetch text mailbox INBOX.olpc uid 97

jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk "doveadm fetch text mailbox 
INBOX.olpc uid 97"
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
doveadm(jonas-debian): Error: fetch(text) failed for box=INBOX.olpc uid=97: 
Message was expunged


> Or even look directly into the maildir (‘x UID FETCH 97 X-GUID’ should
> tell you the file name holding that message).

Again I prepended "x UID FETCH 97 X-GUID":

jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk "doveadm exec imap"
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
imap(jonas-debian): Error: net_connect_unix() failed: Connection refused
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND 
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED 
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 
LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in as 
jonas-debian
a EXAMINE INBOX.olpc
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 4304 EXISTS
* 0 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1225292233] UIDs valid
* OK [UIDNEXT 12584] Predicted next UID
* OK [HIGHESTMODSEQ 17] Highest
a OK [READ-ONLY] Examine completed (0.001 + 0.000 secs).
x UID FETCH 97 X-GUID
x OK Fetch completed (0.001 + 0.000 secs).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#944878: O: palabos

2019-11-16 Thread Anton Gladky
Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On behalf of Debian Science Team I intend to orphan palabos package.

The package description is:

 CFD solver based on the lattice Boltzmann method. Development files
 A software tool for classical CFD, particle-based models and complex physical
 interaction, Palabos offers a powerful environment for your fluid flow
 simulations.

Currently, the package has no active uploader listed in the corresponding
field in d/control. After the call [1] no interest was identified in the
team.

[1] https://lists.debian.org/debian-science/2019/09/msg00018.html

Regards

Anton


-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl3QUNkRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYmLg//bXLN3pgb8YR0QrHxBw7kZfed7HfKfu7S
0ipv2cWeU+lghai8H1LfI4qWVOnHolLam2HHUXlmMcdp+ULHPgoF3917QDczKtNI
AyuGGW53dWKCZgw1vwDGeppeQEOwguH7Kb9wQOo3F8H2MT5vlerdMG8zw6B7W6NJ
+0zxlHy+goYo3V8P4fnyKTx+4gBj/6hO3kwouLzmRs/OW3KZn9msv8i5PTv+qn2Q
vf80rw0uNkkJ00nZkyh+UNwu7qz+mbX9OiYMXtGQIQBkimKwBH2t00PNXKjnemj2
44bMfaV7uzjbMccX23/Dy4p0dRY1xgKnuJRguDiz/rkJKzP2PNXaSL4B5WnfHX0k
n/Xcp1OOT5uJhMg2wBhm1189OupjK3X436P6OgYi0M3Nq2xrgp+XWrpISd5XWQsG
IvQw/H4PCxZcbkVq5Yxda38y14Pc4pa94IYltoOa2jLUzseWoP0XqERNWHVOHVXz
LTzctq9dlwC0YqwAQznqTfD5I8u45LL2apGau4rMarY/O0JMBtssgiDZUtvrWR3V
yEmzBWpMfn23xTHlyQHD4dSScywgG5VEqflFkJOD0VucoJjjJJdsTjtJnmj5nOU+
EnFU7fdWwKjWGf7lwj56sTHa7tHpT4nWfIQP/yUtkIYp9+93MrpJXTIzg4PRWfNL
DBQusnXaOsA=
=gg6J
-END PGP SIGNATURE-



Bug#944877: non-ascii, non-printable byte in jquery.min.js

2019-11-16 Thread JCF Ploemen
Package: libjs-jquery
Severity: normal
Control: found -1 3.2.1-1
Control: found -1 3.3.1~dfsg-3

A recent bug filed against sabnzbdplus [1], a python program using
cherrypy to serve its web interface that in turn uses jquery, reported
the following error upon accessing the web interface:
"UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position
8593: ordinal not in range(128)". The bug only triggered in case the
program was executed in a non-unicode environment.

The origin of that problematic byte turned out to be the minified
jquery from the libjs-jquery package. Both the non-minified code [2]
and upstream's minified file use the notation "\uFFFD" for this byte;
only in Debian's jquery.min.js it ends up as 0xef.

I understand why Debian chooses to build the minified version itself
rather than ship the one supplied with upstream releases, but doing so
shouldn't introduce unnecessary regressions. Please fix the minifying
process to retain the ascii notation for the likes of "\uFFFD".


[1] https://github.com/sabnzbd/sabnzbd/issues/1335
[2] 
https://salsa.debian.org/js-team/jquery/blob/77bef356e3b7385e22d52dd2103f6225eb6012f0/external/sizzle/dist/sizzle.js#L161


pgpip0Bu6BPQc.pgp
Description: OpenPGP digital signature


Bug#944812: interimap: uninitialized value

2019-11-16 Thread Guilhem Moulin
On Sat, 16 Nov 2019 at 18:19:37 +0100, Jonas Smedegaard wrote:
> Quoting Guilhem Moulin (2019-11-16 17:50:14)
>> On Sat, 16 Nov 2019 at 16:25:15 +0100, Jonas Smedegaard wrote:
>>> jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 | 
>>> grep -Fw 97
>>> […]
>>> local(INBOX.olpc): WARNING: No match for modified remote UID 97. 
>>> Downloading again.
>>> remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
>>> BODY.PEEK[] ENVELOPE)
>> 
>> I'm suprised grep didn't match the server response for that command.
> 
> Perhaps if you talking about matching the originally reported warning, 
> then beware that the warning mesage initially reported happened only 
> while initially syncronizing that mailbox from scratch.  I am unable to 
> repeat that exact warning message - but instead the warning message 
> above is now repeatable for me.

Gotcha

> Nope:
> […]
> remote(INBOX.olpc): S: * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
> […]
> remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
> BODY.PEEK[] ENVELOPE)
> remote(INBOX.olpc): S: 04 OK Fetch completed (0.001 + 0.000 secs).

I'm puzzled by that sequence, the response at the top indicates the
presence of a message (at position #3396) with UID 97, mod-sequence 1,
and empty flag list.  But the server doesn't appear to provide any
response when BODY[] in is the list of attributes to FETCH.  (That would
be fine if there was no message with that UID, but since you can
reproduce it doesn't seem to be the case here.)

> a EXAMINE INBOX.olpc
> […]
> b UID FETCH 97 BODY.PEEK[]
> b OK Fetch completed (0.001 + 0.000 secs).
 
> Seems I didn't get the expected response.  So does that indicate broken 
> data at the server?

Not sure yet, but I'm leaning towards that conclusion.  What if you
query the attributes one at a time, does any of these IMAP commands
produce an untagged FETCH response?

a UID FETCH 97 MODSEQ
b UID FETCH 97 FLAGS
c UID FETCH 97 INTERNALDATE
d UID FETCH 97 BODY.PEEK[]
e UID FETCH 97 ENVELOPE

Do you have access to the server log?  If so, is there something
appearing upon ‘b UID FETCH 97 BODY.PEEK[]’?

You could also try to dump the message using doveadm-fetch(1):

doveadm fetch text mailbox INBOX.olpc uid 97

Or even look directly into the maildir (‘x UID FETCH 97 X-GUID’ should
tell you the file name holding that message).

>> I appreciate the assistance in debugging.  Thanks!
> 
> I am having fun :-)

^^

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]

2019-11-16 Thread Fabian Wolff
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: bba...@mit.edu

Dear mentors,

I am looking for a sponsor for an upload of the 'boogie' package.

My changes are summarized in the latest changelog entry:

  boogie (2.4.1-0.1) unstable; urgency=medium

* Non-maintainer upload.
* New upstream release.
* Update debian/watch file.
* Update debian/copyright.
* Change Priority to optional in debian/control.
* Upgrade to debhelper compat level 12.
* Update build dependencies (Closes: #927171).
* Upgrade to Standards-Version 4.4.1.
* Fix debian/rules to make the new version build.
* Enable autopkgtest package testing, and add mccarthy-{91,92} tests.
* Update Vcs-Git and Vcs-Browser fields in debian/control.

   -- Fabian Wolff   Sat, 16 Nov 2019 19:16:48 +0100

The current maintainer is looking for someone to adopt the package (#903142)
and has not made any attempt to keep the package in shape even after it had
been removed from testing, so I don't think he will object to this NMU. But
I have added him in the X-Debbugs-CC header just to be sure.

The Git repository that the Vcs-Git and Vcs-Browser fields point to does not
exist yet, but I've already sent a request on debian-mentors for someone to
create it for me and give me access to it. Once this has happened, I will
push my changes there; in the meantime, the package can be found here:

  https://salsa.debian.org/wolff-guest/boogie

And also on Mentors:

  https://mentors.debian.net/package/boogie

Thank you for your help!

Best regards,
Fabian



Bug#944874: strange phenomenon with primus + nvidia-tesla

2019-11-16 Thread Andreas Beckmann
Source: nvidia-graphics-drivers-tesla
Version: 418.87.01-1
Severity: important
Control: submitter -1 patrice.dur...@igh.cnrs.fr

 Forwarded Message 
Subject: strange phenomenon  with primus +  nvidia-tesla
Date: Fri, 15 Nov 2019 21:23:40 +
From: Patrice DUROUX 
To: pkg-nvidia-de...@alioth-lists.debian.net 


Hi,

Since version 418.88 of nvidia was removed from Debian, my laptop device that
is:
01:00.0 VGA compatible controller: NVIDIA Corporation GK208GLM [Quadro K610M] 
(rev a1)
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev ff)
was no more supported anymore neither by the 390xx nor by the new 430xx.
So I decided to remove entirely all the stack primus nvidia to be back with 
nouveau
(but impossible to use primus tech with it, may be unsupported for this device).

Recently nvidia-tesla was pushed into experimental, so I am trying to setup
again primus + nvidia. Starting from a fresh boot of Debian Sid without any
related packages (to nvidia + primus) and then installing nvidia-tesla + primus,
I am able to get 'optirun glxgears -info' work fine (after some manual
adjustment moreover like setting glx alternative correctly).

But then after a reboot, it is no more working. Here is the log message:
[   56.224448] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 241
[   56.224824] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=none,decodes=none:owns=none
[   56.224847] NVRM: The NVIDIA GPU :01:00.0
   NVRM: (PCI ID: 10de:12b9) installed in this system has
   NVRM: fallen off the bus and is not responding to commands.
[   56.224890] nvidia: probe of :01:00.0 failed with error -1
[   56.224906] NVRM: The NVIDIA probe routine failed for 1 device(s).
[   56.224907] NVRM: None of the NVIDIA graphics adapters were initialized!
[   56.250709] nvidia-nvlink: Unregistered the Nvlink Core, major device number 
241

Should it be possible that there are some bad interactions with the hda hdmi
audio driver that the kernel driver tries to setup?

nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: Unable to sync 
register 0x4f0100. -5
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid 
ELD buf size -1
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid 
ELD buf size -1
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid 
ELD buf size -1
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: out of range 
cmd 0:4:707:
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: out of range 
cmd 0:4:707:ffbf
nov. 15 21:50:40 hp-dark kernel: snd_hda_codec_hdmi hdaudioC1D0: out of range 
cmd 0:4:707:

I am currently able to reproduce this on my system. Removing everything,
rebooting, then install again the necessary packages, the adjusting a bit the
config and get it work with optirun. But then after a reboot I am loosing this
ability again.

Don't know how to help?

Thanks,
Patrice

 Forwarded Message 
Subject: re: strange phenomenon with primus + nvidia-tesla
Date: Sat, 16 Nov 2019 15:22:37 +0100
From: Patrice Duroux 
To: pkg-nvidia-de...@alioth-lists.debian.net 



More progress on the trouble, now 'optirun glxgears' is working even after some
reboots (not clear why unless an update in sid since yesterday). But now here is
what I am getting looking at journalctl each time closing the glxgears X11
window:

nov. 16 15:07:09 hp-dark systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
nov. 16 15:07:09 hp-dark systemd[1]: Started Process Core Dump (PID 3612/UID 0).
nov. 16 15:07:10 hp-dark kernel: nvidia-modeset: Unloading
nov. 16 15:07:10 hp-dark kernel: nvidia-nvlink: Unregistered the Nvlink Core, 
major device number 241
nov. 16 15:07:10 hp-dark kernel: bbswitch: disabling discrete graphics
nov. 16 15:07:10 hp-dark kernel: pci :01:00.0: Refused to change power 
state, currently in D0
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129532] [ERROR][XORG] (EE)
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129551] [ERROR][XORG] (EE) 
Backtrace:
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129556] [ERROR][XORG] (EE) 0: 
/usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x556c1ac5d2c9]
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129561] [ERROR][XORG] (EE) 1: 
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f7885c6355f]
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129565] [ERROR][XORG] (EE) 2: 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.418.87.01 (_nv015glcore+0x141a0) 
[0>
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129569] [ERROR][XORG] (EE) 3: 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.418.87.01 (_nv015glcore+0x1437e) 
[0>
nov. 16 15:07:10 hp-dark bumblebeed[707]: [  231.129574] [ERROR][XORG] (EE) 4: 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 (glXCreateNewContext+0x9c18) 
[0x7f788>
nov. 16 15:07:10 hp-dark bumblebeed[707]: 

Bug#944875: calibre: ebook-convert to pdf aborts due to missing objects in QWebEngineProfile

2019-11-16 Thread rush
Package: calibre
Version: 4.3.0+dfsg-2
Severity: normal

Dear Maintainer,

ebook-convert package aborts every time I'm trying to convert file to pdf 
format.

Abort message looks this way: 

   <..prior conversion log..>
   68% Parsed all content for markup transformation
   70% Completed markup transformation
   WebEngineContext used before QtWebEngine::initialize() or OpenGL context 
creation failed.
   Traceback (most recent call last):
 File "/usr/bin/ebook-convert", line 20, in 
   sys.exit(main())
 File "/usr/lib/calibre/calibre/ebooks/conversion/cli.py", line 401, in main
   plumber.run()
 File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line 1275, 
in run
   self.opts, self.log)
 File "/usr/lib/calibre/calibre/ebooks/conversion/plugins/pdf_output.py", 
line 176, in convert
   self.convert_text(oeb_book)
 File "/usr/lib/calibre/calibre/ebooks/conversion/plugins/pdf_output.py", 
line 243, in convert_text
   log=self.log, cover_data=self.cover_data, 
report_progress=self.report_progress
 File "/usr/lib/calibre/calibre/ebooks/pdf/html_writer.py", line 1139, in 
convert
   manager = RenderManager(opts, log, container.root)
 File "/usr/lib/calibre/calibre/ebooks/pdf/html_writer.py", line 250, in 
__init__
   ans.setUrlRequestInterceptor(self.interceptor)
   AttributeError: 'QWebEngineProfile' object has no attribute 
'setUrlRequestInterceptor' 

If I simply comment out line 250 in html_writer.py, there is no abort and 
conversion passes without issues and produces expected pdf file. Everything 
works.

I see there is a similar issue reported to upstream, but bug was declined as 
they do not support calibre which comes from debian package.
Details are here: https://bugs.launchpad.net/calibre/+bug/1850835

Probably there was a new version for python-pyqt which we don't have yet in 
debian, but I didn't figure that out.

Could you please have a look?

--
Regards, Rushan.


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

Kernel: Linux 5.2.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  4.3.0+dfsg-2
ii  dpkg 1.19.7
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python-apsw  3.29.0-r1-2
ii  python-bs4   4.8.0-2
ii  python-chardet   3.0.4-4
ii  python-cherrypy3 8.9.1-5
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.1.0-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.12-1
ii  python-feedparser5.2.1-1
ii  python-html2text 2019.8.11-1
ii  python-html5-parser  0.4.9-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.4.1-1
ii  python-markdown  3.1.1-2
ii  python-mechanize 1:0.4.3-2
ii  python-msgpack   0.5.6-2
ii  python-netifaces 0.10.4-1+b2
ii  python-pil   6.2.1-2+b1
ii  python-pkg-resources 41.4.0-1
ii  python-pyparsing 2.4.2-1
ii  python-pyqt5 5.12.3+dfsg-3
ii  python-pyqt5.qtsvg   5.12.3+dfsg-3
ii  python-pyqt5.qtwebengine 5.12.1-4+b1
ii  python-regex 0.1.20190207-1+b2
ii  python-routes2.4.1-1
ii  python2.72.7.17-1
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python-unrardll  

-- no debconf information



Bug#944675: udev: Keyboard and mouse not working in X.org with udev 243-5

2019-11-16 Thread Michael Biebl
For everyone affected by this issue, can you please answer this question:

Did you reboot after the upgrade?
Is the problem reproducible after the reboot or only directly after the
upgrade?



signature.asc
Description: OpenPGP digital signature


Bug#891634: cupsd uses 100% a few seconds after startup

2019-11-16 Thread Brian Potkin
tages 891634 moreinfo
thanks


On Tue 27 Feb 2018 at 16:15:33 +0100, Attila Kinali wrote:

> Package: cups
> Version: 2.2.6-5
> Severity: normal
> 
> I just updated my testing system and got the new 2.2.6-5 cups package.
> Now cupsd uses 100% continuously after a few seconds after startup.
> This was not the case with 2.2.6-4.

I have not read the bug record in detail, Attila, but do you observe
this behaviour with what the present unstable has (cups 2.3.0-7)?

Regards,

Brian.



Bug#907721: lxde: workaround : remove xscreensaver

2019-11-16 Thread bikepunk
Package: lxde
Version: 10
Followup-For: Bug #907721

Dear Maintainer,


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I've found out that both packages "light-locker" and "xscreensaver"
 were installed (automaticaly, I didn't installed them manually).
 I purged xscreensaver


   * What was the outcome of this action?

 The problem is solved for me.

   * What outcome did you expect instead?

 I'm curious to know why both packages were installed by default ??
 They seem to conflict.

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

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

Versions of packages lxde depends on:
ii  galculator   2.1.4-1+b1
ii  gpicview 0.2.5-2+b1
ii  leafpad  0.8.18.1-5
ii  lxappearance 0.6.3-1
ii  lxappearance-obconf  0.2.3-1
ii  lxde-core10
ii  lxde-icon-theme  0.5.1-2
ii  lxhotkey-gtk 0.1.0-1+b1
ii  lxinput  0.3.5-1
ii  lxrandr  0.3.2-1
ii  lxsession-edit   0.5.4-1
ii  lxterminal   0.3.2-1
ii  xarchiver1:0.5.4.14-1

Versions of packages lxde recommends:
ii  chromium [www-browser]   78.0.3904.97-1~deb10u1
ii  clipit   1.4.4+git20190202-1
ii  deluge   1.3.15-2
ii  evince [pdf-viewer]  3.30.2-3
ii  firefox-esr [www-browser]68.2.0esr-1~deb10u1
ii  gnome-disk-utility   3.30.2-3
ii  gnome-system-tools   3.0.0-8
ii  gucharmap1:11.0.3-3
ii  lightdm [x-display-manager]  1.26.0-4
ii  lxmusic  0.4.7-1
ii  lxpolkit 0.5.4-1
ii  menu-xdg 0.6
ii  network-manager-gnome1.8.20-1.1
ii  smplayer 18.10.0~ds0-1
ii  usermode 1.109-3
ii  vlc  3.0.8-0+deb10u1
ii  xserver-xorg 1:7.7+19

Versions of packages lxde suggests:
ii  gimp 2.10.8-2
ii  libreoffice  1:6.1.5-3+deb10u4
ii  lxlauncher   0.2.5-1
ii  lxtask   0.1.9-1
pn  pidgin   
pn  pk-update-icon   
pn  xfce4-power-manager  

-- no debconf information



Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

2019-11-16 Thread Holger Levsen
hi Sean,

On Sun, Jul 22, 2018 at 03:54:05PM +0800, Sean Whitton wrote:
> Section 6.4 should perhaps recommend `command -v` not `which`, because
> Debian Policy 4.1.5.0 allows maintainer scripts to assume SUSv4, which
> requires support for `command -v`.

three comments: 

a.) 'should perhaps' is a pretty weak statement ;p 
b.) whats SUSv4?
c.) I'm pondering to mention both but recommend "the winner" once I
learned about SUSv4 - or do you think that's a bad idea?

> Additionally see the discussion in #747320, where Jakub Wilk does point
> out that maintainer scripts may assume /usr is mounted, so I'm not sure
> about this.

how is it relevant if /usr is mounted? if its not, both 'which' and '-v' can
fail...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature


Bug#944871: docbook-xsl: readds catalogs to the super catalog on every upgrade

2019-11-16 Thread Helmut Grohne
Source: docbook-xsl
Version: 1.79.1+dfsg-2
Severity: serious
Justification: Policy 10.7.3

Consider the following interaction:

| # apt install docbook-xsl
| # grep delegateURI.*xsl /etc/xml/catalog
| http://docbook.sourceforge.net/release/xsl/; 
catalog="file:///etc/xml/docbook-xsl.xml"/>
| # update-xmlcatalog --del --type uri --id 
"http://docbook.sourceforge.net/release/xsl/; --root
| # grep delegateURI.*xsl /etc/xml/catalog
| # apt reinstall docbook-xsl
| # grep delegateURI.*xsl /etc/xml/catalog
| http://docbook.sourceforge.net/release/xsl/; 
catalog="file:///etc/xml/docbook-xsl.xml"/>
| #

We can see that apt reinstall docbook-xsl changed the contents of
/etc/xml/catalog. This also happens during package upgrades. The prerm
script removes docbook-xsl from the root catalog and the postinst script
adds it back. Thus, removal by a user is not preserved. This is a
violation of Debian policy section 10.7.3, which says "local changes
must be preserved during a package upgrade".

We had a very similar issue with the sgml super catalog. Read up on
#88010 and #477751. Fixing that one was very painful. It required a lot
of uploads and we ran into bugs with dpkg triggers. I guess that this
bug is similarly painful. On the bright side, fixing this has the
potential to remove a lot of maintainer scripts and move us towards more
declarative packaging.

Unfortunately, it really is a violation of the policy and we should
either fix this bug or policy. I'm unsure how to proceed here, so I just
report it. Good luck.

Helmut



Bug#944873: mark docbook-xsl-ns Multi-Arch: foreign

2019-11-16 Thread Helmut Grohne
Package: docbook-xsl-ns
Version: 1.79.1+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:colord src:gdcm src:iputils src:kildclient src:nsis 
src:package-update-indicator src:xmlstarlet src:xwrited

The affected packages fail to satisfy their cross build dependencies,
because their dependency on docbook-xsl-ns is unsatisfiable. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign or annotated :native. In this case,
the foreign marking is reasonable:
 * docbook-xsl is already thus marked and docbook-xsl-ns is very
   similar.
 * docbook-xsl-ns is not proposed by the multiarch hinter, because it
   has maintainer scripts and the hinter cannot understand them.
   Inspecting them reveals that they only update the super catalog,
   which is an architecture-independent operation.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru docbook-xsl-1.79.1+dfsg/debian/changelog 
docbook-xsl-1.79.1+dfsg/debian/changelog
--- docbook-xsl-1.79.1+dfsg/debian/changelog2016-09-07 01:41:50.0 
+0200
+++ docbook-xsl-1.79.1+dfsg/debian/changelog2019-11-16 18:16:14.0 
+0100
@@ -1,3 +1,9 @@
+docbook-xsl (1.79.1+dfsg-3) UNRELEASED; urgency=medium
+
+  * Also mark docbook-xsl-ns Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 16 Nov 2019 18:16:14 +0100
+
 docbook-xsl (1.79.1+dfsg-2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru docbook-xsl-1.79.1+dfsg/debian/control 
docbook-xsl-1.79.1+dfsg/debian/control
--- docbook-xsl-1.79.1+dfsg/debian/control  2016-09-07 01:41:50.0 
+0200
+++ docbook-xsl-1.79.1+dfsg/debian/control  2019-11-16 18:13:12.0 
+0100
@@ -40,6 +40,7 @@
 
 Package: docbook-xsl-ns
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Recommends: docbook5-xml (>> 5)
 Suggests: dbtoepub,


Bug#944872: libindicator FTBFS: error: G_ADD_PRIVATE [-Werror]

2019-11-16 Thread Helmut Grohne
Source: libindicator
Version: 0.5.0-4
Severity: serious
Tags: ftbfs upstream

libindicator fails to build from source in unstable.

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libindicator_0.5.0-4.rbuild.log.gz
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. 
-I/build/1st/libindicator-0.5.0/./libindicator -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/pango-1.0 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/uuid 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gio-unix-2.0 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DG_LOG_DOMAIN=\"libindicator\" 
-Wall -Werror -Wno-deprecated-declarations -g -O2 
-ffile-prefix-map=/build/1st/libindicator-0.5.0=. -fstack-protector-strong 
-Wformat -Werror=format-security -c 
/build/1st/libindicator-0.5.0/./libindicator/indicator-object.c  -fPIC -DPIC -o 
.libs/libindicator_la-indicator-object.o
| /build/1st/libindicator-0.5.0/./libindicator/indicator-object.c: In function 
'indicator_object_init':
| /build/1st/libindicator-0.5.0/./libindicator/indicator-object.c:307:13: 
error: G_ADD_PRIVATE [-Werror]
|   307 |  IndicatorObjectPrivate * priv = G_TYPE_INSTANCE_GET_PRIVATE (self, 
INDICATOR_OBJECT_TYPE, IndicatorObjectPrivate);
|   | ^~~
| cc1: all warnings being treated as errors
| make[4]: *** [Makefile:643: libindicator_la-indicator-object.lo] Error 1
| make[4]: Leaving directory 
'/build/1st/libindicator-0.5.0/build/gtk2/libindicator'
| make[3]: *** [Makefile:501: all] Error 2
| make[3]: Leaving directory 
'/build/1st/libindicator-0.5.0/build/gtk2/libindicator'
| make[2]: *** [Makefile:434: all-recursive] Error 1
| make[2]: Leaving directory '/build/1st/libindicator-0.5.0/build/gtk2'
| make[1]: *** [Makefile:365: all] Error 2
| make[1]: Leaving directory '/build/1st/libindicator-0.5.0/build/gtk2'
| make: *** [/usr/share/cdbs/1/class/makefile.mk:77: 
debian/stamp-makefile-build/gtk2] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also reproduced by crossqa:
http://crossqa.debian.net/build/libindicator_0.5.0-4_s390x_20191027214029.log

This is likely due to changes in glib2.0. If you search for error and
G_ADD_PRIVATE, you'll find similar bugs.

Helmut



Bug#944764: abcm2ps: please package 8.14.6

2019-11-16 Thread Patrice Duroux
Hi,

Just for info, as I am also a user of its so I started maintaining a guest
repository month ago (and also for abcmidi) here:
https://salsa.debian.org/Peutch-guest/abcm2ps

Sure it is not official and may be not very compliant to Debian policy & co.
It is already targeting version 8.14.6. On my system using cowbuilder the
packages are build successfully and lintian seems to be happy with also!

Patrice

On Thu, 14 Nov 2019 23:51:13 +0100 Nicolas Boulenguez 
wrote:
> Package: abcm2ps
> Severity: wishlist
> Tags: patch
> 
> Hello.
> Please consider updating the package to upstream version 8.14.6.
> No change is required, except maybe a bump of Standards-Version.
> Would you mind me becoming an Uploader?
> How about hosting the package history on salsa.debian.org?
> 
> 



Bug#944862: RM: laditools/oldstable -- ROM; Python 2 removal, dead upstream

2019-11-16 Thread Ross Gammon
retitle 944862 RM: laditools/unstable -- ROM; Python 2 removal, dead upstream
thanks

Hi Adam,

On 11/16/19 4:56 PM, Adam D. Barratt wrote:
> 
> I assume you didn't really mean oldstable, as the subject suggestions,
> as Python 2 removal really isn't relevant there.
> 
> Regards,
> 
> Adam
> 

You are correct - sorry - I meant unstable

Regards,

Ross



signature.asc
Description: OpenPGP digital signature


Bug#907721: lxde: I also have this black screen issue after resume with debian 10 buster.

2019-11-16 Thread bikepunk
Package: lxde
Version: 10
Followup-For: Bug #907721

Dear Maintainer,

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

   * What led up to the situation?
   suspend or lock screen. the issue happens randomly, about 50% chance.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
be able to log back in

*** End of the template - remove these template lines ***


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

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

Versions of packages lxde depends on:
ii  galculator   2.1.4-1+b1
ii  gpicview 0.2.5-2+b1
ii  leafpad  0.8.18.1-5
ii  lxappearance 0.6.3-1
ii  lxappearance-obconf  0.2.3-1
ii  lxde-core10
ii  lxde-icon-theme  0.5.1-2
ii  lxhotkey-gtk 0.1.0-1+b1
ii  lxinput  0.3.5-1
ii  lxrandr  0.3.2-1
ii  lxsession-edit   0.5.4-1
ii  lxterminal   0.3.2-1
ii  xarchiver1:0.5.4.14-1

Versions of packages lxde recommends:
ii  chromium [www-browser]   78.0.3904.97-1~deb10u1
ii  clipit   1.4.4+git20190202-1
ii  deluge   1.3.15-2
ii  evince [pdf-viewer]  3.30.2-3
ii  firefox-esr [www-browser]68.2.0esr-1~deb10u1
ii  gnome-disk-utility   3.30.2-3
ii  gnome-system-tools   3.0.0-8
ii  gucharmap1:11.0.3-3
ii  lightdm [x-display-manager]  1.26.0-4
ii  lxmusic  0.4.7-1
ii  lxpolkit 0.5.4-1
ii  menu-xdg 0.6
ii  network-manager-gnome1.8.20-1.1
ii  smplayer 18.10.0~ds0-1
ii  usermode 1.109-3
ii  vlc  3.0.8-0+deb10u1
ii  xserver-xorg 1:7.7+19

Versions of packages lxde suggests:
ii  gimp 2.10.8-2
ii  libreoffice  1:6.1.5-3+deb10u4
ii  lxlauncher   0.2.5-1
ii  lxtask   0.1.9-1
pn  pidgin   
pn  pk-update-icon   
pn  xfce4-power-manager  

-- no debconf information



Bug#944812: interimap: uninitialized value

2019-11-16 Thread Jonas Smedegaard
Quoting Guilhem Moulin (2019-11-16 17:50:14)
> On Sat, 16 Nov 2019 at 16:25:15 +0100, Jonas Smedegaard wrote:
> > jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 | 
> > grep -Fw 97
> > […]
> > local(INBOX.olpc): WARNING: No match for modified remote UID 97. 
> > Downloading again.
> > remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
> > BODY.PEEK[] ENVELOPE)
> 
> I'm suprised grep didn't match the server response for that command.

Perhaps if you talking about matching the originally reported warning, 
then beware that the warning mesage initially reported happened only 
while initially syncronizing that mailbox from scratch.  I am unable to 
repeat that exact warning message - but instead the warning message 
above is now repeatable for me.


> Do you have anything at all between
> 
> remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
> BODY.PEEK[] ENVELOPE)
> 
>  and
> 
> remote(INBOX.olpc): S: 04 OK Fetch completed

Nope:

jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 | 
grep -Fw 97 -C1
local(INBOX.olpc): S: * 96 FETCH (UID 96 MODSEQ (2) FLAGS ())
local(INBOX.olpc): S: * 97 FETCH (UID 97 MODSEQ (2) FLAGS ())
local(INBOX.olpc): S: * 98 FETCH (UID 98 MODSEQ (2) FLAGS ())
--
remote(INBOX.olpc): S: * 96 FETCH (UID 3466 MODSEQ (2) FLAGS ())
remote(INBOX.olpc): S: * 97 FETCH (UID 3467 MODSEQ (2) FLAGS ())
remote(INBOX.olpc): S: * 98 FETCH (UID 3468 MODSEQ (2) FLAGS ())
--
remote(INBOX.olpc): S: * 3395 FETCH (UID 11660 MODSEQ (2) FLAGS ())
remote(INBOX.olpc): S: * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
remote(INBOX.olpc): S: * 3397 FETCH (UID 11662 MODSEQ (2) FLAGS ())
--
remote(INBOX.olpc): Update last clean state for INBOX.olpc: (UIDNEXT 12584 
HIGHESTMODSEQ 17 UIDVALIDITY 1225292233)
local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading 
again.
remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
BODY.PEEK[] ENVELOPE)
remote(INBOX.olpc): S: 04 OK Fetch completed (0.001 + 0.000 secs).



> > UID FETCH 97 BODY.PEEK[]
> > * 97 FETCH (BODY[] {6520}
> > […])
> > UID OK Fetch completed (0.132 + 0.000 + 0.131 secs).
> 
> Oh my bad, seems I typoed the IMAP command I gave you; that message is 
> sequence number #97 not UID 97.  It's a ‘FETCH’ command with tag 
> ‘UID’, while I wanted to send an ‘UID FETCH’ command with tag $foo, 
> like what's being found in the debug output above.
> 
> Please try again prefixing the command with ‘b ’ (or any other tag):
> 
> b UID FETCH 97 BODY.PEEK[]

I guess uou mean this:

jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk "doveadm exec imap"
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
imap(jonas-debian): Error: net_connect_unix() failed: Connection refused
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND 
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED 
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 
LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in as 
jonas-debian
a EXAMINE INBOX.olpc
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 4304 EXISTS
* 0 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1225292233] UIDs valid
* OK [UIDNEXT 12584] Predicted next UID
* OK [HIGHESTMODSEQ 17] Highest
a OK [READ-ONLY] Examine completed (0.003 + 0.000 + 0.002 secs).
b UID FETCH 97 BODY.PEEK[]
b OK Fetch completed (0.001 + 0.000 secs).


> The server response should be
> 
> * $SEQ FETCH (UID 97 BODY[] $BODY)
> b OK Fetch completed
> 
> Where $SEQ is the sequence number (not necessarily 97) and $BODY is a 
> literal ‘{3}\r\nfoo’, quoted string ‘"bar"’, or NIL.  “UID 97” is 
> required to be present somewhere in the server response.

Seems I didn't get the expected response.  So does that indicate broken 
data at the server?


> I appreciate the assistance in debugging.  Thanks!

I am having fun :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#944860: udevadm trigger fails in chroot

2019-11-16 Thread Michael Biebl
Control: tags -1 moreinfo unreproducible

Am 16.11.19 um 16:05 schrieb Jonah Brüchert:
> Package: udev
> Version: 243-5
> Severity: normal
> 
> Dear Maintainer,
> 
> When running udevadm trigger in a chroot, in this case using debos, it fails 
> to write changes to /sys and exits with an error code.
> This breaks the post-install script of udisks2, which then fails with the 
> following error:

I can't reproduce this issue.


# debootstrap sid /srv/chroot/sid
..

I: Base system installed successfully.
# chroot /srv/chroot/sid/
# mount -t proc none /proc/
# udevadm trigger --subsystem-match=block --action=change
Running in chroot, ignoring request.

Can you be more specific how you setup your chroot so we have a chance
to reproduce the problem?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#944296: debian-policy: Source provenance requirement is WET

2019-11-16 Thread Sean Whitton
Hello,

On Sat 16 Nov 2019 at 04:13AM +01, Guillem Jover wrote:

> On Sat, 2019-11-09 at 08:55:23 -0700, Sean Whitton wrote:
>> On Thu 07 Nov 2019 at 09:00AM -08, Russ Allbery wrote:
>> > I'm in favor of dropping this information from debian/copyright and
>> > instead writing some language saying that packages should include this
>> > information in Homepage in debian/control and, if there's a substantial
>> > non-obvious difference between the package home page and how to download
>> > it, put download information in debian/watch.
>>
>> For a lot of packages I've put some sort of git web view URL into the
>> Source: field and a descriptive homepage into the Homepage: field.
>
> If upstream does not release tarballs, then I guess that usage of the
> Source: field seems appropriate, otherwise it looks a bit like a
> stretch?

Well, if the tarballs are an afterthought for upstream (perhaps
automatically generated by git-archive(1) on GitHub's releases page)
then I think it's appropriate.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#944812: interimap: uninitialized value

2019-11-16 Thread Guilhem Moulin
On Sat, 16 Nov 2019 at 16:25:15 +0100, Jonas Smedegaard wrote:
> jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 | 
> grep -Fw 97
> […]
> local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading 
> again.
> remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
> BODY.PEEK[] ENVELOPE)

I'm suprised grep didn't match the server response for that command.  Do
you have anything at all between

remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
BODY.PEEK[] ENVELOPE)

 and

remote(INBOX.olpc): S: 04 OK Fetch completed

> UID FETCH 97 BODY.PEEK[]
> * 97 FETCH (BODY[] {6520}
> […])
> UID OK Fetch completed (0.132 + 0.000 + 0.131 secs).

Oh my bad, seems I typoed the IMAP command I gave you; that message is
sequence number #97 not UID 97.  It's a ‘FETCH’ command with tag ‘UID’,
while I wanted to send an ‘UID FETCH’ command with tag $foo, like what's
being found in the debug output above.

Please try again prefixing the command with ‘b ’ (or any other tag):

b UID FETCH 97 BODY.PEEK[]

The server response should be

* $SEQ FETCH (UID 97 BODY[] $BODY)
b OK Fetch completed

Where $SEQ is the sequence number (not necessarily 97) and $BODY is a
literal ‘{3}\r\nfoo’, quoted string ‘"bar"’, or NIL.  “UID 97” is
required to be present somewhere in the server response.

> Seems like this _isn't_ a zero-length message.

Message with sequence number #97 is likely not be the one we're looking
for.  (In your debug output I can see that UID 97 had sequence number
#3396 at the time.)

I appreciate the assistance in debugging.  Thanks!

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#944859: interimap: BAD Error in IMAP command UID FETCH: Too long argument

2019-11-16 Thread Jonas Smedegaard
Quoting Guilhem Moulin (2019-11-16 17:26:29)
> Fixed it a few days ago :-)

cool!

> Would you be willing to install a package from experimental in the 
> meantime if I were to upload one? :-)

Yes, certainly!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#943752: Needs GCC-6

2019-11-16 Thread ydirson
> A further information I received via IRC is that memtest86+
> _has_ to be compiled with GCC-6 - newer versions have a bug
> that break memtest86+.
> 
> I have verified that GCC-6 gives a working result,
> while GCC-8 doesn't.

Now that is a major issue, as gcc-6 was not even released with buster, we only 
have
7, 8 and 9 on hand now.



Bug#944870: kwartz-client: German translation for the debconf dialogue

2019-11-16 Thread Markus Hiereth
Package: kwartz-client
Version: 1.1
Severity: normal

Dear Georges,

an undated translation of the message catalogue for debconf 
configuration is attached.

Best regards
Markus

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

Kernel: Linux 4.19.0-5-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# German message catalogue for Configuring the kwartz package on Debian systems
# Copyright (C) 2019 Georges Khaznadar
# This file is distributed under the same license as the kwartz-client package.
# Markus Hiereth , 2019.
msgid ""
msgstr ""
"Project-Id-Version: kwartz-client\n"
"Report-Msgid-Bugs-To: kwartz-cli...@packages.debian.org\n"
"POT-Creation-Date: 2019-10-21 19:08+0200\n"
"PO-Revision-Date: 2019-11-11 20:00+0200\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "URI (\"Uniform Resource Identifier\") of the LDAP server:"
msgstr "URI (»Uniform Resource Identifier«) des LDAP servers:"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid ""
"Please enter the URI of the LDAP server provided by your Kwartz machine. You "
"can use a numeric IP address rather than a symbolic one, in order to "
"minimize failure possibilities when the name service is down."
msgstr ""
"Bitte geben Sie die URI des durch Ihre Kwartz-Maschine bereitgestellten LDAP-"
"Servers an. Nutzen Sie vorzugsweise die numerische IP-Adresse, wodurch es "
"nicht zu einem Ausfall kommt, wenn der Namensserver nicht verfügbar ist."

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "It is possible to specify multiple LDAP URIS, separated by spaces."
msgstr "Sie können mehrere, durch Leerzeichen getrennte LDAP-URIs angeben."

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid "LDAP's Base DN (\"Distinguished Name\"):"
msgstr "Der Basis-DN (»Distinguished Name«) für LDAP:"

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid ""
"Please enter the DN (\"Distinguished Name\") used as the base of the LDAP "
"service. Many systems use the elements of their domain name for this "
"purpose. For example, the domain \"example.net\" would use \"dc=example, "
"dc=net\"."
msgstr ""
"Geben Sie bitte den DN (»Distinguished Name«, den »hervorgehobenen Namen«) "
"ein, der als Basis für den LDAP-Dienst benutzt wird. Zu diesem Zweck greifen "
"viele Systeme auf Elemente des Domain-Namens zurück. Für die Domain "
"»example.net« zum Beispiel »dc=example, dc=net«."

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid "DN (\"Distinguished Name\") of one user:"
msgstr "Der DN (»Distinguished Name«) für einen Benutzer:"

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid ""
"Please enter the DN (\"Distinguished Name\") of one unprivileged user "
"already existing in the LDAP directory. Kwartz requires that requests come "
"from an existing user before replying anything."
msgstr ""
"Bitte geben Sie den DN (»Distinguished Name«) eines im LDAP-Verzeichnis "
"schon existierenden und nicht privilegierten Benutzers ein. Um zu antworten, "
"ist Kwartz darauf angewiesen, dass die Anfrage von einem existierenden "
"Benutzer kommt."

#. Type: password
#. Description
#: ../kwartz-client.templates:4001
msgid "Password of the unprivileged user:"
msgstr "Passwort des nicht privilegierten Benutzers:"

#. Type: password
#. Description
#: ../kwartz-client.templates:4001
msgid ""
"Please enter the password of the unprivileged user. Kwartz requires that "
"requests come from an existing user before replying anything. This password "
"should not be disclosed, and should be fairly strong."
msgstr ""
"Bitte geben Sie das Passwort des nicht privilegierten Benutzers ein. Um zu "
"antworten, ist Kwartz darauf angewiesen, dass die Anfrage von einem "
"existierenden Benutzer kommt. Das Passwort sollte nicht offengelegt und "
"schwer zu ermitteln sein."

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "The Samba name of the kwartz server:"
msgstr "Der Samba-Name des Kwartz-Servers:"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid ""
"Please enter the Samba name of the kwartz server; this is the name of the "
"server, as seen in Windows' neighborhood."
msgstr ""
"Bitte geben Sie den Samba-Namen des Kwartz-Servers ein. Dies ist der Name "
"des Servers, wie er von der Windows-Umgebung aus gesehen wird."

#. Type: string
#. Description
#: 

Bug#944869: ITP: ruby-atlassian-jwt -- simplify generating the claims needed to authenticate with the Atlassian Connect

2019-11-16 Thread Pirate Praveen

Package: wnpp
severity: wishlist
Owner: Pirate Praveen 

 this is a dependency of 
gitlab 12.3+




Bug#944868: xserver-xorg-video-mga: x server fails with segmentation fault with Matrox G400

2019-11-16 Thread Markus Hiereth
Package: xserver-xorg-video-mga
Version: 1:2.0.0-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

with a new installation of Debian 10 (as well after an upgrade to Debian 
9 which I skipped due to this problem, I have a dual boot system) the X 
servers did not start properly anymore as with Debian 8. I got a 
segmentation fault announced.

References 

  https://lists.debian.org/debian-x/2019/07/msg00069.html
Threads in the xorg mailing lists are 
  https://lists.x.org/archives/xorg/2019-July/059852.html
  https://lists.x.org/archives/xorg/2019-August/059876.html
The discussion there contains logfiles.

Due to suggestions given by the xorg mailing list I found to 
configuration items that avoid the failure:

a) introducing

   Option  "DRI" "False"

b) choosing explicitely a colour depth like 8

   SubSection "Display"
   Viewport   0 0
   Depth 8
   EndSubSection

Best regards
Markus Hiereth


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug 21  2017 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Mar  5  2019 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA 
G400/G450 [102b:0525] (rev 04)

Xorg X server configuration file status:

lrwxrwxrwx 1 root root 16 Sep  8 22:46 /etc/X11/xorg.conf -> xorg_190826.conf

Contents of /etc/X11/xorg.conf:
---
Section "ServerLayout"
Identifier "X.org Configured"
Screen "Screen0"
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
#hinzugefuegt am 29.07.2019 fuer manuell kompilierten Treiber mga
#auskommentiert, da am 10.08.2019 auch Debian-Treiberpaket zum Laufen 
gebracht werden konnte
#ModulePath   "/usr/local/lib/xorg/modules/drivers"
ModulePath   "/usr/lib/xorg/modules"
#die folgenden Font-Verzeichnisse am 27.08.2019 auskommentiert, 
#da sie offenbar immer in den FontPath eingefuegt werden
#FontPath "built-ins"
#FontPath "/usr/share/fonts/X11/misc"
#FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
#FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
#FontPath "/usr/share/fonts/X11/Type1"
#FontPath "/usr/share/fonts/X11/100dpi"
#FontPath "/usr/share/fonts/X11/75dpi"
#hinzugefuegt am 19.08.2019 fuer ttf-Schriftdateien in Paketen
# die nicht von Debian sind
FontPath "/usr/share/fonts/truetype"
FontPath "/usr/lib/cinelerra/fonts"
FontPath "/usr/local/bin/siemens/logo-32bit_8.2/jre/lib/fonts"
EndSection

Section "Module"
Load  "glx"
#Hinzugefuegt und auskommentiert am 11.08.2019 da uebergangen
#Disable "ddc"
#Hinzugefuegt und auskommentiert am 11.08.2019 da uebergangen
#Disable "i2c"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "auto"
Option  "Device" "/dev/input/mice"
Option  "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
Identifier   "Monitor0"
VendorName   "LG"
ModelName"575LE"
HorizSync 48.36
VertRefresh   60.00
Modeline "1024x768"  65.00  1024 1048 1184 1344   768 771 777 806 
-hsync -vsync
#hinzugefuegt am 11.08.2019, da Probieren durch X server wohl unnoetig
#Option hat aber nicht den Effekt, dass nur der angegeben Videomodus 
aktiviert wird
Option "DefaultModes" "False"
EndSection

Section "Device"
Identifier  "Card0"
#hinzugefuegt, um einen der drei Treiber auswaehlen zu koennen
Driver  "mga"
#hinzugefuegt, um einen der drei Treiber auswaehlen zu koennen
#Driver  "fbdev"
#hinzugefuegt, um einen der drei Treiber auswaehlen zu koennen
#Driver  "vesa"
BusID   "PCI:1:0:0"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "SWcursor"  # []
#Option "HWcursor"  # []
#Option "PciRetry"  # []
#Option "SyncOnGreen"   # []
#Option "NoAccel"   # []
#Option "ShowCache" # []
#Option "MGASDRAM"  # []
#Option "ShadowFB"  # []
#Option "UseFBDev"  

Bug#944867: adjtimex cannot understand ntpdate output

2019-11-16 Thread Oleg Broytman
Package: adjtimex
Version: 1.29-10
Severity: important

Dear Maintainer, I just upgraded from Debian 9 to 10 and started to get this:

$ sudo adjtimex -h pool.ntp.org
host found : host55.rax.ru
cannot understand ntpdate output

The output from the new ntpdate is:

$ sudo ntpdate pool.ntp.org
16 Nov 19:06:33 ntpdate[30125]: step time server 89.175.20.7 offset 
-32.476235 sec

The output from the old ntpdate (Debian 9) was:

$ sudo ntpdate pool.ntp.org
16 Nov 19:07:18 ntpdate[31131]: adjust time server 192.36.143.130 offset 
0.031384 sec

The problem seems to be related to bug #438718:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438718

The bug should be fixed long ago:
https://github.com/rogers0/adjtimex/commit/f28e0e1cbdc949689d14d9e067e931abbc366913
in version 1.22.


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

Kernel: Linux 4.14.154 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), LANGUAGE=C 
(charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages adjtimex depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  lsb-base   10.2019051400

adjtimex recommends no packages.

Versions of packages adjtimex suggests:
ii  ntpdate  1:4.2.8p12+dfsg-4

-- debconf information:
  adjtimex/compare_rtc: true
  adjtimex/run_daemon: true



Bug#944865: buster-pu: package limnoria/2019.02.23-1+deb10u1

2019-11-16 Thread Mattia Rizzolo
Package: release.debian.org
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Control: clone -1 -2
Control: retitle -2 stretch-pu: package limnoria/2017.01.10-1+deb9u1
Control: tag -2 = stretch
X-Debbugs-Cc: unit...@ubuntu.com


Hello SRMs,

Limnoria is affected by a security issue the security team deemed not
DSA-worthy.  See https://security-tracker.debian.org/tracker/CVE-2019-19010

I'm uploading fixed packages for both stretch and buster; the patch is
pretty much the same, so I'm opening a single bug, attached are the two
diffs.


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

 changelog |7 
 patches/fix-unsafe-eval.patch |  394 ++
 patches/series|1 
 3 files changed, 402 insertions(+)

diff -Nru limnoria-2019.02.23/debian/changelog limnoria-2019.02.23/debian/changelog
--- limnoria-2019.02.23/debian/changelog	2019-02-23 01:52:11.0 +0100
+++ limnoria-2019.02.23/debian/changelog	2019-11-12 16:43:35.0 +0100
@@ -1,3 +1,10 @@
+limnoria (2019.02.23-1+deb10u1) buster; urgency=medium
+
+  * Add patch from upstream to fix remote information disclosure and
+possibly remote code execution in the Math plugin.  CVE-2019-19010
+
+ -- Mattia Rizzolo   Tue, 12 Nov 2019 16:43:35 +0100
+
 limnoria (2019.02.23-1) unstable; urgency=medium
 
   * New upstream version 2019.02.23
diff -Nru limnoria-2019.02.23/debian/patches/fix-unsafe-eval.patch limnoria-2019.02.23/debian/patches/fix-unsafe-eval.patch
--- limnoria-2019.02.23/debian/patches/fix-unsafe-eval.patch	1970-01-01 01:00:00.0 +0100
+++ limnoria-2019.02.23/debian/patches/fix-unsafe-eval.patch	2019-11-12 16:43:35.0 +0100
@@ -0,0 +1,394 @@
+commit 3848ae78de45b35c029cc333963d436b9d2f0a35
+Author: Valentin Lorentz 
+AuthorDate: Sat Nov 9 15:24:37 2019 +0100
+Commit: Valentin Lorentz 
+CommitDate: Sat Nov 9 15:49:31 2019 +0100
+
+Math: Rewrite calc functions with a proper evaluator.
+
+Instead of hacking around eval(), which everyone knows is a bad idea
+even with prior expression sanitizing.
+
+diff --git a/plugins/Math/evaluator.py b/plugins/Math/evaluator.py
+new file mode 100644
+index ..9e7208ef
+--- /dev/null
 b/plugins/Math/evaluator.py
+@@ -0,0 +1,169 @@
++###
++# Copyright (c) 2019, Valentin Lorentz
++# All rights reserved.
++#
++# Redistribution and use in source and binary forms, with or without
++# modification, are permitted provided that the following conditions are met:
++#
++#   * Redistributions of source code must retain the above copyright notice,
++# this list of conditions, and the following disclaimer.
++#   * Redistributions in binary form must reproduce the above copyright notice,
++# this list of conditions, and the following disclaimer in the
++# documentation and/or other materials provided with the distribution.
++#   * Neither the name of the author of this software nor the name of
++# contributors to this software may be used to endorse or promote products
++# derived from this software without specific prior written consent.
++#
++# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
++# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
++# ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
++# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
++# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
++# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
++# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
++# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
++# POSSIBILITY OF SUCH DAMAGE.
++###
++
++import ast
++import math
++import cmath
++import operator
++
++class InvalidNode(Exception):
++pass
++
++def filter_module(module, safe_names):
++return dict([
++(name, getattr(module, name))
++for name in safe_names
++if hasattr(module, name)
++])
++
++UNARY_OPS = {
++ast.UAdd: lambda x: x,
++   

Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7

2019-11-16 Thread Carsten Schoenert
meh, also the second email with the correct recipient got bounced by
T-Online ... :-/

Using now the Give-Back web interface by calling

https://buildd.debian.org/auth/giveback.cgi?pkg=thunderbird=sid=mips64el

More on give back service:
https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html

-- 
Regards
Carsten Schoenert



Bug#944859: interimap: BAD Error in IMAP command UID FETCH: Too long argument

2019-11-16 Thread Guilhem Moulin
Control: tag -1 confirmed pending

On Sat, 16 Nov 2019 at 15:57:16 +0100, Jonas Smedegaard wrote:
> Seems interimap can generate commands exceeding what Dovecot can handle.

Ack, that's a long-standing bug which breaks syncronisation in some
scenarios, such as large mailboxes with many non-contiguous UIDs being
changed at once.  Fixed it a few days ago :-)  It wasn't caught in the
test-suite before as test UID sets are typically way less sparse.


https://git.guilhem.org/interimap/commit/?id=0a2558aabfefd6800fe74c24e5aff2b0d47cc5e2

interimap is at fault here as there was no logic in place to avoid UID
sets from growing indefinitely.  But there is also a bug with Dovecot
(reported upstream at 
https://dovecot.org/pipermail/dovecot/2019-November/117522.html )
which makes thing even worse when COMPRESS=DEFLATE is used.

> Currently with my setup I experience this:

If you have access to the Dovecot config on both ends, a workaround is
to raise `imap_max_line_length` to something sensible (the default is
64k).

That said it's a very anoying bug when it bites, and I should rush the
next release.  I don't forsee a lot of code change anymore, but I'd like
to improve the docs before releasing.  Would you be willing to install a
package from experimental in the meantime if I were to upload one? :-)

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#944864: ITP: ruby-i18n-data -- country/language names and 2-letter-code pairs, in 85 languages

2019-11-16 Thread Sruthi Chandran
Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-i18n-data
  Version : 0.10.0
  Upstream Author : Michael Grosser
* URL : https://github.com/grosser/i18n_data
* License : Expat
  Description :
   - Present users coutries/languages in their language
   - Convert a country/language-name to its 2-letter-code
   - List of 2-letter-code/name pairs for all countries/languages in all
languages

Translations
Through pkg-isocodes:
   - 185 Language codes (iso 639 - 2 letter) in 68 Languages
   - 246 Country codes (iso 3166 - 2 letter) in 86 Languages
   - contry specific codes e.g. zh_TW are also available, have a look at
the isocodes website for all options



signature.asc
Description: OpenPGP digital signature


Bug#914260: dgit-infrastructure: dgit clone fails with "Out of memory, malloc failed"

2019-11-16 Thread Johannes Schauer
Maybe it would somehow be possible to pack the repository and upload it
somewhere so that I at least get the history? It's okay if botch cannot live on
dgit due to this issue but it would be nice if I could get access to its
history before I create a new repo elsewhere.

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#944589: gsequencer: stalls system

2019-11-16 Thread Joël Krähemann
Hi,

your kernel configuration usually resides in:

/boo/config-5.2.0*

Your GSequencer configuration file resides in:

$HOME/.gsequencer/ags.conf

PLEASE, attach both files.

regards,
Joël

On Sat, Nov 16, 2019 at 4:35 AM westlake  wrote:
>
> Bugreport on "Gsequencer" Case:
>   - Kernel I've been using while using Gsequencer was a non-debian build
> that has RT support. (built on this system by me)
>
> Bugreport on Debian Kernel Backports: --- I am about to file a report.
>   - bpo Kernel has an issue:  Chrome cannot start and complains about
> not being able to run due to not being able to create a "sandbox"
>-> ( fwiw I'm filing a report on this to
> linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned )
>
>
> Kernel rebooted my system and sticking with my custom boot-kernel for
> now as I can run chrome again.
>
> I did not check to see if I can run gsequencer with the bpo kernel.
>
> I am using the basic "make deb-pkg" with RT patches. gcc-8 was used to
> compile this kernel.
>
> I am using other RT applications such as ardour, and jackd2/jackdbus and
> I'm not noticing issues..
>
> cat /proc/version
> "Linux version 5.2.14-rt7 (customx@debian) (gcc version 8.3.0 (Debian
> 8.3.0-6)) #1 SMP PREEMPT RT Mon Sep 30 05:58:30 EDT 2019
> "
>
> On 2019-11-13 5:50 a.m., Joël Krähemann wrote:
> > Hi,
> >
> > thank you for reporting the bug.
> >
> > Do you use a custom realtime kernel configuration?
> >
> > best regards,
> > Joël
> >
> > On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
> >>
> >> Package: gsequencer
> >> Version: 2.1.53-2
> >> Severity: important
> >>
> >> stalls a system that is running on an RT kernel
> >>
> >
>



Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

2019-11-16 Thread Christoph Berg
Re: Chris Lamb 2019-11-14 
<36f7dff0-df0b-479b-aa5e-9018ce438...@www.fastmail.com>
> 2.35.0~bpo9+1 and 2.35.0~bpo10+1 uploaded to {stretch,buster}-backports
> respectfully.

Thanks!

Christoph



Bug#944863: plasma-discover times out when fcitx is installed

2019-11-16 Thread Arjen Balfoort
Package: plasma-discover
Version: 5.14.5.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
After installation of fcitx (apt-get install fcitx fcitx-mozc kde-config-fcitx) 
Plasma Discover takes a long time to enable the fetching and update all 
buttons. When it times out, the buttons are enabled.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I started PD in update mode from the terminal: plasma-discover --mode update

   * What was the outcome of this action?
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:182:
 TypeError: Cannot assign to read-only property "parent"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:182:
 TypeError: Cannot assign to read-only property "parent"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:182:
 TypeError: Cannot assign to read-only property "parent"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:182:
 TypeError: Cannot assign to read-only property "parent"
adding empty sources model QStandardItemModel(0x5646e40543b0)
no packages for "org.kde.plasma.activitybar"
no packages for "org.kde.plasma.systemloadviewer"
no packages for "io.devdocs.webapp"
no packages for "org.kde.plasma.showActivityManager"
no packages for "org.kde.plasma.grouping"
no packages for "org.kde.plasma.binaryclock"
no packages for "org.kde.plasma.diskquota"
no packages for "org.kde.kscreen"
no packages for "libgphoto2"
no packages for "org.debian.debian"
no packages for "org.kde.plasma.kimpanel"
no packages for "org.kde.plasma.timer"
no packages for "im.riot.webapp"
no packages for "org.kde.plasma.appmenu"
no packages for "org.kde.plasma.quicklaunch"
invalid kns backend! "/etc/xdg/ksysguard.knsrc" because: "Config group not 
found! Check your KNS3 installation."
invalid kns backend! "/etc/xdg/servicemenu.knsrc" because: "Config group not 
found! Check your KNS3 installation."
org.kde.plasma.discover: couldn't open file 
"/home/solydxk/.cache/discover/featured-5.9.json" "No such file or directory"
org.kde.plasma.discover: couldn't open file 
"/home/solydxk/.cache/discover/featured-5.9.json" "No such file or directory"
org.kde.plasma.discover: couldn't open file 
"/home/solydxk/.cache/discover/featured-5.9.json" "No such file or directory"
org.kde.plasma.libdiscover: Failed to fetch ratings  "Timeout on 
server\nodrs.gnome.org: Socket operation timed out"
org.kde.knewstuff.core: Could not find category "Fcitx Theme"
invalid kns backend! "/etc/xdg/fcitx-skin.knsrc" because: "Backend Fcitx-skin 
took too long to initialize"
org.kde.plasma.libdiscover: Discarding invalid backend "fcitx-skin.knsrc"

PD times out on the second last line.

Content of /etc/xdg/fcitx-skin.knsrc
[KNewStuff3]
Categories=Fcitx Theme
InstallPath=.config/fcitx/skin
Uncompress=archive

   * What outcome did you expect instead?
I do not know why PD needs these knsrc files but if it does, it should not take 
so long to continue and enable the top right buttons.



-- System Information:
Distributor ID: Solydxk
Description:SolydK 10 64-bit
Release:10
Codename:   buster
Architecture: x86_64

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-discover depends on:
ii  appstream0.12.5-1
ii  apt-config-icons 0.12.5-1
ii  kio  5.54.1-1
ii  libappstreamqt2  0.12.5-1
ii  libc62.28-10
ii  libkf5attica55.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5itemmodels55.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5newstuffcore5  5.54.0-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libpackagekitqt5-1   1.0.1-1
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus5  5.11.3+dfsg1-1+deb10u1
ii  libqt5gui5  

Bug#944862: RM: laditools/oldstable -- ROM; Python 2 removal, dead upstream

2019-11-16 Thread Adam D. Barratt
On Sat, 2019-11-16 at 16:50 +0100, Ross Gammon wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Laditools is dead upstream, and Alessio Treglia who forked it
> previously is no longer as active as he used to be.
> 
> The package is python 2, and would need to be ported to python 3 to
> survive in Debian.
> 
> However, laditools is becoming less relevant for Linux Audio as other
> tools are developed (e.g. the KX Studio tools).

I assume you didn't really mean oldstable, as the subject suggestions,
as Python 2 removal really isn't relevant there.

Regards,

Adam



Bug#944862: RM: laditools/oldstable -- ROM; Python 2 removal, dead upstream

2019-11-16 Thread Ross Gammon
Package: ftp.debian.org
Severity: normal

Laditools is dead upstream, and Alessio Treglia who forked it previously is no
longer as active as he used to be.

The package is python 2, and would need to be ported to python 3 to survive in
Debian.

However, laditools is becoming less relevant for Linux Audio as other tools are
developed (e.g. the KX Studio tools).



Bug#943752: memtest86+: Please switch source tree

2019-11-16 Thread ydirson
> Upstream memtest86+ is broken - and there are a few patches that
> aren't
> even included.
> 
> I'd recommend to switch over to
> 
>  $ git clone https://review.coreboot.org/memtest86plus
> 
> as that seems maintained, and will even work on my machine
> (and not just hang, like upstream).
> 
> 
> Base page is at
> 
>  https://www.coreboot.org/Memtest86%2B

Thanks, I'll look into this!



Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7

2019-11-16 Thread Carsten Schoenert
Dear buildd admins,

could you please reschedule the thunderbird build in unstable for misp64el?

I've tested a rebuild without any changes on eller.d.o and the build
went fine there.

My guess is that the buildd had some hiccup while the configure run of
Thunderbird.

Thanks!
Carsten

Am 14.11.19 um 09:56 schrieb Paul Gevers:
> Source: thunderbird
> Version: 1:68.2.2-1
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: ftbfs
>
> Dear maintainers,
> 
> Your package is part of the libevent transition. I binNMU'ed your package but
> if fails to build on mips64el. Can you please investigate the situation?
> 
> Paul
> 
> https://buildd.debian.org/status/package.php?p=thunderbird
> 
> Tail of log for thunderbird on mips64el:
> 
>  3:26.57 js/src> checking whether the C++ compiler supports 
> -Wno-gnu-zero-variadic-macro-arguments... yes
>  3:27.08 js/src> checking whether the C++ compiler supports 
> -Wno-noexcept-type... yes
>  3:27.60 js/src> checking whether the C++ compiler supports 
> -fno-sized-deallocation... yes
>  3:27.63 js/src> checking for rustc... /usr/bin/rustc
>  3:27.63 js/src> checking for cargo... /usr/bin/cargo
>  3:30.11 js/src> checking rustc version... 1.37.0
>  3:30.30 js/src> checking cargo version... 1.36.0
>  3:30.45 js/src> ERROR: Command `/usr/bin/rustc --print target-list` failed 
> with exit status -10.
>  3:30.83 *** Fix above errors and then restart with\
>  3:30.83"./mach build"
>  3:30.83 make[2]: *** [client.mk:115: configure] Error 1
>  3:30.83 make[2]: Leaving directory '/<>'
> make[1]: *** [debian/rules:112: override_dh_auto_configure] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:83: build-arch] Error 2
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- no debconf information
> 
>



Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7

2019-11-16 Thread Carsten Schoenert
resend after fixing main recipient :-)

Am 16.11.19 um 16:38 schrieb Carsten Schoenert:
> Dear buildd admins,
> 
> could you please reschedule the thunderbird build in unstable for misp64el?
> 
> I've tested a rebuild without any changes on eller.d.o and the build
> went fine there.
> 
> My guess is that the buildd had some hiccup while the configure run of
> Thunderbird.
> 
> Thanks!
> Carsten
> 
> Am 14.11.19 um 09:56 schrieb Paul Gevers:
>> Source: thunderbird
>> Version: 1:68.2.2-1
>> Severity: serious
>> Tags: ftbfs sid bullseye
>> Justification: ftbfs
>>
>> Dear maintainers,
>>
>> Your package is part of the libevent transition. I binNMU'ed your package but
>> if fails to build on mips64el. Can you please investigate the situation?
>>
>> Paul
>>
>> https://buildd.debian.org/status/package.php?p=thunderbird
>>
>> Tail of log for thunderbird on mips64el:
>>
>>  3:26.57 js/src> checking whether the C++ compiler supports 
>> -Wno-gnu-zero-variadic-macro-arguments... yes
>>  3:27.08 js/src> checking whether the C++ compiler supports 
>> -Wno-noexcept-type... yes
>>  3:27.60 js/src> checking whether the C++ compiler supports 
>> -fno-sized-deallocation... yes
>>  3:27.63 js/src> checking for rustc... /usr/bin/rustc
>>  3:27.63 js/src> checking for cargo... /usr/bin/cargo
>>  3:30.11 js/src> checking rustc version... 1.37.0
>>  3:30.30 js/src> checking cargo version... 1.36.0
>>  3:30.45 js/src> ERROR: Command `/usr/bin/rustc --print target-list` failed 
>> with exit status -10.
>>  3:30.83 *** Fix above errors and then restart with\
>>  3:30.83"./mach build"
>>  3:30.83 make[2]: *** [client.mk:115: configure] Error 1
>>  3:30.83 make[2]: Leaving directory '/<>'
>> make[1]: *** [debian/rules:112: override_dh_auto_configure] Error 2
>> make[1]: Leaving directory '/<>'
>> make: *** [debian/rules:83: build-arch] Error 2
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers testing
>>   APT policy: (990, 'testing'), (500, 'testing-debug')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> -- no debconf information
>>
>>

-- 
Mit freundlichen Grüßen
Carsten Schönert



Bug#944861: linux-image-3.16.0-10-686-pae: No bluetooth connection with audio devices. Error exists since linux-kernel 3.16.74-1 (debian)

2019-11-16 Thread Guido Güßloff
Package: src:linux
Version: 3.16.76-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
I want to play music over bluetooth and my bluetooth-receiver. Connection was
established für 2-10 seconds and then disconnected again. Also connection to
PDAs and smartphones for transferring and receiving files is  not working.
   * What outcome did you expect instead?
With the kernel 3.16.72-1 (debian) bluetooth was working as expected. Sending
and receiving of files working good, connection to bt-headphones and bt-audio-
receivers was working.



-- Package-specific info:
** Version:
Linux version 3.16.0-10-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10+deb8u2) ) #1 SMP Debian 3.16.76-1 (2019-11-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-10-686-pae 
root=UUID=f97e167c-0dfe-4272-abc1-dff0972c7dce ro

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

** Kernel log:
[   18.771097] atl1c :03:00.0: irq 41 for MSI/MSI-X
[   18.785818] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   18.802847] iwlwifi :01:00.0: L1 Disabled - LTR Disabled
[   18.809519] iwlwifi :01:00.0: Radio type=0x2-0x1-0x0
[   19.089267] iwlwifi :01:00.0: L1 Disabled - LTR Disabled
[   19.099956] iwlwifi :01:00.0: Radio type=0x2-0x1-0x0
[   19.187473] IPv6: ADDRCONF(NETDEV_UP): wlan5: link is not ready
[   35.133402] Bluetooth: RFCOMM TTY layer initialized
[   35.133447] Bluetooth: RFCOMM socket layer initialized
[   35.133475] Bluetooth: RFCOMM ver 1.11
[   40.496818] gma500 :00:02.0: Backlight lvds set brightness 7a121e84
[   58.433395] wlan5: authenticate with 24:65:11:50:c5:c0
[   58.437585] wlan5: send auth to 24:65:11:50:c5:c0 (try 1/3)
[   58.471201] wlan5: send auth to 24:65:11:50:c5:c0 (try 2/3)
[   58.477569] wlan5: authenticated
[   58.481415] wlan5: waiting for beacon from 24:65:11:50:c5:c0
[   58.504154] wlan5: associate with 24:65:11:50:c5:c0 (try 1/3)
[   58.538220] wlan5: associate with 24:65:11:50:c5:c0 (try 2/3)
[   58.547643] wlan5: RX AssocResp from 24:65:11:50:c5:c0 (capab=0x431 status=0 
aid=4)
[   58.574783] wlan5: associated
[   58.574946] IPv6: ADDRCONF(NETDEV_CHANGE): wlan5: link becomes ready
[   58.575042] cfg80211: Calling CRDA for country: DE
[   58.595204] cfg80211: Regulatory domain changed to country: DE
[   58.595221] cfg80211:  DFS Master region: ETSI
[   58.595228] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   58.595242] cfg80211:   (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   58.595254] cfg80211:   (515 KHz - 525 KHz @ 8 KHz, 20 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   58.595268] cfg80211:   (525 KHz - 535 KHz @ 8 KHz, 20 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   58.595279] cfg80211:   (547 KHz - 5725000 KHz @ 16 KHz), (N/A, 2698 
mBm), (0 s)
[   58.595290] cfg80211:   (5725000 KHz - 5875000 KHz @ 8 KHz), (N/A, 1397 
mBm), (N/A)
[   58.595301] cfg80211:   (5700 KHz - 6600 KHz @ 216 KHz), (N/A, 
4000 mBm), (N/A)
[   61.336645] perf interrupt took too long (2534 > 2500), lowering 
kernel.perf_event_max_sample_rate to 5
[  194.117842] wlan5: authenticate with 24:65:11:50:c5:bc
[  194.122005] wlan5: send auth to 24:65:11:50:c5:bc (try 1/3)
[  194.122296] cfg80211: Calling CRDA to update world regulatory domain
[  194.145745] cfg80211: World regulatory domain updated:
[  194.145760] cfg80211:  DFS Master region: unset
[  194.145765] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[  194.145774] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[  194.145783] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[  194.145790] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[  194.145798] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[  194.145806] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[  194.145813] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[  194.145820] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[  194.145827] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[  194.177589] wlan5: authenticated
[  194.180101] wlan5: associate with 24:65:11:50:c5:bc (try 1/3)
[  194.190864] wlan5: associate with 24:65:11:50:c5:bc (try 2/3)
[  194.197462] wlan5: RX AssocResp from 24:65:11:50:c5:bc (capab=0x411 status=0 
aid=2)
[  194.216558] wlan5: associated
[  194.216914] cfg80211: Calling CRDA for country: DE
[  194.246580] cfg80211: Regulatory domain changed to country: DE
[  194.246598] cfg80211:  DFS Master region: ETSI
[  194.246607] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), 

Bug#944812: interimap: uninitialized value

2019-11-16 Thread Jonas Smedegaard
Quoting Guilhem Moulin (2019-11-15 20:05:32)
> On Fri, 15 Nov 2019 at 19:10:56 +0100, Jonas Smedegaard wrote:
> > Use of uninitialized value $length in numeric eq (==) at /usr/bin/interimap 
> > line 955.
> > remote(INBOX.olpc): WARNING: Ignoring new 0-length message (UID 97)
> > 
> > Wanted to let you know in case it is a bug in your code (rather than
> > just a broken email in my mailbox).
> 
> Thanks, it's either cosmetic (it shouldn't complain about the
> uninitialized value), or it's a more severe bug in the parser.  I guess
> this is reproducible with `interimap --repair INBOX.olpc`?

Not exactly - it emits a warning but a different one:

jonas@auryn:~$ interimap --config debian --repair INBOX.olpc
local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading 
again.
local: IMAP traffic (bytes): recv 197.05K sent 234
remote: IMAP traffic (bytes): recv 197.40K sent 338



> If so, could you please enable debug mode and run `grep -Fw "UID 97"` 
> on the logfile?

Here's (to catch anything, see above) a more relaxed debug output:

jonas@auryn:~$ interimap --config debian --repair INBOX.olpc 2>&1 | grep -Fw 97
local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading 
again.
jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 | 
grep -Fw 97
local(INBOX.olpc): S: * 97 FETCH (UID 97 MODSEQ (2) FLAGS ())
remote(INBOX.olpc): S: * 97 FETCH (UID 3467 MODSEQ (2) FLAGS ())
remote(INBOX.olpc): S: * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading 
again.
remote(INBOX.olpc): C: 04 UID FETCH 97 (MODSEQ FLAGS INTERNALDATE 
BODY.PEEK[] ENVELOPE)


> Failing that, you could run the following two commands through an IMAP
> session with the remote server:
> 
> C: a EXAMINE INBOX.olpc
> S: […]
> S: a OK [READ-ONLY] …
> C: UID FETCH 97 BODY.PEEK[]
> S: * $SEQ FETCH (UID 97 BODY[] …)
> 
> I'd like to see the first line of the server response past “BODY[] ”.
> If it's the keyword ‘NIL’ then it's a cosmetic bug; if it's a string,
> either in quoted (‘"foo"’) or literal (‘{3}\r\nfoo’) form it's something
> more problematic.

jonas-debian@xayide:~$ doveadm exec imap
doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
imap(jonas-debian): Error: net_connect_unix() failed: Connection refused
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND 
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED 
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 
LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in as 
jonas-debian
a EXAMINE INBOX.olpc
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 4304 EXISTS
* 0 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1225292233] UIDs valid
* OK [UIDNEXT 12584] Predicted next UID
* OK [HIGHESTMODSEQ 16] Highest
a OK [READ-ONLY] Examine completed (0.002 + 0.000 + 0.001 secs).
UID FETCH 97 BODY.PEEK[]
* 97 FETCH (BODY[] {6520}
Return-Path: 
X-Original-To: jonas-deb...@jones.dk
Delivered-To: jonas-deb...@jones.dk
[...]
From: David Farning 
To: Sugar List 
Date: Tue, 24 Jun 2008 13:32:19 -0500
Message-Id: <1214332339.32315.21.ca...@dfarning.desktop.org>
[...]
Sugar mailing list
su...@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
)
UID OK Fetch completed (0.132 + 0.000 + 0.131 secs).


> About zero-length messages: they are intentionally ignored as RFC 3502
> sec. 6.3.11 explicitly forbids them.  IMHO the WARNING makes sense if
> the body of that message is NIL or the empty string, but we should
> silence the bit mentioning line 955.

Seems like this _isn't_ a zero-length message.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#923490: kmail: random segfaults while idle

2019-11-16 Thread Dmitry Shachnev
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=398577

On Sun, Mar 03, 2019 at 10:08:14PM +0100, Sandro Knauß wrote:
> Control: reassign -1 qtwebengine 5.11.3+dfsg-2
> Control: affects -1 kmail
> Control: retitle -1 QtWebEnigne make kmail random segfault while idle
>
> The complete backtrace looks not to be complete, as I don't see any reference 
> to any libkf5X nor to kmail. For me it looks like an issue in qtwebegine, 
> that's why I reassign it to qtwebengine.

This happens in Qt event loop handling, that’s why there is no reference
to KMail code.

The relevant part of the code looks like:

  void RenderProcessHostImpl::ShutdownRequest() {
// Notify any contents that the renderer might shut down.
for (auto& observer : observers_) {
  observer.RenderProcessShutdownRequested(this);
}
...
  }

This means one of the observers is invalid. It may be coming from KMail code.

Adding a Forwarded link to the KDE bug with the same stacktrace.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#937657: Issue with numpy under Python 3.8

2019-11-16 Thread Andreas Tille
Hi Rebecca,

On Sat, Nov 16, 2019 at 09:16:17AM +, Rebecca N. Palmer wrote:
> I think that just means "numpy hasn't yet been rebuilt for Python 3.8". (In
> Python modules that include a C extension, the .py files are shared but the
> C part is compiled separately for each Python version.)
> 
> As there are ~500 modules requiring such a rebuild
> (https://release.debian.org/transitions/html/python3.8.html), this may take
> some time.  (numpy itself will probably be a source upload, to move 1.17
> from experimental to unstable.)
> 
> For testing, it may be easiest to use an Ubuntu chroot for now.

Its not about testing.  Its the usual build time test.  If I'd do a
source upload of this package it will FTBFS under the current state
of the archive.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Bug#944675: Bug#944838: xorg: after recent upgrade on two different machines, X no longer responds to kbd or mouse input

2019-11-16 Thread Peter Habcak
Out of curiosity, I tried to downgrade udev back to 243-5 and I am not 
able to reproduce the issue anymore. It looks that the upgrade to 243-7 
is not so important.


--
Peter



Bug#944857: ITP: golang-gopkg-resty.v1 -- Simple HTTP and REST client library for Go

2019-11-16 Thread louis
Package: wnpp
Severity: wishlist
Owner: louis 

* Package name: golang-gopkg-resty.v1
  Version : 1.12.0-1
  Upstream Author : Go Resty
* URL : https://github.com/go-resty/resty
* License : MIT
  Programming Lang: Go
  Description : Simple HTTP and REST client library for Go



I want to bring caddy v2 to debian package repository. For this I need
to package a lot of libraries. One of a central is
github.com/go-acme/lego which has some dependencies. One (without any
dependencies) is
github.com/go-resty/resty.



Bug#944786: exim4-config: openspf.org gone

2019-11-16 Thread Andreas Metzler
Control: tags -1 pending

On 2019-11-15 Dean Hamstead  wrote:
> Package: exim4-config
> Version: 4.92-8+deb10u2~bpo9+1
> Severity: normal

> Dear Maintainer,
> 
> The message regarding openspf.org in conf.d/acl/30_exim4-config_check_rcpt is 
> now broken as the openspf.org domain is gone.

Thanks for the report, fixed in GIT by dropping the URL. (SPF should be
common knowledge for MTA admins now, special handholding should not be
necessary.)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#886831: phpmyadmin: Package postinst script database backup fails during Jessie to Stretch migration.

2019-11-16 Thread Felipe Sateler
On Wed, 10 Jan 2018 10:56:27 + Simon Byrnand  wrote:
> Package: phpmyadmin
> Version: 4:4.6.6-4
> Severity: important
>
> Dear Thijs Kinkhorst,
>
> A problem has been noticed with the package upgrade process of phpmyadmin
when migrating an OSMC (Debian) Jessie system to Stretch.
>
> The postinst script appears to fail to back up the old database, this
leads to the entire postinst script failing thus causing a partially failed
dist-upgrade and inconsistent APT state. The following is logged:
>
> Setting up phpmyadmin (4:4.6.6-4) ...
> Installing new version of config file /etc/phpmyadmin/apache.conf ...
> Installing new version of config file /etc/phpmyadmin/config.inc.php ...
> Installing new version of config file /etc/phpmyadmin/lighttpd.conf ...
> Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
> dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
> Replacing config file /etc/dbconfig-common/phpmyadmin.conf with new
version
> Replacing config file /etc/phpmyadmin/config-db.php with new version
> creating database backup in
/var/cache/dbconfig-common/backups/phpmyadmin_4:4.2.12-2+deb8u2.2018-01-10-10.30.29.
> dumping database as user failed, retrying with administrator credentials.
> error encountered backing up the old database:
> mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db =
'phpmyadmin'': Cannot load from mysql.proc. The table is probably corrupted
(1728)
> dbconfig-common: phpmyadmin configure: aborted.
> dbconfig-common: flushing administrative password
> ESC[1mdpkg:ESC[0m error processing package phpmyadmin (--configure):
>  subprocess installed post-installation script returned error exit status
1

I'm not sure there's anything we can do about this anymore. What should we
do about this report?

Saludos


Bug#944856: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u2

2019-11-16 Thread Dmitry Shachnev
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Release team,

I would like to update qtbase-opensource-src in Buster, to fix the following
bugs:

#911702 — okular does not print to network printer
#911844 — okular prints to the wrong printer
#935909 — segfault when removing rich content (like tables) from QLabel
#935627 — graphics tablet hover events (tooltips/mouse-over) broken

The fix for the first two bugs has already been ACKed during the freeze in
#930669, but the fix did not reach bullseye because it was built against gcc-8
from sid.

All these bugs are already fixed in sid/bullseye.

The debdiff against the current version in buster (which was a security
upload) is attached.

--
Dmitry Shachnev
diff --git a/debian/changelog b/debian/changelog
index 2dc6b71..ce68d2f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+qtbase-opensource-src (5.11.3+dfsg1-1+deb10u2) UNRELEASED; urgency=medium
+
+  [ Dmitry Shachnev ]
+  * Backport upstream patch to add support for non-PPD printers and avoid
+silent fallback to a printer supporting PPD (closes: #911702, #911844).
+  * Backport upstream patch to fix crash in QStyleSheetStyle::repolish()
+when using QLabels with rich text (closes: #935909).
+
+  [ Melvin Vermeeren ]
+  * Backport upstream patch to fix graphics tablet hover events (closes:
+#935627).
+
+ -- Dmitry Shachnev   Sat, 16 Nov 2019 15:48:41 +0300
+
 qtbase-opensource-src (5.11.3+dfsg1-1+deb10u1) buster-security; urgency=high
 
   * Fix crash when text contains too many directional chars (CVE-2019-18281).
diff --git a/debian/patches/ensure-qtabletevent-is-not-pre-accepted.patch b/debian/patches/ensure-qtabletevent-is-not-pre-accepted.patch
new file mode 100644
index 000..a0ff4f3
--- /dev/null
+++ b/debian/patches/ensure-qtabletevent-is-not-pre-accepted.patch
@@ -0,0 +1,38 @@
+Description: ensure that QTabletEvent is not pre-accepted before sending
+ In QWidget-world it's normal for input events to have the accepted
+ flag false by default, so that it's obvious after visiting a widget
+ subclass that does not override a particular handler function that it
+ did not handle that event type at all.  For tablet events in
+ particular, the contract (to which we've been paying more attention to
+ ensure that QTBUG-47007 remains properly fixed) is that if a
+ QTabletEvent is not accepted, a mouse event will follow.
+ Tablet-unaware applications need to get the same mouse events from a
+ Wacom stylus as they would receive from an actual mouse.
+ .
+ In this case the issue was missing hover events (mouse movements
+ in which no mouse button is pressed).  Without those, the enterEvent
+ and exitEvent virtuals are also not invoked properly.
+Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=b4b706d454b785ae
+Bug: https://bugs.debian.org/935627
+Last-Update: 2019-08-24
+
+--- a/src/widgets/kernel/qapplication.cpp
 b/src/widgets/kernel/qapplication.cpp
+@@ -3374,6 +3374,7 @@ bool QApplication::notify(QObject *recei
+ tablet->tangentialPressure(), tablet->rotation(), tablet->z(),
+ tablet->modifiers(), tablet->uniqueId(), tablet->button(), tablet->buttons());
+ te.spont = e->spontaneous();
++te.setAccepted(false);
+ res = d->notify_helper(w, w == receiver ? tablet : );
+ eventAccepted = ((w == receiver) ? tablet : )->isAccepted();
+ e->spont = false;
+--- a/src/widgets/kernel/qwidgetwindow.cpp
 b/src/widgets/kernel/qwidgetwindow.cpp
+@@ -1021,6 +1021,7 @@ void QWidgetWindow::handleTabletEvent(QT
+ event->pressure(), event->xTilt(), event->yTilt(), event->tangentialPressure(),
+ event->rotation(), event->z(), event->modifiers(), event->uniqueId(), event->button(), event->buttons());
+ ev.setTimestamp(event->timestamp());
++ev.setAccepted(false);
+ QGuiApplication::forwardEvent(widget, , event);
+ event->setAccepted(ev.isAccepted());
+ }
diff --git a/debian/patches/raw_printers.diff b/debian/patches/raw_printers.diff
new file mode 100644
index 000..9ac8395
--- /dev/null
+++ b/debian/patches/raw_printers.diff
@@ -0,0 +1,92 @@
+Description: cups: support raw printers
+ They don't have a ppd but we don't *really* need a ppd to just print.
+Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=84cc8d0badb4abc3
+Last-Update: 2019-06-16
+
+--- a/src/plugins/printsupport/cups/qcupsprintengine.cpp
 b/src/plugins/printsupport/cups/qcupsprintengine.cpp
+@@ -104,7 +104,11 @@ void QCupsPrintEngine::setProperty(Print
+ break;
+ case PPK_QPageLayout: {
+ QPageLayout pageLayout = value.value();
+-if (pageLayout.isValid() && (d->m_printDevice.isValidPageLayout(pageLayout, d->resolution) || 

Bug#944675: Bug#944838: xorg: after recent upgrade on two different machines, X no longer responds to kbd or mouse input

2019-11-16 Thread Peter Habcak
> On one machine (the AMDGPU one) `libinput debug-events --verbose` 
would complain about certain devices not being initialised by udev, 
including the keyboard device. Upgrading udev from version 243-5 to 
243-7 and reloading udev by running `udevadm control --reload-rules && 
udevadm trigger` and then restarting lightdm worked.


Yes, this fixed the issue for me as well. Upgrading udev was not enough, 
but after reloading udev everything runs smoothly and the fix seems to 
be permanent (no issues after reboot).
It fixed also another issue I was about to mention - "suspend when 
laptop lid is closed" stopped working with udev 243-5 as well.


> Oh and another thing for people wanting to play around with this, 
when you run `systemctl disable lightdm` and then fix the problem and 
then run `systemctl enable lightdm` the latter does not work for some 
stupid reason, even though the former command worked. You have to run 
`dpkg-reconfigure lightdm` to make it work again.


Same here, dpkg-reconfigure lightdm helped

#systemctl enable lightdm.service
Synchronizing state of lightdm.service with SysV service script with 
/lib/systemd/systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install enable lightdm
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.



Bug#944698: Help with updating triggers in gitlab

2019-11-16 Thread Pirate Praveen

Control: tag -1 help

Hi team,

See 

For example ruby-google-protobuf gets installed in 
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/specifications/ 
which is dependent on both ruby versions and architecture. I could not 
find if trigger file support regular expressions or variables.


Currently we have the following lines in debian/gitlab.triggers file

interest-noawait /usr/lib/ruby/vendor_ruby
interest-noawait /usr/share/rubygems-integration

Any suggestions?





Bug#944711: Failed to set session cookie

2019-11-16 Thread Felipe Sateler
Control: severity -1 important

On Thu, Nov 14, 2019 at 5:36 AM Jörg Frings-Fürst  wrote:

> Package: phpmyadmin
> Version: 4:4.9.1+dfsg1-2
> Severity: grave
> Tags: upstream
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello,
>
>
> I get on login
>
> [quote]
> Failed to set session cookie. Maybe you are using HTTP instead of HTTPS to
> access phpMyAdmin.
> [/quote]
>
> Upstream has fix this issue:
>
>
> https://github.com/phpmyadmin/phpmyadmin/pull/15273/files/45d46a6316c7a79d8c110ccbd18035c4d0c633fb
>
>
I don't think this issue qualifies as release-critical. You really should
not be using phpmyadmin over http, and nstead have your http server
redirect to https. I'm thus downgrading.

William, is the entire PR required, or just a section of it?

-- 

Saludos,
Felipe Sateler


Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation

2019-11-16 Thread Abou Al Montacir
A patch was applied on 2.0.6+dfsg-2 but it seems not completely fixing this
issue.Waiting for upstream to fix it properly.
-- 
Cheers,
Abou Al Montacir
Description: lazbuild fails to build some packages during auto tests.
Author: Abou Al Montacir 
Bug-Debian: http://bugs.debian.org/943600
diff --git a/components/ideintf/ideexterntoolintf.pas b/components/ideintf/ideexterntoolintf.pas
index 4654265c..fdf7549f 100644
--- a/components/ideintf/ideexterntoolintf.pas
+++ b/components/ideintf/ideexterntoolintf.pas
@@ -1229,12 +1229,14 @@ end;
 
 procedure TAbstractExternalTool.EnterCriticalSection;
 begin
-  FWorkerMessages.EnterCriticalSection;
+  if Assigned(FWorkerMessages) then
+FWorkerMessages.EnterCriticalSection;
 end;
 
 procedure TAbstractExternalTool.LeaveCriticalSection;
 begin
-  FWorkerMessages.LeaveCriticalSection;
+  if Assigned(FWorkerMessages) then
+FWorkerMessages.LeaveCriticalSection;
 end;
 
 procedure TAbstractExternalTool.ConsistencyCheck;


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


Bug#944323: RFS: piper/0.3-1 [ITP] -- graphical frontend for libratbag

2019-11-16 Thread Stephan Lachnit
Jonathan Carter pointed out, that I didn't add file specific copyright 
information in the copyright file. I uploaded a new version to mentors.

Regards,
Stephan



Bug#944855: dgit: History contains tainted commit -- but tags were accepted by the dgit server, making subsequent dgit push fail

2019-11-16 Thread Felipe Sateler
Package: dgit
Version: 9.9
Severity: normal

If one attempts to push a tainted history (because a package was
rejected from NEW, for example), one gets the "History contains tainted
commit" message. If the questionable history is OK, a dgit push with
--deliberately flag will fail with 

Made pseudo-merge of 2.1-2 into dgit view.

Version 2.1-3 has already been tagged (pushed?)
If this was a failed (or incomplete or rejected) upload by you, just
add a new changelog stanza for a new version number and try again.

dgit: error: Tag archive/debian/2.1-3 already exists.


I suppose dgit should remove the archive/foo tag if the push fails

-- 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 5.3.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, 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

Versions of packages dgit depends on:
ii  apt1.8.4
ii  ca-certificates20190110
ii  coreutils  8.30-3+b1
ii  curl   7.66.0-1+b1
ii  devscripts 2.19.7
ii  dpkg-dev   1.19.7
ii  dput-ng [dput] 1.28
ii  git [git-core] 1:2.24.0-1
ii  git-buildpackage   0.9.17
ii  libdpkg-perl   1.19.7
ii  libjson-perl   4.02000-1
ii  liblist-moreutils-perl 0.416-1+b5
ii  liblocale-gettext-perl 1.07-4
ii  libtext-csv-perl   2.00-1
ii  libtext-glob-perl  0.10-1
ii  libtext-iconv-perl 1.7-7
ii  libwww-curl-perl   4.17-6
ii  perl [libdigest-sha-perl]  5.30.0-9

Versions of packages dgit recommends:
ii  distro-info-data 0.43
ii  liburi-perl  1.76-1
ii  openssh-client [ssh-client]  1:8.1p1-1

Versions of packages dgit suggests:
ii  cowbuilder  0.88
ii  pbuilder0.230.4
ii  sbuild  0.78.1-2

-- no debconf information



Bug#890609: ocaml-native-compilers: Generates invalid assembly for arm64 when building hhvm

2019-11-16 Thread Ralf Treinen
Hi,

hhvm has been removed from sid on Thu, 20 Dec 2018. I suppose this means
that the bug can be closed?

-Ralf.



Bug#944838: xorg: after recent upgrade on two different machines, X no longer responds to kbd or mouse input

2019-11-16 Thread Ximin Luo
Control: affects -1 xorg
Control: severity -1 grave
Severity: grave
Justification: renders package unusable

Thanks, I also figured this out myself separately by running `libinput 
debug-events`, hopefully this helps someone else stumbling upon this strange 
behaviour in the future.

However I am still confused to on how I managed to fix it. On one machine (the 
AMDGPU one) `libinput debug-events --verbose` would complain about certain 
devices not being initialised by udev, including the keyboard device. Upgrading 
udev from version 243-5 to 243-7 and reloading udev by running `udevadm control 
--reload-rules && udevadm trigger` and then restarting lightdm worked. Perhaps 
this bug is related to #944586?

Then again, on the other machine (Intel graphics) it was sufficient to simply 
run `libinput debug-events --device $device`.

Oh and another thing for people wanting to play around with this, when you run 
`systemctl disable lightdm` and then fix the problem and then run `systemctl 
enable lightdm` the latter does not work for some stupid reason, even though 
the former command worked. You have to run `dpkg-reconfigure lightdm` to make 
it work again.

X

Sven Joachim:
> Control: reassign -1 udev 243-5
> Control: forcemerge 944675 -1
> 
> On 2019-11-16 03:45 +, Ximin Luo wrote:
> 
>> Package: xorg
>> Version: 1:7.7+20
>> Severity: important
>>
>> Dear Maintainer,
>>
>> After upgrading a bunch of packages on two very different machines, X no 
>> longer
>> responds to keyboard or mouse input.
>>
>> I am using lightdm with XFCE, the problem is present both in the lightdm 
>> login
>> menu and also in XFCE when using `startx` directly.
>>
>> Nothing obvious is in the kernel or system logs or Xorg.0.log.
> 
> That seems to be bug #944675 in udev.
> 
> Cheers,
>Sven
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Bug#944854: cyrus-common (3.0.8-6+deb10u1) skiplist Unknown type of DB: BACKUP

2019-11-16 Thread SheridanJ West
package: cyrus-common (3.0.8-6+deb10u1) ...


Rather ancient cyrus imap store upgraded many times and does like twoskip
option as of update released 16 nov 2019.


imap seems to still work and i enclose dbtypes.txt I do not edit/adjust
with the /usr/lib/cyrus/cyrus-db-types.txt file other than the dist upgrade
to buster on release


the issue in common then affects cyrus-* too


apt upgrade output


Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up cyrus-common (3.0.8-6+deb10u1) ...
Creating/updating cyrus user account...
The user `cyrus' is already a member of `sasl'.
/usr/lib/cyrus/bin/upgrade-db: Unknown type of DB: BACKUP
dpkg: error processing package cyrus-common (--configure):
installed cyrus-common package post-installation script subprocess returned
error exit status 1


cat /usr/lib/cyrus/cyrus-db-types.txt
ANNOTATION twoskip
BACKUP twoskip
CONVERSATIONS skiplist
DBENGINE BerkeleyDB5.3
DUPLICATE twoskip
MBOX twoskip
PTS twoskip
QUOTA quotalegacy
SEARCH_INDEXED twoskip
SEEN twoskip
SORTCACHE twoskip
STATUSCACHE twoskip
SUBS flat
TLS twoskip
USERDENY flat
ZONEINFO twoskip


dpkg: dependency problems prevent configuration of cyrus-clients:
cyrus-clients depends on cyrus-common (>= 3.0.8); however:
 Package cyrus-common is not configured yet.

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

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

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

dpkg: error processing package cyrus-nntpd (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
cyrus-common
cyrus-clients
cyrus-admin
cyrus-imapd
cyrus-nntpd
needrestart is being skipped since dpkg has failed


s j west


Bug#944853: calligra: FTBFS with Qt 5.12

2019-11-16 Thread Sandro Knauß
Source: calligra
Version: 1:3.1.0+dfsg-5
Severity: normal

Hey,

calligra can't be build anmore within the sid enviornment. It fails
with:

/<>/sheets/plugins/calendar/CalendarToolWidget.cpp:47:39:
error: incomplete type ‘QDate’ used in nested name specifier
   47 | QDate first_day_in_month = QDate::currentDate();

see
https://buildd.debian.org/status/fetch.php?pkg=calligra=amd64=1%3A3.1.0%2Bdfsg-5%2Bb2=1573859614=0

hefee

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

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


Bug#944852: libpython3.8-dbg: does not provide python-3.8-dbg-embed.pc

2019-11-16 Thread Simon McVittie
Package: libpython3.8-dbg
Version: 3.8.0-4
Severity: normal

python3.8 adds python-$(VER)-embed.pc, for use in programs and libraries
that embed Python, and python-$(VER)d-embed.pc, for use in programs and
libraries that embed the debug version of Python (in practice I suspect
this is mostly only used for automated tests).

python-$(VER)d.pc is symlinked as python-$(VER)-dbg.pc, which makes it
convenient to loop over all production and debug Python interpreters
with $(py3versions -sv), loop over appending either nothing or -dbg
to each one, and use python-${x}.pc and python${x} (where values of x
include for example 3.7 and 3.8-dbg) to build and run dependent code.

However, python-$(VER)d-embed.pc does not have a similar symlink.
Please consider adding python-$(VER)-dbg-embed.pc as a symlink pointing
to python-$(VER)d-embed.pc.

I noticed this while enhancing the pygobject tests to loop over all
supported interpreters (not just the default), to get a better idea of
whether the move to Python 3.8 as default is going to break it.

Thanks,
smcv



Bug#944838: xorg: after recent upgrade on two different machines, X no longer responds to kbd or mouse input

2019-11-16 Thread Sven Joachim
Control: reassign -1 udev 243-5
Control: forcemerge 944675 -1

On 2019-11-16 03:45 +, Ximin Luo wrote:

> Package: xorg
> Version: 1:7.7+20
> Severity: important
>
> Dear Maintainer,
>
> After upgrading a bunch of packages on two very different machines, X no 
> longer
> responds to keyboard or mouse input.
>
> I am using lightdm with XFCE, the problem is present both in the lightdm login
> menu and also in XFCE when using `startx` directly.
>
> Nothing obvious is in the kernel or system logs or Xorg.0.log.

That seems to be bug #944675 in udev.

Cheers,
   Sven



  1   2   >