Bug#959821: linux-image-5.6.0-1-amd64: Linux 5.6.0 kernel breaks hostapd 5 GHz AP mode on Atheros radios

[Michael Berg]

I found the associated ath10k mailing list thread
https://www.mail-archive.com/ath10k@lists.infradead.org/msg12068.html

In that thread, Wen Gong (author of the changes in git commit
2dc016599cfa9672a147528ca26d70c3654a5423)
https://github.com/torvalds/linux/commit/2dc016599cfa9672a147528ca26d70c3654a5423
replied that the commit should be reverted.

Bug#937413: pycryptopp: Python2 removal in sid/bullseye

[Vasudev Kamath]

Hi Moritz,

Moritz Mühlenhoff  writes:
>
> Hi Vasudev,
>
> https://github.com/tahoe-lafs/pycryptopp/issues/36#issuecomment-504130020 
> states:
>
> | The Tahoe-LAFS project has decided it is not interested in porting
> | pycryptopp to Python 3. Instead, Tahoe-LAFS is switching to the
> | "cryptography" library.
> | 
> | I don't have any problem with anyone else taking on this porting effort
> | but I'm closing this to reflect the fact that the maintainers have
> | no plans of taking this on.
>
> Given that the now removed tahoe-lafs was the only reverse dependency,
> let's also remove pycryptopp?

Right upstream stopped using it a while ago but I could not get that
change in tahoe-lafs during that time due to dependency on
magic-wormhole lib which was py3 only and could not work with
tahoe-lafs in archive.

I missed  this let me file a bug to get this as well removed from the
archive. Thanks for bringing this up.

Cheers,
Vasudev

Bug#959844: RM: pycryptopp -- ROM; upstream no longer has intent to support python 3

[Vasudev Kamath]

Package: ftp.debian.org
Severity: normal

As mentioned in [1] upstream has moved from pycryptopp to cryptography
library for tahoe-lafs and tahoe was the only dependency using this
package. Since there is no intent by upstream to provide py3 support for
this library I'm requesting its removal from archive.


[1] https://github.com/tahoe-lafs/pycryptopp/issues/36#issuecomment-504130020

Cheers,
Vasudev

Bug#958512: libwoodstox-java: new upstream version available (#958512)

[tony mancill]

Hi Alex,

On Tue, May 05, 2020 at 10:04:30AM +0200, Alexandre Rossi wrote:
> I managed to get the latest upstream version to build. Same result with
> ratt:
> 
> (snip)
> 
> Anyway my work is there:
> https://salsa.debian.org/java-team/libwoodstox-java/-/merge_requests/1

I merged your PR on Salsa and your upstream and pristine-tar branches
from your fork into the java-team/libwoodstox-java repo and have
uploaded the package.

Thank you for your contribution to Debian!

Cheers,
tony


signature.asc
Description: PGP signature

Bug#959843: gajim: Fails to start video sessions

[Bruno Kleinert]

Package: gajim
Version: 1.1.3-2
Severity: normal

Hi,

gajim fails to start video sessions to contacts (Audio sessions work, though.).
It displays a window with the following message when I attempt to start a video
call:

 8< 
## Versions
- OS: Debian GNU/Linux bullseye/sid
- GTK+ Version: 3.24.18
- PyGObject Version: 3.36.0
- python-nbxmpp Version: 0.6.10
- Gajim Version: 1.1.3

## Traceback
```
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gajim/chat_control.py", line 367, in
_on_video
self.on_jingle_button_toggled(state, 'video')
  File "/usr/lib/python3/dist-packages/gajim/chat_control.py", line 766, in
on_jingle_button_toggled
out_xid = out_da.get_window().get_xid()
AttributeError: 'GdkWaylandWindow' object has no attribute 'get_xid'

```
## Steps to reproduce the problem
...
 >8 

To reproduce I set up two Debian (sid/unstable) systems running GNOME 3
desktops and gajim. Each gajim instance is connected to a different XMPP
account and both accounts have each other in the contact list. Open a private
conversation in one of the gajim instances and select from the menu at the
bottom right 'Video Session'. A video call does not start, but gajim displays a
new window with the above error message.

Cheers,
Bruno



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

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

Versions of packages gajim depends on:
ii  gir1.2-gtk-3.0   3.24.18-1
ii  python3  3.8.2-3
ii  python3-cssutils 1.0.2-3
ii  python3-gi   3.36.0-3
ii  python3-gi-cairo 3.36.0-3
ii  python3-idna 2.9-1
ii  python3-keyring  18.0.1-2
ii  python3-nbxmpp   0.6.10-1.1
ii  python3-openssl  19.1.0-2
ii  python3-precis-i18n  1.0.0-1

Versions of packages gajim recommends:
ii  aspell-de [aspell-dictionary]  20161207-7
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  ca-certificates20190110
ii  dbus   1.12.16-2
ii  fonts-noto-color-emoji 0~20200408-1
ii  gajim-omemo2.6.30-1
ii  gajim-pgp  1.2.24-1
ii  gir1.2-farstream-0.2   0.2.8-5
ii  gir1.2-geoclue-2.0 2.5.6-1
ii  gir1.2-gspell-11.8.3-1
ii  gir1.2-gst-plugins-base-1.01.16.2-4
ii  gir1.2-gstreamer-1.0   1.16.2-2
ii  gir1.2-gupnpigd-1.00.2.5-5
ii  gir1.2-secret-10.20.3-1
ii  gnome-shell [notification-daemon]  3.36.2-1
ii  gstreamer1.0-plugins-ugly  1.16.2-2+b1
ii  notification-daemon3.20.0-4
ii  pulseaudio-utils   13.0-5
ii  python3-crypto 2.6.1-13.1+b1
ii  python3-dbus   1.2.16-2
ii  python3-gnupg  0.4.6-1
ii  python3-pil7.0.0-4+b1
ii  sox14.4.2+git20190427-2

Versions of packages gajim suggests:
ii  avahi-daemon  0.7-5
ii  libxss1   1:1.2.3-1
ii  nautilus-sendto   3.8.6-3
pn  python3-kerberos  
ii  python3-pycurl7.43.0.2-3+b1

-- no debconf information

Bug#959842: tweeper: warnings with Facebook: Attribute data-referrer redefined in Entity

[Paul Wise]

Package: tweeper
Version: 1.4.1-1
Severity: normal
Usertags: warnings

When I run tweeper against Facebook, I get a number of warnings:

$ tweeper https://www.facebook.com/facebook
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID login_form already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID email already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID pass already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID loginbutton already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID lgnjs already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID locale already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID prefill_contact_point already defined in Entity, 
line 22 in /usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID prefill_source already defined in Entity, line 22 
in /usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 513: ID prefill_type already defined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257
PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 in 
/usr/share/php/tweeper/src/Tweeper.php on line 257

https://facebook.com;>
  
Tweeper
Facebook - Home | Facebook
https://www.facebook.com/facebook/


  Facebook - Home | Facebook
  https://www.facebook.com/facebook/
  
https://scontent-syd2-1.xx.fbcdn.net/v/t1.0-1/p200x200/87284588_124830725745195_9124219877853233152_n.png?_nc_cat=1_nc_sid=dbb9e7_nc_ohc=3tjbRDJdk0sAX8fvvm0_nc_ht=scontent-syd2-1.xxoh=aeac13e958ded89318cbde3c630294ecoe=5ED6584F

  


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 

Bug#737658: some notes on util-linux takeover of eject

[atzlinux 肖盛文]

在 2020/5/6 上午3:49, Chris Hofstaedtler 写道:
[...]
> util-linux would grow a new eject binary package (to avoid growing
> the essential util-linux binary package).
> I think util-linux (actually the new eject binary package) can get a
> NEWS.Debian entry that lists alternative options for volname. Users
> would need to modify their scripts manually. If users have
> apt-listchanges installed, they will be informed at upgrade time.

For example:

/volname debian-10.3.0-amd64-DVD-1.iso//
/

/Debian 10.3.0 amd64 1/

The volname is easy to use,only need one [] parameter.

reserve the file /usr/bin/volname,use the shell substitute like:

blkid -s LABEL $1

Is this acceptable?

If we do this,when the end user  upgrade to Debian 11,It will become
more smoothness.

>
> Indeed. Well, if we fix #787425 it doesn't need to 
>
> We can fix dkopp in Debian.
>
> I think we need one for /usr/bin/eject - that is "easy enough". We
> have done this before for other packages / binaries.
> For /usr/bin/volname and /usr/lib/eject/dmcrypt-get-device I would
> opt for the NEWS.Debian solution.
>
> Chris

The author of dmcrypt-get-device is mp...@debian.org,he also is a DD.

If you have any suggestion,welcome to tell us.


The present eject package come alone with Debian for  so many years.

With the high popcon,It's quality,stability,security,compatibility had
already verified on Debian by many people.

I hope the eject come from util-linux do better.


The plan of "util-linux takeover of eject" start at many years ago,let
us continuous.


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



signature.asc
Description: OpenPGP digital signature

Bug#959474: Follow-up fix for wml in Debian Stable?

[Boyuan Yang]

Hi Axel,

I just tested the new wml 2.12.2~ds1-3 on Chinese translations for website
(webwml). It looks like the previous bug has been properly fixed.

Since the webmaster team is trying to upgrade the machine from Debian 9 to
Debian 10, it should be better if we have this fix pushed into stable soon.
Can you make a stable update for package wml with this fix?

-- 
Thanks,
Boyuan Yang


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

Bug#959840: dbus-daemon: random crash (SIGABRT)

[Paul Wise]

Package: dbus
Version: 1.12.16-2
Severity: normal
File: /usr/bin/dbus-daemon
Usertags: crash

The last few days I have been getting dbus-daemon crashing randomly
with SIGABRT. I don't know how to reproduce this, so if the below
backtrace isn't useful, please close this bug.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply 
all bt full' --core 
/var/crash/1000/490277-1000-1000-6-1588644032-chianamo--usr-bin-dbus-daemon.core
 /usr/bin/dbus-daemon
[New LWP 490277]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 
--print-address 7 --ses'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f1d488a455b in __GI_abort () at abort.c:79
#2  0x7f1d485d17ea in log_assert_failed_realm (realm=, 
text=0x7f1d485fa7be "fclose_nointr(f) != -EBADF", file=0x7f1d485fa3e9 
"src/basic/fd-util.c", line=121, func=0x7f1d485faff8 
<__PRETTY_FUNCTION__.10669> "safe_fclose") at ../src/basic/log.c:809
#3  0x7f1d485f0c79 in safe_fclose (f=) at 
../src/basic/fd-util.c:121
#4  safe_fclose (f=0x55c3577d4610) at ../src/basic/fd-util.c:114
#5  0x7f1d485db359 in fclosep (f=) at 
../src/basic/fd-util.h:41
#6  json_variant_format (ret=, flags=(unknown: 0), 
v=) at ../src/shared/json.c:1732
#7  varlink_enqueue_json (v=0x55c3577d34e0, m=) at 
../src/shared/varlink.c:1233
#8  0x7f1d485e08f6 in varlink_observe (parameters=, 
method=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", 
v=0x55c3577d34e0) at ../src/shared/varlink.c:1404
#9  userdb_connect (iterator=iterator@entry=0x55c3577c2a70, 
path=path@entry=0x55c3577cb210 "/run/systemd/userdb/io.systemd.DynamicUser", 
method=method@entry=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", 
more=more@entry=true, query=) at ../src/shared/userdb.c:356
#10 0x7f1d485e6a5e in userdb_start_query (iterator=0x55c3577c2a70, 
method=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", more=true, 
query=0x55c3577cb250, flags=USERDB_AVOID_NSS) at ../src/shared/userdb.c:469
#11 0x7f1d485f29d5 in membershipdb_by_user (ret=, 
flags=, name=0x55c3577ca660 "pabs") at ../src/shared/userdb.c:997
#12 _nss_systemd_initgroups_dyn (user_name=user_name@entry=0x55c3577ca660 
"pabs", gid=gid@entry=1000, start=start@entry=0x7fffd3dcba20, 
size=size@entry=0x7fffd3dcba78, groupsp=groupsp@entry=0x7fffd3dcba80, 
limit=limit@entry=-1, errnop=0x7f1d4864d6a0) at 
../src/nss-systemd/nss-systemd.c:561
#13 0x7f1d48946056 in internal_getgrouplist (user=user@entry=0x55c3577ca660 
"pabs", group=group@entry=1000, size=size@entry=0x7fffd3dcba78, 
groupsp=groupsp@entry=0x7fffd3dcba80, limit=limit@entry=-1) at initgroups.c:111
#14 0x7f1d489462b9 in getgrouplist (user=user@entry=0x55c3577ca660 "pabs", 
group=group@entry=1000, groups=groups@entry=0x55c3577ca6a0, 
ngroups=ngroups@entry=0x7fffd3dcbaf0) at initgroups.c:169
#15 0x7f1d48be7eae in fill_user_info (info=info@entry=0x55c3577c8120, 
uid=uid@entry=1000, username=username@entry=0x0, 
error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-sysdeps-unix.c:2548
#16 0x7f1d48be808a in _dbus_user_info_fill_uid 
(info=info@entry=0x55c3577c8120, uid=uid@entry=1000, 
error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-sysdeps-unix.c:2672
#17 0x7f1d48beba4a in _dbus_user_database_lookup (db=0x55c3577c7e30, 
uid=, username=username@entry=0x0, 
error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-userdb.c:176
#18 0x7f1d48bebc8b in _dbus_user_database_get_uid (db=, 
uid=, info=info@entry=0x7fffd3dcbbd8, 
error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-userdb.c:672
#19 0x7f1d48bebcfa in init_system_db () at ../../../dbus/dbus-userdb.c:247
#20 0x7f1d48bebefd in init_system_db () at ../../../dbus/dbus-userdb.c:408
#21 _dbus_homedir_from_current_process (homedir=homedir@entry=0x7fffd3dcbc48) 
at ../../../dbus/dbus-userdb.c:400
#22 0x55c356c24aea in _dbus_get_standard_session_servicedirs 
(dirs=dirs@entry=0x7fffd3dcbcd8) at ../../../dbus/dbus-sysdeps-util-unix.c:1403
#23 0x55c356c10ca2 in start_busconfig_child (error=0x7fffd3dcc280, 
attribute_values=0x7fffd3dcc280, attribute_names=0x7fffd3dcbce0, 
element_name=0x55c3577c786c "standard_session_servicedirs", 
parser=0x55c3577c38c0) at ../../../bus/config-parser.c:935
#24 bus_config_parser_start_element (parser=0x55c3577c38c0, 
element_name=element_name@entry=0x55c3577c786c "standard_session_servicedirs", 
attribute_names=attribute_names@entry=0x55c3577c7d40, 
attribute_values=attribute_values@entry=0x55c3577c3bc0, error=0x7fffd3dcc280) 
at ../../../bus/config-parser.c:2048
#25 0x55c356c0e2b9 in expat_StartElementHandler (atts=0x55c3577c34f0, 

Bug#959839: RFP: javax-annotation-java -- Annotations for common semantic concepts in Java

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: javax-annotation-java
  Version : 1.3.2
  Upstream Author : Oracle
* URL : https://github.com/javaee/javax.annotation
* License : CDDL 1.1, GPL 2 w/ classpath exception
  Programming Lang: Java
  Description : Annotations for common semantic concepts in Java

It was envisioned that various JSRs would use annotations to enable a
declarative style of programming. It would be especially valuable to have
consistency within the Java EE component JSRs, but it is also valuable to
allow consistency between Java EE and Java SE.
.
This standalone release of Java(TM) Common Annotations uses a Java Platform
Module System "automatic" module name of java.annotation, to match the module
name used in JDK 9. A future version will include full module metadata.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#954444: neomutt: New upstream release (2020-05-01)

[наб]

Control: retitle -1 neomutt: New upstream release (2020-05-01)

Hi!

I've mailed the maintainer the patches and a pullable repository
for the 20200313 update shortly after its release (message attached),
and haven't heard back from them.

In the mean-time I've been maintaining my own package at that same URL
 ‒
based on the latest Salsa commit.

By happy coincidence, the packaging for 2020-05-01 was just about done
when I happened upon this report, and so here we are;
building it should be as straightforward as it gets.

Best,
наб
--- Begin Message ---
Dear Maintainer,

Enclosed are the patches I compiled for updating the neomutt package to
version 20200313, based on an uscan import on top of Salsa HEAD
(ea865abd9dff54a3d7a57812fabe13fc5b38395f),
in hopes of easing your work on this.

The patches are as follows:
1. Rebases patches and drops the patch picked from upstream,
   as it's present in this release;
2. Enables the new header cache compression feature with zlib;
3. Adds a build-dep on libzstd-dev and enables that same feature with
   zstd; this patch can be safely dropped if you'd prefer not to support
   zstd;
4. Cherry-picks the fix for upstream issue
   
   (upstream commit a7f602f120788bb8501cba46e9de6cf9de35a742).

Should you prefer to receive these patches another way I'm of course
more than happy to do so;
they can also be found on the for-maintainer branch of
.

Best regards,
nabijaczleweli
From 980770162bbb2013fdeaa9e457d685f681acc354 Mon Sep 17 00:00:00 2001
From: nabijaczleweli 
Date: Mon, 16 Mar 2020 04:07:42 +0100
Subject: [PATCH 1/4] Rebase patches, dropping merged upstream patch

---
 .../document_debian_defaults.patch|  28 +-
 .../patches/debian-specific/neomuttrc.patch   |   9 +-
 .../debian-specific/use_usr_bin_editor.patch  |  20 +-
 debian/patches/misc/smime.rc.patch|  10 +-
 debian/patches/series |   1 -
 ...01-fix-build-tests-for-32-bit-arches.patch | 254 --
 6 files changed, 37 insertions(+), 285 deletions(-)
 delete mode 100644 debian/patches/upstream/0001-fix-build-tests-for-32-bit-arches.patch

diff --git a/debian/patches/debian-specific/document_debian_defaults.patch b/debian/patches/debian-specific/document_debian_defaults.patch
index 325d85810..fe3500902 100644
--- a/debian/patches/debian-specific/document_debian_defaults.patch
+++ b/debian/patches/debian-specific/document_debian_defaults.patch
@@ -5,12 +5,14 @@ Subject: document_debian_defaults
 Some customization of the option which are straying
 from the default only on Debian systems.
 ---
- init.h | 22 ++
- 1 file changed, 22 insertions(+)
+ mutt_config.c | 19 +++
+ 1 file changed, 19 insertions(+)
 
 a/init.h
-+++ b/init.h
-@@ -471,6 +471,9 @@
+diff --git a/mutt_config.c b/mutt_config.c
+index c568f93..4b42da9 100644
+--- a/mutt_config.c
 b/mutt_config.c
+@@ -469,6 +469,9 @@ struct ConfigDef MuttVars[] = {
** .pp
** When this variable is \fIset\fP, NeoMutt will include Delivered-To headers when
** bouncing messages.  Postfix users may wish to \fIunset\fP this variable.
@@ -20,7 +22,7 @@ from the default only on Debian systems.
*/
{ "braille_friendly", DT_BOOL, _BrailleFriendly, false },
/*
-@@ -1568,6 +1571,9 @@
+@@ -1603,6 +1606,9 @@ struct ConfigDef MuttVars[] = {
** Optionally, NeoMutt can be compiled with a fixed domain name.
** .pp
** Also see $$use_domain and $$hidden_host.
@@ -30,7 +32,7 @@ from the default only on Debian systems.
*/
  #ifdef HAVE_LIBIDN
{ "idn_decode", DT_BOOL|R_MENU, _IdnDecode, true },
-@@ -2291,6 +2297,9 @@
+@@ -2338,6 +2344,9 @@ struct ConfigDef MuttVars[] = {
** system.  It is used with various sets of parameters to gather the
** list of known remailers, and to finally send a message through the
** mixmaster chain.
@@ -40,7 +42,7 @@ from the default only on Debian systems.
*/
  #endif
{ "move", DT_QUAD, _Move, MUTT_NO },
-@@ -4042,6 +4051,10 @@
+@@ -4096,6 +4105,10 @@ struct ConfigDef MuttVars[] = {
** This is a format string, see the $$smime_decrypt_command command for
** possible \fCprintf(3)\fP-like sequences.
** (S/MIME only)
@@ -51,7 +53,7 @@ from the default only on Debian systems.
*/
{ "smime_get_signer_cert_command", DT_STRING|DT_COMMAND, _SmimeGetSignerCertCommand, 0 },
/*
-@@ -4335,6 +4348,9 @@
+@@ -4398,6 +4411,9 @@ struct ConfigDef MuttVars[] = {
** .ts
** set ssl_ca_certificates_file=/etc/ssl/certs/ca-certificates.crt
** .te
@@ -61,10 +63,10 @@ from the default only on Debian systems.
*/
  #endif /* USE_SSL_GNUTLS */
{ "ssl_ciphers", DT_STRING, _SslCiphers, 0 },
-@@ -4877,6 +4893,9 @@
-   ** is set to deliver directly via SMTP (see $$smtp_url), this
-   ** option does nothing: NeoMutt will never write out the "Bcc:" 

Bug#959838: RFP: opencensus-java -- Stats collection and distributed tracing framework

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: opencensus-java
  Version : 0.26.0
  Upstream Author : Google Inc.
* URL : https://github.com/census-instrumentation/opencensus-java
* License : Apache 2
  Programming Lang: Java
  Description : Stats collection and distributed tracing framework

Toolkit for collecting application performance and behavior data. It currently
includes 3 APIs: stats, tracing, and tags.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959837: RFP: grpc-java -- Java gRPC implementation, HTTP/2 based RPC

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: grpc-java
  Version : 1.29.0
  Upstream Author : Google Inc.
* URL : https://github.com/grpc/grpc-java
* License : Apache 2
  Programming Lang: Java
  Description : Java gRPC implementation, HTTP/2 based RPC

gRPC-Java works with JDK 7. gRPC-Java clients are supported on Android API
levels 14 and up (Ice Cream Sandwich and later).

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959836: RFP: google-flogger-java -- Fluent Logging API for Java

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: google-flogger-java
  Version : 0.5.1
  Upstream Author : Google Inc.
* URL : https://github.com/google/flogger
* License : Apache 2
  Programming Lang: Java
  Description : Fluent Logging API for Java

Many benefits over existing logging APIs including more self-documenting log
statements and additional features that help you manage your logging better.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959835: RFP: error-prone-java -- Catch common Java mistakes as compile-time errors

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: error-prone-java
  Version : 2.3.4
  Upstream Author : Google Inc.
* URL : https://github.com/google/error-prone
* License : Apache 2
  Programming Lang: Java
  Description : Catch common Java mistakes as compile-time errors

Static analysis tool for Java that catches common programming mistakes at
compile-time.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959834: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: diffutils-java
  Version : 1.3.0
  Upstream Author : Dmitry Naumenko 
* URL : 
https://repo1.maven.org/maven2/com/googlecode/java-diff-utils/diffutils/1.3.0/diffutils-1.3.0-sources.jar
* License : Apache 1.1
  Programming Lang: Java
  Description : Implementation of general operations with diff files

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959833: spacenavd: Please upgrade to spacenavd 0.7.1 which was released Feb 7 2020

[waxhead]

Package: spacenavd
Version: 0.6-1.1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?

 A newer version exists outside the Debian repos

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

 I read the changelog for spacenavd 0.7 , it got some improvements that 
would be nice to have

   * What was the outcome of this action?

 I am now wishing spacenavd 0.7 was in debian

   * What outcome did you expect instead?

 That spacenavd 0.7 get pulled into the debian repos

*** End of the template - remove these template lines ***


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

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

Versions of packages spacenavd depends on:
ii  libc6 2.30-4
ii  libx11-6  2:1.6.9-2+b1

spacenavd recommends no packages.

spacenavd suggests no packages.

-- no debconf information

Bug#959832: RFP: checker-framework-java -- Framework that enhances Java’s type system to make it more powerful and useful

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: checker-framework-java
  Version : 1.8.0
  Upstream Author : Checker Framework developers
* URL : https://github.com/typetools/checker-framework
* License : GPL2 w/ classpath exception, MIT, and (LGPL or Apache)
  Programming Lang: Java
  Description : Framework that makes Java’s type system more powerful and 
useful

A "checker" is a tool that warns you about certain errors or gives you a
guarantee that those errors do not occur. The Checker Framework comes with
checkers for 24 specific types of errors.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959831: RFP: google-auto-java -- Collection of source code generators for Java.

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: google-auto-java
  Version : 1.0/1.0/1.7.1/0.10
  Upstream Author : Google Inc.
* URL : https://github.com/google/auto/
* License : Apache 2.0
  Programming Lang: Java
  Description : Collection of source code generators for Java.

Java is full of code that is mechanical, repetitive, typically untested, and
sometimes the source of subtle bugs. Sounds like a job for robots! The Auto
subprojects are a collection of code generators that automate those types of
tasks. They create the code you would have written, but without the bugs. Save
time. Save code. Save sanity.

**

It's likely that this would be better packaged as 4 distinct packages:
google-auto-factory-java, google-auto-service-java, google-auto-value-java,
and google-common-java. That decision is left to the adopter.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959830: RFP: google-auth-java -- Open source authentication client library for Java

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: google-auth-java
  Version : 0.20.0
  Upstream Author : Google Inc.
* URL : https://github.com/googleapis/google-auth-library-java
* License : BSD-3-Clause
  Programming Lang: Java
  Description : Open source authentication client library for Java

This project consists of 3 artifacts. google-auth-library-credentials contains
base classes and interfaces for Google credentials.
google-auth-library-appengine contains App Engine credentials. This artifact
depends on the App Engine SDK. google-auth-library-oauth2-http contains a wide
variety of credentials as well as utility methods to create them and to get
Application Default Credentials.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

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

[Dmitry Smirnov]

On Wednesday, 6 May 2020 8:28:09 AM AEST Ansgar wrote:
> The last upload adds `Provides: systemd`, but `systemctl` obviously
> doesn't provide the same (or similar) functionality as the `systemd`
> package.

It does provide similar functionality under certain circumstances such as 
inside application containers where "systemd" (or init system) is not 
present.

The purpose of "systemctl" package is to provide alternative "systemctl" 
utility to manage systemd services without systemd. Of course is it not a 
complete implementation but IMHO quite sufficient to be practically useful 
and warrant for "Provides: systemd".

The unfortunate problem why I had to introduce "Provides: systemd" is 
discussed in #959174.


> As a random example, systemd-tmpfiles and other utilities are not
> provided by `systemctl`.

It would be ridiculous to re-implement all broad systemd functionality.
However service management functionality is mature enough and that's a 
primary feature of systemd as well.

-- 
Cheers,
 Dmitry Smirnov.

---

I am easily satisfied with the very best.
-- Winston Churchill


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

Bug#959829: RFP: google-api-client-java -- Flexible, efficient, and powerful Java client library for accessing any HTTP-based API on the web

[Olek Wojnar]

Package: wnpp
Severity: wishlist

* Package name: google-api-client-java
  Version : 1.30.9
  Upstream Author : Google Inc.
* URL : https://github.com/googleapis/google-api-java-client
* License : Apache 2.0
  Programming Lang: Java
  Description : Flexible, efficient, and powerful Java client library for 
accessing any HTTP-based API on the web

This library can access any HTTP-based API on the web, not just Google APIs.
It has a powerful OAuth 2.0 library with a consistent interface. It also has
lightweight and efficient XML and JSON data models that support any data
schema, support for protocol buffers, and a set of generated libraries for
Google APIs.

**

Dear Prospective Packager,

This package is part of the dependency chain for medical and scientific
community resources that the Debian Med team has identified as relevant to the
COVID-19 pandemic. If you are able to participate in this endeavor [1], your
assistance is greatly appreciated!

-Olek
On behalf of the Debian Bazel Team

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#959821: linux-image-5.6.0-1-amd64: Linux 5.6.0 kernel breaks hostapd 5 GHz AP mode on Atheros radios

[Michael Berg]

Package: src:linux
Version: 5.6.7-1
Severity: normal

After upgrading to linux-image-5.6.0-1-amd64 on my Linux-based
wireless access-point (AP), hostapd is no longer able to configure
the Atheros radios for the 5 GHz band.

On the old 5.5 kernel, `iw list` shows the following for the 5 GHz band.
~~
Frequencies:
* 5180 MHz [36] (23.0 dBm)
* 5200 MHz [40] (23.0 dBm)
* 5220 MHz [44] (23.0 dBm)
* 5240 MHz [48] (23.0 dBm)
* 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (23.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (23.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (23.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (23.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (23.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (23.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (23.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (23.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (23.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (23.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (23.0 dBm) (no IR, radar detection)
* 5720 MHz [144] (23.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
~~

On the new 5.6 kernel, `iw list` shows that all of the 5 GHz channels
are either disabled or "no IR" (and so can't be used in AP mode).
~~
Frequencies:
* 5180 MHz [36] (23.0 dBm) (no IR)
* 5200 MHz [40] (23.0 dBm) (no IR)
* 5220 MHz [44] (23.0 dBm) (no IR)
* 5240 MHz [48] (23.0 dBm) (no IR)
* 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (30.0 dBm) (no IR)
* 5765 MHz [153] (30.0 dBm) (no IR)
* 5785 MHz [157] (30.0 dBm) (no IR)
* 5805 MHz [161] (30.0 dBm) (no IR)
* 5825 MHz [165] (30.0 dBm) (no IR)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
~~

I've set the regulatory domain to 'US' in both /etc/default/crda
and in the hostapd configuration files.

On the old 5.5 kernel, `iw reg get` shows a global section and
both Atheros wireless cards configured for "country US".
~~
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#1
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
~~

On the new 5.6 kernel, `iw reg get` only shows a global section,
even though the wireless interfaces are present in other network tools.
~~
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
~~

After some searching, I found the following bug report in Arch linux.
https://bbs.archlinux.org/viewtopic.php?id=254535
Which links to this kernel patch that went into the Linux 5.6 kernel.

Bug#892261: fixed upstream

[Wolfram Sang]

Fixed upstream with commit aef913e ("mmc-utils: use MMC_IOC_MULTI_CMD
for RPMB access") since December 2018.


signature.asc
Description: PGP signature

Bug#659348: #659348 - webext-librejs RFP → ITP

[John Scott]

Control: owner -1 !
Control: retitle -1 ITP: webext-librejs -- browser plugin to block non-free JS

I'm starting to work on this. When it starts taking shape, I hope it will be 
welcome with the Web/MozExt team.

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

Bug#959826: ITP: topcom -- Triangulations Of Point Configurations and Oriented Matroids

[Doug Torrance]

On Tue, May 5, 2020 at 6:26 PM David Bremner  wrote:
> Doug Torrance  writes:
> > I'm interested in packaging TOPCOM as it is a dependency of Macaulay2,
> > which I am working to package for Debian (#439888).  I will maintain
> > TOPCOM under the umbrella of the Debian Science Team.
>
> It can be used by polymake as well, so when you have something working
> let me know and I'll test that interface.

Thanks for your note!

I've been pushing my progress so far to Salsa:
https://salsa.debian.org/science-team/topcom

It's still pretty rough (no d/copyright, tons of Lintian stuff to
address, etc.), but it builds.

I'm curious if you have any thoughts on one decision I've made.  I've
prefixed all of the binaries with "topcom-".  There are a few of them
with very generic names (e.g., "cube").  The Gentoo and Fedora
maintainers chose to do use a prefix with just some of the binaries,
but I figured I'd go all the way.  Looking ahead to the Macaulay2
interface, I don't want to have to worry about which binaries have the
prefix and which don't.

Doug

Bug#959565: libjdom2-intellij-java: FTBFS: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':contrib:co

[Emmanuel Bourg]

Control: reassign -1 libxalan2-java
Control: found -1 2.7.2-3
Control: severity -1 important
Control: affects -1 + libjdom2-intellij-java
Control: retitle -1 libxalan2-java: xml-apis dependency left in the 
xalan:serializer pom

The actual issue is with libxalan2-java, because the xalan:serializer
pom depends on xml-apis but the package doesn't depend on libjaxp1.3-java.

Bug#959113: guava-libraries: Please update to recent upstream (v25.1 or later)

[Emmanuel Bourg]

Le 05/05/2020 à 05:59, Olek Wojnar a écrit :

> However, I will attempt to build with v19 once we get to that point.
> That will hopefully be within the next week or two. If I obtain any
> useful information, I will let you know on this bug report.

Thank you. Guava is a troublesome library to upgrade, it's a core
library used by many projects, but upstream doesn't take binary
compatibility seriously and frequently removes classes/methods. This is
a recurrent source of regression on upgrades. So if the upgrade isn't
absolutely required it's preferable to stick to the current version.

That said, I've uploaded the version 23.6.1 to experimental, and the
version 29.0 should follow soon. So if it doesn't work with Guava 19 you
can try with the recent releases.

Emmanuel Bourg

Bug#959766: libnetty-java: Please package all class files within netty-all.jar

[Emmanuel Bourg]

Le 05/05/2020 à 05:52, Olek Wojnar a écrit :

> The netty-all.jar package currently differs from upstream in that it does not
> contain any class files. I understand that there is a Maven-based dependency
> system that attempts to pull in classes from the other jar files, but this
> does not work reliably. Specifically, when using the Bazel Build system, the
> dependencies are not pulled in and builds fail.

Hi Olek,

The empty jar is a compromise between providing a resolvable netty-all
dependency to the build systems and avoiding a duplication of the
classes installed. If Bazel pulls the transitive dependencies this
shouldn't be a problem. Otherwise you can simply replace the netty-all
dependency by the individual artifacts used by Bazel.

Emmanuel Bourg

Bug#959567: marked as done (dom4j: FTBFS: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':testCompile

[Emmanuel Bourg]

> Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could 
> not resolve xml-apis:xml-apis:debian.
> Required by:
> project : > xalan:xalan:debian > xalan:serializer:debian

The actual issue is with libxalan2-java, because the xalan:serializer
pom depends on xml-apis but the package doesn't depend on
libjaxp1.3-java. Any package depending on xalan is likely to fail similarly.

The xml-apis artifact contains the javax.xml classes now integrated in
the JDK. In most cases this dependency can be dropped (from the poms and
the packages dependencies).

Emmanuel Bourg

Bug#942988: displaycal: Python2 removal in sid/bullseye

[Florian Höch]

Hey, just letting you know upstream is indeed still alive.

As you have noticed, things take longer than expected, and not all is 
due to the move to Python3. While I appreciate the offer to help, at the 
moment it would make things harder to juggle for me.


The reason there is no commits over at SF is also that I'm going to move 
code repos. Too much going on atm.


--
Florian Höch
https://displaycal.net

Bug#959516: RFS: simple-scan/3.36.2-1 -- Simple Scanning Utility

[Jeremy Bicha]

I would be happy to sponsor the simple-scan update for you, but could
you please review my proposed commits first?

https://salsa.debian.org/jbicha/simple-scan/commits/minor-cleanup
https://bugs.debian.org/904168

Thanks,
Jeremy Bicha

Bug#959516: RFS: simple-scan/3.36.2-1 -- Simple Scanning Utility

[Jeremy Bicha]

I would be happy to sponsor the simple-scan update for you, but could
you please review my proposed commits first?

https://salsa.debian.org/jbicha/simple-scan/-/commits/minor-cleanup/
https://bugs.debian.org/904168

Thanks,
Jeremy Bicha

Bug#954801: linux image 5.6.0-1-amd64: Wireless can't follow some AP's frequency changes in 5 GHz band.

[Miguel A. Vallejo]

Hello.

Just a quick update. After upgrading the kernel to 5.6.0-1-amd64
(5.6.7-1) I can confirm the problem is still present:

May  5 23:22:39 wpa_supplicant[537]: wlx8c882bxx:
CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5520 ht_enabled=1 ch_offset=-1
ch_width=80 MHz cf1=5530 cf2=0
May  5 23:22:40 wpa_supplicant[537]: wlx8c882bxx:
CTRL-EVENT-CHANNEL-SWITCH freq=5520 ht_enabled=1 ch_offset=-1
ch_width=80 MHz cf1=5530 cf2=0
May  5 23:22:40 kernel: [46021.832983] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx tries to chanswitch to same channel, ignore
May  5 23:22:40 kernel: [46021.832989] wlx8c882bxx: AP VHT
information is invalid, disable VHT
May  5 23:22:40 kernel: [46021.832994] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx changed bandwidth, new config is 5520 MHz, width 2
(5530/0 MHz)
May  5 23:22:40 kernel: [46021.832996] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx changed bandwidth in a way we can't support -
disconnect
May  5 23:22:40 kernel: [46021.832997] wlx8c882bxx: failed to
follow AP a0:64:8f:xx:xx:xx bandwidth change, disconnect
May  5 23:22:40 wpa_supplicant[537]: wlx8c882bxx:
CTRL-EVENT-DISCONNECTED bssid=a0:64:8f:xx:xx:xx reason=3
locally_generated=1

Greetings

Bug#959805: libproxy1-plugin-mozjs: Passes invalid/corrupted strings to FindProxyForURL()

[Jeremy Bicha]

On Tue, May 5, 2020 at 10:33 AM Simon McVittie  wrote:
> However, this plugin has a popcon of 108 installations (compared with 27K
> for its webkit counterpart), wasn't shipped in buster, and I don't think
> we consider mozjs68 to be safe for use with untrusted content (although
> PAC is probably at least semi-trusted in any reasonable threat model);
> so perhaps it should just be removed instead?

Does anyone know if there is anything the mozjs plugin can do that the
webkit can't?

I'd prefer we only offer the webkit version.

Thanks,
Jeremy Bicha

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

[Ansgar]

Package: systemctl
Version: 1.4.4147-2
Severity: serious

The last upload adds `Provides: systemd`, but `systemctl` obviously
doesn't provide the same (or similar) functionality as the `systemd`
package.

As a random example, systemd-tmpfiles and other utilities are not
provided by `systemctl`.

Ansgar

Bug#959826: ITP: topcom -- Triangulations Of Point Configurations and Oriented Matroids

[David Bremner]

Doug Torrance  writes:

> I'm interested in packaging TOPCOM as it is a dependency of Macaulay2,
> which I am working to package for Debian (#439888).  I will maintain
> TOPCOM under the umbrella of the Debian Science Team.

It can be used by polymake as well, so when you have something working
let me know and I'll test that interface.

d

Bug#959822: [DRE-maint] Bug#959822: redmine: Cannot install redmine on fresh buster install

[Georg Faerber]

Control: severity -1 normal

Hi Joseph,

On 20-05-05 20:56:51, Joseph Muller wrote:
> I have a fresh Buster install, and when I first tried to install
> Redmine I noticed there was no package available in Buster. I added
> the Buster backports repo and the install began, but then apt reported
> unmet dependencies (Depends: ruby-rouge (>= 3.7.0) but 3.3.0-1 is to
> be installed). How can this issue be resolved?

You need to pull ruby-rouge (and probably other packages as well) from
buster-backports. You could achieve this via either doing

apt-get install -t buster-backports redmine

or

APT pinning for these specific packages

or

...

Hope this helps,
cheers,
Georg

Bug#959827: lintian-brush: Consult repology when determining upstream Homepage URL

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.61
Severity: wishlist

In
https://salsa.debian.org/jelmer/debian-janitor/-/issues/102#note_162552,
Patrice mentions that repology also provides homepage information per
package at https://repology.org/project/$source/packages

It would be great if lintian-brush could also consult this when trying
to determine the upstream homepage URL for a package. One of the
challenges is determining the upstream package name - we'll have to
translate from the Debian upstream source package to the repology name.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.3
ii  python3  3.8.2-3
ii  python3-breezy   3.1.0~bzr7509-1
ii  python3-debian   0.1.37
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1+b1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pkginfo  1.4.2-3
ii  python3-ruamel.yaml  0.15.89-3+b2

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.20-1
ii  libdebhelper-perl  13
ii  lintian2.70.0
ii  python3-asyncpg0.20.1-1+b1
ii  python3-pyinotify  0.9.6-1.3

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
ii  postgresql-common  214

-- no debconf information

Bug#935969: Any chance of getting updated package?

[Holger Mickler]

Hi Salvatore,

if I interpret correctly, the needed patch is added for -3, but not yet 
released: "firmware-nonfree (20190717-3) UNRELEASED; urgency=medium"


https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/c11789ce8f522f8d2f7ff83b535d6ae059fc865f


On a Lenovo E595 (AMD Ryzen 3700U), problem is with kernel 4.19 from buster the 
GUI is not working (X fails to start) and with 5.4 from backports GUI works, but 
the WIFI is not available - what a pity :-(


I'd really be happy if you could make available an updated version of 
firmware-realtek.


Regards,
Holger

Bug#896119: bug is still present on buster

[Thierry]

Hi,

i confirm that i can still reproduce the issue, on an up-to-date Debian
buster x86_64:

$ scilab-cli
Scilab 6.0.1 (May 18 2019, 11:50:11)

--> atomsShow('coselica')
Scanning repository http://atoms.scilab.org/6.0 ... Done

HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140194230798720:
  #000: ../../../src/H5G.c line 548 in H5Gget_info(): invalid argument
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140194230798720:
  #000: ../../../src/H5G.c line 299 in H5Gcreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140194230798720:
  #000: ../../../src/H5A.c line 263 in H5Acreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140194230798720:
  #000: ../../../src/H5D.c line 119 in H5Dcreate2(): not a location ID
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140194230798720:
  #000: ../../../src/H5F.c line 664 in H5Fclose(): not a file ID
major: File accessibilty
minor: Inappropriate type
failed to close fileat line   265 of function atomsDESCRIPTIONget ( 
/usr/share/scilab/modules/atoms/macros/atoms_internals/atomsDESCRIPTIONget.sci 
line 284 )
at line31 of function atomsIsPackage  ( 
/usr/share/scilab/modules/atoms/macros/atoms_internals/atomsIsPackage.sci line 
47 )
at line43 of function atomsShow   ( 
/usr/share/scilab/modules/atoms/macros/atomsShow.sci line 59 )

atomsDESCRIPTIONget: save ('/home/user/.Scilab/scilab-6.0.1/.atoms/packages') 
has failed.
--> 

Best regards,
Thierry

Bug#959826: ITP: topcom -- Triangulations Of Point Configurations and Oriented Matroids

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: topcom
  Version : 0.17.1
  Upstream Author : Joerg Rambau 
* URL : http://www.rambau.wm.uni-bayreuth.de/TOPCOM/
* License : GPL
  Programming Lang: C++
  Description : Triangulations Of Point Configurations and Oriented Matroids

TOPCOM is a collection of clients to compute Triangulations Of Point
Configurations and Oriented Matroids, resp.

The algorithms use only combinatorial data of the point configuration
as is given by its oriented matroid. Some basic commands for computing
and manipulating oriented matroids can also be accessed by the user.

It was very much inspired by the maple program PUNTOS, which was
written by Jesus de Loera. TOPCOM is entirely written in C++, so there
is a significant speed up compared to PUNTOS.

I'm interested in packaging TOPCOM as it is a dependency of Macaulay2,
which I am working to package for Debian (#439888).  I will maintain
TOPCOM under the umbrella of the Debian Science Team.

Bug#959825: libwildmagic FTCBFS: uses the build architecture compiler

[Helmut Grohne]

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

libwildmagic fails to cross build from source, because it does not pass
cross tools to make. Beyond that, libwildmagic is a bit unconventional
in that it uses the CC variable (normally used for the C compiler) to
record a C++ compiler. Thus we need to pass the compiler explicitly and
seed it appropriately from dpkg's buildtools.mk.  Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libwildmagic-5.13/debian/changelog 
libwildmagic-5.13/debian/changelog
--- libwildmagic-5.13/debian/changelog  2020-04-06 13:53:56.0 +0200
+++ libwildmagic-5.13/debian/changelog  2020-05-05 17:54:04.0 +0200
@@ -1,3 +1,10 @@
+libwildmagic (5.13-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass C++ compiler as CC. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 05 May 2020 17:54:04 +0200
+
 libwildmagic (5.13-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru libwildmagic-5.13/debian/rules 
libwildmagic-5.13/debian/rules
--- libwildmagic-5.13/debian/rules  2014-08-13 12:04:25.0 +0200
+++ libwildmagic-5.13/debian/rules  2020-05-05 17:54:03.0 +0200
@@ -6,6 +6,7 @@
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
+-include /usr/share/dpkg/buildtools.mk
 
 
 VERSION=5.13
@@ -29,7 +30,7 @@
 
 override_dh_auto_build: manpage
dh_quilt_patch
-   make CFG=DebugDynamic -f makefile.wm5 
+   make CFG=DebugDynamic -f makefile.wm5 'CC=$(CXX)'
 
# Now make sure we reproduce the example files hierarchy in
# some clean location for later shipping by the .install file.

Bug#959678: debhelper: dh_installsystemd --no-restart-on-upgrade without effect unless --no-restart-after-upgrade is given, too (compat 13)

[Axel Beckert]

Hi Niels,

Niels Thykier wrote:
> The options are confusingly similar due to an unfortunate choice many
> years ago.

Yeah, looks historically grown.

> It does not help that the text differs between dh_installinit and
> dh_installsystemd despite the options intend to have the same
> meaning.

Yep, was kinda irritate by this, but since systemd has to do
everything differently, I expected subtle differences in the semantics
and hence also that the option names had to be different for similar
reasons.

> > With a lot of experimenting (e.g. trying the alias --no-stop-on-upgrade
> > for --no-restart-on-upgrade), I figured out that this works as I want
> > it:
> > 
> > 
> > override_dh_installinit:
> > dh_installinit --noscripts
> > 
> > override_dh_installsystemd:
> > dh_installsystemd --no-restart-on-upgrade --no-restart-after-upgrade
> > 
> > 
> 
> Can I please have you use "--no-stop-on-upgrade" instead of
> "--no-restart-on-upgrade".

Can do, but won't do a separate upload just for this.

> The "on" vs. "after" upgrade is not kind to
> the eyes when they have different meanings

Well, depends, I have definitely more issues understanding the
semantic difference.

> and I intend to remove the "on" variant for exactly this reason.

But please not for dh v13, only for v14 upwards.

> The "no-stop-on-upgrade" is not entirely accurate either though,

Exsactly. That's what this bug report is mainly complaining about. :-)

> but at least it is less likely to be misread as "restart".

Well, in this case, I prefer the restart over the stop, because it's
mainly the restart which is the issue here. (Yes, it technically
includes a stop, but it doesn't need to.)

> > "Do not stop service on upgrade." is clearly not true unless additional
> > options are given.
> > 
> > "Undo a previous --restart-after-upgrade (or the default of compat 10)."
> > is not true either there was no previous --restart-after-upgrade to
> > undo.
> > 
> > I suspect that either
> > 
> > * the logic which adds the snippets to postinst is flawed,
> > * the snippets added to postinst are flawed, or
> > * it's a pure documentation issue.
[...]
> It is the logic,

Ah, ok.

> although the documentation was not great either.

*nod*

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#791707: Fixed upstream

[Wolfram Sang]

The issue has been fixed upstream since April 2016 with commit 2e31d1c3a
("chrt: validate priority before trying to use it") which also mentions
this bugreport.



signature.asc
Description: PGP signature

Bug#959824: RM: ropemode -- RoQA; Depends on Py2, orphaned, no reverse deps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ropemode. It depends on Python 2, is orphaned without
an adopter since nine months and there are no reverse deps.

Cheers,
Moritz

Bug#959823: lintian-brush: Upgrading from compat 11 -> 13 can leave an unecessary "dh_missing --fail-missing"

[Niels Thykier]

Package: lintian-brush
Severity: minor

Hi,

Based on a code review of lintian-brush, it seems that lintian-brush
will replace a call to "dh_install --fail-missing" or "dh
... --fail-missing" with "dh_missing --fail-missing" when upgrading
from compat 11 to 12.  This was indeed necessary.

However, if you are going from 11 to 13, then the "dh_missing
--fail-missing" is the default and might as well be omitted.

Possibly related, overrides of dh_missing just to pass --fail-missing
to dh_missing could be removed when upgrading to compat 13.  The problem
with doing it naively this way for 11->13 is that it will be reflected
in the commit message (which it may look a bit weird as it will
reference adding an override target it then removes again).

~Niels

Bug#937413: pycryptopp: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:33:16AM +, Matthias Klose wrote:
> Package: src:pycryptopp
> Version: 0.7.1-4
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> 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.

Hi Vasudev,

https://github.com/tahoe-lafs/pycryptopp/issues/36#issuecomment-504130020 
states:

| The Tahoe-LAFS project has decided it is not interested in porting
| pycryptopp to Python 3. Instead, Tahoe-LAFS is switching to the
| "cryptography" library.
| 
| I don't have any problem with anyone else taking on this porting effort
| but I'm closing this to reflect the fact that the maintainers have
| no plans of taking this on.

Given that the now removed tahoe-lafs was the only reverse dependency,
let's also remove pycryptopp?

Cheers,
Moritz

Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137

[The Wanderer]

On 2020-05-05 at 16:05, Tollef Fog Heen wrote:

> ]] The Wanderer
> 
>> I'm not at all sure whether the underlying cause is still the same,
>> but I'm getting a very similar-looking failure - albeit with
>> different BUG details - after a reboot a few nights ago into a new
>> kernel.
> 
> My understanding is that when you get one of those, it indicates a
> kernel problem, isn't that so?  If so, it should probably just be
> reassigned to linux.

That's entirely possible, and I wouldn't object if that happens.

That said, in my case I'm now reasonably certain that the proximate
underlying cause is misbehaving (either buggy, or outright starting to
fail) storage-related hardware, as touched on at the end of my initial
comment.

After the RAID-array check completed that evening, I ran
/etc/cron.daily/mlocate by hand (as root), and the I/O freeze from
overdoing writes that I mentioned was triggered; the system kept running
for a few hours, but the gkrellm clock froze at one second to midnight,
and the system hadn't recovered by 6:30 the next morning. A hard
power-cycle and a full manual fsck (including fixing several errors on
one partition) got things working again, with no sign of current
problems. I haven't retried explicitly initiating the process again, but
it's been long enough that it would have run on its own, and nothing
seems to have gone awry.

The kernel probably still shouldn't BUG when this happens, but I don't
know how far it's reasonable to expect the kernel to go to avoid such
problems, and it's useful to get the notification of what's happened /
hung under the hood - so I wouldn't be too fussed if the kernel people
just declined this as being outside of their scope.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#959822: redmine: Cannot install redmine on fresh buster install

[Joseph Muller]

Source: redmine
Version: 4.0.7-1~bpo10+1
Severity: important

Dear Maintainer,

I have a fresh Buster install, and when I first tried to install Redmine I 
noticed there was no package available in Buster. I added the Buster backports 
repo and the install began, but then apt reported unmet dependencies (Depends: 
ruby-rouge (>= 3.7.0) but 3.3.0-1 is to be installed). How can this issue be 
resolved?


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

Kernel: Linux 5.3.10-1-pve (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#959806: already done.

[Paul Tagliamonte]

I uploaded this package to NEW last week. This bug should likely be
closed.

   Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Bug#959820: firefox-esr: FTBFS, cannot compile on debian buster + security updates

[Giuseppe Sacco]

Package: firefox-esr
Version: 68.7.0esr-1~deb10u1
Severity: major

The building process on debian 10 i386 stops with an error during
linking.

I just downloaded and rebuilt the package on a freshly installed QEMU
VM and got an error. I was trying to rebuild it with a specific GCC
optimization, this way:

# dpkg-source -x firefox-esr_68.7.0esr-1~deb10u1.dsc
# apt-get build-dep firefox-esr
# apt-get install build-essential
# cd firefox-esr-68.7.0esr
# time env DEB_CFLAGS_MAINT_APPEND="-march=pentium4" dpkg-buildpackage -uc -us

and the build process fails with this error:

/usr/bin/g++ -o ../../dist/bin/plugin-container -Wdate-time -D_FORTIFY_SOURCE=2 
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wall 
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith 
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings 
-Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough 
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations 
-Wno-error=array-bounds -Wno-error=coverage-mismatch 
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros 
-Wno-error=class-memaccess -Wformat -Wformat-overflow=2 -fno-sized-deallocation 
-O2 -fdebug-prefix-map=/mnt/firefox-esr-68.7.0esr=. -fstack-protector-strong 
-Wformat -Werror=format-security -march=pentium4 -fno-schedule-insns2 
-fno-lifetime-dse -fno-delete-null-pointer-checks -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions 
-fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections 
-fno-exceptions -fno-math-errno -pthread -pipe -freorder-blocks -O2 
-fomit-frame-pointer -funwind-tables  
/mnt/firefox-esr-68.7.0esr/build-browser/ipc/app/plugin-container.list
-lpthread -Wl,-z,relro -Wl,--as-needed -Wl,--as-needed 
-Wl,--compress-debug-sections=zlib -Wl,--reduce-memory-overheads 
-Wl,--no-keep-memory -Wl,--stats -fstack-protector-strong -Wl,-z,noexecstack 
-Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions 
-Wl,--build-id=sha1 -rdynamic 
-Wl,-rpath-link,/mnt/firefox-esr-68.7.0esr/build-browser/dist/bin 
-Wl,-rpath-link,/usr/lib -pie ../../config/external/nspr/pr/libnspr4.so 
../../config/external/nspr/libc/libplc4.so 
../../config/external/nspr/ds/libplds4.so ../../toolkit/library/libxul.so -ldl
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_file_chooser_set_do_overwrite_confirmation'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_main_iteration'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_page_setup_new'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_page_setup_set_left_margin'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_dialog_get_content_area'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_print_unix_dialog_get_selected_printer'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gdk_event_copy'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_print_unix_dialog_get_page_setup'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_combo_box_new_with_entry'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_radio_button_get_type'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_print_job_set_source_file'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_window_resize'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_button_new_with_label'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_window_iconify'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_render_background'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to `gdk_flush'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_plug_get_type'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_selection_data_get_target'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_style_context_get_property'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gdk_window_process_updates'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_file_chooser_set_current_name'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_widget_get_style_context'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_print_settings_set_duplex'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_window_unmaximize'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_widget_path_get_object_type'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_icon_set_unref'
/usr/bin/ld: ../../toolkit/library/libxul.so: undefined reference to 
`gtk_print_settings_has_key'
/usr/bin/ld: 

Bug#958444: protobuf: Please add protobuf-java-util to the protobuf-java package

[Olek Wojnar]

On Tue, May 5, 2020 at 2:24 PM László Böszörményi (GCS) 
wrote:

>
>  Indeed, thanks! Going to upload it not to delay you any further.
>

Great, thanks!

-Olek

Bug#787425: dkopp: diff for NMU version 6.5-1.1

[zeha]

Control: tags 787425 + patch
Control: tags 787425 + pending

Dear maintainer,

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

Best,
Chris

diff -Nru dkopp-6.5/debian/changelog dkopp-6.5/debian/changelog
--- dkopp-6.5/debian/changelog  2014-06-06 12:26:36.0 +
+++ dkopp-6.5/debian/changelog  2020-05-05 20:06:12.0 +
@@ -1,3 +1,10 @@
+dkopp (6.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use blkid instead of volname. (Closes: #787425)
+
+ -- Chris Hofstaedtler   Tue, 05 May 2020 20:06:12 +
+
 dkopp (6.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dkopp-6.5/debian/patches/03-blkid.patch 
dkopp-6.5/debian/patches/03-blkid.patch
--- dkopp-6.5/debian/patches/03-blkid.patch 1970-01-01 00:00:00.0 
+
+++ dkopp-6.5/debian/patches/03-blkid.patch 2020-05-05 20:06:00.0 
+
@@ -0,0 +1,13 @@
+Index: dkopp-6.5/dkopp-6.5.cc
+===
+--- dkopp-6.5.orig/dkopp-6.5.cc
 dkopp-6.5/dkopp-6.5.cc
+@@ -2489,7 +2489,7 @@ showpoop:
+ 
+dvdtime = dstat.st_ctime;   // 
 set DVD/BD ID = mod time
+ 
+-   snprintf(command,99,"volname %s",BJdvd);// 
 get DVD/BD label
++   snprintf(command,99,"blkid -c /dev/null -s LABEL -o value %s",BJdvd);   // 
 get DVD/BD label
+fid = popen(command,"r");
+if (fid) {
+   pp = fgets_trim(mbuff,99,fid,1);
diff -Nru dkopp-6.5/debian/patches/series dkopp-6.5/debian/patches/series
--- dkopp-6.5/debian/patches/series 2014-06-06 12:24:51.0 +
+++ dkopp-6.5/debian/patches/series 2020-05-05 20:02:09.0 +
@@ -1,2 +1,3 @@
 01-desktop_file.patch
 02-makefile.patch
+03-blkid.patch

Bug#959678: debhelper: dh_installsystemd --no-restart-on-upgrade without effect unless --no-restart-after-upgrade is given, too (compat 13)

[Niels Thykier]

Axel Beckert:
> Package: debhelper
> Version: 13
> Severity: important
> 
> Hi,
> 
> for switching wdm to compat level 13 I changed debian/rules as follows:
> 
> [...]
> 
> Upon package upgrade, wdm is nevertheless restarted and the currently
> running X session is gone.
> 

Hi Axel,

Thanks for reporting this bug.

The options are confusingly similar due to an unfortunate choice many
years ago. It does not help that the text differs between dh_installinit
and dh_installsystemd despite the options intend to have the same meaning.

> With a lot of experimenting (e.g. trying the alias --no-stop-on-upgrade
> for --no-restart-on-upgrade), I figured out that this works as I want
> it:
> 
> 
> override_dh_installinit:
>   dh_installinit --noscripts
> 
> override_dh_installsystemd:
>   dh_installsystemd --no-restart-on-upgrade --no-restart-after-upgrade
> 
> 

Can I please have you use "--no-stop-on-upgrade" instead of
"--no-restart-on-upgrade".  The "on" vs. "after" upgrade is not kind to
the eyes when they have different meanings and I intend to remove the
"on" variant for exactly this reason.

The "no-stop-on-upgrade" is not entirely accurate either though, but at
least it is less likely to be misread as "restart".

> But the dh_installsystemd(1) man pageIMHO doesn't explain this
> behaviour:
> 
> 
> [...]
> 
> 
> "Do not stop service on upgrade." is clearly not true unless additional
> options are given.
> 
> "Undo a previous --restart-after-upgrade (or the default of compat 10)."
> is not true either there was no previous --restart-after-upgrade to
> undo.
> 
> I suspect that either
> 
> * the logic which adds the snippets to postinst is flawed,
> * the snippets added to postinst are flawed, or
> * it's a pure documentation issue.
> 
> [...]


It is the logic, although the documentation was not great either.

~Niels

Bug#737658: some notes on util-linux takeover of eject

[Chris Hofstaedtler]

* atzlinux 肖盛文  [200505 05:30]:
> 
> 在 2020/5/4 下午7:40, Andreas Henriksson 写道:
[...]
> >
> >> 2) volname apparently uses knowledge about ISO9660 directly, and
> >> personally I'd rather see users use blkid instead, like so:
> >>   /usr/sbin/blkid -s LABEL ./debian-10.3.0-amd64-netinst.iso
> >>   ./debian-10.3.0-amd64-netinst.iso: LABEL="Debian 10.3.0 amd64 n"
> >> (This works for anything that's got a label, not just ISO9660
> >> files/devices.)
> >> I can try a minimal patch to dkopp. (Also dkopp doesn't depend on
> >> eject -- how did you find this?)
> 
> dkopp should add depend on eject.

Indeed. Well, if we fix #787425 it doesn't need to :-)

> apt rdepends eject,show many packages.
> 
> > ... and as soon as someone brings up blkid I can't help but mention
> > that lsblk is the modern replacement (although not available in udeb).
> >
> >>> After the replace plan finished,Are these two commands will disappear in
> >>> Debian 11 ?
> >>>
> >>> If has one shell scripts used these two commands in Debian 10,when the
> >>> OS update to Debian 11,
> >>>
> >>> Do the shell scripts need to modify?How to modify?
> >> blkid can be used to replace volname; not sure if a replacement for
> >> crypt-dev-device is actually needed?
> >>
> >> I'd really like to see us move away from Debian-specific tools,
> >> especially if they're undocumented and/or have security impact.
> >> While the tools shipped in util-linux are sometimes not great, I
> >> think util-linux's upstream is in a way better situation, with a lot
> >> more willing helping hands (and eyes, too).
> > Agreed. And more eyes/help is welcome. Atleast the upstream util-linux
> > project is quite nice to get involved with if you're interested.
> 
> The upstream util-linux project is better,I also agreed.
> 
> Let us talk about the other affcets  if  util-linux takeover of eject:
> 
> 1.The packages Depends: Recommends:Suggests: on eject.
> 
> How to deal with this packages?Is need these packages modify the
> debian/control file?
> 
> or use the source code of the util-linux package to create the new eject
> package? add eject into debian/control ?

util-linux would grow a new eject binary package (to avoid growing
the essential util-linux binary package).

> 2.The scripts invoke volname.
> 
> Can these scripts avoid the modify when the OS update?If the end users
> not need to modify their scripts,this is the better thing.
> 
> add a link for /usr/bin/volname to util-linux tool ?

I think util-linux (actually the new eject binary package) can get a
NEWS.Debian entry that lists alternative options for volname. Users
would need to modify their scripts manually. If users have
apt-listchanges installed, they will be informed at upgrade time.

We can fix dkopp in Debian.

> 3.use simple-cdd to build custom iso
> 
> If eject pachage don't exist in Debian archive, the packages list file
> must delete eject by manual.

eject would still exist as a binary package, so nothing to do here.

> 4.the distributions base on Debian
> 
> There are about 300 distributions base on Debian in the world.
> 
> Are these distributions need to modify?

>From my experience with derivatives, they are quite good at picking
up such changes.

> 5.others
> 
> I don't think about at present.
> 
> 
> At total,eject also has high popcon,we need to think so many things.
> 
> " util-linux takeover of eject",has advantage and disadvantage now.
> 
> We need a total solution,or balance.

I think we need one for /usr/bin/eject - that is "easy enough". We
have done this before for other packages / binaries.
For /usr/bin/volname and /usr/lib/eject/dmcrypt-get-device I would
opt for the NEWS.Debian solution.

Chris

Bug#959486: cloud-init - Enable fallback data source if nothing is detected in ds-identify

[Noah Meyerhans]

On Sat, May 02, 2020 at 11:24:59PM +0200, Bastian Blank wrote:
> cloud-init does some basic tasks, like
> - network config (currently completely shadowed by our own),
> - ssh host keys.
> 
> I think the most sensible setup would always enable cloud-init, and if
> it only runs with the fallback datasource.
> 
> Currently we are using ds-identify.  This tools does not have any way to
> only enable the fallback data source.
> 
> Any ideas?

By fallback datasource, you mean "None"?

We could always reintroduce the use of debconf for datasource selection,
and avoid depending on ds-identify at all.  The nice thing about that is
that we could then pre-fill that answer in our cloud images and
configure an explicit datasource there, too.

(Note that I don't actually *like* the idea of reintroducing debconf...)

noah

Bug#956868: Use Realtek's r8101 driver

[Heiner Kallweit]

r8169 doesn't support XID 240 (= RTL8401), and it's not really worth it to 
retrofit
support for this ancient chip version.  Use Realtek's r8101 driver instead.

Bug#939962: builds in git

[ygrek]

Hi,

 Upstream moved to https://github.com/SKS-Keyserver/sks-keyserver
 git master builds with 4.08 : 
https://travis-ci.org/github/SKS-Keyserver/sks-keyserver/jobs/683544082
 I will look to make a release

-- 

Bug#959791: horizon-eda FTCBFS: uses the build architecture pkg-config

[Uwe Steinmann]

Upѕtream has changed the Makefile. The next release will have it.

This is the commit.

https://github.com/horizon-eda/horizon/commit/cfa44300b932e0a71228be3689c5be7d185f090c

  Uwe

-- 
  MMK GmbH, Fleyer Str. 196, 58097 Hagen
  uwe.steinm...@mmk-hagen.de
  Tel: 02331 840446Fax: 02331 843920


signature.asc
Description: PGP signature

Bug#955689: libcatmandu-filestore-perl: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 255

[Niko Tyni]

On Fri, Apr 03, 2020 at 09:52:13PM +0200, Lucas Nussbaum wrote:
> Source: libcatmandu-filestore-perl
> Version: 1.13-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye

> > # Error:  Can't locate Data/UUID.pm in @INC (you may need to install 
> > the Data::UUID module) (@INC contains: /<>/blib/lib 
> > /<>/blib/arch /etc/perl 
> > /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
> > /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
> > /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
> > /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
> > /<>/blib/lib/Catmandu/DirectoryIndex/UUID.pm line 12.

This was unmasked by libcatmandu-perl 1.2011-1 dropping its dependency
on libdata-uuid-perl.

It looks like Data::UUID was not necessary at all, so upstream has
dropped it in

  
https://github.com/LibreCat/Catmandu-FileStore/commit/0e9e2d09dae88f6a0ca39edf0a342f8364c43f22

-- 
Niko Tyni   nt...@debian.org

Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137

[Tollef Fog Heen]

]] The Wanderer 

> I'm not at all sure whether the underlying cause is still the same, but
> I'm getting a very similar-looking failure - albeit with different BUG
> details - after a reboot a few nights ago into a new kernel.

My understanding is that when you get one of those, it indicates a
kernel problem, isn't that so?  If so, it should probably just be
reassigned to linux.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#959818: libcatmandu-perl: 1.2011-1 breaks libcatmandu-filestore-perl

[Niko Tyni]

Package: libcatmandu-perl
Version: 1.2011-1
Severity: serious
Control: block -1 with 955689

1.2011-1 in unstable dropped its dependency on libdata-uuid-perl,
unmasking a missing dependency in libcatmandu-filestore-perl (#955689).
This was noticed by autopkgtest checks, currently preventing testing
migration of libcatmandu-perl.

libcatmandu-filestore-perl should be fixed first, and libcatmandu-perl
should then declare a Breaks relation on the earlier versions
of libcatmandu-filestore-perl to prevent partial upgrades where
libcatmandu-perl is updated before libcatmandu-filestore-perl.
-- 
Niko Tyni   nt...@debian.org

Bug#959817: libgdal-grass : Depends: grass782 which is a virtual package, provided by:

[積丹尼 Dan Jacobson]

Package: grass-core

The following packages have unmet dependencies:
 libgdal-grass : Depends: grass782 which is a virtual package, provided by:
  - grass-core (7.8.2-1+b5), but 7.8.3-1 is to be 
installed

The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) grass-core [7.8.2-1+b5 (now)]

Bug#863650: Fix available

[Jan Niehusmann]

Hi,

I submitted a patch for this issue upstream:
https://github.com/pam-pgsql/pam-pgsql/pull/16

Jan

Bug#959816: RFP: caas -- XMPP compliance tester

[Martin]

Package: wnpp
Severity: wishlist

* Package name: caas
  Version : 2020-04-26
  Upstream Author : Daniel Gultsch 
* URL : https://github.com/iNPUTmice/caas
* License : BSD-3-clause
  Programming Lang: Java
  Description : XMPP Compliance Tester

web service for checking and visualising compliance status of XMPP servers

this is the software behind https://compliance.conversations.im/

Bug#959815: lintian-brush: Prune obsolete entries from maintscripts

[Niels Thykier]

Package: lintian-brush
Severity: wishlist

Hi,

We are a group of people trying to minimize the number of packages
with maintainer scripts in Debian.  There are many reasons for this
and one is that it would simplify deployment of new prototypes and
ideas such as [InstallBootstrap].

Therefore, it would be nice if lintian-brush could automatically clean
up old maintscripts entries (i.e. entries from debian/*.maintscripts
and debian/maintscript) that are no longer needed.  This would reduce
the amount of manual work involved.

Obviously, this would be even better if lintian-brush could *also* fix
[maintainer-script-should-not-use-dpkg-maintscript-helper] because
then it would naturally expand in coverage.  :)

~Niels


PS: Obviously, an important step is also to improve the tooling in the
other end to reduce the number of maintscripts needed at all or need
to be migrated.  We are working on that in parallel, but it will be a
long transition before we are all done and lintian-brush + Debian
janitor will be very useful in finishing that transition.

[InstallBootstrap]:
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap.

[maintainer-script-should-not-use-dpkg-maintscript-helper]:
https://lintian.debian.org/tags/maintainer-script-should-not-use-dpkg-maintscript-helper.html

Bug#952710: workaround

[mds]

As workaround it is possible to manually install the firmware to get a navi GPU 
(Radeon RX 5300, 5500, 5600, 5700) to work by doing this:

sudo apt install git
git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
cd linux-firmware/
sudo cp -va amdgpu/ /lib/firmware/
sudo update-initramfs -u
reboot

Bug#959587: python-biopython: FTBFS: AssertionError: False is not true

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Peter Cock 

Hi Peter,

with the upload of ncbi-blast+ version 2.10 Biopython test is running
into failures (see 

   https://bugs.debian.org/959587#10

)

Could you please adjust the Biopython test suite accordingly?

Kind regards

 Andreas.

On Tue, May 05, 2020 at 11:38:23AM -0400, Aaron M. Ucko wrote:
> 
> > Since there is a strong relation in time with your upload and this
> > FTBFS of biopython do you think that this could be connected:
> 
> Yes, per https://www.ncbi.nlm.nih.gov/books/NBK131777/, the upgrade to
> 2.10.0 changed the default database version (controlled by makeblastdb's
> -blastdb_version flag) from 4 to 5, causing some output files to change
> names (and formats):
> 
> *.nsd -> *.nnd
> *.nsi -> *.nni
> *.psd -> *.pnd
> *.psi -> *.pni
> 
> Thanks for checking!

-- 
http://fam-tille.de

Bug#959814: oggvideotools: Test dependency on pysycache-i18n that will likely be removed

[Adrian Bunk]

Source: oggvideotools
Version: 0.9.1-5
Severity: serious
Tags: ftbfs bullseye sid
Control: block 912504 by -1
Control: block 937553 by -1

pysycache-i18n will likely be removed due to #912504 and #937553.

Options are to change yet again to another ogg for this test,
or to remove this specific test.

Bug#934793: ITP: nattable -- high-performance SWT data grid

[Hongzhuo Liang]

On Thu, 15 Aug 2019 02:05:17 +0200 Vincent Prat wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package Name : nattable
>   Version               : 1.5.0
> Upstream author : NatTable developers
> * URL : https://www.eclipse.org/nattable/
> * License : Eclipse Public License 1.0
> Programming language : Java
> Description : high-performace SWT data grid
>
> NatTable is a powerful and flexible SWT table/grid widget that is 
built to handle very large data sets, real-time updates, dynamic 
styling, and more.

> NatTable is a subproject of Nebula.
>
> This package is a dependency of HDFView.
>
> This package will be maintained under the Debian Java Maintainers .
>

Waiting for this package for the newer version of hdfview.

Bug#959813: src:libqtdbusmock: fails to migrate to testing for too long: FTBFS on all release archs

[Paul Gevers]

Source: libqtdbusmock
Version: 0.7+bzr49+repack1-3
Severity: serious
Control: close -1 0.7+bzr49+repack1-4
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

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 in testing. Your package src:libqtdbusmock
in its current version in unstable has been trying to migrate for 60
days [2]. 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.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libqtdbusmock




signature.asc
Description: OpenPGP digital signature

Bug#958444: protobuf: Please add protobuf-java-util to the protobuf-java package

[GCS]

Hi Olek,

On Mon, May 4, 2020 at 8:43 AM Olek Wojnar  wrote:
> On Thu, Apr 30, 2020 at 1:26 AM László Böszörményi (GCS)  
> wrote:
> Well, I'm certainly no Java expert but I can definitely take a look. Where is 
> your packaging so far?
 If you ask for VCS location, I don't have one.

>>  How big is your changes? You can send that to me as a patch.
> Not very big. I'm attaching what I have. Note that I added a patch to disable 
> error-prone. The error-prone library is not strictly necessary and, if it 
> enters Debian at some point, you can just remove that patch. In the meantime, 
> it will enable the util java to build. I also ran a `quilt refresh` on the 
> existing patches before I created mine, my normal workflow to prevent 
> possible problems. If you don't want the patch refresh I also included a 
> clean patch that only makes the absolutely necessary changes to enable the 
> -util build.
 While it's good to have updated line information in patches, it loses
information as well - the function names in which the changes are
applied. I went with your clean patch now.

> This builds correctly in a sid cowbuilder and introduces no lintian errors. 
> Hope this helps!
 Indeed, thanks! Going to upload it not to delay you any further.

Regards,
Laszlo/GCS

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Tianon Gravi]

On Sun, 3 May 2020 at 06:12, Lucas Nussbaum  wrote:
> > ...
> > === warnings summary 
> > ===
> > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_fors[sfor]
> >   /<>/hy/models.py:133: RuntimeWarning: coroutine '' 
> > was never awaited
> > return super(HySymbol, cls).__new__(cls, s)
> >
> > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_fors[gfor]
> >   /usr/lib/python3/dist-packages/funcparserlib/parser.py:232: 
> > RuntimeWarning: coroutine '' was never awaited
> > self.pos = pos
> >
> > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_empty_for
> >   /usr/lib/python3/dist-packages/_pytest/nodes.py:192: RuntimeWarning: 
> > coroutine '' was never awaited
> > return (x[1] for x in self.iter_markers_with_node(name=name))
> >
> > .pybuild/cpython3_3.8_hy/build/tests/native_tests/core.hy::test_parse_args
> >   /usr/lib/python3/dist-packages/funcparserlib/parser.py:322: 
> > RuntimeWarning: coroutine '' was never awaited
> > raise NoParseError('got unexpected token', s)
> >
> > -- Docs: https://docs.pytest.org/en/latest/warnings.html
> > === 5 failed, 547 passed, 54 deselected, 4 warnings in 8.47 seconds 
> > 
> > E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
> > /<>/.pybuild/cpython3_3.8_hy/build; python3.8 -m pytest -k 
> > '-test_bin -test_hy2py'
> > dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
> > returned exit code 13
>
> ...

Oh, fun times.

I was definitely over my head with this one, so I reached out to the
Hy community and was pointed to https://bugs.python.org/issue39562,
which does seem quite related from my own limited understanding, so
this might technically be a bug in the Python package?

I'm including the Debian Python list on CC to hopefully see if someone
there can provide some assistance figuring out what's necessary here.
O:)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#959810: Font color for Arc Lighter variant is grayish

[David Mohammed]

There isn't anything configurable via a package which can be done in this
area. Themes are fixed since they are compiled.

Suggestions like this are best made upstream
https://github.com/jnsh/arc-theme

On Tue, 5 May 2020, 17:03 Camaleón,  wrote:

> Package: arc-theme
> Version: 20190917+git20200328-2
> Severity: wishlist
>
> Dear maintainer,
>
> The text color for Arc Lighter is too bright/light to be readable. Looks
> like if it were grayed out and thus very hard to read (see attached
> image).
>
> This was a common complaint for the original project¹ but it seems the
> issue is still present on the forked one.
>
> I understand this is a very personal setting but, could it be possible
> for Debian package, to allow users select the color pattern to use for
> every of the arc-themes variants?
>
> I personally really like texts to be in pure black (#00) but usability
> or other reasons could make it not convenient.
>
> ¹ https://github.com/horst3180/arc-theme/issues/406
>
> Greetings,
>
> --
> Camaleón
>

Bug#904339: what's the current state of jhdf?

[Vincent Prat]

Hi,

For the moment, it is stalled.
I still intent to adopt it, but the latest version depends on nattable,
which is not in Debian yet.
I packaged the latter, but found no sponsor.
As soon as I become a Debian Developer, I will be able to upload it myself.


Le 05/05/2020 à 19:13, Hongzhuo Liang a écrit :
> Hi,
>
> What's the current state of jhdf?
>
> Is there anyone to maintain it?

Bug#959020: upgrade-reports: Soundcard not detected after upgrading to kernel 5.5.0-2-amd64 in testing

[silverblue]

  I updated to kernel linux-image-5.6.0-1-amd64 in testing today and hoped this would resolve the issue. However, the issue is still the same. Booting with the older kernel linux-image-5.4.0-4-amd64 is working. I also tried a Fedora32 live system with kernel 5.6.6 and there the sound card is working just perfectly. Beside playing sound the digital mic is also fully working. How to get the same good experience in debian? Please advice. Thank you!

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

did you get any further with this problem?

cheers, josch

Quoting Francesco Poli (2020-02-24 23:51:52)
> On Sat, 22 Feb 2020 19:03:48 +0100 Johannes Schauer wrote:
> 
> [...]
> > for what it's worth I'm attaching the script I am using to re-generate my
> > autopkgtest qemu image. I uploaded a few packages today and just 
> > successfully
> > used that script so I can confirm it working.
> 
> I cannot spot any significant difference between your script and mine
> (apart from the fact that I have recently added "sync : umount / :
> shutdown" to the guestfish command-line, as you suggested)...
> 
> I really cannot understand what's going on! :-(
> 
> -- 
>  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

signature.asc
Description: signature

Bug#959812: Also broken for Debian 9

[guttersnipe]

I just confirmed that this issue also exists for Debian 9:

```
user@disp5874:~$ sudo su -
root@disp5874:~# cat /etc/issue
Debian GNU/Linux 9 \n \l
root@disp5874:~# apt-get install varnish munin
...
root@disp5874:~# echo -e '\n[varnish*]\nuser root\n' > 
/etc/munin/plugin-conf.d/z-varnish
root@disp5874:~# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
root@disp5874:~# vim /usr/share/munin/plugins/varnish_ 
root@disp5874:~# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
Error: uptime not part of varnishstat.
root@disp5874:~# ~
```

And here's the rest of the objects. Note that varnish_memory_usage actually 
does get some of its values; most don't.

```
root@disp5874:~# munin-run --debug --pidebug  varnish_objects
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_objects'
Error: n_objecthead not part of varnishstat.
Error: n_objcore not part of varnishstat.
Error: n_object not part of varnishstat.
root@disp5874:~# munin-run --debug --pidebug  varnish_backend_traffic
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_backend_traffic'
Error: backend_conn not part of varnishstat.
Error: backend_reuse not part of varnishstat.
Error: backend_fail not part of varnishstat.
Error: backend_recycle not part of varnishstat.
Error: backend_req not part of varnishstat.
Error: backend_unused not part of varnishstat.
Error: backend_unhealthy not part of varnishstat.
Error: backend_busy not part of varnishstat.
root@disp5874:~# munin-run --debug --pidebug  varnish_bad
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_bad'
Error: n_objoverflow not part of varnishstat.
SMA_s0_c_fail.value 0
SMA_Transient_c_fail.value 0
Error: n_wrk_failed not part of varnishstat.
Error: n_wrk_lqueue not part of varnishstat.
Error: client_drop not part of varnishstat.
Error: client_drop_late not part of varnishstat.
Error: backend_unhealthy not part of varnishstat.
Error: accept_fail not part of varnishstat.
Error: fetch_failed not part of varnishstat.
Error: n_wrk_drop not part of varnishstat.
Error: n_wrk_max not part of varnishstat.
Error: backend_busy not part of varnishstat.
Error: esi_warnings not part of varnishstat.
Error: losthdr not part of varnishstat.
Error: esi_errors not part of varnishstat.
root@disp5874:~# munin-run --debug --pidebug  varnish_expunge
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_expunge'
Error: n_expired not part of varnishstat.
Error: n_lru_nuked not part of varnishstat.
root@disp5874:~# munin-run --debug --pidebug  varnish_hit_rate
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_hit_rate'
Error: client_req not part of varnishstat.
Error: cache_hit not part of varnishstat.
Error: cache_miss not part of varnishstat.
Error: cache_hitpass not part of varnishstat.
root@disp5874:~# munin-run --debug --pidebug  varnish_memory_usage
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/z-varnish
# Setting /rgid/ruid/ to /123/0/
# Setting /egid/euid/ to /123 123/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_memory_usage'
Error: sma_nbytes not part of varnishstat.
Error: sms_nbytes not part of varnishstat.
SMA_Transient_g_bytes.value 0
SMA_s0_g_bytes.value 0
Error: 

Bug#959759: dgit-maint-merge(7): Mention --allow-unrelated-histories

[Ian Jackson]

Sean Whitton writes ("Bug#959759: dgit-maint-merge(7): Mention 
--allow-unrelated-histories"):
> Is this what you mean:
> 
> % dgit clone libopencsd
> % cd libopencsd
> % # add and fetch upstream remote
> % git merge -s ours --allow-unrelated-histories v0.14.0
> % git merge v0.14.1
> 
> This is better than my patch.  If you could confirm, I can prepare a new
> patch.

Yes.

There are still possible problems: if 0.14.0-whatever.dsc was made out
of some upstream 0.14.0.tar.gz which has extra stuff in it (autotools
output, or whatever) then this approach leaves you with 0.14.0's
autotools output (because it looks to git like you added it!)  but
0.14.1's autotools input.  So this only works well if the 0.14.0
Debian branch you start with was made from something which looks like
upstream git.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#904339: what's the current state of jhdf?

[Hongzhuo Liang]

Hi,

What's the current state of jhdf?

Is there anyone to maintain it?

Bug#959812: Acknowledgement (munin-plugins-core: varnish_ plugin no output (X not part of varnishstat))

[root]

This bug applies to all "aspects" of the munnin "varnish_" plugin. None of them 
produce any data in their graphs OOTB on Debian 10.

fwiw, `varnishstat` clearly *does* have output for 'uptime':

```
root@disp7450:~# varnishstat -x | grep -iC4 uptime



MGT.uptime
4961
c
d
Management process uptime


MGT.child_start
1
--
i
stat summ operations


MAIN.uptime
4961
c
d
Child process uptime


MAIN.sess_conn
0
root@disp7450:~# 
```

Could this be an issue with varnish changing from v5 to v6 from Debian 9 to 
Debian 10?

 * https://packages.debian.org/source/stretch/varnish
 * https://packages.debian.org/source/buster/varnish

On Tue, May 05, 2020 at 04:51:02PM +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 959812: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Munin Debian Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 959...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 959812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#959812: munin-plugins-core: varnish_ plugin no output (X not part of varnishstat)

[root]

Package: munin-plugins-core
Version: 2.0.49-1
Severity: important



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

Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.49-1
ii  perl  5.28.1-6

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-5

Versions of packages munin-plugins-core suggests:
pn  acpi | lm-sensors 
pn  conntrack 
pn  default-mysql-client  
ii  ethtool   1:4.19-1
ii  hdparm9.58+ds-1
pn  libcache-cache-perl   
pn  libdbd-mysql-perl 
pn  libdbd-pg-perl
ii  libhttp-date-perl 6.02-1
pn  liblwp-useragent-determined-perl  
pn  libnet-dns-perl   
pn  libnet-ip-perl
pn  libnet-irc-perl   
pn  libnet-ldap-perl  
pn  libnet-netmask-perl   
pn  libnet-telnet-perl
ii  libxml-parser-perl2.44-4
pn  libxml-simple-perl
pn  logtail   
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python3   3.7.3-1
ii  ruby  1:2.5.1
pn  smartmontools 

-- no debconf information

Steps to reproduce. First setup depends:

```
sudo su -
apt-get install varnish munin
echo -e '\n[varnish*]\nuser root\n' > /etc/munin/plugin-conf.d/z-varnish
```

Then running the 'varish_' plugin with the 'uptime' aspect produces nothing.


```
root@mail:/etc/munin# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/zzz-myconf
# Setting /rgid/ruid/ to /118/0/
# Setting /egid/euid/ to /118 118/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
root@mail:/etc/munin#
```

But if I manually edit the 'varnish_' script to set DEBUG=1, then it says:

```
root@mail:/etc/munin# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/zzz-myconf
# Setting /rgid/ruid/ to /118/0/
# Setting /egid/euid/ to /118 118/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
Error: uptime not part of varnishstat.
root@mail:/etc/munin#
```

Bug#959811: apparmor: Failed to start Load AppArmor profiles

[Marco]

Package: apparmor
Version: 2.13.4-1+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I was getting an error message when starting apparmor:

# systemctl status apparmor.service

● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Tue 2020-05-05 13:02:26 -03; 2min 
3s ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
   Main PID: 6936 (code=exited, status=1/FAILURE)

systemd[1]: Starting Load AppArmor profiles...
apparmor.systemd[6936]: Restarting AppArmor
apparmor.systemd[6936]: Reloading AppArmor profiles
apparmor.systemd[6955]: AppArmor parser error for /etc/apparmor.d in 
/etc/apparmor.d/abstractions/authentication at line 49: Could not open 
'abstractions/smbpass'
apparmor.systemd[7039]: AppArmor parser error for 
/etc/apparmor.d/usr.sbin.cupsd in /etc/apparmor.d/abstractions/authentication 
at line 49: Could not open 'abstractions/sm>
apparmor.systemd[6936]: Error: At least one profile failed to load
systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: apparmor.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Load AppArmor profiles.



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

Modified /etc/apparmor.d/abstractions/smbpass

But I don't know if this is Ok for everyone (or even for me). I just took a 
lucky guess.

This is the file now:

# vim:syntax=apparmor
# --
#
#Copyright (C) 2009 Canonical Ltd.
#
#This program is free software; you can redistribute it and/or
#modify it under the terms of version 2 of the GNU General Public
#License published by the Free Software Foundation.
#
# --

  # libpam-smbpass/pam_smbpass.so permissions
#  /var/lib/samba/*.[lt]db rwk,
   /var/lib/samba/*.tdb rwk,


   * What was the outcome of this action?

No errors.

# systemctl status apparmor.service 
● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: active (exited) since Tue 2020-05-05 13:30:58 -03; 2s ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 9800 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=0/SUCCESS)
   Main PID: 9800 (code=exited, status=0/SUCCESS)

systemd[1]: Starting Load AppArmor profiles...
apparmor.systemd[9800]: Restarting AppArmor
apparmor.systemd[9800]: Reloading AppArmor profiles
systemd[1]: Finished Load AppArmor profiles.

I don't post this as a patch, because I'm not sure if it is. But this is how I 
managed to get apparmor running. Probably there's something more correct to do 
in this case.

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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.30-4
ii  lsb-base   11.1.0
ii  python33.8.2-3

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
pn  apparmor-utils   

-- Configuration Files:
/etc/apparmor.d/abstractions/smbpass changed:
  # libpam-smbpass/pam_smbpass.so permissions
   /var/lib/samba/*.tdb rwk,


-- debconf information excluded

Bug#954645: closed by Lucas Nussbaum (unreproducible FTBFS)

[Sebastiaan Couwenberg]

Control: tags -1 patch

On Fri, 3 Apr 2020 21:40:10 +0200 Lucas Nussbaum wrote:
> > I'm closing those bugs: those failures are no longer reproducible,
> > checking again 12 hours later. Either they were caused by another
> > package that was fixed in the meantime, or they are random failures.
> 
> Actually, this is reproducible.

It seems to be reproducible only in specific environments. On my system
with cowbuilder it builds fine. But on the reproducible builds systems
with pbuilder you see the same test failures as you.

The attached patch should help, it adds build dependencies for the
modules required for tests, among them is pytest for which
ModuleNotFoundError exceptions were raised.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru behave-1.2.6/debian/control behave-1.2.6/debian/control
--- behave-1.2.6/debian/control 2020-01-25 13:57:18.0 +0100
+++ behave-1.2.6/debian/control 2020-05-05 18:14:19.0 +0200
@@ -11,6 +11,8 @@
python3-nose,
python3-parse,
python3-parse-type,
+   python3-path,
+   python3-pytest,
python3-setuptools,
python3-six,
python3-sphinx,

Bug#959002: broadcom-sta-dkms: Wl driver 6.30.223.271 (r587334) failed with code 21

[Roger Shimizu]

control: notfixed -1 6.30.223.271-14
control: severity -1 important

Dear Gert,

Please CC me when you reply.
Thank you!

> bullseye:
> status installed broadcom-sta-dkms:all 6.30.223.271-14
> buster-backports:
> status installed broadcom-sta-dkms:all 6.30.223.271-14~bpo10+1
> This also did not work with same errors.
> At the buster-backports version I tried the command dpkg-reconfigure
> broadcom-sta-dkms , that gave same errors.
> Also restarts did not help.

I thought you worked well with previous version, but failed with new
version, so marked this ticket as grave.
Now I understand your report is not about a regression.
So lower the severity.

All hardware I have still work well with latest version
(6.30.223.271-14), so I think your hardware may be not supported by
this driver.
We cannot say whether a specific hardware is supported by this driver
or not, until we tried it.

> I have no idea this has some relation, but at April a new version of
> wireless-regdb is upgraded with lot of changes.

If you can modprobe the driver sucessfully, but have problem
connecting to some Wifi AP, it may be related to wireless-regdb.
So I don't think it matters for your case.

> I do not understand why this problem is marked as fixed at
> 6.30.223.271-14, because this just is the version I used when I got the
> problem.

Sorry, I mistook your problem for another one.
So I update the flag this time.

> Is my device not supported and broadcom-sta-dkms:all 6.30.223.271-14
> working without problem for other devices?

I guess so, and you'd better try other drivers listed on wiki:
- https://wiki.debian.org/bcm43xx
- https://wiki.debian.org/brcm80211
- https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx

> In that case perhaps the installation Wiki should be updated to show the
> exceptions?

I'm afraid that's not possible because only the hardware vendor can decide such.
And usually package maintainer don't have all hardware ..

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#959759: dgit-maint-merge(7): Mention --allow-unrelated-histories

[Sean Whitton]

Hello,

On Tue 05 May 2020 at 12:19PM +01, Ian Jackson wrote:

> I think git has pretty much always wanted --allow-unrelated-histories
> for this situation.  The safety catch is there to stop you
> accidentally making a frankenproject, but that doesn't apply here.

Actually only since 2016 (git 2.9).

> If the upstream directory had a debian/ directory I think this rune
> will do something strange to the resulting debian/.  In the general
> case I think the merge algorithm with unrelated histories is not
> correct for upstream files either; eg if you have made changes to
> upstream files something might go wrong.
>
> My approach in these situations is:
>   1. make a branch of the Debian package of the old upstream
>  (ie that has the contents corresponding to the Debian
>  package of the old upstream) but which has the right
>  upstream as an ancestor.
>  git merge -s ours --allow-unrelated-histories v0.14.0
>   2. git merge will now DTRT if we git merge v0.14.1 and do
>  a three-way merge

Is this what you mean:

% dgit clone libopencsd
% cd libopencsd
% # add and fetch upstream remote
% git merge -s ours --allow-unrelated-histories v0.14.0
% git merge v0.14.1

This is better than my patch.  If you could confirm, I can prepare a new
patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#959637: Please provide pristine-tar for libodsstream - or at least way to get upstream source (Was: Bug#959637: beads: FTBFS: build-dependency not installable: libodsstream-qt5-dev)

[Filippo Rusconi]

Greetings, Andreas,

I hope you are doing fine in these difficult times.

On Tue, May 05, 2020 at 02:25:58PM +0200, Andreas Tille wrote:

Hi Filippo,

I tried to investigate this issue of beads:

On Sun, May 03, 2020 at 02:34:20PM +0200, Lucas Nussbaum wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.
...
Relevant part (hopefully):
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: libodsstream-qt5-dev but it is 
not going to be installed


and checked the salsa repository of libodsstream[1].  I was running
routine-update on it and when it tried to build the package it was
unable to find the original source tarball in pristine-tar branch.
There is no watch file and I failed to find any other hint how to obtain
the upstream source.

Would you mind writing a working watch file or at least inject
pristine-tar to enable others building right from Salsa?


Thank you so much for your report. Yeah, I forgot to gbp import-orig. The git
repos I was working on did not have one, oddly enough.

I am currently fixing that issue. Will be uploading in the next minutes and
closing the bug, and pushing to salsa.

Now, the beads project depends on libodsstream, but Olivier failed to recall me
of it. So it almost certainly will fail using libodsstream because I have
totally rewritten the CMake build system. CMake dialect variable names most
probably differ in libodsstream and beads. 


I'll give a look at it.

Ciao
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#948228: bug 948228 is forwarded to https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/55

[Iain Lane]

On Tue, Mar 24, 2020 at 10:13:50AM +, Simon McVittie wrote:
> forwarded 948228 
> https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/55
> thanks

I've just uploaded 0.6.55-2 which is supposed to fix this bug (we were
getting a lot of people hitting it in Ubuntu when doing an upgrade to
focal). Please give it a go and let me know if it doesn't work for you.
Upstream we were wondering whether some more protection would be needed.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#959684: salt: CVE-2020-11651 and CVE-2020-11652

[Elimar Riesebieter]

There are official patches from saltstack available here:

2018.3.x 
2017.7.x 
2016.x.x 

I requested them via
https://www.saltstack.com/lp/request-patch-april-2020/

Please notice that there are more CVE' not fixed yet:

CVE-2019-17361 => 2016.11.2+ds-1+deb9u2 and 2018.3.4+dfsg1-6
CVE-2019-1010259 => 2016.11.2+ds-1+deb9u2
CVE-2018-15751 => 2016.11.2+ds-1+deb9u2

See https://security-tracker.debian.org/tracker/source-package/salt.

I asked saltstack for patches of those as well.

HTH
Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

Bug#959809: compiz-boxmenu FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: compiz-boxmenu
Version: 1.1.12-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

compiz-boxmenu fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. Please consider
applying the attached patch to make it substitutable.

Helmut
--- compiz-boxmenu-1.1.12.orig/Makefile
+++ compiz-boxmenu-1.1.12/Makefile
@@ -5,8 +5,10 @@
 	PREFIX?=/usr
 endif
 
+PKG_CONFIG ?= pkg-config
+
 # checking for python
-PYTHONBIN?=$(shell which python$(shell pkg-config --modversion python-2.7 2> /dev/null))
+PYTHONBIN?=$(shell which python$(shell $(PKG_CONFIG) --modversion python-2.7 2> /dev/null))
 PYTHONBIN?=$(shell which python2.6)
 PYTHONBIN?=$(shell which python2)
 
@@ -15,16 +17,16 @@
 endif
 
 # Set up compile flags
-CPPFLAGS := `pkg-config --cflags dbus-glib-1 gdk-3.0 gtk+-3.0 libwnck-3.0`
-CPPFLAGS_CLIENT := `pkg-config --cflags dbus-glib-1`
+CPPFLAGS := `$(PKG_CONFIG) --cflags dbus-glib-1 gdk-3.0 gtk+-3.0 libwnck-3.0`
+CPPFLAGS_CLIENT := `$(PKG_CONFIG) --cflags dbus-glib-1`
 WARNINGS := -Wall -Wextra -Wno-unused-parameter
 ifneq ("$(DEBUG)","")
 	CFLAGS := -O2 -g $(WARNINGS)
 else
 	CFLAGS := $(WARNINGS)
 endif
-LDFLAGS := -Wl,--as-needed `pkg-config --libs dbus-glib-1 gdk-3.0 gtk+-3.0 libwnck-3.0`
-LDFLAGS_CLIENT := -Wl,--as-needed `pkg-config --libs dbus-glib-1`
+LDFLAGS := -Wl,--as-needed `$(PKG_CONFIG) --libs dbus-glib-1 gdk-3.0 gtk+-3.0 libwnck-3.0`
+LDFLAGS_CLIENT := -Wl,--as-needed `$(PKG_CONFIG) --libs dbus-glib-1`
 
 VERSION=1.1.12
 

Bug#919490: reopening 919490

[Helmut Grohne]

Control: tags -1 - moreinfo

On Mon, Mar 30, 2020 at 03:12:21PM +0200, Rafael Laboissière wrote:
> Could you, please, be more precise about this?  As far as I can tell, the
> patch has indeed be applied upstream.  Could you please tell me if there is
> something in cross-build.patch that has been overlooked?

I'm attaching a patch with the remaining bits against praat/6.1.14-1
your convenience.

Helmut
--- praat-6.1.14.orig/makefiles/makefile.defs.chrome64
+++ praat-6.1.14/makefiles/makefile.defs.chrome64
@@ -7,17 +7,19 @@
 
 CXX = g++
 
-COMMONFLAGS = -DUNIX -Dlinux -Dchrome -DALSA -DHAVE_PULSEAUDIO -D_FILE_OFFSET_BITS=64 `pkg-config --cflags gtk+-2.0` -Wreturn-type -Wunused -Wunused-parameter -Wuninitialized -O3 -g1 -pthread
+PKG_CONFIG ?= pkg-config
+
+COMMONFLAGS = -DUNIX -Dlinux -Dchrome -DALSA -DHAVE_PULSEAUDIO -D_FILE_OFFSET_BITS=64 `$(PKG_CONFIG) --cflags gtk+-2.0` -Wreturn-type -Wunused -Wunused-parameter -Wuninitialized -O3 -g1 -pthread
 
 CFLAGS = -std=gnu99 $(COMMONFLAGS) -Werror=missing-prototypes -Werror=implicit
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat
 
-LIBS = `pkg-config --libs gtk+-2.0` -lm -lpulse -lasound -lpthread
+LIBS = `$(PKG_CONFIG) --libs gtk+-2.0` -lm -lpulse -lasound -lpthread
 
 AR = ar
 RANLIB = ls
--- praat-6.1.14.orig/makefiles/makefile.defs.cygwin64
+++ praat-6.1.14/makefiles/makefile.defs.cygwin64
@@ -14,7 +14,7 @@
 
 CXXFLAGS = -std=gnu++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = Praat.exe
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.alsa
+++ praat-6.1.14/makefiles/makefile.defs.linux.alsa
@@ -15,7 +15,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.barren
+++ praat-6.1.14/makefiles/makefile.defs.linux.barren
@@ -13,7 +13,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat_barren
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.jack
+++ praat-6.1.14/makefiles/makefile.defs.linux.jack
@@ -15,7 +15,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.nogui
+++ praat-6.1.14/makefiles/makefile.defs.linux.nogui
@@ -15,7 +15,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat_nogui
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.rpi
+++ praat-6.1.14/makefiles/makefile.defs.linux.rpi
@@ -15,7 +15,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat
 
--- praat-6.1.14.orig/makefiles/makefile.defs.linux.silent
+++ praat-6.1.14/makefiles/makefile.defs.linux.silent
@@ -15,7 +15,7 @@
 
 CXXFLAGS = -std=c++17 $(COMMONFLAGS) -Wshadow
 
-LINK = g++
+LINK = $(CXX)
 
 EXECUTABLE = praat
 

Bug#959810: Font color for Arc Lighter variant is grayish

[Camaleón]

Package: arc-theme
Version: 20190917+git20200328-2
Severity: wishlist

Dear maintainer,

The text color for Arc Lighter is too bright/light to be readable. Looks
like if it were grayed out and thus very hard to read (see attached 
image).

This was a common complaint for the original project¹ but it seems the 
issue is still present on the forked one.

I understand this is a very personal setting but, could it be possible 
for Debian package, to allow users select the color pattern to use for 
every of the arc-themes variants?

I personally really like texts to be in pure black (#00) but usability
or other reasons could make it not convenient. 

¹ https://github.com/horst3180/arc-theme/issues/406

Greetings,

-- 
Camaleón 

Bug#959808: linpsk FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: linpsk
Version: 1.3.5-1.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

linpsk fails to cross build from source, because the upstream .pro file
hard codes the build architecture pkg-config instead of using the
pkg-config integration provided by qmake. Please consider applying the
attached patch to fix that.

Helmut
--- linpsk-1.3.5.orig/linpsk.pro
+++ linpsk-1.3.5/linpsk.pro
@@ -35,7 +35,7 @@
 LIBS += -lasound -lfftw3
 
 message(LinPSK builds with hamlib)
-LIBS +=$$system("pkg-config --libs hamlib")
+PKGCONFIG += hamlib
 DEFINES += WITH_HAMLIB
 HEADERS +=src/rigcontrol.h
 SOURCES +=src/rigcontrol.cpp

Bug#949222: Bug#959684: salt: CVE-2020-11651 and CVE-2020-11652

[Simon McVittie]

On Tue, 05 May 2020 at 17:37:53 +0200, Salvatore Bonaccorso wrote:
> Do you have respective stretch and buster setups which you could
> expose those packages to?

Sorry, no: the owner of the machines I was looking at asked me to switch
over to upstream's packages.

smcv

Bug#959587: python-biopython: FTBFS: AssertionError: False is not true

[Aaron M. Ucko]

Andreas Tille  writes:

> I've checked ncbi-blast+ and your last upload does not seem to be
> pushed.

AFAICT, it's all properly at https://salsa.debian.org/med-team/ncbi-blastplus.

> Since there is a strong relation in time with your upload and this
> FTBFS of biopython do you think that this could be connected:

Yes, per https://www.ncbi.nlm.nih.gov/books/NBK131777/, the upgrade to
2.10.0 changed the default database version (controlled by makeblastdb's
-blastdb_version flag) from 4 to 5, causing some output files to change
names (and formats):

*.nsd -> *.nnd
*.nsi -> *.nni
*.psd -> *.pnd
*.psi -> *.pni

Thanks for checking!

BTW, python-biopython's build dependency on emboss reminded me that
emboss-data is still probably overkill for emboss(-lib)'s needs and
could stand to be split up (#682042).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#959684: Bug#949222: Bug#959684: salt: CVE-2020-11651 and CVE-2020-11652

[Salvatore Bonaccorso]

Hi Simon,

On Tue, May 05, 2020 at 03:01:45PM +0100, Simon McVittie wrote:
> On Mon, 04 May 2020 at 01:34:33 +0200, Guilhem Moulin wrote:
> >   CVE-2020-11651
> >   CVE-2020-11652
> 
> I found myself needing to mitigate this for a salt deployment, so I
> tried backporting the upstream patches to buster.
> 
> The attached are not at all thoroughly-tested and should be reviewed
> carefully by someone who knows the codebase, but they seem to work, and
> the proof-of-concept from
> https://github.com/rossengeorgiev/salt-security-backports no longer reports
> that the master is vulnerable. This was only a stopgap, because that
> deployment is now using the packages from saltstack.com instead, but it
> might be useful to the salt maintainers.
> 
> There are also unofficial backports in
> https://github.com/rossengeorgiev/salt-security-backports - I tried doing
> the cherry-picks myself and then compared what I got with those, in an
> attempt to guard against mistakes (by either myself or the author of those
> backports).
> 
> Note that patch 0003 contains unofficial workarounds for regressions in the
> release that fixed those CVEs, which you might prefer to exclude from an
> official update.

I did actually work on that already yesterday and uploaded the
attached debdiffs to security-master *but* I'm in need of someone
using salt to effectively ina good way to test them. 

Do you have respective stretch and buster setups which you could
expose those packages to?

Regards,
Salvatore
diff -Nru salt-2016.11.2+ds/debian/changelog salt-2016.11.2+ds/debian/changelog
--- salt-2016.11.2+ds/debian/changelog  2018-04-20 14:33:54.0 +0200
+++ salt-2016.11.2+ds/debian/changelog  2020-05-04 14:29:16.0 +0200
@@ -1,3 +1,14 @@
+salt (2016.11.2+ds-1+deb9u3) stretch-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Address CVE-2020-11651 and CVE-2020-11652 (Closes: #959684)
+Thanks to Daniel Wozniak 
+  * Add note about log messages to hardening salt docs
+  * salt-api NET API with the ssh client enabled is vulnerable to command
+injection (CVE-2019-17361) (Closes: #949222)
+
+ -- Salvatore Bonaccorso   Mon, 04 May 2020 14:29:16 +0200
+
 salt (2016.11.2+ds-1+deb9u2) stretch; urgency=medium
 
   * Fix CVE-2017-8109: salt-ssh minion copied over configuration from the
diff -Nru 
salt-2016.11.2+ds/debian/patches/Add-note-about-log-messages-to-hardening-salt-docs.patch
 
salt-2016.11.2+ds/debian/patches/Add-note-about-log-messages-to-hardening-salt-docs.patch
--- 
salt-2016.11.2+ds/debian/patches/Add-note-about-log-messages-to-hardening-salt-docs.patch
   1970-01-01 01:00:00.0 +0100
+++ 
salt-2016.11.2+ds/debian/patches/Add-note-about-log-messages-to-hardening-salt-docs.patch
   2020-05-04 14:29:16.0 +0200
@@ -0,0 +1,41 @@
+From: "Daniel A. Wozniak" 
+Date: Mon, 13 Apr 2020 07:01:07 +
+Subject: Add note about log messages to hardening salt docs
+Origin: 
https://github.com/saltstack/salt/commit/4631781376ddc9ee9d279f407ac3d0b78644fae7
+
+---
+ doc/topics/hardening.rst | 4 
+ salt/master.py   | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/doc/topics/hardening.rst b/doc/topics/hardening.rst
+index c645b84128e4..569ad654af69 100644
+--- a/doc/topics/hardening.rst
 b/doc/topics/hardening.rst
+@@ -57,6 +57,10 @@ Salt hardening tips
+   particularly sensitive minions. There is also :ref:`salt-ssh` or the
+   :mod:`modules.sudo ` if you need to further restrict
+   a minion.
++- Monitor specific security releated log messages. Salt ``salt-master`` logs
++  attempts to access methods which are not exposed to network clients. These 
log
++  messages are logged at the ``error`` log level and start with ``Requested
++  method not exposed``.
+ 
+ .. _salt-users: https://groups.google.com/forum/#!forum/salt-users
+ .. _salt-announce: https://groups.google.com/forum/#!forum/salt-announce
+diff --git a/salt/master.py b/salt/master.py
+index 7d1444cf1221..aae55f1828e1 100644
+--- a/salt/master.py
 b/salt/master.py
+@@ -1162,7 +1162,7 @@ class TransportMethods(object):
+ try:
+ return getattr(self, name)
+ except AttributeError:
+-log.error("Expose method not found: %s", name)
++log.error("Requested method not exposed: %s", name)
+ else:
+ log.error("Requested method not exposed: %s", name)
+ 
+-- 
+2.20.1
+
diff -Nru 
salt-2016.11.2+ds/debian/patches/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2016.11.2.patch
 
salt-2016.11.2+ds/debian/patches/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2016.11.2.patch
--- 
salt-2016.11.2+ds/debian/patches/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2016.11.2.patch
  1970-01-01 01:00:00.0 +0100
+++ 
salt-2016.11.2+ds/debian/patches/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2016.11.2.patch
  2020-05-04 14:29:16.0 +0200
@@ -0,0 +1,237 @@
+From 006219501bbb3a81a9fb64975035011016d5a7eb Mon Sep 17 

Bug#959364: PR with patch

[Gard Spreemann]

Oops, I was a bit careless. Let me clarify: the patch in my PR is not
from the actual upstream for the package, but rather from the fork [1]
linked to by Thomas Koch in #959729 [2].

[1] https://github.com/teleshoes/acpi_call

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959729#10

Bug#948706: greylistd: python3 version fails to start - conversion from python 2 very broken

[Benedikt Spranger]

Followup-For: Bug #948706
Package: greylistd
Version: 0.8.8.8
Tags: patch

Hi,
I run into the very same problems while setting up a system. Since I
found some spare cycles I looked at the code and made some patches.

For simpler development I have set up a git repo and have import the
packages found on snapshots.debian.org to provide a package history.

You can find the git repo under 

https://github.com/eurovibes/greylistd

Regards
Bene Spranger
>From 376957c38203c951b9b6071c4ebfc13139d3ab2c Mon Sep 17 00:00:00 2001
From: Benedikt Spranger 
Date: Mon, 4 May 2020 00:25:24 +0200
Subject: [PATCH 01/10] Conciliate indentation

greylistd-setup-exim4 fail with
TabError: inconsistent use of tabs and spaces in indentation

Untabify greylistd-setup-exim4.

Signed-off-by: Benedikt Spranger 
---
 program/greylistd-setup-exim4 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/program/greylistd-setup-exim4 b/program/greylistd-setup-exim4
index a8c467a..821670c 100755
--- a/program/greylistd-setup-exim4
+++ b/program/greylistd-setup-exim4
@@ -1,7 +1,7 @@
 #!/usr/bin/python3
 
-### FILE:	greylist-setup-exim4
-### PURPOSE:	Add a greylisting statement to Exim 4 configuration file
+### FILE:   greylist-setup-exim4
+### PURPOSE:Add a greylisting statement to Exim 4 configuration file
 
 
 from sys   import version, stdin, stderr, argv, exit
@@ -251,7 +251,7 @@ def exim4_configure (lines, aclname, options):
 try:
 netmask = int(options["netmask"])
 except:
-	nmstring=options["netmask"]
+nmstring=options["netmask"]
 raise RuntimeError("Invalid netmask size: '%(nmstring)s'"%vars())
 ### org   raise "Invalid netmask size: '%s'"%options["netmask"]
 
-- 
2.26.0.rc2

>From 5265e1c4c346567334d10370f0f81c366e3a865f Mon Sep 17 00:00:00 2001
From: Benedikt Spranger 
Date: Mon, 4 May 2020 14:55:55 +0200
Subject: [PATCH 02/10] Ensure python 3.6 or greater

The greylistd package switched to Python 3 and uses some features
introduced in Python 3.6. Update the version check to fit.

Signed-off-by: Benedikt Spranger 
---
 program/greylistd-setup-exim4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/program/greylistd-setup-exim4 b/program/greylistd-setup-exim4
index 821670c..5ddc1fa 100755
--- a/program/greylistd-setup-exim4
+++ b/program/greylistd-setup-exim4
@@ -10,8 +10,8 @@ from osimport listdir, spawnl, P_WAIT
 from reimport compile
 
 ### Ensure that we can run this program
-if version < "2.3":
-stderr.write("This program requires Python 2.3 or newer\n")
+if version < "3.6":
+stderr.write("This program requires Python 3.0 or newer\n")
 exit(1)
 
 
-- 
2.26.0.rc2

>From ed347398c93602b59e4dcea0998d9f13cc6447f1 Mon Sep 17 00:00:00 2001
From: Benedikt Spranger 
Date: Mon, 4 May 2020 00:56:36 +0200
Subject: [PATCH 03/10] Remove trailing whitespaces

Perform a overall code cleanup by removing trailing whitespaces.
No functional change.

Signed-off-by: Benedikt Spranger 
---
 program/greylist  |  4 +---
 program/greylistd | 24 +++-
 program/greylistd-setup-exim4 | 12 ++--
 3 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/program/greylist b/program/greylist
index 2603a33..88050d8 100755
--- a/program/greylist
+++ b/program/greylist
@@ -46,7 +46,6 @@ sockfile = "/var/run/greylistd/socket"
 commands = ("add", "delete", "check", "update",
 "stats", "list",  "clear", "save",
 "reload", "mrtg")
-
 
 
 def usage (progname, message=None):
@@ -114,7 +113,6 @@ elif not action in commands:
 usage(progname, "Invalid action: '%s'"%action)
 
 
-
 confParser = ConfigParser()
 confParser.read(conffile)
 try:
@@ -149,7 +147,7 @@ while stat:
 
 except IOError:
 break
-
+
 else:
 if not firstword and stat.strip():
 firstword = stat.split(None, 1)[0]
diff --git a/program/greylistd b/program/greylistd
index 58348b6..906dfab 100755
--- a/program/greylistd
+++ b/program/greylistd
@@ -3,10 +3,10 @@
 ### FILE:	greylistd.py
 ### PURPOSE:	Simple greylisting daemon.  See "greylistd(8)".
 ###		For an introduction to greylisting, see:
-### 		http://projects.puremagic.com/greylisting/
+###		http://projects.puremagic.com/greylisting/
 ###
-### 		This program listens for connections on a UNIX domain
-###		socket, presumably from an MTA such as Exim.  Nominally, 
+###		This program listens for connections on a UNIX domain
+###		socket, presumably from an MTA such as Exim.  Nominally,
 ###		it reads an identifier (referred to as a "triplet"),
 ###		and returns a single word ("white" or "grey") depending
 ### on prior knowledge of said identifier.
@@ -270,7 +270,7 @@ def saveToFile (datafile, dictionary, perm=0600):

Bug#959786: [Pkg-javascript-devel] Bug#959786: node-execa: Please remove dependency to node-cross-spawn

[Xavier]

Le 05/05/2020 à 13:36, y...@debian.org a écrit :
> Package: node-execa
> Severity: important
> Control: block 958403 by -1
> 
> node-cross-spawn reimplement builtin Node.js functions
> child_process.sync and child_process.spawnSync compatible with
> Windows.
> 
> This package has also some security holes. Please patch code to
> replace `cross-spawn.spawn` by `child_process.sync` 

Not so easy here, execa uses internal cross-spawn libraries to parse
arguments and uses childProcess.spawn to launch process