date:20210919


On 9/19/2021 4:53 PM, Elliott Mitchell wrote:

On Sun, Sep 19, 2021 at 03:54:01PM -0400, Chuck Zmudzinski wrote:

On 9/19/2021 1:29 PM, Elliott Mitchell wrote:

Have you tried memory ballooning with PVH or HVM domains?

That combination has been reliably crashing Xen for me for a while.
Apparently few others have run into it, yet it is reliable for me.  Have
you tried the combination?  Works?  Panics?

I have not tried ballooning HVM or PVH domains. If the Xen
hypervisor is crashing when ballooning unprivileged domains,
doesn't that support my belief that there are bugs in src:xen
rather than in src:linux?

No.


I still think the patches to fix a panic on devices using the arm 
architecture

are a bit aggressive for the Debian Xen package for Debian stable. Those
patches upstream are intended for Xen unstable, which is currently
Xen 4.16. Such patches do not belong in a stable Xen 4.14 package for
Debian stable, especially after it can be proven they cause a regression
for Xen users of amd64 devices, the regression being that they break the
proper shutdown functioning of amd64 devices.

I think the correct Debian way to support the arm devices that
panic on a true upstream Xen 4.14 hypervisor without the
patches for arm that cause dom0 to not power off properly on
amd64 is by first testing the arm patches as part of a new Xen 4.16
unstable Xen package for Debian unstable, then follow ordinary
development procedures for porting Xen 4.16 to bookworm/testing,
and then finally a backport of Xen 4.16 to bullseye. That is the
only way I can see this being done without causing grief to
Xen users who want a stable Xen on a stable Debian, unless
upstream can help with porting the arm patches back to Xen 4.14
in such a way that they don't break things on amd64.


This was also deliberately not copied to #991967 since this is unrelated.
I'm concerned this second one might be Debian, but the small delta makes
me think it likely originates from upstream Xen.  I was wondering whether
you had seen it since I haven't found other reports.

(note, if you try recreating, this is a Xen panic, all domains get lost)




This is off-topic for bug #991968.

Regards,

Chuck

Bug#991967: #991967: Simply ACPI powerdown/reset issue?

2021-09-19 Thread Elliott Mitchell

On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64
> 
> linux kernel version: 5.10.46-4 (the current amd64 kernel
> for bullseye)
> 
> Boot system: EFI, not using secure boot, booting xen
> hypervisor and dom0 bullseye with grub-efi package for
> bullseye, and it boots the xen-4.14-amd64.gz file, not
> the xen-4.14-amd64.efi file.

> I also tested a buster dom0 with the 4.19 series kernel
> on the xen-4.14 hypervisor from bullseye and saw the
> problem, but I did not see the problem with either
> a buster (linux 4.19) or bullseye (linux 5.10) dom0 on
> the xen-4.11 hypervisor, so I think the problem is
> with the Debian version of the xen-4.14 hypervisor,
> not with src:linux.

You're referencing several software versions which are mismatches for
#991967.  #991967 was observed with Xen 4.11 and Linux kernel 4.19.194-3,
but not Linux kernel 4.19.181.

The fact it correlates with a Linux kernel update rather strongly points
to the Linux kernel.  I could believe the situation is partially the
fault of both though.

> I suspect the following patch is the culprit for problems
> shutting down on the amd64 architecture:
> 
> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch

> This patch does affect amd64 acpi code, and is probably causing
> the problem on my amd64 system, so my build of the xen-4.14
> hypervisor without this patch fixed the problem.

Of the ones listed that is the only one which has any overlap with x86
code.  The next reproduction step is `apt-get source xen &&
patch -p1 -R < 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
&& dpkg-buildpackage -b`.  Then try with this to confirm that patch
is what does it.

Thing is that delta is rather small.  I don't have a simulator, but that
is rather small to be the culprit.

> I think this bug should be re-classified as a bug in src:xen.

There could be a separate bug in src:xen, but that is not #991967.

> I also would inquire with the Debian Xen Team about why they
> are backporting patches from the upstream xen unstable
> branch into Debian's 4.14 package that is currently shipping
> on Debian stable (bullseye). IMHO, the aforementioned
> patches that are not in the stable 4.14 branch upstream
> should not be included in the xen package for Debian stable.

It was requested since someone trying to have Xen operational on a device
needed those for operation.  Rather a lot of bugfix or very small
standalone feature patches get cherry-picked.

Presently I haven't been convinced this is a Xen bug (though it does
effect Xen installations).

Any chance you've got the tools to build and try a 5.5.0 or 5.10.0 Linux
kernel?  I'm suspecting got incorrectly backported on the Linux side
(alternatively the Xen project seems a bit poor at keeping needed patches
in Linux).

-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#994678: [Pkg-javascript-devel] Bug#994678: pkg-js-tools: MA status

2021-09-19 Thread Yadd

Le 19/09/2021 à 12:35, Bastien Roucariès a écrit :
> Package: pkg-js-tools
> Version: 0.9.66
> Severity: important
> 
> Dear Maintainer,
> 
> According to a few cross build test (see for instance
> https://salsa.debian.org/js-team/node-re2/-/jobs/1960208)
> 
> This package is a blocker.
> 
> May be MA: same if possible will help here

pkg-js-tools is arch:all. So this issue seems a duplicate

Bug#994714: ncbi-blast+: makeblastdb output dependent of endianness

2021-09-19 Thread Aaron M. Ucko

Control: reassign 994714 kleborate/2.1.0-1

Étienne Mollier  writes:

> At this point, I strongly suspect that, either makeblastdb does
> not output properly blastdb files on big endian systems, or
> kleborate is not able to decode properly an eventual blastdb
> database with big endian specific layout.

Hi, Étienne.

As of BLAST+ 2.10.0, makeblastdb defaults to making version 5 databases,
via the third-party LMDB library that uses an architecture-dependent
on-disk layout (differing between little-endian and big-endian systems;
I'm not sure offhand about 32-bit vs. 64-bit systems).  TTBOMK, BLAST+
is fine on either type of system as long as you don't try to mix and
match, so the bug is most likely in kleborate; please try directing
makeblastdb to produce traditional version 4 databases by invoking it
with the "-blastdb_version 4" flag.

See also

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959587
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960756

and especially

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981293

Thanks for checking!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#994729: brltty doesn't start on GUI login screen if sysvinit-core is used

2021-09-19 Thread Gregory Nowak

Package: brltty
Version: 6.3+dfsg-1
Severity: normal
Tags: a11y

Dear Maintainer,

When using sysvinit as the init system, brltty
shows "screen not in text mode" at the lightdm and gdm3 login screen.
This is because the /var/lib/BrlAPI/0 socket is missing at boot.

The fix is to add "$local_fs" to the "Required-Start" line of 
/etc/init.d/brltty.
So, the lsb header of /etc/init.d/brltty should read as follows:

### BEGIN INIT INFO
# Provides:  brltty
# Required-Start:mountkernfs $local_fs
# Required-Stop:
# Should-Start:  udev
# Should-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Braille terminal driver
# Description: Used to provide access to refreshable braille terminals.
### END INIT INFO

Implementing this fix to brltty in debian would be much appreciated.
Thank you.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages brltty depends on:
ii  init-system-helpers1.60
ii  libasound2 1.2.4-1.1
ii  libbluetooth3  5.55-3.1
ii  libbrlapi0.8   6.3+dfsg-1
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libdbus-1-31.12.20-2
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libexpat1  2.2.10-2
ii  libglib2.0-0   2.66.8-1
ii  libgpm21.20.7-8
ii  libicu67   67.1-7
ii  liblouis20 3.16.0-1
ii  libncursesw6   6.2+20201114-2
ii  libpcre2-32-0  10.36-2
ii  libpolkit-gobject-1-0  0.105-31
ii  libtinfo6  6.2+20201114-2
ii  lsb-base   11.1.0
ii  policykit-10.105-31

Versions of packages brltty recommends:
ii  python3  3.9.2-3

Versions of packages brltty suggests:
pn  brltty-speechd   
ii  brltty-x11   6.3+dfsg-1
pn  console-braille  

-- no debconf information

Bug#896460: Please package ipywidgets 7

2021-09-19 Thread Sandro Tosi

Hello Gordon,
you've been active uploading several packages of the ipython stack in
the last few days: can you provide an update regarding ipywidgets too?
thanks

On Sun, Sep 12, 2021 at 12:01 PM Sandro Tosi  wrote:
>
> Hello Gordon,
>
> On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen  wrote:
> > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 
> > doctests to fail.
>
> do you have any plan to update ipywidgets to 7+ anytime soon? the
> upstream version currently in sid is severely outdated, being released
> more than 4 years ago!
>
> Several packages are requiring ipywidgets 7 and the lack of it in
> Debian is hold several maintainers back from updating their packages
> (I have 3 myself alone).
>
> This bug was open more than 3 years ago: please provide an update on a
> timeline for ipywidgets 7 for debian, so that we can plan accordingly.
>
> Thanks,
> Sandro



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

Bug#946744: fixed in lintian-brush 0.113

2021-09-19 Thread Paul Wise

On Sun, 2021-09-19 at 12:05 +, Jelmer Vernooĳ wrote:

>    * Clarify that --allow-reformatting will in some cases strip comments.
>  Closes: #946744

Is it possible to avoid that stripping?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#994728: libtirpc3:amd64: rpcbind stops replying to subnet broadcast CALLIT after one stray UDP datagram

2021-09-19 Thread Martin Dorey

Package: libtirpc3
Version: 1.1.4-0.4
Severity: normal
Tags: patch

Dear Maintainer,

My NIS setup stops working occasionally.
The clients rely on subnet broadcast CALLIT requests to locate
the NIS servers.
The rpcbind process on the NIS server sees the requests but
fails to send the reply.
The strace output looks like this:

recvmsg(6, {msg_name={sa_family=AF_INET, sin_port=htons(800), 
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=128->16, 
msg_iov=[{iov_base="\0\2:\270\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5\0\0\0\0\0\0\0\0"...,
 iov_len=9000}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP, 
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=if_nametoindex("eth0"), 
ipi_spec_dst=inet_addr("172.27.8.1"), ipi_addr=inet_addr("172.27.63.255")}}], 
msg_controllen=32, msg_flags=0}, 0) = 64
...
sendmsg(7, {msg_name={sa_family=AF_INET, sin_port=htons(800), 
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=16, 
msg_iov=[{iov_base="\0\2:\270\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\371\0\0\0\4"...,
 iov_len=36}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP, 
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0, 
ipi_spec_dst=inet_addr("127.0.0.1"), ipi_addr=inet_addr("127.0.0.1")}}], 
msg_controllen=32, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)

... where I think the active ingredient is that ipi_spec_dst or
ipi_addr is 127.0.0.1 rather than the 172.27.5.162 intended
reply address.
Once an rpcbind process has got into this state, it doesn't
recover without being restarted.
rpcbind is calling svc_sendreply on the xprt it created in
create_rmtcall_fd, which isn't where the request originated.
That calls svc_dg_reply which assumes:

/* cmsg already set in svc_dg_recv */

... as of:

https://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=74ef3df0236c55185225c62fba34953f2582da72
(Try to ensure datagram replies come from the address requests were sent to.)

That's been zero-initialized, so everything works fine until
a port scan or some such sends a datagram to the same port.
Its IP_PKTINFO gets remembered and used on every subsequent
reply.

I can demonstrate the problem without needing NIS.
First enable remote call support.
On Debian, that can be done with:

sudo tee --append /etc/default/rpcbind <--- src/svc_dg.c.orig   2021-09-19 18:24:32.462610751 -0700
+++ src/svc_dg.c2021-09-19 18:14:52.271066229 -0700
@@ -278,6 +278,8 @@
if (su->su_cache)
cache_set(xprt, slen);
}
+   msg->msg_control = NULL;
+   msg->msg_controllen = 0;
}
return (stat);
 }

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

Control: retitle -1 libxml2: XHTML 1.0 validation is broken with 
w3c-dtd-xhtml's xhtml-special.ent file
Control: tags -1 - unreproducible

This should be reproducible with w3c-dtd-xhtml's xhtml-special.ent file.
The summary of the actual issue is below.

On 2021-09-20 03:18:46 +0200, Vincent Lefevre wrote:
[...]
> So the issue seems to occur when reading xhtml-special.ent.
> 
> Hmm... there seems to be a subtle difference in xhtml-special.ent:
> 
> With the file from w3c-dtd-xhtml:
> 
> 
> 
> 
> 
> 
> But with the file from w3c-sgml-lib:
> 
> 
> 
> 
> 
> 
> 
> The errors correspond to amp and lt.
> 
> Now, I don't know whether the new libxml2 version is too picky,
> or there was a real issue with the old entity files (ignored
> by all parsers until now?). In the latter case, I think that
> there should be a Breaks against w3c-dtd-xhtml.
> 
> One more thing: I've just checked on my Debian/stable machine,
> which just has w3c-sgml-lib installed:
> "xmllint --loaddtd --nonet --noout" works without any error.
> Thus there should be no issue by switching w3c-dtd-xhtml to
> w3c-sgml-lib.

FYI, the change of xhtml-special.ent upstream seems to be in

  
https://github.com/w3c/markup-validator/commit/fa78ea2526fe20a89c90c4734f704fb0126186fd

(the diff output by git seems incorrect: one needs to browse the
files from the parent d1431fc to see the old version).

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

Bug#993490: Acknowledgement (handbrake: terminates on launch, no reason given)

2021-09-19 Thread Rob Moss

Here is the backtrace I obtained using gdb, as per the HowToGetABacktrace
page on the Debian wiki:

Thread 1 "ghb" received signal SIGABRT, Aborted.
0x7371fce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7371fce1 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x73709537 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x7370940f in  () at /lib/x86_64-linux-gnu/libc.so.6
#3  0x73718662 in  () at /lib/x86_64-linux-gnu/libc.so.6
#4  0x7fffbd09ec35 in intel_enc_hw_context_init (ctx=0x56ae5fd0,
obj_config=0x56ae94a0, vme_context_init=0x7fffbd075020
, mfc_context_init=0x7fffbd06cf20
) at i965_encoder.c:1692
#5  0x7fffbd096827 in i965_CreateContext (ctx=,
config_id=, picture_width=,
picture_height=, flag=,
render_targets=0x56ae5b80, num_render_targets=,
context=) at i965_drv_video.c:2706
#6  0x73a21de4 in vaCreateContext (dpy=0x56ae5e60,
config_id=16777216, picture_width=1920, picture_height=1088, flag=1,
render_targets=0x56ae5b80, num_render_targets=4,
context=0x56afb7c0) at va.c:1239
#7  0x7fffbe3fc02d in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#8  0x7fffbe36b55d in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#9  0x7fffbe36ccb6 in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#10 0x7fffbe24fdd7 in MFXVideoENCODE_Init () at
/usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#11 0x555fd47b in  ()
#12 0x556002b4 in  ()
#13 0x5560042f in  ()
#14 0x555e0945 in  ()
#15 0x555b9fb8 in ghb_backend_init ()
#16 0x555a79a5 in ghb_activate_cb ()
#17 0x7705665f in g_closure_invoke () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x7706899b in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x7706ec6f in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x7706f1df in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x773d0ed8 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#22 0x773d104e in g_application_run () at
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#23 0x55586042 in main ()
#0  0x7371fce1 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x73709537 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x7370940f in  () at /lib/x86_64-linux-gnu/libc.so.6
#3  0x73718662 in  () at /lib/x86_64-linux-gnu/libc.so.6
#4  0x7fffbd09ec35 in intel_enc_hw_context_init (ctx=0x56ae5fd0,
obj_config=0x56ae94a0, vme_context_init=0x7fffbd075020
, mfc_context_init=0x7fffbd06cf20
) at i965_encoder.c:1692
i965 = 
intel = 
encoder_context = 0x56b16670
i = 
__PRETTY_FUNCTION__ = "intel_enc_hw_context_init"
#5  0x7fffbd096827 in i965_CreateContext (ctx=,
config_id=, picture_width=,
picture_height=, flag=,
render_targets=0x56ae5b80, num_render_targets=,
context=) at i965_drv_video.c:2706
i965 = 0x56ae86a0
obj_config = 0x56ae94a0
obj_context = 0x56aea630
attrib = 
vaStatus = 0
contextID = 
i = 
max_width = 4096
max_height = 4096
min_width_height = 
__PRETTY_FUNCTION__ = "i965_CreateContext"
#6  0x73a21de4 in vaCreateContext (dpy=0x56ae5e60,
config_id=16777216, picture_width=1920, picture_height=1088, flag=1,
render_targets=0x56ae5b80, num_render_targets=4,
context=0x56afb7c0) at va.c:1239
ctx = 
vaStatus = 
__func__ = "vaCreateContext"
#7  0x7fffbe3fc02d in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#8  0x7fffbe36b55d in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#9  0x7fffbe36ccb6 in  () at /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#10 0x7fffbe24fdd7 in MFXVideoENCODE_Init () at
/usr/lib/x86_64-linux-gnu/libmfxhw64.so.1
#11 0x555fd47b in  ()
#12 0x556002b4 in  ()
#13 0x5560042f in  ()
#14 0x555e0945 in  ()
#15 0x555b9fb8 in ghb_backend_init ()
#16 0x555a79a5 in ghb_activate_cb ()
#17 0x7705665f in g_closure_invoke () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x7706899b in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x7706ec6f in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x7706f1df in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x773d0ed8 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#22 0x773d104e in g_application_run () at
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#23 0x55586042 in main ()

Bug#517994:

2021-09-19 Thread Valentina Kalányos

Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off

2021-09-19 Thread Peter Nowee

Details to follow tomorrow (bisected already, how to reproduce)

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

On 2021-09-19 22:59:31 +0200, Mattia Rizzolo wrote:
> On Sun, Sep 19, 2021 at 09:45:19PM +0200, Vincent Lefevre wrote:
> > On 2021-09-19 19:15:54 +0200, Mattia Rizzolo wrote:
> > > I can never manage to download DTDs from w3.org (how could you?!), so,
> > > taking your testcase and a copy of the same DTD:
> > 
> > The DTD is provided by Debian, no need to download it.
> 
> But you need to instruct xmllint to use said DTD, it won't by its own
> decision to pick a random DTD from the filesystem.

No, this is not necessary with a correctly configured system.
This is not a random DTD, but the DTD mentioned in the HTML file,
which has the standard public identifier

  "-//W3C//DTD XHTML 1.0 Strict//EN"

Then libxml2 can find the right file on the local file system via
catalogs. In my case (which is the *default* setup with Debian
packages on my system, i.e. I haven't changed anything about that
in /etc):

/etc/xml/catalog contains

so that libxml2 then uses /etc/xml/w3c-dtd-xhtml.xml, which contains

so that libxml2 then uses
/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml, which contains

so that libxml2 gets the file

  /usr/share/xml/xhtml/schema/dtd/1.0/xhtml1-strict.dtd

There is the same mechanism for the .ent files referenced
by xhtml1-strict.dtd, i.e. via public identifiers.

>  I also know how to
> use apt-file myself:
> | % apt-file search xhtml1-strict.dtd
> | dita-ot: /usr/share/dita-ot/demo/h2d/dtd/xhtml1-strict.dtd
> | erlang-erl-docgen: 
> /usr/lib/erlang/lib/erl_docgen-1.1.1/priv/dtd/xhtml1-strict.dtd
> | kate5-data: /usr/share/katexmltools/xhtml1-strict.dtd.xml
> | libpxp-ocaml-dev: 
> /usr/share/doc/libpxp-ocaml-dev/examples/namespaces/xhtml1-strict.dtd.gz
> | librdf-rdfa-parser-perl: 
> /usr/share/perl5/auto/share/dist/RDF-RDFa-Parser/catalogue/www.w3.org/MarkUp/DTD/xhtml1-strict.dtd
> | w3-recs: 
> /usr/share/doc/w3-recs/html/www.w3.org/TR/2002/REC-xhtml1-20020801/DTD/xhtml1-strict.dtd.gz
> | w3c-sgml-lib: 
> /usr/share/xml/w3c-sgml-lib/schema/dtd/REC-xhtml1-20020801/xhtml1-strict.dtd
> | xemacs21-basesupport: 
> /usr/share/xemacs21/xemacs-packages/etc/psgml-dtds/xhtml1-strict.dtd
> | xmlcopyeditor: /usr/share/xmlcopyeditor/dtd/xhtml1-strict.dtd
> | %
> 
> indeed the one I used is the one from xmlcopyeditor (I picked a random
> package, trusting that said .dtd is actually the same as all of the
> above).

The one I'm using is from w3c-dtd-xhtml, apparently no longer
available in Debian (my machine is a Debian/unstable one installed
about 5 years ago, and Debian won't replace the package by
w3c-sgml-lib automatically). In any case, the concerned files
from w3c-sgml-lib seem to be the same with minor differences.

> My system is fine.  That error message is only a red herring due to
> --nonet,

Everything is on the local filesystem. There is no reason to do
any network access! If libxml2 tries to do a network access, this
means that something on your system is broken... perhaps catalogs
that are not set up correctly.

> and indeed the return code of xmllint is 0.

Don't look at the return code of xmllint; it is not reliable.
Even in case of bad usage, it will sometimes return 0:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727075

Validation issues are reported on stderr, e.g. with a working libxml2:

$ xmllint --loaddtd --nonet --noout test.html
test.html:6: parser error : EndTag: ' If you prefer, I can modify the DOCTYPE and do this instead, so there
> won't be "I/O error"s and the return code is clear:
> 
> mattia@warren /tmp/tmp/xml % cat test.html
> 
>  "file:///tmp/tmp/xml/xhtml1-strict.dtd">
> http://www.w3.org/1999/xhtml;>
> title
> text
> 
> mattia@warren /tmp/tmp/xml % xmllint --noout --nonet test.html ; echo $?
> 0

Wrong test. You forgot to load the DTD!

Please try:

  xmllint --loaddtd --noout --nonet test.html

Note: you may also need to copy the 3 .ent files referenced by
the DTD in the same directory:

%HTMLlat1;

%HTMLsymbol;

%HTMLspecial;

I have tried that:

$ ls -l /tmp/tmp/xml
total 68
-rw-r--r-- 1 vinc17 vinc17 13484 2012-04-24 22:49:16 xhtml-lat1.ent
-rw-r--r-- 1 vinc17 vinc17  4486 2012-04-24 22:49:16 xhtml-special.ent
-rw-r--r-- 1 vinc17 vinc17 13748 2012-04-24 22:49:16 xhtml-symbol.ent
-rw-r--r-- 1 vinc17 vinc17 25473 2012-04-24 22:49:15 xhtml1-strict.dtd

With libxml2 2.9.10+dfsg-6.7, strace shows that every file is loaded
from this directory, and I get no output, as expected.

But with libxml2 2.9.12+dfsg-4, I get:

$ xmllint --loaddtd --noout --nonet test.html
error : xmlAddEntity: invalid redeclaration of predefined entity
error : xmlAddEntity: invalid redeclaration of predefined entity

and strace still shows that every file is loaded from this directory.

Something interesting:

openat(AT_FDCWD, "/tmp/tmp/xml/xhtml-lat1.ent", O_RDONLY) = 5
lseek(5, 0, SEEK_CUR)   = 0
read(5, "

But with the file from w3c-sgml-lib:

The errors correspond to amp and lt.

Now, I don't know whether the new libxml2 version is too picky,
or

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

2021-09-19 Thread Adam Borowski

On Sun, Sep 19, 2021 at 11:55:53PM +0200, Olivier Girondel wrote:
>   * Package name: lebiniou-data
> Version : 3.62.1-1

> Changes since the last upload:
> 
>   * New upstream release 3.62.1.
>   * test/lebiniou-test.sh: Do not use $HOME for autopkgtest.
>   * debian/source/lintian-overrides: Updated.

Alas, it still keeps looking in $HOME (as in the log below).

The autopkgtest phoning home is also a pretty bad no-no.

autopkgtest [02:33:57]: test command1: /usr/share/lebiniou/test/lebiniou-test.sh
autopkgtest [02:33:57]: test command1: [---
[i] Setting up environment...
[i] Random seed: 361092574
{
"screen": {
"width": 320,
"height": 240
},
"input": {
"name": "sndfile",
"volumeScale": 1.0
},
"themes": [
"biniou",
"covid-19",
"zebulon"
],
"engine": {
"hFlip": false,
"vFlip": false,
"maxFps": 25,
"fadeDelay": 3,
"startMode": "last_created",
"randomMode": 2,
"autoSequencesMode": "shuffle",
"sequencesMin": 1,
"sequencesMax": 1,
"autoColormapsMode": "shuffle",
"colormapsMin": 2,
"colormapsMax": 3,
"autoImagesMode": "shuffle",
"imagesMin": 3,
"imagesMax": 4,
"webcams": 0,
"autoWebcamsMode": "cycle",
"webcamsMin": 15,
"webcamsMax": 30
},
"plugins": [
{
"name": "monitor",
"display_name": "Monitor",
"enabled": false
},
{
"name": "shaker_x",
"display_name": "Shaker X",
"enabled": true
},
{
"name": "big_half_wheel",
"display_name": "Big half wheel",
"enabled": true
},
{
"name": "sin_oscillo_1",
"display_name": "Sin oscillo 1",
"enabled": true
},
{
"name": "bassline",
"display_name": "Bass line",
"enabled": true
},
{
"name": "spiral_pulsing",
"display_name": "Spiral pulsing",
"enabled": true
},
{
"name": "blur_horizontal_2",
"display_name": "Blur horizontal 2",
"enabled": true
},
{
"name": "mirror_top",
"display_name": "Mirror top",
"enabled": true
},
{
"name": "spirals_nested",
"display_name": "Spirals nested",
"enabled": true
},
{
"name": "fadeout",
"display_name": "Fadeout",
"enabled": true
},
{
"name": "swap_columns",
"display_name": "Wave X",
"enabled": true
},
{
"name": "image_colrot",
"display_name": "Image colrot",
"enabled": true
},
{
"name": "tv_nervous",
"display_name": "TV nervous",
"enabled": true
},
{
"name": "scroll_horizontal",
"display_name": "Scroll horizontal",
"enabled": true
},
{
"name": "path_oscillo_freq",
"display_name": "Path oscillo freq",
"enabled": true
},
{
"name": "recurrence_plot",
"display_name": "Recurrence plot",
"enabled": true
},
{
"name": "takens",
"display_name": "Takens",
"enabled": true
},
{
"name": "faders",
"display_name": "Faders",
"enabled": true
},
{
"name": "clear",
"display_name": "Clear",
"enabled": true
},
{
"name": "images_pulse",
"display_name": "Images pulse",
"enabled": true
},
{
"name": "spectrum",
"display_name": "Spectrum",
"enabled": true
},
{
"name": "roller_y",
"display_name": "Roll Y",
"enabled": true
},
{
"name": "infinity",
"display_name": "Infinity",
"enabled": true
},
{
"name": "rotors_freq",
"display_name": "Rotors freq",
"enabled": true
},
{
"name": "spectrogram",
"display_name": "Spectrogram",
"enabled": true
},
{
"name": "galaxy",
"display_name": "Galaxy",
"enabled": true
},
{
"name": "snake",
"display_name": "Snake",
"enabled": true
},
{
"name": "reflector",
"display_name": "Reflector",
"enabled": true
},
{
"name":

Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off

2021-09-19 Thread Peter Nowee

Package: src:linux
Version: 5.10.46-4~bpo10+1
Severity: important

Dear Maintainer,

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

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

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


-- Package-specific info:
** Version:
Linux version 5.10.0-0.bpo.8-amd64 (debian-ker...@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.10.46-4~bpo10+1 (2021-08-07)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-0.bpo.8-amd64 
root=/dev/mapper/disruption--vg-disruption--debstable--root ro ipv6.disable=1 
intel_iommu=off

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: E402NA
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: E402NA.317
board_vendor: ASUSTeK COMPUTER INC.
board_name: E402NA
board_version: 1.0   

** Loaded modules:
ctr
ccm
cmac
rfcomm
appletalk
psnap
llc
bnep
snd_hda_codec_hdmi
ath9k
ath9k_common
ath3k
btusb
ath9k_hw
btrtl
btbcm
btintel
bluetooth
ath
jitterentropy_rng
mac80211
snd_sof_pci
x86_pkg_temp_thermal
intel_powerclamp
coretemp
snd_sof_intel_byt
snd_sof_intel_ipc
snd_sof_intel_hda_common
kvm_intel
mei_hdcp
snd_sof_xtensa_dsp
snd_sof
intel_rapl_msr
snd_sof_intel_hda
snd_hda_codec_realtek
snd_soc_skl
snd_hda_codec_generic
ledtrig_audio
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_sst_ipc
kvm
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_hda_intel
cfg80211
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
snd_compress
soundwire_cadence
drbg
snd_hda_codec
joydev
ansi_cprng
irqbypass
rapl
snd_hda_core
wdat_wdt
intel_cstate
snd_hwdep
asus_nb_wmi
hid_multitouch
watchdog
asus_wmi
soundwire_bus
ecdh_generic
wmi_bmof
sparse_keymap
efi_pstore
serio_raw
pcspkr
snd_pcm
ecc
rfkill
libarc4
intel_xhci_usb_role_switch
snd_timer
roles
sg
mei_me
snd
soundcore
mei
processor_thermal_device
intel_rapl_common
intel_soc_dts_iosf
ac
evdev
nft_ct
nf_conntrack
int3403_thermal
int340x_thermal_zone
int3400_thermal
acpi_thermal_rel
asus_wireless
intel_pmc_core
nf_defrag_ipv6
nf_defrag_ipv4
nf_log_ipv4
nf_log_common
binfmt_misc
nft_log
nft_limit
nft_counter
parport_pc
nf_tables
ppdev
libcrc32c
lp
nfnetlink
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
algif_skcipher
af_alg
dm_crypt
dm_mod
usbhid
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
uas
usb_storage
i915
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
hid_generic
ghash_clmulni_intel
i2c_algo_bit
drm_kms_helper
cec
rtsx_pci_sdmmc
xhci_pci
mmc_core
ahci
libahci
xhci_hcd
drm
libata
r8169
aesni_intel
usbcore
libaes
crypto_simd
cryptd
glue_helper
scsi_mod
realtek
mdio_devres
usb_common
rtsx_pci
lpc_ich
libphy
intel_lpss_pci
i2c_i801
intel_lpss
idma64
i2c_smbus
i2c_hid
wmi
hid
battery
button
video

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: enp1s0f2:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
link/ether 2c:fd:a1:7f:c1:72 brd ff:ff:ff:ff:ff:ff
3: wlp2s0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether f0:03:8c:be:1a:77 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.27/24 brd 10.0.1.255 scope global dynamic wlp2s0
   valid_lft 515398266sec preferred_lft 515398266sec

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 9763976   32212000 0  0 0  9763976   
32212000 0   0  0
enp1s0f2:   0   0000 0  0 00
   0000 0   0  0
wlp2s0: 126272033  139268000 0  0 0 18566882  
105230000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 2
167614 total packets received
11 with invalid addresses
0 forwarded
0 incoming packets discarded
163227 incoming packets delivered
136646 requests sent out
112 dropped because of missing route
4 fragments received ok
8 fragments created
Icmp:
45 ICMP messages received
1 input ICMP message failed
ICMP input histogram:
destination

Bug#994719: linux-image-5.10.0-8-amd64: Kernel oops

2021-09-19 Thread ael

Package: src:linux
Version: 5.10.46-4
Severity: important

Kernal oops:
[ 4895.690309] FAT-fs (sdd1): Directory bread(block 23326848) failed
[ 4895.690312] FAT-fs (sdd1): Directory bread(block 23326849) failed
[ 4895.690314] FAT-fs (sdd1): Directory bread(block 23326850) failed
[ 4895.690315] FAT-fs (sdd1): Directory bread(block 23326851) failed
[ 4895.690317] FAT-fs (sdd1): Directory bread(block 23326852) failed
[ 4895.690319] FAT-fs (sdd1): Directory bread(block 23326853) failed
[ 4895.690320] FAT-fs (sdd1): Directory bread(block 23326854) failed
[ 4895.690322] FAT-fs (sdd1): Directory bread(block 23326855) failed
[ 4895.690324] FAT-fs (sdd1): Directory bread(block 23326856) failed
[ 4895.690325] FAT-fs (sdd1): Directory bread(block 23326857) failed
[ 4895.690530] FAT-fs (sdd1): FAT read failed (blocknr 4243)
[ 4895.690532] [ cut here ]
[ 4895.690533] bdi-(unknown) not registered
[ 4895.690544] WARNING: CPU: 5 PID: 9048 at fs/fs-writeback.c:2326 
__mark_inode_dirty+0
x17a/0x340
[ 4895.690545] Modules linked in: nls_ascii nls_cp437 vfat fat xt_recent 
ipt_REJECT nf_
reject_ipv4 xt_comment xt_hashlimit xt_addrtype xt_mark xt_CT nfnetlink_log 
xt_NFLOG nf
_log_ipv4 nf_log_common xt_LOG nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp 
nf_nat_s
ip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp 
nf_conntrack_aman
da nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp 
nf_conntrack_
netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc 
nf_conntrack_h3
23 nf_conntrack_ftp nft_counter xt_tcpudp xt_conntrack nft_compat nft_chain_nat 
nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink essiv 
authenc
dm_crypt dm_mod uas usb_storage uinput binfmt_misc btusb btrtl btbcm btintel 
bluetooth
uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 jitterentropy_rng 
videobuf2_
common drbg videodev ansi_cprng mc ecdh_generic ecc intel_rapl_msr 
intel_rapl_common x8
6_pkg_temp_thermal cpufreq_ondemand
[ 4895.690601]  intel_powerclamp coretemp snd_hda_codec_realtek kvm_intel 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi iwlmvm pktcdvd kvm 
snd_hda_intel snd_intel_dspcfg irqbypass crc32_pclmul soundwire_intel 
soundwire_generic_allocation ghash_clmulni_intel mac80211 snd_soc_core 
aesni_intel snd_compress soundwire_cadence libaes iTCO_wdt intel_pmc_bxt 
crypto_simd libarc4 snd_hda_codec iTCO_vendor_support rtsx_pci_sdmmc cryptd 
iwlwifi watchdog glue_helper mmc_core snd_hda_core mei_hdcp at24 xhci_pci 
snd_hwdep rapl ehci_pci xhci_hcd soundwire_bus r8169 ehci_hcd intel_cstate 
snd_pcm cfg80211 realtek sr_mod mdio_devres snd_timer intel_uncore cdrom joydev 
mei_me pcspkr usbcore libphy sg i2c_i801 snd rtsx_pci mei rfkill lpc_ich 
soundcore i2c_smbus usb_common wmi battery ac button msr parport_pc nfsd ppdev 
lp parport auth_rpcgss nfs_acl lockd fuse grace configfs sunrpc ip_tables 
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi 
crc_t10dif crct10dif_generic i915
[ 4895.690676]  i2c_algo_bit ahci drm_kms_helper libahci libata cec drm 
scsi_mod psmouse crct10dif_pclmul crct10dif_common crc32c_intel evdev serio_raw 
video
[ 4895.690697] CPU: 5 PID: 9048 Comm: AWT-EventQueue- Not tainted 
5.10.0-8-amd64 #1 Debian 5.10.46-4
[ 4895.690699] Hardware name: Notebook 
W54_55SU1,SUW/W54_55SU1,SUW, BIOS 4.6.5 05/29/2014
[ 4895.690704] RIP: 0010:__mark_inode_dirty+0x17a/0x340
[ 4895.690707] Code: ff ff 48 8b 38 48 89 c5 f6 47 44 01 74 1e 48 8b 40 08 a8 
01 75 16 e8 55 90 f3 ff 48 c7 c7 b8 8b 0f a4 48 89 c6 e8 29 3b 58 00 <0f> 0b 48 
8b 05 1d 14 31 01 49 89 86 c8 00 00 00 45 85 ff 74 0e 48
[ 4895.690709] RSP: 0018:a672830a78a0 EFLAGS: 00010286
[ 4895.690712] RAX:  RBX: 0001 RCX: 96ed0fb58a08
[ 4895.690713] RDX: ffd8 RSI: 0027 RDI: 96ed0fb58a00
[ 4895.690714] RBP: 96eae2f5c460 R08:  R09: a672830a76c0
[ 4895.690715] R10: a672830a76b8 R11: a46cb3e8 R12: 96ea874c66d8
[ 4895.690716] R13:  R14: 96ea874c6650 R15: 
[ 4895.690718] FS:  7fe7da562700() GS:96ed0fb4() 
knlGS:
[ 4895.690719] CS:  0010 DS:  ES:  CR0: 80050033
[ 4895.690720] CR2: 55790a2de0f8 CR3: 00015ccec006 CR4: 001706e0
[ 4895.690722] Call Trace:


[ 4895.690732]  fat_alloc_clusters+0x487/0x4e0 [fat]
[ 4895.690737]  ? xas_load+0x5/0x70
[ 4895.690740]  ? submit_bio_noacct+0x2c/0x420
[ 4895.690744]  fat_add_new_entries+0x92/0x2f0 [fat]
[ 4895.690748]  ? _cond_resched+0x16/0x40
[ 4895.690750]  ? ___ratelimit+0x90/0xe0
[ 4895.690753]  ? fat__get_entry+0x8d/0x230 [fat]
[ 4895.690757]  fat_add_entries+0x49d/0x570 [fat]
[ 4895.690760]  ? vfat_add_entry+0x9c2/0xdf0 [vfat]
[ 4895.690762]  vfat_add_entry+0x9dd/0xdf0 [vfat]
[ 4895.690768]  ? __d_lookup_done+0x76/0xe0
[ 4895.690770]  vfat_create+0x6c/0x170 [vfat]
[

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

On 2021-09-19 22:33:09 +0200, Thorsten Glaser wrote:
> It probably contains the ones for 1.0, but I found w3c-sgml-lib to
> not be sufficient in many ways and now use local files only…

which has always been the case, AFAIK. And the XHTML 1.0 related files
seem to be identical to the w3c-dtd-xhtml ones, except for comments
and spacing. For instance, there's the following change in the comment
of xhtml-lat1.ent:

  Typical invocation:

http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent; >
+  "xhtml-lat1.ent" >
%xhtml-lat1;

but /usr/share/xml/xhtml/schema/dtd/1.0/xhtml1-strict.dtd from
w3c-dtd-xhtml is using:

%HTMLlat1;

%HTMLsymbol;

%HTMLspecial;

(which has never had any issue). So, this was probably an old
documentation bug (but it doesn't matter when one uses only
public identifiers and catalogs).

> which means validating involves copying the file, changing the http
> link in the DOCTYPE with a local file:// link, then validating…
> working but suboptimal.

Everything should be available with the public identifiers via
catalogs. Perhaps w3c-sgml-lib doesn't set the catalogs correctly.
For instance, with w3c-dtd-xhtml, /etc/xml/w3c-dtd-xhtml.xml
contains:

and /usr/share/xml/entities/xhtml/catalog.xml contains:

[...]

[...]

so that libxml2 gets the right files only by using public identifiers.

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

Bug#991967: #991967: Simply ACPI powerdown/reset issue?


On 9/19/2021 1:29 PM, Elliott Mitchell wrote:

On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:

I noticed this bug on bullseye ever since I have been
running bullseye as a dom0, but my testing indicates
there is no problem with src:linux but the problem
appeared in src:xen with the 4.14 version of xen on
bullseye.

I ask Elliott if you are only seeing the problem on Debian's
xen-4.14 hypervisor? Also, which architecture, arm or
amd64? I only see the problem on the Debian xen-4.14
hypervisor, and I have only tested on amd64, and I
have found a fix for my amd64 system which is as
follows:

Motherboard: ASRock B85M Pro4, BIOS P2.50 12/11/2015,
with a Haswell CPU (core i5-4590S)

xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64

linux kernel version: 5.10.46-4 (the current amd64 kernel
for bullseye)

Boot system: EFI, not using secure boot, booting xen
hypervisor and dom0 bullseye with grub-efi package for
bullseye, and it boots the xen-4.14-amd64.gz file, not
the xen-4.14-amd64.efi file.

Actually hardware which is pretty different from mine, so you may run
into distinct bugs.

Have you tried PVH or HVM domains?


HVM domains: Yes, and they work normally on all Debian versions
I have tried..

PVH domains: No, I have not tried these on Debian.


Have you tried memory ballooning with PVH or HVM domains?

That combination has been reliably crashing Xen for me for a while.
Apparently few others have run into it, yet it is reliable for me.  Have
you tried the combination?  Works?  Panics?


I have not tried ballooning HVM or PVH domains. If the Xen
hypervisor is crashing when ballooning unprivileged domains,
doesn't that support my belief that there are bugs in src:xen
rather than in src:linux?

Regards,

Chuck

Bug#994727: reportbug: Hang at boot (pre-X) with [drm] CPU Pipe A FIFO underrun [workaround included]

2021-09-19 Thread John Goerzen

Package: src:linux
Version: 5.10.46-4
Severity: critical

Hello,

After upgrading this laptop from buster to bullseye, I started to have
issues.  The laptop uses a LUKS root, so it pauses before loading X to
prompt for a password.  Therefore I know this problem is not just X.

Immediately after putting in my password, I would observe screen corruption
(random garbage on the top few rows of pixels) followed by a complete
system hang.  Occasionally I was able to see a message on the console
first:

[drm] CPU Pipe A FIFO underrun

I tried booting the Debian bullseye live image, and it too would hang a few
minutes into the session (which was X-based) with no message at all.

Quite a bit of searching brought me to #884116 and this thread
https://lists.debian.org/debian-kernel/2017/12/msg00350.html.
Unfortunately, it didn't immediately help.

I tried iommu=soft and other iommu options, but they only resolved the
corruption but not the crash.

Eventually, I found
https://askubuntu.com/questions/895329/flickering-screen-cpu-pipe-b-fifo-underrun-when-i-use-the-termnal
which recommended these kernel options:

i915.enable_psr=0 i915.edp_vswing=2

This resolved the issue and the system booted normally.  That report also
mentions screen flickering; I also have been experiencing that in the
console (but not X) and the flickering persisted, but that is not a big
deal to me since most of the time is spent in X.

The askubuntu page also referenced disabling C-states in BIOS, though that
was not necessary for me.

This system is a Dell Latitude 7480 with a Core i7-7600U and Intel HD
Graphics 620.



-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=ZFS=rpool/ROOT/debian-1 ro 
i915.enable_psr=0 i915.edp_vswing=2

** Tainted: PUOE (12353)
 * proprietary module was loaded
 * taint requested by userspace application
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[9.961833] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (1bcf:2b96)
[9.966740] dell_laptop: Using i8042 filter function for receiving events
[9.982813] input: Integrated_Webcam_HD: Integrate as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input11
[9.987357] Console: switching to colour dummy device 80x25
[9.987385] i915 :00:02.0: vgaarb: deactivate vga console
[9.991762] usbcore: registered new interface driver uvcvideo
[9.991766] USB Video Class driver (1.1.1)
[   10.010681] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.013323] i915 :00:02.0: firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[   10.013611] i915 :00:02.0: [drm] Finished loading DMC firmware 
i915/kbl_dmc_ver1_04.bin (v1.4)
[   10.033304] i915 :00:02.0: [drm] Panel advertises DPCD backlight 
support, but VBT disagrees. If your backlight controls don't work try booting 
with i915.enable_dpcd_backlight=1. If your machine needs this, please file a 
_new_ bug report on drm/i915, see 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for 
details.
[   10.042820] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[   10.043946] Intel(R) Wireless WiFi driver for Linux
[   10.044259] iwlwifi :02:00.0: enabling device ( -> 0002)
[   10.078776] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   10.079252] iwlwifi :02:00.0: loaded firmware version 36.ad812ee0.0 
8265-36.ucode op_mode iwlmvm
[   10.079281] iwlwifi :02:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   10.079283] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   10.153860] Bluetooth: Core ver 2.22
[   10.153883] NET: Registered protocol family 31
[   10.153886] Bluetooth: HCI device and connection manager initialized
[   10.153890] Bluetooth: HCI socket layer initialized
[   10.153892] Bluetoo
th: L2CAP socket layer initialized
[   10.153896] Bluetooth: SCO socket layer initialized
[   10.170927] usbcore: registered new interface driver btusb
[   10.185285] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[   10.186286] Bluetooth: hci0: Device revision is 16
[   10.186289] Bluetooth: hci0: Secure boot is enabled
[   10.186290] Bluetooth: hci0: OTP lock is enabled
[   10.186291] Bluetooth: hci0: API lock is enabled
[   10.186292] Bluetooth: hci0: Debug lock is disabled
[   10.186293] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   10.189271] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-12-16.sfi
[   10.189278] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[   10.281773] EXT4-fs (sda2): mounting ext2 file

Bug#994726: miniupnpd-nftables scripts eat iptables-nft NAT rules on exit

2021-09-19 Thread Matti Kurkela

Package: miniupnpd-nftables
Version: 2.2.1-1
Severity: normal
Tags: patch

Dear Maintainer,

I have a manually-crafted set of firewall rules, currently using
iptables-nft but still heavily based on classic iptables way of doing
things.

On update from Debian 10 to 11, miniupnpd transitioned to the use of
miniupnpd-nftables, as expected. But I was surprised to find that after
the transition, my existing NAT rules unrelated to miniupnpd had started 
vanishing every time I stopped the miniupnpd service.

On examination of the nft_removeall.sh script, it turns out it runs "nft
delete table nat", which removes any NAT rules created using
iptables-nft's "iptables -t nat" command. As the comment at the
beginning of the script says "Do not disturb other existing structures
in nftables", this must not have been the intention.

I also noticed that the stub chains generated by /etc/miniupnpd/nft_init.sh
seem to be completely unused by the actual daemon, and the rules the
daemon creates won't match the stub chains. In fact, it looks like the
daemon might be able to work just fine without the nft_init script at
all.

On further investigation, I found that the daemon creates three
Netfilter tables, all named "miniupnpd":
* an ip6 table with two NAT chains
* an ip (=IPv4-only) table with two NAT chains
* an inet (=IPv4/v6) table with a single filter chain

The default names for the tables and the chains did match neither what the
scripts used, nor the commented-out values in the miniupnpd.conf file.
The defaults can be found in the source code file 
miniupnpd-2.2.1/netfilter_nft/nftnlrdr_misc.c, lines 66-69.

The name of the tables created by the daemon is clearly intended to be
configurable in the source code, but the configuration file processing
code does not yet define an option to change it away from default.

I cleaned up the scripts to match the assumed intent and the actual
behavior of miniupnpd-nftables, and now it seems to work fine: see patch below.

I created variables at the beginning of each script to match the chain
name configuration options in miniupnpd.conf. I also added a variable
for the table name, in the assumption that the actual configuration
option might eventually be added.

I made the nft commands in the scripts explicitly specify the address 
family in each case, to make it more obvious what the scripts will do.
Since existing documentation is rather sparse, this might be the
next best thing.

diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_delete_chain.sh 
miniupnpd-2.2.1/netfilter_nft/scripts/nft_delete_chain.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_delete_chain.sh  
2019-06-26 00:30:54.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_delete_chain.sh   2021-09-20 
01:05:14.457155573 +0300
@@ -1,5 +1,14 @@
 #!/bin/sh
 
-nft delete chain nat MINIUPNPD
-nft delete chain nat MINIUPNPD-POSTROUTING
-nft delete chain filter MINIUPNPD
+# If you modify the corresponding settings in miniupnpd.conf,
+# change these variables in the scripts too.
+upnp_table=miniupnpd
+upnp_forward_chain=forward
+upnp_nat_chain=prerouting
+upnp_nat_postrouting_chain=postrouting
+
+nft delete chain ip ${upnp_table} ${upnp_nat_chain}
+nft delete chain ip ${upnp_table} ${upnp_nat_postrouting_chain}
+nft delete chain inet ${upnp_table} ${upnp_forward_chain}
+nft delete chain ip6 ${upnp_table} ${upnp_nat_chain}
+nft delete chain ip6 ${upnp_table} ${upnp_nat_postrouting_chain}
diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_display.sh 
miniupnpd-2.2.1/netfilter_nft/scripts/nft_display.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_display.sh   2019-06-26 
00:26:46.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_display.sh2021-09-20 
01:05:24.707083374 +0300
@@ -1,8 +1,19 @@
 #!/bin/sh
 
-# Prerouting
-nft list chain ip nat MINIUPNPD
-# Postrouting
-nft list chain ip nat MINIUPNPD-POSTROUTING
-# Filter
-nft list chain inet filter MINIUPNPD
+# If you modify the corresponding settings in miniupnpd.conf,
+# change these variables in the scripts too.
+upnp_table=miniupnpd
+upnp_forward_chain=forward
+upnp_nat_chain=prerouting
+upnp_nat_postrouting_chain=postrouting
+
+# IPv6 prerouting
+nft list chain ip6 ${upnp_table} ${upnp_nat_chain}
+# IPv6 postrouting
+nft list chain ip6 ${upnp_table} ${upnp_nat_postrouting_chain}
+# IPv4 prerouting
+nft list chain ip ${upnp_table} ${upnp_nat_chain}
+# IPv4 postrouting
+nft list chain ip ${upnp_table} ${upnp_nat_postrouting_chain}
+# IPv4/v6 filter
+nft list chain inet ${upnp_table} ${upnp_forward_chain}
diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_flush.sh 
miniupnpd-2.2.1/netfilter_nft/scripts/nft_flush.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_flush.sh 2019-06-26 
00:30:54.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_flush.sh  2021-09-20 
01:05:35.473674198 +0300
@@ -1,5 +1,14 @@
 #!/bin/sh
 
-nft flush chain ip nat MINIUPNPD
-nft flush chain ip nat

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-09-19 Thread Felix Lechner

Hi,

On Sun, Sep 19, 2021 at 3:11 PM Aurelien Jarno wrote:
>
> Now in the same spirit as in #993955, I am not sure you actually want to
> push maintainers to move libraries from /lib to /usr/lib

The purpose of this tag was never to push people toward usr-merge. It
only looks like that to glibc and libgpg-error-dev because the
packages use mixed installation paths.

Furthermore, the comparison with Bug#993955 is not appropriate. Filed
at the extraordinary 'serious' level by a member of the release team,
it was based on the filer's misunderstanding of what the tag does and
when it was implemented: Introduced seven months ago as a
classification tag [1] it was never shown to users. The purpose was to
aid in the collection of statistics [2] that became then immediately
available via the JSON interface on the Lintian website. [3] The
description, too, was gentle boilerplate [4] and in line with
conventional wisdom at the time. Most significantly, the tag predated
the "considered harmful" thread on -devel [5] that commenced on July
15 by almost half a year.

Lintian's packaging hints never contradicted the consensus now
emerging—if that is what we have—either in that tag or in the
'breakout-link' tag being discussed here.

Maybe 'breakout-link' is not useful and we should get rid of it, but
it looks to me like we found an issue in the way libgpg-error or
Pkg-config invoke Libtool.

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/merge_requests/349#note_215066
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#168
[3] https://lintian.debian.org/query
[4]
https://salsa.debian.org/lintian/lintian/-/blob/fe69b16048052be8ee35e0596cacfdcaff71/tags/u/unmerged-usr.tag
[5] https://lists.debian.org/debian-devel/2021/07/msg00126.html

Bug#993899: bullseye-pu: package btrbk/0.27.1-1.1+deb11u1

2021-09-19 Thread Thorsten Alteholz


Control: tags 993899 - moreinfo

On Fri, 17 Sep 2021, Jonathan Wiltshire wrote:

Please go ahead, and remove the moreinfo tag from this bug when uploaded.


... and uploaded.

 Thorsten

Bug#993898: buster-pu: package btrbk/0.27.1-1+deb10u1

2021-09-19 Thread Thorsten Alteholz





On Sun, 19 Sep 2021, Adam D. Barratt wrote:

Please go ahead.


... and uploaded.

 Thorsten

Bug#993228: buster-pu: package gthumb/3:3.6.2-4+deb10u1

2021-09-19 Thread Thorsten Alteholz




On Sun, 19 Sep 2021, Adam D. Barratt wrote:

Please go ahead.


... and uploaded.

  Thorsten

Bug#994725: fail2ban: Fail2ban 0.11.2 exim failregexs don't match logs from Debian's exim 4.94.2

2021-09-19 Thread Diane Trout

Package: fail2ban
Version: fail2ban
Severity: normal
Tags: patch

Dear Maintainer,

After activating the exim jail in fail2ban I noticed many failed login attempts
continuing to clutter up my logs.

Eventually I figured out the current failregex includ a pattern for the %(pid)s
that my current exim logs don't include.

It seems like default configuration of fail2ban should work with the default
configuration of Debian's log files.

I found similar reports of fail2ban not working with exim like:
https://systemadminspro.com/fail2ban-and-exim-on-ubuntu/

-- System Information:
Debian Release: bullseye
  APT prefers bullseye/main
  APT policy: (500, 'bullseye/main'), (500, 'bullseye/non-free'), (500,
'bulleye-security/main'), (500, 'bullseye-updates/main'), (100, 'bullseye-
backports/main')
Architecture: i386

Kernel: Linux 4.19.0-17-686-pae
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


*** /run/user/1000/exim.conf.debian.patch
--- exim.conf.dpkg-dist 2020-11-23 12:43:03.0 -0800
+++ exim.conf   2021-09-04 13:54:00.199013124 -0700
@@ -17,12 +17,13 @@
 #prefregex = ^%(pid)s \b(?:\w+ authenticator failed|([\w\-]+ )?SMTP
(?:(?:call|connection) from|protocol(?: synchronization)? error)|no MAIL
in|(?:%(host_info_pre)s\[[^\]]+\]%(host_info_suf)s(?:sender verify
fail|rejected RCPT|dropped|AUTH command))).+$

-failregex = ^%(pid)s %(host_info)ssender verify fail for <\S+>: (?:Unknown
user|Unrouteable address|all relevant MX records point to non-existent
hosts)\s*$
-^%(pid)s \w+ authenticator failed for (?:[^\[\( ]* )?(?:\(\S*\)
)?\[\](?::\d+)?(?: I=\[\S+\](:\d+)?)?: 535 Incorrect authentication data(
\(set_id=.*\)|: \d+ Time\(s\))?\s*$
-^%(pid)s %(host_info)srejected RCPT [^@]+@\S+: (?:relay not
permitted|Sender verify failed|Unknown user|Unrouteable address)\s*$
-^%(pid)s SMTP protocol synchronization error \([^)]*\): rejected
(?:connection from|"\S+") %(host_info)s(?:next )?input=".*"\s*$
-^%(pid)s SMTP call from (?:[^\[\( ]* )?%(host_info)sdropped: too
many (?:nonmail commands|syntax or protocol errors) \(last (?:command )?was
"[^"]*"\)\s*$
-^%(pid)s SMTP protocol error in "[^"]+(?:"+[^"]*(?="))*?"
%(host_info)sAUTH command used when not advertised\s*$
-^%(pid)s no MAIL in SMTP connection from (?:[^\[\( ]* )?(?:\(\S*\)
)?%(host_info)sD=\d\S*s(?: C=\S*)?\s*$
-^%(pid)s (?:[\w\-]+ )?SMTP connection from (?:[^\[\( ]*
)?(?:\(\S*\) )?%(host_info)sclosed by DROP in ACL\s*$
+failregex = ^\s*%(host_info)ssender verify fail for <\S+>: (?:Unknown
user|Unrouteable address|all relevant MX records point to non-existent
hosts)\s*$
+^\s*\w+ authenticator failed for (?:[^\[\( ]* )?(?:\(\S*\)
)?\[\](?::\d+)?(?: I=\[\S+\](:\d+)?)?: 535 Incorrect authentication data(
\(set_id=.*\)|: \d+ Time\(s\))?\s*$
+^\s*%(host_info)srejected RCPT [^@]+@\S+: (?:relay not
permitted|Sender verify failed|Unknown user|Unrouteable address)\s*$
+^\s*SMTP protocol synchronization error \([^)]*\): rejected
(?:connection from|"\S+") %(host_info)s(?:next )?input=".*"\s*$
+^\s*SMTP call from \S+ %(host_info)sdropped: too many nonmail
commands \(last was "\S+"\)\s*$
+^\s*SMTP protocol error in "[^"]+(?:"+[^"]*(?="))*?"
%(host_info)sLOGIN authentication mechanism not supported\s*$
+^\s*SMTP protocol error in "[^"]+(?:"+[^"]*(?="))*?"
%(host_info)sAUTH command used when not advertised\s*$
+^\s*no MAIL in SMTP connection from (?:[^\[\( ]* )?(?:\(\S*\)
)?%(host_info)sD=\d\S*s(?: C=\S*)?\s*$
+^\s*(?:[\w\-]+ )?SMTP connection from (?:[^\[\( ]* )?(?:\(\S*\)
)?%(host_info)sclosed by DROP in ACL\s*$
 >

Bug#994714: ncbi-blast+: makeblastdb output dependent of endianness

2021-09-19 Thread Étienne Mollier

Package: ncbi-blast+
Version: 2.11.0+ds-1
Severity: important

Hi Aaron,

I am currently investigating kleborate failure to migrate to
testing.  The failure is due to build time test suite failure on
s390x [1].

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=kleborate=s390x=2.1.0-1=1629929420=0

A recurrent relevant error message in the log is stating errors
on .ndb files, such as:

BLAST Database error: Invalid db file : 
/<>/.pybuild/cpython3_3.9/build/test/test_res_alleles/data/CARD_v3.0.8.fasta.ndb

These files are produced at runtime by the execution of a
makeblastdb command within kleborate build time tests scripts.
Here is one of them:

$ makeblastdb -dbtype nucl -in test/test_res_aac/data/CARD_v3.0.8.fasta

The .fasta file used for producing these databases can be
obtained on Salsa [2].

[2]: 
https://salsa.debian.org/med-team/kleborate/-/raw/master/test/test_res_aac/data/CARD_v3.0.8.fasta

If I produce these ndb files on big endian, then I have the
following consistent md5sum on s390x and ppc64:

08bd786ca54ebc4730e5dd42b57c454f  CARD_v3.0.8.fasta.ndb

On amd64 or arm64, the md5sum is:

8437e0675ad22935790a272be888ff56  CARD_v3.0.8.fasta.ndb

At this point, I strongly suspect that, either makeblastdb does
not output properly blastdb files on big endian systems, or
kleborate is not able to decode properly an eventual blastdb
database with big endian specific layout.

To be honest, I don't know which program is at fault, but if it
is a problem on makeblastdb side, then I thought you would want
to be aware of it.  Otherwise I'm happy with a bug reassigning
(in which case, I suppose I would just skip those test, or ask
for removal from s390x architecture).

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/9, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#981236: miniupnpd: Syslogging is overly verbose due to the -d option

2021-09-19 Thread Matti Kurkela

"Extremely verbose" indeed - it can produce gigabytes of log data in a 
single day. Before I applied the workaround below, it filled the root 
disk of my home server system three times.


Unfortunately it looks like the version in Bullseye does not have the 
"start_daemon" configuration file option.


As a workaround, you might want to create a 
/etc/systemd/system/miniupnpd.service.d/override.conf file with the 
following contents:


cut here
[Service]
Type=forking
ExecStart=
ExecStart=/usr/sbin/miniupnpd -f /etc/miniupnpd/miniupnpd.conf \ 
$MiniUPnPd_OTHER_OPTIONS

cut here

(Note: backslash denotes a line split because of email formatting 
restriction.)


After creating the override file (and probably also the 
miniupnpd.service.d directory to hold it), run "systemctl 
daemon-reload", then "systemctl restart miniupnpd".


The use of "Type=forking" is not optimal, but that's probably best you 
can do unless you're willing to rebuild the package from source.

Bug#992933: transition: proftpd-dfsg

2021-09-19 Thread Sebastian Ramacher

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/proftpd-abi-1.3.7c.html

On 2021-09-19 23:48:49 +0200, Hilmar Preuße wrote:
> Am 30.08.2021 um 08:32 teilte Hilmar Preuße mit:
> > On 8/25/21 11:42 AM, Hilmar Preusse wrote:
> 
> Hi,
> 
> > > This transition was already started by the recent proftpd upload, but is
> > > not caught caught automatically since it is a virtual package name that
> > > has changed.
> > > 
> > > Ben file:
> > > 
> > > title = "proftpd-dfsg";
> > > is_affected = .depends ~ "proftpd-abi-1.3.7a" | .depends ~
> > > "proftpd-abi-1.3.7b";
> > > is_good = .depends ~ "proftpd-abi-1.3.7b";
> > > is_bad = .depends ~ "proftpd-abi-1.3.7a";
> > > 
> > I'll upload proftp 1.3.7c soon and provide a new file for ben. Please
> > don't trigger any rebuild for now.
> > 
> Here is a new ben file:
> 
> title = "proftpd-dfsg";
> is_affected = .depends ~ "proftpd-abi-1.3.7a" | .depends ~
> "proftpd-abi-1.3.7b" | .depends ~ "proftpd-abi-1.3.7c";
> is_good = .depends ~ "proftpd-abi-1.3.7c";
> is_bad = .depends ~ "proftpd-abi-1.3.7a" | .depends ~ "proftpd-abi-1.3.7b";
> 
> Please trigger a rebuild. Thanks!

Scheduled

Cheers

> 
> Hilmar
> -- 
> sigfault
> 
> 




-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994698: one more fix for armhf needed

2021-09-19 Thread Rene Engelhard

reopen 994698
thanks

Hi,


Am 20.09.21 um 00:00 schrieb Rene Engelhard:
> Am 19.09.21 um 17:28 schrieb Rene Engelhard:
>> Whereas LO builds with g++ 11 since 1:7.1.0~rc1-1 in general Rico pointed me 
>> to
>> https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2=d880a443cc0c49692acc457f24468715199f076e
>> which also needs to be done on Debian with g++ 11 on armhf (reproduced
>> on amdahl with 11.2.0-5).
> 
> Actually g++-11 11.2.0-7 fixed that... Will revert that patch (and use a
> proper build dependency).

I shouldn't do such stuff this late and tired. (Forgot to force
GCC_VERSION in my 11.2.0-7 attempt :/).

Patch still is needed.

Regards,

Rene

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-09-19 Thread Aurelien Jarno

On 2021-09-19 13:03, Felix Lechner wrote:
> Hi Aurelien,
> 
> On Sun, Sep 19, 2021 at 12:15 PM Aurelien Jarno  wrote:
> >
> > My question is why this new breakout-link tag has been added
> 
> The tag was implemented in response to Bug#243158. [1] I am not sure
> about Yann's original suggestion, but I hope the tag is useful to
> prevent links to /opt, for example.

It seems to me that the original bug is about internal lintian bugs that
are not able to handle the symlinks.

> Prior to Glibc, I encountered only packages in which links and shared
> objects shared a parent folder.

Well there are a few other ones, libgpg-error-dev is one of them, even
if the number has decreased recently.

Now in the same spirit as in #993955, I am not sure you actually want to
push maintainers to move libraries from /lib to /usr/lib until there is
a clear plan for usrmerge and bookworm.

Also please note that even if fedora has finished the usrmerge
transition, they still ship glibc .so as a relative symlink to the
library in /lib. 

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 21:57, Bastien ROUCARIES
 a écrit :
>
> try to pass
>  -fstack-protector-strong to the local version as cflags
>
> If it fail upstream does not take in acount stack protector
>
> Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
>  a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
> >  a écrit :
> > >
> > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> > > >
> > > > I've reinstalled nodejs and libnode64 back to original Buster 
> > > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> > > >
> > > > It still segfaults!
> > > >
> > > > So it seems that the problem is not libuv version but its linking 
> > > > (included in node or external). Or cflags?
> > > Or ldflags
> > >
> > > Could you dump the cflags/ldfalgs of both version?
> > Or sanatizer that avoid a free after use...
> >
> > We harden a lot on debian side
> >
> > Bastien
> > >
> > >
> > > >
> > > > --
> > > > Ondrej Zary

If it does work try to build both nodejs and libuv with
-fsanitize=address or other sanitizer option

Bastien

> > > > --
> > > > Pkg-javascript-devel mailing list
> > > > pkg-javascript-de...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

try to pass
 -fstack-protector-strong to the local version as cflags

If it fail upstream does not take in acount stack protector

Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
>  a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> > >
> > > I've reinstalled nodejs and libnode64 back to original Buster 
> > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> > >
> > > It still segfaults!
> > >
> > > So it seems that the problem is not libuv version but its linking 
> > > (included in node or external). Or cflags?
> > Or ldflags
> >
> > Could you dump the cflags/ldfalgs of both version?
> Or sanatizer that avoid a free after use...
>
> We harden a lot on debian side
>
> Bastien
> >
> >
> > >
> > > --
> > > Ondrej Zary
> > >
> > > --
> > > Pkg-javascript-devel mailing list
> > > pkg-javascript-de...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

2021-09-19 Thread Olivier Girondel




Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.62.1-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.62.1-1.dsc

Changes since the last upload:

  * New upstream release 3.62.1.
  * test/lebiniou-test.sh: Do not use $HOME for autopkgtest.
  * debian/source/lintian-overrides: Updated.

Regards,

--
Olivier Girondel

Bug#992933: transition: proftpd-dfsg

2021-09-19 Thread Hilmar Preuße


Am 30.08.2021 um 08:32 teilte Hilmar Preuße mit:

On 8/25/21 11:42 AM, Hilmar Preusse wrote:


Hi,


This transition was already started by the recent proftpd upload, but is
not caught caught automatically since it is a virtual package name that
has changed.

Ben file:

title = "proftpd-dfsg";
is_affected = .depends ~ "proftpd-abi-1.3.7a" | .depends ~ 
"proftpd-abi-1.3.7b";

is_good = .depends ~ "proftpd-abi-1.3.7b";
is_bad = .depends ~ "proftpd-abi-1.3.7a";


I'll upload proftp 1.3.7c soon and provide a new file for ben. Please
don't trigger any rebuild for now.


Here is a new ben file:

title = "proftpd-dfsg";
is_affected = .depends ~ "proftpd-abi-1.3.7a" | .depends ~ 
"proftpd-abi-1.3.7b" | .depends ~ "proftpd-abi-1.3.7c";

is_good = .depends ~ "proftpd-abi-1.3.7c";
is_bad = .depends ~ "proftpd-abi-1.3.7a" | .depends ~ "proftpd-abi-1.3.7b";

Please trigger a rebuild. Thanks!

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> >
> > I've reinstalled nodejs and libnode64 back to original Buster 
> > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> >
> > It still segfaults!
> >
> > So it seems that the problem is not libuv version but its linking (included 
> > in node or external). Or cflags?
> Or ldflags
>
> Could you dump the cflags/ldfalgs of both version?
Or sanatizer that avoid a free after use...

We harden a lot on debian side

Bastien
>
>
> >
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994723: ITP: imath -- Utility libraries from ASF used by OpenEXR

2021-09-19 Thread Matteo F. Vescovi

Package: wnpp
Severity: wishlist
Owner: "Matteo F. Vescovi" 
X-Debbugs-Cc: debian-de...@lists.debian.org, ma...@debian.org

* Package name: imath
  Version : 3.1.3
  Upstream Author : Academy Software Foundation
* URL : https://github.com/AcademySoftwareFoundation/Imath
* License : BSD-3 Clause License
  Programming Lang: C++ and C
  Description : Utility libraries from ASF used by OpenEXR


Imath is a basic, light-weight, and efficient C++ representation of 2D
and 3D vectors and matrices and other simple but useful mathematical
objects, functions, and data types common in computer graphics
applications, including the "half" 16-bit floating-point type.

Imath also includes optional Python bindings for all types and
functions, including optimized implementations of vector and matrix
arrays.

This library is the successor of IlmBase (almost EOL) and it's mandatory
for updating OpenEXR to newer versions.

I'll maintain this package under the Debian Phototools Team umbrella.


--
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#994722: apt-show-versions: Syntax error on or around line 378.

2021-09-19 Thread Richard Lewis

Package: apt-show-versions
Version: 0.22.12
Severity: normal
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

giving two arguments including one that is not a package shows there is a 
syntax error somewhere around line 378:

$ apt-show-versions apt whatever
apt:amd64/bullseye 2.2.4 uptodate
Use of uninitialized value $arch in concatenation (.) or string at 
/usr/bin/apt-show-versions line 378.
Use of uninitialized value $arch in hash element at /usr/bin/apt-show-versions 
line 381.
Use of uninitialized value $arch in hash element at /usr/bin/apt-show-versions 
line 393.
whatever: not installed



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

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

Versions of packages apt-show-versions depends on:
ii  apt  2.2.4
ii  libapt-pkg-perl  0.1.39
ii  perl [libstorable-perl]  5.32.1-4+deb11u1

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
>
> I've reinstalled nodejs and libnode64 back to original Buster 
> 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb 
> from http://snapshot.debian.org
>
> It still segfaults!
>
> So it seems that the problem is not libuv version but its linking (included 
> in node or external). Or cflags?
Or ldflags

Could you dump the cflags/ldfalgs of both version?


>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

I've reinstalled nodejs and libnode64 back to original Buster 
10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb 
from http://snapshot.debian.org

It still segfaults!

So it seems that the problem is not libuv version but its linking (included in 
node or external). Or cflags?

-- 
Ondrej Zary

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 21:25, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:15, Ondrej Zary  a écrit :
> >
> > Added back --shared-zlib: works.
> > Added back also --shared-cares: works.
> >
> > So you're right: --shared-libuv is the problem.
> > Upstream seems to include libuv 1.34.2.
> > Buster has 1.24.1-1.
>
> Do you have valgrind ?
>
> If so and if it work (test first on good version), it smell like a use
> after free or a RAII violation
>
> I means, that libuv free a pointer, nodejs fill the buffer with code,
> then libuv free it. BOOOM.
>From libuv changelog
- * unix,win: fix `uv_fs_poll_stop()` when active (Anna Henningsen)
- * unix: fix race condition in uv_async_send() (Ben Noordhuis)

But I suppose it will be quicker to bissect by build/try the different
version of libuv...

Bastien

>
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994706: tar errors with .remove-on-upgrade files

2021-09-19 Thread David Mandelberg


Package: unattended-upgrades
Version: 2.8

After upgrading to bookworm/testing, my unattended-upgrade cron job 
started giving output like this:


tar: .remove-on-upgrade /etc/xdg/okular.categories: Not found in archive
tar: Exiting with failure status due to previous errors

I downgraded okular and ran `unattended-upgrade --debug` to get the 
context for those messages (ignore the `locale-en_US` bit, it's just a 
wrapper to make the log messages more searchable):


$ sudo apt install 
/var/cache/apt/archives/okular_4%3a21.08.0-1_amd64.deb 
/var/cache/apt/archives/libokular5core9_4%3a21.08.0-1_amd64.deb

...
$ locale-en_US sudo unattended-upgrade --debug
...
Get:1 https://deb.debian.org/debian testing/main amd64 okular amd64 
4:21.08.1-1+b1 [6160 kB] 





Get:2 https://deb.debian.org/debian testing/main amd64 libokular5core9 
amd64 4:21.08.1-1+b1 [340 kB] 





Fetched 6500 kB in 0s (0 B/s) 






fetch.run() result: 0 






FileSize: 6159644 
DestFile:'/var/cache/apt/archives/okular_4%3a21.08.1-1+b1_amd64.deb' 
DescURI: 
'https://deb.debian.org/debian/pool/main/o/okular/okular_21.08.1-1%2bb1_amd64.deb' 
ID:1 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/okular_4%3a21.08.1-1+b1_amd64.deb) 






found pkg: okular 






tar: .remove-on-upgrade /etc/xdg/okular.categories: Not found in archive 






tar: Exiting with failure status due to previous errors 






conffile remove-on-upgrade /etc/xdg/okular.categories in missing on the 
system 





FileSize: 339872 
DestFile:'/var/cache/apt/archives/libokular5core9_4%3a21.08.1-1+b1_amd64.deb' 
DescURI: 
'https://deb.debian.org/debian/pool/main/o/okular/libokular5core9_21.08.1-1%2bb1_amd64.deb' 
ID:2 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/libokular5core9_4%3a21.08.1-1+b1_amd64.deb) 






found pkg: libokular5core9 






No conffiles in deb 
/var/cache/apt/archives/libokular5core9_4%3a21.08.1-1+b1_amd64.deb 
(There is no member named 'conffiles')

...

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 21:15, Ondrej Zary  a écrit :
>
> Added back --shared-zlib: works.
> Added back also --shared-cares: works.
>
> So you're right: --shared-libuv is the problem.
> Upstream seems to include libuv 1.34.2.
> Buster has 1.24.1-1.

Do you have valgrind ?

If so and if it work (test first on good version), it smell like a use
after free or a RAII violation

I means, that libuv free a pointer, nodejs fill the buffer with code,
then libuv free it. BOOOM.



> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#973759: lintian: False positive: debian-changelog-file-is-a-symlink matches on upstream changelog

2021-09-19 Thread Axel Beckert

Hi Felix,

Felix Lechner wrote:
> On Sun, Sep 19, 2021 at 7:12 AM Axel Beckert  wrote:
> > Huh? This should be obvious from the binary package version number.
> 
> It isn't. A well-known example is python-defaults [1], which is native
> even though the version number suggests otherwise.

I see. While I was aware that binary and source package numbers can
easily differ, I wasn't aware that the binary versions package can be
arbitrary even in their type.

> The corresponding heuristics were dropped from Lintian two years
> ago. [2]

Oh, wasn't aware of that either.

> In addition, it is not well-publicized that version numbers for
> installation (aka "binary") packages are not necessarily tied to the
> version strings for their sources,

I was aware of that. I just never thought of the fact that this also
means that it is possible that native source packages build non-native
looking binary packages and hence version numbers are error-prone when
trying to distinguish between native and non-native packages.

> But I do not remember an example right now.

The common case I remember and also already used, is to generate
transitional packages formerly built by other source packages which
used to have a higher version. So the trick is to prepend an epoch to
the actual version for just that binary package..

Thanks for the insight and details!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

Added back --shared-zlib: works.
Added back also --shared-cares: works.

So you're right: --shared-libuv is the problem.
Upstream seems to include libuv 1.34.2.
Buster has 1.24.1-1.

-- 
Ondrej Zary

Bug#994720: [Pkg-javascript-devel] Bug#994720: nodejs: Please depends of sse2-support

Le dim. 19 sept. 2021 à 21:03, Jérémy Lal  a écrit :
>
>
>> Le dim. 19 sept. 2021 à 22:33, Bastien Roucariès 
>>  a écrit :
>>
>> Source: nodejs
>> Severity: serious
>> Tags: patch
>> Justification: base arch
>> Forwarded: 
>> https://chromium.googlesource.com/v8/v8.git/+/e825c4318eb2065ffdf9044aa6a5278635c36427
>>
>> Dear Maintainer,
>>
>> libv8 need sse2 on i386 since 2017...
>>
>> I asked upstream better communication with us, but we must depends on
>> sse2-support
>>
>> Patch because I will fix on git asap I have a bug number.
>>
>
> [i386] sse2-support is already a dependency... but that fact has not made it 
> to buster.
Yes and b-d should also depends
>
> Jérémy

Bug#994720: [Pkg-javascript-devel] Bug#994720: nodejs: Please depends of sse2-support

Le dim. 19 sept. 2021 à 22:33, Bastien Roucariès <
roucaries.bast...@gmail.com> a écrit :

> Source: nodejs
> Severity: serious
> Tags: patch
> Justification: base arch
> Forwarded:
> https://chromium.googlesource.com/v8/v8.git/+/e825c4318eb2065ffdf9044aa6a5278635c36427
>
> Dear Maintainer,
>
> libv8 need sse2 on i386 since 2017...
>
> I asked upstream better communication with us, but we must depends on
> sse2-support
>
> Patch because I will fix on git asap I have a bug number.
>
>
[i386] sse2-support is already a dependency... but that fact has not made
it to buster.

Jérémy

Bug#994703: [Pkg-javascript-devel] Bug#994703: Bug#994703: nodejs: please documents deps or avoid it

Le dim. 19 sept. 2021 à 22:27, Bastien ROUCARIES <
roucaries.bast...@gmail.com> a écrit :

> Le dim. 19 sept. 2021 à 19:33, Jérémy Lal  a écrit :
> >
> >
> >
> > Le dim. 19 sept. 2021 à 18:54, Bastien Roucariès <
> roucaries.bast...@gmail.com> a écrit :
> >>
> >> Package: nodejs
> >> Version: 12.22.5~dfsg-2
> >> Severity: serious
> >>
> >> Dear Maintainer,
> >>
> >> README.source should document the deps directory.
> >>
> >> It will be better to remove some libs from deps. Why libz is needed for
> node ?
> >> Could we push this plugin stuff to libz and so on.
> >>
> >> Acorn embdeded should be fixed by recent version.
> >>
> >> openssl one is worry some..
> >
> >
> > Hi,
> >
> > What's in ./deps/ is mostly not used for building node.
> > It's pretty much obvious if you look at ./debian/rules configure flags.
>
> Yes but README.Source is in this case good
> >
> > I believe it is not common practice to remove unused files, as long as
> it's okay with DFSG.
> Yes also
> > That's why
> > zlib, openssl, nghttp2, http-parser, uv, c-ares, brotli
> > are kept around in ./deps/ directory.
> >
> > This is actually useful, it makes debugging against "upstream-like"
> builds easier.
>
> Yes but in order to be less worried about something in this huge code
> base use these files, I will really prefer to move the deps dir before
> configure or removing the -r bit in order to avoid something strange
>
> I was hit ten years ago by some leaking hardcoded path on a project I
> compiled, and I really prefer to be paraonoiac on this side
>

Yes, why not. Better safe than sorry.

Jérémy

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

2021-09-19 Thread Mattia Rizzolo

On Sun, Sep 19, 2021 at 09:45:19PM +0200, Vincent Lefevre wrote:
> On 2021-09-19 19:15:54 +0200, Mattia Rizzolo wrote:
> > I can never manage to download DTDs from w3.org (how could you?!), so,
> > taking your testcase and a copy of the same DTD:
> 
> The DTD is provided by Debian, no need to download it.

But you need to instruct xmllint to use said DTD, it won't by its own
decision to pick a random DTD from the filesystem.  I also know how to
use apt-file myself:
| % apt-file search xhtml1-strict.dtd
| dita-ot: /usr/share/dita-ot/demo/h2d/dtd/xhtml1-strict.dtd
| erlang-erl-docgen: 
/usr/lib/erlang/lib/erl_docgen-1.1.1/priv/dtd/xhtml1-strict.dtd
| kate5-data: /usr/share/katexmltools/xhtml1-strict.dtd.xml
| libpxp-ocaml-dev: 
/usr/share/doc/libpxp-ocaml-dev/examples/namespaces/xhtml1-strict.dtd.gz
| librdf-rdfa-parser-perl: 
/usr/share/perl5/auto/share/dist/RDF-RDFa-Parser/catalogue/www.w3.org/MarkUp/DTD/xhtml1-strict.dtd
| w3-recs: 
/usr/share/doc/w3-recs/html/www.w3.org/TR/2002/REC-xhtml1-20020801/DTD/xhtml1-strict.dtd.gz
| w3c-sgml-lib: 
/usr/share/xml/w3c-sgml-lib/schema/dtd/REC-xhtml1-20020801/xhtml1-strict.dtd
| xemacs21-basesupport: 
/usr/share/xemacs21/xemacs-packages/etc/psgml-dtds/xhtml1-strict.dtd
| xmlcopyeditor: /usr/share/xmlcopyeditor/dtd/xhtml1-strict.dtd
| %

indeed the one I used is the one from xmlcopyeditor (I picked a random
package, trusting that said .dtd is actually the same as all of the
above).

> > mattia@warren /tmp/tmp/xml % xmllint --dtdvalid xhtml1-strict.dtd --nonet 
> > --noout test.html
> > I/O error : Attempt to load network entity 
> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
> > test.html:2: warning: failed to load external entity 
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
> > C//DTD XHTML 1.0 Strict//EN" 
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
> > 
> >^
> > mattia@warren /tmp/tmp/xml %
> > 
> > which looks good to me.
> 
> An I/O error is not good. Your system appears to be broken.

My system is fine.  That error message is only a red herring due to
--nonet, and indeed the return code of xmllint is 0.

If you prefer, I can modify the DOCTYPE and do this instead, so there
won't be "I/O error"s and the return code is clear:

mattia@warren /tmp/tmp/xml % cat test.html

http://www.w3.org/1999/xhtml;>
title
text

mattia@warren /tmp/tmp/xml % xmllint --noout --nonet test.html ; echo $?
0
mattia@warren /tmp/tmp/xml % dpkg -l libxml2|tail -n1
ii  libxml2:amd64  2.9.12+dfsg-4 amd64GNOME XML library
mattia@warren /tmp/tmp/xml %

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#969373: xfonts-terminus: diff for NMU version 4.48-3.1

2021-09-19 Thread Jochen Sprickerhof


Dear maintainer,

I've prepared an NMU for xfonts-terminus (versioned as 4.48-3.1) and
uploaded it. Hope this is fine with you.

Cheers Jochen
diff -Nru xfonts-terminus-4.48/debian/changelog xfonts-terminus-4.48/debian/changelog
--- xfonts-terminus-4.48/debian/changelog	2020-05-25 11:16:29.0 +0200
+++ xfonts-terminus-4.48/debian/changelog	2021-09-19 21:54:17.0 +0200
@@ -1,3 +1,12 @@
+xfonts-terminus (4.48-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove unused bdf2psf build dependency (Closes: #969373)
+  * Rebuild against trscripts 1.18+nmu3 to fix powerline symbols (cf.
+#767442).
+
+ -- Jochen Sprickerhof   Sun, 19 Sep 2021 21:54:17 +0200
+
 xfonts-terminus (4.48-3) unstable; urgency=medium
 
   * In order to ensure smoother upgrade, xfonts-terminus now recommends
diff -Nru xfonts-terminus-4.48/debian/control xfonts-terminus-4.48/debian/control
--- xfonts-terminus-4.48/debian/control	2020-05-25 10:09:19.0 +0200
+++ xfonts-terminus-4.48/debian/control	2021-09-19 21:46:28.0 +0200
@@ -3,7 +3,7 @@
 Section: fonts
 Priority: optional
 Standards-Version: 4.5.0.2
-Build-Depends: debhelper (>=12), trscripts (>= 1.16), xfonts-utils, bdf2psf, fontforge
+Build-Depends: debhelper (>=12), trscripts (>= 1.16), xfonts-utils, fontforge
 
 Package: fonts-terminus-otb
 Architecture: all


signature.asc
Description: PGP signature

Bug#991859: BioConductor MOFA2 needs basilisk - which installs a conda environment

2021-09-19 Thread Dirk Eddelbuettel



On 19 September 2021 at 16:09, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 05:31:14PM +0530, Nilesh Patra wrote:
| > 
| > But I do wonder if more packages in future might as well end up needing 
basilisk too.
| 
| I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.

I had a similar thought. I am also friends with the author of it.

They are doing 'The Right Thing' there for _their_ purposes at BioC in
abstracting OSs away and offering 'Python as a Service' for all setups.

We have a much more controlled setup and _maybe_ we could splice in a
'basilisk-lite' not requiring conda and all that crap.  Would be worth a
shot, but is almost a new research project. I don't have time to dive into
this though. I could ask him if it ever came up before.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 20:21, Ondrej Zary  a écrit :
>
> On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote:
> > Hi,
> >
> > So you work on oldstable.
> >
> > Could you check for stable/testing/unstable/experimental ? And mark
> > the bug with found /not found.
>
> Unfortunately I can't. I'm trying to get gitlab 11.11.8+dfsg-1+fto10+2 to 
> work. Then I can upgrade gitlab further to 12 and 13 and only then I can 
> upgrade Debian to bullseye.
>
> I've rebuilt Debian nodejs without --shared-zlib, --shared-cares and 
> --shared-libuv (remove them from debian/rules). It works now!
begin whith shared-uv

Bastien
>
> Going to narrow it down.
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#993829: Please ship nokogiri.h header file

2021-09-19 Thread Cédric Boutillier

Hi Daniel,

Le Sun, Sep 19, 2021 at 10:13:59PM +0200, Daniel Leidert a écrit :
> Am Sonntag, dem 19.09.2021 um 17:31 +0200 schrieb Cédric Boutillier:
> > I have been looking at the bugs on ruby-nokogiri before trying to update
> > it to the new upstream version.
> > 
> > Using the gem install layout is not enough to have the
> > ext/nokogiri/nokogiri.h installed. As I understand it, gem_installer.rb
> > in gem2deb is removing all sources from the ext/ directory.

Actually, I pushed a couple of commits today to fix that: I changed the
'gemspec' target of debian/rules slightly to call a Ruby script
filtering non-needed dependencies and the ports/* and patches/* parts of
the files metadata.

Removing the ports/* from the list of files fixed the gem install layout
part.

Remains the question about where to put the header file (in the gem
install layout context).
> RUBYHDRDIR (/usr/include/ruby-)
> SITEHDRDIR (/usr/include/ruby-/site_ruby)
> VENDORHDRDIR (/usr/include/ruby-/vendor_ruby)

In the context of an installation under vendor_ruby, I would go for
VENDORHDRDIR, although I would have hoped for a path which does not depend
on the ruby version.

Best wishes,

Cédric


signature.asc
Description: PGP signature

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

2021-09-19 Thread Thorsten Glaser

On Sun, 19 Sep 2021, Vincent Lefevre wrote:

> I can see that xhtml1-strict.dtd is provided by the w3c-dtd-xhtml
> package.

Not quite.

https://packages.qa.debian.org/w/w3c-dtd-xhtml/news/20160107T183823Z.html

--- Reason ---
RoQA; superseded by w3c-sgml-lib
--

That’s not entirely true, though:

 * [22]#826217 [n|  |  ] [[23]w3c-sgml-lib] [24]w3c-sgml-lib: XHTML 1.1
   files missing
   Reported by: [25]Thorsten Glaser ; Date: Fri, 3 Jun
   2016 11:21:02 UTC; Severity: normal; Filed 5 years and 109 days ago;
   Modified 5 years and 109 days ago;

It probably contains the ones for 1.0, but I found w3c-sgml-lib to
not be sufficient in many ways and now use local files only… which
means validating involves copying the file, changing the http link
in the DOCTYPE with a local file:// link, then validating… working
but suboptimal.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#994720: nodejs: Please depends of sse2-support

Source: nodejs
Severity: serious
Tags: patch
Justification: base arch
Forwarded: 
https://chromium.googlesource.com/v8/v8.git/+/e825c4318eb2065ffdf9044aa6a5278635c36427

Dear Maintainer,

libv8 need sse2 on i386 since 2017...

I asked upstream better communication with us, but we must depends on
sse2-support

Patch because I will fix on git asap I have a bug number.

Bastien

Bug#994703: [Pkg-javascript-devel] Bug#994703: Bug#994703: nodejs: please documents deps or avoid it

Le dim. 19 sept. 2021 à 19:33, Jérémy Lal  a écrit :
>
>
>
> Le dim. 19 sept. 2021 à 18:54, Bastien Roucariès 
>  a écrit :
>>
>> Package: nodejs
>> Version: 12.22.5~dfsg-2
>> Severity: serious
>>
>> Dear Maintainer,
>>
>> README.source should document the deps directory.
>>
>> It will be better to remove some libs from deps. Why libz is needed for node 
>> ?
>> Could we push this plugin stuff to libz and so on.
>>
>> Acorn embdeded should be fixed by recent version.
>>
>> openssl one is worry some..
>
>
> Hi,
>
> What's in ./deps/ is mostly not used for building node.
> It's pretty much obvious if you look at ./debian/rules configure flags.

Yes but README.Source is in this case good
>
> I believe it is not common practice to remove unused files, as long as it's 
> okay with DFSG.
Yes also
> That's why
> zlib, openssl, nghttp2, http-parser, uv, c-ares, brotli
> are kept around in ./deps/ directory.
>
> This is actually useful, it makes debugging against "upstream-like" builds 
> easier.

Yes but in order to be less worried about something in this huge code
base use these files, I will really prefer to move the deps dir before
configure or removing the -r bit in order to avoid something strange

I was hit ten years ago by some leaking hardcoded path on a project I
compiled, and I really prefer to be paraonoiac on this side

Bastien

> Jérémy
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#991967: #991967: Simply ACPI powerdown/reset issue?

On 9/19/2021 10:56 AM, Elliott Mitchell wrote:

On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:

On Sat, 11 Sep 2021 13:29:12 +0200 Salvatore Bonaccorso
 wrote:
  >
  > On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
  > > An experiment lead to a potential alternative explanation for #991967.
  > > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
  > > 4.19.194-3. Presence of Xen on the system may be unrelated.
  > >
  > > Failing that, it could be Xen and non-UEFI systems are effected. (Xen
  > > was tried on a UEFI system and the issue wasn't observed)
  >
  > Following up on https://bugs.debian.org/991967#12
  >
  > Did you succeeded in bisecting the issue as you seem to have it
  > reproducible?

I noticed this bug on bullseye ever since I have been
running bullseye as a dom0, but my testing indicates
there is no problem with src:linux but the problem
appeared in src:xen with the 4.14 version of xen on
bullseye.

I ask Elliott if you are only seeing the problem on Debian's
xen-4.14 hypervisor? Also, which architecture, arm or
amd64? I only see the problem on the Debian xen-4.14
hypervisor, and I have only tested on amd64, and I
have found a fix for my amd64 system which is as
follows:

Motherboard: ASRock B85M Pro4, BIOS P2.50 12/11/2015,
with a Haswell CPU (core i5-4590S)

xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64

linux kernel version: 5.10.46-4 (the current amd64 kernel
for bullseye)

Nope.  As per the report the problem appeared with kernel 4.19.194-3 and
at the time using Xen 4.11.

The kernel you're listing is rather more recent, which might suggest a
patch which had been backported from 5.x to 4.19.

I could believe a Xen security update being the trigger though (I don't
recall there being one at the right time, but I wouldn't rule it out).

Boot system: EFI, not using secure boot, booting xen
hypervisor and dom0 bullseye with grub-efi package for
bullseye, and it boots the xen-4.14-amd64.gz file, not
the xen-4.14-amd64.efi file.

I also tested a buster dom0 with the 4.19 series kernel
on the xen-4.14 hypervisor from bullseye and saw the
problem, but I did not see the problem with either
a buster (linux 4.19) or bullseye (linux 5.10) dom0 on
the xen-4.11 hypervisor, so I think the problem is
with the Debian version of the xen-4.14 hypervisor,
not with src:linux.

Just to make sure, the kernel you were testing was 4.19.194-3?  The
issue didn't manifest with kernels earlier than that.

I will check again with a buster dom0 when I get a chance,
probably late tonight or tomorrow. I think it was 4.19.194-3
if that is the latest buster kernel because I don't think there
has been an update to the buster kernel since I tested it.

Could be we're seeing distinct bugs.

I could agree if the problem shows up on my system
with the 4.19.194-3 kernel dom0 on xen-4.11, but if not,
then it is probably the same bug, a bug that is in src:xen,
not src:linux.

This patch does affect amd64 acpi code, and is probably causing
the problem on my amd64 system, so my build of the xen-4.14
hypervisor without this patch fixed the problem.

While that commit modifies the code path the processor takes, the
modified path appears identical.

I also would inquire with the Debian Xen Team about why they
are backporting patches from the upstream xen unstable
branch into Debian's 4.14 package that is currently shipping
on Debian stable (bullseye). IMHO, the aforementioned
patches that are not in the stable 4.14 branch upstream
should not be included in the xen package for Debian stable.

Some people are asking for those.  Those are bugfixes for an extremely
popular device which panics on boot without the patches.

The raspberry pi, I presume.

Meanwhile turned out between 5.10.0 and 5.10.30 the ARM64 device-trees
were modified in a way which broke Xen 4.14 on ARM64.  The change
violated Linux's own standards for device-trees, yet still appeared in a
stable branch.

In other news, if you see device-trees compared to ACPI tables, they're
not very comparable.  99% of ACPI tables work for all versions of all
OSes.  Any given device-tree is only likely to work for a single version
of a single OS.  While a useful abstraction for portions of kernel code,
device-trees are utter garbage compared to ACPI tables.

Well, now we are at Debian stable with 5.10.x for linux and 4.14.x for xen,
so we are kind of stuck with these versions on Debian stable now. I am all
for tweaking the Debian stable packages to support raspberry and amd64. The
question is, what is the quickest and least disturbing way to fix it now?

All the best,

Chuck

Bug#993829: Please ship nokogiri.h header file

2021-09-19 Thread Daniel Leidert

Am Sonntag, dem 19.09.2021 um 17:31 +0200 schrieb Cédric Boutillier:
> Hi,
> 
> I have been looking at the bugs on ruby-nokogiri before trying to update
> it to the new upstream version.
> 
> Using the gem install layout is not enough to have the
> ext/nokogiri/nokogiri.h installed. As I understand it, gem_installer.rb
> in gem2deb is removing all sources from the ext/ directory.

Actually nokogiri just failed when using the gem installation layout and I
wasn't able to fully deal with that yet (one has to remove the tarballs from
the created gemfile).

So I was thinking about just adding the header. But when nokogiri is installed
in the vendor-path, which path should we use to put the header file
(nokogiri/nogogiri.h) in?

RUBYHDRDIR (/usr/include/ruby-)
SITEHDRDIR (/usr/include/ruby-/site_ruby)
VENDORHDRDIR (/usr/include/ruby-/vendor_ruby)

That would fix the issue at hand and give us time to figure out these
questions:

> So my questions are:
> - should we modify gem2deb to allow for installation of headers file?
>   (at least maybe the ones added to the WHITELIST)
> - if so, should we install them, as the gem command does, in the
>   /usr/lib/ruby/gems/x.y.z/gems/package-a.b.c/ext subdirectory?
> OR
> - would it make sense for nokogumbo to use instead Built-Using: to use
>   the nokogiri.h present in the source package?
> 
> what would be the best strategy for this situation?

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote:
> Hi,
> 
> So you work on oldstable.
> 
> Could you check for stable/testing/unstable/experimental ? And mark
> the bug with found /not found.

Unfortunately I can't. I'm trying to get gitlab 11.11.8+dfsg-1+fto10+2 to work. 
Then I can upgrade gitlab further to 12 and 13 and only then I can upgrade 
Debian to bullseye.

I've rebuilt Debian nodejs without --shared-zlib, --shared-cares and 
--shared-libuv (remove them from debian/rules). It works now!

Going to narrow it down.

-- 
Ondrej Zary

Bug#994718: checkbashisms: notice for loops before saying to use $((

2021-09-19 Thread 積丹尼 Dan Jacobson

Package: devscripts
Version: 2.21.4
File: /usr/bin/checkbashisms

Regarding

possible bashism in (stdin) line 1 ('((' should be '$(('):
for (( k=1 ; k<8 ; k++ )) ; do echo $k ; done

OK, but

$ for (( k=1 ; k<8 ; k++ )) ; do echo $k ; done
1
2
3
4
5
6
7
$ for $(( k=1 ; k<8 ; k++ )) ; do echo $k ; done
bash: `$(( k=1 ; k<8 ; k++ ))': not a valid identifier

So checkbashisms needs to remember we are talking about a for loop here,
and say something different. (No, I don't know what it should say instead.)

Bug#994717: mention return codes on man pages

2021-09-19 Thread 積丹尼 Dan Jacobson

Package: alsa-utils
Version: 1.2.5.1-1
Severity: wishlist
File: /usr/share/man/man1/alsactl.1.gz

Mention something like
   An exit status of zero indicates success, and a nonzero value
   indicates failure.
Else one cannot tell if e.g.,

# alsactl --debug restore; echo $?
alsa-lib parser.c:2372:(load_toplevel_config) Unable to find the top-level 
configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use 
case configuration -2
alsactl: set_controls:1493: device='hw:0', doit=0
alsactl: set_controls:1505: card-info-id: 'PCH'
alsactl: set_controls:1531: maxnumid=29
alsactl: set_controls:1549: result code: 0
alsactl: set_controls:1493: device='hw:0', doit=1
alsactl: set_controls:1505: card-info-id: 'PCH'
alsactl: set_controls:1531: maxnumid=29
alsactl: set_controls:1549: result code: 0
0

worked or not.

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-09-19 Thread Felix Lechner

Hi Aurelien,

On Sun, Sep 19, 2021 at 12:15 PM Aurelien Jarno  wrote:
>
> My question is why this new breakout-link tag has been added

The tag was implemented in response to Bug#243158. [1] I am not sure
about Yann's original suggestion, but I hope the tag is useful to
prevent links to /opt, for example.

Prior to Glibc, I encountered only packages in which links and shared
objects shared a parent folder.

Kind regards
Felix Lechner

[1] https://bugs.debian.org/243158

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

On 2021-09-19 21:45:19 +0200, Vincent Lefevre wrote:
> On 2021-09-19 19:15:54 +0200, Mattia Rizzolo wrote:
> > I can never manage to download DTDs from w3.org (how could you?!), so,
> > taking your testcase and a copy of the same DTD:
> 
> The DTD is provided by Debian, no need to download it.

I can see that xhtml1-strict.dtd is provided by the w3c-dtd-xhtml
package.

You have this package installed, right?

On my machine, it is w3c-dtd-xhtml 1.2-4.

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

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

On 2021-09-19 19:15:54 +0200, Mattia Rizzolo wrote:
> I can never manage to download DTDs from w3.org (how could you?!), so,
> taking your testcase and a copy of the same DTD:

The DTD is provided by Debian, no need to download it.

> mattia@warren /tmp/tmp/xml % l
> total 68
> -rw-r--r-- 1 mattia mattia   260 Sep 19 19:02 test.html
> -rw-r--r-- 1 mattia mattia 26450 Sep  6  2014 xhtml1-strict.dtd
> -rw-r--r-- 1 mattia mattia 12055 Sep  6  2014 xhtml-lat1.ent
> -rw-r--r-- 1 mattia mattia  4293 Sep  6  2014 xhtml-special.ent
> -rw-r--r-- 1 mattia mattia 14167 Sep  6  2014 xhtml-symbol.ent
> mattia@warren /tmp/tmp/xml % cat test.html
> 
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml;>
> title
> text
> 
> mattia@warren /tmp/tmp/xml % xmllint --dtdvalid xhtml1-strict.dtd --nonet 
> --noout test.html
> I/O error : Attempt to load network entity 
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
> test.html:2: warning: failed to load external entity 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
> C//DTD XHTML 1.0 Strict//EN" 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
>   
>  ^
> mattia@warren /tmp/tmp/xml %
> 
> which looks good to me.

An I/O error is not good. Your system appears to be broken.

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

Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40

2021-09-19 Thread Jonathan Carter


Hi Samuel

On 2021/09/19 20:47, Samuel Henrique wrote:

I'd like to update this package to the latest upstream version in
order to support Gnome 40 over the next few days.

I'm also planning to push the pristine-tar and upstream branches[0],
as well as adding the upstream code to the master branch, and adding
myself as an Uploader (so that gbp can build it without extra steps).

Please let me know if you'd prefer to keep things the way they are or
would like me to only do some of those things.


Yes please go ahead, you're very welcome, feel free to add yourself as 
an uploader too if you'd like.


-Jonathan

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 19:37, Jérémy Lal  a écrit :
>
>
>
> Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES 
>  a écrit :
>>
>> Hi,
>>
>> So you work on oldstable.
>>
>> Could you check for stable/testing/unstable/experimental ? And mark
>> the bug with found /not found.
>>
>
> Interestingly, the copy of zlib in nodejs source has several patches that are 
> not
> in the official zlib release available in debian.
> So if what was said is correct (that upstream binary builds do not crash) 
> this might be a clue.

I was more thinking about a cflags like hardening flags or something
like this...

Bastien

> Jérémy

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES <
roucaries.bast...@gmail.com> a écrit :

> Hi,
>
> So you work on oldstable.
>
> Could you check for stable/testing/unstable/experimental ? And mark
> the bug with found /not found.
>
>
Interestingly, the copy of zlib in nodejs source has several patches that
are not
in the official zlib release available in debian.
So if what was said is correct (that upstream binary builds do not crash)
this might be a clue.

Jérémy

Bug#994703: [Pkg-javascript-devel] Bug#994703: nodejs: please documents deps or avoid it

Le dim. 19 sept. 2021 à 18:54, Bastien Roucariès <
roucaries.bast...@gmail.com> a écrit :

> Package: nodejs
> Version: 12.22.5~dfsg-2
> Severity: serious
>
> Dear Maintainer,
>
> README.source should document the deps directory.
>
> It will be better to remove some libs from deps. Why libz is needed for
> node ?
> Could we push this plugin stuff to libz and so on.
>
> Acorn embdeded should be fixed by recent version.
>
> openssl one is worry some..
>

Hi,

What's in ./deps/ is mostly not used for building node.
It's pretty much obvious if you look at ./debian/rules configure flags.

I believe it is not common practice to remove unused files, as long as it's
okay with DFSG.
That's why
zlib, openssl, nghttp2, http-parser, uv, c-ares, brotli
are kept around in ./deps/ directory.

This is actually useful, it makes debugging against "upstream-like" builds
easier.

Jérémy

Bug#992908: awesome: autopkgtest regression between 20 and 23 August 2021: Could not resolve keysym

2021-09-19 Thread Paul Gevers

Control: severity -1 serious

Hi Reiner,

On 19-09-2021 16:08, Reiner Herrmann wrote:
> @Paul / Release Team: I'm lowering the severity, as the failure is
> not a regression of awesome, but a test regression caused by another
> package. Solutions for this regression are mentioned above.
> If you disagree with the lowered severity, please raise it again.
> I will then filter/drop xkbcomp's output.

I can see how you come to that conclusion. However because of how
autopkgtest results are used within Debian, we, the Release Team, really
consider failing tests of RC severity [1] even though your package
didn't introduce the issue. Another example of such bugs is FTBFS due to
a build dependency breaking your build, you didn't ask for it, but if
it's not promptly solved by the build dependency it still is a problem
for your package.

As a side note, I think in hindsight autopkgtest would *not* have
defaulted to failing on output to stderr. It was a good idea, but in
practice it's causing more issues that it prevents. So I think by now it
should be opt-in, instead of opt-out. I'm still not decided if I want to
pursue and change it, but using the allow-stderr restriction is
perfectly fine.

Paul

[1] https://release.debian.org/testing/rc_policy.txt 6(a)

OpenPGP_signature
Description: OpenPGP digital signature

Bug#994715: RM: jmol-applet -- ROM; now unmaintained upstream

2021-09-19 Thread Pierre Gruet

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debichem-de...@alioth-lists.debian.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Could you please remove the binary package jmol-applet from unstable?
It is one of the four binary packages built from src:jmol.

I am asking this on behalf of Debichem team, we have discussed this removal on
the mailing list [0,1,2].

The main reasons are:
- - upstream is not providing a working applet anymore;
- - and indeed, we have been shipping a jmol-applet with no working applet 
inside
  for 5 years;
- - the popcon score has been decreasing since then;
- - the java Applet class is deprecated since Java 9;
- - because of the applet part, jmol is going to FTBFS when OpenJDK 17 becomes
  the default in Debian (see bug #981989).

jmol-appled has no reverse-dependencies, it was in the Suggests: field of
chemical-structures but has now be removed from this field in unstable, and
this will also be the case in testing in a few days.

Thanks for your help on this,

Best wishes,

- -- 
Pierre Gruet

[0] 
https://alioth-lists.debian.net/pipermail/debichem-devel/2021-September/012755.html
[1] 
https://alioth-lists.debian.net/pipermail/debichem-devel/2021-September/012756.html
[2] 
https://alioth-lists.debian.net/pipermail/debichem-devel/2021-September/012760.html


-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmFHj3QPHHBndEBkZWJp
YW4ub3JnAAoJEGADFqbcJ3R2hVsP/Ay3uqYjJsg2mK17i4HhCVbvz8V6ogX/GaPy
ICiovdF8Nn7AeUMbJy7NuHZpiEOabNwckPvb+nFMF4kwguiD4d0NMPW7cUm3AYbc
QCRMG6K3A+9Xadno00w3qpPegMPdKswKQ5PgD0ijNC2bgDLRanONUQQNU7ec9QeV
ZI6ueQdZYih3bJRDq27nEXQU70ka0/jt3kVugIJ0ZtOD03YjeKMUfz+mpsq5fqYw
ReH++vhJkW/6VfLLsh4pzpibIi4IEEOTjamjUXzdOiuf+vJUbIrF0O6OE2vibnVp
RAMUQfNM5B2EGOZPQ6AdW0xtwITjCmiXVpgVmZKg6Lkec2Y9VW9cpJSgj0Xokwl+
UUSbiLdmvSirzwHHIyBGhfAUU/6zRI1fnoAmdC7n2Nf7x7+Vvcv7SSLhWiWmO4G0
AIa7F9Te6Zn6JkzDOXRT+h0r7HXk2Xz258pFQLvzvQ9V0SL6a+TOBuips9r7kbAu
pJuOYAPsTxQrcWpHH0/NQSdlSbjMY8qsrIL41PfDbMHs8qtDA/P7iXEgXr9GOekh
8Nscvc9wvFOzeuz9ckE/IBuwhqj1cEkRWd4DzlPeraOJ0tMhSVjr6urf+6fITtQA
OhfoqJpcCFSU2rlH3Qd23YU68HSri6CHlvplkx1lxYz/4sDUV6x1BGpAphcy0y+n
oDP4YLzM
=cLA/
-END PGP SIGNATURE-

Bug#994716: lintian: erroneous unpack-message-for-orig

2021-09-19 Thread Aurelien Jarno

Package: lintian
Version: 2.106.1
Severity: normal

Since recently, I get the following lintian error message on the glibc
package:

E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
glibc-2.32/htl/libpthread.a
E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
glibc-2.32/htl/libpthread_pic.a
E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
glibc-2.32/htl/libpthread_syms.a

Those file are not archive, but a linker script. For example
libpthread.a contains:

| GROUP(-lpthread_syms)
| GROUP(-lpthread2 -lrt)

Lintian should handle this case.

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

Bug#993513: ensmallen: FTBFS with glibc 2.34

2021-09-19 Thread Étienne Mollier

Control: forwarded -1 https://github.com/mlpack/ensmallen/issues/321

Hi Graham,

On Thu, 2 Sep 2021 14:27:51 +0200 Graham Inggs  wrote:
> Your package uses a vendored copy of catch.hpp.  It will FTBFS once
> glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer
> being defined.
> 
> You could take this opportunity to switch to using the catch2 package
> [1] in Debian where this is already fixed.

Thank you for the notice, I informed upstream, and prepare a
patch to accomodate the use of Debian's catch2 in tests.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-09-19 Thread Aurelien Jarno

On 2021-09-16 16:56, Felix Lechner wrote:
> Hi Aurelien,
> 
> On Thu, Sep 16, 2021 at 4:00 PM Aurelien Jarno  wrote:
> >
> > Why is that supposed to be an issue?
> 
> I do not know, but the relocation error shows that the shared library
> installed in /lib by libgpg-error0 is not found unless
> libgpg-error0-dev ships a "breakout" link in /usr/lib.

I guess I wasn't very clear. My question is why this new breakout-link
tag has been added, and how is this supposed to be an issue. Things have
been like that in the glibc package for 20 years, so I wonder why this
issue suddenly popped-up. I can't find anything in the Debian Policy
forbidding that.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#994713: ignition-math: FTBFS on arm64, ppc64el, s390x

2021-09-19 Thread Sebastian Ramacher

Source: ignition-math
Version: 6.8.0+ds-2
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| 98% tests passed, 1 tests failed out of 51
|
| Total Test time (real) = 127.49 sec
|
| The following tests FAILED:
|32 - UNIT_SpeedLimiter_TEST (Failed)
| Errors while running CTest
| make[2]: *** [Makefile:151: test] Error 8

See
https://buildd.debian.org/status/fetch.php?pkg=ignition-math=arm64=6.8.0%2Bds-2=1629995923=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40

2021-09-19 Thread Samuel Henrique

Hello Jonathan,

I'd like to update this package to the latest upstream version in
order to support Gnome 40 over the next few days.

I'm also planning to push the pristine-tar and upstream branches[0],
as well as adding the upstream code to the master branch, and adding
myself as an Uploader (so that gbp can build it without extra steps).

Please let me know if you'd prefer to keep things the way they are or
would like me to only do some of those things.

Thank you!

[0] Though I will probably push only the latest release to these branches.

-- 
Samuel Henrique

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Hi,

So you work on oldstable.

Could you check for stable/testing/unstable/experimental ? And mark
the bug with found /not found.

Thanks

Bastien

Le dim. 19 sept. 2021 à 18:03, Ondrej Zary  a écrit :
>
> There's no such patch in 10.24.0~dfsg-1~deb10u1
>
> --
> Ondrej Zary

Bug#994712: isa-support: Please add arm6 for armel

Source: isa-support
Version: Please add armv6 support
Severity: important

Dear Maintainer,

Could you add an armv6 abi check for armel ?

It will help nodejs

Bastien

Bug#994711: lintian: empty-binary-package ignores "empty package" in package description

2021-09-19 Thread Nicolas Boulenguez

Package: lintian
Version: 2.106.1
Severity: minor
Tags: patch

Hello.

A package with 'empty package' in its long description is nevertheless
reported by lintian as an empty-binary-package.
This is inconsistent with the tag description.
See the 'gnat' package for an example.

The following trivial patch should prevent such false positives.
Of course, an other option is to remove "empty package" from the list
in tags/e/empty-binary-package.tag.

--- a/lib/Lintian/Processable/Installable/Class.pm
+++ b/lib/Lintian/Processable/Installable/Class.pm
@@ -105,7 +105,7 @@
 
 return 1
   if $self->fields->value('Description')
-  =~ /meta[ -]?package|(?:dummy|dependency) package/i;
+  =~ /meta[ -]?package|(?:dummy|dependency|empty) package/i;
 
 # section "tasks" or "metapackages" qualifies too
 return 1

Bug#986354: why this bug matters

2021-09-19 Thread Richard Lewis

I think the severity of this bug should really be set to critical per
debian's definitions (breaks unrelated software on the system)

In buster this package worked fine with gnome, in bullseye it breaks
other packages. This includes at lease uuidd-runtime upower and parts
of gnome (gnome settings crashes/fails to start/freezes if upower did
not start).

The only error messages talk about lack of disk space which is not accurate.

Although the fix may be simple, it's pretty frustrating and difficult
to understand.

Users like me will assume Debian has messed up gnome by not testing
things properly.

Can i request one or more of
- something in README.Debian listing packages broken by this package
and documenting how to re-enable user namespaces
- splitting setting user.max_user_namespaces into a separate package
which conflicts: uuid-runtime, upower (and anything else affected)
- put the setting of user.max_user_namespaces=0 into /etc so it's
easier to override
- have something in postinst that warns the user if upower and uuidd
are installed

Happy to help write documentation if that would help.

Bug#994288: [Debichem-devel] Bug#994288: Bug#994288: libinchi1: feature request, add InChI trust, reference executable

2021-09-19 Thread Michael Banck

Hi Norwid,

On Sat, Sep 18, 2021 at 09:03:45PM +, Norwid Behrnd wrote:
> On Sat, 18 Sep 2021 20:28:30 +0200
> Michael Banck  wrote:
> > On Thu, Sep 16, 2021 at 10:40:02AM +0300, Andrius Merkys wrote:
> > > Control: owner -1 !
> > > Control: tags -1 + pending
> > > 
> > > Hi Norwid,
> > > 
> > > On 2021-09-16 09:26, Norwid Behrnd wrote:  
> > > >> Am I right to assume you are requesting here for the 'inchi_main'
> > > >> executable being included in Debian packages for inchi?  
> > > > 
> > > > Yes, this is .true. and you are right.  If technical possible and
> > > > InChI trust's license permitting, I would like to install their .sdf
> > > > to InChI conversion packaged for Debian such that this may be run
> > > > from the CLI.  
> > > 
> > > Thanks for clarification. I have just packaged the executable in a new
> > > binary package, libinchi-bin, it how has to pass the NEW queue.  
> > 
> > A bit late, but maybe "inchi-bin" or even juust "inchi" would be also
> > appropriate?
> > 
> > 
> > Michael
> 
> I'm not sure if your question is about how to name the eventual
> package, or about how to launch the executable the package provides.

It was about the package.
 
[...]

> On the other hand, I interpret the package tracker's entry
> 
> "NEW/unstable: 1.03+dfsg-4"
> 
> on
> 
> https://tracker.debian.org/pkg/inchi
> 
> as if the inchi executable is going to be included within the already
> existing entry `synaptic` lists as `libinchi1`

No, there will (or is, it got manually processed already I think) be a
new package "libinchi-bin" which ships the executable.


Michael

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

There's no such patch in 10.24.0~dfsg-1~deb10u1

-- 
Ondrej Zary

Bug#994665: [debian-mysql] Bug#994665: mariadb-10.5: FTBFS on kfreebsd

2021-09-19 Thread Otto Kekäläinen

Hello!

Thanks for looking into the issue and for submitting a fix suggestion
in the form of a patch!

It would be easier to process the patch if it was an actual git commit
with explanation of why you think this is the correct solution, how it
has been tested to verify that it does indeed fix kFreeBSD builds in
Debian and how it has been fixed to prove that it does not cause
regressions on other platforms etc.

Sending a patch suggestion is already great and you are not obligated
to polish it. I am only letting you know that it is much easier for
somebody else to finish/merge this if it is more polished, but it will
eventually be done with the current version of the path as well, just
maybe a bit slower.

- Otto

Bug#994709: bullseye-pu: package gnome-maps/3.38.6-0+deb11u1

2021-09-19 Thread Simon McVittie

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

[ Reason ]
User request on #990618

[ Impact ]
If #990618 is not fixed, users who have previously selected an aerial
map (which is no longer available from the web services that GNOME uses,
if I understand correctly) will be unable to use GNOME Maps with their
saved settings due to a crash on startup.

[ Tests ]
Tested manually on a Debian 11 GNOME desktop.

[ Risks ]
GNOME Maps is part of the gnome metapackage, so it might technically be
a key package.

This is an upstream stable/bug-fix release, so it should be low-risk.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
New upstream release:
- data/maps-service.json:
  Update the cached copy of the list of map sources (it will be replaced
  with a freshly downloaded copy from a GNOME-hosted web service if
  posssible)
- po/nb.po: Translation updates
- src/mapSource.js:
  Cope with having different attribution requirements for different
  map sources. I think there's only one map source available at the
  moment, but this might change.
- src/mapView.js:
  - Don't crash if no aerial map is available (this is #990618)
  - Avoid using a special background image in dark mode if wrapping around
near the International Date Line, as a workaround for a libchamplain bug
  - Avoid saving a nonsense zoom level and location if the user changes the
view and then immediately exits
- src/osmConnection.js:
  Fix ability to sign in to OSM
- src/placeBubble.js:
  Fix a bug where place details get lost after searching again for
  the same place
- src/sidebar.js:
  Only grab focus onto next route entry in sidebar if it's empty.
  This avoids a hang when dragging around route markers.

d/watch, d/control*, d/gbp.conf: Watch for 3.38.x releases and
target bullseye.
diffstat for gnome-maps-3.38.2 gnome-maps-3.38.6

 NEWS   |   49 +++
 data/maps-service.json |   44 +--
 data/org.gnome.Maps.appdata.xml.in |   22 +
 debian/changelog   |   24 +
 debian/control |2 
 debian/control.in  |2 
 debian/gbp.conf|4 
 debian/watch   |2 
 meson.build|2 
 po/nb.po   |  515 +
 src/mapSource.js   |   65 +++-
 src/mapView.js |   54 ++-
 src/osmConnection.js   |2 
 src/placeBubble.js |4 
 src/sidebar.js |3 
 15 files changed, 508 insertions(+), 286 deletions(-)

diff -Nru gnome-maps-3.38.2/data/maps-service.json gnome-maps-3.38.6/data/maps-service.json
--- gnome-maps-3.38.2/data/maps-service.json	2020-11-21 13:24:38.734244000 +
+++ gnome-maps-3.38.6/data/maps-service.json	2021-07-09 22:47:16.568429500 +0100
@@ -5,68 +5,68 @@
 },
 "tiles": {
 "street": {
-"id": "mapbox.streets-v11",
-"name": "Mapbox street tiles",
+"id": "osm.streets",
+"name": "OpenStreetMap street tiles",
 "license": "© OpenStreetMap",
 "license_uri": "http://www.openstreetmap.org/copyright;,
 "min_zoom_level": 0,
 "max_zoom_level": 19,
-"tile_size": 512,
-"uri_format": "https://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/#Z#/#X#/#Y#?access_token=pk.eyJ1IjoiZ25vbWUtbWFwcyIsImEiOiJjaXF3a3lwbXkwMDJwaTBubmZlaGk4cDZ6In0.8aukTfgjzeqATA8eNItPJA&;,
-"attribution_logo":

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Le dim. 19 sept. 2021 à 17:40, Ondrej Zary  a écrit :
>
> Upstream node rebuilt in Debian works. So it's not a compiler or libc problem.

Does removing the debian patch
large_pages_assembly_gnu_stack.patch

Changes something ?

Bastien


> The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 already contains SSE2 
> instructions - it does not work on Pentium 3:
> $ node
> Illegal instruction
>
> So I doubt that changing -march would help.
>
> --
> Ondrej Zary

Bug#994691: [debian-mysql] Bug#994691: mariadb-server-10.5: Typo in /usr/bin/wsrep_sst_mariabackup

2021-09-19 Thread Otto Kekäläinen

Hello!

Thanks for the report and the fix suggestion. Would you like to send
it as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5 ?

Even though this is just an onliner, please write a good git commit
message and reference the upstream bug report or commit that fixed it.
If it is not fixed at all upstream, then please also engage there and
help this fixed for everybody. Thanks!

Bug#994076: vim: CVE-2021-3770: using retab with large value may lead to heap buffer overflow

2021-09-19 Thread James McCoy

On Wed, Sep 15, 2021 at 06:23:14AM +0200, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Tue, Sep 14, 2021 at 09:06:22PM -0400, James McCoy wrote:
> > On Sat, Sep 11, 2021 at 09:26:04AM +0200, Salvatore Bonaccorso wrote:
> > > The following vulnerability was published for vim.
> > > 
> > > CVE-2021-3770[0]:
> > > | vim is vulnerable to Heap-based Buffer Overflow
> > > 
> > > The fix is at [1] but needed a followup [2].
> > 
> > Does this need to go through bullseye-security or would a bullseye
> > upload suffice?  I have a couple other fixes (#993766 and maybe #994209)
> > in the pipeline that would be good for bullseye, so I could group these
> > together.
> 
> IMHO it should be enough to route the update trough the upcoming point
> release(s) for bullseye and buster (would you as well prepare an
> update there for buster?)

Yeah, I'll try to get them done in the next few days (for both
releases).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

Upstream node rebuilt in Debian works. So it's not a compiler or libc problem.

The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 already contains SSE2 
instructions - it does not work on Pentium 3:
$ node
Illegal instruction

So I doubt that changing -march would help.

-- 
Ondrej Zary

Bug#994708: pulseaudio: Does not create /etc/pulse/system.pa.d directory

2021-09-19 Thread Diederik de Haas

Package: pulseaudio
Version: 15.0+dfsg1-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have several customizations in /etc/pulse/system.pa and the latest
upgrade of pulseaudio therefor prompted me what to do with it.

The new last lines of /etc/pulse/system.pa are as follows:
=
### Allow including a system.pa.d directory, which if present, can be used
### for additional configuration snippets.
.nofail
.include /etc/pulse/system.pa.d
=

That seems exactly what I want and will prevent future upgrade prompts.
Excellent :-) But the directory doesn't exist.
It does have a 'client.conf.d' and a 'default.pa.d' which I presume have
the same functionality. But the corresponding one for 'system.pa.d' is
missing and I think the package ought to create it.

Cheers,
  Diederik

- -- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.5.1-1
ii  libasound2-plugins   1.2.5-2
ii  libc62.33-0experimental1
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libfftw3-single3 3.3.8-2
ii  libgcc-s111.2.0-5
ii  libglib2.0-0 2.68.4-1
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse015.0+dfsg1-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   11.2.0-5
ii  libsystemd0  247.9-1
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.9-1
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 15.0+dfsg1-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.9-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
ii  paprefs  1.1-2
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 247.9-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYUds7gAKCRDXblvOeH7b
bl2HAQCfYS1KXlXmqnKz3yMy8cyxqYBjPv6hsAQb1GrY/yVgcQEA0EgtMoXx4HQT
nVCqnrGDrEw1qGSNeoc3Swk0dFzM4Q4=
=1wMv
-END PGP SIGNATURE-

Bug#994707: checksecurity: Please move /etc/checksecurity.conf to /etc/checksecurity/checksecurity.conf

2021-09-19 Thread Richard Lewis

Package: checksecurity
Version: 2.0.16+nmu2
Severity: wishlist
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

Please consider moving /etc/checksecurity.conf inside /etc/checksecurity/

this would make it easier to keep all config files in a single git repository

thanks for considering

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

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

Versions of packages checksecurity depends on:
ii  anacron2.3-30
ii  cron   3.0pl1-137
ii  debconf [debconf-2.0]  1.5.77
ii  perl   5.32.1-4+deb11u1
ii  util-linux 2.36.1-8

Versions of packages checksecurity recommends:
ii  debsecan  0.4.20.1
ii  logcheck  1.3.23
ii  meta-missing-dependencies [tripwire]  10.0+3
ii  tiger 1:3.2.4~rc1-3

Versions of packages checksecurity suggests:
ii  cron-apt0.13.0+nmu1
ii  lockfile-progs  0.1.18

-- Configuration Files:
/etc/checksecurity.conf changed [not included]
/etc/checksecurity/check-diskfree.conf changed [not included]
/etc/checksecurity/check-setuid.conf changed [not included]

-- debconf information excluded

Bug#991967: Simply ACPI powerdown/reset issue?

2021-09-19 Thread Diederik de Haas

Adding pkg-xen-de...@lists.alioth.debian.org into the loop.

Chuck Zmudzinski replied to the bug and later replied to his own reply. 
To give full context, I've added the original reply in full and Chuck's reply 
to that (as it only quoted part of the context there).

On zondag 19 september 2021 07:05:56 CEST Chuck Zmudzinski wrote:
> On Sat, 11 Sep 2021 13:29:12 +0200 Salvatore Bonaccorso
> 
>  wrote:
>  > Hi Elliott,
>  > 
>  > On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
>  > > An experiment lead to a potential alternative explanation for #991967.
>  > > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
>  > > 4.19.194-3. Presence of Xen on the system may be unrelated.
>  > > 
>  > > Failing that, it could be Xen and non-UEFI systems are effected. (Xen
>  > > was tried on a UEFI system and the issue wasn't observed)
>  > 
>  > Following up on https://bugs.debian.org/991967#12
>  > 
>  > Did you succeeded in bisecting the issue as you seem to have it
>  > reproducible?
>  > 
>  > Regards,
>  > Salvatore
> 
> Hello Elliott and Salvatore,
> 
> I noticed this bug on bullseye ever since I have been
> running bullseye as a dom0, but my testing indicates
> there is no problem with src:linux but the problem
> appeared in src:xen with the 4.14 version of xen on
> bullseye.
> 
> I ask Elliott if you are only seeing the problem on Debian's
> xen-4.14 hypervisor? Also, which architecture, arm or
> amd64? I only see the problem on the Debian xen-4.14
> hypervisor, and I have only tested on amd64, and I
> have found a fix for my amd64 system which is as
> follows:
> 
> Motherboard: ASRock B85M Pro4, BIOS P2.50 12/11/2015,
> with a Haswell CPU (core i5-4590S)
> 
> xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64
> 
> linux kernel version: 5.10.46-4 (the current amd64 kernel
> for bullseye)
> 
> Boot system: EFI, not using secure boot, booting xen
> hypervisor and dom0 bullseye with grub-efi package for
> bullseye, and it boots the xen-4.14-amd64.gz file, not
> the xen-4.14-amd64.efi file.
> 
> I also tested a buster dom0 with the 4.19 series kernel
> on the xen-4.14 hypervisor from bullseye and saw the
> problem, but I did not see the problem with either
> a buster (linux 4.19) or bullseye (linux 5.10) dom0 on
> the xen-4.11 hypervisor, so I think the problem is
> with the Debian version of the xen-4.14 hypervisor,
> not with src:linux.
> 
> I also found a fix in src:xen:
> 
> I noticed the series of patches in debian/patches of the
> 4.14.2+25-gb6a8c4f72d-2 version of src:xen (and
> earlier versions of xen-4.14 on Debian) have several patches
> backported from the unstable branch of xen upstream. By
> removing some of these patches from the patches
> series of the src:xen package, the dom0 shuts down
> as expected on my ASRock Haswell motherboard.
> 
> I rebuilt the src:xen package after removing the following
> patches from the debian/patches series and the result
> was that the computer shuts down as expected if I boot
> using the patched hypervisor:
> 
> 0027-xen-rpi4-implement-watchdog-based-reset.patch
> 0028-tools-python-Pass-linker-to-Python-build-process.patch
> 0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> 0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
> 0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
> 0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
> 0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
> 0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
> 
> Most of these patches seem unrelated to the amd64
> architecture and instead affect the arm architecture, and
> removing all these patches is probably more than is needed to
> fix this bug, but I removed them all because I could not find
> them upstream on the 4.14 branch but instead only saw them
> on the xen unstable branch upstream (I did not check if they are
> on the 4.15 branch upstream), and I wanted to test
> a true upstream 4.14 version without these seemingly
> aggressive patches added by Debian from the unstable
> branch of xen upstream, and I discovered by being
> more conservative and not adding these patches from the
> unstable branch upstream fixed the problem!
> 
> I suspect the following patch is the culprit for problems
> shutting down on the amd64 architecture:
> 
> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> 
> The commit log for this patch states:
> 
> From: Julien Grall 
> Date: Sat, 26 Sep 2020 17:44:29 +0100
> Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
> 
> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
> while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
> 
> Currently, the former are still containing x86 specific code.
> 
> To avoid this rather strange split, the generic helpers are reworked so
> they are arch-agnostic. This requires the introduction of

Bug#784986: RFP: google-drive-ocamlfuse -- FUSE filesystem over Google Drive

2021-09-19 Thread Attila Csipak

On Mon, 11 May 2015 14:28:12 +0200 Willem Mulder <
will...@scintilla.utwente.nl> wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: google-drive-ocamlfuse
>   Version : 0.5.15
>   Upstream Author : Alessandro Strada 
> * URL : http://gdfuse.forge.ocamlcore.org/
> * License : MIT
>   Programming Lang: OCaml
>   Description : FUSE filesystem over Google Drive
>
> google-drive-ocamlfuse is a FUSE-based file system backed by Google Drive,
> written in OCaml. It lets you mount your Google Drive on Linux.
> .
> Features:
>  *  Full read/write access to ordinary files and folders
>  *  Read-only access to Google Docs, Sheets, and Slides (exported to
> configurable formats)
>  *  Multiple account support
>  *  Duplicate file handling
>  *  Access to trash (`.Trash` directory)
>
> Since the only package in the repositories interfacing with Google Drive
--
> grive -- is now broken (see bug #783169), it's useful to have a
replacement.
> There is a RFP for such a program already (see bug #714973), but that one
does
> not seem to be actively maintained, judging from the last commit to the
git
> repository (9 Sep 2012) and the lack of response to reported issues.
>
> Thanks in advance,
> Willem Mulder
>
>

The URL in the original 2015 request above looks stale, the project has
moved to GitHub:
https://github.com/astrada/google-drive-ocamlfuse/wiki/Installation

Also current version is 0.7.26

Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken

2021-09-19 Thread Mattia Rizzolo

Control: tag -1 unreproducible

On Sat, Sep 04, 2021 at 03:40:17AM +0200, Vincent Lefevre wrote:
> After the upgrade to 2.9.12+dfsg-3, XHTML 1.0 validation is broken.
> There was no such issue with 2.9.10+dfsg-6.7.

Actually, I can't reproduce it.
And, honestly, I think that if really didn't work I would have heard
quite a lot of noise by now.

> $ xmllint --noout --loaddtd --valid test.html
> error : xmlAddEntity: invalid redeclaration of predefined entity
> error : xmlAddEntity: invalid redeclaration of predefined entity

I can never manage to download DTDs from w3.org (how could you?!), so,
taking your testcase and a copy of the same DTD:

mattia@warren /tmp/tmp/xml % l
total 68
-rw-r--r-- 1 mattia mattia   260 Sep 19 19:02 test.html
-rw-r--r-- 1 mattia mattia 26450 Sep  6  2014 xhtml1-strict.dtd
-rw-r--r-- 1 mattia mattia 12055 Sep  6  2014 xhtml-lat1.ent
-rw-r--r-- 1 mattia mattia  4293 Sep  6  2014 xhtml-special.ent
-rw-r--r-- 1 mattia mattia 14167 Sep  6  2014 xhtml-symbol.ent
mattia@warren /tmp/tmp/xml % cat test.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml;>
title
text

mattia@warren /tmp/tmp/xml % xmllint --dtdvalid xhtml1-strict.dtd --nonet 
--noout test.html
I/O error : Attempt to load network entity 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
test.html:2: warning: failed to load external entity 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
   ^
mattia@warren /tmp/tmp/xml %

which looks good to me.


This is with the current 2.9.12+dfsg-4.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#917381: Support git-less operation

2021-09-19 Thread Martin-Éric Racine

Package: lintian-brush
Version: 0.113
Followup-For: Bug #917381

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greetings,

I'm just curious to hear if any progress is being made on this item?

Martin-Éric

- -- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lintian-brush depends on:
ii  devscripts   2.21.4
ii  python3  3.9.2-3
ii  python3-breezy   3.2.1-1
ii  python3-debian   0.1.39
ii  python3-debmutate0.39
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.23-1
ii  python3-iniparse 0.4-3
ii  python3-iso8601  0.1.13-1
ii  python3-ruamel.yaml  0.16.12-2
ii  python3-tqdm 4.57.0-2
ii  python3-upstream-ontologist  0.1.22-1

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-2
ii  libdebhelper-perl13.5.1
ii  lintian  2.106.1
ii  ognibuild0.0.9-1
ii  python3-asyncpg  0.24.0-1
ii  python3-bs4  4.9.3-1
ii  python3-docutils 0.16+dfsg-4
ii  python3-levenshtein  0.12.2-1
ii  python3-lxml 4.6.3+dfsg-1
ii  python3-markdown 3.3.4-1
ii  python3-pyinotify0.9.6-1.3
ii  python3-tomlkit  0.6.0-2

Versions of packages lintian-brush suggests:
pn  breezy-debian  
ii  gnome-pkg-tools0.22.4
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFHan0ACgkQrh+Cd8S0
17bjHg//STvnPN4zp5V5E6Ojg3Ucpyzr4q3d6trpwnFKflxYsFeBDR+PGPJ4mvi7
mq77gXnQNQflvXqkKwFXg/th7LO4iR0eYP4LdsP3z7dEHYApf1cVyLzdMNxA05+r
gRRThupmUb04bd3JNCb12doqypPPzdO7bfH/0YYLVAU9DXh50ntPZLLTyhljwSsF
gw8YHWW3LZWhpYRgILEOvKEne+fDJA6y5/A9wMvsNKdWuJxbq2f5L+YNhkKp+WC4
LI5PTiNTk/23V6h5tanyx7iitdpO1ACnNOza39bTghER1fLit49jow8dGMnbAI8I
P9c/i22ChrZi92gsMwhYmBHH3jp0sOrGMRJFrQ/pgWXFp2eLGF564PIV2QVSpI7f
hm1lvjGKB79pkhp5oBuOgq1ril7p59IYhTSoe6OE6G/urR9S57UihNf9aM5ZDqxt
ZHGfYdhagH4cs9/CTJQITYQuamqq9YyUrNfQ2g9hNuPSMdsuc0qwgpUVZ5R3cao/
rrv9+K215+J8livMKnE+KryasIq3PRYsV/WyDai+V7hoP3tq6DhrHXTn0Hjm5SEG
nNxxCuvkWR13PIxhCbRaRx9BW3i4dj7BsU02alNYkW32E3zXiw2GPDwBP8Mp5VMs
smXLS/AYaQPvuTkvIftyUxMVPgKlmZdF9qJGjBEV8gTvA3jKzck=
=bn4i
-END PGP SIGNATURE-

Bug#994686: [Pkg-nagios-devel] Bug#994686: [INTL:sv] Swedish strings for nagvis debconf

2021-09-19 Thread Sebastiaan Couwenberg

On 9/19/21 6:29 PM, Anders Jonsson wrote:
> I saw this is marked pending, but hopefully there is time for a minor
> fix. The attached file fixes a minor typo (paktet -> paketet).

Thanks. Also applied.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#994705: MA: same libnode-dev

Package: libnode-dev
Version: 12.22.5~dfsg-2
Severity: important

Dear Maintainer,

It will be nice if libnode-dev ship header on arch triplet instead on directly
include path

Bastien

Bug#994704: timeshift: Unable to init server: connection refused. possible pkexec misconfiguration for timeshift-laucher command

2021-09-19 Thread Bruno Gregório

Package: timeshift
Version: 20.11.1-1
Severity: normal
X-Debbugs-Cc: bruno08ne...@gmail.com

Dear Maintainer,

When I tried to open the GUI version of timeshift through the 
application icon, nothing happened.
After trying the timeshift-launcher command I got the following error:

Unable to init server: Could not connect: Connection refused

It seems to be somthing with pkexec. 
I can run other admin GUI applications like synaptics.
I can still open timeshift with `sudo timeshift-gtk`.


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

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

Versions of packages timeshift depends on:
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libjson-glib-1.0-0   1.6.2-1
ii  libvte-2.91-00.62.3-1
ii  psmisc   23.4-2
ii  rsync3.2.3-4

timeshift recommends no packages.

timeshift suggests no packages.

-- no debconf information

Bug#994703: nodejs: please documents deps or avoid it

Package: nodejs
Version: 12.22.5~dfsg-2
Severity: serious

Dear Maintainer,

README.source should document the deps directory.

It will be better to remove some libs from deps. Why libz is needed for node ?
Could we push this plugin stuff to libz and so on.

Acorn embdeded should be fixed by recent version.

openssl one is worry some...

Bastien

Bug#994686: [INTL:sv] Swedish strings for nagvis debconf

2021-09-19 Thread Anders Jonsson


Hi Martin, Sebastiaan,
I saw this is marked pending, but hopefully there is time for a minor 
fix. The attached file fixes a minor typo (paktet -> paketet).



Regards,
Anders Jonsson
# Translation of nagvis debconf template to Swedish
# Copyright (C) 2012 Martin Bagge 
# This file is distributed under the same license as the nagvis package.
#
# Martin Bagge , 2012, 2021
msgid ""
msgstr ""
"Project-Id-Version: nagvis\n"
"Report-Msgid-Bugs-To: nag...@packages.debian.org\n"
"POT-Creation-Date: 2020-01-21 20:05+0100\n"
"PO-Revision-Date: 2021-09-17 20:12+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"

#. Type: select
#. Choices
#: ../nagvis.templates:2001
msgid "shinken"
msgstr "shinken"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid "Monitoring suite used with NagVis:"
msgstr "Övervakningssvit som används med NagVis:"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"The NagVis package supports Icinga as well as Nagios, using the check-mk-"
"live broker backend."
msgstr ""
"NagVis-paketet har stöd för Icinga så väl sm Nagios, genom att använda "
"bakdelen check-mk-live."

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"If you would like to use NagVis with a different backend or a different "
"monitoring suite, please choose \"other\". You'll have to configure it "
"manually."
msgstr ""
"Vill du använda NagVis med en annan bakdel eller en annan övervakningssvit "
"vänligen välj då \"annan\". Inställningarna ska då göras manuellt."

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid "Delete NagVis data when purging the package?"
msgstr "Ska NagVis data tas bort när paketet tas bort?"

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid ""
"NagVis creates files in /var/{cache,lib}/nagvis and /etc/nagvis (for "
"instance background images and map files), including a small database for "
"authentification. If you don't need any of these files, they can be removed "
"now, or you may want to keep them and clean up by hand later."
msgstr ""
"NagVis skapar filer i /var/{cache,lib}/nagvis och /etc/nagvis (exempelvis "
"bakgrundsbilder och datafiler), bland annat en liten databas för "
"autentisering. Om du inte behöver dessa filer så kan de tas bort nu om du "
"inte vill behålla dem och ta bort de manuellt senare."

Bug#991967: #991967: Simply ACPI powerdown/reset issue?