Bug#919145: mailman3: stretch-backports dependencies can not be satisfied with python3-alembic from backports

[Sampo Sorsa]

Package: mailman3
Version: 3.2.0-4~bpo9+1

Dear Maintainer,

The mailman3 dependencies can not be satisfied with python3-alembic from 
stretch-backports:

Package: mailman3
Depends: python3-alembic, python3-sqlalchemy (>= 1.2.3)

Package: python3-alembic
Version: 1.0.0-2~bpo9+1
Depends: python3-sqlalchemy (>= 1.0~), python3-sqlalchemy (<< 1.1)

The python3-sqlalchemy dependency is conflicting. The only way to resolve this 
is to downgrade python3-alembic to stretch version:

Package: python3-alembic
Version: 0.8.8-2
Depends: python3-sqlalchemy (>= 0.7.6)

Perhaps this bug should be filed under python3-alembic to request backports 
upgrade (although buster is 1.0.0-2 too), but I wanted to make both maintainers 
and users of mailman3 aware of the issue. Please refile if necessary.

--
Sampo Sorsa

Bug#919144: wxpython4.0: please package new version 4.0.4

[Carsten Schoenert]

Source: wxpython4.0
Severity: wishlist

Dear Maintainer,

since a few days version 4.0.4 is available for wxpython.
As the freeze for Buster has started just hours ago it would be nice if
Buster could just contain the newest availabe version of wxpython once
Buster will get released.

Please consider packaging this new version so it can get tested enough
before the hard freeze is starting.

Thanks and regards!
Carsten

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

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

Bug#914632: uw-imap: CVE-2018-19518

[Salvatore Bonaccorso]

Hi Magnus,

On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote:
> On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > > CVE-2018-19518[0]:
> > > | University of Washington IMAP Toolkit 2007f on UNIX, as used in
> > > | imap_open() in PHP and other products, launches an rsh command (by
> > > | means of the imap_rimap function in c-client/imap4r1.c and the
> > > | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
> > > | argument injection, 
> > 
> > I'm wondering if anyone would complain if I'd disable RSH (SSH) connections 
> > altogether.
> 
> Full ack, that seems like the most sensible fix.

Any news on this approach, or did you spot any problem with that way?

Regards,
Salvatore

Bug#919057: Qemu GTK display mouse pointer visibility/position problem

[Michael Tokarev]

13.01.2019 0:46, halfdog wrote:

Michael Tokarev writes:

[]

There's no need to explicitly enable gtk/sdl display, it is the
default if the system has all the necessary packages installed
and if X environment is available.


I see. After upgrading the Stretch nonrequired/nonexisting? package
qemu-system-gui was not installed on Buster, so I installed it
manually and forced the qemu call options as sugessted in forum
posts by people having similar issues.


qemu-system-gui is a recommended package. Usually and by default,
apt installs recommended packages. These are not installed only if
you explicitly disable this, by adding APT::Install-Recommends=0
to /etc/apt.conf. But this is explicitly warned against, as you're
now supposed to watch for such "missing" packages for functionality
you might be missing.

Forcing the options is still not needed, as were with the sdl display
before buster. BTW, qemu dropped sdl1 display support completely (the
one used on Debian since the beginning) with 3.0 version iirc.


I guess this might be related to running quite minimalistic window
manager configurations, like mine requiring just ~25MB memory
compared to the multi-100MB full-blown ones. Installing the
"qemu-system-gui" even triggered gtk-base library installation
as thay are not needed by anything else it seems.


No, not installing qemu-system-gui is only related to your apt
configuration, you explicitly told it to stop installing packages
which are recommended.

The large amount of deps for qemu-system-gui is the exact reason
why this whole thing popped out, why this package has been separated
in the first place. Many people use qemu on headless machines, where
no X components are installed at all. These people (rightly) complained
over the years that qemu forces them to install a ton of X support.
Hence once this become possible we separated whole X support into a
separate package. Now with some guest 3D support too, and with other
extra features people asked about but I were unable to enable due to
old sdl1 display on debian which doesn't have this stuff, and due to
larger set of deps for gtk display.

[]
Thank you for the explanation about your window manager behavour.


Do you use USB Tablet device for guest (which syncronizes host and
guest mouse pointer)?


No, it is enabled as all USB features are disabled for security
reasons.


Please try it with -usb -usbdevice tablet to see whenever it fixes
your issues.


Does the same erratic behavour occurs with other vga variants,
like std?


I tried "-vga std" but it seems, that this one is completely broken
when you have a non-standard real-hardware display size and want to
use a guest display covering the full host-hardware-display in
fullscreen mode (no pixel-rot on a quite small "1366x768" display).


Yes that's lovely thing, stdvga only knows about standard VGA
sizes where the key point is that amount of horizontal dots must
be dividable by 8, so each display line ends on whole byte.  I don't
know where this 1366 come from but it was quite often requested
size and it really does not work. It is a nightmare to code this
size in the bios, I've no idea how real hw does that.

BTW, I didn't know about -vga virtio, the first time I come across
it is this your bugreport. And yes this exact thing is done differently
in virtio vga, in a way which is incompatible with old VESA/VGA
interface (in particular there's no BitBLT operations there which
are mandated by VESA standard - that's the main reason why the
horisontal size should be dividable by 8, for bitblt to work right).
Note that -vga std uses a separate video bios code (coming from
seabios project) - this is the code which implements all the video
handling.


With "-vga std" the mouse positioning and display seems to work
both in window and full-screen mode (as far as I can guess from
the reproducible/stable bute quite distorted graphics output).


So it is still distorted...

[]>> Here I don't understand. Are your mobile screen SMALLER than the

guest screen, so that qemu has to scale DOWN?


Yes, it is smaller, when not in full-screen mode: both screens
(real hardware and virutal screen) have exactly the same size.
When not in full screen mode, the top/bottom part of the GTK
window reduces the usable real-screen size about 10%, thus the
guest screen content has to be scaled down by 10$.


Aha. So the real problem is that the menu bar, which is actually
not useful in your configuration, occupes space. There should be
a way to turn it off I guess.

Why -vga std output is distorted in full-screen mode? Because of
the non-standard resolution?  BTW, I have the same screen size
on my laptop, 1366x768.

Thanks!

/mjt

Bug#612993: #612993 debian-faq: FAQ: Please convert SGML to DocBook XML

[Joost van Baal-Ilić]

Hi,

On Thu, Nov 30, 2017 at 11:14:54AM +0100, Joost van Baal-Ilić wrote:
> 
> Yes, we need to finally convert the Debian FAQ from debiandoc to modern 
> DocBook
> XML, so that obsolete debiandoc toolchain can get removed.

See also #870820 debiandoc-sgml  "Time to declare the package obsolete and
start removal campaign?"

Working on this bug #612993 now.

Bye,

Joost

Bug#878066: ganglia-webfrontend: not compatible with PHP 7

[Jochen Hein]

Package: ganglia-webfrontend
Version: 3.6.1-3
Followup-For: Bug #878066

I've just upgraded my Ganglia server to buster. Another needed patch is
https://github.com/ganglia/ganglia-web/commit/13d426bcf66fb0f27d44847154ba2180884edcd6


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

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

Versions of packages ganglia-webfrontend depends on:
ii  apache2 [httpd-cgi] 2.4.37-1
ii  debconf 1.5.69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.0-2
ii  php 2:7.3+69
ii  php-xml 2:7.3+69
ii  php7.3 [php]7.3.0-2
ii  php7.3-xml [php-xml]7.3.0-2
ii  rrdtool 1.7.0-1+b3

Versions of packages ganglia-webfrontend recommends:
ii  gmetad  3.6.0-7+b2
ii  php-gd  2:7.3+69
ii  php7.3-gd [php-gd]  7.3.0-2

ganglia-webfrontend suggests no packages.

-- debconf information excluded

Bug#919046: unattended-upgrades: Uses 25% of CPU time even when offline

[Réczey Bálint]

Hi Gábor,

On Sat, Jan 12, 2019, 15:57 Braun Gábor  Package: unattended-upgrades
> Version: 1.9
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> On my laptop the fan started running unexpectedly.  Starting KDE's
> systemmonitor
> it showed unattended-upgrades using 25% of CPU.  The laptop was offline at
> ths time.
>
>* What outcome did you expect instead?
>
> In my opinion, unattended-ugrades should use minimal system resources as a
> background process.
>

I agree, there is ongoing work on optimizing CPU usage.

I have also doubts that it can do anything useful on an offline system.
>

There is a plan to support offline upgrades and it is already possible to
upgrade most packages offline if they are already downloaded thus I don't
plan making u-u stop early when the system is offline. See: https://
github.com/mvo5/unattended-upgrades/issues/155

Cheers,
Balint


> Best wishes,
>
> Gábor
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
> LANGUAGE=hu:en_US:de (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages unattended-upgrades depends on:
> ii  debconf [debconf-2.0]  1.5.69
> ii  lsb-base   10.2018112800
> ii  lsb-release10.2018112800
> ii  python33.7.1-2
> ii  python3-apt1.7.0
> ii  python3-dbus   1.2.8-2+b2
> ii  python3-distro-info0.20
> ii  ucf3.0038
> ii  xz-utils   5.2.2-1.3
>
> Versions of packages unattended-upgrades recommends:
> ii  anacron 2.3-27
> ii  cron [cron-daemon]  3.0pl1-130
> ii  systemd-sysv239-15
>
> Versions of packages unattended-upgrades suggests:
> ii  bsd-mailx   8.1.2-0.20180807cvs-1
> ii  dma [mail-transport-agent]  0.11-1+b1
> ii  needrestart 3.3-2
> ii  powermgmt-base  1.33
> ii  python3-gi  3.30.4-1
>
> -- debconf information:
>   unattended-upgrades/enable_auto_updates: true
>   unattended-upgrades/origins_pattern:
> "origin=Debian,codename=${distro_codename},label=Debian-Security";
>

Bug#919143: xorg.conf.5: Some formatting and word corrections in the manual

[Bjarni Ingi Gislason]

Package: xserver-xorg-core
Version: 2:1.20.3-1
Severity: minor
Tags: patch

Dear Maintainer,

  see man-pages(7) for a style manual.

--- xorg.conf.5 2018-10-25 18:15:23.0 +
+++ xorg.conf.5.new 2019-01-13 06:12:18.0 +
@@ -14,8 +14,11 @@ than one way, the highest precedence mec
 mechanisms is ordered from highest precedence to lowest. Note that not
 all parameters can be supplied via all methods. The available command
 line options and environment variables (and some defaults) are
-described in the Xserver(1) and
-Xorg(1) manual pages. Most configuration file
+described in the
+.BR Xserver (1)
+and
+.BR Xorg (1)
+manual pages. Most configuration file
 parameters, with their defaults, are described below. Driver and module
 specific configuration parameters are described in the relevant driver
 or module manual page.
@@ -50,11 +53,11 @@ server is started as a normal user:
 .PP
 where
 .I 
-is a relative path (with no \(lq..\(rq components) specified with the
+is a relative path (with no \(lq..\&\(rq components) specified with the
 .B \-config
 command line option,
 .B $XORGCONFIG
-is the relative path (with no \(lq..\(rq components) specified by that
+is the relative path (with no \(lq..\&\(rq components) specified by that
 environment variable, and
 .I 
 is the machine's hostname as reported by
@@ -109,7 +112,7 @@ directories when the server is started a
 .PP
 where
 .I 
-is a relative path (with no \(lq..\(rq components) specified with the
+is a relative path (with no \(lq..\&\(rq components) specified with the
 .B \-configdir
 command line option.
 .PP
@@ -379,7 +382,6 @@ is a number used to order the fontfile F
 .I gscript:pri=60 -> /usr/share/fonts/default/ghostscript
 .I misc:unscaled:pri=10 \-> /usr/share/X11/fonts/misc
 .fi
-.PP
 .RE
 .RE
 .RE
@@ -560,9 +562,14 @@ extension) to connect from another host.
 Default: off.
 .TP 7
 .BI "Option \*qAllowMouseOpenFail\*q  \*q" boolean \*q
-This tells the mousedrv(4) and vmmouse(4)
+This tells the
+.BR mousedrv (4)
+and
+.BR vmmouse (4)
 drivers to not report failure if the mouse device can't be opened/initialised.
-It has no effect on the evdev(4) or other drivers.
+It has no effect on the
+.BR evdev (4)
+or other drivers.
 Default: false.
 .TP 7
 .BI "Option \*qBlankTime\*q  \*q" time \*q
@@ -574,7 +581,7 @@ is in minutes.
 This is equivalent to the Xorg server's
 .B \-s
 flag, and the value can be changed at run\-time with
-.BR xset(1).
+.BR xset (1).
 Default: 10 minutes.
 .TP 7
 .BI "Option \*qStandbyTime\*q  \*q" time \*q
@@ -583,7 +590,7 @@ sets the inactivity timeout for the
 phase of DPMS mode.
 .I time
 is in minutes, and the value can be changed at run\-time with
-.BR xset(1).
+.BR xset (1).
 Default: 10 minutes.
 This is only suitable for VESA DPMS compatible monitors, and may not be
 supported by all video drivers.
@@ -597,7 +604,7 @@ sets the inactivity timeout for the
 phase of DPMS mode.
 .I time
 is in minutes, and the value can be changed at run\-time with
-.BR xset(1).
+.BR xset (1).
 Default: 10 minutes.
 This is only suitable for VESA DPMS compatible monitors, and may not be
 supported by all video drivers.
@@ -611,7 +618,7 @@ sets the inactivity timeout for the
 phase of DPMS mode.
 .I time
 is in minutes, and the value can be changed at run\-time with
-.BR xset(1).
+.BR xset (1).
 Default: 10 minutes.
 This is only suitable for VESA DPMS compatible monitors, and may not be
 supported by all video drivers.
@@ -644,9 +651,9 @@ The default value is
 .BR "typical" ,
 which will setup up a typical subset of
 the GLXFBConfigs provided by the driver as GLX visuals.  Other options are
-.BR "minimal" ,
+.BR minimal ,
 which will set up the minimal set allowed by the GLX specification and
-.BR "all"
+.B all
 which will setup GLX visuals for all GLXFBConfigs.
 .TP 7
 .BI "Option \*qUseDefaultFontPath\*q \*q" boolean \*q
@@ -730,7 +737,7 @@ instruction, the standard name is case-s
 "lib" prefix, or the ".a", ".o", or ".so" suffixes.
 .PP
 The second form of entry is a
-.BR SubSection,
+.BR SubSection ,
 with the subsection name being the module name, and the contents of the
 .B SubSection
 being
@@ -785,7 +792,7 @@ it.
 Entries in this section are listed as Option statements with the name of
 the extension as the first argument, and a boolean value as the second.
 The extension name is case\-sensitive, and matches the form shown in the output
-of \*qXorg -extension ?\*q.
+of \*qXorg \-extension ?\*q.
 .PP
 .RS 7
 Example: the MIT-SHM extension can be disabled with the following entry:
@@ -794,7 +801,7 @@ Example: the MIT-SHM extension can be di
 .nf
 .B "Section \*qExtensions\*q"
 .B "Option \*qMIT-SHM\*q \*qDisable\*q"
-.B "EndSection"
+.B EndSection
 .fi
 .RE
 .RE
@@ -806,7 +813,7 @@ Recent X servers employ HAL or udev back
 and input hotplugging. It is usually not
 necessary to provide
 .B InputDevice
-sections in the xorg.conf if hotplugging is in use (i.e. AutoAddDevices is
+sections in the xorg.conf if 

Bug#912633: Status Update

[Soren Stoutner]

Any idea when the new version that fixes this bug will be released?

-- 
Soren Stoutner
Small Business Tech Solutions
so...@smallbusinesstech.net
623-262-6169

Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start

[Arnaud Rebillout]

Just an update on this bug, as it is in Debian unstable.

I noticed that the bug can't be reproduced on a GNOME/Wayland session. I
can see in the logs that the PA GDM daemon gets killed with SIGTERM. I
don't know enough about Wayland to tell you what happens there. I'm just
surprised because I *think* I bumped into this bug at a time where I was
running GNOME/Wayland, so I'm not sure if there was a change in Wayland,
or if I'm mistaken.

In any case, for those running GNOME/X11, the bug is still there and can
be reproduced.

(choosing between Wayland/X11 is done by editing the file
/etc/gdm3/daemon.conf)

There's an effort to solve that upstream at
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/10,
I just pushed an updated version of a patch.

Thanks,

  Arnaud

Bug#919142: Xorg.1: Some formatting and word corrections in the manual

[Bjarni Ingi Gislason]

Package: xserver-xorg-core
Version: 2:1.20.3-1
Severity: minor
Tags: patch

Dear Maintainer,

  see man-pages(7) for a style guide.

--- Xorg.1  2018-10-25 18:15:23.0 +
+++ Xorg.1.new  2019-01-13 05:09:21.0 +
@@ -3,12 +3,12 @@
 .ds q \N'34'
 .TH Xorg 1 "xorg-server 1.20.3" "X Version 11"
 .SH NAME
-Xorg - X11R7 X server
+Xorg \- X11R7 X server
 .SH SYNOPSIS
 .B Xorg
 .RI [\fB:\fP display ]
 .RI [ option
-.IR ... ]
+.IR \&.\|.\|.\& ]
 .SH DESCRIPTION
 .B Xorg
 is a full featured X server that was originally designed for UNIX and
@@ -33,19 +33,22 @@ free/OpenSource UNIX-like systems such a
 OpenBSD, and Solaris.  Commercial UNIX operating systems such as
 UnixWare are also supported.  Other supported operating systems include
 GNU Hurd.  Mac OS X is supported with the
-Xquartz(1) X server.  Win32/Cygwin is supported with the
-XWin(1) X server.
-.PP
+.BR Xquartz (1)
+X server.  Win32/Cygwin is supported with the
+.BR XWin (1)
+X server.
 .SH "NETWORK CONNECTIONS"
 .B Xorg
 supports connections made using the following reliable
 byte-streams:
 .TP 4
-.I "Local"
+.I Local
 On most platforms, the "Local" connection type is a UNIX-domain socket.
 On some System V platforms, the "local" connection types also include
 STREAMS pipes, named pipes, and some other mechanisms.  See the
-"LOCAL CONNECTIONS" section of X(7) for details.
+"LOCAL CONNECTIONS" section of
+.BR X (7)
+for details.
 .TP 4
 .I TCP/IP
 .B Xorg
@@ -56,12 +59,15 @@ where
 is the display number.  This connection type is usually disabled by default,
 but may be enabled with the
 .B \-listen
-option (see the Xserver(1) man page for details).
+option (see the
+.BR Xserver (1)
+man page for details).
 .SH OPTIONS
 .B Xorg
 supports several mechanisms for supplying/obtaining configuration and
 run-time parameters: command line options, environment variables, the
-xorg.conf(5) configuration files, auto-detection, and
+.BR xorg.conf (5)
+configuration files, auto-detection, and
 fallback defaults.  When the same information is supplied in more than
 one way, the highest precedence mechanism is used.  The list of mechanisms
 is ordered from highest precedence to lowest.  Note that not all parameters
@@ -69,12 +75,14 @@ can be supplied via all methods.  The av
 and environment variables (and some defaults) are described here and in
 the Xserver(1) manual page.  Most configuration file
 parameters, with their defaults, are described in the
-xorg.conf(5) manual page.  Driver and module specific
+.BR xorg.conf (5)
+manual page.  Driver and module specific
 configuration parameters are described in the relevant driver or module
 manual page.
 .PP
 In addition to the normal server options described in the
-Xserver(1) manual page,
+.BR Xserver (1)
+manual page,
 .B Xorg
 accepts the following command line switches:
 .TP 8
@@ -92,14 +100,16 @@ as Linux, BSD, OpenSolaris, SVR3, and SV
 Allow the server to start up even if the mouse device can't be opened
 or initialised.  This is equivalent to the
 .B AllowMouseOpenFail
-xorg.conf(5) file option.
+.BR xorg.conf (5)
+file option.
 .TP 8
 .B \-allowNonLocalXvidtune
 Make the VidMode extension available to remote clients.  This allows
 the xvidtune client to connect from another host.  This is equivalent
 to the
 .B AllowNonLocalXvidtune
-xorg.conf(5) file option.  By default non-local
+.BR xorg.conf (5)
+file option.  By default non-local
 connections are not allowed.
 .TP 8
 .BI \-bgamma " value"
@@ -139,7 +149,9 @@ config directory search path for all oth
 When this option is specified, the
 .B Xorg
 server loads all video driver modules, probes for available hardware,
-and writes out an initial xorg.conf(5) file based on
+and writes out an initial
+.BR xorg.conf (5)
+file based on
 what was detected.  This option currently has some problems on some
 platforms, but in most cases it is a good way to bootstrap the
 configuration process.  This option is only available when the server
@@ -151,7 +163,7 @@ SCO only.  This is the same as the
 option, and is provided for compatibility with the native SCO X server.
 .TP 8
 .BI \-depth " n"
-Sets the default color depth.  Legal values are 1, 4, 8, 15, 16, and
+Sets the default color depth.  Valid values are 1, 4, 8, 15, 16, and
 24.  Not all drivers support all values.
 .TP 8
 .B \-disableVidMode
@@ -159,7 +171,8 @@ Disable the parts of the VidMode extensi
 client) that can be used to change the video modes.  This is equivalent
 to the
 .B DisableVidModeExtension
-xorg.conf(5) file option.
+.BR xorg.conf (5)
+file option.
 .TP 8
 .B \-fbbpp \fIn\fP
 Sets the number of framebuffer bits per pixel.  You should only set this
@@ -168,7 +181,7 @@ value from
 .B \-depth
 above.  Useful if you want to run a depth 24 configuration with a 24
 bpp framebuffer rather than the (possibly default) 32 bpp framebuffer
-(or vice versa).  Legal values are 1, 8, 16, 24, 32.  Not all drivers
+(or vice versa).  Valid values are 1, 8, 16, 24, 32.  Not all drivers
 

Bug#916002: xnbd FTBFS with glibc 2.28

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/glibc-2.28.patch: Fix FTBFS against glibc 2.28.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru xnbd-0.3.0/debian/patches/glibc-2.28.patch 
xnbd-0.3.0/debian/patches/glibc-2.28.patch
--- xnbd-0.3.0/debian/patches/glibc-2.28.patch  1969-12-31 19:00:00.0 
-0500
+++ xnbd-0.3.0/debian/patches/glibc-2.28.patch  2019-01-12 23:33:17.0 
-0500
@@ -0,0 +1,19 @@
+Description: Fix build with glibc 2.28
+Author: Logan Rosen 
+Forwarded: https://bitbucket.org/hirofuchi/xnbd/pull-requests/1
+Last-Update: 2019-01-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/io.h
 b/lib/io.h
+@@ -35,6 +35,10 @@
+ #include 
+ #include 
+ 
++#ifdef __GNU_LIBRARY__
++#include 
++#endif
++
+ 
+ void read_all(int fd, void *buf, size_t len);
+ void write_all(int fd, const void *buf, size_t len);
diff -Nru xnbd-0.3.0/debian/patches/series xnbd-0.3.0/debian/patches/series
--- xnbd-0.3.0/debian/patches/series2013-05-20 10:47:09.0 -0400
+++ xnbd-0.3.0/debian/patches/series2019-01-12 23:32:30.0 -0500
@@ -0,0 +1 @@
+glibc-2.28.patch

Bug#919141: gcc-8-cross: please support binnmu

[YunQiang Su]

Package: src:gcc-8-cross
Version: 24

In this patch, I retrieve the version of current and
compose our local version from changelog.

Then compare these 2 versions, if local is not greater than the version in repo,
then $(error ...)

With this patch, we can support binnmu, or just edit changelog to rebuild.

-- 
YunQiang Su


gcc-8-cross-binnmu.diff
Description: Binary data

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[Jamie Heilman]

This no longer reproduces for me with udev 240-4, my sysvsinit systems
are back to the same behavior as 239-9 leading me to believe #917247
is more #917607 than it is #908796.

Bug#919140: exa.4: Minor corrections of the manual

[Bjarni Ingi Gislason]

Package: xserver-xorg-core
Version: 2:1.20.3-1
Severity: minor
Tags: patch

Dear Maintainer,

  see man-pages(7) for a style guide.

--- exa.4   2018-10-25 18:15:23.0 +
+++ exa.4.new   2019-01-13 04:19:10.0 +
@@ -22,7 +22,8 @@ Disables acceleration of the Composite o
 the Render extension.  Not related to the Composite extension.  Default: No.
 .TP
 .BI "Option \*qEXANoUploadToScreen\*q \*q" boolean \*q
-Disables acceleration of uploading pixmap data to the framebuffer. Default: No.
+Disables acceleration of uploading pixmap data to the framebuffer.
+Default: No.
 .TP
 .BI "Option \*qEXANoDownloadFromScreen\*q \*q" boolean \*q
 Disables acceleration of downloading of pixmap data from the framebuffer.
@@ -37,6 +38,6 @@ may help with specific use cases.  Avail
 \*qgreedy\*q, and \*qsmart\*q.  Default: always.
 .SH "SEE ALSO"
 .BR Xorg (1),
-.BR xorg.conf(5).
+.BR xorg.conf (5).
 .SH AUTHORS
 Authors include: Keith Packard, Eric Anholt, Zack Rusin, and Michel D\(:anzer

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

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

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.188
ii  libaudit1   1:2.8.4-2
ii  libbsd0 0.9.1-1
ii  libc6   2.28-4
ii  libdbus-1-3 1.12.12-1
ii  libdrm2 2.4.95-1
ii  libegl1 1.1.0-1
ii  libegl1-mesa18.2.8-2
ii  libepoxy0   1.5.3-0.1
ii  libgbm1 18.2.8-2
ii  libgcrypt20 1.8.4-4
ii  libgl1  1.1.0-1
ii  libpciaccess0   0.14-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libsystemd0 240-2
ii  libudev1240-2
ii  libunwind8  1.2.1-8
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  udev240-2
ii  xserver-common  2:1.20.3-1

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  18.2.8-2
pn  libpam-systemd   

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
pn  xfonts-scalable  

-- no debconf information

-- 
Bjarni I. Gislason

Bug#919139: cli-common: Invalid maintainer email address

[Scott Kitterman]

Package: cli-common
Version: 0.9+nmu3
Severity: serious
Justification: Policy 3.3

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pkg-cli-common-t...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

A valid maintainer address is required.

Scott K

Bug#905674: parallel citation-begging issue

[Kurt Fitzner]

Hi Rogerio, 

I am writing in support of the recent patch to remove the citation
message from Debian's version of GNU Parallel.  This citation
solicitation is actually quite troubling from an academic perspective,
not just from a licensing standpoint. 

The assertion of Mr. Tange, the upstream author, that "[a]cademic
tradition requires you to cite works you base your article on" is true,
however the active words here are "works" and "base".  In this case,
when writing an article, the nature of the "work" I would base my
article on would be another article.  An academic article (in general)
is not inherently based on the work of the programmer who wrote some of
the software infrastructure used to create or analyze the data.  Mr.
Tange's assertion that mere use of GNU Parallel constitutes a moral
obligation to cite an entry-level self-help tutorial on how to use that
software is an egregious mischaracterization of the academic tradition
Mr. Tange relies on.  Especially, in this case, where the software in
question has nothing to do with data analysis or production, but is a
middleware parallelization job scheduler.  If the article in question is
itself on middleware parallelization job schedulers, that's one thing. 
In virtually every other case the notice is just fishing for something
that is highly inappropriate.  The correct way of mentioning the
software involved is in a footnote, or perhaps in an appendix, when
describing how to replicate the results and analysis.  You include
scripts involved, and the "evidence chain" of the data in such a way. 
This is problematic for Mr. Tange, however, because footnotes are not
tracked.  Citations are.  Which is clearly why he is fishing for them. 

Now, the above isn't Debian's problem.  This is academia's problem. 
What is Debian's problem is what will happen if Mr. Tange convinces
Debian leadership that the citation-begging notice has to be allowed
back in.  Because this will open the flood gates to everyone who wants
the prestige of being cited in an academic journal.  All you have to do
is have a minor article on a piece software, it doesn't have to be an
academic article - just a how to use it will do, published literally
anywhere that is citable, for any software in the processing-chain
commonly used in academia.  Use a shell script, be prepared to have the
Bash authors start putting in citation-begging notices.  Arguably those
that wrote the actual Linux task schedulers and SMP code are just as
worthy of notice as the authors of GNU Parallel.  Or GCC, or PERL, or
Python.  Or how about grep?  If this citation-begging notice gets back
in to Debian, it will become a far larger issue than just whether or not
Mr. Tange is skating on the right side of the GPL/DFSG legalities. 
Debian is going to have to ask the question on whether advertising in a
STDERR message is appropriate at all. 

I would ask you, if and when this comes up for review with the
leadership at Debian, to bring up these issues.  It is my hope that
Debian will see that it is in their best interest to look at a policy
that will exclude this kind of behaviour, before it spreads. 

Thank-you 

Regards, 

  Kurt Fitzner

Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3

[Different55]

Package: wpasupplicant
Version: 2:2.6-21
Severity: important

Dear Maintainer,

Running vanilla Debian Sid on my laptop here. Upgraded last night and when I
woke up in the morning my Wifi had stopped working. It refused to connect to my
home Wifi anymore, although my phone's hotspot still worked fine.

Freshly reinstalled Debian Buster this evening, upgrade back to Sid and the
Wifi failed shortly after the wpa_supplicant package was upgraded to version
2:2.7-3. Downgrading to wpasupplicant back to the version in Buster (2:2.6-21)
returning things to a working state.

I attached some relevant-looking bits from journalctl.



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

Kernel: Linux 4.19.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.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 wpasupplicant depends on:
ii  adduser   3.118
ii  libc6 2.28-4
ii  libdbus-1-3   1.12.12-1
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpcsclite1  1.8.24-1
ii  libreadline7  7.0-5
ii  libssl1.1 1.1.1a-1
ii  lsb-base  10.2018112800

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui




*** /home/diff/NetworkManager.log
Jan 12 20:15:43 Empanada NetworkManager[548]:   [1547345743.8558] device
(wls8): supplicant interface state: disconnected -> scanning
Jan 12 20:15:44 Empanada wpa_supplicant[30551]: wls8: SME: Trying to
authenticate with xx:xx:xx:xx:xx:xx (SSID='Depeche Modem' freq=2442 MHz)
Jan 12 20:15:44 Empanada kernel: wls8: authenticate with xx:xx:xx:xx:xx:xx
Jan 12 20:15:44 Empanada kernel: wls8: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Jan 12 20:15:44 Empanada NetworkManager[548]:   [1547345744.7171] device
(wls8): supplicant interface state: scanning -> authenticating
Jan 12 20:15:44 Empanada wpa_supplicant[30551]: wls8: Trying to associate with
xx:xx:xx:xx:xx:xx (SSID='Depeche Modem' freq=2442 MHz)
Jan 12 20:15:44 Empanada kernel: wls8: authenticated
Jan 12 20:15:44 Empanada kernel: wls8: associate with xx:xx:xx:xx:xx:xx (try
1/3)
Jan 12 20:15:44 Empanada NetworkManager[548]:   [1547345744.7263] device
(wls8): supplicant interface state: authenticating -> associating
Jan 12 20:15:44 Empanada kernel: wls8: RX AssocResp from xx:xx:xx:xx:xx:xx
(capab=0x411 status=30 aid=9)
Jan 12 20:15:44 Empanada kernel: wls8: xx:xx:xx:xx:xx:xx rejected association
temporarily; comeback duration 196 TU (200 ms)
Jan 12 20:15:44 Empanada kernel: wls8: associate with xx:xx:xx:xx:xx:xx (try
2/3)
Jan 12 20:15:44 Empanada kernel: wls8: RX AssocResp from xx:xx:xx:xx:xx:xx
(capab=0x411 status=30 aid=9)
Jan 12 20:15:44 Empanada kernel: wls8: xx:xx:xx:xx:xx:xx rejected association
temporarily; comeback duration 196 TU (200 ms)
Jan 12 20:15:45 Empanada kernel: wls8: associate with xx:xx:xx:xx:xx:xx (try
3/3)
Jan 12 20:15:45 Empanada kernel: wls8: RX AssocResp from xx:xx:xx:xx:xx:xx
(capab=0x411 status=30 aid=9)
Jan 12 20:15:45 Empanada kernel: wls8: xx:xx:xx:xx:xx:xx rejected association
temporarily; comeback duration 196 TU (200 ms)
Jan 12 20:15:45 Empanada kernel: wls8: association with xx:xx:xx:xx:xx:xx timed
out
Jan 12 20:15:45 Empanada NetworkManager[548]:   [1547345745.3751] device
(wls8): supplicant interface state: associating -> disconnected
Jan 12 20:15:46 Empanada NetworkManager[548]:   [1547345746.3754] device
(wls8): supplicant interface state: disconnected -> scanning
Jan 12 20:15:46 Empanada NetworkManager[548]:   [1547345746.6710] dhcp4
(wls8): request timed out
Jan 12 20:15:46 Empanada NetworkManager[548]:   [1547345746.6711] dhcp4
(wls8): state changed unknown -> timeout
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0861] dhcp4
(wls8): canceled DHCP transaction, DHCP client pid 30637
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0862] dhcp4
(wls8): state changed timeout -> done
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0870] device
(wls8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-
iface-state: 'managed')
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0889]
manager: NetworkManager state is now DISCONNECTED
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0911] device
(wls8): Activation: failed for connection 'Depeche Modem'
Jan 12 20:15:47 Empanada NetworkManager[548]:   [1547345747.0914] device
(wls8): state change: failed -> disconnected (reason 'none', sys-iface-state:
'managed')
Jan 12 20:15:47 Empanada avahi-daemon[552]: Withdrawing address record for
fe80::86ef:18ff:fe19:6f68 on wls8.
Jan 12 20:15:47 Empanada avahi-daemon[552]: Leaving mDNS multicast group on
interface wls8.IPv6 with address 

Bug#919137: cvt1: Some adjustments in the man page

[Bjarni Ingi Gislason]

Package: xserver-xorg-core
Version: 2:1.20.3-1
Severity: minor
Tags: patch

Dear Maintainer,

  See man-pages(7) for a style guide.

--- cvt.1   2018-10-25 18:15:23.0 +
+++ cvt.1.new   2019-01-13 02:39:51.0 +
@@ -1,6 +1,6 @@
 .TH CVT 1 "xorg-server 1.20.3" "X Version 11"
 .SH NAME
-cvt - calculate VESA CVT mode lines
+cvt \- calculate VESA CVT mode lines
 .SH SYNOPSIS
 .B cvt
 .RB [ \-v | \-\-verbose ]
@@ -12,15 +12,15 @@ cvt - calculate VESA CVT mode lines
 .I Cvt
 is a utility for calculating VESA Coordinated Video Timing modes.  Given the
 desired horizontal and vertical resolutions, a modeline adhering to the CVT
-standard is printed. This modeline can be included in Xorg
-.B xorg.conf(5)
+standard is printed.
+This modeline can be included in Xorg
+.BR xorg.conf (5).
 .
-
 .SH OPTIONS
 .TP 8
-.BR refresh
-Provide a vertical refresh rate in Hz.  The CVT standard prefers either 50.0,
-60.0, 75.0 or 85.0Hz.  The default is 60.0Hz.
+.B refresh
+Provide a vertical refresh rate in hertz.  The CVT standard prefers either 
50.0,
+60.0, 75.0 or 85.0\ hertz.  The default is 60.0\ hertz.
 .TP 8
 .BR \-v | \-\-verbose
 Warn verbosely when a given mode does not completely correspond with CVT
@@ -28,14 +28,16 @@ standards.
 .TP 8
 .BR \-r | \-\-reduced
 Create a mode with reduced blanking.  This allows for higher frequency signals,
-with a lower or equal dotclock. Not for Cathode Ray Tube based displays though.
-
+with a lower or equal dotclock.
+Not for Cathode Ray Tube based displays though.
+.
 .SH "SEE ALSO"
-xorg.conf(5), gtf(1)
+.BR xorg.conf "(5), " gtf (1)
 .SH AUTHOR
 Luc Verhaegen.
 .PP
 This program is based on the Coordinated Video Timing sample
-implementation written by Graham Loveridge. This file is publicly
-available at . CVT is a
-VESA trademark.
+implementation written by Graham Loveridge.
+This file is publicly available at
+.
+CVT is a VESA trademark.


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

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

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.188
ii  libaudit1   1:2.8.4-2
ii  libbsd0 0.9.1-1
ii  libc6   2.28-4
ii  libdbus-1-3 1.12.12-1
ii  libdrm2 2.4.95-1
ii  libegl1 1.1.0-1
ii  libegl1-mesa18.2.8-2
ii  libepoxy0   1.5.3-0.1
ii  libgbm1 18.2.8-2
ii  libgcrypt20 1.8.4-4
ii  libgl1  1.1.0-1
ii  libpciaccess0   0.14-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libsystemd0 240-2
ii  libudev1240-2
ii  libunwind8  1.2.1-8
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  udev240-2
ii  xserver-common  2:1.20.3-1

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  18.2.8-2
pn  libpam-systemd   

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
pn  xfonts-scalable  

-- no debconf information

-- 
Bjarni I. Gislason

Bug#919136: openldap: restore separate compile and link flags for contrib modules

[Ryan Tandy]

For x32 at least, taking -specs=/usr/share/dpkg/pie-link.specs out of 
the compile command line does seem to be the necessary fix.

Bug#875404: gridengine and java

[Afif Elghraoui]

Control: tag -1 + help

status update on this bug:

I tried to get the build working months ago with the java10 branch on 
Salsa [1]. The current issue is an error when trying to use jemalloc, 
which I've reported upstream [2]. the error is


[java] [java] 
/<>/gridengine-8.1.9+dfsg/source/libs/jgdi/build.xml:495: 
java.lang.UnsatisfiedLinkError?: 
/<>/gridengine-8.1.9+dfsg/source/LINUXAMD64/libdrmaa.so: 
/usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in 
static TLS block


and more details (including the build log) are on the upstream ticket [2].


1. https://salsa.debian.org/hpc-team/gridengine/tree/java10
2. https://arc.liv.ac.uk/trac/SGE/ticket/1642

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#908796: I am facing this bug too

[Aryan Duggal]

https://github.com/systemd/systemd/commit/98aed1d68e13ef44bd844e6347e05faf9385a2ff
fixes it as confirmed by users

Maintainer please have a look

I am able to reproduce this issue on one of my VMs so I can help in testing

My setup is the one generated by the Debian installer (Guided - use entire
disk and set up lvm). I'm not using encryption

Bug#919136: openldap: restore separate compile and link flags for contrib modules

[Ryan Tandy]

Source: openldap
Version: 2.4.47+dfsg-2
Severity: important

In 2.4.47+dfsg-2 I dropped most of the patches to the contrib makefiles. 
Instead I override the provided OPT variable with CFLAGS, CPPFLAGS, and 
LDFLAGS concatenated.

This is not really correct, but seemed to work in my tests. 
Unfortunately it FTBFS on at least ia64 and x32. It looks like those 
architectures use spec files to enable PIE support.

I'm talking to upstream about having these makefiles respect CFLAGS, 
CPPFLAGS, and LDFLAGS. In the mean time, it's probably best to bring 
back the makefile patches.

Bug#918916: Unicorn not reporting proper version for gemfile?

[Julian Calaby]

Package: unicorn
Version: 5.4.1-1
Followup-For: Bug #918916

For reference:

As a workaround, changing _both_ versions in the shipped gemspec and the
version in the filename from 0 to 5.4.1 fixes packages which depend on
this, e.g. gitlab.

Detailed steps:

1. Edit /usr/share/rubygems-integration/2.5.0/specifications/unicorn-0.gemspec
2. On line 2, change 0 to 5.4.1 so it reads: # stub: unicorn 5.4.1 ruby lib
3. On line 7, change 0 to 5.4.1 so it reads:   s.version = "5.4.1"
4. Rename the file to unicorn-5.4.1.gemspec

Thanks,

Julian Calaby

Bug#901296: ping ...

[Roberto C . Sánchez]

On Thu, Oct 04, 2018 at 01:06:33AM +0530, shirish शिरीष wrote:
> Hi Roberto,
> 
> please share your thoughts .
> 

Hi Shirish,

My apologies for the delay.

Right now I am leaning toward following this project as a new upstream:

https://github.com/ValyriaTear/luabind

Please let me know if you have any thoughts on that.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#919135: ERROR:context_group.cc(381)] ContextResult::kFatalFailure: too few texture image units supported (0, should be 8).

[積丹尼 Dan Jacobson]

Package: chromium
Version: 72.0.3626.53-1

Tons of these every page on i386:
[5799:5799:0113/084128.701923:ERROR:context_group.cc(381)] 
ContextResult::kFatalFailure: too few texture image units supported (0, should 
be 8).
Can still browse OK though.

Didn't test amd64.

Doesn't happen with a fresh profile though.

Bug#916606: Possible cause

[bitfreak25]

On Mon, 7 Jan 2019 08:59:30 +0100 Stephen Kitt  wrote:
> On Sat, Jan 05, 2019 at 03:32:02AM -0500, Full Name wrote:
> > A similar problem occurs in DOSBox.  I'm not sure if this is a bug in xorg 
> > or SDL.
> > 
> > What is happening is that when you unpause, lbreakout2 tries to fence the 
> > mouse in its window,
> > but instead the window immediately loses focus causing lbreakout2 to pause 
> > again.  I'm not sure
> > why the mouse lock works the first time, but once it releases it cannot be 
> > regained.
> 
> Yup, this does seem to be the case. This issue was fixed in DOSBox
> with the patch available at
> https://www.dosbox.com/downloads/74-2-events.diff (also included in
> the current DOSBox package in unstable and testing).
> 
> Regards,
> 
> Stephen

Hi,

I've implemented the mentioned fix for DOSBox and it worked. (see added 
diff-file) But I couldn't add the macro from the DOSBox diff, because it 
doesn't work (don't know why). I'm also not very familiar with debian 
packaging, so I expect the diff file wasn't created/applied correctly. But here 
it is.

Kind regards,
bitfreak25
--- lbreakout2-2.6.5.orig/client/game.c	2013-05-03 19:06:20.0 +0200
+++ lbreakout2-2.6.5/client/game.c	2019-01-13 00:21:06.339765000 +0100
@@ -1150,6 +1150,17 @@
 		/* check wether an event occured */
 		button_clicked = key_pressed = 0;
 		if ( SDL_PollEvent(  ) ) {
+			// Special code for broken SDL with Xorg 1.20.1, where pairs of inputfocus gain and loss events are generated
+			// when locking the mouse in windowed mode.
+			if (event.type == SDL_ACTIVEEVENT && event.active.state == SDL_APPINPUTFOCUS && event.active.gain == 0) {
+SDL_Event test; //Check if the next event would undo this one.
+if (SDL_PeepEvents(,1,SDL_PEEKEVENT,SDL_ACTIVEEVENTMASK) == 1 && test.active.state == SDL_APPINPUTFOCUS && test.active.gain == 1) {
+	// Skip both events.
+	SDL_PeepEvents(,1,SDL_GETEVENT,SDL_ACTIVEEVENTMASK);
+	continue;
+}
+			}
+			
 			if ( client_state == CS_PAUSE && game->game_type == GT_NETWORK )
 gui_dispatch_event( , ms );
 			else

Bug#917700: dimbl: FTBFS: build-dependency not installable: libtimbl4-dev

[Steve Langasek]

Package: dimbl
Followup-For: Bug #917700
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hello,

FWIW, no new upstream version is required in order to fix this build
failure, it's a trivial change to debian/control to drop the versioned -dev
package names leaving only the unversioned ones.

I've uploaded the attached patch to Ubuntu to fix the bug there.  But since
there is a comment suggesting that this may not be worth maintaining in
Debian and should be removed, I have not uploaded an NMU.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dimbl-0.15/debian/control dimbl-0.15/debian/control
--- dimbl-0.15/debian/control   2018-01-24 13:15:46.0 +0100
+++ dimbl-0.15/debian/control   2019-01-13 01:27:06.0 +0100
@@ -7,8 +7,8 @@
 Build-Depends: debhelper (>= 11~),
pkg-config,
libxml2-dev,
-   libticcutils2-dev | libticcutils-dev,
-   libtimbl4-dev | libtimbl-dev
+   libticcutils-dev,
+   libtimbl-dev
 Standards-Version: 4.1.3
 Vcs-Browser: https://salsa.debian.org/science-team/dimbl.git
 Vcs-Git: https://salsa.debian.org/science-team/dimbl.git

Bug#919098: libzmq5: remote execution vulnerability

[Luca Boccassi]

On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS)  On Sat, Jan 12, 2019 at 8:33 PM Luca Boccassi  wrote:
> > On Sat, 12 Jan 2019 17:29:23 + Luca Boccassi 
> > wrote:
> > > Sorry, I fat-fingered the patch refresh and the variable name is
> > wrong.
> > > Corrected version attached.
> >
> > Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
> > juggling many emails and bug trackers at the moment...
>  No problem. But I ask for a help with 4.3.1 as one of its tests fail
> on ppc64el architecture [1].
> The minimal log I see:
> "FAIL: tests/test_hwm_pubsub
> ===
>
> Assertion failed: check () (src/msg.cpp:347)
> FAIL tests/test_hwm_pubsub (exit status: 134)"
>
> Can you give me pointers, what to check, how can I help fixing this?
> Other architectures could build it without any problem.
>
> Regards,
> Laszlo/GCS
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=zeromq3=ppc64el=4.3.1-1=1547321006=0


Hi,

I've seen that test fail sometimes on the very very slow windows CI we use
upstream, I've never reproduced it locally or on porter machines or on the
PPC Linux CI we use upstream.
I'd suggest to just try to ask wanna-build for a give back, and it will
most likely pass. If it still fails I'll hop on a porter box tomorrow.

One thing I haven't seen mentioned in the changelog for 4.3.1-1 in Sid - as
I wrote in NEWS, libzmq3-dev should get a dependency on the -dev packages
of the libraries that libzmq5 links against, so that pkgconfig can work, as
we now use Requires.private.

Kind regards,
Luca Boccassi

Bug#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8

[Michael Biebl]

Hi Jussi

On Sun, 2 Dec 2018 00:23:09 +0200 Jussi Pakkanen  wrote:

> The correct way to enable PIE executables with Meson is to remove all
> your own compiler and link flags related to pie and set b_pie to true.
> This is a fairly new feature and probably the reason why systemd is
> not using it.
> 
> If this does not do the right thing then that is a bug in Meson and we
> need to fix it.

I just switched systemd over to use -Db_pie=true in 240-4 [1]
Seems like it still fails on x32 though

Not a super important issue, but I thought I mention it anyway in case
you are interested.

Regards,
Michael

[1]
https://buildd.debian.org/status/fetch.php?pkg=systemd=x32=240-4=1547337999=0

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



signature.asc
Description: OpenPGP digital signature

Bug#919134: python3 missing -fPIE flag

[johnsen32]

Package: python3
Version: 3.7.1-3
Severity: important

Dear Maintainer,

python3 is not compiled as a position independent executeable.

Please use -fPIE when compiling python3 as other distros also do.


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

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

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.7.1-3
ii  python3-minimal3.7.1-3
ii  python3.7  3.7.2-1

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#919133: ITP: python-css-parser -- CSS related utilities (parsing, serialisation, etc) for Python

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: python-css-parser
Version : 1.0.4
Upstream Author : Kovid Goyal (maintainer of fork), Christof Hoeke (orig)
URL : https://github.com/ebook-utils/css-parser
License : LGPL-3.0 and Apache 2.0
Programming Lang: Python
Description : CSS related utilities (parsing, serialization, etc) for Python

CSS parser provides utilities for parsing, serialising CSS in Python.
.
It is a fork of the cssutils-1.0.2, and adds general bug fixes and
extensions specific to editing and working with ebooks.  Other
modifications include Python 2.7+ and 3.x support from the same codebase.

This library is a new requirement for Calibre.  I would like to
maintain it on the DPMT and will soon be joining this team.  Finally,
as I DM I will require a sponsor for the first upload.

Regards,
Nicholas

Bug#918574: Bug 918574: gnome-shell: loops with "failed to bind to /tmp/.X11-unix/X: No such file or directory"

[Simon McVittie]

Control: retitle -1 gnome-shell: loops with "failed to bind to 
/tmp/.X11-unix/X: No such file or directory"

On Sat, 12 Jan 2019 at 13:51:11 +, Robert Stone wrote:
> I'd appreciate somebody looking at this problem as I cannot use my laptop.

Sorry, I don't have any special insight into this problem or why it has
happened to you. It's often not possible for developers to solve a bug
that can't be reproduced on a system under their control.

Yours is the only report I've seen of a similar situation, so this is
probably something specific to your particular system configuration.
I'll try to give some hints about how to narrow this down to something
actionable (either fixing local misconfiguration or finding a bug that can
be fixed), but the Debian bug tracking system is not really a technical
support helpline.

Jason Crain left a message on the bug that might provide some clues:
> The first question that comes to my mind is whether there is something
> that prevents access to /tmp. Whether the filesystem is mounted readonly
> or perhaps something else is preventing write access to /tmp.

Booting the system into a mode that does not attempt to start GNOME might
provide useful information. To do that, select

Advanced options for Debian GNU/Linux
-> Debian GNU/Linux, with Linux [some version] (recovery mode)

from the boot menu, or edit the kernel command line in the boot menu
and add "systemd.unit=multi-user.target" (without the quotes) for a
relatively fully-featured text mode, or "single" (single-user mode)
for the same thing as the "recovery mode" in the menu.

Another way to get a basic command prompt is to tell systemd to boot
in rescue mode or in emergency mode, as described here:
https://www.linuxtechi.com/boot-ubuntu-18-04-debian-9-rescue-emergency-mode/

After you are able to get to a command prompt, you could try installing a
different graphical environment like XFCE, or a different display manager
like xdm, to see whether that one worked any better. However, if there
is something wrong with /tmp on your system then I would expect that all
graphical environments would fail similarly (they all use /tmp/.X11-unix
in the same way).

If /tmp isn't read-only, another possibility is that /tmp/.X11-unix is
a symbolic link to somewhere that doesn't exist. If that's the problem,
deleting it should resolve the situation.

Good luck,
smcv

Bug#919132: RM: libopencolorio1v5 opencolorio-tools python-pyopencolorio [hurd-i386] -- RoQA: uninstallable due to libopenimageio-dev

[Simon Quigley]

Package: ftp.debian.org
Severity: normal

Hello,

These binaries can be removed because a build dependency is
uninstallable, and they are depending on an old yaml-cpp.

Thanks.

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#918260: ruby-protected-attributes: Depends: ruby-activemodel (< 2:5.0) but 2:5.2.0+dfsg-2 is to be installed

[xia boles]

On Fri, 04 Jan 2019 22:00:09 +0200 Adrian Bunk  wrote:
> Source: ruby-protected-attributes
> Version: 1.1.4-2
> Severity: serious
>
> The following packages have unmet dependencies:
>  ruby-protected-attributes : Depends: ruby-activemodel (< 2:5.0) but 
> 2:5.2.0+dfsg-2 is to be installed
>
>
Sent from Mail for Windows 10
Hi, what processor architecture is it?
Otherwise, try installing ruby-activemodel.

Bug#883709: python-rtmidi: build should use librtmidi-dev or drop the dependency

[Nicolas Boulenguez]

Source: python-rtmidi
Version: 1.2.0~rc1-2
Followup-For: Bug #883709

Hello.

My previous suggestions for python-rtmidi were buggy in many respects.
Especially, the build time tests now fail.
The attached patch hopefully fixes all remaining issues.

The problem with tests was introduced by the "patch", so I am using
the same bug log. Reopening it would only cause confusion, though.

I have submitted a patch to rtmidi that should eventually allow
python-rtmidi to use the unpatched rtmidi library. For now, the
python-rtmidi author has good reasons to use a patched version.

I have also changed the upstream version, because the special meaning
of ~ in Debian was confusing uscan and there is no reason for it
anyway.  You have to decide whether to revert this part of my patch,
or rename the orig tarball.

I can prepare an NMU if this helps.

Thanks.
>From 84a98d282897b07d2f5689cadbb25004d2206132 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sat, 5 Jan 2019 17:20:47 +0100
Subject: [PATCH] Fix test. Revert to embedded RtMidi. Debhelper 12.

* Revert to the embedded RtMidi, explain why in README.source.
* Fix upstream version in this changelog (remove ~).
* Switch to debhelper compatibility level 12.
* Add forgotten Rules-Requires-Root: no field.
* Let the run time test check a C call in addition to basic import.
  Prevent the rtmidi subdirectory hiding the installed one.

The upstream tarball must be renamed according to the new version.
---
 debian/README.source  | 11 +++
 debian/changelog  | 12 
 debian/compat |  1 -
 debian/control|  5 +-
 .../build-with-packaged-rtmidi-header.diff| 31 
 debian/patches/series |  2 -
 .../patches/update-for-rtmidi-3.0.0~ds1.diff  | 71 ---
 debian/rules  | 13 +---
 debian/tests/control  |  3 +-
 9 files changed, 30 insertions(+), 119 deletions(-)
 create mode 100644 debian/README.source
 delete mode 100644 debian/compat
 delete mode 100644 debian/patches/build-with-packaged-rtmidi-header.diff
 delete mode 100644 debian/patches/series
 delete mode 100644 debian/patches/update-for-rtmidi-3.0.0~ds1.diff

diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 000..fbf8b92
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,11 @@
+The upstream maintainer recompiles and links statically with RtMidi
+instead of using the packaged librtmidi-dev in order to increase
+RT_SYSEX_BUFFER_SIZE 8192.
+
+He also updates to latest version.
+At the time of this writing, commit
+  5591559e38d11d121c70b5697ec63992d96f4195
+of python-rtmidi picks src/RtMidi.{cpp,h} from commit
+  cadfcf6, between 3.0.0 and next unreleased version.
+
+ -- Nicolas Boulenguez , Sat,  5 Jan 2019 13:14:09 +0100
diff --git a/debian/changelog b/debian/changelog
index 3fc..ab375ff 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+python-rtmidi (1.2.0rc1-3) unstable; urgency=medium
+
+  [ Nicolas Boulenguez ]
+  * Revert to the embedded RtMidi, explain why in README.source.
+  * Fix upstream version in this changelog (remove ~).
+  * Switch to debhelper compatibility level 12.
+  * Add forgotten Rules-Requires-Root: no field.
+  * Let the run time test check a C call in addition to basic import.
+Prevent the rtmidi subdirectory hiding the installed one.
+
+ -- Josue Ortega   Sat, 05 Jan 2019 09:15:49 +0100
+
 python-rtmidi (1.2.0~rc1-2) unstable; urgency=medium
 
   [ Nicolas Boulenguez ]
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index b4de394..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-11
diff --git a/debian/control b/debian/control
index 4fe22c9..81b9b8f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: python-rtmidi
 Section: python
 Priority: optional
 Maintainer: Josue Ortega 
-Build-Depends: debhelper (>=11),
+Build-Depends:
+ debhelper-compat (=12),
  dh-python,
  python3-all,
  python3-all-dev,
@@ -10,10 +11,10 @@ Build-Depends: debhelper (>=11),
  cython3 (>= 0.25.2),
  libasound-dev,
  libjack-dev,
- librtmidi-dev,
  python3-pytest,
  python3-mock
 Standards-Version: 4.3.0
+Rules-Requires-Root: no
 Homepage: http://trac.chrisarndt.de/code/wiki/python-rtmidi
 Vcs-Git: https://salsa.debian.org/debian/python-rtmidi.git
 Vcs-Browser: https://salsa.debian.org/debian/python-rtmidi
diff --git a/debian/patches/build-with-packaged-rtmidi-header.diff b/debian/patches/build-with-packaged-rtmidi-header.diff
deleted file mode 100644
index a4da362..000
--- a/debian/patches/build-with-packaged-rtmidi-header.diff
+++ /dev/null
@@ -1,31 +0,0 @@
-Description: build with packaged librtmidi-dev
- Embedded source copies are generally discouraged.
- More specifically, at the time of this writing:
-  - The two methods below have been removed from rtmidi.
-Python-rtmidi, 

Bug#827832: Sorry, wrong bug number

[Santiago Vila]

severity 827832 serious
retitle 827832 python-pytc: FTBFS: /bin/sh: 3: pythonpython2.7-dbg: not found
thanks

Sorry for the noise, I confused the bug number.
Restoring original info.

Thanks.

Bug#919131: RFS: apt-listbugs/0.1.27

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hi!

I have just finished preparing a new version of the apt-listbugs
package (0.1.27): it is ready to be uploaded to Debian sid.
Could someone please build the package from commit
[eb4d507254f84432405d36a8f563226a4f145522], and sponsor its upload
to unstable?

[eb4d507254f84432405d36a8f563226a4f145522]: 


The changes since the last upload are:

  * fixed "New error message /etc/cron.daily/apt-listbugs: logname: no
login name": enhanced logic to better cope with cases where logname
(or whoami) is not able to determine the user login (or effective)
name (Closes: #917059)
  * bumped Standards-Version to 4.3.0: no changes needed
  * updated Spanish translation, thanks to Jonatan Porras!
  * updated Swedish translation, thanks to Martin Bagge! (Closes: #918001)
  * bumped debhelper compatibility version to 12 by using the new method
based on versioned build-dependency on debhelper-compat: no other
changes needed
  * updated Norwegian Bokmål translation, thanks to Hans Fredrik Nordhaug!


Thanks a lot to anyone who will help!
Bye.

Bug#918751: Investigation results

[Santiago Vila]

severity 918751 minor
retitle 918751 python-shade: Improvement of error message when failing to build 
on small machines (?)
thanks

Sorry, this was my fault.

Here is the reason why it failed for me:

This package (version 1.7.0) used to need 200 MB of RAM to build,
and I was using a small machine (1 GB of RAM) to build it. So far, so
good.

The problem was that the current version (1.30.0) required around 1900 MB
of RAM to build (a lot more than before) while I was still using small
machines to build it.

(You might be wondering why I'm using machines with 1 GB to build
Debian packages: well, around 96.6% of all Debian packages in buster
require 1 GB of RAM or less to build, and machines with 2 GB of RAM
usually cost double the price per-hour).

So no FTBFS problem here. Special thanks to Stewart Ferguson for
actually looking at the build logs.

Now I wonder if the error message in cases like this could be improved
so that it's even more clear that lack of RAM was the problem.
Probably it does not worth the effort, but I leave this to you.

Thanks a lot.

Bug#918751: Investigation results

[Santiago Vila]

severity 827832 minor
retitle 827832 python-shade: Improvement of error message when failing to build 
on small machines (?)
thanks

Sorry, this was my fault.

Here is the reason why it failed for me:

This package (version 1.7.0) used to need 200 MB of RAM to build,
and I was using a small machine (1 GB of RAM) to build it. So far, so
good.

The problem was that the current version (1.30.0) required around 1900 MB
of RAM to build (a lot more than before) while I was still using small
machines to build it.

(You might be wondering why I'm using machines with 1 GB to build
Debian packages: well, around 96.6% of all Debian packages in buster
require 1 GB of RAM or less to build, and machines with 2 GB of RAM
usually cost double the price per-hour).

So no FTBFS problem here. Special thanks to Stewart Ferguson for
actually looking at the build logs.

Now I wonder if the error message in cases like this could be improved
so that it's even more clear that lack of RAM was the problem.
Probably it does not worth the effort, but I leave this to you.

Thanks a lot.

Bug#919117: meson ignores all compiler flags when a --cross-file is given

[Jussi Pakkanen]

On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne  wrote:

> I think this discrepancy is a design bug in Meson. Meson should either
> use environment variables or not. For native compilation, you can simply
> use a native file. Artificially handling things differently just makes
> cross compilation unnecessarily hard.

Using only native and cross files is exactly the thing that we want to
do and are working towards. Sadly it is likely that we will never be
able to get rid of the envvar support. For all the gory details see
for example:

https://github.com/mesonbuild/meson/issues/4664

> That's how debhelper runs it. Yes, your updated debcrossgen fully
> resolves the issue at hand. While the behaviour change persists,
> practically all Debian packages run meson through debhelper and will
> therefore work. Can we get that into unstable soon?

I updated the packaging to have the new debcrossgen script.
Unfortunately the repository is currently broken and pbuilder can not
install all the dependency packages needed to run the test suite so
binary packages can not be built. I have uploaded the packaging to
mentors, feel free to upload it to unstable as you see fit:

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

Bug#906299: vim-conque: patch

[Mike Miller]

Control: tags -1 + patch

I've been using a local build with the attached change to resolve this
dependency bug, in case a tested minimal patch is helpful.

-- 
mike
From c1e60d13b19d309f3bb93fc08baf124b0c99afac Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Sat, 12 Jan 2019 14:55:00 -0800
Subject: [PATCH 1/2] d/control: Add alternative dependency on vim-python3

Closes: #906299

Signed-off-by: Mike Miller 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 954829b66f4d..e14123f667f7 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Homepage: https://code.google.com/p/conque/
 
 Package: vim-conque
 Architecture: all
-Depends: ${python:Depends},${misc:Depends},vim-nox|vim-python
+Depends: ${python:Depends},${misc:Depends},vim-nox|vim-python|vim-python3
 Recommends: vim-addon-manager
 Description: plugin for running interactive commands in a Vim buffer 
  This package provides a Vim plugin which allows interactive programs such as
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#919130: libvirt-daemon: spelling error in control file

[Richard Wurth]

Package: libvirt-daemon
Version: 4.10.0-2
Severity: minor

Dear Maintainer,

In the control file, the long package description says "hypvervisors", it 
should be
"hypervisors"

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.13.1-3+b1
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33-0.2
ii  libc6   2.28-3
ii  libcap-ng0  0.7.9-1+b1
ii  libcurl3-gnutls 7.62.0-1
ii  libdbus-1-3 1.12.12-1
ii  libdevmapper1.02.1  2:1.02.153-2
ii  libfuse22.9.8-2
ii  libgcc1 1:8.2.0-13
ii  libgnutls30 3.6.5-2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-23
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27~rc8-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libudev1240-2
ii  libvirt04.10.0-2
ii  libxenmisc4.11  4.11.1-1
ii  libxenstore3.0  4.11.1-1
ii  libxentoollog1  4.11.1-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-1
ii  qemu-kvm1:3.1+dfsg-2+b1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
pn  libvirt-daemon-system   
pn  numad   

-- no debconf information

Bug#918450: RFS: elpy/1.28.0-1

[Nicholas D Steeves]

Hi Chris,

When you have a minute, would you please sponsor this new upstream
version of Elpy?

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.28.0-1.dsc

Changes since the last upload:

elpy (1.28.0-1) unstable; urgency=medium

  * New upstream version.
  * Rework several sections of README.Debian to be more concise and clear.
  * debian/control: Add "Rules-Requires-Root: no"
  * Update my copyright year range.
  * debian/elpa-test:
- No longer exclude elpy-news-test.el, which was removed upstream.
- Re-enable tests from elpy-promise-wait-test.el now that the Python 3.7
  transition is complete.
  * Declare Standards-Version: 4.3.0. (no additional changes required)

 -- Nicholas D Steeves   Sat, 05 Jan 2019 17:13:12 -0500

elpy (1.26.0-1) unstable; urgency=medium


Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#918751: Investigation results

[Santiago Vila]

owner 918751 sanv...@debian.org
thanks

I believe this problem is not directly related with the number of CPUs.

Will do some additional tests and will probably downgrade this myself
if I confirm my current suspicious.

Thanks.

Bug#919008: python3-pdfminer: should depend on python3-pycryptodome, not recommend python3-crypto

[Daniele Tricoli]

Hello Sean,

On 12/01/2019 17:28, Sean Whitton wrote:
> I think that you need to patch the pdfminer code, then, because it looks
> like it is trying to load pycryptodome, rather than pycrypto.
> 
> OCRmyPDF is currently patched not to use pdfminer at all, but before
> that, I was seeing this:
> 
> spwhitton@develacc:~>ocrmypdf --version
> Traceback (most recent call last):
>   File "/usr/bin/ocrmypdf", line 6, in 
> from pkg_resources import load_entry_point
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3126, in 
> @_call_aside
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3110, in _call_aside
> f(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3139, in _initialize_master_working_set
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 581, in _build_master
> ws.require(__requires__)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 898, in require
> needed = self.resolve(parse_requirements(requirements))
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 784, in resolve
> raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'pycryptodome' distribution was 
> not found and is required by pdfminer.six
> 
> i.e. when OCRmyPDF tries to load pdfminer.six, pdfminer.six tries to
> load pycryptodome.
> 
> Let me know what you decide to do, as it might be possible to reenable
> pdfminer.six in OCRmyPDF.

Thanks for spotting this, I patched pdfminer and removed pycryptodome from
install_require, since it's not used, and it's not really required.

Just uploaded the new revision, now pgk_resource seems is fine:

>>> import pkg_resources
>>> pkg_resources.require(['pdfminer.six'])
[pdfminer.six 20181108 (/usr/lib/python3/dist-packages)]

Kind regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#919117: meson ignores all compiler flags when a --cross-file is given

[Helmut Grohne]

Hi Jussi,

Thank your for the quick reply.

On Sat, Jan 12, 2019 at 11:10:36PM +0200, Jussi Pakkanen wrote:
> This is not really a bug in Meson, it is how things should work by
> design. All arguments used for cross compilation come from the cross
> file only. Envvars are not used for cross compilation, only native
> compilation.

I think this discrepancy is a design bug in Meson. Meson should either
use environment variables or not. For native compilation, you can simply
use a native file. Artificially handling things differently just makes
cross compilation unnecessarily hard.

I also find either way reasonable. It just happens that Meson used to
allow environment variables for cross compilation and it still says that
they are being used (which is at least confusing). So it is a bug in so
far as it is a behaviour change that breaks reverse dependencies.

I do agree with the general approach of supplying all arguments from the
cross file. Just extend it to native compilation.

> I have attached an updated version of the debcrossgen script that
> reads the envvars and puts them in the cross file in the proper form.
> Can you test if it fixes the issue for you? Note that the script must
> be run in the build environment so that CPPFLAGS and all the rest of
> the envvars are set to the values used in the final compilation.

That's how debhelper runs it. Yes, your updated debcrossgen fully
resolves the issue at hand. While the behaviour change persists,
practically all Debian packages run meson through debhelper and will
therefore work. Can we get that into unstable soon?

Helmut

Bug#919129: RM: ido -- RoQA; superseded by ayatana-ido

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

ido is superseded by ayatana-ido, see #895039
all rdepends have been switched over


Andreas

Bug#919057: Qemu GTK display mouse pointer visibility/position problem

[halfdog]

Michael Tokarev writes:
> 12.01.2019 14:51, halfdog wrote:
> > Package: qemu-system-gui
> > Version: 1:3.1+dfsg-2
> > 
> > After upgrading from Debian Stretch to Buster, thus changing
> > the qemu version on host, "-display gtk" has to be used instead
> > of "sdl" as the later is not available with Buster any more.
>
> There's no need to explicitly enable gtk/sdl display, it is the
> default if the system has all the necessary packages installed
> and if X environment is available.

I see. After upgrading the Stretch nonrequired/nonexisting? package
qemu-system-gui was not installed on Buster, so I installed it
manually and forced the qemu call options as sugessted in forum
posts by people having similar issues.

I guess this might be related to running quite minimalistic window
manager configurations, like mine requiring just ~25MB memory
compared to the multi-100MB full-blown ones. Installing the
"qemu-system-gui" even triggered gtk-base library installation
as thay are not needed by anything else it seems.

> > Since that switch the mouse behaviour changed, making guest machines
> > (also Debian Buster) very hard to use. I do not know the old
> > Stretch behaviour with "gtk" interface as I never used it.
>
> I don't remember already if gtk interface has been available in
> stretch, I think I tried to switch to gtk but rolled it back at
> some time. In previous version of qemu as has been available in
> Debian (in buster), gtk interface had a lot of issues (that's why
> I had to revert back to sdl, and did that at least twice).
>
> Current 3.1 gtk is quite stable finally, and it is the default
> upstream too.

That's why, I would like to switch so that the old sdl stuff can
be abandoned to save open source developers time. But therefore
I have to get it working beforehand.

> > Reproduce: Run a qemu instance with "-vga virtio" and "-display
> > gtk". Maybe the window manager is relevant also, using fvwm2
> > with an EdgeScroll configuration on host/guest shows the problematic
> > behaviour. There are no specific guest additions installed in
> > the guest nor acceleration in place.
>
> So guest is linux too? What's "EdgeScroll"?

That is a window manager behaviour, where you let's say have 9
virtual desktops (3x3) and each one can hold windows. By moving
the mouse on screen (1,1) to the right edige of the desktop, the
window manager will switch to screen (1,2). Also the mouse pointer
placement is adjusted, e.g. assuming a 800x600 screen, visible mouse
position would change e.g. (300,580) -> (310,599) -> (315,5).

> Do you use USB Tablet device for guest (which syncronizes host and
> guest mouse pointer)?

No, it is enabled as all USB features are disabled for security
reasons.

> Does the same erratic behavour occurs with other vga variants,
> like std?

I tried "-vga std" but it seems, that this one is completely broken
when you have a non-standard real-hardware display size and want to
use a guest display covering the full host-hardware-display in
fullscreen mode (no pixel-rot on a quite small "1366x768" display).

With "-vga std" the mouse positioning and display seems to work
both in window and full-screen mode (as far as I can guess from
the reproducible/stable bute quite distorted graphics output).

> > Following options exist for still using the mouse/vm:
> > 
> > a) Using "Grab input" and "fullscreen", the mouse position is
> > correct, but one cannot see any guest mouse pointer. Only changes
> > in hilighting or menu popups (when clicking) indicate the current
> > mouse position.
> > 
> > b) Using "fullscreen" and then "grab input" does show the mouse
> > pointer but mouse position near the screen edge is not submitted
> > to the guest, those events seem to be consumed on host before that.
> > Thus those mouse positions cannot be reached in the guest window.
> > 
> > c) Not using fullscreen: fonts are harder to read due to scaling
> > on quite small mobile display (that's why the fullscreen preference
> > to avoid pixel-rot). The mouse pointer is shown and edge detection
> > would work theoretically, but it usually should happen in some
> > undistinguishable area where the guest-screen-background color
> > changes to the same color gtk-window-background, thus it is very
> > hard to hit it with the pointer.
>
> Here I don't understand. Are your mobile screen SMALLER than the
> guest screen, so that qemu has to scale DOWN?

Yes, it is smaller, when not in full-screen mode: both screens
(real hardware and virutal screen) have exactly the same size.
When not in full screen mode, the top/bottom part of the GTK
window reduces the usable real-screen size about 10%, thus the
guest screen content has to be scaled down by 10$.

> ...

Thanks for your great committment to Debian package quality!

hd

Bug#919128: buildbot: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: buildbot
Version: 1.7.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for buildbot's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


buildbot_1.7.0-2_pt.po.gz
Description: application/gzip

Bug#919081: kio-gdrive: Unable to create io-slave. klauncher said: error loading gdrive.so

[Benoît Merlet]

Hi again !


Would you please confirm the following:

a) Have you tried logging out and logging back in?


No, I did not, and I should have: error is now gone.

I am sorry for the trouble.

Thanks a lot,
Benoît

Bug#919108: wbar: segfaults sometimes, undetermined conditions

[Pavel Kreuzt]

Here is the result of the BT:

(gdb) bt
#0  0xda15 in std::_List_iterator::operator--
(this=0x55568500 ) at /usr/include/c++/8/bits/stl_list.h:239
#1  mapIcons () at ../src/core/Main.cc:443
#2  0xaaad in main (argc=, argv=0x555a2630)
at ../src/core/Main.cc:393


On Sat, Jan 12, 2019 at 8:20 PM Markus Koschany  wrote:

> Hello,
>
> Am 12.01.19 um 20:24 schrieb Pavel Kreuzt:
> > Package: wbar
> > Version: 2.3.4-9
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Running wbar in an openbox session with compton as WM, it segfaults
> sometimes with this message on syslog:
> >
> > Jan 12 20:18:18 Desktop kernel: [10939.231130] traps: wbar[22728]
> general protection ip:556fe0222a15 sp:7ffd0b9ffc50 error:0 in
> wbar[556fe021d000+b000]
> >
> > I'm not sure what triggers the fault, but seems related to compton
> effects, it happens when spawning or closing a window.
>
> Thanks for the report. In order to debug this bug I need a backtrace.
> Please install wbar-dbgsym and use gdb when you have found a way to
> reproduce this issue. This page provides some basic tips:
>
> https://wiki.debian.org/HowToGetABacktrace
>
> Thanks,
>
> Markus
>
>

Bug#919127: RFS: kio-gdrive/1.2.5+fixedtarball-1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a bugfix release of Debian's
"kio-gdrive" (my package).

Adam, I've CCed you since you sponsored the last upload and reported the 
missing translations, in the hopes that you might also sponsor this fixed 
version.

Package name: kio-gdrive
Version : 1.2.5+fixedtarball-1

It builds this binary package:

  kio-gdrive - KIO access for GDrive

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

  https://mentors.debian.net/package/kio-gdrive

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

dget -x 
https://mentors.debian.net/debian/pool/main/k/kio-gdrive/kio-gdrive_1.2.5+fixedtarball-1.dsc


Changes since the last upload:

kio-gdrive (1.2.5+fixedtarball-1) unstable; urgency=medium

  * Restore missing translations. (Closes: #915496)
- Previous release was accidentally built from git tag rather than from
  upstream tarball.  This release uses the correct orig tarball.
  * Add dversionmangle to watch file.
  * Declare Standards-Version: 4.3.0. (No additional changes needed)

 -- Nicholas D Steeves   Sat, 12 Jan 2019 14:15:46 -0700

kio-gdrive (1.2.5-1) unstable; urgency=medium


Regards,
Nicholas

Bug#919126: goobox: [INTL:pt] Portuguese translation of manpage

[Américo Monteiro]

Package: goobox
Version: 3ags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  goobox manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro




goobox_3.5.1-1_pt.po.gz
Description: application/gzip

Bug#885742: linsmith: GTK+ 3 / GooCanvas port may be available upstream

[Yavor Doganov]

On Wed, 09 Jan 2019 07:24:00 +0200,
Jeremy Bicha wrote:
> We'd like to remove those libraries soon, but I am willing to wait a
> bit longer for someone to port linsmith to gtk3.

JFTR, I don't intend to work on this package.  I don't have time at
the moment, but more importantly I don't have the motivation, knowing
in advance that this is already fixed upstream.

(I spent good few days working on rasmol, glaring at those molecules
and fighting with ancient code, and the reward was that my work ended
up in the trashcan only because the maintainer didn't bother to write
one or two lines informing people that the issue is fixed upstream.  I
knew my patch was suboptimal but it still leaves a bitter taste in my
mouth -- I could have spent these days working on something else.)

Bug#918820: msmtp: AppArmor profile makes passwordeval unusable

[Simon Deziel]

The updated Apparmor profile and debian/NEWS were proposed for
integration: https://salsa.debian.org/kolter/msmtp/merge_requests/1

Regards,
Simon

Bug#919125: ubuntu-dev-tools: fakesyncs using syncpackage puts -proposed in the changelog

[Simon Quigley]

Package: ubuntu-dev-tools
Version: 0.166

Dear Maintainer,

Doing a fakesync using syncpackage puts e.g. disco-proposed in the
changelog instead of disco. I suspect this is historical; the archive
can now handle putting just disco.

Any objections to changing this?

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#741464: grub-pc-bin: hangs after displaying boot menu

[Jeroen Dekkers]

Control: tag -1 +patch

On Mon, 29 Oct 2018 00:36:00 +0100,
Colin Watson wrote:
> 
> On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote:
> > I see this same at_keyboard behaviour: working in VirtualBox, delivering 
> > garbage on this real hardware:
> >  - an HP Proliant DL380 Gen5 machine
> >  - with a Compaq PS/2 keyboard italian layout attached
> >  - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, 
> > containing a keyboard layout file made with
> >   ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb
> [...]
> > Having read
> > 
> > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html
> > it is obvious what's going on: at_keyboard is using scankey set 1 but the 
> > keyboard is using set 2 and the keyboard controller is not translating.
> 
> Sorry for the long delay.  Are you still in a position to test this?
> 
> I just ran across this upstream commit:
> 
>   
> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095
> 
> Ignoring the specific hardware mentioned here, it seems like this could
> be a plausible cause: if GRUB manages to get out of sync with the
> keyboard controller on the command/data sequence, then it could easily
> end up confused about which is the current scan code set (see the
> changes to query_mode in particular) and so end up using the wrong set,
> or possibly even send a nonsense command somehow.  It seems worth
> testing if you can.

I cherry-picked that commit and tested it but it didn't fix the
problem.

The bug was introduced somewhere between GRUB 2.00 and 2.02 so I used
git bisect to find the commit that introduced the bug:

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0c62a5b28e2783d84d266341c4388b494e058114

As far as I understand the change it will no longer poll forever in
the module init when the keyboard controller isn't ready. The problem
seems to be that we used to initialize the keyboard controller in the
module init but now we always do it later when getkey is
called. Somehow this messes up things but I have no idea why.

I changed it so that it only initializes the keyboard controller when
it is ready and doesn't poll when it isn't. Here is the merge request:

https://salsa.debian.org/grub-team/grub/merge_requests/6

I've tested this on my old laptop (X200s thinkpad) and the problem
goes away with this patch.

Kind regards,

Jeroen Dekkers

Bug#918439: cockpit: FTBFS (failing tests)

[Santiago Vila]

On Sat, Jan 12, 2019 at 09:41:49PM +0100, Andreas Henriksson wrote:

> It might be a good idea to first just test if all problems vanishes
> if builting in a less network restricted environment, [...]

I guess not, because I'm using plain sbuild on a stretch machine,
which AFAIK does not have (by default) network restrictions.

For completeness, I've put a bunch of my build logs here:

https://people.debian.org/~sanvila/build-logs/cockpit/

Also, this started to happen quite recently. This is my build history
for buster:

Status: successful  cockpit_183-1_amd64-20181201T044648Z
Status: successful  cockpit_183-1_amd64-20181210T093126.625Z
Status: successful  cockpit_184-1_amd64-20181216T140526.278Z
Status: successful  cockpit_184-1_amd64-20181226T121643.534Z
Status: failed  cockpit_184-1_amd64-20190105T051830.660Z
Status: failed  cockpit_184-1_amd64-20190112T210843.011Z
Status: failed  cockpit_184-1_amd64-20190112T210843.654Z
Status: failed  cockpit_184-1_amd64-20190112T210842.534Z
Status: failed  cockpit_184-1_amd64-20190112T210841.999Z

Note: I believe this FTBFS problem is "general", but if for whatever
reason you can't reproduce it, please contact me privately, I could
offer ssh access to a machine where this happens all the time.

Thanks.

Bug#919124: [INTL:da] Danish translation of the template deborphan

[Joe Dalton]

Package: deborphan
Severity: wishlist
Tags: l10n patch

Please include the attached Danish deborphan translation

joe@debianbuster:~/over/debianp/deborphan$ msgfmt --statistics -c -v -o 
/dev/null da.po
da.po: 70 oversatte tekster.

bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#899530: gnome-phone-manager: diff for NMU version 0.69-2.1

[Adrian Bunk]

Control: tags 899530 + patch
Control: tags 899530 + pending

Dear maintainer,

I've prepared an NMU for gnome-phone-manager (versioned as 0.69-2.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it.

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

diff -Nru gnome-phone-manager-0.69/debian/changelog gnome-phone-manager-0.69/debian/changelog
--- gnome-phone-manager-0.69/debian/changelog	2014-07-17 04:33:45.0 +0300
+++ gnome-phone-manager-0.69/debian/changelog	2019-01-12 23:05:31.0 +0200
@@ -1,3 +1,10 @@
+gnome-phone-manager (0.69-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Maintainer: to the new address. (Closes: #899530)
+
+ -- Adrian Bunk   Sat, 12 Jan 2019 23:05:31 +0200
+
 gnome-phone-manager (0.69-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru gnome-phone-manager-0.69/debian/control gnome-phone-manager-0.69/debian/control
--- gnome-phone-manager-0.69/debian/control	2014-07-17 03:35:14.0 +0300
+++ gnome-phone-manager-0.69/debian/control	2019-01-12 23:05:31.0 +0200
@@ -1,7 +1,7 @@
 Source: gnome-phone-manager
 Section: gnome
 Priority: extra
-Maintainer: Debian Bluetooth Maintainers 
+Maintainer: Debian Bluetooth Maintainers 
 Uploaders: Francesco Namuri , Geert Stappers , Filippo Giunchedi 
 Build-Depends: cdbs,
  debhelper (>= 5), 

Bug#919123: I have to add the ":i386" by hand for dlocate expansions

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-5

I have to add the ":i386" by hand.

$ dlocate -l curl
ii  curl  7.62.0-1:i386 command line tool for 
transferring data with URL syntax
un  libcurl3  : (no description available)
ii  libcurl3-gnutls:i386  7.62.0-1:i386 easy-to-use client-side URL 
transfer library (GnuTLS flavour)
un  libcurl4-gnutls-dev   : (no description available)
ii  libcurl4:i386 7.62.0-1:i386 easy-to-use client-side URL 
transfer library (OpenSSL flavour)
ii  libwww-curl-perl  4.17-5:i386   Perl bindings to libcurl
ii  python3-pycurl7.43.0.2-0.1:i386 Python bindings to libcurl 
(Python 3)
un  python3-pycurl-dbg: (no description available)
$ dlocate -L libcurl
libcurl3-gnutls  libcurl4
$ dlocate -L libcurl4
Package libcurl4 is not installed or /var/lib/dpkg/info/libcurl4.list is empty.
$ dlocate -L libcurl4:i386
/.
/usr
/usr/lib...

Bug#918998: libical3: Apply changes from Ubuntu

[Nicolas Mora]

Le 19-01-12 à 10 h 17, Jeremy Bicha a écrit :
> 
> Ok, please grant my account ( jbicha ) owner privileges for your repo
> so I can do the move.
> 
Done

Bug#919122: Extra blank line upon error messages

[積丹尼 Dan Jacobson]

Package: dlocate
Version: 1.07+nmu1
Severity: minor

See the extra blank line added to error messages:

$ dlocate -L $RANDOM
Package 1467 is not installed or /var/lib/dpkg/info/1467.list is empty.

$

Bug#919117: meson ignores all compiler flags when a --cross-file is given

[Jussi Pakkanen]

On Sat, Jan 12, 2019 at 10:27 PM Helmut Grohne  wrote:

> We ask meson to include -DDEFINED_VIA_CFLAGS via the CFLAGS environment
> variable and it says that it is appending the flag. However, when
> running ninja, we see that the flag goes missing. When dropping the
> --cross-file flag, the flag is correctly propagated. I fact, all
> environment flags (LDFLAGS, CPPFLAGS, ...) go missing.

This is not really a bug in Meson, it is how things should work by
design. All arguments used for cross compilation come from the cross
file only. Envvars are not used for cross compilation, only native
compilation.

I have attached an updated version of the debcrossgen script that
reads the envvars and puts them in the cross file in the proper form.
Can you test if it fixes the issue for you? Note that the script must
be run in the build environment so that CPPFLAGS and all the rest of
the envvars are set to the values used in the final compilation.


debcrossgen
Description: Binary data

Bug#873016: [Pkg-javascript-devel] Bug#873016: node-lodash-packages: not preferred form for source: Should be built from node-lodash

[Jonas Smedegaard]

Quoting Ivo De Decker (2019-01-12 17:18:02)
> On Wed, Aug 23, 2017 at 11:41:28PM +0530, Pirate Praveen wrote:
> > On ബുധന്‍ 23 ആഗസ്റ്റ് 2017 11:33 വൈകു, Jonas Smedegaard wrote:
> > > Package: node-lodash-packages
> > > Severity: serious
> > > Justification: Policy 2.1
> > 
> > I do not think the root issue is serious, but only important.
> > 
> > > The source package node-lodash-packages does not contain the 
> > > source form preferred for editing by upstream.  Instead, upstream 
> > > documents how the contents of that code is generated from the 
> > > sources included in Debian in the source package node-lodash.
> > 
> > Adding a build dependency on node-lodash would be enough for the 
> > policy requirement.
> 
> No it wouldn't. You need to actually generate the code instead of 
> shipping the pregenerated code from upstream. Not doing that is a 
> serious bug. If you think this is easy to fix, please do so. If not, 
> this package should be removed from testing.

Relevant part of Debian Policy §2.1:

  The program must include source code

Build-depending on another package while using prebuilt code is 
argually permitted (but then discourage in other sections, with less 
strong words than "must"), but only if ensuring that in fact the 
distributed code was once built from this exact version of code in the 
build-depended on package.

I find it disgusting that you try find loopholes in policy, Praveen, 
instead of following the spirit of Debian Policy which is to distribute 
source, and build only from that distributed source (avoid distributing 
pre-built/pre-miified/pre-whatever code).

Please fix this properly!


 - Jonas

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

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


signature.asc
Description: signature

Bug#919057: Qemu GTK display mouse pointer visibility/position problem

[Michael Tokarev]

12.01.2019 14:51, halfdog wrote:

Package: qemu-system-gui
Version: 1:3.1+dfsg-2

After upgrading from Debian Stretch to Buster, thus changing
the qemu version on host, "-display gtk" has to be used instead
of "sdl" as the later is not available with Buster any more.


There's no need to explicitly enable gtk/sdl display, it is the
default if the system has all the necessary packages installed
and if X environment is available.


Since that switch the mouse behaviour changed, making guest machines
(also Debian Buster) very hard to use. I do not know the old
Stretch behaviour with "gtk" interface as I never used it.


I don't remember already if gtk interface has been available in
stretch, I think I tried to switch to gtk but rolled it back at
some time. In previous version of qemu as has been available in
Debian (in buster), gtk interface had a lot of issues (that's why
I had to revert back to sdl, and did that at least twice).

Current 3.1 gtk is quite stable finally, and it is the default
upstream too.


Reproduce: Run a qemu instance with "-vga virtio" and "-display
gtk". Maybe the window manager is relevant also, using fvwm2
with an EdgeScroll configuration on host/guest shows the problematic
behaviour. There are no specific guest additions installed in
the guest nor acceleration in place.


So guest is linux too? What's "EdgeScroll"?

Do you use USB Tablet device for guest (which syncronizes host and
guest mouse pointer)?

Does the same erratic behavour occurs with other vga variants,
like std?


Following options exist for still using the mouse/vm:

a) Using "Grab input" and "fullscreen", the mouse position is
correct, but one cannot see any guest mouse pointer. Only changes
in hilighting or menu popups (when clicking) indicate the current
mouse position.

b) Using "fullscreen" and then "grab input" does show the mouse
pointer but mouse position near the screen edge is not submitted
to the guest, those events seem to be consumed on host before that.
Thus those mouse positions cannot be reached in the guest window.

c) Not using fullscreen: fonts are harder to read due to scaling
on quite small mobile display (that's why the fullscreen preference
to avoid pixel-rot). The mouse pointer is shown and edge detection
would work theoretically, but it usually should happen in some
undistinguishable area where the guest-screen-background color
changes to the same color gtk-window-background, thus it is very
hard to hit it with the pointer.


Here I don't understand. Are your mobile screen SMALLER than the
guest screen, so that qemu has to scale DOWN?


So essentially one can decide beween working mouse cursor display
or working mouse pointer position, but you cannot have both. The
current workaround is to switch between a) and b) requiring 8
multi-key strokes and one mouse gesture instead of having just
to move the mouse pointer to the edge of the screen (old behaviour
with sdl).


Thanks,

/mjt

Bug#919121: RM: yaml-cpp -- NBS; packages superseded during transition

[Simon Quigley]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove libyaml-cpp0.5d1 and libyaml-cpp0.5v5 from unstable on all
arches. Both of these packages were superseded by libyaml-cpp0.6 during
this most recent transition and are no longer built.

Thanks.

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#907015: [Pkg-openssl-devel] Bug#907015: marked as done (openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed)

[Sebastian Andrzej Siewior]

On 2019-01-12 15:51:03 [+], Debian Bug Tracking System wrote:
> Paul just told me this should be ok now, so closing.

Okay. We have one additional breaks in git. If anyone needs more, I
don't mind adding them later if it helps…

> Ivo

Sebastian

Bug#917199: pivy, unbuildable on mips* due to testsuite failures in patchelf.

[Adrian Bunk]

Control: reassign -1 src:pyside2
Control: retitle -1 pyside2 should build without patchelf also on mips+mipsel
Control: affects -1 src:pivy

On Sun, Dec 23, 2018 at 11:47:26PM +, peter green wrote:
> Package: pivy
> Version: 0.6.4-1
> Severity: serious
> 
> pivy cannot be built on mips/mipsel because of a depedency on pyside2 which 
> is not built on mips/mipsel pyside2 is not being built on those architectures 
> due to a dependency on patchelf. patchelf is not currently building on mips* 
> due to a testsuite failure.
> 
> mips64el also looks like it will become a problem going forward as patchelf 
> is not currently available there (but was at the time pyside2 was last built).
> 
> Possible solutions (in roughly descending order of preference):
> 
> 1. Fix the patchelf testsuite failures.
> 2. Break the dependency chain (only possible if the functionality in question 
> is optional, I have not researched that).
>...

pyside2 is now built without patchelf on mips64el.

Doing the same for mips and mipsel should fix the problem for pivy.

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#907277: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8

[Chaim Zax]

Hi, autoconf developers, Debian gcc maintainers,

In Debian there is a bug [1] reported on the autoconf package which
relates to a change in gcc 8. After looking into the issue it's not
completely clear to me what the best solution should be.

The autoconf function AC_SEARCH_LIBS check the availability of a
specific library by generating and compiling a small c++ program. From
gcc version 8 on this seems to fail for some libraries (e.g. atomic),
but not all (we haven't seen major fallout so far).

To reproduce this issue the following configure.ac script can be used:

$ cat configure.ac
AC_INIT
AC_PROG_CXX
AC_LANG([C++])
AC_SEARCH_LIBS([__atomic_load_8],[atomic])

$ autoconf


When configured (build) with g++ 7 the result is correct, as expected:

$ CXX=g++-7 ./configure
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-7 accepts -g... yes
checking for library containing __atomic_load_8... -latomic


But when configured (build) with g++ 8 the atomic library is not found:

$ CXX=g++-8 ./configure
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-8 accepts -g... yes
checking for library containing __atomic_load_8... no


The c++ file generated is:

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char __atomic_load_8 ();
int
main ()
{
return __atomic_load_8 ();
  ;
  return 0;
}


When compiled with g++ 7 it only gives a warning, the function arguments
of '__atomic_load_8' are missing:

$ g++-7 -o conftest -g -O2   test.cpp -latomic
test.cpp:16:6: warning: new declaration ‘char __atomic_load_8()’
ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
volatile void*, int)’ [-Wbuiltin-declaration-mismatch]
 char __atomic_load_8 ();
  ^~~


When compiled with g++ 8 it fails with an compilation error, the missing
arguments are now resulting in an error:

$ g++-8 -o conftest -g -O2   test.cpp -latomic
test.cpp:16:6: error: new declaration ‘char __atomic_load_8()’
ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
volatile void*, int)’ [-fpermissive]
 char __atomic_load_8 ();
  ^~~
test.cpp: In function ‘int main()’:
test.cpp:20:25: error: too few arguments to function ‘long unsigned int
__atomic_load_8(const volatile void*, int)’
 return __atomic_load_8 ();


This error is interpreted by autoconf, which concludes the library is
not available. When the generated c++ file is changed to use a different
function from different library (e.g. the 'exp' function from 'libm')
the file [2] does compile with c++ 8.

$ g++-8 -o conftest -g -O2   exp.cpp -latomic
exp.cpp:16:6: warning: declaration of ‘char exp()’ conflicts with
built-in declaration ‘double exp(double)’ [-Wbuiltin-declaration-mismatch]
 char exp();
  ^~~


To know the impact of this bug on other Debian packages it's important
to know when g++ will produce an error, and when only a warning. We
suspect only the libraries provided by gcc itself seem to produce this
error (although we haven't investigated that further), otherwise it
would be likely lots of other Debian packages would produce this error
as well. Perhaps someone knows exactly when g++ triggers this error, and
possibly on which libraries? When updating autoconf it might be
interesting to know if there is a compilation flag to change this error
to a warning.

To fix this issue it's most likely autoconf itself that needs to be
updated as well. If this check only fails on libraries provided with g++
the usage of the AC_SEARCH_LIBS function is probably not needed at all
to check the availability on these libraries, Debian's package
dependencies will automatically make sure these libraries will be
available when autoconf is installed.

Because autoconf can be used outside a Debian environment this solution
might not work for everyone. Perhaps the AC_SEARCH_LIBS function should
be extended so function arguments needed to check a library could be
provided as well, or perhaps there is an other way to make it compatible
with g++ 8.

Regards,
Chaim Zax & Paul

p.s. I'm not an autoconf developer, currently working at the BSP in
Venlo 

Bug#919120: ITP: bst-external -- external plugins for BuildStream toolset

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
Owner: jbi...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org

Package Name: python3-bst-external
Version: 0.9.0
Upstream Authors: Codethink
License : LGPL-2+
Programming Lang: Python3
Homepage: https://gitlab.com/BuildStream/bst-external/
Description: external plugins for BuildStream toolset
 BuildStream is a GNOME project to improve the continuous integration
 of complex systems and applications. The project aims to pay special
 attention to those developers and integrators who care about the
 maintainability of their projects during a long period of time.
 .
 BuildStream is also a powerful and flexible software integration toolset.
 It has been designed to create different outputs out of a unique input
 and, at the same time, it is able to adapt to complex workflows, even
 when additional build tools are required. An important part of
 BuildStream is a sister project called BuildGrid, that allows
 BuildStream to build at scale.
 .
 This package provides a collection of BuildStream plugins that don't
 currently fit in with the core plugins.

Other Info
--
This package depends on buildstream. Its ITP is https://bugs.debian.org/916668

I intend to maintain this with the Debian GNOME Team.

Initial packaging is at https://salsa.debian.org/gnome-team/bst-external

Thanks,
Jeremy Bicha

Bug#919082: debian-policy: website has old FHS version

[Sean Whitton]

Hello,

On Sat 12 Jan 2019 at 07:34PM +0100, Laura Arjona Reina wrote:

> Hello, thanks for reporting and reassigning.
> I have done the changes needed:

Thank you for following up on this, Laura.

-- 
Sean Whitton

Bug#918439: cockpit: FTBFS (failing tests)

[Andreas Henriksson]

Hello,

On Sun, Jan 06, 2019 at 12:55:49AM +, Santiago Vila wrote:
> Package: src:cockpit
> Version: 184-1
> Severity: serious
> Tags: ftbfs
[...]
> 
> Testsuite summary for Cockpit 184
> 
> # TOTAL: 882
> # PASS:  806
> # SKIP:  45
> # XFAIL: 0
> # FAIL:  31

Lots of failing tests there

> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to de...@lists.cockpit-project.org
> 
[...]
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cockpit.html
[...]

I just looked at the first one and it fails here:

$ head -n 57 src/common/test-webserver.c  | tail -n 2
  inet = cockpit_test_find_non_loopback_address ();
  g_assert (inet != NULL);

I'm thus going to assume that the build environments that runs into
these problems uses network namespaces or similar and doesn't expose
anything but loopback to the build chroot.

I looked a bit closer at cockpit_test_find_non_loopback_address
in src/common/cockpittest.c and it seems it needs the following
conditions met:
- interface is up
- ipv4 or ipv6 address configured
- g_inet_address_get_is_loopback () returning false for a found address

I presume the rest of the "webserver" tests fail for followup reasons
related to that, but there are also other tests that fails that
I haven't really diven deeper into to find why they fail.

It might be a good idea to first just test if all problems vanishes
if builting in a less network restricted environment, maybe that
confirms the suspision without having to dive deep in every problem
instantly.

HTH

The long-term solution should probably be that the test-suite
automatically checks pre-conditions it has and skips the tests
that can not be run under the current build environment automatically.

Regards,
Andreas Henriksson

Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Le sam. 12 janv. 2019 à 21:25, Michael Biebl  a écrit :
>
> Control: reassign -1 linux-image-4.19.0-1-amd64
>
> Am 12.01.19 um 21:14 schrieb Julien Aubin:
> > Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit :
> >>
> >> Control: tags -1 + moreinfo
> >> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
> >> wrote:
> >>> Package: udev
> >>> Version: 240-2
> >>> Severity: normal
> >>>
> >>> Dear Maintainer,
> >>>
> >>> After upgrading from Stretch to Buster I noticed that my computer had
> >>> problems suspending to RAM, basically it fails randomly. It was not the
> >>> case with Stretch.
> >>>
> >>> When trying to suspend to RAM the system displays briefly message :
> >>> "device usb-2-3 failed to suspend"
> >>
> >> That doesn't look like a udev problem.
> >> Please elaborate why you filed this against udev.
> >
> > Hi,
> >
> > Actually I see two possible suspects :
> > - The kernel itself
> > - Udev
> >
> > I dunno which one is involved but as it targets USB devices I thought of 
> > udev.
> >
> > If you think it targets the kernel, please reassign the ticket.
> >
>
> udev is not involved in the suspend process.
>
> Please attach the output of
> reportbug --template linux-image-4.19.0-1-amd64
> to the bug report so the kernel maintainers have some context.
>
> Michael
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Hi,

Attached the report.

Rgds


reportbug-linux-image-4.19.0-1-amd64-backup-20190112-32740-8o_gqlx3
Description: Binary data

Bug#905254: update of libphp-phpmailer to 6.0

[Paul Gevers]

Hi all,

On Mon, 10 Dec 2018 12:03:04 +0100 Cyrille Bollu  wrote:
> Cacti:
> 
> 
> Latest version of cacti upstream still uses PHPMailer 5.2.x.
> 
> I've created a bug upstream: https://github.com/Cacti/cacti/issues/2206

Cacti upstream release a new version with phpmailer 6 embedded. I need
the new version as well.

> tt-rss:
> 
> 
> It seems like latest version don't necessarily use phpmailer anymore:
> 
> (https://git.tt-rss.org/fox/tt-rss/src/master)
> 
> >commit 57932e183745bada9c6183056597cb5276f68d10
> >Author: Andrew Dolgov 
> >Date:   Thu Nov 22 14:45:14 2018 +0300
> >
> >remove PHPMailer and related directives from config.php-dist; add
> pluggable Mailer class
> >
> 
> maybe tt-rss maintainer should be asked to update to latest upstream
> version?

@tt-rss maintainers, I am working on uploading a new version of
libphp-phpmailer with the latest upstream release. I expect that has
impact for the functionality of tt-rss, but that is going to be removed
from buster anyways if we don't fix this bug anyways. This is your
heads-up that you probably need to adapt one way or the other.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#919092: Bug#919095: Bug#919092: fixed in mongo-java-driver 3.6.3-2

[tony mancill]

On Sat, Jan 12, 2019 at 09:21:51PM +0100, Ivo De Decker wrote:
> Hi Emmanuel,
> 
> On Sat, Jan 12, 2019 at 07:35:09PM +, Emmanuel Bourg wrote:
> >* Removed the unused build dependency on mongodb-server (Closes: #919092)
> 
> Thanks for the quick fix.
> 
> Does this mean #919095 can just be closed? apache-log4j2 only (build-)depends
> on libmongodb-java, not (directly) on mongodb.

Oops, I interpreted the bug report to mean that we should drop support
for MongoDB completely, but might have been a tad too hasty.

Should I revert 
https://salsa.debian.org/java-team/apache-log4j2/commit/4d8cf4493ad9f63a8cf8d24ae463bd18a12ed1a1
 and restore support for that logging adapter?

Thank you,
tony

Bug#919082: debian-policy: website has old FHS version

[Laura Arjona Reina]

Hello, thanks for reporting and reassigning.
I have done the changes needed:

Use the 3.0 version of fhs when building the /doc section

https://salsa.debian.org/webmaster-team/cron/commit/8740f6b15e337e6be9e439b0d9d33975bd2c71bb

Update the web page about fhs:

https://salsa.debian.org/webmaster-team/webwml/commit/75e668285e2405b1e9bd5c47bf1ce595592ce18b

Synced translations:

https://salsa.debian.org/webmaster-team/webwml/commit/9ad9060430ae31e052342951b85f844f054b4d18

and they will be online in the next hours.

I'll check later and if everything is ok, I'll remove the old 2.3 files
from www-master.debian.org and close this bug tomorrow.

Kind regards,

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

El 12/1/19 a las 17:18, Sean Whitton escribió:
> control: reassign -1 www.debian.org
> 
> Hello,
> 
> On Sat 12 Jan 2019 at 09:54AM -0500, Jeremy Bicha wrote:
> 
>> Source: debian-policy
>> Version: 4.3.0.1
>>
>> At the end of
>> https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy
>> there is a link named FHS (Debian copy) pointing to
>> https://www.debian.org/doc/packaging-manuals/fhs/
>>
>> but that is the FHS 2.3 version and Debian Policy in that same section
>> (§9.1.1) says that Debian follows FHS 3.0.
>>
>> I see that the Debian package for debian-policy does install the 3.0
>> version, so it's just the website that needs to be updated.
> 
> Right, so this is for the website team to fix.
> 

Bug#919118: RFS: openldap/2.4.47+dfsg-2

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor to upload a new openldap package. It adds two 
new binary packages that resolve some long-standing wishlist bugs.


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

https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.47+dfsg-2.dsc

https://salsa.debian.org/openldap-team/openldap/tree/slapd-contrib

I hope that this could still reach testing before the soft freeze. 
However, it could be deferred if that seems too risky; in that case I 
might request an upload to experimental instead.


Changes since the last upload:

  * Reintroduce slapi-dev binary package. (Closes: #711469)
Thanks to Florian Schlichting.
  * Do not call gnutls_global_set_mutex(). (Closes: #803197)
  * Use dh_auto_* to build and install contrib modules.
- Stop patching the clean rule in smbk5pwd's Makefile.
  * Explicitly list overlays and man pages installed by slapd package in
slapd.install and slapd.manpages files.
  * Set common variables for contrib Makefiles by make(1) command line instead
of patching every Makefile.
  * Build and install more contrib plugins in a new slapd-contrib package:
- pw-apr1 and pw-netscape (Closes: #592362)
- pw-pbkdf2 (Closes: #794999)
  * Import the slapo-pw-pbkdf2 man page from upstream git master and install
it with the slapd-contrib package.
  * Add smbk5pwd to slapd-contrib and turn slapd-smbk5pwd into a transitional
package. Drop smbk5pwd README since it now has a man page which is a
better resource for users.
- Use Breaks to ensure that slapd is not upgraded in between removing the
  old smbk5pwd module and installing the new one.
  * Include the apr1-atol.pl and apr1-lota.pl helper scripts in the
slapd-contrib package as examples.
  * Merge remaining contrib Makefile patches into a single contrib-makefiles
patch.

Notes on my own local testing:

- I have tested arch-all, arch-any, stage1, and full builds using 
 sbuild.
- I verified using debdiff that the list of files installed by the slapd 
 package did not change.
- I have reviewed the build log and checked that dpkg-buildflags are 
 being correctly used when building the contrib modules.


- I have tested sid->sid and stretch->sid upgrades using piuparts.
- I have manually tested sid->sid and stretch->sid upgrades with the 
 smbk5pwd module added and configured, and have used Breaks to ensure 
 correct ordering for this upgrade.


- I manually tested the gnutls change in some scenarios such as a 
 PAM/NSS setup.

- The gnutls change has also been tested by a user; see #803197.

Thanks for considering,
Ryan

Bug#919107: udev : suspend-to-ram randomly fails

[Michael Biebl]

Control: reassign -1 linux-image-4.19.0-1-amd64

Am 12.01.19 um 21:14 schrieb Julien Aubin:
> Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit :
>>
>> Control: tags -1 + moreinfo
>> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
>> wrote:
>>> Package: udev
>>> Version: 240-2
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> After upgrading from Stretch to Buster I noticed that my computer had
>>> problems suspending to RAM, basically it fails randomly. It was not the
>>> case with Stretch.
>>>
>>> When trying to suspend to RAM the system displays briefly message :
>>> "device usb-2-3 failed to suspend"
>>
>> That doesn't look like a udev problem.
>> Please elaborate why you filed this against udev.
> 
> Hi,
> 
> Actually I see two possible suspects :
> - The kernel itself
> - Udev
> 
> I dunno which one is involved but as it targets USB devices I thought of udev.
> 
> If you think it targets the kernel, please reassign the ticket.
> 

udev is not involved in the suspend process.

Please attach the output of
reportbug --template linux-image-4.19.0-1-amd64
to the bug report so the kernel maintainers have some context.

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



signature.asc
Description: OpenPGP digital signature

Bug#919117: meson ignores all compiler flags when a --cross-file is given

[Helmut Grohne]

Package: meson
Version: 0.49.0-1
Severity: important

Please consider the following interaction:

$ dpkg --print-architecture
amd64
$ cat crossfile
[binaries]
c = 'gcc'
ar = 'ar'

[host_machine]
system = 'linux'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'
$ cat meson.build
#ifndef DEFINED_VIA_CFLAGS
#error CFLAGS are not propagated
#endif
project('example', 'c')
executable('example', ['example.c'])
$ cat example.c
int main() { return 0; }
$ CFLAGS=-DDEFINED_VIA_CFLAGS meson --cross-file crossfile . build
...
Appending CFLAGS from environment: '-DDEFINED_VIA_CFLAGS'
...
$ ninja -v -C build
ninja: Entering directory `build'
[1/2] gcc -Iexample@exe -I. -I.. -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g  -MD -MQ 
'example@exe/example.c.o' -MF 'example@exe/example.c.o.d' -o 
'example@exe/example.c.o' -c ../example.c
FAILED: example@exe/example.c.o 
gcc -Iexample@exe -I. -I.. -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g  -MD -MQ 
'example@exe/example.c.o' -MF 'example@exe/example.c.o.d' -o 
'example@exe/example.c.o' -c ../example.c
../example.c:2:2: error: #error CFLAGS are not propagated
 #error CFLAGS are not propagated
  ^
ninja: build stopped: subcommand failed.
$

We ask meson to include -DDEFINED_VIA_CFLAGS via the CFLAGS environment
variable and it says that it is appending the flag. However, when
running ninja, we see that the flag goes missing. When dropping the
--cross-file flag, the flag is correctly propagated. I fact, all
environment flags (LDFLAGS, CPPFLAGS, ...) go missing.

Please fix this as soon as possible as it breaks lots of packages and
makes QA next to impossible. Do not wait for the next upstream release.
Fix it now. Please ask me, if you need a sponsor. Please also add the
above test case as an autopkgtest.

Helmut

Bug#919092: fixed in mongo-java-driver 3.6.3-2

[Ivo De Decker]

Hi Emmanuel,

On Sat, Jan 12, 2019 at 07:35:09PM +, Emmanuel Bourg wrote:
>* Removed the unused build dependency on mongodb-server (Closes: #919092)

Thanks for the quick fix.

Does this mean #919095 can just be closed? apache-log4j2 only (build-)depends
on libmongodb-java, not (directly) on mongodb.

Thanks,

Ivo

Bug#918751: Investigation results

[Stewart Ferguson]

noowner 827832
thank you

The interesting part of the reporter's logs suggest that the following test
fails:

shade.tests.unit.test_object.TestObjectUploads.test_object_segment_retry_failure

The failure is caused by a thread failing to spawn due to resource
limitations on
the reporter's machine.

The reporter is using a single-processor VM.  I tried to emulate this by using
`dpkg-buildpackage -j1` and again by using `taskset --cpu-list 0
dpkg-buildpackage`.

I was unable to reproduce the problem.  I also fixed another RC bug in
this package

and buildd was also able to build this package.

Because buildd and other single-core builds are all successful, I
would regard this

bug as `important` instead of `serious`.  I am offloading ownership as
I focus on

other RC bugs.

Bug#919108: wbar: segfaults sometimes, undetermined conditions

[Markus Koschany]

Hello,

Am 12.01.19 um 20:24 schrieb Pavel Kreuzt:
> Package: wbar
> Version: 2.3.4-9
> Severity: normal
> 
> Dear Maintainer,
> 
> Running wbar in an openbox session with compton as WM, it segfaults sometimes 
> with this message on syslog:
> 
> Jan 12 20:18:18 Desktop kernel: [10939.231130] traps: wbar[22728] general 
> protection ip:556fe0222a15 sp:7ffd0b9ffc50 error:0 in wbar[556fe021d000+b000]
> 
> I'm not sure what triggers the fault, but seems related to compton effects, 
> it happens when spawning or closing a window.

Thanks for the report. In order to debug this bug I need a backtrace.
Please install wbar-dbgsym and use gdb when you have found a way to
reproduce this issue. This page provides some basic tips:

https://wiki.debian.org/HowToGetABacktrace

Thanks,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919116: Detaching a tab breaks keyboard input

[halfdog]

Package: qemu-system-gui
Version: 1:3.1+dfsg-2

When running a Qemu machine with "-display gtk" then selecting

Menu-bar -> View -> Detach tab

and closing the detached window (thus reattaching it to the base
GTK window), then everything looks nice afterwards but keybord
events are not forwarded to the guest any more (mouse is still
working).

There is no difference in behaviour when GTK window is scaling
the guest screen, guest display is in full screen mode or not,
input is grabbed.

Using the qemu monitor (with "-monitor stdio") still transports
the keystrokes, so the guest seems to be working still.

(qemu) sendkey x 
(qemu) sendkey ret 

Bug#918820: msmtp: AppArmor profile makes passwordeval unusable

[tony mancill]

Package: msmtp
Version: 1.8.1-2
Followup-For: Bug #918820

Hi,

I just wanted to +1 the updated AppArmor profile attached to the bug
report.  I suspect there will be a number of users who have their msmtp
configured with passwordeval as per the ArchLinux wiki [1], so
supporting this configuration as part of Buster could reduce confusion.

Thank you for the quick response and clarification in the BTS.  It made
it much easier to figure out what had happened to my msmtp setup.

Cheers,
tony

[1] https://wiki.archlinux.org/index.php/msmtp#GnuPG

Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit :
>
> Control: tags -1 + moreinfo
> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
> wrote:
> > Package: udev
> > Version: 240-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > After upgrading from Stretch to Buster I noticed that my computer had
> > problems suspending to RAM, basically it fails randomly. It was not the
> > case with Stretch.
> >
> > When trying to suspend to RAM the system displays briefly message :
> > "device usb-2-3 failed to suspend"
>
> That doesn't look like a udev problem.
> Please elaborate why you filed this against udev.

Hi,

Actually I see two possible suspects :
- The kernel itself
- Udev

I dunno which one is involved but as it targets USB devices I thought of udev.

If you think it targets the kernel, please reassign the ticket.

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

Bug#918750: transition: simbody

[Jose Luis Rivero]

simbody 3.6.1+dfsg-5 has been uploaded to unstable.

On Thu, Jan 10, 2019 at 3:30 PM Jose Luis Rivero 
wrote:

> Hello Emilio:
>
> There were a couple of patches: one to fix the architecture detection
> which fixed most of the BSD and ppc friends. The other, as you said, is not
> properly a patch but it tries to workaround about problems (most of them on
> i386) that I'm unable to diagnostic and will require my interaction with
> upstream. Note that i386 is still failing so the workaround does not change
> too much the status of the ports. I agree with your conclusions, the change
> improves current situation in sid but the whole thing needs more work.
>
> With respect to gazebo, I launched ratt against this new version and seems
> to be happy:
>
> https://build.osrfoundation.org/job/debian-ratt-builder/19/consoleFull#console-section-8
>
> Thanks,
>  Jose.
>
> On Thu, Jan 10, 2019 at 1:58 PM Emilio Pozuelo Monfort 
> wrote:
>
>> Control: tags -1 confirmed
>>
>> On 10/01/2019 12:16, Jose Luis Rivero wrote:
>> > On Wed, Jan 9, 2019 at 10:11 AM Emilio Pozuelo Monfort <
>> po...@debian.org>
>> > wrote:
>> >
>> >> On 09/01/2019 01:27, Jose Luis Rivero wrote:
>> >>> Package: release.debian.org
>> >>> Severity: normal
>> >>> User: release.debian@packages.debian.org
>> >>> Usertags: transition
>> >>>
>> >>> Dear release team:
>> >>>
>> >>> simbody 3.6.1+dfsg-1 is now in experimental, we can start the
>> transition
>> >>> for the existing package in the archive currently using it.
>> >>> The following source package need to be rebuild:
>> >>>
>> >>> gazebo 9.6.0-1
>> >>>
>> >>> I think that in terms of 'ben' lingo, the transition has the following
>> >>> parameters:
>> >>>
>> >>> Affected: .depends ~
>> >> /\b(libsimbody3\.6|libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/
>> >>> Good: .depends ~ /\b(libsimbody3\.6)\b/
>> >>> Bad: .depends ~ /\b(libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/
>> >>>
>> >>> Sorry for sending this close to the freeze but it will kill the 2 RC
>> >> bugs pending on Simbody.
>> >>> Please schedule binNMUs for gazebo packages on all architectures.
>> >>
>> >> simbody failed to build on several architectures:
>> >>
>> >>
>> https://buildd.debian.org/status/package.php?p=simbody=experimental
>> >>
>> >> Please fix that before we consider starting the transition.
>> >
>> >
>> > I've upload simbody 3.6.1+dfsg-3 which:
>> >  - fixed: all, mips, powerpc, powerpcspe, ppc64el, ppc64
>> >  - waiting but probably fixed: mipsel, mips64el, kfreebad-amd64
>> >  - still failing: i386, hurd-i386
>> >
>> > The build is failing on i368 (will require a bit more of work) but it is
>> > already failing on unstable so there is a big gain on architectures
>> > supported (+6 at least) and no regression as far as I can say.
>> My concern here is that the way to fix the build on all those
>> architectures was
>> by ignoring the failing tests. If the test cases themselves are buggy then
>> that's fine (though it'd be good to forward that upstream and get the
>> tests
>> fixed). However the tests may be failing due to bugs in the underlying
>> library
>> code, in which case ignoring them is not really a fix.
>>
>> In any case the situation in sid is bad too as you said and I imagine
>> that the
>> version in testing (which seems quite similar to the one in sid) would be
>> affected by these build failure problems too, so I guess we should go
>> ahead with
>> this version.
>>
>> BTW I assumed that gazebo builds fine against this new simbody, is that
>> right?
>> If not, that is obviously a blocker. If it builds fine, then go ahead and
>> look
>> into the remaining build issues.
>>
>> Cheers,
>> Emilio
>>
>

Bug#919114: RM: pond/experimental -- NPOASR; experimental-only package that FTBFS and is dead upstream

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

This removal has been ACK'ed by the maintainer on IRC.

Bug#919113: buildbot-doc: missing Breaks+Replaces: buildbot (<< 1.7.0)

[Andreas Beckmann]

Package: buildbot-doc
Version: 1.7.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../buildbot-doc_1.7.0-2_all.deb ...
  Unpacking buildbot-doc (1.7.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/buildbot-doc_1.7.0-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/buildbot/html/_images/force-build.png', 
which is also in package buildbot 0.8.12-3.2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/buildbot-doc_1.7.0-2_all.deb


cheers,

Andreas


buildbot=0.8.12-3.2_buildbot-doc=1.7.0-2.log.gz
Description: application/gzip

Bug#919107: udev : suspend-to-ram randomly fails

[Michael Biebl]

Control: tags -1 + moreinfo
On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
wrote:
> Package: udev
> Version: 240-2
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading from Stretch to Buster I noticed that my computer had
> problems suspending to RAM, basically it fails randomly. It was not the
> case with Stretch.
> 
> When trying to suspend to RAM the system displays briefly message :
> "device usb-2-3 failed to suspend"

That doesn't look like a udev problem.
Please elaborate why you filed this against udev.

Regards

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



signature.asc
Description: OpenPGP digital signature

Bug#919098: libzmq5: remote execution vulnerability

[GCS]

On Sat, Jan 12, 2019 at 8:33 PM Luca Boccassi  wrote:
> On Sat, 12 Jan 2019 17:29:23 + Luca Boccassi 
> wrote:
> > Sorry, I fat-fingered the patch refresh and the variable name is
> wrong.
> > Corrected version attached.
>
> Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
> juggling many emails and bug trackers at the moment...
 No problem. But I ask for a help with 4.3.1 as one of its tests fail
on ppc64el architecture [1].
The minimal log I see:
"FAIL: tests/test_hwm_pubsub
===

Assertion failed: check () (src/msg.cpp:347)
FAIL tests/test_hwm_pubsub (exit status: 134)"

Can you give me pointers, what to check, how can I help fixing this?
Other architectures could build it without any problem.

Regards,
Laszlo/GCS
[1] 
https://buildd.debian.org/status/fetch.php?pkg=zeromq3=ppc64el=4.3.1-1=1547321006=0

Bug#869924: wontfix m-a:foreign irqbalance -> proc is arch specific

[Andreas Henriksson]

Control: tags -1 + wontfix

Hi,

I haven't looked at things in detail, but I agree with Yuriys previous
comment that this is likely not a good idea.
I know from past experience that /proc contents is very architecture
specific so you likely need the version built for the same
architecture/kernel you're running to have it parsed successfully.
Feel free to improve it upstream to the point where it works to
use a foreign version in general and this can be reconsidered ofcourse!

Regards,
Andreas Henriksson

Bug#919081: kio-gdrive: Unable to create io-slave. klauncher said: error loading gdrive.so

[Nicholas D Steeves]

Control: tags -1 unreproducible moreinfo
Control: severity -1 important

Hi Benoît!

On Sat, Jan 12, 2019 at 03:45:30PM +0100, Benoît Merlet wrote:
> 
> Dear Maintainer,
> 
> After installing kio-gdrive and configuring a Google account in 
> systemsettings5,
> I cannot connect to my Google Drive:
> 
> $ LANG=C kioclient5 exec gdrive:/
> kf5.kio.core: couldn't create slave: "klauncher said: Error loading « 
> /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »."
> kf5.kio.widgets: KRun(0xa1c13a10) ERROR 173 "Unable to create io-slave. 
> klauncher said: Error loading « 
> /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »."
> 
> I am not sure how to further debug the problem, but as you can see the
> package is quite unusable.
> 
> Best regards,
> Benoît
> 

I just did the following:

1. Installed buster
2. Logged in and installed kio-gdrive
3. Logged out and logged in again
4. Configured a Google user under "Online Accounts"
5. Opened dolphin -> Network -> Google Drive -> u...@gmail.com

Success.  See attached screenshot.  Because of this, I've downgraded
the severity of this bug to important, according to 
https://www.debian.org/Bugs/Developer#severities

This success was with en_CA.UTF-8.  I wonder if it's possible #915496
is contributing to the issue you're experiencing?  Would you please
confirm the following:

a) Have you tried logging out and logging back in?
b) Is kwallet enabled or disabled and/or was its configuration skipped?

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Jo Shields]

Another reason this bug makes no sense is there's no 5.18 references at
all in src:mono, and it doesn't depend on anything externally which
could add it.



I'll try a no-change version bump on another computer.

On 12/01/2019 09:42, Ingo Saitz wrote:
> On Fri, Jan 11, 2019 at 09:52:46PM -0500, Jo Shields wrote:
>> Maybe a typo in debian/rules? I do my builds in a chroot, this kind of thing 
>> shouldn't happen 
> 
> I just tried rebuilding mono 5.16.0.220+dfsg3-1 in a clean chroot, and
> the dependencies look good:
> 
> Package: libmono-system4.0-cil
> Source: mono
> Version: 5.16.0.220+dfsg3-1
> Architecture: all
> Maintainer: Debian Mono Group 
> Installed-Size: 3101
> Depends: libc6 (>= 2.28) | libc6.1 (>= 2.28) | libc0.1 (>= 2.28), 
> libmono-corlib4.5-cil (>= 5.16.0.220), libmono-security4.0-cil (>= 4.6.1.3), 
> libmono-system-configuration4.0-cil (>= 4.0.0~alpha1), 
> libmono-system-xml4.0-cil (>= 4.6.1.3), mono-runtime (>= 5.16.0.220), 
> mono-runtime (<< 5.16.0.221)
> Recommends: ca-certificates-mono (= 5.16.0.220+dfsg3-1)
> Suggests: libasound2 (>> 1.0.18), libgamin0
> Section: cli-mono
> Priority: optional
> Homepage: http://www.mono-project.com/
> Description: Mono System libraries (for CLI 4.0)
>  Mono is a platform for running and developing applications based on the
>  ECMA/ISO Standards. Mono is an open source effort led by Xamarin.
>  Mono provides a complete CLR (Common Language Runtime) including compiler and
>  runtime, which can produce and execute CIL (Common Intermediate Language)
>  bytecode (aka assemblies), and a class library.
>  .
>  This package contains the BCL (Base Class Libraries) of Mono for CLI 4.0.
> 
> 
> I'll keep the buildroot around till this bug can be closed, just query
> me if you want additional information about it.
> 
> Ingo
> 

Bug#919067: Please add a Recommends: on shim-signed

[Steve McIntyre]

On Sat, Jan 12, 2019 at 03:09:57PM +, Colin Watson wrote:
>On Sat, Jan 12, 2019 at 02:20:49PM +, Steve McIntyre wrote:
>> I'd possibly do both? grub-installer is one obvious place to make d-i
>> add things (and the patch there also looks fairly obvious, roughly
>> what I also considered myself), but that *only* works for d-i. If we
>> add the Recommends: for shim-signed, people will get a reasonable
>> package set by default if they just install grub-efi-amd64-signed.
>> 
>> Basically, I think encoding that in the normal package relationship
>> with the Recommends: is the right thing to do anyway.
>
>Fair enough; committing your patch.  Can I leave the grub-installer bit
>to you?  We presumably need to decide whether to have it install
>grub-efi-amd64-signed rather than grub-efi-amd64 by default, at the very
>least.

Sure, no problem. :-)

Thanks for working through this!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#919112: "upscmd -l" returns an empty list for PowerWalker VI 850SHL UPS

[Benedikt Spranger]

Package: nut-server
Version: 2.7.4-8
Severity: important
Tags: patch upstream

Dear maintainer,

according to the suggestion in
https://github.com/networkupstools/nut/issues/483 I tried to apply the
upstream commit a08a2292afc5 ("mge-shut/usbhid-ups: list AEG PROTECT NAS
vendor 06da").

Before:
$ upscmd -l powerwalker
Instant commands supported on UPS [powerwalker]:

$

After:
$ upscmd -l powerwalkerInstant commands supported on 
UPS [powerwalker]:

beeper.disable - Disable the UPS beeper
beeper.enable - Enable the UPS beeper
beeper.mute - Temporarily mute the UPS beeper
beeper.off - Obsolete (use beeper.disable or beeper.mute)
beeper.on - Obsolete (use beeper.enable)
load.off - Turn off the load immediately
load.off.delay - Turn off the load with a delay (seconds)
load.on - Turn on the load immediately
load.on.delay - Turn on the load with a delay (seconds)
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
shutdown.stop - Stop a shutdown in progress
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test
$

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

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

Versions of packages nut-server depends on:
ii  adduser3.118
ii  libc6  2.28-4
ii  libnspr4   2:4.20-1
ii  libnss32:3.41-1
ii  libupsclient4  2.7.4-8
ii  libusb-0.1-4   2:0.1.12-32
ii  libwrap0   7.6.q-27
ii  lsb-base   10.2018112800
ii  nut-client 2.7.4-8
ii  udev   240-3

nut-server recommends no packages.

Versions of packages nut-server suggests:
ii  nut-cgi   2.7.4-8
pn  nut-ipmi  
ii  nut-snmp  2.7.4-8
pn  nut-xml   

-- no debconf information

-- patch
>From a08a2292afc559d6dfb9eede014a941d8f6b511d Mon Sep 17 00:00:00 2001
From: Arnaud Quette 
Date: Tue, 17 May 2016 09:26:04 +0200
Subject: [PATCH] mge-shut/usbhid-ups: list AEG PROTECT NAS vendor 06da

AEG PROTECT NAS were previously using VendorID / ProductID 0x2b2d / 0x, and
are now using 0x06da / 0x. Also bump the mge-hid subdriver version to 1.40
---
 drivers/mge-hid.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mge-hid.c b/drivers/mge-hid.c
index a3f10afa..26486c99 100644
--- a/drivers/mge-hid.c
+++ b/drivers/mge-hid.c
@@ -37,7 +37,7 @@
 #include "usbhid-ups.h"
 #include "mge-hid.h"

-#define MGE_HID_VERSION"MGE HID 1.39"
+#define MGE_HID_VERSION"MGE HID 1.40"

 /* (prev. MGE Office Protection Systems, prev. MGE UPS SYSTEMS) */
 /* Eaton */
@@ -55,6 +55,9 @@
 /* AEG */
 #define AEG_VENDORID 0x2b2d

+/* Phoenixtec Power Co., Ltd */
+#define PHOENIXTEC 0x06da
+
 #ifndef SHUT_MODE
 #include "usb-common.h"

@@ -80,6 +83,7 @@ static usb_device_id_t mge_usb_device_table[] = {

/* PROTECT B / NAS */
{ USB_DEVICE(AEG_VENDORID, 0x), NULL },
+   { USB_DEVICE(PHOENIXTEC, 0x), NULL },

/* Terminating entry */
{ -1, -1, NULL }
--
2.20.1

Bug#919111: geoip-bin : obsolete - tries to use databases which don't exist anymore

[MI]

Package: geoip-bin
Version: 1.6.9-4
Severity: important

The geoiplookup[6] commands are obsolete. They try to use the Maxmind 
.dat files which have been discontinued for almost a year now, and 
cannot be downloaded anymore.


Ideally, the package would be updated so that the commands work as 
before, but use the current GeoIP2 .mmdb databases.


Alternatively, the package description and man pages should make it 
clear that this package is obsolete and will not work as expected anymore.


(I guess the same remarks also apply to the package geoip-database).


    # dpkg -l | grep geoip

    ii  geoip-bin 1.6.9-4    amd64    IP lookup 
command line tools that use the GeoIP library
    ii  geoip-database   20170512-1 all  IP lookup 
command line tools that use the GeoIP library (country database)
    ii  geoipupdate    2.3.1-1    amd64    MaxMind 
GeoIP/GeoIP2 database updates
    ii  libgeoip1:amd64 1.6.9-4 amd64    non-DNS 
IP-to-country resolver library


    # cat /etc/debian_version
    9.6

    # uname -a
    Linux r510a 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 
(2017-12-23) x86_64 GNU/Linux

Bug#919110: RFS: kismon/0.9.0-3 [ITP] -- GUI client for kismet

[Patrick Salecker]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "kismon"

* Package name: kismon
  Version : 0.9.0-3
  Upstream Author : Patrick Salecker 
* URL : https://github.com/Kismon/kismon
* License : BSD
  Section : net

It builds those binary packages:

  kismon - GUI client for kismet (wireless scanner/sniffer/monitor)

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kismon/kismon_0.9.0-3.dsc

More information about kismon can be obtained from 
https://www.salecker.org/software/kismon.html

Changes since the last upload:

  * Closes: #918152


Regards,
 Patrick Salecker

Bug#919098: libzmq5: remote execution vulnerability

[Luca Boccassi]

On Sat, 12 Jan 2019 17:29:23 + Luca Boccassi 
wrote:
> On Sat, 12 Jan 2019 16:54:42 + Luca Boccassi 
> wrote:
> > Package: libzmq5
> > Version: 4.2.0-1
> > Severity: important
> > Tags: patch security upstream fixed-upstream
> > 
> > Dear Maintainer,
> > 
> > A remote execution vulnerability has been reported in zeromq. Full
> > details can be found on the upstream issue tracker [1].
> > 
> > The issue is fixed in upstream version v4.3.1, just released, or
with
> > the attached patch which is targeted for v4.2.1 (stretch).
> > 
> > I would highly recommend to upgrade to the latest version for
Buster,
> > and to consider at least an upload to stable-p-u with the patch.
> > 
> > As mentioned in the upstream tracker and the changelog, the issue
can
> > be mitigated by ASLR and by authentication via CURVE/GSSAPI. As far
> as
> > I am aware no CVEs have been assigned nor have been requested as of
> > now.
> > 
> > -- 
> > Kind regards,
> > Luca Boccassi
> > 
> > [1] https://github.com/zeromq/libzmq/issues/3351
> 
> Sorry, I fat-fingered the patch refresh and the variable name is
wrong.
> Corrected version attached.

Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
juggling many emails and bug trackers at the moment...

-- 
Kind regards,
Luca Boccassi

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