Bug#985254: openafs-modules-dkms: Fails to build on -rt / non-HIGHMEM kernels

[Witold Baryluk]

Package: openafs-modules-dkms
Version: 1.8.6-5
Followup-For: Bug #985254
X-Debbugs-Cc: witold.bary...@gmail.com

Actually after digging more, it is not due to HIGHMEM. In fact the
kmap_atomic takes single argument since about kernel 3.13 on all
configurations.


The issue actually is somewhere else.

In config.log I found this:

The module compiles, however it doesn't link into .ko file:

FATAL: modpost: GPL-incompatible module conftest.ko uses GPL-only symbol 
'migrate_disable'

And that causes configure to think that the function is not one-argument.

Bug#985254: openafs-modules-dkms: Fails to build on -rt / non-HIGHMEM kernels

[Witold Baryluk]

Package: openafs-modules-dkms
Version: 1.8.6-5
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

I am pretty sure this is know issue (I was expiriencing it for probably 2
years or more), but I didn't found any open issues to track this problem.


...
checking whether kmap_atomic takes no km_type argument... no
...
...
Building in directory: MODLOAD-5.10.0-4-rt-amd64-SP
make[2]: Entering directory 
'/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP'
...
...
  CC [M]  
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.o
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:
 In function ‘afs_bypass_copy_page’:
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:31:
 error: ‘KM_USER0’ undeclared (first use in this function)
  311 | address = kmap_atomic(pp, KM_USER0);
  |   ^~~~
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:31:
 note: each undeclared identifier is reported only once for each function it 
appears in
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:15:
 error: too many arguments to function ‘kmap_atomic’
  311 | address = kmap_atomic(pp, KM_USER0);
  |   ^~~
In file included from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem.h:14,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/pagemap.h:11,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/blkdev.h:14,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/backing-dev.h:15,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/afs/sysincludes.h:126,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/afs/afs_bypasscache.h:67,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:64:
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem-internal.h:179:21:
 note: declared here
  179 | static inline void *kmap_atomic(struct page *page)
  | ^~~
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:321:36:
 error: macro "kunmap_atomic" passed 2 arguments, but takes just 1
  321 | kunmap_atomic(address, KM_USER0);
  |^
In file included from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem.h:14,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/pagemap.h:11,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/blkdev.h:14,
 from 
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/backing-dev.h:15,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/afs/sysincludes.h:126,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/afs/afs_bypasscache.h:67,
 from 
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:64:
/usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem-internal.h:210: 
note: macro "kunmap_atomic" defined here
  210 | #define kunmap_atomic(__addr) \
  | 
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:321:5:
 error: ‘kunmap_atomic’ undeclared (first use in this function); did you mean 
‘kmap_atomic’?
  321 | kunmap_atomic(address, KM_USER0);
  | ^
  | kmap_atomic
make[5]: *** 
[/usr/src/linux-headers-5.10.0-4-common-rt/scripts/Makefile.build:284: 
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.o]
 Error 1
make[4]: *** [/usr/src/linux-headers-5.10.0-4-common-rt/Makefile:1813: 
/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP] 
Error 2
make[3]: *** [/usr/src/linux-headers-5.10.0-4-common-rt/Makefile:185: 
__sub-make] Error 2
make[3]: Leaving directory '/usr/src/linux-headers-5.10.0-4-rt-amd64'
FAILURE: make exit code 2
make[2]: *** [Makefile.afs:279: openafs.ko] Error 1
make[2]: Leaving directory 
'/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP'
make[1]: *** [Makefile:186: linux_compdirs] Error 2
make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.6/build/src/libafs'
make: *** [Makefile:15: all] Error 2


The upstream code, as well the one shipped in Debian -dkms package, does
have provisions to detect this issue, and work, but it doesn't. Here is a
relevant part:


#if !defined(UKERNEL)
# if defined(KMAP_ATOMIC_TAKES_NO_KM_TYPE)
address = kmap_atomic(pp);
# else
address = kmap_atomic(pp, KM_USER0);
# endif
#else
address = pp;
#endif
memcpy(address + pageoff, (char *)(rxiov[iovno].iov_base) + iovoff, dolen);
#if !defined(UKERNEL)
# if defined(KMAP_ATOMIC_TAKES_NO_KM_T

Bug#985247: eom: Selecting Print-->Preview shows nothing. eom evoked from terminal shows 'sh: 1: exec: evince: not found'

[scott092707]

Package: eom
Version: 1.24.1-1
Severity: normal
X-Debbugs-Cc: scott092...@aol.com

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: eom: Selecting  Print-->Preview  shows nothing.  eom evoked from 
terminal shows 'sh: 1: exec: evince: not found'
Bcc: Scott Jacobs 
Message-ID: 
<161577196380.259233.15032026551506305869.reportbug@ASUS-Prime-B350MA>
X-Mailer: reportbug 7.10.3
Date: Sun, 14 Mar 2021 21:32:43 -0400

Dear Maintainer,


   * What led up to the situation?
I wished to see how much of a page an image would occupy, and clicked "Preview"
from the Print dialog.

   * What was the outcome of this action?
Nothing happened.
When I invoked eom from the terminal, along with a number of warnings, the
above text was printed.


   * What outcome did you expect instead?
I expected the preview to be displayed.


[Full text of the terminal output below:]
-
(eom:149269): EOM-WARNING **: 20:54:13.134: Error loading Peas typelib: Typelib
file for namespace 'Peas', version '1.0' not found


(eom:149269): EOM-WARNING **: 20:54:13.134: Error loading PeasGtk typelib:
Typelib file for namespace 'PeasGtk', version '1.0' not found


(eom:149269): dconf-WARNING **: 20:54:13.174: failed to commit changes to
dconf: The connection is closed

(eom:149269): dconf-WARNING **: 20:54:13.175: failed to commit changes to
dconf: The connection is closed

(eom:149269): dconf-WARNING **: 20:54:13.193: failed to commit changes to
dconf: The connection is closed

** (eom:149269): WARNING **: 20:54:23.762: The connection is closed
sh: 1: exec: evince: not found

** (eom:149269): WARNING **: 20:56:58.780: The connection is closed

(eom:149269): GLib-GObject-WARNING **: 20:57:17.935: value "-nan" of type
'gfloat' is invalid or out of range for property 'image-x-align' of type
'gfloat'
-

MATE/eom pull request from 2015:
https://github.com/mate-desktop/eom/pull/107 : "refactor draw/expose code a bit
#107"
contains the following text:
"As for preview via pdf, it happens even w/o my work. It first tries evince,
then gives a Gtk-WARNING when it can't find it on my system, then tries atril
and opens the generated pdf in it. It's the same in both GTK+ builds."

I do not have evince.  I DO have atril.
atril:
  Installed: 1.24.0-1
  Candidate: 1.24.0-1
  Version table:
 *** 1.24.0-1 500
500 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

I can get around the problem by making a symlink to atril, and renaming it as
'evince'.

Something must have happened between 2015 and now, as the commenter had success
with eom trying evince and then trying atril.
Now, it apparently does not try atril, as if it did, it would have succeeded.

[Note: both eom and atril-previewer (once I make the symlink) are displayed 
natively under Wayland,
not XWayland]

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

scott@ASUS-Prime-B350MA:~$ apt-cache policy sway
sway:
  Installed: 1.5-7

scott@ASUS-Prime-B350MA:~$ apt-cache policy *wlroots*
...
libwlroots6:
  Installed: 0.11.0-3
...

scott@ASUS-Prime-B350MA:~$ uname -a
Linux ASUS-Prime-B350MA 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31)
x86_64 GNU/Linux

FF

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

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  eom-common   1.24.1-1
ii  gir1.2-eom-1.0   1.24.1-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libexempi8   2.5.2-1
ii  libexif120.6.22-3
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgl1   1.3.2-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libjpeg62-turbo  1:2.0.5-2
ii  liblcms2-2   2.9-4+b1
ii  libmate-desktop-2-17 1.24.1-2
ii  libpeas-1.0-01.28.0-2+b1
ii  librsvg2-2   2.50.2+dfsg-1
ii  librsvg2-common  2.50.2+dfsg-1
ii  libx11-6   

Bug#985252: vorta: clicking on the notification bar icon doesnt open the application

[Sandro Tosi]

Package: vorta
Version: 0.7.5-1
Severity: normal

Hello,
i think it's pretty natural to expect that, clicking on the vorta icon on the
notification bar, vorta will open.

but that's not the case: i need to right click, and then select "Vorta for Borg
Backup" menu entry for that to happen.

Please change this behavior.

Regards,
Sandro


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

Kernel: Linux 5.10.0-4-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 vorta depends on:
ii  python33.9.1-1
ii  python3-appdirs1.4.3-1
ii  python3-apscheduler3.6.3-1
ii  python3-dateutil   2.7.3-3
ii  python3-paramiko   2.7.1-2
ii  python3-peewee 3.13.1+dfsg-1+b3
ii  python3-pkg-resources  46.1.3-1
ii  python3-psutil 5.7.3-1
ii  python3-pyqt5  5.15.2+dfsg-1+b1
ii  python3-pyqt5.qsci 2.11.6+dfsg-1
ii  python3-secretstorage  2.3.1-2

Versions of packages vorta recommends:
ii  borgbackup  1.1.14-3

vorta suggests no packages.

-- no debconf information

Bug#985119: debian-installer: shared-mime-info installed for no apparent reason

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #985119
X-Debbugs-Cc: witold.bary...@gmail.com

Hi Samuel.

> On qemu, the hwdetect package installs qemu-guest-agent, which depends
> on libglib2.0-0, which recommends shared-mime-info.

Oh. I see, I didn't consider the "Recommends". That makes now sense.

Whatever it should be "Suggests", I don't know. Would be interesting to
know the input from glib people.


Regards,
Witold

Bug#985251: RFS: golang-gitlab-tslocum-cbind/0.1.4+git20210309.dfd1991-1 [ITP] -- Key event handling Golang library for tcell

[Micheal Waltz]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-gitlab-tslocum-cbind":

 * Package name: golang-gitlab-tslocum-cbind
   Version : 0.1.4+git20210309.dfd1991-1
   Upstream Author : Trevor Slocum 
 * URL : https://gitlab.com/tslocum/cbind
 * License : Expat
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-gitlab-tslocum-cbind
   Section : devel

It builds those binary packages:

  golang-gitlab-tslocum-cbind-dev - Key event handling Golang library for tcell

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

  https://mentors.debian.net/package/golang-gitlab-tslocum-cbind/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-gitlab-tslocum-cbind/golang-gitlab-tslocum-cbind_0.1.4+git20210309.dfd1991-1.dsc

Changes for the initial release:

 golang-gitlab-tslocum-cbind (0.1.4+git20210309.dfd1991-1) unstable; 
urgency=medium
 .
   * Initial release (Closes: #985180)
   * New upstream version 0.1.4+git20210309.dfd1991
   * Ignore quilt dir .pc via .gitignore

-- 
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15  3D1F 4FA2 70F5 CD36 71F9


signature.asc
Description: PGP signature

Bug#984581: libpst: Debian bug #984581: readpst: overzealous header validity detection

[Paul Wise]

Hi Carl,

A Debian user reported a bug in libpst's readpst tool:

https://bugs.debian.org/984581

The bug report contains two issues experienced with a sample PST file:

The first is that normal MIME headers were not extracted, because the
headers were not considered valid, because the first header was the
X-GM-THRID header rather than one of the limited list of headers
considered valid by readpst. Clearly the header validity function is
not going to keep up with changes in the list of headers that are
commonly in PST files. My suggestion is to replace the current header
validity function with one that just checks if either the first header,
or the entire header block complies with the email header RFC.
Alternatively the header validity function could be removed, or made
optional but disabled/enabled by default.

The second is that when the headers are considered invalid, the To
field doesn't get an email address, only a name. This is because in the
PST file the 0x0E04 aka PR_DISPLAY_TO aka "Address Sent-To" field does
not contain the email address, only a name. The email address does
appear in some the other PST fields (contact and search key) though,
but I am not sure if all PST files have this problem, and I am not sure
if other PST files have the email address in other fields and I am not
sure if it is right to copy those fields to the To field.

I welcome any help you can give on these two topics.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#983205: golang-github-go-ping-ping: Some tests require network access

[Shengjing Zhu]

Source: golang-github-go-ping-ping
Version: 0.0~git20210312.d90f377-1

Forget to close in changelog.

Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Paul Wise]

I did some further investigation of the PST file you sent.

I conclude that there are two problems you are experiencing:

The first one is that readpst doesn't consider the headers as valid
even though they clearly are valid. Since the header validity detection
was added to detect invalid PST files I am going to have to discuss
this with the upstream author. Perhaps the header validity detection
will have to become more generic or perhaps it will be discarded or
perhaps the invalid PST files will be detected in a different way.
Fixing this will bring back all the headers, including ARC & To.

The second one is that for your particular PST file, the To field does
not contain an email address. Looking at the debug output I see that
the "Display Sent-To Address" contains only the name, not the email.
This appears to be a problem with the PST file itself, as the 0x0E04
type, which is PR_DISPLAY_TO, aka the "Address Sent-To", does not
contain the email address. The email address does appear in the
"Contact Address" and "Search Key" though. I am not sure if it is
correct to merge the contact address into the to address though.

If you have any more samples of working or broken PST files, I would be
happy to have a copy of them to debug further.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#984851: Re ITA: qalculate-gtk -- Powerful and easy to use desktop calculator

[James Lu]

Hi all,

I've been a longtime Qalculate user and I'm also willing to help keep
qalculate-gtk + libqalculate up to date.

My Salsa account is jlu-guest and I've also subscribed myself to the
tracker.

I'll happily extend Norbert's suggestion here:

Maintainer: team+qalcul...@tracker.debian.org
Uploaders: Phil Morrell ,
Norbert Preining ,
James Lu 

Best,
James

Bug#985250: hime-data: hime-user-setup uses pushd, which /bin/sh does not provide

[Chung-chieh Shan]

Package: hime-data
Version: 0.9.11+dfsg-2
Severity: normal
Tags: patch

/usr/share/hime/script/hime-user-setup uses pushd and popd, but /bin/sh
does not provide those commands.  In fact, pushd and popd are not
needed, because the child process running the script has its own current
directory.  So pushd should be changed to cd (two occurrences) and popd
should be removed (two occurrences).

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.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


signature.asc
Description: PGP signature

Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Paul Wise]

On Wed, 2021-03-10 at 09:28 +, Surla, Sai Kalyan wrote:

> Hope you got a chance to at the issue that we reported.

I am looking at the issue today.

I managed to reproduce the issue that you have reported using the
sample PST file that you have provided.

I acknowledge that I am seeing both the issues you reported:

 * only a limited set of headers are being extracted
 * email address is missing from the To header
    - but the From header is correct

The readpst -d option to output debug information was instrumental in
reproducing this, it causes all the info in the PST file and the entire
sequence of decoding steps to be output to a debug file.

I modified the valid_headers function to also accept the ARC-Seal
header but that does not fix the problem. Looking at the debug output I
noticed that the X-GM-THRID header is the first header. I then added a
X-GM-THRID to the valid_headers function and that fixed the problem. I
think that messages with a different first header will not work though,
you would have to add all of the first headers that could exist to the
valid_headers function, which seems like an incorrect thing to do.

If you have any sample PST files that *do* work with the current code,
that would allow me to compare the working PST with the broken PST,
which would be very helpful in tracking down where the problem is.

Until I can figure out the correct fix, I suggest you workaround this
bug by adding "return 1;" without quotes as the first line in the
valid_headers function. This way you can keep readpst working for your
customers while the correct fix is found. I believe that the modern PST
files that you have available are all valid files, while the
valid_headers function aims to detect broken files, so there should be
no risk to the conversion process for your case.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985249: libpano13-bin: format string bug in panoFileOutputNamesCreate()

[Wooseok Kang]

Package: libpano13-bin
Version: 2.9.20~rc2+dfsg-3
Severity: normal
X-Debbugs-Cc: kangwoos...@gmail.com

Dear Maintainer,

In libpano13, there is a format string vulnerability
that can lead to read and write arbitrary memory values.

The vulnerability starts in panoCroppingMain() in PTcommon.c.
The program get 'outputPrefix' using getopt() at line 1829.

1829 case 'p':
1830 if (strlen(optarg) < MAX_PATH_LENGTH) {
1831 strcpy(outputPrefix, optarg);
1832 } else {
1833 PrintError("Illegal length for output prefix");
1834 return -1;
1835 }
1836 break;

Then 'outputPrefix' is passed to sprintf() in panoFileOutputNamesCreate() 
without sanitizing.
This causes the format string bug which can crash the program.

1882 if (panoFileOutputNamesCreate(ptrOutputFiles, filesCount, outputPrefix) == 
0) {
1883 return -1;
1884 }

2915 sprintf( outputFilename, outputPrefix, i );
(in file.c)

There is a simple example of this vulnerability using 
tests/simpleTiff16/060520_3398.TIF.

> PTcrop -p "%p.%p.%p.%p" -f ./060520_3398.TIF
PTcrop Version 2.9.20 , by Daniel M German
Output prefix 1 %p.%p.%p.%p
Cropping 1 files
Processing 0 reading ./060520_3398.TIF creating 
(nil).0x1c.0x78302e296c696e28.tif
TIFFFetchNormalTag: Warning, Incorrect value for "RichTIFFIPTC"; tag ignored.

Thank you.

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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/16 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: unable to detect

Versions of packages libpano13-bin depends on:
ii  libc62.31-9
ii  libpano13-3  2.9.20~rc2+dfsg-3

libpano13-bin recommends no packages.

libpano13-bin suggests no packages.

-- no debconf information

Bug#322551: Sehr dringend !

[Advocate Louis Dibo]

*Herzliche Grüße!*



*Ich entschuldige mich für die Unterbrechung Ihrer täglichen Aktivitäten.
Ich habe Ihnen diese Nachricht zuvor gesendet, aber keine Antwort von Ihnen
erhalten. Deshalb sende ich sie erneut. Bitte nehmen Sie sich einen Moment
Zeit, um meine E-Mail zu lesen, da dies dringend erforderlich ist
Aufmerksamkeit und Sie werden davon profitieren,*

*Mein Name ist Barrister Louis Dibo, ich bin ein Rechtsanwalt, der im
Bereich der Familiengerichtsbarkeit arbeitet. Ich habe meinen Mandanten und
seine Familie durch einen Autounfall verloren. Er hat die Summe von ($
7,211,000.00 USD) bei seiner Bank, die in Kürze sein wird beschlagnahmt,
weil er ein Auftragnehmer hier in Kamerun war und auch schwere Haus- und
Straßenbaumaschinen liefert. Ich möchte, dass der Left-Fonds als Angehörige
der Familie in Ihre Obhut genommen wird, bevor dieser Fonds von den
leitenden Angestellten der Finanzgesellschaft beschlagnahmt wird Hier.*

*Der Grund, warum ich Sie in dieser Angelegenheit kontaktiert habe, ist,
dass Sie denselben Nachnamen wie mein verstorbener Kunde haben. Er stammt
ebenfalls aus Ihrem Land und es gibt keinen registrierten Namen als Erben
in seiner Kontodatei bei der Finanzgesellschaft. Antworten Sie einfach
dringend, um dies zu ermöglichen Ich möchte Ihnen alle notwendigen und
weiteren Informationen und Erläuterungen zu dieser Transaktion zum besseren
Verständnis geben, wenn Sie interessiert sind.*



*Ich wünsche Ihnen einen schönen Tag und warte auf Ihre schnelle Antwort!*

*Hochachtungsvoll!*

*Barr. Louis Dibo Esq.*

Bug#985248: gnuplot: format string bug in PS_load_fontfile()

[Wooseok Kang]

Package: gnuplot
Version: 5.4.1+dfsg1-1
Severity: normal
X-Debbugs-Cc: kangwoos...@gmail.com

Dear Maintainer,

In gnuplot, there is a format string vulnerability
that can lead to read and write arbitrary memory values.

In term/post.trm, the program get string from getenv() and pass it to sprintf() 
directly in line 1420.
This causes the format string bug which can crash the program.

1420 envcmd = getenv("GNUPLOT_TTFTOPFA");
1421 if (envcmd != NULL)
1422 sprintf(cmd,envcmd,current_ps_fontfile->fontfile_fullname);

Thank you.

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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/16 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: unable to detect

Versions of packages gnuplot depends on:
ii  gnuplot-qt [gnuplot-x11]  5.4.1+dfsg1-1

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
pn  gnuplot-doc  

-- no debconf information

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Paul Wise]

On Sun, 2021-03-14 at 21:44 -0400, Sandro Tosi wrote:

> but other paragraphs do (i think) :)

Ah, I see!

> there's no guarantee (althought i find it highly unlikely) that
> src:ppmd will not reach the same version of the old ppmd that used to
> be present in the archive a decade ago.

The requirement is easy to workaround though, by appending extra chars
to the affected versions, but that means remembering the requirement.
Of course just renaming the source package is a much simpler fix.

I think just uploading src:python-ppmd will fix this since src:ppmd
will get autoremoved by the dak decrufting since src:python-ppmd will
take over the binary packages of src:ppmd with newer versions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Sandro Tosi]

> > Per Policy 3.2.2 this is actually RC, and there is no length of time
> > after which it's Policy-compliant to reuse package name--version pairs:
> > "the version numbers which a binary package must not reuse includes the
> > version numbers of any versions of the binary package ever accepted into
> > the archive".
>
> The two ppmd source packages do not have any binary packages in common,
> so this paragraph of policy does not apply here.

but other paragraphs do (i think) :)

from 
https://www.debian.org/doc/debian-policy/ch-binary.html#uniqueness-of-version-numbers

```
The part of the version number after the epoch must not be reused for
a version of the package with different contents once the package has
been accepted into the archive, even if the version of the package
previously using that part of the version number is no longer present
in any archive suites.

This uniqueness requirement applies to the version numbers of source
packages and of binary packages, [...]
```

there's no guarantee (althought i find it highly unlikely) that
src:ppmd will not reach the same version of the old ppmd that used to
be present in the archive a decade ago.

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

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Paul Wise]

On Sun, 2021-03-14 at 18:34 -0700, Sean Whitton wrote:

> Per Policy 3.2.2 this is actually RC, and there is no length of time
> after which it's Policy-compliant to reuse package name--version pairs:
> "the version numbers which a binary package must not reuse includes the
> version numbers of any versions of the binary package ever accepted into
> the archive".

The two ppmd source packages do not have any binary packages in common,
so this paragraph of policy does not apply here.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Sandro Tosi]

> Per Policy 3.2.2 this is actually RC, and there is no length of time
> after which it's Policy-compliant to reuse package name--version pairs:
> "the version numbers which a binary package must not reuse includes the
> version numbers of any versions of the binary package ever accepted into
> the archive".
>
> Please take a look at that section of Policy.  Unfortunately, I think
> you're going to have to introduce an epoch.

meh, at this point i'd rather do a one-time only operation: remove
src:ppdm and reintroduce it as src:python-ppdm.

is there anything that i need to other than file a RM bug for src:ppdm
and then upload a new src:python-ppdm for making this transition
complete?

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

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Sean Whitton]

control: severity -1 serious

Hello Sandro,

On Sun 14 Mar 2021 at 09:17PM -04, Sandro Tosi wrote:

>> > well, ftp-masters approved this package since it passed thru NEW, if
>> > there was a concern on their side i'd expect them to have voiced out
>> > by now.
>>
>> From the #debian-ftp IRC channel:
>>
>>  that is against policy even if dak accepted it
>
> i see Sean is in cc here, so i'll let him explain if there's any
> technical implication of the fact ftp-masters accepted a package which
> had the same name of a previously renamed package.

To be clear, I intended to refer to Debian Policy, not anything
dak-related.  It's also worth noting that NEW processing is not perfect,
and something like this is especially difficult to catch :)

>> > no, i see no reason to do so: upstream chose the name `ppmd`
>>
>> The only thing I can think of is that using the previous name prevents
>> someone else from reintroducing the previous ppmd codebase.
>
> it's been removed since more than 6 years, i think if someone wants to
> reintroduce that project in debian, it's on them to find a
> non-conflicting name, no?

Per Policy 3.2.2 this is actually RC, and there is no length of time
after which it's Policy-compliant to reuse package name--version pairs:
"the version numbers which a binary package must not reuse includes the
version numbers of any versions of the binary package ever accepted into
the archive".

Please take a look at that section of Policy.  Unfortunately, I think
you're going to have to introduce an epoch.

-- 
Sean Whitton

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Paul Wise]

On Sun, 2021-03-14 at 21:17 -0400, Sandro Tosi wrote:

> i see Sean is in cc here, so i'll let him explain if there's any
> technical implication of the fact ftp-masters accepted a package which
> had the same name of a previously renamed package.

I expect there aren't any practical effects, except to things like the
derivatives census when it does diffs between source packages.

> it's been removed since more than 6 years, i think if someone wants to
> reintroduce that project in debian, it's on them to find a
> non-conflicting name, no?

Sure, perhaps they can use not-python-ppmd ;)

From my perspective this bug can now be closed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985231: TypeError: Cannot use 'in' operator to search for 'dependencies' in ../package.json

[James Valleroy]

Package: node-node-sass
Version: 4.14.1+git20200512.e1fc158+dfsg-4
Severity: important
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   * What led up to the situation?

I installed node-node-sass, and ran its installed binary node-sass.

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

Ran the command "node-sass". I tried running in different paths, with
different parameters, and on a different system, but the result was
the same.

   * What was the outcome of this action?

$ node-sass
/usr/share/nodejs/normalize-package-data/lib/fixer.js:138
  if (!(deps in data)) return
 ^

TypeError: Cannot use 'in' operator to search for 'dependencies' in 
../package.json
at Object. 
(/usr/share/nodejs/normalize-package-data/lib/fixer.js:138:18)
at Array.forEach ()
at Object.fixDependencies 
(/usr/share/nodejs/normalize-package-data/lib/fixer.js:137:41)
at /usr/share/nodejs/normalize-package-data/lib/normalize.js:32:38
at Array.forEach ()
at normalize 
(/usr/share/nodejs/normalize-package-data/lib/normalize.js:31:15)
at meow (/usr/share/nodejs/meow/index.js:146:2)
at Object. 
(/usr/lib/x86_64-linux-gnu/nodejs/node-sass/bin/node-sass:21:11)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)


   * What outcome did you expect instead?

Either no error message, or a more meaningful error message (in case I
used the command wrong).


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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 node-node-sass depends on:
ii  libc6 2.31-9
ii  libnode72 12.21.0~dfsg-1
ii  libsass1  3.6.4+20201122-1
ii  libstdc++610.2.1-6
ii  node-chalk4.1.0-1
ii  node-get-stdin8.0.0-1
ii  node-glob 7.1.6+~7.1.3-1
ii  node-globule  1.3.2-1
ii  node-gyp  7.1.2-4
ii  node-lodash   4.17.20+dfsg+~cs8.31.172-1
ii  node-meow 8.0.0+~cs3.21.0-2
ii  node-mkdirp   1.0.4+~1.0.1-1
ii  node-nan  2.14.2-2
ii  node-npmlog   4.1.2-2
ii  node-readable-stream  3.6.0-2
ii  node-source-map   0.7.0++dfsg2+really.0.6.1-7
ii  node-yargs15.3.1+repack-2
ii  nodejs12.21.0~dfsg-1

node-node-sass recommends no packages.

node-node-sass suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmBOfY4WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICG1dD/4v8dyYefhKc0hvITwf0sEz2BCs
yi5qcYMyXF4Xmi7svHJbyCiEdT6opxeO6tbtKxBf9+ct4QaaR0ooAp7v6MZRetN9
pFESYqH2UYTXRCGMctb3+8GM7LPGa7utY+Qdc+7yeNePtnltdji5O8A5yFPm3LxQ
fuziGVv8nJlpaG410YtJXEEUoZwX9sLNWNpL2JHYyYVzbL/3EHq7yB7L/6S6ihLW
ZeFYvib7Hn1ycycxIELdVgleh9pQmOZ7MRDGjmhmQpcWfP4KZRm0kXRb88d5l8sT
6OMjT2acZQyrlVgePas/HOLZWErONikyOVJnPRZxT0WQrY6r6UBUGjpOG1oa4OeH
lu02yZmTYfw/B8AUbm4tOZPtsN8zC/oR/qq6HoainKjj8oi1kgUb0mM8psahE73M
UtCM+JQLzPvAOS0e29v2t7RI6oKC6KxX9d0Ho3OpPe1pHbX+drxiuOVnBPsLvLmw
Ev6nwpmM4VJaSkVP/LewqUYmReRZQAa3+a+KFn1Ef0erz7gyGg4Ij+qyvtv/B886
QLbE7JhecOPBmPh5nUdDnQXWfl86mH/d3mCK9Hff729REuYQOQWQ75Qw/e/bf3b9
EEJzYb50zp/7cfy9mwJGRIjVfSX8DU9iQqSbrLRlxgmcgtdv3tCDOeAo71c6alkp
lU7UZnc8GpTCh/4fug==
=eA7E
-END PGP SIGNATURE-

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Sandro Tosi]

> > well, ftp-masters approved this package since it passed thru NEW, if
> > there was a concern on their side i'd expect them to have voiced out
> > by now.
>
> From the #debian-ftp IRC channel:
>
>  that is against policy even if dak accepted it

i see Sean is in cc here, so i'll let him explain if there's any
technical implication of the fact ftp-masters accepted a package which
had the same name of a previously renamed package.

> > no, i see no reason to do so: upstream chose the name `ppmd`
>
> The only thing I can think of is that using the previous name prevents
> someone else from reintroducing the previous ppmd codebase.

it's been removed since more than 6 years, i think if someone wants to
reintroduce that project in debian, it's on them to find a
non-conflicting name, no?

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

Bug#985246: aux.c: use "snprintf()" instead of "sprintf()"

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From c96c7b634c1024e3cebdad7d66575f0ed16d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 15 Mar 2021 01:01:21 +
>Subject: [PATCH] aux.c: use "snprintf()" instead of "sprintf()"

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

diff --git a/aux.c b/aux.c
index 0a35174..f5c3a87 100644
--- a/aux.c
+++ b/aux.c
@@ -616,7 +616,7 @@ aux.c:...: warning: the address of 'fname' will always 
evaluate as 'true'
temp_file, final);
system(buf);
if (mailer_pipe_input) {
-   sprintf(buf, "%s < %s", mailer_program, final);
+   snprintf(buf, NBUF, "%s < %s", mailer_program, final);
x = system(buf);
} else {
strncpy(buf, mailer_program, 50);
@@ -683,7 +683,7 @@ aux.c:...: warning: the address of 'fname' will always 
evaluate as 'true'
fprintf(rec, "From %s %s", logname, ctime(&t));
fprintf(rec, "From: %s\n", logname);
fclose(rec);
-   sprintf(buf, "cat %s >> %s", temp_file, record);
+   snprintf(buf, NBUF, "cat %s >> %s", temp_file, record);
system(buf);
}
 }
-- 
2.30.1



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Paul Wise]

On Sun, 2021-03-14 at 21:02 -0400, Sandro Tosi wrote:

> it is a new project

Thanks for clarifying.

> well, ftp-masters approved this package since it passed thru NEW, if
> there was a concern on their side i'd expect them to have voiced out
> by now.

From the #debian-ftp IRC channel:

 that is against policy even if dak accepted it

> no, i see no reason to do so: upstream chose the name `ppmd`

The only thing I can think of is that using the previous name prevents
someone else from reintroducing the previous ppmd codebase.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Sandro Tosi]

> src:ppmd has been reintroduced with lower version number than before it
> was removed and as far as I can tell with a different upstream project.

it is a new project

> I expect this will confuse the BTS version tracking

all bugs were closed, so what confusion will it generate?

> and seems like it
> violates some aspect of Debian or ftp-master policy, but I'm not sure.

well, ftp-masters approved this package since it passed thru NEW, if
there was a concern on their side i'd expect them to have voiced out
by now.

> The consequences to user systems should be minimal since the two source
> packages produce different binary packages.

> Should the new source package be renamed to python-ppmd?

no, i see no reason to do so: upstream chose the name `ppmd` and
there's no requirement to prepend `python-` to python-related
packages.

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

Bug#972726: dh-python: uninstallable when python-is-python2 is installed

[Norman Rasmussen]

Package: dh-python
Version: 4.20201102+nmu1
Followup-For: Bug #972726

Note that python-is-python2 (2.7.18-8) provides python (= 2.7.18-1), so
the breaks has to be python (<< 2.7.18-1), otherwise it will conflict
with python provided by python-is-python2.


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dh-python depends on:
ii  python33.9.2-2
ii  python3-distutils  3.9.2-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.20.7.1
ii  libdpkg-perl  1.20.7.1

-- no debconf information

Bug#985245: src:ppmd: reintroduced with lower version number, different project?

[Paul Wise]

Source: ppmd
Version: 0.3.3-1
Severity: normal

src:ppmd has been reintroduced with lower version number than before it
was removed and as far as I can tell with a different upstream project.

I expect this will confuse the BTS version tracking and seems like it
violates some aspect of Debian or ftp-master policy, but I'm not sure. 

The consequences to user systems should be minimal since the two source
packages produce different binary packages.

Should the new source package be renamed to python-ppmd?

Any further thoughts?

https://tracker.debian.org/pkg/ppmd
https://sources.debian.org/src/ppmd/

https://sources.debian.org/src/ppmd/0.3.3-1/
https://sources.debian.org/src/ppmd/0.3.3-1/debian/control
https://sources.debian.org/src/ppmd/0.3.3-1/debian/watch

https://sources.debian.org/src/ppmd/10.1-5/
https://sources.debian.org/src/ppmd/10.1-5/debian/control
https://sources.debian.org/src/ppmd/10.1-5/debian/watch

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985244: exim4-config: Misleading documentation on enabling SSL

[Jorrit Fahlke]

Package: exim4-config
Version: 4.92-8+deb10u4
Severity: important
Tags: security

Dear Maintainer,

When configured using the 'smarthost' or 'satellite' configuration from
exim4-config 4.92-8+deb10u4 (Debian 10 / buster), that configuration will by
default not enforce encrypted connections to the smarthost.  There is
documentation in README.Debian.gz on how to enable encryption, but the steps
laid out there have no effect, and Exim can still fall back to using
unencrypted connection when connecting to the smarthost.  And even if an
encrypted connection is used, the certificate of the server is not verified.

Workaround
--

Set

  hosts_require_tls = *
  tls_verify_hosts = *

on the remote_smtp_smarthost transport.  Any encrypted connection for which
certificate verification fails will be closed, and delivery will be deferred.
The client Exim will never use unencrypted connections to the smarthost.

Alternatively, the same effect can be achieved by setting

  REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
  REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = *

in /etc/exim4/conf.d/main/000_localmacros, although the latter one is only
available since Debian 11 (bullseye).

Details
===

When configuring Exim to use a smarthost by name
(e.g. `smarthost.example.com`, but not `smarthost.example.com/MX`) and to
encrypt the connection to the smarthost, I expect Exim to
- require encryption (no fallback to an unencrypted connection),
- verify the certificate (e.g. validity period, purpose, etc),
- verify that the certificate is (recursily) signed by a trusted CA,
- require the configured hostname to match the certificate,
- and to refrain from using the connection if any of the above steps fail.

This is what I'll call _fully verified SSL_.  Connections that use encryption
but don't ensure that all of those verification steps succeed I'll call
_unverified SSL_.

I'm excluding smarthosts looked up via MX records here, because I'm currently
not in that situation, and also I have no clue how that is supposed to be
matched to certificates.  So I have no expectations there.

To avoid the mail content being intercepted between client and smarthost, I'd
like to require fully verified SSL on that connection.
`/usr/share/doc/exim4/README.Debian.gz`, section 2.2.1. "Exim 4 as TLS/SSL
client" explains that

> Exim will use TLS via STARTTLS automatically as client if the server Exim
> connects to offers it.

This is opportunistic SSL/TLS, which makes sense in the context of independent
mailservers talking with each other.  As a client talking to a smarthost, I
should know whether the server supports TLS or not, and in the case considered
here it does support it.  In this situation, doing SSL/TLS opportunistically
will lower security.

The documentation then goes on to talk about client certificates.  Sandwiched
between two paragraphs dealing with those is a paragraph

> The certificate presented by the remote host is not checked unless you
> specify a tls_verify_certificate option on the transport.

So to enable verification of certificates I need to set an option.  Nowhere
does it say how to switch from opportunistic encryption to required and fully
verified SSL.  But verifying the certificate does not really make sense in an
opportunistic setting, where the client is prepared to fall back to an
unencrypted connection.  So from that documentation I'd consider it is
reasonable to assume that by turning on that option I will implicitly make
fully verified SSL mandatory.

What should the option be set to?  `README.Debian.gz` does not say.  Exim's
`spec.info` does not know that option either, strictly speaking, but there is
a setting on the smtp transport named `tls_verify_certificates` (note the `s`
at the end), so let's go with that.

`spec.info` says in "Private options for smtp":
```
‘tls_verify_certificates’Use: _smtp_ Type: Default:
 _string_*__   _system_

   The value of this option must be either the word "system" or the
absolute path to a file or directory containing permitted certificates
for servers, for use when setting up an encrypted connection.

   The "system" value for the option will use a location compiled into
the SSL library.  [...]

[...]

   For back-compatibility, if neither tls_verify_hosts nor
tls_try_verify_hosts are set (a single-colon empty list counts as being
set) and certificate verification fails the TLS connection is closed.
```

So, this option actually has a default value `system`, which seems to imply
reasonable behaviour.  The last paragraph also sounds reasonable: if no host
is explicitly configured to be checked, then check every host.  Closing the
TLS connection on verification failure sounds reasonable as well (what else
would you do?).  So from this I'd expect that after setting that option to
`system` I'll definitely require fully verified SSL.

It's a bit odd that `README.Debian.gz` instructs me to set an option that
already h

Bug#984976: mumble: Keyboard shortcuts can't be assigned

[Chris Knadle]

tags 984976 + moreinfo
thanks

Pelle:

Package: mumble
Version: 1.3.4-1
Severity: normal

Dear Maintainer,

In the "Shortcuts" settings, when I add a new shortcut and click in the
"Shortcut" column, a "Press Shortcut" label is shown. However, it is not
possible to assign a shortcut, regardless of which key is pressed, and the
"Press Shortcut" label remains, until I click somewhere else.

I expected a key name to be listed in the "Shortcut" column after I pressed th
key while the "Press Shortcut" label was visible. This issue may be because I'm
running a Wayland compositor (Sway).


I've tested adding shortcuts for mumble 1.3.4-1 and it seems to work as expected 
in the Debian Sid VM I use for testing and using mumble, which uses the Xfce 
window manager (and does not use Wayland).


Just to double-check the procedure for setting a shortcut:
  1. Press "Add" to add a shortcut
  2. On the added shortcut, under the "shortcut" label, click on the blank area 
for the shortcut under the "Shotcut" tab

  3. After clicking in the blank area, "Press Shortcut" appears
  4. Press the desired key and/or mouse button for the desisred shortcut
  5. Click the area under the "Function" tab for the shortcut (which starts off 
with "Unassigned") to assign the shortcut function


The order of these steps is optional, i.e. item (5.) above can be done before 
item (2.)


From the description of the bug I think these steps were done correctly, and 
that the underlying issue might be something to do with how keyboard and mouse 
input is done with Wayland, but I'd like a little more information. More 
specifically I'd like to know which window manager and/or desktop environment is 
in use, because I've repeatedly seen bugs with tiling window managers with 
Mumble where non-tiling window managers don't seem to show the symptoms.


Thanks
   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#977694: #977694 is fixed by initramfs-tools 0.140

[Ryutaroh Matsumoto]

Control: reassign -1 initramfs-tools 0.139
Control: tags -1 + pending

#977694 is going to be fixed by the commit
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/a930e9a448d807cd23632c095a45d48842ff2f24

Ryutaroh

Bug#972726: dh-python: uninstallable when python-is-python2 is installed

[Norman Rasmussen]

Package: dh-python
Version: 4.20201102+nmu1
Followup-For: Bug #972726

I think this is due to the fix for #966832, which added breaks python.
I think that was reported as #968046, which was fixed by adding a
versioned breaks python2, but did not change the breaks python.

I assume the breaks on python should be versioned similar to the breaks
python2?

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dh-python depends on:
ii  python33.9.2-2
ii  python3-distutils  3.9.2-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.20.7.1
ii  libdpkg-perl  1.20.7.1

-- no debconf information

Bug#984850: qalculate-gtk (ITA)

[Norbert Preining]

Hi Phil, hi James,

On Sun, 14 Mar 2021, Phil Morrell wrote:
> Excellent I was hoping that would happen, though I only created the new
> micro team a couple of days ago! We must have been working on it at the

Thanks for creating it!

> https://salsa.debian.org/debian/libqalculate/-/tree/debian/master
> NB. I've only merged 3.17.0, haven't reviewed changes yet e.g. manpage

Yeah, updating to some recent 3.N version is good. But nothing is urgent
now since we cannot push that out to unstable/testing for bullseye.

> The version in bullseye does not have autopkgtests, so if you think it's
> worth the effort to update the metadata, then please upload away. Are
> you on IRC, or just email? I'm emorrp1 wherever you find me.

I don't think it makes sense to invest any time in the current status
of bullseye unless bugs show up. We should concentrate on master branch
with 3.N data and get that into shape. Just MHO

Concerning IRC, yes, I hang around in a few chat rooms, any specific you
are around normally? On debian irc I am usually in #debian-ai,
#debian-kde, #debian-private, #debian-qt-kde, pluse some others on other
servers. Username normally norbert or norb.


On Sun, 14 Mar 2021, James Lu wrote:
> I've been a longtime Qalculate user and I'm also willing to help keep
> qalculate-gtk + libqalculate up to date.

Great, having a small team working on it usually makes thing easier and
smoother. From my side all fine!

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#985243: exim4: incorrectly accepts certificates for CNAME targets

[Jorrit Fahlke]

Package: exim4
Version: 4.92-8+deb10u4
Severity: important
Tags: fixed-upstream, security
Control: fixed -1 4.94-15

Dear Maintainer,

When Exim is configured to verify certificates against hostnames and hostname
resolution yields a CNAME, then Exim will verify the certificate against the
canonical name rather than the original hostname.

An attacker with control over the network (e.g. a rogue public wifi) can forge
CNAME records to point to a hostname under their control.  They can then
obtain a legitimate certificate for the host under their control, which Exim
will accept as valid for the host it intended to connect to.

The attacker can thus
- obtain cleartext of credentials the victim needs to connect to e.g. a
  smarthost
- read and manipulate mail text

Note that by default, Exim does opportunistic SSL for most connection,
allowing fallback to unencrypted connections.  For such connection there is no
expectation of any protection anyway, so this flaw is of little importance.
However, when exim is configured to deliver mail to a smarthost, such as when
setting dc_eximconfig_configtype='smarthost' or 'satellite', it make sense to
also configure it to require encryption and successful certificate
verification for the connection to the smarthost.  Such configurations are
also likely to use credentials to authenticate against the smarthost, which
the attack described above can reveal.

This affects exim4 4.92-8+deb10u4 from Debian 10 (buster).  Upstream patched
this some time ago already, and the patch already has made it into Debian 11
(bullseye), e.g. exim4 4.94-15.

The upstream patch is this one, I believe:
--
0851a3bbf4667081d47f5d85b6b3a5cb33cbdba6
Author: Jeremy Harris 
AuthorDate: Thu Jun 11 20:21:38 2020 +0100
Commit: Jeremy Harris 
CommitDate: Thu Jun 11 20:30:18 2020 +0100

TLS: use RFC 6125 rules for certifucate name checks when CNAMES are present. 
Bug 2594
--

This was initially reported 2020-09-04 to secur...@debian.org.

Regards,
Jorrit Fahlke.

-- Package-specific info:
Exim version 4.92 #5 built 13-May-2020 16:01:31
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='censored'
dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.28.1'
dc_readhost='censored'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='192.168.28.2'
dc_smarthost='127.0.0.1::26'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:censored
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on

Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko

[Ryutaroh Matsumoto]

Hi Lucas,

> According to strace, it fails because /dev/dri does not exist.

When vc4.ko is not loaded, /dev/dri does not exist.
If vc4.ko is loaded, /dev/dri exists. Could you make sure that
vc4.ko is loaded by "lsmod | fgrep vc4"?
vc4.ko was disabled at Debian kernel 5.10.9.
Other Debian 5.10.? kernel packages have vc4.ko.

When vc4.ko is not loaded, kmscube fails as:

Script started on 2021-03-15 09:02:32+09:00 [TERM="linux" TTY="/dev/tty3" 
COLUMNS="480" LINES="135"]
root@raspi4b8gb:/tmp# kmscube
drmGetDevices2 failed: No such file or directory
could not open drm device
failed to initialize legacy DRM
root@raspi4b8gb:/tmp# exit
Script done on 2021-03-15 09:02:40+09:00 [COMMAND_EXIT_CODE="255"]

When vc4.ko is loaded, kmscube fails as:

$ kmscube
Using display 0xe087a150 with EGL version 1.4
===
EGL information:
  version: "1.4"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_device_base EGL_EXT_device_enumeration 
EGL_EXT_device_query EGL_EXT_platform_base 
EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug 
EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland 
EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_gbm 
EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless"
  display extensions: "EGL_ANDROID_blob_cache EGL_EXT_buffer_age 
EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers 
EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context 
EGL_KHR_create_context_no_error EGL_KHR_fence_sync 
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace 
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image 
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image 
EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context 
EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float 
EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_image_dma_buf_export 
EGL_MESA_query_driver "
===
OpenGL ES 2.x information:
  version: "OpenGL ES 3.2 Mesa 20.3.4"
  shading language version: "OpenGL ES GLSL ES 3.20"
  vendor: "Mesa/X.org"
  renderer: "llvmpipe (LLVM 11.0.1, 128 bits)"
  extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays 
GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 
GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA 
GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint 
GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 
GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D 
GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float 
GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float 
GL_EXT_draw_instanced GL_EXT_texture_sRGB_decode GL_OES_EGL_image 
GL_OES_depth_texture GL_OES_packed_depth_stencil 
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render 
GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer 
GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments 
GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object 
GL_OES_viewport_array GL_ANGLE_pack_reverse_row_order 
GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 
GL_EXT_occlusion_query_boolean GL_EXT_robustness GL_EXT_texture_rg 
GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth 
GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers 
GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness 
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object 
GL_OES_depth_texture_cube_map GL_OES_required_internalformat 
GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_sRGB_write_control 
GL_EXT_separate_shader_objects GL_EXT_shader_group_vote 
GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix 
GL_EXT_tessellation_point_size GL_EXT_tessellation_shader 
GL_ANDROID_extension_pack_es31a GL_EXT_base_instance 
GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image 
GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 
GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_render_snorm 
GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer 
GL_EXT_texture_cube_map_array GL_EXT_texture_norm16 GL_EXT_texture_view 
GL_KHR_blend_equation_advanced GL_KHR_context_flush_control 
GL_KHR_robust_buffer_access_behavior GL_NV_image_formats GL_OES_copy_image 
GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 
GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables 
GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation 
GL_OES_tessellation_point_size GL_OES_tessellation_shader 
GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array 
GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array 
GL_OES_texture_view GL_EXT_blend_func_extended GL_EXT_buffer_storage 
GL_EXT_float_ble

Bug#984850: qalculate-gtk (ITA)

[Phil Morrell]

On Sun, Mar 14, 2021 at 09:07:40AM +0900, Norbert Preining wrote:
> Great, thanks a lot! I have joined the tracker team for qalculate, and
> pushed the debian/bullseye branch which contains the last NMU currently
> in unstable and testing.

Excellent I was hoping that would happen, though I only created the new
micro team a couple of days ago! We must have been working on it at the
same time because I pushed the new version about the same time as you.

https://salsa.debian.org/debian/libqalculate/-/tree/debian/master

NB. I've only merged 3.17.0, haven't reviewed changes yet e.g. manpage

> Phil, what about the following
>   Maintainer: team+qalcul...@tracker.debian.org
>   Uploaders: Phil Morrell ,
>   Norbert Preining 
> I am happy to help out since we need it for cantor.
> 
> It might be a good idea to upload both packages to unstable with fixed
> maintainer entry so that bugs in stable will not go forever to Vincent.

The version in bullseye does not have autopkgtests, so if you think it's
worth the effort to update the metadata, then please upload away. Are
you on IRC, or just email? I'm emorrp1 wherever you find me.


signature.asc
Description: PGP signature

Bug#985242: png: iCCP: known incorrect sRGB profile

[Ben Hildred]

Package: gimp
Version: 2.10.8-2
Severity: normal

Dear Maintainer,

libpng version 1.6 introduced more strict checking of color profiles and gimp
can when editing some images and exporting them as png cause problems with some
viewers (specifically it was causing an incorrect color temp and warning in
xloadimage, and a warning in xli). To mitigate this I post processed with
mogrify.



-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (500, 'stable'), (100, 'buster-fasttrack')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgs9   9.27~dfsg-2+deb10u4
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.3.2-2~deb10u1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4.1+deb10u1
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   8.3.0-6
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1+deb10u1
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-1
pn  gimp-python   
pn  gvfs-backends 
ii  libasound21.1.8-1

-- no debconf information

Bug#985241: RFS: golang-github-rkoesters-xdg/0.0~git20181125.edd15b8-1 [ITP] -- FreeDesktop.org (xdg) Specs implemented in Go

[Micheal Waltz]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-rkoesters-xdg":

 * Package name: golang-github-rkoesters-xdg
   Version : 0.0~git20181125.edd15b8-1
   Upstream Author : Ryan Koesters 
 * URL : https://github.com/rkoesters/xdg
 * License : BSD-3-clause
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-rkoesters-xdg
   Section : devel

It builds those binary packages:

  golang-github-rkoesters-xdg-dev - FreeDesktop.org (xdg) Specs implemented in 
Go

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

  https://mentors.debian.net/package/golang-github-rkoesters-xdg/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-rkoesters-xdg/golang-github-rkoesters-xdg_0.0~git20181125.edd15b8-1.dsc

Changes for the initial release:

 golang-github-rkoesters-xdg (0.0~git20181125.edd15b8-1) unstable; 
urgency=medium
 .
   * New upstream version 0.0~git20181125.edd15b8
   * Ignore quilt dir .pc via .gitignore
   * Initial packaging (Closes: #985179)

-- 
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15  3D1F 4FA2 70F5 CD36 71F9


signature.asc
Description: PGP signature

Bug#985227: ITP: awesomplete -- Ultra lightweight, customizable, simple autocomplete widget

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: awesomplete
  Version : 1.1.5
  Upstream Author : Lea Verou 
* URL : https://projects.verou.me/awesomplete/
* License : Expat
  Programming Lang: JS, CSS
  Description : Ultra lightweight, customizable, simple autocomplete widget

Awesomplete is an ultra lightweight, customizable, simple autocomplete
widget with zero dependencies, built with modern standards for modern
browsers.

Awesomplete is needed for Shaarli frontend (#980134). It will be
maintained in JS team.

I noticed another RFP (#892813) for libjs-awesomplete-avoid-xss, a
fork of awesomplete. However, this fork has not kept up with new
upstream versions. It is a small patch though, and (if there is
interest) could be updated and applied within the awesomplete
package. The effect of applying this patch would be that suggestions
cannot be rendered as HTML, however this is not relevant for Shaarli.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmBOYe0WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICLgvEACTP/pD5kBIf0hnJo2PhFtMqtOo
f2oGADIx9ZhA1Kjqc1CbpjB/YCr+tM5wI/CehGKPrK1t2SzEXHbEQQ7P/00QBpJC
Z4m+FlAaKiJzqmau7FidoaEoag6GaqCnmNtNFq2KroaeStxSjCuUFA7hy07G26HJ
7UmyKp9ZFMwG6D+pe02RfQ7LJf9p6qRoROgioZpZ8F1t/ZHBwPtAJutVH8vtetH1
Kcbu+4Ky6fsqMCaeMZfoWFXWYu4T5Du7p/TL3mRwfvHIjVonCSAOJ8u747609Qwe
/fG4We1FmUKe5etLLK7lDv1D5tZDxKBG6ksT9WWLVkjaUmhUTBNJGlEAxYcf01a0
6G8RyT/8LrqIafYquNAV1w2Rs1ifpOhOK9GEkf7OujPqy4Bkk/1HdV2/e+6FEIva
umjdCZrB65vOWBvTCf5JuFui1ipH2JfcyO+YDEoxZJWjYx9CfBJasTfzwAO5yY1W
urRrChx4vyOptug3huGeYrGqfo/AsMRmBQHRPof8sdZ/uA7w1yIDyngV9K5IzWdF
BpS/w83ejMyRGP5H3Nq9ze3Oo4zQCitBFGr1iAYFVahiZIWOUWOJjN8NOPhdL7gd
PIio4MsPgp7NdqX7rCZ1EH8K/eptGzTy1C6LW38MQzpu8izDtzXBUYPHV9CYGuxD
fz6n8KxS9eQoBywKEw==
=YJW3
-END PGP SIGNATURE-

Bug#985142:

[Michel Le Bihan]

Hello,

This should be fixed in
https://salsa.debian.org/mimi8/chromium/-/commit/13d089e2059a8a09bd3d0611826ccc3e43293e0a
that is waiting to be sponsored.

Bug#984926:

[Michel Le Bihan]

Hello,

This should be fixed in
https://salsa.debian.org/mimi8/chromium/-/commit/13d089e2059a8a09bd3d0611826ccc3e43293e0a
that is waiting to be sponsored.

Michel Le Bihan

Bug#985240: db.c: declare parameter "mode" in "open_master()" to be unused

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 169f71432e29750e90fe91851ed1fb9d2ce73223 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 14 Mar 2021 22:56:46 +
>Subject: [PATCH] db.c: declare parameter "mode" in "open_master()" to be
> unused

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

diff --git a/db.c b/db.c
index 2fec992..251be35 100644
--- a/db.c
+++ b/db.c
@@ -539,7 +539,7 @@ make_master_copy(int force_copy)
 int only_newsrc_groups = 0;
 
 void
-open_master(int mode)
+open_master(int mode __attribute__ ((unused)))
 {
 register group_header *gh;
 
-- 
2.30.1



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985239: rspamd should depend on publicsuffix

[Christer Mjellem Strand]

Package: rspamd
Version: 2.7-1~bpo10+1
Severity: normal

Dear Maintainer,

rspamd is currently shipping its own bundled copy of the public suffix list 
(see publicsuffix.org),
as /usr/share/rspamd/effective_tld_names.dat. It should instead depend on the 
publicsuffix package,
where this list is maintained, and use it from 
/usr/share/publicsuffix/effective_tld_names.dat.

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rspamd depends on:
ii  adduser 3.118
ii  ca-certificates 20210119
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-1
ii  init-system-helpers 1.56+nmu1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-2+deb10u2
ii  libhyperscan5   5.1.0-1
ii  libicu6363.1-6+deb10u1
ii  libjs-bootstrap44.5.2+dfsg1-6
ii  libjs-jquery3.5.1+dfsg-4~bpo10+1
ii  libjs-requirejs 2.3.6-1
ii  libluajit-5.1-2 2.1.0~beta3+dfsg-5.1
ii  libpcre2-8-010.32-5
ii  libsodium23 1.0.17-1
ii  libsqlite3-03.27.2-3+deb10u1
ii  libssl1.1   1.1.1d-0+deb10u5
ii  libstdc++6  8.3.0-6
ii  libunwind8  1.2.1-10~deb10u1
ii  lsb-base10.2019051400
ii  perl5.28.1-6+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages rspamd recommends:
ii  redis-server  5:6.0.10-4~bpo10+1

rspamd suggests no packages.

-- no debconf information

Bug#985238: glewlwyd fails to install during dbconfig-common when using postgres

[Florian Küpper]

Package: glewlwyd
Version: 2.5.2-

Postgres-client Version: 13.2-1

root@auth:~# dpkg -l|grep postgresql-clien*
ii  postgresql-client 13+225 all  front-end programs 
for PostgreSQL (supported version)
ii  postgresql-client-13  13.2-1 amd64    front-end programs 
for PostgreSQL 13
ii  postgresql-client-common  225 all  manager for multiple 
PostgreSQL client versions

root@auth:~#

When instaling glewlwyd on postresql on a fresh bullseye vm , I get an 
error from dbconfig-common.


root@auth:~# apt-get -y install glewlwyd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  rnbyc
The following NEW packages will be installed:
  glewlwyd
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/474 kB of archives.
After this operation, 1,696 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package glewlwyd.
(Reading database ... 37317 files and directories currently installed.)
Preparing to unpack .../glewlwyd_2.5.2-1_amd64.deb ...
Unpacking glewlwyd (2.5.2-1) ...
Setting up glewlwyd (2.5.2-1) ...
Created symlink 
/etc/systemd/system/multi-user.target.wants/glewlwyd.service → 
/lib/systemd/system/glewlwyd.service.

Add user glewlwyd
dbconfig-common: writing config to /etc/dbconfig-common/glewlwyd.conf

Creating config file /etc/dbconfig-common/glewlwyd.conf with new version

Creating config file /etc/glewlwyd/glewlwyd-db.conf with new version
creating postgres user glewlwyd:  success.
verifying creation of user: success.
creating database glewlwyd: success.
verifying database glewlwyd exists: success.
dbconfig-common: flushing administrative password
/usr/lib/postgresql/13/bin/psql: invalid option -- 'u'
Try "psql --help" for more information.
dpkg: error processing package glewlwyd (--configure):
 installed glewlwyd package post-installation script subprocess 
returned error exit status 1

Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
 glewlwyd
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@auth:~#


I have stopped trying to force it, since I would like to have automatic 
db mirgrations on upgrade.


I can report that installing with mariadb-server works :

...

...

Creating config file /etc/dbconfig-common/glewlwyd.conf with new version

Creating config file /etc/glewlwyd/glewlwyd-db.conf with new version
checking privileges on database glewlwyd for glewlwyd@localhost: user 
creation needed.

granting access to database glewlwyd for glewlwyd@localhost: success.
verifying access for glewlwyd@localhost: success.
creating database glewlwyd: success.
verifying database glewlwyd exists: success.
dbconfig-common: flushing administrative password
Start Glewlwyd service
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-9) ...
root@auth:~#

Bug#985080: Akonadi server crashes because of Apparmor rules

[bs.net]

Hi hefee,

I think I found the cause for the Apparmor messages and the crash.

The package plasma-workspace needs the virtual package default-dbus-session-
bus or dbus-session-bus.
This dependency is fulfilled by the package dbus-user-session as well as by 
dbus-x11.
On my system the package dbus-x11 was installed, which apparently triggers the 
messages or the rules of akonadi-server are aligned to dbus-user-session.
I therefore installed the package dbus-user-session and then deleted dbus-x11. 
After that all messages except one and the akonadi server crashes do not occur 
anymore. 

The only message I continue to receive is:
Mär 14 22:49:00 mcp kernel: audit: type=1400 audit(1615758540.971:29): 
apparmor="DENIED" operation="open" profile="/usr/bin/akonadiserver" name="/usr/
local/share/mime/mime.cache" pid=2305 comm=5468726561642028706F6F6C656429 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Maybe it should be pointed out that the Akonadi server can not be used with 
dbus-11.

Many kind regards
Sascha

Bug#985237: ITP: x-tile -- Tile selected windows in different ways

[Fabio Augusto De Muzio Tobich]

Package: wnpp
Severity: wishlist
Owner: Fabio Augusto De Muzio Tobich 
X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com

* Package name: x-tile
  Version : 3.3
  Upstream Author : Giuseppe Penone 
* URL : https://www.giuspen.com/x-tile/
* License : GPL-2+
  Programming Lang: Python
  Description : Tile selected windows in different ways

X-tile is an application that allows you to select a number of
windows and tile them in different ways. Works on any X desktop.

Main features include:
 * Several tiling geometries
 * Undo tiling
 * Invert tiling order
 * Optional system tray docking and menu
 * Filter to exclude windows
 * Filter to include windows by default
 * Command line interface

Bug#985236: RFS: python-mockito/1.2.2-1 [ITP] -- Spying framework for Python

[Fabrice Bauzac-Stehly]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-mockito":

 * Package name: python-mockito
   Version : 1.2.2-1
   Upstream Author : https://github.com/kaste/mockito-python/issues
 * URL : https://github.com/kaste/mockito-python
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-mockito
   Section : python

It builds these binary packages:

  python3-mockito - Spying framework for Python
  python-mockito-doc - Spying framework for Python - documentation

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

  https://mentors.debian.net/package/python-mockito/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-1.dsc

Changes since the last upload:

 python-mockito (1.2.2-1) unstable; urgency=low
 .
   * Initial release. Closes: #981067

Thanks!

Best regards
-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#985235: unblock: libpam-krb5/4.9-2

[Russ Allbery]

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

Please unblock package libpam-krb5

[ Reason ]
Apply an upstream patch to prevent a double free if
krb5_cc_get_principal fails on the newly-acquired ticket cache.

[ Impact ]
My guess is that this isn't exploitable because I don't think
an attacker can trigger the error condition, but a user of the
module did run into it, so I'd rather be safe than sorry.  It is
a double free, so if I'm wrong, it could potentially lead to
code execution or other security issues.

[ Tests ]
Passed CI tests with both Kerberos and Heimdal.

[ Risks ]
Trivial one-line patch, so the risk of updating the package
should be minimal.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libpam-krb5/4.9-2
diff -Nru libpam-krb5-4.9/debian/changelog libpam-krb5-4.9/debian/changelog
--- libpam-krb5-4.9/debian/changelog2020-03-30 19:46:43.0 -0700
+++ libpam-krb5-4.9/debian/changelog2021-03-14 12:31:39.0 -0700
@@ -1,3 +1,10 @@
+libpam-krb5 (4.9-2) unstable; urgency=medium
+
+  * Apply upstream patch to avoid a double free if calling
+krb5_cc_get_principal on the new cache fails.
+
+ -- Russ Allbery   Sun, 14 Mar 2021 12:31:39 -0700
+
 libpam-krb5 (4.9-1) unstable; urgency=high
 
   * New upstream release.
diff -Nru 
libpam-krb5-4.9/debian/patches/0001-Avoid-double-free-of-ctx-princ-in-a-failure-case.patch
 
libpam-krb5-4.9/debian/patches/0001-Avoid-double-free-of-ctx-princ-in-a-failure-case.patch
--- 
libpam-krb5-4.9/debian/patches/0001-Avoid-double-free-of-ctx-princ-in-a-failure-case.patch
  1969-12-31 16:00:00.0 -0800
+++ 
libpam-krb5-4.9/debian/patches/0001-Avoid-double-free-of-ctx-princ-in-a-failure-case.patch
  2021-03-14 12:31:39.0 -0700
@@ -0,0 +1,40 @@
+From: Russ Allbery 
+Date: Sat, 30 Jan 2021 11:55:44 -0800
+Subject: Avoid double free of ctx->princ in a failure case
+
+When re-retrieving the authenticated principal from the current cache,
+ensure the stored principal in the authentication context is always
+either valid or NULL.  Otherwise, a failure of krb5_cc_get_principal
+could result in a double free.  Thanks to Michael Muehle for the
+report.
+
+Fixes #20
+---
+ module/account.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/module/account.c b/module/account.c
+index 211975a..c270c9b 100644
+--- a/module/account.c
 b/module/account.c
+@@ -5,7 +5,7 @@
+  * user's authorization against .k5login (or whatever equivalent we've been
+  * configured for).
+  *
+- * Copyright 2005-2009, 2014, 2020 Russ Allbery 
++ * Copyright 2005-2009, 2014, 2020-2021 Russ Allbery 
+  * Copyright 2011
+  * The Board of Trustees of the Leland Stanford Junior University
+  * Copyright 2005 Andres Salomon 
+@@ -78,8 +78,10 @@ pamk5_account(struct pam_args *args)
+  */
+ if (ctx->cache != NULL) {
+ putil_debug(args, "retrieving principal from cache");
+-if (ctx->princ != NULL)
++if (ctx->princ != NULL) {
+ krb5_free_principal(ctx->context, ctx->princ);
++ctx->princ = NULL;
++}
+ retval = krb5_cc_get_principal(ctx->context, ctx->cache, &ctx->princ);
+ if (retval != 0) {
+ putil_err_krb5(args, retval, "cannot get principal from cache");
diff -Nru libpam-krb5-4.9/debian/patches/series 
libpam-krb5-4.9/debian/patches/series
--- libpam-krb5-4.9/debian/patches/series   1969-12-31 16:00:00.0 
-0800
+++ libpam-krb5-4.9/debian/patches/series   2021-03-14 12:31:39.0 
-0700
@@ -0,0 +1 @@
+0001-Avoid-double-free-of-ctx-princ-in-a-failure-case.patch

Bug#985234: unblock: rust-smallvec/1.4.2-2

[plugwash]

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

Please unblock package rust-smallvec

The insert_many function in rust-smallvec 1.6.0 and earlier suffers from a
buffer overflow if the number of items returned by the iterator is greater
than the size hint provided by the iterator. This was picked up by the rust
security team as CVE-2021-27378 and in turn by the Debian security team
who filed it with serious severity as Debian bug 985087

I did a fair bit of searching and was unable to find any code that actually
called the problem function, but nevertheless I think this is something
that should be fixed for bullseye. The new upstream version however contained
a number of feature changes that did not seem appropriate at this stage in the
release process.

Therefore I applied the upstream fix as a patch and uploaded to unstable.
The package built successfully on all release architectures and the
autopkgtests passed on all debci architectures.

unblock rust-smallvec/1.4.2-2
diff -Nru rust-smallvec-1.4.2/debian/cargo-checksum.json 
rust-smallvec-1.4.2/debian/cargo-checksum.json
--- rust-smallvec-1.4.2/debian/cargo-checksum.json  2020-10-18 
00:11:43.0 +0100
+++ rust-smallvec-1.4.2/debian/cargo-checksum.json  2021-03-13 
16:28:35.0 +
@@ -1 +1 @@
-{"package":"fbee7696b84bbf3d89a1c2eccff0850e3047ed46bfcd2e92c29a2d074d57e252","files":{}}
+{"package":"Could not get crate checksum","files":{}}
diff -Nru rust-smallvec-1.4.2/debian/changelog 
rust-smallvec-1.4.2/debian/changelog
--- rust-smallvec-1.4.2/debian/changelog2020-10-18 00:11:43.0 
+0100
+++ rust-smallvec-1.4.2/debian/changelog2021-03-13 16:28:35.0 
+
@@ -1,3 +1,12 @@
+rust-smallvec (1.4.2-2) unstable; urgency=medium
+
+  * Team upload.
+  * Package smallvec 1.4.2 from crates.io using debcargo 2.4.3
+  * Apply upstream patch to fix overflow in insert_many
+( Closes: 984665 )
+
+ -- Peter Michael Green   Sat, 13 Mar 2021 16:28:35 +
+
 rust-smallvec (1.4.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-smallvec-1.4.2/debian/copyright 
rust-smallvec-1.4.2/debian/copyright
--- rust-smallvec-1.4.2/debian/copyright2020-10-18 00:11:43.0 
+0100
+++ rust-smallvec-1.4.2/debian/copyright2021-03-13 16:28:35.0 
+
@@ -11,7 +11,7 @@
 
 Files: debian/*
 Copyright:
- 2018-2019 Debian Rust Maintainers 

+ 2018-2021 Debian Rust Maintainers 

  2018 kpcyrd 
  2018-2019 Wolfgang Silbermayr 
 License: MIT or Apache-2.0
diff -Nru rust-smallvec-1.4.2/debian/copyright.debcargo.hint 
rust-smallvec-1.4.2/debian/copyright.debcargo.hint
--- rust-smallvec-1.4.2/debian/copyright.debcargo.hint  2020-10-18 
00:11:43.0 +0100
+++ rust-smallvec-1.4.2/debian/copyright.debcargo.hint  2021-03-13 
16:28:35.0 +
@@ -21,9 +21,9 @@
 
 Files: debian/*
 Copyright:
- 2018-2020 Debian Rust Maintainers 

- 2018-2020 kpcyrd 
- 2018-2020 Wolfgang Silbermayr 
+ 2018-2021 Debian Rust Maintainers 

+ 2018-2021 kpcyrd 
+ 2018-2021 Wolfgang Silbermayr 
 License: MIT or Apache-2.0
 
 License: Apache-2.0
diff -Nru 
rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch 
rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
--- rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
1970-01-01 01:00:00.0 +0100
+++ rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
2021-03-13 16:28:35.0 +
@@ -0,0 +1,128 @@
+Debian patch for bug 984665
+
+The patches to lib.rs and tests.rs are identical to the upstream
+commit described below. The changes to Cargo.toml (which were
+just a change of the package version number) have been excluded.
+
+commit 9998ba0694a6b51aa6604748b00b6a98f0a0039e
+Author: Matt Brubeck 
+Date:   Thu Jan 7 21:28:46 2021 -0800
+
+Fix potential buffer overflow in `insert_many`
+
+Fixes #252.
+
+diff --git a/src/lib.rs b/src/lib.rs
+index 0241aefa..5e9de828 100644
+--- a/src/lib.rs
 b/src/lib.rs
+@@ -1009,7 +1009,7 @@ impl SmallVec {
+ /// Insert multiple elements at position `index`, shifting all following 
elements toward the
+ /// back.
+ pub fn insert_many>(&mut self, index: 
usize, iterable: I) {
+-let iter = iterable.into_iter();
++let mut iter = iterable.into_iter();
+ if index == self.len() {
+ return self.extend(iter);
+ }
+@@ -1017,13 +1017,16 @@ impl SmallVec {
+ let (lower_size_bound, _) = iter.size_hint();
+ assert!(lower_size_bound <= core::isize::MAX as usize); // Ensure 
offset is indexable
+ assert!(index + lower_size_bound >= index); // Protect against 
overflow
+-self.reserve(lower_size_bound);
++
++let mut num_added = 0;
++let old_len = self.len();
++assert!(index <= old_len);
+ 
+ unsafe {
+-let old_len = self.len();
+-assert!(i

Bug#985139: unblock: manpages-l10n/4.9.3-1

[Helge Kreutzmann]

retitle 985139 unblock: manpages-l10n/4.9.3-3
tags 985139 - moreinfo
thanks

Hello Ivo,
On Sun, Mar 14, 2021 at 03:53:01PM +0100, Ivo De Decker wrote:
> Control: tags -1 confirmed moreinfo
> 
> On Sat, Mar 13, 2021 at 04:02:43PM +0100, Helge Kreutzmann wrote:
> > Please unblock package manpages-l10n
> 
> In General, I think this is ok, if the issues below can be fixed fairly soon.
> 
> [...]
> 
> > Furthermore, I finally managed to contact Javier Fernández-Sanguino
> > Peña, and we agreed that the very outdated spanish man page
> > translations are taken over by manpages-l10n, manpages-es-extra is
> > asked for removal.
> 
> The current version has this in debian/control:
> 
> Replaces: manpages-es (<= 1.55-10), manpages-es-extraA
> 
> That's clearly a typo. Please fix this first. When that fix is in unstable,
> please remove the moreinfo tag from this bug and retitle it as needed.
> 
> I assume you tested the upgrade scenario from manpages-es-extra to the
> packages that currently contain the manpages?

I now tested the scenario, sorry for not doing this in the last
upload. Thanks for spotting.

> > I can prepare the debdiff, but it will contain lots of changes, since
> > many man pages had updated (even if only due to po4a reformatting
> > them).
> 
> Could you prepare a filtered debdiff between the version currently in testing
> and the new upload to unstable, that doesn't contain the translation changes.
> Also, please mention the command you used to do the filtering.

I used:
debdiff --exclude "upstreambug" --exclude "upstream" --exclude "templates" 
--exclude "po" --exclude copyright --exclude create-authors-file.sh --exclude 
README.md ./4.9.1-7/manpages-l10n_4.9.1-7.dsc 
./4.9.3-3/manpages-l10n_4.9.3-3.dsc

The filtered debdiff is attached.

> > [ Other info ]
> > If there is any open question regarding this unblock, I'm most happy
> > to provide it.
> > 
> > In the changelog unfortunately there is a typo, the new upstream
> > versio is indeed 4.9.3, *not* 4.9.1.
> 
> As a new upload is needed anyway, you can fix this too.

This is fixed as well (was already fixed in git).

unblock manpages-l10n/4.9.3-3

> Thanks,

Me as well: thanks

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n-4.9.1/aclocal.m4 manpages-l10n-4.9.3/aclocal.m4
--- manpages-l10n-4.9.1/aclocal.m4  2021-02-06 21:39:51.0 +0100
+++ manpages-l10n-4.9.3/aclocal.m4  2021-03-09 20:24:24.0 +0100
@@ -1,4 +1,4 @@
-# generated automatically by aclocal 1.16.2 -*- Autoconf -*-
+# generated automatically by aclocal 1.16.3 -*- Autoconf -*-
 
 # Copyright (C) 1996-2020 Free Software Foundation, Inc.
 
@@ -14,8 +14,8 @@
 m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS], 
[])m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])])
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
-m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.70],,
-[m4_warning([this file was generated for autoconf 2.70.
+m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.71],,
+[m4_warning([this file was generated for autoconf 2.71.
 You have another version of autoconf.  It may work, but is not guaranteed to.
 If you have problems, you may need to regenerate the build system entirely.
 To do so, use the procedure documented by the package, typically 
'autoreconf'.])])
@@ -35,7 +35,7 @@
 [am__api_version='1.16'
 dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
 dnl require some minimum version.  Point them to the right macro.
-m4_if([$1], [1.16.2], [],
+m4_if([$1], [1.16.3], [],
   [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
 ])
 
@@ -51,7 +51,7 @@
 # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
 # This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-[AM_AUTOMAKE_VERSION([1.16.2])dnl
+[AM_AUTOMAKE_VERSION([1.16.3])dnl
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
 _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
@@ -370,12 +370,7 @@
 [AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([missing])dnl
 if test x"${MISSING+set}" != xset; then
-  case $am_aux_dir in
-  *\ * | *\*)
-MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
-  *)
-MISSING="\${SHELL} $am_aux_dir/missing" ;;
-  esac
+  MISSING="\${SHELL} '$am_aux_dir/missing'"
 fi
 # Use eval to expand $SHELL
 if eval "$MISSING --is-lightweight"; then
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exc

Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems

[Al Stone]

Package: wnpp
Severity: normal
X-Debbugs-Cc: da...@debian.org
Control: affects -1 src:lmbench

I intend to orphan the lmbench package.  I no longer use it,
and have not for quite some time, and no longer have the time
to maintain it properly.

Upstream seems to be static (perhaps reasonably so for a benchmark)
but we have cleaned up things a bit over the years.  Cleaned up most
of the lintian issues on the last update, too, but there are still
a couple of minor bugs left.

The package description is:
 Lmbench is a set of utilities to test the performance
 of a unix system producing detailed results as well
 as providing tools to process them. It includes a series of
 micro benchmarks that measure some basic operating
 system and hardware metrics:
 .
  * file reading and summing
  * memory bandwidth while reading, writing and copying
  * copying data through pipes
  * copying data through Unix sockets
  * reading data through TCP/IP sockets

Bug#985232: ITP: deviceinfo -- Library for Lomiri to detect and configure devices

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: deviceinfo
  Version : 0.1.0
  Upstream Author : Marius Gripsgard 
* URL : https://gitlab.com/ubports/core/deviceinfo
* License : GPL-3
  Programming Lang: C++
  Description : Library for Lomiri to detect and configure devices

 Lomiri Operating Environment is a convergent work shell designed
 for use cases on phone, tablet or desktop devices.
 .
 This package provides a library to detect and configure devices.
 .
 This package will be maintained under the umbrella of the UBports packaging
 team.

Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko

[Lucas Nussbaum]

Hi,

On 13/03/21 at 11:31 +0900, Ryutaroh Matsumoto wrote:
> Package: src:linux
> Version: 5.10.19-1
> Severity: normal
> Tags: upstream sid bullseye
> X-Debbugs-Cc: debian-...@lists.debian.org
> Control: forwarded -1 
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008049.html
> 
> Dear Maintainer,
> 
> kmscube   0.0.0~git20210103-1 fails to start with the error message
> on Raspberry Pi 4B:
> 
> failed to set mode: Invalid argument
> 
> kmscube works fine on linux-image-amd64 and Raspberry Pi OS kernel
> with vc4.ko and v3d.ko loaded.
> Debian kernel without vc4.ko does not have KMS support on RPi4B.
> 
> If this is an issue in kmscube, please feel free to reassign.
> This has been reported to the upstream maintainer.

According to strace, it fails because /dev/dri does not exist.

My understanding is that 5.10 does not have DRI support for the RPI4.
There's still some work to do in the V3D driver for that (see the
discussion at the end of
https://github.com/lategoodbye/rpi-zero/issues/46 )

Lucas

Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV

[Thorsten Glaser]

Hi Fabian,

>Am Sonntag, dem 14.03.2021 um 20:05 + schrieb Thorsten Glaser:
>> @Fabian since you were the driving force behind SF3 integration
>> into FluidSynth itself, you might wish to have a look at the
>> patch as well.
>
>forwarded to Fluidsynth upstream, thanks!

OK, thanks!

> (I am not active in this project anymore).

Oh, sad. Thanks for still responding.

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Bug#984985: wordpress: WordPress 5.7 available

[Craig Small]

On Fri, 12 Mar 2021 at 02:09, Christer Mjellem Strand 
wrote:

> WordPress 5.7 has been released. Appreciate if you're able to update the
> package at your earliest convenience.
>
Hi Christer,
  Thanks for the email, I'm packaging it today and if it doesn't give any
problems should be uploaded today too.

 - Craig

Bug#985230: ITP: mypy-protobuf -- Generate mypy stub files from protobuf specs

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org

* Package name: mypy-protobuf
  Version : 2.4
  Upstream Author : Nipunn Koorapati 
* URL : https://github.com/dropbox/mypy-protobuf
* License : Apache 2.0
  Programming Lang: Python
  Description : Generate mypy stub files from protobuf specs

This package is introduced as a dependency for the "ortools" source
package (ITP created). I intent to maintain this package under the
umbrella of the Debian Python team.

Bug#247134: debconf: affects backups

[Colin Watson]

On Sun, Mar 14, 2021 at 12:55:09PM +0100, Marco d'Itri wrote:
> On Jun 15, gambarimasu+report...@gmail.com wrote:
> > just wanted to say that many users will exclude /var/cache from
> > backups.
> Yes, this is the main issue: it is a best practice to exclude files in
> /var/cache/ from backups, but this way a restore will lose the whole 
> debconf database.
> 
> Can we get some feedback about this from the debconf maintainers?

Moving the database to /var/lib/debconf/ (in line with cdebconf) seems
fairly clearly the right thing to do; I'm sorry for having put this off
for so long.  I'll see if we can get that done for bookworm.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#985080: Akonadi server crashes because of Apparmor rules

[bs.net]

Hi hefee,

thank you very much for the quick feedback.

I do not use anything unusual. Primarily POP3 accounts (external providers)
and a local mailbox. I also use an embedded MariaDB as backend and X11
(without Wayland). The file system is Btrfs and the user directory is
encrypted.

The setup exists since 2003 and has survived all upgrades.

I hope that a permanent solution can be found.

Thank you very much and best regards
Sascha

Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV

[Fabian Greffrath]

Hi Thorsten,

Am Sonntag, dem 14.03.2021 um 20:05 + schrieb Thorsten Glaser:
> @Fabian since you were the driving force behind SF3 integration
> into FluidSynth itself, you might wish to have a look at the
> patch as well.

forwarded to Fluidsynth upstream, thanks! (I am not active in this
project anymore).

 - Fabian



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

Bug#985229: unblock: musescore2/2.3.2+dfsg4-14, musescore3/3.2.3+dfsg2-10, musescore-general-soundfont/0.2-3, timgm6mb-soundfont/1.3-5

[Thorsten Glaser]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de

Please unblock package musescore2, musescore3,
 musescore-general-soundfont and timgm6mb-soundfont
(all packages related to #984592)

[ Reason ]
In rare conditions, “rmdir --ignore-fail-on-non-empty” as used in
the prerm of some packages can fail because dpkg already removed
one of the directories in question; this was found as #984592 by
piuparts. To ensure uninstalling without errors, we mkdir -p the
directories first (other errors will still cause aborting).

[ Impact ]
#984592 is considered an RC bug, so it would lead to removing a
package from the release, which is very suboptimal. In very rare
cases, not fixing this may cause package uninstallation to fail.

[ Tests ]
None; the code is trivial.

[ Risks ]
No risk, this is trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I have another set of uploads for musescore2 and musescore3 fixing
crash bugs coming up (not uploading them today, I want upstream to
have a go at reviewing the change first). How should this be handled?
Should I first wait until the current set of packages is unblocked
and has migrated to testing? Otherwise, if I upload now musescore2
would get AUTORM’d which is suboptimal. Waiting so long will however
delay availability of the fix even to sid users.

unblock musescore2/2.3.2+dfsg4-14
unblock musescore3/3.2.3+dfsg2-10
unblock musescore-general-soundfont/0.2-3
unblock timgm6mb-soundfont/1.3-5
diff -Nru musescore-general-soundfont-0.2/debian/changelog 
musescore-general-soundfont-0.2/debian/changelog
--- musescore-general-soundfont-0.2/debian/changelog2020-07-12 
17:02:25.0 +0200
+++ musescore-general-soundfont-0.2/debian/changelog2021-03-12 
20:58:58.0 +0100
@@ -1,3 +1,12 @@
+musescore-general-soundfont (0.2-3) unstable; urgency=medium
+
+  * Bump Policy (no relevant changes)
+  * Avoid rare error in prerm (Closes: #984592)
+  * Update from maintainer script template
+  * Do latest lintian tag rename churn
+
+ -- Thorsten Glaser   Fri, 12 Mar 2021 20:58:58 +0100
+
 musescore-general-soundfont (0.2-2) unstable; urgency=high
 
   * Merge musescore-general-soundfont-small (0.2-2) changes
diff -Nru musescore-general-soundfont-0.2/debian/control 
musescore-general-soundfont-0.2/debian/control
--- musescore-general-soundfont-0.2/debian/control  2020-05-28 
23:19:04.0 +0200
+++ musescore-general-soundfont-0.2/debian/control  2021-03-12 
20:34:13.0 +0100
@@ -5,7 +5,7 @@
 Homepage: https://musescore.org/en/node/269869
 Build-Depends: debhelper-compat (= 13),
  python3-minimal, sf3convert
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 VCS-git: https://evolvis.org/anonscm/git/alioth/soundfonts.git -b 
musescore-general-soundfont
 VCS-Browser: 
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/soundfonts.git;a=shortlog;h=refs/heads/musescore-general-soundfont
diff -Nru 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
--- 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2020-05-28 23:00:17.0 +0200
+++ 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2021-03-12 20:45:47.0 +0100
@@ -21,9 +21,12 @@
 #
 # * postinst "triggered" "${triggers[*]}"
 # For trigger-only calls, i.e. if "configure" is not called.
+#
+# * new-postinst "reconfigure" [$most_recently_configured_version](?)
+# Treat this as just like "configure" for a future extension by debconf.
 
 case $1 in
-configure)
+(configure|reconfigure)
# need the directories existing before update-alternatives
mkdir -p /usr/share/sounds/sf2 /usr/share/sounds/sf3
# see #929185 for the history behind this
@@ -39,13 +42,13 @@
/usr/share/sounds/sf2/MuseScore_General_Full.sf2 55
;;
 
-abort-upgrade|abort-remove|abort-deconfigure)
+(abort-upgrade|abort-remove|abort-deconfigure)
;;
 
-triggered)
+(triggered)
;;
 
-*)
+(*)
echo >&2 "E: postinst called with unknown subcommand '$1'"
exit 1
;;
diff -Nru 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
--- 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
   2020-05-28 23:00:17.0 +0200
+++ 
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
   2021-03-12 20:46:28.0 +0100
@@ -19,7 +19,7 @@
 # other constraints the same as above.
 
 case $1 in
-remove|deconfigure)
+(remove|deconfigure)
# Mus

Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV

[Thorsten Glaser]

forwarded 985129 https://github.com/musescore/MuseScore/pull/7728
tags 985129 - moreinfo
tags 985129 + confirmed upstream pending
affects 985129 musescore
outlook 985129 a patch has been found and musescore{2,3} will be uploaded soon
thanks

@Fabian since you were the driving force behind SF3 integration
into FluidSynth itself, you might wish to have a look at the
patch as well.

Paul Menzel dixit:

> (gdb) print *s
> $2 = {_valid = true, sf = 0x563075eb55a0, start = 0, end = 0,
>  loopstart = 29362, loopend = 38401, samplerate = 44100,
>  origpitch = 63, pitchadj = -8, sampletype = 17, data = 0x0,

Good news: With sf3convert, I was able to identify this sample:

  
25705425
25743841
29362
38401
44100
63
-8
1


(Ignore that sampletype is 1 here.)

Bad news: the sample and the soundfont is fine, so this probably
was a temporary hiccup, I/O or decompression-related… or maybe
even caused by threads interjecting… the last commit related to
mutex locking around soundfont loading is present, though… no idea.

More good news: I have a patch, also forwarded upstream, which I
believe fixes this bug, but also others. I’m not uploading this any
more tonight but later but if you want to test it already I provide
it at: https://people.debian.org/~tg/musescore3_3.2.3+dfsg2-11_amd64.deb

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#985228: unblock: petsc/3.14.5+dfsg1-2

[Drew Parsons]

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

Please unblock package petsc

[ Reason ]

upstream released petsc 3.14.5 with bug fixes only.
This will help improve the stability of the package over the lifetime
of the bullseye release.

This update also fixes Bug#983892, fixing orphaned alternatives after
removal of libpetsc64-complex3.14-dev,

[ Impact ]

If this release is not permitted into stable then some users may
encounter the issues addressed by the patch, especially when running
under MPI parallelization.  A range of bugs have been addressed:
- MatBAIJ: Fix specialization for size 9
- Do not use MPI_Bcast() on a single rank.
- PCHPDDM: fix for KSPLSQR
- DMPlexVTKWriteAll_VTU: a couple of bugfixes
- handling error conditions in PetscOptions
- handling NULL objects in Fortran interface
- bugfix for MatMatMultSymbolic_MPIAIJ_MPIDense() 
- CPARDISO: stick to OpenMPI BLACS when needed
- minor Documentation fixes

If the release is not allowed into stable then
libpetsc64-complex3.14-dev will leave dangling alternatives links when
removed.


[ Tests ]

debian/tests autopkgtest is enabled.
petsc debci tests have passed in unstable.

debci tests in client packages are also passing successfully in unstable
(petsc4py, slepc, slep4py, deal.ii, dolfin, mshr, dolfinx)

sundials continues to build successfully.

[ Risks ]

The patch fixes a range of bugs, it is not a simple one-line patch.

[ Checklist ]
  [-] all changes are documented in the d/changelog
  - documented as "New upstream release (bugfixes)"
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing


unblock petsc/3.14.5+dfsg1-2

Bug#985225: put-dns: [INTL:fr] French templates translation

[John Lines]

Thank you, it will be in the next release

John


On Sun, 2021-03-14 at 18:12 +0100, Jean-Pierre Giraud wrote:
> Package: put-dns 0.0.2-3
> Severity: wishlist
> Tags: patch l10n
> 
> Hi!
> 
> Please find attached the french templates translation, proofread
> by the debian-l10n-french mailing list contributors.
> 
> This file should be put as debian/po/fr.po in your package build
> tree.
> 
> I do apologize for missing the deadline. The file will be ready for
> the
> next release of the package...
> 
> Kind Regards
> 
> Jean-Pierre Giraud

Bug#985218: package-supports-alternative-init-but-no-init.d-script is outdated

[Faidon Liambotis]

Hi Felix,

On Sun, Mar 14, 2021 at 09:18:25AM -0700, Felix Lechner wrote:
> On Sun, Mar 14, 2021 at 8:42 AM Faidon Liambotis  wrote:
> >
> > I maintain a package
> 
> Thank you for bringing this to our attention. I would like to test the
> proposed changes with your package. What is the name, please? Thanks!

Thanks for the quick response! gdnsd is the package in question; 3.5.2-1
would be a good version to test this against.

Best,
Faidon

Bug#979765: Kernel panic of linux 5.10.19-1 with VIA Nano L2200 on VX800

[8vvbbqzo567a]

I re-tested with the latest bullseye 5.10.19-1 kernel and the problem remains. 
Any advice how to debug this?

Panic message (full boot messages attached):
[   12.884349] general protection fault:  [#1] SMP PTI
[   12.884352] CPU: 0 PID: 1 Comm: systemd Not tainted 5.10.0-4-amd64 #1 Debian 
5.10.19-1
[   12.884354] Hardware name: VIA Technologies Ltd. VX800 /VX800 , BIOS 6.00 PG 
02/26/2009
[   12.884355] RIP: 0010:native_read_pmc+0x4/0x40
[   12.884358] Code: 00 00 00 0f 1f 00 53 48 89 fb 66 66 90 66 90 48 89 df e8 
6f 11 01 00 48 89 c6 48 89 33 5b c3 0f 1f 80 00 00 00 00 41 54 89 f9 <0f> 33 66 
66 66 66 90 48 c1 e2 20 49 89 d4 49 09 c4 4c 89 e0 41 5c
[   12.884360] RSP: 0018:fe00bc88 EFLAGS: 00010046
[   12.884364] RAX: 0021 RBX: fffc4677b0e0 RCX: 4001
[   12.884365] RDX: 0021 RSI: 0040 RDI: 4001
[   12.884367] RBP: 9dba811c9000 R08: 030a R09: 
[   12.884369] R10:  R11:  R12: 9dba811c91e0
[   12.884371] R13: 0018 R14: 0021 R15: 9dbaf5c119a0
[   12.884372] FS:  7f5fd7b3f900() GS:9dbaf5c0() 
knlGS:
[   12.884374] CS:  0010 DS:  ES:  CR0: 80050033
[   12.884376] CR2: 55ba2e4b1238 CR3: 01f3e000 CR4: 06f0
[   12.884377] Call Trace:
[   12.884378]  
[   12.884379]  x86_perf_event_update+0x4a/0xa0
[   12.884381]  zhaoxin_pmu_handle_irq+0x13a/0x250
[   12.884382]  perf_event_nmi_handler+0x28/0x50
[   12.884383]  nmi_handle+0x58/0x100
[   12.884385]  default_do_nmi+0x42/0x130
[   12.884386]  exc_nmi+0x131/0x150
[   12.884387]  end_repeat_nmi+0x16/0x55
[   12.884389] RIP: 0010:step_into+0xb/0x700
[   12.884392] Code: e9 27 fd ff ff 45 85 ff 74 08 4c 89 c7 e8 5d 48 ff ff 49 
c7 c5 ec ff ff ff e9 0e fd ff ff 90 66 66 66 66 90 55 48 89 e5 41 57 <41> 89 f7 
41 56 45 89 c6 41 55 49 89 cd 41 54 49 89 d4 53 48 89 fb
[   12.884393] RSP: 0018:c11c4001bc88 EFLAGS: 0246
[   12.884396] RAX: 9dba877cf900 RBX: c11c4001be50 RCX: b68ca162
[   12.884398] RDX: 9dba877cf900 RSI: 0001 RDI: c11c4001bd28
[   12.884399] RBP: c11c4001bc90 R08:  R09: 7861
[   12.884401] R10: 0002 R11: 879e R12: 0001
[   12.884403] R13: 9dba84211020 R14:  R15: 
[   12.884404]  ? path_init+0x1e2/0x3e0
[   12.884405]  ? step_into+0xb/0x700
[   12.884406]  ? step_into+0xb/0x700
[   12.884408]  
[   12.884409]  walk_component+0x70/0x1d0
[   12.884410]  ? tomoyo_init_request_info+0x8f/0xb0
[   12.884412]  ? path_init+0x1e2/0x3e0
[   12.884413]  path_lookupat+0x72/0x1c0
[   12.884414]  filename_lookup+0xaa/0x1b0
[   12.884416]  ? strncpy_from_user+0x4e/0x140
[   12.884417]  ? getname_flags.part.0+0x45/0x1a0
[   12.884418]  vfs_statx+0x74/0x130
[   12.884420]  __do_sys_newfstatat+0x31/0x70
[   12.884421]  ? exit_to_user_mode_prepare+0x32/0x120
[   12.884422]  do_syscall_64+0x33/0x80
[   12.884424]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   12.884425] RIP: 0033:0x7f5fd830c87b
[   12.884428] Code: 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 41 89 f9 45 
89 c2 89 f7 48 89 d6 48 89 ca 41 83 f9 01 77 2c b8 06 01 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 e1 f5 0c 00 f7 d8
[   12.884430] RSP: 002b:7ffda4214bc8 EFLAGS: 0246 ORIG_RAX: 
0106
[   12.884433] RAX: ffda RBX: 7ffda4214f60 RCX: 7f5fd830c87b
[   12.884435] RDX: 7ffda4214be0 RSI: 55fcce693373 RDI: 0029
[   12.884436] RBP: 7ffda4214f60 R08: 0100 R09: 0001
[   12.884438] R10: 0100 R11: 0246 R12: 55fcce693373
[   12.884440] R13: 7ffda4214ce0 R14: 7ffda4214be0 R15: 55fcce5e9bb0
[   12.884441] Modules linked in: fuse configfs ip_tables x_tables autofs4 ext4 
crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath 
linear md_mod hid_generic usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic 
crct10dif_common ata_generic uas usb_storage uhci_
[   13.257443] ---[ end trace e665e0cbc79538c9 ]---
[   13.257444] RIP: 0010:native_read_pmc+0x4/0x40
[   13.257448] Code: 00 00 00 0f 1f 00 53 48 89 fb 66 66 90 66 90 48 89 df e8 
6f 11 01 00 48 89 c6 48 89 33 5b c3 0f 1f 80 00 00 00 00 41 54 89 f9 <0f> 33 66 
66 66 66 90 48 c1 e2 20 49 89 d4 49 09 c4 4c 89 e0 41 5c
[   13.257449] RSP: 0018:fe00bc88 EFLAGS: 00010046
[   13.257452] RAX: 0021 RBX: fffc4677b0e0 RCX: 4001
[   13.257453] RDX: 0021 RSI: 0040 RDI: 4001
[   13.257455] RBP: 9dba811c9000 R08: 030a R09: 
[   13.257457] R10:  R11:  R12: 9dba811c91e0
[   13.257458] R13: 0018 R14: 000

Bug#985080: Akonadi server crashes because of Apparmor rules

[Sandro Knauß]

Hi,

> the Akonadi server permanently crashes on login after upgrading to Bullseye.

I cannot reproduce this on my setup an using Akonadi server the whole time. So 
I'm interested, why this happens for you and not for me.

What resources are you using? I use only a private IMAP server with MariaDB as 
Akonadi backend and using X11 (not Wayland).

> It would be good if the Apparmor rules of the Akonadi server were
> functional. In the current state, the Akonadi server is unfortunately not
> usable without user adjustments.

This is not true for me and also other distros use these Apparmor rules and 
are happy ( at least I did not got any negative feedback/patches for around 6 
months). So it seems like you triggered a test case other did not catch, so it 
would be helpful if you describe your setup, to get this patch upstream.

regards,

hefee

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

Bug#971956: release-notes: SANE and driverless scanning

[Brian Potkin]

On Sun 14 Mar 2021 at 18:10:48 +, Justin B Rye wrote:

> Brian Potkin wrote:
> > On Sun 14 Mar 2021 at 17:01:14 +, Justin B Rye wrote:
>  Driverless scanning is the ability to scan without using a vendor
>  backend driver, free or non-free. [...]
> >>
> >> It all looks okay.  "Vendor backend driver" is a strange expression,
> >> but it seems to be what people are used to!
> > 
> > Does this work better?
> > 
> >   Driverless scanning is the ability to scan without requiring a
> >   free or non-free backend driver that depends on the particular
> >   scanner model.
> 
> People might stumble on the "that depends" part... could we say:
> 
> Driverless scanning is the ability to scan without requiring a
> free or non-free backend driver specific to that scanner model.

Indeed we can say that. Thanks.

-- 
Brian.

Bug#985212: dh_installdeb: Check for dpkg-maintscript-helper args misparses shell code, cannot handle filenames with spaces

[Niels Thykier]

Control: tags -1 moreinfo

Andreas Metzler:
> Package: debhelper
> Version: 13.3.4
> Severity: normal
> 
> Hello,
> 
> in #929165 Hideki wanted to use rm_conffile to remove junk from earlier
> versions, notably files containing spaces and wildcards in their name:
>  ./etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive, 
> ubuntu-cloud-removed-keys.gpg
>  ./etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg, *
> 
> Which would be straightforward enough, adding debian/maintscript with
> these contents (using "hello" as package name for demonstration
> purposes):
> rm_conffile '/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive, 
> ubuntu-cloud-removed-keys.gpg' '2.10-2.2~' 'hello'
> rm_conffile '/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg, *' 
> '2.10-2.2~' 'hello'
> 
> Which works perfectly well with ancient (DH 9 compat level) but throws
> an error with compat level 13:
> ---
> (sid)ametzler@argenau:/tmp/HELLODH13/hello-2.10$ dh_installdeb --no-act 
> --verbose
> dh_installdeb: error: The current conffile path for rm_conffile must be 
> present and absolute, got 
> '/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive,
> ---
> 
> Looking at /usr/bin/dh_installdeb one finds a check for a literal "/" as
> leading character of the first argument of rm_conffile. Just for the fun
> of it, I have try escaping instead of quoting, but the check splits on
> space.
> 
> (sid)ametzler@argenau:/tmp/HELLODH13/hello-2.10$ cat debian/hello.maintscript
> rm_conffile /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive,\ 
> ubuntu-cloud-removed-keys.gpg '2.10-2.2~' 'hello'
> rm_conffile /etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg,\ \* 
> '2.10-2.2~' 'hello'
> (sid)ametzler@argenau:/tmp/HELLODH13/hello-2.10$ dh_installdeb --no-act 
> --verbose
> dh_installdeb: error: The version for rm_conffile 
> /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive,\ is not valid, got 
> ubuntu-cloud-removed-keys.gpg
> 
> 
> cu Andreas
> 

Hi Andreas,

Does it work correctly when you use the substitution feature in
debhelper 13 to insert the space?

It should be something like:

/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive,${SPACE}ubuntu-cloud-removed-keys.gpg

~Niels

Bug#985226: Outdated information in Debian's copyright file for the strace package

[Eugene Syromiatnikov]

Package: strace
Version: 4.26-0.2
Severity: normal

Debian's copyright file for the strace package is significantly outdated:
 * The upstream sources are no longer available at [1], but rather
   at [2] or [3], as pointed from the project page [4] and in the README
   files[5][6].  See also [7][8].
 * The copyrightship (as outlined in COPYING[9]) after the year 2001
   has been replaced with a wildcard "Copyright (c) 2001-20xx The strace
   developers." line, with the list of developers provided in the distributed
   CREDITS[10] file and the last copyright year corresponding to the year
   of the packaged strace release.
 * The license has been changed from BSD to LGPL-2.1-or-later for the main code
   and GPL-2.0-or-later for the test suite [11].

These issues are not present in the upstream debian/copyright[12].

The aforementioned also holds for the latest strace package version, 5.10-1.

[1] http://sourceforge.net/projects/strace/
[2] https://gitlab.com/strace/strace
[3] https://github.com/strace/strace
[4] https://strace.io/
[5] https://gitlab.com/strace/strace/-/blob/master/README.md
[6] https://fossies.org/linux/strace/README
[7] https://gitlab.com/strace/strace/-/commit/51d40516df
[8] https://gitlab.com/strace/strace/-/commit/003c02745f
[9] https://gitlab.com/strace/strace/-/blob/master/COPYING
[10] https://fossies.org/linux/strace/CREDITS
[11] https://gitlab.com/strace/strace/-/commit/b93d52fe3d
[12] https://gitlab.com/strace/strace/-/blob/master/debian/copyright

Bug#971956: release-notes: SANE and driverless scanning

[Justin B Rye]

Brian Potkin wrote:
> On Sun 14 Mar 2021 at 17:01:14 +, Justin B Rye wrote:
 Driverless scanning is the ability to scan without using a vendor
 backend driver, free or non-free. [...]
>>
>> It all looks okay.  "Vendor backend driver" is a strange expression,
>> but it seems to be what people are used to!
> 
> Does this work better?
> 
>   Driverless scanning is the ability to scan without requiring a
>   free or non-free backend driver that depends on the particular
>   scanner model.

People might stumble on the "that depends" part... could we say:

Driverless scanning is the ability to scan without requiring a
free or non-free backend driver specific to that scanner model.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#985216: RFS: sabnzbdplus/2.3.6+dfsg-1+deb10u1 -- web-based binary newsreader with nzb support

[Jeroen Ploemen]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

Note that this update has been approved by the stable release managers,
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984604

I am looking for a sponsor for my package "sabnzbdplus":
 * Package name: sabnzbdplus
   Version : 2.3.6+dfsg-1+deb10u1
   Upstream Author : SABnzbd Team
 * URL : https://sabnzbd.org
 * License : GPL-2+ and others
 * Vcs : 
https://salsa.debian.org/python-team/applications/sabnzbdplus
   Section : contrib/net

It builds those binary packages:

  sabnzbdplus - web-based binary newsreader with nzb support

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/s/sabnzbdplus/sabnzbdplus_2.3.6+dfsg-1+deb10u1.dsc

Changes since the last upload:

 sabnzbdplus (2.3.6+dfsg-1+deb10u1) buster; urgency=medium
 .
   * Backport upstream security fixes to prevent code execution from
 the program's web interface through crafted settings.
 (CVE-2020-13124)

Regards,
-- 
  jcfp


pgpISsGqFbsxQ.pgp
Description: OpenPGP digital signature

Bug#588260: Fixed in official 0.4.0 upstream release

[Martin Nordholts]

This has been fixed in the official 0.4.0 upstream release found here:
https://github.com/Enselic/recordmydesktop/releases/tag/v0.4.0

In fact, this release fixes the following Debian bugs:

#588260 recordmydesktop: There is no --y=N option

#706574 recordmydesktop: truncates recordings

#649824 recordmydesktop: Specifying --use-jack makes recordmydesktop
exit with a bad screen geometry

#859686 recordmydesktop: man page is really ugly

#584269 recordmydesktop: Typo with recordmydesktop

Let me know if I can help in any way to get this Debian package updated.

Bug#985215: RFS: awstats/7.6+dfsg-2+deb10u1 [QA] -- powerful and featureful web server log analyzer

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: awstats
   Version : 7.6+dfsg-2+deb10u1
   Upstream Author : Laurent Destailleur 
 * URL : http://awstats.sourceforge.net/
 * License : Apache-2.0, GPL-3+, CC-BY-3.0, GPL-1+
 * Vcs :
http://anonscm.debian.org/gitweb/?p=collab-maint/awstats.git;a=summary
   Section : web

It builds those binary packages:

  awstats - powerful and featureful web server log analyzer

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/a/awstats/awstats_7.6+dfsg-2+deb10u1.dsc

Changes since the last upload:

 awstats (7.6+dfsg-2+deb10u1) buster; urgency=medium
 .
   * QA upload.
   * CVE-2020-29600: cgi-bin/awstats.pl?config= accepts an absolute
 pathname, even though it was intended to only read a file in the
 /etc/awstats/awstats.conf format. NOTE: this issue exists because of
 an incomplete fix for CVE-2017-1000501. Closes: #891469
   * CVE-2020-35176: in AWStats through 7.8, cgi-bin/awstats.pl?config=
 accepts a partial absolute pathname (omitting the initial /etc), even
 though it was intended to only read a file in the
 /etc/awstats/awstats.conf format. NOTE: this issue exists because of
 an incomplete fix for CVE-2017-1000501 and CVE-2020-29600.
 Closes: #977190


This upload was approved with bug #982996. Afterwards I changed it from
a NMU to QA upload.

Regards,
Håvard

Bug#985194: konsole: blue bar on the left side when text is scrolling

[Sandro Tosi]

> Hello Sandro, hello Norbert,
> this sounds like the feature "Highlight lines coming into view" [1].
>
> There is an option that looks like it could be disabled in:
>  Profiles - Scrollbars - "Highlight the lines coming into view"
>
> Kind regards,
> Bernhard
>
> https://invent.kde.org/utilities/konsole/-/commit/dabac1f47ead4626f0ff83affb851309f10a6e58

thanks guys for the quick answer! that is indeed what was causing that
blue bar: disabling  "Highlight the lines coming into view" fixed it
for me.

as for closing this bug or not, it feels this feature is very buggy:
if its purpose is to show the new line appearing on the terminal, it
does not work properly; it does not show all the new lines produced by
a program (see reportbug screenshot in the initial message), when
scrolling with the mouse wheel, the highlight is pretty erratic.

if you want to close this, i'm fine with it tho, but probably it'd be
better to retitle/repurpose it to make this feature useful?

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

Bug#971956: release-notes: SANE and driverless scanning

[Brian Potkin]

On Sun 14 Mar 2021 at 17:01:14 +, Justin B Rye wrote:

> Paul Gevers wrote:
> >> Driverless scanning is the ability to scan without using a vendor
> >> backend driver, free or non-free. [...]
> >
> > You didn't comment on this text, does it mean it passes your judgement?
>
> It all looks okay.  "Vendor backend driver" is a strange expression,
> but it seems to be what people are used to!

Does this work better?

  Driverless scanning is the ability to scan without requiring a
  free or non-free backend driver that depends on the particular
  scanner model.

--
Brian.

Bug#984684: z80dasm: add support z180

[Tomaž Šolc]

Dear Ben,

thanks for your patch! I've merged it upstream with some changes.

I've made the output of Z180 instructions optional (it's now hidden
behind a command-line flag). One of the features of z80dasm is that its
output can be directly fed into z80asm to produce the same binary again.
Your original patch unfortunately broke that, since a Z80 assembler
doesn't know about Z180 instructions.

See "z180" branch in git repo at

https://www.tablix.org/~avian/git/z80dasm.git

What Z180 assembler do you use? I want to test the output of the patched
z80dasm against it.

Best regards
Tomaž

Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV

[Thorsten Glaser]

@Igor, Jojo: this relates to commit 5aea0ab5b50b9037ba8ed9dd100dcf06396a4c9d
and the follow-up commit 48163e958f02b82e59d910176c5d806d0c9ef7b6 and to
https://musescore.org/en/node/89216 (see my comments there), I will of course
provide a PR if I manage to fix this correctly.

Dixi quod…

>> (gdb) print *s
>> $2 = {_valid = true, sf = 0x563075eb55a0, start = 0, end = 0,
>>  loopstart = 29362, loopend = 38401, samplerate = 44100,
>>  origpitch = 63, pitchadj = -8, sampletype = 17, data = 0x0,
>
>Hah! There we are, loopstart and loopend are larger than 0,
>start and end are 0 and data is even nil…

You don’t happe to have a copy of the terminal output (perhaps in
~/.xsession-errors or so) from the crashing run?

I’d expect there to be either “Sample::decompressOggVorbis: open failed”
or (more likely) “Sample read failed”.

>I shall be compiling a debug build now which will output information
>in the code area in question when the data is bad, like that, or not
>matching the SoundFont spec (if this works, I’ll even try to push it
>upstream), then we’ll see whether this is bad soundfont data.

This took MUCH longer than I thought, as the soundfont code is split
in SF3 and not-SF3 and that is not harmonic and apparently buggy:
https://musescore.org/en/node/89216

In addition, the changes…

>>> +  IF_ASSERT_FAILED(s->loopstart >= s->start) {
>>> +s->loopstart = s->start;
>>> +}
>>> +
>>> +  if (s->loopend > s->end) {
>>> +s->loopend = s->end;
>>> +}

… were intended to fix this but not enough and too late.

Right now I *think* I have a fix for all related issues including
audible artefacts with certain SF3 samples (clicking, or even other
notes sounding after one note finished playing).

>I’ll update this bug later, when knowing more.

Building is going to take a while… in the meantime, sf3convert(1)
from the sf3convert Debian package can convert a soundfont to XML
showing the data (such as {,loop}{start,end}) involved. I’ll try
having a look at that as well.

Again thank you for the bugreport, this (probably) proves to be useful!

I’ll also fix this in musescore2 of course.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#934921: openssl: Wrong regular expression in /usr/bin/c_rehash

[Marcus C. Gottwald]

Andreas Gryphius wrote (Fri 2019-Aug-16 18:22:00 +0200):

> the perl script /usr/bin/c_rehash contains a line (#123)
> 
> FILE: foreach $fname (grep {/\.(pem)|(crt)|(cer)|(crl)$/} @flist) {
> 
> where I think the regex grouping is wrong.
> Obviously it is intended to find only files with the listed suffixes.
> But it also finds files with "crt" or "cer" just anywhere within the
> filename. For example it would find the file "i_am_not_a_cert_file.pdf"

That behaviour caused a (small) security incident for me. I had
renamed files containing CA certificates which should no longer be
trusted, expecting c_rehash to delete and not re-create symlinks
to those files. However, c_rehash unexpectedly re-created the
symlinks, and the application verifying certificates unexpectedly
found and thus kept trusting those CA certificates.

If c_rehash's current behaviour is intended, at least the man page
should reflect that, I guess. The man page currently says:

   rehash scans directories and calculates a hash value of
   each ".pem", ".crt", ".cer", or ".crl" file

Thanks, Marcus

-- 
   Marcus C. Gottwald  ··  @mcg:cheers.de

Bug#985164: 403 Forbidden

[Scott C. MacCallum]

Hi Tomas,

My IP address has changed and I have no record of the previous one (VPN).

 Original Message 

On Mar 14, 2021, 8:02 AM, Tomas Pospisek < t...@sourcepole.ch> wrote:

Hi Scott,

On 13.03.21 22:28, Scott C. MacCallum wrote:

> Package: www.debian.org

> URL: https://wiki.debian.org/UnattendedUpgrades

>

> Forbidden

>

> You are not allowed to access this!

On the other hand I *am* allowed to access it. So there must be

something that's different between me and you. I guess it's the IP

address. What's yours? Could you please add your IP address to the bug

report?

*t

Bug#985225: put-dns: [INTL:fr] French templates translation

[Jean-Pierre Giraud]

Package: put-dns 0.0.2-3
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

I do apologize for missing the deadline. The file will be ready for the
next release of the package...

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Cyril Brulebois]

Cyril Brulebois  (2021-03-14):
> Please use systemctl status haveged -n 100 or something. The lines
> quoted above merely capture the fact that systemd gave up trying to
> start it.

FTR, submitter's mail system doesn't want to receive my mails:

   Client host […] blocked using urbl.hostedemail.com; Your IP has been
   manually blacklisted

Sigh.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#971956: release-notes: SANE and driverless scanning

[Justin B Rye]

Paul Gevers wrote:
>> Driverless scanning is the ability to scan without using a vendor
>> backend driver, free or non-free. [...]
> 
> You didn't comment on this text, does it mean it passes your judgement?

It all looks okay.  "Vendor backend driver" is a strange expression,
but it seems to be what people are used to!
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Cyril Brulebois]

Hi Rick,

Rick Thomas  (2021-03-14):
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster
> to Bullseye and now haveged crashes.
> 
> $ sudo service haveged status
> * haveged.service - Entropy Daemon based on the HAVEGE algorithm
>  Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
> preset: enabled)
>  Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h 
> ago
>Docs: man:haveged(8)
>  http://www.issihosts.com/haveged/
> Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
> $DAEMON_ARGS (code=killed, signal=SYS)
>Main PID: 1610 (code=killed, signal=SYS)
> CPU: 247ms
> 
> Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
> restart counter is at 5.
> Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
> algorithm.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated 
> too quickly.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 
> 'signal'.
> Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on 
> the HAVEGE algorithm.

Please use systemctl status haveged -n 100 or something. The lines
quoted above merely capture the fact that systemd gave up trying to
start it.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options

[Werner Koch]

On Sun, 14 Mar 2021 14:32, Christoph Biedl said:

> Point is, the legacy file ~/.gnupg/options is still being used in
> surprisingly many applications, also in documentation:

Then please file a bug against such documentation.  And maybe even
against any application which read the option filre directly, that is
without using gpgconf.

> https://codesearch.debian.net/search?q=.gnupg%2Foptions&literal=1

Look at the code shown tehre: Almost everywhere it is used as a fallback
from gpg.conf.

> In Debian, revert that commit, and emit a deprecation warning if the
> legacy file is parsed.

Sysadmins will kill you if you do that.  The global conf file has been a
long standing request from many parties.  It comes very hadny for large
installations because it can be used to enforce options on users.  That
is why I took the trouble to actually backported this from master.

Supporting the legacy option file would be a Bad Idea.  In particular
for a new major release it should be not a problem to add release notes
mention that after 18 years the deprecated legacy option file is not
anymore supported.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#985218: package-supports-alternative-init-but-no-init.d-script is outdated

[Felix Lechner]

Hi Faidon,

On Sun, Mar 14, 2021 at 8:42 AM Faidon Liambotis  wrote:
>
> I maintain a package

Thank you for bringing this to our attention. I would like to test the
proposed changes with your package. What is the name, please? Thanks!

Kind regards,
Feli Lechner

Bug#985224: unblock: rheolef/ 7.1-6

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pierre.saram...@imag.fr debian-scie...@lists.debian.org

Please unblock package rheolef

[ Reason ]
The current version of rheolef in Testing has piuparts error
(Buster2Bullseye, missing Breaks+Conflicts) as shown in
https://bugs.debian.org/984529 . The current version in Sid targets on
fixing this RC bug.

[ Impact ]
If the bug is not fixed, the upgrade from Debian 10 to Debian 11 will
fail when both rheolef and librheolef-dev are installed.

[ Tests ]
Piuparts test failed for package in Testing but succeeded for package
in Sid. See: https://piuparts.debian.org/sid/source/r/rheolef.html

[ Risks ]
No risk expected.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock rheolef/ 7.1-6
diff -Nru rheolef-7.1/debian/changelog rheolef-7.1/debian/changelog
--- rheolef-7.1/debian/changelog	2021-01-01 04:20:09.0 -0500
+++ rheolef-7.1/debian/changelog	2021-03-13 11:30:49.0 -0500
@@ -1,3 +1,29 @@
+rheolef (7.1-6) unstable; urgency=medium
+
+  * Team upload.
+  * Really properly bump all versioned Breaks+Replaces relationship
+to (<< 7.1-6~). See #984529.
+
+ -- Boyuan Yang   Sat, 13 Mar 2021 11:30:49 -0500
+
+rheolef (7.1-5) unstable; urgency=medium
+
+  * Team upload.
+  * Properly write Breaks+Replaces relationship, use librheolef-dev
+instead of incorrect rheolef-dev. Really fixes #984529.
+
+ -- Boyuan Yang   Fri, 12 Mar 2021 15:38:50 -0500
+
+rheolef (7.1-4) unstable; urgency=high
+
+  * Team upload.
+  * debian/control: Bump Breaks+Replaces relationship between package
+rheolef and librheolef-dev from (<< 6.1) to (<< 7.1-4~).
+(Closes: #984529)
+  * debian/changelog: Remove trailing spaces.
+
+ -- Boyuan Yang   Wed, 10 Mar 2021 21:45:18 -0500
+
 rheolef (7.1-3) unstable; urgency=medium
 
   * d/patches
@@ -112,7 +138,7 @@
   thanks to Joachim Reichel 
 - mpi-autodetect.patch: fixes openmpi and libscotch autodetection in
   autoconf files
-  * rules: add -g compilation flag for debug symbols 
+  * rules: add -g compilation flag for debug symbols
   * control: Standards-Version updated to 4.1.1
   * compat:  debhelper version updated to 9
 
@@ -121,7 +147,7 @@
 rheolef (6.7-3) unstable; urgency=medium
 
   * Team upload
-  * Do not treat all compilers warnings as errors, 
+  * Do not treat all compilers warnings as errors,
 this avoids a FTBFS with GCC 7 (Closes: #853641)
 
  -- Graham Inggs   Mon, 07 Aug 2017 18:25:34 +0200
@@ -141,7 +167,7 @@
  - fix for latex documentation build  (closes: #824788)
  - source code compile now with g++-6 (closes: #811590)
 
-  * control: 
+  * control:
 - architectures:
   armel armhf s390x s390 ia64 sparc : not considered (compliation problems)
 - depends:
@@ -159,7 +185,7 @@
with damped_newton algorithms
  - sparse matrix determinant computations in solver (mumps o umfpack)
  - write in append mode for gziped parallel output files (branch; etc)
-  * control: 
+  * control:
 * Standards-Version updated to version 3.9.6
 * Recommends: replace gnuplot by gnuplot-x11
   * rules: automatically generated compilation flags (fortify)
@@ -261,7 +287,7 @@
   * New upstream release 6.0 (major changes):
 - massively distributed and parallel support
 - full FEM characteristic method (Lagrange-Gakerkin method) support
-- enhanced users documentation 
+- enhanced users documentation
 - source code supports g++-4.7 (closes: #667356)
   * debian/control: dependencies for MPI distributed solvers added
   * debian/rules: build commands simplified
@@ -293,10 +319,10 @@
 
 rheolef (5.92-2) unstable; urgency=low
 
-  * debian/control: 
+  * debian/control:
 - rheolef-doc: add older package name "librheolef-doc" in "replace" and
   "conflict" sections (Closes: Bug#612556)
- 
+
  -- Pierre Saramito   Thu, 9 Feb 2011 10:54:07 +0200
 
 rheolef (5.92-1) unstable; urgency=low
@@ -305,10 +331,10 @@
 - "rheolef" suffix added to all unix manuals (Closes: #607117)
 - minor source code fixes for g++-4.5 (Closes: #607184)
 - minor reference manual fix (Closes: #607038)
-  * debian/control: 
-- libboost-iostreams-dev dependency added, as required by the new 
+  * debian/control:
+- libboost-iostreams-dev dependency added, as required by the new
   upstream version.
- 
+
  -- Pierre Saramito   Thu, 8 Feb 2011 10:00:06 +0200
 
 rheolef (5.91-1) unstable; urgency=low
@@ -375,4 +401,3 @@
   * bug fix in div_div form : compressible linear elasticity and such.
 
  -- Pierre Saramito   Tue, 17 Jan 2006 16:43:12 +0200
-
diff -Nru rheolef-7.1/debian/control rheolef-7.1/debian/control
--- rheolef-7.1/debian/control	2021-01-01 04:20:09.0 -0500
+++ rheolef-7.1/debian/control	2021-03-13 11:29:33.0 -0500
@@ -106,8 +106,8 @@
   

Bug#971956: release-notes: SANE and driverless scanning

[Paul Gevers]

Hi Justin,

On Sat, 10 Oct 2020 16:27:06 +0100 Brian Potkin 
wrote:
> Driverless scanning is the ability to scan without using a vendor
> backend driver, free or non-free. It is mainly associated with modern
> multi-function devices, but some modern standalone scanners are known to
> work driverless. "Modern" refers to devices that have been marketed in
> the past five years or so.
> 
> The official SANE driverless backend is provided by sane-escl in
> libsane1 [1]. An independently developed driverless backend is
> sane-airscan [2]. Both backends understand the eSCL protocol [3] but
> sane-airscan can also use the WSD protocol [4]. Users should consider
> having both backends on their systems.
> 
> eSCL and WSD are network protocols. Consequently they will operate over
> a USB connection if the device is an IPP-over-USB device [5]. Note that
> libsane1 has ipp-usb [6] as a recommended package. This leads to a
> suitable device being automatically set up to use a driverless backend
> driver when it is connected to a USB port.
> 
> 
> 
> [1] 
> https://packages.debian.org/search?keywords=libsane1&searchon=names&suite=all§ion=all
> [2] 
> https://packages.debian.org/search?keywords=sane-airscan&searchon=names&suite=all§ion=all
> [3] https://wiki.debian.org/SaneOverNetwork#escl
> [4] https://wiki.debian.org/SaneOverNetwork#wsd
> [5] https://wiki.debian.org/CUPSDriverlessPrinting#ippoverusb
> [6] 
> https://packages.debian.org/search?keywords=ipp-usb&searchon=names&suite=all§ion=all

You didn't comment on this text, does it mean it passes your judgement?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985159: mirrors: CD mirrors list out of date - https://www-master.debian.org/build-logs/urlcheck/CD.en

[Andrew M.A. Cater]

Package: mirrors
Followup-For: Bug #985159

Dear Maintainer,

sov.goscomb - no debian-cd mirror there now
osousl - mirror renamed to debian-cdimage



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

Kernel: Linux 4.19.0-14-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#985223: phpldapadmin: maintained by NMUs, has security issues, new upstream versions available

[Salvatore Bonaccorso]

Source: phpldapadmin
Version: 1.2.2-6.3
Severity: serious
Tags: security
Justification: unfit for stable release
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

It looks that phpldapadmin lacks several upstream releases behind, was
recently updated by NMUs but the the base version for phpldapadmin is
from 2012. There is at least as well CVE-2020-35132 unfixed.

Regards,
Salvatore

Bug#876675: Avoid filling up btrfs

[Osamu Aoki]

Hi,

If you wish to check the diskspace used by the btrfs subvolume, you are
suppose to use qgroup thing as mentiond. That is not safe to use.

But if the objective is to avoid filling up the disk. may be abit
simpler approach may help.  Let me explain.

FYI:
If the base of Btrfs is at $BTRFS_BASE, somthing like the following
should be OK as shell code. (__echo is a shell function)

The idea is set limit for minimum absolute disk size and minumum free
desk space percentage.  I am testing idea with free 10% (FMIN=10) disk
space with the following code. 

```
  # disk size sanity check without quota consideration
  BSS_STAT_TOTAL=$(stat -f -c %b "$BTRFS_BASE")
  # Even on 4k block system, disk with 200 blocks is less than 1MB
  if [ "$BSS_STAT_TOTAL" -le 200 ]; then
__echo 0 "Total disk size: $BSS_STAT_TOTAL blocks (too small,
minimum required 200)"
__echo 0 "skip snapshot: BASE=$BTRFS_BASE TIME=${NOW_TSTR}
TYPE=${BSS_TYPE}"
exit 1
  fi
  BSS_STAT_UNIT=$((BSS_STAT_TOTAL/100))
  BSS_STAT_FREE=$(stat -f -c %f "$BTRFS_BASE")
  BSS_FREE_UNIT=$((BSS_STAT_FREE/BSS_STAT_UNIT))
  if [ "$BSS_FREE_UNIT" -le "$BSS_FMIN" ]; then
__echo 0 "Free disk space: $BSS_FREE_UNIT%  (too small, minimum
required FMIN=$BSS_FMIN%)"
__echo 0 "skip snapshot: BASE=$BTRFS_BASE TIME=${NOW_TSTR}
TYPE=${BSS_TYPE}"
exit 1
  else
__echo 2 "Free disk space: $BSS_FREE_UNIT%  (enough, minimum
required FMIN=$BSS_FMIN%)"
  fi
  # make snapshot
  $NOOP $SUDO mkdir -p "$BSS_DIR_BASE" >/dev/null
  while [ -d "$BSS_DIR_BASE/${NOW_TSTR}.${BSS_TYPE}" ]; do
sleep "1s"
NOW_TSTR=$(date -u --iso=second)
  done
  __echo 2 "make snapshot: BASE=$BTRFS_BASE TIME=${NOW_TSTR}
TYPE=${BSS_TYPE}"
  # shellcheck disable=SC2086
  $NOOP $BSV snapshot -r "$BTRFS_BASE"
"$BSS_DIR_BASE/${NOW_TSTR}.${BSS_TYPE}"

```
(This is what I do here for my own needs here and playing with data
aging parameters.)

I think snapper can do the similar.

Bug#985201: flameshot: Unable to capture screen in Sway

[Boyuan Yang]

forwarded -1 https://github.com/flameshot-org/flameshot/issues/1356
thanks

在 2021-03-14星期日的 11:27 +0100，Pelle写道：
> Package: flameshot
> Version: 0.9.0+ds1-1
> Severity: important
> 
> Dear Maintainer,
> 
> After starting Flameshot, a tray icon appears. When clicking on that
> icon, a
> notification is displayed:
> 
> > Flameshot Info
> > Unable to capture screen

Flameshot as of v0.9.0 does not support Sway yet.

-- 
Thanks,
Boyuan Yang


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

Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts

[Steinar H. Gunderson]

On Sun, Mar 07, 2021 at 01:28:19PM +0100, Steinar H. Gunderson wrote:
> On Sun, Mar 07, 2021 at 12:51:36PM +0100, Marcel Partap wrote:
>> Quite strange; I noticed paths missing from my locate DB and digged a bit 
>> into
>> this. It seems for two (?!) of my XFS volumes, only the root directory is 
>> being
>> indexed; updatedb.mlocate recurses the whole tree on these.
>> Tested with
>> 
>>> # updatedb.plocate -vU /mnt/x -o /run/shm/updatedb.plocate.test|wc
>>>  35  37 795
>>> # updatedb.mlocate -vU /mnt/x -o /run/shm/updatedb.mlocate.test|wc
>>> […] ⌛️
>>> 4843228 6172553 528118933
>> 
>> Got the repo checked out, if you have recommendations for debugging this.. 😅
> Could you do strace -vff on updatedb.plocate? (Do note that it will contain
> all your file names, if you care about the privacy of them.)

Hi,

Did anything happen here? (I run XFS on my own machines, and see nothing like
this.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#985221: velocity-tools: CVE-2020-13959

[Salvatore Bonaccorso]

Source: velocity-tools
Version: 2.0-7
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for velocity-tools.

CVE-2020-13959[0]:
| The default error page for VelocityView in Apache Velocity Tools prior
| to 3.1 reflects back the vm file that was entered as part of the URL.
| An attacker can set an XSS payload file as this vm file in the URL
| which results in this payload being executed. XSS vulnerabilities
| allow attackers to execute arbitrary JavaScript in the context of the
| attacked website and the attacked user. This can be abused to steal
| session cookies, perform requests in the name of the victim or for
| phishing attacks.


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-2020-13959
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13959
[1] https://www.openwall.com/lists/oss-security/2021/03/10/2

Regards,
Salvatore

Bug#984760: grub-efi-amd64: Upgrade worked here

[Rainer Dorsch]

Package: grub-efi-amd64
Followup-For: Bug #984760

Dear Maintainer,

just wanted to report that the upgrade worked here flawless.

If any additional information is needed, let me know.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/nvme0n1p4_crypt / btrfs 
rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p2 /boot ext2 rw,relatime 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod btrfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  d486a599-e1eb-4e9f-9f0d-8578e9276bfb
else
  search --no-floppy --fs-uuid --set=root d486a599-e1eb-4e9f-9f0d-8578e9276bfb
fi
font="/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod btrfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  d486a599-e1eb-4e9f-9f0d-8578e9276bfb
else
  search --no-floppy --fs-uuid --set=root d486a599-e1eb-4e9f-9f0d-8578e9276bfb
fi
insmod png
if background_image /usr/share/desktop-base/homeworld-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d486a599-e1eb-4e9f-9f0d-8578e9276bfb' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
52ce073f-68fd-44c6-9d29-e9d040ae76ac
else
  search --no-floppy --fs-uuid --set=root 
52ce073f-68fd-44c6-9d29-e9d040ae76ac
fi
echo'Loading Linux 5.10.0-4-amd64 ...'
linux   /vmlinuz-5.10.0-4-amd64 
root=UUID=d486a599-e1eb-4e9f-9f0d-8578e9276bfb ro  quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-5.10.0-4-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-d486a599-e1eb-4e9f-9f0d-8578e9276bfb' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-4-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.10.0-4-amd64-advanced-d486a599-e1eb-4e9f-9f0d-8578e9276bfb' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
52ce073f-68fd-44c6-9d29-e9d040ae76ac
else
  search --no-floppy --fs-uuid --set=root 
52ce073f-68fd-44c6-9d29-e9d040ae76ac
fi
echo'Loading Linux 5.10.0-4-amd64 ...'
linux   /vmlinuz-5.10.0-4-amd64 
root=UUID=d486a599-e1eb-4e9f-9f0d-8578e

Bug#985220: velocity: CVE-2020-13936

[Salvatore Bonaccorso]

Source: velocity
Version: 1.7-5.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.7-5

Hi,

The following vulnerability was published for velocity.

CVE-2020-13936[0]:
| An attacker that is able to modify Velocity templates may execute
| arbitrary Java code or run arbitrary system commands with the same
| privileges as the account running the Servlet container. This applies
| to applications that allow untrusted users to upload/modify velocity
| templates running Apache Velocity Engine versions up to 2.2.


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-2020-13936
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13936
[1] https://www.openwall.com/lists/oss-security/2021/03/10/1

Regards,
Salvatore

Bug#985219: xbs -- Fails to build reproducibly due to varying umask

[Nilesh Patra]

Package: xbs
Version: 0-10
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: nil...@debian.org, reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

Hi

Currently xbs fails to build reproducibly because varying file creation
masks values result in different permissions for the "runex" example
binary.

Please either defer this to dh_fixperms, or manually set permissions for
this file.
The attached patch does that job.

Nilesh

diff --git a/debian/rules b/debian/rules
index 86ab906..5501154 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ override_dh_installchangelogs:

 override_dh_installexamples:
dh_installexamples
-   chmod +x debian/xbs/usr/share/doc/xbs/examples/runex
+   chmod u=rwx,g=rx,o=x debian/xbs/usr/share/doc/xbs/examples/runex

 override_dh_compress:
# Leave these uncompressed so that runex works.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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: unable to detect

Versions of packages xbs depends on:
ii  libc6 2.31-3
ii  libx11-6  2:1.6.12-1

xbs recommends no packages.

xbs suggests no packages.

Bug#985218: package-supports-alternative-init-but-no-init.d-script is outdated

[Faidon Liambotis]

Package: lintian
Version: 2.104.0
Severity: normal

The package-supports-alternative-init-but-no-init.d-script check has
this text at the end:
N:   Refer to Debian Policy Manual section 9.11 (Alternate init systems)
N:   for details.

However, section 9.11 reads "This section has been deleted." in the
Policy. So at minimum that needs to be fixed :)

Furthermore, the check tests for the absence of an init.d script, and
specifically says: "[...] must provide init.d script for starting that
services with sysvinit". My understanding is that this is not a "must"
anymore, and thus this check needs to either go away, or its language
changed to be more like "would be nice to ship as sysvinit if you can".

(Practically speaking, I maintain a package that ships a systemd unit
file, but does not ship an init.d file, and it'd be extra hard to do so.
I've added a lintian override, but I question the accuracy and value of
this check more broadly.)

Thanks,
Faidon

Bug#985040: qemu-system-data: too tight dependencies breaking on binNMUs

[Sven Joachim]

Control: reopen -1

On 2021-03-14 13:59 +0300, Michael Tokarev wrote:

> Version: 1:5.2+dfsg-7
>
> 12.03.2021 09:52, Sven Joachim wrote:
>> Package: qemu-system-data
>> Version: 1:5.2+dfsg-6
>> Severity: serious
>> The fix for #956377 has made the latest binNMU of qemu-system-x86
>> uninstallable:
>
> This is fixed by 1:5.2+dfsg-7 upload, and I missed to mention this bugreport
> in the Closes: clause.

No, it is not fixed.  You removed the dependencies from
qemu-system-common, but the ones in qemu-system-data remain.  The next
binNMU will therefore reintroduce the uninstallability. :-(

AFAICS the right fix would be to make qemu-system-x86 and co. depend on
qemu-system-data (= ${source:Version}) and remove the dependencies on
qemu-system-foo from qemu-system-data.

Cheers,
   Sven

Bug#984776: tightvncserver: fails to start when $HOME contains a whitespace

[Sven Geuer]

Hello Lucio,

Am Montag, dem 08.03.2021 um 11:15 +0100 schrieb Lucio Crusca:
> [...]
> # adduser --home '/home/john doe' johndoe
> [...]
> cat: doe/.vnc/passwd: No such file or directory
> xauth:  timeout in locking authority file /home/john
> xauth:  timeout in locking authority file /home/john
> sh: 1: cannot create /home/john: Permission denied
> cat: /home/john: No such file or directory
> cat: 'doe/.vnc/t470:1.pid': No such file or directory
> Couldn't start Xtightvnc; trying default font path.
> [...]

Thank you for bringing up this issue. It may take some time before I
can look into it, though.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#985217: unblock: samba/2:4.13.5+dfsg-1

[Mathieu Parent (Debian)]

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

Please unblock package samba

This is an update from 4.13.4 to 4.13.5 (requested in #984863).

[ Reason ]
This is a stability fixes release.

Full list of changes:
o  Trever L. Adams 
   * BUG 14634: s3:modules:vfs_virusfilter: Recent talloc changes cause infinite
 start-up failure.

o  Jeremy Allison 
   * BUG 13992: s3: libsmb: Add missing cli_tdis() in error path if encryption
 setup failed on temp proxy connection.
   * BUG 14604: smbd: In conn_force_tdis_done() when forcing a connection closed
 force a full reload of services.

o  Andrew Bartlett 
   * BUG 14593: dbcheck: Check Deleted Objects and reduce noise in reports about
 expired tombstones.

o  Ralph Boehme conn->session_info for the initial
 delete-on-close token.

o  Peter Eriksson 
   * BUG 14648: s3: VFS: nfs4_acls. Add missing TALLOC_FREE(frame) in error
 path.

o  Björn Jacke 
   * BUG 14624: classicupgrade: Treat old never expires value right.

o  Volker Lendecke 
   * BUG 14636: g_lock: Fix uninitalized variable reads.

o  Stefan Metzmacher 
   * BUG 13898: s3:pysmbd: Fix fd leak in py_smbd_create_file().

o  Andreas Schneider 
   * BUG 14625: lib:util: Avoid free'ing our own pointer.

o  Paul Wise 
   * BUG 12505: HEIMDAL: krb5_storage_free(NULL) should work.

[ Impact ]
At least Paul Wise is affected. See:

https://bugzilla.samba.org/show_bug.cgi?id=13992
https://bugzilla.samba.org/show_bug.cgi?id=12505


[ Tests ]
As is every samba release, the testsuite is improved.

I've also tested the package.

[ Risks ]

[ Checklist ]

  [ ] all changes are documented in the d/changelog

I forgot samba was a key package, so the changelog is not complete.
The missing pieces are above.

  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

Attached are releavant changes (removing diff in the doc about the version).


[ Other info ]
I may ask another unblock request before the bullseye release if samba
4.13.6+ is released.

unblock samba/2:4.13.5+dfsg-1
diff --git a/Makefile b/Makefile
index 0b7b0ae8866..7f5960d5191 100644
--- a/Makefile
+++ b/Makefile
@@ -15,6 +15,9 @@ uninstall:
 test:
 	$(WAF) test $(TEST_OPTIONS)
 
+testonly:
+	$(WAF) testonly $(TEST_OPTIONS)
+
 perftest:
 	$(WAF) test --perf-test $(TEST_OPTIONS)
 
diff --git a/VERSION b/VERSION
index 130087004f0..c24df6ba32e 100644
--- a/VERSION
+++ b/VERSION
@@ -25,7 +25,7 @@
 
 SAMBA_VERSION_MAJOR=4
 SAMBA_VERSION_MINOR=13
-SAMBA_VERSION_RELEASE=4
+SAMBA_VERSION_RELEASE=5
 
 
 # If a official release has a serious bug  #
diff --git a/WHATSNEW.txt b/WHATSNEW.txt
index 544f4377bfd..8b8c349eaa5 100644
--- a/WHATSNEW.txt
+++ b/WHATSNEW.txt
@@ -1,3 +1,79 @@
+   ==
+   Release Notes for Samba 4.13.5
+   March 09, 2021
+   ==
+
+
+This is the latest stable release of the Samba 4.13 release series.
+
+
+Changes since 4.13.4
+
+
+o  Trever L. Adams 
+   * BUG 14634: s3:modules:vfs_virusfilter: Recent talloc changes cause infinite
+ start-up failure.
+
+o  Jeremy Allison 
+   * BUG 13992: s3: libsmb: Add missing cli_tdis() in error path if encryption
+ setup failed on temp proxy connection.
+   * BUG 14604: smbd: In conn_force_tdis_done() when forcing a connection closed
+ force a full reload of services.
+
+o  Andrew Bartlett 
+   * BUG 14593: dbcheck: Check Deleted Objects and reduce noise in reports about
+ expired tombstones.
+
+o  Ralph Boehme conn->session_info for the initial
+ delete-on-close token.
+
+o  Peter Eriksson 
+   * BUG 14648: s3: VFS: nfs4_acls. Add missing TALLOC_FREE(frame) in error
+ path.
+
+o  Björn Jacke 
+   * BUG 14624: classicupgrade: Treat old never expires value right.
+
+o  Volker Lendecke 
+   * BUG 14636: g_lock: Fix uninitalized variable reads.
+
+o  Stefan Metzmacher 
+   * BUG 13898: s3:pysmbd: Fix fd leak in py_smbd_create_file().
+
+o  Andreas Schneider 
+   * BUG 14625: lib:util: Avoid free'ing our own pointer.
+
+o  Paul Wise 
+   * BUG 12505: HEIMDAL: krb5_storage_free(NULL) should work.
+
+
+###
+Reporting bugs & Development Discussion
+###
+
+Please discuss this release on the samba-technical mailing list or by
+joining the #samba-technical IRC channel on irc.freenode.net.
+
+If you do report problems then please try to send high quality
+feedback. If you don't provide vital information to help us track down
+the problem then you will probably be ignored.  All bug reports should
+be filed under the Samba 4.1 and newer product in the project's Bugzilla
+database (https://bugzilla.samba.org/).
+
+
+