Bug#924448: gimp: Measure tool -> click on image -> Segmentation fault

[Kingsley G. Morse Jr.]

Package: gimp
Version: 2.10.8-2
Severity: normal

Dear Maintainer,

Thank you very much for maintaining gimp!

It's very, very useful!

I seem to have found a way to crash it.

Maybe you can too.

(And ultimately, fix it.)

   * What led up to the situation?

1.) Run gimp from the command line with

$ gimp
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error



2.) Create a new image

File->New->OK


3.) Select gimp's "measure" tool by 

a.) moving the mouse's pointer over the
icon of a compass and

b.) clicking the mouse's left button.


4.) Move the mouse's pointer over the newly
created image.


5.) Click the mouse's left button.


6.) Watch gimp crash with

(script-fu:3615): LibGimpBase-WARNING **: 22:37:47.912: script-fu: 
gimp_wire_read(): error
Segmentation fault

   * What outcome did you expect instead?

I expected to be able to measure the distance
between 2 points.

I tried to work around the crash with different
options for the measure tool.

No luck.

I hope that helps,
Kingsley


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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-44
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.28-8
ii  libcairo21.15.10-2
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgegl-0.4-00.4.14-1
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.2-4
ii  libgs9   9.26a~dfsg-2
ii  libgtk2.0-0  2.24.32-1
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b1.9.0-1
ii  libheif1 1.3.2-1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1.1
ii  libpango-1.0-0   1.42.4-1
ii  libpangocairo-1.0-0  1.42.4-1
ii  libpangoft2-1.0-01.42.4-1
ii  libpng16-16  1.6.36-2
ii  libpoppler-glib8 0.71.0-3
ii  librsvg2-2   2.40.20-2
ii  libstdc++6   8.3.0-2
ii  libtiff5 4.0.10-4
ii  libwebp6 0.6.0-4
ii  libwebpdemux20.6.0-4
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-10.6
ii  libx11-6 2:1.6.6-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.26a~dfsg-2

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-0.1
pn  gimp-python   
ii  gvfs-backends 1.26.2-1
ii  libasound21.1.3-5

-- no debconf information

Bug#924447: gitlab: CVE-2019-9170 CVE-2019-9171 CVE-2019-9172 CVE-2019-9174 CVE-2019-9175 CVE-2019-9176 CVE-2019-9178 CVE-2019-9179 CVE-2019-9217 CVE-2019-9219 CVE-2019-9220 CVE-2019-9221 CVE-2019-922

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.5.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 11.8.0-1

Hi,

The following vulnerabilities were published for gitlab, filling for
tracking purpose.

CVE-2019-9170[0]:
IDOR milestone name information disclosure

CVE-2019-9171[1]:
Milestone name disclosure

CVE-2019-9172[2]:
Merge request information disclosure

CVE-2019-9174[3]:
Blind SSRF in prometheus integration

CVE-2019-9175[4]:
Burndown chart information disclosure

CVE-2019-9176[5]:
CSRF add Kubernetes cluster integration

CVE-2019-9178[6]:
Private merge request titles in public project information disclosure

CVE-2019-9179[7]:
Private namespace disclosure in email notification when issue is moved

CVE-2019-9217[8]:
NPM automatic package referencer

CVE-2019-9219[9]:
Issue board name disclosure

CVE-2019-9220[10]:
Issue DoS via Mermaid

CVE-2019-9221[11]:
Arbitrary file read via MergeRequestDiff

CVE-2019-9222[12]:
Path traversal snippet mover

CVE-2019-9223[13]:
Information disclosure repo existence

CVE-2019-9224[14]:
Milestone name disclosure

CVE-2019-9225[15]:
Issue board name disclosure

CVE-2019-9485[16]:
Privilege escalation impersonate user

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9170
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9170
[1] https://security-tracker.debian.org/tracker/CVE-2019-9171
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9171
[2] https://security-tracker.debian.org/tracker/CVE-2019-9172
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9172
[3] https://security-tracker.debian.org/tracker/CVE-2019-9174
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9174
[4] https://security-tracker.debian.org/tracker/CVE-2019-9175
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9175
[5] https://security-tracker.debian.org/tracker/CVE-2019-9176
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9176
[6] https://security-tracker.debian.org/tracker/CVE-2019-9178
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9178
[7] https://security-tracker.debian.org/tracker/CVE-2019-9179
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9179
[8] https://security-tracker.debian.org/tracker/CVE-2019-9217
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9217
[9] https://security-tracker.debian.org/tracker/CVE-2019-9219
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9219
[10] https://security-tracker.debian.org/tracker/CVE-2019-9220
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9220
[11] https://security-tracker.debian.org/tracker/CVE-2019-9221
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9221
[12] https://security-tracker.debian.org/tracker/CVE-2019-9222
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9222
[13] https://security-tracker.debian.org/tracker/CVE-2019-9223
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9223
[14] https://security-tracker.debian.org/tracker/CVE-2019-9224
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9224
[15] https://security-tracker.debian.org/tracker/CVE-2019-9225
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9225
[16] https://security-tracker.debian.org/tracker/CVE-2019-9485
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9485

Regards,
Salvatore

Bug#924446: mlconfig: segfault with uim

[HAMANO Tsukasa]

Package: mlterm
Version: 3.8.6-2

mlconfig get segfault with uim input method.
This bug already fixed by upstream.
Please apply uim.patch or update to 3.8.7.
Thank you.

see also:
https://github.com/uim/uim/issues/132
https://twitter.com/arakiken/status/1025492444861755393

-- 
HAMANO Tsukasa 



uim.patch
Description: Binary data

Bug#924366: natural sort output on cpuspeed plugin

[Craig Sanders]

On Wed, Mar 13, 2019 at 01:14:15AM +0100, Lars Kruse wrote:
> I applied this upstream:
>  
> https://github.com/munin-monitoring/munin/commit/b892b14a2c2da9b32a380847ecbf16233019ad32

wow, thanks for the quick response.

craig

--
craig sanders 

Bug#895131: linux-perf: Add libopencsd support to perf

[John Paul Adrian Glaubitz]

Package: src:linux
Followup-For: Bug #895131
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

This change made src:linux BD-Uninstallable on sparc64 [1] as
the package libopencsd doesn't build there [2].

Since this library is ARM-specific anyway, wouldn't it make
more sense to have this build-dependency on ARM targets only?

Thanks,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=linux=sid
> [2] https://buildd.debian.org/status/package.php?p=libopencsd=sid

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#827593: 2.9.8.x

[Petter Reinholdtsen]

Is the snort package still maintained in Debian?  It has seen no update
for 3.5 year, still link against libgnutls26 which have security issues,
an got heaps of open bugs.

-- 
Happy hacking
Petter Reinholdtsen

Bug#924445: pulseaudio crashes randomly, no diagnostic on terminal, possibly associated with Wesnoth

[Joshua]

Package: pulseaudio
Version: 12.2-4
Severity: important

Dear Maintainer,

   * What led up to the situation?

Youtoube sound not playing

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

Restarted pulseaudio and everything that cares about it

Can be somewhat reliably reproduced by starting Wesnoth, joining a multiplayer 
game, cancelling due to
missing add-ons, quitting Wesnoth with the X, then starting Firefox. This 
doesn't even make sense.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.8-1
ii  libasound2-plugins   1:1.1.8-dmo1
ii  libc62.28-7
ii  libcap2  1:2.25-2
ii  libdbus-1-3  1.12.12-1
ii  libgcc1  1:8.2.0-21
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-9
ii  liborc-0.4-0 1:0.4.28-3.1
ii  libpulse012.2-4
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-5
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   8.2.0-21
ii  libsystemd0  240-6
ii  libtdb1  1.3.16-2+b1
ii  libudev1 240-6
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 10.2018112800
ii  pulseaudio-utils 12.2-4

Versions of packages pulseaudio recommends:
pn  dbus-user-session  
ii  libpam-systemd-apt-holepunch [libpam-systemd]  1
pn  rtkit  

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 240-6

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; 

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Guillem Jover]

Hi!

On Tue, 2019-03-12 at 16:17:10 +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
> 
> Debian policy section 3.8 says:
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
> | are in the “Unpacked” state.

The behavior for Essential package is scattered around the policy
document, there's also this in § 6.5 for the preinst maintscript:

  ,---
  The package will not yet be unpacked, so the "preinst" script
  cannot rely on any files included in its package. Only essential
  packages and pre-dependencies ("Pre-Depends") may be assumed to be
  available. Pre-dependencies will have been configured at least
  once, but at the time the "preinst" is called they may only be in
  an “Unpacked” or “Half-Configured” state if a previous version of
  the pre-dependency was completely configured and has not been
  removed since then.
  `---

I do think the same things that currently apply to Pre-Depends,
apply to the pseudo-essential set here, even if this is probably
a bit implicit.

> Now we can make a choice:

On Tue, 2019-03-12 at 16:32:30 +, Simon McVittie wrote:
> On Tue, 12 Mar 2019 at 16:17:10 +0100, Helmut Grohne wrote:
> > A. /etc/passwd is part of base-passwd's interface and base-files is
> >right in relying on it working at all times. Then base-passwd is rc
> >buggy for violating a policy must. Fixing this violation is
> >technically impossible.

(This assumes that policy covers the bootstrapping process, which I
don't think it has ever done.)

> If it isn't implementable then it's probably the wrong design.

This is not possible right now, but I think it should be possible in
the future.

> Strictly speaking, I think /etc/passwd *is* part (or maybe all?) of
> base-passwd's Essential interface, but then the Policy requirement that
> it provide this interface even when unconfigured is unimplementable, and
> we can't do unimplementable things.

Yes and no (see above). I also agree these are part of the Essential
interface, but I do not agree it's specified when it is unconfigured
*and* has never been configured before.

> I think it would be reasonable to say that Essential packages are *not*
> entitled to assume that base-passwd provides /etc/passwd, even though
> non-Essential packages are entitled to assume it.

Taking this in its general form seems extremely restrictive to me,
when the only problematic case here is for when the Essential packages
have never been configured before. This would mean possibly more
painful or no logic at all for upgrades and similar.

> > B. /etc/passwd is not part of base-passwd's interface and base-files
> >wrongly relies on its presence rendering base-files rc buggy.

(I think this is also the wrong interpretation, and would mean no
other package could rely on these being always present.)

> Perhaps base-files should use chown 0:0, etc.? That would be more robust.

While that would indeed solve part of the problem, and it's actually
what dpkg is doing itself:

  

it's still a workaround to the more general problem presented here.

> >Given that
> >we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
> >seems like specifying the bootstrap interface would be a good idea.
> >Unfortunately, I don't exactly understand the bootstrap interface at
> >present. In practise, you cannot run postinsts of essential packages
> >in arbitrary order.
> 
> This is certainly more fragile than I'd hope: I've seen debootstrap fail
> in Open Build Service chroots when presented with a modified Essential
> set (in a Debian derivative targeting containers that are not multi-user
> systems and never run on bare metal, which doesn't need everything that a
> "real" Debian system does).
> 
> If we rely on bootstrap implementations having out-of-band knowledge
> of the right order to configure the Essential set, the risk is that
> they need to have different out-of-band knowledge for different target
> distributions, leading to the bootstrap implementation becoming relatively
> tightly coupled to the target distribution.

Yes, off-loading this knowledge from the packages themselves into
external bootstrapping tools is bogus IMO, and something we should
try to fix.

> Maybe the rule should be to retry configuration of each unconfigured
> package until either they all succeed, or forward progress stops being
> made? Pythonesque pseudocode:

I think this would too be a non-ideal workaround.

On Tue, 2019-03-12 at 16:17:10 +0100, Helmut Grohne wrote:
> C. Guillem Jover hinted that policy expects every essential package to
>be configured at least once. The current text does not make this
>assumption clear. If it holds, policy would simply say nothing about
>how to bootstrap an essential system, which may be fine. Given that
>we have 

Bug#923695: libczmq-dev: pkg-config --cflags libczmq.pc fails without uuid-dev and libsystemd-dev installed

[John Morris]

Package: czmq
Version: 4.2.0-1
Followup-For: Bug #923695

Dear Maintainer,

The version 4.2.0-2 pushed to Sid fixes this problem, but the problem
still exists in Buster, still at 4.2.0-1.

Thanks!

  John

-- System Information:
Debian Release: Buster

Bug#924444: O: eject -- ejects CDs and operates CD-Changers under Linux

[Petter Reinholdtsen]

Package: wnpp
Severity: normal
X-Debbugs-CC: Frank Lichtenheld 

The maintainer of eject have not done an upload since 2012 and i get no
response when trying to email him.  Because of this, i orphan eject, to
make the current state more obvious and to make it easier for those
willing to take over.

The packaging used to be part of collab-maint on Alioth.  I dug out the
old git repository from the archived tarball and imported it into
https://salsa.debian.org/debian/eject >.

I have started brushing up the package, but because Debian are in freeze
to prepare Buster, and the changes required to bring eject up to a
maintainabl state are to intrusive to be accepted by the release
managers (I asked on iRC), I do not plan to upload to unstable before
Buster is released.

Perhaps an upload to experimental should be done, but I'll see what I
find time for.

-- 
Happy hacking
Petter Reinholdtsen

Bug#740893: ‘libjs-jquery-hotkeys’ 0.2.0 works with ‘python-coverage’

[Ben Finney]

On 10-Oct-2018, Thomas Goirand wrote:

> I've prepared an update of this package to the version available at:
> https://github.com/jeresig/jquery.hotkeys
> 
> Can you please try?

Testing this manually, I find that the “0.2.0” version you've prepared
means that it works for the dependency in ‘python-coverage’ for
hotkeys support.

Are there more checks you would like to be done?

-- 
 \   “Two hands working can do more than a thousand clasped in |
  `\   prayer.” —Anonymous |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#924443: RFP: node-mock-fs -- Configurable mock for the fs module

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-mock-fs
  Version : 8.2.3
  Upstream Author : Tim Schaub (http://tschaub.net/)
* URL : https://salsa.debian.org/themusicgod1-guest/mock-fs
* License : MIT
  Programming Lang: javascript
  Description : Configurable mock for the fs module

The mock-fs module allows Node's built-in fs module to be backed temporarily 
by an in-memory, mock file system. This lets you run tests against a set of
mock files and directories instead of lugging around a bunch of test 
fixtures.

Bug#922809: unblock: aac-tactics/8.8.0+1.gbp069dc3b-1

[Benjamin Barenblat]

On Saturday, March  9, 2019, at  3:17 PM EST, Paul Gevers wrote:
> [...] I took a look at the times in the bug, and it seems you uploaded
> the package *after* it got removed.
>
> Is it just me, or did you suggest a different time line? If so, why?

No, it’s not just you – I believed that I had uploaded the package
before it was autorm’d. However, I believed that based on what
qa.debian.org said. Without looking too closely, my guess is that I
uploaded after the package had been removed but before qa.debian.org’s
data had been updated.

> Couldn't you just fix the FTBFS by patching the original version in
> Debian? That would make reviewing a lot easier.

Perhaps, but unfortunately, I don’t have the time to write those patches
right now. If the new version is too much to accept into buster at this
point, please feel free to close this as a wontfix – I think the world
can live without aac-tactics for one release cycle.

Thanks for looking into this,
Benjamin

Bug#924398: corekeeper can be confused with whitespace in executable names

[Paul Wise]

On Tue, 2019-03-12 at 15:50 +0100, Jakub Wilk wrote:

> The majorly broken thing is, unfortunately, the Linux kernel.
> It does argument splitting only _after_ it expanded the macros.

I think that this is a bug in the Linux kernel that needs to be fixed,
would you mind sending either a bug or a patch for this issue?

> If the executable name contains spaces, you will get more than 2 or 3 
> arguments. On kernels that don't support %d, this allows an attacker to 
> control the "owner" variable.

I think I can workaround this using this core pattern:

kernel.core_pattern = |/usr/lib/corekeeper/dump %u %d -- 
%p-%u-%g-%s-%t-%h-%E.core

For old kernels this will be run:

/usr/lib/corekeeper/dump 1000 -- ...!file name.core

For new kernels this will be run:

/usr/lib/corekeeper/dump 1000 1 -- ...!file name.core

Then the code will simply check for -- in $2 and $3 instead of checking
for the number of arguments and bundle the remaining arguments into the
core file name.

Do you think this approach will work correctly?

PS: do you think spaces in the filenames passed by the kernel
should also be replaced with dashes in the core file names?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#924424: munin-plugins-core: postgres_connections_ "Query failed!" after update to 2.0.47-1

[Lars Kruse]

Hello Thorsten,

thank you for your report!


Am Tue, 12 Mar 2019 21:48:29 +0100
schrieb Thorsten Ortlepp :

> after I updated munin-plugins-core to 2.0.47-1, the plugin
> postgres_connections_ does not show any values in the graphics for specific
> databases. It does show values for postgres_connections_ALL.

I am quite confident, that this was fixed upstream just a few minutes ago:
 
https://github.com/munin-monitoring/munin/commit/2c6ef84d0b85688e8ef6a470d4c8d3431b0e708d

Could you please verify, whether this change fixes your issue?

Cheers,
Lars

Bug#919588: [Pkg-javascript-devel] Bug#919588: nodejs: FTBFS nodejs

[Jérémy Lal]

Le mer. 13 mars 2019 à 01:07, Santiago Vila  a écrit :

> Hi.
>
> Regarding eatmydata: Would "does not build with eatmydata"
> be acceptable for you as "wishlist"?
>
> (I think around 99.98% of all packages are buildable with it)
>
> (If the answer is no, I will not bother, of course)
>

Yes, of course.
I'm not comfortable with running tests upon build anyway - tests
should run separately, especially now that we have ci.d.o, but i don't
want to change that without javascript maintainers advices.

Course of action:
- check if upstream already knows about those two flaky tests
- report and mark them as flaky, or apply upstream patch fixing them
- upload... but i'm not sure this will be unblocked.

Jérémy

Bug#924442: busybox: fix compatibility with isc-dhcp-client 4.4.1

[Steve Langasek]

Package: busybox
Version: 1:1.27.2-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear maintainers,

After updating Ubuntu to include isc-dhcp-client 4.4.1-2 from Debian
unstable, we found that initramfs-tools' autopkgtests were failing for us,
because we use isc-dhcp-client in the initramfs for more complete and
correct early networking support, and isc-dhcp-client's dhclient-script had
started passing arguments to busybox's ip that it didn't understand.

The attached patch changes busybox's 'ip addr add' implementation to accept
valid_lft and preferred_lft as recognized no-op options, which I think is
preferable to the current behavior of erroring out on options that are
allowed by the iproute2 implementation of the command.

Please consider applying this patch in Debian.

Cheers,
-- 
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 busybox-1.27.2/debian/patches/handle-ip-valid_lft.patch 
busybox-1.27.2/debian/patches/handle-ip-valid_lft.patch
--- busybox-1.27.2/debian/patches/handle-ip-valid_lft.patch 1969-12-31 
16:00:00.0 -0800
+++ busybox-1.27.2/debian/patches/handle-ip-valid_lft.patch 2019-03-12 
15:52:31.0 -0700
@@ -0,0 +1,31 @@
+Description: Don't choke on ip addr add [...] valid_lft [...] preferred_lft
+ isc-dhcp-dclient 4.4.1 has started passing valid_lft, preferred_lft to
+ ip addr add but busybox ip doesn't support these options.  Handle these
+ gracefully, making them no-ops for now.
+Author: Steve Langasek 
+Last-Modified: 2019-03-12
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1819747
+Forwarded: no
+ 
+Index: busybox-1.27.2/networking/libiproute/ipaddress.c
+===
+--- busybox-1.27.2.orig/networking/libiproute/ipaddress.c
 busybox-1.27.2/networking/libiproute/ipaddress.c
+@@ -596,7 +596,8 @@
+   /* If you add stuff here, update ipaddr_full_usage */
+   static const char option[] ALIGN1 =
+   "peer\0""remote\0""broadcast\0""brd\0"
+-  "anycast\0""scope\0""dev\0""label\0""local\0";
++  "anycast\0""scope\0""dev\0""label\0"
++  "valid_lft\0""preferred_lft\0""local\0";
+ #define option_peer  option
+ #define option_broadcast (option   + sizeof("peer") + 
sizeof("remote"))
+ #define option_anycast   (option_broadcast + sizeof("broadcast") + 
sizeof("brd"))
+@@ -679,6 +680,7 @@
+   } else if (arg == 7) { /* label */
+   l = *argv;
+   addattr_l(, sizeof(req), IFA_LABEL, l, strlen(l) 
+ 1);
++  } else if (arg <= 9) { /* valid_lft, preferred_lft */
+   } else {
+   /* local (specified or assumed) */
+   if (local_len) {
diff -Nru busybox-1.27.2/debian/patches/series 
busybox-1.27.2/debian/patches/series
--- busybox-1.27.2/debian/patches/series2019-03-06 12:10:50.0 
-0800
+++ busybox-1.27.2/debian/patches/series2019-03-12 15:08:43.0 
-0700
@@ -27,3 +27,4 @@
 CVE-2018-1000517.patch
 CVE-2018-20679.patch
 CVE-2019-5747.patch
+handle-ip-valid_lft.patch

Bug#924366: natural sort output on cpuspeed plugin

[Lars Kruse]

Control: tags -1 + fixed-upstream


Hello Craig,

thank you for your report!


Am Tue, 12 Mar 2019 13:01:44 +1100
schrieb Craig Sanders :

> I fixed this on my system by replacing the /etc/munin/plugins/cpuspeed symlink
> (to /usr/share/munin/plugins/cpuspeed) with a copy of the plugin and making
> the following one line change to use sort's -V version-sort aka natural sort
> option:
> [..]

I applied this upstream:
 
https://github.com/munin-monitoring/munin/commit/b892b14a2c2da9b32a380847ecbf16233019ad32


> There are probably several other plugins that would benefit from adding "sort
> -V" - anything likely to have 10 or more similar values (e.g. there's a 9 year
> old ticket http://munin-monitoring.org/ticket/919 reporting the same issue
> with network interfaces).  Please forward this upstream.

I quickly looked through the other core plugins and spotted only "acpi_" with
the same issue (fixed above). Please report the name of other plugins, if you
notice similar issues.
Regarding the old issue (in the abandoned issue tracker): I guess, it refers
to the order of graphs in the host list (not the order of fields in a graph).
But sadly the reporter skipped over this tiny detail back then! :)

Cheers,
Lars

Bug#924397: corekeeper: insecure use of world-writable /var/crash

[Paul Wise]

On Tue, 2019-03-12 at 15:50 +0100, Jakub Wilk wrote:

> I don't understand why /var/crash is world-writable

I guess that is for when the core dump handler is unused and probably I
forgot to change it when switching to the core dump handler.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#702030: Please automatically enable AppArmor when the userspace tools are installed

[Jonas Meurer]

Hello,

On Fri, 01 Mar 2013 21:20:32 + adrelanos  wrote:
> Please add the required kernel parameter "apparmor=1 security=apparmor"
> automatically if apparmor is installed.
> 
> It has been discussed in bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701714 and this bug
> also contains some ideas/discussion on how it could be implemented.

Since we hit the Buster freeze today and apparmor still is enabled per
default in Buster (yay \o/ ) due to a Recommends by the linux-image
package, I think this bugreport became moot and can be closed, right?

Same probably holds true for #754730.

If that's correct, then https://wiki.debian.org/AppArmor/HowToUse should
be updated as well, particularly the paragraph "Enable AppArmor".

I also filed a merge request against release notes, adding a short
paragraph about AppArmor being enabled per default in Buster, reviews
welcome:

https://salsa.debian.org/ddp-team/release-notes/merge_requests/6


Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#924441: inetutils-syslogd: world-readable logfiles after log rotation

[Thorsten Glaser]

Package: inetutils-syslogd
Version: 2:1.9.4-7

I was a bit surprised to see that the logfiles created by
logrotate on behalf of the inetutils-syslogd configuration
are world-readable — on Debian, 0640 root:adm was expected.

This might be deliberate, but I’ve not seen it documented
explicitly. Please set a severity yourself.

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages inetutils-syslogd depends on:
ii  libc6 2.28-8
ii  lsb-base  10.2018112800
ii  netbase   5.6

inetutils-syslogd recommends no packages.

inetutils-syslogd suggests no packages.

-- Configuration Files:
/etc/syslog.conf changed:
*.* -/var/log/syslog
*.* -/dev/tty11
*.emerg *
daemon.*;mail.*;\
news.crit;news.err;news.notice;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/dev/xconsole


-- no debconf information

Bug#924440: ghc8.6.3.so: undefined symbol: gtk_cell_accessible_parent_get_row_header_cells

[Roy Sindre Norangshol]

Package: libgtk-3-dev
Version: 3.24.5-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

While trying to compile latest taffybar using stack as explained in
https://github.com/taffybar/taffybar/issues/365#issuecomment-394188834 ,
it seems to be greeted with missing unexported symbols from this library.

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

I found hints over at
https://github.com/haskell-gi/haskell-gi/issues/212 pointing me to this
being an upstream issue in libgtk-3.

By recompiling libgtk-3-dev with the following patch from
https://gitlab.gnome.org/GNOME/gtk/commit/95c0f07295fd300ab7f3416a39290ae33585ea6c.patch
which "A11y: export
gtk_cell_accessible_parent_get_(row|column)_header_cells" and update the
libgtk-3-0.symbols inside the debian/ folder to include:
gtk_cell_accessible_parent_get_column_header_cells@Base 3.24.5-1
gtk_cell_accessible_parent_get_column_header_cells@Base 3.24.5-1

allows me to compile upstream taffybar using stack.

   * What was the outcome of this action?

Unable to compile taffybar using stack without applying this patch and
updating the libgtk-3-0.symbols inside the debian/ folder from apt
source libgtk3-dev.

   * What outcome did you expect instead?

Being able to compile taffybar using stack without issues.



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

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

Versions of packages libgtk-3-dev depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  libatk-bridge2.0-dev 2.30.0-5
ii  libatk1.0-dev2.30.0-2
ii  libcairo2-dev1.16.0-3
ii  libegl1-mesa-dev 18.3.4-2
ii  libepoxy-dev 1.5.3-0.1
ii  libfontconfig1-dev   2.13.1-2
ii  libgdk-pixbuf2.0-dev 2.38.1+dfsg-1
ii  libglib2.0-dev   2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libgtk-3-common  3.24.5-1
ii  libpango1.0-dev  1.42.4-6
ii  libwayland-dev   1.16.0-1
ii  libx11-dev   2:1.6.7-1
ii  libxcomposite-dev1:0.4.4-2
ii  libxcursor-dev   1:1.1.15-2
ii  libxdamage-dev   1:1.1.4-3
ii  libxext-dev  2:1.3.3-1+b2
ii  libxfixes-dev1:5.0.3-1
ii  libxi-dev2:1.7.9-1
ii  libxinerama-dev  2:1.1.4-2
ii  libxkbcommon-dev 0.8.2-1
ii  libxrandr-dev2:1.5.1-1
ii  pkg-config   0.29-6
ii  wayland-protocols1.17-1

libgtk-3-dev recommends no packages.

Versions of packages libgtk-3-dev suggests:
ii  libgtk-3-doc  3.24.5-1

-- no debconf information

Bug#923282: freezegun breaks cached-property autopkgtest

[Mathias Behrle]

* Paul Gevers: " Fwd: Bug#923282: freezegun breaks cached-property
  autopkgtest" (Tue, 12 Mar 2019 21:51:28 +0100):

Hi all,

> [ bounced, trying again.
> 
>  Forwarded Message 
> Subject: Re: Bug#923282: freezegun breaks cached-property autopkgtest
> Date: Tue, 5 Mar 2019 19:35:35 +0100
> From: Paul Gevers 
> To: 923...@bugs.debian.org, Mathias Behrle , Dominik
> George 
> 
> Hi all,
> 
> On Wed, 27 Feb 2019 00:38:16 +0100 Mathias Behrle 
> wrote:> I don't see how
> > anything could be done from the side of cached_property at this stage of the
> > freeze. Therefore I am bumping the bug to severity serious to be safe this
> > version of freezegun will not migrate to testing and assigning to
> > freezegun.  
> 
> Keeping this version of freezegun out of buster for this is trading one
> RC bug versus another.
> 
> Mathias, could you please check if you can make cached_property
> compatible with the current freezegun in unstable, as that means we
> could move things forward.

My research shows that the issue is known for cached_property since 5 Nov 2018
[1], related issues for freezegun date from 21 Oct 2018 [2] resp. 17 Oct 2018
[3]. Indeed freezegun obviously introduced substantial API changes from 0.3.10
to 0.3.11 (btw in no way following semver).

What can be done in the current situation:

1) I really don't see what can be done on the side of cached_property. No
solution so far was able to workaround the test failures acording to [1]. If
there is any input from the freezegun maintainers how the tests could be
changed to pass I am all open for it.

2) freezegun 0.3.11 was released on 15 Oct 2018 [4] and there seem to be some
more recent commits related to this issue (e.g. [5]). I would propose to
cherry-pick some relevant commits or to package current trunk from git to see
if it solves the issues.

3) As a last resort the release team should be involved to evtl. mark the issue
as ignore for buster.

4) If that should be impossible/not desired I would be willing as a very very
last resort to disable temporarily the relevant autopkgtests in cached_property.
Basically cached_property *is* and *was* working, it is only that the tests are
failing due to API incompatibilities introduced by a test utility (freezegun)
during or shortly before the soft freeze. 


> Dominik, did you investigate if a different solution for the FTBFS of
> freezegun in bug 916702 [1] was possible?
> 
> Federico, I would appreciate it when you would share your opinion on how
> to solve the freezegun situation for buster.
> 
> Time is ticking.

My personal preference obviously goes to 1) or 2). Please advise on how to
proceed further.

Mathias

[1] https://github.com/pydanny/cached-property/issues/131
[2] https://github.com/ktosiek/pytest-freezegun/issues/6
[3] https://github.com/spulec/freezegun/issues/269
[4] https://pypi.org/project/freezegun/#history
[5]
https://github.com/spulec/freezegun/commit/028dee229f06d200d0f79a130deaad65b14779ef


-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#757697: support arch autodetection on bootloader isolinux

[adrian15]

Can you any of the new maintainers take a look at this request?

I attach an updated patch that adds arch autodetection support to isolinux.

I've tried it in actual hardware booting in BIOS-only mode and it works
as expected.


Thank you very much!


Note that the grub2's support arch autodetection is already present in
binary_loopback_cfg. So I only want isolinux support to be added.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 13730f7f8db6eb9bdd82a06b5c38148c56b2278d Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Sun, 7 Dec 2014 17:46:07 +0100
Subject: [PATCH] Syslinux build now supports: Arch detection It adds a default
 boot option that automatically chooses either amd64 or x86 kernel depending
 on the detected cpu flags.

---
 scripts/build/binary_syslinux | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/scripts/build/binary_syslinux b/scripts/build/binary_syslinux
index bb6658826..24ddbb445 100755
--- a/scripts/build/binary_syslinux
+++ b/scripts/build/binary_syslinux
@@ -147,6 +147,12 @@ case "${LB_BUILD_WITH_CHROOT}" in
 		;;
 esac
 
+# Copy necessary syslinux modules
+for module in ifcpu64.c32
+do
+	cp "chroot/usr/lib/syslinux/modules/bios/${module}" "${_TARGET}/"
+done
+
 # Configuring files
 if [ -e "${_TARGET}/live.cfg.in" ]
 then
@@ -169,6 +175,22 @@ then
 			;;
 
 		*)
+			_AMD64_686_NUMBER="0"
+
+			for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+			do
+if [ "${_FLAVOUR}" = "amd64" -o "${_FLAVOUR}" = "686" ] ; then
+	_AMD64_686_NUMBER="$((${_AMD64_686_NUMBER} + 1))"
+fi
+			done
+
+			if [ "${_AMD64_686_NUMBER}" -ge 2 ] ; then
+_AMD64_LABEL=$(cat "${_TARGET}/live.cfg.in" | grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e "s|@FLAVOUR@|""amd64""|g")
+_686_LABEL=$(cat "${_TARGET}/live.cfg.in" | grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e "s|@FLAVOUR@|""686""|g")
+_AUTO_LABEL=$(cat "${_TARGET}/live.cfg.in" | grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e "s|@FLAVOUR@|""autodetect""|g")
+_AUTO_MENU_LABEL=$(cat "${_TARGET}/live.cfg.in" | grep "menu label" | grep -v "failsafe" | sed 's/.*menu label //g' | sed -e "s|@FLAVOUR@|""auto""|g")
+			fi
+
 			_NUMBER="0"
 
 			for _FLAVOUR in ${LB_LINUX_FLAVOURS}
@@ -183,7 +205,22 @@ then
 	echo "" >> "${_TARGET}/live.cfg"
 	grep -v 'menu default' "${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
 else
-	cat "${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
+	if [ "${_AMD64_686_NUMBER}" -ge 2 ] ; then
+		cat << EOF >> "${_TARGET}/live.cfg"
+label ${_AUTO_LABEL}
+	menu label ${_AUTO_MENU_LABEL}
+	com32 ifcpu64.c32
+	append ${_AMD64_LABEL} -- ${_686_LABEL} -- ${_686_LABEL}
+
+EOF
+	fi
+
+
+	if [ "${_AMD64_686_NUMBER}" -ge 2 ] ; then
+		grep -v 'menu default' "${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
+	else
+		cat "${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"
+	fi
 fi
 
 sed -i -e "s|@FLAVOUR@|${_FLAVOUR}|g" \

Bug#924439: unblock: debian-edu-config/2.10.62

[Dominik George]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package debian-edu-config

OK, first the most honest part: I f***ed up. 2.10.61 was uploade well before
full freeze, fixing a list of bugs. I then wanted to fix two critical bugs
which prevented parts of the package from workign at all, and when
uploading, failed at primary school maths and thought it would get in before
the full freeze. This also prevented the migration of 2.10.61.

The upload's impact is limited to the Debian Edu pure blend. It fixes the
following issues, which are not all tracked as a bug in BTS:

 * Fix handling of LDAP certificates on LTSP clients, especially
   verification.
 * Fix screen locking on LTSP clients with Xfce.
 * Replace the old skolelinux popcon service with only the Debian one.
 * Fix handling of LTSP client config from LDAP.

All these are bugs that would probably grant an unblock. Looking at the
situation described at the top, I kindly ask you to approve and unblock it
without adding it as separate bug reports belatedly.

Thanks!

unblock debian-edu-config/2.10.62

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQKJBAEBCgBzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlyIPugxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylu1aD/9J4efC
SUM3sHLVU+0EpToTTVCcFDas2JGK23y81NjXZ7wXzl9T6m7v2Lr/xScZIEQFy0wp
MtJy2/6g3oVsYIFU7q2MpsTq917qcVugOLFqtAFB76+fxsY/saOyKDttOSnEpOcf
nnEOf9mJbXh6gVdlgbpTkkGN1ZUsVy8MAbGuENLLo9S1h70rsHGCkVW5mNmAqpWR
F3EIonLweCPcCAqJ5mcTxeW2g8ekHOSKiQmlxlDYreDpnHlGzTXN5rr+pm/uy48B
Z38c98ym1IwYeG0t7B+JfTlHJ/J/NekRZbYZ+yh9TC8B3VXXakqrs/O9HXv4upG6
jKsNNgBXxgEu+EO/JPS0HtKKeFy5A8u3oCZ0cTiHR2Zksyh3qVuk9Mo7xRVdx86D
7OgTvBcxIf43z5ZFPcrKSId5CVRLGDD4kPNSgCFFeZDHZM7gZidOqE6SmfdGaldK
gJIokBfKbEo2nyPYgA0z8ECppvImt6AYV2PK/m4eUCq6IonF/IbWidgb/tN6wc+3
UlLTA/9e4bJh009Gqmx/8jp4KxoZ1ASQCqe/ORJVghjhJQkA0i58n3iqB1CyuVot
icXMI17IkrY29XIUdoqRTaZxm9KC2c5x8nLn7qx/VnhPMe/FjfRo/HHs4GI69DS7
VqbOB3pqv/jyi2wp+m/onyvR9LMFBDNrALJGVA==
=dom6
-END PGP SIGNATURE-
diff -Nru debian-edu-config-2.10.60/cf3/cf.workarounds 
debian-edu-config-2.10.62/cf3/cf.workarounds
--- debian-edu-config-2.10.60/cf3/cf.workarounds2019-02-12 
14:58:47.0 +0100
+++ debian-edu-config-2.10.62/cf3/cf.workarounds2019-02-23 
17:12:47.0 +0100
@@ -22,5 +22,13 @@
 "/etc/resolvconf/update-libc.d/squid"
   link_from => ln_s("/usr/share/debian-edu-config/squid.resolvconf"),
   move_obstructions => "true";
+
+commands:
+
+  debian.xfce.(ltspclient|ltspserver).installation::
+  # Provide a screensaver as a workaround for #922718 (fixed in experimental
+  # but not in Buster). FIXME: Check if this is still needed for Bullseye.
+"/usr/bin/apt-get install -y xscreensaver"
+  contain => in_shell;
 }
 
diff -Nru debian-edu-config-2.10.60/debian/changelog 
debian-edu-config-2.10.62/debian/changelog
--- debian-edu-config-2.10.60/debian/changelog  2019-02-12 15:00:57.0 
+0100
+++ debian-edu-config-2.10.62/debian/changelog  2019-03-01 12:50:01.0 
+0100
@@ -1,3 +1,32 @@
+debian-edu-config (2.10.62) unstable; urgency=medium
+
+  * get-ldap-ltsp-config: Fix detection of MAC address.
+  * get-ldap-ltsp-config: Fix extraction of ltspConfig from LDAP.
+  * update-hostname-from-ip: Always print hostname if -n is used.
+  * Add myself as Uploader.
+
+ -- Dominik George   Fri, 01 Mar 2019 12:50:01 +0100
+
+debian-edu-config (2.10.61) unstable; urgency=medium
+
+  [ Wolfgang Schweer ]
+  * cf3/cf.workarounds:
+- Provide Xfce screensaver for LTSP clients (workaround for bug #922718,
+  fixed in experimental but unlikely to be fixed in Buster).
+  * Improve LDAP server certificate check:
+- tools/create-debian-edu-certs:
+  Make /etc/debian-edu/www/debian-edu-bundle.{crt,pem} downloadable.
+- debian-edu-config.fetch-ldap-cert:
+  Verify the LDAP server cert using the downloaded Debian-Edu_rootCa one.
+  * testsuite/{ldap-client,ldap-server,sudo,webcache,webserver}:
+- Fix scripts to match the recent configuration changes.
+
+  [ Holger Levsen ]
+  * www/index* and www/*.po: replace http://popcon.skolelinux.org with
+https://popcon.debian.org as the former is unmaintained.
+
+ -- Holger Levsen   Sun, 24 Feb 2019 18:28:43 +0100
+
 debian-edu-config (2.10.60) unstable; urgency=medium
 
   [ Wolfgang Schweer ]
diff -Nru 

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 07:10:09PM -0400, Reinhard Tartler wrote:
> On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:
> 
> > On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> > >Depends: libavcodec58 (= 7:4.1.1-2),
> > > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> > libc6
> > > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > > libswscale5 (= 7:4.1.1-2)
> > >  Suggests: ffmpeg-doc
> >
> > You might want to add a Suggests on ffplay, as well.
> >
> 
> Good idea, done.
> 
> The changes are in the 'master' branch of our packaging repository now.
> Unfortunately, we missed the Debian freeze. Not sure if this is worth
> asking for a freeze exception.
> 
> What do you guys think?

Speaking for myself only, all the systems on which this might end up
installed run sid. And the previous Debian stable had this dependency,
so this isn't a regression. I'd suggest not asking for a freeze
exception.

Bug#924438: unblock: pyglet/1.3.0-2

[Scott Kitterman]

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

Please unblock package pyglet

Unfortunately, due to my miscalculation by a few hours of when the freeze 
would hit, unstable is now blocked for pyglet for future uploads to support 
buster.  If I had calculated better, I would have uploaded to experimental, 
since the driver for getting 1.3.0-2 uploaded was to add python3 support to 
enable qgis to move to python3 and Qt5 (important for Bullseye, but not going 
to make Buster).

On balance, I think it would be better to unblock the current pyglet upload, 
get it into Buster early in the freeze, and then have a clear path (that 
doesn't require TPU) if any RC issues are identified during the freeze.

This is a very low risk unblock.  There are three changes to the installed 
binary packages as a result of this update:

 - python3-pyglet added (zero regression risk, entirely new binary package)
 - examples files are now compressed (zero regression risk, they aren't   
   executed)
 - depends/provides are cleaned up (the deleted Depends/Provides have been no-
   ops for multiple release cycles)

I am attaching both the usual source debdiff and a binary debdiff to show that 
the installed package is unchanged in any technically meaningful way.

Please unblock, I think it's better to do this now than potentially face it 
later when determining how to deal with some new RC issue.

Thanks,

Scott K

unblock pyglet/1.3.0-2
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet-1.3.0.egg-info/PKG-INFO
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet-1.3.0.egg-info/dependency_links.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet-1.3.0.egg-info/top_level.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet-1.3.0.egg-info/zip-safe
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/__init__.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/__init__.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/base.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/carbon.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/cocoa.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/win32.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/app/xlib.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/__init__.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/base.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/carbon.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/cocoa.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/win32.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/canvas/xlib.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/canvas/xlib_vidmoderestore.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/clock.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/com.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/compat.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/debug.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/pyglet/event.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/_dummy_thread/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/_markupbase/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/_thread/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/builtins/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/configparser/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/copyreg/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/html/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/html/entities.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/html/parser.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/http/__init__.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/http/client.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/pyglet/extlibs/future/py2/http/cookiejar.py

Bug#919588: [Pkg-javascript-devel] Bug#919588: nodejs: FTBFS randomly

[Santiago Vila]

retitle 919588 nodejs: FTBFS randomly 
(parallel/test-net-listen-after-destroying-stdin fails)
thanks

Hi.

Today I built nodejs the standard way (i.e. without eatmydata) 26 times,
of which it failed 12 times. This makes the failure rate to be around
46%, too high for my taste.

For these builds I was using a mix of self-hosted KVM machines and
n1-standard-1 instances from GCE.

Failed build logs available here:

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

Fortunately the (single) failing test was always the same, the one
I've just put in the bug title:

not ok 1208 parallel/test-net-listen-after-destroying-stdin

So I would definitely disable such test for buster.

Alternatively, if you feel brave enough to investigate and debug why
the test fails so much (and fix it the "proper" and "elegant" way),
I will gladly offer ssh access to an instance where this "randomness"
is reproducible (so to speak). If interested, please contact me
privately for details.

Thanks a lot.

Bug#924437: [wesnoth] High CPU Load

[tra_cker]

Package: wesnoth
Version: 1:1.14.5-1
Severity: normal
 
--- Please enter the report below this line. ---
 
Wesnoth produces high load on my CPU while playing. This has been already 
reported also in the wesnoth forum
https://www.wesnoth.org/forum/viewtopic.php?t=48666 by other people.
The reported workaround to launch wesnoth with
 
OMP_WAIT_POLICY="passive" wesnoth
 
works for me.
 
 
 
--- System information. ---
Architecture:
Kernel: Linux 4.19.0-2-amd64
 
Debian Release: buster/sid
500 xenial updates.signal.org
500 testing ftp.de.debian.org
500 stretch download.docker.com
 
--- Package information. ---
Depends (Version) | Installed
=-+-
wesnoth-1.14 (>= 1:1.14.5-1) | 1:1.14.5-1
wesnoth-1.14-data (= 1:1.14.5-1) | 1:1.14.5-1
 
 
Package's Recommends field is empty.
 
Package's Suggests field is empty.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:

> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> >Depends: libavcodec58 (= 7:4.1.1-2),
> > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> libc6
> > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > libswscale5 (= 7:4.1.1-2)
> >  Suggests: ffmpeg-doc
>
> You might want to add a Suggests on ffplay, as well.
>

Good idea, done.

The changes are in the 'master' branch of our packaging repository now.
Unfortunately, we missed the Debian freeze. Not sure if this is worth
asking for a freeze exception.

What do you guys think?

-- 
regards,
Reinhard

Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

Control: tag -1 patch

On 3/10/19 9:32 PM, Arnaud Rebillout wrote:

>>
>> As far as I understand the packaging, it seems that all of them could be 
>> easily added to
>> https://sources.debian.org/src/docker.io/18.09.1+dfsg1-5/debian/golang-github-docker-docker-dev.install
>>
>> Is this assumption right? Are there compelling reasons against doing that?
> 
> I think you're correct, you should give it a try, and if it works feel
> free to commit on the docker.io salsa repo.
> [...]

Hi Arnaud,

thank you very much for your detailed explanation, while surprising, it does 
help with the understanding of this source package significantly.

I've implemented the change and confirmed that the attached patch does allow 
github.com/openstack/imagebuilder to be built successfully. As suggested, I've 
tried to push to salsa, but it seems I'm not permissioned to do so (docker.io 
is not under the go-team umbrella):

  $ git push 
  GitLab: You are not allowed to push code to this project.
  fatal: Could not read from remote repository.

Would you be able to upload the patch to experimental anytime soon? If it 
helped, I'd be happy to upload this patch as an NMU to experimental myself. 
Please let me know what works for you best.

Cheers,
-rt
From 4abbd5b15e0735443cf8ad54165ab054dcab6f14 Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Tue, 12 Mar 2019 18:53:36 -0400
Subject: [PATCH] github-golang-docker-docker-dev: add missing sources

While working on the package 'golang-github-openshift-imagebuilder', it
turns out that some sources that are contained in the docker.io source
package were left out at installation time. This commit includes
some sources that allow golang-github-openshift-imagebuilder to be
built.

Closes: #924257
---
 debian/golang-github-docker-docker-dev.install | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/golang-github-docker-docker-dev.install b/debian/golang-github-docker-docker-dev.install
index b5cdcebe..fc6c5861 100644
--- a/debian/golang-github-docker-docker-dev.install
+++ b/debian/golang-github-docker-docker-dev.install
@@ -11,9 +11,12 @@
 ## Engine
 engine/dockerversionusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/apiusr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/builderusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/cliusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/client usr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/container  usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/errdefsusr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/image  usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/opts   usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/pkgusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/reference  usr/share/gocode/src/github.com/docker/docker/
@@ -31,6 +34,10 @@ engine/dockerversionusr/share/gocode/src/github.
 .gopath/src/github.com/docker/libnetwork/typesusr/share/gocode/src/github.com/docker/libnetwork/
 
 
+## go-metrics
+.gopath/src/github.com/docker/go-metricsusr/share/gocode/src/github.com/docker/go-metrics
+
+
 ## Sub-vendoring:
 engine/vendor/github.com/containerd/continuity/driverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
 engine/vendor/github.com/containerd/continuity/pathdriverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
@@ -39,3 +46,5 @@ engine/vendor/github.com/Nvveen/Gottyusr/share/gocode/sr
 
 distribution/reference   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/docker/distribution/
 distribution/digestset   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/docker/distribution/
+
+cli/vendor/github.com/moby/buildkit/ usr/share/gocode/src/github.com/moby/
-- 
2.11.0

Bug#914992: network-manager-openconnect-gnome: Unable to select realm when connecting to Juniper VPN

[Jonathan McDowell]

On Tue, Mar 12, 2019 at 10:31:31AM -0700, Mike Miller wrote:
> On Thu, Nov 29, 2018 at 10:49:19 +, Jonathan McDowell wrote:
> > When trying to login to a Juniper Network Connect VPN using the NM VPN
> > login dialog I get a form that provides a drop down "realm" to select as
> > well as requesting the username + password. Upon selecting a realm other
> > than the default as soon as focus switches away from that form entry the
> > realm switches back to the initial entry. This means it's impossible to
> > use the graphical login interface for a Juniper VPN.
> 
> Does this work for you now with openconnect 8.02-1?
> 
> There is an upstream bug report, where it is reported that updating to
> openconnect 8 fixed this.
> 
>   https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/5
> 
> If it still persists for you, can you comment on this upstream report?

I can confirm that using my Buster/testing machine I'm now able to
correctly select the realm and login to the VPN. Versions are:

openconnect 8.02-1
network-manager-openconnect-gnome   1.2.4-2

J.

-- 
Professional Geek + recovering Law Student
Do not expose this tagline to direct sunlight.


signature.asc
Description: PGP signature

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Tue, Mar 12, 2019 at 07:30:21PM +0100, Helmut Grohne wrote:

> > Do any of them still don't know that base-passwd should be configured
> > first because otherwise any other package using root (be it base-files
> > or any other) will fail? I think this was already settled in the last
> > discussion we had about this several years ago.
> 
> multistrap doesn't take care of this and you can provoke a
> base-files.postinst failure this way.

In such case I would say that as a bootstrapping tool it's not doing
its job properly.

The first rule of a bootstrapping tool is that it has to work.
(And there are actually no other rules. As far as it does its job,
you are allowed to do all sorts of dirty hacks).

Bootstrapping tools exist so that we don't have to worry about
dependencies on essential packages. It has always been my opinion that
if we start to do hacks here and there so that bootstrapping tools
work properly, we are already doing it wrong.

> > Can you provide at least a bug number for the bootstrapping tool that
> > apparently still tries to configure all packages at once, or
> > base-passwd and base-files in the same row?
> 
> #924401, but I'm not yet sure which part we need to fix.

Hmm, but that's the present bug.

I meant a bug in a bootstrapping tool.

> [,,,]
> Just because debootstrap encodes a ton of hacks to make things barely
> work (and break every so often) doesn't mean we have to maintain them
> until eternity.

I would say: Just because people writing new bootstrapping tools seem
to forget the lessons learned from previous bootstrapping tools, we
have to learn again what bootstrapping really means: It's not adding
hacks to the normal packages, it's concentrating all the hacks in the
bootstrapping tools, so that we can keep ordinary packages clean of
hacks.

(Or at least that's what I think it was the idea behind the essential
definition).

Thanks.

Bug#924204: persepolis: the packaged version is outdated

[Salman Mohammadi]

Dear Moein,

Would you please specify what the problem is?

I could create the deb package and then successfully installed it, and
also checked new features like downloading from youtube, and it was
working for me.

To build the deb package I used

    $ dpkg-buildpackage -b -rfakeroot -us -uc


On Sun, 10 Mar 2019 23:41:18 +0100 Moein Alinaghian 
wrote:

> Dear Salman,
>
> The problem is the incompatibility of the setup.py and debianhelper.
> It can be solved either with a patch in the Debian Package or directly
> in upstream. Solving it in the upstream is definitely a better idea,
> but it requires to test it in different operating systems, as it
> suppose to work in another operating systems as well.
>
> The best help would be rewriting a compatible setup.py and send it to
> the upstream.
>
> --
> Sincerely yours,
> Moein Alinaghian
>
>

Bug#924435: rainloop: Upstream development recently declined: is it still suitable for Buster?

[Lars Kruse]

Package: rainloop
Severity: normal

Dear Maintainer,

I am a user of rainloop and I am glad, that you packaged it.

But recently I took a look at the development activity:
 https://github.com/RainLoop/rainloop-webmail/graphs/contributors

This looks a bit bleak :(
(there are only a few maintenance commits in the last year)

Even though I would be happy, if rainloop were part of Buster, I
could also imagine, that the lack of upstream activity (in case it
continues to be low) could place quite a burden on your shoulder for
the next years while Buster is supported.
Thus maybe you want to consider removing the package from testing and
let users install it from unstable (without expecting proper security
support and so on).


Please consider this just as a friendly hint.  Feel free to close this
issue without comment, if you think rainloop deserves a place in Buster.

Thank you!

Cheers,
Lars

Bug#924436: unblock: node-gyp/3.8.0-6

[Jérémy Lal]

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

Please unblock package node-gyp

- fixes #921625: node-gyp cannot extract tarballs,
something that happens when installing big projects
from npm.
- removes temporarily-needed Breaks:node-modern-syslog,
which was only there to speed up migration of nodejs
- adds upstream tests as autopkgtest, but not
during build to avoid surprises this late winter.

Please find the debdiff attached.

unblock node-gyp/3.8.0-6

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru node-gyp-3.8.0/debian/changelog node-gyp-3.8.0/debian/changelog
--- node-gyp-3.8.0/debian/changelog 2019-01-28 16:40:25.0 +0100
+++ node-gyp-3.8.0/debian/changelog 2019-03-04 00:51:30.0 +0100
@@ -1,3 +1,22 @@
+node-gyp (3.8.0-6) unstable; urgency=medium
+
+  * Upstream test suite depends on build-essential
+
+ -- Jérémy Lal   Mon, 04 Mar 2019 00:51:30 +0100
+
+node-gyp (3.8.0-5) unstable; urgency=medium
+
+  [ Mattia Rizzolo ]
+  * Remove the Breaks:node-modern-syslog added in the previous
+upload: it was a workaround to avoid ci testing regression.
+
+  [ Jérémy Lal ]
+  * Upstream support for node-tar 3 (Closes: #921625)
+  * Drop node-fstream dependency, unneeded with tar3-compat.patch
+  * Add upstream test suite to autopkgtests
+
+ -- Jérémy Lal   Sat, 02 Mar 2019 23:11:39 +0100
+
 node-gyp (3.8.0-4) unstable; urgency=medium
 
   * Team upload
diff -Nru node-gyp-3.8.0/debian/control node-gyp-3.8.0/debian/control
--- node-gyp-3.8.0/debian/control   2019-01-28 16:37:51.0 +0100
+++ node-gyp-3.8.0/debian/control   2019-03-02 19:32:09.0 +0100
@@ -18,7 +18,6 @@
  , nodejs
  , libnode-dev
  , gyp (>= 0.1+20150913git1f374df9)
- , node-fstream
  , node-glob
  , node-graceful-fs
  , node-mkdirp
@@ -31,7 +30,6 @@
  , node-tar
  , node-which
 Recommends: build-essential
-Breaks: node-modern-syslog (<< 1.1.4-2)
 Description: Native addon build tool for Node.js
  node-gyp is a cross-platform command-line tool written in Node.js
  for compiling native addon modules for Node.js.
diff -Nru node-gyp-3.8.0/debian/patches/series 
node-gyp-3.8.0/debian/patches/series
--- node-gyp-3.8.0/debian/patches/series2019-01-28 16:31:48.0 
+0100
+++ node-gyp-3.8.0/debian/patches/series2019-03-02 18:55:56.0 
+0100
@@ -2,3 +2,4 @@
 2003_fPIC_ia32.patch
 kfreebsd.patch
 link_libnode.patch
+tar3-compat.patch
diff -Nru node-gyp-3.8.0/debian/patches/tar3-compat.patch 
node-gyp-3.8.0/debian/patches/tar3-compat.patch
--- node-gyp-3.8.0/debian/patches/tar3-compat.patch 1970-01-01 
01:00:00.0 +0100
+++ node-gyp-3.8.0/debian/patches/tar3-compat.patch 2019-03-02 
18:55:42.0 +0100
@@ -0,0 +1,125 @@
+From 5f924ce62c9bca9ab9c2e547bfb87b9a391271ed Mon Sep 17 00:00:00 2001
+From: isaacs 
+Date: Tue, 30 May 2017 20:52:45 -0400
+Subject: [PATCH] Upgrade to tar v3
+
+Tar version 3 performs better and is more well tested than its
+predecessor.  npm will be using this in the near future, so there is no
+benefit in shipping a node-gyp that uses the slower and less reliable
+fstream-based tar.
+
+This drops support for node 0.x, and thus should be considered a
+breaking semver-major change.
+
+PR-URL: https://github.com/nodejs/node-gyp/pull/1212
+Reviewed-By: Refael Ackermann 
+Reviewed-By: Ben Noordhuis 
+Reviewed-By: Gibson Fahnestock 
+---
+ lib/install.js | 38 --
+ package.json   |  5 ++---
+ 2 files changed, 18 insertions(+), 25 deletions(-)
+
+--- a/lib/install.js
 b/lib/install.js
+@@ -20,10 +20,8 @@
+   , rm = require('rimraf')
+   , path = require('path')
+   , crypto = require('crypto')
+-  , zlib = require('zlib')
+   , log = require('npmlog')
+   , semver = require('semver')
+-  , fstream = require('fstream')
+   , request = require('request')
+   , mkdir = require('mkdirp')
+   , processRelease = require('./process-release')
+@@ -148,41 +146,33 @@
+   var tarPath = gyp.opts.tarball
+   var badDownload = false
+ , extractCount = 0
+-, gunzip = zlib.createGunzip()
+-, extracter = tar.Extract({ path: devDir, strip: 1, filter: isValid })
+ 
+   var contentShasums = {}
+   var expectShasums = {}
+ 
+   // checks if a file to be extracted from the tarball is valid.
+   // only .h header files and the gyp files get extracted
+-  function isValid () {
+-var name = this.path.substring(devDir.length + 1)
+-var isValid = valid(name)
+-if 

Bug#924434: unblock pre-approval: movim/0.14.1-4

[Dominik George]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package movim

Upstream fixed a few semi-critical bugs, which we here would call important.
I added the bugs to the BTS and backported the fixes form the new upstream
release, they are listed in the attached
debdiff/changelog.

If you are up to gifts today, you may as well pre-approve the upload of 0.14.2,
the new upstream release. It does not include much more, only some more
minor bugfixes and some UI improvements in CSS ;).

unblock movim/0.14.1-4

-BEGIN PGP SIGNATURE-

iQKJBAEBCgBzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlyILzcxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylngIEAC9TpaQ
MUrSe6vqDXtcrW+wDQ3dMgovdLH2fxpjvQ3SUvV9vAuOQc/9y+e0AllkqXgFEbEH
TDLS0QoC9VpDun6ScPIJlCYHs2LfQc2HAcjlqJM/xToXAWzyMhafkt1B28v8m1y8
/LYowOfUR6e0LWmq2D9pBxaeRaGg0Ree5/vX7APuWLbAY0TIMM506p09yXVnuHvJ
2MTFdlyi6G0NK0ZY0GAa9pxQML7nC8ahO92EQKHVFpj9Yq0oRYni0OAiHdkYJn+7
GYLsnbx9g9XAYw97QGa7ucpR1PUg1jKPSZeLoSZNlXOSXBL/FQvo474/E9Z8RaVi
V+q9lJjpjZ5DGiXy6fscUAhYM2rdLrvN49o0SjguVLehwwQKSW4wc2prY41SEG5g
Hd4z48f7s6yDpmuoXeweY44MwPMh8UIbHDLlbZ+bIv9ZNLC3T1Niyt/NTnehBpyE
xsZUqZwzH0aENr8f9/Mo8tZfvDkKkH6kWqGtW/Xam721mBERISUZ3dMwbyo7h32q
ffMnL2+Ms8YjxmT+4l+iG/65kUxytdOWEMlFrQyJQTthrfrw5ygPBy2SrYBdrF2f
37VBDzRPYDKWxmoGdFYEYQ6YnHKITJDmI1mvrSTYzYZXtNwvOk0gMIiMlQuWBQL6
P7bdvSxVeqqqRyyMI+k6jef8LBUDajisNhRe9w==
=NKPE
-END PGP SIGNATURE-
diff -Nru movim-0.14.1/debian/changelog movim-0.14.1/debian/changelog
--- movim-0.14.1/debian/changelog   2019-02-23 17:19:27.0 +0100
+++ movim-0.14.1/debian/changelog   2019-03-12 22:49:08.0 +0100
@@ -1,3 +1,11 @@
+movim (0.14.1-4) unstable; urgency=medium
+
+  * Restart movim daemon if it exits. (Closes: #924429)
+  * Fix MUC autojoin when used in parallel with other clients. (Closes: 
#924431)
+  * Allow long descriptions of MUC rooms. (Closes: #924432)
+
+ -- Dominik George   Tue, 12 Mar 2019 22:49:08 +0100
+
 movim (0.14.1-3) unstable; urgency=medium
 
   * Fix bug number in last changelog.
diff -Nru movim-0.14.1/debian/patches/fix_924429.diff 
movim-0.14.1/debian/patches/fix_924429.diff
--- movim-0.14.1/debian/patches/fix_924429.diff 1970-01-01 01:00:00.0 
+0100
+++ movim-0.14.1/debian/patches/fix_924429.diff 2019-03-12 22:49:01.0 
+0100
@@ -0,0 +1,16 @@
+From: Dominik George 
+Subject: Restart movim from systemd when it exits due to database outage or 
the like
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924429
+Origin: 
https://github.com/movim/movim/commit/4d2f0704de590db33567b8f6b843f2ed9e6fcf8c
+Applied-Upstream: 0.14.2
+--- a/etc/systemd/system/movim.service
 b/etc/systemd/system/movim.service
+@@ -13,6 +13,8 @@ WorkingDirectory=/usr/share/movim/
+ StandardOutput=syslog
+ SyslogIdentifier=movim
+ PIDFile=/run/movim.pid
++Restart=on-failure
++RestartSec=10
+ 
+ [Install]
+ WantedBy=multi-user.target
diff -Nru movim-0.14.1/debian/patches/fix_924431.diff 
movim-0.14.1/debian/patches/fix_924431.diff
--- movim-0.14.1/debian/patches/fix_924431.diff 1970-01-01 01:00:00.0 
+0100
+++ movim-0.14.1/debian/patches/fix_924431.diff 2019-03-12 22:49:08.0 
+0100
@@ -0,0 +1,16 @@
+From: pitchum
+SubjectL Fix MUC autojoin with non-int autojoin values saved by other clients.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924431
+Origin: 
https://github.com/movim/movim/commit/54d5fe37080f78b6ed7e74d73b04ebd49307b025
+Applied-Upstream: 0.14.2
+--- a/lib/moxl/src/Moxl/Xec/Action/Bookmark/Get.php
 b/lib/moxl/src/Moxl/Xec/Action/Bookmark/Get.php
+@@ -35,7 +35,7 @@ class Get extends Action
+ $conference->conference = (string)$c->attributes()->jid;
+ $conference->name   = (string)$c->attributes()->name;
+ $conference->nick   = (string)$c->nick;
+-$conference->autojoin   = (int)$c->attributes()->autojoin;
++$conference->autojoin   = 
filter_var($c->attributes()->autojoin, FILTER_VALIDATE_BOOLEAN);
+ 
+ $conference->save();
+ }
diff -Nru movim-0.14.1/debian/patches/fix_924432.diff 
movim-0.14.1/debian/patches/fix_924432.diff
--- movim-0.14.1/debian/patches/fix_924432.diff 1970-01-01 01:00:00.0 
+0100
+++ movim-0.14.1/debian/patches/fix_924432.diff 2019-03-12 22:49:08.0 
+0100
@@ -0,0 +1,47 @@
+From: Jaussoin Timothée (edhe...@movim.eu>
+Subject: Fix database field for MUC description.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924432
+Origin: 
https://github.com/movim/movim/commit/a9458dd75a000cc5fd51702013eb5b885aed0d83
+Applied-Upstream: 0.14.2
+--- /dev/null
 
b/database/migrations/20190224220950_change_length_columns_conferences_rosters_users.php
+@@ -0,0 +1,39 @@
++schema->table('conferences', function(Blueprint $table) {
++ 

Bug#924433: stretch-pu: package nvidia-settings/390.116-1

[Andreas Beckmann]

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

Hi,

this is a new upstream version corresponding to the updated
nvidia-graphics-drivers package.
I don't want to mix the package versions in a way that features would be
missing.
This package has been requested to be unblocked for buster as
nvidia-settings-legacy-390xx.
The package is already uploaded.


Andreas


n-s-390.116-1.diff.gz
Description: application/gzip

Bug#865140: Broken with network-manager 1.8.0-5 (at least for split tunnel)

[Russ Allbery]

Mike Miller  writes:
> On Mon, Jun 19, 2017 at 09:07:44 -0700, Russ Allbery wrote:

>> After upgrading network-manager to 1.8.0-5 from 1.6.2-3, connecting to
>> a VPN with network-manager-openconnect still works but doesn't set up
>> the routing table entries properly.  (This is a split-tunnel VPN.)  I'm
>> guessing something changed in the NetworkManager internals that broke
>> part of this plugin.
>> 
>> The problem went away again after downgrading network-manager back to
>> 1.6.2-3.

> Unfortunately I can't easily test this to try to reproduce.

> Are you still affected by this bug with network-manager 1.14.6-2 and
> network-manager-openconnect 1.2.4-2 in testing?

> If so, it would be helpful to know if it's fixed in upstream git (it's
> been a long time since the last release), if there's an upstream issue,
> or what configuration is needed to reproduce this.

Sorry, I should have followed up.  This went away again quite some time
ago, and I no longer have any problems.  I think it may have been fixed in
1.8.2.

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

Bug#924432: movim: Cannot insert MUCs with too long description

[Dominik George]

Package: movim
Version: 0.14.1-3
Severity: important
Tags: upstream

The databsae field used for MUC descriptions is to oshort (shorter than
the description length allowed by XMPP). Thus, adding MUCs with a very
long description that are valid XMPP rooms fails.

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

Kernel: Linux 4.19.0-3-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)

Versions of packages movim depends on:
ii  composer1.8.4-1
ii  dbconfig-pgsql  2.0.11
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-open-sans 1.11-1
ii  libjs-favico.js 0.3.10~dfsg1-3
ii  php-cboden-ratchet  0.4.1-2
ii  php-cocur-slugify   3.1-1
ii  php-common  2:69
ii  php-curl2:7.3+69
ii  php-defuse-php-encryption   2.2.1-1
ii  php-dflydev-fig-cookies 2.0.0-1
ii  php-doctrine-dbal   2.9.2-1
ii  php-embed   3.3.9-1
ii  php-fabiang-sasl1.0.0-1
ii  php-gd  2:7.3+69
ii  php-htmlpurifier4.10.0-1
ii  php-illuminate-database 5.7.27-1
ii  php-imagick 3.4.3-4
ii  php-markdown1.8.0-1
ii  php-mbstring2:7.3+69
ii  php-monolog 1.24.0-1
ii  php-pgsql   2:7.3+69
ii  php-raintpl 3.1.0+dfsg-1
ii  php-ratchet-pawl0.3.4-1
ii  php-react-child-process 0.5.2-2
ii  php-react-dns   0.4.16-1
ii  php-react-http  0.8.3-3
ii  php-respect-validation  1.1.29-2
ii  php-robmorgan-phinx 0.9.2-1
ii  php-sqlite3 2:7.3+69
ii  php-symfony-console 3.4.22+dfsg-1
ii  php-xml 2:7.3+69
ii  php7.3-cli [php-cli]7.3.2-3
ii  php7.3-curl [php-curl]  7.3.2-3
ii  php7.3-gd [php-gd]  7.3.2-3
ii  php7.3-json [php-json]  7.3.2-3
ii  php7.3-mbstring [php-mbstring]  7.3.2-3
ii  php7.3-pgsql [php-pgsql]7.3.2-3
ii  php7.3-sqlite3 [php-sqlite3]7.3.2-3
ii  php7.3-xml [php-xml]7.3.2-3

Versions of packages movim recommends:
ic  apache2 [httpd]   2.4.25-3+deb9u6
ii  nginx-full [httpd]1.14.2-2
ii  php-fpm   2:7.3+69
ii  php7.3-fpm [php-fpm]  7.3.2-3

Versions of packages movim suggests:
ii  ejabberd  18.12.1-2

-- Configuration Files:
/etc/default/movim changed [not included]

-- debconf information excluded

Bug#924431: movim: Auto-joining chatrooms breaks when some other clients modify room bookmarks

[Dominik George]

Package: movim
Version: 0.14.1-3
Severity: important
Tags: upstream

Movim fails at correctly casting some data types found in the autojoin
attributes of room bookmarks to boolean, so orrectly parsing the
bookmarks breaks when another lcient uses, e.g., true as a boolean value
instead of 1. This is true forat least Gajim and poezio, two other very
relevant clients used in parallel with movim.

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

Kernel: Linux 4.19.0-3-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)

Versions of packages movim depends on:
ii  composer1.8.4-1
ii  dbconfig-pgsql  2.0.11
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-open-sans 1.11-1
ii  libjs-favico.js 0.3.10~dfsg1-3
ii  php-cboden-ratchet  0.4.1-2
ii  php-cocur-slugify   3.1-1
ii  php-common  2:69
ii  php-curl2:7.3+69
ii  php-defuse-php-encryption   2.2.1-1
ii  php-dflydev-fig-cookies 2.0.0-1
ii  php-doctrine-dbal   2.9.2-1
ii  php-embed   3.3.9-1
ii  php-fabiang-sasl1.0.0-1
ii  php-gd  2:7.3+69
ii  php-htmlpurifier4.10.0-1
iu  php-illuminate-database 5.7.27-1
ii  php-imagick 3.4.3-4
ii  php-markdown1.8.0-1
ii  php-mbstring2:7.3+69
ii  php-monolog 1.24.0-1
ii  php-pgsql   2:7.3+69
ii  php-raintpl 3.1.0+dfsg-1
ii  php-ratchet-pawl0.3.4-1
ii  php-react-child-process 0.5.2-2
ii  php-react-dns   0.4.16-1
ii  php-react-http  0.8.3-3
ii  php-respect-validation  1.1.29-2
ii  php-robmorgan-phinx 0.9.2-1
ii  php-sqlite3 2:7.3+69
ii  php-symfony-console 3.4.22+dfsg-1
ii  php-xml 2:7.3+69
ii  php7.3-cli [php-cli]7.3.2-3
ii  php7.3-curl [php-curl]  7.3.2-3
ii  php7.3-gd [php-gd]  7.3.2-3
ii  php7.3-json [php-json]  7.3.2-3
ii  php7.3-mbstring [php-mbstring]  7.3.2-3
ii  php7.3-pgsql [php-pgsql]7.3.2-3
ii  php7.3-sqlite3 [php-sqlite3]7.3.2-3
ii  php7.3-xml [php-xml]7.3.2-3

Versions of packages movim recommends:
ic  apache2 [httpd]   2.4.25-3+deb9u6
ii  nginx-full [httpd]1.14.2-2
ii  php-fpm   2:7.3+69
ii  php7.3-fpm [php-fpm]  7.3.2-3

Versions of packages movim suggests:
ii  ejabberd  18.12.1-2

-- Configuration Files:
/etc/default/movim changed [not included]

-- debconf information excluded

Bug#919699: Please support -w switch to halt(8)

[Andras Korn]

On Tue, Mar 12, 2019 at 06:37:45PM +, Dmitry Bogatov wrote:

Hi,

> [2019-03-11 16:24] Lorenzo Puliti 
> > Package: runit-init
> > Version: 2.1.2-25helpers1
> > Followup-For: Bug #919699
> >
> > Hi,
> >
> > >I am okay with accepting patch to implement writing `wtmp' entry, if it
> > >is reasonably small, but I would prefer to delegate it to external
> > >implementation, like https://git.suckless.org/utmp (not sure it is
> > >applicable).
> >
> > Just in case you don't know, there is already a 'sac' package that include a
> > 'writetmp - write special wtmp entries to a wtmp file.' program.
> >
> > https://packages.debian.org/sid/sac
> >
> > The only thing is that last sac release is dated around Dec 2004 and last
> > update of the Debian sac package is from Dec 2011, otherwise it looks the
> > right external tool.
> 
> Just noticed, that bin:runit too provides tool for wtmp -- utmpset(8).
> But it expects 'line' argument, and I do not know, what is correct value
> for it.
> 
> halt.c from src:sysvinit pass '~~' as line, but utmpset(8) rejects such
> usage. Any advice?

Indeed, sysvinit's halt.c does this:

write_wtmp("shutdown", "~~", 0, RUN_LVL, "~~");

and write_wtmp looks like this (some irrelevant lines omitted, some
commentary added):

void write_wtmp(
char *user, /* name of user */
char *id,   /* inittab ID */
int pid,/* PID of process */
int type,   /* TYPE of entry */
char *line) /* Which line is this */
{
int fd;
struct utmp utmp;
struct utsname uname_buf;
struct timeval tv;

/* [...] */

memset(, 0, sizeof(utmp));
#if defined(__GLIBC__)
gettimeofday(, NULL);
utmp.ut_tv.tv_sec = tv.tv_sec;
utmp.ut_tv.tv_usec = tv.tv_usec;
#else
time(_time);
#endif
utmp.ut_pid  = pid;
utmp.ut_type = type;
strncpy(utmp.ut_name, user, sizeof(utmp.ut_name));
strncpy(utmp.ut_id  , id  , sizeof(utmp.ut_id  ));
strncpy(utmp.ut_line, line, sizeof(utmp.ut_line));

/* Put the OS version in place of the hostname */
if (uname(_buf) == 0)
strncpy(utmp.ut_host, uname_buf.release, sizeof(utmp.ut_host));

#if HAVE_UPDWTMP
updwtmp(WTMP_FILE, ); /* Linux, NetBSD, Solaris etc. have updwtmp 
*/
#else
write(fd, (char *), sizeof(utmp)); /* fallback */
#endif
close(fd);
}

In contrast, utmpset.c from runit does:

/* [...] */

  if (utmp_logout(*argv) == -1)
strerr_die4x(111, WARNING, "unable to logout line ", *argv,
 " in utmp: no such entry");
  if (wtmp)
if (wtmp_logout(*argv) == -1)
  strerr_die4sys(111, WARNING,
 "unable to logout line ", *argv, " in wtmp: ");

utmp_logout() tries to find a matching login entry, and since there is none,
it returns an error; thus, wtmp_logout is never called.

I tried to put the wtmp_logout() call above the utmp_logout() call, and
stepped through the wtmp_logout() function with gdb; it succeeds and writes
a record to wtmp, but it's in the wrong format.

Examining the code in wtmp_logout(), it seems it sets ut_type to
DEAD_PROCESS unconditionally, but it would need to be RUN_LVL; also, it
doesn't set ut_user or ut_id.

I have to conclude that utmpset is incapable of generating a shutdown
record.

I think that, as a minimum, 'halt -w' should become a no-op and exit
successfully immediately. Ideally, it should generate a valid
shutdown/reboot record the way halt.c from sysvinit does.

If you're short on time, I would suggest that you immediately change your
shutdown.c to just exit cleanly if '-w' is passed on the command line (as
per your existing patch), and wait for someone to send a patch to generate a
valid shutdown record. Since, as you can see above, the code to do that is
minimal, I'm not sure it makes sense to call an external program for it,
adding a dependency.

András

-- 
God heals, but always someone else wants a fee.

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/12/19 8:19 PM, Juergen Gross wrote:
> On 12/03/2019 17:41, Hans van Kranenburg wrote:
>> On 3/12/19 5:04 PM, Juergen Gross wrote:
>>> On 11/03/2019 20:50, Hans van Kranenburg wrote:
 On 3/11/19 7:34 AM, Juergen Gross wrote:
>
> I'm not sure. Patch 3 of this series is basically already there (see
> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
> is patch 4, which should really be easy to do?
>
> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
> I can do the official patch posting in case you confirm it working.

 Ehm ok, well... This is interesting.

 I just built a 4.20.13 (without the patch), and I did it from the Debian
 kernel team repo, because then I just get all latest config options like
 I would get them in Debian.

 I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
 errors similar to the ones I pasted earlier.

 I haven't been running any domU on it yet (just installed it), but this
 is not what I expected.
>>>
>>> Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
>>> rather large series making the dma interface cleaner and using it more
>>> correctly where appropriate. Maybe your use case is covered by this
>>> series already.
>>
>> It seems so. That's good, of course, but it also means that I cannot be
>> of any use here any more to test the additional proposed change. ;]
> 
> I don't think the change is needed any longer.
> 
> Christoph's series was meant to fix stuff like that and it did that very
> well.

Clear.

Then for 4.19 in Debian the workaround is documented in here.

And if someone from the kernel team is reading along... Please mark as
solved when >= 4.20 is uploaded to Debian unstable?

Hans

Bug#924429: movim: reacts indignent to database outages

[Dominik George]

Package: movim
Version: 0.14.1-3
Severity: important

When the postgresql database, for example, is restarted, Movim will halt
as well and exit the daemon. This is no great behaviour, but can be
circumvented by having systemd restart the daemon on failure.

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

Kernel: Linux 4.19.0-3-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)

Versions of packages movim depends on:
ii  composer1.8.4-1
ii  dbconfig-pgsql  2.0.11
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-open-sans 1.11-1
ii  libjs-favico.js 0.3.10~dfsg1-3
ii  php-cboden-ratchet  0.4.1-2
ii  php-cocur-slugify   3.1-1
ii  php-common  2:69
ii  php-curl2:7.3+69
ii  php-defuse-php-encryption   2.2.1-1
ii  php-dflydev-fig-cookies 2.0.0-1
ii  php-doctrine-dbal   2.9.2-1
ii  php-embed   3.3.9-1
ii  php-fabiang-sasl1.0.0-1
ii  php-gd  2:7.3+69
ii  php-htmlpurifier4.10.0-1
iu  php-illuminate-database 5.7.27-1
ii  php-imagick 3.4.3-4
ii  php-markdown1.8.0-1
ii  php-mbstring2:7.3+69
ii  php-monolog 1.24.0-1
ii  php-pgsql   2:7.3+69
ii  php-raintpl 3.1.0+dfsg-1
ii  php-ratchet-pawl0.3.4-1
ii  php-react-child-process 0.5.2-2
ii  php-react-dns   0.4.16-1
ii  php-react-http  0.8.3-3
ii  php-respect-validation  1.1.29-2
ii  php-robmorgan-phinx 0.9.2-1
ii  php-sqlite3 2:7.3+69
ii  php-symfony-console 3.4.22+dfsg-1
ii  php-xml 2:7.3+69
ii  php7.3-cli [php-cli]7.3.2-3
ii  php7.3-curl [php-curl]  7.3.2-3
ii  php7.3-gd [php-gd]  7.3.2-3
ii  php7.3-json [php-json]  7.3.2-3
ii  php7.3-mbstring [php-mbstring]  7.3.2-3
ii  php7.3-pgsql [php-pgsql]7.3.2-3
ii  php7.3-sqlite3 [php-sqlite3]7.3.2-3
ii  php7.3-xml [php-xml]7.3.2-3

Versions of packages movim recommends:
ic  apache2 [httpd]   2.4.25-3+deb9u6
ii  nginx-full [httpd]1.14.2-2
ii  php-fpm   2:7.3+69
ii  php7.3-fpm [php-fpm]  7.3.2-3

Versions of packages movim suggests:
ii  ejabberd  18.12.1-2

-- Configuration Files:
/etc/default/movim changed [not included]

-- debconf information excluded

Bug#924430: libpodofo: CVE-2019-9687

[Salvatore Bonaccorso]

Source: libpodofo
Version: 0.9.6+dfsg-4
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libpodofo.

CVE-2019-9687[0]:
| PoDoFo 0.9.6 has a heap-based buffer overflow in
| PdfString::ConvertUTF16toUTF8 in base/PdfString.cpp.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9687
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9687
[1] https://sourceforge.net/p/podofo/code/1969

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924427: unblock: lxc/1:3.1.0+really3.0.3-4

[Pierre-Elliott Bécue]

Le mardi 12 mars 2019 à 22:25:53+0100, Pierre-Elliott Bécue a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear Release Managers,
> 
> I'd llike to ask you to please unblock package lxc version
> 1:3.1.0+really3.0.3-6 currently lying in unstable, so it replaces lxc
> version 1:3.1.0+really3.0.3-4 currently in testing.
> 
> Indeed, Antonio Terceiro did an upload for 1:3.1.0+really3.0.3-5 in
> unstable on March the 2nd, with changes regarding Debconf translation in
> Dutch (see bug #923328 [0]) and another change to fix an issue I
> introduced in the provided `/etc/lxc/default.conf` file, which made it
> not usable without a fix by the end user. (see bug #923395 [1])
> 
> Although these changes should have reached testing before the freeze, I
> realized that changes I've made for 1:3.1.0+really3.0.3-4 to fix a CVE
> introduced some anomalies due to upstream patch not being enough (see
> bug #923932 [2]), and that I forgot to update debian/NEWS with proper
> instructions regarding the breaking changes from LXC2 to 3. (explain the
> reason for the unblock here)
> 
> Hence I did a 1:3.1.0+really3.0.3-6 upload in unstable to include these
> changes, and it reset the counter for -5.
> 
> Attached is a debdiff between testing and unstable.
> 
> Thanks a lot for considering such an unblock.
> 
> With best regards,

Sorry for forgetting:

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923328
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923395
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923932

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#924428: unblock: grfcodec/6.0.6-3

[Matthijs Kooijman]

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

Please unblock package grfcodec

Version 6.0.6-3 adds a tiny patch to fix a serious bug (#922625).

unblock grfcodec/6.0.6-3

Thanks!

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (50, 'unstable'), 
(1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.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 /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru grfcodec-6.0.6/debian/changelog grfcodec-6.0.6/debian/changelog
--- grfcodec-6.0.6/debian/changelog 2018-05-10 21:42:34.0 +0200
+++ grfcodec-6.0.6/debian/changelog 2019-03-12 22:19:01.0 +0100
@@ -1,3 +1,11 @@
+grfcodec (6.0.6-3) unstable; urgency=medium
+
+  [ Jordi Mallach ]
+  * [e61a00b] Force build to abort upon endian_check failure. Thanks to
+Helmut Grohne for suggesting this fix (Closes: #922625)
+
+ -- Matthijs Kooijman   Tue, 12 Mar 2019 22:19:01 +0100
+
 grfcodec (6.0.6-2) unstable; urgency=medium
 
   * [4dce67c] Bump debhelper version to v11
diff -Nru grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch 
grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch
--- grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch 
1970-01-01 01:00:00.0 +0100
+++ grfcodec-6.0.6/debian/patches/endian_check_cpp_abort_on_ftbfs.patch 
2019-03-12 22:19:01.0 +0100
@@ -0,0 +1,18 @@
+Description: Prevent infinite loop during build on endian_check failure
+Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922625
+Forwarded: https://github.com/OpenTTD/grfcodec/pull/1
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922625
+
+Index: grfcodec/Makefile
+===
+--- grfcodec.orig/Makefile
 grfcodec/Makefile
+@@ -213,7 +213,7 @@ objs/$(ENDIAN_CHECK): src/endian_check.c
+ 
+ src/endian.h: objs/$(ENDIAN_CHECK)
+   $(_E) [ENDIAN] Determining endianness
+-  $(_C)objs/$(ENDIAN_CHECK) $(ENDIAN_PARAMS) > src/endian.h || rm 
src/endian.h
++  $(_C)objs/$(ENDIAN_CHECK) $(ENDIAN_PARAMS) > src/endian.h || { rm 
src/endian.h; exit 1; }
+ 
+ FORCE:
+ %_r: FORCE
diff -Nru grfcodec-6.0.6/debian/patches/series 
grfcodec-6.0.6/debian/patches/series
--- grfcodec-6.0.6/debian/patches/series2018-05-10 21:42:34.0 
+0200
+++ grfcodec-6.0.6/debian/patches/series2019-03-12 22:19:01.0 
+0100
@@ -1 +1,2 @@
 # Series of quilt patches
+endian_check_cpp_abort_on_ftbfs.patch

Bug#924346: xmltooling: CVE-2019-9628: XML parser class fails to trap exceptions on malformed XML declaration

[Moritz Mühlenhoff]

On Tue, Mar 12, 2019 at 02:53:14PM +0100, wf...@niif.hu wrote:
> Moritz Muehlenhoff  writes:
> 
> > On Tue, Mar 12, 2019 at 10:19:00AM +0100, wf...@niif.hu wrote:
> >
> >> The resulting packages works fine in my setup.  However, I failed to
> >> reproduce the original issue under stretch.  After consulting upstream,
> >> it turns out that the old Xerces library actually helps somewhat in this
> >> case, please see Scott Cantor's reply below.  So the known exploit
> >> (using an invalid XML declaration) does not work on stable, but if
> >> somebody finds a way to trigger a DOMException in Xerces 3.1, any
> >> xmltooling users will crash all the same.  See also his comment on
> >> https://issues.apache.org/jira/browse/XERCESC-2016.
> >
> > I think we can still fix this via stretch-security
> 
> OK, uploaded.

DSA has been released, thanks.

Cheers,
Moritz

Bug#924427: unblock: lxc/1:3.1.0+really3.0.3-4

[Pierre-Elliott Bécue]

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

Dear Release Managers,

I'd llike to ask you to please unblock package lxc version
1:3.1.0+really3.0.3-6 currently lying in unstable, so it replaces lxc
version 1:3.1.0+really3.0.3-4 currently in testing.

Indeed, Antonio Terceiro did an upload for 1:3.1.0+really3.0.3-5 in
unstable on March the 2nd, with changes regarding Debconf translation in
Dutch (see bug #923328 [0]) and another change to fix an issue I
introduced in the provided `/etc/lxc/default.conf` file, which made it
not usable without a fix by the end user. (see bug #923395 [1])

Although these changes should have reached testing before the freeze, I
realized that changes I've made for 1:3.1.0+really3.0.3-4 to fix a CVE
introduced some anomalies due to upstream patch not being enough (see
bug #923932 [2]), and that I forgot to update debian/NEWS with proper
instructions regarding the breaking changes from LXC2 to 3. (explain the
reason for the unblock here)

Hence I did a 1:3.1.0+really3.0.3-6 upload in unstable to include these
changes, and it reset the counter for -5.

Attached is a debdiff between testing and unstable.

Thanks a lot for considering such an unblock.

With best regards,

unblock lxc/1:3.1.0+really3.0.3-4

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lxc-3.1.0+really3.0.3/debian/changelog 
lxc-3.1.0+really3.0.3/debian/changelog
--- lxc-3.1.0+really3.0.3/debian/changelog  2019-02-16 16:21:41.0 
+0100
+++ lxc-3.1.0+really3.0.3/debian/changelog  2019-03-09 15:49:21.0 
+0100
@@ -1,3 +1,22 @@
+lxc (1:3.1.0+really3.0.3-6) unstable; urgency=medium
+
+  * d/patches/0005: Tweaks the 0004 patch for CVE-2019-5736 (Closes: #923932)
+  * d/NEWS: summary of the important changes since LXC2.
+
+ -- Pierre-Elliott Bécue   Sat, 09 Mar 2019 15:49:21 +0100
+
+lxc (1:3.1.0+really3.0.3-5) unstable; urgency=medium
+
+  [ Christian Kastner ]
+  * /etc/default/lxc.conf Change back to lxc.net.0.type
+(Closes: #923395)
+
+  [ Frans Spiesschaert ]
+  * debian/po/nl.po: Add Dutch translation of debconf messages
+(Closes: #923328)
+
+ -- Antonio Terceiro   Sat, 02 Mar 2019 12:33:08 -0300
+
 lxc (1:3.1.0+really3.0.3-4) unstable; urgency=medium
 
   [ Lev Lamberov ]
diff -Nru lxc-3.1.0+really3.0.3/debian/contrib/default.conf 
lxc-3.1.0+really3.0.3/debian/contrib/default.conf
--- lxc-3.1.0+really3.0.3/debian/contrib/default.conf   2019-02-11 
22:59:58.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/contrib/default.conf   2019-03-09 
12:54:41.0 +0100
@@ -1,3 +1,3 @@
-lxc.net.type = empty
+lxc.net.0.type = empty
 lxc.apparmor.profile = generated
 lxc.apparmor.allow_nesting = 1
diff -Nru lxc-3.1.0+really3.0.3/debian/liblxc1.symbols 
lxc-3.1.0+really3.0.3/debian/liblxc1.symbols
--- lxc-3.1.0+really3.0.3/debian/liblxc1.symbols2019-02-16 
16:21:29.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/liblxc1.symbols2019-03-09 
12:54:41.0 +0100
@@ -381,6 +381,7 @@
  lxc_remove_nic_by_idx@Base 1:3.0.2
  lxc_requests_empty_network@Base 1:3.0.2
  lxc_restore_phys_nics_to_netns@Base 1:3.0.2
+ lxc_rexec@Base 1:3.0.3
  lxc_ringbuf_create@Base 1:3.0.2
  lxc_ringbuf_move_read_addr@Base 1:3.0.2
  lxc_ringbuf_read@Base 1:3.0.2
diff -Nru lxc-3.1.0+really3.0.3/debian/NEWS lxc-3.1.0+really3.0.3/debian/NEWS
--- lxc-3.1.0+really3.0.3/debian/NEWS   2018-12-22 22:49:44.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/NEWS   2019-03-09 15:49:19.0 +0100
@@ -1,3 +1,35 @@
+lxc (1:3.1.0+really3.0.3-6) unstable; urgency=medium
+
+  LXC 3 got some significant changes from LXC 2.
+
+   1. The configuration files use different variables. A userland script
+  lxc-update-config is available to update automatically your
+  configuration files. An automatic update is possible and offered by
+  debconf during the upgrade of lxc version < 3.0.2 to lxc version >=
+  3.0.2. Mind that this update will only work for priviledged containers
+  with configurations present in /var/lib/lxc/*/config and any other
+  container will not be updated.
+   2. AppArmor support in Debian has increased, thus preventing some systemd
+  isolation features to work in LXC 3.0.X. Debian has backported some
+  patches from LXC 3.1 that, along with some configurations in a
+  container, will allow systemd isolation features to work.
+
+  The required configuration parameters are the ones which follow:
+lxc.apparmor.profile = generated
+

Bug#851771: CVE-2016-6175 and 851771

[Ivo De Decker]

control: tags -1 buster-ignore

Hi,

On Sun, Jan 22, 2017 at 10:47:32PM +0100, Ola Lundqvist wrote:
> I started checking the CVEs for php-gettext and I'm not sure I follow
> the information for CVE-2016-6175.
> Maybe you have more data than I do.
> 
> The vulnerability is that a malicous user that have permission to
> craft .mo files in the target filesystem could execute any php code on
> that system.
> I find that a quite unlikely attack vector. Based on this I also think
> the bug should have a different priority than grave.
> 
> Or have I missed anything crucial?

After a brief discussion on irc, and input from the security team, I'm marking
this buster-ignore, on the understanding that php-gettext won't be in bullseye.

"< jmm_> I'm fine with buster-ignoring it, but it should go away after buster"

Thanks,

Ivo

Bug#884553: Foreign architecture package support for linux kernel flavours patch

[adrian15]

I attach a patch that adds foreign architecture support.


Improvements since last patch:

* Makes sure a consistent use of the new variable:
LB_LINUX_FLAVOURS_WITH_ARCH
* Makes a better job of explaining how to use on the manpage
.

Testing:

This patch has been tested by using:
--linux-flavours "686 amd64:amd64"
in a buster i386 chroot and it works flawlessly.


If you want to avoid the grub> prompt with Secure Boot you should apply
patch from #924053 bug too.


Is it ok for merging in Debian GIT or is there anything that I can improve?

Thank you very much!


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From ad11d1c44909466baa259c2716d126dc9bc54080 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Fri, 15 Dec 2017 17:22:57 +
Subject: [PATCH] Fixed foreign architecture package support to linux kernel
 flavours

This problem originated in Stretch where amd64 kernel is not part of i386 repo.
So it needs to be fetched from amd64 repo.

So first of all you need to enable amd64 foreign architecture in your i386 system
thanks to:

dpkg --add-architecture amd64
apt-get update
.

Once you have done this thanks to this commit
now you can set linux flavours ( --linux-flavours ) as:

"686 amd64:amd64"

in a i386 system and it will install the amd64 kernel alongside the i386 system's 686 kernel.
---
 functions/defaults.sh| 24 
 manpages/en/lb_config.1  |  2 +-
 scripts/build/chroot_linux-image |  2 +-
 scripts/build/config |  6 +++---
 4 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index c48955104..c1ca10258 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -407,27 +407,27 @@ Set_defaults ()
 	# Setting linux flavour string
 	case "${LB_ARCHITECTURES}" in
 		arm64)
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-arm64}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-arm64}"
 			;;
 
 		armel)
 			# armel will have special images: one rootfs image and many additional kernel images.
 			# therefore we default to all available armel flavours
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-marvell}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-marvell}"
 			;;
 
 		armhf)
 			# armhf will have special images: one rootfs image and many additional kernel images.
 			# therefore we default to all available armhf flavours
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-armmp armmp-lpae}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-armmp armmp-lpae}"
 			;;
 
 		amd64)
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-amd64}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-amd64}"
 			;;
 
 		i386)
-LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-686-pae}"
+LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-686-pae}"
 			;;
 
 		ia64)
@@ -438,7 +438,7 @@ Set_defaults ()
 	;;
 
 *)
-	LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-itanium}"
+	LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-itanium}"
 	;;
 			esac
 			;;
@@ -451,7 +451,7 @@ Set_defaults ()
 	;;
 
 *)
-	LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-powerpc64 powerpc}"
+	LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-powerpc64 powerpc}"
 	;;
 			esac
 			;;
@@ -464,7 +464,7 @@ Set_defaults ()
 	;;
 
 *)
-	LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-s390x}"
+	LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-s390x}"
 	;;
 			esac
 			;;
@@ -475,6 +475,14 @@ Set_defaults ()
 			;;
 	esac
 
+	LB_LINUX_FLAVOURS=""
+	for FLAVOUR in ${LB_LINUX_FLAVOURS_WITH_ARCH}
+	do
+		ARCH_FILTERED_FLAVOUR="$(echo ${FLAVOUR} | awk -F':' '{print $1}')"
+		LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS} ${ARCH_FILTERED_FLAVOUR}"
+	done
+
+
 	# Set linux packages
 	LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES:-linux-image}"
 
diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1
index ac562d209..e46331ec7 100644
--- a/manpages/en/lb_config.1
+++ b/manpages/en/lb_config.1
@@ -360,7 +360,7 @@ sets the eraseblock size for a JFFS2 (Second Journaling Flash File System) files
 .IP "\fB\-\-keyring\-packages\fR \fIPACKAGE\fI|""\fIPACKAGES\fR""" 4
 sets the keyring package or additional keyring packages. By default this is set to debian\-archive\-keyring.
 .IP "\-k|\fB\-\-linux\-flavours\fR \fIFLAVOUR\fR|""\fIFLAVOURS\fR""" 4
-sets the kernel flavours to be installed. Note that in case you specify more than that the first will be configured the default kernel that gets booted.
+sets the kernel flavours to be installed. Note that in case you specify more than that the first will be configured the default kernel that gets booted. Optionally you can use an architecture qualifier, e.g. amd64:amd64. Given an i386 system you can enable amd64 foreign architecture thanks to the 

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Christoph Müllner]

On 3/12/19 9:57 PM, Ben Hutchings wrote:
> On Tue, 2019-03-12 at 19:04 +0100, Christoph Müllner wrote:
>> I've been able to reproduce and analyse this issue.
>>
>> The security error seems to be valid.
> [...]
> 
> I don't see a security issue here.  The kernel does not and should not
> stop root breaking the system with direct access to /dev/mem, *unless*
> Secure Boot / lockdown is active - and in that case access to /dev/mem
> is blocked completely.

You are right. There is no security error.
SError stands for system error.

Bug#924426: unblock: nvidia-settings-legacy-390xx/390.116-1

[Andreas Beckmann]

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

Please unblock package nvidia-settings-legacy-390xx

This is a new upstream release to match the new driver (which migrated
on its own). I was a bit late to upload this package in time, too.
It also includes an important fix for generating xorg.conf for the
Xserver that we have in stretch (even if upstream's changelog only
mentioned it for nvidia-xconfig).

Andreas

unblock nvidia-settings-legacy-390xx/390.116-1


n-s-390xx-390.116-1.diff.gz
Description: application/gzip

Bug#924425: nfsidmap[]: nss_getpwname: nfs4_name_to_uid: final return value is -22

[Michael Barkdoll]

Package: libnfsidmap2
Version: 0.25-5.1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
AD realmd join machine unable to see `ls -lan` with proper user mapping.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Only thing that fixed it was upgrading libnfsidmap to version 0.26
   * What was the outcome of this action?
This fixed the isssue.
   * What outcome did you expect instead?
I expected to see proper username and group for file mapping on `ls -lan` 
instead I saw nobody was the owner.

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


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

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

Versions of packages libnfsidmap2 depends on:
ii  libc6  2.24-11+deb9u4
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u2

libnfsidmap2 recommends no packages.

libnfsidmap2 suggests no packages.

-- no debconf information

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Nicholas D Steeves]

On Tue, Mar 12, 2019 at 05:55:37AM -0400, Chris Lamb wrote:
> Nicholas,
> 
> > If you have a minute would you please sponsor this backport
> 
> Please drop the "new-package-should-not-package-python2-module"
> override and move the justification to the changelog.
> 
> It should be clear from this tag's description that this is override
> is inappropriate and, IIRC, explicitly not requested.
> 

Oops, I missed that :-$  Just to confirm: you'd like me to make this
change to the stretch-backport (after which it will no longer be a
no-change backport), and also the branch for sid, which would not be
uploaded until buster is released?

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Ben Hutchings]

On Tue, 2019-03-12 at 19:04 +0100, Christoph Müllner wrote:
> I've been able to reproduce and analyse this issue.
> 
> The security error seems to be valid.
[...]

I don't see a security issue here.  The kernel does not and should not
stop root breaking the system with direct access to /dev/mem, *unless*
Secure Boot / lockdown is active - and in that case access to /dev/mem
is blocked completely.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.




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

Bug#924424: munin-plugins-core: postgres_connections_ "Query failed!" after update to 2.0.47-1

[Thorsten Ortlepp]

Package: munin-plugins-core
Version: 2.0.47-1
Severity: normal

Dear Maintainer,

after I updated munin-plugins-core to 2.0.47-1, the plugin 
postgres_connections_ does not show any values in the graphics for specific 
databases. It does show values for postgres_connections_ALL.

$ munin-run postgres_connections_ALL
active.value 0
idle.value 0
idletransaction.value 0
unknown.value 0
waiting.value 0

0 is fine, there was no active connection at time of running. In the graphic I 
see a connection when there is one.

$ munin-run postgres_connections_example
Query failed!

The graphic shows nothing, the current value is "-nan".

Before the update was done, both postgres_connections_example and 
postgres_connections_ALL showed correct values.


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

Kernel: Linux 4.18.7-xen (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.47-1
ii  perl  5.28.1-4

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-5

Versions of packages munin-plugins-core suggests:
pn  acpi | lm-sensors 
pn  conntrack 
pn  default-mysql-client  
pn  ethtool   
pn  hdparm
pn  libcache-cache-perl   
pn  libdbd-mysql-perl 
ii  libdbd-pg-perl3.7.4-2
ii  libhttp-date-perl 6.02-1
pn  liblwp-useragent-determined-perl  
pn  libnet-dns-perl   
pn  libnet-ip-perl
pn  libnet-irc-perl   
pn  libnet-ldap-perl  
pn  libnet-netmask-perl   
pn  libnet-telnet-perl
ii  libxml-parser-perl2.44-4
ii  libxml-simple-perl2.25-1
pn  logtail   
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python3   3.7.2-1
pn  ruby  
pn  smartmontools 

-- no debconf information

Bug#924363: wget: segfault when using --convert-links [stretch only]

[Christoph Biedl]

Christoph Biedl wrote...

> This was fixed in 10-buster/sid (1.20), and the change is fairly
> simple, see attached patch. Please apply when convenient.

Upstream fix is
http://git.savannah.gnu.org/cgit/wget.git/commit/src/html-url.c?id=a2c4849900d1d5c7e5c273536ab0b8bbba9c1e54

| Fix crash on 'srcset' inline URIs
|
| * src/html-url.c (tag_handle_img): Check append_url() for NULL
|   return value before dereference.
|
| Crashed reproducable with parsing srcset="data:..." inline data.
| Reported-by: Coverity


signature.asc
Description: PGP signature

Bug#924051: nfs-common: Krb5 NFSv4 Realmd AD nfsidmap files owned by nobody group 4294967294

[Michael Barkdoll]

I was able to find a solution to this issue that will require a
patch/update to the libnfsidmap version 0.26.

Please see reference to another user that experience the issue.

https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/thread/SIA6J7IZRWX2FVGHKMS5F3HB7DE3MCFC/

I confirmed after custom compiling and using the newer lib's .so file that
the naming convention was normal.  One directory timed out when I did a
chown but after fixing the file permissions to a user inside AD it seems to
be working alright.

Can you please patch libnfsidmap to use version 0.26 to fix this bug?
Thanks!

Michael Barkdoll

Bug#924423: In debian testing I can't get PXE boot logs from libvirt guest on a serial console

[Katerina Koukiou]

Package: libvirt
libvirt-daemon 5.0.0-1
qemu 1:3.1+dfsg-4
virt-manager 1:2.0.0-3

# uname -a
Linux unassigned-hostname 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1
(2019-01-17) x86_64 GNU/Linux

Steps to reproduce:

1. Create a libvirt Virtual Network with tftp server configured. Example XML:

# virsh net-dumpxml pxe-nat

  pxe-nat
  

  

  
  
  
  


  
  

  

Bug#922618: Any plan to package bird 2.0 as a separate package?

[Stephen Gelman]

On Tue, Mar 12, 2019 at 2:55 PM Ondřej Surý  wrote:
> It’s sitting in NEW queue: 
> https://ftp-master.debian.org/new/bird2_2.0.4-1.html
>
> The priority for ftp-masters is now getting buster out, so the NEW queue 
> might get a little bit longer before they clear it up.
>
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org

Ah I totally missed that.  Thanks for the quick reply!

Stephen

Bug#924422: update to 1.9.1

[nusenu]

Package: unbound
Version: 1.9.0-2

Update to upstream release 1.9.1 to address some issues in OOOR, 
QNAME minimization and more.

upstream announcement and changelog:

https://nlnetlabs.nl/pipermail/unbound-users/2019-March/011415.html

Bug#922275: libomp-7-dev

[Ron Lovell]

Or alternatively have /usr/lib//libomp.so point to libomp5.so so it
won't have to changed with LLVM version. The libomp5.so symlink is already
maintained by libomp-dev, so it will be updated with the libomp-dev release
updates.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Daniel Kahn Gillmor]

Control: tags 921904 + help

On Sat 2019-02-09 23:50:03 +, Santiago Vila wrote:
> Package: src:win-iconv
> Version: 0.0.8-2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
>
> 
> [...]
>  debian/rules build-indep
> dh build-indep
>dh_update_autotools_config -i
>dh_auto_configure -i
>debian/rules override_dh_auto_build-indep
> make[1]: Entering directory '/<>'
> for arch in x86_64-w64-mingw32 i686-w64-mingw32; do \
>  mkdir -p build-$arch && \
>  cd build-$arch && \
>   ln -s ../*.h ../*.c ../*.def ../Makefile ./ && \
>   /usr/bin/make CC=$arch-gcc AR=$arch-ar RANLIB=$arch-ranlib 
> DLLTOOL=$arch-dlltool prefix=/usr/$arch \
>   || exit 1 ; \
>   cd .. ; \
> done
> make[2]: Entering directory '/<>/build-x86_64-w64-mingw32'
> x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL
> x86_64-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s 
> -Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o 
> x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c
> x86_64-w64-mingw32-ar rcs libiconv.a win_iconv.o
> x86_64-w64-mingw32-ranlib libiconv.a
> x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE
> make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32'
> make[2]: Entering directory '/<>/build-i686-w64-mingw32'
> i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL
> i686-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s 
> -Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o 
> i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c
> i686-w64-mingw32-ar rcs libiconv.a win_iconv.o
> i686-w64-mingw32-ranlib libiconv.a
> i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE
> make[2]: Leaving directory '/<>/build-i686-w64-mingw32'
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> cd build-x86_64-w64-mingw32 && 
> WINEPREFIX=/<>/build-x86_64-w64-mingw32/.wine /usr/bin/make 
> CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar 
> RANLIB=x86_64-w64-mingw32-ranlib DLLTOOL=x86_64-w64-mingw32-dlltool test
> make[2]: Entering directory '/<>/build-x86_64-w64-mingw32'
> x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
> -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv_test.exe win_iconv_test.c
> wine ./win_iconv_test.exe
> it looks like wine32 is missing, you should install it.
> multiarch needs to be enabled first.  as root, please
> execute "dpkg --add-architecture i386 && apt-get update &&
> apt-get install wine32"
> wine: created the configuration directory 
> '/<>/build-x86_64-w64-mingw32/.wine'
> wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory
> make[2]: *** [Makefile:51: test] Error 1
> make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32'
> make[1]: *** [debian/rules:40: override_dh_auto_test] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:19: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> E: Build killed with signal TERM after 60 minutes of inactivity
> 
>
> (Additionally, the autobuilder hangs and sbuild has to kill remaining 
> processes)
>
> The build was made in my autobuilder with "dpkg-buildpackage -A"
> and it also fails here:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/win-iconv.html
>
> where you can get a full build log if you need it.
>
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
>
> Thanks.



Interesting. I can see the same behavior above (without the hanging) on
my own cowbuilder instance.

But building it directly on a dedicated amd64 VM, i see a completed run,
(output at the end).

I don't think the problem is "missing" wine32, because my run succeeds
despite not having wine32 installed.  I'm cc'ing the debian-wine mailing
list in hopes that they can point to what's happening here.

Bug#924329: xastir: FTBFS (magick/image-private.h: No such file or directory)

[Andrey Rahmatullin]

On Mon, Mar 11, 2019 at 05:09:58PM +, Santiago Vila wrote:
> In file included from /usr/include/GraphicsMagick/magick/analyze.h:18,
>  from /usr/include/GraphicsMagick/magick/api.h:55,
>  from map_geo.c:137:
> /usr/include/GraphicsMagick/magick/image.h:1108:10: fatal error: 
> magick/image-private.h: No such file or directory
>  #include "magick/image-private.h"
>   ^~~~


src/map_geo.c:

"""
#ifdef HAVE_GRAPHICSMAGICK
/*#include */
/* Define MAGICK_IMPLEMENTATION to access private interfaces
 * such as DestroyImagePixels(). This may not be a good thing,
 * but DestroyImagePixels() has been in this code for a long
 * time. Defining MAGIC_IMPLEMENTATION eliminates the warning that is
 * now (9/28/2010) being seen on some distros (Ubuntu 10.04 and
 * OpenSuSE-11.3)
 */
#define MAGICK_IMPLEMENTATION
#include 
"""

Haha NOPE.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#924420: Subject: RFS: fonts-myanmar/0.1-1 [ITP] -- Prease Sponsor for myanmar-font pack

[Ko Ko Ye`]

Package: fonts-myanmar
Version: 0.1-1
Severity: wishlist

Dear Maintainer,

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

* Its Myanmar (Burma,Shan,Mon,Karen,Pao etc) Font Pack
* Its Effect to all Debian Linux User
* We can use easiy with Font Pack, More Linux User
* Now we have fonts-sil-padauk font repo only
* Next plan is keyboard and system fonts switcher
 * Package name: fonts-myanmar
   Version : 0.1-1
   Upstream Author : kokoye2007 
 * URL :
https://salsa.debian.org/kokoye2007-guest/fonts-myanmar/
 * License : GPL3
   Section : fonts

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

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


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

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

  More information about fonts-myanmar can be obtained from
https://salsa.debian.org/kokoye2007-guest/fonts-myanmar/
https://code.launchpad.net/~kokoye2007/ttf-burmese-fonts/ttf-burmese-fonts

  Changes since the last upload:

  we fix infomation and DFSG, Social Contract

  #896887  #899260 #924039 #923710

  Regards,
   kokoye2007

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

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

-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#924383: ruby-coveralls: FTBFS (dh_installman: Cannot find "debian/coveralls.1")

[Andrey Rahmatullin]

On Tue, Mar 12, 2019 at 09:43:22AM +, Santiago Vila wrote:
> TZ=UTC ronn --roff debian/coveralls.mkd
>  roff: debian/coveralls.mkd.1 
[...]
> dh_installman: Cannot find (any matches for) "debian/coveralls.1" (tried in 
> ., debian/tmp)

So a change in ronn, I guess. The package in sid wasn't built on buildds
so nothing to compare with.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#924421: ld.gold searches for non-existent -lug, eventually crashes

[Eduard Bloch]

Package: binutils-x86-64-linux-gnu
Version: 2.32-5
Severity: normal

Hi,

I tried to optimize the build of apt-cacher-ng a little bit, and I found
that I have not used -Wl,threads with gold. So I "fixed" this and then
it started crashing. Apparently linking shared libraries works, but
executables segfaults. Tried with current sid (version 2.31, I think)
and experimental, same problem.

While trying to reproduce, I run into the following (and not sure why
omiting -Wl,threads makes this go away, but something with -lug looks
fishy).

gcc is latest from Sid:
ii  gcc-8  8.3.0-2  amd64GNU C compiler

dev/apt-cacher-ng/dev/relbuild $ gdb /usr/bin/ld.gold
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ld.gold...(no debugging symbols found)...done.
(gdb) run -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plug
Starting program: /usr/bin/ld.gold -plugin 
/usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/usr/bin/ld.gold: error: cannot find -lug

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x5569ab8d in ?? ()
#2  0x5569fe1d in ?? ()
#3  0x5566edb9 in ?? ()
#4  0x556b0448 in ?? ()
#5  0x556b066a in ?? ()
#6  0x555a148b in ?? ()
#7  0x77a2009b in __libc_start_main (main=0x555a0ef0, argc=4, 
argv=0x7fffdf08, init=, fini=, 
rtld_fini=, stack_end=0x7fffdef8) at ../csu/libc-start.c:308
#8  0x555a235a in ?? ()

Best regards,
Eduard.


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

Kernel: Linux 5.0.0+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages binutils-x86-64-linux-gnu depends on:
ii  binutils-common  2.32-5
ii  libbinutils  2.32-5
ii  libc62.28-7
ii  zlib1g   1:1.2.11.dfsg-1

binutils-x86-64-linux-gnu recommends no packages.

Versions of packages binutils-x86-64-linux-gnu suggests:
pn  binutils-doc  

-- no debconf information

Bug#922618: Any plan to package bird 2.0 as a separate package?

[Ondřej Surý]

It’s sitting in NEW queue: https://ftp-master.debian.org/new/bird2_2.0.4-1.html

The priority for ftp-masters is now getting buster out, so the NEW queue might 
get a little bit longer before they clear it up.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 12 Mar 2019, at 20:50, Stephen Gelman  wrote:
> 
> Ondřej,
> 
> What is your plan for uploading the bird2 package?  I am currently
> looking at upgrading some hosts running old releases of bird and am
> debating whether I should make the effort to go all the way to bird2
> or not.
> 
> Thanks!
> 
> Stephen

Bug#922618: Any plan to package bird 2.0 as a separate package?

[Stephen Gelman]

Ondřej,

What is your plan for uploading the bird2 package?  I am currently
looking at upgrading some hosts running old releases of bird and am
debating whether I should make the effort to go all the way to bird2
or not.

Thanks!

Stephen

Bug#800707: systemd: Sytem hangs on shutdown when nfs-shares are mounted via autofs

[Jürgen Bausa]

Am Dienstag, 12. März 2019, 03:49:44 CET schrieb Michael Biebl:
> Control: tags -1 + moreinfo
> 
> On Fri, 02 Oct 2015 21:01:07 +0200 =?utf-8?q?J=C3=BCrgen_Bausa?=
> 
>  wrote:
> > Package: systemd
> > Version: 215-17+deb8u2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I am running jessie on a laptop with wlan (Networkmanager) and want to use
> > autofs to mount nfs shares, as the shares are only available, when I am at
> > home.
> > 
> > The problem is, that when I am actually accessing the share (and it is
> > therefore mounted by autofs), the system hangs on shutdown. At first I get
> > the message
> > 
> >   [*]A stop job is running for /mnt/nfs/share (xxs / 1mn 30s)
> > 
> > and the systems counts down 90 s. After that I see som more messages which
> > end up with
> > 
> >   Reached target shutdown
> > 
> > After that, the system hangs forever (at least for a long time, I think I
> > waited some minutes).
> > 
> > When I am not accessing an nfs share during the session, and autofs does
> > not need to actually mount it, shutdown works fine.
> > 
> > I think the reason for this problem is, that systemd stops Networkmanager
> > before autofs had a chance to unmount the shares. After that unmounting
> > doesnt work and later stopping autofs also fails. Thats my theory.
> 
> Is this still an issue with stretch or buster?
> Can you share more details about your network configuration, (wifi,
> ethernet,...)

I am running stretch now and it is not an issue anymore. As I remember I found 
some workaround for jessie. Most lilkely decreasing some timeouts, but I am 
not sure.

At the time of reporting the bug I used jessie with network-manager, and a wifi 
connection.

Juergen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 08:31:51PM +0100, Carl Eugen Hoyos wrote:
> 2019-03-12 18:48 GMT+01:00, Josh Triplett :
> > On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> 
> >> I think this should address the issue. Any objections to this approach?
> >
> > This would work perfectly for me, and I would then avoid installing
> > ffplay on my servers.
> 
> I was expecting that the ffmpeg package would still pull a large
> number of dependencies including X11 with this change but if
> there is an improvement for you, all the better!

As long as libavdevice no longer depends on libsdl2 either, that'll
suffice. libavdevice still depends on a handful of X libraries, but I
don't mind having a few of those installed on my server, and I already
had some of them for things like `ssh -X`. libsdl2 substantially
increased the dependencies.

Thank you!

Bug#924220: sddm-theme-debian-maui: background-nologo.svg from theme.conf does not exist

[Lisandro Damián Nicanor Pérez Meyer]

El mar., 12 mar. 2019 15:21, Matthew Crews 
escribió:

> On Sun, 10 Mar 2019 12:22:07 +0100 Robert  wrote:
> > Package: sddm-theme-debian-maui
> > Version: 0.18.0-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > "/usr/share/sddm/themes/debian-maui/theme.conf" contains
> >
> "background=/usr/share/desktop-base/active-theme/login/background-nologo.svg",
> > but the "background-nologo.svg" does not exist on a fresh installed
> debian
> > testing.
> >
> > There is only a "background.svg" and a "background-withlogo.svg" under
> > "/usr/share/desktop-base/active-theme/login/"
>
> This is  a problem when upgrading from Stretch to Buster as well.
> background-nologo.svg is deleted from the system as a result of the
> change in default theme to FuturePrototype from softWaves.
>
> This should be classified as a critical bug IMO, as it directly impacts
> KDE Plasma users upgrading from Stretch to Buster.
>


If I'm not mistaken this is a desktop-base bug

>

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-12 18:48 GMT+01:00, Josh Triplett :
> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:

>> I think this should address the issue. Any objections to this approach?
>
> This would work perfectly for me, and I would then avoid installing
> ffplay on my servers.

I was expecting that the ffmpeg package would still pull a large
number of dependencies including X11 with this change but if
there is an improvement for you, all the better!

Bug#924419: unblock: nvidia-graphics-drivers/410.104-1

[Andreas Beckmann]

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

Please unblock package nvidia-graphics-drivers

This is a new upstream release fixing CVE‑2018‑6260.
I had postponed the upload to have the package stack sitting in sid
(which was blocked by hashcat-meta) migrate to testing first, that
happened last night.

unblock nvidia-graphics-drivers/410.104-1

Andreas


ngd-410.104-1.diff.gz
Description: application/gzip

Bug#924417: lintian: Allow *.pth files in python dist-packages

[Chris Lamb]

tags 924417 + pending
thanks

Fixed in Git, pending upload:

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

  data/files/allowed-python-files | 1 +
  1 file changed, 1 insertion(+)


Regards,

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

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Juergen Gross]

On 12/03/2019 17:41, Hans van Kranenburg wrote:
> On 3/12/19 5:04 PM, Juergen Gross wrote:
>> On 11/03/2019 20:50, Hans van Kranenburg wrote:
>>> On 3/11/19 7:34 AM, Juergen Gross wrote:

 I'm not sure. Patch 3 of this series is basically already there (see
 commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
 is patch 4, which should really be easy to do?

 Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
 I can do the official patch posting in case you confirm it working.
>>>
>>> Ehm ok, well... This is interesting.
>>>
>>> I just built a 4.20.13 (without the patch), and I did it from the Debian
>>> kernel team repo, because then I just get all latest config options like
>>> I would get them in Debian.
>>>
>>> I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
>>> errors similar to the ones I pasted earlier.
>>>
>>> I haven't been running any domU on it yet (just installed it), but this
>>> is not what I expected.
>>
>> Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
>> rather large series making the dma interface cleaner and using it more
>> correctly where appropriate. Maybe your use case is covered by this
>> series already.
> 
> It seems so. That's good, of course, but it also means that I cannot be
> of any use here any more to test the additional proposed change. ;]

I don't think the change is needed any longer.

Christoph's series was meant to fix stuff like that and it did that very
well.


Juergen

Bug#924418: libvirt-daemon-system: apparmor prevents libvirtd from spawning VMs

[Robbie Harwood]

Package: libvirt-daemon-system
Version: 5.0.0-1
Severity: important

Dear Maintainer,

When I attempt to spawn a QEMU/kvm VM (sudo virsh start vmname), it fails with:

error: Failed to start domain 7-1
error: internal error: Process exited prior to exec: libvirt:  error : 
unable to set AppArmor profile 'libvirt-16efecbc-66ca-4559-8558-7084588065d4' 
for '/usr/bin/kvm': No existe el fichero o el directorio

(That approximately translates to "The file or directory doesn't exist".  I
set LC_ALL=en_US.utf8, but it didn't seem to be respected.)

Here's the contents of /etc/apparmor.d/libvirt:

root@seton:~# ls -1 /etc/apparmor.d/libvirt
libvirt-0bb30752-0938-406e-a1db-897cc3dafff5
libvirt-0bb30752-0938-406e-a1db-897cc3dafff5.files
libvirt-168159f5-b57b-49f1-9326-306feeedcc44
libvirt-168159f5-b57b-49f1-9326-306feeedcc44.files
libvirt-16efecbc-66ca-4559-8558-7084588065d4
libvirt-16efecbc-66ca-4559-8558-7084588065d4.files
libvirt-2c26722b-4577-426a-af38-b81e7575c0ca
libvirt-2c26722b-4577-426a-af38-b81e7575c0ca.files
libvirt-4e7b35eb-3999-4879-afb6-e408445540ba
libvirt-4e7b35eb-3999-4879-afb6-e408445540ba.files
libvirt-53d197b4-935b-414e-8978-cd1c7fbbdf46
libvirt-53d197b4-935b-414e-8978-cd1c7fbbdf46.files
libvirt-59dc44de-10a8-41e8-bdc8-602bc03627a5
libvirt-59dc44de-10a8-41e8-bdc8-602bc03627a5.files
libvirt-92762faa-855e-43ab-8398-73f5cf54e7b9
libvirt-92762faa-855e-43ab-8398-73f5cf54e7b9.files
libvirt-ba5458f8-9ab6-4713-9bab-fdc620e4c64e
libvirt-ba5458f8-9ab6-4713-9bab-fdc620e4c64e.files
libvirt-c2bf8e0f-a7bc-4b01-ab12-bccae2ad43d0
libvirt-c2bf8e0f-a7bc-4b01-ab12-bccae2ad43d0.files
libvirt-d3397f74-1497-4f9a-9239-a941567f5201
libvirt-d3397f74-1497-4f9a-9239-a941567f5201.files
libvirt-e3a53b88-8c90-4126-b539-745e04d9169a
libvirt-e3a53b88-8c90-4126-b539-745e04d9169a.files
libvirt-e7d3374a-321b-4e50-9ca0-34ee843395c2
libvirt-e7d3374a-321b-4e50-9ca0-34ee843395c2.files
libvirt-ea10a337-7a16-469f-9bbf-49601a7390bc
libvirt-ea10a337-7a16-469f-9bbf-49601a7390bc.files
libvirt-f402a8d4-d6f3-4823-a20a-66c6e5a62924
libvirt-f402a8d4-d6f3-4823-a20a-66c6e5a62924.files
TEMPLATE.lxc
TEMPLATE.qemu
root@seton:~#

and indeed, it's not there.

I don't know how to debug this further, but please let me know if there's more
information I can provide.

Thanks,
--Robbie

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-4
ii  libacl12.2.53-4
ii  libapparmor1   2.13.2-9
ii  libaudit1  1:2.8.4-2
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-8
ii  libcap-ng0 0.7.9-2
ii  libdbus-1-31.12.12-1
ii  libdevmapper1.02.1 2:1.02.155-2
ii  libgnutls303.6.6-2
ii  libnl-3-2003.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libnuma1   2.0.12-1
ii  libselinux12.8-1+b1
ii  libvirt-clients5.0.0-1
ii  libvirt-daemon 5.0.0-1
ii  libvirt0   5.0.0-1
ii  libxml22.9.4+dfsg1-7+b3
ii  libyajl2   2.1.0-3
ii  logrotate  3.14.0-4
ii  lsb-base   10.2018112800
ii  policykit-10.105-25

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  ebtables 2.0.10.4+snapshot20181205-2
ii  iproute2 4.20.0-2
ii  parted   3.2-24

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.2-9
pn  auditd  
ii  nfs-common  1:1.3.4-2.4
pn  open-iscsi  
ii  pm-utils1.4.1-18
pn  radvd   
ii  systemd 241-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permiso denegado: 

Bug#924417: lintian: Allow *.pth files in python dist-packages

[Stewart Ferguson]

Package: lintian
Version: 2.9.1
Severity: normal
Tags: patch

Dear Maintainer,

/usr/lib/python*/dist-packages/*.pth files currently trigger lintian error
tag:

unknown-file-in-python-module-directory

*.pth should not be unknown. They are well-documented by the Python
specification[1] and this location is exactly where they belong.

Legitimate uses of this file exist in the archive.  python-
testing.mysqld[2] and python-input-pad[3] override this tag with the phrase
"false positive". The vast majority (>150) of others including python-
matplotlib and python-gobject-2 simply ignore this lintian error as they
deploy pth files[4].

There few important cases of this lintian error being raised including:
- debdry deploying 'control'
- python-cf deploying 'delme.nc'
- python-django-ranged-response deploying 'db.sqlite3'
- python3-csvkit deploying 'stdin_out.csv'

One could argue that the use of *.pth files should be discouraged.
Installing a package which deploys a *.pth can change the global python
environment. In this case a new tag (perhaps with lower severity) would be
more appropriate which warns the packager to carefully check the file's
contents and consider removing it. A more relevant tag describing the
position is less likely to be ignored than a general error which says this
Python-specification-compliant file is 'unknown'. A new tag would be more
appropriate than changing this tag because there are legitimate and
important instances of the existing tag as-is.

Best Regards,

Stewart Ferguson

[1] https://docs.python.org/3/library/site.html
[2] 
https://sources.debian.org/src/python-testing.mysqld/1.4.0-3/debian/python3-testing.mysqld.lintian-overrides/
[3] 
https://sources.debian.org/src/input-pad/1.0.3-3/debian/python-input-pad.lintian-overrides/
[4] 
https://lintian.debian.org/tags/unknown-file-in-python-module-directory.html

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-15
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.5
ii  dpkg-dev   1.19.5
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-4
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.54-1

-- no debconf information
From d63a53132f8aa87895f38cddee932b93f7d4f218 Mon Sep 17 00:00:00 2001
From: Stewart Ferguson 
Date: Tue, 12 Mar 2019 19:51:20 +0100
Subject: [PATCH] Allowing *pth files in python dist-packages

---
 data/files/allowed-python-files | 1 +
 1 file changed, 1 insertion(+)

diff --git a/data/files/allowed-python-files b/data/files/allowed-python-files
index e55d096c9..edaba07d9 100644
--- a/data/files/allowed-python-files
+++ b/data/files/allowed-python-files
@@ -4,3 +4,4 @@
 \.egg-info$
 \.so$
 \.py[ic]?$
+\.pth$
-- 
2.20.1



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

Bug#924416: yacas FTCBFS: multiple issues

[Helmut Grohne]

Source: yacas
Version: 1.3.6-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

yacas fails to cross build from source. The immediate failure is failing
to pass --host to ./configure. This can be solved by running ./configure
through dh_auto_configure. Additional configure flags can be passed to
dh_auto_configure after a "--". Then it tries to run code generators in
the manmake directory for the host architecture. Such generators need to
be built with the built architecture compiler. The autoconf-archive
provides a macro AX_PROG_CXX_FOR_BUILD to discover this compiler and the
attached patch demonstrates how to use it. Unfortunately, LT_INIT and
AX_PROG_CXX_FOR_BUILD don't work well together (#924415), so I'm
providing an additional workaround here. After fixing these, the build
of yacas itself succeeds, but the texdocs target runs yacas. I fear we
won't be able to generate the documentation in a cross build, but since
yacas-doc is an Architecture: all package, that can be avoided in
principle.

This may sound very complicated, but it really boils down to three
things:
 1. Run ./configure through dh_auto_configure.
 2. Apply my patch to make the manpage generators work.
 3. Avoid building documentation in an arch-only build.

I haven't provided a solution for the third part here. Please close this
bug if you fix 1 and 2. If you need help, please ask.

Helmut
--- yacas-1.3.6.orig/configure.ac
+++ yacas-1.3.6/configure.ac
@@ -15,6 +15,8 @@
 AC_PROG_CC
 AC_PROG_CPP
 AC_PROG_CXX
+m4_defun([_LT_LANG_CXX_FOR_BUILD_CONFIG],[])dnl make LT_LANG happy
+AX_PROG_CXX_FOR_BUILD
 
 AC_CHECK_PROG(have_perl, perl, yes, no)
 AC_CHECK_PROG(have_pdflatex, pdflatex, yes, no)
--- yacas-1.3.6.orig/manmake/Makefile.am
+++ yacas-1.3.6/manmake/Makefile.am
@@ -11,13 +11,13 @@
 ## PDF_DOCS   is either "pdf-docs" or empty
 all-am: @BOOKS_HTML@ @PDF_DOCS@ hints
 
-noinst_PROGRAMS = manripper removeduplicates
-
-manripper_SOURCES = manripper.cpp 
+manripper$(BUILD_EXEEXT): manripper.cpp
+	$(CXX_FOR_BUILD) -o $@ $^
 
-removeduplicates_SOURCES = removeduplicates.cpp
+removeduplicates$(BUILD_EXEEXT): removeduplicates.cpp
+	$(CXX_FOR_BUILD) -o $@ $^
 
-hints: manripper removeduplicates $(REFSOURCES) $(REFPROGSOURCES) ref.book.txt refprog.book.txt
+hints: manripper$(BUILD_EXEEXT) removeduplicates$(BUILD_EXEEXT) $(REFSOURCES) $(REFPROGSOURCES) ref.book.txt refprog.book.txt
 	rm -f hints.unsorted
 	for file in ref.book.txt $(REFSOURCES) refprog.book.txt $(REFPROGSOURCES); do \
 	./manripper $(srcdir)/"$$file" >> hints.unsorted ; done

Bug#924415: LT_LANG: unsupported language: "CXX_FOR_BUILD"

[Helmut Grohne]

Package: libtool,autoconf-archive
Tags: upstream

libtool.m4 does not work well with autoconf-archive. Specifically,
LT_INIT and AX_PROG_CXX_FOR_BUILD break when used together:

$ cat configure.ac
AC_INIT(foo,1,,,)
LT_INIT
AX_PROG_CXX_FOR_BUILD
$ aclocal
configure.ac:3: error: LT_LANG: unsupported language: "CXX_FOR_BUILD"
/usr/share/aclocal/libtool.m4:822: LT_LANG is expanded from...
/usr/share/aclocal/ax_prog_cxx_for_build.m4:37: AX_PROG_CXX_FOR_BUILD is 
expanded from...
configure.ac:3: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
$

The error message comes from:
https://sources.debian.org/src/libtool/2.4.6-10/m4/libtool.m4/#L834

The problem can be worked around by defining
_LT_LANG_CXX_FOR_BUILD_CONFIG before issuing AX_PROG_CXX_FOR_BUILD. Can
you come up with a better solution?

Helmut

Bug#924269: chiark-really: providing bin:sudo

[Dmitry Bogatov]

[2019-03-11 11:23] Ian Jackson 
> Dmitry Bogatov writes ("Bug#924269: chiark-really: providing bin:sudo"):
> > Package: chiark-really
> > Version: 6.0.3
> > Severity: wishlist
> ...
> > please consider making chiark-really drop-in replacement for sudo. For
> > my own purposes,
> > alias sudo='PATH=/bin:/sbin:/usr/bin:/usr/sbin /usr/sbin/really'
> > is perfectly fine, but some packages pull dependency on bin:sudo
> > (ubuntu-dev-tools, as example). What about making
> > 
> > bin:really-sudo, which provides `sudo` wrapper and Conflicts+Provides sudo?
>
> What an interesting idea.
>
> I definitely don't want to make this always be the case.  In general I
> really hate the way that build scripts all over the universe think
> they are allowed to make themselves root, and the fact that I have no
> sudo is then very useful: I get some message about sudo not found,
> usually followed by a pile of random junk as the script blunders on
> anyway.
>
> I wonder if maybe
>   ln -s /usr/sbin/really /usr/local/sbin/sudo
> would suffice for your use case?

No, since problem is with debian packages relationships. And, by the
way, /sbin/really does not set PATH. Note, that I do not propose
complicating bin:chiark-really, I propose separate binary package with
tiny wrapper.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924414: RFP: rke -- Rancher Kubernetes Engine, an extremely simple, lightning fast Kubernetes installer that works everywhere.

[Varac]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rke
  Version : 0.2.0
  Upstream Author : Alena Prokharchyk 
* URL : https://github.com/rancher/rke
* License : Apache 2.0
  Programming Lang: Golang
  Description : Rancher Kubernetes Engine, an extremely simple, lightning 
fast Kubernetes installer that works everywhere.

Rancher Kubernetes Engine (RKE) is a light-weight Kubernetes installer that 
supports installation on bare-metal and virtualized servers. RKE solves a 
common issue in the Kubernetes community: installation complexity. With RKE, 
Kubernetes installation is simplified, regardless of what operating systems and 
platforms you’re running.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAlyH/A4QHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBOHLD/9IdHBllMWiTZz/Vfe/fRCUepz12wbgXRbo
Cl0cUtMZr5JrkdvC1fSRsb/QhBY4O3jPOvAJzAPwirslD0axolEGzc2gVFXwS2yO
ykFsK2Y9kZbwaUQrVc+h/U7kmjV4VR0FuiV9gQNRRA+BvemxR62K6CPZx9uKbkbE
uYsiaWAE+EbeM9LxP6HxdmqlNzYIPWybXsKeub2KozUTZMTnqQeZTM7b6CvRmyO2
wb3TMdAawhgRJwhu/fBpRDlQ/KIDROIrvyyVNvPgde6Vz2ni+m1yEaje0D4a2Fhh
2jQkw8rzjC6JXhpcVONMVkIbGsTRJe1UlH4PVTq9JP/NWECzX9SNubB+VlG1+BjO
dAc23xRL1HPTJpKChNp1lD/P5D/+/T/rD8e9ohBsK75JRrnHSOb62o2q1GOWVQ03
dKvZPREEesjCm6GoZ3nfRK57AH+ZWA6zk/4WaifskC1qErVkM8/EQD3uXj4t4lMC
RKkzsRp2XU8AE2m5sovVu/hjmIUsLq79CZT8l87pUmZqTs9e+BCVydP+idZU6yfq
Ft0GWp2EAUPQEjx8UAAE4BmDDr0NeRjKtM9rzR+qasA/Iwi23r7POdEsKsp71Hgo
uI/xmrSM1AepmcGkQ281CpCabtpO5HGqMv9ryH3xCOnVATc4+Un/qWF/0OhYad/u
z31rw7C//Q==
=9LK7
-END PGP SIGNATURE-

Bug#919699: Please support -w switch to halt(8)

[Dmitry Bogatov]

control: tags -1 +help

[2019-03-11 16:24] Lorenzo Puliti 
> Package: runit-init
> Version: 2.1.2-25helpers1
> Followup-For: Bug #919699
>
> Hi,
>
> >I am okay with accepting patch to implement writing `wtmp' entry, if it
> >is reasonably small, but I would prefer to delegate it to external
> >implementation, like https://git.suckless.org/utmp (not sure it is
> >applicable).
>
> Just in case you don't know, there is already a 'sac' package that include a
> 'writetmp - write special wtmp entries to a wtmp file.' program.
>
> https://packages.debian.org/sid/sac
>
> The only thing is that last sac release is dated around Dec 2004 and last
> update of the Debian sac package is from Dec 2011, otherwise it looks the
> right external tool.

Just noticed, that bin:runit too provides tool for wtmp -- utmpset(8).
But it expects 'line' argument, and I do not know, what is correct value
for it.

halt.c from src:sysvinit pass '~~' as line, but utmpset(8) rejects such
usage. Any advice?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924082: more dh-sequences

[Chris Lamb]

Chris Lamb wrote:

> > We can grep through the Packages list to find more dh-sequence provides.
[..]
> https://salsa.debian.org/lintian/lintian/commit/34b939afb51b637f4d7708c8c3edcc1163f862d5

WIP patch for doing this automatically in private/refresh-debhelper-data
is:

diff --git a/private/refresh-debhelper-data b/private/refresh-debhelper-data
index 89df2810b..b19458fdf 100755
--- a/private/refresh-debhelper-data
+++ b/private/refresh-debhelper-data
@@ -124,6 +124,9 @@ else
 
 cd "$workdir"
 wget dists/sid/main/Contents-i386.gz
+wget dists/sid/main/binary-i386/Packages.gz
+gunzip Packages.gz
+
 zgrep -E "$dh_regex" Contents-i386.gz > dh_entries
 cat dh_entries \
 | perl -n -w -E 's#'"$dh_command_perl_regex"'#$1=$2# and print' \
@@ -133,11 +136,20 @@ else
 | perl -n -w -E 's#'"$dh_addon_perl_regex"'#$1=$2# and print' \
 | sed 's/=debhelper$/=debhelper | debhelper-compat/' \
 > dh_addons
+cat dh_entries \
+| perl -n -w -E 's#'"$dh_addon_perl_regex"'#$2# and print' \
+| while read X; do
+printf '%s=' $X; grep-dctrl -w -P -n $X -s Provides Packages \
+| perl -nle 'print join ",", m/dh-sequence-(\w+)/g'; \
+echo; \
+  done \
+| grep -E '=.' \
+| sort -u > dh_sequences
 cat dh_commands \
 | cut -d '|' -f 1 | sed 's/\s*$//' \
 | cut -d '=' -f 2 | sort -u > dh_packages
 
-for f in commands packages; do
+for f in commands packages sequences; do
 rf="$lintian_data/debhelper/dh_$f"
 [ ! -f "$rf" ] ||
 mv "$rf" "${rf}.old"
@@ -151,8 +163,6 @@ else
 create_data_file "$rf" < "dh_$f"
 done
 
-wget dists/sid/main/binary-i386/Packages.gz
-gunzip Packages.gz
 for package in $(cat dh_packages); do
 fn="$(grep-dctrl -n -P -X "$package" -sFilename Packages)"
 wget "$fn"

(This will need corresponding code in debhelper.pm to check this new
data file too, of course.)


Regards,

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

Bug#924413: RFP: helmfile -- Helmfile is a declarative spec for deploying helm charts.

[Varac]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: helmfile
  Version : 0.45.3
  Upstream Author : KUOKA Yusuke 
* URL : https://github.com/roboll/helmfile
* License : MIT
  Programming Lang: Golang
  Description : Helmfile is a declarative spec for deploying helm charts.

- - Keep a directory of chart value files and maintain changes in version 
control.
- - Apply CI/CD to configuration changes.
- - Periodically sync to avoid skew in environments.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAlyH+0sQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBM7yD/4wfQXgJ5TkaeBBEW7FhAU5YkSF1rGPK7/B
jHDDdC9jLOVmVhdPq0ixz1r1nkpq5C0P97BM+FkgtXbMfPE90rUandefQk2HRxXb
tUkF7MNmRzsjtmuAoBm8+abJq+vZZ1/xUr9XwHDndAQKrJRolot0mRTovtO1TECe
OKMUbGvUOxracyHqD0Tc7pKiNaNdYfvyU3lXqqaZtOzvjGSsYSiIVB2Ue3PGu2D9
d5PbrOj0vDvvwPLbkHdmT9TWmWPHW8wqoZXK3wEkh+B2k2J390l2ZTXSRem/WSMl
x7K2IFuabzLE0ou2ZO650x8oUrXLZTfK99UGjR2XNrwIb6TP9c8ojgU6iKpdcO0L
U0n48zfHEW7Bt2DIRozyQ3R8LSFnrEm+LdKqQj3Hkjz6Td1P1r8jF4J3jRLIG9iU
J0cKDW95xXhkMnqJtf1jUgAc2+MjrsxTZs2zFZujmu4Sr3SzY0onqCbhn2fFn/fm
xeeImlpEjhiOr380gQe6U2ZUM6C+j/ouO5dLrfxQi+RUS3ra2jOQnW+SD/6cAngY
RS0bJe4mlYnc3/Dz9BOb2dnshJ2ZWK5zqhHYzf3/c44SfGwiQsbdYIunTvOq65xF
4PoJbYgIcAY+Sz/DQ+Dz6tVMlM6TQJBvRrjYI2iUCltcbCjeBvlRsx65KrCiOAX1
4v52llMCdA==
=yuXM
-END PGP SIGNATURE-

Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Daniel Kahn Gillmor]

On Tue 2019-03-12 15:01:26 +, Simon McVittie wrote:
> If I understand their position correctly, the Debian systemd maintainers
> would consider that to be a misconfiguration, because
> Depends: libpam-systemd is the official way for a package to say "I need
> a fully working systemd-logind and systemd --user", and packages like
> dbus-user-session are allowed to assume that. If a sysadmin wants to
> not use pam_systemd (which will mean their systemd-logind doesn't work
> correctly and systemd --user doesn't get started), they should remove
> that package so it doesn't satisfy dependencies.

thanks for this clarification, it sounds reasonable to me.

> I'd be very tempted to make dbus-user-session the only implementation of
> dbus-session-bus on Linux if it wasn't for the systemd-related political
> reasons not to, because it's becoming increasingly clear to me that the
> "one bus per X11 display" case is decreasing in viability over time
> as upstreams and packagers both start to assume (the equivalent of)
> dbus-user-session.

This makes me a little bit sad, as someone who has in the past made good
use of multiple X11 displays for the same user, but i agree that it
reflects current reality pretty clearly.  Furthermore, the main use
cases i had in the past for multiple X11 displays were (a) testing, and
(b) X11 isolation, both of which are better served by a distinct user
account in the first place.

> No, I don't think we should. Many packages explicitly use dbus-launch
> (which is in dbus-x11.deb), even packages that should really be using
> something else (see my 2016 MBF). Historical design choices in dbus-launch
> mean that it does two different things when run with different options:
> some options try to reuse an existing bus, but some options guarantee
> to start a new bus.

fwiw, i helped someone debug a problem on IRC the other day, and it was
due to unnecessary use of dbus-launch in their ~/.Xsession (they were
doing something like "exec dbus-launch awesome" instead of just "exec
awesome", even though they had dbus-user-session installed).

So the existence of dbus-launch on their system was actually causing
them problems.  I think this was a case of problem-solving via "don't do
that then", but it seems likely that many folks have cargo-culted
dbus-launch into places where they don't necessarily need it, and where
it was unable to fall back to the dbus per-user session.

thanks for all of your work in fixing as many of these corner cases as
you've done, it's much appreciated!

   --dkg


signature.asc
Description: PGP signature

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

Hi Santiago,

On Tue, Mar 12, 2019 at 06:17:50PM +0100, Santiago Vila wrote:
> To be precise: Who is unpacking (but not configuring) a buster or
> unstable essential package set, if not a bootstrapping tool?

multistrap is doing just that.

https://manpages.debian.org/testing/multistrap/multistrap.1.en.html
| Once installed, the packages themselves need to be configured using
| the package maintainer scripts and "dpkg --configure -a", unless this
| is a native multistrap.

> Do any of them still don't know that base-passwd should be configured
> first because otherwise any other package using root (be it base-files
> or any other) will fail? I think this was already settled in the last
> discussion we had about this several years ago.

multistrap doesn't take care of this and you can provoke a
base-files.postinst failure this way.

Then there is mmdebstrap. I looked into it and couldn't find any code
that orders base-passwd or base-files or creates an /etc/passwd. It
might not fail now.

> Can you provide at least a bug number for the bootstrapping tool that
> apparently still tries to configure all packages at once, or
> base-passwd and base-files in the same row?

#924401, but I'm not yet sure which part we need to fix.

I really like Simon's (thank you for that enlightening reply) view of
interpolating the uids. It removes a bunch of problems from the equation
and works well when bootstrapping from non-Debian or from ancient Debian
releases even in chrootless mode. At the same time, it is quite safe
(due to the static allocation) and easy to implement. I fail to see
downsides.

Just because debootstrap encodes a ton of hacks to make things barely
work (and break every so often) doesn't mean we have to maintain them
until eternity.

> In other words: Is the present bug report to be considered in a
> theoretical way, or it is the result of some problem that you actually
> found recently with a bootstrapping tool?

I don't have a minimal test case at hand, but I can reproduce it with
multistrap at least.

Helmut

Bug#924405: in Buster

[Andreas Beckmann]

On 2019-03-12 18:02, Karl-Heinz Künzel wrote:
> and screenshot nvidia page, that those mentioned graphic board are
> supported by 410.93

See also
https://www.nvidia.com/object/IO_32667.html


Andreas

Bug#924412: RFP: krew -- krew is the package manager for kubectl plugins.

[Varac]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: krew
  Version : 0.2.1
  Upstream Author : Ahmet Alp Balkan 
* URL : https://krew.dev
* License : Apache-2.0
  Programming Lang: golang
  Description : krew is the package manager for kubectl plugins.

krew is a tool that makes it easy to use kubectl plugins. krew helps you 
discover plugins, install and manage them on your machine. It is similar to 
tools like apt, dnf or brew.

- - For kubectl users: krew helps you find, install and manage kubectl plugins 
in a consistent way.
- - For plugin developers: krew helps you package and distribute your plugins 
on multiple platforms and makes them discoverable.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAlyH+dgQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBFc6D/9RLTSqMZrIzrC2TCdII4hK3bb8zS6CQNhN
Anr76AVfda1BWEvUf0nC0QI+7Hr8wx8lalYC/Nv7Bz/nwfr/Rw9E4IGtf9MYa3rf
EFLhshwbz7VskYBoVpGCmLRKCUApbJQBKn2arqAnYjNPw3v2qGIhxJho2sx8KyBJ
csy8hDK+pbUKYUKt9gGYQSBOIXUJWcpOX+0jJMRE1dW0Zgp4zIiTWWEEFeGbwQDc
gKXpXxNK0EaMkiIdSfS83iHAuxjAVgyk7IjxI/fnS3mONFy64MCP53eSSaRG+GiL
6kv/7fCh/ATssT7dWgyFrcqKpYB0WQAfPnRMHoQPAhyTMP2fKHyxVsUGv57Z9INO
tO+qiYiKROuVVvymd6QIHzim4T7RRDbV92i3dVwV5rhhLO6Vx5TTjANDySX9sBnm
hvFMBzLewKu3NczrWsMPtmHshai4EWwdf5Suu/llIGoAOp8i9RaN1TiOV1Ces/88
BNeYSjvL8VjMt7eIh7kyn7+wPdiFhlCdgb8urc/4yP71bYBfxKkDWUBdyLhuQoWG
oAK/cs65dguALGQvo+dngHdsCAob4wzeTBVF6TOiYo9Kl92PN9rWk/tmrDiK7sJF
urg30pUq6F5T8Rw4Q1N79+e+zS4G0GNwmsPkYHLM4ziIFPRctmiLbsJ9KgWyo36w
Mgkl8C4KNQ==
=ZJqU
-END PGP SIGNATURE-

Bug#865140: Broken with network-manager 1.8.0-5 (at least for split tunnel)

[Mike Miller]

On Mon, Jun 19, 2017 at 09:07:44 -0700, Russ Allbery wrote:
> After upgrading network-manager to 1.8.0-5 from 1.6.2-3, connecting to
> a VPN with network-manager-openconnect still works but doesn't set up
> the routing table entries properly.  (This is a split-tunnel VPN.)  I'm
> guessing something changed in the NetworkManager internals that broke
> part of this plugin.
> 
> The problem went away again after downgrading network-manager back to
> 1.6.2-3.

Unfortunately I can't easily test this to try to reproduce.

Are you still affected by this bug with network-manager 1.14.6-2 and
network-manager-openconnect 1.2.4-2 in testing?

If so, it would be helpful to know if it's fixed in upstream git (it's
been a long time since the last release), if there's an upstream issue,
or what configuration is needed to reproduce this.

Sorry for the delay,

-- 
mike


signature.asc
Description: PGP signature

Bug#924220: sddm-theme-debian-maui: background-nologo.svg from theme.conf does not exist

[Matthew Crews]

On Sun, 10 Mar 2019 12:22:07 +0100 Robert  wrote:
> Package: sddm-theme-debian-maui
> Version: 0.18.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> "/usr/share/sddm/themes/debian-maui/theme.conf" contains
> "background=/usr/share/desktop-base/active-theme/login/background-nologo.svg",
> but the "background-nologo.svg" does not exist on a fresh installed debian
> testing.
> 
> There is only a "background.svg" and a "background-withlogo.svg" under
> "/usr/share/desktop-base/active-theme/login/"

This is  a problem when upgrading from Stretch to Buster as well.
background-nologo.svg is deleted from the system as a result of the
change in default theme to FuturePrototype from softWaves.

This should be classified as a critical bug IMO, as it directly impacts
KDE Plasma users upgrading from Stretch to Buster.



signature.asc
Description: OpenPGP digital signature

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Christoph Müllner]

I've been able to reproduce and analyse this issue.

The security error seems to be valid.

What actually happens is, that dmidecode does the following (strace):

> openat(AT_FDCWD, "/dev/mem"
> , O_RDONLY)  = 3
> fstat(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
> mmap(NULL, 65536, PROT_READ, MAP_SHARED, 3, 0xf) = 0x8777
> --- SIGBUS {si_signo=SIGBUS, si_code=BUS_OBJERR, si_addr=0x8777} ---
> +++ killed by SIGBUS +++
> Bus error

According to the dmidecode source code (dmidecode.c) this is some sort
of fallback mechanism for x86 and or x86_64. In any case that's not a valid
access on arm64.

I think this should not be done in dmidecode on non-x86 machines (maybe with 
#ifdef __x86_64__ and friends).

> ...
> memory_scan:
> 
> if
>  (!(opt.flags & FLAG_QUIET))
> printf(
> "Scanning %s for entry point.\n"
> , opt.devmem);
> /* Fallback to memory scan (x86, x86_64) */
> 
> if
>  ((buf = mem_chunk(0xF, 0x1, opt.devmem)) == NULL)
> {
> ret = 1;
> 
> goto
>  exit_free;
> }
> ...


The reason why the fallback is executed is that the kernel does not find DMI
and reports this during bootup as:

> [0.353729] DMI not present or invalid.

This is caused by the fact that the bootloader (U-Boot) does not have
EFI support enabled and thus does not provide the DMI.
This is something we will address.

Bug#924272: decopy: FTBFS (mv: cannot stat 'README.1': No such file or directory)

[Vincent Blut]

Package: decopy
Version: 0.2.4.1-1
Followup-For: Bug #924272

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

The attached patch fixes this issue. Please apply!

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAlyH9ZUXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4DP/w/9FRwUyxTb4xR5wMWcRXYLSOwz
2I0M+L0sjiOEFGxMd/imKhm/ekOMYr8kS+wDHbkEVRhtDNDsES33s2DSJwVrV3Cm
aRJJWPbDa/hH5QTkWbNthrST7gnGlhnMZb40MlJdnLgHHqy12mKnzgrP4ymyqSCZ
+xtnMHvU/8LxVbVeFvujTFbpSLcxBguQWG+/ilEUh8/p/fzWkrbjssX+WCm+iNAu
UxpQ0E+fH1qguPabqF88vaNLNvq39AymL/F/2BZqAYqPrQ1JOoQmvum0SzquMiO6
KPTC51J2UUfjNqKc0avESxVJdKlJw4KRyfFo4SePpG2tuvHLh//nfBlmJR7Plbxr
qLNm0UxFCDJKrvlgPAUyLI4eMiEuGuR/kQTvst5yV6siuA0ExFKtAJpLx5VlYaPA
0Va+MpxCQ3uu70oQaeUUe2rDjLpu/hw1Nsma8tYS2asEFL1egEqDWBW3EtvHUEOh
nHvHfcl3V4vyZ/dgqTZL3tIUw57WvIL6q0XeCFirYuxEcPIpt1Qs6OE9O9CjfqO6
v3ttOdfISBDksY0bd8CfW7rgpY8RcTOCGsy/rf3XcA5tpPbZatrGRPWsQc46Wx+B
ps0jsEdqIC7mYzCsGTCFtE90VlPlq8uPQ8yuXXOTRyMB1+9wiJ2nTcL0ynFyAN+s
63iakMVP3MsuFTHrZYI=
=7aks
-END PGP SIGNATURE-
>From 6a7f600b19b024e48fd38f1b1a9069d55a74c7ab Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Tue, 12 Mar 2019 18:36:49 +0100
Subject: [PATCH] Fix FTBFS due to incorrect filename

Closes #924272
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index f5a0731..f50f790 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,8 +8,8 @@
 override_dh_auto_build:
dh_auto_build
ronn README.md
-   mv README.1 decopy.1
-   mv README.1.html decopy.1.html
+   mv README.md.1 decopy.1
+   mv README.md.1.html decopy.1.html
 
 override_dh_auto_test:
LC_ALL=C.UTF-8 dh_auto_test
-- 
2.20.1

Bug#924361: smcroute: racy systemd unit start (and autopkgtest failure)

[Joachim Nilsson]

Hi Steve!

On Mon, Mar 11, 2019 at 04:37:52PM -0700, Steve Langasek wrote:
> Thanks for the fixes to the smcroute autopkgtests in 2.4.2-4.  I've synced
> this new version into Ubuntu, and the autopkgtests have now passed on all
> architectures *except* for i386:
> [snip]
> autopkgtest [11:06:00]: test daemon-init-scripts: [---
> ok 7 - starting smcroute
> not ok 8 - smcroute is really running
> #   Failed test 'smcroute is really running'
> #   at /tmp/autopkgtest.Fz4BvX/build.HSu/src/debian/tests/daemon-init-scripts 
> line 36.
> #  got: '1'
> # expected: '0'
> Considering that the behavior of the tests here is to: check whether
> smcroute is running, then restart it, then check again if it's running; and
> only the first check fails; this looks to me like it might be a startup
> race.

Yes indeed, that seems to be the case.  The tests require a bit
of love and encouragement to get into shape.

> [snip]
> So, since you are starting the service and then immediately checking if the
> service is running (using pgrep), it's possible that this is running into a
> race because systemd is returning success immediately.  But even if that's
> not the cause of the autopkgtest failure, since smcrouted is a daemon that
> provides a socket IPC interface, this would still be a bug (race condition)
> in the startup of the service since systemd can definitely return before
> smcrouted is listening on the socket.

Yup.

I'll see what I can do about this.  I'm still very much a Debian n00b,
but I'll try to set up a unit test environment to sandbox my fixes. 
The last fixes were made with a blindfold on ...

Cheers
 /Joachim

Bug#924410: Patch available

[Louis-Philippe Véronneau]

Control: tag -1 patch

Dear maintainers,

I've create a Merge Request on Salsa [1] with a patch for this bug.

Don't hesitate to communicate with me if there is anything wrong with it.

[1] https://salsa.debian.org/mailman-team/hyperkitty/merge_requests/1

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#924411: RFS: vitetris/0.58.0-1

[Baptiste BEAUPLAT]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: vitetris
Version : 0.58.0-1
Upstream Author : Victor Geraldsson
  * URL : http://www.victornils.net/tetris/
  * License : BSD-2-Clause
Section : games

It builds those binary packages:

  vitetris - Virtual terminal *tris clone

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.58.0-1.dsc

More information about vitetris can be obtained from
https://salsa.debian.org/lyknode-guest/vitetris.

Changes since the last upload:

   * New upstream version 0.58.0
   * Drop patches applied upstream:
 - 0005-fix-implicit-declaration.patch
 - 0002-fix-insecure-printf.patch
   * d/watch: Remove leftover from dh_make template

Regards,

-- 
Baptiste BEAUPLAT - lyknode





signature.asc
Description: OpenPGP digital signature

Bug#923609: proposed solution

[Niko Tyni]

On Sun, Mar 10, 2019 at 07:12:43PM +, Dmitry Bogatov wrote:

> Good. Try this version of patch, please. It seems to works for me in my
> i386 chroot.

Works for me too, and light testing didn't reveal any problems.

> > It would make sense to limit this to 32-bit architectures as I believe the
> > 64-bit architectures always have LFS support no matter the build flags.
> 
> I'd leave it as-is. Yes, it may be redundant on 64 bit platforms, but it
> will go away rather soon anyway. I'd rather not complicate `debian/rules'.

Whatever, just seems strange to me to ship a -nolfs binary that's actually
LFS enabled just like the normal one.

> > Shipping these -nolfs binaries and including instructions for upgrading
> > databases in the Buster release notes would be an acceptable fix for
> > this issue IMO.

> By the way, should I file bug aganist release.debian.org now, or when we
> are settled on solution?

I'm fine with either, and I think we're pretty much settled now :)

Thanks for your work,
-- 
Niko

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
>Depends: libavcodec58 (= 7:4.1.1-2),
> libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
> (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> libswscale5 (= 7:4.1.1-2)
>  Suggests: ffmpeg-doc

You might want to add a Suggests on ffplay, as well.

Bug#924410: 'manage.py' uses '/usr/bin/env python' instead of '/usr/bin/python3'

[Louis-Philippe Véronneau]

Package: python3-django-hyperkitty
Severity: normal

Dear maintainers,

On systems running both python2 and python3 and where python2 is the
default, running 'example_project/manage.py' fails, since this is a
python3 package. (i.e. hyperkitty can't be imported by python2 since it
is not installed in the python2 path).

This is important since the files in 'example_project' are a very good
way to bootstrap an hyperkitty instance without having to create a
Django project manually.

I'll send a patch today.

Thanks for packaging this!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature