Bug#993867: glewlwyd: possible buffer overflow on webauthn registration

2021-09-07 Thread Nicolas Mora
Package: glewlwyd
Version: 2.5.2-2
Severity: important
Tags: patch security
X-Debbugs-Cc: Debian Security Team 




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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 glewlwyd depends on:
ii  dbconfig-pgsql 2.0.19
ii  debconf [debconf-2.0]  1.5.77
pn  glewlwyd-common
ii  init-system-helpers1.60
ii  libc6  2.31-13
ii  libcbor0   0.5.0+dfsg-2
ii  libconfig9 1.5-0.4
ii  libcrypt1  1:4.4.18-4
ii  libgnutls303.7.1-5
pn  libhoel1.4 
pn  libiddawc0.9   
ii  libjansson42.13.1-1.1
ii  libldap-2.4-2  2.4.57+dfsg-3
ii  libnettle8 3.7.3-1
ii  liboath0   2.6.6-3
pn  liborcania2.1  
pn  librhonabwy0.9 
pn  libulfius2.7   
pn  libyder2.0 
ii  lsb-base   11.1.0
ii  sqlite33.34.1-3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

glewlwyd recommends no packages.

Versions of packages glewlwyd suggests:
--- a/src/scheme/webauthn.c
+++ b/src/scheme/webauthn.c
@@ -1530,7 +1530,7 @@
   gnutls_pubkey_t pubkey = NULL;
   gnutls_x509_crt_t cert = NULL;
   gnutls_datum_t cert_dat, data, signature, cert_issued_by;
-  unsigned char data_signed[200], client_data_hash[32], cert_export[32], 
cert_export_b64[64];
+  unsigned char * data_signed = NULL, client_data_hash[32], cert_export[32], 
cert_export_b64[64];
   size_t data_signed_offset = 0, client_data_hash_len = 32, cert_export_len = 
32, cert_export_b64_len = 0;
   
   if (j_error != NULL) {
@@ -1619,6 +1619,12 @@
 break;
   }
   
+  if ((data_signed = 
o_malloc(rpid_hash_len+client_data_hash_len+credential_id_len+cert_x_len+cert_y_len+2))
 == NULL) {
+y_log_message(Y_LOG_LEVEL_DEBUG, "check_attestation_fido_u2f - Error 
allocating data_signed");
+json_array_append_new(j_error, json_string("Internal error"));
+break;
+  }
+
   // Build bytestring to verify signature
   data_signed[0] = 0x0;
   data_signed_offset = 1;
@@ -1653,6 +1659,7 @@
   }
   
 } while (0);
+o_free(data_signed);
 
 if (json_array_size(j_error)) {
   j_return = json_pack("{sisO}", "result", G_ERROR_PARAM, "error", 
j_error);


Bug#993866: librhonabwy0.9: jwe cbc tag computation error and jws alg:none signature verification issue

2021-09-07 Thread Nicolas Mora
Package: librhonabwy0.9
Version: 0.9.13-3
Severity: important
Tags: patch




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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 librhonabwy0.9 depends on:
ii  libc6  2.31-13
ii  libgnutls303.7.1-5
ii  libjansson42.13.1-1.1
pn  liborcania2.1  
pn  libulfius2.7   
pn  libyder2.0 
ii  zlib1g 1:1.2.11.dfsg-2

librhonabwy0.9 recommends no packages.
--- a/src/jwe.c
+++ b/src/jwe.c
@@ -450,7 +450,7 @@
 memcpy(compute_hmac+hmac_size, al, 8);
 hmac_size += 8;
 
-if (!(res = gnutls_hmac_fast(mac, jwe->key, 16, compute_hmac, hmac_size, 
tag))) {
+if (!(res = gnutls_hmac_fast(mac, jwe->key, jwe->key_len/2, compute_hmac, 
hmac_size, tag))) {
   *tag_len = gnutls_hmac_get_len(mac)/2;
   ret = RHN_OK;
 } else {
--- a/src/jws.c
+++ b/src/jws.c
@@ -1268,9 +1268,6 @@
 case R_JWA_ALG_ES256K:
   ret = RHN_ERROR_UNSUPPORTED;
   break;
-case R_JWA_ALG_NONE:
-  ret = RHN_OK;
-  break;
 default:
   ret = RHN_ERROR_INVALID;
   break;
--- a/test/jws_core.c
+++ b/test/jws_core.c
@@ -496,7 +496,7 @@
   ck_assert_ptr_ne((token = r_jws_serialize(jws_sign, NULL, 0)), NULL);
   
   ck_assert_int_eq(r_jws_parse(jws_verify, token, 0), RHN_OK);
-  ck_assert_int_eq(r_jws_verify_signature(jws_verify, NULL, 0), RHN_OK);
+  ck_assert_int_eq(r_jws_verify_signature(jws_verify, NULL, 0), 
RHN_ERROR_INVALID);
   o_free(token);
   
   r_jws_free(jws_sign);


Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

2021-09-07 Thread Diederik de Haas
On dinsdag 7 september 2021 14:58:59 CEST Elena ``of Valhalla'' Grandi wrote:
> On 2021-09-06 at 22:58:54 +0200, Diederik de Haas wrote:
> > I wanted to print the Debian Social Contract, which turned out to be WAY
> > more difficult then I expected and then it should be.
> > [...]
> > Then I went looking for a PDF version and didn't find anything.
> 
> There is a PDF version in the Debian Flyers website:
> https://debian.pages.debian.net/debian-flyers/
> 
> only English, French and Italian are currently available, but the
> sources used to generate that PDF are on
> https://salsa.debian.org/debian/debian-flyers
> 
> would this be useful?
> 
> (I agree that making this easier to discover would be a good idea)

That looks nice! So yes, that is useful :-)

I wasn't aware of that site before, so discoverability can and should be 
improved.

Cheers,
  Diederik

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


Bug#993564: bullseye-pu: package dlt-viewer/2.21.2+dfsg-2+deb11u1

2021-09-07 Thread Jonathan Wiltshire
Control: tag -1 confirmed moreinfo

On Fri, Sep 03, 2021 at 08:48:41AM +0200, Gianfranco Costamagna wrote:
> Hello, for some reasons some headers in the -dev file were not
> installed, leading to an error in building external plugins.
> I opened RC: #993562 to track this issue, and I would like to fix also
> bullseye since the fix is trivial

I'm fine with this change, but your changelog doesn't mention the bug
number that it fixes and you uploaded a binary amd64 package with it. I'm
not bothered by the binary package but I do want the changelog fixed, so we
may as well do both.

You will receive a REJECT message from the archive. Once you have that,
please re-upload with the changelog updated and make it a source-only
upload. Then remove the wontfix tag from this request bug.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature


Bug#993118: buster-pu: package popper.js/1.16.1+ds-3+deb11u1

2021-09-07 Thread Jonathan Wiltshire
Control: tag -1 confirmed moreinfo

On Fri, Aug 27, 2021 at 03:58:38PM +0200, Yadd wrote:
> [ Changes ]
> Replace bad dir_to_symlink target

Not mentioned in this request is the change to debian/watch, and not in the
request nor changelog is copyright and uploaders chnages, but I can live
with that. 

Please go ahead and remove this bug's wontfix tag when uploaded.

Thanks,
-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature


Bug#993805: UDD: duplicate entries for the same release

2021-09-07 Thread Andreas Beckmann

I still find very odd that

 $ dak rm -Rn python-setuptools-scm

doesn't find anything though.  dak is obviously aware of the package...


You missed -b for binary packages:

$ dak rm -Rn -b python-setuptools-scm
Will remove the following packages from unstable:

python-setuptools-scm |4.1.2-3 | all

Maintainer: Debian Python Modules Team 



--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

A RM bug for manual cruft removal of this arch:all package should fix it ...

Andreas



Bug#993035: sabnzbdplus 3.1.1+dfsg-2+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 993035 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: sabnzbdplus
Version: 3.1.1+dfsg-2+deb11u1

Explanation: prevent directory escape in renamer function



Bug#993865: please enable CONFIG_MT7915E

2021-09-07 Thread Piotr Ożarowski
Package: src:linux
Version: 5.10.28-1
Severity: wishlist

Dear Maintainer,

Please enable CONFIG_MT7915E (MediaTek MT7915E (PCIe) support) - looks
like my new mini PCIe card needs this one.
5.14-1~exp2 from experimental doesn't have this one enabled as well

CONFIG_MT7915E was added in Linux 5.8

TIA



Bug#992563: transition: gdal

2021-09-07 Thread Sebastiaan Couwenberg
On 9/5/21 6:48 PM, Sebastian Ramacher wrote:
> On 2021-08-20 11:32:16 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
>> Control: forwarded -1 
>> https://release.debian.org/transitions/html/auto-gdal.html
>> Control: block -1 by 992527 992528
>>
>> For the Debian GIS team I'd like to transition to GDAL 3.3.1.
>>
>> Most reverse dependencies rebuilt successfully with GDAL 3.3.1 from
>> experimental as summarized below.
>>
>> libgdal-grass doesn't need a binNMU as the 3.3.1 version will be
>> uploaded to unstable instead.
> 
> Assuming that the version of pdal in experimental also builds fine
> against the new version of gdal, please go ahead and also start the pdal
> transition.

PDAL 2.3.0 also builds successfully with GDAL 3.3 so I'll upload that to
unstable once gdal is built on all release architectures. The gdal
upload to unstable had to wait a bit for 3.2.2+dfsg-3 to migrated to
testing to fix #993334 there too.

Kind Regards,

Bas

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



Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

2021-09-07 Thread Elena ``of Valhalla'' Grandi
On 2021-09-06 at 22:58:54 +0200, Diederik de Haas wrote:
> I wanted to print the Debian Social Contract, which turned out to be WAY
> more difficult then I expected and then it should be.
> [...]
> Then I went looking for a PDF version and didn't find anything.

There is a PDF version in the Debian Flyers website:
https://debian.pages.debian.net/debian-flyers/

only English, French and Italian are currently available, but the
sources used to generate that PDF are on
https://salsa.debian.org/debian/debian-flyers

would this be useful?

(I agree that making this easier to discover would be a good idea)

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature


Bug#993858: ocaml-dune: dune-install doesn't correctly place "doc" section in Debian systems

2021-09-07 Thread Stéphane Glondu
Hello,

Le 07/09/2021 à 12:27, Emilio Jesús Gallego Arias a écrit :
> dune-install will by default install files in the "doc" section to
> $prefix/doc, this is incorrect in Debian as it should be $share/doc.

I guess we are talking about people doing "sudo dune install", right? As
opposed to "dune install" being called during Debian package builds.

Installing arbitrary software this way (with root privileges) should not
be done IMHO, but if done, it must happen in /usr/local (or outside
/usr). I remember having trouble configuring dune correctly to do that
(I couldn't tell it to "dune install" into /usr/local, but still look
for libraries in /usr/lib/ocaml in "dune build".

It would be nice if dune had a notion of "profile": a default "local"
one that would use /usr/local directories, and a "debian" one, used only
for Debian package builds, that would use $destdir/usr and $destdir/etc.
While searching for libraries in all profiles ("local" first, then
"debian").

The "correct" path for the "doc" section in the "local" profile would be
/usr/local/share/doc.

> This creates problems for both users and developers.

What kind of problems?

> Dune >= 2.9 allows configuring the doc install path. For previous
> versions, this patch must be added:
> 
> diff --git a/src/dune_rules/install.ml b/src/dune_rules/install.ml
> index afa2acdad..9fd7e6779 100644
> --- a/src/dune_rules/install.ml
> +++ b/src/dune_rules/install.ml
> @@ -209,7 +209,7 @@ module Section = struct
>let libexec_root = libdir in
>let share_root = Path.relative destdir "share" in
>let etc_root = Path.relative destdir "etc" in
> -  let doc_root = Path.relative destdir "doc" in
> +  let doc_root = Path.relative share_root "doc" in
>{ lib_root
>; libexec_root
>; share_root

Patching things this way could (would, I think) break Debian package
builds. One has to check that all packages using dune (and there are a
lot of them now) still build with this patch. Maybe this could be done
during as part of an OCaml transition... To be continued.

> Note that a similar problem may exist for files in the "etc" section.

I am not really sure on how to handle the "etc" section. I would use
/etc directly, even for third-party software but /usr/local/etc exists
on the Internet, so maybe it would be better to use it in the "local"
profile.


Cheers,

-- 
Stéphane



Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

2021-09-07 Thread Vincent Lefevre
On 2021-09-07 13:31:36 +0200, Vincent Lefevre wrote:
[...]
> zsh-static is linked statically. What does it have to do with libc.so.6?
> If it expects some functions from libc.so.6 and others that had been
> linked statically, then with the upgrade of libc6 to 2.32-1, I think
> that this is likely to break.

Indeed, a rebuild solves the issue. My patch at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993861#15

may be needed due to a FTBFS if libncursesw5-dev is not installed
(now provided by libncurses-dev).

I suppose that the libc6 upgrade was the reason, though I didn't
do a test to check.

A rebuild doesn't really solve the bug, since at the next libc6
upgrade, a similar issue may occur. The use of libc.so.6 should
be removed completely. Now, I don't know whether the libc.so.6
is due to the build rules, binutils, or something else.

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



Bug#992527: node-srs: FTBFS with GDAL 3.3.1

2021-09-07 Thread Sebastiaan Couwenberg
Control: severity -1 serious

The gdal transition has started, raising the severity accordingly.

Kind Regards,

Bas

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



Bug#993861: FTBFS: dpkg-gencontrol: error: parsing package 'zsh-static'

2021-09-07 Thread Vincent Lefevre
Control: tags -1 patch

On 2021-09-07 14:15:08 +0200, Vincent Lefevre wrote:
> At 
> https://buildd.debian.org/status/fetch.php?pkg=zsh=amd64=5.8-7=1630542289=0
> (successful build on 2021-09-02), I can see:
> 
> dh_gencontrol -a -- -VBuilt-Using="libcap2 (= 1:2.44-1), ncurses (= 
> 6.2+20201114-4), ncurses (= 6.2+20201114-4), pcre3 (= 2:8.39-13), glibc (= 
> 2.31-17), "
> 
> Notice the duplicate "ncurses (= 6.2+20201114-4)". On my machine, the
> second one is replaced by " (= )", which yields the failure.
> 
> Moreover, debian/rules has
> 
> BUILT_USING=$(shell for pkg in libcap-dev libncurses-dev libncursesw5-dev 
> libpcre3-dev libc-dev-bin; do dpkg-query -f '$${status}' -W $$pkg 2>&1 | grep 
> -Fq installed && dpkg-query -f '$${source:Package} (= $${source:Version}), ' 
> -W $$pkg; done)
> 
> while on my machine, libncursesw5-dev is not installed and is provided
> by libncurses-dev.

I suppose that libncursesw5-dev should be replaced by libncurses-dev
in every file under the debian directory, and that the resulting
duplicates should be removed. I've attached the corresponding patch,
which solves the FTBFS issue for me.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -aurd zsh-5.8-a/debian/control zsh-5.8-b/debian/control
--- zsh-5.8-a/debian/control2021-08-25 00:25:11.0 +
+++ zsh-5.8-b/debian/control2021-09-07 12:17:57.521181547 +
@@ -10,7 +10,7 @@
libcap-dev [linux-any],
libelf-dev,
libgdbm-dev,
-   libncursesw5-dev,
+   libncurses-dev,
libpcre3-dev
 Build-Depends-Indep: cm-super-minimal,
  ghostscript,
diff -aurd zsh-5.8-a/debian/rules zsh-5.8-b/debian/rules
--- zsh-5.8-a/debian/rules  2021-08-24 23:44:06.0 +
+++ zsh-5.8-b/debian/rules  2021-09-07 12:16:59.009746260 +
@@ -50,7 +50,7 @@
 # resulting syntax might be invalid. Needed for packages which are
 # also provided by other packages like libncurses-dev and
 # libncursesw5-dev which both fulfil the according build-dependency.
-BUILT_USING=$(shell for pkg in libcap-dev libncurses-dev libncursesw5-dev 
libpcre3-dev libc-dev-bin; do dpkg-query -f '$${status}' -W $$pkg 2>&1 | grep 
-Fq installed && dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W 
$$pkg; done)
+BUILT_USING=$(shell for pkg in libcap-dev libncurses-dev libpcre3-dev 
libc-dev-bin; do dpkg-query -f '$${status}' -W $$pkg 2>&1 | grep -Fq installed 
&& dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $$pkg; done)
 
 %:
dh $@
diff -aurd zsh-5.8-a/debian/tests/control zsh-5.8-b/debian/tests/control
--- zsh-5.8-a/debian/tests/control  2021-08-24 23:50:41.0 +
+++ zsh-5.8-b/debian/tests/control  2021-09-07 12:17:38.993360527 +
@@ -2,7 +2,7 @@
 Depends: libcap-dev [linux-any],
  libelf-dev,
  libgdbm-dev,
- libncursesw5-dev,
+ libncurses-dev,
  libpcre3-dev,
  zsh,
  zsh-dev


Bug#993441: kleopatra: Creates unsafe ~/.gnupg when not already present

2021-09-07 Thread Diederik de Haas
On dinsdag 7 september 2021 11:32:28 CEST Peter Green wrote:
>  > Version: 4:21.08.0-1
> 
> You filed this against the version in sid? 

I run Sid as my daily driver, so yes. That's what I (almost?) always do.

> have you investigated whether earlier versions are also affected?

No, I did not.

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


Bug#993861: FTBFS: dpkg-gencontrol: error: parsing package 'zsh-static'

2021-09-07 Thread Vincent Lefevre
On 2021-09-07 13:51:28 +0200, Vincent Lefevre wrote:
> I've tried to rebuild zsh, and I get the following error:
> 
> [...]
> make[1]: Entering directory '/home/vinc17/tmp/zsh-5.8'
> dh_gencontrol -a -- -VBuilt-Using="libcap2 (= 1:2.44-1), ncurses (= 
> 6.2+20201114-4),  (= ), pcre3 (= 2:8.39-13), glibc (= 2.32-1), "
[...]

At 
https://buildd.debian.org/status/fetch.php?pkg=zsh=amd64=5.8-7=1630542289=0
(successful build on 2021-09-02), I can see:

dh_gencontrol -a -- -VBuilt-Using="libcap2 (= 1:2.44-1), ncurses (= 
6.2+20201114-4), ncurses (= 6.2+20201114-4), pcre3 (= 2:8.39-13), glibc (= 
2.31-17), "

Notice the duplicate "ncurses (= 6.2+20201114-4)". On my machine, the
second one is replaced by " (= )", which yields the failure.

Moreover, debian/rules has

BUILT_USING=$(shell for pkg in libcap-dev libncurses-dev libncursesw5-dev 
libpcre3-dev libc-dev-bin; do dpkg-query -f '$${status}' -W $$pkg 2>&1 | grep 
-Fq installed && dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W 
$$pkg; done)

while on my machine, libncursesw5-dev is not installed and is provided
by libncurses-dev.

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



Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

2021-09-07 Thread Diederik de Haas
On dinsdag 7 september 2021 11:26:15 CEST Gard Spreemann wrote:
> Diederik de Haas  writes:
> > I wanted to print the Debian Social Contract, which turned out to be WAY
> > more difficult then I expected and then it should be.
> > ...
> 
> Are any of these helpful? I'm happy to do more iterations – perhaps
> using LuaLaTeX and better fonts? This is so far just rushed lunch-work:
> 
> https://nonempty.org/~gspr/social.tex
> 
> https://nonempty.org/~gspr/social.pdf

I only looked at the pdf and it's a very nice start, thanks!

Couple of remarks, all in my opinion of course:
- I don't know if there is or should be different versions based on paper size 
(A4 vs US Letter).
- I like to have a header which is repeated on all pages and a footer which 
says "Page X of Y", so you know those (currently 3) pages belong together and 
know the sequence and how large it is in total.
In my LO Writer attempt, I had "Debian Social Contract" on the first page as 
header and "Debian Free Software Guidelines (DFSG)" on second, but I squeezed 
things to fit in those 2 pages. Probably not worth aiming for.
*If* there is an official location for the Social Contract, like 
https://www.debian.org/social_contract then I'd like to have that in the page 
header or footer as well.
- it's not in f.e. the web page, but I'd suggest the "Supersedes Version 1.0 
..." on a new line. This prevent the case where '1997' is on a line on it's 
own. It's all in 1 line on my printed version, but I decreased margins.
(Whether version history should be part of the document itself is a separate 
matter, so I'll leave that aside)
- the header "Debian will remain 100% free"* (f.e.) should be on its own line 
and I prefer it to be in "bold" or something like that to visually make a 
distinction between the header and the text.
- ideally an item of the Social Contract should fully on 1 page. The amount of 
white space on especially the first page is quite high and if that gets 
reduced, item 4 should fit on the first page as well. The amount of white space 
at the bottom of the pages seems rather high as well. It doesn't bug me, but 
if you want/need some extra lines to put text in, you could squeeze some from 
that. But not too much as some printers may then run into issues ;-)
It's possibly hard to realize this in a general case, but I assume doable for 
this specific document.
- the last part after "Example Licenses" is formatted differently on the 
website from the rest of the Social Contract and that seems correct.
The first paragraph gives some history. The 2nd shows a link between The Open 
Source Definition and the Social Contract. The 3rd looks like a kind of 
license? (without making it explicit; but also outside the scope of this bug)

Cheers,
  Diederik

*) when copying from the pdf the spaces around '100%' vanished, resulting in 
'remain100%free'

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


Bug#993863: ftp.debian.org: dak check-archive files-in-dsc and dak check-archive validate-builddeps crashes

2021-09-07 Thread Christian Marillat
Package: ftp.debian.org
Severity: normal
Usertags: dak

Hi,

This morning I was playing with dak check-archive, and see these two issues :

dak@christian ~ % dak check-archive validate-indices
Traceback (most recent call last):
  File "/usr/bin/dak", line 252, in 
main()
  File "/usr/bin/dak", line 231, in main
module.main()
  File "/usr/lib/python3/dist-packages/dak/check_archive.py", line 591, in main
check_indices_files_exist()
  File "/usr/lib/python3/dist-packages/dak/check_archive.py", line 456, in 
check_indices_files_exist
validate_packages(suite, component, arch)
  File "/usr/lib/python3/dist-packages/dak/check_archive.py", line 431, in 
validate_packages
% (Cnf["Dir::Root"], suite, component, architecture)
NameError: name 'Cnf' is not defined


dak@christian ~ % dak check-archive validate-builddeps
Traceback (most recent call last):
  File "/usr/bin/dak", line 252, in 
main()
  File "/usr/bin/dak", line 231, in main
module.main()
  File "/usr/lib/python3/dist-packages/dak/check_archive.py", line 595, in main
check_build_depends()
  File "/usr/lib/python3/dist-packages/dak/check_archive.py", line 501, in 
check_build_depends
os.path.walk(cnf["Dir::Root"], chk_bd_process_dir, None)
AttributeError: module 'posixpath' has no attribute 'walk'

Chirstian



Bug#963892: libruby2.7: circular dependency hell

2021-09-07 Thread Mikhail Krylov
I think this circular dependency causes a problem with debfoster: it
tries to remove vim-gtk3 (and, probably, any package that depends on
libruby2.7) if ruby is not set as a keeper.


signature.asc
Description: PGP signature


Bug#993862: ITP: avocado -- Framework for automated testing

2021-09-07 Thread Anton Mikanovich
Package: wnpp
Severity: wishlist
Owner: Avocado Debian package maintainers 

* Package name: avocado
  Version : 91.0
  Upstream Author : Red Hat, Cleber Rosa 
* URL : https://github.com/avocado-framework/avocado
* License : GPLv2+
  Programming Lang: Python
  Description : Framework for automated testing

Avocado is a next generation testing framework inspired by Autotest and modern 
development tools such as git.

It is a set of tools and libraries to help with automated testing. One can call 
it a test framework with benefits. Native tests are written in Python and they 
follow the unittest pattern, but any executable can serve as a test.

The main features are:
 * Multiple result formats (human-readable/xUnit/JSON/TAP)
 * Job Replay to reproduce a given job
 * Job Diff to compare several aspects of two given jobs
 * Plugin system for framework extension
 * Utility libraries to perform basic operations like process execution, system 
information obtain, package management, etc
 * Good documentation available: 
https://avocado-framework.readthedocs.io/en/latest

Current packaging state can be found at 
https://github.com/avocado-framework/avocado/tree/master/contrib/packages/debian

We plan to maintain it and need a sponsor for the upload.



Bug#993848: postgresql-13: A SELECT query with cursor can cause segmentation fault

2021-09-07 Thread Christoph Berg
Re: Tomas Barton
> a slightly sophisticated SELECT query with a CURSOR can lead to
> postgresql server segmentation fault.
> 
> LOG:  server process (PID 10722) was terminated by signal 11: Segmentation
> fault
> DETAIL:  Failed process was running: COMMIT

> I'll try to make an reproducable code, let me known if you need more
> information.
> 
> The query might be a bit nasty, but it shouldn't crash whole server.

Can you share the query and the schema?

Christoph



Bug#975191: [Pkg-rust-maintainers] Bug#975191: Bug#975191: re: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

2021-09-07 Thread Fabian Grünbichler
On August 31, 2021 9:16 pm, Wolfgang Silbermayr wrote:
> On 8/31/21 4:25 PM, Bastian Germann wrote:
>> On Wed, 2 Dec 2020 02:46:36 + peter green  wrote:
>>>  > This will impact quite some other modules.
>>>
>>> I agree that the current autoremoval list looks pretty scary, so I decided
>>> to do some
>>> dependency analysis. It seems there are 5 source packages with direct or
>>> indirect hard
>>> dependencies on rust-js-sys.
>>>
>>> rust-www-sys
>>> rust-ring
>>> rust-rustls
>>> rust-sct
>>> rust-webpki
>> 
>> Hey,
>> 
>> I would like to get rustls migrating to bookworm but this is a blocker for 
>> it.
>> Can you please state if you want to fix this or would like help with it? I
>> guess importing the current version will do it.
> 
> Hi Bastian,
> 
> I'd be happy to support getting rustls to migrate as well.
> 
> After taking a look, "just" updating rust-js-sys to the latest version also
> requires an update of the wasm-bindgen related crates to the latest version
> (which currently is 0.2.76 across all of them):
> 
> wasm-bindgen-shared
> wasm-bindgen-backend
> wasm-bindgen-macro-support
> wasm-bindgen-macro
> wasm-bindgen
> 
> I did a quick test run updating all of these, and it basically works, once
> `syn` got updated. For `syn`, we have an RFS note indicating that autopkgtests
> don't work yet with the updated version and need some other packages such as
> `insta` uploaded before. I didn't dig too deeply into that part, but we might
> need to invest some additional work here.
> 
> Within the wasm-bindgen* group, I also stumbled over a few autopkgtest 
> problems:
> 
> wasm-bindgen-macro-support has a few features that fail their tests, but I
> expect that these tests simply aren't intended to be run with only a single
> feature enabled. Would require some investigation and either fixing or marking
> them as broken. The rest of the tests succeeds.
> 
> wasm-bindgen-macro requires wasm-bindgen to be available for the autopkgtest,
> but it should be possible to handle that. In addition, it requires
> wasm-bindgen-futures 0.4, some more about that below.
> 
> wasm-bindgen requires js-sys 0.3 to be available for the autopkgtest, but
> again that can be handled.
> 
> js-sys requires wasm-bindgen-futures 0.4 for the autopkgtest as well.
> 
> Regarding wasm-bindgen-futures, that one has a dev dependency on
> futures-channel-preview in a 0.3 alpha version. We can basically handle that,
> but that crate received its last update about two years ago. At a quick look,
> it seems to be a bootstrapping crate that might be intended to be replaced by
> futures-channel which is available by now, but that didn't happen yet for
> whichever reason. Might be a topic to investigate upstream. That one pulls in
> futures-core 0.3, and thus requires an update of the futures ecosystem from
> 0.1 to 0.3 which by itself is a topic that is much larger than the
> wasm-bindgen topic that I describe here. There was already some preparation
> done by another team member, but I'm not sure when it was the last time
> somebody took a thorough look at what they prepared.

yeah, the -preview crates are relicts from a time when the futures/async 
stuff was not yet written in stone. they are all replaced by the 
non-preview version, in this case futures-channel. I plan on pushing 
forward the futures 0.3 (and related tokio 1.x and hyper/... ecosystems) 
update this fall, but it will be a process spanning months ;)

> 
> I'd love to work on untangling these issues, but once I start working on such
> a group of problematic packages, I usually discover blockers which stop my
> undertaking, and due to being a DM, I need a DD to either grant me upload
> access for the affected crates, or sponsor the upload for me, so it's quite
> tedious to finish such a group of packages, with all the inconveniences that
> come from the delays, such as packages failing to migrate for some time or
> autopkgtests failing until the required dependencies become available. If it
> was for me, we could go forward and upload the updates, but in the past it
> didn't take long until we collected many reports about failing or skipped
> autopkgtests.

the same applies to me modulo not even being a DM yet ;)

> That's what I can tell upfront from my quick evaluation, but speaking from
> experience, I'd expect some unforeseen roadblock to show up when working on 
> it.
> 
> I hope this quick analysis gives you some insight into the overall state, and
> some idea where and how you would like to proceed. In case you need some
> support working on a specific crate, let me know.
> 
> Best regards,
> Wolfgang.
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 



Bug#992739: fonts-courier-prime: Would it be possible to include Cyrillic?

2021-09-07 Thread Gürkan Myczko

Hello

I think it's absolutely possible, what's not clear about the user 
contributions is

though the licensing. I'd guess same as upstream, however not sure.

Best would probably someone create a repo for it for github.com (or as 
you
prefer somehwere else) and merge the user contributions to upstream 
version,

then tag releases.

If you feel like taking over the package and doing the work, please go 
ahead.

I'm also in #debian-fonts

Best,



Bug#993861: FTBFS: dpkg-gencontrol: error: parsing package 'zsh-static'

2021-09-07 Thread Vincent Lefevre
Source: zsh
Version: 5.8-7
Severity: serious
Tags: ftbfs

I've tried to rebuild zsh, and I get the following error:

[...]
make[1]: Entering directory '/home/vinc17/tmp/zsh-5.8'
dh_gencontrol -a -- -VBuilt-Using="libcap2 (= 1:2.44-1), ncurses (= 
6.2+20201114-4),  (= ), pcre3 (= 2:8.39-13), glibc (= 2.32-1), "
dpkg-gencontrol: warning: can't parse dependency (= )
dpkg-gencontrol: error: parsing package 'zsh-static' Built-Using field: libcap2 
(= 1:2.44-1), ncurses (= 6.2+20201114-4),  (= ), pcre3 (= 2:8.39-13), glibc (= 
2.32-1), 
dh_gencontrol: error: dpkg-gencontrol -pzsh-static -ldebian/changelog 
-Tdebian/zsh-static.substvars -Pdebian/.debhelper/zsh-static/dbgsym-root 
"-VBuilt-Using=libcap2 (= 1:2.44-1), ncurses (= 6.2+20201114-4),  (= ), pcre3 
(= 2:8.39-13), glibc (= 2.32-1), " -UPre-Depends -URecommends -USuggests 
-UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage 
-UImportant -UBuilt-Using -DAuto-Built-Package=debug-symbols -UProtected 
-DPackage=zsh-static-dbgsym "-DDepends=zsh-static (= \${binary:Version})" 
"-DDescription=debug symbols for zsh-static" 
-DBuild-Ids=fc897dcedd2f17176628f94b638cb9f863c547d2 -DSection=debug 
-UMulti-Arch -UReplaces -UBreaks returned exit code 25
dh_gencontrol: error: Aborting due to earlier error
make[1]: *** [debian/rules:169: override_dh_gencontrol-arch] Error 25
make[1]: Leaving directory '/home/vinc17/tmp/zsh-5.8'
make: *** [debian/rules:56: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed

This machine has glibc 2.32-1 and debhelper 13.5.1 (I don't know what
else could be related to this issue).

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture Description
+++--=--===
ii  bubblewrap   0.5.0-1   amd64utility for unprivileged chroot 
and namespace manipulation
ii  curl 7.74.0-1.3+b1 amd64command line tool for 
transferring data with URL syntax
ii  mercurial-common 5.9-3 all  easy-to-use, scalable 
distributed version control system (common files)
ii  meson0.59.1-1  all  high-productivity build system
ii  ninja-build  1.10.1-1  amd64small build system closest in 
spirit to Make
ii  pass 1.7.4-1   all  lightweight directory-based 
password manager
ii  pulseaudio   14.2-2amd64PulseAudio sound server
ii  qpdf 10.1.0-1  amd64tools for transforming and 
inspecting PDF files
ii  systemd  247.9-1   amd64system and service manager
ii  udev 247.9-1   amd64/dev/ and hotplug management 
daemon
ii  vlc-bin  3.0.16-1+b2   amd64binaries from VLC
ii  youtube-dl   2021.06.06-1  all  downloader of videos from 
YouTube and other sites

The following files were modified:

/etc/systemd/journald.conf
/etc/systemd/system.conf
/etc/systemd/logind.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

-- no debconf information

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



Bug#993860: public-inbox-imapd: missing dependency libparse-recdescent-perl

2021-09-07 Thread Nicolas Schier
Package: public-inbox
Version: 1.6.0-1
Severity: normal
X-Debbugs-Cc: nico...@fjasle.eu

Hi Uwe,

thanks for packaging public-inbox!  When I attempted to start
public-inbox-imapd, it failed:

$ public-inbox-imapd
Can't locate Parse/RecDescent.pm in @INC (you may need to install the 
Parse::RecDescent module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at 
/usr/share/perl5/PublicInbox/IMAPsearchqp.pm line 10.
BEGIN failed--compilation aborted at 
/usr/share/perl5/PublicInbox/IMAPsearchqp.pm line 10.
Compilation failed in require at /usr/share/perl5/PublicInbox/IMAP.pm line 
43.
BEGIN failed--compilation aborted at /usr/share/perl5/PublicInbox/IMAP.pm 
line 43.
Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/perl-base/base.pm line 135.
...propagated at /usr/lib/x86_64-linux-gnu/perl-base/base.pm line 157.
BEGIN failed--compilation aborted at 
/usr/share/perl5/PublicInbox/IMAPdeflate.pm line 10.
Compilation failed in require at /usr/bin/public-inbox-imapd line 8.
BEGIN failed--compilation aborted at /usr/bin/public-inbox-imapd line 8.

Installing libparse-recdescent-perl was enough on my system to solve the
issue.  Perhaps you might want to add it as dependency?

Kind regards,
Nicolas



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

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

Versions of packages public-inbox depends on:
ii  git1:2.30.2-1
ii  libdbd-sqlite3-perl1.66-1+b1
ii  libemail-mime-perl 1.949-1
ii  libnet-server-perl 2.009-2
ii  libplack-perl  1.0048-1
ii  libsearch-xapian-perl  1.2.25.4-1
ii  perl   5.32.1-4
ii  xapian-tools   1.4.18-3

public-inbox recommends no packages.

public-inbox suggests no packages.

-- no debconf information



Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

2021-09-07 Thread Vincent Lefevre
On 2021-09-07 12:23:38 +0200, Axel Beckert wrote:
> A first strace ends as follows:
> 
> mprotect(0x7f75ad335000, 4096, PROT_READ) = 0
> munmap(0x7f75ad337000, 327870)  = 0
> mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f75ad03a000
> openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 11
> fstat(11, {st_mode=S_IFREG|0644, st_size=526, ...}) = 0
> read(11, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 526
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe0} ---
> +++ killed by SIGSEGV (core dumped) +++

A more interesting part of the strace output:

[...]
223550 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) 
= 11
223550 read(11, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\177\2\0\0\0\0\0"..., 832) = 
832
223550 fstat(11, {st_mode=S_IFREG|0755, st_size=1839168, ...}) = 0
223550 mmap(NULL, 1852480, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 11, 0) = 
0x7f8847303000
223550 mprotect(0x7f8847329000, 1658880, PROT_NONE) = 0
223550 mmap(0x7f8847329000, 1347584, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0x26000) = 0x7f8847329000
223550 mmap(0x7f8847472000, 307200, PROT_READ, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0x16f000) = 0x7f8847472000
223550 mmap(0x7f88474be000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0x1ba000) = 0x7f88474be000
223550 mmap(0x7f88474c4000, 13376, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f88474c4000
223550 close(11)= 0
[...]

zsh-static is linked statically. What does it have to do with libc.so.6?
If it expects some functions from libc.so.6 and others that had been
linked statically, then with the upgrade of libc6 to 2.32-1, I think
that this is likely to break.

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



Bug#993045: Please bring back the -unsafe-string switch

2021-09-07 Thread Stéphane Glondu
Le 06/09/2021 à 11:01, Julien Puydt a écrit :
> The configure script checks for the availability of the switch, and
> adds it to OCAMLCFLAGS... I checked String.set doesn't seem to be used
> and String.blit only once, so perhaps there's something simple to do.
> 
> My current packaging is available here:
> https://salsa.debian.org/science-team/scilab

I've removed the check (patch attached), and the package builds with no
errors. I don't know how to check that everything works properly, though.


Cheers,

-- 
Stéphane
>From a2856e548fa6084c02d3b67205ca94c0b9177bf4 Mon Sep 17 00:00:00 2001
From: Stephane Glondu 
Date: Tue, 7 Sep 2021 12:51:42 +0200
Subject: [PATCH] Remove check for ocaml's -unsafe-string

---
 scilab/m4/ocaml.m4 | 12 
 1 file changed, 12 deletions(-)

diff --git a/scilab/m4/ocaml.m4 b/scilab/m4/ocaml.m4
index f25e10a08..11323c8a6 100644
--- a/scilab/m4/ocaml.m4
+++ b/scilab/m4/ocaml.m4
@@ -23,22 +23,10 @@ AC_DEFUN([AC_CHECK_PROG_OCAML],[
 	if test "$OCAMLC" = no; then
 		AC_MSG_ERROR([ocamlc not found. Mandatory to build the Scicos modelica compiler (Use --without-modelica to disable the Modelica compiler).])
 	fi
-	# since ocaml 4.06, unsafe string is no more the default parameter ; enforce it
-"$OCAMLC" -unsafe-string
-	if test "$?" -ne "0"; then
-		AC_MSG_WARN([ocamlc does not support "-unsafe-string". Needed to build the Scicos modelica compiler (Use --without-modelica to disable the Modelica compiler).])
-	fi
-OCAMLCFLAGS="$OCAMLCFLAGS -unsafe-string"
 	AC_CHECK_PROG(OCAMLOPT,ocamlopt,ocamlopt,no)
 	if test "$OCAMLOPT" = no; then
 		AC_MSG_ERROR([ocamlopt not found. Mandatory to build the Scicos modelica compiler.])
 	fi
-	# since ocaml 4.06, unsafe string is no more the default parameter ; enforce it
-"$OCAMLOPT" -unsafe-string
-	if test "$?" -ne "0"; then
-		AC_MSG_WARN([ocamlc does not support "-unsafe-string". Needed to build the Scicos modelica compiler (Use --without-modelica to disable the Modelica compiler).])
-	fi
-OCAMLOPTFLAGS="$OCAMLOPTFLAGS -unsafe-string"
 	AC_CHECK_PROG(OCAMLDEP,ocamldep,ocamldep,no)
 	if test "$OCAMLDEP" = no; then
 		AC_MSG_ERROR([ocamldep not found. Mandatory to build the Scicos modelica compiler.])
-- 
2.33.0



Bug#993843: zsh-static segfaults immediately

2021-09-07 Thread Vincent Lefevre
Control: found -1 5.8-6

I also get a crash with zsh-static 5.8-6+b2 on one of my machines:

zira:~> /bin/zsh-static -f
zsh: segmentation fault (core dumped)  /bin/zsh-static -f

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



Bug#982147: Test case for libmgba-dev

2021-09-07 Thread Sébastien Noel

Hi !

Le 2021-09-04 21:17, Ryan Tandy a écrit :

Hello,

I'm working on the libmgba-dev package. Can either of you share a link
to a project or test case that I can use to test it? or would either
of you be willing to test the package if I push the changes (or a repo
of built packages) somewhere?


Sorry, no easy test-case to share with you, but I can test
your WIP packages against a local modified Dolphin build.

br,
Sébastien



Bug#993843: zsh-static segfaults immediately

2021-09-07 Thread David
Package: zsh-static
Version: 5.8-7
Severity: important

Dear Maintainer,

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

I recently upgraded zsh-static:amd64 from 5.8-6+b2 to 5.8-7.

With version 5.8-7, /bin/zsh-static segfaults immediately upon execution.  The 
previous 5.8-6+b2 version was fine.

Here is an example attempt to run zsh-static:

  tensor(pts/3):~> /bin/zsh-static
  zsh: segmentation fault /bin/zsh-static 
  tensor(pts/3):~> echo $?
  139

A side effect of this is that any user relying on zsh-static as their login 
shell cannot login via ssh any more, since their shell immediately crashes.


-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture Description
+++--=--===
ii  bubblewrap   0.5.0-1   amd64utility for unprivileged chroot 
and namespace manipulation
ii  curl 7.74.0-1.3+b1 amd64command line tool for 
transferring data with URL syntax
ii  mercurial-common 5.9-3 all  easy-to-use, scalable 
distributed version control system (common files)
ii  systemd  247.9-1   amd64system and service manager
ii  udev 247.9-1   amd64/dev/ and hotplug management 
daemon

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh-static depends on:
ii  zsh  5.8-7

zsh-static recommends no packages.

Versions of packages zsh-static suggests:
pn  zsh-doc  

-- no debconf information



Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

2021-09-07 Thread Aurelien Jarno
Hi,

On 2021-09-07 10:39, Michael Hudson-Doyle wrote:
> On Tue, 7 Sept 2021 at 10:21, Michael Biebl  wrote:
> 
> > Am 06.09.21 um 23:45 schrieb Vincent Bernat:
> >  > Package: systemd
> >  > Version: 247.9-1
> >  > Severity: normal
> >  >
> > > Hey!
> > >
> > > After upgrading to libc6 2.32-1, some services are unable to restart.
> > > In my case, systemd-resolved, systemd-timesyncd and colord. Using
> > > "systemctl daemon-reexec" fixes the issue. Unsure if there is really
> > > something to be fixed but as I didn't find anything about that, a bug
> > > report may help others. I suppose the problem is related to NSS.
> > >
> > > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
> > Synchronization...
> > > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> > Failed to determine user credentials: No such process
> > > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> > Failed at step USER spawning /lib/systemd/systemd-timesyncd: No such process
> > >
> > >
> >
> >
> > @libc maintainers: any ideas what could be causing this? If this is
> > triggered by a libc6 update, should this be reassigned to glibc?
> >
> 
> We went through this in Ubuntu recently and decided that restarting systemd
> in glibc's postinst was the safest option:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276
> 
> What's happening is that systemd is running with the old glibc, forks and
> then does NSS things that cause the new glibc's NSS modules to load and
> they don't necessarily work, leading to failures in any unit that specifies
> User=. At least for Ubuntu's builds the NSS modules seem to be ABI
> compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they are
> definitely not between 2.33 and 2.34.

Thanks for this feedback and the pointer to the patch used in Ubuntu. It
seems to be a good solution, and matches what is done for other init
systems.

On the other hand, the problem is supposed to only happen for major
glibc version upgrade where the NSS modules might have a different ABI.
In that regard, I would be tempted to restart it only for major versions
upgrade like it's done for other daemons. Now if the systemd maintainers
consider it's fine restarting it for each glibc upgrade, we should
probably go that way.

Regards,
Aurelien

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



Bug#993859: linux-image-5.10.0-8-armmp: HDMI audio playback broken on i.MX6 HummingBoard

2021-09-07 Thread Josua Mayer
Package: src:linux
Version: 5.10.46-4
Severity: normal
X-Debbugs-Cc: josua.maye...@gmail.com

Dear Maintainer,

During testing I found that audio playback to the HDMI port produces just loud 
noise. I was playing the amarok jingle as a test:
ogg123 -d alsa -o dev:dmix:CARD=DWHDMI first_run_jingle.ogg

Hopefully I'll find some time to investiaget - find a point where it still 
worked, and bisect.

Sincerely
Josua Mayer

This worked previously, but I can put my finger on when exactly. CVhanges since 
then:
-- Package-specific info:
** Version:
Linux version 5.10.0-8-armmp (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
  console=ttymxc0,115200 deferred_probe_timeout=10 ahci_imx.hotplug=1 
log_level=7 net.ifnames=0 cma=128M

** Tainted: WCE (9728)
 * kernel issued warning
 * staging driver was loaded
 * unsigned module was loaded

** Kernel log:
[   12.069422] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[   12.096480] systemd[1]: Reached target Local Encrypted Volumes.
[   12.120468] systemd[1]: Reached target Paths.
[   12.140339] systemd[1]: Reached target Remote File Systems.
[   12.160262] systemd[1]: Reached target Slices.
[   12.176432] systemd[1]: Reached target Swap.
[   12.193295] systemd[1]: Listening on fsck to fsckd communication Socket.
[   12.216699] systemd[1]: Listening on initctl Compatibility Named Pipe.
[   12.241412] systemd[1]: Listening on Journal Audit Socket.
[   12.265183] systemd[1]: Listening on Journal Socket (/dev/log).
[   12.289322] systemd[1]: Listening on Journal Socket.
[   12.318746] systemd[1]: Listening on udev Control Socket.
[   12.341053] systemd[1]: Listening on udev Kernel Socket.
[   12.365221] systemd[1]: Condition check resulted in Huge Pages File System 
being skipped.
[   12.379484] systemd[1]: Mounting POSIX Message Queue File System...
[   12.416554] systemd[1]: Mounting Kernel Debug File System...
[   12.461157] systemd[1]: Mounting Kernel Trace File System...
[   12.502351] systemd[1]: Starting Create list of static device nodes for the 
current kernel...
[   12.537094] systemd[1]: Starting Load Kernel Module configfs...
[   12.569557] systemd[1]: Starting Load Kernel Module drm...
[   12.601128] systemd[1]: Starting Load Kernel Module fuse...
[   12.672399] systemd[1]: Condition check resulted in Set Up Additional Binary 
Formats being skipped.
[   12.711060] fuse: init (API version 7.32)
[   12.726776] systemd[1]: Starting File System Check on Root Device...
[   12.768988] systemd[1]: Starting Journal Service...
[   12.818378] systemd[1]: Starting Load Kernel Modules...
[   12.866644] systemd[1]: Starting Coldplug All udev Devices...
[   12.981618] systemd[1]: Mounted POSIX Message Queue File System.
[   13.014393] systemd[1]: Mounted Kernel Debug File System.
[   13.068936] systemd[1]: Mounted Kernel Trace File System.
[   13.115109] systemd[1]: Finished Create list of static device nodes for the 
current kernel.
[   13.159261] systemd[1]: modprobe@configfs.service: Succeeded.
[   13.185653] systemd[1]: Finished Load Kernel Module configfs.
[   13.226694] systemd[1]: modprobe@drm.service: Succeeded.
[   13.248464] systemd[1]: Finished Load Kernel Module drm.
[   13.286712] systemd[1]: modprobe@fuse.service: Succeeded.
[   13.310263] systemd[1]: Finished Load Kernel Module fuse.
[   13.351342] systemd[1]: Finished File System Check on Root Device.
[   13.395286] systemd[1]: Finished Load Kernel Modules.
[   13.448559] systemd[1]: Mounting FUSE Control File System...
[   13.494279] systemd[1]: Mounting Kernel Configuration File System...
[   13.554210] systemd[1]: Started File System Check Daemon to report status.
[   13.610566] systemd[1]: Starting Remount Root and Kernel File Systems...
[   13.682070] systemd[1]: Starting Apply Kernel Variables...
[   13.754329] systemd[1]: Mounted FUSE Control File System.
[   13.823376] systemd[1]: Mounted Kernel Configuration File System.
[   13.927190] systemd[1]: Finished Apply Kernel Variables.
[   13.932734] EXT4-fs (mmcblk1p1): re-mounted. Opts: (null)
[   13.982485] systemd[1]: Started Journal Service.
[   14.285169] systemd-journald[170]: Received client request to flush runtime 
journal.
[   14.329445] systemd-journald[170]: File 
/var/log/journal/2ebf67f9996a43629433b9fd557084ee/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[   16.708767] random: crng init done
[   16.712184] random: 7 urandom warning(s) missed due to ratelimiting
[   17.413602] Registered IR keymap rc-empty
[   17.500182] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[   17.513362] imx-ipuv3 240.ipu: IPUv3H probed
[   17.588254] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, 
raw IR receiver, no transmitter
[   17.764881] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input0
[   17.871183] 

Bug#993856: [Pkg-libvirt-maintainers] Bug#993856: libvirt-daemon-system: vfio device passthrough fails with device pools due to apparmor profile

2021-09-07 Thread Vasudev Kamath


Hi Again,

Vasudev Kamath  writes:
>
> And the network configuration in libvirt domain looks like below
>
> 
>   
>   
>   
>function='0x0'/>
> 
>
> When I start the domain even though domain starts fine VF pass through does 
> not happen and the following
> message is seen in the dmesg output
>
> [11236.601474] audit: type=1400 audit(1630925018.676:49): apparmor="DENIED" 
> operation="open" profile="libvirt-e70e9c2c-110c-401c-982f-cb384d158471" 
> name="/dev/vfio/315" pid=5929 comm=43505520382F4B564D requested_mask="wr" 
> denied_mask="wr" fsuid=64055 ouid=64055
>
> and passthrough does not happen.

Just  wanted to add that this failure happens only with device pool
pass through which is handled by the libvirt. [1]. Normal hostdev pass
through which looks like below works just fine and apparmor does not
cause issue in this case.


  
  

  
  
  



[1] https://libvirt.org/formatnetwork.html

Best Regards,
Vasudev



Bug#993858: ocaml-dune: dune-install doesn't correctly place "doc" section in Debian systems

2021-09-07 Thread Emilio Jesús Gallego Arias
Source: ocaml-dune
Version: 2.7.1-2
Severity: important

Dear OCaml Maintainers,

dune-install will by default install files in the "doc" section to
$prefix/doc, this is incorrect in Debian as it should be $share/doc.

This creates problems for both users and developers.

Dune >= 2.9 allows configuring the doc install path. For previous
versions, this patch must be added:

diff --git a/src/dune_rules/install.ml b/src/dune_rules/install.ml
index afa2acdad..9fd7e6779 100644
--- a/src/dune_rules/install.ml
+++ b/src/dune_rules/install.ml
@@ -209,7 +209,7 @@ module Section = struct
   let libexec_root = libdir in
   let share_root = Path.relative destdir "share" in
   let etc_root = Path.relative destdir "etc" in
-  let doc_root = Path.relative destdir "doc" in
+  let doc_root = Path.relative share_root "doc" in
   { lib_root
   ; libexec_root
   ; share_root

Note that a similar problem may exist for files in the "etc" section.

Kind regards,
Emilio

-- 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-81-lowlatency (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

2021-09-07 Thread Axel Beckert
Control: tag -1 + confirmed
Control: severity serious

Hi David,

David wrote:
> I recently upgraded zsh-static:amd64 from 5.8-6+b2 to 5.8-7.
> 
> With version 5.8-7, /bin/zsh-static segfaults immediately upon
> execution.  The previous 5.8-6+b2 version was fine.

Thanks for the bug report! Can reproduce and confirm it.

Sorry for the trouble. I (and the tests) admittedly only test the
non-static zsh. And except for some special lookups known to be not
possible with static compiled binaries, I also don't expect any
difference in functionality with zsh-static.

A first strace ends as follows:

mprotect(0x7f75ad335000, 4096, PROT_READ) = 0
munmap(0x7f75ad337000, 327870)  = 0
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f75ad03a000
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=526, ...}) = 0
read(11, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 526
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe0} ---
+++ killed by SIGSEGV (core dumped) +++

Then again, according to the same strace run, it read
/etc/nsswitch.conf beforehand and didn't segfault there, so it's
likely not that file. Additionally I don't see anything unexpected or
weird in it.

Additionally there are no changes in or new patches against zsh's code
between 5.8-6 and 5.8-7, just packaging changes: Updated packaging
documentation, removal of ancient conflicts and changes how
documentation is distributed over zsh-common and zsh-doc.

So I suspect a change in another package to be the culprit. The big
question is: Which package? Maybe one related to nsswitch.conf.

So far for a first look at this issue...

> A side effect of this is that any user relying on zsh-static as
> their login shell cannot login via ssh any more, since their shell
> immediately crashes.

Of course.

Unfortunately I won't be able to debug this in detail for a few days
due to travelling. But I'll have a closer look into it at the end of
this week.

There's a new upload of zsh planned anyway, although so far due to
less severe (and more long-standing) issues.

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



Bug#993857: gnupg2: Please remove librsvg2-bin from BD

2021-09-07 Thread Laurent Bigonville
Source: gnupg2
Version: 2.2.27-2
Severity: important

Hello,

Having librsvg2-bin in the build-dependencies prevent the package to
build on some architecture (librsvg only builds on architecutres where
rust is ported to)

Could you please drop librsvg2-bin from the build-dependencies?

The BD was added in the following commit:

commit 90e4beaa8cb065d5964681b8b1dc72c84eeb5f9e
Author: Daniel Kahn Gillmor 
Date:   Tue May 10 21:31:12 2016 -0400

build gnupg-module-overview.png and ship it

Upstream uses imagemagick for conversion of svg to png, and
imagemagick itself appears to delegate to  rsvg-convert

But what I see is that the .png file is not rebuilt during the build of
the package and I don't know if imagemagick is still using rsvg-convert
anyway, so, is it really necessary to have that BD?

Without it, gnupg builds fine on kfreebsd

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy



Bug#993856: libvirt-daemon-system: vfio device passthrough fails with device pools due to apparmor profile

2021-09-07 Thread Vasudev Kamath
Package: libvirt-daemon-system
Version: 7.6.0-1
Severity: important

Dear Maintainer,

Possibly related bug [1]. Issue is similar to what is explained in this bug 
but is not addressed by the fix which is already present in src:libvirt 7.6 
version.

PS: Though I reporting from unstable machine actual test was done using libvirt 
7.6 
from unstable built for Bullseye. 

I'm defining the network device pool which looks like below


  passthrough
  f152e522-96d1-4a74-8aae-01f94244f8df
  
















  


And the network configuration in libvirt domain looks like below


  
  
  
  


When I start the domain even though domain starts fine VF pass through does not 
happen and the following
message is seen in the dmesg output

[11236.601474] audit: type=1400 audit(1630925018.676:49): apparmor="DENIED" 
operation="open" profile="libvirt-e70e9c2c-110c-401c-982f-cb384d158471" 
name="/dev/vfio/315" pid=5929 comm=43505520382F4B564D requested_mask="wr" 
denied_mask="wr" fsuid=64055 ouid=64055

and passthrough does not happen.

Note that this does not happen if the device pool interface is not present 
during start of domain and hot
attached using below command

sudo virsh attach-device --live --config debian10 network-pool-debian10.xml

To get the above working here is what I did I edited the 
/etc/apparmor.d/libvirt/libvirt-e70e9c2c-110c-401c-982f-cb384d158471 to
add line /dev/vfio/vfio rw, and this is what the changed file looks like

iaas@515-2102020016:~$ sudo cat 
/etc/apparmor.d/libvirt/libvirt-e70e9c2c-110c-401c-982f-cb384d158471
#
# This profile is for the domain whose UUID matches this file.
#

#include 

profile libvirt-e70e9c2c-110c-401c-982f-cb384d158471 
flags=(attach_disconnected) {
  #include 
  #include 
  #
  # for vfio hotplug on systems without static vfio (LP: #1775777)
  /dev/vfio/vfio rw,
}

Post the change I did following

sudo aa-teardown
sudo systemctl restart libvirtd
sudo systemctl restart apparmor

And on the next start device passthrough happens. I'm not sure if what I did is 
right but this seems to work
and I would be happy to see this done in the apparmor profile shipped by 
libvirt.

PS: I'm noob with apparmor all I did was bit of experiment to get the things 
working for my usecase.

If any other information is needed from my side please let me know.


[1] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1775777


Thanks and Regards,
Vasudev

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  gettext-base0.21-4
ii  iptables1.8.7-1
ii  libvirt-clients 7.6.0-1
ii  libvirt-daemon  7.6.0-1
ii  libvirt-daemon-config-network   7.6.0-1
ii  libvirt-daemon-config-nwfilter  7.6.0-1
ii  libvirt-daemon-system-systemd   7.6.0-1
ii  logrotate   3.18.1-2
ii  policykit-1 0.105-31

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.3-3
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.13.0-2
ii  mdevctl  0.81-1
ii  parted   3.4-1

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.6-10
pn  auditd  
ii  nfs-common  1:1.3.4-6
ii  open-iscsi  2.1.3-5
pn  pm-utils
ii  radvd   1:2.18-3
ii  systemd 247.9-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'

-- debconf information:
  libvirt-daemon-system/id_warning: true



Bug#993839: thunderbird: vary bad look in high dpi screen; tiny fonts and icons

2021-09-07 Thread Andrei L
Package: thunderbird
Version: 1:78.12.0-1
Severity: normal
X-Debbugs-Cc: 507...@mail.ru

Dear Maintainer,

my screen dpi is 160, and the thunderbird in debian 11 looks terrible ... tears 
of eyes due to tiny fonts and icons ...


Note that it's allright with thunderbird fonts in suse thumbleweed linux with 
high dpi screen ...

How to correct this?  

WBR,
Andrei L

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

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

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-7
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1
ii  hunspell-ru [hunspell-dictionary] 1:7.1.0~rc3-3

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-6
ii  libgtk2.0-0   2.24.33-2

-- no debconf information



Bug#993838: sane-utils: fails to detect scanner w/o root privileges; the user is in scanner group

2021-09-07 Thread Jörg Frings-Fürst
Hello Andrei,

please add as root the file

/usr/lib/udev/rules.d/99-libsane1.rules

with the context 

ENV{DEVNAME}!="", ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m 
g:scanner:rw $env{DEVNAME}"

then reboot. And tell me if the error is fixed with it.

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.


Am Dienstag, dem 07.09.2021 um 12:11 +0700 schrieb Andrei L:
> Package: sane-utils
> Version: 1.0.31-4.1
> Severity: normal
> X-Debbugs-Cc: 507...@mail.ru
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
> I add myself to the scanner group and plug the scanner to the usb
> port.
> 
> (scanner:x:119:saned,andrei )
> 
> Then, I try
> 
> $ sane-find-scanner
> 
>   # sane-find-scanner will now attempt to detect your scanner. If the
>   # result is different from what you expected, first make sure your
>   # scanner is powered up and properly connected to your computer.
> 
>   # No SCSI scanners found. If you expected something different, make
> sure that
>   # you have loaded a kernel SCSI driver for your SCSI adapter.
> 
> could not open USB device 0x8087/0x0024 at 003:002: Access denied
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 003:001: Access denied
> (insufficient permissions)
> could not open USB device 0x046d/0xc33a at 001:004: Access denied
> (insufficient permissions)
> could not open USB device 0x062a/0x4101 at 001:003: Access denied
> (insufficient permissions)
> could not open USB device 0x8087/0x0024 at 001:002: Access denied
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 001:001: Access denied
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0003 at 004:001: Access denied
> (insufficient permissions)
> could not open USB device 0x07b3/0x1300 at 002:002: Access denied
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 002:001: Access denied
> (insufficient permissions)
>   # No USB scanners found. If you expected something different, make
> sure that
>   # you have loaded a kernel driver for your USB host controller and
> have setup
>   # the USB system correctly. See man sane-usb for details.
> 
>   # Not checking for parallel port scanners.
> 
>   # Most Scanners connected to the parallel port or other proprietary
> ports
>   # can't be detected by this program.
> 
>   # You may want to run this program as root to find all devices.
> Once you
>   # found the scanner devices, be sure to adjust access permissions
> as
>   # necessary.
> 
> So it fails.
> 
> Then I log in with root privileges and try
> 
> # sane-find-scanner
> 
>   # sane-find-scanner will now attempt to detect your scanner. If the
>   # result is different from what you expected, first make sure your
>   # scanner is powered up and properly connected to your computer.
> 
>   # No SCSI scanners found. If you expected something different, make
> sure that
>   # you have loaded a kernel SCSI driver for your SCSI adapter.
> 
> found USB scanner (vendor=0x07b3 [PLUSTEK INC], product=0x1300
> [USB2.0 SCANNER], chip=GL845) at libusb:002:002
>   # Your USB scanner was (probably) detected. It may or may not be
> supported by
>   # SANE. Try scanimage -L and read the backend's manpage.
> 
>   # Not checking for parallel port scanners.
> 
>   # Most Scanners connected to the parallel port or other proprietary
> ports
>   # can't be detected by this program.
> 
> 
> So it is successfully detected.
> 
> What is wrong in debian 11 bullseye system settings ?
> 
> WBR,
> Andrei L
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sane-utils depends on:
> ii  adduser    3.118
> ii  debconf [debconf-2.0]  1.5.77
> ii  init-system-helpers    1.60
> ii  libavahi-client3   0.8-5
> ii  libavahi-common3   0.8-5
> ii  libc6  2.31-13
> ii  libieee1284-3  0.2.11-14
> ii  libjpeg62-turbo    1:2.0.6-4
> ii  libpng16-16    1.6.37-3
> ii  libsane1   1.0.31-4.1
> ii  libsystemd0    247.3-6
> ii  libusb-1.0-0   2:1.0.24-3
> ii  

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

2021-09-07 Thread Lucas Nussbaum
On 03/09/21 at 08:04 -0700, Felix Lechner wrote:
> Hi,
> 
> On Fri, Sep 3, 2021 at 7:50 AM Tobias Frost  wrote:
> >
> > But as said earlier: This is not a license issue; the license of GNU 
> > parallel
> > would allow removal, but this would make upstream sad.
> > The status quo is likely to mke our users sad, though.
> 
> Maybe the debconf system can provide a choice? The default could be
> consistent with Debian's standards.

I like this idea. It would allow organizations to install GNU parallel
with --will-cite disabled, but instead mention the "please cite" request
in user documentation.

Lucas



Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

2021-09-07 Thread Lucas Nussbaum
On 06/09/21 at 20:56 +0200, Ole Tange wrote:
> On Fri, Sep 3, 2021 at 5:05 PM Felix Lechner  
> wrote:
> > On Fri, Sep 3, 2021 at 7:50 AM Tobias Frost  wrote:
> > >
> > > But as said earlier: This is not a license issue; the license of GNU 
> > > parallel
> > > would allow removal, but this would make upstream sad.
> > > The status quo is likely to mke our users sad, though.
> 
> Maybe it would help if the consequences were explained to them:
> 
> * Do you want the software with no citation notice and risk that the
> maintainer will step down because he cannot afford spending time on it
> - thus getting less free software in the long run?
> * Or do you want to spend the 10 seconds it takes to silence the
> notice if you don't want to see it?
> 
> The ultimate goal has never been to have a license notice. The goal is
> to make it possible for me to spend time developing free software. In
> practice this means either pay my salary or have GNU Parallel cited,
> so it is easier for me to get a job that pays my salary.
> 
> It is unlikely that the Debian project will provide my salary, so let
> us focus on the second part.
> 
> Before the license notice was implemented researchers forgot to cite
> GNU Parallel; not because they did not want to honor the tradition,
> but simply because they forgot. The citation notice changed this for
> the better.
> 
> If there is a different way that will ensure researchers will not
> forget, it would be acceptable to me.

It is common for scientific tools or research infrastructures to provide
a "how to cite" section in their documentation. This is not a problem:
when researchers freely determine that they should cite something (for
example to provide the necessary context for their work) it's a good
idea to help them do that. See for example
https://www.open-mpi.org/papers/

Alternatively, infrastructures (and funding organizations) often require
an acknowledgement in publications. See for example
https://prace-ri.eu/hpc-access/project-access/project-access-information-for-awarded-projects/

However GNU parallel goes much further than that, because:
(1) the wording almost requires citation
(2) it does so by providing a version-specific citation, not a generic
one. In the past, it was asking to cite:
O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
;login: The USENIX Magazine, February 2011:42-47.
(This publication attracted 939 citations according to Google Scholar)
But now it asks to cite (in the current development version):

  @software{tange_2021_5233953,
author   = {Tange, Ole},
title= {GNU Parallel 20210822 ('Kabul')},
month= Aug,
year = 2021,
note = {{GNU Parallel is a general parallelizer to run
 multiple serial command line programs in parallel
 without changing them.}},
publisher= {Zenodo},
doi  = {10.5281/zenodo.5233953},
url  = {https://doi.org/10.5281/zenodo.5233953}
  }

In a way, this is a way to manipulate metrics such as h-index, by
artificially generating several entries that will collect some
citations.

It is also marginally an abuse of the Zenodo archive: Zenodo provides a
way to track versions for the same software or dataset (see for example the
Versions box in https://zenodo.org/record/5458943). GNU parallel uses
different records, as if each version was different software. (I'm not
sure if this is done by mistake or also serves the purpose of generating
different entries to accumulate citations)

Thus while asking users to acknowledge their use of GNU Parallel in
publications would be totally OK, My personal opinion is that this goes
too far (and might also be ethically questionable). With a wrong eye,
one could even see it as extortion/blackmail.

Lucas



Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

2021-09-07 Thread Gard Spreemann

Diederik de Haas  writes:

> I wanted to print the Debian Social Contract, which turned out to be WAY
> more difficult then I expected and then it should be.
>
> So I went to https://www.debian.org/social_contract and wanted to print
> that. Apparently there isn't a print stylesheet for it, so if you print
> that, you also get 'Blog', 'Micronews', 'Planet' and a search box.
> Of course I didn't mind the Debian logo.
> The last page (of the print preview) shows that it's available in a whole
> bunch of languages, which is good, but undesirable for a print version. 
> And then you get a bunch of links, also undesirable for a print version.
>
> Then I went looking for a PDF version and didn't find anything.
>
> I did find a 'social-contract.txt.gz' (why compressed?), but that's
> missing any form of nice formatting (that the webpage does have).
> I did try 'zcat ' and editing that in
> LibreOffice Writer, but apparently I've lost my skills in office
> programs, so I bailed on that.

Are any of these helpful? I'm happy to do more iterations – perhaps
using LuaLaTeX and better fonts? This is so far just rushed lunch-work:

https://nonempty.org/~gspr/social.tex

https://nonempty.org/~gspr/social.pdf


 -- Gard
 


signature.asc
Description: PGP signature


Bug#991036: libhandy: Should this package be removed in bookworm?

2021-09-07 Thread Adrian Bunk
On Tue, Sep 07, 2021 at 10:07:10AM +0100, Simon McVittie wrote:
> On Tue, 13 Jul 2021 at 13:36:17 +0300, Adrian Bunk wrote:
> > A more recent version is already available in src:libhandy-1.
> > 
> > Both versions will be in bullseye, but still shipping both in
> > bookworm would feel wrong.
> 
> I think you're right, but I think it might also be too soon for this to
> be considered RC, because progress cannot be made on its removal until
> some transitions have gone through.

The popcon increase in bullseye made it a key package, in practice the 
release team would start looking at this bug in around a year when the 
bookworm freeze will be closer if the package is still in testing at
that point.

> I've opened bugs for the four remaining reverse-dependencies:
>...

Thanks!
 
> smcv

cu
Adrian



Bug#993838: sane-utils: fails to detect scanner w/o root privileges; the user is in scanner group

2021-09-07 Thread Andrei L
Package: sane-utils
Version: 1.0.31-4.1
Severity: normal
X-Debbugs-Cc: 507...@mail.ru

Dear Maintainer,

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

I add myself to the scanner group and plug the scanner to the usb port.

(scanner:x:119:saned,andrei )

Then, I try

$ sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

could not open USB device 0x8087/0x0024 at 003:002: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 003:001: Access denied (insufficient 
permissions)
could not open USB device 0x046d/0xc33a at 001:004: Access denied (insufficient 
permissions)
could not open USB device 0x062a/0x4101 at 001:003: Access denied (insufficient 
permissions)
could not open USB device 0x8087/0x0024 at 001:002: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 001:001: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0003 at 004:001: Access denied (insufficient 
permissions)
could not open USB device 0x07b3/0x1300 at 002:002: Access denied (insufficient 
permissions)
could not open USB device 0x1d6b/0x0002 at 002:001: Access denied (insufficient 
permissions)
  # No USB scanners found. If you expected something different, make sure that
  # you have loaded a kernel driver for your USB host controller and have setup
  # the USB system correctly. See man sane-usb for details.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.

So it fails.

Then I log in with root privileges and try

# sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x07b3 [PLUSTEK INC], product=0x1300 [USB2.0 
SCANNER], chip=GL845) at libusb:002:002
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.


So it is successfully detected.

What is wrong in debian 11 bullseye system settings ?

WBR,
Andrei L

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

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

Versions of packages sane-utils depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13
ii  libieee1284-3  0.2.11-14
ii  libjpeg62-turbo1:2.0.6-4
ii  libpng16-161.6.37-3
ii  libsane1   1.0.31-4.1
ii  libsystemd0247.3-6
ii  libusb-1.0-0   2:1.0.24-3
ii  libxml22.9.10+dfsg-6.7
ii  lsb-base   11.1.0
ii  update-inetd   4.51

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
ii  avahi-daemon  0.8-5
pn  unpaper   

-- debconf information:
  sane-utils/saned_run: false
  sane-utils/saned_scanner_group: true



Bug#991036: libhandy: Should this package be removed in bookworm?

2021-09-07 Thread Simon McVittie
On Tue, 13 Jul 2021 at 13:36:17 +0300, Adrian Bunk wrote:
> A more recent version is already available in src:libhandy-1.
> 
> Both versions will be in bullseye, but still shipping both in
> bookworm would feel wrong.

I think you're right, but I think it might also be too soon for this to
be considered RC, because progress cannot be made on its removal until
some transitions have gone through.

I've opened bugs for the four remaining reverse-dependencies:

- #993849: gnome-authenticator
- #993850: gnome-calendar
- #993852: gnome-metronome
- #993853: kgx

gnome-authenticator has a new upstream version 4.x that uses GTK4 and
libadwaita, but libadwaita is not yet stable and is in NEW (it might be
possible to bundle a snapshot in gnome-authenticator). gnome-authenticator 4
itself is a rewrite from Python into Rust, so this is unlikely to be quick
to update. (The Debian package is also mis-named, this is not an official
GNOME application.)

gnome-calendar has a new upstream version that uses libhandy-1, but it
cannot move from experimental to unstable until we are ready for the
evolution-data-server 40 transition, and there are two other GNOME 40
transitions that need to happen first (libmutter and libgweather).

gnome-metronome's upstream project appears to have disappeared, although a
replacement exists. It seems to be a very similar UI but not sharing any
actual code. (The Debian package is also mis-named, this is not an official
GNOME application.)

kgx is fixed upstream, but there has been no upstream release since it moved
to handy-1.

smcv



Bug#993855: rustc: Bootstrapping rustc for x32

2021-09-07 Thread John Paul Adrian Glaubitz
Source: rustc
Severity: normal

Hello!

Bootstrapping the Rust compiler on x32 is now possible provided that the
LLVM version used is 13 or newer. I have successfully cross-compiled the
Rust compiler from git for x86_64-unknown-linux-gnux32 which is what we
call x32 in Debian.

There is one pending patch [1] necessary for the build to succeed. So, if
the patch is not included in Rust 1.55.0, please pull it from there.

I was already able to cross-compile and upload the cargo package and I will
keep updating the package manually once new upstream versions have been
uploaded to unstable.

Once we have version 1.55.0 in unstable, we will be able to build the rustc
package for x32 without any problems. I haven't verified the testsuite results
though.

Adrian

> [1] https://github.com/rust-lang/rust/pull/88668

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#993854: override: libhandy:oldlibs/optional

2021-09-07 Thread Simon McVittie
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: libha...@packages.debian.org

src:libhandy (libhandy version 0) has been superseded by src:libhandy-1,
but cannot be removed yet because several packages still depend on it
(see #991036).

Please move all of its binary packages to oldlibs, to give maintainers
a hint that it is no longer the right thing to be using.

Thanks,
smcv



Bug#993853: kgx: Depends on deprecated libhandy version 0

2021-09-07 Thread Simon McVittie
Source: kgx
Version: 0.2.1-2
Tags: sid bookworm fixed-upstream
Severity: normal
Control: block 991036 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libhandy

This package Build-Depends on libhandy-0.0-dev, which has been superseded
by libhandy-1-dev (for GTK 3 applications) or by libadwaita (for GTK 4
applications, currently in NEW).

https://bugs.debian.org/991036 is a request for libhandy version 0 to be
removed from Debian before bookworm, so this might become release-critical
at some point in the future.

Newer versions in upstream git seem to have switched to libhandy-1, but
there doesn't seem to be a release with that dependency yet.

smcv



Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

2021-09-07 Thread Michael Hudson-Doyle
On Tue, 7 Sept 2021 at 17:49, Michael Biebl  wrote:

> Control: reassign -1 libc6
> Control: found -1 2.32-1
> Control: severity -1 serious
> Control: affects -1 + systemd
>
> Hi Michael
>
> Am 07.09.21 um 00:39 schrieb Michael Hudson-Doyle:
> > On Tue, 7 Sept 2021 at 10:21, Michael Biebl  > > wrote:
> >
> > Am 06.09.21 um 23:45 schrieb Vincent Bernat:
> >   > Package: systemd
> >   > Version: 247.9-1
> >   > Severity: normal
> >   >
> >  > Hey!
> >  >
> >  > After upgrading to libc6 2.32-1, some services are unable to
> restart.
> >  > In my case, systemd-resolved, systemd-timesyncd and colord. Using
> >  > "systemctl daemon-reexec" fixes the issue. Unsure if there is
> really
> >  > something to be fixed but as I didn't find anything about that, a
> bug
> >  > report may help others. I suppose the problem is related to NSS.
> >  >
> >  > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
> > Synchronization...
> >  > Sep 06 23:06:43 chocobo systemd[236983]:
> > systemd-timesyncd.service: Failed to determine user credentials: No
> > such process
> >  > Sep 06 23:06:43 chocobo systemd[236983]:
> > systemd-timesyncd.service: Failed at step USER spawning
> > /lib/systemd/systemd-timesyncd: No such process
> >  >
> >  >
> >
> >
> > @libc maintainers: any ideas what could be causing this? If this is
> > triggered by a libc6 update, should this be reassigned to glibc?
> >
> >
> > We went through this in Ubuntu recently and decided that restarting
> > systemd in glibc's postinst was the safest option:
> > https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276
> > 
> >
> > What's happening is that systemd is running with the old glibc, forks
> > and then does NSS things that cause the new glibc's NSS modules to load
> > and they don't necessarily work, leading to failures in any unit that
> > specifies User=. At least for Ubuntu's builds the NSS modules seem to be
> > ABI compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but
> > they are definitely not between 2.33 and 2.34.
>
> Thanks for this information. This is indeed an icky issue and I feel
> like we are between a rock and a hard place.
>

Yeah. I guess one could say that having a long running process that forks
and then does NSS stuff is skating on thin ice a bit. At least the changes
in glibc 2.34 to move nss_files functionality into glibc itself will reduce
the fallout of this considerably.


> I'm not a huge fan of going back to re-exec systemd again directly in
> libc6.postinst, but your proposed patch to at least check that the
> systemd binary can be sucessfully executed should at least deal with the
> situation sufficiently, where a library is (temporarily) missing.
> I do wonder though, if this this will mean that on dist-upgrades the
> daemon-reexec will be skipped.
>

FWIW I had a long chat with Julian (the apt maintainer) about this and he
thought there were three potential situations that could be a problem:

1) a new systemd is unpacked before its Depends
2) one of systemd dependencies has a Breaks: systemd (<< new)
3) in some cases a cycle has to be broken by removing a package with
--force-deps

It think 1) is by some margin the most likely to actually happen, and at
least in that situation systemd will be restarted shortly by its own
postinst.

Cheers,
Michael

Anyway, I think it's best to reassign this libc6 for now and mark it as
> RC so the package doesn't migrate to testing for now.
>
> Regards,
> Michael
>
>


Bug#993852: gnome-metronome: Depends on deprecated libhandy version 0

2021-09-07 Thread Simon McVittie
Source: gnome-metronome
Version: 0.1.1-1
Tags: sid bookworm
Severity: normal
Control: block 991036 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libhandy

This package Build-Depends on libhandy-0.0-dev, which has been superseded
by libhandy-1-dev (for GTK 3 applications) or by libadwaita (for GTK 4
applications, currently in NEW).

https://bugs.debian.org/991036 is a request for libhandy version 0 to be
removed from Debian before bookworm, so this might become release-critical
at some point in the future.

This version's upstream git repo seems to have disappeared, but perhaps
https://gitlab.gnome.org/aplazas/metronome is a suitable replacement?

Neither the version currently packaged nor Adrien Plazas' version seems to
be official GNOME software (see
https://wiki.gnome.org/Foundation/SoftwarePolicy) so if Adrien Plazas'
version is packaged, it would be good to avoid the gnome- naming convention
for it.

smcv



Bug#993851: ulfius: CVE-2021-40540

2021-09-07 Thread Neil Williams
Source: ulfius
Version: 2.7.1-1
Severity: important
Tags: security upstream

A security vulnerability exists in ulfius prior to version 2.7.4

CVE-2021-40540 [0]

ulfius_uri_logger in Ulfius HTTP Framework before 2.7.4 omits con_info
initialization and a con_info->request NULL check for certain malformed
HTTP requests.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40540
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40540

Thanks



Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

2021-09-07 Thread Roger Lynn

On 06/09/2021 11:05, Didier 'OdyX' Raboud wrote:

CUPS appears to already have access to everything in /etc/ssl/ on all
systems, which is where I used to keep my CAcert certificates. This doesn't
feel any different.


You're absolutely right; that's convincing to me!

Reopening, and will fix in the next upload.


Excellent! Thank you.



Bug#993850: gnome-calendar: Depends on deprecated libhandy version 0

2021-09-07 Thread Simon McVittie
Source: gnome-calendar
Version: 3.38.2-1
Tags: sid bookworm fixed-upstream
Severity: normal
Control: block 991036 by -1
Control: fixed -1 40.1-1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libhandy

This package Build-Depends on libhandy-0.0-dev, which has been superseded
by libhandy-1-dev (for GTK 3 applications) or by libadwaita (for GTK 4
applications, currently in NEW).

https://bugs.debian.org/991036 is a request for libhandy version 0 to be
removed from Debian before bookworm, so this might become release-critical
at some point in the future.

Upstream versions 40.x use libhandy-1, but uploading these versions requires
the evolution-data-server transition to have started, which we can't do yet.

smcv



Bug#993849: gnome-authenticator: Depends on deprecated libhandy version 0

2021-09-07 Thread Simon McVittie
Source: gnome-authenticator
Version:  3.32.2+dfsg1-3
Tags: sid bookworm
Severity: normal
Control: block 991036 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libhandy

This package Build-Depends on libhandy-0.0-dev, which has been superseded
by libhandy-1-dev (for GTK 3 applications) or by libadwaita (for GTK 4
applications, currently in NEW).

https://bugs.debian.org/991036 is a request for libhandy version 0 to be
removed from Debian before bookworm, so this might become release-critical
at some point in the future.

The new upstream releases 4.0.x no longer use libhandy, having moved to
GTK 4 and libadwaita. They have also been rewritten in Rust, so the Python
team are probably not the right people to be maintaining this app any more.

smcv



Bug#993848: postgresql-13: A SELECT query with cursor can cause segmentation fault

2021-09-07 Thread Tomas Barton
Package: postgresql-13
Version: 13.4-1.pgdg100+1
Severity: normal

Dear Maintainer,

a slightly sophisticated SELECT query with a CURSOR can lead to
postgresql server segmentation fault.

LOG:  server process (PID 10722) was terminated by signal 11: Segmentation
fault
DETAIL:  Failed process was running: COMMIT
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.

Here's a backtrace retrieved from core dump:

(gdb) bt
#0  slot_deform_heap_tuple (natts=5, offp=0x557cc2e8ffd0, tuple=, slot=0x557cc2e8ff88) at
./build/../src/backend/executor/execTuples.c:930
#1  tts_buffer_heap_getsomeattrs (slot=0x557cc2e8ff88, natts=5) at
./build/../src/backend/executor/execTuples.c:695
#2  0x557cc1d3998c in slot_getsomeattrs_int
(slot=slot@entry=0x557cc2e8ff88,
attnum=5) at ./build/../src/backend/executor/execTuples.c:1912
#3  0x557cc1d28fba in slot_getsomeattrs (attnum=,
slot=0x557cc2e8ff88) at ./build/../src/include/executor/tuptable.h:344
#4  ExecInterpExpr (state=0x557cc303c538, econtext=0x557cc2d08178,
isnull=) at
./build/../src/backend/executor/execExprInterp.c:482
#5  0x557cc1d5548d in ExecEvalExprSwitchContext (isNull=0x7ffdd2599507,
econtext=0x557cc2d08178, state=0x557cc303c538) at
./build/../src/include/executor/executor.h:322
#6  ExecQual (econtext=0x557cc2d08178, state=0x557cc303c538) at
./build/../src/include/executor/executor.h:391
#7  MJFillInner (node=0x557cc2d07f68) at
./build/../src/backend/executor/nodeMergejoin.c:494
#8  0x557cc1d55ce8 in ExecMergeJoin (pstate=0x557cc2d07f68) at
./build/../src/backend/executor/nodeMergejoin.c:1353
#9  0x557cc1d2cc83 in ExecProcNode (node=0x557cc2d07f68) at
./build/../src/include/executor/executor.h:248
#10 ExecutePlan (execute_once=, dest=0x557cc2ed8f60,
direction=, numberTuples=0, sendTuples=,
operation=CMD_SELECT, use_parallel_mode=,
planstate=0x557cc2d07f68,
   estate=0x557cc2d07d08) at
./build/../src/backend/executor/execMain.c:1632
#11 standard_ExecutorRun (queryDesc=0x557cc2ed8ed0, direction=, count=0, execute_once=) at
./build/../src/backend/executor/execMain.c:350
#12 0x7f0ec05ae09d in pgss_ExecutorRun (queryDesc=0x557cc2ed8ed0,
direction=ForwardScanDirection, count=0, execute_once=) at
./build/../contrib/pg_stat_statements/pg_stat_statements.c:1045
#13 0x557cc1cdbcd4 in PersistHoldablePortal
(portal=portal@entry=0x557cc2d489f8)
at ./build/../src/backend/commands/portalcmds.c:407
#14 0x557cc1ff95f9 in HoldPortal (portal=portal@entry=0x557cc2d489f8)
at ./build/../src/backend/utils/mmgr/portalmem.c:642
#15 0x557cc1ff9e7d in PreCommit_Portals (isPrepare=isPrepare@entry=false)
at ./build/../src/backend/utils/mmgr/portalmem.c:738
#16 0x557cc1c001c4 in CommitTransaction () at
./build/../src/backend/access/transam/xact.c:2087
#17 0x557cc1c015d5 in CommitTransactionCommand () at
./build/../src/backend/access/transam/xact.c:3085
#18 0x557cc1ea211d in finish_xact_command () at
./build/../src/backend/tcop/postgres.c:2662
#19 0x557cc1ea4703 in exec_simple_query (query_string=0x557cc2c9cd28
"COMMIT") at ./build/../src/backend/tcop/postgres.c:1264
#20 0x557cc1ea6143 in PostgresMain (argc=,
argv=argv@entry=0x557cc2cf7af8, dbname=, username=) at ./build/../src/backend/tcop/postgres.c:4339
#21 0x557cc1e25bcd in BackendRun (port=0x557cc2ce9650,
port=0x557cc2ce9650) at ./build/../src/backend/postmaster/postmaster.c:4526
#22 BackendStartup (port=0x557cc2ce9650) at
./build/../src/backend/postmaster/postmaster.c:4210
#23 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1739
#24 0x557cc1e26b41 in PostmasterMain (argc=5, argv=) at
./build/../src/backend/postmaster/postmaster.c:1412
#25 0x557cc1b70f4f in main (argc=5, argv=0x557cc2c96c30) at
./build/../src/backend/main/main.c:210

(gdb) frame 11
#11 standard_ExecutorRun (queryDesc=0x557cc2ed8ed0, direction=, count=0, execute_once=) at
./build/../src/backend/executor/execMain.c:350
350 ./build/../src/backend/executor/execMain.c: No such file or
directory.
(gdb) p queryDesc
$1 = (QueryDesc *) 0x557cc2ed8ed0
(gdb) p *(QueryDesc *) 0x557cc2ed8ed0
$2 = {operation = CMD_SELECT, plannedstmt = 0x557cc2faef08,
 sourceText = 0x557cc2ed8a70 "\n", ' ' , "DECLARE
\"categoryPagePhotoUrl_image_urls\" CURSOR WITH HOLD FOR\n", ' ' , "SELECT di.itemId, image_number, filename FROM (SELECT *\n", ' '
, "FROM downloaded_images"..., snapshot = 0x557cc2edf328,
crosscheck_snapshot = 0x0, dest = 0x557cc2ed8f60, params = 0x0, queryEnv =
0x0, instrument_options = 0, tupDesc = 0x557cc303bc58,
 estate = 0x557cc2d07d08, planstate = 0x557cc2d07f68, already_executed =
true, totaltime = 0x0

I'll try to make an reproducable code, let me known if you need more
information.

The query might be a bit nasty, but it shouldn't 

Bug#993847: link-grammar: FTBFS on 32bit

2021-09-07 Thread Adrian Bunk
Source: link-grammar
Version: 5.10.0~dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=link-grammar=sid

...
FAIL: tests
===

Running by: /usr/bin/python3
Running ./tests.py in: /<>/bindings/python-examples
PYTHONPATH=./../python:../python:../python/.libs
srcdir=.
LINK_GRAMMAR_DATA=./../../data
Compiled with: gcc __VERSION__="10.3.0"  
OS: linux-gnu __unix__ 
Standards: __STDC_VERSION__=201112L _POSIX_C_SOURCE=200809L 
Configuration (source code):
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CFLAGS=-D_DEFAULT_SOURCE -std=c11 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE -D_ISOC11_SOURCE -g -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 
-fvisibility=hidden
Configuration (features):
DICTIONARY_DIR=/usr/share/link-grammar
-DPACKAGE_NAME="link-grammar" -DPACKAGE_TARNAME="link-grammar" 
-DPACKAGE_VERSION="5.10.0" -DPACKAGE_STRING="link-grammar 5.10.0" 
-DPACKAGE_BUGREPORT="https://github.com/opencog/link-grammar; 
-DPACKAGE_URL="https://www.abisource.com/projects/link-grammar; 
-DPACKAGE="link-grammar" -DVERSION="5.10.0" -DYYTEXT_POINTER=1 -DHAVE_STDIO_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_THREADS_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" 
-DHAVE_STRNDUP=1 -DHAVE_STRTOK_R=1 -DHAVE_SIGACTION=1 -DHAVE_ALIGNED_ALLOC=1 
-DHAVE_POSIX_MEMALIGN=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_FORK=1 
-DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_PRCTL=1 
-D__STDC_FORMAT_MACROS=1 -D__STDC_LIMIT_MACROS=1 -DTLS=_Thread_local 
-DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_VISIBILITY=1 
-DHAVE_LOCALE_T_IN_LOCALE_H=1 -DHAVE_STDATOMIC_H=1 -DUSE_WORDGRAPH_DISPLAY=1 
-DHAVE_SQLITE3=1 -DHAVE_HUNSPELL=1 -DHUNSPELL_DICT_DIR="/usr/share/hunspell" 
-DHAVE_EDITLINE=1 -DHAVE_WIDECHAR_EDITLINE=1 -DHAVE_PCRE2_H=1 
-DHAVE_MAYBE_UNINITIALIZED=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 
-DSTRERROR_R_CHAR_P=1
Using >/bindings/python/linkgrammar.py'>
Using >/bindings/python/clinkgrammar.py'>
Using >/bindings/python/.libs/_clinkgrammar.so'>
Using >/bindings/python-examples/lg_testutils.py'>
s...s.s...s.s..malloc():
 invalid size (unsorted)
FAIL tests.py (exit status: 134)


Testsuite summary for link-grammar 5.10.0

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See bindings/python-examples/test-suite.log
Please report to https://github.com/opencog/link-grammar

make[6]: *** [Makefile:619: test-suite.log] Error 1



Bug#992956: bullseye-pu: package modsecurity-crs/3.3.0-1

2021-09-07 Thread Jonathan Wiltshire
On Mon, Sep 06, 2021 at 11:40:08AM +0200, Alberto Gonzalez Iniesta wrote:
> On Sat, Sep 04, 2021 at 03:17:25PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2021-08-25 at 16:55 +0200, Alberto Gonzalez Iniesta wrote:
> > > This [1] security bug was found in modsecurity-crs.
> > > As stated in #992863 by the security team, a DSA won't be issued
> > > (security team on Cc:) so I'm targeting bullseye proposed updates
> > > instead.
> > > 
> > 
> > >From reading #992863 and checking the Security Tracker, it appears that
> > the issue is already fixed in unstable. However, that fact is not
> > reflected in the BTS. Assuming that I haven't missed anything, please
> > add an appropriate fixed version to #992863 and go ahead.
> > 
> 
> Ooops, sorry I messed the original bug number in my upload to unstable
> as Salvatore found out.
> 
> May I upload the packages for stable (#992956) and oldstable (#992863)?
> Only for stable and wait for an answer to #992863?

Just stable for now please; oldstable will be answered on the other
request when someone reaches it.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature


Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

2021-09-07 Thread Filippo Giunchedi
On Tue, Aug 24, 2021 at 02:32 PM, Filippo Giunchedi wrote:
> I was able to get python3-eventlet to play nice with dnspython2 by
> integrating https://github.com/eventlet/eventlet/pull/722 from upstream.

Upstream has merged the PR, please consider updating the patch in the
package. Possibily for a point release too?

best,
Filippo



Bug#993783: snapd: AppArmor profile breaks snaps

2021-09-07 Thread Michael Vogt
Hi,

thanks for your bugreport. I can reproduce the issue and it seems like
it is triggered by the recent move to apparmor 3 in unstable. The
profile loading for snaps used to be done directly by apparmor but
with apparmor3 we need a patch in snapd to do it ourselfs. I will push
a fix ASAP (testing right now).

Sorry for the trouble,
 Michael



Bug#992843: apr 1.7.0-6+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 992843 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: apr
Version: 1.7.0-6+deb11u1

Explanation: prevent out-of-bounds array dereference



Bug#992547: detox 1.3.3-1+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 992547 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: detox
Version: 1.3.3-1+deb11u1

Explanation: fix handling of large files



Bug#992836: termshark 2.2.0-1+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 992836 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: termshark
Version: 2.2.0-1+deb11u1

Explanation: include themes in package



Bug#992206: ruby-rqrcode-rails3 0.1.7-1.1+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 992206 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: ruby-rqrcode-rails3
Version: 0.1.7-1.1+deb11u1

Explanation: fix for ruby-rqrcode 1.0 compatibility



Bug#992299: txt2man 1.7.1-1+deb11u1 flagged for acceptance

2021-09-07 Thread Jonathan Wiltshire
package release.debian.org
tags 992299 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: txt2man
Version: 1.7.1-1+deb11u1

Explanation: fix regression in handling display blocks



Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1

2021-09-07 Thread Jonathan Wiltshire
On Sun, Sep 05, 2021 at 09:58:48AM +0200, László Böszörményi (GCS) wrote:
> Hi Jonathan,
> 
> On Sat, Sep 4, 2021 at 11:59 AM Jonathan Wiltshire  wrote:
> > Control: tag -1 confirmed moreinfo
> [...]
> > Please go ahead, and remove this bug's moreinfo tag when it is uploaded.
>  Just to make sure, you accept the updated patch [1], right?

Yes please!

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature


Bug#993846: otrs2: CVE-2021-36096 CVE-2021-36095 CVE-2021-36094 CVE-2021-36093

2021-09-07 Thread Neil Williams
Package: otrs2
Version: 6.0.36-2
Severity: important
Tags: security upstream


Hi,

The following vulnerabilities were published for otrs2. Couldn't
find any Znuny references yet.

CVE-2021-36096[0]
Generated Support Bundles contains private S/MIME and PGP keys if 
containing folder is not hidden. This issue affects: OTRS AG ((OTRS)) 
Community Edition 6.0.x version 6.0.1 and later versions. OTRS AG OTRS 
7.0.x version 7.0.28 and prior versions; 8.0.x version 8.0.15 and prior 
versions.
https://otrs.com/release-notes/otrs-security-advisory-2021-10/

CVE-2021-36095[1]
Malicious attacker is able to find out valid user logins by using the 
"lost password" feature. This issue affects: OTRS AG ((OTRS)) Community 
Edition version 6.0.1 and later versions. OTRS AG OTRS 7.0.x version 
7.0.28 and prior versions.
https://otrs.com/release-notes/otrs-security-advisory-2021-18/

CVE-2021-36094[2]
It's possible to craft a request for appointment edit screen, which 
could lead to the XSS attack. This issue affects: OTRS AG ((OTRS)) 
Community Edition 6.0.x version 6.0.1 and later versions. OTRS AG OTRS 
7.0.x version 7.0.28 and prior versions.
https://otrs.com/release-notes/otrs-security-advisory-2021-17/

CVE-2021-36093[3]
It's possible to create an email which can be stuck while being 
processed by PostMaster filters, causing DoS. This issue affects: OTRS 
AG ((OTRS)) Community Edition 6.0.x version 6.0.1 and later versions. 
OTRS AG OTRS 7.0.x version 7.0.28 and prior versions; 8.0.x version 
8.0.15 and prior versions.
https://otrs.com/release-notes/otrs-security-advisory-2021-16/

[0] https://security-tracker.debian.org/tracker/CVE-2021-36096
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36096

[1] https://security-tracker.debian.org/tracker/CVE-2021-36095
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36095

[2] https://security-tracker.debian.org/tracker/CVE-2021-36094
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36094

[3] https://security-tracker.debian.org/tracker/CVE-2021-36093
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36093


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

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



Bug#993346: pytest-mock: please upgrade to latest upstream release

2021-09-07 Thread Diego M. Rodriguez
Hello Sandro,

On Mon, 6 Sep 2021 22:20:29 -0400 Sandro Tosi  wrote:
> debian/changelog misses several of your changes, please update and
> i'll then sponsor it

Thanks - just pushed an update to debian/changelog.

-- 
Diego M. Rodriguez



Bug#984956: Pmix issues with openmpi-4.1.0

2021-09-07 Thread Samuel Thibault
Hello,

The openmpi version is unstable does not contain the patch included in
4.1.0-9, and thus this bug Bug#984956 is still preventing openmpi from
migrating (as well as rdeps such as starpu).

Samuel



Bug#986491: Acknowledgement (fails to fully configure with debconf low priority)

2021-09-07 Thread Nick Gawronski
My main reason for running installs at low priority both at the main 
debian-installer screen and wanting to do so after the base system is 
installed is so I can have a fully configured system and not have to go 
back and reconfigure everything after the installation is finished.  If 
the debconf priority of the installation would be transfered over to the 
installed system when the base system was being installed then I could 
have an installation where I was asked about all configuration questions 
the first time the system was fully installed and when it came up at the 
end of the installation everything would be ready to go. My question is 
why is the debconf priority not carried over from the debian-installer 
to the installed system after the base system is installed as if a user 
chose expert mode or just low priority I would have thought this would 
have been the case?


On 4/6/2021 5:03 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 986491: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986491.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   n...@nickgawronski.com
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian Install System Team 

If you wish to submit further information on this problem, please
send it to 986...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.





Bug#993845: bind9-utils: /etc/bind/rndc.key is no longer used

2021-09-07 Thread Debian/GNU
Package: bind9-utils
Version: 1:9.16.15-1
Severity: normal

Dear Maintainer,

After a recent upgrade from buster to bullseye, my rndc setup was
broken.


Running any `rndc` command that requires authentication, I get an error:
```
$ rndc thaw
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized,
* the key signing algorithm is incorrect, or
* the key is invalid.
$
```

After a bit of investigation, I found that the problem is, that up to
and including buster, `rndc` (and `bind9`) would honour an
`/etc/bind/rndc.key` file (out of the box), but since bullseye only the
`/etc/rndc.key` file is used.

>From reading old bug reports (e.g. #179353), i gather that the
/etc/bind/key.rndc was a Debian specific modification, and i guess it
was eventually removed.

The transition is easy enough, however, i haven't found any trace of a
documentation hinting at that.

I would have expected a NEWS entry, or at least a mention in the
changelog.Debian.

cheerio & mfgtfa
IOhannes



Bug#993844: RFP: akvcam-dkms -- Virtual camera driver for Linux

2021-09-07 Thread Martin-Éric Racine
Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: akvcam-dkms
  Version : 1.2.2
  Upstream Author : Gonzalo Exequiel Pedone 
* URL : https://github.com/webcamoid/akvcam
* License : GPL 2+
  Programming Lang: C
  Description : Virtual camera driver for Linux
akvcam is a fully compliant V4L2 virtual camera driver for Linux.
.
Features:
 * Flexible configuration with a simple INI file like.
 * Support for map, user pointer, and read/write modes.
 * Can cat and echo to the device.
 * Supports emulated camera controls in capture devices (brightness, contrast, 
saturation, etc.).
 * Configurable default picture in case no input signal available.
 * The devices can't be rejected by programs that rejects M2M devices.
 * Fully compliant with V4L2 standard.
 * Support for LTS kernels.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmE3FTIACgkQrh+Cd8S0
17a5iRAAp+3eu8VhZE4LIpXjfxWChsWGe1lvZD1ppBFwYR8PAGcJHupPwkaSiCVj
4OnyMz5XFI8NPIBJuZzMOv3Etey737kKwcTIXsNGFLmtvZPQ58aoWekug4t3O394
0ZfMNeFKYo6POFzB1UUto4ZeAjWiSZpSOw9I+ej8bcHlX355OlTqacHQa66fwm8Z
Z8D2qlDbrmZebUlUTGVWcrzp0BwG1LKpKSu+TTOEG2WGsisFWCvk6xw9gPRf/LSC
f7uMj3PBd5jXfCyAJae3yWjU8njMc2Fj/6gCCUxq//AB6wmiALaQ01Td8LgQi2Qy
MCNbDm/XBJVs97dxxhA+kjnzIUadRJUvWeejp4XFkZX2IXWNadka1Xwu1oHo5FSG
mS6InSxLtFR8WD/HJZ3Q7oB29hSwB9pJxmSqPZCuQjzZm3dzE3KSXCRq+xIauXht
PeKG8EqwqhFZ0YO8ocZf+JEkRT2UN67CDXQuBSI3AqBxkJQux8ziUoAAxRkPnzuo
ZYVRNTs/rpwxIT2s3gFtDs1iGkU89831b3u6QU5mwFnr1jVskXmKpnOqk5C5C+R2
bYf2Yiy+keQ3HEncAarEVgyThJv+ffYyH6WVSa9wmMEznAzYDofhBUUAB9tpO+hz
+Bze02131oxYULAvYbV/e9HQZaEeJ/hRHPs4gjSKpfqoHvQTicc=
=QQ0G
-END PGP SIGNATURE-



Bug#993837: shotcut FTBFS with mlt 7

2021-09-07 Thread Gürkan Myczko
a solution for sid with an updated version according the comment at 
https://mentors.debian.net/package/shotcut/

should appear soon. 

thanks for your bug report

Gürkan


> On 7 Sep 2021, at 04:57, Adrian Bunk  wrote:
> 
> Source: shotcut
> Version: 21.01.29+ds-1
> Severity: serious
> Tags: ftbfs bookworm sid
> 
> https://buildd.debian.org/status/package.php?p=shotcut=sid
> 
> ...
> cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
> /<>/src/src.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
> 'QMAKE_CFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
> 'QMAKE_CXXFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2' QMAKE_LFLAGS_RELEASE=-Wl,-z,relro 
> QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: PREFIX=/usr ) && make -f 
> Makefile
> Project ERROR: mlt++ development package not found
> make[1]: *** [Makefile:74: sub-src-make_first] Error 3
> 


Bug#993839: thunderbird: vary bad look in high dpi screen; tiny fonts and icons

2021-09-07 Thread Carsten Schoenert
Hello Andrei,

Am 07.09.21 um 07:28 schrieb Andrei L:
> 
> my screen dpi is 160, and the thunderbird in debian 11 looks terrible
> ... tears of eyes due to tiny fonts and icons ...>
> 
> Note that it's allright with thunderbird fonts in suse thumbleweed
> linux with high dpi screen ...>
> How to correct this?  

the size for the used fonts can be adjusted within the configuration dialog.

https://support.mozilla.org/en-US/questions/1102350

Otherwise you should provide more information what you did (and what
not), and what you have already tried. And this all please on one of the
user support channels. Your question isn't a typical question to talk
with the package maintainer as this isn't a issue on the packaging at my
opinion. Thanks!

https://www.debian.org/support

-- 
Regards
Carsten



Bug#829444: Accepting / adopting DEP-14

2021-09-07 Thread Guido Günther
Hi Otto,
On Mon, Sep 06, 2021 at 10:28:48PM -0700, Otto Kekäläinen wrote:
> Hello!
> 
> Any updates on the Debian package git branch layout?
> 
> I am about to start working on mariadb-10.6 and will create a new repo
> for it, and would be open to adopting DEP-14 if it is finalized.
> 
> If gbp-buildpackage adopts the current  DEP-14, please mention it in
> the changelog:
> https://tracker.debian.org/media/packages/g/git-buildpackage/changelog-0.9.23
> 
> Latest reference to DEP-14 is in 2016. Following DEP-14 would be
> easiest if git-buildpackage simply did so by default.
> 
> Also, it would be nice to see a couple of links to repositories that
> have DEP-14. Even better would be some stats on the different
> suggested conventions to see what their adoption rate currently is,
> and what has turned out to be the most popular conventions.
> 
> Thanks if you have time to update the status on this,

It mostly didn't happen due to lack of time. Hope to make some progress
at next mini debconf but will also happily review changes.
Cheers,
 -- Guido

> 
> - Otto
> 



Bug#993842: ITP: golang-github-0xax-notificator -- Desktop notifications with golang

2021-09-07 Thread Takuma Shibuya
Package: wnpp
Severity: wishlist
Owner: Takuma Shibuya 

* Package name: golang-github-0xax-notificator
  Version : 0.0~git20210731.c42e3d4-1
  Upstream Author : 0xAX <0...@users.noreply.github.com>
* URL : https://github.com/0xAX/notificator
* License : BSD-3-clause
  Programming Lang: Go
  Description: Desktop notifications with golang
   notificator Desktop notification written by Golang
   .
   Windows with growlnotify
   .
   Mac OS X with terminal-notifier (if installed) or osascript
   (native, 10.9 Mavericks or Up.)
   .
   Linux with notify-send for Gnome and kdialog for Kde



Bug#993745: O: psad -- Designed to work with iptables to detect port scans

2021-09-07 Thread Leandro Cunha
X-Debbugs-CC: by...@debian.org

> I believe what you are doing is exactly called "packaging hijacking", which is
> unfavorable. Since the original maintainer did not volunteerly orphan the
> package and that the Debian MIA Team did not kick in, we must not assume that
> the original package maintainer has given up the maintenance responsibility.
>
> Debian has a readily-available process to handle current situation (ITS) and I
> believe you also know it. We should follow this procedure to take over package
> maintenance in order to ensure smooth takeover where no argument would take
> place.
>
> My suggestion is to convert this orphaning report to ITS report and start ITS
> process immediately according to
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging
> .
>
> This mail copy is also sent to the original package maintainer (Franck
> Joncourt). Franck: please let us know whether you are still going to maintain
> this package in Debian. If there's no response, we will continue with the ITS
> process and take over the maintenance of package psad in Debian.
>
> Thanks,
> Boyuan Yang

He was a maintainer of fwsnort according to the bug report [1]. That's
where I made this decision. I was in doubt if the package is orphaned
directly or needs to go through ITS. But I've never seen this before and
seeing bug reports like this that the package has simply been orphaned.

I had emailed him, let's not fill his inbox.

I have a little over a year and I'm still learning to deal with situations.
And yes, I've read the documentation, link below:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package

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

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.


signature.asc
Description: Binary data


Bug#993841: libcrypto++: CVE-2021-40530

2021-09-07 Thread Salvatore Bonaccorso
Source: libcrypto++
Version: 8.4.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/weidai11/cryptopp/issues/1059
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcrypto++.

CVE-2021-40530[0]:
| The ElGamal implementation in Crypto++ through 8.5 allows plaintext
| recovery because, during interaction between two cryptographic
| libraries, a certain dangerous combination of the prime defined by the
| receiver's public key, the generator defined by the receiver's public
| key, and the sender's ephemeral exponents can lead to a cross-
| configuration attack against OpenPGP.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40530
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40530
[1] https://github.com/weidai11/cryptopp/issues/1059

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#993840: botan: CVE-2021-40529

2021-09-07 Thread Salvatore Bonaccorso
Source: botan
Version: 2.18.1+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/randombit/botan/pull/2790
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for botan.

CVE-2021-40529[0]:
| The ElGamal implementation in Botan through 2.18.1, as used in
| Thunderbird and other products, allows plaintext recovery because,
| during interaction between two cryptographic libraries, a certain
| dangerous combination of the prime defined by the receiver's public
| key, the generator defined by the receiver's public key, and the
| sender's ephemeral exponents can lead to a cross-configuration attack
| against OpenPGP.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40529
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40529
[1] 
https://github.com/randombit/botan/commit/9a23e4e3bc3966340531f2ff608fa9d33b5185a2
[2] https://github.com/randombit/botan/pull/2790

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#984520: Goeie dag

2021-09-07 Thread comp dir
Ek het hierdie sakegeleentheid -voorstel vir u wat ons sal baat; Ek sal ook
daarvan hou dat jy dit sien.

Groete,
Frank William
64 980 4011


<    1   2