Bug#963746: Fw: [PATCH v2] Re: Strange segmentation violations of rpc.gssd in Debian Buster

2020-06-28 Thread Kraus, Sebastian
Testing upstream patch by Doug Nazar:
Manually patching gssd.c, gssd_proc.c and gssd.h wihtin nfs-utils_1.3.4 source.
Rebuilding binary package nfs-common-1.3.4-2.5 from nfs-utils_1.3.4 source.
Testing altered binary packages nfs-common_1.3.4-2.5_amd64.deb and 
nfs-common-dbgsym_1.3.4-2.5_amd64.deb on one machine.

ToDo:
Correctly backporting Nazar's patch to nfs-utils_1.3.4 source of Debian Stable 
and Oldstable.
Roll-out to all NFS file servers.


Jump into nightmare's heaven oUt
Sebastian


Sebastian Kraus
Team IT am Institut für Chemie
Gebäude C, Straße des 17. Juni 115, Raum C7

Technische Universität Berlin
Fakultät II
Institut für Chemie
Sekretariat C3
Straße des 17. Juni 135
10623 Berlin

Email: sebastian.kr...@tu-berlin.de


From: linux-nfs-ow...@vger.kernel.org  on 
behalf of Doug Nazar 
Sent: Friday, June 26, 2020 23:30
To: J. Bruce Fields
Cc: Kraus, Sebastian; linux-...@vger.kernel.org; Steve Dickson; Olga 
Kornievskaia
Subject: [PATCH v2] Re: Strange segmentation violations of rpc.gssd in Debian 
Buster

On 2020-06-26 17:02, J. Bruce Fields wrote:
> Unless I'm missing something--an upcall thread could still be using this
> file descriptor.
>
> If we're particularly unlucky, we could do a new open in a moment and
> reuse this file descriptor number, and then then writes in do_downcall()
> could end up going to some other random file.
>
> I think we want these closes done by gssd_free_client() in the !refcnt
> case?

Makes sense. I was thinking more that it was an abort situation and we
shouldn't be sending any data to the kernel but re-use is definitely a
concern.

I've split it so that we are removed from the event loop in destroy()
but the close happens in free().

DougFrom 8ef49081e8a42bfa05bb63265cd4f951e2b23413 Mon Sep 17 00:00:00 2001
From: Doug Nazar 
Date: Fri, 26 Jun 2020 16:02:04 -0400
Subject: [PATCH] gssd: Refcount struct clnt_info to protect multithread usage

Struct clnt_info is shared with the various upcall threads so
we need to ensure that it stays around even if the client dir
gets removed.

Reported-by: Sebastian Kraus 
Signed-off-by: Doug Nazar 
---
 utils/gssd/gssd.c  | 67 --
 utils/gssd/gssd.h  |  5 ++--
 utils/gssd/gssd_proc.c |  4 +--
 3 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index 588da0fb..b40c3220 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -90,9 +90,7 @@ char *ccachedir = NULL;
 /* Avoid DNS reverse lookups on server names */
 static bool avoid_dns = true;
 static bool use_gssproxy = false;
-int thread_started = false;
-pthread_mutex_t pmutex = PTHREAD_MUTEX_INITIALIZER;
-pthread_cond_t pcond = PTHREAD_COND_INITIALIZER;
+pthread_mutex_t clp_lock = PTHREAD_MUTEX_INITIALIZER;
 
 TAILQ_HEAD(topdir_list_head, topdir) topdir_list;
 
@@ -359,20 +357,28 @@ out:
free(port);
 }
 
+/* Actually frees clp and fields that might be used from other
+ * threads if was last reference.
+ */
 static void
-gssd_destroy_client(struct clnt_info *clp)
+gssd_free_client(struct clnt_info *clp)
 {
-   if (clp->krb5_fd >= 0) {
+   int refcnt;
+
+   pthread_mutex_lock(_lock);
+   refcnt = --clp->refcount;
+   pthread_mutex_unlock(_lock);
+   if (refcnt > 0)
+   return;
+
+   printerr(3, "freeing client %s\n", clp->relpath);
+
+   if (clp->krb5_fd >= 0)
close(clp->krb5_fd);
-   event_del(>krb5_ev);
-   }
 
-   if (clp->gssd_fd >= 0) {
+   if (clp->gssd_fd >= 0)
close(clp->gssd_fd);
-   event_del(>gssd_ev);
-   }
 
-   inotify_rm_watch(inotify_fd, clp->wd);
free(clp->relpath);
free(clp->servicename);
free(clp->servername);
@@ -380,6 +386,24 @@ gssd_destroy_client(struct clnt_info *clp)
free(clp);
 }
 
+/* Called when removing from clnt_list to tear down event handling.
+ * Will then free clp if was last reference.
+ */
+static void
+gssd_destroy_client(struct clnt_info *clp)
+{
+   printerr(3, "destroying client %s\n", clp->relpath);
+
+   if (clp->krb5_fd >= 0)
+   event_del(>krb5_ev);
+
+   if (clp->gssd_fd >= 0)
+   event_del(>gssd_ev);
+
+   inotify_rm_watch(inotify_fd, clp->wd);
+   gssd_free_client(clp);
+}
+
 static void gssd_scan(void);
 
 static int
@@ -416,11 +440,21 @@ static struct clnt_upcall_info *alloc_upcall_info(struct 
clnt_info *clp)
info = malloc(sizeof(struct clnt_upcall_info));
if (info == NULL)
return NULL;
+
+   pthread_mutex_lock(_lock);
+   clp->refcount++;
+   pthread_mutex_unlock(_lock);
info->clp = clp;
 
return info;
 }
 
+void free_upcall_info(struct clnt_upcall_info *info)
+{
+   gssd_free_client(info->clp);
+   free(info);
+}
+
 /* For each upcall read the upcall info into the buffer, then create a
  * thread in 

Bug#963949: aptitude: "search aborted by fatal exception" during upgrade

2020-06-28 Thread Robbie Harwood
Package: aptitude
Version: 0.8.13-1+b1
Severity: normal

Dear Maintainer,

```
frozencemetery@kirtar:~$ sudo aptitude full-upgrade
The following NEW packages will be installed:
  libmfx1{a} libpocketsphinx3{a} librabbitmq4{a} libsphinxbase3{a} 
libsrt1-gnutls{a} 
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5 
10 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives. After unpacking 26.2 MB will be used.
The following packages have unmet dependencies:
 chromium : Conflicts: libavcodec58 (= 7:4.3-2) but it is not going to be 
installed
*** ERROR: search aborted by fatal exception.  You may continue
   searching, but some solutions will be unreachable.

I want to resolve dependencies, but no dependency resolver was created.The 
following NEW packages will be installed:
  libmfx1{a} libpocketsphinx3{a} librabbitmq4{a} libsphinxbase3{a} 
libsrt1-gnutls{a} 
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5 
10 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives. After unpacking 26.2 MB will be used.
aptitude failed to find a solution to these dependencies.  You can solve them 
yourself by hand or type 'n' to quit.
The following packages have unmet dependencies:
 chromium : Conflicts: libavcodec58 (= 7:4.3-2) but it is not going to be 
installed
Resolve these dependencies by hand? [N/+/-/_/:/?] ^C
frozencemetery@kirtar:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  chromium
The following NEW packages will be installed:
  libmfx1 libpocketsphinx3 librabbitmq4 libsphinxbase3 libsrt1-gnutls
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5
10 upgraded, 5 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives.
After this operation, 153 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
frozencemetery@kirtar:~$ 
```

Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963035 , right now
we're in a state where chromium has

Conflicts: libavcodec58 (= 7:4.3-1), libavcodec58 (= 7:4.3-2)

however, 7:4.3-2 is the only available version of libavcodec58.  I assume this
is why aptitude bails out here.  There isn't a fix, so it's understandable
that it can't come up with one, but "fatal exception" isn't usually the way I
expect that to be presented :)

Thanks,
--Robbie

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 9.3.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20200212
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd98be4000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f0aef302000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f0aef2c7000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f0aef298000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f0aef28f000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f0aef189000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f0aef05f000)
libboost_iostreams.so.1.71.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0 (0x7f0aef036000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f0aeee1c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f0aeedfb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f0aeec2e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0aeeae9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f0aeeacf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0aee90a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f0aee8f2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0aee8d5000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f0aee8c2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0aee899000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f0aee877000)
libzstd.so.1 => 

Bug#963865: kodi: circular dependency hell

2020-06-28 Thread Vasyl Gello
Dear colleagues,

I checked out the dependency issue and pushed the commit removing "kodi-bin" 
from dependency lists of kodi-{x11,gbm,wayland} to the team's kodi repository. 
I believe that kodi-x11's dependency was added by Balint to have minimally 
launchable configuration if kodi-x11 is installed alone using

apt install kodi-x11

However, this will not work anyway because kodi-data will not be installed and 
Kodi profile directory will not be populated.

I was also thinking to reorder the build dependency graph as follows:

kodi -> kodi-gbm -> kodi-bin
   -> kodi-data
 -> or kodi-wayland -> kodi-bin
   -> kodi-data
 -> or kodi-x11 -> kodi-bin
   -> kodi-data

but I see no practical benefit encouraging users to install and remove kodi in 
the way other than:

apt install kodi
apt --purge autoremove kodi

Cheers!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#963948: failed to start with status=11/SEGV

2020-06-28 Thread Ernesto Domato
Package: firewalld
Version: 0.8.2-1
Severity: important

Hi,

After upgrading from 0.8.2-1 to 0.8.2-2, firewalld doesn't work anymore and
systemd status command says:

● firewalld.service - firewalld - dynamic firewall daemon
 Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor
preset: enabled)
 Active: failed (Result: signal) since Sun 2020-06-28 22:42:27 -03; 1h 7min
ago
   Docs: man:firewalld(1)
Process: 7218 ExecStart=/usr/sbin/firewalld --nofork --nopid (code=killed,
signal=SEGV)
   Main PID: 7218 (code=killed, signal=SEGV)

jun 28 22:42:26 linux systemd[1]: Starting firewalld - dynamic firewall
daemon...
jun 28 22:42:27 linux systemd[1]: Started firewalld - dynamic firewall daemon.
jun 28 22:42:27 linux systemd[1]: firewalld.service: Main process exited,
code=killed, status=11/SEGV
jun 28 22:42:27 linux systemd[1]: firewalld.service: Failed with result
'signal'.

Downgrading to 0.8.2-1 solved the problem.

Let me know anything else that I can do to help with the problem :-)

Greets.
Ernesto



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

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

Versions of packages firewalld depends on:
ii  dbus 1.12.18-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-nm-1.01.24.2-1
ii  init-system-helpers  1.57
ii  iptables 1.8.5-2
ii  policykit-1  0.105-26
ii  python3  3.8.2-3
ii  python3-dbus 1.2.16-2
hi  python3-firewall 0.8.2-1
ii  python3-gi   3.36.0-3
ii  python3-nftables 0.9.6-1

Versions of packages firewalld recommends:
ii  ipset  7.6-2

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permiso denegado: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permiso denegado: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information


Bug#963946: ITP: libpath-dispatcher-perl -- flexible and extensible dispatcher module

2020-06-28 Thread Andrew Ruthven
Package: wnpp
Severity: wishlist
Owner: Andrew Ruthven 

* Package name: libpath-dispatcher-perl
  Version : 1.07
  Upstream Author : Shawn M Moore 
* URL : https://metacpan.org/pod/Path::Dispatcher
* License : GPL v1+ or Artistic License
  Programming Lang: Perl
  Description : flexible and extensible dispatcher module

 Path::Dispatcher is a Perl module that allows a program to determine which
 code to execute by matching a path against a list of rules. Dispatch takes
 a path and returns a list of matches; from there, you can "run" the rules
 that matched. Developers may also inspect which rules were matched without
 executing their codeblocks.

This package is a dependency on the upcoming Request Tracker 5 release.
It has been in Debian in the past but was removed for Buster due to a
dependency on a deprecated package[0]. Path::Dispatcher has since
been updated to remove that dependency.

The Debian Perl Group will maintain this package. Updated packaging for
Debian is here:
https://salsa.debian.org/perl-team/modules/packages/libpath-dispatcher-perl

Cheers,
Andrew

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



Bug#963947: gcc-10-cross-mipsen: FTBFS: empty variable name

2020-06-28 Thread Niko Tyni
Source: gcc-10-cross-mipsen
Version: 2+c1
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

  Command: dpkg-buildpackage -us -uc -b -rfakeroot
  dpkg-buildpackage: info: source package gcc-10-cross-mipsen
  dpkg-buildpackage: info: source version 2+c1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by YunQiang Su 
   dpkg-source --before-build .
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  debian/rules:6: *** empty variable name.  Stop.
  dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2
 

This was presumably broken by the backward incompatible changes in
make_4.3-1.
-- 
Niko Tyni   nt...@debian.org



Bug#961141: antimony: q

2020-06-28 Thread Johannes Ranke
Package: antimony
Version: 0.9.3-1+b1
Followup-For: Bug #961141

Dear Maintainer,

The package is currently unusable in Debian stable.

I compiled my own package from the sources in unstable and was able to 
test antimony. Thanks for packaging antimony.

Johannes

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

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

Versions of packages antimony depends on:
ii  libboost-python1.67.0  1.67.0-13+deb10u1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libpng16-161.6.36-6
ii  libpython3.7   3.7.3-2+deb10u1
ii  libqt5concurrent5  5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5  5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libstdc++6 8.3.0-6
ii  python33.7.3-1
ii  zlib1g 1:1.2.11.dfsg-1

antimony recommends no packages.

antimony suggests no packages.

-- no debconf information



Bug#843835: UDD: expose an API for upstream versions to rmadison

2020-06-28 Thread Paul Wise
On Sun, 2020-06-28 at 18:17 +0200, Lucas Nussbaum wrote:

> That would be easy. What should that API look like? Would returning all
> the info for a given source package, as json, be enough?

Probably just the same API as the existing rmadison APIs. Since there
is already a udd madison script, probably just add it there with an
additional parameter. Since the ftp-master NEW madison API is in a
similar situation and uses s=new as the additional parameter, I suggest
one of s=upstream, s=uscan or s=watch as the additional parameter.

https://api.ftp-master.debian.org/madison?s=new
https://qa.debian.org/cgi-bin/madison.cgi

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#963944: libdpkg-perl: dpkg-source cannot build packages with keys anymore

2020-06-28 Thread Norbert Preining
Hi Guillem,

thanks for the quick answer.

> I think this is just git being missing in that chroot. And I see the

No, even with git it breaks the same way. But what I did is
# in the git repo
gbp buildpackage -us -uc -rfakeroot -S
# then
cowbuilder --build --buildresult . dpkg*.dsc

> If you don't want to install git there, you could workaround it with

installing git didn't help here, but that:

>   «echo -n 1.20.3 >.dist-version»

Did help.

And I can confirm that with the version from git
dpkg-source -b .
works again.

Thanks!!!

Norbert

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



Bug#963944: libdpkg-perl: dpkg-source cannot build packages with keys anymore

2020-06-28 Thread Guillem Jover
On Mon, 2020-06-29 at 10:27:51 +0900, Norbert Preining wrote:
> > I assume you have the key found in the upstream/signing-key.asc in
> > your keyring,
> 
> No, I don't have it. Is this a (new?) requirement?

No, was just a wild guess in case gpg was getting confused by seeing a
missing private key for an ultimately trusted key or something like
that.

> > perhaps that's even your private key?
> 
> No, it is upstream's.

Ok.

> > Maybe this is just
> > a bad interaction with the trustdb or something. :/  Could you try the
> > dpkg from git to see whether that fixes this problem?
> 
> Trying to build a version in a clean chroot (cowbuilder --build ...)
> I get:
> ...
> Copying file scripts/po/remove-potcdate.sin
> error: cannot get project version.
> configure.ac:21: error: AC_INIT should be called with package and version 
> arguments
> /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
> configure.ac:21: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: error: echo failed with exit status: 1
> autoreconf: aclocal failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> 
> Is this because I used the version
>   1.20.3~1
> in the changelog?

I think this is just git being missing in that chroot. And I see the
error message from get-version is not very clear, will improve that.

If you don't want to install git there, you could workaround it with
something like:

  «echo -n 1.20.3 >.dist-version»

Thanks,
Guillem



Bug#963945: Build kmsro and etnaviv on mipsel and mips64el

2020-06-28 Thread Jiaxun Yang

Source: mesa

Hi mesa maintainers,

Recently, some mipsel and mips64el hardware (e.g. Ingenic JZ4760) have been 
supported by etnaviv.
However, currently etnaviv is arm only in Debian's mesa.

Could you please build etnaviv, and it's dependency kmsro on mipsel and 
mips64el as well?

Thanks.



Bug#963944: libdpkg-perl: dpkg-source cannot build packages with keys anymore

2020-06-28 Thread Norbert Preining
Hi Guillem,

> I think this might have been fixed in git already (with the changes to

Sounds great!

> I assume you have the key found in the upstream/signing-key.asc in
> your keyring,

No, I don't have it. Is this a (new?) requirement?

> perhaps that's even your private key?

No, it is upstream's.

> Maybe this is just
> a bad interaction with the trustdb or something. :/  Could you try the
> dpkg from git to see whether that fixes this problem?

Trying to build a version in a clean chroot (cowbuilder --build ...)
I get:
...
Copying file scripts/po/remove-potcdate.sin
error: cannot get project version.
configure.ac:21: error: AC_INIT should be called with package and version 
arguments
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:21: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1

Is this because I used the version
1.20.3~1
in the changelog?

Best

Norbert

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



Bug#963944: libdpkg-perl: dpkg-source cannot build packages with keys anymore

2020-06-28 Thread Guillem Jover
Hi!

On Mon, 2020-06-29 at 09:19:18 +0900, Norbert Preining wrote:
> Package: libdpkg-perl
> Version: 1.20.2
> Severity: serious
> Justification: breaks unrelated packages

> it seems that the bump to 1.20 changed the behaviour of building
> packages, i.e., dpkg-source -b . doesn't work anymore, out of the blue,
> due to signature/key import errors:
> 
> $ dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building kig using existing ./kig_20.04.2.orig.tar.xz
> dpkg-source: info: building kig using existing ./kig_20.04.2.orig.tar.xz.asc
> gpg: public key of ultimately trusted key F3B9C351F80F635D not found
> gpg: public key of ultimately trusted key 8ABC9E07886A9BC5 not found
> gpg: public key of ultimately trusted key 6CACA448860CDC13 not found
> gpg: public key of ultimately trusted key D2BF4AA309C5B094 not found
> dpkg-source: error: failed to import key in 
> kig-20.04.2/debian/upstream/signing-key.asc
> $
> 
> This hasn't been the case before, and I am a bit at loss what needs to
> be done.

I think this might have been fixed in git already (with the changes to
use a different GNUPGHOME directory for the temporary key import), but
as I cannot reproduce your problem I'd like to be sure before I upload
the current version.

I assume you have the key found in the upstream/signing-key.asc in
your keyring, perhaps that's even your private key? Maybe this is just
a bad interaction with the trustdb or something. :/  Could you try the
dpkg from git to see whether that fixes this problem?

Thanks,
Guillem



Bug#963937: ITP: node-prosemirror-state -- implements the editor state

2020-06-28 Thread Abraham Raji
Package: wnpp
Severity: wishlist
Owner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-prosemirror-state
  Version : 1.3.3
  Upstream Author : 2015-2017 by Marijn Haverbeke  and others
* URL : https://github.com/prosemirror/prosemirror-state#readme
* License : Expat
  Programming Lang: JavaScript
  Description :  ProseMirror editor state

This module implements the editor state, which tracks the current document
and selection, and manage plugins.
.
ProseMirror is a well-behaved rich semantic content editor based on
contentEditable, with support for collaborative editing and custom document 
schemas.
.
Node.js is an event-based server-side JavaScript engine.

I intend to package this with myself but will need sponsorship. I will help the
debian-js team maintain.

---
Regards,
Abraham Raji


Bug#963659: pybind11: FTBFS with Sphinx 3.1

2020-06-28 Thread Rebecca N. Palmer
This looks like #963653, which is fixed by using python3-breathe 4.19 
from experimental.  However, doing that here gives a different error:


sphinx-build -b html -d .build/doctrees   . .build/html
Running Sphinx v3.1.1
making output directory... done
1.8.17
/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/operators.h:162: 
warning: Found ';' while parsing initializer list! (doxygen could be 
confused by a macro call without semicolon)
/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/pytypes.h:518: 
warning: Found ';' while parsing initializer list! (doxygen could be 
confused by a macro call without semicolon)
/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/detail/common.h:472: 
warning: Detected potential recursive class relation between class 
make_index_sequence_impl and base class make_index_sequence_impl< N - 1, 
N - 1, S... >!


/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/detail/common.h:472: 
warning: Detected potential recursive class relation between class 
make_index_sequence_impl and base class make_index_sequence_impl< N - 1, 
N - 1, S... >!


/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/detail/descr.h:57: 
warning: Detected potential recursive class relation between class 
int_to_str and base class int_to_str< Rem/10, Rem%10, Digits... >!


/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/detail/descr.h:57: 
warning: Detected potential recursive class relation between class 
int_to_str and base class int_to_str< Rem/10, Rem%10, Digits... >!


/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/cast.h:2164: 
warning: no uniquely matching class member found for

  template < Derived >
  template < policy, Args >
  object object_api< Derived >::call(Args &&... args) const

/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/include/pybind11/detail/common.h:588: 
warning: explicit link request to 'value' could not be resolved

building [mo]: targets for 0 po files that are out of date
building [html]: targets for 29 source files that are out of date
updating environment: [new config] 29 added, 0 changed, 0 removed
/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/docs/reference.rst:52: 
WARNING: Duplicate declaration, str : public object
/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/docs/reference.rst.rst:52: 
WARNING: C++ declarations inside functions are not supported. Parent 
function is str


Exception occurred:
  File 
"/usr/lib/python3/dist-packages/breathe/renderer/sphinxrenderer.py", 
line 425, in run_directive

rst_node = nodes[1]
IndexError: list index out of range
The full traceback has been saved in /tmp/sphinx-err-uyh7xlsd.log, if 
you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error 
message can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!

make[2]: *** [Makefile:55: html] Error 2
make[2]: Leaving directory 
'/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0/docs'

make[1]: *** [debian/rules:38: override_dh_auto_build] Error 2
make[1]: Leaving directory 
'/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0'

make: *** [debian/rules:20: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit 
status 2
test1@rnpalmer-laptop:/home/rnpalmer/Debian/builds/stackbuild/pybind11-2.5.0$ 
cat /tmp/sphinx-err-uyh7xlsd.log

# Sphinx version: 3.1.1
# Python version: 3.8.3 (CPython)
# Docutils version: 0.16 release
# Jinja2 version: 2.11.2
# Last messages:
#   reading sources... [ 65%] basics
#   reading sources... [ 68%] benchmark
#   reading sources... [ 72%] changelog
#   reading sources... [ 75%] classes
#   reading sources... [ 79%] compiling
#   reading sources... [ 82%] faq
#   reading sources... [ 86%] index
#   reading sources... [ 89%] intro
#   reading sources... [ 93%] limitations
#   reading sources... [ 96%] reference
# Loaded extensions:
#   sphinx.ext.mathjax (3.1.1) from 
/usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
#   alabaster (0.7.8) from 
/usr/lib/python3/dist-packages/alabaster/__init__.py

#   breathe (4.19.2) from /usr/lib/python3/dist-packages/breathe/__init__.py
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, 
in build_main

app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 
342, in build

self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 297, in build_update

self.build(to_build,
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 311, in build

updated_docnames = set(self.read())
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 418, in read


Bug#963653: libgpuarray: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError()

2020-06-28 Thread Rebecca N. Palmer

Control: reassign -1 src:sphinx
Control: retitle -1 sphinx breaks python3-breathe < 4.15
Control: tags -1 patch

This does not happen with breathe 4.19 (from experimental); this 
upstream report suggests it happens with breathe < 4.15.


https://github.com/sphinx-doc/sphinx/issues/7424

Hence, a fix for this is to increase the Breaks: version to 4.15
https://salsa.debian.org/python-team/modules/sphinx/-/blob/debian/master/debian/control#L67
and move python3-breathe from experimental to unstable before sphinx.



Bug#963525: Bug#963941: steam: Steam fails to start

2020-06-28 Thread Simon McVittie
Control: severity 963525 grave
Control: tag 963525 + upstream bullseye sid
Control: found 963525 1.0.0.33-1
Control: forcemerge 963525 963941

The reporter of #963941 confirmed in private email that libmount1 is at
version 2.35.2-6, so I'm merging it with the existing bug and raising
its severity in an attempt to avoid more duplicate reports.

I'm marking this as "found" in the oldest version of the steam package on
record, to indicate that it affects all versions equally (not a regression
in the steam package), and tagging it as "bullseye sid" to indicate that
it is not a practical problem in Debian 10 'buster' and older (because
they don't have the libmount1 that triggers it).

This isn't an ideal representation, but the Debian bug tracking system
is designed for tracking bugs that we might be able to fix, and we
are both legally and technically unable to fix this one without Valve
taking action (which would have to be in the form of a Steam update,
and would not necessarily involve an update to our package).

smcv



Bug#963944: libdpkg-perl: dpkg-source cannot build packages with keys anymore

2020-06-28 Thread Norbert Preining
Package: libdpkg-perl
Version: 1.20.2
Severity: serious
Justification: breaks unrelated packages

Hi,

it seems that the bump to 1.20 changed the behaviour of building
packages, i.e., dpkg-source -b . doesn't work anymore, out of the blue,
due to signature/key import errors:

$ dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building kig using existing ./kig_20.04.2.orig.tar.xz
dpkg-source: info: building kig using existing ./kig_20.04.2.orig.tar.xz.asc
gpg: public key of ultimately trusted key F3B9C351F80F635D not found
gpg: public key of ultimately trusted key 8ABC9E07886A9BC5 not found
gpg: public key of ultimately trusted key 6CACA448860CDC13 not found
gpg: public key of ultimately trusted key D2BF4AA309C5B094 not found
dpkg-source: error: failed to import key in 
kig-20.04.2/debian/upstream/signing-key.asc
$

This hasn't been the case before, and I am a bit at loss what needs to
be done.

Thanks

Norbert


-- Package-specific info:

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

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

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.20.2
ii  perl  5.30.3-4

Versions of packages libdpkg-perl recommends:
ii  bzip2   1.0.8-3
ii  libfile-fcntllock-perl  0.22-3+b6
ii  liblocale-gettext-perl  1.07-4
ii  xz-utils5.2.4-1+b1

Versions of packages libdpkg-perl suggests:
ii  binutils   2.34-8
ii  brz [bzr]  3.1.0-4
ii  clang-10 [c-compiler]  1:10.0.0-4
ii  clang-8 [c-compiler]   1:8.0.1-9
ii  clang-9 [c-compiler]   1:9.0.1-12
ii  debian-keyring 2020.06.24
ii  gcc [c-compiler]   4:9.2.1-3.1
ii  gcc-8 [c-compiler] 8.4.0-4
ii  gcc-9 [c-compiler] 9.3.0-14
ii  git1:2.27.0-1
ii  gnupg  2.2.20-1
ii  gpgv   2.2.20-1
ii  patch  2.7.6-6
ii  sensible-utils 0.0.12+nmu1

-- no debconf information



Bug#963868: linux-image-amd64: 5.7.6 crash (maybe amdgpu and temperature related)

2020-06-28 Thread Christian Göttsche
Related: https://bugzilla.kernel.org/show_bug.cgi?id=207383



Bug#963943: mupdf-tools: mutool decompression broken due to mismatched jbig2dec versions

2020-06-28 Thread Rogério Brito
Package: mupdf-tools
Version: 1.16.1+ds1-2
Severity: important

The version of mupdf in testing/unstable is partially broken (thus, only
severity important, instead of a higher severity).

This happens because mutool produces unparseable/unreadable PDF files when
used like the following, if the files contain jbig2 images:

,
| $ mutool clean -g -gg -ggg - -d -c -s test.pdf test.unc.pdf 
| warning: first object in xref is not free
| warning: jbig2dec error: incompatible jbig2dec header (0.17) and library 
(0.18) versions (segment -1)
| error: cannot allocate jbig2 globals context
| warning: dropping unclosed PDF processor
`

Please, consider:

1 - tightening the dependency of mupdf/mupdf-tools with the version of
libjbig2dec0 that it was compiled to (so as to not not allow "major" steps
like going from 0.17 to 0.18).
2 - recompiling a new version of mupdf and uploading it to the archives
ASAP.


Thanks,

Rogério Brito.

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

Kernel: Linux 5.6.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8), 
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mupdf-tools depends on:
ii  libc62.30-8
ii  libfreetype6 2.10.1-2
ii  libharfbuzz0b2.6.4-1+b1
ii  libjbig2dec0 0.18+20200417-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.1-1
ii  zlib1g   1:1.2.11.dfsg-2

mupdf-tools recommends no packages.

mupdf-tools suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br



Bug#963941: steam: Steam fails to start

2020-06-28 Thread Simon McVittie
On Sun, 28 Jun 2020 at 17:13:29 -0500, Jonathan Guthrie wrote:
> When run from the command line, it pops up a dialog for updating Steam and,
> well, I get some stuff that I don't understand.  See the attached file.  It
> looks like it generates a dump and tries to upload it, but the network
> activity fails.

Did you recently update libmount1:i386 to version 2.35.2-5 or later?

If yes, then this is probably #963525, which is a bug in the proprietary
upstream Steam binaries, triggered by extra dependencies being added
to Debian's libmount1, and cannot be fixed by the Debian steam
package. Because this is to do with the upstream Steam binaries, it
affects all versions of this package, not just 1.0.0.63-1.

Workarounds include (any one of these will probably work, choose
whichever one looks least bad to you):

- Downgrade libmount1:i386 to 2.35.2-4 and put it on apt hold for now
- Remove libglib2.0-0:i386 (this only works if you do not have packages
  that need it, such as 32-bit Wine)
- Install Steam from Flathub instead of via the steam package

> If I run with STEAM_RUNTIME=0

This is unsupported, and its probability of working successfully drops
over time as we get further away from the Steam binaries' minimal
distribution (Ubuntu 12.04). Since it's now 8 years since the release
of that base distribution, there's basically no chance of it working
(you would have to construct a special OS distribution around Steam's
expectations, which is basically what the Steam Runtime is).

smcv



Bug#963833: dh_auto_build: libglib update breaks build (GParameters)

2020-06-28 Thread Norbert Preining
severity 963833 normal
tag 963833 + moreinfo
thanks

Hi everyone,

On Sat, 27 Jun 2020, Joshua Peisach wrote:
> Justification: fails to build from source (but built successfully in the past)
> Building on: Ubuntu Focal 20.04. Also applies on unstable branch 20.10 Groovy

On Sun, 28 Jun 2020, Adrian Bunk wrote:
> 4.6.0-2 built in both Debian and Ubuntu.

On Sun, 28 Jun 2020, Joshua Peisach wrote:
> Patch is now available. Does the override_dh_auto_configure mentioned above,
> and adds the xvfb and libxml2-utils dependencies.

I cannot align the comments from Adrian with all the rest of
discussions. I can add missing B-Ds if this is actually the case, but I
don't see this problem in my clean chroot builds.
(At least the last time I checked).

And adding dh_auto_conifugure overrides doesn't seem like a good idea if
the builds are actually succeeding.

So how to proceed:
- first of all it would be nice to hear **which** version of cjs
  did **not** build on **which** version of Ubuntu, including a full
  log file/terminal output.
- Then, if this is only a problem in Ubuntu, I need some good
  explanation why we should hack around something that only breaks
  in Ubuntu.

Thanks and all the best

Norbert

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



Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892

2020-06-28 Thread Sergio Durigan Junior
On Sunday, June 28 2020, Craig Small wrote:

> On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack 
> wrote:
>
>> we are not happy yet with those commits because they change a struct
>> without bumping the soname. We are investigating how impactful that is.
>>
>
> Hi,
>   Did you see how bad these patches are with the API change?  Generally if
> the API is doing things like mystruct_new() and mystruct_free() its
> probably ok but malloc(struct mystruct) will be a problem because the
> binary will have one idea of the size and the library another. It also
> depends if they are using accessor functions to get values or directly
> pulling them out of the struct.
>
> I'm concerned that if the binary has one idea of the struct and the library
> has another we are going to get some very bad corruption going on between
> them.

Yeah, I did investigate that.  You can see some of my findings here:

  https://github.com/net-snmp/net-snmp/commit/39381c4d2#commitcomment-40180748

In an perfect world, a user would not be accessing the struct fields
directly.  However, we can never guarantee that 100%, because the whole
definition of struct used to be exported.  Upstream has changed that
recently (and introduced another API breakage, FWIW).

I think the important piece of information here is that upstream bit the
bullet and bumped the soname recently:

  
https://github.com/net-snmp/net-snmp/commit/a0932b73ea0851308ca3e797caa600192cc3508a

But we have to decide what to do with the version we're carrying on
Debian.


Arguably, it is really unlikely that a user will be using this struct in
a program.  And a quick search on sources.d.o tells us that net-snmp is
the only package in the archive that uses this struct:

  https://codesearch.debian.net/search?q=usmStateReference

So we could do like Fedora did and ignore that the ABI has been broken,
since there are no apparent packages that will be affected.  In this
case, the set of patches I backported from upstream is enough to address
the CVE.  This is probably what Ubuntu will do as well, FWIW.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature


Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup

2020-06-28 Thread Simon McVittie
On Sun, 28 Jun 2020 at 22:00:58 +0200, Chris Hofstaedtler wrote:
> the autopkgtest suite offers quite interesting behaviour:
> With an installed libcryptsetup-dev, ld fails with "cannot find
> -lcryptsetup".
...
> I imagine this might be caused by libcryptsetup-dev not shipping an
> .a library.

This means that GLib could previously be successfully statically linked
(and we had a test to prove it), and now it cannot.

Do you consider this to be a deliberate change? Is statically linking
a library that depends on libmount no longer supported?

(If it is, then we might as well stop providing static libraries for
GLib too, and you might as well stop providing static libraries for
libmount.)

smcv



Bug#963883: liblwp-protocol-https-perl: circular dependency with libwww-perl

2020-06-28 Thread gregor herrmann
On Sun, 28 Jun 2020 16:46:55 +0200, Bill Allombert wrote:

> There is a circular dependency between liblwp-protocol-https-perl and 
> libwww-perl:
> 
> liblwp-protocol-https-perl:Depends: libwww-perl (>= 6.05-2)
> libwww-perl   :Depends: liblwp-protocol-https-perl
> 
> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.

This circular dependency exists since May 2011, i.e. since
liblwp-protocol-https-perl was split off from libwww-perl.

I don't remember any problems in the last 9 years, and I fail to
immediately see which problems this could cause.

Please note that there is no circular _build_ dependency (and even if
there were, all pure test dependencies are annotated with 
in both packages).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Penelope Swales: Almond Eyes


signature.asc
Description: Digital Signature


Bug#963717: aerc embeds build path and can't find config files

2020-06-28 Thread Ben Fiedler

The bug is fixed and the release 0.3.0-2 prepared. As soon as someone
sponsors it the fix will be available.

Best,
Ben



Bug#963942: stretch-pu: package nvidia-graphics-drivers/390.138-1

2020-06-28 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

This is a new upstream release fixing CVE-2020-5963 and CVE-2020-5967.
The packaging changes are minimal this time ;-) (renamed lintian tags,
removed/refreshed patches and a new trivial patch for Linux 5.7).
The upload is comparable to the nvidia-graphics-drivers-legacy-390xx
390.138-1 upload to sid a few minutes ago.

Andreas


ngd-390.138-1.diff.gz
Description: application/gzip


Bug#963450: Bug #963450: installation-guide: FTBFS: /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty: File `ctexhook.sty' not found.

2020-06-28 Thread Holger Wansing
Control: tags -1 + pending

Lucas Nussbaum  wrote (Sun, 21 Jun 2020 20:43:17 UTC):
> Source: installation-guide
> Version: 20191229+rebuild1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
[...]
> Info: creating .pdf file...
> xelatex failed
> /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty: File 
> `ctexhook.sty' not found.
> /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty:105: Emergency stop.
> /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty:105: leading text: 
> \AtBeginDocument
> Unexpected error occured
> Error: xelatex compilation failed
> Error: build of pdf failed with error code 1
> Info: creating temporary .html file...
> Info: creating .txt file...
> Warning: The following formats failed to build: pdf
> make[1]: *** [Makefile:8: ja.i386] Error 2

This bug did not show up on debian-boot ...


texlive added additional Build-Depends somewhere in last versions for 
Chinese|Japanese|Korean PDFs (texlive-lang-chinese / texlive-lang-korean).
Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961703

Fixed for installation-guide now.
Tagging this bug as pending.


Holger


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



Bug#952370: #952370 not fixed yet

2020-06-28 Thread Emmanuel Bourg
Le 28/06/2020 à 10:47, Niko Tyni a écrit :

> The actual fix for #952370 seems to be missing, I only see a changelog
> entry in the debdiff.
> 
> At least cronometer_0.9.9+dfsg-3 still fails to build.
> 
> Reopening.

Thank you for spotting this mistake Niko, it looks like I've erased the
fix just before uploading. I'll upload it again.

Emmanuel Bourg



Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892

2020-06-28 Thread Craig Small
On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack 
wrote:

> we are not happy yet with those commits because they change a struct
> without bumping the soname. We are investigating how impactful that is.
>

Hi,
  Did you see how bad these patches are with the API change?  Generally if
the API is doing things like mystruct_new() and mystruct_free() its
probably ok but malloc(struct mystruct) will be a problem because the
binary will have one idea of the size and the library another. It also
depends if they are using accessor functions to get values or directly
pulling them out of the struct.

I'm concerned that if the binary has one idea of the struct and the library
has another we are going to get some very bad corruption going on between
them.

 - Craig


Bug#963940: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.138-1~deb10u1

2020-06-28 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

This is a new upstream release fixing CVE-2020-5963 and CVE-2020-5967.
The packaging changes are minimal this time ;-) (renamed lintian tags,
removed/refreshed patches and a new trivial patch for Linux 5.7).
The upload is a plain rebuild of the sid package uploaded a few minutes ago.

Andreas


ngd390xx-390.138-1~deb10u1.diff.gz
Description: application/gzip


Bug#963884: libmaven-plugin-tools-java: circular dependency with libsurefire-java

2020-06-28 Thread Emmanuel Bourg
Le 28/06/2020 à 16:49, Bill Allombert a écrit :

> There is a circular dependency between libmaven-plugin-tools-java and
> libsurefire-java:
> 
> libmaven-plugin-tools-java:Depends: libsurefire-java (>= 2.22.1)
> libsurefire-java  :Depends: libmaven-plugin-tools-java (>= 3.6.0)
> 
> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.

Hi Bill,

There are many circular dependencies in the Maven ecosystem. I don't
think this is really an issue though, none of these libraries have
maintainer scripts that may trigger an issue during upgrades.

Emmanuel Bourg



Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)

2020-06-28 Thread Adam Borowski
On Sun, Jun 28, 2020 at 05:33:30AM +0300, Boian Bonev wrote:
>  * Package name: iotop-c
>Version : 1.4-1

> Changes since the last upload:
> 
>* Upstream release 1.4

Hi!
1. What "last upload"?  This is the first release into Debian.  And thus,
there's no history yet -- work in progress that hasn't ever been uploaded
to the archive isn't really of interest to anyone (except maybe a git
archive).  The changelog is meant to notify users and other developers
what has been changed.  Thus, could you please squash this into just
"Initial release: closes #123456"?

The only case when keeping such history would be good is when the package
had already been provided via some other repository, such as a Debian
derivative (such as Ubuntu, Devuan, Mint...) or at least to a group of
users.

2. The package fails to build:
   dh_auto_install
make -j64 install DESTDIR=/<>/debian/iotop-c 
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
STRIP iotop
INSTALL iotop
install: cannot change ownership of 
'/<>/debian/iotop-c/usr/sbin/iotop': Operation not permitted
make[1]: *** [Makefile:53: install] Error 1
make[1]: Leaving directory '/<>'
dh_auto_install: error: make -j64 install 
DESTDIR=/<>/debian/iotop-c AM_UPDATE_INFO_DIR=no "INSTALL=install 
--strip-program=true" returned exit code 2

3. The long desc talks about kernel 2.6.20.  This is no longer relevant, as
Debian won't work on kernels < 3.2 (non-systemd) or < 3.13 (systemd), many
packages probably having a much newer requirement.  Thus, this piece can
be dropped.


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



Bug#963205:

2020-06-28 Thread Thomas Orgis
Am Sun, 28 Jun 2020 22:16:13 +0200
schrieb Sebastian Ramacher : 

> Unfortunately the patch fails to build on i386:

Darn. Of course, sorry. This is missing:

Index: src/libsyn123/syn123.h.in
===
--- src/libsyn123/syn123.h.in   (revisión: 4743)
+++ src/libsyn123/syn123.h.in   (copia de trabajo)
@@ -964,6 +964,7 @@
 ssize_t syn123_resample_inexpect(syn123_handle *sh, size_t outs);
 
 
+#ifndef SYN123_NO_LARGENAME
 /* Lightweight large file hackery to enable worry-reduced use of off_t.
Depending on the size of off_t in your client build, the corresponding
library function needs to be chosen. */
@@ -978,6 +979,7 @@
 #error "Unpredicted _FILE_OFFSET_BITS value."
 #  endif
 #endif
+#endif
 
 /** Give exact output sample count for total input sample count.
  *
Index: src/libsyn123/syn123_int.h
===
--- src/libsyn123/syn123_int.h  (revisión: 4743)
+++ src/libsyn123/syn123_int.h  (copia de trabajo)
@@ -17,6 +17,7 @@
 #include "intsym.h"
 #include "compat.h"
 #include "abi_align.h"
+#define SYN123_NO_LARGENAME
 #include "syn123.h"
 
 // Generally, a number of samples we work on in one go to


I pushed a new snapshot. Can you verify?


Alrighty then,

Thomas


pgpwmazzlfxm2.pgp
Description: Firma digital OpenPGP


Bug#963875: [Pkg-roundcube-maintainers] Bug#963875: roundcube: SQL Error

2020-06-28 Thread Guilhem Moulin
Control: tag -1 + unreproducible moreinfo

On Sun, 28 Jun 2020 at 14:35:11 +0100, Nigel Horne wrote:
> Fails to install properly with 'apt install roundcube':
>
> Creating config file /etc/roundcube/debian-db.php with new version
> checking privileges on database roundcube for roundcube@localhost: user 
> creation needed.
> granting access to database roundcube for roundcube@localhost: failed.
> error encountered creating user:

Can't reproduce this in a clean sid chroot, and piuparts didn't complain
either: https://piuparts.debian.org/sid/pass/roundcube_1.4.6+dfsg.1-2.log

> mysql said: ERROR 1064 (42000) at line 1: You have an error in your SQL 
> syntax; check the manual that corresponds to your MySQL server version for 
> the right syntax to use near 'IF NOT EXISTS 'roundcube'@'localhost'' at line 1
> dbconfig-common: roundcube configure: trying again.

It's not us doing the user creation but dbconfig-common.  So your RDMS
doesn't like the CREATE USER statement?  Which MySQL flavor are you
using?  MariaDB or MySQL?  Which version?

It appears MySQL ≤5.6 doesn't support `CREATE USER IF NOT EXISTS` [0],
however Debian has only 5.7.26 (in sid only) [1] which does [2].  And as
of Debian Stretch the default MySQL flavor is MariaDB which *does*
support `CREATE USER IF NOT EXISTS` since 10.1.3 [3].

-- 
Guilhem.

[0] https://dev.mysql.com/doc/refman/5.6/en/create-user.html
[1] https://tracker.debian.org/pkg/mysql-server
[2] https://dev.mysql.com/doc/refman/5.7/en/create-user.html
[3] https://mariadb.com/kb/en/create-user/#if-not-exists


signature.asc
Description: PGP signature


Bug#963939: lintian: breakout-link wrongly reported against jar files

2020-06-28 Thread Emmanuel Bourg
Package: lintian
Version: 2.82.0
Severity: normal

Hi,

lintian is reporting breakout-link warnings on several Eclipse packages
(such as eclipse-platform-ui). This is due to links in /usr/lib/eclipse/plugins/
pointing to jar files in /usr/share/java/.

I don't think this warning applies to architecture independent jar files.

Emmanuel Bourg



Bug#963938: latex2rtf FTCBFS: relinks latex2rtf during make install-bin with the build architecture compiler

2020-06-28 Thread Helmut Grohne
Source: latex2rtf
Version: 2.3.18a-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

latex2rtf fails to cross build from source, because it relinks latex2rtf
during make install-bin using the build architecture compiler. Nothing
passes a cross compiler to make install-bin and in theory, make
install-bin shouldn't compile anything. Unfortunately, latex2rtf is
included in the .PHONY rule and thus is uselessly remade. You can see
this in native build logs and it breaks cross build. Please consider
applying the attached patch.

Helmut
--- latex2rtf-2.3.18a.orig/Makefile
+++ latex2rtf-2.3.18a/Makefile
@@ -259,7 +259,7 @@ appleclean:
 splint:
 	splint -weak $(SRCS) $(HDRS)
 	
-.PHONY: all check checkdir clean depend dist doc install install-info realclean latex2rtf uptodate releasedate splint fullcheck install-doc install-bin
+.PHONY: all check checkdir clean depend dist doc install install-info realclean uptodate releasedate splint fullcheck install-doc install-bin
 
 # created using "make depend"
 commands.o: commands.c cfg.h main.h convert.h chars.h fonts.h preamble.h \


Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

2020-06-28 Thread Bernd Zeimetz



On 6/28/20 10:58 PM, Lucas Nussbaum wrote:
> Well, I think that it would a good thing for Debian to enforce some
> consistency on Debian images for clouds and software that require
> VM images, at least about where to find information about such images,
> and where to report problems.
> 
> And I don't think that pointing to github for our tooling, and for bug
> reporting, is really an acceptable solution for something that is
> officially endorsed by Debian.

Official *Docker* images come from
https://github.com/docker-library/official-images

It might be possible to pull git repositories from the outside of git
hub in there, though, but I doubt it is. At least you'll have to use
github pull requests.

Of course you are free to run your own registry even under a debian.org
domain and provide official Debian images for docker there, but as long
as you want to have them in the docker hub, I think the current practice
is just fine. And: its an image from DOCKER, maintained by Debian
developers - its not an image from DEBIAN. It says 'Docker official
images', not 'Debian official images'.

To be honest, I fail to understand why this needs discussion at all.



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



Bug#963889: O: ifenslave -- configure network interfaces for parallel routing (bonding)

2020-06-28 Thread Marco d'Itri
On Jun 28, Guus Sliepen  wrote:

> ifenslave used to be a standalone binary that sent ioctls to the kernel,
> but nowadays bonding can be configured via the "ip" command from the
> iproute2 package, and by writing to the /sys/ tree. The package no
> longer contains the standalone binary, but just provides hooks scripts
> for ifupdown.
I suggest that whoever adopts ifupdown will also take ifenslave and just 
fold it in ifupdown, because since it only contains scripts then it does 
not make any sense to keep it around as a standalone package anymore.
Hence also brilliantly solving the issue with the s-word.

Also, modern systems are supposed to migrate to the "new" teaming 
driver, but AFAIK it is well integrated only in NetworkManager.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#963792: transition: ros-*

2020-06-28 Thread Sebastian Ramacher
Hi Jochen

On 2020-06-27 11:50:12 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> I would like to transition these packages to unstable:
> 
> ros-roscpp-core
> ros-ros-comm
> ros-geometric-shapes
> ros-urdf
> ros-interactive-markers
> ros-actionlib
> ros-geometry2
> ros-vision-opencv
> 
> Would you be ok with doing all of them at the same time?
> (Otherwise I would start with ros-roscpp-core.)

Do all reverse dependencies build fine against the new versions?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

2020-06-28 Thread Lucas Nussbaum
On 28/06/20 at 10:54 -0700, Ross Vandegrift wrote:
> [removing serpent@d.o from CC, he's resigned as delegate]
> 
> Hi Lucas,
> 
> On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote:
> > One could argue that the Cloud team delegation does not cover Docker
> > images.
> 
> Whether it does or not, I've been told that the docker image maintainers 
> prefer
> to keep their current organization and workflow.  I'd welcome their
> participation in the team, if they were interested.  But I don't think they
> need to be.

Well, I think that it would a good thing for Debian to enforce some
consistency on Debian images for clouds and software that require
VM images, at least about where to find information about such images,
and where to report problems.

And I don't think that pointing to github for our tooling, and for bug
reporting, is really an acceptable solution for something that is
officially endorsed by Debian.

Solving this for Docker or Vagrant sounds very similar to solving it for
cloud images; so it's probably best if the same people are in charge.

> Maybe it could be nice, if the people building those images want to use our
> tools and work with us.  Some would raise concerns in my mind, but I don't
> think it's useful to discuss before someone wants to build e.g. raspberry pi
> images in cloud-team.

I'm surprised by this. I thought of the delegation as a (soft) hammer to
enforce some rules, even when people are not nice and don't want to work
with the cloud team (I'm not saying it's the case here).


I've seen people saying "oh look, the official Debian images for docker
point to github! that's funnny!". If those images are not official,
then this should be clarified. If they are, then they should probably
conform to standard ways of maintaining stuff in Debian.

Lucas



Bug#963904: RFS: nfq/1.0.13-1 [ITP] -- punicode DNS filter to mitigate homograph phishing attacks

2020-06-28 Thread Joachim Bauernberger
Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

 * Package name: nfq
   Version : 1.0.13-1
   Upstream Author : Joachim Bauernberger 
 * URL : https://gitlab.com/jbauernberger/nfq/
 * License : GPL-3.0+
 * Vcs : https://gitlab.com/jbauernberger/nfq/
   Section : net

It builds those binary packages:

  nfq - punicode DNS filter to mitigate homograph phishing attacks

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nfq/nfq_1.0.13-1.dsc

Changes since the last upload:

   * fix nfq.service rm PrivateDevice=true which breaks syslog

Regards,

--
  Joachim Bauernberger



Bug#963936: inspircd: Problematic "lazy" + banana reference in inspircd example motd

2020-06-28 Thread Ernesto Alfonso
Source: inspircd
Severity: normal

The example inspircd motd (inspircd/docs/conf/motd.txt.example)
contains a reference to "lazy" and "bannana" together,
which is considered racially offensive.

I pointed this out in the upstream issuetracker, but the maintainers
promptly dismissed the issue and then hid it from public view:

https://github.com/inspircd/inspircd/issues/1786

While the maintainers have made their position clear,
does Debian consider this sort of language acceptable
in a package distributed by Debian?

 __   __  _
|_   _|  |_   _| |  __ \  / || |
  | |_ _____   _ __| |   | |__) || |   __| |
  | |   | '_ \  / __| | '_ \   | |   |  _  / | |  / _` |
 _| |_  | | | | \__ \ | |_) | _| |_  | | \ \ | | | (_| |
|_| |_| |_| |___/ | .__/ |_| |_|  \_\ \_| \__,_|
__| |___
   |__|_|___|

Putting the ricer in IRCer since 2007

   //\
   V  \WELCOME TO AN INSPIRCD NETWORK
\  \_If you see this, I am probably new.
 \,'.`-.   If I'm not new, my owner is lazy.
  |\ `. `.
  ( \  `. `-._,.-:\
   \ \   `.  `-._ __..--' ,-';/
\ `.   `-.   `-..___..---'   _.--' ,'/
 `. `.`-.___..--',' /
   `. `-_ ``--..''   _.-' ,'
 `-_ `-._____,--'   ,'
`-.__  `"""__.-'
 `--....--'

 To change, see motd.txt.example -



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

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

Ernesto



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-28 Thread Bastian Blank
On Sun, Jun 28, 2020 at 09:40:12PM +0200, Mattia Rizzolo wrote:
> On Sun, Jun 28, 2020 at 05:32:05PM +0200, Lucas Nussbaum wrote:
> > The importer uses http://duck.debian.net/ which doesn't resolve anymore.

duck.d.n in the past pulled git repositories from salsa.d.o, not sure
what exactly it did with them.  However it stopped pulling at least
three months ago.

>  * it turns out said code was not freely license and as such easily
>usable by a new maintainer in a new deployment

Nice, not really.

> Baptiste (CCed) volunteered to write it over again, but for now there is
> no clear timeline as for when the new project will be started.

Maybe you could add that to vcswatch?

Regards,
Bastian

-- 
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4



Bug#963205:

2020-06-28 Thread Sebastian Ramacher
On 2020-06-26 15:46:59 +0200, Thomas Orgis wrote:
> OK,
> 
> I introduced the additional wrapper now with svn commit 4743 on
> svn://scm.orgis.org/mpg123 .
> 
> You can test by using current https://mpg123.org/snapshot or by
> applying the attached patch.
> 
> Test reports before I release (this weekend?) are welcome.
> 
> 
> Alrighty then,
> 
> Thomas

> Index: NEWS
> ===
> --- NEWS  (revisión: 4742)
> +++ NEWS  (revisión: 4743)
> @@ -10,6 +10,8 @@
>  - More CMake build fixes thanks to David Callu (bug 290).
>  - Use PROG_LIBS for output modules, to reinstate not necessarily proper but
>previous behaviour and fix FreeBSD port build (bug 291).
> +- Refine LFS support in libsyn123, avoiding architecture-dependent syn123.h
> +  (debian bug 963205).
>  
>  1.26.1
>  --
> Index: src/libsyn123/resample.c
> ===
> --- src/libsyn123/resample.c  (revisión: 4742)
> +++ src/libsyn123/resample.c  (revisión: 4743)
> @@ -1899,15 +1899,25 @@
>   return (tot <= INT64_MAX) ? (int64_t)tot : SYN123_OVERFLOW;
>  }
>  
> -#if SIZEOF_LONG == 4
> -long attribute_align_arg
> -syn123_resample_total_32(long inrate, long outrate, long ins)
> +int32_t attribute_align_arg
> +syn123_resample_total_32(int32_t inrate, int32_t outrate, int32_t ins)
>  {
>   int64_t tot = syn123_resample_total_64(inrate, outrate, ins);
> - return (tot <= LONG_MAX) ? (long)tot : SYN123_OVERFLOW;
> + return (tot <= INT32_MAX) ? (int32_t)tot : SYN123_OVERFLOW;
>  }
> +
> +lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
> +{
> +#if   LFS_ALIAS_BITS+0 == 64
> + return syn123_resample_total_64(inrate, outrate, ins);
> +#elif LFS_ALIAS_BITS+0 == 32
> + return syn123_resample_total_32(inrate, outrate, ins);
> +#else
> + #error "Unexpected LFS_ALIAS_BITS value."
>  #endif
> +}
>  
> +
>  // The inverse function: How many input samples are needed to get at least
>  // the desired amount of output?
>  int64_t attribute_align_arg
> @@ -1959,17 +1969,24 @@
>   return (tot <= INT64_MAX) ? (int64_t)tot : SYN123_OVERFLOW;
>  }
>  
> -#if SIZEOF_LONG == 4
> -long attribute_align_arg
> -syn123_resample_intotal_32(long inrate, long outrate, long outs)
> +int32_t attribute_align_arg
> +syn123_resample_intotal_32(int32_t inrate, int32_t outrate, int32_t outs)
>  {
>   int64_t tot = syn123_resample_intotal_64(inrate, outrate, outs);
> - return (tot <= LONG_MAX) ? (long)tot : SYN123_OVERFLOW;
> + return (tot <= INT32_MAX) ? (int32_t)tot : SYN123_OVERFLOW;
>  }
> +
> +lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t 
> outs)
> +{
> +#if   LFS_ALIAS_BITS+0 == 64
> + return syn123_resample_intotal_64(inrate, outrate, outs);
> +#elif LFS_ALIAS_BITS+0 == 32
> + return syn123_resample_intotal_32(inrate, outrate, outs);
> +#else
> + #error "Unexpected LFS_ALIAS_BITS value."
>  #endif
> +}
>  
> -#define syn123_resample_total syn123_resample_total_64
> -
>  // As any sensible return value is at least 1, this uses the unsigned
>  // type and 0 for error/pathological input.
>  // This function could be simplified to
> Index: src/libsyn123/syn123.h.in
> ===
> --- src/libsyn123/syn123.h.in (revisión: 4742)
> +++ src/libsyn123/syn123.h.in (revisión: 4743)
> @@ -977,9 +977,6 @@
>  #  else
>  #error "Unpredicted _FILE_OFFSET_BITS value."
>  #  endif
> -#else
> -#define syn123_resample_total   syn123_resample_total_@LFS_ALIAS_BITS@
> -#define syn123_resample_intotal syn123_resample_intotal_@LFS_ALIAS_BITS@
>  #endif
>  
>  /** Give exact output sample count for total input sample count.

Unfortunately the patch fails to build on i386:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src 
-DPKGLIBDIR=\"/usr/lib/i386-linux-gnu/mpg123\" -I./src -I./src/compat 
-I./src/libmpg123 -I./src/libout123 -I./src/libmpg123 -I./src/libsyn123 
-I./src/libout123 -DOPT_MULTI -DOPT_GENERIC -DOPT_GENERIC_DITHER -DOPT_I386 
-DOPT_I586 -DOPT_I586_DITHER -DOPT_MMX -DOPT_3DNOW -DOPT_3DNOW_VINTAGE 
-DOPT_3DNOWEXT -DOPT_3DNOWEXT_VINTAGE -DOPT_SSE -DOPT_SSE_VINTAGE 
-DREAL_IS_FLOAT -DNEWOLD_WRITE_SAMPLE -Wdate-time -D_FORTIFY_SOURCE=2 -O2 
-fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c src/libsyn123/resample.c  -fPIC -DPIC -o 
src/libsyn123/.libs/resample.o
In file included from src/libsyn123/syn123_int.h:20,
 from src/libsyn123/resample.c:84:
src/libsyn123/syn123.h:975:37: error: conflicting types for 
‘syn123_resample_total_64’
  975 | #define syn123_resample_total   syn123_resample_total_64
  | ^~~~
src/libsyn123/resample.c:1909:13: note: in expansion of macro 
‘syn123_resample_total’
 1909 | 

Bug#963902: ITP: node-tiptap -- A renderless and extendable rich-text editor for Vue.js

2020-06-28 Thread Abraham Raji
Package: wnppSeverity: wishlistOwner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-tiptap
  Version : 1.27.1
  Upstream Author : 2019, Scrumpy UG (limited liability)
* URL : https://github.com/scrumpy/tiptap/blob/master/README.md
* License : Expat
  Programming Lang: JavaScript
  Description : A renderless and extendable rich-text editor for Vue.js


This package is a dependency for hui-vue, pbpm, adminify, vue-butler and many 
other node modules.
.
I intend to package this myself but I will need sponsorship to upload.


Bug#884135: qa.debian.org: UDD should honor comment-only watch file

2020-06-28 Thread Lucas Nussbaum
Hi,

On 11/12/17 at 20:59 +0100, Paul Gevers wrote:
> Package: qa.debian.org
> Severity: normal
> User: qa.debian@packages.debian.org
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Multiple of my packages do not have a proper URL to watch. Lintian suggest to
> add a watch file with comments, and uscan handles those gracefully. UDD
> turns them into an error on line 106 in rimporters/upstream.rb.
> 
> Please improve UDD to treat "empty" watch files as they are meant to be by
> people that follow Lintian's advice.

Bug triaging: this still happens, as shown for example by:

select source,watch_file,last_check,status from upstream where watch_file is 
not null and length(watch_file) < 30;

Lucas


signature.asc
Description: PGP signature


Bug#963932: Duplicate symbol json_object_iter_next in json-c, jansson

2020-06-28 Thread Chris Hofstaedtler
* Chris Hofstaedtler  [200628 20:10]:
> your libraries BOTH export a symbol named json_object_iter_next,
> causing crashes for binaries that end up loading both (possibly
> transitively).
[..]

Upstream bugs:

https://github.com/json-c/json-c/issues/621

https://github.com/akheron/jansson/issues/523

Chris



Bug#963935: node-modern-syslog: missing versioned dependency relation?: modern-syslog/build/Release/core.node',was compiled against a different Node.js version

2020-06-28 Thread Paul Gevers
Source: node-modern-syslog
Version: 1.2.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, nod...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:nodejs

Dear maintainer(s),

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

   passfail
nodejs from testing12.18.0~dfsg-3
node-modern-syslog from testing1.2.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Similar to the
issues with node-iconv, node-expat and node-node-sass,
node-modern-syslog seems to be missing a versioned relation with nodejs.
Because of the missing relation, nodejs can be upgraded without the
rebuild node-modern-syslog unstable.

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=nodejs

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-modern-syslog/6061132/log.gz

Error: The module
'/usr/lib/x86_64-linux-gnu/nodejs/modern-syslog/build/Release/core.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 64. This version of Node.js requires
NODE_MODULE_VERSION 72. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
at Object.Module._extensions..node
(internal/modules/cjs/loader.js:1188:18)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)
at Module.require (internal/modules/cjs/loader.js:1026:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object.
(/usr/lib/x86_64-linux-gnu/nodejs/modern-syslog/index.js:9:12)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)



signature.asc
Description: OpenPGP digital signature


Bug#963900: ITP: node-decode-uri-component -- A Decode URI Component

2020-06-28 Thread Abraham Raji
Package: wnppSeverity: wishlistOwner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-tiptap
  Version : 1.27.1
  Upstream Author : 2019, Scrumpy UG (limited liability)
* URL : https://github.com/scrumpy/tiptap/blob/master/README.md
* License : Expat
  Programming Lang: JavaScript
  Description : A renderless and extendable rich-text editor for Vue.js


This package is a dependency for hui-vue, pbpm, adminify, vue-butler and many 
other node modules.
.
I intend to package this myself but I will need sponsorship to upload.






Bug#963934: ITP: golang-github-shenwei356-bpool -- Buffer/Byte pool for Go (library)

2020-06-28 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: golang-github-shenwei356-bpool -- Buffer/Byte pool for Go 
(library)
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: golang-github-shenwei356-bpool
  Version : 0.0~git20160710.f9e0ee4
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/bpool
* License : Apache-2.0
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Buffer/Byte pool for Go (library)
 This library implements leaky pools of byte arrays and Buffers as bounded
 channels.  It is based on the leaky buffer example from the Effective
 .
 Bpool provides the following pool types:
 .
  BufferPool: fixed-size pool of bytes.Buffers
  BytePool:   fixed-size pool of byte slices with a pre-set width
  SizedBufferPool: alternative to BufferPool that pre-sizes the
  capacity of buffers issued from the pool and discards
  buffers that have grown too large upon return.
 .
 A common use case for this package is to use buffers
 to execute HTML templates against (via ExecuteTemplate) or encode JSON
 into (via json.NewEncoder). This allows you to catch any rendering
 or marshalling errors prior to writing to a http.ResponseWriter,
 which helps to avoid writing incomplete or malformed data to the
 response.

Remark: This package is maintained by Debian Go Packaging Team at
   https://salsa.debian.org/go-team/packages/golang-github-shenwei356-bpool



Bug#963932: Duplicate symbol json_object_iter_next in json-c, jansson

2020-06-28 Thread Chris Hofstaedtler
Control: reassign -1 jansson,json-c
Control: affects -1 firewalld
Control: severity -1 serious

Dear json-c and jansson Maintainers,

your libraries BOTH export a symbol named json_object_iter_next,
causing crashes for binaries that end up loading both (possibly
transitively).

This is currently the case in Debian for firewalld, which loads
libmount1 and libnftables1, which use json-c and jansson
respectively. firewalld then crashes because of this.

Some detail:

* Michael Biebl  [200628 21:27]:
> Am 28.06.20 um 21:16 schrieb Chris Hofstaedtler:
> 
> > $ ldd /usr/lib/x86_64-linux-gnu/libmount.so.1
> > libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 
> > (0x7f289aec6000)
> > ...
> > 
> > $ ldd /usr/lib/x86_64-linux-gnu/libnftables.so.1
> > libjansson.so.4 => /lib/x86_64-linux-gnu/libjansson.so.4 
> > (0x7f71ffd16000)
> > ...
> > 
> > $ nm -Dg /lib/x86_64-linux-gnu/libjson-c.so.4 | grep json_object_iter
> > 6fe0 T json_object_iter_begin
> > 7000 T json_object_iter_end
> > 7040 T json_object_iter_equal
> > 7050 T json_object_iter_init_default
> > 7010 T json_object_iter_next
> > 7020 T json_object_iter_peek_name
> > 7030 T json_object_iter_peek_value
> > $ nm -Dg /lib/x86_64-linux-gnu/libjansson.so.4 | grep json_object_iter
> > 9030 T json_object_iter
> > 9050 T json_object_iter_at
> > 90b0 T json_object_iter_key
> > 9080 T json_object_iter_next
> > 9b00 T json_object_iter_set_new
> > 90d0 T json_object_iter_value
[..]
> Agreed, this should be tracked separately.

Please find a way to fix this situation.

Thanks,
Chris



Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup

2020-06-28 Thread Chris Hofstaedtler
Source: glib2.0
Severity: serious
Version: 2.64.3-1

Dear glib2.0 Maintainers,

the autopkgtest suite offers quite interesting behaviour:
With an installed libcryptsetup-dev, ld fails with "cannot find
-lcryptsetup".

Log: 
https://ci.debian.net/data/autopkgtest/testing/amd64/g/glib2.0/6071882/log.gz

autopkgtest [00:19:30]: test build: preparing testbed
..
Selecting previously unselected package libcryptsetup-dev:amd64.
Preparing to unpack .../19-libcryptsetup-dev_2%3a2.3.3-1_amd64.deb ...
Unpacking libcryptsetup-dev:amd64 (2:2.3.3-1) ...
..
autopkgtest [00:19:45]: test build: ---]
autopkgtest [00:19:45]: test build:  - - - - - - - - - - results - - - - - - - 
- - -
buildPASS (superficial)
autopkgtest [00:19:45]: test build-static: preparing testbed
..
+ gcc -static -o gio-static gio.c -pthread -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lgio-2.0 -ldl -pthread -lresolv 
-lgmodule-2.0 -pthread -ldl -lz -lmount -lblkid -lcryptsetup -lselinux -lsepol 
-lpcre2-8 -pthread -lgobject-2.0 -pthread -lffi -lglib-2.0 -pthread -lpcre 
-pthread
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgmodule-2.0.a(gmodule.c.o):
 in function `g_module_open':
(.text+0x703): warning: Using 'dlopen' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lcryptsetup

I imagine this might be caused by libcryptsetup-dev not shipping an
.a library.

This prevents libmount1/util-linux to transition. Please investigate
and hopefully fix the problem at hand.

Thanks,
Chris



Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-28 Thread Chris Hofstaedtler
Control: clone -1 -2
Control: retitle -1 libmount1: pulls in libssl, breaking 
statically-linked-to-libssl software
Control: severity -1 wishlist
Control: tags -1 wontfix
Control: retitle -2 libjson-c and libjansson both export json_object_iter_next


Hi Christian, Guilhem,

For Steam issues, please see #963525:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963525

This is a bug in Steam upstream.

I imagine the same is true for Minecraft, which I'd expect to ship a
statically linked copy of libssl too. This is not something we can
fix in Debian.

Sorry that there will be no immediate fix; I hope you'll understand.
If possible, please tell the people producing Minecraft for Debian
that they need to fix their packages.


* Michael Biebl  [200628 21:27]:
> Agreed, this should be tracked separately.
> Sorry for hijacking #963721 with that firewalld issue.
> To my defence, it appeared to be related due to the libmount1 update
> triggering the issue.

For this issue, I'll clone this bug and reassign.

Best,
Chris



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-28 Thread Mattia Rizzolo
On Sun, Jun 28, 2020 at 05:32:05PM +0200, Lucas Nussbaum wrote:
> The importer uses http://duck.debian.net/ which doesn't resolve anymore.

Some context:
 * the previous maintainer of duck.d.n retired, and as such the .d.n
   domain was removed
 * the previous maintainer was contacted to have at least access to the
   previously running code
 * it turns out said code was not freely license and as such easily
   usable by a new maintainer in a new deployment

Baptiste (CCed) volunteered to write it over again, but for now there is
no clear timeline as for when the new project will be started.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#963927: Bug-report severity fix

2020-06-28 Thread Nilesh Patra
Control: severity -1 serious
thanks


Bug#963930: O: starfighter -- 2D scrolling shooter game

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the starfighter package.

I no longer have time to maintain this package. This game is actively
maintained, and there are newer upstream versions of this game that
should be packaged:

https://github.com/pr-starfighter/starfighter/releases

The package description is:
 After decades of war one company, who had gained powerful supplying both
 sides with weaponry, steps forwards and crushes both warring factions
 in one swift movement. Using far superior weaponry and AI craft, the
 company was completely unstoppable and now no one can stand in their
 way. Thousands began to perish under the iron fist of the company. The
 people cried out for a saviour, for someone to light this dark hour...
 and someone did.
 .
 Features of the game:
 .
  o 26 missions over 4 star systems
  o Primary and Secondary Weapons (including a laser cannon and a charge weapon)
  o A weapon powerup system
  o Wingmates
  o Missions with Primary and Secondary Objectives
  o A Variety of Missions (Protect, Destroy, etc)
  o Boss battles



Bug#963916: rust-debcargo: Cannot build debcargo

2020-06-28 Thread peter green


I cannot build debcargo currently. It fails with:

missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: librust-cargo-0.43+default-dev:amd64

Thanks
Sylvestre


The root cause (or at least one of the root causes) of this is that rust-im-rc 
is stuck in new.



Bug#963931: linux-image-4.19.0-8-amd64: onetime crash on radeon (hardware: Radeon HD 4200)

2020-06-28 Thread Neo
Package: src:linux
Version: 4.19.98-1+deb10u1
Severity: normal

Dear Maintainer,

I had a onetime crash in radeon module using kernel 4.19.0-8-amd64 on debian 
stable
10.4. Not a temperature issue as the system was idle. With
much disk space free and memory free. Swap was disabled.
Uptime was 22 days.
Visually, system looked like this: https://i.imgur.com/At72mkb.jpg
(window manager is ratpoison)
But I was still able to get into tty1, use htop etc. Reboot fixed the issue.

The relevant logs are on kernl.log:

Jun 28 14:14:37 NeoPC kernel: [1957414.528236] radeon :01:05.0: ring 0 
stalled for more than 10456msec
Jun 28 14:14:37 NeoPC kernel: [1957414.528250] radeon :01:05.0: GPU lockup 
(current fence id 0x070b35a6 last fence id 0x070b3628 on ring 0)
Jun 28 14:14:38 NeoPC kernel: [1957415.040203] radeon :01:05.0: ring 0 
stalled for more than 10968msec
Jun 28 14:14:38 NeoPC kernel: [1957415.040216] radeon :01:05.0: GPU lockup 
(current fence id 0x070b35a6 last fence id 0x070b3628 on ring 0)

(repeat every second for a few seconds. Then:)

Jun 28 14:14:55 NeoPC kernel: [1957432.303807] radeon :01:05.0: couldn't 
schedule ib
Jun 28 14:14:55 NeoPC kernel: [1957432.303909] [drm:radeon_uvd_suspend 
[radeon]] *ERROR* Error destroying UVD (-22)!
Jun 28 14:14:55 NeoPC kernel: [1957432.303931] radeon :01:05.0: couldn't 
schedule ib
Jun 28 14:14:55 NeoPC kernel: [1957432.303998] [drm:radeon_uvd_suspend 
[radeon]] *ERROR* Error destroying UVD (-22)!
Jun 28 14:14:55 NeoPC kernel: [1957432.305156] radeon :01:05.0: Saved 10617 
dwords of commands on ring 0.
Jun 28 14:14:55 NeoPC kernel: [1957432.305166] radeon :01:05.0: GPU 
softreset: 0x0008
Jun 28 14:14:55 NeoPC kernel: [1957432.305170] radeon :01:05.0:   
R_008010_GRBM_STATUS  = 0xA0003030
Jun 28 14:14:55 NeoPC kernel: [1957432.305173] radeon :01:05.0:   
R_008014_GRBM_STATUS2 = 0x0003
Jun 28 14:14:55 NeoPC kernel: [1957432.305177] radeon :01:05.0:   
R_000E50_SRBM_STATUS  = 0x20040040
Jun 28 14:14:55 NeoPC kernel: [1957432.305180] radeon :01:05.0:   
R_008674_CP_STALLED_STAT1 = 0x
Jun 28 14:14:55 NeoPC kernel: [1957432.305183] radeon :01:05.0:   
R_008678_CP_STALLED_STAT2 = 0x
Jun 28 14:14:55 NeoPC kernel: [1957432.305186] radeon :01:05.0:   
R_00867C_CP_BUSY_STAT = 0x00020182
Jun 28 14:14:55 NeoPC kernel: [1957432.305189] radeon :01:05.0:   
R_008680_CP_STAT  = 0x80028241
Jun 28 14:14:55 NeoPC kernel: [1957432.305193] radeon :01:05.0:   
R_00D034_DMA_STATUS_REG   = 0x44C83D57
Jun 28 14:14:55 NeoPC kernel: [1957432.365831] radeon :01:05.0: 
R_008020_GRBM_SOFT_RESET=0x4001
Jun 28 14:14:55 NeoPC kernel: [1957432.365885] radeon :01:05.0: 
SRBM_SOFT_RESET=0x0100
Jun 28 14:14:55 NeoPC kernel: [1957432.367976] radeon :01:05.0:   
R_008010_GRBM_STATUS  = 0xA0003030
Jun 28 14:14:55 NeoPC kernel: [1957432.367980] radeon :01:05.0:   
R_008014_GRBM_STATUS2 = 0x0003
Jun 28 14:14:55 NeoPC kernel: [1957432.367983] radeon :01:05.0:   
R_000E50_SRBM_STATUS  = 0x20048040
Jun 28 14:14:55 NeoPC kernel: [1957432.367986] radeon :01:05.0:   
R_008674_CP_STALLED_STAT1 = 0x
Jun 28 14:14:55 NeoPC kernel: [1957432.367989] radeon :01:05.0:   
R_008678_CP_STALLED_STAT2 = 0x
Jun 28 14:14:55 NeoPC kernel: [1957432.367992] radeon :01:05.0:   
R_00867C_CP_BUSY_STAT = 0x
Jun 28 14:14:55 NeoPC kernel: [1957432.367995] radeon :01:05.0:   
R_008680_CP_STAT  = 0x8010
Jun 28 14:14:55 NeoPC kernel: [1957432.367998] radeon :01:05.0:   
R_00D034_DMA_STATUS_REG   = 0x44C83D57
Jun 28 14:14:55 NeoPC kernel: [1957432.368004] radeon :01:05.0: GPU reset 
succeeded, trying to resume
Jun 28 14:14:55 NeoPC kernel: [1957432.386132] [drm] PCIE GART of 512M enabled 
(table at 0xC0146000).
Jun 28 14:14:55 NeoPC kernel: [1957432.386173] radeon :01:05.0: WB enabled
Jun 28 14:14:55 NeoPC kernel: [1957432.386176] radeon :01:05.0: fence 
driver on ring 0 use gpu addr 0xac00 and cpu addr 0xc8ce5bbe
Jun 28 14:14:55 NeoPC kernel: [1957432.388439] radeon :01:05.0: fence 
driver on ring 5 use gpu addr 0xc0056038 and cpu addr 0x1ea7bb9b
Jun 28 14:14:55 NeoPC kernel: [1957432.420343] [drm] ring test on 0 succeeded 
in 1 usecs
Jun 28 14:14:55 NeoPC kernel: [1957432.595058] [drm] ring test on 5 succeeded 
in 1 usecs
Jun 28 14:14:55 NeoPC kernel: [1957432.595190] [drm] UVD initialized 
successfully.
Jun 28 14:14:56 NeoPC kernel: [1957433.599697] [drm:r600_ib_test [radeon]] 
*ERROR* radeon: fence wait timed out.
Jun 28 14:14:56 NeoPC kernel: [1957433.599784] [drm:radeon_ib_ring_tests 
[radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110).
Jun 28 14:45:42 NeoPC kernel: [1959278.570267] docker0: port 2(veth7e9588f) 
entered disabled state
Jun 28 14:45:42 NeoPC kernel: [1959278.570554] vethb231955: renamed from eth0
Jun 28 

Bug#583489: qa.debian.org: Please provide 1.0 (explicit) and 1.0 (implicit) information

2020-06-28 Thread Lucas Nussbaum
Control: tags -1 + wontfix

Hi,

This is unlikely to be provided in the Sources file. However, that
information is available through lintian.

Tagging wontfix, as this bug was specifically about the sources table.

Lucas



Bug#963929: O: rsh-redone -- Reimplementation of rsh and rlogin

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the rsh-redone package.

I no longer have time to maintain this. I am also the upstream author of
this; if you want to adopt the package, you are also welcome to take
over upstream maintainership. However, since no-one should be using RSH
in this day and age anymore, if no one is interested I will request
removal of this package.

The package description is:
 Rsh-redone is a reimplementation of the remote shell clients and servers.
 It is written from the ground up to avoid the bugs found in the standard
 clients and servers. It also fully supports IPv6.
 .
 This package provides rsh and rlogin.



Bug#963927: predictprotein:Unusable, fails with: Assigning non-zero to $[ is no longer possible

2020-06-28 Thread Nilesh Patra
Package: predictprotein
Version: 1.1.09-2
Severity: severe

Dear Maintainer,

predictprotein uses `$[ = 1` which is no longer supported with newer
perl versions.
Way to reproduce:

Get the predictprotein source package, and cd there. Try running
examples with predictprotein:

$ cd examples
$ predictprotein --seqfile p53.fasta --output-dir test
Assigning non-zero to $[ is no longer possible at
/usr/share/librg-utils-perl//copf.pl line 11.
make: *** [/usr/share/predictprotein/MakefilePP.mk:475: query.fasta]
Error 255
make --no-builtin-rules INFILE=query.in -C /tmp/9BCtEP40vL JOBID=query
-j 1 BLASTCORES=1 LIBRGUTILS=/usr/share/librg-utils-perl/
PPROOT=/usr/share/predictprotein/ PROFNUMRESMIN=17
PROFROOT=/usr/share/profphd/prof/
BIGBLASTDB=/mnt/project/rost_db/data/blast/big
BIG80BLASTDB=/mnt/project/rost_db/data/blast/big_80
PFAM2DB=/mnt/project/rost_db/data/pfam/Pfam_ls
PFAM3DB=/mnt/project/rost_db/data/pfam/Pfam-A.hmm
PROSITEDAT=/mnt/project/rost_db/data/prosite/prosite.dat
PROSITECONVDAT=/mnt/project/rost_db/data/prosite/prosite_convert.dat
PSICEXE=/usr/share/rost-runpsic/runNewPSIC.pl
SPKEYIDX=/mnt/project/rost_db/data/swissprot/keyindex_loctree.txt
SWISSBLASTDB=/mnt/project/rost_db/data/blast/swiss --quiet -f
/usr/share/predictprotein/MakefilePP.mk all failed: 512 at
/usr/bin/predictprotein line 393.

Thanks

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

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

Versions of packages predictprotein depends on:
ii  bioperl   1.7.7-1
ii  disulfinder   1.2.11-8
ii  hmmer 3.3+dfsg2-1
ii  hmmer2    2.3.2+dfsg-6
ii  librg-exception-perl  1.0.3-4
ii  librg-utils-perl  1.0.43-6
ii  make  4.2.1-1.2
ii  metastudent   2.0.1-8
ii  ncbi-blast+-legacy    2.9.0-4
ii  ncbi-seg  0.0.2620-5
ii  ncoils    2002-7
ii  norsnet   1.0.17-6
ii  norsp 1.0.6-4
ii  perl  5.30.0-10
ii  predictnls    1.0.20-6
ii  profbval  1.0.22-6
ii  profisis  1.0.11-5
ii  profphd   1.0.42-3
ii  proftmb   1.1.12-8+b1
ii  reprof    1.0.1-7

predictprotein recommends no packages.

Versions of packages predictprotein suggests:
pn  pp-cache-mgr    
ii  pp-popularity-contest   1.0.6-4+b1
pn  predictprotein-nonfree  

-- no debconf information



Bug#963928: O: omega-rpg -- text-based roguelike game

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the omega-rpg package.

I no longer have time to maintain this package.

The package description is:
 Omega is a complex rogue-style game of dungeon exploration. Unlike other such
 games, there are a number of ways to "win", depending on various actions
 taken during play. The ways you can get your name on the high score board
 include becoming the highest ranked head of a guild, sect, college, etc., as
 well as gaining the most points figured from possessions and experience. The
 game (via the oracle) may impose some structure on your exploration, but you
 need not follow all of the oracle's advice. There *is* a "total winner"
 status, by the way.



Bug#963925: O: mod-mime-xattr -- Apache2 module to get MIME info from filesystem extended attributes

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the mod-mime-xattr package.

Upstream has stopped maintaining this a long time ago, and there are
only few users according to popcon. If there is no interest in it, I
will request a removal.

The package description is:
 This is a module for the Apache HTTPD 2.4 which may be used to set a range of
 MIME properties of files served from a document tree with extended attributes
 (EAs) as supported by the underlying file system. The following attributes may
 be used:
 .
  - user.mime_type: set the MIME type of a file explicitly. This attribute is
compatible with the shared MIME database specification as published by
freedesktop.org.
  - user.charset: set the charset used in a file.
  - user.mime_encoding: set the MIME encoding of a file (e.g. gzip).
  - user.apache_handler: set the apache handler of a file explicitly.
 This is a module for the Apache HTTPD 2.4 which may be used to set a range of
 MIME properties of files served from a document tree with extended attributes
 (EAs) as supported by the underlying file system. The following attributes may
 be used:
 .
  - user.mime_type: set the MIME type of a file explicitly. This attribute is
compatible with the shared MIME database specification as published by
freedesktop.org.
  - user.charset: set the charset used in a file.
  - user.mime_encoding: set the MIME encoding of a file (e.g. gzip).
  - user.apache_handler: set the apache handler of a file explicitly.



Bug#963926: O: mstch -- Mustache implementation in C++11

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the mstch package.

The package description is:
 Mstch is a complete implementation of {{mustache}} templates using
 modern C++. It's compliant with specifications v1.1.3, including the
 lambda module.
 .
 Mustache is a logic-less template language. As such, it is very well
 suited for programs that are written in a compiled language, such as C
 and C++, as they cannot easily evaluate code found in a template.
 Mustache does however supports a simple conditional and a loop statement.
 .
 This package contains the header files and a static library.



Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-28 Thread Michael Biebl

Nice work, Chris

Am 28.06.20 um 21:16 schrieb Chris Hofstaedtler:

> $ ldd /usr/lib/x86_64-linux-gnu/libmount.so.1
>   libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 
> (0x7f289aec6000)
> ...
> 
> $ ldd /usr/lib/x86_64-linux-gnu/libnftables.so.1
>   libjansson.so.4 => /lib/x86_64-linux-gnu/libjansson.so.4 
> (0x7f71ffd16000)
> ...
> 
> $ nm -Dg /lib/x86_64-linux-gnu/libjson-c.so.4 | grep json_object_iter
> 6fe0 T json_object_iter_begin
> 7000 T json_object_iter_end
> 7040 T json_object_iter_equal
> 7050 T json_object_iter_init_default
> 7010 T json_object_iter_next
> 7020 T json_object_iter_peek_name
> 7030 T json_object_iter_peek_value
> $ nm -Dg /lib/x86_64-linux-gnu/libjansson.so.4 | grep json_object_iter
> 9030 T json_object_iter
> 9050 T json_object_iter_at
> 90b0 T json_object_iter_key
> 9080 T json_object_iter_next
> 9b00 T json_object_iter_set_new
> 90d0 T json_object_iter_value
> 
> I'm considering cloning and reassinging to json-c and jansson.
> Personally I would guess jansson should not export symbols named
> json_*, but this is going to be ... interesting.

Agreed, this should be tracked separately.
Sorry for hijacking #963721 with that firewalld issue.
To my defence, it appeared to be related due to the libmount1 update
triggering the issue.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature


Bug#963922: rust-process-viewer: Cannot build process-viewer

2020-06-28 Thread Sylvestre Ledru
Source: rust-process-viewer
Severity: important

Dear Maintainer,

process-viewer cannot be build with:

missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: librust-sysinfo-0.9+default-dev:amd64

Thanks
Sylvestre

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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



Bug#963924: O: libdc1394-22 -- high level programming interface for IEEE 1394 digital cameras

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the libdc1394-22 package.

Note that libdc1394 replaces libdc1394-22, but this transition has not
finished.

The package description is:
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.



Bug#963923: O: libdc1394 -- high level programming interface for IEEE 1394 digital cameras

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the libdc1394 package.

There is occasional upstream activity for this package. At the moment
there are no reverse dependencies, but this package replaces
libdc1394-22, and the new maintainer should ensure the transition from
libdc1394-22 to libdc1394 is completed.

The package description is:
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.



Bug#963920: O: fgallery -- static HTML+JavaScript photo album generator

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the fgallery package.

There has been no upstream activity in the last 4 years, but apart from
that the package is working as intended. This program generates very
nice, mobile-friendly and responsive galleries.

The package description is:
 “fgallery” is a static photo gallery generator with no frills that has a
 stylish, minimalist look. “fgallery” shows your photos, and nothing else.
 .
 There is no server-side processing, only static generation. The resulting
 gallery can be uploaded anywhere without additional requirements and works with
 any modern browser.
 .
  * Automatically orients pictures without quality loss.
  * Multi-camera friendly: automatically sorts pictures by time: just throw your
(and your friends) photos and movies in a directory. The resulting gallery
shows the pictures in seamless shooting order.
  * Adapts to the current screen size and proportions, switching from
horizontal/vertical layout and scaling thumbnails automatically.
  * Includes original (raw) pictures in a zip file for downloading.
  * Panoramas can be seen full-size by default.


Bug#963921: O: inputlirc -- Zeroconf LIRC daemon using input event devices

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the inputlirc package.

I'm also the upstream maintainer of this package, if you are interested
in maintaining it you are welcome to take over upstream maintainership
as well.

The package description is:
 This is a small LIRC-compatible daemon that reads from /dev/input/eventX
 devices and sends the received keycodes to connecting LIRC clients. Inputlircd
 needs no configuration, it uses the standardised names for the keycodes as
 used by the kernel. Many USB remote controls that present HID devices, as well
 as multimedia keyboards should work out of the box.
 This is a small LIRC-compatible daemon that reads from /dev/input/eventX
 devices and sends the received keycodes to connecting LIRC clients. Inputlircd
 needs no configuration, it uses the standardised names for the keycodes as
 used by the kernel. Many USB remote controls that present HID devices, as well
 as multimedia keyboards should work out of the box.



Bug#963917: O: dhis-tools-dns -- Dynamic Host Information System - DNS configuration tools

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the dhis-tools-dns package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package includes a set of tools that may be used to manually
 create DHIS records on a dynamic DNS server.



Bug#963912: O: dhis-client -- Dynamic Host Information System - client

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the dhis-client package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 dhid is the DHIS client daemon. After setting up with a DHIS provider,
 each machine may run a dhid daemon (in background) in order to
 update its dynamic IP address within the server.



Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-28 Thread Chris Hofstaedtler
Hi Michael,

* Michael Biebl  [200628 03:30]:
> Am 27.06.20 um 21:14 schrieb Michael Biebl:
> > [16014.637459] traps: firewalld[35622] general protection fault
> > ip:7f981342d7b2 sp:7ffe6abe4ed0 error:0 in
> > libjansson.so.4.11.1[7f981342c000+8000]
> 
> Attached is a back trace.

It appears you indeed have found a symbol naming clash!

$ ldd /usr/lib/x86_64-linux-gnu/libmount.so.1
libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 
(0x7f289aec6000)
...

$ ldd /usr/lib/x86_64-linux-gnu/libnftables.so.1
libjansson.so.4 => /lib/x86_64-linux-gnu/libjansson.so.4 
(0x7f71ffd16000)
...

$ nm -Dg /lib/x86_64-linux-gnu/libjson-c.so.4 | grep json_object_iter
6fe0 T json_object_iter_begin
7000 T json_object_iter_end
7040 T json_object_iter_equal
7050 T json_object_iter_init_default
7010 T json_object_iter_next
7020 T json_object_iter_peek_name
7030 T json_object_iter_peek_value
$ nm -Dg /lib/x86_64-linux-gnu/libjansson.so.4 | grep json_object_iter
9030 T json_object_iter
9050 T json_object_iter_at
90b0 T json_object_iter_key
9080 T json_object_iter_next
9b00 T json_object_iter_set_new
90d0 T json_object_iter_value

I'm considering cloning and reassinging to json-c and jansson.
Personally I would guess jansson should not export symbols named
json_*, but this is going to be ... interesting.

Best,
Chris



Bug#963913: O: dhis-server -- Dynamic Host Information System - server

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the dhis-server package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.


The package description is:
 DHIS is a client-server architecture meant to update databases
 for systems which are assigned a dynamic IP[v4] address.
 .
 By the means of a DHIS client a host which is assigned a dynamic
 IP address (either from its ISP or from DHCP) is able to
 communicate with a DHIS server in order to advertise its newly
 acquired IP address.



Bug#963918: rust-spotify-tui: Cannot build spotify-tui

2020-06-28 Thread Sylvestre Ledru
Source: rust-spotify-tui
Severity: important

Dear Maintainer,

I cannot build spotify-tui, it fails with:


   depchain:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: librust-rspotify-0.7+default-dev:amd64 | 
librust-rspotify-0.7+default-dev:amd64

Thanks
Sylvestre


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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



Bug#963915: O: dhis-mx-sendmail-engine -- Dynamic Host Information System - sendmail MX engine

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the dhis-mx-sendmail-engine package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package contains a mail relaying service module to be used
 with dhisd release 5 or above and the dynamic DNS module.
 .
 While the DHIS server dhisd retrieves dynamic IP addresses
 from clients, this module allows the server to deliver messages
 that were previously queued for the newly online host.



Bug#963919: sniffglue: Cannot build sniffglue

2020-06-28 Thread Sylvestre Ledru
Package: sniffglue
Severity: important

Dear Maintainer,

The package cannot be build:

 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: librust-base64-0.11+default-dev:amd64

Sylvestre

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


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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



Bug#963916: rust-debcargo: Cannot build debcargo

2020-06-28 Thread Sylvestre Ledru
Source: rust-debcargo
Severity: important

Dear Maintainer,

I cannot build debcargo currently. It fails with:

missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: librust-cargo-0.43+default-dev:amd64

Thanks
Sylvestre


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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



Bug#963914: O: dhis-dns-engine -- Dynamic Host Information System - DNS engine

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the dhis-dns-engine package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package contains a dynamic DNS service module to be used
 with dhisd release 5 or above.
 .
 While the DHIS server dhisd retrieves dynamic IP addresses
 from clients, this module allows the server to update a
 dynamic DNS zone based on those retrieved IP addresses.



Bug#963911: O: coriander -- control IEEE1394 digital camera

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the coriander package.

This is a live camera viewer for Firewire and USB Vision cameras (mainly
industrial and scientific cameras, not webcams). It is not being
maintained upstream anymore, but it is otherwise functional.

The package description is:
 Coriander is a GUI that lets you view camera images and control all the
 features of an IEEE-1394 Digital Camera complying with the DC Specifications
 v1.04 or later (see http://www.1394ta.org).



Bug#963525: Bug#963721: Bug#963525, Bug#963721: libmount1 with libcryptsetup dependency

2020-06-28 Thread Chris Hofstaedtler
Simon,

* Simon McVittie  [200628 19:39]:
> Control: retitle 963525 steam: crashes with libmount version that depends on 
> libcryptsetup12
> 
> On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> > 1) Software that is not shipped by Debian and uses a statically
> > linked or private copy of libssl crashes, because libmount1 pulls 
> > in libssl1.1, transitively. This is quite clearly unsupported by
> > libssl. If anyone ships binaries for Debian, they need to either
> > link against Debian's libssl, or not use any of the system provided
> > libs.
> 
> If you consider this to be a bug in the proprietary Steam binaries rather
> than in libmount, then that's at least plausible, but please leave #963525
> open and with a reasonably descriptive title so that Steam users don't
> open duplicate bugs.

Sure! I was not going to touch #963525 - this mail was more a "heads
up".

(Dropping #963721 because now it's really unrelated.)

Chris



Bug#963910: O: blobwars -- platform shooting game

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the blobwars package.

This game has no active upstream developers, but it is in a very good
state. There are some minor bugs that could be fixed.

The package description is:
 Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob
 Wars series.
 .
 Since their world was invaded by an alien race, the Blobs have faced a
 lifetime of war. But now they have a chance to win the war once and for
 all.
 .
 In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob
 agent, Bob. Bob's mission is to infiltrate the various enemy bases around
 the Blobs' homeworld and rescue as many MIAs as possible. But standing in
 his way are many vicious aliens, other Blobs who have been assimilated and
 the evil alien leader, Galdov.
 Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob
 Wars series.
 .
 Since their world was invaded by an alien race, the Blobs have faced a
 lifetime of war. But now they have a chance to win the war once and for
 all.
 .
 In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob
 agent, Bob. Bob's mission is to infiltrate the various enemy bases around
 the Blobs' homeworld and rescue as many MIAs as possible. But standing in
 his way are many vicious aliens, other Blobs who have been assimilated and
 the evil alien leader, Galdov.



Bug#963909: O: blobandconquer -- 3D platform shooting game

2020-06-28 Thread Guus Sliepen
Package: wnpp
Severity: normal

I intend to orphan the blobandconquer package.

Due to the original game having undistributable music, sound and
graphics assets, this game is not very interesting to play. The upstream
developers are also not maintaining this game anymore. If you wish to
take over this package, some effort should be put into replacing all the
assets with DFSG-compatible ones. If there is no interest, I will ask
for removal of this package.

The package description is:
 Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars:
 Metal Blob Solid.
 .
 With the apparent defeat of Galdov and the reclaiming of the Fire,
 Time, Space and Reality Crystals the Blobs' battle was only just
 beginning. Bob had rescued many Blobs and fought many battles, but now
 he had an ever bigger task ahead of him. The Blobs' homeworld is still
 littered with the alien forces and Bob once again makes it his task to
 lead the counter attack. But even without Galdov the aliens are still
 extremely well organised...
 Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars:
 Metal Blob Solid.
 .
 With the apparent defeat of Galdov and the reclaiming of the Fire,
 Time, Space and Reality Crystals the Blobs' battle was only just
 beginning. Bob had rescued many Blobs and fought many battles, but now
 he had an ever bigger task ahead of him. The Blobs' homeworld is still
 littered with the alien forces and Bob once again makes it his task to
 lead the counter attack. But even without Galdov the aliens are still
 extremely well organised...



Bug#963895: libuno-cppu3: circular dependency hell

2020-06-28 Thread Rene Engelhard
Hi,

Am 28.06.20 um 19:40 schrieb Rene Engelhard:
> One can argue about the "ure" here.
> 
> 
> This comes from the .symbols and is - if I remember right - just there
> to have C++ stuff using those libs have the appropriate runtime
> dependencies.  (We don't have some right now, one in the past was
> libreoffice-voikko, though.)
> 
> Because those libraries in itself are totally useless without ure.

So, and after I did what I did in expertimental one gets: (random
package choosen):

$ debdiff libreoffice-evolution_7.0.0~rc1~git20200627-1_amd64.deb
libreoffice-evolution_7.0.0~rc1~git20200628-1_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: libreoffice-base, libreoffice-common, libreoffice-core (=
[-1:7.0.0~rc1~git20200627-1),-] {+1:7.0.0~rc1~git20200628-1),+}
libebook-1.2-20, ucf (>= 0.8), libc6 (>= 2.14), libgcc-s1 (>= 3.0),
libglib2.0-0 (>= 2.38.0), libstdc++6 (>= 5), libuno-cppu3 (>=
4.4.0~alpha), libuno-cppuhelpergcc3-3 (>= 4.0.0~alpha), libuno-sal3 (>=
5.1.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0), [-uno-libs-private,
ure-] {+uno-libs-private+}
Version: [-1:7.0.0~rc1~git20200627-1-] {+1:7.0.0~rc1~git20200628-1+}

OK, -core/-common depend on ure anyway, but...

Regards,

Rene



Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

2020-06-28 Thread Ross Vandegrift
[removing serpent@d.o from CC, he's resigned as delegate]

Hi Lucas,

On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote:
> One could argue that the Cloud team delegation does not cover Docker
> images.

Whether it does or not, I've been told that the docker image maintainers prefer
to keep their current organization and workflow.  I'd welcome their
participation in the team, if they were interested.  But I don't think they
need to be.

> But I think that it would be a nice addition to change the delegation to
> also include official images for virtualization environments such as
> Docker, LXC, Vagrant, as well as official images for SBC such as the
> Raspberry Pi (where it's often more convenient to boot a pre-built image
> than use the Debian installer).

Maybe it could be nice, if the people building those images want to use our
tools and work with us.  Some would raise concerns in my mind, but I don't
think it's useful to discuss before someone wants to build e.g. raspberry pi
images in cloud-team.

But it's also nice for people to provide images without us, or using different
tools.  The delegation only covers Debian-official cloud images.  And speaking
for myself: I don't feel the need to gather all other cloud-related or
image-related work under a this team.

Ross



Bug#963717: aerc embeds build path and can't find config files

2020-06-28 Thread ben

Hi,

thanks for the report! I've identified the problem and will
upload a fix in the coming days.

Best,
Ben



Bug#963785: gman: Search and viewing are inconsistant

2020-06-28 Thread Josip Rodin
On Fri, Jun 26, 2020 at 01:36:26PM -1000, Howard Johnson wrote:
> Also I'm seeing error messages in monitor I started it in.  I would think that
> I should not be seeing these.  (Example is below)

> $ gman
> P
> sh: $'0k\317G\265\177whatis': command not found

Hmm, if you just run whatis from console, does it work?

-- 
Josip Rodin



Bug#963907: bip: init integration does not actually stop bip

2020-06-28 Thread Antonio Terceiro
Package: bip
Severity: normal
Version: 0.9.0~rc3-1

I run bip as my IRC bouncer. Sometimes, it goes intro a frenzy consuming
all of the available CPU time (that will be a separate bug report), and
I need to restart it. However, trying to stop bip doesn't actually do
anything:

# systemctl stop bip
# pgrep -fa bip
5036 /usr/bin/bip -f /etc/bip/bip.conf -s /var/lib/bip
# systemctl status bip
● bip.service - Bip IRC Proxy
   Loaded: loaded (/lib/systemd/system/bip.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Mon 2020-06-22 11:41:11 -03; 6 days ago
  Process: 5033 ExecStartPre=/bin/sh -c [ $ENABLED != 0 ] (code=exited, 
status=0/SUCCESS)
  Process: 5034 ExecStart=/usr/bin/bip $DAEMON_ARGS (code=exited, 
status=0/SUCCESS)
 Main PID: 5035 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 2353)
   Memory: 5.5M
   CGroup: /system.slice/bip.service
   └─5036 /usr/bin/bip -f /etc/bip/bip.conf -s /var/lib/bip

Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.
#

The behavior is the same wether bip is consuming all CPU or not.


signature.asc
Description: PGP signature


Bug#795281: autofs: Please provide a mechanism to make automount root mount points shared

2020-06-28 Thread Sam Morris
Tags: patch

On Wed, Aug 12, 2015 at 04:37:04PM +0100, Ian Campbell wrote:
> As described in the final section of
> https://www.kernel.org/doc/Documentation/filesystems/autofs4.txt it is
> necessary to run "mount --make-shared /autofs/mount/point" on systems
> which make use of bind mounts and/or namespaces, or else things start
> spuriously failing with ELOOP.
> 
> Assuming that there is no desire to change the default then having an
> easy way to configure this would be very useful.

Fedora is carrying this patch:

https://src.fedoraproject.org/rpms/autofs/blob/master/f/autofs-5.1.6-make-bind-mounts-propagation-slave-by-default.patch

In addition to making 'slave' the default, it also adds a 'shared' mount
option.

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



Bug#963833: The sneaky deets

2020-06-28 Thread ItzSwirlz Joshua Peisach
Okay-so the option IS --disable-Werror, but you can't invoke it via 
dh_auto_configure.

dh_autoreconf is not responsible for this as the file is in ./configure.

dh_auto_configure automatically adds flags that I copied over using verbose and 
then added -disable-Werror flag in. This is what the new debian/rules 
override_dh_auto_configure looks like:

override_dh_auto_configure:
./configure --build=x86_64-linux-gnu \
--prefix=/usr \
--includedir=\${prefix}/include \
--mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info \
--sysconfdir=/etc --localstatedir=/var \
--disable-silent-rules \
--libdir=\${prefix}/lib/x86_64-linux-gnu \
--libexecdir=\${prefix}/lib/x86_64-linux-gnu \
--runstatedir=/run \
--disable-maintainer-mode \
--disable-dependency-tracking \
--disable-Werror

The diff will add that and update dependencies.


Bug#963906: ITP: ruby-aubio -- Ruby bindings for the aubio audio library

2020-06-28 Thread Valentin Vidic
Package: wnpp
Severity: wishlist
Owner: Valentin Vidic 

* Package name: ruby-aubio
  Version : 0.3.3
  Upstream Author : Xavier Riley 
* URL : https://github.com/xavriley/ruby-aubio
* License : MIT
  Programming Lang: Ruby
  Description : Ruby bindings for the aubio audio library

Aubio is a tool designed for the extraction of annotations from audio signals.
Its features include segmenting a sound file before each of its attacks,
performing pitch detection, tapping the beat and producing midi streams from
live audio.

This library is required as a dependency for the new version of the
sonic-pi package. The package will be maintained in the ruby-team
group on Salsa.



Bug#963900: ITP: node-decode-uri-component -- A Decode URI Component

2020-06-28 Thread Andrei POPESCU
Control: reassign -1 wnpp
Control: severity -1 wishlist
Control: owner -1 Abraham Raji 
Control: retitle -1 ITP: node-decode-uri-component -- A Decode URI Component

On Du, 28 iun 20, 18:08:17, Abraham Raji wrote:
> Package: wnppSeverity: wishlistOwner: Abraham Raji 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name    : node-tiptap
>   Version : 1.27.1
>   Upstream Author : 2019, Scrumpy UG (limited liability)
> * URL : https://github.com/scrumpy/tiptap/blob/master/README.md
> * License : Expat
>   Programming Lang: JavaScript
>   Description : A renderless and extendable rich-text editor for Vue.js
> 
> 
> This package is a dependency for hui-vue, pbpm, adminify, vue-butler and many 
> other node modules.
> .
> I intend to package this myself but I will need sponsorship to upload.

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#963902: ITP: node-tiptap -- A renderless and extendable rich-text editor for Vue.js

2020-06-28 Thread Andrei POPESCU
Control: reassign -1 wnpp
Control: severity -1 wishlist
Control: owner -1 Abraham Raji 
Control: retitle -1 ITP: node-tiptap -- A renderless and extendable rich-text 
editor for Vue.js

On Du, 28 iun 20, 18:12:12, Abraham Raji wrote:
> Package: wnppSeverity: wishlistOwner: Abraham Raji 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name    : node-tiptap
>   Version : 1.27.1
>   Upstream Author : 2019, Scrumpy UG (limited liability)
> * URL : https://github.com/scrumpy/tiptap/blob/master/README.md
> * License : Expat
>   Programming Lang: JavaScript
>   Description : A renderless and extendable rich-text editor for Vue.js
> 
> 
> This package is a dependency for hui-vue, pbpm, adminify, vue-butler and many 
> other node modules.
> .
> I intend to package this myself but I will need sponsorship to upload.

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#963080: chromium: crashing due to ffmpeg 4.3 update

2020-06-28 Thread Frederic MASSOT

Hi,

After updating my Bullseye system, chromium crashes as soon as there is 
a video.


I tried to downgrade ffmpeg with apt-get, but we only have access to 
versions 4.3 and 4.1, chromium requires 4.2 minimum.


The ffmpeg 4.2 packages are still available on Debian FTP: 
http://ftp.debian.org/debian/pool/main/f/ffmpeg/


ffmpeg_4.2.2-1+b1_amd64.deb
libavcodec-extra58_4.2.2-1+b1_amd64.deb
libavcodec-extra_4.2.2-1+b1_amd64.deb
libavcodec58_4.2.2-1+b1_amd64.deb
libavdevice58_4.2.2-1+b1_amd64.deb
libavfilter7_4.2.2-1+b1_amd64.deb
libavformat58_4.2.2-1+b1_amd64.deb
libavresample4_4.2.2-1+b1_amd64.deb
libavutil56_4.2.2-1+b1_amd64.deb
libpostproc55_4.2.2-1+b1_amd64.deb
libswresample3_4.2.2-1+b1_amd64.deb
libswscale5_4.2.2-1+b1_amd64.deb

You have to download them by hand, then install them with "dpkg -i".

Once Chromium is restarted, the videos are visible without crashing 
chromium.



Regards.
--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===



Bug#963895: libuno-cppu3: circular dependency hell

2020-06-28 Thread Rene Engelhard
found 963895 1:7.0.0~beta2-2

severity 963895 minor

reassign 963895
libuno-cppu3,libuno-sal3,libuno-cppuhelpergcc3-3,libuno-salhelpergcc3-3,uno-libs3,ure

retitle 963895 circular dependencies between
libuno-cppu3,libuno-sal3,libuno-cppuhelpergcc3-3,libuno-salhelpergcc3-3,uno-libs3,ure

thanks


[ And again you did it. Again by accussing people of carelessness and
not thinking and by using the words "dependency hell". There is no
dependency "hell" here.

Didn't we already have this the last time you came up with a "bug" like
this? ]


Hi,

Am 28.06.20 um 17:56 schrieb Bill Allombert:
> Package: libuno-cppu3

If this was a circular dependency, why only filed on this one?

If you file "bugs", please some care.

> Version: 1:6.4.5~rc1-2

Dead.

There will only be a update to 6.4.5-1 final next week and then 6.4.x
will be dead. Unstable will get 7.0.0 rc1.

And I simply will not rush something like this in for a last 6.4.x
upload, no, sorry.

> Severity: important

Wrong. Please tell me how this fits into

--- snip ---

1 important  a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.

--- snip ---

How does it have "a major effect on the usability of a package"?

The use of this package is at runtime, where everything is straight.

> There is a circular dependency between libuno-cppu3, libuno-cppuhelpergcc3-3, 
> libuno-purpenvhelpergcc3-3, libuno-salhelpergcc3-3, uno-libs-private and ure:
>
> libuno-cppu3  :Depends: libuno-salhelpergcc3-3 (>= 1.4.0), ure
> libuno-cppuhelpergcc3-3   :Depends: uno-libs-private (= 1:6.4.5~rc1-2), 
> libuno-cppu3 (>= 4.4.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0), ure
Unfortunately the public libuno_cppuhelpergcc3.so.3 depends on private
libs. (uno-libs-private). What are you expecting? Not declare that
dependency? That would be a policy violation.
> libuno-purpenvhelpergcc3-3:Depends: libuno-cppu3 (>= 1.4.0), ure
> libuno-salhelpergcc3-3:Depends: ure

One can argue about the "ure" here.


This comes from the .symbols and is - if I remember right - just there
to have C++ stuff using those libs have the appropriate runtime
dependencies.  (We don't have some right now, one in the past was
libreoffice-voikko, though.)

Because those libraries in itself are totally useless without ure.

> uno-libs-private  :Depends: libuno-cppu3 (>= 1.4.0), 
> libuno-salhelpergcc3-3 (>= 1.4.0), ure
> ure   :Depends: uno-libs-private (= 1:6.4.5~rc1-2), libuno-cppu3 (>= 
> 4.4.0~alpha), libuno-cppuhelpergcc3-3 (>= 4.0.0~alpha), 
> libuno-purpenvhelpergcc3-3 (>= 1.4.0), libuno-salhelpergcc3-3 (>= 3.6.0~beta)

These are simply not discussable since that are the actual library
dependencies.

The nature of private libs is that they are private.

One might merge uno-libs-private into ure, but I don't think that makes
sense.

Neither does merging all those libuno* somewhere else (packages of
public libraries should be named to that they change if the SONAME
changes, and lintian correctly complains about
package-name-not-matching-soname or however it it called.)

> Complex circular dependencies are known to cause problems during upgrade,

If said stuff is used during the upgrade.


None of these is. If apt broke the cycle up during update so what? After
the upgrade they will be present as intended.


Regards,


Rene



Bug#937442: pygame-sdl2: Python2 removal in sid/bullseye

2020-06-28 Thread peter green

severity 937442 serious
thanks

The cython binary package has been removed from testing. So pygame-sdl2 can no 
longer be built in testing



Bug#843835: UDD: expose an API for upstream versions to rmadison

2020-06-28 Thread Lucas Nussbaum
Hi Paul,

On 10/11/16 at 13:54 +0800, Paul Wise wrote:
> Package: qa.debian.org
> User: qa.debian@packages.debian.org
> Usertags: udd madison watch
> Severity: wishlist
> Control: affects -1 devscripts
> 
> It would be nice if the UDD watch file scanning service had a madison
> frontend that could be added to rmadison so that one could get the
> upstream version of a package from the command-line.

That would be easy. What should that API look like? Would returning all
the info for a given source package, as json, be enough?

Lucas


signature.asc
Description: PGP signature


Bug#693782: auto.master.d documentation

2020-06-28 Thread Sam Morris
On Tue, Nov 20, 2012 at 11:17:09AM +0100, Stefan Skoglund wrote:
> The documentation for how to use the 'auto.master.d' feature is really
> non-existing. What exists is a sketch from the designer for what it is
> (or how it should be.)

/etc/auto.master now has comments that describe how to use the feature:

# Include /etc/auto.master.d/*.autofs
# To add an extra map using this mechanism you will need to add
# two configuration items - one /etc/auto.master.d/extra.autofs file
# (using the same line format as the auto.master file)
# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS 
map)
# that is referred to by the extra.autofs file.
#
+dir:/etc/auto.master.d

For instance, I have the following:

$ cat /etc/auto.master.d/work.autofs
/workfile:/etc/auto.workbrowse

$ cat /etc/auto.work
server1-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser 
://server1.example.com/share1
server2-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser 
://server2.example.com/share1

In addition, auto.master(5) describes the + inclusion feature:

Additionally, a map may be included from its source as if it were itself
present in the master map by including a line of the form:

+[maptype[,format]:map options]

and automount(8) will process the map according to the specification
described below for map entries.

... the format of a master map entry:

mount-point [map-type[,format]:]map [options]

... and describes the 'dir' map-type:

This map type can be used at + master map including notation. The
contents of files under given directory are included to the master
map. The name of file to be included must be ended with ".autofs". A
file will be ignored if its name is not ended with the suffix. In
addition a dot file, a file which name is started with "." is also
ignored.

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



Bug#963525: , Bug#963721: libmount1 with libcryptsetup dependency

2020-06-28 Thread Simon McVittie
Control: retitle 963525 steam: crashes with libmount version that depends on 
libcryptsetup12

On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> 1) Software that is not shipped by Debian and uses a statically
> linked or private copy of libssl crashes, because libmount1 pulls 
> in libssl1.1, transitively. This is quite clearly unsupported by
> libssl. If anyone ships binaries for Debian, they need to either
> link against Debian's libssl, or not use any of the system provided
> libs.

If you consider this to be a bug in the proprietary Steam binaries rather
than in libmount, then that's at least plausible, but please leave #963525
open and with a reasonably descriptive title so that Steam users don't
open duplicate bugs.

I'm in contact with Valve about making the proprietary Steam binaries
more robust against system libraries that pull in OpenSSL, and have
suggested various possible routes. However, none of these are things we
can fix unilaterally in Debian: they require recompiling (or at least
relinking) the proprietary Steam client, which we are both legally and
technically unable to do.

I suspect this is likely to trigger brokenness in other binaries that
we can't fix, not just Steam, but let's see what happens...

Workarounds include:

- Hold back libmount1 until there's a better solution from Valve
- Install Steam via Flatpak or similar rather than using steam.deb
- Uninstall libglib2.0-0:i386, if you don't need it for other reasons
  (the most common reason to need it is 32-bit Wine)

smcv



  1   2   3   >