Bug#968075: ITP: iminuit -- Robust Python minimisation library based around MINUIT2

[Jeremy Sanders]

Package: wnpp
Severity: wishlist
Owner: Jeremy Sanders 

* Package name: iminuit
  Version : 1.4.2
  Upstream Author : Piti Ongmongkolkul
* URL : https://github.com/scikit-hep/iminuit
* License : MIT
  Programming Lang: C++, Python
  Description : Robust Python minimisation library based around MINUIT2

iminuit is a Jupyter-friendly Python frontend to the MINUIT2 C++ library.
It can be used as a general robust function minimisation method, but is
most commonly used for likelihood fits of models to data, and to get model
parameter error estimates from likelihood profile analysis.

Further comments
 - Optional dependency for veusz debian package
 - One of the most robust and easy to use numerical minimisation packages
   for Python
 - Based around MINUIT2, which is a rewrite of the very widely used and
   well-tested MINUIT minimisation package, developed since the 1970s
 - Other packages which provide similar minimisers are scipy. A comparison
   of its performance is here:
   https://iminuit.readthedocs.io/en/stable/benchmark.html
 - Would prefer to maintain it within the Debian Science Team
 - I would need a sponsor to get it included

Bug#968074: /usr/sbin/dkms: line 247: /dev/fd/62: No such file or directory

[Harald Dunkel]

Package: dkms
Version: 2.8.3-3

Instaling aufs-dkms (or others) fails with messages like

/usr/sbin/dkms: line 247: /dev/fd/62: No such file or directory

Sample:

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up aufs-dkms (5.2+20190909-1.1) ...
Removing old aufs-5.2+20190909 DKMS files...
/usr/sbin/dkms: line 247: /dev/fd/62: No such file or directory

--
Deleting module version: 5.2+20190909
completely from the DKMS tree.
--
Done.
Loading new aufs-5.2+20190909 DKMS files...
Building for 5.7.12-raw 5.7.14-raw
/usr/sbin/dkms: line 2130: /dev/fd/62: No such file or directory
/usr/sbin/dkms: line 2061: /dev/fd/62: No such file or directory
dpkg: error processing package aufs-dkms (--configure):
 installed aufs-dkms package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 aufs-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)


Regards
Harri

Bug#968051: Please include direct links to PGP public keys where possible

[Paul Wise]

On Fri, Aug 7, 2020 at 12:00 PM Steve McIntyre wrote:

> Maybe we could/should link to direct lookups on keyring.d.o if that's
> possible, or use WKD somehow (hand-wave)?

The HKPS URL could be used for this:

https://keyring.debian.org/pks/lookup?op=get=0x10460DAD76165AD81FBC0CE9988021A964E6EA7D
https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-3.4

AFAICT the WKD stuff doesn't have lookups based on key fingerprint.

Probably also listing commands to download the keys would be good:

gpg --verbose --recv-keys --keyserver hkps://keyring.debian.org '1046
0DAD 7616 5AD8 1FBC  0CE9 9880 21A9 64E6 EA7D'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#965288: r-cran-findpython: Python2 removal in sid/bullseye - reopen 965288

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:r-cran-findpython)Testsuite-Triggers->python
(binary:r-cran-findpython)Recommends->python

Re-opening, so that they can be taken care of.

Bug#945673: fvwm-crystal: Python2 removal in sid/bullseye - reopen 945673

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(binary:fvwm-crystal)Depends->python2

Re-opening, so that they can be taken care of.

Bug#673724: Relicensing done by upstream

[olivier sallou]

Good news, upstream license has been modified after some rewriting (see
issue closed https://github.com/jshint/jshint/issues/1234), so should fit
for debian now

Bug#946046: not fixed

[Vincent Lefevre]

Control: tags -1 - wontfix
Control: severity -1 serious

as currently the unison-all is not usable at all as described
(see below).

On 2020-08-07 23:57:02 +0200, Stéphane Glondu wrote:
> severity 946046 wishlist
> tags 946046 + wontfix
> thanks

The wontfix does not make any sense. The unison-all package is
described as follows:

Description: file synchronization tool (all console versions)
 This is a metapackage that depends on all supported console versions
 of Unison, a file synchronization tool.
 .
 Each of the supported versions uses a different protocol version;
 installing this metapackage ensures the ability to synchronize with
 old systems.

See the latest sentence. That's the *only* purpose of the unison-all
metapackage.

So, either you are able to fix the issue in some way via unison-all
(I can see only a rather ugly solution, though the end user would
not see the ugly part), or the issue cannot be fixed in a clean way,
and the unison-all package should just be removed from Debian as
being broken by design (co-instability of the stable versions and the
unstable version should be sufficient, without needing unison-all),
which is probably the easiest was to fix this bug.

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

Bug#968072: ITP: libdata-downsample-largesttrianglethreebuckets-perl -- Perl module for downsampling time series for visual representation

[Alexander Zangerl]

Package: wnpp
Severity: wishlist
Owner: Alexander Zangerl 

* Package name: libdata-downsample-largesttrianglethreebuckets-perl
  Version : 1.00
  Upstream Author : Steve Troxel 
* URL : 
https://metacpan.org/release/Data-DownSample-LargestTriangleThreeBuckets
* License : Artistic 2
  Programming Lang: Perl
  Description : Perl module for downsampling time series for visual 
representation

This module implements a downsampling technique known as
Largest Triangle Three Buckets, which aims at retaining
the visual character of the plotted data even at very much
reduced data set size.
 
The technique is described in detail in Sveinn Steinarsson's thesis
which can be found at https://skemman.is/handle/1946/15343

Bug#965002: mumble: New upstream version available (1.3.2)

[Jonathan Rubenstein]

On Wed, 15 Jul 2020 04:27:16 + Chris Knadle 
 wrote:

> Matthias Heinz:
> > Package: mumble
> > Version: 1.3.0+dfsg-1+b3
> > Severity: wishlist
> >
> > Hi!
> >
> > There is a new version of mumble available upstream. It would be 
great if this
> > could be packaged, because it would solve the slow startup of 
mumble (waiting

> > for jack).
> >
> > Thanks you!
> >
> > - Matthias
>
> Yes I'm aware of the 1.3.2 bugfix release.
>
> I've also been wanting to fix the startup delay. Prior to 1.3.1 which 
had a
> long delay before release, I had attempted to include patches to the 
current
> Debian package to fix the slow startup among other issues, but 
unfortunately
> when I tested I found that the patches caused Mumble to fail to find 
internal
> audio notification sound files. This means backtracking the local Git 
changes

> out and then trying again with a 1.3.2 tarball now that that's available.
>
> -- Chris
>
> --
> Chris Knadle

> chris.kna...@coredump.us
>
>

Are there any blockers in updating to the new version?


-Jonathan

Bug#968031: take-vector-screenshot: crash (SIGSEGV) under GNOME Wayland

[Paul Wise]

On Fri, 2020-08-07 at 10:01 +0200, Joachim Breitner wrote:

> I don’t think I’ll be able to develop it a lot further at this point.
> Patches are welcome of course, as are offers to take over (upstream &
> Debian) maintenance. 

Fair enough. FTR I don't care about the package or what it does really,
I just thought I would report a crash I had noticed in passing. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#967975: rss2email 3.12-1 error

[gustavo panizzo]

Hello Justin

I think the bug you are reporting has been reported upstream already.
https://github.com/rss2email/rss2email/issues/126

Can you provide more information about your setup?

Specifically the versions of python, python3-feedparser, python3-html2text
and python3-bs4

what operation were you doing when the error appeared? can you
reproduce the issue with a clean configuration/state?

thanks


--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#968071: lintian: Differentiate between "ar" static libraries and "ar" archives

[Olek Wojnar]

Package: lintian
Version: 2.62.0
Severity: normal

Dear Maintainer,

Lintian currently emits an arch-dependent-file-in-usr-share error when it sees
an "ar" file within usr/share. Based on the description, it seems that lintian
assumes that this is a static library. However, it gives the same error for
an "ar" archive file which is *not* arch dependent. For example, the *.ar
files in this directory:
https://salsa.debian.org/bazel-team/bazel-bootstrap/-/tree/olek-temp4/tools/build_defs/pkg/testdata

Please consider using the `file` command or something similar to distinguish
between the two types of "ar" files. Thank you!

Bug#968070: ITP: liblinux-termios2-perl -- Perl module for accessing the termios2 structure and ioctl

[Alexander Zangerl]

Package: wnpp
Severity: wishlist
Owner: Alexander Zangerl 

* Package name: liblinux-termios2-perl
  Version : 0.01
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Linux-Termios2
* License : same as Perl - GPL 1+ or Artistic
  Programming Lang: Perl, C
  Description : Perl module for accessing the termios2 structure and ioctl

This module provides an API equivalent to the POSIX::Termios class,
but backed by the Linux-specific struct termios2 structure instead.

The primary use case is setting arbitrary baud rates, because
POSIX::Termios only knows the standard speeds up to 38400 baud.

Bug#946046: not fixed

[Vincent Lefevre]

On 2020-08-07 23:57:02 +0200, Stéphane Glondu wrote:
> The unison in Debian 10 is compiled with OCaml 4.05.0, which is long
> gone. The only way to synchronize with a buster machine is to use unison
> from buster.

This is what I've done until now, with the unison package put on hold.
But when I wanted to upgrade, based on the the new packaging structure
(which claimed to fix the bug), this version got upgraded too!!!

> I'm sorry I haven't been sufficiently clear on that.
> 
> Since the version of OCaml changes at each Debian release, there will
> not be /in the archive/ a package (or metapackage) that will be
> compatible with two successive Debian releases (or with stable and
> testing/unstable). My goal with the new packaging structure is that once
> a version of Unison is installed, it may be kept installed even after an
> upgrade of Unison (meta)packages. So, for example, if we transition to a
> new version of OCaml (say 4.11.0), I will ask for the removal of
> unison-2.48 from the archive and upload a new unison-2.48+4.11.0. In
> this hypothetic future, unison-2.48 can be kept installed on systems (or
> installed from snapshots) where its compatibility set is needed.
> Moreover, unison-2.48 and unison-2.48+4.11.0 would be co-installable,
> easing migration from one version to the other.

unison-2.48 should have never been created: buster has a unison
package with version number 2.48.4-1, thus one has the impression
that this is compatible with unison-2.48, while this is not the
case. The package should have been named unison-2.48+4.08.1 right
now to avoid this confusion.

Moreover, unison-2.48 provides /usr/bin/unison-2.48; this is not fine
since buster also has /usr/bin/unison-2.48, which is not compatible.
As the client will start a server with the same version number on
the remote machine (by using the recommended "addversionno = true"),
this means that one will likely get an archive corruption (which
happened to me). The OCaml version must be part of the version and
attached to the name of the unison executable.

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

Bug#968069: ITP: weechat-matrix -- matrix plugin for weechat

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: weechat-matrix
  Version : 0.2.0
  Upstream Author : poljar
* URL : https://github.com/poljar/weechat-matrix
* License : MIT
  Programming Lang: Python
  Description : matrix plugin for weechat

A Python plugin for Weechat that allows weechat to communicate
over the Matrix protocol. Currently supports large parts of the
Matrix protocol, but end-to-end encryption is still
experimental.

Weechat is a fast and light chat client for many operating
systems. Everything can be done with a keyboard

Will be maintained on Salsa under Debian

Bug#968068: ITP: weechat-matrix -- matrix plugin for weechat

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: weechat-matrix
  Version : 0.2.0
  Upstream Author : poljar
* URL : https://github.com/poljar/weechat-matrix
* License : MIT
  Programming Lang: Python
  Description : matrix plugin for weechat

A Python plugin for Weechat that allows weechat to communicate
over the Matrix protocol. Currently supports large parts of the
Matrix protocol, but end-to-end encryption is still
experimental.

Weechat is a fast and light chat client for many operating
systems. Everything can be done with a keyboard

Will be maintained on Salsa under Debian

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[Russ Allbery]

gregor herrmann  writes:

> Right, except that this also doesn't work at build time.
> But if we skip the test phase that would be ok.

> What I'm wondering is:
> - depending on debian-policy would be another dependency, and the
>   debian-policy only installs files to /usr/share/doc which is not
>guaranteed to exist; and there's also no easily parsable file there;
> - will lintian continue to ship
>   /usr/share/lintian/data/standards-version/release-dates ? Then we
>   could still parse it ourselves without the Lintian perl modules;
> - even if lintian ships the perl modules in a private path, it would
>   be possible to use it; if this makes sense depends on the reason
>   why lintian moves the files, which I haven't fully understood yet
>   (my impression is more that this has to do with lintian internales
>   like tests that with the question if the modules should be uses by
>   others).

> But yeah, maybe just using rmadison or whatever other online method
> to get the lates S-V is easier than to rely on lintian.

If it would be helpful for debian-policy to ship this information directly
in the package, that should be relatively easy to do.  Feel free to open a
bug against debian-policy.  I'm not sure if Sean would see any problems
that I'm not seeing, but I personally have no objection to Policy starting
to install some machine-readable information about Policy in files in
/usr/share/debian-policy in a documented format.

If we did that, I would probably ship this information in YAML rather than
in the somewhat ad hoc format of Lintian's data file (which was my fault
originally).

-- 
Russ Allbery (r...@debian.org)  

Bug#966554: how to apply the workaround?

[quixote]

Well, I waited till the weekend so if I needed hours to recover my 
system, I wouldn't have to drop the ball on all the other things going 
on in my life. And I made sure I had printouts of the instructions on 
recovering grub, and grug-efi, using chroot, and that I had a bootable 
recent live thumbdrive of Debian. (I only have the one computer, no 
fallback.) When I looked, my last version was Debian 9.3


I had it all laid out, told it to shut down, rebooted, and

it worked perfectly on the first try.

I love Debian.

One curious thing: /sys/firmware/vars/efivars/ still reports itself as 
being full. It didn't stop the system from booting. Haven't tried a 
manual grub-install. But is that expected behavior?

Bug#967963: installation failure: rockpro64

[Forest]

On Fri, 7 Aug 2020 09:27:14 +0300, Alper Nebi Yasak wrote:
>It's updated now, so the current daily builds should work.

Thank you!

>Can you check /sys/firmware/devicetree/base/chosen/stdout-path 

It contains "serial2:150n8" which I suppose is the expected value
(though maybe not the best choice for this board since the boot firmware
uses 115200).

I tried your suggestion of refreshing screen after boot finished, to clear
the 1.5mbps garbage, but it didn't help.  If the cause is not something in
the installer image, I wonder if it might lie in my serial adapter; it is
supposed to support that speed, but I don't think I've ever tried it before.

Anyway, the main problem I reported is fixed with the new daily builds.
Thanks again!

Bug#636317: libagar (ITP) libtool troubles

[Tormod Volden]

The launchpad links I posted didn't survive. I have now set up a git
repository for the Debian packaging,
which includes Stephen's 1.4.1 and my 1.5.0:
https://salsa.debian.org/tormod/agar

Upstream has after 4 years recently released a 1.6.0, I might take a look at it.

Bug#946046: not fixed

[Stéphane Glondu]

severity 946046 wishlist
tags 946046 + wontfix
thanks

Le 07/08/2020 à 22:24, Vincent Lefevre a écrit :
> This is not sufficient to synchronize with Debian 10 (buster).
> It depends only on unison, which depends on unison-2.48, and
> with the latest version of unison-2.48, I get lots of errors:
> [...]

The unison in Debian 10 is compiled with OCaml 4.05.0, which is long
gone. The only way to synchronize with a buster machine is to use unison
from buster.

I'm sorry I haven't been sufficiently clear on that.

Since the version of OCaml changes at each Debian release, there will
not be /in the archive/ a package (or metapackage) that will be
compatible with two successive Debian releases (or with stable and
testing/unstable). My goal with the new packaging structure is that once
a version of Unison is installed, it may be kept installed even after an
upgrade of Unison (meta)packages. So, for example, if we transition to a
new version of OCaml (say 4.11.0), I will ask for the removal of
unison-2.48 from the archive and upload a new unison-2.48+4.11.0. In
this hypothetic future, unison-2.48 can be kept installed on systems (or
installed from snapshots) where its compatibility set is needed.
Moreover, unison-2.48 and unison-2.48+4.11.0 would be co-installable,
easing migration from one version to the other.


Cheers,

-- 
Stéphane

Bug#963396: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure

[Thorsten Glaser]

On Fri, 7 Aug 2020, Pierre Gruet wrote:

> I suggest using the enclosed patch, which allows the build to succeed by
> overriding the ``test'' method of Predicate. The ``apply'' method
> provided by upstream has to be kept as it is used by the ``test'' method.

But why? This amount of redundancy is… ridiculous.

private static final Predicate NOT_EMPTY =
  new Predicate() {
@Override
public boolean apply(Object input) {
  return !input.toString().isEmpty();
}
  };

I was just suggesting replacing this with…

private static final Predicate NOT_EMPTY =
input -> !input.toString().isEmpty();

… but then I saw https://stackoverflow.com/q/41930727/2171120
and the code from jimfs seems to use Guava, not standard Java:

import com.google.common.collect.Iterables;
import com.google.common.base.Predicate;

Looking at guava/src/com/google/common/base/Predicate.java in
the Debian source package guava-libraries (29.0-5) I see:

 * As this interface extends {@code java.util.function.Predicate}, an 
instance of this type may
 * be used as a {@code Predicate} directly. To use a {@code 
java.util.function.Predicate} where a
 * {@code com.google.common.base.Predicate} is expected, use the method 
reference {@code
 * predicate::test}.
 *
 * This interface is now a legacy type. Use {@code 
java.util.function.Predicate} (or the

This means the correct patch is more like… ugh, this is more complicated.
Also, com.google.common.base.Predicate implements a default test method.

In addition, for some reason, jimfs still builds for Java 7.

Gimme a bit, I’ll build it locally, now I found the Debian packaging.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#697781: ITP

[Raphael Hertzog]

Control: retitle -1 ITP: hamster-time-tracker -- a GNOME time tracker
Control: owner -1 !

I'm going to reintroduce the hamster time tracker into Debian. I was
using hamster-applet up to today but I just realized that it was dropped
from Debian a long time ago...

I will use https://salsa.debian.org/projecthamster-team/hamster-time-tracker
to maintain the package since Matthijs already created this a while ago.
I'm waiting to have write access but I have the package ready to upload
and I will upload it right away.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#968034: xidle: introduction of setsid() call introduces undocumented behaviour changes

[Thorsten Glaser]

Marcel Partap dixit:

>.. actually did track it down and thus:
>https://github.com/openbsd/xenocara/blame/cb9cf7367eab7967cc49564626c11e0cc7d865bc/app/xidle/xidle.c

Not sure what I’m supposed to see there but okay…

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#968034: xidle: introduction of setsid() call introduces undocumented behaviour changes

[Thorsten Glaser]

Marcel Partap dixit:

>in my user .tmux.conf, I have put following mechanism

This is a very complex setup; I cannot easily reproduce what exactly
makes this fail for you.

>https://www.mail-archive.com/tech@openbsd.org/msg49105.html

As I said in my earlier mail, this patch combines multiple changes
and is… tricky.

Matthieu, can you have a look at it as well as the change
http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/xidle/xidle.c.diff?r1=1.3=1.4
possibly introducing the problem for our user?

I’m seeing multiple things here:

• closing stdout and stderr: I agree with that output should go
  to .xsession-errors (if open) and would remove that, redirecting
  only stdin from /dev/null

• using execvp: this makes me cringe, both the change and the
  current code also. I’d propose introducing two new ways of
  specifying the command to run. One would take one argument,
  like -program does, but actually run sh -c  (with
  shell interpolation, pipes, I/O redirection, etc. possible);
  the other (probably a double dash) would collect all remaining
  arguments and create an argument vector from them (whitespace-
  safe), perhaps with an -argv0 option (like exec -a in some shells)
  and retire -program entirely (or keep it for a while but document
  it as deprecated, to avoid breaking users right now)

• calling setsid(2): is this deliberate? What are the effects of
  doing so vs. not doing so for the programs run?

  If this is deliberate, perhaps we can introduce a -keepsession
  flag that would omit the call to setsid(2) only, for use cases
  like Marcel’s.

>noticed the introduction of a setsid() call, which seem to be the source of the

Are you sure about this? That is, if you locally recompile xidle with
just the call to setsid removed, does your scenatio work?

Thanks,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#963396: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure

[Pierre Gruet]

Hi Andreas,

Le 07/08/2020 à 13:40, Andreas Tille a écrit :
> Hi Thorsten,
> 
> On Thu, Aug 06, 2020 at 04:04:22PM +0200, Thorsten Glaser wrote:
>> On Thu, 6 Aug 2020, Andreas Tille wrote:
>>
>>> [ERROR] 
>>> /build/jimfs-1.1/jimfs/src/main/java/com/google/common/jimfs/PathService.java:[290,30]
>>>  error:  is not abstract 
>>> and does not override abstract method test(Object) in Predicate
>>
>> Change apply to test in line 292 (or let the IDE convert it to lambda).
> 
> I tried to implement this in
> 
> 
> https://salsa.debian.org/java-team/jimfs/-/commit/2d67acb2f577596a121622a94295407e22155eed
> 
> but this does not help much and the build issue remains.
>
I suggest using the enclosed patch, which allows the build to succeed by
overriding the ``test'' method of Predicate. The ``apply'' method
provided by upstream has to be kept as it is used by the ``test'' method.
The definition in the patch is the same as in Predicate. ``test'' is
a default method in the interface Predicate, I thus don't see why it
needs an override... Nevertheless, this fixes the issue.

> 
> Thanks for the attempt to help anyway
> 
>Andreas.
> 

All the best,
Pierre
Description: Providing Override of test method
Author: Pierre Gruet 
Last-Update: 2020-08-07

--- a/jimfs/src/main/java/com/google/common/jimfs/PathService.java
+++ b/jimfs/src/main/java/com/google/common/jimfs/PathService.java
@@ -292,5 +292,10 @@
 public boolean apply(Object input) {
   return !input.toString().isEmpty();
 }
+
+@Override
+public boolean test (Object input) {
+  return apply(input);
+}
   };
 }

Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

[Marc Haber]

On Thu, Aug 06, 2020 at 11:40:23PM +0200, Michael Biebl wrote:
> Am 06.08.20 um 14:25 schrieb Marc Haber:
> > On Tue, Jul 14, 2020 at 09:13:15PM +0100, Hugh Cole-Baker wrote:
> >> It turns out this is just caused by running a 5.8-rc kernel with systemd
> >> compiled against linux-libc-dev 5.7, there's a new capability cap_bpf
> >> that systemctl fails to display since it's not in linux/capability.h.
> >>
> >> The same issue is described here, with a link to the upstream fix:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1853736
> > 
> > Thanks for the accurate description. This also happens when a stable
> > system is running a 5.8 release kernel. Can this fix possibly be applied
> > in stable as well?
> 
> I'll add this to the list of things to consider for the next stable upload.

Thank you very much. This doesn't seem to be as easy as we think.
417770f3033c426ca848b158d0bf057cd8ad1329 applies to
systemd_241-7~deb10u4 with a bit of fuzz, but the test test-cap-list
does still fail, at least on a system with kernel 5.8.

When I disable the tests, the resulting packages install fine, the issue
with systemctl show is gone, and the system seems to run fine.

So the commit has the fix right but the test wrong.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#946046: not fixed

[Vincent Lefevre]

On 2020-08-07 22:24:10 +0200, Vincent Lefevre wrote:
> This is not sufficient to synchronize with Debian 10 (buster).
> It depends only on unison, which depends on unison-2.48, and
> with the latest version of unison-2.48, I get lots of errors:
> 
> Failed: Server: Fatal error during unmarshaling (input_value: ill-formed 
> message),
> possibly because client and server have been compiled with differentversions 
> of the OCaml compiler.

And this has the effect to corrupt the archive files!

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

Bug#946046: not fixed

[Vincent Lefevre]

Control: reopen -1
Control: found -1 2.48.4+2

On 2020-08-05 07:51:04 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the unison-all package:
> 
> #946046: unison-all should also depend on the old unison version, compatible 
> with Debian 10
> 
> It has been closed by Debian FTP Masters  
> (reply to Stéphane Glondu ).
[...]
> Date: Wed, 05 Aug 2020 09:28:33 +0200
> Source: meta-unison
> Architecture: source
> Version: 2.48.4+1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian OCaml Maintainers 
> Changed-By: Stéphane Glondu 
> Closes: 946046
> Changes:
>  meta-unison (2.48.4+1) unstable; urgency=medium
>  .
>* Change packaging structure (Closes: #946046)
>  - add new binary packages unison and unison-gtk that depend on
>new unison-2.48 and unison-2.48-gtk and provide symlinks

This is not sufficient to synchronize with Debian 10 (buster).
It depends only on unison, which depends on unison-2.48, and
with the latest version of unison-2.48, I get lots of errors:

Failed: Server: Fatal error during unmarshaling (input_value: ill-formed 
message),
possibly because client and server have been compiled with differentversions of 
the OCaml compiler.

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

Bug#967971: jhead: A Segmentation fault error in jhead 1:3.04-2

[Ludovic Rousseau]

I can reproduce the problem now.
Thanks

Le 07/08/2020 à 18:48, Anshunkang Zhou a écrit :

Hi, here is the steps to reproduce this bug, you should unzip the attached file 
and run it:

```
seviezhou@ubuntu:~$ git clone https://salsa.debian.org/debian/jhead.git
Cloning into 'jhead'...
remote: Enumerating objects: 814, done.
remote: Counting objects: 100% (814/814), done.
remote: Compressing objects: 100% (311/311), done.
remote: Total 814 (delta 436), reused 755 (delta 392), pack-reused 0
Receiving objects: 100% (814/814), 179.29 KiB | 283.00 KiB/s, done.
Resolving deltas: 100% (436/436), done.
Checking connectivity... done.
seviezhou@ubuntu:~$ cd jhead/
seviezhou@ubuntu:~/jhead$ CC="gcc -g -fsanitize=address" make -j
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jhead.c -o jhead.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jpgfile.c -o 
jpgfile.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jpgqguess.c -o 
jpgqguess.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c paths.c -o paths.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c exif.c -o exif.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c iptc.c -o iptc.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c gpsinfo.c -o 
gpsinfo.o
gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c makernote.c -o 
makernote.o
gcc -g -fsanitize=address -Wl,-Bsymbolic-functions -Wl,-z,relro -o jhead 
./jhead.o ./jpgfile.o ./jpgqguess.o ./paths.o ./exif.o ./iptc.o ./gpsinfo.o 
./makernote.o  -lm
./jhead.o: In function `DoCommand':
/home/seviezhou/jhead/jhead.c:379: warning: the use of `mktemp' is dangerous, 
better use `mkstemp' or `mkdtemp'
seviezhou@ubuntu:~/jhead$ ./jhead -ft -exifmap -de -purejpg -di -dx 
./SEGV-Get32s-exif-333
Map: 8-00158: Directory
Map: 00158-00167:   Data for tag 010f
Map: 00168-00184:   Data for tag 0110
Map: 00184-00192:   Data for tag 011a
Map: 00192-00200:   Data for tag 011b

Nonfatal Error : './SEGV-Get32s-exif-333' Too many components -65535 for tag 
0002 in Exif
Map: 00200-00211:   Data for tag 0131
Map: 00212-00232:   Data for tag 0132
Map: 00232-00237:   Data for tag 8298
Map: 00266-00704: Directory
Map: 00704-00712:   Data for tag 829a
Map: 00712-00720:   Data for tag 829d

Nonfatal Error : './SEGV-Get32s-exif-333' Inappropriate format (3) for Exif GPS 
coordinates!

Nonfatal Error : './SEGV-Get32s-exif-333' Inappropriate format (3) for Exif GPS 
coordinates!
ASAN:SIGSEGV
=
==77365==ERROR: AddressSanitizer: SEGV on unknown address 0x61a3f28c (pc 
0x0040a901 bp 0x sp 0x7ffeadf0f830 T0)
     #0 0x40a900 in Get32s /home/seviezhou/jhead/exif.c:333
     #1 0x410d94 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:138
     #2 0x40d282 in ProcessExifDir /home/seviezhou/jhead/exif.c:866
     #3 0x40d209 in ProcessExifDir /home/seviezhou/jhead/exif.c:852
     #4 0x40d947 in process_EXIF /home/seviezhou/jhead/exif.c:1041
     #5 0x407fbf in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287
     #6 0x408210 in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379
     #7 0x404e66 in ProcessFile /home/seviezhou/jhead/jhead.c:905
     #8 0x4025d5 in main /home/seviezhou/jhead/jhead.c:1756
     #9 0x7f8d56c7c83f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
     #10 0x403b08 in _start (/home/seviezhou/jhead/jhead+0x403b08)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/exif.c:333 Get32s
==77365==ABORTING
```
On 08/8/2020 00:33，Ludovic Rousseau 
 wrote：

Hello,

I can't reproduce the crash.
I tried with the normal binary and also a new build using your arguments.

I get a lot of "Nonfatal Error : 'SEGV-Get32s-exif-333' Illegal number format 
1024 for tag  in Exif"
but NO crash.

How can I reproduce the problem?

Bye

Le 06/08/2020 à 05:14, Anshunkang Zhou a écrit :

Package: jhead
Version: 1:3.04-2
Severity: important

Dear Maintainer,

I found a segmentation fault in the latest version of jhead, detailed
information is as follows, the poc is in the mail attachment.

## System info

Ubuntu x86_64, gcc , jhead (latest 1:3.04-2)

## Configure

CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make

## 

Bug#968055: journal uses an unsupported feature, ignoring file

[Michael Biebl]

Am 07.08.20 um 18:02 schrieb Michael Biebl:
> Am 07.08.20 um 15:22 schrieb 積丹尼 Dan Jacobson:

>> # journalctl -f
>> Journal file 
>> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>>  uses an unsupported feature, ignoring file.
>> Use SYSTEMD_LOG_LEVEL=debug journalctl 
>> --file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>>  to see the details.
>>
>> # SYSTEMD_LOG_LEVEL=debug journalctl 
>> --file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>> Journal effective settings seal=no compress=no compress_threshold_bytes=8B
>> Journal file 
>> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>>  has unknown incompatible flags 0xc
>> Failed to open journal file 
>> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal:
>>  Protocol not supported
>> mmap cache statistics: 0 hit, 1 miss
>> Failed to open files: Protocol not supported
>>
>> Maybe this was caused by me
>> downgrading 246-2 to 245.7-1 ?
> 
> Correct. Keep in mind, that downgrades are in general not supported.

To be more specific: journald was compiled with zstd support in v246 and
this is used as default compression, apparently. Older journalctl
versions don't support zstd.
Maybe we should keep lz4 as default compression (for one additional
release cycle), even if zstd support was enabled. This way we would have
some sort of forward compatibility.

Thoughts? Anyone willing to work on this?



signature.asc
Description: OpenPGP digital signature

Bug#968066: haskell-hgettext: autopkgtest fails with newer version of ghc

[Paul Gevers]

Source: haskell-hgettext
Version: 0.1.31.0-5
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, g...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ghc

Dear maintainer(s),

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

   passfail
ghcfrom testing8.8.3-3
haskell-hgettext   from testing0.1.31.0-5
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems there
is some versioned dependency missing somewhere, either in the test
definition or in package itself, or something really breaks
haskell-hgettext in testing and doesn't declare it. If I read the error
correctly and understand a tiny bit of the haskell packaging, something
should prevent mix and match of packages build with different versions
of ghc.

Currently this regression is blocking the migration of ghc to testing
[1]. Of course, ghc shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in ghc was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ghc should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
ghc/8.8.3-3. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=ghc

https://ci.debian.net/data/autopkgtest/testing/amd64/h/haskell-hgettext/6551760/log.gz

autopkgtest [14:11:27]: test cabal-install-compatibility:
[---
Warning: No remote package servers have been specified. Usually you
would have
one specified in the config file.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: example-0.1.0 (user goal)
[__1] next goal: example:setup.Cabal (dependency of example)
[__1] rejecting: example:setup.Cabal-3.0.1.0/installed-3.0... (conflict:
example => example:setup.Cabal>=1.8 && <1.25)
[__1] fail (backjumping, conflict set: example, example:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: example, example:setup.Cabal

autopkgtest [14:11:28]: test cabal-install-compatibility:
---]



signature.asc
Description: OpenPGP digital signature

Bug#968065: nmu: libheif_1.6.1-1

[Adrian Bunk]

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

nmu libheif_1.6.1-1 . ANY . unstable . -m "Rebuild with libjpeg-turbo that has 
bug 966409 fixed"


Package: libheif-examples
Depends: ..., libjpeg62-turbo (>= 2.0.2), ...

Due to #966409 this misses the epoch, and the dependency
could wrongly be fulfilled by the buster libjpeg62-turbo.

Bug#968064: [20190710-1]

[dimas manila]

Package: 20190710-1 Version: SoapFault - faultcode: 'SOAP-ENV:Server'
faultstring: 'Processing Failure' faultactor: 'null' detail:
org.kxml2.kdom.Node@1be349b Severity: Tags: X-Debbugs-CC: Dear Maintainer,
*** Please consider answering these questions, where appropriate *** * What
led up to the situation? * What exactly did you do (or not do) that was
effective (orineffective)? * What was the outcome of this action? * What
outcome did you expect instead? *** End of the template - remove these
lines ***

dimas_qddir

Bug#957286: gnomekiss: diff for NMU version 2.0-6.1

[Sudip Mukherjee]

Control: tags 957286 + patch
Control: tags 957286 + pending

Dear maintainer,

I've prepared an NMU for gnomekiss (versioned as 2.0-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru gnomekiss-2.0/debian/changelog gnomekiss-2.0/debian/changelog
--- gnomekiss-2.0/debian/changelog  2018-08-21 22:51:15.0 +0100
+++ gnomekiss-2.0/debian/changelog  2020-08-07 19:52:28.0 +0100
@@ -1,3 +1,10 @@
+gnomekiss (2.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957286)
+
+ -- Sudip Mukherjee   Fri, 07 Aug 2020 19:52:28 
+0100
+
 gnomekiss (2.0-6) unstable; urgency=low
 
   * Team upload.
diff -Nru gnomekiss-2.0/debian/patches/fix_ftbfs.patch 
gnomekiss-2.0/debian/patches/fix_ftbfs.patch
--- gnomekiss-2.0/debian/patches/fix_ftbfs.patch1970-01-01 
01:00:00.0 +0100
+++ gnomekiss-2.0/debian/patches/fix_ftbfs.patch2020-08-07 
19:52:03.0 +0100
@@ -0,0 +1,42 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957286
+Forwarded: no
+
+---
+
+--- gnomekiss-2.0.orig/src/callbacks.c
 gnomekiss-2.0/src/callbacks.c
+@@ -33,6 +33,7 @@ static int x1, y1, dragged;
+ static int ox, oy;
+ 
+ int mouse_x, mouse_y;
++GtkListStore *error_store;
+ 
+ void
+ on_exit_activate  (GtkMenuItem *menuitem,
+--- gnomekiss-2.0.orig/src/interface.c
 gnomekiss-2.0/src/interface.c
+@@ -26,7 +26,7 @@
+ #define GLADE_HOOKUP_OBJECT_NO_REF(component,widget,name) \
+   g_object_set_data (G_OBJECT (component), name, widget)
+ 
+-extern GSettings *settings;
++GSettings *settings;
+ 
+ GtkWidget*
+ create_application (void)
+--- gnomekiss-2.0.orig/src/kiss.h
 gnomekiss-2.0/src/kiss.h
+@@ -26,8 +26,8 @@ extern GtkWidget *about, *error_list;
+ extern GtkWidget *buttons[SETS], *items[SETS];
+ 
+ static gboolean clear_area = FALSE;
+-GSettings *settings;
+-GtkListStore *error_store;
++extern GSettings *settings;
++extern GtkListStore *error_store;
+ 
+ enum {
+   FILE_COLUMN,
diff -Nru gnomekiss-2.0/debian/patches/series 
gnomekiss-2.0/debian/patches/series
--- gnomekiss-2.0/debian/patches/series 2018-08-21 22:51:15.0 +0100
+++ gnomekiss-2.0/debian/patches/series 2020-08-07 19:43:46.0 +0100
@@ -2,3 +2,4 @@
 020_gtkspinbutton.patch
 fix-close-button-of-about-dialog.patch
 gtk3-port.patch
+fix_ftbfs.patch

Bug#968062: [20190710-1]

[dimas manila]

Package: 20190710-1 Version: SoapFault - faultcode: 'SOAP-ENV:Server'
faultstring: 'Processing Failure' faultactor: 'null' detail:
org.kxml2.kdom.Node@c90d793 Severity: Tags: X-Debbugs-CC: Dear Maintainer,
*** Please consider answering these questions, where appropriate *** * What
led up to the situation? * What exactly did you do (or not do) that was
effective (orineffective)? * What was the outcome of this action? * What
outcome did you expect instead? *** End of the template - remove these
lines ***

Bug#968049: Failed to kill unit rsyslog.service: Input/output error

[Christian Göttsche]

Is this maybe related to #720096 and #831764 ?

logrotate calling the rsyslog-rotate wrapper twice (one time for
/var/log/syslog and another time for the rest (/var/log/mail.* etc.))
and the second time rsyslog is not (yet) ready to receive the SIGHUP ?

Bug#968061: [083150171666]

[dimas manila]

Package: 083150171666 Version: SoapFault - faultcode: 'SOAP-ENV:Server'
faultstring: 'Processing Failure' faultactor: 'null' detail:
org.kxml2.kdom.Node@6d24757 Severity: Tags: X-Debbugs-CC: Dear Maintainer,
*** Please consider answering these questions, where appropriate *** * What
led up to the situation? * What exactly did you do (or not do) that was
effective (orineffective)? * What was the outcome of this action? * What
outcome did you expect instead? *** End of the template - remove these
lines ***

Bug#968060: axi-cache: string/bytes confusion in display

[rharwood]

Package: apt-xapian-index
Version: 0.51
Severity: minor
Tags: patch

Dear Maintainer,

In rdepends output:

rharwood@eesha:~$ axi-cache rdepends apt-xapian-index
apt-xapian-index
Reverse Depends:
  b'muon'
  b'packagesearch'
  b'synaptic'
  b'aptitude'
  b'python3-apt'
rharwood@eesha:~$ 

When print() is called on a `bytes` object in python3, it formats it like that
(with the leading 'b' etc.).  The smallest fix is probably to change the
print() in do_rdepends() (on line 701) from

print(" ", pkg)

to

print(" ", pkg.decode("utf-8"))

However, this probably shows up other places as well and a more invasive fix
might be better.

Thanks,
--Robbie

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

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

Versions of packages apt-xapian-index depends on:
ii  python3 3.8.2-3
ii  python3-apt 2.1.3
ii  python3-debian  0.1.37
ii  python3-xapian  1.4.15-1+b1

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
ii  python3-xdg  0.26-3

-- no debconf information

Bug#968055: journal uses an unsupported feature, ignoring file

[Michael Biebl]

Am 07.08.20 um 18:10 schrieb 積丹尼 Dan Jacobson:

> (Well I can't upgrade back until the infinite loop is fixed.)

You can either uninstall resolvconf or use the workaround I posted at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906#47






signature.asc
Description: OpenPGP digital signature

Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Paul Gevers]

Hi,

I am preparing an upload with the symbols file removed as there seems to
be consensus that using symbols files for C++ projects in Debian isn't
worth the effort.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953986: Acknowledgement (nmap-mac-prefixes outdated)

[Carsten Burkhardt]

Hello Samuel,

thanks for your help.

You updates the Vendor Prefixes only on new releases:
https://packages.debian.org/search?keywords=nmap

For example on Debian Stretch the Vendor Prefixes stuck in year 2016.

In this case all newer products can't resolve.

A fast solution is following:
wget https://svn.nmap.org/nmap/nmap-mac-prefixes -O 
/usr/share/nmap/nmap-mac-prefixes

Apt upgrade would be more nice.

Greetings
Carsten

Bug#957684: pick: diff for NMU version 2.0.2-1.1

[Sudip Mukherjee]

Control: tags 957684 + patch
Control: tags 957684 + pending

Dear maintainer,

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

--
Regards
Sudip

diff -Nru pick-2.0.2/debian/changelog pick-2.0.2/debian/changelog
--- pick-2.0.2/debian/changelog 2018-04-18 10:30:02.0 +0100
+++ pick-2.0.2/debian/changelog 2020-08-07 18:21:05.0 +0100
@@ -1,3 +1,10 @@
+pick (2.0.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957684)
+
+ -- Sudip Mukherjee   Fri, 07 Aug 2020 18:21:05 
+0100
+
 pick (2.0.2-1) unstable; urgency=medium
 
   * New upstream version 2.0.2
diff -Nru pick-2.0.2/debian/patches/fix_ftbfs.patch 
pick-2.0.2/debian/patches/fix_ftbfs.patch
--- pick-2.0.2/debian/patches/fix_ftbfs.patch   1970-01-01 01:00:00.0 
+0100
+++ pick-2.0.2/debian/patches/fix_ftbfs.patch   2020-08-07 18:18:00.0 
+0100
@@ -0,0 +1,20 @@
+Description: Fix ftbfs with GCC-10
+ Rename the unused variable.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957684
+Forwarded: no
+
+---
+
+--- pick-2.0.2.orig/compat-reallocarray.c
 pick-2.0.2/compat-reallocarray.c
+@@ -7,7 +7,7 @@
+  * compile. Since the point of this file is to not exist, declare an unused
+  * variable here.
+  */
+-int unused;
++int another_unused;
+ 
+ #ifndef HAVE_REALLOCARRAY
+ 
diff -Nru pick-2.0.2/debian/patches/series pick-2.0.2/debian/patches/series
--- pick-2.0.2/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ pick-2.0.2/debian/patches/series2020-08-07 18:16:49.0 +0100
@@ -0,0 +1 @@
+fix_ftbfs.patch

Bug#968059: cmark: outdated manpage

[Russell Hernandez Ruiz]

Package: cmark
Version: 0.29.0-2~bpo10+1
Severity: normal

Dear Maintainer,

I tried to use the documented `--normalize` option. However, that
option has not existed since version 0.27, so my script failed.

I checked and this is still a problem in bullseye.

I went down the rabbit whole and long story short this is an upstream
problem. When they merged pull request #194, they did not update the
manpage.

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

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

Versions of packages cmark depends on:
ii  libc6  2.28-10

cmark recommends no packages.

cmark suggests no packages.

-- debconf-show failed

Bug#966816: lvm2: Patch to fix the problem

[Asher Gordon]

Asher Gordon  writes:

> It seems that this problem was present for quite a while, so I'm not
> sure why I didn't notice it before.

Ah, it's because the bug only came up after the new release
(2.03.09-2). The bug lay dormant in 2.03.09-1. That's because
'--bindir=/bin' was removed from debian/rules in commit 5df1ae4 in order
to fix #929437. (That commit was between debian/2.03.09-1 and
debian/2.03.09-2.)

So that's why I didn't notice it before.

Thanks,
Asher

-- 
If you stand on your head, you will get footprints in your hair.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#968058: RFS: kas/2.1.1-2 -- Setup tool for bitbake based projects

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "kas". A source-only update is
needed to help it migrate to testing.

 * Package name: kas
   Version : 2.1.1-2
   Upstream Author : Jan Kiszka 
 * URL : https://github.com/siemens/kas
 * License : Expat
 * Vcs : https://salsa.debian.org/python-team/applications/kas
   Section : devel

It builds those binary packages:

  kas - Setup tool for bitbake based projects

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/k/kas/kas_2.1.1-2.dsc

Changes since the last upload:

 kas (2.1.1-2) unstable; urgency=medium
 .
   * Clean build leftovers
   * Use pristine-tar as required by DPMT

Regards,

Bug#957928: welcome2l: diff for NMU version 3.04-27.1

[Sudip Mukherjee]

Control: tags 957928 + patch
Control: tags 957928 + pending

Dear maintainer,

I've prepared an NMU for welcome2l (versioned as 3.04-27.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru welcome2l-3.04/debian/changelog welcome2l-3.04/debian/changelog
--- welcome2l-3.04/debian/changelog 2018-08-05 09:22:28.0 +0100
+++ welcome2l-3.04/debian/changelog 2020-08-07 18:02:07.0 +0100
@@ -1,3 +1,10 @@
+welcome2l (3.04-27.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957928)
+
+ -- Sudip Mukherjee   Fri, 07 Aug 2020 18:02:07 
+0100
+
 welcome2l (3.04-27) unstable; urgency=medium
 
   * Switch to debhelper v11.
diff -Nru welcome2l-3.04/debian/patches/10_fix_ftbfs.patch 
welcome2l-3.04/debian/patches/10_fix_ftbfs.patch
--- welcome2l-3.04/debian/patches/10_fix_ftbfs.patch1970-01-01 
01:00:00.0 +0100
+++ welcome2l-3.04/debian/patches/10_fix_ftbfs.patch2020-08-07 
18:00:25.0 +0100
@@ -0,0 +1,18 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957928
+Forwarded: no
+
+---
+
+--- welcome2l-3.04.orig/main.c
 welcome2l-3.04/main.c
+@@ -79,7 +79,6 @@ static char XMAS_AUTO = FALSE;
+ static char IS_WELCOME = TRUE;
+ static char NO_TIME = FALSE;
+ char NO_BLINK = FALSE;
+-char WSCREEN[1];
+ char XMAS_SCREEN = 3;
+ #define MAX_RAND_SCREEN 4.0
+ 
diff -Nru welcome2l-3.04/debian/patches/series 
welcome2l-3.04/debian/patches/series
--- welcome2l-3.04/debian/patches/series2018-08-05 09:22:28.0 
+0100
+++ welcome2l-3.04/debian/patches/series2020-08-07 18:00:47.0 
+0100
@@ -8,3 +8,4 @@
 07_sprintf_ub.patch
 08_reproducible_builds.patch
 09_login_notty.patch
+10_fix_ftbfs.patch

Bug#967924: jhead: A Segmentation fault error in jhead 1:3.04-2

[Ludovic Rousseau]

Hello,

I can't reproduce the crash.

I get a lot of "Nonfatal Error : 'SEGV-ProcessGpsInfo-gpsinfo-122' Maximum Exif 
directory nesting exceeded (corrupt Exif header)"
but NO crash.

How can I reproduce the problem?

Thanks

On Wed, 5 Aug 2020 12:13:01 +0800 Anshunkang Zhou  wrote:
> Package: jhead
> Version: 1:3.04-2
> Severity: important
> 
> Dear Maintainer,
> 
> I found a segmentation fault in the latest version of jhead, detailed
> information is as follows, the poc is in the mail attachment.
> 
> ## System info
> 
> Ubuntu x86_64, gcc , jhead (latest 1:3.04-2)
> 
> ## Configure
> 
> CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make
> 
> ## Command line
> 
> ./jhead -ft -exifmap -de -purejpg -di -dx @@
> 
> ## Output
> 
> ```
> Segmentation fault
> ```
> 
> ## AddressSanitizer output
> 
> ```
> ASAN:SIGSEGV
> =
> ==27891==ERROR: AddressSanitizer: SEGV on unknown address
> 0x61a3f288 (pc 0x0042cb79 bp 0x0002 sp 0x7ffefb7a18f0
> T0)
> #0 0x42cb78 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:122
> #1 0x42411f in ProcessExifDir /home/seviezhou/jhead/exif.c:866
> #2 0x423e0e in ProcessExifDir /home/seviezhou/jhead/exif.c:852
> #3 0x4255e1 in process_EXIF /home/seviezhou/jhead/exif.c:1041
> #4 0x4103ad in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287
> #5 0x4117ce in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:126
> #6 0x4117ce in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379
> #7 0x408e4e in ProcessFile /home/seviezhou/jhead/jhead.c:905
> #8 0x402e40 in main /home/seviezhou/jhead/jhead.c:1756
> #9 0x7ff98ecdf83f in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
> #10 0x406c88 in _start (/home/seviezhou/jhead/jhead+0x406c88)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/gpsinfo.c:122
> ProcessGpsInfo
> ==27891==ABORTING
> ```

Bug#890627: getting worse

[Ilias Tsitsimpis]

Control: tags -1 + pending

On Wed, Aug 05, 2020 at 05:25PM, Joey Hess wrote:
> In the 2 years since I filed this bug report

Thanks for pinging again. I have now fixed it here:


https://salsa.debian.org/haskell-team/DHG_packages/-/commit/c3b2053654c61140c41d61d7143e040d802ae4e7

> it's also
> started hotlinking a font from google, in addition to now 2 mathjax
> js files from cloudflare.
> 
> The font seems to be packaged in Debian in fonts-paratype.

See bug #963690 for this.

Thanks,

-- 
Ilias

Bug#967971: jhead: A Segmentation fault error in jhead 1:3.04-2

[Ludovic Rousseau]

Hello,

I can't reproduce the crash.
I tried with the normal binary and also a new build using your arguments.

I get a lot of "Nonfatal Error : 'SEGV-Get32s-exif-333' Illegal number format 1024 
for tag  in Exif"
but NO crash.

How can I reproduce the problem?

Bye

Le 06/08/2020 à 05:14, Anshunkang Zhou a écrit :

Package: jhead
Version: 1:3.04-2
Severity: important

Dear Maintainer,

I found a segmentation fault in the latest version of jhead, detailed
information is as follows, the poc is in the mail attachment.

## System info

Ubuntu x86_64, gcc , jhead (latest 1:3.04-2)

## Configure

CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make

## Command line

./jhead -ft -exifmap -de -purejpg -di -dx @@

## Output

```
Segmentation fault
```

## AddressSanitizer output

```
ASAN:SIGSEGV
=
==17939==ERROR: AddressSanitizer: SEGV on unknown address
0x61a3f28c (pc 0x0041a7f0 bp 0x sp 0x7ffc54eee3a0
T0)
 #0 0x41a7ef in Get32s /home/seviezhou/jhead/exif.c:333
 #1 0x42c908 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:138
 #2 0x42411f in ProcessExifDir /home/seviezhou/jhead/exif.c:866
 #3 0x423e0e in ProcessExifDir /home/seviezhou/jhead/exif.c:852
 #4 0x4255e1 in process_EXIF /home/seviezhou/jhead/exif.c:1041
 #5 0x4103ad in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287
 #6 0x4117ce in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:126
 #7 0x4117ce in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379
 #8 0x408e4e in ProcessFile /home/seviezhou/jhead/jhead.c:905
 #9 0x402e40 in main /home/seviezhou/jhead/jhead.c:1756
 #10 0x7ffacc7e783f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
 #11 0x406c88 in _start (/home/seviezhou/jhead/jhead+0x406c88)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/exif.c:333 Get32s
==17939==ABORTING
```




--
Dr. Ludovic Rousseau

Bug#966069: analysis and partial patch

[Ilias Tsitsimpis]

Control: tags -1 + pending

Hey Joey,

On Wed, Aug 05, 2020 at 05:15PM, Joey Hess wrote:
> ghc-pkg dump output has changed slightly, it now indents values with spaces
> to make then line up or something

Thanks for digging into this.

> This patch partially fixed it for me, but does not deal with the line 
> wrapping,
> which would take more of a rfc-822 type parser than this.

I followed a different approach and used `ghc-pkg field` to parse the
package database [1]. It seems to be working for me, but would be great
if you could test it as well.

[1] 
https://salsa.debian.org/haskell-team/DHG_packages/-/commit/24ecab15f29b87d6a0293e9cbb9a4305ab6e45b1

Thanks,

-- 
Ilias

Bug#926210: even newer upstream version

[Bobby de Vos]

Greetings,

The upstream version of TECkit is now 2.5.10. Can this latest version be
packaged?

Thanks, Bobby

-- 
Bobby de Vos
/bobby_de...@sil.org/



signature.asc
Description: OpenPGP digital signature

Bug#963690: ghc: Haddock uses fonts from URL

[Ilias Tsitsimpis]

Control: forwarded -1 https://github.com/haskell/haddock/issues/1211
Control: tags -1 + pending

It seems that these fonts are not necessary for the docs to be rendered
correctly, so I am going to patch haddock and remove them until upstream
can add an option to override them.

-- 
Ilias

Bug#968038: sysvinit-utils: do_restart fails when not ran from a terminal

[Stephane Lapie]

Yes, indeed, something should probably be done with regards to that too.

I didn't tweak that bit in my suggestion because I balked at the potential
implications of altering what parameters a hook expects, after pinpointing
why it surfaced only in snmpd on Buster/sysvinit. (It SHOULD be safe now
that I think about it, but I wouldn't dare guarantee everything would work
fine and as intended without testing every package using that script)
-- 
ラピー ステファン Lapie Stephane
株式会社朝日ネット システム第1部
〒104-0061 東京都中央区銀座4-12-15 歌舞伎座タワー21F
TEL : 03-3541-9590(代表) 03-3541-9591(直通) FAX : 03-3541-5633
E-MAIL: stephane.la...@asahinet.com

Bug#968034: xidle: introduction of setsid() call introduces undocumented behaviour changes

[Thorsten Glaser]

Marcel Partap dixit:

>noticed the introduction of a setsid() call, which seem to be the source of the
>issue... there is no note about change in behaviour in documentation which is
>why I'm filing this issue ^^

Yeah, the upstream source was imported from OpenBSD in a whole batch.

>.. also found patches in this thread
>https://www.mail-archive.com/tech@openbsd.org/msg49105.html
>to revert the behaviour change (e.g. by cloning stdout file descriptors); but
>that has not gotten integrated "as of yet".

Thanks for tracking this down upstream. I’ll have a look at it and
will consider merging it; it mixes multiple changes in one patch so
I will need to have more than a casual look first. (Or, you can push
for OpenBSD to commit it, then ping me.)

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#968055: journal uses an unsupported feature, ignoring file

[積丹尼 Dan Jacobson]

>> Maybe this was caused by me
>> downgrading 246-2 to 245.7-1 ?

MB> Correct. Keep in mind, that downgrades are in general not supported.

(Well I can't upgrade back until the infinite loop is fixed.)

Bug#968057: local mail injection fails: cleanup process killed by signal 11

[Jamie McClelland]

Package: postfix
Version: 3.4.14-0+deb10u1

When a messaage is in the maildrop queue, it can't get out.

Each time cleanup is run, the cleanup process dies:

Aug 06 16:57:30 amilcar postfix/pickup[11470]: warning:
maildrop/88D7A333A: error writing 7082252D6: queue file write error
Aug 06 16:57:30 amilcar postfix/master[6205]: warning: process
/usr/lib/postfix/sbin/cleanup pid 18641 killed by signal 11

Attached is an strace of the cleanup process, which ends with:

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---


strace: Process 12050 attached
wait4(12051, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 12051
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, 
sa_restorer=0x7ff7e46c0840}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, 
sa_restorer=0x7ff7e46c0840}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12051, si_uid=0, 
si_status=0, si_utime=0, si_stime=0} ---
openat(AT_FDCWD, "pid/unix.cleanup", O_RDWR) = 8
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("pid/unix.cleanup", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fcntl(8, F_GETFD)   = 0
fcntl(8, F_SETFD, FD_CLOEXEC)   = 0
chdir("/var/spool/postfix") = 0
openat(AT_FDCWD, "/etc/postfix/virtual_alias_maps.db", O_RDONLY) = 9
flock(9, LOCK_SH)   = 0
getpid()= 12050
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 10
read(10, "0-3\n", 8192) = 4
close(10)   = 0
openat(AT_FDCWD, "/etc/postfix/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=1064960, ...}) = 0
stat("/etc/postfix/virtual_alias_maps.db", {st_mode=S_IFREG|0644, 
st_size=12288, ...}) = 0
stat("/etc/postfix/virtual_alias_maps.db", {st_mode=S_IFREG|0644, 
st_size=12288, ...}) = 0
openat(AT_FDCWD, "/etc/postfix/virtual_alias_maps.db", O_RDONLY) = 10
fcntl(10, F_GETFD)  = 0
fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
read(10, 
"\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\t\0\0\0\0\20\0\0\0\10\0\0\0\0\0\0"..., 512) = 
512
stat("/etc/postfix/virtual_alias_maps.db", {st_mode=S_IFREG|0644, 
st_size=12288, ...}) = 0
openat(AT_FDCWD, "/etc/postfix/virtual_alias_maps.db", O_RDONLY) = 11
fcntl(11, F_GETFD)  = 0
fcntl(11, F_SETFD, FD_CLOEXEC)  = 0
fstat(11, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
pread64(11, 
"\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\t\0\0\0\0\20\0\0\0\10\0\0\0\0\0\0"..., 4096, 
0) = 4096
flock(9, LOCK_UN)   = 0
close(9)= 0
fstat(11, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
stat("/etc/postfix/virtual_alias_maps", {st_mode=S_IFREG|0644, st_size=2062, 
...}) = 0
fcntl(11, F_GETFD)  = 0x1 (flags FD_CLOEXEC)
fcntl(11, F_SETFD, FD_CLOEXEC)  = 0
fcntl(11, F_GETFD)  = 0x1 (flags FD_CLOEXEC)
fcntl(11, F_SETFD, FD_CLOEXEC)  = 0
stat("/usr/lib/postfix/postfix-pcre.so", {st_mode=S_IFREG|0644, st_size=18664, 
...}) = 0
futex(0x7ff7e66ea0c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/usr/lib/postfix/postfix-pcre.so", O_RDONLY|O_CLOEXEC) = 9
read(9, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\22\0\0\0\0\0\0"..., 
832) = 832
fstat(9, {st_mode=S_IFREG|0644, st_size=18664, ...}) = 0
mmap(NULL, 20816, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 9, 0) = 0x7ff7e6c9e000
mmap(0x7ff7e6c9f000, 8192, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x1000) = 0x7ff7e6c9f000
mmap(0x7ff7e6ca1000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 
0x3000) = 0x7ff7e6ca1000
mmap(0x7ff7e6ca2000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x3000) = 0x7ff7e6ca2000
close(9)= 0
openat(AT_FDCWD, "/usr/lib/postfix/libpcre.so.3", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=50685, ...}) = 0
mmap(NULL, 50685, PROT_READ, MAP_PRIVATE, 9, 0) = 0x7ff7e434
close(9)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 9
read(9, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340!\0\0\0\0\0\0"..., 
832) = 832
fstat(9, {st_mode=S_IFREG|0644, st_size=469248, ...}) = 0
mmap(NULL, 471528, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 9, 0) = 0x7ff7e42cc000
mmap(0x7ff7e42ce000, 335872, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x2000) = 0x7ff7e42ce000
mmap(0x7ff7e432, 122880, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 
0x54000) = 0x7ff7e432
mmap(0x7ff7e433e000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x71000) = 0x7ff7e433e000
close(9)= 

Bug#968056: nanoc: missing dependency on ruby-nanoc-cli

[Antonio Terceiro]

Package: nanoc
Version: 4.11.14-1
Severity: serious
Justification: missind dependency for normal operation

Hello, thanks for updating nanoc. After upgrading from 4.11.0, nanoc now
fails right away:

8<8<8<-
$ nanoc
Traceback (most recent call last):
8: from /usr/bin/nanoc:23:in `'
7: from /usr/lib/ruby/vendor_ruby/rubygems.rb:297:in `activate_bin_path'
6: from /usr/lib/ruby/vendor_ruby/rubygems.rb:297:in `synchronize'
5: from /usr/lib/ruby/vendor_ruby/rubygems.rb:298:in `block in 
activate_bin_path'
4: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1363:in 
`activate'
3: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate_dependencies'
2: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`each'
1: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1393:in 
`block in activate_dependencies'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:308:in `to_specs': Could not 
find 'nanoc-cli' (= 4.11.14) among 439 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/home/terceiro/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
 , execute `gem env` for more information
8: from /usr/bin/nanoc:23:in `'
7: from /usr/lib/ruby/vendor_ruby/rubygems.rb:297:in `activate_bin_path'
6: from /usr/lib/ruby/vendor_ruby/rubygems.rb:297:in `synchronize'
5: from /usr/lib/ruby/vendor_ruby/rubygems.rb:298:in `block in 
activate_bin_path'
4: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1363:in 
`activate'
3: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate_dependencies'
2: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`each'
1: from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1392:in 
`block in activate_dependencies'
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1395:in `rescue in block in 
activate_dependencies': Could not find 'nanoc-cli' (= 4.11.14) among 439 total 
gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/home/terceiro/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
 at: /usr/share/rubygems-integration/all/specifications/nanoc-4.11.14.gemspec, 
execute `gem env` for more information
8<8<8<-

nanoc needs to depend on (or at least recommend) ruby-nanoc-cli.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nanoc depends on:
ii  pry   0.13.1-1
ii  ruby  1:2.7+2~0.2020.07.17.17.04.8afbadd
ii  ruby-addressable  2.7.0-1
ii  ruby-adsf 1.4.3+dfsg1-2
ii  ruby-brandur-json-schema  0.19.1-1
ii  ruby-colored  1.2-2
ii  ruby-cri  2.15.10-1
ii  ruby-hamster  3.0.0-2
ii  ruby-listen   3.2.1-1
ii  ruby-nanoc-core   4.11.14-1
ii  ruby-parallel 1.19.1-1
ii  ruby-ref  2.0.0-1
ii  ruby-tomlrb   1.3.0-1
ii  ruby-tty-command  0.9.0-2
ii  ruby-tty-which0.4.2-2

Versions of packages nanoc recommends:
ii  asciidoc-base   9.0.0~rc2-1
ii  asciidoctor 2.0.10-2
ii  ruby-builder3.2.4-1
ii  ruby-coffee-script  2.4.1-2
ii  ruby-erubi  1.9.0-1
ii  ruby-erubis 2.7.0-3
ii  ruby-haml   5.1.2-2
ii  ruby-kramdown   1.17.0-4
ii  ruby-maruku 0.7.3-1
ii  ruby-mime-types 3.3.1-1
ii  ruby-mustache   1.0.2-1
ii  ruby-nokogiri   1.10.9+dfsg-1
ii  ruby-nokogumbo  1.4.2+ds-2
ii  ruby-rdiscount  2.1.8-1+b7
ii  ruby-redcarpet  3.5.0-2
ii  ruby-redcloth   4.3.2-3+b3
ii  ruby-rouge  3.21.0-1
ii  ruby-rubypants  0.6.0-1
ii  ruby-sass   3.7.4-3
ii  ruby-slim   4.0.1-3
ii  ruby-uglifier   2.7.2+dfsg-2

Versions of packages nanoc suggests:
ii  coderay   1.1.2-3
ii  git   1:2.28.0-1
ii  python3-pygments  2.3.1+dfsg-4
ii  rsync 3.2.2-2
ii  ruby-fog-core 2.1.0-3
ii  

Bug#968038: sysvinit-utils: do_restart fails when not ran from a terminal

[Thorsten Glaser]

On Fri, 7 Aug 2020, Stephane Lapie wrote:

>   if is_call_implemented do_start_cleanup ; then
>   call do_start_cleanup

Shouldnt the hook be passed $result as well, so it can see
whether the start was successful or not?

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#963396: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure

[Thorsten Glaser]

On Fri, 7 Aug 2020, Andreas Tille wrote:

> but this does not help much and the build issue remains.

Erk… then I don’t know either.

Sorry,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#968055: journal uses an unsupported feature, ignoring file

[Michael Biebl]

Am 07.08.20 um 15:22 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 245.7-1
> 
> I never touched any of this.
> 
> # journalctl -f
> Journal file 
> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>  uses an unsupported feature, ignoring file.
> Use SYSTEMD_LOG_LEVEL=debug journalctl 
> --file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>  to see the details.
> 
> # SYSTEMD_LOG_LEVEL=debug journalctl 
> --file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
> Journal effective settings seal=no compress=no compress_threshold_bytes=8B
> Journal file 
> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
>  has unknown incompatible flags 0xc
> Failed to open journal file 
> /var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal:
>  Protocol not supported
> mmap cache statistics: 0 hit, 1 miss
> Failed to open files: Protocol not supported
> 
> Maybe this was caused by me
> downgrading 246-2 to 245.7-1 ?

Correct. Keep in mind, that downgrades are in general not supported.




signature.asc
Description: OpenPGP digital signature

Bug#968041: lintian: fails with internal error

[Felix Lechner]

Hi,

On Fri, Aug 7, 2020 at 8:06 AM Raphaël Hertzog
 wrote:
>
> I get the same error for lzop as well as for unzip.

Thanks, lzop was added too:


https://salsa.debian.org/lintian/lintian/-/commit/424208c0365c401a89577742e6db5f7aee715fc1

Kind regards
Felix Lechner

Bug#964661: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps

[Jessica Clarke]

On 29 Jul 2020, at 09:04, Michael Meskes  wrote:
> 
> On Mon, Jul 27, 2020 at 03:01:31PM +0100, Jessica Clarke wrote:
>> Package: bsdmainutils
>> Version: 12.1.3
>> Severity: serious
>> Control: affects -1 src:freebsd-buildutils src:freebsd-glue src:freebsd-libs
>> 
>> Hi,
>> The removal of lorder in 12.1.3 causes various freebsd-* packages to
>> FTBFS which are now scheduled for autoremoval from testing. Please
>> restore this shell script; it's not deprecated, it's still widely used
>> by the BSDs and maintained in at least FreeBSD.
> 
> I'm surprised it is actually used as it was pointed out to me that the script
> has been non-functional for quite a while.

I do recall having an issue with it at one point a few years back and
meaning to submit a patch to bsdmainutils to fix it, but resolved it
one way or another without that, though can't find any evidence of that
nor can I remember what the problem was. But regardless, it was working
well enough for the freebsd-* packages to build fine.

> Anyway, it cannot easily be "restored"
> because the old bsdmainutils package does not exist anymore. All tools except
> ncal and calendar, which are now in their own package, are now build out of
> util-linux. Would it be possible to include lorder.sh in one of the affected
> freebsd packages?

Yeah, it's possible, and that's no doubt what I'll end up doing. But I
really don't appreciate all the breakage that's come about from
bsdmainutils in the past few months. The util-linux handover was
poorly-handled causing all kinds of problems across the archives
(release and ports), and this removal of something, and thus
*deliberately breaking* the package's "API", should have been done more
carefully by checking whether anyone is actually using it (archive-wide
rebuilds like is done for the new GCC versions is the
easy-but-computationally-expensive way to do it). As it stands, I got
hit with a surprise set of RC bugs from the first archive-wide rebuild
after this change landed, and I therefore have to react in a
time-pressured way to fix it lest packages be removed from testing
(though, arguably, testing doesn't matter so much for these given
kfreebsd-* aren't release architectures). This really should have been
found out first, with Severity: important bugs filed a month or more in
advance of making the change, that can then be upgraded to be
release-critical further down the line. So, please, never do a
transition like this again.

Jess

Bug#967918: (no subject)

[Steve McIntyre]

On Fri, Aug 07, 2020 at 11:54:49AM +0100, Aperture wrote:
>Patch has also been submitted in salsa as:
>
>https://salsa.debian.org/installer-team/partman-efi/-/merge_requests/1

ACK, thanks. Merged now, will do an upload shortly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Bug#968042: upgrading packet python2 from 2.7.17-2 up to 2.7.18-2 asks packets deletion

[Vladmimir Stavrinov]

Package: python
Followup-For: Bug #968042

Now there are no problems with python2 but dependencies are still broken for 
python itself:

apt-get install python
Reading package lists... Done
Building dependency tree
Reading state information... Done
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:
 python : PreDepends: python-minimal (= 2.7.17-2) but it is not going to be 
installed
  Depends: libpython-stdlib (= 2.7.17-2) but it is not going to be 
installed
  Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be installed
E: Unable to correct problems, you have held broken packages.


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

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

Versions of packages python depends on:
pn  libpython-stdlib  
pn  python-minimal
ii  python2   2.7.18-2
ii  python2.7 2.7.18-1

python recommends no packages.

Versions of packages python suggests:
pn  python-doc  
ii  python-tk   2.7.18-1

Bug#968041: lintian: fails with internal error

[Raphaël Hertzog]

Package: lintian
Version: 2.87.0
Followup-For: Bug #968041
User: de...@kali.org
Usertags: origin-kali

I get the same error for lzop as well as for unzip. You need to add a
dependency on lzop too.

Running lintian...
No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
eval {...} called at /usr/share/perl5/IPC/Run3.pm line 380
IPC::Run3::run3(ARRAY(0x55da48fbdba8), undef, SCALAR(0x55da48fbb910), 
SCALAR(0x55da48f85b38)) called at /usr/share/perl5/Lintian/IPC/Run3.pm line 74
Lintian::IPC::Run3::safe_qx("lzop", "--test", 
"/tmp/lintian-pool-nyK9V4GzPA/pool/a/aflplusplus/afl++-doc_2.6"...) called at 
/usr/share/lintian/checks/files/compressed/lzo.pm line 42

Lintian::files::compressed::lzo::visit_installed_files(Lintian::files::compressed::lzo=HASH(0x55da4ca63430),
 Lintian::Index::Item=HASH(0x55da484e5778)) called at 
/usr/share/perl5/Lintian/Check.pm line 88

Lintian::Check::visit_files(Lintian::files::compressed::lzo=HASH(0x55da4ca63430),
 "installed") called at /usr/share/perl5/Lintian/Check.pm line 117

Lintian::Check::run(Lintian::files::compressed::lzo=HASH(0x55da4ca63430)) 
called at /usr/share/perl5/Lintian/Check/Info.pm line 261

Lintian::Check::Info::run_check(Lintian::Check::Info=HASH(0x55da47da06b0), 
Lintian::Processable::Binary=HASH(0x55da47e60d50), 
Lintian::Group=HASH(0x55da45ed65d0)) called at 
/usr/share/perl5/Lintian/Group.pm line 419
eval {...} called at /usr/share/perl5/Lintian/Group.pm line 419
Lintian::Group::process(Lintian::Group=HASH(0x55da45ed65d0), 
HASH(0x55da45ef3e20), HASH(0x55da474e8730), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/perl5/Lintian/Pool.pm line 179
Lintian::Pool::process(Lintian::Pool=HASH(0x55da45eb97e0), 
Lintian::Profile=HASH(0x55da476f3920), SCALAR(0x55da474e8b80), 
HASH(0x55da474e8730), GLOB(0x55da477d6b80), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/lintian/commands/lintian.pm line 809
lintian::main() called at /usr/bin/lintian line 148
eval {...} called at /usr/bin/lintian line 148
internal error: cannot run files/compressed/lzo check on package 
binary:afl++-doc/2.66c-1/all
warning: skipping check of binary:afl++-doc/2.66c-1/all
No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
eval {...} called at /usr/share/perl5/IPC/Run3.pm line 380
IPC::Run3::run3(ARRAY(0x55da4ca633a0), undef, SCALAR(0x55da4c9e5690), 
SCALAR(0x55da4cc5fe48)) called at /usr/share/perl5/Lintian/IPC/Run3.pm line 74
Lintian::IPC::Run3::safe_qx("unzip", "-l", 
"/tmp/lintian-pool-nyK9V4GzPA/pool/a/aflplusplus/afl++-doc_2.6"...) called at 
/usr/share/lintian/checks/files/compressed/zip.pm line 45

Lintian::files::compressed::zip::visit_installed_files(Lintian::files::compressed::zip=HASH(0x55da4cde1618),
 Lintian::Index::Item=HASH(0x55da484ea570)) called at 
/usr/share/perl5/Lintian/Check.pm line 88

Lintian::Check::visit_files(Lintian::files::compressed::zip=HASH(0x55da4cde1618),
 "installed") called at /usr/share/perl5/Lintian/Check.pm line 117

Lintian::Check::run(Lintian::files::compressed::zip=HASH(0x55da4cde1618)) 
called at /usr/share/perl5/Lintian/Check/Info.pm line 261

Lintian::Check::Info::run_check(Lintian::Check::Info=HASH(0x55da47da05a8), 
Lintian::Processable::Binary=HASH(0x55da47e60d50), 
Lintian::Group=HASH(0x55da45ed65d0)) called at 
/usr/share/perl5/Lintian/Group.pm line 419
eval {...} called at /usr/share/perl5/Lintian/Group.pm line 419
Lintian::Group::process(Lintian::Group=HASH(0x55da45ed65d0), 
HASH(0x55da45ef3e20), HASH(0x55da474e8730), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/perl5/Lintian/Pool.pm line 179
Lintian::Pool::process(Lintian::Pool=HASH(0x55da45eb97e0), 
Lintian::Profile=HASH(0x55da476f3920), SCALAR(0x55da474e8b80), 
HASH(0x55da474e8730), GLOB(0x55da477d6b80), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/lintian/commands/lintian.pm line 809
lintian::main() called at /usr/bin/lintian line 148
eval {...} called at /usr/bin/lintian line 148
internal error: cannot run files/compressed/zip check on package 
binary:afl++-doc/2.66c-1/all
warning: skipping check of binary:afl++-doc/2.66c-1/all


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

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

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 

Bug#919525: race condition between sshguard and ufw on startup

[Fabrice Meyer]

Looks like this one is fixed: here is the service file of 2.3.1-1 realease

[Unit]Description=SSHGuard
Documentation=man:sshguard(8)
After=network.target
Before=sshd.service

You may consider to close this bug



On Wed, 16 Jan 2019 22:53:58 +0100 Simon Vetter
 wrote:
> Package: sshguard
> Version: 1.7.1-1
>
> On systems with ufw (uncomplicated firewall, a popular firewall
manager/frontend) *and* sshguard installed, a race condition exists
between sshguard's firewall setup script and ufw.
>
> As I understand it, ufw calls iptables-restore on multiple files on
startup to create and populate its various chains.
> If, during one of those calls, /usr/lib/sshguard/firewall is called to
add the sshguard chain, the iptable-restore call fails and ufw cracks open.
> This has bitten me a few times, leaving remote boxes unreachable over
the network after a reboot since ufw was unable to restore all of its rules.
>
> sshguard's systemd service file seems to have an After= directive
which should prevent this, as ufw specifies a Before=network.target
directive.
>
> [Unit]
> Description=SSHGuard
> Documentation=man:sshguard(8)
> After=network.service
> Before=sshd.service
>
> Since none of my Debian systems have a network.service file, I tried
changing "After=network.service" to "After=network.target", which did
the trick: sshguard is now started well after ufw, and after tens of
reboots I haven't seen the issue come up again.
>
> Given my limited systemd knowledge, this may or may not be the best
fix, but I believe something along these lines should be changed and a
new package published.
>
> This is on Debian 9.6 (latest at the time of this writing), all
packages up to date.
>
> Cheers,
> -Simon
>
> --
> --
> Simon Vetter
> Embedded Software Engineer - EDF store & forecast
> Phone: +33 7 83 40 26 11
>
-- 
**Fabrice MEYER*
Software and System Engineer*

EDF Store & Forecast
13 Avenue Albert Einstein
69100 Villeurbanne
France

*fabrice.me...@edf-sf.com*
*www.edf-sf.com*

Bug#967970: redis-server crashes with jemalloc error if activedefrag is enabled

[Chris Lamb]

Hi Matthew,

> But at the same time, I wanted to be sure the community was made aware of it 
> if they were setting up the service and expected the feature to work, and 
> advise that at least a base config file comment about it could be a good idea 
> if everybody decides not to fix it.

Good idea. I'll add a comment to the config file now.

> If you could provide some advice, of the right way to temporarily disable the 
> USE_SYSTEM_JEMALLOC patch, for building a one-off Debian package of the 
> redis-server where defrag would be able to operate, probably that's good 
> enough so that somebody would see it in the public historical record if they 
> run into this later.

Simply removing (or changing) USE_SYSTEM_JEMALLOC=yes in debian/rules should be
enough.

> Thanks for your prompt reply and analysis, and for maintaining the package.

No problem. :)


Regards,

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

Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period

[micah anderson]

Hi Balint,

I looked at the patch you link to
(https://github.com/mvo5/unattended-upgrades/pull/280) but the
unattended-upgrade code that is in the diff is fairly different from
what is in the version in Buster, specifically this chunk:

-if not marking_succeeded or \
-   not check_changes_for_sanity(self, desired_pkg=pkg):
+if (not marking_succeeded
+or not check_changes_for_sanity(self, desired_pkg=pkg)) \
+and allow_marking_fallback():
logging.debug("falling back to adjusting %s's dependencies"
  % pkg.name)
self.clear()

this class UnattendedUpgradesCache(apt.Cache) is in there, but it seems
fairly different and there is no 'if not marking_succeeded' in there at
all.

-- 
micah

Bug#968041: lintian: fails with internal error

[Sudip Mukherjee]

Hi Felix,

On Fri, Aug 7, 2020 at 2:38 PM Felix Lechner  wrote:
>
> Control: tags -1 + pending
>
> Hi Sudip,
>
> On Fri, Aug 7, 2020 at 2:51 AM Sudip Mukherjee
>  wrote:
> >
> > No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
> > Lintian::IPC::Run3::safe_qx("unzip", "-l", 
> > "/tmp/lintian-pool-tbdEtEj6Sb/pool/libi/libisnativec-java/libi"...) called 
> > at
>
> Do you have the 'unzip' program installed? I think it is missing from
> Lintian's prerequisites. Fixed here:
>
> 
> https://salsa.debian.org/lintian/lintian/-/commit/2fe37725b5816551b0850d2fe431c606bf5cefa2

I pulled the HEAD from master branch and tested with that. It works.
Thanks for fixing it so quickly.

-- 
Regards
Sudip

Bug#928525: Confirming

[Fabrice Meyer]

This issue is still present, I opened a merge request on salsa with the
fix you suggested which seems to work well on my side:

https://salsa.debian.org/debian/sshguard/-/merge_requests/2

Thanks mate !


On Tue, 29 Oct 2019 17:43:56 -0400 gi1242+debianb...@gmail.com wrote:
> Confirming I have this problem too. My /etc/sshguard/sshguard.conf has
>
> LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat
SYSLOG_FACILITY=4 SYSLOG_FACILITY=10"
>
> The example provided by upstream has
>
> LOGREADER="LANG=C journalctl -afb -p info -n1 -t sshd -t sendmail -o cat"
>
> Changing it to this makes the problem go away. (Since I use postfix, I
> used "-t postfix/smtpd" instead of sendmail.)
>
> GI
>
> --
> My wife told me I had to stop acting like a flamingo. So I had to put my
> foot down.
>
>
-- 
**Fabrice MEYER*
Software and System Engineer*

EDF Store & Forecast
13 Avenue Albert Einstein
69100 Villeurbanne
France

*fabrice.me...@edf-sf.com*
*www.edf-sf.com*

Bug#968041: lintian: fails with internal error

[Felix Lechner]

Control: tags -1 + pending

Hi Sudip,

On Fri, Aug 7, 2020 at 2:51 AM Sudip Mukherjee
 wrote:
>
> No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
> Lintian::IPC::Run3::safe_qx("unzip", "-l", 
> "/tmp/lintian-pool-tbdEtEj6Sb/pool/libi/libisnativec-java/libi"...) called at

Do you have the 'unzip' program installed? I think it is missing from
Lintian's prerequisites. Fixed here:


https://salsa.debian.org/lintian/lintian/-/commit/2fe37725b5816551b0850d2fe431c606bf5cefa2

In the commit, I forgot the hash before the bug number so the message
was not automatically forwarded here.

Please confirm if installing unzip fixes your problem. Thanks!

Kind regards
Felix Lechner

Bug#964611: [Pkg-pascal-devel] Bug#964611: Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Abou Al Montacir]

Hi Peter,

On Fri, 2020-08-07 at 11:08 +0100, peter green wrote:
> > > +#MISSING: 2.6+2.0.8+dfsg-1# 
> > > _ZN7QVectorI6QPointE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base
> > > 2.6~alpha
> 
> c++filt -n decodes this to
> QVector::reallocData(int, int, QFlags)
> This looks like an instantiation of a QT template that may or may not be
> included in the library as a seperatesymbol depending on whether it gets in-
> lined or not. So I believe it should be marked as (optional=templinst)
>  >> +#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst)
> _Z27qRegisterNormalizedMetaTypeIP7QActionEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS5_Xaasr12QMetaTypeId2IS5_E7DefinedntsrSA_9IsBuiltInEE11DefinedTypeE@Base
> 2.6~beta-4
> > > +#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst)
> > > _ZN7QVectorI6QPointEC1Ei@Base 2.6~alpha+#MISSING: 2.6+2.0.8+dfsg-1#
> > > (optional=templinst)_ZN7QVectorI6QPointEC2Ei@Base 2.6~alpha+#MISSING:
> > > 2.6+2.0.8+dfsg-1# (optional=templinst)_ZN7QVectorI7QPointFEC1Ei@Base
> > > 2.6~alpha+#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst)_ZN7QVectorI7QP
> > > ointFEC2Ei@Base 2.6~alpha
> 
> These are marked as optional already, so although they show up in the log they
> won't actually cause a failure.
> > > +#MISSING: 2.6+2.0.8+dfsg-1# 
> > > _ZN7QVectorIdE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base
> > > 2.6~alpha
> 
> c++filt -n decodes this to
> QVector::reallocData(int, int, QFlags)
> Again this looks like an instantiation of a QT template that may or may not be
> included in the library as a seperatesymbol depending on whether it gets in-
> lined or not. So again I believe it should be marked as (optional=templinst)
> If noone objects i'll prepare a team upload marking the offending symbols as
> (optional=templinst) in the next few days.

I'm going to upload both FPC 3.2.0 and Lazarus 2.0.10. So maybe you can wait
until I upload them before fixing this?
-- 
Cheers,
Abou Al Montacir


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

Bug#968055: journal uses an unsupported feature, ignoring file

[積丹尼 Dan Jacobson]

Package: systemd
Version: 245.7-1

I never touched any of this.

# journalctl -f
Journal file 
/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
 uses an unsupported feature, ignoring file.
Use SYSTEMD_LOG_LEVEL=debug journalctl 
--file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
 to see the details.

# SYSTEMD_LOG_LEVEL=debug journalctl 
--file=/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
Journal effective settings seal=no compress=no compress_threshold_bytes=8B
Journal file 
/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal
 has unknown incompatible flags 0xc
Failed to open journal file 
/var/log/journal/64f9b494837d480e9ecd81ea0cef1551/system@5cd966d8e5d24653b114e239c300135e-000e3792-0005ac0f7ccf0a84.journal:
 Protocol not supported
mmap cache statistics: 0 hit, 1 miss
Failed to open files: Protocol not supported

Maybe this was caused by me
downgrading 246-2 to 245.7-1 ?

Bug#965352: libopenmpi3: breaks tests in client programs

[Drew Parsons]

Package: libopenmpi3
Version: 4.0.4-2
Followup-For: Bug #965352
Control: forwarded -1 https://bitbucket.org/mpi4py/mpi4py/issues/171

Calling on mpi4py upstream for advice.

Bug#968054: version 9.5.2 broken on arm

[Göran Weinholt]

Package: chezscheme9.5.2
Version: 9.5.2+dfsg-1
Severity: important
Tags: upstream

Upstream released version 9.5.2 some time ago and I've uploaded it to
experimental. However, I then discovered that ARM support is broken,
which I want to record here in case anyone is wondering why the new
version hasn't hit unstable yet.

The upstream bug report is:
 https://github.com/cisco/ChezScheme/issues/438

The relevant PR with references to fixes:
 https://github.com/cisco/ChezScheme/pull/510

Racket has arm and arm64 support in their fork of Chez Scheme and I
expect their work to be merged back into Cisco's version eventually.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#967507: gutenprint: depends on deprecated GTK 2

[Didier 'OdyX' Raboud]

Control: block -1 by 967394

Le mardi, 4 août 2020, 12.47:37 h CEST s...@debian.org a écrit :
> Source: gutenprint
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gtk2 oldlibs
> Control: block 947713 by -1
> 
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

Yep. Through Gimp. Can't really get it fixed on its own. Marking as blocked

OdyX

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

Bug#968041: lintian: fails with internal error

[Sudip Mukherjee]

Sorry, a correction.
The error is still there in 2.86.0. The last good version was 2.85.0
I have downgraded to 2.85.0 and confirmed with the build.


-- 
Regards
Sudip

Bug#968025: Acknowledgement (iproute2: Cannot delete xfrm policy if `mark` is not preseent)

[Bernardo Soares]

dear maintainer,

we are moving our xfrm configuration to be based on xfrm interfaces as
opposed to using mark values. so we use intf_id to glue the state/policy
and interface.
right now i found out that, while the states can be managed just fine, the
policy won't be deleted as the mark value seems to be the only key we can
use to reference a policy.

example:

```
ip xfrm policy update src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 20
ptype main tmpl src 1.2.3.4 dst 4.3.2.1 proto esp spi 0x12345678 reqid 4096
mode tunnel if_id 0x100


root@ca870b7a2863:/opt/src# ip xfrm policy ls
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 20 ptype main
tmpl src 1.2.3.4 dst 4.3.2.1
proto esp spi 0x12345678 reqid 4096 mode tunnel
if_id 0x100

root@ca870b7a2863:/opt/src# ip xfrm policy del src 0.0.0.0/0 dst 0.0.0.0/0
dir out if_id 4096
Error: argument "if_id" is wrong: unknown
root@ca870b7a2863:/opt/src# ip xfrm policy del src 0.0.0.0/0 dst 0.0.0.0/0
dir out if_id 0x100
Error: argument "if_id" is wrong: unknown
root@ca870b7a2863:/opt/src# ip xfrm policy del src 0.0.0.0/0 dst 0.0.0.0/0
dir out mark 0x100
RTNETLINK answers: No such file or directory
root@ca870b7a2863:/opt/src# ip xfrm policy del src 0.0.0.0/0 dst 0.0.0.0/0
dir out mark 4096
RTNETLINK answers: No such file or directory
root@ca870b7a2863:/opt/src# ip xfrm policy del src 0.0.0.0/0 dst 0.0.0.0/0
dir out spi 0x12345678
Error: argument "spi" is wrong: unknown
root@ca870b7a2863:/opt/src#
```

On Thu, Aug 6, 2020 at 5:18 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 968025:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968025.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   bsoares...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Alexander Wirt 
>
> If you wish to submit further information on this problem, please
> send it to 968...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 968025: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968025
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#641812: Packaging qtsingleapplication?

[Lisandro Damián Nicanor Pérez Meyer]

Hi Kunal! Sorry for the very late reply.

On Mon, 6 Jul 2020 at 05:42, Kunal Mehta  wrote:
>
> Hi Qt maintainers,
>
> I'm currently packaging kiwix (#763321) and came across
> qtsingleapplication. It has had an open RFP (#641812) since 2011.
>
> Currently upstream kiwix bundles a copy of qtsingleapplication in its
> Git repo/tarballs, as there is no packaged version.
>
> However, the Fedora kiwix packager has asked
> () for
> qtsingleapplication to be unbundled as they have it packaged.
>
> I noticed via codesearch that there are other packages that also bundle
> qtsingleapplication:
> .
>
> Is this something current Qt maintainers would be interested in
> providing a package for? Or should I recommend to upstream to continue
> bundling it?

Wow, I didn't know that it worked with Qt5, last time I checked it was
a Qt 4 only thing.

For what I understand this is a non-maintained piece of technology,
for example: where is upstream for it?

Anyways, you are free to package it yourself.

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#966438: src:bambam: Autopkgtest fail wiht newer imagemagick*

[Marcin Owsiany]

Bastien, the screenshot is there, in the artifact tarball from autopkgtest.

I had some free time today and took a look at this in some detail. The
problem is indeed in the changed output format from "convert", bambam is
working as expected.

I have a fix ready and hope to upload it this weekend or next week.

wt., 28 lip 2020, 16:54 użytkownik Bastien Roucariès <
roucaries.bast...@gmail.com> napisał:

> Package: src:bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Justification: block imagemagick
>
> Dear Maintainer,
>
> Upgrading imagemagick fail due to autopkg test failling for your package.
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/bambam/6448023/log.gz
>
> Could you :
> 1. Fix the failure
> 2. Please in case of error take a screenshot convert it to png and print
> the png as base64 (help debugging)
>
> Bastien
>

Bug#968053: range-v3: Please package Release 0.11.0 ; needed for seqan3 3.0.2

[Michael R. Crusoe]

Source: range-v3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer. Range-v3 version 0.11.0 has been released to conform
with ISO C++20. Please package this as we need it for the upcoming
seqan3 release.

I am happy to make the update myself, if you wish.

Cheers,

- -- 
Michael R. Crusoe

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

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl8tRpYSHGNydXNvZUBk
ZWJpYW4ub3JnAAoJEDwmdj9sZ+biDscP/1xNkEmvAIhX0Xv1an7+duUkAiJ4rEp6
7Wcqe4fwp0OYgUBF9hQlv+XnVS1igz0nGXMt7nmOjZfc57UjhZimbUL6WlYRDGUC
GO155lVcZd1aBDvzkc01h4Bcb9Oh8e83vLm+pzC3K6ZEbD4n23V9GQwYVLUeFBrB
E3+bZgvDPhwSLPcJ1buLc+j7M3BlE62pmt7OAk3KCbWqYk8I2Obx6dwqHVUWc+6R
JtOxRoAYAdqcy06+Jg5AeULA8X2p5P7btxM6ffhiQvUdeNVynSVlwLY9NRblmix5
5IQt2kgjW3g53C2KQG8bAESd18R8j5pyPPBjtYvhn3A8CCDlODeiQz024IiOz9fK
xfqL/ByMiEi9U+aYNw0hjogW3l4kf4v5h4pUrt41WuC/N3CymWZzKWrsECJlUb7Y
pYls3Ze9LPUOE8E+OqKYOxeoQN2oiiVPgD8/zsRgLdr/3Na5HWwzXJtD5xqHaON8
0SKRsXeKS9Mfnpaj2NsF3O/HGNSI2GTCCrVh1DmeSDkgWmMFCOCJ8WlkTH/+VRhc
5sMYbl1v9wcTuYstfrMjoZk9T5riblGnJ7MqNAqRFQLhaBy+zFLWEJQz8xJQmlqx
poFJepYXIX3h2fBpx+GIj8rvaTxnYH0ZrH5u6g6GSdFTgiNpiKOjyMzxMyi0DMPW
5l1VqQjyXgOW
=zh61
-END PGP SIGNATURE-

Bug#963396: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure

[Andreas Tille]

Hi Thorsten,

On Thu, Aug 06, 2020 at 04:04:22PM +0200, Thorsten Glaser wrote:
> On Thu, 6 Aug 2020, Andreas Tille wrote:
> 
> > [ERROR] 
> > /build/jimfs-1.1/jimfs/src/main/java/com/google/common/jimfs/PathService.java:[290,30]
> >  error:  is not abstract 
> > and does not override abstract method test(Object) in Predicate
> 
> Change apply to test in line 292 (or let the IDE convert it to lambda).

I tried to implement this in


https://salsa.debian.org/java-team/jimfs/-/commit/2d67acb2f577596a121622a94295407e22155eed

but this does not help much and the build issue remains.

Thanks for the attempt to help anyway

   Andreas.

-- 
http://fam-tille.de

Bug#968052: O: pmacct -- promiscuous mode traffic accountant

[Bernd Zeimetz]

Package: wnpp
Severity: normal

Hi!

I intend to orphan the pmacct package.

Unfortunately I don't have the time to maintain it properly anymore.
There are various new daemons and features that should be enabled and
properly supported, otherwise the package is hopefully in a still
working shape.

The package description is:
 pmacct is a tool designed to gather traffic information (bytes and number
 of packets) by listening on a promiscuous interface or for Netflow data,
 which may facilitate billing, bandwidth management, traffic analysis, or
 creating usage graphs.
 .
 Data can be stored in memory and queried, displayed directly, or written
 to a database; storage methods are quite flexible and may aggregate totals
 or keep them separate.


Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#967017: [request-tracker-maintainers] Bug#967017: Bug#967017: request-tracker4: FTBFS: can't exec /usr/bin/gpg

[Andrew Ruthven]

On Mon, 2020-08-03 at 15:48 +0100, Dominic Hargreaves wrote:
> This seems related to changes in libgnupg-interface-perl, which on
> the
> face of it is ignoring the instruction to use 'gpg1' (configured via
> the test_gnupg_interface_gpg1.diff patch). I can't immediately see
> why
> that's happening but it seems related to the recent changes
> libgnupg-interface-perl.
> 
> Andrew, any clues?

Yes, this is related. I hadn't spotted it because I have both gpg and
gpg1 installed on my workstation.

If gpg isn't present, then I can reproduce this. The issue is with how
GnuPG::Interface checks for the version of the gpg binary that is being
run.

A minor change to RT::Crypt::GnuPG in RT fixes this. I've written the
patch to resolve this bug, pushed it to Salsa and raised a bug with
Best Practical:   
https://rt.bestpractical.com/SelfService/Display.html?id=36623

I also find it a little puzzling though, I've checked the source in
unstable and the patch name is test_gnupg-interface_gpg1.diff but the
name of the patch used in the build log is test_gnupg-
interface_gnupg.diff . This isn't in git, bullseye or unstable. 

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  |
Catalyst Cloud:| This space intentionally left blank
   https://catalystcloud.nz|

Bug#968051: Please include direct links to PGP public keys where possible

[Steve McIntyre]

Package: www.debian.org
Severity: normal

Hi,

Now that keyservers are not so useful any more, it's probably a good
plan to directly publish public keys in the various places where we
list key IDs / fingerprints etc.:

 * DAM in /intro/organization
 * CD signing keys in /CD/verify
 * Security team in /security/faq (currently links to a keyserver)
 * (maybe others?)

Maybe we could/should link to direct lookups on keyring.d.o if that's
possible, or use WKD somehow (hand-wave)?

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

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

Bug#968050: unison-gtk: Latest version does not update menu correctly

[Joe Rowan]

Package: unison-gtk
Version: 2.48.4+2
Severity: normal

Dear Maintainer,



Since upgrading yesterday, Xfce panel launcher is not showing correct start
command or any icon.

Fixed by editing launcher to correct start command and adding icon.



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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unison-gtk depends on:
ii  unison-2.48-gtk  2.48.4-6

unison-gtk recommends no packages.

Versions of packages unison-gtk suggests:
pn  unison-all-gtk  

-- no debconf information

Bug#968049: Failed to kill unit rsyslog.service: Input/output error

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 07.08.20 um 11:01 schrieb Harald Dunkel:
> Package: systemd
> Version: 241-7~deb10u4
> 
> logrotate.service dies with
> 
> ● logrotate.service - Rotate log files
>    Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor
> preset: enabled)
>    Active: activating (start) since Fri 2020-08-07 00:00:01 CEST; 346ms ago
>  Docs: man:logrotate(8)
>    man:logrotate.conf(5)
>  Main PID: 359518 (logrotate)
>     Tasks: 3 (limit: 618789)
>    Memory: 1.9M
>    CGroup: /system.slice/logrotate.service
>    └─359518 /usr/sbin/logrotate /etc/logrotate.conf
> 
> Aug 07 00:00:01 srvvm01.ac.aixigo.de systemd[1]: Starting Rotate log
> files...
> Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: Failed to kill
> unit rsyslog.service: Input/output error
> Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: error: error
> running non-shared postrotate script for /var/log/syslog of
> '/var/log/syslog
> Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: '
> 
> 
> Looking closely this seems to be the part that is broken:
> 
> # systemctl kill -s HUP rsyslog.service
> Failed to kill unit rsyslog.service: Input/output error
> 
> 
> rsyslog *does* receive the HUP, as /var/log/messages seems to indicate:
> 
> Aug  7 10:48:53 srvvm01 rsyslogd:  [origin software="rsyslogd"
> swVersion="8.1901.0" x-pid="96" x-info="https://www.rsyslog.com;]
> rsyslogd was HUPed
> 
> 
> Apparently only systemd thinks that something went wrong, but
> this is sufficient to break log file rotation :-(.
> 
> This is highly important. The host in question is our EMail server.
> I have to move back to sysvinit, if logging and rotation don't work.
> 
> This is an LXC container. Host and container are both running Debian 10
> and systemd 241-7~deb10u4.


What's the output of logrotate -v /etc/logrotate.d/rsyslog






signature.asc
Description: OpenPGP digital signature

Bug#539201: Cannot specify rpc.nfsd options

[Tom H]

It's misnamed but "RPCNFSDCOUNT" in "/etc/default/nfs-kernel-server"
can be used.

It might not be worth creating a more appropriate, separate variable
given that, when Debian upgrades to v2.x (first released, as 2.1.1,
three and a half years ago), options'll be set via "/etc/nfs.conf".

Bug#968049: Failed to kill unit rsyslog.service: Input/output error

[Harald Dunkel]

Package: systemd
Version: 241-7~deb10u4

logrotate.service dies with

● logrotate.service - Rotate log files
   Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor 
preset: enabled)
   Active: activating (start) since Fri 2020-08-07 00:00:01 CEST; 346ms ago
 Docs: man:logrotate(8)
   man:logrotate.conf(5)
 Main PID: 359518 (logrotate)
Tasks: 3 (limit: 618789)
   Memory: 1.9M
   CGroup: /system.slice/logrotate.service
   └─359518 /usr/sbin/logrotate /etc/logrotate.conf

Aug 07 00:00:01 srvvm01.ac.aixigo.de systemd[1]: Starting Rotate log files...
Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: Failed to kill unit 
rsyslog.service: Input/output error
Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: error: error running 
non-shared postrotate script for /var/log/syslog of '/var/log/syslog
Aug 07 00:00:01 srvvm01.ac.aixigo.de logrotate[359518]: '


Looking closely this seems to be the part that is broken:

# systemctl kill -s HUP rsyslog.service
Failed to kill unit rsyslog.service: Input/output error


rsyslog *does* receive the HUP, as /var/log/messages seems to indicate:

Aug  7 10:48:53 srvvm01 rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" 
x-pid="96" x-info="https://www.rsyslog.com;] rsyslogd was HUPed


Apparently only systemd thinks that something went wrong, but
this is sufficient to break log file rotation :-(.

This is highly important. The host in question is our EMail server.
I have to move back to sysvinit, if logging and rotation don't work.

This is an LXC container. Host and container are both running Debian 10
and systemd 241-7~deb10u4.


Regards
Harri

Bug#968048: ax25-{,x}tools: both ship /usr/bin/smdiag and some more files

[Andreas Beckmann]

Package: ax25-tools,ax25-xtools
Version: 0.0.10-rc5+git20190411+3595f87-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Preparing to unpack 
.../ax25-xtools_0.0.10-rc5+git20190411+3595f87-2_amd64.deb ...
  Unpacking ax25-xtools (0.0.10-rc5+git20190411+3595f87-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ax25-xtools_0.0.10-rc5+git20190411+3595f87-2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/smdiag', which is also in package ax25-tools 
0.0.10-rc5+git20190411+3595f87-2
  Errors were encountered while processing:
   
/var/cache/apt/archives/ax25-xtools_0.0.10-rc5+git20190411+3595f87-2_amd64.deb

These files are shipped by both packages:

  usr/bin/smdiag
  usr/sbin/xfhdlcchpar
  usr/sbin/xfhdlcst
  usr/sbin/xfsmdiag
  usr/sbin/xfsmmixer
  usr/share/man/man8/smdiag.8.gz


cheers,

Andreas


ax25-tools=0.0.10-rc5+git20190411+3595f87-2_ax25-xtools=0.0.10-rc5+git20190411+3595f87-2.log.gz
Description: application/gzip

Bug#845128: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Jonas Smedegaard]

Quoting Dieter (2020-08-07 13:09:42)
> As i did some testing with my RevK and RevC and various values for 
> GMAC_TX_DELAY, I logged into the RevC Lime2 today to check if 
> CONFIG_RTL8211X_PHY_FORCE_MASTER=y was set in the u-boot config.
> 
> As i did not change this setting from the debian-default, i figured i 
> would only have to test the "other" value.
> 
> However, i can not find it in the .config in the u-boot-src. Which 
> seems fine, as the config can not be found in upstream u-boot: 
> https://gitlab.denx.de/u-boot/u-boot/-/blob/v2019.01/configs/A20-OLinuXino-Lime2_defconfig
> 
> But this configuration then re-appeared in release 2020.07: 
> https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.07/configs/A20-OLinuXino-Lime2_defconfig
> 
> 
> Now i do not know how to check if FORCE_MASTER was set or not.
> 
> 
> see the results for RevC with u-boot-sunxi (2019.01+dfsg-7) here: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911560#126

It seems that FORCE_MASTER was disabled in 2019.01+dfsg-7.

Few minutes ago I updated 
https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks with my 
newest findings from upstream u-boot.  I also looked at Debian packaging 
where I did not locate any patches related to this issue, so it seems 
Debian packaging is aligned with upstream on this.


 - Jonas

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

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

signature.asc
Description: signature

Bug#845128: u-boot: Olimex Lime 2 Rev C Gigabit Ethernet problem

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-08-07 11:45:32)
> Sunil Mohan wrote:
> > I noticed that a "force master" workaround[1] was introduced into 
> > u-boot in 2016 after some discussion[2] for fixing poor Ethernet 
> > performance on RTL8211C found in Lime2 Rev.C. Later, perhaps 
> > inadvertently, this seems to be removed[3].
> 
> Your link [3] apparently no longer works¹ - a currently working link to 
> the commit where LIME2 rev.C workaround got dropped is this: 
> https://gitlab.denx.de/u-boot/u-boot/-/commit/8728c97eff5bd95f58320f886ae305f17931a374#df39e52b3ea1557b1fb508755955c9ad86f92c38
> 
> 
> That change happened prior to release v2017.03 and was reverted prior to 
> release v2020.04: 
> https://gitlab.denx.de/u-boot/u-boot/-/commit/8728c97eff5bd95f58320f886ae305f17931a374#df39e52b3ea1557b1fb508755955c9ad86f92c38

Silly me: Above URLs are identical.

See https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks for 
the proper URLs, and more related information and tests that seems 
relevant to conduct.


 - Jonas

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

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

signature.asc
Description: signature

Bug#968047: texlive-fonts-extra-links: missing Breaks+Replaces: texlive-fonts-extra (<< 2020.20200804)

[Andreas Beckmann]

Package: texlive-fonts-extra-links
Version: 2020.20200804-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../texlive-fonts-extra-links_2020.20200804-1_all.deb ...
  Unpacking texlive-fonts-extra-links (2020.20200804-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-fonts-extra-links_2020.20200804-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/texlive/texmf-dist/fonts/truetype/google/noto-emoji/NotoColorEmoji.ttf',
 which is also in package texlive-fonts-extra 2020.20200629-1
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-fonts-extra-links_2020.20200804-1_all.deb


cheers,

Andreas


texlive-fonts-extra=2020.20200629-1_texlive-fonts-extra-links=2020.20200804-1.log.gz
Description: application/gzip

Bug#958010: yubikey-personalization: diff for NMU version 1.20.0-2.1

[Sebastian Ramacher]

Control: tags 958010 + pending
Control: tags 966606 + pending

Dear maintainer,

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

Cheers
-- 
Sebastian Ramacher
diff -Nru yubikey-personalization-1.20.0/debian/changelog yubikey-personalization-1.20.0/debian/changelog
--- yubikey-personalization-1.20.0/debian/changelog	2020-01-31 04:05:11.0 +0100
+++ yubikey-personalization-1.20.0/debian/changelog	2020-08-07 13:21:24.0 +0200
@@ -1,3 +1,11 @@
+yubikey-personalization (1.20.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patches to fix build with GCC 10 and json-c 0.14 and newer
+(Closes: #958010, #966606)
+
+ -- Sebastian Ramacher   Fri, 07 Aug 2020 13:21:24 +0200
+
 yubikey-personalization (1.20.0-2) unstable; urgency=medium
 
   * Fix install location for AppStream metadata (Closes: #943591)
diff -Nru yubikey-personalization-1.20.0/debian/patches/09ea16d9e2030e4da6ad00c1e5147e962aa7ff84.patch yubikey-personalization-1.20.0/debian/patches/09ea16d9e2030e4da6ad00c1e5147e962aa7ff84.patch
--- yubikey-personalization-1.20.0/debian/patches/09ea16d9e2030e4da6ad00c1e5147e962aa7ff84.patch	1970-01-01 01:00:00.0 +0100
+++ yubikey-personalization-1.20.0/debian/patches/09ea16d9e2030e4da6ad00c1e5147e962aa7ff84.patch	2020-08-07 13:19:48.0 +0200
@@ -0,0 +1,25 @@
+From 09ea16d9e2030e4da6ad00c1e5147e962aa7ff84 Mon Sep 17 00:00:00 2001
+From: Klas Lindfors 
+Date: Mon, 17 Feb 2020 08:58:33 +0100
+Subject: [PATCH] make header declarations extern
+
+fixes #155
+---
+ ykpers-args.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/ykpers-args.h b/ykpers-args.h
+index 2a63268..9ff455a 100644
+--- a/ykpers-args.h
 b/ykpers-args.h
+@@ -33,8 +33,8 @@
+ 
+ #include "ykpers.h"
+ 
+-const char *usage;
+-const char *optstring;
++extern const char *usage;
++extern const char *optstring;
+ 
+ int args_to_config(int argc, char **argv, YKP_CONFIG *cfg, char *oathid,
+ 		   size_t oathid_len, const char **infname,
diff -Nru yubikey-personalization-1.20.0/debian/patches/0aa2e2cae2e1777863993a10c809bb50f4cde7f8.patch yubikey-personalization-1.20.0/debian/patches/0aa2e2cae2e1777863993a10c809bb50f4cde7f8.patch
--- yubikey-personalization-1.20.0/debian/patches/0aa2e2cae2e1777863993a10c809bb50f4cde7f8.patch	1970-01-01 01:00:00.0 +0100
+++ yubikey-personalization-1.20.0/debian/patches/0aa2e2cae2e1777863993a10c809bb50f4cde7f8.patch	2020-08-07 13:20:35.0 +0200
@@ -0,0 +1,83 @@
+From 0aa2e2cae2e1777863993a10c809bb50f4cde7f8 Mon Sep 17 00:00:00 2001
+From: Christian Hesse 
+Date: Sat, 25 Apr 2020 20:55:28 +0200
+Subject: [PATCH] fix boolean value with json-c 0.14
+
+Upstream removed the TRUE and FALSE defines in commit
+0992aac61f8b087efd7094e9ac2b84fa9c040fcd.
+---
+ ykpers-json.c | 18 +-
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/ykpers-json.c b/ykpers-json.c
+index a62e907..15ad380 100644
+--- a/ykpers-json.c
 b/ykpers-json.c
+@@ -40,7 +40,7 @@
+ #define yk_json_object_object_get(obj, key, value) json_object_object_get_ex(obj, key, )
+ #else
+ typedef int json_bool;
+-#define yk_json_object_object_get(obj, key, value) (value = json_object_object_get(obj, key)) == NULL ? (json_bool)FALSE : (json_bool)TRUE
++#define yk_json_object_object_get(obj, key, value) (value = json_object_object_get(obj, key)) == NULL ? 0 : 1
+ #endif
+ 
+ static void set_json_value(struct map_st *p, int mode, json_object *options, YKP_CONFIG *cfg) {
+@@ -50,7 +50,7 @@ static void set_json_value(struct map_st *p, int mode, json_object *options, YKP
+ 	if(p->mode && (mode & p->mode) == mode) {
+ 		json_object *joption;
+ 		json_bool ret = yk_json_object_object_get(options, p->json_text, joption);
+-		if(ret == TRUE && json_object_get_type(joption) == json_type_boolean) {
++		if(ret == 1 && json_object_get_type(joption) == json_type_boolean) {
+ 			int value = json_object_get_boolean(joption);
+ 			if(value == 1) {
+ p->setter(cfg, true);
+@@ -230,20 +230,20 @@ int _ykp_json_import_cfg(YKP_CONFIG *cfg, const char *json, size_t len) {
+ 			ykp_errno = YKP_EINVAL;
+ 			goto out;
+ 		}
+-		if(yk_json_object_object_get(jobj, "yubiProdConfig", yprod_json) == FALSE) {
++		if(yk_json_object_object_get(jobj, "yubiProdConfig", yprod_json) == 0) {
+ 			ykp_errno = YKP_EINVAL;
+ 			goto out;
+ 		}
+-		if(yk_json_object_object_get(yprod_json, "mode", jmode) == FALSE) {
++		if(yk_json_object_object_get(yprod_json, "mode", jmode) == 0) {
+ 			ykp_errno = YKP_EINVAL;
+ 			goto out;
+ 		}
+-		if(yk_json_object_object_get(yprod_json, "options", options) == FALSE) {
++		if(yk_json_object_object_get(yprod_json, "options", options) == 0) {
+ 			ykp_errno = YKP_EINVAL;
+ 			goto out;
+ 		}
+ 
+-		if(yk_json_object_object_get(yprod_json, "targetConfig", jtarget) == TRUE) {
++		if(yk_json_object_object_get(yprod_json, 

Bug#957487: libzstd: ftbfs with GCC-10

[Reiner Herrmann]

Control: forward -1 https://github.com/facebook/zstd/issues/2204

Hi,

the issue seems to be known upstream.
As a workaround (until it is fixed properly), the package could be compiled
without the -Werror flag, as this turns compiler warnings into errors, which
causes the build to fail.

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#966604: libu2f-server: diff for NMU version 1.1.0-3.1

[Sebastian Ramacher]

Control: tags 966604 + pending


Dear maintainer,

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

Cheers
-- 
Sebastian Ramacher
diff -Nru libu2f-server-1.1.0/debian/changelog libu2f-server-1.1.0/debian/changelog
--- libu2f-server-1.1.0/debian/changelog	2020-03-05 02:41:30.0 +0100
+++ libu2f-server-1.1.0/debian/changelog	2020-08-07 13:15:15.0 +0200
@@ -1,3 +1,11 @@
+libu2f-server (1.1.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix build with json-c 0.14 and newer (Closes:
+#966604)
+
+ -- Sebastian Ramacher   Fri, 07 Aug 2020 13:15:15 +0200
+
 libu2f-server (1.1.0-3) unstable; urgency=low
 
   [ nicoo ]
diff -Nru libu2f-server-1.1.0/debian/patches/f7c4983b31909299c47bf9b2627c84b6bfe225de.patch libu2f-server-1.1.0/debian/patches/f7c4983b31909299c47bf9b2627c84b6bfe225de.patch
--- libu2f-server-1.1.0/debian/patches/f7c4983b31909299c47bf9b2627c84b6bfe225de.patch	1970-01-01 01:00:00.0 +0100
+++ libu2f-server-1.1.0/debian/patches/f7c4983b31909299c47bf9b2627c84b6bfe225de.patch	2020-08-07 13:14:36.0 +0200
@@ -0,0 +1,34 @@
+From f7c4983b31909299c47bf9b2627c84b6bfe225de Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bj=C3=B6rn=20Esser?= 
+Date: Mon, 13 Apr 2020 14:16:20 +0200
+Subject: [PATCH] Add support for upcoming json-c 0.14.0.
+
+TRUE/FALSE are not defined anymore.  1 and 0 are used instead.
+---
+ u2f-server/core.c | 13 +
+ 1 file changed, 13 insertions(+)
+
+diff --git a/u2f-server/core.c b/u2f-server/core.c
+index 2fb325e..895c004 100644
+--- a/u2f-server/core.c
 b/u2f-server/core.c
+@@ -44,6 +44,19 @@ typedef int json_bool;
+ #define u2fs_json_object_object_get(obj, key, value) (value = json_object_object_get(obj, key)) == NULL ? (json_bool)FALSE : (json_bool)TRUE
+ #endif
+ 
++/* json-c 0.13.99 does not define TRUE/FALSE anymore
++ * the json-c maintainers replaced them with pure 1/0
++ * https://github.com/json-c/json-c/commit/0992aac61f8b
++ */
++#if defined JSON_C_VERSION_NUM && JSON_C_VERSION_NUM >= ((13 << 8) | 99)
++#ifndef FALSE
++#define FALSE 0
++#endif
++#ifndef TRUE
++#define TRUE  1
++#endif
++#endif
++
+ static u2fs_rc encode_b64u(const char *data, size_t data_len, char *output)
+ {
+   base64_encodestate b64;
diff -Nru libu2f-server-1.1.0/debian/patches/series libu2f-server-1.1.0/debian/patches/series
--- libu2f-server-1.1.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libu2f-server-1.1.0/debian/patches/series	2020-08-07 13:14:39.0 +0200
@@ -0,0 +1 @@
+f7c4983b31909299c47bf9b2627c84b6bfe225de.patch


signature.asc
Description: PGP signature

Bug#845128: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Dieter]

Hello all!

As i did some testing with my RevK and RevC and various values for
GMAC_TX_DELAY, I logged into the RevC Lime2 today to check if
CONFIG_RTL8211X_PHY_FORCE_MASTER=y was set in the u-boot config.

As i did not change this setting from the debian-default, i figured i
would only have to test the "other" value.

However, i can not find it in the .config in the u-boot-src.
Which seems fine, as the config can not be found in upstream u-boot:
https://gitlab.denx.de/u-boot/u-boot/-/blob/v2019.01/configs/A20-OLinuXino-Lime2_defconfig

But this configuration then re-appeared in release 2020.07:
https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.07/configs/A20-OLinuXino-Lime2_defconfig


Now i do not know how to check if FORCE_MASTER was set or not.


see the results for RevC with u-boot-sunxi (2019.01+dfsg-7) here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911560#126

Best regards,
Dieter

Bug#968046: dh-python: missing Breaks+Replaces: python2 (<< 2.7.18)

[Andreas Beckmann]

Package: dh-python
Version: 4.20200804
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../dh-python_4.20200804_all.deb ...
  Unpacking dh-python (4.20200804) ...
  dpkg: error processing archive 
/var/cache/apt/archives/dh-python_4.20200804_all.deb (--unpack):
   trying to overwrite '/usr/share/debhelper/autoscripts/postinst-pycompile', 
which is also in package python2 2.7.17-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/dh-python_4.20200804_all.deb


cheers,

Andreas

Bug#966602: libu2f-host: diff for NMU version 1.1.10-1.1

[Sebastian Ramacher]

Control: tags 966602 + pending

Dear maintainer,

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

Cheers
-- 
Sebastian Ramacher
diff -Nru libu2f-host-1.1.10/debian/changelog libu2f-host-1.1.10/debian/changelog
--- libu2f-host-1.1.10/debian/changelog	2019-07-13 13:35:42.0 +0200
+++ libu2f-host-1.1.10/debian/changelog	2020-08-07 13:09:25.0 +0200
@@ -1,3 +1,11 @@
+libu2f-host (1.1.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch for compatibility with json-c 0.14 and newer (Closes:
+#966602)
+
+ -- Sebastian Ramacher   Fri, 07 Aug 2020 13:09:25 +0200
+
 libu2f-host (1.1.10-1) unstable; urgency=high (security fix)
 
   [ Nicolas Braud-Santoni ]
diff -Nru libu2f-host-1.1.10/debian/patches/840f01135d2892f45e71b9e90405de587991bd03.patch libu2f-host-1.1.10/debian/patches/840f01135d2892f45e71b9e90405de587991bd03.patch
--- libu2f-host-1.1.10/debian/patches/840f01135d2892f45e71b9e90405de587991bd03.patch	1970-01-01 01:00:00.0 +0100
+++ libu2f-host-1.1.10/debian/patches/840f01135d2892f45e71b9e90405de587991bd03.patch	2020-08-07 13:08:56.0 +0200
@@ -0,0 +1,34 @@
+From 840f01135d2892f45e71b9e90405de587991bd03 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bj=C3=B6rn=20Esser?= 
+Date: Mon, 13 Apr 2020 14:12:25 +0200
+Subject: [PATCH] Add support for upcoming json-c 0.14.0.
+
+TRUE/FALSE are not defined anymore.  1 and 0 are used instead.
+---
+ u2f-host/u2fmisc.c | 13 +
+ 1 file changed, 13 insertions(+)
+
+diff --git a/u2f-host/u2fmisc.c b/u2f-host/u2fmisc.c
+index e40ca3d..5a032ce 100644
+--- a/u2f-host/u2fmisc.c
 b/u2f-host/u2fmisc.c
+@@ -33,6 +33,19 @@ typedef int json_bool;
+ #define u2fh_json_object_object_get(obj, key, value) (value = json_object_object_get(obj, key)) == NULL ? (json_bool)FALSE : (json_bool)TRUE
+ #endif
+ 
++/* json-c 0.13.99 does not define TRUE/FALSE anymore
++ * the json-c maintainers replaced them with pure 1/0
++ * https://github.com/json-c/json-c/commit/0992aac61f8b
++ */
++#if defined JSON_C_VERSION_NUM && JSON_C_VERSION_NUM >= ((13 << 8) | 99)
++#ifndef FALSE
++#define FALSE 0
++#endif
++#ifndef TRUE
++#define TRUE  1
++#endif
++#endif
++
+ static void
+ dumpHex (unsigned char *data, int offs, int len)
+ {
diff -Nru libu2f-host-1.1.10/debian/patches/series libu2f-host-1.1.10/debian/patches/series
--- libu2f-host-1.1.10/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libu2f-host-1.1.10/debian/patches/series	2020-08-07 13:09:00.0 +0200
@@ -0,0 +1 @@
+840f01135d2892f45e71b9e90405de587991bd03.patch


signature.asc
Description: PGP signature