Bug#898032: Warnings upon start

[積丹尼 Dan Jacobson]

Package: gpxviewer
Version: 0.5.2-1

Warnings upon start:

$ gpxviewer
/usr/bin/gpxviewer:28: PyGIWarning: Gdk was imported without specifying a 
version first. Use gi.require_version('Gdk', '3.0') before import to ensure 
that the right version gets loaded.
  from gi.repository import Gdk
/usr/share/gpxviewer/gpxviewer/ui.py:26: PyGIWarning: Gtk was imported without 
specifying a version first. Use gi.require_version('Gtk', '3.0') before import 
to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/share/gpxviewer/gpxviewer/ui.py:30: PyGIWarning: OsmGpsMap was imported 
without specifying a version first. Use gi.require_version('OsmGpsMap', '1.0') 
before import to ensure that the right version gets loaded.
  from gi.repository import OsmGpsMap
/usr/share/gpxviewer/gpxviewer/pygtk_chart/chart.py:42: PyGIWarning: PangoCairo 
was imported without specifying a version first. Use 
gi.require_version('PangoCairo', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import PangoCairo

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

[Scott Kitterman]

On Sat, 05 May 2018 19:42:05 +0100 Chris Lamb  wrote:
> tags 884499 + pending
> thanks
> 
> Actually, let's give this a whirl. Implemented in Git,
> pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/1ecc761fea7b22f85faf400ac134d24438454e4d
> 
>   checks/debhelper.desc  | 12 +++
>   checks/debhelper.pm|  5 -
>   debian/changelog   |  4 +++-
>   .../debian/debian/control.in   | 14 +
>   .../debian/debian/rules| 23 
> ++
>   .../desc   |  6 ++
>   .../tags   |  2 ++
>   7 files changed, 64 insertions(+), 2 deletions(-)

For what it's worth, this is an example of the kind of check that isn't 
supported by policy.  There's absolutely no requirement to use debhelper or 
CDBS, so it's not clear why lintian should have care.

There is nothing to fix based on this tag.  I know most won't see it since it's 
pedantic, but it isn't clear why it should exist at all.

Scott K

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

[Stuart Young]

I'm seeing this on a few laptops with SSD's.

The behaviour is that if the device isn't interacted with in any way, the
machines hang for 2-4 mins at boot.

Seems to be related to the fix for CVE-2018-1108 - random: fix crng_ready()
test

https://security-tracker.debian.org/tracker/CVE-2018-1108

Pedro & Sten, can you try introducing entropy into the systems affected
when they appear to hang, to see if this reduces the delays?

eg: moving the mouse, tapping shift/ctrl/alt keys, pinging the device on
the network if network is already up, etc?

I suspect this bug can be merged with 897599, 897632 and 897917.

-- 
Stuart Young (aka Cefiar)

Bug#898014: autopkgtest-pkg-python in Testsuite ignored if tests/control exists

[Russ Allbery]

Paul Gevers  writes:
> On 05-05-18 23:55, Russ Allbery wrote:

>> In other words, I would like to run the merger of the tests in
>> debian/tests/control plus the tests corresponding to any
>> autopkgtest-pkg-* entries in the Testsuite control field.

> Rename debian/tests/control to debian/tests/control.autodep8 and you get
> what you want as documented $(man autodep8).

Ah!  Sorry, I missed that entirely -- didn't read the right man pages.
Thank you.

-- 
Russ Allbery (r...@debian.org)   

Bug#898031: tracker.debian.org: display URL problems detected by Repology for debian_* repositories

[Paul Wise]

Package: tracker.debian.org
Severity: wishlist

The Debian package tracker has an action item about URLs:

   The URL(s) for this package had some recent persistent issues

Currently this only imports data from DUCK:

   http://duck.debian.net/

Another source of action items about URLs is Repology:

   https://repology.org/repository/debian_experimental/problems
https://repology.org/repository/debian_unstable/problems
https://repology.org/repository/debian_testing/problems
https://repology.org/repository/debian_stable/problems
https://repology.org/repository/debian_oldstable/problems

The JSON versions of these pages are here:

   https://repology.org/api/v1/repository/debian_experimental/problems
https://repology.org/api/v1/repository/debian_unstable/problems
https://repology.org/api/v1/repository/debian_testing/problems
https://repology.org/api/v1/repository/debian_stable/problems
https://repology.org/api/v1/repository/debian_oldstable/problems

These have a different set of suggestions to the ones by DUCK, so once
Repology pull request #615 (adding per-package problem reports) is merged and 
deployed on the repology website, it would be nice if the DPT URL issues action 
item could also import the JSON URLs above and emit links to the report pages 
for each package.

   https://github.com/repology/repology/pull/615
https://repology.org/repository/debian_experimental/problems/
https://repology.org/repository/debian_unstable/problems/
https://repology.org/repository/debian_testing/problems/
https://repology.org/repository/debian_stable/problems/
https://repology.org/repository/debian_oldstable/problems/

I'd suggest only reporting problems in a suite if the package is not
present in a "higher" suite. The unstable suite should count as higher
than experimental as per the usual suite ordering.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#898030: linux-image-4.15.0-0.bpo.2-amd64: 1366x768 at 40 Hz despite reporting 60 Hz

[Eduardo GV]

Package: src:linux
Version: 4.15.11-1~bpo9+1
Severity: important

Dear Maintainer,

* What led up to the situation?
Movement in HD videos appeared not smooth any more after a kernel update from 
4.13 to 4.15.
Then I checked with glgears and xrandr. Video vertical refresh rate is stuck at 
40 Hz despite attempts to set up 60 Hz back.
This happens at 1366x768 if the graphics card has a 40 Hz mode in addition to 
the usual 60 Hz.
My older laptop is not able of 40 Hz and then 60 Hz is used. This is why many 
have not noticed this yet. However, newer laptops come with a 40 Hz mode for 
power saving purposes and it is going to afect more and more users.

* What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to set up the video back to 1366x768@60 Hz, both with xrandr and the 
MATE Video Preferences frontend. 

* What was the outcome of this action?
The commands were silently accepted but the video refresh rate is still 40 Hz.

* What outcome did you expect instead?
I expected to have a correct 60 Hz refresh rate back and so get smooth movement 
in NTSC video.
This is only possible at 1366x768 by downgrading to kernel 4.13.

Remark: Kernel 4.14 was affected too, but user was too lazy to fill a report.
Kernel 4.13 is OK.


-- Package-specific info:
** Version:
Linux version 4.15.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.15.11-1~bpo9+1 
(2018-04-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-0.bpo.2-amd64 
root=UUID=9db2706e-7967-4fc1-b3b5-4044860a889b ro quiet

** Not tainted

** Kernel log:
[9.828812] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-3168-27.ucode (-2)
[9.828815] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-3168-27.ucode failed with error -2
[9.828836] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-3168-26.ucode (-2)
[9.828839] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-3168-26.ucode failed with error -2
[9.828859] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-3168-25.ucode (-2)
[9.828862] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-3168-25.ucode failed with error -2
[9.828882] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-3168-24.ucode (-2)
[9.828885] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-3168-24.ucode failed with error -2
[9.828904] iwlwifi :02:00.0: firmware: failed to load 
iwlwifi-3168-23.ucode (-2)
[9.828907] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-3168-23.ucode failed with error -2
[   10.075672] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-3168-22.ucode
[   10.076263] iwlwifi :02:00.0: loaded firmware version 22.361476.0 
op_mode iwlmvm
[   10.225476] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
3168, REV=0x220
[   10.248729] iwlwifi :02:00.0: base HW address: d4:25:8b:6c:73:7a
[   10.305607] Console: switching to colour frame buffer device 170x48
[   10.305739] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   10.336848] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   10.784254] [drm] RC6 on
[   10.847231] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:04F3:250E.0002/input/input10
[   10.847540] hid-multitouch 0003:04F3:250E.0002: input,hiddev0,hidraw1: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-6/input0
[   10.865345] media: Linux media interface: v0.10
[   10.905657] Linux video capture interface: v2.00
[   11.114301] Bluetooth: Core ver 2.22
[   11.114325] NET: Registered protocol family 31
[   11.114326] Bluetooth: HCI device and connection manager initialized
[   11.114331] Bluetooth: HCI socket layer initialized
[   11.114334] Bluetooth: L2CAP socket layer initialized
[   11.114341] Bluetooth: SCO socket layer initialized
[   11.135683] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   11.227554] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3227: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   11.227561] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   11.227566] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   11.227570] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   11.227573] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   11.227577] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x19
[   11.227581] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   11.245486] intel_rapl: Found RAPL domain package
[   11.245490] intel_rapl: Found RAPL domain core
[   11.245493] intel_rapl: Found RAPL domain uncore
[   11.245496] intel_rapl: Found RAPL domain dram
[   11.326322] Adding 12582908k swap on /dev/sda5.  Priority:-2 extents:1 
across:12582908k FS
[   11.359969] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   11.361462] 

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

[Sten Heinze]

Package: src:linux
Version: 4.16.5-1
Followup-For: Bug #898021

Dear Maintainer,

I also seem to have this issue. After upgrading my kernel to 
linux-image-4.16.0-1-amd64, 
the graphical login screen (sddm) either is not shown or only shown after a 
delay 
(>10s after I complete the text mode login). Before the upgrade X would start 
instantly.
Clicking the mouse does not seem to have an effect with my setup.

Booting the previous kernel, linux-image-4.15.0-3-amd64, does not exhibit this 
problem.
After booting linux-image-4.16.0-1-amd64, starting X from the tty (startkde in 
my case), 
works too.

I can provide additional details if helpful.

Sten

-- Package-specific info:
** Version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 
root=UUID=822f5786-fcce-4563-ada9-f9c9d684742e ro quiet

** Not tainted

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

** Model information
sys_vendor: HP
product_name: HP EliteBook Folio G1
product_version: 
chassis_vendor: HP
chassis_version: 
bios_vendor: HP
bios_version: N91 Ver. 01.16
board_vendor: HP
board_name: 8170
board_version: KBC Version 29.70

** Loaded modules:
ctr
ccm
cmac
rfcomm
bnep
arc4
intel_rapl
nls_ascii
x86_pkg_temp_thermal
intel_powerclamp
nls_cp437
coretemp
vfat
kvm_intel
hid_alps
fat
kvm
irqbypass
hid_generic
snd_hda_codec_hdmi
crct10dif_pclmul
crc32_pclmul
snd_hda_codec_conexant
snd_hda_codec_generic
ghash_clmulni_intel
intel_cstate
wmi_bmof
hp_wmi
btusb
btrtl
btbcm
btintel
iwlmvm
bluetooth
mac80211
snd_soc_skl
jitterentropy_rng
snd_soc_skl_ipc
snd_hda_ext_core
iwlwifi
snd_soc_sst_dsp
intel_uncore
snd_soc_sst_ipc
snd_soc_acpi
intel_rapl_perf
drbg
snd_soc_core
efi_pstore
ansi_cprng
joydev
uvcvideo
snd_compress
cfg80211
pcspkr
snd_hda_intel
snd_hda_codec
videobuf2_vmalloc
snd_hda_core
videobuf2_memops
evdev
i915
videobuf2_v4l2
snd_hwdep
ecdh_generic
serio_raw
videobuf2_common
efivars
videodev
snd_pcm
rfkill
media
crc16
idma64
snd_timer
drm_kms_helper
snd
iTCO_wdt
soundcore
iTCO_vendor_support
drm
mei_me
tpm_crb
shpchp
mei
intel_lpss_pci
intel_lpss
i2c_algo_bit
intel_pch_thermal
wmi
battery
tpm_tis
tpm_tis_core
intel_hid
tpm
sparse_keymap
video
rng_core
ac
hp_wireless
button
acpi_pad
efivarfs
ip_tables
x_tables
autofs4
btrfs
crc32c_generic
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
crc32c_intel
nvme
aesni_intel
aes_x86_64
crypto_simd
xhci_pci
cryptd
glue_helper
xhci_hcd
i2c_i801
psmouse
nvme_core
usbcore
usb_common
i2c_hid
thermal
hid

** Network interface configuration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: wlp109s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether a0:c5:89:21:5e:b2 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic noprefixroute 
wlp109s0
   valid_lft 85617sec preferred_lft 85617sec
inet6 fe80::ec5c:f6ba:937a:f66b/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   48172 592000 0  0 048172 
592000 0   0  0
wlp109s0: 29612796   21537000 0  0 0   721865   
 6479000 0   0  0


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:190c] (rev 08)
Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Host Bridge/DRAM Registers [103c:8170]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 515 
[8086:191e] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company HD Graphics 515 [103c:8170]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- 

Bug#897958: plymouth: long delay before splashscreen with kernel 4.16

[Arnaud Meyer]

From discussion in Bug#897572, I confirm that with kernel 4.16, the 
Plymouth password prompt brings up in mere instants when randomly moving 
the mouse.

Bug#897943: mkfs.ext4 gets stuck on getrandom() syscall

[Theodore Y. Ts'o]

On Sat, May 05, 2018 at 02:11:59AM +0200, Piotr Jurkiewicz wrote:
> Package: e2fsprogs
> Version: 1.44.1-2
> 
> Trying to mkfs.ext4 from initramfs (so with klibc) inside QEMU, it gets
> stuck on getrandom syscall. Running it with strace:
> 
> I wasn't experiencing such a behavior one month before, but I don't know
> what caused it: kernel update from 4.15 to 4.16 or e2fsprogs update.

The immediate cause is that you upgraded to a kernel (probably 4.16.4)
with the patches to CVE-2018-1108 (which was reported by Google's
Project Zero).

commit 43838a23a05fbd13e47d750d3dfd77001536dd33
Author: Theodore Ts'o 
Date:   Wed Apr 11 13:27:52 2018 -0400

random: fix crng_ready() test

The crng_init variable has three states:

0: The CRNG is not initialized at all
1: The CRNG has a small amount of entropy, hopefully good enough for
   early-boot, non-cryptographical use cases
2: The CRNG is fully initialized and we are sure it is safe for
   cryptographic use cases.

The crng_ready() function should only return true once we are in the
last state.  This addresses CVE-2018-1108.

Reported-by: Jann Horn 
Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jann Horn 

The simple workaround is that you build your guest kernel with
CONFIG_HW_RANDOM_VIRTIO enabled, and then make sure QEMU is making a
virtio-rng device enabled.  A simple way to do this is to add the
following the QEMU command line:

-object rng-trandom,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0

> mkfs.ext4 -U 08365ab2-bf18-43eb-9035-ce947f4a7565 -E hash_seed=08365a
> b2-bf18-43eb-9035-ce947f4a7565 /dev/sda
> 
> I don't think mke2fs should do blocking random calls. /dev/urandom is
> present and works fine (I checked it).

mke2fs is not directly doing a blocking random mcall.  It's calling
the UUID library, and the UUID library is using the getrandom(2)
system call.  This system call blocks when the initial entropy pool
has not yet been initialized, and after that, it does not block at
all.

Does the UUID library need cryptographic randomness when it generates
its UUID?  Well, it depends on the user of said library.  There are
libraries that depend on the UUID generated by libuuid to be random
and not guessable.

As far as mke2fs is concerned, there are cases where people *do* want
the UUID to be unique, and if you generate the UUID using a
not-yet-fully-initialized random number generator there is a chance
(probably small) that you might get duplicate UUID's.

So anyway, the cause of what you saw was:

1)  You upgraded to a kernel which no longer erroneously reports the
CRNG is fully initialized when it wasn't.

2) Your VM and/or your Host doesn't use/provide virtio-rng to get
random entropy passed from the host to the guest.

3) mke2fs calls the UUID library to get random UUIDs.  It uses one for
the file system UUID, and another as a secret directory hash to
prevent a potential denial of service attack by a malicious user.

4) The UUID library uses getrandom(2) which is intended to provide
cryptographic-grade security.  As such, it blocks until the entropy
pool is considered initialized.

Note: Using getrandom(2) instead of /dev/urandom is considered best
practice, because of there are programs which generate long-term
secrets that must be secure during early system startup, it's possible
that they will generate insecure RSA keys.  See [1] for an example of
what can happen when the entropy pool is not fully initialized before
RSA keys get generated.

[1] https://factorable.net/paper.html

Cheers,

- Ted

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

[Ben Hutchings]

On Sun, 2018-05-06 at 12:33 +1200, Ben Caradoc-Davies wrote:
> On 06/05/18 07:01, Ben Hutchings wrote:
> > I wonder if this is related to the recent RNG changes.  It seems that
> > many programs have started using blocking RNG functions like
> > getentropy(), and now that the kernel is more conservative in its
> > initial entropy estimation they can block for a long time.  Keyboard or
> > mouse input adds entropy.
> > At a guess, plymouth is starting the X server and the X server wants
> > random bits for MIT-MAGIC-COOKIE authentication.
> 
> Ben, I think you might be right. Only a few mouse wiggles are sufficient 
> to trigger the appearance of the plymouth LUKS screen. I guess that 
> mouse activity is a richer source of entropy than key presses.
> 
> So, where to from here? Should this be reassigned to plymouth or xorg?

Now that I've looked, it appears that Xorg is actually still using
/dev/urandom (via arc4random_buf() in libbsd).  So far as I know, reads
from /dev/urandom have historically succeeded without blocking, even
when there is very little entropy available.  Since many daemons depend
on this I think it has to be maintained.

But so far as I can see from the kernel code, that hasn't changed -
only the newer getentropy() function is more likely to block.  So I'm
quite confused.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.



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

Bug#898028: RFP: python-flask-assets -- Flask webassets integration.

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist

* Package name: python-flask-assets
  Upstream Author : Michael Elsdoerfer 
* URL : https://flask-assets.readthedocs.io/
* License : BSD-2
  Programming Lang: Python
  Description : Flask webassets integration

Integrates the webassets library with Flask, adding support for merging, 
minifying and compiling CSS and Javascript files.

Bug#898029: RFP: python-ghdiff -- Generate unified diffs with Github-style HTML/CSS.

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist

* Package name: python-ghdiff
  Upstream Author : Patrick Strawderman 
* URL : https://github.com/kilink/ghdiff
* License : MIT
  Programming Lang: Python
  Description : Generate unified diffs with Github-style HTML/CSS.

Python module that can generate Github-style HTML for unified diffs

Bug#898027: RFP: python-flask-cache -- Adds cache support to your Flask application

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist

* Package name: python-flask-cache
  Upstream Author : Thadeus Burgess 
* URL : https://github.com/thadeusb/flask-cache
* License : BSD
  Programming Lang: Python
  Description : Adds cache support to your Flask application

Simple extension for flask that adds caching support.

Bug#898026: git-buildpackage: multiple upstream tarball (mixed tar.gz and tar.xz) with --git-component option

[Hideki Yamane]

package: git-buildpackage
severity: minor

Hi,

 I'm maintaining poppler-data package that has three upstream tarballs,
 and two are tar.gz and rest one is tar.xz. Today I've tried to use gbp's
 experimental --git-component option but failed since its option assumes
 that tarball is only tar.gz.

 So question is, as limitation, is upstream tarball that is specified with
 --git-component option should be same compression as main upstream tarball?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#898025: lxc: apparmor="DENIED" operation="mount" info="failed flags match" error=-13

[johnw]

-- Configuration Files:
/etc/apparmor.d/abstractions/lxc/container-base [Errno 13] Permission
denied: '/etc/apparmor.d/abstractions/lxc/container-base'
/etc/apparmor.d/abstractions/lxc/start-container [Errno 13] Permission
denied: '/etc/apparmor.d/abstractions/lxc/start-container'
/etc/apparmor.d/lxc-containers [Errno 13] Permission denied:
'/etc/apparmor.d/lxc-containers'
/etc/apparmor.d/lxc/lxc-default [Errno 13] Permission denied:
'/etc/apparmor.d/lxc/lxc-default'
/etc/apparmor.d/lxc/lxc-default-cgns [Errno 13] Permission denied:
'/etc/apparmor.d/lxc/lxc-default-cgns'
/etc/apparmor.d/lxc/lxc-default-with-mounting [Errno 13] Permission
denied: '/etc/apparmor.d/lxc/lxc-default-with-mounting'
/etc/apparmor.d/lxc/lxc-default-with-nesting [Errno 13] Permission
denied: '/etc/apparmor.d/lxc/lxc-default-with-nesting'
/etc/apparmor.d/usr.bin.lxc-start [Errno 13] Permission denied:
'/etc/apparmor.d/usr.bin.lxc-start'

-- no debconf information


Attached apparmor.d rules(default from lxc.deb without modify) and lxc 
config here



--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC


lxc-apparmor.tar
Description: Unix tar archive

Bug#898025: lxc: apparmor="DENIED" operation="mount" info="failed flags match" error=-13

[kaka]

Package: lxc
Version: 1:2.0.9-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
Over the year, if I enable apparmor for lxc (lxc.aa_profile = 
lxc-container-default),
I see a lot of "apparmor denied" messages like below,
But the lxc itself is can running and functional without a problem,
Why apparmor always complain lxc? (is this normal)?

apparmor="DENIED" operation="mount" info="failed type match" error=-13 
profile="lxc-container-default" name="/sys/fs/pstore/" pid=2676 comm="mount" 
fstype="pstore" srcname="pstore"
apparmor="DENIED" operation="mount" info="failed type match" error=-13 
profile="lxc-container-default" name="/sys/fs/pstore/" pid=2676 comm="mount" 
fstype="pstore" srcname="pstore" flags="ro"
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default" name="/" pid=2763 comm="mount" flags="rw, 
remount"

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


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

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

Versions of packages lxc depends on:
ii  libapparmor1  2.12-4
ii  libc6 2.27-3
ii  libcap2   1:2.25-1.2
ii  libgnutls30   3.5.18-1
ii  liblxc1   1:2.0.9-6
ii  libseccomp2   2.3.3-1
ii  libselinux1   2.7-2+b2
ii  lsb-base  9.20170808
ii  python3   3.6.5-3
ii  python3-lxc   1:2.0.9-6

Versions of packages lxc recommends:
ii  bridge-utils  1.5-16
pn  debootstrap   
ii  dirmngr   2.2.5-1
pn  dnsmasq-base  
ii  gnupg 2.2.5-1
ii  iptables  1.6.2-1
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.1.0h-2
ii  rsync 3.1.2-2.1
pn  uidmap

Versions of packages lxc suggests:
ii  apparmor 2.12-4
ii  btrfs-progs  4.15.1-2
pn  lvm2 

-- Configuration Files:
/etc/apparmor.d/abstractions/lxc/container-base [Errno 13] Permission denied: 
'/etc/apparmor.d/abstractions/lxc/container-base'
/etc/apparmor.d/abstractions/lxc/start-container [Errno 13] Permission denied: 
'/etc/apparmor.d/abstractions/lxc/start-container'
/etc/apparmor.d/lxc-containers [Errno 13] Permission denied: 
'/etc/apparmor.d/lxc-containers'
/etc/apparmor.d/lxc/lxc-default [Errno 13] Permission denied: 
'/etc/apparmor.d/lxc/lxc-default'
/etc/apparmor.d/lxc/lxc-default-cgns [Errno 13] Permission denied: 
'/etc/apparmor.d/lxc/lxc-default-cgns'
/etc/apparmor.d/lxc/lxc-default-with-mounting [Errno 13] Permission denied: 
'/etc/apparmor.d/lxc/lxc-default-with-mounting'
/etc/apparmor.d/lxc/lxc-default-with-nesting [Errno 13] Permission denied: 
'/etc/apparmor.d/lxc/lxc-default-with-nesting'
/etc/apparmor.d/usr.bin.lxc-start [Errno 13] Permission denied: 
'/etc/apparmor.d/usr.bin.lxc-start'

-- no debconf information

Bug#898023: notmuch: Please disable gdb build-dependency on riscv64

[David Bremner]

David Bremner  writes:

>
> These architectures have gdb, but it's broken in various ways.  They're
> also release architectures, where bugs in gdb introduced a regression in
> notmuch.

I see that some of these architectures have stopped being release
architectures since that exclusion was added. Probably that list should
be cleaned up.

d

Bug#898024: trying to overwrite '/usr/include/nodejs/common.gypi', which is also in package nodejs-dev 10.0.0~dfsg-2

[積丹尼 Dan Jacobson]

Package: nodejs-dev

Unpacking libnode64-dev (10.0.0~dfsg1-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-NI7HKh/073-libnode64-dev_10.0.0~dfsg1-3_amd64.deb 
(--unpack):
 trying to overwrite '/usr/include/nodejs/common.gypi', which is also in 
package nodejs-dev 10.0.0~dfsg-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)


dpkg: dependency problems prevent configuration of nodejs-dev:
 nodejs-dev depends on libnode-dev; however:
  Package libnode-dev is not installed.

dpkg: error processing package nodejs-dev (--configure):
 dependency problems - leaving unconfigured

Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

[Ben Caradoc-Davies]

Looks like the same bug. We should probably merge, but into what package 
(linux, plymouth, or xorg)?:


Bug#897958: plymouth: long delay before splashscreen with kernel 4.16
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897958

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Ben Hutchings suggests that this is probably caused by the new RNG 
behaviour in 4.16, and I concur. See Ben's remarks in #897572 
.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#898023: notmuch: Please disable gdb build-dependency on riscv64

[David Bremner]

"Manuel A. Fernandez Montecelo"  writes:

> notmuch depends on gdb, which is not available yet in Debian for the riscv64
> architecture.
>
> After a bit of research, it's not clear to me the purpose of build-depending 
> on
> gdb.  (If you know from the top of your head and can explain briefly it would 
> be
> great, I am curious now :) ).

notmuch uses gdb in its test suite. So disabling it means parts of the
test suite don't run.

> We're generally reluctant to ask to disable dependencies specifically for this
> architecture, because we hope to get them available in a reasonable timeframe.

If you plan on supporting gdb, it probably makes more sense to just wait
for that, and at least see if it works.

> However, since this is also disables in fully supported arches for many years
> like s390x, ppc64el or mips*, in this case is probably better to remove it for
> riscv64 as well.

These architectures have gdb, but it's broken in various ways.  They're
also release architectures, where bugs in gdb introduced a regression in
notmuch.

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Dmitry Eremin-Solenikov]

Hello,

2018-05-05 16:47 GMT+03:00 Lumin :
> On Sat, Apr 28, 2018 at 01:58:26PM +0300, Dmitry Eremin-Solenikov wrote:
>> > 5. Could you explain why these lines exist? Package libodp-linux-dev
>> > seems not exist.
>>
>> Packages libodp-linux-dev and libodp-linux119 are virtual package,
>> provided by different implementations of ODP API. We are providing
>> another ODP implementation, implemented specifically on top of DPDK
>> (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These
>> two implementations are binary compatible. It is planned that odp-dpdk
>> will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev
>> (Provides: libodp-linux-dev) packages.
>>
>> Would you recommend how should I better document and/or implement these
>> packages.
>
> How many libodp-linux.so.119 providers are there?

It is not known yet. For previous long term support release we had more than 6
providers. Not all of them are going to be packaged/provided through Debian,
as they were provided by hardware vendors.

> If there are only a few alternatives, why should we make a virtual
> package, whose SOVERSION might bump regularly? From the policy we can
> find a list of authoritative virtual packages:
>
>   https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>
> All of these packages are widely used and be depended by a lot of
> packages. If the list of libodp-linux.so.* providers is short, we can
> write the Depends field of an application package like this:
>
>   Depends: libodp-implement1 | libodp-impl2 | ...,
>
> where there is no virtual package.

Unfortunately it is not easy to predict in advance, which
libraries/implementations
will be provided (and when).

I will make my next upload use alternatives, thank you.

> By doing so you will get rid of the 'package-name-doesnt-match-sonames'
> warning, and be able to keep several implementations at the same time.
> This situation must be better for your next package.
>
> To implement this, you first need to rename libodp-linux.so.* to match
> your package name. Then write some postinst and prerm scripts. Here is a
> good example:
>
>   
> https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.postinst.in
>   
> https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.prerm.in
>
> By looking around in the openblas packaging you'll also find the example
> for -dev package.

Quite interesting, thank for the pointer. The idea of generating these scripts
during build time didn't occur to me before.

>> libodp-test-utils? These tools are mostly testing programs, that can be
>> used either by autotests (in future) or users (to check that their ODP
>> installation works).
>
> odp-linux-tools:
>
> -rwxr-xr-x root/root 31016 2018-04-28 14:48 
> ./usr/lib/odp/linux/examples/odp_l3fwd
> -rwxr-xr-x root/root 18504 2018-04-28 14:48 
> ./usr/lib/odp/linux/examples/odp_pktio
>
> This still look weird. The convention is that -utils/-tools packages
> would install executable binaries under /usr/bin (or /usr/sbin in some
> cases). I think either of the two solutions will do
>
> * move all the executables to /usr/bin. Their name starts with odp_, so
>   I don't expect them to pollute the public name space. Putting these
>   test programs in a private directory just makes it hard to find and
>   use them.

This looks logical to me. I will move some (usefull) programs to /usr/bin
and will drop the rest of them.

>> > 11. Why is dh_auto_test overrode to empty?
>>
>> We had issues with make check before, they interacted strangely with
>> build environment, that is why it is disabled for now. I plan to
>> reenable it later.
>
> How strange is it? And what happend during the test?
>
> As per policy, network access during the build is not availble. If this
> is the cause of test problem, we can omit the test part. However, we
> should still write the tests in the override_dh_auto_test target, if our
> user want to test it somehow.

Some of the validation scripts are trying to create/remove network
interfaces.

>   override_dh_auto_test:
>   -test_binary
>
> This should be ok.

Ack

-- 
With best wishes
Dmitry

Bug#898023: notmuch: Please disable gdb build-dependency on riscv64

[Manuel A. Fernandez Montecelo]

Source: notmuch
Version: 0.26.2-1
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

notmuch depends on gdb, which is not available yet in Debian for the riscv64
architecture.

After a bit of research, it's not clear to me the purpose of build-depending on
gdb.  (If you know from the top of your head and can explain briefly it would be
great, I am curious now :) ).

We're generally reluctant to ask to disable dependencies specifically for this
architecture, because we hope to get them available in a reasonable timeframe.

However, since this is also disables in fully supported arches for many years
like s390x, ppc64el or mips*, in this case is probably better to remove it for
riscv64 as well.

It would be great if you could include these changes and release a new version
for unstable soonish.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#898022: diffoscope: Traceback when comparing paths with invalid unicode characters

[Chris Lamb]

Package: diffoscope
Version: 93
Severity: important

Hi,

This is via , but I
think the bug is in diffoscope itself.

So, given the following test:

  import os
  import pytest
  import subprocess

  def test_invalid_filename(capsys, tmpdir):
  base = str(tmpdir.mkdir('src')).encode('utf-8')
  
  a = os.path.join(base, b'\xf0\x28\x8c\x28')
  b = os.path.join(base, b'\xf0\x28\x8c\x29')
  
  with open(a, 'w'), open(b, 'w'):
  pass
  
  subprocess.check_call(('bin/diffoscope', a, b))

I get:

   test_invalid_filename 
_
  
  capsys = <_pytest.capture.CaptureFixture object at 0x7f25bd267710>
  tmpdir = local('/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0')
  
  def test_invalid_filename(capsys, tmpdir):
  base = str(tmpdir.mkdir('src')).encode('utf-8')
  
  a = os.path.join(base, b'\xf0\x28\x8c\x28')
  b = os.path.join(base, b'\xf0\x28\x8c\x29')
  
  with open(a, 'w'), open(b, 'w'):
  pass
  
  >   subprocess.check_call(('bin/diffoscope', a, b))
  
  tests/test_filenames.py:34: 
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ 
  
  popenargs = (('bin/diffoscope', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c(', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c)'),)
  kwargs = {}, retcode = 2
  cmd = ('bin/diffoscope', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c(', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c)')
  
  def check_call(*popenargs, **kwargs):
  """Run command with arguments.  Wait for command to complete.  If
  the exit code was zero then return, otherwise raise
  CalledProcessError.  The CalledProcessError object will have the
  return code in the returncode attribute.
  
  The arguments are the same as for the call function.  Example:
  
  check_call(["ls", "-l"])
  """
  retcode = call(*popenargs, **kwargs)
  if retcode:
  cmd = kwargs.get("args")
  if cmd is None:
  cmd = popenargs[0]
  >   raise CalledProcessError(retcode, cmd)
  E   subprocess.CalledProcessError: Command '('bin/diffoscope', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c(', 
b'/tmp/pytest-of-lamby/pytest-43/test_invalid_filename0/src/\xf0(\x8c)')' 
returned non-zero exit status 2.
  
  /usr/lib/python3.6/subprocess.py:291: CalledProcessError
  -- Captured log setup 
--
  locale.py   33 DEBUGNormalising locale, timezone, etc.
  __init__.py128 DEBUGLoaded 66 comparator classes
  __init__.py128 DEBUGLoaded 66 comparator classes
  - Captured stderr call 
-
  Traceback (most recent call last):
File "/home/lamby/git/debian/reproducible/diffoscope/diffoscope/main.py", 
line 448, in main
  sys.exit(run_diffoscope(parsed_args))
File "/home/lamby/git/debian/reproducible/diffoscope/diffoscope/main.py", 
line 420, in run_diffoscope
  difference = compare_root_paths(path1, path2)
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/compare.py",
 line 65, in compare_root_paths
  file1 = specialize(FilesystemFile(path1, container=container1))
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/specialize.py",
 line 49, in specialize
  if try_recognize(file, cls, cls.recognizes):
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/specialize.py",
 line 36, in try_recognize
  if not recognizes(file):
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/debian.py",
 line 169, in recognizes
  if not super().recognizes(file):
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/file.py",
 line 141, in recognizes
  lambda m, t: t.search(m), file.magic_file_type),
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/file.py",
 line 227, in magic_file_type
  self._magic_file_type = File.guess_file_type(self.path)
File 
"/home/lamby/git/debian/reproducible/diffoscope/diffoscope/comparators/utils/file.py",
 line 71, in guess_file_type
  return self._mimedb.file(path)
File "/usr/lib/python3/dist-packages/magic/compat.py", line 148, in file
  return Magic.__tostr(_file(self._magic_t, Magic.__tobytes(filename)))
File "/usr/lib/python3/dist-packages/magic/compat.py", line 138, in 
__tobytes
  return bytes(b, 'utf-8')
  UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf0' in position 
58: surrogates not allowed
  

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

[Pedro MGP]

Package: src:linux
Version: 4.16.5-1
Severity: important

Dear Maintainer,

kernel 4.16 on debian testing is causing an infinite wait after the FIRST
display manager authentication.

clicking the mouse buttons alternately L-R-L-R sometimes ceases it. subsequent
authentications are good. rebooting repeats it.
tested with lightdm and xdm, and xfce and lxqt.

seen on yvy bridge and bay trail systems using integrated intel graphics. ok on
dicrete nvidia graphics using the vendor driver, and old GMA3000 and N550
(pineview) systems.

all fine when booting 4.15.




-- Package-specific info:
** Version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 
root=UUID=5c551418-b5f0-4854-aeb4-383d6dd9d36e ro quiet

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

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

** Model information
sys_vendor: System manufacturer
product_name: P5E
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 1201   
board_vendor: ASUSTeK Computer INC.
board_name: P5E
board_version: Rev 1.xx

** Loaded modules:
cpuid
pci_stub
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
zram
zsmalloc
fuse
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
binfmt_misc
snd_hda_codec_analog
snd_hda_codec_generic
snd_hda_codec_hdmi
pktcdvd
joydev
iTCO_wdt
iTCO_vendor_support
evdev
coretemp
kvm_intel
ip6t_REJECT
nf_reject_ipv6
snd_hda_intel
kvm
snd_hda_codec
irqbypass
nf_log_ipv6
snd_hda_core
snd_hwdep
snd_pcm
serio_raw
pcspkr
snd_timer
xt_hl
sg
snd
lpc_ich
x38_edac
ip6t_rt
soundcore
shpchp
asus_atk0110
button
nf_conntrack_ipv6
nf_defrag_ipv6
ipt_REJECT
nf_reject_ipv4
nf_log_ipv4
nf_log_common
xt_LOG
xt_limit
xt_tcpudp
xt_addrtype
nf_conntrack_ipv4
nf_defrag_ipv4
nvidia_drm(PO)
xt_conntrack
drm_kms_helper
drm
ip6table_filter
ip6_tables
nvidia_modeset(PO)
nf_conntrack_netbios_ns
nf_conntrack_broadcast
nf_nat_ftp
nf_nat
nvidia(PO)
nf_conntrack_ftp
nf_conntrack
ipmi_devintf
ipmi_msghandler
parport_pc
iptable_filter
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
btrfs
zstd_decompress
zstd_compress
xxhash
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
sr_mod
cdrom
sd_mod
hid_generic
usbhid
hid
ahci
libahci
libata
scsi_mod
sky2
i2c_i801
r8169
xhci_pci
mii
uhci_hcd
ehci_pci
xhci_hcd
ehci_hcd
usbcore
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 82X38/X48 Express DRAM Controller 
[8086:29e0] (rev 01)
Subsystem: ASUSTeK Computer Inc. 82X38/X48 Express DRAM Controller 
[1043:8295]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: x38_edac
Kernel modules: x38_edac

00:01.0 PCI bridge [0604]: Intel Corporation 82X38/X48 Express Host-Primary PCI 
Express Bridge [8086:29e1] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:06.0 PCI bridge [0604]: Intel Corporation 82X38/X48 Express Host-Secondary 
PCI Express Bridge [8086:29e9] (rev 01) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P5K PRO Motherboard [1043:8277]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P5K PRO Motherboard [1043:8277]
Control: I/O+ Mem- 

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

[Ben Caradoc-Davies]

On 06/05/18 07:01, Ben Hutchings wrote:

I wonder if this is related to the recent RNG changes.  It seems that
many programs have started using blocking RNG functions like
getentropy(), and now that the kernel is more conservative in its
initial entropy estimation they can block for a long time.  Keyboard or
mouse input adds entropy.
At a guess, plymouth is starting the X server and the X server wants
random bits for MIT-MAGIC-COOKIE authentication.


Ben, I think you might be right. Only a few mouse wiggles are sufficient 
to trigger the appearance of the plymouth LUKS screen. I guess that 
mouse activity is a richer source of entropy than key presses.


So, where to from here? Should this be reassigned to plymouth or xorg?

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#898020: poco: Please add support for arch riscv64

[Manuel A. Fernandez Montecelo]

Source: poco
Version: 1.9.0-2
Severity: normal
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

We need support in this package for the riscv64 architecture.

I am attaching a patch that adds support.  It applies cleanly when added last in
the "series" file.

Without it, it simply FTBFS since it doesn't know about the architecture.

It would be great if you could include these changes and release a new version
for unstable soonish.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
Index: poco-1.9.0/Foundation/include/Poco/Platform.h
===
--- poco-1.9.0.orig/Foundation/include/Poco/Platform.h
+++ poco-1.9.0/Foundation/include/Poco/Platform.h
@@ -134,6 +134,7 @@
 #define POCO_ARCH_NIOS2   0x0e
 #define POCO_ARCH_AARCH64 0x0f
 #define POCO_ARCH_ARM64   0x0f // same as POCO_ARCH_AARCH64
+#define POCO_ARCH_RISCV64 0x10
 
 
 #if defined(__ALPHA) || defined(__alpha) || defined(__alpha__) || 
defined(_M_ALPHA)
@@ -224,6 +225,9 @@
 #elif defined(__AARCH64EB__)
#define POCO_ARCH POCO_ARCH_AARCH64
#define POCO_ARCH_BIG_ENDIAN 1
+#elif defined(__riscv) && (__riscv_xlen == 64)
+   #define POCO_ARCH POCO_ARCH_RISCV64
+   #define POCO_ARCH_LITTLE_ENDIAN 1
 #endif
 
 
Index: poco-1.9.0/Foundation/src/utils.h
===
--- poco-1.9.0.orig/Foundation/src/utils.h
+++ poco-1.9.0/Foundation/src/utils.h
@@ -62,6 +62,7 @@
 defined(__sparc__) || defined(__sparc) || defined(__s390__) || \
 defined(__SH4__) || defined(__alpha__) || \
 defined(_MIPS_ARCH_MIPS32R2) || \
+defined(__riscv) || \
 defined(__AARCH64EL__) || \
 defined(nios2) || defined(__nios2) || defined(__nios2__)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
diff -Nru poco-1.9.0/debian/changelog poco-1.9.0/debian/changelog
--- poco-1.9.0/debian/changelog 2018-04-06 13:39:17.0 +0200
+++ poco-1.9.0/debian/changelog 2018-05-05 22:59:49.0 +0200
@@ -1,3 +1,10 @@
+poco (1.9.0-2+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: add support
+
+ -- Manuel A. Fernandez Montecelo   Sat, 05 May 2018 20:59:49 
+
+
 poco (1.9.0-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru poco-1.9.0/debian/patches/riscv64-support.patch 
poco-1.9.0/debian/patches/riscv64-support.patch
--- poco-1.9.0/debian/patches/riscv64-support.patch 1970-01-01 
01:00:00.0 +0100
+++ poco-1.9.0/debian/patches/riscv64-support.patch 2018-05-05 
22:59:43.0 +0200
@@ -0,0 +1,34 @@
+Index: poco-1.9.0/Foundation/include/Poco/Platform.h
+===
+--- poco-1.9.0.orig/Foundation/include/Poco/Platform.h
 poco-1.9.0/Foundation/include/Poco/Platform.h
+@@ -134,6 +134,7 @@
+ #define POCO_ARCH_NIOS2   0x0e
+ #define POCO_ARCH_AARCH64 0x0f
+ #define POCO_ARCH_ARM64   0x0f // same as POCO_ARCH_AARCH64
++#define POCO_ARCH_RISCV64 0x10
+ 
+ 
+ #if defined(__ALPHA) || defined(__alpha) || defined(__alpha__) || 
defined(_M_ALPHA)
+@@ -224,6 +225,9 @@
+ #elif defined(__AARCH64EB__)
+   #define POCO_ARCH POCO_ARCH_AARCH64
+   #define POCO_ARCH_BIG_ENDIAN 1
++#elif defined(__riscv) && (__riscv_xlen == 64)
++  #define POCO_ARCH POCO_ARCH_RISCV64
++  #define POCO_ARCH_LITTLE_ENDIAN 1
+ #endif
+ 
+ 
+Index: poco-1.9.0/Foundation/src/utils.h
+===
+--- poco-1.9.0.orig/Foundation/src/utils.h
 poco-1.9.0/Foundation/src/utils.h
+@@ -62,6 +62,7 @@
+ defined(__sparc__) || defined(__sparc) || defined(__s390__) || \
+ defined(__SH4__) || defined(__alpha__) || \
+ defined(_MIPS_ARCH_MIPS32R2) || \
++defined(__riscv) || \
+ defined(__AARCH64EL__) || \
+ defined(nios2) || defined(__nios2) || defined(__nios2__)
+ #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
diff -Nru poco-1.9.0/debian/patches/series poco-1.9.0/debian/patches/series
--- poco-1.9.0/debian/patches/series2018-02-28 21:00:38.0 +0100
+++ poco-1.9.0/debian/patches/series2018-05-05 22:59:44.0 +0200
@@ -6,3 +6,4 @@
 0007-Switch-FreeBSD-to-poll.patch
 0009-Link-against-dl-on-FreeBSD.patch
 MySQL-5.7-compatibility.patch
+riscv64-support.patch

Bug#898019: sunpinyin: Please add support for arch riscv64

[Manuel A. Fernandez Montecelo]

Source: sunpinyin
Severity: normal
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

We need support in this package for the riscv64 architecture.

I am attaching a patch that adds support.  It applies cleanly when added last in
the "series" file.

Without it, it doesn't even start to build and it FTBFS.

It would be great if you could include these changes and release a new version
for unstable soonish.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
Index: sunpinyin-3.0.0~git20160910/SConstruct
===
--- sunpinyin-3.0.0~git20160910.orig/SConstruct
+++ sunpinyin-3.0.0~git20160910/SConstruct
@@ -333,6 +333,7 @@ def AppendEndianCheck(conf):
   || defined(_M_X64)|| defined(__bfin__) \
   || defined(__alpha__) || defined(__ARMEL__) \
   || defined(_MIPSEL)   || (defined(__sh__) && defined(__LITTLE_ENDIAN__)) \
+  || defined(__riscv) \
   || defined(__AARCH64EL__)
 # undef WORDS_BIGENDIAN
 
diff -Nru sunpinyin-3.0.0~git20160910/debian/changelog 
sunpinyin-3.0.0~git20160910/debian/changelog
--- sunpinyin-3.0.0~git20160910/debian/changelog2016-10-12 
20:44:02.0 +0200
+++ sunpinyin-3.0.0~git20160910/debian/changelog2018-05-05 
23:54:46.0 +0200
@@ -1,3 +1,10 @@
+sunpinyin (3.0.0~git20160910-1+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: support, endianness
+
+ -- Manuel A. Fernandez Montecelo   Sat, 05 May 2018 21:54:46 
+
+
 sunpinyin (3.0.0~git20160910-1) unstable; urgency=medium
 
   * New upstream snapshot 20160910
diff -Nru sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch 
sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch
--- sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch
1970-01-01 01:00:00.0 +0100
+++ sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch
2018-05-05 23:54:46.0 +0200
@@ -0,0 +1,12 @@
+Index: sunpinyin-3.0.0~git20160910/SConstruct
+===
+--- sunpinyin-3.0.0~git20160910.orig/SConstruct
 sunpinyin-3.0.0~git20160910/SConstruct
+@@ -333,6 +333,7 @@ def AppendEndianCheck(conf):
+   || defined(_M_X64)|| defined(__bfin__) \
+   || defined(__alpha__) || defined(__ARMEL__) \
+   || defined(_MIPSEL)   || (defined(__sh__) && defined(__LITTLE_ENDIAN__)) \
++  || defined(__riscv) \
+   || defined(__AARCH64EL__)
+ # undef WORDS_BIGENDIAN
+ 
diff -Nru sunpinyin-3.0.0~git20160910/debian/patches/series 
sunpinyin-3.0.0~git20160910/debian/patches/series
--- sunpinyin-3.0.0~git20160910/debian/patches/series   2016-10-12 
20:44:02.0 +0200
+++ sunpinyin-3.0.0~git20160910/debian/patches/series   2018-05-05 
23:54:46.0 +0200
@@ -1 +1,2 @@
 fix-data-dir.diff
+riscv64-support.patch

Bug#898018: marisa: Please add support for arch riscv64

[Manuel A. Fernandez Montecelo]

Source: marisa
Severity: normal
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

We need support in this package for the riscv64 architecture.

I am attaching a patch that adds support.  It applies cleanly when added last in
the "series" file.

Without it, the tests fail, and it FTBFS.

It would be great if you could include these changes and release a new version
for unstable soonish.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
Index: marisa-0.2.4/lib/marisa/base.h
===
--- marisa-0.2.4.orig/lib/marisa/base.h
+++ marisa-0.2.4/lib/marisa/base.h
@@ -31,6 +31,7 @@ typedef uint64_t marisa_uint64;
 #if defined(_WIN64) || defined(__amd64__) || defined(__x86_64__) || \
 defined(__ia64__) || defined(__ppc64__) || defined(__powerpc64__) || \
 ( defined(__sparc__) && defined(__arch64__) ) || \
+( defined(__riscv) && (__riscv_xlen == 64) ) || \
 defined(__mips64) || defined(__aarch64__) || defined(__s390x__)
  #define MARISA_WORD_SIZE 64
 #else  // defined(_WIN64), etc.
diff -Nru marisa-0.2.4/debian/changelog marisa-0.2.4/debian/changelog
--- marisa-0.2.4/debian/changelog   2014-10-11 16:08:17.0 +0200
+++ marisa-0.2.4/debian/changelog   2018-05-06 01:47:40.0 +0200
@@ -1,3 +1,10 @@
+marisa (0.2.4-8+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: add support for riscv64 to fix tests
+
+ -- Manuel A. Fernandez Montecelo   Sat, 05 May 2018 23:47:40 
+
+
 marisa (0.2.4-8) unstable; urgency=medium
 
   [debian/control]
diff -Nru marisa-0.2.4/debian/patches/riscv64-support.patch 
marisa-0.2.4/debian/patches/riscv64-support.patch
--- marisa-0.2.4/debian/patches/riscv64-support.patch   1970-01-01 
01:00:00.0 +0100
+++ marisa-0.2.4/debian/patches/riscv64-support.patch   2018-05-06 
01:47:40.0 +0200
@@ -0,0 +1,12 @@
+Index: marisa-0.2.4/lib/marisa/base.h
+===
+--- marisa-0.2.4.orig/lib/marisa/base.h
 marisa-0.2.4/lib/marisa/base.h
+@@ -31,6 +31,7 @@ typedef uint64_t marisa_uint64;
+ #if defined(_WIN64) || defined(__amd64__) || defined(__x86_64__) || \
+ defined(__ia64__) || defined(__ppc64__) || defined(__powerpc64__) || \
+ ( defined(__sparc__) && defined(__arch64__) ) || \
++( defined(__riscv) && (__riscv_xlen == 64) ) || \
+ defined(__mips64) || defined(__aarch64__) || defined(__s390x__)
+  #define MARISA_WORD_SIZE 64
+ #else  // defined(_WIN64), etc.
diff -Nru marisa-0.2.4/debian/patches/series marisa-0.2.4/debian/patches/series
--- marisa-0.2.4/debian/patches/series  2014-09-17 18:05:17.0 +0200
+++ marisa-0.2.4/debian/patches/series  2018-05-06 01:47:40.0 +0200
@@ -1,3 +1,4 @@
 module-version-for-egg-inof.patch
 wordsize-test-for-some-archs.patch
 support-mips64el.patch
+riscv64-support.patch

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[James McCoy]

On Thu, May 03, 2018 at 11:25:03PM +0200, Emmanuel Bourg wrote:
> On Wed, 2 May 2018 22:11:49 -0400 James McCoy  wrote:
> 
> > Ah, that's because the javah command was removed in Java 10, to be
> > replaced by running "javac -h".
> > 
> > It would have been useful to get a notice about this ahead of time, for
> > those not as involved with Java.  Especially since this has apparently
> > been planned since Java 8.
> 
> Sorry for the lack of communication around the switch, there was a
> deprecation warning about javah during the build since the switch to
> OpenJDK 9 in March, but it might have been difficult to notice for
> Subversion.
> 
> Looking at the build log it seems javah is invoked 5 times and the
> headers are all generated into the subversion/bindings/javahl/include
> directory. Did you try disabling the calls to javah and adding '-h
> subversion/bindings/javahl/include/' to the javac parameters?

Thanks for the tip.  I'm not sure why that didn't register when first
looking at the help.

It looks like that will do the right thing.  Now I just need to figure
out the larger issue of adapting upstream's build system.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897671: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

[Tom Rini]

On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:

> Hello U-Boot.
> 
> Markus Krebs discovered that the sheevaplug target has again grown and
> installation overlaps where the u-boot env is saved since u-boot
> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
> overwrites any prior environment settings.
> 
> More detail on the bug report in Debian:
> 
>   https://bugs.debian.org/897671
> 
> We don't carry any patches for the sheevaplug u-boot target in Debian,
> so this is likely also an issue upstream. Who are the current
> maintainers for sheevaplug in u-boot upstream?
> 
> A brief summary of the current findings:
> 
> On 2018-05-05, Markus Krebs wrote:
> > Am 05.05.2018 um 20:36 schrieb Markus Krebs:
> >> Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:
> >>> * Markus Krebs  [2018-05-05 20:32]:
>  I got it. Indeed it has to to with the size of u-boot.
> >>>
> >>> Does it boot?
> >>>
> >> 
> >> Yes it does.
> >
> > ... and no longer so, when I "saveenv" :-(
> >
> > I downloaded u-boot via git; I guess that the config for u-boot for 
> > sheevaplug is already broken upstream (in sheevaplug.h):
> >
> >#define CONFIG_ENV_SIZE 0x2 /* 128k */
> >#define CONFIG_ENV_ADDR 0x8
> >#define CONFIG_ENV_OFFSET   0x8 /* env starts here */
> >
> > but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
> > in this case 'saveenv' overwrites u-boot (?).
> > Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
> > so-modified sources, and now I can start Debian fine.
> 
> It looks like it was bumped from 0x6 to 0x8 in 2014:
> 
>   
> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
> 
> If 0x8 isn't enough, there might be some features in the config to
> experiment with removing, or it may need to be bumped again.

I've added the maintainer to the list as well.  I would suggest looking
for things to trim out, perhaps CMD_MEMTEST ?  Also, a patch to make it
a link error when we exceed the size allowed would be great, so that in
the future we catch this when it happens.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Bug#898017: ncurses abi change.

[peter green]

Package: fp-units-base
Tags: buster,sid

ncurses has just bumped it's soname and has apparently changed the data type of 
chtype. This will most likely require a corresponding modification to the fpc 
ncurses unit if we don't want pascal programs using ncurses to break horriblly..

I have asked the release team not to binnmu fpc and I would suggest avoiding 
uploads of the fpc package until we have looked at this.

Bug#894049: transition: ncurses

[peter green]

I suspect fpc will also need a sourceful upload for the new ncurses. I would 
recommend not binnmuing it until the maintainers have had chance to take a look.

Is there a full list of differences between the version 5 and 6 ABIs anywhere? 
chtype has already been mentioned, are there any others?

Bug#897990: gscan2pdf assertion failed when completing a scan

[Francois Gouget]

On Sat, 5 May 2018, Jeff wrote:
[...]
> That is cairo crashing and taking Perl with it. This report looks
> similar and suggests that the problem is connected to the image size:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1132667
> 
> Would you mind testing to see whether smaller images also have the same
> problem?

Yes. That's the bug.

Scanning in color or grayscale at 300 dpi works. Scanning at 600 dpi 
triggers the crash, whether that's in grayscale or color (I guess it's 
all color in memory anyway).


> This bug report suggests a solution. Would you mind trying it out?
> 
> https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1520211/comments/5

Yep. That works. Here are some more tidbits:

* The default shmmax value on my system is 268435456 (256GB). Increasing 
  that to 536870912 (512GB) fixes the crash.

* One can change the shmmax without rebooting with:
  echo 536870912 >/proc/sys/kernel/shmmax

* To repeat the referenced bug reports, to make the setting permanent 
  add the following line to /etc/sysctl.conf:

kernel.shmmax = 536870912

* Setting shmmax to 536870911 (512GB - 1 byte) does not avoid the 
  crash.

* The reason scanimage allowed me to work around the bug before is 
  because the default dpi sucks!

* I can also reproduce the crash by using gimp to save the 
  600 dpi image to a png file and then loading that png file in 
  gscan2pdf. So the issue is indeed not related to the scanner 
  interface. The 600 dpi PNG file resolution is 5098x7012.

* But scanning with a 1200 dpi resolution directly in gscan2pdf works 
  fine. This may indicate that it's not necessary to keep increasing 
  shmmax to work on higher and higher resolution images.

* Interestingly, even with shmmax set to 512GB gscan2pdf cannot load a 
  1200 dpi png file (10196x14024):
  ERROR - Exception 445: cache resources exhausted 
`/home/fgouget/Documents/c1200.png' @   error/cache.c/OpenPixelCache/4076
  ERROR - /home/fgouget/Documents/c1200.png is not a recognised image   type

  So this indicates a separate (memory?) issue in the PNG code.


* I upgraded my system on 2018/04/14 and scanning worked on the 15th. 
  I did another upgrade on the 15th (before or after scanning) and again 
  on the 20th and I think the 2018/05/05 is the next time I scanned. 
  That's when I noticed things were broken. So something changed in that 
  interval and broke things. Obviously I did not manually changed 
  shmmax.



-- 
Francois Gouget   http://fgouget.free.fr/
 There are 10 types of people in the world...
   those who understand binary and those who don't.

Bug#896666: qemu-system-x86: page allocation failure: 4.15.0-0.bpo.2-amd64

[Russell Mosemann]

Package: src:linux
Version: 4.15.11-1~bpo9+1
Severity: important

 
May 05 18:29:18 vhost004 kernel: qemu-system-x86: page allocation failure: 
order:4, mode:0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO)
, nodemask=(null)
May 05 18:29:18 vhost004 kernel: qemu-system-x86 cpuset=emulator 
mems_allowed=0-1
May 05 18:29:18 vhost004 kernel: CPU: 8 PID: 1499 Comm: qemu-system-x86 
Tainted: G  I  4.15.0-0.bpo.2-amd64 #1 Debian 4.
15.11-1~bpo9+1
May 05 18:29:18 vhost004 kernel: Hardware name: HP ProLiant DL380 G6, BIOS P62 
08/16/2015
May 05 18:29:18 vhost004 kernel: Call Trace:
May 05 18:29:18 vhost004 kernel:  dump_stack+0x5c/0x85
May 05 18:29:18 vhost004 kernel:  warn_alloc+0xfc/0x180
May 05 18:29:18 vhost004 kernel:  __alloc_pages_slowpath+0xde9/0xdf0
May 05 18:29:18 vhost004 kernel:  ? _cond_resched+0x16/0x40
May 05 18:29:18 vhost004 kernel:  ? page_add_file_rmap+0xa4/0x140
May 05 18:29:18 vhost004 kernel:  __alloc_pages_nodemask+0x231/0x250
May 05 18:29:18 vhost004 kernel:  kmalloc_order+0x14/0x40
May 05 18:29:18 vhost004 kernel:  kmalloc_order_trace+0x1d/0xa0
May 05 18:29:18 vhost004 kernel:  kvm_dev_ioctl+0xb4/0x6b0 [kvm]
May 05 18:29:18 vhost004 kernel:  do_vfs_ioctl+0xa2/0x620
May 05 18:29:18 vhost004 kernel:  SyS_ioctl+0x74/0x80
May 05 18:29:18 vhost004 kernel:  do_syscall_64+0x8d/0x120
May 05 18:29:18 vhost004 kernel:  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
May 05 18:29:18 vhost004 kernel: RIP: 0033:0x7f69164b1dd7
May 05 18:29:18 vhost004 kernel: RSP: 002b:7ffc695532e8 EFLAGS: 0246 
ORIG_RAX: 0010
May 05 18:29:18 vhost004 kernel: RAX: ffda RBX: ae01 
RCX: 7f69164b1dd7
May 05 18:29:18 vhost004 kernel: RDX:  RSI: ae01 
RDI: 000b
May 05 18:29:18 vhost004 kernel: RBP:  R08: 55b591d479b8 
R09: 0050
May 05 18:29:18 vhost004 kernel: R10: 0020 R11: 0246 
R12: 55b593788d90
May 05 18:29:18 vhost004 kernel: R13: 0002 R14: 0120 
R15: 
May 05 18:29:18 vhost004 kernel: Mem-Info:
May 05 18:29:18 vhost004 kernel: active_anon:12701 inactive_anon:21275 
isolated_anon:0
  active_file:303829 inactive_file:975269 
isolated_file:0
  unevictable:16671 dirty:47425 writeback:0 
unstable:0
  slab_reclaimable:63412 
slab_unreclaimable:196886
  mapped:25834 shmem:10280 pagetables:5345 
bounce:0
  free:71752 free_pcp:0 free_cma:0
May 05 18:29:18 vhost004 kernel: Node 0 active_anon:41984kB 
inactive_anon:67596kB active_file:848712kB inactive_file:1819684kB 
unevictable:64852kB isolated(anon):0kB isolated(file):0kB mapped:85292kB 
dirty:31208kB writeback:0kB shmem:40328kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 24576kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 05 18:29:18 vhost004 kernel: Node 1 active_anon:8820kB 
inactive_anon:17504kB active_file:366604kB inactive_file:2081392kB 
unevictable:1832kB isolated(anon):0kB isolated(file):0kB mapped:18044kB 
dirty:158492kB writeback:0kB shmem:792kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 2048kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 05 18:29:18 vhost004 kernel: Node 0 DMA free:15892kB min:20kB low:32kB 
high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 05 18:29:18 vhost004 kernel: lowmem_reserve[]: 0 3486 30117 30117 30117

May 05 18:29:18 vhost004 kernel: Node 0 DMA32 free:119236kB min:5204kB 
low:8772kB high:12340kB active_anon:40392kB inactive_anon:66052kB 
active_file:837196kB inactive_file:1776840kB unevictable:61688kB 
writepending:30376kB present:3643520kB managed:3577952kB mlocked:61688kB 
kernel_stack:2896kB pagetables:10556kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 05 18:29:18 vhost004 kernel: lowmem_reserve[]: 0 0 26631 26631 26631
May 05 18:29:18 vhost004 kernel: Node 0 Normal free:40668kB min:39748kB 
low:67016kB high:94284kB active_anon:1508kB inactive_anon:1516kB 
active_file:11840kB inactive_file:42860kB unevictable:3164kB writepending:828kB 
present:27787264kB managed:27274752kB mlocked:3164kB kernel_stack:1560kB 
pagetables:324kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
May 05 18:29:18 vhost004 kernel: lowmem_reserve[]: 0 0 0 0 0
May 05 18:29:18 vhost004 kernel: Node 1 Normal free:111212kB min:45132kB 
low:76092kB high:107052kB active_anon:7868kB inactive_anon:17364kB 
active_file:366240kB inactive_file:2081464kB unevictable:1832kB 
writepending:158492kB present:31457276kB managed:30961984kB mlocked:1832kB 
kernel_stack:5304kB pagetables:10500kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 05 18:29:18 vhost004 kernel: lowmem_reserve[]: 0 0 0 

Bug#898016: speech-tools: needs config.guess/sub update for riscv64

[Manuel A. Fernandez Montecelo]

Source: speech-tools
Version: 1:2.5.0-4
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).

The files config.{guess,sub} included in this package are too old to detect this
system.

This package is using dh-autoreconf, as Debian Policy §4.3 recommends, to update
these automatically [1].

However, for some reason it's not working, the tool is not working well together
with the build system as implemented by this package.


[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources

"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).

If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#897671: u-boot does not work on sheevaplug

[Vagrant Cascadian]

Hello U-Boot.

Markus Krebs discovered that the sheevaplug target has again grown and
installation overlaps where the u-boot env is saved since u-boot
~2017.09. Running saveenv overwrites u-boot, and installing u-boot
overwrites any prior environment settings.

More detail on the bug report in Debian:

  https://bugs.debian.org/897671

We don't carry any patches for the sheevaplug u-boot target in Debian,
so this is likely also an issue upstream. Who are the current
maintainers for sheevaplug in u-boot upstream?

A brief summary of the current findings:

On 2018-05-05, Markus Krebs wrote:
> Am 05.05.2018 um 20:36 schrieb Markus Krebs:
>> Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:
>>> * Markus Krebs  [2018-05-05 20:32]:
 I got it. Indeed it has to to with the size of u-boot.
>>>
>>> Does it boot?
>>>
>> 
>> Yes it does.
>
> ... and no longer so, when I "saveenv" :-(
>
> I downloaded u-boot via git; I guess that the config for u-boot for 
> sheevaplug is already broken upstream (in sheevaplug.h):
>
>#define CONFIG_ENV_SIZE 0x2 /* 128k */
>#define CONFIG_ENV_ADDR 0x8
>#define CONFIG_ENV_OFFSET   0x8 /* env starts here */
>
> but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
> in this case 'saveenv' overwrites u-boot (?).
> Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
> so-modified sources, and now I can start Debian fine.

It looks like it was bumped from 0x6 to 0x8 in 2014:

  
http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01

If 0x8 isn't enough, there might be some features in the config to
experiment with removing, or it may need to be bumped again.

Not sure what the best coarse of action is.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#897566: freeplane freezes while entering text node under OpenJDK 10

[Ben Caradoc-Davies]

On 05/05/18 20:01, Felix Natter wrote:

Freeplane upstream has made me aware that this is an OpenJDK issue:
https://bugs.openjdk.java.net/browse/JDK-8202580
This very well fits your logs:
   at
   sun.java2d.pipe.ShapeSpanIterator.lineTo(java.desktop@10.0.1/Native
   Method)
So I think we can close this bug since it's not something fixable in
Freeplane? Please use OpenJDK-9 meanwhile.


Thanks, Felix. That looks convincing. I agree that this is an OpenJDK 
issue, so I will reassign this to openjdk-10 and set forwarded to the 
OpenJDK issue. I will test again when OpenJDK 10 is fixed. Until then I 
am using a wrapper script to set OpenJDK 8.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#897575: Doesn't properly store seen state for handelsblatt.com

[martin f krafft]

retitle 897575 Cannot handle empty ID fields in feed entries
tags 897575 + patch
kthxkby

The problem with the particular site is that they actually have
a bug in their RSS output, meaning that each item has an ID field,
but it's empty. Therefore, when feed.py:_process_entry runs,
entry['id'] is not None, but '', which is a value for what getattr
is concerned, therefore squashing the guid.

The following patch fixes this, although depending on trust_link,
it'll now just store link → link pairs in the seen dictionary, or id
→ id pairs. However, this seems to be what it does for all other
(valid) feeds too, so I guess that's just a design decision (you're
using the dictionary as a set).

--- rss2email-3.9.orig/rss2email/feed.py
+++ rss2email-3.9/rss2email/feed.py
@@ -452,7 +452,8 @@
 # If .trust_guid isn't set, we get back hashes of the content.
 # Instead of letting these run wild, we put them in context
 # by associating them with the actual ID (if it exists).
-guid = entry.get('id', id_)
+entry_id = entry.get('id', '')
+guid = entry_id if len(entry_id) > 0 else id_
 if isinstance(guid, dict):
 guid = guid.values()[0]
 if guid in self.seen:

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#897952: aspell-autobuildhash warnings on upgrade

[Agustin Martin]

2018-05-05 8:22 GMT+02:00 Andrius Merkys :
> Package: aspell-lv
> Version: 0.9.6-6
>
> Dear Maintainers,
>
> during regular package upgrade [(0.9.6-6) over (0.9.6-5)] 
> aspell-autobuildhash throws several warnings about invalid characters in 
> dictionary:
>
> aspell-autobuildhash: processing: lv [lv].
> Warning: The word "Nr." is invalid. The character '.' (U+2E) may not appear 
> at the end of a word. Skipping word.
...
> Warning: The word "š.g." is invalid. The character '.' (U+2E) may not appear 
> at the end of a word. Skipping word.
>
> I wonder whether this means that due to invalid characters these words are 
> altogether removed from prepared hash.

Hi,

This is indeed what happens, those words are ignored. As a matter of
fact this also happened with previous version (changes in this version
are only to adjust references to the new git repo and other minor
issues).

I think the best is to strip those words from the list used to
generate the hash, at least temporaririly. That would remove the
noise.  Allowing dots at the end of the word may have some other
undesired affects, but I still have to think about it.

Thanks for your contribution,

Regards,

-- 
Agustin

Bug#898015: iproute2: 'ip addr add' drops capabilities, breaking ZeroTier

[Mantas Mikulėnas]

Package: iproute2
Version: 4.16.0-2
Severity: normal

zerotier-one (a mesh-VPN program) calls `ip addr add` as non-root, but
with the necessary capabilities present (ambient, inheritable, and
effective).

However, the latest iproute2 version made `ip` drop all capabilities
unconditionally (except for `ip vrf exec`), so this no longer works --
ip receives "Operation not permitted" and ZeroTier becomes unable to
configure its tunnel interface, making the VPN completely unusable.

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

Kernel: Linux 4.15.0-3-amd64 (SMP w/1 CPU core)
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 iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libc6  2.27-3
ii  libcap21:2.25-1.2
ii  libcap2-bin1:2.25-1.2
ii  libdb5.3   5.3.28-13.1+b1
ii  libelf10.170-0.4
ii  libmnl01.0.4-2
ii  libselinux12.7-2+b2

Versions of packages iproute2 recommends:
pn  libatm1   
ii  libxtables12  1.6.2-1

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- Configuration Files:
/etc/iproute2/rt_tables changed [not included]

-- debconf information excluded

Bug#884567: lintian: Report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Mattia Rizzolo]

Control: tag -1 - moreinfo

On Sat, May 05, 2018 at 05:36:27PM +0100, Chris Lamb wrote:
> > lintian: Report about mismatches between the Build-IDs field and
> > the content of /usr/lib/debug/
> 
> Is this still an issue with a fixed debhelper?

AFAIK it is not, but I believe lintian should check for this
nonetheless: another debhelper bug may pop up in the future, and there
are packages building dbgsyms without using the facilities provided by
debhelper.

-- 
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#898014: autopkgtest-pkg-python in Testsuite ignored if tests/control exists

[Russ Allbery]

Package: autopkgtest
Version: 5.3.1
Severity: wishlist

I have a package (remctl) that provides both Perl and Python bindings with
corresonding binary packages.  I want to run autopkgtest-pkg-perl and
autopkgtest-pkg-python tests on the corresponding binary packages.

autodep8 can't see how to run Perl tests because the Perl module is in a
perl subdirectory, which isn't surprising, so just adding
autopkgtest-pkg-perl to the Testsuite control field didn't work for those
tests.  I therefore manually created a debian/tests/control file with the
corresponding content, and that works fine (except for the smoke tests
because of the subdirectory thing, but I can work on that later).

Surprisingly, once I did that, the autopkgtest-pkg-python tests specified
via the Testsuite control field stopped running.  That value was ignored
once a debian/tests/control file exists.

In retrospect, this makes sense given what I suspect to be the implementation
using autodep8, but it's unfortunate.  If I explicitly list
autopkgtest-pkg-python in Testsuite, it would be nice to still generate and
run a test control file using autodep8 for it as well as the
manually-specified debian/tests/control file.  (In other words, I would
like to run the merger of the tests in debian/tests/control plus the tests
corresponding to any autopkgtest-pkg-* entries in the Testsuite control
field.)

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.6.1
ii  libdpkg-perl1.19.0.5
ii  procps  2:3.3.14-1+b1
ii  python3 3.6.5-3
ii  python3-debian  0.1.32

Versions of packages autopkgtest recommends:
ii  autodep8  0.12

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-4

-- no debconf information

Bug#897794: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Alf Gaida]

Hi Andreas,
there is a MR waiting in salsa.

Cheers Alf

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Stefan Weil]

On Wed, 25 Apr 2018 10:51:09 +0200 Graham Inggs  wrote:
> I agree, and with the upload of leptonlib 1.75.3-4, the tests are now
> run during the build [3], and failure here will result in a failed
> build. Builds of leptonlib were successful on all architectures [4]
> except sparc64, which is notoriously sensitive to unaligned memory access.

Leptonica 1.76.0 built without problems and passed nearly all tests on
sparc64.

With a small fix for a misaligned memory read, only a single failing
test remains:
https://github.com/DanBloomberg/leptonica/pull/342

Bug#865359: python-backports-shutil-get-terminal-size: ipython invocation of module shutil_get_terminal_size broken

[Tore Ferner]

Tore Ferner:
> Hello,
> 
> I can confirm that the package python-backports-shutil-get-terminal-size
> breaks ipython in stretch with a traceback as described in initial bug
> report. It also breaks the sagemath package (the CLI sage command) for
> the same reason.
> 
> I quick-fixed it thusly (diff -u):

Hello again,

It turned out I had one pip-installed package, "configparser", that
installed itself in a sub-folder "backports" in a way that shadowed
debian's shutil-backport which also is in a "backports" folder.

I guess a better solution is either

(A) to pip-uninstall configparser:

   $ pip uninstall configparser

or (B) also to install the "shutil_get_terminal_size" with pip if you
have pip-installed "configparser" and want/need to keep it:

   $ pip install backports.shutil-get-terminal-size

With either (A) or (B) both ipython and sage start without a traceback
(in stretch).


Best regards,
Tore

Bug#898013: lua-redis: Not compatible with lua5.3

[Tim Duesterhus]

Package: lua-redis
Version: 2.0.5~git20141117.880dda9-1
Severity: important

Dear Maintainer,

this package cannot be used with lua5.3 out of the box, because
it is not installed into the LUA_PATH:

  root@637bfdbb9112:/# lua5.3
  Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
  > require("redis")
  stdin:1: module 'redis' not found:
no field package.preload['redis']
no file '/usr/local/share/lua/5.3/redis.lua'
no file '/usr/local/share/lua/5.3/redis/init.lua'
no file '/usr/local/lib/lua/5.3/redis.lua'
no file '/usr/local/lib/lua/5.3/redis/init.lua'
no file '/usr/share/lua/5.3/redis.lua'
no file '/usr/share/lua/5.3/redis/init.lua'
no file './redis.lua'
no file './redis/init.lua'
no file '/usr/local/lib/lua/5.3/redis.so'
no file '/usr/lib/x86_64-linux-gnu/lua/5.3/redis.so'
no file '/usr/lib/lua/5.3/redis.so'
no file '/usr/local/lib/lua/5.3/loadall.so'
no file './redis.so'
  stack traceback:
[C]: in function 'require'
stdin:1: in main chunk
[C]: in ?

After symlinking redis.lua to the version in 5.1 the package works fine:

  root@637bfdbb9112:~# ls -alh /usr/share/lua/5.3/redis.lua 
  lrwxrwxrwx 1 root root 16 May  5 20:06 /usr/share/lua/5.3/redis.lua -> 
../5.1/redis.lua
  root@637bfdbb9112:~# lua5.3
  Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
  > require("redis").connect("*snip*", 6379):set("foo", "bar")
  true
  > require("redis").connect("*snip*", 6379):get("foo")   
  bar


Please add the missing symlink.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lua-redis depends on:
ii  lua-socket  3.0~rc1+git+ac3201d-3

lua-redis recommends no packages.

lua-redis suggests no packages.

-- no debconf information

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 05.05.2018 um 20:36 schrieb Markus Krebs:

Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:

* Markus Krebs  [2018-05-05 20:32]:

I got it. Indeed it has to to with the size of u-boot.


Does it boot?



Yes it does.


... and no longer so, when I "saveenv" :-(

I downloaded u-boot via git; I guess that the config for u-boot for 
sheevaplug is already broken upstream (in sheevaplug.h):


  #define CONFIG_ENV_SIZE 0x2 /* 128k */
  #define CONFIG_ENV_ADDR 0x8
  #define CONFIG_ENV_OFFSET   0x8 /* env starts here */

but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
in this case 'saveenv' overwrites u-boot (?).
Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
so-modified sources, and now I can start Debian fine.


Markus

Bug#897244: lintian: doc-base-file-references-missing-file for files in depending package

[Russ Allbery]

Rene Engelhard  writes:

> ... and on DDPO, which is what I care about right now. (And NEW)

> 143548 _errors_

Just as a data point, if I saw 143,548 errors in a Debian package from an
experienced maintainer such as yourself, my immediate first thought would
be some bug in Lintian.  Not that you had somehow done something horribly
wrong with your package.

-- 
Russ Allbery (r...@debian.org)   

Bug#898012: RFA: xsd -- XML Data Binding for C++

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wnpp
Severity: normal

Hello,

I search an adopter for the xsd package.


The package description:

 CodeSynthesis XSD is an open-source, cross-platform W3C XML Schema to
 C++ data binding compiler. Provided with an XML instance specification
 (XML Schema), it generates C++ classes that represent the given
 vocabulary as well as parsing and serialization code.
 You can then access the data stored in XML using types and functions
 that semantically correspond to your application domain rather than
 dealing with intricacies of reading and writing XML.
 

CU
Jörg
- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlruDakACgkQCfifPIyh
0l3WIBAAm8kQOq1LppObtCMPgQWWHDuFnr2NBqMYjc5ezJah/2fglXMJ4OVi51gq
v+h2DFYg04goFcPwpRaJJvCubWk3qPFAiACZGINU7/MKoZSY0ISAGqp8yHPVE1i8
JXyAh3vbRE0OcMb80sNRmarlp63CSIleZbyhquM2nbDvb4hWI9/OPeFkTVCOiPPo
hVO5tD6h+7t96AJcYaacc5d6L3cJSTh4LhmexGkP/rUW8Tg9CZIqhz6aRKKPqCqy
n/ErZM8MoDEaLRfgJPNiI5F0E7lhRQ6qXyWH76NUAb87dekuDnsMP4KH8kVa53Cb
Spk05zqmaQxSY5N8J2nj47dLww1BSP2dpEy3Njovmvfc5hhAUT6oXYFsMicV+trK
Q8H8q3QbyqqbKDGpdyLzeX/RQZjX0mpbfdQAnZfkMOHmb2Ji5dnXF9CdpnqFBQy1
4mrh6xFOh6G9xZ2ulrmTU/Ci0lAfkRMCwRzGY15YYIVvz4a7Y6vsGp2FsDpOskS/
x2TckGnyvmLGd7i9R+0npFRzMyj/Tq1I65uL+BP8R3/pzAcx/v+Pz0lSB+jxpnGk
/q56/pGosMZxKqRSV/PbgsW2nLzfujttSbC0Nr7dq81REObWngnrb/13fXOvoatR
1Ny6R6MgjQSB1fv5TcKGMqLcpfbs6Im6U+ZINcSaPCW65fRyfyI=
=kitS
-END PGP SIGNATURE-

Bug#898011: libconfig-model-perl: new version breaks multiple autopkgtests of other packages

[gregor herrmann]

Control: block -1 with 897960
Control: block -1 with 897963
Control: block -1 with 897962

On Sat, 05 May 2018 21:06:08 +0200, Paul Gevers wrote:

> Source: libconfig-model-perl
> Version: 2.123-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: breaks
> Control: affects -1 src:libconfig-model-dpkg-perl
> Control: affects -1 src:libconfig-model-systemd-perl
> Control: affects -1 src:libconfig-model-tkui-perl
> 
> With the upload of version 1.123-1 of libconfig-model-perl the
> autopkgtests of libconfig-model-dpkg-perl, libconfig-model-systemd-perl
> and libconfig-model-tkui-perl started to fail. 

Right, that's a known temporary problem, tracked as #897960,
#897963, #897962.

I guess this bug can be closed once the three reverse dependencies
are updated.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#878191: corrupted double-linked list: 0x0000560ab80de850

[Reimar Döffinger]

Sample file or valgrind log might be more useful.
Valgrind as this backtrace is when the memory corruption
is detected, when it occurred is more useful.
Also, whether this happens with -vo other than vdpau.
The probesize thing is probably not particularly relevant.

Bug#897687: libpam-kwallet5: kwallet stopped working

[Sylvain L. Sauvage]

Le samedi 5 mai 2018, 13:07:50 CEST Maximiliano Curia a écrit :
> Hi!
> 
> As far as I could test the issue it should be solved in the new version, 
> could 
> you please check if the issue is also solved for you?
> 
> Happy hacking,

Hi,

Confirmed.
Just installed the -3 and it works.

Thanks!
-- 
 Sylvain L. Sauvage

Bug#898011: libconfig-model-perl: new version breaks multiple autopkgtests of other packages

[Paul Gevers]

Source: libconfig-model-perl
Version: 2.123-1
Severity: normal
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 src:libconfig-model-dpkg-perl
Control: affects -1 src:libconfig-model-systemd-perl
Control: affects -1 src:libconfig-model-tkui-perl

With the upload of version 1.123-1 of libconfig-model-perl the
autopkgtests of libconfig-model-dpkg-perl, libconfig-model-systemd-perl
and libconfig-model-tkui-perl started to fail. This is currently
delaying the migration of libconfig-model-perl version 2.123-1 to
testing. Can you, together with the maintainers of the failing packages
(which I CC'ed to this bug), please investigate if the failure is caused
by libconfig-model-perl and if it is more severe than failing test cases
or if the tests of those packages need updating (e.g. for testing
deprecated functionality)?

If the issue is in the autopkgtests of the other packages, please clone
and reassign this bug. In this case and if you want your package to
migrate in a timely fashion, please contact me after the maintainers of
those packages agree and I can add an ignore hint to the migration software.

Paul

¹ https://ci.debian.net/packages/libc/libconfig-model-dpkg-perl
² https://ci.debian.net/packages/libc/libconfig-model-systemd-perl
³ https://ci.debian.net/packages/libc/libconfig-model-tkui-perl



signature.asc
Description: OpenPGP digital signature

Bug#790814: evaluating Kanboard for mentoring

[Daniel Pocock]

On 05/05/18 15:56, Thomas Levine wrote:
> You did make it sound very appealing in comparison with those I tried
> that are available in Sandstorm. Please install it, and I will at least
> try it out.
> 
> It might save me enough time to be worth the effort to administrate it,
> though I would probably check with other hackers to see if anyone else
> wants to administrate it, and even then, I would probably do that only
> if other Debian GSoC projects were going to use it too.
> 



I had a look at the package[1] and it doesn't appear ready to use yet.
I made a quick attempt to make it work:

- created /etc/kanboard

- copied config.default.php to /etc/kanboard/config.php

- symlinked /usr/share/kanboard/config.php -> /etc/kanboard/config.php

- created /etc/kanboard/apache.conf:


Alias /kanboard /usr/share/kanboard/

Allow from all
Options -MultiViews
Require all granted
DirectoryIndex index.php


for inclusion into a VirtualHost

- in the config.php, I set DATA_DIR = /var/lib/kanboard

- created the directory:
  mkdir -p /var/lib/kanboard/data
  chown www-data.www-data /var/lib/kanboard/data

It still doesn't work, this appears in the log:

Fatal error:  require(): Failed opening required
'/usr/share/kanboard/app/../vendor/autoload.php'
(include_path='.:/usr/share/php:/usr/share/pear') in
/usr/share/kanboard/app/common.php on line 3


Most of the above steps should be done by the package itself.  If
anybody has time to help finish the package I'd be happy to install it
on the outreach-lab.debian.net server.  The package doesn't need to be
uploaded into Debian, just as long as the necessary changes are in a
clone of the Git repository so I can build the package myself.
Alternatively, maybe somebody can check with other teams using Kanboard
to see if they have packaged it in another repository or something.

Regards,

Daniel


1. https://salsa.debian.org/debian/kanboard

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

[Ben Hutchings]

On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote:
> On 04/05/18 11:52, Ben Caradoc-Davies wrote:
> > - Pressing *any* key repeatedly is enough to eventually wake up the 
> > plymouth LUKS screen. For example, pressing Backspace many times.
> 
> Even a modifier key is sufficient. Without input, the screen remains 
> blank indefinitely (with just a blinking cursor for "quiet" boot). 
> Pressing right Alt 11-18 times (varies from test to test) causes the 
> plymouth LUKS passphrase screen to appear.
> 
> I have attached a photo of the screen for a boot with "quiet" removed 
> from and "plymouth.debug" added to the kernel command line.

I wonder if this is related to the recent RNG changes.  It seems that
many programs have started using blocking RNG functions like
getentropy(), and now that the kernel is more conservative in its
initial entropy estimation they can block for a long time.  Keyboard or
mouse input adds entropy.

At a guess, plymouth is starting the X server and the X server wants
random bits for MIT-MAGIC-COOKIE authentication.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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

Bug#898010: Dpkg::Source::Package::V3::Quilt unconditionally tries to chmod patches

[Sean Whitton]

Package: dpkg
File: /usr/share/perl5/Dpkg/Source/Package/V3/Quilt.pm
Version: 1.19.0.5
Severity: minor

Dear maintainer,

Dpkg::Source::Package::V3::Quilt unconditionally tries to chmod patches
without checking whether the permissions it would set are already set on
the patch:

chmod(0666 & ~ umask(), $patch)
or syserr(g_("unable to change permission of '%s'"), $patch);

In my setup I sometimes want to build source packages from trees that
are not owned by the user calling dpkg-source, so the chmod call fails.
It would be nice if dpkg would check whether the chmod would do
anything, and not try to call it if it would not.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#897967: linux-image-4.9.0-6-amd64: Kernel 4.9.0-6-amd64 boot failed

[Ben Hutchings]

Control: tag -1 moreinfo

On Sat, 2018-05-05 at 13:30 +0430, SMAH1 wrote:
> Package: src:linux
> Version: 4.9.88-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
[...]

You forgot to fill in this information.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

[Chris Lamb]

tags 884499 + pending
thanks

Actually, let's give this a whirl. Implemented in Git,
pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/1ecc761fea7b22f85faf400ac134d24438454e4d

  checks/debhelper.desc  | 12 +++
  checks/debhelper.pm|  5 -
  debian/changelog   |  4 +++-
  .../debian/debian/control.in   | 14 +
  .../debian/debian/rules| 23 ++
  .../desc   |  6 ++
  .../tags   |  2 ++
  7 files changed, 64 insertions(+), 2 deletions(-)


Regards,

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

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Markus Krebs  [2018-05-05 20:32]:
> I got it. Indeed it has to to with the size of u-boot.

Does it boot?
-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:

* Markus Krebs  [2018-05-05 20:32]:

I got it. Indeed it has to to with the size of u-boot.


Does it boot?



Yes it does.

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

I got it. Indeed it has to to with the size of u-boot.
The space in the command in your instructions "nand erase 0x0 0x8" 
is too small now for u-boot.kwb. I tried "nand erase 0x0 0xc0" 
(which should still be ok, as mtd0 is 1 Megabyte) and everything works 
fine (flashing with ${filesize} afterwards of course).


This works when flashing from u-boot. For flashing from Debian maybe 
"/etc/fw_env.config" must be changed? Or the commands/values in 
/usr/share/doc/u-boot/README.Debian which are


  sudo flash_erase /dev/mtd0 0 0
  sudo nandwrite -p /dev/mtd0 /usr/lib/u-boot/sheevaplug/u-boot.kwb

I don't know how, though. Maybe you can direct me?

Am 05.05.2018 um 14:41 schrieb Markus Krebs:

It gives the same type of error when flashing:

  NAND write: device 0 offset 0x0, size 0x934cc
  nand_write_ecc: Attempt to write not page aligned data
   0 bytes written: ERROR


Am 05.05.2018 um 11:13 schrieb Martin Michlmayr:

Can you try:
http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2018.05~rc3+dfsg-1_armel.deb 

Bug#869030: elixir: Please package v1.4

[Dato Simó]

retitle 869030 elixir: please package v1.6
thanks

I would also love to see an updated Elixir in Debian, particularly 
now that v1.6 is released.


If you don't have the time to do it, would you welcome some help 
in preparing the upload?


-d

Bug#613000: Convert Hardening Debian to XML

[Marcos Fouces]

Hello

I already done the following work so far and uploaded to the repo [1]:

* Imported SVN repo to git.

* Migrated debiandoc sgml to Docbook XML. In order to test it, i
slightly adapted the debian-handbook build apparatus moslty due to its
simplicity.

* Merged german an french *.po files with latest version of original text.

* Used po4a-gettextize in order to get every translated string in the
rest of available languages (spanish, italian, japanese,  chinese,
portuguese).

All languages have at least 30% translated strings.

Hope that helps to maintain this good manual.

Greetings.

Marcos

[1] https://anonscm.debian.org/cgit/ddp/securing-debian-howto.git/log/


> On Sun, Apr 16, 2017 at 03:16:24PM +0200, Marcos Fouces wrote:
>> Hello
>>
>> I would be glad to (try my best to) convert this book to XML. I have a
>> personal interest in it because (time ago) i learn a lot from it.
> Great.
>  
>> I already did a clean and complete (hopefully...) of its SVN repo to git and
>> asked for write access on alioth ddp repo.
> Please coordinate how exactly push this through.  Javi is the maintainer
> of FAQ.  
>
> Please check with:
>  https://wiki.debian.org/Teams/DDP
>
> I just added you but please discuss with javi how exactly you start
> committing.
>
> Osamu

Bug#818928: terminology: fails to start terminology

[Ross Vandegrift]

Control: tags -1 moreinfo

On Mon, Mar 21, 2016 at 09:26:48PM +0200, Denys wrote:
> Dear Maintainer, terminology fails to start on debian sid.
> 
> ERR<8080>:terminology main.c:3001 elm_main() Could not initialize key 
> bindings.
> ERR<8080>:efreet_cache lib/efreet/efreet_cache.c:1108 on_send_register()
> org.enlightenment.DBus.Canceled Canceled by user.
> CRI: lib/eet/eet_lib.c:626 eet_shutdown() eina_log_print() unknown domain -1,
> original message format 'Init count not greater than 0 in shutdown.'

I don't know what could've caused this issue.  But I'm not able to reproduce
with EFL 1.20 and terminology 1.1.1 now in sid.  Could you retest?

Thanks,
Ross

Bug#773057: Dependency problem

[Ross Vandegrift]

Control: tags -1 moreinfo

On Wed, Jan 11, 2017 at 04:35:40PM +0200, Bruce Weirdan wrote:
> There's a dependency problem that renders the fix unusable:
> terminology 0.9.1-1 depends on libeina1 >=1.8.0 (available 1.8.6-2.5+b1)
> libemotion-players 1.18.4-1 depends on libeina1a >=1.18.4-1 (available
> 1.18.4-1) which conflicts with libeina1

EFL 1.20 has recently migration from experimental to sid & buster.  This issue
should no longer cause installation issues.  Can you retest?

Thanks,
Ross

Bug#897568: zfs-dkms 0.7.6 fails to build on 4.16.0-1-amd64

[John Allen]

According to the release notes (
https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.8), the latest
version (0.7.8) is needed to build on the 4.16 kernel.

The latest version in Debian is still 0.7.6 (in testing since 7 March
2018).

John

Bug#773057: Dependency problem

[Bruce Weirdan]

Installable and working.

Bug#897904: libzstd: please make the build reproducible

[Alex Mestiashvili]

Thanks for the patch and forwarding it upstream!
I'll incorporate it to 1.3.4+dfsg-3 and upload once I check the test
issues on gnu/hurd.

Bug#898009: sphinx-common: prefer scripts from py3k, if available

[Sandro Tosi]

Package: sphinx-common
Version: 1.7.4-1
Severity: important

Hello,
looking at /var/lib/dpkg/info/sphinx-common.postinst it seems to me sphinx
"prefers" script from the python2 package, if it's installed. I think we want to
migrate to actually build sphinx doc using the python3 package, so i think that
postinst script should be updated to link scripts from the py3k package instead.

This resulted in an issue when building numpy, where we specify to use the numpy
module from python3.6 but the upstream makefile still refers to sphinx-build
which is forcibly linked to ../share/sphinx/scripts/python2/sphinx-build ; this
is still on my development workstation where i want to have both python-sphinx
and python3-sphinx installed (i maintain some sphinx extensions so i want to be
able to test-build them on both before prepare the official package in a
chroot).

I set the priority to important, because IIRC there is a lintian working to use
py3k sphinx if a python-sphinx deps is detected.

Thanks for maintaining sphinx!

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

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

Versions of packages sphinx-common depends on:
ii  libjs-sphinxdoc  1.7.4-1

Versions of packages sphinx-common recommends:
ii  python3-sphinx  1.7.4-1

sphinx-common suggests no packages.

-- no debconf information

Bug#889095: Haikunator

[Lin Haowen]

I can adopt it. My company uses it.

Bug#898007: RFS: edenmath.app/1.1.1a-8

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for my package "edenmath.app".

 * Package name: edenmath.app
   Version : 1.1.1a-8
   Upstream Author : Chad Armstrong ,
 Rob Burns 
 * URL : http://www.eskimo.com/~pburns/EdenMath/
 * License : GPL-2+
   Section : math

It builds this binary package:

edenmath.app - Scientific calculator for GNUstep

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

  https://mentors.debian.net/package/edenmath.app

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/edenmath.app/edenmath.app_1.1.1a-8.dsc

Git repository:

  https://salsa.debian.org/gnustep-team/edenmath.app

Changes since the last upload:

  * debian/compat: Bump to 11.
  * debian/source/format: New file, set to 3.0 (quilt).
  * GNUmakefile: Move local modifications...
  * debian/patches/include-help.patch: ...here.
  * debian/patches/series: New file.
  * debian/rules: Rewrite for modern dh.  Move Resources to /usr/share.
Enable hardening.  Do not use gs_make (Closes: #897622).
(override_dh_compress): Exclude .rtf files.
  * debian/maintscript: New file, handle the dir to symlink switch.
  * debian/control: Run wrap-and-sort -ast for diff-friendliness.
(Uploaders): Remove Hubert on his request; add myself.
(Build-Depends): Bump debhelper to >= 11.  Drop ancient
libgnustep-gui-dev version constraint.  Require gnustep-make >=
2.7.0-3 for the optim variable definition.
(Vcs-Git, Vcs-Browser): New fields.
(Standards-Version): Compliant with 4.1.4 as of this release.
(Description): Mention the original app.
  * debian/changelog: Whitespace cleanup.
  * debian/lintian-override:
  * debian/menu:
  * debian/dirs: Delete; no longer necessary.
  * debian/install: New file; install the .desktop file.
  * debian/EdenMath.desktop: Remove invalid Version key, add Keywords, set
Icon to the real file in /usr/share.
  * debian/watch: New file.
  * debian/copyright: Rewrite in format 1.0.

Bug#897958: plymouth: long delay before splashscreen with kernel 4.16

[Arnaud Meyer]

Package: plymouth
Followup-For: Bug #897958

Dear Maintainer,

I found the same issue on my system, also just after upgrading to
kernel 4.16, once available in testing.

I also use full-disk encryption, so I need to input the volume password
using Plymouth interface each time the computer boots (don't know
whether this is related).

Now, after loading the 4.16 kernel, an empty Plymouth splash screen
(properly themed) is displayed for approx. 1 minute, during which the
ESC key has no effect.

After that delay, the input field for entering encryption passphrase is
shown and everything boots up and works properly after. 
(If ESC was pressed during the wait, the text interface also shows up
properly after the delay, asking passphrase).

Booting kernel 4.16 with 'nosplash' does not reproduce this problem.

Booting kernel 4.15 with 'splash' does not reproduce this problem.

Thank you in advance and regards,
Arnaud Meyer.


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

Kernel: Linux 4.16.0-1-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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.51
ii  initramfs-tools  0.130
ii  libc62.27-3
ii  libdrm2  2.4.91-2
ii  libplymouth4 0.9.3-2
ii  lsb-base 9.20170808
ii  systemd  238-4
ii  udev 238-4

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 9.0.5
ii  plymouth-themes  0.9.3-2

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed:
[Daemon]
Theme=solar


-- no debconf information

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

[Chris Lamb]

Chris Lamb wrote:

> > lintian: Pedantic check for packages not using debhelper or CDBS

We actually already have this as a classification tag of sorts in
checks/debhelper.pm:

if (%build_systems) {
my @systems = sort(keys(%build_systems));
tag 'debian-build-system', join(', ', @systems);
} else {
tag 'debian-build-system', 'other';
}


Regards,

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

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

[Chris Lamb]

tags 884499 + moreinfo
thanks

Hi,

> lintian: Pedantic check for packages not using debhelper or CDBS

I'm in two minds about this. Whilst I would like everyone to use such
things, as it was pointed out recently Lintian tags should always be
actionable.

If one's personal style was not to use debhelper or CDBS then this
would simply be overly-didactic or annoying, leading to folks
ignoring Lintian in the future.

Any thoughts?


Regards,

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

Bug#898006: stretch-pu: package pcl/1.8.0+dfsg1-3

[Jochen Sprickerhof]

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

Dear release team,

in #894656 I was asked to add libvtk6-qt-dev as a dependency to
libpcl-dev in stretch. I would like to do this, except for armel and
armhf which fails due to OpenGLES, cf. #835292.

The resulting debdiff is attached.

Thanks for consideration

Jochen
diff -Nru pcl-1.8.0+dfsg1/debian/changelog pcl-1.8.0+dfsg1/debian/changelog
--- pcl-1.8.0+dfsg1/debian/changelog2016-09-04 07:30:23.0 +
+++ pcl-1.8.0+dfsg1/debian/changelog2018-05-05 12:52:44.0 +
@@ -1,3 +1,9 @@
+pcl (1.8.0+dfsg1-4+deb9u1) stretch; urgency=medium
+
+  * Add dependency to libvtk6-qt-dev (Closes: #894656)
+
+ -- Jochen Sprickerhof   Sat, 05 May 2018 14:52:44 +0200
+
 pcl (1.8.0+dfsg1-3) unstable; urgency=medium
 
   * Disable QT on arm (Closes: #835292)
diff -Nru pcl-1.8.0+dfsg1/debian/control pcl-1.8.0+dfsg1/debian/control
--- pcl-1.8.0+dfsg1/debian/control  2016-09-04 07:22:11.0 +
+++ pcl-1.8.0+dfsg1/debian/control  2018-05-05 12:52:44.0 +
@@ -40,6 +40,7 @@
 libflann-dev,
 libvtk6-dev,
 libqhull-dev,
+libvtk6-qt-dev [!armel !armhf],
 libopenni-dev [!s390x !alpha !hppa !hurd-i386 !kfreebsd-any !m68k !sh4 
!sparc64],
 libopenni2-dev [!armel !hppa !hurd-i386 !kfreebsd-any !m68k 
!powerpcspe],
 libpcl-apps1.8 (= ${binary:Version}),

Bug#880922: lintian: Check for -dev -> runtime library package dependencies

[Chris Lamb]

tags 880922 + moreinfo
thanks

Hi Christoph,

> Hopefully, implementation would not that difficult: In debian/control,
> identify -dev packages, in the libdevel section, and if there's a
> related  package in the lib section, the -dev package
> should have a strict versioned dependency on the runtime library. The
> latter is actually already covered by "weak-library-dev-dependency".

Thanks for the report. I was wondering if you could quickly provide
some example "bad" and "good" dependencies. This would 100% confirm
my understanding of what you are after, as well as be useful as
testcases within Lintian.

A very quick draft for a tag description (which I am happy to rework
later) would also be highly appreciated. :)


Best wishes,

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

Bug#898005: autopostgresqlbackup: homepage does no longer exist

[Markus Koschany]

Package: autopostgresqlbackup
Version: 1.0-7
Severity: minor

Hi,

the homepage field is outdated because 
http://projects.frozenpc.net/autopgsqlbackup/ does no
longer exist.

Regards,

Markus

Bug#884567: lintian: Report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Chris Lamb]

tags 884567 + moreinfo
thanks

Hi,

> lintian: Report about mismatches between the Build-IDs field and
> the content of /usr/lib/debug/

Is this still an issue with a fixed debhelper?


Regards,

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

Bug#896465: lintian: Lintian should warn on udebs depending on non-udeb packages

[Chris Lamb]

tags 896465 + moreinfo
thanks

Hi!

> Is it possible to add a check that udeb package depends on a deb
> package?

Is this possible from lintian's "view of the world"? It does not have
access to APT so thus would not know the difference between, say,
libzastd1 and libzstd1.


Best wishes,

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

Bug#898004: llvm-toolchain-6.0: patch to solve error on undefined symbol: LLVMInitializeInstCombine

[Daniel Stender]

Package: llvm-toolchain-6.0
Version: 1:6.0-3
Severity: wishlist

Hi Sylvestre,

I don't know what you're plans are on bringing llvm 6.0.1 into unstable (where 
this has
been solved), but maybe you would like to add this patch [1] into the 6.0 
package in the
meanwhile. With is we can upgrade llvmlite to 0.23.0 into unstable [2].

If you don't want to for whatever reason, please just discard this bug report.

Best,
Daniel Stender

[1] https://reviews.llvm.org/D44140

[2] https://alioth-lists.debian.net/pipermail/pkg-llvm-team/2018-May/008047.html

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Description: Add missing header for InstructionCombining.cpp, in order to export
 LLVMInitializeInstCombine as extern "C"
Origin: https://reviews.llvm.org/rL326843
Bug: https://bugs.llvm.org/show_bug.cgi?id=35947

--- a/lib/Transforms/InstCombine/InstructionCombining.cpp
+++ b/lib/Transforms/InstCombine/InstructionCombining.cpp
@@ -34,6 +34,7 @@
 
//===--===//
 
 #include "InstCombineInternal.h"
+#include "llvm-c/Initialization.h"
 #include "llvm/ADT/APInt.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/DenseMap.h"

Bug#897244: lintian: doc-base-file-references-missing-file for files in depending package

[Chris Lamb]

Rene Engelhard wrote:

> I'd agree for _warnings_, yes.
> 
> Not errors. and these are errors.

Firstly, such a distinction not really relevant here; both are
displayed on DDPO and an outsider reading lintian.d.o would not be
aware of any nuance between the two.

Secondly this state of affairs won't even happen as a Lintian upload
is currently pending (indeed, likely later today) thus making this an
entirely hypothetical scenario.

Lastly — and more importantly — by focusing on the distinction between
"E:" and "W:", etc. I fear you have missed my central point about your
interaction style.


Regards,

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

Bug#865120: release-notes: document i386/amd64 kernel changes for jessie->stretch

[Justin B Rye]

Masanori Goto wrote:
> Recently I encountered this amd64 kernel issue on my i386 architecture
> machine.  I think this is useful to be mentioned. Why don't we want to
> apply this proposed text?

I don't know anything about how widespread or critical or worthy of
documentation this bug might be, but I notice a couple of lines that
have English language problems sneaking back in.

> 
>  Users are advised that the -amd64 flavor of kernel
>  is no longer provided for the i386 architecture.
>  Instead, these kernels are available and installed directly from amd64

"Available and installed" makes it sound as if the kernels are already
automatically installed (and if they can be installed then it's
obvious that they're available).  My draft had

   These kernels should instead be installed directly from the amd64

(With definite article)

>  architecture, using multiarch, the mechanism allowing the
>  installation of foreign-architecture packages.
> 
> 
> 
>  
>   
>To check if you are running i386 user space with
>amd64 kernel, run:
>dpkg --print-architecture; uname -r (would give
>i386 and a flavor ending in
>-amd64).
>   
>  
> 
>  
>   
>To add amd64 as a foreign architecture, run:
>dpkg --add-architecture amd64; apt-get update
>   
>  
>  
>   
>(Install the appropriate kernel metapackage as described above.)
>   
>  
> 
> 
> 
>  Note that installing kernel modules are not officially supported
>  through module-assistant.
> 

Number agreement fix:

   Note that installing kernel modules is not officially supported
   through module-assistant.

But hang on, surely that's not true - handling kernel modules is the
one and only thing module-assistant *does* officially support!  Don't
you mean something more like this?

   Note that module-assistant does not officially
   support foreign-architecture kernel modules.

(So maybe it should add "but DKMS does"?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#892741: llvmlite: FTBFS on mips64el - testsuite segfaults

[Daniel Stender]

Control: severity -1 important

I'm lowering the severity of this bug report now to unblock the migration to 
testing.

DS

-- 
4096R/DF5182C8 (sten...@debian.org)
http://www.danielstender.com/

Bug#898002: RM: python-llvmlite python3-llvmite [mips64el] -- ROM; currently doesn't build on these archs

[Daniel Stender]

Package: ftp.debian.org
Severity: normal

Hello FTP masters,

would you please remove the old binaries python-llvmite and python3-llmvite 
from mips64el (0.19.0-2).

llvmlite [1] currently doesn't build on theses archs (segfault in the 
testsuite, see #892741) and
therefore the current 0.22.0-2 is blocked from migrating to testing.

Thanks,
Daniel Stender

[1] https://packages.qa.debian.org/l/llvmlite.html
 
-- 
4096R/DF5182C8 (sten...@debian.org)
http://www.danielstender.com/

Bug#898003: Newer upstream 2.2.2 available

[Yuri D'Elia]

Package: gmic
Version: 1.7.9+zart-4.1
Severity: wishlist

Dear maintainer, the current upstream version of gmic is at 2.2.2.
The current packaged release is more than one year old.

Bug#898001: libmessage-filters-dev: invalid operands of types ‘’ and ‘int’ to binary ‘operator<’

[Jochen Sprickerhof]

Package: libmessage-filters-dev
Version: 1.13.5+ds1-3
Severity: normal

Compiling with GCC8 gives:

Repos/ros_catkin_ws/src/image_common/image_transport/src/camera_subscriber.cpp:112:64:
   required from here
Repos/ros_catkin_ws/install_isolated/include/message_filters/synchronizer.h:358:14:
 error: invalid operands of types ‘’ and 
‘int’ to binary ‘operator<’
 this->add(evt);

The patch is here and I will include it in the next upload:

https://github.com/ros/ros_comm/pull/1388

Bug#897244: lintian: doc-base-file-references-missing-file for files in depending package

[Rene Engelhard]

Hi,

On Sat, May 05, 2018 at 04:48:12PM +0100, Chris Lamb wrote:
> > And probably even causing a reject from NEW. > 4000 errors/per
> > package.
> 
> Well, I happen to disagree and nor do I think that a large number of
> (false-positive) warnings

I'd agree for _warnings_, yes.

Not errors. and these are errors.

> being temporarily displayed on lintian.d.o

... and on DDPO, which is what I care about right now. (And NEW)

143548 _errors_

Regards,

Rene

Bug#536814: proftpd-basic: :SSL23_GET_SERVER_HELLO:unknown protocol

[Hilmar Preuße]

On 13.07.2009 20:24, Anders Lagerås wrote:

Hi Anders,

https://bugs.debian.org/536814

> When using TLSv1 in proftpd do I get the following error mesage when trying 
> to connect the server:
> 234 AUTH SSL successful
> ftp: SSL_connect error error:140770FC:SSL 
> routines:SSL23_GET_SERVER_HELLO:unknown protocol
> 
That bug is now a few years old. Are you still able to reproduce the
problem using proftp 1.3.6?

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

Bug#541868: mod_tls/2.2.1: unexpected OpenSSL error, disconnecting

[Hilmar Preuße]

On 16.08.2009 21:35, Anders Lagerås wrote:

Hi Anders,

https://bugs.debian.org/541868

> in proftpd.log
> mod_tls/2.2.1: unexpected OpenSSL error, disconnecting
> 
> in control.log
> aug 16 21:20:38 mod_tls/2.2.1[5186]: TLS/TLS-C requested, starting TLS 
> handshake
> aug 16 21:20:39 mod_tls/2.2.1[5187]: TLS/TLS-C requested, starting TLS 
> handshake
> aug 16 21:20:39 mod_tls/2.2.1[5187]: TLSv1/SSLv3 connection accepted, using 
> cipher DHE-RSA-AES128-SHA (128 bits)
> aug 16 21:20:39 mod_tls/2.2.1[5186]: TLSv1/SSLv3 connection accepted, using 
> cipher DHE-RSA-AES128-SHA (128 bits)
> aug 16 21:20:40 mod_tls/2.2.1[5187]: Protection set to Private
> aug 16 21:20:41 mod_tls/2.2.1[5187]: starting TLS negotiation on data 
> connection
> aug 16 21:20:41 mod_tls/2.2.1[5187]: TLSv1/SSLv3 data connection accepted, 
> using cipher DHE-RSA-AES128-SHA (128 bit
> aug 16 21:20:43 mod_tls/2.2.1[5187]: starting TLS negotiation on data 
> connection
> aug 16 21:20:48 mod_tls/2.2.1[5187]: panic: SSL_ERROR_SSL, line 2646: 
>   (1) error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac
> aug 16 21:20:48 mod_tls/2.2.1[5187]: unexpected OpenSSL error, disconnecting
> 
That bug is now a few years old. Are you still able to reproduce the
problem using proftp 1.3.6?

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

Bug#898000: uftrace should be built on arm64

[Matthias Klose]

Package: src:uftrace
Version: 0.8.2-1
Tags: patch

patch at
http://launchpadlibrarian.net/368824240/uftrace_0.8.2-1_0.8.2-1ubuntu1.diff.gz

fyi, I am running ps after the build to see if some processes are still running
after the testing.  If you want to call ps in Debian, you have to build-depend
on the procps package as well.

Bug#537314: proftpd-basic: Server did not properly shut down TLS connection

[Hilmar Preuße]

On 17.07.2009 00:38, Anders Lagerås wrote:

Hi Anders,

https://bugs.debian.org/537314

> After connectiong the server with filezilla does it seems to hang
> when trying to connect with ftp-ssl do I get this message:
> 234 AUTH SSL successful
> [SSL Cipher DHE-RSA-AES256-SHA]
> ssl_getc: SSL_read failed -1 = 104
> 421 Service not available, remote server has closed connection
> Login failed.
> No control connection for command: Transport endpoint is not connected
> After restarting the server does it work for a while again.
> 
That bug is now a few years old. Are you still able to reproduce the
problem using proftp 1.3.6?

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

Bug#865359: python-backports-shutil-get-terminal-size: ipython invocation of module shutil_get_terminal_size broken

[Tore Ferner]

Hello,

I can confirm that the package python-backports-shutil-get-terminal-size
breaks ipython in stretch with a traceback as described in initial bug
report. It also breaks the sagemath package (the CLI sage command) for
the same reason.

I quick-fixed it thusly (diff -u):

---[ begin patch ]-
---
/usr/lib/python2.7/dist-packages/IPython/utils/terminal.py-backup-orig
2016-08-13 14:56:43.0 +0200
+++ /usr/lib/python2.7/dist-packages/IPython/utils/terminal.py
2018-05-05 16:25:36.734613218 +0200
@@ -19,7 +19,11 @@
 from shutil import get_terminal_size as _get_terminal_size
 except ImportError:
 # use backport on Python 2
-from backports.shutil_get_terminal_size import get_terminal_size as
_get_terminal_size
+try:
+sys.path.append('/usr/lib/python2.7/dist-packages/backports')
+from shutil_get_terminal_size import get_terminal_size as
_get_terminal_size
+except ImportError:
+from backports.shutil_get_terminal_size import
get_terminal_size as _get_terminal_size

 from . import py3compat
---[ end   patch ]-


Then both ipython and sage can start without a traceback.


Some package versions:

ii  ipython 5.1.0-3
ii  python-backports-abc0.5-1
ii  python-backports-shutil-get-terminal-size   1.0.0-3
ii  python-backports.ssl-match-hostname   3.5.0.1-1
ii  python-ipython  5.1.0-3
ii  python3-ipython 5.1.0-3
ii  sagemath:amd64  7.4-9
ii  sagemath-common 7.4-9


Best regards
Tore

Bug#897244: lintian: doc-base-file-references-missing-file for files in depending package

[Chris Lamb]

Rene,

> And probably even causing a reject from NEW. > 4000 errors/per
> package.

Well, I happen to disagree and nor do I think that a large number of
(false-positive) warnings being temporarily displayed on lintian.d.o
would change peoples' perceptions of you.

But this all misses my *main* point that such exaggerated, overwrought
and accusatory style of reporting technical issues is not remotely
conducive to a productive atmosphere, let alone a fun one.


Regards,

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

Bug#897937: debhelper: handle whitespace before debhelper-compat B-D

[Peter Pentchev]

On Sat, May 05, 2018 at 04:10:18PM +0300, Peter Pentchev wrote:
> On Sat, May 05, 2018 at 06:18:00AM +, Niels Thykier wrote:
> > Peter Pentchev:
> > > Package: debhelper
> > > Version: 11.2.1
> > > Severity: minor
> > > Tags: patch
> > > 
> > > Hi,
> > > 
> > > Thanks for maintaining and extending debhelper!
> > > 
> > 
> > 
> > Hi Peter,
> > 
> > Thanks for testing and the feedback. :)
> > 
> > > When trying to test the new B-D: debhelper-compat (= 11) mechanism on
> > > my mdk and mdk-doc packages, I stumbled upon a minor issue: if this
> > > dependency is the first one listed, and it's on a separate line (there
> > > are no package names on the "Build-Depends:" line itself), then it is
> > > not recognized because the regular expression used will not match
> > > the whitespace before the "debhelper-compat" token.
> > > 
> > 
> > Indeed, that sounds like an annoying papercut.
> > 
> > > Attached is a trivial patch.  Well, actually the trivial patch is in
> > > the second commit; the first one adds some debhelper-compat tests and
> > > the third one adds a test for the bug fixed by the second one.
> > > Of course, if you feel that adding test-only functions to the Dh_Lib
> > > module is not really proper, it's your call whether to accept just
> > > the fix itself without the tests.
> > > 
> > > Thanks again for taking care of debhelper!
> > > 
> > > Best regards,
> > > Peter
> > > 
> > > [...]
> > I am happy to apply all the patches with/after some minor tweaks:
> > 
> > > From 4680d18a5125ce6a46afa846e9b4866df0ce7a72 Mon Sep 17 00:00:00 2001
> > > From: Peter Pentchev 
> > > Date: Fri, 4 May 2018 23:59:04 +0300
> > > Subject: [PATCH 1/3] Lay the groundwork for testing debhelper-compat.
> > > [...]
> > > diff --git a/lib/Debian/Debhelper/Dh_Lib.pm 
> > > b/lib/Debian/Debhelper/Dh_Lib.pm
> > > index 9c829f0f..9666b7ad 100644
> > > --- a/lib/Debian/Debhelper/Dh_Lib.pm
> > > +++ b/lib/Debian/Debhelper/Dh_Lib.pm
> > > @@ -63,7 +63,7 @@ our (@EXPORT, %dh);
> > >   _doc_main_package _so_or_exec_elf_file 
> > >   _opt_is_known_package _tmpdir _hardlinks
> > >   _use_root _root_cmd DEFAULT_PACKAGE_TYPE
> > > - DBGSYM_PACKAGE_TYPE
> > > + DBGSYM_PACKAGE_TYPE _levels  
> > 
> > No need to export these; no tool (except tests) should need them and
> > they can live with using the fully qualified name.
> > 
> > Example usage:
> > """
> > Debian::Debhelper::Dh_Lib::resetcompat();
> > """
> 
> Right, I should have thought of that.  Will do.
> 
> > Note the separate comment about compat_levels below.
> > 
> > > [...]
> > > @@ -2386,4 +2399,15 @@ sub dbgsym_tmpdir {
> > >   }
> > >  }
> > >  
> > > +sub compat_levels {
> > 
> > Let's move this to Test::DH (and use the same method the max as used in
> > each_compat_from_and_above_subtest).  Probably renamed to
> > "non_deprecated_compat_levels".
> 
> Hm, if by "use the same method" you mean "accept a code ref, wrap
> the creation of the temporary directory in it, and copy some files",
> it wouldn't be exactly the same in this case: here we need to generate
> the control file from a template substituting different B-D contents for
> each test case.  Of course, if you mean just "accept a code ref and
> wrap the temp dir creation within it", that might work - the test case
> itself will remember its original directory and generate the control
> file each time.  Hm, come to think of it, there wouldn't really be any
> harm done if the function also copied the control file over, and then
> the test case regenerated it anyway - install_file() is cheap.
> 
> However, what about the fact that I actually lifted this from
> the debian/gen-provides tool?  It doesn't feel very clean to me to have
> gen-provides use Test::DH, and it certainly feels a bit weird to have
> gen-provides create a temporary directory for each compat level and
> then proceed to completely ignore it and just use the level number.

On second thoughts, maybe you meant "just accept a code ref and pass
the compat levels to it one by one"; I can do that later today, tomorrow
at the latest.  Thanks for the idea, and, yes, it is indeed consistent
with the other Test::DH routines.

> > > [...]
> > > +}
> > > +
> > >  1
> > > [...]
> > > index ..0f711f5f
> > > --- /dev/null
> > > +++ b/t/debhelper-compat/syntax.t
> > > [...]
> > > +
> > > +sub test_build_depends {
> > > + my ($level, $build_depends) = @_;
> > > + my $dir = Test::DH::tempdir(CLEANUP => 1);
> > > [...]
> > 
> > That is actually "File::Temp::tempdir" and should be imported/use'd
> > directly.  E.g.
> > 
> > """
> > use File::Temp qw(tempdir);
> > 
> > ...
> > 
> >   my $dir = tempdir(CLEANUP => 1);
> > """
> 
> Sure, that's actually what I initially wrote; I don't even remember why
> I decided to change it to use the one "already provided" by Test::DH.
> Will do.
> 
> > > -- 
> > > 2.17.0
> > > 
> > 
> > 
> > > From 8cc0086067b77be6f3ac130a50e375c6c379e212 Mon Sep 17 00:00:00 2001
> > > From: Peter 

Bug#864082: fontconfig: please make the cache files reproducible

[Chris Lamb]

forwarded 864082 
https://lists.freedesktop.org/archives/fontconfig/2018-May/006271.html
thanks

This is now *really* on the upstream mailing list... :)

  https://lists.freedesktop.org/archives/fontconfig/2018-May/006271.html


Regards,

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

Bug#897999: octave-symbolic: flaky autopkgtest

[Graham Inggs]

Source: octave-symbolic
Version: 2.6.0-3
User: debian...@lists.debian.org
Usertags: flaky

Hi Maintainer

The autopkgtest for octave-symbolic always fails on Debian CI
infrastructure [1], hanging and eventually timing out at almost 3
hours:

* test
 % system should work on all system, but just runs sysoneline on windows
 fprintf('\nRunning some tests that reset the IPC and produce output\n');
 sympref('ipc', 'system');
 syms x

Running some tests that reset the IPC and produce output

On Ubuntu's infrastructure [2], the autopkgtest fails about 75% of the
time at the same point.

Would you please investigate?  As it is, the autopkgtest is not
suitable for regression testing.

Regards
Graham


[1] https://ci.debian.net/packages/o/octave-symbolic/unstable/amd64/
[2] http://autopkgtest.ubuntu.com/packages/octave-symbolic/bionic/amd64

Bug#896771: claws-mail: When deleting an email, select next unread instead of last read.

[Andreas Ronnquist]

On Tue, 24 Apr 2018 10:26:15 +0200
Benoit Panizzon  wrote:

>Dear Maintainer,
>
>After upgrading from the previous version (sorry I don't know which
>one exactly) I noticed that the logic, which email is being selected
>after deleting an email, has changed in a very bad way which causes me
>to repeateldy deleting emails I did not want to delete.
>
>I sort my emails having the newest at the bottom.
>
>Usualy there are a lot of emails I can just delete.
>
>Previously I marked an unread mail, and hit delete, then the next
>unread (below) was being marked etc, so I could just repeateldy hit
>delete until I got to an email I wanted to read.
>
>After this update, that logic has changed, after deleting an email,
>the one 'above' is being selected, which usualy is an email I have
>read and need to keep. So I need to manualy selecting the next unread
>one disrupting my work flow. And as I am used to just hit delete, I
>often delete the emails I want to keep by error.
>
>I did not find any way to configure this behaviour.
>


I believe you are looking for the hidden option "next_on_delete" which
was added in claws-mail 3.13.1 - 

Close down claws, edit your ($HOME)/.claws-mail/clawsrc

- next_on_delete can be either 0 or 1, I am guessing that your value
is 0.

Either this, or use the clawsker tool where the option you are
looking for is under the GUI tab (also this with claws-mail closed while
doing it).

/Andreas Rönnquist
gus...@debian.org

Bug#897998: ITP: libcatmandu-xls-perl -- modules for working with Excel files within the Catmandu framework

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libcatmandu-xls-perl
  Version : 0.08
  Upstream Author : Nicolas Steenlant 
* URL : https://metacpan.org/release/Catmandu-XLS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for working with Excel files within the Catmandu 
framework

 Catmandu::XLS provides modules for working with Excel .xls and .xlsx files
 within the Catmandu framework.
 .
 Catmandu is a suite of Perl modules
 to ease the import, storage, retrieval, export and transformation
 of metadata records.

This package will be maintained in the Perl team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlrtzRQACgkQLHwxRsGg
ASHqjhAAjMroAsGsw1psVR/RGedi5buSPWrc7K3i4WXHMxX767jIPwkC5k5+h2jR
VObA6EqDD6bK1KOTGgBDVlHzpwK0Ozk1jTB7UOLwW/oEAVpCVQ+mvQpUO+pYBGM1
5SF3PCgCLBdjnj/8po0ZX76WM22tA1E6rpHK+ceQABttetmhg4kixT/HNYQgqj+M
TciNQnaP2qWLvPYokleogTYqm5HInRL4OpmSn0+Hq6FJ/OfkpJn4PYBtQBrY6D2P
MHj6vedzcRgaGPJvM62tGWxBytB9qihCEJ40WDJFiOOAZ4Lt/VWf63P2QcAbLeE3
GxPjgdromED+acpWAk9QmQKkSzamQEEOphXMK+Xv2cSK9MB13DpS7d2TP9r+sS0P
RN7BxE0NXBgiUtqM+oyLy1wZBqmCOOxqgQYM6uLNUm7Yf3J7zCtyZToFKvRK5YhL
9S//f2CXWUAYmMFr1bIKaApyH4wQFDGCkNpUPDmQxMTYJaR5l4Jhn53SRgg6sgc7
6+srsS3JC1Ku7RAjiHdLbO8d9wD/W29XbHB5q2e0ZqyFGcZMzhzExSCizsnyEdoD
bCkiwnYk+oAA0DbRohVSbf0MDh6mTNv6eMCzO9T1SnutM/xWi2WrbHXvznd2nKQM
KZ6vexjPQKJGoqj/bZB40Wq1tmyTXB3sOX+Ff0UXJv5n1hzbCkc=
=g2mh
-END PGP SIGNATURE-

Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Michael J. Redd]

On further investigation, Arne's absolutely right. I upgraded the
kernel back to 4.9.88-1 from Debian Security and installed 'haveged'
(another random number generator). Everything started quickly and
normally after a reboot. Turns out I hadn't noticed this on any of my
other virtual servers because they're all running haveged anyway.

So,

Workarounds:

1. Roll back kernel to 4.9.82-1+deb9u3
OR
2. Install another RNG, such has 'haveged'

Bug#897687: fixed in kwallet-pam 5.12.1-3)

[Mikhail Morfikov]

It looks like the issue is fixed for me, thanks!



signature.asc
Description: OpenPGP digital signature