Bug#948295: python-dateutils's autopkg tests fail / Update to 2.8.1 for Python 3.8

[Guido Günther]

Hi,
On Tue, Mar 31, 2020 at 03:59:28PM +0200, Thomas Goirand wrote:
> Hi!
> 
> Please accept and upload the merge request over her adressing this bug:
> 
> https://salsa.debian.org/agx/python-dateutil/-/merge_requests/1

That one would not build for me since the patches weren't rebased and the
so i just fixed it up myself. Uploaded now, sorry for the delay.
 -- Guido

> 
> Alternatively, ping me to NMU.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

Bug#956012: debian-edu-config: use DuckDuckGo as Chromium's default search provider

[Mike Gabriel]

Package: chromium
Severity: wishlist

Currently (during the bullseye release cycle), chromium uses Google as  
the default search provider.


With the below snippet dropped into  
/etc/chromium/policies/managed/.json we could switch that to  
DuckDuckGo:


{
   "DefaultSearchProviderEnabled":true,
   "DefaultSearchProviderName": "DuckDuckGo",
   "DefaultSearchProviderIconURL":"https://duckduckgo.com/favicon.ico";,
   "DefaultSearchProviderEncodings":["UTF-8"],
   "DefaultSearchProviderSearchURL":"https://duckduckgo.com/?q={searchTerms}";,

"DefaultSearchProviderSuggestURL":"https://duckduckgo.com/ac/?q={searchTerms}&type=list";,

   "DefaultSearchProviderNewTabURL":"https://duckduckgo.com/chrome_newtab";,
}

Maybe an option for Chromium in Debian?

Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp3ClXf3WGNi.pgp
Description: Digitale PGP-Signatur

Bug#956014: new upstream LTS version

[Harald Dunkel]

Package: lxc
Version: 1:3.1.0+really3.0.4-2

Upstream announced new LTS versions for LXC, LXCFS and LXD, see
https://lists.linuxcontainers.org/pipermail/lxc-users/2020-April/015198.html

Do you think it would be possible to upgrade the lxc and lxcfs packages
for sid? I would be glad to help.


Regards
Harri

Bug#956013: Fails to install

[David Prévot]

Package: manpages-fr-dev
Version: 4.0.0-2
Severity: serious

Hi,

Thanks for updating those translations. Unfortunately, there is an
unhandled upgrade path (missing Breaks and Replace on manpages-fr-extra
(<< 20151231something), and of course the manpages-fr-extra counterpart
update).

> Preparing to unpack .../manpages-fr-dev_4.0.0-2_all.deb ...
> Unpacking manpages-fr-dev (4.0.0-2) over (3.65d1p1-1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/manpages-fr-dev_4.0.0-2_all.deb (--unpack):
>  trying to overwrite '/usr/share/man/fr/man3/libblkid.3.gz', which is also in 
> package manpages-fr-extra 20151231
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/manpages-fr-dev_4.0.0-2_all.deb
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Regards

David


signature.asc
Description: PGP signature

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[GCS]

On Wed, Apr 1, 2020 at 1:39 AM László Böszörményi (GCS)  wrote:
> On Tue, Mar 31, 2020 at 8:12 PM Pirate Praveen  
> wrote:
> > dh_missing --list-missing
> > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so exists in
> > debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9 exists in
> > debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9.0.0 exists in
> > debian/tmp but is not installed to anywhere
> > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.a exists in
> > debian/tmp but is not installed to anywhere
>  Reason is simple. It's an _external_ project and does _not_ needed in
> Sid / Bullseye as those use the normal protobuf packages.
> Please see that it's a third_party library[1] in gRPC, developed
> independently[2] and that it's _not_ a full implementation (but a
> micro, subset one)[3].
 Just for the record, I've packaged upb [4] if you might need it for
something. It's in the NEW queue as well, hopefully it will be
accepted soon.
Still no intention to ship it from gRPC, especially that your problem
lies elsewhere, in dh_dwz.

Regards,
Laszlo/GCS
[4] dget -x http://www.barcikacomp.hu/gcs/upb_0.0.0~git200311-1.dsc

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[GCS]

On Wed, Apr 1, 2020 at 6:33 AM Pirate Praveen  wrote:
>dh_dwz
> dwz: Too few files for multifile optimization
> objcopy: 
> 'debian/libgrpc9/usr/lib/debug/.dwz/x86_64-linux-gnu/libgrpc9.debug': No such 
> file
> dh_dwz: objcopy --compress-debug-sections 
> debian/libgrpc9/usr/lib/debug/.dwz/x86_64-linux-gnu/libgrpc9.debug returned 
> exit code 1
 As noted by Niels and you can see yourself, the failure comes from
dh_dwz. According to his note[1], a dh_dwz override with the switch
'--no-dwz-multifile' can be the solution.

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933541#10

Bug#955717: RM: lambda-align2/stable [arm64 armel armhf i386 mips64el ppc64el s390x] -- ROM; Does not yet build correctly on non-amd64

[Juhani Numminen]

reassign 955717 release.debian.org
user release.debian@packages.debian.org
usertags 955717 rm
stop

On Sat, 04 Apr 2020 09:29:06 +0200 "Michael R. Crusoe" 
 wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> See also: https://bugs.debian.org/953081 and https://bugs.debian.org/955363

I'm reassigning this bug to the Release Managers per
.

Cheers,
Juhani

Bug#956011: netfilter: pkttype broadcast cant be matched in OUTPUT chain (INPUT works)

[Simon H]

Package: netfilter
Version: nftables
Severity: important

Dear Maintainer,

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

im trying to filter broadcasts with netfilter in the output chain. input is 
workiing with pkttype broadcast, but on output i get no matches. i tested that 
by using the destination addr 255.255.255.255 for catching broadcasts and that 
works. basically im trying to allow DHCP communication (the broadcast part)

you can easily test this by inserting those rules directly at the top of output 
chain f.e. (on input it works)
rule: nft add rule inet t1 c_output oifname ${zone_dev} meta pkttype { 
broadcast, multicast} counter goto ${zone_out}

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


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

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

Bug#955301: sympa: archived broken after upgrade to debian 9 - Command /usr/bin/mhonarc failed with exit code 255

[Stefan Hornburg (Racke)]

On 4/4/20 5:56 PM, Christophe Moille wrote:
> Le vendredi 03 avril 2020 à 11:28:42 (+0200), Stefan Hornburg (Racke) a écrit 
> :
>> On 4/3/20 11:22 AM, Christophe Moille wrote:
>>> Le vendredi 03 avril 2020 à 10:50:11 (+0200), Stefan Hornburg (Racke) a 
>>> écrit :

 Hello Christophe,

 /usr/sbin/mhonarc should use the scripts located in /usr/share/mhonarc, so 
 it looks like
 your local (Perl) setup causes the problems.

 Regards
>>>
>>> I used `/usr/lib/sympa/bin/sympa_wizard.pl --check` on my instance when
>>> it was debian 8, and I have executed again when debian 9.
>>>
>>> Maybe that's a contribution to the problem. Is there knowed problems
>>> with this script on debian 9 ?
>>>
>>
>> Yes, that sounds like a reasonable explanation for your problem. I suggest 
>> to remove these Mhonarc scripts
>> from /usr/local/share/perl/5.24.1.
> 
> I dunno if it's a good solution but this modification fixed the problem:
> 
> added line in /usr/sbin/mhonarc l37 before unshift(@INC, 'lib');
> 
> unshift(@INC, '/usr/share/mhonarc/');
> 
> 

OK, so from my point of view this is a local problem and sympa_wizard --check 
doesn't make much
sense for a Debian package installation. So I'm going to close this bug. Please 
contact Sympa
mailing list if you need more assistance.

Regards
   Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



signature.asc
Description: OpenPGP digital signature

Bug#956004: mesa: Please build Mesa agaisng llvm 10

[Timo Aaltonen]

On 6.4.2020 1.03, Shmerl wrote:
> Source: mesa
> Severity: wishlist
> 
> Dear Maintainer,
> 
> llvm 10 has various fixes that affect AMD Navi cards, that apparently were not
> backported to llvm 9 series. llvm 9 is causing desktop hangs on Navi cards 
> even
> with Mesa 20.x. Please build Mesa in Debian unstable / testing using llvm 10.

Sure, if only it would build:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955531
https://bugs.llvm.org/show_bug.cgi?id=44870



-- 
t

Bug#956010: zpb-ttf: Packaging licensing should be changed

[Joao Eriberto Mota Filho]

Source: zpb-ttf
Severity: normal

The zpb-ttf is under BSD-2-Clause but the packaging is under GPL-2+ license.
GPL-2 in packaging is incompatible with the upstream development if needed
send patches to the author.

I am opening this bug with a CC to previous maintainer in Debian to ask if
someone has any objection to change the licensing in Debian packaging
(to BSD-2-Clause). IMO, this is the best option to interact with the upstream.

I will wait 10 days to know if anyone has any objection.

Thanks!

Regards,

Eriberto

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Drew Parsons]

On 2020-04-06 09:56, Drew Parsons wrote:

On 2020-04-06 01:48, Gilles Filippini wrote:

Drew Parsons a écrit le 05/04/2020 à 18:57 :


Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if 
"mpirun

-n 1 dh_auto_build" or a variation of that is viable.  Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild


This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:

I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now 
abort,

***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not 
able

to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit 
code=1:

cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13

But the HDF5 error is no more present with python3.7. So it seems a 
good

point.



Strange again.  I would have expected the same behaviour in python3.8
and python3.7, whether successful or unsuccessful.



Putting dh into mpirun seems to be interfering with process spawning.  
Once MPI is initialised (for the python3.7 test) it's not reinitialised 
for the python3.8 and so it's in a bad state for the test. Something 
like that.


It's only in the tests where h5py is invoked that we get the problems. 
This variant works, applying mpirun separately for each test run:


override_dh_auto_test:
set -e; \
for py in `py3versions -s -v`; do \
  mpirun -n 1 pybuild --test -i python{version} -p $$py; \
done

(could use mpirun -n $(NPROC) for real mpi testing).

Do we want to use this as a solution? Or would you prefer an environment 
variable that h5py can check to allow mpi invocation on a serial 
process?



Note that this means bitshuffle as built now is expressly tied in with 
hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and 
debian/control, though the Build-Depends must be updated to 
python3-h5py-mpi).  It's a separate question whether it's desirable to 
also support a hdf5-serial build of bitshuffle.  Likewise we need to 
think about what we want to happen when bitshuffle is invoked in a 
serial process.


I think part of the confusion here is that bitshuffle (at least in the 
tests) is double-handling the HDF5 library, with direct calls on the one 
hand, but indirectly through h5py as well, on the other hand.

Bug#956009: gvfs: Nautilus not mounting filesystems in /run/user/1000/gvfs

[Bill Wohler]

Package: gvfs
Version: 1.44.1-1
Severity: important

Since a recent upgrade to bullseye from stretch, navigating to a remote
Samba directory via Nautilus or running "gio mount smb://server/share"
no longer creates a mount point in /run/user/1000/gvfs.

I found [1] which may be helpful. There's a glib packaging fix suggested
at the end. I tried the suggested workaround [2] to no avail. I didn't
find a Debian glib package. The closest I found was
glib-networking:amd64, 2.64.1-1.

1. https://github.com/NixOS/nixpkgs/issues/50254
2. systemctl --user stop gvfs-daemon

I marked this important since my scripts that depend on this directory
are broken until the directory is populated, or I read some
documentation that points out that the mounts can be found elsewhere. So
far, all of the documentation points to /run/user/1000/gvfs or
$XDG_RUNTIME_DIR/gvfs, which is empty.

In case it is useful, here are some diagnostics after running [2]
and mounting a remote filesystem in nautilus.

[wohler@olgas doc]$ systemctl --user stop gvfs-daemon
[Mount somedirectory from somehostname in Nautilus.]
[/var/log/syslog]
Apr  5 10:50:59 olgas systemd[3267]: Stopping Virtual filesystem service...
Apr  5 10:50:59 olgas systemd[3267]: gvfs-daemon.service: Succeeded.
Apr  5 10:50:59 olgas systemd[3267]: Stopped Virtual filesystem service.
Apr  5 10:51:20 olgas dbus-daemon[7865]: [session uid=1000 pid=7865] 
Activating via systemd: service name='org.gtk.vfs.Daemon' 
unit='gvfs-daemon.service' requested by ':1.140' (uid=1000 pid=14616 comm="gio 
mount --list ")
Apr  5 10:51:20 olgas systemd[3267]: Starting Virtual filesystem service...
Apr  5 10:51:20 olgas dbus-daemon[7865]: [session uid=1000 pid=7865] 
Successfully activated service 'org.gtk.vfs.Daemon'
Apr  5 10:51:20 olgas systemd[3267]: Started Virtual filesystem service.

[Starting Nautilus]
Apr  5 10:54:05 olgas dbus-daemon[7865]: [session uid=1000 pid=7865] 
Activating service name='org.gnome.Nautilus' requested by ':1.39' (uid=1000 
pid=8340 comm="/usr/bin/gnome-shell ")
Apr  5 10:54:05 olgas dbus-daemon[7865]: [session uid=1000 pid=7865] 
Successfully activated service 'org.gnome.Nautilus'
Apr  5 10:54:05 olgas org.gnome.Nautilus[14669]: Initializing 
nautilus-dropbox 2019.02.14
Apr  5 10:54:05 olgas dbus-daemon[679]: [system] Activating via systemd: 
service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.1969' (uid=1000 
pid=14669 comm="/usr/bin/nautilus --gapplication-service ")
Apr  5 10:54:05 olgas systemd[1]: Starting Hostname Service...
Apr  5 10:54:05 olgas dbus-daemon[679]: [system] Successfully activated 
service 'org.freedesktop.hostname1'
Apr  5 10:54:05 olgas systemd[1]: Started Hostname Service.

[Navigating to Samba filesystem.]
[No output in /var/log/syslog.]

[wohler@olgas ~]$ gio mount --list
...
Mount(1): public on  -> smb://somehostname/somedirectory>/
  Type: GDaemonMount

[wohler@olgas ~]$ ls /run/user/1000/gvfs
[wohler@olgas ~]$ 

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

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

Versions of packages gvfs depends on:
ii  gvfs-common   1.44.1-1
ii  gvfs-daemons  1.44.1-1
ii  gvfs-libs 1.44.1-1
ii  libc6 2.30-4
ii  libglib2.0-0  2.64.1-1

gvfs recommends no packages.

Versions of packages gvfs suggests:
ii  gvfs-backends  1.44.1-1

-- no debconf information

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Drew Parsons]

On 2020-04-06 01:48, Gilles Filippini wrote:

Drew Parsons a écrit le 05/04/2020 à 18:57 :


Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if "mpirun
-n 1 dh_auto_build" or a variation of that is viable.  Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild


This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:

I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now 
abort,

***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit 
code=1:

cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13

But the HDF5 error is no more present with python3.7. So it seems a 
good

point.



Strange again.  I would have expected the same behaviour in python3.8 
and python3.7, whether successful or unsuccessful.


We'll keep digging!

Drew

Bug#945544: lintian: Field too long doesn't report anything on the website

[Felix Lechner]

Hi Sylvestre,

On Tue, Nov 26, 2019 at 10:36 AM Sylvestre Ledru  wrote:
>
> https://lintian.debian.org/tags/field-too-long.html is empty while it should 
> return
> some results (oca-core, parl-desktop-world, some rust stuff)

Our website is still not working properly. Below please find a
database excerpt that shows the recent activity for your tag.

Right now, we only have it for main from unstable. Automatic debug
packages are also not yet included.

I hope this information is helpful to you. Sorry about the delay.

Kind regards
Felix Lechner

* * *

sqlite> select file.name, tag.hint from tag inner join file on file.id
= tag.file_id where tag.name = 'field-too-long';

consul_1.7.1+dfsg1-2_amd64.deb|Built-Using (5092 chars > 5000)
docker.io_19.03.6+dfsg1-2_amd64.deb|Built-Using (5014 chars > 5000)
firefox-esr_68.6.0esr-1.dsc|Checksums-Sha1 (8728 chars > 5000)
firefox-esr_68.6.0esr-1.dsc|Files (7976 chars > 5000)
gcc-10_10-20200211-1.dsc|Build-Depends (10687 chars > 5000)
gcc-10_10-20200324-1.dsc|Build-Depends (10691 chars > 5000)
gcc-10_10-20200402-1.dsc|Build-Depends (10691 chars > 5000)
gcc-10-cross_5.dsc|Binary (9282 chars > 5000)
gcc-10-cross-mipsen_2+c1.dsc|Binary (15867 chars > 5000)
gcc-10-cross-ports_3.dsc|Binary (9660 chars > 5000)
gcc-10-cross-ports_4.dsc|Binary (9660 chars > 5000)
gcc-8_8.3.0-2.dsc|Build-Depends (9812 chars > 5000)
gcc-8_8.4.0-1.dsc|Build-Depends (9575 chars > 5000)
gcc-8_8.4.0-2.dsc|Build-Depends (9575 chars > 5000)
gcc-8_8.4.0-3.dsc|Build-Depends (9607 chars > 5000)
gcc-9_9.2.1-21.dsc|Build-Depends (10484 chars > 5000)
gcc-9_9.2.1-24.dsc|Build-Depends (10484 chars > 5000)
gcc-9_9.2.1-25.dsc|Build-Depends (10484 chars > 5000)
gcc-9_9.2.1-29.dsc|Build-Depends (10497 chars > 5000)
gcc-9_9.3.0-3.dsc|Build-Depends (10501 chars > 5000)
gcc-9_9.3.0-6.dsc|Build-Depends (10497 chars > 5000)
gcc-9_9.3.0-7.dsc|Build-Depends (10497 chars > 5000)
gcc-9_9.3.0-8.dsc|Build-Depends (10497 chars > 5000)
gcc-9_9.3.0-9.dsc|Build-Depends (10497 chars > 5000)
gcc-9-cross_18.dsc|Binary (9418 chars > 5000)
gcc-9-cross_21.dsc|Binary (7157 chars > 5000)
gcc-9-cross-mipsen_3+c1.dsc|Binary (15516 chars > 5000)
gcc-9-cross-mipsen_4+c2.dsc|Binary (11527 chars > 5000)
gcc-9-cross-mipsen_4+c2.dsc|Build-Depends (5411 chars > 5000)
gcc-9-cross-ports_15.dsc|Binary (9801 chars > 5000)
gcc-9-cross-ports_17.dsc|Binary (7355 chars > 5000)
gcc-9-cross-ports_18.dsc|Binary (7355 chars > 5000)
gcc-snapshot_20191110-1.dsc|Build-Depends (10756 chars > 5000)
gcc-snapshot_20191130-1.dsc|Build-Depends (10756 chars > 5000)
gcc-snapshot_20200124-1.dsc|Build-Depends (10628 chars > 5000)
gcc-snapshot_20200401-1.dsc|Build-Depends (10663 chars > 5000)
gstreamer1.0-libav_1.16.2-2_amd64.deb|Gstreamer-Elements (8155 chars > 5000)
kubernetes_1.7.7+dfsg-3.dsc|Build-Depends (5085 chars > 5000)
libdpdk-dev_19.11-4_amd64.deb|Depends (5238 chars > 5000)
libmono-cil-dev_6.8.0.105+dfsg-2_all.deb|Depends (7485 chars > 5000)
librust-winapi-dev_0.3.8-2_amd64.deb|Provides (65642 chars > 5000)
linux_4.19.98-1.dsc|Binary (42108 chars > 5000)
linux_4.19.98-1.dsc|Build-Depends-Arch (6323 chars > 5000)
linux_5.4.19-1.dsc|Binary (43272 chars > 5000)
linux_5.4.19-1.dsc|Build-Depends-Arch (6155 chars > 5000)
linux_5.5.13-2.dsc|Binary (42827 chars > 5000)
linux_5.5.13-2.dsc|Build-Depends-Arch (6155 chars > 5000)
med-bio_3.5.1_all.deb|Recommends (5222 chars > 5000)
mono_6.8.0.105+dfsg-2.dsc|Binary (5384 chars > 5000)
mono-devel_6.8.0.105+dfsg-2_all.deb|Breaks (9778 chars > 5000)
mono-devel_6.8.0.105+dfsg-2_all.deb|Replaces (9890 chars > 5000)
node-gulp_4.0.2-6.dsc|Checksums-Sha1 (5670 chars > 5000)
node-gulp_4.0.2-6.dsc|Files (5150 chars > 5000)
nomad_0.10.2+dfsg1-10.dsc|Build-Depends (5456 chars > 5000)
nomad_0.10.4+dfsg1-1.dsc|Build-Depends (5507 chars > 5000)
nomad_0.10.4+dfsg1-3_amd64.deb|Built-Using (7135 chars > 5000)
nomad_0.10.4+dfsg1-3.dsc|Build-Depends (5507 chars > 5000)
oca-core_11.0.20180730-1_all.deb|Provides (7505 chars > 5000)
parl-desktop-world_1.9.23_all.deb|Depends (6846 chars > 5000)

Bug#951592: sagemath-common: SyntaxWarnings setting up sagemath-common

[John Scott]

Control: affects -1 python3-sagetex

Upgrading to 9.0-3 and installing SageTeX says
Setting up python3-sagetex (3.4+ds-1) ...
/usr/lib/python3/dist-packages/sagetexparse.py:135: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  if t.format is not '':


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

Bug#956008: diodon: didon eats up CPU power

[Christoph Anton Mitterer]

Package: diodon
Version: 1.9.0-1
Severity: important



Hi.

Just noted that, even though not used, diodon eats up quite some CPU power, 
like 120mW or so all the time.

Attaching to it with strace it seems to constantly poll some resource, and 
always getting errors on it.


Any ideas?

Cheers,
Chris.

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

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

Versions of packages diodon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libappindicator3-1   0.4.92-7
ii  libc62.30-4
ii  libdiodon0   1.9.0-1
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.17-1
ii  libpeas-1.0-01.26.0-2
ii  zeitgeist-core   1.0.2-3

diodon recommends no packages.

diodon suggests no packages.

-- no debconf information

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sean Whitton]

control: tag -1 + patch

Hello,

On Thu 26 Mar 2020 at 09:57AM -07, Sean Whitton wrote:

> The relevant parts of Policy to update are §§ 2.3, 4.5 and 12.5.

Here's a patch for seconding, and for the FTP Team to approve.  Thanks
to Scott for prompting the "all copies" amendation.

There could probably be some useful re-organisation and deduplication
between §§ 2.3, 4.5 and 12.5, but as that's non-normative, let's get
this change committed first.

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index b8ba081..4217dd4 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -184,15 +184,32 @@ Copyright considerations
 

 Every package must be accompanied by a verbatim copy of its
-distribution license in the file ``/usr/share/doc/package/copyright``.
-
-Every package must be accompanied by a verbatim copy of its copyright
-information, unless its distribution license explicitly permits this
-information to be excluded from distributions of binaries built from
-the source.  In such cases, a verbatim copy of its copyright
-information should normally still be included, but need not be if
-creating and maintaining a copy of that information involves
-significant time and effort.  [#]_
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.
+
+The copyright information for files in a package must be copied
+verbatim into ``/usr/share/doc/package/copyright``, when
+
+#. the distribution license for those files requires that copyright
+   information be included in all copies and/or binary distributions;
+
+#. the files are shipped in the binary package, either in source or
+   compiled form; and
+
+#. the form in which the files are present in the binary package does
+   not include a plain text version of their copyright notices.
+
+Thus, the copyright information for files in the source package which
+are only part of its build process, such as autotools files, need not
+be included in ``/usr/share/doc/package/copyright``, because those
+files do not get installed into the binary package.  Similarly, plain
+text files which include their own copyright information and are
+installed into the binary package unmodified need not have that
+copyright information copied into ``/usr/share/doc/package/copyright``
+
+However, the copyright notices for any files which are compiled into
+the object code shipped in the binary package must all be included in
+d/copyright when the license requires that copyright information be
+included in all copies and/or binary distributions, as most do.  [#]_

 See :ref:`s-copyrightfile` for further details.

diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index b466304..3e797d6 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -181,10 +181,13 @@ maintainer's discretion.
 Copyright information
 -

-Every package must be accompanied by a verbatim copy of its copyright
-information and distribution license in the file
-``/usr/share/doc/package/copyright``. This file must neither be
-compressed nor be a symbolic link.
+Every package must be accompanied by a verbatim copy of its
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.
+This file must neither be compressed nor be a symbolic link.
+
+A verbatim copy of the package's copyright information is often
+required to be present in ``/usr/share/doc/package/copyright``, too;
+see :ref:`s-pkgcopyright`.

 In addition, the copyright file must say where the upstream sources (if
 any) were obtained, and should include a name or contact address for the
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1a4e871..7644a27 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -211,9 +211,9 @@ Copyright: ``debian/copyright``
 ---

 Every package must be accompanied by a verbatim copy of its
-distribution license in the file ``/usr/share/doc/package/copyright``.
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.

-This file is usually required to contain a verbatim copy of the
+This file is often required to contain a verbatim copy of the
 package's copyright information, too; see :ref:`s-copyrightfile` and
 :ref:`s-pkgcopyright` for details, and for further considerations
 related to copyrights for packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#956007: mercurial: Remove use of python-subversion

[James McCoy]

Source: mercurial
Version: 5.3.1-1
Severity: important

python-subversion can't be built with current src:swig, so I'm in the
process of removing it.  Subversion's next upstream release will have
support for Python 3, but since src:subversion currently FTBFS I'm
removing the package early.

It appears that mercurial uses python-subversion in some of its
testsuite (and therefore also autopkgtests), so those should probably be
blacklisted until they're converted to work with the future
python3-subversion.

Cheers,
James

-- 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.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#956006: dselect: removes postfix package unless locked

[Damien Moore]

Package: dselect
Version: 1.19.7
Severity: important

Dear Maintainer,


When I go into Select, and choose postfix to be installed, dselect accepts this 
option:
 *=* Opt mail postfix  amd64  i386   3.4.8-0+10d 3.4.8-0+10d 
High-performance mail transport

But then when I go to Install as the next step, dselect attempts to remove 
postfix

The following packages will be REMOVED:
  postfix

The only way to stop it doing this is to lock it to a specific version (thus 
the = in the original status)

I would expect dselect to either report an issue when selecting the package or 
to not try and remove the package when moving to the next stage.

I'm concerned this is leaving me unable to update as security patches are ready.


-- Package-specific info:

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

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

Versions of packages dselect depends on:
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libtinfo6 6.1+20181013-2+deb10u2

dselect recommends no packages.

Versions of packages dselect suggests:
ii  perl  5.28.1-6

-- no debconf information

Bug#956001: cinnamon-common: Python SyntaxWarning in package setup - bad identity comparisons against literals

[Norbert Preining]

severity 956001 minor
thanks

Hi Phil,

On Sun, 05 Apr 2020, Phil Miller wrote:
> /usr/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py:197: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   name_valid = name_text is not ""

Yeah yeah, Python 3.8 noisiness. Python devs enjoy breaking
compatibility.

This will probably be fixed upstream in due time. The warnings are
harmless and can be ignored.

Best

Norbert

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

Bug#956005: transition page checkbox labels are not marked as such

[Dagfinn Ilmari Mannsåker]

Package: ben
Verison: 0.9.0
Severity: minor

Marking up the labels for the status filter checkboxes on the transition
details page with  tags would make them easier to toggle, since
that makes the whole label clickable, not just the checkbox.  It also
makes them more accessible to assistive technology users.

For example:

  good

See  for more details.

Thanks,

- ilmari
-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.   - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.  - Calle Dybedahl

Bug#933378: bug report should go upstream

[David Christensen]

I purged Thunderbird from my system, moved my .thunderbird folder aside, 
installed Thunderbird, started Thunderbird, set up my e-mail account, 
shut down Thunderbird, renamed my profile folder and adjusted 
profiles.ini, and copied the address books and e-mail files and folders 
from my old profile to my new profile.



I have configured Thunderbird not to synchronize messages from the 
server to this computer.



I have created an Inbox subfolder on Local Folders, and created a 
message filter to copy incoming messages from the server Inbox to the 
local Inbox.



So, between a fresh install, a fresh profile, and changing my workflow 
to avoid moving messages from IMAP folders to local folders, hopefully 
Thunderbird will behave.



But, given that I sometimes see the toilet bowl mouse icon in Thunar, I 
can only wonder if the problem might be Xfce or something deeper...



We'll see what happens.


Thanks for the help.  :-)


David

Bug#954311: Not just rendering issues...

[Pascal Giard]

Thanks A LOT for the /etc/drirc trick, it fixed the problem detailed below
for me.
Took me over an hour to figure out what was wrong and to end up on this bug
report.

I have a Thinkpad T480 (Intel UHD 620).

The new iris driver causes all my video players to crash (e.g., VLC or mpv)
and prevents Zoom from converting my recorded sessions.

Best regards,

-Pascal
--
Homepage (http://pascal.giard.info)
École de technologie supérieure (http://etsmtl.ca)

Bug#952313: arduino-builder: FTBFS: failed to initialize build cache at /sbuild-nonexistent/.cache/go-build: mkdir /sbuild-nonexistent: permission denied

[Logan Rosen]

Package: arduino-builder
Version: 1.3.25-1
Followup-For: Bug #952313
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * Export a writable home directory to fix FTBFS initializing build cache.

Thanks for considering the patch.

Logan

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

Kernel: Linux 5.4.0-21-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru arduino-builder-1.3.25/debian/rules 
arduino-builder-1.3.25/debian/rules
--- arduino-builder-1.3.25/debian/rules 2018-03-29 12:01:11.0 -0400
+++ arduino-builder-1.3.25/debian/rules 2020-04-05 18:29:35.0 -0400
@@ -2,6 +2,7 @@
 
 # Output every command that modifies files on the build system.
 export DH_VERBOSE = 1
+export HOME = $(CURDIR)
 
 EXCLUDED_TESTS := add_build_board_property_if_missing_test.go \
   builder_test.go \

Bug#955999: openmsx: Issues with pressing multiple keys

[Manuel Bilderbeek]

Hi,

I can't reproduce the problem. Just walking the right in MoG and 
jumping, I keep walking to the right.


Are you sure you didn't change something with keyboard hardware or some 
other keyboard settings?


Can you confirm the problem doesn't occur by compiling a previous 
version and trying that?


Thanks.

Kind regards,

Manuel
(one of the upstream authors)

On 05-04-2020 22:37, Jesus Barrado Varela wrote:

Package: openmsx
Version: 0.15.0-2+b1
Severity: important

Dear Maintainer,
When using openMSX, holding a key and then pressing another one makes the 
emulator act as if the key that was being held weren't.

This issue can be easily reproduced with the arrow keys and a game that is 
controlled with them. In order to reproduce:
1. Hold the right arrow key.
2. Press any other arrow key without releasing the previously held one.
3. A few seconds later the emulator will acts as if the right arrow key weren't 
held, but it is.

A game where this issue is pretty noticeable is "Knightmare II: The Maze of 
Galious", where the up arrow key is used to jump. Moving the character to the right, 
jumping and keeping going to the right makes the character to stop although I hold the 
right arrow key.
It can be reproduced pressing any kery (e.g. pressing M while holding up), but 
it's more noticeable when it happens with movement keys.

This happens launching openmsx from the terminal or by using openmsx-catapult. 
And it happens with any MSX type (C-BIOS, FS-A1WSX...).

It may look like it's a problem with the keyboard or a limitation of the game 
console, but this wasn't present in previous versions.

I hope I explained myself well.

Bug#956004: mesa: Please build Mesa agaisng llvm 10

[Shmerl]

Source: mesa
Severity: wishlist

Dear Maintainer,

llvm 10 has various fixes that affect AMD Navi cards, that apparently were not
backported to llvm 9 series. llvm 9 is causing desktop hangs on Navi cards even
with Mesa 20.x. Please build Mesa in Debian unstable / testing using llvm 10.

Thanks!



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

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

Bug#956003: xfce4-panel: Memory leak in panel plugin wrapper

[Ben Wiederhake]

Package: xfce4-panel
Version: 4.14.3-1
Severity: normal
Tags: patch

Dear Maintainer,

tl;dr: The wrapper leaks 32 bytes with every redraw event.
On my system, that means I have to reboot every other week.

First I want to convince you that there actually is an issue.
For that, I replaced /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 by a
little script that usually exec's the real binary, but intercepts cpugraph, and
calls it through valgrind. This way I could see what the wrapper does under
"real" circumstances.

Here is the relevant valgrind log output, for xfce4-panel 4.14.3-1 with
cpugraph-plugin on "Very fast (250ms)",
killing after 1 hour:

==7077== 414,560 bytes in 12,955 blocks are definitely lost in loss record
6,679 of 6,679
==7077==at 0x48367F3: malloc (in /usr/lib/x86_64-linux-
gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==7077==by 0x544D1C8: g_malloc (gmem.c:102)
==7077==by 0x54651F1: g_slice_alloc (gslice.c:1024)
==7077==by 0x5465851: g_slice_copy (gslice.c:1075)
==7077==by 0x5390AAF: boxed_proxy_lcopy_value (gboxed.c:267)
==7077==by 0x4B4F530: gtk_style_context_get_valist (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077==by 0x4B4F759: gtk_style_context_get (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==7077==by 0x10CCA2: wrapper_plug_draw (wrapper-plug.c:221)
==7077==by 0x4BF2813: ??? (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==7077==by 0x4BFB9AF: ??? (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==7077==by 0x4AA9C93: gtk_main_do_event (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==7077==by 0x4F99804: ??? (in /usr/lib/x86_64-linux-
gnu/libgdk-3.so.0.2404.10)
==7077==
==7077== LEAK SUMMARY:
==7077==definitely lost: 415,048 bytes in 12,988 blocks
==7077==indirectly lost: 0 bytes in 0 blocks
==7077==  possibly lost: 4,720 bytes in 47 blocks
==7077==still reachable: 1,561,423 bytes in 16,581 blocks
==7077==   of which reachable via heuristic:
==7077== length64   : 4,744 bytes in 82 blocks
==7077== newarray   : 2,160 bytes in 55 blocks
==7077== suppressed: 0 bytes in 0 blocks
==7077== Reachable blocks (those to which a pointer was found) are not shown.
==7077== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7077==
==7077== ERROR SUMMARY: 40 errors from 40 contexts (suppressed: 0 from 0)

That's about 70 MB per week:
https://www.wolframalpha.com/input/?i=414560+byte+*+week+%2F+hour
That matches my observations about cpugraph needing more and more memory.

wrapper-plug.c:221 fetches the background color, and from the stacktrace it
looks like a copy is made, and the caller is supposed to clean up that copy.
However, wrapper-plug does not do that.
Note that sizeof(GdkRGBA)==32 and 414560.0 / 12955.0 == 32.0, so it's
plausible.

The latest version in salsa (>4.15.0-1) doesn't help.
That makes sense because wrapper-plug.c didn't change significantly.
Here's the result after running for 10 minutes:

==6308== 65,952 bytes in 2,061 blocks are definitely lost in loss record 6,456
of 6,459
==6308==at 0x48367F3: malloc (in /usr/lib/x86_64-linux-
gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==6308==by 0x544F1C8: g_malloc (gmem.c:102)
==6308==by 0x54671F1: g_slice_alloc (gslice.c:1024)
==6308==by 0x5467851: g_slice_copy (gslice.c:1075)
==6308==by 0x5392AAF: boxed_proxy_lcopy_value (gboxed.c:267)
==6308==by 0x4B51530: gtk_style_context_get_valist (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308==by 0x4B51759: gtk_style_context_get (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==6308==by 0x10CCC2: wrapper_plug_draw (wrapper-plug.c:190)
==6308==by 0x4BF4813: ??? (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==6308==by 0x4BFD9AF: ??? (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==6308==by 0x4AABC93: gtk_main_do_event (in /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0.2404.10)
==6308==by 0x4F9B804: ??? (in /usr/lib/x86_64-linux-
gnu/libgdk-3.so.0.2404.10)
==6308==
==6308== LEAK SUMMARY:
==6308==definitely lost: 66,095 bytes in 2,069 blocks
==6308==indirectly lost: 0 bytes in 0 blocks
==6308==  possibly lost: 4,696 bytes in 47 blocks
==6308==still reachable: 1,544,097 bytes in 16,302 blocks
==6308==   of which reachable via heuristic:
==6308== length64   : 4,384 bytes in 76 blocks
==6308== newarray   : 2,144 bytes in 54 blocks
==6308== suppressed: 0 bytes in 0 blocks
==6308== Reachable blocks (those to which a pointer was found) are not shown.
==6308== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Freeing the GdkRGBA causes no problems and fixes the leak. This is with the
patch, after 10 minutes:

==5086== LEAK SUMMARY:
==5086==definitely lost: 143 bytes in 8 blocks
==5086==

Bug#951999: Autoconf issue in mpqc

[Jeremy Sowden]

On 2020-04-05, at 14:32:16 +0200, Andreas Tille wrote:
> On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote:
> > > > I've attached the part or the build log that seems to be
> > > > autoconf relevant.  I admit I'm a bit astonished since I can
> > > > only see warnings but no error ...
> > >
> > > Here's a patch that fixes the autoheader warnings.
> >
> > Whoops.  That version doesn't seem to apply.  The patch I've
> > attached to this message I have actually tested properly.
> >
> > > autoreconf is still failing.
> >
> > That's not quite right: "autoreconf" fails, but  "autoreconf -f -i"
> > (which is what dh_autoreconf does) succeeds.  Now dh_auto_configure
> > fails.
>
> I confirm it fails with
>
> ...
> checking if semctl requires semun... no
> checking if fortran compiler works... no
> configure: error: in `/build/mpqc-2.3.1':
> configure: error: fortran compiler does not work
>
>
> I've updated Git with your patch - thanks a lot so far.

In my case, the problem was:

  ./configure: line 4287: mpicc: command not found

IOW, missing build-deps.  Once I installed those, dh_auto_configure was
happy, but there were compilation failures because autoheader clobbered
src/lib/scconfig.h.in.  I've attached two patches which fix those.

J.
From 179ea7ad88afe65c49976fe713e7e061692d51cf Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Sun, 5 Apr 2020 20:22:51 +0100
Subject: [PATCH 1/2] shmtype fix.

---
 debian/patches/series|  1 +
 debian/patches/shmtype.patch | 45 
 2 files changed, 46 insertions(+)
 create mode 100644 debian/patches/shmtype.patch

diff --git a/debian/patches/series b/debian/patches/series
index db79d4fb8ff5..c5ef93ff27ed 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@ g++6-constexpr.patch
 Fix_mpi.patch
 autoconf.patch
 autoheader.patch
+shmtype.patch
diff --git a/debian/patches/shmtype.patch b/debian/patches/shmtype.patch
new file mode 100644
index ..0a8273be680a
--- /dev/null
+++ b/debian/patches/shmtype.patch
@@ -0,0 +1,45 @@
+diff --git a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in
+index 81510ae39834..8ca70c95073d 100644
+--- a/src/lib/scconfig.h.in
 b/src/lib/scconfig.h.in
+@@ -156,10 +156,6 @@
+ /* Define to the type used for shared memory.  */
+ /* #undef SHMTYPE */
+ 
+-#ifndef SHMTYPE
+-#define SHMTYPE char*
+-#endif
+-
+ /* Define if you have the  header file.  */
+ #undef HAVE_FCNTL_H
+ 
+diff --git a/src/lib/util/group/memshm.cc b/src/lib/util/group/memshm.cc
+index 91964682b7f0..1314e43f01ec 100644
+--- a/src/lib/util/group/memshm.cc
 b/src/lib/util/group/memshm.cc
+@@ -41,6 +41,10 @@
+ using namespace std;
+ using namespace sc;
+ 
++#ifndef SHMTYPE
++#define SHMTYPE char*
++#endif
++
+ #ifndef SHMMAX
+ // glibc 2.0.3 isn't defining SHMMAX so make set it here
+ #  ifdef __linux__
+diff --git a/src/lib/util/group/messshm.cc b/src/lib/util/group/messshm.cc
+index f07fe1a79fde..34ee31e1ddbf 100644
+--- a/src/lib/util/group/messshm.cc
 b/src/lib/util/group/messshm.cc
+@@ -40,6 +40,10 @@
+ using namespace std;
+ using namespace sc;
+ 
++#ifndef SHMTYPE
++#define SHMTYPE char*
++#endif
++
+ //#define DEBUG
+ 
+ #ifndef SEM_A
-- 
2.25.1

From 4d6bd8fc829d385bc05d696780429a03d915b18f Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Sun, 5 Apr 2020 20:58:57 +0100
Subject: [PATCH 2/2] restrictxx fix.

---
 debian/patches/restrictxx.patch | 102 
 debian/patches/series   |   1 +
 2 files changed, 103 insertions(+)
 create mode 100644 debian/patches/restrictxx.patch

diff --git a/debian/patches/restrictxx.patch b/debian/patches/restrictxx.patch
new file mode 100644
index ..e86d7d1a95e3
--- /dev/null
+++ b/debian/patches/restrictxx.patch
@@ -0,0 +1,102 @@
+diff --git a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in
+index 81510ae39834..3eaea90920ab 100644
+--- a/src/lib/scconfig.h.in
 b/src/lib/scconfig.h.in
+@@ -14,12 +14,6 @@
+ /* Define if the C++ restrict keyword extension exists.  */
+ #undef CXX_RESTRICT
+ 
+-#ifdef CXX_RESTRICT
+-#define restrictxx restrict
+-#else
+-#define restrictxx
+-#endif
+-
+ #endif
+ 
+ /* Define if you want to optimize the reference counting code.  */
+diff --git a/src/lib/chemistry/qc/intv3/build2e.cc b/src/lib/chemistry/qc/intv3/build2e.cc
+index 1179f9dcb6d2..fec356986d33 100644
+--- a/src/lib/chemistry/qc/intv3/build2e.cc
 b/src/lib/chemistry/qc/intv3/build2e.cc
+@@ -36,6 +36,12 @@
+ #include 
+ #include 
+ 
++#ifdef CXX_RESTRICT
++#define restrictxx restrict
++#else
++#define restrictxx
++#endif
++
+ using namespace std;
+ using namespace sc;
+ 
+diff --git a/src/lib/chemistry/qc/intv3/shift2e.cc b/src/lib/chemistry/qc/intv3/shift2e.cc
+index 97d9f24df6a0..5a01bff73894 100644
+--- a/src/lib/chemistry/qc/intv3/shift2e.cc
 b/src/lib/chemistry/qc/intv3/shift2e.cc
+@@ -29,6 +29,12 @@
+ #include 
+ #include 
+ 
++#ifdef CXX_RESTRICT
++#define restrictxx restrict
++#else
++#define re

Bug#956001: cinnamon-common: Python SyntaxWarning in package setup - bad identity comparisons against literals

[Phil Miller]

Package: cinnamon-common
Version: 4.4.8-3
Severity: important

During upgrade, I saw the following warnings:

Setting up cinnamon-common (4.4.8-3) ...
/usr/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py:197: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  name_valid = name_text is not ""
/usr/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py:239: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  valid = (name_text is not "")
/usr/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py:284: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  name_valid = name_text is not ""
/usr/share/cinnamon/cinnamon-settings/bin/ChooserButtonWidgets.py:342: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if show_seconds is 'default':
/usr/share/cinnamon/cinnamon-settings/bin/ChooserButtonWidgets.py:346: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if show_seconds is 'true':
/usr/share/cinnamon/cinnamon-settings/bin/ChooserButtonWidgets.py:348: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif show_seconds is 'false':
/usr/share/cinnamon/cinnamon-settings/bin/JsonSettingsWidgets.py:242: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if key[:1] is '!':
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:422: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if category.int_name is not "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:431: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if category.int_name is "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:446: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if category.int_name is "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:456: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if entry is not "_invalid_":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:539: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if cat[2].int_name is "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:577: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if cat[2].int_name is "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:603: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if cat[2].int_name is "custom":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:694: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if entry is not "":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:734: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if entry is not "":
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:780: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  ok_enabled = self.name_entry.get_text().strip() is not "" and 
self.command_entry.get_text().strip() is not ""
/usr/share/cinnamon/cinnamon-settings/modules/cs_keyboard.py:780: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  ok_enabled = self.name_entry.get_text().strip() is not "" and 
self.command_entry.get_text().strip() is not ""
/usr/share/cinnamon/cinnamon-slideshow/cinnamon-slideshow.py:121: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(files) is not 0:


-- 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)
Foreign Architectures: i386

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

Versions of packages cinnamon-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gettext  0.19.8.1-10
ii  gir1.2-cinnamondesktop-3.0   4.4.1-3
ii  gir1.2-meta-muffin-0.0   4.4.3-1
ii  libglib2.0-bin   2.64.1-1
ii  python3  3.8.2-2
ii  python3-xapp 1.8.1-2
ii  xdg-utils1.1.3-2

cinnamon-common recommends no packages.

cinnamon-common suggests no packages.

-- no debconf information

Bug#956002: pitivi: Python SyntaxWarning in package setup - bad identity comparisons against literals

[Phil Miller]

Package: pitivi
Version: 0.999-2
Severity: normal

running python rtupdate hooks for python3.8...
[snip other packages with the same warning]
/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py:328: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif status is "UNSUPPORTED":
/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/timeline/previewers.py:869: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if self._image_size[0] is 0:


-- 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)
Foreign Architectures: i386

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

Versions of packages pitivi depends on:
ii  gir1.2-gdkpixbuf-2.02.40.0+dfsg-3
ii  gir1.2-ges-1.0  1.16.2-2
ii  gir1.2-glib-2.0 1.64.0-2
ii  gir1.2-gst-plugins-base-1.0 1.16.2-4
ii  gir1.2-gstreamer-1.01.16.2-2
ii  gir1.2-gtk-3.0  3.24.17-1
ii  gir1.2-pango-1.01.42.4-8
ii  gstreamer1.0-gtk3 [gstreamer1.0-videosink]  1.16.2-3
ii  gstreamer1.0-plugins-bad [gstreamer1.0-videosink]   1.16.2-2.1
ii  gstreamer1.0-plugins-base   1.16.2-4
ii  gstreamer1.0-plugins-good [gstreamer1.0-videosink]  1.16.2-3
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.16.2-3
ii  gstreamer1.0-x [gstreamer1.0-videosink] 1.16.2-4
ii  libc6   2.30-4
ii  libcairo2   1.16.0-4
ii  libglib2.0-02.64.1-1
ii  libgstreamer-plugins-base1.0-0  1.16.2-4
ii  libgstreamer1.0-0   1.16.2-2
ii  libpython3.83.8.2-1+b1
ii  python3 3.8.2-2
ii  python3-cairo   1.16.2-2
ii  python3-dbus1.2.16-1
ii  python3-gi  3.36.0-1
ii  python3-gi-cairo3.36.0-1
ii  python3-gst-1.0 1.16.2-2
ii  python3-matplotlib  3.2.1-1
ii  python3-numpy   1:1.17.4-5
ii  python3-xdg 0.26-2
ii  python3.8   3.8.2-1+b1

pitivi recommends no packages.

Versions of packages pitivi suggests:
ii  frei0r-plugins 1.7.0-1
ii  gir1.2-gnomedesktop-3.03.34.2-2
pn  gir1.2-gsound-1.0  
ii  gir1.2-notify-0.7  0.7.9-1
ii  gstreamer1.0-libav 1.16.2-2
ii  gstreamer1.0-plugins-ugly  1.16.2-2

-- no debconf information

Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

On 4/5/20 11:16 PM, John Paul Adrian Glaubitz wrote:
> This is actually still #895723 [1], for some reason the fix doesn't work
> on powerpc while it works on ppc64 and ppc64el.
> 
> I suggest we just disable the testsuite on powerpc completely for the
> time being.

Attaching a patch.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig	2020-04-05 23:32:24.043398267 +0300
+++ debian/rules	2020-04-06 00:12:01.338385767 +0300
@@ -61,6 +61,12 @@
 	CARGO_INCREMENTAL=1 dh_auto_test -- TESTS=$(TESTS)
 endif
 
+# https://bugs.debian.org/955845
+ifneq (,$(filter $(DEB_HOST_ARCH), powerpc))
+override_dh_auto_test:
+	:
+endif
+
 override_dh_auto_test-arch:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	mkdir -p $(CURDIR)/debian/locales

Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine

[John Paul Adrian Glaubitz]

Control: retitle -1 librsvg: Testsuite linking failure still affects powerpc

This is actually still #895723 [1], for some reason the fix doesn't work
on powerpc while it works on ppc64 and ppc64el.

I suggest we just disable the testsuite on powerpc completely for the
time being.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895723

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

Bug#919202: the issue is still pending

[shirish शिरीष]

Dear Maintainer,

Even with epiphany-browser update the issue is still update -

epiphany-browser-data: broken-symlink
/usr/share/epiphany-browser/mime-types-permissions.xml ->
/etc/gnome/epiphany/mime-types-permissions.xml

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#956000: gtk-gnutella: missing source for Configure

[Helmut Grohne]

Source: gtk-gnutella
Version: 1.1.15-1
Severity: serious
Justification: missing source

gtk-gnutella misses the source for the file "Configure". Close to the
start it says:

| # Generated on Sun Nov 18 15:25:45 CET 2018 [metaconfig 3.5-244]

For running metaconfig a .package file is required. However such a file
is missing from the gtk-gnutella source. As such, Configure cannot be
regenerated and is missing the corresponding source. Please include the
.package file in the source distribution to allow downstream
modification.

Helmut

Bug#955999: openmsx: Issues with pressing multiple keys

[Jesus Barrado Varela]

Package: openmsx
Version: 0.15.0-2+b1
Severity: important

Dear Maintainer,
When using openMSX, holding a key and then pressing another one makes the 
emulator act as if the key that was being held weren't.

This issue can be easily reproduced with the arrow keys and a game that is 
controlled with them. In order to reproduce:
1. Hold the right arrow key.
2. Press any other arrow key without releasing the previously held one.
3. A few seconds later the emulator will acts as if the right arrow key weren't 
held, but it is.

A game where this issue is pretty noticeable is "Knightmare II: The Maze of 
Galious", where the up arrow key is used to jump. Moving the character to the 
right, jumping and keeping going to the right makes the character to stop 
although I hold the right arrow key.
It can be reproduced pressing any kery (e.g. pressing M while holding up), but 
it's more noticeable when it happens with movement keys.

This happens launching openmsx from the terminal or by using openmsx-catapult. 
And it happens with any MSX type (C-BIOS, FS-A1WSX...).

It may look like it's a problem with the keyboard or a limitation of the game 
console, but this wasn't present in previous versions.

I hope I explained myself well.

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

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

Versions of packages openmsx depends on:
ii  cbios0.28-1
ii  libasound2   1.1.8-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libglew2.1   2.1.0-4
ii  libogg0  1.3.2-1+b1
ii  libpng16-16  1.6.36-6
ii  libsdl-ttf2.0-0  2.0.11-6
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6
ii  libtcl8.68.6.9+dfsg-2
ii  libtheora0   1.1.1+dfsg.1-15
ii  libvorbis0a  1.3.6-2
ii  openmsx-data 0.15.0-2
ii  zlib1g   1:1.2.11.dfsg-1

openmsx recommends no packages.

Versions of packages openmsx suggests:
pn  dmktools  
ii  openmsx-catapult  0.15.0-1
pn  openmsx-debugger  

-- no debconf information

Bug#955998: ITP: python-merge3 -- Python implementation of 3-way merge

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-merge3
  Version : 0.0.2
  Upstream Author : Canonical Ltd
* URL : https://github.com/breezy-team/merge3
* License : GPL
  Programming Lang: Python
  Description : Python implementation of 3-way merge

 A Python implementation of 3-way merge of texts.
 .
 Given BASE, OTHER, THIS, tries to produce a combined text
 incorporating the changes from both BASE->OTHER and BASE->THIS.
 All three will typically be sequences of lines.

Bug#955997: rust-libc: autopkgtest failure.

[peter green]

Package: rust-libc
Version: 0.22-6-1
Severity: serious

rust-libc's autopkgtest failure is failing, this is happening in both the 
unstable->testing migration tests and the plain unstable tests and seems to be 
a blocker for getting rust-cbindgen back into testing.

[libc 0.2.66] thread 'main' panicked at 'const-extern-fn requires a nightly 
compiler >= 1.40', build.rs:80:13
[libc 0.2.66] stack backtrace:
[libc 0.2.66]    0: backtrace::backtrace::libunwind::trace
[libc 0.2.66]  at 
/usr/src/rustc-1.41.1/vendor/backtrace/src/backtrace/libunwind.rs:88
[libc 0.2.66]    1: backtrace::backtrace::trace_unsynchronized
[libc 0.2.66]  at 
/usr/src/rustc-1.41.1/vendor/backtrace/src/backtrace/mod.rs:66
[libc 0.2.66]    2: std::sys_common::backtrace::_print_fmt
[libc 0.2.66]  at src/libstd/sys_common/backtrace.rs:84
[libc 0.2.66]    3: ::fmt
[libc 0.2.66]  at src/libstd/sys_common/backtrace.rs:61
[libc 0.2.66]    4: core::fmt::write
[libc 0.2.66]  at src/libcore/fmt/mod.rs:1025
[libc 0.2.66]    5: std::io::Write::write_fmt
[libc 0.2.66]  at src/libstd/io/mod.rs:1426
[libc 0.2.66]    6: std::sys_common::backtrace::_print
[libc 0.2.66]  at src/libstd/sys_common/backtrace.rs:65
[libc 0.2.66]    7: std::sys_common::backtrace::print
[libc 0.2.66]  at src/libstd/sys_common/backtrace.rs:50
[libc 0.2.66]    8: std::panicking::default_hook::{{closure}}
[libc 0.2.66]  at src/libstd/panicking.rs:193
[libc 0.2.66]    9: std::panicking::default_hook
[libc 0.2.66]  at src/libstd/panicking.rs:210
[libc 0.2.66]   10: std::panicking::rust_panic_with_hook
[libc 0.2.66]  at src/libstd/panicking.rs:471
[libc 0.2.66]   11: std::panicking::begin_panic
[libc 0.2.66]  at /usr/src/rustc-1.41.1/src/libstd/panicking.rs:404
[libc 0.2.66]   12: build_script_build::main
[libc 0.2.66]  at ./build.rs:80
[libc 0.2.66]   13: std::rt::lang_start::{{closure}}
[libc 0.2.66]  at /usr/src/rustc-1.41.1/src/libstd/rt.rs:67
[libc 0.2.66]   14: std::rt::lang_start_internal::{{closure}}
[libc 0.2.66]  at src/libstd/rt.rs:52
[libc 0.2.66]   15: std::panicking::try::do_call
[libc 0.2.66]  at src/libstd/panicking.rs:292
[libc 0.2.66]   16: __rust_maybe_catch_panic
[libc 0.2.66]  at src/libpanic_unwind/lib.rs:78
[libc 0.2.66]   17: std::panicking::try
[libc 0.2.66]  at src/libstd/panicking.rs:270
[libc 0.2.66]   18: std::panic::catch_unwind
[libc 0.2.66]  at src/libstd/panic.rs:394
[libc 0.2.66]   19: std::rt::lang_start_internal
[libc 0.2.66]  at src/libstd/rt.rs:51
[libc 0.2.66]   20: std::rt::lang_start
[libc 0.2.66]  at /usr/src/rustc-1.41.1/src/libstd/rt.rs:67
[libc 0.2.66]   21: main
[libc 0.2.66]   22: __libc_start_main
[libc 0.2.66]   23: _start
[libc 0.2.66] note: Some details are omitted, run with `RUST_BACKTRACE=full` 
for a verbose backtrace.
error: failed to run custom build command for `libc v0.2.66 
(/usr/share/cargo/registry/libc-0.2.66)`

Bug#955652: dvdbackup: diff for NMU version 0.4.2-4.1

[Sebastian Ramacher]

Control: tags 955652 + patch
Control: tags 955652 + pending

Dear maintainer,

I've prepared an NMU for dvdbackup (versioned as 0.4.2-4.1) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it
longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru dvdbackup-0.4.2/debian/changelog dvdbackup-0.4.2/debian/changelog
--- dvdbackup-0.4.2/debian/changelog	2013-07-04 14:32:09.0 +0200
+++ dvdbackup-0.4.2/debian/changelog	2020-04-05 17:57:40.0 +0200
@@ -1,3 +1,12 @@
+dvdbackup (0.4.2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/libdvdread6.1.0.patch: Adapt to API changes in libdvdread
+6.1.0 (Closes: #955652)
+Thanks to Felix Palmen for the patch.
+
+ -- Sebastian Ramacher   Sun, 05 Apr 2020 17:57:40 +0200
+
 dvdbackup (0.4.2-4) unstable; urgency=low
 
   * remove-path_max-limitation.patch: Remove PATH_MAX limitation to fix build
diff -Nru dvdbackup-0.4.2/debian/patches/libdvdread6.1.0.patch dvdbackup-0.4.2/debian/patches/libdvdread6.1.0.patch
--- dvdbackup-0.4.2/debian/patches/libdvdread6.1.0.patch	1970-01-01 01:00:00.0 +0100
+++ dvdbackup-0.4.2/debian/patches/libdvdread6.1.0.patch	2020-04-05 17:53:42.0 +0200
@@ -0,0 +1,88 @@
+--- a/src/dvdbackup.c
 b/src/dvdbackup.c
+@@ -1180,7 +1180,7 @@
+ 	int size;
+ 
+ 	/* DVD handler */
+-	ifo_handle_t* ifo_file = NULL;
++	dvd_file_t* ifo_file = NULL;
+ 
+ 
+ 	if (title_set_info->number_of_title_sets + 1 < title_set) {
+@@ -1245,7 +1245,7 @@
+ 	if ((streamout_ifo = open(targetname_ifo, O_WRONLY | O_CREAT | O_TRUNC, 0666)) == -1) {
+ 		fprintf(stderr, _("Error creating %s\n"), targetname_ifo);
+ 		perror(PACKAGE);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1257,7 +1257,7 @@
+ 	if ((streamout_bup = open(targetname_bup, O_WRONLY | O_CREAT | O_TRUNC, 0666)) == -1) {
+ 		fprintf(stderr, _("Error creating %s\n"), targetname_bup);
+ 		perror(PACKAGE);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1268,9 +1268,9 @@
+ 
+ 	/* Copy VIDEO_TS.IFO, since it's a small file try to copy it in one shot */
+ 
+-	if ((ifo_file = ifoOpen(dvd, title_set))== 0) {
++	if ((ifo_file = DVDOpenFile(dvd, title_set, DVD_READ_INFO_FILE))== 0) {
+ 		fprintf(stderr, _("Failed opening IFO for title set %d\n"), title_set);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1279,11 +1279,11 @@
+ 		return 1;
+ 	}
+ 
+-	size = DVDFileSize(ifo_file->file) * DVD_VIDEO_LB_LEN;
++	size = DVDFileSize(ifo_file) * DVD_VIDEO_LB_LEN;
+ 
+ 	if ((buffer = (unsigned char *)malloc(size * sizeof(unsigned char))) == NULL) {
+ 		perror(PACKAGE);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1292,11 +1292,11 @@
+ 		return 1;
+ 	}
+ 
+-	DVDFileSeek(ifo_file->file, 0);
++	DVDFileSeek(ifo_file, 0);
+ 
+-	if (DVDReadBytes(ifo_file->file,buffer,size) != size) {
++	if (DVDReadBytes(ifo_file,buffer,size) != size) {
+ 		fprintf(stderr, _("Error reading IFO for title set %d\n"), title_set);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1308,7 +1308,7 @@
+ 
+ 	if (write(streamout_ifo,buffer,size) != size) {
+ 		fprintf(stderr, _("Error writing %s\n"),targetname_ifo);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
+@@ -1319,7 +1319,7 @@
+ 
+ 	if (write(streamout_bup,buffer,size) != size) {
+ 		fprintf(stderr, _("Error writing %s\n"),targetname_bup);
+-		ifoClose(ifo_file);
++		DVDCloseFile(ifo_file);
+ 		free(buffer);
+ 		free(targetname_ifo);
+ 		free(targetname_bup);
diff -Nru dvdbackup-0.4.2/debian/patches/series dvdbackup-0.4.2/debian/patches/series
--- dvdbackup-0.4.2/debian/patches/series	2013-07-04 14:30:12.0 +0200
+++ dvdbackup-0.4.2/debian/patches/series	2020-04-05 17:45:32.0 +0200
@@ -1,2 +1,3 @@
 ignore-automake-warnings.patch
 remove-path_max-limitation.patch
+libdvdread6.1.0.patch


signature.asc
Description: PGP signature

Bug#955496: RFS: libsys-hostaddr-perl/0.993-1 [ITP] -- Get IP address information about this host

[Adam Borowski]

On Wed, Apr 01, 2020 at 05:51:28PM +0200, Hilmar Preusse wrote:
>  * Package name: libsys-hostaddr-perl
>Version : 0.993-1
>Upstream Author : Jeremy Kister|http://jeremy.kister.net/
>  * URL : https://metacpan.org/release/Sys-HostAddr

> Changes since the last upload:
> 
>* Initial release. (Closes: #955449).

Hi!
I'm not quite sure if this particular implementation is adequate.  So far
I noticed that it:

* has seen no updates since 2014
* relies on a long-deprecated interface, via a tool that hasn't seen an
  upstream release since April 2001
* has non-working support for IPv6
* its support for IPv4 isn't stellar either
* doesn't handle lack of answer or answers it doesn't understand
* provides only partial answers

For example:

perl -e 'use Sys::HostAddr;use Data::Dumper; print "\e[33m$_\e[0m\n", 
eval("Dumper(Sys::HostAddr->new()->$_())") for qw(public interfaces addresses 
ip first_ip main_ip)'

Modification of a read-only value attempted at /usr/share/perl5/Sys/HostAddr.pm 
line 68.
public
$VAR1 = undef;
interfaces
$VAR1 = [
  'br0',
  'eth0',
  'lo'
];
addresses
$VAR1 = [
  '10.0.1.9',
  '127.0.0.1'
];
ip
$VAR1 = {
  'lo' => [
{
  'netmask' => '255.0.0.0',
  'address' => '127.0.0.1'
}
  ],
  'br0' => [
 {
   'netmask' => '255.255.255.0',
   'address' => '10.0.1.9'
 }
   ]
};
first_ip
$VAR1 = '10.0.1.9';
main_ip
$VAR1 = '10.0.1.9';

(error message from public(), 192.168.0.9 on br0 is missing in other calls)

After disabling legacy IP:

Can't use an undefined value as a symbol reference at 
/usr/share/perl5/Sys/HostAddr.pm line 60.
public
$VAR1 = undef;
interfaces
$VAR1 = [
  'br0',
  'eth0',
  'lo'
];
addresses
$VAR1 = [
  '127.0.0.1'
];
ip
$VAR1 = {
  'lo' => [
{
  'netmask' => '255.0.0.0',
  'address' => '127.0.0.1'
}
  ]
};
first_ip
main_ip

(a different error from public())


Thus, I wonder if there's a better module to do this task.


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

Bug#955833: please describe your "invalid data"

[Glenn Strauss]

> GET requests send invalid data for files above 30kB when connecting to the 
> server over http. But GET requests send good data when connecing over https.

What do you mean by "invalid data"?  Please be more specific.
What kind of requests?  Please be more specific.

It would be hightly unlikely that lighttpd would pass its unit tests and
yet be unable to server a static file.

Your minimal configuration is missing a basic mimetypes config which
would inform your browser of the Content-Type of the responses.

> include_shell "/usr/share/lighttpd/create-mime.conf.pl"

or, for testing purposes:

> mimetype.assign = (".html" => "text/html", ".png => "image/png" )

Bug#955995: octavia: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: octavia
Version: 5.0.1-1
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for octavia
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the octavia package.
# Helge Kreutzmann , 2020.
#
# See https://docs.openstack.org/octavia/latest/reference/glossary.html
#
msgid ""
msgstr ""
"Project-Id-Version: octavia 5.0.1-1\n"
"Report-Msgid-Bugs-To: octa...@packages.debian.org\n"
"POT-Creation-Date: 2019-12-31 16:09+0100\n"
"PO-Revision-Date: 2020-01-19 18:35+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../octavia-health-manager.templates:1001
msgid "Configure health-manager with debconf ?"
msgstr "Health-manager mit Debconf konfigurieren?"

#. Type: boolean
#. Description
#: ../octavia-health-manager.templates:1001
msgid ""
"Octavia health-manager needs to have bind_ip, bind_port and heartbeat_key "
"configured. This can be configured via debconf."
msgstr ""
"Octavia setzt voraus, dass bind_ip, bind_port und heartbeat_key konfiguriert "
"sind. Dies kann mittels Debconf erfolgen."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:2001
msgid "Value for health_manager bind_ip:"
msgstr "Wert für health_manager bind_ip:"

# HELPME heart beat?
#. Type: string
#. Description
#: ../octavia-health-manager.templates:2001
msgid ""
"IP address of Octavia health_manager on which will listen for heart beats. "
"This IP has to be in external octavia LB network to be able communicate with "
"amphora instances. This value will be set in config block health_manager "
"bind_ip."
msgstr ""
"IP-Adresse des health_manager von Octavia, auf der er auf Herzschläge warten "
"wird. Diese IP muss in einem externen Octavia-LB-Netz sein, um mit der "
"Amphora-Instanz zu kommunizieren. Dieser Wert wird im Konfigurationsblock "
"health_manager bind_ip gesetzt."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:3001
msgid "Value for health_manager bind_port:"
msgstr "Wert für health_manager bind_port:"

#. Type: string
#. Description
#: ../octavia-health-manager.templates:3001
msgid ""
"IP port of Octavia health_manager on which will listen for heart beats. This "
"value will be set in config block health_manager bind_port."
msgstr ""
"IP-Port von Octavias health_manager, auf der er auf Herzschläge warten wird. "
"Dieser Wert wird im Konfigurationsblock health_manager bind_port gesetzt."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:4001
msgid "Octavia's hearthbeat_key:"
msgstr "Octavias hearthbeat_key:"

#. Type: string
#. Description
#: ../octavia-health-manager.templates:4001
msgid ""
"Key used to validate amphora sending the message. This value will be set in "
"config block health_manager, heartbeat_key."
msgstr ""
"Mit diesem Schlüssel wird bestätigt, dass Amphora die Nachricht sendet. "
"Dieser Wert wird im Konfigurationsblock health_manager, heartbeat_key gesetzt."

Bug#955429: possiblity of using a different download agent like wget in bad internet connections

[Eduard Bloch]

Hallo,
* Pirate Praveen [Sun, Apr 05 2020, 11:13:32AM]:

> >So, simple questions:
> >- do you have enough skills to rebuild a Debian package from source?
>
> Yup, I maintain 100s of packages.
>
> >- would you like to assist in testing when you get an unofficial
> >  package? (and for which architecture?)
>
> Yes, amd64.

Great. Anyway, after digging in messy code for days, I decided to make a
regular release ASAP. Please check version 3.4-1 when it has hit your
mirrors. If the problem does not go away then, again, please provide a
raw tcp dump.

Best regards,
Eduard.

--
 n=amne@gentoo/developer/amne ; urgs sowas gibts ja wirklich
 ich dachte damit erschrickt man abends kleine Kinder
 "Sei ja artig, sonst kommt dich der böse Gentoo Entwickler holen"

Bug#955979: does not work with magit in Debian

[Antoine Beaupré]

Control: severity -1 normal

On 2020-04-05 23:32:39, Lev Lamberov wrote:
> I use Emacs and Emacs packages only from the Debian archive. No packages
> are installed from MELPA or _any_ other source. And... magit-todos works
> for me just fine. I'm not sure why, but I simply cannot reproduce this
> bug report.

On 2020-04-05 23:41:20, Lev Lamberov wrote:
> Hmm... I mean hitting M-x magit-todos-mode runs fine and TODOs are
> listed in magit status correctly, but I agree that magit-todos-list
> throws the error as you specified.

oooh! that's neat, i didn't realize that. :)

nice trick, i guess it's a good enough workaround to downgrade the
severity here...

thanks!

a.

Bug#955737: texlive-base: dangling symlinks /usr/bin/{allec,kpsepath,kpsexpand}

[Norbert Preining]

Hi Jochen,

> /usr/bin/{allec,kpsepath,kpsexpand} dangling symlinks in texlive-base.

Indeed, thanks for the report. Fixed for the next upload (which is
TL2020).

Best

Norbert

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

Bug#955993: annotate Build-Depends: libsodium-dev with

[Ryan Tandy]

Control: tag -1 pending

Right, thanks for catching that. Applied in git.

Bug#955981: libreoffice-gtk3: Bottom of the LibreOffice Writer print dialog window appears off-screen making it unusable.

[Rene Engelhard]

# mark as found in a ancestor (as in the bz bug)
# otherwise 1:6.4.3~rc3-* from experimental are not marked
# as affected (since 1:6.4.2-3 is branch, see the version tracking...)
found 955981 1:6.3.0-1
tag 955981 + upstream
forwarded 955981 https://bugs.documentfoundation.org/show_bug.cgi?id=127782
thanks

Hi,

On Sun, Apr 05, 2020 at 06:06:18PM +0100, Diogo wrote:
> The bottom of the LibreOffice Writer print dialog window appears off-screen
> making it unusable because the buttons are off-screen. (1366*768 screen
> resolution).

That is https://bugs.documentfoundation.org/show_bug.cgi?id=127782
upstream. Looks like the fix attempted for 6.4.2 didn't work.

Regards,

Rene

Bug#955438: Processed: Reassign to debhelper

[Niels Thykier]

Control: reassign -1 grpc

Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> reassign 955438 debhelper
> Bug #955438 [grpc] grpc: libupb.so.9 is not installed in any binary package
> Bug reassigned from package 'grpc' to 'debhelper'.
> No longer marked as found in versions 1.26.0-2.
> Ignoring request to alter fixed versions of bug #955438 to the same values 
> previously set
>> affects 955438 grpc
> Bug #955438 [debhelper] grpc: libupb.so.9 is not installed in any binary 
> package
> Added indication that 955438 affects grpc
>> retitle 955438 debhelper-compat 11 and 12 fails differently for grpc
> Bug #955438 [debhelper] grpc: libupb.so.9 is not installed in any binary 
> package
> Changed Bug title to 'debhelper-compat 11 and 12 fails differently for grpc' 
> from 'grpc: libupb.so.9 is not installed in any binary package'.
>> --
> Stopping processing here.
> 
> Please contact me if you need assistance.
> 

Hi Pirate Praveen

It is not really clear to me what you think the bug is.  But most likely
you are looking for #933541 or a newer version of dwz (if not possible,
use dh_dwz --no-dwz-multifile or skip dh_dwz).  Either way, it involves
bumping Build-Depends or changing the d/rules of grpc (possibly
"backports-only").

If you still feel there is something for debhelper to do, then I would
like you to be explicit about which part you consider the bug in
debhelper when reassigning the bug.

~Niels

Bug#955994: xen-utils-common: Could not start vif

[Samuel Thibault]

Package: xen-utils-common
Version: 4.11.3+24-g14b62ab3e5-1
Severity: normal
Tags: patch

Hello,

I was having issues with starting domains with vif-nat: 

♭ xl cr -c mydom
Parsing config from mydom
libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus: 
/etc/xen/scripts/vif-nat online [27191] exited with error status 1
libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb: script: 
/etc/xen/scripts/vif-nat failed; error detected.
libxl: error: libxl_create.c:1519:domcreate_attach_devices: Domain 25:unable to 
add vif devices
libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 25:Non-existant 
domain
libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 25:Unable to 
destroy guest
libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 25:Destruction of 
domain failed

It happens that it seems that's merely because handle_iptable() does not
pass a return value, and I guess the return value is thus that of the
latest command, which may not be true, and that makes vif-nat fail. The
attached patch fixes that.

Samuel

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

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

Versions of packages xen-utils-common depends on:
ii  libc6   2.30-2
ii  libxenstore3.0  4.11.3+24-g14b62ab3e5-1
ii  lsb-base11.1.0
ii  python  2.7.17-2
ii  ucf 3.0038+nmu1
ii  udev244.3-1
ii  xenstore-utils  4.11.3+24-g14b62ab3e5-1

xen-utils-common recommends no packages.

Versions of packages xen-utils-common suggests:
pn  xen-doc  

-- Configuration Files:
/etc/xen/scripts/vif-nat changed:
dir=$(dirname "$0")
. "$dir/vif-common.sh"
if [ -f /etc/dhcpd.conf ]
then
dhcp=${dhcp:-yes}
else
dhcp=${dhcp:-no}
fi
if [ "$dhcp" != 'no' ]
then
  dhcpd_conf_file=$(find_dhcpd_conf_file)
  dhcpd_init_file=$(find_dhcpd_init_file)
  dhcpd_arg_file=$(find_dhcpd_arg_file)
  if [ -z "$dhcpd_conf_file" ] || [ -z "$dhcpd_init_file" ] || [ -z 
"$dhcpd_arg_file" ]
  then
echo 'Failed to find dhcpd configuration or init or args file.' >&2
exit 1
  fi
fi
domid=$(xenstore_read "$XENBUS_PATH/frontend-id")
vifid=$(xenstore_read "$XENBUS_PATH/handle")
vifid=$(( $vifid + 1 ))
ip_from_dom()
{
  local domid1=$(( $domid / 256 ))
  local domid2=$(( $domid % 256 ))
  echo "10.$domid1.$domid2.$vifid/16"
}
routing_ip()
{
  echo $(echo $1 | awk -F. '{print $1"."$2"."$3"."$4 + 127}')
}
dotted_quad()
{
 echo\
 $(( ($1 & 0xFF00) >> 24))\
.$(( ($1 & 0x00FF) >> 16))\
.$(( ($1 & 0xFF00) >> 8 ))\
.$((  $1 & 0x00FF   ))
}
if [ "$ip" = "" ]
then
  ip=$(ip_from_dom)
fi
router_ip=$(routing_ip "$ip")
vif_ip=`echo ${ip} | awk -F/ '{print $1}'`
hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-')
if [ "$vifid" != "1" ]
then
  hostname="$hostname-$vifid"
fi
dhcparg_remove_entry()
{
  local tmpfile=$(mktemp)
  sed -e "s/${dev} //" "$dhcpd_arg_file" >"$tmpfile"
  if diff "$tmpfile" "$dhcpd_arg_file" >/dev/null
  then
rm "$tmpfile"
  else
mv "$tmpfile" "$dhcpd_arg_file"
  fi
}
dhcparg_add_entry()
{
  dhcparg_remove_entry
  local tmpfile=$(mktemp)
  # handle Red Hat, SUSE, and Debian styles, with or without quotes
  sed -e 's/^DHCPDARGS="*\([^"]*\)"*/DHCPDARGS="\1'"${dev} "'"/' \
 "$dhcpd_arg_file" >"$tmpfile" && mv "$tmpfile" "$dhcpd_arg_file"
  sed -e 's/^DHCPD_INTERFACE="*\([^"]*\)"*/DHCPD_INTERFACE="\1'"${dev} "'"/' \
 "$dhcpd_arg_file" >"$tmpfile" && mv "$tmpfile" "$dhcpd_arg_file"
  sed -e 's/^INTERFACES="*\([^"]*\)"*/INTERFACES="\1'"${dev} "'"/' \
 "$dhcpd_arg_file" >"$tmpfile" && mv "$tmpfile" "$dhcpd_arg_file"
  rm -f "$tmpfile"
}
dhcp_remove_entry()
{
  local tmpfile=$(mktemp)
  grep -v "host $hostname" "$dhcpd_conf_file" >"$tmpfile"
  if diff "$tmpfile" "$dhcpd_conf_file" >/dev/null
  then
rm "$tmpfile"
  else
mv "$tmpfile" "$dhcpd_conf_file"
  fi
  dhcparg_remove_entry
}
dhcp_up()
{
  claim_lock "vif-nat-dhcp"
  dhcp_remove_entry
  mac=$(xenstore_read "$XENBUS_PATH/mac")
  echo >>"$dhcpd_conf_file" \
"host $hostname { hardware ethernet $mac; fixed-address $vif_ip; option routers 
$router_ip; option host-name \"$hostname\"; }"
  dhcparg_add_entry
  release_lock "vif-nat-dhcp"
  "$dhcpd_init_file" restart || true
}
dhcp_down()
{
  claim_lock "vif-nat-dhcp"
  dhcp_remove_entry
  release_lock "vif-na

Bug#955993: annotate Build-Depends: libsodium-dev with

[Helmut Grohne]

Source: openldap
Version: 2.4.49+dfsg-3
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

openldap recently gained a build dependency on libsodium-dev. It turns
out that it is only needed for a slapd module, so it can be disabled
with the pkg.openldap.noslapd build profile. Doing so reduces the amount
of packages required for a cross bootstrap. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru openldap-2.4.49+dfsg/debian/changelog 
openldap-2.4.49+dfsg/debian/changelog
--- openldap-2.4.49+dfsg/debian/changelog   2020-04-04 19:43:56.0 
+0200
+++ openldap-2.4.49+dfsg/debian/changelog   2020-04-05 15:18:24.0 
+0200
@@ -1,3 +1,11 @@
+openldap (2.4.49+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate libsodium-dev dependency with .
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Apr 2020 15:18:24 +0200
+
 openldap (2.4.49+dfsg-3) unstable; urgency=medium
 
   * Drop patch no-AM_INIT_AUTOMAKE. Instead, configure dh_autoreconf to skip
diff --minimal -Nru openldap-2.4.49+dfsg/debian/control 
openldap-2.4.49+dfsg/debian/control
--- openldap-2.4.49+dfsg/debian/control 2020-04-04 19:43:56.0 +0200
+++ openldap-2.4.49+dfsg/debian/control 2020-04-05 15:18:24.0 +0200
@@ -14,7 +14,7 @@
libltdl-dev ,
libperl-dev (>= 5.8.0) ,
libsasl2-dev,
-   libsodium-dev,
+   libsodium-dev ,
libwrap0-dev ,
nettle-dev ,
perl:any,

Bug#952102: salmon: FTBFS: SalmonAlevin.cpp:780:6: error: ‘class rapmap::utils::MappingConfig’ has no member named ‘maxSlack’

[Alberto Garcia]

On Sun, Feb 23, 2020 at 09:02:55AM +0100, Lucas Nussbaum wrote:

> > /<>/src/SalmonAlevin.cpp: In function ‘void 
> > processReadsQuasi(alevin::paired_parser*, ReadExperimentT&, ReadLibrary&, 
> > alevin::AlnGroupVec&, std::atomic > unsigned int>&, std::atomic&, std::atomic > int>&, std::atomic&, std::atomic&, 
> > std::atomic&, RapMapIndexT*, std::vector&, 
> > ForgettingMassCalculator&, ClusterForest&, FragmentLengthDistribution&, 
> > BiasParams&, SalmonOpts&, std::mutex&, bool, std::atomic&, volatile 
> > bool&, AlevinOpts&, SoftMapT&, 
> > spp::sparse_hash_map, unsigned int>&)’:
> > /<>/src/SalmonAlevin.cpp:780:6: error: ‘class 
> > rapmap::utils::MappingConfig’ has no member named ‘maxSlack’
> >   780 |   mc.maxSlack = salmonOpts.consensusSlack;
> >   |  ^~~~
> > make[4]: *** [src/CMakeFiles/salmon.dir/build.make:274: 
> > src/CMakeFiles/salmon.dir/SalmonAlevin.cpp.o] Error 1

This usage of mc.maxSlack was already removed upstream last year, see

   
https://github.com/COMBINE-lab/salmon/commit/056f9c357a2b28ebcd5db923c53a1ea635bf88dd

I guess that the salmon package simply needs to be updated to the
most recent upstream version (latest is 1.1.0, Debian has 0.12.0 from
2018).

Berto

Bug#955991: mark pccts Multi-Arch: foreign

[Helmut Grohne]

Package: pccts
Version: 1.33MR33-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:

 fails to cross build from source, because it fails running antlr
with an Exec format error. Usually, that indicates that the relevant
package should be marked Multi-Arch: foreign. In this case, I think that
such a marking is correct. pccts can generally be described as a parser
generator. As such it converts a textual syntax description into source
code for a programming language (C or C++). Since both formats it deals
with are textual, the behaviour can be assumed architecture-independent.
Please consider applying the attached patch.

Helmut
diff -u pccts-1.33MR33/debian/changelog pccts-1.33MR33/debian/changelog
--- pccts-1.33MR33/debian/changelog
+++ pccts-1.33MR33/debian/changelog
@@ -1,3 +1,10 @@
+pccts (1.33MR33-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark pccts Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Apr 2020 14:59:09 +0200
+
 pccts (1.33MR33-6) unstable; urgency=low
 
   * Updating to standards 3.8.3.
diff -u pccts-1.33MR33/debian/control pccts-1.33MR33/debian/control
--- pccts-1.33MR33/debian/control
+++ pccts-1.33MR33/debian/control
@@ -7,6 +7,7 @@
 
 Package: pccts
 Architecture: any
+Multi-Arch: foreign
 Replaces: sorcerer
 Provides: sorcerer
 Depends: ${shlibs:Depends}, ${misc:Depends}

Bug#955992: qwinff FTCBFS: uses the build architecture qmake

[Helmut Grohne]

Source: qwinff
Version: 0.2.1+git20191128-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qwinff fails to cross build from source, because it uses the build
architecture qmake. Please use the host architecture qmake. I've
attached a patch for your convenience.

Helmut
diff --minimal -Nru qwinff-0.2.1+git20191128/debian/changelog 
qwinff-0.2.1+git20191128/debian/changelog
--- qwinff-0.2.1+git20191128/debian/changelog   2019-11-28 10:31:49.0 
+0100
+++ qwinff-0.2.1+git20191128/debian/changelog   2020-04-05 20:48:24.0 
+0200
@@ -1,3 +1,10 @@
+qwinff (0.2.1+git20191128-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Apr 2020 20:48:24 +0200
+
 qwinff (0.2.1+git20191128-1) unstable; urgency=medium
 
   * New upstream version. (Closes: #945602)
diff --minimal -Nru qwinff-0.2.1+git20191128/debian/rules 
qwinff-0.2.1+git20191128/debian/rules
--- qwinff-0.2.1+git20191128/debian/rules   2019-11-28 10:31:49.0 
+0100
+++ qwinff-0.2.1+git20191128/debian/rules   2020-04-05 20:48:24.0 
+0200
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE = 1
 
+include /usr/share/dpkg/architecture.mk
+
 # see FEATURE AREAS in dpkg-buildflags(1)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
@@ -18,9 +20,12 @@
dh $@
 
 override_dh_auto_configure:
-   qmake -makefile PREFIX=$(shell pwd)/qwinff/usr src/qwinff.pro
+   $(DEB_HOST_GNU_TYPE)-qmake -makefile PREFIX=$(shell pwd)/qwinff/usr 
src/qwinff.pro
sed -i "s,-DQT_NO_DEBUG,,g" Makefile
sed -i 's/^CXXFLAGS.*/& -g/g' Makefile
 
+override_dh_auto_build:
+   dh_auto_build -- QMAKE=$(DEB_HOST_GNU_TYPE)-qmake
+
 override_dh_auto_install:
@echo skip install target

Bug#954579: datalad-container: FTBFS: build-dependency not installable: datalad (>= 0.11.5~)

[Scott Kitterman]

What's the status on getting this fixed?  This is causing quite a backlog on 
Testing migration.

requests Migrates after: datalad-container
python-urllib3 Migrates after: requests
python-certifi Migrates after: requests
python-pip Migrates after: python-certifi, python-urllib3, requests

Those I the ones I know of since I'm tyring to get python-pip to migrate.

Scott K

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

Bug#933378: bug report should go upstream

[Carsten Schoenert]

Am 05.04.20 um 20:08 schrieb David Christensen:
> I have created a bug report here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1627528

Thanks, added that bug number to this Debian bug.

> I reinstalled my system on February 2, 2020, using the ext4 filesystem 
> for root (and home).  Thunderbird is still misbehaving,  Same for Thunar.

You've created a new profile too?
The most problems that get reported are in the end grounded on
misbehaving of the local profile.

-- 
Regards
Carsten Schoenert

Bug#955989: O: didiwiki -- simple wiki implementation with built-in webserver

[Ignace Mouzannar]

Package: wnpp
Severity: normal

This package was my first official Debian package [1]. A first step in
what became a passion for FOSS and its open philosophy. I am so grateful
for having decided to follow this Debian maintainer path. I am
unfortunately unable to maintain my packages anymore, and therefore am
orphaning them.

A big thank you to all Debian contributors. Your contributions are
making this world a better place. <3

Package: https://tracker.debian.org/pkg/didiwiki

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531177





signature.asc
Description: OpenPGP digital signature

Bug#955990: terminator: Switching upstream

[Markus Frosch]

Package: terminator
Version: 1.91-4
Severity: normal
Tags: upstream

I plan to switch upstream to the new organziation on GitHub within the
next weeks: https://github.com/gnome-terminator/terminator

Disclaimer: I'm managing upstream and also act as the maintainer in
Debian.

Please see this issue for details on why:
https://github.com/gnome-terminator/terminator/issues/1

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

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

Versions of packages terminator depends on:
ii  dbus-x11   1.12.16-2
ii  gir1.2-glib-2.01.64.0-2
ii  gir1.2-gtk-3.0 3.24.14-1
ii  gir1.2-pango-1.0   1.42.4-8
ii  gir1.2-vte-2.910.60.1-1
ii  python33.8.2-2
ii  python3-cairo  1.16.2-2
ii  python3-configobj  5.0.6-3
ii  python3-dbus   1.2.16-1
ii  python3-gi 3.36.0-1
ii  python3-gi-cairo   3.36.0-1
ii  python3-psutil 5.6.7-2

Versions of packages terminator recommends:
ii  gir1.2-keybinder-3.0  0.3.2-1+b1
ii  gir1.2-notify-0.7 0.7.9-1
ii  xdg-utils 1.1.3-2

terminator suggests no packages.

-- no debconf information

Bug#948858: rtorrent: Segfaults with "session.save = yes"

[user]

Package: rtorrent
Followup-For: Bug #948858

Fix NULL pointer dereference
https://github.com/rakshasa/rtorrent/pull/977/commits/09301fecc95857ae43c3d8abbe46ba34d8b09586

Bug#955987: O: gip -- IP calculator for GNOME desktop environment

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/gip

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M





signature.asc
Description: OpenPGP digital signature

Bug#955979: does not work with magit in Debian

[Lev Lamberov]

Вс 05 апр 2020 @ 13:40 Antoine Beaupre :

> magit-todos, as packaged in Debian, does not work. It seems to assume
> a magit version that is not present in Debian. When I run "M-x
> magit-todos" I get the error:
>
>magit-todos-list-internal: Symbol’s function definition is void: 
> magit-setup-buffer

Hmm... I mean hitting M-x magit-todos-mode runs fine and TODOs are
listed in magit status correctly, but I agree that magit-todos-list
throws the error as you specified.

Regards,
Lev

Bug#955988: O: aqemu -- Qt5 front-end for QEMU and KVM

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/aqemu

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M





signature.asc
Description: OpenPGP digital signature

Bug#955986: O: iptotal -- monitor for IP traffic, not requiring SNMP

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/iptotal

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M





signature.asc
Description: OpenPGP digital signature

Bug#955985: O: kdocker -- lets you dock any application into the system tray

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/kdocker

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M



signature.asc
Description: OpenPGP digital signature

Bug#955983: O: tenshi -- https://tracker.debian.org/pkg/tenshi

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/tenshi

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M



signature.asc
Description: OpenPGP digital signature

Bug#955984: O: kiki -- tool for python regular expression testing

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/kiki

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M



signature.asc
Description: OpenPGP digital signature

Bug#955979: does not work with magit in Debian

[Lev Lamberov]

Hi Antoine,

Вс 05 апр 2020 @ 13:40 Antoine Beaupre :

> Package: elpa-magit-todos
> Version: 1.5.2-1
> Severity: grave
>
> magit-todos, as packaged in Debian, does not work. It seems to assume
> a magit version that is not present in Debian. When I run "M-x
> magit-todos" I get the error:
>
>magit-todos-list-internal: Symbol’s function definition is void: 
> magit-setup-buffer
>
> The debugger trace is this:
>
> Debugger entered--Lisp error: (void-function magit-setup-buffer)
>   magit-setup-buffer(magit-todos-list-mode)
>   magit-todos-list-internal("/home/anarcat/src/tor/tsa-misc/")
>   magit-todos-list(nil)
>   funcall-interactively(magit-todos-list nil)
>   call-interactively(magit-todos-list record nil)
>   command-execute(magit-todos-list record)
>   execute-extended-command(nil "magit-todos-list" nil)
>   funcall-interactively(execute-extended-command nil "magit-todos-list" nil)
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)
>
> I reported this in the ITP but it seems that problem was either
> disregarded or overlooked:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951450#10
>
> It's also been reported upstream:
>
> https://github.com/alphapapa/magit-todos/issues/87
>
> The response there was:
>
>> Unfortunately, that doesn't matter. Magit is a moving target, and
>> it's not feasible for me to produce "stable" versions in sync with
>> Magit "stable" versions. Magit does not coordinate its changes with
>> me. So when Magit suddenly breaks this package for 99% of users
>> without warning, I have to fix it, and that means breaking things
>> for older Magit versions.
>>
>> If you insist on not upgrading Magit, you could use a version of
>> this package from before that change was made.
>
> It's too bad this newer version was packaged instead of a working
> version because now it would be difficult to reverse this without
> adding an epoch to the version number.
>
> In any case, this is definitely broken right now in Debian, unless we
> install magit from *outside* Debian. If that's what is expected of
> magit-todos users, the package does not belong in main (because it
> requires packages outside of main) but rather contrib.
>
> Alternatively, maybe we can just hope magit will be released upstream
> (as it's been promised since november) and that this will fix itself
> when it lands in Debian (#952560), but I have kind of stopped hoping
> for that at this point... :/

I use Emacs and Emacs packages only from the Debian archive. No packages
are installed from MELPA or _any_ other source. And... magit-todos works
for me just fine. I'm not sure why, but I simply cannot reproduce this
bug report.

Regards,
Lev

Bug#955982: O: alltray -- Dock any program into the system tray

[Ignace Mouzannar]

Package: wnpp
Severity: normal

I'm seeking somebody to adopt this package:
https://tracker.debian.org/pkg/alltray

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

I'm happy to help transition packages if needed.

 Ignace M



signature.asc
Description: OpenPGP digital signature

Bug#731435: warning: iteration 55823u invokes undefined behavior [-Waggressive-loop-optimizations]

[Alberto Garcia]

On Thu, Dec 05, 2013 at 02:00:59PM +0100, Mathieu Malaterre wrote:
> /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c: In function 'rgb_ycc_start':
> /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c:99:43: warning: iteration
> 55823u invokes undefined behavior [-Waggressive-loop-optimizations]
>  rgb_ycc_tab[i+G_Y_OFF] = FIX(0.58700) * i;
>^
> /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c:97:3: note: containing loop
>for (i = 0; i <= MAXJSAMPLE; i++) {
>^

This has already been reported upstream, and it seems exactly the same
as #731433, which was fixed upstream in DCMTK:

   https://support.dcmtk.org/redmine/issues/759

Berto

Bug#933378: bug report should go upstream

[David Christensen]

I have created a bug report here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1627528


I reinstalled my system on February 2, 2020, using the ext4 filesystem 
for root (and home).  Thunderbird is still misbehaving,  Same for Thunar.



David

Bug#955812: gedit-latex-plugin does not work anymore

[Matthias Brennwald]

I ran gedit from the terminal. There was no warning, error or other 
message.



On So, 5 Apr, 2020 at 12:46, Pietro Battiston  
wrote:

Matthias, thank you for your report.

Indeed, I still didn't test the plugin with gedit version later 
3.30.2.


Could you please try running gedit from the terminal (with "-s" if you
have other windows open already) and report any warning/error message?

Thanks,

Pietro



Il giorno dom, 05/04/2020 alle 10.06 +0200, Matthias Brennwald ha
scritto:

 Package: gedit-latex-plugin
 Version: 3.20.0-1
 Severity: important

 I am running on Debian Testing. Since pulling in an upgrade
 yesterday, the
 gedit-latex-plugin does not work anymore. The gedit bottom panel 
used

 to show
 the LaTeX stuff, now it's just empty. Running the LaTeX compiler 
from

 within
 gedit (CTRL-ALT-1) does nothing. This happened to me on two 
different

 machines.
 I confirmed the plugin is activated in the gedit preferences.



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

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

 Versions of packages gedit-latex-plugin depends on:
 ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
 ii  gedit3.36.1-1
 ii  gvfs-bin 1.44.1-1
 ii  python3  3.8.2-2
 ii  python3-dbus 1.2.16-1
 ii  python3-gi   3.36.0-1
 ii  rubber   1.5.1-2

 Versions of packages gedit-latex-plugin recommends:
 ii  texlive  2019.20200302-1

 gedit-latex-plugin suggests no packages.

 -- no debconf information

Bug#955981: libreoffice-gtk3: Bottom of the LibreOffice Writer print dialog window appears off-screen making it unusable.

[Diogo]

Package: libreoffice-gtk3
Version: 1:6.4.2-3
Severity: important

Dear Maintainer,

The bottom of the LibreOffice Writer print dialog window appears off-screen
making it unusable because the buttons are off-screen. (1366*768 screen
resolution).

I tried to resize it but it wasn't possible.

A scroll bar is expected to exist on the right side to move the contents of the
dialog window.

Feel free to contact me in need of more information.

Thank you

Diogo

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

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

Versions of packages libreoffice-gtk3 depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libepoxy01.5.4-1
ii  libgcc-s110-20200324-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.14-1
ii  libpango-1.0-0   1.42.4-8
ii  libreoffice-core 1:6.4.2-3
ii  libstdc++6   10-20200324-1
ii  libuno-cppu3 1:6.4.2-3
ii  libuno-cppuhelpergcc3-3  1:6.4.2-3
ii  libuno-sal3  1:6.4.2-3
ii  libx11-6 2:1.6.9-2
ii  uno-libs-private 1:6.4.2-3
ii  ure  1:6.4.2-3

Versions of packages libreoffice-gtk3 recommends:
ii  gstreamer1.0-gtk3  1.16.2-3

Versions of packages libreoffice-gtk3 suggests:
ii  libreofficekit-data  1:6.4.2-3

-- no debconf information

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 05/04/2020 à 18:57 :
> On 2020-04-05 22:34, Gilles Filippini wrote:
>> I suspect a mismatch between mpi and serial build-depdencies:
>>
>> python3-h5py-serial + libhdf5-dev    => OK
>> python3-h5py-serial + libhdf5-openmpi-dev    => KO
>> python3-h5py-mpi + libhdf5-dev    => KO
>> python3-h5py-mpi + libhdf5-openmpi-dev    => KO(*)
>>
>> (*) because it fails to import h5py submodules when python3-h5py-serial
>> is not installed:
>> ImportError: cannot import name 'h5f' from 'h5py' (unknown location)
>>
>> With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
>> flavour, while building against 'serial' flavour requires serial flavour
>> of libhdf5 -dev package as well.
> 
> 
> I've set up h5py so that the mpi build is only invoked when actually run
> with mpirun. In that sense the two builds are complementary rather than
> replacements (there was complaining that module loading was too slow
> when I had h5py built only against hdf5-mpi).  It seemed to me that's
> desirable to allow both serial and mpi builds of h5py to be installable
> at the same time, just as libhdf_*.so is, so I didn't want
> python3-h5py-serial and python3-h5py-mpi to Replace and Conflicts with
> each other.
> 
> Probably this is what's going on. bitshuffle is trying to make an mpi
> build, but running the build single processor so h5py accesses hdf5-serial.
> 
> In that case, running the bitshuffle mpi build in mpi might help, as in
> "mpirun -n 1 python3 setup.py". Not sure if that would be easy to do,
> e.g. if it's as "simple" as
> 
> override_dh_auto_build:
> 
>     mpirun -n 1 dh_auto_build
> 
> Another option is to create an environment variable to force h5py to
> load the mpi version even when run in a serial environment without
> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
> -n 1 dh_auto_build" or a variation of that is viable.  Maybe
> %:
> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild

This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:

I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13

But the HDF5 error is no more present with python3.7. So it seems a good
point.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955980: rxvt-unicode: please disable PrintScreen by default

[David Bremner]

Package: rxvt-unicode
Version: 9.22-6+b2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The default behaviour of silently sending scrollback to the default
printer when PrintScreen is pressed seems like it is asking for private data 
leakage.

Apparently it can be disabled by setting XResources, but it would be
better IMHO if it needed to be enabled by those people who actually
want it.

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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.5.47
ii  libc6 2.30-4
ii  libfontconfig12.13.1-2+b1
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:10-20200324-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libglib2.0-0  2.64.1-1
ii  libperl5.30   5.30.0-9
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.9-2
ii  libxft2   2.3.2-2
ii  libxrender1   1:0.9.10-1
ii  ncurses-base  6.2-1
ii  ncurses-term  6.2-1

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-1
ii  fonts-vlgothic [fonts-japanese-gothic]  20141206-5

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.12+nmu1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl6KGRcACgkQA0U5G1Wq
FSFesxAAgsTgEz+gO91lcvCSkFWwsKu5LazHRKQUiYLaN6h0hZwtkOh6szq/ZmSW
gCG3DdIQY27D4Ar0waUL+wVc0OpZH502RvzAxNcZ+LLNRkfNhQSWI8sovzFwHd+Z
zAI6JzypZwPNSI1ag54O1QWXKKL7yf1YJxZupT9Rni04BbiqIBP0CEYtW1LTzoVV
VLk2ul5pxEnOI9c/g86eaDlHv2Ko6LmpEJ1d+u5OrENXFKp+HDmcooVXwOQbEVgZ
kzXPR9yBVq0tVmnqZKeIMyHNjBnxDPzcmIh4OzL5kYBvHrIBLQw1+1Ua0T48InZT
O9meV0qJn1cZQqgLTqnbAZmTFE9SkXNisR5W2bl/Ecwylp3kyrJrD3zF06YgS/aD
m7VQE84YXLcZeMxw5ODv8J8wUvum0rDHlhYnZmHNe26IlUSII59LQdmZHfJLHbSC
WxjAoBPJSxAzHdP3wW07Q9SCDv8pbpSc7QNrFQC4pEMHdQkweZO+iyqUVgxgZ+cH
yHcM5Wz5FLSQqXnyjMojOpU1O4RiuIHjoGtFlHkyZ3byde3xZgoxxvGmcy1FxqFd
Gd9jg16cHm9cy5KP9MK2U1kAMTpdhX3uSl9XTt1qPsHFOqQDZ2YtC6xTIPrDN86a
aZ+bOQFw1VsIno0c/2/I6HnozeewLS69qqlfRErYMJOdBuKXrds=
=zSkQ
-END PGP SIGNATURE-

Bug#955979: does not work with magit in Debian

[Antoine Beaupre]

Package: elpa-magit-todos
Version: 1.5.2-1
Severity: grave

magit-todos, as packaged in Debian, does not work. It seems to assume
a magit version that is not present in Debian. When I run "M-x
magit-todos" I get the error:

   magit-todos-list-internal: Symbol’s function definition is void: 
magit-setup-buffer

The debugger trace is this:

Debugger entered--Lisp error: (void-function magit-setup-buffer)
  magit-setup-buffer(magit-todos-list-mode)
  magit-todos-list-internal("/home/anarcat/src/tor/tsa-misc/")
  magit-todos-list(nil)
  funcall-interactively(magit-todos-list nil)
  call-interactively(magit-todos-list record nil)
  command-execute(magit-todos-list record)
  execute-extended-command(nil "magit-todos-list" nil)
  funcall-interactively(execute-extended-command nil "magit-todos-list" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

I reported this in the ITP but it seems that problem was either
disregarded or overlooked:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951450#10

It's also been reported upstream:

https://github.com/alphapapa/magit-todos/issues/87

The response there was:

> Unfortunately, that doesn't matter. Magit is a moving target, and
> it's not feasible for me to produce "stable" versions in sync with
> Magit "stable" versions. Magit does not coordinate its changes with
> me. So when Magit suddenly breaks this package for 99% of users
> without warning, I have to fix it, and that means breaking things
> for older Magit versions.
>
> If you insist on not upgrading Magit, you could use a version of
> this package from before that change was made.

It's too bad this newer version was packaged instead of a working
version because now it would be difficult to reverse this without
adding an epoch to the version number.

In any case, this is definitely broken right now in Debian, unless we
install magit from *outside* Debian. If that's what is expected of
magit-todos users, the package does not belong in main (because it
requires packages outside of main) but rather contrib.

Alternatively, maybe we can just hope magit will be released upstream
(as it's been promised since november) and that this will fix itself
when it lands in Debian (#952560), but I have kind of stopped hoping
for that at this point... :/

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

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

Versions of packages elpa-magit-todos depends on:
ii  dh-elpa-helper  2.0.2~bpo10+2
ii  elpa-async  1.9.3-1
ii  elpa-dash   2.14.1+dfsg-1
ii  elpa-f  0.20.0-1
ii  elpa-hl-todo2.2.0-1
ii  elpa-magit  2.90.1-2
ii  elpa-pcre2el1.8-1
ii  elpa-s  1.12.0-2
ii  emacsen-common  3.0.4

Versions of packages elpa-magit-todos recommends:
ii  emacs  1:26.1+1-3.2+deb10u1
ii  emacs-gtk [emacs]  1:26.1+1-3.2+deb10u1
ii  git1:2.20.1-2+deb10u1

elpa-magit-todos suggests no packages.

-- no debconf information

Bug#955977: openldap: No manual page for module 'pw-argon2'

[Ryan Tandy]

Hi Peter, thanks again for contributing these man pages. I will include 
this in the next upload. (Maybe just the man page; I'm not installing 
its README in the package right now, and probably won't, now that there 
is a man page.)


Is there already an ITS# for this one? I searched the bugzilla just now 
but didn't find it. Thank you!

Bug#951984: tree-puzzle: FTBFS: mpi.h:322:57: error: static assertion failed: "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead."

[Alberto Garcia]

Control: tags -1 patch

On Sun, Feb 23, 2020 at 08:39:23AM +0100, Lucas Nussbaum wrote:

> >  2842 | #define MPI_Address(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Address, MPI_Get_address)
> >  2850 | #define MPI_Type_struct(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Type_struct, MPI_Type_create_struct)

So tree-puzzle uses two symbols from MPI-2.0 that have been deprecated
in MPI-3.0. Fortunately in both cases the only change is the name of
the symbol, and it's not necessary to do anything else.

See here for details:

   https://www.open-mpi.org/faq/?category=mpi-removed

The attached patch fixes the build. The latest upstream release
candidate still uses the old symbol btw.

Berto
From: Alberto Garcia 
Subject: Replace obsolete MPI-2.0 API with their MPI-3.0 equivalents
Bug-Debian: https://bugs.debian.org/951984
Index: tree-puzzle-5.2/src/ppuzzle.c
===
--- tree-puzzle-5.2.orig/src/ppuzzle.c
+++ tree-puzzle-5.2/src/ppuzzle.c
@@ -21,11 +21,14 @@
 #endif
 
 #define EXTERN extern
+#define OMPI_OMIT_MPI1_COMPAT_DECLS 1
  
 #include 
 #include 
 #include "ppuzzle.h"
  
+#define MPI_Address MPI_Get_address
+#define MPI_Type_struct MPI_Type_create_struct
 
 int PP_IamMaster;
 int PP_IamSlave;

Bug#955978: should ship policies file to fix Thunderbird TLS/SSL setup

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.65+deb10u4
Severity: important

Since some time, new users are faced with an 'insecure certificate' and 
have to accept it if they want to use mail inside the internal Debian Edu 
network.

Reason for this has been a change in the way Thunderbird sets up 
profiles (randomly named subdir).

Now that Thunderbird support for system-wide policies has been enabled, 
it is easy to fix it:

A policy file /usr/lib/thunderbird/distribution/policies.json will make 
sure that the Debian-Edu_rootCA.crt file gets installed as trusted 
certificate for Thunderbird.

File content:

{
  "policies": {
"Certificates": {
  "ImportEnterpriseRoots": true,
  "Install": [
"/etc/ssl/certs/Debian-Edu_rootCA.crt"
  ]
}
  }
}

Wolfgang


signature.asc
Description: PGP signature

Bug#955977: openldap: No manual page for module 'pw-argon2'

[Peter Marschall]

Source: openldap
Version: 2.4.49+dfsg-3
Severity: normal
Tags: patch upstream

Hi,

the pw-argon2 password module, which was backported from upstream master,
lacks a manual page.

Please find attached patches to upstream to fix the issue not only for Debian
but for all OpenLDAP users.
(@Ryan: thanks for implementing some of the changes I proposed to upstream's 
ITS)

Thanks for working on OpenLDAP upstream and maintaining it in Debian
Peter

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From b32a42144df54e6872113fcf5ccb561ecad47878 Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Sun, 5 Apr 2020 14:20:57 +0200
Subject: [PATCH 1/2] contrib/passwd/argon2: add manual page

Add manual page slapd-pw-argon2.5 and make sure it gets installed.

Signed-off-by: Peter Marschall 
---
 contrib/slapd-modules/passwd/argon2/Makefile  | 14 ++-
 .../passwd/argon2/slapd-pw-argon2.5   | 97 +++
 2 files changed, 110 insertions(+), 1 deletion(-)
 create mode 100644 contrib/slapd-modules/passwd/argon2/slapd-pw-argon2.5

diff --git a/contrib/slapd-modules/passwd/argon2/Makefile 
b/contrib/slapd-modules/passwd/argon2/Makefile
index b35d7a36f..093bd8fb0 100644
--- a/contrib/slapd-modules/passwd/argon2/Makefile
+++ b/contrib/slapd-modules/passwd/argon2/Makefile
@@ -7,6 +7,7 @@ LDAP_LIB = $(LDAP_BUILD)/libraries/libldap_r/libldap_r.la \
$(LDAP_BUILD)/libraries/liblber/liblber.la
 
 LIBTOOL = $(LDAP_BUILD)/libtool
+INSTALL = /usr/bin/install
 CC = gcc
 OPT = -g -O2 -Wall
 #DEFS = -DSLAPD_ARGON2_DEBUG
@@ -27,6 +28,7 @@ $(error Unsupported implementation $(implementation))
 endif
 
 PROGRAMS = pw-argon2.la
+MANPAGES = slapd-pw-argon2.5
 LTVER = 0:0:0
 
 #prefix=/usr/local
@@ -38,6 +40,8 @@ ldap_subdir=/openldap
 libdir=$(exec_prefix)/lib
 libexecdir=$(exec_prefix)/libexec
 moduledir = $(libexecdir)$(ldap_subdir)
+mandir = $(exec_prefix)/share/man
+man5dir = $(mandir)/man5
 
 .SUFFIXES: .c .o .lo
 
@@ -53,8 +57,16 @@ pw-argon2.la: pw-argon2.lo
 clean:
rm -rf *.o *.lo *.la .libs
 
-install:   $(PROGRAMS)
+install: install-lib install-man FORCE
+
+install-lib: $(PROGRAMS)
mkdir -p $(DESTDIR)$(moduledir)
for p in $(PROGRAMS) ; do \
$(LIBTOOL) --mode=install cp $$p $(DESTDIR)$(moduledir) ; \
done
+
+install-man: $(MANPAGES)
+   mkdir -p  $(DESTDIR)$(man5dir)
+   $(INSTALL) -m 644 $(MANPAGES) $(DESTDIR)$(man5dir)
+
+FORCE:
diff --git a/contrib/slapd-modules/passwd/argon2/slapd-pw-argon2.5 
b/contrib/slapd-modules/passwd/argon2/slapd-pw-argon2.5
new file mode 100644
index 0..a8b6a8022
--- /dev/null
+++ b/contrib/slapd-modules/passwd/argon2/slapd-pw-argon2.5
@@ -0,0 +1,97 @@
+.TH SLAPD-PW-ARGON2 5 "RELEASEDATE" "OpenLDAP LDVERSION"
+.\" Copyright 2020 The OpenLDAP Foundation All Rights Reserved.
+.\" Copying restrictions apply.  See COPYRIGHT/LICENSE.
+.\" $OpenLDAP$
+.SH NAME
+slapd-pw-argon2 \- Argon2 password module to slapd
+.SH SYNOPSIS
+ETCDIR/slapd.conf
+.RS
+.LP
+.B moduleload
+.B pw-argon2
+.RE
+.SH DESCRIPTION
+.LP
+The
+.B pw-argon2
+module to
+.BR slapd (8)
+provides support for the use of the key derivation function Argon2,
+that was selected as the winner of the Password Hashing Competition in July 
2015,
+in hashed passwords in OpenLDAP.
+.LP
+It does so by providing the additional password scheme 
+.B {ARGON2}
+for use in slapd.
+
+.SH CONFIGURATION
+The
+.B pw-argon2
+module does not need any configuration.
+.LP
+After loading the module, the password scheme
+.B {ARGON2}
+will be recognised in values of the
+.I userPassword
+attribute.
+.LP
+You can then instruct OpenLDAP to use this scheme when processing
+the LDAPv3 Password Modify (RFC 3062) extended operations by using the
+.BR password-hash
+option in
+.BR slapd.conf (5):
+.RS
+.LP
+.BR password-hash  {ARGON2}
+.RE
+.LP
+
+.SS NOTES
+If you want to use the scheme described here with
+.BR slappasswd (8),
+remember to load the module using its command line options.
+The relevant option/value is:
+.RS
+.LP
+.B \-o
+.BR module\-load = pw-argon2
+.LP
+.RE
+Depending on
+.BR pw-argon2 's
+location, you may also need:
+.RS
+.LP
+.B \-o
+.BR module\-path = \fIpathspec\fP
+.RE
+
+.SH EXAMPLES
+Both userPassword LDAP attributes below encode the password
+.RI ' secret '
+using different salts:
+.EX
+.LP
+userPassword: 
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$c2FsdHNhbHQ$DKlexoEJUoZTmkAAC3SaMWk30El9/RvVhlqGo6afIng
+.LP
+userPassword: 
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$c2FsdHNhbHRzYWx0$qOCkx9nMeFlaGOO4DUmPDgrlUbgMMuO9T1+vQCFuyzw
+.EE
+
+.SH SEE ALSO
+.BR slapd.c

Bug#955383: terminator: URLs are not clickable

[Markus Frosch]

forwarded -1 https://github.com/gnome-terminator/terminator/pull/6
owner -1 !
tags -1 + upstream
thanks

Am Donnerstag, den 02.04.2020, 09:38 -0300 schrieb Antonio Terceiro:
> FWIW I have been running with this patch for a while, and I didn't
> notice any issues. I have clicked URLs several times and it all just
> works.

I tested your patch, it works fine, only noticed one warning:

VTE-WARNING **: 18:12:07.240: (../src/vtegtk.cc:2171):int 
vte_terminal_match_add_regex(VteTerminal*, VteRegex*, guint32): runtime
check failed: (_vte_regex_has_multiline_compile_flag(regex))

Apparently one should use MULTILINE to search with vte, if not the warning is 
raised. Unfortunately there is no proper constant
for that, at least not with the Python interface.

This will be implemented with: 
https://github.com/gnome-terminator/terminator/pull/6
Patch: 
https://github.com/gnome-terminator/terminator/pull/6/commits/07d7dd56b2adf7eb8a526cc10bd5373756ff58f2

Regards
Markus
-- 
lazyfro...@debian.org
https://lazyfrosch.de

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Drew Parsons]

On 2020-04-05 22:34, Gilles Filippini wrote:

I suspect a mismatch between mpi and serial build-depdencies:

python3-h5py-serial + libhdf5-dev   => OK
python3-h5py-serial + libhdf5-openmpi-dev   => KO
python3-h5py-mpi + libhdf5-dev  => KO
python3-h5py-mpi + libhdf5-openmpi-dev  => KO(*)

(*) because it fails to import h5py submodules when python3-h5py-serial
is not installed:
ImportError: cannot import name 'h5f' from 'h5py' (unknown location)

With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
flavour, while building against 'serial' flavour requires serial 
flavour

of libhdf5 -dev package as well.



I've set up h5py so that the mpi build is only invoked when actually run 
with mpirun. In that sense the two builds are complementary rather than 
replacements (there was complaining that module loading was too slow 
when I had h5py built only against hdf5-mpi).  It seemed to me that's 
desirable to allow both serial and mpi builds of h5py to be installable 
at the same time, just as libhdf_*.so is, so I didn't want 
python3-h5py-serial and python3-h5py-mpi to Replace and Conflicts with 
each other.


Probably this is what's going on. bitshuffle is trying to make an mpi 
build, but running the build single processor so h5py accesses 
hdf5-serial.


In that case, running the bitshuffle mpi build in mpi might help, as in 
"mpirun -n 1 python3 setup.py". Not sure if that would be easy to do, 
e.g. if it's as "simple" as


override_dh_auto_build:

mpirun -n 1 dh_auto_build

Another option is to create an environment variable to force h5py to 
load the mpi version even when run in a serial environment without 
mpirun. Easy enough to set up, though I'm interested to see if "mpirun 
-n 1 dh_auto_build" or a variation of that is viable.  Maybe

%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild

to avoid overrides.

Drew

Bug#955976: dbusada: FTBFS on unstable: /usr/bin/ld: cannot open output file obj/tests/rebounder: No such file or directory

[Antonio Terceiro]

Source: dbusada
Version: 0.5.0-3
Severity: serious
Tags: ftbfs bullseye sid
Justification: fails to build from source

dbusada currently fails to build on unstable. The full build log is attached, 
and hopefully the relevant part is the following:

make[1]: Entering directory '/<>'
/usr/bin/make tests GNAT_BUILDER_FLAGS='-j2 -R -v -eS' ADAFLAGS=' -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong ' 
LDFLAGS='-Wl,-z,relro -Wl,-z,now -Wl,--no-undefined 
-Wl,--no-copy-dt-needed-entries -Wl,--no-allow-shlib-undefined' VERSION='0.5.0'
make[2]: Entering directory '/<>'
gprbuild -p -j2 -R -v -eS "-XADAFLAGS=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong " 
"-XLDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--no-undefined 
-Wl,--no-copy-dt-needed-entries -Wl,--no-allow-shlib-undefined" 
"-XVERSION=0.5.0" -Pd_bus_ada_tests -XLIBRARY_KIND=static
gcc tests/c/dbus-rebound.c `pkg-config --cflags --libs dbus-glib-1` -o 
obj/tests/rebounder
/usr/bin/ld: cannot open output file obj/tests/rebounder: No such file or 
directory
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:73: obj/tests/rebounder] Error 1


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

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


dbusada-ftbfs.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#955975: Massive memory leak in openshot 2.4.4 leads to freeze

[Jack Lucchetti]

Package: openshot-qt
Version: 1:2.4.4-dmo4
Severity: grave

When you edit a project with many clips, the cache is not freed properly.
This causes a number of problems, including complete freeze of the computer
when exporting the project to a file because the RAM gets used up (and the
swap space too).

The issue is describe well here:
https://github.com/OpenShot/openshot-qt/issues/2237

Apparently, the bug was fixed upstream over a year ago and version 2.5.1
should be ok.

Bug#949694: tasksel: Please drop all kde-l10n packages

[Holger Wansing]

Control: tags -1 + pending


Holger Wansing  wrote:
> Ok, so I will drop all the kde-l10n-* packages from the tasks shortly.

Done. Tagging this bug as pending


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#955859: lacme: please provide apache2 snippet below /etc/apache2/conf-available/

[Jonas Smedegaard]

Quoting Guilhem Moulin (2020-04-05 16:55:26)
> On Sun, 05 Apr 2020 at 15:19:16 +0200, Jonas Smedegaard wrote:
> > lacme provides a snippet for Apache 2.x below /etc/lacme/ - that's 
> > nice but not ideal.
> > 
> > Ideal would be to provide that snippet below 
> > /etc/apache2/conf-available/ to be usable with a2enconf/a2disconf 
> > interface.
> 
> I'm afraid I'm no longer familiar with Apache 2.x these days, is a 
> symlink /etc/apache2/conf-available/lacme.conf pointing to 
> /etc/lacme/apache2.conf all that's needed to make this work?  (Moving 
> the file away from /etc/lacme isn't an option since the path might be 
> hardcoded in the HTTPd configuration via include directives.)

Yes, a symlink as you describe above is fine.


 - Jonas

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

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

signature.asc
Description: signature

Bug#954434: pulseaudio-module-bluetooth: Adds Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

[Stefano F.]

Some updates for Pulseaudio 14 branch

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_441126

Il sab 21 mar 2020, 18:45 Stefano F.  ha scritto:

> If we need a new alternative package the RFC is at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954442
>
> Il giorno sab 21 mar 2020 alle ore 17:17 Felipe Sateler
>  ha scritto:
> >
> > Control: tags -1 moreinfo
> >
> > On Sat, Mar 21, 2020 at 12:33 PM Stefano F. 
> wrote:
> >>
> >> Package: pulseaudio-module-bluetooth
> >> Version: 13.99.1-1
> >> Severity: wishlist
> >> Tags: upstream
> >>
> >> Dear Maintainer,
> >>
> >> it would be nice to have non-free alternative package for A2DP codecs
> for
> >> modern true wireless earbuds supporte codecs with the packaging of[1].
> >>
> >> See also[2][3][4]
> >>
> >> [1]https://github.com/EHfive/pulseaudio-modules-bt
> >> [2]
> https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-
> >> upstream-this-into-pulseaudio
> >> [3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3
> >> [4]
> https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-
> >> on-linux/
> >
> >
> > I'm not sure what you are proposing. If you want these modules to be
> packaged, please help with getting #794692 resolved and then file a RFP for
> the modules.
> >
> > --
> >
> > Saludos,
> > Felipe Sateler
>

Bug#943656: python3-construct: please update to 2.9

[Henry-Nicolas Tourneur]

Hello Josch,

I have just uploaded a new version of the package on mentors.d.n.
It is lintian clean, I have also tested it by running some examples 
provided with the documentation of the library.


As per changelog of the updated package, uploading it to Debian set 
this bug as Closed.


Best regards,
Henry-Nicolas Tourneur
Matrix id: @hntourne:matrix.nilux.be

Le lun 30 mars 2020 à 21:45, Johannes Schauer  a 
écrit :

Hi,

Quoting deb...@nilux.be (2020-03-30 20:19:46)
 > upstream is active and it looks like there's enough interest in 
this
 > package, so anyone of you in CC can just go ahead and do a QA 
upload
 > (setting the QA team as maintainer) for the new upstream release 
or, for

 > bonus points, adopt it under the Debian Python Modules Team.

 I am not a Debian developper so I cannot upload myself without
 sponsoring/mentor.
 Eventually, my objective is to enhance the user experience on the
 Librem 5 smartphone from Purism by adding new packages into Debian 
that

 are relevant  (CCing Guido Gunther regarding this).

 So far, this is a bit of a domino game, which is fine: I wish to add
 gnome-passwordsafe Python software into Debian, but it depends on
 pykeepass.
 In turn, pykeepass depends on construct >= 2.10, thus my interest in
 this bug report :)

 It is fine for me to package an updated version of 
python3-construct.
 Any advise on the best way forward are most welcome (mentors ML, 
anyone here

 interested to provide support, ...).


if you are willing to package the new upstream version, then I can 
review and

sponsor it for you.

Thanks!

cheers, josch

Bug#955974: matrix-synapse: Increasing max_upload_size

[James Valleroy]

Package: matrix-synapse
Version: 1.12.0-1
Severity: wishlist

Dear Maintainer,

For FreedomBox, we have set max_upload_size to 100M, since about 3 years ago. I 
wonder if it would make sense to change the default from 10M to 100M.

Please consider adopting this as default or making it configurable with a 
low/medium priority debconf setting.


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

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

Versions of packages matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  libjs-jquery   3.3.1~dfsg-3
ii  libpython3-stdlib  3.8.2-2
ii  lsb-base   11.1.0
ii  python33.8.2-2
ii  python3-attr   19.3.0-2
ii  python3-bcrypt 3.1.7-2+b1
ii  python3-bleach 3.1.4-1
ii  python3-canonicaljson  1.1.4-3
ii  python3-daemonize  2.4.7-4
ii  python3-distutils  3.8.2-2
ii  python3-frozendict 1.2-2
ii  python3-idna   2.8-1
ii  python3-jinja2 2.10.1-2
ii  python3-jsonschema 3.0.2-4
ii  python3-lxml   4.5.0-1
ii  python3-msgpack0.6.2-1
ii  python3-nacl   1.3.0-5
ii  python3-netaddr0.7.19-4
ii  python3-openssl19.0.0-1
ii  python3-phonenumbers   8.9.10-2
ii  python3-pil6.2.1-2+b1
ii  python3-prometheus-client  0.7.1-1.1
ii  python3-pyasn1 0.4.2-3
ii  python3-pyasn1-modules 0.2.1-0.2
ii  python3-pymacaroons0.13.0-3
ii  python3-service-identity   18.1.0-5
ii  python3-signedjson 1.1.0-1
ii  python3-six1.14.0-2
ii  python3-sortedcontainers   2.1.0-2
ii  python3-systemd234-3+b1
ii  python3-treq   18.6.0-0.2
ii  python3-twisted18.9.0-10
ii  python3-typing-extensions  3.7.4.1-1
ii  python3-unpaddedbase64 1.1.0-5
ii  python3-yaml   5.3.1-1

Versions of packages matrix-synapse recommends:
ii  python3-psycopg2  2.8.4-2

Versions of packages matrix-synapse suggests:
pn  python3-txacme  

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed:
allow_guest_access: false
app_service_config_files: []
bcrypt_rounds: 12
database:
  args: {database: /var/lib/matrix-synapse/homeserver.db}
  name: sqlite3
dynamic_thumbnails: false
enable_metrics: false
enable_registration: false
enable_registration_captcha: false
event_cache_size: 10K
expire_access_token: false
federation_rc_concurrent: 3
federation_rc_reject_limit: 50
federation_rc_sleep_delay: 500
federation_rc_sleep_limit: 10
federation_rc_window_size: 1000
key_refresh_interval: 1d
listeners:
- bind_addresses: ['::', 0.0.0.0]
  port: 8448
  resources:
  - compress: true
names: [client, webclient]
  - compress: false
names: [federation]
  tls: true
  type: http
  x_forwarded: false
- bind_address: 127.0.0.1
  port: 8008
  resources:
  - compress: true
names: [client, webclient]
  - compress: false
names: [federation]
  tls: false
  type: http
  x_forwarded: false
log_config: /etc/matrix-synapse/log.yaml
max_image_pixels: 32M
max_spider_size: 10M
max_upload_size: 100M
media_store_path: /var/lib/matrix-synapse/media
no_tls: false
old_signing_keys: {}
password_config: {enabled: true}
password_providers:
- config:
attributes: {mail: '', name: uid, uid: uid}
base: ou=users,dc=thisbox
enabled: true
start_tls: false
uri: ldap://localhost:389
  module: ldap_auth_provider.LdapAuthProvider
perspectives:
  servers:
matrix.org:
  verify_keys:
ed25519:auto: {key: ...}
pid_file: /var/run/matrix-synapse.pid
rc_message_burst_count: 10.0
rc_messages_per_second: 0.2
recaptcha_private_key: YOUR_PRIVATE_KEY
recaptcha_public_key: YOUR_PUBLIC_KEY
recaptcha_siteverify_api: https://www.google.com/recaptcha/api/siteverify
room_invite_state_types: [m.room.join_rules, m.room.canonical_alias, 
m.room.avatar,
  m.room.name]
signing_key_path: /etc/matrix-synapse/homeserver.signing.key
soft_file_limit: 0
thumbnail_sizes:
- {height: 32, method: crop, width: 32}
- {height: 96, method: crop, width: 96}
- {height: 240, method: scale, width: 320}
- {height: 480, method: scale, width: 640}
- {height: 600, method: scale, width: 800}
tls_certificate_path: /etc/matrix-synapse/homeserver.tls.crt
tls_dh_params_path: /etc/matrix-synapse/homeserver.tls.dh
tls_private_key_path: /etc/matrix-synapse/homeserver.tls.key
trusted_third_party_id_servers: [matrix.org, vector.im]
turn_shared_secret: YOUR_SHARED_SECRET
turn_uris: []
turn_user_lifetime: 1h
url_preview_enabled: false
user_creation_max_duration: 120960
web_client: false


-- debconf information:
* matrix-synapse/server-name:

Bug#955859: lacme: please provide apache2 snippet below /etc/apache2/conf-available/

[Guilhem Moulin]

On Sun, 05 Apr 2020 at 15:19:16 +0200, Jonas Smedegaard wrote:
> lacme provides a snippet for Apache 2.x below /etc/lacme/ - that's nice
> but not ideal.
> 
> Ideal would be to provide that snippet below /etc/apache2/conf-available/
> to be usable with a2enconf/a2disconf interface.

I'm afraid I'm no longer familiar with Apache 2.x these days, is a
symlink /etc/apache2/conf-available/lacme.conf pointing to
/etc/lacme/apache2.conf all that's needed to make this work?  (Moving
the file away from /etc/lacme isn't an option since the path might be
hardcoded in the HTTPd configuration via include directives.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#954075: busybox: provide a low-priority alternative for vi, view, editor

[Cyril Brulebois]

John Paul Adrian Glaubitz  (2020-04-05):
> On 3/28/20 5:16 PM, Cyril Brulebois wrote:
> > John Paul Adrian Glaubitz  (2020-03-17):
> >> I think enabling vi in the busybox configuration is actually the best
> >> approach to address this problem as this way we continue to ship vi
> >> with debian-installer and at the same time get rid of the vim
> >> dependency which is regularly causing headaches when building
> >> debian-installer images for Debian Ports.
> > 
> > Can you expand on that?
> 
> src:vim is regularly failing to build from source, even on release
> architectures and I think that this is rather unfortunate for packages
> that are required for even a minimal Debian installation.
> 
> Just the latest upload of src:vim is failing on ppc64el again:
> 
> > https://buildd.debian.org/status/package.php?p=vim&suite=sid
> > https://buildd.debian.org/status/logs.php?pkg=vim&arch=ppc64el

In other words, as I suspected, this has nothing to do with building
debian-installer images.

> > I'm not aware of vi playing any part in Debian Installer (there's
> > nano instead) but maybe I've been missing some piece of information
> > during all those years?
> 
> vim-tiny is always installed when debootstrap installs a minimal
> Debian system and vim-tiny is built from src:vim.
> 
> My suggestion would be to replace the problematic vim-tiny with the
> less problematic vile:
> 
> > https://buildd.debian.org/status/package.php?p=vile&suite=sid
> 
> > Digging a bit more in the mail you pointed to (and its references…),
> > it seems you might be referring to the “Priority: important” field for
> > vim-tiny. While this is indeed used in Debian Installer through
> > debootstrap(-udeb), the former is not depending on anything provided
> > by vim-tiny. We've had a number of packages having their priorities
> > changed over the last release cycle(s), mainly initiated by Ansgar. I
> > don't think vim-tiny is special here, and if the consensus is that it
> > should no longer be “Priority: important”, I'm not immediately seeing
> > reasons for the installer team to object.
> 
> I just want to avoid debian-installer to be dependent on a package
> that has regularly quality issues and rather replace it with a simple
> VI clone which will hopefully also take away pressure from the
> maintainer of src:vim since he can remove vim-tiny (which he actually
> wants to) and not bother about debootstrap or debian-installer if the
> package FTBFS in unstable again.

In other words, this is not related to debootstrap or debian-installer,
but to what debootstrap pulls from the archive, which is controlled by
priorities, that are only remotely overseen by the d-i team when the
FTP masters are asked to change them (I don't remember NACKing any of
them, just a vague recollection of asking to postpone one so that we
could get something adjusted before it hit the archive).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM

[Paride Legovini]

Hello Ludovic,

On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau  
wrote:
> Hello Paride,
> 
> Le 03/04/2020 à 13:20, Paride Legovini a écrit :
> > Hi,
> > 
> > I'm also hitting this issue, but after trying a few things I'm not
> > convinced it is strictly a "resume after suspend" problem. But
> > let's proceed with order.
> > 
> > I normally keep a OpenPGP smartcard in my laptop's smartcard reader and
> > I use it via scdaemon with disable-ccid. Sometimes when I suspend and
> > resume my laptop I lose access to the smartcard: gnupg/scdaemon can't
> > find it anymore. Restarting pcscd helps (systemctl restart pcscd) often
> > but *not always* helps.
> > 
> > I tried to collect logs running pcscd in foreground in a shell, but
> > guess what, it *never* happens if I run it like this. The problem seems
> > to happen only when pcscd is started by systemd, and I found out that I
> > can reproduce it by restarting pcscd several time with systemctl. So I
> > modified pcscd.service like this:
> > 
> > 
> > [Service]
> > Environment=LIBCCID_ifdLogLevel=0x000F
> > ExecStart=/usr/sbin/pcscd --foreground --debug --apdu
> > #ExecStart=/usr/sbin/pcscd --foreground --auto-exit
> > #ExecReload=/usr/sbin/pcscd --hotplug
> > 
> > 
> > in order to collect the relevant logs. Here they are.
> 
> Thanks a lot for your tests and logs.

> When it fails:
> - is the socket /var/run/pcscd/pcscd.comm still present?

This was a hint in the right direction and I think it makes most of the
logs I collected useless. Apparently when the problem occurs the
/var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still
have a file descriptor open for it, as I found out using lsof:

COMMAND  PID  TID TASKCMD  USER  FD   TYPE DEVICE  SIZE/OFF 
NODE NAME
systemd1   root  45u  unix 0xa066a5154400   0t0  
3172053 /run/pcscd/pcscd.comm type=STREAM

I think the systemd socket unit (pcscd.socket) does not recreate the
socket because of this, and passes a "dead" file descriptor to pcscd.
What exactly deletes the pcscd.comm socket is not clear to me. Now after
fiddling with pcscd I don't think I have clean logs to provide, I prefer
to wait for the problem to happen again and then check if anything
relevant is logged. I did try to suspend/resume a few times but but I
didn't manage to reproduce the issue. But maybe you know what could be
deleting the socket.

> - what do you get when you run pcsc_scan? (from the pcsc-tools package)

It fails with:

SCardEstablishContext: Service not available.

as it can't find the socket.

> PS: maybe you should change your smart card password if it starts with "c".

That was already a temporary password as I did fear the debugging logs might
leak it, but thanks for the warning :) Adding a note on the website where 
the instructions on how to collect logs are given might be a good idea.

Thank again,

Paride

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 05/04/2020 à 15:28 :
> On 2020-04-05 20:38, Gilles Filippini wrote:
>>>
>>> But it must be something else from these new h5py upstream patches
>>> that's leading to any other bitshuffle errors (the ones apart from the
>>> file-not-found error).
>>
>> Nope. Seems related to the h5py 'serial' flavour only. It appears for
>> the first time when you configure the build for both flavours. If I
>> force the 'mpi' flavour installation *without* the 'serial' one,
>> bitshuffle builds fine.
>>
> 
> A good clue. I've pushed a h5py without the patches, but looks like the
> problem might remain. Strange if bitshuffle builds fine against h5py-mpi
> but not against h5py-serial. You'd expect any problem to come the other
> way around.

I suspect a mismatch between mpi and serial build-depdencies:

python3-h5py-serial + libhdf5-dev   => OK
python3-h5py-serial + libhdf5-openmpi-dev   => KO
python3-h5py-mpi + libhdf5-dev  => KO
python3-h5py-mpi + libhdf5-openmpi-dev  => KO(*)

(*) because it fails to import h5py submodules when python3-h5py-serial
is not installed:
ImportError: cannot import name 'h5f' from 'h5py' (unknown location)

With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
flavour, while building against 'serial' flavour requires serial flavour
of libhdf5 -dev package as well.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955530: tomcat9: ipa-server-install fails due to servlet crash

[Emmanuel Bourg]

Le 02/04/2020 à 05:30, Timo Aaltonen a écrit :

> ipa-server-install (from freeipa-server) started failing within the last few 
> weeks,
> I don't know exactly when but it's a regression in sid, Ubuntu focal is still 
> fine.
> 
> Redhat folks said this would've been due to openjdk-8-jre being built with 
> gcc10, but the latest
> version isn't anymore, and I've tried older versions from snapsho.d.o and 
> they didn't help.
> I've also tried downgrading dogtag-pki but that didn't help either.
> 
> 2020-04-01 14:35:35 [main] SEVERE: Unable to start CMS engine: null
> java.lang.NullPointerException
> at 
> com.netscape.ca.CRLIssuingPoint.initConfig(CRLIssuingPoint.java:764)
> at com.netscape.ca.CRLIssuingPoint.init(CRLIssuingPoint.java:497)
> at 
> com.netscape.ca.CertificateAuthority.initCRL(CertificateAuthority.java:2304)
> at 
> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:633)
> at 
> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:824)
> at 
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:799)
> at 
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:791)
> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:468)
> at 
> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:113)
> at javax.servlet.GenericServlet.init(GenericServlet.java:158)

Hi Timo,

Why do you think this is related to tomcat9?

Emmanuel Bourg

Bug#955973: fail2ban: Set default mail command to exim?

[James D. Amberger]

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

Dear Maintainer,

Fresh install of Buster, I installed fail2ban and noticed that the
jail.conf specifies sendmail as the mail transport even though the
debian default is still exim (right?). Should not the debian-specific
conf in jail.d set the following?

mta = sendmail


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

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

Versions of packages fail2ban depends on:
ii  lsb-base  10.2019051400
ii  python3   3.7.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.8.2-4
ii  python 2.7.16-1
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd234-2+b1
ii  whois  5.4.3

Versions of packages fail2ban suggests:
ii  mailutils [mailx]1:3.5-3
pn  monit
ii  rsyslog [system-log-daemon]  8.1901.0-1
pn  sqlite3  

-- Configuration Files:
/etc/fail2ban/jail.conf changed [not included]

-- no debconf information

Bug#955867: opendmarc: Schema update script with ARC changes not present

[boson]

Package: opendmarc
Version: 1.4.0~beta1+dfsg-1
Severity: normal

Dear Maintainer,

After updating OpenDMARC to version 1.4.0~beta1+dfsg-1 the following
has begun to occur:

- When running opendmarc-import in a crontab I get the following
  message:
opendmarc-import: failed to insert message: Unknown column 'arc' in 'field 
list'

  I tried to import (to MariaDB) the schema update script located at:
 /usr/share/doc/opendmarc/README.update-db-schema.mysql

 but it does not contain any SQL.  It states that the following command
 should be executed:

   mysql -u  -p  --force < update-db-schema.mysql

 but the stated file could not be found.

- The expected outcome is that there would be a schema update script
  which could be applied to the opendmarc DB to include the new ARC
  DB tables/fields.


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

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

Versions of packages opendmarc depends on:
ii  adduser3.118
ii  dbconfig-mysql 2.0.13
ii  debconf [debconf-2.0]  1.5.73
ii  init-system-helpers1.57
ii  libbsd00.10.0-1
ii  libc6  2.30-4
ii  libmilter1.0.1 8.15.2-18
ii  libopendmarc2  1.4.0~beta1+dfsg-1
ii  lsb-base   11.1.0
ii  publicsuffix   20200201.2258-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.050-3
ii  libdbi-perl   1.643-1
ii  libhttp-message-perl  6.22-1
ii  libopendbx1   1.4.6-14
ii  libopendbx1-mysql 1.4.6-14
ii  libswitch-perl2.17-2
ii  perl  5.30.0-9

Versions of packages opendmarc suggests:
ii  libmime-tools-perl  5.509-1
pn  libxml-simple-perl  
ii  python  2.7.17-2
pn  python-mysqldb  

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

-- debconf information:
  opendmarc/remote/port:
  opendmarc/mysql/method: Unix socket
  opendmarc/db/app-user: opendmarc@localhost
  opendmarc/remote/host: localhost
  opendmarc/install-error: abort
  opendmarc/upgrade-error: abort
  opendmarc/db/dbname: opendmarc
* opendmarc/dbconfig-install: true
  opendmarc/database-type: mysql
  opendmarc/internal/skip-preseed: false
  opendmarc/mysql/authplugin: default
  opendmarc/upgrade-backup: true
  opendmarc/purge: false
* opendmarc/mysql/admin-user: debian-sys-maint
  opendmarc/remove-error: abort
  opendmarc/dbconfig-reinstall: false
  opendmarc/passwords-do-not-match:
  opendmarc/internal/reconfiguring: false
  opendmarc/remote/newhost:
  opendmarc/dbconfig-remove: true
  opendmarc/dbconfig-upgrade: true
  opendmarc/missing-db-package-error: abort

Bug#955869: RM: geis -- RoQA; RC-buggy, unmaintained, dead upstream

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

Please remove geis from the archive. It is RC buggy (#855124, 948821)
and NMU-maintained since 2015. It has no reverse dependencies in the
archive. It also appears to be dead upstream (last upstream commit was
in 2016).

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955868: html2text: Please migrate to new upstream project location

[Boyuan Yang]

Package: html2text
Severity: important
Version: 1.3.2a-25

Hi Martin,

According to https://tracker.debian.org/pkg/html2text and
https://bugs.debian.org/951882 ,
package html2text in Debian has been orphaned since Feb 2020 with no maintainer
at this time.

I am converting your email to a bug report in Debian in case someone
interested in it
can see it and switch the upstream information. Feel free to let me
know if you have
further questions.

-- 
Regards,
Boyuan Yang

Martin Bayer  于2020年4月5日周日 上午9:36写道：
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear members of the team,
>
> it occurs to me that you are maintaining a binary release of html2text:
> https://packages.debian.org/sid/html2text
>
> | html2text is now maintained by Fabian Groffen on GitHub at
> | https://github.com/grobian/html2text .
>
> html2text's primary site was http://www.mbayer.de/html2text/ (and before
> that http://userpage.fu-berlin.de/~mbayer/tools/ ). Please adjust any
> links and mirrors to refer to the new home at GitHub. Also, any
> contributions or issue reports should now be submitted via GitHub.
>
> Thank you for your your commitment and stay safe!
>
> Martin Bayer
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAl6J2RUACgkQJNRoLMKw06kXLwCeNYXDV1DEPgY7ROHuFVKRfT5j
> QUAAn2qf8YjN3e5W+5KZm4LarL4r6bNp
> =pGFh
> -END PGP SIGNATURE-

Bug#955755: mediathekview fails to start with openjdk-11-jre version 11.0.7+9-1

[Markus Koschany]

Control: retitle -1 commons-text.jar is missing on the CLASSPATH of 
libcommons-configuration2-java
Control: reassign -1 libcommons-configuration2-java
Control: severity -1 serious

Hi,

Am 04.04.20 um 18:40 schrieb Michel Messerschmidt:
> Package: mediathekview
> Version: 13.2.1-3
> Severity: important
>
> Dear Maintainer,
>
> mediathekview does not work with the updated openjdk packages anymore.
>
> The program hangs with these error messages if started on the console:
> ~$ mediathekview
[...]
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.text.lookup.StringLookupFactory
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
>   ... 28 more
[...]

The problem was caused by the upgrade of libcommons-configuration2-java on 
which mediathekview
depends on. Apparently one class was moved to another package but since it was 
not on the CLASSPATH,
mediathekview fails to detect it and fails to start now. I'm currently 
uploading a fixed version.
Thanks for reporting!

Regards,

Markus








signature.asc
Description: OpenPGP digital signature

Bug#955816: Improve documentation of bridge option

[Bastien ROUCARIES]

control: forwarded -1 net...@vger.kernel.org

On Sun, Apr 5, 2020 at 1:05 PM Luca Boccassi  wrote:
>
> On Sun, 5 Apr 2020 at 10:30, Bastien Roucariès
>  wrote:
> >
> > Subject: iproute2: Improve bridge documentation
> > Package: iproute2
> > Version: 5.5.0-1
> > Severity: wishlist
> > Tags: patch
> > Forwarded: step...@networkplumber.org
> >
> > Dear Maintainer,
> >
> > I have improved the documentation of man pages for bridge.
> >
> > Moreover state is now case insensitive.
> >
> > Please apply
>
> Please send these upstream first. You can do so with git send-email:

Done

Thanks
>
> git send-email --subject-prefix='PATCH iproute2' --to
> net...@vger.kernel.org --annotate -6

Bug#955866: synapse: unnecessarily Build-Depends on deprecated dbus-glib

[Simon McVittie]

Source: synapse
Version: 0.2.99.4-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation
Control: block 895291 by -1

dbus-glib is a deprecated D-Bus library with some significant design
flaws, and is essentially unmaintained. As announced in [0], I would
like to minimize its use, and eventually remove it from Debian.

This package Build-Depends on libdbus-glib-1-dev, but it looks as though
all its D-Bus bits are implemented using GLib's GDBus, which is part of
libglib2.0-0. If this analysis is correct, please remove the Build-Depends
on libdbus-glib-1-dev.

If this package has other uses of dbus-glib that I have missed, please
see [0] for how to proceed.

Thanks,
smcv

[0] https://lists.debian.org/debian-devel/2020/03/msg00272.html

Bug#955827: Please remove me from uploaders

[jnqnfe]

On Sun, 2020-04-05 at 13:43 +0100, Ana Custura wrote:
> On 05/04/2020 12:46, jnq...@gmail.com wrote:
> > you can submit a merge request via salsa... 
> 
> Done, thanks! I should probably be removed from the salsa team too.
> 
> Ana
> 

no problem :)

the reviewer will want you to add a "Closes: #955827" line to the
commit message though, such that the bug report automatically gets
marked as pending & closed upon merge and release of the next version
respectively.

probably be a good idea to email Steve / Raphaël / Iain to get your
salsa team membership removed rather than rely upon them noticing it in
this bug discussion.