date:20200405

Bug#955860: buster-pu: package csync2/2.0-22-gce67c55-1+deb10u1

2020-04-05 Thread Valentin Vidic

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

Hi,

Please approve the following update for buster fixing a CVE:

diff -Nru csync2-2.0-22-gce67c55/debian/changelog 
csync2-2.0-22-gce67c55/debian/changelog
--- csync2-2.0-22-gce67c55/debian/changelog 2018-10-06 23:05:46.0 
+0200
+++ csync2-2.0-22-gce67c55/debian/changelog 2020-04-05 12:55:07.0 
+0200
@@ -1,3 +1,9 @@
+csync2 (2.0-22-gce67c55-1+deb10u1) buster; urgency=medium
+
+  * Add patch for CVE-2019-15522 (Closes: #955445)
+
+ -- Valentin Vidic   Sun, 05 Apr 2020 12:55:07 +0200
+
 csync2 (2.0-22-gce67c55-1) unstable; urgency=medium
 
   * New upstream version 2.0-22-gce67c55
diff -Nru csync2-2.0-22-gce67c55/debian/patches/CVE-2019-15522.patch 
csync2-2.0-22-gce67c55/debian/patches/CVE-2019-15522.patch
--- csync2-2.0-22-gce67c55/debian/patches/CVE-2019-15522.patch  1970-01-01 
01:00:00.0 +0100
+++ csync2-2.0-22-gce67c55/debian/patches/CVE-2019-15522.patch  2020-04-05 
12:51:42.0 +0200
@@ -0,0 +1,21 @@
+From 0ecfc333da51575f188dd7cf6ac4974d13a800b1 Mon Sep 17 00:00:00 2001
+From: Malte Kraus 
+Date: Tue, 13 Aug 2019 11:25:57 +0200
+Subject: [PATCH] fail HELLO command when SSL is required
+
+---
+ daemon.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/daemon.c b/daemon.c
+index 2d8407d..2a1a8af 100644
+--- a/daemon.c
 b/daemon.c
+@@ -747,6 +747,7 @@ void csync_daemon_session()
+   goto conn_without_ssl_ok;
+   }
+   cmd_error = conn_response(CR_ERR_SSL_EXPECTED);
++  peer = NULL;
+   }
+ conn_without_ssl_ok:;
+ #endif
diff -Nru csync2-2.0-22-gce67c55/debian/patches/series 
csync2-2.0-22-gce67c55/debian/patches/series
--- csync2-2.0-22-gce67c55/debian/patches/series2018-04-18 
22:30:48.0 +0200
+++ csync2-2.0-22-gce67c55/debian/patches/series2020-04-05 
12:51:17.0 +0200
@@ -3,3 +3,4 @@
 spelling.patch
 fix-manpage-header.patch
 fix-parallel-build.patch
+CVE-2019-15522.patch

-- 
Valentin

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

2020-04-05 Thread Jonas Smedegaard

Source: lacme
Version: 0.6-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6J2tEACgkQLHwxRsGg
ASGrNw/+Kk5LXLcySLctnpmaeImVMKP03sKKf1tFhC5klKDPak8dJ59b1961U/dT
cJ/5FpdaWPCoCRWLFegstzeunttwmnH2DDJi5KD847M58QPHmv6ATSc0vZ4NuRyh
kl0cFDDusUdiRGAPpWUJenwFdpVkfSKdrlQBdPrcz1dUfEQpCD3wxqsk84UPPA9M
DW07EV5P7tZM3zU4LTbLRMokBEFfVleJWDP1SpxyBVDBN2H+C9CY2G8aeoVfoSH4
m18ny3oqJd0Y3erGXj4O/Anqr3544B/yeugm6IrNq0C/SlC0j3XCbyxj1ALP9XWg
tjsdnmzg43kAzRmahgTFJI6/ExL8DkcWE+I4ucP12t/fhMy+PEceHi0kLPSML/qj
MBRaEEwtMuJq92R9wM/KC28i/wpGfIxezfehkY4g373jHUrQrowzy8x2aimzARHA
AEPmkSr0+Lh36XBlno9PzEa1e9q2hBHcoozS2lpVSvhlfrt/H0bUg9pWfE2I4Ub3
oUB9Q48II1l/muFwpEarZd+MX2xAjUXiMpx3iJK6jis7tjJglBrQUKwbVeMy7cG1
w3Sqsavwo/u5YRtiAvVhWQNBy8Lh1z0Y+0+VH35u8lznJdPXcNeD7ZKALqvKYGDm
p5s7gSXYDUuwgZCYWZ3lEk6Vl0q/b3fRHRWtABJqrtPlUzJ0J0k=
=wf09
-END PGP SIGNATURE-

Bug#955858: gparted: does not start, 'unable to init server', tmp.mount does not exist

2020-04-05 Thread Kyle B

Package: gparted
Version: 1.0.0-0.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I am unable to start gparted. When attempting to start it from the gui
interfaces, I get a password prompt, and then nothing. When I attempt to start
it as root in the terminal, I get

Unit tmp.mount does not exist, proceeding anyway.
Unable to init server: Could not connect: Connection refused

(gpartedbin:11049): Gtk-WARNING **: 09:04:39.901: cannot open display:

Thanks.



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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 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

Versions of packages gparted depends on:
ii  gparted-common1.0.0-0.1
ii  libatkmm-1.6-1v5  2.28.0-2
ii  libc6 2.30-4
ii  libcairomm-1.0-1v51.12.2-4
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.64.1-1
ii  libglibmm-2.4-1v5 2.58.0-2
ii  libgtk-3-03.24.5-1
ii  libgtkmm-3.0-1v5  3.24.0-2
ii  libpangomm-1.4-1v52.42.0-2
ii  libparted-fs-resize0  3.2-25
ii  libparted23.2-25
ii  libsigc++-2.0-0v5 2.10.1-2
ii  libstdc++610-20200324-1
ii  libuuid1  2.33.1-0.1
ii  policykit-1   0.105-25

gparted recommends no packages.

Versions of packages gparted suggests:
pn  dmraid 
ii  dmsetup2:1.02.155-3
ii  dosfstools 4.1-2
ii  e2fsprogs  1.44.5-1+deb10u3
pn  gpart  
pn  jfsutils   
pn  kpartx 
pn  mtools 
ii  ntfs-3g1:2017.3.23AR.3-3
pn  reiser4progs   
pn  reiserfsprogs  
pn  udftools   
pn  xfsprogs   
ii  yelp   3.31.90-1

-- no debconf information

Bug#955827: Please remove me from uploaders

2020-04-05 Thread Ana Custura



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

Bug#955856: xfce4-verve-plugin: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: xfce4-verve-plugin
Version: 2.0.0-1
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 I couldn't find any
sign of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please remove the
Build-Depends on libdbus-glib-1-dev.

If this package has 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#955857: xwrited: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: xwrited
Version: 3-1
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 I couldn't find
any sign of it actually *using* dbus-glib - presumably it used to use
dbus-glib and was later ported to GDBus? 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#955855: xfburn: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: xfburn
Version: 0.6.2-1
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 I couldn't find any
sign of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please remove the
Build-Depends on libdbus-glib-1-dev.

If this package has 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#955456: FTBFS: test file tmp_test_filters.h5 does not exist

2020-04-05 Thread Gilles Filippini

Drew Parsons a écrit le 03/04/2020 à 15:08 :
> On 2020-04-03 20:13, Gilles Filippini wrote:
>>
>> This is not related to the ongoing hdf5 transition, but to the recent
>> uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've
>> checked that bitshuffle builds successfully. It was against h5py
>> 2.10.0-2 by then.
> 
> 
> The change in behaviour comes from the h5py upstream patches applied in
> h5py 2.10.0-3.
> 
> file_default_read_5e71c49.patch in particular is the one that updates
> the API, setting File() to mode='r' by default.  I added the patch to
> deal with the H5pyDeprecationWarning we were getting, since the change
> was flagged as coming in from upstream anyway.  In principle it just
> means mode needs to be added explicitly as h5py.File(filename, mode), if
> the required mode is not 'r'.
> 
> 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.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev

2020-04-05 Thread Evgeni Golov

Hi Bernhard,

thanks for digging into this! I'd argue that the real bug is in the grpc 
package, as dropping symbols without a soname bump is bad. But that clearly 
doesn't help you now.

CCing the maintainer of grpc, shall we reassign and you do the needed changes?

Evgeni

On April 5, 2020 11:49:04 AM UTC, "Bernhard Übelacker"  
wrote:
>Dear Maintainer,
>I tried to have a look and it looks like being related
>to the libgrpc++1 package.
>
>The _ZN4grpc13ClientContextC1Ev symbol was included in
>libgrpc++1 versions up to 1.17.2-1.
>Since version 1.22.0-2 it is missing from that library.
>
>Because 1.26.0-2 is the first version after 1.16.1-1,
>which got uploaded to unstable (other versions just in
>experimental), this issue got visible since 2020-03-21.
>
>A local rebuild of sysdig against libgrpc++1 1.26.0-2
>seems to work.
>
>Therefore it looks like there was an ABI change in libgrpc++1.
>I am not sure what actions on grpc side are needed,
>but at least a rebuild of sysdig seems necessary.
>
>Kind regards,
>Bernhard

Bug#955854: worker: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: worker
Version: 4.0.1-1
Severity: normal
Tags: upstream
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.

worker Build-Depends on libdbus-glib-1-dev, and its upstream build system
checks for dbus-glib-1.pc, but it looks as though it does not actually
use dbus-glib. Instead, it uses the reference D-Bus implementation,
libdbus (dbus-1.pc), which is the libdbus-1-dev Debian package.

If this analysis is correct, please patch the upstream build system so
that it only checks for dbus-1 (this change should be sent upstream),
then replace the Build-Depends on libdbus-glib-1-dev with a Build-Depends
on libdbus-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#944382: [xscreensaver-data-extra] /usr/share/application/screensavers/glitchpeg.desktop file error

2020-04-05 Thread Tormod Volden

merge 944382 920753
thanks

Thanks for your report.

On Thu, Apr 2, 2020 at 10:21 PM Stephen Lyons wrote:
>
> Package: xscreensaver-data-extra
> Version: 5.42+dfsg1-1
>
> --- Please enter the report below this line. ---
> The problem seems to be a spurious line-feed part way through the
> "Comment" entry for that file which then appears to break something when
> it tries to parse that glitchpeg.desktop file. It is not immediately
> clear to me from reading
> https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
> whether that filed may contain Line-Feeds within its contents, but given
> the behaviour in this case I suspect not!
>

Bug#955853: ITP: ruby-slack-messenger -- Slim ruby wrapper for posting to slack webhooks

2020-04-05 Thread Pirate Praveen


Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

https://rubygems.org/gems/slack-messenger is a dependency of gitlab 
12.9.x

Bug#955852: usbguard: unnecessarily Build-Depends on deprecated dbus-glib (and also dbus-1)

2020-04-05 Thread Simon McVittie

Source: usbguard
Version: 0.7.6+ds-1
Severity: normal
Tags: upstream
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, and checks for
dbus-glib-1 in its upstream build system, but I couldn't find any sign
of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please patch out
the check for dbus-glib-1 (this change could usefully be sent upstream)
and remove the Build-Depends on libdbus-glib-1-dev.

Similarly, it Build-Depends on libdbus-1-dev (which is not deprecated),
and checks for dbus-1 in its upstream build system, but it doesn't
appear to actually use that dependency. To use GLib's "GDBus" family of
APIs (GDBusConnection, etc.) you only need to check for the gio-2.0
pkg-config module: it is not necessary to have dbus-1 or dbus-glib-1
development files installed. Removing this dependency would make the
overall dependency graph of Debian a bit less tightly-coupled.

If this package has 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#951999: Autoconf issue in mpqc

2020-04-05 Thread Andreas Tille

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.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#955850: ofono: Build-Depends on dbus-glib but does not appear to use it

2020-04-05 Thread Simon McVittie

Package: ofono
Version: 1.31-3
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation
Control: block 895291 by -1

ofono Build-Depends on libdbus-glib-1-dev, but does not appear to use
it, and does not have a runtime Depends on the corresponding library
libdbus-glib-1-2.

It looks as though ofono *does* explicitly check for dbus-1 >= 1.4
(libdbus-1-dev >= 1.4 in Debian terms), so it should explicitly
Build-Depend on that instead.

Please update the build-dependencies.

(This is part of a mass-bug-filing for dependencies on dbus-glib,
which is deprecated.)

smcv

Bug#955851: ukui-control-center: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: ukui-control-center
Version: 2.0.2-1
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 I couldn't find any
sign of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please remove the
Build-Depends on libdbus-glib-1-dev.

If this package has 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#955729: wofi fails to show window

2020-04-05 Thread Birger Schacht

Hi,

On 4/4/20 11:38 AM, Nicolas Évrard wrote:
> Package: wofi
> Version: 1.1.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> Hello,
> 
> This morning I updated the following packages and right after this
> update wofi stopped showing the window but did not crash either.


That happened to me today with waybar and pinentry ;)

> 
> I suspect that the libgtk-3 update is the issue.

I agree. I had to downgrade libgtk to 3.24.16-1 to make it work again.
There is #955820 blocking migration of 3.24.17 which also lists upstream
bugreports.

cheers,
Birger



signature.asc
Description: OpenPGP digital signature

Bug#955849: network-manager-strongswan: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: network-manager-strongswan
Version: 1.4.5-2.1
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 I couldn't find any
sign of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please remove the
Build-Depends on libdbus-glib-1-dev.

If this package has 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#955848: libaccounts-glib-dev: unnecessarily Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Package: libaccounts-glib-dev
Version: 1.23-1
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.

libaccounts-glib appears to have been ported from dbus-glib to GDBus
as recommended in [0], but its -dev package still depends on
libdbus-glib-1-dev. Please remove that dependency, assuming it is now
unnecessary.

If this package has 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#955847: gthumb: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: gthumb
Version: 3:3.8.0-2.1
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.

gthumb Build-Depends on libdbus-glib-1-dev, but I couldn't find any sign
of it actually *using* dbus-glib - perhaps it used to use dbus-glib
but does not any more? If this analysis is correct, please remove the
Build-Depends on libdbus-glib-1-dev.

If this package has 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#955844: gpick: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: gpick
Version: 0.2.6~rc1-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.

gpick Build-Depends on libdbus-glib-1-dev, but I couldn't find any sign of
it actually *using* dbus-glib - presumably it used to use dbus-glib and
was later ported to GDBus? 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#955846: gpsd: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: gpsd
Version: 3.20-6
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.

gpsd Build-Depends on libdbus-glib-1-dev, but it looks as though
it does not actually use dbus-glib. Instead, it uses the reference
D-Bus implementation, libdbus (dbus-1.pc), which is the libdbus-1-dev
Debian package.

If this is correct, please replace the Build-Depends on libdbus-glib-1-dev
with a Build-Depends on libdbus-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#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine

2020-04-05 Thread John Paul Adrian Glaubitz

Source: librsvg
Version: 2.48.0-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc

Hi!

librsvg currently fails with a linking error on powerpc [1]:

  = note: /usr/bin/ld: bss-plt forced due to 
/<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.16te3j7dbumhvm74.rcgu.o
  /usr/bin/ld: 
/<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.2bda6oryqf97lk8y.rcgu.o:
 in function `rsvg_c_api::c_api::CHandle::set_base_url':
  
2bda6oryqf97lk8y:(.text._ZN10rsvg_c_api5c_api7CHandle12set_base_url17h7b7ca170a5e223b2E+0xa4):
 undefined reference to `rsvg_g_critical_from_c'
  /usr/bin/ld: 
/<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.2bda6oryqf97lk8y.rcgu.o:
 in function `rsvg_c_api::c_api::CHandle::get_handle_ref':
  
2bda6oryqf97lk8y:(.text._ZN10rsvg_c_api5c_api7CHandle14get_handle_ref17hb5b3d86143bb7e4aE+0x178):
 undefined reference to `rsvg_g_critical_from_c'
  collect2: error: ld returned 1 exit status

This particular problem on powerpc does not show on openSUSE [2] and I cannot 
reproduce
it when building the upstream source instead of the Debian package.

I have tried removing Debian-specific build flags from debian/rules and also 
adding
Debian's own build flags for an upstream build using "dpkg-buildflags --export" 
plus
playing around with the configure flags, but so far I haven't figured out why 
the
linking problems show only when building the Debian package.

The issue can be reproduced on the porterbox perotto.debian.net.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=librsvg=powerpc=2.48.0-2=1586078010=0
> [2] 
> https://build.opensuse.org/build/openSUSE:Factory:PowerPC/standard/ppc/librsvg/_log

--
 .''`.  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#955843: gnome-flashback: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: gnome-flashback
Version: 3.36.1-1
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 I couldn't find
any sign of it actually *using* dbus-glib - presumably it used to use
dbus-glib and was later ported to GDBus? 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#955840: freerdp2: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: freerdp2
Version: 0.2.0-3
Severity: normal
Tags: upstream
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.

freerdp2 Build-Depends on libdbus-glib-1-dev, and its upstream build
system checks that dbus-glib is available at build-time, but I couldn't
find any references to dbus-glib being used in practice. If this analysis
is correct, please remove the build system checks for dbus-glib (this
change could usefully be sent upstream) and 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#955842: gimp: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: gimp
Version: 2.10.18-1
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.

gimp Build-Depends on libdbus-glib-1-dev, but I couldn't find any sign of
it actually *using* dbus-glib - presumably it used to use dbus-glib and
was later ported to GDBus? 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#955841: libvirt: CVE-2020-10701: guest agent timeout can be set under read-only mode leading to DoS

2020-04-05 Thread Salvatore Bonaccorso

Source: libvirt
Version: 6.0.0-5
Severity: important
Tags: security upstream
Control: found -1 6.0.0-4
Control: found -1 6.0.0~rc1-1

Hi,

The following vulnerability was published for libvirt.

CVE-2020-10701[0]:
| guest agent timeout can be set under read-only mode leading to DoS

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10701
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10701

Please adjust the affected versions in the BTS as needed.



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

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

Bug#955839: fcitx-fbterm: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: fcitx-fbterm
Version: 0.2.0-3
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.

fcitx-fbterm Build-Depends on libdbus-glib-1-dev, but I couldn't find
any sign of it actually *using* dbus-glib. 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#955838: eom: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: eom
Version: 1.24.0-1
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.

eom Build-Depends on libdbus-glib-1-dev, but I couldn't find any sign of
it actually *using* dbus-glib - presumably it used to use dbus-glib and
was later ported to GDBus? 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#955833: Minimalistic server configuration file

2020-04-05 Thread Guillaume Brocker


Here is the minimalistic configuration file I've used to do my testings.

--
/etc/lighttpd/test.conf

server.document-root = "/var/www/html/"
server.modules += ( "mod_openssl" )

$SERVER["socket"] == "0.0.0.0:443" {
    ssl.engine  = "enable"
    ssl.pemfile = "/etc/lighttpd/cert.pem"
    ssl.privkey = "/etc/lighttpd/privkey.pem"
    ssl.cipher-list = "HIGH"
}

Bug#955837: entangle: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: entangle
Version: 2.0-1
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.

entangle Build-Depends on libdbus-glib-1-dev, but I couldn't find any
sign of it actually *using* dbus-glib. 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#955836: dlt-daemon: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: dlt-daemon
Version: 2.18.4-0.1
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.

dlt-daemon Build-Depends on libdbus-glib-1-dev, but it looks as though
it does not actually use dbus-glib. Instead, it uses the reference
D-Bus implementation, libdbus (dbus-1.pc), which is the libdbus-1-dev
Debian package.

If this is correct, please replace the Build-Depends on libdbus-glib-1-dev
with a Build-Depends on libdbus-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#955834: enchant: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: enchant
Version: 1.6.0-11.3
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.

enchant Build-Depends on libdbus-glib-1-dev, but it looks as though
its only use of dbus-glib is in the zemberek backend, which is explicitly
disabled in debian/rules. If this is correct, please remove the
build-dependency.

If this package has other uses of dbus-glib that I have missed, or if the
zemberek backend needs to be reinstated, please see [0] for how to proceed.

Thanks,
smcv

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

Bug#955835: enchant-2: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Source: enchant-2
Version: 2.2.8-1
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.

enchant-2 Build-Depends on libdbus-glib-1-dev, but it looks as though
its only use of dbus-glib is in the zemberek backend, which is explicitly
disabled in debian/rules. If this is correct, please remove the
build-dependency.

If this package has other uses of dbus-glib that I have missed, or if the
zemberek backend needs to be reinstated, please see [0] for how to proceed.

Thanks,
smcv

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

Bug#955833: lighttpd: Get requests send invalid data for files above 30kB

2020-04-05 Thread Guillaume Brocker

Package: lighttpd
Version: 1.4.55-1
Severity: important

Dear Maintainer,

Here is a very wired bug. I'll try to explain...

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.

I've done my investigations using png image files, having different sizes. I've 
also tested with different client softawares : firefox 74.0, gnome-web 3.34.4, 
and wget 1.20.3. ANd I used a minimalistic server configuration file that can 
be found as attachment.

Thank's for your help !

Guillaume


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

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-5
ii  libbz2-1.01.0.8-2
ii  libc6 2.30-4
ii  libcrypt1 1:4.4.15-1
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12+b1
ii  libssl1.1 1.1.1d-2
ii  lsb-base  11.1.0
ii  mime-support  3.64
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages lighttpd recommends:
ii  perl5.30.0-9
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils   
pn  lighttpd-doc
pn  lighttpd-mod-authn-gssapi   
pn  lighttpd-mod-authn-pam  
pn  lighttpd-mod-authn-sasl 
pn  lighttpd-mod-cml
pn  lighttpd-mod-geoip  
pn  lighttpd-mod-magnet 
pn  lighttpd-mod-maxminddb  
pn  lighttpd-mod-trigger-b4-dl  
pn  lighttpd-mod-vhostdb-dbi
pn  lighttpd-mod-vhostdb-pgsql  
pn  lighttpd-mod-webdav 
pn  lighttpd-modules-ldap   
pn  lighttpd-modules-mysql  
ii  openssl 1.1.1d-2
ii  php-cgi 2:7.3+69
ii  php7.0-cgi [php-cgi]7.0.31-1
ii  php7.3-cgi [php-cgi]7.3.15-3
pn  rrdtool 

-- Configuration Files:
/etc/lighttpd/conf-available/10-ssl.conf changed:
server.modules += ( "mod_openssl" )
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine  = "enable"
ssl.pemfile = "/etc/lighttpd/cert.pem"
ssl.privkey = "/etc/lighttpd/privkey.pem"
ssl.cipher-list = "HIGH"
}

/etc/lighttpd/conf-available/90-debian-doc.conf changed:
$HTTP["remoteip"] =~ "^127\.0\.0\.1$|^::1$" {
alias.url += (
#   "/cgi-bin/" => "/usr/lib/cgi-bin/",
"/doc/" => "/usr/share/doc/",
"/images/" => "/usr/share/images/"
)
$HTTP["url"] =~ "^/doc/|^/images/" {
dir-listing.activate = "enable"
}
$HTTP["url"] =~ "^/cgi-bin/" {
cgi.assign = ( "" => "" )
}
}

/etc/lighttpd/lighttpd.conf changed:
server.modules = (
"mod_indexfile",
"mod_access",
"mod_alias",
"mod_redirect",
)
server.document-root= "/var/www/html"
server.upload-dirs  = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/run/lighttpd.pid"
server.username = "www-data"
server.groupname= "www-data"
server.port = 80
server.http-parseopts = (
  "header-strict"   => "enable",# default
  "host-strict" => "enable",# default
  "host-normalize"  => "enable",# default
  "url-normalize-unreserved"=> "enable",# recommended highly
  "url-normalize-required"  => "enable",# recommended
  "url-ctrls-reject"=> "enable",# recommended
  "url-path-2f-decode"  => "enable",# recommended highly (unless breaks app)
 #"url-path-2f-reject"  => "enable",
  "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks app)
 #"url-path-dotseg-reject"  => "enable",
 #"url-query-20-plus"   => "enable",# consistency in query string
)
index-file.names= ( "index.php", "index.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
compress.cache-dir  = "/var/cache/lighttpd/compress/"
compress.filetype   = ( "application/javascript", "text/css", 
"text/html", "text/plain" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"
server.compat-module-load   = "disable"
server.modules += (
"mod_compress",
"mod_dirlisting",
"mod_staticfile",
)


-- no debconf information

Bug#955832: dbus-test-runner: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Package: dbus-test-runner
Version: 16.10.0~bzr100+repack1-4.1
Severity: normal
Tags: upstream
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.

dbus-test-runner Build-Depends on libdbus-glib-1-dev, but doesn't have
a runtime Depends on libdbus-glib-1-2, and I couldn't find any actual
*uses* of dbus-glib, except for a check in configure.ac. Perhaps the
dependency was removed in the past and the upstream developers just
forgot to remove the configure check?

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#955831: libsocl-contrib-1.3-0: please rebuild against new libhdf5 packages on sid

2020-04-05 Thread Giacomo Mulas

Package: libsocl-contrib-1.3-0
Version: 1.3.3+dfsg-1
Severity: normal

Dear Maintainer,

libsocl-contrib-1.3-0, libstarpu-contrib-1.3-2, other packages built from
the starpu-contrib source package need to be rebuilt updating their
dependencies on the new versions of libhdf, since they currently explicitly
depend on libhdf5-103, which is being replaced by libhdf5-103-1.
Till then, these packages will be uninstallable.

Thanks in advance, best regards
Giacomo Mulas


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

Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set 
to it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsocl-contrib-1.3-0 depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-9
ii  libc6  2.30-4
ii  libhdf5-1031.10.4+repack-11
ii  liblapack3 [liblapack.so.3]3.9.0-2
ii  libopenblas0-pthread [liblapack.so.3]  0.3.9+ds-1
ii  libstarpu-contrib-1.3-21.3.3+dfsg-1

libsocl-contrib-1.3-0 recommends no packages.

libsocl-contrib-1.3-0 suggests no packages.

-- no debconf information

Bug#955830: efax-gtk: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Package: efax-gtk
Version: 3.2.8-2.1
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.

efax-gtk Build-Depends on libdbus-glib-1-dev, but its README says:

gtk+3 >= 2.99.0, dbus-glib >= 0.70 and libtiff must be installed,
except that dbus-glib is not required if glib >= 2.26.0.

GLib 2.26 is about 10 years old, so the libdbus-glib-1-dev Build-Depends
should be unnecessary now.

If efax-gtk 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#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev

2020-04-05 Thread Bernhard Übelacker

Dear Maintainer,
I tried to have a look and it looks like being related
to the libgrpc++1 package.

The _ZN4grpc13ClientContextC1Ev symbol was included in
libgrpc++1 versions up to 1.17.2-1.
Since version 1.22.0-2 it is missing from that library.

Because 1.26.0-2 is the first version after 1.16.1-1,
which got uploaded to unstable (other versions just in
experimental), this issue got visible since 2020-03-21.

A local rebuild of sysdig against libgrpc++1 1.26.0-2
seems to work.

Therefore it looks like there was an ABI change in libgrpc++1.
I am not sure what actions on grpc side are needed,
but at least a rebuild of sysdig seems necessary.

Kind regards,
Bernhard


_ZN4grpc13ClientContextC1Ev

# https://demangler.com/
grpc::ClientContext::ClientContext()







https://buildd.debian.org/status/fetch.php?pkg=sysdig=amd64=0.26.4-1=1571110364=0

+==+
| sysdig 0.26.4-1 (amd64)  Tue, 15 Oct 2019 03:28:26 + |
+==+






approx:
debian-11-bullseye-snapshot.debian.org  
https://snapshot.debian.org/archive/debian/20191016T00Z/

sources.list:
# snapshot
deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb-src [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ unstable main
deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-debug-snapshot.debian.org/ 
unstable-debug main


# Unstable amd64 qemu VM as of date 2019-10-16

apt update
apt dist-upgrade


apt install systemd-coredump binutils sysdig


# dpkg -l | grep -E "sysdig|0.26.4-1"
ii  sysdig0.26.4-1 amd64
system-level exploration and troubleshooting tool
ii  sysdig-dkms   0.26.4-1 all  
system-level exploration and troubleshooting tool - kernel source


##


# for lib in `ldd /usr/bin/sysdig | grep -v -E 
"linux-vdso.so.1|/lib64/ld-linux-x86-64.so.2" | awk '{print $3}'`; do echo 
x $lib; nm -D $lib; done | grep -E "x|_ZN4grpc13ClientContextC1Ev"
...
x /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
00026b60 T _ZN4grpc13ClientContextC1Ev
x /lib/x86_64-linux-gnu/libprotobuf.so.17
...

# dpkg -S /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1
libgrpc++1:amd64: /usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1

# dpkg -l | grep -E "libgrpc|1.16.1-1+b1"
ii  libgrpc++1:amd64  1.16.1-1+b1  amd64
high performance general RPC framework
ii  libgrpc6:amd641.16.1-1+b1  amd64
high performance general RPC framework


##



wget 
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb2_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191119T213110Z/pool/main/g/grpc/libgrpc6_1.16.1-1%2Bb2_amd64.deb
dpkg -i *_1.16.1-1+b2_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00026b70 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20200220T030240Z/pool/main/g/grpc/libgrpc%2B%2B1_1.16.1-1%2Bb3_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181203T153211Z/pool/main/g/grpc/libgrpc6_1.16.1-1_amd64.deb
dpkg -i --force-depends *_1.16.1-1+b3_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00026b80 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.0-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181206T103113Z/pool/main/g/grpc/libgrpc7_1.17.0-1_amd64.deb
dpkg -i --force-depends *_1.17.0-1_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev



##



wget 
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc%2B%2B1_1.17.2-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20181217T091644Z/pool/main/g/grpc/libgrpc7_1.17.2-1_amd64.deb
dpkg -i --force-depends *_1.17.2-1_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep 
_ZN4grpc13ClientContextC1Ev
00032da0 T _ZN4grpc13ClientContextC1Ev



##


grpc 1.22.0-1, not available for amd64


##



wget 
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc%2B%2B1_1.22.0-2_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190811T045655Z/pool/main/g/grpc/libgrpc7_1.22.0-2_amd64.deb
dpkg -i --force-depends *_1.22.0-2_*

# nm -D /lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1 | grep

Bug#955827: Please remove me from uploaders

2020-04-05 Thread jnqnfe

On Sun, 2020-04-05 at 12:35 +0100, Ana Custura wrote:
> I've not been involved in this for a while now, please remove me from
> the uploaders field in the next upload to keep the list accurate.

you can submit a merge request via salsa...

Bug#955829: cinnamon-session: unnecessarily Build-Depends on deprecated dbus-glib

2020-04-05 Thread Simon McVittie

Package: cinnamon-session
Version: 4.4.1-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation

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.

cinnamon-session Build-Depends on libdbus-glib-1-dev, but doesn't seem
to check for it or use it anywhere, so the Build-Depends can probably
just be dropped.

If cinnamon-session 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#955828: cinnamon-control-center: Build-Depends on deprecated dbus-glib, but doesn't need to

2020-04-05 Thread Simon McVittie

Package: cinnamon-control-center
Version: 4.4.0-2
Severity: normal
Tags: upstream
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation

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.

cinnamon-control-center Build-Depends on libdbus-glib-1-dev, and has a
configure check "PKG_CHECK_MODULES(DATETIME_PANEL, ... dbus-glib-1)".
However, it doesn't actually seem to *use* dbus-glib anywhere, and NEWS
says "configure: datetime panel do not depend on dbus-glib anymore",
so this dependency and check can probably be dropped without any real
code changes.

If cinnamon-control-center 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

2020-04-05 Thread Ana Custura

Package: live-tasks


Hi,

I've not been involved in this for a while now, please remove me from
the uploaders field in the next upload to keep the list accurate.

Thank you,

Ana

Bug#955826: cinnamon: Build-Depends on deprecated dbus-glib, but doesn't need to

2020-04-05 Thread Simon McVittie

Package: cinnamon
Version: 4.4.8-3
Severity: normal
Tags: upstream
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation

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.

cinnamon Build-Depends on libdbus-glib-1-dev, checks for dbus-glib-1.pc
in configure.ac, and has #include  in src/main.c.

However, from a quick check, it seems that its only uses of dbus-glib
are for a few constants with names starting with DBUS_, which actually
come from  in dbus-1.pc (libdbus-1-dev).

If this is true, please either change it to use libdbus-1-dev, dbus-1.pc
and  instead, or hard-code the values of those constants
in cinnamon (they are part of the D-Bus "wire protocol" documented in
the D-Bus Specification[1], and will not change) and drop the dependency
completely.

If cinnamon 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
[1] 
https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-request-name

Bug#951999: Autoconf issue in mpqc

2020-04-05 Thread Jeremy Sowden

On 2020-04-05, at 12:13:45 +0100, Jeremy Sowden wrote:
> On 2020-04-05, at 12:45:47 +0200, Andreas Tille wrote:
> > On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote:
> > > > Any help would be appreciated.
> > > >
> > > > [1] https://salsa.debian.org/debichem-team/mpqc
> > >
> > > Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it
> > > (patch attached).
> >
> > Thanks a lot for the promising patch I have commited to Git[1].
> > Unfortunately the build does not yet succeed in a pbuilder chroot.
> > 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.

J.
diff --git a/debian/patches/autoheader.patch b/debian/patches/autoheader.patch
new file mode 100644
index ..f00d772e29ef
--- /dev/null
+++ b/debian/patches/autoheader.patch
@@ -0,0 +1,69 @@
+diff --git a/configure.in b/configure.in
+index 99a09d38b3c2..c183ac3ef252 100644
+--- a/configure.in
 b/configure.in
+@@ -11,6 +11,8 @@ AC_CONFIG_HEADER(src/lib/scconfig.h)
+ AC_CONFIG_AUX_DIR(bin)
+ AC_CONFIG_MACRO_DIR([lib/autoconf])
+ 
++AC_DEFINE_HEADER_TEMPLATES
++
+ AC_CANONICAL_SYSTEM
+ 
+ AC_DEFINE_UNQUOTED(HOST_ARCH, "$host")
+diff --git a/lib/autoconf/templates.m4 b/lib/autoconf/templates.m4
+new file mode 100644
+index ..693d54289326
+--- /dev/null
 b/lib/autoconf/templates.m4
+@@ -0,0 +1,50 @@
++AC_DEFUN([AC_DEFINE_HEADER_TEMPLATES],[
++AH_TEMPLATE([ALWAYS_USE_MPI], [])
++AH_TEMPLATE([CXX_RESTRICT], [])
++AH_TEMPLATE([DEFAULT_ARMCI], [])
++AH_TEMPLATE([DEFAULT_MPI], [])
++AH_TEMPLATE([DEFAULT_MTMPI], [])
++AH_TEMPLATE([DEFAULT_SC_MEMORY], [])
++AH_TEMPLATE([EXPLICIT_TEMPLATE_INSTANTIATION], [])
++AH_TEMPLATE([HAVE_ARMCI], [])
++AH_TEMPLATE([HAVE_BACKTRACE], [])
++AH_TEMPLATE([HAVE_CCA_CHEM_HEADERS], [])
++AH_TEMPLATE([HAVE_CCA_SPEC_BABEL_HEADERS], [])
++AH_TEMPLATE([HAVE_FCHDIR], [])
++AH_TEMPLATE([HAVE_IOS_FMTFLAGS], [])
++AH_TEMPLATE([HAVE_ISNAN], [])
++AH_TEMPLATE([HAVE_LIBDERIV], [])
++AH_TEMPLATE([HAVE_LIBINT], [])
++AH_TEMPLATE([HAVE_LIBR12], [])
++AH_TEMPLATE([HAVE_LONG_LONG], [])
++AH_TEMPLATE([HAVE_MPI], [])
++AH_TEMPLATE([HAVE_MPIIO], [])
++AH_TEMPLATE([HAVE_MPIPP], [])
++AH_TEMPLATE([HAVE_MPI_INIT_THREAD], [])
++AH_TEMPLATE([HAVE_NIAMA], [])
++AH_TEMPLATE([HAVE_PERF], [])
++AH_TEMPLATE([HAVE_PTHREAD], [])
++AH_TEMPLATE([HAVE_PUBSEEKOFF], [])
++AH_TEMPLATE([HAVE_SCALABLE_BLAS], [])
++AH_TEMPLATE([HAVE_SEEKOFF], [])
++AH_TEMPLATE([HAVE_SGETN], [])
++AH_TEMPLATE([HAVE_SIDL_HEADERS], [])
++AH_TEMPLATE([HAVE_SYSV_IPC], [])
++AH_TEMPLATE([HAVE_TYPENAME], [])
++AH_TEMPLATE([HOST_ARCH], [])
++AH_TEMPLATE([INSTALLED_SCLIBDIR], [])
++AH_TEMPLATE([REF_OPTIMIZE], [])
++AH_TEMPLATE([SCDATADIR], [])
++AH_TEMPLATE([SC_BUILDID], [])
++AH_TEMPLATE([SC_MAJOR_VERSION], [])
++AH_TEMPLATE([SC_MICRO_VERSION], [])
++AH_TEMPLATE([SC_MINOR_VERSION], [])
++AH_TEMPLATE([SC_MPI_THREAD_LEVEL], [])
++AH_TEMPLATE([SC_VERSION], [])
++AH_TEMPLATE([SEMCTL_REQUIRES_SEMUN], [])
++AH_TEMPLATE([SIGHASELLIP], [])
++AH_TEMPLATE([SRC_SCLIBDIR], [])
++AH_TEMPLATE([TARGET_ARCH], [])
++AH_TEMPLATE([USING_NAMESPACE_STD], [])
++AH_TEMPLATE([WORDS_BIGENDIAN], [])
++])
diff --git a/debian/patches/series b/debian/patches/series
index d700ae497e80..db79d4fb8ff5 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -11,3 +11,4 @@
 g++6-constexpr.patch
 Fix_mpi.patch
 autoconf.patch
+autoheader.patch


signature.asc
Description: PGP signature

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

2020-04-05 Thread Holger Levsen

On Fri, Apr 03, 2020 at 10:20:37PM +, Mike Gabriel wrote:
> Possibly an option for Debian Edu? Maybe even for Chromium in Debian?

yes, I'd suggest to close this bug and file a new one against chromium...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#955825: isc-dhcp-client: wrong ipv6 prefix length set automatically

2020-04-05 Thread Adrian Zaugg

Package: isc-dhcp-client
Version: 4.3.1-6+deb8u4
Severity: important
Tags: ipv6

Requesting an address with dhclient over dhcp6 does not always set the ipv6 
prefix length 
right. The address received seems always to get a /128 prefix set, even if the 
dhcp6 server 
sends another one.

I would expect dhclient to set the prefix lenght, if the dhcp6 server sends one.

The code in /sbin/dhclient-script under the relevant section "### DHCPv6 
Handlers" is the 
same in Devuan Jessie, where I used reportbug to write this bug, Debian Stretch 
(4.3.5-3+deb9u1)
and in Debian Sid (4.4.1-2.1+b2).

In the code that does set the ipv6 address using iproute2 there is no prefix 
mentioned at all. 
See line 385 and the following:

385 BOUND6|RENEW6|REBIND6)
386 if [ "${new_ip6_address}" ]; then
387 # set leased IP
388 ip -6 addr add ${new_ip6_address} \
389 dev ${interface} scope global
390 fi

It could be that /sbin/dhclient should set the prefix to the address, I don't 
know.

This part has two problems: It should also be called upon reason REBOOT6 (see 
man dhclient-script(8)) 
and it should set the prefix if one was given (and not already present with the 
address). Something 
like the following would help:

385 BOUND6|RENEW6|REBIND6|REBOOT6)
386 if [ "${new_ip6_address}" ]; then
387 
388 # check wether a prefix was passed and add it to the address
389 if [ -n "$new_ip6_prefixlen" ]; then
390 
new_ip6_address_and_prefix="${new_ip6_address}/${new_ip6_prefixlen}"
391 else
392 new_ip6_address_and_prefix="${new_ip6_address}"
393 fi
394 
395 # set leased IP
396 ip -6 addr add ${new_ip6_address_and_prefix} \
397 dev ${interface} scope global
398 fi

What really confuses me, is that ISC did change the IPv6 handling in the 
dhclient-script, but it is not
brought to Debian. In the upstream version they call a function 
"add_ipv6_addr_with_DAD". So I guess, the
bug is not present there. If I watch at the source package of 4.4.1-2.1, I do 
see the upstream changes, but
they are not present in the script that the binary package of 4.4.1-2.1+b2 
delivers. Sorry, I don't 
understand what's going on here.

Thank you for your help.


Regards, Adrian.


-- System Information:
Debian Release: 7.11
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.4+b1
ii  iproute2  3.16.0-2
ii  isc-dhcp-common   4.3.1-6+deb8u4
ii  libc6 2.19-18+deb8u10
ii  libdns-export100  1:9.9.5.dfsg-9+deb8u18
ii  libirs-export91   1:9.9.5.dfsg-9+deb8u18
ii  libisc-export95   1:9.9.5.dfsg-9+deb8u18

isc-dhcp-client recommends no packages.

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd  
pn  resolvconf 

-- no debconf information

Bug#952145: t-code: FTBFS: build-dependency not installable: emacs25

2020-04-05 Thread Tatsuya Kinoshita

Control: tags -1 + patch

On February 23, 2020 at 2:01PM +0100, lucas (at debian.org) wrote:
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-main-dummy : Depends: emacs25 but it is not installable

The attached patch fixes this FTBFS bug, though I don't know
whether this package is really usable on Emacs 26.

Thanks,
--
Tatsuya Kinoshita
From 932516eb83afab5e9cf14f16c99915bf0e6c92ce Mon Sep 17 00:00:00 2001
From: Tatsuya Kinoshita 
Date: Sun, 5 Apr 2020 19:45:58 +0900
Subject: [PATCH] Prefer emacs-nox and emacs instead of emacs25 (Closes:
 #952145)

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index aa0cd6f..4eccace 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: HIGUCHI Daisuke (VDR dai) 
 Standards-Version: 4.3.0
 Build-Depends: debhelper (>= 11~)
-Build-Depends-Indep: emacs25 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
+Build-Depends-Indep: emacs-nox | emacs | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
 Homepage: http://openlab.jp/tcode/
 Vcs-Git: https://salsa.debian.org/debian/t-code.git
 Vcs-Browser: https://salsa.debian.org/debian/t-code
@@ -13,7 +13,7 @@ Package: t-code
 Architecture: all
 Pre-Depends: dpkg (>= 1.17.5)
 Depends: ${misc:Depends}, t-code-common (= ${source:Version}),
-	emacs25 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
+	emacs-nox | emacs | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
 Multi-Arch: foreign
 Description: Japanese direct input method environment for emacsen
  This package is provides tc2. the T-Code input environment for emacsen,
-- 
2.26.0



pgp7vF4nMmSsG.pgp
Description: PGP signature

Bug#955823: bluez: Build-Depends on dbus-glib but does not appear to use it

2020-04-05 Thread Simon McVittie

Package: bluez
Version: 5.50-1.2
Severity: normal
Control: found -1 5.52-1
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation

bluez Build-Depends on libdbus-glib-1-dev, but does not appear to use
it, and does not have a runtime Depends on the corresponding library
libdbus-glib-1-2.

It looks as though bluez *does* explicitly check for dbus-1 >= 1.6
(libdbus-1-dev >= 1.6 in Debian terms), so it should explicitly
Build-Depend on that instead.

Please update the build-dependencies.

(This is part of a mass-bug-filing for dependencies on dbus-glib,
which is deprecated.)

smcv

Bug#955824: bluez-tools: Build-Depends on dbus-glib but does not appear to use it

2020-04-05 Thread Simon McVittie

Package: bluez-tools
Version: 2.0~20170911.0.7cb788c-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: dbus-glib-deprecation

bluez-tools Build-Depends on libdbus-glib-1-dev, but does not appear
to use it, and does not have a runtime Depends on the corresponding
library libdbus-glib-1-2.

Please update the build-dependencies to remove libdbus-glib-1-dev.

(This is part of a mass-bug-filing for dependencies on dbus-glib,
which is deprecated.)

smcv

Bug#953409: frescobaldi: Missing dependency: ModuleNotFoundError: No module named 'PyQt5.QtWebEngineWidgets'

2020-04-05 Thread Moebius


Bonjour,
I can confirm that bug, already present in a former version of frescobaldi
Same fix than you did, as you can expect :-)
cordialement,

Bug#942081: utox: crashed on advanced network settings

2020-04-05 Thread BunteKnete


Package: utox
Version: 0.17.0-1
OS: Debian GNU/Linux 10

Dear Maintainer,

On the switches UDP (on/off) or IPv6(On/Off) or editing the proxy (both
text fields) utox crashes immediately. After restart tox manually, my
settings are not taken.

using tor is impossible.


utox/stable,now 0.17.0-1 amd64
libtoxcore2/stable,now 0.2.9-1 amd64
libxcb1/stable,now 1.13.1-2 amd64

Bug#951999: Autoconf issue in mpqc

2020-04-05 Thread Jeremy Sowden

On 2020-04-05, at 12:45:47 +0200, Andreas Tille wrote:
> Hi Jeremy,
>
> On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote:
> > > Any help would be appreciated.
> > >
> > > [1] https://salsa.debian.org/debichem-team/mpqc
> >
> > Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch
> > attached).
>
> Thanks a lot for the promising patch I have commited to Git[1].
> Unfortunately the build does not yet succeed in a pbuilder chroot.
> 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.  autoreconf is still
failing.

J.

> [...]
> autoheader: warning: missing template: ALWAYS_USE_MPI
> autoheader: Use AC_DEFINE([ALWAYS_USE_MPI], [], [Description])
> autoheader: warning: missing template: CXX_RESTRICT
> autoheader: warning: missing template: DEFAULT_ARMCI
> autoheader: warning: missing template: DEFAULT_MPI
> autoheader: warning: missing template: DEFAULT_MTMPI
> autoheader: warning: missing template: DEFAULT_SC_MEMORY
> autoheader: warning: missing template: EXPLICIT_TEMPLATE_INSTANTIATION
> autoheader: warning: missing template: HAVE_ARMCI
> autoheader: warning: missing template: HAVE_BACKTRACE
> autoheader: warning: missing template: HAVE_CCA_CHEM_HEADERS
> autoheader: warning: missing template: HAVE_CCA_SPEC_BABEL_HEADERS
> autoheader: warning: missing template: HAVE_FCHDIR
> autoheader: warning: missing template: HAVE_IOS_FMTFLAGS
> autoheader: warning: missing template: HAVE_ISNAN
> autoheader: warning: missing template: HAVE_LIBDERIV
> autoheader: warning: missing template: HAVE_LIBINT
> autoheader: warning: missing template: HAVE_LIBR12
> autoheader: warning: missing template: HAVE_LONG_LONG
> autoheader: warning: missing template: HAVE_MPI
> autoheader: warning: missing template: HAVE_MPIIO
> autoheader: warning: missing template: HAVE_MPIPP
> autoheader: warning: missing template: HAVE_MPI_INIT_THREAD
> autoheader: warning: missing template: HAVE_NIAMA
> autoheader: warning: missing template: HAVE_PERF
> autoheader: warning: missing template: HAVE_PTHREAD
> autoheader: warning: missing template: HAVE_PUBSEEKOFF
> autoheader: warning: missing template: HAVE_SCALABLE_BLAS
> autoheader: warning: missing template: HAVE_SEEKOFF
> autoheader: warning: missing template: HAVE_SGETN
> autoheader: warning: missing template: HAVE_SIDL_HEADERS
> autoheader: warning: missing template: HAVE_SYSV_IPC
> autoheader: warning: missing template: HAVE_TYPENAME
> autoheader: warning: missing template: HOST_ARCH
> autoheader: warning: missing template: INSTALLED_SCLIBDIR
> autoheader: warning: missing template: REF_OPTIMIZE
> autoheader: warning: missing template: SCDATADIR
> autoheader: warning: missing template: SC_BUILDID
> autoheader: warning: missing template: SC_MAJOR_VERSION
> autoheader: warning: missing template: SC_MICRO_VERSION
> autoheader: warning: missing template: SC_MINOR_VERSION
> autoheader: warning: missing template: SC_MPI_THREAD_LEVEL
> autoheader: warning: missing template: SC_VERSION
> autoheader: warning: missing template: SEMCTL_REQUIRES_SEMUN
> autoheader: warning: missing template: SIGHASELLIP
> autoheader: warning: missing template: SRC_SCLIBDIR
> autoheader: warning: missing template: TARGET_ARCH
> autoheader: warning: missing template: USING_NAMESPACE_STD
> autoheader: warning: missing template: WORDS_BIGENDIAN
> autoreconf: /usr/bin/autoheader failed with exit status: 1
> [...]
diff --git a/configure.in b/configure.in
index ee82977e4931..5a77f343331e 100644
--- a/configure.in
+++ b/configure.in
@@ -9,7 +9,9 @@ AC_INIT(src/lib/util/ref/ref.h)
 AC_PREREQ(2.55)
 AC_CONFIG_HEADER(src/lib/scconfig.h)
 AC_CONFIG_AUX_DIR(bin)
 AC_CONFIG_MACRO_DIR([lib/autoconf])
+
+AC_DEFINE_HEADER_TEMPLATES
 
 AC_CANONICAL_SYSTEM
 
diff --git a/lib/autoconf/templates.m4 b/lib/autoconf/templates.m4
new file mode 100644
index ..693d54289326
--- /dev/null
+++ b/lib/autoconf/templates.m4
@@ -0,0 +1,50 @@
+AC_DEFUN([AC_DEFINE_HEADER_TEMPLATES],[
+AH_TEMPLATE([ALWAYS_USE_MPI], [])
+AH_TEMPLATE([CXX_RESTRICT], [])
+AH_TEMPLATE([DEFAULT_ARMCI], [])
+AH_TEMPLATE([DEFAULT_MPI], [])
+AH_TEMPLATE([DEFAULT_MTMPI], [])
+AH_TEMPLATE([DEFAULT_SC_MEMORY], [])
+AH_TEMPLATE([EXPLICIT_TEMPLATE_INSTANTIATION], [])
+AH_TEMPLATE([HAVE_ARMCI], [])
+AH_TEMPLATE([HAVE_BACKTRACE], [])
+AH_TEMPLATE([HAVE_CCA_CHEM_HEADERS], [])
+AH_TEMPLATE([HAVE_CCA_SPEC_BABEL_HEADERS], [])
+AH_TEMPLATE([HAVE_FCHDIR], [])
+AH_TEMPLATE([HAVE_IOS_FMTFLAGS], [])
+AH_TEMPLATE([HAVE_ISNAN], [])
+AH_TEMPLATE([HAVE_LIBDERIV], [])
+AH_TEMPLATE([HAVE_LIBINT], [])
+AH_TEMPLATE([HAVE_LIBR12], [])
+AH_TEMPLATE([HAVE_LONG_LONG], [])
+AH_TEMPLATE([HAVE_MPI], [])
+AH_TEMPLATE([HAVE_MPIIO], [])
+AH_TEMPLATE([HAVE_MPIPP], [])
+AH_TEMPLATE([HAVE_MPI_INIT_THREAD], [])
+AH_TEMPLATE([HAVE_NIAMA], [])
+AH_TEMPLATE([HAVE_PERF], [])
+AH_TEMPLATE([HAVE_PTHREAD], [])

Bug#955816: Improve documentation of bridge option

2020-04-05 Thread Luca Boccassi

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:

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

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

2020-04-05 Thread John Paul Adrian Glaubitz

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=sid
> https://buildd.debian.org/status/logs.php?pkg=vim=ppc64el

>> It also seems that the maintainer of the vim package would like to
>> get rid of vim-tiny which he currently only ships because of
>> debian-installer [1].
>>
>> Switching the vi implementation in debian-installer from src:vim to
>> src:busybox would therefore make both parties happy, I would say.
> 
> 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=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.

Adrian

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

Bug#955822: ITP: r-cran-kmsurv -- data sets for GNU R from Klein and Moeschberger (1997), Survival Analysis

2020-04-05 Thread Andreas Tille

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-kmsurv -- data sets for GNU R from Klein and Moeschberger 
(1997), Survival Analysis
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-kmsurv
  Version : 0.1
  Upstream Author : Original by Klein and Moeschberger, modifications by Jun Yan
* URL : https://cran.r-project.org/package=KMsurv
* License : GPL-3+
  Programming Lang: GNU R
  Description : data sets for GNU R from Klein and Moeschberger (1997), 
Survival Analysis
 Data sets and functions for Klein and Moeschberger (1997),
 "Survival Analysis, Techniques for Censored and Truncated
 Data", Springer.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-kmsurv

Bug#955821: torbrowser-launcher: include upstream patch to allow access to u2f tokens

2020-04-05 Thread Birger Schacht

Package: torbrowser-launcher
Version: 0.3.2-7
Severity: wishlist
Tags: patch

Dear Maintainers,

it would be great if U2F devices (like a yubikey) would be usable by
default with torbrowser. I created an upstream merge request to allow
these devices in the apparmor profile a couple of months ago and it was
was merged [0] (thanks to intrigeri!), but there was no new torbrowser
release since then.
Would it be possible to include the patch in the debian package? That
would allow using salsa with U2F tokens (and any other Gitlab instance
that might come up ;))

cheers,
Birger


[0] https://github.com/micahflee/torbrowser-launcher/pull/434


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-5
ii  python3   3.8.2-2
ii  python3-gpg   1.13.1-7
ii  python3-pyqt5 5.14.1+dfsg-3
ii  python3-requests  2.23.0+dfsg-2
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.2.7-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.4-1

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed [not included]

-- no debconf information
>From 3052e6579dd489923bca95a82308e5f4b6399e68 Mon Sep 17 00:00:00 2001
From: Birger Schacht 
Date: Sat, 4 Apr 2020 18:18:50 +0200
Subject: [PATCH] Add AppArmor patch to allow U2F devices

---
 .../0016-AppArmor-allow-u2f-devices.patch | 28 +++
 debian/patches/series |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/patches/0016-AppArmor-allow-u2f-devices.patch

diff --git a/debian/patches/0016-AppArmor-allow-u2f-devices.patch 
b/debian/patches/0016-AppArmor-allow-u2f-devices.patch
new file mode 100644
index 000..bc6130f
--- /dev/null
+++ b/debian/patches/0016-AppArmor-allow-u2f-devices.patch
@@ -0,0 +1,28 @@
+From: Birger Schacht 
+Date: Wed, 23 Oct 2019 19:47:55 +0200
+Subject: [PATCH] Allow torbrowser to access u2f devices
+
+(cherry picked from 704e5ca3b46ac1bcf7931875fc7d33ad13910e10)
+---
+ apparmor/torbrowser.Browser.firefox | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/apparmor/torbrowser.Browser.firefox 
b/apparmor/torbrowser.Browser.firefox
+index 42516b6..c067375 100644
+--- a/apparmor/torbrowser.Browser.firefox
 b/apparmor/torbrowser.Browser.firefox
+@@ -133,5 +133,14 @@ profile torbrowser_firefox 
@{torbrowser_firefox_executable} {
+   /etc/xfce4/defaults.list r,
+   /usr/share/xfce4/applications/ r,
+ 
++  # u2f (tested with Yubikey 4)
++  /sys/class/ r,
++  /sys/bus/ r,
++  /sys/class/hidraw/ r,
++  /run/udev/data/c24{7,9}:* r,
++  /dev/hidraw* rw,
++  # Yubikey NEO also needs this:
++  /sys/devices/**/hidraw/hidraw*/uevent r,
++
+   #include 
+ }
diff --git a/debian/patches/series b/debian/patches/series
index c1ae347..0eb4798 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -13,3 +13,4 @@
 0013-AppArmor-Pass-the-environment-to-Firefox-content-pro.patch
 0014-AppArmor-allow-running-the-Firefox-updater-from-its-.patch
 0015-Update-setup.py.patch
+0016-AppArmor-allow-u2f-devices.patch
-- 
2.26.0

Bug#953032: xkbcomp: Internal error: Could not resolve keysym XF86FullScreen

2020-04-05 Thread Reiner Herrmann

Control: affects -1 + src:awesome

This also caused a regression in awesome's autopkgtests [1], as this error
now appears on stderr:

> The XKEYBOARD keymap compiler (xkbcomp) reports:
> > Internal error:   Could not resolve keysym XF86FullScreen
> Errors from xkbcomp are not fatal to the X server

[1] https://ci.debian.net/packages/a/awesome/unstable/amd64/


signature.asc
Description: PGP signature

Bug#916564: python-pyte: new upstream version: 0.8.0

2020-04-05 Thread Andrej Shadura

Hi,

On Sun, 5 Apr 2020 at 12:24, Guilhem Moulin  wrote:
> On Sun, 05 Apr 2020 at 10:20:38 +0200, Andrej Shadura wrote:
> > On Sat, 4 Apr 2020 at 23:39, Guilhem Moulin  wrote:
> >> On Tue, 1 Oct 2019 at 16:21:54 +0200, Andrej Shadura wrote
> >>> Why? 0.4.8 should be good enough for anyone for a few years more :)
> >>
> >> FWIW termtosvg, which I just ITP'ed, needs pyte.graphics.FG_BG_256 which
> >> was added in 0.6.0 :-P
> >
> > Ha, my joke probably came across not very well :D
>
> I understood it was a joke, it's my tongue-in-cheek poke that apparently
> didn't come across as such ;-)

Oh no, it totally did, it’s just to a random observer (who doesn’t
know I have some work in progress somewhere on my disk) I might have
sounded a bit rude :)

-- 
Cheers,
  Andrej

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

2020-04-05 Thread Pietro Battiston

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#951999: Autoconf issue in mpqc

2020-04-05 Thread Andreas Tille

Hi Jeremy,

On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote:
> > Any help would be appreciated.
> >
> > [1] https://salsa.debian.org/debichem-team/mpqc
> 
> Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch
> attached).

Thanks a lot for the promising patch I have commited to Git[1].
Unfortunately the build does not yet succeed in a pbuilder chroot.
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 ...

Kind regards

 Andreas.

-- 
http://fam-tille.de
   dh_autoreconf -O--no-parallel
aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
configure.in:766: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from...
configure.in:766: the top level
configure.in:776: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from...
configure.in:776: the top level
configure.in:1259: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
configure.in:1259: the top level
configure.in:766: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from...
configure.in:766: the top level
configure.in:776: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from...
configure.in:776: the top level
configure.in:1259: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
configure.in:1259: the top level
configure.in:1761: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
lib/autoconf/libtool.m4:664: AC_LIBTOOL_COMPILER_OPTION is expanded from...
lib/autoconf/libtool.m4:4901: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
lib/autoconf/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
lib/autoconf/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
configure.in:1761: the top level
configure.in:1761: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
lib/autoconf/libtool.m4:709: AC_LIBTOOL_LINKER_OPTION is expanded from...
lib/autoconf/libtool.m4:4901: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
lib/autoconf/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
lib/autoconf/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
configure.in:1761: the top level
configure.in:1761: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
lib/autoconf/libtool.m4:332: _LT_AC_SYS_LIBPATH_AIX is expanded from...
lib/autoconf/libtool.m4:5428: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from...
lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
lib/autoconf/libtool.m4:60:

Bug#955820: libgtk-3-0: various regressions since 3.24.14, defer migration until resolved

2020-04-05 Thread Simon McVittie

Package: libgtk-3-0
Version: 3.24.17-1
Severity: serious
Justification: uploader says so
Tags: upstream help

GTK 3 releases since 3.24.14 seem to have had an unexpected number of
regressions. Some were fixed in 3.24.17, but that has its own regressions:

- gcr prompts apparently don't appear in non-GNOME Wayland compositors
  (https://gitlab.gnome.org/GNOME/gtk/-/issues/2574)

- windows with a "custom surface", such as waybar, don't appear
  (https://gitlab.gnome.org/GNOME/gtk/-/issues/2572,
  https://gitlab.gnome.org/GNOME/gtk/-/issues/2578)

- PaulePanter on #debian-gnome says:
  """
  The Firefox windows (image) always seems to be in the foreground,
  despite actually something else is happening on the GNOME Shell
  desktop. I have to switch to another tty and `killall firefox`
  """

https://gitlab.gnome.org/GNOME/gtk/-/issues/2577 might also be related.

(I'm using this version and haven't actually seen any of these myself...
some don't happen with GNOME, some don't happen unless you use particular
programs that I don't, and I have no idea why I'm not seeing the Firefox
issue.)

Let's not allow this version to migrate until these are resolved, or at
least understood.

smcv

Bug#955767: lacme: please comment out section [accountd] by default

2020-04-05 Thread Guilhem Moulin

Control: retitle -1 lacme: --socket= CLI option should take precedence over 
[accountd] config section
Control: tag -1 upstream

On Sun, 05 Apr 2020 at 07:42:13 +0200, Jonas Smedegaard wrote:
> Quoting Guilhem Moulin (2020-04-05 02:54:46)
>>> it is possible to use lacme with a remote accountd _without_ touching
>>> any conffile.
>> 
>> I see the appeal in that, will think of a better detection logic;
>> Suggestions welcome :-)
> 
> How about respecting "lacme --socket=path" - it is common behaviour for 
> command-line options to take priority over configfile options, and 
> you've swapped that logic for lacme making configfile editing mandatory.

Make sense, --socket= is meaningless in locally-controlled mode so I
don't foresee any regression.  Thanks for the suggestion!

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#955819: ITP: sphinx-autoapi -- Sphinx AutoAPI provides "autodoc" style documentation for multiple programming languages without needing to load, run, or import the project being documented.

2020-04-05 Thread Félix Sipma

Package: wnpp
Severity: wishlist
Owner: Félix Sipma 

* Package name: sphinx-autoapi
  Version : 1.2.1
  Upstream Author : Read the Docs, Inc
* URL : https://github.com/readthedocs/sphinx-autoapi/
* License : Expat
  Programming Lang: Python
  Description : Sphinx AutoAPI provides "autodoc" style documentation for 
multiple programming languages without needing to load, run, or import the 
project being documented.

In contrast to the traditional Sphinx autodoc, which is Python-only and 
uses code imports, AutoAPI finds and generates documentation by parsing 
source code.

This is needed for packaging the new version of khard.

I intend to maintain this package in the PAPT. I will need a sponsor to 
upload the package.

-- 
Félix


signature.asc
Description: PGP signature

Bug#955818: libc6: Invalid symbolic link directory x86_64-linux-gnu

2020-04-05 Thread Santiago José López Borrazás

Package: libc6
Version: 2.30-4
Severity: normal

Dear Maintainer,

This little mistake, which brings me upside down. It may be a symbolic
link problem, but...

Resolve that, every time I install a new package, it appears at the end
of everything:

ldconfig: /lib/x86_64-linux-gnu/ is not a symbolic link

I see everything correctly, but there is a but. And that but it is, that
every time I install a new package I get that.

The /etc/ld.so.conf.d/x86_64-linux-gnu.conf file is correct, I see no
problem.

This is kind of weird.

Thanks.

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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1 [libgcc-s1]  10-20200402-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.73
pn  glibc-doc  
ii  libc-l10n  2.30-4
ii  locales2.30-4

-- debconf information excluded

Bug#955817: kazam: Fails to get audio sources from pulseaudio with python3.8

2020-04-05 Thread Roberto

Package: kazam
Version: 1.4.5-3
Severity: important
Tags: upstream

Dear Maintainer,

Kazam fails to get audio sources from pulseaudio with python3.8.
The function time.clock() has been removed, after having been deprecated since
Python 3.3: use time.perf_counter() or time.process_time() instead.

Replacing time.clock() with time.perf_counter() in pulseaudio.py file solves
the problem.


Bebug before changes:

user@pc:~$ kazam --debug
WARNING Kazam - Failed to correctly detect operating system.
DEBUG Kazam - Starting ...
DEBUG Kazam - Running on: Ubuntu 12.10
DEBUG Kazam - Kazam version: 1.4.5 NCC-80102
DEBUG Kazam - Starting new instance ...
DEBUG Prefs - XDG_PICTURES is a directory and accessible
DEBUG Prefs-HW - Getting hardware specs
DEBUG Prefs-HW - Getting Video sources.
DEBUG Prefs-HW - Found 1 monitor(s).
DEBUG Prefs-HW -   Monitor 0 - X: 0, Y: 0, W: 1920, H: 1080
DEBUG Main - Gstreamer version detected: 1.16.2.0
DEBUG Main - Setting variables.
DEBUG PulseAudio - Starting mainloop.
DEBUG PulseAudio - Getting API.
DEBUG PulseAudio - Setting context.
DEBUG PulseAudio - Set state callback.
DEBUG PulseAudio - Connecting to server.
DEBUG PulseAudio - Start mainloop.
DEBUG PulseAudio - State connected.
DEBUG Main - Connecting indicator signals.
DEBUG Main - Starting in silent mode: False
DEBUG Indicator - Indicatior silent: False
DEBUG Indicator - Trying to bind hotkeys.

** (kazam:8174): WARNING **: 12:19:15.613: Binding 'F' failed!

** (kazam:8174): WARNING **: 12:19:15.614: Binding 'P' failed!
DEBUG Main - Main Window UI setup.
/usr/lib/python3/dist-packages/kazam/app.py:145: Warning: value "((GtkIconSize)
32)" of type 'GtkIconSize' is invalid or out of range for property 'icon-size'
of type 'GtkIconSize'
  self.builder.add_from_file(os.path.join(prefs.datadir, "ui", "kazam.ui"))
DEBUG Main - Unable to get name for ''

(kazam:8174): Gtk-WARNING **: 12:19:15.699: Can't set a parent on widget which
has a parent

(kazam:8174): Gtk-WARNING **: 12:19:15.717: Can't set a parent on widget which
has a parent
DEBUG Prefs - Getting Audio sources.
DEBUG PulseAudio - get_audio_sources() called.
DEBUG PulseAudio - Unable to get audio sources.
WARNING Prefs - Unable to find any audio devices.
DEBUG PulseAudio - pa_sourcelist_cb()
DEBUG PulseAudio -   IDX: 0
DEBUG PulseAudio -   Name:
b'alsa_input.usb-046d_HD_Pro_Webcam_C920_6768241F-02.analog-stereo'
DEBUG PulseAudio -   Desc: b'OrbiCam Est\xc3\xa9reo Anal\xc3\xb3gico'
DEBUG PulseAudio - pa_sourcelist_cb()
DEBUG PulseAudio -   IDX: 1
DEBUG PulseAudio -   Name: b'alsa_output.pci-_00_1f.3.hdmi-stereo.monitor'
DEBUG PulseAudio -   Desc: b'Monitor of Audio Interno Digital Stereo (HDMI)'
DEBUG PulseAudio - pa_sourcelist_cb()
DEBUG PulseAudio -   IDX: 2
DEBUG PulseAudio -   Name: b'alsa_input.pci-_00_1f.3.analog-stereo'
DEBUG PulseAudio -   Desc: b'Audio Interno Est\xc3\xa9reo Anal\xc3\xb3gico'
DEBUG PulseAudio - pa_sourcelist_cb() -- finished
DEBUG Main - Capture cursor: True.
DEBUG Main - Capture microphone: True.
DEBUG Main - Capture cursor_pic: True.
DEBUG Main - Capture borders_pic: True.
DEBUG Main - Quit requested.
DEBUG PulseAudio - Disconnecting from server.
DEBUG Kazam - Finishing ...



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (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=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kazam depends on:
ii  gir1.2-gst-plugins-base-1.0  1.16.2-dmo3
ii  gir1.2-gstreamer-1.0 1.16.2-2
ii  gir1.2-keybinder-3.0 0.3.2-1+b1
ii  gir1.2-wnck-3.0  3.36.0-1
ii  gnome-session-canberra   0.30-7
ii  gstreamer1.0-plugins-base1.16.2-dmo3
ii  gstreamer1.0-plugins-good1.16.2-dmo1
ii  gstreamer1.0-plugins-ugly1:1.16.2-dmo2
ii  gstreamer1.0-pulseaudio  1.16.2-dmo1
ii  python3  3.8.2-2
ii  python3-cairo1.16.2-2
ii  python3-dbus 1.2.16-1
ii  python3-gi   3.36.0-1
ii  python3-gi-cairo 3.36.0-1
ii  python3-xdg  0.26-1

Versions of packages kazam recommends:
ii  gstreamer1.0-libav  1:1.16.2-dmo2

kazam suggests no packages.

-- no debconf information

Bug#916564: python-pyte: new upstream version: 0.8.0

2020-04-05 Thread Guilhem Moulin

On Sun, 05 Apr 2020 at 10:20:38 +0200, Andrej Shadura wrote:
> On Sat, 4 Apr 2020 at 23:39, Guilhem Moulin  wrote:
>> On Tue, 1 Oct 2019 at 16:21:54 +0200, Andrej Shadura wrote
>>> Why? 0.4.8 should be good enough for anyone for a few years more :)
>>
>> FWIW termtosvg, which I just ITP'ed, needs pyte.graphics.FG_BG_256 which
>> was added in 0.6.0 :-P
> 
> Ha, my joke probably came across not very well :D

I understood it was a joke, it's my tongue-in-cheek poke that apparently
didn't come across as such ;-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#955056:

2020-04-05 Thread Andreas Tille

Control: forwarded -1 https://github.com/snakemake/snakemake/issues/296
Control: tags -1 upstream

Bug#951265: Fix fixed versions

2020-04-05 Thread Pirate Praveen




Control: fixed -1 2.0.17-1
Control: notfixed -1 2.017-1

Really fix correct versions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#955056:

2020-04-05 Thread Vladimir Jendrol

Issue in source repository: https://github.com/snakemake/snakemake/issues/296

Bug#951999: Autoconf issue in mpqc

2020-04-05 Thread Jeremy Sowden

On 2020-04-05, at 08:18:30 +0200, Andreas Tille wrote:
> while Nilesh has fixed the MPI-3.0 issue of mpqc in Git[1] the package
> does not build any more due to an autoconf issue:
>
> ...
> configure.in:1802: error: possibly undefined macro: AC_CHECK_CCA
>   If this token and others are legitimate, please use
> m4_pattern_allow.
>   See the Autoconf documentation.
> configure.in:1833: error: possibly undefined macro: AC_DEFINE_DIR
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> ...
>
> The macro AC_CHECK_CCA is defined in
>
>lib/autoconf/cca.m4
>
> but it seems it is not found any more by recent autotools.
>
> Any help would be appreciated.
>
> Kind regards
>
> Andreas.
>
> [1] https://salsa.debian.org/debichem-team/mpqc

Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch
attached).

J.
diff --git a/configure.in b/configure.in
index ee82977e4931..d615d3854a6c 100644
--- a/configure.in
+++ b/configure.in
@@ -9,6 +9,7 @@ AC_INIT(src/lib/util/ref/ref.h)
 AC_PREREQ(2.55)
 AC_CONFIG_HEADER(src/lib/scconfig.h)
 AC_CONFIG_AUX_DIR(bin)
+AC_CONFIG_MACRO_DIR([lib/autoconf])
 
 AC_CANONICAL_SYSTEM
 


signature.asc
Description: PGP signature

Bug#955411: ruby-image-processing FTBFS Failure: ImageProcessing::Vips#test_0003_allows changing metadata

2020-04-05 Thread Pirate Praveen

Control: fixed -1 1.10.3-1
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#951265: Closing

2020-04-05 Thread Pirate Praveen

Control: fixed -1 2.0.17-1
Control: notfixed -1 2.0.17-1

On Thu, 02 Apr 2020 12:06:12 +0530 Pirate Praveen  
wrote:
> fixed 951265 2.017-1
> thanks

Correcting fixed version.

> Fixed in last upload.
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#936061: reportbug: querybts doesn't find a certain existing bug report for package linux-image-5.2.0-2-amd64

2020-04-05 Thread Nis Martensen

On 31 Aug 2019 Nis Martensen wrote:
> I'm not familiar with reportbug-ng so I cannot tell how you managed to 
> find the bug there.
You might have found the bug there simply by searching for bugs in
src:linux, and not in linux-image-5.2.0-2-amd64.

I think the actual problem here is that the linux-image packages use a
bug control file with "Submit-As: src:linux", which however is not the
actual source package that the binaries get built from.

So as a solution reportbug could consider respecting a Submit-As already
when retrieving the list of existing bugs. It could do this either
instead of using the actual package name given on the command line, or
in addition (presenting the union of both lists to the user).

Bug#955816: Improve documentation of bridge option

2020-04-05 Thread Bastien Roucariès

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 applyFrom 04c9ce1ac1b9dc91eedb2f267766bb9682232ef0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Sun, 5 Apr 2020 11:08:11 +0200
Subject: [PATCH 6/6] State of bridge STP port are now case insensitive
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Improve use experience

Signed-off-by: Bastien Roucariès 
---
 bridge/link.c | 2 +-
 man/man8/bridge.8 | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/bridge/link.c b/bridge/link.c
index 074edf0..3bc7af2 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -378,7 +378,7 @@ static int brlink_modify(int argc, char **argv)
 			state = strtol(*argv, , 10);
 			if (!(**argv != '\0' && *endptr == '\0')) {
 for (state = 0; state < nstates; state++)
-	if (strcmp(port_states[state], *argv) == 0)
+	if (strcasecmp(port_states[state], *argv) == 0)
 		break;
 if (state == nstates) {
 	fprintf(stderr,
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 96ea482..b7b85d1 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -293,16 +293,16 @@ droot port selectio algorithms.
 
 .TP
 .BI state " STATE "
-the operation state of the port. Except state 0 (disabled),
+the operation state of the port. Except state 0 (disable STP),
 this is primarily used by user space STP/RSTP
-implementation. One may enter a lowercased port state name, or one of the
+implementation. One may enter port state name (case insensitive), or one of the
 numbers below. Negative inputs are ignored, and unrecognized names return an
 error.
 
 .B 0
-- port is in
+- port is in STP
 .B DISABLED
-state. Make this port completely inactive. This is also called
+state. Make this port completely inactive for STP. This is also called
 BPDU filter and could be used to disable STP on an untrusted port, like
 a leaf virtual devices.
 .sp
-- 
2.25.1

From 1572dd1b6143a3a542505d62b8e0ee95961e1194 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Sun, 5 Apr 2020 01:52:26 +0200
Subject: [PATCH 1/6] Better documentation of mcast_to_unicast option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This option is useful for Wifi bridge but need some tweak.

Document it from kernel patches documentation

Signed-off-by: Bastien Roucariès 
---
 man/man8/bridge.8 | 28 
 1 file changed, 28 insertions(+)

diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index b9bd6bc..efb8458 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -383,6 +383,34 @@ there is no MDB entry. By default this flag is on.
 Controls whether a given port will replicate packets using unicast
 instead of multicast. By default this flag is off.
 
+This is done by copying the packet per host and
+changing the multicast destination MAC to a unicast one accordingly.
+
+.BR mcast_to_unicast
+works on top of the multicast snooping feature of
+the bridge. Which means unicast copies are only delivered to hosts which
+are interested in it and signalized this via IGMP/MLD reports
+previously.
+
+
+This feature is intended for interface types which have a more reliable
+and/or efficient way to deliver unicast packets than broadcast ones
+(e.g. WiFi).
+
+However, it should only be enabled on interfaces where no IGMPv2/MLDv1
+report suppression takes place. IGMP/MLD report suppression issue is usually
+overcome by the network daemon (supplicant) enabling AP isolation and
+by that separating all STAs.
+
+Delivery of STA-to-STA IP mulitcast is made possible again by
+enabling and utilizing the bridge hairpin mode, which considers the
+incoming port as a potential outgoing port, too (see
+.B hairpin
+option)
+
+Hairpin mode is performed after multicast snooping, therefore leading to
+only deliver reports to STAs running a multicast router.
+
 .TP
 .BR "neigh_suppress on " or " neigh_suppress off "
 Controls whether neigh discovery (arp and nd) proxy and suppression is
-- 
2.25.1

From a9332a9a9b3e693af028db77d27b98fd2814815c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Sun, 5 Apr 2020 02:00:45 +0200
Subject: [PATCH 2/6] Improve hairpin mode description
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Mention VEPA and reflective relay.

Signed-off-by: Bastien Roucariès 
---
 man/man8/bridge.8 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index efb8458..4dc8a63 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -332,7 +332,9 @@ cause the port to stop processing STP BPDUs.
 .TP
 .BR "hairpin on " or " hairpin off "
 Controls whether traffic

Bug#947754: gitlab 12.8.8 uses doorkeeper 5

2020-04-05 Thread Pirate Praveen

Control: fixed -1 12.8.8-1

On 2020, ഏപ്രിൽ 5 2:16:36 PM IST, Dragos Jarca  
wrote:
>I just tested with gitlab 12.8.8-5 and Mattermost Version: 5.21.0 and 
>work as expected.
>
> From my point of view, this issue can be close.

Thanks for confirming. Closing bug.

>Dragos
>
>On 04.04.2020 21:48, Pirate Praveen wrote:
>> On Fri, 28 Feb 2020 15:06:48 +0100 
>> =?UTF-8?B?RGF2aWQgTMOzcGV6IFphamFyYSAoRXJfTWFxdWkp?= 
>>  wrote:
>> > Package: gitlab
>> > Version: 12.6.7-1+fto10+1
>> >
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> >
>> > Hi,
>> >
>> > Bug is still present (and checked) on 12.6.7.
>> > I haven't done any configuration changes.
>>
>> Can you try with gitlab 12.8.8 which uses doorkeeper 5?
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#932047: lightdm: greeter session support for elogind

2020-04-05 Thread Mark Hindley

Hello,

Just a gentle nudge on this.

On Sun, 14 Jul 2019 12:59:32 +0100 Mark Hindley  wrote:
> Patches implementing both of these approaches are attached.

I would be grateful if you could adopt one or other of these so that they can be
more widely tested well in advance of the freeze.

Thanks

Mark

Bug#607008: mencal: with l10n, calendar header formatting not aligned with column content

2020-04-05 Thread Stanislav V. Vlasov

Package: mencal
Version: 3.0-4
Followup-For: Bug #607008

Dear Maintainer,

Week headers not only not aligned, but printed completely wrong with l10n in 
3.0-4:

Wide character in print at /usr/bin/mencal line 351.
апреля 2020 
Ð Ð Ð¡ Ð§ Ð 8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30  



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

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

Versions of packages mencal depends on:
ii  perl  5.28.1-6

mencal recommends no packages.

mencal suggests no packages.

-- no debconf information

Bug#947754: gitlab 12.8.8 uses doorkeeper 5

2020-04-05 Thread Dragos Jarca

I just tested with gitlab 12.8.8-5 and Mattermost Version: 5.21.0 and 
work as expected.


From my point of view, this issue can be close.

Dragos

On 04.04.2020 21:48, Pirate Praveen wrote:
On Fri, 28 Feb 2020 15:06:48 +0100 
=?UTF-8?B?RGF2aWQgTMOzcGV6IFphamFyYSAoRXJfTWFxdWkp?= 
 wrote:

> Package: gitlab
> Version: 12.6.7-1+fto10+1
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> Bug is still present (and checked) on 12.6.7.
> I haven't done any configuration changes.

Can you try with gitlab 12.8.8 which uses doorkeeper 5?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#954504: marked as done (sagemath: FTBFS: [sagelib-9.0] /<>/sage/src/bin/sage-env: line 130: cd: /doesnotexist: No such file or directory)

2020-04-05 Thread unitedcabl...@gmail.com

Stop message please

On Sun, Apr 5, 2020, 14:21 Debian Bug Tracking System 
wrote:

> Your message dated Sun, 05 Apr 2020 08:49:34 +
> with message-id 
> and subject line Bug#954504: fixed in sagemath 9.0-3
> has caused the Debian Bug report #954504,
> regarding sagemath: FTBFS: [sagelib-9.0]
> /<>/sage/src/bin/sage-env: line 130: cd: /doesnotexist: No
> such file or directory
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 954504: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954504
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Lucas Nussbaum 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 22 Mar 2020 09:28:39 +0100
> Subject: sagemath: FTBFS: [sagelib-9.0]
> /<>/sage/src/bin/sage-env: line 130: cd: /doesnotexist: No
> such file or directory
> Source: sagemath
> Version: 9.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200321 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[5]: Entering directory '/<>/sage/build/make'
> > if [ -z "$SAGE_INSTALL_FETCH_ONLY" ]; then \
> >   cd /<>/sage/src && source bin/sage-env && \
> >   sage-logger -p 'time make -j4 sage'
> '/<>/sage/logs/pkgs/sagelib-9.0.log'; \
> > fi
> > [sagelib-9.0] make[6]: Entering directory '/<>/sage/src'
> > [sagelib-9.0] make[6]: warning: -j4 forced in submake: resetting
> jobserver mode.
> > [sagelib-9.0] cd . && export\
> > [sagelib-9.0] SAGE_ROOT=/doesnotexist   \
> > [sagelib-9.0] SAGE_SRC=/doesnotexist\
> > [sagelib-9.0] SAGE_SRC_ROOT=/doesnotexist   \
> > [sagelib-9.0] SAGE_DOC_SRC=/doesnotexist\
> > [sagelib-9.0] SAGE_BUILD_DIR=/doesnotexist  \
> > [sagelib-9.0] SAGE_PKGS=/<>/sage/build/pkgs
> \
> > [sagelib-9.0] && sage-python -u setup.py --no-user-cfg build install
> --root ../../debian/build --install-layout deb -O2
> > [sagelib-9.0] /<>/sage/src/bin/sage-env: line 130: cd:
> /doesnotexist: No such file or directory
> > [sagelib-9.0] Warning: overwriting SAGE_ROOT environment variable:
> > [sagelib-9.0] Old SAGE_ROOT=/doesnotexist
> > [sagelib-9.0] New SAGE_ROOT=
> > [sagelib-9.0] Discovering Python/Cython source code
> > [sagelib-9.0] Discovered Python/Cython sources, time: 0.01 seconds.
> > [sagelib-9.0] running build
> > [sagelib-9.0] Generating auto-generated sources
> > [sagelib-9.0] Building interpreters for fast_callable
> > [sagelib-9.0] running build_cython
> > [sagelib-9.0] Enabling Cython debugging support
> > [sagelib-9.0] Updating Cython code
> > [sagelib-9.0] Finished Cythonizing, time: 1.51 seconds.
> > [sagelib-9.0] running build_py
> > [sagelib-9.0] running build_ext
> > [sagelib-9.0] Executing 0 commands (using 1 thread)
> > [sagelib-9.0] Time to execute 0 commands: 0.01 seconds.
> > [sagelib-9.0] Total time spent compiling C/C++ extensions: 0.04 seconds.
> > [sagelib-9.0] running install
> > [sagelib-9.0] running install_lib
> > [sagelib-9.0] writing byte-compilation script '/tmp/tmpsgo_pj_o.py'
> > [sagelib-9.0] /usr/bin/python3 /tmp/tmpsgo_pj_o.py
> > [sagelib-9.0] removing /tmp/tmpsgo_pj_o.py
> > [sagelib-9.0] running install_egg_info
> > [sagelib-9.0] Removing
> ../../debian/build/usr/lib/python3/dist-packages/sage-9.0.egg-info
> > [sagelib-9.0] Writing
> ../../debian/build/usr/lib/python3/dist-packages/sage-9.0.egg-info
> > [sagelib-9.0] Cleaning up stale installed files
> > [sagelib-9.0] - cleaning ../../debian/build/usr/lib/python3/dist-packages
> > [sagelib-9.0] - cleaning build/lib.linux-x86_64-3.8
> > [sagelib-9.0] Finished cleaning, time: 0.14 seconds.
> > [sagelib-9.0] if [ "$UNAME" = "CYGWIN" ]; then \
> > [sagelib-9.0] sage-rebase.sh "$SAGE_LOCAL" 2>/dev/null;\
> > [sagelib-9.0] fi
> > [sagelib-9.0] make[6]: Leaving directory '/<>/sage/src'
> > [sagelib-9.0]
> > [sagelib-9.0] real0m3.468s
> > [sagelib-9.0] user0m2.879s
> > [sagelib-9.0] sys 0m0.427s
> > cd ../.. && sage-logger -p './sage --docbuild --no-pdf-links all html '
> logs/dochtml.log
> > [dochtml]
> > [dochtml] Building reference manual, first pass.
> > [dochtml]
> > [dochtml] Setting permissions of DOT_SAGE directory so only you can read
> and write it.
> > [dochtml] [reference] building [inventory]: targets for 1 source

Bug#950147: marked as done (sagemath ftbfs with python 3.8)

2020-04-05 Thread unitedcabl...@gmail.com

Stop message please

On Sun, Apr 5, 2020, 14:21 Debian Bug Tracking System 
wrote:

> Your message dated Sun, 05 Apr 2020 08:49:34 +
> with message-id 
> and subject line Bug#950147: fixed in sagemath 9.0-3
> has caused the Debian Bug report #950147,
> regarding sagemath ftbfs with python 3.8
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 950147: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950147
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Matthias Klose 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 29 Jan 2020 15:07:37 +0100
> Subject: sagemath ftbfs with python 3.8
> Package: src:sagemath
> Version: 9.0-1
> Severity: important
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.8
>
> sagemath ftbfs with python 3.8.  Not sure if you already can check that in
> Debian, however in Ubuntu, there seem to be a lot of failing tests, plus
> the
> tests failing because of too many open files (googling about that, I found
> some
> hints, but just for MacOSX).
>
> Build logs at
> https://launchpad.net/ubuntu/+source/sagemath/9.0-1build1
>
> Any help would be appreciated.
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 950147-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 05 Apr 2020 08:49:34 +
> Subject: Bug#950147: fixed in sagemath 9.0-3
> Source: sagemath
> Source-Version: 9.0-3
> Done: Tobias Hansen 
>
> We believe that the bug you reported is fixed in the latest version of
> sagemath, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 950...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Tobias Hansen  (supplier of updated sagemath package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Sat, 04 Apr 2020 20:48:51 +0200
> Source: sagemath
> Architecture: source
> Version: 9.0-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Science Team <
> debian-science-maintain...@lists.alioth.debian.org>
> Changed-By: Tobias Hansen 
> Closes: 950147 954504
> Changes:
>  sagemath (9.0-3) unstable; urgency=medium
>  .
>[ Julien Puydt ]
>* Mark the -doc-en package M-A: foreign following hinter.
>  .
>[ Tobias Hansen ]
>* New (Build-)Depends:
>  - pari (>= 2.11.4~pre1)
>  - gap-atlasrep (>= 2.1.0-2)
>  - libec-dev (>= 20190909-3)
>* Remove (Build-)Depends:
>  - python3-openid   #29320
>  - python3-twisted  #29320
>* New patches:
>  - u0-version-python-3.8.patch (Closes: #950147)
>  - u0-version-pari-2.11.3.patch   #29313
>  - u0-version-sympy-1.5.patch #28911
>  - u2-version-matplotlib-3.2.1.patch (Closes: #954504)
> Checksums-Sha1:
>  1c020edec056274d4825aa8036e38037eead363c 5865 sagemath_9.0-3.dsc
>  2fb30dc5e5b9391c139b6556239271ea2315484d 114420
> sagemath_9.0-3.debian.tar.xz
>  d8dc73861a6a5149eb934c5a75f96d4f737e3087 22267
> sagemath_9.0-3_source.buildinfo
> Checksums-Sha256:
>  28d9ec9a7b9f0b4c0e21ce24c1efdb99f8fbeb783dd9279720a6535b5d7f2c4c 5865
> sagemath_9.0-3.dsc
>  269932530a25cf8232ee5730e7b835693833063a9ea7ca507994872929c7101a 114420
> sagemath_9.0-3.debian.tar.xz
>  6a8cacb37a11575b990d269c62826b74068531a76b3c6a06b946f88bf1178433 22267
> sagemath_9.0-3_source.buildinfo
> Files:
>  fdd3f318a919e41bb7efe048a9044fee 5865 math optional sagemath_9.0-3.dsc
>  66339346caf610ee31cec215795392b3 114420 math optional
> sagemath_9.0-3.debian.tar.xz
>  c164c6d4afec68029dee358f40c45866 22267 math optional
> sagemath_9.0-3_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEoH46ol3M2u2mYo0kjIIWnY7OzSoFAl6JlZYACgkQjIIWnY7O
> zSqp+Q//TPMtUWFiI2R6uxrDj/Jxee0zx2N9hGYdtr9CMzIVf6jH+adWCdvl5U63
> PWIcJYIZF0sKLKTxwmj3nJwJ6JD0cw6VliPeeIn3FjTptttvpiVwsPy11YfPV+Ez
> MbPqCwPZNICHo0Qkw4SdzrFQP2jNt/8jcERvV8N/cWx1DboS5AvUr4GSh9llc3Z4
> +fm2wV6BwT6KlE/21K6RPVCt6/uybgfoP+k3pxxybi11Sk6OaeN8TlxVdP/GqfAO
> CsaIWQHOWcneaWQO2ThvCR+l+iCgpi8/Rs1OVrnHW7nCTwPLSeRZQePimdXPJ3Dw
>

Bug#955652: dvdbackup: FTBFS: dvdbackup.c:1282:29: error: ‘ifo_handle_t’ {aka ‘struct ’} has no member named ‘file’

2020-04-05 Thread Sebastian Ramacher

Control: forwarded -1 https://bugs.launchpad.net/dvdbackup/+bug/1869226

On 2020-04-03 21:37:15 +0200, Lucas Nussbaum wrote:
> Source: dvdbackup
> Version: 0.4.2-4
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
> > -DLOCALEDIR=\"/usr/share/locale\" -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -pedantic -Wall -Wextra  -c -o dvdbackup.o 
> > dvdbackup.c
> > dvdbackup.c: In function ‘DVDWriteCells’:
> > dvdbackup.c:172:22: warning: unused parameter ‘title_set_info’ 
> > [-Wunused-parameter]
> >   172 |   title_set_info_t * title_set_info, titles_info_t * titles_info,
> >   |   ~~~^~
> > dvdbackup.c: In function ‘DVDCopyIfoBup’:
> > dvdbackup.c:1282:29: error: ‘ifo_handle_t’ {aka ‘struct ’} has 
> > no member named ‘file’
> >  1282 |  size = DVDFileSize(ifo_file->file) * DVD_VIDEO_LB_LEN;
> >   | ^~
> > dvdbackup.c:1295:22: error: ‘ifo_handle_t’ {aka ‘struct ’} has 
> > no member named ‘file’
> >  1295 |  DVDFileSeek(ifo_file->file, 0);
> >   |  ^~
> > dvdbackup.c:1297:27: error: ‘ifo_handle_t’ {aka ‘struct ’} has 
> > no member named ‘file’
> >  1297 |  if (DVDReadBytes(ifo_file->file,buffer,size) != size) {
> >   |   ^~
> > make[3]: *** [Makefile:392: dvdbackup.o] Error 1

A patch is available at
https://bugs.launchpad.net/dvdbackup/+bug/1869226

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#952332: kxd: diff for NMU version 0.14-1.1

2020-04-05 Thread Maximiliano Curia


On 2020-04-05 06:38, Håvard Flaget Aasen wrote:

Control: tags 952332 + patch
Control: tags 952332 + pending

Dear maintainer,

I've prepared an NMU for kxd (versioned as 0.14-1.1) and
uploaded it to mentors. Please feel free to tell me if I
should remove it.


Thanks, could you prepare a merge request against
https://salsa.debian.org/debian/kxd ?

Thanks,
--
Saludos /\/\ /\ >< `/


signature.asc
Description: OpenPGP digital signature

Bug#955815: intel-opencl-clang: requires a source-only upload

2020-04-05 Thread Sebastian Ramacher

Source: intel-opencl-clang
Version: 9.0.0-1
Severity: serious

intel-opencl-clang currently cannot migrate:

Not built on buildd: arch all binaries uploaded by tjaal...@ubuntu.com, a new 
source-only upload is needed to allow migration
Not built on buildd: arch amd64 binaries uploaded by tjaal...@ubuntu.com

Since this is includes an Arch: all binary package, a binNMU won't help
in this case. Please perform an source-only upload to fix this issue.

I also wonder why libopencl-clang-dev is an Arch: all binary in the
first place. It contains an architecture specific interface -- the
symlink to the shared library provided by libopencl-clang9.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955814: ITP: r-cran-km.ci -- GNU R confidence intervals for the Kaplan-Meier estimator

2020-04-05 Thread Andreas Tille

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-km.ci -- GNU R confidence intervals for the Kaplan-Meier 
estimator
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-km.ci
  Version : 0.5
  Upstream Author : Ralf Strobl 
* URL : https://cran.r-project.org/package=km.ci
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R confidence intervals for the Kaplan-Meier estimator
 Computes various confidence intervals for the Kaplan-Meier
 estimator, namely: Petos CI, Rothman CI, CI's based on
 Greenwoods variance, Thomas and Grunkemeier CI and the
 simultaneous confidence bands by Nair and Hall and Wellner.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-km.ci

Bug#955775: ipython3: entry_points not working with virtualenvwrapper

2020-04-05 Thread Magnus Nord

Investigating this a bit further, changing the shebang in 
/usr/bin/ipython3 from "#!/usr/bin/python3" to "#!/usr/bin/env python" 
solves the issue. But I guess this is in conflict with Debian's policy 
on interpreter location, that says "/usr/bin/env name" should not be 
used: 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc


Replacing /usr/bin/ipython3 with Fedora's ipython3 initialization script:

#!/usr/bin/python3
# This script was automatically generated by setup.py
if __name__ == '__main__':
    from IPython import start_ipython
    start_ipython()

Fixes the issue, although I'm not certain what other consequences this has.

Bug#888988: reportbug: Retrieved base64 messages aren't decoded

2020-04-05 Thread Nis Martensen

On 14 Feb 2019:
> control: tags -1 unreproducible moreinfo
> 
> On 2 Feb 2017 Scott Leggett wrote:
> > The same thing occurs when saving a bug report to disk if the bug report
> > contains a non-ascii character - it is saved as base64 and then is
> > rejected by the bug tracking system if you try to send it later because
> > the first line doesn't begin with "Package: ".
> 
> A small test[1] shows that the BTS is able to deal with base64-encoded
> mail just fine. So there is probably no bug here, unless we can still
> find one -
> 
> Do you have more information on mails generated by reportbug that were
> rejected by the BTS? What method do you use to "send later" reports
> saved by reportbug?
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868155#17

Ping?
If there is no more information, then I think we can close this bug.

Bug#785228: reportbug: Reportbug crashes after selecting gtk in terminal

2020-04-05 Thread Nis Martensen

On Wed, 13 May 2015 13:26:49 -0400 Sandro Tosi  wrote:
> On Wed, May 13, 2015 at 1:15 PM, Henriquew  wrote:
> > Package: reportbug
> > Version: 6.6.3
> > Severity: normal
> 
> empty bug reports are not very useful... would you mind reporting the
> exact, unaltered, traceback you get on the terminal when the crash
> happens?

This bug has been waiting for more information since nearly 5 years now.
Reportbug has seen quite a lot of changes in the meantime. Time to close
this bug?

Bug#955813: ITP: r-cran-exactranktests -- GNU R exact distributions for rank and permutation tests

2020-04-05 Thread Andreas Tille

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-exactranktests -- GNU R exact distributions for rank and 
permutation tests
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-exactranktests
  Version : 0.8
  Upstream Author : Torsten Hothorn,
* URL : https://cran.r-project.org/package=exactRankTests
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R exact distributions for rank and permutation tests
 This GNU R package provides functions to compute exact conditional
 p-values and quantiles using an implementation of the Shift-Algorithm
 by Streitberg & Roehmel.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-exactranktests

Bug#916564: python-pyte: new upstream version: 0.8.0

2020-04-05 Thread Andrej Shadura

Hi,

On Sat, 4 Apr 2020 at 23:39, Guilhem Moulin  wrote:
> On Tue, 1 Oct 2019 at 16:21:54 +0200, Andrej Shadura wrote
> > Control: tag -1 pending
>
> Anything still blocking for 0.8.0-1? :-)
>
> > Why? 0.4.8 should be good enough for anyone for a few years more :)
>
> FWIW termtosvg, which I just ITP'ed, needs pyte.graphics.FG_BG_256 which
> was added in 0.6.0 :-P

Ha, my joke probably came across not very well :D I intended to upload
a newer version back in October, but something happened and I never
did.

-- 
Cheers,
  Andrej

Bug#919285: reportbug can't handle onion addresses.

2020-04-05 Thread Nis Martensen

control: affects -1 - apt-transport-tor

> > Reportbug can't handle onion addresses. Thus when sources.list only
> > contains onion addresses reportbug thinks it is empty.
> > 
> > $ reportbug
> > E: You must put some 'source' URIs in your sources.list
> 
> The error message comes from "apt-cache showsrc " (which is called
> from reportbug) and is trying to tell you that you have no deb-src
> entries in your sources.list.

Since apt 2.0 the error message now says 'deb-src' instead of 'source'
to make this clearer.

I think there is no bug in reportbug here.

Bug#955811: [pgbackrest] Binary moved from /usr/bin to /bin

2020-04-05 Thread bugs-debian

Package: pgbackrest
Version: 2.25-2
Severity: normal

--- Please enter the report below this line. ---

Hi,

>From 2.14-1 to 2.25-2, the main binary moved from /usr/bin to /bin. I
know that we should have merged /usr but it should either be mentioned
in the changelog, or revert the change.

For now, I'll change my cron jobs.

Adrien


--- System information. ---
Architecture:
Kernel: Linux 5.4.0-4-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

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

2020-04-05 Thread Matthias Brennwald

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#955808: RFS: kxd/0.14-1.1 [NMU, RC] -- Key exchange daemon

2020-04-05 Thread Håvard Flaget Aasen

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: kxd
   Version : 0.14-1.1
   Upstream Author :
 * URL : https://blitiri.com.ar/p/kxd
 * License : Expat
 * Vcs : https://salsa.debian.org/debian/kxd
   Section : net

It builds those binary packages:

  kxc - Key exchange daemon -- client
  kxd - Key exchange daemon

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/k/kxd/kxd_0.14-1.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Set absolute path in d/rules closes: #952332
   * Cherry-pick upstream commit, needed for upstream testsuite.
 0001-tests-Add-missing-conn.getresponse-which-was-causing.patch

Regards,
Håvard

Bug#955810: ITP: upb -- small protobuf implementation in C

2020-04-05 Thread GCS

Package: wnpp
Severity: wishlist

* Package name: upb
  Version : 0.0.0 (git)
  Upstream Author : Google Inc.
* URL : https://github.com/protocolbuffers/upb/wiki
* License : BSD-3-Clause
  Programming Lang: C
  Description : small protobuf implementation written in C

upb generates a C API for creating, parsing, and serializing messages as
declared in .proto files. upb is heavily arena-based: all messages always live
in an arena (note: the arena can live in stack or static memory if desired).

Bug#955281: libwebsockets: allow to compile again on !linux archs

2020-04-05 Thread Pino Toscano

In data domenica 29 marzo 2020 18:37:40 CEST, László Böszörményi (GCS) ha 
scritto:
> On Sun, Mar 29, 2020 at 1:00 PM Pino Toscano  wrote:
> > starting from 2.4.2-1, libwebsockets cannot be built on non-Linux
> > architectures due to the unconditional libcap-dev build dependency.
> > Considering that libcap is Linux-specific, it is possible to restrict
> > its usage only on Linux architectures.
>  Indeed, my bad. Will change that dependency to Linux only. However as
> I see, the missing of cmake (at least on kFreeBSD architectures) are a
> bigger problem. Making many packages unbuildable and not just
> libwebsockets. You work only with Hurd, right? Do you know if any work
> done on cmake and its dependencies for kFreeBSD?

Unfortunately I cannot say much about kFreeBSD sorry; I can tell you
that libwebsockets built fine on the Hurd with the libcap requirement
removed.

-- 
Pino Toscano

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

Bug#955790: libproj-dev: please don't ship .la files

2020-04-05 Thread Pino Toscano

In data domenica 5 aprile 2020 06:56:49 CEST, Sebastiaan Couwenberg ha scritto:
> On 4/4/20 11:54 PM, Pino Toscano wrote:
> > as per Policy §10.2, .la files should not be included in the Debian 
> > package.  Patch attached for this.
> 
> dependency_libs is already set to an empty string.

Note that this bug is about getting rid of the .la file, not about
emptying dependency_libs. src:proj has often SONAME bumps, so if you
remove the .la file at the next one there will be no problem, since
reverse dependencies of libproj will be rebuilt anyway.

Note that in general there is little reason to ship .la files,
especially in cases like this when there is no libltdl (and plugins
based on it) used.

-- 
Pino Toscano

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

Bug#886679: Bug#937400: pycaml: Python2 removal in sid/bullseye

2020-04-05 Thread Stéphane Glondu

Le 04/04/2020 à 20:21, Moritz Mühlenhoff a écrit :
>>> pycaml is deprecated in favour of pyml (in NEW). The only reverse
>>> dependency, coccinelle, is supposed to switch to pyml. Once it's done,
>>> we can remove pycaml.
>>
>> pyml is now in testing.
>>
>> Emmanuel Arias (in CC) has shown interest in adopting coccinelle (#886679).
>>
>> Emmanuel, what is the status of packaging a new version of coccinelle?
> 
> A new version of coccinelle has been uploaded, so let's remove pycaml now?

I see no objection.


Cheers,

-- 
Stéphane

Bug#950654: node-eslint-plugin-html seems unusable without eslint

2020-04-05 Thread Xavier Guimard

Package: node-eslint-plugin-html
Version: 3.2.1-3
Followup-For: Bug #950654

Hi,

in previous upload, eslint was moved from binary dependency to
"Enhances". This breaks autopkgtest. Please revert that change.

Bug#955809: reportbug: Patch to add 'ftbfs' tag.

2020-04-05 Thread Bas Couwenberg

Source: reportbug
Version: 7.6.0
Severity: normal
Tags: patch

Dear Maintainer,

The attached patch adds the 'ftbfs' tag to make `-T ftbfs` work.

Kind Regards,

Bas
diff -Nru reportbug-7.6.0/debian/changelog reportbug-7.6.0+nmu1/debian/changelog
--- reportbug-7.6.0/debian/changelog2019-12-14 19:18:07.0 +0100
+++ reportbug-7.6.0+nmu1/debian/changelog   2020-04-05 09:22:43.0 
+0200
@@ -1,3 +1,10 @@
+reportbug (7.6.0+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 'ftbfs' tag.
+
+ -- Bas Couwenberg   Sun, 05 Apr 2020 09:22:43 +0200
+
 reportbug (7.6.0) unstable; urgency=medium
 
   [ Bastian Venthur ]
diff -Nru reportbug-7.6.0/reportbug/debbugs.py 
reportbug-7.6.0+nmu1/reportbug/debbugs.py
--- reportbug-7.6.0/reportbug/debbugs.py2019-12-14 19:18:07.0 
+0100
+++ reportbug-7.6.0+nmu1/reportbug/debbugs.py   2020-04-05 09:22:38.0 
+0200
@@ -846,6 +846,7 @@
 'l10n': 'This bug reports a localization/internationalization issue.',
 'a11y': 'This bug is relevant to the accessibility of the package.',
 'newcomer': 'This bug has a known solution but the maintainer requests 
someone else implement it.',
+'ftbfs': 'The package fails to build from source.',
 }

< 1 2 3 >

101 - 200 of 206 matches

Mail list logo