Bug#944402: ITP: golang-github-toqueteos-webbrowser -- Convenient Web-browser controller library for Go

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-toqueteos-webbrowser
  Version : 1.2.0+git20190725.dc97d39-1
  Upstream Author : Carlos Cobo
* URL : https://github.com/toqueteos/webbrowser
* License : Expat
  Programming Lang: Go
  Description : Convenient Web-browser controller library for Go

 This Go library provides a simple API for opening web pages on your default
 browser. This is inspired on Python's webbrowser library.

Bug#937648: python-click: Python2 removal in sid/bullseye

[peter green]

severity 937648 serious
thanks

python-click depends on the python-colorama binary package, which is no longer 
built by the python-colorama source package.

Bug#944401: pgcli: does not start due to unmet psycopg2 requirement

[Paul]

Package: pgcli
Version: 1.9.1-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When starting /usr/bin/pgcli the script terminates with a Version
conflict error.
It seems like the packaged python3-psycopg2 version is too recent for
the packaged pgcli release.

$ pgcli
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 791, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (psycopg2 2.8.3 
(/usr/lib/python3/dist-packages), Requirement.parse('psycopg2<2.8,>=2.7.4'), 
{'pgcli'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pgcli", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3250, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3234, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3263, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 585, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 598, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'psycopg2<2.8,>=2.7.4' distribution was 
not found and is required by pgcli


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

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

Versions of packages pgcli depends on:
ii  python3 3.7.5-1
ii  python3-click   7.0-2
ii  python3-configobj   5.0.6-3
ii  python3-humanize0.5.1-3
ii  python3-pgspecial   1.9.0-2
ii  python3-prompt-toolkit  1.0.15-1
ii  python3-psycopg22.8.3-2
ii  python3-pygments2.3.1+dfsg-1
ii  python3-setproctitle1.1.10-1+b2
ii  python3-sqlparse0.2.4-1
ii  python3-tabulate0.8.2-1.1
ii  python3-terminaltables  3.1.0-2

pgcli recommends no packages.

pgcli suggests no packages.

-- no debconf information

Bug#944400: sphinx: autopkgtest fails with texlive (2019.20191030-1)

[Bas Couwenberg]

Source: sphinx
Version: 1.8.5-3
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest of your package fail with texlive (2019.20191030-1):

 https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinx/3363555/log.gz

This is blocking testing migration of various packages.

Kind Regards,

Bas

Bug#944399: ccache: Building aosp-10 bionic leads to ld.lld: error: undefined symbol: strcpy_a9

[Stefan Rücker]

Package: ccache
Version: 3.7.5-1
Severity: important

Have a look here, that is where I reported the problem first:
https://github.com/sonyxperiadev/bug_tracker/issues/492

I can provide you files or infos from the failing build if you need those, the
problem is reproducible.

The error message from the build is:

[ 66% 72657/109596] //bionic/libc:libc link libc.so [arm]
FAILED:
out/soong/.intermediates/bionic/libc/libc/android_arm_armv8-a_cortex-a73_core_shared_com.android.runtime.debug/unstripped/libc.so
prebuilts/clang/host/linux-x86/clang-r353983c/bin/clang++
@out/soong/.intermediates/bionic/libc/libc/android_arm_armv8-a_cortex-a73_core_shared_com.android.runtime.debug/unstripped/libc.so.rsp
-Wl,--whole-archive
out/soong/.intermediates/external/jemalloc_new/libjemalloc5/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libjemalloc5.a
out/soong/.intermediates/bionic/libc/libc_init_dynamic/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libc_init_dynamic.a
out/soong/.intermediates/bionic/libc/libc_common_shared/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libc_common_shared.a
-Wl,--no-whole-archive
out/soong/.intermediates/bionic/libdl/libdl_android/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libdl_android.a
prebuilts/clang/host/linux-x86/clang-r353983c/lib64/clang/9.0.3/lib/linux/libclang_rt.builtins-
arm-android.a prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/arm-linux-
androideabi/lib/libatomic.a
out/soong/.intermediates/build/soong/libgcc_stripped/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libgcc_stripped.a
out/soong/.intermediates/bionic/linker/ld-
android/android_arm_armv8-a_cortex-a73_core_shared_com.android.runtime.debug/ld-
android.so
out/soong/.intermediates/bionic/libdl/libdl/android_arm_armv8-a_cortex-a73_core_shared_com.android.runtime.debug/libdl.so
-o
out/soong/.intermediates/bionic/libc/libc/android_arm_armv8-a_cortex-a73_core_shared_com.android.runtime.debug/unstripped/libc.so
-nostdlib -Wl,--gc-sections -shared -Wl,-soname,libc.so -target armv7a-linux-
androideabi -Bprebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/arm-linux-
androideabi/bin -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
-Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined-version -Wl,
--exclude-libs,libgcc.a -Wl,--exclude-libs,libgcc_stripped.a -fuse-ld=lld -Wl,
--pack-dyn-relocs=none -Wl,--no-undefined -Wl,--icf=safe -Wl,--hash-style=gnu
-Wl,-m,armelf -Wl,-z,muldefs -Wl,--hash-style=both  -Wl,--version-
script,out/soong/.intermediates/bionic/libc/libc.arm.map/gen/libc.arm.map -Wl,
--symbol-ordering-file,bionic/libc/symbol_ordering
ld.lld: error: undefined symbol: strcpy_a9
>>> referenced by dynamic_function_dispatch.cpp:0 (bionic/libc/arch-
arm/dynamic_function_dispatch.cpp:0)
>>>   dynamic_function_dispatch.o:(strcpy) in archive
out/soong/.intermediates/bionic/libc/libc_common_shared/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libc_common_shared.a

ld.lld: error: undefined symbol: stpcpy_a9
>>> referenced by dynamic_function_dispatch.cpp:0 (bionic/libc/arch-
arm/dynamic_function_dispatch.cpp:0)
>>>   dynamic_function_dispatch.o:(stpcpy) in archive
out/soong/.intermediates/bionic/libc/libc_common_shared/android_arm_armv8-a_cortex-a73_core_static_com.android.runtime.debug/libc_common_shared.a
clang-9: error: linker command failed with exit code 1 (use -v to see
invocation)
06:59:15 ninja failed with: exit status 1

To use ccache along with the android build it is required to do following
exports:

export USE_CCACHE=1
export CCACHE_EXEC=/usr/bin/ccache

It used to work without problems using ccache 3.7.4-1, last successful build
was 2019-10-28/2019-10-29 after that ccache 3.7.5-1 was migrated to testing and
with that version the problem seems to have been introduced.



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

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

Versions of packages ccache depends on:
ii  libc6   2.29-2
ii  zlib1g  1:1.2.11.dfsg-1+b1

ccache recommends no packages.

Versions of packages ccache suggests:
pn  distcc | icecc  

-- no debconf information

Bug#944238: buster-pu: package debian-edu-config/2.10.65+deb10u2

[Holger Levsen]

On Fri, Nov 08, 2019 at 10:10:54PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
[...]
> Please go ahead.
 
thanks, uploaded.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#944398: ITP: node-timezone

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-timezone
  Version : 1.0.22
  Upstream Author : Alan Gutierrez 
* URL : http://bigeasy.github.io/timezone
* License : Expat
  Programming Lang: JavaScript
  Description : Timezone database and functions for node.js

  Small, elegant, Olson educated, timezone aware date math and
  `strftime` date formatting in pure JavaScript with no dependendcies
  for Node.js and the browser. Timezone uses the Olson/IANA timezone
  database. Timezone is aware of every clock transition in the Olson
  database. Timezones supports the full compilment of `strftime` format
  specifiers defined by GNU `date`. Timezone can perform date math and
  adjust for daylight savings time. Timezone works in the browser too
  where it is less than 3K minified and gzipped

I'd like to submit it to the pkg-js-team or at least get a few comments
as I don't have much experience with javascript packaging.

Current progress is in:
https://salsa.debian.org/diane/node-timezone

Lintian is currently reporting a few errors where files are in
usr/lib/nodejs instead of usr/share/nodejs.

Diane Trout


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

Bug#919170: [Piuparts-devel] Bug#919170: Please update dependency to python3-debianbts

[Holger Levsen]

On Fri, Nov 08, 2019 at 11:34:41PM -0500, Sandro Tosi wrote:
> Holger, you mentioned you need help testing the py3k-ported piuparts:
> could you please detail for me, who is extremely inexperienced with
> piuparts, what kind of tests you're looking for?

test piuparts master-slave mode in buster, this works, also on localhost and
just needs the piuparts-(master|slave) packages packages installed in eg
a chroot. then switch to sid, build the packages from the piuparts.git
develop branch and do the test again. this currently fails...

I think its enought to call the slave and let it ask the master for new
packages to be tested. At least that was what failed when I last tried
this with the develop branch.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#944397: libldm FTBFS: error: G_ADD_PRIVATE [-Werror]

[Helmut Grohne]

Source: libldm
Version: 0.2.4-2
Severity: serious
Tags: ftbfs

libldm fails to build from source in unstable.

Here is the excerpt from reproducible builds amd64/pbuilder:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libldm_0.2.4-2.rbuild.log.gz
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Werror -Wshadow -Wextra -Wno-unused-local-typedefs 
-Wno-unused-parameter -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -g -O2 
-ffile-prefix-map=/build/1st/libldm-0.2.4=. -fstack-protector-strong -Wformat 
-Werror=format-security -c ldm.c  -fPIC -DPIC -o .libs/libldm_1_0_la-ldm.o
| ldm.c: In function 'ldm_init':
| ldm.c:293:13: error: G_ADD_PRIVATE [-Werror]
|   293 | o->priv = LDM_GET_PRIVATE(o);
|   | ^~~
| ldm.c: In function 'ldm_disk_group_init':
| ldm.c:430:13: error: G_ADD_PRIVATE [-Werror]
|   430 | o->priv = LDM_DISK_GROUP_GET_PRIVATE(o);
|   | ^~~
| ldm.c: In function 'ldm_volume_init':
| ldm.c:674:13: error: G_ADD_PRIVATE [-Werror]
|   674 | o->priv = LDM_VOLUME_GET_PRIVATE(o);
|   | ^~~
| ldm.c: In function 'ldm_partition_init':
| ldm.c:841:13: error: G_ADD_PRIVATE [-Werror]
|   841 | o->priv = LDM_PARTITION_GET_PRIVATE(o);
|   | ^~~
| ldm.c: In function 'ldm_disk_init':
| ldm.c:1055:13: error: G_ADD_PRIVATE [-Werror]
|  1055 | o->priv = LDM_DISK_GET_PRIVATE(o);
|   | ^~~
| cc1: all warnings being treated as errors
| make[3]: *** [Makefile:581: libldm_1_0_la-ldm.lo] Error 1
| make[3]: Leaving directory '/build/1st/libldm-0.2.4/src'
| make[2]: *** [Makefile:500: all-recursive] Error 1
| make[2]: Leaving directory '/build/1st/libldm-0.2.4'
| make[1]: *** [Makefile:407: all] Error 2
| make[1]: Leaving directory '/build/1st/libldm-0.2.4'
| dh_auto_build: make -j16 returned exit code 2
| make: *** [debian/rules:13: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also observable on crossqa for arm64 using sbuild:
http://crossqa.debian.net/build/libldm_0.2.4-2_arm64_20191021161651.log

Looks like some glib interface change.

Helmut

Bug#909750:

[Matthijs van Duin]

I got the message "Unable to revert mtime: /usr/local/share/fonts"
(see also related bug 909728) upon opening a particular pdf file with
xpdf and discovered this message was emitted after it had created a
.uuid file in that directory (which was writable by me as normal user,
probably something I did in the past), so clearly libfontconfig still
writes to /usr under some circumstances. I'm using the latest
fontconfig in sid (2.13.1-2+b1).

relevant strace output:

access("/usr/local/share/fonts/.uuid", F_OK) = -1 ENOENT (No such file
or directory)
stat("/usr/local/share/fonts", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/local/share/fonts/.uuid.TMP-gyDVw4",
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 5
link("/usr/local/share/fonts/.uuid.TMP-gyDVw4",
"/usr/local/share/fonts/.uuid.LCK") = 0
unlink("/usr/local/share/fonts/.uuid.TMP-gyDVw4") = 0
unlink("/usr/local/share/fonts/.uuid.NEW") = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/local/share/fonts/.uuid.NEW",
O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 5
rename("/usr/local/share/fonts/.uuid.NEW", "/usr/local/share/fonts/.uuid") = 0
unlink("/usr/local/share/fonts/.uuid.LCK") = 0
utimes("/usr/local/share/fonts", [{tv_sec=1573279099, tv_usec=455382}
/* 2019-11-09T06:58:19.455382+0100 */, {tv_sec=1573279221,
tv_usec=252001} /* 2019-11-09T07:00:21.252001+0100 */]) = -1 EPERM
(Operation not permitted)

Bug#944396: transition: exiv2

[Steve M. Robbins]

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

New upstream, new soversion.

Ben file:

title = "exiv2";
is_affected = .depends ~ "libexiv2-14" | .depends ~ "libexiv2-27";
is_good = .depends ~ "libexiv2-27";
is_bad = .depends ~ "libexiv2-14";


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

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

Bug#919170: [Piuparts-devel] Bug#919170: Please update dependency to python3-debianbts

[Sandro Tosi]

On Sun, Nov 3, 2019 at 12:55 PM Bastian Venthur  wrote:
>
> Hi Sando and Holger,
>
> according to Holger, I can upload the new version of python-debianbts
> that removes Python2 support to unstable, since piuparts is broken in
> sid and bullseye anyways.

Holger, you mentioned you need help testing the py3k-ported piuparts:
could you please detail for me, who is extremely inexperienced with
piuparts, what kind of tests you're looking for?

> Just to verify once more before breaking stuff for real: is this OK for
> everyone?

works for me, thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#944379: brz: ERROR: [Errno 2] No such file or directory: '.config/breezy'

[Jelmer Vernooij]

On Fri, Nov 08, 2019 at 10:59:13PM +0100, Jochen Sprickerhof wrote:
> breezy doesn't always create it's config dir resulting in an exception.
> The current behaviour breaks ros-wstool since the switch from bzr to brz:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ros-wstool.html
> 
> Steps to reproduce:
> 
> $ cd $(mktemp -d)
> $ HOME=$(pwd) brz init
> Created a standalone tree (format: 2a)
> $ touch foo
> $ HOME=$(pwd) brz status
> brz: ERROR: [Errno 2] No such file or directory: 
> '/tmp/tmp.7OnfYj98A5/.config/breezy'
Thanks for the bug report; I've forwarded this to 
https://bugs.launchpad.net/brz/+bug/1851904

I suspect we didn't use os.makedirs in the past since we didn't want
to inadvertently create the users home directory if it didn't exist.

> P.S.: brz in experimental is not installable, because this is not
> fulfillable:
> 
> python3-breezy (<= 3.1.0~bzr7295-1.1~)
> python3-breezy (>= 3.1.0~bzr7295-1)
> 
> $ dpkg --compare-versions "3.1.0~bzr7372-1" lt "3.1.0~bzr7295-1.1" && echo 
> true
> 
> I would propose to use 3.1.0-bzr7372 as the upstream version in future,
> as the tilde is special.

The use of the tilde is intentional; the bzr7372 bit is the
upstream version snapshot (3.1.0 is not released yet), not a part of
the Debian revision.

Jelmer



signature.asc
Description: PGP signature

Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL

[Michael Gilbert]

control: tag -1 moreinfo

On Sat, Oct 26, 2019 at 10:48 AM Witold Baryluk wrote:
> Thread 20 "Chrome_InProcGp" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffaa7fc700 (LWP 32634)]
> 0x7fff770d9c37 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
> (gdb) bt
> #0  0x7fff770d9c37 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
> #1  0x7fff76f76409 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
> #2  0x59e1d3b1 in 
> gpu::gles2::GLES2DecoderImpl::InvalidateFramebufferImpl(unsigned int, int, 
> unsigned int const volatile*, int, int, int, int, char const*, 
> gpu::gles2::GLES2DecoderImpl::FramebufferOperation) ()
> #3  0x59e2030a in 
> gpu::gles2::GLES2DecoderImpl::HandleInvalidateFramebufferImmediate(unsigned 
> int, void const volatile*) ()
> #4  0x59dfa261 in gpu::error::Error 
> gpu::gles2::GLES2DecoderImpl::DoCommandsImpl(unsigned int, void const 
> volatile*, int, int*) ()

This looks like an error in the RadeonSI driver.  Could you try
installing libgl1-mesa-dri-dbgsym to fill in the ?? in the backtrace?

Best wishes,
Mike

Bug#914704: ibus: candidate window appears at bottom

[Changwoo Ryu]

I still can't reproduce it in Cinamon desktop in a new account with
the same im-config settings. Something should be different in the
reproducing desktop.

Bug#932085: grub-common: Grub can't load initrd for Xen after upgrade to Buster

[Cameron Davidson]

I also had the same problem after upgrading from 9.9 to 10.1. (from
network repos 8 November 2019).

The symptoms were the same, on the video console, the message appeared
(not verbatim as I forgot to transcribe it)

 loading xen-4.11
 then the same old warning about no available console for the kernel
 loading linux-4.19.0-6   
 loading initrd...
 error writing to console (then nothing)

This is just as it appeared when booting Xen from EFI in Stretch, except
that the version numbers were updated.

Neither of the workarounds made any difference. There was no evidence of
HDD activity, no network interfaces were activated, no logs were generated.

Only after trying the workarounds did I noticed that the grub boot menu
screen was displaying the suspicious-looking version 2.02~beta3-5+deb9u1.

The only file in /boot/efi/EFI/debian was (I think) grubx64.efi.

I manually ran grub-install and it seems to have fixed everything.  I
have no idea why it was not run automatically at some stage during the
upgrade.

The system now boots via the file shimx64.efi. 

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Am Sa., 9. Nov. 2019 um 03:54 Uhr schrieb Scott Kitterman
:
> On November 9, 2019 1:58:50 AM UTC, Matthias Klumpp  wrote:
> >Am Fr., 8. Nov. 2019 um 23:29 Uhr schrieb Matthias Klumpp
> >:
> >> [...]
> >> Please remove the gtk-d package binaries for the armhf architecture
> >temporarily.
> >> [...]
> >
> >Speaking of which, could the armhf packages of appstream-generator and
> >glib-d also be removed? The former suffers from a different issue (but
> >one that will only be fixed in a more recent GDC version (10), as the
> >package depends on a higher D language version), and the latter has
> >the exact same issue as described here (and appstream-generator
> >depends on glib-d, so removing the armhf binaries together makes
> >sense)
>
> Please file separate bugs for those.

I kind of expected that reply ^^
Separate issues for those two packages are filed as well now.
Thanks!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944395: RM: glib-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the glib-d package binaries for the armhf architecture
temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and the
package does not migrate to testing while it's not built on armhf.
Meanwhile, all packages depending on it are broken on all
architectures until the new version migrates (due to LDC ABI issues),
so in this particular instance I think it is justified that the
package is removed on armhf temporarily, to allow it to migrate.
The armhf binaries will highly likely be reintroduces as soon as the
issue is fixed in GDC or worked around there, and glib-d built on armhf
with gdc.
RM issues were filed against appstream-generator and glib-d as well.

Thanks for considering!
Cheers,
Matthias

Bug#944394: RM: appstream-generator [armhf] -- ROM; FTBFS because it needs newer D features

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the appstream-generator package binaries for the armhf
architecture temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and
appstream-generator depends on glib-d which is affected by this issue.
Furthermore, asgen depends on D features the gdc compiler does not yet
provide (version 10 is needed for that), so the package can't be
introduced on armhf until GDC 10 is available in the archive.

Thanks for considering!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Scott Kitterman]

On November 9, 2019 1:58:50 AM UTC, Matthias Klumpp  wrote:
>Am Fr., 8. Nov. 2019 um 23:29 Uhr schrieb Matthias Klumpp
>:
>> [...]
>> Please remove the gtk-d package binaries for the armhf architecture
>temporarily.
>> [...]
>
>Speaking of which, could the armhf packages of appstream-generator and
>glib-d also be removed? The former suffers from a different issue (but
>one that will only be fixed in a more recent GDC version (10), as the
>package depends on a higher D language version), and the latter has
>the exact same issue as described here (and appstream-generator
>depends on glib-d, so removing the armhf binaries together makes
>sense)

Please file separate bugs for those.

Scott K

Bug#944393: cope with non-matching patterns when upgrading to debhelper 11+

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.38
Severity: normal

The debhelper upgrade guide says for debhelper 11:

The helpers dh_installdocs, dh_installexamples, dh_installinfo, and 
dh_installman now error out if their config has a pattern that does not match 
anything or reference a path that does not exist. 


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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-6
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.13-1
ii  python3-levenshtein  0.12.0-3+b1
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.1
ii  lintian2.34.0
ii  python3-asyncpg0.18.3-2
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  209

-- no debconf information

Bug#944392: frr: /usr/share/man/man8/vrrpd.8.gz is already shipped by vrrpd

[Andreas Beckmann]

Package: frr
Version: 7.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package frr.
  Preparing to unpack .../16-frr_7.2-1_amd64.deb ...
  Unpacking frr (7.2-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-3pfMjQ/16-frr_7.2-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man8/vrrpd.8.gz', which is also in 
package vrrpd 1.0-2+b2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-3pfMjQ/16-frr_7.2-1_amd64.deb


cheers,

Andreas


vrrpd=1.0-2+b2_frr=7.2-1.log.gz
Description: application/gzip

Bug#944391: Sieve redirect does not collect the sendmail child process correctly

[Delian Krustev]

Package: dovecot-core
Source: dovecot
Version: 1:2.3.4.1-5+deb10u1


I've submitted the following bugreport upstream:

  https://dovecot.org/pipermail/dovecot/2019-November/thread.html#117438

As Dovecot does not seems to have a public bug tracker I'm submitting it here
in order it to be publicly tracked.


Hi,

I got this simple test Sieve config:

#
# Sieve Filter
# Generated by Ingo (http://www.horde.org/apps/ingo/) (11/01/2019, 10:46:06 PM)

# Forwards
if true {
redirect "krus...@krustev.net";
}
# Forward Keep Action
if true {
keep;
stop;
}
#


Which used to work fine with:

  # 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
  # Pigeonhole version 0.4.16 (fed8554)
  # OS: Linux 4.9.0-8-amd64 x86_64 Debian 9.11

Then I've tried migrating to:

  # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
  # Pigeonhole version 0.5.4 ()
  # OS: Linux 4.19.0-6-amd64 x86_64 Debian 10.1

And started getting the following errors:

  # cat .dovecot.sieve.log
  sieve: info: started log at Nov 01 22:55:50.
  error: msgid=<4221584.AlbrL4BjWX@home>: failed to redirect message to 
: Failed to execute sendmail (temporary failure).

A google search lead me to:

  https://bugs.archlinux.org/task/56933

which blames systemd service changes:

  NoNewPrivileges=true

, however I'm not running dovecot via systemd but use DJB's daemontools for
service supervision .

The page above suggested to change from:

  sendmail_path = /usr/sbin/sendmail

to

  submission_host = localhost

in "conf.d/15-lda.conf", which worked fine.
But since I don't have other problems with "sendmail" execution I've decided
to debug this further.

I have dovecot integrated with Qmail:

# apt-cache policy qmail
qmail:
  Installed: 1.06-6+b1
  Candidate: 1.06-6+b1
  Version table:
 *** 1.06-6+b1 900
900 http://deb.debian.org/debian buster/main amd64 Packages

so sendmail's implementation comes from Qmail:

  # ls -al `which sendmail`
  lrwxrwxrwx 1 root root 14 Feb 23  2015 /usr/sbin/sendmail -> qmail-sendmail


I've strace-d the qmail-lspawn process which executes dovecot's LDA, which
processes the Sieve rules and executes "sendmail".
The sendmail process executes and returns successfully, the mail is delivered,
however the Sieve code does not wait for the child process correctly and tries
to kill the already exited process after 30 seconds timeout.

Here are the problematic Sieve syscalls:

22:55:15.283482 execve("/usr/lib/dovecot/deliver", ["/usr/lib/dovecot/deliver", 
"-e", "-a", "tes...@krustev.net"], 0x5620b4330c40 /* 61 vars */) = 0
...
22:55:15.286845 pipe([5, 6])= 0
22:55:15.286870 fcntl(5, F_GETFL)   = 0 (flags O_RDONLY)
22:55:15.286889 fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
22:55:15.286909 fcntl(6, F_GETFL)   = 0x1 (flags O_WRONLY)
22:55:15.286928 fcntl(6, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
22:55:15.286947 fcntl(5, F_GETFD)   = 0
22:55:15.286966 fcntl(5, F_SETFD, FD_CLOEXEC) = 0
22:55:15.286985 fcntl(6, F_GETFD)   = 0
22:55:15.287003 fcntl(6, F_SETFD, FD_CLOEXEC) = 0
22:55:15.287024 epoll_create(128)   = 7
22:55:15.287043 fcntl(7, F_GETFD)   = 0
22:55:15.287062 fcntl(7, F_SETFD, FD_CLOEXEC) = 0
22:55:15.287084 epoll_ctl(7, EPOLL_CTL_ADD, 5, 
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=47201248, u64=94699781110752}}) = 0
...
22:55:15.294625 epoll_ctl(7, EPOLL_CTL_DEL, 5, 0x7ffd59156b8c) = 0
22:55:15.294647 epoll_create(128)   = 12
22:55:15.294668 fcntl(12, F_GETFD)  = 0
22:55:15.294687 fcntl(12, F_SETFD, FD_CLOEXEC) = 0
22:55:15.294708 epoll_ctl(12, EPOLL_CTL_ADD, 5, 
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=47455536, u64=94699781365040}}) = 0

  Dovecot/Sieve will wait for this pipe FD 5 later, but no event will arrive.

22:55:15.294740 rt_sigaction(SIGCHLD, {sa_handler=0x7f15404b3640, sa_mask=[], 
sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f1540229840}, NULL, 
8) = 0
22:55:15.294763 pipe([13, 14])  = 0
22:55:15.294788 clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f15401ec2d0) = 6929


  The sendmail child process with PID 6929 is forked here.


22:55:15.294928 close(13)   = 0
22:55:15.294969 fcntl(14, F_GETFL)  = 0x1 (flags O_WRONLY)
22:55:15.295006 fcntl(14, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
22:55:15.295039 lseek(14, 0, SEEK_CUR)  = -1 ESPIPE (Illegal seek)
22:55:15.295065 getsockname(14, 0x7ffd59156a40, [28]) = -1 ENOTSOCK (Socket 
operation on non-socket)
22:55:15.295109 write(14, "EDITTED LONG MESSAGE DATA\n", 1461) = 1461
22:55:15.295150 close(14)   = 0
22:55:15.295175 wait4(6929, 0x562102d4fee4, WNOHANG, NULL) = 0
22:55:15.295211 epoll_wait(12, [], 1, 3) = 0


  Here's where the 30 second's timeout is requested and waited.


22:55:45.325580 kill(6929, SIGTERM) = 0
22:55:45.325769 epoll_wait(12, [], 1, 5000) = 0
22:55:50.331108 kill(6929, SIGKILL) = 0
22:55:50.332867 

Bug#893253: Is it still reproducible?

[Changwoo Ryu]

Control: tag -1 + moreinfo

Is it still reproducible with recent versions of ibus and clients?

Bug#879717: Wallpapers should have a better quality

[Jiri Kanicky]

I would like to confirm this. I run KDE and wallpaper, login screen, 
lock screen are very bad looking and it looks very unprofessional.


All the Debian svg images have got ripples.

/usr/share/desktop-base/futureprototype-theme/wallpaper/contents/images/

When you use XFCE and its wallpapers there is no such issue.

Would be nice if someone fixes this, that Debian looks more professional.

Thanks Jiri

Bug#887324: stretch-pu: package python-flask-rdf/0.2.0-1.1~deb9u1

[Andreas Beckmann]

Followup-For: Bug #887324
Control: tag -1 - moreinfo

On Thu, 22 Aug 2019 15:07:42 +0200 Andreas Beckmann 
wrote:
> On 21/08/2019 00.30, Adam D. Barratt wrote:
> >> That is not sufficient: #896358, #896385
> >>
> >> ImportError: No module named 'rdflib'
> > 
> > What's the status here?
> 
> Still reproducible in sid (same version as in buster), just reopened
> the bugs.

Obviously the Depends: python{3,}-rdflib has to be added manually.
Seen that in sid, applied to buster and now to stretch on top of the
previous patch.

Andreas
diff -Nru python-flask-rdf-0.2.0/debian/changelog 
python-flask-rdf-0.2.0/debian/changelog
--- python-flask-rdf-0.2.0/debian/changelog 2016-04-04 20:59:20.0 
+0200
+++ python-flask-rdf-0.2.0/debian/changelog 2019-11-09 02:45:10.0 
+0100
@@ -1,3 +1,19 @@
+python-flask-rdf (0.2.0-1.1~deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for stretch.
+  * Add (Build-)Depends on python{3,}-rdflib.  (Closes: #896358, #896385)
+
+ -- Andreas Beckmann   Sat, 09 Nov 2019 02:45:10 +0100
+
+python-flask-rdf (0.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix the missing dependencies in python3-flask-rdf.
+(Closes: #867429)
+
+ -- Adrian Bunk   Fri, 04 Aug 2017 15:27:27 +0300
+
 python-flask-rdf (0.2.0-1) unstable; urgency=medium
 
   * Imported Upstream version 0.2.0
diff -Nru python-flask-rdf-0.2.0/debian/control 
python-flask-rdf-0.2.0/debian/control
--- python-flask-rdf-0.2.0/debian/control   2016-04-04 20:57:50.0 
+0200
+++ python-flask-rdf-0.2.0/debian/control   2019-11-09 02:27:06.0 
+0100
@@ -9,7 +9,9 @@
python-setuptools,
python3-setuptools,
python-mimeparse (>= 0.1.4),
-   python3-mimeparse
+   python3-mimeparse,
+   python-rdflib,
+   python3-rdflib,
 Standards-Version: 3.9.7
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-flask-rdf.git
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-flask-rdf.git
@@ -19,6 +21,7 @@
 Architecture: all
 Depends: ${python:Depends},
  ${misc:Depends},
+ python-rdflib,
  python-mimeparse (>= 0.1.4)
 Description: Flask decorator to output RDF using content negotiation (Python 2)
  Apply the @flask_rdf decorator to a view function and return an rdflib
@@ -35,8 +38,9 @@
 
 Package: python3-flask-rdf
 Architecture: all
-Depends: ${python:Depends},
+Depends: ${python3:Depends},
  ${misc:Depends},
+ python3-rdflib,
  python3-mimeparse
 Description: Flask decorator to output RDF using content negotiation (Python 3)
  Apply the @flask_rdf decorator to a view function and return an rdflib

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Am Fr., 8. Nov. 2019 um 23:29 Uhr schrieb Matthias Klumpp :
> [...]
> Please remove the gtk-d package binaries for the armhf architecture 
> temporarily.
> [...]

Speaking of which, could the armhf packages of appstream-generator and
glib-d also be removed? The former suffers from a different issue (but
one that will only be fixed in a more recent GDC version (10), as the
package depends on a higher D language version), and the latter has
the exact same issue as described here (and appstream-generator
depends on glib-d, so removing the armhf binaries together makes
sense)

Thanks!

Bug#926416: ITP: conda -- OS-agnostic, system-level binary package manager and ecosystem

[Mo Zhou]

Hi Andreas,

Conda should not enter the main section.

As doko said, conda use MKL (non-free) by default, and prebuilt packages
are linked against libmkl_rt.so (entrance lib of MKL). So if you are going
to do performance tests, swithing BLAS/LAPACK alterntive to libmkl_rt
for Debian packages could help you reduce the number of variables to
control.

Install an Anaconda instance and identify the MKL linkage:

  fdfind -e so -x readelf -d | rg mkl

Another point supporting the "should enter contrib" claim is that
Anaconda does NOT allow its software repository be mirrored without
asking, which makes the packages not freely redistributable.

Bug#913061: systemd: stop shipping /bin/systemd

[Michael Biebl]

Hi Ansgar

On Thu, 12 Sep 2019 09:00:12 +0200 Ansgar  wrote:
> Ben Hutchings writes:
> > On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote:
> >> would it be possible to add a fallback to try /lib/systemd/systemd if
> >> the user provided init=/bin/systemd and the file no longer exists?
> >> 
> >> I would like systemd to stop shipping the /bin/systemd symlink as this
> >> should not be run by users, however it was suggested to use
> >> init=/bin/systemd for testing purposes in the past (see below).  So just
> >> removing the symlink might make some systems unbootable.
> >
> > I don't think it's appropriate for the initramfs to do this sort of
> > magic.  Even if they did, this wouldn't cover systems using a custom
> > kernel that doesn't need an initramfs.
> >
> > I think that a better way to handle this would be for systemd itself to
> > warn on upgrade if /proc/cmdline contains init=/bin/systemd.
> 
> The problem is that many people don't read warning or don't react on
> them right away.  So I would prefer if we had an additional safety net.
> If this wouldn't result in unbootable systems, I agree that a warning
> would be sufficient.

Since Ben was against adding such a fallback to initramfs-tools, we
either need a different solution or continue to ship the symlink.

I wonder whether aborting in preinst is acceptable or not. A warning
message probably won't cut it.


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



signature.asc
Description: OpenPGP digital signature

Bug#909791: udev: Disk labels are not detected correctly

[Michael Biebl]

On Sun, 30 Sep 2018 10:24:10 +0300
=?UTF-8?B?0J/QsNCy0LXQuyDQodCw0LzRgdC+0L3QvtCy?=
 wrote:
> Please get image
> wget http://tinyware.ru/iso/Test.iso

Is this issue still valid? If so, can you please re-upload that image.
I'm getting a 404 for that URL.

Thanks,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#904303: /sys/fs/cgroup/cpu,cpuacct/machine.slice changed after systemctl daemon-reload

[Michael Biebl]

Control: tags -1 + moreinfo

On Mon, 23 Jul 2018 10:11:15 +0800 Zhu Yijun  wrote:
> Package: systemd
> Version: 232-25+deb9u4
> 
> 
> Description of problem:
> After a 'systemctl daemon-reload' followed by any service 'systemctl
> restart xxx' the blkio, cpu,cpuacct、memory cgroup path changed.
> 
> Steps to Reproduce:
> 1. Create and launch a basic VM
> 2. Check that the cgroups are mapped properly for example with 'virsh
> memtune VM_NAME'
> 3. Execute 'systemctl daemon-reload'
> 4. Restart _any_ service on your machine, such as : systemctl restart libvirtd
> 
> before:
> 10:perf_event:/machine/qemu-1462-zyjtest.libvirt-qemu
> 9:blkio:/machine/qemu-1462-zyjtest.libvirt-qemu
> 8:cpu,cpuacct:/machine/qemu-1462-zyjtest.libvirt-qemu/emulator
> 7:memory:/machine/qemu-1462-zyjtest.libvirt-qemu
> 6:freezer:/machine/qemu-1462-zyjtest.libvirt-qemu
> 5:pids:/system.slice/libvirtd.service
> 4:devices:/machine/qemu-1462-zyjtest.libvirt-qemu
> 3:cpuset:/machine/qemu-1462-zyjtest.libvirt-qemu/emulator
> 2:net_cls,net_prio:/machine/qemu-1462-zyjtest.libvirt-qemu
> 1:name=systemd:/system.slice/libvirtd.service
> 
> after results:
> 10:perf_event:/machine/qemu-1462-zyjtest.libvirt-qemu
> 9:blkio:/
> 8:cpu,cpuacct:/
> 7:memory:/
> 6:freezer:/machine/qemu-1462-zyjtest.libvirt-qemu
> 5:pids:/system.slice/libvirtd.service
> 4:devices:/system.slice/libvirtd.service
> 3:cpuset:/machine/qemu-1462-zyjtest.libvirt-qemu/emulator
> 2:net_cls,net_prio:/machine/qemu-1462-zyjtest.libvirt-qemu
> 1:name=systemd:/system.slice/libvirtd.servi
> 
> # virsh memtune zyj_test
> error: Unable to get memory parameters
> error: Requested operation is not valid: cgroup memory controller is not 
> mounted
> 
> I found a similar description at :
> https://bugzilla.redhat.com/show_bug.cgi?id=1140215
> 
> And I had checked this systemd version had merged the patches.
> core: introduce new Delegate=yes/no property controlling creation of
> cgroup subhierarchies
> core: don't migrate PIDs for units that may contain subcgroups, do
> this only for leaf units
> 
> However, this issue is still exist.

Is the Delegate= option set for those cgroup hierarchies created by libvirt?

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



signature.asc
Description: OpenPGP digital signature

Bug#940595: transition: hypre

[Drew Parsons]

On 2019-11-09 05:45, Paul Gevers wrote:

Hi Drew,

On 03-11-2019 21:01, Paul Gevers wrote:

On 30-10-2019 08:26, Drew Parsons wrote:

So yes, the unversioned libhypre package name is certainly the option
that will preserve the greatest sanity (I'll proceed directly with
2.18.2 once you give the thumbs up).


Thumbs up.


All migrated. Closing this bug.



Thanks Paul.

Since we've got this ABI-free upstream with hypre, to save overworking 
you with future patch updates for little patch version updates (Z in 
X.Y.Z), I'm thinking to treat them as minor, so proceeding without a 
formal transition. I can request a binNMU for petsc/sundials/slepc.


Alternatively, more often than not there's a petsc upgrade waiting at 
the same time as a hypre upgrade (for example petsc 3.12 is waiting in 
experimental at the moment).  Maybe next time we can consider running a 
joint hypre/petsc/slepc transition. To save the busywork of hypre patch 
version transitions.


Drew

Bug#943981: Proposal: Switch to cgroupv2 by default

[Michael Biebl]

Hi Noah,

I plan to upload v243 to unstable soonish and will revert back to hybrid
for the time being.

That said, I started filing / user tagging bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=cgroupv2

Please *do* test cgroupv2 / unified hierarchy (by booting with
"systemd.unified_cgroup_hierarchy=true") though and report any issues
you find. This would be very much appreciated.
Feel free to use the same usertags (or mark this bug report as blocked
by) for the bug reports you file.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#944390: buster-pu: package python-flask-rdf/0.2.1-1+deb10u1

[Andreas Beckmann]

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

Let's add the missing Depends on python{3,}-rdflib.


Andreas
diff -Nru python-flask-rdf-0.2.1/debian/changelog 
python-flask-rdf-0.2.1/debian/changelog
--- python-flask-rdf-0.2.1/debian/changelog 2018-07-08 18:12:13.0 
+0200
+++ python-flask-rdf-0.2.1/debian/changelog 2019-11-09 01:56:51.0 
+0100
@@ -1,3 +1,10 @@
+python-flask-rdf (0.2.1-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Depends on python{3,}-rdflib.  (Closes: #896358, #896385)
+
+ -- Andreas Beckmann   Sat, 09 Nov 2019 01:56:51 +0100
+
 python-flask-rdf (0.2.1-1) unstable; urgency=medium
 
   * New upstream version 0.2.1
diff -Nru python-flask-rdf-0.2.1/debian/control 
python-flask-rdf-0.2.1/debian/control
--- python-flask-rdf-0.2.1/debian/control   2018-07-08 18:00:19.0 
+0200
+++ python-flask-rdf-0.2.1/debian/control   2019-11-09 01:56:43.0 
+0100
@@ -21,6 +21,7 @@
 Architecture: all
 Depends: ${python:Depends},
  ${misc:Depends},
+ python-rdflib,
  python-mimeparse (>= 0.1.4)
 Description: Flask decorator to output RDF using content negotiation (Python 2)
  Apply the @flask_rdf decorator to a view function and return an rdflib
@@ -39,6 +40,7 @@
 Architecture: all
 Depends: ${python3:Depends},
  ${misc:Depends},
+ python3-rdflib,
  python3-mimeparse
 Description: Flask decorator to output RDF using content negotiation (Python 3)
  Apply the @flask_rdf decorator to a view function and return an rdflib

Bug#917931: Lowering severity of ibus/XIM bugs

[Changwoo Ryu]

Control: retitle: -1 ibus: Chromium shortcuts with letter keys do not
work via XIM
Control: outlook -1 0
Control: severity -1 minor
Control: tags -1 + wontfix

This problem is XIM only and easily avoided by installing ibus-gtk3.

--

I'm lowering severity of the XIM related ibus bugs. I'm also adding
wontfix tag when a clear workaround exists (e.g. installing ibus-gtk3
for GTK apps).

One reason is that the upstream doesn't consider XIM related issues as
open bugs. I agree with the upstream; the protocol is ancient and
limited, the protocol spec is vague and client implementations are
often buggy. While we can't drop XIM as some clients (e.g. Java) do
not support other IM, I think most of the XIM bugs are not very worth
to fix.

Bug#944389: Add missing log file

[Michael Biebl]

log file attached

Probably relevant part is

> lxc-start autopkgtest-sid 20191109004244.136 WARN cgfsng - 
> cgroups/cgfsng.c:get_hierarchy:205 - There is no useable devices controller
> lxc-start autopkgtest-sid 20191109004244.136 ERRORcgfsng - 
> cgroups/cgfsng.c:cg_legacy_set_data:2299 - Failed to setup limits for the 
> "devices" controller. The controller seems to be unused by "cgfsng" cgroup 
> driver or not enabled on the cgroup hierarchy
> lxc-start autopkgtest-sid 20191109004244.136 WARN cgfsng - 
> cgroups/cgfsng.c:__cg_legacy_setup_limits:2341 - Failed to set "devices.deny" 
> to "a"


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
lxc-start autopkgtest-sid 20191109004243.980 INFO lxccontainer - lxccontainer.c:do_lxcapi_start:971 - Set process title to [lxc monitor] /var/lib/lxc autopkgtest-sid
lxc-start autopkgtest-sid 20191109004243.980 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM security driver AppArmor
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "reject_force_umount  # comment this to allow umount -f;  not recommended"
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:935 - Added native rule for arch 0 for reject_force_umount action 0(kill)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:944 - Added compat rule for arch 1073741827 for reject_force_umount action 0(kill)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:954 - Added compat rule for arch 1073741886 for reject_force_umount action 0(kill)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:964 - Added native rule for arch -1073741762 for reject_force_umount action 0(kill)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "[all]"
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "kexec_load errno 1"
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:935 - Added native rule for arch 0 for kexec_load action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:944 - Added compat rule for arch 1073741827 for kexec_load action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:954 - Added compat rule for arch 1073741886 for kexec_load action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:964 - Added native rule for arch -1073741762 for kexec_load action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "open_by_handle_at errno 1"
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:935 - Added native rule for arch 0 for open_by_handle_at action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:944 - Added compat rule for arch 1073741827 for open_by_handle_at action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:954 - Added compat rule for arch 1073741886 for open_by_handle_at action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:964 - Added native rule for arch -1073741762 for open_by_handle_at action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "init_module errno 1"
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:935 - Added native rule for arch 0 for init_module action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:944 - Added compat rule for arch 1073741827 for init_module action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:954 - Added compat rule for arch 1073741886 for init_module action 327681(errno)
lxc-start autopkgtest-sid 20191109004243.980 INFO seccomp - seccomp.c:parse_config_v2:964 - Added native rule for arch -1073741762 for init_module action 327681(errno)

Bug#883014: Lowering severity of ibus/XIM bugs

[Changwoo Ryu]

Control: retitle: -1 Using poedit textboxes via XIM without ibus-gtk3
Control: outlook -1 0
Control: severity -1 minor
Control: tags -1 + wontfix

This problem is XIM only and easily avoided by installing ibus-gtk3.

--

I'm lowering severity of the XIM related ibus bugs. I'm also adding
wontfix tag when a clear workaround exists (e.g. installing ibus-gtk3
for GTK apps).

One reason is that the upstream doesn't consider XIM related issues as
open bugs. I agree with the upstream; the protocol is ancient and
limited, the protocol spec is vague and client implementations are
often buggy. While we can't drop XIM as some clients (e.g. Java) do
not support other IM, I think most of the XIM bugs are not very worth
to fix.

Bug#840829: docker.io: Won't start under cgroupsv2

[Michael Biebl]

Package: docker.io
Version: 19.03.4+dfsg2-1
Followup-For: Bug #840829

Hi,

systemd maintainer here.

As you might have heard, Fedora has switched to cgroupv2 in their latest
release [1]. The new upstream default in systemd is unified, i.e.
cgroupv2. While we will revert this change for now, we plan to release
bullseye with cgroupv2 as the default [2], making this bug report RC.

I can confirm, that docker still fails if booted with unified hierarchy
enabled. I used cockpit-docker and got the following error message:

OCI runtime create failed: container_linux.go:346: starting container process 
caused "process_linux.go:297: applying cgroup configuration for process caused 
\"open /sys/fs/cgroup/docker/cpuset.cpus.effective: no such file or 
directory\"": unknown

I'm also attached the journal log from docker.service.

If you want to reproduce the failure, you can enable cgroupv2 by adding
"systemd.unified_cgroup_hierarchy=true" to the kernel command line.

Regards,
Michael


[1] https://fedoraproject.org/wiki/Changes/CGroupsV2
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981

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

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

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.3-2
ii  libc6   2.29-3
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libltdl72.4.6-11
ii  libnspr42:4.23-1
ii  libnss3 2:3.47-1
ii  libseccomp2 2.4.1-2
ii  libsystemd0 243-3
ii  lsb-base11.1.0
ii  runc1.0.0~rc9+dfsg1-1
ii  tini0.18.0-1+b1

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
pn  cgroupfs-mount   
ii  git  1:2.24.0-1
pn  needrestart  
ii  xz-utils 5.2.4-1+b1

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  5.3.1-1
ii  debootstrap  1.0.116
pn  docker-doc   
ii  e2fsprogs1.45.4-1
pn  rinse
ii  xfsprogs 5.2.1-1
pn  zfs-fuse | zfsutils  

-- no debconf information
-- Logs begin at Tue 2019-11-05 22:38:05 CET, end at Sat 2019-11-09 02:03:07 
CET. --
Nov 09 01:40:47 pluto systemd[1]: Starting Docker Application Container 
Engine...
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.665821447+01:00" 
level=info msg="Starting up"
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670404791+01:00" 
level=info msg="libcontainerd: started new docker-containerd process" pid=1378
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670480555+01:00" 
level=info msg="parsed scheme: \"unix\"" module=grpc
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670493413+01:00" 
level=info msg="scheme \"unix\" not registered, fallback to default scheme" 
module=grpc
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670519044+01:00" 
level=info msg="ccResolverWrapper: sending update to cc: 
{[{unix:///var/run/docker/containerd/containerd.sock 0  }] }" 
module=grpc
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670539576+01:00" 
level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.670647704+01:00" 
level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc00038b5c0, 
CONNECTING" module=grpc
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.777299292+01:00" 
level=info msg="starting containerd" 
revision=7c1e88399ec0b0b077121d9d5ad97e647b11c870 version=19.03.4
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.778353477+01:00" 
level=info msg="loading plugin \"io.containerd.content.v1.content\"..." 
type=io.containerd.content.v1
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.778633132+01:00" 
level=info msg="loading plugin \"io.containerd.snapshotter.v1.btrfs\"..." 
type=io.containerd.snapshotter.v1
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.779236043+01:00" 
level=info msg="skip loading plugin \"io.containerd.snapshotter.v1.btrfs\"..." 
error="path 
/var/lib/docker/containerd/daemon/io.containerd.snapshotter.v1.btrfs must be a 
btrfs filesystem to be used with the btrfs snapshotter: skip plugin" 
type=io.containerd.snapshotter.v1
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.779291267+01:00" 
level=info msg="loading plugin \"io.containerd.snapshotter.v1.devmapper\"..." 
type=io.containerd.snapshotter.v1
Nov 09 01:40:47 pluto dockerd[1274]: time="2019-11-09T01:40:47.779634957+01:00" 

Bug#944389: Fails to work with cgroupv2 / unified hierarchy

[Michael Biebl]

Package: lxc
Version: 1:3.1.0+really3.0.4-2
Severity: important
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2

Hi,

starting with systemd v243, the new upstream default in systemd will be
to use the unified hierarchy, i.e. cgroupv2

When trying to start an lxc container while booted with unified
hierarchy, I get the following failure:

lxc-start: autopkgtest-sid: lxccontainer.c: wait_on_daemonized_start: 850 
Received container state "ABORTING" instead of "RUNNING"
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 329 The container failed 
to start
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 332 To get more details, 
run the container in foreground mode
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 334 Additional information 
can be obtained by setting the --logfile and --logpriority options

A full DEBUG log is attached.

If you want to reproduce the failure, you can boot with systemd adding
"systemd.unified_cgroup_hierarchy=true" to the kernel command line.

While the Debian package will revert back to the hybrid hierarchy for
the time being, we plan to make cgroupv2 the default in bullseye.
Once we make this switch, this bug report would become RC.

See also
https://fedoraproject.org/wiki/Changes/CGroupsV2
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981

Regards,
Michael


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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.29-3
ii  libgcc11:9.2.1-17
ii  liblxc11:3.1.0+really3.0.4-2
ii  lsb-base   11.1.0

Versions of packages lxc recommends:
ii  apparmor 2.13.3-6
ii  bridge-utils 1.6-2
ii  debootstrap  1.0.116
ii  dirmngr  2.2.17-3
ii  dnsmasq-base [dnsmasq-base]  2.80-1+b1
ii  gnupg2.2.17-3
ii  iproute2 5.3.0-1
ii  iptables 1.8.3-2
ii  libpam-cgfs  1:3.1.0+really3.0.4-2
ii  lxc-templates3.0.4-1
ii  lxcfs3.0.4-2
ii  nftables 0.9.2-2
ii  openssl  1.1.1d-2
ii  rsync3.1.3-8
ii  uidmap   1:4.7-2

Versions of packages lxc suggests:
ii  btrfs-progs  5.3.1-1
ii  lvm2 2.03.02-3
ii  python3-lxc  1:3.0.4-1

-- Configuration Files:
/etc/lxc/default.conf changed [not included]

-- debconf information excluded

Bug#799042: cups-client: lpoptions no longer outputs anything

[Vincent Lefevre]

Control: reopen -1
Control: found -1 2.3.0-7

On 2019-11-08 20:11:13 +, Brian Potkin wrote:
> This report is a little old. and involves an unsupported Debian. Myself,
> I didn't observe the issue at the time of reporting. I still do not
> observe it. Closing time.

I can still see this issue with Debian unstable:

cventin:~> cat .cups/lpoptions
Default lip-multi-1 ColorModel=Gray Resolution=1200dpi
Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
cventin:~> lpq
lip-multi-1 is ready
no entries
cventin:~> lpoptions
cventin:~> lpoptions -plip-multi-1
ColorModel=Gray copies=1 
device-uri=lpd://liqqqs.lip.ens-lyon.fr/lip-multi-1-physical finishings=3 
job-hold-until=no-hold job-priority=50 job-sheets=none,none 
marker-change-time=0 number-up=1 
printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='Copieur 
multifonction Ricoh MP C3003, monochrome/couleur, A3/A4, recto-verso.' 
printer-is-accepting-jobs=true printer-is-shared=true printer-location='M1 3e 
étage - Bocal du LIP.' printer-make-and-model='Ricoh MP C3003 PS' 
printer-state=3 printer-state-change-time=157360 printer-state-reasons=none 
printer-type=12628220 
printer-uri-supported=ipp://liqqs.lip.ens-lyon.fr:443/printers/lip-multi-1 
Resolution=1200dpi
cventin:~>

Since lip-multi-1 is the default printer (note: none of the LPDEST and
PRINTER environment variables are set, so that the default destination
is obtained from ~/.cups/lpoptions), "lpoptions" should be equivalent
to "lpoptions -plip-multi-1", as documented.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#943594: buster-pu: package libapache-mod-auth-kerb/5.4-2.4~deb10u1

[Paul Wise]

On Fri, 2019-11-08 at 22:06 +, Adam D. Barratt wrote:

> Please go ahead.

Signed and uploaded the source package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#942493: lintian: Complain of too long header fields

[Michael Biebl]

Hi Felix

Am 09.11.19 um 00:27 schrieb Felix Lechner:
>> Given that systemd-tests-dbgsym is an autogenerated package, there isn't
>> really something that can be done to reduce the number of characters, or
>> is there?
> 
> Unless there is a flag that indicates autobuilding, we could exempt
> all packages ending in -dbgsym.
> 
> Alternatively, we could exempt the field Build-Ids. Or, we could
> except Build-Ids only in dbgsym packages. Please let us know.

I don't have a preference here or the insight to judge which option is
better suited or not.


Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#879044: gobject-introspection: mini-policy: clarify where language overrides should be shipped

[Changwoo Ryu]

But one problem of having Python (for example) overrides file in
gir1.2-* package is, that it creates unnecessary dependency on python
even for non-python rdepends.

Currently some gir1.2-* packages with Python overrides files have
intentionally missing python dependency to avoid such unnecessary
dependency and have lintian-overrides to avoid lintian error
python-package-missing-depends-on-python.
(https://lintian.debian.org/tags/python-package-missing-depends-on-python.html)

I'm not against having language overrides in gir1.2-* packages. But
when we choose to do it, it would be great if the mini policy clarify
this: If gir1.2-foo has Python overridess file, should gir1.2-foo
depend on Python? If not, is it OK to have lintian-overrides?

Bug#944388: tzfile(5): missing field charcnt in description of fields after the header

[Omer Zak]

Package: manpages
Version: 4.16-2
Severity: normal
Tags: upstream

In 'man 5 tzfile', after the header description, six fields are
described: tzh_timecnt*4, tzh_timecnt*1, tzh_typecnt*6, tzh_leapcnt*8,
tzh_ttisstdcnt*1, tzh_ttisgmtcnt*1.

According to https://tools.ietf.org/html/rfc8536 (section 3.2. TZif
Data Block), there should be also a tzh_charcnt field after the first
three fields (i.e. total of seven fields).

I was bitten by this omission when developing a script to process files
following the tzfile format.

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

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  konqueror [man-browser]  4:18.12.0-1
ii  man-db [man-browser] 2.8.5-2

-- no debconf information

Bug#944387: gir1.2-ibus-1.0: Remove Python2 g-i overrides file

[Changwoo Ryu]

Package: gir1.2-ibus-1.0
Version: 1.5.2-1
Severity: normal
Control: block -1 by 936717

For Python2 removal in sid/bullseye, the Python 2.x
gobject-introspection overrides file should be removed from
gir1.2-ibus-1.0. Currently ibus-array (0.2.1-2) is the only affected
package.

I'm filing this bug to track rdepends bug (#936717) before the removal.

Fixing this bug can be done just by adding --disable-python2 configure flag.

Bug#942759: [PATCH] handling of 0-width terminals

[Fabrice BAUZAC-STEHLY]

forwarded 942759 https://github.com/liske/needrestart/issues/166
tags 942759 + upstream fixed-upstream
thanks

A fix [1] has just been merged upstream.

There is no upstream release yet.

[1] https://github.com/liske/needrestart/pull/167

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#942493: lintian: Complain of too long header fields

[Felix Lechner]

Hi,

On Fri, Nov 8, 2019 at 2:57 PM Michael Biebl  wrote:
>
> > 1/ emit a warning when a field is larger than say 16K (somehow to force
> >the maintainer to think twice whether's he's doing something
> >reasonable)
> >
> > 2/ emit an error when a field is larger than 200K (it breaks reprepro
> >above 256K)

Lintian currently issues only a single tag---an error---for any field
value exceeding 5000 characters.

> > This should be applied to .deb headers and .dsc headers. (.changes headers
> > are less interesting as they are auto-generated without much control by
> > the maintainer, or are a simple copy of fields already present in other
> > files).

Lintian currently issue the tag for all files.

> this now triggers an error in systemd:
> E: systemd-tests-dbgsym: field-too-long 'Build-Ids' (8568 chars > 5000)
>
> Given that systemd-tests-dbgsym is an autogenerated package, there isn't
> really something that can be done to reduce the number of characters, or
> is there?

Unless there is a flag that indicates autobuilding, we could exempt
all packages ending in -dbgsym.

Alternatively, we could exempt the field Build-Ids. Or, we could
except Build-Ids only in dbgsym packages. Please let us know.

Kind regards,
Felix Lechner

Bug#942486: buster-pu: package shelldap/1.4.0-4+deb10u1

[Salvatore Bonaccorso]

hi Adam,

On Fri, Nov 08, 2019 at 09:52:28PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2019-10-17 at 08:52 +0200, Salvatore Bonaccorso wrote:
> > I was asked if we can address #941411 ("shelldap: sometimes falls
> > back to simple auth when it should do sasl") as well for buster. The
> > severity is not very high, so you might want to dispute this but it
> > fixes the issue seen.
> > 
> > Uwe reported that when calling shelldap repeatedly it sometimes fails
> > and this was due in Net::LDAP in the bind() method the iteration
> > through %ptype happens in different orderings.
> > 
> > We forwarded the original issue to upstream at
> > https://github.com/mahlonsmith/shelldap/issues/2 resulting in the
> > changes:
> > 
> >  - Don't provide a password for sasl authentication (adressing the
> >original concern)
> >  -  Fix sasl for DIGEST-MD5, PLAIN, and LOGIN mechanisms
> 
> Please go ahead; thanks.

Thank you; done.

Regards,
Salvatore

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Steffen Möller]

Hello,

On 08.11.19 23:14, Andreas Tille wrote:

On Fri, Nov 08, 2019 at 06:00:08PM +0100, Michael Crusoe wrote:

I got farther, but now the "dashboard" module won't load (no traceback).
The tests still fail spectacularly.

This is very old and non-free code. I suggest that all mglools* and
autodocktools* packages be removed.

I'm all for this - but as far as I understood Steffen he does not like
this idea.  I decided personally not invest any time into these
packages any more.


if the autodocktools are blocking something else then they have to go.
If not, well, I admit these packages are close to me but if this works
nowhere else than with me then there is no point, really.

Resistance weakens. I somehow keep doing things that are more important
than chasing the mgltools up. Maybe this all needs a new start, indeed.

Steffen

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli (wintermute)]

Package: autopkgtest
Version: 5.11
Severity: wishlist

Hello and thanks for maintaining autopkgtest!

I wanted to give the QEMU/KVM testbed a try. Hence I tried to create
a VM image by using autopkgtest-build-qemu. Its man page states:

[...]
|  Note that you need to call this as root.
[...]

And indeed the command

  $ autopkgtest-build-qemu unstable ~/var/cache/autopkgtest/sid.img

fails, when issued by a regular user, as it cannot even find parted
in the search PATH.

I guess this is because of vmdb2, which requires superuser privileges.
But why?
Is there any hope to improve vmdb2 or to use another tool, in order
to create a KVM testbed without requiring superuser privileges?



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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.4
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2+b1
ii  python3 3.7.5-1
ii  python3-debian  0.1.36

Versions of packages autopkgtest recommends:
ii  autodep8  0.19

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20190828.37eef910-3
ii  qemu-efi-aarch64  0~20190828.37eef910-3
ii  qemu-efi-arm  0~20190828.37eef910-3
ii  qemu-system   1:4.1-1+b4
ii  qemu-utils1:4.1-1+b4
pn  schroot   
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information

Bug#944385: ITP: skewer --

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: skewer -- 
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: skewer
  Version : 0.2.2
  Upstream Author : by Hongshan Jiang 
* URL : https://github.com/relipmoc/skewer
* License : MIT
  Programming Lang: C
  Description : 
 skewer implements the bit-masked k-difference matching algorithm
 dedicated to the task of adapter trimming and it is specially designed
 for processing next-generation sequencing (NGS) paired-end sequences.
 .
 Features
 .
  * Detection and removal of adapter sequences
  * Insertion and deletion allowed in pattern matching
  * Targeted at Single End, Paired End (PE), and Long Mate Pair (LMP) reads
  * Demultiplexing of barcoded sequencing runs
  * Multi-threading support
  * Trimming based on phred quality scores
  * IUPAC characters for barcodes and adapters
  * Compressed input and output support

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/skewer

Bug#943600: [Pkg-pascal-devel] Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation

[Abou Al Montacir]

I finally managed to catch one of these errors on amd64 machine.
The issue is that on some packages that are expected to fail, the failure
results on an exception.However and despite the expected failure is caught, the
test infrastructure detects a message written to stderr and thus triggers the
failure.
I've rebuilt lazuild using debug symbols, and the error seems to be caught in an
object destructor (#3) as shown in the following gdb stack trace:Warning:
(lazarus) [TLazPackageGraph.ConvertPackageRSTFiles] skipping read only directory
/usr/lib/lazarus/2.0.6/components/sparta/dockedformeditor/language/
Thread 4 "lazbuild" received signal SIGSEGV, Segmentation fault.[Switching to
Thread 0x77408700 (LWP 25224)]0x0051ac03 in LEAVECRITICALSECTION
(this=0x77649720) at ideexterntoolintf.pas:12371237   FWorkerMessages.LeaveC
riticalSection;(gdb) bt#0  0x0051ac03 in LEAVECRITICALSECTION
(this=0x77649720) at ideexterntoolintf.pas:1237#1  0x009e9cb5 in
SETTHREAD (this=0x77649720, AVALUE=0x0) at
exttools.pas:411#2  0x009edc57 in SETTOOL (this=0x7761fc40,
AVALUE=0x0) at exttools.pas:1313#3  0x009eeeb1 in DESTROY
(this=0x7761fc40, vmt=0x1) at exttools.pas:1612#4  0x0041cd20 in
SYSTEM$_$TOBJECT_$__$$_FREE ()#5  0x777a9a80 in ??
()#6  0x00440cd7 in CLASSES_$$_THREADFUNC$POINTER$$INT64
()#7  0x7761fc40 in ?? ()#8  0x in ?? ()(gdb) 
To be continued!
-- 
Cheers,
Abou Al Montacir


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

Bug#942493: lintian: Complain of too long header fields

[Michael Biebl]

Hi

On Thu, 17 Oct 2019 09:51:39 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?=
 wrote:
> Package: lintian
> Version: 2.27.0
> Severity: wishlist
> 
> Based on the problem discovered in #942487 where a Provides line of more
> than 256K slipped in the archive, I believe it would be nice if lintian
> could:
> 
> 1/ emit a warning when a field is larger than say 16K (somehow to force
>the maintainer to think twice whether's he's doing something
>reasonable)
> 
> 2/ emit an error when a field is larger than 200K (it breaks reprepro
>above 256K)
> 
> This should be applied to .deb headers and .dsc headers. (.changes headers
> are less interesting as they are auto-generated without much control by
> the maintainer, or are a simple copy of fields already present in other
> files).


this now triggers an error in systemd:
E: systemd-tests-dbgsym: field-too-long 'Build-Ids' (8568 chars > 5000)
N:
N:The length of the specified field is too long.
N:
N:Overly-long fields not only can break some tools tools (eg.
reprepro(1))
N:they can waste space as they are shipped to all users.
N:
N:Please reduce the number of characters.
N:
N:Refer to https://bugs.debian.org/942493 for details.
N:
N:Severity: important, Certainty: certain
N:
N:Check: fields/length, Type: binary, udeb, source


Given that systemd-tests-dbgsym is an autogenerated package, there isn't
really something that can be done to reduce the number of characters, or
is there?


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



signature.asc
Description: OpenPGP digital signature

Bug#944381: (no subject)

[westlake]

apt-get output:
'Error in file "/usr/share/applications/Projucer.desktop":
"applications/x-juce" is an
invalid MIME type ("applications" is an unregistered media type)'

Bug#944384: nmu: ros-*-msgs

[Jochen Sprickerhof]

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

Hi,

ros-gencpp in version 0.6.2-3 doesn't sort elements before generating
headers during the build of ros-*-msgs resulting in multi arch problems.
This has been fixed in ros-gencpp 0.6.2-4. Please binnmu the following
packages to align all headers again and make the multi arch hinter
happy:

nmu ros-common-msgs_1.12.7-2 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"
nmu ros-navigation-msgs_1.13.1-1 . ANY . unstable . -m "rebuild against 
ros-gencpp 0.6.2-4"
nmu ros-navigation-msgs_1.13.1-1 . ANY . unstable . -m "rebuild against 
ros-gencpp 0.6.2-4"
nmu ros-ros-comm-msgs_1.11.2-10 . ANY . unstable . -m "rebuild against 
ros-gencpp 0.6.2-4"
nmu ros-std-msgs_0.5.12-2 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"

Thanks

Jochen

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

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

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the gtk-d package binaries for the armhf architecture temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and the
package does not migrate to testing while it's not built on armhf.
Meanwhile, all packages depending on it are broken on all
architectures until the new version migrates (due to LDC ABI issues),
so in this particular instance I think it is justified that the
package is removed on armhf temporarily, to allow it to migrate.
The armhf binaries will highly likely be reintroduces as soon as the
issue is fixed in GDC or worked around there, and gtk-d built on armhf
with gdc.

Thanks for considering!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944382: xscreensaver-data-extra: invalid syntax in glitchpeg.desktop

[westlake]

Package: xscreensaver-data-extra
Version: 5.42+dfsg1-1
Severity: normal

from apt display error output,
"Could not parse file 
"/usr/share/applications/screensavers/glitchpeg.desktop": Key file 
contains line ?several times a second.  After a while, finds a new image 
to corrupt. Written by Jamie Zawinski; 2018.? which is not a key-value 
pair, group, or comment "

Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2

[Moritz Mühlenhoff]

On Fri, Nov 08, 2019 at 10:09:07PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2019-10-30 at 16:44 +0100, Moritz Muehlenhoff wrote:
> > (This is a followup update on top of the +deb10u1 already in s-p-u,
> > I've reached out to Tristan beforehand)
> > 
> > Attached debdiff fixes a memory leak in python-cryptography, which
> > was noticed in an ACME-related service (
> > https://wikitech.wikimedia.org/wiki/Acme-chief)
> > running on Buster. It has been verified that the updated packages
> > fix the memory leak (and are otherwise working fine as well).
> > 
> 
> Please go ahead.

Uploaded.

Cheers,
Moritz

Bug#944380: GDC generates duplicate symbols when using mixins/interfaces

[Matthias Klumpp]

Package: gdc-9
Version: 9.2.1-17
Severity: serious

Hi!
Currently, GDC can't build package like gtk-d because it generates
duplicate non-weak symbols in object files, causing a collision when
linking. This seems to happen when using mixins / interfaces.
For more information and a workaround, please check the upstream bug report.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944381: juce-tools: invalid syntax in desktop file

[westlake]

Package: juce-tools
Version: 5.4.1+really5.4.1~repack-3
Severity: normal

'Error in file "/usr/share/applications/Projucer.desktop": 
"applications/x-juce" is an

invalid MIME type ("applications" is an unregistered media type)'

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Andreas Tille]

On Fri, Nov 08, 2019 at 06:00:08PM +0100, Michael Crusoe wrote:
> 
> I got farther, but now the "dashboard" module won't load (no traceback).
> The tests still fail spectacularly.
> 
> This is very old and non-free code. I suggest that all mglools* and
> autodocktools* packages be removed.

I'm all for this - but as far as I understood Steffen he does not like
this idea.  I decided personally not invest any time into these
packages any more.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#944238: buster-pu: package debian-edu-config/2.10.65+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-11-06 at 22:22 +0800, Holger Levsen wrote:
> We'd like to update debian-edu-config in buster to fix one important
> (#944013 debian-edu-config: adjusted ini files needed to match
> changed behaviour of firefox-esr 68.2.0esr) and one normal bug:
> 
> debian-edu-config (2.10.65+deb10u2) UNRELEASED; urgency=medium
> 
>   * Adjust share/debian-edu-config/d-i/finish-install: (Closes:
> #941574)
> - Use 'dpkg-reconfigure -u --no-reload debian-edu-config' to add
> post-up
>   stanza to /etc/network/interfaces eth0 entry conditionally.
>   * Cope with Firefox-ESR ini files that need to be different (as of
> version
> 68.2.0esr) to further allow centralized configuration: (Closes:
> #944013)
> - Add share/debian-edu-config/profiles.ini.ff (Firefox-ESR
> profiles.ini).
> - Add share/debian-edu-config/installs.ini (now needed in
> addition for users
>   that don't have a Firefox-ESR profile, i.e. new users).
> - Adjust share/debian-edu-config/tools/gosa-create which is used
> to copy
>   the related Firefox-ESR ini files.
> - Ajust Makefile.
> - Adjust ldap-tools/ldap-debian-edu-install (fix for the first
> user).
> 

Please go ahead.

Regards,

Adam

Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-10-30 at 16:44 +0100, Moritz Muehlenhoff wrote:
> (This is a followup update on top of the +deb10u1 already in s-p-u,
> I've reached out to Tristan beforehand)
> 
> Attached debdiff fixes a memory leak in python-cryptography, which
> was noticed in an ACME-related service (
> https://wikitech.wikimedia.org/wiki/Acme-chief)
> running on Buster. It has been verified that the updated packages
> fix the memory leak (and are otherwise working fine as well).
> 

Please go ahead.

Regards,

Adam

Bug#943766: buster-pu: package libofx/1:0.9.14-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-10-29 at 15:21 +0100, Dylan Aïssi wrote:
> Upstream has fixed CVE-2019-9656, this CVE is non-dsa. I already
> backported patches to unstable (#924350) and now I would like to fix
> the Buster version. Please find attached a debdiff.
> 

Please go ahead.

Regards,

Adam

Bug#943594: buster-pu: package libapache-mod-auth-kerb/5.4-2.4~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-10-27 at 14:10 +0800, Paul Wise wrote:
> This brings the fix for a use after free crash to buster.
> Since there were no other changes between buster and bullseye,
> I elected to just add a "backport to buster" changelog.

Please go ahead.

Regards,

Adam

Bug#942827: buster-pu: package ndppd/0.2.5-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-10-22 at 09:18 +0200, Jean-Michel Vourgère wrote:
> In buster, ndppd has a world writable pid file. This prevent the
> daemon to be stop/restarted, which is a real pain when you set it up.

Please go ahead.

Regards,

Adam

Bug#944379: brz: ERROR: [Errno 2] No such file or directory: '.config/breezy'

[Jochen Sprickerhof]

Package: python3-breezy
Version: 3.0.1-6
Severity: normal
Tags: patch

Hi,

breezy doesn't always create it's config dir resulting in an exception.
The current behaviour breaks ros-wstool since the switch from bzr to brz:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ros-wstool.html

Steps to reproduce:

$ cd $(mktemp -d)
$ HOME=$(pwd) brz init
Created a standalone tree (format: 2a)
$ touch foo
$ HOME=$(pwd) brz status
brz: ERROR: [Errno 2] No such file or directory: 
'/tmp/tmp.7OnfYj98A5/.config/breezy'


Excrept from the .bzr.log:

0.039  encoding stdout as sys.stdout encoding 'UTF-8'
0.039  encoding stdout as sys.stdout encoding 'UTF-8'
0.039  encoding stdout as sys.stdout encoding 'UTF-8'
0.049  breezy version: 3.0.1
0.049  brz arguments: ['status']
0.154  encoding stdout as sys.stdout encoding 'UTF-8'
0.170  opening working tree '/tmp/tmp.7OnfYj98A5'
0.172  check paths: None
0.173  creating config directory: '/tmp/tmp.7OnfYj98A5/.config/breezy'
0.173  Transferred: 0kB (0.0kB/s r:0kB w:0kB)
0.175  Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/ignores.py", line 93, in 
get_user_ignores
f = open(path, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmp.7OnfYj98A5/.config/breezy/ignore'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 1016, in 
exception_to_return_code
return the_callable(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 1202, in 
run_bzr
ret = run(*run_argv)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 759, in 
run_argv_aliases
return self.run(**all_cmd_args)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 784, in run
return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 137, in 
run_simple
self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 166, in 
_do_with_cleanups
result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 1219, in 
ignore_pipe
result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/builtins.py", line 422, in run
classify=not no_classify)
  File "/usr/lib/python3/dist-packages/breezy/status.py", line 168, in 
show_tree_status
show_ids=show_ids, classify=classify)
  File "/usr/lib/python3/dist-packages/breezy/status.py", line 80, in 
report_changes
delta.unversioned if not new.is_ignored(unversioned[0])]
  File "/usr/lib/python3/dist-packages/breezy/status.py", line 80, in 
delta.unversioned if not new.is_ignored(unversioned[0])]
  File "/usr/lib/python3/dist-packages/breezy/bzr/workingtree.py", line 604, in 
is_ignored
self.get_ignore_list())
  File "/usr/lib/python3/dist-packages/breezy/bzr/workingtree.py", line 576, in 
get_ignore_list
ignore_globs.update(ignores.get_user_ignores())
  File "/usr/lib/python3/dist-packages/breezy/ignores.py", line 103, in 
get_user_ignores
_set_user_ignores(USER_DEFAULTS)
  File "/usr/lib/python3/dist-packages/breezy/ignores.py", line 125, in 
_set_user_ignores
config.ensure_config_dir_exists()
  File "/usr/lib/python3/dist-packages/breezy/config.py", line 1449, in 
ensure_config_dir_exists
os.mkdir(path)
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmp.7OnfYj98A5/.config/breezy'

0.175  return code 3


The easiest fix is to use os.makedirs instead of os.mkdir. See attached
patch.

Cheers Jochen

P.S.: brz in experimental is not installable, because this is not
fulfillable:

python3-breezy (<= 3.1.0~bzr7295-1.1~)
python3-breezy (>= 3.1.0~bzr7295-1)

$ dpkg --compare-versions "3.1.0~bzr7372-1" lt "3.1.0~bzr7295-1.1" && echo true

I would propose to use 3.1.0-bzr7372 as the upstream version in future,
as the tilde is special.

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

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

Versions of packages python3-breezy depends on:
ii  libc6   2.29-3
ii  python3 3.7.5-1
ii  python3-configobj   5.0.6-3
ii  python3-dulwich 0.19.13-1
ii  python3-fastimport  0.9.8-2
ii  python3-six 1.12.0-2

Versions of packages python3-breezy recommends:
ii  ca-certificates  20190110
ii  openssh-client [ssh-client]  1:8.1p1-1
pn  python3-github   
pn  python3-gitlab   
pn  python3-gpg  
pn  python3-launchpadlib 
ii  python3-paramiko  

Bug#942575: buster-pu: package openjpeg2/2.3.0-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-10-18 at 13:23 +0200, Hugo Lefeuvre wrote:
> as discussed in #939553[0], no DSA will be issued by the security
> team for CVE-2018-21010 and this vulnerability can be fixed via -pu.
> The attached debdiff addresses this issue, along with CVE-2018-20847.

Please go ahead; thanks.

Regards,

Adam

Bug#942520: buster-pu: package oar/2.5.8-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-10-17 at 15:48 +0200, Vincent Danjean wrote:
>   The default behavior of perl Storable::dclone function changed
> in buster, setting a default maximum recursion in the structures
> [1], [2].
>   This change has not been spotted before the release, but now
> that buster is released and that big clusters are switching to
> buster, this bug has been found (before the release, oar was
> tested only on smaller cluster).
>   So, we sould like to revert to the old behavior of Storable::dclone
> in the oar package (it is just two variables to set), so that
> oar in buster still works on big cluster (> 1000 cores).
> 

Please go ahead.

Regards,

Adam

Bug#942486: buster-pu: package shelldap/1.4.0-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-10-17 at 08:52 +0200, Salvatore Bonaccorso wrote:
> I was asked if we can address #941411 ("shelldap: sometimes falls
> back to simple auth when it should do sasl") as well for buster. The
> severity is not very high, so you might want to dispute this but it
> fixes the issue seen.
> 
> Uwe reported that when calling shelldap repeatedly it sometimes fails
> and this was due in Net::LDAP in the bind() method the iteration
> through %ptype happens in different orderings.
> 
> We forwarded the original issue to upstream at
> https://github.com/mahlonsmith/shelldap/issues/2 resulting in the
> changes:
> 
>  - Don't provide a password for sasl authentication (adressing the
>original concern)
>  -  Fix sasl for DIGEST-MD5, PLAIN, and LOGIN mechanisms

Please go ahead; thanks.

Regards,

Adam

Bug#944378: RFS: fbset/2.1-31 [ITA] -- framebuffer device maintenance program

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fbset
   Version : 2.1-31
   Upstream Author : Geert Uytterhoeven 
 * URL : http://users.telenet.be/geertu/Linux/fbdev/
 * License : GPL-2
 * Vcs : https://github.com/sudipm-mukherjee/fbset.git
   Section : admin

It builds those binary packages:

  fbset - framebuffer device maintenance program
  fbset-udeb - framebuffer device maintenance program

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/f/fbset/fbset_2.1-31.dsc

Changes since the last upload:

   * Update Maintainer (Closes: #740580)
   * sync with Linux Kernel v5.4-rc6
   * Update to Standards-Version 4.4.1
   * Use compatibility level 12
   * Change Priority to optional and remove duplicate Priority
   * Use github as Vcs


-- 
Regards
Sudip

Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2

[Sven Joachim]

On 2019-11-08 19:52 +, Adam D. Barratt wrote:

> On Wed, 2019-11-06 at 11:54 +, Adam D. Barratt wrote:
>> Control: tags -1 + confirmed d-i
>>
>> On 2019-11-02 19:10, Sven Joachim wrote:
>> > I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster,
>> > fixing
>> > several bugs in tic's parser which have been reported last
>> > month.  Two
>> > of them are heap buffer overflows that have been assigned CVE
>> > numbers
>> > and a Debian bug[1], two others are out-of-bound-reads and one an
>> > infinite loop.
>> >
>> > I have verified that the reported crashes and the infinite loop
>> > which I
>> > could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be
>> > fixed,
>> > at
>> > least with the submitted corrupt input files.  Also, the compiled
>> > terminfo files in ncurses-base and ncurses-term are identical to
>> > the
>> > ones currently in buster.
>> >
>> > This upload touches the tinfo library which is used in the
>> > installer,
>> > however to the best of my knowledge the changed functions are only
>> > used
>> > by tic and not by any other packages.
>>
>> Nevertheless I'd appreciate a formal ACK there.
>
> Given that the window for getting fixes into the 10.2 point release
> closes this weekend, feel free to upload and we'll wait for the d-i ack
> before deciding whether to include it in 10.2.

Thanks, uploaded.

Cheers,
   Sven

Bug#855995: Bug#942122: does not fallback to ipv4 when ipv6 fails

[Eduard Bloch]

Hallo,
* Antoine Beaupré [Sun, Oct 13 2019, 09:32:49AM]:
> > a) get all DNS records like ATM
> > b) filter to IPv4 or IPv6 or both (depending on user preference in 
> >  setting)
> > c) auto-sort the list so that the first entry is v4 or v6 (depending on 
> >  preference) and the following ones are alternativing
> > d) start connecting on the first entry
> > e) when nothing happened after N seconds, start a second connection attempt 
> > in parallel (using the second address, which is of different family then)
> > f) if the second background connect attmpt fails after N, abort it, try the 
> > next DNS entry in the sequence, etc. etc. (while the first connect attempt 
> > is still ongoing, until  seconds is reached)
> >
> > Questions:
> >
> > a) do you consider this reasonable enough?
>
> That seems reasonable, and actually pretty close to RFC8305.
>
> > b) would you like to become a tester for this, in case you can reproduce
> > this regularly? (I can fake the test case but nothing beats the real
> > thing)
>
> I can try! it can take up to a month for this situation to occur and I
> haven't tried reproducing it manually, but I'm definitely happy to help.

Well, I am sorry for the delay. The idea was to get it done ASAP but
it's not as easy as it seemed and I am short on spare time. I wanted to
release a fixed version a week ago but I found more and more issues with
legacy code. OTOH I think those issues has existed for years and nobody
really noticed and my stress tests were not tense enough.

So, the only thing I can offer ATM is a snapshot of unfinished version 3.3.

I believe that this is the best version of apt-cacher-ng since 2014 but
it still has a couple issues which I need to fix prior to release. And
this will take some time. For now, feel free to build it from salsa
("fakeroot debian/rules binary" on the debian/experimental branch) or
take a binary build from
https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.3/ . Receiving some
feedback would be good, but I will first prepare a release to
experimental anyway.

Changelogs:

  * Make errors on purging of cache folder non-fatal (closes: #915082)
  * Recommends: ca-certificates (closes: #926282)

  [ POSSIBLY BREAKING CHANGES ]
  * the setting of cachedir and logdir in the built-in defaults is now
configurable at build time (-DACNG_CACHE_DIR=... -DACNG_LOG_DIR=...)
and this settings are also propagated into generated configuration examples
  * Dropping support for CMake prior to v3.1, dropped most custom variables
for target locations, now relying on public CMake variables from
GNUInstallDirs module; for details, see
https://cmake.org/cmake/help/v3.2/module/GNUInstallDirs.html
  * Dropping support for OpenSSL before 1.0.2

  [ FEATURES AND IMPROVEMENTS ]
  * Change of default network timeout to 40 seconds
  * Alternative fallback scheme for non-primary target connection attempts
(with default timeout value of 4s, see FastTimeout setting). By default,
this should help with unstable (blocking) IPv6 routing where IPv4 is still
operational (Debian bug #942122)
  * Refactored DNS resolution code, potential fix of rate connection
problems
  * RequiresMountsFor directive in systemd service file example with
additional remarks on keeping this in sync with the config (as in Debian
bug #929035 and partly suggested in #942355)
  * PFilePattern extensions for Fedora 29 and 30, by Alan Jenkins, Debian
bug #928270 (thanks!)
  * VFilePattern extension for Centos8, by Andy Lowther, Debian bug #944143
(thanks!)
  * added very explicit explanation on what "default value" means in the
acng.conf example (Debian bug #855995) and also how to print it
(with acngtool, Debian bug #914746)
  * Mirror database update
  * Configurable timeout for forced client disconnect on the last portion of
data

  [ BUGFIXES ]
  * increased size of the decompression line buffer for config file reading
(Debian bug #942634)
  * fixes potential data race in DNS resolution
  * Typo in INSTALL file (Debian bug #913593)
  * In Arch Linux database mirror list, rewrite https URLs to http since the
official JSON query only returns https versions, also add a different
source (from Debian bug #942844)
  * Generation of Sourceforge mirror redirectors list is fixed
  * Fixed an ancient bug where there last answered request might have been
delayed in processing due to incorrect selection of MSG_MORE flag
  * Potential crash on shutdown prevented (misordered destructor sequence)

  [ INTERNAL REFACTORING ]
  * Overhauling code deployment, using a shared library (reducing installed
file size by up to 20%)
  * dropped rfc2553emu code from old APT, using the platform abstraction from
libevent instead
  * partial redesign for more singlethreaded IO operation
  * Disabled LTO by default, still crashing gold linker with certain option
combinations
  * Moved lingering on CLOSE_WAIT sockets to the single main thread

Best 

Bug#941713: buster-pu: package ntpsec/1.1.3+dfsg1-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-10-04 at 00:54 -0500, Richard Laager wrote:
> This is my first time with the Debian proposed update process (though
> I have done my own Ubuntu SRU once), so please bear with me and let
> me know if I've done anything wrong.

Seems OK to me. :-)

> The debdiff from the current version in Buster is attached. All of
> these
> fixes are in the version of ntpsec in Debian unstable.
> 
> 
> This upload is to fix several things, most importantly the first two:
> 
> * Backport fix for slow DNS retries (Closes: 924192)
> 
> The user described this pretty well, "What seems to be happening is
> that if DNS is not immediately available when ntpsec starts, it waits
> about 10 minutes before trying again. Ten minutes is too long."
> 
> This is fixed by backporting an upstream commit which has made it
> into an upstream point release.
> 
> 
> * Fix ntpdate -s (syslog) to fix the if-up hook (Closes: 931414)
[...]
> It may be controversial that I'm including fixes for bugs in man
> pages, including some without Debian bug numbers. The fixes below are
> trivial and only affect two (related) man pages. I likely would not
> have made a buster update for them alone, but since I'm making an
> update anyway, it seemed reasonable to me to include those fixes.

Indeed. That basically matches our policy - documentation fixes are
generally fine when part of a larger update, but not usually on their
own unless the incorrect documentation causes a severe bug.

Please go ahead with the upload.

Regards,

Adam

Bug#941683: buster-pu: package node-yarnpkg/1.13.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-10-03 at 20:57 +0200, Xavier Guimard wrote:
> node-yarnpkg is vulnerable: it exports auth data in http requests
> (#941354, CVE-2019-5448). This patch imports upstream fix.

Please go ahead; thanks.

Regards,

Adam

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-11-08 at 20:53 +, Adam D. Barratt wrote:
> Sorry for the delay in getting back to you.

Yeah, this time it's me who's really sorry.
> 
> That sounds OK, but it looks like the fix still hasn't made it to sid,
> so I'm tagging this as moreinfo for now. Please remove the tag and
> confirm the final debdiff once that's sorted.

Indeed, I'm still waiting on upstream to actually chose the way they bump the
soname… I still don't have any answer on 
https://github.com/libimobiledevice/libusbmuxd/issues/81

I'll keep you posted as soon as possible.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3F1koACgkQ3rYcyPpX
RFsL6ggAwAdOO596ztCsGMlHNWQ9Ch5QsXFKPLb70yJaBPOyVerr1Rq98ctNnGvH
Z3U1oQRrm3GhUo5wWIZ+Z5POlByxaWKbwCcVbStUQBnVtxxuG5cfgAEyH3aO87mc
BP2J3KHLQO86WYRRy0fG/b6swgl7581VEiaz97zJ1vovhckQwdpzPrSG9/NjdYLH
SwGGZ5HykgUMYnyynuVOW24IVh6nqqd5vB2Q89AB9YOwzx616DL16QNC1U1t8xJX
g45zciLGKW+fnxYV0QJ2oYnEVEXal8UdLcq9rC8v2KErhn5by/vADLnzttpu2h5T
NtJc7uXKpG14bLO6tw233QL7kkW55A==
=wUH1
-END PGP SIGNATURE-

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2019-09-29 at 18:48 +0200, Yves-Alexis Perez wrote:
> libimobiledevice in Buster has some issue with devices running iOS
> 13+. Backup using idevicebackup2 never finishes, apparently because
> of some behavior change in newer iOS version.
> 
> With coordination with upstream
> (https://github.com/libimobiledevice/libimobiledevice/issues/848) a
> small fix was identified.
> 
> Would it be possible to upload a fixed package to Buster at some
> point?
> The fix is not yet in sid (a previous package is waiting in NEW, I'll
> upload a package fix soon) so it's more a pre-approval.

Sorry for the delay in getting back to you.

That sounds OK, but it looks like the fix still hasn't made it to sid,
so I'm tagging this as moreinfo for now. Please remove the tag and
confirm the final debdiff once that's sorted.

Regards,

Adam

Bug#940647: buster-pu: package libmysofa/0.6~dfsg0-3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-09-18 at 14:42 +0200, IOhannes m zmoelnig wrote:
> the binary package libmysofa0 is used by VLC (the ubiquitous media
> player) and the ffmpeg framework (the ubiquitous media framework),
> and consequently has a popcon of 43382.
> 
> The src:libmysofa package has been assigned a number of CVEs and a
> cumulative Debian bug #939735.
> The issues (NULL-pointer access, out-of-bound reads, invalid reads
> and writes) have been promptly fixed by upstream, who have released a
> new version (0.8).
> 

Please go ahead. Sorry for the delay.

Regards,

Adam

Bug#944377: src:devscripts: Rebuild hangs

[Christoph Biedl]

Package: devscripts
Version: 2.19.7
Severity: important

Dear Maintainer,

since 2.19.7, rebuilding the devscripts package hangs on all my hosts.
The last logged line is at the end of the regular build:

| dpkg-buildpackage: info: binary-only upload (no source included)

Same checks revealed sbuild (my build system) tries to clean up the
build environment then and stalls since there are still processes
running. Among them is "/bin/sh ./test_uscan" from the test suite, and
killing it will continue the job and result in a successful build.

This does not occur with 2.19.6, even with today's sid. So it's fairly
certain the problem lies within devscripts itself, not in some of the
build dependencies.

Looking at the changes in test_uscan sources I fail to see why the
change that happened should have such a side effect, so I feel a bit
lost here.

Regards,
Christoph

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.19.80 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.37-6
ii  gnupg 2.2.17-3
ii  gpgv  2.2.17-3
ii  libc6 2.29-3
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.003006-1
ii  libwww-perl   6.39-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  pseudo [fakeroot] 1.9.0+git20190515+996bead-2
ii  python3   3.7.5-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
pn  at  
ii  curl7.66.0-1+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2019.09.24
ii  dput-ng [dput]  1.28
pn  equivs  
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
ii  libgitlab-api-v4-perl   0.23-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.34.0
ii  man-db  2.9.0-1
ii  patch   2.7.6-6
ii  python3-apt 1.8.4
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  5.11
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.7.1
pn  devscripts-el
ii  diffoscope   129
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-3
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.31-1+b2
ii  mozilla-devscripts   0.54
pn  mutt 
ii  openssh-client [ssh-client]  1:8.1p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information



signature.asc
Description: PGP signature

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Nicholas D Steeves]

On Fri, Nov 08, 2019 at 10:53:31AM -0700, Sean Whitton wrote:
> On Thu 07 Nov 2019 at 04:51PM -05, Nicholas D Steeves wrote:
> 
> > I suggest replacing the whole sentence with "The purpose of this field
> > is exclusively for cases where a package's license, or when DFSG
> > requirements, necessitate its presence; Built-Using should not be used
> > for any other purpose".  This is much more clear and it flows
> > nicely into the next sentence "In particular, it should not be added
> > solely to enable finding packages that should be rebuilt against newer
> > versions of their build dependencies."
> 
> Thank you for this.  I agree that the sentence is unnecessarily hard to
> read.  Perhaps you could propose a patch against policy.git.

You're welcome :-)  Done!
  https://salsa.debian.org/sten-guest/policy/merge_requests/2


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#944136: laptop audio not working

[Ben Hutchings]

Control: reassign -1 src:linux
Control: forcemerge 942881 -1

On Mon, 2019-11-04 at 14:06 -0700, Bdale Garbee wrote:
> Package: linux-image-5.3.0-1-amd64
> Version: 5.3.7-1
> 
> The audio on my Lenovo T490 doesn't work at all with this kernel package.
> Dropping back to linux-image-5.2.0-3-amd64 resolves the problem.
> 
> 00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio 
> Controller (rev 30)
> 
> Is this a known issue, or should I start bisecting?

I strongly suspect this is the same as #942881 (bad signature on
snd-hda-codec-hdmi that prevents it loading).  Unmerge this if that
looks wrong.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Ben Hutchings]

On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
[...]
> The code for libtracevent lives in the kernel tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> tools/lib/traceevent folder.
> And so, it will be great if kernel team will like to package and maintain it, 
> if not, then I will
> be happy to do it. But, if I am doing it then I will need a sponsor to upload 
> it.

If kernel.org's kernel source repository is the canonical location for
this code, not just a convenience copy, then the binary package should
be built from src:linux and not a separate source package.

I think src:linux already builds the library, but only as a static
library that's linked into perf.

I don't know exactly what changes you would need to make, but they
should be roughly along these lines:

1. Add debian/rules.d/tools/lib/traceevent/Makefile with a default
   target that calls the upstream build system.  This must build in
   the current directory (somewhere under debian/build) and not the
   source directory.  It must enable printing of all build comamnds
   by default.

2. Define the new binary packages and their build-dependencies in
   debian/templates/control.tools-unversioned.in.  These packages
   must have "Build-Profiles: ".

3. Define build-libtraceevent and install-libtraceevent targets in 
   debian/rules.real, similarly to those for libcpupower.
   Add those to the dependencies of the build-arch-arch and
   binary-arch-arch targets, using the if_package macro to check
   whether the packages should be built.

4. Generate the debian/libtraceevent.symbols file recording
   the shared library's exported symbols.

5. (Not sure if this is needed.)  Modify
   debian/rules.d/tools/perf/Makefile to make perf use the shared
   library.  Add libtraceevent to the dependencies of
   linux-perf- in debian/templates/control.tools-versioned.in.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#944376: dh-make: Won't migrate to testing due to non-source-only upload

[Boyuan Yang]

Package: dh-make
Version: 2.201902
Severity: normal

Hi Craig,

Your previous upload of package dh-make/2.201902 will not migrate to Debian
Testing since the upload contains maintainer-build binary packages. Please
consider making another upload to fix this issue.

-- 
Best,
Boyuan Yang


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

Bug#944133: buster-pu: package glib2.0/2.58.3-2+deb10u2

[Adam D. Barratt]

On Wed, 2019-11-06 at 12:08 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On 2019-11-04 19:12, Simon McVittie wrote:
> > A recent security fix to ibus (CVE-2019-14822, #940267, DSA-4525-1)
> > exposed an interoperability bug between GLib's implementation of D-
> > Bus
> > and the reference implementation libdbus (#941018). The practical 
> > impact
> > is that Qt clients cannot use the updated ibus input method until
> > GLib
> > is fixed.
> > 
> > This has been fixed in the upstream master and 2.62.x branches and
> > in unstable, and I've prepared backports for buster (this bug)
> > and stretch (I'll open a separate bug when I have a successful
> > build/autopkgtest/piuparts pipeline).
> 
> This looks OK to me, but will need a d-i ACK due to the udeb build; 
> thanks.

Given that the window for getting fixes into the 10.2 point release
closes this weekend, feel free to upload and we'll wait for the d-i ack
before deciding whether to include it in 10.2.

Regards,

Adam

Bug#944374: buster-pu: package fonts-noto-cjk/1:20170601+repack1-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-11-08 at 14:01 -0500, Boyuan Yang wrote:
> A solution for https://bugs.debian.org/907999 was recently found and
> the fix has been tested and pushed onto Sid. Since this bug also
> affects Stable, it would be better to have it fixed through a stable-
> pu as well.
> 
> The bug lies in a Debian-provided fontconfig file (70-fonts-noto-
> cjk.conf) and the old version was using the "prepend_first" attribute
> to adjust the font priority under Chinese-locale systems, which turns
> out to be buggy and made font rendering to be ignoring font fallback
> info in CSS files and forcefully using Noto CJK fonts under certain
> scenarios in web browsers like Firefox and
> Chromium. This proposed patch would solve this bug.
> 

Please go ahead.

Regards,

Adam

Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2

[Adam D. Barratt]

On Wed, 2019-11-06 at 11:54 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On 2019-11-02 19:10, Sven Joachim wrote:
> > I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster,
> > fixing
> > several bugs in tic's parser which have been reported last
> > month.  Two
> > of them are heap buffer overflows that have been assigned CVE
> > numbers
> > and a Debian bug[1], two others are out-of-bound-reads and one an
> > infinite loop.
> > 
> > I have verified that the reported crashes and the infinite loop
> > which I
> > could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be
> > fixed, 
> > at
> > least with the submitted corrupt input files.  Also, the compiled
> > terminfo files in ncurses-base and ncurses-term are identical to
> > the
> > ones currently in buster.
> > 
> > This upload touches the tinfo library which is used in the
> > installer,
> > however to the best of my knowledge the changed functions are only
> > used
> > by tic and not by any other packages.
> 
> Nevertheless I'd appreciate a formal ACK there.

Given that the window for getting fixes into the 10.2 point release
closes this weekend, feel free to upload and we'll wait for the d-i ack
before deciding whether to include it in 10.2.

Regards,

Adam

Bug#943419: NMU-upload python-requests-toolbelt

[Petter Reinholdtsen]

Håvard Flaget Aasen  writes:

> Hello,
>
> I am wondering if i am allowed to upload new package of 
> python-requests-toolbelt. I have prepared a NMU upload.

I take it from what I see in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943419 >, you
are not aware that sending email to 943...@bugs.debian.org do not reach
the requestor. :)

It is probably better to adapt it, and join the #debian-python IRC
channel and the python team to learn more how to maintain python
packages in Debian. :)

NMU is probably a waste if you instead can adapt it. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#944373: fs-uae: update fs-uae to upstream version

[John Paul Adrian Glaubitz]

Hi Thorsten!

On 11/8/19 8:00 PM, Thorsten Ehlers wrote:
> upstream has released version 3 some month ago so it would by really nice to
> have fs-uae deb-package updated from 2.8.3 to 3.0.2.
> 
> Debian's tracker page https://tracker.debian.org/pkg/fs-uae doesn't find newer
> versions of fs-uae as web site of upstream has changed. It is now located at
> https://fs-uae.net/download

Yes, I'm aware of this. I haven't had the time to work on it though. I have
planned to do that during the Christmas holidays.

Adrian

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

Bug#919134: Python and PIE

[Michele Orrù]

Arch linux seems to have PIE too:

$ file /usr/bin/python3.7
/usr/bin/python3.7: ELF 64-bit LSB pie executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=edce9cb329b348463d5c868aa48bac4e146ce0e7, for GNU/Linux
3.2.0, stripped

Hope this clarifies a bit more what «other distros also do» meant in the
top message.
Ciao,



On Fri, Nov 8, 2019 at 5:21 PM Michele Orrù  wrote:

> Hello again Doko,
>
> I'm reaching out once again (and updating the bug) to ask if perhaps you
> could take a look at my patch. I really just want to remove 4 lines of
> code!
>
> https://salsa.debian.org/maker-guest/python3/commit/ecb4c4647e99243d03888ee5ddec5dfdfd223d5c
>
> I tested the compiled packaged (once again, on your updated revision) and
> everything seemed okay on my machine.
>
> I tried to reach out to you via Holger, who said I should double-check for
> potential performance issues and whether other distributions use it.
>
> On fedora, Giovanni tested python3-3.7.3-1.fc30.i686.rpm
>
> $ hardening-check python3
> python3:
>  Position Independent Executable: yes
>  Stack protected: no, not found!
>  Fortify Source functions: unknown, no protectable libc functions used
>  Read-only relocations: yes
>  Immediate binding: yes
>
>
> Attached, you will find the result of pyperformance compare between
> python3.8 compiled with -fPIE and without. I don't really buy the argument
> of performance loss in a language like python, especially given the big
> attack surface we are offering right now; anyways, just for the record,
> it's between 2-5x slower, which doesn't seem so dramatic to me.
>
> I also find it very suspicious that in the git log (of python 3 and python
> 2) there is no justification for disabling PIE explicitly: why this code
> was there in the first place?
>
>
> I'm going to try escalating this issue to other people in debian security
> if I don't get a reply within a week!
> Cheers,
>

Bug#944375: synaptic: Add option to explicitly accept repository changes

[Keven L. Ates]

Package: synaptic
Version: 0.84.5
Severity: wishlist

Occasionally, repository owners change related information, keys, etc. This
generally causes apt to issue an error to the user, such as:

...
Reading package lists... Done
E: Repository 'http://ppa.launchpad.net///ubuntu disco
InRelease' changed its 'Label' value from '' to ''
N: This must be accepted explicitly before updates for this repository can be
applied. See apt-secure(8) manpage for details.
...

When using "apt" on the command line, the system asks:

Do you want to accept these changes and continue updating from this repository?
[y/N]

Synaptic will report the error, but does nothing to allow the user to accept
changes. The older "apt-get" tool does the same unless a --allow-releaseinfo-
change update" switch is given:

sudo apt-get --allow-releaseinfo-change update

I suggest an enhancement to allow synaptic to somehow "accept the changes" for
the affected repository(s).



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

Kernel: Linux 5.0.0-32-generic (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages synaptic depends on:
ii  hicolor-icon-theme  0.17-2
ii  libapt-inst2.0  1.8.3
ii  libapt-pkg5.0   1.8.3
ii  libc6   2.29-0ubuntu2
ii  libc6-udeb [libc6]  2.30-0ubuntu2
ii  libept1.5.0 1.1+nmu3build1
ii  libgcc1 1:9.1.0-2ubuntu2~19.04
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.60.4-0ubuntu0.19.04.1
ii  libgtk-3-0  3.24.8-1ubuntu1
ii  libpango-1.0-0  1.42.4-6ubuntu0.1
ii  libstdc++6  9.1.0-2ubuntu2~19.04
ii  libvte-2.91-0   0.56.2-1ubuntu1~19.04.1
ii  libxapian30 1.4.10-1
ii  policykit-1 0.105-25

Versions of packages synaptic recommends:
ii  libgtk2-perl  2:1.24992-1build2
ii  xdg-utils 1.1.3-1ubuntu2

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.47ubuntu13
pn  deborphan
pn  dwww 
pn  menu 
ii  software-properties-gtk  0.97.11
pn  tasksel  

-- no debconf information

Bug#944374: buster-pu: package fonts-noto-cjk/1:20170601+repack1-3+deb10u1

[Boyuan Yang]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: debian-fo...@lists.debian.org

Dear Release Team,

A solution for https://bugs.debian.org/907999 was recently found and the fix
has been tested and pushed onto Sid. Since this bug also affects Stable, it
would be better to have it fixed through a stable-pu as well.

The bug lies in a Debian-provided fontconfig file (70-fonts-noto-cjk.conf) and
the old version was using the "prepend_first" attribute to adjust the font
priority under Chinese-locale systems, which turns out to be buggy and made
font rendering to be ignoring font fallback info in CSS files and forcefully
using Noto CJK fonts under certain scenarios in web browsers like Firefox and
Chromium. This proposed patch would solve this bug.

Please review the fix and let me know if there's any question.

The full debdiff is provided as attachment.

-- 
Regards,
Boyuan Yang
diff -Nru fonts-noto-cjk-20170601+repack1/debian/70-fonts-noto-cjk.conf fonts-noto-cjk-20170601+repack1/debian/70-fonts-noto-cjk.conf
--- fonts-noto-cjk-20170601+repack1/debian/70-fonts-noto-cjk.conf	2018-08-28 09:44:11.0 -0400
+++ fonts-noto-cjk-20170601+repack1/debian/70-fonts-noto-cjk.conf	2019-11-08 13:10:08.0 -0500
@@ -32,7 +32,7 @@
 
 serif
 
-
+
 Noto Serif CJK SC
 
 
@@ -44,7 +44,7 @@
 
 serif
 
-
+
 Noto Serif CJK TC
 
 
@@ -80,7 +80,7 @@
 
 sans-serif
 
-
+
 Noto Sans CJK SC
 
 
@@ -92,7 +92,7 @@
 
 sans-serif
 
-
+
 Noto Sans CJK TC
 
 
@@ -128,7 +128,7 @@
 
 monospace
 
-
+
 Noto Sans Mono CJK SC
 
 
@@ -140,7 +140,7 @@
 
 monospace
 
-
+
 Noto Sans Mono CJK TC
 
 
diff -Nru fonts-noto-cjk-20170601+repack1/debian/changelog fonts-noto-cjk-20170601+repack1/debian/changelog
--- fonts-noto-cjk-20170601+repack1/debian/changelog	2018-08-28 09:50:21.0 -0400
+++ fonts-noto-cjk-20170601+repack1/debian/changelog	2019-11-08 13:10:08.0 -0500
@@ -1,3 +1,13 @@
+fonts-noto-cjk (1:20170601+repack1-3+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * debian/70-fonts-noto-cjk.conf: Use "prepend" instead of
+"prepend_first". This fixes over-aggressive font selection
+of Noto CJK fonts in modern web browsers under Chinese locale.
+(Closes: #907999)
+
+ -- Boyuan Yang   Fri, 08 Nov 2019 13:10:08 -0500
+
 fonts-noto-cjk (1:20170601+repack1-3) unstable; urgency=medium
 
   [ Boyuan Yang ]


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

Bug#944373: fs-uae: update fs-uae to upstream version

[Thorsten Ehlers]

Package: fs-uae
Version: 2.8.4+dfsg-2
Severity: wishlist

Dear Maintainer,

upstream has released version 3 some month ago so it would by really nice to
have fs-uae deb-package updated from 2.8.3 to 3.0.2.

Debian's tracker page https://tracker.debian.org/pkg/fs-uae doesn't find newer
versions of fs-uae as web site of upstream has changed. It is now located at
https://fs-uae.net/download

greetings



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

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

Versions of packages fs-uae depends on:
ii  libc6  2.29-3
ii  libgcc11:9.2.1-17
ii  libgl1 1.1.0-1+b1
ii  libglib2.0-0   2.62.2-3
ii  libmpeg2-4 0.5.1-8+b1
ii  libopenal1 1:1.19.1-1+b1
ii  libpng16-161.6.37-1
ii  libsdl2-2.0-0  2.0.10+dfsg1-1
ii  libstdc++6 9.2.1-17
ii  libx11-6   2:1.6.8-1
ii  zlib1g 1:1.2.11.dfsg-1+b1

fs-uae recommends no packages.

fs-uae suggests no packages.

-- no debconf information

Bug#944352: Additional infos from /var/log/syslog:

[Thorsten Ehlers]

starting scummvm, moving mouse and finally terminating scummvm with Alt+F4:

Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
EDID vendor "FUS", prod id 1804
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Using hsync ranges from config file
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Using vrefresh ranges from config file
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Printing DDC gathered Modelines:
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066
+hsync +vsync (64.0 kHz eP)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync
+vsync (37.9 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync
-vsync (37.5 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync
-vsync (31.5 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync
+vsync (31.5 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066
+hsync +vsync (80.0 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800
+hsync +vsync (60.0 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806
-hsync -vsync (48.4 kHz e)
Nov  8 19:23:15 eumel /usr/lib/gdm3/gdm-x-session[1447]: (II) AMDGPU(0):
Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync
+vsync (46.9 kHz e)
Nov  8 19:23:15 eumel scummvm.desktop[1683]: WARNING: SDL mixer output
buffer size: 512 differs from desired: 1024!
Nov  8 19:23:17 eumel kernel: [  369.966750] [drm] pstate TEST_DEBUG_DATA:
0x3FF6
Nov  8 19:23:17 eumel kernel: [  369.966752] [ cut here
]
Nov  8 19:23:17 eumel kernel: [  369.966909] WARNING: CPU: 3 PID: 198 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:932
dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu]
Nov  8 19:23:17 eumel kernel: [  369.966911] Modules linked in:
snd_seq_dummy snd_seq fuse pci_stub vboxpci(OE) vboxnetadp(OE)
vboxnetflt(OE) vboxdrv(OE) snd_usb_audio snd_usbmidi_lib snd_rawmidi
snd_seq_device pwc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2
videobuf2_common videodev mc edac_mce_amd kvm_amd ccp rng_core kvm
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel binfmt_misc
aesni_intel snd_hda_codec_realtek snd_hda_codec_generic aes_x86_64
ledtrig_audio crypto_simd cryptd snd_hda_intel sp5100_tco glue_helper
snd_hda_codec eeepc_wmi asus_wmi snd_hda_core sparse_keymap pcspkr
serio_raw rfkill wmi_bmof snd_hwdep k10temp watchdog snd_pcm sg snd_timer
snd soundcore evdev acpi_cpufreq parport_pc ppdev lp parport ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sr_mod sd_mod cdrom
uas usb_storage hid_generic usbhid hid amdgpu gpu_sched i2c_algo_bit ttm
drm_kms_helper drm crc32c_intel mfd_core ahci xhci_pci libahci i2c_piix4
xhci_hcd libata r8169 realtek usbcore libphy scsi_mod
Nov  8 19:23:17 eumel kernel: [  369.966950]  usb_common wmi video
gpio_amdpt gpio_generic button
Nov  8 19:23:17 eumel kernel: [  369.966957] CPU: 3 PID: 198 Comm:
kworker/u64:9 Tainted: GW  OE 5.3.0-1-amd64 #1 Debian 5.3.7-1
Nov  8 19:23:17 eumel kernel: [  369.966958] Hardware name: System
manufacturer System Product Name/PRIME B450M-A, BIOS 1821 09/30/2019
Nov  8 19:23:17 eumel kernel: [  369.966971] Workqueue: events_unbound
commit_work [drm_kms_helper]
Nov  8 19:23:17 eumel kernel: [  369.967086] RIP:
0010:dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu]
Nov  8 19:23:17 eumel kernel: [  369.967089] Code: 83 c8 ff e9 7e 1d f8 ff
48 c7 c7 50 8b a5 c0 e8 9f f4 54 e1 0f 0b 83 c8 ff e9 68 1d f8 ff 48 c7 c7
50 8b a5 c0 e8 89 f4 54 e1 <0f> 0b 80 bb 9f 01 00 00 00 75 05 e9 4c 44 f8
ff 48 8b 83 f8 02 00
Nov  8 19:23:17 eumel kernel: [  369.967091] RSP: 0018:b0cec05a7a88
EFLAGS: 00210246
Nov  8 19:23:17 eumel kernel: [  369.967093] RAX: 0024 RBX:
9e1ead8b RCX: 0006
Nov  8 19:23:17 eumel kernel: [  369.967094] RDX:  RSI:
00200092 RDI: 9e1ebeed7680
Nov  8 19:23:17 eumel kernel: [  369.967095] RBP: 9e1eb6ec R08:
042e R09: 0004
Nov  8 19:23:17 eumel kernel: [  369.967096] R10:  R11:
0001 R12: 9e1ead8b
Nov  8 19:23:17 eumel kernel: [  369.967097] R13: 9e1ead96c000 R14:

Bug#944372: mailutils: "mail" command segfaults

[Steve Newcomb]

On Fri, 08 Nov 2019 11:55:50 -0500 Steve Newcomb  wrote:
>
> 191108 11:52 /tmp srn@vsv1% mail
> "maildir:///home/srn/Maildir": 3 messages 3 new
> Segmentation fault
> 191108 11:52 /tmp srn@vsv1%

...and syslog receives the following entries:


Nov  8 11:52:42 vsv1 kernel: [ 3370.653281] mail[4906]: segfault at 0 ip 
7f4354c7f181 sp 7ffde6656168 error 4 in 
libc-2.28.so[7f4354b45000+148000]
Nov  8 11:52:42 vsv1 kernel: [ 3370.653290] Code: 84 00 00 00 00 00 0f 
1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 
f9 ef c0 83 e1 3f 83 f9 20 77 1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 
df 00 00 00 48 83 c7 20 83 e1

Bug#944361: cgal: cgal 5.0 released

[Nico Schlömer]

Alright, thanks for the update! (I didn't even know there was discussion
about git atm.)

On Fri, Nov 8, 2019, 5:40 PM Joachim Reichel  wrote:

> tag 944361 +pending
> thanks
>
> Hi,
>
> I did not see any release announcement for CGAL 5.0 final yet, only for
> Beta 2.
>
> Thanks for your offer to help, but I'm already working on updating the
> packaging
> and in contact with upstream to get the last problems fixed. Updating the
> packaging requires non-trivial changes due to the header-only mode now
> being the
> default. Also, CGAL 5.0 will need to go to experimental first and needs a
> transition slot.
>
> Yes, the package is not on salsa yet. I plan to do that eventually, but
> wanted
> to wait for the outcome of the currently ongoing discussion about git
> packaging.
>
>   Joachim
>

Bug#944329: debian-policy: Unclear text about password files modifications

[Sean Whitton]

Hello,

On Fri 08 Nov 2019 at 01:18AM +01, Guillem Jover wrote:

> There's this text in section §9.2.1:
>
>   ,---
>   Packages other than "base-passwd" must not modify "/etc/passwd",
>   "/etc/shadow", "/etc/group" or "/etc/gshadow".
>   `---
>
> It's not clear to me, whether this refers to the packaging or any
> program provided by that package. Depending on the reading this
> would make the passwd package buggy. So it might be worth clarifying
> probably by adding "passwd" to the exception.

Makes sense to me.  Perhaps you could propose a patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944360: Proposal for lua-lpeg src pkg modernisation

[Eric Desrochers]

Dear maintainers,

Here's a proposal to modernise the lua-lpeg package. No more lintian 'W:'
reported.


bug944360.debdiff
Description: Binary data

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Sean Whitton]

Hello,

On Thu 07 Nov 2019 at 04:51PM -05, Nicholas D Steeves wrote:

> The full sentence in question is "This field should not be added
> solely for purposes other than satisfying license or DFSG requirements
> to provide full source code".
>
> "solely for purposes other than satisfying" is the problematic
> construction and should be rephrased for readability and clarity.
>
> I suggest replacing the whole sentence with "The purpose of this field
> is exclusively for cases where a package's license, or when DFSG
> requirements, necessitate its presence; Built-Using should not be used
> for any other purpose".  This is much more clear and it flows
> nicely into the next sentence "In particular, it should not be added
> solely to enable finding packages that should be rebuilt against newer
> versions of their build dependencies."

Thank you for this.  I agree that the sentence is unnecessarily hard to
read.  Perhaps you could propose a patch against policy.git.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940192: wine-development: msi regression, not installing dotnet35sp1

[Jens Reyer]

control: tags -1 + fixed-upstream

Hi

Hans Leidekker wrote https://bugs.winehq.org/show_bug.cgi?id=47724#c22
> This might be fixed by cce9a5f124ae6d3fffcc7772cab6523f09a1e3d1,
please test.

I rebuilt wine-development with upstream merged at
cce9a5f124ae6d3fffcc7772cab6523f09a1e3d1:

"winetricks dotnet35sp1" now worked.  So this will be fixed in 4.20-1.

Please report upstream if this also fixes the
Office 2007 SP3 installer.

Greets
jre

Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Wed, Nov 06, 2019 at 09:44:59PM -0800, Dima Kogan wrote:
> Hi.
> 
> It looks like the elpa-gnuplot-mode package is missing some of the
> debiany emacs machinery: the files in
> 
>   /usr/lib/emacsen-common/packages/...
> 
> Somebody should look at the packaging, and figure out what we're missing
> and add it. Likely it's just a line or two somewhere.

Hi,

Having played with gnuplot-mode before (but not with elpa) I have been
digging into this problem, which is not Emacs26 related.

Original problem seems to be a bogus hyphen in debian/rules that completely
disables the elpa machinery, so problem went undetected. It really took me
a while to spot this problem.

I also added a debian/gnuplot-mode-pkg.el file and fine tuned
elpa-gnuplot-mode.elpa to include it and be more selective regarding files
to install.

Once this is done I noticed that package did not pass the tests because
gnuplot package was missing at that time, so I added it to Build-Deps.

I finally added elpa-gnuplot-mode.emacsen-startup to keep the .gp -> gnuplot
mode association in Emacs auto-mode-alist.

I am attaching three git patches dealing with the above.

Hope they help

-- 
Agustin
>From 1c6e992136fb5c33f28ee74e6992387a9bfa91d0 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:09:19 +0100
Subject: [PATCH 1/3] Modify to work better with elpa.

* debian/rules: Remove bogus hyphen
* debian/gnuplot-mode-pkg.el: Create
* debian/elpa-gnuplot-mode.elpa: Rename from gnuplot-mode.elpa and modify
  to include install contents and gnuplot-mode-pkg.el.
* debian/install: Remove. No longer needed.
---
 debian/elpa-gnuplot-mode.elpa | 4 
 debian/gnuplot-mode-pkg.el| 5 +
 debian/gnuplot-mode.elpa  | 1 -
 debian/install| 3 ---
 debian/rules  | 2 +-
 5 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 debian/elpa-gnuplot-mode.elpa
 create mode 100644 debian/gnuplot-mode-pkg.el
 delete mode 100644 debian/gnuplot-mode.elpa
 delete mode 100644 debian/install

diff --git a/debian/elpa-gnuplot-mode.elpa b/debian/elpa-gnuplot-mode.elpa
new file mode 100644
index 000..cd726c7
--- /dev/null
+++ b/debian/elpa-gnuplot-mode.elpa
@@ -0,0 +1,4 @@
+gnuplot.el
+gnuplot-gui.el
+gnuplot-context.el
+debian/gnuplot-mode-pkg.el
diff --git a/debian/gnuplot-mode-pkg.el b/debian/gnuplot-mode-pkg.el
new file mode 100644
index 000..8b98b6e
--- /dev/null
+++ b/debian/gnuplot-mode-pkg.el
@@ -0,0 +1,5 @@
+(define-package
+  "gnuplot-mode"
+  "50"
+  "Emacs gnuplot mode"
+  nil)
diff --git a/debian/gnuplot-mode.elpa b/debian/gnuplot-mode.elpa
deleted file mode 100644
index abf136d..000
--- a/debian/gnuplot-mode.elpa
+++ /dev/null
@@ -1 +0,0 @@
-*.el
diff --git a/debian/install b/debian/install
deleted file mode 100644
index 4463e0a..000
--- a/debian/install
+++ /dev/null
@@ -1,3 +0,0 @@
-gnuplot.el usr/share/emacs/site-lisp/gnuplot-mode
-gnuplot-gui.el usr/share/emacs/site-lisp/gnuplot-mode
-gnuplot-context.el usr/share/emacs/site-lisp/gnuplot-mode
diff --git a/debian/rules b/debian/rules
index ffea5e3..bb43d84 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-	dh $@ --with-elpa
+	dh $@ --with elpa
 
 override_dh_auto_build:
 	$(if $(filter nodoc,$(DEB_BUILD_OPTIONS)),true,make -f Makefile.dst gpelcard.pdf)
-- 
2.24.0.rc1

>From a019516e49055cc424a624bf076874e2e3ee9e48 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:26:14 +0100
Subject: [PATCH 2/3] debian/control: Build depend on gnuplot, to allow tests
 being actually passed.

---
 debian/control | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 8d96b1f..29411f8 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,11 @@ Section: lisp
 Priority: optional
 Maintainer: Debian Emacs addons team 
 Uploaders: Dima Kogan 
-Build-Depends: debhelper (>= 10), dh-elpa (>= 0.0.17), texlive-latex-base, texlive-latex-recommended
+Build-Depends: debhelper (>= 10),
+	   dh-elpa (>= 0.0.17),
+	   texlive-latex-base,
+	   texlive-latex-recommended,
+	   gnuplot
 Standards-Version: 4.3.0
 Vcs-Git: https://salsa.debian.org/debian/gnuplot-mode.git
 Vcs-Browser: https://salsa.debian.org/debian/gnuplot-mode
-- 
2.24.0.rc1

>From 0b7604f0e336f69f9b9bcb08a2e66dbf408b5dc3 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:41:06 +0100
Subject: [PATCH 3/3] elpa-gnuplot-mode.emacsen-startup: Add auto-mode-alist
 entry for .gp->gnuplot-mode association.

Based on old one, but with path and autoload handling removed.
---
 debian/elpa-gnuplot-mode.emacsen-startup | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 debian/elpa-gnuplot-mode.emacsen-startup

diff --git a/debian/elpa-gnuplot-mode.emacsen-startup b/debian/elpa-gnuplot-mode.emacsen-startup
new file mode 100644
index 000..2b83d62
--- /dev/null
+++