Bug#922498: piglit: i386 workaround can be removed

[Adrian Bunk]

Source: piglit
Version: 0~git20180515-62ef6b0db-1
Severity: normal
Tags: patch

The gcc bug is fixed in gcc 8, so the following can be
applied to remove the i386 workaround:

--- debian/rules.old2019-02-15 21:40:30.777278651 +0200
+++ debian/rules2019-02-15 21:40:42.949278535 +0200
@@ -6,23 +6,6 @@
 %:
dh $@ --buildsystem cmake --with python3
 
-# workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364
-DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-ifneq (,$(filter $(DEB_HOST_ARCH), i386))
-export DEB_CFLAGS_MAINT_APPEND=-O1 -DNDEBUG
-
-override_dh_auto_configure:
-   dh_auto_configure -- \
-   -DCMAKE_INSTALL_PREFIX=/usr \
-   -DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-   -DPIGLIT_BUILD_GLES1_TESTS=1 \
-   -DPIGLIT_BUILD_GLES2_TESTS=1 \
-   -DPIGLIT_BUILD_GLES3_TESTS=1 \
-   -DPIGLIT_BUILD_CL_TESTS=1 \
-   -DPIGLIT_USE_WAFFLE=1
-
-else
-
 override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_INSTALL_PREFIX=/usr \
@@ -34,8 +17,6 @@
-DPIGLIT_BUILD_CL_TESTS=1 \
-DPIGLIT_USE_WAFFLE=1
 
-endif
-
 override_dh_auto_install:
dh_auto_install
find $(DEB_DESTDIR) -type d -name __pycache__ -exec rm -r {} +

Bug#922497: BUG: unable to handle kernel paging request at ffff9b30a7cb488

[Allan Wind]

Package: nvidia-driver
Version: 390.87-8~deb9u1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

The stable release 9.8 contained an upgrade of nvidia-drivers from 
384.130-1 to 390.87-8~deb9u1 which caused my system hang during
subsequent boots.  The release also contains a linux-image 
update, and I installed a known working kernel (4.9.0-5) and it 
too failed to boot with 390.87-8~deb9u1. Then I upgraded 
nividia-driver to the version in unstable, and I was able to boot 
my system.  Unfortunately, this is the version information being 
picked up in this bug report.


Here are an overview of the relevant traces from the crash with 
linux-image-4.9.0-8-amd64:amd64 4.9.144-3

and nvidia-driver 390.87-8~deb9u1:

2019-02-17T04:46:15.746+00:00 vent kernel: BUG: unable to handle kernel paging 
request at 9b30a7cb4880
2019-02-17T04:47:10.146+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 23s! [ps:1177]
2019-02-17T04:48:04.181+00:00 vent kernel: BUG: unable to handle kernel paging 
request at 9dab95bae880
2019-02-17T04:48:54.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 23s! [ps:1164]
2019-02-17T04:49:22.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 23s! [ps:1164]
2019-02-17T04:49:58.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:50:26.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:51:02.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:51:30.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:52:06.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:52:34.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 23s! [ps:1164]
2019-02-17T04:53:06.181+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#2 stuck for 22s! [ps:1164]
2019-02-17T04:58:46.294+00:00 vent kernel: BUG: unable to handle kernel paging 
request at 975a15bcc880
2019-02-17T04:59:37.347+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#5 stuck for 23s! [ps:1141]
2019-02-17T05:06:03.643+00:00 vent kernel: BUG: unable to handle kernel paging 
request at 9f8e15cdf880
2019-02-17T05:06:55.244+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#7 stuck for 23s! [ps:1137]
2019-02-17T05:07:23.244+00:00 vent kernel: NMI watchdog: BUG: soft lockup - 
CPU#7 stuck for 22s! [ps:1137]

and some selected traces:

2019-02-17T04:46:15.746+00:00 vent kernel: BUG: unable to handle kernel paging 
request at 9b30a7cb4880
2019-02-17T04:46:15.746+00:00 vent kernel: IP: [] 
_nv015088rm+0x614/0x780 [nvidia]
2019-02-17T04:46:15.746+00:00 vent kernel: PGD f5df34067 
2019-02-17T04:46:15.746+00:00 vent kernel: PUD 0 
2019-02-17T04:46:15.746+00:00 vent kernel: 
2019-02-17T04:46:15.746+00:00 vent kernel: Oops:  [#1] SMP

2019-02-17T04:46:15.746+00:00 vent kernel: Modules linked in: snd_seq_midi 
snd_seq_midi_event uvcvideo snd_usb_audio videobuf2_vmalloc hid_generic 
videobuf2_memops videobuf2_v4l2 videobuf2_core snd_usbmidi_lib snd_rawmidi 
videodev btusb btrtl media btbcm btintel bluetooth usbhid snd_hrtimer snd_seq 
snd_seq_device binfmt_misc nls_ascii nls_cp437 vfat fat arc4 thinkpad_acpi 
nvram intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp 
snd_hda_codec_realtek snd_hda_codec_generic kvm_intel iwlmvm 
i2c_designware_platform kvm i2c_designware_core irqbypass crct10dif_pclmul 
crc32_pclmul mac80211 snd_hda_intel efi_pstore joydev ghash_clmulni_intel 
pcspkr snd_hda_codec serio_raw efivars iwlwifi snd_hda_core snd_hwdep snd_pcm 
rtsx_pci_ms iTCO_wdt snd_timer iTCO_vendor_support snd soundcore idma64 
cfg80211 memstick mei_me rfkill mei intel_lpss_pci
2019-02-17T04:46:15.746+00:00 vent kernel:  intel_lpss shpchp battery ac evdev 
acpi_pad nvidia_drm(PO) drm_kms_helper drm nvidia_modeset(PO) nvidia(PO) 
ipmi_msghandler parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 
ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache rtsx_pci_sdmmc mmc_core 
crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd 
psmouse e1000e ptp i2c_i801 xhci_pci pps_core i2c_smbus rtsx_pci xhci_hcd nvme 
mfd_core nvme_core usbcore usb_common thermal wmi video i2c_hid hid button
2019-02-17T04:46:15.750+00:00 vent kernel: CPU: 5 PID: 704 Comm: irq/327-nvidia 
Tainted: P   O4.9.0-8-amd64 #1 Debian 4.9.144-3
2019-02-17T04:46:15.750+00:00 vent kernel: Hardware name: LENOVO 
20HHCTO1WW/20HHCTO1WW, BIOS N1UET37W (1.11 ) 07/24/2017
2019-02-17T04:46:15.750+00:00 vent kernel: task: 9b1ca9d9f080 task.stack: 
c1a8d0a1c000
2019-02-17T04:46:15.750+00:00 vent kernel: RIP: 0010:[]  
[] _nv015088rm+0x614/0x780 [nvidia]
2019-02-17T04:46:15.750+00:00 vent kernel: RSP: 0018:c1a8d0a1fcc8  EFLAGS: 
00010246
2019-02-17T04:46:15.750+00

Bug#922496: GCC 9: gnat ftbs on kfreebsd-*

[Matthias Klose]

Package: src:gcc-9
Version: 9-20190216-2
Tags: important
Severity: sid bullseye

ftbfs, and we still have local, not forwarded patches for kfreebsd.

s-tpopmo.adb:61:25: expected private type "System.Os_Interface.clockid_t"
s-tpopmo.adb:61:25: found type universal integer
s-tpopmo.adb:76:34: expected private type "System.Os_Interface.clockid_t"
s-tpopmo.adb:76:34: found type universal integer
../gcc-interface/Makefile:299: recipe for target 'a-dispat.o' failed
make[8]: *** [a-dispat.o] Error 1
make[8]: Leaving directory '/<>/build/gcc/ada/rts'
gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
make[7]: *** [gnatlib] Error 2
make[7]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
make[6]: *** [gnatlib-shared-dual] Error 2
make[6]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
make[5]: *** [gnatlib-shared] Error 2
make[5]: Leaving directory '/<>/build/gcc/ada'
Makefile:104: recipe for target 'gnatlib-shared' failed
make[4]: *** [gnatlib-shared] Error 2

Bug#681714: smokeping - off-by-one error on graph time axis

[Gabriel Filion]

Hi James,

I'm sorry to be reviving such an old report. I'm current helping out
with maintenance of this package and I'm trying to clear out as many
bugs as possible.

On Sun, 15 Jul 2012 13:57:31 -0600 ja...@nurealm.net wrote:
> The chart data seem to be displayed "off-by-one", with the most recent 5min
> measurement shown covering the earlier 10min to earlier 5min time period, and
> with the most recent time period shown blank, when using 5min updates.  The
> data is shown 5min earlier than the actual time.
> 
> This is especially a problem when setting-up smokeping "targets" for the first
> time and wondering if new configuration is correct and working, where it may
> appear that no measurement was made or recorded for the current time period.

I believe the behavior you mentioned is normal. since measurements are
done only every once in a while, the most recent period is almost always
empty. so once you do get results on the graph, it means that it was
already measured and it's not necessarily what is happening right now.

Tell me if I misunderstood your inquiry. I will close this bug report in
one week if I get no response.

Cheers!



signature.asc
Description: OpenPGP digital signature

Bug#834331: test code fails and ignored for ibus

[Osamu Aoki]

Hi,

I just build 1.5.19-4.

Even with XDG_RUNTIME_DIR patch from Simon, test fails.

For the sake of having useful piece of package, I keep disabling test
code.

Anyway, here is a log:

...
make[5]: Nothing to be done for 'check-am'.
make[5]: Leaving directory '/build/ibus-1.5.19/src'
Making check in tests
make[5]: Entering directory '/build/ibus-1.5.19/src/tests'
make  check-TESTS
make[6]: Entering directory '/build/ibus-1.5.19/src/tests'
make[7]: Entering directory '/build/ibus-1.5.19/src/tests'
FAIL: ibus-bus
FAIL: ibus-config
FAIL: ibus-factory
FAIL: ibus-configservice
FAIL: ibus-inputcontext
FAIL: ibus-inputcontext-create
FAIL: ibus-registry
FAIL: ibus-keynames
FAIL: ibus-serializable
FAIL: ibus-share
FAIL: ibus-util
FAIL: ibus-engine-switch
FAIL: ibus-compose
FAIL: ibus-keypress
===
   ibus 1.5.19: src/tests/test-suite.log
===

# TOTAL: 14
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  14
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: ibus-bus
==

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-bus (exit status: 2)

FAIL: ibus-config
=

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-config (exit status: 2)

FAIL: ibus-configservice


./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-configservice (exit status: 2)

FAIL: ibus-factory
==

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-factory (exit status: 2)

FAIL: ibus-inputcontext
===

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-inputcontext (exit status: 2)

FAIL: ibus-inputcontext-create
==

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-inputcontext-create (exit status: 2)

FAIL: ibus-keynames
===

./runtest: 113: ./runtest: pushd: not found
./runtest: 177: ./runtest: .././ibus-keynames: not found
./runtest: 181: ./runtest: popd: not found
FAIL ibus-keynames (exit status: 127)

FAIL: ibus-registry
===

./runtest: 113: ./runtest: pushd: not found
./runtest: 177: ./runtest: .././ibus-registry: not found
./runtest: 181: ./runtest: popd: not found
FAIL ibus-registry (exit status: 127)

FAIL: ibus-serializable
===

./runtest: 113: ./runtest: pushd: not found
./runtest: 177: ./runtest: .././ibus-serializable: not found
./runtest: 181: ./runtest: popd: not found
FAIL ibus-serializable (exit status: 127)

FAIL: ibus-share


./runtest: 113: ./runtest: pushd: not found
./runtest: 177: ./runtest: .././ibus-share: not found
./runtest: 181: ./runtest: popd: not found
FAIL ibus-share (exit status: 127)

FAIL: ibus-util
===

./runtest: 113: ./runtest: pushd: not found
./runtest: 177: ./runtest: .././ibus-util: not found
./runtest: 181: ./runtest: popd: not found
FAIL ibus-util (exit status: 127)

FAIL: ibus-engine-switch


./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-engine-switch (exit status: 2)

FAIL: ibus-compose
==

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-compose (exit status: 2)

FAIL: ibus-keypress
===

./runtest: 113: ./runtest: pushd: not found
NOT FOUNND ibus-memconf. Need configure --enable-memconf
./runtest: 125: exit: Illegal number: -1
FAIL ibus-keypress (exit status: 2)


Testsuite summary for ibus 1.5.19

# TOTAL: 14
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  14
# XPASS: 0
# ERROR: 0

See src/tests/test-suite.log
Please report to https://github.com/ibus/ibus/issues

make[7]: *** [Makefile:1084: test-suite.log] Error 1
make[7]: Leaving directory '/build/ibus-1.5.19/src/tests'
make[6]: *** [Makefile:1192: check-TESTS] Error 2
make[6]: Leaving directory '/build/ibus-1.5.19/src/tests'
make[5]: *** [Makefile:1356: check-am] Error 2
make[5]: Leaving directory '/build/ibus-1.5.19/src/tests'
make

Bug#922349: eatmydata: ld.so “secure-execution mode” considerations?

[Aurelien Jarno]

On 2019-02-16 19:43, Thorsten Glaser wrote:
> Hi Aurelien,
> 
> […]
> >All the above are purely hypothetical cases and I do not have a good
> 
> Thanks for the insight, you have me understanding your point.
> 
> These were about eatmydata in particular, do you have any
> insight on the other?

I don't really know what the other is trying to achieve and I haven't
reviewed its code, so and I can't say anything.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Michael Welsh Duggan]

Markus Koschany  writes:

> Hello Michael,
>
>
> On Fri, 18 Jan 2019 01:19:36 -0500 Michael Welsh Duggan 
> wrote:
>> Package: solr-tomcat
>> Version: 3.6.2+dfsg-16
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> After updating tomcat to tomcat9 and solr-tomcat to 3.6.2+dfsg-16, it
>> seems to be having problems writing to its index directory.  The
>> problem surfaced when using dovecot to look up messages.  Attached is
>> the error from the catalina log.
>> 
>> /var/lib/solr/index does look like it has the right permissions:
>> /var/lib/solr/data and /var/lib/solr/data/index are owned by
>> tomcat:tomcat, permissions 770, and tomcat seems to be running as user
>> tomcat.  I have verified that I can write to the directory as root,
>> and as such it's not on a read-only filesystem.  I have no idea why it
>> fails to write the lock file.
>
> Could you try the following?
>
> Please copy the tomcat9.service file to /etc/systemd/system and modify
> it by adding
>
> ReadWritePaths=/var/lib/solr/
> ReadWritePaths=/var/lib/solr/data
>
> to the # Security paragraph. Then execute systemctl daemon-reload.
>
> This should whitelist the solr directories and writing to them should be
> possible again. This is caused by restrictive systemd settings like
> ProtectSystem=strict. I think Debian's tomcat9 package could allow this
> by default but we could probably add a NEWS and README file to
> solr-tomcat too and explain the steps to make it work.

Based on your prior tip, I had already done that.  (Only the
/var/lib/solr/ entry seemed to be necessary.)  This caused things to
work again.

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

[Hans van Kranenburg]

On 2/17/19 12:27 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Feb 16, 2019 at 10:36:00PM +0100, Hans van Kranenburg wrote:
>> Actually, while looking at this again...
>>
>> In the init script, we already have...
>>
>> capability_check()
>> {
>> [ -e "/proc/xen/capabilities" ] || return 1
>> grep -q "control_d" /proc/xen/capabilities || return 1
>> return 0
>> }
>>
>> ...which gets called like this...
>>
>> capability_check
>> case "$?" in
>> 0) ;;
>> *) log_end_msg 255; exit ;;
>> esac
>>
>> Looking at /proc/xen/capabilities and seeing if there's control_d inside
>> seems to be a more common way to check if this is a dom0.
>>
>> It does log_end_msg 255 and 255 seems to be warning.
> 
> systemd doesn't agree:
> 
> Setting up xen-utils-common (4.11.1-2~) ...
> (...)
> Job for xen.service failed because the control process exited with error 
> code.
> See "systemctl status xen.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript xen, action "restart" failed.
> ● xen.service - LSB: Xen daemons
>Loaded: loaded (/etc/init.d/xen; generated)
>Active: failed (Result: exit-code) since Sat 2019-02-16 18:16:04 EST; 
> 6ms ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 7215 ExecStart=/etc/init.d/xen start (code=exited, 
> status=255/EXCEPTION)

Hah! Yes, of course, because the exit without code will use the return
code of the previous command instead of 0. I forgot about that.

> Feb 16 18:16:04 d10test systemd[1]: Starting LSB: Xen daemons...
> Feb 16 18:16:04 d10test xen[7215]: Starting Xen daemons: (warning).
> Feb 16 18:16:04 d10test systemd[1]: xen.service: Control process exited, 
> code=exited, status=255/EXCEPTION
> Feb 16 18:16:04 d10test systemd[1]: xen.service: Failed with result 
> 'exit-code'.
> Feb 16 18:16:04 d10test systemd[1]: Failed to start LSB: Xen daemons.
> dpkg: error processing package xen-utils-common (--configure):
>  installed xen-utils-common package post-installation script subprocess 
> returned error exit status 1
> 
> Full output: https://gist.github.com/marmarek/f6964e16157e69f5761e68ea1a925ae7
> 
>> The upstream init script has...
>>
>> # run this script only in dom0:
>> # no capabilities file in xenlinux domU kernel
>> # empty capabilities file in pv_ops domU kernel
>> if test -f /proc/xen/capabilities && \
>>! grep -q "control_d" /proc/xen/capabilities ; then
>> exit 0
>> fi
>>
>> ...which also doesn't look really good, since this exit 0 doesn't happen
>> when /proc/xen/capabilities does *not* exist, and the first domU I'm
>> looking inside here doesn't have it.
> 
> Generally I (too?) try to migrate away from /proc/xen, that's why my
> patch use /sys/hypervisor/uuid instead.

Ok, I don't know too much about all the xen things in /proc and /sys
yet, but it seems the current check for a dom0 does its work, so let's
not change that right now.

But, change it to just exit 0. I added a change on top of the wip.testme
branch.

https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme

Thanks,
Hans

Bug#922495: [armel/marvell] linux-image-4.19.0-2-marvell: please enable CONFIG_ZSWAP and CONFIG_Z3FOLD (and CONFIG_ZBUD) on armel

[Rogério Brito]

Package: src:linux
Version: 4.19.16-1
Severity: wishlist


Please, enable CONFIG_ZSWAP and its suboptions Z3FOLD and ZBUD.

They are specially important for systems that are very constrained with
memory (in the particular case, a NAS box with 128MB of RAM).

Roger removed them when we were looking to shrink the size of the armel
kernels, but, IIRC, these options were not guilty of bloating the kernel.

I can provide a patch if necessary.


Thanks,

Rogério Brito.


-- Package-specific info:
** Version:
Linux version 4.19.0-2-marvell (debian-ker...@lists.debian.org) (gcc
version 8.2.0 (Debian 8.2.0-14)) #1 Debian 4.19.16-1 (2019-01-17)

** Command line:
console=ttyS0,115200 zswap.enabled=1

** Not tainted

** Kernel log:
[729332.189907] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.189951] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.189995] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190039] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190086] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190131] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190175] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190348] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190392] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190437] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190481] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190524] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190569] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190613] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190657] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190701] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190745] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190793] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190836] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190880] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190924] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.190968] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191013] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191057] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191101] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191145] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191190] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191236] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191281] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191325] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191369] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191414] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191458] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191502] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191546] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191590] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191635] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191681] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to
linearize skb with tiny unaligned fragment
[729332.191725] mv643xx_eth_port mv643xx_eth_port.0

Bug#922019: cdimage.debian.org: Non-free live builds missing contrib and non-free components

[Daniel Lewart]

Steve,

> Right, that's as expected. The only non-free bit about those images is
> that they include some non-free firmware packages too. Otherwise
> they're just the same as the normal free images. Is there a problem
> with that?

Yes, a minor one.  Especially for Buster, I expect "apt update; apt upgrade"
to install available upgrades for all packages, including firmware.

Thank you!
Dan

Bug#856595:

[Pavel Minaev]

It looks like all the dependencies are now in Buster, thanks to Kunal. It
would be a shame to have it all, except for the actual user-facing app that
uses it...

Is there any chance that this package might make it into Buster? Is there
any assistance I could provide to accelerate the process?

Bug#804552: API reference mostly empty

[Dato]

found 804552 0.23.3-1
severity 804552 important
retitle 804552 Pandas documentation package is empty
thanks

$ dpkg -L python-pandas-doc
/usr/share/doc/python-pandas-doc
/usr/share/doc/python-pandas-doc/AUTHORS.md
/usr/share/doc/python-pandas-doc/README.md.gz
/usr/share/doc/python-pandas-doc/RELEASE.md
/usr/share/doc/python-pandas-doc/changelog.Debian.gz
/usr/share/doc/python-pandas-doc/copyright
/usr/share/doc/python-scikits-learn-doc
/usr/share/doc/python-scikits-learn-doc/html
/usr/share/doc/python-scikits-learn-doc/html/_static
/usr/share/doc/python-scikits-learn-doc/html/_static/jquery.js

Bug#917318: fixed in ruby-ronn 0.8.0-1

[Andrew Janke]

Hi, Debian folks. Ronn-ng maintainer here. Thanks for picking up my fork!

Feel free to let me know if there's anything I can do to make packaging 
easier for you folks, either by email at fl...@apjanke.net or at 
https://github.com/apjanke/ronn-ng/issues/21.


In particular, I'm interested in maybe pulling in your patches upstream. 
I don't think I can do the gem rename because of ownership/permissions 
at RubyGems.org. But maybe the others.


$SOURCE_DATE_EPOCH is new to me. I'm reading the doco now. Do you think 
this would be appropriate for me to support directly in Ronn-NG so that 
other distros or environments could use it?


I'm a little surprised that the patch to relax gem dependency versions 
was necessary. I thought that e.g. "'~> 0.7', '>= 0.7.0'" would require 
"a version starting with 0.7, using SemVer-style versioning, and greater 
than or equal to 0.7.0", basically requiring 0.7.*. Are you doing this 
relaxation because you want to potentially use later minor versions, 
like mustache 0.8.* or nokogiri 1.10.* or 2.*, and these gems are all 
installed in a global library space?


Cheers,
Andrew

Bug#919058: itstool bug bisection

[Lars Skovlund]

Redhat now have this bug in their bug tracker. Given that the itstool author 
seems to
either be or have been a Redhat employee at some point, I guess this is good.

https://bugzilla.redhat.com/show_bug.cgi?id=1677838

Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method

[Andrew Janke]

I've confirmed this is the https://github.com/apjanke/ronn-ng/issues/24 
bug in ronn-ng.


It looks liike an easy fix and I have pushed a ronn-ng 0.8.1.beta.1 
gem/release with the fix. Are you able to test against a prerelease gem?


I've tested locally and it fixed the problem for git-lfs man generation. 
I've also added an ordered-list example to Ronn-NG's internal test suite.


Cheers,
Andrew

Bug#899337: closed by Dominique Dumont (Bug#899337: fixed in libconfig-model-dpkg-perl 2.114)

[Guillem Jover]

Control: found -1 2.121

Hi!

On Sun, 2018-07-15 at 15:39:03 +, Debian Bug Tracking System wrote:
> Source: libconfig-model-dpkg-perl
> Source-Version: 2.114
> 
> We believe that the bug you reported is fixed in the latest version of
> libconfig-model-dpkg-perl, which is due to be installed in the Debian FTP 
> archive.

Unfortunately, only part of the bug was fixed. :)

> Format: 1.8
> Date: Sun, 15 Jul 2018 16:53:53 +0200
> Source: libconfig-model-dpkg-perl
> Binary: libconfig-model-dpkg-perl
[…]
> Changes:
>  libconfig-model-dpkg-perl (2.114) unstable; urgency=medium
>  .
>* Store my_config in ~/.config/config-model/dpkg-meta.yml.
>  dpkg-meta data from old locations (~/.dpkg-meta.yaml and
>  ~/.local/share/.dpkg-meta.yml) are migrated and the old
>  files are removed. (Closes: 899337)
[…]


> Date: Wed, 23 May 2018 02:52:13 +0200
> From: Guillem Jover 
> To: sub...@bugs.debian.org
> Subject: libconfig-model-dpkg-perl: Please use XDG paths for user config
>  and cache files
> Message-ID: <20180523005213.ga14...@gaara.hadrons.org>
> User-Agent: Mutt/1.9.5 (2018-04-13)
> X-Spam-Status: No, score=-26.5 required=4.0 tests=ALL_TRUSTED,BAYES_00,
>  FROMDEVELOPER,HAS_PACKAGE,TXREP autolearn=ham autolearn_force=no
>  version=3.4.1-bugs.debian.org_2005_01_02
> 
> Package: libconfig-model-dpkg-perl
> Version: 2.111
> Severity: wishlist
> User: guardi...@namespace.hadrons.org
> Usertags: homespace-rift

> This package by default stores cache file directly under ~/, named as
> «.config_model_depend_cache», and its config in either ~/.dpkg-meta.yml
> or ~/.local/share/.dpkg-meta.yml. It would be nice if these could default
> instead to the XDG basedir cache and config directories [X], using
> properly namespaced paths, so that we can get a clean home directory. :)
> 
> The namespace would be ideally something like:
> 
>   ${XDG_CONFIG_HOME:-~/.config}/config-model/dpkg-meta.yml
>   ${XDG_CACHE_HOME:-~/.cache}/config-model/dpkg-depend.cache
> 
> or something along those lines (File::HomeDir does have support for
> my_config and my_cache methods on FreeDesktop supporting platforms).
> The current usage of ~/.local/share/ seems wrong, both for the chosen
> path and for using a dot dir within.
> 
> Given that actually moving these files around might be considered tricky,
> if taking into account shared home directories, or backwards compatibility,
> I think reading both XDG and legacy directories in that order, by default
> would be fine.
> 
> [X] 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Although the config file got handled, the cache file did not.

Thanks,
Guillem

Bug#919115: linux-image-4.19.0-0.bpo.1-amd64-unsigned: Graphical glitches (lightdm and cinnamon) after upgrading linux (RadeonRX540)

[N G]

Today I tested this laptop with testing and unstable branch, all 
defaults, no personalized parameters or configurations.

About lightdm graphical glitches: Couldn't reproduce any hang, frozen 
frame, or 'black screen' when using testing or unstable branch. 
(firmware seems to be related, will test stretch with 
firmware-amd-graphics-20190114 when available), every animation is 
properly refreshed, from typing to menus.

About wallpaper issues: When using testing or unstable branch I couldn't 
reproduce any graphical glitches in wallpapers (neither cinnamon or 
lightdm) seems related to firmware as well.

About Cinnamon's lockscreen: Still buggy in both testing and unstable, 
although linux-image-4.19.0-3-amd64 is definitely smoother compared to 
4.19.0-2 (stretch,testing), cinnamon's lockscreen doesn't seem to 
refresh in real time, and it rather refreshes itself every 5 seconds 
exactly (easy to check with the lockscreen's clock). With stretch it 
doesn't refreshes at all so it looks like a black screen (like what 
happens with lightdm/stable), but it's actually running fine if you type 
the password (avoiding typos while typing blind), it's just that there's 
no graphical refreshing (to put in in my own terms lol).

Since amdgpu.dc it's enabled by default, an old issue with redshift not 
lowering the cursor's temperature color, it's as well fixed.

I do see some weird lines appearing and disappearing in the top right 
corner of my screen and some other areas, but I guess it's fine since 
it's unstable branch.


This laptop (acer with a12-9720p, radeon rx 540) works awful with linux 
btw, Acer doesn't care, neither AMD, sadly I might be returning it / 
selling it, next month.

Thanks for the help, sorry for any typos.

Bug#922166: linux-image-4.19.0-0.bpo.2-amd64-unsigned: [regression] Touchpad doesn't work unless set to 'Basic' from BIOS

[N G]

 >This is working correctly with linux-image-4.19.0-0.bpo.3-amd64 from sid.

I sent this from my secondary email by mistake, sorry.

Bug#922494: kernel-package: Tries to copy nonexistent ChangeLog file

[Guillem Jover]

Package: kernel-package
Version: 13.018+nmu1
Severity: minor

Hi!

The make-kpkg program tries to copy its ChangeLog file into the
generated package, but that file does not exist. This is the error
message printed:

  ,---
  cp: cannot stat '/usr/share/kernel-package/ChangeLog': No such file or 
directory
  `---

Thanks,
Guillem

Bug#922493: kernel-package: Uses obsolete dpkg-gencontrol option

[Guillem Jover]

Package: kernel-package
Version: 13.018+nmu1
Severity: normal

Hi!

The make-kpkg program calls dpkg-gencontrol with the deprecated -isp
option, which by now prints a warning. Please stop using it.

Thanks,
Guillem

Bug#922492: kernel-package: Hardcodes kernel config location

[Guillem Jover]

Package: kernel-package
Version: 13.018+nmu1
Severity: wishlist

Hi!

The make-kpkg program hardcodes the location of the kernel
configuration as «.config», but the kbuild system can be told to use
a different config file via the KCONFIG_CONFIG environment variable,
so it woulbe be nice to use that if it's set.

Thanks,
Guillem

Bug#922166: linux-image-4.19.0-0.bpo.2-amd64-unsigned: [regression] Touchpad doesn't work unless set to 'Basic' from BIOS

[Felipe Gaitán]

This is working correctly with linux-image-4.19.0-0.bpo.3-amd64 from sid.

Bug#922420: got an unexpected keyword argument 'bg'

[Ben Finney]

On 15-Feb-2019, Enrico Zini wrote:
> It looks like --background has been added to the command line
> parser, but not to the function arguments to which the command line
> parser result is sent.

The code changes from version “1.2” → “1.4” includes a bunch of
changes related to the ‘--background’ option. The change log
unfortunately does not describe what behaviour change this is meant to
have.

So maybe, though upstream has not described any change to this effect,
the bug has been fixed? Can you try again with version “1.4-1”, now in
Debian?

-- 
 \  “People demand freedom of speech to make up for the freedom of |
  `\   thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature

Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method

[Andrew Janke]

Hi folks. ronn-ng maintainer here. I've prioritized this bug since it's 
causing problems for Debian package builds.


Cheers,
Andrew Janke

Bug#922393: reportbug: please specify the installed packages architecture

[Sandro Tosi]

> In a world where multi-arch is relevant, reportbug should list the
> architectures a a package is installed. As you can see below, the
> package list does not have architecture qualifiers. While normally not
> relevant, they do provide useful information, as would have been in #922350.

you're suggesting to add a 4th column with the architecture of the
package, correct?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#922164: fetchmail: With buster :fetchmail: Erreur de login ou d'identification inconnue pour xx...@pop.free.fr

[Gérard ROBIN]

Thanks 6.4.0 works fine now in my buster box with fetchmail --ssl  

-- 
Gerard

Bug#922491: ITP: ffcast -- Screenshot & screencast command line tool

[aeliton]

Package: ffcast
Version : 2.5.0
Author : lolilolicon 
URL : https://github.com/lolilolicon/ffcast
License : GPL-3

Description : FFcast is a command line too for taking screenshots and recording 
screen regions of with really simple and useful interface. 

It depends on: Bash 4.3+, FFmpeg (png rec), ImageMagick (trim), xdpyinfo (-x), 
xprop (-f),xrectsel[1] (-s), xwininfo (-w).
[1] https://github.com/lolilolicon/xrectsel

Aeliton G. Silva

Bug#922489: qtkeychain: relies on existence of libsecret-1.so -dev symlink

[Simon McVittie]

Control: reassign -1 qtkeychain 0.9.1-1
Control: retitle -1 qtkeychain: relies on existence of libsecret-1.so -dev 
symlink

On Sun, 17 Feb 2019 at 00:21:55 +0100, Sandro Knauß wrote:
> qtkeychain is using libsecret as a backend to request passwords. ldd is
> showing me that it is linked against libsecret-1.so.0 (fine). But strace
> shows one sucessfull read of libsecret-1.so.0 (fine) but afterwards, it
> tries to load libsecret-1.so without success (as libsecret-1-dev is not
> installed). If I create this symlink from libsecret-1.so ->
> libsecret-1.so, qtkeychain can load/store successfully passwords.

Sorry, this is not how shared libraries are packaged in
Debian. libsecret-1-0 must not contain the libsecret-1.so symlink. If it
did, it would not be co-installable with a future libsecret-1-1, defeating
a large part of the purpose of having an ABI version in the name.
(See Debian Policy §8.)

> For me this looks like an error in libsecret, as qtkeychain only imports
> libsecret/secret.h in libsecret.cpp [0]. Or maybe the usage in that file
> is wrong or cmake screws things up...

I think this is a qtkeychain bug. This code that appears to be responsible
for dlopen()ing libsecret:

LibSecretKeyring::LibSecretKeyring()
: QLibrary("secret-1")

doesn't mention the ABI version, so it could equally easily end up loading
an incompatible future library libsecret-1.so.1 or libsecret-1.so.27,
and then crashing when it calls a function by assuming that it has the
same ABI as the corresponding function in libsecret-1.so.0.

I haven't programmed against Qt for years, but the documentation
suggest that it should probably inherit from QLibrary("secret-1", 0)
as described at ,
so that Qt will specifically load libsecret-1.so.0 on Unix platforms.

smcv

Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[Simon McVittie]

On Sun, 17 Feb 2019 at 00:18:54 +0100, W. Martin Borgert wrote:
> (Just for myself in order to not forget it,) the six
> GLib-2.0.gir variants are:
> 
>  - amd64
>  - armel, armhf, i386, mipsel
>  - arm64, mips64el, ppc64el
>  - hurd-i386
>  - mips
>  - s390x
> 
> The differences are e.g. in how/whether GDoubleIEEE754,
> GFloatIEEE754, G_VA_COPY_AS_ARRAY, GLIB_SIZEOF_LONG (4 vs 8
> bytes), GUINTPTR_FORMAT (lu vs. u) etc. are defined.

I suspect those should perhaps just not be in the GIR - they aren't
really information that is going to benefit a program in Python or
JavaScript.

> On 2019-02-16 17:02, Simon McVittie wrote:
> > The program that generates GIR (g-ir-scanner) is architecture-independent
> > Python code, so it's easy to say "gobject-introspection should look in
> > its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
> > probably harder to actually implement than you might think.
> 
> I found only one .gir file under $libdir in sid, only for ppc:
> 
> /usr/lib/powerpc-linux-gnu/mutter/ClutterX11-1.0.gir
> /usr/lib/powerpc-linux-gnu/mutter/Clutter-1.0.gir

This is Mutter's private fork of Clutter, deliberately installed outside
the normal search paths. Only a small group of cooperating packages
(basically Mutter and GNOME Shell) should be looking here.
Those same packages need to set a special rpath or LD_LIBRARY_PATH to
load the libraries.

> > One option for fixing this for buster, if it is considered to be urgent,
> > is to investigate what the difference is and whether it can be eliminated,
> > perhaps by wrapping the code that differs between architectures in
> > #ifndef __GI_SCANNER__.
> 
> Sorry, here you lost me: In which code do you like to see the
> conditionals? In glib?

Maybe? Whatever code the architecture-dependent definitions come from.

For context, normally the GIR XML is produced by g-ir-scanner while
building a GLib-based library (let's say GTK), by scanning its source
code and maybe binaries. g-ir-scanner ignores anything wrapped in
#ifndef __GI_SCANNER__, which is usually used for weird cpp constructs
that confuse its somewhat simplistic C parser, but can also be used
for things that aren't representable or useful in non-C languages.

However, GLib is a special case - GObject-Introspection depends on
GLib, so it would be annoyingly circular to have GLib build-depend on
GObject-Introspection, and instead the GIR XML for GLib itself is built
by the gobject-introspection source package (not the glib2.0 source
package as it would usually be). I'm not sure precisely how that special
case works.

> > Another is to remove the M-A: same annotation.
> 
> I like to be able to cross-build certain packages. For my
> usecase, I have to install libgirepository1.0-dev for multiple
> architectures, because the package depends on it.

Sure, but a package not being co-installable is a less serious bug, with
a more difficult and more intrusive solution, than a package claiming
to be co-installable but not achieving it.

smcv

Bug#922488: linux-image-4.9.0-8-amd64: Kernel panic in IPv6 stack after some hours of operation

[Ralf Jung]

Oh, I should probably also mention that these machines all run an extra kernel
module compiled via dkms: batman-adv 2019.0 from .
The same kernel module also runs on a fourth machine with the same setup, but
which hasn't gotten the kernel update yet, and that machine runs stable.

; Ralf

Bug#922489: libsecret-1-0: needs symlink to libsecret-1.so

[Sandro Knauß]

Control: severity -1 serious
Control: affects -1 libqt5keychain

I raise the severity to serious, as this bug makes it impossible to use the 
libsecret backend of qtkeychain (that was working before). And it affects every 
application that uses qtkeychain on a GNOME, MATE,XFCE desktop.

hefee

--
On Sonntag, 17. Februar 2019 00:21:55 CET Sandro Knauß wrote:
> Package: libsecret-1-0
> Version: 0.18.7-1
> Severity: normal
> 
> Hey,
> 
> qtkeychain is using libsecret as a backend to request passwords. ldd is
> showing me that it is linked against libsecret-1.so.0 (fine). But strace
> shows one sucessfull read of libsecret-1.so.0 (fine) but afterwards, it
> tries to load libsecret-1.so without success (as libsecret-1-dev is not
> installed). If I create this symlink from libsecret-1.so ->
> libsecret-1.so, qtkeychain can load/store successfully passwords.
> 
> For me this looks like an error in libsecret, as qtkeychain only imports
> libsecret/secret.h in libsecret.cpp [0]. Or maybe the usage in that file
> is wrong or cmake screws things up...
> 
> My testsystem is a vagrant with a VirtualBox with only task-xfce-desktop and
> nextcloud-desktop installed. I enabled to load GNOME startup scripts for
> the XFCE environment.
> 
> hefee
> 
> [0] https://sources.debian.org/src/qtkeychain/0.9.1-1/libsecret.cpp/
> 
> -- System Information:
> Debian Release: buster/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 4.19.0-3-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
> 
> Versions of packages libsecret-1-0 depends on:
> ii  libc6 2.28-7
> ii  libgcrypt20   1.8.4-5
> ii  libglib2.0-0  2.58.3-1
> ii  libsecret-common  0.18.7-1
> 
> libsecret-1-0 recommends no packages.
> 
> libsecret-1-0 suggests no packages.
> 
> -- no debconf information




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

Bug#920984: nextcloud-desktop: Client forgets credentials

[Sandro Knauß]

Hey,

I found now a workaround for the issue of not detecting credentials.

Just create this symlink:

ln -s /usr/lib/x86_64-linux-gnu/libsecret-1.so.0 
/usr/lib/x86_64-linux-gnu/libsecret-1.so

But please keep in mind, it is just a workaround - it may break you system 
later.

Otherwise I created a bug at libsecret: 922489 for folling a propper solution.

hefee

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

Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

[Marek Marczykowski-Górecki]

On Sat, Feb 16, 2019 at 10:36:00PM +0100, Hans van Kranenburg wrote:
> Actually, while looking at this again...
> 
> In the init script, we already have...
> 
> capability_check()
> {
> [ -e "/proc/xen/capabilities" ] || return 1
> grep -q "control_d" /proc/xen/capabilities || return 1
> return 0
> }
> 
> ...which gets called like this...
> 
> capability_check
> case "$?" in
> 0) ;;
> *) log_end_msg 255; exit ;;
> esac
> 
> Looking at /proc/xen/capabilities and seeing if there's control_d inside
> seems to be a more common way to check if this is a dom0.
> 
> It does log_end_msg 255 and 255 seems to be warning.

systemd doesn't agree:

Setting up xen-utils-common (4.11.1-2~) ...
(...)
Job for xen.service failed because the control process exited with error 
code.
See "systemctl status xen.service" and "journalctl -xe" for details.
invoke-rc.d: initscript xen, action "restart" failed.
● xen.service - LSB: Xen daemons
   Loaded: loaded (/etc/init.d/xen; generated)
   Active: failed (Result: exit-code) since Sat 2019-02-16 18:16:04 EST; 
6ms ago
 Docs: man:systemd-sysv-generator(8)
  Process: 7215 ExecStart=/etc/init.d/xen start (code=exited, 
status=255/EXCEPTION)

Feb 16 18:16:04 d10test systemd[1]: Starting LSB: Xen daemons...
Feb 16 18:16:04 d10test xen[7215]: Starting Xen daemons: (warning).
Feb 16 18:16:04 d10test systemd[1]: xen.service: Control process exited, 
code=exited, status=255/EXCEPTION
Feb 16 18:16:04 d10test systemd[1]: xen.service: Failed with result 
'exit-code'.
Feb 16 18:16:04 d10test systemd[1]: Failed to start LSB: Xen daemons.
dpkg: error processing package xen-utils-common (--configure):
 installed xen-utils-common package post-installation script subprocess 
returned error exit status 1

Full output: https://gist.github.com/marmarek/f6964e16157e69f5761e68ea1a925ae7

> The upstream init script has...
> 
> # run this script only in dom0:
> # no capabilities file in xenlinux domU kernel
> # empty capabilities file in pv_ops domU kernel
> if test -f /proc/xen/capabilities && \
>! grep -q "control_d" /proc/xen/capabilities ; then
> exit 0
> fi
> 
> ...which also doesn't look really good, since this exit 0 doesn't happen
> when /proc/xen/capabilities does *not* exist, and the first domU I'm
> looking inside here doesn't have it.

Generally I (too?) try to migrate away from /proc/xen, that's why my
patch use /sys/hypervisor/uuid instead.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Bug#922490: man: Text from standard error disappears on the top

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.8.5-1
Severity: normal

Dear Maintainer,

  modern computers are now that fast, that the text from standard error
gets rolled out of sight without noticing.

  This can be seen by adding a '.tm' lines with text, for example
early, in the middle and at the end of a big file and a small one, for
example bash(1) and test(1).

  I have had to write a script to catch the output of standard error in
a temporary file.

  a) if the file is empty it is deleted

  b) if not, a message is displayed when "man" is quit to inform the
user about it, and asked if he wants to see it.

  c) No: file deleted

 Yes: file is read with the pager (less).  After that the user is
asked if he wants to keep it or delete it.


  Such a procedure should be part of the "man" program.

  If the user selects '--warning=...' the warnings are only sent to the
terminal if the environmental variable "MAN_KEEP_STDERR" is set, and
then it is improbable that the user notices something strange and rolls
the screen down.

  There should be a notice about this where "--warning" is explained,
otherwise no warning can be noticed (if one has a fast enough computer)
in the usual interactive mode, which is the most common one.

  "man" should abort with an error message, if '--warning' is selected
without "MAN_KEEP_STDERR" being active in the interactive mode.

  I think that practically all users of "man" do not type a redirection
for the standard error as man pages should already be clean in this
regard, but my experience shows that is not the case.

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

Kernel: Linux 4.9.144-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.70
ii  dpkg   1.19.2
ii  groff-base 1.22.4-2
ii  libc6  2.28-6
ii  libgdbm6   1.18.1-2
ii  libpipeline1   1.5.1-1
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  firefox-esr [www-browser]  60.5.1esr-1~deb9u1
ii  groff  1.22.4-2
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  w3m [www-browser]  0.5.3-37

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

-- 
Bjarni I. Gislason

Bug#922489: libsecret-1-0: needs symlink to libsecret-1.so

[Sandro Knauß]

Package: libsecret-1-0
Version: 0.18.7-1
Severity: normal

Hey,

qtkeychain is using libsecret as a backend to request passwords. ldd is
showing me that it is linked against libsecret-1.so.0 (fine). But strace
shows one sucessfull read of libsecret-1.so.0 (fine) but afterwards, it
tries to load libsecret-1.so without success (as libsecret-1-dev is not
installed). If I create this symlink from libsecret-1.so ->
libsecret-1.so, qtkeychain can load/store successfully passwords.

For me this looks like an error in libsecret, as qtkeychain only imports
libsecret/secret.h in libsecret.cpp [0]. Or maybe the usage in that file
is wrong or cmake screws things up...

My testsystem is a vagrant with a VirtualBox with only task-xfce-desktop and
nextcloud-desktop installed. I enabled to load GNOME startup scripts for
the XFCE environment.

hefee

[0] https://sources.debian.org/src/qtkeychain/0.9.1-1/libsecret.cpp/

-- System Information:
Debian Release: buster/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 4.19.0-3-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

Versions of packages libsecret-1-0 depends on:
ii  libc6 2.28-7
ii  libgcrypt20   1.8.4-5
ii  libglib2.0-0  2.58.3-1
ii  libsecret-common  0.18.7-1

libsecret-1-0 recommends no packages.

libsecret-1-0 suggests no packages.

-- no debconf information

Bug#921680: ufw cannot determine iptables version, fails

[PanaColina]

Thank you for your response.

Tried a 4.19 kernel,  then tried 4.20.10, same result as the 4.17 kernel.

Output of '/usr/share/ufw/check-requirements'

ERROR: Couldn't determine iptables version

Output of '/sbin/iptables --version'

iptables v1.8.2 (nf_tables)


Searching for issues with iptables and nftables, it seems to be a mess with
dependencies. I'm (obviously) not a programmer, but I took a wild guess and
enabled all of the nfttables kernel modules (a dozen or so). Now it works.

The ufw "ERROR: Couldn't determine iptables version" didn't lead me to
assume I needed additional kernel modules.

Thank you,
Jeff H.



On Fri, Feb 15, 2019 at 4:10 PM Jamie Strandboge 
wrote:

> On Thu, 07 Feb 2019, PanaColina wrote:
>
> > Package: ufw
> > Version: 0.36-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> > On clean new install of ufw, any ufw command
> > (eg: "ufw status") results in:
> > "ERROR: Couldn't determine iptables version"
> >
> > Additional packages automatically installed at the same time:
> >  iptables 1.8.2-3
> >  libnftables0 0.9.0-2
> >  libnftnl11 1.1.2-2
> >  nftables 0.9.0-2
> >
> > Assuming some conflict, I removed nftables and libnftables0, but error
> > persists.
> >
> > ufw is set as dependent on libnftnl11, and of course iptables
> >
>
> I cannot reproduce this with the current 4.19 kernel or on an older 4.17
> kernel
> (like you have-- you may want to consider upgrading).
>
> $ dpkg -l|grep -E '(ufw|iptables|nft)'|awk '{print $1, $2, $3}'
> ii iptables 1.8.2-3
> ii libnftables0:amd64 0.9.0-2
> ii libnftnl11:amd64 1.1.2-2
> ii libnftnl7:amd64 1.1.1-1
> ii nftables 0.9.0-2
> ii ufw 0.36-1
>
> $ /sbin/iptables --version
> iptables v1.8.2 (nf_tables)
>
> $ sudo ufw status
> Status: inactive
>
> $ sudo ufw enable
> Firewall is active and enabled on system startup
>
> $ sudo ufw status
> Status: active
>
> To Action  From
> -- --  
> 22/tcp ALLOW   Anywhere
> 22/tcp (v6)ALLOW   Anywhere (v6)
>
>
> It continues to work with iptables-legacy (using update-alternatives; I
> updated
> the alternative, ran ufw disable and rebooted):
>
> $ /sbin/iptables --version
> iptables v1.8.2 (legacy)
>
> $ sudo ufw status
> Status: inactive
>
> $ sudo ufw enable
> Firewall is active and enabled on system startup
>
> $ sudo ufw status
> Status: active
>
> To Action  From
> -- --  
> 22/tcp ALLOW   Anywhere
> 22/tcp (v6)ALLOW   Anywhere (v6)
>
>
> What is the output of 'sudo /usr/share/ufw/check-requirements'?
>
> What is the output of '/sbin/iptables --version'?
>
>
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.17.17 (SMP w/8 CPU cores)
> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages ufw depends on:
> > ii  debconf [debconf-2.0]  1.5.70
> > ii  iptables   1.8.2-3
> > ii  lsb-base   10.2018112800 
> > ii  python33.7.2-1
> > ii  ucf3.0038+nmu1
> >
> > ufw recommends no packages.
> >
> > Versions of packages ufw suggests:
> > ii  rsyslog  8.40.0-1+b1
> >
> > -- debconf information:
> >   ufw/existing_configuration:
> >   ufw/allow_known_ports:
> >   ufw/enable: false
> >   ufw/allow_custom_ports:
> --
> Jamie Strandboge | http://www.canonical.com
>

Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[W. Martin Borgert]

Hi Simon,

many thanks for taking the time to go through this bug report!
Very much appreciated!

On 2019-02-16 17:02, Simon McVittie wrote:
> Multiarch-qualified directories under /usr/share don't seem like they make
> much sense: the whole point of the $libdir/$datadir duality is that if
> files need to be different on some architectures, then the files should
> be in $libdir, not in $datadir.

True.

> My understanding is that GIR is intended to be a collection of
> machine-readable facts about the source code, rather than facts about
> the binary, which is why it's in /usr/share in the first place (unlike
> the typelib, which is architecture-dependent). However, those facts are
> partially derived from inspecting the binary, so can in principle end
> up different in rare cases, and presumably that is what's happened here.

(Just for myself in order to not forget it,) the six
GLib-2.0.gir variants are:

 - amd64
 - armel, armhf, i386, mipsel
 - arm64, mips64el, ppc64el
 - hurd-i386
 - mips
 - s390x

The differences are e.g. in how/whether GDoubleIEEE754,
GFloatIEEE754, G_VA_COPY_AS_ARRAY, GLIB_SIZEOF_LONG (4 vs 8
bytes), GUINTPTR_FORMAT (lu vs. u) etc. are defined.

Btw. Peter Pearse of Linaro found similar issues in 2011:
"Investigation of gobject introspection with a view to cross
compiling"
(https://wiki.linaro.org/PeterPearse/GobjectIntrospection)

The differences he found in Clutter-1.0.gir seem to be solved now,
the GLib-2.0.gir differences not.

> The program that generates GIR (g-ir-scanner) is architecture-independent
> Python code, so it's easy to say "gobject-introspection should look in
> its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
> probably harder to actually implement than you might think.

I found only one .gir file under $libdir in sid, only for ppc:

/usr/lib/powerpc-linux-gnu/mutter/ClutterX11-1.0.gir
/usr/lib/powerpc-linux-gnu/mutter/Clutter-1.0.gir

> One option for fixing this for buster, if it is considered to be urgent,
> is to investigate what the difference is and whether it can be eliminated,
> perhaps by wrapping the code that differs between architectures in
> #ifndef __GI_SCANNER__.

Sorry, here you lost me: In which code do you like to see the
conditionals? In glib?

> Another is to remove the M-A: same annotation.

I like to be able to cross-build certain packages. For my
usecase, I have to install libgirepository1.0-dev for multiple
architectures, because the package depends on it.

Cheers

Bug#922488: linux-image-4.9.0-8-amd64: Kernel panic in IPv6 stack after some hours of operation

[Ralf Jung]

Package: linux-image-4.9.0-8-amd64
Version: 4.9.144-3
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

after installing the kernel updates that got released to Debian stable earlier
today or yesterday, we saw all the three updated systems fail in the same way:
after 3-5h, they stop responding. We managed to grab a picture of the kernel
console on one of them, which showed a kernel panic in the IPv6 stack:

  https://imgur.com/7Teb8BV

The topmost stack items are (hoping I got no typos)

  __pskb_pull_tail
  ip6_dst_lookup_tail
  _decode_session6
  __xfrm_decode_session
  icmpv6_route_lookup
  icmp6_send

That system was using the kernel this bug is reported against 
(linux-image-4.9.0-8-amd64 4.9.144-3).
The other two affected systems used a backports kernel instead 
(linux-image-4.19.0-0.bpo.2-amd65 4.19.16-1~bpo9+1).
Unfortunately we have no console access there, all we can do there is a hard 
reboot from the web interface.

These servers are all operating as gateway servers for our Freifunk network, 
meaning they mostly forward traffic and their network setup is very 
non-standard.
Please let me know if there is any configuration details that would be helpful 
to track this down.

Kind regards,
Ralf

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 16 Feb 2019, at 22:52, Synthea  wrote:
> 
> Here's the result after installing that lib
> Note: this error seems more likely to happen with notifications

Thanks, that makes it clear what's happening. The DBus connection is being
closed by the remote end, and the exit-on-close property defaults to true,
which causes GLib to send a SIGTERM to the process. This is the intended
behaviour of applications using the session bus as per the documentation, so
you need to figure out why the remote is closing the bus, but it's very much
not HexChat's fault. Maybe GLib is doing something wrong, but more likely
there's something weird in your local setup affecting DBus, given there are no
other reports I know of of people encountering this.

Regards,
James

> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/hexchat 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x7fffe76e6700 (LWP 25681)]
> [New Thread 0x7fffe6ee5700 (LWP 25682)]
> 
> ** (hexchat:25675): WARNING **: Invalid borders specified for theme
> pixmap:
> /usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
> borders don't fit within the image
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
> esistente.
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x7fffe6ee5700 (LWP 25682)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in g_main_context_poll (priority= out>, n_fds=1, fds=0x7fffd80010c0, timeout=,
> context=0x56fc6b80) at ././glib/gmain.c:4228
> #2  0x745c99f6 in g_main_context_iterate
> (context=0x56fc6b80, block=block@entry=1, dispatch=dispatch@entry=1
> , self=) at ././glib/gmain.c:3924
> #3  0x745c9d82 in g_main_loop_run (loop=0x5597d6f0) at
> ././glib/gmain.c:4125
> #4  0x75b4a656 in gdbus_shared_thread_func
> (user_data=0x5597d730) at ././gio/gdbusprivate.c:247
> #5  0x745f13d5 in g_thread_proxy (data=0x56d64590) at
> ././glib/gthread.c:784
> #6  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
> pthread_create.c:333
> #7  0x73e99acf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> Thread 2 (Thread 0x7fffe76e6700 (LWP 25681)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in g_main_context_poll (priority= out>, n_fds=1, fds=0x7fffe8c0, timeout=,
> context=0x56fc5e50) at ././glib/gm

Bug#922235: nextcloud-desktop: Client seems to not save login credentials

[Sandro Knauß]

Control: reassign -1 libqt5keychain1  0.9.1-2
Control: forcemerge 920984 -1 

Hi,
 
> I've looked into it, and the new client (as opposed to owncloud-client which
> I used before) uses qtkeychain, which uses either gnome-keyring or kwallet.
> I'm starting gnome-keyring with my login session running Xfce, however the
> password is still not saved.

Why everyone thinks, that nextcloud-desktop is not using qtkeychain.  It is 
listed in the depends list and you can't install nextcloud-desktop without 
qtkeychain. Let's merge bugs.

> (At a minimum it should recommend gnome-keyring | kwallet, as it's required
> for that to even work.)

qtkeychain already recommends gnome-keyring | kwallet. But both are only 
recommended as you can use the software without on of those packages.

hefee

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

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[Synthea]

Here's the result after installing that lib
Note: this error seems more likely to happen with notifications

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hexchat...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/hexchat 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7fffe76e6700 (LWP 25681)]
[New Thread 0x7fffe6ee5700 (LWP 25682)]

** (hexchat:25675): WARNING **: Invalid borders specified for theme
pixmap:
/usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
borders don't fit within the image

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

** (hexchat:25675): WARNING **: invalid source position for vertical
gradient

Thread 1 "hexchat" received signal SIGTERM, Terminated.
raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
esistente.
(gdb) thread apply all bt

Thread 3 (Thread 0x7fffe6ee5700 (LWP 25682)):
#0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x745c99f6 in g_main_context_poll (priority=, n_fds=1, fds=0x7fffd80010c0, timeout=,
context=0x56fc6b80) at ././glib/gmain.c:4228
#2  0x745c99f6 in g_main_context_iterate
(context=0x56fc6b80, block=block@entry=1, dispatch=dispatch@entry=1
, self=) at ././glib/gmain.c:3924
#3  0x745c9d82 in g_main_loop_run (loop=0x5597d6f0) at
././glib/gmain.c:4125
#4  0x75b4a656 in gdbus_shared_thread_func
(user_data=0x5597d730) at ././gio/gdbusprivate.c:247
#5  0x745f13d5 in g_thread_proxy (data=0x56d64590) at
././glib/gthread.c:784
#6  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
pthread_create.c:333
#7  0x73e99acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fffe76e6700 (LWP 25681)):
#0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x745c99f6 in g_main_context_poll (priority=, n_fds=1, fds=0x7fffe8c0, timeout=,
context=0x56fc5e50) at ././glib/gmain.c:4228
#2  0x745c99f6 in g_main_context_iterate (context=context@entry
=0x56fc5e50, block=block@entry=1, dispatch=dispatch@entry=1,
self=) at ././glib/gmain.c:3924
#3  0x745c9b0c in g_main_context_iteration
(context=0x56fc5e50, may_block=may_block@entry=1) at
././glib/gmain.c:3990
#4  0x745c9b51 in glib_worker_main (data=) at
././glib/gmain.c:5783
#5  0x745f13d5 in g_thread_proxy (data=0x56d646d0) at
././glib/gthread.c:784
#6  0x74157494 in start_thread (arg=0x7fffe76e6700) at
pthread_create.c:333
#7  0x73e99acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x77f08a80 (LWP 25675)):
#0  0x74160f9f in raise (sig=15) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fffefef0038 in ffi_call_unix64 () at /usr/lib/x86_64-linux-
gnu/libffi.so.6
#2  0x7fffefeefa9a in ffi

Bug#922487: Please coordinate removal of python-tox transitional pkg

[Jeremy Bicha]

Source: tox
Version: 3.7.0-2

I noticed that you dropped the python-tox transitional package, but
several Debian packages still Build-Depend on it. Could you work to
fix those packages?

Debian's auto-cruft tool doesn't handle arch:all NBS packages so
please file a removal bug for python-tox.

https://bugs.debian.org/917971 is a recent example of an arch:all removal bug.

$ reverse-depends -r sid -b python-tox
Reverse-Build-Depends-Indep
===
* onionbalance
* python-bottle
* python-scales

Reverse-Build-Depends
=
* derpconf
* gitsome
* preggy
* pypuppetdb
* python-osmapi


Thanks,
Jeremy Bicha

Bug#922485: brainparty: Minigame "Symbolic Logic": Premises are empty or contain garbage.

[Markus Koschany]

Control: tags -1 confirmed pending

Hi!

Am 16.02.19 um 22:10 schrieb Johann Suhter:
> Package: brainparty
> Version: 0.61+dfsg-3+b1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> the minigame "Symbolic Logic" whithin brainparty cannot be played
> because the premises are not shown.

Thank you for the bug report and your patch. I can confirm the bug and
your patch seems to work. Update is pending.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 16 Feb 2019, at 21:38, Synthea  wrote:
> 
> Just downgraded hexchat from backports to stable (2.12.4-3), I still
> encounter the same problem. If you won't solve that I will feel obliged
> to use another client, I just cannot use a client that crashes
> everytime in minus that one minute

Please install libglib2.0-0-dbg so the stack trace is clearer.

My initial suspicion though is something about your Breeze-Dark theme is
breaking GLib2.0. You might like to try with Adwaita.

James

> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/hexchat 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x7fffe76e6700 (LWP 22421)]
> [New Thread 0x7fffe6ee5700 (LWP 22422)]
> 
> ** (hexchat:22413): WARNING **: Invalid borders specified for theme
> pixmap:
> /usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
> borders don't fit within the image
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
> esistente.
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x7fffe6ee5700 (LWP 22422)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x745c9d82 in g_main_loop_run () from /lib/x86_64-linux-
> gnu/libglib-2.0.so.0
> #3  0x75b4a656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-
> 2.0.so.0
> #4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #5  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
> pthread_create.c:333
> #6  0x73e99acf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> Thread 2 (Thread 0x7fffe76e6700 (LWP 22421)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x745c9b0c in g_main_context_iteration () from /lib/x86_64-
> linux-gnu/libglib-2.0.so.0
> #3  0x745c9b51 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #5  0x74157494 in start_thread (arg=0x7fffe76e6700) at
> pthread_create.c:333
> #6  0x73e99acf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clon

Bug#922486: python3-sbml5: libsbml fails to import

[Andreas Tille]

Hi Liubov,

On Sat, Feb 16, 2019 at 10:37:29PM +0100, Liubov Chuprikova wrote:
> After installing python3-sbml5, it is not possible to import libsbml module:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'libsbml'

Uhmmm, thanks a lot for spotting this.
 
> I have found it when I was looking into python-cobra package that has
> python3-sbml5 in its extra dependencies.

If you see any chance to hunt this issue in libsbml down this would be
really welcome.  I'm busy with real life this weekend.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[Synthea]

Just downgraded hexchat from backports to stable (2.12.4-3), I still
encounter the same problem. If you won't solve that I will feel obliged
to use another client, I just cannot use a client that crashes
everytime in minus that one minute

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hexchat...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/hexchat 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7fffe76e6700 (LWP 22421)]
[New Thread 0x7fffe6ee5700 (LWP 22422)]

** (hexchat:22413): WARNING **: Invalid borders specified for theme
pixmap:
/usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
borders don't fit within the image

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

** (hexchat:22413): WARNING **: invalid source position for vertical
gradient

Thread 1 "hexchat" received signal SIGTERM, Terminated.
raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
esistente.
(gdb) thread apply all bt

Thread 3 (Thread 0x7fffe6ee5700 (LWP 22422)):
#0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#2  0x745c9d82 in g_main_loop_run () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#3  0x75b4a656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-
2.0.so.0
#4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#5  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
pthread_create.c:333
#6  0x73e99acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fffe76e6700 (LWP 22421)):
#0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#2  0x745c9b0c in g_main_context_iteration () from /lib/x86_64-
linux-gnu/libglib-2.0.so.0
#3  0x745c9b51 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#5  0x74157494 in start_thread (arg=0x7fffe76e6700) at
pthread_create.c:333
#6  0x73e99acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x77f08a80 (LWP 22413)):
#0  raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fffefef0038 in ffi_call_unix64 () from /usr/lib/x86_64-
linux-gnu/libffi.so.6
#2  0x7fffefeefa9a in ffi_call () from /usr/lib/x86_64-linux-
gnu/libffi.so.6
#3  0x74aa5c8a in g_cclosure_marshal_generic_va () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x74aa51a4 in ?? () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#5  0x74abf8cd in g

Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

[Hans van Kranenburg]

On 2/16/19 1:41 PM, Hans van Kranenburg wrote:
> On 2/16/19 4:26 AM, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
>>> Creating new binary packages etc... is not an option anymore during the
>>> Buster freeze.
>>
>> Ok, I can carry myself a startup script calling actual xl directly. But
>> one thing would be very useful to have in buster - avoid starting
>> dom0 related services in guest. Otherwise even package installation
>> fails (if you happen to have the same version of xen packages in dom0
>> and domU). Would the below patch be acceptable?
> 
> That's a good one yes. There's some optimization of checks already been
> done in branch wip.testme [1], e.g. [2], but those checks would indeed
> still not result in a noop in a domU. Nice find!
> 
> I'll add your change later today, and resend it for review. I think the
> warning is not necessary, since a warning points at something that you
> should fix. This should just noop.

Actually, while looking at this again...

In the init script, we already have...

capability_check()
{
[ -e "/proc/xen/capabilities" ] || return 1
grep -q "control_d" /proc/xen/capabilities || return 1
return 0
}

...which gets called like this...

capability_check
case "$?" in
0) ;;
*) log_end_msg 255; exit ;;
esac

Looking at /proc/xen/capabilities and seeing if there's control_d inside
seems to be a more common way to check if this is a dom0.

It does log_end_msg 255 and 255 seems to be warning.

The upstream init script has...

# run this script only in dom0:
# no capabilities file in xenlinux domU kernel
# empty capabilities file in pv_ops domU kernel
if test -f /proc/xen/capabilities && \
   ! grep -q "control_d" /proc/xen/capabilities ; then
exit 0
fi

...which also doesn't look really good, since this exit 0 doesn't happen
when /proc/xen/capabilities does *not* exist, and the first domU I'm
looking inside here doesn't have it.

Can you show what happens exactly when 'package installation fails'?

> In domU:
> -# cat /sys/hypervisor/uuid
> d5ad9b8c-b230-4bba-a74d-04049d090a36
> 
> In dom0:
> -# cat /sys/hypervisor/uuid
> ----
> 
> Thanks,
> Hans
> 
> [1] https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
> [2]
> https://salsa.debian.org/xen-team/debian-xen/commit/30c9a3c54332f34c515143b261514a04e1e1d13c
> 
>> -8<-
>>
>> From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
>>  
>> Subject: [PATCH] Do not start dom0 services if running inside domU
>>
>> Signed-off-by: Marek Marczykowski-Górecki 
>> ---
>>  debian/xen-utils-common.xen.init | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/debian/xen-utils-common.xen.init 
>> b/debian/xen-utils-common.xen.init
>> index 4b793d5ac2..d73e827514 100644
>> --- a/debian/xen-utils-common.xen.init
>> +++ b/debian/xen-utils-common.xen.init
>> @@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
>>  exit 0
>>  fi
>>  
>> +if grep -q '[^0-]' /sys/hypervisor/uuid; then
>> +log_warning_msg "Xen guest detected"
>> +exit 0
>> +fi
>> +
>>  XENCONSOLED="$ROOT"/bin/xenconsoled
>>  XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
>>  XENSTORED="$ROOT"/bin/xenstored
>>
> 

Bug#922486: python3-sbml5: libsbml fails to import

[Liubov Chuprikova]

Package: python3-sbml5
Version: 5.17.2+dfsg-3
Severity: normal

Hi,

After installing python3-sbml5, it is not possible to import libsbml module:

Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'libsbml'

I have found it when I was looking into python-cobra package that has
python3-sbml5 in its extra dependencies.

Liubov

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

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

Bug#922443: texlive-extra-utils: latexpand script: detection of comments is buggy

[Hilmar Preuße]

tags 922443 + fixed-upstream
stop

On 16.02.19 01:47, Vincent Lefevre wrote:

> In the latexpand script, the detection of comments is buggy:
> if a % is not at the beginning of a line, it will not be regarded
> as introducing a comment, unless it is preceded by a backslash;
> in short, the meaning of a backslash has been reversed.
> 
Has been commited to upstream git in
2890b421acbeb3e487637a24c79677bc4eb43cf8. Tag that bug as fixed in upstream.

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



signature.asc
Description: OpenPGP digital signature

Bug#896468: [Pkg-javascript-devel] Bug#896468: libjs-chartjs: Please upload newer versions

[Paul Gevers]

Hi,

On 15-02-2019 07:46, Pirate Praveen wrote:
> Thanks Jonas for the confirmation. I have uploaded 2.7.3 to
> experimental. Since browserify is not available in the archive, I have
> used rollup to build the umd bundle. Please review, test and confirm if
> it is working as expected and I can upload to unstable.

I must admit that I don't know how to program in JavaScript, but if I
compare the upstream version of 2.7.3 [1] with the one in experimental,
I am missing already the first function that I see upstream, i.e.
getRgba().

I expect that is not ok, no?

Also the file looks quite different, but I guess that is to be expected
due to build system differences.

Paul


[1] https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.7.3/Chart.js



signature.asc
Description: OpenPGP digital signature

Bug#922400: Config

[Dr. Diether Knof]

I have forgotten that I have set the option hwdec=auto in my config file. 
Without the config file, the default call of mpv does not crash on a video.

Bug#922484: nmu: paw_1:2.14.04.dfsg.2-9.1, mclibs_20061220+dfsg3-3.1, geant321_1:3.21.14.dfsg-11

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release team,

Now that #922453 is fixed, paw, mclibs and geant321 have to be rebuilt
against this fixed cernlib release.

nmu paw_1:2.14.04.dfsg.2-9.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu mclibs_20061220+dfsg3-3.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu geant321_1:3.21.14.dfsg-11 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"

Thanks in advance;

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlxoe+wACgkQ7+hsbH/+
z4P8ywf+OdYQS2XYWdGZ9y5bBJoQGT0mQ0zvD+SdFfgAMU9o+91FqhTtxB8jTLd2
QQpkcBgaI+U/PIzKWVea3Tyu2sEzL5sm7J/GWKe5sYOYp3sQSftp+Sz0IRmoXhzA
BHENzlB/L/vs00yJWrMH/h5/t2DH/s99K5dxYfV/V3fA9HbWWuvTmTteQ6ecsOP3
Xr09Vbhh3iuWR1x6yiyTvOETJer9CxyMX+SQSHai6wKYZNP8aKPoVP7QPl4I8goN
B6B7clVuAhTTtDInfTN+0RxHgX2pIuxEoPDJGUxefhY2VJvLnUl/FCaRaneyZx3d
/xsODhYvd5BIO2Hox3GS7jnDa6faeQ==
=ZIna
-END PGP SIGNATURE-

Bug#922485: brainparty: Minigame "Symbolic Logic": Premises are empty or contain garbage.

[Johann Suhter]

Package: brainparty
Version: 0.61+dfsg-3+b1
Severity: normal
Tags: patch

Dear Maintainer,

the minigame "Symbolic Logic" whithin brainparty cannot be played
because the premises are not shown.


Steps to reproduce:

Start the program and select the game "Symbolic Logic".
I can select it by clicking on 
- "PLAY!" 
- "PRACTISE" 
- 3 times "MORE" for searching the "Symbolic Logic" minigame
- the item in the middle which has an icon with a text like "All sales
  assist / wrestle crocodi / Catherine ...". 
- Then a description of the game appears, and I click anywhere on
  this description. 
- Now the game starts.


Expected behaviour:

I expect 3 sentences: Two premises and a conclusion.


Observed behaviour:

The conclusion is shown.
The two premises are completely missing, only two full stops appear.
Sometimes, I see some garbage characters instead.


Patch:

I have debugged the program a bit and I think the responsible function
is "const char* FlattenPremise(...)" which returns a pointer to a
temporary string object which is undefined behaviour.

I would suggest the following patch. The patch refers to
brainparty_0.61+dfsg-3 (I am on Debian stable), but when I browse the
sources on https://salsa.debian.org/games-team/brainparty the bug
still seems to exist.


--- a/symboliclogic.cpp Sat Feb 16 21:39:30 2019 +0100
+++ b/symboliclogic.cpp Sat Feb 16 21:49:13 2019 +0100
@@ -116,7 +116,7 @@
   }
 }

-const char* 
BPMiniGame_SymbolicLogic::FlattenPremise(BPMiniGame_SymbolicLogic_Premise* 
premise) {
+string 
BPMiniGame_SymbolicLogic::FlattenPremise(BPMiniGame_SymbolicLogic_Premise* 
premise) {
   ostringstream result;
   
   switch (premise->Type) {
@@ -150,7 +150,7 @@
 break;
   }
  
-  return result.str().c_str();
+  return result.str();
 }

 void BPMiniGame_SymbolicLogic::Tick() {

--- a/symboliclogic.h   Sat Feb 16 21:39:30 2019 +0100
+++ b/symboliclogic.h   Sat Feb 16 21:49:13 2019 +0100
@@ -67,7 +67,7 @@
   void Start();
   int GetWeight();
   void Render();
-  const char* FlattenPremise(BPMiniGame_SymbolicLogic_Premise* premise);
+  string FlattenPremise(BPMiniGame_SymbolicLogic_Premise* premise);
   void Tick();

   void OnMouseDown();



Thank you.


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

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

Versions of packages brainparty depends on:
ii  brainparty-data   0.61+dfsg-3
ii  fonts-freefont-ttf20120503-6
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libsdl-gfx1.2-5   2.0.25-5
ii  libsdl-image1.2   1.2.12-5+deb9u1
ii  libsdl-mixer1.2   1.2.12-11+b3
ii  libsdl-ttf2.0-0   2.0.11-3+b1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.3.0-18+deb9u1

brainparty recommends no packages.

brainparty suggests no packages.

-- no debconf information

Bug#922483: RFP: git-absorb -- auto fixup a stack of git commits [Rust ☹]

[Adam Borowski]

Package: wnpp
Severity: wishlist

* Package name: git-absorb
  Version : 0.3.0
  Upstream Author : Stephen Jung
* URL : https://github.com/tummychow/git-absorb
* License : BSD-3
  Programming Lang: Rust :(
  Description : auto fixup a stack of git commits

It's a tool that, when run on a git feature branch with a stack of pending
git commits and some uncommitted fixes, automatically finds a relevant
commit (above a given base, such as master) where the given hunk should be
applied to.  There's an interactive mode where you get to review the
assignment of fixups or fully automated YOLO ("git reflog" is --> over
there).

This functionality is something I wish for approximately once per day --
alas, this implementation is written in some ugly heathen language I neither
speak nor understand insanities of packaging of.  Thus, if I could get a
Rust user to do the dirty work...

No, I haven't actually tried if git-absorb is as good as it's advertised.

Bug#922482: capstone4: duplicates capstone

[Jeremy Bicha]

Source: capstone4
Version: 4.0.1-2
Severity: important

capstone4 ships the same packages as capstone. You should probably
just use the capstone source package name instead.

I think it would have been better if the new version of capstone were
uploaded to experimental instead of as a separate source package to
unstable.

Thanks,
Jeremy Bicha

Bug#841524: [Pkg-emacsen-addons] Bug#841524: Depend or Suggest markdown package for preview to work

[David Bremner]

Nicholas D Steeves  writes:

>
> List of supported converters from upstream README.md: markdown |
> libtext-multimarkdown-perl | pandoc
>
> Also available in Debian: discount | python3-markdown
>
> Also from the README
>   `markdown-command` - the command used to run Markdown (default:
>`markdown`)
>
> Given that markdown-mode is configured upstream to use "bin:markdown",
> it seems more reasonable (and easy!) to just Recommends markdown, and
> then add a list of alternatives to Suggests.  This way it works out of
> the box, and the user can consult Suggests when interpreting the
> upstream README.md.

I don't usually think about Suggests as alternatives to Recommends, but
rather things less commonly useful, but still enabling additional
functionality.

markdown, libtext-markdown-perl and discount provide
/usr/bin/markdown. You could test how well those work ootb, 
and recommend them as alternatives if it seems ok.

There are also conflicts between several of those, which looks odd to
me, but I'll investigate that seperately.

d

Bug#888202: stretch->buster: reminder that kernel should be >= 3.2 before upgrade

[Paul Gevers]

Control: tags -1 patch pending

On Tue, 23 Jan 2018 22:28:00 +0100 Aurelien Jarno 
wrote:
> Starting with glibc 2.26, Linux kernel 3.2 or later is required. This
> change only affects amd64 and i386 as it was already the case in Stretch
> for other architectures. The libc6 preinst has a check and aborts the
> installation if it is not the case to avoid completely breaking the
> system. That said it will leave the upgrade unfinished.

I have prepared the attached patch that I intend to commit if nobody
objects to the wording in a couple of days. It adds this description to
the issues list.

Paul
PS: is it somehow possible to only add this to the i386 and amd64
release-notes?
From 2d3da17e1c29af23d974cbfffdec1cf0aeee071f Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Sat, 16 Feb 2019 20:48:47 +0100
Subject: [PATCH] Add note about glibc requiring Linux >= 3.2

Closes: 888202
---
 en/issues.dbk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index d15d12da..156e0489 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -213,6 +213,21 @@ information mentioned in .
 
   
 
+  
+
+glibc requires linux kernel 3.2 or higher
+
+  Starting with glibc 2.26, Linux
+  kernel 3.2 or later is required. This change only affects amd64 and i386
+  as it was already the case in stretch for other architectures. The
+  libc6 preinst has a check and
+  aborts the installation if it is not the case to avoid completely
+  breaking the system. That said it will leave the upgrade
+  unfinished. Please update the kernel before starting the system upgrade
+  if the system still runs a kernel before 3.2.
+
+  
+
 
 
 
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#922349: eatmydata: ld.so “secure-execution mode” considerations?

[Thorsten Glaser]

Hi Aurelien,

[…]
>All the above are purely hypothetical cases and I do not have a good

Thanks for the insight, you have me understanding your point.

These were about eatmydata in particular, do you have any
insight on the other?


Yves-Alexis Perez dixit:

>My own opinion on this is that no setuid bits should be added to a library
>without a thorough audit of the source code to make sure it can't be abused
>against an suid binary in order to escalate privilege.

OK. We have that, plus the known bugs in eatmydata. So this is an
issue for README.Debian… or, no, the upstream README probably, plus
fixing bugs. Then the user can set that bit themselves, if they want.

As for my xunihex (final name yet undecided), if I wanted to have
such an audit, how’d I best do that? It’s best if not the original
author does it, due to organisational blindness. Would I perhaps
find someone here willing to do it for a small donation or $beverage?
(It’s going to be a really small thing.)

Thanks,
//mirabilos
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]

Bug#921274: teeworlds: baseline violation on i386

[Adrian Bunk]

On Sun, Feb 10, 2019 at 06:35:06PM +, Jordy RUIZ wrote:
> Greetings,

Hi Jordy,

> I'm Dune, coming from upstream.
> This should be fixed by 
> https://github.com/teeworlds/teeworlds/commit/fdc14f07386272c47a95e060643620f537ab9d5e
>  for bam and https://github.com/teeworlds/teeworlds/pull/2033 for cmake.
> Teeworlds will only use the SSE flag if necessary (old gcc compilers, gcc < 
> 4.10). I hope that does it for you, Adrian.

thanks, looks good to me (there was no gcc 4.10 since gcc 5 followed 
after 4.9, but that has no practical relevance here).

> Jordy.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#835913: ibus: use of dbus-run-session ...

[Simon McVittie]

Control: tags -1 + patch

On Sat, 16 Feb 2019 at 16:25:51 +, Simon McVittie wrote:
> I'm testing a real patch, which should be a bit cleaner and more
> upstreamable than the untested pseudo-patch I gave on the bug (I didn't
> have time to do this for every package during the mass-bug-filing).

Better patch: https://salsa.debian.org/debian/ibus/merge_requests/1

I build-tested this one and it seems to work, with the same package
contents (disregarding timestamps).

smcv

Bug#921985: munin-node: df plugin fails to get data for /home

[Steve Schnepp]

On Sat, 16 Feb 2019 16:39 Marc Donges  However, a separate /home is a common configuration and this problem can
> easily be overlooked and is then not trivial to find, because there are no
> error messages anywhere, there is just this odd difference in reality
> between munin-node as a daemon and everything else the sysadmin does
> manually on the CLI.
>

Here the issue feels much more in munin-run not being the same as
munin-node.

That systemd configuration is new from stretch IMHO, but I think it is for
the better nowadays.

I think to make this less awkward two things would be nice:
>

That said, I agree that we should make it more obvious.

- a option to allow monitoring of /home without editing a non-conffile in
> /lib (How is this even done properly? I just edited the service file to
> find the cause of my problem, but I suppose it will be overwritten on every
> update. Is there a nice way to do this?)
>

You can always copy the file into /etc, it will then take precedence

- a way to alert the admin of the possibly unintended configuration:
> df-plugin activated + ProtectHome + Separate /home
>

This can be done inside the munin-run environment, and not only for the df
plugin.

Can the df* plugin itself detect the situation and then make a log entry?
> That would have severely cut down the time it took me to find this.
>

I have to see if the df plugin does know about it, as I'm not sure it can
detect it reliably.

-- 
Steve Schnepp

>

Bug#922481: O: ooo-thumbnailer -- thumbnailer for OpenOffice.org documents

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of ooo-thumbnailer has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/ooo-thumbnailer


Package: ooo-thumbnailer
Binary: ooo-thumbnailer
Version: 0.2-5.1
Maintainer: David D Lowe 
Build-Depends: cdbs (>= 0.4.49), debhelper (>= 7)
Architecture: all
Standards-Version: 3.8.4.0
Format: 1.0
Files:
 5a9d381160ddfcfcd6eebdc55c18a39a 1715 ooo-thumbnailer_0.2-5.1.dsc
 441b3280fdb69be029f81d2b3036b6d0 8524 ooo-thumbnailer_0.2.orig.tar.gz
 490f370ac753d4fd58d322a38c6f549e 2442 ooo-thumbnailer_0.2-5.1.diff.gz
Checksums-Sha256:
 21f56d6478ccbace9c2742348266466d032f42f8b62cf947e1bddbea94981a8e 1715 
ooo-thumbnailer_0.2-5.1.dsc
 48c012bf041b6ff7e87e4c6eb26018750ec8f45ca2e6abc21272f9c6c497cac5 8524 
ooo-thumbnailer_0.2.orig.tar.gz
 b39e9f9929924f0553b887f4f20cf73d5878ead87910991e80bb77fa10838a59 2442 
ooo-thumbnailer_0.2-5.1.diff.gz
Package-List: 
 ooo-thumbnailer deb gnome optional arch=all
Directory: pool/main/o/ooo-thumbnailer
Priority: source
Section: gnome

Package: ooo-thumbnailer
Version: 0.2-5.1
Installed-Size: 23
Maintainer: David D Lowe 
Architecture: all
Depends: unzip, imagemagick
Description-en: thumbnailer for OpenOffice.org documents
 ooo-thumbnailer is a lightweight OpenOffice.org document thumbnailer that can
 be used by Nautilus to create thumbnails for your documents, spreadsheets,
 presentations and drawings.
Description-md5: a4b011e02bad67ce711dfcdd5da8a8d8
Tag: implemented-in::shell, interface::commandline, role::program,
 scope::application, use::browsing, works-with-format::odf,
 works-with::dtp, works-with::spreadsheet, works-with::text
Section: gnome
Priority: optional
Filename: pool/main/o/ooo-thumbnailer/ooo-thumbnailer_0.2-5.1_all.deb
Size: 4932
MD5sum: df1c6ec336b62768d631f2887a9725a2
SHA256: 15a63ad0876b548d2bd53f0ef6f46f02d6c4e180f89aafadb36da3c157a8cc0f

Bug#922480: progress-linux: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: progress-linux 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of progress-linux
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#922444: racket: Install Package doesn't work in DrRacket

[Ma Kai]

On Sat, 16 Feb 2019 09:00:50 -0400 David Bremner 
wrote:
> Mike Manilone  writes:
> > cadr: contract violation
> >   expected: (cons/c any/c pair?)
> >   given: #f
> >   context...:
> >/usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by-
> > source.rkt:534:4: adjust-deps method in by-source-panel%
> >/usr/share/racket/pkgs/gui-pkg-manager-lib/pkg/gui/private/by-
> > source.rkt:422:4: adjust-all method in by-source-panel%
> >/usr/share/racket/collects/racket/private/class-
internal.rkt:3554:0:
> 
> Looking at this again, do you mean that you get the traceback when
you
> select the menu item?
Yes. When I click this menu item, DrRacket reports this error.

> Are you running the standard Gnome3 interface, or something else?
Yes, I'm using Gnome3.

I've got a new discovery. Run DrRacket under the en_US.utf8 locale and
the problem is gone.  I tested ja_JP.utf8 as well and it also worked. I
don't know if it only happens under zh_CN.utf8. Maybe an upstream bug?

Bug#879007: cyrus-imapd does not accept new connections

[Simon Josefsson]

Hi.  Just another person to confirm this bug, it took me some time to
track down and then notice it was already reported.  I upgraded my mail
server to debian 9 and cyrus imapd always stop working after a couple
of days due to this.  Fortunately my mail server is pretty low traffic,
so I'm hoping a /etc/cron.daily/ job to '/etc/init.d/cyrus-imapd
restart' will work around it.

/Simon


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

Bug#921754: gfsview: undefined reference to symbol 'glEndList'

[Andreas Tille]

Hi,

I tried to build gfsview whether I could do something to fix #921754.
I can confirm that the build leads to

...
/usr/bin/ld: 
/build/gfsview-20121130+dfsg/batch/.libs/librender2D.a(librender2D_la-render.o):
 undefined reference to symbol 'glEndList'
/usr/bin/ld: //usr/lib/x86_64-linux-gnu/libGL.so.1: error adding symbols: DSO 
missing from command line
/usr/bin/ld: 
/build/gfsview-20121130+dfsg/batch/.libs/librender3D.a(librender3D_la-render.o):
 undefined reference to symbol 'glEndList'
/usr/bin/ld: //usr/lib/x86_64-linux-gnu/libGL.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
...

I guess this is just a missing OpenGL library - but which one.  I have
no idea about OpenGL but may be someone here on the list could help?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#922479: nvidia-legacy-340xx-kernel-dkms unknown symbols, kernel 4.20.x

[S R Wright]

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.107-3

This is completely functional in kernel 4.19.x and before,  but an attempt to 
use this in 4.20.x has failed.  While dkms can build the module to completion,  
at boot time in throws a large number of unknown symbols.

The list is attached.


[9.093073] nvidia: loading out-of-tree module taints kernel.
[9.093094] nvidia: module license 'NVIDIA' taints kernel.
[9.093322] nvidia: Unknown symbol rm_p2p_init_mapping (err -2)
[9.093341] nvidia: Unknown symbol rm_init_private_state (err -2)
[9.093392] nvidia: Unknown symbol rm_is_supported_device (err -2)
[9.093415] nvidia: Unknown symbol rm_gpu_ops_get_attached_uuids (err -2)
[9.093438] nvidia: Unknown symbol rm_gpu_ops_get_gpu_arch (err -2)
[9.093456] nvidia: Unknown symbol rm_gpu_ops_memory_alloc_sys (err -2)
[9.093477] nvidia: Unknown symbol rm_get_vbios_version (err -2)
[9.093500] nvidia: Unknown symbol nv_is_virtualized_system (err -2)
[9.093518] nvidia: Unknown symbol rm_resume_smu (err -2)
[9.093565] nvidia: Unknown symbol rm_power_management (err -2)
[9.093610] nvidia: Unknown symbol rm_gvi_free_private_state (err -2)
[9.093662] nvidia: Unknown symbol rm_gvi_isr (err -2)
[9.093702] nvidia: Unknown symbol rm_free_private_state (err -2)
[9.093719] nvidia: Unknown symbol rm_disable_gpu_state_persistence (err -2)
[9.093737] nvidia: Unknown symbol rm_init_adapter (err -2)
[9.093759] nvidia: Unknown symbol rm_ioctl (err -2)
[9.093781] nvidia: Unknown symbol rm_gpu_ops_memory_free (err -2)
[9.093820] nvidia: Unknown symbol rm_run_rc_callback (err -2)
[9.093841] nvidia: Unknown symbol rm_gvi_get_firmware_version (err -2)
[9.093859] nvidia: Unknown symbol rm_is_legacy_device (err -2)
[9.093876] nvidia: Unknown symbol rm_release_api_lock (err -2)
[9.093893] nvidia: Unknown symbol rm_gpu_ops_channel_destroy (err -2)
[9.093918] nvidia: Unknown symbol rm_validate_mmap_request (err -2)
[9.093951] nvidia: Unknown symbol rm_gpu_ops_memory_cpu_map (err -2)
[9.093989] nvidia: Unknown symbol rm_gpu_ops_get_uvm_priv_region (err -2)
[9.094007] nvidia: Unknown symbol rm_isr (err -2)
[9.094029] nvidia: Unknown symbol rm_shutdown_rm (err -2)
[9.094051] nvidia: Unknown symbol rm_acquire_api_lock (err -2)
[9.094068] nvidia: Unknown symbol rm_is_legacy_arch (err -2)
[9.094085] nvidia: Unknown symbol rm_gvi_bh (err -2)
[9.094103] nvidia: Unknown symbol rm_p2p_get_pages (err -2)
[9.094120] nvidia: Unknown symbol rm_i2c_remove_adapters (err -2)
[9.094142] nvidia: Unknown symbol rm_gpu_ops_kill_channel (err -2)
[9.094166] nvidia: Unknown symbol rm_gvi_resume (err -2)
[9.094203] nvidia: Unknown symbol rm_gpu_ops_address_space_create (err -2)
[9.094234] nvidia: Unknown symbol rm_gpu_ops_memory_alloc_fb (err -2)
[9.094255] nvidia: Unknown symbol rm_gvi_attach_device (err -2)
[9.094272] nvidia: Unknown symbol rm_suspend_smu (err -2)
[9.094313] nvidia: Unknown symbol rm_write_registry_dword (err -2)
[9.094333] nvidia: Unknown symbol rm_gvi_get_device_name (err -2)
[9.094351] nvidia: Unknown symbol rm_shutdown_adapter (err -2)
[9.094368] nvidia: Unknown symbol rm_get_gpu_uuid (err -2)
[9.094390] nvidia: Unknown symbol rm_i2c_transfer (err -2)
[9.094421] nvidia: Unknown symbol rm_write_registry_binary (err -2)
[9.094443] nvidia: Unknown symbol rm_get_gpu_uuid_raw (err -2)
[9.094467] nvidia: Unknown symbol rm_gpu_ops_copy_engine_allocate (err -2)
[9.094484] nvidia: Unknown symbol rm_p2p_put_pages (err -2)
[9.094505] nvidia: Unknown symbol rm_perform_version_check (err -2)
[9.094526] nvidia: Unknown symbol rm_isr_bh (err -2)
[9.094543] nvidia: Unknown symbol rm_gvi_suspend (err -2)
[9.094560] nvidia: Unknown symbol rm_gpu_ops_address_space_destroy (err -2)
[9.094618] nvidia: Unknown symbol rm_gvi_detach_device (err -2)
[9.094697] nvidia: Unknown symbol rm_gpu_ops_check_ecc_error_slowpath (err 
-2)
[9.094727] nvidia: Unknown symbol rm_gpu_ops_channel_translate_error (err 
-2)
[9.094744] nvidia: Unknown symbol rm_purge_mmap_contexts (err -2)
[9.094764] nvidia: Unknown symbol rm_p2p_destroy_mapping (err -2)
[9.094802] nvidia: Unknown symbol rm_get_device_name (err -2)
[9.094812] nvidia: Unknown symbol rm_shutdown_smu (err -2)
[9.094820] nvidia: Unknown symbol rm_init_smu (err -2)
[9.094828] nvidia: Unknown symbol rm_check_pci_config_space (err -2)
[9.094846] nvidia: Unknown symbol rm_execute_work_item (err -2)
[9.094855] nvidia: Unknown symbol rm_gpu_ops_destroy_session (err -2)
[9.094863] nvidia: Unknown symbol rm_shutdown_gvi_device (err -2)
[9.094881] nvidia: Unknown symbol rm_gpu_ops_channel_allocate (err -2)
[9.094891] nvidia: Unknown symbol rm_i2c_is_smbus_capable (err -2)
[9.094905] nvidia: Unknown symbol rm_gpu_ops_query_caps (err -2)
[9.094920] nvidia: Un

Bug#921804: rt-extension-jsgantt: diff for NMU version 1.03-1.1

[gregor herrmann]

Control: tags 921804 + patch pending


Dear maintainer,

I've uploaded an NMU for rt-extension-jsgantt (versioned as 1.03-1.1). The diff
is attached to this message.

Regards.


-- 
 .''`.  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: Jerry Lee Lewis: High School Confidencial
diff -Nru rt-extension-jsgantt-1.03/debian/changelog rt-extension-jsgantt-1.03/debian/changelog
--- rt-extension-jsgantt-1.03/debian/changelog	2015-06-03 20:21:53.0 +0200
+++ rt-extension-jsgantt-1.03/debian/changelog	2019-02-16 19:21:10.0 +0100
@@ -1,3 +1,15 @@
+rt-extension-jsgantt (1.03-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Dominic Hargreaves ]
+  * Update Vcs-* fields to point to Salsa
+
+  [ gregor herrmann ]
+  * Add libcapture-tiny-perl to Build-Depends-Indep. (Closes: #921804)
+
+ -- gregor herrmann   Sat, 16 Feb 2019 19:21:10 +0100
+
 rt-extension-jsgantt (1.03-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru rt-extension-jsgantt-1.03/debian/control rt-extension-jsgantt-1.03/debian/control
--- rt-extension-jsgantt-1.03/debian/control	2015-06-03 20:21:53.0 +0200
+++ rt-extension-jsgantt-1.03/debian/control	2019-02-16 19:21:10.0 +0100
@@ -2,16 +2,18 @@
 Section: perl
 Priority: optional
 Maintainer: Debian Request Tracker Group 
-Uploaders: KURASHIKI Satoru 
+Uploaders: KURASHIKI Satoru ,
+Dominic Hargreaves 
 Build-Depends: debhelper (>= 8)
 Build-Depends-Indep: request-tracker4,
+ libcapture-tiny-perl,
  libjson-perl,
  liblist-moreutils-perl,
  libmodule-install-rtx-perl
 Standards-Version: 3.9.6
 Homepage: http://search.cpan.org/dist/RT-Extension-JSGantt/
-Vcs-Git: git://anonscm.debian.org/pkg-request-tracker/rt-extension-jsgantt.git
-Vcs-Browser: http://anonscm.debian.org/?p=pkg-request-tracker/rt-extension-jsgantt.git
+Vcs-Browser: https://salsa.debian.org/request-tracker-team/rt-extension-jsgantt
+Vcs-Git: https://salsa.debian.org/request-tracker-team/rt-extension-jsgantt.git
 
 Package: rt4-extension-jsgantt
 Architecture: all


signature.asc
Description: Digital Signature

Bug#921899: rt-extension-calendar: diff for NMU version 1.01-1.1

[gregor herrmann]

Control: tags 921899 + patch
Control: tags 921899 + pending

Dear maintainer,

I've prepared an NMU for rt-extension-calendar (versioned as 1.01-1.1) and
uploaded it to DELAYED/0.

Regards.


-- 
 .''`.  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: Jerry Lee Lewis: High School Confidencial
diff -Nru rt-extension-calendar-1.01/debian/changelog rt-extension-calendar-1.01/debian/changelog
--- rt-extension-calendar-1.01/debian/changelog	2017-01-20 15:16:42.0 +0100
+++ rt-extension-calendar-1.01/debian/changelog	2019-02-16 19:05:12.0 +0100
@@ -1,3 +1,15 @@
+rt-extension-calendar (1.01-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Dominic Hargreaves ]
+  * Update Vcs-* fields to point to Salsa
+
+  [ gregor herrmann ]
+  * Add libcapture-tiny-perl to Build-Depends-Indep. (Closes: #921899)
+
+ -- gregor herrmann   Sat, 16 Feb 2019 19:05:12 +0100
+
 rt-extension-calendar (1.01-1) unstable; urgency=medium
 
   * Drop incorrect Build-Depends on perl-modules and unnecessary
diff -Nru rt-extension-calendar-1.01/debian/control rt-extension-calendar-1.01/debian/control
--- rt-extension-calendar-1.01/debian/control	2017-01-20 15:11:53.0 +0100
+++ rt-extension-calendar-1.01/debian/control	2019-02-16 19:05:12.0 +0100
@@ -6,14 +6,15 @@
 Dominic Hargreaves ,
 Build-Depends: debhelper (>= 9)
 Build-Depends-Indep: request-tracker4,
+ libcapture-tiny-perl,
  libmodule-install-rtx-perl,
  libdatetime-perl,
  libdatetime-set-perl,
  perl,
 Standards-Version: 3.9.8
 Homepage: http://search.cpan.org/dist/RTx-Calendar/
-Vcs-Git: git://anonscm.debian.org/pkg-request-tracker/rt-extension-calendar.git
-Vcs-Browser: http://anonscm.debian.org/?p=pkg-request-tracker/rt-extension-calendar.git
+Vcs-Browser: https://salsa.debian.org/request-tracker-team/rt-extension-calendar
+Vcs-Git: https://salsa.debian.org/request-tracker-team/rt-extension-calendar.git
 
 Package: rt4-extension-calendar
 Architecture: all


signature.asc
Description: Digital Signature

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[Niko Tyni]

On Fri, Feb 15, 2019 at 08:55:16PM +0100, gregor herrmann wrote:

> > > - As for the implementation in [0]:
> > >   not sure if the "exit 0" in smoke is correct
> 
> This still confuses me.
> Shouldn't it "exit $?" or just nothing (line 174)?

It's a "set -e" script so a failure from test.pl should stop processing
before the 'exit 0'. But yeah, the flow could be a bit clearer.

> > > - What about the skipped tests within use.t and syntax.t? Should they
> > >   or some of them also exit 77?
> > runner do it for them. 
> 
> Well, only partially. First of all, runners can run more than one
> test in a subdirectory (even if we currently only have 3 files in 4
> subdirectories, with 3 times 1 and 1 time zero), second, there are
> several places in syntax.t and use.t were all or parts of the tests
> are skipped. -- But:
> 
> > I didn't modify them if all is skipped as it has
> > no effect on a test marked as "superficial": 0 or 77 gives the same
> > result: no benefit, no penalty
> 
> … this "no benefit, no penalty" makes it indeed kind of moot :)

Given we need to mark the superficial tests as skippable (due to
the runner change), it would seem cleaner to me to make them signal
properly also the other cases of skipping. But I can see it doesn't
matter that much.

> (Random note, so we don't forget it: There are a few adjusted copies
> of the autodep8 file in various packages as debian/tests/control
> which should also be adjusted, at least in git for the next upload.)

AIUI these changes only affect packages without proper 'smoke'
tests. When 'smoke' is working correctly, neither the 'superficial'
nor the 'skippable' part really matters.

So adjusting those individual copies doesn't seem much of a priority
unless there are some where 'smoke' is skipped (or left out).
-- 
Niko

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable

[Jürgen Löb]

Package: linux-image-4.9.0-8-armmp-lpae

Version: 4.9.144-3

Severity: serious

Updated my Lamobo R1 board with apt update;apt upgrade

After the update uboot is struck at "Starting kernel". There is no
further output after "Starting kernel". Same happens on Bananapi 1
board. Unfortunately there is no more useful information.


I have been able to recover by downgrading to a backup kernel by
mounting the boot partiton on the sd card. Then:

dd if=boot.scr of=boot.script bs=72 skip=1 (extract script)

replaced  in boot.script:

setenv fk_kvers '4.9.0-8-armmp-lpae'

with

setenv fk_kvers '4.9.0-7-armmp-lpae'  (backup kernel that has been
available on my boot partition)

then:

mkimage -C none -A arm -T script -d boot.script boot.scr


Afterwards I have been able to boot the system with the old kernel
version. Then I was able to restore the previous version (4.9.130-2) with:

dpkg -i linux-image-4.9.0-8-armmp-lpae_4.9.130-2_armhf.deb (luckily
found the older package)

Upgrading to 4.9.144-3 again after this results in the unbootable
behavior again. Thus for sure the upgrade to 4.9.144-3 is causing the
problem.

---
Hiermit widerspreche ich/wir der Nutzung oder Uebermittlung 
meiner/unserer Daten fuer Werbezwecke oder fuer die Markt- oder 
Meinungsforschung gem. Par. 28 Abs. 3 Bundesdatenschutzgesetz.




signature.asc
Description: OpenPGP digital signature

Bug#862073: Uploading buildinfo files to buildinfo.debian.net

[Mattia Rizzolo]

On Sat, Feb 16, 2019 at 08:48:27AM -0800, Vagrant Cascadian wrote:
> On 2019-02-16, Mattia Rizzolo wrote:
> > Do you think you could provide more info about the kbsd and hurd
> > buildinfo that are unsigned?
> 
> Looks like kfreebsd were fixed at some point.
> 
> I'm not sure what more information is needed ... the .buildinfo files
> available on coccia are unsigned. The only current ones still failing
> are hurd-i386 or the infrequent developer uploads, for example:

ACK, I've asked youpi to have a look at his signing script (remember
that kbsd and hurd uploads are all manually signed by a DD).
Hopefully this will greatly reduce the number of unsigned buildinfo :)

> I've privately emailed some of the individual developer uploads when
> I've noticed, but haven't done a systematic look. Maybe it's time to do that.

Maybe after youpi confirms he improved his script.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[Niko Tyni]

On Wed, Feb 13, 2019 at 09:23:00PM +0100, Xavier Guimard wrote:
> Package: pkg-perl-autopkgtest
> Version: 0.50
> Severity: wishlist

>  - tests skipped should return a 77 exit code and all tests marked as
>"Restrictions: skippable". It avoids to consider that a test succeeds
>if maintainer skipped it, but needs a merge request to autodep8. See
>
> https://salsa.debian.org/ci-team/autodep8/blob/master/support/nodejs/generate
>(changed by MR !11)

Makes sense to me.

>  - runtime-deps* tests should be tagged as "Restrictions: superficial"
>since these tests don't really test package features but just Perl
>syntax
> 
> Then with this 2 changes, if "build-deps.d" is skipped, success won't
> give the benefit of 3-days-reduce.

I agree with the intention here. The only non-superficial test of the
current ones is indeed the 'smoke' test.

However, I have an "architectural" concern.

The proposed implementation overloads the 'runtime-deps' vs 'build-deps'
separation. Theoretically, we might come up with a 'runtime-deps' test
that is not superficial even though all of them currently are, or a
'build-deps' test that is superficial unlike the current ones.

The separation precedes autodep8 and was designed to make it possible to
update the set of standard pkg-perl autopkgtests without having to update
every package separately. This was later solved in a more centralized
way by autodep8.

I think we should probably get rid of this now unnecessary layer of
indirection and just list smoke, use.t and syntax.t in autodep8, with
the proper restrictions. This seems buster+1 material.

Please don't consider this a blocker or veto for the proposed
implementation. It's a clear improvement and does not make
it any harder to simplify the architecture later.

Thanks for working on this,
-- 
Niko

Bug#922413: runit-helper's Description is confusing

[Dmitry Bogatov]

[2019-02-15 11:20] Daniel Kahn Gillmor 
> runit-helper's Description claims to be an implementation detail of
> dh-sysuser, but then only talks about dh-runit.  I assume that
> dh-sysuser is an entirely different thing than dh-runit, so i'm
> confused.
>
> Is this just a copy/paste error?

Yes, it is copy/paste error. Thank you very much. Uploaded new version.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#922475: postfix: /etc/postfix/makedefs.out not turned into a symlink on upgrade

[Sven Joachim]

Control: tags -1 + patch

On 2019-02-16 18:01 +0100, Sven Joachim wrote:

> Package: postfix
> Version: 3.3.2-3
>
> Thanks for finally fixing #908545 and stopping to ship makedefs.out as a
> conffile.  However, there is a problem with it: the version in
> debian/postfix.mainstscript is way too low, and so the obsolete conffile
> remains on the system when upgrading from buster or sid.

Attached is a patch for that, untested because of #922477.  Note that
the assumption is that you apply it in the next upload, otherwise the
version will have to be adjusted further.  See
dpkg-maintscript-helper(1):

,
|  If  the conffile has not been shipped for several versions,
|  and you are now modifying the maintainer scripts  to  clean
|  up  the obsolete file, prior-version should be based on the
|  version of the package that you are now preparing, not  the
|  first version of the package that lacked the conffile. This
|  applies to all other actions in the same way.
`

Cheers,
   Sven

>From b9744df4dfc81c82c5d8db1a265cb2e9944ef588 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sat, 16 Feb 2019 18:13:34 +0100
Subject: [PATCH] Bump version in debian/postfix.maintscript

Closes: #922475
---
 debian/postfix.maintscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/postfix.maintscript b/debian/postfix.maintscript
index 7a81ec99..057c175e 100644
--- a/debian/postfix.maintscript
+++ b/debian/postfix.maintscript
@@ -1,2 +1,2 @@
 # moved to sharedir to not bother users with conffile prompts
-rm_conffile /etc/postfix/makedefs.out 3.2.4-2~ postfix
+rm_conffile /etc/postfix/makedefs.out 3.3.2-4~ postfix
-- 
2.20.1

Bug#776246: Processed: severity of 776246 is grave

[Andrey Rahmatullin]

On Sat, Feb 16, 2019 at 12:33:08PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > severity 776246 grave
> Bug #776246 [librsync1] MD4 collision/preimage attacks (CVE-2014-8242)
> Severity set to 'grave' from 'important'
> > thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
Fixing this requires a transition and removing or patching rdiff-backup so 

Checking reverse dependencies...
# Broken Depends:
burp: burp [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips 
mips64el mipsel ppc64el s390x]
csync2: csync2
duplicity: duplicity
rdiff-backup: rdiff-backup

# Broken Build-Depends:
burp: librsync-dev
csync2: librsync-dev
duplicity: librsync-dev (>= 0.9.6)
   rdiff
rdiff-backup: librsync-dev


Unfortunately I was too demotivated by the initial state of new librsync
(1.0+) and the API breakage affecting rdiff-backup to proceed with this
during the release cycle.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#922476: RFP: git-absorb -- easier fixup for rebasing git history

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: git-absorb
  Version : 0.3.0
  Upstream Author : Stephen Jung 
* URL : https://github.com/tummychow/git-absorb
* License : BSD-3
  Programming Lang: Rust
  Description : easier fixup for rebasing git history

You have a feature branch with a few commits. Your teammate reviewed
the branch and pointed out a few bugs. You have fixes for the bugs,
but you don't want to shove them all into an opaque commit that says
fixes, because you believe in atomic commits. Instead of manually
finding commit SHAs for git commit --fixup, or running a manual
interactive rebase, do this:

   git add $FILES_YOU_FIXED
   git absorb
   git rebase -i --autosquash master

git absorb will automatically identify which commits are safe to
modify, and which indexed changes belong to each of those commits. It
will then write fixup! commits for each of those changes. You can
check its output manually if you don't trust it, and then fold the
fixups into your feature branch with git's built-in autosquash
functionality.



I frequently do stuff like that:

 1. find the commit i want to modify with git log
 2. copy the commit id
 3. git commit -m'fixup! '
 4. git rebase -i

This automates steps 1-3.

This being Rust, I don't feel competent packaging it myself, it would
be great if some Rust people would look at it.

Thanks!

Bug#922477: postfix: FTBFS under Linux > 4

[Sven Joachim]

Source: postfix
Version: 3.3.2-3
Severity: important
Tags: ftbfs

I was trying to test a patch for #922475, but the build system barfed
when it saw my kernel:

,
| make[1]: Entering directory '/tmp/postfix'
| /usr/bin/make -f Makefile.in MAKELEVEL= Makefiles
| make: Entering directory '/tmp/postfix'
| (echo "# Do not edit -- this file documents how Postfix was built for your 
machine."; /bin/sh makedefs) >makedefs.tmp
| ATTENTION:
| ATTENTION: Unknown system type: Linux 5.0.0-rc6-nouveau
| ATTENTION:
| make: *** [Makefile.in:32: Makefiles] Error 1
`

Please tell upstream to stop this nonsense.  Linux kernel version
numbers don't really mean anything, as Linus has told the world for many
years.


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

Kernel: Linux 5.0.0-rc6-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#922334: ibus breaks KDE

[Charles Samuels]

Cross referencing with the KDE bug tracker:

KDE simply doesn't want ibus enabled:

https://bugs.kde.org/show_bug.cgi?id=379930

And exactly the same bug as mine:

https://bugs.kde.org/show_bug.cgi?id=379649

Bug#922386: VICE Commodore 8bit emulator does not play sound

[GCS]

Control: tags -1 +moreinfo

On Fri, Feb 15, 2019 at 11:33 AM Cambays Water  wrote:
> Vice seems to need package libmp3lame0 in order to play sound.
 It should _not_ as it's an mp3 encoding library and not a sound player.

> I also had to issue this command:
>
> ln -s /usr/lib/x86_64-linux-gnu/libmp3lame.so.0.0.0
> /usr/lib/x86_64-linux-gnu/libmp3lame.so
>
> because it searches for libmp3lame.so
 This is strange. I also have an amd64 type of machine and x64 can
find and open libmp3lame.so.0 on my system.

> After making the link sound was available.
 Which emulator did you try? Do you see "Sound: Available sound
devices: ..." line in the output of your emulator and what does it
contain?
Do you also see "Sound: Opened device ..." in the emulator output?
Also interested about your setting, please run:
$ grep SoundDeviceName ~/.config/vice/vicerc

Regards,
Laszlo/GCS

Bug#922334: ibus breaks KDE

[Osamu Aoki]

> When I rested KDE(testing), Konsole which was open lost key-input but
> newly started konsole worked and mose kept working under KDE.

When I tested KDE(testing), Konsole which was open lost proper key-input but
the newly started Konsole accepted key-input and working under KDE
after exiting the ibus panel.

Bug#922474: (no subject)

[Мартин Борисов]

I used apt-get install linux-headers-4.19 and i get it to install this.

root@Hosting:/home# apt-get install linux-headers-4.19
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'linux-headers-4.19.0-2-amd64' for regex 'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-all' for regex 'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-686:i386' for regex 'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-rt-amd64' for regex 'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-all-amd64' for regex 
'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-common-rt' for regex 
'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-all-i386:i386' for regex 
'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-686-pae:i386' for regex 
'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-common' for regex 'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-rt-686-pae:i386' for regex 
'linux-headers-4.19'
Note, selecting 'linux-headers-4.19.0-2-cloud-amd64' for regex 
'linux-headers-4.19'
The following additional packages will be installed:
linux-compiler-gcc-8-x86 linux-kbuild-4.19
The following NEW packages will be installed:
linux-compiler-gcc-8-x86 linux-headers-4.19.0-2-686:i386 
linux-headers-4.19.0-2-686-pae:i386 linux-headers-4.19.0-2-all 
linux-headers-4.19.0-2-all-amd64
linux-headers-4.19.0-2-all-i386:i386 linux-headers-4.19.0-2-amd64 
linux-headers-4.19.0-2-cloud-amd64 linux-headers-4.19.0-2-common 
linux-headers-4.19.0-2-common-rt
linux-headers-4.19.0-2-rt-686-pae:i386 linux-headers-4.19.0-2-rt-amd64 
linux-kbuild-4.19
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.6 MB of archives.
After this operation, 116 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian testing/main amd64 linux-compiler-gcc-8-x86 
amd64 4.19.16-1 [212 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-common all 4.19.16-1 [8,131 kB]
Get:3 http://deb.debian.org/debian testing/main amd64 linux-kbuild-4.19 amd64 
4.19.16-1 [445 kB]
Get:4 http://deb.debian.org/debian testing/main i386 linux-headers-4.19.0-2-686 
i386 4.19.16-1 [681 kB]
Get:5 http://deb.debian.org/debian testing/main i386 
linux-headers-4.19.0-2-686-pae i386 4.19.16-1 [682 kB]
Get:6 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-amd64 amd64 4.19.16-1 [688 kB]
Get:7 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-cloud-amd64 amd64 4.19.16-1 [450 kB]
Get:8 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-common-rt all 4.19.16-1 [6,354 kB]
Get:9 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-rt-amd64 amd64 4.19.16-1 [686 kB]
Get:10 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-all-amd64 amd64 4.19.16-1 [213 kB]
Get:11 http://deb.debian.org/debian testing/main amd64 
linux-headers-4.19.0-2-all amd64 4.19.16-1 [212 kB]
Get:12 http://deb.debian.org/debian testing/main i386 
linux-headers-4.19.0-2-rt-686-pae i386 4.19.16-1 [680 kB]
Get:13 http://deb.debian.org/debian testing/main i386 
linux-headers-4.19.0-2-all-i386 i386 4.19.16-1 [213 kB]
Fetched 19.6 MB in 5s (4,217 kB/s)
Selecting previously unselected package linux-compiler-gcc-8-x86.
(Reading database ... 32251 files and directories currently installed.)
Preparing to unpack .../00-linux-compiler-gcc-8-x86_4.19.16-1_amd64.deb ...
Unpacking linux-compiler-gcc-8-x86 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-common.
Preparing to unpack .../01-linux-headers-4.19.0-2-common_4.19.16-1_all.deb ...
Unpacking linux-headers-4.19.0-2-common (4.19.16-1) ...
Selecting previously unselected package linux-kbuild-4.19.
Preparing to unpack .../02-linux-kbuild-4.19_4.19.16-1_amd64.deb ...
Unpacking linux-kbuild-4.19 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-686:i386.
Preparing to unpack .../03-linux-headers-4.19.0-2-686_4.19.16-1_i386.deb ...
Unpacking linux-headers-4.19.0-2-686:i386 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-686-pae:i386.
Preparing to unpack .../04-linux-headers-4.19.0-2-686-pae_4.19.16-1_i386.deb ...
Unpacking linux-headers-4.19.0-2-686-pae:i386 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-amd64.
Preparing to unpack .../05-linux-headers-4.19.0-2-amd64_4.19.16-1_amd64.deb ...
Unpacking linux-headers-4.19.0-2-amd64 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-cloud-amd64.
Preparing to unpack 
.../06-linux-headers-4.19.0-2-cloud-amd64_4.19.16-1_amd64.deb ...
Unpacking linux-headers-4.19.0-2-cloud-amd64 (4.19.16-1) ...
Selecting previously unselected package linux-headers-4.19.0-2-common-rt.
Preparing to unpack .../07-linux-headers-4.19.0-2-common-rt_4.19.16-1_all.deb 
...
Unpacking

Bug#922475: postfix: /etc/postfix/makedefs.out not turned into a symlink on upgrade

[Sven Joachim]

Package: postfix
Version: 3.3.2-3

Thanks for finally fixing #908545 and stopping to ship makedefs.out as a
conffile.  However, there is a problem with it: the version in
debian/postfix.mainstscript is way too low, and so the obsolete conffile
remains on the system when upgrading from buster or sid.


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

Kernel: Linux 5.0.0-rc6-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-6
ii  debconf [debconf-2.0]  1.5.70
ii  dpkg   1.19.5
ii  e2fsprogs  1.44.5-1
ii  libc6  2.28-7
ii  libdb5.3   5.3.28+dfsg1-0.3
ii  libicu63   63.1-6
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1a-1
ii  lsb-base   10.2018112800
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.2-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-1
ii  emacs-gtk [mail-reader]   1:26.1+1-3.2
ii  emacs-snapshot [mail-reader]  1:20190131-1
ii  libsasl2-modules  2.1.27+dfsg-1
ii  mailutils [mail-reader]   1:3.5-2
ii  mutt [mail-reader]1.10.1-2
pn  postfix-cdb   
ii  postfix-doc   3.3.2-3
pn  postfix-ldap  
pn  postfix-lmdb  
pn  postfix-mysql 
pn  postfix-pcre  
pn  postfix-pgsql 
ii  postfix-sqlite3.3.2-3
ii  procmail  3.22-26
pn  resolvconf
ii  s-nail [mail-reader]  14.9.11-2
ii  thunderbird [mail-reader] 1:60.5.1-1
pn  ufw   

-- debconf information:
  postfix/bad_recipient_delimiter:
* postfix/mailbox_limit: 0
  postfix/relay_restrictions_warning:
* postfix/mailname: localhost.localdomain
* postfix/relayhost: mail.gmx.net
* postfix/lmtp_retired_warning: true
* postfix/chattr: false
  postfix/newaliases: false
* postfix/recipient_delim: +
  postfix/not_configured:
  postfix/kernel_version_warning:
  postfix/main_cf_conversion_warning: true
* postfix/procmail: true
* postfix/protocols: all
* postfix/sqlite_warning: true
* postfix/destinations: turtle.local, turtle, localhost.localdomain, localhost
* postfix/main_mailer_type: Internet with smarthost
* postfix/dynamicmaps_conversion_warning: true
  postfix/rfc1035_violation: false
* postfix/compat_conversion_warning: true
  postfix/mydomain_warning:
* postfix/root_address: sven
  postfix/tlsmgr_upgrade_warning:
* postfix/mynetworks: 127.0.0.0/8
  postfix/retry_upgrade_warning:

Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[Simon McVittie]

(Cross-posting to debian-devel, but with Reply-To to the bug)

On Sat, 16 Feb 2019 at 09:32:16 +0100, W. Martin Borgert wrote:
> at the moment, .gir files are placed under /usr/share/gir-1.0/.
> However, such files can contain architecture specific content.
> What would be the right directory? /usr/share/gir-1.0//?

The vast majority of GIR files are architecture-independent, so the
majority of GIR files should stay where they are in any case.

Multiarch-qualified directories under /usr/share don't seem like they make
much sense: the whole point of the $libdir/$datadir duality is that if
files need to be different on some architectures, then the files should
be in $libdir, not in $datadir.

However, the search path for GIR files is effectively part of the API
of gobject-introspection, and it's documented to use $XDG_DATA_DIRS as
defined in the freedesktop.org Base Directory specification (defaulting to
/usr/local/share:/usr/share as per the spec), so any change to how this
works would need to be discussed with gobject-introspection's upstream
developers (regardless of what the specific directory was).

My understanding is that GIR is intended to be a collection of
machine-readable facts about the source code, rather than facts about
the binary, which is why it's in /usr/share in the first place (unlike
the typelib, which is architecture-dependent). However, those facts are
partially derived from inspecting the binary, so can in principle end
up different in rare cases, and presumably that is what's happened here.

The program that generates GIR (g-ir-scanner) is architecture-independent
Python code, so it's easy to say "gobject-introspection should look in
its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
probably harder to actually implement than you might think.

One option for fixing this for buster, if it is considered to be urgent,
is to investigate what the difference is and whether it can be eliminated,
perhaps by wrapping the code that differs between architectures in
#ifndef __GI_SCANNER__.

Another is to remove the M-A: same annotation.

smcv

Bug#922474: Problem with linux-headers-4.19.0-1-amd64 in Debian Buster Alpha 5

[Мартин Борисов]

Package: linux-headers
Version: 4.19.0-1-amd64

I set my /apt/sources.list like this (witout the 1. 2. 3. numbers and dots)
*  deb http://deb.debian.org/debian/ testing main contrib non-free
*  deb-src http://deb.debian.org/debian/ testing main contrib non-free
*  deb http://deb.debian.org/debian/ testing-updates main contrib non-free
*  deb-src http://deb.debian.org/debian/ testing-updates main contrib non-free
*  deb http://deb.debian.org/debian-security testing/updates main
*  deb-src http://deb.debian.org/debian-security testing/updates main
After i use apt-get update && apt-get upgrade && apt-get dist-upgrade
After i use apt-get install linux-headers-$(uname-r) and i get the message 
bellow
*  root@Hosting:/etc/apt# apt-get install linux-headers-$(uname -r)
*  Reading package lists... Done
*  Building dependency tree
*  Reading state information... Done
*  E: Unable to locate package linux-headers-4.19.0-1-amd64
*  E: Couldn't find any package by glob 'linux-headers-4.19.0-1-amd64'
*  E: Couldn't find any package by regex 'linux-headers-4.19.0-1-amd64'
I am using Linux Hosting 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) 
x86_64 GNU/Linux

-- 
Мартин Борисов

Bug#922334: ibus breaks KDE

[Osamu Aoki]

Hi,

On Sat, Feb 16, 2019 at 08:27:49AM -0800, Charles Samuels wrote:
> On Saturday, February 16, 2019 4:07:41 PM PST Osamu Aoki wrote:
> > Hi,
> > 
> > I just installed KDE (testing) to see...
> > 
> > I agree this is not the best situation for people under non-Gnome.
> > 
> > On Fri, Feb 15, 2019 at 04:33:08PM -0800, Charles Samuels wrote:
> > > > > If I exit that, the keyboard stopped working.
> > > > 
> > > > You killed input method... so your key stop working.  It's nice if ibus
> > > > tray is robust to restart automatically to enable keyboard.  But ...
> > > > Excuse me this is not important bug.
> > > 
> > > I didn't "kill" the input method. I choose "Exit" from its
> > > right-click-menu.
> > Yah.  Right click menu has "Exit" which stops panel process.
> > 
> > That certainly causes lots of problem on keyboard input to running
> > processes.  Maybe "Exit" shouldn't be there to prevent people to stop it
> > casually.  You are not supposed to exit this panel process.
> 
> Does "Exit" break keyboard inputs on Gnome? It might be a clue for a root 
> cause.

Gnome doesn't start ibus-setup etc.  It has it's own script written in
javascript for gnome-shell.  KDE may have created their own and stop
using ibus-setup and panel apps provided by ibus.
 
> What's curious is that having ibus not installed only breaks it on 
> applications that started as part of the session, and not new processes that 
> I 
> manually start after login.

When I rested KDE(testing), Konsole which was open lost key-input but
newly started konsole worked and mose kept working under KDE.

Osamu

Bug#862073: [rb-general] Bug#862073: Uploading buildinfo files to buildinfo.debian.net

[Vagrant Cascadian]

On 2019-02-16, Mattia Rizzolo wrote:
> On Fri, Feb 15, 2019 at 01:51:40PM -0800, Vagrant Cascadian wrote:
>> There are a few individual developers uploading unsigned .buildinfo
>> files, as well as a few buildds for non-release architectures
>> (e.g. hurd-i386, kfreebsd-*). To hadle those, I actually had a
>> legitimate use for the technique described in:
>> 
>>   https://xkcd.com/1181/
>
> Do you think you could provide more info about the kbsd and hurd
> buildinfo that are unsigned?

Looks like kfreebsd were fixed at some point.

I'm not sure what more information is needed ... the .buildinfo files
available on coccia are unsigned. The only current ones still failing
are hurd-i386 or the infrequent developer uploads, for example:

NOSIGNATURE: 
['/srv/ftp-master.debian.org/buildinfo/2019/02/16/gcc-9_9-20190215-1_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/acl_2.2.52-5_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/attr_2.4.47-4_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/usepackage_1.13-4_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/libocas_0.97+dfsg-5_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/lxqt-metapackages_28_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/ocaml-mm_0.4.0-1_hurd-i386.buildinfo',
'/srv/ftp-master.debian.org/buildinfo/2019/02/16/postfix_3.3.2-2_amd64.buildinfo']

I've privately emailed some of the individual developer uploads when
I've noticed, but haven't done a systematic look. Maybe it's time to do that.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922473: RFS: pokemmo-installer/1.4.7-2 -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pokemmo-installer"

 * Package name: pokemmo-installer
   Version : 1.4.7-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/pokemmo-installer/wikis
 * License : GPL-3+ with OpenSSL exception
   Section : contrib/games

  It builds those binary packages:

  pokemmo-installer - Installer and Launcher for the PokeMMO emulator

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

  https://mentors.debian.net/package/pokemmo-installer

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pokemmo-installer/pokemmo-installer_1.4.7-2.dsc

  More information about Pokemmo Installer can be obtained from 
https://gitlab.com/coringao/pokemmo-installer.

  Changes since the last upload:

  pokemmo-installer (1.4.7-2) unstable; urgency=medium

  * Switch to compat level 12
  * debian/control:
+ Bump debhelper compat to 12
+ Bump Standards-Version to 4.3.0
  * Updated d/copyright years
  * Update d/upstream/metadata years
  * Added tarball option 'bz2' from file d/watch

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#922472: gnome-menus-blacklist: not found

[Alex Henry]

Package: gnome-menus
Version: 3.31.4-3
Severity: normal

Dear Maintainer,

Upon trying to install the latest Discord .deb package, I have come across this
issue. Exploring the contents of the Discord .deb file, I could find nothing
related to gnome-menus in particular so I'm assuming the problem is in the
gnome-menus package and not deriving from installing a third-party .deb.

As a workaround, I deleted my gnome-menus package, installed the Discord .deb
and then reinstalled gnome-menus (which is required by menulibre, otherwise I'd
just leave it uninstalled). Through this workaround, every step worked normally
without any errors or warnings.

A big thank you to everyone involved in maintaining these packages!

Here's the console output in question:

root@hydra:/tmp# dpkg -i discord-0.0.8.deb
(Reading database ... 263433 files and directories currently installed.)
Preparing to unpack discord-0.0.8.deb ...
Unpacking discord (0.0.8) over (0.0.8) ...
Setting up discord (0.0.8) ...
Processing triggers for gnome-menus (3.31.4-3) ...
/var/lib/dpkg/info/gnome-menus.postinst: 4: /var/lib/dpkg/info/gnome-
menus.postinst: gnome-menus-blacklist: not found
dpkg: error processing package gnome-menus (--install):
 installed gnome-menus package post-installation script subprocess returned
error exit status 127
Processing triggers for desktop-file-utils (0.23-4) ...
Processing triggers for mime-support (3.61) ...
Errors were encountered while processing:
 gnome-menus



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 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

Versions of packages gnome-menus depends on:
ii  python3  3.7.2-1

gnome-menus recommends no packages.

gnome-menus suggests no packages.

-- no debconf information

Bug#921598: No METAR available since noaa.gov switched to https

[Gabriel F. T. Gomes]

On Sat, Feb 16 2019, Florent Rougon wrote:
> 
> As has been discussed on flightgear-devel and despite the commit
> message, commit [1] is not a proper fix and will probably be reverted (I
> mean, the "if( responseCode() >= 400 )" part, not the http to https URL
> change which is okay though unnecessary now that redirection is fixed in
> SimGear's HTTP::Client).

OK, thanks for the clarification.

> The correct fix is [a]. [b] is also a bug fix in this area, but doesn't
> solve the particular METAR fetching problem.
> 
> [a] 
> https://sourceforge.net/p/flightgear/simgear/ci/34b3c52a288d62779073fc7694344d0658755645/
> [b] 
> https://sourceforge.net/p/flightgear/simgear/ci/6197098541eceecdb0dcfe8a58b15f0d0773c391/

I'll close the merge request.

Thanks,
Gabriel

Bug#922334: ibus breaks KDE

[Charles Samuels]

On Saturday, February 16, 2019 4:07:41 PM PST Osamu Aoki wrote:
> Hi,
> 
> I just installed KDE (testing) to see...
> 
> I agree this is not the best situation for people under non-Gnome.
> 
> On Fri, Feb 15, 2019 at 04:33:08PM -0800, Charles Samuels wrote:
> > > > If I exit that, the keyboard stopped working.
> > > 
> > > You killed input method... so your key stop working.  It's nice if ibus
> > > tray is robust to restart automatically to enable keyboard.  But ...
> > > Excuse me this is not important bug.
> > 
> > I didn't "kill" the input method. I choose "Exit" from its
> > right-click-menu.
> Yah.  Right click menu has "Exit" which stops panel process.
> 
> That certainly causes lots of problem on keyboard input to running
> processes.  Maybe "Exit" shouldn't be there to prevent people to stop it
> casually.  You are not supposed to exit this panel process.

Does "Exit" break keyboard inputs on Gnome? It might be a clue for a root 
cause.

What's curious is that having ibus not installed only breaks it on 
applications that started as part of the session, and not new processes that I 
manually start after login.

Bug#835913: ibus: use of dbus-run-session ...

[Simon McVittie]

I'm testing a real patch, which should be a bit cleaner and more
upstreamable than the untested pseudo-patch I gave on the bug (I didn't
have time to do this for every package during the mass-bug-filing).

On Sat, 16 Feb 2019 at 08:20:45 +0900, Osamu Aoki wrote:
> dbus[22693]: Unable to set up transient service directory: XDG_RUNTIME_DIR 
> "/run/user/1000" not available: No such file or directory

Unfortunately, official buildds that use sbuild don't have a
properly-set-up XDG_RUNTIME_DIR. They inherit the environment variable
from the host system, but they don't create the corresponding directory
in the chroot.

If a package needs an XDG_RUNTIME_DIR for its build or tests, you
will have to set up a temporary XDG_RUNTIME_DIR, either in debian/rules
(like glib2.0 does) or in the upstream build system. Or, if it copes
gracefully with XDG_RUNTIME_DIR being unset, you could unset it.

For instance, you could maybe add this to make-dconf-override-db.sh:

export XDG_RUNTIME_DIR="$TMPDIR/run"

> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or 
> kill -l [sigspec]
> make[5]: *** [Makefile:809: 00-upstream-settings] Error 2

It looks as though this is the real cause of the build failure.
You missed the part of my pseudo-patch that removed
"kill $DBUS_SESSION_BUS_PID" near the end of the script.

smcv

Bug#864079: I am onboard the team to help package BackupPC V4

[sixerjman]

I have been tracking and using the upstream version of BackupPC V4 for
awhile and would
like to help out as a set of eyes and testing. I am currently using V4.2.1
but will be upgrading
to V4.3.0 this weekend. Thanks for all your efforts with this marvelous
software backup suite!

Bug#922452: sopel: Missing dependency to python3-dnspython

[Antoine Beaupré]

Control: clone 922452 -1 -2
Control: reassign -2 dh-python

On 2019-02-16 10:23:23, Adrien CLERC wrote:
> Hi,
>
> After starting sopel, I got the following errors:
>
> pkg_resources.DistributionNotFound: The 'dnspython<3.0' distribution was
> not found and is required by sopel
>
> It was removed for an unkown reason on my system 6 days ago. Maybe a
> transitive dependency was removed?
>
> Reinstalling python3-dnspython manually fixed the issue

Hi!

Thank you for your bug report. This should be fixed in the next upload
of sopel, but i think it hilights a problem with the underlying Python
build tools. Those *should* have noticed the dnspython dependency, as
it's specified in `requirements.txt`:

https://salsa.debian.org/debian/sopel/raw/debian/requirements.txt

In setup.py, the requirements list is read from the file:

   requires = read_reqs('requirements.txt')
   [...]
   setup([...], install_requires=requires, [...])

Other dependencies *are* picked up form there (and not specified in the
control file):

 Depends: python3-geoip2, python3-praw, python3-requests, python3-tz, 
python3-xmltodict, python3:any, adduser, lsb-base (>= 3.0-6)

It might be that the extra comparitive logic in the file confuses the
parse:

dnspython<2.0; python_version >= '2.7' and python_version < '3.0'
dnspython<1.16.0; python_version == '3.3'
dnspython<3.0; python_version >= '3.4'

... but I don't have time to investigate this further, unfortunately.

A.

-- 
A riot is the language of the unheard.
 - Martin Luther King, Jr.

Bug#922467: Noise from wkhtmltopdf ends up in the process' stdout/stderr

[Enrico Zini]

Package: python3-pdfkit
Version: 0.6.1-1
Severity: normal

Hello,

thanks for packaging pdfkit.

In the current buster, using pdfkit results in noise to the program's
output streams:

$ cat /tmp/foo.py
import pdfkit

pdfkit.from_string("foo", "/tmp/test.pdf")

$ python3 /tmp/foo.py
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Loading page (1/2)
Printing pages (2/2)   
Done   


This is unfortunately almost a showstopper for using pdfkit on command
line tools.

Enrico

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

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

Versions of packages python3-pdfkit depends on:
ii  python3  3.7.2-1
ii  wkhtmltopdf  0.12.4-1

python3-pdfkit recommends no packages.

python3-pdfkit suggests no packages.

-- no debconf information

Bug#921598: No METAR available since noaa.gov switched to https

[Florent Rougon]

Hello,

"Gabriel F. T. Gomes"  wrote:

> I updated the merge request.
>
> When I first wrote the merge request, upstream did not have a fix for
> the METAR problem.  Now they do [1].  So, I removed the simple patch I
> wrote, and replaced it with this upstream fix.

(...)

> [1]
> https://sourceforge.net/p/flightgear/flightgear/ci/2fdc24c1097955c5d2c88a9cc0be66069b22eebe/

As has been discussed on flightgear-devel and despite the commit
message, commit [1] is not a proper fix and will probably be reverted (I
mean, the "if( responseCode() >= 400 )" part, not the http to https URL
change which is okay though unnecessary now that redirection is fixed in
SimGear's HTTP::Client).

The correct fix is [a]. [b] is also a bug fix in this area, but doesn't
solve the particular METAR fetching problem.

[a] 
https://sourceforge.net/p/flightgear/simgear/ci/34b3c52a288d62779073fc7694344d0658755645/
[b] 
https://sourceforge.net/p/flightgear/simgear/ci/6197098541eceecdb0dcfe8a58b15f0d0773c391/

-- 
Florent

Bug#922465: joystick: Please use device IDs instead of names for calibration state

[Guillem Jover]

Hi!

On Sat, 2019-02-16 at 16:20:43 +0100, Stephen Kitt wrote:
> On Sat, 16 Feb 2019 16:08:35 +0100, Guillem Jover  wrote:
> > The jscal-store and jscal-restore programs are great! The problem is that
> > they use the device names (such as js0) as keys for the calibration state,
> > which means that if you've got multiple and different devices then you
> > need to connect them all in the same order for them to get the correct
> > calibration.
> > 
> > It would be nice if the state used something like the device IDs as keys
> > instead.
> 
> It already does, at least if a name can be found for the device.

Ah, right I see now from the jscal-*store code, was confused by the
udev rule which only passes the name and the state which only had the
DEVICE= attribute for all my joysticks.

> What does
> 
> udevadm info -a -n /dev/input/js0 | /usr/share/joystick/ident

For all of them it just returns stuff like:

  ,---
  DEVICE="js2"
  NAME=""
  SERIAL=""
  VENDOR=""
  PRODUCT=""
  `---

with changed DEVICE names.

> output on your system, with your various joysticks connected?

I'm including the whole «udevadm info» output for various devices
I've just got connected now. This is with Linux 4.20.x from
experimental, but was the same with 4.19.x several weeks ago when
I first tried.

,--- /dev/input/js0 ---

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/input/input18/js0':
KERNEL=="js0"
SUBSYSTEM=="input"
DRIVER==""
ATTR{SUBSYSTEM}=="input"
ATTR{MAJOR}=="13"
ATTR{MINOR}=="0"
ATTR{USEC_INITIALIZED}=="1023960455"
ATTR{ID_INPUT}=="1"

  looking at parent device '/devices/virtual/input/input18':
KERNELS=="input18"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{SUBSYSTEM}=="input"
ATTRS{PRODUCT}=="19/1014/5054/6801"
ATTRS{NAME}==""ThinkPad HDAPS joystick emulation""
ATTRS{PHYS}==""hdaps/input0""
ATTRS{PROP}=="0"
ATTRS{EV}=="9"
ATTRS{ABS}=="3"
ATTRS{MODALIAS}=="input:b0019v1014p5054e6801-e0,3,kra0,1,mlsfw"
ATTRS{USEC_INITIALIZED}=="1023959158"
ATTRS{ID_INPUT}=="1"

`---

,--- /dev/input/js1 ---

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/input/input19/js1':
KERNEL=="js1"
SUBSYSTEM=="input"
DRIVER==""
ATTR{SUBSYSTEM}=="input"
ATTR{MAJOR}=="13"
ATTR{MINOR}=="1"
ATTR{USEC_INITIALIZED}=="1023961422"
ATTR{ID_INPUT}=="1"

  looking at parent device '/devices/virtual/input/input19':
KERNELS=="input19"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{SUBSYSTEM}=="input"
ATTRS{PRODUCT}=="19/1014/5054/4801"
ATTRS{NAME}==""ThinkPad HDAPS accelerometer data""
ATTRS{PHYS}==""hdaps/input1""
ATTRS{PROP}=="0"
ATTRS{EV}=="9"
ATTRS{ABS}=="3"
ATTRS{MODALIAS}=="input:b0019v1014p5054e4801-e0,3,kra0,1,mlsfw"
ATTRS{USEC_INITIALIZED}=="1023959728"
ATTRS{ID_INPUT}=="1"

`---

,--- /dev/input/js2 ---

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device 
'/devices/pci:00/:00:1d.0/usb6/6-1/6-1:1.0/0003:054C:0268.000A/input/input33/js2':
KERNEL=="js2"
SUBSYSTEM=="input"
DRIVER==""
ATTR{SUBSYSTEM}=="input"
ATTR{MAJOR}=="13"
ATTR{MINOR}=="2"
ATTR{USEC_INITIALIZED}=="137765902111"
ATTR{ID_INPUT}=="1"
ATTR{ID_INPUT_JOYSTICK}=="1"
ATTR{ID_VENDOR}=="Sony"
ATTR{ID_VENDOR_ENC}=="Sony"
ATTR{ID_VENDOR_ID}=="054c"
ATTR{ID_MODEL}=="PLAYSTATION_R_3_Controller"
ATTR{ID_MODEL_ENC}=="PLAYSTATION\x28R\x293\x20Controller"
ATTR{ID_MODEL_ID}=="0268"
ATTR{ID_REVISION}=="0100"
ATTR{ID_SERIAL}=="Sony_PLAYSTATION_R_3_Controller"
ATTR{ID_TYPE}=="hid"
ATTR{ID_BUS}=="usb"
ATTR{ID_USB_INTERFACES}==":03:"
ATTR{ID_USB_INTERFACE_NUM}=="00"
ATTR{ID_USB_DRIVER}=="usbhid"
ATTR{ID_PATH}=="pci-:00:1d.0-usb-0:1:1.0"
ATTR{ID_PATH_TAG}=="pci-_00_1d_0-usb-0_1_1_0"

  looking at parent device 
'/devices/pci:00/:00:1d.0/usb6/6-1/6-1:1.0/0003:054C:0268.000A/input/input33':
KERNELS=="input33"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{SUBSYSTEM}=="input"
ATTRS{PRODUCT}=="3/54c/268/8111"
ATTRS{NAME}==""Sony PLAYSTATION(R)3 Controll

Bug#922457: [Pkg-fonts-devel] Bug#922457: fonts-roboto-hinted: update broke reverse-dependencies without notice

[Norbert Preining]

On Sat, 16 Feb 2019, Markus Koschany wrote:
> the recent upload of fonts-roboto broke reverse-dependencies like
> renpy because you removed or renamed previously installed files in
> fonts-roboto-hinted. I find that less than optimal given that we have
> entered the soft freeze for Debian 10. Please revert this change or
> provide the missing files again.

+1, same problem here with TeX Live packages suddently having dead
links.

Norbert

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

Bug#922462: git debrebase convert-from-gbp fails on cups-filters with unhelpful error message

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#922462: git debrebase convert-from-gbp fails 
on cups-filters with unhelpful error message"):
> Package: git-debrebase
> Version: 8.3
> Severity: important
> 
> Hi there,
> 
> Just after importing cups-filters' latest upstream releas, I considered moving
> to git debrebase (for the occasional patches); but didn't manage:
> 
> $ export LANG=C
> $ git clone -b debian/experimental 
> https://salsa.debian.org/printing-team/cups-filters/ cups-filters 
> $ cd cups-filters
> $ git debrebase convert-from-gbp
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> Use of uninitialized value $_[1] in sprintf at 
> /usr/share/dgit/gdr/perl5/Debian/Dgit/I18n.pm line 26.
>  at /usr/share/dgit/gdr/perl5/Debian/Dgit.pm line 145.

Indeed it does this for me too.  This is clearly a bug.

For my reference: the input commit is
3d4187026eb5d427f287059b694dbe6543e34bce

Ian.

Bug#921985: munin-node: df plugin fails to get data for /home

[Marc Donges]

Hi Holger,

thanks for the prompt reply.

I understand the security benefits this presents in combination with
ProtectSystem=full.

However, a separate /home is a common configuration and this problem can
easily be overlooked and is then not trivial to find, because there are no
error messages anywhere, there is just this odd difference in reality
between munin-node as a daemon and everything else the sysadmin does
manually on the CLI.

I think to make this less awkward two things would be nice:

- a option to allow monitoring of /home without editing a non-conffile in
/lib (How is this even done properly? I just edited the service file to
find the cause of my problem, but I suppose it will be overwritten on every
update. Is there a nice way to do this?)

- a way to alert the admin of the possibly unintended configuration:
df-plugin activated + ProtectHome + Separate /home
Can the df* plugin itself detect the situation and then make a log entry?
That would have severely cut down the time it took me to find this.

Cheers
Marc




On Mon, 11 Feb 2019 at 11:45, Holger Levsen  wrote:

> Hi Marc,
>
> On Mon, Feb 11, 2019 at 01:09:37AM +0100, Lars Kruse wrote:
> > > # Plugins like "df" require access to /home if that is a separate
> filesystem
> > > ProtectHome=false
> > See the other bug report for this issue:
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918851
> > We are discussing whether there is good way to work around this.
>
> IMO this is a good default. If you want to monitor /home (and accept the
> risk that munin-node (and all its plugins) can access /home, you can
> modify the service file locally and get what you want.
>
> Suggestions where&how to document this better welcome!
>
>
> --
> tschau,
> Holger
>
>
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>


-- 
Marc A. Donges
Kaiserallee 50
76185 Karlsruhe
☎ +49 177 59 666 43 • marc.don...@gmail.com