date:20210707


Control: reopen -1
Control: tags -1 + fixed-in-experimental
Control: fixed -1 2.3.1+dfsg-9

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is still impacted by the bug.


Rafael Laboissière

Bug#988657: Reopen Bug#988657, fixed in experimental


Control: reopen -1
Control: tags -1 + fixed-in-experimental
Control: fixed -1 2.3.1+dfsg-9

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is still impacted by the bug.


Rafael Laboissière

Bug#990202: u-boot: [debian/rules] Make more settings explicit in build logs

2021-07-07 Thread Vagrant Cascadian

On 2021-06-22, Nicolas Boulenguez wrote:
> Append Debian revision to UBOOTVERSION via the command line instead of
> a patch.
>
> Set HOSTCFLAGS via the command line instead of the environment.
>
> Improve separation of concerns in debian/rules with a common_make_args
> variable.

Overall, this looks good!

Minor change requested; could you separate this into two patches, one
implementing common_make_args, and the second with the
UBOOTVERSION/EXTRAVERSION changes (which makes use of the
common_make_args changes)?

If you'd rather I split the patches, I can do that too; it looks pretty
straightforward.


live well,
  vagrant

> --- a/debian/patches/add-debian-revision-to-u-boot-version
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -Add the debian revision to the U-boot version, which is displayed at
> -boot and can be helpful to determine which specific version is used.
> -
>  a/Makefile
> -+++ b/Makefile
> -@@ -447,7 +447,7 @@
> - 
> - # Read UBOOTRELEASE from include/config/uboot.release (if it exists)
> - UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null)
> --UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
> $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
> -+UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
> $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)$(DEBIAN_REVISION)
> - 
> - export VERSION PATCHLEVEL SUBLEVEL UBOOTRELEASE UBOOTVERSION
> - export ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -1,5 +1,3 @@
> -add-debian-revision-to-u-boot-version
> -
>  tools-generic-builds.patch
>  
>  mx53loco
> --- a/debian/rules
> +++ b/debian/rules
> @@ -2,7 +2,13 @@
>  
>  include /usr/share/dpkg/architecture.mk
>  include /usr/share/dpkg/pkg-info.mk
> -export DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 
> 's,.*+dfsg,+dfsg,')
> +
> +# Add the debian revision to the U-boot version, which is displayed at
> +# boot and can be helpful to determine which specific version is used.
> +original_EXTRAVERSION = $(shell sed -n '/^EXTRAVERSION = /{s///p;q}' 
> Makefile)
> +DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 's,.*+dfsg,+dfsg,')
> +EXTRAVERSION = $(original_EXTRAVERSION)$(DEBIAN_REVISION)
> +common_make_args += EXTRAVERSION='$(EXTRAVERSION)'
>  
>  include debian/targets.mk
>  
> @@ -17,6 +23,7 @@ VERBOSE=0
>  else
>  VERBOSE=1
>  endif
> +common_make_args += V=$(VERBOSE)
>  
>  # the upstream build passes LDFLAGS directly to ld instead of calling gcc for
>  # linking; so instead of passing -Wl,foo in LDFLAGS as in automake builds, 
> one
> @@ -50,7 +57,8 @@ ifneq (,$(only_platforms))
>  endif
>  
>  # Enable debugging symbols and remove build paths
> -export HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=.
> +HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=.
> +common_make_args += HOSTCFLAGS='$(HOSTCFLAGS)'
>  
>  %:
>   dh $@
> @@ -76,12 +84,14 @@ define build_template
>   # debian/rules: building platform: $(platform)
>   mkdir -p debian/build/$(platform)
>  
> - dh_auto_build -- V=$(VERBOSE) O=debian/build/$(platform) \
> + dh_auto_build -- $(common_make_args) \
> +   O=debian/build/$(platform) \
> CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
> $($(package)_assigns) $($(platform)_assigns) \
> $(platform)_defconfig
>   sed -i 's,CONFIG_FIT_SIGNATURE=y,# CONFIG_FIT_SIGNATURE is not set,' 
> debian/build/$(platform)/.config
> - dh_auto_build -- V=$(VERBOSE) O=debian/build/$(platform) \
> + dh_auto_build -- $(common_make_args) \
> +   O=debian/build/$(platform) \
> CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
> $($(package)_assigns) $($(platform)_assigns)
>  
> @@ -106,10 +116,14 @@ $(foreach package, u-boot-qemu $(subarchs),\
>  
>  TOOLSDIR := debian/build/tools
>  build-tools:
> - dh_auto_build -- V=$(VERBOSE) O=$(TOOLSDIR) 
> CROSS_COMPILE=$(CROSS_COMPILE) tools-only_defconfig
> + dh_auto_build -- $(common_make_args) \
> +   O=$(TOOLSDIR) \
> +   CROSS_COMPILE=$(CROSS_COMPILE) \
> +   tools-only_defconfig
>   cp $(TOOLSDIR)/.config $(TOOLSDIR)/config
>   # board-independent tools
> - dh_auto_build -- V=$(VERBOSE) O=$(TOOLSDIR) \
> + dh_auto_build -- $(common_make_args) \
> + O=$(TOOLSDIR) \
>   CROSS_COMPILE=$(CROSS_COMPILE) \
>   CROSS_BUILD_TOOLS=$(cross_build_tools) \
>   NO_SDL=1 \


signature.asc
Description: PGP signature

Bug#820848: RFS: phcpack 2.4.84 (NEW)

2021-07-07 Thread Torrance, Douglas


On Wed 07 Jul 2021 08:37:08 AM EDT, Doug Torrance  
wrote:

On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra  wrote:

./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.


Good catch!  I've sent upstream a note asking for clarification on the license
of the files in this directory.


Upstream confirmed that this particular feature would cause limitations for
commercial use due to the license.  It's just one feature, though, and I think
that PHCpack would still be a valuable addition to Debian without it.  (For
example, the PHCpack package in Macaulay2 doesn't use it.)

I'll spend some time working on stripping this feature out to create a
DFSG-compliant version of PHCpack and ping the list when it's ready for another
look.

Thanks again!
Doug


signature.asc
Description: PGP signature

Bug#990812: unblock: python-authlib/0.15.4-1

2021-07-07 Thread Stefano Rivera

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

Please unblock package python-authlib

[ Reason ]
Upstream made a security point release. No CVE.

[ Impact ]
Security vulnerability.

[ Tests ]
Added a unit test to cover the issue.

Package builds and tests pass.

[ Risks ]
Tiny diff, looks good.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock python-authlib/0.15.4-1
diff -Nru python-authlib-0.15.3/authlib/consts.py 
python-authlib-0.15.4/authlib/consts.py
--- python-authlib-0.15.3/authlib/consts.py 2021-01-15 09:51:55.0 
-0400
+++ python-authlib-0.15.4/authlib/consts.py 2021-06-05 03:07:38.0 
-0400
@@ -1,5 +1,5 @@
 name = 'Authlib'
-version = '0.15.3'
+version = '0.15.4'
 author = 'Hsiaoming Yang '
 homepage = 'https://authlib.org/'
 default_user_agent = '{}/{} (+{})'.format(name, version, homepage)
diff -Nru python-authlib-0.15.3/authlib/jose/rfc7519/claims.py 
python-authlib-0.15.4/authlib/jose/rfc7519/claims.py
--- python-authlib-0.15.3/authlib/jose/rfc7519/claims.py2021-01-15 
09:51:55.0 -0400
+++ python-authlib-0.15.4/authlib/jose/rfc7519/claims.py2021-06-05 
03:07:38.0 -0400
@@ -58,10 +58,10 @@
 
 def _validate_claim_value(self, claim_name):
 option = self.options.get(claim_name)
-value = self.get(claim_name)
-if not option or not value:
+if not option:
 return
 
+value = self.get(claim_name)
 option_value = option.get('value')
 if option_value and value != option_value:
 raise InvalidClaimError(claim_name)
diff -Nru python-authlib-0.15.3/debian/changelog 
python-authlib-0.15.4/debian/changelog
--- python-authlib-0.15.3/debian/changelog  2021-01-20 14:21:23.0 
-0400
+++ python-authlib-0.15.4/debian/changelog  2021-07-07 19:32:08.0 
-0400
@@ -1,3 +1,9 @@
+python-authlib (0.15.4-1) unstable; urgency=medium
+
+  * New upstream point release, fixing a security issue.
+
+ -- Stefano Rivera   Wed, 07 Jul 2021 19:32:08 -0400
+
 python-authlib (0.15.3-1) unstable; urgency=medium
 
   [ Stefano Rivera ]
diff -Nru python-authlib-0.15.3/tests/core/test_jose/test_jwt.py 
python-authlib-0.15.4/tests/core/test_jose/test_jwt.py
--- python-authlib-0.15.3/tests/core/test_jose/test_jwt.py  2021-01-15 
09:51:55.0 -0400
+++ python-authlib-0.15.4/tests/core/test_jose/test_jwt.py  2021-06-05 
03:07:38.0 -0400
@@ -73,6 +73,20 @@
 claims.validate,
 )
 
+def test_validate_expected_issuer_received_None(self):
+id_token = jwt.encode({'alg': 'HS256'}, {'iss': None, 'sub': None}, 
'k')
+claims_options = {
+'iss': {
+'essential': True,
+'values': ['foo']
+}
+}
+claims = jwt.decode(id_token, 'k', claims_options=claims_options)
+self.assertRaises(
+errors.InvalidClaimError,
+claims.validate
+)
+
 def test_validate_aud(self):
 id_token = jwt.encode({'alg': 'HS256'}, {'aud': 'foo'}, 'k')
 claims_options = {

Bug#986804: CVE-2021-28116

2021-07-07 Thread Amos Jeffries


forwarded -1 https://bugs.squid-cache.org/show_bug.cgi?id=5131
thanks

Bug#990811: ITP: elpa-emacs-dashboard -- extensible emacs startup screen showing you what's most important

2021-07-07 Thread Martin

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: elpa-emacs-dashboard
  Version : 1.7.0
  Upstream Author : Rakan Al-Hneiti 
* URL : https://github.com/emacs-dashboard/emacs-dashboard
* License : GPL-3
  Programming Lang: Emacs-Lisp
  Description : extensible emacs startup screen showing you what's most 
important
  Features
  1. Displays an Emacs banner
  2. Recent files
  3. Bookmarks list
  4. Recent projects list (Depends on `projectile` or `project.el` package)
  5. Org mode agenda
  6. Register list

Bug#990809: unblock: wpebackend-fdo/1.10.0-2

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

Please unblock package wpebackend-fdo

I filed a separate bug report (#990754) requesting to unblock
wpewebkit so it is up-to-date in order to provide security releases
for bullseye.

To that end and for the same reasons I would also like to request the
unblocking of wpebackend-fdo, a Wayland backend required by wpewebkit
and developed by the same WPE WebKit team.

See #990754 for more details.

unblock wpebackend-fdo/1.10.0-2

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru wpebackend-fdo-1.8.0/debian/changelog 
wpebackend-fdo-1.10.0/debian/changelog
--- wpebackend-fdo-1.8.0/debian/changelog   2020-09-12 23:48:20.0 
+0200
+++ wpebackend-fdo-1.10.0/debian/changelog  2021-06-16 11:29:41.0 
+0200
@@ -1,3 +1,59 @@
+wpebackend-fdo (1.10.0-2) unstable; urgency=medium
+
+  * Upload to unstable.
+
+ -- Alberto Garcia   Wed, 16 Jun 2021 11:29:41 +0200
+
+wpebackend-fdo (1.10.0-1) experimental; urgency=medium
+
+  * New upstream release.
+  * debian/watch:
++ Fix regular expression to scan stable releases.
+  * debian/control:
++ Replace build dependency on cmake with meson.
++ Remove build dependency on libegl1-mesa-dev.
+  * debian/libwpebackend-fdo-1.0-1.symbols:
++ Update symbols.
+  * debian/copyright:
++ Remove deleted files.
+
+ -- Alberto Garcia   Mon, 07 Jun 2021 23:57:03 +0200
+
+wpebackend-fdo (1.8.4-1) experimental; urgency=medium
+
+  * New upstream release.
+  * debian/libwpebackend-fdo-1.0-1.symbols:
++ Update symbols.
+
+ -- Alberto Garcia   Wed, 12 May 2021 21:23:59 +0200
+
+wpebackend-fdo (1.8.3-1) experimental; urgency=medium
+
+  * New upstream release.
+  * debian/control:
++ Update Standards-Version to 4.5.1 (no changes).
+
+ -- Alberto Garcia   Wed, 31 Mar 2021 01:08:01 +0200
+
+wpebackend-fdo (1.8.2-1) unstable; urgency=medium
+
+  * New upstream release.
+  * debian/copyright:
++ Update copyright years.
+
+ -- Alberto Garcia   Thu, 18 Mar 2021 17:05:26 +0100
+
+wpebackend-fdo (1.8.1-1) unstable; urgency=medium
+
+  * New upstream release.
+  * debian/control:
++ Explain how WebKitGTK uses this package.
+  * debian/watch:
++ Track stable releases only.
++ Set version to 4 (fixes older-debian-watch-file-standard)
+
+ -- Alberto Garcia   Wed, 10 Mar 2021 14:59:13 +0100
+
 wpebackend-fdo (1.8.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru wpebackend-fdo-1.8.0/debian/control 
wpebackend-fdo-1.10.0/debian/control
--- wpebackend-fdo-1.8.0/debian/control 2020-09-12 23:48:20.0 +0200
+++ wpebackend-fdo-1.10.0/debian/control2021-06-16 11:29:41.0 
+0200
@@ -4,13 +4,12 @@
 Maintainer: Debian WebKit Maintainers 

 Uploaders: Alberto Garcia 
 Build-Depends: debhelper-compat (= 12),
-   cmake,
-   libegl1-mesa-dev,
+   meson,
libepoxy-dev,
libglib2.0-dev,
libwayland-dev,
libwpe-1.0-dev (>= 1.5.90)
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/webkit-team/wpebackend-fdo
 Vcs-Git: https://salsa.debian.org/webkit-team/wpebackend-fdo.git
@@ -33,6 +32,9 @@
  FreeDesktop.org technologies (Wayland protocol and the Wayland EGL
  platform) to enable integration into the WPE WebKit process model.
  .
+ In addition to WPE WebKit, wpebackend-fdo is also used by WebKitGTK
+ to implement hardware-accelerated rendering under Wayland.
+ .
  This package contains the development files.
 
 Package: libwpebackend-fdo-1.0-1
@@ -48,4 +50,7 @@
  FreeDesktop.org technologies (Wayland protocol and the Wayland EGL
  platform) to enable integration into the WPE WebKit process model.
  .
+ In addition to WPE WebKit, wpebackend-fdo is also used by WebKitGTK
+ to implement hardware-accelerated rendering under Wayland.
+ .
  This package contains the shared libraries.
diff -Nru wpebackend-fdo-1.8.0/debian/copyright 
wpebackend-fdo-1.10.0/debian/copyright
--- wpebackend-fdo-1.8.0/debian/copyright   2020-09-12 23:48:20.0 
+0200
+++ wpebackend-fdo-1.10.0/debian/copyright  2021-06-16 11:29:41.0 
+0200
@@ -3,7 +3,7 @@
 Source: https://wpewebkit.org/releases/
 
 Files: *
-Copyright: © 2017-2020 Igalia, S.L.
+Copyright: © 2017-2021 Igalia, S.L.
 License: BSD-2-clause
 
 Files: src/bridge/wpe-bridge.xml
@@ -15,12 +15,8 @@
© 2014, 2015 Collabora, Ltd.
 License: Expat
 
-Files: cmake/FindGLIB.cmake
-Copyright: © 2012 Raphael Kubo da

Bug#990810: unblock: libwpe/1.10.0-2

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

Please unblock package libwpe

I filed a separate bug report (#990754) requesting to unblock
wpewebkit so it is up-to-date in order to provide security releases
for bullseye.

To that end and for the same reasons I would also like to request the
unblocking of libwpe, a library developed by the same team as part of
the WPE WebKit project that defines a set of interfaces used by
wpewebkit.

See #990754 for more details.

unblock libwpe/1.10.0-2

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libwpe-1.6.0/debian/changelog libwpe-1.10.0/debian/changelog
--- libwpe-1.6.0/debian/changelog   2020-03-12 00:32:32.0 +0100
+++ libwpe-1.10.0/debian/changelog  2021-06-15 19:01:32.0 +0200
@@ -1,3 +1,24 @@
+libwpe (1.10.0-2) unstable; urgency=medium
+
+  * Upload to unstable.
+
+ -- Alberto Garcia   Tue, 15 Jun 2021 19:01:32 +0200
+
+libwpe (1.10.0-1) experimental; urgency=medium
+
+  * New upstream release.
+  * debian/copyright:
++ Update copyright years.
+  * debian/libwpe-1.0-1.symbols:
++ Update symbols
+  * debian/control:
++ Update Standards-Version to 4.5.1 (no changes).
+  * debian/watch:
++ Set version to 4 (fixes older-debian-watch-file-standard)
++ Scan stable releases only.
+
+ -- Alberto Garcia   Sat, 27 Mar 2021 23:08:25 +0100
+
 libwpe (1.6.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libwpe-1.6.0/debian/control libwpe-1.10.0/debian/control
--- libwpe-1.6.0/debian/control 2020-03-12 00:32:32.0 +0100
+++ libwpe-1.10.0/debian/control2021-06-15 19:01:32.0 +0200
@@ -8,7 +8,7 @@
libegl1-mesa-dev,
libxkbcommon-dev,
cmake
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/webkit-team/libwpe
 Vcs-Git: https://salsa.debian.org/webkit-team/libwpe.git
diff -Nru libwpe-1.6.0/debian/copyright libwpe-1.10.0/debian/copyright
--- libwpe-1.6.0/debian/copyright   2020-03-12 00:32:32.0 +0100
+++ libwpe-1.10.0/debian/copyright  2021-06-15 19:01:32.0 +0200
@@ -3,7 +3,7 @@
 Source: https://wpewebkit.org/releases/
 
 Files: *
-Copyright: © 2018-2020 Igalia, S.L.
+Copyright: © 2018-2021 Igalia, S.L.
 License: BSD-2-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
diff -Nru libwpe-1.6.0/debian/libwpe-1.0-1.symbols 
libwpe-1.10.0/debian/libwpe-1.0-1.symbols
--- libwpe-1.6.0/debian/libwpe-1.0-1.symbols2020-03-12 00:32:32.0 
+0100
+++ libwpe-1.10.0/debian/libwpe-1.0-1.symbols   2021-06-15 19:01:32.0 
+0200
@@ -1,7 +1,5 @@
 libwpe-1.0.so.1 libwpe-1.0-1 #MINVER#
 * Build-Depends-Package: libwpe-1.0-dev
- 
(optional)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
 1.3.0
- 
(optional)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
 1.3.0
  wpe_backend_get_major_version@Base 1.3.0
  wpe_backend_get_micro_version@Base 1.3.0
  wpe_backend_get_minor_version@Base 1.3.0
@@ -38,6 +36,7 @@
  wpe_renderer_backend_egl_offscreen_target_get_native_window@Base 1.3.0
  wpe_renderer_backend_egl_offscreen_target_initialize@Base 1.3.0
  wpe_renderer_backend_egl_target_create@Base 1.3.0
+ wpe_renderer_backend_egl_target_deinitialize@Base 1.10.0
  wpe_renderer_backend_egl_target_destroy@Base 1.3.0
  wpe_renderer_backend_egl_target_dispatch_frame_complete@Base 1.3.0
  wpe_renderer_backend_egl_target_frame_rendered@Base 1.3.0
diff -Nru libwpe-1.6.0/debian/watch libwpe-1.10.0/debian/watch
--- libwpe-1.6.0/debian/watch   2020-03-12 00:32:32.0 +0100
+++ libwpe-1.10.0/debian/watch  2021-06-15 19:01:32.0 +0200
@@ -1,3 +1,3 @@
-version=3
+version=4
 opts=pgpsigurlmangle=s/$/.asc/ \
-https://wpewebkit.org/releases/ libwpe-(.*).tar.xz
+https://wpewebkit.org/releases/ libwpe-(\d+\.\d*[02468]\.\d+).tar.xz

Bug#990808: ganglia-modules-linux: library paths in configs are wrong

2021-07-07 Thread Christoph Anton Mitterer

Package: ganglia-modules-linux
Version: 1.3.6-4
Severity: important


Hi.

The library paths in the configs (and sample configs):
/etc/ganglia/conf.d/mod_fs.conf-sample
/etc/ganglia/conf.d/mod_io.conf
/etc/ganglia/conf.d/mod_multicpu.conf-sample


use still the old locations like:
/usr/lib/ganglia/modio.so

whereas these files are now in:
/usr/lib/x86_64-linux-gnu/ganglia


Cheers,
Chris.

Bug#990800: ITA: btcheck/2.1-5 -- downloaded data checker and a torrent file content viewer

2021-07-07 Thread Lin Qigang

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor to adopt the package "btcheck":

 * Package name: btcheck
   Version : 2.1-5
   Upstream Author : Jean Diraison 
 * URL : http://btcheck.sourceforge.net/
 * License : GPL-3
 * Vcs : https://salsa.debian.org/debian/btcheck
   Section : utils

It builds those binary packages:

  btcheck - downloaded data checker and a torrent file content viewer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btcheck/btcheck_2.1-5.dsc

Changes since the last upload:

 btcheck (2.1-5) experimental; urgency=medium
 .
   * debian/upstream/metadata: Added upstream metadata

Regards,
-- 

  Lin Qigang

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

signature.asc
Description: OpenPGP digital signature

Bug#988647: crash: please update to new upstream release

2021-07-07 Thread Guilherme Piccoli

Outstanding Troy, thanks a bunch! We owe you a coffee/beer in some
conference heheh
Cheers,


Guilherme

Bug#988647: crash: please update to new upstream release

2021-07-07 Thread Troy Heber

On 07/07/21 12:43, dann frazier wrote:
> On Wed, Jul 7, 2021 at 12:17 PM Guilherme Piccoli
>  wrote:
> >
> > Hi Troy, I'd like to enforce that request! We want to upgrade crash
> > version on next Ubuntu release, and the correct process would be to
> > match Debian's Sid version.
> > Thanks in advance,
> 
> Hi Guillherme!
> 
> Just a heads-up that Debian is currently in freeze (see
> https://release.debian.org/), so new upstream releases are unlikely to
> appear in sid until after bullseye releases. Of course, we could bribe
> Troy for an upload to experimental :) Let us know if we can help at
> all.

Hello Everyone,

I was indeed waiting until release before doing a fresh upload to sid
but am more than happy to push 7.3.0 to experimental if that is
helpful! The upload just completed so it should be available soon. 

Troy


signature.asc
Description: PGP signature

Bug#729188: Mutual Business Establishment

2021-07-07 Thread Dr Nelson Rodriguez

Good Day,


My name is Dr Nelson Rodriguez. I have a very good business 
opportunity that will benefit both of us.Kindly get back to me 
for more details.


Regards,

Dr Nelson Rodriguez
(Dir., Research & Development)

Bug#990754: unblock: wpewebkit/2.32.1-1

On Wed, Jul 07, 2021 at 06:40:39PM +0200, Sebastian Ramacher wrote:

> > At the moment doing an additional security release for wpewebkit
> > is going to be little more than adapting the webkit2gtk advisory.
> 
> ACK, then please send a (filtered) debdiff for wpewebkit to the bug
> report so that we can look at unblocking it.

Attached.

Berto
diff -Nru wpewebkit-2.30.6/debian/changelog wpewebkit-2.32.1/debian/changelog
--- wpewebkit-2.30.6/debian/changelog	2021-03-19 20:17:01.0 +0100
+++ wpewebkit-2.32.1/debian/changelog	2021-05-08 16:53:58.0 +0200
@@ -1,3 +1,39 @@
+wpewebkit (2.32.1-1) unstable; urgency=medium
+
+  * New upstream release.
+  * debian/patches/revert-soname-change.patch:
++ Drop this patch, this is now upstream.
+  * debian/patches/fix-ftbfs-m68k.patch:
++ Update patch.
+
+ -- Alberto Garcia   Sat, 08 May 2021 16:53:58 +0200
+
+wpewebkit (2.32.0-2) unstable; urgency=medium
+
+  * debian/patches/fix-ftbfs-m68k.patch:
++ Compile BytecodeGenerator.cpp without optimizations on m68k and sh4,
+  otherwise the build fails due to gcc bugs.
+
+ -- Alberto Garcia   Thu, 22 Apr 2021 15:24:36 +0200
+
+wpewebkit (2.32.0-1) experimental; urgency=medium
+
+  * New upstream release.
+  * debian/gbp.conf:
++ Update upstream branch name.
+  * Use -DFORCE_32BIT on 32-bit builds.
++ This replaces debian/patches/fix-ftbfs-x86.patch.
+  * Refresh all patches.
+  * Update copyright information of all files.
+  * debian/control:
++ Add build dependencies on libglib2.0-doc and libsoup2.4-doc.
+  * debian/libwpewebkit-1.0-3.symbols:
++ Update symbols.
+  * debian/patches/revert-soname-change.patch:
++ Revert upstream soname change.
+
+ -- Alberto Garcia   Tue, 06 Apr 2021 11:20:35 +0200
+
 wpewebkit (2.30.6-1) unstable; urgency=high
 
   * New upstream release.
diff -Nru wpewebkit-2.30.6/debian/control wpewebkit-2.32.1/debian/control
--- wpewebkit-2.30.6/debian/control	2021-03-19 20:17:01.0 +0100
+++ wpewebkit-2.32.1/debian/control	2021-05-08 16:53:58.0 +0200
@@ -35,7 +35,9 @@
ninja-build,
ruby:native,
wayland-protocols
-Build-Depends-Indep: gtk-doc-tools
+Build-Depends-Indep: gtk-doc-tools,
+   libglib2.0-doc,
+   libsoup2.4-doc
 Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/webkit-team/webkit
diff -Nru wpewebkit-2.30.6/debian/copyright wpewebkit-2.32.1/debian/copyright
--- wpewebkit-2.30.6/debian/copyright	2021-03-19 20:17:01.0 +0100
+++ wpewebkit-2.32.1/debian/copyright	2021-05-08 16:53:58.0 +0200
@@ -8,14 +8,14 @@
1999-2000 Lars Knoll 
2001 Dirk Mueller 
2002-2013 Vivek Thampi
-   2003-2020 Apple Inc
+   2003-2021 Apple Inc
2004-2006 Rob Buis 
2004-2008 Nikolas Zimmermann 
-   2005 Alexey Proskuryakov
2005 Frerich Raabe 
2005 Maksim Orlovich 
-   2005, 2007-2013, 2015, 2017-2020 Google Inc
+   2005, 2007-2013, 2015, 2017-2021 Google Inc
2005, 2008-2013 Nokia
+   2005-2006 Alexey Proskuryakov
2005-2006 Kimmo Kinnunen 
2005-2008 Eric Seidel 
2006 Alexander Kellett 
@@ -46,7 +46,7 @@
2009-2010 Holger Hans Peter Freyther
2009-2011 Brent Fulgham 
2009-2015 University of Szeged
-   2009-2020 Igalia S.L.
+   2009-2021 Igalia S.L.
2010 Andras Becsi , University of Szeged
2010 Mozilla Corporation
2010 Peter Varga , University of Szeged
@@ -70,7 +70,7 @@
2011 Peter Varga , University of Szeged
2011 ProFUSION embedded systems
2011 Renata Hodovan 
-   2011, 2015-2017 The Chromium Authors
+   2011, 2014-2017 The Chromium Authors
2011-2012, 2014-2015 Ericsson AB
2011-2013 Intel Corporation
2011-2013 Samsung Electronics
@@ -111,14 +111,14 @@
2015, 2018 Andy VanWagoner 
2015-2016 Sukolsak Sakshuwong 
2015-2017 Canon Inc
-   2015-2017 Devin Rousso 
+   2015-2020 Devin Rousso 
2016 Caitlin Potter 
2016 Konstantin Tokavev 
2016 Yusuke Suzuki 
2016-2018 Akamai Technologies Inc
2016-2019 Oleksandr Skachkov 
-   2016-2020 Metrological Group B.V
-   2016-2020 Sony Interactive Entertainment
+   2016-2021 Metrological Group B.V
+   2016-2021 Sony Interactive Entertainment
2017 Caio Lima 
2017 Endless Mobile Inc
2017 Oleksandr Skachkov 
@@ -126,7 +126,8 @@
2018 Yusuke Suzuki 
2018 mce sys Ltd
2019 Carlos Eduardo Ramalho 
-   2019-2020 Alexey Shvayka 
+   2019-2021 Alexey Shvayka 
+   2020 Cloudinary Inc
2020 Darryl Pogue 
2020

Bug#950941: see also #990807

2021-07-07 Thread Tomas Pospisek


see also #990807

Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove

2021-07-07 Thread Tomas Pospisek

Package: thunderbird
Version: 1:78.11.0-2
Severity: normal
X-Debbugs-Cc: Carsten Schoenert , Paul Menzel 


I'd like to describe my problem, which is related to #950941.

I have copyied over ~/thunderbird from my old laptop. Now when
I start thunderbird, it start's normally. However at next start it
will fail and complain and tell me that I should resolve the
situation.

Why?

Because on first start, the second layer of wrappers will
apparently make a **copy** of ~/.thunderbird to ~/.icedove.

And on the second start the first layer wrapper will see:

$ ls -l .thunderbird/ .icedove/ -d
drwx-- 3 me mi 4096  7. Jul 22:24 .icedove/
drwx-- 5 me mi 4096  2. Jul 21:57 .thunderbird/

and ... fail.

So I've tried to find out. Took me now over 1.5 hours and
I still haven't found out because... well it's complex.
And even with the whole complexity the wrapper is still
not able to handle (in the sense of behaving like
thunderbird itself would in the same situation) the
situation.

So I'd suggest something in the vein of:

$ cat /usr/bin/thunderbird
#!/bin/bash
if [ "$SKIP_THUNDERBIRD_WRAPPER" != "" ]; then 
/usr/lib/thunderbird/thunderbird "$@"; fi

But then again one could simply do:

alias thunderbird=/usr/lib/thunderbird/thunderbird

(the path /usr/lib/thunderbird/thunderbird not being
trivial to find...). Or maybe [also] document that...

Yet another alternative is to use upstream?

What do you think?

Greetings and thanks!
*t

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-6
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-9
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.18.3-5
ii  libgtk2.0-0   2.24.33-2

-- no debconf information

Bug#888831: NS_ERROR_NET_INADEQUATE_SECURITY error on armhf/arm64 at least

2021-07-07 Thread Mike Hommey

On Wed, Jul 07, 2021 at 03:35:48PM +0200, Raphael Hertzog wrote:
> The simplest fix is thus to let nss migrate into bullseye.

The simplest fix is a binNMU of firefox-esr because the issue was fixed
in NSS, but since there's going to be a security update for firefox-esr
next week, I didn't ask for a binNMU. See bug 990699.

Mike

Bug#990806: No log rotation for xrdp

2021-07-07 Thread Linde, Evan

Package: xrdp
Version: 0.9.12

Log files from xrdp do not rotate, but grow continuously. 

Please consider adding a logrotate file (i.e. /etc/logrotate.d/xrdp) to the 
xrdp package. Here is the config I would suggest:

/var/log/xrdp*.log {
compress
missingok
notifempty
copytruncate
}

Or the following if it is preferable to define the rotation schedule explicitly 
rather than inherit from /etc/logrotate.conf:

/var/log/xrdp*.log {
rotate 4
weekly
compress
missingok
notifempty
copytruncate
}

Evan Linde
Research Cyberinfrastructure Analyst
Oklahoma State University
High Performance Computing Center
405-744-1455
http://hpcc.okstate.edu/

Bug#990803: unblock: libvdestack/0.1.2-1 debdiff

2021-07-07 Thread Renzo Davoli

I forgot to attach the debdiff

renzo
diff -Nru libvdestack-0.1.1/CMakeLists.txt libvdestack-0.1.2/CMakeLists.txt
--- libvdestack-0.1.1/CMakeLists.txt2020-12-05 17:00:01.0 +0100
+++ libvdestack-0.1.2/CMakeLists.txt2021-06-29 16:29:41.0 +0200
@@ -2,7 +2,7 @@
 project("vdestack"
 DESCRIPTION "A network namespace as a library, i.e. Internet of Threads 
through Network Namespaces."
 HOMEPAGE_URL "https://github.com/rd235/libvdestack;
-VERSION 0.1.0
+VERSION 0.1.2
 LANGUAGES C)
 
 include(GNUInstallDirs)
@@ -10,8 +10,8 @@
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_FORTIFY_SOURCE=2 -O2 -pedantic -Wall 
-Wextra")
 
 set(CMAKE_REQUIRED_QUIET TRUE)
-set(LIBS_REQUIRED vdeplug cap execs)
-set(HEADERS_REQUIRED libvdeplug.h sys/capability.h execs.h)
+set(LIBS_REQUIRED vdeplug cap execs pthread)
+set(HEADERS_REQUIRED libvdeplug.h sys/capability.h execs.h pthread.h)
 set(PROJECT_PC_REQUIRES "vdeplug cap execs")
 
 foreach(THISLIB IN LISTS LIBS_REQUIRED)
@@ -32,7 +32,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR})
 
 add_library(vdestack SHARED vdestack.c)
-target_link_libraries(vdestack -lcap -lexecs -lvdeplug)
+target_link_libraries(vdestack -lcap -lexecs -lvdeplug -lpthread)
 
 set_target_properties(vdestack PROPERTIES VERSION ${PROJECT_VERSION}
 SOVERSION ${PROJECT_VERSION_MAJOR})
diff -Nru libvdestack-0.1.1/debian/changelog libvdestack-0.1.2/debian/changelog
--- libvdestack-0.1.1/debian/changelog  2021-01-08 19:52:31.0 +0100
+++ libvdestack-0.1.2/debian/changelog  2021-07-07 18:27:00.0 +0200
@@ -1,3 +1,9 @@
+libvdestack (0.1.2-1) unstable; urgency=medium
+
+  * New Upstream Release: fix a race condition bug
+
+ -- Renzo Davoli   Wed, 07 Jul 2021 18:27:00 +0200
+
 libvdestack (0.1.1-1) unstable; urgency=medium
 
   * New Upstream Release
diff -Nru libvdestack-0.1.1/man/libvdestack.3 
libvdestack-0.1.2/man/libvdestack.3
--- libvdestack-0.1.1/man/libvdestack.3 2020-12-05 17:00:01.0 +0100
+++ libvdestack-0.1.2/man/libvdestack.3 2021-06-29 16:29:41.0 +0200
@@ -20,9 +20,9 @@
 .\" Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
 .\" MA 02110-1301 USA.
 .\"
-.\" generated with Ronn-NG/v0.8.0
-.\" http://github.com/apjanke/ronn-ng/tree/0.8.0
-.TH "LIBVDESTACK" "3" "December 2019" "VirtualSquare"
+.\" generated with Ronn-NG/v0.9.1
+.\" http://github.com/apjanke/ronn-ng/tree/0.9.1
+.TH "LIBVDESTACK" "3" "June 2021" "VirtualSquare"
 .SH "NAME"
 vde_addstack, vde_delstack, vde_stackcmd, vde_msocket \- vde network namespace 
as a user library
 .SH "SYNOPSIS"
@@ -44,7 +44,7 @@
 .P
 \fBvde_delstack\fR destroys a vdestack when it is no longer needed\.
 .P
-\fBvde_stackcmd\fR run a command or a comma separated sequence of commands in 
the private network namespace\. The purpose of this function is to configure 
the networking parameters and options (e\.g\. IP address, routing)\. For 
security reasons, commands must be specified using full pathnames\.
+\fBvde_stackcmd\fR run a command or a comma separated sequence of commands in 
the private network namespace\. The purpose of this function is to configure 
the networking parameters and options (e\.g\. IP address, routing)\. For 
security reasons, commands must be specified using full pathnames\. Do not use 
this function to start long lasting or non terminating programs, the caller 
waits for the termination of the command sequence\.
 .P
 \fBvde_msocket\fR has the same semantics of \fBsocket\fR(2) except that the 
socket is defined in the scope of the network namespace whose descriptor is the 
first argument\. The remaining arguments are those defined in socket(2)\.
 .P
@@ -84,6 +84,6 @@
 .SH "SEE ALSO"
 \fBsocket\fR(2), \fBvde_plug\fR(1)
 .SH "BUGS"
-Bug reports should be addressed to \fI\%mailto:info@virtualsquare\.org\fR
+Bug reports should be addressed to \fIinfo@virtualsquare\.org\fR
 .SH "AUTHOR"
 VirtualSquare\. Project leader: Renzo Davoli\.
diff -Nru libvdestack-0.1.1/man/libvdestack.3.ronn 
libvdestack-0.1.2/man/libvdestack.3.ronn
--- libvdestack-0.1.1/man/libvdestack.3.ronn2020-12-05 17:00:01.0 
+0100
+++ libvdestack-0.1.2/man/libvdestack.3.ronn2021-06-29 16:29:41.0 
+0200
@@ -57,7 +57,8 @@
 
 `vde_stackcmd`  run  a  command or a comma separated sequence of commands in 
the private network namespace.  The purpose of
 this function is to configure the networking parameters and options (e.g. IP 
address, routing).   For  security  reasons,
-commands must be specified using full pathnames.
+commands must be specified using full pathnames. Do not use this function to 
start long lasting or non terminating programs,
+the caller waits for the termination of the command sequence.
 
 `vde_msocket`  has  the same semantics of `socket`(2) except that the socket 
is defined in the scope of the network namespace
 whose descriptor is the first argument. The remaining arguments are those 
defined in socket(2).
diff -Nru

Bug#990805: lios: Unable open preferences settings menu

2021-07-07 Thread Gniurk

Package: lios
Version: 2.7.2-2
Severity: important
X-Debbugs-Cc: gni...@gmail.com

Dear Maintainer,
On the Lios application, it is not possible to open the preferences settings 
menu, the orca screen reader wait a very long time before we can browse options 
on the dialog box.
my locales settings are fr-FR.UTF-8

Steps to reproduce the problem:
Open lios,
On the menu bar, select preferences then Preferences-General submenu, the 
screen reader read nothing before one minute.
Many Thanks

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lios depends on:
ii  aspell-en2018.04.16-0-1
ii  espeak   1.48.15+dfsg-2
ii  gir1.2-gst-plugins-base-1.0  1.18.4-2
ii  gir1.2-gstreamer-1.0 1.18.4-2
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-vte-2.91  0.62.3-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  poppler-utils20.09.0-3.1
ii  python3  3.9.2-3
ii  python3-enchant  3.2.0-1
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2
ii  python3-sane 2.9.1-1
ii  python3-speechd  0.10.2-2
ii  tesseract-ocr4.1.1-2.1

Versions of packages lios recommends:
ii  gnome-icon-theme  3.12.0-3

Versions of packages lios suggests:
pn  cuneiform  

-- no debconf information

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

2021-07-07 Thread Holger Wansing

Hi,

Javier Fernandez-Sanguino  wrote (Wed, 7 Jul 2021 15:25:41 
+0200):
> tag 990720 confirmed fixed-upstream
> thanks
> 
> Dear colleagues,
> 
> I have fixed this today in the debian installer GIT repository:
> 
> $ git commit -m "Fix error in translation (Closes: #990720)" es.po
> [master 64d9fb0063] Fix error in translation (Closes: #990720)
>  1 file changed, 1 insertion(+), 1 deletion(-)

I cannot find this commit in the GIT repo.
Maybe you forgot to 'git push'?


Holger




> 
> Regards
> 
> Javier
> 
> 
> On Mon, 5 Jul 2021 at 19:36, Javier Fernandez-Sanguino 
> wrote:
> 
> > Dear Cyril,
> >
> > Thank you for forwarding me this bug (and to Federico for reporting). I'll
> > take a look and fix the string. There is clearly a mistake there.
> >
> > Saludos,
> >
> > Javier
> >
> > El lun., 5 jul. 2021 18:42, Cyril Brulebois  escribió:
> >
> >> Control: reassign -1 grub-installer 1.172
> >>
> >> ¡Ola Federico!
> >>
> >> And thanks for your report.
> >>
> >> Federico Pinal Moreira  (2021-07-05):
> >> > Dear Maintainer,
> >> >
> >> > Installing with debian-bullseye-DI-rc2-amd64 in spanish I got a prompt
> >> "Aunque
> >> > p" where I should have got something like "Instalar el cargador de
> >> arranque
> >> > GRUB".
> >> >
> >> > grub-installer.templates:28001 @ d-i/packages/po/sublevel1/es.po
> >>
> >> This seems to date back to the following commit:
> >>
> >> commit abe81e97d4ddef0dc17cc69e35d84c505064b23b
> >> Author: Javier Fernández-Sanguino 
> >> Date:   Sun Aug 23 17:03:03 2020 +0200
> >>
> >> Update translation and fix typos
> >>
> >> See:
> >>
> >> https://salsa.debian.org/installer-team/grub-installer/-/commit/9b7b5692e964b70260a7af4197cc017998291543
> >>
> >> Specifically:
> >>
> >> -msgstr "Instalando el cargador de arranque GRUB"
> >> +msgstr "Aunque p"
> >>
> >> which happened along with unfuzzying that particular message.
> >>
> >> Reassigning and cc-ing accordingly. If it were me, I would simply revert
> >> that single msgstr update, as the original translation doesn't seem
> >> crazy to me. I'll let Javier or the translation coordinator look at it
> >> first, as I'm absolutely no Spanish speaker. :)
> >>
> >>
> >> Cheers,
> >> --
> >> Cyril Brulebois (k...@debian.org)
> >> D-I release manager -- Release team member -- Freelance Consultant
> >>
> >


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

2021-07-07 Thread Sebastian Ramacher

On 2021-06-30 21:52:36 +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Sebastian
> 
> On 29-06-2021 22:41, Sebastian Ramacher wrote:
> >> Please note that the current plans are that a Debian 10 (buster)
> >> security update, intel-microcode/3.20210608.2~deb10u1, will be delivered
> >> to Debian stable in the next couple days through debian-security, in
> >> which case the version currently in Debian 11 "bullseye" would be
> >> *OLDER* than what would be available in buster-security and unstable.
> >>
> >> Also, please be warned that this update has the potential to cause
> >> regressions when compared to the previous version of the intel-microcode
> >> package.  But do read the text below for the full rationale.
> > 
> > The regression potential seems worth adding to the release notes.
> > Cloning and reassigning accordingly.
> 
> I may be missing something, or your intentions, but if I understand
> correctly, users that upgrade to bullseye will already have had the
> regression and as such the release notes will not help them to prepare
> for the upgrade. Hence, if this needs further documenting, I think we
> should look for better places.

We still don't have a fix for iwlwifi. So if people held back on
upgrading intel-microcode because of the warning in DSA-4934-1, I think
we should warn again in the release-notes. I'd rather have this
documented one time too much instead of people rebooting with broken
wifi after the upgrade or system failing to boot.

(I'm not sure if there are people out there that start from an up-to-date buster
without the security archive enabled. In that case they also have an
intel-firmware package installed without the regressions.)

What about the following text (adapted from the DSA)?

The intel-firmware package contained in bullseye and released as part of
DSA-4934-1 is known to contain two significant bugs. For some CoffeeLake
CPUs this update may break iwlwifi
(https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56)
and some for Skylake R0/D0 CPUs on systems using a very outdated
firmware/BIOS, the system may hang on boot:
(https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31)

If you held back the update from DSA-4934-1 due to any of these two
issues or do not have the security archive enabled, be aware that
upgrading to the intel-firwmare package in bullseye may cause your
system to hang on boot or break iwlwifi. In that case, you can recover by
disabling microcode loading on boot (as documented in README.Debian,
also available online at
https://salsa.debian.org/hmh/intel-microcode/-/blob/master/debian/README.Debian)

Cheers
Sebastian
-- 
Sebastian Ramacher

signature.asc
Description: PGP signature

Bug#778519: i just wanted to say heloo

2021-07-07 Thread HI DEAR

Hello sweet

Do you remember me?
You said that I was very beautiful.Would you like to get to know each other?

look at meClick to see me

Bug#982928: systemd: boot-and-services testsuite failure on armhf

2021-07-07 Thread Michael Biebl

Control: tags -1 + moreinfo

On Wed, 17 Feb 2021 02:56:52 +0900 Ryutaroh Matsumoto
 wrote:
> Source: systemd
> Version: 247.3-1
> Severity: minor
> 
> Dear Maintainer,
> 
> Salsa latest version of autopkgtest adds armhf qemu testbed.
> autopkgtest-virt-qemu --dpkg-architecture=armhf on systemd
> fails on boot-and-service. Failure happens at boot-and-service.
> The relevant log is as follows. It seems that the error message
> is different from what is expected by testsuite script...
> 
> 17:test_bash_crash (__main__.CoredumpTest) ... FAIL
> 41:FAIL: test_bash_crash (__main__.CoredumpTest)
> 44:  File "/tmp/autopkgtest.XllwP8/build.pib/src/debian/tests/boot-and-
services", line 457, in test_bash_crash
> 45:    self.assertRegex(journal, b'#[0-9] .*bash')
> 46:AssertionError: Regex didn't match: b'#[0-9] .*bash' not found in b'--
Journal begins at Sun 2021-02-14 16:04:21 UTC, ends at Sun 2021-02-14
16:09:03 UTC. --\nFeb 14 16:09:03 host systemd-coredump[835]: Process 833
(bash) of user 0 dumped core.\n   
\n    Stack trace of thread
833:\n    #0  0xb6eba0e8
kill (libc.so.6 + 0x2a0e8)\n'

Is this still reproducible with v249 from experimental?
If so, can you please forward this issue to the arm porters and tag the bug
report accordingly. So far, this looks like an armhf and/or qemu specific
problem to me. But lacking the necessary hardware / test environment, I can
debug this.






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

Bug#988450: bootctl systemd-efi-options doesn't work

2021-07-07 Thread Michael Biebl

Control: forwarded -1 https://github.com/systemd/systemd/issues/19597
Control: fixed -1 249~rc1-1

Hi Thomas

On Thu, 13 May 2021 10:46:04 + =?utf-8?q?Thomas_M=C3=BChlbacher?=
 wrote:
> I will file it upstream. Thanks for helping!

Thanks for that. Marking accordingly.

It appears this has been fixed in by
https://github.com/systemd/systemd/pull/19896 which is part of 249~rc1-1
Marking as fixed for that version.

Regards,
Michael


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

Bug#990803: unblock: libvdestack/0.1.2-1

2021-07-07 Thread Renzo Davoli

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

Please unblock package libvdestack

[ Reason ]
There was a bug: a race condition.
The diff is minimal: just a mutex has been added.

[ Impact ]
vde_msocket can return the wrong socket in case uf multithread usage.

[ Tests ]
There is no automated test covering that part. Manually tested.

[ Risks ]
No specific risks, apart from the program misbehavior.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libvdestack/0.1.2-1

--
regards,
  renzo davoli

Bug#989294: unblock: insighttoolkit4/4.13.3withdata-dfsg1-4.1

2021-07-07 Thread Sebastian Ramacher

On 2021-07-03 14:38:16 +0200, Andreas Beckmann wrote:
> On 01/07/2021 11.25, Sebastian Ramacher wrote:
> > Besides libotb-apps, is this an issue for any other package? I've randomly
> > tried two packages from your list above (elastix and odin), but apt
> > found upgrade paths just fine.
> 
> I just tried without patched insighttoolkit and found e.g.
> gis-remotesensing, probably more to come as tests progress.

I am unable to reproduce any upgrade issues with gis-remotesensing. With
or without --install-recommends enabled, apt finds a solution and the
upgrade works just fine.

Unless there are others, let's close this unblock request.

Cheers

> 
> Currently libinsighttoolkit4.12 and libinsighttoolkit4.13 are not
> co-installable. Adding this Breaks would just make that explicit. (Unless we
> need to make them co-installable fro whatever reason.) And having the Breaks
> will make apt's job easier as it automatically solves the corner cases.
> 
> (Installing 4.12 on top of 4.13 in bullseye fails with
>  libniftiio2 : Breaks: libnifti2 (<= 3.0) but 2.0.0-3 is to be installed
> )
> 
> Andreas



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#888831: NS_ERROR_NET_INADEQUATE_SECURITY error on armhf/arm64 at least

2021-07-07 Thread Pekka Sarnila

On Wed, 7 Jul 2021 15:35:48 +0200 Raphael Hertzog  
wrote:

Control: severity -1 serious
Control: found -1 firefox-esr/78.11.0esr-1
Control: tag -1 + bullseye

Hello,

it looks like this issue resurfaced again and it happens in bullseye
right now (with firefox-esr 78.11.0esr-1 and libnss3 2:3.61-1).
If you upgrade to the version of libnss3 in unstable (2:3.67-2)
then the issue goes away.

This has been reproduced in Kali on an rpi (armhf) and on the Lenovo Yoga
C630 (arm64).

The simplest fix is thus to let nss migrate into bullseye.

Cheers,
--
Raphaël Hertzog


This is kind of odd. I updated firefox-esr 78.3.0esr-2 -> 78.11.0esr-1. 
I had libnss3 2:3.58-1. https stopped working. Updating libnss3 -> 
2:3.61-1 solved the problem.


Pekka Sarnila

Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch


On 07/07/2021 18.18, Otto Kekäläinen wrote:

Galera 3 works with MariaDB 10.1-10.3. Galera 4 works with MariaDB
10.4-10.6.

Galera 4 has new API,  thus does not work with MariaDB 10.3.


Thanks for clarifying. That was not obvious since the filename of the 
plugin library did not change. And another reason that dropping the 
virtual galera package should not do any harm.
(If the plugin would have changed the name (e.g. used a proper 
SOVERSION), -3 and -4 should be co-installable and we would not have 
this problem now.) Actually, I don't really like calling it "plugin" any 
more. (A probably good example of packaged plugins would be proftpd*.)


Andreas

PS: Otto, what do you think about dropping the epoch from 
src:mariadb-10.6 onwards and applying it only to the binary packages 
that don't change their names? If you want to do this, get in touch once 
you start preparing 10.6

Bug#988647: crash: please update to new upstream release

2021-07-07 Thread dann frazier

On Wed, Jul 7, 2021 at 12:17 PM Guilherme Piccoli
 wrote:
>
> Hi Troy, I'd like to enforce that request! We want to upgrade crash
> version on next Ubuntu release, and the correct process would be to
> match Debian's Sid version.
> Thanks in advance,

Hi Guillherme!

Just a heads-up that Debian is currently in freeze (see
https://release.debian.org/), so new upstream releases are unlikely to
appear in sid until after bullseye releases. Of course, we could bribe
Troy for an upload to experimental :) Let us know if we can help at
all.

  -dann

Bug#990618: gnome-maps: fail to start (JS ERROR: TypeError: source is undefined)

2021-07-07 Thread Davide Prina


Hi,

I have try to execute gnome-maps from another user:

$ xhost +si:localuser:$1
$ su - $1
$ DISPLAY=:0
$ gnome-maps
(org.gnome.Maps:21491): Clutter-CRITICAL **: 20:05:54.039: 
clutter_actor_set_size: assertion 'CLUTTER_IS_ACTOR (self)' failed


(org.gnome.Maps:21491): Clutter-CRITICAL **: 20:05:54.039: 
clutter_actor_set_size: assertion 'CLUTTER_IS_ACTOR (self)' failed


(org.gnome.Maps:21491): Clutter-CRITICAL **: 20:05:54.039: 
clutter_canvas_set_size: assertion 'CLUTTER_IS_CANVAS (canvas)' failed


(org.gnome.Maps:21491): Clutter-CRITICAL **: 20:05:54.040: 
clutter_content_invalidate: assertion 'CLUTTER_IS_CONTENT (content)' failed


(org.gnome.Maps:21491): Clutter-CRITICAL **: 20:05:54.040: 
clutter_actor_hide: assertion 'CLUTTER_IS_ACTOR (self)' failed



and then it start and it work fine. I don't see the satellite images, 
but all the rest work without problems.


I have try to see the environment variables, but I was unable to 
understand the problem.


Ciao
Davide

Bug#990802: RFA: propellor -- property-based host configuration management in haskell

2021-07-07 Thread Sean Whitton

Package: wnpp
Severity: normal
Control: affects -1 src:propellor

I am working on a new configuration management system, Consfigurator,
and recently was able to transfer all my usage of Propellor over to
Consfigurator.  It would be better for Propellor to be maintained in
Debian by someone still using it; thus, I request an adopter for the
propellor package.

The package description is:
 Propellor ensures that the system it's run in satisfies a list of
 properties, taking action as necessary when a property is not yet met.
 .
 It is configured using haskell.

-- 
Sean Whitton

Bug#990801: Bump kexec-tools version to 2.0.22

2021-07-07 Thread Guilherme G. Piccoli

Package: kexec-tools
Version: 1:2.0.20-2.1

Hi Khalid, I'd like to ask you for a bump in the version of Debian's
kexec-tools. Upstream is now at 2.0.22, so would be nice if Debian could
sync with that so we can sync the Ubuntu kexec-tools for our next
release, since we follow the Debian version here.

Thanks in advance,


Guilherme

Bug#988647: crash: please update to new upstream release

2021-07-07 Thread Guilherme Piccoli

Hi Troy, I'd like to enforce that request! We want to upgrade crash
version on next Ubuntu release, and the correct process would be to
match Debian's Sid version.
Thanks in advance,


Guilherme

Bug#989370: Reassinging #989370 to ifenslave: In bonding network configuration, hwaddress crashes networking service, fails to restart

2021-07-07 Thread Santiago Ruano Rincón

Control: reassign 989370 ifenslave

El 04/06/21 a las 14:55, Chris Hofstaedtler escribió:
> Control: reopen 989370
> Control: reassign 989370 ifupdown
> 
> Reassigning to ifupdown, which is the package having the
> /etc/network/interfaces conffile.
> 
> Chris

The bonding functionality is handled by the ifenslave package.
Reassinging it accordingly.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#990799: libsixel: CVE-2020-19668

Source: libsixel
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libsixel.

CVE-2020-19668[0]:
| Unverified indexs into the array lead to out of bound access in the
| gif_out_code function in fromgif.c in libsixel 1.8.6.

https://github.com/saitoha/libsixel/issues/136

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-2020-19668
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-19668

Please adjust the affected versions in the BTS as needed.

Bug#990798: Switch to fork?

2021-07-07 Thread Moritz Muehlenhoff

Source: libsixel
Severity: wishlist

https://github.com/saitoha/libsixel/issues/154 states that the original
author in active and there's now a fork, maybe Debian should also switch
to it?

Cheers,
 Moritz

Bug#990793: kubernetes: CVE-2020-8554 CVE-2020-8562 CVE-2021-25735 CVE-2021-25737

2021-07-07 Thread Moritz Muehlenhoff

On Thu, Jul 08, 2021 at 12:27:08AM +0800, Shengjing Zhu wrote:
> On Wed, Jul 7, 2021 at 11:48 PM Moritz Mühlenhoff  wrote:
> >
> > Source: kubernetes
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerabilities were published for kubernetes.
> >
> > These are not relevant for bullseye, as it only includes the client
> > package, but relevant for updates via fasttrack after the release:
> 
> Bullseye still includes the server package.

Oh indeed. Janos, can you please file an unblock request?

Cheers,
Moritz

Bug#990783: espeakup: Russian in debian-installer seems incomprehensible

2021-07-07 Thread Samuel Thibault

Control: reassign -1 espeak-ng

Hello,

Philip Hands, le mer. 07 juil. 2021 12:25:02 +0200, a ecrit:
> I'm not sure if this is an issue with espeakup or perhaps espeak-ng-data-udeb
> (which is at version 1.50+dfsg-7) -- please reassign as you see fit.

espeak-ng -v ru "Выберите местонахождение"

seems to be producing the same output, so reassigning to espeak-ng.

> I'm not a Russian speaker myself, but having asked someone who is to listen to
> this they report that they are unable to understand the audio even when the 
> text
> that is supposedly being read is in front of them.

Hum, that's bad. Does it help if we slow the speed down? E.g.

espeak-ng -s 100 -v ru "Выберите местонахождение"

Possibly it's just the default speed which is bad for russian. Trying
translate.google.com, it seems that -s 100 provides the same kind of
speed.

Samuel

Bug#990797: most: Please package new upstream release (5.1.0)

2021-07-07 Thread Boyuan Yang

Package: most
Severity: normal
X-Debbugs-CC: m...@debian.org

Dear Debian most package maintainer,

The upstream of package most is now at http://www.jedsoft.org/most/index.html
with a new release of version 5.1.0. Please package this new version.

Thanks,
Boyuan Yang


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

Bug#986800: CVE-2021-30163 CVE-2021-30164

2021-07-07 Thread Adi Kriegisch

Tags: security, patch

Dear maintainers,

I took the patches from upstream and rebased them; so far everything works
fine on our systems. I'd very much apprechiate an officially patched
version in buster-backports.

CVE-2021-31863: 
https://www.redmine.org/projects/redmine/repository/revisions/20854
CVE-2021-31864: 
https://www.redmine.org/projects/redmine/repository/revisions/20946
CVE-2021-31865: 
https://www.redmine.org/projects/redmine/repository/revisions/20970
CVE-2021-31866: 
https://www.redmine.org/projects/redmine/repository/revisions/20962

best regards,
Adi Kriegisch
Index: redmine-4.0.7/app/models/token.rb
===
--- redmine-4.0.7.orig/app/models/token.rb
+++ redmine-4.0.7/app/models/token.rb
@@ -113,11 +113,13 @@ class Token < ActiveRecord::Base
 return nil unless action.present? && key =~ /\A[a-z0-9]+\z/i
 
 token = Token.find_by(:action => action, :value => key)
-if token && (token.action == action) && (token.value == key) && token.user
-  if validity_days.nil? || (token.created_on > validity_days.days.ago)
-token
-  end
-end
+return unless token
+return unless token.action == action
+return unless ActiveSupport::SecurityUtils.secure_compare(token.value.to_s, key)
+return unless token.user
+return unless validity_days.nil? || (token.created_on > validity_days.days.ago)
+
+token
   end
 
   def self.generate_token_value
Index: redmine-4.0.7/app/controllers/sys_controller.rb
===
--- redmine-4.0.7.orig/app/controllers/sys_controller.rb
+++ redmine-4.0.7/app/controllers/sys_controller.rb
@@ -16,6 +16,8 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 
 class SysController < ActionController::Base
+  include ActiveSupport::SecurityUtils
+
   before_action :check_enabled
 
   def projects
@@ -74,7 +76,7 @@ class SysController < ActionController::
 
   def check_enabled
 User.current = nil
-unless Setting.sys_api_enabled? && params[:key].to_s == Setting.sys_api_key
+unless Setting.sys_api_enabled? && secure_compare(params[:key].to_s, Setting.sys_api_key.to_s)
   render :plain => 'Access denied. Repository management WS is disabled or key is invalid.', :status => 403
   return false
 end
Index: redmine-4.0.7/app/controllers/mail_handler_controller.rb
===
--- redmine-4.0.7.orig/app/controllers/mail_handler_controller.rb
+++ redmine-4.0.7/app/controllers/mail_handler_controller.rb
@@ -16,6 +16,8 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 
 class MailHandlerController < ActionController::Base
+  include ActiveSupport::SecurityUtils
+
   before_action :check_credential
 
   # Displays the email submission form
@@ -37,7 +39,7 @@ class MailHandlerController < ActionCont
 
   def check_credential
 User.current = nil
-unless Setting.mail_handler_api_enabled? && params[:key].to_s == Setting.mail_handler_api_key
+unless Setting.mail_handler_api_enabled? && secure_compare(params[:key].to_s, Setting.mail_handler_api_key.to_s)
   render :plain => 'Access denied. Incoming emails WS is disabled or key is invalid.', :status => 403
 end
   end
Index: redmine-4.0.7/test/unit/attachment_test.rb
===
--- redmine-4.0.7.orig/test/unit/attachment_test.rb
+++ redmine-4.0.7/test/unit/attachment_test.rb
@@ -151,6 +151,19 @@ class AttachmentTest < ActiveSupport::Te
 end
   end
 
+  def test_extension_update_should_be_validated_against_denied_extensions
+with_settings :attachment_extensions_denied => "txt, png" do
+  a = Attachment.new(:container => Issue.find(1),
+ :file => mock_file_with_options(:original_filename => "test.jpeg"),
+ :author => User.find(1))
+  assert_save a
+
+  b = Attachment.find(a.id)
+  b.filename = "test.png"
+  assert !b.save
+end
+  end
+
   def test_valid_extension_should_be_case_insensitive
 with_settings :attachment_extensions_allowed => "txt, Png" do
   assert Attachment.valid_extension?(".pnG")
Index: redmine-4.0.7/app/models/attachment.rb
===
--- redmine-4.0.7.orig/app/models/attachment.rb
+++ redmine-4.0.7/app/models/attachment.rb
@@ -27,7 +27,8 @@ class Attachment < ActiveRecord::Base
   validates_length_of :filename, :maximum => 255
   validates_length_of :disk_filename, :maximum => 255
   validates_length_of :description, :maximum => 255
-  validate :validate_max_file_size, :validate_file_extension
+  validate :validate_max_file_size
+  validate :validate_file_extension, :if => :filename_changed?
 
   acts_as_event :title => :filename,
 :url => Proc.new {|o| {:controller => 'attachments', :action

Bug#990796: dpkg: warning: package not in status nor available database at line

2021-07-07 Thread Christoph Anton Mitterer

Package: dpkg
Severity: normal


Hi.

I've seen the following several times now when upgrading from stretch to buster
via aptitude:

Setting up libgail-common:amd64 (2.24.32-3) ...
Setting up xscreensaver (5.42+dfsg1-1) ...

=> at this point /var/log/apt/term.log stops, which I guess it shouldn't...

Errors were encountered while processing:
 netfilter-persistent
 iptables-persistent

=> that this fails is probably related to iptables switching nft compatibiltiy
stuff and/or the old kernel being purged by myself during the upgrade


But the following is the actual reason I'm writing:

dpkg: warning: package not in status nor available database at line 4: 
clang-3.8:amd64
dpkg: warning: package not in status nor available database at line 5: 
libclang1-3.8:amd64
dpkg: warning: package not in status nor available database at line 6: 
python-lldb-3.8:amd64
dpkg: warning: package not in status nor available database at line 7: 
liblldb-3.8-dev:amd64
dpkg: warning: package not in status nor available database at line 8: 
lldb-3.8:amd64
dpkg: warning: package not in status nor available database at line 9: 
llvm-3.8-dev:amd64
dpkg: warning: package not in status nor available database at line 10: 
llvm-3.8:amd64
dpkg: warning: package not in status nor available database at line 11: 
libllvm3.8:amd64
dpkg: warning: package not in status nor available database at line 12: 
libperl5.24:amd64
dpkg: warning: package not in status nor available database at line 13: 
perl-modules-5.24:all
dpkg: warning: package not in status nor available database at line 14: 
libpython3.5:amd64
dpkg: warning: package not in status nor available database at line 15: 
python3.5:amd64
dpkg: warning: package not in status nor available database at line 16: 
libpython3.5-stdlib:amd64
dpkg: warning: package not in status nor available database at line 17: 
openjdk-8-jdk:amd64
dpkg: warning: package not in status nor available database at line 18: 
openjdk-8-jre:amd64
dpkg: warning: package not in status nor available database at line 19: 
libllvm3.9:amd64
dpkg: warning: package not in status nor available database at line 20: 
ca-cacert:all
dpkg: warning: package not in status nor available database at line 21: 
clang-3.8-doc:all
dpkg: warning: package not in status nor available database at line 22: 
gcc-6-locales:all
dpkg: warning: package not in status nor available database at line 24: 
linux-headers-4.9.0-14-amd64:amd64
dpkg: warning: package not in status nor available database at line 25: 
linux-compiler-gcc-6-x86:amd64
dpkg: warning: package not in status nor available database at line 26: 
gcc-6:amd64
dpkg: warning: package not in status nor available database at line 27: 
cpp-6:amd64
dpkg: warning: package not in status nor available database at line 28: 
cpp-6-doc:all
dpkg: warning: package not in status nor available database at line 30: 
g++-6-multilib:amd64
dpkg: warning: package not in status nor available database at line 31: 
g++-6:amd64
dpkg: warning: package not in status nor available database at line 32: 
libx32stdc++-6-dev:amd64
dpkg: warning: package not in status nor available database at line 33: 
gcc-6-multilib:amd64
dpkg: warning: package not in status nor available database at line 34: 
gcc-6-base:amd64
dpkg: warning: package not in status nor available database at line 35: 
gcc-6-doc:all
dpkg: warning: package not in status nor available database at line 38: 
lib32stdc++-6-dev:amd64
dpkg: warning: package not in status nor available database at line 39: 
lib32gcc-6-dev:amd64
dpkg: warning: package not in status nor available database at line 40: 
libx32gcc-6-dev:amd64
dpkg: warning: package not in status nor available database at line 41: 
lib32asan3:amd64
dpkg: warning: package not in status nor available database at line 42: 
libstdc++-6-dev:amd64
dpkg: warning: package not in status nor available database at line 43: 
libobjc-6-dev:amd64
dpkg: warning: package not in status nor available database at line 44: 
libgcc-6-dev:amd64
dpkg: warning: package not in status nor available database at line 45: 
libasan3:amd64
dpkg: warning: package not in status nor available database at line 46: 
libbind9-140:amd64
dpkg: warning: package not in status nor available database at line 47: 
libblas-common:amd64
dpkg: warning: package not in status nor available database at line 48: 
libboost-filesystem1.62.0:amd64
dpkg: warning: package not in status nor available database at line 49: 
libcephfs1:amd64
dpkg: warning: package not in status nor available database at line 50: 
libboost-iostreams1.62.0:amd64
dpkg: warning: package not in status nor available database at line 51: 
libboost-program-options1.62.0:amd64
dpkg: warning: package not in status nor available database at line 52: 
libboost-random1.62.0:amd64
dpkg: warning: package not in status nor available database at line 53: 
libboost-regex1.62.0:amd64
dpkg: warning: package not in status nor available database at line 54: 
libboost-thread1.62.0:amd64
dpkg:

Bug#808802: SERVICE DE COMPTE

2021-07-07 Thread GINA ALEJANDRINA VALLADARES BANCHON




SERVICE DE COMPTE



Cher utilisateur de messagerie,



Nous avons remarqué une connexion à votre compte Microsoft à partir d'un 
appareil non reconnu le mercredi 7 juillet 2021 (GMT + 8) à 13h40 depuis San 
José, Uruguay.



Était vous? Si tel est le cas, veuillez ignorer le reste de cet e-mail.



Si ce n'est pas vous, suivez les liens ci-dessous pour sécuriser votre compte 
de messagerie et fournir les informations nécessaires pour que votre compte 
reste actif.



CLIQUEZ ICI



CODE D'ACCES : 2021



Merci,

Sécurité de la Messagerie Web









Trabajo Final

De: GINA ALEJANDRINA VALLADARES BANCHON
Enviado: miércoles, 4 de noviembre de 2020 1:39
Para: NORY ALEJANDRA VINA PALOMINO

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

2021-07-07 Thread David Mohammed

Basically budgie uses Mutter, the GNOME window manager. So it will be
updates to mutter that you will see resolution of issues like this.

The other thing you could try is look at budgie desktop settings and turn
off window animations.

On Wed, 7 Jul 2021, 16:48 Pascal,  wrote:

> Package: budgie-desktop
> Version: 10.5.2-3
> Followup-For: Bug #990678
> X-Debbugs-Cc: pascal.mart...@gmx.fr
>
> Dear Maintainer,
>
> I had the opportunity to use software in Budgie recently and even made
> (quick)
> tests with most of the applications I have on my PC. So I came again across
> those same bugs about window displaying. Those bugs come unexpectedly, they
> happen rarely now, but they still DO happen.
>
> Apart from MPV, of which I abundantly talked about here above, the first
> striking and undeniable bug I came across was with QuteBrowser. It's a nice
> browser I use when Firefox is not quick enough. When quitting it (by
> clicking
> the x close button upright or typing  I don't remember, though it
> may
> be important) the window apparently stayed open and the "cleverly hidden"
> Budgie tool bar/panel reappeared. In fact QuteBrowser was really shut and
> the
> desktop should have been displayed instead, which it did when I refreshed
> the
> screen.
> Of all the applications I tested, all seemed to work fine (they generally
> do)
> except DevHelp. In that program too, the menu window "Shortcuts" generally
> doesn't display as being shut when in fact it is.
>
> At that point, the least thing you do that refreshes the screen makes
> things
> come to normal, and all visible evidence of the bug is gone. For example
> pressing the  key (MS-Windows key), , making a screenshot,
> etc.
> So if we act too quickly we always miss those bugs, the more so as they
> generally come unnoticed, and fortunately much more rarely than they did a
> few
> months ago.
> So we notice the bug by stopping our work, because what we see on the
> screen is
> not understandable : We close a window and it is still there, we move a
> window
> and we don't see it move. Then we refresh the screen and the closed window
> has
> gone and the moved window has moved.
>
> That problem of windows that can't be moved, I observed again with Abiword.
> Abiword is a program I like a lot but it is not heavily maintained /
> updated.
> Now, rather often, the menu windows seem to close correctly but they move
> badly. You grab a window to move it and nothing happens (unlike MPV where
> you
> see some kind of transparent window frame moving). That window seems to be
> frozen. When you refresh the screen you see that it had effectively moved,
> invisibly.
>
> Since things have improved with Budgie these last months, if little or
> nothing
> has been done about these window bugs, the improvement may have come from
> the
> Gnome updates, so what updates and when ? And why do those bugs not happen
> everytime, as generally expected from a bug ? Is it some kind of Budgie
> screen
> refreshment, compositor / display server problem ? Just asking to help, I
> could
> do no more alas !
>
> So I wanted to report this quickly, not waiting for new evidence, because
> of
> the expected Debian 11 stable. I read things about a possible date release
> but
> I wouldn't risk to repeat it, Debian's policy of "It is ready when it is
> ready"
> is surely the best one.
>
> Please excuse my verbosity, it's a personal shortcoming ;) and I want to
> be as
> clear and precise as possible.
>
> Cordially,
> Pascal
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages budgie-desktop depends on:
> ii  budgie-core  10.5.2-3
> ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
> ii  gir1.2-budgie-1.010.5.2-3
> ii  gnome-control-center 1:3.38.4-1
> ii  gnome-menus  3.36.0-1
> ii  network-manager-gnome1.20.0-3
>
> Versions of packages budgie-desktop recommends:
> ii  budgie-desktop-view  1.1.1-1
>
> Versions of packages budgie-desktop suggests:
> ii  gnome-terminal  3.38.3-1
> ii  nautilus3.38.2-1
> pn  slick-greeter   
>

Bug#990754: unblock: wpewebkit/2.32.1-1

2021-07-07 Thread Sebastian Ramacher

On 2021-07-07 13:01:32 +0200, Alberto Garcia wrote:
> On Wed, Jul 07, 2021 at 11:53:16AM +0200, Moritz Muehlenhoff wrote:
> > > What's the security team's take on this? Will browsers other than
> > > firefox, chromium and webkit2gtk itself be security supported
> > > throughout bullseye's lifetime?
> > 
> > We synced up with this before; wpewebkit is closely related to
> > webkit and Alberto will keep both updated in stable.
> 
> As I said wpewebkit and webkit2gtk releases are made almost in
> parallel, the numbering scheme, etc., is almost identical and they
> have joint security advisories[1]. A longer term upstream goal would
> be to merge both projects and make the GTK API a layer on top of
> wpewebkit, but this is not currently on the roadmap.
> 
> At the moment doing an additional security release for wpewebkit is
> going to be little more than adapting the webkit2gtk advisory.

ACK, then please send a (filtered) debdiff for wpewebkit to the bug
report so that we can look at unblocking it.

Cheers

> 
> > > The concern also extends to web rendering engines not explicitly
> > > mentioned here, with the exception of  > > role="source">webkit2gtk.
> > 
> > Good point wrt the releases notes part. I guess we should simply
> > make this "with the exception of webkit2gtk/wpewebkit". Alberto,
> > could you file a bug against the release notes?
> 
> Yes, but thinking about it there is something new in bullseye and I
> would like to discuss it because it affects webkit2gtk as well.
> 
> The WPE WebKit project has a couple of additional libraries
> called libwpe and wpebackend-fdo. They are used by wpewebkit and,
> since a couple of years ago, also by webkit2gtk to implement
> hardware-accelerated rendering under Wayland. In the case of
> webkit2gtk this dependency is optional but recommended.
> 
> The buster builds of webkit2gtk are made with all wpe libraries
> disabled because those packages were never available in buster in the
> first place. In bullseye they are enabled so any security update for
> bullseye would need to have them enabled as well.
> 
> Both libwpe and wpebackend-fdo are projects with little activity
> and generally few and small changes. I don't expect that building
> the latest version of webkit2gtk or wpewebkit for a security update
> requires updating any of those libraries, but I think it can
> theoretically happen. Is there a way to handle that in Debian?
> 
> Berto
> 
> [1] https://lists.webkit.org/pipermail/webkit-gtk/2021-March/003689.html
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990795: libident -- Fails to build reproducibly

2021-07-07 Thread Nilesh Patra

Package: libident
Version: 0.22-3.1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps, buildpath
X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, 
reproducible-b...@lists.alioth.debian.org


Dear Maintainer,

libident fails to build reproducibly because:

a) It injects timestamps in gzip
b) It injects buildpath

Please consider applying the attached patch

Nilesh

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

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

Versions of packages libident depends on:
ii  libc6  2.31-3

libident recommends no packages.

Versions of packages libident suggests:
pn  libident-dev  
diff -u libident-0.22/Makefile libident-0.22/Makefile
--- libident-0.22/Makefile
+++ libident-0.22/Makefile
@@ -117,7 +117,7 @@
(PACKNAME=`basename \`pwd\`` ; cd .. ; /usr/gnu/bin/tar Zcf 
$$PACKNAME.tar.Z $$PACKNAME)
 
 dist distz:clean version
-   (PACKNAME=`basename \`pwd\`` ; cd .. ; /usr/gnu/bin/tar cf - $$PACKNAME 
| gzip -9 >$$PACKNAME.tar.gz)
+   (PACKNAME=`basename \`pwd\`` ; cd .. ; /usr/gnu/bin/tar cf - $$PACKNAME 
| gzip -9n >$$PACKNAME.tar.gz)
 
 
 
diff -u libident-0.22/debian/rules libident-0.22/debian/rules
--- libident-0.22/debian/rules
+++ libident-0.22/debian/rules
@@ -27,7 +27,7 @@
 $(tmpdir-dev)/usr/share/man/man3
 
 CC=gcc
-CFLAGS=-g -Wall -DHAVE_ANSIHEADERS -D_REENTRANT
+CFLAGS=-g -Wall -DHAVE_ANSIHEADERS -D_REENTRANT -ffile-prefix-map=$(CURDIR)=.
 LDFLAGS=
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -71,15 +71,15 @@
$(tmpdir)/usr/share/man/man8
$(installbin) -s ident-tester \
$(tmpdir)/usr/sbin/in.identtestd
-   gzip -v9 $(tmpdir)/usr/share/man/man?/*
-   gzip -v9 $(tmpdir-dev)/usr/share/man/man?/*
+   gzip -v9n $(tmpdir)/usr/share/man/man?/*
+   gzip -v9n $(tmpdir-dev)/usr/share/man/man?/*
for manalias in ident_lookup ident_id ident_free id_open id_close 
id_query \
id_parse id_fileno ; do \
ln -s ident.3.gz 
$(tmpdir-dev)/usr/share/man/man3/$$manalias.3.gz ; \
done
# dont compress copyright
-   gzip -v9 $(tmpdir)/usr/share/doc/libident/README
-   gzip -v9 $(tmpdir)/usr/share/doc/libident/changelog.Debian
+   gzip -v9n $(tmpdir)/usr/share/doc/libident/README
+   gzip -v9n $(tmpdir)/usr/share/doc/libident/changelog.Debian
strip --strip-debug$(tmpdir-dev)/usr/lib/libident.a
strip --strip-unneeded $(tmpdir)/usr/lib/libident.so.$(version)
strip --remove-section=.comment $(tmpdir)/usr/lib/libident.so.$(version)

Bug#990794: binutils FTCBFS: does not honour DEB_BUILD_OPTIONS=nocheck for some architectures

2021-07-07 Thread Helmut Grohne

Source: binutils
Version: 2.35.2-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
User: helm...@debian.org
Usertags: rebootstrap

binutils' debian/rules has code to specifically ignore
DEB_BUILD_OPTIONS=nocheck when building for e.g. m68k. I suppose this is
in place to override buildd maintainers that set this option. Working
around such disagreements using code seems like a suboptimal solution,
but I prefer not being dragged into this dispute. Unfortunately, it
happens to break cross building e.g. from amd64 to m68k. As a
compromise, I propose reducing the impact of this code to specifically
exempt all cross builds from ignoring nocheck. Would that be acceptable?

I'm attaching a patch for unstable for your convenience. It doesn't
apply cleanly to experimental. Another form of the patch is:

sed -i -e 's/ifeq (\(,$(filter $(DEB_HOST_ARCH),\)/ifneq 
($(DEB_BUILD_ARCH)\1/' debian/rules

Helmut
diff --minimal -Nru binutils-2.35.2/debian/changelog 
binutils-2.35.2/debian/changelog
--- binutils-2.35.2/debian/changelog2021-02-20 16:38:30.0 +0100
+++ binutils-2.35.2/debian/changelog2021-07-07 07:29:03.0 +0200
@@ -1,3 +1,10 @@
+binutils (2.35.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Honour nocheck option during cross builds. Closes: #-1.
+
+ -- Helmut Grohne   Wed, 07 Jul 2021 07:29:03 +0200
+
 binutils (2.35.2-2) unstable; urgency=medium
 
   * Add debugedit as dependency for the build autopkg test.
diff --minimal -Nru binutils-2.35.2/debian/rules binutils-2.35.2/debian/rules
--- binutils-2.35.2/debian/rules2021-02-19 18:21:07.0 +0100
+++ binutils-2.35.2/debian/rules2021-07-07 07:29:01.0 +0200
@@ -550,7 +550,7 @@
 with_check := yes
 ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
   # override buildd admins to run the testsuite anyway ...
-  ifeq (,$(filter $(DEB_HOST_ARCH), m68k sh4))
+  ifneq ($(DEB_BUILD_ARCH),$(filter $(DEB_HOST_ARCH),m68k sh4))
 with_check := disabled through DEB_BUILD_OPTIONS
   endif
 endif

Bug#990793: kubernetes: CVE-2020-8554 CVE-2020-8562 CVE-2021-25735 CVE-2021-25737

2021-07-07 Thread Janos LENART

Thanks for the report Moritz.

As zhsj@ wrote bullseye atm has 1.20.2-1, which has the server packages,
instead of 1.20.5+really1.20.2-1, which does only includes that client it
was of course uploaded for exactly this reason. I will file a bug so the
correct version gets included in bullseye.

On Wed, 7 Jul 2021 at 17:30, Shengjing Zhu  wrote:

> On Wed, Jul 7, 2021 at 11:48 PM Moritz Mühlenhoff  wrote:
> >
> > Source: kubernetes
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerabilities were published for kubernetes.
> >
> > These are not relevant for bullseye, as it only includes the client
> > package, but relevant for updates via fasttrack after the release:
>
> Bullseye still includes the server package.
>
> $ rmadison -S kubernetes
> kubernetes| 1.20.2-1  | testing| source
> kubernetes| 1.20.5+really1.20.2-1 | unstable   | source
> kubernetes-client | 1.20.2-1  | testing| amd64, arm64,
> armel, armhf, i386, s390x
> kubernetes-client | 1.20.5+really1.20.2-1 | unstable   | amd64, arm64,
> armel, armhf, i386, s390x
> kubernetes-master | 1.20.2-1  | testing| amd64, arm64,
> armel, armhf, i386, s390x
> kubernetes-node   | 1.20.2-1  | testing| amd64, arm64,
> armel, armhf, i386, s390x
>
> --
> Shengjing Zhu
>


-- 
LÉNÁRT, János

Bug#990777: mirror listing update for debianmirror.nkn.in

2021-07-07 Thread Julien Cristau

Control: tag -1 moreinfo

Hi,

some comments/issues:

o The tracefile at
  http://debianmirror.nkn.in/debian/project/trace/debianmirror.nkn.in
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your tracefile is missing one or both of them.

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Can you take a look?

Cheers,
Julien

On Wed, Jul 07, 2021 at 03:04:57AM +, S.Gopinath wrote:
> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: debianmirror.nkn.in
> Type: leaf
> Archive-architecture: amd64 arm64 armhf
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: S.Gopinath 
> Country: IN India
> Location: Chennai
> Sponsor: National Knowledge Network https://www.nkn.in
> Comment: Due to some constraints, the site was working for sometime. The site 
> was re-established and may add the same.
>  
>  Ipv6 is still an issue at this moment
> 
> 
> 
> 
> Trace Url: http://debianmirror.nkn.in/debian/project/trace/
> Trace Url: 
> http://debianmirror.nkn.in/debian/project/trace/ftp-master.debian.org
> Trace Url: http://debianmirror.nkn.in/debian/project/trace/debianmirror.nkn.in
>

Bug#990793: kubernetes: CVE-2020-8554 CVE-2020-8562 CVE-2021-25735 CVE-2021-25737

2021-07-07 Thread Shengjing Zhu

On Wed, Jul 7, 2021 at 11:48 PM Moritz Mühlenhoff  wrote:
>
> Source: kubernetes
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
>
> Hi,
>
> The following vulnerabilities were published for kubernetes.
>
> These are not relevant for bullseye, as it only includes the client
> package, but relevant for updates via fasttrack after the release:

Bullseye still includes the server package.

$ rmadison -S kubernetes
kubernetes| 1.20.2-1  | testing| source
kubernetes| 1.20.5+really1.20.2-1 | unstable   | source
kubernetes-client | 1.20.2-1  | testing| amd64, arm64,
armel, armhf, i386, s390x
kubernetes-client | 1.20.5+really1.20.2-1 | unstable   | amd64, arm64,
armel, armhf, i386, s390x
kubernetes-master | 1.20.2-1  | testing| amd64, arm64,
armel, armhf, i386, s390x
kubernetes-node   | 1.20.2-1  | testing| amd64, arm64,
armel, armhf, i386, s390x

-- 
Shengjing Zhu

Bug#990735: mirror submission for mirror.mia.velocihost.net

2021-07-07 Thread Julien Cristau

Control: tag -1 moreinfo

Hi,

I'm seeing errors accessing
http://mirror.mia.velocihost.net/debian/dists/stable/main/source/Sources.xz

Can you double check the mirroring?

Cheers,
Julien

On Mon, Jul 05, 2021 at 08:58:40PM +, Support team wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.mia.velocihost.net
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Support team 
> Country: US United States
> Location: Miami, FL 
> Sponsor: VelociHOST https://www.velocihost.net/
> Comment: Hosted by VelociHOST Bare Metal Servers. Located in Miami, FL - Full 
> native IPv6 and IPv4 support. Syncs every 6 hours.
> 
> 
> 
> 
> Trace Url: http://mirror.mia.velocihost.net/debian/project/trace/
> Trace Url: 
> http://mirror.mia.velocihost.net/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mirror.mia.velocihost.net/debian/project/trace/mirror.mia.velocihost.net
>

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

2021-07-07 Thread Otto Kekäläinen

>
> Some general understanding question: Would mariadb-server-10.5 work with
> galera-3, too? (with only the Depends being relaxed to 'Depends:
> galera-4 | galera-3, ...', without recompilation or similar actions)
> (Bonus question: would mariadb-server-10.3/buster work with
> galera-4/bullseye with only the dependencies similarily relaxed?)
> That could allow for even easier solutions.
>

Galera 3 works with MariaDB 10.1-10.3. Galera 4 works with MariaDB
10.4-10.6.

Galera 4 has new API,  thus does not work with MariaDB 10.3.

MariaDB needs Galera only if the feature is used. In future might change
Depends to Suggests.

Bug#990667: dgit(7) Documentation: MODEL dgit-repo, --overwrite, /fast forward/fast-forward/, --deliberately-not-fast-forward, ...

2021-07-07 Thread Sean Whitton

Hello,

On Wed 07 Jul 2021 at 02:36PM +09, Osamu Aoki wrote:

> In order to try dgit for my imediff package, I was initially reading 
> dgit-maint-
> merge(7).  It's basically a Ncurses based merge/split tool for which I took 
> over
> upstream.  Since I was upstream, I was comiting everything to devel branch.  
> Then I
> made a upstream tarball by excluding debian/ directory.  Using this upstream 
> tarball,
> I was making non-native dpkg 3.0 (quilt) package.  That tarball and uploaded 
> debian
> package was kept in repo as gbp-style branches 
> (master/upstream/pristine-tar).  Since
> I sometimes made the last minutes change to debian/changelog, master was not 
> exactly
> as devel.  So after upload, I merged master back to devel.  I got sick of this
> complicated scheme and tried git-maint-merge(7).  Basically, devel branch was 
> patch
> applied while master was sometimes created manually using git-format-patch 
> etc. on
> devel branch.

Okay.

> Naturally, "Existing git history using another workflow" was the one and I 
> started
> from my devel branch.  The last part of this document goes as:
>
>>The first dgit push will require --overwrite.  If this is the first
>>ever dgit push of the package, consider passing
>>--deliberately-not-fast-forward instead of --overwrite.  This avoids
>>introducing a new origin commit into your git history.  (This origin
>>commit would represent the most recent non-dgit upload of the package,
>>but this should already be represented in your git history.)
>
> This talks "first" twice.  What makes "first" not "first ever"? This threw me 
> out.

It's deliberately distinguishing between your first dgit push using this
workflow, and the first ever dgit push of the package.  For example,
someone else might have NMUed your package using dgit long before you
decided to switch.

It should be more explicit.

> Besides, "overwrite" sounds scary. Also, at the botton in
> "INCORPORATING NMUS", it aian recommend to use --overwrite.  Normally,
> we don't overwrite things without fully understanding its impacts.

We should probably rename --overwrite.  Thoughts?

> Then I went back to the top of the page: "INTRODUCTION" to understand
> what is this
> doing.   There,I saw "the information such aseries would contain is readily 
> available
> from dgit-repos".  This "dgit-repo" made me wonder what exactly is this.  Is 
> there
> anything more than upload queue and my salsa repo.

Ah.  dgit-repos is pretty much just , a
special git server.  We should mention that in the workflow manpage.

Please do share further suggestions/patches to the manpages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#981224: ruby-uglifier: FTBFS: tests fail: uglifier_spec.rb:383, uglifier_spec.rb:751

2021-07-07 Thread Pirate Praveen

On Wed, 27 Jan 2021 23:18:24 +0100 Andreas Beckmann  
wrote:
> ruby-uglifier/experimental recently started to FTBFS, probably after 
some

> build-dependency was updated:

I think switching to ruby-terser is a good idea (gitlab and diaspora 
moved already). This should be a drop in replacement (moving gitlab and 
diaspora was pretty easy).

See https://github.com/diaspora/diaspora/pull/8268 for an idea. I think 
rails need it only for the newapp autopkgtests,ruby-sprockets I have 
not checked.

Should we target removal of ruby-uglifier from bookworm?

$ reverse-depends ruby-uglifier
Reverse-Recommends
* nanoc

Reverse-Depends
* diaspora
* gitlab
* obs-api
* rails

$ reverse-depends -b ruby-uglifier
Reverse-Build-Depends
* nanoc
* open-build-service
* rails
* ruby-sprockets

Bug#950008: gfan: assertion fails on riscv64

2021-07-07 Thread Torrance, Douglas

On Tue, 28 Jan 2020 10:29:07 +0100 Tobias Hansen  wrote:
> many of sagemath's doctests in the interface to gfan fail on riscv64 with the 
> following error:
> 
> gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed.
> 
> It looks like the pointer arithmetic in the function tail() in 
> application.cpp does not work like this on riscv64. Unfortunately there are 
> no porterboxes for riscv64 yet, so I can't come up with a minimal example 
> triggering the bug.

This is also causing macaulay2 to FTBFS in riscv64 [1]:

checking whether the package gfan is installed... gfan: 
src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed.
yes, but < 0.6, will build

...

make -C gfan fetch
make[3]: Entering directory '/<>/M2/libraries/gfan'
error: for the third-party library or program source "gfan"
   the source code is not present in the file 
"/<>/M2/BUILD/tarfiles/gfan0.6.2.tar.gz"
   so either download a "fat" tar file of the Macaulay2 source code
   or rerun the Macaulay2 "configure" command with the added option 
"--enable-download"
   to enable automatic downloading of the source code over the internet
make[3]: *** [../Makefile.library:235: 
/<>/M2/BUILD/tarfiles/gfan0.6.2.tar.gz] Error 1

[1] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=riscv64=1.18%2Bds-1%7Eexp1=1625665959=0

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

2021-07-07 Thread Pascal

Package: budgie-desktop
Version: 10.5.2-3
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

I had the opportunity to use software in Budgie recently and even made (quick)
tests with most of the applications I have on my PC. So I came again across
those same bugs about window displaying. Those bugs come unexpectedly, they
happen rarely now, but they still DO happen.

Apart from MPV, of which I abundantly talked about here above, the first
striking and undeniable bug I came across was with QuteBrowser. It's a nice
browser I use when Firefox is not quick enough. When quitting it (by clicking
the x close button upright or typing  I don't remember, though it may
be important) the window apparently stayed open and the "cleverly hidden"
Budgie tool bar/panel reappeared. In fact QuteBrowser was really shut and the
desktop should have been displayed instead, which it did when I refreshed the
screen.
Of all the applications I tested, all seemed to work fine (they generally do)
except DevHelp. In that program too, the menu window "Shortcuts" generally
doesn't display as being shut when in fact it is.

At that point, the least thing you do that refreshes the screen makes things
come to normal, and all visible evidence of the bug is gone. For example
pressing the  key (MS-Windows key), , making a screenshot, etc.
So if we act too quickly we always miss those bugs, the more so as they
generally come unnoticed, and fortunately much more rarely than they did a few
months ago.
So we notice the bug by stopping our work, because what we see on the screen is
not understandable : We close a window and it is still there, we move a window
and we don't see it move. Then we refresh the screen and the closed window has
gone and the moved window has moved.

That problem of windows that can't be moved, I observed again with Abiword.
Abiword is a program I like a lot but it is not heavily maintained / updated.
Now, rather often, the menu windows seem to close correctly but they move
badly. You grab a window to move it and nothing happens (unlike MPV where you
see some kind of transparent window frame moving). That window seems to be
frozen. When you refresh the screen you see that it had effectively moved,
invisibly.

Since things have improved with Budgie these last months, if little or nothing
has been done about these window bugs, the improvement may have come from the
Gnome updates, so what updates and when ? And why do those bugs not happen
everytime, as generally expected from a bug ? Is it some kind of Budgie screen
refreshment, compositor / display server problem ? Just asking to help, I could
do no more alas !

So I wanted to report this quickly, not waiting for new evidence, because of
the expected Debian 11 stable. I read things about a possible date release but
I wouldn't risk to repeat it, Debian's policy of "It is ready when it is ready"
is surely the best one.

Please excuse my verbosity, it's a personal shortcoming ;) and I want to be as
clear and precise as possible.

Cordially,
Pascal

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter

Bug#990793: kubernetes: CVE-2020-8554 CVE-2020-8562 CVE-2021-25735 CVE-2021-25737

Source: kubernetes
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for kubernetes.

These are not relevant for bullseye, as it only includes the client
package, but relevant for updates via fasttrack after the release:

CVE-2020-8554[0]:
| Kubernetes API server in all versions allow an attacker who is able to
| create a ClusterIP service and set the spec.externalIPs field, to
| intercept traffic to that IP address. Additionally, an attacker who is
| able to patch the status (which is considered a privileged operation
| and should not typically be granted to users) of a LoadBalancer
| service can set the status.loadBalancer.ingress.ip to similar effect.

https://www.openwall.com/lists/oss-security/2020/12/07/5
https://github.com/kubernetes/kubernetes/issues/97076

CVE-2020-8562[1]:
https://www.openwall.com/lists/oss-security/2021/05/04/8

CVE-2021-25735[2]:
Validating Admission Webhook does not observe some previous fields
https://www.openwall.com/lists/oss-security/2021/04/14/1
https://github.com/kubernetes/kubernetes/issues/100096

CVE-2021-25737[3]:
https://www.openwall.com/lists/oss-security/2021/05/18/4

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-2020-8554
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8554
[1] https://security-tracker.debian.org/tracker/CVE-2020-8562
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8562
[2] https://security-tracker.debian.org/tracker/CVE-2021-25735
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25735
[3] https://security-tracker.debian.org/tracker/CVE-2021-25737
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25737

Please adjust the affected versions in the BTS as needed.

Bug#990792: redmine: CVE-2021-31863 CVE-2021-31864 CVE-2021-31865 CVE-2021-31866

Source: redmine
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for redmine.

CVE-2021-31863[0]:
| Insufficient input validation in the Git repository integration of
| Redmine before 4.0.9, 4.1.x before 4.1.3, and 4.2.x before 4.2.1
| allows Redmine users to read arbitrary local files accessible by the
| application server process.

https://www.redmine.org/news/131
https://www.redmine.org/projects/redmine/repository/revisions/20854


CVE-2021-31864[1]:
| Redmine before 4.0.9, 4.1.x before 4.1.3, and 4.2.x before 4.2.1
| allows attackers to bypass the add_issue_notes permission requirement
| by leveraging the incoming mail handler.

https://www.redmine.org/news/131
https://www.redmine.org/projects/redmine/repository/revisions/20946


CVE-2021-31865[2]:
| Redmine before 4.0.9, 4.1.x before 4.1.3, and 4.2.x before 4.2.1
| allows users to circumvent the allowed filename extensions of uploaded
| attachments.

https://www.redmine.org/news/131
https://www.redmine.org/projects/redmine/repository/revisions/20970


CVE-2021-31866[3]:
| Redmine before 4.0.9 and 4.1.x before 4.1.3 allows an attacker to
| learn the values of internal authentication keys by observing timing
| differences in string comparison operations within SysController and
| MailHandlerController.

https://www.redmine.org/news/131
https://www.redmine.org/projects/redmine/repository/revisions/20962


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-2021-31863
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31863
[1] https://security-tracker.debian.org/tracker/CVE-2021-31864
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31864
[2] https://security-tracker.debian.org/tracker/CVE-2021-31865
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31865
[3] https://security-tracker.debian.org/tracker/CVE-2021-31866
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31866

Please adjust the affected versions in the BTS as needed.

Bug#990791: ruby-addressable: CVE-2021-32740

Source: ruby-addressable
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ruby-addressable.

CVE-2021-32740[0]:
| Addressable is an alternative implementation to the URI implementation
| that is part of Ruby's standard library. An uncontrolled resource
| consumption vulnerability exists after version 2.3.0 through version
| 2.7.0. Within the URI template implementation in Addressable, a
| maliciously crafted template may result in uncontrolled resource
| consumption, leading to denial of service when matched against a URI.
| In typical usage, templates would not normally be read from untrusted
| user input, but nonetheless, no previous security advisory for
| Addressable has cautioned against doing this. Users of the parsing
| capabilities in Addressable but not the URI template capabilities are
| unaffected. The vulnerability is patched in version 2.8.0. As a
| workaround, only create Template objects from trusted sources that
| have been validated not to produce catastrophic backtracking.

https://github.com/sporkmonger/addressable/security/advisories/GHSA-jxhc-q857-3j6g
https://github.com/sporkmonger/addressable/commit/b48ff03347a6d46e8dc674e242ce74c6381962a5#diff-fb36d3dc67e6565ffde17e666a98697f48e76dac38fabf1bb9e97cdf3b583d76

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-2021-32740
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32740

Please adjust the affected versions in the BTS as needed.

Bug#990255: keyringer incorrectly tries to use vim settings from '/usr/bin/../share/keyringer/editors/vim'

2021-07-07 Thread Cody Brownstein

rhatto wrote:
> Just released keyringer 0.5.6 which I believe fix this issue by moving
> the file into /usr/share/keyringer/editos/vim.

Awesome! I think we need a new package now, at least that's what's being
reported at:

https://tracker.debian.org/pkg/keyringer



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990787: Follow-up: patroni: Custom data-directory is ignored during bootstrap

2021-07-07 Thread Ralph Weires

As follow-up to the initial report.

The same issue also exists in the corresponding pg_clonecluster_patroni
script, too.

Affects the current buster (stable) version "1.5.5-2: all" at least.

>From looking into the same files of sid (unstable) version "2.0.2-1: all",
here it seems that the problem has been addressed.

Thanks.

Bug#990790: Regression: PAM does not find modules in /lib/security

2021-07-07 Thread Sam Hartman

package: libpam0g
version: 1.4.0-1
severity: important

In the merge of upstream 1.4.0, we lost the ability to read
/lib//security and only support /lib/security/multiarch_path.
Steve says that this was not an intentional change; it appears to be a
regression that affects software both inside and outside Debian.
I think software inside Debian that doesn't use multiarch paths for PAM
modules is buggy because it breaks non-native arch applications that use
libpam.
Even so, it is desirable to fix.
See bug 990412 for more details; I'm apparently not good enough at using
the BTS to manage to clone a merged bug.

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch


On 07/07/2021 15.37, Andreas Beckmann wrote:

you can find a 990708 branch in both repositories


The galera-4 upgrade job failed, but I'd expect that to succeed once the 
mariadb-server-10.5 change is in as well.


BTW, the following apt option might be helpful for debugging upgrade 
issues in your CI jobs:


  Debug::pkgProblemResolver "true";

Andreas

Bug#990789: LERC compression in TIFF

2021-07-07 Thread Antonio Valentino

Package: tiff
Version: 4.3.0-1

Starting form libtiff v4.3 support for the LERC compression codec has been 
officially integrated into libtiff.
LERC is a very interesting compressor and it is gaining a lot o momentum 
recently.

Please consider to enable the LERC coded in the debian package for libtiff 
(v4.3.0~1 is currently in experimental).


Kind regards
--
Antonio Valentino

Bug#990788: unblock: llvm-toolchain-9/1:9.0.1-17 (pre-approval)

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

Please unblock package llvm-toolchain-9

Hi,

I'd like to drop the Recommends: libomp-9-dev from clang-9
libomp-*-dev are not co-installable and libomp-dev depends on
libomp-11-dev. Having the Recomends on the non-default libomp-9-dev
causes many upgrade scenarios from buster with --install-recommends
enabled and libomp-dev installed to keep libomp-dev at the buster
version (and therefore libomp-7-dev installed) if some bullseye package
involved is built against clang-9 instead of clang-11.
With this Recommends dropped, libomp-dev always gets upgraded to the
bullseye version and libomp-11-dev gets installed.

The clang-9 bug is #990452

Andreas

unblock llvm-toolchain-9/1:9.0.1-17
diff -Nru llvm-toolchain-9-9.0.1/debian/changelog 
llvm-toolchain-9-9.0.1/debian/changelog
--- llvm-toolchain-9-9.0.1/debian/changelog 2021-01-08 12:48:25.0 
+0100
+++ llvm-toolchain-9-9.0.1/debian/changelog 2021-06-28 20:41:14.0 
+0200
@@ -1,3 +1,11 @@
+llvm-toolchain-9 (1:9.0.1-17) UNRELEASED; urgency=medium
+
+  * clang-9: Drop Recommends: libomp-9-dev which is not co-installable with
+libomp-11-dev (and libomp-dev) for smoother upgrades of libomp-dev from
+buster to bullseye.  (Closes: #-1)
+
+ -- Andreas Beckmann   Mon, 28 Jun 2021 20:41:14 +0200
+
 llvm-toolchain-9 (1:9.0.1-16) unstable; urgency=medium
 
   [ Adrian Bunk ]
diff -Nru llvm-toolchain-9-9.0.1/debian/control 
llvm-toolchain-9-9.0.1/debian/control
--- llvm-toolchain-9-9.0.1/debian/control   2021-01-08 12:48:25.0 
+0100
+++ llvm-toolchain-9-9.0.1/debian/control   2021-06-28 20:41:14.0 
+0200
@@ -34,7 +34,8 @@
  ${dep:devlibs-objc}, libclang-common-9-dev (= ${binary:Version}),
  libclang-cpp9 (= ${binary:Version}), libc6-dev, binutils
 Provides: c-compiler, objc-compiler, c++-compiler
-Recommends: llvm-9-dev, python3, libomp-9-dev
+Recommends: llvm-9-dev, python3,
+# libomp-9-dev
 Suggests: clang-9-doc
 Description: C, C++ and Objective-C compiler
  Clang project is a C, C++, Objective C and Objective C++ front-end

Bug#990412: Clone and fix in PAM too

2021-07-07 Thread Sam Hartman

control: clone -1 -2
control: retitle -2 mis-merge in patches prevents reading /lib/security
control: reassign -2 pam
control: found -2 1.4.0-1
control: severity -2 important
control: severity -1 serious

Steve said that it was not an intentional change to prevent finding pam
modules in /lib/security.  Steve also points out that /lib/security may
be used by software not in Debian.

The cloned bug will track reintroducing the feature based on Hideki's
patch.
I still believe there is a (probably RC) bug in PAM modules that don't
use multiarch paths.
In particular, if the user installs any application that edpends on PAM
and is not of the native architeture, things will break if there are
modules in /lib/security.
So, libpam-yubico and other PAM modules still need to get fixed, but we
will work to fix the regression in PAM too.


signature.asc
Description: PGP signature

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch


On 06/07/2021 01.25, Otto Kekäläinen wrote:

Thanks Andreas for testing potential changes!


So far this looks good, I see no more cases of default-mysql-server 
being held at the buster version (and thus mariadb-server-10.3 instead 
of mariadb-server-10.5 being installed).



If you file them as MRs at
https://salsa.debian.org/mariadb-team/galera-4 and
https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the
additional CI testing run on top of the for free for extra validation.


you can find a 990708 branch in both repositories


There is a mariadb-10.5 Bullseye update pending already, so this is
excellent time to put in more changes as long as they are justified
(these are).

We also plan to make a mariadb-10.3 stable update to Buster, so
putting a critical fix is also an option.


I don't think anything needs to be fixed in stable.

Some general understanding question: Would mariadb-server-10.5 work with 
galera-3, too? (with only the Depends being relaxed to 'Depends: 
galera-4 | galera-3, ...', without recompilation or similar actions)
(Bonus question: would mariadb-server-10.3/buster work with 
galera-4/bullseye with only the dependencies similarily relaxed?)

That could allow for even easier solutions.

Andreas

Bug#990412: pam: Regression - it won't search /lib/security

2021-07-07 Thread Sam Hartman

> "Steve" == Steve Langasek  writes:

Steve> For the record, I did not intentionally drop those lines,
Steve> this was a matter of a mis-merge.

Okay, if it was a miss-merge, let's see if we can fix.
I'm reasonably busy this morning but will try to prepare something later
today based on the patch Hideki proposed.
I know I'm going to phrase the changelog entry differently, but will
credit Hideki and use that patch as a starting point.

Bug#990397: fixed in version 5.15.0+dfsg-21


Control: reopen -1 5.15.0+dfsg-21

I am hereby indicating that this bug is fixed in version reopening 
5.15.0+dfsg-21, which is in experimental.


Rafael Laboissière

Bug#888831: NS_ERROR_NET_INADEQUATE_SECURITY error on armhf/arm64 at least

2021-07-07 Thread Raphael Hertzog

Control: severity -1 serious
Control: found -1 firefox-esr/78.11.0esr-1
Control: tag -1 + bullseye

Hello,

it looks like this issue resurfaced again and it happens in bullseye
right now (with firefox-esr 78.11.0esr-1 and libnss3 2:3.61-1).
If you upgrade to the version of libnss3 in unstable (2:3.67-2)
then the issue goes away.

This has been reproduced in Kali on an rpi (armhf) and on the Lenovo Yoga
C630 (arm64).

The simplest fix is thus to let nss migrate into bullseye.

Cheers,
-- 
Raphaël Hertzog

Bug#984266: fixed in version 4.0.0-3


Control: fixed -1 4.0.0-3

I am hereby indicating that this bug is fixed in version 4.0.0-3, 
which is in experimental now.


Rafael Laboissière

Bug#984265: fixed in 0.3.6-4


Control: fixed -1 0.3.6-4

I am hereby indicating that this bug is fixed in version 0.3.6-4, 
which is in experimental.


Rafael Laboissière

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

2021-07-07 Thread Javier Fernandez-Sanguino

tag 990720 confirmed fixed-upstream
thanks

Dear colleagues,

I have fixed this today in the debian installer GIT repository:

$ git commit -m "Fix error in translation (Closes: #990720)" es.po
[master 64d9fb0063] Fix error in translation (Closes: #990720)
 1 file changed, 1 insertion(+), 1 deletion(-)


Regards

Javier


On Mon, 5 Jul 2021 at 19:36, Javier Fernandez-Sanguino 
wrote:

> Dear Cyril,
>
> Thank you for forwarding me this bug (and to Federico for reporting). I'll
> take a look and fix the string. There is clearly a mistake there.
>
> Saludos,
>
> Javier
>
> El lun., 5 jul. 2021 18:42, Cyril Brulebois  escribió:
>
>> Control: reassign -1 grub-installer 1.172
>>
>> ¡Ola Federico!
>>
>> And thanks for your report.
>>
>> Federico Pinal Moreira  (2021-07-05):
>> > Dear Maintainer,
>> >
>> > Installing with debian-bullseye-DI-rc2-amd64 in spanish I got a prompt
>> "Aunque
>> > p" where I should have got something like "Instalar el cargador de
>> arranque
>> > GRUB".
>> >
>> > grub-installer.templates:28001 @ d-i/packages/po/sublevel1/es.po
>>
>> This seems to date back to the following commit:
>>
>> commit abe81e97d4ddef0dc17cc69e35d84c505064b23b
>> Author: Javier Fernández-Sanguino 
>> Date:   Sun Aug 23 17:03:03 2020 +0200
>>
>> Update translation and fix typos
>>
>> See:
>>
>> https://salsa.debian.org/installer-team/grub-installer/-/commit/9b7b5692e964b70260a7af4197cc017998291543
>>
>> Specifically:
>>
>> -msgstr "Instalando el cargador de arranque GRUB"
>> +msgstr "Aunque p"
>>
>> which happened along with unfuzzying that particular message.
>>
>> Reassigning and cc-ing accordingly. If it were me, I would simply revert
>> that single msgstr update, as the original translation doesn't seem
>> crazy to me. I'll let Javier or the translation coordinator look at it
>> first, as I'm absolutely no Spanish speaker. :)
>>
>>
>> Cheers,
>> --
>> Cyril Brulebois (k...@debian.org)
>> D-I release manager -- Release team member -- Freelance Consultant
>>
>

Bug#820848: RFS: phcpack 2.4.84 (NEW)

2021-07-07 Thread Nilesh Patra

On Wed, 7 Jul 2021 at 18:07, Torrance, Douglas 
wrote:

> >> * qepcad (NEW)
> >>   https://salsa.debian.org/science-team/qepcad
> >
> >
> > ./plot2d/ADJ2D_plot is a binary file, and I'm sure FTP masters will not
> > like it. Please repack this and compile the same during the build.
>
> It was already being re-compiled during build ("make -C plot2d" in
> d/rules), but
> I went ahead and also repacked the tarball without it.
>

Uploaded this, thanks for your work!

Nilesh

Bug#990787: patroni: Custom data-directory is ignored during bootstrap

2021-07-07 Thread Ralph Weires

Package: patroni
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I tried to use patroni with a custom data-directory for PostgreSQL, and ran 
into strange failures during bootstrap.

Note: I did try this on a Ubuntu 20.04 system, and on a different system than 
the one I'm reporting this bug from.
I could see that the problem is also present in the latest Debian package 
though, so reporting it here.

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

Sticking to the default data-directory 
(/var/lib/postgresql//) worked okay,
but trying a custom data-dir triggers the failure

   * What was the outcome of this action?

Failure messages, mixup between the intended (custom) data-dir and the default 
one which is still used in Postgres.

   * What outcome did you expect instead?

No failure.


The root-cause seems to be a bug in the pg_createcluster_patroni file of this 
package, which just ignores
the --datadir argument that patroni passes to it (namely, the DATADIR-variable 
is not being used anywhere)

Suggested diff for /usr/share/patroni/pg_createcluster_patroni
- pg_createcluster --start-conf=manual $VERSION $CLUSTER
+ pg_createcluster --start-conf=manual -d "${DATADIR}" $VERSION $CLUSTER

With that change, the custom data directory is also effectively used for a new 
cluster, which also worked in a test for me

Thanks

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

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

Versions of packages patroni depends on:
ii  lsb-base  11.1.0ubuntu2
ii  python3   3.8.2-0ubuntu2
pn  python3-cdiff 
ii  python3-click 7.0-3
pn  python3-dateutil  
pn  python3-etcd | python3-consul | python3-kazoo | python3-  
ii  python3-pkg-resources 45.2.0-1
pn  python3-prettytable   
ii  python3-psutil5.5.1-1ubuntu4
pn  python3-psycopg2  
ii  python3-six   1.14.0-2
pn  python3-tzlocal   
ii  python3-urllib3   1.25.8-2ubuntu0.1
ii  python3-yaml  5.3.1-1ubuntu0.1

Versions of packages patroni recommends:
ii  iproute2  5.5.0-1ubuntu1

Versions of packages patroni suggests:
pn  etcd-server | consul | zookeeperd  
pn  haproxy
pn  patroni-doc
pn  postgresql 
pn  vip-manager

Bug#984265: Bug#984266: Reopen Bug#984266, fixed in experimental


Control: reopen -1
Control: tags -1 + fixed-in-experimental

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is impacted by the bug.


Rafael Laboissière

Bug#987601: Debian Bugs information: logs for Bug#987601

2021-07-07 Thread Alexandre Rossi

Hi,

> My current policy was to Suggest: deps required by the ui components.
> This enables server users to skip those. I think I'll add default-jre
> as a Suggest: for the mean time

Moving on with the above solution.

Thanks, and sorry for the misinterpretation of bug severity values.

Alex

Bug#820848: RFS: phcpack 2.4.84 (NEW)

2021-07-07 Thread Nilesh Patra

On Wed, 7 Jul, 2021, 10:46 am Nilesh Patra,  wrote:

>
>> I'm also still looking for sponsors for a few other packages:
>>
>> * macaulay2 (new upstream version 1.18, for experimental)
>>   https://salsa.debian.org/science-team/macaulay2
>
>
> Unfortunately, I've got no resources to build it :-(
> I hope someone else uploads this. If not, just ping me after your keys are
> added to the DM keyring, and I'll grant you DM access for this
>

Update: Uploaded Macaulay2 to experimental -- took a few hours to compile

Nilesh

Bug#820848: RFS: phcpack 2.4.84 (NEW)

2021-07-07 Thread Torrance, Douglas

On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra  wrote:

Hi Doug,

On Wed, 7 Jul 2021 at 03:42, Torrance, Douglas 
wrote:

On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance 
wrote:
> I've finished packaging PHCpack, which is written in Ada and solves
polynomial systems using homotopy continuation, for Debian.  It also
includes Python and Octave interfaces.
>
> Would anyone be willing to review/sponsor?  Note that I currently have
it set for upload to unstable since it's destined for the NEW queue and I
don't think that would interfere with the freeze, but perhaps it would make
sense to upload to experimental instead?
>
> https://salsa.debian.org/science-team/phcpack

FYI, I'm still looking for a sponsor for PHCpack.  Upstream recently
released a new version (2.4.85), and I've updated the packaging in Salsa
accordingly.

./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.

Good catch!  I've sent upstream a note asking for clarification on the license
of the files in this directory.

I've also opened a merge request in the Debian Science Blend repo to add
it to the mathematics task:
https://salsa.debian.org/blends-team/science/-/merge_requests/7

I'm also still looking for sponsors for a few other packages:

* macaulay2 (new upstream version 1.18, for experimental)
  https://salsa.debian.org/science-team/macaulay2

Unfortunately, I've got no resources to build it :-(
I hope someone else uploads this. If not, just ping me after your keys are
added to the DM keyring, and I'll grant you DM access for this

I see that you've uploaded this after all -- thank you!

* macaulay2-jupyter-kernel (NEW)
  https://salsa.debian.org/science-team/macaulay2-jupyter-kernel

Uploaded!

Thank you!

* qepcad (NEW)
  https://salsa.debian.org/science-team/qepcad

./plot2d/ADJ2D_plot is a binary file, and I'm sure FTP masters will not
like it. Please repack this and compile the same during the build.

It was already being re-compiled during build ("make -C plot2d" in d/rules), but
I went ahead and also repacked the tarball without it.

Good news: my DM application was recently approved, so once the keyring is
updated, I won't need to ask for sponsorship for non-NEW packages.  :)

I'm very happy about this. Whilst I could not advocate you due to us
working on not many packages together, I was definitely cheering on the
sidelines all this while.
I hope you apply for being a DD someday, and by that time I've sponsored
enough packages for you.

Thanks again!
Doug

signature.asc
Description: PGP signature

Bug#990786: fonts-alegreya-sans: The "small caps" variant seems to be missing.

2021-07-07 Thread olaf . wolff

Package: fonts-alegreya-sans
Version: 2.008-1
Severity: normal

Dear Maintainer,

please be so kind and check the fonts "Alegreya Sans SC".

Thank you in advance!

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (99, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

-- no debconf information

Bug#990785: unblock: linuxptp/3.1-2.1

2021-07-07 Thread Salvatore Bonaccorso

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org

Hi release team,

Please unblock package linuxptp (and age it so it can make the
bullseye release)

[ Reason ]
linuxptp was affected by two CVEs recently unembargoed, CVE-2021-3570
and CVE-2021-3571.

[ Impact ]
They would remain unfixed otherwise until either the first bullseye
point release or a DSA  for it. The issues can lead potentially to
remote code execution (for an attacker with access to the network).

[ Tests ]
None specifically to the vunerability, upstream has carefully applied
the patches to several of their upstream versions and provided
patches, their CI passed on all of them were patches were provided.
See: https://www.openwall.com/lists/oss-security/2021/07/06/1

[ Risks ]
would consider it low, upstrea has a CI and covered their branches.
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
None.

unblock linuxptp/3.1-2.1

Regards,
Salvatore
diff -Nru linuxptp-3.1/debian/changelog linuxptp-3.1/debian/changelog
--- linuxptp-3.1/debian/changelog   2020-12-13 23:33:39.0 +0100
+++ linuxptp-3.1/debian/changelog   2021-07-06 20:16:00.0 +0200
@@ -1,3 +1,13 @@
+linuxptp (3.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Validate the messageLength field of incoming messages (CVE-2021-3570)
+(Closes: #990748)
+  * tc: Fix length of follow-up message of one-step sync (CVE-2021-3571)
+(Closes: #990749)
+
+ -- Salvatore Bonaccorso   Tue, 06 Jul 2021 20:16:00 +0200
+
 linuxptp (3.1-2) unstable; urgency=medium
 
   [ Punit Agrawal ]
diff -Nru 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
--- 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
  1970-01-01 01:00:00.0 +0100
+++ 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
  2021-07-06 20:16:00.0 +0200
@@ -0,0 +1,96 @@
+From: Richard Cochran 
+Date: Sat, 17 Apr 2021 15:15:18 -0700
+Subject: Validate the messageLength field of incoming messages.
+Origin: 
https://github.com/richardcochran/linuxptp/commit/ce15e4de5926724557e8642ec762a210632f15ca
+Bug-Debian: https://bugs.debian.org/990748
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3570
+
+The PTP messageLength field is redundant because the length of a PTP
+message is precisely determined by the message type and the appended
+TLVs.  The current implementation validates the sizes of both the main
+message (according to the fixed header length and fixed length by
+type) and the TLVs (by using the 'L' of the TLV).
+
+However, when forwarding a message, the messageLength field is used.
+If a message arrives with a messageLength field larger than the actual
+message size, the code will read and possibly write data beyond the
+allocated buffer.
+
+Fix the issue by validating the field on ingress.  This prevents
+reading and sending data past the message buffer when forwarding a
+management message or other messages when operating as a transparent
+clock, and it also prevents a memory corruption in msg_post_recv()
+after forwarding a management message.
+
+Reported-by: Miroslav Lichvar 
+Signed-off-by: Richard Cochran 
+---
+ msg.c | 18 --
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/msg.c b/msg.c
+index d1619d4973f1..5ae8ebbfc3ae 100644
+--- a/msg.c
 b/msg.c
+@@ -186,7 +186,7 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+ {
+   uint8_t *ptr = msg_suffix(msg);
+   struct tlv_extra *extra;
+-  int err;
++  int err, suffix_len = 0;
+ 
+   if (!ptr)
+   return 0;
+@@ -204,12 +204,14 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+   tlv_extra_recycle(extra);
+   return -EBADMSG;
+   }
++  suffix_len += sizeof(struct TLV);
+   len -= sizeof(struct TLV);
+   ptr += sizeof(struct TLV);
+   if (extra->tlv->length > len) {
+   tlv_extra_recycle(extra);
+   return -EBADMSG;
+   }
++  suffix_len += extra->tlv->length;
+   len -= extra->tlv->length;
+   ptr += extra->tlv->length;
+   err = tlv_post_recv(extra);
+@@ -219,7 +221,7 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+   }
+   msg_tlv_attach(msg, extra);
+   }
+-  return 0;
++  return suffix_len;
+ }
+ 
+

Bug#990784: universal-ctags: FTBFS with glibc 2.33

2021-07-07 Thread Athos Ribeiro

Package: universal-ctags
Version: 0+git20200824-1.1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

The current universal-ctags version fails to build against glibc 2.33,
as shown in
https://launchpad.net/ubuntu/+source/universal-ctags/0+git20200824-1.1/+build/21478505
This issue was fixed upstream in 
https://github.com/universal-ctags/ctags/pull/2990

While glibc 2.33 is not yet available in Debian, I thought it would be
nive to report this in here, in case glibc 2.33 lands in unstable before
this package gets updated to the latest upstream version (which carries
the mentioned fix).

In Ubuntu, the attached patch was submitted in
https://bugs.launchpad.net/ubuntu/+source/universal-ctags/+bug/1934829,
which is a backport of the upstream fix.

Once again, note that this patch is not needed in Debian at the moment.

  * Add newfstatat seccomp rule for glibc 2.33 builds
- d/p/series: apply new patch
  0001-main-add-newfstatat-to-seccomp-rules.patch


Best Regards,

Athos
diff -Nru 
universal-ctags-0+git20200824/debian/patches/0001-main-add-newfstatat-to-seccomp-rules.patch
 
universal-ctags-0+git20200824/debian/patches/0001-main-add-newfstatat-to-seccomp-rules.patch
--- 
universal-ctags-0+git20200824/debian/patches/0001-main-add-newfstatat-to-seccomp-rules.patch
1969-12-31 21:00:00.0 -0300
+++ 
universal-ctags-0+git20200824/debian/patches/0001-main-add-newfstatat-to-seccomp-rules.patch
2021-07-06 16:48:58.0 -0300
@@ -0,0 +1,34 @@
+From f827e85fdee9bc438d3d28612c99478f9957e612 Mon Sep 17 00:00:00 2001
+From: Masatake YAMATO 
+Date: Sun, 2 May 2021 02:18:35 +0900
+Subject: [PATCH] main: add newfstatat to seccomp rules
+
+Close #2894.
+
+Signed-off-by: Masatake YAMATO 
+
+Origin: backport, 
https://github.com/universal-ctags/ctags/commit/f827e85fdee9bc438d3d28612c99478f9957e612
+Bug: https://github.com/universal-ctags/ctags/issues/2894
+Last-Update: 2021-07-05
+
+---
+ main/seccomp.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/main/seccomp.c b/main/seccomp.c
+index 12e60982..27e704ea 100644
+--- a/main/seccomp.c
 b/main/seccomp.c
+@@ -43,6 +43,9 @@ int installSyscallFilter (void)
+   // The bowels of stdio want to know the size of a file, even for stdout.
+   seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS (fstat), 0);
+   seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS (fstat64), 0);
++#ifdef __SNR_newfstatat
++  seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS (newfstatat), 0);
++#endif
+ 
+   // seems unnecessary, but this comes from
+   // main/parse.c:2764 : tagFilePosition ();
+-- 
+2.25.1
+
diff -Nru universal-ctags-0+git20200824/debian/patches/series 
universal-ctags-0+git20200824/debian/patches/series
--- universal-ctags-0+git20200824/debian/patches/series 1969-12-31 
21:00:00.0 -0300
+++ universal-ctags-0+git20200824/debian/patches/series 2021-07-06 
16:48:13.0 -0300
@@ -0,0 +1 @@
+0001-main-add-newfstatat-to-seccomp-rules.patch

Bug#990754: unblock: wpewebkit/2.32.1-1

On Wed, Jul 07, 2021 at 11:53:16AM +0200, Moritz Muehlenhoff wrote:
> > What's the security team's take on this? Will browsers other than
> > firefox, chromium and webkit2gtk itself be security supported
> > throughout bullseye's lifetime?
> 
> We synced up with this before; wpewebkit is closely related to
> webkit and Alberto will keep both updated in stable.

As I said wpewebkit and webkit2gtk releases are made almost in
parallel, the numbering scheme, etc., is almost identical and they
have joint security advisories[1]. A longer term upstream goal would
be to merge both projects and make the GTK API a layer on top of
wpewebkit, but this is not currently on the roadmap.

At the moment doing an additional security release for wpewebkit is
going to be little more than adapting the webkit2gtk advisory.

> > The concern also extends to web rendering engines not explicitly
> > mentioned here, with the exception of  > role="source">webkit2gtk.
> 
> Good point wrt the releases notes part. I guess we should simply
> make this "with the exception of webkit2gtk/wpewebkit". Alberto,
> could you file a bug against the release notes?

Yes, but thinking about it there is something new in bullseye and I
would like to discuss it because it affects webkit2gtk as well.

The WPE WebKit project has a couple of additional libraries
called libwpe and wpebackend-fdo. They are used by wpewebkit and,
since a couple of years ago, also by webkit2gtk to implement
hardware-accelerated rendering under Wayland. In the case of
webkit2gtk this dependency is optional but recommended.

The buster builds of webkit2gtk are made with all wpe libraries
disabled because those packages were never available in buster in the
first place. In bullseye they are enabled so any security update for
bullseye would need to have them enabled as well.

Both libwpe and wpebackend-fdo are projects with little activity
and generally few and small changes. I don't expect that building
the latest version of webkit2gtk or wpewebkit for a security update
requires updating any of those libraries, but I think it can
theoretically happen. Is there a way to handle that in Debian?

Berto

[1] https://lists.webkit.org/pipermail/webkit-gtk/2021-March/003689.html

Bug#990783: espeakup: Russian in debian-installer seems incomprehensible

2021-07-07 Thread Philip Hands

Package: espeakup
Version: 1:0.80-20
Severity: normal

Hi,

I'm not sure if this is an issue with espeakup or perhaps espeak-ng-data-udeb
(which is at version 1.50+dfsg-7) -- please reassign as you see fit.

When installing Debian with debian-installer (using daily d-i images) in Speech 
Synthisis
mode, if one selects Russian the resulting audio seems garbled.

There is a recording here:

  https://openqa.debian.net/tests/11385#step/locale/3

I'm not a Russian speaker myself, but having asked someone who is to listen to
this they report that they are unable to understand the audio even when the text
that is supposedly being read is in front of them.

Cheers, Phil.

Bug#990782: inkscape: /usr/share/inkscape/fonts does not exist

2021-07-07 Thread Hendrik Tews

Package: inkscape
Version: 1.0.2-4
Severity: normal
X-Debbugs-Cc: none, Hendrik Tews 

Dear Maintainer,

each time I start inkscape, it complains

   ** (org.inkscape.Inkscape:44746): WARNING **: 11:29:57.779: Fonts dir 
'/usr/share/inkscape/fonts' does not exist and will be ignored.

   ** (org.inkscape.Inkscape:44746): WARNING **: 11:29:57.779: Fonts dir 
'/home/tews/.config/inkscape/fonts' does not exist and will be ignored.

It is possible to get rid of these warnings by just creating
these directories. But if inkscape expects these directories, the
package or inkscape should create them, shouldn't they?

Thanks,

Hendrik


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.0-3
ii  libc6  2.31-12
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libdbus-glib-1-2   0.110-6
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgc1 1:8.0.4-3
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libgdl-3-5 3.34.0-1
ii  libglib2.0-0   2.66.8-1
ii  libglibmm-2.4-1v5  2.64.2-2
ii  libgomp1   10.2.1-6
ii  libgsl25   2.6+dfsg-2
ii  libgtk-3-0 3.24.24-4
ii  libgtkmm-3.0-1v5   3.24.2-2
ii  libgtkspell3-3-0   3.0.10-1
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.0.6-4
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpangoft2-1.0-0  1.46.2-3
ii  libpangomm-1.4-1v5 2.42.1-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler102  20.09.0-3.1
ii  libpotrace01.16-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.50.3+dfsg-1
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.72.0-2
ii  libstdc++6 10.2.1-6
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.1-1
ii  libxml22.9.10+dfsg-6.7
ii  libxslt1.1 1.1.34-4
ii  python33.9.2-3
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-2
ii  fig2dev  1:3.2.8-3+b1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.8.4-17
ii  python3-lxml 4.6.3-1
ii  python3-numpy1:1.19.5-1
ii  python3-scour0.38.2-1

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  libxml-xql-perl   
pn  pstoedit  
pn  python3-uniconvertor  
ii  ruby  1:2.7+2

-- no debconf information

Bug#935395: RFP: python3-anytree -- Tree data library

2021-07-07 Thread Diego M. Rodriguez

Hello Simon,

On Thu, 22 Aug 2019 10:32:26 +0100 Simon McVittie  wrote:
> For now I've replaced its use in gtk-doc-tools with a simple
> reimplementation (it's a tree data structure, it isn't rocket science),
> but in the long term either someone should package anytree, or someone
> needs to ask the upstream maintainer of gtk-doc to use a different tree
> implementation instead of depending on anytree (in which case this bug
> can be closed as wontfix).

I think you managed to solve it via the second approach [1], and thus
the bug can be indeed be closed?

For context, I'm doing a round for trying to work on some RFP packages,
and currently attempting to identify the ones with the higher chance of
helping improve existing packages.

[1] https://gitlab.gnome.org/GNOME/gtk-doc/-/merge_requests/56
-- 
Diego M. Rodriguez

Bug#990754: unblock: wpewebkit/2.32.1-1

2021-07-07 Thread Moritz Muehlenhoff

On Tue, Jul 06, 2021 at 10:11:36PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> On 2021-07-06 11:20:10 +0200, Alberto Garcia wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Please unblock package wpewebkit
> > 
> > webkit2gtk was unblocked last month, testing has the most recent
> > stable version and we will provide security updates during the
> > lifetime of bullseye, as we already did during buster.
> > 
> > wpewebkit is another official port of webkit. It's maintained by the
> > same team, follows a very similar release schedule and numbering
> > system, shares most of the code and almost all CVEs fixes apply to
> > both ports.
> > 
> > Because of this it won't take me too much effort to prepare security
> > updates for wpewebkit so the Debian security team is proposing that we
> > also provide them.
> > 
> > If we do this we should unblock the package and put the latest stable
> > version in testing. At the moment the only user of wpewebkit in Debian
> > is cog, which is a simple, single-window web browser, developed and
> > released by the same team. So we should also unblock cog and the two
> > other libraries that are part of the wpewebkit releases: libwpe and
> > wpebackend-fdo (I don't know if you need separate bugs to unblock
> > those).
> > 
> > If we don't do this then it's probably a good idea to mention in the
> > release notes that wpewebkit is not covered by security updates.
> 
> What's the security team's take on this? Will browsers other than firefox,
> chromium and webkit2gtk itself be security supported throughout bullseye's
> lifetime?

We synced up with this before; wpewebkit is closely related to webkit and
Alberto will keep both updated in stable.

> The concern also extends to web rendering engines not explicitly
> mentioned here, with the exception of  role="source">webkit2gtk.

Good point wrt the releases notes part. I guess we should simply
make this "with the exception of webkit2gtk/wpewebkit". Alberto, could
you file a bug against the release notes?

Cheers,
Moritz

Bug#990781: localechooser: mojibake at 'Select a Language' question when in speech mode

2021-07-07 Thread Philip Hands

Package: localechooser
Version: 2.92
Severity: minor

When doing a speech install, the menu of available languages does not manage to
render the own-language versions of some languages, where those languages 
require
another font:

  https://openqa.debian.net/tests/11328#step/locale/1

(where one can see that for quite a few languages one just gets solid-white
little squares in place of the e.g. Cyrillic characters ... and for any other
non-Latin character sets)

I've tagged that as minor because the target audience for the speech install are
less bothered by what is on-screen than how it is rendered into audio.

For example, if one selects Punjabi the next screen is almost completely
mojibake, but it does seem (to a non-Punjabi speaker) to be doing a reasonable
job of reading what would be there if the font was available, which is the main
thing.

Russian, not so much -- the font works but the voice is nonsense -- I'll report
a separate bug about that when I have a recorded sample to point at.

Cheers, Phil.

Bug#989644: iwd: After upgrading to 1.14-3, can no longer connect to access point

2021-07-07 Thread Jonas Smedegaard

Quoting Alejandro Valenzuela (2021-07-07 10:23:12)
> Hello Jonas and Timur,
> 
> I can confirm the issue still exists in 1.15-1 and will report the bug
> upstream as requested
> 
> Thanks for the message and sorry for replying so late!
> /Alejandro

Thanks!

(also: no need for apology)


 - Jonas

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

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

signature.asc
Description: signature

Bug#990215: tmux: Missleading error message if socket path has wrong permissions

2021-07-07 Thread Uwe Kleine-König

Control: tag -1 + fixed-upstream

Hello Romain,

On Thu, Jun 24, 2021 at 08:49:53PM +0200, Romain Francoise wrote:
> On Wed, Jun 23, 2021 at 8:57 AM Uwe Kleine-König  wrote:
> > To improve this, the following patch helps: [...]
> 
> Thanks for the bug report and the patch. Can you contribute this
> directly upstream? It's always a bit awkward for me to try and get
> someone else's patch merged...

I reworked the patch a bit and upstream committed something similar in
commit 32f2d9d089ce ("Improve error reporting when the tmux /tmp
directory cannot be created or used, GitHub issue 2765 from Uwe
Kleine-Koenig.")

So I'm marking as fixed-upstream.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#989644: iwd: After upgrading to 1.14-3, can no longer connect to access point

2021-07-07 Thread Alejandro Valenzuela

Hello Jonas and Timur,

I can confirm the issue still exists in 1.15-1 and will report the bug
upstream as requested

Thanks for the message and sorry for replying so late!
/Alejandro

On Sun, 20 Jun 2021 at 09:12, Jonas Smedegaard  wrote:

> control: tag -1 +upstream
>
> Hi Alejandro and Timur,
>
> Thanksd for your bug reporting.
>
> IWD has seen only upstream changes since release 1.9 (packaging changes
> since then has only affected metadata and testsuite).
>
> I have now released 1.15-1 to experimental.  Upstream changes between
> 1.14 and 1.15 mentions no bugfixes, only feature improvements, but
> perhaps some of that anyway improves behavior on your MacBooks.
>
> Please tell if 1.15-1 works for you or not.  And if it doesn't then also
> please consider reporting the issue upstream.  Better if you report it
> yourself, since you have the hardware needed to test things so I expect
> that me acting as proxy would only slow down the process for no benefit.
>
> Upstream contact info is here (at the bottom):
> https://iwd.wiki.kernel.org/
>
> If you do report the issue upstream, then please share a link to the
> upstream issue report here.
>
>
> Kind regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#987601: openjdk-11-jre-headless: libawt_xawt.so still listed as part of this package instead of openjdk-11-jre

2021-07-07 Thread Matthias Klose

Control: severity -1 serious

> Lowering severity as working around is trivial by installing openjdk-11-jre

this is not how to work-around it.  Severity of an issue is not related to how
trivial the fix is.

Bug#990780: jabref fails to start

2021-07-07 Thread Matthias Klose

Package: jabref
Version: 3.8.2+ds-14
Severity: serious
Tags: sid bullseye

$ jabref
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library:
/usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2630)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at 
java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at 
java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2648)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
at java.base/java.lang.System.loadLibrary(System.java:1873)
at java.desktop/java.awt.Toolkit$3.run(Toolkit.java:1399)
at java.desktop/java.awt.Toolkit$3.run(Toolkit.java:1397)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1396)
at java.desktop/java.awt.Toolkit.(Toolkit.java:1429)
at java.desktop/java.awt.EventQueue.invokeLater(EventQueue.java:1312)
at 
java.desktop/javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1421)
at net.sf.jabref.JabRefMain.main(JabRefMain.java:40)

There are at least two issues here:

 - a script (jabref) is provided without depending on the
   corresponding interpreter packages

 - even if the interpreter is installed in the headless
   form, it's not good enough, as jabref is an UI application.

Maybe the least invasive fix is to just add a dependency on default-jre, however
if some of the jabref libraries can be used without any UI, then maybe better
split out a libjabref-java package, and let jabref depend on it.

Bug#990748: linuxptp: diff for NMU version 3.1-2.1

2021-07-07 Thread Salvatore Bonaccorso

Dear maintainer,

I've prepared an NMU for linuxptp (versioned as 3.1-2.1). The diff
is attached to this message. Given the time for the bullseye release I
went ahead without delay, hope this was fine with you.

Regards,
Salvatore
diff -Nru linuxptp-3.1/debian/changelog linuxptp-3.1/debian/changelog
--- linuxptp-3.1/debian/changelog	2020-12-13 23:33:39.0 +0100
+++ linuxptp-3.1/debian/changelog	2021-07-06 20:16:00.0 +0200
@@ -1,3 +1,13 @@
+linuxptp (3.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Validate the messageLength field of incoming messages (CVE-2021-3570)
+(Closes: #990748)
+  * tc: Fix length of follow-up message of one-step sync (CVE-2021-3571)
+(Closes: #990749)
+
+ -- Salvatore Bonaccorso   Tue, 06 Jul 2021 20:16:00 +0200
+
 linuxptp (3.1-2) unstable; urgency=medium
 
   [ Punit Agrawal ]
diff -Nru linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
--- linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch	1970-01-01 01:00:00.0 +0100
+++ linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch	2021-07-06 20:16:00.0 +0200
@@ -0,0 +1,96 @@
+From: Richard Cochran 
+Date: Sat, 17 Apr 2021 15:15:18 -0700
+Subject: Validate the messageLength field of incoming messages.
+Origin: https://github.com/richardcochran/linuxptp/commit/ce15e4de5926724557e8642ec762a210632f15ca
+Bug-Debian: https://bugs.debian.org/990748
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3570
+
+The PTP messageLength field is redundant because the length of a PTP
+message is precisely determined by the message type and the appended
+TLVs.  The current implementation validates the sizes of both the main
+message (according to the fixed header length and fixed length by
+type) and the TLVs (by using the 'L' of the TLV).
+
+However, when forwarding a message, the messageLength field is used.
+If a message arrives with a messageLength field larger than the actual
+message size, the code will read and possibly write data beyond the
+allocated buffer.
+
+Fix the issue by validating the field on ingress.  This prevents
+reading and sending data past the message buffer when forwarding a
+management message or other messages when operating as a transparent
+clock, and it also prevents a memory corruption in msg_post_recv()
+after forwarding a management message.
+
+Reported-by: Miroslav Lichvar 
+Signed-off-by: Richard Cochran 
+---
+ msg.c | 18 --
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/msg.c b/msg.c
+index d1619d4973f1..5ae8ebbfc3ae 100644
+--- a/msg.c
 b/msg.c
+@@ -186,7 +186,7 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ {
+ 	uint8_t *ptr = msg_suffix(msg);
+ 	struct tlv_extra *extra;
+-	int err;
++	int err, suffix_len = 0;
+ 
+ 	if (!ptr)
+ 		return 0;
+@@ -204,12 +204,14 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ 			tlv_extra_recycle(extra);
+ 			return -EBADMSG;
+ 		}
++		suffix_len += sizeof(struct TLV);
+ 		len -= sizeof(struct TLV);
+ 		ptr += sizeof(struct TLV);
+ 		if (extra->tlv->length > len) {
+ 			tlv_extra_recycle(extra);
+ 			return -EBADMSG;
+ 		}
++		suffix_len += extra->tlv->length;
+ 		len -= extra->tlv->length;
+ 		ptr += extra->tlv->length;
+ 		err = tlv_post_recv(extra);
+@@ -219,7 +221,7 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ 		}
+ 		msg_tlv_attach(msg, extra);
+ 	}
+-	return 0;
++	return suffix_len;
+ }
+ 
+ static void suffix_pre_send(struct ptp_message *msg)
+@@ -337,7 +339,7 @@ void msg_get(struct ptp_message *m)
+ 
+ int msg_post_recv(struct ptp_message *m, int cnt)
+ {
+-	int pdulen, type, err;
++	int err, pdulen, suffix_len, type;
+ 
+ 	if (cnt < sizeof(struct ptp_header))
+ 		return -EBADMSG;
+@@ -422,9 +424,13 @@ int msg_post_recv(struct ptp_message *m, int cnt)
+ 		break;
+ 	}
+ 
+-	err = suffix_post_recv(m, cnt - pdulen);
+-	if (err)
+-		return err;
++	suffix_len = suffix_post_recv(m, cnt - pdulen);
++	if (suffix_len < 0) {
++		return suffix_len;
++	}
++	if (pdulen + suffix_len != m->header.messageLength) {
++		return -EBADMSG;
++	}
+ 
+ 	return 0;
+ }
+-- 
+2.32.0
+
diff -Nru linuxptp-3.1/debian/patches/series linuxptp-3.1/debian/patches/series
--- linuxptp-3.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ linuxptp-3.1/debian/patches/series	2021-07-06 20:16:00.0 +0200
@@ -0,0 +1,2 @@
+Validate-the-messageLength-field-of-incoming-message.patch
+tc-Fix-length-of-follow-up-message-of-one-step-sync.patch
diff -Nru linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch
--- linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch	1970-01-01

Bug#990777: mirror listing update for debianmirror.nkn.in

2021-07-07 Thread S.Gopinath

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debianmirror.nkn.in
Type: leaf
Archive-architecture: amd64 arm64 armhf
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: S.Gopinath 
Country: IN India
Location: Chennai
Sponsor: National Knowledge Network https://www.nkn.in
Comment: Due to some constraints, the site was working for sometime. The site 
was re-established and may add the same.
 
 Ipv6 is still an issue at this moment




Trace Url: http://debianmirror.nkn.in/debian/project/trace/
Trace Url: http://debianmirror.nkn.in/debian/project/trace/ftp-master.debian.org
Trace Url: http://debianmirror.nkn.in/debian/project/trace/debianmirror.nkn.in

Bug#990779: kpartx returns exit code 0 on failure(s)

2021-07-07 Thread Stefan Schwarzer

Package: kpartx
Version: 0.8.5-2
Severity: minor

Dear Maintainer,

While testing a script, I stumbled over a case where kpartx -av (expectedly) 
failed to
setup loop devices for a standard text file.
The script failed later because the exit code of the command was 0
(echo $? directly after execution of kpartx -av ), which I expected 
to signal
success.

So, it would be great if kpartx one day would return exit codes > 0 on failures 
in line with
other utilities, as this avoids inventing heuristics to parse the output to 
achieve
failure/success detection.




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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kpartx depends on:
ii  dmsetup 2:1.02.175-2.1
ii  libc6   2.31-12
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  udev247.3-5

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

Bug#984266: Reopen Bug#984266, fixed in experimental