Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci

[Andrea Palazzi]

Package: firmware-realtek
Version: 20190717-2
Followup-For: Bug #935969

Hi,

What's keeping this bug from being fixed, given that there's a patch available?
Is there something that I can do to help?

Also, shouldn't it be an important bug, since it makes unusable the wifi in
systems with boars using the rtw88 firmware?

Andrea Palazzi



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

Kernel: Linux 5.3.0-3-amd64 (SMP w/12 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.135

-- no debconf information
--- rules.gen.orig  2019-10-22 21:14:32.320024105 +0200
+++ rules.gen   2019-10-22 21:13:07.251925642 +0200
@@ -46,7 +46,7 @@
 binary-indep::
$(MAKE) -f debian/rules.real binary-indep 
FILES='cbfw-3.2.3.0.bin:cbfw-3.2.3.0.bin cbfw-3.2.5.1.bin:cbfw-3.2.5.1.bin 
ct2fw-3.2.3.0.bin:ct2fw-3.2.3.0.bin ct2fw-3.2.5.1.bin:ct2fw-3.2.5.1.bin 
ctfw-3.2.3.0.bin:ctfw-3.2.3.0.bin ctfw-3.2.5.1.bin:ctfw-3.2.5.1.bin 
qed/qed_init_values_zipped-8.10.10.0.bin:qed/qed_init_values_zipped-8.10.10.0.bin
 
qed/qed_init_values_zipped-8.33.1.0.bin:qed/qed_init_values_zipped-8.33.1.0.bin 
qed/qed_init_values_zipped-8.33.11.0.bin:qed/qed_init_values_zipped-8.33.11.0.bin
 
qed/qed_init_values_zipped-8.37.2.0.bin:qed/qed_init_values_zipped-8.37.2.0.bin 
qlogic/1040.bin:qlogic/1040.bin qlogic/1280.bin:qlogic/1280.bin 
qlogic/12160.bin:qlogic/12160.bin qlogic/sd7220.fw:qlogic/sd7220.fw 
ql2100_fw.bin:ql2100_fw.bin ql2200_fw.bin:ql2200_fw.bin 
ql2300_fw.bin:ql2300_fw.bin ql2322_fw.bin:ql2322_fw.bin 
ql2400_fw.bin:ql2400_fw.bin ql2500_fw.bin:ql2500_fw.bin' LINKS='' 
PACKAGE='qlogic'
 binary-indep::
-   $(MAKE) -f debian/rules.real binary-indep 
FILES='RTL8192E/boot.img:RTL8192E/boot.img RTL8192E/data.img:RTL8192E/data.img 
RTL8192E/main.img:RTL8192E/main.img 
rtl_bt/rtl8192ee_fw.bin:rtl_bt/rtl8192ee_fw.bin 
rtl_bt/rtl8812ae_fw.bin:rtl_bt/rtl8812ae_fw.bin 
rtl_bt/rtl8761a_fw.bin:rtl_bt/rtl8761a_fw.bin 
rtl_bt/rtl8821a_fw.bin:rtl_bt/rtl8821a_fw.bin 
rtl_bt/rtl8192eu_fw.bin:rtl_bt/rtl8192eu_fw.bin 
rtl_bt/rtl8723a_fw.bin:rtl_bt/rtl8723a_fw.bin 
rtl_bt/rtl8723b_fw.bin:rtl_bt/rtl8723b_fw.bin 
rtl_bt/rtl8723d_config.bin:rtl_bt/rtl8723d_config.bin 
rtl_bt/rtl8723d_fw.bin:rtl_bt/rtl8723d_fw.bin 
rtl_bt/rtl8821c_config.bin:rtl_bt/rtl8821c_config.bin 
rtl_bt/rtl8821c_fw.bin:rtl_bt/rtl8821c_fw.bin 
rtl_bt/rtl8822b_config.bin:rtl_bt/rtl8822b_config.bin 
rtl_bt/rtl8822b_fw.bin:rtl_bt/rtl8822b_fw.bin 
rtl_bt/rtl8822cu_fw.bin:rtl_bt/rtl8822cu_fw.bin 
rtl_nic/rtl8105e-1.fw:rtl_nic/rtl8105e-1.fw 
rtl_nic/rtl8106e-1.fw:rtl_nic/rtl8106e-1.fw 
rtl_nic/rtl8106e-2.fw:rtl_nic/rtl8106e-2.fw 
rtl_nic/rtl8107e-1.fw:rtl_nic/rtl8107e-1.fw 
rtl_nic/rtl8107e-2.fw:rtl_nic/rtl8107e-2.fw 
rtl_nic/rtl8168d-1.fw:rtl_nic/rtl8168d-1.fw 
rtl_nic/rtl8168d-2.fw:rtl_nic/rtl8168d-2.fw 
rtl_nic/rtl8168e-1.fw:rtl_nic/rtl8168e-1.fw 
rtl_nic/rtl8168e-2.fw:rtl_nic/rtl8168e-2.fw 
rtl_nic/rtl8168e-3.fw:rtl_nic/rtl8168e-3.fw 
rtl_nic/rtl8168f-1.fw:rtl_nic/rtl8168f-1.fw 
rtl_nic/rtl8168f-2.fw:rtl_nic/rtl8168f-2.fw 
rtl_nic/rtl8168g-1.fw:rtl_nic/rtl8168g-1.fw 
rtl_nic/rtl8168g-2.fw:rtl_nic/rtl8168g-2.fw 
rtl_nic/rtl8168g-3.fw:rtl_nic/rtl8168g-3.fw 
rtl_nic/rtl8168h-1.fw:rtl_nic/rtl8168h-1.fw 
rtl_nic/rtl8168h-2.fw:rtl_nic/rtl8168h-2.fw 
rtl_nic/rtl8402-1.fw:rtl_nic/rtl8402-1.fw 
rtl_nic/rtl8411-1.fw:rtl_nic/rtl8411-1.fw 
rtl_nic/rtl8411-2.fw:rtl_nic/rtl8411-2.fw 
rtlwifi/rtl8188efw.bin:rtlwifi/rtl8188efw.bin 
rtlwifi/rtl8188eufw.bin:rtlwifi/rtl8188eufw.bin 
rtlwifi/rtl8192cfw.bin:rtlwifi/rtl8192cfw.bin 
rtlwifi/rtl8192cfwU_B.bin:rtlwifi/rtl8192cfwU_B.bin 
rtlwifi/rtl8192cfwU.bin:rtlwifi/rtl8192cfwU.bin 
rtlwifi/rtl8192cufw_A.bin:rtlwifi/rtl8192cufw_A.bin 
rtlwifi/rtl8192cufw_B.bin:rtlwifi/rtl8192cufw_B.bin 
rtlwifi/rtl8192cufw_TMSC.bin:rtlwifi/rtl8192cufw_TMSC.bin 
rtlwifi/rtl8192cufw.bin:rtlwifi/rtl8192cufw.bin 
rtlwifi/rtl8192defw.bin:rtlwifi/rtl8192defw.bin 
rtlwifi/rtl8192eefw.bin:rtlwifi/rtl8192eefw.bin 
rtlwifi/rtl8192eu_nic.bin:rtlwifi/rtl8192eu_nic.bin 
rtlwifi/rtl8192eu_wowlan.bin:rtlwifi/rtl8192eu_wowlan.bin 
rtlwifi/rtl8192sefw.bin:rtlwifi/rtl8192sefw.bin 
rtlwifi/rtl8712u.bin:rtlwifi/rtl8712u.bin 
rtlwifi/rtl8723aufw_A.bin:rtlwifi/rtl8723aufw_A.bin 
rtlwifi/rtl8723aufw_B.bin:rtlwifi/rtl8723aufw_B.bin 
rtlwifi/rtl8723aufw_B_NoBT.bin:rtlwifi/rtl8723aufw_B_NoBT.bin 
rtlwifi/rtl8723befw_36.bin:rtlwifi/rtl8723befw_36.bin 
rtlwifi/rtl8723befw.bin:rtlwifi/rtl8723befw.bin 
rtlwifi/rtl8723bs_bt.bin:rtlwifi/rtl8723bs_bt.bin 

Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Bioconductor Package Maintainer 


Hi,

as you can read below S4Vectors segfaults in its test.  Here you can
find a complete test log

   
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-bioc-s4vectors/3725032/log.gz

which says in the end:

...
> S4Vectors:::.test()

 *** caught segfault ***
address 0x5586e27d4a60, cause 'invalid permissions'

Traceback:
 1: runmed(y, 7)
 2: runmed(y, 7)
 3: as.vector(target)
 4: mode(target)
 5: attr.all.equal(target, current, tolerance = tolerance, scale = scale, 
...)
 6: all.equal.numeric(as.vector(target), as.vector(current), tolerance = 
tolerance, ...)
 7: checkEqualsNumeric(runmed(y, 7), as.vector(runmed(Rle(y), 7)))
 8: func()
 9: system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest)
10: doTryCatch(return(expr), name, parentenv, handler)
11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
12: tryCatchList(expr, classes, parentenv, handlers)
13: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix <- 
paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
14: try(system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest))
15: .executeTestCase(funcName, envir = sandbox, setUpFunc = .setUp, 
tearDownFunc = .tearDown)
16: .sourceTestFile(testFile, testSuite$testFuncRegexp)
17: RUnit::runTestSuite(suite)
18: BiocGenerics:::testPackage("S4Vectors")
19: S4Vectors:::.test()
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault


Any idea how to fix this?

Kind regards

Andreas.

On Thu, Dec 19, 2019 at 11:51:03AM +0100, Sebastien Bacher wrote:
> Package: r-bioc-s4vectors
> Version: 0.24.1-1
> 
> The autopkgtest started failing on a segfault
> https://ci.debian.net/packages/r/r-bioc-s4vectors/unstable/amd64/
> 
> It seems to have started with the r-base update
> -r-base-core 3.6.1-7
> +r-base-core 3.6.1.20191206-1
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de

Bug#947001: IRanges segfaults after R was upgraded in Debian (Was: Bug#947001: Tests segfaults (since the r-base-core update?))

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Bioconductor Package Maintainer 


Hi,

as you can read below the test suite of IRanges in Debian started failing
after r-base-core was upgraded.  A complete build log can be found here

   
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-bioc-iranges/3717079/log.gz

which says at the end:

...
> IRanges:::.test()
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.

 *** caught segfault ***
address 0x55c0daa0aa60, cause 'invalid permissions'

Traceback:
 1: FUN(X[[i]], ...)
 2: FUN(X[[i]], ...)
 3: lapply(as.list(X), match.fun(FUN), ...)
 4: lapply(as.list(X), match.fun(FUN), ...)
 5: lapply(x, runmed, k = k, endrule = match.arg(endrule), algorithm = 
algorithm, print.level = print.level)
 6: lapply(x, runmed, k = k, endrule = match.arg(endrule), algorithm = 
algorithm, print.level = print.level)
 7: .dotargsAsList("numeric", ...)
 8: NumericList(lapply(x, runmed, k = k, endrule = match.arg(endrule), 
algorithm = algorithm, print.level = print.level), compress = FALSE)
 9: runmed(list3, 7)
10: runmed(list3, 7)
11: as.list(runmed(list3, 7))
12: checkIdentical(as.list(runmed(list3, 7)), lapply(list3, function(x) {y 
<- runmed(x, 7)if (type != "RleList") y <- as.vector(y)y}))
13: func()
14: system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest)
15: doTryCatch(return(expr), name, parentenv, handler)
16: tryCatchOne(expr, names, parentenv, handlers[[1L]])
17: tryCatchList(expr, classes, parentenv, handlers)
18: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix <- 
paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
19: try(system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest))
20: .executeTestCase(funcName, envir = sandbox, setUpFunc = .setUp, 
tearDownFunc = .tearDown)
21: .sourceTestFile(testFile, testSuite$testFuncRegexp)
22: RUnit::runTestSuite(suite)
23: BiocGenerics:::testPackage("IRanges")
24: IRanges:::.test()
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault


Any idea how to fix this?  BTW, there is a similar effect with
S4Vectors.  May be that's related.

Kind regards

   Andreas.



On Thu, Dec 19, 2019 at 11:23:18AM +0100, Sebastien Bacher wrote:
> Package: r-bioc-iranges
> Version: 2.20.1-1
> 
> The autopkgtest started failing on a segfault
> https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
> 
> It seems to have started with the r-base update
> -r-base-core 3.6.1-7
> +r-base-core 3.6.1.20191206-1
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de

Bug#946255: dwz: returns exit status 1, causing FTBFS in deal.ii

[Graham Inggs]

Control: severity -1 serious
Control: tags -1 + pending
Control: block -1 by 944688

Fixed in git, waiting on #944688 in Trilinos which requires a trip through NEW.

Bug#947158: systemd: After=network.target is ineffective

[Paul Szabo]

Package: systemd
Version: 241-7~deb10u2
Severity: normal
Tags: patch

Lately (since buster?) I observe that "After=network.target" is ineffective,
maybe because dhcpcd runs asynchronously. I seem to get good results by
creating a file

  /etc/network/if-up.d/00waitup

with contents as below.


Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


Contents of /etc/network/if-up.d/00waitup :

#!/bin/bash -

#V0.1  22 Dec 19  wait for (ensure) interface is up
# Paul Szabo   p...@maths.usyd.edu.au

# Ensure network interface is "up".
# DHCP may take long... and at buster it seems to be done asynchronously,
# so systemd "After=network.target" is ineffective.

# Though neither we, nor any commands we run, should ever fail or
# show anything on STDERR: ensure we do not, otherwise ifup may think
# we failed, and fail the interface. 
exec 2>&1

case "$IFACE" in
  eth* ) echo -E "00waitup: Waiting for $IFACE to be up ...";;
  * ) echo -E "00waitup: No waiting for $IFACE"; exit;;
esac

n=0
while :; do
  LINE="$(ip -o address show $IFACE)"
  if [ -n "$LINE" ] ; then
echo -E "00waitup: $IFACE is up, 'ip -o address show $IFACE' shows '$LINE'"
exit
  fi
  (( n = $n+1 ))
  if [ $n -gt 60 ]; then
echo -E "00waitup: 'ip -o address show $IFACE' failed, seems down, giving 
up"
exit
  fi
  echo -n -E "00waitup: Waiting for $IFACE to come up at "; date
  sleep 1
done

Bug#943786: lmfit-py: failing tests with python3.8

[Andreas Tille]

Hi Alexandre,

since you previously did some commits fixing a RC bug:  It would help if
you make some noise on the Debian Science list to get the fix sponsored.
May be it was not the best idea of mine to bump to the new upstream
version since it created new trouble.  If you have some idea how to fix
it, please commit and ping me.

Kind regards
Andreas.

On Sat, Dec 21, 2019 at 11:30:02PM +0100, Andreas Tille wrote:
> Hi,
> 
> I tried hard to get lmfit-py (now at upstream version 1.0.0) building
> but I endet up with 
> 
> 
> build succeeded, 73 warnings.
> 
> The HTML pages are in build/html.
> 
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py", line 
> 313, in sumarize_failing_examples
> "\n" + "-" * 79)
> ValueError: Here is a summary of the problems encountered when running the 
> examples
> 
> Examples expected to fail, but not failing:
> Please remove these examples from
> sphinx_gallery_conf['expected_failing_examples']
> /build/lmfit-py-1.0.0/examples/documentation/model_loadmodel.py
> 
> 
> 
> The full sphinx log says:
> 
> 
> # Sphinx version: 1.8.5
> # Python version: 3.7.6 (CPython)
> # Docutils version: 0.15.2 release
> # Jinja2 version: 2.10.1
> # Last messages:
> #   done
> #   copying extra files...
> #   done
> #   dumping search index in English (code: en) ...
> #   done
> #   dumping object inventory...
> #   done
> #   build succeeded, 73 warnings.
> #...
> #   The HTML pages are in build/html.
> # Loaded extensions:
> #   sphinx.ext.mathjax (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
> #   alabaster (0.7.8) from 
> /usr/lib/python3/dist-packages/alabaster/__init__.py
> #   sphinx.ext.autodoc (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/autodoc/__init__.py
> #   sphinx.ext.extlinks (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/extlinks.py
> #   sphinx.ext.intersphinx (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py
> #   sphinx.ext.napoleon (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/napoleon/__init__.py
> #   sphinx.ext.todo (1.8.5) from 
> /usr/lib/python3/dist-packages/sphinx/ext/todo.py
> #   IPython.sphinxext.ipython_console_highlighting (unknown version) from 
> /usr/lib/python3/dist-packages/IPython/sphinxext/ipython_console_highlighting.py
> #   sphinx_gallery.gen_gallery (0.2.0) from 
> /usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 304, in 
> build_main
> app.build(args.force_all, filenames)
>   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 369, in 
> build
> self.emit('build-finished', None)
>   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 510, in 
> emit
> return self.events.emit(event, self, *args)
>   File "/usr/lib/python3/dist-packages/sphinx/events.py", line 80, in emit
> results.append(callback(*args))
>   File "/usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py", line 
> 313, in sumarize_failing_examples
> "\n" + "-" * 79)
> ValueError: Here is a summary of the problems encountered when running the 
> examples
> 
> Examples expected to fail, but not failing:
> Please remove these examples from
> sphinx_gallery_conf['expected_failing_examples']
> /build/lmfit-py-1.0.0/examples/documentation/model_loadmodel.py
> ---
> 
> 
> 
> Any idea how to fix this?
> 
> 
> Kind regards
> 
>Andreas.
> 
> 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#947157: adequate reports broken-symlinks for supervise

[shirish शिरीष]

Package: tor
Version: 0.4.2.5-1
Severity: normal
Usertags: broken-symlink adequate

Dear all,
Adequate informed me of the broken symlinks while upgrading tor.

shirish@debian:"22 Dec 2019 10:36:52" ~$ adequate tor
tor: broken-symlink /etc/sv/tor/log/supervise -> /run/runit/supervise/tor.log
tor: broken-symlink /etc/sv/tor/supervise -> /run/runit/supervise/tor

Please fix the same.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.29-3
ii  libcap2 1:2.27-1
ii  libevent-2.1-7  2.1.11-stable-1
ii  liblzma55.2.4-1+b1
ii  libseccomp2 2.4.2-2
ii  libssl1.1   1.1.1d-2
ii  libsystemd0 244-3
ii  libzstd11.4.4+dfsg-1
ii  lsb-base11.1.0
ii  runit-helper2.8.14
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages tor recommends:
ii  logrotate3.15.1-2
ii  tor-geoipdb  0.4.2.5-1
ii  torsocks 2.3.0-2+b1

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
ii  obfs4proxy   0.0.8-1
ii  socat1.7.3.3-2
pn  tor-arm  
ii  torbrowser-launcher  0.3.2-4

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#947156: ceph: Please omit ceph server packages on Ubuntu/i386

[Steve Langasek]

Package: ceph
Version: 12.2.11+dfsg1-2.2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64.  We are keeping ceph on i386 because it
is a build-dependency of samba, but the various ceph server packages built
from this source package have dependencies on other packages that are not
being kept as part of the compatibility library set.

We would like to drop these various binary packages rather than keeping them
around in the Ubuntu archive and uninstallable.  Would you please consider
applying the attached patch, or something like it, to omit building this
binary package on Ubuntu?

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ceph-12.2.11+dfsg1/debian/rules ceph-12.2.11+dfsg1/debian/rules
--- ceph-12.2.11+dfsg1/debian/rules 2019-04-05 08:12:52.0 -0500
+++ ceph-12.2.11+dfsg1/debian/rules 2019-12-21 22:43:03.0 -0600
@@ -27,6 +27,10 @@
 
 export DEB_HOST_ARCH  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
+ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
+   skip_packages = -Nceph -Nceph-base -Nceph-mds -Nceph-mgr -Nceph-mon 
-Nceph-osd
+endif
+
 export JAVA_HOME=/usr/lib/jvm/default-java
 ## Set JAVAC to prevent FTBFS due to incorrect use of 'gcj' if found (see 
"m4/ac_prog_javac.m4").
 export JAVAC=javac
@@ -189,4 +193,10 @@
 --exclude=src/erasure-code/jerasure/jerasure/makefile.orig \
 etc/sysctl/90-ceph-osd.conf
 
+override_dh_builddeb:
+   dh_builddeb ${skip_packages}
+
+override_dh_gencontrol:
+   dh_gencontrol ${skip_packages}
+
 .PHONY: override_dh_auto_configure override_dh_installinit 
override_dh_makeshlibs override_dh_auto_test override_dh_missing

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

[Ross Vandegrift]

Hi Felix,

I forgot all about this, thanks for following up.

On Sat, Dec 14, 2019 at 02:15:41PM -0800, Felix Lechner wrote:
> $ fgrep -- -5 dir2/symbols
>  
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
> 1.21.1-5+b1
> 
> The symbol shows a Debian revision. Lintian is right.

Aha - I was searching the symbols file from the source package.  Now I see that
the binary package's symbols file is not necessarily the same.  Sorry for the
mistake.

> As a side note, I was surprised to find 188 additional Debian revisions:

These are intentional (and have overrides).  See "Note on eolian-generated
symbols" in README.source if you're curious.

> Finally, I am not sure why some symbols were decoded properly using
> the appropriate pattern [1], while the offender is raw 'c++'. Did you
> mix C and C++ symbols in the same shared library?

Yes, by accident - libephysics uses a c++ library, and was leaking this c++
symbol.  Looks like gcc8 -O2 inlined this function, while gcc9 doesn't until
-O3.

Ross

Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile

[Norbert Preining]

Hi Hilmar,

On Sat, 21 Dec 2019, Hilmar Preuße wrote:
> hille@sid:~ $ apt-file search fourier-orns.sty
> texlive-fonts-extra:
> /usr/share/texlive/texmf-dist/tex/latex/fourier/fourier-orns.sty
> 
> Fix your installation!! ;-)

The OP already mentioned that this file is present in his installation,
so it is unclear why it wasn't found.

Best

Norbert

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

Bug#938840: xcffib: Python2 removal in sid/bullseye

[peter green]

I just tried removing the build-dependency on python-autopep8 and other than 
file date changes, there did not seem to be any changes in the resulting 
packagse, so I decided to go ahead with a NMU.

While preparing the NMU I noticed that the clean target was not cleaning up 
properly, so I fixed that too.

Debdiff is attached, NMU is in delayed/5.

diff -Nru xcffib-0.8.1/debian/changelog xcffib-0.8.1/debian/changelog
--- xcffib-0.8.1/debian/changelog   2019-09-07 09:47:56.0 +
+++ xcffib-0.8.1/debian/changelog   2019-12-22 01:57:12.0 +
@@ -1,3 +1,11 @@
+xcffib (0.8.1-0.6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-depends on python-autopep8 (downgrades: 938840)
+  * Fix clean target.
+
+ -- Peter Michael Green   Sun, 22 Dec 2019 01:57:12 +
+
 xcffib (0.8.1-0.5) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru xcffib-0.8.1/debian/control xcffib-0.8.1/debian/control
--- xcffib-0.8.1/debian/control 2019-07-26 07:27:42.0 +
+++ xcffib-0.8.1/debian/control 2019-12-22 01:57:02.0 +
@@ -22,7 +22,6 @@
   , libghc-either-dev
   , python-setuptools
   , python3-setuptools
-  , python-autopep8
   , python-all
   , python3-all
   , python-cffi
diff -Nru xcffib-0.8.1/debian/rules xcffib-0.8.1/debian/rules
--- xcffib-0.8.1/debian/rules   2019-09-07 09:47:56.0 +
+++ xcffib-0.8.1/debian/rules   2019-12-22 01:57:12.0 +
@@ -10,6 +10,8 @@
 # we can't use setup.py clean here, since it checks for the existence of 
xcffib/
 override_dh_auto_clean:
make clean
+   rm -rf debian/cabalconfig
+   rm -rf .ghc.environment.*
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild

Bug#946874: llvm-toolchain-9: please include upstream patch D71028 for rust mips tests

[YunQiang Su]

On Fri, 20 Dec 2019 18:34:49 + Ximin Luo  wrote:
> Hi, James Clarke tells me to replace Register with unsigned, which also gets 
> rid of the fuzz factor in that patch. Please see the new one, attached.

I confirmed that this patch works.
I just finished building rustc 1.39 with patched llvm-9.

>
> X
>
> Sylvestre Ledru:
> >
> > Le 16/12/2019 à 23:31, Ximin Luo a écrit :
> >> Source: llvm-toolchain-9
> >> Severity: normal
> >> Tags: patch upstream
> >>
> >> Dear Maintainer,
> >>
> >> Please include this upstream patch which is already merged: 
> >> https://reviews.llvm.org/D71028
> >>
> >> It is needed for rustc mips to pass 
> >> https://github.com/rust-lang/rust/issues/67167
> >>
> >> I have confirmed that the raw diff applies cleanly to the current Debian 
> >> package.
> >>
> >> https://reviews.llvm.org/file/data/62pyj4rca74lyduv2gkr/PHID-FILE-267qlycncoogjurgx7hc/D71028.diff
> >>
> >> (It does not apply cleanly to llvm-8, only 9 and upwards.)
> >
> > And it fails with:
> >
> > /build/llvm-toolchain-9-9.0.1/llvm/lib/Target/Mips/MipsExpandPseudo.cpp: In 
> > member function 'bool 
> > {anonymous}::MipsExpandPseudo::expandAtomicBinOp(llvm::MachineBasicBlock&, 
> > llvm::MachineBasicBlock::iterator, llvm::MachineBasicBlock::iterator&, 
> > unsigned int)':
> > /build/llvm-toolchain-9-9.0.1/llvm/lib/Target/Mips/MipsExpandPseudo.cpp:740:21:
> >  error: operands to ?: have different types 'unsigned int' and 
> > 'llvm::Register'
> >  (Size == 8) ? STI->getRegisterInfo()->getSubReg(Scratch2, 
> > Mips::sub_32)
> > ^~~
> >  : Scratch2;
> >  ~~
> >
> >
> > S
> >
> >
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git

Bug#946083: buster-pu: package opensmtpd/6.0.3p1-5

[Ryan Kavanagh]

Hi,

On Sun, Dec 08, 2019 at 08:43:17PM +, Adam D. Barratt wrote:
> Why is the dpkg-statoverride call using --force-all? It should only be
> executing if no existing override exists, unless I'm missing something.

You're right, it should not be used and I've dropped it from the patch.
In the process, I discovered another bug (the statoverride needs to be
removed before the group at purge time), which has since been fixed in
unstable. I've attached a revised debdiff.

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
diff --git a/debian/NEWS b/debian/NEWS
index c4355207..74cfa9e9 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,28 @@
+opensmtpd (6.0.3p1-5+b10u1) buster; urgency=medium
+
+There have been changes to the smtpd.conf file format[0] which may
+require manual editing of your /etc/smtpd.conf file. Full details
+may be found in the man page smtpd.conf(5). Quoting from the
+"OpenBSD Upgrade Guide: 6.1 to 6.2" [0]:
+
+The "secure" keyword is not valid anymore in "listen" directives
+in smtpd.conf(5). Users are advised to replace existing
+"listen secure" directives with two separate "tls" and "smtps"
+listeners, i.e., a line like
+
+   listen on $iface secure pki $pki
+
+has to be replaced with
+
+listen on $iface tls pki $pki
+listen on $iface smtps pki $pki
+
+Relaying syntax is not affected by this change.
+
+[0] https://www.openbsd.org/faq/upgrade62.html
+
+ -- Ryan Kavanagh   Tue, 03 Dec 2019 12:11:02 -0500
+
 opensmtpd (5.4.1p1-1) unstable; urgency=medium
 
 There have been minor changes to the smtpd.conf file format[0] which
diff --git a/debian/changelog b/debian/changelog
index 0d54bf3b..92daa76e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opensmtpd (6.0.3p1-5+b10u1) buster; urgency=medium
+
+  * Warn users of change of smtpd.conf syntax (Closes: #944268)
+  * Install smtpctl setgid opensmtpq (Closes: #945910)
+
+ -- Ryan Kavanagh   Sat, 21 Dec 2019 17:41:55 -0500
+
 opensmtpd (6.0.3p1-5) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --git a/debian/control b/debian/control
index 155615d5..231817fb 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper (>= 11)
  , zlib1g-dev
 Standards-Version: 4.3.0
 Homepage: https://www.opensmtpd.org/
-Vcs-Git: https://salsa.debian.org/debian/opensmtpd.git -b debian/sid
+Vcs-Git: https://salsa.debian.org/debian/opensmtpd.git -b debian/buster
 Vcs-Browser: https://salsa.debian.org/debian/opensmtpd
 
 Package: opensmtpd
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 9d1db0e4..f8489f25 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 upstream-branch = upstream
-debian-branch = debian/sid
+debian-branch = debian/buster
 pristine-tar = True
 sign-tags = True
diff --git a/debian/postinst b/debian/postinst
index 9d7c9870..22dc979a 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -175,6 +175,13 @@ case "$1" in
 --no-create-home --disabled-password \
 --gecos "OpenSMTD queue user" \
 --ingroup opensmtpq opensmtpq
+# smtpctl needs to be setgid opensmtpq per
+# https://github.com/OpenSMTPD/OpenSMTPD/commit/8bdce604
+if ! dpkg-statoverride --list --quiet "/usr/sbin/smtpctl" >/dev/null;
+then
+dpkg-statoverride --quiet --update \
+--add root opensmtpq 2755 "/usr/sbin/smtpctl"
+fi
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure|reconfigure)
diff --git a/debian/postrm b/debian/postrm
index 3e9dd07f..b0452774 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -5,6 +5,18 @@ set -e
 case "$1" in
 purge)
rm -rf /var/spool/smtpd
+# Remove the statoverride before the opensmtpq group.
+# Otherwise, if users attempt to install the package after
+# a purge, dpkg will abort with:
+# > dpkg: unrecoverable fatal error, aborting:
+# >  unknown system group 'opensmtpq' in statoverride file; the system
+# > group got removed before the override, which is most probably a
+# > packaging bug, to recover you can remove the override manually with
+# > dpkg-statoverride
+if dpkg-statoverride --list --quiet "/usr/sbin/smtpctl" >/dev/null;
+then
+dpkg-statoverride --quiet --remove "/usr/sbin/smtpctl"
+fi
 for name in opensmtpd opensmtpq; do
 # By debian Policy §6.5, we may only rely on essential packages and
 # must fail gracefully if they are unavailable.


signature.asc
Description: PGP signature

Bug#937834: python-iniparse: Python2 removal in sid/bullseye

[Stuart Prescott]

Control: tags -1 pending

I've prepared an upload for this package and made a MR on salsa with the 
relevant changes.

https://salsa.debian.org/debian/python-iniparse/merge_requests/1

I'll upload this once #936346 is fixed.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#876107: Patch

[João Paulo Just Peixoto]

This also happens to me. Fixed by using str() function in some strings.
I am attaching my patch to this message.

-- 
Prof. M.Sc. João Paulo Just Peixoto
IFBA - Instituto Federal da Bahia - Campus Valença
--
TIM/WhatsApp: +55 75 9176 8499
Blog: http://just.pro.br/
--- avahi-discover	2019-12-21 22:47:11.422497727 -0300
+++ avahi-discover.new	2019-12-21 22:46:39.370583958 -0300
@@ -243,7 +243,7 @@
 infos += "" + _("Domain Name:") + " %s\n"
 infos += "" + _("Interface:") + " %s %s\n"
 infos += "" + _("Address:") + " %s/%s:%i\n%s"
-infos = infos % (stype, name, domain, self.siocgifname(interface), self.protoname(protocol), host, address, port, txts.strip())
+infos = infos % (str(stype), str(name), str(domain), str(self.siocgifname(interface)), self.protoname(protocol), str(host), str(address), port, txts.strip())
 self.info_label.set_markup(infos)
 
 def insert_row(self, model,parent,


signature.asc
Description: OpenPGP digital signature

Bug#705143: ltsp-server-standalone: LTSP client graphics severely corrupt with Cinnamon 2D desktop

[Vagrant Cascadian]

Version: 19.11-1

On 2014-10-19, Vagrant Cascadian wrote:
> On 2014-01-05, Vagrant Cascadian wrote:
>> On Wed, Apr 10, 2013 at 05:36:21PM +0200, Peter Tuharsky wrote:
>>> When used directly on the server, the Cinnamon 2D works fine. Moreover, I
>>> installed one of the thin clients with Debian Wheezy, effectively making it 
>>> a
>>> thick client (other words, a standalone desktop PC), and the Cinnamon 2D 
>>> works
>>> fine. However booting the machine as LTSP thin client again, screen 
>>> corrupted
>>> in Cinnamon 2D.
>>> 
>>> Please, are there any hints, what can I try to make it work?
>>
>> This is a bit of a long shot, but try setting in lts.conf:
>>
>>   X_SMART_COLOR_DEPTH=false
>>
>> or
>>
>>   X_COLOR_DEPTH=24
>>
>> It may be issues with 16-bit color depth, which is the default for thin 
>> clients
>> unless specified. Although it sounds like your issues may be a bit more
>> severe...
>
> Sounds like these workarounds resolved the issue, in the long term we
> might consider just using the default color depth, though that
> significantly increases the network bandwidth used...

Recent versions fo LTSP use the default color depth, and do not support
thin clients.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#947154: ITS: yubioath-desktop due to lack of activity

[Taowa Munene-Tardif]

Package: yubioath-desktop
Severity: important
X-Debbugs-CC: si...@josefsson.org
X-Debbugs-CC: k...@yubico.com
X-Debbugs-CC: d...@yubico.com
X-Debbugs-CC: d...@yubico.com
X-Debbugs-CC: pkg-auth-maintain...@lists.alioth.debian.org

Hello,

As per [0] and the removal from unstable, I intend to salvage the
package yubioath-desktop. Should anyone object, please let me know. 

[0] https://github.com/Yubico/yubioath-desktop/issues/328#issuecomment-513132914

Taowa

-- 
Taowa Munene-Tardif
taowa@deb{ian,conf}.org
taowa.ca
Montréal



signature.asc
Description: PGP signature

Bug#947153: RFS: htmldoc/1.9.7-1 [QA] ]RC] [CVE]?-- HTML processor that generates indexed HTML, PS, and PDF

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : htmldoc
Version : 1.9.7-1
Upstream Author : Michael R Sweet michael.r.sw...@gmail.com
* URL : https://www.msweet.org/htmldoc/
* License : GPL-2
* Vcs : None
Section : web

It builds those binary packages:

htmldoc - HTML processor that generates indexed HTML, PS, and PDF
htmldoc-common - Common arch-independent files for htmldoc

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.7-1.dsc


Changes since the last upload:

* QA upload
* New upstream version 1.9.7
* Add patch to fix a buffer underflow issue with GCC on Linux.
- Fixes: CVE-2019-19630
* Change debian/compat to debhelper-compat
* Update Standards-Version to 4.4.1
* Update patches
* Bump dh to 12

Regards,

Bug#947152: RFS: htmldoc/1.9.7-1 -- HTML processor that generates indexed HTML, PS, and PDF

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : htmldoc
Version : 1.9.7-1
Upstream Author : Michael R Sweet michael.r.sw...@gmail.com
* URL : https://www.msweet.org/htmldoc/
* License : GPL-2
* Vcs : None
Section : web

It builds those binary packages:

htmldoc - HTML processor that generates indexed HTML, PS, and PDF
htmldoc-common - Common arch-independent files for htmldoc

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.7-1.dsc


Changes since the last upload:

* QA upload
* New upstream version 1.9.7
* Add patch to fix a buffer underflow issue with GCC on Linux.
- Fixes: CVE-2019-19630
* Change debian/compat to debhelper-compat
* Update Standards-Version to 4.4.1
* Update patches
* Bump dh to 12

Regards,
Håvard

Bug#946819: atril 1.20.3-1+deb10u1 flagged for acceptance

[Adam D. Barratt]

On Sun, 2019-12-22 at 00:03 +, Mike Gabriel wrote:
> Hi Adam,
> 
> Am Samstag, 21. Dezember 2019 schrieb Adam D Barratt:
> > package release.debian.org
> > tags 946819 = buster pending
> > thanks
> > 
> > Hi,
> > 
> > The upload referenced by this bug report has been flagged for
> > acceptance into the proposed-updates queue for Debian buster.
> > 
> > Thanks for your contribution!
> > 
> > Upload details
> > ==
> > 
> > Package: atril
> > Version: 1.20.3-1+deb10u1
> > 
> > Explanation: fix segfault when no documentation is needed; fix read
> > of uninitialised memory [CVE-2019-11459]
> > 
> 
> The first should be: fux segfault when no document is loaded

Fixed, although using "fix". ;-)

Regards,

Adam

Bug#947147: RFS: wavbreaker/0.13-1 -- tool to split wave files into multiple chunks

[Adam Borowski]

On Sun, Dec 22, 2019 at 12:06:35AM +0100, Dennis Braun wrote:
> I am looking for a sponsor for my package "wavbreaker"
 ^^
> 
>  * Package name: wavbreaker
>Version : 0.13-1

> Changes since the last upload:
> 
>* New upstream release
>* debian/control:
>  + Build-Depends: Add cmake, meson, libao-dev and libmpg123-dev
>  + Build-Depends: Replace libgtk2.0-dev with libgtk-3-dev
>* debian/copyright: Rewrite and update
>* debian/docs: Replace README with README.md and drop NEWS
>* debian/patches:
>  + 0001-Fix-format-not-a-string-literal-errors.patch: Drop, obsolete
>  + 0002-Add-F-to-Exec.patch: Update
>  + 0003-Disable-Moodbar-Support.patch: Add
>* debian/watch: Update for github releases

Hi!
The update looks fine wrt its contents.  But, parts of our infrastructure
that care about maintainers would think this is a non-maintainer upload.
You're neither one of Uploaders, nor have marked this as "Team upload".

Thus, please do one of the above, to have this version recognized as a
regular upload.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#946819: atril 1.20.3-1+deb10u1 flagged for acceptance

[Mike Gabriel]

Hi Adam,

Am Samstag, 21. Dezember 2019 schrieb Adam D Barratt:
> package release.debian.org
> tags 946819 = buster pending
> thanks
> 
> Hi,
> 
> The upload referenced by this bug report has been flagged for acceptance into 
> the proposed-updates queue for Debian buster.
> 
> Thanks for your contribution!
> 
> Upload details
> ==
> 
> Package: atril
> Version: 1.20.3-1+deb10u1
> 
> Explanation: fix segfault when no documentation is needed; fix read of 
> uninitialised memory [CVE-2019-11459]
>

The first should be: fux segfault when no document is loaded

Mike

-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Bug#947150: virtinst: virt-clone is unable to clone guest with disk on lvm volume, due to undeclared variable "need" in diskbackend.py in function is_size_conflict

[Kristian Kallenberg]

Package: virtinst
Version: 1:2.0.0-3
Severity: normal

Dear Maintainer,

I have upgraded virtinst from 1.4.0-5. Once done virt-clone fails with an error 
about an undeclared variable. This is happening in 
/usr/share/virt-manager/virtinst/diskbackend.py line 534. If i am cloning a 
guest with its disk on a LVM volume then the variable "need" is not set.

def is_size_conflict(self):
ret = False
msg = None
->  if self.get_dev_type() == "block":
avail = _stat_disk(self._path)[1]
else:
vfs = os.statvfs(os.path.dirname(self._path))
avail = vfs.f_frsize * vfs.f_bavail
need = int(self._size) * 1024 * 1024 * 1024
if need > avail:

...

I found this, but am not versed in python yet, sorry.

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

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

Versions of packages virtinst depends on:
ii  e2fsprogs 1.44.5-1+deb10u2
ii  genisoimage   9:1.1.11-3+b2
ii  gir1.2-libosinfo-1.0  1.2.0-1
ii  python3   3.7.3-1
ii  python3-distutils 3.7.3-1
ii  python3-gi3.30.4-1
ii  python3-libvirt   5.0.0-1
ii  python3-libxml2   2.9.4+dfsg1-7+b3
ii  python3-requests  2.21.0-1

Versions of packages virtinst recommends:
ii  qemu-utils   1:3.1+dfsg-8+deb10u3
ii  virt-viewer  7.0-2

virtinst suggests no packages.

-- no debconf information

Bug#861053:

[Joshua Hudson]

The problem is /boot/grub/grub.cfg contains lines that look like:

  search --no-floppy --fs-uuid --set=root  
d847c628-aa10-4bef-92b6-72ebacc07d7b

search doesn't work because it starts the protected mode driver, which
finds multiple copies of the disk (because it's a full-disk RAID
array), selects one of them to try to use, and access it. Besides the
fact that this won't work very well if one of the disks were to
develop bad sectors, this is wrong because grub will later write to
the environment block, which resets the NVRAM flip-flop, causing the
automatic RAID resync to not work anymore.

The solution is to specify the device (hd0,1) explicitly everywhere
and never use any search directive anywhere in the config file. Device
hd0 uses bios 0x13 calls to access the disk, allowing the boot-time
RAID driver to do its job until the kernel is loaded.

Bug#944062: yapsy: diff for NMU version 1.12.0-1.2

[Sandro Tosi]

Control: tags 944062 + patch


Dear maintainer,

I've prepared an NMU for yapsy (versioned as 1.12.0-1.2). The diff
is attached to this message.

Regards.

diff -Nru yapsy-1.12.0/debian/changelog yapsy-1.12.0/debian/changelog
--- yapsy-1.12.0/debian/changelog	2019-10-14 20:47:33.0 -0400
+++ yapsy-1.12.0/debian/changelog	2019-12-21 18:27:42.0 -0500
@@ -1,3 +1,11 @@
+yapsy (1.12.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/unittests
+- drop python2 tests, needed to reach testing; Closes: #944062
+
+ -- Sandro Tosi   Sat, 21 Dec 2019 18:27:42 -0500
+
 yapsy (1.12.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yapsy-1.12.0/debian/tests/unittests yapsy-1.12.0/debian/tests/unittests
--- yapsy-1.12.0/debian/tests/unittests	2018-09-29 10:28:36.0 -0400
+++ yapsy-1.12.0/debian/tests/unittests	2019-12-21 18:27:06.0 -0500
@@ -1,2 +1 @@
 python3 runtests.py
-python runtests.py

Bug#710440: scrypt bug can be closed

[Graham Percival]

Hi,

Now that libscrypt-kdf-dev has been in the repositories for a few months, I
think it's safe to close this "wishlist for -dev package" report.

Cheers,
- Graham

Bug#861053:

[Joshua Hudson]

So the real problem is grub.cfg contains lines that look like this:

  search --no-floppy --fs-uuid --set=root  
d847c628-aa10-4bef-92b6-72ebacc07d7b

The probe tries to activate builtin protected-mode drivers, and the
drivers "work", so the probe finds two paths to the disk. Both of them
are wrong. In fact this error would be harmless, except for grub will
later write to the disk (the grub environment block). This desyncs the
RAID array.

The correct solution is to explicitly specify the driver is to be used.

Bug#947105: puppet: Default install uses outdated configuration file and directory locations

[Louis-Philippe Véronneau]

On Fri, 20 Dec 2019 21:46:05 -0500 "Todd H. Poole"
 wrote:
> Package: puppet
> Version: 5.5.10-4
> Severity: important
> 
> In early 2015, upstream Puppet changed the location of several core config 
> files and directories with the release of Puppet 4.0. Today, almost 5 years 
> later, a default install of Puppet 5.5 on Debian 10 still uses those old 
> config file and directory locations.
> 
> For example, per Debian's Puppet man page[1], the upstream Puppet docs[2], 
> and innumerable web search results, the default config directory ("confdir") 
> for Puppet should be /etc/puppetlabs/puppet/, but in Puppet 5.5.10-4 on 
> Debian 10, it's still /etc/puppet/.
> 
> Similar issues exist for all other config file and directory locations 
> changed in Puppet 4.0[3].
> 
> Although not package-breaking, inconsistencies like these present usability 
> problems for those coming from other distributions or for those who were 
> previously using Puppet's official open source packages.
> 
> Could a Maintainer update the Debian Puppet package so that Puppet's behavior 
> on Debian matches the documented behavior in the man pages, upstream docs, 
> and upstream packages?
> 
> [1] https://manpages.debian.org/buster/puppet/puppet.conf.5.en.html
> [2] https://puppet.com/docs/puppet/5.5/dirs_confdir.html
> [3] https://puppet.com/docs/puppet/5.5/whered_it_go.html
> 
> Thank you,
> Todd H. Poole

Although I'm not a maintainer for this package, I respectfully disagree
with you on this.

First of all, I feel the severity level for this bug is too high. In my
opinion, this should be downgraded to a wishlist bug, as the current
behavior does not break anything nor induces any critical vulnerability.

I also don't think the current default configuration directory should be
changed. There are a bunch of things the Debian puppet package does
differently then upstream, for a bunch of reasons.

For example, we are not installing Puppet in /opt/puppetlabs, because
that's not the Debian way of doing things.

I feel /etc/puppet minimizes breakage when upgrading to newer versions
of Puppet, is clearer than /etc/puppetlabs/puppet and is quicker to
type. I'd be sad if we moved away from that.

The man page not being consistent with the current Debian behavior
should be filed as a separate bug, as I think this should indeed be
fixed :). If you do that, I'll be happy to send a patch to make it so.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#946422: silx: autopkgtest regression: pocl error

[Andreas Beckmann]

Control: severity -1 important

I've now filed #947148 against openmpi 4 which seems to break lt_dlopen()

Andreas

Bug#947149: RFS: yoshimi/1.6.0.3-1 -- software synthesizer originally based on ZynAddSubFX2

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: yoshimi
   Version : 1.6.0.3-1
   Upstream Author : yoshimi-u...@lists.sourceforge.net
 * URL : https://yoshimi.sourceforge.io
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/multimedia-team/yoshimi
   Section : sound

It builds those binary packages:

  yoshimi - software synthesizer originally based on ZynAddSubFX2
  yoshimi-data - Presets for Yoshimi
  yoshimi-doc - Documentation for Yoshimi

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/y/yoshimi/yoshimi_1.6.0.3-1.dsc

Changes since the last upload:

   * New upstream version 1.6.0.3
   * d/copyright:
 + Change license for desktop/metainfo/* and Util/YoshimiSplash.svg to 
CC-BY-4.0
   * Fix license name of yoshimi.appdata.xml to make lintian happy

Regards,

--
Dennis Braun

Bug#947148: openmpi: causes lt_dlopen() to fail with 'can't close resident module'

[Andreas Beckmann]

Source: openmpi
Version: 4.0.2-4
Severity: serious
Control: block 946422 with -1
Control: block 946582 with -1

Hi,

this bug was initially observed as a silx autopkgtest failure (#946422)
in pocl (#946582). I've reduced it to a python-free OpenCL example in C
and now I'm convinced that it is caused by by OpenMPI 4.

Attached you can find a trivial OpenCL example (yes, that needs a bit of
boilerplate code) that is linked against MPI and calls MPI_Init().
This works fine with OpenMPI 3 in buster, MPICH in sid (and no MPI as
well), but fails with OpenMPI 4 in sid.

You need opencl-dev and libopenmpi-dev to build it and pocl-opencl-icd
to run it.
You build it with 
 mpicc -o test_mpi_ocl test_mpi_ocl.c -lOpenCL
and get this when running successfully:

# ./test_mpi_ocl 
Success

but the failure with OpenMPI 4 is

# ./test_mpi_ocl 
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident 
module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.
Aborted

OpenMPI 4 seems to change some state causing subsequent lt_dlopen() to fail.

In gdb we have 
(gdb) bt
#0  0x77d10081 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x77cfb535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fffed2b66d1 in pocl_check_kernel_dlhandle_cache 
(cmd=cmd@entry=0x5562b730, initial_refcount=initial_refcount@entry=1) at 
./lib/CL/devices/common.c:1097
#3  0x7fffed2bc327 in pocl_pthread_prepare_kernel (cmd=0x5562b730, 
data=0x556cb5e0) at ./lib/CL/devices/pthread/pthread_scheduler.c:413
#4  pocl_pthread_exec_command (td=0x556cd200, cmd=0x5562b730) at 
./lib/CL/devices/pthread/pthread_scheduler.c:450
#5  pocl_pthread_driver_thread (p=) at 
./lib/CL/devices/pthread/pthread_scheduler.c:496
#6  0x779aafb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#7  0x77dd02df in clone () from /lib/x86_64-linux-gnu/libc.so.6

The error stems from line lib/CL/devices/common.c 1062
ci->dlhandle = lt_dlopen (module_fn);
where module_fn = 
"//.cache/pocl/kcache/IL/PFLJNNHLKAHONADOJOEENLMDLFHDJKOMFJHEO/foo/1-1-1/foo.so"

OK, we can further minimize this testcase if we just take foo.so
(amd64 version attached) and lt_dlopen() it:

// mpicc -o test_lt_dlopen test_lt_dlopen.c -lltdl 

#include 
#include 
#include 

int main(int argc, char **argv)
{
MPI_Init(, );
lt_dlinit();
lt_dlhandle handle = lt_dlopen ("./foo.so");
const char * dl_error = lt_dlerror ();
printf("%p %s\n", handle, dl_error ? dl_error : "(null)");
}

Without OpenMPI 4 we succeed:
# ./test_lt_dlopen
0x55c4accfc480 (null)

but with OpenMPI 4 we run into the same problem:
# ./test_lt_dlopen
0x559b5c923250 can't close resident module

Andreas
// install packages
// apt-get install libopenmpi-dev opencl-dev pocl-opencl-icd
// compile with
// mpicc -o test_mpi_ocl test_mpi_ocl.c -lOpenCL

// based on https://wiki.aalto.fi/display/HPEC/OpenCL+tutorial

#define CL_TARGET_OPENCL_VERSION 100

// 0a_trivial.c
#include 
#include 
 
#ifdef __APPLE__
#include 
#else
#include 
#endif

#include 

/* A kernel which does nothing */
const char * source_str  = "__kernel void foo(void)"
   "{"
   ""
   "}";

int main(int argc, char** argv) {
MPI_Init(, );

/* Get platform and device information */
cl_platform_id platform_id = NULL;
cl_device_id device_id = NULL;   
cl_uint num_devices;
cl_uint num_platforms;
cl_int ret = clGetPlatformIDs(1, _id, _platforms);
ret = clGetDeviceIDs( platform_id, CL_DEVICE_TYPE_CPU, 1, _id, 
_devices);
 
/* Create an OpenCL context */
cl_context context = clCreateContext( NULL, 1, _id, NULL, NULL, 
);
 
/* Create a command queue */
cl_command_queue command_queue = clCreateCommandQueue(context, device_id, 
0, );
 
/* Create a program from the kernel source */
cl_program program = clCreateProgramWithSource(context, 1, _str, 
NULL, );
 
/* Build the program */
ret = clBuildProgram(program, 1, _id, NULL, NULL, NULL);
 
/* Create the OpenCL kernel */
cl_kernel kernel = clCreateKernel(program, "foo", );
 
/* Execute the OpenCL kernel */
size_t global_item_size = 1;
size_t local_item_size = 1;
ret = clEnqueueNDRangeKernel(command_queue, kernel, 1, NULL, 
_item_size, _item_size, 0, NULL, NULL);

ret = clFlush(command_queue);
ret = clFinish(command_queue);

if (ret == CL_SUCCESS)
printf("Success\n");
else
printf("OpenCL error executing kernel: %d\n", ret); 
 
/* Clean up */
ret = clReleaseKernel(kernel);
ret = clReleaseProgram(program);
ret = clReleaseCommandQueue(command_queue);
ret = clReleaseContext(context);
return 0;
}
// mpicc -o test_lt_dlopen test_lt_dlopen.c -lltdl 

#include 
#include 
#include 

int main(int argc, char **argv)
{
MPI_Init(, );
  

Bug#947147: RFS: wavbreaker/0.13-1 -- tool to split wave files into multiple chunks

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wavbreaker
   Version : 0.13-1
   Upstream Author : https://github.com/thp/wavbreaker
 * URL : http://wavbreaker.sourceforge.net/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/multimedia-team/wavbreaker
   Section : x11

It builds those binary packages:

  wavbreaker - tool to split wave files into multiple chunks

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wavbreaker/wavbreaker_0.13-1.dsc

Changes since the last upload:

   * New upstream release
   * debian/control:
 + Build-Depends: Add cmake, meson, libao-dev and libmpg123-dev
 + Build-Depends: Replace libgtk2.0-dev with libgtk-3-dev
   * debian/copyright: Rewrite and update
   * debian/docs: Replace README with README.md and drop NEWS
   * debian/patches:
 + 0001-Fix-format-not-a-string-literal-errors.patch: Drop, obsolete
 + 0002-Add-F-to-Exec.patch: Update
 + 0003-Disable-Moodbar-Support.patch: Add
   * debian/watch: Update for github releases

Regards,

--
Dennis Braun

Bug#947146: buster-pu: package python-mistral-lib/1.0.0-1 CVE-2019-3866

[Salvatore Bonaccorso]

Hi Thomas

[Disclaimer: not part of the stable release managers, so this reply is
not authoritative]

Thanks for handling CVE-2019-3866 for unstable and buster.

On Sat, Dec 21, 2019 at 11:12:17PM +0100, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear Stable Release team,
> 
> I'd like to upgrade python-mistral-lib to address CVE-2019-3866,
> which is described in https://bugs.debian.org/946060. Please note
> that this patch is only useful if you also approve the upload of
> python-oslo.utils which I requested in #947142.
> 
> Debdiff containing the patch is attached. Note that there's, as
> much as I understand, no need to upgrade Mistral to address this
> CVE (probably it would be needed in Stretch though...), as I believe
> the issue is fully addressed by the update of python-mistral-lib
> (at least, that's my understanding when reading the upstream bug
> entry at https://bugs.launchpad.net/tripleo/+bug/1850843).

Question (which apply as well for the unstable upload which was just
done): the python-mistral-lib patch depends on the fixed version of
python-oslo.utils. Wouldn't that need a versioned dependency
python-oslo.utils?

Regards,
Salvatore

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[Adam Borowski]

Control: tags +moreinfo

On Sat, Dec 21, 2019 at 11:08:46PM +0100, deb...@think-future.com wrote:
> Severity: critical

If it's indeed this serious, shouldn't this update go via security channels
first?

> On 2019-12-21 22:29:06, DebBug wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for the package "wordpress"
> > 
> > * Package name: wordpress
> >  Version : 5.3.2+dfsg1-0.1

> > Changes since the last upload:
> > 
> >  * Non-maintainer upload.
> >  * New upstream release

So you're trying to upload merely a new release, rather than a fix for a
security bug (which would warrant such expedience).  There might be
bugfix-only upstream releases (for good upstreams) or hopelessly-tied-with-
unrelated-features releases (for bad upstreams), but at the very least you'd
need to point to specific reasons to hurry.

But here, you're apparently going with a whole new upstream branch, over the
head of the maintainer, who seems to be active -- and all of that without
even trying to follow the procedure.

Would you care to explain what you're doing?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#943786: lmfit-py: failing tests with python3.8

[Andreas Tille]

Hi,

I tried hard to get lmfit-py (now at upstream version 1.0.0) building
but I endet up with 


build succeeded, 73 warnings.

The HTML pages are in build/html.

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py", line 
313, in sumarize_failing_examples
"\n" + "-" * 79)
ValueError: Here is a summary of the problems encountered when running the 
examples

Examples expected to fail, but not failing:
Please remove these examples from
sphinx_gallery_conf['expected_failing_examples']
/build/lmfit-py-1.0.0/examples/documentation/model_loadmodel.py



The full sphinx log says:


# Sphinx version: 1.8.5
# Python version: 3.7.6 (CPython)
# Docutils version: 0.15.2 release
# Jinja2 version: 2.10.1
# Last messages:
#   done
#   copying extra files...
#   done
#   dumping search index in English (code: en) ...
#   done
#   dumping object inventory...
#   done
#   build succeeded, 73 warnings.
#...
#   The HTML pages are in build/html.
# Loaded extensions:
#   sphinx.ext.mathjax (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
#   alabaster (0.7.8) from /usr/lib/python3/dist-packages/alabaster/__init__.py
#   sphinx.ext.autodoc (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/autodoc/__init__.py
#   sphinx.ext.extlinks (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/extlinks.py
#   sphinx.ext.intersphinx (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py
#   sphinx.ext.napoleon (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/napoleon/__init__.py
#   sphinx.ext.todo (1.8.5) from 
/usr/lib/python3/dist-packages/sphinx/ext/todo.py
#   IPython.sphinxext.ipython_console_highlighting (unknown version) from 
/usr/lib/python3/dist-packages/IPython/sphinxext/ipython_console_highlighting.py
#   sphinx_gallery.gen_gallery (0.2.0) from 
/usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 304, in 
build_main
app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 369, in 
build
self.emit('build-finished', None)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 510, in emit
return self.events.emit(event, self, *args)
  File "/usr/lib/python3/dist-packages/sphinx/events.py", line 80, in emit
results.append(callback(*args))
  File "/usr/lib/python3/dist-packages/sphinx_gallery/gen_gallery.py", line 
313, in sumarize_failing_examples
"\n" + "-" * 79)
ValueError: Here is a summary of the problems encountered when running the 
examples

Examples expected to fail, but not failing:
Please remove these examples from
sphinx_gallery_conf['expected_failing_examples']
/build/lmfit-py-1.0.0/examples/documentation/model_loadmodel.py
---



Any idea how to fix this?


Kind regards

   Andreas.



-- 
http://fam-tille.de

Bug#947146: buster-pu: package python-mistral-lib/1.0.0-1 CVE-2019-3866

[Thomas Goirand]

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

Dear Stable Release team,

I'd like to upgrade python-mistral-lib to address CVE-2019-3866,
which is described in https://bugs.debian.org/946060. Please note
that this patch is only useful if you also approve the upload of
python-oslo.utils which I requested in #947142.

Debdiff containing the patch is attached. Note that there's, as
much as I understand, no need to upgrade Mistral to address this
CVE (probably it would be needed in Stretch though...), as I believe
the issue is fully addressed by the update of python-mistral-lib
(at least, that's my understanding when reading the upstream bug
entry at https://bugs.launchpad.net/tripleo/+bug/1850843).

Note that I've also uploaded the package here, for your convenience:

http://shade.infomaniak.ch/buster-pu/python-mistral-lib/

Please allow me to upload:
python-mistral-lib/1.0.0-1+deb10u1.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-mistral-lib-1.0.0/debian/changelog 
python-mistral-lib-1.0.0/debian/changelog
--- python-mistral-lib-1.0.0/debian/changelog   2018-09-04 00:06:52.0 
+0200
+++ python-mistral-lib-1.0.0/debian/changelog   2019-12-21 22:59:56.0 
+0100
@@ -1,3 +1,10 @@
+python-mistral-lib (1.0.0-1+deb10u1) buster; urgency=medium
+
+  * CVE-2019-3866: Sensitive information leaked in mistral logs. Apply
+upstream patch: Ensure we mask sensitive data from Mistral Action logs.
+
+ -- Thomas Goirand   Sat, 21 Dec 2019 22:59:56 +0100
+
 python-mistral-lib (1.0.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
python-mistral-lib-1.0.0/debian/patches/CVE-2019-3866_Ensure_we_mask_sensitive_data_from_Mistral_Action_logs.patch
 
python-mistral-lib-1.0.0/debian/patches/CVE-2019-3866_Ensure_we_mask_sensitive_data_from_Mistral_Action_logs.patch
--- 
python-mistral-lib-1.0.0/debian/patches/CVE-2019-3866_Ensure_we_mask_sensitive_data_from_Mistral_Action_logs.patch
  1970-01-01 01:00:00.0 +0100
+++ 
python-mistral-lib-1.0.0/debian/patches/CVE-2019-3866_Ensure_we_mask_sensitive_data_from_Mistral_Action_logs.patch
  2019-12-21 22:59:56.0 +0100
@@ -0,0 +1,97 @@
+Author: Cédric Jeanneret 
+Date: Fri, 1 Nov 2019 11:47:35 +0100
+Description: CVE-2019-3866 Ensure we mask sensitive data from Mistral Action 
logs
+ Mistral didn't make use of the oslo_utils "mask_password" methods,
+ leading in sensitive data leakage in its logs.
+ .
+ This patch corrects this security issue.
+ Note that it depends on oslo_utils patch adding new patterns, and
+ ensuring it's case-insensitive.
+Change-Id: I544d3c172f2dea02c62c49c311c4b5954413ae15
+Related-Bug: #1850843
+Co-Authored-By: Dougal Matthews 
+Signed-off-by: Cédric Jeanneret 
+Origin: upstream, https://review.opendev.org/692975
+
+diff --git a/mistral_lib/actions/types.py b/mistral_lib/actions/types.py
+index cd8bf28..a77b96f 100644
+--- a/mistral_lib/actions/types.py
 b/mistral_lib/actions/types.py
+@@ -32,8 +32,11 @@ class Result(serialization.MistralSerializable):
+ )
+ 
+ def cut_repr(self):
++_data = utils.mask_data(self.data)
++_error = utils.mask_data(self.error)
++_cancel = utils.mask_data(self.cancel)
+ return 'Result [data=%s, error=%s, cancel=%s]' % (
+-utils.cut(self.data), utils.cut(self.error), str(self.cancel)
++utils.cut(_data), utils.cut(_error), str(_cancel)
+ )
+ 
+ def is_cancel(self):
+diff --git a/mistral_lib/tests/test_utils.py b/mistral_lib/tests/test_utils.py
+index 599aaac..78ec3ec 100644
+--- a/mistral_lib/tests/test_utils.py
 b/mistral_lib/tests/test_utils.py
+@@ -84,3 +84,20 @@ class TestUtils(tests_base.TestCase):
+ s = utils.cut_dict(d, 100)
+ 
+ self.assertIn(s, ["{1: 2, 3: 4}", "{3: 4, 1: 2}"])
++
++def test_mask_data(self):
++payload = {'adminPass': 'fooBarBaz'}
++expected = {'adminPass': '***'}
++self.assertEqual(expected, utils.mask_data(payload))
++
++payload = """adminPass='fooBarBaz'"""
++expected = """adminPass='***'"""
++self.assertEqual(expected, utils.mask_data(payload))
++
++payload = [{'adminPass': 'fooBarBaz'}, {"new_pass": "blah"}]
++expected = [{'adminPass': '***'}, {"new_pass": "***"}]
++self.assertEqual(expected, utils.mask_data(payload))
++
++payload = ["adminPass", 'fooBarBaz']
++expected = ["adminPass", 'fooBarBaz']
++self.assertEqual(expected, utils.mask_data(payload))
+diff --git a/mistral_lib/utils/__init__.py b/mistral_lib/utils/__init__.py
+index 92dda4e..7f845dc 100644
+--- a/mistral_lib/utils/__init__.py
 b/mistral_lib/utils/__init__.py
+@@ -14,6 +14,8 @@
+ # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ # License for the specific language governing permissions and limitations
+ # under the License.
++from oslo_utils.strutils import mask_dict_password
++from 

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[debbug]

Severity: critical

On 2019-12-21 22:29:06, DebBug wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "wordpress"

* Package name: wordpress
 Version : 5.3.2+dfsg1-0.1
 Upstream Author : Hard to find for https://wordpress.org
* URL : https://wordpress.org
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/wordpress
 Section : web

It builds those binary packages:

wordpress - weblog manager
wordpress-l10n - weblog manager - language files
wordpress-theme-twentysixteen - weblog manager - twentysixteen theme files
wordpress-theme-twentyseventeen - weblog manager - twentyseventeen theme files
wordpress-theme-twentynineteen - weblog manager - twentynineteen theme files

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/w/wordpress/wordpress_5.3.2+dfsg1-0.1.dsc

Changes since the last upload:

 * Non-maintainer upload.
 * New upstream release

Thank you.

Regards,

Nils



signature.asc
Description: PGP signature

Bug#908438: cubietruck wifi reversion

[Salvatore Bonaccorso]

Hi Hans,

On Fri, Dec 20, 2019 at 11:53:43AM +0100, Hans de Goede wrote:
> On 18-12-2019 22:46, Salvatore Bonaccorso wrote:
> > Can you report this to upstream directly? (Please keep the Debian bug
> > into the loop).
> 
> I have submitted the patch upstream at the same time I added a comment
> to the Debian bug. Upstream did not accept the patch back then because
> the were hoping a real fix would show up soon.

Right, I missed to check on upstream list, so
https://lore.kernel.org/linux-arm-kernel/20180930150927.12076-1-hdego...@redhat.com/
.
 
> If people are still hitting this issue, it might be a good idea if
> someone re-tests and if the patch still helps re-submits it upstream.

Helmut was reporting to see the issue on buster, but we would need
confirmation that the issue is seen still at least on 5.4.6 or ideally
as well on 5.5-rc2.

Regards,
Salvatore

Bug#947145: libucommon-dev: #include unexpectedly defines NDEBUG

[Frédéric Brière]

Package: libucommon-dev
Version: 7.0.0-16
Severity: normal

When included, ucommon/ucommon.h (via platform.h) unexpectedly defines
NDEBUG without any warning, unless DEBUG has already been defined.

That led to a lot of head-scratching, trying to figure out why assert()
was sometimes, but not always, not doing its job while working on a
project that uses uCommon in some places.


 $ cat ucommon-ndebug.cpp
 #ifdef NDEBUG
 #warning "NDEBUG was already defined before including "
 #endif
 
 #include 
 
 #ifdef NDEBUG
 #error "NDEBUG is defined after including "
 #endif

 $ g++ -E ucommon-ndebug.cpp >/dev/null && echo OK
 ucommon-ndebug.cpp:8:2: error: #error "NDEBUG is defined after including 
"
  #error "NDEBUG is defined after including "
   ^

 $ g++ -E -DDEBUG ucommon-ndebug.cpp >/dev/null && echo OK
 OK


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

Kernel: Linux 4.9.0-11-amd64 (SMP w/3 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libucommon-dev depends on:
ii  libgnutls28-dev  3.6.7-4
ii  libucommon8  7.0.0-16

Versions of packages libucommon-dev recommends:
ii  pkg-config  0.29-6

Versions of packages libucommon-dev suggests:
pn  ucommon-doc  
#ifdef NDEBUG
#warning "NDEBUG was already defined before including "
#endif

#include 

#ifdef NDEBUG
#error "NDEBUG is defined after including "
#endif

Bug#936924: Moving libsvm to Debian Science team

[Christian Kastner]

Hi all,

Regarding liblinear: I thought I already set the Maintainer to Debian
Science Team, I guess I missed it.

On 2019-12-21 20:11, Chen-Tse Tsai wrote:
> I've created an account on Salsa. 
> 
> Do you think we should remove cdbs and use another build system
> instead? Please let me know if you have any suggestion. I'm not
> familiar with other build systems.

Yep, the Debian Policy was updated and recommends dh now.

@Andreas: Chen-Tse and I discussed upgrading the package in October (I
think), but both did not have the time back then.

I could also help with some work starting on the 27th or so. As
src:liblinear and src:libsvm have the same upstream, they are quite
similar WRT to building, so src:liblinear (which is up to date) might
have some helpful ideas.

Given that the last libsvm update was a while ago, I wouldn't be
surprised if a transition were necessary.

Bug#947144: libqcalculate FTCBFS: unsatisfiable Build-Depends: libxml-parser-perl

[Helmut Grohne]

Source: libqalculate
Version: 2.8.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

libqalculate fails to cross build from source, because its build
dependency on libxml-parser-perl is not satisfiable. It turns out that
libqalculate no longer embeds intltool, but uses the packaged intltool.
Thus the dependency on libxml-parser-perl is no longer necessary and can
be dropped. After doing so, libqalculate cross builds successfully.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru libqalculate-2.8.2/debian/changelog 
libqalculate-2.8.2/debian/changelog
--- libqalculate-2.8.2/debian/changelog 2019-01-06 08:21:01.0 +0100
+++ libqalculate-2.8.2/debian/changelog 2019-12-21 22:05:43.0 +0100
@@ -1,3 +1,10 @@
+libqalculate (2.8.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Drop unused B-D: libxml-parser-perl. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 21 Dec 2019 22:05:43 +0100
+
 libqalculate (2.8.2-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru libqalculate-2.8.2/debian/control 
libqalculate-2.8.2/debian/control
--- libqalculate-2.8.2/debian/control   2019-01-06 08:21:01.0 +0100
+++ libqalculate-2.8.2/debian/control   2019-12-21 22:05:41.0 +0100
@@ -2,7 +2,7 @@
 Section: math
 Priority: optional
 Maintainer: Vincent Legout 
-Build-Depends: debhelper (>= 11), libncurses5-dev, libreadline-dev, 
libglib2.0-dev, libxml2-dev, libcln-dev (>> 1.2), libgmp-dev, 
libxml-parser-perl, intltool, libmpfr-dev, libcurl4-gnutls-dev, doxygen
+Build-Depends: debhelper (>= 11), libncurses5-dev, libreadline-dev, 
libglib2.0-dev, libxml2-dev, libcln-dev (>> 1.2), libgmp-dev, intltool, 
libmpfr-dev, libcurl4-gnutls-dev, doxygen
 Standards-Version: 4.3.0
 Homepage: https://qalculate.github.io/
 Vcs-Git: https://salsa.debian.org/vlegout/libqalculate.git

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] -- weblog manager

[DebBug]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "wordpress"

* Package name: wordpress
  Version : 5.3.2+dfsg1-0.1
  Upstream Author : Hard to find for https://wordpress.org
* URL : https://wordpress.org
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/wordpress
  Section : web

It builds those binary packages:

 wordpress - weblog manager
 wordpress-l10n - weblog manager - language files
 wordpress-theme-twentysixteen - weblog manager - twentysixteen theme files
 wordpress-theme-twentyseventeen - weblog manager - twentyseventeen theme files
 wordpress-theme-twentynineteen - weblog manager - twentynineteen theme files

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/w/wordpress/wordpress_5.3.2+dfsg1-0.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * New upstream release

Thank you.

Regards,

Nils

Bug#938174: python-simpy: Python2 removal in sid/bullseye

[Andreas Tille]

Hi,

just a comment that this bug is

   Fix blocked by 937033: mgltools-scenario2: Python2 removal in sid/bullseye

mgltools-scenario2 is in non-free and chances that somebody will care
soon are not very high.  I'd consider it sensible to ignore this rdepends
and remove Python2 support from python-simpy.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#936924: Moving libsvm to Debian Science team

[Andreas Tille]

Hi Chen-Tse,

On Sat, Dec 21, 2019 at 02:11:23PM -0500, Chen-Tse Tsai wrote:
> I've created an account on Salsa.

Nice, I've added you to the science-team.

> Do you think we should remove cdbs and use another build system instead?

Yes.  Debian Science (and all other teams I'm aware of) are migrating to
debhelper with short dh.  You have an example in the just uploaded

   https://salsa.debian.org/science-team/liblinear

> Please let me know if you have any suggestion. I'm not familiar with other
> build systems.

Dh is considered simpler and more transparent.  If you might have
serious trouble either I (or someone from the Debian Science team who
might beat me) will do this for you.  I need to admit my time to do so
is extremely limited between 24.12. and 6.1. but I'm sure we'll manage
in the team somehow.

> Thanks
> Chen-Tse

Thanks a lot for your cooperation

 Andreas.
 
> On Sat, Dec 21, 2019 at 12:27 PM Andreas Tille  wrote:
> 
> > Hi Chen-Tse,
> >
> > thanks for you quick response.
> >
> > On Sat, Dec 21, 2019 at 09:48:14AM -0500, Chen-Tse Tsai wrote:
> > > Hi, Andreas,
> > >
> > > I agree with your suggestions. Thanks for putting it on salsa!
> >
> > Thanks for confirming.
> >
> > > Should I investigate dropping python2? I can spend some time this week on
> > > this. But I may need help with debian stuff.
> >
> > What exact help do you need?  Do you have a login on Salsa?  We could
> > add you to science-team to grant you commit permissions.  I admit I have
> > not yet looked into the packaging - just realised that its cdbs which is
> > unfortunate since it would not eliminate the Python2 dependency fully.
> >
> > Kind regards
> >
> >   Andreas.
> >
> > > On Sat, Dec 21, 2019 at 7:39 AM Andreas Tille  wrote:
> > >
> > > > On Sat, Dec 21, 2019 at 08:28:57AM +, Mo Zhou wrote:
> > > > > I second this proposal, and the same for src:liblinear.
> > > >
> > > > That's done as I wrote.
> > > >
> > > > > These are high popcon packages, dependencies for a number of other
> > > > > packages. They should be team maintained to unblock important fixes.
> > > >
> > > > To push a bit I just commited
> > > >
> > > >https://salsa.debian.org/science-team/libsvm
> > > >
> > > > Last maintainer upload was more than 3 years ago, 2 NMUs inbetween,
> > > > package is lagging behind upstream.  Anybody is kindly invited to adapt
> > > > the packaging (I think we should really get rid of cdbs since this in
> > > > turn is Python2) and proceed from here.
> > > >
> > > > Kind regards
> > > >
> > > >  Andreas.
> > > >
> > > >
> > > > > On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> > > > > > Hi Chen-Tse,
> > > > > >
> > > > > > I'm maintaining a package that depends from libsvm.  Due to bug
> > #936924
> > > > > > that did not received any response since August it is in danger to
> > be
> > > > > > removed from testing so I'm interested that this bug will be fixed.
> > > > > > When looking at the package I realised that while it would fit into
> > > > > > Debian Science team scope it is not team maintained nor is there
> > any
> > > > > > repository in Salsa.  That's why I have the following suggestion:
> > > > > >
> > > > > >   1. I create a repository on Salsa
> > > > > >   2. Move the package to Debian Science team maintenance
> > > > > >  and add you as Uploader
> > > > > >   3. Drop Python2 package and close bug #936924
> > > > > >   4. May be migrate packaging from cdbs to dh
> > > > > >
> > > > > > If I do not hear from you until Monday I assume you agree with this
> > > > > > plan and will do so.
> > > > > >
> > > > > > Kind regards
> > > > > >
> > > > > >  Andreas.
> > > > > >
> > > > > > PS: @Christian: I noticed that you and Chen-Tse are maintaining
> > > > > > liblinear.  I have just removed Python2 package and reassigned
> > > > > > #936889 to ftp.debian.org to make sure python-liblinear will
> > be
> > > > > > removed.  Thus libsvm can be dealt as suggested.
> > > > > >
> > > > > > --
> > > > > > http://fam-tille.de
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > http://fam-tille.de
> > > >
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile

[Hilmar Preuße]

Am 21.12.2019 um 01:21 teilte Norbert Preining mit:
> On Fri, 20 Dec 2019, Hilmar Preuße wrote:

Hi,

>> I'm able to reproduce:
> 
> Strange, I can ..but I have that file somewhere else ...
> 
> (/usr/local/share/texmf/tex/latex/fourier/fourier-orns.sty))) (./asb.aux)
> 
> Need to investigate.
> 
hille@sid:~ $ apt-file search fourier-orns.sty
texlive-fonts-extra:
/usr/share/texlive/texmf-dist/tex/latex/fourier/fourier-orns.sty

Fix your installation!! ;-)

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



signature.asc
Description: OpenPGP digital signature

Bug#947142: #947142: buster-pu: package python-oslo.utils/3.36.4-2 CVE-2019-3866 - https://bugs.debian.org/947142

[Thomas Goirand]

FYI, for reference, the package is built and available here:

http://shade.infomaniak.ch/buster-pu/python-oslo.utils/

Bug#947142: buster-pu: package python-oslo.utils/3.36.4-2 CVE-2019-3866

[Thomas Goirand]

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

Dear Stable release team,

I'd like to update python-oslo.utils in Buster to address CVE-2019-3866.
It wasn't possible to apply directly the patch available here:

https://review.opendev.org/692972

and I found too dangerous to skip the commits right before it, which are
related to this patch. So I just merged upstream branch stable/rocky into
the Debian package. However, looking closer to all patches, either they
are all related to the official patch, or are cosmetic from the Debian
perspective (ie: .gitreview, or upstream CI related).

Please find, attached to this bug, the debdiff for the udpate.

Please allow me to upload:
python-oslo.utils/3.36.4+2019.11.15.git.c49a426b66-1+deb10u1

Cheers,

Thomas Goirand (zigo)
diff -Nru python-oslo.utils-3.36.4/debian/changelog 
python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/debian/changelog
--- python-oslo.utils-3.36.4/debian/changelog   2018-09-03 23:20:56.0 
+0200
+++ python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/debian/changelog 
2019-12-21 21:37:40.0 +0100
@@ -1,3 +1,11 @@
+python-oslo.utils (3.36.4+2019.11.15.git.c49a426b66-1+deb10u1) buster; 
urgency=medium
+
+  * CVE-2019-3866: Sensitive information leaked in mistral logs. Upgrade to
+the tip of the upstream stable/rocky branch (as the upstream patch would
+not otherwise apply).
+
+ -- Thomas Goirand   Sat, 21 Dec 2019 21:37:40 +0100
+
 python-oslo.utils (3.36.4-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru python-oslo.utils-3.36.4/.gitreview 
python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/.gitreview
--- python-oslo.utils-3.36.4/.gitreview 2018-07-18 05:43:01.0 +0200
+++ python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/.gitreview   
2019-11-18 10:13:41.0 +0100
@@ -1,4 +1,5 @@
 [gerrit]
-host=review.openstack.org
+host=review.opendev.org
 port=29418
-project=openstack/oslo.utils.git
\ No newline at end of file
+project=openstack/oslo.utils.git
+defaultbranch=stable/rocky
diff -Nru python-oslo.utils-3.36.4/oslo_utils/strutils.py 
python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/oslo_utils/strutils.py
--- python-oslo.utils-3.36.4/oslo_utils/strutils.py 2018-07-18 
05:43:01.0 +0200
+++ python-oslo.utils-3.36.4+2019.11.15.git.c49a426b66/oslo_utils/strutils.py   
2019-11-18 10:13:41.0 +0100
@@ -54,11 +54,19 @@
 SLUGIFY_HYPHENATE_RE = re.compile(r"[-\s]+")
 
 
-# NOTE(flaper87): The following globals are used by `mask_password`
-_SANITIZE_KEYS = ['adminPass', 'admin_pass', 'password', 'admin_password',
+# NOTE(flaper87): The following globals are used by `mask_password` and
+# `mask_dict_password`
+_SANITIZE_KEYS = ['adminpass', 'admin_pass', 'password', 'admin_password',
   'auth_token', 'new_pass', 'auth_password', 'secret_uuid',
   'secret', 'sys_pswd', 'token', 'configdrive',
-  'CHAPPASSWORD', 'encrypted_key', 'private_key']
+  'chappassword', 'encrypted_key', 'private_key',
+  'encryption_key_id', 'fernetkey', 'sslkey', 'passphrase',
+  'cephclusterfsid', 'octaviaheartbeatkey', 'rabbitcookie',
+  'cephmanilaclientkey', 'pacemakerremoteauthkey',
+  'designaterndckey', 'cephadminkey', 'heatauthencryptionkey',
+  'cephclientkey', 'keystonecredential',
+  'barbicansimplecryptokek', 'cephrgwkey', 'swifthashsuffix',
+  'migrationsshkey', 'cephmdskey', 'cephmonkey']
 
 # NOTE(ldbragst): Let's build a list of regex objects using the list of
 # _SANITIZE_KEYS we already have. This way, we only have to add the new key
@@ -69,17 +77,18 @@
 
 # NOTE(amrith): Some regular expressions have only one parameter, some
 # have two parameters. Use different lists of patterns here.
-_FORMAT_PATTERNS_1 = [r'(%(key)s\s*[=]\s*)[^\s^\'^\"]+']
-_FORMAT_PATTERNS_2 = [r'(%(key)s\s*[=]\s*[\"\'])[^\"\']*([\"\'])',
-  r'(%(key)s\s+[\"\'])[^\"\']*([\"\'])',
-  r'([-]{2}%(key)s\s+)[^\'^\"^=^\s]+([\s]*)',
-  r'(<%(key)s>)[^<]*()',
-  r'([\"\']%(key)s[\"\']\s*:\s*[\"\'])[^\"\']*([\"\'])',
-  r'([\'"][^"\']*%(key)s[\'"]\s*:\s*u?[\'"])[^\"\']*'
+_FORMAT_PATTERNS_1 = [r'(%(key)s[0-9]*\s*[=]\s*)[^\s^\'^\"]+']
+_FORMAT_PATTERNS_2 = [r'(%(key)s[0-9]*\s*[=]\s*[\"\'])[^\"\']*([\"\'])',
+  r'(%(key)s[0-9]*\s+[\"\'])[^\"\']*([\"\'])',
+  r'([-]{2}%(key)s[0-9]*\s+)[^\'^\"^=^\s]+([\s]*)',
+  r'(<%(key)s[0-9]*>)[^<]*()',
+  r'([\"\']%(key)s[0-9]*[\"\']\s*:\s*[\"\'])[^\"\']*'
+  '([\"\'])',
+  r'([\'"][^"\']*%(key)s[0-9]*[\'"]\s*:\s*u?[\'"])[^\"\']*'
   '([\'"])',
-  

Bug#947140: libgeo-ip-perl FTCBFS: Build-Depends: perl

[Helmut Grohne]

Source: libgeo-ip-perl
Version: 1.51-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

libgeo-ip-perl is one of the packages that fails to cross build, because
it Build-Depends on perl. Like many packages, it should be updated to
perl-xs-dev. Once doing so, libgeo-ip-perl becomes cross buildable.
geoip-database was recently marked Multi-Arch: foreign.  Please consider
applying the attached patch without urgency.

Helmut
diff --minimal -Nru libgeo-ip-perl-1.51/debian/changelog 
libgeo-ip-perl-1.51/debian/changelog
--- libgeo-ip-perl-1.51/debian/changelog2017-11-11 20:24:47.0 
+0100
+++ libgeo-ip-perl-1.51/debian/changelog2019-12-21 21:57:49.0 
+0100
@@ -1,3 +1,10 @@
+libgeo-ip-perl (1.51-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build-Depends: perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 21 Dec 2019 21:57:49 +0100
+
 libgeo-ip-perl (1.51-1) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru libgeo-ip-perl-1.51/debian/control 
libgeo-ip-perl-1.51/debian/control
--- libgeo-ip-perl-1.51/debian/control  2017-11-11 20:23:35.0 +0100
+++ libgeo-ip-perl-1.51/debian/control  2019-12-21 21:57:47.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 9.20120312),
geoip-database,
libgeoip-dev,
-   perl
+   perl-xs-dev
 Standards-Version: 4.1.1
 Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-perl/packages/libgeo-ip-perl.git
 Vcs-Git: https://anonscm.debian.org/git/pkg-perl/packages/libgeo-ip-perl.git

Bug#946794: hibiscus: Please backport hibiscus

[Jochen Sprickerhof]

Hi Memnon,

thanks for the bug report. I proposed an upgrade to the release team in 
#943889.


Cheers Jochen

* Memnon Anon  [2019-12-15 22:32]:


Source: hibiscus
Severity: wishlist

Dear Maintainer,

since every bank in Germany changed to comply with PSD2,
the version currently in stable is pretty much useless
at the moment. By now, it seems like hibiscus has
stabilized enough with 2.8.21, which already hit testing.

Please consider preparing a backport for the stable
users.


Kernel: Linux 4.19.0-6-686-pae (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/bash

Init: systemd (via /run/systemd/system)

-- System Information:
Debian Release: 10.2
APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
  Architecture: i386 (i686)


signature.asc
Description: PGP signature

Bug#947138: udo FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: udo
Version: 6.4.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

udo fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
fails when the built udo is run to generate the documentation. Given
that udo is small and has few dependencies, we can simply build it twice
though. Please consider applying the attached patch.

Helmut
diff --minimal -Nru udo-6.4.1/debian/changelog udo-6.4.1/debian/changelog
--- udo-6.4.1/debian/changelog
+++ udo-6.4.1/debian/changelog
@@ -1,3 +1,9 @@
+udo (6.4.1-6) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Build a second time for cross building. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 Dec 2019 17:14:56 +0100
+
 udo (6.4.1-5) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru udo-6.4.1/debian/rules udo-6.4.1/debian/rules
--- udo-6.4.1/debian/rules
+++ udo-6.4.1/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE = 1
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
 
 %:
@@ -23,6 +25,11 @@
Source/udo --no-logfile --html -q -o eng/html/index.html 
$(CURDIR)/Guide/eng/manual/index.u
cp Guide/ger/manual/images/*.gif ger/html/images/
Source/udo --no-logfile --html -q -o ger/html/index.html 
$(CURDIR)/Guide/ger/manual/index.u
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dh_auto_clean --sourcedirectory=Source --buildsystem=makefile -- -f 
Makefile.debian
+   dh_auto_build --sourcedirectory=Source --buildsystem=makefile -- -f 
Makefile.debian \
+   CFLAGS="$(CFLAGS) $(CPPFLAGS) -D__LINUX__" LDFLAGS="$(LDFLAGS)"
+endif
 
 override_dh_auto_install:
$(MAKE) -C Source -f Makefile.debian install 
DESTDIR=$(CURDIR)/debian/tmp

Bug#947139: libjpeg FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: libjpeg
Version: 0.0~git20190821.87636f3b26b4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libjpeg fails to cross build from source, because it configures for the
build architecture. Unconventionally, ./configure is invoked by the
Makefile during dh_auto_build. This happens, because the Makefile also
performs autoconf and thus debhelper uses the makefile buildsystem due
to the absence of configure. Enabling autoreconf makes debhelper select
the autoconf buildsystem and run ./configure with --host. However,
configuration fails due to frequent use of AC_TRY_RUN. The attached
patch adds autoreconf and fixes a lot of AC_TRY_RUN, but not all. It is
an incremental improvement and does not make libjpeg cross buildable.
Please consider applying it anyway and close this bug when doing so.

Helmut
diff --minimal -Nru libjpeg-0.0~git20190821.87636f3b26b4/debian/changelog 
libjpeg-0.0~git20190821.87636f3b26b4/debian/changelog
--- libjpeg-0.0~git20190821.87636f3b26b4/debian/changelog
+++ libjpeg-0.0~git20190821.87636f3b26b4/debian/changelog
@@ -1,3 +1,12 @@
+libjpeg (0.0~git20190821.87636f3b26b4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #-1)
++ Let debhelper perform configuration with --host.
++ cross.patch: Replace a lot of AC_TRY_RUN.
+
+ -- Helmut Grohne   Tue, 21 Dec 2019 09:52:48 +0100
+
 libjpeg (0.0~git20190821.87636f3b26b4-1) unstable; urgency=medium
 
   * d/watch: Add missing watch file
diff --minimal -Nru libjpeg-0.0~git20190821.87636f3b26b4/debian/control 
libjpeg-0.0~git20190821.87636f3b26b4/debian/control
--- libjpeg-0.0~git20190821.87636f3b26b4/debian/control
+++ libjpeg-0.0~git20190821.87636f3b26b4/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian PhotoTools Maintainers 

 Uploaders: Mathieu Malaterre 
-Build-Depends: autotools-dev, debhelper (>= 9.20160114), help2man
+Build-Depends: autotools-dev, debhelper (>= 9.20160114), help2man, 
dh-autoreconf
 Standards-Version: 4.4.1
 Homepage: https://github.com/thorfdbg/libjpeg
 Vcs-Git: https://salsa.debian.org/debian-phototools-team/libjpeg.git
diff --minimal -Nru 
libjpeg-0.0~git20190821.87636f3b26b4/debian/patches/cross.patch 
libjpeg-0.0~git20190821.87636f3b26b4/debian/patches/cross.patch
--- libjpeg-0.0~git20190821.87636f3b26b4/debian/patches/cross.patch
+++ libjpeg-0.0~git20190821.87636f3b26b4/debian/patches/cross.patch
@@ -0,0 +1,82 @@
+--- libjpeg-0.0~git20190821.87636f3b26b4.orig/configure.in
 libjpeg-0.0~git20190821.87636f3b26b4/configure.in
+@@ -318,7 +318,7 @@
+ AC_LANG(C++)
+ # The first test checks whether a signal handler takes an "int" as argument.
+ AC_MSG_CHECKING([whether argument type for signal handlers is "int"])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ extern "C" {
+ #include
+ }
+@@ -334,7 +334,7 @@
+ #
+ # Ditto for ... instead
+ AC_MSG_CHECKING([whether argument type for signal handlers is "..."])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ extern "C" {
+ #include
+ }
+@@ -365,7 +365,7 @@
+ # Check whether integers work as template arguments. This is required
+ # for several classes, but not all compilers accept it.
+ AC_MSG_CHECKING([whether integer constants are valid template arguments])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ template
+ struct A {
+  int b;
+@@ -512,7 +512,7 @@
+ # Check whether templated subclasses used in subclasses require explicitly 
the name space
+ # of the parent class to work. This should not happen, but gcc 2.95 has a bug 
here.
+ AC_MSG_CHECKING([whether templates are in local namespace])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ class A {
+  template
+  class B {
+@@ -532,7 +532,7 @@
+ # Check whether static const integral initializers work
+ # Some compilers don't support them properly, but gcc does.
+ AC_MSG_CHECKING([whether initializers of static const integral members work])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ class A {
+  static const int a=0;
+ };
+@@ -544,7 +544,7 @@
+ # Check whether casting works in template arguments. This doesn't seem to 
apply for 
+ # all compiles, so be a bit careful.
+ AC_MSG_CHECKING([whether casting works in template arguments])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ typedef unsigned char UC;
+ template
+ struct A {
+@@ -583,7 +583,7 @@
+ #
+ # Check whether the ALWAYS_INLINE attribute is available
+ AC_MSG_CHECKING([whether the always_inline attribute is available])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ int test(int code) __attribute__ ((always_inline));
+ int test(int code)
+ {
+@@ -592,7 +592,6 @@
+ int main(int,char**)
+ {
+  return test(0);
+- return 10;
+ }
+ ],[ac_have_always_inline='yes';AC_DEFINE(HAVE_ALWAYS_INLINE,[1],
+ [Define to 1 if the always_inline attribute is 
available])],[ac_have_always_inline='no'])
+@@ -677,7 +676,7 @@
+ # Check whether we have SIMD instructions for floating point. This can speed 
up at
+ # least the vertical lifting steps on some machines.
+ AC_MSG_CHECKING([for float SIMD instructions])
+-AC_TRY_RUN([
++AC_LINK_IFELSE([
+ typedef 

Bug#947066: closed by michael.cru...@gmail.com (Michael R. Crusoe) (Bug#947066: fixed in htslib 1.10.2-1)

[Michael Crusoe]

On Sat, Dec 21, 2019 at 2:36 AM John Marshall 
wrote:

> On 20 Dec 2019, at 19:21, Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
> > htslib (1.10.2-1) unstable; urgency=medium
> > .
> >   * New upstream version
> >   * debian/source/options: ignore changes to aclocal.m4 config.h.in
> configure
> >   * debian/control: remove libhts-private-dev (Closes: #947066)
>
> These changes have not yet been pushed to
> salsa.debian.org/med-team/htslib.git so it is difficult to verify the bug
> fix.
>

Oops, mea culpa. I've pushed them up.


>
> What is the purpose of the htslib-test subpackage? Its description says it
> contains the test data and scripts (from test/*), presumably so the
> upstream HTSlib test suite can be run against the library and tools
> installed from libhts3 and the subpackage currently named tabix. Why then
> does it also include HTSlib source code and an incomplete copy of HTSlib's
> build infrastructure?
>

I believe that was the easiest way to build and run the unit tests against
the installed libhts library. If you can find a simpler or smaller method
to build + run the unit tests (especially if any changes needed can be
incorporated upstream) then that would be very welcome!

Cheers,
-- 
Michael R. Crusoe

Bug#947137: progress-linux: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: progress-linux 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of progress-linux
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#947136: plinth: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: plinth 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of plinth debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#929493: Workaround

[aparat2]

Usual google advise to change Exec to: Exec=GDK_BACKEND=x11 totem %U  seamed to 
have no effect.After few hours I found how to apply  GDK_BACKEND=x11 
totem   in Nautilus   In file:  org.gnome.Totem.desktop  changed two lines 
so they look like:  Exec=/home/user/.local/bin/tot %U  DBusActivatable=false   
file totemx11:  #!/bin/sh  GDK_BACKEND=x11 /usr/bin/totem $@

Bug#947135: golang-github-mendersoftware-mender-artifact-dev: Drops (used) API without declaring a Breaks relationship

[Andreas Henriksson]

Package: golang-github-mendersoftware-mender-artifact-dev
Version: 3.2.0-1
Severity: important
Control: affects -1 mender-client

Dear Maintainer,

The mender-artifact upstream release 3.2.0 drops the NewRootfsV1 API
which the mender-client package uses. The updated mender-artifact
package apparently missed adding a
'Breaks: mender-client (<< $FIXEDVERSION)' relationship.

This causes the mender-client package to fail to build from source
(FTBFS) in both testing and unstable at the moment.
The new upstream releases of mender-client imported into the packaging
VCS is apparently also affected by this, so still unsolved there.

Regards,
Andreas Henriksson

Bug#944986: ITP: emacs-wgrep -- edit multiple files simultaneously in Emacs using grep buffers--pattern editing

[anarcat]

On Sun, Nov 17, 2019 at 07:39:49PM -0500, Nicholas D Steeves wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nicholas D Steeves 
> Control: tag + moreinfo
> 
> Package name: emacs-wgrep
> Version : 2.3.0
> Upstream Author : Masahiro Hayashi 
> URL : https://github.com/mhayashi1120/Emacs-wgrep
> License : GPL-3+
> Programming Lang: Emacs LISP
> Description : edit multiple files simultaneously in Emacs using grep 
> buffers--pattern editing

I heard through the grapevine (#debian-til, specifically) that there's a
similar project for the silver searcher (ag):

https://github.com/syohex/emacs-helm-ag

a.
-- 
The individual has always had to struggle to keep from being overwhelmed
by the tribe. If you try it, you will be lonely often, and sometimes
frightened. But no price is too high to pay for the privilege of owning
yourself.- Friedrich Nietzsche

Bug#936924: Moving libsvm to Debian Science team

[Chen-Tse Tsai]

I've created an account on Salsa.

Do you think we should remove cdbs and use another build system instead?
Please let me know if you have any suggestion. I'm not familiar with other
build systems.

Thanks
Chen-Tse


On Sat, Dec 21, 2019 at 12:27 PM Andreas Tille  wrote:

> Hi Chen-Tse,
>
> thanks for you quick response.
>
> On Sat, Dec 21, 2019 at 09:48:14AM -0500, Chen-Tse Tsai wrote:
> > Hi, Andreas,
> >
> > I agree with your suggestions. Thanks for putting it on salsa!
>
> Thanks for confirming.
>
> > Should I investigate dropping python2? I can spend some time this week on
> > this. But I may need help with debian stuff.
>
> What exact help do you need?  Do you have a login on Salsa?  We could
> add you to science-team to grant you commit permissions.  I admit I have
> not yet looked into the packaging - just realised that its cdbs which is
> unfortunate since it would not eliminate the Python2 dependency fully.
>
> Kind regards
>
>   Andreas.
>
> > On Sat, Dec 21, 2019 at 7:39 AM Andreas Tille  wrote:
> >
> > > On Sat, Dec 21, 2019 at 08:28:57AM +, Mo Zhou wrote:
> > > > I second this proposal, and the same for src:liblinear.
> > >
> > > That's done as I wrote.
> > >
> > > > These are high popcon packages, dependencies for a number of other
> > > > packages. They should be team maintained to unblock important fixes.
> > >
> > > To push a bit I just commited
> > >
> > >https://salsa.debian.org/science-team/libsvm
> > >
> > > Last maintainer upload was more than 3 years ago, 2 NMUs inbetween,
> > > package is lagging behind upstream.  Anybody is kindly invited to adapt
> > > the packaging (I think we should really get rid of cdbs since this in
> > > turn is Python2) and proceed from here.
> > >
> > > Kind regards
> > >
> > >  Andreas.
> > >
> > >
> > > > On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> > > > > Hi Chen-Tse,
> > > > >
> > > > > I'm maintaining a package that depends from libsvm.  Due to bug
> #936924
> > > > > that did not received any response since August it is in danger to
> be
> > > > > removed from testing so I'm interested that this bug will be fixed.
> > > > > When looking at the package I realised that while it would fit into
> > > > > Debian Science team scope it is not team maintained nor is there
> any
> > > > > repository in Salsa.  That's why I have the following suggestion:
> > > > >
> > > > >   1. I create a repository on Salsa
> > > > >   2. Move the package to Debian Science team maintenance
> > > > >  and add you as Uploader
> > > > >   3. Drop Python2 package and close bug #936924
> > > > >   4. May be migrate packaging from cdbs to dh
> > > > >
> > > > > If I do not hear from you until Monday I assume you agree with this
> > > > > plan and will do so.
> > > > >
> > > > > Kind regards
> > > > >
> > > > >  Andreas.
> > > > >
> > > > > PS: @Christian: I noticed that you and Chen-Tse are maintaining
> > > > > liblinear.  I have just removed Python2 package and reassigned
> > > > > #936889 to ftp.debian.org to make sure python-liblinear will
> be
> > > > > removed.  Thus libsvm can be dealt as suggested.
> > > > >
> > > > > --
> > > > > http://fam-tille.de
> > > > >
> > > >
> > > >
> > >
> > > --
> > > http://fam-tille.de
> > >
>
> --
> http://fam-tille.de
>

Bug#946185: fig2dev 3.2.6a-2+deb9u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946185 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.6a-2+deb9u3

Explanation: allow Fig v2 text strings ending with multiple ^A [CVE-2019-19555]

Bug#945944: ros-ros-comm 1.12.6-2+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 945944 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ros-ros-comm
Version: 1.12.6-2+deb9u1

Explanation: fix buffer overflow issue [CVE-2019-13566]

Bug#946824: libvncserver 0.9.11+dfsg-1.3~deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946824 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libvncserver
Version: 0.9.11+dfsg-1.3~deb9u2

Explanation: rfbserver: don't leak stack memory to the remote [CVE-2019-15681]; 
resolve a freeze during connection closure and a segmentation fault on 
multi-threaded VNC servers; fix issue connecting to VMWare servers

Bug#947125: buster-pu: package cyrus-imapd/3.0.8-6+deb10u4

[Xavier]

Le 21/12/2019 à 16:18, Adam D. Barratt a écrit :
> Control: tags -1 + moreinfo
> 
> On Sat, 2019-12-21 at 14:43 +0100, Xavier Guimard wrote:
>> cyrus-imapd has a RC bug. This little patch tested by reporters fixes
>> the problem.
> 
> Fun timing, given +deb10u3 only just went through security... :-p
> 
> +cyrus-imapd (3.0.8-6+deb10u4) buster; urgency=medium
> +
> +  * Add BACKUP type to cyrus-upgrade-db (Closes: #930764)
> [...]
> -   DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN)
> +   DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN|CONVERSATIONS|S
> EARCH_INDEXED|SORTCACHE)
> 
> What's that change for? (As none of the mentioned items is "BACKUP".)

Hi, sorry:
 * I took cyrus-imapd just few month ago and haven't seen that bug
   (recently upgraded as "grave"). I took maintenance because some RC
   bugs risked to expel cyrus-imapd from Buster
 * I didn't test this patch but reported does
   (https://bugs.debian.org/930764)
 * I missed to add link to the RC bug in this BTS

The bug is:

$ dpkg --configure --pending
  Setting up cyrus-common (3.0.8-6) ...
  Creating/updating cyrus user account...
  The user `cyrus' is already a member of `sasl'.
  /usr/lib/cyrus/bin/upgrade-db: Unknown type of DB: BACKUP
  dpkg: error processing package cyrus-common (--configure):
   installed cyrus-common package post-installation script subprocess
returned error exit status 1

BACKUP is listed in /usr/lib/cyrus/cyrus-db-types.txt and then required
for upgrade

Cheers,
Xavier

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)

[Ola Lundqvist]

Thank you. You can skip the delay.

Den lör 21 dec. 2019 19:12Mike Gabriel  skrev:

> Package: src:tightvnc
> Version; 1.3.9-9
> Severity: important
>
> Hi Ola et al,
>
> I have just dput tightvnc 1.3.9-9.1 targetting unstable to DELAYED/10.
>
> This is the upload's changelog:
>
> ```
> diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
> --- tightvnc-1.3.9/debian/changelog 2017-01-27 22:08:21.0 +0100
> +++ tightvnc-1.3.9/debian/changelog 2019-12-21 10:35:50.0 +0100
> @@ -1,3 +1,26 @@
> +tightvnc (1:1.3.9-9.1) unstable; urgency=medium
> +
> +  * Security upload. (Closes: #945364).
> +  * CVE-2014-6053: Check malloc() return value on client->server
> ClientCutText
> +message.
> +  * CVE-2019-8287 (aka CVE-2018-20020): Fix heap out-of-bound write
> +vulnerability inside structure in VNC client code.
> +  * CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client
> code.
> +  * CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
> +  * CVE-2018-7225: Uninitialized and potentially sensitive data could be
> +accessed by remote attackers because the msg.cct.length in
> rfbserver.c was
> +not sanitized.
> +  * CVE-2019-15678: LibVNCClient: ignore server-sent cut text longer
> than 1MB.
> +  * Extra patch similar to the fix for CVE-2019-15678: LibVNCClient:
> ignore
> +server-sent reason strings longer than 1MB (see CVE-2018-20748/
> +libvncserver).
> +  * CVE-2019-15679: rfbproto.c/InitialiseRFBConnection: Check desktop name
> +length received before allocating memory for it and limit it to 1MB.
> +  * CVE-2019-15680: Fix null-pointer-deref issue in vncviewer/zlib.c.
> +  * CVE-2019-15681: rfbserver: don't leak stack memory to the remote.
> +
> + -- Mike Gabriel   Sat, 21 Dec 2019 10:35:50 +0100
> +
>   tightvnc (1:1.3.9-9) unstable; urgency=high
>
> * Reverted the transition. Tigervnc is not ready for being a full
>
> ```
>
> The .debdiff for the made upload is attached. Please let me know, if
> you want to let it just pass through after 10 days or if I shall
> cancel the upload and do the upload to unstable yourself.
>
> Please also note my proposal to move tightvnc over under the umbrella
> of the Debian Remote Maintainers Team (debian-rem...@lists.debian.org).
>
> Thanks+Greets,
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#946864: libmatroska 1.4.9-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946864 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libmatroska
Version: 1.4.9-1+deb10u1

Explanation: bump shared library dependency to 1.4.7 since that version 
introduced new symbols

Bug#946184: fig2dev 3.2.7a-5+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946184 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.7a-5+deb10u2

Explanation: allow Fig v2 text strings ending with multiple ^A [CVE-2019-19555]

Bug#946831: freerdp2 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946831 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: freerdp2
Version: 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u1

Explanation: fix realloc return handling [CVE-2019-17177]

Bug#946467: debos 1.0.0+git20190123.d6e16be-1+b1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946467 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: debos
Version: 1.0.0+git20190123.d6e16be-1+b1

Explanation: rebuild against updated golang-github-go-debos-fakemachine

Bug#946819: atril 1.20.3-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946819 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: atril
Version: 1.20.3-1+deb10u1

Explanation: fix segfault when no documentation is needed; fix read of 
uninitialised memory [CVE-2019-11459]

Bug#946822: libvncserver 0.9.11+dfsg-1.3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946822 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libvncserver
Version: 0.9.11+dfsg-1.3+deb10u1

Explanation: rfbserver: don't leak stack memory to the remote [CVE-2019-15681]; 
resolve a freeze during connection closure and a segmentation fault on 
multi-threaded VNC servers; fix issue connecting to VMWare servers

Bug#945925: gnutls28 3.6.7-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 945925 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnutls28
Version: 3.6.7-4+deb10u1

Explanation: fix interop problems with gnutls 2.x

Bug#947134: util-linux should stop depending on fdisk

[Helmut Grohne]

Package: util-linux
Version: 2.34-0.1
Severity: wishlist
User: helm...@debian.org
Usertags: nonessentialfdisk
Control: tags -1 + moreinfo

Hi,

as discussed with Andreas Henriksson (temporary util-linux maintainer)
and others, I think that fdisk (and cfdisk and sfdisk) should not be
part of an essential Debian installation. Initially, fdisk was part of
the util-linux binary package. For buster, it was split out to a
separate fdisk binary package. Since util-linux originally shipped the
binary, a dependency from util-linux on fdisk was added. This dependency
makes fdisk pseudo-essential and unremovable. We want to get rid of that
dependency. Doing so makes an essential installation about 1MB smaller.

Before we can do that, we must ensure that other packages that use one
of the fdisk tools declare a dependency on fdisk. This has not yet
happened, which is why I am tagging this bug moreinfo. Nevertheless, I
want a bug number now to have a central place for discussions on making
fdisk non-essential.

The following packages already depend on (or recommend or suggest)
fdisk:

backupninja, boot-info-script, bootcd, cedar-backup3, clonezilla,
cloud-init, cloud-initramfs-growroot, crmsh, ddrutility, drbl,
fai-client, freedom-maker, fusioninventory-agent, ganeti,
ganeti-instance-debootstrap, gpart, grml-debootstrap, hw-probe,
libblockdev-part2, libguestfs0, live-clone, mkosi, nmon, nova-compute,
obs-worker, ocsinventory-agent, percona-toolkit, rear, reiserfsprogs,
salt-minion, uhd-host, vbackup

These packages will be unaffected by making fdisk non-essential. The
more difficult question is which packages use fdisk without declaring a
dependency on it.

To that end, I downloaded every binary package from unstable amd64. I
extracted them and grepped every file for the string "fdisk". This
includes decompressing gzip compressed files before grepping as well as
grepping control files (e.g. maintainer scripts). This resulted in
around 300 candidate packages. I further filtered the list e.g. removing
references from /usr/share/doc, locales, html files, dictionaries etc.
Then I investigated the remaining cases manually. I've arrived at the
following references:

$binarypackage $filename ($filemagic)

calamares 
./usr/lib/x86_64-linux-gnu/calamares/modules/partition/libcalamares_viewmodule_partition.so
 (ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux))
cdist 
./usr/lib/python3/dist-packages/cdist/conf/type/__install_partition_msdos/man.rst
 (ASCII text)
cdist 
./usr/lib/python3/dist-packages/cdist/conf/type/__install_partition_msdos_apply/files/lib.sh
 (POSIX shell script, ASCII text executable)
cdist 
./usr/lib/python3/dist-packages/cdist/conf/type/__install_reset_disk/gencode-remote
 (POSIX shell script, ASCII text executable)
cloud-guest-utils ./usr/bin/growpart (POSIX shell script, ASCII text executable)
cloud-image-utils ./usr/bin/mount-image-callback (Bourne-Again shell script, 
ASCII text executable)
debian-edu-config ./usr/lib/debian-edu-config/testsuite/partitioning (POSIX 
shell script, ASCII text executable)
debootstick ./usr/share/debootstick/scripts/create-image/target/rpi/formatting 
(ASCII text)
debootstick ./usr/share/debootstick/scripts/live/init/tools.sh (ASCII text)
dselect ./usr/lib/dpkg/methods/disk/setup (POSIX shell script, UTF-8 Unicode 
text executable)
dselect ./usr/lib/dpkg/methods/multicd/setup (POSIX shell script, UTF-8 Unicode 
text executable)
ecryptfs-utils ./usr/bin/ecryptfs-setup-swap (POSIX shell script, ASCII text 
executable)
ecryptfs-utils DEBIAN/postinst (POSIX shell script, ASCII text executable)
ganeti-2.16 ./usr/share/ganeti/2.16/lvmstrap (a /usr/bin/python2 script, ASCII 
text executable)
golang-github-go-easygen-easygen-dev 
./usr/share/gocode/src/github.com/go-easygen/easygen/test/sgdisk.sh (ASCII text)
golang-github-go-easygen-easygen-dev 
./usr/share/gocode/src/github.com/go-easygen/easygen/test/sgdisk.tmpl (ASCII 
text)
golang-github-go-easygen-easygen-dev 
./usr/share/gocode/src/github.com/go-easygen/easygen/test/sgdisk.txt (ASCII 
text)
golang-github-snapcore-snapd-dev 
./usr/share/gocode/src/github.com/snapcore/snapd/gadget/partition.go (ASCII 
text)
golang-github-snapcore-snapd-dev 
./usr/share/gocode/src/github.com/snapcore/snapd/gadget/partition_test.go 
(ASCII text)
guestfsd ./usr/sbin/guestfsd (ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV))
inxi ./usr/bin/inxi (Perl script text executable)
lilo ./usr/sbin/mkrescue (Bourne-Again shell script, ASCII text executable)
live-build ./usr/lib/live/build/config (POSIX shell script, ASCII text 
executable)
live-build ./usr/share/live/build/functions/defaults.sh (POSIX shell script, 
ASCII text executable)
mtd-utils ./usr/sbin/docfdisk (ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV))
open-infrastructure-system-build ./usr/lib/live/build/config (POSIX shell 
script, ASCII text executable)
open-infrastructure-system-build ./usr/share/live/build/functions/defaults.sh 
(POSIX shell script, ASCII text 

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)

[Mike Gabriel]

Package: src:tightvnc
Version; 1.3.9-9
Severity: important

Hi Ola et al,

I have just dput tightvnc 1.3.9-9.1 targetting unstable to DELAYED/10.

This is the upload's changelog:

```
diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog 2017-01-27 22:08:21.0 +0100
+++ tightvnc-1.3.9/debian/changelog 2019-12-21 10:35:50.0 +0100
@@ -1,3 +1,26 @@
+tightvnc (1:1.3.9-9.1) unstable; urgency=medium
+
+  * Security upload. (Closes: #945364).
+  * CVE-2014-6053: Check malloc() return value on client->server  
ClientCutText

+message.
+  * CVE-2019-8287 (aka CVE-2018-20020): Fix heap out-of-bound write
+vulnerability inside structure in VNC client code.
+  * CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+  * CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+  * CVE-2018-7225: Uninitialized and potentially sensitive data could be
+accessed by remote attackers because the msg.cct.length in  
rfbserver.c was

+not sanitized.
+  * CVE-2019-15678: LibVNCClient: ignore server-sent cut text longer  
than 1MB.

+  * Extra patch similar to the fix for CVE-2019-15678: LibVNCClient: ignore
+server-sent reason strings longer than 1MB (see CVE-2018-20748/
+libvncserver).
+  * CVE-2019-15679: rfbproto.c/InitialiseRFBConnection: Check desktop name
+length received before allocating memory for it and limit it to 1MB.
+  * CVE-2019-15680: Fix null-pointer-deref issue in vncviewer/zlib.c.
+  * CVE-2019-15681: rfbserver: don't leak stack memory to the remote.
+
+ -- Mike Gabriel   Sat, 21 Dec 2019 10:35:50 +0100
+
 tightvnc (1:1.3.9-9) unstable; urgency=high

   * Reverted the transition. Tigervnc is not ready for being a full

```

The .debdiff for the made upload is attached. Please let me know, if  
you want to let it just pass through after 10 days or if I shall  
cancel the upload and do the upload to unstable yourself.


Please also note my proposal to move tightvnc over under the umbrella  
of the Debian Remote Maintainers Team (debian-rem...@lists.debian.org).


Thanks+Greets,
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net

diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog 2017-01-27 22:08:21.0 +0100
+++ tightvnc-1.3.9/debian/changelog 2019-12-21 10:35:50.0 +0100
@@ -1,3 +1,26 @@
+tightvnc (1:1.3.9-9.1) unstable; urgency=medium
+
+  * Security upload. (Closes: #945364).
+  * CVE-2014-6053: Check malloc() return value on client->server ClientCutText
+message.
+  * CVE-2019-8287 (aka CVE-2018-20020): Fix heap out-of-bound write
+vulnerability inside structure in VNC client code.
+  * CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+  * CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+  * CVE-2018-7225: Uninitialized and potentially sensitive data could be
+accessed by remote attackers because the msg.cct.length in rfbserver.c was
+not sanitized.
+  * CVE-2019-15678: LibVNCClient: ignore server-sent cut text longer than 1MB.
+  * Extra patch similar to the fix for CVE-2019-15678: LibVNCClient: ignore
+server-sent reason strings longer than 1MB (see CVE-2018-20748/
+libvncserver).
+  * CVE-2019-15679: rfbproto.c/InitialiseRFBConnection: Check desktop name
+length received before allocating memory for it and limit it to 1MB.
+  * CVE-2019-15680: Fix null-pointer-deref issue in vncviewer/zlib.c.
+  * CVE-2019-15681: rfbserver: don't leak stack memory to the remote.
+
+ -- Mike Gabriel   Sat, 21 Dec 2019 10:35:50 +0100
+
 tightvnc (1:1.3.9-9) unstable; urgency=high
 
   * Reverted the transition. Tigervnc is not ready for being a full
diff -Nru tightvnc-1.3.9/debian/patches/CVE-2014-6053.patch 
tightvnc-1.3.9/debian/patches/CVE-2014-6053.patch
--- tightvnc-1.3.9/debian/patches/CVE-2014-6053.patch   1970-01-01 
01:00:00.0 +0100
+++ tightvnc-1.3.9/debian/patches/CVE-2014-6053.patch   2019-12-19 
21:39:14.0 +0100
@@ -0,0 +1,29 @@
+From 6037a9074d52b1963c97cb28ea1096c7c14cbf28 Mon Sep 17 00:00:00 2001
+From: Nicolas Ruff 
+Date: Mon, 18 Aug 2014 15:16:16 +0200
+Subject: [PATCH] Check malloc() return value on client->server ClientCutText
+ message. Client can send up to 2**32-1 bytes of text, and such a large
+ allocation is likely to fail in case of high memory pressure. This would in a
+ server crash (write at address 0).
+
+[sunweaver] port libvncserver patch over to tightvnc's vnc server code
+
+---
+ libvncserver/rfbserver.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+--- a/Xvnc/programs/Xserver/hw/vnc/rfbserver.c
 b/Xvnc/programs/Xserver/hw/vnc/rfbserver.c
+@@ -891,6 +891,12 @@
+ 
+   str = (char *)xalloc(msg.cct.length);

Bug#947132: nspr: please package version 4.24

[Carsten Schoenert]

On Sat, Dec 21, 2019 at 06:33:08PM +0100, Carsten Schoenert wrote:
> requires NSS by version >= 4.24.

Damn c, I mean aof NSPR here.

Regards
Carsten

Bug#938528: sphinx: Python2 removal in sid/bullseye

[Nicolas Boulenguez]

Package: src:sphixn
Followup-For: Bug #938528
Control: unblock 938528 by 936624

gnat-gps embeds a python2 interpreter, but its documentation already
builds with python3.

Bug#947132: nspr: please package version 4.24

[Carsten Schoenert]

Source: nspr
Severity: wishlist

Hello Mike,

could you please package the current version 4.24 of NSPR.

I'm trying to build a recent beta version of Thunderbird but this
requires NSS by version >= 4.24.

Thanks!

Carsten

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

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

Bug#947131: nss: please package version 3.48

[Carsten Schoenert]

Source: nss
Severity: wishlist

Hello Mike,

could you please package the current version 3.48 of NSS.

I'm trying to build a recent beta version of Thunderbird but this
requires NSS by version >= 3.48.

Thanks!

Carsten

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

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

Bug#936924: Moving libsvm to Debian Science team

[Andreas Tille]

Hi Chen-Tse,

thanks for you quick response.

On Sat, Dec 21, 2019 at 09:48:14AM -0500, Chen-Tse Tsai wrote:
> Hi, Andreas,
> 
> I agree with your suggestions. Thanks for putting it on salsa!

Thanks for confirming.
 
> Should I investigate dropping python2? I can spend some time this week on
> this. But I may need help with debian stuff.

What exact help do you need?  Do you have a login on Salsa?  We could
add you to science-team to grant you commit permissions.  I admit I have
not yet looked into the packaging - just realised that its cdbs which is
unfortunate since it would not eliminate the Python2 dependency fully.

Kind regards

  Andreas. 
 
> On Sat, Dec 21, 2019 at 7:39 AM Andreas Tille  wrote:
> 
> > On Sat, Dec 21, 2019 at 08:28:57AM +, Mo Zhou wrote:
> > > I second this proposal, and the same for src:liblinear.
> >
> > That's done as I wrote.
> >
> > > These are high popcon packages, dependencies for a number of other
> > > packages. They should be team maintained to unblock important fixes.
> >
> > To push a bit I just commited
> >
> >https://salsa.debian.org/science-team/libsvm
> >
> > Last maintainer upload was more than 3 years ago, 2 NMUs inbetween,
> > package is lagging behind upstream.  Anybody is kindly invited to adapt
> > the packaging (I think we should really get rid of cdbs since this in
> > turn is Python2) and proceed from here.
> >
> > Kind regards
> >
> >  Andreas.
> >
> >
> > > On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> > > > Hi Chen-Tse,
> > > >
> > > > I'm maintaining a package that depends from libsvm.  Due to bug #936924
> > > > that did not received any response since August it is in danger to be
> > > > removed from testing so I'm interested that this bug will be fixed.
> > > > When looking at the package I realised that while it would fit into
> > > > Debian Science team scope it is not team maintained nor is there any
> > > > repository in Salsa.  That's why I have the following suggestion:
> > > >
> > > >   1. I create a repository on Salsa
> > > >   2. Move the package to Debian Science team maintenance
> > > >  and add you as Uploader
> > > >   3. Drop Python2 package and close bug #936924
> > > >   4. May be migrate packaging from cdbs to dh
> > > >
> > > > If I do not hear from you until Monday I assume you agree with this
> > > > plan and will do so.
> > > >
> > > > Kind regards
> > > >
> > > >  Andreas.
> > > >
> > > > PS: @Christian: I noticed that you and Chen-Tse are maintaining
> > > > liblinear.  I have just removed Python2 package and reassigned
> > > > #936889 to ftp.debian.org to make sure python-liblinear will be
> > > > removed.  Thus libsvm can be dealt as suggested.
> > > >
> > > > --
> > > > http://fam-tille.de
> > > >
> > >
> > >
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Nicolas Boulenguez]

Package: src:texlive-extra
Followup-For: Bug #938656
Control: unblock 938656 by 936624

gnat-gps embeds a python2 interpreter, but its documentation already
builds with python3.

Bug#947130: please provide a backport for buster

[Martin]

Source: python-dbussy
Version: 1.2.1-1
Severity: wishlist

Please provide a backport for buster.

Bug#946918: transition: libcgns

[Gilles Filippini]

Hi,

Paul Gevers a écrit le 19/12/2019 à 21:29 :
> Hi Gilles,
> 
> On 17-12-2019 23:07, Gilles Filippini wrote:
>> Paul Gevers a écrit le 17/12/2019 à 22:31 :
 I'd like to transition libcgns 3.4.0 which has been staging into 
 experimental
 for more than a month. There are very few reverse depedencies:
 * paraview
 * code-saturne
 and maybe gmsh which build-depends on libcgns-dev but has no binary package
 depending on libcgns3.3.
 I've built all these packages against libcgns 3.4.0 without issue so far.
>>>
>>> Go ahead, thanks.
>>
>> Uploaded.
> 
> paraview FTBFS on mips64el where the same version built before. Maybe
> you want to have a quick look. Don't worry *too* much about it as the
> package is only in sid and has armel, armhf and mipsel failing as well
> already before the transition, so it needs more investigation and a new
> version already to migrate to testing.

I've just had a look. It fails with this message:
E: Build killed with signal TERM after 150 minutes of inactivity

Building paraview is very demanding on resources, and this failure may
just be related to the buildd machine it was built on. Is it possible to
force a build on the same machine it was previously successfully built?
It is mipsel-sil-01.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#936932: libvigraimpex: Python2 removal in sid/bullseye

[Andreas Metzler]

On 2019-12-21 Andreas Metzler  wrote:
> On 2019-12-21 Andreas Metzler  wrote:
> > On 2019-10-01 Andreas Tille  wrote:
> > > Control: tags -1 help

> > > Hi,

> > > I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> > > managed.

> > Hello Andreas,

> > I did not get far trying to build what is currently on salsa:
> [...]

> I have now made progress to a successful build. Will post a patch series
> or merge request today or tomorrow.

See https://salsa.debian.org/science-team/libvigraimpex/merge_requests/1

cu Andreas

Bug#947129: x2goclient: regression caused by CVE-2019-14889/libssh fix

[Mike Gabriel]

Package: x2goclient
Version: 4.1.2.1-3
Severity: serious
Control: found -1 4.0.3.1-4
Control: found -1 4.0.5.2-2

the recent libssh fix for CVE-2019-14889 causes a regresion in X2Go Client:

```
Connection failed. Couldn't create remote file  
~/.x2go/ssh/key.X18947 - SCP: Warning: status code 1 received:  
scp: ~/.x2go/ssh: No such file or directory"

```

The solution to this is a fix to be applied against X2Go Client (in  
jessie/stretch/buster/unstable):

https://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=ce559d1

light+love
Mike

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpkdWRqQ3o_N.pgp
Description: Digitale PGP-Signatur

Bug#947128: ITP: eshell-z -- cd to frequent directory in eshell

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: eshell-z
  Version : 0.4
  Upstream Author : Chunyang Xu 
* URL or Web page : https://github.com/xuchunyang/eshell-z
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : cd to frequent directory in eshell

It is an Emacs port of z. It keeps track of where you’ve been and how
many commands you invoke there, and provides a convenient way to jump
to the directories you actually use. eshell-z and z can work together
by sharing the same data file.

Bug#947127: npm: CVE-2019-16775 CVE-2019-16776 CVE-2019-16777

[Salvatore Bonaccorso]

Source: npm
Version: 5.8.0+ds6-4
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for npm.

CVE-2019-16775[0]:
| Versions of the npm CLI prior to 6.13.3 are vulnerable to an Arbitrary
| File Write. It is possible for packages to create symlinks to files
| outside of thenode_modules folder through the bin field upon
| installation. A properly constructed entry in the package.json bin
| field would allow a package publisher to create a symlink pointing to
| arbitrary files on a user#8217;s system when the package is
| installed. This behavior is still possible through install scripts.
| This vulnerability bypasses a user using the --ignore-scripts install
| option.


CVE-2019-16776[1]:
| Versions of the npm CLI prior to 6.13.3 are vulnerable to an Arbitrary
| File Write. It fails to prevent access to folders outside of the
| intended node_modules folder through the bin field. A properly
| constructed entry in the package.json bin field would allow a package
| publisher to modify and/or gain access to arbitrary files on a
| user#8217;s system when the package is installed. This behavior
| is still possible through install scripts. This vulnerability bypasses
| a user using the --ignore-scripts install option.


CVE-2019-16777[2]:
| Versions of the npm CLI prior to 6.13.4 are vulnerable to an Arbitrary
| File Overwrite. It fails to prevent existing globally-installed
| binaries to be overwritten by other package installations. For
| example, if a package was installed globally and created a serve
| binary, any subsequent installs of packages that also create a serve
| binary would overwrite the previous serve binary. This behavior is
| still allowed in local installations and also through install scripts.
| This vulnerability bypasses a user using the --ignore-scripts install
| option.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16775
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16775
[1] https://security-tracker.debian.org/tracker/CVE-2019-16776
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16776
[2] https://security-tracker.debian.org/tracker/CVE-2019-16777
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16777

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#947126: ITP: gajim-lengthnotifier -- displays character count and notifies when maximum length is reached

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: gajim-lengthnotifier
  Version : 1.2.2
  Upstream Author : Mateusz Biliński 
* URL : 
https://dev.gajim.org/gajim/gajim-plugins/wikis/LengthNotifierPlugin
* License : GPL3
  Programming Lang: Python
  Description : displays character count and notifies when maximum length 
is reached

User will be notified when the length of the message you are
typing reaches a configured limit. A character counter can
optionally be displayed.

Package will be maintained by the XMPP team.

Bug#947125: buster-pu: package cyrus-imapd/3.0.8-6+deb10u4

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2019-12-21 at 14:43 +0100, Xavier Guimard wrote:
> cyrus-imapd has a RC bug. This little patch tested by reporters fixes
> the problem.

Fun timing, given +deb10u3 only just went through security... :-p

+cyrus-imapd (3.0.8-6+deb10u4) buster; urgency=medium
+
+  * Add BACKUP type to cyrus-upgrade-db (Closes: #930764)
[...]
-   DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN)
+   DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN|CONVERSATIONS|S
EARCH_INDEXED|SORTCACHE)

What's that change for? (As none of the mentioned items is "BACKUP".)

Regards,

Adam

Bug#947120: vim-nox: :syn contains=TOP inside a :syn-include'd file refers to the outer file

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, Dec 21, 2019 at 11:09:39 +:
>* What was the outcome of this action?
> 
> When the file iota is viewed with «set filetype=foo», the words "lorem
> ipsum" on line 1 are not highlighted.
> 
>* What outcome did you expect instead?
> 
> I expected those two words on line 1 to be highlighted (via the chain
> TOP -> fooBlock -> @bar -> barBlock -> barKeyword).
> 
> I note that if contains=TOP is either removed, or changed to
> contains=@bar, then the words on line 1 do get highlighted.  However,
> either of these changes would break the highlighting of ft=bar files.

Changing contains=TOP to contains=barKeyword also causes the words on
line 1 to be highlighted.  Since «:help syn-contains» defines "TOP" as
"all groups that aren't 'contained'", and barKeyword isn't 'contained',
I would have expected contains=TOP to imply contains=barKeyword.

> It seems to me that when «contains=TOP» is encountered in a
> :syn-include'd file, it's taken as a reference to the actual top-level,
> i.e., the top of foo.vim, rather than as a reference to the top of the
> included syntax's scope, i.e., the syntax match or region that did
> «contains=@bar».

According to syntax.c:in_id_list(), "TOP" is indeed supposed to only
accept groups that are defined in the same file (i.e., bar.vim).

Cheers,

Daniel

Bug#936924: Moving libsvm to Debian Science team

[Chen-Tse Tsai]

Hi, Andreas,

I agree with your suggestions. Thanks for putting it on salsa!

Should I investigate dropping python2? I can spend some time this week on
this. But I may need help with debian stuff.

Thanks,
Chen-Tse


On Sat, Dec 21, 2019 at 7:39 AM Andreas Tille  wrote:

> On Sat, Dec 21, 2019 at 08:28:57AM +, Mo Zhou wrote:
> > I second this proposal, and the same for src:liblinear.
>
> That's done as I wrote.
>
> > These are high popcon packages, dependencies for a number of other
> > packages. They should be team maintained to unblock important fixes.
>
> To push a bit I just commited
>
>https://salsa.debian.org/science-team/libsvm
>
> Last maintainer upload was more than 3 years ago, 2 NMUs inbetween,
> package is lagging behind upstream.  Anybody is kindly invited to adapt
> the packaging (I think we should really get rid of cdbs since this in
> turn is Python2) and proceed from here.
>
> Kind regards
>
>  Andreas.
>
>
> > On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> > > Hi Chen-Tse,
> > >
> > > I'm maintaining a package that depends from libsvm.  Due to bug #936924
> > > that did not received any response since August it is in danger to be
> > > removed from testing so I'm interested that this bug will be fixed.
> > > When looking at the package I realised that while it would fit into
> > > Debian Science team scope it is not team maintained nor is there any
> > > repository in Salsa.  That's why I have the following suggestion:
> > >
> > >   1. I create a repository on Salsa
> > >   2. Move the package to Debian Science team maintenance
> > >  and add you as Uploader
> > >   3. Drop Python2 package and close bug #936924
> > >   4. May be migrate packaging from cdbs to dh
> > >
> > > If I do not hear from you until Monday I assume you agree with this
> > > plan and will do so.
> > >
> > > Kind regards
> > >
> > >  Andreas.
> > >
> > > PS: @Christian: I noticed that you and Chen-Tse are maintaining
> > > liblinear.  I have just removed Python2 package and reassigned
> > > #936889 to ftp.debian.org to make sure python-liblinear will be
> > > removed.  Thus libsvm can be dealt as suggested.
> > >
> > > --
> > > http://fam-tille.de
> > >
> >
> >
>
> --
> http://fam-tille.de
>

Bug#947081: fixed in fribidi 1.0.8-2

[gregor herrmann]

On Sat, 21 Dec 2019 02:35:48 +, أحمد المحمودي (Ahmed El-Mahmoudy) wrote:

>  fribidi (1.0.8-2) unstable; urgency=medium
>  .
>* Add  revert_log2vis_get_embedding_levels.diff patch to revert back
>  fribidi_log2vis_get_embedding_levels function.
>  It seems to be removed by mistake by upstream, since its documentation is
>  still there (Closes: #947081)
>* Revert last update to symbols file

Thanks for the quick fix!

I can confirm that libtext-bidi-perl indeed builds/tests/runs again
as expected.

pyfribidi still has an interesting failure in its autopkgtests but I
don't know if this is a problem of fribidi or pyfribidi:

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pyfribidi/3712389/log.gz


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#867123: [PATCH] mdoc: Update operating system release numbers

[Ingo Schwarze]

Hello Colin and Guillem,

Colin Watson wrote on Tue, Dec 17, 2019 at 01:15:30PM +:
> On Tue, Dec 17, 2019 at 01:14:06PM +, Colin Watson wrote:

>> Based on a patch from Guillem Jover .
>> 
>> * tmac/doc-common-u: Update NetBSD, OpenBSD, FreeBSD, Darwin, and
>> DragonFly version strings.
>> 
>> * tmac/groff_mdoc.7.man: Synchronize.

> Side note: I am not the biggest fan of this business of encoding a bunch
> of other projects' release history in groff, so please don't take me as
> an advocate of that.  However, I am generally an advocate of the
> position that if one is going to encode this sort of thing then it makes
> sense to keep it up to date.

I completely agree with all you are saying here.

Consequently, i just pushed the patch to the upstream groff repository,
with the following tweaks:

 * I included the following versions which appeared to be missing:
- NetBSD 6.0.6 and 7.2
- DragonFly 3.0.2 and 3.2.2

 * I did *not* include the following releases because x.y.0 are not
   included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0.
   I'm not a DragonFly user and i'm not completely sure what would make
   most sense for that system, so i just stuck to existing practice as
   best i could.

I do think that removing version verification and just printing
whatever the manual page author requests in the same way as mandoc(1)
is already doing it would be an improvement, but that should be discussed
separately, not in this ticket.

Thanks for your patch,
  Ingo

Bug#947125: buster-pu: package cyrus-imapd/3.0.8-6+deb10u4

[Xavier Guimard]

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

Hi,

cyrus-imapd has a RC bug. This little patch tested by reporters fixes
the problem.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 391230f..c96adf9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cyrus-imapd (3.0.8-6+deb10u4) buster; urgency=medium
+
+  * Add BACKUP type to cyrus-upgrade-db (Closes: #930764)
+
+ -- Xavier Guimard   Sat, 21 Dec 2019 14:39:58 +0100
+
 cyrus-imapd (3.0.8-6+deb10u3) buster-security; urgency=medium
 
   * Add patch to avoid mailbox creation as administrator
diff --git a/debian/cyrus-upgrade-db b/debian/cyrus-upgrade-db
index d7037b2..c50a4ce 100755
--- a/debian/cyrus-upgrade-db
+++ b/debian/cyrus-upgrade-db
@@ -62,6 +62,7 @@ upgradealldb() {
 
DO_UPGRADE_DB=
if [ "${NEW_DBVALUE}" != "${OLD_DBVALUE}" ] ; then
+   echo "Upgrading $OLD_DBKEY from $OLD_DBVALUE to $NEW_DBVALUE ..."
DO_UPGRADE_DB=yes
fi
 
@@ -82,11 +83,14 @@ upgradealldb() {
return 1
fi
;;
-   DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN)
+   
DUPLICATE|PTS|STATUSCACHE|TLS|ZONEINFO|SEEN|CONVERSATIONS|SEARCH_INDEXED|SORTCACHE)
;;
USERDENY)
DBFILE=user_deny.db
;;
+   BACKUP)
+   DBFILE=backups.db
+   ;;
*)
echo "$0: Unknown type of DB: $OLD_DBKEY" 1>&2
return 1

Bug#945920: Chromium segfaults - backtraces

[Michel Meyers]

Thanks to Jaap Joris Vens for helping me figure out why my dumb ass 
couldn't find the debug package with apt-cache (they're in a separate 
repo now as the README points out).


I've discovered two interesting things, the first one is possibly 
unrelated:


1. I can reliably cause Chromium to SIGSEGV by opening the Task Manager 
(Ctrl+Esc). Here's a backtrace from such a crash:



Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x5a77cf87 in 
memory_instrumentation::MemoryInstrumentation::RequestPrivateMemoryFootprint(int, 
base::OnceCallbackstd::unique_ptrstd::default_delete >)>) ()

(gdb) bt
#0  0x5a77cf87 in 
memory_instrumentation::MemoryInstrumentation::RequestPrivateMemoryFootprint(int, 
base::OnceCallbackstd::unique_ptrstd::default_delete >)>) ()

#1  0x591baaa9 in task_manager::TaskManagerImpl::Refresh() ()
#2  0x593e7c76 in base::RepeatingTimer::RunUserTask() ()
#3  0x593b5165 in base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) ()
#4  0x593c466b in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, 
bool*) ()
#5  0x593c5fec in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() 
()
#6  0x59376aca in base::(anonymous 
namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
#7  0x77064f2e in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x770651c8 in  () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7706525c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x59376dd0 in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#11 0x593c62a9 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, 
base::TimeDelta) ()

#12 0x593a22fa in base::RunLoop::Run() ()
#13 0x58ea8217 in 
ChromeBrowserMainParts::MainMessageLoopRun(int*) ()
#14 0x571cd1c6 in 
content::BrowserMainLoop::RunMainMessageLoopParts() ()

#15 0x571cd375 in content::BrowserMainRunnerImpl::Run() ()
#16 0x571a35f7 in 
content::BrowserMain(content::MainFunctionParams const&) ()
#17 0x58e30101 in 
content::RunBrowserProcessMain(content::MainFunctionParams const&, 
content::ContentMainDelegate*) ()
#18 0x58e30338 in 
content::ContentMainRunnerImpl::RunServiceManager(content::MainFunctionParams&, 
bool) ()

#19 0x58e306a7 in content::ContentMainRunnerImpl::Run(bool) ()
#20 0x58e66802 in 
service_manager::Main(service_manager::MainParams const&) ()
#21 0x58e2e0c6 in 
content::ContentMain(content::ContentMainParams const&) ()

#22 0x5635c3e5 in ChromeMain ()
#23 0x704a1bbb in __libc_start_main (main=
0x56339f80 , argc=1, argv=0x7fffe168, init=out>, fini=, rtld_fini=, 
stack_end=0x7fffe158)

at ../csu/libc-start.c:308
#24 0x5635c22a in _start ()
(gdb)


Might be an unrelated issue though.

2. While running in gbd and watching a YouTube video in full screen, I 
tried to pause it and couldn't (no cursor, YouTube UI not showing up), 
only to find it had segfaulted randomly. The video continued to play 
until I killed the process. This is that backtrace:



Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x5a77cee7 in 
memory_instrumentation::MemoryInstrumentation::RequestGlobalDump(std::vectorstd::char_traits, std::allocator >, 
std::allocator, 
std::allocator > > > const&, base::OnceCallbackstd::unique_ptrstd::default_delete >)>) ()

(gdb) bt
#0  0x5a77cee7 in 
memory_instrumentation::MemoryInstrumentation::RequestGlobalDump(std::vectorstd::char_traits, std::allocator >, 
std::allocator, 
std::allocator > > > const&, base::OnceCallbackstd::unique_ptrstd::default_delete >)>) ()
#1  0x58f8ddb0 in 
ProcessMemoryMetricsEmitter::FetchAndEmitProcessMemoryMetrics() ()
#2  0x58f85e82 in (anonymous namespace)::RecordMemoryMetrics() 
()
#3  0x593b5165 in base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) ()
#4  0x593c466b in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, 
bool*) ()
#5  0x593c5fec in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() 
()
#6  0x59376aca in base::(anonymous 
namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
#7  0x77064f2e in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x770651c8 in  () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7706525c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x59376dd0 in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#11 0x593c62a9 in 

Bug#947124: apache-log4j1.2: CVE-2019-17571

[Salvatore Bonaccorso]

Source: apache-log4j1.2
Version: 1.2.17-8
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1.2.17-7
Control: found -1 1.2.17-5

Hi,

The following vulnerability was published for apache-log4j1.2.

CVE-2019-17571[0]:
| Included in Log4j 1.2 is a SocketServer class that is vulnerable to
| deserialization of untrusted data which can be exploited to remotely
| execute arbitrary code when combined with a deserialization gadget
| when listening to untrusted network traffic for log data. This affects
| Log4j versions up to 1.2 up to 1.2.17.

Note that this issue correponds to the old CVE-2017-5645 for the 2.x
branch codebasis[1].

1.2 reached end of life in 2015 accordingly, and the "right move"
would be to switch to 2.x. Which raises a question from security
support point of view: We would need to fade out apache-log4j1.2 for
bullseye at least now right? From a quick check via a simulated dak
rm, it looks right now impossible to actually remove it. Are there
current plans from the Debian Java Maintainers for that? Or is there
something I currently just miss from the big picture?

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-17571
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
[1] https://www.openwall.com/lists/oss-security/2019/12/19/2

Regards,
Salvatore

Bug#947123: apt package list in resulting system cannot be cleared using hooks, increases the image size

[nodiscc]

Package: live-build
Version: 1:20190311
Debian 10 Buster

Dear Maintainer,

I noticed that the /var/lib/apt/lists/ directory in the squashfs
contains about 162MB of files after the build. This makes my ISO image
slightly larger than the expected max size of 2GB (small USB drives,
ISO hosting restrictions). My config/archives/debian.list.chroot:

deb https://deb.debian.org/debian/ buster main contrib non-free
deb http://security.debian.org/ buster/updates main contrib non-free
deb https://deb.debian.org/debian/ buster-updates main contrib non-free
deb https://deb.debian.org/debian/ buster-backports main contrib non-free

In an attempt to decrease the size of the ISO image, I added this to
config/hooks/normal/0900-clear-apt-cache.hook.chroot and made it
executable:

#!/bin/sh
# clear APT package download cache to reduce the image size
rm -vr /var/lib/apt/lists/

By reading build.log I can confirm that the hook does run during the
process; and clears out the directory, however one of the following
build steps must have put those files in place again, because they are
still present in the squashfs/live system.

I can see the following solutions:
- Something is wrong with my hook (what?) and I should correct it
- live-build should implement a built-in way to clear
/var/lib/apt/lists before the squashfs is generated
- live-build should implement a way to run custom hooks just before
the squashfs is generated

Workarounds very welcome, thanks in advance

Bug#947122: RFS: paperwork/1.3.0-1 [ITP] -- Personal document manager

[Thomas Perret]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: paperwork
   Version : 1.3.0-1
   Upstream Author : https://groups.google.com/forum/#!forum/paperwork-gui
 * URL : https://openpaper.work
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/openpaperwork-team/paperwork
   Section : python

It builds those binary packages:

  paperwork-backend - Personal document manager
  paperwork-gtk - Paperwork is a personal document manager - GTK3 frontend
  paperwork-gtk-l10n-en - Gui for paperwork-backend - French localization
  paperwork-gtk-l10n-fr - Gui for paperwork-backend - English localization
  paperwork-gtk-l10n-de - Gui for paperwork-backend - German localization
  paperwork-gtk-l10n-uk - Gui for paperwork-backend - Ukrainian localization

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/paperwork/paperwork_1.3.0-1.dsc

Changes since the last upload:

   * Initial release (Closes: #721287)

Regards,

--
  Thomas Perret

Bug#936932: libvigraimpex: Python2 removal in sid/bullseye

[Andreas Metzler]

On 2019-12-21 Andreas Metzler  wrote:
> On 2019-10-01 Andreas Tille  wrote:
> > Control: tags -1 help

> > Hi,

> > I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> > managed.

> Hello Andreas,

> I did not get far trying to build what is currently on salsa:
[...]

I have now made progress to a successful build. Will post a patch series
or merge request today or tomorrow.

[...]
> I suspect Fedora's patch would help.
> https://src.fedoraproject.org/rpms/vigra/blob/master/f/vigra-1.11.1.py37.patch

it does.

cu Andreas

Bug#936924: Moving libsvm to Debian Science team

[Andreas Tille]

On Sat, Dec 21, 2019 at 08:28:57AM +, Mo Zhou wrote:
> I second this proposal, and the same for src:liblinear.

That's done as I wrote.
 
> These are high popcon packages, dependencies for a number of other
> packages. They should be team maintained to unblock important fixes.

To push a bit I just commited

   https://salsa.debian.org/science-team/libsvm

Last maintainer upload was more than 3 years ago, 2 NMUs inbetween,
package is lagging behind upstream.  Anybody is kindly invited to adapt
the packaging (I think we should really get rid of cdbs since this in
turn is Python2) and proceed from here.

Kind regards

 Andreas.


> On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> > Hi Chen-Tse,
> > 
> > I'm maintaining a package that depends from libsvm.  Due to bug #936924
> > that did not received any response since August it is in danger to be
> > removed from testing so I'm interested that this bug will be fixed.
> > When looking at the package I realised that while it would fit into
> > Debian Science team scope it is not team maintained nor is there any
> > repository in Salsa.  That's why I have the following suggestion:
> > 
> >   1. I create a repository on Salsa
> >   2. Move the package to Debian Science team maintenance
> >  and add you as Uploader
> >   3. Drop Python2 package and close bug #936924
> >   4. May be migrate packaging from cdbs to dh
> > 
> > If I do not hear from you until Monday I assume you agree with this
> > plan and will do so.
> > 
> > Kind regards
> > 
> >  Andreas.
> > 
> > PS: @Christian: I noticed that you and Chen-Tse are maintaining
> > liblinear.  I have just removed Python2 package and reassigned
> > #936889 to ftp.debian.org to make sure python-liblinear will be
> > removed.  Thus libsvm can be dealt as suggested.
> > 
> > -- 
> > http://fam-tille.de
> > 
> 
> 

-- 
http://fam-tille.de

Bug#947121: doxygen: Incorrect invocation of ghostscript (breaks with 9.50)

[Andreas Metzler]

Source: doxygen
Version: 1.8.16-1
Severity: important
Tags: patch upstream

Hello,

doxygen incorrectly invokes ghostscript which breaks e.g. building
libvigraimpex:
---
Transcript written on _formulas.log.
Error: /undefinedfilename in (_form0.ps)
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push
Dictionary stack:
   --dict:730/1123(ro)(G)--   --dict:0/20(G)--   --dict:76/200(L)--
Current allocation mode is local
Last OS error: Permission denied
GPL Ghostscript 9.50: Unrecoverable error, exit code 1
error: Problem running ghostscript gs -q -g130x104 -r614x614x -sDEVICE=ppmraw 
-sOutputFile=_form0.pnm -dNOPAUSE -dBATCH -- _form0.ps. Check your installation!
---

This is fixed in upstream GIT, see 
https://github.com/doxygen/doxygen/issues/7290

cu Andreas
diff -Nru doxygen-1.8.16/debian/changelog doxygen-1.8.16/debian/changelog
--- doxygen-1.8.16/debian/changelog	2019-12-10 23:48:20.0 +0100
+++ doxygen-1.8.16/debian/changelog	2019-12-21 10:41:35.0 +0100
@@ -1,3 +1,11 @@
+doxygen (1.8.16-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Pull fix for https://github.com/doxygen/doxygen/issues/7290 from upstream
+GIT.
+
+ -- Andreas Metzler   Sat, 21 Dec 2019 10:41:35 +0100
+
 doxygen (1.8.16-1) unstable; urgency=medium
 
   [ Steve Langasek ]
diff -Nru doxygen-1.8.16/debian/patches/0001-issue-7290-error-Problem-running-ghostscript-gs-q-g5.patch doxygen-1.8.16/debian/patches/0001-issue-7290-error-Problem-running-ghostscript-gs-q-g5.patch
--- doxygen-1.8.16/debian/patches/0001-issue-7290-error-Problem-running-ghostscript-gs-q-g5.patch	1970-01-01 01:00:00.0 +0100
+++ doxygen-1.8.16/debian/patches/0001-issue-7290-error-Problem-running-ghostscript-gs-q-g5.patch	2019-12-21 10:41:35.0 +0100
@@ -0,0 +1,39 @@
+From f08e87623368134c6541af12995b811ef9aff069 Mon Sep 17 00:00:00 2001
+From: albert-github 
+Date: Tue, 12 Nov 2019 11:42:22 +0100
+Subject: [PATCH] issue #7290 error: Problem running ghostscript gs -q -g562x56
+ -r384x384x -sDEVICE=ppmraw -sOutputFile=_form0.pnm -dNOPAUSE -dBATCH --
+ _form0.ps. Check your installation!
+
+@maehr had a talk with Robin Watts and Ken Sharp at IRC and there seem to be basically 3 different problems:
+* `-r%dx%d` (the dimension for `r` shouldn't be `-r384x384x`, but `-r384x384`),
+* misuse / unnecessary use of `--` and
+* since 9.50 the command needs more control access (that might be worked around by either whitelisting the file via `--permit-file-read=_form0.eps` (only works from 9.50 and upwards) or generally accepting any file with `-dNOSAFER` (works since quite some time). The second option is considered to be unsafe if we would process any file, but in this case we process self produced / controlled files. I don't know if doxygen has any threat model that it assumes. ).
+
+> Ken Sharp: Yeah the %dx is wrong, as Robin says its sheer luck that works
+the -- isn't needed and is what's causing the first problem
+and file control is the new bugbear
+
+The suggestions have been implemented and test / docs works now with old and new version.
+---
+ src/formula.cpp | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/formula.cpp b/src/formula.cpp
+index 534f56ac..3d8e6ce1 100644
+--- a/src/formula.cpp
 b/src/formula.cpp
+@@ -193,8 +193,8 @@ void FormulaList::generateBitmaps(const char *path)
+   // used.  
+ 
+   char gsArgs[4096];
+-  sprintf(gsArgs,"-q -g%dx%d -r%dx%dx -sDEVICE=ppmraw "
+-"-sOutputFile=%s.pnm -dNOPAUSE -dBATCH -- %s.ps",
++  sprintf(gsArgs,"-q -g%dx%d -r%dx%d -sDEVICE=ppmraw "
++"-sOutputFile=%s.pnm -dNOPAUSE -dBATCH -dNOSAFER %s.ps",
+ gx,gy,(int)(scaleFactor*72),(int)(scaleFactor*72),
+ formBase.data(),formBase.data()
+  );
+-- 
+2.24.0
+
diff -Nru doxygen-1.8.16/debian/patches/series doxygen-1.8.16/debian/patches/series
--- doxygen-1.8.16/debian/patches/series	2019-12-10 19:12:28.0 +0100
+++ doxygen-1.8.16/debian/patches/series	2019-12-21 10:41:35.0 +0100
@@ -13,3 +13,4 @@
 faketime_pdflatex.diff
 libatomic.diff
 blank-file-patterns.diff
+0001-issue-7290-error-Problem-running-ghostscript-gs-q-g5.patch

Bug#947120: vim-nox: :syn contains=TOP inside a :syn-include'd file refers to the outer file

[Daniel Shahaf]

Package: vim-nox
Version: 2:8.1.2269-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

I wanted to write a custom syntax file that includes another syntax file.

(Specifically, I wanted to write a syntax filefor zsh's test suite, and
have it include the zsh syntax file shipped with Vim itself.  zsh's test
suite consists of test cases, that should be highlighted as zsh scripts,
plus metadata such as the expected exit code, which would be highlighted
by the custom syntax file I was writing.)

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

To cut a long story short, here's a minimal example:

% head -999 .vim/syntax/foo.vim .vim/syntax/bar.vim iota
==> .vim/syntax/foo.vim <==
if exists("b:current_syntax")
  finish
endif

syntax clear
syntax include @bar :p:h/bar.vim
unlet b:current_syntax
syntax region fooBlock start=/^\s/ end=/$/ contains=@bar

let b:current_syntax = "foo"

==> .vim/syntax/bar.vim <==
if exists("b:current_syntax")
  finish
endif

syntax clear
syntax region barBlock matchgroup=barBraces start=+{+ end=+}+ 
transparent contains=TOP
syntax keyword barKeyword lorem ipsum

hi def link barBraces  Special
hi def link barKeyword Keyword

let b:current_syntax = "bar"

==> iota <==
  { lorem ipsum dolor sit amet }
  lorem ipsum dolor sit amet
% 

(For orientation, in this example foo.vim stands for my custom syntax,
bar.vim stands for $VIMRUNTIME/syntax/zsh.vim, barBlock corresponds to
zshBrackets, and barKeyword corresponds to the zsh.vim syntax rules
responsible for highlighting, say, the «cd» and «$0» in «{ cd $0 }».)

   * What was the outcome of this action?

When the file iota is viewed with «set filetype=foo», the words "lorem
ipsum" on line 1 are not highlighted.

   * What outcome did you expect instead?

I expected those two words on line 1 to be highlighted (via the chain
TOP -> fooBlock -> @bar -> barBlock -> barKeyword).

I note that if contains=TOP is either removed, or changed to
contains=@bar, then the words on line 1 do get highlighted.  However,
either of these changes would break the highlighting of ft=bar files.

It seems to me that when «contains=TOP» is encountered in a
:syn-include'd file, it's taken as a reference to the actual top-level,
i.e., the top of foo.vim, rather than as a reference to the top of the
included syntax's scope, i.e., the syntax match or region that did
«contains=@bar».

Cheers,

Daniel


-- Package-specific info:

(Freshly-created, up-to-date sid chroot with default settings.)

Bug#947118: [Pkg-javascript-devel] Bug#947118: node-on-headers: autopkgtest started failing and then times out

[Xavier]

Le 21/12/2019 à 12:04, Utkarsh Gupta a écrit :
> Hiya,
> 
> On Sat, Dec 21, 2019 at 3:51 PM Paul Gevers  > wrote:
> 
> Your package has an autopkgtest, great. However, I noticed that without
> any change from your side it started failing, and while doing so also
> doesn't finish, hence timing out on ci.debian.net
> . Obviously this isn't
> your fault, but please investigate, such that you can assign this bug to
> the right package. Please consider improving the test suite to not hang
> in case of failure. This is not the only node package that has this,
> e.g. check https://ci.debian.net/status/slow/ to see more. Don't
> hesitate to ask for help from the Debian CI team (in X-Debbugs-CC) if
> you need help solving this issue.
> 
> 
> I've just added a --timeout 1, which should be enough to fix this
> (and switched the package to use pkg-js-tools).
> 
> Could someone confirm if that indeed works?
> 
> Best,
> Utkarsh

No, this is a node-supertest problem. Fixed and uploaded (see the link,
test ≥ 2h)