Bug#930401: mutter: Crashes on restart if Static Workspaces are enabled (gnome-shell)

[Matthew Gabeler-Lee]

Package: mutter
Version: 3.30.2-7
Severity: normal
Tags: upstream

If you enable static instead of dynamic workspaces, then gnome-shell
segfaults if you restart it.

This has been reported and fixed upstream in 3.32.x, it would be nice if
this fix could be backported to Debian's 3.30.x release.

https://gitlab.gnome.org/GNOME/mutter/issues/479
https://gitlab.gnome.org/GNOME/mutter/merge_requests/466
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1796607

Note: I've put "gnome-shell" in the title in the hopes of making it
discoverable by web search, since the user perception is that this happens
when restarting gnome-shell, even though the upstream bug/fix is in mutter.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (490, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-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 mutter depends on:
ii  gnome-settings-daemon-common  3.30.2-3
ii  gsettings-desktop-schemas 3.28.1-1
ii  libc6 2.28-10
ii  libglib2.0-0  2.58.3-2
ii  libmutter-3-0 3.30.2-7
ii  libx11-6  2:1.6.7-1
ii  libxcomposite11:0.4.4-2
ii  mutter-common 3.30.2-7
ii  zenity3.30.0-2

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.30.3-1
ii  xdg-user-dirs 0.17-2

-- no debconf information

Bug#930404: [Meta] move gitlab back to main from contrib

[Pirate Praveen]

Package: gitlab
Version: 11.8.10+dfsg-1
Severity: wishlist
Control: block -1 by 863293
Control: block -1 by 930372

This is a meta bug to track progress of packaging node dependencies.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[tony mancill]

On Wed, Jun 12, 2019 at 12:37:11AM +0200, Moritz Mühlenhoff wrote:
> On Mon, Jun 10, 2019 at 09:46:41PM -0700, tony mancill wrote:
> > I am not a member of the OpenJDK team and contributed far less to the
> > JDK 8 -> 11 transition than Emmanuel has.  If he and Matthias are in
> > agreement and the plan is palatable to the Release and Security Teams,
> > that's ideal.
> 
> I don't have any preference either, just adding my 2 cents here; with
> our buster release set to 6th of July and the next Oracle CPU set for
> July 16, we'll ship a non-GA release of Java for maybe two, at most three
> weeks (as buster-security will rebase to the next openjdk-11 following
> the CPU). I'm also fairly sure we've shipped non-GA releases for openjdk-8
> before?
> 
> In any case, whether we go with t-p-u or unblocking the sid version,
> we should fix a solution before the release and not ship buster with
> the unfixed issues from the April CPU :-)

Regarding t-p-u and/or unstable, a source package and build of
11.0.4+4+really11.0.3+7 can be found here:

  https://people.debian.org/~tmancill/openjdk-11/

The interdiff [1] between this build and the 11.0.3+7-5 discussed
previously in this thread and this build is small (as would be
expected).  The debdiff [2] against 11.0.4+4-1 is (predictably) huge, as
it reverts all of the 11.0.4 development.  The packaging changes against
unstable are also attached.

I have done some basic smoke-testing of the 11.0.4+4+really11.0.3+7
packages - e.g. running zookeeper and building a few packages that
depend on the JDK.  The version reported by JVM is:

> $ java -version
> openjdk version "11.0.3" 2019-04-16
> OpenJDK Runtime Environment (build 11.0.3+7-post-Debian-1)
> OpenJDK 64-Bit Server VM (build 11.0.3+7-post-Debian-1, mixed mode, sharing)

Note that the date reported is part of JDK.  Even the current version in
buster, which was uploaded in February, reports the future "GA" date:

> $ java -version
> openjdk version "11.0.3" 2019-04-16
> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1)
> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1, mixed mode, sharing)

Decision time... :)

Thanks,
tony

[1] 
https://people.debian.org/~tmancill/openjdk-11/interdiff_buster_11.0.3+7+5_vs_11.0.4+4+really11.0.3+7-1.diff
[2] 
https://people.debian.org/~tmancill/openjdk-11/11.0.4+4-1.dsc_vs_11.0.4+4+really11.0.3+7-1.dsc.debdiff
diff --git a/debian/changelog b/debian/changelog
index af1e3ee8a..eeba772dd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+openjdk-11 (11.0.4+4+really11.0.3+7-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert upstream sources to GA release 11.0.3+7.
+  * Disable workaround_expand_exec_shield_cs_limit.diff and
+hotspot-disable-exec-shield-workaround.diff patches
+  * No longer try to install jspawnhelper.
+
+ -- tony mancill   Mon, 10 Jun 2019 19:16:00 -0700
+
 openjdk-11 (11.0.4+4-1) unstable; urgency=medium
 
   * OpenJDK 11.0.4+4 build (early access).
diff --git a/debian/patches/series b/debian/patches/series
index 8d10621eb..d057ce0af 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,7 +6,7 @@ icedtea-override-redirect-compiz.diff
 libpcsclite-dlopen.diff
 jexec.diff
 default-jvm-cfg.diff
-workaround_expand_exec_shield_cs_limit.diff
+#workaround_expand_exec_shield_cs_limit.diff
 adlc-parser.diff
 multiple-pkcs11-library-init.diff
 s390x-thread-stack-size.diff
@@ -20,7 +20,7 @@ machine-flag.diff
 zero-x32.diff
 mips-sigset.diff
 # s390x-zEC12.diff
-hotspot-disable-exec-shield-workaround.diff
+#hotspot-disable-exec-shield-workaround.diff
 atk-wrapper-security.diff
 # java-access-bridge-security.diff
 # jdk-pulseaudio.diff
diff --git a/debian/rules b/debian/rules
index 0a12fba23..3ee4fc237 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,7 +91,9 @@ else
 endif
 jvmver		= 1.11.0
 shortver	= 11
-v_upstream	:= $(shell echo $(PKGVERSION) | sed 's/-[^-][^-]*$$//')
+#v_upstream	:= $(shell echo $(PKGVERSION) | sed 's/-[^-][^-]*$$//')
+#v_pkgrel	:= $(shell echo $(PKGVERSION) | sed 's/^.*-//')
+v_upstream	:= 11.0.3+7
 v_pkgrel	:= $(shell echo $(PKGVERSION) | sed 's/^.*-//')
 # FIXME. currently v_upstream like 11~4
 v_upbase	:= $(word 1, $(subst +, , $(v_upstream)))
@@ -100,9 +102,9 @@ v_upbuild	:= $(word 2, $(subst +, , $(v_upstream)))
 #v_upbuild	:= $(word 2, $(subst ~, , $(v_upstream)))
 # that should be the package version ...
 
-ifneq ($(PKGVERSION),$(v_upbase)+$(v_upbuild)-$(v_pkgrel))
-  $(error wrong version: $(v_upbase)+$(v_upbuild)-$(v_pkgrel) should be: $(PKGVERSION))
-endif
+#ifneq ($(PKGVERSION),$(v_upbase)+$(v_upbuild)-$(v_pkgrel))
+#  $(error wrong version: $(v_upbase)+$(v_upbuild)-$(v_pkgrel) should be: $(PKGVERSION))
+#endif
 #ifneq ($(PKGVERSION),$(v_upbase)~$(v_upbuild)-$(v_pkgrel))
 #  $(error wrong version: $(v_upbase)~$(v_upbuild)-$(v_pkgrel) should be: $(PKGVERSION))
 #endif
@@ -1201,7 +1203,6 @@ endif
 	  echo '$(basedir)/lib/jli/libjli.so'; \
 	  echo '$(basedir)/lib/ct.sym'; \
 	  echo 

Bug#930402: kball FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: kball
Version: 0.0.20041216-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kball fails to cross build from source, because it uses the build
architecture compiler. It uses a non-standard variable GCC for the
compiler while debhelper passes it as CXX. After renaming the variable,
kball cross builds successfully. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru kball-0.0.20041216/debian/changelog 
kball-0.0.20041216/debian/changelog
--- kball-0.0.20041216/debian/changelog 2016-06-03 09:51:11.0 +0200
+++ kball-0.0.20041216/debian/changelog 2019-06-12 06:18:27.0 +0200
@@ -1,3 +1,10 @@
+kball (0.0.20041216-11) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass C++ compiler as GCC. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Jun 2019 06:18:27 +0200
+
 kball (0.0.20041216-10) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru kball-0.0.20041216/debian/rules 
kball-0.0.20041216/debian/rules
--- kball-0.0.20041216/debian/rules 2016-06-03 09:51:11.0 +0200
+++ kball-0.0.20041216/debian/rules 2019-06-12 06:18:24.0 +0200
@@ -14,6 +14,9 @@
$(RM) test_linux.bin
$(RM) test.run
 
+override_dh_auto_build:
+   dh_auto_build -- 'GCC=$$(CXX)'
+
 override_dh_install-indep:
dh_install bin/*.dat usr/share/games/kball
dh_install bin/levels/*.map usr/share/games/kball/levels

Bug#930403: ibod FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: ibod
Version: 1.5.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ibod fails to cross build from source, because its make install passes
the -s flag to install and thus uses the wrong strip. Beyond breaking
cross compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
generating a -dbgsym package. The attached patch disables such stripping
and defers it to dh_strip instead. Please consider not applying the
patch and bumping the compatibility level to 11 or higher. In that
level, debhelper will disable the stripping. Failing that, consider
applying the patch.

Helmut
diff --minimal -Nru ibod-1.5.0/debian/changelog ibod-1.5.0/debian/changelog
--- ibod-1.5.0/debian/changelog 2012-05-29 11:19:25.0 +0200
+++ ibod-1.5.0/debian/changelog 2019-06-12 06:27:08.0 +0200
@@ -1,3 +1,10 @@
+ibod (1.5.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't strip during dh_auto_install. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Jun 2019 06:27:08 +0200
+
 ibod (1.5.0-6) unstable; urgency=low
 
   * Fix typo in package description. (Closes: #24)
diff --minimal -Nru ibod-1.5.0/debian/rules ibod-1.5.0/debian/rules
--- ibod-1.5.0/debian/rules 2012-05-22 16:46:22.0 +0200
+++ ibod-1.5.0/debian/rules 2019-06-12 06:27:07.0 +0200
@@ -2,6 +2,9 @@
 %:
dh $@
 
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'
+
 override_dh_installppp:
dh_installppp --name=00-ibod
dh_installppp --name=zz-ibod

Bug#927254: [Pkg-javascript-devel] Bug#927254: possible solution

[Paolo Greppi]

On 10/06/19 20:03, Paolo Greppi wrote:

...
Tomorrow I'll test the generated file inside laminar. If that works this is an 
acceptable solution.
The last bit is to move this config change to debian/rollup-umd.js so that it 
does not impact all builds..

Paolo



I tested with the non-minified file generated using the patched build/config.js 
and this command:
NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd.js
but when opening the laminar dashboard I get a new error:

vue-router.min.js:1195 Uncaught TypeError: Cannot read property 'forEach' of 
undefined
at compileRouteRegex (vue-router.min.js:1195)
at addRouteRecord (vue-router.min.js:1112)
at vue-router.min.js:1061
at Array.forEach ()
at createRouteMap (vue-router.min.js:1060)
at createMatcher (vue-router.min.js:1274)
at new VueRouter (vue-router.min.js:2374)
at app.js:796

Not sure if this is due to some path-to-regexp API change.

Anyway that code is skipped for the minified version:
https://salsa.debian.org/js-team/vue-router.js/blob/master/src/create-route-map.js#L156

so I tested the file generated with:
NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd-min.js

and the JavaScript now works apart from some missing CSS and vue is in dev mode 
(see attached screenshot)

So I confirm that the way to go to fix the issue with libjs-vue-router minified 
UMD build is to enable rollup-plugin-node-resolve.
The proposed config change should be moved from build/config.js to 
debian/rollup-umd*.js so that it does not impact the other builds.

But the dev mode, minified UMD build would be affected by the exception above, 
generated in compileRouteRegex function.

Paolo

Bug#930351: linux-image-4.9.0-9-amd64: soft lockup / stuck in pid_revalidate

[Bernhard M. Wiedemann]

Package: src:linux
Version: 4.9.168-1+deb9u2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 ran the server for some days with KVM VMs on top
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Tried to ssh + ping.
   * What was the outcome of this action?
 ssh session got stuck. Ping still worked.
   * What outcome did you expect instead?
 should work

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


-- Package-specific info:
** Version:
Linux version 4.9.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-9-amd64 
root=UUID=83dcd5bf-42df-4931-aa7a-e09d8ecf6bb5 ro nomodeset nohz=off panic=30

** Not tainted

** Kernel log:
(obtained via netconsole)
Message from syslogd@golf at Jun 11 06:37:56 ...
 kernel:[1616241.072680] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! 
[ps:28525]

[1626796.848128] CPU: 5 PID: 28525 Comm: ps Tainted: G  D  L  
4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u2
[1626796.848205] Hardware name: MSI MS-7816/H87-G43 (MS-7816), BIOS V2.14B4 
07/31/2013
[1626796.848277] task: 88d2c5923080 task.stack: 9e7fcf8a4000
[1626796.848337] RIP: 0010:[]  [] 
native_queued_spin_lock_slowpath+0x10f/0x1a0
[1626796.848459] RSP: 0018:9e7fcf8a7c70  EFLAGS: 0246
[1626796.848518] RAX:  RBX: 88da78f18140 RCX: 
0003  
[1626796.848595] RDX: 88da9eb59480 RSI: 0018 RDI: 
88da78f18860  
[1626796.848673] RBP: 88da787e5088 R08:  R09: 
88d4fc338025  
[1626796.848745] R10: 88da9d1b99f8 R11:  R12: 
88da78f18860  
[1626796.848817] R13: 88da786fecc0 R14: 9e7fcf8a7d70 R15: 
88da9d4d44e0  
[1626796.848889] FS:  7f461c3ba880() GS:88da9eb4() 
knlGS:
[1626796.848962] CS:  0010 DS:  ES:  CR0: 80050033
[1626796.849020] CR2: 557cc5139688 CR3: 7e5f CR4: 
00162670  
[1626796.849093] Stack:
[1626796.849147]  9941a79d 9907e5af 9e7fcf8a7d78 
9e7fcf8a7de0
[1626796.849370]  88da9d1b99c0 9e7fcf8a7d78 990175cf 
9e7fcf8a7d6c
[1626796.849597]  9e7fcf8a7de0 9e7fcf8a7cf0 679aab8063728a19 
9e7fcf8a7d78
[1626796.849817] Call Trace:
[1626796.849872]  [] ? _raw_spin_lock+0x1d/0x20
[1626796.849931]  [] ? pid_revalidate+0x4f/0xf0
[1626796.849994]  [] ? lookup_fast+0x2cf/0x2f0
[1626796.850054]  [] ? path_openat+0x178/0x15b0
[1626796.850113]  [] ? filename_lookup+0xf1/0x180
[1626796.850173]  [] ? do_filp_open+0x91/0x100
[1626796.850233]  [] ? __check_object_size+0xfa/0x1d8
[1626796.850294]  [] ? do_sys_open+0x12e/0x210
[1626796.850356]  [] ? do_syscall_64+0x8d/0x100
[1626796.850417]  [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[1626796.850478] Code: 12 83 e0 03 83 e9 01 48 c1 e0 04 48 63 c9 48 05 80 94 01 
00 48 03 04 cd e0 f3 86 99 48 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 <85> c0 
74 f7 4c 8b 02 4d 85 c0 74 08 41 0f 18 08 eb 02 f3 90 8b


and another had
[1626780.842859] Call Trace:
[1626780.842914]  [] ? _raw_spin_lock+0x1d/0x20
[1626780.842974]  [] ? pid_revalidate+0x4f/0xf0
[1626780.843034]  [] ? lookup_fast+0x2cf/0x2f0
[1626780.843093]  [] ? walk_component+0x44/0x330
[1626780.843153]  [] ? path_lookupat+0x67/0x120
[1626780.843216]  [] ? filename_lookup+0xb1/0x180
[1626780.843277]  [] ? mem_cgroup_commit_charge+0x78/0x4b0
[1626780.843340]  [] ? __check_object_size+0xfa/0x1d8
[1626780.843401]  [] ? strncpy_from_user+0x48/0x160
[1626780.843465]  [] ? vfs_fstatat+0x59/0xb0
[1626780.843526]  [] ? SYSC_newlstat+0x2d/0x60
[1626780.843586]  [] ? do_syscall_64+0x8d/0x100
[1626780.843648]  [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6


** Model information
sys_vendor: MSI
product_name: MS-7816
product_version: 1.0
chassis_vendor: MSI
chassis_version: 1.0
bios_vendor: American Megatrends Inc.
bios_version: V2.14B4
board_vendor: MSI
board_name: H87-G43 (MS-7816)
board_version: 1.0

** Loaded modules:
ipt_REJECT
nf_reject_ipv4
iptable_filter
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_multiport
xt_nat
xt_tcpudp
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
ip_tables
x_tables
nfnetlink_queue
nfnetlink_log
nfnetlink
bluetooth
rfkill
cpufreq_conservative
cpufreq_powersave
cpufreq_userspace
algif_skcipher
af_alg
tun
loop
dm_crypt
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
i915
ghash_clmulni_intel
intel_cstate
iTCO_wdt
iTCO_vendor_support
mei_me
mei
intel_uncore
mxm_wmi
drm_kms_helper
intel_rapl_perf
pcspkr
lpc_ich
drm
evdev
serio_raw
shpchp
wmi
sg
button
mfd_core
video
i2c_algo_bit
ext4
crc16
jbd2
fscrypto
ecb
mbcache
btrfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx

Bug#930314: [debian-mysql] Bug#930314: mariadb-10.3 FTCBFS: multiple reasons

[Otto Kekäläinen]

Hello!

I converted the patch into a git commit at
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/a91d8491ce4587efdc41f11b73905f261f0366d4

Tests running at
https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines/50365

Bug#927254: [Pkg-javascript-devel] Bug#927254: possible solution

[Paolo Greppi]

On 11/06/19 08:03, Pirate Praveen wrote:

I think rollup-plugin-commonjs will also work without extra options, see 
node-d3-fetch.



rollup-plugin-commonjs is already there in the upstream rollup config:
https://salsa.debian.org/js-team/vue-router.js/blob/master/build/configs.js#L4

P.

Bug#930348: chromium: missing intrinsics on armhf

[Michael Gilbert]

package: src:chromium
severity: serious
version: 75.0.3770.80-1

The latest upload fails to build on armhf due to missing intrinsics [0].

Best wishes,
Mike

[0]https://buildd.debian.org/status/fetch.php?pkg=chromium=armhf=75.0.3770.80-1=1560141959=0

Bug#927996: RFS: diskfit/2.0.2.3 [ITP] -- Simple disk fit calculator

[Heiko Schäfer]

Good morning,

an updated package is available at

https://launchpad.net/~velnias/+archive/ubuntu/sandbox/+sourcefiles/diskfit/
2.0.2.13-1~eoan~ppa1/diskfit_2.0.2.13-1~eoan~ppa1.dsc

Am Dienstag, 11. Juni 2019, 00:41:15 CEST schrieb Adam Borowski:
> Hi!
> 
> On Wed, May 29, 2019 at 08:30:50AM +0200, Heiko Schäfer wrote:
> 
> You'll need to update that for the final upload, but during the review
> that's ok.
Of course I will do that as soon as I have a final place to upload it.

> debian/copyright needs an entry for install-sh which is under the MIT/X11
> license.
I hope I got the right license text.

> debians/source/options forces xz level 9 compression, which for this size of
> files is harmful (doesn't improve disk space, and requires a lot of memory
> on tiny machines).  Please just drop these settings -- they should be used
> only in special cases.
I've removed this file completely.

> debian/control: could you please fill in Homepage/Vcs-*, or at least drop
> the commented out fields?
done.

> The long desc really needs to be extended.  Even with trying to use the
> program, I had some trouble finding out what it is for.
To describe it is a big challenge for me. I hope is is a bit clearer now.

I'm aware it is a quite special tool, but my search for an existing one I 
could integrate in my daily workflow has been unsuccessful, so I decided to 
write one for myself.

Over 3 years being a lot of help, I decided to make it available to a broader 
audience by requesting it to get added to Debian.

> Also, a man page is vital for a command-line tool.
I added one for 'diskfit'. I did none for the GUI.

> Upstreamish side: I played with the GUI a bit, and it seems to handle
> selecting a dir badly (which, in my naive understanding, is what most
> people will try to do).  It does nothing until you click "Cancel", in
> which case it'll add one of previously (not currently) show directories.
> And then the program doesn't seem to do anything useful.  So, if dirs
> are not supported, the programs shouldn't at least try them.
First of all a *big* thank you for this extra testing!

At least in my version of Qt (5.12.3) it is - as wanted - not possible to just 
select a directory. I guess you mean the contents of an entire directory.

Due to the mathematical nature of combinatorics the larger the amount of files 
to process, the 'much' longer it takes. On my PC it takes around 7.5 h to 
process 38 files. Good for an overnight calculation :-)

The progress bar is updated discretely at 1 % steps, so - if you have a lot of 
input files - it can take a *long* time until you will see any progress.

This is unavoidable, because a non-discrete update (of the underlying) diskfit 
process would slow down everything up to an absolutely unacceptable amount of 
time. There is a second drawback, if you are patient and you're close to 50 % 
it can happen, that the remaining 50 % will run nearly as fast as light.

The progress calculation is divided into two parts:

1) the calculation of all combinations (lengthy)
2) preparing the output (*can* be lengthy, but hard to predict)

The goal of this tool is to approach the target size as exactly as possible 
and not to use heuristical algorithms and the most common use cases will do 
that in a reasonable time. Of course it is not meant to recursively create a 
set of optimally fitted DVDs for a huge collection of movies.

You could try out a similar example I use to generate the profile information 
while building:

- choose the file pattern '[cdmMR]*' from src/diskfit, no directories just 
files
- choose a custom target of 72240 bytes

This should give you two results and will run under one second.

If you have ideas how to communicate this behaviour to the user, I would be 
thankful.

> 
> Meow!

P.S. I love funeral doom too :-D

Bug#927254: [Pkg-javascript-devel] Bug#927254: possible solution

[Pirate Praveen]

On 2019, ജൂൺ 10 11:33:29 PM IST, Paolo Greppi  wrote:
>If I build manually the UMD version using the same command as in
>debian/rules:
>
>NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd.js
>
>I get this:
>
>/home/paolog/Sviluppo/debian/vue-router.js/src/index.js →
>dist/vue-router.js...
>(!) Unresolved dependencies
>https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
>path-to-regexp (imported by src/util/params.js,
>src/create-route-map.js)
>(!) Missing global variable name
>Use options.globals to specify browser global variable names
>corresponding to external modules
>path-to-regexp (guessing 'Regexp')
>created dist/vue-router.js in 761ms
>
>so it is not bundling path-to-regexp, assuming it is available to the
>browser as Regexp which clearly is not the case.
>
>Following the advice from the rollup and rollup-plugin-node-resolve
>docs, I modified the rollup config like this:
>
>diff --git a/build/configs.js b/build/configs.js
>index f81ec3a..378437b 100644
>--- a/build/configs.js
>+++ b/build/configs.js
>@@ -36,11 +36,19 @@ module.exports = [
>}
>  ].map(genConfig)
>  
>+const resolve1 = require('rollup-plugin-node-resolve')
>+
>  function genConfig (opts) {
>const config = {
>  input: {
>input: resolve('src/index.js'),
>plugins: [
>+  require('rollup-plugin-node-resolve')({
>+customResolveOptions: {
>+moduleDirectory: ['/usr/lib/nodejs'],
>+preferBuiltins: false
>+  }
>+}),
>  flow(),
>  node(),
>  cjs(),
>
>Now the same command bundles path-to-regexp, so that the differences
>between the file generated in dist/vue-router.js
>and the one from  wget
>https://unpkg.com/vue-router@3.0.2/dist/vue-router.js are much less
>(mainly the differences between path-to-regexp 1.7.0 bundled by
>upstream and 3.0.0 bundled by us).
>
>Tomorrow I'll test the generated file inside laminar. If that works
>this is an acceptable solution.
>The last bit is to move this config change to debian/rollup-umd.js so
>that it does not impact all builds..
>

I think rollup-plugin-commonjs will also work without extra options, see 
node-d3-fetch.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

forwarded 911844 https://bugs.kde.org/402015
thanks
-- 
Martin

Bug#930350: gnome-shell: Play/pause keyboard button stops controlling Rhythmbox/Totem

[Mike Crowe]

Package: gnome-shell
Version: 3.30.2-9
Severity: normal

I use Totem to listen to long media files and pause/resume them using the
Play/Pause button on my keyboard. After a while (sometimes a few hours,
sometimes a few days) this button stops working. Pressing it has no effect on
Totem, Rhythmbox or any other media-playing application running on my Gnome
desktop.

I continue to be able to play/pause from withing the user interface of the
application itself (well, provided I don't run into bug 926164.) I can also
play/pause from the Media player (MPRISv2) shell extension.

All other keys and keyboard shortcuts continue to work on my keyboard,
including the volume and calculator buttons.

Running xev shows no events being received when I press the button (but perhaps
that's normal, since the volume buttons also show no events.)

Rebooting my machine restores the functionality of the keyboard play/pause
button, until the next time it stops working.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-9
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2
ii  libglib2.0-bin   2.58.3-2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-5
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-7
ii  python3

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

severity: important
thanks

Hi Brian,

Brian Potkin - 10.06.19, 21:32:
> Severity: critical
> thanks
> 
> On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:
> > Package: okular
> > Version: 4:17.12.2-2
> > Severity: critical
> > Tags: upstream security
> > 
> > 
> > 
> > "critical" because a document should always go to where it is sent.
> > Please reduce the severity if I have overestimated the security
> > implications.
> > 
> > The CUPS version being used is 2.2.8-5 and cups-browsed is not
> > running. The issue was encountered while taking another look at
> > #911702.> 
[…]
> > The job is always sent to a local queue when its destination
> > precedes
> > realq_desktop alphabetically.
[…]
> I have retested this. There is no change on the present unstable. I
> cannot see why a confidential print job going to a staff printer is
> anything but a security issue. Maybe this is something that merits
> the tag of normal but explanations are in short supply.

Brian, before raising a bug severity to the highest severity possible, 
please read and understand the Debian's release team guidelines 
regarding release critical bugs¹ as well as the general descriptions of 
bug severities².

A "critical" bug is a bug that introduces a (remotely exploitable) 
security hole on systems you install the package to. A "grave" bug is a 
bug that introduces a (remotely exploitable) security hole allowing 
access to the accounts of users using the package.

None of this is the case here.

If at all, the bug might be "serious" if in the maintainers opinion it 
would make the package unsuitable for release.

Now please respect the reduced bug severity. Raising the severity again 
won't get you any priority handling with an already understaffed Debian 
Qt/KDE team. This is a community of people who are mostly doing unpaid 
work.


Two ways to use your (and our) time in a more productive manner are:

1) Retest with Okular 18.04 from Debian experimental (in case you run 
buster/sid). Or start KDE Neon in a machine and try with the newest 
Okular available there.

2) Remind upstream in a friendly way to have a look at the issue. Once 
there is a patch upstream it is very likely it could be backported for 
buster. Maybe it would be an idea to raise the upstream bug to KDE's 
security team.


[1] https://release.debian.org/testing/rc_policy.txt

[2] https://www.debian.org/Bugs/Developer

Thanks,
-- 
Martin

Bug#929078: fixed in ibus-sunpinyin 2.0.3+git20181120-2

[Gedalya]

Hi,

With ibus-sunpinyin 2.0.3+git20181120-2, I get the following:

$ /usr/lib/ibus/ibus-setup-sunpinyin

(main.py:2830): IBUS-WARNING **: 14:03:58.069: 
org.freedesktop.IBus.Config.GetValue: 
GDBus.Error:org.freedesktop.DBus.Error.Failed: Config value 
[engine/SunPinyin/General:MemoryPower] does not exist.
Traceback (most recent call last):
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 156, in __set_value
    self.widget.set_value(self.unwrap(v))
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 102, in unwrap
    return self.unwrappers[type(self.default)](v)
TypeError: argument self: Expected GLib.Variant, but got int

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 635, in 
    MainWindow().run()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 496, in run
    self.__read_config()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 569, in __read_config
    opt.init_ui()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 124, in init_ui
    self.read_config()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 133, in read_config
    self.__set_value(self.v)
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 158, in __set_value
    self.widget.set_active(self.unwrap(v))
AttributeError: 'HScale' object has no attribute 'set_active'


Thanks,

Gedalya

Bug#930134: [PKG-Openstack-devel] Bug#930134: Please package new upstream version

[Thomas Goirand]

On 6/10/19 9:59 PM, Jonas Meurer wrote:
> Mh, but the version in Debian is 1.0.0, so that doesn't work for current
> OpenStack version either, right? Mailman3 would be fine with any version
> newer than 1.0.0, so 1.4.1 would be sufficient.
> 
> Cheers
>  jonas

As much as I know, 1.0.0 to 1.4.1 is fine for OpenStack Stein (currently
in Experimental). Let's see if I can upgrade to 1.4.1 then.

Cheers,

Thomas Goirand (zigo)

Bug#930322: French Translation : at least one text string is not translated

[gilles . charabot]

Of course, I would like to point out that, although I have translated 
everything, I confirm that we can see "Paramètres" -> "Réseau" -> "Filaire" -> 
"Identité" in the network-manager-gnome graphic application. In addition, with 
the result of the following command line I think other languages are affected 
by the bug. 


find / -xdev -type f -print0 | xargs -0 grep -H "Wired connection" 
Fichier binaire /usr/share/locale/ca/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/fr/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/eo/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/as/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/ru/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/tr/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/hi/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/gl/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/kn/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/cs/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/ja/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/zh_CN/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/te/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/lt/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/es/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/it/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/ta/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/uk/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/pa/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/mr/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/ko/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/or/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/sv/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/el/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/bn_IN/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/ml/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/pl/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/zh_TW/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/pt_BR/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/hu/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/sl/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/en_GB/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/de/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/gu/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/share/locale/id/LC_MESSAGES/NetworkManager.mo 
correspondant 
Fichier binaire /usr/sbin/NetworkManager correspondant 

Bug#930349: undertow: CVE-2019-3888: leak credentials to log files UndertowLogger.REQUEST_LOGGER.undertowRequestFailed

[Salvatore Bonaccorso]

Source: undertow
Version: 1.4.25-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/undertow-io/undertow/pull/736

Hi,

The following vulnerability was published for undertow.

CVE-2019-3888[0]:
leak credentials to log files 
UndertowLogger.REQUEST_LOGGER.undertowRequestFailed

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-3888
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3888
[1] https://github.com/undertow-io/undertow/pull/736

Regards,
Salvatore

Bug#926032: [chromium] Buggy / Solarized videos

[Vincent Bernat]

Package: chromium
Version: 75.0.3770.80-1
Followup-For: Bug #926032

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I am also hit by this bug and it's still present in 75. It seems to be known 
upstream:

 https://bugs.freedesktop.org/show_bug.cgi?id=109548
 https://bugs.freedesktop.org/show_bug.cgi?id=106490

I have tried the workaround of putting this in /etc/drirc, without much success:


  

  

  


Arch does that too:

 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/chromium-drirc-disable-10bpc-color-configs.conf?h=packages/chromium=2323668d0369f38f9319d88b70d9409b0ca5abb1
 
I have tried to put the file in /usr/share/drirc.d/10-chromium.conf,
like they do, no success either. It's hard to know if this setting is
really used.

I have:

 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Baffin [Radeon RX 550 640SP / RX 560/560X] (rev ff)

- -- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  75.0.3770.80-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-7
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.3-1
ii  libavformat587:4.1.3-1
ii  libavutil56  7:4.1.3-1
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3~rc1-1
ii  libdbus-1-3  1.12.14-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-7
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-1
ii  libnss3  2:3.44+really3.42.1-2
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-5
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4
ii  libre2-5 20190101+dfsg-2+b1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-7
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  75.0.3770.80-1

Versions of packages chromium suggests:
ii  chromium-driver  75.0.3770.80-1
ii  chromium-l10n75.0.3770.80-1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 75.0.3770.80-1
ii  fonts-liberation 1:1.07.4-9
ii  libgl1-mesa-dri  18.3.6-2
ii  libu2f-udev  1.1.9-1
ii  notification-daemon  3.20.0-4
ii  upower   0.99.10-1

Versions of packages chromium-driver depends on:
ii  libatomic1   8.3.0-7
ii  libc62.28-10
ii  libdbus-1-3  1.12.14-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-7
ii  libglib2.0-0 2.58.3-2
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-1
ii  libnss3  2:3.44+really3.42.1-2
ii  libpng16-16  1.6.36-6
ii  libre2-5 20190101+dfsg-2+b1
ii  libstdc++6   8.3.0-7
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  

Bug#930134: Please package new upstream version

[Thomas Goirand]

On 6/10/19 9:59 PM, Jonas Meurer wrote:
> Hi Thomas,
> 
> Thomas Goirand:
>>> do you have plans to update the python-falcon packages to a newer
>>> upstream version (2.0.0 being the most recent one at the moment)
>>> anytime soon?
>>>
>>> python3-falcon is a dependency for mailman3 and starting with mailman3
>>> version 3.2.2, falcon > 1.0.0 is required. So I'll have to wait for the
>>> python-falcon update before being able to update mailman3 to latest
>>> upstream release.
>>
>> OpenStack Train (ie: the next version, due for early September) also
>> needs version 2.0.0, so I will package that. However, I don't see any
>> urgency during the Buster freeze.
> 
> Sounds reasonable to me. I agree that we're not in a rush and can easily
> wait until after the Buster release.
> 
>> Also, the current OpenStack version
>> needs 1.4.1, so uploading 2.0.0 to Experimental would break it.
> 
> Mh, but the version in Debian is 1.0.0, so that doesn't work for current
> OpenStack version either, right? Mailman3 would be fine with any version
> newer than 1.0.0, so 1.4.1 would be sufficient.
> 
> Cheers
>  jonas
> 
> 

Falcon 1.4.1 requires python3-mimeparse (>= 1.5.2), which isn't packaged
in Debian. Can you fill a bug against it so that it gets upgraded in
Experimental as well? Otherwise, I wont be able to do the work.

Cheers,

Thomas Goirand (zigo)

Bug#911844: okular: Prints to the wrong printer

[Brian Potkin]

On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:

> severity: important
> thanks
> 
> Hi Brian,
> 
> Brian Potkin - 10.06.19, 21:32:
> > Severity: critical
> > thanks
> > 
> > On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:
> > > Package: okular
> > > Version: 4:17.12.2-2
> > > Severity: critical
> > > Tags: upstream security
> > > 
> > > 
> > > 
> > > "critical" because a document should always go to where it is sent.
> > > Please reduce the severity if I have overestimated the security
> > > implications.
> > > 
> > > The CUPS version being used is 2.2.8-5 and cups-browsed is not
> > > running. The issue was encountered while taking another look at
> > > #911702.> 
> […]
> > > The job is always sent to a local queue when its destination
> > > precedes
> > > realq_desktop alphabetically.
> […]
> > I have retested this. There is no change on the present unstable. I
> > cannot see why a confidential print job going to a staff printer is
> > anything but a security issue. Maybe this is something that merits
> > the tag of normal but explanations are in short supply.
> 
> Brian, before raising a bug severity to the highest severity possible, 
> please read and understand the Debian's release team guidelines 
> regarding release critical bugs¹ as well as the general descriptions of 
> bug severities².
> 
> A "critical" bug is a bug that introduces a (remotely exploitable) 
> security hole on systems you install the package to. A "grave" bug is a 
> bug that introduces a (remotely exploitable) security hole allowing 
> access to the accounts of users using the package.

Thank you, Martin, for taking the time and trouble to explain. I admit
to feeling uneasy about raising the severity level and did give it some
thought - but obviously not enough. Anyway, something it's for me to
take into account for the future.

> None of this is the case here.
> 
> If at all, the bug might be "serious" if in the maintainers opinion it 
> would make the package unsuitable for release.
> 
> Now please respect the reduced bug severity. Raising the severity again 
> won't get you any priority handling with an already understaffed Debian 
> Qt/KDE team. This is a community of people who are mostly doing unpaid 
> work.
 
I have no intention of touching the severity level again.

> Two ways to use your (and our) time in a more productive manner are:
> 
> 1) Retest with Okular 18.04 from Debian experimental (in case you run 
> buster/sid). Or start KDE Neon in a machine and try with the newest 
> Okular available there.

There might be time for me to do both of these today or tomorrow.
 
> 2) Remind upstream in a friendly way to have a look at the issue. Once 
> there is a patch upstream it is very likely it could be backported for 
> buster. Maybe it would be an idea to raise the upstream bug to KDE's 
> security team.

You seem to have done that. Thanks.

Regards,

Brian.

Bug#929830: syslog shows netlink error

[Vincent Bernat]

 ❦ 11 juin 2019 11:36 +02, michael-dev :

> the problem occured on multiple machines. Directly after restart,
> lldpd memory usage seems fine, but eventually memory usage starts
> exploding again.
> The started happening within weeks after upgrading to stretch. All
> machines were restartet after upgrading to stretch.

Is there anything special on your setup? Lots of interface running or
interfaces cycling (VM)?
-- 
My only love sprung from my only hate!
Too early seen unknown, and known too late!
-- William Shakespeare, "Romeo and Juliet"


signature.asc
Description: PGP signature

Bug#924155: icewm-common: broken-symlink /usr/share/doc/icewm-common/FAQ/index.html -> IceWM-FAQ.html

[Thorsten Glaser]

Package: icewm-common
Version: 1.5.5+git20190610-1
Followup-For: Bug #924155

This bug is still pertinent, as reported by adequate.

(Also, why do you upload a new upstream version to sid
during deep freeze?)

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 icewm-common depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-7
ii  libglib2.0-02.58.3-2
ii  libstdc++6  8.3.0-7
ii  sensible-utils  0.0.12

Versions of packages icewm-common recommends:
ii  menu  2.1.47
pn  xscreensaver  
ii  xterm 344-1

icewm-common suggests no packages.

-- no debconf information

Bug#730572: reprepro: support for ddebs (debug symbols)

[Simon McVittie]

On Sun, 20 Dec 2015 at 08:53:16 +, Niels Thykier wrote:
> In the actual implementation we got live now, there are a couple of
> changes though.
> 
>  * The dbgsym packages use the .deb extension

For the non-Debian projects for which I developed this patch, we still
need at least basic support for .ddeb files, because Ubuntu's toolchain
still produces those (and as far as I can tell it will continue to do
so indefinitely - they no longer use pkg-create-dbgsym, but they have a
patch in their dh_strip to make it produce .ddeb instead of .deb files).

I wouldn't object to simplifying it by treating .ddeb files as exactly
equivalent to .deb, so they go alongside ordinary debs, instead of
creating a /debug pseudo-component? That's what happens right
now when you import a Debian-built -dbgsym package into an unpatched
reprepro. (You can't currently import an Ubuntu-built -dbgsym package
at all.)

(Cc'ing my colleague Lucas Kanashiro who will be looking into rebasing
this patch for our own use - we need a fork of reprepro that supports
this, even if it can't go upstream, so we might as well provide an
updated patch on this bug too.)

> In DAK / the Debian infrastructure, the dbgsym packages are placed in a
> separate component called "-debug".

Isn't that a suite or a "dist" or something, rather than a component?
The production Debian dbgsym infrastructure seems to have the same
three components (aka archive areas) as the main Debian archive, namely
main, contrib and non-free.

I don't think reprepro can or should mimic dak's output accurately,
because dak creates a separate lookaside apt repository for detached
debug symbols, but the scope of reprepro is that it deals with a single
apt repository.

Because reprepro can already accept *-dbgsym_*.deb and will currently
list them alongside any other .deb, moving Debian-built (.deb) -dbgsym
packages into a separate suite, component or repository would arguably
be an incompatible behaviour change.

smcv

Bug#930343: libgcr410 FTCBFS: uses the wrong compiler

[Peter 'p2' De Schrijver]

Go ahead.

Peter.

On 2019-06-11 06:13:16 (+0200), Helmut Grohne  wrote:
> Source: libgcr410
> Version: 2.4.0-9.2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> libgcr410 fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes libgcr410 cross buildable. Please consider applying the attached
> patch.
> 
> Helmut

> diff -u libgcr410-2.4.0/debian/changelog libgcr410-2.4.0/debian/changelog
> --- libgcr410-2.4.0/debian/changelog
> +++ libgcr410-2.4.0/debian/changelog
> @@ -1,3 +1,10 @@
> +libgcr410 (2.4.0-9.3) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
> +
> + -- Helmut Grohne   Tue, 11 Jun 2019 06:10:48 +0200
> +
>  libgcr410 (2.4.0-9.2) unstable; urgency=low
>  
>* Non-maintainer upload.
> diff -u libgcr410-2.4.0/debian/rules libgcr410-2.4.0/debian/rules
> --- libgcr410-2.4.0/debian/rules
> +++ libgcr410-2.4.0/debian/rules
> @@ -3,7 +3,7 @@
>  build: build-stamp
>  build-stamp: 
>   dh_testdir
> - $(MAKE)
> + dh_auto_build
>   touch build-stamp
>  
>  clean:

Bug#930361: exim4: Further on to CVE-2019-10149

[Brent Clark]

Package: exim4
Version: 4.89-2+deb9u4
Severity: important

Dear Maintainer,

This is just a FYI and I sure hope its nothing.

In light of CVE-2019-10149

What I did was build a vagrant instance with Exim 4.89-2+deb9u3 to
replicate the POC.

Please see https://pastebin.com/raw/EiLbpsH4 for successful
exploitation.

What was of interest to me, I upgraded to 4.89-2+deb9u4 and redid the POC.

Please see https://pastebin.com/raw/iqaJyHt2, but you will see is, the
file POC does not work, BUT mail still gets accepted.

Please see https://pastebin.com/raw/YLS7CBHY

I just want to double check is this is correct / acceptable.

Kind Regards
Brent Clark
P.s. Just a Q of food for thought, should not CHECK_RCPT_LOCAL_LOCALPARTS and / 
or
CHECK_RCPT_REMOTE_LOCALPARTS be updated in
/etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs?

-- Package-specific info:
Exim version 4.89 #2 built 28-May-2019 20:13:55
Copyright (c) University of Cambridge, 1995 - 2017
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC Event 
OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='local'
dc_other_hostnames='REMOVED
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains='stephan.trial.co.za'
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:stephan.trial.co.za
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 25:587:10025 -oP /run/exim4/exim.pid
SMTPLISTENEROPTIONS=''

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  exim4-base 4.89-2+deb9u4
ii  exim4-daemon-light 4.89-2+deb9u4

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
  exim4/drec:

Bug#930354: curl: Verbose output contains accidental debug messages

[Sebastian Krause]

Package: curl
Version: 7.64.0-3
Severity: normal
Tags: patch

Dear Maintainer,

Executing curl with verbose output (-v) contains a lot of debug messages
like these:

* Expire in 0 ms for 6 (transfer 0x56013e137dd0)
* Expire in 1 ms for 1 (transfer 0x56013e137dd0)
* Expire in 0 ms for 1 (transfer 0x56013e137dd0)

This was added upstream only by accident 
(https://curl.haxx.se/mail/archive-2019-02/0013.html)
and has already been fixed there: https://github.com/curl/curl/pull/3558

The following upstream patch fixes the problem:
https://github.com/curl/curl/commit/63b9d14da0952b7fdbf94a78937a4d2bd63bf815.patch

It would be nice if the stable package in the next Debian release didn't include
this debug output.

Sebastian Krause

Bug#930350: Reboot not required to fix

[Mike Crowe]

It appears that normal behaviour of the play/pause button returns if I log
out and log back in again. A full reboot is not required.

Mike.

Bug#930361: More to add

[Brent Clark]

Sorry, just to add, I used the following link to test.

https://www.openwall.com/lists/oss-security/2019/06/06/1

Please read points 3 and 4 under section 'Default configuration'

HTH

Regards

Brent Clark

Bug#930356: CVE-2019-12760

[Moritz Muehlenhoff]

Source: parso
Severity: grave
Tags: security

Please see https://bugzilla.redhat.com/show_bug.cgi?id=1718212

Patch is at https://gist.github.com/dhondta/f71ae7e5c4234f8edfd2f12503a5dcc7

Cheers,
Moritz

Bug#775029: Processed: reassign 775029 to src:trac

[W. Martin Borgert]

I assume, that the bug is not present in Debian >= 8, i.e. Trac >= 1.
It has been fixed upstream seven years ago.
If the bug is still present in Debian 10, please reopen.

Bug#924961: [Mailman-Developers] Re: How strict are the dependencies on the django-compressor related backends?

[Christian Ehrhardt]

[...]

> I think this is perfectly fine and I don't see much benefit in combining
> the CSS and JS files at build-time. It would allow to drop the
> django-compressor dependency but with the cost of more heavy build-time
> adjustments that need to be maintained in future.

I agree, the extra gain by this would be minimal at a rather high
maintenance cost.

>
> So I'm happy to now have a solution to drop both node-less and sassc
> from runtime dependencies in the Debian package. Thanks to everyone for
> their input on this topic.

Thank you so much!

I think that also eases the maintenance of a live mailman deployment having
much less complex components installed.

I understand that this won't be for Buster.
Just curious for related Ubuntu planning - are you planning to do an
upload to experimental ahead of time or are you waiting until Buster
is released?

> I added a comment to upstream hyperkitty issue #120 where I proposed to
> do the same in the upstream hyperkitty release process and that way get
> rid of the sassc runtime dependency:
>
> https://gitlab.com/mailman/hyperkitty/issues/120#note_179256370

Great, that will help to keep things in sync.

Bug#930352: RFS: easy-rsa 3.0.6-2

[Michele Orru]

Package: easy-rsa
Version: 3.0.6-1
Severity: normal




Dear mentors,

I am looking for a sponsor for my package easy-rsa:

* Package name: easy-rsa
  Version : 3.0.6-1
  Upstream Author : the Open-Source OpenVPN development community
* URL : https://github.com/OpenVPN/easy-rsa/
* License : GPLv2


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


   https://salsa.debian.org/debian/easy-rsa/

Changes since the last upload:

*  Fix program name in synopsis for "make-cadir" (Closes: #929634).

--
μ.

Bug#930355: ftp.debian.org: add lintian autoreject: invalid-versioned-provides

[Andreas Beckmann]

Package: ftp.debian.org
Severity: important

Hi,

to prevent bugs like #930256 (versioned provides with non-equal
DepCompareOp) from happening again, please add
invalid-versioned-provides to the list of autorejects.


Andreas

Bug#908868: RFH: docker.io // Would like to maintain Docker.io package

[Arnaud Rebillout]

On 6/11/19 9:25 AM, Dmitry Smirnov wrote:
> On Monday, 10 June 2019 3:03:23 PM AEST Arnaud Rebillout wrote:
>> I also want to try to unbundle
>> containerd from the docker package,
> This may be very risky to do so one have to have a good justification what 
> those risks are taken for.
>
> It has been attempted in the past with disastrous results. Containerd is used 
> by Docker (exclusively?) and with very specific vendoring. With current 
> upstream culture of incompetence in regards to versioning, another attempt to 
> ship containerd separately is likely to fail. Unbundling containerd should be 
> considered very very carefully with full understanding of why burning effort 
> for the attempt.
>
AFAIU there's two issues:

1. the fact that docker uses snaphots of containerd.

2. the fact that both docker and containerd vendor each other, leading
to unbreakable circular dependencies.

For issue 1, I would have a the docker releases accross the last year,
and see what version of containerd they use. If it happens that they
consistently use releases of containerd rather than snapshots, then
maybe we can consider that issue 1 is gone (but it's true that they're
no warranty that they won't go back to using snapshots later down the
road)

For issue 2, I would try to have a look at what they vendor from docker,
once again over a one year time span, and try to assess it they're doing
any progress un-bundling docker parts from containerd, or not. I've seen
in Shengjing Zhu's containerd package that there is still some vendoring
of docker parts, so I don't think it's solved yet, but maybe it's on the
way.

Even if these two points are solved, it's true that there's a risk that
it comes back, even more both projects have more or less the same
upstream. I'm not really aware of who develop what, and if both projects
are really developed separately, or by the same group of people.

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Shengjing Zhu]

Hi,

I checked more carefully on https://github.com/moby/moby/pull/28257
and https://github.com/moby/moby/issues/14041
Then I concluded that docker does nothing wrong in this case.

If you didn't set net.ipv4.ip_forward=1 before starting docker, then
docker will set this for you by default, otherwise the containers
can't access the network. This causes security issue as described in
https://github.com/moby/moby/issues/14041.
So if docker set net.ipv4.ip_forward=1 itself, it will set the default
FORWARD policy to DROP. This looks quite correct.

So when docker will not touch your FORWARD policy? just don't let
docker enable ip_forward itself. You can set net.ipv4.ip_forward=1 in
/etc/sysctl.conf(enable it before starting docker). Then docker will
know that user want the host to forward all traffic and it will touch
your default FORWARD policy.

I've verified it by adding net.ipv4.ip_forward=1 to /etc/sysctl.conf,
then reboot. And my FORWARD policy is ACCEPT.

So as for your VM scenario, why didn't you set ip_forward manually?
How docker know it's not a vulnerability if it didn't set FORWARD
chain to DROP when it enables ip_forward.

-- 
Shengjing Zhu

Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)

[Norbert Lange]

I don't know how I initially got there, but I kept the old version's
.deb archived around when I first encountered the issue, and installed
them with dpkg -i afterwards.

And whether shim-signed is installed or not makes no difference, it
just affects the defaults grub is using. I always have to make sure
"--no-uefi-secure-boot" is used (which is implicitly set if
shim-signed is not installed AFAIK).

Am Mo., 10. Juni 2019 um 02:51 Uhr schrieb Steve McIntyre :
>
> Hi Norbert,
>
> On Sat, May 11, 2019 at 12:00:41PM +0200, Norbert Lange wrote:
> >I got newer versions to work by adding the "--no-uefi-secure-boot" switch,
> >so apparently uefi-secure-boot is not working for me.
> >
> >older versions might have defaulted to not using it,
> >or I did not have the shim packages installed.
>
> I'm curious how you got here. Did you install with Recommends
> disabled? There's a Recommends: chain from grub-efi-amd64-bin to
> grub-efi-amd64-signed to shim-signed which should cause shim-signed to
> be installed.
>
> Does installing shim-signed fix your problem?
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> You raise the blade, you make the change... You re-arrange me 'til I'm sane...
>

Bug#930357: stretch-pu: package miniupnpd/1.8.20140523-4.1+deb9u2 CVE-2019-12107, CVE-2019-12108, CVE-2019-12109, CVE-2019-12110

[Thomas Goirand]

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

Dear release team,

Please allow me to upload miniupnpd/1.8.20140523-4.1+deb9u2, as the
security team told me the CVE in the Subject do not need a DSA.

The upload only adds the upstream patches, Stretch doesn't seem to
be affected by CVE-2019-12111. On top of that, the fixed version adds
a change to debian/gbp.conf (only branch names), please allow this to
get in as well, as this simplifies the packaging update tasks.

Debdiff attached, pre-built packages available from here:
http://sid.gplhost.com/stretch-proposed-updates/miniupnpd/

Cheers,

Thomas Goirand (zigo)
diff -Nru miniupnpd-1.8.20140523/debian/changelog 
miniupnpd-1.8.20140523/debian/changelog
--- miniupnpd-1.8.20140523/debian/changelog 2018-02-07 12:18:50.0 
+0100
+++ miniupnpd-1.8.20140523/debian/changelog 2019-06-07 09:16:03.0 
+0200
@@ -1,3 +1,11 @@
+miniupnpd (1.8.20140523-4.1+deb9u2) stretch; urgency=medium
+
+  * Applied upstream patches for CVE-2019-12107, CVE-2019-12108,
+CVE-2019-12109, CVE-2019-12110. This version looks like not affected by
+CVE-2019-12111. (Closes: #930050).
+
+ -- Thomas Goirand   Fri, 07 Jun 2019 09:16:03 +0200
+
 miniupnpd (1.8.20140523-4.1+deb9u1) stretch; urgency=medium
 
   * Apply patch from upstream for CVE-2017-1000494 (Closes: #887129).
diff -Nru miniupnpd-1.8.20140523/debian/gbp.conf 
miniupnpd-1.8.20140523/debian/gbp.conf
--- miniupnpd-1.8.20140523/debian/gbp.conf  2014-12-09 15:37:29.0 
+0100
+++ miniupnpd-1.8.20140523/debian/gbp.conf  2019-06-07 09:16:03.0 
+0200
@@ -1,6 +1,6 @@
 [DEFAULT]
-upstream-branch = upstream-sid
-debian-branch = debian-sid
+upstream-branch = upstream-stretch
+debian-branch = debian-stretch
 pristine-tar = True
 
 [git-buildpackage]
diff -Nru 
miniupnpd-1.8.20140523/debian/patches/CVE-2019-12107_upnp_event_prepare_check_the_return_value_of_snprintf.patch
 
miniupnpd-1.8.20140523/debian/patches/CVE-2019-12107_upnp_event_prepare_check_the_return_value_of_snprintf.patch
--- 
miniupnpd-1.8.20140523/debian/patches/CVE-2019-12107_upnp_event_prepare_check_the_return_value_of_snprintf.patch
1970-01-01 01:00:00.0 +0100
+++ 
miniupnpd-1.8.20140523/debian/patches/CVE-2019-12107_upnp_event_prepare_check_the_return_value_of_snprintf.patch
2019-06-07 09:16:03.0 +0200
@@ -0,0 +1,57 @@
+Description: CVE-2019-12107: upnp_event_prepare(): check the return value of 
snprintf()
+Author: Thomas Bernard 
+Date: Tue, 18 Dec 2018 22:37:14 +0100
+Origin: upstream, 
https://github.com/miniupnp/miniupnp/commit/bec6ccec63cadc95655721bc0e1dd49dac759d94
+Last-Update: 2019-06-07
+Bug-Debian: https://bugs.debian.org/930050
+
+Index: miniupnpd/upnpevents.c
+===
+--- miniupnpd.orig/upnpevents.c
 miniupnpd/upnpevents.c
+@@ -383,19 +383,34 @@ static void upnp_event_prepare(struct up
+   l = 0;
+   }
+   obj->buffersize = 1024;
+-  obj->buffer = malloc(obj->buffersize);
+-  if(!obj->buffer) {
+-  syslog(LOG_ERR, "%s: malloc returned NULL", 
"upnp_event_prepare");
+-  if(xml) {
+-  free(xml);
++  for (;;) {
++  obj->buffer = malloc(obj->buffersize);
++  if(!obj->buffer) {
++  syslog(LOG_ERR, "%s: malloc returned NULL", 
"upnp_event_prepare");
++  if(xml) {
++  free(xml);
++  }
++  obj->state = EError;
++  return;
+   }
+-  obj->state = EError;
+-  return;
++  obj->tosend = snprintf(obj->buffer, obj->buffersize, notifymsg,
++ obj->path, obj->addrstr, obj->portstr, 
l+2,
++ obj->sub->uuid, obj->sub->seq,
++ l, xml);
++  if (obj->tosend < 0) {
++  syslog(LOG_ERR, "%s: snprintf() failed", 
"upnp_event_prepare");
++  if(xml) {
++  free(xml);
++  }
++  obj->state = EError;
++  return;
++  } else if (obj->tosend < obj->buffersize) {
++  break; /* the buffer was large enough */
++  }
++  /* Try again with a buffer big enough */
++  free(obj->buffer);
++  obj->buffersize = obj->tosend + 1;  /* reserve space for 
the final 0 */
+   }
+-  obj->tosend = snprintf(obj->buffer, obj->buffersize, notifymsg,
+- obj->path, obj->addrstr, obj->portstr, l+2,
+- obj->sub->uuid, obj->sub->seq,
+- l, xml);
+   if(xml) {
+   free(xml);
+   xml = NULL;
diff -Nru 

Bug#930358: qmodbus: Qt-based ModBus master application

[Cédric]

Package: wnpp
Severity: wishlist

Package name: qmodbus
Version : 0.3.0
Upstream Author : Karl-Heinz Reichel 
URL : https://github.com/ed-chemnitz/qmodbus
License : GPL2+
Programming Lang: C++
Description : ModBus master GUI

QModBus is a free Qt-based implementation of a ModBus master application.
A graphical user interface allows easy communication with ModBus slaves over
serial line interface. QModBus also includes a bus monitor for sniffing all
traffic on the bus.

Bug#930359: xwayland: Sluggish performance with Intel 520

[tkoeck]

Package: xwayland
Version: 2:1.20.4-1
Severity: normal

Dear Maintainer,

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

I upgraded from Debian 9 to Debian 10. I am using a Thinkpad with a 

0:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)

graphics card.

Just wanted to inform you that the graphic performance for that CPU/GPU
is very bad. It needs twice as much CPU load as the X-server variant.
Just wanted to inform you. There could be a problem with the Wayland 
implementation with the Intel HD 520 right now.

I have switched back to the xserver and it works fine again.


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


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

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

Versions of packages xwayland depends on:
ii  libaudit1   1:2.8.4-3
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libdrm2 2.4.97-1
ii  libegl1 1.1.0-1
ii  libepoxy0   1.5.3-0.1
ii  libgbm1 18.3.6-2
ii  libgcrypt20 1.8.4-5
ii  libgl1  1.1.0-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libsystemd0 241-5
ii  libunwind8  1.2.1-9
ii  libwayland-client0  1.16.0-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.4-1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#930360: pelican warnings when building bits.d.o in Buster

[Laura Arjona Reina]

Package: press
Severity: normal
X-Debbugs-CC: debian-public...@lists.debian.org

Hi all

I've tried to build bits.debian.org in a machine with Debian Buster (currently 
testing, but it will be stable soon) and I get these pelican warnings:


WARNING: %s usage in TRANSLATION_FEED_ATOM is deprecated, use {lang} instead.
WARNING: %s usage in TRANSLATION_FEED_RSS is deprecated, use {lang} instead.

and a lot of these:

WARNING: {filename} used for linking to staticcontent images/name_of_image.ext 
in path/to/post/title.md. Use {static} instead


I guess we should adapt our code to Pelican version 4 (and change "filename" to 
"static" in the posts including images).


Kind regards

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

Bug#865975: #865975 docker.io breaks (bridged) network for VMs

[Jonathan Dowland]

severity 865975 critical
thanks

My report just got merged into this one as a duplicate, so sorry for being
late to the party…

On Tue, Nov 27, 2018 at 12:42:28PM +1100, Dmitry Smirnov wrote:

I'm lowering severity back to "important". You are not wrong that Docker is
hostile to other applications but I think many users would agree that we need
Docker in "testing" and upcoming Debian release despite of this problem.


With respect Dmitry, I don't think that this is an appropriate reason to lower
the severity.

I agree that we should ship Docker in Buster, even if we have not resolved this
issue in time, since we couldn't introduce it after the fact, and it's an
important and/or high-profile package.

But the bug clearly meets the criteria for Critical severity: "makes unrelated
software on the system (or the whole system) break": one can witness unrelated
VMs lose networking in real time by starting the docker daemon and triggering
the policy change.

The proper way to try and ensure that Docker does not get dropped from Buster
is to either fix the bug or request an exception from the release team (a
"buster-ignore" tag). Lowering the severity to avoid triggering a removal is 
just
hiding the bug from RC bug summaries and dashboards etc., violating SC §3 "We
will not hide problems".

I'm fairly confident that the release team would tag this buster-ignore. But,
the preferred solution is, of course, to fix the bug.

As Clint points out in [1], a solution is to ship a minimal conffile.
On the face of it that seems like a simple solution, which has not been 
discussed
by anyone else yet in the bug. I've tested the concept and it works, but needs
cooking up into a patch. What are the caveats for this? At a minimum we
would need a README.Debian too, I guess.


[1] <20180104025648.eycf37gbzkxe7...@scru.org>

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#930302: installing and starting docker changes iptables FORWARD policy, breaking unrelated things

[Jonathan Dowland]

On Mon, Jun 10, 2019 at 07:12:37PM +0800, Shengjing Zhu wrote:

I looked at the bug list of docker.io, found it's already reported at #865975


Thank you, I missed this when I looked myself.


docker did this intentionally, and also metioned this behaviour in its
chanelog(in src engine/CHANGELOG.md, not in /usr/share/doc)

* Change the default `FORWARD` policy to `DROP`
[#28257](https://github.com/docker/docker/pull/28257)

And please note that this change is since docker 1.13.0(2017-01-18).


All the above is interesting but seems entirely tangential to either
the discussion about severity or getting it fixed.


in #865975, people has already palyed with the bug severity, and I
don't think it's worth playing again this time.


Please feel free not to.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#929830: syslog shows netlink error

[michael-dev]

Hi,

the problem occured on multiple machines. Directly after restart, lldpd 
memory usage seems fine, but eventually memory usage starts exploding 
again.
The started happening within weeks after upgrading to stretch. All 
machines were restartet after upgrading to stretch.


Regards,
M. Braun

Bug#929931: [Pkg-samba-maint] Bug#929931: CTDB: Debian Enablement (focus: NFS HA)

[Mathieu Parent]

Hello Rafael,

Thanks for your work.

Have you sent all patches to upstream? Once this is done, please
propose a MR at:
https://salsa.debian.org/samba-team/samba

(with cherry-picked commits, with "-x")

Those may go in Debian 10 buster.

Thanks again

Mathieu Parent

Bug#929521: Conflicts in upgrade to 418.74-1 with optimus setup

[Luca Boccassi]

On Tue, 2019-06-11 at 00:21 +0200, Andreas Beckmann wrote:
> On 07/06/2019 18.12, Luca Boccassi wrote:
> > Hi, this should be the list:
> > 
> > bbswitch bumblebee bumblebee-nvidia primus primus-libs primus-libs-
> > ia32 
> > nvidia-driver-libs-nonglvnd nvidia-driver-libs-nonglvnd-i386
> 
> Is this documented somewhere?
> 
> This can be minimized to
>   apt-get install --install-recommends \
> nvidia-driver-libs-nonglvnd bumblebee-nvidia primus
> if i386 is available as a foreign architecture.
> 
> That makes me think: should we have a primus-nvidia metapackage that
> depends on these packages?
> 
> Which component in this stack did not work with libgl1-nvidia-glvnd-
> glx?
> According to the existing Breaks this should be primus ...
> 
> Running
>   apt-get install --install-recommends bumblebee-nvidia primus
> in a minimal *stretch* chroot results in the installation of
>   nvidia-driver nvidia-driver-libs libgl1-glvnd-nvidia-glx ...
> which does not give a working setup?
> 
> Running
>   apt-get install --install-recommends bumblebee-nvidia primus
> in a minimal *buster* chroot results in the installation of
> nvidia-kernel-dkms, but no driver or library components, which does
> not
> sound useful either.
> 
> I'll send some piuparts logs to this bug later, dropping all Cc:s.
> Testing stretch->buster upgrades with
> * foreign arch i386 enabled and
> * --install-recommends enabled
> of the package set nvidia-driver-libs-nonglvnd bumblebee-nvidia
> primus
> did not show problems. It pulled in some legacy-390xx packages, but
> not
> the 390xx driver itself. It will be hard to reproduce the problem
> people
> exerienced with some transient set of packages from testing
> installed.
> 
> We will probably have to review the Depends/Recommends/Suggests in
> the
> bumblebee and primus packages ... to better cope with the driver:i386
> removal.
> 
> 
> Andreas

In theory, "apt install bumblebee-nvidia" should do the right thing.
The problem is that we can't depend directly from primus-libs to
nvidia-driver-libs-nonglvnd as the former is in main and the latter in
non-free, so at the moment we try to "nudge" apt with breaks and
suggests:

Breaks:
 libgl1-nvidia-glvnd-glx (>= 0),
 nvidia-driver-libs (>= 0),
 libgl1-nvidia-legacy-390xx-glvnd-glx (>= 0),
 nvidia-legacy-390xx-driver-libs (>= 0),
Suggests:
 nvidia-driver-libs-nonglvnd | nvidia-legacy-390xx-driver-libs-nonglvnd

This obviously doesn't seem to work reliably all the time...

Originally the point of bumblebee and primus in main was that they were
needed for the noveau stack as well. But nowadays as far as I know
DRI_PRIME is the better choice for noveau, for recent hardware. I
wonder if we should simply move primus and bumblebee to non-free so
that we can have a working set of dependencies?

But also note that upstream is going to deprecate non-glvnd after 430,
so optimus users will be stuck with whatever legacy release we cut
before that:

https://devtalk.nvidia.com/default/topic/1032650/linux/unix-graphics-feature-deprecation-schedule/

-- 
Kind regards,
Luca Boccassi


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

Bug#930363: faad2: fix build with gcc-9 [patch]

[Gianfranco Costamagna]

Source: faad2
Version: 2.8.8-3
Severity: normal
tags: patch

Hello, looks like gcc-9 is adding wl,asneeded flag in compilation, so libs 
passed as CFLAGS are not correctly
used by gcc anymore, because only LIBS is added at the end of the compilation 
line.

The following patch fixes the issue, and starts then using again the glib 
implementation of the library.
(without the patch, the bundled version is used everywhere, and the build fails 
only on i386 because of an implementation mismatch of a long/int data type)

I reported the patch already upstream
https://sourceforge.net/p/faac/bugs/242/


patch: 
http://launchpadlibrarian.net/427773869/faad2_2.8.8-3_2.8.8-3ubuntu1.diff.gz


please apply if possible, thanks!

Gianfranco
>From b9e6b9bf906c8c2c6fabf7255bcf9eceff96023b Mon Sep 17 00:00:00 2001
From: Gianfranco Costamagna 
Date: Tue, 11 Jun 2019 14:54:38 +0200
Subject: [PATCH] Add patch to fix a gcc-9 build failure on i386 and to
 correctly use lprintf from glibc

---
 debian/changelog   |  6 ++
 debian/patches/gcc-9.patch | 26 ++
 debian/patches/series  |  1 +
 3 files changed, 33 insertions(+)
 create mode 100644 debian/patches/gcc-9.patch

diff --git a/debian/changelog b/debian/changelog
index dfa8217..c1267f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+faad2 (2.8.8-4) UNRELEASED; urgency=medium
+
+  * Fix build with gcc-9 and asneeded flag on i386.
+
+ -- Gianfranco Costamagna   Tue, 11 Jun 2019 14:41:09 +0200
+
 faad2 (2.8.8-3) unstable; urgency=high
 
   * Team upload.
diff --git a/debian/patches/gcc-9.patch b/debian/patches/gcc-9.patch
new file mode 100644
index 000..e17a3a3
--- /dev/null
+++ b/debian/patches/gcc-9.patch
@@ -0,0 +1,26 @@
+Description: Fix link failure with gcc-9 and wl,asneeded flags
+Author: Gianfranco Costamagna 
+Last-Update: 2019-06-11
+
+--- faad2-2.8.8.orig/configure.ac
 faad2-2.8.8/configure.ac
+@@ -91,8 +91,8 @@ AC_DEFUN([AC_C99_FUNC_LRINTF],
+ [AC_CACHE_CHECK(for lrintf,
+   ac_cv_c99_lrintf,
+ [
+-lrintf_save_CFLAGS=$CFLAGS
+-CFLAGS="-O -lm"
++lrintf_save_LIBS=$LIBS
++LIBS="-O -lm"
+ AC_TRY_LINK([
+ #define _ISOC9X_SOURCE  1
+ #define _ISOC99_SOURCE  1
+@@ -102,7 +102,7 @@ AC_TRY_LINK([
+ #include 
+ ], if (!lrintf(3.14159)) lrintf(2.7183);, ac_cv_c99_lrintf=yes, ac_cv_c99_lrintf=no)
+ 
+-CFLAGS=$lrintf_save_CFLAGS
++LIBS=$lrintf_save_LIBS
+ 
+ ])
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 6d4062f..f35c884 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ reproducible-build.patch
 0009-syntax.c-check-for-syntax-element-inconsistencies.patch
 0010-sbr_hfadj-sanitize-frequency-band-borders.patch
 0004-Fix-a-couple-buffer-overflows.patch
+gcc-9.patch
-- 
2.17.1

Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

[Nicolas Quiniou-Briand]

Package: cloud.debian.org
Severity: normal

Dear Maintainer,

I noticed a difference between providers for the same box 
(debian/stretch64):


* with libvirt provider, `systemd-networkd` service is enabled and started
after first boot of VM.

* with virtualbox provider, `systemd-networkd`
service is disabled and stopped after first boot of VM.

It will be better to have only one way to manage network for the same 
image with different providers.

Bug#930371: unblock: dbus/1.12.16-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: d-i
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dbus to fix CVE-2019-12749. I forgot to set high
urgency, so you might want to adjust its age-days too.

Filtered and full diffs are attached (the former has Autotools noise
removed). As usual, I'm happy to revert anything that -release can't
accept, because the whole 1.12.x branch exists for the benefit of
distros with a bugfix-only policy (but having said that, everything
in this particular version is either CVE-2019-12749, tests for it,
or release preparation).

dbus builds udebs, so this will need an ack from debian-boot (although
from comments on #929132 it isn't clear to me whether the udebs are
actually used for anything).

unblock dbus/1.12.16-1

Breakdown of the diff:

> diffstat for dbus-1.12.14 dbus-1.12.16
>
>  dbus/dbus-auth.c|   32 

CVE-2019-12749

>  dbus/dbus-auth-script.c |   87 
> +++-
>  dbus/dbus-sysdeps-util-unix.c   |   40 +++
>  dbus/dbus-sysdeps-util-win.c|   25 ++
>  dbus/dbus-sysdeps.h |   10 ++
>  test/Makefile.am|2 
>  test/data/auth/cookie-sha1-username.auth-script |   12 +++
>  test/data/auth/cookie-sha1.auth-script  |   11 +++

Regression tests for CVE-2019-12749 (these are #ifdef'd out and do
not affect the dbus binary package, although they do end up in the
special debug build in the dbus-tests package)

>  NEWS|   18 
>  configure.ac|4 -
>  debian/changelog|   15 

Release preparation

>  Makefile.in |4 -
>  aminclude_static.am |2 
>  bus/Makefile.in |2 
>  configure   |   26 +++
>  dbus/Makefile.in|2 
>  test/Makefile.in|4 -

Autotools noise from doing the release

Thanks,
smcv
filterdiff -p1 -xMakefile.in -x'*/Makefile.in' -xaminclude_static.am -xconfigure < dbus_1.12.16-1.diff > dbus_1.12.16-1-filtered.diff

diffstat for dbus-1.12.14 dbus-1.12.16

 Makefile.in |4 -
 NEWS|   18 
 aminclude_static.am |2 
 bus/Makefile.in |2 
 configure   |   26 +++
 configure.ac|4 -
 dbus/Makefile.in|2 
 dbus/dbus-auth-script.c |   87 +++-
 dbus/dbus-auth.c|   32 
 dbus/dbus-sysdeps-util-unix.c   |   40 +++
 dbus/dbus-sysdeps-util-win.c|   25 ++
 dbus/dbus-sysdeps.h |   10 ++
 debian/changelog|   15 
 test/Makefile.am|2 
 test/Makefile.in|4 -
 test/data/auth/cookie-sha1-username.auth-script |   12 +++
 test/data/auth/cookie-sha1.auth-script  |   11 +++
 17 files changed, 272 insertions(+), 24 deletions(-)

diff -Nru dbus-1.12.14/configure.ac dbus-1.12.16/configure.ac
--- dbus-1.12.14/configure.ac	2019-05-17 10:38:45.0 +0100
+++ dbus-1.12.16/configure.ac	2019-06-09 13:09:13.0 +0100
@@ -3,7 +3,7 @@
 
 m4_define([dbus_major_version], [1])
 m4_define([dbus_minor_version], [12])
-m4_define([dbus_micro_version], [14])
+m4_define([dbus_micro_version], [16])
 m4_define([dbus_version],
   [dbus_major_version.dbus_minor_version.dbus_micro_version])
 AC_INIT([dbus],[dbus_version],[https://bugs.freedesktop.org/enter_bug.cgi?product=dbus],[dbus])
@@ -42,7 +42,7 @@
 
 ## increment any time the source changes; set to
 ##  0 if you increment CURRENT
-LT_REVISION=10
+LT_REVISION=11
 
 ## increment if any interfaces have been added; set to 0
 ## if any interfaces have been changed or removed. removal has
diff -Nru dbus-1.12.14/dbus/dbus-auth.c dbus-1.12.16/dbus/dbus-auth.c
--- dbus-1.12.14/dbus/dbus-auth.c	2017-10-30 12:26:18.0 +
+++ dbus-1.12.16/dbus/dbus-auth.c	2019-06-09 13:08:12.0 +0100
@@ -529,6 +529,7 @@
   DBusString tmp2;
   dbus_bool_t retval = FALSE;
   DBusError error = DBUS_ERROR_INIT;
+  DBusCredentials *myself = NULL;
 
   _dbus_string_set_length (>challenge, 0);
   
@@ -565,6 +566,34 @@
   return FALSE;
 }
 
+  myself = _dbus_credentials_new_from_current_process ();
+
+  if (myself == NULL)
+goto out;
+
+  if (!_dbus_credentials_same_user (myself, auth->desired_identity))
+{
+  /*
+   * DBUS_COOKIE_SHA1 

Bug#930363: faad2: fix build with gcc-9 [patch]

[Sebastian Ramacher]

Control: tags -1 + moreinfo

On 2019-06-11 15:06:01, Gianfranco Costamagna wrote:
> Source: faad2
> Version: 2.8.8-3
> Severity: normal
> tags: patch
> 
> Hello, looks like gcc-9 is adding wl,asneeded flag in compilation, so libs 
> passed as CFLAGS are not correctly
> used by gcc anymore, because only LIBS is added at the end of the compilation 
> line.
> 
> The following patch fixes the issue, and starts then using again the glib 
> implementation of the library.
> (without the patch, the bundled version is used everywhere, and the build 
> fails only on i386 because of an implementation mismatch of a long/int data 
> type)
> 
> I reported the patch already upstream
> https://sourceforge.net/p/faac/bugs/242/
> 
> 
> patch: 
> http://launchpadlibrarian.net/427773869/faad2_2.8.8-3_2.8.8-3ubuntu1.diff.gz
> 
> 
> please apply if possible, thanks!
> 
> Gianfranco

> >From b9e6b9bf906c8c2c6fabf7255bcf9eceff96023b Mon Sep 17 00:00:00 2001
> From: Gianfranco Costamagna 
> Date: Tue, 11 Jun 2019 14:54:38 +0200
> Subject: [PATCH] Add patch to fix a gcc-9 build failure on i386 and to
>  correctly use lprintf from glibc
> 
> ---
>  debian/changelog   |  6 ++
>  debian/patches/gcc-9.patch | 26 ++
>  debian/patches/series  |  1 +
>  3 files changed, 33 insertions(+)
>  create mode 100644 debian/patches/gcc-9.patch
> 
> diff --git a/debian/changelog b/debian/changelog
> index dfa8217..c1267f4 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +faad2 (2.8.8-4) UNRELEASED; urgency=medium
> +
> +  * Fix build with gcc-9 and asneeded flag on i386.
> +
> + -- Gianfranco Costamagna   Tue, 11 Jun 2019 
> 14:41:09 +0200
> +
>  faad2 (2.8.8-3) unstable; urgency=high
>  
>* Team upload.
> diff --git a/debian/patches/gcc-9.patch b/debian/patches/gcc-9.patch
> new file mode 100644
> index 000..e17a3a3
> --- /dev/null
> +++ b/debian/patches/gcc-9.patch
> @@ -0,0 +1,26 @@
> +Description: Fix link failure with gcc-9 and wl,asneeded flags
> +Author: Gianfranco Costamagna 
> +Last-Update: 2019-06-11
> +
> +--- faad2-2.8.8.orig/configure.ac
>  faad2-2.8.8/configure.ac
> +@@ -91,8 +91,8 @@ AC_DEFUN([AC_C99_FUNC_LRINTF],
> + [AC_CACHE_CHECK(for lrintf,
> +   ac_cv_c99_lrintf,
> + [
> +-lrintf_save_CFLAGS=$CFLAGS
> +-CFLAGS="-O -lm"
> ++lrintf_save_LIBS=$LIBS
> ++LIBS="-O -lm"

Why is -O controlling the optimization level moved to LIBS? I suppose,
this should stay in CFLAGS.

Cheers

> + AC_TRY_LINK([
> + #define _ISOC9X_SOURCE  1
> + #define _ISOC99_SOURCE  1
> +@@ -102,7 +102,7 @@ AC_TRY_LINK([
> + #include 
> + ], if (!lrintf(3.14159)) lrintf(2.7183);, ac_cv_c99_lrintf=yes, 
> ac_cv_c99_lrintf=no)
> + 
> +-CFLAGS=$lrintf_save_CFLAGS
> ++LIBS=$lrintf_save_LIBS
> + 
> + ])
> + 
> diff --git a/debian/patches/series b/debian/patches/series
> index 6d4062f..f35c884 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -2,3 +2,4 @@ reproducible-build.patch
>  0009-syntax.c-check-for-syntax-element-inconsistencies.patch
>  0010-sbr_hfadj-sanitize-frequency-band-borders.patch
>  0004-Fix-a-couple-buffer-overflows.patch
> +gcc-9.patch
> -- 
> 2.17.1
> 


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#930365: CUDA 10.1 Update 1 is now available

[Graham Inggs]

Source: nvidia-cuda-toolkit
Version: 9.2.148-6
Severity: wishlist

Hi Maintainers

CUDA 10.1 Update 1 (10.1.168) was released at the end of May, 2019.  The 
minimum NVIDIA driver version remains at 418.39 and support is added for 
Clang 8.


As per the release notes [1]:
"CUDA 10.1 Update 1 is a minor update that is binary compatible with 
CUDA 10.1. This release will work with all versions of the R418 NVIDIA 
driver."


Regards
Graham


[1] 
https://docs.nvidia.com/cuda/archive/10.1/cuda-toolkit-release-notes/index.html

Bug#930350: Not related to the Media Player Indicator extension

[Mike Crowe]

I disabled the Media Player Indicator extension in Tweaks, yet the
play/pause button has just stopped working again.

I probably should have mentioned earlier that I'm running on Wayland. This
appears to mean that I can't try restarting gnome-shell to see if that
fixes the problem.

Mike.

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Raphael Hertzog]

Hi,

On Wed, 05 Jun 2019, Michael Biebl wrote:
> systemd-networkd.service in v241 is locked down more tightly then v232.
> It might be worth a try to comment out the hardening features one by one
> to see if one of them causes your problem.

Thanks for the idea! I tried that but it did not help. I found the issue
after a few more tries tweaking the network configuration file. It's
simply that the system has IPv6 disabled in the kernel policy while the
.network file instructs to configure an IPv6 address.

Both are contradictory but they happily lived together up-to-now.
I don't know what changed but if we don't improve systemd-networkd
to just skip IPv6 configuration when the kernel has a policy disabling
IPv6, then we will have plenty of servers broken on upgrades because
it's quite common to keep the network configuration file provided by
the hoster and just disable IPv6 at the kernel level with sysctl:

$ grep ipv6 /etc/sysctl.conf
# Disable ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#905772: Not Fixed by dh* in the meantime, actually got worse in experimental

[Christian Ehrhardt]

Hi,
I checked this issue for Ubuntu bug 1786179 as I wanted to drop the
related delta that we formerly had. That is the same topic as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905772 that we
discuss here.

At first I thought the changes to dh_ resolved this sysV-vs-systemd
fight as I've seen it happen in other packages.

After initial install we have all sockets, but no service running => ok
But if services are running (later in the live-cycle) and we trigger a
reinstall/upgrade they are all restarted (which they are not supposed
to be done).

4 0  6927  6039  20   0  68836 55752 poll_s S+   ?  0:00
\_ apt install --reinstall libvirt-daemon-system
4 0  7045  6927  20   0  12924  4524 do_wai Ss+  pts/1  0:00
   \_ /usr/bin/dpkg --status-fd 25 --configure --pending
0 0  7046  7045  20   0  25560 16328 do_wai S+   pts/1  0:00
   \_ /usr/bin/perl -w /usr/share/debconf/frontend
/var/lib/dpkg/info/libvirt-daemon-system.postinst configure 5.4.
4 0  7055  7046  20   0   2572  1352 do_wai S+   pts/1  0:00
   \_ /bin/sh
/var/lib/dpkg/info/libvirt-daemon-system.postinst configure
5.4.0-0ubuntu1~ppa6
0 0  7492  7055  20   0  11028  2464 poll_s S+   pts/1  0:00
   \_ /bin/systemctl restart libvirt-guests.service
virtlockd-admin.socket virtlockd.service virtlockd.sock


This causes it to hang for 30-60 seconds on the upgrade which isn't
good but also not too bad.
But the logd/lockd services are restarted (I see new PIDs) which is
bad since those are all "--no-stop-on-upgrade".

I went back to (I know this is less of an option for Debian, but it
proved to be a great stop gap measure all too often) drop the sysV
scripts.

And back on that code not only does it look fine after install, now
also reinstall/upgrade work again.
The PIDs stay constant and no hang is perceived.
- install (sockets up, services down) = good
- reinstall (sockets up, services down) = good
- reinstall with services up
  - no hang perceived = good
  - PIDs still change = bad

So it is better without sysV, but not perfect (as in former versions) either.

Since there were discussions about reproducibility, the shortest test IMHO is:
$ apt install libvirt-daemon-system
$ systemctl start virtlogd.service
$ systemctl start virtlockd.service
$ systemctl status virtlogd.service virtlockd.service --no-pager
--lines 1 | grep PID
 Main PID: 14021 (virtlogd)
 Main PID: 14020 (virtlockd)
$ apt install --reinstall libvirt-daemon-system
# the PIDs will have changed, but they should not being "--no-stop-on-upgrade"

With compat 12 (even with sysV dropped as we did in Ubuntu) the
services will restart which is not what is wanted.
I verified e.g. Disco which has libvirt 5.0 and the sysV dropped, no
problem there.

For simplicity I compare/debug the versions with sysV dropped (less
interactions).
A lot of the postinst is the same, here "old = good" (Disco based on
libvirt 5.0) and "new = bad" (Eoan based on your 5.3 updated to
libvirt 5.4 from upstream).

old:
  dh_systemd_start/12ubuntu1 for libvirtd.service
  => deb-systemd-invoke $_dh_action 'libvirtd.service' (action => restart)
  dh_systemd_start/12ubuntu1 for "all others"
  deb-systemd-invoke start ... (all services and sockets)
  # on already running services that is a no-op the PIDs stay the same
new:
  dh_installsystemd/12.1.1ubuntu1 for all services
  deb-systemd-invoke $_dh_action (action => restart)
  # this is what breaks the current libvirt, calling restart on the service

I started a buster system to check if this is special to Ubuntu, or at
least only to what we have in -experimental.
Ok, as initially reported on the bug here in Buster this issue applies
to virtlockd but not virtlogd.
I installed 5.2.0-2 from experimental, and there as expected both PIDs
are recycled.
Which makes sense given that it seems a non libvirt specific issue in
the postinst as generated by dh_installsystemd.

The d/rules line for all affected services surely has --no-stop-on-upgrade:
  dh_installsystemd -p libvirt-daemon-system --no-stop-on-upgrade
$(LIBVIRT_SYSTEM_SERVICES)

Not sure what to do yet - I'm experimenting, but I wanted to keep you
in the loop as well.

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#930370: debconf: Overriding debconf db with file fails with a message "access to disallowed key Filename in restricted hash"

[Jiri Palecek]

Package: debconf
Version: 1.5.71
Severity: normal

Dear Maintainer,

while trying to debug some difficulties with unattended package
installation, I came accross an interesting problem. While debconf(7)
says you can use DEBCONF_DB_OVERRIDE like this:

DEBCONF_DB_FALLBACK=File{Filename:/root/config.dat Backup:no}

when trying it actually, i got an error message:

# LC_MESSAGES=C DEBCONF_DEBUG=developer 
DEBCONF_DB_OVERRIDE="File{Filename:config2.dat.Lwzkvd}" 
DEBIAN_FRONTEND=noninteractive dpkg --auto-deconfigure -i 
../linux-*_"$DATE"_*.deb
... blah blah...
Attempt to access disallowed key 'Filename' in a restricted hash at 
/usr/share/perl5/Debconf/DbDriver.pm line 35.

It does work, though, without the "Filename:" part. What gives?

Another problem, and the reason I am actually experimentig with this, is
that it actually doesn't work unattended, because it somehow disregards
what is in the config file. ie:

debconf (developer): <-- FSET 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+ seen 
false
debconf (developer): --> 0 false
debconf (developer): <-- SUBST 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+ 
modules_base /lib/modules
debconf (developer): --> 0
debconf (developer): <-- SUBST 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+ 
package linux-image-4.19.36-bughunt+
debconf (developer): --> 0
debconf (developer): <-- INPUT critical 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
debconf (developer): --> 30 question skipped
debconf (developer): <-- GO
debconf (developer): --> 0 ok
debconf (developer): <-- GET 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
debconf (developer): --> 0 true

I need false on the last line, but still get true (the
default). However, the config2.dat contains

Name: linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
Template: 
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
Value: false

Maybe you could help me with that.

Regards
Jiri Palecek

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.36-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debconf depends on:
ii  perl-base  5.28.1-6

Versions of packages debconf recommends:
ii  apt-utils 1.8.2
ii  debconf-i18n  1.5.71

Versions of packages debconf suggests:
ii  debconf-doc1.5.71
pn  debconf-kde-helper 
ii  debconf-utils  1.5.71
ii  dialog 1.3-20190211-1
pn  libgtk3-perl   
pn  libnet-ldap-perl   
ii  libterm-readline-gnu-perl  1.36-1
ii  perl   5.28.1-6
ii  whiptail   0.52.20-4

-- debconf information:
  debconf-apt-progress/preparing:
  debconf-apt-progress/media-change:
  debconf-apt-progress/info:
* debconf/frontend: Dialog
  debconf-apt-progress/title:
* debconf/priority: low

Bug#929821: libgd2: CVE-2019-11038: Uninitialized read in gdImageCreateFromXbm

[Jonas Meurer]

Hello,

Salvatore Bonaccorso wrote:
> The following vulnerability was published for libgd2.
> 
> CVE-2019-11038[0]:
> Uninitialized read in gdImageCreateFromXbm
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

While working on a libgd2 update for Jessie LTS, I prepared a patch that
fixes this bug for unstable as well. If nobody objects, I would go ahead
with an NMU to get this CVE fixed in time for Buster, ok?

The patch (created with `git format-patch`) is attached.

I also sent the patch upstream: https://github.com/libgd/libgd/pull/503

Cheers
 jonas
From 6d9343547910719714d2606a9cb11da859200c3d Mon Sep 17 00:00:00 2001
From: Jonas Meurer 
Date: Tue, 11 Jun 2019 16:23:01 +0200
Subject: [PATCH] Fix CVE-2019-11038: Uninitialized read in
 gdImageCreateFromXbm

---
 debian/changelog  |  8 +
 ...ialized-read-in-gdImageCreateFromXbm.patch | 35 +++
 debian/patches/series |  1 +
 3 files changed, 44 insertions(+)
 create mode 100644 debian/patches/Fix-501-Uninitialized-read-in-gdImageCreateFromXbm.patch

diff --git a/debian/changelog b/debian/changelog
index c732f03..87fde35 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libgd2 (2.2.5-5.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2019-11038: Uninitialized read in gdImageCreateFromXbm
+(Closes: #929821)
+
+ -- Jonas Meurer   Tue, 11 Jun 2019 16:21:57 +0200
+
 libgd2 (2.2.5-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/Fix-501-Uninitialized-read-in-gdImageCreateFromXbm.patch b/debian/patches/Fix-501-Uninitialized-read-in-gdImageCreateFromXbm.patch
new file mode 100644
index 000..150f133
--- /dev/null
+++ b/debian/patches/Fix-501-Uninitialized-read-in-gdImageCreateFromXbm.patch
@@ -0,0 +1,35 @@
+From: Jonas Meurer 
+Date: Tue, 11 Jun 2019 12:16:46 +0200
+Subject: Fix #501: Uninitialized read in gdImageCreateFromXbm
+ (CVE-2019-11038)
+
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-11038
+Bug-Debian: https://bugs.debian.org/929821
+Bug: https://github.com/libgd/libgd/issues/501
+
+We have to ensure that `sscanf()` does indeed read a hex value here,
+and bail out otherwise.
+
+Original patch by Christoph M. Becker  for PHP libgd ext.
+https://git.php.net/?p=php-src.git;a=commit;h=ed6dee9a198c904ad5e03113e58a2d2c200f5184
+---
+ src/gd_xbm.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/gd_xbm.c b/src/gd_xbm.c
+index 29bc5c2..1aad2ff 100755
+--- a/src/gd_xbm.c
 b/src/gd_xbm.c
+@@ -169,7 +169,11 @@ BGD_DECLARE(gdImagePtr) gdImageCreateFromXbm(FILE * fd)
+ 			}
+ 			h[3] = ch;
+ 		}
+-		sscanf(h, "%x", );
++		if (sscanf(h, "%x", ) != 1) {
++			gd_error("invalid XBM");
++			gdImageDestroy(im);
++			return 0;
++		}
+ 		for (bit = 1; bit <= max_bit; bit = bit << 1) {
+ 			gdImageSetPixel(im, x++, y, (b & bit) ? 1 : 0);
+ 			if (x == im->sx) {
diff --git a/debian/patches/series b/debian/patches/series
index 1eb76ca..91e5574 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ Fix-420-Potential-infinite-loop-in-gdImageCreateFrom.patch
 bmp-check-return-value-in-gdImageBmpPtr.patch
 CVE-2019-6977.patch
 Fix-492-Potential-double-free-in-gdImage-Ptr.patch
+Fix-501-Uninitialized-read-in-gdImageCreateFromXbm.patch
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#930364: unblock: gvfs/1.38.1-5

[Simon McVittie]

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

Please unblock package gvfs to fix a missing authorization check on a
private D-Bus socket (no CVE ID yet).

This also adds some security hardening that was applied upstream at the
same time (restricting D-Bus authentication mechanisms on the private
socket to only accept EXTERNAL, which is the simplest and most robust
mechanism available).

unblock gvfs/1.38.1-5


diffstat for gvfs-1.38.1 gvfs-1.38.1

 changelog   |   13 +
 patches/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch |   89 ++
 patches/gvfsdaemon-Only-accept-EXTERNAL-authentication.patch|   51 +
 patches/ref-jobs-in-thread.patch|8 
 patches/series  |2 
 5 files changed, 159 insertions(+), 4 deletions(-)

diff -Nru gvfs-1.38.1/debian/changelog gvfs-1.38.1/debian/changelog
--- gvfs-1.38.1/debian/changelog	2019-06-05 08:34:17.0 +0100
+++ gvfs-1.38.1/debian/changelog	2019-06-11 12:28:34.0 +0100
@@ -1,3 +1,16 @@
+gvfs (1.38.1-5) unstable; urgency=high
+
+  * Team upload
+  * d/p/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch:
+Add missing authentication, preventing a local attacker from connecting
+to an abstract socket address learned from netstat(8) and issuing
+arbitrary D-Bus method calls
+  * d/p/gvfsdaemon-Only-accept-EXTERNAL-authentication.patch:
+Harden private D-Bus connection by rejecting the more complicated
+DBUS_COOKIE_SHA1 authentication mechanism and only accepting EXTERNAL.
+
+ -- Simon McVittie   Tue, 11 Jun 2019 12:28:34 +0100
+
 gvfs (1.38.1-4) unstable; urgency=high
 
   * Team upload
diff -Nru gvfs-1.38.1/debian/patches/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch gvfs-1.38.1/debian/patches/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch
--- gvfs-1.38.1/debian/patches/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch	1970-01-01 01:00:00.0 +0100
+++ gvfs-1.38.1/debian/patches/gvfsdaemon-Check-that-the-connecting-client-is-the-same-u.patch	2019-06-11 12:28:34.0 +0100
@@ -0,0 +1,89 @@
+From: Simon McVittie 
+Date: Wed, 5 Jun 2019 13:33:38 +0100
+Subject: gvfsdaemon: Check that the connecting client is the same user
+
+Otherwise, an attacker who learns the abstract socket address from
+netstat(8) or similar could connect to it and issue D-Bus method
+calls.
+
+Signed-off-by: Simon McVittie 
+Applied-upstream: 1.38.3, commit:e3808a1b4042761055b1d975333a8243d67b8bfe
+---
+ daemon/gvfsdaemon.c | 36 +++-
+ 1 file changed, 35 insertions(+), 1 deletion(-)
+
+diff --git a/daemon/gvfsdaemon.c b/daemon/gvfsdaemon.c
+index 406d4f8..be148a7 100644
+--- a/daemon/gvfsdaemon.c
 b/daemon/gvfsdaemon.c
+@@ -79,6 +79,7 @@ struct _GVfsDaemon
+   
+   gint mount_counter;
+   
++  GDBusAuthObserver *auth_observer;
+   GDBusConnection *conn;
+   GVfsDBusDaemon *daemon_skeleton;
+   GVfsDBusMountable *mountable_skeleton;
+@@ -171,6 +172,8 @@ g_vfs_daemon_finalize (GObject *object)
+ }
+   if (daemon->conn != NULL)
+ g_object_unref (daemon->conn);
++  if (daemon->auth_observer != NULL)
++g_object_unref (daemon->auth_observer);
+   
+   g_hash_table_destroy (daemon->registered_paths);
+   g_hash_table_destroy (daemon->client_connections);
+@@ -236,6 +239,35 @@ name_vanished_handler (GDBusConnection *connection,
+   daemon->lost_main_daemon = TRUE;
+ }
+ 
++/*
++ * Authentication observer signal handler that authorizes connections
++ * from the same uid as this process. This matches the behaviour of a
++ * libdbus DBusServer/DBusConnection when no DBusAllowUnixUserFunction
++ * has been set, but is not the default in GDBus.
++ */
++static gboolean
++authorize_authenticated_peer_cb (GDBusAuthObserver *observer,
++ G_GNUC_UNUSED GIOStream *stream,
++ GCredentials *credentials,
++ G_GNUC_UNUSED gpointer user_data)
++{
++  gboolean authorized = FALSE;
++
++  if (credentials != NULL)
++{
++  GCredentials *own_credentials;
++
++  own_credentials = g_credentials_new ();
++
++  if (g_credentials_is_same_user (credentials, own_credentials, NULL))
++authorized = TRUE;
++
++  g_object_unref (own_credentials);
++}
++
++  return authorized;
++}
++
+ static void
+ g_vfs_daemon_init (GVfsDaemon *daemon)
+ {
+@@ -265,6 +297,8 @@ g_vfs_daemon_init (GVfsDaemon *daemon)
+ 
+   daemon->conn = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, NULL);
+   g_assert (daemon->conn != NULL);
++  daemon->auth_observer = g_dbus_auth_observer_new ();
++  g_signal_connect (daemon->auth_observer, "authorize-authenticated-peer", G_CALLBACK (authorize_authenticated_peer_cb), NULL);
+ 
+   

Bug#930350: marked as done (gnome-shell: Play/pause keyboard button stops controlling Rhythmbox/Totem)

[Simon McVittie]

Mike Crowe wrote:
> It appears that functionality of the play/pause keyboard button returns to
> normal if I close Google Chrome

This probably means Google Chrome uses GNOME's D-Bus APIs to register
itself as a media player, so that the play/pause/etc. keys can control
sites like Youtube and Soundcloud?

The play/pause/etc. keys are intercepted by GNOME and routed to exactly
one media player, to make sure that pressing Play while you have, for
example, both Totem and Rhythmbox open doesn't cause them both to start
playing at the same time (which would usually result in cacophony). I
don't know whether they're sent to the most recently registered media
player, or follow some more elaborate heuristic.

It would perhaps be better if Chrome only registered itself as a media
player while the current tab is a site containing multimedia playback,
so that other browser uses did not interfere with local media player apps.

smcv

Bug#930311: lintian: Possible exception to package-contains-documentation-outside-usr-share-doc

[Chris Lamb]

Niels Thykier wrote:

> If we intend to create the exception in lintian, I would personally
> probably go with making the exception first and then filing the bug
> against dh-r to remove the auto-generation.

Good call. I've done the former task and filed the latter
as #930369.


Regards,

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

Bug#771339: linux: linux-headers 3.16 Makefile contains VERSION=2 PATCHLEVEL=6

[Fab Stz]

Source: linux
Version: 4.9.0 or 4.19... probably any
Followup-For: Bug #771339

Dear Maintainer,

This bug still exists in linux 4.9 and 4.19 (stretch, stretch-backports and
also buster)

Like the first reporter, I tried compiling the amdgpu driver provided by AMD
(through DKMS) and it is searching for the kernel version in that file.

As a workaroung in the meantime, I manually set VERSION to 4 and PATCHLEVEL to
19 in /usr/src/linux-headers-4.9.0-9-amd64/Makefile
or the equivalent for 4.19



-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#930366: initramfs-tools: unmkinitramfs fails to unpack lz4 compressed initrd

[Dimitri John Ledkov]

Package: initramfs-tools
Version: 0.133
Severity: normal
Tags: patch

Dear Maintainer,

unmkinitramfs fails to unpack lz4 compressed initrd, ie.:

$ sudo apt install initramfs-tools lz4 file
$ mkinitramfs -c lz4 -o foo.img
$ unmkinitramfs foo.img bar
cpio: premature end of archive
$ echo $?
2

I think this is because lz4cat is strict with file extensions:

$ file foo.img 
foo.img: LZ4 compressed data (v0.1-v0.9)
$ lz4cat -t foo.img 
File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: foo.img

I propose the attached patch to change 'lz4cat -t $archive'
invocations to become 'lz4cat -t <$archive' instead. As lz4cat does
not / cannot enforce extension checking on streams.

Regards,

Dimitri.
diff -Nru initramfs-tools-0.133ubuntu6/unmkinitramfs 
initramfs-tools-0.133ubuntu8/unmkinitramfs
--- initramfs-tools-0.133ubuntu6/unmkinitramfs  2019-06-07 19:22:58.0 
+
+++ initramfs-tools-0.133ubuntu8/unmkinitramfs  2019-06-09 23:21:17.0 
+
@@ -33,8 +33,8 @@
gzip -c -d "$archive"
elif xzcat -t "$archive" >/dev/null 2>&1 ; then
xzcat "$archive"
-   elif lz4cat -t "$archive" >/dev/null 2>&1 ; then
-   lz4cat "$archive"
+   elif lz4cat -t <"$archive" >/dev/null 2>&1 ; then
+   lz4cat <"$archive"
elif bzip2 -t "$archive" >/dev/null 2>&1 ; then
bzip2 -c -d "$archive"
elif lzop -t "$archive" >/dev/null 2>&1 ; then

Bug#930369: dh-r: Please drop automated package-contains-documentation-outside-usr-share-doc Lintian override generation

[Chris Lamb]

Package: dh-r
Version: 20190121
Severity: wishlist
X-Debbugs-CC: lintian-ma...@debian.org

Hi,

In #930311, Niels Thykier mentions that he:

> noticed that the dh-r package by default creates an override for
> package-contains-documentation-outside-usr-share-doc when the R
> package puts documentation in usr/lib/R/site-library

To wit, https://sources.debian.org/src/dh-r/20190121/dh/R.pm/?hl=3#L268.

My retort was that "the idea of automatically-generated overrides
simply makes me squirm" and so I added an exception to Lintian itself
here:

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

Accordingly, please remove the automatic generation code. At the very
least it will now result in annoying "unused override" warnings
instead.

(As an aside, if a similar situation occurs in the future, please
consider requesting the Lintian maintainers to make a general
exception; it is surely poor software engineering practice to litter
our entire archive when we can so easily fix it in one place.)


Best wishes,

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

Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

[Antonio Terceiro]

Control: retitle -1 vagrant images: network setup in libvirt images are not 
consistent with Debian defaults

On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
> Package: cloud.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> I noticed a difference between providers for the same box
> (debian/stretch64):
> 
> * with libvirt provider, `systemd-networkd` service is enabled and started
> after first boot of VM.
> 
> * with virtualbox provider, `systemd-networkd`
> service is disabled and stopped after first boot of VM.
> 
> It will be better to have only one way to manage network for the same image
> with different providers.

actually, the correct fix would be to make the libvirt images use the
same setup as virtualbox (which is the same as a regular Debian install
created by the Debian installer).


signature.asc
Description: PGP signature

Bug#930362: new post: Help the Java Team Distribute your project!

[Laura Arjona Reina]

Package: press
Severity: normal
X-Debbugs-CC: debian-public...@lists.debian.org, debian-j...@lists.debian.org

Hi
Thanks Hans-Christoph Steiner for resuming the work on this post.
This bug is the continuation of the !16 merge request in Salsa [1], I have 
merged the work so far, and turned the post into a draft until we're all happy 
to publish it.


[1] https://salsa.debian.org/publicity-team/bits/merge_requests/16

I think it's better that we continue using the BTS and committing directly in 
the bits repo, so we don't need to maintain several merge requests.


The current draft is here:

https://salsa.debian.org/publicity-team/bits/blob/master/content/2019/help-the-java-team-distribute-your-project.md

I have not much time today to comment about the content (and I would like to 
provide patches) so I'm leaving this bug open for now and will come back to it 
soon, I hope.


I propose to publish it next week (17 to 23 Jun 2019) because we have just 
published a blog post and we had planned another one during this week.


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

Bug#930363: faad2: fix build with gcc-9 [patch]

[Gianfranco Costamagna]

control: tags -1 - moreinfo

Hello Sebastian

do you like the attached version then? :)

thanks for the quick update,
I think a CFLAG passed as LIB doesn't matter that much, while the opposite 
hurts more, 
but you are right, we should keep them separate indeed.

thanks for pointing it out!

Gianfranco
Description: Fix link failure with gcc-9 and wl,asneeded flags
Author: Gianfranco Costamagna 
Last-Update: 2019-06-11

--- faad2-2.8.8.orig/configure.ac
+++ faad2-2.8.8/configure.ac
@@ -92,7 +92,9 @@ AC_DEFUN([AC_C99_FUNC_LRINTF],
   ac_cv_c99_lrintf,
 [
 lrintf_save_CFLAGS=$CFLAGS
-CFLAGS="-O -lm"
+lrintf_save_LIBS=$LIBS
+CFLAGS="-O"
+LIBS="-lm"
 AC_TRY_LINK([
 #define _ISOC9X_SOURCE  1
 #define _ISOC99_SOURCE  1
@@ -103,6 +105,7 @@ AC_TRY_LINK([
 ], if (!lrintf(3.14159)) lrintf(2.7183);, ac_cv_c99_lrintf=yes, ac_cv_c99_lrintf=no)
 
 CFLAGS=$lrintf_save_CFLAGS
+LIBS=$lrintf_save_LIBS
 
 ])
 

Bug#930368: gatb-core: FTBFS due to inaccurate symbols file

[Gilles Filippini]

Source: gatb-core
Version: 1.4.1+git20181225.44d5a44+dfsg-2
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During a rebuild of gatb-core for unstable on amd64 I experienced a FTBFS at the
dh_makeshlibs step:

   dh_makeshlibs -O--sourcedirectory=gatb-core
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libgatbcore2/DEBIAN/symbols doesn't match 
completely debian/libgatbcore2.symbols.amd64
- --- debian/libgatbcore2.symbols.amd64 
(libgatbcore2_1.4.1+git20181225.44d5a44+dfsg-2_amd64)
+++ dpkg-gensymbolsErQvax   2019-06-11 09:56:28.965481025 +
@@ -8997,7 +8997,7 @@
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE7reserveEm@Base
 1.4.1
- - 
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
+#MISSING: 1.4.1+git20181225.44d5a44+dfsg-2# 
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE7reserveEm@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi3EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
@@ -9007,7 +9007,7 @@
  
_ZNSt6vectorISt5tupleIJmiEESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJmiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt6threadSaIS0_EE17_M_realloc_insertIJZN10ThreadPoolC4EmEUlvE_EEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_@Base
 1.4.1
- - _ZNSt6vectorIbSaIbEE13_M_initializeEm@Base 1.4.1+git20181225.44d5a44+dfsg
+#MISSING: 1.4.1+git20181225.44d5a44+dfsg-2# 
_ZNSt6vectorIbSaIbEE13_M_initializeEm@Base 1.4.1+git20181225.44d5a44+dfsg
  _ZNSt6vectorIbSaIbEE13_M_insert_auxESt13_Bit_iteratorb@Base 1.4.1
  _ZNSt6vectorIbSaIbEE13_M_reallocateEm@Base 1.4.1
  _ZNSt6vectorIbSaIbEE14_M_fill_insertESt13_Bit_iteratormb@Base 1.4.1
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

Thanks,

_g.

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlz/ttsACgkQ7+hsbH/+
z4P/bgf/aI8Kn2N0XrowNHz05+Hw9zTryiLdxmSgqs3HYJwq+bUjzbpZQTbwFb+U
Fgosu7yUAzPQSc0XeWAHbE9zosOVH5pqsvIVCvOOcwIrMJ1w28arh0YtsVTNIs71
4Cn1/x22ZZNHe6rbbb1Kzf0gf1JBMm6riKVqXDh1iJf0S4a1O63w1O6gNXGvXPsj
cwfqbP6En5Wmqys51FH3ZTAWK/ZF/3LPAyGlxgrK7KiFpub1ckph0WiKlaRFOYAv
uzG8Wy7MeVBaG9fpUd/oF+qQiUM+OrHWCXZLLuWKj7UCdCfRgzu3D+t7R5NlTFVr
Rh/mAr/U0rbFG7nDa8g0wOCQNrGBIw==
=2Gnd
-END PGP SIGNATURE-

Bug#930363: faad2: fix build with gcc-9 [patch]

[Fabian Greffrath]

Control: forwarded -1 
https://github.com/knik0/faad2/commit/920ec985a74c6f88fe507181df07a0cd7e51d519
Control: tags -1 +upstream +fixed-upstream

Applied upstream, thanks!

Am Dienstag, den 11.06.2019, 16:05 +0200 schrieb Gianfranco Costamagna:
> control: tags -1 - moreinfo
> 
> Hello Sebastian
> 
> do you like the attached version then? :)
> 
> thanks for the quick update,
> I think a CFLAG passed as LIB doesn't matter that much, while the
> opposite hurts more, 
> but you are right, we should keep them separate indeed.
> 
> thanks for pointing it out!
> 
> Gianfranco


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

Bug#930311: lintian: Possible exception to package-contains-documentation-outside-usr-share-doc

[Chris Lamb]

Hi Niels,

> Re:
> https://salsa.debian.org/lintian/lintian/commit/a16cd3a1c812c8894bddf9b920561eb0dd602d85
> 
> I suspect we should probably match usr/lib/R/site-library/ as a prefix
> rather than an exact match.

Whoops. Fixed in:

  
https://salsa.debian.org/lintian/lintian/commit/3ced3d1b699f86726809043a4c3dd6c377593a35

Thanks for your review.


Best wishes,

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

Bug#910143:

[Emmanuel Kasper]

For virtualbox vagrant boxes, please find new box releases at 
https://app.vagrantup.com/debian

Libvirt boxes are pending.

Extending the disk image to 20GB slows the build process a bit, as we need to 
zero free a bigger filesystem, but it is still acceptable.


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#930377: unblock: haskell-argon2/1.3.0.1-5

[Sean Whitton]

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

Please unblock package haskell-argon2.

Fixes a stretch->buster upgrade bug caused by libargon2-0-dev becoming a
virtual package.

unblock haskell-argon2/1.3.0.1-5

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton
diff -Nru haskell-argon2-1.3.0.1/debian/changelog 
haskell-argon2-1.3.0.1/debian/changelog
--- haskell-argon2-1.3.0.1/debian/changelog 2018-10-01 03:47:25.0 
-0700
+++ haskell-argon2-1.3.0.1/debian/changelog 2019-06-10 13:12:30.0 
-0700
@@ -1,3 +1,10 @@
+haskell-argon2 (1.3.0.1-5) unstable; urgency=medium
+
+  * Switch deps libargon2-0-dev -> libargon2-dev (Closes: #930300).
+Thanks Andreas Beckmann for reporting the problem.
+
+ -- Sean Whitton   Mon, 10 Jun 2019 13:12:30 -0700
+
 haskell-argon2 (1.3.0.1-4) unstable; urgency=medium
 
   * Remove build dependency on libghc-text-dev (provided by ghc-8.4.3)
diff -Nru haskell-argon2-1.3.0.1/debian/control 
haskell-argon2-1.3.0.1/debian/control
--- haskell-argon2-1.3.0.1/debian/control   2018-10-01 03:47:25.0 
-0700
+++ haskell-argon2-1.3.0.1/debian/control   2019-06-10 13:12:30.0 
-0700
@@ -10,7 +10,7 @@
  ghc (>= 8.4.3),
  ghc-prof,
  haskell-devscripts (>= 0.13),
- libargon2-0-dev,
+ libargon2-dev,
  libghc-text-short-dev (>= 0.1.2),
  libghc-text-short-dev (<< 0.2),
  libghc-text-short-prof,
@@ -24,12 +24,12 @@
  This library provides Haskell bindings to libargon2, the reference
  implementation of the Argon2 password-hashing function.
  .
- See the libargon2-0-dev package for more information on Argon2.
+ See the libargon2-dev package for more information on Argon2.
 
 Package: libghc-argon2-dev
 Architecture: any
 Depends:
- libargon2-0-dev,
+ libargon2-dev,
  ${haskell:Depends},
  ${misc:Depends},
  ${shlibs:Depends},


signature.asc
Description: PGP signature

Bug#930379: xfdesktop4: Deskop icons order resets at login

[Simon]

Package: xfdesktop4
Version: 4.12.4-2.1
Severity: important

Dear Maintainer,

Current xfdesktop4 version still suffers from a bug opened in 2014 and now (at
last!) solved upstream in version 4.12.5.

https://bugzilla.xfce.org/show_bug.cgi?id=11266

Since it makes life of XFCE users a lot easier, could you please include it in
the forthcoming Debian release?

Thanks.



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages xfdesktop4 depends on:
ii  exo-utils0.12.4-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.14-1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.4-2.1

Versions of packages xfdesktop4 recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.14-1
ii  dbus-x11 [dbus-session-bus]   1.12.14-1
ii  librsvg2-common   2.44.10-2.1
pn  tumbler   
ii  xdg-user-dirs 0.17-2

Versions of packages xfdesktop4 suggests:
ii  menu  2.1.47+b1

-- no debconf information

Bug#930378: ITP: qunit-selenium -- Run QUnit tests through Selenium WebDriver

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 

* Package name: qunit-selenium
  Version : 0.0.4
  Upstream Author : Silvio Montanari 
* URL : https://github.com/smontanari/qunit-selenium
* License : Expat
  Programming Lang: Ruby
  Description : Run QUnit tests through Selenium WebDriver

 This package provides a wrapper around the selenium-webdriver with the
 additional logic to parse the QUnit test results page and report the
 success/failure of QUnit tests.

This package is used by rails 6 ujs related web testing codes.

Bug#930311: lintian: Possible exception to package-contains-documentation-outside-usr-share-doc

[Niels Thykier]

Chris Lamb:
> Hi Niels,
> 
>> My question is: Should we move this exception to lintian itself and
>> stop having people automate overrides
> 
> Oh, without any doubt here — the idea of automatically-generated
> overrides simply makes me squirm.
> 
> (Shall we begin by cloning this bug "against" dh-r?)
> 
> 
> Regards,
> 

Re:
https://salsa.debian.org/lintian/lintian/commit/a16cd3a1c812c8894bddf9b920561eb0dd602d85

I suspect we should probably match usr/lib/R/site-library/ as a prefix
rather than an exact match.  My guess is that they have a "per-package"
folder structure beneath that directory.

Thanks,
~Niels

Bug#930375: CVE-2019-12749: DBusServer DBUS_COOKIE_SHA1 authentication bypass

[Simon McVittie]

Package: libdbus-1-3
Version: 1.0.0-1
Severity: grave
Tags: security fixed-upstream patch
Forwarded: https://gitlab.freedesktop.org/dbus/dbus/issues/269

Joe Vennix of Apple Information Security discovered an implementation flaw
in the DBUS_COOKIE_SHA1 authentication mechanism. A malicious client with
write access to its own home directory could manipulate a ~/.dbus-keyrings
symlink to cause a DBusServer with a different uid to read and write
in unintended locations. In the worst case, this could result in the
DBusServer reusing a cookie that is known to the malicious client, and
treating that cookie as evidence that a subsequent client connection
came from an attacker-chosen uid, allowing authentication bypass.

This vulnerability does not normally affect the standard system
dbus-daemon, which only allows the EXTERNAL authentication mechanism.
In supported branches of dbus it also does not normally affect the standard
session dbus-daemon, for the same reason.

However, this vulnerability can affect third-party users of DBusServer
(such as Upstart in Ubuntu 14.04 LTS), third-party dbus-daemon instances,
standard dbus-daemon instances with non-standard configuration, and the
session bus in older/unsupported dbus branches (such as dbus 1.6.x in
Ubuntu 14.04 LTS).

For buster this has been fixed in libdbus-1-3 1.12.16-1. I'll close this
bug when I have a bug number.

For stretch this has been fixed in upstream release 1.10.28 and I am
discussing with the security team whether it is DSA-worthy, and if so,
whether to upload 1.10.28-0+deb9u1 or a minimal backport.

For experimental this will be fixed by upstream release 1.13.12 when
I've tested it.

If the Debian LTS team want to address this vulnerability
in jessie (which has an EOL dbus branch that we no
longer support upstream), they should backport upstream commit

and optionally also the build-time test coverage found in
.

Regards,
smcv

Bug#930380: calligraflow: crash on startup (when run under gnome?)

[Zack Weinberg]

Package: calligraflow
Version: 1:2.9.11+dfsg-4+b1
Severity: important

calligraflow crashes on startup - possibly only when run under a GNOME 
desktop session and/or with KDE persistent state not properly initialized,
since a stack trace fingers the KDE most-recently-used-files implementation.

Stack trace collected with gdb:

QObject::connect: Cannot connect KoDocumentInfo::infoUpdated(const QString &, 
const QString &) to (null)::documentInformationUpdated(const QString &, const 
QString &)

Program received signal SIGSEGV, Segmentation fault.
0x7689f73c in QString::operator=(QString const&) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
(gdb) bt
#0  0x7689f73c in QString::operator=(QString const&) ()
at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#1  0x74c78f88 in  () at /usr/lib/libkdeui.so.5
#2  0x74c68d84 in KXMLGUIClient::findMostRecentXMLFile(QStringList 
const&, QString&) () at /usr/lib/libkdeui.so.5
#3  0x779548ad in KoMainWindow::KoMainWindow(QByteArray const&, 
KComponentData const&) () at /usr/lib/libkomain.so.14
#4  0x7fffec52a535 in FlowPart::createMainWindow() ()
at /usr/lib/libflowprivate.so.14
#5  0x7792b39f in KoApplication::start() () at /usr/lib/libkomain.so.14
#6  0x77dcc88f in kdemain ()
at /usr/lib/kde4/libkdeinit/libkdeinit4_calligraflow.so
#7  0x77c0309b in __libc_start_main (main=
0x4780, argc=1, argv=0x7fffddc8, init=, 
fini=, rtld_fini=, stack_end=0x7fffddb8)
at ../csu/libc-start.c:308
#8  0x47ba in _start ()



-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages calligraflow depends on:
ii  calligra-libs  1:2.9.11+dfsg-4+b1
ii  calligraflow-data  1:2.9.11+dfsg-4
ii  kde-runtime4:17.08.3-2.1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libkdecore54:4.14.38-3
ii  libkdeui5  4:4.14.38-3
ii  libodfgen-0.1-10.1.7-1
ii  libqtcore4 4:4.8.7+dfsg-18
ii  libqtgui4  4:4.8.7+dfsg-18
ii  librevenge-0.0-0   0.0.4-6
ii  libstdc++6 8.3.0-7
ii  libvisio-0.1-1 0.1.6-1+b2
ii  libwpg-0.3-3   0.3.3-1

calligraflow recommends no packages.

calligraflow suggests no packages.

-- no debconf information

Bug#930373: Shotwell: double clicking on the image viewer freezes an image of the picture. Reboot required

[Fran Glais]

Package: shotwell
Version: 0.30.1-1
Severity: critical
Tags: patch
Justification: breaks unrelated software

Dear Maintainer,

In a Wayland session (gnome-shell in my case), double-clicking on an image when
using the Shotwell Viewer fullscreens the image, but then fails to close the
picture.

This picture will remain on-screen even after logging out. I need to reboot the
system to get rid of it.

I consider this a critical bug, as it renders the system unusable, and can
somewhat lead to data loss. It so happened that I manages to properly close and
save my work using purely the keyboard, but without being able to see what's on
the screen. This is due to an image being stuck on my screen, hiding everything
else.

In a way, this could also be a (local) security bug, considering that the user 
can't
make the image on screen disappear, even after logging out. This information may
be leaked to any other user of the same system.

This is a known bug, which was fixed upstream on version 0.32. Due to the Debian
freeze policy, this fix never made it into Buster.

Upstream fix: 
https://gitlab.gnome.org/GNOME/shotwell/commit/6031f8a285c1599fa692905eaa0475faced08415

Best,
Fran

-- Package-specific info:

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

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

Versions of packages shotwell depends on:
ii  dbus-x11 [dbus-session-bus] 1.12.14-1
ii  dconf-cli   0.30.1-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexif12   0.6.21-5.1
ii  libgcr-base-3-1 3.28.1-1
ii  libgcr-ui-3-1   3.28.1-1
ii  libgdata22  0.17.9-3
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgee-0.8-20.20.1-2
ii  libgexiv2-2 0.10.9-1
ii  libglib2.0-02.58.3-2
ii  libgphoto2-62.5.22-3
ii  libgphoto2-port12   2.5.22-3
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libjson-glib-1.0-0  1.4.4-2
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libraw190.19.2-2
ii  librsvg2-common 2.44.10-2.1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-2
ii  libwebkit2gtk-4.0-372.24.2-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  shotwell-common 0.30.1-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#930375: CVE-2019-12749: DBusServer DBUS_COOKIE_SHA1 authentication bypass

[Simon McVittie]

Version: 1.12.16-1

On Tue, 11 Jun 2019 at 17:34:40 +0100, Simon McVittie wrote:
> For buster this has been fixed in libdbus-1-3 1.12.16-1. I'll close this
> bug when I have a bug number.

Bug#930376: gvfsd GetConnection() missing authorization check

[Simon McVittie]

Package: gvfs-daemons
Version: 1.14.1-1
Severity: grave
Tags: security fixed-upstream patch
Forwarded: 
https://gitlab.gnome.org/GNOME/gvfs/commit/70dbfc68a79faac49bd3423e079cb6902522082a

While looking for services that might be vulnerable to CVE-2019-12749
or a similar vulnerability, I noticed that gvfsd has a mechanism to open
a private D-Bus server socket, and does not configure an authorization
check for clients connecting to that socket. An attacker who learns the
abstract socket address from netstat(8) or similar could connect to it
and issue D-Bus method calls.

Mitigation: the attacker would have to win a race with the user owning
gvfsd, who is probably also trying to connect to the same socket. gvfsd
closes the socket after it has accepted one connection.

I have requested a CVE ID from MITRE but not received one yet.

For buster/sid this has been fixed in gvfs 1.38.1-5.

For experimental this has been fixed in gvfs 1.40.1-2.

I do not have a tested patch for stretch or jessie, but the same change
would probably work as-is.

It would probably be a good idea to also backport
https://gitlab.gnome.org/GNOME/gvfs/commit/16a275041de2e70063da8aa5cfb2804de9a2f60a
for additional hardening. This forces authentication to use the
simple, robust EXTERNAL (credentials-passing) mechanism, disabling
DBUS_COOKIE_SHA1, which is somewhat fragile and seems more likely to
contain unknown vulnerabilities.

Regards,
smcv

Bug#930372: Provide node-bootstrap (install package.json and symlink dist to /usr/lib/nodejs)

[Pirate Praveen]

Package: libjs-bootstrap4
severity: wishlist
version: 4.3.1+dfsg2-1

gitlab uses webpack and expects bootstrap node module. Please provide 
this in addition to libjs.

Bug#929708: Reopen the accidentially-closed ITP report

[Boyuan Yang]

Control: reopen -1

Seems that my new upload came with a wrong number of bug report. Reopening
this ITP bug to fix this problem. Sorry for the noise.

Regards,
Boyuan Yang


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

Bug#920567: bash: dpkg-reconfigure: command not found

[Jiri Palecek]

On Sun, 27 Jan 2019 09:12:32 +0600 Thulium Equasman wrote:
> Package: python3-reportbug
> Version: 7.5.1
> Severity: normal
> Tags: d-i
>
> Hi,
> I got the message "bash: dpkg-reconfigure: command not found
> " when I ran `dpkg-reconfigure fontconfig-config`. I ran this command
as root.
> I then ran `echo $PATH` and the following appeared
> "/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games". I
searched for


How did you get your root shell? If that was by running "su", what you
describe is actually expected. You should use "su -". See
https://unix.stackexchange.com/questions/460478/debian-su-and-su-path-differences
for more information about that.


Regards

    Jiri Palecek

Bug#930383: sniffit: New upstream homepage

[Joao Eriberto Mota Filho]

Package: sniffit
Severity: normal

Please see:

https://github.com/resurrecting-open-source-projects/sniffit

Regards,

Eriberto

Bug#930381: txt2html: New upstream homepage

[Joao Eriberto Mota Filho]

Package: txt2html
Severity: normal

Please, see:

https://github.com/resurrecting-open-source-projects/txt2html

Regards,

Eriberto

Bug#930382: outguess: New upstream homepage

[Joao Eriberto Mota Filho]

Package: outguess
Severity: normal

Please, see:

https://github.com/resurrecting-open-source-projects/outguess

Regards,

Eriberto

Bug#929821: libgd2: CVE-2019-11038: Uninitialized read in gdImageCreateFromXbm

[Jonas Meurer]

Jonas Meurer wrote:
> Salvatore Bonaccorso wrote:
> > The following vulnerability was published for libgd2.
> > 
> > CVE-2019-11038[0]:
> > Uninitialized read in gdImageCreateFromXbm
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> While working on a libgd2 update for Jessie LTS, I prepared a patch that
> fixes this bug for unstable as well. If nobody objects, I would go ahead
> with an NMU to get this CVE fixed in time for Buster, ok?
> 
> The patch (created with `git format-patch`) is attached.
> 
> I also sent the patch upstream: https://github.com/libgd/libgd/pull/503

After uploading patched libgd2 to jessie and stretch, I also decided to
go ahead with the NMU to unstable.

I just uploaded libgd2 2.2.5-5.2 to the DELAYED-1 queue. Once it's been
accepted into unstable, I'll file a unblock request to get it into Buster.

I also pushed all three updates to the packaging Git repo at
https://salsa.debian.org/debian/libgd2

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#905772: we might also need --no-restart-after-upgrade in addition to --no-stop-on-upgrade

[Christian Ehrhardt]

Was:
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'libvirt-guests.service'
'virtlockd-admin.socket' 'virtlockd.service' 'virtlockd.socket'
'virtlogd-admin.socket' 'virtlogd.service' 'virtlogd.socket'
>/dev/null || true


/usr/bin/dh_installsystemd
R_FLAG => no restart
RESTART_AFTER_UPGRADE => restart (default)

R_FLAG is only considered in postrm to stop/notstop it
RESTART_AFTER_UPGRADE is considered for postinst

We'd need to set RESTART_AFTER_UPGRADE=0 as well.
That is not (no more?) implied by --no-stop-on-upgrade

First I split list in services and sockets and added the extra arg
just to those not intended to restart:
  dh_installsystemd -p libvirt-daemon-system --no-stop-on-upgrade
--no-restart-after-upgrade $(LIBVIRT_SYSTEM_SERVICES_NR)

New section is:
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
deb-systemd-invoke start 'virtlockd.service'
'virtlockd.socket' 'virtlogd.service' 'virtlogd.socket' >/dev/null ||
true
fi
fi

And one would think that this would keep the processes it up and running as-is.
This actually worked, but we are somewhat back at the original issue
that the restarting the sockets restarts the services (just without
sysV this time).

Later on come the services which still have "restart"

 Main PID: 28688 (virtlogd)
 Main PID: 28687 (virtlockd)
+ deb-systemd-invoke restart libvirt-guests.service
virtlockd-admin.socket virtlockd.socket virtlogd-admin.socket
virtlogd.socket
++ grep 'Main PID'
++ systemctl status virtlogd.service virtlockd.service --no-pager --lines 1
 Main PID: 29470 (virtlogd)
 Main PID: 29469 (virtlockd)

But there isn't really a reason to restart the sockets at all.
And the services already have their systemctl reload virtlogd.service
section in postinst for the proper re-exec.
So lets just make the sockets --no-stop-on-upgrade +
--no-restart-after-upgrade as well.

This seems to do the trick to achieve the correct behavior.
diff --git a/debian/rules b/debian/rules
index 26fc3e7171..63b8a2a316 100755
--- a/debian/rules
+++ b/debian/rules
@@ -247,7 +247,7 @@ override_dh_installinit:

 override_dh_installsystemd:
dh_installsystemd -p libvirt-daemon-system
--restart-after-upgrade libvirtd.service
-   dh_installsystemd -p libvirt-daemon-system
--no-stop-on-upgrade $(LIBVIRT_SYSTEM_SERVICES)
+   dh_installsystemd -p libvirt-daemon-system
--no-stop-on-upgrade --no-restart-after-upgrade
$(LIBVIRT_SYSTEM_SERVICES)

 override_dh_installdocs:
dh_installdocs -plibvirt-doc --doc-main-package libvirt-doc

I have not yet tried what happens if I let the sysV scripts back in.
But for systemd only this seems worth to discuss.

Bug#930373: Shotwell: double clicking on the image viewer freezes an image of the picture. Reboot required

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,


Am Dienstag, den 11.06.2019, 20:19 +0200 schrieb Jörg Frings-Fürst:
[...]
> Hello Fran,
> 
8...]
> Please can you send me the output of 
> 
> dconf dump /org/yorba/shotwell
> 
[...]

Sorry this must be

dconf dump /org/yorba/shotwell/


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

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

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


git:  https://jff.email/cgit/

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


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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlz/8ZcACgkQCfifPIyh
0l30Jg/9EbskosTzqgyrTSpeY5kC+8zPvpLkBBFBBIWd5v7Fopskjxe8VTSzuHQ+
FPQc2t5HarZPRlz2+WtKFHoc43QTo/jKvWvR5bQbdpFgafJFDfNacuJZeWd4+JXO
lfqThVfwVseklGjNwhdOvEi7D62+R+7SV5uYWUlcEXCf5800+Fspw/149lwLAgpT
79VGf2iKw80YDkwVA/1qfsJtotEpQSD5+gp3Lgfao32gRhv41WpWqNEWAJRYpN2u
lZk9JlkWtvcVPrGKJhQP8NjTJle31d7Le+fVRI8qeK47bxXohGi4sgvDwDTMqchZ
XjNKXl3apFZ4fGeVd/GfknwO2fUaE3qBElegYtG75qd7ciepyWp4JeMPEkUxs/vk
WwRaeqioauteQIg4Uy74d58EmXLO475nmlK0wP6L2MpCMtMKCTcD2ldSWvQ6h/yL
PmxOKZKfZFrqnEjN8UYqqL5/SY+c8B689ar1MBMwkWUVpW6ftSkwcWxXmZ3hBqsS
14bISjmef2OHmMpKaDbmOtFrD7opO9p+kNNzW1tA+VAnRjI7gb71khY/hx0HRHh3
Du4r996c/DEbJFQ0+4bOz8EwopaUmnVfI6+uiZpUwg7M5AcXY/AgUy/pRV7Id7Z3
c7qWI4Z2zTl0gmUX/eixXk8Xfe4rWlPSTudKLd9RM4OsU48kBQQ=
=zJrb
-END PGP SIGNATURE-

Bug#930373: Shotwell: double clicking on the image viewer freezes an image of the picture. Reboot required

[Fran Glais]

Hello Jörg,

Thank you for your prompt reply.

You can find the output requested below.

As for reproducing this bug, it was mentioned upstream that it could be
hardware related. I'm running Debian with Sandybridge integrated graphics
(2450M to be more specific).
Upstream issue: https://gitlab.gnome.org/GNOME/shotwell/issues/26

The screencast provided in the link shows exactly my issue. What is not
shown is that the image persists on screen even upon locking the screen or
logging out.

Best regards,
Fran


$ dconf dump /org/yorba/shotwell/
[preferences/export]
export-metadata=true
photo-file-format='PNG'
constraint='ORIGINAL'
export-format-mode='SPECIFIED'
quality='HIGH'
scale=1200

[preferences/ui]
sidebar-position=180
display-sidebar=true
pin-toolbar-state=false
display-basic-properties=true
display-photo-tags=true
display-search-bar=false
display-photo-titles=false
show-welcome-dialog=false
display-photo-ratings=true
events-sort-ascending=false
library-photos-sort-by=2
library-photos-sort-ascending=false
display-photo-comments=false

[preferences/window]
direct-maximize=false
direct-height=1053
direct-width=1866
library-height=741
library-width=1315
library-maximize=false

[crop-settings]
last-crop-height=1
last-crop-width=1
last-crop-menu-choice=0

[printing]
content-width=20.545531914893619
titles-font='Sans Bold 12'
content-units=2
images-per-page=1
size-selection=11
content-ppi=200
print-titles=false
match-aspect-ratio=true
content-height=13.0
content-layout=3

On Tue, Jun 11, 2019 at 2:23 PM Jörg Frings-Fürst  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
>
> Am Dienstag, den 11.06.2019, 20:19 +0200 schrieb Jörg Frings-Fürst:
> [...]
> > Hello Fran,
> >
> 8...]
> > Please can you send me the output of
> >
> > dconf dump /org/yorba/shotwell
> >
> [...]
>
> Sorry this must be
>
> dconf dump /org/yorba/shotwell/
>
>
> CU
> Jörg
> - --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54470 Lieser
>
>
> git:  https://jff.email/cgit/
>
> Threema:  SYR8SJXB
> Wire: @joergfringsfuerst
> Skype:joergpenguin
> Ring: jff
> Telegram: @joergfringsfuerst
>
>
> My wish list:
>  - Please send me a picture from the nature at your home.
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlz/8ZcACgkQCfifPIyh
> 0l30Jg/9EbskosTzqgyrTSpeY5kC+8zPvpLkBBFBBIWd5v7Fopskjxe8VTSzuHQ+
> FPQc2t5HarZPRlz2+WtKFHoc43QTo/jKvWvR5bQbdpFgafJFDfNacuJZeWd4+JXO
> lfqThVfwVseklGjNwhdOvEi7D62+R+7SV5uYWUlcEXCf5800+Fspw/149lwLAgpT
> 79VGf2iKw80YDkwVA/1qfsJtotEpQSD5+gp3Lgfao32gRhv41WpWqNEWAJRYpN2u
> lZk9JlkWtvcVPrGKJhQP8NjTJle31d7Le+fVRI8qeK47bxXohGi4sgvDwDTMqchZ
> XjNKXl3apFZ4fGeVd/GfknwO2fUaE3qBElegYtG75qd7ciepyWp4JeMPEkUxs/vk
> WwRaeqioauteQIg4Uy74d58EmXLO475nmlK0wP6L2MpCMtMKCTcD2ldSWvQ6h/yL
> PmxOKZKfZFrqnEjN8UYqqL5/SY+c8B689ar1MBMwkWUVpW6ftSkwcWxXmZ3hBqsS
> 14bISjmef2OHmMpKaDbmOtFrD7opO9p+kNNzW1tA+VAnRjI7gb71khY/hx0HRHh3
> Du4r996c/DEbJFQ0+4bOz8EwopaUmnVfI6+uiZpUwg7M5AcXY/AgUy/pRV7Id7Z3
> c7qWI4Z2zTl0gmUX/eixXk8Xfe4rWlPSTudKLd9RM4OsU48kBQQ=
> =zJrb
> -END PGP SIGNATURE-
>
>

Bug#926434: fixed (in my point of view) & not listetd in "netinst.iso-image Debian 9.9"

[Martin Kubiak]

Hi Julian,

I answered your question of defining the upstream-mirror correctly at 
"05.04.2019, 18:07". So I thought it is done.


Isn't it?

It seems to be open:
 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926434

And another part:

Today I installed a new machine and wondered that debian.tu-bs.de is not 
listed any more in the mirrors list. Why? Do I have to mirror from 
another source?


Thanks a lot in advance to know what to be done to be listed again,

Martin

Bug#930388: ruby-openid: CVE-2019-11027

[Salvatore Bonaccorso]

Source: ruby-openid
Version: 2.7.0debian-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/openid/ruby-openid/issues/122

Hi,

The following vulnerability was published for ruby-openid.

CVE-2019-11027[0]:
| Ruby OpenID (aka ruby-openid) through 2.8.0 has a remotely exploitable
| flaw. This library is used by Rails web applications to integrate with
| OpenID Providers. Severity can range from medium to critical,
| depending on how a web application developer chose to employ the ruby-
| openid library. Developers who based their OpenID integration heavily
| on the "example app" provided by the project are at highest risk.

Unfortunately there very scarce information available for this issue.
SuSE folks did try to ask upstream in [1]. Originally the assignement
seems to come from [2], but this as well does practiaclly not give
enough information.

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-11027
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11027
[1] https://github.com/openid/ruby-openid/issues/122
[2] https://marc.info/?l=openid-security=155154717027534=2

Regards,
Salvatore

Bug#930390: iperf server will not exit

[dann frazier]

Package: iperf
Version: 2.0.12+dfsg1-2
Severity: important
Tags: patch, upstream

After running some iperf testing, ^c'ing the server fails:

$ iperf -s

Server listening on TCP port 5001
TCP window size:  128 KByte (default)

[..]
[ 19]  0.0- 0.7 sec  5.75 MBytes  65.2 Mbits/sec
^CWaiting for server threads to complete. Interrupt again to force quit.
^C^C^C

This is addressed by upstream commit:
  
https://sourceforge.net/p/iperf2/code/ci/7c0ac64ebea38d0d9ff4d160db4d33bc087a3490/

-- System Information:
Debian Release: 10.0
  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-trunk-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)
LSM: AppArmor: enabled

Versions of packages iperf depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-7
ii  libstdc++6  8.3.0-7

iperf recommends no packages.

iperf suggests no packages.

-- no debconf information

Bug#930389: twisted: CVE-2019-12387

[Salvatore Bonaccorso]

Source: twisted
Version: 18.9.0-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for twisted.

CVE-2019-12387[0]:
| In Twisted before 19.2.1, twisted.web did not validate or sanitize
| URIs or HTTP methods, allowing an attacker to inject invalid
| characters such as CRLF.


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-12387
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12387
[1] 
https://github.com/twisted/twisted/commit/6c61fc4503ae39ab8ecee52d10f10ee2c371d7e2
[2] 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#930391: frei0r-plugins-dev: Missing header files in /usr/include directory

[Laurent BRULET]

Package: frei0r-plugins-dev
Version: 1.6.1-2
Severity: important

Dear Maintainer,

I was trying to build a frei0r plugin I wrote in C++. But the compilation
failed because the header file frei0r.hpp was not present in /usr/include

The unique present header file is frei0r.h which allows to build C plugins
only,
and with limited functionality.

Note : The problem is also present in upstream distribution.

Please find a patch below, which may allow to install these headers.

Regards,



diff -ru a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt2017-05-31 07:57:25.0 +0200
+++ b/CMakeLists.txt2019-06-11 21:22:25.637472171 +0200
@@ -46,7 +46,10 @@
 INCLUDE( cmake/modules/TargetDistclean.cmake OPTIONAL)

 # See this thread for a ridiculous discussion about the simple question how to
install a header file with CMake:
http://www.cmake.org/pipermail/cmake/2009-October/032874.html
-install (DIRECTORY include DESTINATION . FILES_MATCHING PATTERN "frei0r.h"
PATTERN "msvc" EXCLUDE)
+install (DIRECTORY include DESTINATION . FILES_MATCHING
+PATTERN "frei0r*.h"
+PATTERN "frei0r*.hpp"
+PATTERN "msvc" EXCLUDE)

 add_subdirectory (doc)
 add_subdirectory (src)



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

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

-- no debconf information

Bug#930393: RFS: aqemu/0.9.2-2.3 [NMU] [RC] -- Fix #927126 including suggestion from #929342 - aqemu: after updating can't open VMs

[Alexis Murzeau]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: Ignace Mouzannar 
X-Debbugs-CC: Abhijith PA 

Dear mentors,

I am looking for a sponsor for a NMU of "aqemu" to fix this RC bug:
#927126  - aqemu: after updating can't open VMs [0].
This bug was fixed in previous NMU aqemu/0.9.2-2.2 bug after discussion
with release team in #929342 [1], I modified the fix before being able
to migrate to buster.

This NMU remove references to VLANs in the description texts.

The maintainer has not responded to this bug at all, nor other bugs on
this package since 26/07/2016.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927126
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929342#10

 * Package name: aqemu
   Version : 0.9.2-2.3
   Upstream Author : Andrey Rijov, Tobias Gläßer
 * URL : https://sourceforge.net/projects/aqemu/,
 https://github.com/tobimensch/aqemu
 * License : GPL-2+, BSD-3-clause
   Section : x11

It builds those binary packages:

  aqemu - Qt5 front-end for QEMU and KVM

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/aqemu


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

  dget -x
https://mentors.debian.net/debian/pool/main/a/aqemu/aqemu_0.9.2-2.3.dsc

Changes since the last upload in unstable:
aqemu (0.9.2-2.3) unstable; urgency=medium

  * Non-maintainer upload.
  *
debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
- Remove "Virtual LAN" references in description texts.

 -- Alexis Murzeau   Sun, 26 May 2019 01:03:06 +0200

Additional change since the version in buster:
aqemu (0.9.2-2.2) unstable; urgency=medium

  * Non-maintainer upload.
  *
debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
- Fix "after updating can't open VMs": Remove vlan related options.
(Closes: #927126)

 -- Alexis Murzeau   Fri, 17 May 2019 00:55:49 +0200

Source packages diff is in attachment and can be viewed here:
https://salsa.debian.org/amurzeau-guest/aqemu/compare/debian%2F0.9.2-2.2...debian%2F0.9.2-2.3


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
From 26087ea3c3700bc5a019ae8cc0f84eb14954ef3d Mon Sep 17 00:00:00 2001
From: Alexis Murzeau 
Date: Sun, 26 May 2019 01:02:34 +0200
Subject: [PATCH] Remove Virtual LAN references in description texts

---
 debian/changelog |  8 
 ...N-stuff-QEMU-doesn-t-support-it-anymore.patch | 16 
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index b65fecf..24da78a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+aqemu (0.9.2-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
+- Remove "Virtual LAN" references in description texts.
+
+ -- Alexis Murzeau   Sun, 26 May 2019 01:03:06 +0200
+
 aqemu (0.9.2-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git 
a/debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch 
b/debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
index 1e1014c..53591b4 100644
--- 
a/debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
+++ 
b/debian/patches/0002-Remove-VLAN-stuff-QEMU-doesn-t-support-it-anymore.patch
@@ -41,7 +41,7 @@ QEMU can work again.
 +  // -net nic[,macaddr=addr][,model=type][,name=name]
if( ui.CB_Network_Type->currentText() == "nic" )
 -  QMessageBox::information( this, tr("nic"), tr("-net 
nic[,vlan=n][,macaddr=addr][,model=type][,name=name] \nCreate a new Network 
Interface Card and connect it to VLAN n (n = 0 is the default). The NIC is an 
ne2k_pci by default on the PC target. Optionally, the MAC address can be 
changed to addr and a name can be assigned for use in monitor commands. If no 
\'-net\' option is specified, a single NIC is created. Qemu can emulate several 
different models of network card. Valid values for type are i82551, i82557b, 
i82559er, ne2k_pci, ne2k_isa, pcnet, rtl8139, e1000, smc91c111, lance and 
mcf_fec. Not all devices are supported on all targets. Use -net nic,model=? for 
a list of available devices for your target.") );
-+  QMessageBox::information( this, tr("nic"), tr("-net 
nic[,macaddr=addr][,model=type][,name=name] \nCreate a new Network Interface 
Card and connect it to Virtual LAN n (n = 0 is the default). The NIC is an 
ne2k_pci by default on the PC target. Optionally, the MAC address can be 
changed to addr and a name can be assigned for use in monitor commands. If no 
\'-net\' option is specified, a single NIC is created. Qemu can emulate several 
different models of network card. Valid values for type are i82551, i82557b, 
i82559er, ne2k_pci, ne2k_isa, pcnet, rtl8139, e1000, 

Bug#930392: unblock: ibus-sunpinyin/2.0.3+git20181120-4

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: debian-input-met...@lists.debian.org idaob...@gmail.com

Please unblock ibus-sunpinyin 2.0.3+git20181120-4. This upload fixes 
https://bugs.debian.org/929078 , which caused crash when the user is trying to
save settings for this input method.

The full debdiff is pasted below. Please let me know if there are any issues.

Regards,
Boyuan Yang



diff -Nru ibus-sunpinyin-2.0.3+git20181120/debian/changelog ibus-sunpinyin-
2.0.3+git20181120/debian/changelog
--- ibus-sunpinyin-2.0.3+git20181120/debian/changelog   2018-11-20
15:38:43.0 -0500
+++ ibus-sunpinyin-2.0.3+git20181120/debian/changelog   2019-06-11
13:40:06.0 -0400
@@ -1,3 +1,29 @@
+ibus-sunpinyin (2.0.3+git20181120-4) unstable; urgency=medium
+
+  * Team upload.
+  * debian/patches/0003-Fix-upstream-issue-85: Rework again on the
+patch to fix issues introduced in the previous uploads. (really
+really closes: #929078).
+
+ -- Boyuan Yang   Tue, 11 Jun 2019 13:40:06 -0400
+
+ibus-sunpinyin (2.0.3+git20181120-3) unstable; urgency=high
+
+  * Team upload.
+  * debian/patches/0003-Fix-upstream-issue-85: Rework on the patch
+to fix issues introduced in the previous upload. (really
+closes: #929078).
+
+ -- Boyuan Yang   Tue, 11 Jun 2019 12:07:21 -0400
+
+ibus-sunpinyin (2.0.3+git20181120-2) unstable; urgency=high
+
+  * Team upload.
+  * debian/patches: Cherry-pick upstream patch to fix crashing
+when trying to save user settings. (Closes: #929078)
+
+ -- Boyuan Yang   Mon, 10 Jun 2019 12:41:17 -0400
+
 ibus-sunpinyin (2.0.3+git20181120-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ibus-sunpinyin-2.0.3+git20181120/debian/patches/0003-Fix-upstream-
issue-85-the-config-value-is-glib.Varia.patch ibus-sunpinyin-
2.0.3+git20181120/debian/patches/0003-Fix-upstream-issue-85-the-config-value-
is-glib.Varia.patch
--- ibus-sunpinyin-2.0.3+git20181120/debian/patches/0003-Fix-upstream-issue-
85-the-config-value-is-glib.Varia.patch 1969-12-31 19:00:00.0
-0500
+++ ibus-sunpinyin-2.0.3+git20181120/debian/patches/0003-Fix-upstream-issue-
85-the-config-value-is-glib.Varia.patch 2019-06-11 13:40:02.0
-0400
@@ -0,0 +1,64 @@
+From: Boyuan Yang 
+Date: Tue, 11 Jun 2019 12:06:51 -0400
+Subject: Fix upstream issue 85: the config value is glib.Variant
+
+Bug-Debian: https://bugs.debian.org/929078
+Forwarded: https://github.com/sunpinyin/sunpinyin/issues/85
+Applied-Upstream: https://github.com/sunpinyin/sunpinyin/pull/86
+Signed-off-by: LI Daobing 
+Signed-off-by: Boyuan Yang 
+Last-Update: 2019-06-11
+---
+ setup/main.py | 19 +++
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+diff --git a/setup/main.py b/setup/main.py
+index e20a3a5..aaa4a7d 100644
+--- a/setup/main.py
 b/setup/main.py
+@@ -39,10 +39,13 @@ import os
+ from os import path
+ try:
+ import gtk
++import glib
+ except ImportError:
+ from gi import require_version as gi_require_version
+ gi_require_version('Gtk', '3.0')
++gi_require_version('GLib', '2.0')
+ from gi.repository import Gtk as gtk
++from gi.repository import GLib as glib
+ try:
+ import ibus
+ except ImportError:
+@@ -69,19 +72,27 @@ class Option(object):
+ it is used to synchronize the configuration with setting on user
interface
+ """
+ config = ibus.Bus().get_config()
+-
++
++__wrappers = {
++type(True): glib.Variant.new_boolean,
++type(1): glib.Variant.new_int32,
++type('str'): glib.Variant.new_string,
++type([]): glib.Variant.new_strv,
++}
++
+ def __init__(self, name, default):
+ self.name = name
+ self.default = default
++self.__wrap = self.__wrappers[type(self.default)]
+ 
+ def read(self):
+ section, key = self.__get_config_name()
+-return self.config.get_value(section, key, self.default)
++wrapped = self.config.get_value(section, key)
++return self.default if wrapped is None else wrapped.unpack()
+ 
+ def write(self, v):
+ section, key = self.__get_config_name()
+-return self.config.set_value(section, key, type(self.default)(v))
+-
++return self.config.set_value(section, key, self.__wrap(v))
+
+ def __get_config_name(self):
+ keys = self.name.rsplit(SEPARATOR ,1)
diff -Nru ibus-sunpinyin-2.0.3+git20181120/debian/patches/series ibus-
sunpinyin-2.0.3+git20181120/debian/patches/series
--- ibus-sunpinyin-2.0.3+git20181120/debian/patches/series  2018-11-20
15:37:17.0 -0500
+++ ibus-sunpinyin-2.0.3+git20181120/debian/patches/series  2019-06-11
13:40:02.0 -0400
@@ -1,2 +1,3 @@
 libexecdir.patch
 0003-setup-ibus-setup-sunpinyin.in-Use-python3-explicitly.patch
+0003-Fix-upstream-issue-85-the-config-value-is-glib.Varia.patch


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

Bug#916610: spacenavd: diff for NMU version 0.6-1.1

[sur5r]

Control: tags 916610 + pending


Dear maintainer,

I've prepared an NMU for spacenavd (versioned as 0.6-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru spacenavd-0.6/debian/changelog spacenavd-0.6/debian/changelog
--- spacenavd-0.6/debian/changelog  2015-05-18 10:04:05.0 +
+++ spacenavd-0.6/debian/changelog  2019-06-01 11:13:33.0 +
@@ -1,3 +1,11 @@
+spacenavd (0.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "conflict with /dev/input/js0" (Closes: #916610)
+- Fixed upstream in 34ddda1246ad07e8ff2e6606224e710852e3e3d8
+
+ -- Jakob Haufe   Sat, 01 Jun 2019 11:13:33 +
+
 spacenavd (0.6-1) unstable; urgency=medium
 
   * Imported Upstream version 0.6
diff -Nru spacenavd-0.6/debian/patches/series 
spacenavd-0.6/debian/patches/series
--- spacenavd-0.6/debian/patches/series 2015-05-18 10:04:05.0 +
+++ spacenavd-0.6/debian/patches/series 2019-06-01 11:04:55.0 +
@@ -1,2 +1,3 @@
 add-buildflags-to-makefile.patch
 run.patch
+skip-joystick-devices.patch
diff -Nru spacenavd-0.6/debian/patches/skip-joystick-devices.patch 
spacenavd-0.6/debian/patches/skip-joystick-devices.patch
--- spacenavd-0.6/debian/patches/skip-joystick-devices.patch1970-01-01 
00:00:00.0 +
+++ spacenavd-0.6/debian/patches/skip-joystick-devices.patch2019-06-01 
11:13:33.0 +
@@ -0,0 +1,37 @@
+Description: Skip joystick device files
+Author: John Tsiombikas 
+Origin: upstream, 
https://github.com/FreeSpacenav/spacenavd/commit/34ddda1246ad07e8ff2e6606224e710852e3e3d8
+Bug-Debian: https://bugs.debian.org/916610
+---
+commit 34ddda1246ad07e8ff2e6606224e710852e3e3d8
+Author: John Tsiombikas 
+Date:   Sat Oct 11 05:07:58 2014 +
+
+added code to skip joystick device files while parsing 
/proc/bus/input/devices
+
+
+git-svn-id: svn+ssh://svn.code.sf.net/p/spacenav/code/trunk/spacenavd@183 
ef983eb1-d774-4af8-acfd-baaf7b16a646
+
+diff --git a/src/dev_usb_linux.c b/src/dev_usb_linux.c
+index 30db579..5f4baad 100644
+--- a/src/dev_usb_linux.c
 b/src/dev_usb_linux.c
+@@ -342,11 +342,16 @@ struct usb_device_info *find_usb_devices(int 
(*match)(const struct usb_device_in
+   case 'H':
+   keyptr = strstr(cur_line, "Handlers=");
+   if(keyptr) {
+-  char *devfile, *valptr = keyptr 
+ strlen("Handlers=");
++  char *devfile = 0, *valptr = 
keyptr + strlen("Handlers=");
+   static const char *prefix = 
"/dev/input/";
+ 
+   int idx = 0;
+-  while((devfile = strtok(idx ? 0 
: valptr, " \t\v\n\r"))) {
++  while((devfile = strtok(devfile 
? 0 : valptr, " \t\v\n\r"))) {
++  if(strstr(devfile, 
"js") == devfile) {
++  /* ignore 
joystick device files, can't use them */
++  continue;
++  }
++
+   
if(!(devinfo.devfiles[idx] = malloc(strlen(devfile) + strlen(prefix) + 1))) {
+   perror("failed 
to allocate device filename buffer");
+   continue;

Bug#930385: RFP: container-diff -- Diff your Docker containers

[Varac]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: container-diff
  Version : latest
  Upstream Author : ?
* URL : https://github.com/GoogleContainerTools/container-diff
* License : Apache-2.0
  Programming Lang: Golang
  Description : Diff your Docker containers

container-diff is a tool for analyzing and comparing container images. 
container-diff can examine images along several different criteria, including:

* Docker Image History
* Image file system
* Image size
* Apt packages
* RPM packages
* pip packages
* npm packages

These analyses can be performed on a single image, or a diff can be performed 
on two images to compare. The tool can help users better understand what is 
changing inside their images, and give them a better look at what their images 
contain.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAlz/8rQQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBOFSD/96rJzU5vFyi370lXuc55RbWOrjx5rx/D+D
eQEY+k4+lTB87yf4VoXjM4YLNofQLIRxh3SUCIWqk0+jxllv/vp0J6iO4qa+rGwS
7LFGZ/ya4Wxaalc2KEupDkXB+upyUncnfI1id9t3stq4QmviFr5+K3GOxnx9kPf3
zknJuRbAycfze9+Xti6HLwgPwgL9FNgHV7hLkZirTG0uhfFyNgbDxwD0OPOdL4Nt
eNTq48ck65JY5LcUyaObnOoAYfvbre5kmyeG6H1oZ58OoKbnl++5QQ1QsfjNsjsR
J+9j6SnznGzcKL2SK/q21or3y09SNBtS6Rd9dD5XQ7DT49WKiRJ2FT+1wnbfEMpx
3k5FaA/eFrwLTD88MhHbhL2a8NIeTKM1ziIl2sSZ3XqE6MfFvcm0S52VmQ6pk6Hy
ZrO4CyDG/BNegFFEkgmGLrM1pH4y2VTJ6IrkboEH82RMZD89YzhFRDT0cLC7DD8B
1FxfX1pWuqUTbfE2ExUFoFzDh9Y+rx4cd5+lHopamfmhNmnu0ZRromng8DwphD6M
jZrpHze+a/fUFOEdKyDCB3lYIJsVZn+F/iVLkNt2Zuicq0Zphn3Dxt9C4lcPq0Oj
dTiJSFqXCR9p+F2CTUVzCDEFJ8TFNFy7yhLiCNWAMUb8Jh20dHo8yPoOMw9h3WCY
tS5HtDeOLw==
=2o2j
-END PGP SIGNATURE-

Bug#930386: hangs and connection resets w/ high thread count

[dann frazier]

Package: iperf
Version: 2.0.12+dfsg1-2
Severity: important
Tags: upstream patch

When attempting an iperf run with 24 threads, I either hit a
hang [*] or a bunch of "write failed: Connection reset by peer"
errors [**]. These are both resolved by the following upstream commit:

https://sourceforge.net/p/iperf2/code/ci/4565c2ce318318a8a1d4578bab78c0e03fb49437/

[*]
$ iperf -c 192.168.86.2 -P 24 
^C^Cconnect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
connect failed: Operation now in progress
^C^C^Z
[1]+  Stopped iperf -c 192.168.86.2 -P 24
$ bg
[1]+ iperf -c 192.168.86.2 -P 24 &
$ killall -9 iperf
$ fg
-bash: fg: job has terminated
[1]+  Killed  iperf -c 192.168.86.2 -P 24

[**]
$ iperf -c 192.168.86.2 -P 24 

Client connecting to 192.168.86.2, TCP port 5001
TCP window size: 85.0 KByte (default)

write failed: Connection reset by peer
write failed: Connection reset by peer
write failed: Connection reset by peer
write failed: Connection reset by peer
[ 21] local 192.168.86.1 port 47950 connected with 192.168.86.2 port 5001
[ ID] Interval   Transfer Bandwidth
[ 21]  0.0- 0.0 sec   107 KBytes  0.00 bits/sec
[ 16] local 192.168.86.1 port 47940 connected with 192.168.86.2 port 5001
[ 16]  0.0- 0.0 sec   107 KBytes  0.00 bits/sec
[  4] local 192.168.86.1 port 47914 connected with 192.168.86.2 port 5001
[  8] local 192.168.86.1 port 47918 connected with 192.168.86.2 port 5001
[  3] local 192.168.86.1 port 47916 connected with 192.168.86.2 port 5001
[  5] local 192.168.86.1 port 47920 connected with 192.168.86.2 port 5001
[  6] local 192.168.86.1 port 47922 connected with 192.168.86.2 port 5001
[  7] local 192.168.86.1 port 47924 connected with 192.168.86.2 port 5001
[ 22] local 192.168.86.1 port 47952 connected with 192.168.86.2 port 5001
[  9] local 192.168.86.1 port 47926 connected with 192.168.86.2 port 5001
[ 20] local 192.168.86.1 port 47948 connected with 192.168.86.2 port 5001
[ 26] local 192.168.86.1 port 47960 connected with 192.168.86.2 port 5001
[ 19] local 192.168.86.1 port 47946 connected with 192.168.86.2 port 5001
[ 15] local 192.168.86.1 port 47938 connected with 192.168.86.2 port 5001
[ 15]  0.0- 0.0 sec   107 KBytes  0.00 bits/sec
[ 10] local 192.168.86.1 port 47930 connected with 192.168.86.2 port 5001
[ 25] local 192.168.86.1 port 47958 connected with 192.168.86.2 port 5001
[ 12] local 192.168.86.1 port 47928 connected with 192.168.86.2 port 5001
[ 17] local 192.168.86.1 port 47944 connected with 192.168.86.2 port 5001
[ 14] local 192.168.86.1 port 47936 connected with 192.168.86.2 port 5001
[ 13] local 192.168.86.1 port 47934 connected with 192.168.86.2 port 5001
[ 11] local 192.168.86.1 port 47932 connected with 192.168.86.2 port 5001
[ 11]  0.0- 0.0 sec   107 KBytes  0.00 bits/sec
[ 24] local 192.168.86.1 port 47956 connected with 192.168.86.2 port 5001
[ 23] local 192.168.86.1 port 47954 connected with 192.168.86.2 port 5001
[ 18] local 192.168.86.1 port 47942 connected with 192.168.86.2 port 5001
write failed: Connection reset by peer
write failed: Connection reset by peer
[ 12]  0.0- 0.0 sec   107 KBytes  73.0 Mbits/sec
[ 18]  0.0- 0.0 sec   107 KBytes  73.3 Mbits/sec
[  4]  0.0-10.0 sec  4.19 GBytes  3.60 Gbits/sec
[  8]  0.0-10.0 sec  2.87 GBytes  2.47 Gbits/sec
[  3]  0.0-10.0 sec  2.04 GBytes  1.75 Gbits/sec
[  5]  0.0-10.0 sec  2.00 GBytes  1.72 Gbits/sec
[  6]  0.0-10.0 sec  2.71 GBytes  2.33 Gbits/sec
[  7]  0.0-10.0 sec  4.10 GBytes  3.52 Gbits/sec
[ 22]  0.0-10.0 sec  2.00 GBytes  1.72 Gbits/sec
[  9]  0.0-10.0 sec  2.71 GBytes  2.33 Gbits/sec
[ 20]  0.0-10.0 sec  2.82 GBytes  2.42 Gbits/sec
[ 26]  0.0-10.0 sec  2.71 GBytes  2.32 Gbits/sec
[ 19]  0.0-10.0 sec  4.58 GBytes  3.94 Gbits/sec
[ 10]  0.0-10.0 sec  2.92 GBytes  2.51 Gbits/sec
[ 25]  0.0-10.0 sec  4.15 GBytes  3.57 Gbits/sec
[ 17]  0.0-10.0 sec  2.74 GBytes  2.35 Gbits/sec
[ 14]  0.0-10.0 sec  2.78 GBytes  2.39 Gbits/sec
[ 13]  0.0-10.0 sec  2.00 GBytes  1.72 Gbits/sec
[ 24]  0.0-10.0 sec  2.81 GBytes  2.41 Gbits/sec
[ 23]  0.0-10.0 sec  4.13 GBytes  3.55 Gbits/sec
[SUM]  0.0-10.0 sec  54.3 GBytes  46.6 Gbits/sec


-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 

Bug#930387: rdekstop: security issues fixed in 1.8.5 and 1.8.6

[Salvatore Bonaccorso]

Source: rdesktop
Version: 1.8.4-1
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
Control: fixed -1 1.8.6-1

Hi

1.8.6-1 mentions a new upstream release with many security fixes, but
none of those apparently have (yet) a CVE. Filling this bug for having
an unique identifier for the tracker in meanwhile.

Reference: 
https://tracker.debian.org/news/1041036/accepted-rdesktop-186-1-source-into-unstable/

Regards,
Salvatore