Bug#946217: reopening 946217

[Salvatore Bonaccorso]

Hi Ondrej,

On Mon, May 11, 2020 at 10:39:51PM +0200, Ondřej Surý wrote:
> reopen 946217 
> thanks

Was this sent to the wrong bug or are CVE-2019-19333 and
CVE-2019-19334 in libyang really unfixed? (AFAICS the upstream patches
are applied in the source in the -2 upload).

Regards,
Salvatore

Bug#960201: python-gmpy2: autopkgtest regression: RuntimeWarning: coroutine '' was never awaited

[Case Van Horsen]

I can reproduce the issue with Python 3.8.3rc1. I'll check the other
3.8 versions to see if it exists in earlier versions.

On Mon, May 11, 2020 at 11:00 AM Paul Gevers  wrote:
>
> Hi Martin,
>
> On 11-05-2020 02:01, Martin Kelly wrote:
> >> Because your autopkgtest was part of the tests for glibc, I spotted that
> >> the autopkgtest of python-gmpy2 regressed recently. On 2020-05-01 at
> >> 19:13 we had the last successful run on arm64 in testing, the first
> >> failure was also on 2020-05-01, even earlier: at 02:08 in unstable on
> >> amd64. I copied some of the output at the bottom of this report.
> >>
> >> Can you please investigate the situation and fix it?
> >>
> >> More information about this bug and the reason for filing it can be
> >> found on
> >> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> >>
> >> Paul
> >>
> >> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-gmpy2/5338978/log.gz
> >>
> >>
> >
> > Thanks for the bug report. Given that no new python-gmpy2 package was
> > uploaded on May 1, I'm guessing one of the dependencies of this package
> > has broken, or changed in a way that broke this package. Is there a way
> > to get a list of packages that were uploaded after the last successful
> > test and before the first failure?
>
> The interesting thing is that it regressed in both unstable and testing
> nearly at the same time. So either I would bet on something external to
> the archive (like sources or time) or maybe a kernel update? You can see
> the packages in the testbed if you inspect the artifacts linked from the
> ci.d.n pages.
>
> > +Case Van Horsten, the upstream maintainer. Case, could you take a look
> > at the failures here? They seem to have occurred without gmpy2 changing,
> > so some dependency is failing.
>
> Paul
>

Bug#960341: swi-prolog-core,swi-prolog-core-packages: missing Breaks+Replaces: swi-prolog-nox (<< 8.1.30)

[Lev Lamberov]

Hi,

Пн 11 мая 2020 @ 22:56 Andreas Beckmann :

> Package: swi-prolog-core,swi-prolog-core-packages
> Version: 8.1.30+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
> It installed fine in 'sid', then the upgrade to 'experimental' 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

these changes are in git already. So, pending...

Cheers!
Lev Lamberov

Bug#933734: CRTL+ARROWS switch but does not really now

[PICCORO McKAY Lenz]

tryit new version, this time let me redefine keys and works, but by
default does not work! gtk2 works perfectly (debian wheeze with older
version custon build)

2020-05-10 8:32 GMT-04:00, Andreas Ronnquist :
> On Tue, 6 Aug 2019 08:30:10 -0400 PICCORO McKAY Lenz
>  wrote:
>> i created manually the file.. now the config as you pointed was put..
>>
>> BUT graphically seems change to the next terminal.. but the internal
>> screeen still show the current terminal
>>
>> it's clear that the sakura release are totally broken but why?
>> libvte? gtk3 ?
>>
>
> I cannot reproduce your problem, it works just find over here. I have
> uploaded a new version of sakura (3.7.1-1), could you please try this
> version and check if you can reproduce the problem in this version?
>
> /Andreas
> gus...@debian.org
>


-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Friday, 8 May 2020 3:52:31 AM AEST Julien Cristau wrote:
> That's not what "Provides" means though.  What you're saying is
> "systemctl provides a subset of the systemd package's functionality".
> That's not good enough.  Provides is much stronger than "there are cases
> where this might be enough", and there's more to systemd than systemctl.

Basically what you are saying is that systemd provides so much that no 
package qualifies for "Provides: systemd".

I have a metaphor in mind. Suppose systemd provides "house" with all its 
facilities such as microwave, dishwasher, fridge, washing machine, drier, 
etc. Re-implementing package have too much to provide so no package qualifies 
for "Provides: house" because under that doctrine providing package have to 
implement compatible facilities exactly the way systemd does so.
I'm not sure what would be the incentive to re-write systemd with outcome 
closely resembling what systemd already provides...

However realistic paradigm is more like when systemd provides "shelter".
There are different types of _shelter_, e.g. motel, hotel, apartment and 
_tent_. The latter "Provides: shelter" but it needs no dishwasher and not 
expected to have it. Having it would require a lot of other facilities that 
_tent_ intentionally don't have (e.g. sewage, permanent water supply, 240V 
electricity, etc.). Note that feature-rich _hotel_ also don't provide 
dishwasher and also not expected to have it because other types of shelter 
are not meant to be identical to "house". Quite contrary they are meant to be 
different.

Based on that analogy I think "Provides: systemd" is acceptable if we don't 
take "systemd" literally as the collection of all systemd-specific features/
facilities/interfaces altogether.

Just like we would not consider _library_ to be a _library_ only if it 
provides a particular and very specific set of books similar to a certain 
public library.



> Also, per policy §3.6, virtual packages outside the defined agreed-upon
> names should only be used "amongst a cooperating group of packages".  It
> seems clear to me this is neither of those cases.

Perhaps you know better but I'm not sure how much this matters in the context 
of the intended outcome.


> [...] or the
> php-fpm maintainer to forgo using functionality that is only available
> in systemd, but abusing package relationships the way you're doing now
> is just not on.

Noted. I disagree with strong statement about "abusing package relationships" 
but agree with you that removing "Provides: systemd" from "systemctl" package 
would be desirable as long as "php-fpm" package makes changes to allow our 
packages to be co-installable.

I am making attempt to convince Ondřej to make changes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959174#52

-- 
Regards,
 Dmitry Smirnov.

---

No system of mass surveillance has existed in any society that we know of
to this point that has not been abused.
-- Edward Snowden


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

Bug#960370: RFS: jag/0.3.7-1 -- arcade and puzzle 2D game

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: jag
   Version : 0.3.7-1
   Upstream Author : XlabSoft & Industrial Infosystems
 * URL : https://gitlab.com/coringao/jag/wikis
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/games-team/jag
   Section : games

It builds those binary packages:

  jag - arcade and puzzle 2D game
  jag-data - arcade and puzzle 2D game (data file)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jag/jag_0.3.7-1.dsc

Changes since the last upload:

   * New upstream release. FTCBFS bug fixed. (Closes: #958672)
 - Fixed integrated qmake support for pkg-config. (Thanks Helmut Grohne)
   * Added autopkgtest.
   * Added debian/docs.
   * debian/rules:
 - export DEB_LDFLAGS_MAINT_APPEND removed.
 - export QT_SELECT removed.
   * debian/watch:
 - Fixed the requested URL in the uscan information.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Friday, 8 May 2020 1:17:59 AM AEST Shengjing Zhu wrote:
> I can see both php-fpm and systemctl maintainers have good reasons to
> do what they did.

No, php-fpm maintainer had a bad reason to do what he did. His insistence on 
using "systemd-tmpfiles" in SysV init script is a _demand_ to develop, 
provide and maintain a compatible implementation of a redundant systemd 
feature.

And all that is merely to replace the following:


mkdir -p /run/php
chown www-data:www-data /run/php


SysV never needed a tool to do just that.

I'm not against having a standalone implementation of "systemd-tmpfiles".
However this very bug is an evidence of how unreasonable it is to depend on 
such tool before its existence.


> So taking one step back, does it make sense to dpkg-divert
> /usr/bin/systemctl?

I think this is not an option.

If that has to be done manually then it adds needless Debian-specific 
complexity so for user it might become easier just to install the script 
manually without even using the package.

dpkg-divert have potential to break normal systemd-managed system. I can't be 
sure it would even boot. Obviously that is dangerous to do manually and for 
that reason not acceptable for automatic divert.

IMHO it is much better when "systemctl" just conflicts with "systemd".
If admin installed "systemctl" by mistake (and ignored prompt to uninstall 
"systemd") then the system is not broken as it will still boot normally under 
SysV fallback.

But is "systemctl" binary is replaced on normal/default systemd-managed 
system then the outcome is the worst of all I can think of.

-- 
All the best,
 Dmitry Smirnov.

---

Vaccination is the leading cause of coincidences.
-- Brett Wilcox


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

Bug#959174: php7.4-fpm: should not depend on "systemd" ideally?

[Dmitry Smirnov]

On Tuesday, 5 May 2020 9:13:37 PM AEST Ondřej Surý wrote:
> Then focus on fixing this.

Ondřej, please consider the following patch:


 Make init script not depending on systemd (Closes: #959174).

--- a/debian/control
+++ b/debian/control
@@ -238,7 +238,6 @@ Depends: libmagic1,
  php7.4-json,
  php7.4-opcache,
  procps,
- systemd | systemd-tmpfiles,
  tzdata,
  ucf,
  ${misc:Depends},
diff --git a/debian/control.in b/debian/control.in
index 96817035..ca9ae146 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -238,7 +238,6 @@ Depends: libmagic1,
  php@PHP_VERSION@-json,
  php@PHP_VERSION@-opcache,
  procps,
- systemd | systemd-tmpfiles,
  tzdata,
  ucf,
  ${misc:Depends},
diff --git a/debian/php-fpm.init b/debian/php-fpm.init
index 865376e5..bb5c6647 100644
--- a/debian/php-fpm.init
+++ b/debian/php-fpm.init
@@ -96,7 +96,9 @@ do_reload() {
 case "$1" in
 start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
-   systemd-tmpfiles --remove --create 
/usr/lib/tmpfiles.d/php@php_vers...@-fpm.conf
+   mkdir -p /run/php
+   chown www-data:www-data /run/php
+   # chmod -c 0755 /run/php
case "$?" in
0)
do_start


I'm also raising severity of this bug because it prevents
our packages from being installed together.

Thanks.

-- 
All the best,
 Dmitry Smirnov.

---

If you want to live a happy life, tie it to a goal, not to people or things.
-- Albert Einstein


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

Bug#940704: first try with node-jest 24.9.0

[Paolo Greppi]

With node-jest now in the NEW queue, I have started working on this here:

  https://salsa.debian.org/js-team/node-yarnpkg/-/tree/jest

I have built jest from https://salsa.debian.org/js-team/node-jest assuming 
commit b9255f45c22c030b863e7d42aaf78c207db43478 will be tagged as 24.9.0+ds-2 
(although that is not in NEW queue):

  git checkout b9255f45c22c030b863e7d42aaf78c207db43478
  git switch -c debian/24.9.0+ds-2
  gbp buildpackage -uc -us --git-ignore-branch

I need to side-load these packages to /usr/share/nodejs to make jest start:

  import-local realpath-native jest-snapshot-serializer-raw sane react-is 
natural-compare p-each-series throat

Now the test suite starts, and all 91 tests fail. I need to also side-load:

  string-length fast-json-stable-stringify source-map-support

not sure if these are jest run-time dependencies or yarnpkg test-time 
dependencies.

Now all the tests fail because:

  Cannot find module 'source-map-support' from 'source-map-support.js'

To fix this, I upgrade source-map-support to 0.5.19; now I get:

  Cannot find module 'chalk' from 'Env.js'

this comes from /usr/share/nodejs/jest-jasmine2/build/jasmine/Env.js which is 
compiled from node-jest/packages/jest-jasmine2/src/jasmine/Env.ts.
But node-chalk is installed:

  nodejs
  > chalk = require('chalk');
  { [Chalk]
constructor: [Function: Chalk],
supportsColor: { level: 2, hasBasic: true, has256: true, has16m: false },
default: [Circular] }
  > ^d

Clearly the jest command is broken.
I suggest to enable the jest self-test suite in node-jest.

I tried running "jest" in node-jest source tree (after side-loading the 8 
packages above), I get:

● Validation Error:

  Test environment ./packages/jest-environment-node cannot be found. Make sure 
the testEnvironment configuration option points to an existing node module.

  Configuration Documentation:
  https://jestjs.io/docs/configuration.html

Although ./packages/jest-environment-node exists (?)

I tried to specify the testEnvironment from the command line:

  jest --env=node

and with that I get:

● Validation Error:

  Module /packages/pretty-format/build/plugins/ConvertAnsi.js in the 
snapshotSerializers option was not found.
  is: /root/node-jest

  Configuration Documentation:
  https://jestjs.io/docs/configuration.html

Also note that the command:

  jest --init

requires side-loading prompts module.

For my own record, I reset all the changes to my test machine with:

  apt remove jest
  apt autoremove
  cd /usr/share/nodejs
  rm import-local realpath-native jest-snapshot-serializer-raw sane react-is 
natural-compare p-each-series throat string-length fast-json-stable-stringify 
source-map-support prompts
  mv source-map-support.old/ source-map-support

Paolo

Bug#960368: kallisto: v0.46.2 segfaults with upstream tests

[merkys]

Source: kallisto
Version: 0.46.2
Forwarded: https://github.com/pachterlab/kallisto/issues/254

Kallisto v0.46.2 segfaults with upstream test case (the one in 'test'
subdirectory). This is to report that packaging v0.46.2 should probably
not be attempted before the upstream solves the issue.

Andrius

Bug#960367: lintian: warn about URL based fields that aren't fully qualified URLs

[Paul Wise]

Package: lintian
Version: 2.72.0
Severity: wishlist

Please warn about Homepage and other URL based fields that do not
contain fully qualified URLs. It seems that the Data::Validate::URI or
URI Perl modules might be able to be used for this. There is currently
one package in Debian that doesn't have a fully qualified Homepage URL:

$ grep -Eh '^Homepage:[^:]+$' /var/lib/apt/lists/*Sources | sort -u
Homepage: bbtools.sourceforge.net/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#960366: lintian: warn about Homepage fields pointing to download directories

[Paul Wise]

Package: lintian
Version: 2.72.0
Severity: wishlist

Please warn about Homepage fields that point to download directories.
Download directories are not "homepages" and should not be used like
that. This complaint should be either info or pedantic level and should
only be applied to Homepage fields not all URLs in the package.

Since lintian doesn't do network requests it will have to detect
solely based on the URL rather than content of the Homepage.

URLs to ftp servers that end in a slash should be detected:

   ^ftp://.*/$

Maybe any ftp URL that doesn't end in .htm/.html should be detected?

You could also detect specific servers based on the URLs:

The first one that could be added is the GNU FTP server:

Please match this regular expression:

   (https?|ftp)://ftp\.gnu\.org/gnu/(.*)

and suggest replacing them with this replacement:

   https://www.gnu.org/software/$2

Please match this regular expression:

   (https?|ftp)://ftp\.gnu\.org/gnu/aspell/dict/[^/]*/

and suggest replacing them with this replacement (and ignore that URL):

   https://ftp.gnu.org/gnu/aspell/dict/0index.html

These are the currently known ftp.gnu.org URLs:

   $ grep -h Homepage.*ftp.gnu.org /var/lib/apt/lists/*Sources | sort -u
   Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/am/
Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/he/
Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/hy/
Homepage: ftp://ftp.gnu.org/non-gnu/chinese-fonts-truetype/
Homepage: http://ftp.gnu.org/gnu/aspell/dict/0index.html
Homepage: http://ftp.gnu.org/gnu/aspell/dict/ar/
Homepage: http://ftp.gnu.org/gnu/aspell/dict/fa/
Homepage: http://ftp.gnu.org/gnu/bc/
Homepage: http://ftp.gnu.org/gnu/pem/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[Wookey]

On 2020-05-12 01:04 +0200, John Paul Adrian Glaubitz wrote:
> On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote:
> > On 5/11/20 11:56 PM, Xavier wrote:
> >> Could someone help us here ? I forwarded this bug to upstream ([1]) but
> >> didn't receive any response for now.
> >>
> >> (Cc to RFH bug)
> > 
> > The problem here is va_list. On some architectures, the calling convention
> > doesn't seem to allow comparing va_list against NULL due to the way va_list
> > is implemented on a particular architecture.
> Correction: The va_list problem seems to affect ARM architectures only.

This is a classic 'porting to arm' issue which used to catch people
out regularly 15 years ago because it was something where you could do
technically incorrect things that worked fine on other
architectures. It's a very long time since I saw something hit this issue.

Thanks for the patch Adrian.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#904893: duck: Duck webpage footer points to anonscm.debian.org link which is 404

[Paul Wise]

Control: tags 904893 + pending

On Sun, 29 Jul 2018 10:44:23 +0100 Ian Campbell wrote:

> I tried to search[2] on Salsa for a replacement

Since Simon has retired from Debian and orphaned the duck package, I
migrated the git repos from alioth-archive.d.o to salsa and made a few
fixes in the git repositories. I have also fixed the VCS link in the
duck-website git repository. I initiated a discussion with Simon about
moving the duck.debian.net domain somewhere else but didn't yet get a
response. I don't have the time to maintain the package or the service
but I hope someone else does. In case you want to move the service to
duck.debian.org, check out the documentation provided below.

https://bugs.debian.org/960137
https://salsa.debian.org/debian/duck
https://salsa.debian.org/debian/duck-website
https://wiki.debian.org/ServicesHosting

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#734752: sudo, pam_limits, users with same UID

[Todd C. Miller]

This has been fixed in sudo 1.9.0:
https://www.sudo.ws/repos/sudo/rev/b45608f29a02

Bug#571621: sudoers grammar doesn't show that sudoedit takes an argument

[Todd C. Miller]

In sudo 1.9.0, the sudoers grammar in the manual now indicates that
"sudoedit" requires one or more arguments.

 - todd

Bug#956640: Here's how to fix this issue

[Stevo Pusser]

patch via ungoogled-chromium and Fedora. Refactor
debian/patches/fixes/gl.patch to make the changed line read

+  glx_image_ = new gl::GLImageGLX(size_, gfx::BufferFormat::BGRX_);

And rebuild. Proof of concept here:

https://build.opensuse.org/package/show/home:stevenpusser:schmonium/chromium

Bug#669687: sudo does not call pam_end on authorization failure

[Todd C. Miller]

Sudo 1.9.0 includes a fix for this:
www.sudo.ws/repos/sudo/rev/98cb9d98f547

Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Noah Meyerhans]

Control: tags -1 + patch

> I'll move this package to a cloud-team repository and prepare an upload
> to unstable on Monday if nobody beats me to it.

https://salsa.debian.org/cloud-team/python-boto/-/merge_requests/1

Bug#958256: Use system libjsonparser-dev

[наб]

Hi!

I'm attaching a patch, based on the Salsa HEAD at 82d10d0,
to do just that.

The package builds with src/json.[ch] removed, too. Could probably be an
uscan exclusion rule, but I didn't want to touch the legacy d/copyright.

Best,
наб
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: libc6 (>= [-2.29)-] {+2.27), libjsonparser1.1 (>= 1.1.0)+}
Installed-Size: [-515-] {+507+}
From 2ab04febc4618de2517a0b1ccda28f7cb2804357 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Tue, 12 May 2020 03:20:32 +0200
Subject: [PATCH] Add patch and Build-Depends to use system libjsonparser

Closes: #958256
---
 debian/control   |  2 +-
 debian/patches/series|  1 +
 debian/patches/use-system-libjsonparser.diff | 49 
 3 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/use-system-libjsonparser.diff

diff --git a/debian/control b/debian/control
index 172edb7..b05ed20 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: remind
 Section: utils
 Priority: optional
 Maintainer: Ana Beatriz Guerrero Lopez 
-Build-Depends: debhelper (>= 10), cdbs
+Build-Depends: debhelper (>= 10), cdbs, libjsonparser-dev
 Standards-Version: 4.5.0
 Homepage: https://dianne.skoll.ca/projects/remind/
 Vcs-Git: https://salsa.debian.org/debian/remind.git
diff --git a/debian/patches/series b/debian/patches/series
index 6d8f97d..352cc12 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 do-not-strip.diff
+use-system-libjsonparser.diff
diff --git a/debian/patches/use-system-libjsonparser.diff b/debian/patches/use-system-libjsonparser.diff
new file mode 100644
index 000..b0c9efb
--- /dev/null
+++ b/debian/patches/use-system-libjsonparser.diff
@@ -0,0 +1,49 @@
+From: наб 
+Date: Tue, 12 May 2020 03:14:11 +0200
+Subject: Use system libjsonparser
+
+---
+ src/Makefile.in | 6 +++---
+ src/rem2ps.c| 2 +-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/Makefile.in b/src/Makefile.in
+index fb24a2c..b895e9c 100644
+--- a/src/Makefile.in
 b/src/Makefile.in
+@@ -45,8 +45,8 @@ test: remind
+ 
+ $(REMINDOBJS): $(REMINDHDRS)
+ 
+-rem2ps: rem2ps.o dynbuf.o json.o
+-	@CC@ @LDFLAGS@ $(LDEXTRA) -o rem2ps rem2ps.o dynbuf.o json.o -lm
++rem2ps: rem2ps.o dynbuf.o
++	@CC@ @LDFLAGS@ $(LDEXTRA) -o rem2ps rem2ps.o dynbuf.o -ljsonparser -lm
+ 
+ remind: $(REMINDOBJS)
+ 	@CC@ @LDFLAGS@ $(LDEXTRA) -o remind $(REMINDOBJS) @LIBS@
+@@ -74,7 +74,7 @@ clobber:
+ 	rm -f *.o *~ remind rem2ps test.out core *.bak
+ 
+ depend:
+-	gccmakedep @DEFS@ $(REMINDSRCS) rem2ps.c json.c
++	gccmakedep @DEFS@ $(REMINDSRCS) rem2ps.c
+ 
+ # The next targets are not very useful to you.  I use them to build
+ # distributions, etc.
+diff --git a/src/rem2ps.c b/src/rem2ps.c
+index a32af96..2646fd0 100644
+--- a/src/rem2ps.c
 b/src/rem2ps.c
+@@ -20,7 +20,7 @@
+ #include 
+ #include 
+ #include "rem2ps.h"
+-#include "json.h"
++#include "json-parser/json.h"
+ 
+ #define NEW(type) (malloc(sizeof(type)))
+ 
+-- 
+2.20.1
+
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#960199: libexif: CVE-2020-12767

[Hugh McMaster]

Control: tags -1 + pending

This is already fixed upstream. I'll push it to Debian shortly.

Hugh

Bug#960364: nmu: libalien-wxwidgets-perl_0.69+dfsg-3

[Scott Talbert]

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

nmu libalien-wxwidgets-perl_0.69+dfsg-3 . ANY . unstable . -m "Rebuild for new 
wxwidgets3.0 3.0.5.1+dfsg release"

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

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

Bug#960363: RFS: qterm/1:0.7.3-3 -- BBS client for X Window System written in Qt

[atzlinux 肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : qterm
Version : 1:0.7.3-3
Upstream Author : [fill in name and email of upstream]
* URL : https://github.com/qterm/qterm
* License : GPL-2+ with OpenSSL exception
* Vcs : https://salsa.debian.org/chinese-team/qterm
Section : x11

It builds those binary packages:

qterm - BBS client for X Window System written in Qt

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/q/qterm/qterm_0.7.3-3.dsc

Changes since the last upload:

[ Debian Janitor ]
* Bump debhelper from old 11 to 12.
* Set debhelper-compat version in Build-Depends.
* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
Repository-Browse.
[ 肖盛文 ]
* add Uploaders: xiao sheng wen 
* Bump debhelper-compat (= 13)
* Bump Standards-Version: 4.5.0
* add Rules-Requires-Root: no
* fix lintian: desktop-entry-lacks-keywords-entry
* fxi lintian: spelling-error-in-binary
* add patches/series
* fix lintian: debian-rules-uses-as-needed-linker-flag

Regards,

-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#956260: bkchem: should this package be removed?

[Stuart Prescott]

> > What exactly is it blocking?
> 
> It blocks reverse deps from removing their Python 2 packages (or if
> Py2-specific the package at large), which in turn block the removal
> of other packages.
> 
> In the case of bkchem python-pil and python-pmw, which in turn block
> the removal of python-tk.

As bkchem is no longer in testing and the Python 2 version of bkchem can 
*never* migrate back to testing, these rdeps can now drop their Python 2 
packages without making testing more buggy. 

* python-pil is already only cruft and is not in testing. 

* python-pmw can also be removed from testing now as it has no rdeps in 
testing and will be autoremoved soon; it may as well be removed from the 
archive entirely, unless someone wants to upgrade it to the Python 3 version 
just for the fun of it.

(This has been the standard practice throughout the process of removing Python 
2 and is the reason why the bugs are slowly elevated in severity; ideally, we 
never get as far as breaking packages that are in unstable but that is not a 
hard requirement in *any* transition, much less big and messy one like this.)

The Python 2 version of bkchem will not be released with bullseye, so we may 
as well make it easier for those trying to do other things for the bullseye 
release.

*If* a Python 3 version of bkchem appears we can get it into bullseye. I doubt 
that is ever going to appear, however, as that effort is tangled with several 
other changes to modules that bkchem currently ships embedded copies of; a 
py3-bkchem therefore needs to catch up with changes to other modules as well 
as port to Python 3. All this without a test suite to help catch the 
inevitable porting problems.

I say this as a bkchem user who doesn't have a good Plan B :(

regards
Stuart


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

Bug#960362: transmission: new upstream 3.00

[Jonatan Nyberg]

Package: transmission
Version: 3.00

Please consider to upgrade to the current upstream version (3.00).

Regards
Jonatan

Bug#960361: src:chromium: FTBFS with re2 20200501

[Stefano Rivera]

Package: src:chromium
Version: 81.0.4044.92-1
Severity: normal
Tags: upstream patch
Control: block 960360 by -1

Chromium needs this (1-line) patch to build with re2 20200501
https://github.com/chromium/chromium/commit/ede390a0b18e4565abf8ac1e1ff717e1d43fc320

> Clean up a call to set_utf8().
> This is part of an effort to rewrite calls to utf8() and set_utf8()
> (in RE2::Options) as calls to encoding() and set_encoding(),
> respectively. utf8() and set_utf8() have been marked as the "legacy"
> interface since 2008, so it is long past time that we get rid of them.

This is is upstream in 84.0.4115.0, and applies cleanly to
81.0.4044.92-1.

Please backport it, so that we can update RE2.

re2 20200501 is available in experimental.

SR

Bug#960360: transition: re2

[Stefano Rivera]

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

Public ABI Breakage:
Types changed from maps to vectors in a couple of functions. Nothing in
Debian uses them.

Public API Breakage:
The deprecated RE2::Options::set_utf8 and RE2::Options::utf8 helper
functions were removed from re2.h.

https://github.com/google/re2/commit/58141dc9c92189ed8d046f494f5e034d5db91bea
https://github.com/google/re2/commit/ac65d4531798ffc9bf807d1f7c09efb0eec70480

Reverse Dependencies:
* Updated ruby-re2 to 1.2.0 to support this.
* Chromium needs a patch:
  
https://github.com/chromium/chromium/commit/ede390a0b18e4565abf8ac1e1ff717e1d43fc320
* Others build without error.

Ben file:

title = "re2";
is_affected = .depends ~ "libre2-6" | .depends ~ "libre2-7";
is_good = .depends ~ "libre2-7";
is_bad = .depends ~ "libre2-6";

https://release.debian.org/transitions/html/auto-re2.html LGTM

SR

Bug#960339: ITP: adios2 -- ADIOS2 Adaptable IO system for simulations

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: adios2
  Version : 2.6.0
  Upstream Author : Oak Ridge National Laboratory
* URL : https://github.com/ornladios/ADIOS2
* License : Apache
  Programming Lang: C++
  Description : ADIOS2 Adaptable IO system for simulations

The Adaptable IO System (ADIOS) provides a simple, flexible way for
scientists to describe the data in their code that may need to be
written, read, or processed outside of the running simulation. By
providing an external to the code XML file describing the various
elements, their types, and how you wish to process them this run, the
routines in the host code (either Fortran or C) can transparently
change how they process the data.

Kyle

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[Michael Cree]

On Tue, May 12, 2020 at 01:04:06AM +0200, John Paul Adrian Glaubitz wrote:
> On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote:
> > On 5/11/20 11:56 PM, Xavier wrote:
> >> Could someone help us here ? I forwarded this bug to upstream ([1]) but
> >> didn't receive any response for now.
> >>
> >> (Cc to RFH bug)
> > 
> > The problem here is va_list. On some architectures, the calling convention
> > doesn't seem to allow comparing va_list against NULL due to the way va_list
> > is implemented on a particular architecture.
> Correction: The va_list problem seems to affect ARM architectures only

According to the standard va_list is a complete object type.  There is
therefore no guarantee it can be compared to NULL and it is only by
accident (implementation detail) that is possible to do so on some
architectures.

Cheers,
Michael.

Bug#960338: ITP: python-mergedict -- A Python dict with a merge() method

[Inaki Malerba]

Package: wnpp
Owner: Iñaki Malerba 
Severity: wishlist

* Package name: python-mergedict
  Version : 1.0.0
  Upstream Author : Eduardo Naufel Schettino 
* URL : https://github.com/schettino72/mergedict
* License : MIT
  Programming Lang: Python
  Description : A Python dict with a merge() method

A MergeDict is a dict with a merge() method. merge() is like
dict.update(), but it can be subclassed to create custom
"merge" operations based on the type of an item value.

The mergedict module comes with a ConfigDict that will
extend/update lists/sets/dicts.

Needed as a dependency to close an RC bug in src:doit


-- 
- ina



signature.asc
Description: OpenPGP digital signature

Bug#960337: ITP: libevpath -- Event transport middleware

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: libevpath
  Version : 4.6.0
  Upstream Author : Georgia Tech Research Corporation
* URL : https://github.com/GTkorvo/evpath
* License : BSD-3-clause
  Programming Lang: C
  Description : Event transport middleware

EVpath is an event transport middleware layer designed to allow for the
easy implementation of overlay networks, with active data processing,
routing and management at all points in the overlay.

Kyle

Bug#960249: inn2: Please enable DO_RNEWS_SAVE_BAD for rnews

[Herbert Xu]

On Mon, May 11, 2020 at 09:07:06PM +0200, Julien ÉLIE wrote:
> 
> I don't believe enabling this setting by default is a good idea.
> Nevertheless, you're right that having an inn.conf parameter to enable it,
> if the news admin wants, would be better.

Yes, a run-time configuration option would be the best.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#959742: closed by Debian FTP Masters (reply to Ondřej Surý ) (Bug#959742: fixed in php-defaults 76)

[Sunil Mohan Adapa]

Dear Ondřej,

Many thanks for fixing this.

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#960336: RFS: gtkorvo-libenet/1.3.15-1 [ITP] -- Georgia Tech fork of libenet

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

Dear mentors,

I am looking for a sponsor for my package "gtkorvo-libenet":

 * Package name: gtkorvo-libenet
   Version : 1.3.15-1
   Upstream Author : Lee Salzman
 * URL : https://github.com/GTkorvo/enet
 * License : other
 * Vcs : https://gitlab.kitware.com/debian/gtkorvo-libenet
   Section : libs

It builds those binary packages:

  gtkorvo-libenet-dev - Georgia Tech fork of libenet -
development files
  gtkorvo-libenet7 - Georgia Tech fork of libenet
  gtkorvo-libenet-doc - Georgia Tech fork of libenet -
documentation

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

  https://gitlab.kitware.com/debian/gtkorvo-libenet

Regards,

--
  Kyle Edwards

Bug#960335: texlive-binaries: texhash is missing

[eb]

Package: texlive-binaries
Version: 2020.20200327.54578-4
Severity: normal

Dear Maintainer,

The current version of the package does not contain /usr/bin/texhash
which should be a link to /usr/bin/mktexlsr

Without texthash it is impossible to install Automatic Journal Title 
Abbreviation Package for LaTeX (https://github.com/compholio/jabbrv).

Adding this link manually resolves the issue.

Regards,
eb

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

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

Versions of packages texlive-binaries depends on:
ii  dpkg1.19.7
ii  install-info6.7.0.dfsg.2-5
ii  libc6   2.30-7
ii  libcairo2   1.16.0-4
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgcc-s1   10-20200418-1
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   2.6.4-1
ii  libicu6363.2-3
ii  libkpathsea62020.20200327.54578-4
ii  libmpfr64.0.2-1
ii  libpaper1   1.1.28+b1
ii  libpixman-1-0   0.36.0-1
ii  libpng16-16 1.6.37-2
ii  libptexenc1 2020.20200327.54578-4
ii  libstdc++6  10-20200418-1
ii  libsynctex2 2020.20200327.54578-4
ii  libteckit0  2.5.8+ds2-5
ii  libtexlua53 2020.20200327.54578-4
ii  libtexluajit2   2020.20200327.54578-4
ii  libx11-62:1.6.9-2+b1
ii  libxaw7 2:1.0.13-1+b2
ii  libxi6  2:1.7.9-1
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  libzzip-0-130.13.62-3.2
ii  perl5.30.0-10
ii  t1utils 1.41-4
ii  tex-common  6.14
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages texlive-binaries recommends:
ii  dvisvgm   2.9.1-1
ii  texlive-base  2020.20200417-1

texlive-binaries suggests no packages.

-- no debconf information

Bug#960358: exim4-base: spec.txt, NFS and file locking

[Vincent Lefevre]

Package: exim4-base
Version: 4.93-15
Severity: normal

In /usr/share/doc/exim4-base/spec.txt.gz :


In order to append to an NFS file safely from more than one host, it is
necessary to take out a lock before opening the file, and the lock file
achieves this. Otherwise, even with fcntl() locking, there is a risk of file
corruption.


I don't see why. If used correctly, fcntl() locking should be
sufficient under NFS. And if fcntl() locking is broken, lock files
won't prevent corruption anyway: even if you have the lock, there
is no guarantee that the client will synchronize the changes with
the server before another process gets the lock and do changes
(this is the problem I had with shared zsh history, which often
got corrupted even though zsh used some form of locking... until
I patched it in 2008 to use fcntl() locking).

-- Package-specific info:
Exim version 4.93 #5 built 25-Apr-2020 12:10:47
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event I18N OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4-base depends on:
ii  adduser3.118
ii  anacron2.3-29
ii  cron [cron-daemon] 3.0pl1-136
ii  debconf [debconf-2.0]  1.5.74
ii  exim4-config [exim4-config-2]  4.93-15
ii  libc6  2.30-4
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  lsb-base   11.1.0
ii  netbase6.1
ii  systemd-sysv   245-2

Versions of packages exim4-base recommends:
ii  mailutils [mailx]  1:3.7-2.1
ii  psmisc 23.3-1

Versions of packages exim4-base suggests:
ii  emacs-gtk [mail-reader]  1:26.3+1-1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.38-4
ii  gnutls-bin   3.6.13-2
ii  mailutils [mail-reader]  1:3.7-2.1
ii  mutt [mail-reader]   1.13.2-1
ii  openssl  1.1.1g-1
pn  spf-tools-perl   
pn  swaks

-- debconf information excluded

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

Bug#960359: nlohmann-json-dev: cmake configuration files are installed in the wrong directory

[Simon Désaulniers]

Package: nlohmann-json-dev
Version: 2.1.1-1.1
Severity: important
Tags: patch

Dear Maintainer,

When trying to build my project which depends on nlohmann-json-dev 2.1.1, using
CMake leads to configuration files not found. See the error message below:

Could not find a package configuration file provided by "nlohmann_json"
(requested version 2.1.1) with any of the following names:

  nlohmann_jsonConfig.cmake
  nlohmann_json-config.cmake

Add the installation prefix of "nlohmann_json" to CMAKE_PREFIX_PATH or set
"nlohmann_json_DIR" to a directory containing one of the above files.  If
"nlohmann_json" provides a separate development package or SDK, be sure it
has been installed.

This is due to the files not being installed correctly on the system. The
package installs them to the following paths:

/usr/lib/cmake/*.cmake

However, according to CMake documentation~[1], the files should be found under
one of the following directories:

/(lib/|lib*|share)/cmake/*/
/(lib/|lib*|share)/*/
/(lib/|lib*|share)/*/(cmake|CMake)/
/*/(lib/|lib*|share)/cmake/*/
/*/(lib/|lib*|share)/*/
/*/(lib/|lib*|share)/*/(cmake|CMake)/

Therefore, the directory for nlohmann-json should rather be:

/usr/lib/cmake/nlohmann_json/

and not

/usr/lib/cmake/

I did include a patch for fixing this in the attchments of this mail.

Note that the package doesn't seem to build now in unstable due to tests failing
to compile. If you're to provide a new version for this package in order to
address this issue, you may have to disable tests (or go around the issue if you
investigate more than I did). I have attached a patch (for debian/rules file)
for this as well which you can use.

Regards,

[1]: https://cmake.org/cmake/help/v3.13/command/find_package.html

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com
commit cd93409ebc0bac1a0c61a4262801a96673c29995
Author: Simon Désaulniers 
Date:   Mon May 11 18:17:55 2020 -0400

patches: cmake path should contain project name

According to
https://cmake.org/cmake/help/v3.13/command/find_package.html.

diff --git a/debian/patches/0002-fix-path-for-cmake-files.patch b/debian/patches/0002-fix-path-for-cmake-files.patch
index edcf86ba..0bdc9d4a 100644
--- a/debian/patches/0002-fix-path-for-cmake-files.patch
+++ b/debian/patches/0002-fix-path-for-cmake-files.patch
@@ -7,7 +7,7 @@ Subject: fix path for cmake files
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 30e3966..6279544 100644
+index 30e3966..839d2cb 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -13,7 +13,7 @@ set(JSON_PACKAGE_NAME ${JSON_TARGET_NAME})
@@ -15,7 +15,7 @@ index 30e3966..6279544 100644
  set(JSON_CONFIG_FILENAME "${JSON_PACKAGE_NAME}Config.cmake")
  set(JSON_CONFIGVERSION_FILENAME "${JSON_PACKAGE_NAME}ConfigVersion.cmake")
 -set(JSON_CONFIG_DESTINATION "cmake")
-+set(JSON_CONFIG_DESTINATION "lib/cmake")
++set(JSON_CONFIG_DESTINATION "lib/cmake/${PROJECT_NAME}/")
  set(JSON_INCLUDE_DESTINATION "include/nlohmann")
  
  set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
diff --git a/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch b/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
index 4db82c9e..ecd746fe 100644
--- a/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
+++ b/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
@@ -7,11 +7,11 @@ Subject: [PATCH] modify json.hpp to compile with recent gcc
 
 https://github.com/nlohmann/json/issues/606
 ---
- src/json.hpp | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
+ src/json.hpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/json.hpp b/src/json.hpp
-index c2e1f20..48d797d 100644
+index 6dfc183..5259d06 100644
 --- a/src/json.hpp
 +++ b/src/json.hpp
 @@ -6054,7 +6054,7 @@ class basic_json
commit 5df7a99f4fff4e564da65ad884926dd6aff402b6
Author: Simon Désaulniers 
Date:   Mon May 11 19:39:35 2020 -0400

rules: don't build tests

diff --git a/debian/rules b/debian/rules
index 9ab5610f..8701eb09 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@ override_dh_clean:
 	dh_clean
 	make -C doc clean
 
+override_dh_auto_configure:
+	dh_auto_configure -- -DBuildTests=OFF
+
 override_dh_auto_build:
 	make re2c
 	make -C doc


signature.asc
Description: PGP signature

Bug#960335: texlive-binaries: texhash is missing

[Norbert Preining]

reassign 960335 texlive-base
tags 960335 + pending
thanks

On Mon, 11 May 2020, eb wrote:
> The current version of the package does not contain /usr/bin/texhash
> which should be a link to /usr/bin/mktexlsr

Thanks for the report - and it is good to hear that practically nobody
is using texhash anymore ;-)

> Without texthash it is impossible to install Automatic Journal Title 
> Abbreviation Package for LaTeX (https://github.com/compholio/jabbrv).

That install.sh script is anyway borken, doesn't search correct
directories, installs into system directories, all no-no-go.

The correct way would be to install into TEXMFLOCAL by using
kpsewhich -var-value TEXMFLOCAL
and install there, if no target is given. Furthermore, it should call
mktexlsr instead of texhash ;-)

Anyway, the next upload will bring back texhash, committed to git.

Thanks for the report.

Norbert

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

Bug#960012: Info received ((No Subject))

[Johan Fleury]

I believe this is also the cause of issues with PrivateBin version 1.3 and 
higher. It is not possible to send or read a paste. Reading a paste will result 
in:

```
DOMException: "The operation failed for an operation-specific reason" 
privatebin.js:1240:25
decipher https://[PrivateBin Server]/js/privatebin.js?1.3.4:1240
```

Version prior to 1.3 used JS libraries while newer version uses WebCrypto API 
and AES GCM. I suppose this is broken by the NSS 3.52 - Firefox 76 
incompatibility.

--
Johan Fleury
PGP Key ID : 0x5D404386805E56E6

signature.asc
Description: OpenPGP digital signature

Bug#960357: Vuls still uses obsolete and deprecated "github.com/hashicorp/uuid" library

[Dmitry Smirnov]

Source: vuls
Version: 0.7.0-1
Severity: normal
Control: forwarded -1 https://github.com/future-architect/vuls/issues/929

Vuls still uses obsolete and deprecated "github.com/hashicorp/uuid" library
that should be removed from Debian.

Recently upstream replaced this library with "github.com/hashicorp/go-uuid":

  https://github.com/future-architect/vuls/commit/9dd025437

Please consider replacing the obsolete library so we could request its removal.

Thanks.

-- 
Cheers,
 Dmitry Smirnov

---

Richard Nixon got kicked out of Washington for tapping one hotel suite.
Today we're tapping every American citizen in the country, and no one has
been put on trial for it or even investigated. We don't even have an
inquiry into it.
-- Edward Snowden


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

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[David Farrier]

I see I am coming to this thread a bit late, but for what it is worth, 
here is some additional information.


But first, thanks to Udo Richter for suggesting the workaround of 
installing linux-image-5.4.0-0.bpo.2-amd64, in other words backporting the 
testing/bullseye kernel into buster. On my laptop, this fixed the 
intermittent problem restoring blanked screen. It also seems to have 
introduced a new problem where the computer occasionally does not blank 
or lock when it should, but that is far better than occasionally losing 
work-in-progress due to inability to restore the screen.


However, this does not seem to simply be a case of buster's default 4.19.0 
kernel being buggy. I say this, because I tried the backport version of 
4.19.0 in stretch. On my laptop, screen blanking and locking work just 
fine in stretch, regardless whether it is the default 4.9.0 or the 
backported 4.19.0 kernel. Apparently, something besides the kernel 
changed between stretch and buster.


Some background info: I have been testing with the xfce desktop on a 
Panasonic CF-19 laptop. Intel Corporation Xeon E3-1200 v3/4th Gen Core 
Processor Integrated Graphics Controller (rev 06)

Bug#960356: exim4-base: the exim_lock(8) refers to section 25.2, which does not exist

[Vincent Lefevre]

Package: exim4-base
Version: 4.93-15
Severity: minor

In the exim_lock(8) man page:

  The  exim_lock utility locks a mailbox file using the same algorithm as
  Exim.  For a discussion of locking issues, see section 25.2.  exim_lock
 

But /usr/share/doc/exim4-base/spec.txt.gz does not have such a
section. Shouldn't it be section 26.3?

This is what /usr/share/doc/exim4-base/spec.txt.gz section 54.15
gives:

The exim_lock utility locks a mailbox file using the same algorithm as Exim.
For a discussion of locking issues, see section 26.3. Exim_lock can be used to


-- Package-specific info:
Exim version 4.93 #5 built 25-Apr-2020 12:10:47
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event I18N OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4-base depends on:
ii  adduser3.118
ii  anacron2.3-29
ii  cron [cron-daemon] 3.0pl1-136
ii  debconf [debconf-2.0]  1.5.74
ii  exim4-config [exim4-config-2]  4.93-15
ii  libc6  2.30-4
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  lsb-base   11.1.0
ii  netbase6.1
ii  systemd-sysv   245-2

Versions of packages exim4-base recommends:
ii  mailutils [mailx]  1:3.7-2.1
ii  psmisc 23.3-1

Versions of packages exim4-base suggests:
ii  emacs-gtk [mail-reader]  1:26.3+1-1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.38-4
ii  gnutls-bin   3.6.13-2
ii  mailutils [mail-reader]  1:3.7-2.1
ii  mutt [mail-reader]   1.13.2-1
ii  openssl  1.1.1g-1
pn  spf-tools-perl   
pn  swaks

-- debconf information excluded

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

Bug#960012: (No Subject)

[Johan Fleury]

merge 960012 959971
thanks

signature.asc
Description: OpenPGP digital signature

Bug#960229: [DRE-maint] Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Georg Faerber]

Hi Rogério,

On 20-05-11 15:22:04, Rogério Brito wrote:
> Thanks for the kind message. I gave it a shot with gem2deb and I
> produced a (very) preliminary package. It is at:
> 
> https://github.com/rbrito/pkg-pdfbeads

Did you import the latest upstream release? The gemspec tells
"2014-01-30", which was quite some time ago.

Did you try to build the package? Did it work?

Cheers,
Georg

Bug#960355: Invalid serial console blocks system boot

[Jonas Zeiger]

Package: initramfs-tools-core
Version: 0.137

Putting a serial console on a non-existent/broken serial port
via the last "console=" argument of the kernel command line
causes the initrd to hang without completing the boot process.

If the problematic serial console argument comes first in the kernel
command line, the system boots without issues.


***To reproduce:***

1. Check for a non-connected/disabled serial port.

On the problematic system running

[$] stty -a -F /dev/ttyS1
stty: /dev/ttyS1: Input/output error

	The serial ports are registered by the "serial8250" driver but are 
probably not wired to anything.



2. Boot with a kernel command line that puts serial console on a 
non-existent/broken serial port via last "console=" argument:


console=tty0 console=ttyS1,115200n8


3. Check if system boots successfully


I am using Debian GNU/Linux 11 (bullseye/testing), vanilla kernel 
5.7-rc5.



This issue was initially reported multiple times for Debian and Ubuntu
to the systemd maintainers as:

https://github.com/systemd/systemd/issues/15656  (for Ubuntu)
https://github.com/systemd/systemd/issues/15783  (for Debian, duplicate)


I am not sure if the _exact_ cause of both issues is the same,
because I observed the problem on a very minimal system without
console-setup or kbd.

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[John Paul Adrian Glaubitz]

On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote:
> On 5/11/20 11:56 PM, Xavier wrote:
>> Could someone help us here ? I forwarded this bug to upstream ([1]) but
>> didn't receive any response for now.
>>
>> (Cc to RFH bug)
> 
> The problem here is va_list. On some architectures, the calling convention
> doesn't seem to allow comparing va_list against NULL due to the way va_list
> is implemented on a particular architecture.
Correction: The va_list problem seems to affect ARM architectures only.

The other architectures have testsuite failures which seem unrelated.

Adrian

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

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[John Paul Adrian Glaubitz]

Hi Xavier!

On 5/11/20 11:56 PM, Xavier wrote:
> Could someone help us here ? I forwarded this bug to upstream ([1]) but
> didn't receive any response for now.
> 
> (Cc to RFH bug)

The problem here is va_list. On some architectures, the calling convention
doesn't seem to allow comparing va_list against NULL due to the way va_list
is implemented on a particular architecture.

You could maybe add an auxiliary boolean variable to control whether
"va_list args" is empty or not, i.e. something like this:

Index: cyrus-imapd-3.2.0/imap/httpd.c
===
--- cyrus-imapd-3.2.0.orig/imap/httpd.c
+++ cyrus-imapd-3.2.0/imap/httpd.c
@@ -2350,7 +2350,7 @@ EXPORTED void simple_hdr(struct transact
 simple_hdr(txn, "Access-Control-Expose-Headers", hdr)
 
 static void comma_list_body(struct buf *buf,
-const char *vals[], unsigned flags, va_list args)
+const char *vals[], unsigned flags, int has_args, 
va_list args)
 {
 const char *sep = "";
 int i;
@@ -2358,11 +2358,11 @@ static void comma_list_body(struct buf *
 for (i = 0; vals[i]; i++) {
 if (flags & (1 << i)) {
 buf_appendcstr(buf, sep);
-if (args) buf_vprintf(buf, vals[i], args);
+if (has_args) buf_vprintf(buf, vals[i], args);
 else buf_appendcstr(buf, vals[i]);
 sep = ", ";
 }
-else if (args) {
+else if (has_args) {
 /* discard any unused args */
 vsnprintf(NULL, 0, vals[i], args);
 }
@@ -2377,7 +2377,7 @@ EXPORTED void comma_list_hdr(struct tran
 
 va_start(args, flags);
 
-comma_list_body(, vals, flags, args);
+comma_list_body(, vals, flags, 1, args);
 
 va_end(args);
 
@@ -3077,17 +3077,17 @@ EXPORTED void response_header(long code,
 }
 if (code == HTTP_SWITCH_PROT || code == HTTP_UPGRADE) {
 buf_printf(logbuf, "%supgrade=", sep);
-comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, NULL);
+comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, 0, 0);
 sep = "; ";
 }
 if (txn->flags.te) {
 buf_printf(logbuf, "%stx-encoding=", sep);
-comma_list_body(logbuf, te, txn->flags.te, NULL);
+comma_list_body(logbuf, te, txn->flags.te, 0, 0);
 sep = "; ";
 }
 if (txn->resp_body.enc.proc) {
 buf_printf(logbuf, "%scnt-encoding=", sep);
-comma_list_body(logbuf, ce, txn->resp_body.enc.type, NULL);
+comma_list_body(logbuf, ce, txn->resp_body.enc.type, 0, 0);
 sep = "; ";
 }
 if (txn->location) {

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Don't try to compare va_list against NULL
Author: John Paul Adrian Glaubitz 
Last-Update: 2020-05-12


Index: cyrus-imapd-3.2.0/imap/httpd.c
===
--- cyrus-imapd-3.2.0.orig/imap/httpd.c
+++ cyrus-imapd-3.2.0/imap/httpd.c
@@ -2350,7 +2350,7 @@ EXPORTED void simple_hdr(struct transact
 simple_hdr(txn, "Access-Control-Expose-Headers", hdr)
 
 static void comma_list_body(struct buf *buf,
-const char *vals[], unsigned flags, va_list args)
+const char *vals[], unsigned flags, int has_args, va_list args)
 {
 const char *sep = "";
 int i;
@@ -2358,11 +2358,11 @@ static void comma_list_body(struct buf *
 for (i = 0; vals[i]; i++) {
 if (flags & (1 << i)) {
 buf_appendcstr(buf, sep);
-if (args) buf_vprintf(buf, vals[i], args);
+if (has_args) buf_vprintf(buf, vals[i], args);
 else buf_appendcstr(buf, vals[i]);
 sep = ", ";
 }
-else if (args) {
+else if (has_args) {
 /* discard any unused args */
 vsnprintf(NULL, 0, vals[i], args);
 }
@@ -2377,7 +2377,7 @@ EXPORTED void comma_list_hdr(struct tran
 
 va_start(args, flags);
 
-comma_list_body(, vals, flags, args);
+comma_list_body(, vals, flags, 1, args);
 
 va_end(args);
 
@@ -3077,17 +3077,17 @@ EXPORTED void response_header(long code,
 }
 if (code == HTTP_SWITCH_PROT || code == HTTP_UPGRADE) {
 buf_printf(logbuf, "%supgrade=", sep);
-comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, NULL);
+comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, 0, 0);
 sep = "; ";
 }
 if (txn->flags.te) {
 buf_printf(logbuf, "%stx-encoding=", sep);
-comma_list_body(logbuf, te, txn->flags.te, NULL);
+comma_list_body(logbuf, te, txn->flags.te, 0, 0);
 sep = "; ";
 }
 if (txn->resp_body.enc.proc) {
 buf_printf(logbuf, "%scnt-encoding=", sep);
-

Bug#960320: ITP: gtkorvo-libenet -- Georgia Tech fork of libenet

[Kyle Edwards]

Package: wnpp
Owner: Kyle Edwards 
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

* Package name: gtkorvo-libenet
  Version : 1.3.15
  Upstream Author : Lee Salzman
* URL : https://github.com/GTkorvo/enet
* License : other
  Programming Lang: C
  Description : Georgia Tech fork of libenet

This is the Georgia Tech fork of libenet, which changes libenet in
several ways:

1. It builds with a CMake buildsystem and exports CMake package config
files in addition to pkgconfig files
2. It add a new function, enet_host_get_sock_fd(), to allow access to
the internal file descriptor
3. It supports dynamic sizing of the internal peer array
4. It changes the protocol to support 24-bit peer IDs

Kyle

Bug#960229: [DRE-maint] Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Georg Faerber]

(Adding the Ruby team to the loop.)

Hi team, Rogério,

On 20-05-11 15:22:04, Rogério Brito wrote:
> On May 10 2020, Georg Faerber wrote:
> > On 20-05-10 17:24:12, Rogério Brito wrote:
> > > Since I don't know much ruby, I guess that it would be best to
> > > have people from the Ruby team maintain and/or package it. I am
> > > even willing to co-maintain it, if necessary, but, again, my
> > > knowledge of Ruby is minimal.
> > 
> > If you're interested in learning (on your own) and improving your
> > Ruby packaging skills, I'm happy to give you any help necessary.
> 
> Thanks for the kind message. I gave it a shot with gem2deb and I
> produced a (very) preliminary package. It is at:
> 
> https://github.com/rbrito/pkg-pdfbeads
> 
> The changelog, in particular, is very cluttered and should be cleaned,
> among other things. Regarding ruby-specific packaging stuff, I would
> love to get comments and/or corrections.
> 
> The package providing jbig2 should, really, be a Recommends instead of
> a Suggests, but since it is not in Debian yet, I left it as is for the
> time being.
> 
> > Let me know in case you're interested.
> 
> While I'm not sure if I am able to maintain this package (let's say
> that some use asks for a new feature), I won't know how to proceed.
> 
> Assistance and opinions is highly appreciated.

I would like to mentor Rogério and help them "learning by doing". To
make this easier, an account on salsa.d.o with (limited) access to the
team and/or the repo makes sense, IMHO.

Thoughts?

Cheers,
Georg

Bug#960319: RFS: cowsay/3.03+dfsg2-8 -- configurable talking cow

[James McDonald]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: cowsay
  Version : 3.03+dfsg2-8
  Upstream Author : Tony Monroe 
* URL : 
https://web.archive.org/web/20120527202447/http://www.nog.net/~tony/warez/cowsay.shtml
* License : COWSAY
* Vcs : https://salsa.debian.org/debian/cowsay
  Section : games

It builds those binary packages:

 cowsay - configurable talking cow
 cowsay-off - configurable talking cow (offensive cows)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-8.dsc

Changes since the last upload:

  * Fix capitalization of man page title as per man-pages(7)
  * Bump Standards-Version to 4.5.0
  * Bump debhelper compat to 13
  * Clear up various lintian errors

Regards,

--
James McDonald

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Tue, May 12, 2020 at 12:17:36AM +0200, Francesco Poli wrote:
> On Tue, 12 May 2020 06:55:00 +0900 Mike Hommey wrote:
> 
> > On Mon, May 11, 2020 at 11:34:39PM +0200, Francesco Poli wrote:
> [...]
> > > Yes, I downgraded firefox-esr and the bug vanished.
> > > This confirms that the issue is indeed caused by the new version of
> > > firefox-esr.
> > 
> > Or not. This could also be caused by some upgraded build dependency.
> 
> Well, that's another possibility, I agree...
> 
> > Do you have the resources to attempt rebuilding 68.7 against current
> > unstable?
> 
> I can try inside a pbuilder-managed sid chroot.
> 
> I issued the following command:
> 
>  $ dget 
> https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc
> 
> and obtained the unpacked source package.
> 
> Can you confirm that this the source I should attempt to build?

Sounds good.

Mike

Bug#960354: ytcc: Failed to migrate to testing for too long

[Boyuan Yang]

Source: ytcc
Version: 1.8.1-1
Severity: serious
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
X-Debbugs-CC: fre...@debian.org  fre...@linux.vnet.ibm.com

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:ytcc in its current
version in unstable has been trying to migrate for 273 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer period,
this usually means that bugs in the package in testing cannot be fixed via
unstable. Additionally, blocked packages can have impact on other packages,
which makes preparing for the release more difficult. Finally, it often
exposes issues with the package and/or its (reverse-)dependencies. We expect
maintainers to fix issues that hamper the migration of their package in a
timely manner.

Currently your package only needs another source-only upload to be able to
migrate to Testing; please refer to https://wiki.debian.org/SourceOnlyUpload
to see how to make a source-only upload.

Regards,
Boyuan Yang

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html


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

Bug#960353: haskell-hindent: Failed to migrate to testing for too long

[Boyuan Yang]

Source: haskell-hindent
Version:  5.3.1-1
Severity: serious
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
X-Debbugs-CC: cl...@debian.org


Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:haskell-hindent in its current
version in unstable has been trying to migrate for 154 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

Currently your package only needs another source-only upload to be able to
migrate to Testing; please refer to https://wiki.debian.org/SourceOnlyUpload
to see how to make a source-only upload.

Regards,
Boyuan Yang

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html


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

Bug#960312: RFS: libffs/1.7.0-1 [ITP] -- Data communication library

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@debian.org

Dear mentors,

I am looking for a sponsor for my package "libffs":

 * Package name: libffs
   Version : 1.7.0-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/ffs
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libffs
   Section : libs

It builds those binary packages:

  libffs-dev - Data communication library -
development files
  libffs - Data communication library

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

  https://gitlab.kitware.com/debian/libffs

Regards,

--
  Kyle Edwards

Bug#960351: mtd-utils: Add AES support

[Bastian Germann]

Package: mtd-utils
Severity: wishlist

mtd-utils can be built with AES support. As OpenSSL cannot be used for
license reasons, compile with wolfSSL's OpenSSL compatibility layer.
From 1d226f5bd2929ceef6df9a327a1cf492984e2a3b Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Tue, 12 May 2020 00:05:55 +0200
Subject: [PATCH] Add AES support via wolfSSL

---
 debian/control |  2 +-
 debian/patches/check-for-wolfssl.patch | 22 ++
 debian/patches/series  |  1 +
 debian/rules   |  2 ++
 4 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/check-for-wolfssl.patch

diff --git a/debian/control b/debian/control
index 5d296b5..1a8dca7 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: mtd-utils
 Section: utils
 Priority: optional
 Maintainer: Riku Voipio 
-Build-Depends: debhelper (>= 9), pkg-config, dh-autoreconf, dh-exec (>= 0.3), zlib1g-dev, libacl1-dev, libcmocka-dev , liblzo2-dev, uuid-dev, libzstd-dev
+Build-Depends: debhelper (>= 9), pkg-config, dh-autoreconf, dh-exec (>= 0.3), zlib1g-dev, libacl1-dev, libcmocka-dev , liblzo2-dev, uuid-dev, libwolfssl-dev (>= 4.4), libzstd-dev
 Build-Conflicts: libssl-dev
 Standards-Version: 4.3.0
 Homepage: http://www.linux-mtd.infradead.org/
diff --git a/debian/patches/check-for-wolfssl.patch b/debian/patches/check-for-wolfssl.patch
new file mode 100644
index 000..1c90b6f
--- /dev/null
+++ b/debian/patches/check-for-wolfssl.patch
@@ -0,0 +1,22 @@
+From 72e050136fc2ad363f67e082be3ab91902a15c3e Mon Sep 17 00:00:00 2001
+From: Bastian Germann 
+Date: Mon, 11 May 2020 22:03:33 +0200
+Subject: [PATCH] Check for wolfSSL
+
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1b97ff6..1061c33 100644
+--- a/configure.ac
 b/configure.ac
+@@ -252,7 +252,7 @@ fi
+ 
+ if test "x$need_openssl" = "xyes"; then
+ 	AC_CHECK_HEADER(openssl/rand.h)
+-	PKG_CHECK_MODULES(OPENSSL, [openssl], [], [openssl_missing="yes"])
++	PKG_CHECK_MODULES(OPENSSL, [wolfssl], [], [openssl_missing="yes"])
+ fi
+ 
+ if test "x$need_cmocka" = "xyes"; then
diff --git a/debian/patches/series b/debian/patches/series
index 2b16aae..bf09369 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+check-for-wolfssl.patch
 libubigen-remove-unnecessary-include.patch
 libubi-remove-private-kernel-header.patch
diff --git a/debian/rules b/debian/rules
index 14b0bb2..9b8da76 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,6 @@
 #!/usr/bin/make -f
+export DEB_CPPFLAGS_MAINT_APPEND=-I/usr/include/wolfssl
+
 %:
 	dh $@ --parallel --with autoreconf
 
-- 
2.26.2

Bug#960352: perl: crashes from perl in deallocation routines

[Jiri Palecek]

Package: perl
Version: 5.30.0-10
Severity: normal

Dear Maintainer,

I've discovered several crash dumps made by perl in my
/var/crash. However, I cannot debug them further since perl doesn't have
debug symbols in Debian. I could try to reproduce it under valgrind, but
without debug symbols this would be fruitless. The backtraces are like
this:

Core was generated by `/usr/bin/perl t/Pool01.t'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00516406 in Perl_op_free ()
(gdb) bt
#0  0x00516406 in Perl_op_free ()
#1  0x005733bc in Perl_cv_undef_flags ()
#2  0x00573822 in Perl_cv_undef ()
#3  0x005df2fa in Perl_sv_clear ()
#4  0x005dfa9e in Perl_sv_free2 ()
#5  0x00611e79 in Perl_free_tmps ()
#6  0x00539c52 in perl_destruct ()
#7  0xb79bf5ea in ?? () from 
/usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so
#8  0xb79c14ec in ?? () from 
/usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so
#9  0x005d9b98 in Perl_pp_entersub ()
#10 0x005cfec9 in Perl_runops_standard ()
#11 0x0053542c in Perl_call_sv ()
#12 0x00538493 in Perl_call_list ()
#13 0x00539de2 in perl_destruct ()
#14 0x005123fe in main ()

Or this, similar:

Core was generated by `/usr/bin/perl t/Pool02.t'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb7f3cbad in __kernel_vsyscall ()
(gdb) bt
#0  0xb7f3cbad in __kernel_vsyscall ()
#1  0xb7c278b2 in __libc_signal_restore_set (set=0xbfa36a0c) at 
../sysdeps/unix/sysv/linux/internal-signals.h:84
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7c10309 in __GI_abort () at abort.c:79
#4  0xb7c6aa3c in __libc_message (action=, fmt=) 
at ../sysdeps/posix/libc_fatal.c:181
#5  0xb7c72b2d in malloc_printerr (str=str@entry=0xb7d7f7bc "munmap_chunk(): 
invalid pointer") at malloc.c:5339
#6  0xb7c72ddb in munmap_chunk (p=) at malloc.c:2830
#7  0x0051656e in Perl_Slab_Free ()
#8  0x00517287 in Perl_op_free ()
#9  0x0051742f in Perl_op_free ()
#10 0x005743bc in Perl_cv_undef_flags ()
#11 0x00574822 in Perl_cv_undef ()
#12 0x005e02fa in Perl_sv_clear ()
#13 0x005e0a9e in Perl_sv_free2 ()
#14 0x00612e79 in Perl_free_tmps ()
#15 0x0053ac52 in perl_destruct ()
#16 0xb799f5ea in ?? () from 
/usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so
#17 0xb79a14ec in ?? () from 
/usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so
#18 0x005dab98 in Perl_pp_entersub ()
#19 0x005d0ec9 in Perl_runops_standard ()
#20 0x0053642c in Perl_call_sv ()
#21 0x00539493 in Perl_call_list ()
#22 0x0053ade2 in perl_destruct ()
#23 0x005133fe in main ()

Problem is, I'm not 100% sure I can reproduce these crashes.

Could you look at this and maybe advise me how to debug it?

Regards
Jiri Palecek

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

Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perl depends on:
ii  dpkg   1.20.1~2.gbp7298ec
ii  libperl5.305.30.0-10
ii  perl-base  5.30.0-10
ii  perl-modules-5.30  5.30.0-10

Versions of packages perl recommends:
ii  netbase  6.1

Versions of packages perl suggests:
ii  libb-debug-perl  1.26-1
pn  liblocale-codes-perl 
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.36-2+b1
ii  make 4.2.1-1.3
ii  perl-doc 5.30.0-10

-- no debconf information

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Tue, 12 May 2020 06:55:00 +0900 Mike Hommey wrote:

> On Mon, May 11, 2020 at 11:34:39PM +0200, Francesco Poli wrote:
[...]
> > Yes, I downgraded firefox-esr and the bug vanished.
> > This confirms that the issue is indeed caused by the new version of
> > firefox-esr.
> 
> Or not. This could also be caused by some upgraded build dependency.

Well, that's another possibility, I agree...

> Do you have the resources to attempt rebuilding 68.7 against current
> unstable?

I can try inside a pbuilder-managed sid chroot.

I issued the following command:

 $ dget 
https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc

and obtained the unpacked source package.

Can you confirm that this the source I should attempt to build?


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


pgp1231FHrkqW.pgp
Description: PGP signature

Bug#958500: False positive for missing-build-dependency-for-dh_-command dh_gnome => gnome-pkg-tools

[Chris Lamb]

Hi Niels,

> I think that commit is missing "dh_gnome" in
> data/debhelper/dh_commands-manual?   At least matches the tag output.

Bingo, well spotted. Fix committed in:

  
https://salsa.debian.org/lintian/lintian/commit/3c6da207dd13ea4689482c37f47e85c4d3be1ca3


Regards,

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

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[Xavier]

> cyrus-imapd failed to build on almost all architectures. See
>
https://buildd.debian.org/status/fetch.php?pkg=cyrus-imapd=i386=3.2.0-1=1588581560=0
> and
>
https://buildd.debian.org/status/fetch.php?pkg=cyrus-imapd=arm64=3.2.0-1=1588581432=0
> for examples.

Hi,

Could someone help us here ? I forwarded this bug to upstream ([1]) but
didn't receive any response for now.

(Cc to RFH bug)

Cheers,
Xavier

[1]: https://github.com/cyrusimap/cyrus-imapd/issues/3040

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Mon, May 11, 2020 at 11:34:39PM +0200, Francesco Poli wrote:
> On Tue, 12 May 2020 06:03:17 +0900 Mike Hommey wrote:
> 
> > On Mon, May 11, 2020 at 06:27:01PM +0200, Francesco Poli (wintermute) wrote:
> > > Package: firefox-esr
> > > Version: 68.8.0esr-1
> > > Severity: important
> > > 
> > > Hello!
> > > 
> > > This morning I upgraded my Debian testing box, and firefox-esr
> > > had the following upgrade:
> > > 
> > >   [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1
> > 
> > Did you try downgrading?
> 
> Hello Mike,
> thanks for your followup.
> 
> Yes, I downgraded firefox-esr and the bug vanished.
> This confirms that the issue is indeed caused by the new version of
> firefox-esr.

Or not. This could also be caused by some upgraded build dependency.
Do you have the resources to attempt rebuilding 68.7 against current
unstable?

Mike

Bug#959506: git-annex: `git annex add` sometimes treats non-dotfiles in dotdirs as dotfiles

[Sean Whitton]

control: tag -1 + upstream moreinfo

Dear Marco,

On Sat 09 May 2020 at 12:39AM +02, Marco Ricci wrote:

> Granted. I did however submit to my distro's tracker first to eliminate
> the case of this being Debian's fault due to a distro-specific patch, as
> I know happens with some other packages. Sadly, I lack the technical
> knowledge to verify by myself whether this is indeed the case. I also
> assumed that if this turned out not to be a Debian-specific complaint,
> then someone would forward to or request resubmission on git-annex's
> tracker. I take it that I have permission (or encouragement, or
> whatever) to do so now.

The issue is not really actionable at the distro level -- we wouldn't
add a patch to change this behaviour.

So it sounds like the discussion should indeed be moved to the upstream
bug tracker.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#960348: Patch for /lib/systemd/system/logrotate.service

[Tilman Heinrich]

Shortly: Solution for preventing from errors by systemd
logrotate.service when running before local file systems are ready.

4a5
> After=local-fs.target

Bug#960350: prosody-modules: add mod_muc_moderation

[Martin]

Package: prosody-modules
Version: 0.0~hg20200423.0233da912ab6+dfsg-1
Severity: wishlist

This module implements XEP-0425: Message Moderation.
(Currently supported by the Converse.js client.)

Bug#960309: znc: Missing required dependency: openssl

[Savyasachee Jha]

Package: znc
Version: 1.7.2-3
Severity: normal

Znc cannot connect to ssl-enabled networks if the openssl binary is not present
on the system. It cannot verify their certificates. It requires that both
ca-certificates and openssl be present on the system. Granted, on most systems
it will be, but both openssl and ca-certificates ought to appear as either
requried or at least recommended dependencies for znc, because some very core
functionality does not work without them.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: 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 znc depends on:
pn  libboost-locale1.67.0  
ii  libc6  2.28-10
pn  libgcc-s1  
ii  libgcc11:8.3.0-6
ii  libicu63   63.1-6+deb10u1
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u3
ii  libstdc++6 8.3.0-6
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages znc recommends:
pn  znc-perl
pn  znc-python  
pn  znc-tcl 

znc suggests no packages.

Bug#960349: libmrpt-tfest-dev,libmrpt-bayes-dev: missing Breaks+Replaces: libmrpt-dev (<< 1:2)

[Andreas Beckmann]

Package: libmrpt-tfest-dev,libmrpt-bayes-dev
Version: 1:2.0.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', 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

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

...
  Selecting previously unselected package libmrpt-bayes-dev.
  Preparing to unpack .../23-libmrpt-bayes-dev_1%3a2.0.2-1_amd64.deb ...
  Unpacking libmrpt-bayes-dev (1:2.0.2-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-lpS9iV/23-libmrpt-bayes-dev_1%3a2.0.2-1_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/include/mrpt/bayes/include/mrpt/bayes/CKalmanFilterCapable.h', which is 
also in package libmrpt-dev 1:1.5.6-1+b1
...
  Selecting previously unselected package libmrpt-tfest-dev.
  Preparing to unpack .../27-libmrpt-tfest-dev_1%3a2.0.2-1_amd64.deb ...
  Unpacking libmrpt-tfest-dev (1:2.0.2-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-lpS9iV/27-libmrpt-tfest-dev_1%3a2.0.2-1_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/include/mrpt/tfest/include/mrpt/tfest/indiv-compat-decls.h', which is 
also in package libmrpt-dev 1:1.5.6-1+b1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-lpS9iV/23-libmrpt-bayes-dev_1%3a2.0.2-1_amd64.deb
   /tmp/apt-dpkg-install-lpS9iV/27-libmrpt-tfest-dev_1%3a2.0.2-1_amd64.deb


cheers,

Andreas


libmrpt-dev=1:1.5.6-1+b1_libmrpt-tfest-dev=1:2.0.2-1.log.gz
Description: application/gzip

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Tue, 12 May 2020 06:03:17 +0900 Mike Hommey wrote:

> On Mon, May 11, 2020 at 06:27:01PM +0200, Francesco Poli (wintermute) wrote:
> > Package: firefox-esr
> > Version: 68.8.0esr-1
> > Severity: important
> > 
> > Hello!
> > 
> > This morning I upgraded my Debian testing box, and firefox-esr
> > had the following upgrade:
> > 
> >   [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1
> 
> Did you try downgrading?

Hello Mike,
thanks for your followup.

Yes, I downgraded firefox-esr and the bug vanished.
This confirms that the issue is indeed caused by the new version of
firefox-esr.

I was going to add a comment to the bug report, just to let you know
about the downgrade test, but you were faster than me!  :-)


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


pgpdxNIxSwcHO.pgp
Description: PGP signature

Bug#960348: logrotate: Logrotate.service fails at boottime if dedicated /var is not ready

[Tilman Heinrich]

Package: logrotate
Version: 3.14.0-4
Severity: important
Tags: patch

Dear Maintainer,

the logrotate.service failed when started by the systemd under the following 
conditions:
 - There is no graphical target but the system runs to multi-user.target,
 - The system was not started for a few days,
 - The logrotate service was started at boot time, maybe triggered by the 
stand still period,
 - The /var directory is separated to a dedicated md device.

There was no error after manually starting the service at the command line 
when the system was up.

If you don't wish that users will be faced by error messages at boot time it 
would be help to complete the unit description in the file 
/lib/systemd/system/logrotate.service by simply add the following statement 
to the unit section: After=local-fs.target.

This statement is also missing in the unstable package 
logrotate_3.16.0-3_amd64.deb.

Best Regards
T. Heinrich

-- Package-specific info:
Contents of /etc/logrotate.d
total 28
-rw-r--r-- 1 root root 120 Apr 19  2019 alternatives
-rw-r--r-- 1 root root 173 May 28  2019 apt
-rw-r--r-- 1 root root 130 Aug 29  2018 btmp
-rw-r--r-- 1 root root 112 Apr 19  2019 dpkg
-rw-r--r-- 1 root root 501 Feb 26  2019 rsyslog
-rw-r--r-- 1 root root 340 Jul 24  2019 squid
-rw-r--r-- 1 root root 145 Feb 19  2018 wtmp


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

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

Versions of packages logrotate depends on:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1
ii  libacl1 2.2.53-4
ii  libc6   2.28-10
ii  libpopt01.16-12
ii  libselinux1 2.8-1+b1
ii  systemd-sysv241-7~deb10u4

Versions of packages logrotate recommends:
pn  bsd-mailx | mailx  

logrotate suggests no packages.

-- no debconf information

Bug#960230: thunderbird: Thunderbird doesn't run if DEBUG variable is exported

[Carles Pina i Estany]

Hi Carsten,

On May/11/2020, Carles Pina i Estany wrote:

> > To generic variable names are always problematic at some point, so your
> > suggestion to prefix all the DEBUG name is a thing that need to happen.
> > Would you be willing came up with a patch? If not I will try to work on this
> > later within the preparation for next ESR cycle in Debian.
> 
> I'm happy to provide a patch (probably today later or tomorrow evening).
> I didn't in case that someone else was working on it / something else.

I created a salsa.debian.org account and:

a) I was looking at the code and realised that some variables were
initialized to 0 probably for the same reason that the bug was found.
Initially I've done an unset, consistent with existing code: 
https://salsa.debian.org/carlespina/thunderbird/-/commit/eb0d71b9cdb386cd94dea9bd8acabd2374f13a97
 . If you prefer me prefixing that in TB_ or THUNDERBIRD_ let me know.

b) I got a bit carried away:
https://salsa.debian.org/carlespina/thunderbird/-/commits/thunderbird-launcher-variables/
with some small refactoring that you might or might not agree / minor
fixes or deleting code for commented out fixes.

I'm happy to change the name of the variables, but well, it was interesting.

Cheers,

-- 
Carles Pina i Estany

Bug#956260: [Debichem-devel] Bug#956260: Bug#956260: bkchem: should this package be removed?

[Moritz Mühlenhoff]

On Mon, May 11, 2020 at 10:51:47AM +0200, Michael Banck wrote:
> Hi,
> 
> On Sun, May 10, 2020 at 11:22:32AM +0200, Moritz Mühlenhoff wrote:
> > Let's go ahead with removal now? This is blocking progress on lower level
> > dependencies. 
> 
> What exactly is it blocking?

It blocks reverse deps from removing their Python 2 packages (or if
Py2-specific the package at large), which in turn block the removal
of other packages.

In the case of bkchem python-pil and python-pmw, which in turn block
the removal of python-tk.

Cheers,
Moritz

Bug#936206: binplist: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, May 11, 2020 at 08:55:52AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 08 May 2020, Moritz Mühlenhoff wrote:
> > > Your package either build-depends, depends on Python2, or uses Python2
> > > in the autopkg tests.  Please stop using Python2, and fix this issue
> > > by one of the following actions.
> > 
> > https://github.com/google/binplist/issues/6 is without any update since 
> > 2016 and there
> > are no reverse deps, let's remove?
> 
> No objection from me.

I've just filed an RM bug.

Cheers,
Moritz

Bug#960346: RM: binplist -- RoQA; Depends on Python 2, dead upstream, no reverse deps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove binplist. It depends on Python 2, is dead upstream and there are 
no
rev deps in the archive. Acked by Raphael and Hilko in #936206.

Cheers,
Moritz

Bug#960347: libsolv{,ext}-dev: missing (unversioned) Breaks+Replaces: libsolv{,ext}0-dev

[Andreas Beckmann]

Package: libsolv-dev,libsolvext-dev
Version: 0.7.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files 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...):

  Selecting previously unselected package libsolvext-dev:amd64.
  Preparing to unpack .../libsolvext-dev_0.7.11-1_amd64.deb ...
  Unpacking libsolvext-dev:amd64 (0.7.11-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libsolvext-dev_0.7.11-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/libsolvext.pc', 
which is also in package libsolvext0-dev:amd64 0.6.36-2
  Selecting previously unselected package libsolv-dev:amd64.
  Preparing to unpack .../libsolv-dev_0.7.11-1_amd64.deb ...
  Unpacking libsolv-dev:amd64 (0.7.11-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libsolv-dev_0.7.11-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/libsolv.pc', which 
is also in package libsolv0-dev:amd64 0.6.36-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libsolvext-dev_0.7.11-1_amd64.deb
   /var/cache/apt/archives/libsolv-dev_0.7.11-1_amd64.deb

Since the versioned -dev packages will go away, the B+R can be unversioned.


cheers,

Andreas


libsolv0-dev=0.6.36-2_libsolv-dev=0.7.11-1.log.gz
Description: application/gzip

Bug#960345: ITP: allelecount -- NGS copy number algorithms

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: allelecount -- NGS copy number algorithms
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: allelecount
  Version : 4.1.0
  Upstream Author : Genome Research Ltd
* URL : https://github.com/cancerit/alleleCount
* License : AGPL-3
  Programming Lang: C
  Description : NGS copy number algorithms
 Support code for NGS copy number algorithms. Takes a file of locations
 and a [cr|b]am file and generates a count of coverage of each allele
 [ACGT] at that location (given any filter settings).
 .
 The alleleCount package primarily exists to prevent code duplication
 between some other projects, specifically AscatNGS and Battenberg.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/allelecount

Bug#936206: binplist: Python2 removal in sid/bullseye

[Hilko Bengen]

* Moritz Mühlenhoff:

>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>
> https://github.com/google/binplist/issues/6 is without any update since 2016 
> and there
> are no reverse deps, let's remove?

Yes. The reverse-dependen for which I had originally packaged it is
gone.

Cheers,
-Hilko

Bug#960344: libkf5dav-dev,libkf5dav-data: missing Breaks+Replaces: libkpimkdav-{dev,data}

[Andreas Beckmann]

Package: libkf5dav-dev,libkf5dav-data
Version: 20.04.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' 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 .../10-libkf5dav-data_20.04.0-1_all.deb ...
  Unpacking libkf5dav-data (20.04.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-KCmgJU/10-libkf5dav-data_20.04.0-1_all.deb (--unpack):
   trying to overwrite '/usr/share/locale/ar/LC_MESSAGES/libkdav.mo', which is 
also in package libkpimkdav-data 19.08.3-1
...
  Preparing to unpack .../20-libkf5dav-dev_20.04.0-1_amd64.deb ...
  Unpacking libkf5dav-dev:amd64 (20.04.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-KCmgJU/20-libkf5dav-dev_20.04.0-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_kdav.pri', which is also in 
package libkpimkdav-dev:amd64 19.08.3-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-KCmgJU/10-libkf5dav-data_20.04.0-1_all.deb
   /tmp/apt-dpkg-install-KCmgJU/20-libkf5dav-dev_20.04.0-1_amd64.deb


cheers,

Andreas


libkpimkdav-dev=19.08.3-1_libkf5dav-dev=20.04.0-1.log.gz
Description: application/gzip

Bug#960282: [Pkg-zsh-devel] Bug#960282: Bug#960282: zsh: completion error with non exsiting files since deca7c928520fba5a73383f1cac0b3ace8e0e45d

[TS]

Hello Daniel,
Hello Axel,

>> _arguments:comparguments:393: too many arguments

> In version 5.8-4, line 393 of _arguments doesn't call
> comparguments.
>> after deleting $opt_args_use_NUL_separators from _arguments:
> You seem to be using _arguments from git HEAD with zsh 5.8-4.  > That
is not a supported use case.

Thats true. For 2 or 3 yrs i use debian Zsh with upstream completion
funcs from git. Had been working all this time w/o problems through all
this time so far.

>>> using _arguments from git HEAD with zsh 5.8-4 [...] is not a
>>> supported use case.
> 
> Is this something that might affect users when migrating from zsh 5.8
> to a potential 5.9, i.e. something we might need to put into NEWS.Debian?
> 
>> Citation: workers/37986.
> 
> Thanks! (see https://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=37986)
> 
> Ok, this reads more that it is cared about backwards-compatiblity for
> 3rd party completion, but not about backwards-compatiblity to older
> zsh release for our own completions inside the zsh source, right?

The point i took time to write this bugreport is, comparguments seems to
be more pigy about the count of arguments then i am.

If this changes with rebuild feel free to close this report.
I am not a great hacker at all, but this seem fishy at all if that == true.

Thank you for maintaing Zsh.



kind regards,

 Thilo

Bug#960342: obs-plugins: Please include v4lsink plugin for video loopback under linux

[Michael Gebetsroither]

Package: obs-plugins
Version: 25.0.3+dfsg1-2
Severity: wishlist

Dear Maintainer,

Please include the v4lsink plugin for video loopback under linux.

It would be awesome to have out-of-the box support for a greenscreen
working with a normal webcam and consumeable by the various video
conferencing software, eg. bigbluebutton or jitsy running in a browser.
(without needed expensive external hardware for framegrabbing).

With the v4l2sink obs module and the already included kernel module
v4l2loopback-dkms, this works on current debian testing without any
problems.

I tested it with both a logitech c930 and the internal webcam and after
building and installing the obs plugin manually it worked without
problems.

obs-v4l2sink plugin: https://github.com/CatxFish/obs-v4l2sink

also required is the v4l2loopback kernel module, but that's just a
apt install v4l2loopback-dkms away in debian testing.

greets,
gebi


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages obs-plugins depends on:
ii  libasound21.2.2-2.1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavdevice58 7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libc6 2.30-4
ii  libcurl3-gnutls   7.68.0-1
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200418-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjansson4   2.12-1
ii  libmbedcrypto32.16.5-1
ii  libmbedtls12  2.16.5-1
ii  libmbedx509-0 2.16.5-1
ii  libobs0   25.0.3+dfsg1-2
ii  libpulse0 13.0-5
ii  libqt5core5a  5.12.5+dfsg-10
ii  libqt5gui55.12.5+dfsg-10
ii  libqt5widgets55.12.5+dfsg-10
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libstdc++610-20200418-1
ii  libswscale5   7:4.2.2-1+b1
ii  libudev1  245.5-1
ii  libv4l-0  1.18.0-2
ii  libx11-6  2:1.6.9-2
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libxcb-randr0 1.14-2
ii  libxcb-shm0   1.14-2
ii  libxcb-xfixes01.14-2
ii  libxcb-xinerama0  1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxfixes31:5.0.3-2
ii  python3   3.8.2-3

Versions of packages obs-plugins recommends:
ii  vlc  3.0.9.2-1

obs-plugins suggests no packages.

-- no debconf information

Bug#960343: firefox: Google Hangouts and Google Meet not working in Firefox

[José Luis Segura Lucas]

Package: firefox
Version: 76.0-2
Severity: normal

Dear Maintainer,

I upgraded my Debian OS during the weekend. Today I found that I cannot use
Google Meet from Firefox nor Firefox ESR installation. It works normally with
other browsers (tested with Chromium and Google Chrome).

I tried with Google Hangouts too, and I found the same problem.

When I create or enter in a Google Meet/Hangout room, I can select which webcam
and audio devices I want to use, I can see my webcam in my own window, but I
cannot hear or see anybody else in the meeting, and they cannot see nor hear me
too.

I'm very sure that probably it is not a Firefox problem, but I don't know how
to start debugging this problem.

A bit of help for getting some more helpful information will be appreciated.

Thank you in advance




-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-7
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgcc-s1   10.1.0-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.20-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.52-1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10.1.0-1
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.9-2+b1
ii  libx11-xcb1 2:1.6.9-2+b1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-2
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Mon, May 11, 2020 at 06:27:01PM +0200, Francesco Poli (wintermute) wrote:
> Package: firefox-esr
> Version: 68.8.0esr-1
> Severity: important
> 
> Hello!
> 
> This morning I upgraded my Debian testing box, and firefox-esr
> had the following upgrade:
> 
>   [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1

Did you try downgrading?

Mike

Bug#960340: isospec: FTBFS on ppc64el

[Sebastian Ramacher]

On 2020-05-11 22:55:41 +0200, Sebastian Ramacher wrote:
> Source: isospec
> Version: 2.0.2+dfsg1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> isospec failed to build on ppc64el:
> https://buildd.debian.org/status/fetch.php?pkg=isospec=ppc64el=2.0.2%2Bdfsg1-1=1589192318=0

Looking at other build logs, isospec builds with -march=native
everywhere. This is a base line violation, so needs to be removed.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#954020: buster-pu: package zipios++/0.1.5.9+cvs.2007.04.28-10+deb10u1

[François Mazen]

Hello Georg,

thanks a lot for your help. The packaging repo is:
https://salsa.debian.org/mzf/zipios

the branch for this buster patch is "fix_CVE-2019-13453_for_buster":
https://salsa.debian.org/mzf/zipios/-/tree/fix_CVE-2019-13453_for_buster

the last commit is:
https://salsa.debian.org/mzf/zipios/-/commit/7bdc65a62cacea47e03c13e6d92157da3c11f6bd

I can upload the package to mentors.d.n if needed. Just let me know.

Best,
François

Bug#960340: isospec: FTBFS on ppc64el

[Sebastian Ramacher]

Source: isospec
Version: 2.0.2+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

isospec failed to build on ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=isospec=ppc64el=2.0.2%2Bdfsg1-1=1589192318=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#960341: swi-prolog-core,swi-prolog-core-packages: missing Breaks+Replaces: swi-prolog-nox (<< 8.1.30)

[Andreas Beckmann]

Package: swi-prolog-core,swi-prolog-core-packages
Version: 8.1.30+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' 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 .../swi-prolog-core_8.1.30+dfsg-1_amd64.deb ...
  Unpacking swi-prolog-core (8.1.30+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/swi-prolog-core_8.1.30+dfsg-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/swi-prolog/bin/swipl.home', which is also in 
package swi-prolog-nox 8.1.29+dfsg-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../swi-prolog-core-packages_8.1.30+dfsg-1_amd64.deb ...
  Unpacking swi-prolog-core-packages (8.1.30+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/swi-prolog-core-packages_8.1.30+dfsg-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/swi-prolog/bin/latex2html', which is also in 
package swi-prolog-nox 8.1.29+dfsg-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/swi-prolog-core_8.1.30+dfsg-1_amd64.deb
   /var/cache/apt/archives/swi-prolog-core-packages_8.1.30+dfsg-1_amd64.deb


cheers,

Andreas


swi-prolog-nox=8.1.29+dfsg-2_swi-prolog-core-packages=8.1.30+dfsg-1.log.gz
Description: application/gzip

Bug#959897: RFS: awf-gtk2/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK

[Adam Borowski]

On Wed, May 06, 2020 at 07:51:53PM +0200, Fabrice Creuzot wrote:
>  * Package name: awf-gtk2
>Version : 2.0.0-3

> Changes since the last upload:
> 
>* Initial debian package release (Closes: #959434)

Hi!
The package looks almost good to go:

* Debian revision: how come it's -3 on an initial upload?  Especially with
  nothing in the changelog?

  We don't bump a version just because you've tested it at home -- it often
  takes many, many test builds to get things right.  An exception is if a
  version of the package has been released to an audience, be they users of
  some Debian-based distribution, your team at works, etc -- having two
  different versions with the same number would give them a hardship.

* the real name (according to a Lintian override) is "A Widget Factory",
  yet you capitalize only the article.  For an English speaking person,
  that's for sure some common thing.  Could you please put it into title
  case (Ie, Starting Every Word with a Cap Letter)?

Both of these are common to either variant (gtk2 and gtk3).

Also: despite GTK2 being deprecated, having the gtk2 package would be great.
It already proven useful in finding out regressions in a theme I maintain
-- a bunch of functionality is wrong in gtk3, having both side-to-side
made that immediately visible.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#960314: Please add a python3-tifffile package

[Andreas Tille]

Hi Ole,

I'm currently so much involved into urgend COVID-19 packaging that I
would really love if you could add a team upload - or even add yourself
as Uploader.  Lots of packages who were maintained by Mathieu Malaterre
previously ended on my desk when he left and these are extremely far
from my actual work.  I'm just maintaining these to keep on supporting
our users.  If you have specific needs feel free to do whatever seems
sensible to you.

Sorry for beeing of less help here

  Andreas.

-- 
http://fam-tille.de

Bug#959027: swi-prolog-nox: compiler and runtime execution shipped in same package

[Ivan Shmakov]

> On 2020-05-04 14:54:15 +0500, Lev Lamberov wrote:

 > I can upload swi-prolog with these changes right after it is processed
 > in NEW.  Anyway I should add Breaks and Replaces to make updating from
 > older versions smooth.

While we’re at it, could you please consider also downgrading
swi-prolog-core-packages’ dependency on libjs-jquery to
Recommends:?  As far as I can tell, it’s only used by the
integrated HTTP server, and even then it’s only served to
clients, not actually executed by the Prolog system itself.

TIA.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Scott Kitterman]

On Monday, May 11, 2020 4:18:45 PM EDT Emmanuel Arias wrote:
> El lun., 11 de may. de 2020 a la(s) 17:10, Antoine Beaupré
> 
> (anar...@debian.org) escribió:
> > On 2020-05-11 14:53:29, Scott Kitterman wrote:
> > > On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote:
> > >> On 2020-05-11 15:18:53, Emmanuel Arias wrote:
> > >> > Hi,
> > >> > 
> > >> > The upstream and pristine-tar branches are not generated on salsa for
> > >> > any particular reason.?
> > >> 
> > >> I'm not sure what question you are asking here. This package doesn't
> > >> use
> > >> pristine-tar or upstream branches right now, if that's what you're
> > >> asking.
> > > 
> > > Which it should since part of the DPMT standard repository layout. 
> > > Please fix.> 
> > I just found the time to update half a dozen Debian packages last
> > night. I have no time for administrative details like this. I'm happy if
> > some other folks in the team have time for that and won't stand in their
> > way.
> > 
> > I just hope my contributions to the team are otherwise appreciated. That
> > package doesn't have pristine-tar and I don't plan to add it myself. If
> > that's a problem for the team, I'm happy to move it to collab-maint or
> > stop maintaining it.
> 
> Sorry, my intention was not introduce noises. I did just asking just for be
> sure if that package need help or not.  I will happy to add upstream and
> pristine-tar branches :)

Thank you.  Please do.

This is not just administrivia.  People who interact with the team 
repositories expect a certain layout and it causes confusion when it is not 
used.

When following the standard team processes (that we've all agreed to do), this 
amount of extra time it takes to do it correctly is virtually nil.

Scott K

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

Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5

[Uwe Kleine-König]

Control: forwarded -1 
https://lore.kernel.org/r/20200506144558.ga4...@taurus.defre.kleine-koenig.org

Hello,

On Tue, Apr 21, 2020 at 12:59:15PM +, Lennert Van Alboom wrote:
> ‐‐‐ Original Message ‐‐‐
> On Sunday, 19 April 2020 17:02, Lennert Van Alboom  
> wrote:
> > ‐‐‐ Original Message ‐‐‐
> > On Sunday, 19 April 2020 15:56, Uwe Kleine-König u...@kleine-koenig.org 
> > wrote:
> > > Do you have INTEL_IOMMU and INTEL_IOMMU_DEFAULT_ON included in your
> > > custom kernel? (If only the former: Do you suffer from the reported
> > > problem when you add intel_iommu=on to the kernel command line?)
> > 
> 
> > I started with the stock Debian 5.5-rc config, and just did make oldconfig 
> > from there on (don't like to stray too far from the official packages). So 
> > the option should be identical to the Debian kernels.
> > 
> 
> > $ grep INTEL_IOMMU Build/kernel/linux-5.7-rc1/.config
> > CONFIG_INTEL_IOMMU=y
> > CONFIG_INTEL_IOMMU_SVM=y
> > 
> 
> > CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
> > 
> 
> > =
> > 
> 
> > CONFIG_INTEL_IOMMU_FLOPPY_WA=y
> > CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON=y
> > 
> 
> > I don't reboot often, but I'll very likely run into the i915 hang above 
> > again soon, so I'll try the intel_iommu=on then.
> 
> 
> Verified: my 5.7.0-rc1 system with intel_iommu=on can suspend/resume without 
> issues.

I brought this problem to the attention of the x86 guys; see above URL
for the conversation.

Up to now no breaking insights.

@Lennert: Did you change your BIOS settings since the problem occured to
you? Lenny Szubowicz hinted it might be related to the TPM chip and
indeed switching it in the BIOS settings from 2.0 to 1.2 mode makes the
problem go away for me.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Emmanuel Arias]

El lun., 11 de may. de 2020 a la(s) 17:10, Antoine Beaupré
(anar...@debian.org) escribió:
>
> On 2020-05-11 14:53:29, Scott Kitterman wrote:
> > On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote:
> >> On 2020-05-11 15:18:53, Emmanuel Arias wrote:
> >> > Hi,
> >> >
> >> > The upstream and pristine-tar branches are not generated on salsa for
> >> > any particular reason.?
> >>
> >> I'm not sure what question you are asking here. This package doesn't use
> >> pristine-tar or upstream branches right now, if that's what you're
> >> asking.
> >
> > Which it should since part of the DPMT standard repository layout.  Please 
> > fix.
>
> I just found the time to update half a dozen Debian packages last
> night. I have no time for administrative details like this. I'm happy if
> some other folks in the team have time for that and won't stand in their
> way.
>
> I just hope my contributions to the team are otherwise appreciated. That
> package doesn't have pristine-tar and I don't plan to add it myself. If
> that's a problem for the team, I'm happy to move it to collab-maint or
> stop maintaining it.

Sorry, my intention was not introduce noises. I did just asking just for be
sure if that package need help or not.  I will happy to add upstream and
pristine-tar branches :)

Cheers,
Emmanuel
>
> A.
>
> --
> Man really attains the state of complete humanity when he produces,
> without being forced by physical need to sell himself as a commodity.
> - Ernesto "Che" Guevara

Bug#960333: hpanel FTCBFS: does not pass cross tools to make

[Helmut Grohne]

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

hpanel fails to cross build from source, because it does not pass cross
tools to make. A simple way to fix this is using dh_auto_build with the
makefile buildsystem. The makefile buildsystem needs to be explicitly
selected due to the presence of a configure script (which we don't want
to run here and which is automatically skipped by the makefile build
system). Please consider applying the attached patch.

Helmut
diff --minimal -Nru hpanel-0.3.2/debian/changelog hpanel-0.3.2/debian/changelog
--- hpanel-0.3.2/debian/changelog   2020-05-09 20:30:41.0 +0200
+++ hpanel-0.3.2/debian/changelog   2020-05-11 21:39:59.0 +0200
@@ -1,3 +1,10 @@
+hpanel (0.3.2-6) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make using the
+makefile build system. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 May 2020 21:39:59 +0200
+
 hpanel (0.3.2-5) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru hpanel-0.3.2/debian/rules hpanel-0.3.2/debian/rules
--- hpanel-0.3.2/debian/rules   2012-03-23 11:51:10.0 +0100
+++ hpanel-0.3.2/debian/rules   2020-05-11 21:39:58.0 +0200
@@ -33,17 +33,14 @@
 override_dh_installchangelogs:
dh_installchangelogs  $(CHANGELOG)
 
-override_dh_auto_configure:
-   # Skip this step
-
 override_dh_auto_build: man
-   $(MAKE) CFLAGS="$(CPPFLAGS) $(CFLAGS)" LDFLAGS="$(LDFLAGS)" hpanel
+   dh_auto_build -- CFLAGS="$(CPPFLAGS) $(CFLAGS)" LDFLAGS="$(LDFLAGS)" 
hpanel
 
 override_dh_auto_install:
# Disable. See debian/install
 
 %:
-   dh $@
+   dh $@ -Smakefile
 
 .PHONY: man get-changelog
 

Bug#960324: bgpdump: autopkgtest failure: testing issue-17.1346938280.gz..../test.sh: 27: ./bgpdump: not found

[Christoph Biedl]

Control: tags 960324 pending

Paul Gevers wrote...

> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?

Yeah, it's not that easy to get around the autopkgtest world. Noticed
the situation but did not bother to upload a fix immediately.

Christoph


signature.asc
Description: PGP signature

Bug#960334: prads FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: prads
Version: 0.3.3-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

prads fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
almost makes prads cross buildable. It fails running rst2man due to a
missing python3-docutils dependency. The attached patch fixes both the
ftcbfs and the ftbfs. Please consider applying it.

Helmut
diff --minimal -Nru prads-0.3.3/debian/changelog prads-0.3.3/debian/changelog
--- prads-0.3.3/debian/changelog2020-05-10 20:19:36.0 +0200
+++ prads-0.3.3/debian/changelog2020-05-11 21:57:15.0 +0200
@@ -1,3 +1,11 @@
+prads (0.3.3-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+  * Fix FTBFS: Missing Build-Depends: python3-docutils.
+
+ -- Helmut Grohne   Mon, 11 May 2020 21:57:15 +0200
+
 prads (0.3.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru prads-0.3.3/debian/control prads-0.3.3/debian/control
--- prads-0.3.3/debian/control  2020-05-10 20:19:29.0 +0200
+++ prads-0.3.3/debian/control  2020-05-11 21:57:15.0 +0200
@@ -9,6 +9,7 @@
  dh-systemd,
  libpcap-dev,
  libpcre3-dev,
+ python3-docutils,
 Standards-Version: 3.9.5
 Homepage: http://gamelinux.github.com/prads/
 Vcs-Git: git://github.com/gamelinux/prads.git
diff --minimal -Nru prads-0.3.3/debian/rules prads-0.3.3/debian/rules
--- prads-0.3.3/debian/rules2014-02-11 10:15:28.0 +0100
+++ prads-0.3.3/debian/rules2020-05-11 21:57:13.0 +0200
@@ -8,7 +8,7 @@
dh $@ --with=systemd
 
 override_dh_auto_build:
-   $(MAKE) CONFDIR=/etc/prads
+   dh_auto_build -- CONFDIR=/etc/prads
 
 override_dh_auto_install:
$(MAKE) PREFIX=/usr CONFDIR=/etc/prads DESTDIR=$(CURDIR)/debian/prads 
install

Bug#960332: aobook FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: aobook
Version: 1.0.3-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aobook fails to cross build from source, because configure.ac abuses
AC_CHECK_FILE to search for files (includes in this case) expected on
the build system while it is meant to search the host system. Please use
a simple test -f for build system checks. I'm attaching a patch for your
convenience.

Helmut
--- aobook-1.0.3.orig/configure.ac
+++ aobook-1.0.3/configure.ac
@@ -28,7 +28,7 @@
 	[AC_DEFINE([HAVE_PTHREAD_H], [1], [pthread.h])],
 	AC_MSG_ERROR(pthread.h not found))
 
-AC_CHECK_FILE("$freetype_dir/ft2build.h",,AC_MSG_ERROR([(freetype) ft2build.h not found]))
+AS_IF([test -f "$freetype_dir/ft2build.h"],,AC_MSG_ERROR([(freetype) ft2build.h not found]))
 AC_CHECK_HEADER([fontconfig/fontconfig.h],,AC_MSG_ERROR(fontconfig.h not found))
 AC_CHECK_HEADER([zlib.h],,AC_MSG_ERROR(zlib.h not found))
 AC_CHECK_HEADER([png.h],,AC_MSG_ERROR(png.h not found))

Bug#960330: libusbredirhost.so.1: undefined symbol: libusb_set_option

[Wojciech Nizinski]

Package: virt-viewer
Version: 7.0-2
Severity: important

I just installed virt-viewer package. Program cannot be executed because of:

virt-viewer: symbol lookup error: /usr/lib/x86_64-linux-
gnu/libusbredirhost.so.1: undefined symbol: libusb_set_option

I was tried latest version from experimental repository, but with the same
result.

Downgrading libusbredirhost1 to 0.7.1-1 solves the problem.



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

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

Versions of packages virt-viewer depends on:
ii  libatk1.0-0 2.36.0-2~bpo10+1
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgovirt2  0.3.4-3.1
ii  libgtk-3-0  3.24.5-1
ii  libgtk-vnc-2.0-00.9.0-1.1
ii  libgvnc-1.0-0   0.9.0-1.1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libpangocairo-1.0-0 1.42.4-8~deb10u1
ii  librest-0.7-0   0.8.1-1
ii  libsoup2.4-12.64.2-2
ii  libspice-client-glib-2.0-8  0.35-2
ii  libspice-client-gtk-3.0-5   0.35-2
ii  libvirt-glib-1.0-0  1.0.0-1
ii  libvirt05.0.0-4+deb10u1
ii  libxml2 2.9.4+dfsg1-7+b3

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.195-2
ii  netcat-traditional [netcat]  1.10-41.1

-- debconf-show failed

Bug#843982: Still having this issue

[Anton Zinoviev]

On Mon, May 11, 2020 at 12:44:42PM -0300, Nelson A. de Oliveira wrote:
> 
> Today after upgrading from 4.40-2 to 4.48-1 I had this issue one more
> time (where I was unable to open any terminal; message was "urxvt:
> unable to load base fontset, please specify a valid one using -fn,
> aborting.")
> 
> I had to manually run "xset fp rehash" again.
 
The command xset has to be executed _within_ the X session of the current 
user.  On the other hand the upgrade of the package can happen anywhere, 
for example in the text console or in a X terminal but as root user 
without the rights to execute X programs.  Therefore, the upgrading 
packages (including xfonts-terminus) are not always allowed to execute X 
commands.

> Now I am unsure if "xset fp rehash" needs to be called in some other
> step while upgrading/installing xfonts-terminus or if there is another
> kind of issue somewhere else.

I am unsure too.  It would be best if X autodetects that the fonts have 
changed and runs this command automatically.

Anton Zinoviev

Bug#776736: Drogi przyjacielu,

[Calhun Delph]

*Drogi  przyjacielu, Wysłałem ci ten list wcześniej, ale nie jestem pewien,
czy go dostałeś, ponieważ nie otrzymałem od ciebie wiadomości, i dlatego
piszę do ciebie ponownie, jestem adwokatem Calhun Delph, składam ci tę
ofertę w związku ze śmiercią mojego zmarłego klienta, który był moim
klientem przed śmiercią, żyjąc ogromną sumą pieniędzy, Dziewięć milionów
siedemset trzydzieści pięć tysięcy dolarów (9 ,735,000.00 dolarów) w banku,
po nieudanych próbach znalezienia tam związku, Postanowiłem się z tobą
skontaktować, ponieważ masz takie samo nazwisko jak mój zmarły klient i
chcę, abyś pomógł mi stać się najbliższym krewnym w banku, aby pieniądze
trafiły na twoje konto w kraju. Zapewniam, że nie wiąże się to z żadną
szkodą, ponieważ zapewnię wszystkie dokumenty potrzebne do wykonania kopii
zapasowej. Może to zabrzmi dla ciebie jak żart, ale obiecuję udowodnić, że
się mylisz pod koniec tej transakcji. proszę o kontakt w celu uzyskania
dodatkowych informacji. pozdrowienia Barrister Calhun Delph.*

Bug#917985: OpenFOAM should not build (nor skip) dummy libraries

[Mark Olesen]

The "dummy" library files are a useful part of the OpenFOAM build 
process. They are essentially stub libraries that can act as a failsafe 
for library interfaces that are unsupported or not available on the 
system. Additionally, the dummy Pstream is an extremely useful MPI stub. 
It obviously cannot be used for parallel calculations, but does help 
solve circular linker dependencies for the gold linker, some clang 
linkers and the mingw linker.


I think that the main issue is simply messiness if these are installed 
into system locations. The merge request


https://salsa.debian.org/science-team/openfoam/-/merge_requests/4

should solve these concerns.

Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Antoine Beaupré]

On 2020-05-11 14:53:29, Scott Kitterman wrote:
> On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote:
>> On 2020-05-11 15:18:53, Emmanuel Arias wrote:
>> > Hi,
>> > 
>> > The upstream and pristine-tar branches are not generated on salsa for
>> > any particular reason.?
>> 
>> I'm not sure what question you are asking here. This package doesn't use
>> pristine-tar or upstream branches right now, if that's what you're
>> asking.
>
> Which it should since part of the DPMT standard repository layout.  Please 
> fix.

I just found the time to update half a dozen Debian packages last
night. I have no time for administrative details like this. I'm happy if
some other folks in the team have time for that and won't stand in their
way.

I just hope my contributions to the team are otherwise appreciated. That
package doesn't have pristine-tar and I don't plan to add it myself. If
that's a problem for the team, I'm happy to move it to collab-maint or
stop maintaining it.

A.

-- 
Man really attains the state of complete humanity when he produces,
without being forced by physical need to sell himself as a commodity.
- Ernesto "Che" Guevara

Bug#954070: let's get this into buster

[Hans-Christoph Steiner]

Control: severity -1 serious

Bug#960331: aoflagger: libboost-signals-dev will be removed with boost 1.71

[Sebastian Ramacher]

Source: aoflagger
Version: 2.15.0-1
Severity: important
User: team+bo...@tracker.debian.org
Usertags: boost1.71

aoflagger has a build-dependency on liboosost-signals-dev. Once
boost switches to 1.71, the package will no longer be available. Simply
remove the dependency will be enough

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature