Bug#898095: ITP: node-syslog-client -- pure JavaScript implementation of Syslog protocol

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: node-syslog-client
  Version : 1.1.1
  Upstream Author : Paul Grove 
* URL : https://github.com/paulgrove/node-syslog-client
* License : Expat
  Programming Lang: JavaScript
  Description : pure JavaScript implementation of Syslog protocol

syslog-client is a pure JavaScript implementation of the BSD Syslog Protocol
RFC 3164 and the Syslog Protocol RFC 5424. It can easily be used to push
some message from a Node.js application to system syslog service.

Bug#897631: Kernel update breaks GDM

[Yannick Ihmels]

On 2018-05-07 01:30, Ben Hutchings wrote:

This may sound like a silly request, but does GDM start up if you
wiggle the mouse for a few seconds?


Yes, that works for me. I found out that my desktop is also affected by 
this bug. The "mouse trick" also works there.

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]

Hi Stuart,

I definitely experience a much shorter delay if I press keys on the keyboard 
vs. doing nothing; the delay decreases from >5 minutes to 10-20 seconds before 
sddm appears.

Sten

Bug#898092: Acknowledgement (sddm: takes extremely long time to start)

[Leandro Doctors]

By the way: lightdm works fine.
(gdm3 does not work at all, but I cannot debug everything at the same time)

Bug#898060: linux-image-4.9.0-6-amd64: q

[yunchih]

Hi, maintainers:

I just rebooted the problematic NFS server, but
the problem soon appeared again!  In other words,
some NFS clients are hanging and server is filled
with the error message:

# dmesg | tail -2
[ 6180.718237] RPC request reserved 84 but used 272
[ 6180.732857] RPC request reserved 84 but used 272
# dmesg | grep RPC | wc -l
2519
# uname -a
Linux home 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 (2018-04-29) x86_64 GNU/Linux

Please help!

Bug#898094: freebirth FTCBFS: multiple reasons

[Helmut Grohne]

Source: freebirth
Version: 0.3.2-9.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

freebirth fails to cross build from source, for many reasons:
 * debian/rules does not pass cross tools to make. The easiest way of
   fixing that is deferring it to dh_auto_build.
 * debian/rules uses the build architecture pkg-config and thus fails
   finding gtk-2, which is only requested for the host architecture by
   its Build-Depends. Using dpkg's buildtools.mk can fix that.
 * The upstream build system hard codes the build architecture compiler
   and the build architecture pkg-config in a few places. Making them
   substitutable is the proper solution here.

The attached patch fixes all of that and makes freebirth cross build
successfully. Please consider applying it.

Helmut
diff -u freebirth-0.3.2/Makefile freebirth-0.3.2/Makefile
--- freebirth-0.3.2/Makefile
+++ freebirth-0.3.2/Makefile
@@ -2,9 +2,10 @@
 #
 
 CC=gcc
+PKG_CONFIG ?= pkg-config
 LOADLIBES=-lm -L/usr/lib -lgtk-x11-2.0
-CFLAGS=-g -Wall $(shell pkg-config --cflags gtk+-2.0)
-LDFLAGS=$(LOADLIBES) $(shell pkg-config --libs gtk+-2.0)
+CFLAGS=-g -Wall $(shell $(PKG_CONFIG) --cflags gtk+-2.0)
+LDFLAGS=$(LOADLIBES) $(shell $(PKG_CONFIG) --libs gtk+-2.0)
 
 OFILES=\
 oscillator.o sequencer.o envelope.o filter.o gtkdial.o mixer.o \
@@ -32,5 +33,5 @@
 
 Makefile.deps:
-   gcc -MM $(CFLAGS) $(CFILES) > Makefile.deps
+   $(CC) -MM $(CFLAGS) $(CFILES) > Makefile.deps
 
 include Makefile.deps
diff -u freebirth-0.3.2/debian/changelog freebirth-0.3.2/debian/changelog
--- freebirth-0.3.2/debian/changelog
+++ freebirth-0.3.2/debian/changelog
@@ -1,3 +1,13 @@
+freebirth (0.3.2-9.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
+   + Let dh_auto_build pass cross tools to make.
+   + Patch build system to allow substituting build tools.
+   + Let dpkg's buildtools.mk supply pkg-config in d/rules.
+
+ -- Helmut Grohne   Thu, 03 May 2018 21:32:18 +0200
+
 freebirth (0.3.2-9.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u freebirth-0.3.2/debian/rules freebirth-0.3.2/debian/rules
--- freebirth-0.3.2/debian/rules
+++ freebirth-0.3.2/debian/rules
@@ -5,8 +5,11 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-CFLAGS=-g -Wall $(shell pkg-config --cflags gtk+-2.0) $(shell dpkg-buildflags 
--get CFLAGS)
-LDFLAGS=$(shell pkg-config --libs gtk+-2.0) $(shell dpkg-buildflags --get 
LDFLAGS)
+-include /usr/share/dpkg/buildtools.mk
+PKG_CONFIG ?= pkg-config
+
+CFLAGS=-g -Wall $(shell $(PKG_CONFIG) --cflags gtk+-2.0) $(shell 
dpkg-buildflags --get CFLAGS)
+LDFLAGS=$(shell $(PKG_CONFIG) --libs gtk+-2.0) $(shell dpkg-buildflags --get 
LDFLAGS)
 
 # Handle DEB_BUILD_OPTIONS
 ifneq "$(findstring noopt,$(DEB_BUILD_OPTIONS))" ""
@@ -29,7 +32,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) CFLAGS="$(CFLAGS)"
+   dh_auto_build -- CFLAGS="$(CFLAGS)"
/usr/bin/docbook-to-man debian/freebirth.sgml > debian/freebirth.1
 
touch build-stamp

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

[Theodore Y. Ts'o]

On Mon, May 07, 2018 at 02:58:03PM +1200, Ben Caradoc-Davies wrote:
> This reverts commit 43838a23a05f ("random: fix crng_ready() test"),
> which causes urandom to hang in early boot even when crng_init==1.
> 
> One impact of this hang is that it prevents display of the plymouth
> graphical passphrase prompt required to proceed with boot. In the
> absence of sources of entropy (such as a wired network adapter?), the
> hang is indefinite. User workarounds are to generate entropy with key
> presses or mouse motion, or to disable the plymouth graphical
> passphrase prompt by removing "splash" from the kernel command line.

Unfortunately, commit 43838a23a05f is needed to address CVE-2018-1108,
which was reported by Jann Horn of Google's Project Zero.  There are
real problems with allowing programs to assume that they have a fully
initialized cryptographic random number generation when they don't.
For an example of the sort of rather embarssing security oopsie that
can result, please see [1]

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

For this reason, I don't really recommend reverting the commit.  Jann
and I did see if we it was blatently exploitable, and I don't think
it's quite as bad, as say, Debian's OpenSSL RNG bug[2].  However, if
you revert the change, I am not sure whether or not a cyber attacker
with the resources of nation-state could be able to find a way predict
random numbers generated during early system startup, for at least
some classes of hardware.

[2] https://www.debian.org/security/2008/dsa-1571

There are discussions about this on LKML; the best way to fix the
problem is to address the userspace problem.  Does userspace *really*
need cryptographic randomness before the user logs in?  And if so,
*why*?  Generating long-term public keys right after a machine is
first booted is a really bad idea.

Regards,

- Ted

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

[Theodore Y. Ts'o]

By the way, if anyone is interested in working on this related
problem:

   https://news.ycombinator.com/item?id=16976421

   The reason why this is hard is because Linux is supported on a
   great number of architectures, and some architectures have more
   than one boot loader that is used. The approach of letting the
   bootloader pass seed entropy is the right answer in general, I
   agree, but unlike OpenBSD we can't assume that it will always be
   present. (OpenBSD only supports a limited number of architectures,
   and a single bootloader.) Hence, no matter what, we have to have
   fallback mechanisms for dealing with the case where we have a
   bootloader which doesn't pass a seed to the kernel.

   The other issue is that I don't get paid to work on the random
   driver in Linux. I've been looking for volunteers to work with the
   grub, syslinux, efistub, not to mention all of the various signed
   bootloaders used by different Android devices, but because we had a
   fallback mechanism there is less motivation for people to want to
   work on this.

   This would actually be a great intern project or GSOC project, but
   this have been so hectic this year, personally and professionally,
   I didn't have the time to commit to hosting an intern or GSOC
   student this summer. :-(

Send me an note, and let's talk.  :-)

  - Ted

Bug#894870: lintian could ask maintainers to use dh_auto_*

[Chris Lamb]

Hi Helmut,

> No. I was pondering it on irc and it didn't seem immediately actionable
> to me. You wanted a bug report anyway and you got one.

(Sure, and that was appreciated so we didn't lose the idea and
context.)
 
> Is there really much point in discussing whether tool diversity is good?
> The case seems pretty clear to me.

Hm? I don't quite follow. Or rather, I'm quite sure of the relevance
here?


Best wishes,

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

Bug#894870: lintian could ask maintainers to use dh_auto_*

[Helmut Grohne]

On Fri, May 04, 2018 at 07:54:46PM +0100, Chris Lamb wrote:
> How did you get on with this? :)

No. I was pondering it on irc and it didn't seem immediately actionable
to me. You wanted a bug report anyway and you got one.

Is there really much point in discussing whether tool diversity is good?
The case seems pretty clear to me.

Helmut

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

[Ben Caradoc-Davies]

On 07/05/18 15:29, Theodore Y. Ts'o wrote:

Unfortunately, commit 43838a23a05f is needed to address CVE-2018-1108,
which was reported by Jann Horn of Google's Project Zero.  There are
real problems with allowing programs to assume that they have a fully
initialized cryptographic random number generation when they don't.


Thanks, Ted. I agree with your concerns. I tried to fix urandom to work 
when crng_init==1 but did not want to touch common code and risk 
reverting the security fixes.


Laurent, is there a workaround in plymouth space? Why does plymouth need 
random numbers?


Kind regards,

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

Bug#898093: sponsorship-requests: fonts-myanmar/1.0-2 [ITA] -- friendly greeter

[kokoye2007]

Package: sponsorship-requests
Severity: normal

Dear Maintainer,

  I am looking for a sponsor for my package "fonts-myanmar"

 * Package name: fonts-myanmar
   Version : 1.0-1
   Upstream Author : Debian Fonts Task Force 

 * URL : https://launchpad.net/ttf-burmese-fonts
 * License : gpl3
   Section : fonts

  It builds those binary packages:

fonts-myanmar - ttf myanmar fonts:
 fonts-myanmar-angoun - myanmar fonts: angoun;
 fonts-myanmar-ayar - ttf myanmar fonts: ayar;
 fonts-myanmar-chatu - myanmar fonts: chatu;
 fonts-myanmar-chatulight - myanmar fonts: chatulight;
 fonts-myanmar-gantgaw - myanmar fonts: gantgaw;
 fonts-myanmar-khyay - myanmar fonts: khyay;
 fonts-myanmar-kuttar - myanmar fonts: kuttar;
 fonts-myanmar-myanmar3 - ttf myanmar fonts: Myanmar3;
 fonts-myanmar-myanmarcensus - ttf myanmar fonts: MyanmarCensus;
 fonts-myanmar-nayone - myanmar fonts: nayone;
 fonts-myanmar-njaun - myanmar fonts: njaun;
 fonts-myanmar-pauklay - myanmar fonts: pauklay;
 fonts-myanmar-phetsot - myanmar fonts: phetsot;
 fonts-myanmar-phiksel - myanmar fonts: phiksel;
 fonts-myanmar-phikselsmooth - myanmar fonts: phikselsmooth;
 fonts-myanmar-ponenyet - myanmar fonts: ponenyet;
 fonts-myanmar-pyidaungsu - ttf myanmar fonts: Pyidaungsu;
 fonts-myanmar-sabae - myanmar fonts: sabae;
 fonts-myanmar-sagar - myanmar fonts: sagar;
 fonts-myanmar-sanpya - myanmar fonts: sanpya;
 fonts-myanmar-squarelight - myanmar fonts: squarelight;
 fonts-myanmar-tagu - myanmar fonts: tagu;
 fonts-myanmar-thuriya - myanmar fonts: thuriya;
 fonts-myanmar-unicode - ttf myanmar unicode fonts
 fonts-myanmar-waso - myanmar fonts: waso;
 fonts-myanmar-yinmar - myanmar fonts: yinmar;
 fonts-myanmar-zawgyi - ttf myanmar fonts: ZawgyiOne2008;

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

  https://mentors.debian.net/package/fonts-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_1.0-1.dsc

  More information about fonts-myanmar can be obtained from 
https://www.ubuntu-mm.net and launchpad.net/ttf-burmese-fonts

with regards with SC DFSG

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

Kernel: Linux 4.15.0-21-generic (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)
LSM: AppArmor: enabled

Bug#898092: sddm: takes extremely long time to start

[Leandro Doctors]

Package: sddm
Version: 0.17.0-1
Severity: important

Dear Maintainer,

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

* What led up to the situation?

Intalling Plasma Desktop after having problems with several GTK-based
Desktop Environments (may fill bug on that once this one is solved).

* What exactly did you do (or not do) that was effective (or
  ineffective)?

For now, just started to do some debugging... (I copy the output of
relevant systemd-related commands below.)

It looks as if the program was spending those three minutes trying to find
something else, and it starts only after that time.


* What was the outcome of this action?

SSDM takes three (3!) minutes to initialize.


* What outcome did you expect instead?

SSDM to take a couple of seconds to initialize.


Here is the output of relevant systemd-related commands


  * The service seems to be OK...

root@berlin:/home/allentiak# systemctl status sddm.service
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/lib/systemd/system/sddm.service; indirect; vendor
preset: enabled)
Active: active (running) since Sun 2018-05-06 23:33:07 -03; 8min ago
  Docs: man:sddm(1)
man:sddm.conf(5)
  Main PID: 685 (sddm)
 Tasks: 4 (limit: 4915)
Memory: 199.6M
CGroup: /system.slice/sddm.service
├─685 /usr/bin/sddm
└─783 /usr/lib/xorg/Xorg -nolisten tcp -auth
/var/run/sddm/{60ab4bb8-66a7-463a-a7cf-3241d7bd2e6c} -back

May 06 23:39:16 berlin sddm-helper[1031]: [PAM] returning.
May 06 23:39:16 berlin sddm[685]: Authenticated successfully
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
May 06 23:39:16 berlin sddm-helper[1031]: pam_unix(sddm:session): session
opened for user allentiak by (uid=0)
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:session):
pam_kwallet5: pam_sm_open_session
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:session):
pam_kwallet5: final socket path: /run/user/1
May 06 23:39:16 berlin sddm-helper[1031]: Starting: "/etc/sddm/Xsession
\"/usr/bin/startkde\""
May 06 23:39:16 berlin sddm[685]: Session started
May 06 23:39:16 berlin sddm[685]: Auth: sddm-helper exited successfully
May 06 23:39:16 berlin sddm[685]: Greeter stopped.


  * ...But it took it (3 minutes!) to start.


root@berlin:/home/allentiak# journalctl -rx --unit=sddm.service
-- Logs begin at Sun 2018-05-06 23:33:05 -03, end at Sun 2018-05-06
23:41:05 -03. --
May 06 23:39:16 berlin sddm[685]: Greeter stopped.
May 06 23:39:16 berlin sddm[685]: Auth: sddm-helper exited successfully
May 06 23:39:16 berlin sddm[685]: Session started
May 06 23:39:16 berlin sddm-helper[1031]: Starting: "/etc/sddm/Xsession
\"/usr/bin/startkde\""
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:session):
pam_kwallet5: final socket path: /run/user/1
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:session):
pam_kwallet5: pam_sm_open_session
May 06 23:39:16 berlin sddm-helper[1031]: pam_unix(sddm:session): session
opened for user allentiak by (uid=0)
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
May 06 23:39:16 berlin sddm[685]: Authenticated successfully
May 06 23:39:16 berlin sddm-helper[1031]: [PAM] returning.
May 06 23:39:16 berlin sddm-helper[1031]: pam_kwallet5(sddm:auth): (null):
pam_sm_authenticate
May 06 23:39:16 berlin sddm-helper[1031]: [PAM] Conversation with 1 messages
May 06 23:39:16 berlin sddm-helper[1031]: [PAM] Preparing to converse...
May 06 23:39:16 berlin sddm-helper[1031]: [PAM] Authenticating...
May 06 23:39:16 berlin sddm-helper[1031]: [PAM] Starting...
May 06 23:39:16 berlin sddm[685]: Session
"/usr/share/xsessions/plasma.desktop" selected, command: "/usr/bin/start
May 06 23:39:16 berlin sddm[685]: Reading from
"/usr/share/xsessions/plasma.desktop"
May 06 23:39:16 berlin sddm[685]: Reading from
"/usr/share/xsessions/plasma.desktop"

* look here

May 06 23:39:16 berlin sddm[685]: Message received from greeter: Login
May 06 23:36:52 berlin sddm[685]: Message received from greeter: Connect
May 06 23:36:52 berlin sddm[685]: Greeter session started successfully
May 06 23:36:52 berlin sddm-helper[792]: pam_unix(sddm-greeter:session):
session opened for user sddm by (uid=0)
May 06 23:36:52 berlin sddm-helper[792]: [PAM] returning.
May 06 23:36:52 berlin sddm-helper[792]: [PAM] Authenticating...
May 06 23:36:52 berlin sddm-helper[792]: [PAM] Starting...



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

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 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 sddm depends on:
ii  adduser   

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

[Russ Allbery]

Benjamin Kaduk  writes:
> On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:

>> This seems trivial enough that the krb5-kdc package could just ship
>> this service for now and gauge interest.  I think all you'd need is a
>> program that called getrandom() and then exited when it returned, run
>> via systemd as a Type=oneshot service that krb5-kdc depends on and with
>> a reasonable timeout.

> I think that's what it would look like, yes.  It's less clear that
> putting it in krb5-kdc would actually do anything to gauge demand,
> but I suppose I could be wrong.

Yeah, that was probably the wrong phrasing.  Proof of concept?  To be
usable by any other package, it would have to be a separate package, so it
would be more of an immediate workaround.  It would at least demonstrate
whether this solution works, which is a good basis to talk to the systemd
maintainers (either in Debian or upstream).

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

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

[Chris Lamb]

clone 884499 -1
retitle -1 lintian: Alter the semantics (etc.) of --pedantic?
severity -1 wishlist
tags -1 + moreinfo
thanks

Hi Russ 

> […]

At the very least lets not lose this conversation in a somewhat-
unrelated bug, hence cloning etc. Tagging as "moreinfo" for now.

> lintian --suggestions, maybe?

Well, I was trying to avoid the early bikeshedding on the name, more
trying to capture the different essence. :)


Best wishes,

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

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

[Ben Caradoc-Davies]

This reverts commit 43838a23a05f ("random: fix crng_ready() test"),
which causes urandom to hang in early boot even when crng_init==1.

One impact of this hang is that it prevents display of the plymouth
graphical passphrase prompt required to proceed with boot. In the
absence of sources of entropy (such as a wired network adapter?), the
hang is indefinite. User workarounds are to generate entropy with key
presses or mouse motion, or to disable the plymouth graphical
passphrase prompt by removing "splash" from the kernel command line.

See:

urandom hang in early boot prevents plymouth passphrase entry
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Signed-off-by: Ben Caradoc-Davies 
---
 drivers/char/random.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..cae3249ecdef 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -428,7 +428,7 @@ struct crng_state primary_crng = {
  * its value (from 0->1->2).
  */
 static int crng_init = 0;
-#define crng_ready() (likely(crng_init > 1))
+#define crng_ready() (likely(crng_init > 0))
 static int crng_init_cnt = 0;
 static unsigned long crng_global_init_time = 0;
 #define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)
@@ -843,7 +843,7 @@ static int crng_fast_load(const char *cp, size_t len)
 
if (!spin_trylock_irqsave(_crng.lock, flags))
return 0;
-   if (crng_init != 0) {
+   if (crng_ready()) {
spin_unlock_irqrestore(_crng.lock, flags);
return 0;
}
@@ -963,7 +963,7 @@ static void _extract_crng(struct crng_state *crng,
 {
unsigned long v, flags;
 
-   if (crng_ready() &&
+   if (crng_init > 1 &&
(time_after(crng_global_init_time, crng->init_time) ||
 time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL)))
crng_reseed(crng, crng == _crng ? _pool : NULL);
@@ -1245,7 +1245,7 @@ void add_interrupt_randomness(int irq, int irq_flags)
fast_mix(fast_pool);
add_interrupt_bench(cycles);
 
-   if (unlikely(crng_init == 0)) {
+   if (!crng_ready()) {
if ((fast_pool->count >= 64) &&
crng_fast_load((char *) fast_pool->pool,
   sizeof(fast_pool->pool))) {
@@ -2314,7 +2314,7 @@ void add_hwgenerator_randomness(const char *buffer, 
size_t count,
 {
struct entropy_store *poolp = _pool;
 
-   if (unlikely(crng_init == 0)) {
+   if (!crng_ready()) {
crng_fast_load(buffer, count);
return;
}
-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

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

[Benjamin Kaduk]

On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:
> Benjamin Kaduk  writes:
> > On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> >> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> 
> >>> Arguably more preferable would be to have a systemd target that
> >>> indicates the RNG is seeded, and then krb5 could have its KDC service
> >>> depend on this "RNG-available" service.  So far as I know, no such
> >>> service currently exists, so again, there would need to be some
> >>> sytsemd effort (potentially in cooperation with the kernel) to provide
> >>> such a service.
> 
> >> Yes, that certainly seems like a good approach.
> 
> > Do you know who would be the right person to talk to about getting
> > that work done?
> 
> This seems trivial enough that the krb5-kdc package could just ship this
> service for now and gauge interest.  I think all you'd need is a program
> that called getrandom() and then exited when it returned, run via systemd
> as a Type=oneshot service that krb5-kdc depends on and with a reasonable
> timeout.

I think that's what it would look like, yes.  It's less clear that
putting it in krb5-kdc would actually do anything to gauge demand,
but I suppose I could be wrong.

-Ben

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

[Russ Allbery]

Benjamin Kaduk  writes:
> On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
>> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:

>>> Arguably more preferable would be to have a systemd target that
>>> indicates the RNG is seeded, and then krb5 could have its KDC service
>>> depend on this "RNG-available" service.  So far as I know, no such
>>> service currently exists, so again, there would need to be some
>>> sytsemd effort (potentially in cooperation with the kernel) to provide
>>> such a service.

>> Yes, that certainly seems like a good approach.

> Do you know who would be the right person to talk to about getting
> that work done?

This seems trivial enough that the krb5-kdc package could just ship this
service for now and gauge interest.  I think all you'd need is a program
that called getrandom() and then exited when it returned, run via systemd
as a Type=oneshot service that krb5-kdc depends on and with a reasonable
timeout.

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

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

[Ben Caradoc-Davies]

On 07/05/18 12:38, Ben Caradoc-Davies wrote:

I am testing a more localised fix that should be more palatable to upstream.


My more localised fix did not work. I think the use of crng_ready() in 
urandom_read only affects the logging of a warning message. The change 
that causes the read to block is deeper in the stack.


Kind regards,

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

Bug#898038: caused by host

[Trent Lloyd]

I have been tracking this issue in Ubuntu at: 
https://bugs.launchpad.net/bugs/1752411


The root cause of this issue is a bug in 'host', in certain 
circumstances the host command hangs and never returns. I can reproduce 
this reliably.
The main case I have found is when an interface is up, but the link is 
still down and a default route is installed in the state 'linkdown'.  
This only happens if that is the route used to send packets to a 
nameserver listed in resolv.conf


I haven't yet managed to debug what causes host to fail internally and 
never timeout in this case, but a workaround is to modify 
avahi-daemon-check-dns.sh to launch host under the 'timeout' command 
with a 5 second timeout to ensure it doesn't block forever.


The real issue in host needs to be fixed, though, I have a machine that 
reproduces this issue reliably if anyone is experience in bind9-host 
debugging and I can reproduce it on demand.


- Trent

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

[Russ Allbery]

Chris Lamb  writes:

> Y'know, I think we could make it even more effective if we renamed --
> pedantic at the same time. This would have the benefits of a)
> highlighting the change of semantics and b) we could perhaps choose a
> name that does not imply it is "just" another level of pickiness…
> Almost to the point of "lintian --give-me-possible-things-to-consider"

Yeah, I was cringing over the break in backward-compatibility in my
original proposal, so I think something like this plus a deprecation
warning on --pedantic while making it do nothing would be friendlier.

lintian --suggestions, maybe?

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

Bug#898017: ncurses abi change.

[peter green]

On 06/05/18 01:05, peter green wrote:

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.

Ok, it appears I was a little mistaken, I thought the freepascal IDE uses 
ncurses but it seems it does not.

I got an answer from the ncurses maintainer with more details on the ABI change 
and even a patch. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894049#39

So afaict what we need to do is.

1. Apply svens patch
2. Add breaks ( libncursesw5-dev << 6.1+20180210 ) to fp-units-base-
3. Figure out if any pascal packages in debian use ncurses and if-so request 
binnmus with the patched fpc.

Does this sound right to everyone?

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

[Benjamin Kaduk]

On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> > Hi Ben,
> > 
> > On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> > > I've cloned this bug as #898073 and reassigned that to krb5.
> > > 
> > > krb5 is using the new(ish) getrandom() system call to read random bits,
> > > with the code comment "This ensures strong randomness while only
> > > blocking during first system boot."
> > > 
> > > While this is a regression, the kernel is only doing what krb5 was
> > > asking for (whereas previously it could wrongly provide weak random
> > > bits).
> > > 
> > > We might still revert this change in the kernel temporarily.  However,
> > > the krb5 developers need to decide what they really want, and if that's
> > > strong randomness then they need to configure the service to allow for
> > > a longer delay at boot.
> > 
> > I read through the history on #898073 and am still not sure I have
> > the backstory quite right.  This is what it sounds like has
> > happened:
> > 
> > The kernel in stable has for some time provided a getrandom() system
> > call that provided "weak" (more on this later) random numbers for
> > some time after startup, though did eventually converge to "strong"
> > randomness after some time (a few minutes?).  The kernel 4.9.88-1
> > upload fixed the bug that getrandom() could provide "weak" output
> > (since getrandom() is supposed to block until strong output is
> > ready), and this in turn caused the krb5 KDC to block at boot until
> > the RNG was ready, blocking long enough that systemd timed out the
> > unit and marked it as failed.  We're now talking about the proper
> > way to improve the situation.
> 
> Right.
> 
> > If the above is correct, I'm not yet sure that I see a krb5-specific
> > bug.  It is definitely true that krb5 is specifically requesting the
> > getrandom() semantics of blocking until the RNG is fully seeded, but
> > krb5 is hardly expected to be the only consumer of getrandom().  As
> > such, why should krb5 be responsible for increasing the systemd
> > timeout at boot -- could not systemd be responsible for increasing
> > the default timeout to allow for entropy seeding as used by multiple
> > applications?
> 
> How would systemd determine which systems require this?

I didn't have anything in mind other than globally increasing the
default timeout.

> > Arguably more preferable would be to have a systemd
> > target that indicates the RNG is seeded, and then krb5 could have
> > its KDC service depend on this "RNG-available" service.  So far as I
> > know, no such service currently exists, so again, there would need
> > to be some sytsemd effort (potentially in cooperation with the
> > kernel) to provide such a service.
> 
> Yes, that certainly seems like a good approach.

Do you know who would be the right person to talk to about getting
that work done?

> > To rephrase in a different way, "getrandom() is a system service,
> > and the system's init system should not penalize other services for
> > using system services -- why should the onus of adapting be placed on
> > individual consumers of that system service?"
> > 
> > 
> > Back to the "weak" random numbers.  How weak are we talking about?
> 
> If I'm reading the code correctly, the previous condition for
> successful return of getrandom() (without the GRND_RANDOM flag) was
> that at least 64 bits of raw random data have been added to the random
> pool.  The raw random data might come from a high quality hardware
> random number generator but might be much weaker.  The current
> condition is that at least 128 bits of entropy have been added (based
> on a conservative estimate of entropy).

Thanks for sharing your interpretation.  Hmm, 64 bits is not very
much (e.g., 64^W56-bit single-DES keys are brute-forceable at
relatively low cost, these days), though I don't have a sense for
what the weakest source that could be used is.  It's of course not
just as simple as the first 64 bits, since other input is
continually added, but it sounds like there is some
larger-than-normal-security-margin chance that an attacker could
reproduce a key that was generated on a user system.  It sounds like
we should try to get some additional eyes on this.

> > The krb5 KDC and kadmind are used (among other things) to generate
> > shared symmetric keys, used to encrypt and authenticate traffic over
> > the network.  Some of these keys are long-lived, and an
> > insufficiently random long-lived key could have rather disasterous
> > consequences for deployments unlucky enough to have generated them.
> > Are we looking at a repeat of the openssl RNG fiasco where piles of
> > ssh keys and TLS certificates had to be regenerated?  If there's a
> > real issue here of weak randomness, we may need to publicize this
> > issue much more widely.
> 
> The real issue is that k5_get_os_entropy() silently falls back to
> reading /dev/urandom, which has never, and 

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

[Chris Lamb]

Hi Russ,

> My modest proposal, and this is going to sound nuts so bear with me for a
> moment, would be to make it impossible to get pedantic tags and regular
> tags at the same time.  If you use --pedantic, suppress all other tags.

Ooh, now that's an interesting concept. :) Let me run that over in my
mind for a few days..

Y'know, I think we could make it even more effective if we renamed --
pedantic at the same time. This would have the benefits of a)
highlighting the change of semantics and b) we could perhaps choose a
name that does not imply it is "just" another level of pickiness…
Almost to the point of "lintian --give-me-possible-things-to-consider"


Best wishes,

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

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Norbert Preining]

Hi all,

I did the following:

tex.man:
added to the ENVIRONMENT section:
+.P
+Notes for Debian developers: please keep in mind, that this version of
+the \*(TX interpreter ignores the
+.B SOURCE_DATE_EPOCH
+variable. Instead the current timestamp is written into the
+.I DVI
+file. If you need a reproducible time stamp, please use any engine based
+on pdf\*(TX, e.g., etex, pdftex, latex, pdflatex.


etex.man:
added to the ENVIRONMENT section:
+.TP
+.B SOURCE_DATE_EPOCH
+If set, its value, taken to be in epoch-seconds, will be used for the
+timestamps in the PDF output, such as the CreationDate and ModDate keys.
+This is useful for making reproducible builds.
+.TP
+.B FORCE_SOURCE_DATE
+If set to the value "1", the time-related \*(TX primitives
+.RI ( \eyear ,
+.IR \emonth ,
+.IR \eday ,
+.IR \etime )
+are also initialized from the value of SOURCE_DATE_EPOCH.  This is not
+recommended if there is any viable alternative.


Hope that is fine with you

Norbert

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

Bug#897554: maint-guide: FTBFS: dh_install: missing files, aborting

[Boyuan Yang]

在 2018年5月7日星期一 CST 上午12:44:19，Osamu Aoki 写道：
> Hi Boyuan Yang,
> 
> On Wed, May 02, 2018 at 10:59:48PM +0200, Lucas Nussbaum wrote:
> > Source: maint-guide
> > Version: 1.2.40
> > Severity: serious
> > Tags: buster sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20180502 qa-ftbfs
> > Justification: FTBFS on amd64
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> > 
> > Relevant part (hopefully):
> > >  fakeroot debian/rules binary
> > > 
> > > dh  binary
> > > 
> > >dh_testroot
> > >dh_prep
> > >dh_auto_install
> > >dh_install
> > > 
> > > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-cn.pdf"
> > > (tried in ., debian/tmp)
> > > 
> > > dh_install: maint-guide-zh-cn missing files: tmp/maint-guide.zh-cn.pdf
> > > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-tw.pdf"
> > > (tried in ., debian/tmp)
> > > 
> > > dh_install: maint-guide-zh-tw missing files: tmp/maint-guide.zh-tw.pdf
> > > dh_install: missing files, aborting
> > > make: *** [debian/rules:35: binary] Error 25
> > 
> > The full build log is available from:
> >http://aws-logs.debian.net/2018/05/02/maint-guide_1.2.40_unstable.log
> > 
> > A list of current common problems and possible solutions is available at
> > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> > 
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> 
> Can you look into this problem?  Is this tool chain problem or missiong
> dependency package?
> 
> I thought you enabled zh-* build since tool chain is now ready...
> 
> Regards,
> 
> Osamu

I didn't touch maint-guide recently; I was previously fixing the build problem 
of debian-reference.

There were several mails regarding zh-* problem in maint-guide (written by 
others), mainly about backquote character (`). I didn't follow them but those 
mails seem to have pointed out the cause of the build failure. Will dig into 
it later.

--
Regards,
Boyuan Yang

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

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

[Scott Kitterman]

On May 7, 2018 1:26:36 AM UTC, Russ Allbery  wrote:
>Chris Lamb  writes:
>
>> However, my experience with being an author of a handful of static
>> analysis tools is that people have a slight tendency to delegate
>> thinking to the computer's output. The addition of an objective
>target
>> (ie. zero output) only encourages our post-lapsarian brains to make
>> poor, err, compromises.
>
>> Do correct me if I'm wrong, but I believe this is the angle Scott was
>> pushing. :)
>
>> How could we make --pedantic more useful/obvious/something? 
>Ironically,
>> if it were less useful in a strict sense — for example, if we moved
>some
>> P: tags to I: — it would get less incorrect usage. :p
>
>My modest proposal, and this is going to sound nuts so bear with me for
>a
>moment, would be to make it impossible to get pedantic tags and regular
>tags at the same time.  If you use --pedantic, suppress all other tags.
>
>This problem stems from the fact that people are using Lintian as if
>pickier is better, and the deeper they go into Lintian's settings while
>keeping the package clear of any output, the better the package is. 
>And
>that's true, up to a point -- moving from error to warning is certainly
>significant, and moving from warning to info is probably significant.
>
>But pedantic was a collection of tags that were mostly designed for a
>far
>different purpose: you run them on a package to ask for a set of things
>that might be out of step with common best practices or that you may
>want
>to consider changing if you've not touched the package in years.  It's
>much more of a one-time thing.  You run it, you look at the tags and
>read
>the descriptions (I would argue that --pedantic is basically useless
>without --info, and perhaps --pedantic should force --info,
>particularly
>if one implements my modest proposal), you decide which ones make sense
>and which ones don't, and then you fix the ones you like and move on
>with
>your life.
>
>Lintian has emitted pedantic warnings about some of my packages for not
>having an upstream changelog for literally years.  This is never going
>to
>be fixed; upstream is not going to make a changelog, and I'm not going
>to
>make an artificial one.  The correct disposition of that tag is for me
>to
>ignore it completely, *but it's still useful* for new packages when I'm
>doing initial packaging and may have forgotten to include the right
>debhelper command to copy over upstream's unconventionally-named
>changelog.
>
>If we *force* people to not treat --pedantic the same as other severity
>levels and *force* it to be a separate pass that you only run in
>specific
>situations, maybe this will finally get through to people, since
>arguing
>with people in debian-mentors that they're using Lintian wrong doesn't
>seem to be working.

I think this is an excellent idea.

Thanks,

Scott K

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

[Russ Allbery]

Chris Lamb  writes:

> However, my experience with being an author of a handful of static
> analysis tools is that people have a slight tendency to delegate
> thinking to the computer's output. The addition of an objective target
> (ie. zero output) only encourages our post-lapsarian brains to make
> poor, err, compromises.

> Do correct me if I'm wrong, but I believe this is the angle Scott was
> pushing. :)

> How could we make --pedantic more useful/obvious/something?  Ironically,
> if it were less useful in a strict sense — for example, if we moved some
> P: tags to I: — it would get less incorrect usage. :p

My modest proposal, and this is going to sound nuts so bear with me for a
moment, would be to make it impossible to get pedantic tags and regular
tags at the same time.  If you use --pedantic, suppress all other tags.

This problem stems from the fact that people are using Lintian as if
pickier is better, and the deeper they go into Lintian's settings while
keeping the package clear of any output, the better the package is.  And
that's true, up to a point -- moving from error to warning is certainly
significant, and moving from warning to info is probably significant.

But pedantic was a collection of tags that were mostly designed for a far
different purpose: you run them on a package to ask for a set of things
that might be out of step with common best practices or that you may want
to consider changing if you've not touched the package in years.  It's
much more of a one-time thing.  You run it, you look at the tags and read
the descriptions (I would argue that --pedantic is basically useless
without --info, and perhaps --pedantic should force --info, particularly
if one implements my modest proposal), you decide which ones make sense
and which ones don't, and then you fix the ones you like and move on with
your life.

Lintian has emitted pedantic warnings about some of my packages for not
having an upstream changelog for literally years.  This is never going to
be fixed; upstream is not going to make a changelog, and I'm not going to
make an artificial one.  The correct disposition of that tag is for me to
ignore it completely, *but it's still useful* for new packages when I'm
doing initial packaging and may have forgotten to include the right
debhelper command to copy over upstream's unconventionally-named
changelog.

If we *force* people to not treat --pedantic the same as other severity
levels and *force* it to be a separate pass that you only run in specific
situations, maybe this will finally get through to people, since arguing
with people in debian-mentors that they're using Lintian wrong doesn't
seem to be working.

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

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

[Chris Lamb]

Hi Russ & Scott,

> I'm not sure how one could possibly be more clear.  If one's definition of
> lintian-clean includes --pedantic, one's definition of lintian-clean is,
> well, wrong.

There is no doubt that you are absolutely right in a technical sense
and maintainers should not be using --pedantic in this way.

However, my experience with being an author of a handful of static
analysis tools is that people have a slight tendency to delegate
thinking to the computer's output. The addition of an objective
target (ie. zero output) only encourages our post-lapsarian brains to
make poor, err, compromises.

Do correct me if I'm wrong, but I believe this is the angle Scott was
pushing. :)

How could we make --pedantic more useful/obvious/something?
Ironically, if it were less useful in a strict sense — for example,
if we moved some P: tags to I: — it would get less incorrect usage. :p


Best wishes,

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

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

[Russ Allbery]

Scott Kitterman  writes:

> Back in the debate about the python2 check (thanks for fixing), I made
> the point that not all lintian checks are created equal.  Some represent
> serious package defects that needs to be addressed and some merely
> reflect the lintian maintainer's opinion on what should be tracked and
> it's entirely up to the maintainer to decide if any action is needed.

> This is one of the latter.

Which is why it's pedantic, no?  Speaking as the person who merged
Raphael's patch to introduce pedantic, that's precisely what pedantic
*means*.

> I worry about this class of tag because some people view a lintian
> 'clean' package as an important goal when it's not universally.  One
> needs to look at what lintian is reporting and evaluate it.  Not
> everyone does a great job of that and so unintended consequences arise.

In the lintian man page:

Pedantic tags are Lintian at its most pickiest and include checks for
particular Debian packaging styles and checks that many people
disagree with.  Expect false positives and Lintian tags that you don't
consider useful if you use this option.

I'm not sure how one could possibly be more clear.  If one's definition of
lintian-clean includes --pedantic, one's definition of lintian-clean is,
well, wrong.

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

Bug#898090: apt-show-sversions: Unable to install apt-show-versions

[Hugh B.]

Package: apt-show-sversions
Version: apt-show-versions
Severity: normal
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation? Unknown.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? tried uninstalling, reinstalling, purging, upgrading
 perl version.
   * What was the outcome of this action? No change, the package still
   * fails to install.
   * What outcome did you expect instead? Install succesfull.

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


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

Kernel: Linux 4.9.0-5-amd64 (SMP w/48 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)

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

[Ben Caradoc-Davies]

Ben,

even though X is not involved, you are right on the money about this 
being caused by waiting for random bits. This is a kernel bug caused by 
urandom blocking when it should not. I will merge the issues when I have 
my final patch ready.


You can see the "random: plymouthd: uninitialized urandom read" warning 
in my screen photo:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=897572;filename=img_20180504_120059.jpg;msg=37

This bug is introduced by the "crng_init > 0" to "crng_init > 1" change 
in this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33

This change inadvertently impacts urandom_read, causing the crng_init==1 
state to be treated as uninitialized and causing urandom to block, 
despite this state existing *specifically* to support non-cryptographic 
needs at boot time:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1863

Reverting 43838a23a05f ("random: fix crng_ready() test") fixes the bug 
(tested with 4.16.5-1), but this may cause security concerns 
(CVE-2018-1108 is mentioned in 43838a23a05f). I am testing a more 
localised fix that should be more palatable to upstream.


Kind regards,

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

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

[Scott Kitterman]

On May 7, 2018 12:20:04 AM UTC, Chris Lamb  wrote:
>Hi Scott,
>
>> For what it's worth, this is an example of the kind of check that
>isn't 
>> supported by policy.
>
>I'm not quite following your chain of logic wrt to Lintian and Debian
>Policy. I mean, there are countless checks in Lintian that have no
>basis in Policy? :)
>
>(100% agree that there is no requirement whatsoever to use debhelper
>or CDBS and I have a great deal of sympatahy with you position on
>this tag. Indeed, I can quite possibly see myself removing this tag
>at a later date.)

Back in the debate about the python2 check (thanks for fixing), I made the 
point that not all lintian checks are created equal.  Some represent serious 
package defects that needs to be addressed and some merely reflect the lintian 
maintainer's opinion on what should be tracked and it's entirely up to the 
maintainer to decide if any action is needed.

This is one of the latter.  I worry about this class of tag because some people 
view a lintian 'clean' package as an important goal when it's not universally.  
One needs to look at what lintian is reporting and evaluate it.  Not everyone 
does a great job of that and so unintended consequences arise.

Scott K

Bug#896684: fontconfig-config: Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf, due to many errors

[Vincent Lefevre]

On 2018-05-06 21:56:07 +0200, Julian Raisch wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=105818
> https://bugs.chromium.org/p/chromium/issues/detail?id=829890
> 
> Seems to be a Chromium bug. It has its own outdated version of fontconfig.

I don't use Chromium. It isn't even installed on my machines.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#892307: fixed in bash-completion 1:2.8-1

[Paul Wise]

On Sun, 2018-05-06 at 16:16 -0300, Gabriel F. T. Gomes wrote:

> I can definitely send this upstream, but since you have already
> provided the solution in the bug report, may I set the author name to
> "Paul Wise " in the patch (git commit)?

That is fine by me.

I think single-letter options are more likely to function differently
between man implementations than long options, so long ones are better.

I noticed in the Debian manual page for man that there are actually
four options that can be used for printing the manual page path:

-w --where --path --location

I'm assuming these are compatibility options for other operating
systems. I'd suggest that before committing, you go through each of the
Linux man implementations (at least Debian, Fedora, Gentoo), each of
the open source BSD ones and the ones for proprietary UNIXen like
macOS, Solaris, HPUX. Then order the solutions by how common they are.

I wonder if any man implementations actually have a way to do
completion without the shell parts having to do the completion.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[Chris Lamb]

Hi Scott,

> For what it's worth, this is an example of the kind of check that isn't 
> supported by policy.

I'm not quite following your chain of logic wrt to Lintian and Debian
Policy. I mean, there are countless checks in Lintian that have no
basis in Policy? :)

(100% agree that there is no requirement whatsoever to use debhelper
or CDBS and I have a great deal of sympatahy with you position on
this tag. Indeed, I can quite possibly see myself removing this tag
at a later date.)


Regards,

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

Bug#898089: Query by submitter fails with "Internal Server Error"

[Ben Hutchings]

Package: bugs.debian.org
Severity: normal

I can't view my submitted bug reports:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=b...@decadent.org.uk

After a few seconds a generic "Internal Server Error" message appears.

Ben.

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

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

Bug#898088: arc4random_buf() may block for a long time

[Ben Hutchings]

On Mon, 2018-05-07 at 01:04 +0100, Ben Hutchings wrote:
[...]
> But the fix for this means that getrandom() and arc4random_buf() may
> block until a minute or even longer after boot.  Since
> gnome-session-binary calls arc4random_buf() via
> IceGenerateMagicCookie(), fixing the kernel causes a "blank screen"
> regression for some systems.
[...]

See bug #897632 for an example.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon


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

Bug#898088: arc4random_buf() may block for a long time

[Ben Hutchings]

Source: libbsd
Version: 0.8.7-1
Severity: serious
Tags: upstream

The manual page for arc4random_buf() says "High quality 32-bit
pseudo-random numbers are generated very quickly."  This promise is
false, and it can never be true in general!

On recent Linux kernel versions arc4random_buf() uses the getrandom()
system call where available.  getrandom() is documented to block
(or return an error, depending on the flags parameter) when
the kernel's RNG does not have enough entropy available.  It was
recently found that the RNG was unblocking getrandom() too early
(CVE-2018-1108).

But the fix for this means that getrandom() and arc4random_buf() may
block until a minute or even longer after boot.  Since
gnome-session-binary calls arc4random_buf() via
IceGenerateMagicCookie(), fixing the kernel causes a "blank screen"
regression for some systems.

I don't know quite how we're going to solve this, but at the very
least the manual page for arc4random_buf() must clarify whether it
is intended to provide high quality, or non-blocking, behaviour.

Ben.

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

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

Bug#897631: Kernel update breaks GDM

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 03 May 2018 18:59:36 +0200 silvio.s...@gmail.com wrote:
[...]
> However soon after logging in (usually by the time I had written a
> couple of commands) GDM would start and I could then log in from the
> GUI and from then on everything would work just fine. GDM would however
> not start if I didn't log in from the command line, instead the system
> would just hang indefinetly (I actually left it on for about 30 min
> while going on lunch).
[...]

This may sound like a silly request, but does GDM start up if you
wiggle the mouse for a few seconds?

Ben.
 
-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

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

[Ben Hutchings]

On Sun, 2018-05-06 at 20:43 +0100, Ben Hutchings wrote:
> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
[...]
> > If the above is correct, I'm not yet sure that I see a krb5-specific
> > bug.  It is definitely true that krb5 is specifically requesting the
> > getrandom() semantics of blocking until the RNG is fully seeded, but
> > krb5 is hardly expected to be the only consumer of getrandom().  As
> > such, why should krb5 be responsible for increasing the systemd
> > timeout at boot -- could not systemd be responsible for increasing
> > the default timeout to allow for entropy seeding as used by multiple
> > applications?
> 
> How would systemd determine which systems require this?
[...]

I meant, which services.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#898087: linux debian.py change breaks "+" in changelog revision_other

[Ben Caradoc-Davies]

Package: linux-image-amd64
Version: 4.16+93
Severity: normal

Dear Maintainer,

until recent changes in debian/lib/python/debian_linux/debian.py,
changelog versions like 4.16.5-1+revert+crng+ready for local test
builds were accepted with "+" part as the revision_other Python
symbolic group name.

After this change:
https://salsa.debian.org/kernel-
team/linux/commit/f4dbf1aa828f18a7e3d9fd7158166b8cedbac0ce

I get:

$ fakeroot debian/rules clean
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
make[1]: Entering directory '/home/ben/tmp/debian/linux-4.16.5'
PYTHONHASHSEED=0 debian/bin/gencontrol.py
Traceback (most recent call last):
  File "debian/bin/gencontrol.py", line 601, in 
Gencontrol()()
  File "debian/bin/gencontrol.py", line 57, in __init__
VersionLinux)
  File "debian/lib/python/debian_linux/gencontrol.py", line 83, in __init__
self.changelog = Changelog(version=version)
  File "debian/lib/python/debian_linux/debian.py", line 60, in __init__
self._parse(version, f)
  File "debian/lib/python/debian_linux/debian.py", line 76, in _parse
v = version(top_match.group('version'))
  File "debian/lib/python/debian_linux/debian.py", line 196, in __init__
raise RuntimeError(u"Invalid debian linux version")
RuntimeError: Invalid debian linux version
make[1]: *** [debian/rules:104: debian/control-real] Error 1
make[1]: Leaving directory '/home/ben/tmp/debian/linux-4.16.5'
make: *** [debian/rules:95: debian/control] Error 2

Please either fix this change to support names like 4.16.5-1+revert+crng+ready
or recommend a naming convention for custom test builds.

Kind regards,
Ben.



-- 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/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.16.0-1-amd64  4.16.5-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

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

[Manuel A. Fernandez Montecelo]

2018-05-06 13:55 GMT+02:00 David Bremner :
> David Bremner  writes:
>
>> 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.
>>
>
> In the just uploaded 0.26.2-2, I've done that trimming, and marked gdb
> as , so it need not block bootstrapping efforts.

Ah, that's good, thanks.

I'll build it during this next week.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#898086: libequinox-osgi-java: Does not install symlinks into /usr/lib/eclipse/plugins

[Nick Morrott]

Source: libequinox-osgi-java
Version: 3.9.1-1
Severity: grave
Justification: renders package unusable
Control: affects eclipse

Dear Maintainer,

The separation of the libequinox-osgi-java binary package from the eclipse
source appears to break fresh installations of eclipse.

On a fresh installation of eclipse on buster/sid (using a supported JDK
version), it is apparent that eclipse is unable to locate
/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar (configured in
/usr/lib/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info).

On stretch (3.8.1-10), the relevant symlinks between
/usr/lib/eclipse/plugins and
/usr/share/java are present.

On buster/sid, no symlink is created to /usr/lib/eclipse/plugins,
which causes eclipse to immediately crash.

Manually installing the following symlink resolves the issue:

cd /usr/lib/eclipse/plugins
ln -s ../../../share/java/org.eclipse.osgi-3.9.1.jar
org.eclipse.osgi_3.8.1.dist.jar



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

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

Bug#898085: gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM

[Cyril Brulebois]

Package: gnupg
Version: 2.1.18-8~deb9u1
Severity: important

Hi,

Ever since the dist-upgrade to stretch (last september), I'm unable to
search keys, and parcimonie is failing on me:
| kibi@armor:~$ gpg --search-keys some@mail.address
| gpg: WARNING: Tor is not properly configured
| gpg: error searching keyserver: Permission denied
| gpg: keyserver search failed: Permission denied

and;
| Sleeping for 1 hour and 32 minutes...
| Fetching key ...
| Failed to fetch key : gpg:
| WARNING: Tor is not properly configured
| gpg: keyserver receive failed: Permission denied
|  at /usr/share/perl5/App/Parcimonie/Daemon.pm line 350.
| .
| Sleeping for 1 day and 4 minutes...

I've also had much troubles with caff but I don't have specific logs
handy any more; I just remember having trashed the whole .gnupg
directory and reinjected keys there, to be extra sure I had no specific
configuration files that might be getting in the way.

How come gpg fails this badly in stable, with a default configuration?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-8~deb9u1
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u2
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-8~deb9u1
ii  gnupg-l10n  2.1.18-8~deb9u1

Versions of packages gnupg suggests:
ii  parcimonie  0.10.2-4
pn  xloadimage  

-- no debconf information

Bug#898080: mpv: Segfault on any file

[James Cowgill]

Control: severity -1 grave

Hi,

On 06/05/18 21:48, Chiraag Nataraj wrote:
> Package: mpv
> Version: 0.28.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> Upon upgrading to mpv 0.28, mpv segfaults on any file I open. After 
> downgrading to 0.27, this was no longer an issue. I can provide strace output 
> if desired.

Yes I am aware of this. It happens because the ffmpeg 4.0 ABI is
different from the ffmpeg 3.5 ABI mpv 0.28 was originally built with.
Rebuilding mpv should fix it (after fixing the ffmpeg issues probably).

Jamea



signature.asc
Description: OpenPGP digital signature

Bug#898084: Please migrate to libsrtp2 in Buster

[Bernhard Schmidt]

Package: src:kopete
Version: 4:17.08.3-1
Severity: wishlist

Hi,

as already stated in #890606 we (pkg-voip-maintainers) would like to get rid of
libsrtp0 for Buster. librtp0 (src:srtp) has not been updated for five years.
The successor libsrtp2 has been released with Stretch and most users are
already converted. The remaining users except for Kopete are likely to be
dropped for Buster.

I haven't seen any upstream work on this and it seems to be entangled with the
mediastreamer2 FTBFS (also in libjingle). I'm filing this bug so we don't
forget about it.

Best Regards,
Bernhard

Bug#892539: pdftk: Depends on GCJ which is going away

[Emilio Pozuelo Monfort]

On Mon, 2 Apr 2018 19:12:01 +0200 Emilio Pozuelo Monfort  
wrote:
> On Wed, 21 Mar 2018 15:12:30 +0100 Petter Reinholdtsen  
> wrote:
> > I use pdftk regularly, and really hope we can manage to keep it in
> > Debian.
> > 
> > Is there a plan for adressing this before gcj is removed?
> 
> There's a fork that doesn't require GCJ as Adrian pointed out, you could help
> package that.

I did some work on this, there's a source and deb package prepared in

  https://people.debian.org/~pochu/pdftk/

This is based on upstream commit 121337af4464f3cb6b9acb3b2095d43d1453e05b.

Once installed, you can run pdftk as:

  java -jar /usr/share/pdftk/pdftk.jar

A wrapper script could be created and put into /usr/bin, or perhaps
there's a better way. I'm not very familiar with Java packages.

There's a problem though. If you run a more complex command it will
fail to find the dependencies. It's probably missing CLASSPATH, or
perhaps a dependency in the jar manifest file. Again, I'm not
familiar with this to know how to fix it:

  $ java -jar /usr/share/pdftk/pdftk.jar mypdf.pdf burst
  Unhandled Java Exception in create_output():
  java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringEscapeUtils
at report.OutputXmlString(Unknown Source)
at report.OutputPdfName(Unknown Source)
at report.ReportInfo(Unknown Source)
at report.ReportOnPdf(Unknown Source)
at TK_Session.create_output(Unknown Source)
at pdftk.main(Unknown Source)
  Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.lang3.StringEscapeUtils
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:190)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
... 6 more

Feel free to take this here, I won't do any more work on this package.
I will be removing pdftk from testing soon though, in order to finish
this GCJ removal transition. So if you or anyone cares about this
package, you may want to get it into shape and test this port and
upload it.

Cheers,
Emilio

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Bill Allombert]

On Fri, May 04, 2018 at 11:56:43PM +0900, Norbert Preining wrote:
> Hi Bill,
> 
> > > tex is tex as DEK wanted it. Please use etex, which is the pdftex binary
> > > producing dvi.
> 
> Well, tex the name has already a copyright that makes this necessary.
> 
> > Maybe this could be documented in the manpage ? There is already:
> 
> Any suggestion for a paragraph?

To start with etex man page could list SOURCE_DATE_EPOCH and
FORCE_SOURCE_DATE in the ENVIRONMENT section of the manpage
as pdftex does.

Secondly the tex manpage could give a nod to etex for users
with "special" requirement (I did not know about etex, there
are so many "extended tex" program.

Cheers,
Bill.

Bug#844297: vsftpd (3.0.2-17+deb8u1): no welcome message, problem in /etc/pam.d/vsftpd

[Keng-Yu Lin]

2016-11-14 16:51 GMT+08:00 Alexandre LE GALL :
> Subject: vsftpd (3.0.2-17+deb8u1): no welcome message, problem in 
> /etc/pam.d/vsftpd
> Package: vsftpd
> Version: 3.0.2-17+deb8u1
> Severity: important
>
> Dear Maintainer,
>
> Since I update vsftpd to 3.0.2-17+deb8u1, I can't connect to my ftp server.
> To fix this problem, I comment "@include common-auth " in /etc/pam.d/vsftpd.
>
> My server is a VM with samba (in domain) and vsftpd only.
>
> Thanks for your work.


I use 3.0.3-9 with ftpd_banner="FTP Server Ready" in /etc/vsftpd.conf.
I can't reproduce the issue:

ftp> open 192.168.1.10
Connected to 192.168.1.10.
220 "FTP Server Ready"
Name (192.168.1.10:kengyu):

Bug#898083: kdepim-addons: autopkgtest times out

[Paul Gevers]

Source: kdepim-addons
Version: 17.12.3-1
Severity: normal
User: debian...@lists.debian.org
Usertags: timeout

Since the upload of version 17.12.3-1 of kdepim-addons, the autopkgtest¹
are timing out (~ 3 hours) while previous runs tested in about 40
minutes (and failed). There is output to the log (copied below). Could
you please investigate how to get rid of the timeout? And please fix
your test to actually pass, but that is less important now.

I have blacklisted kdepim-addons for now.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

¹ https://ci.debian.net/packages/k/kdepim-addons/unstable/amd64/
² #debci on oftc or debian...@lists.debian.org

autopkgtest [17:40:53]: test testsuite: [---
Openbox-Message: Unable to find a valid menu file
"/var/lib/openbox/debian-menu.xml"
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 20147, result = 0
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit5: opened connection to :99
cd obj-x86_64-linux-gnu && make -j2 -Oline test ARGS\+=-j2
Running tests...
autopkgtest [20:27:34]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/build.6DT/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/build.6DT/src/debian/tests/testsuite;
touch /tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-stdout
/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-stderr;
/tmp/autopkgtest-lxc.rdb2i6d2/downtmp/build.6DT/src/debian/tests/testsuite
2> >(tee -a /tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.rdb2i6d2/downtmp/testsuite-stdout);"
(kind: test)
autopkgtest [20:27:34]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#898077: lintian: False positive in missing-build-dependency-for-dh-addon, python package

[Niels Thykier]

Chris Lamb:
> tags 898077 + pending
> thanks
> 
>> Lintian should perhaps check of there is a python package that meets the
>> dependency requirement? Or allow e.g. "*scour"?
> 
> We can't do a wildcard (!) but we can also check for
> python-scour. I've done this in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/fc69686ae2d6aff415762812e805af4e5e9ca627
> 
>   data/debhelper/dh_addons-manual | 1 +
>   debian/changelog| 4 
>   2 files changed, 5 insertions(+)
> 
> 
> Regards,
> 

Hi,

I am not entirely convinced this is a good idea.  As I understand it,
that dependency is a temporary measure to avoid breakage but the plan is
to remove the dependency (i.e. packages will be required to build-depend
directly on "scour" for the add-on).

I have taken the liberty of CC'ing Martin (maintainer of scour) to
clarify the situation.

Thanks,
~Niels

Bug#894865: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone

[Carlos Donizete Froes]

> Hi Carlos,

Hi Tobias, how are you? :)

> Some general remarks: Please do not open new RFS bugs for new versions
> of your package if the previous one has not been sponsored.
> Reopen the bug, retitle it appropiatly and send the RFS to the old bug
> please. (that this is something I've told you already earlier.)

I apologize again for my idiocy in mentors.d.n. :(

It will not be repeated in the next uploads.

> Now let's review cavestory-nx:

> Debian-Packaging:
> 
> - There is a wrapper script in /usr/share/games calling
>   /usr/share/games/cavestory-nx which is a symlink to
> ../../../lib/games/cavestory-nx/cavestory-nx
>   This feels quite wrong...

Removed the script and symbolic link from Debian-Packaging.

> - Can't the executable not installed to /usr/share/games/ directly?

Fixed the installed executable for /usr/share/games.

> - as you're upstream, please include the manpage also there, so that
>   other distributions will benefit from it more easily.

Moved manpage to directory "data".

> - you can also use the file d/clean for cleaning, sparing you of the
>   override of dh_auto_clean.

I made changes to file deletion in d/rules.

> - There seems to bean embedded code copy of nlohmann-json.
> - That means also that your d/copyright is incomplete.
>   Please make sure to go over _every_ file to ensure that d/copyright
>   is accurate. There are tools like licensecheck or license-reconsile
>   to aid you with this.

Added the JSON license in d/copyright. Thanks for the sugestion. :D

> Others / ITP related / Project related. 
> - there is a Readme.txt on the game assests stating that this is free
>   software but there is no license text attached. As "free" is ambiguous,
>   Can you please elaborate the source where you've got the data from?
>   I've only found some data file at the original authors website, but it
>   is lacking this Readme.txt. (I can't find the rationale why you say it
>   is Public Domain)

I added this readme.txt where copied the license comments in the official forum
of the game.

If there is no need to document this, I will remove it from the 'data' directory
and d/copyright.

> - as you've seem have to forked from nxegine-evo [1], can you go a bit
>   into the reasons of your fork. As far as I can see the changes are
>   minor, to the level of fixing spelling errors in comments and variable
>   names.
> 
> [1] https://github.com/nxengine/nxengine-evo

Yes, I made a fork with this engine where I made minor changes. I've already
mentioned this mechanism in this package.

> (I'm BCC'ing the ITP as the "Others" sections would actually belong
> there, but I do not want to join those threads (therefore BCC)

I'm sorry but I did not understand this part. :(

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes (a.k.a coringao) 
⣾⠁⢠⠒⠀⣿⡁ Fingerprint: 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780
⢿⡄⠘⠷⠚⠋⠀ Debian Wiki: https://wiki.debian.org/coringao
⠈⠳⣄⠀⠀⠀   

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

Bug#898082: libkf5mailcommon: autopkgtest times out

[Paul Gevers]

Source: libkf5mailcommon
Version: 4:17.12.3-1
Severity: normal
Control: user debian...@lists.debian.org
Control: usertags -1 timeout

Since the upload of version 4:17.12.3-1 of libkf5mailcommon, the
autopkgtest¹ are timing out (~ 3 hours) while previous runs tested in
about 20 minutes (and failed). There is output to the log (copied
below). Could you please investigate how to get rid of the timeout? And
please fix your test to actually pass, but that is less important now.

I have blacklisted 4:17.12.3-1 for now.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

¹ https://ci.debian.net/packages/libk/libkf5mailcommon/unstable/amd64/
² #debci on oftc or debian...@lists.debian.org

autopkgtest [17:12:31]: test testsuite: [---
cd obj-x86_64-linux-gnu && make -j2 -Oline test ARGS\+=-j2
Running tests...
autopkgtest [19:59:11]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/build.AcF/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/build.AcF/src/debian/tests/testsuite;
touch /tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-stdout
/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-stderr;
/tmp/autopkgtest-lxc.9rqu_sd7/downtmp/build.AcF/src/debian/tests/testsuite
2> >(tee -a /tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.9rqu_sd7/downtmp/testsuite-stdout);"
(kind: test)
autopkgtest [19:59:12]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#898081: kdelibs4support: autopkgtest times out

[Paul Gevers]

Source: kdelibs4support
Version: 5.42.0-2
Severity: normal
User: debian...@lists.debian.org
Usertags: timeout

Since the upload of version 5.42.0-2 of kdelibs4support, the
autopkgtest¹ are timing out (~ 3 hours) while previous runs tested in
about 20 minutes (and failed). There is output to the log (copied
below). Could you please investigate how to get rid of the timeout? And
please fix your test to actually pass, but that is less important now.

I have blacklisted kdelibs4support for now.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

¹ https://ci.debian.net/packages/k/kdelibs4support/unstable/amd64/
² #debci on oftc or debian...@lists.debian.org

autopkgtest [10:23:13]: test testsuite: [---
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
kbuildsycoca5 running...
Openbox-Message: Unable to find a valid menu file
"/var/lib/openbox/debian-menu.xml"
cd obj-x86_64-linux-gnu && make -j2 -Oline test ARGS\+=-j2
Running tests...
dbus-daemon[17350]: [session uid=105 pid=17350] Activating service
name='org.kde.kded5' requested by ':1.0' (uid=105 pid=17369
comm="/tmp/autopkgtest-lxc.7bwod5uu/downtmp/build.RQw/sr")
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
dbus-daemon[17350]: [session uid=105 pid=17350] Successfully activated
service 'org.kde.kded5'
kf5.kded: No X-KDE-DBus-ServiceName found in
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/networkstatus.so"
kf5.kded: No X-KDE-DBus-ServiceName found in
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/remotenotifier.so"
kf5.kded: No X-KDE-DBus-ServiceName found in
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/proxyscout.so"
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 17386, result = 0
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debci'
kdeinit5: opened connection to :99
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/libexec/kf5/kconf_update' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/libexec/kf5/kconf_update'
kdeinit5: PID 17389 terminated.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
kf5.kded: could not find kded module with id "ktimezoned"
kf5.kded: attempted to load an invalid module.
autopkgtest [13:09:53]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.7bwod5uu/downtmp/build.RQw/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.7bwod5uu/downtmp/testsuite-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.7bwod5uu/downtmp/testsuite-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.7bwod5uu/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.7bwod5uu/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f

Bug#898080: mpv: Segfault on any file

[Chiraag Nataraj]

Package: mpv
Version: 0.28.0-1
Severity: important

Dear Maintainer,

Upon upgrading to mpv 0.28, mpv segfaults on any file I open. After downgrading 
to 0.27, this was no longer an issue. I can provide strace output if desired.

Sincerely,

Chiraag

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

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

Versions of packages mpv depends on:
ii  libarchive13  3.2.2-3.1
ii  libasound21.1.6-1
ii  libass9   1:0.14.0-1
ii  libavcodec58  7:4.0-1+b1
ii  libavdevice58 7:4.0-1+b1
ii  libavfilter7  7:4.0-1+b1
ii  libavformat58 7:4.0-1+b1
ii  libavutil56   7:4.0-1+b1
ii  libc6 2.27-3
ii  libcaca0  0.99.beta19-2+b3
ii  libcdio-cdda2 10.2+0.94+2-2+b1
ii  libcdio-paranoia2 10.2+0.94+2-2+b1
ii  libcdio17 1.0.0-2+b1
ii  libdrm2   2.4.91-2
ii  libdvdnav46.0.0-1
ii  libdvdread4   6.0.0-1
ii  libegl1   1.0.0+git20180308-2
ii  libgbm1   18.0.2-2
ii  libgl11.0.0+git20180308-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-1
ii  liblua5.2-0   5.2.4-1.1+b2
ii  libpulse0 11.1-5
ii  librubberband21.8.1-7
ii  libsdl2-2.0-0 2.0.8+dfsg1-1
ii  libsmbclient  2:4.8.1+dfsg-1
ii  libsndio6.1   1.1.0-3
ii  libswresample37:4.0-1+b1
ii  libswscale5   7:4.0-1+b1
ii  libuchardet0  0.0.6-2
ii  libva-drm22.1.0-3
ii  libva-x11-2   2.1.0-3
ii  libva22.1.0-3
ii  libvdpau1 1.1.1-8
ii  libvulkan11.1.73+dfsg-1
ii  libx11-6  2:1.6.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.2-1+b2
ii  libxv12:1.0.11-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.2-2
ii  youtube-dl  2018.04.25-1

mpv suggests no packages.

-- no debconf information

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

[Manuel A. Fernandez Montecelo]

2018-05-06 18:47 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
:
>>
>> I somehow prefer to use generic, because there's no point in low-level
>> porting Qt4 at this point.
>
> Worst case scenario: C generic to riscv64, fix that line and be done. But
> yes, let's use this as a last resort, as the fix seems legit.

Gracias!

-- 
Manuel A. Fernandez Montecelo 

Bug#834577: needs more work

[Adam Borowski]

lamby wrote:
> I believe there is a typo in debian/rules:
>
>  override_dh_autoconfigure -> override_dh_auto_configure
>
> Patch attached.

I'm afraid your patch is 0 bytes long.

If what you intended is the obvious one character change, then plugwash tried
it in #897114:

} The only tricky bit was that there seems to have been a typo in
} debian/rules, there was a target called override_dh_autoconfigure which I
} presume was a typo for override_dh_autoconfigure , I tried fixing said
} typo but that seemed to cause more problems than it solved, so I left it
} alone and added my own override target.  You might want to consider either
} fixing or removing the dead code.


Thus, it would need more attention at than my drive-by QA upload to fix the
FTBFS has tuits allotted for.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!
⠈⠳⣄ 

Bug#838678: vsftpd 3.0.2-17+deb8u1 does not start when allow_writeable_chroot=YES is present in vsftpd.conf

[Keng-Yu Lin]

2016-09-23 22:43 GMT+08:00 Robert Mueller :
> Package: vsftpd
> Version: 3.0.2-17+deb8u1
> Severity: important
>
> Dear Maintainer,
>
> when trying to configure vsftpd to allow it to run with user-writeable chroot 
> directories, the daemon does not start up. Removing the 
> allow_writeable_chroot directive helps, but for my configuration here I 
> really need this to be enabled.
> According to vsftpd upstream changelogs, the directive was added in 2.3.5 and 
> never removed. However, the version provided in jessie does not seem to 
> recognise the option, and it's also not mentioned in the vsftpd.conf manpage.
>
> Is this a bug, or was this option removed intentionally in the Debian build?
>

I just tried vsftpd 3.0.3-9 from Jesse. With allow_writeable_chroot
directive=YES in /etc/vsftpd.conf, vsftpd can start.
I believe this bug is fixed by newer version of vsftpd package.

I will close this bug for now. Feel free to reopen it if you still
encounter the bug.





> -- Package-specific info:
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages vsftpd depends on:
> ii  adduser3.113+nmu3
> ii  debconf [debconf-2.0]  1.5.56
> ii  dialog 1.2-20140911-1
> ii  init-system-helpers1.22
> ii  libc6  2.19-18+deb8u6
> ii  libcap21:2.24-8
> ii  libpam-modules 1.1.8-3.1+deb8u1+b1
> ii  libpam0g   1.1.8-3.1+deb8u1+b1
> ii  libssl1.0.01.0.1t-1+deb8u4
> ii  libwrap0   7.6.q-25
> ii  netbase5.3
>
> Versions of packages vsftpd recommends:
> ii  logrotate  3.8.7-1+b1
> ii  ssl-cert   1.0.35
>
> vsftpd suggests no packages.
>
> -- Configuration Files:
> /etc/vsftpd.conf changed [not included]
>
> -- debconf information:
>   vsftpd/directory: /srv/ftp
>   vsftpd/username: ftp

Bug#613000: Convert Hardening Debian to XML

[Marcos Fouces]

El 06/05/18 a las 18:40, Osamu Aoki escribió:
>
> We need to move to salsa (debian group), I think.
>
> I mean in https://salsa.debian.org/debian
>
> like https://salsa.debian.org/debian/debian-reference
OK, could you give me access?

BTW, is there any plan to create a ddp group?

> This way, all DD has access.
>
> https://wiki.debian.org/Salsa/Doc
>
>> 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.
> This is still pending, I think.
No, i talked with Javi on IRC a year ago. He told me to work on *.po
files (i already had done the migration to git and to xml at that time).

The simplest build system i found was the debian-handbook so i re-used
its Publican based system.

Greetings,
Marcos

Bug#898079: [L10N,DE] ucf: updated german debconf translation

[Holger Wansing]

Package: ucf
Severity: wishlist
Tags: patch,l10n
Version: 3.0037


Hi,
attached is the updated german debconf translation for ucf, version 3.0037.
Please include it in your package.

Thanks for your i18n efforts.

So long
Holger

-- 

Created with Sylpheed 3.2.0 under the new
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



ucf_de.po.gz
Description: application/gzip

Bug#895872: #895872 Crash if ~/.wget-hsts cannot be opened for writing

[Ben Hutchings]

Do you plan to fix this in a stable update?

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#898078: O: zbar

[Bernd Zeimetz]

Package: wnpp
Severity: normal

Hi,

zbar does not have an active upstream for a long time now.
More and more bugs are reported.
If nobody steps up to maintain the package - and I guess
become upstream for it, I'll file a removal bug.

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#898046: Acknowledgement (abcde: Options -T (because of octal) and -n broken)

[Samuel Hym]

retitle 898046 Options -T and -W broken because of octal
thanks

I ran into the same issue with -W than with -T, namely that handling
of track numbers is broken for numbers >= 8, because of "0" prefix.

Glancing over the code for -n, I think I indeed misunderstood the role
of that option.

Best regards

Bug#896684: fontconfig-config: Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf, due to many errors

[Julian Raisch]

https://bugs.freedesktop.org/show_bug.cgi?id=105818
https://bugs.chromium.org/p/chromium/issues/detail?id=829890

Seems to be a Chromium bug. It has its own outdated version of fontconfig.

Bug#897537: tudu: FTBFS: ./configure: 394: ./configure: rmtest.c: not found

[Sven Joachim]

On 2018-05-02 22:54 +0200, Lucas Nussbaum wrote:

> Source: tudu
> Version: 0.10.2-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> make[1]: Entering directory '/<>'
>> rm -f configure Makefile */Makefile
>> acr
>> acr: ./configure script created successfully.
>> acr: all done.
>> dh_auto_configure
>>  ./configure --build=x86_64-linux-gnu --prefix=/usr
>> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
>> --infodir=\${prefix}/share/info --sysconfdir=/etc
>> --localstatedir=/var --disable-silent-rules
>> --libdir=\${prefix}/lib/x86_64-linux-gnu
>> --libexecdir=\${prefix}/lib/x86_64-linux-gnu
>> --disable-maintainer-mode --disable-dependency-tracking
>> checking for cpp... ERROR:  cannot parse sources

It seems to me this is a bug in acr 1.6.1-1.  The configure script
generated by it is clearly broken, and the same tudu version built
successfully with acr 1.2-1 back in June 2017.  Maybe the acr
maintainer can find out what went wrong here.

>> WARNING: Unknown flag '--disable-silent-rules'.
>> 
>> 
>> WARNING: Unknown flag '--disable-maintainer-mode'.
>> 
>> 
>> WARNING: Unknown flag '--disable-dependency-tracking'.
>> 
>> checking build system type... x86_64-linux-gnu
>> checking host system type... x86_64-unknown-linux-gnu
>> checking target system type... x86_64-unknown-linux-gnu
>> checking for working directories... current
>> using prefix '/usr'
>> checking for c++ compiler... g++
>> checking for xcurses.h... no
>> checking for ncursesw/curses.h... yes
>> checking for ncurses/curses.h... no
>> checking for ncurses.h... yes
>> checking for curses.h... yes
>> checking for libncursesw ... yes
>> checking for libncurses ... yes
>> checking for libcurses ... yes
>> checking for WIDEC_CURSES... ./configure: 394: ./configure: 
>> echo#define_XOPEN_SOURCE_EXTENDED: not found
>> ./configure: 394: ./configure: echo#include: not found
>> ./configure: 394: ./configure: echointmain(){addwstr(L"");}: not found
>> ./configure: 394: ./configure: cannot create /dev/null2: Permission denied
>> ./configure: 394: ./configure: eval$CXX-g: not found
>> ./configure: 394: ./configure: rmtest.c: not found
>> no
>> 
>> ERROR: There is no wide character support on curses!
>> 
>> dh_auto_configure: ./configure --build=x86_64-linux-gnu
>> --prefix=/usr --includedir=\${prefix}/include
>> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
>> --sysconfdir=/etc --localstatedir=/var --disable-silent-rules
>> --libdir=\${prefix}/lib/x86_64-linux-gnu
>> --libexecdir=\${prefix}/lib/x86_64-linux-gnu
>> --disable-maintainer-mode --disable-dependency-tracking returned
>> exit code 1
>> make[1]: *** [debian/rules:9: override_dh_auto_configure] Error 2

Cheers,
   Sven

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

[Ben Hutchings]

On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> Hi Ben,
> 
> On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> > I've cloned this bug as #898073 and reassigned that to krb5.
> > 
> > krb5 is using the new(ish) getrandom() system call to read random bits,
> > with the code comment "This ensures strong randomness while only
> > blocking during first system boot."
> > 
> > While this is a regression, the kernel is only doing what krb5 was
> > asking for (whereas previously it could wrongly provide weak random
> > bits).
> > 
> > We might still revert this change in the kernel temporarily.  However,
> > the krb5 developers need to decide what they really want, and if that's
> > strong randomness then they need to configure the service to allow for
> > a longer delay at boot.
> 
> I read through the history on #898073 and am still not sure I have
> the backstory quite right.  This is what it sounds like has
> happened:
> 
> The kernel in stable has for some time provided a getrandom() system
> call that provided "weak" (more on this later) random numbers for
> some time after startup, though did eventually converge to "strong"
> randomness after some time (a few minutes?).  The kernel 4.9.88-1
> upload fixed the bug that getrandom() could provide "weak" output
> (since getrandom() is supposed to block until strong output is
> ready), and this in turn caused the krb5 KDC to block at boot until
> the RNG was ready, blocking long enough that systemd timed out the
> unit and marked it as failed.  We're now talking about the proper
> way to improve the situation.

Right.

> If the above is correct, I'm not yet sure that I see a krb5-specific
> bug.  It is definitely true that krb5 is specifically requesting the
> getrandom() semantics of blocking until the RNG is fully seeded, but
> krb5 is hardly expected to be the only consumer of getrandom().  As
> such, why should krb5 be responsible for increasing the systemd
> timeout at boot -- could not systemd be responsible for increasing
> the default timeout to allow for entropy seeding as used by multiple
> applications?

How would systemd determine which systems require this?

> Arguably more preferable would be to have a systemd
> target that indicates the RNG is seeded, and then krb5 could have
> its KDC service depend on this "RNG-available" service.  So far as I
> know, no such service currently exists, so again, there would need
> to be some sytsemd effort (potentially in cooperation with the
> kernel) to provide such a service.

Yes, that certainly seems like a good approach.

> To rephrase in a different way, "getrandom() is a system service,
> and the system's init system should not penalize other services for
> using system services -- why should the onus of adapting be placed on
> individual consumers of that system service?"
> 
> 
> Back to the "weak" random numbers.  How weak are we talking about?

If I'm reading the code correctly, the previous condition for
successful return of getrandom() (without the GRND_RANDOM flag) was
that at least 64 bits of raw random data have been added to the random
pool.  The raw random data might come from a high quality hardware
random number generator but might be much weaker.  The current
condition is that at least 128 bits of entropy have been added (based
on a conservative estimate of entropy).

> The krb5 KDC and kadmind are used (among other things) to generate
> shared symmetric keys, used to encrypt and authenticate traffic over
> the network.  Some of these keys are long-lived, and an
> insufficiently random long-lived key could have rather disasterous
> consequences for deployments unlucky enough to have generated them.
> Are we looking at a repeat of the openssl RNG fiasco where piles of
> ssh keys and TLS certificates had to be regenerated?  If there's a
> real issue here of weak randomness, we may need to publicize this
> issue much more widely.

The real issue is that k5_get_os_entropy() silently falls back to
reading /dev/urandom, which has never, and will never, wait for a
reasonable amount of entropy to be available.

Worse still, it ignores the "strong" flag when calling getrandom().

If you're serious about the quality of your random numbers, you need to
deal with those issues rather than quibbling about whether the kernel
issue (CVE-2018-1108) is a "fiasco" or not.

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#894302: Re[2]: g++-7: Compiler generates wrong code with warning options

[Matthias Klose]

On 06.05.2018 16:48, Vadim Zeitlin wrote:
> On Sun, 6 May 2018 13:42:48 +0200 Matthias Klose  wrote:
> 
> MK> I am not aware of any Debian local patches which could trigger that.  
> Please
> MK> could you check if you can reproduce this with GCC 8 as well?
> 
>  I can't reproduce the problem with the minimized test case using gcc 8
> from Sid (8.1.0-1). As an aside, gcc 8 also produces much smaller (less
> than 50%) assembly and object code from the same files compared to gcc 7,
> which surprised me. FWIW I can still reproduce the problem with the
> latest g++-7 (7.3.0-17) in exactly the same way as originally reported for
> 7.2.
> 
>  The original problem, in the real program I was working on, only appeared
> when using MinGW, so I can't [easily] test whether it is still present or
> not as there is no gcc-mingw-w64 8 in Debian yet, but I'll do it when it
> becomes available.

I doubt I'll have time for this. If you know how to build a debian package, you
could have a look at the gcc-7 package, debian/rules.patch and try to disable
some patches (is a gcc upstream snapshot taken from the gcc-7-branch ok?), and
then see if things get better. svn-updates is the big hammer, but you could try
to disable libstdc++-pic to pr84761 and see if things get better.

Matthias

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

[Daniel Stender]

On 05/06/2018 08:56 PM, Adrian Bunk wrote:
> Control: severity -1 serious
> 
> On Sat, May 05, 2018 at 05:58:21PM +0200, Daniel Stender wrote:
>> Control: severity -1 important
>>
>> I'm lowering the severity of this bug report now to unblock the migration to 
>> testing.
> 
> The failed mips64el build does block testing migration in any case:
> https://tracker.debian.org/pkg/llvmlite

#898002

> The easiest way forward might be going from 5.0 to 6.0?

#898004
 
>> DS
> 
> cu
> Adrian

DS

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

Bug#885135: pygtk will be part of buster

[Adrian Bunk]

Control: severity -1 important

pygtk will be part of buster, see #895248 for background.

Note that pygtk is Python 2 only, and Python 2 is expected to be
removed from unstable after the release of buster.
It is therefore still advisable to port these packages away
from pygtk.

cu
Adrian

-- 

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

Bug#892307: fixed in bash-completion 1:2.8-1

[Gabriel F. T. Gomes]

On 02 Apr 2018, Paul Wise wrote:

>On Sun, 2018-04-01 at 18:19 +, Gabriel F. T. Gomes wrote:
>
>>* Fix regression when MANPATH is set with colons (Closes:
>> #892307)  
>
>I noticed the upstream version of the fix misses these things:
>
> * falling back on `man --path` when the man implementation does not
>   have support for `manpath` and `man -w`
> * falling back on $MANPATH when the man implementation does not have
>   support for printing the manual pages paths
>
>Would it be possible for one of you to send them a fix for that?

Sorry for taking so long to reply to this.

I can definitely send this upstream, but since you have already
provided the solution in the bug report, may I set the author name to
"Paul Wise " in the patch (git commit)?

It would look like this:



Author: Paul Wise 
Date:   Sun May 6 16:09:58 2018 -0300

Fallbacks for man completion

The commit

  commit e6a471511dfdc230ff3eed65ccba09b6d7d30262
  Author: Pawel 
  Date:   Wed Sep 27 06:34:59 2017 +0200

  man: Don't use $MANPATH directly (#161)

fixes the behavior of man completion when MANPATH is set, however, it
misses the following:

  * falling back on `man --path` when the man implementation does not
have support for `manpath` and `man -w`
  * falling back on $MANPATH when the man implementation does not have
support for printing the manual pages paths

This patch addresses them.

diff --git a/completions/man b/completions/man
index 0668b8ee..d0068fc7 100644
--- a/completions/man
+++ b/completions/man
@@ -51,7 +51,8 @@ _man()
 return
 fi
 
-local manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null )
+local manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null || 
command man --path 2>/dev/null )
+[[ -z $manpath ]] && manpath=$MANPATH
 [[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man"
 
 # determine manual section to search

Bug#898077: lintian: False positive in missing-build-dependency-for-dh-addon, python package

[Chris Lamb]

tags 898077 + pending
thanks

> Lintian should perhaps check of there is a python package that meets the
> dependency requirement? Or allow e.g. "*scour"?

We can't do a wildcard (!) but we can also check for
python-scour. I've done this in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/fc69686ae2d6aff415762812e805af4e5e9ca627

  data/debhelper/dh_addons-manual | 1 +
  debian/changelog| 4 
  2 files changed, 5 insertions(+)


Regards,

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

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

[Benjamin Kaduk]

Hi Ben,

On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> I've cloned this bug as #898073 and reassigned that to krb5.
> 
> krb5 is using the new(ish) getrandom() system call to read random bits,
> with the code comment "This ensures strong randomness while only
> blocking during first system boot."
> 
> While this is a regression, the kernel is only doing what krb5 was
> asking for (whereas previously it could wrongly provide weak random
> bits).
> 
> We might still revert this change in the kernel temporarily.  However,
> the krb5 developers need to decide what they really want, and if that's
> strong randomness then they need to configure the service to allow for
> a longer delay at boot.

I read through the history on #898073 and am still not sure I have
the backstory quite right.  This is what it sounds like has
happened:

The kernel in stable has for some time provided a getrandom() system
call that provided "weak" (more on this later) random numbers for
some time after startup, though did eventually converge to "strong"
randomness after some time (a few minutes?).  The kernel 4.9.88-1
upload fixed the bug that getrandom() could provide "weak" output
(since getrandom() is supposed to block until strong output is
ready), and this in turn caused the krb5 KDC to block at boot until
the RNG was ready, blocking long enough that systemd timed out the
unit and marked it as failed.  We're now talking about the proper
way to improve the situation.

If the above is correct, I'm not yet sure that I see a krb5-specific
bug.  It is definitely true that krb5 is specifically requesting the
getrandom() semantics of blocking until the RNG is fully seeded, but
krb5 is hardly expected to be the only consumer of getrandom().  As
such, why should krb5 be responsible for increasing the systemd
timeout at boot -- could not systemd be responsible for increasing
the default timeout to allow for entropy seeding as used by multiple
applications?  Arguably more preferable would be to have a systemd
target that indicates the RNG is seeded, and then krb5 could have
its KDC service depend on this "RNG-available" service.  So far as I
know, no such service currently exists, so again, there would need
to be some sytsemd effort (potentially in cooperation with the
kernel) to provide such a service.

To rephrase in a different way, "getrandom() is a system service,
and the system's init system should not penalize other services for
using system services -- why should the onus of adapting be placed on
individual consumers of that system service?"


Back to the "weak" random numbers.  How weak are we talking about?
The krb5 KDC and kadmind are used (among other things) to generate
shared symmetric keys, used to encrypt and authenticate traffic over
the network.  Some of these keys are long-lived, and an
insufficiently random long-lived key could have rather disasterous
consequences for deployments unlucky enough to have generated them.
Are we looking at a repeat of the openssl RNG fiasco where piles of
ssh keys and TLS certificates had to be regenerated?  If there's a
real issue here of weak randomness, we may need to publicize this
issue much more widely.

Thanks,

Ben


signature.asc
Description: PGP signature

Bug#898052: libupnp6-dev is marked Multi-Arch: same but has a conflicting file

[Uwe Kleine-König]

Control: tag 898052 + pending

On Sun, May 06, 2018 at 05:56:06AM -0400, Francois Gouget wrote:
> Trying to install the amd64 and i386 versions of this
> package results in the following error:
> 
> # apt-get install libupnp6-dev:amd64 libupnp6-dev:i386
> [...]
> Unpacking libupnp6-dev:i386 (1:1.6.24-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libupnp6-dev_1%3a1.6.24-4_i386.deb (--unpack):
>  trying to overwrite shared '/usr/include/upnp/upnpconfig.h', which is 
> different from other instances of package libupnp6-dev:i386
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/libupnp6-dev_1%3a1.6.24-4_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

I had this issue on the radar and fixed it in the VCS already.

Best regards and thanks for the report
Uwe


signature.asc
Description: PGP signature

Bug#898077: lintian: False positive in missing-build-dependency-for-dh-addon, python package

[Ross Gammon]

Package: lintian
Version: 2.5.55
Severity: normal

Dear Maintainer,

When building laditools, the missing-build-dependency-for-dh-addon lintian
warning is received because scour is not a build dependency when the scour dh
addon is used in debian/rules.

However, python-scour is a build dependency and pulls in the scour package.

Lintian should perhaps check of there is a python package that meets the
dependency requirement? Or allow e.g. "*scour"?

Regards,

Ross



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

Kernel: Linux 4.13.0-39-generic (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)

Versions of packages lintian depends on:
ii  binutils  2.29.1-4ubuntu1
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1build1
ii  dpkg  1.18.24ubuntu1
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4ubuntu1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2build2
ii  libdpkg-perl  1.18.24ubuntu1
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1build3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8ubuntu1.1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2build1
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-8ubuntu1.1
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build3

Versions of packages lintian suggests:
ii  binutils-multiarch 2.29.1-4ubuntu1
ii  dpkg-dev   1.18.24ubuntu1
ii  libhtml-parser-perl3.72-3build1
ii  libtext-template-perl  1.46-1

-- no debconf information

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

[Adrian Bunk]

Control: severity -1 serious

On Sat, May 05, 2018 at 05:58:21PM +0200, Daniel Stender wrote:
> Control: severity -1 important
> 
> I'm lowering the severity of this bug report now to unblock the migration to 
> testing.

The failed mips64el build does block testing migration in any case:
https://tracker.debian.org/pkg/llvmlite

The easiest way forward might be going from 5.0 to 6.0?

> DS

cu
Adrian

--

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

Bug#898076: wget: CVE-2018-0494: cookie injection

[Salvatore Bonaccorso]

Source: wget
Version: 1.19.4-1
Severity: grave
Tags: patch security upstream fixed-upstream

Hi,

The following vulnerability was published for wget.

CVE-2018-0494[0]:
cookie injection

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-0494
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0494
[1] 
https://git.savannah.gnu.org/cgit/wget.git/commit/?id=1fc9c95ec144499e69dc8ec76dbe07799d7d82cd

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#865797: signond FTBFS: symbol changes

[Manuel A. Fernandez Montecelo]

user debian-ri...@lists.debian.org
usertag 865797 + riscv64
stop


Hi,

2017-06-24 23:17 Adrian Bunk:

Source: signond
Version: 8.59-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes signond FTBFS:

https://tests.reproducible-builds.org/debian/history/signond.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/signond.html


FWIW I was able to build for riscv64 updating symbols with
pkgkde-symbolshelper (update for all arches), debdiff attached.

ia64 and riscv64 are the only ones built recently though.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru signond-8.59/debian/changelog signond-8.59/debian/changelog
--- signond-8.59/debian/changelog   2016-06-24 14:20:35.0 +0200
+++ signond-8.59/debian/changelog   2018-05-06 19:35:09.0 +0200
@@ -1,3 +1,10 @@
+signond (8.59-1+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: symbols update
+
+ -- Manuel A. Fernandez Montecelo   Sun, 06 May 2018 17:35:09 
+
+
 signond (8.59-1) unstable; urgency=medium
 
   [ Diane Trout ]
diff -Nru signond-8.59/debian/libsignon-plugins-common1.symbols 
signond-8.59/debian/libsignon-plugins-common1.symbols
--- signond-8.59/debian/libsignon-plugins-common1.symbols   2016-06-24 
14:20:35.0 +0200
+++ signond-8.59/debian/libsignon-plugins-common1.symbols   2018-05-06 
19:34:49.0 +0200
@@ -1,15 +1,15 @@
-# SymbolsHelper-Confirmed: 8.59 amd64
+# SymbolsHelper-Confirmed: 8.59-1 alpha arm64 armel armhf hppa hurd-i386 i386 
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe 
ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
 libsignon-plugins-common.so.1 libsignon-plugins-common1 #MINVER#
- (optional=templinst|arch=mips64el 
mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base
 8.57+20150423
+#MISSING: 8.59-1# (optional=templinst|arch=mips64el 
mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base
 8.57+20150423
  _Z23expandDBusArgumentValueRK8QVariantPb@Base 8.57+20150423
  
(optional=templinst|arch=amd64)_Z27qRegisterNormalizedMetaTypeI13QDBusArgumentEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS4_Xaasr12QMetaTypeId2IS4_E7DefinedntsrS9_9IsBuiltInEE11DefinedTypeE@Base
 8.57+20150423
- 
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base
 8.57+20150423
- 
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base
 8.57+20150423
+#MISSING: 8.59-1# 
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base
 8.57+20150423
+#MISSING: 8.59-1# 
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base
 8.57+20150423
  
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE8DestructEPv@Base
 8.57+20150423
  
(optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE9ConstructEPvPKv@Base
 8.57+20150423
  (optional=templinst)_ZN4QMapI7QString8QVariantE13detach_helperEv@Base 
8.57+20150423
- (optional=templinst)_ZN4QMapI7QString8QVariantED1Ev@Base 8.59
- (optional=templinst)_ZN4QMapI7QString8QVariantED2Ev@Base 8.59
+ (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED1Ev@Base 
8.59
+ (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED2Ev@Base 
8.59
  _ZN6SignOn13BlobIOHandler11qt_metacallEN11QMetaObject4CallEiPPv@Base 
8.57+20150423
  _ZN6SignOn13BlobIOHandler11qt_metacastEPKc@Base 8.57+20150423
  _ZN6SignOn13BlobIOHandler11receiveDataEi@Base 8.57+20150423
@@ -31,23 +31,26 @@
  
(optional=templinst)_ZN7QVectorI10QByteArrayE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base
 8.57+20150423
  (optional=templinst)_ZN7QVectorI10QByteArrayE6appendERKS0_@Base 8.57+20150423
  (optional=templinst)_ZN8QMapNodeI7QString8QVariantE14destroySubTreeEv@Base 
8.57+20150423
+ (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD1Ev@Base 8.59-1
+ (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD2Ev@Base 8.59-1
+ (optional=templinst|arch=ia64 
riscv64)_ZN9QtPrivate24readAssociativeContainerI4QMapI7QString8QVariantEEER11QDataStreamS6_RT_@Base
 8.59-1
  _ZNK6SignOn13BlobIOHandler10metaObjectEv@Base 8.57+20150423
  
(optional=templinst)_ZNK8QMapNodeI7QString8QVariantE4copyEP8QMapDataIS0_S1_E@Base
 8.57+20150423
  _ZTVN6SignOn13BlobIOHandlerE@Base 8.57+20150423
  
(optional=templinst)_ZZN11QMetaTypeIdI13QDBusArgumentE14qt_metatype_idEvE11metatype_id@Base
 8.57+20150423
- 
(optional=templinst)_ZrsI7QString8QVariantER11QDataStreamS3_R4QMapIT_T0_E@Base 
8.57+20150423
+ (optional=templinst|arch=!ia64 

Bug#897159: flightgear: missing qml dependencies

[Rebecca N. Palmer]

This is known upstream:
https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/96b69154-ebd9-166f-9be5-d4971ee4ab05%40numericable.com/#msg36224500

Upstream keep a dependency list in
https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh 
(lines ~330), but it's for the current development branch (e.g. we 
probably don't need -dialogs just yet), and doesn't distinguish build 
and runtime dependencies.

Bug#895332: flightgear: FTBFS on armel and armhf - GLES related?

[Rebecca N. Palmer]

This looks like a GL vs GLES incompatibility: libqt5opengl uses OpenGL 
ES on armel+armhf, simgear/flightgear use full OpenGL on all 
architectures, and the two can't be mixed.


simgear+flightgear probably can't switch to OpenGL ES because they use 
legacy OpenGL functions that aren't in ES.  (They fail to build on 
Ubuntu's GLES-only(?) armhf because of this: 
https://launchpad.net/ubuntu/+source/simgear/1:2018.1.1+dfsg-1/+build/14785755/+files/buildlog_ubuntu-bionic-armhf.simgear_1%3A2018.1.1+dfsg-1_BUILDING.txt.gz 
https://bugs.launchpad.net/ubuntu/+source/simgear/+bug/1423380 )


Given this, I suspect the best we can get on armel+armhf is a no-Qt 
flightgear (i.e. no launcher etc - change -DENABLE_QT in debian/rules). 
It must also continue to use openscenegraph 3.2 (OpenGL) rather than 3.4 
(OpenGL ES on armel+armhf).

Bug#862230: mplayer: error while loading shared libraries: R_PPC_REL24 relocation at 0x207ac54c for symbol `htonl' out of range

[Reimar Döffinger]

I can reproduce it with the 1.0.3-8 Debian package on a PPC MacMini.
However I cannot reproduce it when manually building MPlayer (from the debian 
source package). (I haven't tried rebuilding from source using the debian 
tools).
I think the package must have been built with a badly broken compiler (possibly 
the hardening options cause issues?), for 2 reasons:
- htonl is defined as a macro in netinet/in.h, we should never get a call to 
the function at all (I can confirm no such calls exist in the manual build). 
Digging deeper is hard since the debug symbol package seems to not longer 
exist?!
- REL24 should not be used for relocations against a dynamic library, at least 
not if ASLR might be active.

Maybe someone could try rebuilding it with the latest toolchain?

Bug#898066: New mailing list: debian-wine (move from alioth)

[James Lu]

Hello everyone,

As the current exe-thumbnailer maintainer I'm seconding this request.

Best,
James



signature.asc
Description: OpenPGP digital signature

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

[Jérémy Lal]

2018-05-06 3:19 GMT+02:00 積丹尼 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
>

Note that it should be easy to work around: remove nodejs-dev, apply, then
install latest version.

Jérémy

Bug#898075: jack: segfaults at start

[Francesco Poli (wintermute)]

Package: jack
Version: 3.1.1+cvs20050801-29.2+b1
Severity: grave
Justification: renders package unusable

Hello!

I have just found out that jack stopped working in Debian testing.
Last time I used it (around last December, on an up-to-date Debian
testing box), it worked without any glitch.

Now, when I try to encode one audio CD (*any* audio CD, including
one that was successfully encoded in the past), I just get a
segfault, immediately after selecting which FreeDB entry I want to use
(when there is a multiple choice):

  $ jack -Q
  [...]
  Segmentation fault

My /var/log/kern.log says:

  May  6 19:44:10 HOSTNAME kernel: [36919.353320] jack[10063]: segfault at 
7f89 ip 7f89ed5665c1 sp 7ffee93b2398 error 4 in 
libc-2.27.so[7f89ed40d000+1b1000]

My configuration file is:

  $ cat ~/.jack3rc 
  # jackrc-version:31
  ripper:cdparanoia
  base_dir:~/music/CDs
  unusable_chars:[' ', '/', ':', '?', '|', '>', '<']
  replacement_chars:['_', '_', '_', '_', '_', '_', '_']

in case it makes any difference.


Could you please try to reproduce the bug and fix it and/or
forward my bug report upstream, as appropriate?

Thanks for your time!
Bye.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (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 jack depends on:
ii  cdparanoia   3.10.2+debian-13
ii  libc62.27-3
ii  libncursesw6 6.1+20180210-2
ii  libtinfo66.1+20180210-2
ii  python   2.7.15~rc1-1
ii  python-cddb  1.4-5.3
ii  python-eyed3 0.8.4-2
ii  python-pyvorbis  1.5-4
ii  vorbis-tools 1.4.0-10.1

jack recommends no packages.

jack suggests no packages.

-- no debconf information

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

[Ben Hutchings]

I've cloned this bug as #898073 and reassigned that to krb5.

krb5 is using the new(ish) getrandom() system call to read random bits,
with the code comment "This ensures strong randomness while only
blocking during first system boot."

While this is a regression, the kernel is only doing what krb5 was
asking for (whereas previously it could wrongly provide weak random
bits).

We might still revert this change in the kernel temporarily.  However,
the krb5 developers need to decide what they really want, and if that's
strong randomness then they need to configure the service to allow for
a longer delay at boot.

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#898074: linux-image-4.9.0-6-amd64: gdb3 fails to start

[Kevin Bube]

Package: src:linux
Version: 4.9.88-1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

after an update from linux-image-4.9.0-5-amd64 to
linux-image-4.9.0-6-amd64 gdm3 did not start anymore. The screen remains
black. However, I can still switch to a text console.

It seems that the permissions of /dev/dri/card0 changed. See below for
the end of syslog. syslog.broken is the error case, syslog.ok is the
successful case.

Thanks,

Kevin

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 4383
product_version: Lenovo G575 
chassis_vendor: Chassis Manufacturer
chassis_version: Chassis Version
bios_vendor: LENOVO
bios_version: 41CN27WW(V2.03)
board_vendor: LENOVO
board_name: Inagua
board_version: Base Board Version

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 14h 
Processor Root Complex [1022:1510]
Subsystem: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root 
Complex [1022:1510]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon

00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (prog-if 01 [AHCI 
1.0])
Subsystem: Lenovo SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] 
[17aa:3971]
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: ahci
Kernel modules: ahci

00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI])
Subsystem: Lenovo SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [17aa:397b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI])
Subsystem: Lenovo SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [17aa:397b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus 
Controller [1002:4385] (rev 42)
Subsystem: Lenovo SBx00 SMBus Controller [17aa:397b]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)
Subsystem: Lenovo SB7x0/SB8x0/SB9x0 LPC host controller [17aa:397b]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) [1002:43a0] (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:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB700/SB800/SB900 PCI to PCI bridge (PCIE port 1) [1002:43a1] (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:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h 
Processor Function 0 

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

[Felix Geyer]

Control: severity -1 grave

On Wed, 2 May 2018 17:13:03 -0700 Sohum Banerjea  wrote:
> zfs-dkms fails to build on installing linux kernel 4.16.0-1-amd64, with the
> following error.

Bumping the severity since it makes the package unusable with the
testing/unstable kernel.

Felix

Bug#898071: ITP: foundationdb -- distributed, transactional, key-value store

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: foundationdb
  Version : 5.1.7
  Upstream Author : Apple Inc.
* URL : https://www.foundationdb.org/
* License : Apache-2.0
  Programming Lang: C/C++ with bindings for many others
  Description : distributed, transactional, key-value store

FoundationDB is a distributed database designed to handle large volumes of
structured data across clusters of commodity servers. It organizes data as an
ordered key-value store and employs ACID transactions for all operations. It is
especially well-suited for read/write workloads but also has excellent
performance for write-intensive workloads. Users interact with the database
using API language binding.

Bug#898072: ITP: mpl-scatter-density -- Fast scatter density plots for Matplotlib

[Josue Ortega]

Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

*Package name: python-mpl-scatter-density
 Version: 0.3
 Upstream Author: Thomas Robitaille 
*URL: https://github.com/astrofrog/mpl-scatter-density
*Licence: BSD-2-Clause
Programming Lang: Python
Description: The mpl-scatter-density mini-package provides functionality to
 make it easy to make your own scatter density maps, both for interactive
 and non-interactive use. Fast. The following animation shows real-time
 interactive use with 10 million points, but interactive performance is still
 good even with 100 million points (and more if you have enough RAM).

I intend to maintain this package under the umbrella of the Debian Astro Team,
since it is a dependency of the latest glueviz version

---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: PGP signature

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

[Ben Hutchings]

On Sun, 2018-05-06 at 17:22 +0200, Laurent Bigonville wrote:
> On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings  
> wrote:
>  > 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.
> 
> Hello Ben,
> 
> plymouth doesn't uses Xorg, it uses libdrm and KMS directly.

Oh I see, I was confused by the existence of plymouth-x11.

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#897572:

[Eric Mill]

FWIW, I have the exact same problem (and can resolve it the exact same way,
by moving my finger over my trackpad for a few seconds), and am on a
different graphics card -- Intel Iris Graphics 540 (Skylake GT3e).

I'm not an expert in kernel/firmware stuff at all, and can't compile a
kernel from scratch, but let me know if there's anything I can pull from my
system that would be useful in diagnosing the issue.

Bug#898070: back-mdb broken on kfreebsd-*

[Ryan Tandy]

Source: openldap
Version: 2.4.46+dfsg-1
Severity: important

It looks like the LMDB backend is not working at all on kfreebsd-* and 
slapd just fails to start.



Starting test000-rootdse for mdb...

running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to retrieve the root DSE...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
../../../tests/scripts/test000-rootdse: 66: kill: No such process

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Test failed
test000-rootdse failed for mdb

(exit 255)

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 5 de mayo de 2018 10:06:22 -03 Manuel A. Fernandez Montecelo 
escribió:
> 2018-05-05 3:56 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
> 
> :
> > I was about to upload qt4 when I found:
> > 
> > -Q_GLOBAL_STATIC_WITH_ARGS(const QString, orgFreedesktopDBusString,
> > (QLatin1String(DBUS_SERVICE_DBUS))) +Q_GLOBAL_STATIC_WITH_ARGS(QString,
> > orgFreedesktopDBusString, (QLatin1String(DBUS_SERVICE_DBUS)))
> > 
> > This clearly does not looks ok. Probably a mistake?
> 
> I changed this because the compilation fails otherwise:
[snip yet another excellent explanation]
> The alternative would be to use -fpermissive globally, I think, but
> this would mask other similar problems, so I patched that one and it
> was the only such problematic line in the whole code.
> 
> 
> My best guess is that no other [popular] platforms are using "generic"
> but its own, so this code is never compiled in Debian for other arches
> and thus it doesn't fail, it's a latent error in code of unused
> code-paths.

Let's check that. I'm currently running getbuildlog and will grep them. But 
judging for what you wrote above you are probably just right.

Right, there seems to be no direct usage.

> I somehow prefer to use generic, because there's no point in low-level
> porting Qt4 at this point.

Worst case scenario: C generic to riscv64, fix that line and be done. But 
yes, let's use this as a last resort, as the fix seems legit.



-- 
"In college, I cooked some hot dogs by putting metal forks in each end of the
hot dog and running 120 volts through it. Hot dogs have just enough
conductivity so that this works well"
  greenroom(576281) - on a truly geeky way to cook hot dogs.
  Posted in Slashdot, also found in The Open Source Cookbook for Geeks.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#898069: asd

[Josue Ortega]

Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

*Package name: python-fast-histogram
 Version: 0.5
 Upstream Author: Thomas Robitaille 
*URL: https://github.com/astrofrog/fast-histogram
*Licence: BSD-2-Clause
Programming Lang: Python
Description:
 The fast-histogram mini-package aims to provide simple and fast histogram
 functions for regular bins that don't compromise on performance. It doesn't do
 anything complicated - it just implements a simple histogram algorithm in C and
 keeps it simple. The aim is to have functions that are fast but also robust and
 reliable. The result is a 1D histogram function here that is 7-15x faster than
 numpy.histogram, and a 2D histogram function that is 20-25x faster than
 numpy.histogram2d

I intend to maintain this package under the umbrella of the Debian Astro Team,
since it is a transitive dependency of the latest glueviz version

---
Josue Ortega
«Happy Hacking»
http://josueortega.org


signature.asc
Description: PGP signature

Bug#613000: Convert Hardening Debian to XML

[Osamu Aoki]

Hi,

On Sat, May 05, 2018 at 08:12:00PM +0200, Marcos Fouces wrote:
> Hello
> 
> I already done the following work so far and uploaded to the repo [1]:
> 
> * Imported SVN repo to git.

Great

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

Good
 
> * 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).

Good

> All languages have at least 30% translated strings.

Good start

> Hope that helps to maintain this good manual.

Yes.

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

We need to move to salsa (debian group), I think.

I mean in https://salsa.debian.org/debian

like https://salsa.debian.org/debian/debian-reference

This way, all DD has access.

https://wiki.debian.org/Salsa/Doc

> 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.

This is still pending, I think.
 
> Please check with:
>  https://wiki.debian.org/Teams/DDP
> 
> I just added you but please discuss with javi how exactly you start
> committing.
> 
> Osamu

Osamu

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

[Pedro MG Palmeiro]

Hi Stuart,
I guess it is related, just moving the mouse will indeed bypass the
"freeze", but there is always some delay (4-5 sec) in which the desktop
will wait. And it does happen on SSD-only laptops: a Bay Trail (Celeron)
and a Ivy Bridge (i3), but not on a Pineview (Atom), this last one has a 32
bit install.

Pedro

Bug#897554: maint-guide: FTBFS: dh_install: missing files, aborting

[Osamu Aoki]

Hi Boyuan Yang,

On Wed, May 02, 2018 at 10:59:48PM +0200, Lucas Nussbaum wrote:
> Source: maint-guide
> Version: 1.2.40
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> >  fakeroot debian/rules binary
> > dh  binary
> >dh_testroot
> >dh_prep
> >dh_auto_install
> >dh_install
> > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-cn.pdf" 
> > (tried in ., debian/tmp)
> > 
> > dh_install: maint-guide-zh-cn missing files: tmp/maint-guide.zh-cn.pdf
> > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-tw.pdf" 
> > (tried in ., debian/tmp)
> > 
> > dh_install: maint-guide-zh-tw missing files: tmp/maint-guide.zh-tw.pdf
> > dh_install: missing files, aborting
> > make: *** [debian/rules:35: binary] Error 25
> 
> The full build log is available from:
>http://aws-logs.debian.net/2018/05/02/maint-guide_1.2.40_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Can you look into this problem?  Is this tool chain problem or missiong
dependency package?

I thought you enabled zh-* build since tool chain is now ready...

Regards,

Osamu

Bug#898068: Message with no Package: tag cannot be processed! ([Deprecated] Methods with the same name as their class on roundcube package :)

[Ph. Gras]

Package: roundcube

> Hi there!
> 
> message on upgrading my server:
> 
> Paramétrage de roundcube-core (1.2.3+dfsg.1-4+deb9u2) ...
> Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
> dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
> dbconfig-common: flushing administrative password
> Package apache2 is not configured yet. Will defer actions by package 
> roundcube-core.
> 
> Deprecated: Methods with the same name as their class will not be 
> constructors in a future version of PHP; runlog has a deprecated constructor 
> in /usr/share/roundcube/plugins/debug_logger/runlog/runlog.php on line 8
> 
> 
> 
> vi /usr/share/roundcube/plugins/debug_logger/runlog/runlog.php
> 
>  1   2 
>  3 /**
>  4  * runlog
>  5  *
>  6  * @author Ziba Scott 
>  7  */
>  8 class runlog {
>  9 
> 10 private $start_time   = FALSE;
> 11 private $parent_stack = array();
> 12 private $file_handles = array();
> 13 private $indent   = 0;
> 14 private $run_log  = array();
> 15 
> 16 public $print_to_console = FALSE;
> 17 public $threshold= 0;
> 18 public $tag_count= array();
> 19 public $timestamp= "d-M-Y H:i:s O";
> 20 public $max_line_size= 150;
> 21 
> 22 //function runlog()
> 23 function __construct()
> 24 {
> 25 $this->start_time = microtime(true);
> 26 }
> 27 
> 
> 
> Best regards,
> 
> Ph. Gras
> 

Bug#898067: Division by zero in microcode loader when booting on EC2 c3.large/r3.large

[Ben Hutchings]

Package: src:linux
Version: 3.16.56-1
Severity: important
Tags: upstream fixed-upstream patch

The following crash at boot was reported to me by someone who has had
trouble submitting it using reportbug:

[0.819406] divide error:  [#1] SMP
[0.821156] Modules linked in:
[0.822474] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-6-amd64 #1 
Debian 3.16.56-1
[0.823392] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
[0.823392] task: 8803de66f2d0 ti: 8803de6c task.ti: 
8803de6c
[0.823392] RIP: 0010:[]  [] 
init_intel_microcode+0x4b/0x5c
[0.823392] RSP: :8803de6c3e60  EFLAGS: 00010206
[0.823392] RAX: 0190 RBX: 8181b040 RCX: 
[0.823392] RDX:  RSI: 000e RDI: 0282
[0.823392] RBP: 8803d07f3180 R08:  R09: 
[0.823392] R10: 8170378c R11: 015b R12: 81923f40
[0.823392] R13:  R14:  R15: 
[0.823392] FS:  () GS:8803e040() 
knlGS:
[0.823392] CS:  0010 DS:  ES:  CR0: 80050033
[0.823392] CR2: 8803e07ff000 CR3: 01812000 CR4: 00160670
[0.823392] Stack:
[0.823392]  81923f6f 0018 8803de6c3ec0 
8803de6c3e80
[0.823392]  ea000d59bd28 8181b040 8803d07f3180 
81923f40
[0.823392]    8181b040 
8100214a
[0.823392] Call Trace:
[0.823392]  [] ? microcode_init+0x2f/0x1b9
[0.823392]  [] ? mtrr_trim_uncached_memory+0x2b4/0x2b4
[0.823392]  [] ? do_one_initcall+0xda/0x210
[0.823392]  [] ? initcall_blacklist+0x6f/0xb2
[0.823392]  [] ? parse_args+0x236/0x4f0
[0.823392]  [] ? kernel_init_freeable+0x189/0x20a
[0.823392]  [] ? rest_init+0x80/0x80
[0.823392]  [] ? kernel_init+0xa/0xf0
[0.823392]  [] ? ret_from_fork+0x6e/0xa0
[0.823392]  [] ? rest_init+0x80/0x80
[0.823392] Code: 00 40 74 14 0f b6 31 48 c7 c7 f8 32 71 81 31 c0 e8 7c e3 
c0 ff 31 c0 c3 8b 81 90 00 00 00 0f b7 89 a8 00 00 00 31 d2 48 c1 e0 0a <48> f7 
f1 89 05 8b e3 12 00 48 c7 c0 e0 d4 82 81 c3 48 c7 c0 40
[0.823392] RIP  [] init_intel_microcode+0x4b/0x5c
[0.823392]  RSP 
[0.913472] ---[ end trace a991ea625763b5ba ]---

AWS support reproduced this on the c3.large and r3.large instance
types, which have 2 CPUs, but not instances with larger numbers of
CPUs.  I couldn't reproduce it with a c2.micro instance (1 CPU).

The crash is apparently in the calc_llc_size_per_core() function
(inlined into init_intel_microcode()), which was added in Linux 4.15
by commit 7e702d17ed13 "x86/microcode/intel: Extend BDW late-loading
further with LLC size check" and backported into 3.16.55.  The
processor last-level-cache size is divided by the number of cores, and
evidently the latter is not detected correctly on these EC2 instance
types.

The microcode loader ought to be completely disabled on virtual
machines since only the hypervisor can update the microcode.  This was
fixed upstream in Linux 4.10 by commit a15a753539ec
"x86/microcode/AMD: Do not load when running on a hypervisor" and
in Linux 4.9.81, so the same regression has not occurred in stretch
or sid.

I intend to fix this by backporting commit a15a753539ec.

Ben.

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

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

Bug#896543: liblwp-authen-negotiate-perl: diff for NMU version 0.08-2.1

[gregor herrmann]

On Sun, 06 May 2018 17:03:05 +0200, Maximilian Wilhelm wrote:

> > I've prepared an NMU for liblwp-authen-negotiate-perl (versioned as 
> > 0.08-2.1) and
> > uploaded it to DELAYED/5. Please feel free to tell me if I
> > should delay it longer.
> Please go ahead! As I'm not a DD/DM I would need a sponsor anyway. :)

Thanks! Rescheduled to 0-day.
 
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
   `-   


signature.asc
Description: Digital Signature