date:20200707

tag 964471 - moreinfo

tag 964471 - unreproducible

Hi,

Am 07.07.20 um 23:05 schrieb Evgeny Kapun:
> On 07.07.2020 22:40, Rene Engelhard wrote:
>> Even that worked for me in said testing VM "upgraded" to unstable with
>> your apt-get --with-new-pkgs upgrade.
>>
>> libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept
>> back.
>
> After some testing, I found out that you also need to pass
> `--no-install-recommends`, as otherwise `Recommends: libreoffice-core
> (>> 1:7.0.0~rc1)` in libreoffice-l10n-ru prevents it from upgrading.
>
Ah, yes, indeed.

Regards,


Rene

Bug#958024: ITP: openapi-spec-validator -- OpenAPI Spec Validator is a Python library that validates OpenAPI Specs

2020-07-07 Thread merkys

Hello,

On Fri, 17 Apr 2020 14:47:32 + Joachim Langenbach  wrote:

> The openapi-spec-validator is needed for connexion, which is my final goal of 
> packaging.
> Connexion is a python-library, which uses flask to server openapi defined 
> webservices.
> The following packages are needed on top of the ones already listed in debian:
> * python3-connexion
> * python3-clickclick
> * python3-openapi-spec-validator
> * python3-pytest-aiohttp
> * python3-swagger-ui-bundle
> * python3-pytest-flake8 (s. Bug #894786)
> I already packaged all of this packages and will upload them one after 
> another.

What is the status of the openapi-spec-validator and its dependencies? I am 
really interested in seeing it in Debian. Could you please upload your 
packaging of the above mentioned packages to salsa.debian.org?

Best,
Andrius

Bug#964499: Kernel panic with 5.7.0-1 & i7-9800X

2020-07-07 Thread Andrei POPESCU

Control: reassign -1 linux-image-5.7.0-1-amd64

On Ma, 07 iul 20, 21:05:47, Dean Loros wrote:
> Package: linux-image
> 
> Version: 5.7.0-1-amd64
> 
> 
> After I updated my system with an i7-9800X, the system would no longer
> boot. At first the system would hang at GDM with no keybopard or mouse
> input.
> I noted that there was a microcode update & applied it. After that,
> the system will get almost to GDM & kernel panic.
> 
> I have tried both 5.6.0-2 & 5.7.0-1 with the same results. Kernels
> earlier than 5.6.0-2 will boot normally, this includes 5.6.0-1 & the
> 4.19-X series.
> 
> This problem happened after the CPU upgrade, the prior CPU (i7-7800X)
> booted normally with all kernels installed on my system but this was
> with the prior microcode, as I can not test that CPU with the current
> microcode.
> 
> 
> For some reason I have problems with Reportbug, so I have reported
> this way. Please advise of any other information needed.
> 
> 
> 
> -- 
> Cheers!!!
> Dean Loros
> Performance by Design Ltd.
> autocrosser at http://forums.linuxmint.com
> debianmainuser at http://forums.debian.net



-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)

2020-07-07 Thread Paul Wise

On Sun, Jun 28, 2020 at 2:36 AM Boian Bonev wrote:

>   iotop-c - simple top-like I/O monitor (implemented in C)

I am willing to sponsor this.

Some issues that I think need to be fixed before uploading:

Please comply with Debian Policy about build verbosity:

https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please fix these lintian warnings:

I: iotop-c: hardening-no-bindnow usr/sbin/iotop-c

Please fix the cppcheck warning-level complaints. While looking at the
pw_name warning, I noticed that the same pattern occurs in both
view_batch and view_curses but cppcheck doesn't detect the two
occurrences in view_curses for some reason.

Some issues that would be nice to fix:

I know that GNU Make has some default rules that could make most of
the Makefile unnecessary, but I wonder if other Make implementations
also have enough of them so that you could actually rely on the
default rules.

Please wrap and sort the debian/ packaging files, this makes packaging
diffs easier to read.

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

Please include copyright holder information and license grants in each
of the source files. SPDX is a standard machine-readable way to do
that.

https://lu.is/blog/2012/03/17/on-the-importance-of-per-file-license-information/
https://spdx.org/

Please replace COPYING with the canonical version of the GPLv2:

https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

Please fix any of the easy-to-fix lintian complaints. I'm not sure
what is correct for the conflicts, but you could test using piuparts
if using breaks is enough or if using conflicts is really needed. I
assume you'll want to keep debhelper compat 12 for backportability.
Look up the tag names on lintian.d.o or using `lintian-info -t` for
descriptions of the tags.

I: iotop-c: conflicts-with-version iotop (<= 0.6-24-g733f3f8-1)
I: iotop-c source: debian-watch-contains-dh_make-template 
I: iotop-c source: testsuite-autopkgtest-missing
X: iotop-c source: debian-watch-does-not-check-gpg-signature
P: iotop-c source: maintainer-manual-page debian/iotop-c.alternatives-dh13.1
P: iotop-c source: maintainer-manual-page debian/iotop.8
P: iotop-c source: package-uses-old-debhelper-compat-version 12
X: iotop-c source: upstream-metadata-file-is-missing

The following tools run by check-all-the-things produce some probably
actionable complaints:

blhc
mandoc
wrap-and-sort
cppcheck

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#964458: checkinstall: causes segfault of cmake

2020-07-07 Thread Stephen Gelman

Perfect, thanks. I will take a look and see what I can do. I will warn
you that the original developer of checkinstall doesn't seem
interested in the project anymore so any fix will be limited to
anything I or any other Debian contributor can figure out so no
promises that this will be able to be fixed promptly.

Stephen

On Tue, Jul 7, 2020 at 7:30 PM Jiri Palecek  wrote:
>
> Hello,
>
> On 07. 07. 20 17:11, Stephen Gelman wrote:
> > On Jul 7, 2020, at 9:42 AM, Jiri Palecek  wrote:
> >> Package: checkinstall
> >> Version: 1.6.2+git20170426.d24a630-2
> >> Severity: important
> >> File: /usr/bin/installwatch
> >>
> >> Dear Maintainer,
> >>
> >> while trying to use checkinstall to create a debianized package from a
> >> cmake based source, the build failed with a segfault. These are linked
> >> to installwatch and don't happen without it:
> >>
> >> $ installwatch make cmake_check_build_system
> >>
> >> INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H
> >>
> >> make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup 
> >> do paměti (SIGSEGV) (obraz paměti uložen)
> >>
> >> There is a backtrace of the crash, which indicates it happens early in
> >> the initialization of cmake around a stat call:
> >>
> >> (gdb) bt
> >> #0  0x in ?? ()
> >> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> >> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> >> #2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
> >> #3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
> >> ../../lib/global.c:387
> >> #4  0xb6a25950 in lib_init () at ../../lib/global.c:511
> >> #5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
> >> argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
> >> #6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, 
> >> l=) at dl-init.c:30
> >> #7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
> >> env=0xbfe33e80) at dl-init.c:119
> >> #8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
> >> (gdb) frame 1
> >> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> >> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> >> 455   return __xstat (_STAT_VER, __path, __statbuf);
> >>
> >> Why did it end up with EIP=0 I don't know.
> >>
> >> It seems there's some incompatibility between installwatch's LD_PRELOAD
> >> and glibc.
> >>
> >> Could you have a look at it?
> >>
> >> Regards
> >> Jiri Palecek
> > Jiri,
> >
> > Thanks for the report. In order to help me narrow this down are you able to 
> > provide a simple test case to reproduce the problem?
>
> I don't know if it's simple, but here goes. In an empty directory:
>
> $ touch CMakeLists.txt
>
> $ cmake .
>
> $ installwatch cmake .
>
>
> The last line crashes on my system.
>
> Regards
>
>  Jiri Palecek

Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64

2020-07-07 Thread Ben Hutchings

Control: reassign -1 src:linux
Control: tag -1 moreinfo

On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote:
> Package: linux-signed-amd64
> Version: 4.19.0-9-amd64
> 
> We've had two separate reports now of debian buster users running
> 4.19.0-9-amd64 who experienced serious file system corruption.

Which version?  (I.e. what does "uname -v" or
"dpkg -s linux-image-4.19.0-9-amd64" say?)

> - Both were using ext3
> - Both are running Xen HVM, but I do not have reason to believe this to be 
> related

I have no reason to assume that this is unrelated to the hypervisor, so
please report the version of Xen and whatever provides the back-end
block driver.

> - Both are on distinct physical hosts
> - Both had upgraded from an older non 4.19 kernel within the last two or 
> three weeks

From which older versions?

> One user had the error:
> 
> ext4-fs error (device xvda1): ext4_validate_block_bitmap:393: comm cat: bg 
> 812: block 26607617: invalid block bitmap
> aborting journal on device xvda1-8
> ext4-fs error (device xvda1): ext4_journal_check_start:61: Detected abnormal 
> journal
> ext4-fs (xvda1): Remounting filesystem read-only
> ext4-fs (xvda1): Remounting filesystem read-only
> ext4-fs error (device xvda1) in ext4_orphan_add:2863: Journal has aborted

And were there any other error messages, e.g. relating to I/O errors,
around the same time?  How about in the back-end domain?

> The other gave us the output of tune2fs -l:
[...]

Looks like a fairly ordinary ext3 filesystem.  It doesn't tell us
anything about what went wrong.

In general I would advise against continued use of the ext3 format.  It
should continue to be supported by the ext4 code, but it is inevitably
going to be less well-tested than the ext4 format.  So far as I can
remember, it is easy to upgrade in-place.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg

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

Bug#964362: chromium crash frequently, SEGV_MAPERR

2020-07-07 Thread laalaa laalaa

Source: chromium
Version: 83.0.4103.116-1~deb10u2
Followup-For: Bug #964362

Dear Maintainer,

Frequent crash still occurred after upgrade from 83.0.4103.116-1~deb10u1 to 
~deb10u2.  Crash occurs after executing chromium for few minutes.  Slow 
responsiveness found from 83..debu10u1 did not occur in this version.

Command:
/usr/bin/chromium --proxy-server="X.X.X.X:X" 
--proxy-bypass-list="X.X.*;X.X.*;*.X" --disk-cache-dir=/dev/null

Error log:
[9545:9545:0708/100337.163855:ERROR:sandbox_linux.cc(374)] InitializeSandbox() 
called with multiple threads in process gpu-process.
[9506:9561:0708/100337.177992:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/js
[9506:9562:0708/100337.178131:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/wasm
[9506:9561:0708/100337.193285:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/js
[9506:9562:0708/100337.193285:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/wasm
[9506:9561:0708/100337.193321:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Code Cache/js
[9506:9562:0708/100337.193331:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Code 
Cache/wasm
[9506:9527:0708/100337.275442:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/js
[9506:9529:0708/100337.275452:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/wasm
[9506:9527:0708/100337.275485:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/js
[9506:9529:0708/100337.275493:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Code Cache/wasm
[9506:9527:0708/100337.275494:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Code Cache/js
[9506:9529:0708/100337.275507:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Code 
Cache/wasm
[9550:9630:0708/100337.294177:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Cache
[9550:9630:0708/100337.294308:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Cache
[9550:9630:0708/100337.294328:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Cache
[9550:9629:0708/100337.294541:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Cache
[9550:9629:0708/100337.294580:ERROR:simple_backend_impl.cc(81)] Failed to 
create directory: /dev/null/Profile 2/Cache
[9550:9629:0708/100337.294589:ERROR:simple_backend_impl.cc(757)] Simple Cache 
Backend: wrong file structure on disk: 1 path: /dev/null/Profile 2/Cache
[9550:9616:0708/100337.303063:ERROR:disk_cache.cc(184)] Unable to create cache
[9506:9506:0708/100337.305955:ERROR:disk_cache.cc(184)] Unable to create cache
[9506:9506:0708/100337.305995:ERROR:disk_cache.cc(184)] Unable to create cache
[9506:9528:0708/100346.855696:ERROR:connection_factory_impl.cc(420)] Failed to 
connect to MCS endpoint with error -111
[9506:9528:0708/100915.111885:ERROR:socket_stream.cc(218)] Closing stream with 
result -2
[9506:9528:0708/100915.118034:ERROR:connection_factory_impl.cc(420)] Failed to 
connect to MCS endpoint with error -111
Received signal 11 SEGV_MAPERR 7f01c431fad7
#0 0x564a040cc469 (/usr/lib/chromium/chromium+0x51f9468)
#1 0x564a0402a193 (/usr/lib/chromium/chromium+0x5157192)
#2 0x564a040cbff1 (/usr/lib/chromium/chromium+0x51f8ff0)
#3 0x7ff2ed488730 (/lib/x86_64-linux-gnu/libpthread-2.28.so+0x1272f)
#4 0x7ff2e7394d48 (/lib/x86_64-linux-gnu/libc-2.28.so+0x7fd47)
#5 0x7ff2e7397a58 (/lib/x86_64-linux-gnu/libc-2.28.so+0x82a57)
#6 0x7ff2e739956a __libc_malloc
#7 0x564a040e3bee operator new()
#8 0x7ff2e760e3cd std::__cxx11::basic_string<>::reserve()
#9 0x7ff2e7602845 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7ff2e760c9cb std::basic_streambuf<>::xsputn()
#11 0x7ff2e75fdb34 std::__ostream_insert<>()
#12 0x564a040cc7b9 (/usr/lib/chromium/chromium+0x51f97b8)
#13 0x564a040cc844 (/usr/lib/chromium/chromium+0x51f9843)
#14 0x564a0403c9d2 (/usr/lib/chromium/chromium+0x51699d1)
#15 0x564a0403eb1e (/usr/lib/chromium/chromium+0x516bb1d)
#16 0x564a027a762a (/usr/lib/chromium/chromium+0x38d4629)
#17 0x564a027a767e (/usr/lib/chromium/chromium+0x38d467d)
#18 0x564a01e4d98f (/usr/lib/chromium/chromium+0x2f7a98e)
#19 0x564a02761559 (/usr/lib/chromium/chromium+0x388e558)
#20 0x564a0276179e (/usr/lib/chromium/chromium+0x388e79d)
#21 0x564a027aae67 (/usr/lib/chromium/chromium+0x38d7e66)
#22 0x564a027d6ac2 (/usr/lib/chromium/chromium+0x3903ac1)
#23 0x564a027d6d7e (/usr/lib/chromium/chromium+0x3903d7d)
#24

Bug#964498: ITP: luastatus -- Universal status bar content generator

2020-07-07 Thread Viktor Krapivenskiy

Package: wnpp
Severity: wishlist
Owner: shdownn...@gmail.com

* Package name: luastatus
  Version : 0.5.0
  Upstream Author : Viktor Krapivenskiy 
* URL : https://github.com/shdown/luastatus
* License : LGPL-3.0+
  Programming Lang: C
  Description : Universal status bar content generator

luastatus is a universal status bar content generator.  It allows the
user to configure the way the data from event sources is processed and
shown, with Lua.  Its main feature is that the content can be updated
immediately as some event occurs.

It also avoids heavy forking, which is also a common issue of status bar
content generators, affecting performance and power consumption.

It supports i3bar, lemonbar, dwm bar, and more.

Upstream repository includes debian/ directory with build scripts.

I need a sponsor to upload the packages.

Bug#964497: ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol

2020-07-07 Thread Pablo Mestre

Package: wnpp
Severity: wishlist
Owner: Pablo Mestre Drake 
Control: block 963605 by -1
Control: block 946035 by -1
Control: block 946451 by -1

* Package name    : python-jsonrpc-server
  Version       : 0.3.4
  Upstream Author  : Palantir Technologies, Inc 
* URL : https://github.com/palantir/python-jsonrpc-server
* License  : MIT
  Programming Lang: Python
  Description       : JSON-RPC is a stateless, light-weight remote
procedure call (RPC) protocol

 A Python 2.7 and 3.4+ server implementation of
 the JSON RPC 2.0 protocol. This library has been pulled out
 of the Python Language Server project.

 Required in order to upgrade the popular Python IDE Spyder to its
 latest version.

Bug#942367: openipmi: Bashisms in init script

2020-07-07 Thread Sergio Durigan Junior

Control: merge -1 920461

On Tuesday, November 06 2018, Sam Morris wrote:

> /etc/init.d/openipmi uses /bin/sh but uses some features that require
> bash:
>
> $ checkbashisms debian/openipmi.init 
> possible bashism in debian/openipmi.init line 55 (should be 'b = a'):
> if [ "${kernel}" == "2.4" ]; then
> possible bashism in debian/openipmi.init line 202 ($"foo" should be 
> eval_gettext "foo"):
>   log_begin_msg $"Starting ipmi_watchdog driver: "
> possible bashism in debian/openipmi.init line 213 ($"foo" should be 
> eval_gettext "foo"):
>   log_begin_msg $"Stopping ipmi_watchdog driver: "
> possible bashism in debian/openipmi.init line 245 (should be 'b = a'):
>   if [ "${IPMI_POWERCYCLE}" == "yes" ]; then
>
> Per policy sec. 10.4:
>
> If a shell script requires non-POSIX.1-2017 features from the shell
> interpreter other than those listed above, the appropriate shell
> must be specified in the first line of the script (e.g.,
> #!/bin/bash) and the package must depend on the package providing
> the shell (unless the shell package is marked “Essential”, as in the
> case of bash).

Thanks for the report.  This bug can be merged with 920461.  I'm
preparing a release to address them.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#769066: lintian: Consider processing files in disk order

2020-07-07 Thread Felix Lechner

Hi,

> access files in disk order to increase performance

What was the speedup in man-db and dpkg, please?

Kind regards
Felix Lechner

Bug#964496: libjson-validator-perl: License known for cache files

2020-07-07 Thread tuxayo/Victor Grousset

Package: libjson-validator-perl
Version: 3.25+dfsg-1+koha3
Severity: normal

Dear Maintainer,

https://salsa.debian.org/perl-team/modules/packages/libjson-validator-perl/-/raw/master/debian/copyright
> Comment: The +dfsg version is created by removing the cache files from the
> lib/JSON/Validator directory, where the license is unknown.

This causes malfunction when there is no internet access or when swagger.io 
(where the schemas are hosted) is down.

But actually excluding the files from the package doesn't seem necessary.
I got a confirmation[1] that they[2] are under Apache-2.0 license.

[1] https://github.com/OAI/OpenAPI-Specification/issues/2280
[2] example, one of them: 
https://github.com/OAI/OpenAPI-Specification/blob/master/schemas/v2.0/schema.json

Cheers,

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

Kernel: Linux 5.7.7-arch1-1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libjson-validator-perl depends on:
ii  libmojolicious-perl  8.12+dfsg-1.2~koha1
ii  perl 5.28.1-6

Versions of packages libjson-validator-perl recommends:
ii  libcpanel-json-xs-perl4.09-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.27-1
ii  libnet-idn-encode-perl2.500-1
ii  libyaml-libyaml-perl  0.76+repack-1

libjson-validator-perl suggests no packages.

-- no debconf information

Bug#964441: geeqie: No image is rendered, only white rectangle visible

2020-07-07 Thread Paul Wise

Control: forwarded -1 https://github.com/BestImageViewer/geeqie/issues/539
Control: retitle -1 geeqie: No image is rendered, only white rectangle visible 
under GNOME Wayland
Control: tags -1 + patch
Control: usertags -1 + wayland

On Tue, 07 Jul 2020 12:19:13 +0200 Florian wrote:

> No image is shown, instead only a white rectangle is visible.

I'm getting this too. 

> I am on gnome/wayland.

I've tested GNOME Xorg and it does not have this issue, retitling.

> Might be this one: 
https://github.com/BestImageViewer/geeqie/issues/539

Marking as forwarded.

It seems there is a patch that makes it work for GPU acceleration mode
but unfortunately not for software rendering mode.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#964495: libmicrohttpd: New 0.97.1-1 version causes libkiwix to FTBFS

2020-07-07 Thread Kunal Mehta

Package: libmicrohttpd
Version: 0.97.1-1
Severity: serious
Tags: ftbfs

The new 0.97.1 version is causing libkiwix to FTBFS.

[12/51] c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include 
-I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu 
-I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libkiwix-9.3.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-MD -MQ 'src/25a6634@@kiwix@sha/server.cpp.o' -MF 
'src/25a6634@@kiwix@sha/server.cpp.o.d' -o 
'src/25a6634@@kiwix@sha/server.cpp.o' -c ../src/server.cpp
FAILED: src/25a6634@@kiwix@sha/server.cpp.o 
c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include 
-I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu 
-I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libkiwix-9.3.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-MD -MQ 'src/25a6634@@kiwix@sha/server.cpp.o' -MF 
'src/25a6634@@kiwix@sha/server.cpp.o.d' -o 
'src/25a6634@@kiwix@sha/server.cpp.o' -c ../src/server.cpp
../src/server.cpp: In member function ‘bool kiwix::InternalServer::start()’:
../src/server.cpp:248:29: error: invalid conversion from ‘int (*)(void*, 
MHD_Connection*, const char*, const char*, const char*, const char*, size_t*, 
void**)’ {aka ‘int (*)(void*, MHD_Connection*, const char*, const char*, const 
char*, const char*, long unsigned int*, void**)’} to 
‘MHD_AccessHandlerCallback’ {aka ‘MHD_Result (*)(void*, MHD_Connection*, const 
char*, const char*, const char*, const char*, long unsigned int*, void**)’} 
[-fpermissive]
  248 | ,
  | ^~
  | |
  | int (*)(void*, MHD_Connection*, const 
char*, const char*, const char*, const char*, size_t*, void**) {aka int 
(*)(void*, MHD_Connection*, const char*, const char*, const char*, const char*, 
long unsigned int*, void**)}
In file included from ../src/server.cpp:39:
/usr/include/microhttpd.h:2428:45: note:   initializing argument 5 of 
‘MHD_Daemon* MHD_start_daemon(unsigned int, uint16_t, MHD_AcceptPolicyCallback, 
void*, MHD_AccessHandlerCallback, void*, ...)’
 2428 |   MHD_AccessHandlerCallback dh, void *dh_cls,
  |   ~~^~


Upstream libkiwix ticket discussing the issue is
https://github.com/kiwix/kiwix-lib/issues/373, but I (and upstream) believe
this is an unexexpected breaking change in libmicrohttpd.

-- Kunal

Bug#964244: stretch-pu: package xml-security-c/1.7.3-4+deb9u2

2020-07-07 Thread wferi

"Adam D. Barratt"  writes:

> Please go ahead, bearing in mind that the window for getting fixes into
> the final stretch point release closes this weekend.

Thanks, uploaded.
-- 
Feri

Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64

2020-07-07 Thread Sarah Newman


Package: linux-signed-amd64
Version: 4.19.0-9-amd64

We've had two separate reports now of debian buster users running 
4.19.0-9-amd64 who experienced serious file system corruption.

- Both were using ext3
- Both are running Xen HVM, but I do not have reason to believe this to be 
related
- Both are on distinct physical hosts
- Both had upgraded from an older non 4.19 kernel within the last two or three 
weeks

One user had the error:

ext4-fs error (device xvda1): ext4_validate_block_bitmap:393: comm cat: bg 812: 
block 26607617: invalid block bitmap
aborting journal on device xvda1-8
ext4-fs error (device xvda1): ext4_journal_check_start:61: Detected abnormal 
journal
ext4-fs (xvda1): Remounting filesystem read-only
ext4-fs (xvda1): Remounting filesystem read-only
ext4-fs error (device xvda1) in ext4_orphan_add:2863: Journal has aborted

The other gave us the output of tune2fs -l:

tune2fs 1.44.5 (15-Dec-2018)
Last mounted on: /
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype 
needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4700160
Block count: 9437183
Reserved block count: 471048
Free blocks: 6164372
Free inodes: 4479367
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 730
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16320
Inode blocks per group: 510
Filesystem created: Thu Apr 26 19:55:21 2012
Last mount time: Tue Jul 7 15:11:46 2020
Last write time: Tue Jul 7 15:11:45 2020
Mount count: 1
Maximum mount count: 26
Last checked: Tue Jul 7 15:10:50 2020
Check interval: 15552000 (6 months)
Next check after: Sun Jan 3 14:10:50 2021
Lifetime writes: 10 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 1224109
Default directory hash: tea
Directory Hash Seed: 77ef7ea3-5e01-4e55-b3da-3036769fb64b
Journal backup: inode blocks

--Sarah

Bug#964458: checkinstall: causes segfault of cmake

2020-07-07 Thread Jiri Palecek


Hello,

On 07. 07. 20 17:11, Stephen Gelman wrote:

On Jul 7, 2020, at 9:42 AM, Jiri Palecek  wrote:

Package: checkinstall
Version: 1.6.2+git20170426.d24a630-2
Severity: important
File: /usr/bin/installwatch

Dear Maintainer,

while trying to use checkinstall to create a debianized package from a
cmake based source, the build failed with a segfault. These are linked
to installwatch and don't happen without it:

$ installwatch make cmake_check_build_system

INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H

make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do 
paměti (SIGSEGV) (obraz paměti uložen)

There is a backtrace of the crash, which indicates it happens early in
the initialization of cmake around a stat call:

(gdb) bt
#0  0x in ?? ()
#1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
#2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
#3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
../../lib/global.c:387
#4  0xb6a25950 in lib_init () at ../../lib/global.c:511
#5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
#6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, l=) at dl-init.c:30
#7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
env=0xbfe33e80) at dl-init.c:119
#8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
(gdb) frame 1
#1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
455   return __xstat (_STAT_VER, __path, __statbuf);

Why did it end up with EIP=0 I don't know.

It seems there's some incompatibility between installwatch's LD_PRELOAD
and glibc.

Could you have a look at it?

Regards
Jiri Palecek

Jiri,

Thanks for the report. In order to help me narrow this down are you able to 
provide a simple test case to reproduce the problem?


I don't know if it's simple, but here goes. In an empty directory:

$ touch CMakeLists.txt

$ cmake .

$ installwatch cmake .


The last line crashes on my system.

Regards

    Jiri Palecek

Bug#964444: systemd-timesyncd: time synchronization suddenly stopped working

2020-07-07 Thread Vincent Lefevre

On 2020-07-07 23:59:06 +0200, Michael Biebl wrote:
> Am 07.07.20 um 12:58 schrieb Vincent Lefevre:
> > Package: systemd-timesyncd
> > Version: 245.6-1
> > Severity: important
> > 
> > systemd-timesyncd no longer seems to work. I couldn't find any
> > reason in the logs. Now there's a 5-second delta!
> > 
> > zira:~> timedatectl timesync-status
> >Server: (null) (3.debian.pool.ntp.org)   
> > Poll interval: 34min 8s (min: 32s; max 34min 8s)
> >  Leap: normal   
> >   Version: 4
> >   Stratum: 2
> > Reference: 596DFB17 
> > Precision: 1us (-24)
> > Root distance: 40.580ms (max: 5s)   
> >Offset: -1.087495s   
> 
> For smaller offset likes this one, timesyncd will adjust the time gradually.
> I don't see anything in the logs which would show that timesyncd is not
> working.

I don't know what this offset means, but this does not explain the
5-second difference with other machines.

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

Bug#770418: mawk: integer output from printf within awk limited to signed 32 bits

2020-07-07 Thread Thomas Dickey

On Mon, Jan 27, 2020 at 07:25:04PM +0100, Guillem Jover wrote:
> Control: tags -1 - unreproducible moreinfo
> 
> On Sun, 2020-01-26 at 20:25:46 +0100, Andreas Henriksson wrote:
> > Control: tags -1 + unreproducible moreinfo
> 
> > I did a quick attempt at reproducing this but failed to do so with
> > the current version in unstable.
> > 
> > $ find ~/Downloads/ -ls -type f | awk 'BEGIN{ ttl=0 }{ ttl+=$7 }END{
> > print ttl }'
> > 18945235595
> > $ du -sh ~/Downloads/
> > 18G /home/ah/Downloads/
> > 
> > Possibly the bug has been fixed since the original bug report, but
> > it seems unlikely as it's the same upstream version still.
> > Probably a better testcase to easily be able to reproduce this issue
> > is needed, so tagging accordingly...
> 
> Are you sure you were testing mawk instead of say gawk? It reproduces
> for me here:
> 
>   $ mawk -- 'BEGIN{ttl=2^48;printf("%i\n",ttl)}'2147483647
>   $ gawk -- 'BEGIN{ttl=2^48;printf("%i\n",ttl)}'281474976710656

I don't see that here.  mawk uses double's for floating point (no 64-digit
arithmetic).  That's perhaps not as clear as one might wish in the manpage:

   2. Data types, conversion and comparison
   There are two basic data types, numeric and string.  Numeric  constants
   can  be  integer  like -2, decimal like 1.08, or in scientific notation
   like -1.1e4 or .28E-3.  All numbers are represented internally and  all
   computations  are  done  in floating point arithmetic.  So for example,
   the expression 0.2e2 == 20 is true and true is represented as 1.0.

But gawk's manual (more than twice as long) gives no insight;
original-awk's man (less than twice as long) likewise is uninformative.

Back to the point: mawk's not using plain integers in the given example.

I ran that example (with a larger directory) using mawk, gawk, original-awk
(on Debian 64-bits):

** mawk
2.61152e+11
** gawk
261151514660
** original-awk
261151514660

and the equivalent on my FreeBSD 11 32-bit machine ("awk" is original-awk):

** awk
261151514660
** mawk
2.61152e+11
** gawk
261151514660

(I dropped Debian 32-bits because it was too unstable).  Those gave me
the same results, as you can see.  Whether mawk should print large
numbers in floating point doesn't appear to be the issue here.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature

Bug#964288: override: debichem

2020-07-07 Thread Sean Whitton

Hello,

On Sun 05 Jul 2020 at 01:14AM -04, Sandro Tosi wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Hello,
> could you please apply these changes:
>
> dak override debichem-cheminformatics metapackages # from 'debichem'
> dak override debichem-visualisation metapackages # from 'debichem'
> dak override debichem-view-edit-2d metapackages # from 'debichem'
> dak override debichem-semiempirical metapackages # from 'debichem'
> dak override debichem-modelling metapackages # from 'debichem'

Done all except the last which seems not to exist.

> (as requested in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# )

I got a bit confused here -- please put the old section, not the source
package name, at the end of the lines.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964288: override: debichem

2020-07-07 Thread Sean Whitton

Hello Sandro,

On Tue 07 Jul 2020 at 04:34PM -04, Sandro Tosi wrote:

> they are indeed metapackages.

This is what I wanted to know :)

> Is there any specific reason for pushing back on this request?

No.  But if ftpteam members were just to always process override request
without asking why they're needed, we might as well program dak to
automatically update sections when the control file changes.

-- 
Sean Whitton

signature.asc
Description: PGP signature

Bug#964492: RFS: emacs-wgrep/2.3.2+9.gf0ef9bf-1 [ITP] -- edit multiple Emacs buffers using a master grep pattern buffer

2020-07-07 Thread Nicholas D Steeves

Package: sponsorship-requests
Severity: normal
Justification: blocks importing the latest upstream release of Ivy
Control: block 944986 by -1

Dear mentors,

I am looking for a sponsor for my package "emacs-wgrep"

 * Package name: emacs-wgrep
   Version : 2.3.2+9.gf0ef9bf-1
   Upstream Author : Masahiro Hayashi 
 * URL : https://github.com/mhayashi1120/Emacs-wgrep
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/emacsen-team/emacs-wgrep
   Section : editors

It builds these binary packages:

  elpa-wgrep - edit multiple Emacs buffers using a master grep pattern buffer
  elpa-wgrep-ack - edit multiple Emacs buffers using a master ack pattern buffer
  elpa-wgrep-ag - edit multiple Emacs buffers using a master ag pattern buffer
  elpa-wgrep-helm - edit multiple Emacs buffers with a helm-grep-mode buffer

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

  https://mentors.debian.net/package/emacs-wgrep

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-wgrep/emacs-wgrep_2.3.2+9.gf0ef9bf-1.dsc

For the option to sponsor from git, use:

  https://salsa.debian.org/emacsen-team/emacs-wgrep
  and git deborig

Changes since the last upload:

   * Initial release. (Closes: #944986)

Regards,
Nicholas

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

2020-07-07 Thread Nicholas D Steeves

Control: severity -1 normal
Justification: blocks importation of new emacs-ivy version


signature.asc
Description: PGP signature

Bug#963728: transition: protobuf

2020-07-07 Thread Sebastian Ramacher

Control: tags -1 + confirmed

On 2020-06-26 09:07:54 +0200, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> The new soname release of Protobuf is available in experimental for
> some time. Packages starting to need it, thus time for the transition.
> According to my testing, the only failing to build packages are mozc,
> onnx, vg, ignition-fuel-tools, ignition-transport and gazebo.
> Filed bugs for these and recently got a message[1] that another
> maintainer re-tested ignition-fuel-tools, ignition-transport and
> gazebo. A binNMU would be sufficient for these as well.
> The only remaining FTBFS packages are mozc, onnx and vg.

Let's do this one.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

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

2020-07-07 Thread Nicholas D Steeves

Hi Antoine,

On Sat, Dec 21, 2019 at 02:30:12PM -0500, anarcat wrote:
> On Sun, Nov 17, 2019 at 07:39:49PM -0500, Nicholas D Steeves wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Nicholas D Steeves 
> > Control: tag + moreinfo
> > 
> > Package name: emacs-wgrep
> > Version : 2.3.0
> > Upstream Author : Masahiro Hayashi 
> > URL : https://github.com/mhayashi1120/Emacs-wgrep
> > License : GPL-3+
> > Programming Lang: Emacs LISP
> > Description : edit multiple files simultaneously in Emacs using grep 
> > buffers--pattern editing
> 
> I heard through the grapevine (#debian-til, specifically) that there's a
> similar project for the silver searcher (ag):
> 
> https://github.com/syohex/emacs-helm-ag
> 

Thanks for the tip!  ISTM that ag.el, and counsel are more directly
comparable to helm-ag, but I've added this info to the elpa-wgrep-helm
description, and have queued the change for the -2 release :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#964491: RFP: python3-catboost -- Gradient boosting machine learning library

2020-07-07 Thread Federico Ceratto

Package: wnpp
Severity: wishlist

* Package name: python3-catboost
  Version : 0.23.2
  Upstream Author : CatBoost Authors
* URL : https://github.com/catboost/catboost
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : Gradient boosting machine learning library

CatBoost is an upcoming machine learning library based on gradien
boosting over decision trees. It has excellent prediction speed
compared to and supports numerical and categorical features.
It aims to provide good results with the default parameters.
CatBoost can run on CPUs and GPUs.

This RFP is for a Python3 package. The project also provides a
R package and a CLI tool.

Bug#962545: Invalid serial console blocks system boot

2020-07-07 Thread Guilherme G. Piccoli

I'm hereby also attaching the patch to the bug, in order more audience
has access to it, given BTS is the more generic way to report fixes in
Debian. Currently, there's a merge request in salsa with this fix [0].

Cheers,

Guilherme


[0] https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/30
From c3cbf35505d1767189e6ae4b9d906bcf12275bb4 Mon Sep 17 00:00:00 2001
From: "Guilherme G. Piccoli" 
Date: Mon, 8 Jun 2020 18:38:52 -0300
Subject: [PATCH] scripts/functions: Prevents printf error carry over if wrong
 console is set

Currently the _log_msg() functions is "void" typed - with no return -,
which in terms of shell means it returns whatever its last command
returns. This function is the basic building block for all error/warning
messages in initramfs-tools.

It was noticed [0] that in case of bad console is provided to kernel on
command-line, printf (and apparently all write()-related functions) returns
error, and so this error is carried over in _log_msg(). Happens that
checkfs() function has a loop that runs forever in this scenario (*if* fsck
is not present in initramfs, and obviously if "quiet" is not provided in the
command-line). The situation is easily reproducible and we can find various
reports dating back some years. The reports usually are of the form
"machine can't boot if wrong console is provided" or slightly different
forms of that, almost always relating serial consoles with boot issues.

This patch proposes a pretty simple fix: return zero on _log_msg().
We should definitely not brake the boot due to error log functions;
one could argue we could fix checkfs() and that's true, until eventually
we find another subtle corner case of "misuse" of the _log_msg() return
value (after some debugging), and fix that too, and so on...
W could also argue that printf shouldn't return error in this case,
and although a valid discussion, it's not worth to have users waiting
on a dilemma while boot is quite easy to brake, just by passing a wrong
kernel parameter (or having the underlying serial console device changed
to output to a different port than the previously set on kernel cmdline).

[0] bugs.launchpad.net/cloud-images/+bug/1573095/comments/46
Signed-off-by: Guilherme G. Piccoli 
---
 scripts/functions | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/functions b/scripts/functions
index db7c833a8356..d8fb0ca7be2b 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -5,6 +5,7 @@ _log_msg()
 	if [ "${quiet?}" = "y" ]; then return; fi
 	# shellcheck disable=SC2059
 	printf "$@"
+	return 0 # Prevents error carry over in case of unavailable console
 }
 
 log_success_msg()
-- 
2.27.0

Bug#964444: systemd-timesyncd: time synchronization suddenly stopped working

2020-07-07 Thread Michael Biebl

Am 07.07.20 um 12:58 schrieb Vincent Lefevre:
> Package: systemd-timesyncd
> Version: 245.6-1
> Severity: important
> 
> systemd-timesyncd no longer seems to work. I couldn't find any reason in the 
> logs.
> Now there's a 5-second delta!
> 
> zira:~> timedatectl timesync-status
>Server: (null) (3.debian.pool.ntp.org)   
> Poll interval: 34min 8s (min: 32s; max 34min 8s)
>  Leap: normal   
>   Version: 4
>   Stratum: 2
> Reference: 596DFB17 
> Precision: 1us (-24)
> Root distance: 40.580ms (max: 5s)   
>Offset: -1.087495s   

For smaller offset likes this one, timesyncd will adjust the time gradually.
I don't see anything in the logs which would show that timesyncd is not
working.




signature.asc
Description: OpenPGP digital signature

Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892

2020-07-07 Thread Craig Small

On Wed, 8 Jul 2020 at 01:48, Sylvain Beucler  wrote:

> On 07/07/2020 17:07, Sylvain Beucler wrote:
> > In any case, all of this happens between 5.7.3 and 5.8.pre1.
>
> Restricting further (good..bad):
>
> $ git shortlog
>
> 1a0dbe19bf2787bb5bea913f210a9a5eb4c0c80c..e207b8113260fd7d84df0ebdb66925ab70da29b2
> Robert Story (2):
>   Add VMware copyright
>   tweak sndMsgMaxSize handling
>
> VMwareDev Randy (4):
>   getbulk enhancements: limit responses gathered
>   reduce session msg max sizes to transport max
>   getbulk enhancements: response size + fallback to forward encoding
>   move v3 engineID probe into initial packet build
>
Thanks for doing this bisect. So the issue happened after 5.7.3 (this
change happened in 2015, 5.7.3 was released in 2014) which means we only
need to worry about unstable and testing.

 - Craig

Bug#830904: RFP: puppetserver -- the next-generation application for managing Puppet agents

2020-07-07 Thread Louis-Philippe Véronneau

On Tue, 12 Jul 2016 22:20:45 +0200 Mathieu Parent 
wrote:
> Package: wnpp
> Severity: wishlist
> Control: block -1 by 819811
> 
> * Package name: puppetserver
>   Version : 2.4
>   Upstream Author : Puppetlabs
> * URL : https://docs.puppet.com/puppetserver/latest/
> * License : Apache-2.0
>   Programming Lang: Clojure, Ruby
>   Description : the next-generation application for managing Puppet agents
> 
> Puppet Server is the next-generation application for managing Puppet agents. 
> This platform implements Puppet's server-side components in a more 
> distributed, service-oriented architecture. We've built Puppet Server on top 
> of the same technologies that make PuppetDB successful, and which allow us to 
> greatly improve performance, scalability, advanced metrics collection, and 
> fine-grained control over the Ruby runtime.
> 
> This package needs some additionnal dependencies, most of them needed by 
> puppetdb too (#673515).
> 
> It would also benefit from leiningen (#819811).
> 
> 

Work to package puppetserver is being tracked here:

https://wiki.debian.org/Teams/Puppet/Work#Puppet_Server

Help appreciated. Please coordinate with the Puppet Team on
#debian-puppet or on the team's mailing list.

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



signature.asc
Description: OpenPGP digital signature

Bug#964490: ITP: useful-clojure

2020-07-07 Thread Louis-Philippe Véronneau

Package: wnpp
Severity: wishlist
Owner: po...@debian.org


* Package name : useful-clojure
Version : 0.11.6
Upstream Author : Alan Malloy , Daniel Compton

* URL : https://github.com/clj-commons/useful
* License : EPL-1.0
Description : A collection of generally-useful Clojure utility functions.

This library is a prerequisite for packaging Puppet Server. I am
planning to maintain it in the Clojure Team.

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



signature.asc
Description: OpenPGP digital signature

Bug#964399: Should ganglia be removed?

2020-07-07 Thread Marcos Fouces

Hello Moritz

I did some work time ago on ganglia [1] but i never get this work
published due to unactive/unresponsive uploaders.

I also done some work on ganglia-web and ganglia-linux-modules packages
(also unpublished).

I believe that it is still a good piece of software that deserve its
place on Debian so i would like to step up as uploader (co-uploaders
welcome!) if needed.

I also would like to maintain it under pkg-security team umbrella.

Please, let me know your thoughs.

Greetings,
 
Marcos

[1] https://salsa.debian.org/mfouces-guest/ganglia



El lun, 06-07-2020 a las 20:12 +0200, Moritz Muehlenhoff escribió:
> Source: ganglia
> Severity: serious
> 
> Should ganglia be removed? It's dead upstream (last commits from over
> three years ago,
> last release from 2015), is now orphaned (last active maintainer is
> no longer a DD, but
> wasn't very actively maintained to begin with, the current packaged
> version is from 2013),
> most of the plugins depend on Python 2, there's unfixed security
> issues dating back to
> 2013 and doesn't even support ipv6 (730257).
> 
> Unless anyone steps up for maintenance (and partly becomes upstream),
> it should better
> be removed.
> 
> Cheers,
> Moritz
>

Bug#964489: ITP: ordered-clojure

2020-07-07 Thread Louis-Philippe Véronneau

Package: wnpp
Severity: wishlist


* Package name : ordered-clojure
Version : 1.5.9
Upstream Author : Alan Malloy , Daniel Compton

* URL : https://github.com/clj-commons/ordered/
* License : EPL-1.0
Description : ordered provides sets and maps that maintain the insertion
order of their contents for Clojure.

This library is a prerequisite for packaging Puppet Server.

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



signature.asc
Description: OpenPGP digital signature

Bug#850248: New upstream version available

2020-07-07 Thread Ian Jackson

Chris Hofstaedtler writes ("Bug#850248: New upstream version available"):
> * Ian Jackson  [200707 18:46]:
> > Package: vtwm
> > Version: 5.4.7-3
> > 
> > Upstream git appears to have what git-describe calls
> > `5.5.0-rc8-15-g0b1705e' from 2013.  That would probably be nice.  (But
> > not for stretch.)
> 
> Upstream has released a real 5.5.0 in 2018.

Realistically, I am not likely to get to this soon.  But if someone
were to prepare an upload (as a git branch, preferably) I would be
happy to review and sponsor it.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners

2020-07-07 Thread Till Kamppeter


On 07/07/2020 22:25, Didier 'OdyX' Raboud wrote:

For the record, I am primarily concerned about the printing support in Debian,
which packaging I carry mostly alone (I get great help from Brian Potkin for
bug triaging, and Till Kamppeter for upstream and Ubuntu support). I don't
really intend to also start carrying the scanning stack on my shoulders too.

(While I state this, I also know that I might end up taking on this packaging,
just don't wait on me if you're interested!)


Thank you for having a look into this.

This is not a regular scanner driver but it is a driver which gives 
support for the scanning parts of practically all modern printer/scanner 
multi-function devices. And with the soon to be added IPP Scan support 
an important part of the new IPP-based printing/scanning architecture 
which is currently under development.


Therefore it is especially interesting to have this package maintained 
by the Debian Printing Team.


OdyX, I will not ask you to package arbitrary scanner drivers or SANE 
itself.


WDYT?

   Till

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

2020-07-07 Thread Evgeny Kapun


On 07.07.2020 22:40, Rene Engelhard wrote:

Even that worked for me in said testing VM "upgraded" to unstable with
your apt-get --with-new-pkgs upgrade.

libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept
back.


After some testing, I found out that you also need to pass `--no-install-recommends`, 
as otherwise `Recommends: libreoffice-core (>> 1:7.0.0~rc1)` in 
libreoffice-l10n-ru prevents it from upgrading.

Anyway, upgrading any subset of packages, if permitted by dependencies, should 
not produce any errors. To test that this is indeed the case, I suggest running 
`apt-get --no-install-recommends install $pkg` in a test environment for every 
package to test the upgrade of that package in isolation (so that only the 
package and the packages that are strictly required to satisfy dependencies are 
upgraded).

Bug#964438: apt-listbugs: dns error when running from cron job

2020-07-07 Thread Oswald Buddenhagen


On Tue, Jul 07, 2020 at 10:53:59PM +0200, Francesco Poli wrote:

On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote:
there is a report every hour despite it claiming to be a daily job.  
that's weird at least.


It works this way by design. [...]
The rationale is: the job must be attempted at various times, since the
network could be down sometimes.

i see. you actually want anacron-like functionality with network 
awareness. i guess systemd should be doing something like that ...



Was your system offline 5 min after waking up from sleep?

no, my point was that this is happening *right* after waking up. there 
is no delay.



Please reply to the other questions in my previous message.

the only one which seems relevant would be the one about recent changes, 
to which i can speculate that this possibly started with the recent-ish 
systemd v245.6 upgrade.

Bug#656026: mawk: Hardened build flags not fully enabled

2020-07-07 Thread Thomas Dickey

On Sun, Jan 26, 2020 at 07:28:52PM +0100, Andreas Henriksson wrote:
> Hello Thomas Dickey,
> 
> You've previously interacted with the debian bug report at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656026
> and the issue there should have been fixed already.
> 
> While preparing an updated debian package with the latest
> snapshot release the packaging CI however noticed another
> (minor) issue with hardening. Full "blhc" log available at:
> https://salsa.debian.org/debian/mawk/-/jobs/530844
> 
> Basically it seems the issue is that $(LDFLAGS) is still
> missing from the Makefile.in line that builds makescan(.c).
> Given that makescan seems to be a tool only used during
> build and not actually shipped/installed, hardening it
> is probably very low priority. It might however be nice
> to have this fixed simply so that the blhc job will succeed
> making it easier to spot any potential future regressions
> in hardening. Would be great if you could consider looking
> into this. Thanks in advance.

This was addressed by

20200106
+ use both CFLAGS/LDFLAGS when linking in makefile (report by
  Rajeev V Pillai).

The makefile uses LDFLAGS by this route:

LDFLAGS = @CFLAGS@ @LDFLAGS@

BUILD_LDFLAGS   = @BUILD_LDFLAGS@

@ECHO_LD@$(BUILD_CC) $(BUILD_CFLAGS) $(BUILD_CPPFLAGS) $(BUILD_LDFLAGS) 
-o makescan$x $(srcdir)/makescan.c

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

2020-07-07 Thread Francesco Poli

On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote:

> On Tue, Jul 07, 2020 at 07:46:50PM +0200, Francesco Poli wrote:
> > • when did it begin?
> >
> i don't remember - i tend to ignore non-critical errors at first.

Mmmh, that's unfortunate: I think that knowing this would have helped a
bit...

> the journal doesn't say when it began, either, as it says that the 
> sevice "succeeded" despite the error mail ...
> 
> but there are actually clues in the journal:
> 
> there is a report every hour despite it claiming to be a daily job.  
> that's weird at least.

It works this way by design.

Basically, when the job completes without issues, it drops the date
into /var/spool/apt-listbugs/lastprefclean .
When the job encounters issues, it exits (with status 0).

The job is attempted hourly (with a randomized delay), but it does
nothing if it has already dropped the date
into /var/spool/apt-listbugs/lastprefclean on the same day (where "day"
is a 24 h time interval, starting at 7:00 a.m. local time).

The rationale is: the job must be attempted at various times, since the
network could be down sometimes.
But it must be completed (at most) once per day.

> 
> more importantly, there is another report (outside the hourly schedule) 
> right after waking up from sleep -

This must be due to "OnActiveSec=5min".
See /lib/systemd/system/apt-listbugs.timer

> and this one could plausibly 
> consistently run into a dns failure, as it runs before the network stack 
> is restarted.

Was your system offline 5 min after waking up from sleep?
If so, then it's the expected behavior...

> so it's systemd-related, just differently than i thought.

We still have to understand why it cannot query the DNS from the
systemd timer, while you are able to do so from the command line.

Please reply to the other questions in my previous message.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpQsd3INYB80.pgp
Description: PGP signature

Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners

2020-07-07 Thread Alexander Pevzner


Hi OdyX,


For the record, I am primarily concerned about the printing support in Debian,
which packaging I carry mostly alone (I get great help from Brian Potkin for
bug triaging, and Till Kamppeter for upstream and Ubuntu support). I don't
really intend to also start carrying the scanning stack on my shoulders too.


I already provide Debian packages, build on OpenSUSE Build Services, so 
this software proven to build and work on Debian.


Technically, the question is in integration it with the official Debian 
packaging process.


Actually, sane-airscan is not capricious in building and packaging.

Regarding technical support, I can provide it for Debian users as well 
as I already provide it for users of my own packages, assuming I will be 
somehow notified if user files bug to Debian bug tracking system.


--

Wishes, Alexander Pevzner (p...@apevzner.com)

Bug#964488: UDD: browse upstream versions

2020-07-07 Thread Matt Taggart


Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Version: 20200707
Severity: wishlist

I would like a way to browse upstream versions in different ways. I 
don't know how much is already in the database but here are some fields 
I've thought of.


For packages with a newer upstream:
* time since latest debian upload to present. (aka how much newer in 
time is upstream)
* time since upstream with a greater version than debian latest (aka how 
long the package could have been updated, would need to know when uscan 
detected versions)
* how many new upstream versions have happened since the current debian 
latest (this might require info about multiple uscan results?).
* delta from debian version to upstream version (arbitrary and can't be 
compared package to package, but might still be interesting)


Maybe there are more?

Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#959599: frama-c: FTBFS fixed upstream

2020-07-07 Thread Andre Maroneze

On Sat, 06 Jun 2020 09:47:57 -0400 John Scott  wrote:
> Control: forwarded -1 
https://lists.gforge.inria.fr/pipermail/frama-c-discuss/2020-June/005823.html

> Control: tags -1 fixed-upstream
>
> I'm having trouble finding their VCS and what commit fixed this, but 
updating
> Frama-C to the beta should be sufficient. Unstable and testing 
already have

> Why3 >= 1.3.

For information, the Frama-C public VCS (git) is available at: 
https://git.frama-c.com/pub/frama-c/-/tree/master

There is no specific commit which updated compatibility from Why3 1.2 to 
Why3 1.3 (there is an entire branch with several commits related to it), 
but https://git.frama-c.com/pub/frama-c/-/commit/1c7acc37c44f914f60a27 
would be close.

In any case, thanks for looking into this, and please tell us if there's 
anything we can do to help fix the frama-c package on Debian testing.

--
André Maroneze, for the Frama-C team

Bug#964288: override: debichem

2020-07-07 Thread Sandro Tosi

> I wasn't completely clear.
>
> What I meant to ask for was justification for why the section in the
> control file was changed.

(please note i dont work on debichem nor ever touched it before, so
this is mostly guess-work :)

from
https://salsa.debian.org/blends-team/debichem/-/commit/c093c22a1ec7ae6b79442a6f32809e58bc942902#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2
it looks like previously there was no Section in d/control (blends may
have evolved since early releases to include it), so probably
overrides assigned to those bin pkgs a default one.

I'm opening this ticket (as i've opened several others in the past)
because PTS mention the overrides disparity and they are indeed
metapackages.

Is there any specific reason for pushing back on this request?

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

Bug#964482: buster-pu: xen/4.11.4+24-gddaaccbbab-1~deb10u1

On Tue, 2020-07-07 at 22:21 +0200, Hans van Kranenburg wrote:
> On 7/7/20 9:51 PM, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Tue, 2020-07-07 at 21:16 +0200, Hans van Kranenburg wrote:
> > > I'd like to update the xen packages in buster to
> > > 4.11.4+24-gddaaccbbab-1~deb10u1 for the 10.5 point release. This
> > > is an update to keep following the stable-4.11 upstream Xen
> > > code,which mainly contains security fixes.
> > > 
> > > https://salsa.debian.org/xen-team/debian-xen/-/blob/10f1a4a8f15b6748459cd1c826d3808694682faf/debian/changelog
> > 
> > In that case, please attach a source debdiff between the current
> > stable package and the proposed package (built and tested on
> > stable) to this request.
> 
> I can do that. Are you sure you want to read through the upstream
> changes in a way that collapses everything and removes the context of
> the original git commits with any useful information about whether
> it's related to an XSA, or if it's a backport of a critical bug that
> crashes systems for our stable users or if it's a commit that really
> needs to be included before the security fix will actually work?

Well, you're welcome to provide additional information that you think
would help. But there does need to at least be a debdiff that can
persist in the bug report.

> I'm trying to run this through the stable release process because
> there's an (one) actual packaging change involved.
> 
> If we only had upstream changes, we'd do this as a regular security
> update.

In that case, have you discussed this with the Security Team at all?
They're often open to including small non-security changes if those are
separately identified and acked from the SRM side.

Regards,

Adam

Bug#964288: override: debichem

2020-07-07 Thread Sean Whitton

Hello,

On Tue 07 Jul 2020 at 01:11AM -04, Sandro Tosi wrote:

> control: tag -1 - moreinfo
>
> On Tue, Jul 7, 2020 at 12:58 AM Sean Whitton  wrote:
>>
>> control: tag -1 + moreinfo
>>
>> Hello,
>>
>> On Sun 05 Jul 2020 at 01:14AM -04, Sandro Tosi wrote:
>>
>> > Package: ftp.debian.org
>> > Severity: normal
>> >
>> > Hello,
>> > could you please apply these changes:
>> >
>> > dak override debichem-cheminformatics metapackages # from 'debichem'
>> > dak override debichem-visualisation metapackages # from 'debichem'
>> > dak override debichem-view-edit-2d metapackages # from 'debichem'
>> > dak override debichem-semiempirical metapackages # from 'debichem'
>> > dak override debichem-modelling metapackages # from 'debichem'
>> >
>> > (as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956258# 
>> > )
>>
>> Sure, but could you briefly explain the reason?
>
> because that's what the package d/control file says:
> https://salsa.debian.org/blends-team/debichem/-/blob/master/debian/control
>
> the actual effect of the overrides file having a different section
> than `metapackages` is that the py2removal tracking program wont
> ignore those packages (as removing a package that's a dep of a
> metapackage is "okay") and thus we dont mark leaf packages as such.
>
> Please let me know if this clarification suffices and you can proceed.

I wasn't completely clear.

What I meant to ask for was justification for why the section in the
control file was changed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964482: buster-pu: xen/4.11.4+24-gddaaccbbab-1~deb10u1

2020-07-07 Thread Hans van Kranenburg

On 7/7/20 9:51 PM, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 2020-07-07 at 21:16 +0200, Hans van Kranenburg wrote:
>> I'd like to update the xen packages in buster to
>> 4.11.4+24-gddaaccbbab-1~deb10u1 for the 10.5 point release. This is
>> an update to keep following the stable-4.11 upstream Xen code, which
>> mainly contains security fixes.
>>
>> https://salsa.debian.org/xen-team/debian-xen/-/blob/10f1a4a8f15b6748459cd1c826d3808694682faf/debian/changelog
> 
> In that case, please attach a source debdiff between the current stable
> package and the proposed package (built and tested on stable) to this
> request.

I can do that. Are you sure you want to read through the upstream
changes in a way that collapses everything and removes the context of
the original git commits with any useful information about whether it's
related to an XSA, or if it's a backport of a critical bug that crashes
systems for our stable users or if it's a commit that really needs to be
included before the security fix will actually work?

I'm trying to run this through the stable release process because
there's an (one) actual packaging change involved.

If we only had upstream changes, we'd do this as a regular security update.

>> I also have 4.11.4+24-gddaaccbbab-1 for unstable ready for upload
>> here.
>> All of it is right now waiting for the upstream testing at the Xen
>> project to finish, which is regression testing the latest additions
>> for todays published security advisories (
>> https://xenbits.xen.org/xsa/,
>> 2020-07-07). But, I'm already sending the request.
> 
> It's fine to send the request now, but the unstable upload needs to
> happen first.

That's for sure!

Hans

Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners

2020-07-07 Thread Didier 'OdyX' Raboud

Le mardi, 7 juillet 2020, 13.26:01 h CEST Till Kamppeter a écrit :
> Package: wnpp
> Severity: wishlist
> 
> * Package name: sane-airscan
>Version : 0.99.8
>Upstream Author : Alexander Pevzner 
> * URL : https://github.com/alexpevzner/sane-airscan
> * License : GPL-2+ with sane exception (same as sane-backends)
>Programming Lang: C
>Description : SANE backend for AirScan (eSCL) and WSD document
>  scanners
> 
> sane-airscan is a SANE backend (scanner driver) for two
> manufacturer-neutral, standardized communication protocols (AirScan/eSCL
> and WSD) which are used by the scanners in most modern printer/scanner
> multi-function devices and so used by thousands of scanners.

For the record, I am primarily concerned about the printing support in Debian, 
which packaging I carry mostly alone (I get great help from Brian Potkin for 
bug triaging, and Till Kamppeter for upstream and Ubuntu support). I don't 
really intend to also start carrying the scanning stack on my shoulders too.

(While I state this, I also know that I might end up taking on this packaging, 
just don't wait on me if you're interested!)

Regards,
OdyX

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

Bug#961218: ipp-usb Packaging some more remarks

2020-07-07 Thread Didier 'OdyX' Raboud

Control: retitle -1 ITP: ipp-usb -- Daemon for IPP over USB printer support
Control: owner -1 !

Le lundi, 6 juillet 2020, 14.41:18 h CEST Till Kamppeter a écrit :
> I have worked a lot with Alexander Pevzner on making ipp-usb what it is
> now and I also have succeeded to get localhost support into Avahi.
> 
> Most was already told in the initial report, but I have some additional
> remarks:
> 
> - IPP-over-USB is a very important standard to allow printing and
> scanning without hardware-model-specific drivers when the device is
> connected via USB. There is no way for driverless USB access to such
> devices without using IPP-over-USB, Practically all modern
> printer/scanner-multi-function devices support driverless IPP operation
> including IPP-over-USB. This way we get thousands of printers and
> scanners (and even sending fax) working, without needing to develop
> drivers. ipp-usb is currently the only way to get this working reliably.
> 
> - The upstream source repository https://github.com/OpenPrinting/ipp-usb
> (Note: it has moved to OpenPrinting) contains also the debian packaging
> in its debian/ subdiectory, so packaging for Debian probably needs only
> some simple corrections. The work load needed is very low. Also
> maintaining would be easy as Alexander would probably help.
> 
> - I also want to introduce ipp-usb in Ubuntu, in 20.10 (Groovy Gorilla)
> which has Feature Freeze Aug 27. It would be great if I could sync from
> Debian.
> 
> No one interested? OdyX, could you package/upload it?

I just became interested :-) ; so I will take a look in the following days; 
perhaps next week.

Best regards,

OdyX

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

Bug#964487: RM: syslinux-themes-debian -- RoQA; orphaned; rc-buggy; outdated

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove syslinux-themes-debian:

- it's been orphaned for 7+ years
- is rc buggy for over a year
- ships themes for squeeze and wheezy, which are both... not really
  relevant anymore

Thanks,
Chris

Bug#824774: pkg-config: please support DPKG_ROOT in dpkghook script

2020-07-07 Thread David Kalnischkies

On Tue, Jul 07, 2020 at 05:58:36PM +0200, David Kalnischkies wrote:
> as the unlucky stars aligned today again for who knows what reason
> (I guess it comes with the support dpkg added around d-m-h recently)

Turns out that now everyone (who runs apts testcases or something
comparable) is affected as dpkg has increased its support for DPKG_ROOT
which now causes architectures of the dpkgroot to be reported while the
hookscript tries to add/remove links on the host system and of course
fails to do so (see #964475).

I have a workaround for #964475 so that this bug won't block the transition
of dpkg to testing, but it would be nice if we could eventually resolve
this here as I feel kinda dirty working around and ignoring failures,
especially after reported this four years ago already.

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

Bug#699114: O: libnss-ldap -- NSS module for using LDAP as a naming

Hi Arthur, Barry, Moritz,

* Arthur de Jong  [200707 20:02]:
> On Sun, 2013-01-27 at 19:25 +, Steve McIntyre wrote:
> > The current maintainer of libnss-ldap, Richard A Nelson (Rick)
> >  > orphan this package now.
> 
> If anyone is willing to be maintainer of the libnss-ldap and libpam-ldap
> packages I'm willing to help getting the packages into shape.

[..]

> I may also point people to libnss-ldapd and libpam-ldapd as alternatives
> (depending on whether anyone else is willing to do any work on this).

[..]

> The alternative is to remove the packages (see #717917 and #717918)
> which, while being good for the popularity of my packages ;), would
> perhaps not be the most ideal situation.

Do any of you think the situation has changed since 2013?

Personally I would not want to have once popular NSS and PAM
libraries in the next stable release, if upstream has vanished a long
time ago.

Maybe its time to reopen 717917 and 717918?

Chris

Bug#964475: dpkg breaks apt autopkgtest: dpkg: error: unknown option --foreign-architecture

2020-07-07 Thread David Kalnischkies

Control: tags -1 + pending

Hi,

On Tue, Jul 07, 2020 at 08:47:21PM +0200, Paul Gevers wrote:
> Currently this regression is blocking the migration of dpkg to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?

We (apt & dpkg maintainers) talked about this on IRC already and
I pushed a workaround (of sorts) to apt.git [0] for this.

The underlying problem is that the hookscript pkg-config installs does
not support DPKG_ROOT while the newer version of dpkg does support it
(more) now reporting architectures from the DPKG_ROOT rather than the
host system it previously did (arguably incorrectly). Based on that
pkg-config-dpkghook attempts to create (or remove) symlinks in /usr/bin
for architectures added/removed in dpkgroot which it isn't allowed to
(as it isn't run as root) and fails.

APTs testcases detect these failures in "dpkg --add-architecture" and
assumes it is working with a previous version of a dpkg Multi-Arch
implementation used e.g. in older Ubuntus resulting in the tests
eventually using commandline options unknown to the dpkg version
it is really using here.

The workaround detects these failures and ignores them now – as the
hookscript is post-invoke the architecture is added, so we got what
we were asking for – but ideally #824774 in pkg-config would be resolved.

(Ignoring that dpkg should also probably not read /etc/dpkg.cfg.d files
 from the root system, but that might be an even longer endeavour)

Best regards

David Kalnischkies

[0] 
https://salsa.debian.org/apt-team/apt/-/commit/3fe1419433f195d57b948b100b218cf14a2841d0

signature.asc
Description: PGP signature

Bug#964169:

2020-07-07 Thread Marat Salakhutdinov

So it seems the issue is with OverlayFS and the underlying kernel
version. The kernel prior to 4.9 overlayfs is not supporting POSIX
access-control lists (https://lwn.net/Articles/718062/) and that seems
the issue. Where our container libraries (and sed particularly)
support ACLs starting version 4.5.2 -
https://metadata.ftp-master.debian.org/changelogs//main/s/sed/sed_4.7-1_changelog.

I assume the issue can be closed and the fix would be either to
upgrade the underlying OS (kernel), change of docker storage driver or
downgrading container library (sed binary) versions.

Many thanks to Krzysztof Opasiak for pointing out the root cause.

Bug#964486: RM: initz -- RoQA; orphaned; dead upstream; alternatives exist

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove initz, an init files helper for emacsen.

- Orphaned for 8+ years, no interest in the O bug
- Last upstream release in 2003
- There are other, more modern helpers for configuring emacs (at least
  when I last used emacs a few years ago)
- popcon numbers say there are 6 total installs

Thanks,
Chris

Bug#964485: RM: mknbi -- RoQA; orphaned; dead upstream; superseded

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove mknbi:
- orphaned for more than 8 years, with no interest in the O bug
- is only useful with Etherboot, which was removed in 2011
- it doesn't work with Linux 2.6 kernels (...)
- upstream stopped making changes to it over 12 years ago
- hardware built in the last 15 years didn't need mknbi.

Thanks,
Chris

Bug#964482: buster-pu: xen/4.11.4+24-gddaaccbbab-1~deb10u1

Control: tags -1 + moreinfo

On Tue, 2020-07-07 at 21:16 +0200, Hans van Kranenburg wrote:
> I'd like to update the xen packages in buster to
> 4.11.4+24-gddaaccbbab-1~deb10u1 for the 10.5 point release. This is
> an update to keep following the stable-4.11 upstream Xen code, which
> mainly contains security fixes.
> 
> https://salsa.debian.org/xen-team/debian-xen/-/blob/10f1a4a8f15b6748459cd1c826d3808694682faf/debian/changelog

In that case, please attach a source debdiff between the current stable
package and the proposed package (built and tested on stable) to this
request.

> I also have 4.11.4+24-gddaaccbbab-1 for unstable ready for upload
> here.
> All of it is right now waiting for the upstream testing at the Xen
> project to finish, which is regression testing the latest additions
> for todays published security advisories (
> https://xenbits.xen.org/xsa/,
> 2020-07-07). But, I'm already sending the request.

It's fine to send the request now, but the unstable upload needs to
happen first.

Regards,

Adam

Bug#936071: Followup: fixing /etc/pam.d/common-auth to not error on missing /etc/securetty?

2020-07-07 Thread josh

Following up on this bug. Would it be possible to get common-auth to
stop using "nullok_secure" in its pam_unix invocation, so that it stops
producing an error about /etc/securetty?

Bug#964484: RM: aewm -- RoQA; orphaned; dead upstream; ftbfs with gcc-10; alternatives exist

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove aewm:
- has been orphaned for 8+ years, with no interest in the O bug
- the previous Maintainer is also the upstream, homepage has disappeared
- currently ftbfs with the coming gcc-10
- we have enough other options for minimalist window managers, some of
  them might also work with wayland in the future.
- popcon tells me usage is virtually non-existent and never really was

Thanks,
Chris

Bug#960600: buster-pu: package asunder/2.9.3-3+deb10u1

On Tue, 2020-07-07 at 20:37 +0200, Andreas Ronnquist wrote:
> On Tue, 07 Jul 2020 18:49:38 +0100,
> Adam D. Barratt wrote:
> 
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2020-05-14 at 14:25 +0200, Andreas Ronnquist wrote:
> > > The cddb service freedb,org has been closed down, and I would
> > > like to
> > > update asunder so that it uses gnudb.org by default instead. I
> > > mention it in a NEWS item too, so that others get a warning and
> > > chance to change their setting too.  
> > 
> > diff -Nru asunder-2.9.3/debian/NEWS.Debian
> > asunder-2.9.3/debian/NEWS.Debian --- asunder-
> > 2.9.3/debian/NEWS.Debian
> >  2019-01-23 21:58:01.0 +0100 +++
> > asunder-2.9.3/debian/NEWS.Debian2020-05-14 14:12:58.0
> > +0200
> > @@ -1,3 +1,12 @@
> > +asunder (2.9.3-3+deb10u1) unstable; urgency=medium
> > 
> > That should be buster, in line with the changelog.
> > 
> > With that fixed, please go ahead.
> > 
> 
> Done! Package has just been accepted into proposed-updates.

Not quite yet. :-) It's in stable-new, it'll be in p-u once we process
the upload.

Regards,

Adam

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

On Tue, Jul 07, 2020 at 09:30:23PM +0200, Rene Engelhard wrote:
> Am 07.07.20 um 21:21 schrieb Evgeny Kapun:
> >> but how did you get into this situation?
> >
> > I've run `apt-get --with-new-pkgs upgrade`. This upgraded some
> > libreoffice packages including libreoffice-l10n-ru, but not
> > libreoffice-common because this would require it to remove
> > libreoffice-style-tango.
> 
> Aha. Will try.

Even that worked for me in said testing VM "upgraded" to unstable with
your apt-get --with-new-pkgs upgrade.

libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept
back.

Regards,

Rene

Bug#964483: RM: lomoco -- RoQA; orphaned; dead upstream; hardware support questionable

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove lomoco:
- orphaned for 8 years, with no interest in the O bug
- only supports Logitech hardware that is probably broken by now (only
  mice older than ~2009)
- upstream has vanished

Thanks,
Chris

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

2020-07-07 Thread R hertoric

Thank you

On Tue, Jul 7, 2020, 1:24 PM Samuel Henrique  wrote:

> > Please go ahead.
>
> Thank you Adam,
>
> nmap_7.70+dfsg1-6+deb10u1_source.changes ACCEPTED into
> proposed-updates->stable-new
>
> Regards,
>
> --
> Samuel Henrique 
>
>

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

Hi,

Am 07.07.20 um 21:21 schrieb Evgeny Kapun:
>> but how did you get into this situation?
>
> I've run `apt-get --with-new-pkgs upgrade`. This upgraded some
> libreoffice packages including libreoffice-l10n-ru, but not
> libreoffice-common because this would require it to remove
> libreoffice-style-tango.

Aha. Will try.

And libreoffice-style-tango is required to be removed for a reason: It
simply is gone upstream :-)

> In the future, it seems wise to test plain `upgrade` and
> `--with-new-pkgs upgrade` in addition to dist-upgrade. 

Maybe. But here you DO want dist-upgrade. You are not supposed to keep
libreoffice-style-tango and the dependencies enforce that.

Regards,


Rene

Bug#964481: RM: xpp -- RoQA; orphaned; rc-buggy; alternatives exist

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove xpp:
- has been orphaned over 10 years ago, with very little interest since
  2013. The original maintainer said 7 years ago "IMHO, we should just
  remove it from Debian"
- is rc-buggy for over 6 months
- upstream didn't do anything for over 14 years
- alternatives exist: desktop environments nowadays have "printer
  panels", and for other usages gtklp appears to be a viable alternative

Thanks,
Chris

Bug#964482: buster-pu: xen/4.11.4+24-gddaaccbbab-1~deb10u1

2020-07-07 Thread Hans van Kranenburg

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

Hi,

I'd like to update the xen packages in buster to
4.11.4+24-gddaaccbbab-1~deb10u1 for the 10.5 point release. This is an
update to keep following the stable-4.11 upstream Xen code, which mainly
contains security fixes.

https://salsa.debian.org/xen-team/debian-xen/-/blob/10f1a4a8f15b6748459cd1c826d3808694682faf/debian/changelog

I also have 4.11.4+24-gddaaccbbab-1 for unstable ready for upload here.
All of it is right now waiting for the upstream testing at the Xen
project to finish, which is regression testing the latest additions for
todays published security advisories (https://xenbits.xen.org/xsa/,
2020-07-07). But, I'm already sending the request.

Both unstable and Buster are on Xen 4.11. Currently buster has
4.11.3+24-g14b62ab3e5-1~deb10u1, so in the changelog you can see we'll
be syncing it up with unstable again.

The 4.11.4-1 package version contained an actual packaging change, that
fixes a bug for upgrading to a new Xen version. This is something we
want to have in Buster for our users. It means fixing upgrading from
Buster to Bullseye, but also for whoever follows Debian unstable now.
It's the stuff related to #932759 and these are the changes:

Init scripts:

https://salsa.debian.org/xen-team/debian-xen/-/commit/420d05e8b5950cb79b03a613f791cad400390bb8

NEWS:

https://salsa.debian.org/xen-team/debian-xen/-/commit/10baa2d48db43a5ff675bddf5482717f60fb748a

Testing and code review can also be seen in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932759#38

So, since 4.11.4-1 is in unstable already, these changes have been out
there for weeks now. We have not seen any user report about any regression.

Thanks,
Hans van Kranenburg

Bug#964480: linux: ath9k (USB) broken in upstresm linux 5.7.3 after commit 6602f080cb

2020-07-07 Thread Juergen

Source: linux
Version: 5.7.0-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

see https://bugzilla.kernel.org/show_bug.cgi?id=208251.

This affects all kernel versions that include

ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb

by

Qiujun Huang 

In 5.7 reverting 6602f080cb is known to fix the problem, but it hasn't yet been
analyzed by an expert, therefore I'd like to report my findings to perhaps get
an expert interested:-)

At least one problem is in function ath9k_hif_usb_reg_in_cb(). In the call to
usb_fill_int_urb() it should be rx_buf instead of nskb as penultimate
parameter.

I'm currently running the following patch to send this bug report using my ath9k
dongle.

Best regards

Jürgen

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 4ed21dad6a8e..f3622d686002 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -693,15 +693,8 @@ static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
struct rx_buf *rx_buf = (struct rx_buf *)urb->context;
struct hif_device_usb *hif_dev = rx_buf->hif_dev;
struct sk_buff *skb = rx_buf->skb;
-   struct sk_buff *nskb;
int ret;

-   if (!skb)
-   return;
-
-   if (!hif_dev)
-   goto free;
-
switch (urb->status) {
case 0:
break;
@@ -711,9 +704,6 @@ static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
case -ESHUTDOWN:
goto free;
default:
-   skb_reset_tail_pointer(skb);
-   skb_trim(skb, 0);
-
goto resubmit;
}

@@ -725,22 +715,27 @@ static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
 skb->len, USB_REG_IN_PIPE);


-   nskb = alloc_skb(MAX_REG_IN_BUF_SIZE, GFP_ATOMIC);
-   if (!nskb) {
+   skb = alloc_skb(MAX_REG_IN_BUF_SIZE, GFP_ATOMIC);
+   if (!skb) {
dev_err(_dev->udev->dev,
"ath9k_htc: REG_IN memory allocation 
failure\n");
urb->context = NULL;
-   return;
+   goto free;
}

+   rx_buf->skb = skb;
+
usb_fill_int_urb(urb, hif_dev->udev,
 usb_rcvintpipe(hif_dev->udev,
 USB_REG_IN_PIPE),
-nskb->data, MAX_REG_IN_BUF_SIZE,
-ath9k_hif_usb_reg_in_cb, nskb, 1);
+skb->data, MAX_REG_IN_BUF_SIZE,
+ath9k_hif_usb_reg_in_cb, rx_buf, 1);
}

 resubmit:
+   skb_reset_tail_pointer(skb);
+   skb_trim(skb, 0);
+
usb_anchor_urb(urb, _dev->reg_in_submitted);
ret = usb_submit_urb(urb, GFP_ATOMIC);
if (ret) {

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

tag 964471 + moreinfo
tag 964471 + unreproducible
thanks

Hi,

On Tue, Jul 07, 2020 at 08:59:26PM +0200, Rene Engelhard wrote:
> On Tue, Jul 07, 2020 at 08:40:54PM +0200, Rene Engelhard wrote:
> > Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
> > upgtaded libreoffice-common before the l10ns (and thus 
> > /etc/libreoffice/registry
> > iwas there at .postinst time)
> 
> And a clean testing VM dist-upgraded to unstable just now also worked.

(with -help-ru installed.)

> But anyways, as you should have already seen - added the same dependency in 
> git to
> anything having anything in /etc/libreoffice/registry.
> 
> Should fix it.

Also for (which I think you did, why can't people just do proper
upgrades, you "helpfully" didn't add your distro info added by reportbug in 
your report)
"let's install the unstable package on testing" scenarios.

Regards,

Rene

Bug#964479: blackbox: New upstream version available

Package: blackbox
Version: 0.70.1-38
Severity: normal

There is a new upstream and a new release available:
https://github.com/bbidulock/blackboxwm/releases/tag/0.76

Please consider updating to it.

Bug#964478: RM: ddns3-client -- RoQA; orphaned; untestable

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove ddns3-client:
- it was orphaned 9 years ago, with no interest in the O bug for 6 years
- has seen only one upload since then, 5 years ago
- is a client for a service not accepting new users for 11 years,
  so there is no way to test it
- upstream has not made any changes in 11 years
- popcon suggests no, or maybe a single, user
- better, actively maintained dynamic DNS options exist.

Thanks,
Chris

Bug#964477: libc6-dev: Fails to cleanly upgrade from Stable

2020-07-07 Thread Helge Kreutzmann

Package: libc6-dev
Version: 2.28-10
Severity: important

Until a few hours ago I run stable. Switching sources to testing and
then
apt-get update
apt-get upgrade

worked. Now:

apt-get dist-ugprade tells me the following:

root@samd:~# LC_ALL=C apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

If I try to remove either libc6-dev or libgcc-8-dev then a long list of 
programms is scheduled for deinstallation, e.g. lots of KDE, okular, 
libreoffice etc.

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.28-10
ii  libc6   2.28-10
ii  linux-libc-dev  5.7.6-1

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
ii  glibc-doc 2.30-8
ii  manpages-dev  5.07-1

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

On Tue, Jul 07, 2020 at 08:40:54PM +0200, Rene Engelhard wrote:
> Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
> upgtaded libreoffice-common before the l10ns (and thus 
> /etc/libreoffice/registry
> iwas there at .postinst time)

And a clean testing VM dist-upgraded to unstable just now also worked.

But anyways, as you should have already seen - added the same dependency in git 
to
anything having anything in /etc/libreoffice/registry.

Should fix it.

Regards,

Rene

Bug#964476: RM: autounit -- RoQA; orphaned; dead upstream; unused

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove autounit:
- it has been orphaned for 10 years, with no interest to pick it up
- last QA upload was 5 years ago
- its a development helper package, and nothing depends or build-depends
  on it
- upstream has vanished

Given this is a development tool, and nothing needs it in Debian, I
think it's safe to say this is an unused thing, and no new software will
start using it. We can save our QA energy for other packages.

Thanks,
Chris

Bug#964366: [aristocratos/bashtop] [BUG] insecure use of /tmp (#161)

2020-07-07 Thread Jakub Wilk


* Dylan Aïssi , 2020-07-06, 15:13:

pytmpdir=$(mktemp -d "${TMPDIR:-/tmp}"/)
pywrapper=$(mktemp "${pytmpdir}"/bashtop.psutil.)

Should fix the issue.


Does the proposed fix by upstream look good to you?


It's mostly OK, but:
- mktemp(1) can fail, and this failure should not be ignored;
- there's no need for two mktemp calls.

Something like this should work:

  pytmpdir=$(mktemp -d "${TMPDIR:-/tmp}"/bashtop.XX) || exit 1
  pywrapper=${pytmpdir}/psutil

--
Jakub Wilk

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

Hi,

On Tue, Jul 07, 2020 at 09:13:58PM +0300, Evgeny Kapun wrote:
> When upgrading Libreoffice, the following errors occur:
> 
> 
> Setting up libreoffice-l10n-ru (1:7.0.0~rc1-3) ...
> 
> Creating config file /etc/libreoffice/registry/Langpack-ru.xcd with new 
> version
> cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': 
> No such file or directory
> dpkg: error processing package libreoffice-l10n-ru (--configure):
>  installed libreoffice-l10n-ru package post-installation script subprocess 
> returned error exit status 1
> dpkg: dependency problems prevent configuration of libreoffice-help-ru:
>  libreoffice-help-ru depends on libreoffice-l10n-ru; however:
>   Package libreoffice-l10n-ru is not configured yet.
> 
> dpkg: error processing package libreoffice-help-ru (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  libreoffice-l10n-ru
>  libreoffice-help-ru
> 
> 
> This is apparently caused by /etc/libreoffice/registry not existing.

Interesting. I had that error once for other packages:

libreoffice (1:7.0.0~alpha1-2) experimental; urgency=medium

libreoffice (1:7.0.0~alpha1-2) experimental; urgency=medium

  * debian/patches/libreoffice.jar-pom.diff: add pom for new
libreoffice.jar
  * debian/patches/bigendian-ustrbuf-hxx.diff: add missing include
on bigendian architectures
  * debian/patches/skia-SkOpts_crc32.diff: add missing SkOpts_crc32
to fix skia build on arm

  * debian/control*in:
- make -librelogo, -sdbc-postgresql and -report-builder explicitly
  depend on libreoffice-common (>= 1:7.0.0~alpha~) as otherwise
  /etc/libreoffice/registry might not exist yet
[...]

but how did you get into this situation?

Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
upgtaded libreoffice-common before the l10ns (and thus /etc/libreoffice/registry
iwas there at .postinst time)

Regards,

Rene

Bug#850248: New upstream version available

* Ian Jackson  [200707 18:46]:
> Package: vtwm
> Version: 5.4.7-3
> 
> Upstream git appears to have what git-describe calls
> `5.5.0-rc8-15-g0b1705e' from 2013.  That would probably be nice.  (But
> not for stretch.)

Upstream has released a real 5.5.0 in 2018.

Chris

Bug#964475: dpkg breaks apt autopkgtest: dpkg: error: unknown option --foreign-architecture

2020-07-07 Thread Paul Gevers

Source: dpkg, apt
Control: found -1 dpkg/1.20.4
Control: found -1 apt/2.1.6
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of dpkg the autopkgtest of apt fails in testing
when that autopkgtest is run with the binary packages of dpkg from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
dpkg   from testing1.20.4
aptfrom testing2.1.6
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of dpkg to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=dpkg

https://ci.debian.net/data/autopkgtest/testing/amd64/a/apt/6176292/log.gz

Test for successful execution of aptmark hold bar … dpkg: error: unknown
option --foreign-architecture

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or
'more' !
E: Sub-process dpkg --set-selections returned an error code (2)
E: Executing dpkg failed. Are you root?
FAIL: exitcode 100
 P
Part of the test group: Test for successful execution of aptmark
showholds bar …
Test for correctness of file
/tmp/tmp.nOcxNldGYL/rootdir/tmp/testsuccess.output …
+bar
=== content of file we compared with
(/tmp/tmp.nOcxNldGYL/rootdir/tmp/testsuccess.output) ===
FAIL

T



signature.asc
Description: OpenPGP digital signature

Bug#960600: buster-pu: package asunder/2.9.3-3+deb10u1

2020-07-07 Thread Andreas Ronnquist

On Tue, 07 Jul 2020 18:49:38 +0100,
Adam D. Barratt wrote:

>Control: tags -1 + confirmed
>
>On Thu, 2020-05-14 at 14:25 +0200, Andreas Ronnquist wrote:
>> The cddb service freedb,org has been closed down, and I would like to
>> update asunder so that it uses gnudb.org by default instead. I
>> mention it in a NEWS item too, so that others get a warning and
>> chance to change their setting too.  
>
>diff -Nru asunder-2.9.3/debian/NEWS.Debian
>asunder-2.9.3/debian/NEWS.Debian --- asunder-2.9.3/debian/NEWS.Debian
>  2019-01-23 21:58:01.0 +0100 +++
> asunder-2.9.3/debian/NEWS.Debian2020-05-14 14:12:58.0
> +0200
>@@ -1,3 +1,12 @@
>+asunder (2.9.3-3+deb10u1) unstable; urgency=medium
>
>That should be buster, in line with the changelog.
>
>With that fixed, please go ahead.
>

Done! Package has just been accepted into proposed-updates.

Thank you!

best
-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

Bug#964338: buster-pu: package mariadb-10.3 10.3.23-0+deb10u1

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

Sorry, the changelog is wrong, it was actually not removed, just
changed location:

--- a/debian/libmariadb-dev.install
+++ b/debian/libmariadb-dev.install
@@ -8,4 +8,4 @@ usr/lib/*/libmysqlservices.a
 usr/share/aclocal/mysql.m4
 usr/share/man/man1/mysql_config.1
 usr/lib/pkgconfig/libmariadb.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
-usr/share/pkgconfig/mariadb.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
+usr/lib/*/pkgconfig/mariadb.pc

So upstream adopted our view of what the location should be, so the
move was removed. End result is that location is exactly the same.


This is the correct changelog:

mariadb-10.3 (1:10.3.23-0+deb10u1) buster; urgency=high

  * SECURITY UPDATE: New upstream version 10.3.23. Includes fixes for the
following security vulnerabilities (Closes: #961849):
- CVE-2020-2752
- CVE-2020-2760
- CVE-2020-2812
- CVE-2020-2814
- CVE-2020-13249
  * Backport upstream patch to fix regression in RocksDB ZSTD detection
which prevents a serious bug and also autopkgtest detectable
regression.
  * Update libmariadb symbols for upstream release 3.1.8. Upstream
added one new symbol and it needs to be tracked in the symbols file.

 -- Otto Kekäläinen   Sat, 04 Jul 2020 15:31:51 +0300


Since the amendment is so small I will not attach a new debdiff.
Latest source always visible at
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/tree/buster

Bug#964474: RM: ctwm -- RoQA; orphaned; outdated

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove ctwm:
- orphaned for 11 years
- Debian package is based upon upstream from 14 years ago
- virtually no popcon usage

While upstream doesn't seem to be dead, there appears to be zero
interest in Debian. Whomever has an interest in this package, should
probably start from scratch with a current upstream version.

Thanks,
Chris

Bug#964470: whatmaps: long description could compare with needrestart

2020-07-07 Thread Guido Günther

Hi Jonas,
On Tue, Jul 07, 2020 at 08:11:55PM +0200, Jonas Smedegaard wrote:
> Package: whatmaps
> Version: 0.0.12-3
> Severity: minor
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> whatmaps sounds like it does something similar (or maybe the exact same)
> as needrestart.
> 
> Please consider mentioning needrestart in long description
> and describe in which situations this package is more suitable.

whatmaps is very outdated so i think needsrestart is better suited for
the job - i should ask for removal.
 -- Guido

> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8EuusACgkQLHwxRsGg
> ASHcyg/+KQsb1oGR2e9x5YPI0IXFmPju8ml+6BcBV7vSfMwKoGmCCKg9EC5tkipN
> 9Yu/ij/VPWiHNaNgdYhC/Ukh++QpY1Sp7WjYewnjVfdc4BDAZurtC/n7NrKSY7bs
> CXKn2tU9JNXm7WFPikCD9w7FgpiOo57zWowwLTD5g87ihsXrBBPpls+ReJpd25/C
> 8jH9lt4cgJy+XIDfU4w+thPpI9jZuWdCnJVh4wo+Q37W3KgJnGQhsCu+mP2pxqtf
> ZHqDRIp/eVgx3vfBczvz2kJoDO3ztrRGgu8UBOR3iBHDmjSCxplcgblveWX2HDDp
> P9xJqhZFWvmTs0COtncl6Gly+QfYsbKIZbUALUOGhhPRHgQTqLb2d4wPl5RteEbv
> ezsZKrneqZbe2rD1An3iNfSRQ5voL9By5knMpSNWFJO9/2GiPmEXvIX2a12cDJdl
> 0vgf+7EMzEvW22c7fsSJzodmfk4Ew2FPdJX0sYKvVF1ozxzgz95UuVKZO3SeNk+I
> woIpC3v+qN5BNUaYr5aOv/6NiJEJBWZf+5DOPNvAQk025EPTLXkceADz3MaYGNzt
> Q1AWrWjw2Z/u6V4g7jrzAT3Ed6i3WnDsf3DnFMwhFJrBtPy6vd0O2R20ziUQCU14
> iv+Y5Cu4tH1jIPQX0vUu8N+VG5NJiJFH5CZF8upihw7tNmrtHA8=
> =0GVC
> -END PGP SIGNATURE-
>

Bug#964473: nova: please suggestpsycopg2 instead of pygresql

Package: nova
Version: 2:21.0.0-3

Dear Maintainer,

your package nova-common suggests python3-pygresql, which I found to be
highly unlikely. Build-Depends-Indep already lists python3-psycopg2
instead, and given that nova seems to use SQLAlchemy under the hood,
python3-psycopg2 would be the better idea at runtime, too.

Please remove python3-pygresql - possibly replacing it with
python3-psycopg2. Note that pygresql is pretty much dead (and
orphaned).

Thanks,
Chris

Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

2020-07-07 Thread Sergio Durigan Junior

On Tuesday, July 07 2020, Sudip Mukherjee wrote:

> Hi Sergio,

Hi Sudip,

> On Tue, Sep 17, 2019 at 05:30:01PM -0400, Sergio Durigan Junior wrote:
>> [ Forwarding.  ]
>> 
>> <#secure method=pgpmime mode=sign>
>> On Tuesday, September 17 2019, I wrote:
>> 
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Sergio Durigan Junior 
>> >
>> > * Package name: poke
>> >   Version : 0.1-beta
>> >   Upstream Author : Jose E. Marchesi
>> > * URL : http://www.jemarch.net/poke.html
>> > * License : GPL-3+
>> >   Programming Lang: C
>> >   Description : GNU poke -- An interactive, extensible editor for 
>> > binary data
>> >
>> >  GNU poke is an interactive, extensible editor for binary data. Not
>> >  limited to editing basic entities such as bits and bytes, it provides a
>> >  full-fledged procedural, interactive programming language designed to
>> >  describe data structures and to operate on them.
>
> Any idea when this can land? I attended a conference last year where
> Jose demonstrated this and it seemed pretty cool.

Unfortunately no.  GNU poke depends on jitter
(http://ageinghacker.net/git/cgit.cgi/jitter), which is not available in
Debian.  I was going to package it, but then got sidetracked.

I'm fairly busy with other stuff these days, but I will try to give it a
go this next weekend.  Let's see.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

2020-07-07 Thread Oswald Buddenhagen


On Tue, Jul 07, 2020 at 07:46:50PM +0200, Francesco Poli wrote:

• when did it begin?


i don't remember - i tend to ignore non-critical errors at first.
the journal doesn't say when it began, either, as it says that the 
sevice "succeeded" despite the error mail ...


but there are actually clues in the journal:

there is a report every hour despite it claiming to be a daily job.  
that's weird at least.


more importantly, there is another report (outside the hourly schedule) 
right after waking up from sleep - and this one could plausibly 
consistently run into a dns failure, as it runs before the network stack 
is restarted. so it's systemd-related, just differently than i thought.

Bug#964472: pwman3: incorrect Recommends on pygresql

Package: pwman3
Version: 0.10.0-3

Dear Maintainer,

your package pwman3 recommends python3-pygresql, which I found to be
highly unlikely. From a quick glance at the source, it seems to use
psycopg2 if available, and not pygresql.

Please remove python3-pygresql - possibly replacing it with
python3-psycopg2. Note that pygresql is pretty much dead.

Thanks,
Chris

Bug#959579: adapta-gtk-theme: FTBFS: make[2]: *** [Makefile:1040: all] Error 1

2020-07-07 Thread Franciscarlos Soares

Dear Sidup,

Thanks for the patch, it is of great value.

The upstream of this package has archived the project and is currently not
in development.

However, after testing your patch, I think it is feasible to continue
maintaining this package in Debian.

Soon we will upload it with your patch.

Thanks again.

Em seg, 6 de jul de 2020 08:09, Sudip Mukherjee 
escreveu:

> On Mon, Jul 6, 2020 at 11:19 AM Samuel Henrique 
> wrote:
> >
> > Hello Sudip,
> >
> > Just a quick update, I spoke to Franciscarlos (he will reply back here
> > soon) and he intends to keep the package, so your patch will be
> > accepted, he just wants to confirm that the package is working fine
> > with the latest version of gnome.
>
> thats great.
>
> >
> > Meanwhile, can you push your changes to the git repo?
>
> Sure, I have raised a merge request after changing the release to
> "UNRELEASED", so that you can accept it after Franciscarlos has tested
> it.
> Kept it UNRELEASED as I assumed you might want to update the
> Standards-Version and debhelper also (which I should not do as part of
> NMU).
>
>
> --
> Regards
> Sudip
>

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

2020-07-07 Thread Samuel Henrique

> Please go ahead.

Thank you Adam,

nmap_7.70+dfsg1-6+deb10u1_source.changes ACCEPTED into
proposed-updates->stable-new

Regards,

-- 
Samuel Henrique

Bug#964470: whatmaps: long description could compare with needrestart

2020-07-07 Thread Jonas Smedegaard

Package: whatmaps
Version: 0.0.12-3
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

whatmaps sounds like it does something similar (or maybe the exact same)
as needrestart.

Please consider mentioning needrestart in long description
and describe in which situations this package is more suitable.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8EuusACgkQLHwxRsGg
ASHcyg/+KQsb1oGR2e9x5YPI0IXFmPju8ml+6BcBV7vSfMwKoGmCCKg9EC5tkipN
9Yu/ij/VPWiHNaNgdYhC/Ukh++QpY1Sp7WjYewnjVfdc4BDAZurtC/n7NrKSY7bs
CXKn2tU9JNXm7WFPikCD9w7FgpiOo57zWowwLTD5g87ihsXrBBPpls+ReJpd25/C
8jH9lt4cgJy+XIDfU4w+thPpI9jZuWdCnJVh4wo+Q37W3KgJnGQhsCu+mP2pxqtf
ZHqDRIp/eVgx3vfBczvz2kJoDO3ztrRGgu8UBOR3iBHDmjSCxplcgblveWX2HDDp
P9xJqhZFWvmTs0COtncl6Gly+QfYsbKIZbUALUOGhhPRHgQTqLb2d4wPl5RteEbv
ezsZKrneqZbe2rD1An3iNfSRQ5voL9By5knMpSNWFJO9/2GiPmEXvIX2a12cDJdl
0vgf+7EMzEvW22c7fsSJzodmfk4Ew2FPdJX0sYKvVF1ozxzgz95UuVKZO3SeNk+I
woIpC3v+qN5BNUaYr5aOv/6NiJEJBWZf+5DOPNvAQk025EPTLXkceADz3MaYGNzt
Q1AWrWjw2Z/u6V4g7jrzAT3Ed6i3WnDsf3DnFMwhFJrBtPy6vd0O2R20ziUQCU14
iv+Y5Cu4tH1jIPQX0vUu8N+VG5NJiJFH5CZF8upihw7tNmrtHA8=
=0GVC
-END PGP SIGNATURE-

Bug#964338: buster-pu: package mariadb-10.3 10.3.23-0+deb10u1

On Sun, 2020-07-05 at 22:41 +0300, Otto Kekäläinen wrote:
> mariadb-10.3 (1:10.3.23-0+deb10u1) buster; urgency=high
> 
>   * SECURITY UPDATE: New upstream version 10.3.23. Includes fixes for
> the
> following security vulnerabilities (Closes: #961849):
> - CVE-2020-2752
> - CVE-2020-2760
> - CVE-2020-2812
> - CVE-2020-2814
> - CVE-2020-13249
>   * Remove mariadb.pc from package as upstream no longer provides it.
> Update the mysqlclient.pc link to point to the libmariadb.pc file
> instead to keep backwards compatibility.

I assume nothing actually links against / using mariadb.pc?

Regards,

Adam

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

2020-07-07 Thread Evgeny Kapun


Package: libreoffice-l10n-ru
Version: 1:7.0.0~rc1-3
Severity: serious

When upgrading Libreoffice, the following errors occur:


Setting up libreoffice-l10n-ru (1:7.0.0~rc1-3) ...

Creating config file /etc/libreoffice/registry/Langpack-ru.xcd with new version
cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No 
such file or directory
dpkg: error processing package libreoffice-l10n-ru (--configure):
 installed libreoffice-l10n-ru package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of libreoffice-help-ru:
 libreoffice-help-ru depends on libreoffice-l10n-ru; however:
  Package libreoffice-l10n-ru is not configured yet.

dpkg: error processing package libreoffice-help-ru (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libreoffice-l10n-ru
 libreoffice-help-ru


This is apparently caused by /etc/libreoffice/registry not existing.

Bug#964469: whatmaps: manpage references wrong README file and does not mention debconf

2020-07-07 Thread Jonas Smedegaard

Package: whatmaps
Version: 0.0.12-3
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Manpage for whatmaps includes this:

  See "usr/share/doc/whatmaps/README.Debian" for details.

There is a missing initail slash, and the package is native
so the file is README (not README.Debian).

Also, would be nice if the manpage additionally mentioned the option
to not manually edit config file but instead run

  dpkg-reconfigure whatmaps


Thanks for a nice tool,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8EucQACgkQLHwxRsGg
ASGYRQ//cu1acooWYNsK2Cpp2/qwJ8KCVZEAbHFNjJXPhoZhg3rot91CzXWGej38
DqwIzrvB24oGFmR763KQDsCRjukZx4tZXJZWXmbEwpXlqTVDUHQC29xZmj3exKS/
Q6FNNtESOESNp+742Xc2lm5SIyYagZuRFkGgQEK1O5MCIqdWCsuU2p7M/4uJ6GQ9
EjS3hxKitPSge/tusPyAryyj221eexwSGa6VD+54yhzw3D/sDT3gFuJSrkBlm42y
7euCtN3LPAiR5DM7/Pz7EvIay/bet8yMM9F8gYlcLit7xPQ3KGKF2RuuyRnz8wA4
NEbObq1i28Y1Y/hieRF6NsO8C/Dki+wJIvtH4mxeh/P13yX84zZktOtmVW++IV9Q
C5gEgk4yJOyG+7iH2tT0gU2I2e+Ewy/n6xGSMSyEDIO+sP7gYxtEu9egpn9oFJ6G
t0cH8751vIRs+3Url10X7z7hyQARGKywVL4gPwY0PFf+riTVtYmc2IuXNyoJt4oz
SLCsWz+Gn3ZY8K6oJcGEiVj8lIwYrGNP0Er02J60VUKWN4DqOvtACwcgpdlagCxE
Egvfr96Cc3SdAoUY7eQu9ygZvJJH/x81osFlIH2JtLiIuDRbDkLpRKHTBmjF1zXQ
5K0ykIlVnlMVIVlYxYhXXtManGVGPcIDIj/HpyL0wl8wHjOiUJU=
=/+jR
-END PGP SIGNATURE-

Bug#964468: RM: libifp -- RoQA; unmaintained; dead upstream; obsolete hardware

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove libifp: communicate with iRiver iFP audio devices.

It has not seen an upload for 9+ years, and is a support library for
iRiver media players, which I haven't seen in years either.

It does not seem to have any reverse dependencies.

Looks like interest in support for the hardware is just gone.
There's an open bug to switch to current libusb API, but obviously
that's also not happening.

Thanks,
Chris

Bug#947758: buster-pu: package node-handlebars/3:4.1.0-1+deb10u1

Control: tags -1 -pending +confirmed

On Mon, 2020-05-04 at 22:02 +0200, Xavier wrote:
> Le 04/05/2020 à 18:53, Mattia Rizzolo a écrit :
> > Hi,
> > 
> > let me reply before adsb has a chance ;)
> > 
> > On Mon, May 04, 2020 at 02:24:20PM +0200, Xavier wrote:
> > > Finally I found a way to fix CVE and keep autopkgtest OK
> > > (node-markdown-it-html5-embed). Here is a debdiff for a future
> > > point release
> > 
> > This is good, however,
> > 
> > > diff --git a/debian/changelog b/debian/changelog
> > > index b985661..64df8db 100644
> > > --- a/debian/changelog
> > > +++ b/debian/changelog
> > > @@ -1,3 +1,11 @@
> > > +node-handlebars (3:4.1.0-1+deb10u1) buster; urgency=medium
> > > +
> > > +  * Team upload
> > > +  * Disallow calling "helperMissing" and "blockHelperMissing"
> > > directly
> > > +(Closes: CVE-2019-19919)
> > > +
> > > + -- Xavier Guimard   Mon, 04 May 2020 14:21:11
> > > +0200
> > 
> > By now 3:4.1.0-1+deb10u1 is already accepted in p-u, built and all,
> > and
> > it can't really be removed from there and replaced by a same-
> > versined
> > pacakge.
> > 
> > Please prepare a +deb10u2 version, and post here a debdiff against
> > the
> > already uploaded +deb10u1 one.
> 
> Is it good so ?

Sorry for the delay. Please feel free to go ahead.

Regards,

Adam

Bug#964417: buster-pu: package mod-gnutls/0.9.0-1.1~deb10u1

Control: tags -1 + confirmed

On Tue, 2020-07-07 at 01:07 +0300, Adrian Bunk wrote:
> On Tue, Jul 07, 2020 at 12:58:41AM +0300, Adrian Bunk wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> >   * Backported patches to fix test failures with the
> > apache CVE-2019-10092 fix. (Closes: #950300)
> >   * Disable a test that fails with GnuTLS >= 3.6.11. (Closes:
> > #950301)
> >   * Backported a fix for a possible segfault on failed TLS
> > handshake.
> > 
> > Technically the #950301 fix is not necessary in buster,
> > but the tests of this package are so fragile with changes
> > in build dependencies that disabling a test that might
> > pass is better-safe-than-sorry.
> 
> The missing debdiff is attached.

Please go ahead.

Regards,

Adam

Bug#948653: stretch-pu: package mod-gnutls/0.8.2-3+deb9u1

Control: tags -1 + confirmed

On Tue, 2020-07-07 at 01:01 +0300, Adrian Bunk wrote:
> Control: retitle -1 stretch-pu: package mod-gnutls/0.8.2-3+deb9u2
> Control: tags -1 - pending
> 
> On Fri, Jul 03, 2020 at 06:57:55AM +0100, Adam D. Barratt wrote:
> > Hi,
> 
> Hi Adam,
> 
> > On Fri, 2020-01-31 at 08:43 +0200, Adrian Bunk wrote:
> > > Control: block -1 by 950300
> > > 
> > > On Tue, Jan 28, 2020 at 08:41:29AM +, Adam D. Barratt wrote:
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On 2020-01-11 10:34, Adrian Bunk wrote:
> > > > >   * Avoid deprecated ciphersuites in test suite (Closes:
> > > > > #907008)
> > > > > 
> > > > > FTBFS, tests were broken by gnutls28 3.5.8-5+deb9u4.
> > > > 
> > > > Please go ahead.
> > > 
> > > The apache2 2.4.25-3+deb9u9 upgrade causes an unrelated FTBFS in 
> > > mod-gnutls, which made 0.8.2-3+deb9u1 fail on the buildds.
> > > 
> > > Reported as #950300, this bug is present even in unstable.
> > > 
> > > Seems fixed in upstream 0.9.1.
> > > 
> > > I'll take care of this, but there is not enough time left to get
> > > this fixed for the upcoming stretch point release - I won't do a
> > > 0-
> > > day NMU  for a just reported FTBFS in unstable.
> > 
> > What's the status of this?
> 
> sorry for the delay, debdiff is attached.

Thanks; please go ahead.

Regards,

Adam

Bug#960600: buster-pu: package asunder/2.9.3-3+deb10u1

Control: tags -1 + confirmed

On Thu, 2020-05-14 at 14:25 +0200, Andreas Ronnquist wrote:
> The cddb service freedb,org has been closed down, and I would like to
> update asunder so that it uses gnudb.org by default instead. I
> mention it in a NEWS item too, so that others get a warning and
> chance to change their setting too.

diff -Nru asunder-2.9.3/debian/NEWS.Debian asunder-2.9.3/debian/NEWS.Debian
--- asunder-2.9.3/debian/NEWS.Debian2019-01-23 21:58:01.0 +0100
+++ asunder-2.9.3/debian/NEWS.Debian2020-05-14 14:12:58.0 +0200
@@ -1,3 +1,12 @@
+asunder (2.9.3-3+deb10u1) unstable; urgency=medium

That should be buster, in line with the changelog.

With that fixed, please go ahead.

Regards,

Adam

Bug#964244: stretch-pu: package xml-security-c/1.7.3-4+deb9u2