Bug#1060768: pdudaemon: Missing dependency on python3-aiohttp

[Mark Brown]

Package: pdudaemon
Version: 0.0.8.58.g597052b-1
Severity: serious

Attempting to use pdudaemon without python3-aiohttp installed results in
a traceback:

# pdudaemon
Traceback (most recent call last):
  File "/usr/sbin/pdudaemon", line 33, in 
sys.exit(load_entry_point('pdudaemon==0.1', 'console_scripts', 
'pdudaemon')())
 ^^
  File "/usr/sbin/pdudaemon", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pdudaemon/__init__.py", line 32, in 

from pdudaemon.httplistener import HTTPListener
  File "/usr/lib/python3/dist-packages/pdudaemon/httplistener.py", line 24, in 

from aiohttp import web
ModuleNotFoundError: No module named 'aiohttp'

but there is no dependency declared in the package.  Installing the
python3-aiohttp resolves this issue.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pdudaemon depends on:
ii  python3   3.11.2-1+b1
pn  python3-hid   
pn  python3-paramiko  
ii  python3-pexpect   4.8.0-4
ii  python3-pyasn10.4.8-3
ii  python3-pysnmp4   4.4.12-2
ii  python3-requests  2.28.1+dfsg-1
ii  python3-serial3.5-1.1
pn  python3-systemd   
pn  python3-usb   

Versions of packages pdudaemon recommends:
ii  inetutils-telnet [telnet]  2:2.4-2
ii  openssh-client 1:9.2p1-2

pdudaemon suggests no packages.

Bug#1059165: [Pkg-javascript-devel] Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Mark Brown]

On Wed, Dec 20, 2023 at 10:14:44PM +0100, Jérémy Lal wrote:

> BURP wrong zlib version check in the failing test - this could be NMUed

> DOLFIN has a single test failure, that is odd and unrelated as well - this
> could be NMUed

For non-technical reasons I can't do these NMUs myself if they're
warranted/needed.


signature.asc
Description: PGP signature

Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Mark Brown]

clone 1059165 -1
reassign -1 nodejs
retitle -1 autopkgtest failures on i386
found -1 18.19.0+dfsg-6
block 1059165 by -1
kthxbye

On Wed, Dec 20, 2023 at 08:15:31PM +0100, Paul Gevers wrote:

> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:zlib has been trying to migrate for 32 days [2].
> Hence, I am filing this bug. The version in unstable triggers autopkgtest
> failures in multiple packages (although I suspect that the current dolfin
> issues are due to it being flaky). The failure for burp has already a bug
> report against that package, which leaves nodejs on i386.

...

> 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.

Not sure that's likely in the case of zlib?

> 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.

There are non-technical issues with me doing active work on nodejs
package but from a quick glance the log does not seem particularly
plausibly related to zlib, and I note that the failures are

   not ok 498 parallel/test-debugger-heap-profiler
   not ok 962 parallel/test-fs-utimes-y2K38 # TODO : Fix flaky test 

the second of which especially doesn't inspire confidence that this is
due to zlib rather than general updates to unstable setting off an
already flaky test (eg, the kernel changed timing?).  Full log is:

   https://ci.debian.net/packages/n/nodejs/testing/i386/41176091/

and looking at:

   https://ci.debian.net/packages/n/nodejs/testing/i386/

there seem to be a number of packages triggering what from spot checks
look to be the same or similar issues in nodejs in testing.

I frankly don't really know what I'm supposed to do with this, the test
results look like noise as far as zlib is concerned so I don't see
anything to fix or investigate in the package itself.  AFAICT bugs don't
get filed for autopkgtest failures like they do for build failures so
perhaps this was just missed up until now?


signature.asc
Description: PGP signature

Bug#1055938: zlib1g: move libz.so.* to /usr

[Mark Brown]

On Tue, Nov 14, 2023 at 03:33:00PM +0100, Helmut Grohne wrote:

> > debootstrap is already broken by the /usr merge, which is something of
> > an annoyance for anyone who uses pbuilder to actually build packages...

> I suspect you are using a bulleye or bookworm system with pbuilder to
> build for unstable. Please update your debootstrap package from the
> relevant -updates suite and it'll work again. The debootstrap update
> will be part of the next point release. I'm sorry for the inconvenience,
> but the ordering has been beyond my control.

I already managed to bodge it in the end, but trying to work around the
unannounced breakage did burn all the time I'd allocated to spend on
package updates last week.


signature.asc
Description: PGP signature

Bug#1055938: zlib1g: move libz.so.* to /usr

[Mark Brown]

On Tue, Nov 14, 2023 at 11:45:35AM +0100, Helmut Grohne wrote:

> fortunately. We do not break the debian-installer (P10), because even
> unmerged chroots have /usr/lib/ on their library search
> paths. I locally verified that we do not break debootstrap (P8) and
> since the affected filename is architecture-dependent, the multi-arch
> file loss scenario (P7) also does not apply.

debootstrap is already broken by the /usr merge, which is something of
an annoyance for anyone who uses pbuilder to actually build packages...


signature.asc
Description: PGP signature

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Mark Brown]

On Thu, Aug 17, 2023 at 04:34:56PM +0200, Bastian Germann wrote:
> Am 17.08.23 um 14:25 schrieb Mark Brown:

> > Would it not be more sensible to just require that the format always be 
> > specified?

> The problem with that is that most of the implicitly 1.0 packages are
> essentially unmaintained. Making them RC buggy intentionally by requiring an
> explicit format will not help but drive many packages out of Debian or
> shifts the update burden to other DDs who have enough work already.

Right, but I'm just generally unclear what the upside is from changing
the default at all.  Changing the default under packages is also going
to make them rc buggy.


signature.asc
Description: PGP signature

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Mark Brown]

On Wed, Aug 16, 2023 at 04:51:44PM +0200, Bastian Germann wrote:
> Am 16.08.23 um 16:40 schrieb Mark Brown:
> > On Wed, Aug 16, 2023 at 04:33:40PM +0200, Bastian Germann wrote:

> > > If you do not want to move to format 3.0, please at least specify 1.0 
> > > format
> > > so that dpkg-source can move to default 3.0 format.

> > If you're forcing people to specify the format why does the default
> > matter?

> I am not forcing anybody. Think about this: If every implicit 1.0 package
> that has upstream changes on its program makes the version explicit, every
> implicitly 1.0 packages that does not have an upstream diff can still be
> built with 3.0 semantics.

> The total 1.0 packages are ~450 but if ~140 of them added a
> debian/source/format with 1.0, the defaut could be moved.

Would it not be more sensible to just require that the format always be
specified?  If the format isn't changed again it makes no difference, if
the format is changed then we would just be in the same position over
again.


signature.asc
Description: PGP signature

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Mark Brown]

On Wed, Aug 16, 2023 at 04:33:40PM +0200, Bastian Germann wrote:

> If you do not want to move to format 3.0, please at least specify 1.0 format
> so that dpkg-source can move to default 3.0 format.

If you're forcing people to specify the format why does the default
matter?


signature.asc
Description: PGP signature

Bug#1036764: xemacs21: new upstream version available

[Mark Brown]

On Thu, May 25, 2023 at 04:50:59PM +0200, Étienne Mollier wrote:

> Newer releases look to have moved here[3], and there[4] for the
> 21.5.y series; I reckon the layout is not ideal for watch files.

The 21.5 series are beta releases still, the stable release is still
21.4.


signature.asc
Description: PGP signature

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Mark Brown]

On Tue, May 23, 2023 at 09:57:42PM +0200, Alejandro Colomar wrote:

> I'm going to use zlib in the near future in my job, so I can write some
> manual pages for the functions I use.  I'll keep upstream in the loop,
> in case they want to pick the pages.  I will probably only write pages
> for the functions I use, though, of course.

That'd be excellent!


signature.asc
Description: PGP signature

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Mark Brown]

severity 1036648 wishlist
kthxbye

On Tue, May 23, 2023 at 09:26:57PM +0200, Alejandro Colomar wrote:

> This library lacks manual pages for the available functions, which seems
> to be a violation of the Debian Policy.

This is an *extremely* widespread violation of policy at this point...
it'd be nice, certainly.


signature.asc
Description: PGP signature

Bug#1035485: network-manager-l2tp-gnome: No diagnostics

[Mark Brown]

Package: network-manager-l2tp-gnome
Version: 1.20.8-1
Severity: normal

When attempting to enable a L2TP VPN connection via Network Manager if
the connection fails then an error message is popped up briefly saying
"Activation of network connection failed" but no diagnostics are made
available indicating what the problem might be, either immediately or
for example in the settings app.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-l2tp-gnome depends on:
ii  libc6 2.36-9
ii  libglib2.0-0  2.74.6-2
ii  libgtk-3-03.24.37-2
ii  libgtk-4-14.8.3+ds-2
ii  libnm01.42.4-1
ii  libnma-gtk4-0 1.10.6-1
ii  libnma0   1.10.6-1
ii  libsecret-1-0 0.20.5-3
ii  libssl3   3.0.8-1
ii  network-manager-l2tp  1.20.8-1

network-manager-l2tp-gnome recommends no packages.

network-manager-l2tp-gnome suggests no packages.

-- no debconf information

Bug#1024715: xemacs21: should use sed instead of perl in prerm scripts

[Mark Brown]

On Wed, Nov 23, 2022 at 05:34:00PM +0100, Gioele Barabucci wrote:

> index 73fd7e9..f1beb10 100644
> --- a/debian/prerm-base
> +++ b/debian/prerm-base
> @@ -9,7 +9,7 @@ fi
>  # installed.
>  ALREADY=0
>  for i in mule nomule mule-canna-wnn gnome-mule gnome-nomule
> gnome-mule-canna-wnn ; do
> -  STAT=`dpkg -s xemacs@MAJVERSION@-$i 2>/dev/null | perl -ne 'next if $_ !~
> m/^Status/; $_ =~ s/^Status:\s*(.*)/$1/; print;'`
> +  STAT=$(dpkg -s xemacs@MAJVERSION@-$i 2>/dev/null | sed -ne '/^Status:\s*/
> s///p')

This patch doesn't apply as sent, it's word wrapped.


signature.asc
Description: PGP signature

Bug#993612: [PATCH v2] of/address: Return an error when no valid dma-ranges are found

[Mark Brown]

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
Changes in v2:
- Don't leak parsed resources.
- Link to v1: 
https://lore.kernel.org/r/20230126-synquacer-boot-v1-1-94ed0eb10...@kernel.org
---
 drivers/of/address.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..67763e5b8c0e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -965,8 +965,19 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
}
 
of_dma_range_parser_init(, node);
-   for_each_of_range(, )
+   for_each_of_range(, ) {
+   if (range.cpu_addr == OF_BAD_ADDR) {
+   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
+  range.bus_addr, node);
+   continue;
+   }
num_ranges++;
+   }
+
+   if (!num_ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
 
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -975,18 +986,16 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
-   if (range.cpu_addr == OF_BAD_ADDR) {
-   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
-  range.bus_addr, node);
+   if (range.cpu_addr == OF_BAD_ADDR)
continue;
-   }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;

---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230126-synquacer-boot-243bd1b87f64

Best regards,
-- 
Mark Brown 

Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found

[Mark Brown]

On Fri, Jan 27, 2023 at 12:37:35PM -0600, Rob Herring wrote:

> Looks to me like we are leaking 'r' with this change.

Oh, probably now that you mention it.  Usually the OF code keeps
track of more things than I expect...

> Wouldn't this change work:

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index c34ac33b7338..f43311f01c32 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -968,6 +968,11 @@ int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map)
> for_each_of_range(, )
> num_ranges++;
> 
> +   if (!num_ranges) {
> +   ret = -EINVAL;
> +   goto out;
> +   }
> +

Not as-is, there is a range counted by that first loop but it's
then rejected by the check in the second loop for cpu_addr ==
OF_BAD_ADDR.  We'd need to add a similar check in the first loop.
It should work otherwise though and avoids doing the allocation
in this case.


signature.asc
Description: PGP signature

Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found

[Mark Brown]

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
 drivers/of/address.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..21342223b8e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -975,10 +975,12 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
+   ret = -EINVAL;
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
@@ -992,6 +994,7 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
r->size = range.size;
r->offset = range.cpu_addr - range.bus_addr;
r++;
+   ret = 0;
}
 out:
of_node_put(node);

---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230126-synquacer-boot-243bd1b87f64

Best regards,
-- 
Mark Brown 

Bug#1016803: [Pkg-utopia-maintainers] Bug#1016803: Bug#1016803: Generates unusable resolv.conf

[Mark Brown]

On Thu, Aug 25, 2022 at 10:50:01PM +0200, Michael Biebl wrote:

> Output of "nmcli" as well, please.

wlp61s0: connected to sirena
"Intel 8265 / 8275"
wifi (iwlwifi), 48:F1:7F:C0:88:CF, hw, mtu 1500
ip4 default
inet4 192.168.8.100/16
route4 192.168.0.0/16
route4 0.0.0.0/0
inet6 fe80::788e:1990:4d51:7a42/64
route6 fe80::/64

docker0: connected to docker0
"docker0"
bridge, 02:42:62:06:90:BF, sw, mtu 1500
inet4 172.17.0.1/16
route4 172.17.0.0/16
inet6 fe80::ddf5:758f:ebbd:71dc/64
route6 fe80::/64

lxcbr0: connected to lxcbr0
"lxcbr0"
bridge, 00:16:3E:00:00:00, sw, mtu 1500
inet4 10.0.3.1/24
route4 10.0.3.0/24
route4 169.254.0.0/16

p2p-dev-wlp61s0: disconnected
"p2p-dev-wlp61s0"
wifi-p2p, hw

enp0s31f6: unavailable
"Intel Ethernet"
ethernet (e1000e), E8:6A:64:AB:B8:78, hw, mtu 1500

lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.

Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details.

> Is /etc/resolv.conf a real file or a symlink pointing somewhere?

Normal file.

-rw-r--r-- 1 root root 72 Aug 26 19:15 /etc/resolv.conf

> Please also post the content of /run/NetworkManager/no-stub-resolv.conf

# Generated by NetworkManager
nameserver 192.168.8.1

(which is good for this network).


signature.asc
Description: PGP signature

Bug#1016803: Generates unusable resolv.conf

[Mark Brown]

Package: network-manager
Version: 1.30.6-1+deb11u1
Severity: important

On one of my systems whenever network-manager connects to a WiFi
network it generates an unusable resov.conf:

# Generated by NetworkManager
search example.org

Other devices on the same network manage to acquire a sensible
nameserver from DHCP, and this has manifested on every network
I've tried with recently.  The networks are set to use automatic
network configuration and DNS for both IPv4 and IPv6, and
resolv.conf does get updated automatically.  Setting an explicit
DNS server does generate a useful network configuration.

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

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

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-2
ii  libaudit11:3.0-2
ii  libbluetooth35.55-3.1
ii  libc62.31-13+deb11u3
ii  libcurl3-gnutls  7.74.0-1.3+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-5+deb11u1
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.14.12-0.2
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b3
ii  libnm0   1.30.6-1+deb11u1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-7
ii  libteamdctl0 1.31-1
ii  libudev1 247.3-7
ii  libuuid1 2.36.1-8+deb11u1
ii  policykit-1  0.105-31+deb11u1
ii  udev 247.3-7
ii  wpasupplicant2:2.9.0-21

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iptables 1.8.7-1
ii  libpam-systemd   247.3-7
ii  modemmanager 1.14.12-0.2
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2022.04.08-2~deb11u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.3
pn  libteam-utils

-- no debconf information

Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Wed, Jul 27, 2022 at 09:00:09PM +0200, vollan...@gmail.com wrote:

> There is no licence on this code, it is juste free!!

If that's the goal they should have a clear statement that they're in
the public domain, without an explicit license grant of some kind the
default is that things are copyrighted and all rights reserved.


signature.asc
Description: PGP signature

Bug#1016088: binutils-multiarch-dev: libbfd and friends not available for multiarch development

[Mark Brown]

Package: binutils-multiarch-dev
Version: 2.35.2-2
Severity: normal

Attempting to build a program linking against libbfd (such as perf) for
a non-native architecture is not supported in a multiarch environment,
binutils-multarch-dev does not provide the libraries and attempting to
install the multiarch version will remove the native version:

| The following additional packages will be installed:
|   binutils:arm64 binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
|   libbinutils:arm64 libctf-nobfd0:arm64 libctf0:arm64
| Suggested packages:
|   binutils-doc:arm64
| The following packages will be REMOVED:
|   binutils binutils-aarch64-linux-gnu binutils-dev binutils-multiarch
|   binutils-multiarch-dev clang-15 gcc-10 gcc-10-aarch64-linux-gnu
|   gcc-aarch64-linux-gnu
| The following NEW packages will be installed:
|   binutils:arm64 binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
|   binutils-dev:arm64 libbinutils:arm64 libctf-nobfd0:arm64 libctf0:arm64

This causes issues with for example perf.

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/56 CPU threads)
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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages binutils-multiarch-dev depends on:
pn  binutils-dev
ii  binutils-multiarch  2.35.2-2

binutils-multiarch-dev recommends no packages.

binutils-multiarch-dev suggests no packages.

-- no debconf information

Bug#1014763: dput-ng: dcut rm generates invalid commands

[Mark Brown]

Package: dput-ng
Version: 1.33
Severity: normal

I have tried to delete some uploads using commands like

dcut rm --searchdirs -f zlib_1.2.12.dfsg-0.1.dsc

however I'm told that there are errors showing up in the logs on
ftp-master saying

Jul 11 17:18:33 /broonie-1657559146.commands contains no or bad 
Uploader: field: 

Using -O to collect a commands file shows that it's generating files
like:

| Archive: ftp.upload.debian.org
| Commands:
|  rm --searchdirs zlib_1.2.12.dfsg-0.1.dsc

which just don't have an Uploader: field.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/56 CPU threads)
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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.9.2-3
ii  python3-dput  1.33

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#1014762: dput-ng: Handling of .changes files for rm is unclear

[Mark Brown]

Package: dput-ng
Version: 1.33
Severity: normal

The documentation for the rm option gives examples like

dcut rm -f DELAYED/X-day/foobar.deb

which indicate that dcut rm takes a list of files on the command line
and will assemble a commands file for itself.  For most files this seems
to work fine however if a .changes file specified then dcut appears to
try to read the .changes file:

| $ dcut rm --searchdirs -f zlib_1.2.12.dfsg-0.1_source.changes
| Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
| [Errno 2] No such file or directory: 'zlib_1.2.12.dfsg-0.1_source.changes'

rather than trying to delete the .changes file.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/56 CPU threads)
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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.9.2-3
ii  python3-dput  1.33

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:54:13PM +0200, Bastian Germann wrote:
> Am 11.07.22 um 18:40 schrieb Mark Brown:
> > On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> > > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to 
> > > DELAYED/3.

> > Why?  Please drop this.

> Okay. When are you going to address this bug then?
> It has been a month not reacting to the RC bug.
> I think this is not acceptable for a key package such as zlib.

I'm not sure what there is to react to here other than doing an upload;
it's a packaging thing more than something causing active breakage for
users and we're nowhere near to doing a release yet so there didn't seem
a huge sense of urgency here so I'd been going to roll it into packaging
the new upstream release.  The bug gives the air of being from an audit
and in those cases you do have to balance keeping people up to date with
creating noise for submitters and there's been no followup requests for
status or anything.

I have been hoping that we're going to get another upstream release
which rolls in some of the fixes for the string of problems that people
have been having with the security fix release that was recently done
though that is looking depressingly unlikely and so I need to figure out
what needs backporting.  Given the release schedule startng to kick off
at the beginning of next year it'll be some time this year, I'd guess
some time this quarter.

In any case this upload isn't a targetted fix for the individual issue,
it's got a whole bunch of other unrelated changes including a new
upstream release which are clearly out of scope.  Like I say I have
substantial concerns about the new upstream release so that having been
rolled in is especially worrying.


signature.asc
Description: PGP signature

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3.

Why?  Please drop this.  


signature.asc
Description: PGP signature

Bug#1014467: zlib1g: cannot install both of armhf and arm64 in multiarch setup

[Mark Brown]

On Wed, Jul 06, 2022 at 05:03:36PM +0200, Jonas Schäfer wrote:

> I installed Debian with an arm64 kernel but an armhf userland. I now
> need some components as arm64, one of which depends on zlib1g. It is
> impossible to install both zlib1g:armhf and zlib1g:arm64, which causes
> the installation to fail because apt somehow depends also on zlib1g.
> 
> This is after I had a Debian with arm64 kernel and arm64 userland and
> I needed a component in armhf which exhibited the same issue, which is
> why I went with a "split" userland/kernel in the first place.
> 
> Please (re?-)add support for multiarch armhf+arm64 for the zlib1g
> package, thanks a lot.

This is most likely some system configuration issue on your part, there
is nothing in the packaging that specifically excludes this combination
and indeed I appear to have a system available to me with both
architectures installed without problem.  You haven't provided any error
messages here, a dependency from apt to zlib1g on one architecture won't
prevent installation of zlib1g on another architecture so it's not going
to be that.


signature.asc
Description: PGP signature

Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye

[Mark Brown]

On Tue, Mar 29, 2022 at 01:02:34AM +0100, Mark Brown wrote:
> On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote:

> I bisected this to
> 
> commit 7a8b64d17e35810dc3176fe61208b45c15d25402
> 
> of/address: use range parser for of_dma_get_range
> 
> on what appears to have been a DT system with a built in DT from
> the firmware, using upstream's defconfig.  I dimly recall seeing

Oh, and probably worth pointing out that current mainline handles
the failures with ATA a lot more gracefully, still failing to
bring up ATA but just printing:

[2.652674] ahci :02:00.0: SSS flag set, parallel bus scan disabled
[2.659364] ahci :02:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 
impl SATA mode
[2.667474] ahci :02:00.0: flags: 64bit ncq sntf stag led clo pmp pio 
slum part ccc sxs 
[2.676825] ahci :02:00.0: failed to start port 0 (errno=-12)
[2.682955] ahci: probe of :02:00.0 failed with error -12

and MMC still also fails but this time with an identified oops
rather than just timeouts:

[2.987953] [ cut here ]
[2.994834] usbcore: registered new interface driver usbhid
[2.998370] f_sdh30 5230.sdhci: swiotlb addr 0x+65536 
overflow (mask , bus limit 0).
[2.998395] WARNING: CPU: 2 PID: 8 at kernel/dma/swiotlb.c:740 
swiotlb_map+0x1e4/0x1f8
[3.003981] usbhid: USB HID core driver
[3.014149] Modules linked in:
[3.014159] CPU: 2 PID: 8 Comm: kworker/u48:0 Not tainted 
5.17.0-11137-gb953c6822375 #1
[3.026681] NET: Registered PF_PACKET protocol family
[3.028964] Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS 
build #54 Mar  6 2019
[3.028973] Workqueue: events_unbound async_run_entry_fn
[3.028987] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[3.037169] 9pnet: Installing 9P2000 support
[3.042056] pc : swiotlb_map+0x1e4/0x1f8
[3.042068] lr : swiotlb_map+0x1e4/0x1f8
[3.042078] sp : 8818bb80
[3.050930] Key type dns_resolver registered
[3.056180] x29: 8818bb80 x28:  x27: 
[3.063504] registered taskstats version 1
[3.067423] 
[3.067427] x26: 0001 x25: 0080 x24: 000801787010
[3.067439] x23:  x22: 
[3.071388] Loading compiled-in X.509 certificates
[3.075292]  x21: 0001
[3.075299] x20: 898c3998 x19: 000801787010
[3.079127] pstore: Using crash dump compression: deflate
[3.082890]  x18: 0020
[3.082897] x17:  x16: 206f74206b636162 x15: 
[3.082909] x14: 0001
[3.097298] OF: translation of DMA address(0) to CPU address failed node()
[3.102762]  x13: 000f7bf76556 x12: 000f7bf76551
[3.102773] x11: 0720072007200720 x10: 000a x9 : 8818bb80
[3.102785] x8 : 8a331198 x7 : 8818b980
[3.108037] gpio-keys gpio-keys: Invalid size 0x1 for dma-range(s)
[3.112816]  x6 : 000f7bf3ef80
[3.112823] x5 :  x4 : 
[3.116564] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[3.121457]  x3 : 
[3.121464] x2 : 8a0125a0 x1 : fbd95b9fae668f00 x0 : 
[3.197275] Call trace:
[3.199721]  swiotlb_map+0x1e4/0x1f8
[3.203305]  dma_map_page_attrs+0xec/0x228
[3.207408]  sdhci_setup_host+0x8f0/0xd30
[3.211430]  sdhci_add_host+0x18/0x50
[3.215098]  sdhci_f_sdh30_probe+0x2a0/0x378
[3.219373]  platform_probe+0x68/0xd8
[3.223043]  really_probe+0xb8/0x300
[3.226622]  __driver_probe_device+0x78/0xe0
[3.230896]  driver_probe_device+0x3c/0xe8
[3.234997]  __driver_attach_async_helper+0x2c/0x50
[3.239880]  async_run_entry_fn+0x34/0xd0
[3.243896]  process_one_work+0x1ec/0x330
[3.247912]  worker_thread+0x44/0x420
[3.251579]  kthread+0x110/0x120
[3.254815]  ret_from_fork+0x10/0x20
[3.258397] ---[ end trace  ]---

followed by more in sdhci_send_command().

[   23.661522] WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:1151 
sdhci_send_command+0x954/0xde8

I'm guessing these are going to be the same underlying issue with the
firmware but manifesting a bit differently, the network device
does still complain about the 1 byte dma-range.  The system gets
to a ramdisk but has no useful I/O.


signature.asc
Description: PGP signature

Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye

[Mark Brown]

On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote:
> On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote:
> >
> >I have a synquacer here still and I'll take a look. I noticed on
> >bullseye release day that USB stuff didn't seem to work in the
> >installer on the synquacer either. Maybe there's been a regression in
> >config. :-/
> >
> >I'll take a look...
> 
> Hmmm, booting 5.10.0-0.bpo.8-arm64 here does not work at all. I'm
> seeing a lot of errors around DMA setup, e.g.:

I bisected this to

7a8b64d17e35810dc3176fe61208b45c15d25402 is the first bad commit
commit 7a8b64d17e35810dc3176fe61208b45c15d25402
Author: Rob Herring 
Date:   Thu Feb 6 14:02:30 2020 +

of/address: use range parser for of_dma_get_range

on what appears to have been a DT system with a built in DT from
the firmware, using upstream's defconfig.  I dimly recall seeing
some discussion of issues here in the past, though I don't have
one of these boxes myself so wasn't paying huge attention.  I'd
guess there's some bug in the DT which given that this is in the
firmware the kernel ought to fix up during early init, if someone
with better access to one of these systems could supply a DT for
inspection that might help people figure things out.

I suspect the machines might work fine when booted with ACPI
firmware.

The bisect log:

git bisect start
# bad: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7
git bisect bad 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162
# good: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6
git bisect good 0ad2c0e5fc7bd5c5a60f88be1174271410254e32
# skip: [50a5de895dbe5df947b3a695777db5b2c313e065] Merge tag 'for-linus-hmm' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
git bisect skip 50a5de895dbe5df947b3a695777db5b2c313e065
# good: [422c032afcf57d5e8109a54912e22ffc53d99068] netfilter: flowtable: Use rw 
sem as flow block lock
git bisect good 422c032afcf57d5e8109a54912e22ffc53d99068
# skip: [8c1b724ddb218f221612d4c649bc9c7819d8d7a6] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect skip 8c1b724ddb218f221612d4c649bc9c7819d8d7a6
# bad: [88d7fcfa3b1fe670f0412b95be785aafca63352b] net: inet_csk: Fix 
so_reuseport bind-address cache in tb->fast*
git bisect bad 88d7fcfa3b1fe670f0412b95be785aafca63352b
# skip: [6cad420cc695867b4ca710bac21fde21a4102e4b] Merge branch 'akpm' (patches 
from Andrew)
git bisect skip 6cad420cc695867b4ca710bac21fde21a4102e4b
# good: [77a36a3ab4ff17fad23831192e3694a3c5a1750d] HID: Add driver fixing 
Glorious PC Gaming Race mouse report descriptor
git bisect good 77a36a3ab4ff17fad23831192e3694a3c5a1750d
# bad: [8ec91c0fce1500306a858d0c35d1383fd9eb6ba6] Merge tag 'gpio-v5.7-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect bad 8ec91c0fce1500306a858d0c35d1383fd9eb6ba6
# skip: [7be97138e7276c71cc9ad1752dcb502d28f4400d] Merge tag 'xfs-5.7-merge-8' 
of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect skip 7be97138e7276c71cc9ad1752dcb502d28f4400d
# bad: [f5637d3b42ab0465ef71d5fb8461bce97fba95e8] mm/memory_hotplug: rename 
mhp_restrictions to mhp_params
git bisect bad f5637d3b42ab0465ef71d5fb8461bce97fba95e8
# skip: [f365ab31efacb70bed1e821f7435626e0b2528a6] Merge tag 
'drm-next-2020-04-01' of git://anongit.freedesktop.org/drm/drm
git bisect skip f365ab31efacb70bed1e821f7435626e0b2528a6
# skip: [c101e9bbce4ae2947b35a660f17d617fc3827595] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
git bisect skip c101e9bbce4ae2947b35a660f17d617fc3827595
# good: [dc8c609bd31d2b410fd47a82a7b259f68056b244] drm/rcar-du: Plug atomic 
state hooks to the default implementation
git bisect good dc8c609bd31d2b410fd47a82a7b259f68056b244
# skip: [ccfc569347f870830e7c7cf854679a06cf9c45b5] mlxsw: spectrum_flower: Do 
not stop at FLOW_ACTION_VLAN_MANGLE
git bisect skip ccfc569347f870830e7c7cf854679a06cf9c45b5
# skip: [e964f1e04a1ce562f0d748b29326244d3cb35ba4] Merge tag 
'dmaengine-5.7-rc1' of git://git.infradead.org/users/vkoul/slave-dma
git bisect skip e964f1e04a1ce562f0d748b29326244d3cb35ba4
# good: [1fd34184aab0fe04c5d50af01a37fe1bb8bd6595] drm/meson: dw-hdmi: stop 
enforcing input_bus_format
git bisect good 1fd34184aab0fe04c5d50af01a37fe1bb8bd6595
# skip: [ff2ae607c6f329d11a3b0528801ea7474be8c3e9] Merge tag 'spdx-5.7-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx
git bisect skip ff2ae607c6f329d11a3b0528801ea7474be8c3e9
# good: [cc674ef252f4750bdcea1560ff491081bb960954] KVM: s390: introduce module 
parameter kvm.use_gisa
git bisect good cc674ef252f4750bdcea1560ff491081bb960954
# good: [b17350e4037257d25f1ca9772ba5daced9f1bf07] soundwire: cadence: commit 
changes in the exit_reset() sequence
git bisect good b17350e4037257d25f1ca9772ba5daced9f1bf07
# bad: [aa1a8ce533324d12696a9f4b71dbc5eb561a2e04] Merge tag 'trace-v5.7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect bad aa1a8ce533324d12696a9f4b71dbc5eb561a2e04
# skip: 

Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate

[Mark Brown]

On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote:

> Here is a preliminary debdiff to address this.

Thanks, that's roughly what I uploaded - it looks like your mail
raced with my own update.


signature.asc
Description: PGP signature

Bug#919598: zlib: copyright file needs updating

[Mark Brown]

On Thu, Jan 17, 2019 at 07:14:00PM +0100, Kai Pastor, DG0YT wrote:

> a) the zlib 1:1.2.11.dfsg-1 copyright file claims to be based on sources
> from zlib-1.0.4.tar.gz which is obviously wrong.

That's just descriptive stuff about the creation of the package
transferred over from the free form changelog.

> The win32 directory is how I came here: I'm building for Mingw from the
> Debian sources, which now fails. Is the removal of the win32 directory
> neccessary? I do see the restrictions established in win32/DLL_FAQ.txt.
> However, I don't think these restrictions are removed by removing this file.
> They may apply to the DFSG sources as well, even with the win32 dir removed.

I can't immediately see why it was removed, I don't even see
which restrictions you're referring to in the DLL FAQ.  It could
*probably* be added back, though there might be something I'm
missing.


signature.asc
Description: PGP signature

Bug#999155: ping

[Mark Brown]

On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote:

> In order have some activity on this bug and to avoid autoremoval of
> dependencies, this is a reminder of outstanding things to do ...

Please don't send content free pings, they just add noise and make it
likely that it's going to take longer (since I remember that I did
something but forget that it was just handling the ping).


signature.asc
Description: PGP signature

Bug#999155: RC bug in mm and zlib

[Mark Brown]

On Wed, Jan 05, 2022 at 12:57:47PM +0100, Thorsten Alteholz wrote:

> are you already working on an update of mm and zlib? Or do you need some
> help?

They're utterly trivial, I'll get round to them at some point when I do
a batch run through all my packages.  It'd be more effort to integrate
something.


signature.asc
Description: PGP signature

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Mark Brown]

On Tue, Dec 21, 2021 at 04:45:21AM +0100, Guillem Jover wrote:

> instead of with its native API. But if that happens, I think it would
> make sense to upload, as it's currently being embedded in several
> upstream projects and even if dpkg would not switch to it, it would
> still help with removing embedded code copies, and speeding up other
> packages. Or make other RPFs such as #901490 (an alternative fork)
> unnecessary.

The alternative fork is the big issue here - there's several different
zlib projects active which don't seem to be working towards each other
and there's none of them that is clearly going to be the one that will
become the default in future if it's not the original zlib.  We should
just pick a new zlib if we want a new zlib rather than making users go
and figure out which they want.


signature.asc
Description: PGP signature

Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license

[Mark Brown]

On Wed, Aug 11, 2021 at 02:38:48PM +0200, Pierre Gruet wrote:

> Source: xemacs21-packages
> Version: 2009.02.17.dfsg.2-4
> Severity: serious
> Tags: stretch buster bullseye sid

...

> The file
> xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java
> incorporates a non-free license, stating 

This bug has been present for several decades now, it is *extremely*
late for the buster release at this point and fixing this will require
an upload of a new source version to pull out the file.  I therefore
propose that we ignore this bug for the upcoming release to avoid the
minor but still present risk of disruption at this point in the cycle.


signature.asc
Description: PGP signature

Bug#787860: closed by Simon McVittie (Re: Bug#787860: build seahorse compatible with gpg2)

[Mark Brown]

On Mon, Apr 12, 2021 at 04:27:46PM +0100, Simon McVittie wrote:
> On Mon, 12 Apr 2021 at 15:54:07 +0100, Mark Brown wrote:
> > This bug appears to have drifted well away from the initial report
> > (which was about GNOME forcing itself as the SSH agent even if one is
> > already set)

> Are you confusing the clone #787860 "build seahorse compatible with gpg2"
> with your original report #760102 "gnome-keyring: Breaks gpg-agent with
> no UI to disable", later retitled to "gnome-keyring: please build with
> --disable-gpg-agent"?

> You originally reported #760102, which was about gnome-keyring acting as
> a GPG agent (it no longer does this, it talks to the normal gpg-agent
> instead).

Right, it looks like the duplication has caused some confusion here and
the BTS showing the original bug with cloned stuff doesn't help.  I've
reported both bugs several times, the SSH agent part of it has persisted
for a couple of releases while getting harder and harder to work around.

> As a side issue in the original report of #760102, you also mentioned
> gnome-keyring also acting as a *SSH* agent, which is what you're now
> talking about. It does still do *that* by default (in GNOME, Unity or
> MATE desktops), but it can be disabled (I disable it myself, to use the
> gpg-agent as my SSH agent for smart card/token support).

Ugh, this is depressing.  :(

> FYI, here is how to disable gnome-keyring's SSH agent implementation on a
> per-user basis:

> * copy /etc/xdg/autostart/gnome-keyring-ssh.desktop to ~/.config/autostart/
> * add Hidden=true to the [Desktop Entry] group

This is obviously very user hostile, though IIRC that's at least
consistent with the bodge that was needed before so hopefully my systems
won't break on upgrade this time around.  I still find this to be a
pretty serious bug in GNOME since it's actively replacing the existing
SSH agent with a much less functional one with no real user interface
for disabling it (having to hack the start files isn't great and has
been fragile whenever someone decides to refactor them).

> I don't think reopening #787860 is useful: that bug report asks for seahorse
> to be compiled to be gpg2-compatible, and now it is.

Yes, unfortunately the fact that the bug was cloned meant that the
report that it said was being closed was my original report rather than
this separate issue.

> If you are not happy with gnome-keyring providing a *SSH* agent by default
> (in GNOME, MATE and Unity desktops), that would be appropriate to open
> as a new bug report against gnome-keyring (although that bug might be
> wontfix); but please don't report it as a bug in seahorse. I think a new
> bug would be more appropriate than reopening #760102, because the bug
> identified in #760102's title was resolved some time ago.

I'm pretty sure I've already reported that one - it's been present for
a couple of releases - though I can't see it in the set of open bugs any
more so I guess someone closed it at some point, especially if you're
saying you'd just mark it wontfix.  That's pretty disappointing TBH, I
don't entirely understand why a similar approach isn't being adopted to
that with gpg-agent - layering UI on top of an underlying agent rather
than insisting on replacing the agent.


signature.asc
Description: PGP signature

Bug#787860: closed by Simon McVittie (Re: Bug#787860: build seahorse compatible with gpg2)

[Mark Brown]

reopen 787860
kthxbye

On Sun, Apr 11, 2021 at 04:03:19PM +, Debian Bug Tracking System wrote:

> On Fri, 05 Jun 2015 at 16:45:28 -0400, Daniel Kahn Gillmor wrote:
> > I've now filed a more extensive changeset at seahorse upstream, as noted
> > above.

> This seems to have been applied a long time ago: since version 3.20.0,
> seahorse upstream only has what was formerly the GnuPG 2 code path, and
> does not support use of GnuPG 1.4.

This bug appears to have drifted well away from the initial report
(which was about GNOME forcing itself as the SSH agent even if one is
already set) - I don't understand how this discussion would be relevant
to the reported issue and I've never seen any acknowledgement that
GNOME sees this as a problem.  You can see in the bug log that at one
point the discussion switches from discussions of gpg-agent providing
SSH_AUTH_SOCK to discussions of interactions between gpg and gpg-agent
which is a separate issue.


signature.asc
Description: PGP signature

Bug#952257: xemacs21-packages: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Mark Brown]

On Sun, Feb 23, 2020 at 02:22:15PM +0100, Lucas Nussbaum wrote:

> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/xemacs-packages/edit-utils'

Not sure how these are generated but there's over 1000 lines of
log here, most of it irrelevant.  This makes it hard to both find
the actual problem and reply to this mail.  The only relevant
part of the log is:

> > cd . && makeinfo  -o edit-utils.info edit-utils.texi
> > cd . && makeinfo  -o tempo.info tempo.texi
> > utf8 "\xE5" does not map to Unicode at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796,  line 22.
> > Malformed UTF-8 character: \xe5\x67\x65 (unexpected non-continuation byte 
> > 0x67, immediately after start byte 0xe5; need 3 bytes, got 1) in pattern 
> > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > Malformed UTF-8 character (fatal) at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > make[3]: *** [../../XEmacs.rules:310: tempo.info] Error 25


signature.asc
Description: PGP signature

Bug#952434: dovecot-imapd: Problems opening mailboxes since upgrade to Debian 10

[Mark Brown]

Package: dovecot-imapd
Version: 1:2.3.4.1-5+deb10u1
Severity: important

Since upgrading to Debian 10 several mailboxes have started failing to
open/read, apparently due to some cache corruption or some format change
between versions.  The logs show errors like:

read(FILENAME) failed: Cached message size larger than expected (4627 > 4537, 
box=NAME, UID=64) (read reason=)

and imapd exits with no obvious way to recover the mailbox.  This
renders the affected mailboxes unusable.

It looks like this is a known issue upstream which has been resolved.

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

Kernel: Linux 5.1.17-x86_64-linode128 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dovecot-imapd depends on:
ii  dovecot-core  1:2.3.4.1-5+deb10u1
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10
ii  liblz4-1  1.8.3-1
ii  liblzma5  5.2.4-1
ii  ucf   3.0038+nmu1
ii  zlib1g1:1.2.11.dfsg-1

dovecot-imapd recommends no packages.

Versions of packages dovecot-imapd suggests:
pn  ufw  

Versions of packages dovecot-imapd is related to:
ii  dovecot-core [dovecot-common]  1:2.3.4.1-5+deb10u1
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.4.1-5+deb10u1
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

-- no debconf information

Bug#950626: dcut silently fails

[Mark Brown]

reopen 950626
kthxbye

On Thu, Feb 06, 2020 at 01:47:34PM +1100, Ben Finney wrote:
> On 05-Feb-2020, Mark Brown wrote:

> > If dcut is generating commands which produce no response from the
> > server that seems like a really bad bug in dcut.

> The server does not process commands immediately, so there is no way
> for a client (like ‘dcut’) to know whether they succeed or fail.

"succeed or fail" is not the same as "produce no response".  It
should be possible for dcut to tell if the commands are likely to
be silently discarded and avoid that.

> I hope that clears up the behaviour you're seeing. This is not a bug
> in ‘dcut(1)’, so I'm closing this report.

No, I perfectly understand that the commands are processed in a
laggy fashion.  Like I say that doesn't mean that dcut should be
generating command files which can produce just no reponse at
all, I'd expect dcut to have a good idea before it uploads files
if that will happen and take steps to avoid it.


signature.asc
Description: PGP signature

Bug#950626: dcut silently fails

[Mark Brown]

On Tue, Feb 04, 2020 at 11:54:01PM +1100, Ben Finney wrote:
> Control: tags -1 + moreinfo
> 
> On 04-Feb-2020, Mark Brown wrote:
> > I recently attempted to use dcut to cancel an upload which
> > someone had done with commands like

> > dcut ftp-master *zlib*

> > This appeared to have succeded and produced no error message

> As defined, the ‘dcut(1)’ command can only send commands to the
> command server. Once the commands file is successfully sent, the
> program succeeds and its execution is complete.

If dcut is generating commands which produce no response from the
server that seems like a really bad bug in dcut.  

> > but did not in fact result in the upload being cancelled which is
> > somewhat irritating given that there's no way to inspect the upload
> > queue.

> That is unfortunate. I Think ‘dcut’ cannot do anything about that,
> though, with the command server interface as is?

If there is genuinely no way to guarantee a response from the
server that seems like something where the dcut developers need
to work with the archive people to ensure that there's a way to
do that.

> > I would expect that dcut would detect any errors that will not be
> > being reported by ftp-master.

> My understanding is that the channel to upload commands to the server
> has no way for those errors to come back to the ‘dcut’ program as it
> runs. Is this something the uploading program can detect?

The program should at least know what the server requires in
order to ensure that a response is generated and do local
validation of those requirements.  Even if it were to add some
command that's guaranteed to report an error that'd be a massive
improvement.


signature.asc
Description: PGP signature

Bug#950626: dcut silently fails

[Mark Brown]

Package: dput
Version: 1.0.3
Severity: important

I recently attempted to use dcut to cancel an upload which
someone had done with commands like

dcut ftp-master *zlib*

This appeared to have succeded and produced no error message but
did not in fact result in the upload being cancelled which is
somewhat irritating given that there's no way to inspect the
upload queue.  I would expect that dcut would detect any errors
that will not be being reported by ftp-master.

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /home/broonie/.dput.cf --

[DEFAULT]
login = *
method = ftp
hash = md5
allow_unsigned_uploads = 0
allow_dcut = 0
distributions = 
allowed_distributions = (?!UNRELEASED)
run_lintian = 0
run_dinstall = 0
check_version = 0
scp_compress = 0
default_host_main = 
post_upload_command = 
pre_upload_command = 
ssh_config_options = 
passive_ftp = 1
progress_indicator = 0
delayed = 

[ftp-master]
fqdn = ftp.upload.debian.org
incoming = /pub/UploadQueue/
login = anonymous
allow_dcut = 1
method = ftp
allowed_distributions = (?!UNRELEASED|.*-security)

[ftp-eu]
fqdn = ftp.eu.upload.debian.org
method = ftp
incoming = /pub/UploadQueue/
login = anonymous
allow_dcut = 1
allowed_distributions = (?!UNRELEASED|.*-security)

[ssh-upload]
login = *
fqdn = ssh.upload.debian.org
method = scp
incoming = 

Bug#949388: zlib: build lib64z for x32 and mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el

[Mark Brown]

On Tue, Jan 28, 2020 at 08:50:09PM +0800, YunQiang Su wrote:
> On Tue, 21 Jan 2020 08:48:23 +0800 YunQiang Su  wrote:

> > This is some problem we met on mips/mipsel:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879636
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849657

> I NMUed zlib with the attached patch with 5-days delay.
> Feel free to cut it if you think that it is not good.

This is extremely short notice on what should be a wishlist bug that was
only filed just over a week ago for a non-mainstream port with an
unclear description of the issue, it seems quite hasty to be doing a
NMU.  I've hopefully cancelled the upload for now, though this is the
first time I've had to use dcut.


signature.asc
Description: PGP signature

Bug#945024: msmtp: Doesn't generate a Message-Id

[Mark Brown]

Package: msmtp
Version: 1.8.3-1
Severity: normal

When injecting mail via /usr/sbin/sendmail if the client program does
not generate a message ID then one won't be provided by msmtp resulting
in messages going out without a message ID at all.  This isn't an unusal
thing for simple scripts or similar to do and results in messages that
are out of spec.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/56 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.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 msmtp depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgnutls303.6.7-4
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20190110

Versions of packages msmtp suggests:
ii  msmtp-mta  1.8.3-1

-- debconf information excluded

Bug#931419: [Pkg-utopia-maintainers] Bug#931419: network-manager: Support for multiple wired networks is confusing

[Mark Brown]

On Thu, Jul 04, 2019 at 05:09:08PM +0200, Michael Biebl wrote:
> Am 04.07.19 um 16:14 schrieb Mark Brown:

> > I actually see the same behaviour with the CLI and TUI as I do
> > with the GNOME settings stuff - there's nothing obvious that
> > suggests that the two connections are mutually exclusive (in the
> > TUI they do both say "Wired Connection 1" but that's a child of
> > the interface so those configs look like they're per-interface).
> > AFAICT the exclusion is being enforced at the NM level and the
> > clients are just passing through what they see through the APIs.

> > Anyway, I'm attaching an image showing the GNOME settings app.

> So you have two network interfaces but one connection profile?
> Can you attach that connection profile (see
> /etc/NetworkManager/system-connections)?
> I still struggle to understand your problem tbh.

I don't know what a "connection profile" is, I didn't configure
one knowingly.  I just tried to click "enable" on the interfaces.
Anyway, attaching.
[connection]
id=Wired connection 1
uuid=ee6d6cf2-5f27-43d0-af17-16d67291e0cc
type=ethernet
permissions=
timestamp=1562192049

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
address1=REDACTED
dns-search=
ip6-privacy=2
method=manual


signature.asc
Description: PGP signature

Bug#931419: network-manager: Support for multiple wired networks is confusing

[Mark Brown]

Package: network-manager
Version: 1.14.6-2
Severity: normal

On a system with multiple wired networks Network Manager displays
them separately (eg, in the system settings app I see two network
connections listed with separate settings buttons and on/off
toggles) but in actual fact there is only a single set of wired
settings and toggling one connection on toggles other wired
connections off.  Similar things happen when configuring via the
system menu.

This is not helped by the presence of a "use this connection only
for resources on its network" option (which is what I want to do
with one of the connections).

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/56 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.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 network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1
ii  libc6  2.28-10
ii  libcurl3-gnutls7.64.0-4
ii  libglib2.0-0   2.58.3-2
ii  libgnutls303.6.7-4
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2
ii  libpam-systemd 241-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-5
ii  libteamdctl0   1.28-1
ii  libudev1   241-5
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019051400
ii  policykit-10.105-25
ii  udev   241-5
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-6

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#918113: linux-image-4.19.0-1-amd64: Fails to initalize DisplayPort displays with rx560

[Mark Brown]

On Thu, Jan 03, 2019 at 01:49:49PM +, Mark Brown wrote:

> Even with only one monitor connected the system is unable to do anything
> useful with the display, it has trouble setting up a valid clock
> configuration though there is no oops:
> 
> Dec 29 17:57:14 debutante kernel: [3.561312] amdgpu :01:00.0: 
> firmware: direct-loading firmware amdgpu/polaris11_k_smc.bin
> Dec 29 17:57:14 debutante kernel: [3.622018] EXT4-fs (sdb1): mounted 
> filesystem with ordered data mode. Opts: errors=remount-ro
> Dec 29 18:14:17 debutante kernel: [3.482651] amdgpu: [powerplay] Failed 
> to retrieve minimum clocks.
> Dec 29 18:14:17 debutante kernel: [3.482652] amdgpu: [powerplay] Error in 
> phm_get_clock_info 

I've confirmed that this part of the issue is fixed with the 4.20
packages in experimental, the problems with a dual monitor setup oopsing
and generally failing to work that were the main focus of the report
remain.


signature.asc
Description: PGP signature

Bug#918113: linux-image-4.19.0-1-amd64: Fails to initalize DisplayPort displays with rx560

[Mark Brown]

Package: src:linux
Version: 4.19.13-1
Severity: important

As covered in the kernel log below the amdgpu driver fails to initialize
a multi-monitor DisplayPort chain connected to a and AMD RX560
(Polaris11), rendering the system unusable in desktop configurations.
There is an oops earlier in the kernel output:

Jan  3 12:44:01 debutante kernel: [7.630953] WARNING: CPU: 2 PID: 69 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2293 
core_link_enable_stream+0x4b3/0xb90 [am
dgpu]
Jan  3 12:44:01 debutante kernel: [7.630954] Modules linked in: fuse 
binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp amdk
fd kvm_intel kvm irqbypass crct10dif_pclmul amdgpu crc32_pclmul 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 chash 
gpu_sched ghash_clmulni_intel snd_hda_
intel ttm snd_hda_codec intel_cstate cp210x mei_me snd_hda_core sr_mod cdrom 
drm_kms_helper snd_hwdep iTCO_wdt efi_pstore intel_uncore snd_pcm usbserial 
intel_rapl_perf cdc_acm
 joydev efivars sg evdev pcspkr mei parport_serial iTCO_vendor_support 
snd_timer drm snd i2c_algo_bit soundcore video pcc_cpufreq button ipmi_devintf 
ipmi_msghandler loop nfsd 
parport_pc auth_rpcgss ppdev nfs_acl lp lockd parport grace sunrpc efivarfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto btrfs
Jan  3 12:44:01 debutante kernel: [7.630978]  zstd_decompress zstd_compress 
xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor 
async_tx xor usb_storage
 raid6_pq libcrc32c raid1 raid0 multipath linear md_mod hid_generic usbhid hid 
sd_mod crc32c_intel ahci libahci xhci_pci libata aesni_intel xhci_hcd ehci_pci 
realtek ehci_hcd a
es_x86_64 i2c_i801 scsi_mod crypto_simd r8169 cryptd usbcore glue_helper libphy 
natsemi lpc_ich usb_common thermal fan
Jan  3 12:44:01 debutante kernel: [7.630993] CPU: 2 PID: 69 Comm: 
kworker/2:1 Tainted: P   OE 4.19.0-1-amd64 #1 Debian 4.19.12-1
Jan  3 12:44:01 debutante kernel: [7.630994] Hardware name: Gigabyte 
Technology Co., Ltd. H87-HD3/H87-HD3, BIOS F3 05/09/2013
Jan  3 12:44:01 debutante kernel: [7.631002] Workqueue: events_long 
drm_dp_mst_link_probe_work [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631043] RIP: 
0010:core_link_enable_stream+0x4b3/0xb90 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631044] Code: ff 48 89 ef be 01 00 00 
00 e8 b9 86 00 00 4c 89 ef 48 89 de e8 fe df ff ff bf c8 00 00 00 89 c5 e8 62 
67 26 fb e9 ea fd ff ff <0f> 0b e9 de fe ff ff 48 8b 82 50 02 00 00 48 8b 40 50 
48 8b 40 30
Jan  3 12:44:01 debutante kernel: [7.631045] RSP: 0018:a57081dd7668 
EFLAGS: 00010246
Jan  3 12:44:01 debutante kernel: [7.631046] RAX:  RBX: 
901ca62a4188 RCX: 
Jan  3 12:44:01 debutante kernel: [7.631046] RDX: 0005 RSI: 
c2349588 RDI: 0004
Jan  3 12:44:01 debutante kernel: [7.631047] RBP: 901cb7dede00 R08: 
0005 R09: 
Jan  3 12:44:01 debutante kernel: [7.631047] R10:  R11: 
a57081dd75c0 R12: 901ca89ed000
Jan  3 12:44:01 debutante kernel: [7.631048] R13: 901cb7dedf90 R14: 
901cb77f0400 R15: 0006
Jan  3 12:44:01 debutante kernel: [7.631048] FS:  () 
GS:901cbe08() knlGS:
Jan  3 12:44:01 debutante kernel: [7.631049] CS:  0010 DS:  ES:  
CR0: 80050033
Jan  3 12:44:01 debutante kernel: [7.631050] CR2: 7f586f069e20 CR3: 
4f20a002 CR4: 001606e0
Jan  3 12:44:01 debutante kernel: [7.631050] Call Trace:
Jan  3 12:44:01 debutante kernel: [7.631095]  ? 
dce110_stream_encoder_update_dp_info_packets+0x14c/0x200 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631133]  
dce110_apply_ctx_to_hw+0x63f/0x650 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631171]  dc_commit_state+0x2c6/0x520 
[amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631207]  ? 
set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631241]  ? 
mod_freesync_set_user_enable+0x11f/0x150 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631277]  
amdgpu_dm_atomic_commit_tail+0x388/0xdb0 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631280]  ? _cond_resched+0x15/0x30
Jan  3 12:44:01 debutante kernel: [7.631282]  ? 
wait_for_completion_timeout+0x3b/0x1a0
Jan  3 12:44:01 debutante kernel: [7.631318]  ? 
amdgpu_dm_atomic_commit_tail+0xdb0/0xdb0 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631325]  commit_tail+0x3d/0x70 
[drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631329]  
drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631333]  
restore_fbdev_mode_atomic+0x170/0x1d0 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631337]  
drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: 

Bug#915190: xemacs21-support: infinite loop in /etc/xemacs21/site-start.d

[Mark Brown]

On Sun, Dec 02, 2018 at 02:20:17PM +0900, Tatsuya Kinoshita wrote:
> reassign 909381 xemacs21-support
> forcemerge 915190 909381
> tags 915190 + patch
> thanks
> 
> See the following patch to fix this bug.

Which I didn't see because the mail only went to the control bot and the
pre-merged bug - it isn't even visble in the web view of the bug unless
you explicitly expand the message :(  It's better to add an explicit CC
to the maintainer to make sure the BTS does the right thing, the
defaults really aren't altogether helpful for reassignments and control
mail.  I'll just apply this just now, thanks...

> 
> ```
> --- a/debian/00debian.el
> +++ b/debian/00debian.el
> @@ -94,8 +94,4 @@
> )
> load-path))
>  
> -;; should now load from one of the /etc dirs since they are first in
> -;; the path now.
> -(load "site-start" t)
> -
>  ;;; end 00debian.el
> ```
> 
> This `(load "site-start" t)` was intended to load `/etc/emacs/site-start.el`,
> but unneeded now (dropped by emacsen-common 3.x).
> 
> cf. https://lists.debian.org/debian-emacsen/2018/06/msg00093.html
> > Date: Sat, 16 Jun 2018 11:04:27 -0500
> > From: Rob Browning 
> > Subject: [PATCH 3/4] Given new policy and emacsXY unversioning drop shared 
> > dirs
> > To: debian-emac...@lists.debian.org
> > Cc: Mark Brown 
> > 
> > ---
> >  debian/00debian.el | 7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> > 
> > diff --git a/debian/00debian.el b/debian/00debian.el
> > index 87508d5..fd06986 100644
> > --- a/debian/00debian.el
> > +++ b/debian/00debian.el
> > @@ -83,10 +83,6 @@ starting with a '.'"
> > (dir-and-all-good-subs
> >  (expand-file-name "~/.xemacs/packages"))
> > (list (concat "/etc/xemacs" debian-xemacs-major-version))
> > -   '("/etc/emacs")
> > -   (list (concat "/usr/local/share/emacs/xemacs-" debian-xemacs-version
> > - "/site-lisp"))
> > -   '("/usr/local/share/emacs/site-lisp")
> > `(,@(dir-and-all-good-subs "/usr/local/lib/xemacs/site-lisp")
> > ,@(dir-and-all-good-subs
> >(concat "/usr/share/xemacs/site-lisp-"
> > @@ -96,8 +92,7 @@ starting with a '.'"
> >(concat "/usr/share/xemacs" debian-xemacs-major-version
> >"/site-lisp/"))
> > )
> > -   load-path
> > -   '("/usr/share/emacs/site-lisp")))
> > +   load-path))
> >  
> >  ;; should now load from one of the /etc dirs since they are first in
> >  ;; the path now.
> > -- 
> > 2.15.1
> 
> Thanks,
> -- 
> Tatsuya Kinoshita




signature.asc
Description: PGP signature

Bug#908022: xemacs is not in testing/buster repo any more

[Mark Brown]

On Mon, Sep 10, 2018 at 06:00:05PM +0200, Agustin Martin wrote:

> For the records, emacsen-common 3.0.3, already in sid, seems to fix this
> dependency,

> emacsen-common (3.0.3) unstable; urgency=medium
> 
> * Don't conflict with xemacs21; it's now ready for 3.0.

Ah, great - then it should propagate through into testing shortly.


signature.asc
Description: PGP signature

Bug#908022: xemacs is not in testing/buster repo any more

[Mark Brown]

On Mon, Sep 10, 2018 at 12:08:15PM +0200, Chris Nospam wrote:

> unfortunately the problem still exists, although you have closed the bug. Is 
> there any time esitmation, as xemacs is my favorite editor?

Not really, it's dependent on Rob fixing the emacsen-common package to
not conflict with xemacs.  I've closed the bug because it's not a bug in
the package itself and will if anything only impede the package going
back into testing.


signature.asc
Description: PGP signature

Bug#908022: xemacs21: xemacs is not in testing/buster repo any more

[Mark Brown]

On Wed, Sep 05, 2018 at 09:53:38AM +0200, Christian Bachmaier wrote:

> today 9/5/18 'apt-get dist-upgrade' automatically removed xemacs (xemacs21,
> xemacs21-bin, ...) automatically from my buster/testing system.

Yes, this is an expected result of a partially done transition - we need
an update of the emacsen-common package which will remove a conflict.


signature.asc
Description: PGP signature

Bug#897573: You need to install the extra package

[Mark Brown]

On Mon, May 07, 2018 at 03:01:23PM +0200, Bastien ROUCARIES wrote:
> hi,
> 
> It is a feature you need to depends on extra package

It would have been rather more helpful if you were to mention which
package this is.  It would also have been helpful to have made some
effort to communicate this change to packages that build depend on yours
when making the change rather than just letting them break with zero
communication.

Please also note that -done mails only go to the submitter of a bug,
with duplicated bugs like this one 


signature.asc
Description: PGP signature

Bug#900358: O: nis -- clients and daemons for the Network Information Service (NIS)

[Mark Brown]

Package: wnpp
Severity: normal

I intend to orphan the nis package.

The package description is:
 This package provides tools for setting up and maintaining a NIS domain.
 NIS, originally known as Yellow Pages (YP), is mostly used to let
 several machines in a network share the same account information, such
 as the password file.
 This package provides tools for setting up and maintaining a NIS domain.
 NIS, originally known as Yellow Pages (YP), is mostly used to let
 several machines in a network share the same account information, such
 as the password file.

Note that the package really should be split into multiple source
packages but there's licensing problems which will cause problems
getting through new.

Bug#897551: usbview: FTBFS: convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No such file or directory @ error/constitute.c/ReadImage/544.

[Mark Brown]

clone 897551 -1
reassign -1 imagemagick
retitle -1 imagemagic: Errors converting SVG to PNG causing build failures
thanks

On Wed, May 02, 2018 at 10:55:01PM +0200, Lucas Nussbaum wrote:

> > make[2]: Entering directory '/<>'
> > convert -geometry $(basename $(dirname $(dirname 
> > hicolor/64x64/apps/usbview_icon.xpm))) usbview_icon.svg 
> > hicolor/64x64/apps/usbview_icon.xpm
> > convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ 
> > error/delegate.c/InvokeDelegate/1919.
> > convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No 
> > such file or directory @ error/constitute.c/ReadImage/544.
> > convert-im6.q16: no images defined `hicolor/64x64/apps/usbview_icon.xpm' @ 
> > error/convert.c/ConvertImageCommand/3258.
> > make[2]: *** [Makefile:964: hicolor/64x64/apps/usbview_icon.xpm] Error 1

> The full build log is available from:
>
> http://aws-logs.debian.net/2018/05/02/usbview_2.0-21-g6fe2f4f-1_unstable.log

This appears to be triggered by some internal bug in ImageMagick, the
"delegate failed" messsage doesn't appear to be an intentional error
message and I can't see any obvious indication that there's been an
intentional change in the ImageMagick CLI.


signature.asc
Description: PGP signature

Bug#883180: help with zlib package ?

[Mark Brown]

> On 27 Apr 2018, at 14:03, Jérémy Lal  wrote:
> 
> Not directly related, but kind of a bug
> please fix your email address broo...@debian.org: it isn't working.

I seem to get a reasonable amount of mail there and the test mail I just sent 
to myself arrived fine... whatever problem you believe exists you’ll have to 
tell me what it is. 

> 
> Jérémy 
> 

Bug#883180: help with zlib package ?

[Mark Brown]

On Fri, Apr 27, 2018 at 10:01:35AM +0200, Jérémy Lal wrote:

> I'd like to help maintaining zlib package.
> It really needs an update and a couple of fixes.

Which fixes?  I'm not aware of anything except the new version update...

> Could you either do something about it, or accept help ?

I've got an update 90% of the way there, I should really finish it off.
I'll take a look today.  Unfortunately all the last batch of releases
upstream did arrived during the middle of the freeze so nothing could
get uploaded for months and I lost track of it.


signature.asc
Description: PGP signature

Bug#836021: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable

[Mark Brown]

On Wed, Mar 28, 2018 at 12:27:03PM +0100, James Cowgill wrote:
> On 28/03/18 02:56, Mark Brown wrote:

> > bugs are useful for keeping it out of releases.

> I emailed the BTS with the diff on Thursday last week. The BTS says it
> forwarded the email to you:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853714#21

I'm seeing no sign of that mail having arrived on my systems.  No idea
what happened there...

> If you don't want the package in the next release, you should file a
> separate RC bug for it or at minimum email the bug explaining why it is
> still open.

I wasn't specifically using these bugs to keep the package out of
testing (it does no harm there, it's just not useful), the problem is
more that every out of tree patch added to the package makes it harder
to work with and make useful.


signature.asc
Description: PGP signature

Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable

[Mark Brown]

On Tue, Mar 27, 2018 at 08:51:30PM +, Debian FTP Masters wrote:

>* Non-maintainer upload.
>* debian/patches:
>  - Add patch to fix FTBFS with GCC 7. (Closes: #853714)
>  - Add patch to fix FTBFS on architectures with strict alignment
>requirements. (Closes: #836021)

Please don't send unnanounced non-maintainer uploads - note that this
package can't ever be usefully installed or used at the moment as the
rest of the NIS suite isn't split out into separate packages, the RC
bugs are useful for keeping it out of releases.


signature.asc
Description: PGP signature

Bug#890994: nis: ypbind started when the computer start without network

[Mark Brown]

On Wed, Feb 21, 2018 at 01:04:33PM +0100, adrien moulin wrote:

> On stretch when i start without network, the computer is very slow to
> launch the graphical interface and when i try to login on tty console there
> are important latency.

> After research the origin of the problem, i found that /etc/nsswitch.conf
> tried to bind nis because ypbind is launch but without network it can't do
> it. It seems there are no timeout on this.

This is normal and intended, ypbind will start and continue to run while
the network is disconnected so that when the network is ready NIS starts
working.  You probably shouldn't be using NIS on a computer that might
run disconnected, it's really not intended for that.  What's the use
case here?

> I hope there are an other solution with systemd but i can't find out for
> now.

Unfortunatly we need to support non-systemd init daemons as well, and I
expect them to have a disproportionately large subset of NIS users.


signature.asc
Description: PGP signature

Bug#867555: gnome-shell: Tries to drive monitor at unsupported refresh rate

[Mark Brown]

Package: gnome-shell
Version: 3.26.1-3
Followup-For: Bug #867555

This bug appears to have become *much* worse on a recent upgrade.  As
well as having once again forgotten my monitor settings I'm now seeing
almost any attempt to change settings away from the default resulting in
at least one of my monitors (generally my 16:9 primary display) being
disabled and there is no longer any visible refresh rate control so the
workaround I was previously using (lowering the refresh rate on the
primary display) is no longer available.

In addition it feels like the UI in the settings daemon has started
doing some kind of snap to grid thing for aligning the displays which
isn't helpful.

I can get things kind of working if I disable monitor 3, leave monitor 1
at the default resolution and leave monitor 2 with the top aligned with
the top of monitor 1 (it physically is much lower) but clearly this is a
substantial regression.  This affects both X11 and Wayland sessions.

My three monitors are:

  1: 2560x1440 DisplayPort
  2: 1280x1024 DVI
  3: 1280x1024 DVI

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

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

Versions of packages gnome-shell depends on:
ii  caribou  0.4.21-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-1
ii  evolution-data-server3.26.1-1
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.26.0-2
ii  gir1.2-caribou-1.0   0.4.21-2
ii  gir1.2-freedesktop   1.54.1-1
ii  gir1.2-gcr-3 3.20.0-5.1
ii  gir1.2-gdesktopenums-3.0 3.24.1-1
ii  gir1.2-gdm-1.0   3.26.1-3
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-glib-2.0  1.54.1-1
ii  gir1.2-gnomebluetooth-1.03.26.1-1
ii  gir1.2-gnomedesktop-3.0  3.26.1-1
ii  gir1.2-gtk-3.0   3.22.24-3
ii  gir1.2-gweather-3.0  3.26.0-1
ii  gir1.2-ibus-1.0  1.5.14-3
ii  gir1.2-mutter-1  3.26.1-6
ii  gir1.2-networkmanager-1.01.8.4-4
ii  gir1.2-nmgtk-1.0 1.8.4-1
ii  gir1.2-pango-1.0 1.40.12-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-rsvg-2.0  2.40.18-2
ii  gir1.2-soup-2.4  2.60.1-1
ii  gir1.2-upowerglib-1.00.99.6-1
ii  gjs  1.50.1-2
ii  gnome-backgrounds3.26.2-1
ii  gnome-settings-daemon3.26.1-2
ii  gnome-shell-common   3.26.1-3
ii  gsettings-desktop-schemas3.24.1-1
ii  libasound2   1.1.3-5
ii  libatk-bridge2.0-0   2.26.0-2
ii  libatk1.0-0  2.26.1-1
ii  libc62.24-17
ii  libcairo21.15.8-2
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.12-1
ii  libdbus-glib-1-2 0.108-2
ii  libecal-1.2-19   3.26.1-1
ii  libedataserver-1.2-223.26.1-1
ii  libgcr-base-3-1  3.20.0-5.1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libgirepository-1.0-11.54.1-1
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.50.1-2
ii  libglib2.0-0 2.54.2-1
ii  libglib2.0-bin   2.54.2-1
ii  libgstreamer1.0-01.12.3-1
ii  libgtk-3-0   3.22.24-3
ii  libical2 2.0.0-0.5+b1
ii  libjson-glib-1.0-0   1.2.8-1
ii  libmutter-1-03.26.1-6
ii  libnm-glib4  1.8.4-4
ii  libnm-util2  1.8.4-4
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  11.1-1
ii  libpulse011.1-1
ii  libsecret-1-0 

Bug#867555: gnome-shell: Tries to drive monitor at unsupported refresh rate

[Mark Brown]

On Fri, Jul 07, 2017 at 06:49:06PM +0100, Simon McVittie wrote:
> On Fri, 07 Jul 2017 at 13:20:28 +0100, Mark Brown wrote:

> > > * Move your ~/.config/monitors.xml out of the way (don't delete it; if
> > >   this works, it would be useful to see what's in it). This is where
> > >   GNOME stores display settings. You could also compare it with
> > >   ~/.config/monitors.xml~ which is the second-most-recent version.

> > Removing my monitors.xml appears to fix things, the difference appears
> > to be that if I try to make any change to the default layout of the
> > monitors monitor 1 goes blank.

> Thanks. It seems that the mode in which GNOME Shell brings up your
> displays when unconfigured is fine, but when you start reconfiguring
> (for which I assume you're using gnome-control-center, aka "Settings"?),
> some code that only runs during reconfiguration chooses an impossible
> mode. Hopefully this will be enough for someone more knowledgeable than
> me to narrow down which module has the problem.

This also happens during parsing of a preexisting copy of that file,
like I say this is something that has been working for a while and just
broke.

> > I'm using a default Debian system with systemd, I don't know how
> > specifically the X server is started. The X logs haven't been updated
> > for a long time.  There's no obvious X logs in .cache/gdm and I've no
> > idea how to get X logs from systemd.

> Please check /var/log/syslog (as root or a member of group adm), assuming
> you haven't removed rsyslogd. X logs go there via the systemd Journal;
> the Journal is in-memory-only by default, because writing it to disk
> is mostly redundant with having a syslogd.

I don't really know what I'm looking for in terms of display server
output in those logs, though I do see a few of these:

Jul 10 11:22:02 debutante gnome-shell[2360]: Failed to apply DRM plane 
transform 0: Invalid argument
Jul 10 11:22:02 debutante gnome-shell[2360]: Failed to apply DRM plane 
transform 0: Invalid argument
Jul 10 11:22:02 debutante gnome-shell[2360]: Failed to apply DRM plane 
transform 0: Invalid argument
Jul 10 11:22:03 debutante kernel: [  618.626812] 
[drm:cypress_dpm_set_power_state [radeon]] *ERROR* 
rv770_restrict_performance_levels_before_switch failed
Jul 10 11:22:04 debutante kernel: [  619.256880] 
[drm:cypress_dpm_set_power_state [radeon]] *ERROR* 
rv770_restrict_performance_levels_before_switch failed

so perhaps this is a kernel change.

> If you are intentionally living in the future, someone who knows more
> about the DRI/DRM stack than I do will have to tell you what the

Well, I'm just randomly changing settings in the hope that I can
persuade something to not render my primary development sysetm
unusuable.  I'm definitely running Wayland on my laptop as there's been
some previous issue which completely prevented login with X11 but it
seemed to work fine with Wayland but on this system I don't really care
(I've not noticed any problems).

> Wayland equivalent of xrandr is. Rummaging in /sys/class/drm/card*/modes,
> or using parse-edid < /sys/class/drm/cardwhatever/edid (parse-edid is
> in the read-edid package), might be informative?

I don't appear to have a parse-edid installed.


signature.asc
Description: PGP signature

Bug#867555: gnome-shell: Tries to drive monitor at unsupported refresh rate

[Mark Brown]

On Fri, Jul 07, 2017 at 12:44:46PM +0100, Simon McVittie wrote:

> My first question is, what graphics hardware and driver is this?

It's this:

05:00.0 VGA compatible controller: Advanced Micro Devices, Inc.  [AMD/ATI] 
Cedar [Radeon HD 5000/6000/7350/8350 Series]

using whatever Debian drives it with by default.

> Other things you could try:
> 
> * Run xrandr --verbose (X11 only, not useful in Wayland)

Attached.

> * Move your ~/.config/monitors.xml out of the way (don't delete it; if
>   this works, it would be useful to see what's in it). This is where
>   GNOME stores display settings. You could also compare it with
>   ~/.config/monitors.xml~ which is the second-most-recent version.

Removing my monitors.xml appears to fix things, the difference appears
to be that if I try to make any change to the default layout of the
monitors monitor 1 goes blank.  This has worked for a considerable time.

> * Look for mentions of EDID, DDC or mode in the Xorg log
>   (could be /var/log/Xorg.*.log, ~/.cache/gdm/* or the systemd Journal
>   depending how your X server was started)

I'm using a default Debian system with systemd, I don't know how
specifically the X server is started. The X logs haven't been updated
for a long time.  There's no obvious X logs in .cache/gdm and I've no
idea how to get X logs from systemd.
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 8192 x 8192
XWAYLAND0 connected 2560x1440+0+0 (0x26) normal (normal left inverted right x 
axis y axis) 550mm x 310mm
Identifier: 0x21
Timestamp:  8824845
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 0.0
Clones:
CRTC:   0
CRTCs:  0
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
  2560x1440 (0x26) 312.000MHz -HSync +VSync *current +preferred
h: width  2560 start 2752 end 3024 total 3488 skew0 clock  89.45KHz
v: height 1440 start 1443 end 1448 total 1493   clock  59.91Hz
XWAYLAND1 connected 1280x1024+2560+0 (0x27) normal (normal left inverted right 
x axis y axis) 380mm x 300mm
Identifier: 0x23
Timestamp:  8824845
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 0.0
Clones:
CRTC:   1
CRTCs:  1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
  1280x1024 (0x27) 109.000MHz -HSync +VSync *current +preferred
h: width  1280 start 1368 end 1496 total 1712 skew0 clock  63.67KHz
v: height 1024 start 1027 end 1034 total 1063   clock  59.89Hz
XWAYLAND2 connected 1280x1024+3840+0 (0x27) normal (normal left inverted right 
x axis y axis) 340mm x 270mm
Identifier: 0x25
Timestamp:  8824845
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 0.0
Clones:
CRTC:   2
CRTCs:  2
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
  1280x1024 (0x27) 109.000MHz -HSync +VSync *current +preferred
h: width  1280 start 1368 end 1496 total 1712 skew0 clock  63.67KHz
v: height 1024 start 1027 end 1034 total 1063   clock  59.89Hz


monitors.xml.old
Description: application/trash


signature.asc
Description: PGP signature

Bug#867555: gnome-shell: Tries to drive monitor at unsupported refresh rate

[Mark Brown]

Package: gnome-shell
Version: 3.22.3-3
Severity: important

A recent upgrade on my system appears to have caused GNOME to drive one
of my monitors at an unsupported refresh rate after login (gdm is fine).
After login my primary display goes into power saving mode though GNOME
appears to think it's fine.  Changing my GNOME session to Wayland caused
the monitor to display an error message about the unsupported refresh
rate, I am able to use the monitor if I lower the refresh rate.

This may not be a bug in gnome-shell but I don't know which package is
responsible.  Both GNOME and X got upgrades.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  evolution-data-server3.22.7-1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-atspi-2.0 2.24.1-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-freedesktop   1.50.0-1+b1
ii  gir1.2-gcr-3 3.20.0-5.1
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.3-4
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomebluetooth-1.03.20.1-1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.16-1
ii  gir1.2-gweather-3.0  3.20.4-1
ii  gir1.2-ibus-1.0  1.5.14-3
ii  gir1.2-mutter-3.03.22.4-2
ii  gir1.2-networkmanager-1.01.8.0-5
ii  gir1.2-nmgtk-1.0 1.8.2-1
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-2
ii  gir1.2-upowerglib-1.00.99.4-4+b1
ii  gjs  1.46.0-1+b2
ii  gnome-backgrounds3.22.1-1
ii  gnome-settings-daemon3.22.2-4
ii  gnome-shell-common   3.22.3-3
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.12-1
ii  libdbus-glib-1-2 0.108-2
ii  libecal-1.2-19   3.22.7-1
ii  libedataserver-1.2-223.22.7-1
ii  libgcr-base-3-1  3.20.0-5.1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-1+b1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1+b2
ii  libglib2.0-0 2.52.3-1
ii  libglib2.0-bin   2.52.3-1
ii  libgstreamer1.0-01.12.1-2
ii  libgtk-3-0   3.22.16-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-6
ii  libjson-glib-1.0-0   1.2.8-1
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmutter0i  3.22.4-2
ii  libnm-glib4  1.8.0-5
ii  libnm-util2  1.8.0-5
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  10.0-2
ii  libpulse010.0-2
ii  libsecret-1-00.18.5-3.1
ii  libstartup-notification0 0.12-4+b2
ii  libsystemd0  233-10
ii  libtelepathy-glib0   0.24.1-1.1
ii  libwayland-client0   1.12.0-1
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  mutter   

Bug#864418: lava-tool: Attempting to cancel invalid job produces Python traceback

[Mark Brown]

Package: lava-tool
Version: 0.21-1
Severity: normal

Attempting to cancel a non-existant job produces a Python traceback:

Traceback (most recent call last):
  File "/usr/bin/lava-tool", line 11, in 
load_entry_point('lava-tool==0.21', 'console_scripts', 'lava-tool')()
  File "/usr/lib/python2.7/dist-packages/lava_tool/dispatcher.py", line 49, in 
main
LavaDispatcher.run()
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 150, in 
run
raise SystemExit(cls().dispatch(args))
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 140, in 
dispatch
return command.invoke()
  File "/usr/lib/python2.7/dist-packages/lava_scheduler_tool/commands.py", line 
202, in invoke
server.scheduler.cancel_job(self.args.JOB_ID)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
  File "/usr/lib/python2.7/dist-packages/lava_tool/authtoken.py", line 349, in 
request
return self.parse_response(response)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response
return u.close()
  File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: 

rather than simply displaying an error message indicating that the job
doesn't exist.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lava-tool depends on:
ii  python 2.7.13-2
ii  python-jinja2  2.8-1
ii  python-requests2.12.4-1
ii  python-setuptools  33.1.1-1
ii  python-xdg 0.25-4
ii  python-yaml3.12-1
ii  python-zmq 16.0.2-2
ii  python2.7  2.7.13-2

Versions of packages lava-tool recommends:
ii  ca-certificates  20161130+nmu1

lava-tool suggests no packages.

-- no debconf information

Bug#864417: lava-tool: Python exception splat attempting to list jobs

[Mark Brown]

Package: lava-tool
Version: 0.21-1
Severity: normal

When attempting to list jobs on my server I get:

$ lava-tool jobs-list http://broo...@lava.sirena.org.uk/RPC2
Traceback (most recent call last):
  File "/usr/bin/lava-tool", line 11, in 
load_entry_point('lava-tool==0.21', 'console_scripts', 'lava-tool')()
  File "/usr/lib/python2.7/dist-packages/lava_tool/dispatcher.py", line 49, in 
main
LavaDispatcher.run()
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 150, in 
run
raise SystemExit(cls().dispatch(args))
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 140, in 
dispatch
return command.invoke()
  File "/usr/lib/python2.7/dist-packages/lava_scheduler_tool/commands.py", line 
319, in invoke
jobs_list = server.scheduler.all_jobs()
  File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
  File "/usr/lib/python2.7/dist-packages/lava_tool/authtoken.py", line 349, in 
request
return self.parse_response(response)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1491, in parse_response
p.close()
  File "/usr/lib/python2.7/xmlrpclib.py", line 567, in close
parser.Parse("", 1) # end of data
xml.parsers.expat.ExpatError: no element found: line 613922, column 12

There are rather a lot of jobs but this shouldn't happen.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lava-tool depends on:
ii  python 2.7.13-2
ii  python-jinja2  2.8-1
ii  python-requests2.12.4-1
ii  python-setuptools  33.1.1-1
ii  python-xdg 0.25-4
ii  python-yaml3.12-1
ii  python-zmq 16.0.2-2
ii  python2.7  2.7.13-2

Versions of packages lava-tool recommends:
ii  ca-certificates  20161130+nmu1

lava-tool suggests no packages.

-- no debconf information

Bug#862260: zlib: debian/copyright isn't in DEP5 format

[Mark Brown]

severity 862260 wishlist
tag 862260 - patch
kthxbye

On Wed, May 10, 2017 at 06:21:09PM +0700, Do Thanh Trung wrote:

> +Files: *
> +Copyright: 1995-2013 Jean-loup Gailly and Mark Adler
> +License: Zlib
> + This software is provided 'as-is', without any express or implied
> + warranty.  In no event will the authors be held liable for any damages
> + arising from the use of this software.

As Stephen indicated not all the files in the package are under the same
license.  I guess I'm OK with doing the conversion but it needs to be
accurate.


signature.asc
Description: PGP signature

Bug#859661: chromium: Poor integration with gnome-shell after extension removal

[Mark Brown]

Package: chromium
Version: 57.0.2987.98-1
Severity: important

With the removal of extension support there is a NEWS.Debian entry
recommending that either a command line option or an environment
variable is set to reenable them if users rely on them.  Unfortunately
there is no information provided on how to actually accomplish either of
these things and no visible facility to do them exists for this in GNOME
3 which is a pretty standard desktop for Debian.  This results in a very
poor user experience, more technical users will probably figure this out
but less technical users who wish to use extensions will struggle to
understand what they're being asked to do (or why).  It's entirely
likely that some will never see the NEWS.Debian entry in the first
place.

We should do a much better job of explaining this change to users.  It
really should be something directly controllable through the browser UI,
or a "with extensions" version of Chromium could be provided in the
system menus.  Documenting some "create a file here" workaround would
probably work as well though it is a bit less discoverable.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.4-1
ii  libavformat577:3.2.4-1
ii  libavutil55  7:3.2.4-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.16-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3+b2
ii  libgcc1  1:6.3.0-11
it  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.4-1
ii  libstdc++6   6.3.0-11
ii  libvpx4  1.6.1-3
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b4
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#854376: gnupg-agent: Broken with systemd

[Mark Brown]

Package: gnupg-agent
Version: 2.1.18-4
Severity: important

I've got:

  SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent

(this is manually forced since gnome-keyring appears to be managing to
force itself as the SSH agent, I've filed a separate bug about that).
When I try to list keys I get:

   $ ssh-add -L
   error fetching identities for protocol 2: invalid format
   The agent has no identities.

Similarly attempting to SSH result in:

   debug1: pubkey_prepare: ssh_fetch_identitylist: invalid format

in the SSH verbose output.  If I manually disable all the systemd based
activation and start gpg-agent from the command line with --daemon then
the problem is resolved and I can happily authenticate.

Severity important since this is preventing me logging into remote
systems (including in my case kernel.org which is preventing me doing
upstream kernel work right now).

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

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

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-9
ii  libgcrypt20 1.7.6-1
ii  libgpg-error0   1.26-2
ii  libnpth01.3-1
ii  libreadline77.0-2
ii  pinentry-gnome3 [pinentry]  1.0.0-1
ii  pinentry-gtk2 [pinentry]1.0.0-1

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-4

Versions of packages gnupg-agent suggests:
ii  dbus-user-session  1.10.14-1
ii  libpam-systemd 232-15
ii  pinentry-gnome31.0.0-1
ii  scdaemon   2.1.18-4

-- no debconf information

Bug#854318: gnome-keyring: Attempts to provide ssh-agent

[Mark Brown]

On Mon, Feb 06, 2017 at 02:29:40AM +0100, Michael Biebl wrote:
> Am 06.02.2017 um 00:43 schrieb Mark Brown:

> > I have previously removed /etc/xdg/autostart/gnome-keyring-ssh.desktop
> > (which is still removed) but it appears that this is now triggred by
> > systemd somehow.

> Might this be a gnupg-agent issue?

Well, the first order problem I'm seeing here is that SSH_AUTH_SOCK is
set to /run/user/1000/keyring/ssh so GnuPG isn't getting a look in.

> I see it enables
> /usr/lib/systemd/user/sockets.target.wants/gpg-agent-ssh.socket by default.

> What happens if you run
> systemctl --user mask gpg-agent-ssh.socket
> systemctl --user stop gpg-agent-ssh.socket

This does nothing visible with regard to SSH.

Whenever I've had to fix this before half the problem is that GnuPG
doesn't provide a SSH agent if something else is doing it so the usual
problem is getting rid of GNOME keyring, after that's gone the problem
is normally resolved.


signature.asc
Description: PGP signature

Bug#854318: gnome-keyring: Attempts to provide ssh-agent

[Mark Brown]

Package: gnome-keyring
Version: 3.20.0-3
Severity: important

A recent upgrade to gnome-keyring appears to have resulted in it once
again trying to provide a SSH agent.  Since I use a gnupg smartcard to
store my authentication keys for SSH (which is supported by GnuPG but
not by gnome-keyring) this breaks my ability to SSH into most remote
systems, including things like preventing me from doing anything on
kernel.org.

I have previously removed /etc/xdg/autostart/gnome-keyring-ssh.desktop
(which is still removed) but it appears that this is now triggred by
systemd somehow.

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

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

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.14-1
ii  dbus-x11 [dbus-session-bus]   1.10.14-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2
ii  gcr   3.20.0-3
ii  libc6 2.24-9
ii  libcap-ng00.7.7-3
ii  libcap2-bin   1:2.25-1
ii  libgck-1-03.20.0-3
ii  libgcr-base-3-1   3.20.0-3
ii  libgcrypt20   1.7.6-1
ii  libglib2.0-0  2.50.2-2
ii  p11-kit   0.23.3-5
ii  pinentry-gnome3   1.0.0-1

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.20.0-3

gnome-keyring suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/gnome-keyring-ssh.desktop [Errno 2] No such file or 
directory: '/etc/xdg/autostart/gnome-keyring-ssh.desktop'

-- no debconf information

Bug#849000: Upstream Updates and Packaging

[Mark Brown]

On Wed, Feb 01, 2017 at 12:42:38PM +, Barak A. Pearlmutter wrote:

> Okay. I'm including a diff from 2.0-3 to the debian/* subdir below.
> I'm sending a tarball of an upstream snapshot (commit 6fe2f4f) under
> separate cover without a BTS CC, because it seems silly to include it
> as an attachment. I am however including below a log of the nontrivial
> upstream commits, along with file change histograms, so you can see
> what's what.

You're missing the point here - the problem here is having to do some
combination of reverse engineering the diff and fiddling through the git
history to extract individual, reviewable changes so I can find out what
happened.  If the package were maintained in git this would work a lot
better but it's not so I've just got this big lump that's been thrown
over the wall at me.

> BTW, this kind of thing is really easy w/ git, each of the above is a
> single short command. Github also exports snapshots as tarballs at
> some magic URLs. If you need anything like that in the future just let
> me know.

I'm more than familiar with git.


signature.asc
Description: PGP signature

Bug#849000: Upstream Updates and Packaging

[Mark Brown]

On Wed, Dec 21, 2016 at 04:58:24PM +, Barak A. Pearlmutter wrote:

> to support some modern devices etc. I have also done a revision pass
> on the packaging scripts to enable a desktop file hooked into
> policykit, harden the executable (which after all sees unsanitised
> data from removable devices) etc. These are in

> https://github.com/barak/usbview
> branch: master

Can you please send these as normal patches rather than pointing to a
git repository when the package isn't maintained in git?  One of the
reasons it's taken me a while to get round to this is that it's effort
to figure out how to get packaging out of git.


signature.asc
Description: PGP signature

Bug#853781: git am ignores messages in Maildirs

[Mark Brown]

Package: git
Version: 1:2.11.0-2
Severity: important

When running

  $ git am --signoff $MAILDIR

git will frequently not even attempt to apply some of the patches in the
Maildir.  I can't see any obvious pattern in the messages being ignored,
but it does seem to happen with excessive regularity making the program
very error prone and cumbersome to use.  I can supply a Maildir
(reportbug doesn't seem to have any attachment support).

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

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

Versions of packages git depends on:
ii  dpkg 1.18.15
ii  git-man  1:2.11.0-1
ii  libc62.24-8
ii  libcurl3-gnutls  7.51.0-1
ii  liberror-perl0.17024-1
ii  libexpat12.2.0-1
ii  libpcre3 2:8.39-2
ii  perl 5.24.1~rc4-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.3p1-5
ii  patch2.7.5-1
ii  rsync3.1.2-1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-1
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.11.0-1
ii  git-el1:2.11.0-1
ii  git-email 1:2.11.0-1
ii  git-gui   1:2.11.0-1
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.11.0-1
pn  gitweb

-- no debconf information

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Jan 07, 2017 at 11:15:51AM +0100, Matthias Klose wrote:

> multiarch is not yet ready; you can't build it on the buildds, you can't 
> depend
> on foreign architectures on the buildds.  If you want to spend some time 
> working
> on this, it would be appreciated, but until then I think it's better to make
> these packages working.

Right, but as I said before it doesn't seem like anyone is doing that
with programs written in D and it also doesn't seem likely that they'll
start soon.  I'm just not seeing the users here.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Fri, Jan 06, 2017 at 08:48:06AM +0100, Matthias Klose wrote:
> On 05.12.2016 18:50, Mark Brown wrote:

> > As we have been discussing it is still not clear to me if I should fix
> > or remove the multilib packages since it is still not clear to me that
> > there is a sensible use case for them.  As things stand I'm still not
> > seeing much of a use case here so it seems like the best thing to do
> > would be to remove the multilibs.

> If this didn't become clear, may I suggest to fix the packages for the release
> instead of removing them?

I got that, what I still don't have a handle on is why that's a good
idea - it was a worrying struggle to understand what was going on and
even now that I think I've got that figured out it feels like something
that's just being done by default and I am concerned that the packages
will do more harm than good given the confusion they can cause with
respect to multiarch.


signature.asc
Description: PGP signature

Bug#847270: closed by Mark Brown <broo...@debian.org> (Re: Bug#847270: zlib CVE-2016-9840 and CVE-2016-9841)

[Mark Brown]

On Wed, Dec 07, 2016 at 07:21:02PM +0100, Salvatore Bonaccorso wrote:
> > On Wed, Dec 07, 2016 at 12:31:43PM +0100, Salvatore Bonaccorso wrote:

> > That's because you filed three different bug reports about CVEs all with
> > just boilerplate and no directly readable content about them, mainly a

> Will do  next time probably four reports. But: It was not just
> boilerplate. If you look at all three reports I collected the upstream
> commits relative to the CVE, and as well linked to the
> security-tracker which leads you to the CVE assignments and more

Sorry, when I say that the content was boilerplate with no directly
readable content what I mean is that the human readable bits were
boilerplate - the links you'd collected were of course distinct but the
actual text of the report was essentially the same between all of them
(indeed it took me a couple of goes to realize that the reports were
actually different).  It was just the formatting, of course I should
have been clear and I realize there was work went into collecting the
links to the commits and trackers.


signature.asc
Description: PGP signature

Bug#845793: Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Mon, Dec 05, 2016 at 06:24:46PM +0100, Matthias Klose wrote:
> On 05.12.2016 18:14, Mark Brown wrote:

> > I am suggesting that since nothing except for the multlib D runtime
> > packages needs a multilib zlib and there seems to be a very limited use
> > case for them it seems better to just not ship the multilib runtime for
> > D and instead have people who want to build or run non-native D code use
> > multiarch.  That's where we want to get to anyway.

> >> PS: I pinged about a) moving back zconf.h to /usr/include and b) running
> >> dh_makeshlibs for the 64bit multilib variant. Any update on this?

> > I saw your content free pings.

> If the ping should have been content free, than the content should be in the 
> PS.
>  Or please could you tell me what you are missing?

As we have been discussing it is still not clear to me if I should fix
or remove the multilib packages since it is still not clear to me that
there is a sensible use case for them.  As things stand I'm still not
seeing much of a use case here so it seems like the best thing to do
would be to remove the multilibs.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Mon, Dec 05, 2016 at 04:40:29PM +0100, Matthias Klose wrote:
> On 05.12.2016 11:29, Mark Brown wrote:
> > On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote:

> >> it's available in the GCC packages for a while now.

> > Sure, but there's a bunch more stuff needed.

> sorry, I don't understand what you mean.

Getting full x32 support is going to require more than just the
compiler.

> Well, there are less requirements for the C and C++ runtime libraries 
> (basically
> glibc), but the D runtime library requires one more, zlib. I'm not sure what 
> you
> are arguing here.

I am suggesting that since nothing except for the multlib D runtime
packages needs a multilib zlib and there seems to be a very limited use
case for them it seems better to just not ship the multilib runtime for
D and instead have people who want to build or run non-native D code use
multiarch.  That's where we want to get to anyway.

> PS: I pinged about a) moving back zconf.h to /usr/include and b) running
> dh_makeshlibs for the 64bit multilib variant. Any update on this?

I saw your content free pings.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote:
> On 30.11.2016 13:45, Mark Brown wrote:

> > Well, there's a bunch of questions there - people seem generally
> > negative on x32 and the use cases for multilib with tooling for early
> > boot and so on don't seem to apply in any case.  I'd really have
> > expected that it'd just be added as a new architecture at this point.

> it's available in the GCC packages for a while now.

Sure, but there's a bunch more stuff needed.

> > install the multiarch runtime?  The motivation I'm aware of for still
> > having the multilib packages is to allow other multilib packages to be
> > built with them but I'm not seeing any packages written in D (and it'd
> > be pretty surprising TBH given the narrow use case) so I'm not seeing
> > the use case.

> If we remove everything where "people seem generally negative on FOO", we'll 
> end
> up with a really small distro. We still require the multilibs for 32bit
> architectures needing to build 64bit kernels, and I'd rather not ask people to
> work around issues when they can be fixed.

These are good reasons for having multilib for C and (to a bit of a
lesser extent) C++ but this is D which is a different thing - it's a new
language which is much less widely used.  It is much more difficult to
see the use case for D, as far as I can tell the applications don't
really need multilibs.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote:
> On 28.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:

> > Which apparently changed at some point in the toolchain, probably quite
> > some time ago, but fortunately we'd actually managed to remove all the
> > users before that happened so it didn't affect anyone.

> Wrong. Until the zconf.h header was moved from /usr/include to
> /usr/include/ these packages found the *wrong* header in
> /usr/include, now they don't find anything anymore.

So that'll be what changed.  But really this is a bug in the multiarch
support, zconf.h isn't at all architecture specific within the context
of Debian (there's a few things that change but they're all related to
completely non-Unix OSs).

> > Right now as far as I can tell there's been some change in the GNU D
> > compiler that's attempting to add usage of the multilib zlib versions
> > for some reason which is not at all clear to me.  You said something
> > about moving the GDC runtime to a shared library but I'm finding that
> > confusing as the issue with the header file as should also affect static
> > usage so it seems like there must be something else in the mix
> > somewhere.

> The libphobos configury falls back to the zlib copy shipped within the GCC
> sources, when the system zlib cannot be used. So sure, dropping the build
> dependencies on the multilib zlib packages does use the embedded copy, but
> that's not what you usually want to do.

OK, so this makes at least that part of things clearer.  It's not a
result of linking against the DSO but rather a result of not using an
embedded copy of the source.

> > It seems there's also something going on with x32 but as far as I can
> > tell that's orthogonal though it does seem to be related to changes in
> > GDC as well somehow.

> that's just the third multilib on amd64 and i386.

Well, there's a bunch of questions there - people seem generally
negative on x32 and the use cases for multilib with tooling for early
boot and so on don't seem to apply in any case.  I'd really have
expected that it'd just be added as a new architecture at this point.

> > Shouldn't people building i386 D programs on amd64 (or other similar
> > builds that would historically have been done with multilib) just be
> > using multiarch to install the 32 bit runtime?  Please bear in mind
> > that I'm not at all familiar with D here.

> there's nothing you need to understand with D, just that it tries to use zlib 
> as
> a dependency.

No, it's trying to use a multilib zlib as a dependency.  That's still
really unclear to me here - to repeat my question above why aren't we
asking people who want to build non-native D applications to just
install the multiarch runtime?  The motivation I'm aware of for still
having the multilib packages is to allow other multilib packages to be
built with them but I'm not seeing any packages written in D (and it'd
be pretty surprising TBH given the narrow use case) so I'm not seeing
the use case.

> So removing these packages is fine with me too; in this case, please wait with
> the removal and I'll prepare a new source package to build these multilib
> libraries for the stretch release.

No, that's obviously not a good solution as it just ends up duplicating
the source.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sun, Nov 27, 2016 at 06:39:22PM +0200, Sami Liedes wrote:

> It seems to me that Mark is saying that this is not even supposed to
> work with lib32z1-dev installed, but rather you should have
> zlib1g-dev:i386 installed (and not doing so is user error).

Right, that's now the expected way for users to get an i386 version on
amd64.

> I found this surprising (and wonder what lib32z1-dev is actually for
> then), but as I don't know how these packages are supposed to work, I
> won't take a position. I am happy enough that I got things working by
> installing zlib1g-dev:i386.

In the past before Debian supported coinstallation of packages from
multiple architectures on one system (multiarch) some packages like zlib
were built specially to provide binaries for one architecture in
packages for another architecture (so lib32z1 is a 32 bit version of
zlib built as a package for a 64 bit architecture for example).  This
was called multilib and the goal has been to phase it out in favour of
using multiarch.

It appears that there have been changes in the toolchain that mean that
broke the multilib packages (I'm guessing that it was some of the
multiarch implementation) but given the availability of multiarch which
supports all libraries rather than just ones that have been specially
built people should be using that instead.  There are some cases where
the infrastructure isn't able to cope yet which may be what's going on
here but they definitely don't apply to end users.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:
> On 26.11.2016 20:35, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> >> On 26.11.2016 19:42, Mark Brown wrote:
> >>> On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:

> >> This exactly is the correct issue, not "some random bug".

> > I'm afraid I'm still unclear what you are trying to do or why.

> well, you removed the example from your reply and didn't comment on it.

That is one of several different things you've been talking about which
seem to be related somehow to at least one underlying goal.  I'm still
trying to figure out that underlying goal here to work out what the most
sensible thing to do is.

> The example fails because the zconf.h header is not found. You can see the 
> list
> of the standard include paths when calling gcc with the -v option.

Which apparently changed at some point in the toolchain, probably quite
some time ago, but fortunately we'd actually managed to remove all the
users before that happened so it didn't affect anyone.

Right now as far as I can tell there's been some change in the GNU D
compiler that's attempting to add usage of the multilib zlib versions
for some reason which is not at all clear to me.  You said something
about moving the GDC runtime to a shared library but I'm finding that
confusing as the issue with the header file as should also affect static
usage so it seems like there must be something else in the mix
somewhere.

It seems there's also something going on with x32 but as far as I can
tell that's orthogonal though it does seem to be related to changes in
GDC as well somehow.

As things stand it seems like the best thing to do just looking at this
issue by itself is remove the multilib zlib packages since they've been
broken for some time without anyone noticing and we have multiarch so
there shouldn't be any need for new users.  However I don't want to just
upload that right now since you're looking to add new users though I'm a
bit confused as to why, it seems like a step backwards.

Shouldn't people building i386 D programs on amd64 (or other similar
builds that would historically have been done with multilib) just be
using multiarch to install the 32 bit runtime?  Please bear in mind
that I'm not at all familiar with D here.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> On 26.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:

> > Please allow at least a little time for a response, I've no real idea
> > what you're even asking for here.

> well, I asked you in private before, without getting replies on all messages 
> and
> proposals.

You sent me a mail last week asking for some additional multilib
packages for x32 ABI which seemed a bit strange at this point in the
release cycle and not that urgent as a new ABI would be at most
wishlist.  I'd been intending to have a look to try to work out what's
going on with x32 over the weekend.  I'm having a hard time relating
that to what you're talking about here though I do see you mentioned
that this was for "libgphobos (gdc runtime)" in both.

> This exactly is the correct issue, not "some random bug".

I'm afraid I'm still unclear what you are trying to do or why.  This is
a bug about trying to use the lib32z1-dev package, your private mails
were about adding x32 multilib packages and I'm really confused about
how either of these things relates to the shared libgphobos you keep
mentioning.  The proposed changes below don't have anything to do with
x32 either so I'm just completely confused now.

Can you please provide a clear, from first steps description of what's
needed and why?

> attaching the diff for the proposed changes

Please do not upload this, I will be back at home on Monday and can do
an upload then and...

> +  * Non-maintainer upload.
> +  * Install the zconf.h header file for the multilib packages. Closes: 
> #787956.
> +  * Use the target prefixed ar, available since binutils 2.26.
> +  * Run dh_makeshlibs for the 64bit multilib library.
> +  * Add ${misc:Depends} to zlib1g-dbg's dependencies.
> +  * Support nobiarch build profile (Johannes Schauer). Closes: #709623.

...this clearly isn't just fixing the bug and there are a bunch of
additional changes not mentioned in the changelog.  

I need to investigate what's going on here as I'm unconvinced that this
doesn't introduce further problems (will this break multiarch for
example, I appear to be able to build with -m32...).  This might be a
lot clearer with split out incremental patches and really seems
inappropriate for a zero notice NMU.

> -Standards-Version: 3.9.4
> +Standards-Version: 3.9.8

If you're making changes like this they ought to be mentioned in the
changelog.

> -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) 
> [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc 
> ppc64 s390 sparc s390x], dpkg-dev (>= 1.16.1)
> +Build-Depends: debhelper (>= 9), gcc-multilib [amd64 i386 kfreebsd-amd64 
> mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)

Not sure why the debhelper dependency got changed or why we dropped the
binutils dependency.

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

On Sun, Oct 23, 2016 at 02:06:29AM +0200, Marco d'Itri wrote:
> On Oct 23, Mark Brown <broo...@debian.org> wrote:

> > I'd have expected to at least have seen something going round saying
> > that the transition was mostly complete and that there were only a few
> > packages blocking it prior to just dumping a new version of deboostrap
> > in unstable and rendering everything instabuggy.  Most similar

> I did this in *february* for the other packages, but not this one since 
> you had recently suggested that it was not ready anyway.

Telling other package maintainers doesn't help me know that this is a
transition that's actually happening, and one of the things that would
tell me that there might be some sense of urgency would be an indication
that the transition was actually happening.  I do remember you asking me
about my plans to fix it but there was no context that this was anything
more than a "hey, it'd be nice sometime".  For things like this even if
people aren't working on something now if there's a bigger picture it's
good to tell people about it, something like "OK, but please note that
we're actively working on this transition and expect it to be done for
stretch" would've really helped here in avoiding surprise with sudden RC
bugs out of nowhere.

> > I didn't ask for help because I just don't care about this transition,
> > in part because as I indicated there's no way to really use yp-tools at
> > present so it's the least of anyone's worries so when I'm spending time

> Maybe then the package should not be in testing anyway?

It's not impossible that someone could use it, it's just not as useful
as it could be.


signature.asc
Description: PGP signature

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

On Sun, Oct 23, 2016 at 01:18:54AM +0200, Marco d'Itri wrote:
> On Oct 23, Mark Brown <broo...@debian.org> wrote:

> > Which was uploaded yesterday without warning which isn't exactly
> > helpful, there's not even been a proposal from anyone working on this
> > for how to fix it.  I would expect that if something like this were
> > going to be imposed it'd be imposed towards the start of the release
> > cycle rather than at the very end.

> We have been discussing switching to merged /usr for over two years and 
> there are just five broken packages left, all of them rarely used.

My expectation is that the people working on a transition like this
would be pushing it forwards - things get talked about for a long time
often (and Debian is quite big so the fact that some people have been
talking about it doesn't mean everyone knows), there's a difference
between talking about something and it actually happening.  In the case
of merging / and /usr it's been talked about for pretty much as long as
I've been involved in Debian but the change in bug severity was the
first indiciation I'd had that there was a chance of it actually being
implemented.

I'd have expected to at least have seen something going round saying
that the transition was mostly complete and that there were only a few
packages blocking it prior to just dumping a new version of deboostrap
in unstable and rendering everything instabuggy.  Most similar
transitions have come along with patches (usually quite early on in the
process) though it's not always possible, in this case I suspect it is.

> This bug has been open since january and you never asked for help 
> (actually you hinted that yp-tools was useless anyway as is).

I didn't ask for help because I just don't care about this transition,
in part because as I indicated there's no way to really use yp-tools at
present so it's the least of anyone's worries so when I'm spending time
on these packages it'd be on the things that are required to make the
package more practically useful.

> We (people interested in merged /usr) are not going to waste another 
> release cycle.

That doesn't mean it's a good idea to just implement the transition
quite late in the release cycle without making any effort to coordinate
with the affected packages.  Some advance warning would have made all
the difference here.


signature.asc
Description: PGP signature

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

severity 812532 serious

On Sun, Oct 23, 2016 at 12:36:18AM +0200, Marco d'Itri wrote:
> Control: severity -1 grave

Please don't play severity games, it's not at all helpful.  

> On Jan 24, Marco d'Itri  wrote:

> > which have the same name of file installed by the hostname package in 
> > /bin/, so this breaks the package when installed on a marged /usr system.

> Merged /usr is the default since debootstrap 1.0.85, so the package
> is uninstallable on new systems.

Which was uploaded yesterday without warning which isn't exactly
helpful, there's not even been a proposal from anyone working on this
for how to fix it.  I would expect that if something like this were
going to be imposed it'd be imposed towards the start of the release
cycle rather than at the very end.


signature.asc
Description: PGP signature

Bug#837712: Processed: severity of 837712 is serious

[Mark Brown]

On Fri, Oct 21, 2016 at 05:45:39PM +0200, Lucas Nussbaum wrote:
> On 21/10/16 at 16:32 +0100, Mark Brown wrote:

> > > Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled
> > > Severity set to 'serious' from 'important'

> > I've still not seen any usable reproduction instructions.

> Well it fails to build in a standard, up-to-date unstable chroot here.
> That was what I implied with the '# now fails in unstable' comment in my
> BTS control message.

> You cannot reproduce it? Could you send a build log so that we could
> diff it with mine?

Oh, someone uploaded these compilers to unstable?  Nice :(  I'll go take
a look.  Comments in the BTS messages really aren't visible, the
messages are very noisy so it's hard to spot them.


signature.asc
Description: PGP signature

Bug#837712: Processed: severity of 837712 is serious

[Mark Brown]

On Fri, Oct 21, 2016 at 02:08:47PM +, Debian Bug Tracking System wrote:

> Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled
> Severity set to 'serious' from 'important'

I've still not seen any usable reproduction instructions.


signature.asc
Description: PGP signature

Bug#837225: xemacs21: FTBFS: Can't locate var_file.pl in @INC

[Mark Brown]

On Sat, Sep 10, 2016 at 09:30:31AM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build on
> amd64.

FFS, why did this suddenly break and if it's due to the perl include
transition why did it not get reported in the mass bug filing for this?


signature.asc
Description: PGP signature

Bug#837712: xemacs21: FTBFS with bindnow and PIE enabled

[Mark Brown]

On Tue, Sep 13, 2016 at 09:25:13PM +0200, Balint Reczey wrote:

> For more information about the changes to sid's dpkg and GCC please
> visit:
>  https://wiki.debian.org/Hardening/PIEByDefaultTransition

You've not provided any instructions for reproducing this problem :(


signature.asc
Description: PGP signature

Bug#835614: chromium: HiDPI handling no longer works

[Mark Brown]

On Sat, Aug 27, 2016 at 06:06:38PM +0200, Mark Brown wrote:

> Previous versions of Chromium rendered correctly on high DPI displays.
> Since the most recent upgrade this support appears to have been removed
> or at least become non-functional - everything in the display is
> rendered without reference to the high pixel density.

This appears to be https://bugs.debian.org/833074 manifesting with GNOME
3 as well, the workaround Tollef provided works there but is clearly
awful.

This is a substantial regression in functionality on fairly common
hardware (I'm using a Dell XPS 13 (2015)) so I'm not lowering the
severity to merge, there's an awful lot of modern laptops with HiDPI
screens and currently the default behaviour results in an illegible UI
on these systems.

https://bugs.chromium.org/p/chromium/issues/detail?id=515984 upstream
may be related, though the workaround at the bottom does *not* work for
me (I suspect --force-device-scale-factor=1.8 may be needed but I've not
tested yet).


signature.asc
Description: PGP signature

Bug#835614: chromium: HiDPI handling no longer works

[Mark Brown]

Package: chromium
Version: 52.0.2743.116-2
Severity: important

Previous versions of Chromium rendered correctly on high DPI displays.
Since the most recent upgrade this support appears to have been removed
or at least become non-functional - everything in the display is
rendered without reference to the high pixel density.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.20.0-1
ii  libavcodec57 7:3.1.2-1
ii  libavformat577:3.1.2-1
ii  libavutil55  7:3.1.2-1
ii  libc62.23-5
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.10-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.2.0-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-3
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.20.9-1
ii  libharfbuzz0b1.2.7-1+b1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-2
ii  libspeechd2  0.8.4-2
ii  libstdc++6   6.2.0-1
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-1+b1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.29-1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  2.00.1-2

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information

Bug#831695: RM: tendra, tendra-doc -- ROM; No longer useful

[Mark Brown]

Package: ftp.debian.org
Severity: normal

TenDRA has been having portability problems for newer libcs for quite
some time and only supports i386 so is useful for fewer and fewer
machines.  At this point it seems best to remove it, there are now other
alternatives to GCC available and the effort involved in keeping it
available isn't worth it.

Bug#823552: Endless "supply vcc not found, using dummy regulator"

[Mark Brown]

On Tue, May 24, 2016 at 05:26:38PM +0200, Steinar H. Gunderson wrote:
> On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote:

> > Please send an appropriate separate patch for fixing this. Your email
> > did not reach people, I think.

> I only sent one patch so far, namely the leak fix.

You buried it in the middle of another mail and didn't CC any of the
maintainers - he's asking you to submit it using the process in
SubmittingPatches, the USB maintainers won't have seen this discussion
and may not notice a patch buried in the middle of a message in the
middle of a thread even if they see it.


signature.asc
Description: PGP signature

Bug#823552: Endless "supply vcc not found, using dummy regulator"

[Mark Brown]

On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote:

> What other problems exactly do you have? Late binding of S2MPS11
> regulator driver? That does not look like a problem. If it is built as
> a module then it should be loaded, probably from initramfs because
> these are regulators.

AFAICT the fact that every time the dwc3-exynos driver probes it creates
a new child device which successfully instantiates means that we end up
constantly running deferred probes.  It should only create the child
devices if it managed to get the other resources, that way we don't get
the constant deferred probe retries.


signature.asc
Description: PGP signature

Bug#823552: Endless "supply vcc not found, using dummy regulator"

[Mark Brown]

On Mon, May 23, 2016 at 07:46:43PM +0200, Steinar H. Gunderson wrote:
> On Mon, May 23, 2016 at 07:06:17PM +0200, Steinar H. Gunderson wrote:

> > Then, there's the issue of why the messages come for each deferred probe
> > attempt. It seems from your message this is about something in the
> > declaration of the device tree; I don't understand the nuances here, but I
> > suppose it's pretty easy?

> FWIW, from reading drivers/usb/phy/phy-generic.c, it looks like vcc-supply on
> the USB phy is supposed to be optional.

No, not unless the device can operate without power which seems
improbable.  Optional supplies are for supplies which may be physically
absent, not to shut up warnings from partially specified system
descriptions.  If there is an optional supply with no configuration of
the device to operate in a different mode without that supply it is most
likely that the API is being abused.  The API is there to support users
with things like optional external reference voltages that may be
missing in some system designs, it's not there to support broken system
integrations.


signature.asc
Description: PGP signature

Bug#823552: Endless "supply vcc not found, using dummy regulator"

[Mark Brown]

On Mon, May 23, 2016 at 07:06:17PM +0200, Steinar H. Gunderson wrote:
> On Mon, May 23, 2016 at 05:24:55PM +0100, Mark Brown wrote:

> >>> Cc-ing Mark in case he has any insights (I hope I have the right email
> >>> address).

> > But nobody who works on probe deferral or made any of the suggestions I
> > mentioned in the message you linked to, nor anyone who works on the
> > driver you've identified a bug in...  :(

> As for the former, I have no idea who they would be, sorry. For the latter,

There's the people I mentioned in the e-mail you linked to for
exmaple...  you could also look at git annotate for the probe deferral
code and see who worked on it, or do whatever it is lead to you finding
me.

> isn't linux-samsung-soc@ the right place? MAINTAINERS said it was.

That's just the list, not people.  You really want to see who's working
on the driver and talk to them, you can't guarantee that everyone reads
the lists sufficiently well that they will notice some random post that
doesn't even mention the driver in the subject line (it's probably a
good idea to submit that patch BTW).  Note also that if MAINTAINERS has
multiple hits you want to pay attention to them.

> Then, there's the issue of why the messages come for each deferred probe
> attempt. It seems from your message this is about something in the
> declaration of the device tree; I don't understand the nuances here, but I
> suppose it's pretty easy?

No.  This is nothing to do with the device tree.  The dwc3-exynos driver
is continually creating new, partially specified devices.  Since each of
these new devices has the same problem they all get the same warning
reported for them.

The regulator API has no idea that this is anything to do with deferred
probe, it's printing a warning message because something asked for a
supply that not mapped at all which is a potential concern if we explode
later due to this being an error in the code.  All the regulator API can
realistically do is remove all diagnostics in case someone triggers them
with deferred probe but that's probably not enormously helpful to people
if they run into an error directly triggered at the regulator level who
might like some diagnostics to help them figure out what went wrong.

> Fourth, there's the question of why there are thousands of probe attempts;
> it shouldn't be even if the regulator takes a long time to come up. I guess
> this is what your original message was about, and fixing that would also
> reduce the amount of logging a ton (plus presumably speed up boot by wasting
> less CPU on repeated probing). But as I understand you, it's not strictly
> necessary to actually fix this issue?

No, this is the way probe deferral is supposed to work.  It is a bit
wasteful of CPU but realistically it's not that much and it's really
simple to implement robustly unlike anything that involves actually
looking at dependencies.  Some breakage in your system is triggering
vastly more retries than are normal, even a hundred rounds would be
*extremely* high for the initial boot.

We're doing repeated probes because the way deferred probe works is that
every time a new device binds we start a new retry of all deferred
devices to see if that new device unblocked anything (if multiple
devices progress in one run it should only schedule one new run).  The
reason you're seeing the spectacular volume is that every time we retry
we add more devices (notice that you're not complaining about the log
message generated by the underlying Designware controller failing to get
the supply it requests which will print once per probe but rather by the
PHY devices it spams in).

The fact that the Exynos driver is instantiating subdevices before it's
even acquired its own resources is probably not helping here of course,
it's more than likely that at least some of those resources need to be
passed on to the child devices and of course if the children did
actually instantiate that'd trigger continual probe deferral runs.
Looking at the code I've got a horrible feeling that might be the root
cause here, it's a single regulator that's being requested so the
diagnostics should be being printed in the caller but that just silently
passes back failures to get supplies (which is why it wasn't immediately
obvious that that was failing).

> > The patch you linked to was for a completely different error message
> > which is at least related to probe deferral

> Yes, it's a different error message, but points to the same issue as #4
> above, no?

Not from the point of the view of the regulator API and really as far as
I can tell this is just a driver specific issue.  The regulator API has
no idea this is anything to do with deferred probe.

> > though fundamentally unless
> > we just stop printing diagnostics (which is getting more and more
> > tempting to be honest) I'm not sure anyt

Bug#823552: Endless "supply vcc not found, using dummy regulator"

[Mark Brown]

On Mon, May 23, 2016 at 04:40:47PM +0200, Steinar H. Gunderson wrote:
> On Mon, May 23, 2016 at 03:47:37PM +0200, Steinar H. Gunderson wrote:

> > In this case, it's not just an annoyance, though; they're so many that they
> > keep the system from booting unless loglevel is turned down. Cc-ing Mark in
> > case he has any insights (I hope I have the right email address).

But nobody who works on probe deferral or made any of the suggestions I
mentioned in the message you linked to, nor anyone who works on the
driver you've identified a bug in...  :(

> > I don't understand entirely why it tries 2000+ times before it succeeds

> Now I do; the initramfs doesn't include i2c-exynos5, and before that is
> loaded, s2mps11 (the regulator) can't come up either.

> So fixing initramfs-tools to include the driver will seemingly fix (or maybe
> more work around) the huge amounts of spam, but this is still a larger issue
> that needs resolving.

Not really, the issue you're seeing is just a plain resource leak in the
driver that happens to blow up worse than normal in your particular
configuration.  This isn't even something related to probe deferral at
the regulator level, the core is complaining that your system
description is buggy as it has omitted some of the supplies for the
device (notice how it says "using dummy regulator"...).   This is
happening a lot as the DWC3 driver is leaking, it is happening at all
because when the Exynos DWC3 integration creates it PHYs it doesn't map
the supplies through to them (it should be registering a supply alias to
do this).

The patch you linked to was for a completely different error message
which is at least related to probe deferral, though fundamentally unless
we just stop printing diagnostics (which is getting more and more
tempting to be honest) I'm not sure anything is going to fully resolve
leaks like this, the best chance you've got is something that explicitly
looks at the dependencies like Raphael was proposing.


signature.asc
Description: PGP signature

Bug#819250: minidlna: Poor handling of inotify limits

[Mark Brown]

On Wed, Mar 30, 2016 at 12:12:39PM +0300, Alexander Gerasiov wrote:
> Mark Brown <broo...@debian.org> wrote:

> > > 2. I believe the problem is fixed in current testing version. Please
> > > try 1.1.5 from testing or backports and report if crash persists.

> > Are you sure this isn't serious enough to be fixed in stable?  The
> > number of directories it's failing on is relatively low...

> Debian release policy only allows to fix bugs in stable which are
> 1. security flows
> or
> 2. makes software totally (or really highly) unusable.

> Other fixes should go normal way through unstable and could be
> delivered to users of stable distribution via backports.

I'd argue that this is going towards the second case, my music
collection is not *that* big.

> So could you confirm that problem is not reproducible with 1.1.5?

I don't *think* I was seeing it with unstable but can't confirm for
several weeks now.


signature.asc
Description: PGP signature

Bug#819250: minidlna: Poor handling of inotify limits

[Mark Brown]

On Sun, Mar 27, 2016 at 08:09:33PM +0300, Alexander Gerasiov wrote:

> 1. I don't think the reason of crash is someway linked to inotify. But
> this doesn't matter because of 2.

I am seeing other crashes due to Linn Kazoo which I need to report
properly (and would expect to be fixed in stable) but this is happening
separately to that with no client software on the network.

> 2. I believe the problem is fixed in current testing version. Please
> try 1.1.5 from testing or backports and report if crash persists.

Are you sure this isn't serious enough to be fixed in stable?  The
number of directories it's failing on is relatively low...


signature.asc
Description: PGP signature

Bug#819250: minidlna: Poor handling of inotify limits

[Mark Brown]

Package: minidlna
Version: 1.1.2+dfsg-1.1+b3
Severity: important

On startup on my system minidlna exits with the following log message:

[2016/03/25 15:04:04] inotify.c:198: warn: WARNING: Inotify max_user_watches 
[16382] is low or close to the number of used watches [1887] and I do not have 
permission to increase this limit.  Please do so manually by writing a higher 
value into /proc/sys/fs/inotify/max_user_watches.

There are several problems with this.  One is that this message is
marked as a warning and it is therefore very surprising to find it
treated as a fatal error.  This is especially the case since the message
says that the number of used watches is about an order of magnitude
lower than the limit which doesn't suggest that the limit has actually
been hit.

The other is that since the program appears to have support for
non-inotify operation (there's a configuration option to control inotify
use) I'd expect it to fall back to that.

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

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

Versions of packages minidlna depends on:
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-59
ii  libavformat566:11.6-1~deb8u1
ii  libavutil54  6:11.6-1~deb8u1
ii  libc62.19-18+deb8u3
ii  libexif120.6.21-2
ii  libflac8 1.3.0-3
ii  libid3tag0   0.15.1b-11
ii  libjpeg62-turbo  1:1.3.1-12
ii  libogg0  1.3.2-1
ii  libsqlite3-0 3.8.7.1-1+deb8u1
ii  libvorbis0a  1.3.4-2
ii  lsb-base 4.1+Debian13+nmu1

minidlna recommends no packages.

minidlna suggests no packages.

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

-- no debconf information