Bug#956502: docker: Error response from daemon: no status provided on response: unknown.

[Shengjing Zhu]

On Mon, Apr 13, 2020 at 12:05 PM Arnaud Rebillout
 wrote:
[...]
> It's unfortunate that upstream does not provide a source package for
> containerd.io, they only provide the binary package AFAIK.

Though the packaging source is not available, their CI scripts are there.
https://github.com/moby/moby/blob/19.03/hack/dockerfile/install/containerd.installer
It seems they just build from containerd upstream tree.

-- 
Shengjing Zhu

Bug#866171: this bug is still in gnome logs.

[Jaap Bosman]

I have same bug (Fedora 32)

Bug#950198: 950198

[Sébastien Delafond]

On 07/04 14:06, Alexandre Viau wrote:
> - https://bugs.debian.org/950198

Hi Alexandre,

I will look into Felix's packaging of restinio soon.

Cheers,

-- 
Seb

Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions

[Sébastien Delafond]

On 11/04 06:31, Nicholas D Steeves wrote:
> #947017 "ITP: org-drill" is blocked by this RFS (#954050) for a
> required dependency (persist-el).  Please sponsor at your earliest
> convenience to we can resume progress on getting org-drill back into
> Debian.

Hello,

I have very little bandwidth these days, so if Thomas has some to handle
this mentoring request, that would work out best. If not, I will try to
find some time next week-end to do a one-time review and upload of
persist-el. Thomas, can you let us know what you think?

Cheers,

-- 
Seb

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

[Arno van Amersfoort]

Upstream fix here: 
https://github.com/arno-iptables-firewall/aif/commit/d145f9b665ae3573055470cd45c750e63e7bebf6


On 12-04-2020 21:05, Julia Longtin wrote:

Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk 
"/tcp.*$service/"' { print $4 }' |uniq

this causes arno to fail to start if you have NFS services, and have turned 
this plugin on.

--- 90rpc.plugin~   2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@

echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"

-  IFS=' ,'
+  IFS=$" ,\n"
for service in $RPC_SERVICES; do
 ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
 echo "${INDENT}Adding TCP ports $ports for RPC service $service"

fixes it.

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

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

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.6.0-1
ii  iptables   1.8.4-3
ii  kmod   27-2
ii  procps 2:3.3.16-4

Versions of packages arno-iptables-firewall recommends:
ii  bind9-dnsutils [dnsutils]  1:9.16.1-2
ii  curl   7.68.0-1
ii  dnsutils   1:9.16.1-2
ii  rsyslog8.2002.0-2

arno-iptables-firewall suggests no packages.

-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin 
(from arno-iptables-firewall package)

Bug#956502: docker: Error response from daemon: no status provided on response: unknown.

[Shengjing Zhu]

On Mon, Apr 13, 2020 at 2:05 PM Arnaud Rebillout
 wrote:
>
> For what it's worth, I could rebuild containerd packages from the 1.2
> series, starting from [1] and iterating with different containerd versions.
>
> Starting from containerd version 1.2.7, the containerd binary produced
> works. So it looks like we're looking for a change between 1.2.6 and 1.2.7.
>
> A notable change between those two versions is the update of the
> dependency containerd-ttrpc.

But compared to docker.io 19.03.6+dfsg1-2 and 19.03.6+dfsg1-3, the
buildinfos[1] show that both used
golang-github-containerd-ttrpc-dev/0.0~git20190828.92c8520-2.

I'm afraid it's because of the changes in grpc libraries. But I have
no clue about it, since containerd is not using grpc, but ttrpc.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=amd64&ver=19.03.6%2Bdfsg1-2&stamp=1582680638&raw=0

https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=amd64&ver=19.03.6%2Bdfsg1-3&stamp=1586598671&raw=0

-- 
Shengjing Zhu

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

[Arno van Amersfoort]

Thanks for the report. We will fix it upstream as well. Please note that 
the patch you provided is not POSIX-compatible since $'\n' is not POSIX. 
The correct fix should be something like:

IFS=" ,
"

cheers,

Arno

On 12-04-2020 21:05, Julia Longtin wrote:

Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk 
"/tcp.*$service/"' { print $4 }' |uniq

this causes arno to fail to start if you have NFS services, and have turned 
this plugin on.

--- 90rpc.plugin~   2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@

echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"

-  IFS=' ,'
+  IFS=$" ,\n"
for service in $RPC_SERVICES; do
 ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
 echo "${INDENT}Adding TCP ports $ports for RPC service $service"

fixes it.

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

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

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.6.0-1
ii  iptables   1.8.4-3
ii  kmod   27-2
ii  procps 2:3.3.16-4

Versions of packages arno-iptables-firewall recommends:
ii  bind9-dnsutils [dnsutils]  1:9.16.1-2
ii  curl   7.68.0-1
ii  dnsutils   1:9.16.1-2
ii  rsyslog8.2002.0-2

arno-iptables-firewall suggests no packages.

-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin 
(from arno-iptables-firewall package)

Bug#592031: Unreproducible

[Bruno Kleinert]

Hi,

I didn't observe this bug anymore for some years. Hence, I close the
bug.

Cheers,
Bruno


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

Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)

[Andreas Tille]

Control: tags -1 pending
Control: reassign -1 minimap2
Control: retitle -1 "-flto flag breaks nanopolish"

Hamid, thanks a lot for your investigation.

Kind regards, Andreas.

-- 
http://fam-tille.de

Bug#956555: runc init hangs on reopening exec.fifo

[Shengjing Zhu]

On Mon, Apr 13, 2020 at 5:03 AM Jan Nordholz  wrote:
>
> Package: runc
> Version: 1.0.0~rc10+dfsg1-1
> Severity: normal
>
> Hi,
>
> I'm unable to run even the simplest Docker container on my system.
> Even doing 'docker build/run -it' on "FROM busybox:latest" results in
> 'runc init' getting stuck. This is what I get...
>
> =
> jan@p53:~/tmp$ docker run -it my:bb
> docker: Error response from daemon: no status provided on response: unknown.
> ERRO[0001] error waiting for container: context canceled
> =
>

I think it's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956502

Though we haven't figured out what's the root cause.

--
Shengjing Zhu

Bug#956567: libh2o-dev-common: uninstallable in Multi-Arch situation due to missing foreign declaration

[Matt Brown]

Package: libh2o-dev-common
Version: 2.2.5+dfsg2-2+deb10u1
Severity: serious
Justification: 8

Dear Maintainer,

https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages
states that an architecture all package which is used a dependency for an
Architecture: any package must set Multi-Arch: foreign on the depedency.
libh2o-dev-common does not do this currently, and therefore it prevents the
multi-arch installation of libh2o-dev as it cannot be used to satisfy the
dependency that package specifies.

E.g.

matt@web:~$ dpkg --print-architecture
amd64

matt@web:~$ sudo apt install libh2o-dev:armhf
[sudo] password for matt:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libh2o-dev:armhf : Depends: libh2o-dev-common:armhf (=
2.2.5+dfsg2-2+deb10u1) but it is not installable
E: Unable to correct problems, you have held broken packages.


I believe fixing this is as simple as adding Multi-Arch: foreign to the
control
file stanza for libh2o-dev-common.

Thanks!

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

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

Versions of packages libh2o-dev-common depends on:
ii  libh2o0.13  2.2.5+dfsg2-2+deb10u1

libh2o-dev-common recommends no packages.

libh2o-dev-common suggests no packages.

-- no debconf information

Bug#956520: libpango-1.0-0: The new package breaks certain packages like dropbox or Minecraft-launcher

[Christian Lützenkirchen]

On 12/04/2020 15:40, Simon McVittie wrote:

libpango1.0-0 was already a transitional package, since 2013 (a few days
more than 7 years ago). Transitional packages are normally removed in the
next stable release after they become transitional, so libpango1.0-0 was
already several years overdue for removal. Its removal was requested in
#940744 and #948462.

If libpango1.0-0 really needs to come back, it should probably be taken
over by the pangox-compat source package, so that it "naturally" goes away
when libpangox-1.0-0 does.



Hello,

thanks for the clarification. Though apt is having trouble to configure
these packages - the within delivered binaries seem to work fine. It is
probably up to Dropbox and Mojang etc. to alter their deb packages to
depend on libpango-1.0-0 instead.

For the meantime I will probably hack those packages myself or create a
temporary transitional package in order to prevent apt from removing
Dropbox every morning when I need to do the daily apt upgrade ;-) .
In case some of you have a better work around I'd love to hear it.

Additionally I will try to open a ticket at Dropbox and Minecraft
support for a tiny change request.


Best regards

Chris

Bug#956502: docker: Error response from daemon: no status provided on response: unknown.

[Arnaud Rebillout]

For what it's worth, I could rebuild containerd packages from the 1.2 
series, starting from [1] and iterating with different containerd versions.


Starting from containerd version 1.2.7, the containerd binary produced 
works. So it looks like we're looking for a change between 1.2.6 and 1.2.7.


A notable change between those two versions is the update of the 
dependency containerd-ttrpc.


[1]: 
https://salsa.debian.org/go-team/packages/containerd/-/commit/c9e2aa545934b326d7f81cb267369772ab51f3f7


On 4/13/20 10:58 AM, Arnaud Rebillout wrote:


On 4/12/20 7:49 PM, Chris Lamb wrote:

severity 956502 serious
thanks

Hi,

docker: Error response from daemon: no status provided on response: 
unknown.

This, too, happens for me. Downgrading to 19.03.6+dfsg1-2 (from
19.03.6+dfsg1-3) restores all functionality.

Marking as RC merely to prevent migration to bullseye (which still has
19.03.6+dfsg1-2).



Thanks!

So far I had some success by replacing the binary 
/usr/bin/docker-containerd by the one mentioned by upstream, either 
one of:


- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.10-3_amd64.deb
- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.10-2_amd64.deb


While the older version available on their mirror shows the same issue 
that we're hitting:


- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.6-3_amd64.deb


It's unfortunate that upstream does not provide a source package for 
containerd.io, they only provide the binary package AFAIK.



    ~~ For more understanding on this bug ~~

Note that Docker upstream uses two different versions of containerd:

- one version of containerd is used to build docker (ie. it's part of 
the dependency tree in the vendor/ directory). At the moment they use 
a commit that is on the master branch, somewhere between `v1.2.0` and 
`v1.3.0-beta.0`.


- another version of containerd is used to build the containerd 
binary, then is packaged as `containerd.io`, and is installed as a 
dependency of `docker.io`. This package is built from a tagged 
version, on the `release/1.2` branch. So it's kind of "stable".


While for Debian packaging, we use only the version that is mentioned 
in the vendor tree (so the commit from the master branch), for both 
purpose: building the docker package and also building the 
docker-containerd binary that is then installed along with docker.


So here I would say that we need to find a patch in containerd, that 
should be on the 1.2 branch. That's my best guess.

Bug#956566: Noveau freezes randomly with GT215M (GeFORCE 335M) chipset

[Dramon Conte]

Noveau freezes randomly including the mouse pointer and I can't switch to
text mode (crtl+shift+Fn) to shut down. I need to restart the system with
power off buton. With Nvidia proprietary driver it's works fine (GT215M
GeFORCE 335M). I'm using XFCE4 with xfw4 window's manager but I tested with
XFCE4 with compiz and it's still freenzing every fourty or fifty minutes.

Bug#953996: julia: FTBFS on ppc64el

[Graham Inggs]

Control: severity -1 important

Downgrading severity since julia was removed on ppc64el.

Bug#731459: Can't reproduce anymore but volume not changed

[Bruno Kleinert]

Hi,

I tried to reproduce today and the symptom changed: It is possible now
to create CUE/BIN images with the normalization plugin enable for more
than 1 track. However, the normalization plugin does nothing.

To reproduce, I created a loud and a silent Ogg Vorbis file in Audacity
and had brasero create an audio CUE/BIN image with the normalization
plugin enabled. I extracted the WAV files with bchunk -w -s foo.bin
foo.cue test and the WAV files had the volume levels of the input Ogg
Vorbis files.

I suggest to change the bug title to "Normalization plugin does not
change audio volumes".

Cheers,
Bruno


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

Bug#956566: xserver-xorg-video-nouveau: Noveau freezes randomy with GT215M (GeFORCE 335M) chipset

[Dramon Conte]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT215M [GeForce GT 
335M] [10de:0caf] (rev a2)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 67686 Apr 12 18:42 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 67321 Apr 13 00:55 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   228.963] 
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[   228.963] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian
[   228.963] Current Operating System: Linux lgdramon 5.2.0-2-amd64 #1 SMP 
Debian 5.2.9-2 (2019-08-21) x86_64
[   228.963] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=8712cf56-891b-4f3b-b948-eddd47936447 ro quiet
[   228.963] Build Date: 31 March 2020  10:14:40AM
[   228.963] xorg-server 2:1.20.8-2 (https://www.debian.org/support) 
[   228.963] Current version of pixman: 0.36.0
[   228.963]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   228.963] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   228.963] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 13 00:54:23 
2020
[   229.334] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   229.480] (==) No Layout section.  Using the first Screen section.
[   229.480] (==) No screen section available. Using defaults.
[   229.480] (**) |-->Screen "Default Screen Section" (0)
[   229.480] (**) |   |-->Monitor ""
[   229.533] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   229.533] (==) Automatically adding devices
[   229.534] (==) Automatically enabling devices
[   229.534] (==) Automatically adding GPU devices
[   229.534] (==) Max clients allowed: 256, resource mask: 0x1f
[   229.621] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   229.621]Entry deleted from font path.
[   229.716] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   229.716] (==) ModulePath set to "/usr/lib/xorg/modules"
[   229.716] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   229.716] (II) Loader magic: 0x562279aede20
[   229.716] (II) Module ABI versions:
[   229.716]X.Org ANSI C Emulation: 0.4
[   229.716]X.Org Video Driver: 24.1
[   229.716]X.Org XInput driver : 24.1
[   229.716]X.Org Server Extension : 10.0
[   229.717] (++) using VT number 7

[   229.717] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[   229.718] (II) xfree86: Adding drm device (/dev/dri/card0)
[   229.723] (--) PCI:*(1@0:0:0) 10de:0caf:1854:0832 rev 162, Mem @ 
0xd200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x4000/128, BIOS @ 0x/131072
[   229.723] (II) LoadModule: "glx"
[   229.817] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   230.572] (II) Module glx: vendor="X.Org Foundation"
[   230.572]compiled for 1.20.8, module version = 1.0.0
[   230.572]ABI class: X.Org Server Extension, version 10.0
[   230.699] (==) Matched modesetting as autoconfigured driver 0
[   230.700] (==) Matched fbdev as autoconfigured driver 1
[   230.700] (==) Matched vesa as autoconfigured driver 2
[   230.700] (==) Assigned the driver to the xf86ConfigLayout
[   230.700] (II) LoadModule: "modesetting"
[   230.700] (II) Loading /usr/lib/xorg/modules/drivers/modesetting

Bug#956502: docker: Error response from daemon: no status provided on response: unknown.

[Arnaud Rebillout]

On 4/12/20 7:49 PM, Chris Lamb wrote:

severity 956502 serious
thanks

Hi,


docker: Error response from daemon: no status provided on response: unknown.

This, too, happens for me. Downgrading to 19.03.6+dfsg1-2 (from
19.03.6+dfsg1-3) restores all functionality.

Marking as RC merely to prevent migration to bullseye (which still has
19.03.6+dfsg1-2).



Thanks!

So far I had some success by replacing the binary 
/usr/bin/docker-containerd by the one mentioned by upstream, either one of:


- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.10-3_amd64.deb
- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.10-2_amd64.deb


While the older version available on their mirror shows the same issue 
that we're hitting:


- 
https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/containerd.io_1.2.6-3_amd64.deb


It's unfortunate that upstream does not provide a source package for 
containerd.io, they only provide the binary package AFAIK.



    ~~ For more understanding on this bug ~~

Note that Docker upstream uses two different versions of containerd:

- one version of containerd is used to build docker (ie. it's part of 
the dependency tree in the vendor/ directory). At the moment they use a 
commit that is on the master branch, somewhere between `v1.2.0` and 
`v1.3.0-beta.0`.


- another version of containerd is used to build the containerd binary, 
then is packaged as `containerd.io`, and is installed as a dependency of 
`docker.io`. This package is built from a tagged version, on the 
`release/1.2` branch. So it's kind of "stable".


While for Debian packaging, we use only the version that is mentioned in 
the vendor tree (so the commit from the master branch), for both 
purpose: building the docker package and also building the 
docker-containerd binary that is then installed along with docker.


So here I would say that we need to find a patch in containerd, that 
should be on the 1.2 branch. That's my best guess.

Bug#956564: liquidsoap libraries are not installed in the right place

[Cole Anthony Capilongo]

Package: liquidsoap
Version: 1.4.1-1
Severity: important

Dear Maintainer,

The liquidsoap packages comes with several libraries as .liq files, called 
"pervasive script libraries".
The Debian package for liquidsoap installs these libraries to 
/usr/share/liquidsoap/libs/,
but liquidsoap doesn't look for these libraries there. This can be seen when 
one runs `liquidsoap --help`:

```
  --no-pervasives 
  Do not load pervasives script libraries (i.e.,
  /usr/share/liquidsoap/1.4.1/libs/*.liq).
```

It looks for those libraries in a different folder, based on the version of 
liquidsoap installed.
This means the default setup of the Debian package will not allow basic 
liquidsoap functions like
`mksafe` to be used without manually copying or symlinking the library folder.
Personally, my quick solution was:
```
sudo mkdir /usr/share/liquidsoap/1.4.1
sudo ln -s /usr/share/liquidsoap/libs /usr/share/liquidsoap/1.4.1/
```

Thank you!

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

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

Versions of packages liquidsoap depends on:
ii  adduser3.118
ii  curl   7.64.0-4+deb10u1
ii  libao4 1.2.2+20180113-1
ii  libasound2 1.1.8-1
ii  libavcodec-extra58 [libavcodec58]  7:4.2.2-1+b1
ii  libavdevice58  7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.30-4
ii  libcamomile-ocaml-data 1.0.2-2
ii  libexif12  0.6.21-6
ii  libfaad2   2.9.1-1
ii  libflac8   1.3.2-3
ii  libgavl1   1.4.0-5
ii  libgcc-s1 [libgcc1]10-20200324-1
ii  libgcc11:8.3.0-6
ii  libgd3 2.2.5-5.2
ii  libgif75.1.4-3
ii  libglib2.0-0   2.64.1-1
ii  libgstreamer-plugins-base1.0-0 1.16.2-4
ii  libgstreamer1.0-0  1.16.2-2
ii  libjack-jackd2-0 [libjack-0.125]   1.9.12~dfsg-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblo7 0.30-3
ii  libmad00.15.1b-10
ii  libmagic1  1:5.35-4+deb10u1
ii  libmp3lame03.100-2+b1
ii  libogg01.3.2-1+b1
ii  libopus0   1.3-1
ii  libpcre3   2:8.39-12
ii  libpng16-161.6.36-6
ii  libportaudio2  19.6.0-1
ii  libpulse0  12.2-4+deb10u1
ii  libsamplerate0 0.1.9-2
ii  libsdl-image1.21.2.12-12
ii  libsdl-ttf2.0-02.0.11-6
ii  libsdl1.2debian1.2.15+dfsg2-5
ii  libshine3  3.1.1-2
ii  libsoundtouch1 2.1.2+ds1-1
ii  libspeex1  1.2~rc1.2-1+b2
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libstdc++6 8.3.0-6
ii  libswresample3 7:4.2.2-1+b1
ii  libswscale57:4.2.2-1+b1
ii  libtag1v5  1.11.1+dfsg.1-0.3+b1
ii  libtheora0 1.1.1+dfsg.1-15
ii  libtiff5   4.1.0+git191117-2~deb10u1
ii  libvorbis0a1.3.6-2
ii  libvorbisenc2  1.3.6-2
ii  libvorbisfile3 1.3.6-2
ii  libxpm41:3.5.12-1
ii  ocaml-base-nox 4.08.1-8
ii  sox14.4.2+git20190427-2

Versions of packages liquidsoap recommends:
ii  logrotate 3.14.0-4
ii  vorbis-tools  1.4.0-11
ii  vorbisgain0.37-2+b1

Versions of packages liquidsoap suggests:
pn  festival
ii  icecast22.4.4-1
pn  mplayer 
pn  youtube-dl  

-- no debconf information

Bug#845616: Please suggest gnome-shell-extension-appindicator

[Bruno Kleinert]

Hi,

as some time has passed, I retried today on sid: Sparkleshare still
only works with gnome-shell-extension-appindicator on GNOME 3, i.e.,
that is the only possibility for users to control Sparkleshare while it
is running.

As /usr/share/doc/sparkleshare/README.md mentions Sparkleshare uses the
AppIndicator interface by default (while the documented alternative
unfortunately does not work on GNOME 3), please make the sparkleshare
binary package suggest gnome-shell-extension-appindicator.

Cheers,
Bruno


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

Bug#956565: fish_config requires python3-distutils, but it is not a dependency

[Piper McCorkle]

Package: fish
Version: 3.1.0-1.1
Severity: normal
Tags: patch

Trying to run fish without python3-distutils installed results in the 
following error:

$ fish_config
Traceback (most recent call last):
  File "/usr/share/fish/tools/web_config/webconfig.py", line 11, in 
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'

Installing python3-distutils resolves this issue.



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

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

Versions of packages fish depends on:
ii  bc 1.07.1-2+b2
ii  dpkg   1.19.7
ii  firefox-esr [www-browser]  68.7.0esr-1
ii  fish-common3.1.0-1.1
ii  konqueror [www-browser]4:19.08.2-2+b1
ii  libc6  2.30-4
ii  libpcre2-32-0  10.34-7
ii  libstdc++6 10-20200410-1
ii  libtinfo6  6.2-1
ii  lynx [www-browser] 2.9.0dev.5-1
ii  man-db 2.9.1-1
ii  python33.8.2-3

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information>From d3ac2aa91547fe359e00efc5c975e8e25a95e2f7 Mon Sep 17 00:00:00 2001
From: Piper McCorkle 
Date: Sun, 12 Apr 2020 20:20:14 -0700
Subject: [PATCH] Depend on python3-distutils so fish_config works

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index de881f1..efb07a3 100644
--- a/debian/control
+++ b/debian/control
@@ -31,6 +31,7 @@ Depends: bc,
  lynx | www-browser,
  man-db,
  python3,
+ python3-distutils,
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: xsel
-- 
2.26.0



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

Bug#956563: qemu-kvm: iPhone USB passthrough crashes Windows 10 guest

[Hank Knox]

Package: qemu-kvm
Version: 1:4.2-3
Severity: normal

Dear Maintainer,

On a Debian Bullseye host running Windows 10 as a guest:
Plugging an iPhone 6 into the USB port and Redirecting the device to the VM
causes Windows 10 to crash every time.
Plugging a USB drive into the USB port and redirecting the device to the VM
works fine for a Windows 10 guest.



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

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

Versions of packages qemu-kvm depends on:
ii  qemu-system-x86  1:4.2-3

qemu-kvm recommends no packages.

qemu-kvm suggests no packages.

-- no debconf information

Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

[Nicholas D Steeves]

Hi Ben,

Ben Finney  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Ben Finney 
>
> * Package name: elpa-page-break-lines
>   Version : 0.11
>   Upstream Author : Steve Purcell 
> * URL : https://github.com/purcell/page-break-lines
> * License : GPL-3+
>   Programming Lang: Emacs Lisp
>   Description : Emacs mode to display ugly ^L page breaks as tidy 
> horizontal lines
>   This library provides an Emacs mode which displays form feed
>   characters as horizontal rules.
>   .
>   The U+000C FORM FEED character is a normal white-space character, and
>   in a text file is often used to mark virtual “page” separation.
>   .
>   Though it is rendered invisibly as white space, Emacs will (like many
>   text editors) represent it with a glyph such as “^L”. This Emacs mode
>   allows the same character to instead display as a custom horizontal
>   line.
>
> I have found this package useful and would like to make it available
> in Debian. If the Debian Emacs addons team are willing, this could be
> maintained there, otherwise I will maintain it myself.
>

Sorry for the long delay replying; it looks like no one on the team saw
this bug.  Are you still interested in packaging page-break-lines and
maintaining it in on the Emacsen Team, or would you like to treat it as
an RFP?  Were you to want to package it, please man DH-MAKE-ELPA(1) :-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#952336: photocollage: FTBFS: dh: error: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 mo

[Logan Rosen]

Package: photocollage
Version: 1.4.3-2.1
Followup-For: Bug #952336
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

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

  * Build-depend on dh-python to fix FTBFS due to missing python3.pm.

Thanks for considering the patch.

Logan

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

Kernel: Linux 5.4.0-21-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru photocollage-1.4.3/debian/control photocollage-1.4.3/debian/control
--- photocollage-1.4.3/debian/control   2018-12-21 16:49:53.0 -0500
+++ photocollage-1.4.3/debian/control   2020-04-12 22:26:53.0 -0400
@@ -4,6 +4,7 @@
 Maintainer: Adrien Vergé 
 Build-Depends:
  debhelper (>=9),
+ dh-python,
  gettext,
  python3-all,
 Standards-Version: 3.9.8

Bug#938752: unbound: Python2 removal in sid/bullseye

[Stuart Prescott]

Control: tags -1 + patch

Dear maintainers,

unbound can now drop its Python 2 module package as there are no users of that 
package left in bullseye.

I've just opened a merge request on salsa to do so:

https://salsa.debian.org/dns-team/unbound/-/merge_requests/8

thanks
Stuart

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

Bug#899533: hash-slinger: Invalid maintainer address pkg-dns-de...@lists.alioth.debian.org

[Stuart Prescott]

Hi Ondřej,

src:hash-slinger seems to have been pseudo-orphaned during the move from 
alioth to salsa; the maintainer email address no longer works, the VCS was not 
copied across to salsa and hash-slinger was removed from testing 21 months 
ago. 

Upstream, the package has moved from the URL listed in d/copyright and some 
porting work to Python 3 seems to have been done.

Is this package still useful and should it be upgraded to the 3.0 release from 
upstream? Or alternatively, should this package be removed from Debian?

regards
Stuart

[1] Upstream releases have moved to github.com
http://people.redhat.com/pwouters/hash-slinger/
https://github.com/letoams/hash-slinger

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

Bug#956497: ristretto: 25 seconds delay when org.Xfce.FileManager isn't available

[Daniel Shahaf]

Control: retitle -1 ristretto: 25 seconds delay when org.Xfce.FileManager isn't 
available

Daniel Shahaf wrote on Sun, Apr 12, 2020 at 03:59:07 +:
>   I captured a backtrace (from a different ristretto run, because lldb
>   failed to attached to the strace'd run):
> 
>   * thread #1, name = 'ristretto', stop reason = signal SIGSTOP
> * frame #0: 0x76ba0819 
> libc.so.6`__GI___poll(fds=0x55648720, nfds=1, timeout=25000) at 
> poll.c:29 
>
>   frame #1: 0x7762b136 
> libglib-2.0.so.0`___lldb_unnamed_symbol193$$libglib-2.0.so.0 + 374

Oops, I overlooked the library's dbgsym package.  Here's a more complete
backtrace:

* thread #1, name = 'ristretto', stop reason = signal SIGSTOP
  * frame #0: 0x76ba0819 libc.so.6`__GI___poll(fds=0x55646b30, 
nfds=1, timeout=25000) at poll.c:29
frame #1: 0x7762b136 libglib-2.0.so.0`g_main_context_iterate at 
gmain.c:4221
frame #2: 0x7762b110 
libglib-2.0.so.0`g_main_context_iterate(context=0x55647af0, 
block=, dispatch=1, self=) at gmain.c:3915
frame #3: 0x7762b4c2 
libglib-2.0.so.0`g_main_loop_run(loop=0x55647880) at gmain.c:4116
frame #4: 0x778a1b53 
libgio-2.0.so.0`initable_init(initable=0x5562a5f0, 
cancellable=0x, error=0x) at gdbusproxy.c:1950
frame #5: 0x778118c2 
libgio-2.0.so.0`g_initable_new_valist(object_type=, 
first_property_name="g-flags", var_args=0x7fffe180, 
cancellable=0x, error=0x) at ginitable.c:248
frame #6: 0x77811979 
libgio-2.0.so.0`g_initable_new(object_type=, 
cancellable=, error=, 
first_property_name=) at ginitable.c:162
frame #7: 0x778a34fc 
libgio-2.0.so.0`g_dbus_proxy_new_for_bus_sync(bus_type=G_BUS_TYPE_SESSION, 
flags=G_DBUS_PROXY_FLAGS_NONE, info=0x, 
name="org.xfce.FileManager", object_path="/org/xfce/FileManager", 
interface_name="org.xfce.FileManager", cancellable=0x, 
error=0x) at gdbusproxy.c:2257
frame #8: 0x55575ef5 
ristretto`rstto_main_window_init(window=0x555d9260) at main_window.c:809
frame #9: 0x77730107 
libgobject-2.0.so.0`g_type_create_instance(type=) at gtype.c:1864
frame #10: 0x77712548 
libgobject-2.0.so.0`g_object_new_internal(class=0x55627080, 
params=0x, n_params=0) at gobject.c:1805
frame #11: 0x77713cc5 
libgobject-2.0.so.0`g_object_new_with_properties(object_type=93824992996720, 
n_properties=0, names=0x, values=0x) at 
gobject.c:1973
frame #12: 0x77714731 
libgobject-2.0.so.0`g_object_new(object_type=, 
first_property_name=) at gobject.c:1645
frame #13: 0x55578f5a 
ristretto`rstto_main_window_new(image_list=0x555a95a0, fullscreen=0) at 
main_window.c:1263
frame #14: 0x55566c74 ristretto`main(argc=, 
argv=) at main.c:134
frame #15: 0x76ad609b 
libc.so.6`__libc_start_main(main=(ristretto`main at main.c:86), argc=1, 
argv=0x7fffe828, init=, fini=, 
rtld_fini=, stack_end=0x7fffe818) at libc-start.c:308
frame #16: 0x55566e0a ristretto`_start + 42

I used dbus-send(1) [1] to list the available DBus services.  The
"org.xfce.FileManager" service is available when I run ristretto under
xfce but not available when I run ristretto under openbox.  However, if
I use openbox and run —
.
% thunar&
[1] 8868
% ristretto
.
— in an empty directory, then ristretto starts with no delay.

I added «thunar --daemon &» to my .xinitrc and the delay does not occur
any more.

I suppose all that remains is to improve the startup behaviour when the
"org.xfce.FileManager" service isn't available — for example, by
shortening the delay, or adding a progress dialog, etc..

Thanks,

Daniel

[1] «dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus 
org.freedesktop.DBus.ListNames»

Bug#944616:

[Rob Browning]

Nick Gasson  writes:

> I had a look at this. It's possible to reproduce the failure inside
> qemu-mipsel-static. The test set-process-filter-t is fundamentally racy:
> it reads output from a sub-process and compares that to an expected
> value. But on a slow machine it's possible to get a partial read from
> the child process which causes the test to fail. I don't think it's
> anything related to MIPS per se.
>
> This has already been fixed upstream. See here:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit?id=aa49aa884053d0e8b33efe265f2aade19d1f3f3d
>
> Maybe we can import the above patch or mark this test as unstable?

Thanks much for he investigation.  I'll see about doing something like
that in the next upload.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#955604: gulkan: unsatisfiable Build-Depends on s390x

[李健秋]

Source: gulkan
Followup-For: Bug #955604


Hi,

gulkan builds now on s390x:
 
https://buildd.debian.org/status/fetch.php?pkg=gulkan&arch=s390x&ver=0.14.0-2&stamp=1586175154&raw=0

Best regards,
-Andrew

Bug#883155: fixed in inkscape 1.0~beta1+ds-1

[Sandro Tosi]

Hey Mattia,

> Format: 1.8
> Date: Fri, 04 Oct 2019 23:08:14 +0200
> Source: inkscape
> Architecture: source
> Version: 1.0~beta1+ds-1
> Distribution: experimental
> Urgency: low
> Maintainer: Debian Multimedia Maintainers 
> Changed-By: Mattia Rizzolo 
> Closes: 883155 933678 933688
> Changes:
>  inkscape (1.0~beta1+ds-1) experimental; urgency=low
>  .
>* New upstream version 1.0~beta1.  Closes: #933678
>  http://wiki.inkscape.org/wiki/index.php/Release_notes/1.0
>  https://inkscape.org/release/inkscape-1.0beta1/
>  + Also include the extensions.  Closes: #933688
>* Drop the Drop_PS_and_PDF_support_in_MimeType patch.
>  This was added without any real satisfying explanation many years ago,
>  and I could figure why anybody would want this.
>  Let's stop this unjustified divergence from upstream.
>* Add back Marc Jeanmougin's upstream key.
>* Drop all patches, mostly applied upstream.
>* Move everything from Python2 to Python3.  Closes: #883155
>  + d/p/python3: Add patch to call python3 instead of python while 
> building.
>* d/control: Update Build-Depends.
>* Bump debhlper compat level to 12.
>* Remove an extension that work only on Windows.  #930154

How close do you think we are to uploading inkscape with "Move
everything from Python2 to Python3.  Closes: #883155" to unstable
(even in a 1.0 beta status)?

We are at a point where we can remove
python-bs4+python-soupsieve+python-html5lib+pyhton-lxml (which is a
closed set and needs to go at the same time) but that would break
inkscape, which Recommends python-lxml.

inkscape in unstable already has a missing Recommends (python-scour)
but i'm not sure how much breakage would cause if we remove
python-lxml too.

Can you give us your take on this? tbh i'd like to proceed with the 4
packages removal mentioned above rather quickly, as they are blocking
several other packages from removal.

Thanks,
Sandro

Bug#956562: ITP: ruby-rexml -- XML toolkit for Ruby

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-rexml
  Version : 3.2.4
  Upstream Author : Yukihiro Matsumoto
* URL : https://github.com/ruby/rexml
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : XML toolkit for Ruby

REXML was inspired by the Electric XML library for Java, which features an
easy-to-use API, small size, and speed. Hopefully, REXML, designed with the
same philosophy, has these same features. It supports both tree and stream
document parsing. Stream parsing is faster (about 1.5 times as fast). However,
with stream parsing, one doesn't get access to features such as XPath.


The gem has been split out of Ruby's standard library and needs packaging.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6Tn5UACgkQS80FZ8KW
0F2PzxAApIjXjZdbcM/Z5QNhV/m2fIMlg5VkhV4KdM4Hdhar2111fQ5/utGGCnkl
QgCbVtbr/TTj/ksOlwaTXAhFgzNnjcjzvfwVTwiAQPnV3MJQADLo9XQumjbA/KDu
nBwZCrQe0C6J0CkUAKF6LZBieP1qBm9M5ijLs5W/K9XHfOUidCxaCBi+xR97jHYt
9xydHIvGVvEOiZ2bTOjkP1Bo0BFaYeznQw6Vs/5VyBj8iUG80mNRj8HlisQQMhrl
BEEt8N77rQv1VCqmJEoIlLMQks3NCtmPgrTOLvYHQSaJF5nSXzHfobFXN2PMAzF3
C3AZad60xZW1imTcgYYrJkXb3j3ptDggevyxQ9obc+u+S1qd79v/uKD9cB5G6Rzm
VKqzinXGS/kNVlErBQSDPrR1hX2PbKhVu6kj9hD6glrv74vZ3bn9UpdK9U84bC7J
tmfSNWb/+6aJfIsytMwBpvQ7mQAFp8dzRg5sp+t3x37B9SDft6z8ka209XpsyL1T
cB9sAy8brGdlVlYwC47azTVdp+/hqn5DMNzrTMELAbEY2jrEjO3g4ZbxUdGnrv6B
HFD2SnafN13hWRrRZOz1BL5pQ7cNASH3ME5Omg/+tDViCHCFJtBs9RZdmssHBAbD
XV+4l6ooAQiaJQb3i2rUdn0bYoEmPJy2elTYw0b6/8SOVQzLmOo=
=PDx8
-END PGP SIGNATURE-

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

[Sven Geuer]

Hi Julia,

Thank you for filing this bug.

In addition, could you please attach a sample output of 'rpcinfo -p' to
have the full picture of why this happens?

Regards,
Sven


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

Bug#952470:

[Chris Putnam]

I was hit again by this today. In the current state, Netdata is completely
broken when it tries to send an email. I have to manually edit the systemd
file, which is clobbered by any apt upgrades. I had unattended-upgrades on
a bit aggressively and today Netdata broke again, as 1.19.0-3 was pulled
in. Because the systemd file is (correctly) not flagged as a config file,
it was replaced. Then as soon as netdata tried to send an email, it was
broken again.

In my case I am using postfix instead of exim, but the issue is similar.
Netdata needs r/w access to the mail queue to send mail.

This was originally brought up in #851852. It seems it was fixed in 1.5.0
(?) and has regressed at some point since then.

Thank you for maintaining this package!

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Balint Reczey]

Hi Michael,

On Sun, Apr 12, 2020 at 7:58 PM Michael Biebl  wrote:
>
> Am 12.04.20 um 19:40 schrieb Balint Reczey:
> > Hi Michael,
> >
> > On Sat, Apr 11, 2020 at 9:53 PM Michael Biebl  wrote:
> >>
> >> Am 11.04.20 um 10:02 schrieb luca:
> >>> Package: systemd-timesyncd
> >>> Version: 245.4-3
> >>> Severity: normal
> >>>
> >>>
> >>> # apt-get -V dist-upgrade
> >>> Reading package lists... Done
> >>> Building dependency tree
> >>> Reading state information... Done
> >>> Calculating upgrade... Done
> >>> The following packages were automatically installed and are no longer 
> >>> required:
> >>>libnotify-bin (0.7.9-1)
> >>>libqpdf26 (9.1.1-1)
> >>> Use 'apt autoremove' to remove them.
> >>> The following packages will be REMOVED:
> >>>virtualbox-guest-utils (6.1.4-dfsg-4)
> >>>virtualbox-guest-x11 (6.1.4-dfsg-4)
> >>
> >> Balint, I guess we should drop
> >> Conflicts: virtualbox-guest-utils,
> >>virtualbox-guest-utils-hwe
> >> ?
> >
> > Ah, yes, sorry, I did think about that, but forgot to propose the
> > solution in the MR.
> >
> > IMO systemd-timesyncd should be the default time-daemon but also the
> > least preferred option to install, when some other installed package
> > can sync the time.
> >
> > I think the cleanest solution would be virtualbox source building a
> > binary package that Conflicts/Provides/Replaces: time-daemon and sets
> > up time synchronisation with the host (
> > https://www.virtualbox.org/manual/ch09.html#changetimesync )
>
> Nod, I think that package actually is virtualbox-guest-utils?

Virtualbox-guest-utils ships other utils which could be useful even if
time synchronization should be done by a proper time-daemon, so a new
binary package could make sense, but virtualbox-guest-utils can indeed
just that package as well.

>
> > If this solution is not viable, then I think the second best option is
> > considering virtualbox-guest-utils as a time-daemon alternative:
> >
> > AFAIK when virtualbox-guest-utils* is installed the guest's clock can
> > be considered to be synchronised to the host and hopefully
> > transitively to a reasonably good source, so I propose changing
> > systemd instead to depend on systemd-timesyncd | time-daemon |
> > virtualbox-guest-utils | virtualbox-guest-utils-hwe.  This solution
> > has the disadvantage of not being able to install systemd-timesyncd
> > when virtualbox-guest-utils is present, but should not sync time with
> > the host. IMO this is not a huge problem, since other time-daemon-s
> > can still be installed such as chrony, so the guest can still have
> > accurate time, just not with systemd-timesyncd.
>
> I would prefer not to add virtualbox-guest-utils* as an alternative
> Depends.
>
> > Cheers,
> > Balint
> >
> > PS: virtualbox-guest-utils is in contrib, but per #681419 it can still
> > be used as an alternate dependency.
>
> I guess I'll drop the conflicts and clone/reassign this bug report to
> virtualbox and leave it up to them to decide if it should be possible to
> install an NTP client alongside virtualbox-guest-utils* or not (and if
> the latter, to add a C/R/P: time-daemon)

Thanks, that's fair.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#956561: RFS: memo/1.7.1-1 [ITP] -- unix-style note-taking software

[Francisco]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : memo
Version : 1.7.1-1
Upstream Author : Niko Rosvall 
* URL : https://github.com/nrosvall/memo
* License : GPL-3+
* Vcs : https://salsa.debian.org/francisco-guest/memo
Section : utils

It builds those binary packages:

memo - unix-style note-taking software

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/m/memo/memo_1.7.1-1.dsc

Changes since the last upload:

* Initial release (Closes: #955462)

Regards,

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#956553: blurry notifications in gnome 3.36

[jnqnfe]

Control: forwarded -1 https://github.com/jnsh/arc-theme/issues/31

I did test and confirm not present in adwaita, just forgot to mention,
sorry.

Reported upstream.

On Sun, 2020-04-12 at 21:15 +0100, David Mohammed wrote:
> Please test with adwaita.
> 
> If notifications are still blurred with adwaita then its not a theme
> issue.
> 
> If notifications are blurred only with arc theme then please report
> this to the upstream issue tracker - 
> https://github.com/jnsh/arc-theme
> 
> On Sun, 12 Apr 2020 at 21:03,  wrote:
> > Package: arc-theme
> > Version: 20190917+git20200328-1
> > 
> > Notifications, such as new email received, are now blurry for me
> > after
> > the gnome 3.36 update.
> > 
> > Example attached.
> > 
> > I have a Hi-DPI screen.
> > 
> > Relevant (?) font config from tweak tool:
> >  - interface: cantarell regular 11
> >  - hinting: slight
> >  - antialiasing: subpixel
> >  - scaling factor: 1.00
> > 
> > Hi-DPI scaling factor is set to 2 somewhere. Ah, settings >
> > displays >
> > scale: 200%

Bug#956560: Please backport jwcrypto to buster

[Enrico Zini]

Package: python3-jwcrypto
Version: 0.6.0-2
Severity: wishlist

Hello,

thanks for packaging jwcrypto!

The package from testing seems to install just fine and to work in
buster.

Would it be possible to have a backport of it? I'm trying it out for
using it on nm.debian.org


Enrico


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

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

Versions of packages python3-jwcrypto depends on:
ii  python3   3.7.3-1
ii  python3-cryptography  2.6.1-3+deb10u2

python3-jwcrypto recommends no packages.

python3-jwcrypto suggests no packages.

-- no debconf information

Bug#956414: #956414: Upload a partially fixed version?

[Svante Signell]

Hi again,

I saw that there was some complaints from lintian of the uploaded 
version. I've fixed some of them. Upload again?

BTW: running lintian with the --pedantic flag does not show all issues
as 956...@bugs.debian.org does. Which option(s) trigger all the output
at the link?

Thanks!

Bug#956534: Bug#956532: stretch-pu: package php-horde-data/2.1.4-3+deb9u1

[Roberto C . Sánchez]

On Sun, Apr 12, 2020 at 10:10:14PM +0100, Adam D. Barratt wrote:
> 
> Looking at the Security Tracker and the BTS, it appears that this issue
> is not yet resolved in unstable. If that's correct, please let us know
> once that's been done; if not, please ensure that the tracking /
> metadata is corrected.
> 
> Regards,
> 
> Adam
> 
Hi Adam,

You are correct that this has not been fixed in unstable; that is the
case for the updates associated with #956532, #956533, #956534, #956535,
#956536, and #956537.  I will coordinate with the maintainer to get that
done for each package and then I will follow-up to the bugs once that is
done.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#956559: gdm3: Login screen buttons aren't clickable

[Helen Koike]

Package: gdm3
Version: 3.34.1-3
Severity: important

Dear Maintainer,

In my gdm3 screen:

https://people.collabora.com/~koike/gdm3-screen.jpeg

Clicking on buttons on top won't do anything, and when selecting a
user, clicking in the gear button to select a Desktop Environment also
doesn't do anything (which is particularly annoying since I would like to
switch between Gnome, Gnome on Xorg, Xfce and others).

Also, when I press enter on top of an user to add my password, the "Not listed?"
appears in front as shown here 
https://people.collabora.com/~koike/gdm3-screen-not-listed.jpeg

I can type my password and login normally, but it would be nice to easily switch
desktop environment.

I tried switching from Wayland to Xorg by editing /etc/gdm3/daemon.conf with
WaylandEnable=false
But I get the same results.

The command:
sudo journalctl -b -g gdm 
doesn't seem to show anything relevant http://ix.io/2hMK

Please let me know where I can find relevant logs, or how I can get more 
information
to help debug this.

Thanks a lot for your work as a maintainer.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
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)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-1
ii  adduser   3.118
ii  dconf-cli 0.36.0-1
ii  dconf-gsettings-backend   0.36.0-1
ii  debconf [debconf-2.0] 1.5.73
ii  gir1.2-gdm-1.03.34.1-3
ii  gnome-session [x-session-manager] 3.36.0-2
ii  gnome-session-bin 3.36.0-2
ii  gnome-settings-daemon 3.36.0-1
ii  gnome-shell   3.36.1-5
ii  gnome-terminal [x-terminal-emulator]  3.36.1.1-2
ii  gsettings-desktop-schemas 3.36.0-1
ii  libaccountsservice0   0.6.55-1
ii  libaudit1 1:2.8.5-3
ii  libc6 2.30-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libgdm1   3.34.1-3
ii  libglib2.0-0  2.64.1-1
ii  libglib2.0-bin2.64.1-1
ii  libgtk-3-03.24.18-1
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd245.4-3
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.48.2-1
ii  libselinux1   3.0-1+b2
ii  libsystemd0   245.4-3
ii  libwrap0  7.6.q-30
ii  libx11-6  2:1.6.9-2
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.36.1-4
ii  policykit-1   0.105-26
ii  procps2:3.3.16-4
ii  terminator [x-terminal-emulator]  1.91-4
ii  ucf   3.0038+nmu1
ii  x11-common1:7.7+20
ii  x11-xserver-utils 7.7+8
ii  xfce4-session [x-session-manager] 4.14.1-1
ii  xfwm4 [x-window-manager]  4.14.0-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.36.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.8-2
ii  xserver-xorg1:7.7+20
ii  zenity  3.32.0-5

Versions of packages gdm3 suggests:
ii  gnome-orca3.36.1-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
WaylandEnable=false
[security]
[xdmcp]
[chooser]
[debug]


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#956558: ITP: ylva -- command line password manager

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: ylva
  Version : 1.5
  Upstream Author : Niko Rosvall 
* URL : https://github.com/nrosvall/ylva
* License : MIT
  Programming Lang: C
  Description : command line password manager

 Password management belongs to the command line, deep into the Unix
 heartland, the shell. Ylva makes managing passwords easy and secure.
 It's a traditional command line software written in C. Ylva is very
 portable and should run fine on most Unix-like operating systems.
 Ylva is mainly developed on Linux.
 .
 Command line password manager is useful. You may choose to run it on
 a remote server to make your passwords available remotely (over SSH
 etc.). No need to sync your password database between machines.
 .
 Ylva uses OpenSSL (or LibreSSL) for encryption. For password database
 SQLite is used. Ylva encrypts the database using AES with 256 keys.
 Encrypted database is authenticated using HMAC. For key generation
 PKBDF2-SHA256 is used with 200 000 iterations.
 .
 Ylva does not stay running, so possible plain text passwords are not
 in memory except for a very short while. For example, running command
 ylva --auto-encrypt --list-all would list all the password entries,
 encrypt the database and then exit. Plain text passwords will be in
 memory only couple of seconds. This makes it very hard for malware
 to steal them.
 .
 When the database is decrypted, it's readable only by the owner
 (chmod 600). Ylva does that automatically for the database file
 so you don't have to change the permissions.

Bug#955638: Please update cargo - it's holding up a firefox update, impacting security

[jnqnfe]

Control: severity -1 serious

On Sat, 4 Apr 2020 14:17:43 +0100 Ximin Luo 
wrote:
> Yes, I will update cargo immediately after I get rustc 1.42 into
Debian, which is currently blocked on NEW.

Hi Ximin,

It's been a couple days since rustc entered unstable, and no sign yet
of cargo.

Firefox v75 is currently held up waiting upon cargo being updated.
Firefox v75 was released five days ago (and been queued for unstable
for four), and as usual it comes with a bunch of very important
security fixes.

I'm sure you are probably working on this already, but _please_ make
addressing this your top priority. We're relying upon you. Not wanting
to be overly dramatic, but considering the importance of a secure web
browser, the security of many Sid users has been at stake these past
few days waiting upon your getting this done.

Regards,
Lyndon

Bug#953745: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u5

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2020-03-12 at 21:54 +0100, Hilmar Preusse wrote:
> the package fixes two critical issues, which impact the usability of
> the mod_sftp proftp module and the proftp package itself.
> There are situations, where users can't connect to an proftp server
> using sftp in case the client is recent enough.  Further I removed
> the debconf call as it causes a hang in postinst.  Debconf
> integration has been removed
> for buster anyway.
> 
> - Issue is solved in Debian unstable since 1.3.6c-1
> 

I'm afraid that I'm slightly confused on this point:

adsb@coccia:~$ grep debconf proftpd-dfsg-1.3.6c/debian/proftpd-basic.postinst
ucf --debconf-ok ${file}.proftpd-new $file 
. /usr/share/debconf/confmodule

That looks like the debconf modules are still be pulled in in unstable.

Regards,

Adam

Bug#956531: [Pkg-utopia-maintainers] Bug#956531: router firmware is not an issue

[Michael Biebl]

Am 12.04.20 um 23:29 schrieb Antonio Russo:
> The router firmware mentioned above is a red herring. A macbook on the same 
> network
> is perfectly able to maintain ipv6 connectivity. Conversely, both wired and 
> wireless
> connections are exhibiting this misbehavior on 3 separate Debian 
> testing/unstable
> machines.

Please raise this issue upstream at

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/



signature.asc
Description: OpenPGP digital signature

Bug#956557: minecraft-launcher: Depends on libpango1.0-0, which is a transitional package

[Peter Denison]

Package: minecraft-launcher
Version: 2.1.10835
Severity: important

Dear Maintainer,

Trying to do a system update, and the latest version of libpango-1.0-0 >= 
1.44.7-2 drops the previous transitional package libpango1.0-0, which is
what minecraft-launcher depends on.

Fixing it should be as simple as depending on libpango-1.0-0 instead of
libpango1.0-0. (Note the hyphen - sometimes it really hard to see these
differences!)

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

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

Versions of packages minecraft-launcher depends on:
ii  ca-certificates  20190110
ii  curl 7.68.0-1
ii  default-jre  2:1.11-72
ii  dpkg 1.19.7
ii  gconf-service3.2.6-6
ii  libasound2   1.2.2-2.1
ii  libatk1.0-0  2.36.0-2
ii  libbz2-1.0   1.0.8-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.1-11
ii  libcurl4 7.68.0-1
ii  libdbus-1-3  1.12.16-2
ii  libexpat12.2.9-1
ii  libfontconfig1   2.13.1-2+b1
ii  libgcc-s1 [libgcc1]  10-20200324-1
ii  libgcc1  1:10-20200324-1
ii  libgconf-2-4 3.2.6-6
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.14-1
ii  libgtk2.0-0  2.24.32-4
ii  libnspr4 2:4.25-1
ii  libnss3  2:3.49.1-1
ii  libpango1.0-01.42.4-8
ii  libstdc++6   10-20200324-1
ii  libx11-6 2:1.6.9-2
ii  libx11-xcb1  2:1.6.9-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  wget 1.20.3-1+b2
ii  xdg-utils1.1.3-2

minecraft-launcher recommends no packages.

minecraft-launcher suggests no packages.

-- no debconf information

Bug#933302: RTL8723DE not working

[Jesse Rhodes]

Hi,

I just attempted to help a user in OFTC #debian with this nic and
confirmed/discovered the following:

- there is no rtl8723de module in buster or bullseye/sid's kernel,
despite the binary blob being present in firmware-realtek
- Ubuntu's 5.4 kernel *does* have support, but it's via the RTW88
driver that should be unrelated aiui because the 8723DE nic is 802.11n
and RTW88 is specifically 802.11ac, and yet:

jesse@bivouac:~/temp/ubuntu$ grep -i rtw88 boot/config-5.4.0-21-generic
CONFIG_RTW88=m
CONFIG_RTW88_CORE=m
CONFIG_RTW88_PCI=m
CONFIG_RTW88_8822BE=y
CONFIG_RTW88_8822CE=y
CONFIG_RTW88_8723DE=y 

The user in #debian confirmed that the ubuntu driver supported their nic.

Bullseye's 5.4 and sid's 5.5 have RTW88 as well, but sans 8723DE. See
https://salsa.debian.org/kernel-team/linux/-/blob/6ba1f0beb871cf2ba9a12837cf51999692a08c53/debian/config/config
for 5.5.

Hopefully this information helps get support for the rtl8723de into bullseye.

sney

Bug#956556: coinst FTBFS: Error: The implementation ptset.ml does not match the interface ptset.cmi

[Adrian Bunk]

Source: coinst
Version: 1.9.3-1
Severity: serious
Tags: ftbfs bullseye sid

https://buildd.debian.org/status/package.php?p=coinst

...
usr/bin/make opt
make[2]: Entering directory '/<>'
ocamlfind ocamlc -package unix,str,bigarray,cudf -g -I viewer -annot -bin-annot 
-safe-string -c ptset.mli
ocamlfind ocamlopt  -package unix,str,bigarray,cudf -g -I viewer -annot 
-bin-annot -safe-string -c ptset.ml
File "ptset.ml", line 305, characters 12-30:
305 |   List.sort Pervasives.compare (elements_aux [] s)
  ^^
Alert deprecated: module Stdlib.Pervasives
Use Stdlib instead.

If you need to stay compatible with OCaml < 4.07, you can use the 
stdlib-shims library: https://github.com/ocaml/stdlib-shims
File "ptset.ml", line 567, characters 14-32:
567 | List.sort Pervasives.compare (elements_aux [] s)
^^
Alert deprecated: module Stdlib.Pervasives
Use Stdlib instead.

If you need to stay compatible with OCaml < 4.07, you can use the 
stdlib-shims library: https://github.com/ocaml/stdlib-shims
File "ptset.ml", line 1:
Error: The implementation ptset.ml does not match the interface ptset.cmi:
   ...
   In module Big:
   The value `of_seq' is required but not provided
   File "set.mli", line 282, characters 4-31: Expected declaration
   In module Big:
   The value `add_seq' is required but not provided
   File "set.mli", line 278, characters 4-37: Expected declaration
   In module Big:
   The value `to_seq' is required but not provided
   File "set.mli", line 274, characters 4-31: Expected declaration
   In module Big:
   The value `to_seq_from' is required but not provided
   File "set.mli", line 269, characters 4-43: Expected declaration
   In module Big:
   The value `find_last_opt' is required but not provided
   File "set.mli", line 254, characters 4-55: Expected declaration
   In module Big:
   The value `find_last' is required but not provided
   File "set.mli", line 247, characters 4-44: Expected declaration
   In module Big:
   The value `find_first_opt' is required but not provided
   File "set.mli", line 240, characters 4-56: Expected declaration
   In module Big:
   The value `find_first' is required but not provided
   File "set.mli", line 227, characters 4-45: Expected declaration
   In module Big:
   The value `find_opt' is required but not provided
   File "set.mli", line 221, characters 4-40: Expected declaration
   In module Big:
   The value `choose_opt' is required but not provided
   File "set.mli", line 199, characters 4-35: Expected declaration
   In module Big:
   The value `max_elt_opt' is required but not provided
   File "set.mli", line 188, characters 4-36: Expected declaration
   In module Big:
   The value `min_elt_opt' is required but not provided
   File "set.mli", line 177, characters 4-36: Expected declaration
   In module Big:
   The value `map' is required but not provided
   File "set.mli", line 126, characters 4-35: Expected declaration
   In module Big:
   The value `disjoint' is required but not provided
   File "set.mli", line 101, characters 4-32: Expected declaration
make[2]: *** [Makefile:69: ptset.cmx] Error 2

Bug#949826: buster-pu: package haproxy/1.8.19-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-02-08 at 10:51 +0100, Vincent Bernat wrote:
>  ❦  8 février 2020 08:43 +01, Salvatore Bonaccorso  >:
> 
> > This needs to be rebased to the 1.8.19-1+deb10u1 which was released
> > as
> > DSA 4577-1 AFAICT.
> 
> Oh, sorry. Here is the updated patch.

Please go ahead.

Regards,

Adam

Bug#543340: "info automake" gives automake-1.11 documentation instead of automake-1.16

[Vincent Lefevre]

Control: retitle -1 "info automake" gives automake-1.11 documentation instead 
of the latest version when automake1.11 is installed
Control: found -1 1:1.16.1-4

On 2015-01-26 03:31:46 +0100, Vincent Lefevre wrote:
> Control: retitle -1 "info automake" gives automake-1.10 documentation instead 
> of the latest version when automake1.10 is installed
> 
> On 2015-01-25 15:04:16 -0500, Eric Dorland wrote:
> > That is odd. I get the latest info documentation when I do this. Are
> > you still seeing this?
> 
> I've just tried, and yes, I'm still seeing this.
> 
> With automake 1:1.14.1-4 installed *only*, I get the automake 1.14
> documentation. Well, this is not surprising.
> 
> Then I installed automake1.11 1:1.11.6-3, and the behavior did not
> change: "info automake" still gave the automake 1.14 documentation.

This still occurs when automake1.11 (which is still in Debian)
is installed.

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

Bug#954716: buster-pu: package suricata/1:4.1.2-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-03-22 at 15:46 +0100, Sascha Steinbiss wrote:
> I would like to propose an update for the version of suricata in
> buster (4.1.2-2). It addresses a problem with dropping privileges
> when started wn a particular runmode, which would otherwise fail in
> this version.
> Upstream has merged this patch already [1] and it has been included
> in the current version in unstable (5.0.2) [2] which the original
> patch author backported to 4.1.2 to allow fixing it in buster as
> well.
> 
> The correponding bug in Debian is #951181 [3] -- it has the required
> severity of important and describes the issue in more detail.

The metadata for that bug suggests that it still affects unstable,
which is contrary to your earlier comment above. Please could you
confirm the status of the issue in unstable, and add relevant fixed
versions to the bug if appropriate.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-03-15 at 20:57 +0100, François Mazen wrote:
> Please find attached the debdiff.
> 

Please go ahead.

Regards,

Adam

Bug#956531: router firmware is not an issue

[Antonio Russo]

The router firmware mentioned above is a red herring. A macbook on the same 
network
is perfectly able to maintain ipv6 connectivity. Conversely, both wired and 
wireless
connections are exhibiting this misbehavior on 3 separate Debian 
testing/unstable
machines.

Antonio

Bug#956315: buster-pu: package orocos-kdl/1.4.0-7

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-04-09 at 18:54 +0200, Jochen Sprickerhof wrote:
> I would like to update orocos-kdl in buster to fix #956254 (PyKDL
> crashes Python 3 interpreter). The bug shows a simple way to
> reproduce
> the issue and the patch was taken from the upstream git. The diff to
> the
> package is attached.
> 

Please go ahead.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-04-05 at 15:24 +0200, Valentin Vidic wrote:
> Please approve the following update for buster fixing a CVE:
> 

Please go ahead.

Regards,

Adam

Bug#956155: buster-pu: package corosync-qdevice/3.0.0-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-04-07 at 23:19 +0200, Valentin Vidic wrote:
> Due to missing Default-Start runlevels, corosync-qdevice cannot be
> enabled after installation:
> 
> # systemctl enable corosync-qdevice
> Synchronizing state of corosync-qdevice.service with SysV service
> script with /lib/systemd/systemd-sysv-install.
> Executing: /lib/systemd/systemd-sysv-install enable corosync-qdevice
> update-rc.d: error: corosync-qdevice Default-Start contains no
> runlevels, aborting.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#956195: buster-pu: package cloud-init/18.3-6+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2020-04-08 at 16:53 +0800, Aron Xu wrote:
> As discussed in #947351, this is a more targeted fix prepared for
> buster-pu. The updated debdiff is attached.
> 

The metadata for #936030 implies that this issue affects the package in
unstable. Is that correct? If not, please add an appropriate fixed
version to that bug to more accurately indicate which versions are
affected.

Regards

Adam

Bug#955861: stretch-pu: package csync2/2.0-8-g175a01c-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-04-05 at 15:30 +0200, Valentin Vidic wrote:
> Please approve the following update for stretch fixing a CVE:
> 

Please go ahead.

Regards,

Adam

Bug#956532: stretch-pu: package php-horde-data/2.1.4-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:25 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-data.  The
> change fixes CVE-2020-8518, which the security team has classified as
> , deeming it a minor issue which can be fixed via a point
> release.  I have prepared this update in coordination with the
> security team.  May I have
> permission to upload to stretch-proposed-updates?
> 

Looking at the Security Tracker and the BTS, it appears that this issue
is not yet resolved in unstable. If that's correct, please let us know
once that's been done; if not, please ensure that the tracking /
metadata is corrected.

Regards,

Adam

Bug#956537: stretch-pu: package php-horde-trean/1.1.7-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:34 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-trean.  The
> change
> fixes CVE-2020-8865, which the security team has classified as  dsa>,
> deeming it a minor issue which can be fixed via a point release.  I
> have
> prepared this update in coordination with the security team.  May I
> have
> permission to upload to stretch-proposed-updates?
> 

Looking at the Security Tracker and the BTS, it appears that this issue
is not yet resolved in unstable. If that's correct, please let us know
once that's been done; if not, please ensure that the tracking /
metadata is corrected.

Regards,

Adam

Bug#956533: buster-pu: package php-horde-form/2.0.18-3.1+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:27 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-form.  The
> change
> fixes CVE-2020-8866, which the security team has classified as  dsa>,
> deeming it a minor issue which can be fixed via a point release.  I
> have
> prepared this update in coordination with the security team.  May I
> have
> permission to upload to buster-proposed-updates?
> 

Looking at the Security Tracker and the BTS, it appears that this issue
is not yet resolved in unstable. If that's correct, please let us know
once that's been done; if not, please ensure that the tracking /
metadata is corrected.

Regards,

Adam

Bug#956536: buster-pu: package php-horde-trean/1.1.9-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:33 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-trean.  The
> change
> fixes CVE-2020-8865, which the security team has classified as  dsa>,
> deeming it a minor issue which can be fixed via a point release.  I
> have
> prepared this update in coordination with the security team.  May I
> have
> permission to upload to buster-proposed-updates?
> 

Looking at the Security Tracker and the BTS, it appears that this issue
is not yet resolved in unstable. If that's correct, please let us know
once that's been done; if not, please ensure that the tracking /
metadata is corrected.

Regards,

Adam

Bug#956534: stretch-pu: package php-horde-form/2.0.15-1+deb9u2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:27 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-form.  The
> change
> fixes CVE-2020-8866, which the security team has classified as  dsa>,
> deeming it a minor issue which can be fixed via a point release.  I
> have
> prepared this update in coordination with the security team.  May I
> have
> permission to upload to stretch-proposed-updates?

Looking at the Security Tracker and the BTS, it appears that this issue
is not yet resolved in unstable. If that's correct, please let us know
once that's been done; if not, please ensure that the tracking /
metadata is corrected.

Regards,

Adam

Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-04-12 at 09:23 -0400, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde-data.  The
> change fixes CVE-2020-8518, which the security team has classified as
> , deeming it a minor issue which can be fixed via a point
> release.

The Security Tracker indicates that this issue affects the package in
unstable and is not yet fixed there; is that correct?

Regards,

Adam

Bug#956555: runc init hangs on reopening exec.fifo

[Jan Nordholz]

Package: runc
Version: 1.0.0~rc10+dfsg1-1
Severity: normal

Hi,

I'm unable to run even the simplest Docker container on my system.
Even doing 'docker build/run -it' on "FROM busybox:latest" results in
'runc init' getting stuck. This is what I get...

=
jan@p53:~/tmp$ docker run -it my:bb
docker: Error response from daemon: no status provided on response: unknown.
ERRO[0001] error waiting for container: context canceled 
=

... and what I found looking around:

=
root 27066 23255  0 15:46 ?Sl 0:00  \_ 
docker-containerd-shim -namespace moby -workdir 
/var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/5a53a9fbfd52215143a737ef16f398f0d1debe8b0e955bbff9c12f2f9b78da33
 -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/
root 27082 27066  4 15:46 pts/0Ssl+   0:00  \_ runc init
=
root@p53:/tmp/runc-1.0.0~rc10+dfsg1# docker container ls -a
CONTAINER IDIMAGE   COMMAND  CREATED
 STATUS  PORTS   NAMES
5a53a9fbfd52my:bb   "sh" 12 seconds ago 
 Created amazing_villani
=
root@p53:/tmp/runc-1.0.0~rc10+dfsg1# strace -p27082
strace: Process 27082 attached
openat(AT_FDCWD, "/proc/self/fd/6", O_WRONLY|O_CLOEXEC^Cstrace: Process 27082 
detached
 
=
root@p53:/tmp/runc-1.0.0~rc10+dfsg1# lsof -p27082
COMMAND PID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
runc:[2:I 27082 root  cwd   DIR  253,4 4096   131073 /
runc:[2:I 27082 root  rtd   DIR  253,4 4096   131073 /
runc:[2:I 27082 root  txt   REG  253,0  8940480 27669163 /
runc:[2:I 27082 root  mem   REG  253,0  1831600 27670317 
/usr/lib/x86_64-linux-gnu/libc-2.30.so
runc:[2:I 27082 root  mem   REG  253,0   329960 27665569 
/usr/lib/x86_64-linux-gnu/libseccomp.so.2.4.3
runc:[2:I 27082 root  mem   REG  253,0   146912 27670379 
/usr/lib/x86_64-linux-gnu/libpthread-2.30.so
runc:[2:I 27082 root  mem   REG  253,0   169720 27669833 
/usr/lib/x86_64-linux-gnu/ld-2.30.so
runc:[2:I 27082 root0u  CHR  136,0  0t03 /dev/pts/0
runc:[2:I 27082 root1u  CHR  136,0  0t03 /dev/pts/0
runc:[2:I 27082 root2u  CHR  136,0  0t03 /dev/pts/0
runc:[2:I 27082 root5w FIFO   0,11  0t0   371326 pipe
runc:[2:I 27082 root6u FIFO   0,19  0t0   371323 
/run/docker/runtime-runc/moby/5a53a9fbfd52215143a737ef16f398f0d1debe8b0e955bbff9c12f2f9b78da33/exec.fifo
runc:[2:I 27082 root8u  a_inode   0,120 1039 [eventpoll]
runc:[2:I 27082 root9u  CHR  136,0  0t03 /dev/pts/0
=
root@p53:/tmp/runc-1.0.0~rc10+dfsg1# lsof 
/run/docker/runtime-runc/moby/5a53a9fbfd52215143a737ef16f398f0d1debe8b0e955bbff9c12f2f9b78da33/exec.fifo
 
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
runc:[2:I 27082 root6u  FIFO   0,19  0t0 371323 
/run/docker/runtime-runc/moby/5a53a9fbfd52215143a737ef16f398f0d1debe8b0e955bbff9c12f2f9b78da33/exec.fifo
=

Manually doing a 'cat .../exec.fifo' yields a single '0' and allows the
'runc init' process to spawn into the desired shell. However I cannot
attach to the container, as docker insists it's not running.

Some googling around showed that there have been some races in opening
that fifo in the past[1]. I don't understand how this call can still be
blocked; no matter which open came first (O_RDWR that resulted in fd 6
or the blocked O_WRONLY one), once a reader is present this should
complete.

Multithreading backtraces, if that's any help (yes, different PID,
same problem as above):

=
(gdb) inf thr
  Id   Target Id Frame 
* 1LWP 27577 "runc:[2:INIT]" syscall.Syscall6 () at 
syscall/asm_linux_amd64.s:53
  2LWP 27579 "runc:[2:INIT]" runtime.futex () at 
runtime/sys_linux_amd64.s:536
  3LWP 27580 "runc:[2:INIT]" runtime.futex () at 
runtime/sys_linux_amd64.s:536
  4LWP 27581 "runc:[2:INIT]" runtime.futex () at 
runtime/sys_linux_amd64.s:536
  5LWP 27582 "runc:[2:INIT]" runtime.futex () at 
runtime/sys_linux_amd64.s:536
(gdb) bt
#0  syscall.Syscall6 () at syscall/asm_linux_amd64.s:53
#1  0x0052ef7b in golang.org/x/sys/unix.openat (dirfd=-100, path=..., 
flags=524289, mode=0, fd=, err=...) at 
golang.org/x/sys/unix/zsyscall_linux_amd64.go:89
#2  0x007967f2 in golang.org/x/sys/unix.Open (path=..., fd=, err=..., mode=, perm=) at 
golang.org/x/sys/unix/syscall_linux.go:150
#3  github.com/opencontainers/runc/libcontainer.(*linuxStandardInit).Init 
(l=0xc00015da70, ~r0=...) at 
github.com/opencontainers/runc/libcontainer/standard_init_linux.go:188
#4  0x00784ad4 in 
github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization 
(l=, err=...) at 
github.com/opencontainers/runc/libcontainer/factory_linux.go:380
#5  0x007f84ab in main.glob..func6 (context=, ~r1=...) 
at github.com/opencontaine

Bug#956554: run-xpra script indentation is invalid shell

[Jamie Heilman]

Package: xpra
Version: 3.0.8+dfsg1-1+b1
Severity: important

Apparently the initial release of 3.0.8 from upstream fumbled a patch
at the end and it resulted in this:
https://lists.devloop.org.uk/pipermail/shifter-users/2020-April/002555.html

I'm assuming it's the same problem I see where server/server_util.py
has obvious indentation problems that result in the run-xpra script
being invliad shell due to a damaged heredoc.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#956553: blurry notifications in gnome 3.36

[David Mohammed]

Please test with adwaita.

If notifications are still blurred with adwaita then its not a theme issue.

If notifications are blurred only with arc theme then please report
this to the upstream issue tracker - https://github.com/jnsh/arc-theme

On Sun, 12 Apr 2020 at 21:03,  wrote:
>
> Package: arc-theme
> Version: 20190917+git20200328-1
>
> Notifications, such as new email received, are now blurry for me after
> the gnome 3.36 update.
>
> Example attached.
>
> I have a Hi-DPI screen.
>
> Relevant (?) font config from tweak tool:
>  - interface: cantarell regular 11
>  - hinting: slight
>  - antialiasing: subpixel
>  - scaling factor: 1.00
>
> Hi-DPI scaling factor is set to 2 somewhere. Ah, settings > displays >
> scale: 200%

Bug#956553: blurry notifications in gnome 3.36

[jnqnfe]

Package: arc-theme
Version: 20190917+git20200328-1

Notifications, such as new email received, are now blurry for me after
the gnome 3.36 update.

Example attached.

I have a Hi-DPI screen.

Relevant (?) font config from tweak tool:
 - interface: cantarell regular 11
 - hinting: slight
 - antialiasing: subpixel
 - scaling factor: 1.00

Hi-DPI scaling factor is set to 2 somewhere. Ah, settings > displays >
scale: 200%

Bug#954845: poor performance for -g 256x50

[Thomas Dickey]

On Sun, Apr 12, 2020 at 11:50:32AM -0400, Thomas Dickey wrote:
> On Sun, Apr 12, 2020 at 05:27:56PM +0200, Harald Dunkel wrote:
> > You can reproduce the performance fall-off by using a slow network 
> > connection,
> 
> I suppose I could, if I had a slow connection.
> Simulating one (from previous experience) hasn't been reliable :-(

You might get different behavior by setting the 'buffered' resource,
which is available in 353:

   buffered (class Buffered)
   Normally xterm is built with double-buffer support.  This
   resource can be used to turn it on or off.  Setting the
   resource to “true” turns double-buffering on.  The default
   value is “False”.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

[Julia Longtin]

Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

90-rpc.plugin does not see carriage return as a line break when running rpcinfo 
-p |awk "/tcp.*$service/"' { print $4 }' |uniq

this causes arno to fail to start if you have NFS services, and have turned 
this plugin on.

--- 90rpc.plugin~   2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@

   echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"

-  IFS=' ,'
+  IFS=$" ,\n"
   for service in $RPC_SERVICES; do
ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
 echo "${INDENT}Adding TCP ports $ports for RPC service $service"

fixes it.

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

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

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.6.0-1
ii  iptables   1.8.4-3
ii  kmod   27-2
ii  procps 2:3.3.16-4

Versions of packages arno-iptables-firewall recommends:
ii  bind9-dnsutils [dnsutils]  1:9.16.1-2
ii  curl   7.68.0-1
ii  dnsutils   1:9.16.1-2
ii  rsyslog8.2002.0-2

arno-iptables-firewall suggests no packages.

-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin 
(from arno-iptables-firewall package)

Bug#956551: ibus-chewing FTCBFS: does not pass cross flags to cmake

[Helmut Grohne]

Source: ibus-chewing
Version: 1.6.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ibus-chewing fails to cross build from source, because it does not pass
cross flags to cmake. The easiest way of doing so - using
dh_auto_configure - makes the cmake invocation succeed, but the actual
build still fails with an Exec format error. Using dh_auto_configure
also makes DEB_BUILD_OPTIONS=terse work. Please consider applying the
attached patch anyway and close this bug when doing so.

Helmut
diff --minimal -Nru ibus-chewing-1.6.1/debian/changelog 
ibus-chewing-1.6.1/debian/changelog
--- ibus-chewing-1.6.1/debian/changelog 2019-01-05 03:35:14.0 +0100
+++ ibus-chewing-1.6.1/debian/changelog 2020-04-12 17:18:24.0 +0200
@@ -1,3 +1,11 @@
+ibus-chewing (1.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross compilation: Let dh_auto_configure pass cross flags to
+cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 Apr 2020 17:18:24 +0200
+
 ibus-chewing (1.6.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru ibus-chewing-1.6.1/debian/rules 
ibus-chewing-1.6.1/debian/rules
--- ibus-chewing-1.6.1/debian/rules 2019-01-05 02:57:36.0 +0100
+++ ibus-chewing-1.6.1/debian/rules 2020-04-12 17:18:23.0 +0200
@@ -26,8 +26,7 @@
cp $(CURDIR)/po/zanata.xml $(CURDIR)/debian/bak/po
cp $(CURDIR)/ChangeLog $(CURDIR)/debian/bak
 
-   cmake -DCMAKE_INSTALL_PREFIX="/usr" \
-   -DCMAKE_VERBOSE_MAKEFILE=ON \
+   dh_auto_configure -- \
-DCMAKE_SKIP_RPATH=ON \
-DLIBEXEC_DIR=/usr/lib/ibus \
-DSYSCONF_INSTALL_DIR=/usr/share \

Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Sandro Tosi]

On Sun, Apr 12, 2020 at 1:42 PM Dmitry Shachnev  wrote:
> On Sun, Apr 12, 2020 at 01:14:31PM -0400, Sandro Tosi wrote:
> > Hey Dmitry, do you think you can consider uploading sphinx 2.* to
> > unstable now? bugs have been filed, additional extensions have been
> > packaged, and i think it's time to release it to unstable (this will
> > allow me to update numpy to a new upstream release too).
>
> Ok, I will upload it tomorrow.

Thanks! let me know if you need help with anything

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956377: qemu-system-gui: need versioned dependencies for qemu-system-gui

[Iain Learmonth]

Hi,

On 12/04/2020 19:31, Michael Tokarev wrote:
> Do you mean something like
> 
>  Depends: qemu-system-x86 (=version) | qemu-system-arm (=version) | ...
> 
> ?
> 
> It doesn't really depends on either of them, to my understanding, but
> it _extends_ either of them. Dunno. And even there, you might have
> qemu-system-arm installed that matches qemu-system-gui, but your
> qemu-system-x86 (of different version) wont work exactly the same way
> why you filed this bugreport.

Maybe a qemu-system-x86-gui metapackage that depends on qemu-system-x86
and qemu-system-gui? qemu-system-gui needs to depend on at least one of
the qemu-system-* packages because without that it's a useless package.
It is a dependency.

> I dunno. I thought about various possible ways, and found neither of
> them to be well enough, or at least better than current variant.
> 
> What I really want to do is to have _single_ package with all the
> qemu-system-* combined, and a few more that extends them, like -gui
> or qemu-block-extra, if needed. This way it will be easy to mix-n-match
> them.

That would work for me.

>> Nope, this is my desktop that I use every day, it's not some weird
>> setup, it's as close to standard Debian defaults as is possible.
> 
> That's interesting, - I don't understand how you ended up installing
> different versions of qemu subpackages. Which version of qemu-system-x86
> did you have, why it hasn't been up to date?

I already had qemu-system-x86 installed, and had been using it before
with the VNC display, but I was doing a livestream and needed to have a
real GUI display so I installed the -gui package. Enough time between
the installs led to the mismatch.

Unfortunately I didn't note down what version I had before.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature

Bug#956550: src:umockdev: fails to migrate to testing for too long

[Paul Gevers]

Source: umockdev
Version: 0.13.2-1
Severity: serious
Control: close -1 0.14.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#956499: MESA-LOADER: failed to open i915

[Michael Gilbert]

control: tag -1 moreinfo

On Sun, Apr 12, 2020 at 12:18 AM Dan Jacobson wrote:
> MESA-LOADER: failed to retrieve device information
> MESA-LOADER: failed to open i915 (search paths 
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load 
> driver: i915

Do you have the libgl1-mesa-dri package installed?  chromium already
recommends this.

Best wishes,
Mike

Bug#956377: qemu-system-gui: need versioned dependencies for qemu-system-gui

[Iain Learmonth]

Hi,

On 12/04/2020 19:13, Michael Tokarev wrote:
> This is only problematic when you have a mix of stable and testing
> (which is not recommended) or testing or unstable, or something of
> that sort.

I run testing. I upgraded all my packages a week or so before, then I
installed the GUI package. My expectation was that the qemu-system
package would be upgraded to match.

> At any rate this is definitely not an important issue, with a trivial
> resolution too (installing the right version of both components, - which
> should be relatively easy to understand from the above error message).

It prevents use of the package, you say it's a trivial fix but I only
guessed at what to do, and I'm a Debian Developer. Other users may find
themselves stuck.

>> A versioned dependency would ensure that I had the correct versions of
>> things and everything would work together.
> 
> Which package, in your opinion, should depend on which?

The -gui package should depend on qemu-system-* relevant for the
platform first, or any other qemu-system-* package to avoid installing
the one for the platform if another one is already installed. Although
maybe that's not right either and apt just isn't built for this scenario.

> Please note that qemu-system-x86 already recommends qemu-system-gui
> with proper version. Unfortunately the versioned Recommends does not
> work "right" in this case, basically the version there is ignored.
> 
> Here, I'm not sure but it _smells_ like you also have APT::Install-Recommends
> set to false, which is also not recommended.

Nope, this is my desktop that I use every day, it's not some weird
setup, it's as close to standard Debian defaults as is possible.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature

Bug#956377: qemu-system-gui: need versioned dependencies for qemu-system-gui

[Michael Tokarev]

12.04.2020 21:18, Iain Learmonth wrote:
...
>>> A versioned dependency would ensure that I had the correct versions of
>>> things and everything would work together.
>>
>> Which package, in your opinion, should depend on which?
> 
> The -gui package should depend on qemu-system-* relevant for the
> platform first, or any other qemu-system-* package to avoid installing
> the one for the platform if another one is already installed. Although

Do you mean something like

 Depends: qemu-system-x86 (=version) | qemu-system-arm (=version) | ...

?

It doesn't really depends on either of them, to my understanding, but
it _extends_ either of them. Dunno. And even there, you might have
qemu-system-arm installed that matches qemu-system-gui, but your
qemu-system-x86 (of different version) wont work exactly the same way
why you filed this bugreport.

I dunno. I thought about various possible ways, and found neither of
them to be well enough, or at least better than current variant.

What I really want to do is to have _single_ package with all the
qemu-system-* combined, and a few more that extends them, like -gui
or qemu-block-extra, if needed. This way it will be easy to mix-n-match
them.

It is really good that qemu grew up enough to need some serious debugging
less and less often, - before I tried really hard to keep various
qemu-system-* of different versions fully working when installed together.

> maybe that's not right either and apt just isn't built for this scenario.
> 
>> Please note that qemu-system-x86 already recommends qemu-system-gui
>> with proper version. Unfortunately the versioned Recommends does not
>> work "right" in this case, basically the version there is ignored.
>>
>> Here, I'm not sure but it _smells_ like you also have APT::Install-Recommends
>> set to false, which is also not recommended.
> 
> Nope, this is my desktop that I use every day, it's not some weird
> setup, it's as close to standard Debian defaults as is possible.

That's interesting, - I don't understand how you ended up installing
different versions of qemu subpackages. Which version of qemu-system-x86
did you have, why it hasn't been up to date?

Thanks,

/mjt

Bug#956511: linux-image-5.5.0-1-amd64: general protection fault in i915_active_ref with 5.5

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2020-04-12 at 12:05 +0300, Vincas Dargis wrote:
> Package: src:linux
> Version: 5.5.13-2
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading to 5.5 on Sid, I've experiencing full computer freeze after
> some time of playing, for example, minetest for some time (even though I use
> `optirun` to use discrete graphics).
> 
> Problems are completely gone if I reboot back to 5.4.
[...]

Is this reproducible without the nvidia drivers loaded at all?

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.




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

Bug#956377: qemu-system-gui: need versioned dependencies for qemu-system-gui

[Michael Tokarev]

Control: tag -1 + moreinfo
Control: severity -1 normal

10.04.2020 15:58, Iain R. Learmonth wrote:
> Package: qemu-system-gui
> Version: 1:4.2-3
> Severity: important
> 
> Hi,
> 
> I just installed qemu-system-gui to get the GTK2 thing working, but I
> got:
> 
> ===
> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/ui-gtk.so
> Note: only modules from the same build can be loaded.
> ===
> 
> Which is pretty upsetting.

This is only problematic when you have a mix of stable and testing
(which is not recommended) or testing or unstable, or something of
that sort.

At any rate this is definitely not an important issue, with a trivial
resolution too (installing the right version of both components, - which
should be relatively easy to understand from the above error message).

> A versioned dependency would ensure that I had the correct versions of
> things and everything would work together.

Which package, in your opinion, should depend on which?

Please note that qemu-system-x86 already recommends qemu-system-gui
with proper version. Unfortunately the versioned Recommends does not
work "right" in this case, basically the version there is ignored.

Here, I'm not sure but it _smells_ like you also have APT::Install-Recommends
set to false, which is also not recommended.

Please also note that I definitely don't want to add a versioned
Depends (or conflicts) on various qemu-system-* versus qemu-system-gui,
to be able to test one or another version of particular qemu-system-foo
in case some debugging or the like, - we can easily turn off gui while
debugging but switch just the main executable.

Thanks,

/mjt

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Michael Biebl]

Am 12.04.20 um 19:40 schrieb Balint Reczey:
> Hi Michael,
> 
> On Sat, Apr 11, 2020 at 9:53 PM Michael Biebl  wrote:
>>
>> Am 11.04.20 um 10:02 schrieb luca:
>>> Package: systemd-timesyncd
>>> Version: 245.4-3
>>> Severity: normal
>>>
>>>
>>> # apt-get -V dist-upgrade
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> Calculating upgrade... Done
>>> The following packages were automatically installed and are no longer 
>>> required:
>>>libnotify-bin (0.7.9-1)
>>>libqpdf26 (9.1.1-1)
>>> Use 'apt autoremove' to remove them.
>>> The following packages will be REMOVED:
>>>virtualbox-guest-utils (6.1.4-dfsg-4)
>>>virtualbox-guest-x11 (6.1.4-dfsg-4)
>>
>> Balint, I guess we should drop
>> Conflicts: virtualbox-guest-utils,
>>virtualbox-guest-utils-hwe
>> ?
> 
> Ah, yes, sorry, I did think about that, but forgot to propose the
> solution in the MR.
> 
> IMO systemd-timesyncd should be the default time-daemon but also the
> least preferred option to install, when some other installed package
> can sync the time.
> 
> I think the cleanest solution would be virtualbox source building a
> binary package that Conflicts/Provides/Replaces: time-daemon and sets
> up time synchronisation with the host (
> https://www.virtualbox.org/manual/ch09.html#changetimesync )

Nod, I think that package actually is virtualbox-guest-utils?

> If this solution is not viable, then I think the second best option is
> considering virtualbox-guest-utils as a time-daemon alternative:
> 
> AFAIK when virtualbox-guest-utils* is installed the guest's clock can
> be considered to be synchronised to the host and hopefully
> transitively to a reasonably good source, so I propose changing
> systemd instead to depend on systemd-timesyncd | time-daemon |
> virtualbox-guest-utils | virtualbox-guest-utils-hwe.  This solution
> has the disadvantage of not being able to install systemd-timesyncd
> when virtualbox-guest-utils is present, but should not sync time with
> the host. IMO this is not a huge problem, since other time-daemon-s
> can still be installed such as chrony, so the guest can still have
> accurate time, just not with systemd-timesyncd.

I would prefer not to add virtualbox-guest-utils* as an alternative
Depends.

> Cheers,
> Balint
> 
> PS: virtualbox-guest-utils is in contrib, but per #681419 it can still
> be used as an alternate dependency.

I guess I'll drop the conflicts and clone/reassign this bug report to
virtualbox and leave it up to them to decide if it should be possible to
install an NTP client alongside virtualbox-guest-utils* or not (and if
the latter, to add a C/R/P: time-daemon)

Regards,
Michael

Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Dmitry Shachnev]

Hi,

On Sun, Apr 12, 2020 at 01:14:31PM -0400, Sandro Tosi wrote:
> Hey Dmitry, do you think you can consider uploading sphinx 2.* to
> unstable now? bugs have been filed, additional extensions have been
> packaged, and i think it's time to release it to unstable (this will
> allow me to update numpy to a new upstream release too).

Ok, I will upload it tomorrow.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Balint Reczey]

Hi Michael,

On Sat, Apr 11, 2020 at 9:53 PM Michael Biebl  wrote:
>
> Am 11.04.20 um 10:02 schrieb luca:
> > Package: systemd-timesyncd
> > Version: 245.4-3
> > Severity: normal
> >
> >
> > # apt-get -V dist-upgrade
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Calculating upgrade... Done
> > The following packages were automatically installed and are no longer 
> > required:
> >libnotify-bin (0.7.9-1)
> >libqpdf26 (9.1.1-1)
> > Use 'apt autoremove' to remove them.
> > The following packages will be REMOVED:
> >virtualbox-guest-utils (6.1.4-dfsg-4)
> >virtualbox-guest-x11 (6.1.4-dfsg-4)
>
> Balint, I guess we should drop
> Conflicts: virtualbox-guest-utils,
>virtualbox-guest-utils-hwe
> ?

Ah, yes, sorry, I did think about that, but forgot to propose the
solution in the MR.

IMO systemd-timesyncd should be the default time-daemon but also the
least preferred option to install, when some other installed package
can sync the time.

I think the cleanest solution would be virtualbox source building a
binary package that Conflicts/Provides/Replaces: time-daemon and sets
up time synchronisation with the host (
https://www.virtualbox.org/manual/ch09.html#changetimesync )

If this solution is not viable, then I think the second best option is
considering virtualbox-guest-utils as a time-daemon alternative:

AFAIK when virtualbox-guest-utils* is installed the guest's clock can
be considered to be synchronised to the host and hopefully
transitively to a reasonably good source, so I propose changing
systemd instead to depend on systemd-timesyncd | time-daemon |
virtualbox-guest-utils | virtualbox-guest-utils-hwe.  This solution
has the disadvantage of not being able to install systemd-timesyncd
when virtualbox-guest-utils is present, but should not sync time with
the host. IMO this is not a huge problem, since other time-daemon-s
can still be installed such as chrony, so the guest can still have
accurate time, just not with systemd-timesyncd.

Cheers,
Balint

PS: virtualbox-guest-utils is in contrib, but per #681419 it can still
be used as an alternate dependency.

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#956482: Additional clarification

[Michael Robinson]

Sorry, an additional clarification. After some testing it is clear that no 
avahi support is built in. In order to advertise a service I must manually 
create a .service definition in /etc/avahi/services. Please built samba with 
full avahi support and include time machine support as per the above. 

Much appreciated!

Bug#955227: ibus-cangjie: Migrate from /usr/lib/ibus to /usr/libexec

[Changwoo Ryu]

Control: tags -1 + patch

See merge request at
https://salsa.debian.org/input-method-team/ibus-cangjie/-/merge_requests/1

I found that the upstream Makefile.am overrided $(libexecdir) for some
reason.  https://github.com/Cangjians/ibus-cangjie/issues/58  But I
think it's better to install the files just to /usr/libexec.

Bug#956482: Clarification

[Michael Robinson]

Just to clarify - samba is built with avahi support, but it is not built with 
Avahi support for Apple Time Machine destinations. This it is possible with a 
simple compile time switch As per the samba mailing list, fully Time Machine 
support needs to have the arg --enable-spotlight in the samba compile configs.

https://lists.samba.org/archive/samba/2019-September/225824.html 

Enabling this option allows us to use the smb.conf option "fruit:time machine = 
yes” that signals avahi to advertise a Time Machine destination over mDNS

Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Sandro Tosi]

On Fri, Mar 27, 2020 at 2:03 PM Dmitry Shachnev  wrote:
>
> On Fri, Mar 27, 2020 at 03:54:11PM +0100, Lucas Nussbaum wrote:
> > Right, I think I fixed all the cases where the summary was wrong
> >
> > All bugs filed!
>
> Thanks! You saved me days if not weeks :)

Hey Dmitry, do you think you can consider uploading sphinx 2.* to
unstable now? bugs have been filed, additional extensions have been
packaged, and i think it's time to release it to unstable (this will
allow me to update numpy to a new upstream release too).

Thanks.
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956549: gmap: please make the build reproducible

[Chris Lamb]

Source: gmap
Version: 2020-04-08+ds-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
gmap could not be built reproducibly.

This is because the tests embed the absolute build dir, as well as
inherit the build system's choice of /bin/sh symlink.

Patch attached that normalises these prior to calling tar(1).

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2020-04-12 17:00:43.068505091 +0100
--- b/debian/rules  2020-04-12 17:35:28.162127458 +0100
@@ -43,6 +43,9 @@
 
 override_dh_installexamples:
mkdir 
$(CURDIR)/debian/$(DEB_SOURCE)/usr/share/doc/$(DEB_SOURCE)/examples
+   find tests/ -type f -print0 | xargs -0r sed -i \
+   -e 's@$(CURDIR)@«buildpath»@g' \
+   -e 's@\#! /bin/bash@\#! /bin/sh@g'
tar --sort=name \
--mtime="@${SOURCE_DATE_EPOCH}" \
--owner=root --group=root --numeric-owner \

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

[Pietro Battiston]

Thanks Maurizio!

Il giorno dom, 12/04/2020 alle 18.12 +0200, Maurizio Quadrio ha
scritto:
> > Mmmhhh... that's strange. Are you sure you only edited the line
> > starting with "location = self.text_buffer"?!
> [...]
> AttributeError: 'LaTeXEditor' object has no attribute
> '_document_is_master'

OK, seems to be

https://gitlab.gnome.org/GNOME/gedit-latex/-/issues/2

Will try to fix this too.

Pietro

Bug#944339: broadcom-sta-dkms

[Roger Shimizu]

> Version: latest

Please inform us the version of broadcom-sta-dkms you tried.

> I am using: Linux roci 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26)
> x86_64 GNU/Linux
> Hp Envy 16GB RAM Debian testing, UEFI boot

So what's your hardware?

> I have followed the instructions on the wiki in an attempt to install
> this wifi driver on this system. Everything goes fine until I issue the
> modprobe wl command:
> modprobe: ERROR: could not insert 'wl': Operation not permitted

Can you share the kernel log?

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

Bug#853827: tracker-extract: Could not insert metadata for item

[Jay Haines]

Same general error here on a new install of Ubuntu 19.10.

I could not even run tracker-extract.

I had to remove every single tracktotal tag from over 6TB of flac files 
before syslog stopped being spammed.

Bug#905068: ITP: libdqlite - High-availability SQLite with Raft consensus (Was: Re: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications)

[Clément Hermann]

retitle -1 ITP: libdqlite - High-availability SQLite with Raft consensus
thanks


On Tue, 31 Jul 2018 11:24:36 +0800 (CST) "Clement Hermann"  
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Clement Hermann 
> 
> * Package name: golang-github-canonicalltd-dqlite
>   Version : 0.0~git20180507.e5bc052-1
>   Upstream Author : Canonical Ltd
> * URL : https://github.com/CanonicalLtd/dqlite
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : Distributed SQLite for Go applications
> 
>  dqlite can be used to replicate a SQLite database across a cluster,
>  using the Raft algorithm.
>  - No external processes needed: dqlite is just a Go library, you link
>it to your application exactly like you would with SQLite.
>  - Full support for transactions
>  - No need for statements to be deterministic (e.g. you can use time())
> 
> This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the
> Go team umbrella.

New description

* Package name: libdqlite
   Version : 1.4.0
   Upstream Author : Canonical Ltd
 * URL : https://github.com/CanonicalLtd/dqlite
 * License : LGPLv3 with linking exception
   Programming Lang: C
   Description : High-availability SQLite with Raft consensus
 

 dqlite is a C library that implements an embeddable and replicated SQL 
database 
 engine with high-availability and automatic failover.

 "dqlite" stands for "distributed SQLite", meaning that dqlite extends SQLite 
with 
 a network protocol that can connect together various instances of your 
application
 and have them act as a highly-available cluster, with no dependency on 
external databases.
 
 Design higlights:
 - Asynchronous single-threaded implementation using libuv as event loop.
 - Custom wire protocol optimized for SQLite primitives and data types.
 - Data replication based on the Raft algorithm and its efficient C-raft 
implementation.

Bug#956547: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat

[Taowa Munene-Tardif]

On Sun, Apr 12, 2020 at 11:59:49AM -0400, Taowa Munene-Tardif wrote:
> [1] Unfortunately, I have to write to the three upstream authors to get
> them to license ptc-go. I'll ask that they reply to the bug to have it
> on record :).

Here's the github issue: https://github.com/harenber/ptc-go/issues/28

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

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

[Maurizio Quadrio]

> Mmmhhh... that's strange. Are you sure you only edited the line
> starting with "location = self.text_buffer"?!

Sorry, my fault, I misunderstood the color code and deleted too much.

Now the change is applied correctly. Plugin loads, the toolbar appears
afer loading (or at startup if left loaded). This is my trace, I guess
only the last chance is relevant to gedit-latex.

[495][mq.asus: Varie]$ gedit reference-martino.tex &
[1] 68322
[495][mq.asus: Varie]$ Traceback (most recent call last):
  File "/usr/lib/gedit/plugins/latex/latex/editor.py", line 252, in __parse
if BENCHMARK: t = time.clock()
AttributeError: module 'time' has no attribute 'clock'

[495][mq.asus: Varie]$ Traceback (most recent call last):
  File "/usr/lib/gedit/plugins/latex/tabdecorator.py", line 98, in _on_save
self._editor.on_save()
  File "/usr/lib/gedit/plugins/latex/latex/editor.py", line 211, in on_save
self.__parse()
  File "/usr/lib/gedit/plugins/latex/latex/editor.py", line 252, in __parse
if BENCHMARK: t = time.clock()
AttributeError: module 'time' has no attribute 'clock'
Traceback (most recent call last):
  File "/usr/lib/gedit/plugins/latex/tools/__init__.py", line 133, in
run_tool
self._runner.run(context.active_editor.file, self._tool, tool_view)
  File "/usr/lib/gedit/plugins/latex/latex/editor.py", line 385, in file
if self._document_is_master:
AttributeError: 'LaTeXEditor' object has no attribute '_document_is_master'

Bug#956121: Blank screen on 2nd display using wayland

[Pierre Cheynier]

Le ven. 10 avr. 2020 à 14:42, Simon McVittie  a écrit :
>
> 3.36.x should be in unstable, or even in testing, by then. You might
> want to put your working 3.34.3 setup on "hold" in apt/aptitude for now.
>

Seeing that you released to unstable 2 days ago, but doing an apt-get
update doesn't change anything for me.
Should I conclude that my mirror is late? (seeing the package when
browing it though...
http://ftp.fr.debian.org/debian/pool/main/m/mutter/)
```
$ date
dimanche 12 avril 2020, 15:28:36 (UTC+0200)
$ sudo apt-get update | grep sid
Atteint :4 http://ftp.fr.debian.org/debian sid InRelease
$ apt-cache policy mutter
mutter:
  Installé : 3.34.3-1
  Candidat : 3.34.4-1
 Table de version :
 3.34.4-1 500
500 http://ftp.fr.debian.org/debian bullseye/main amd64 Packages
  2 http://ftp.fr.debian.org/debian sid/main amd64 Packages
 *** 3.34.3-1 100
100 /var/lib/dpkg/status
```

> > > You appear to have a dual-GPU system. Is the NVIDIA device completely
> > > disabled, or are they both active via some sort of dual-GPU arrangement
> > > like Bumblebee?
>
> You didn't answer this. If the NVIDIA device is disabled, how did you
> disable it?

Yes, actually I just didn't do any bumblebee setup of whatever related
to nvidia drivers, but you're right that it doesn't mean my chip is
disabled.
Unfortunately, I just figured out that I cannot disable the chip since
the wiring is the following:
```
$ sudo ls -l /sys/class/drm/card*
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card0 ->
../../devices/pci:00/:00:02.0/drm/card0
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card0-LVDS-1 ->
../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card0-VGA-1 ->
../../devices/pci:00/:00:02.0/drm/card0/card0-VGA-1
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card1 ->
../../devices/pci:00/:00:01.0/:01:00.0/drm/card1
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card1-DP-1 ->
../../devices/pci:00/:00:01.0/:01:00.0/drm/card1/card1-DP-1
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card1-DP-2 ->
../../devices/pci:00/:00:01.0/:01:00.0/drm/card1/card1-DP-2
lrwxrwxrwx 1 root root 0 avril 12 15:12 /sys/class/drm/card1-DP-3 ->
../../devices/pci:00/:00:01.0/:01:00.0/drm/card1/card1-DP-3
```
So in my case, LVDS-1 and DP-1 connected.

> > Let me tell you that it's a mess if we consider all graphics +
> > gnome-shell + plugins related logs :)
>
> Yes it is, but it might be helpful to show us anyway.

Just did an apt-get upgrade + gdm3 stop/start > bug > gdm3 stop +
dpkg-i .
You'll find in attachment the full journald logs (between the gdm3
start and stop), concretely if I clean the thing a bit (remove pids,
etc.) and do a diff, I see nothing obvious.. (I mean, there are a lot
of errors, but present in both cases).

>
> If you're using GNOME Shell extensions, please test with them all disabled
> and see whether that works (you can re-enable them afterwards).
>

Disabled everything, same behavior.

> If you run the lspci command (install pciutils if you don't already have
> it), what device is 00:1f.2?

OK, it seems unrelated (and older anyway).
```
$ lspci | grep 00:1f.2
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA
Controller [RAID mode] (rev 04)
```
> Similarly, what device is 01:00.0? It's on its own separate PCIE bus if I
> understand correctly, which probably means it's either your Intel GPU or
> NVIDIA GPU.

True, the NVIDIA GPU.
```
$ lspci | grep 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro
K2000M] (rev a1)
```
>
> Searching for the log messages suggests that booting with
> intel_iommu=igfx_off
> or
> intel_iommu=off

Tried these, didn't change anything.


logs.out
Description: Binary data

Bug#956548: python-cassandra-driver: FTBFS on 32 bit arches

[Sebastian Ramacher]

Source: python-cassandra-driver
Version: 3.20.2-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

python-cassandra-driver FTBFS on 32 bit arches with
| ==
| ERROR: test_datetype (tests.unit.cython.test_types.TypesTest)
| --
| Traceback (most recent call last):
|   File 
"/<>/.pybuild/cpython3_3.8_cassandra/build/tests/unit/cython/test_types.py",
 line 28, in test_datetype
| types_testhelper.test_datetype(self.assertEqual)
|   File "tests/unit/cython/types_testhelper.pyx", line 59, in 
tests.unit.cython.types_testhelper.test_datetype
| assert_equal(deserialize(expected), datetime.datetime(2242, 3, 16, 12, 
56, 32))
|   File "tests/unit/cython/types_testhelper.pyx", line 41, in 
tests.unit.cython.types_testhelper.test_datetype.deserialize
| dt = datetime.datetime.utcfromtimestamp(timestamp)
| OverflowError: timestamp out of range for platform time_t

See
https://buildd.debian.org/status/fetch.php?pkg=python-cassandra-driver&arch=i386&ver=3.20.2-2&stamp=1581670586&raw=0
for an example.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956542: RFS: simple-scan/3.36.1-1 -- Simple Scanning Utility

[Adam Borowski]

On Sun, Apr 12, 2020 at 04:12:08PM +0200, Jörg Frings-Fürst wrote:
>  * Package name: simple-scan
>Version : 3.36.1-1

> Changes since the last upload:
> 
>* New upstream release.
>* Declare compliance with Debian Policy 4.5.0 (No changes needed).
>* Add Smoketest:
>  - New debian/tests/control.
>* Refresh debian/copyright.

Alas, it fails the autopkgtest:

autopkgtest [17:57:18]: test command1: /usr/bin/simple-scan -v
autopkgtest [17:57:18]: test command1: [---
Unable to init server: Could not connect: Connection refused
Cannot open display: 
Run “/usr/bin/simple-scan --help” to see a full list of available command line 
options.

Full log attached.


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


simple-scan_3.36.1-1_amd64.build.xz
Description: application/xz

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

[Pietro Battiston]

Il giorno dom, 12/04/2020 alle 16.24 +0200, Maurizio Quadrio ha
scritto:
> @return: the extension of the currently opened file
>  ^
> SyntaxError: invalid syntax


Mmmhhh... that's strange. Are you sure you only edited the line
starting with "location = self.text_buffer"?!

Bug#956547: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat

[Taowa Munene-Tardif]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taowa Munene-Tardif 

* Package name: golang-github-harenber-ptc-go
  Version : 2.0.3-1
  Upstream Author :
* URL : https://github.com/harenber/ptc-go
* License : [1]
  Programming Lang: Go
  Description : A driver for SCS PACTOR modems for Pat

 ptc-go is a plug-in/driver to support PACTOR modems manufacted by SCS
 in the Pat Winlink-client (http://getpat.io/). It does this by
 communicating with the PACTOR modems using the WA8DED hostmode, 
 enabling full binary transparency.

[1] Unfortunately, I have to write to the three upstream authors to get
them to license ptc-go. I'll ask that they reply to the bug to have it
on record :).

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#954845: poor performance for -g 256x50

[Thomas Dickey]

On Sun, Apr 12, 2020 at 05:27:56PM +0200, Harald Dunkel wrote:
> You can reproduce the performance fall-off by using a slow network connection,

I suppose I could, if I had a slow connection.
Simulating one (from previous experience) hasn't been reliable :-(

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#955415: Compile fix with kernel 5.6.0

[Roger Shimizu]

control: tags -1 +patch +pending

Latest commit should fix it:
- https://salsa.debian.org/broadcom-sta-team/broadcom-sta/-/commit/8ce8c7f

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

Bug#956500: ITP: node-bash -- Utilities for using bash from node.js.

[Xavier]

Le 12/04/2020 à 16:17, fancycade a écrit :
> 
>> Hi,
> 
>> I don't see you as member of JS Team, are you ?
> 
> Currently I am not. I requested access over IRC yesterday, but have not heard 
> a response. It is still my plan to maintain it as part of the JS Team though 
> ;)
> 
> Thank you for the quick response.

Hi,

request access via salsa and read our doc:
 * https://wiki.debian.org/Javascript
 * https://wiki.debian.org/Javascript/Tutorial

Thanks for joining us !

Cheers,
Xavier