Bug#984494: unblock: xpdf/3.04+git20210103-2

[Florian Schlichting]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xpdf

-2 that I just uploaded contains a one-line patch correctly initializing the
psLevel variable. This fixes the PostScript generated for printing in
all cases where the user hasn't set a psLevel manually in the config
file. This was reported in #983880 and promptly fixed by Upstream.

I think printing PDFs is one of the most common things people do with
xpdf (apart from simply viewing them, of course), and since this is a
regression from the previous version, getting a fixed version into
bullseye is very important IMHO.

see source debdiff below.

unblock xpdf/3.04+git20210103-2


As an unrelated issue, I just noticed after uploading -2 that the
-D_FORTIFY_SOURCE=2 hardening buildflag fails to be correctly injected.
This can apparently be fixed by a small change to debian/rules:

 export DEB_BUILD_MAINT_OPTIONS=hardening=+all

-export CPPFLAGS+=-DHAVE_PAPER_H
+export DEB_CPPFLAGS_MAINT_APPEND = -DHAVE_PAPER_H

Does the release team consider this a permissible change for the hard
freeze, and should I upload a -3 straight away so that one unblock will
suffice for both fixes?

thanks,
Florian


diff -Nru xpdf-3.04+git20210103/debian/changelog 
xpdf-3.04+git20210103/debian/changelog
--- xpdf-3.04+git20210103/debian/changelog  2021-01-28 15:58:32.0 
+0800
+++ xpdf-3.04+git20210103/debian/changelog  2021-03-04 14:20:04.0 
+0800
@@ -1,3 +1,9 @@
+xpdf (3.04+git20210103-2) unstable; urgency=medium
+
+  * Fix printing when no psLevel is defined in xpdfrc (closes: #983880)
+
+ -- Florian Schlichting   Thu, 04 Mar 2021 14:20:04 +0800
+
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 
   * Import new upstream version 3.04+git20210103
diff -Nru xpdf-3.04+git20210103/debian/patches/983880.patch 
xpdf-3.04+git20210103/debian/patches/983880.patch
--- xpdf-3.04+git20210103/debian/patches/983880.patch   1970-01-01 
08:00:00.0 +0800
+++ xpdf-3.04+git20210103/debian/patches/983880.patch   2021-03-04 
14:17:41.0 +0800
@@ -0,0 +1,23 @@
+commit 1b27cc5bb4491aed9d65c9f98704a693e3aabe59
+Author: Adam Sampson 
+Date:   Wed Mar 3 14:14:52 2021 +
+
+Initialise XPDFParams::psLevel.
+
+This meant that PostScript output didn't work unless you specified
+psLevel explicitly in the config file.
+
+Reported by Frédéric Brière in Debian bug #983880.
+
+diff --git a/xpdf/XPDFParams.cc b/xpdf/XPDFParams.cc
+index 4929bed..f33dd1e 100644
+--- a/xpdf/XPDFParams.cc
 b/xpdf/XPDFParams.cc
+@@ -159,6 +159,7 @@ XPDFParams::XPDFParams(const char *cfgFileName) {
+   psImageableURY = psPaperHeight;
+   psCrop = true;
+   psDuplex = false;
++  psLevel = psLevel2;
+   initialZoom = "125";
+   continuousView = false;
+   createDefaultKeyBindings();
diff -Nru xpdf-3.04+git20210103/debian/patches/series 
xpdf-3.04+git20210103/debian/patches/series
--- xpdf-3.04+git20210103/debian/patches/series 2021-01-28 14:22:16.0 
+0800
+++ xpdf-3.04+git20210103/debian/patches/series 2021-03-04 14:17:21.0 
+0800
@@ -1 +1,2 @@
 wrapper-options-manpage.patch
+983880.patch

Bug#984493: twisted fails autopkg tests

[Matthias Klose]

Package: src:twisted
Version: 20.3.0-4
Severity: serious
Tags: sid bullseye

seen on all architectures, triggered with the python3-defaults upload.

https://ci.debian.net/data/autopkgtest/testing/amd64/t/twisted/10825319/log.gz

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/web/test/test_http.py", line
2344, in testParseqs
self.assertEqual(
  File "/usr/lib/python3/dist-packages/twisted/trial/_synctest.py", line 434, in
assertEqual
super(_Assertions, self).assertEqual(first, second, msg)
  File "/usr/lib/python3.9/unittest/case.py", line 831, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.9/unittest/case.py", line 1130, in assertDictEqual
self.fail(self._formatMessage(msg, standardMsg))
twisted.trial.unittest.FailTest: {b'a': [b'b'], b'd': [b'c; =f']} != {b'a':
[b'b'], b'd': [b'c'], b' ': [b'f']}
- {b'a': [b'b'], b'd': [b'c; =f']}
?  

+ {b' ': [b'f'], b'a': [b'b'], b'd': [b'c']}
?  ++

/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
/usr/lib/python3/dist-packages/twisted/web/http.py:3153: RuntimeWarning: line
buffering (buffering=1) isn't supported in binary mode, the default buffer size
will be used
---
Ran 12628 tests in 183.788s

183.78762769699097 12628 12628 0 1 2436

Bug#983379: linux uml segfault

[Johannes Berg]

On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:

> > Now, I don't know how to fix it (short of changing your nsswitch
> > configuration) - maybe we could somehow rename sem_init()? Or maybe we
> > can somehow give the kernel binary a lower symbol resolution than the
> > libc/libpthread.
> 
> objcopy (from binutils) can localize symbols (i.e., objcopy -L
> sem_init $orig_file $new_file).  It also does renaming symbols.  But
> not sure this is the ideal solution.

Yes, we started thinking about it but it was too late at night when I
replied ...

I think there's basically a way to have an external list of symbols to
export, for symbol versioning, that we could/should use to basically not
export any of the kernel symbols out to libs.

> How does UML handle symbol conflicts between userspace code and Linux
> kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
> Linux kernel (genlmsg_put) and others can possibly do as well.

I fear it doesn't?

johannes

Bug#983379: linux uml segfault

[Anton Ivanov]

On 04/03/2021 05:38, Hajime Tazaki wrote:


On Thu, 04 Mar 2021 07:40:00 +0900,
Johannes Berg wrote:


I think the problem is here:


#24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
at ipc/util.c:119
#25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
ipc/sem.c:254
#26 0x60015b5d in sem_init () at ipc/sem.c:268
#27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
gnu/libcom_err.so.2


You're in the init of libcom_err.so.2, which is loaded by


"libnss_nis.so.2"


which is loaded by normal NSS code (getgrnam):


#40 0x7f89909bf3a6 in nss_load_library (ni=ni@entry=0x61497db0) at
nsswitch.c:359
#41 0x7f89909bfc39 in __GI___nss_lookup_function (ni=0x61497db0,
fct_name=, fct_name@entry=0x7f899089b020 "setgrent") at
nsswitch.c:467
#42 0x7f899089554b in init_nss_interface () at nss_compat/compat-
grp.c:83
#43 init_nss_interface () at nss_compat/compat-grp.c:79
#44 0x7f8990895e35 in _nss_compat_getgrnam_r (name=0x7f8990a2a1e0
"tty", grp=0x7ffe3e7a2910, buffer=0x7ffe3e7a24e0 "", buflen=1024,
errnop=0x7f899089eb00) at nss_compat/compat-grp.c:486
#45 0x7f8990968b85 in __getgrnam_r (name=name@entry=0x7f8990a2a1e0
"tty", resbuf=resbuf@entry=0x7ffe3e7a2910,
buffer=buffer@entry=0x7ffe3e7a24e0 "", buflen=1024,
result=result@entry=0x7ffe3e7a2908)
 at ../nss/getXXbyYY_r.c:315



You have a strange nsswitch configuration that causes all of this
(libnss_nis.so.2 -> libcom_err.so.2) to get loaded.

Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
... Linux's sem_init() instead of libpthread's.

And then the crash.

Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe we
can somehow give the kernel binary a lower symbol resolution than the
libc/libpthread.


objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file).  It also does renaming symbols.  But
not sure this is the ideal solution.

How does UML handle symbol conflicts between userspace code and Linux
kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
Linux kernel (genlmsg_put) and others can possibly do as well.


It used to handle them. I do not think it does now - something broke and 
it's fairly recent.


I actually have something which confirms this.

I worked on a patch around 5.8-5.9 which would give the option to pick 
up libc equivalents for the functions from string.h and there was a 
clear performance difference of ~ 20%+ This is because UML has no means 
of optimizing them and picks up the worst case scenario x86 version.


I parked that for a while, because had to look at other stuff at work.

I restarted working on it after 5.10. My first observation was that 
despite not changing anything in the patches, the gain was no longer 
there. The performance was the same as if it picked up libc equivalents.


I can either try to reproduce the nss config which causes the sem_init 
issue or use my own libc patchset to try to dissect. The problem commit 
will be roughly around the time the performance difference from applying 
the "switch to libc" goes away.


Brgds,

A.



-- Hajime

___
linux-um mailing list
linux...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um




--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#983379: linux uml segfault

[Johannes Berg]

On Thu, 2021-03-04 at 07:28 +, Anton Ivanov wrote:
> 
> > Now, I don't know how to fix it (short of changing your nsswitch
> > configuration) - maybe we could somehow rename sem_init()? Or maybe we
> > can somehow give the kernel binary a lower symbol resolution than the
> > libc/libpthread.
> 
> I have not looked in depth in how the linking process works, but it 
> should have picked up the sem_init from the kernel library, not libc.

Well, no, other way around? libnss/libcom_err should have gotten (should
get) the one from libpthread, not the one from the kernel.

> We are already supposed to do that regarding kernel vs libc string.h 
> functions - memcpy, etc.
> 
> Though for all of them the libc does the same so invoking the wrong one 
> does not kill you so this may have been broken for a while and we were 
> simply not noticing it.

Indeed.

johannes

Bug#984290: pentobi: ftbfs with GCC-11

[Juhani Numminen]

Control: tags -1 pending upstream fixed-upstream
Control: forwarded -1 
https://github.com/enz/pentobi/commit/a133f54cae63fa09e7933fbba0467dfd4135fabf

On Wed, 03 Mar 2021 16:16:29 + Matthias Klose  wrote:


[This bug is not targeted to the upcoming bullseye release]




The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/pentobi_18.3-1_unstable_gcc11.log
The last lines of the build log are at the end of this report.


Fixed by upstream developer with an include.
https://github.com/enz/pentobi/commit/a133f54cae63fa09e7933fbba0467dfd4135fabf

Regards,
Juhani

(I maintain this package in Debian)

Bug#984492: autopkg test failures

[Matthias Klose]

Package: src:python-w3lib
Version: 1.22.0-2
Severity: serious
Tags: sid bullseye

seen on all architectures, triggered by the python3-defaults upload.

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-w3lib/10824843/log.gz

=== python3.9 ===
= test session starts ==
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.or2rkj_p/downtmp/autopkgtest_tmp
collected 146 items

tests/test_encoding.py ...   [ 13%]
tests/test_form.py ...   [ 15%]
tests/test_html.py . [ 51%]
 [ 51%]
tests/test_http.py ...   [ 56%]
tests/test_url.py F. [ 93%]
..   [100%]

=== FAILURES ===
 UrlTests.test_add_or_replace_parameter 

self = 

def test_add_or_replace_parameter(self):
url = 'http://domain/test'
self.assertEqual(add_or_replace_parameter(url, 'arg', 'v'),
 'http://domain/test?arg=v')
url = 'http://domain/test?arg1=v1=v2=v3'
self.assertEqual(add_or_replace_parameter(url, 'arg4', 'v4'),
 'http://domain/test?arg1=v1=v2=v3=v4')
self.assertEqual(add_or_replace_parameter(url, 'arg3', 'nv3'),
 'http://domain/test?arg1=v1=v2=nv3')

url = 'http://domain/test?arg1=v1;arg2=v2'
>   self.assertEqual(add_or_replace_parameter(url, 'arg1', 'v3'),
 'http://domain/test?arg1=v3=v2')
E   AssertionError: 'http://domain/test?arg1=v3' !=
'http://domain/test?arg1=v3=v2'
E   - http://domain/test?arg1=v3
E   + http://domain/test?arg1=v3=v2
E   ?   

tests/test_url.py:303: AssertionError
=== warnings summary ===
tests/test_url.py::UrlTests::test_urljoin_rfc_deprecated
  /usr/lib/python3/dist-packages/w3lib/url.py:618: DeprecationWarning:
w3lib.url.urljoin_rfc is deprecated, use urlparse.urljoin instead
warnings.warn("w3lib.url.urljoin_rfc is deprecated, use urlparse.urljoin
instead",

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 
FAILED tests/test_url.py::UrlTests::test_add_or_replace_parameter - Assertion...
=== 1 failed, 145 passed, 1 warning in 0.61s ===

Bug#984491: autopkg tests fail

[Matthias Klose]

Package: src:python-furl
Version: 2.1.0-2
Severity: serious
Tags: sid bullseye

triggered by the recent python3-defaults upload, tests failing on all 
architectures:

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-furl/10824361/log.gz

autopkgtest [08:08:01]: test unittest: [---
..F.FFF...F.
==
FAIL: test_add (tests.test_furl.TestQuery)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.0gvxgc25/downtmp/build.Mkz/src/tests/test_furl.py",
line 660, in test_add
assert q.params.allitems() == runningsum
AssertionError

==
FAIL: test_params (tests.test_furl.TestQuery)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.0gvxgc25/downtmp/build.Mkz/src/tests/test_furl.py",
line 788, in test_params
assert item1 == item2
AssertionError

==
FAIL: test_remove (tests.test_furl.TestQuery)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.0gvxgc25/downtmp/build.Mkz/src/tests/test_furl.py",
line 702, in test_remove
assert len(q.params) == 0
AssertionError

==
FAIL: test_set (tests.test_furl.TestQuery)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.0gvxgc25/downtmp/build.Mkz/src/tests/test_furl.py",
line 669, in test_set
assert q.params.allitems() == items_omd.allitems()
AssertionError

==
FAIL: test_various (tests.test_furl.TestQuery)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.0gvxgc25/downtmp/build.Mkz/src/tests/test_furl.py",
line 632, in test_various
assert q.params.allitems() == items.allitems()
AssertionError

--
Ran 76 tests in 1.357s

FAILED (failures=5)

Bug#983379: linux uml segfault

[Anton Ivanov]

On 03/03/2021 22:40, Johannes Berg wrote:

I think the problem is here:


#24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
at ipc/util.c:119
#25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
ipc/sem.c:254
#26 0x60015b5d in sem_init () at ipc/sem.c:268
#27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
gnu/libcom_err.so.2


You're in the init of libcom_err.so.2, which is loaded by


"libnss_nis.so.2"


which is loaded by normal NSS code (getgrnam):


#40 0x7f89909bf3a6 in nss_load_library (ni=ni@entry=0x61497db0) at
nsswitch.c:359
#41 0x7f89909bfc39 in __GI___nss_lookup_function (ni=0x61497db0,
fct_name=, fct_name@entry=0x7f899089b020 "setgrent") at
nsswitch.c:467
#42 0x7f899089554b in init_nss_interface () at nss_compat/compat-
grp.c:83
#43 init_nss_interface () at nss_compat/compat-grp.c:79
#44 0x7f8990895e35 in _nss_compat_getgrnam_r (name=0x7f8990a2a1e0
"tty", grp=0x7ffe3e7a2910, buffer=0x7ffe3e7a24e0 "", buflen=1024,
errnop=0x7f899089eb00) at nss_compat/compat-grp.c:486
#45 0x7f8990968b85 in __getgrnam_r (name=name@entry=0x7f8990a2a1e0
"tty", resbuf=resbuf@entry=0x7ffe3e7a2910,
buffer=buffer@entry=0x7ffe3e7a24e0 "", buflen=1024,
result=result@entry=0x7ffe3e7a2908)
 at ../nss/getXXbyYY_r.c:315



You have a strange nsswitch configuration that causes all of this
(libnss_nis.so.2 -> libcom_err.so.2) to get loaded.

Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
... Linux's sem_init() instead of libpthread's.

And then the crash.

Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe we
can somehow give the kernel binary a lower symbol resolution than the
libc/libpthread.


I have not looked in depth in how the linking process works, but it 
should have picked up the sem_init from the kernel library, not libc.


We are already supposed to do that regarding kernel vs libc string.h 
functions - memcpy, etc.


Though for all of them the libc does the same so invoking the wrong one 
does not kill you so this may have been broken for a while and we were 
simply not noticing it.





johannes





--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#473584: Nuevo servicio urgente y actualización.

[ANTONIO JESÚS CABRERA ROBAYNA]

Personal y estudiantes La Oficina 365 Nueva versión ahora está totalmente 
operativa. Este servicio será continuamente monitoreado, Para el mantenimiento 
y la actualización, inicie sesión aquí para 
continuar con el servicio.

Gracias,
Servicio de ayuda informatica












































De: estudiantes-bounces

Bug#984490: test-archive.t fails in the autopkg tests

[Matthias Klose]

Package: src:mercurial
Version: 5.6.1-2
Severity: serious
Tags: sid bullseye

test-archive.t fails in the autopkg tests (all architectures), triggered by the
python3-defaults upload:

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/10823665/log.gz

--- /tmp/autopkgtest-lxc.75_lnl28/downtmp/build.6MQ/src/tests/test-archive.t
+++ /tmp/autopkgtest-lxc.75_lnl28/downtmp/build.6MQ/src/tests/test-archive.t.err
@@ -350,49 +350,59 @@
   > sys.stderr.write(str(e) + '\n')
   > EOF
   $ "$PYTHON" getarchive.py "$TIP" gz | gunzip | tar tf - 2>/dev/null
-  test-archive-1701ef1f1510/.hg_archival.txt
-  test-archive-1701ef1f1510/.hgsub
-  test-archive-1701ef1f1510/.hgsubstate
-  test-archive-1701ef1f1510/bar
-  test-archive-1701ef1f1510/baz/bletch
-  test-archive-1701ef1f1510/foo
-  test-archive-1701ef1f1510/subrepo/sub
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=gz
+
+  gzip: stdin: unexpected end of file
+  [2]
   $ "$PYTHON" getarchive.py "$TIP" bz2 | bunzip2 | tar tf - 2>/dev/null
-  test-archive-1701ef1f1510/.hg_archival.txt
-  test-archive-1701ef1f1510/.hgsub
-  test-archive-1701ef1f1510/.hgsubstate
-  test-archive-1701ef1f1510/bar
-  test-archive-1701ef1f1510/baz/bletch
-  test-archive-1701ef1f1510/foo
-  test-archive-1701ef1f1510/subrepo/sub
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=bz2
+
+  bunzip2: Compressed file ends unexpectedly;
+   perhaps it is corrupted?  *Possible* reason follows.
+  bunzip2: Inappropriate ioctl for device
+   Input file = (stdin), output file = (stdout)
+
+  It is possible that the compressed file(s) have become corrupted.
+  You can use the -tvv option to test integrity of such files.
+
+  You can use the `bzip2recover' program to attempt to recover
+  data from undamaged sections of corrupted files.
+
+  [2]
   $ "$PYTHON" getarchive.py "$TIP" zip > archive.zip
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=zip
   $ unzip -t archive.zip
   Archive:  archive.zip
-  testing: test-archive-1701ef1f1510/.hg_archival.txt*OK (glob)
-  testing: test-archive-1701ef1f1510/.hgsub*OK (glob)
-  testing: test-archive-1701ef1f1510/.hgsubstate*OK (glob)
-  testing: test-archive-1701ef1f1510/bar*OK (glob)
-  testing: test-archive-1701ef1f1510/baz/bletch*OK (glob)
-  testing: test-archive-1701ef1f1510/foo*OK (glob)
-  testing: test-archive-1701ef1f1510/subrepo/sub*OK (glob)
-  No errors detected in compressed data of archive.zip.
+End-of-central-directory signature not found.  Either this file is not
+a zipfile, or it constitutes one disk of a multi-part archive.  In the
+latter case the central directory and zipfile comment will be found on
+the last disk(s) of this archive.
+  unzip:  cannot find zipfile directory in one of archive.zip or
+  archive.zip.zip, and cannot find archive.zip.ZIP, period.
+  [9]

 test that we can download single directories and files

   $ "$PYTHON" getarchive.py "$TIP" gz baz | gunzip | tar tf - 2>/dev/null
-  test-archive-1701ef1f1510/baz/bletch
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=gz;file=baz
+
+  gzip: stdin: unexpected end of file
+  [2]
   $ "$PYTHON" getarchive.py "$TIP" gz foo | gunzip | tar tf - 2>/dev/null
-  test-archive-1701ef1f1510/foo
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=gz;file=foo
+
+  gzip: stdin: unexpected end of file
+  [2]

 test that we detect file patterns that match no files

   $ "$PYTHON" getarchive.py "$TIP" gz foobar
-  HTTP Error 404: file(s) not found: foobar
+  HTTP Error 400: no such method: archive;node=1701ef1f1510;type=gz;file=foobar

 test that we reject unsafe patterns

   $ "$PYTHON" getarchive.py "$TIP" gz relre:baz
-  HTTP Error 404: file(s) not found: relre:baz
+  HTTP Error 400: no such method: 
archive;node=1701ef1f1510;type=gz;file=relre:baz

   $ killdaemons.py


ERROR: test-archive.t output changed
!# Ret was: 0 (test-archive.t)

Bug#984489: firmware-brcm80211: newer versions fail to load on raspberry pi 4b with "brcmf_sdio_htclk: HT Avail timeout"

[maximilian attems]

Dear Andres,

> 
> [   12.471809] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> clkctl 0x50
> 
> 
> You can specifically see that the driver times out after one second
> with that error message, then times out again with the error and gives
> up. No wlan0 is available.
> 
> There are some pretty major firmware updates between those two
> versions, and they are generally Good. However, there's also some minor
> updates to the raspi4 board file
> /lib//firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
> 
> If we revert the line "boardflags3=0x48200100" in that file back to
> what was in the 20201218-3 version (so it would instead be
> "boardflags3=0x44200100"), and then reboot, the driver now loads:

upstream indeed resets this line too,
boardflags3=0x44200100
seen in 58825f74eb0156822065c449a770644a69044d88 of linux-firmware.git.
 
 
> [   23.961230] br0: port 3(wlan1) entered blocking state
> [   23.963358] br0: port 3(wlan1) entered disabled state
> [   23.966488] device wlan1 entered promiscuous mode
> [   29.417766] br0: port 2(wlan0) entered blocking state
> [   29.419853] br0: port 2(wlan0) entered forwarding state
> 
> 
> 
> I'm not sure if the driver needs fixing, or if the boardflags need
> fixing, but the boardflags thing seems to be a functional workaround
> for users hitting this issue. Thanks to Steev Klimaszewski for helping
> me figure out the workaround.

I will upload -4 with that fix as soon as -3 finaly hits testing
to push that minor change to upcoming release.


Thank you for your report!

-- 
maks

Bug#983997: bochs: ftbfs with GCC-11

[Matthias Klose]

On 3/3/21 5:29 PM, Stephen Kitt wrote:
> Hi Matthias,
> 
> Your test didn’t actually test whether bochs builds with GCC-11, in this case:
> 
> The following packages have unmet dependencies:
>  gcc-i686-linux-gnu : Depends: cpp-i686-linux-gnu (= 4:11-20210116-1) but it 
> is
> not going to be installed
>   Depends: gcc-11-i686-linux-gnu (>= 11-20210116-0~) but 
> it
> is not installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.
> E: Package installation failed

my bad, I didn't provide the cross compilers for the test rebuild. Does it build
in experimental with gcc-11?

Bug#984489: firmware-brcm80211: newer versions fail to load on raspberry pi 4b with "brcmf_sdio_htclk: HT Avail timeout"

[Andres Salomon]

Package: firmware-brcm80211
Version: 20210208-3
Severity: important

The version of firmware-brcm80211 in bullseye (specifically 20201218-3)
works fine on my Rasperry Pi 4 board. However, the version in sid does
not. Specifically, the brcmfmac kernel driver fails to load with some
clock errors. Here's snippets from boot dmesg:

[0.00] Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06)
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1

[...]

[   10.308867] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   10.318818] usbcore: registered new interface driver brcmfmac
[   10.322875] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   10.335422] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
[   10.343356] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[   10.350443] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.358185] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.365828] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.373704] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.376815] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.bin
[   10.384437] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[   10.398479] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

[...]

[   11.462064] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 
0x50

[...]

[   12.471809] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50


You can specifically see that the driver times out after one second
with that error message, then times out again with the error and gives
up. No wlan0 is available.

There are some pretty major firmware updates between those two
versions, and they are generally Good. However, there's also some minor
updates to the raspi4 board file
/lib//firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

If we revert the line "boardflags3=0x48200100" in that file back to
what was in the 20201218-3 version (so it would instead be
"boardflags3=0x44200100"), and then reboot, the driver now loads:


[   13.342844] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   13.353195] usbcore: registered new interface driver brcmfmac
[   13.465495] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.bin
[   13.472403] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   13.488397] hub 1-1:1.0: 4 ports detected
[   13.488428] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   13.500413] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
[   13.673868] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   13.812345] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd
[   13.856502] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.clm_blob
[   13.869572] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 
2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b
[...]
[   23.951744] br0: port 2(wlan0) entered blocking state
[   23.953859] br0: port 2(wlan0) entered disabled state
[   23.956221] device wlan0 entered promiscuous mode
[   23.961230] br0: port 3(wlan1) entered blocking state
[   23.963358] br0: port 3(wlan1) entered disabled state
[   23.966488] device wlan1 entered promiscuous mode
[   29.417766] br0: port 2(wlan0) entered blocking state
[   29.419853] br0: port 2(wlan0) entered forwarding state



I'm not sure if the driver needs fixing, or if the boardflags need
fixing, but the boardflags thing seems to be a functional workaround
for users hitting this issue. Thanks to Steev Klimaszewski for helping
me figure out the workaround.

Bug#984488: grub-install: error: embedding is not possible w/ grub-pc_2.02-deb10u4

[Gerd Aschemann]

Package: grub-pc
Version: 2.02+dfsg1-20+deb10u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

 (Automatic) update to grub-pc_2.02-deb10u4

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 apt update && apt dist-upgrade

   * What was the outcome of this action?

 grub-install: error: embedding is not possible, but this is required for 
RAID and LVM install.

   * What outcome did you expect instead?

 Smoothless installation of Grub

Falling back to 2.02+dfsg1-20+deb10u3 solved the problem.
Note: The error might be a problem of one of the other grub packages 
(grub-pc-bin, grub-common, ...)


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/ga20141221-wheezy / ext4 rw,relatime,errors=remount-ro 0 0
/dev/md127 /boot ext4 rw,relatime,stripe=4 0 0
/dev/mapper/ga20141221-isos /isos ext4 rw,relatime 0 0
/dev/mapper/ga20141221-lvarchive /archive ext4 rw,relatime 0 0
/dev/mapper/ga20141221-lvpublic /public ext4 rw,relatime 0 0
/dev/mapper/ga20140303-lvbackup /backup ext4 rw,relatime 0 0
/dev/mapper/ga20141221-wheezy /var/lib/docker/aufs ext4 
rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/lvm-pv-uuid-gEVjjc-kbQE-SqvN-SzUk-bodU-0Tpc-nMC7Ry
(hd1)   /dev/disk/by-id/lvm-pv-uuid-dgfBl3-uXZv-C4ZB-3SzU-covO-TLfr-NDVCVR
(hd2)   /dev/disk/by-id/ata-HGST_HTS541010A9E680_JA10001029G5WR
(hd3)   /dev/disk/by-id/ata-HGST_HTS541010A9E680_JA10001029GANR
(hd4)   /dev/disk/by-id/ata-WDC_WD30EZRX-00D8PB0_WD-WMC4N1908988
(hd5)   /dev/disk/by-id/ata-WDC_WD30EZRX-00D8PB0_WD-WMC4N1865131
(hd6)   /dev/disk/by-id/ata-ST9500325AS_6VE0F0X6
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod lvm
insmod ext2
set 
root='lvmid/z8arYE-CVx2-Obzw-75fA-o6jm-9l8c-eKgpQP/SxcJSl-tCPq-iLJw-s2qR-OsQ2-T83e-DqhUlo'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/z8arYE-CVx2-Obzw-75fA-o6jm-9l8c-eKgpQP/SxcJSl-tCPq-iLJw-s2qR-OsQ2-T83e-DqhUlo'
  95d18c99-d334-47ed-a4e9-fa9f77928351
else
  search --no-floppy --fs-uuid --set=root 95d18c99-d334-47ed-a4e9-fa9f77928351
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-95d18c99-d334-47ed-a4e9-fa9f77928351' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/84c9d30fadd349dcc5ddbb41b045ce54'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='mduuid/84c9d30fadd349dcc5ddbb41b045ce54'  
7f76fbd3-e2fc-4110-b4fa-d1f33668a8a6
else
  search --no-floppy --fs-uuid --set=root 
7f76fbd3-e2fc-4110-b4fa-d1f33668a8a6
fi

Bug#981515: kcoreaddons: please replace fam with gamin

[Glenn Strauss]

On Wed, Mar 03, 2021 at 02:54:58PM -0500, Nicholas D Steeves wrote:
> I don't think the removal of FAM is as clear-cut as it has been
> presented to be.
> 
> AFAIK the following is still current: Gamin provides "No NFS support
> based on specific RPC and server, instead gamin monitors only the state
> as reported locally by the kernel, not that locally done changes on NFS
> or AFS filesystems are reported on Linux which is the main criteria when
> having user home directories on such filesystems."
> 
>   https://people.gnome.org/~veillard/gamin/differences.html
> 
> thus FAM covers a use case that gamin does not, and this case is: users
> who want to receive inotify style events for files that have been
> remotely created or modified on NFS mounts.
> 
> I can't speak to how widespread the need for this feature is, but if it
> is non-zero then it seems to me that FAM should not be removed this late
> in the Bullseye cycle.

FAM attempts to get notifications for NFS by requiring that a remote FAM
server is running on the NFS server.  No encryption is used.  I hope
this is not widely used.  FAM code was last modified circa 2003 in the
tar ball I downloaded from debian and predates inotify().

However, using FAM or gamin in kcoreaddons is not necessary.

Quoting from kcoreaddons src/lib/io/kdirwatch.h:
https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.h#L44
  * The implementation uses the INOTIFY functionality on LINUX.
  * Otherwise the FAM service is used, when available.
  * As a last resort, a regular polling for change of modification times
  * is done; the polling interval is a global config option:
  * DirWatch/PollInterval and DirWatch/NFSPollInterval for NFS mounted
  * directories.

Please consider removing kcoreaddons dependency on FAM and on gamin in
the Debian package.  kcoreaddons has its own fallbacks.  Also,
kcoreaddons is not using FAM or gamin on Linux.

> FreeBSD doesn't have inotify, so there is a need for FAM, and maybe
> someone from their community has become the defacto upstream (via their
> "ports" packaging system)?  Or maybe someone from their community would
> be willing to officially become FAM's new upstream?

FYI: *BSD has kqueue() with EVFILT_VNODE.

Please consider removing FAM and gamin from the Debian package for
kcoreaddons by removing libfam-dev and libgamin-dev from debian/control,
or at least changing it to libgamin-dev.

https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3

Cheers, Glenn

Bug#983398: ZFS 2.0 update - buster

[M. Zhou]

Control: close -1

Hi Daniel and Mathias,

Thanks for the confirmation. Neither did I manage to reproduce
the issue in virtualbox according to that guide.

On Wed, 2021-03-03 at 19:45 +0100, Daniel Garcia Sanchez wrote:
> Hi Mathias,
> 
> Thanks a lot!
> 
> I tried an older version, 2.0.2. Maybe it didn't work for me because
> I
> used an old version or something else related to my system.
> 
> Mo, could you close this bug? The update 0.8.6 -> 2.0.3 is working
> properly.
> 
> Best,
> Daniel
> 
> On Wed, Mar 3, 2021 at 2:52 PM Mathias Gibbens 
> wrote:
> > 
> >   As another data point, I've successfully upgraded four buster
> > installs from 0.8.6 -> 2.0.3 as packaged from the buster-backports
> > repo. My setups are similar to Daniel's (ZFS as root filesystem,
> > following the same install guide); one instance uses native ZFS
> > encryption while the other three don't. All four also use ZFS for
> > the
> > /boot/ partition. One install is on physical hardware with legacy
> > BIOS,
> > and the other three are virtual machines.
> > 
> > Mathias

Bug#926501: xpdf: continuousView memory leak

[Florian Schlichting]

Hi Kevin, Martin and Greg,

On Wed, Mar 03, 2021 at 10:06:37PM +, Adam Sampson wrote:
> On Sat, 06 Apr 2019 18:30:26 +1100 Kevin Ryde  
> wrote:
> > With continuousView enabled [...]
> > Viewing a medium to large document such as
> > xpdf /usr/share/doc/bash-doc/bash.pdf
> > and paging through it with space or page-down, results in the xpdf
> > process using apparently ever growing memory, as shown by top or
> > memstat.
> 
> I've just tested this with the latest xpopple and it seems fine, so I
> think it was caused by one (or more) of the leaks that were fixed in the
> most recent (xpopple-based) Debian xpdf package.

can you please test this issue with xpdf 3.04+git20210103-1 or newer and
confirm that your memory problem has indeed been solved?

thanks,
Florian

Bug#984487: nmu: libzstd1 rdeps relying on 1.3.8

[Stephen Kitt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Dear release team,

libzstd1 used to provide an over-enthusiastic symbols file, which has
resulted in dependencies which are too relaxed. The library API isn’t
determined by its exported symbols, unfortunately, but by one of its
headers. See https://bugs.debian.org/969597 and
https://github.com/facebook/zstd/pull/2501 for details.

As a result, a (small) number of packages have picked up a dependency
on “libzstd1 (>= 1.3.8)” when it should be “(>= 1.4.0)” — they were
built with one of the 1.4 packages, but the symbols file declared some
of the 1.4 functions as available in 1.3.8 (which they were,
technically, but with a different API in some cases).

To fix this, would it be possible to binNMU the following? The version
of libzstd1 no longer provides a symbols file and relies on shlibs to
provide the correct dependency.

nmu badger_2.2007.2-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu burrow_1.2.1-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu cadvisor_0.38.7+ds1-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu garagemq_0.0~git20200204.15e6a9d+ds-3 . ANY . unstable . -m "update 
libzstd1 dependency"
nmu lammps_20210122~gita77bb+ds1-2 . ANY . unstable . -m "update libzstd1 
dependency"
nmu libarchive_3.4.3-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu libdrpm_0.5.0-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu mmllib_12-113e3+ds-3 . ANY . unstable . -m "update libzstd1 dependency"
nmu mysql-8.0_8.0.23-3 . ANY . unstable . -m "update libzstd1 dependency"
nmu rsymphony_3.2.3-4 . ANY . unstable . -m "update libzstd1 dependency"

Regards,

Stephen


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Bug#983379: linux uml segfault

[Hajime Tazaki]

On Thu, 04 Mar 2021 07:40:00 +0900,
Johannes Berg wrote:
> 
> I think the problem is here:
> 
> > #24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
> > at ipc/util.c:119
> > #25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
> > ipc/sem.c:254
> > #26 0x60015b5d in sem_init () at ipc/sem.c:268
> > #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
> > gnu/libcom_err.so.2
> 
> You're in the init of libcom_err.so.2, which is loaded by
> 
> > "libnss_nis.so.2"
> 
> which is loaded by normal NSS code (getgrnam):
> 
> > #40 0x7f89909bf3a6 in nss_load_library (ni=ni@entry=0x61497db0) at
> > nsswitch.c:359
> > #41 0x7f89909bfc39 in __GI___nss_lookup_function (ni=0x61497db0,
> > fct_name=, fct_name@entry=0x7f899089b020 "setgrent") at
> > nsswitch.c:467
> > #42 0x7f899089554b in init_nss_interface () at nss_compat/compat-
> > grp.c:83
> > #43 init_nss_interface () at nss_compat/compat-grp.c:79
> > #44 0x7f8990895e35 in _nss_compat_getgrnam_r (name=0x7f8990a2a1e0
> > "tty", grp=0x7ffe3e7a2910, buffer=0x7ffe3e7a24e0 "", buflen=1024,
> > errnop=0x7f899089eb00) at nss_compat/compat-grp.c:486
> > #45 0x7f8990968b85 in __getgrnam_r (name=name@entry=0x7f8990a2a1e0
> > "tty", resbuf=resbuf@entry=0x7ffe3e7a2910,
> > buffer=buffer@entry=0x7ffe3e7a24e0 "", buflen=1024,
> > result=result@entry=0x7ffe3e7a2908)
> > at ../nss/getXXbyYY_r.c:315
> 
> 
> You have a strange nsswitch configuration that causes all of this
> (libnss_nis.so.2 -> libcom_err.so.2) to get loaded.
> 
> Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
> ... Linux's sem_init() instead of libpthread's.
> 
> And then the crash.
> 
> Now, I don't know how to fix it (short of changing your nsswitch
> configuration) - maybe we could somehow rename sem_init()? Or maybe we
> can somehow give the kernel binary a lower symbol resolution than the
> libc/libpthread.

objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file).  It also does renaming symbols.  But
not sure this is the ideal solution.

How does UML handle symbol conflicts between userspace code and Linux
kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
Linux kernel (genlmsg_put) and others can possibly do as well.


-- Hajime

Bug#984486: libsmbclient-dev: ffmpeg 4.3.2 FTBFS against libsmbclient.h

[Vasyl Gello]

Source: libsmbclient-dev
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: important
Tags: ftbfs patch
Justification: fails to build from source
X-Debbugs-Cc: sramac...@debian.org

Dear colleagues,

I encountered an old SMB client header bug trying to backport ffmpeg 4.3.2 to 
buster.
The build logs are identical to https://bugs.gentoo.org/666548 and the patch 
applied
from there (attached to this message) does resolve the build failure on 
buster-bpo for
amd64 and i386.

Is it possible to incorporate this low-risk fix to stable-updates / 
stable-security?

Regards,
Vasyl

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

Kernel: Linux 5.4.0-66-generic (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
>From 11e8c14b78e2423041f3846882f74cd6490a3e44 Mon Sep 17 00:00:00 2001
From: Joan Karadimov 
Date: Thu, 18 Oct 2018 18:16:17 +0300
Subject: [PATCH] Fix compatibility issues with the timespec struct

---
 source3/include/libsmbclient.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source3/include/libsmbclient.h b/source3/include/libsmbclient.h
index 5e4a1715402..6487ea7a8aa 100644
--- a/source3/include/libsmbclient.h
+++ b/source3/include/libsmbclient.h
@@ -78,6 +78,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 #include 
 
   /* Debian bug #221618 */

Bug#984457: 特殊符號第二頁有重複字

[Changwoo Ryu]

Control: reassign -1 libchewing3-data 0.5.1-4

The dictionary is provided by libchewing

Bug#170850: contract dispute

[GISELL SANCHEZ PINZON]

Hello Attorney,



   I was referred to you by the Bar Referral Services. Do advise if your firm 
handles Litigation Cases.





Regards.

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Osamu Aoki]

Hi,

Let me recall my memory 

On Tue, 2021-03-02 at 13:02 +0800, Shengjing Zhu wrote:
> > On 2021-03-01 15:25, Shengjing Zhu wrote:
> > > I'm not a GNOME user. But reading this, I feel it's seriously
> > > broken.
> > > GNOME shouldn't take over the responsibility of tasksel to decide
> > > what the IM engine to use.
> > > Japanese GNOME desktop users should continue to use uim if it's
> > > prefered by Japanese users.
> > > And Chinese GNOME desktop users should continue to use fcitx as
> > > their default IM engine.
> > 
> > The GNOME (upstream) choice in this respect is unfortunate. A
> > flexible
> > design with support for multiple IM frameworks had of course been
> > preferable. But they made their strategic decision several years
> > ago,
> > and we won't likely make them change their mind.

We don't need to ask GNOME (upstream) to change mind to fix this
situation.  This problem of GNOME hardcoding ibus is an old problem
happened during buster cycle when wayland support was added.


If I remember correctly, the initial upstream code unconditionally
overridden user settings.  That was fixed but still tightly tied to
ibus.  The eventual upstream allowed us to set up a mechanism for im-
config to set IM.  That was buster cycle.  As I posted previously, this
is a very fragile solution.

Since this worked OK, fcitx dropped its own intrusive mechanism (Ubuntu
origin?) to force using fcitx irrespective of im-config settings.  So
current fcitx relyes on im-config hooks originally created by Yoshino-
san and recently updated by Gunnar.  We knew this hook approach was
fragile but no one created better solution during the last moment of
buster freeze.  So we added this hook as the last resort.

What we need now is not the intrusive old fcitx approach but still a
clean patch to GNOME to make default IM setting code configurable via
Gsetting etc without hook scripts. if uim or fcitx wants to be made
usable robustly.  Then im-config can access it to set environment
variable and daemon cleanly.  I think I mentioned offending code point
in previous related bug report.  If fcitx or uim fans wishes to meke
GNOME to be friendly, they need to come up with non-intrusive mechanism
for GNOME and update im-config to use it.  Patch doesn't need to be
accepted by the GNOME upstream.  As long as it is carefully and non-
intrusively organized by the interested party, Debian GNOME maintainer
can accept such feature.

I am a happy ibus user and this is a non-trivial task.  So I am not the
person to work on this.

> > Given the circumstances it's not obvious to me that Debian should
> > keep
> > defaulting to non-IBus IM frameworks on GNOME. A user who wants to
> > use
> > e.g. a Fcitx IM basically have the choice to
> > 
> > 1. actively select Fcitx on a GNOME desktop, and with that give 
> > up some features which GNOME only offers together with IBus, or
> > 
> > 2. switch to some other desktop environment.
> > 
> > GNOME favors IBus, and Debian should relate to that IMO.
> 
> It's totally fine that GNOME only works with IBus. And there's no
> blame for upstream for their choice.

I say:

It's totally fine that GNOME as upstream only works with IBus. And
there's no blame for upstream for their choice.

It's not fine that GNOME as released by Debin only works with IBus if
fcitx or uim to be viable options on Debian.  If fcitx or uim fans wish
to make fcitx and uim viable options, they need to work on it.

> But in Debian, it's a system, not just GNOME. When GNOME packager
> changes its packaging relations, they should also work with other
> teams, like tasksel, im-config, to provide users a working system.

Debian is a collection of efforts.  It's a consolidation platform. 
Each component and each contributor need to contribute.

Osamu

Bug#983345: therion: FTBFS with PROJ 8.0.0

[Wookey]

On 2021-02-24 11:29 +0100, Sebastiaan Couwenberg wrote:
> On 2/24/21 10:59 AM, Sebastiaan Couwenberg wrote:
> > On 2/23/21 7:25 PM, Sebastiaan Couwenberg wrote:
> >> On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote:
> >>> On 2/22/21 11:42 PM, Wookey wrote:
> > 
> > This change helps to not pass an empty string to faketime:
> > 
> > The build still hangs on the sed call to get the PROJ major version, though.
> 
> If awk is used instead of sed like so:
> 
> There is some progress, but then the build hangs with 100% CPU on:
> 
>  mkdir -p ./extern/poly2tri/sweep/
> 
> It's proving hard to fix the arch-indep target.

Thanks for doing all that work Bas. I'll put your fixes in and try to
get to the bottom of this.

The package has been reworked to use cmake from the next release which
will get rid of the homegrown pile of perl, tcl, make and seddery this
20-year old bit of software uses. So a lot of this stuff (like using
sed/awk to get the libproj version) may well change. So I'll probably
wait for that before putting in a lot of time on build-system issues.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#984485: admin.c: remove a duplicate declaration of the array "group_path_name[]"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 971dc8c6aeeaaf94205e7e68f339ff928421 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 4 Mar 2021 03:31:02 +
>Subject: [PATCH] admin.c: remove a duplicate declaration of the array
> "group_path_name[]"

Signed-off-by: Bjarni Ingi Gislason 
---
 admin.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/admin.c b/admin.c
index 421aee1..2be9b72 100644
--- a/admin.c
+++ b/admin.c
@@ -44,9 +44,11 @@ static void group_admin(register group_header * gh);
 static void show_config(void);
 
 
+/* group_path_name[] is declared in "global.h" */
+
 extern char
*master_directory, *db_directory, *db_data_directory, 
*bin_directory, *news_directory,
-   *news_lib_directory, *log_file, *news_active, *pager, 
group_path_name[];
+   *news_lib_directory, *log_file, *news_active, *pager;
 
 extern char*exec_chdir_to;
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984426: (no subject)

[Boyan Penkov]

Hello folks -- +1 here, same problem, same solution.

--
Boyan Penkov
www.boyanpenkov.com

Bug#984484: nn.c: remove a duplicate of "seq_cross_filtering"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 2df591af239b7a53c53d59dcbe9588ce1eb6a600 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 4 Mar 2021 03:10:04 +
>Subject: [PATCH] nn.c: remove a duplicate of "seq_cross_filtering"

nn.c
  Remove a duplicate of "seq_cross_filtering"

  Correct a typo, from dublicate
  to   duplicate

Signed-off-by: Bjarni Ingi Gislason 
---
 nn.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/nn.c b/nn.c
index 7bc2779..8576046 100644
--- a/nn.c
+++ b/nn.c
@@ -77,13 +77,12 @@ int init_on_entry = 0; /* in init.c.  Repeat after 
open_master if true */
 
 extern char proto_host[];
 extern int  newsrc_update_freq, novice;
-/* extern int  seq_cross_filtering; */ /* dublicate */
-extern int  seq_cross_filtering;
+/* extern int  seq_cross_filtering; */ /* duplicate */
 extern char*news_active;
 extern long unread_articles;
 extern long initial_memory_break;
 extern int  first_time_user;
-/* extern int  also_cross_postings; */ /* dublicate */
+/* extern int  also_cross_postings; */ /* duplicate */
 
 static int
 group_name_args = 0, nngrab_mode = 0, prompt_for_group = 0;
-- 
2.30.1


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984483: ITP: pyfltk -- Python bindings for FLTK

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: pyfltk
  Version : 1.3.5
  Upstream Author : Andreas Held, Clemmitt Sigler, Robert Arkiletian
* URL or Web page : https://pyfltk.sourceforge.io/
* License : LGPL-2
  Description : Python bindings for FLTK

This was removed from Debian earlier, but I need it, and I'd like to
bring it back.

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

Unclear what the core problem was other than inactive maintainership.



Previous attempt to bring it back:

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

  https://lists.debian.org/debian-mentors/2019/02/msg00036.html

Robert: are you still interested in doing this? If so, we can
collaborate, and I can sponsor. Otherwise, I'll just do this myself.

Bug#984482: nn.c: silence warnings about a possible fall through

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From b400f526f90b73bf6eb0127f528a9c806e5d854e Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 4 Mar 2021 02:44:37 +
>Subject: [PATCH] nn.c: silence warnings about a possible fall through

  Add __attribute__ ((fallthrough));

  Add "break" after an "nn_exit()" as the compiler can't know,
that the next code is never reached.

Signed-off-by: Bjarni Ingi Gislason 
---
 nn.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/nn.c b/nn.c
index 7c77057..7bc2779 100644
--- a/nn.c
+++ b/nn.c
@@ -303,6 +303,7 @@ read_news(flag_type access_mode, char *mask)
break;
case 0:
gh = group_sequence;
+   __attribute__ ((fallthrough));
default:
after_loop = prev;
continue;
@@ -1107,6 +1108,7 @@ nnspew:
prt_unread((char *) NULL);
}
nn_exit(unread_articles ? 0 : 99);
+   break; /* added to silence warning about possible fall through */
/* NOTREACHED */
 
case I_AM_TIDY:
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984481: chroma: description says terminal version is in 'chroma', which is the graphical version

[Paul Wise]

Package: chroma
Version: 1.18-1
Severity: minor

The 'chroma' description says the terminal version is in 'chroma', but
'chroma' is graphical and the terminal version is 'chroma-curses'.

   $ apt-cache show chroma | grep -E 'Package|Description-en|terminal'
   Package: chroma
   Description-en: Abstract puzzle game - graphical version
A terminal-based version of this game is available in the 'chroma'

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages chroma depends on:
pn  chroma-data
ii  fonts-dejavu-core  2.37-2
ii  libc6  2.31-9
ii  libfreetype6   2.10.4+dfsg-1
ii  libsdl-image1.21.2.12-12
ii  libsdl1.2debian1.2.15+dfsg2-6

chroma recommends no packages.

chroma suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#984480: python3-yubikey-manager: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: python3-yubikey-manager
Version: 4.0.0~a1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  buster -> bullseye

>From the attached log (scroll to the bottom...):

0m36.3s ERROR: WARN: Inadequate results from running adequate!
  python3-yubikey-manager: missing-copyright-file 
/usr/share/doc/python3-yubikey-manager/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/python3-yubikey-manager/copyright
  # ls -lad /usr/share/doc/python3-yubikey-manager
  drwxr-xr-x 2 root root 40 Mar  3 01:47 /usr/share/doc/python3-yubikey-manager
  # ls -la /usr/share/doc/python3-yubikey-manager/
  total 0
  drwxr-xr-x   2 root root   40 Mar  3 01:47 .
  drwxr-xr-x 142 root root 2980 Mar  3 01:47 ..


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


python3-yubikey-manager_4.0.0~a1-2.log.gz
Description: application/gzip

Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs

[Ryutaroh Matsumoto]

Package: src:linux
Version: 5.10.19-1
Followup-For: Bug #977647
Control: retitle -1 5.10.19 Debian kernel has mysterious tpm error in dmesg
Control: severity -1 minor

Dear Maintainer,

The boot failure problem originally reported as #977647 somehow gets fixed
in Debian kernel 5.10.19.

The severity seems now minor.
It has still the mysterious dmesg error on tpm as follows.
The full dmesg log is attached.

[7.077378] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x0, rev-id 78)
[7.082612] [ cut here ]
[7.082741] proc_thermal :00:04.0: enabling device ( -> 0002)
[7.085668] TPM returned invalid status
[7.085692] WARNING: CPU: 10 PID: 372 at drivers/char/tpm/tpm_tis_core.c:249 
tpm_tis_status+0x86/0xa0 [tpm_tis_core]
[7.091064] intel_rapl_common: Found RAPL domain package
[7.093429] Panasonic Laptop Support: probe of MAT0019:00 failed with error 
-5
[7.093991] Modules linked in: processor_thermal_device(+) ucsi_acpi(+) 
tpm_tis(+) intel_rapl_common typec_ucsi kfifo_buf tpm_tis_core 
intel_soc_dts_iosf intel_pch_thermal typec rfkill pcc_cpufreq(-) industrialio 
int3403_thermal(+) tpm int340x_thermal_zone evdev rng_core int3406_thermal 
panasonic_laptop intel_hid sparse_keymap int3400_thermal intel_pmc_core 
acpi_pad acpi_thermal_rel ac msr fuse configfs efivarfs ip_tables x_tables 
autofs4 btrfs xor raid6_pq libcrc32c hid_rmi rmi_core sr_mod cdrom hid_generic 
i915 i2c_algo_bit drm_kms_helper ahci nvme cec libahci xhci_pci xhci_hcd 
sdhci_pci nvme_core e1000e cqhci
[7.096714] intel_rapl_common: Found RAPL domain dram
[7.099285]  libata i2c_i801 drm t10_pi sdhci thunderbolt ptp usbcore 
crc_t10dif crc32_pclmul scsi_mod mmc_core i2c_hid crc32c_intel intel_lpss_pci 
i2c_smbus pps_core crct10dif_generic hid intel_lpss crct10dif_pclmul 
crct10dif_common usb_common idma64 wmi battery button fan video
[7.115229] CPU: 10 PID: 372 Comm: systemd-udevd Not tainted 5.10.0-4-amd64 
#1 Debian 5.10.19-1
[7.115230] Hardware name: Panasonic Corporation CFSV9-2/CFSV9-2L, BIOS 
V2.00L12 04/20/2020
[7.115236] RIP: 0010:tpm_tis_status+0x86/0xa0 [tpm_tis_core]
[7.115239] Code: 00 75 30 48 83 c4 18 c3 31 c0 80 3d e3 48 00 00 00 75 e0 
48 c7 c7 4c 03 ce c0 88 44 24 07 c6 05 cf 48 00 00 01 e8 9a 77 59 ca <0f> 0b 0f 
b6 44 24 07 eb c0 e8 ac ef 5c ca 66 66 2e 0f 1f 84 00 00
[7.115240] RSP: 0018:b0900064f9b0 EFLAGS: 00010282
[7.115242] RAX:  RBX: 8b2d02a72000 RCX: 8b3064498a08
[7.115243] RDX: ffd8 RSI: 0027 RDI: 8b3064498a00
[7.115244] RBP: 8b2d02a72000 R08: 8c05b320 R09: 0001
[7.115245] R10: 8c05b348 R11: 0001 R12: 8b2d18408918
[7.115246] R13: 8b2d02de1000 R14:  R15: b0900064fa82
[7.115247] FS:  7ff671d628c0() GS:8b306448() 
knlGS:
[7.115248] CS:  0010 DS:  ES:  CR0: 80050033
[7.115249] CR2: 7fbf241f8260 CR3: 000102144005 CR4: 003706e0
[7.115250] Call Trace:
[7.115257]  tpm_tis_send_data+0x3f/0x250 [tpm_tis_core]
[7.115262]  ? irq_domain_hierarchical_is_msi_remap+0x20/0x20
[7.115265]  tpm_tis_send_main+0x2e/0xf0 [tpm_tis_core]
[7.115271]  tpm_transmit+0xd8/0x3d0 [tpm]
[7.115275]  tpm_transmit_cmd+0x25/0x90 [tpm]
[7.115282]  tpm2_get_tpm_pt+0xe8/0x150 [tpm]
[7.115286]  tpm_tis_probe_irq_single+0x179/0x1f4 [tpm_tis_core]
[7.115289]  tpm_tis_core_init.cold+0x243/0x526 [tpm_tis_core]
[7.115294]  tpm_tis_plat_probe+0xd8/0xf6 [tpm_tis]
[7.115300]  platform_drv_probe+0x35/0x80
[7.115303]  really_probe+0xf2/0x440
[7.115306]  driver_probe_device+0xe1/0x150
[7.115309]  device_driver_attach+0xa1/0xb0
[7.115311]  __driver_attach+0x8a/0x150
[7.115314]  ? device_driver_attach+0xb0/0xb0
[7.115316]  ? device_driver_attach+0xb0/0xb0
[7.115318]  bus_for_each_dev+0x78/0xc0
[7.115321]  bus_add_driver+0x12b/0x1e0
[7.115323]  driver_register+0x8b/0xe0
[7.115325]  ? 0xc0d04000
[7.115330]  init_tis+0x8d/0x1000 [tpm_tis]
[7.198814]  do_one_initcall+0x44/0x1d0
[7.198818]  ? do_init_module+0x23/0x260
[7.198820]  ? kmem_cache_alloc_trace+0xf5/0x200
[7.198822]  do_init_module+0x5c/0x260
[7.198824]  __do_sys_finit_module+0xb1/0x110
[7.198827]  do_syscall_64+0x33/0x80
[7.198830]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[7.198832] RIP: 0033:0x7ff67221b9b9
[7.198834] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48
[7.198835] RSP: 002b:7ffe3ba628b8 EFLAGS: 0246 ORIG_RAX: 
0139
[7.198836] RAX: ffda RBX: 55ee81379020 RCX: 7ff67221b9b9
[7.198837] RDX:  RSI: 7ff6723a6e2d RDI: 0011
[7.198838] RBP: 

Bug#984479: fai-nfsroot: fails to upgrade from 'buster': diversion clash

[Andreas Beckmann]

Package: fai-nfsroot
Version: 5.9.4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../28-fai-nfsroot_5.9.4_all.deb ...
  dpkg-divert: error: 'diversion of /etc/init.d/rcS to /etc/init.d/rcS.orig by 
fai-nfsroot' clashes with 'diversion of /etc/init.d/rcS to 
/etc/init.d/rcS.distrib by fai-nfsroot'
  dpkg: error processing archive 
/tmp/apt-dpkg-install-1rWE0W/28-fai-nfsroot_5.9.4_all.deb (--unpack):
   new fai-nfsroot package pre-installation script subprocess returned error 
exit status 2
  Preparing to unpack .../29-libss2_1.46.1-1_amd64.deb ...
  Unpacking libss2:amd64 (1.46.1-1) over (1.44.5-1+deb10u3) ...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-1rWE0W/28-fai-nfsroot_5.9.4_all.deb

You need to manually migrate the existing diversion to the new name.


cheers,

Andreas


fai-nfsroot_5.9.4.log.gz
Description: application/gzip

Bug#984478: nmu: jgmenu_4.3.0-1

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: by...@debian.org
Severity: normal

Package jgmenu needs a binNMU to have the amd64 binary packages rebuilt
on buildd after passing the NEW queue.


nmu jgmenu_4.3.0-1 . amd64 . unstable . -m "Rebuild on buildd"


-- 
Thanks,
Boyuan Yang



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

Bug#984477: libbio-variation-perl: missing Breaks+Replaces: bioperl (<< 1.7.3)

[Andreas Beckmann]

Package: libbio-variation-perl
Version: 1.7.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libbio-variation-perl.
  Preparing to unpack .../048-libbio-variation-perl_1.7.5-1_all.deb ...
  Unpacking libbio-variation-perl (1.7.5-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-eyjeT8/048-libbio-variation-perl_1.7.5-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/bp_flanks', which is also in package bioperl 
1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

IIRC bioperl 1.7.3 is the version that got split up into several packages,
therefore the existing
  Breaks+Replaces: libbio-perl-perl (<= 1.7.2)
are also insufficiently versioned (should be (<< 1.7.3) as well).

cheers,

Andreas


bioperl-run_1.7.3-6.log.gz
Description: application/gzip

Bug#984476: nn_term.h: make "prompt_line" again to an external variable

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From dd7750dd553e3bf455b43c9099363e35edc27a39 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 4 Mar 2021 01:20:14 +
>Subject: [PATCH] nn_term.h: make "prompt_line" again to an external variable

  nn_term.h: make "prompt_line" again to an external variable.

Signed-off-by: Bjarni Ingi Gislason 
---
 nn_term.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/nn_term.h b/nn_term.h
index 92d7b3e..acfec32 100644
--- a/nn_term.h
+++ b/nn_term.h
@@ -48,7 +48,8 @@ extern int  STANDOUT;
  */
 
 
-/* extern int prompt_line; */  /* prompt line */
+/* storage in "term.c", used in "nn.c" and other files */
+extern int prompt_line;
 
 #defineP_MOVE  (char *)1
 #define P_REDRAW   (char *)5
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984475: libbio-db-ncbihelper-perl: missing Breaks+Replaces: bioperl (<< 1.7.3)

[Andreas Beckmann]

Package: libbio-db-ncbihelper-perl
Version: 1.7.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + bioperl-run

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libbio-db-ncbihelper-perl.
  Preparing to unpack .../045-libbio-db-ncbihelper-perl_1.7.6-2_all.deb ...
  Unpacking libbio-db-ncbihelper-perl (1.7.6-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-eyjeT8/045-libbio-db-ncbihelper-perl_1.7.6-2_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/bp_biofetch_genbank_proxy', which is also in 
package bioperl 1.7.2-3

IIRC bioperl 1.7.3 is the version that got split up into several packages.


cheers,

Andreas


bioperl-run_1.7.3-6.log.gz
Description: application/gzip

Bug#984473: Fix

[Bryce Harrington]

The ubuntu bug report this issue pertains to is:

https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1690432

The branch with the fix we're deploying for Ubuntu is:


https://code.launchpad.net/~bryce/ubuntu/+source/postgresql-common/+git/postgresql-common/+ref/fix-lp1690432-hirsute

A debdiff with these ubuntu changes is attached, for ease of
consideration.

Thank you,
Brycediff --git a/debian/changelog b/debian/changelog
index bce80a8..069345a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+postgresql-common (225ubuntu1) hirsute; urgency=medium
+
+  * d/postinst: Only add postgres to group ssl-cert if it isn't
+already a member of that group.
+(LP: #1690432)
+
+ -- Bryce Harrington   Thu, 25 Feb 2021 16:21:44 -0800
+
 postgresql-common (225) unstable; urgency=medium
 
   * pg_lsclusters, cluster_info: Show cluster managed by pacemaker or patroni.
diff --git a/debian/control b/debian/control
index 9c4e88a..c70ce42 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
 Source: postgresql-common
 Section: database
 Priority: optional
-Maintainer: Debian PostgreSQL Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian PostgreSQL Maintainers 

 Uploaders:
  Martin Pitt ,
  Christoph Berg ,
diff --git a/debian/postgresql-common.postinst 
b/debian/postgresql-common.postinst
index a435b72..fc897ac 100644
--- a/debian/postgresql-common.postinst
+++ b/debian/postgresql-common.postinst
@@ -90,9 +90,12 @@ EOF
 fi
 
 # Add postgres user to the ssl-cert group on fresh installs
+# if not already in the group
 if [ -z "$2" ]; then
if getent group ssl-cert >/dev/null; then
-   adduser $quiet postgres ssl-cert
+   if ! id -Gn postgres 2> /dev/null | grep -qw ssl-cert; then
+   adduser $quiet postgres ssl-cert
+   fi
fi
 fi
 

Bug#984474: libbio-asn1-entrezgene-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Andreas Beckmann]

Package: libbio-asn1-entrezgene-perl
Version: 1.730-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libbio-asn1-entrezgene-perl.
  Preparing to unpack .../039-libbio-asn1-entrezgene-perl_1.730-1_all.deb ...
  Unpacking libbio-asn1-entrezgene-perl (1.730-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-eyjeT8/039-libbio-asn1-entrezgene-perl_1.730-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/man/man3/Bio::SeqIO::entrezgene.3pm.gz', 
which is also in package libbio-perl-perl 1.7.2-3

IIRC bioperl 1.7.3 is the version that got split up into several packages,
thus the existing B+R: libbio-perl-perl (<= 1.7.2) is insufficient.


cheers,

Andreas


bioperl-run_1.7.3-6.log.gz
Description: application/gzip

Bug#984473: postgresql-common: Only add postgres user to ssl-cert group if it's not already in the group

[Bryce Harrington]

Source: postgresql-common
Version: 225
Severity: normal

The postgres postinst script creates the postgres user with matching
group if, and only if, it doesn't already exist.  It also adds the user
to the ssl-cert but does this unconditionally, which is a bit
inconsistent.

This has cropped up in certain corner cases where the system config is
unwriteable for some odd reason (in one reported case, due to broken
oneconf; in a more immediate case we're hitting it building postgres
inside Docker, possibly due to a change in glibc/libseccomp behavior).

This change makes the postinst script more consistent in how it handles
setting up the postgres user's groups, and in so doing enables a
workaround for corner cases: the postgres user can be set up prior to
installing postgres; the postinst will then skip trying to make those
changes itself.


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

Kernel: Linux 5.4.0-65-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed

[Ryutaroh Matsumoto]

> rrs@lenovo:~$ autopkgtest -B -U -u debci -o /tmp/multipath-tools-qemu
> multipath-tools -- qemu -d --show-boot -c 1 --ram-size=3072
> /var/lib/debci/qemu/sid-amd64.img

This should work...
You could try the same command by root, but
it should work under an ordinary user.

> Booting from Hard Disk...
> autopkgtest-virt-qemu: DBG: cleanup...
> : failure: timed out waiting for "login prompt on ttyS0"
> autopkgtest [20:12:41]: ERROR: testbed failure: cannot send to testbed:
> [Errno 32] Broken pipe

Have you seen "Grub" or "Linux"?
If not, the installation of grub and/or linux-image-amd64 is broken
in the VM image /var/lib/debci/qemu/sid-amd64.img.
I wonder if /var/lib/debci/qemu/sid-amd64.img can be booted under virt-manager.

I also see a problem in grub-pc/sid.
Could you try

# debci setup -f -s bullseye -a amd64 -b qemu
Then
> rrs@lenovo:~$ autopkgtest -B -U -u debci -o /tmp/multipath-tools-qemu
> multipath-tools -- qemu -d --show-boot -c 1 --ram-size=3072
> /var/lib/debci/qemu/bullseye-amd64.img
(sid replaced by bullseye).

Best regards, Ryutaroh

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Ryutaroh Matsumoto]

> What should be the steps to reproduce this bug on my machine using
> debci/autopkgtest ?

(Assuming you are using Debian Bullseye amd64.)

# debci setup -f -b qemu -a amd64 -s sid
The above will create /var/lib/debci/qemu/sid-amd64.img
"debci setup" sometimes fails, in such a case please retry...

The above image has /sbin/init==systemd-sysv, of course.
As open-iscsi has no problem with /sbin/init==systemd-sysv,
We need to replace it with sysvinit-core in the VM image.

# apt-get --install-recommends install virt-manager
# cp /var/lib/debci/qemu/sid-amd64.img /var/lib/libvirt/images
# virt-manager (this can be run by an ordinary user belonging to libvirt group)

Start VM on /var/lib/libvirt/images/sid-amd64.img
Login as root (no password) into the Linux running on VM.
on-VM# apt-get install sysvinit-core
on-VM# echo "S0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100" >>/etc/inittab
on-VM# shutdown -h -P now

/var/lib/libvirt/images/sid-amd64.img should have /sbin/init==sysvinit-core now.

autopkgtest -B -u debci -o some-dir-for-logging open-iscsi -- qemu --debug 
--show-boot /var/lib/libvirt/images/sid-amd64.img
The test should get stuck at apt-get install open-iscsi...

Best regards, Ryutaroh

Bug#984471: inotify-hookable: Man page omits quiet flag

[James Vasile]

Package: inotify-hookable
Version: 0.09-1
Severity: normal
X-Debbugs-Cc: ja...@opentechstrategies.com

Dear Maintainer,

inotify-hookable has an option, '--quiet' that is missing from the man page.
The option appears when I run 'inotify-hookable --help', it has a section
devoted to it in the source file, and it works when I use at the command line.

I have been using this program for years, wishing it had this option and when I
finally sat down to add it, I discovered it was already there.  I am a fool,
but a happy fool.

Suggest adding to man page the same note as in the help text:

"-q" or "--[no-]quiet"
Don't log noisy information

Thank you.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inotify-hookable depends on:
ii  libclass-inspector-perl  1.36-1
ii  libdata-bitmask-perl 0.91-2.1
ii  liblinux-inotify2-perl   1:2.2-2+b1
ii  liblist-moreutils-perl   0.430-2
ii  libmoose-perl2.2014-2
ii  libmoosex-getopt-perl0.74-1
ii  libmoosex-types-perl 0.50-1
ii  libtry-tiny-perl 0.30-1
ii  perl 5.32.1-2

inotify-hookable recommends no packages.

inotify-hookable suggests no packages.

Bug#984470: nn_term.h: fix a warning from the compiler

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 647e71c0e726a4dc011c7df471d6032ddb5baa40 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 4 Mar 2021 00:04:12 +
>Subject: [PATCH] nn_term.h: fix a warning from the compiler

In file included from nn.c:39:
nn_term.h:93:47: error: unknown type name 'fct_type'
   93 | char   *get_s(char *, char *, char *, fct_type);
  |   ^~~~



  Use special function declaration "fct_type_char_int" instead of
"fct_type.

Signed-off-by: Bjarni Ingi Gislason 
---
 nn_term.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nn_term.h b/nn_term.h
index 778c9f0..92d7b3e 100644
--- a/nn_term.h
+++ b/nn_term.h
@@ -48,7 +48,7 @@ extern int  STANDOUT;
  */
 
 
-extern int prompt_line;/* prompt line */
+/* extern int prompt_line; */  /* prompt line */
 
 #defineP_MOVE  (char *)1
 #define P_REDRAW   (char *)5
@@ -90,7 +90,7 @@ int no_raw(void);
 int unset_raw(void);
 voidflush_input(void);
 int get_c(void);
-char   *get_s(char *, char *, char *, fct_type);
+char   *get_s(char *, char *, char *, fct_type_char_int);
 int list_completion(char *);
 int yes(int);
 voidding(void);
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983365: [PATCH] Re: Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Am 03.03.21 um 18:55 schrieb Dennis Filder:

Hi Dennis,

> On Sun, Feb 28, 2021 at 11:07:31PM +0100, Bernhard Schmidt wrote:
>> an updated liblinphone has been uploaded to sid yesterday. Could you
>> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
>> report back? If it does not work you might need libsoci-core4.0 and
>> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).
> 
> I finally found the bug: libsoci_sqlite3 sometimes returns string
> where liblinphone unconditionally expects int, long, double etc. which
> led to silent std::bad_cast exceptions.  I can't say who is actually
> to blame (I feel soci should do that conversion already as it knows
> what type the user requested, or at least not throw silently), but the
> attached patches remedy the issue through some conditional string
> conversion and make chat history actually work again in the GUI.  They
> should really have separated the sqlite3 database code better from the
> MySQL code.
> 
> I put this in two separate patches to make it easier to remove the
> changes to the code for the legacy DB migration in case it causes
> problems.

Cool, thanks. Would you mind discussing your findings with upstream at
https://gitlab.linphone.org/BC/public/liblinphone ? We will need a
freeze exception for this, having this bug confirmed by upstream would
help a lot, cherry-picking a commit from upstream would be even better.

Right now I don't plan to upload src:linphone before 4.4.21-2 has
migrated to testing, in order to have a minimum amount of changes to be
discussed for the freeze exception.

Bernhard

Bug#984469: guitarix: debian/copyright is inaccurate

[Francesco Poli (wintermute)]

Package: guitarix
Version: 0.42.1+dfsg1-1
Severity: serious
Tags: patch
Justification: Policy 12.5

Dear Debian Multimedia Maintainers,
I noticed that the [debian/copyright] file for guitarix states that
two images ('data/Layout.svg' and 'data/stereo.svg') are under
CC-BY-1.0, which does not meet the DFSG.

[debian/copyright]: 


I got in touch with the upstream developers, with the intention to
persuade them to re-license the two files under DFSG-free terms.
And I found out that those two files are already under GPL-2+,
as the majority of the guitarix package files.
See the [confirmation] from the Guitarix devs.

[confirmation]: 

This means that there is no DFSG-freeness issue in the guitarix package
(and that's wonderful news!): it's the debian/copyright file that appears
to be inaccurate.

Please find attached a patch that fixes the debian/copyright file
to better reflect the actual licensing status of the package.

Please apply the patch as soon as possible.
Thanks for your time.

Bye!


fix_guitarix_copyright.diff.xz
Description: application/xz

Bug#984468: Pre-approval for uploading KDE Apps 20.12.3

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Dear Release Team,

KDE Apps 20.12.3 will be released tomorrow and a preliminary
changelog is available at [1].
I’d like to get a pre-aproval for uploading the packages listed below as
they will not have migrated to testing before the hard freeze.

I’m listing the change log first then the code diffs, excluding
translation updates and version changes in xml metadata files.

Juk has a couple of trivial packaging changes pending and other packages
would be uploaded as is with just the new upstream version.

Feel free to ask for the changes in any other form if it makes the review
easier for you.

[1] https://phabricator.kde.org/P672


Thanks,
--
Aurélien


== change log ==


 elisa-player 
- fix sort by duration to not use string sort

 gwenview 
- Switch from QGLWidget to QOpenGLWidget
- Use Quality level when saving JPEG images

 juk 
- filerenamer: Prevent creating track name folders

 kdeconnect-kde 
- Don't escape notification title text

 konsole 
- Delete client builder before d-pointer of KXMLGUIClient is killed

=== kpmcore ===
- Fix out of bounds read when parsing fstab.
- Add initial support for dosfstools 4.2.

 krdc 
- Fix low quality connections
- VNC: accept the wheel event
- Unpress modifiers on focusOutEvent in VncView

 marble 
- Fix GeoNames web service URL, is now api.geonames.org (#432598)
- Provide BUILD_TOUCH option to force install of touch variant

 okular 
- presentation: Show better the status of the "playing" button
- pdf: Fix InPlace text annotations being loaded as linked

 palapeli 
- Make the cache work

 kde-spectacle 
- Fix compression quality range


===
== diffs ==
===

 elisa-player 
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 10078c21..17f34229 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,7 +7,7 @@ cmake_minimum_required(VERSION 3.8)
 # KDE Applications version, managed by release script.
 set(RELEASE_SERVICE_VERSION_MAJOR "20")
 set(RELEASE_SERVICE_VERSION_MINOR "12")
-set(RELEASE_SERVICE_VERSION_MICRO "2")
+set(RELEASE_SERVICE_VERSION_MICRO "3")
 set(RELEASE_SERVICE_VERSION 
"${RELEASE_SERVICE_VERSION_MAJOR}.${RELEASE_SERVICE_VERSION_MINOR}.${RELEASE_SERVICE_VERSION_MICRO}")
 
 project(elisa
diff --git a/src/models/datamodel.cpp b/src/models/datamodel.cpp
index 69d71397..7559c0e5 100644
--- a/src/models/datamodel.cpp
+++ b/src/models/datamodel.cpp
@@ -87,7 +87,7 @@ QHash DataModel::roleNames() const
 
 roles[static_cast(DataTypes::ColumnsRoles::AlbumRole)] = "album";
 roles[static_cast(DataTypes::ColumnsRoles::AlbumArtistRole)] = 
"albumArtist";
-roles[static_cast(DataTypes::ColumnsRoles::DurationRole)] = 
"duration";
+roles[static_cast(DataTypes::ColumnsRoles::StringDurationRole)] = 
"duration";
 roles[static_cast(DataTypes::ColumnsRoles::TrackNumberRole)] = 
"trackNumber";
 roles[static_cast(DataTypes::ColumnsRoles::DiscNumberRole)] = 
"discNumber";
 roles[static_cast(DataTypes::ColumnsRoles::RatingRole)] = "rating";
@@ -156,7 +156,7 @@ QVariant DataModel::data(const QModelIndex , int 
role) const
 break;
 }
 break;
-case DataTypes::ColumnsRoles::DurationRole:
+case DataTypes::ColumnsRoles::StringDurationRole:
 {
 switch (d->mModelType)
 {

 gwenview 
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 25adb69b..c34f4108 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,7 +3,7 @@ cmake_minimum_required (VERSION 3.0 FATAL_ERROR)
 # KDE Application Version, managed by release script
 set (RELEASE_SERVICE_VERSION_MAJOR "20")
 set (RELEASE_SERVICE_VERSION_MINOR "12")
-set (RELEASE_SERVICE_VERSION_MICRO "1")
+set (RELEASE_SERVICE_VERSION_MICRO "3")
 set (RELEASE_SERVICE_VERSION 
"${RELEASE_SERVICE_VERSION_MAJOR}.${RELEASE_SERVICE_VERSION_MINOR}.${RELEASE_SERVICE_VERSION_MICRO}")
 
 project(gwenview VERSION ${RELEASE_SERVICE_VERSION})
@@ -51,7 +51,7 @@ else()
 set(GWENVIEW_SEMANTICINFO_BACKEND_BALOO ON)
 endif()
 
-find_package(Qt5 ${QT_MIN_VERSION} CONFIG REQUIRED Core Widgets Concurrent Svg 
OpenGL PrintSupport)
+find_package(Qt5 ${QT_MIN_VERSION} CONFIG REQUIRED Core Widgets Concurrent Svg 
PrintSupport)
 find_package(Qt5DBus ${QT_MIN_VERSION} CONFIG QUIET)
 set(HAVE_QTDBUS ${Qt5DBus_FOUND})
 
diff --git a/app/gvcore.cpp b/app/gvcore.cpp
index 9f400059..4008e19c 100644
--- a/app/gvcore.cpp
+++ b/app/gvcore.cpp
@@ -425,8 +425,10 @@ void GvCore::saveAs(const QUrl )
 } else {
 // Regardless of job result, reset JPEG config value if it was changed 
by
 // the Save As dialog
-if (GwenviewConfig::jPEGQuality() != d->configFileJPEGQualityValue)
-GwenviewConfig::setJPEGQuality(d->configFileJPEGQualityValue);
+connect(job, ::result, [=]() {
+if (GwenviewConfig::jPEGQuality() != 

Bug#983379: linux uml segfault

[Johannes Berg]

I think the problem is here:

> #24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
> at ipc/util.c:119
> #25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
> ipc/sem.c:254
> #26 0x60015b5d in sem_init () at ipc/sem.c:268
> #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
> gnu/libcom_err.so.2

You're in the init of libcom_err.so.2, which is loaded by

> "libnss_nis.so.2"

which is loaded by normal NSS code (getgrnam):

> #40 0x7f89909bf3a6 in nss_load_library (ni=ni@entry=0x61497db0) at
> nsswitch.c:359
> #41 0x7f89909bfc39 in __GI___nss_lookup_function (ni=0x61497db0,
> fct_name=, fct_name@entry=0x7f899089b020 "setgrent") at
> nsswitch.c:467
> #42 0x7f899089554b in init_nss_interface () at nss_compat/compat-
> grp.c:83
> #43 init_nss_interface () at nss_compat/compat-grp.c:79
> #44 0x7f8990895e35 in _nss_compat_getgrnam_r (name=0x7f8990a2a1e0
> "tty", grp=0x7ffe3e7a2910, buffer=0x7ffe3e7a24e0 "", buflen=1024,
> errnop=0x7f899089eb00) at nss_compat/compat-grp.c:486
> #45 0x7f8990968b85 in __getgrnam_r (name=name@entry=0x7f8990a2a1e0
> "tty", resbuf=resbuf@entry=0x7ffe3e7a2910,
> buffer=buffer@entry=0x7ffe3e7a24e0 "", buflen=1024,
> result=result@entry=0x7ffe3e7a2908)
> at ../nss/getXXbyYY_r.c:315


You have a strange nsswitch configuration that causes all of this
(libnss_nis.so.2 -> libcom_err.so.2) to get loaded.

Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
... Linux's sem_init() instead of libpthread's.

And then the crash.

Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe we
can somehow give the kernel binary a lower symbol resolution than the
libc/libpthread.


johannes

Bug#984467: menu.h: fix a warning from the compiler

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3abe01c61d7bc1987a6d512fa15680d4c3924b2d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 3 Mar 2021 22:42:53 +
>Subject: [PATCH] menu.h: fix a warning from the compiler

In file included from nn.c:32:
menu.h:65:1: warning: parameter names (without types) in function declaration
   65 | int menu(fct_type);
  | ^~~



  Use an adequate function declaration "int (*)(void)" instead of
"fct_type)".

Signed-off-by: Bjarni Ingi Gislason 
---
 menu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/menu.h b/menu.h
index 6d1e903..e43ca02 100644
--- a/menu.h
+++ b/menu.h
@@ -62,7 +62,7 @@
 #define AC_UNCHANGED   6   /* no display changes */
 
 char   *pct(long, long, long, long);
-int menu(fct_type);
+int menu(int (*)(void));
 article_header *get_menu_article(void);
 int alt_command(void);
 int prt_replies(int);
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982935: [Pkg-mailman-hackers] Bug#982935: Postorius & Hyperkitty -- broken Javascript (Bootstrap)? - disfunctional drop-down menus

[Pierre-Elliott Bécue]

Le mercredi 03 mars 2021 à 22:06:20+0100, jonas a écrit :
> Hey PEB,
> 
> Plesse don't upload yet. I've a few other fixes pending and would like to do 
> some further testing before hands but won't make it before start of next 
> week. Or I'll do another upload shortly after.

If you are not sure to be able to upload in the next ten days, then
probably the three uploads I prepared are worth it.

Tell me what you prefer. :)

Cheers! :)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

Bug#946270: xpdf: can't search for various Unicode characters

[Adam Sampson]

On Fri, 6 Dec 2019 14:51:39 +0100 Vincent Lefevre  wrote:
> It is not possible to search for various Unicode characters.
[...]
> The "Find" dialogue box does not accept such characters, either
> via the keyboard or via copy-paste.

It was actually worse than that -- none of the text entry boxes accepted
non-ISO-8859-1 characters, and the search operated in ISO-8859-1
regardless of your locale's character encoding! To be fair to xpdf, it
does quite considerably predate Unicode support in Motif...

I've fixed this in xpopple with the patches below (use Unicode fonts,
enable locale support, convert the search string from the locale's
encoding), but I suspect there might be other locale problems lurking,
so I'll hold off pushing this to master until I've used it in practice
for a few days.

Cheers,
Adam

diff --git a/xpdf/XPDFApp.cc b/xpdf/XPDFApp.cc
index 990a01e..de460a7 100644
--- a/xpdf/XPDFApp.cc
+++ b/xpdf/XPDFApp.cc
@@ -31,9 +31,9 @@
 //
 
 static String fallbackResources[] = {
-  "*.zoomComboBox*FontList: 
-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1",
-  "*XmTextField.FontList: -*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1",
-  "*.FontList: -*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1",
+  "*.zoomComboBox*FontList: 
-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso10646-1",
+  "*XmTextField.FontList: -*-courier-medium-r-normal--12-*-*-*-*-*-iso10646-1",
+  "*.FontList: -*-helvetica-medium-r-normal--12-*-*-*-*-*-iso10646-1",
   "*XmTextField.translations: #override\\n"
   "  Ctrla:beginning-of-line()\\n"
   "  Ctrlb:backward-character()\\n"
diff --git a/xpdf/XPDFViewer.cc b/xpdf/XPDFViewer.cc
index 54380eb..8fe77c6 100644
--- a/xpdf/XPDFViewer.cc
+++ b/xpdf/XPDFViewer.cc
@@ -2767,11 +2767,11 @@ void XPDFViewer::initAboutDialog() {
 
   //- fonts
   aboutBigFont =
-createFontList("-*-times-bold-i-normal--20-*-*-*-*-*-iso8859-1");
+createFontList("-*-times-bold-i-normal--20-*-*-*-*-*-iso10646-1");
   aboutVersionFont =
-createFontList("-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1");
+createFontList("-*-times-medium-r-normal--16-*-*-*-*-*-iso10646-1");
   aboutFixedFont =
-createFontList("-*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1");
+createFontList("-*-courier-medium-r-normal--12-*-*-*-*-*-iso10646-1");
 
   //- heading
   n = 0;
diff --git a/xpdf/XPDFApp.cc b/xpdf/XPDFApp.cc
index de460a7..c72e0af 100644
--- a/xpdf/XPDFApp.cc
+++ b/xpdf/XPDFApp.cc
@@ -121,6 +121,8 @@ static int xErrorHandler(Display *display, XErrorEvent *ev) 
{
 #endif
 
 XPDFApp::XPDFApp(int *argc, char *argv[]) {
+  XtSetLanguageProc(NULL, NULL, NULL);
+
   appShell = XtAppInitialize(, xpdfAppName, xOpts, nXOpts,
 argc, argv, fallbackResources, NULL, 0);
   display = XtDisplay(appShell);
diff --git a/xpdf/PDFCore.cc b/xpdf/PDFCore.cc
index 4e7814b..aab0a18 100644
--- a/xpdf/PDFCore.cc
+++ b/xpdf/PDFCore.cc
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include "GlobalParams.h"
 #include "XPDFParams.h"
@@ -1650,16 +1651,21 @@ GooString *PDFCore::extractText(int pg, double xMin, 
double yMin,
 
 bool PDFCore::find(const char *s, bool caseSensitive, bool next, bool backward,
   bool wholeWord, bool onePageOnly) {
+  wchar_t *wbuf;
   Unicode *u;
   int len, i;
   bool ret;
 
-  // convert to Unicode
-  len = (int)strlen(s);
+  // Convert from the current locale's encoding to Unicode.
+  // (Poppler's Unicode type is not necessarily the same as wchar_t!)
+  len = (int)mbstowcs(NULL, s, 0);
+  wbuf = (wchar_t *)gmallocn(len + 1, sizeof(wchar_t));
+  mbstowcs(wbuf, s, len + 1);
   u = (Unicode *)gmallocn(len, sizeof(Unicode));
   for (i = 0; i < len; ++i) {
-u[i] = (Unicode)(s[i] & 0xff);
+u[i] = (Unicode)wbuf[i];
   }
+  gfree(wbuf);
 
   ret = findU(u, len, caseSensitive, next, backward, wholeWord, onePageOnly);
 
-- 
Adam Sampson  

Bug#984466: dput-ng: sends invalid Uploader field if no email set

[Dominic Hargreaves]

Package: dput-ng
Version: 1.32
Severity: important
Tags: patch

Per https://salsa.debian.org/debian/dput-ng/-/merge_requests/15 dput-ng
sends invalid data when the user doesn't specify an email address. The
patch supplied resolves this.

Bug#926501: xpdf: continuousView memory leak

[Adam Sampson]

On Sat, 06 Apr 2019 18:30:26 +1100 Kevin Ryde  wrote:
> With continuousView enabled [...]
> Viewing a medium to large document such as
> xpdf /usr/share/doc/bash-doc/bash.pdf
> and paging through it with space or page-down, results in the xpdf
> process using apparently ever growing memory, as shown by top or
> memstat.

I've just tested this with the latest xpopple and it seems fine, so I
think it was caused by one (or more) of the leaks that were fixed in the
most recent (xpopple-based) Debian xpdf package.

Thanks,

-- 
Adam Sampson  

Bug#984465: group.h: fix an error from the compiler

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From a09d4736ab1efd42e84d5b8e6e62093f14316477 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 3 Mar 2021 22:24:40 +
>Subject: [PATCH] group.h: fix an error from the compiler

cc -Iconf -Wall -Wextra -Wformat=2 -Wstringop-overflow=4
-Wshadow=global -Wredundant-decls -Wunused -Wunused-parameter
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error
-fstack-protector-strong -fno-common -fstack-clash-protection -ftrapv
-funsigned-char -fvar-tracking-assignments -ggdb -D_FORTIFY_SOURCE=2
-Wmissing-prototypes -Wold-style-definition -Wstrict-prototypes
-Wold-style-declaration -std=c2x   -c -o nn.o nn.c

In file included from nn.c:25:
group.h:6:97: error: unknown type name 'fct_type'; did you mean 'flag_type'?
6 | int group_menu(register group_header *, article_number, 
register flag_type, char *, fct_type);
  | 
^~~~
  | 
flag_type



  Use a specific type of "fct_type": int (*) (fct_type_void)

Signed-off-by: Bjarni Ingi Gislason 
---
 group.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/group.h b/group.h
index e8341e5..4a21d9f 100644
--- a/group.h
+++ b/group.h
@@ -3,7 +3,8 @@
  */
 
 int group_completion(char *, int);
-int group_menu(register group_header *, article_number, register 
flag_type, char *, fct_type);
+int group_menu(register group_header *, article_number, register 
flag_type, char *,
+  int (*) (fct_type_void) );
 group_header   *lookup_regexp(char *, char *, int);
 int goto_group(int, article_header *, flag_type);
 voidmerge_and_read(flag_type, char *);
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984464: global.h:. Fix a warning from the compiler

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 027ac74467e9fedb91ad68eac9a14b145a921677 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 3 Mar 2021 21:57:21 +
>Subject: [PATCH] global.h:. Fix warning from the compiler

cc -Iconf -Wall -Wextra -Wformat=2 -Wstringop-overflow=4
-Wshadow=global -Wredundant-decls -Wunused -Wunused-parameter
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error
-fstack-protector-strong -fno-common -fstack-clash-protection -ftrapv
-funsigned-char -fvar-tracking-assignments -ggdb -D_FORTIFY_SOURCE=2
-Wmissing-prototypes -Wold-style-definition -Wstrict-prototypes
-Wold-style-declaration -std=c2x   -c -o nn.o nn.c

In file included from nn.c:18:
global.h:30:1: warning: function declaration isn't a prototype 
[-Wstrict-prototypes]
   30 | typedef int (*fct_type) ();
  | ^~~



  Create more specific prototypes:

(*fct_type_void) (void);

(*fct_type_int) (int);

(*fct_type_char_int) (char *, int);

Signed-off-by: Bjarni Ingi Gislason 
---
 global.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/global.h b/global.h
index 0d9d475..9f75975 100644
--- a/global.h
+++ b/global.h
@@ -27,9 +27,17 @@ typedef longarticle_number;
 typedef int32   group_number;
 typedef uint32  time_stamp;
 
-typedef int (*fct_type) ();
+/* Special "*fct_type" are needed */
+/* typedef int (*fct_type) (); */
+typedef int (*fct_type_void) (void);
+typedef int (*fct_type_int) (int);
+typedef int (*fct_type_char_int) (char *, int);
+
 #define CALL(fct)  (* (fct))
-#define NULL_FCT  (fct_type)NULL
+/* #define NULL_FCT  (fct_type)NULL */
+#define NULL_FCT  (fct_type_char_int)NULL
+#define NULL_FCT_INT  (fct_type_int)NULL
+
 
 /* frequently used characters */
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982935: [Pkg-mailman-hackers] Bug#982935: Postorius & Hyperkitty -- broken Javascript (Bootstrap)? - disfunctional drop-down menus

[jonas]

Hey PEB,

Plesse don't upload yet. I've a few other fixes pending and would like to do 
some further testing before hands but won't make it before start of next week. 
Or I'll do another upload shortly after.

Cheers
 jonas


Am 3. März 2021 21:30:30 MEZ schrieb "Pierre-Elliott Bécue" :
>Le vendredi 26 février 2021 à 13:06:12+0100, Wolfgang Walkowiak a écrit :
>> 
>> Packages: python3-django-postorius, python3-django-hyperkitty
>> Version: 1.3.4-1
>> 
>> Dear Debian maintainers for the packages postorius and hyperkitty,
>> dear Jonas, dear Matt,
>> 
>> we experienced similar issues with non-functional drop down menus
>> in mailman3-web after installing mailman3-full (version 3.3.3.1)
>> which includes the two packages mentioned above.
>> 
>> The hints in Jonas' response have been very useful.  Thank you!
>> However, this only fixed the issue for postorius, but not for hyperkitty. As
>> soon as we klicked on the archive link, the drop-down menus didn't function
>> any longer.
>> 
>> After we have replaced a couple more bootstrap related symlinks in
>> python3-django-hyperkitty with the js-files from the master branch
>> on gitlab and recollected and recompressed all static items, and
>> restarted mailman3-web it worked.  See our full recipe for obtaining
>> a mailman3-web interface with working drop-down menus below.
>> 
>> We would appreciate if the replacement of the bootstrap-related
>> javascript files in the postorius and hyperkitty packages by symlinks
>> to generic instances on the system could be reconsidered for the
>> next revision of these two Debian packages.
>> 
>> Thank you very much for maintaining these Debian packages,
>> 
>> w.w.
>> 
>> 
>> --
>> Details on our recipe (work-around) to fix the drop-down menus:
>> (For other users hitting the same issue.)
>> 
>> Replace the the symbolic links in python3-django-postorius from
>> upstream master following suggestion on bug report 982935 above:
>> 
>> # cd /usr/share/python3-django-postorius/static/postorius/libs/bootstrap/js
>> # mv bootstrap.min.js bootstrap.min.js.org
>> # wget 
>> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/bootstrap/js/bootstrap.min.js
>> # cd /usr/share/python3-django-postorius/static/postorius/libs/jquery
>> # mv jquery-1.11.3.min.js jquery-1.11.3.min.js.org
>> # wget 
>> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/jquery/jquery-1.11.3.min.js
>> # cd /usr/share/python3-django-postorius/static/postorius/libs/html5shiv
>> # mv html5shiv.js html5shiv.js.org
>> # mv html5shiv.min.js html5shiv.min.js.org
>> # wget 
>> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.js
>> # wget 
>> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.min.js
>> 
>> Replace the bootstrap.js and bootstrap.min.js links from the upstream master:
>> 
>> # cd 
>> /usr/share/python3-django-hyperkitty/static/hyperkitty/libs/bootstrap/javascripts
>> # mv bootstrap.js bootstrap.js.org
>> # mv bootstrap.min.js bootstrap.min.js.org
>> # wget 
>> https://gitlab.com/mailman/hyperkitty/-/raw/master/hyperkitty/static/hyperkitty/libs/bootstrap/javascripts/bootstrap.min.js
>> # wget 
>> https://gitlab.com/mailman/hyperkitty/-/raw/master/hyperkitty/static/hyperkitty/libs/bootstrap/javascripts/bootstrap.js
>> 
>> Afterwards, using the wrapper script defined below, run:
>> 
>> # mailman-web collectstatic --no-input -v 1 --clear
>> # mailman-web compress -v 1
>> # systemctl restart mailman3-web
>> 
>> Wrapper script /usr/local/sbin/mailman-web :
>> #!/bin/sh
>> su -s /bin/sh -c "/usr/share/mailman3-web/manage.py $*" www-data
>> 
>> (Would be useful if a script like this were included in the mailman3-web
>> packages as the mailman3 documentation often refers to it instead of to
>> the lenghty /usr/share/mailman3-web/manage.py etc.)
>
>Hi,
>
>There is a plan to keep using Debian's versions of the JS libs here.
>Bundled libs are a hell to sort out.
>
>Regarding the bug, it's due to the fact that now, hyperkitty and
>postorius are depending on bootstrap4 while we relink to bootstrap 3.
>
>I've made a patch that I'll upload soon for both packages.
>
>Sorry for the inconvenience.
>

Bug#956437: closed by Debian FTP Masters (reply to Aurélien COUDERC ) (Bug#956426: fixed in desktop-base 11.0.2)

[Aurélien COUDERC]

Le mercredi 3 mars 2021, 21:24:47 CET Gert van de Kraats a écrit :
> Hello Aurelien,

Hi Gert,

> Unfortunately this solution does not help.

thanks for the feedback.

Would you mind confirming which theme you’re using ?
So far I fixed it only for the Homeworld theme, the default for Bullseye.
If not your current theme would you mind trying with it and reporting back ?

When I say fixed, I didn’t try with your exact resolutions but I now have a 
laptop + external monitor, and I definitely experienced the bug as you 
described it and made a change that fixed it.

The fix is at /usr/share/plymouth/themes/homeworld/homeworld.script:122

-min_height = Window.GetHeight();
+min_height = window_max.height;

You may want to try that with other themes and also report back if you feel 
like it.
You can directly change the script in
/usr/share/plymouth/theme/$theme/$theme.script
and remember to update-initramfs -u before rebooting to test the change.


Happy hacking !
--
Aurélien

Bug#984463: recollgui: missing Breaks+Replaces: recollcmd (<< 1.28)

[Andreas Beckmann]

Package: recollgui
Version: 1.28.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../5-recollgui_1.28.5-1_amd64.deb ...
  Unpacking recollgui (1.28.5-1) over (1.24.3-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-EVss6r/5-recollgui_1.28.5-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/recoll/doc/docbook-xsl.css', which is also 
in package recollcmd 1.24.3-3
  Preparing to unpack .../6-recollcmd_1.28.5-1_amd64.deb ...
  Unpacking recollcmd (1.28.5-1) over (1.24.3-3) ...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-EVss6r/5-recollgui_1.28.5-1_amd64.deb


cheers,

Andreas


recollgui_1.28.5-1.log.gz
Description: application/gzip

Bug#983913: [Pkg-puppet-devel] Bug#983913: puppet-master, puppet-master-passenger: depends on unavailable puppet-server

[Thomas Goirand]

On 3/3/21 11:06 AM, Andreas Beckmann wrote:
> Package: puppet-master,puppet-master-passenger
> Version: 6.16.0-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed puppet-master*/experimental is not
> installable due to an unsatisfiable dependency on puppet-server
> 
> 
> Cheers,
> 
> Andreas

Hi Andreas,

This is a well known issue, done on purpose. We have the intention to
package puppet-server, unfortunately, we're currently stuck on packaging
jruby (it has problems). This is also the reason why the package lives
in Experimental.

Cheers,

Thomas Goirand (zigo)

Bug#984447: CVE-2021-3419

[Salvatore Bonaccorso]

Hi Moritz, hi 
On Wed, Mar 03, 2021 at 08:12:50PM +0100, Moritz Muehlenhoff wrote:
> Package: qemu
> Severity: normal
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> This was assigned CVE-2021-3419:
> https://bugs.launchpad.net/qemu/+bug/1910826
> https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg00010.html

it looks that Red Hat (the assigning CNA) has actually just withdrawn
the CVE with reason "This candidate was withdrawn by its CNA." No
further explanation.

So I guess the issue was just found to be either covered by another
CVE or a non-issue, I have no details.

I just have updated the security-tracker removing the references
accordingly.

Regards,
Salvatore

Bug#956437: closed by Debian FTP Masters (reply to Aurélien COUDERC ) (Bug#956426: fixed in desktop-base 11.0.2)

[Gert van de Kraats]

Hello Aurelien,

Unfortunately this solution does not help.

Message is still written through word "Debian" with same color white,

and therefore unreadable.

I tested it at

    text_height = first_line_height * 7.5;
    min_height = Window.GetHeight();
    #Debug("text_height=" + text_height + "; min_height=" + min_height);


    if (y + text_height > min_height)
    y = min_height - text_height;

The script has a lot of code to accommodate screens of different size.

My screens use heigths 1024 and 800.

Plymouth shows at the smallest screen  the center part of the largest 
screen, that just fits.


The smallest screen has a vertical offset Window.GetY() to the top of 
the largest screen.


y is the offset of text to the top of the largest screen.

But min_height is the height of the smallest screen.

It must be compared with the offset to the top of the smallest screen.

This offset is  y - Window.GetY() and should be used at the compare.

The second problem is that if it does not fit, the text will be shifted 
a little bit upwards at the


middle of the large word "Debian" and become unreadalble.

Therefore it should shifetd to the first line that is visible at both 
screens.


Therfore I  think still the proposed fix is needed:


    if (y - Window.GetY() + text_height > min_height)
    # shift to top of smallest window
    y = Window.GetY() + 1;




On 3/2/21 1:06 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the desktop-base package:

#956437: plymouth: Message is unreadable at initial Debian screen on dual 
monitor

It has been closed by Debian FTP Masters  (reply to 
Aurélien COUDERC).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP 
Masters  (reply to Aurélien 
COUDERC) by
replying to this email.

Bug#982935: [Pkg-mailman-hackers] Bug#982935: Postorius & Hyperkitty -- broken Javascript (Bootstrap)? - disfunctional drop-down menus

[Pierre-Elliott Bécue]

Le vendredi 26 février 2021 à 13:06:12+0100, Wolfgang Walkowiak a écrit :
> 
> Packages: python3-django-postorius, python3-django-hyperkitty
> Version: 1.3.4-1
> 
> Dear Debian maintainers for the packages postorius and hyperkitty,
> dear Jonas, dear Matt,
> 
> we experienced similar issues with non-functional drop down menus
> in mailman3-web after installing mailman3-full (version 3.3.3.1)
> which includes the two packages mentioned above.
> 
> The hints in Jonas' response have been very useful.  Thank you!
> However, this only fixed the issue for postorius, but not for hyperkitty. As
> soon as we klicked on the archive link, the drop-down menus didn't function
> any longer.
> 
> After we have replaced a couple more bootstrap related symlinks in
> python3-django-hyperkitty with the js-files from the master branch
> on gitlab and recollected and recompressed all static items, and
> restarted mailman3-web it worked.  See our full recipe for obtaining
> a mailman3-web interface with working drop-down menus below.
> 
> We would appreciate if the replacement of the bootstrap-related
> javascript files in the postorius and hyperkitty packages by symlinks
> to generic instances on the system could be reconsidered for the
> next revision of these two Debian packages.
> 
> Thank you very much for maintaining these Debian packages,
> 
> w.w.
> 
> 
> --
> Details on our recipe (work-around) to fix the drop-down menus:
> (For other users hitting the same issue.)
> 
> Replace the the symbolic links in python3-django-postorius from
> upstream master following suggestion on bug report 982935 above:
> 
> # cd /usr/share/python3-django-postorius/static/postorius/libs/bootstrap/js
> # mv bootstrap.min.js bootstrap.min.js.org
> # wget 
> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/bootstrap/js/bootstrap.min.js
> # cd /usr/share/python3-django-postorius/static/postorius/libs/jquery
> # mv jquery-1.11.3.min.js jquery-1.11.3.min.js.org
> # wget 
> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/jquery/jquery-1.11.3.min.js
> # cd /usr/share/python3-django-postorius/static/postorius/libs/html5shiv
> # mv html5shiv.js html5shiv.js.org
> # mv html5shiv.min.js html5shiv.min.js.org
> # wget 
> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.js
> # wget 
> https://gitlab.com/mailman/postorius/-/raw/master/src/postorius/static/postorius/libs/html5shiv/html5shiv.min.js
> 
> Replace the bootstrap.js and bootstrap.min.js links from the upstream master:
> 
> # cd 
> /usr/share/python3-django-hyperkitty/static/hyperkitty/libs/bootstrap/javascripts
> # mv bootstrap.js bootstrap.js.org
> # mv bootstrap.min.js bootstrap.min.js.org
> # wget 
> https://gitlab.com/mailman/hyperkitty/-/raw/master/hyperkitty/static/hyperkitty/libs/bootstrap/javascripts/bootstrap.min.js
> # wget 
> https://gitlab.com/mailman/hyperkitty/-/raw/master/hyperkitty/static/hyperkitty/libs/bootstrap/javascripts/bootstrap.js
> 
> Afterwards, using the wrapper script defined below, run:
> 
> # mailman-web collectstatic --no-input -v 1 --clear
> # mailman-web compress -v 1
> # systemctl restart mailman3-web
> 
> Wrapper script /usr/local/sbin/mailman-web :
> #!/bin/sh
> su -s /bin/sh -c "/usr/share/mailman3-web/manage.py $*" www-data
> 
> (Would be useful if a script like this were included in the mailman3-web
> packages as the mailman3 documentation often refers to it instead of to
> the lenghty /usr/share/mailman3-web/manage.py etc.)

Hi,

There is a plan to keep using Debian's versions of the JS libs here.
Bundled libs are a hell to sort out.

Regarding the bug, it's due to the fact that now, hyperkitty and
postorius are depending on bootstrap4 while we relink to bootstrap 3.

I've made a patch that I'll upload soon for both packages.

Sorry for the inconvenience.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#984462: RFH: open-build-service

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org, Andrew Lee (李健秋) 
, Debian Ruby Extras Maintainers 


Hi,

While I don’t work on the OBS package in Debian, I know about the state
of the package in Debian right now: the team, and most notably the main
maintainer, Andrew Lee, need help to maintain this package, as it
requires a lot of work due to a combination of Ruby / Ruby on Rails,
Perl and shell bits. Ruby parts specifically is a pain point, since
there’s a lot of gems this package depends on and updating one or
multiple of them can break OBS in ways the upstream didn’t think about.

The package has already missed Buster and Bullseye, and if the situation
doesn’t improve, it may result in a removal at some point.

Unfortunately, I lack necessary knowledge of the Ruby ecosystem to be
able to meaningfully help myself, but this package needs more people to
work on it, so if you can help, please consider doing so.

Thanks!

-- 
Cheers,
  Andrej

Bug#984461: ITP: fnt -- Font downloader/manager

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: fnt
  Version : 1.1
  Upstream Author : Alex Myczko 
* URL : https://github.com/alexmyczko/fnt
* License : MIT
  Description : Font downloader/manager
 Search, preview, and download more than 1800 fonts as user.

I plan to improve that thing quite a bit, but prefer to package this
within the debian fonts team.

Bug#982704: ofxstatement-plugins: FTBFS: TypeError: expected str, bytes or os.PathLike object, not NoneType

[Alexander Gerasiov]

On Thu, 4 Mar 2021 00:27:17 +0500
Andrey Rahmatullin  wrote:

> On Sat, Feb 13, 2021 at 06:06:54PM +0100, Lucas Nussbaum wrote:
> > > cd ofxstatement-be-argenta && python3 setup.py test
> > > running test
> > > [...]
> > >   File
> > > "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > > 1379, in __init__ self.module_path =
> > > os.path.dirname(getattr(module, '__file__', '')) File
> > > "/usr/lib/python3.9/posixpath.py", line 152, in dirname p =
> > > os.fspath(p) TypeError: expected str, bytes or os.PathLike
> > > object, not NoneType make[1]: *** [debian/rules:32:
> > > plugin_test_ofxstatement-be-argenta] Error 1  
> So Python tries to find tests here and fails. I tried to debug why it
> failes here but in ofxstatement-airbankcz and the difference seems to
> be caused by unittest.loader.TestLoader._find_test_path() finding
> ofxstatement/__init__.py here but not in ofxstatement-airbankcz. I'll
> leave this at this point to someone more familiar with test discovery,
> namespaces and packages.

Yep, failed to quickly solve this issue too.
I think I just had to turn off test discovery for
ofxstatement-be-argenta. Will fix it later this week.


-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#984460: RFS: tlog/11-1 [ITP] -- terminal I/O recording and playback

[Markus Schade]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: tlog
   Version : 11-1
   Upstream Author : Nikolai Kondrashov 
 * URL : http://scribery.github.io/tlog/
 * License : GPL-2+
 * Vcs : https://github.com/Scribery/tlog
   Section : misc

It builds those binary packages:

  libtlog0 - library for terminal I/O recording and playback
  tlog - terminal I/O recording and playback

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


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

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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlog/tlog_11-1.dsc

Changes for the initial release:

 tlog (11-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #886927)

Regards,
Markus

Bug#984459: spring: Broken manpages due to bashisms in source

[Jessica Clarke]

Source: spring
Version: 105.0.1+dfsg-2
Severity: important

In spring.6.txt there are snippets like the following:

{sys: echo -e "{USER_WRITEDIRS}"}

However, this is not portable across shells, as echo -e is a bash
extension, causing this to print a literal -e when /bin/sh is dash.
This is important, since that is the default for Debian systems,
including on all buildds.

Interestingly, the escape sequences still give the right value for
dash, the only difference is whether -e is printed too, so I suspect
the -e is entirely superfluous and asciidoc(?) has already done the
expansion (and potentially risks double-expanding on bash, so \\n might
print as a newline rather than a literal \n), but that is just
speculation. Regardless, this should be fixed one way or another, as
the packages currently in the archive have stray -e's in the manpage:

   
+-+---+--+--+--+
   |priority |  section  |normal|   
portable   |  isolation   |
   
+-+---+--+--+--+
   | |   |  |   
   |  |
   |high | custom user write | -e directory defined via --write-dir | 
-e directory defined via --write-dir | -e directory defined via --write-dir |
   | |   |  |   
   |  |
   | |   | SPRING_WRITEDIR envvar   | 
SPRING_WRITEDIR envvar   | SPRING_WRITEDIR envvar   |
   
+-+---+--+--+--+
   | |   |  |   
   |  |
   | | automatic scanned | -e CONFIG_HOME   | 
-e INSTALL_DIR   | ISOLATION_DIR|
   | |   |  |   
   |  |
   | |   | ETC_DIRS | 
CONFIG_HOME  |  |
   | |   |  |   
   |  |
   | |   | USR_SHARE| 
ETC_DIRS |  |
   | |   |  |   
   |  |
   | |   |  | 
USR_SHARE|  |
   
+-+---+--+--+--+
   | |   |  |   
   |  |
   | low | custom user read  | -e SPRING_DATADIR envvar | 
-e SPRING_DATADIR envvar | -e SPRING_DATADIR envvar |
   | |   |  |   
   |  |
   | |   | SpringData configtag | 
SpringData configtag | SpringData configtag |
   
+-+---+--+--+--+

(spring(6) in the latest amd64 unstable package)

In case you're interested, this was discovered by the automated builds
done as part of reproducible-builds.org.

Jess

Bug#984438: questionable dependency on python3-pip

[Karsten Hilbert]

Am Wed, Mar 03, 2021 at 08:33:57PM +0100 schrieb Matthias Klose:

> >> gnumed-client depends on python3-pip. Why?
> >>
> >> The only use is in external-tools/check-prerequisites.py trying to 
> >> download the
> >> pysvg module last updated in 2012, and not ported to Python3 ...
> >
> > The helper script external-tools/check-prerequisites.py
> > certainly does not do anything obnoxious like "trying to
> > download the pysvg module". It merely tells the user how to
> > retrieve the proper version thereof.
>
> well, then it can tell to install python3-pip as well.

It now does, thanks for the suggestiong.

> > Quite apart from that the dependency can safely be demoted to
> > Recommends:, or even Suggests:, if the former is still
> > coupling too tightly.
>
> just remove it, or package the dependency properly.

Is there anything fundamentally, conceptually *wrong*
(not just not recommendable) with

Suggests: python3-pip

?

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#983845: doas does not autocomplete apt

[Scupake]

Actually, nevermind.
I think bash-completion doesn't support doas yet.
I have just opened an issue on the git repo:
https://github.com/scop/bash-completion/issues/505

-- 
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#982579: Solution for loading firmware

[maximilian attems]

> Both patches applied and pushed out.

great thank you.
 
> In the future, could you please send the patches either as direct
> emails or as attachments or as pull requests?  When you embed them in
> the body of the email I have to manually adjust them to get the commit
> log properly included.

sure, will do as pull request.

Bug#984458: libtorrent-rasterbar10: libtorrent 1.2.9 unable to move completed torrents

[jug007]

Package: libtorrent-rasterbar10
Version: 1.2.9-0.2+b2
Severity: normal

Dear Maintainer,

libtorrent 1.2.9 seems to include a bug which causes it to become unable to 
move completed torrents.
In my case this issue appears when using libtorrent 1.2.9 together with Deluge 
2.3.0 from the official debian bullseye repositories.
This issue didn't appear on 1.1.11-2.
Another user suggests that this issue was fixed in 1.2.11. (See  
https://dev.deluge-torrent.org/ticket/3458 )

Greetings
Julian Groß

-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (400, 'testing'), (1, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libtorrent-rasterbar10 depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libssl1.1   1.1.1d-0+deb10u5
ii  libstdc++6  10.2.1-6

libtorrent-rasterbar10 recommends no packages.

Versions of packages libtorrent-rasterbar10 suggests:
pn  libtorrent-rasterbar-dbg  

-- no debconf information

Bug#981515: kcoreaddons: please replace fam with gamin

[Nicholas D Steeves]

Hi,

Glenn Strauss  writes:

> gamin provides libfam0.
>
> kcoreaddons should load just fine with libfam0 from gamin.
>
> I did the research in #510368 and #966273, reviewing the actual code
> and confidentally concluded that FAM can be removed from Bullseye.
>
> The safest choice is to have a single library (gamin) used in the
> distro, rather than having both FAM and gamin.
>

I don't think the removal of FAM is as clear-cut as it has been
presented to be.

AFAIK the following is still current: Gamin provides "No NFS support
based on specific RPC and server, instead gamin monitors only the state
as reported locally by the kernel, not that locally done changes on NFS
or AFS filesystems are reported on Linux which is the main criteria when
having user home directories on such filesystems."

  https://people.gnome.org/~veillard/gamin/differences.html

thus FAM covers a use case that gamin does not, and this case is: users
who want to receive inotify style events for files that have been
remotely created or modified on NFS mounts.

I can't speak to how widespread the need for this feature is, but if it
is non-zero then it seems to me that FAM should not be removed this late
in the Bullseye cycle.

Also, IIRC gamin depends on Linux-specific features such as inotify
where FAM provides fallbacks (eg: IIRC FAM is required on kfreebsd and
hurd); this might not be significant, but I felt it was worth mentioning
:-)

FreeBSD doesn't have inotify, so there is a need for FAM, and maybe
someone from their community has become the defacto upstream (via their
"ports" packaging system)?  Or maybe someone from their community would
be willing to officially become FAM's new upstream?


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#980963: dpkg: Please add ARC architecture

[Helmut Grohne]

Hi Alexey,

On Wed, Mar 03, 2021 at 07:35:39PM +, Alexey Brodkin wrote:
> Well not sure why there's a dependency on glibc as w/o ARC target support
> in dpkg nothing could be built for ARC. For example I did built Binutils
> with fixed dpkg.

There is no hard dependency in that direction. Just pushback on adding
lots of Debian architectures that never really take off. For instance,
or1k was never fully bootstrapped. It'll be merged. Just not now. (Not
speaking as a dpkg maintainer here, just telling what will happen from
experience.)

> > Things that often need architecture-specific support for a new
> > architecture include:
> >  * guile-X.Y (cross support)
> >  * libgc
> 
> Above 2 are not [yet] supported but seems to be easy ones.

guile-X.Y is quite mechanical, yes. libgc can be a little more
difficult.

> >  * libxcrypt (symbols)
> 
> Not sure about "libxcrypt" (whatver that means), but libgpg-error supports 
> ARC since 2018, see:

https://tracker.debian.org/pkg/libxcrypt

> https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

This should be unneeded. libgpg-error now defaults to
force_use_syscfg=no and no longer needs arch-specific changes.

> >  * nspr
> 
> Done in 2019, see 
> https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

Great.

> >  * openssl (packaging)
> 
> Not sure what needs to be done here as I know we build a lot of complex
> things with OpenEmbedded/Yocto and openssl libs are being built for sure.

https://sources.debian.org/src/openssl/1.1.1j-1/debian/patches/debian-targets.patch/

> > Are any of these fixed or confirmed working for arc?
> 
> See above, quite some do work.

Impressive. Some work is left. What also is left is demonstrating that
it actually works. It seems that Vineet is working on integrating it.

Helmut

Bug#980963: dpkg: Please add ARC architecture

[Alexey Brodkin]

Hi Helmut,

> On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote:
> > Any chances to get updates on this one some time soon?
> 
> No. The triplet cannot be changed once added. Therefore, the addition is
> often deferred. The absence of the triplet can easily be worked around.
> A bootstrap can be prototyped already. A major missing piece though is
> glibc 2.32 being packaged in Debian. That likely is a prerequisite for
> resolving this bug.

Well not sure why there's a dependency on glibc as w/o ARC target support
in dpkg nothing could be built for ARC. For example I did built Binutils
with fixed dpkg.

> Things that often need architecture-specific support for a new
> architecture include:
>  * guile-X.Y (cross support)
>  * libgc

Above 2 are not [yet] supported but seems to be easy ones.

>  * libxcrypt (symbols)

Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC 
since 2018, see:
https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

>  * nspr

Done in 2019, see 
https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

>  * openssl (packaging)

Not sure what needs to be done here as I know we build a lot of complex
things with OpenEmbedded/Yocto and openssl libs are being built for sure.

> Are any of these fixed or confirmed working for arc?

See above, quite some do work.
 
-Alexey

Bug#984457: 特殊符號第二頁有重複字

[積丹尼 Dan Jacobson]

Package: ibus-chewing
Version: 1.6.1-1
Severity: minor

特殊符號第二頁有重複字， 1,2 與 5,6 重複， 如圖：

Bug#970259: xfce4-weather-plugin: Someone upload an updated to buster-backports, PLEASE

[Marcel Partap]

Package: xfce4-weather-plugin
Followup-For: Bug #970259
X-Debbugs-Cc: mpar...@gmx.net

We have deployed a lot of systems that have now a broken panel setup; for some,
working weather is deemed critical infrastructure.
Would anyone !please! take the liberty to upload a working package to
backports, it is trivial to compile. This will not fix existing installs
(unattended updates enabled only for security-updates) but at least allow keep
deploying another round of buster images..

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

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

Versions of packages xfce4-weather-plugin depends on:
ii  libc62.31-9
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libgtk-3-0   3.24.24-1
ii  libpango-1.0-0   1.46.2-3
ii  libsoup2.4-1 2.72.0-2
ii  libxfce4panel-2.0-4  4.16.1-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2
ii  libxml2  2.9.10+dfsg-6.3+b1

xfce4-weather-plugin recommends no packages.

xfce4-weather-plugin suggests no packages.

Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.

[Markus Schade]

Hi,

as there has not been any activity on this in the last two years,
I have taken the liberty to re-assign this bug to myself.

I have started the packaging at:

https://salsa.debian.org/ascii/tlog

An intial package uploaded at mentors:

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

@Adam:
I know this conflicts with your own termrec package,
but Fedora/RHEL have chosen/created tlog as standard
for session-recording.

That means those who want unified solution across distros
will want or have to use tlog on Debian-based systems as well.


Best regards,
Markus

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Thomas Uhle]

On Sat, 13 Jul 2019, Dmitry Bogatov wrote:


control: tags -1 +moreinfo
control: user kact...@debian.org
control: usertags -1 +objections

[2019-03-07 14:45] Dmitry Bogatov 
> [2019-03-05 23:41] Michael Biebl 
> > Control: reassign -1 insserv
> > > I think insserv should depend on initscripts. It requires that to
> > > actually do anything.
> > >
> > > Adding Conflicts will likely make switching inits much more difficult.
> >
> > Nod, reassigning back to insserv.
>
> Bug is in incorrect usage of insserv, not within insserv. You may want to
> add check, that /etc/init.d/mountkernfs.sh exists.
>
> If it will help you, I can add 'Recommends' (not Depends) on
> bin:initscripts into insserv.
>
> If if you disagree, please close + wontfix this bug.

On second thought, maybe it is okay to add dependency of insserv on
initscripts? After all, we already have initscripts installed, and
systemd users are unlikely to complain about bloat...

Opinions?



It might be a bit late but I had encountered the same situation after 
dist-upgrading from an older Debian release. So maybe I can somehow shed 
some additional light on this issue.
The actual culprit is rcconf which is marked as manually installed and 
depends on sysv-rc which in turn depends on insserv and startpar; and so 
all these packages remain installed after the migration to systemd. At the 
same time sysvinit-core (which depends on initscripts) is removed and so 
is initscripts because the package systemd-sysv has corresponding entries 
for 'Conflicts:' and 'Replaces:'.
But if you manually remove rcconf, the other three packages can be 
automatically removed afterwards as none of them is needed by systemd.


So I think both would make sense, add 'Recommends: initscripts' to insserv 
because initscripts is somehow needed for insserv as well as adding 
'Conflicts: sysv-rc' to systemd-sysv to help migrating to systemd. Anyway, 
systemd-sysv already conflicts with file-rc and openrc, so additionally 
conflicting with sysv-rc shouldn't really make things worse.


Best regards,

Thomas Uhle

Bug#984438: questionable dependency on python3-pip

[Matthias Klose]

On 3/3/21 8:29 PM, Karsten Hilbert wrote:
> Am Wed, Mar 03, 2021 at 07:49:29PM +0100 schrieb Matthias Klose:
> 
>> gnumed-client depends on python3-pip. Why?
>>
>> The only use is in external-tools/check-prerequisites.py trying to download 
>> the
>> pysvg module last updated in 2012, and not ported to Python3 ...
> 
> The helper script external-tools/check-prerequisites.py
> certainly does not do anything obnoxious like "trying to
> download the pysvg module". It merely tells the user how to
> retrieve the proper version thereof.

well, then it can tell to install python3-pip as well. No need to have a hard
dependency on that.

> Quite apart from that the dependency can safely be demoted to
> Recommends:, or even Suggests:, if the former is still
> coupling too tightly.

just remove it, or package the dependency properly.

Matthias

Bug#983702: voltron: Update package with new upstream release

[Andrey Rahmatullin]

Control: retitle -1 Doesn't work with current werkzeug
COntrol: tags -1 + upstream fixed-upstream patch

On Sun, Feb 28, 2021 at 05:52:23PM +0100, Thomas Nyberg wrote:
> The reason seems to be that the debian testing packaged version of werkzeug is
> 1.0.1 while the packaged version of voltran does not support it. There is a
> commit in the upstream repo that solves this problem:
> 
> 
> https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a
> 
> Unfortunately that commit is not included in an official release. I'm unsure 
> if
> that is required for it to be packaged with debian. Regardless, the older
> version does not work as packaged (though the required changes are admittedly
> quite minor).
Assuming this patch fixes the problem, the correct way will be to apply it
to the current version and upload it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#984456: RM: gcc-cross-support/experimental -- ROM; implemented by gcc-defaults

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org

Dear ftp master,

please remove the source package gcc-cross-support and all of its
binary packages from experimental.

gcc-cross-support was meant as a proof-of-concept for showcasing where
we're headed. This now causes issues with gcc-defaults providing the
same packages, which is a good thing. We're not quite there yet, but I
think at this point, the concept is well understood and the package
serves no useful purpose anymore.

Helmut

Bug#984438: questionable dependency on python3-pip

[Karsten Hilbert]

Am Wed, Mar 03, 2021 at 07:49:29PM +0100 schrieb Matthias Klose:

> gnumed-client depends on python3-pip. Why?
>
> The only use is in external-tools/check-prerequisites.py trying to download 
> the
> pysvg module last updated in 2012, and not ported to Python3 ...

The helper script external-tools/check-prerequisites.py
certainly does not do anything obnoxious like "trying to
download the pysvg module". It merely tells the user how to
retrieve the proper version thereof.

Quite apart from that the dependency can safely be demoted to
Recommends:, or even Suggests:, if the former is still
coupling too tightly.

Thanks,
Karsten (upstream)
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#982704: ofxstatement-plugins: FTBFS: TypeError: expected str, bytes or os.PathLike object, not NoneType

[Andrey Rahmatullin]

On Sat, Feb 13, 2021 at 06:06:54PM +0100, Lucas Nussbaum wrote:
> > cd ofxstatement-be-argenta && python3 setup.py test
> > running test
> > [...]
> >   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> > 1379, in __init__
> > self.module_path = os.path.dirname(getattr(module, '__file__', ''))
> >   File "/usr/lib/python3.9/posixpath.py", line 152, in dirname
> > p = os.fspath(p)
> > TypeError: expected str, bytes or os.PathLike object, not NoneType
> > make[1]: *** [debian/rules:32: plugin_test_ofxstatement-be-argenta] Error 1
So Python tries to find tests here and fails. I tried to debug why it
failes here but in ofxstatement-airbankcz and the difference seems to be
caused by unittest.loader.TestLoader._find_test_path() finding
ofxstatement/__init__.py here but not in ofxstatement-airbankcz. I'll
leave this at this point to someone more familiar with test discovery,
namespaces and packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#984455: CVE-2020-35505

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-35505:
https://bugzilla.redhat.com/show_bug.cgi?id=1909769
https://bugs.launchpad.net/qemu/+bug/1910723 (reproducer)

Cheers,
Moritz

Bug#984454: CVE-2020-35506

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-35506:
https://bugzilla.redhat.com/show_bug.cgi?id=1909996
https://bugs.launchpad.net/qemu/+bug/1909247

Cheers,
Moritz

Bug#984453: CVE-2021-20196

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-20196:
https://bugzilla.redhat.com/show_bug.cgi?id=1919210
https://bugs.launchpad.net/qemu/+bug/1912780
https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg05986.html

Cheers,
Moritz

Bug#983932: hplip: Actual section name in models.dat doesn't match expected section name

[Tobias Diedrich]

Package: hplip
Version: 3.21.2+dfsg1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

there seems to be a mismatch between [some?] section names in 
/usr/share/hplip/data/models/models.dat
and the name that hp-config_usb_printer determines and tries to look up:

# lsusb -d 03f0:0217
Bus 003 Device 076: ID 03f0:0217 HP, Inc LaserJet 2200
# hp-config_usb_printer -ldebug 003:076
hp-config_usb_printer[29315]: debug: param=003:076
hp-config_usb_printer[29315]: debug: Cache miss: hp_laserjet_2200
hp-config_usb_printer[29315]: debug: Reading file: 
/usr/share/hplip/data/models/models.dat
hp-config_usb_printer[29315]: debug: Searching for section [hp_laserjet_2200] 
in file /usr/share/hplip/data/models/models.dat
error: This is not a valid device

Now, the section name as in the config is actually `hp_laserjet_2200_series`.
If I manually edit the file and rename that section to `hp_laserjet_2200` it 
works:

# hp-config_usb_printer -ldebug 003:076
hp-config_usb_printer[29452]: debug: param=003:076
hp-config_usb_printer[29452]: debug: Cache miss: hp_laserjet_2200
hp-config_usb_printer[29452]: debug: Reading file: 
/usr/share/hplip/data/models/models.dat
hp-config_usb_printer[29452]: debug: Searching for section [hp_laserjet_2200] 
in file /usr/share/hplip/data/models/models.dat
hp-config_usb_printer[29452]: debug: Found section [hp_laserjet_2200] in file 
/usr/share/hplip/data/models/models.dat
hp-config_usb_printer[29452]: debug: 
Setting up device: hp:/usb/HP_LaserJet_2200?serial=00JPHGC19417

hp-config_usb_printer[29452]: debug: Done.


Cheers,
Tobias

- -- Package-specific info:
Saving output in log file: /ssdhome/ranma/hp-check.log

HP Linux Imaging and Printing System (ver. 3.21.2)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper 
dependencies are installed to successfully compile HPLIP.   

  
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball 
has the proper dependencies installed to successfully run.  


3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of the above cases (both compile- and run-time dependencies).   


  

Check types:


   
a. EXTERNALDEP - External Dependencies  


   
b. GENERALDEP - General Dependencies (required both at compile and run time)


   
c. COMPILEDEP - Compile time Dependencies   


   
d. [All are run-time checks]


   
PYEXT SCANCONF QUEUES PERMISSION


   

Status Types:
OK
MISSING 

Bug#984452: CVE-2021-20203

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-20203:
https://bugs.launchpad.net/qemu/+bug/1913873
https://bugs.launchpad.net/qemu/+bug/1890152
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07935.html

Cheers,
Moritz

Bug#984450: CVE-2021-20257

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-20257:
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03595.html

Cheers,
Moritz

Bug#984451: CVE-2021-20255

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-20255:
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html
https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Feepro100_stackoverflow1

Cheers,
Moritz

Bug#984449: CVE-2021-3392

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-3392
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00488.html
https://bugs.launchpad.net/qemu/+bug/1914236

Cheers,
Moritz

Bug#984448: CVE-2021-3416

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-3416:
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg07431.html
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg07484.html

Cheers,
Moritz

Bug#984446: CVE-2021-3420

[Moritz Muehlenhoff]

Source: newlib
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-3420 and also affects src:newlib:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=aa106b29a6a8a1b0df9e334704292cbc32f2d44e

Cheers,
Moritz

Bug#984447: CVE-2021-3419

[Moritz Muehlenhoff]

Package: qemu
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-3419:
https://bugs.launchpad.net/qemu/+bug/1910826
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg00010.html

Cheers,
Moritz

Bug#980963: dpkg: Please add ARC architecture

[Vineet Gupta]

On Wed, 3 Mar 2021 19:04:36 +0100 Helmut Grohne  wrote:
 > On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote:
 > > Any chances to get updates on this one some time soon?
 >
 > No. The triplet cannot be changed once added. Therefore, the addition is
 > often deferred. The absence of the triplet can easily be worked around.
 > A bootstrap can be prototyped already. A major missing piece though is
 > glibc 2.32 being packaged in Debian. That likely is a prerequisite for
 > resolving this bug.
 >
 > Things that often need architecture-specific support for a new
 > architecture include:
 > * guile-X.Y (cross support)
 > * libgc
 > * libxcrypt (symbols)
 > * nspr
 > * openssl (packaging)
 >
 > Are any of these fixed or confirmed working for arc?
 >
 > I suggest that you coordinate with Vineet Gupta as he is already working
 > on this.

The current WIP is at

https://github.com/foss-for-synopsys-dwc-arc-processors/rebootstrap.git

The deal breaker is glibc support since debian is at 2.31 while ARC port was 
merged in 2.32. So here we patch in the entire ARC port :-)

Bug#984445: unneeded dependency on python3-pip

[Matthias Klose]

Package: src:pypandoc
Version: 1.5+ds0-1
Severity: important

unneeded dependency on python3-pip. Please drop it.

Bug#984444: questionable dependency on python3-pip

[Matthias Klose]

Package: parsero
Version: 0.0+git20140929.e5b585a-4
Severity: important

questionable dependency on python3-pip. The httplib3 dependency is satisfied by
the Debian package dependency. There's no need to have the python3-pip 
dependency.

Bug#982712: tiledarray: FTBFS: gemm_helper.h:168:30: error: expected initializer before ‘const’

[Andrey Rahmatullin]

Control: -1 fixed-upstream

Looks like this was caused by an update of libmadness-dev. Feel free to
reassign this RC bug there, as it broke API compatibility when updated
from 0.10.1~gite4aa500e-10.1 to 0.10.1+git20200818.eee5fd9f-1:
 now #defines "MADNESS_RESTRICT" instead of "restrict".
This seems to be fixed upstream at
https://github.com/ValeevGroup/tiledarray/commit/dbb665cb5e400aeebc39be12d015981078eff72b


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#983605: dicomscope: Files missing from distribution

[Andreas Tille]

On Wed, Mar 03, 2021 at 05:44:15PM +, John Talbut wrote:
> Thank you sV3 and Andreas, this appears to be the problem.  I have
> recompiled the kernel with binfmt_misc and it now works.

Good to know,  I wonder whether we keep that bug open to write
a real wrapper and by doing so avoid this kind of issues.

Kind regards

  Andreas. 

-- 
http://fam-tille.de