date:20210506

I have now 'finally' gotten the error 'I was looking for':

Traceback (most recent call last):
  File "/usr/bin/py3compile", line 319, in 
main()
  File "/usr/bin/py3compile", line 290, in main
compile(files, compile_versions, options.force,
  File "/usr/bin/py3compile", line 201, in compile
interpreter.magic_number(version), mtime)
  File "/usr/share/python3/debpython/interpreter.py", line 233, in magic_number
result = self._execute('import imp; print(imp.get_magic())', version)
  File "/usr/share/python3/debpython/interpreter.py", line 359, in _execute
raise Exception('{} failed with status code {}'.format(command, 
output['returncode']))
Exception: python3.9 -c 'import imp; print(imp.get_magic())' failed with status 
code 139
dpkg: error processing package python3-minimal (--configure):
 installed python3-minimal package post-installation script subprocess returned 
error exit status 1

And this in 'dmesg':
[44932.698657] python3.9[313800]: segfault at 2524310 ip 005637c0 sp 
7ffdeefd1098 error 4 in qemu-aarch64-static[401000+3e3000]
[44932.698664] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 
74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 
25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b

HTH

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

Bug#988177: aptitude: character encoding issues within the manual

2021-05-06 Thread Christoph Anton Mitterer

Package: aptitude
Version: 0.8.13-3
Severity: normal



Hey.

When opening the manual from within aptitude, I always see character
encoding issues (just within the manual, the rest of aptitude is fine).

With:
LANG=C.UTF-8
tables look like:
   ââ¼¤ 

 ▒
   â Actions â Forget new   â Discard all information about whatâ   

 ▒
   â packages (f)   â packages are ânewâ (empty the âNewâ   

 ▒
   ââ Packagesâ tree).  â   

 ▒
   ââ¼¤ 

 ▒
   ââ Cancel all pending actions from this  â   

 ▒
   ââ session (including installations, â   

 ▒
   â Actions â Cancel pending   â removals, upgrades, holds, marking as â   

 ▒
   â actionsâ automatically installed...). This is  â   

 ▒
   ââ roughly equivalent to restart the â   

 ▒
   ââ program.  â   

 ▒
   ââ¼¤ 

 ▒
   â Actions â Clean packageâ Delete all the compressed packages that   â   

 ▒
   â cache  â were downloaded by aptitude ^[a]. â   

 ▒
   ââ¼¤ 

 ▒

With
LANG=C.UTF-8
the tables’ borders don't seem to appear at all.


Cheers,
Chris.

Bug#988176: repo: Package version 2.14 for bullseye

2021-05-06 Thread Dmitry Semyonov

Package: repo
Version: 1.13.2-1
Severity: wishlist

Dear Maintainer,

Is there a chance to package the 2.14 version in time for the upcoming
Debian bullseye release?

The upstream compatibility version was recently bumped to 2.14.
That causes the following unpleasant warning with some repositories
when trying to use older repo versions currently shipped in Debian:

... A new version of repo (2.14) is available.
... New version is available at: [...]/.repo/repo/repo
... The launcher is run from: /usr/bin/repo
!!! The launcher is not writable.  Please talk to your sysadmin or distro
!!! to get an update installed.

-- 
...Bye..Dmitry.

Bug#988175: colrm: Document on the man page that it cannot deal with binary files

2021-05-06 Thread Dan Jacobson

Package: bsdextrautils
Version: 2.36.1-7
X-Debbugs-Cc: util-li...@vger.kernel.org
File: /usr/bin/colrm

Document on the colrm man page that it cannot deal with "binary" files.

$ 
f=.config/google-chrome-unstable/BrowserMetrics/BrowserMetrics-609464BE-1391.pma

# A similar file is surely available on your computer.

$ colrm 88 < $f; echo $?
0

# 0, how pleasant. But then where's the output?

$ strace colrm 88 < $f
...
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", 
O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=27002, ...}) = 0
mmap(NULL, 27002, PROT_READ, MAP_SHARED, 3, 0) = 0x7f5caf526000
close(3)= 0
fstat(0, {st_mode=S_IFREG|0600, st_size=4194304, ...}) = 0
read(0, 
"\334\5\203@\0\0@\0\0\0@\0\2\0\0\0C\335]\223\0\0\0\0@\0\0\0\0\0\0\0"..., 4096) 
= 4096
dup(1)  = 3
close(3)= 0
dup(2)  = 3
close(3)= 0
exit_group(0)   = ?
+++ exited with 0 +++
$ cat -v $f|colrm 88
M-\^EM-^C@^@^@@^@^@^@@^@^B^@^@^@CM-]]M-^S^@^@^@^@@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@M-PM-U^
0M--^@^@^@^@UV+k<^B^@^@^@^@^@^@^@^A^@^@^@^B^@^A^@UV+k<^@^@^@^@^@^@^@^@^@^
...

Bug#985104: closing 985104

2021-05-06 Thread Thomas Goirand

On 5/6/21 9:03 PM, Salvatore Bonaccorso wrote:
> close 985104 2:17.1.1-1
> thanks
> 
> Apparently, following https://bugs.launchpad.net/neutron/+bug/1902917 there is
> disagreement on if the issue was incompletely fixed or not but still upstream
> seems to have considered CVE-2021-20267.
> 
> OpenStack maintainers, double-check as well please.
> 
> Regards,
> Salvatore

Hi Salvatore,

To me, the issue isn't fixed upstream. The patch at:
https://review.opendev.org/c/openstack/neutron/+/783743

hasn't been merged. I expect it to be backported by upstream to the
version in Bullseye.

Probably it would be more reasonable to wait until the patch is merged
upstream before we/I apply it in Debian.

Cheers,

Thomas Goirand (zigo)

Bug#988174: /usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64

Package: qemu-user-static
Version: 1:5.2+dfsg-10
Severity: normal
File: /usr/bin/qemu-aarch64-static
X-Debbugs-Cc: pkg-raspi-maintain...@lists.alioth.debian.org

When trying to build an arm64 image for Raspberry Pi image specs
(https://salsa.debian.org/raspi-team/image-specs) I and others have
gotten a segfault when installing pyton3[-minimal] on a regular basis,
but not always.
This is essentially a 'forwarded' for an issue reported in its issue
tracker: https://salsa.debian.org/raspi-team/image-specs/-/issues/42

I had to try 3 times now to trigger the issue, but now I 'succeeded'.

You can reproduce it as follows:
- clone the 'image-specs' repo
- add 'python3' or 'python3-minimal' to the "apt: install" step
- run as root or via sudo: make raspi_3_bullseye.img

If it succeeds (you'll see "All went fine."), try again (and again) till
it fails.

Relevant part of the log file created during image built:
===
Setting up linux-image-5.10.0-6-arm64 (5.10.28-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-6-arm64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-6-arm64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-6-arm64
I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-6-arm64
Setting up linux-image-arm64 (5.10.28-1) ...
Setting up ssh (1:8.4p1-5) ...
Processing triggers for libc-bin (2.31-11) ...
Processing triggers for ca-certificates (20210119) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-6-arm64
Processing triggers for dbus (1.12.20-2) ...

2021-05-06 23:44:24 DEBUG STDERR: E: Can not write log (Is /dev/pts mounted?) - 
posix_openpt (19: No such device)
Moving old data out of the way
Created symlink /etc/systemd/system/sysinit.target.wants/apparmor.service -> 
/lib/systemd/system/apparmor.service.
invoke-rc.d: could not determine current runlevel
ls: cannot access '/boot/initrd.img-*': No such file or directory
raspi-firmware: no initrd found in /boot/initrd.img-*, cannot populate 
/boot/firmware
Updating certificates in /etc/ssl/certs...
129 added, 0 removed; done.
Segmentation fault
dpkg: error processing package python3.9 (--configure):
 installed python3.9 package post-installation script subprocess returned error 
exit status 139

===

And the following gets written to 'dmesg':

===
[38867.808238] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
(null)
[38867.849329] show_signal_msg: 38 callbacks suppressed
[38867.849331] arm64[112046]: segfault at 1e54310 ip 005637c0 sp 
7ffc88256398 error 4 in qemu-aarch64-static[401000+3e3000]
[38867.849339] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 
74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 
25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
[38989.616760] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
(null)
[39277.809928] python3.9[134304]: segfault at 24de310 ip 005637c0 sp 
7ffc4cc1e6f8 error 4 in qemu-aarch64-static[401000+3e3000]
[39277.809936] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 
74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 
25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b

===

I noticed there's now also a segfault on 'arm64', but I don't think I've
seen that before. The one that *consistently* pops up *when* it fails,
is "dpkg: error processing package python3.9 (--configure)", although,
thus far it was actually python3-minimal, during the '--configure' step.

Normally the logical candidate to file this against is python3, but 
'we' (various ppl on #debian-raspberrypi and in the previous mentioned 
issue) have not seen this issue on a native arm64 device or under 
systemd-nspawn.

https://salsa.debian.org/raspi-team/image-specs/-/issues/40#note_216315
(and following) also contains several 'segfault' incidents.



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

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.1-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.9.5p2-3

-- no debconf information

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

2021-05-06 Thread Cyril Brulebois

Steve McIntyre  (2021-05-06):
> Hmmm, odd. I've not touched that at all. But maybe it's part of the
> debug that kibi is doing with fonts etc. atm...

I certainly didn't touch anything yet: unless otherwise specified, my
testing happens before touching the archive.

If one wants to look into it, we have build logs alongside images at:
  https://d-i.debian.org/daily-images/

and also MANIFESTS{,.udeb} files, in case the set of udebs changed.

(I only see a single change in the master branch for the installer, from
Steve as alluded to earlier in this thread.)


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


signature.asc
Description: PGP signature

Bug#988166: breezy breaks check-manifest autopkgtest: brz: ERROR: No module named 'dulwich'

2021-05-06 Thread Jelmer Vernooĳ

On Thu, May 06, 2021 at 09:36:30PM +0200, Paul Gevers wrote:
> With a recent upload of breezy the autopkgtest of check-manifest fails
> in testing when that autopkgtest is run with the binary packages of
> breezy from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> breezy from testing3.2.0-1
> check-manifest from testing0.46-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Looking at the
> error message, it seems that either package needs an additional
> dependency on dulwich.
> 
> Currently this regression is blocking the migration of breezy to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package? Note, because we're in the freeze for
> bullseye, we need to take a bit of care. I have marked this bug as
> bullseye-ignore because I don't intent this bug to cause the removal of
> check-manifest from bullseye and the autopkgtest failure will keep this
> version of breezy out of bullseye automatically.
> 
> More information about this bug and the reason for filing it can be found 
> on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=breezy
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/check-manifest/12161616/log.gz
> 
> ==
> ERROR: test_get_vcs_files (tests.TestBzr)
> --
> Traceback (most recent call last):
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 992, in test_get_vcs_files
> self._init_vcs()
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 978, in _init_vcs
> self.vcs._init_vcs()
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 1128, in _init_vcs
> self._run('bzr', 'init')
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 949, in _run
> raise subprocess.CalledProcessError(rc, command[0], output=stdout)
> subprocess.CalledProcessError: Command 'bzr' returned non-zero exit
> status 3.
>  >> begin captured stdout << -
> $ bzr init
> brz: ERROR: No module named 'dulwich'
> You may need to install this Python library separately.
Pretty sure this is a Breezy regression - at the very least it should be
giving a clearer error message.

I'll take a look.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#987976: mediawiki: autopkgtests are missing restrictions and dependencies

2021-05-06 Thread Kunal Mehta


Hi,

On 5/2/21 7:42 PM, Tobias Wiese wrote:

The install-* autopkgtest require the start of services and should
therefore be tagged with the isolation-container restriction.
They also use the systemctl command from the systemd package which is
missing in the depends field.

I also think that the lint test should be marked with the superficial
restriction, as it doesn't test the installed packages functionality,
but its code style.


Thanks! I pushed these to the Git repo, will include it in the next 
upload or after the freeze. I assume that since you marked this as minor 
it isn't important to get in for bullseye?


-- Kunal

Bug#985786: systemd: should be restartable even with mounted network filesystems

Control: forwarded -1 https://github.com/systemd/systemd/issues/16156
Control: tags -1 fixed-upstream

On Wed, 24 Mar 2021 12:30:55 +0100 Michael Biebl  wrote:
> Am 23.03.2021 um 16:23 schrieb Michael Biebl:
> > Please consider raising this upstream at
> > https://github.com/systemd/systemd
> > 
> > It's very likely that upstream has some follow up questions.
> > 
> > I would suggest to include your strace in that upstream bug report and 
> > also attach your /etc/fstab.
> 
> This sounds a bit like https://github.com/systemd/systemd/issues/16156
> Unfortunately your strace log was clipped off.
> 
> Can you try https://github.com/systemd/systemd/pull/19101 ?
> 

As I haven't heard back from you, I'm tentatively marking this issue as
fixed upstream


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

Bug#988171: projectm-data: please add Breaks+Replaces: libprojectm2

Package: projectm-data
Version: 3.1.7-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libprojectm2 libprojectm-qt1

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie' to 'stretch' to 'buster'.
It installed fine in 'jessie', and upgraded to 'stretch' and 'buster'
successfully,
but then the upgrade to 'bullseye' failed.

libprojectm2 seems to have stayed installed in this test for a long time
along projectm-data.

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

  Preparing to unpack .../74-projectm-data_3.1.7-1_all.deb ...
  Unpacking projectm-data (3.1.7-1) over (2.1.0+dfsg-4) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-Gdw01s/74-projectm-data_3.1.7-1_all.deb (--unpack):
   trying to overwrite '/usr/share/projectM/config.inp', which is also in 
package libprojectm2 2.1.0+dfsg-1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-Gdw01s/74-projectm-data_3.1.7-1_all.deb


cheers,

Andreas


libprojectm-qt1_None.log.gz
Description: application/gzip

Bug#982877: firefox-esr: please provide an official way to run using wayland

2021-05-06 Thread Amr Ibrahim

On Mon, 15 Feb 2021 14:32:53 -0500 Andres Salomon  
wrote:

> In a wayland environment, by default firefox will run as an X
> application using Xwayland. This can be changed with 'export
> MOZ_ENABLE_WAYLAND=1' before calling firefox-esr, but that isn't
> integrated into a desktop environment. It would be good to get it
> integrated.

Thanks for the hint. I added "export MOZ_ENABLE_WAYLAND=1" to my 
~/.profile file, restarted the session, and now Firefox and Thunderbird 
run on Wayland by default (they respect the fractional scaling so that's 
how I know they run on Wayland).

Bug#988172: libgss3: please add Breaks+Replaces: libgss0

Package: libgss3
Version: 1.0.3-6
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libgss-dev

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'lenny' to 'squeeze' to 'wheezy' to 'jessie' to 'stretch' to 'buster' to
'bullseye'.
It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy',
'jessie', 'stretch', and 'buster' successfully,
but then the upgrade to 'bullseye' failed.

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

  Preparing to unpack .../17-libgss3_1.0.3-6_amd64.deb ...
  Unpacking libgss3:amd64 (1.0.3-6) over (1.0.3-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-mPZZEz/17-libgss3_1.0.3-6_amd64.deb (--unpack):
   trying to overwrite '/usr/share/locale/en@boldquot/LC_MESSAGES/gss.mo', 
which is also in package libgss0 0.0.23-3

libgss0 seems to have survived a very long time along libgss-dev
which got constantly upgraded.


cheers,

Andreas


libgss-dev_1.0.3-6.log.gz
Description: application/gzip

Bug#988165: obsolete conffile not removed

Le jeudi 06 mai 2021 à 20:57 +0200, Sébastien Villemot a écrit :
> Package: unp
> Version: 2.0~pre8

> In version 2.0~pre8, the bash completion file was moved from /etc to 
> /usr/share.
> 
> However, the obsolete conffile is not properly clean up during the upgrade
> (e.g. from buster to bullseye):

Actually I realize that the conffile is removed from the postinst
script.

However, this is not sufficient, since the file still appears in the
dpkg database (and is marked there as obsolete). I guess this is
because the removal was done with an ad hoc shell snippet, instead of
using the appropriate tooling from dh_installdeb / .maintscript.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#985050: jackd2: libdb-dev dependency is missing

2021-05-06 Thread Chris Hofstaedtler

* Geoffrey McRae  [210506 20:10]:
> I would also like to confirm this issue, failure to include the database
> support breaks the metadata feature that was added. The configure flag for
> this is `--db` and is required for applications such as Carla to share and
> store positional information for the plugins/clients in use.

Just want to point out that Debian might want to remove libdb
(= Berkely DB 5.x) in bookworm. Adding this dependency would not
last very long.

Chris

Bug#988170: libwbclient0: please add Breaks+Replaces: libsamba-util0

Package: libwbclient0
Version: 2:4.13.5+dfsg-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libsmbclient-raw0 samba4-common-bin

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'wheezy' to 'jessie' to 'stretch' to 'buster'.
It installed fine in 'wheezy', and upgraded to 'jessie', 'stretch' and
'buster' successfully,
but then the upgrade to 'bullseye' failed.

libsamba-util0 has not existed for many releases, but stayed installed
in this test. Now some other package reintroduced a file with a clashing
filename.

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

  Preparing to unpack .../06-libwbclient0_2%3a4.13.5+dfsg-1_amd64.deb ...
  Unpacking libwbclient0:amd64 (2:4.13.5+dfsg-1) over (2:4.9.5+dfsg-5+deb10u1) 
...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-yZI30I/06-libwbclient0_2%3a4.13.5+dfsg-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libsamba-util.so.0.0.1', 
which is also in package libsamba-util0:amd64 4.0.0~beta2+dfsg1-3.2+deb7u2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

There is nothing on the upgrade path from wheezy that caused the
ancient libsamba-util0 package to be removed. libwbclient0 was installed
all the time.


cheers,

Andreas


libsmbclient-raw0_None.log.gz
Description: application/gzip

Bug#988169: unblock: samba/2:4.13.5+dfsg-2

2021-05-06 Thread Mathieu Parent

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

Please unblock package samba.

[ Reason ]

It fixes:

  * CVE-2021-20254: Negative idmap cache entries can cause incorrect group
entries in the Samba file server process token (Closes: #987811)
  * Add Breaks+Replaces: samba-dev (<< 2:4.11) (Closes: #987209)

[ Impact ]

Without the second fix, some buster -> bulleye upgrades will fail.

There is no known exploit for the security issue, but:

> an unprivileged user was able to delete a file within
> a network share that they should have been disallowed access to


[ Tests ]

Minimal manual tests done.

[ Risks ]

?

[ 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 ]
(Anything else the release team should know.)

unblock samba/2:4.13.5+dfsg-2


samba.debdiff
Description: Binary data

Bug#988089: [debian-mysql] Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

2021-05-06 Thread Otto Kekäläinen

So in summary everything else goes OK and upgrade passes, but there is
one 'mariadb-server' metapackage removed which should have been kept:

Removing mariadb-server (1:10.3.27-0+deb10u1) ...   <-
Removing mariadb-server-10.3 (1:10.3.27-0+deb10u1) ...
Removing mariadb-client-10.3 (1:10.3.27-0+deb10u1) ...
Removing mariadb-client-core-10.3 (1:10.3.27-0+deb10u1) ...
Removing mariadb-server-core-10.3 (1:10.3.27-0+deb10u1) ...

Bug#902752: Still a problem in 2021

2021-05-06 Thread Chris Hofstaedtler

Control: fixed -1 0.10.2-2.1

The *default* configuration files in buster already say "imap,imaps"
and not "imap3" any longer.

Apparently fixed upstream.

Chris

Bug#988089: [debian-mysql] Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

2021-05-06 Thread Olaf van der Spek

> So in summary everything else goes OK and upgrade passes

It would be kinda nice to end up with mariadb-server-10.5 too... ;)

Op do 6 mei 2021 om 21:43 schreef Otto Kekäläinen :
>
> So in summary everything else goes OK and upgrade passes, but there is
> one 'mariadb-server' metapackage removed which should have been kept:
>
> Removing mariadb-server (1:10.3.27-0+deb10u1) ...   <-
> Removing mariadb-server-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-client-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-client-core-10.3 (1:10.3.27-0+deb10u1) ...
> Removing mariadb-server-core-10.3 (1:10.3.27-0+deb10u1) ...



-- 
Olaf

Bug#988168: unblock: cifs-utils/6.11-3

2021-05-06 Thread Mathieu Parent (Debian)

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

Please unblock package cifs-utils.

[ Reason ]

It fixes:

CVE-2021-20208: cifs.upcall kerberos auth leak in container
(Closes: #987308)

[ Impact ]

Only needed when using containers. Marked "minor" for stretch and
buster.

[ Tests ]

Minimal manual tests done.

[ Risks ]

?

[ 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 ]
(Anything else the release team should know.)

unblock cifs-utils/6.11-3


cifs-utils.debdiff
Description: Binary data

Bug#988167: breezy breaks silver-platter autopkgtest: not equal: a = 'ssh://g...@git.kali.org/jelmer/blah.git',b = 'git+ssh://g...@git.kali.org/jelmer/blah.git'

2021-05-06 Thread Paul Gevers

Source: breezy, silver-platter
Control: found -1 breezy/3.2.0-1
Control: found -1 silver-platter/0.4.1-2
Severity: serious
Tags: sid bullseye bullseye-ignore
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of breezy the autopkgtest of silver-platter fails
in testing when that autopkgtest is run with the binary packages of
breezy from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
breezy from testing3.2.0-1
silver-platter from testing0.4.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of breezy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?  Note, because we're in the freeze for
bullseye, we need to take a bit of care. I have marked this bug as
bullseye-ignore because I don't intent this bug to cause the removal of
silver-platter from bullseye and the autopkgtest failure will keep this
version of breezy out of bullseye automatically.

More information about this bug and the reason for filing it can be found 
on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=breezy

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/12161617/log.gz

==
FAIL: test_git_ssh
(silver_platter.tests.test_debian.ConvertDebianVcsUrlTests)
silver_platter.tests.test_debian.ConvertDebianVcsUrlTests.test_git_ssh
--
testtools.testresult.real._StringException: Empty attachments:
  log

Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.22bwh14d/downtmp/build.T7v/src/silver_platter/tests/test_debian.py",
line 60, in test_git_ssh
self.assertEqual(
  File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line
1307, in assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = 'ssh://g...@git.kali.org/jelmer/blah.git'
b = 'git+ssh://g...@git.kali.org/jelmer/blah.git'


--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988166: breezy breaks check-manifest autopkgtest: brz: ERROR: No module named 'dulwich'

2021-05-06 Thread Paul Gevers

Source: breezy, check-manifest
Control: found -1 breezy/3.2.0-1
Control: found -1 check-manifest/0.46-1
Severity: serious
Tags: sid bullseye bullseye-ignore
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of breezy the autopkgtest of check-manifest fails
in testing when that autopkgtest is run with the binary packages of
breezy from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
breezy from testing3.2.0-1
check-manifest from testing0.46-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
error message, it seems that either package needs an additional
dependency on dulwich.

Currently this regression is blocking the migration of breezy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package? Note, because we're in the freeze for
bullseye, we need to take a bit of care. I have marked this bug as
bullseye-ignore because I don't intent this bug to cause the removal of
check-manifest from bullseye and the autopkgtest failure will keep this
version of breezy out of bullseye automatically.

More information about this bug and the reason for filing it can be found 
on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=breezy

https://ci.debian.net/data/autopkgtest/testing/amd64/c/check-manifest/12161616/log.gz

==
ERROR: test_get_vcs_files (tests.TestBzr)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 992, in test_get_vcs_files
self._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 978, in _init_vcs
self.vcs._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 1128, in _init_vcs
self._run('bzr', 'init')
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 949, in _run
raise subprocess.CalledProcessError(rc, command[0], output=stdout)
subprocess.CalledProcessError: Command 'bzr' returned non-zero exit
status 3.
 >> begin captured stdout << -
$ bzr init
brz: ERROR: No module named 'dulwich'
You may need to install this Python library separately.


- >> end captured stdout << --

==
ERROR: test_get_vcs_files_added_but_uncommitted (tests.TestBzr)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 1001, in test_get_vcs_files_added_but_uncommitted
self._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 978, in _init_vcs
self.vcs._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 1128, in _init_vcs
self._run('bzr', 'init')
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 949, in _run
raise subprocess.CalledProcessError(rc, command[0], output=stdout)
subprocess.CalledProcessError: Command 'bzr' returned non-zero exit
status 3.
 >> begin captured stdout << -
$ bzr init
brz: ERROR: No module named 'dulwich'
You may need to install this Python library separately.


- >> end captured stdout << --

==
ERROR: test_get_vcs_files_empty (tests.TestBzr)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 1038, in test_get_vcs_files_empty
self._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 978, in _init_vcs
self.vcs._init_vcs()
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 1128, in _init_vcs
self._run('bzr', 'init')
  File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
line 949, in _run
raise subprocess.CalledProcessError(rc, command[0], output=stdout)
subprocess.CalledProcessError: Command 'bzr' returned non-zero exit
status 3.
 >> begin captured stdout << -
$ bzr init
brz: ERROR: No module named 'dulwich'
You may need to install this Python library separately.


- >> end captured stdout << --

Bug#987959: pev: peres affected by off-by-one error in libpe

2021-05-06 Thread Benoît Sevens

Since it can corrupt adjacent heap chunk metadata, this definitely looks
like a security issue to me.

On Thu, May 6, 2021 at 9:29 AM Petter Reinholdtsen  wrote:

>
> I asked for an unblock from the release team in
> https://bugs.debian.org/988095 >.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Bug#988165: obsolete conffile not removed

Package: unp
Version: 2.0~pre8
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,

In version 2.0~pre8, the bash completion file was moved from /etc to /usr/share.

However, the obsolete conffile is not properly clean up during the upgrade
(e.g. from buster to bullseye):

$ adequate unp
unp: obsolete-conffile /etc/bash_completion.d/unp
$ dpkg-query -W -f='${Conffiles}\n' unp | grep obsolete$
 /etc/bash_completion.d/unp 325011df902bf38dcf2ab188fb28f961 obsolete

Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove this obsolete conffile on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

Thanks for your work,

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

Kernel: Linux 5.12.1 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 unp depends on:
ii  perl  5.32.1-4

unp recommends no packages.

Versions of packages unp suggests:
ii  bzip2   1.0.8-4
ii  cabextract  1.9-3
ii  lhasa   0.3.1-3
pn  orange  
ii  p7zip   16.02+dfsg-8
ii  p7zip-full  16.02+dfsg-8
pn  unrar | unrar-free  
ii  unzip   6.0-26
pn  xdms

-- Configuration Files:
/etc/bash_completion.d/unp [Errno 2] Aucun fichier ou dossier de ce type: 
'/etc/bash_completion.d/unp'

-- no debconf information

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#988164: obsolete conffile not removed

Package: rdiff-backup
Version: 1.2.8-8
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,

In version 1.2.8-8, the bash completion file was moved from /etc to /usr/share.

However, the obsolete conffile is not properly clean up during the upgrade
(e.g. from buster to bullseye):

$ adequate rdiff-backup
rdiff-backup: obsolete-conffile /etc/bash_completion.d/rdiff-backup
$ dpkg-query -W -f='${Conffiles}\n' rdiff-backup | grep obsolete$
 /etc/bash_completion.d/rdiff-backup ace9481dc2609603de4ade233623fa03 obsolete

Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove this obsolete conffile on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

Thanks for your work,

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

Kernel: Linux 5.12.1 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 rdiff-backup depends on:
ii  libc6  2.31-11
ii  librsync2  2.3.1-1
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-3
ii  python3-setuptools 52.0.0-3

Versions of packages rdiff-backup recommends:
ii  python3-pylibacl  0.6.0-1+b1
ii  python3-pyxattr   0.7.2-1+b1

rdiff-backup suggests no packages.

-- no debconf information

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#988163: obsolete conffile not removed

Package: radicale
Version: 3.0.6-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,

Radicale 3 no longer ships /etc/radicale/logging.

However, the upgrade from radicale 2 to 3 does not properly clean up this
obsolete conffile:

$ adequate radicale
radicale: obsolete-conffile /etc/radicale/logging
$ dpkg-query -W -f='${Conffiles}\n' radicale | grep obsolete$
 /etc/radicale/logging 8b80eb58ed94b56dc4e1bbfecc5349f4 obsolete

Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

Thanks for your work,

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

Kernel: Linux 5.12.1 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-radicale 3.0.6-2

Versions of packages radicale recommends:
ii  ssl-cert  1.1.0

Versions of packages radicale suggests:
ii  apache2 2.4.46-4
ii  apache2-utils   2.4.46-4
pn  libapache2-mod-proxy-uwsgi  
ii  python3-bcrypt  3.1.7-4
ii  python3-passlib 1.7.4-1
pn  uwsgi   
pn  uwsgi-plugin-python3

-- no debconf information

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#816176: linux-image-4.3.0-0.bpo.1-amd64: xhci_hub_control causes abnormally high CPU usage when no USB devices attached

2021-05-06 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2021-05-06 at 20:11 +0200, Moritz Mühlenhoff wrote:
> Is that still an issue with current kernels?

Hi Moritz, I don't think so. It's been a while since that original bug report,
but I don't think I've recently seem some high CPU usage related to the usb
drive (I can't believe I have that laptop since 6y already :)

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmCUOEIACgkQ3rYcyPpX
RFtlLwf+N2xMDGSm+11cYH51sXF5jLry9R6/QaIz50WyGAy+JtPyzTFJ/+TLaI9r
n6qCUhFul0WJME8c5IQPEq5PP8r0rQkgmkczUmcF+tIAkUFd2T4g0tWbEqp+MJqc
GeUhwCSgRQ+41frz1BKsmUjTsLfLCgQxVR1KuttFQM8rkVPbYDWnd7WdKtr5Y+DC
QQUA5IIiOuU4OM9sttkiYu/aEE2nL93xXKA8WOjWjCluIIRhe6mNg+bqhiIxmTYm
IBpHkR17Bj+hdypprBR2hOT3+0uQtIc9c03FqF5SqGzhIkg8M5zZRoN81vmP+q1z
rHF1kubxQYEp5ic1wKGYIWEDkcEWvg==
=b2Et
-END PGP SIGNATURE-

Bug#988162: python-keystonemiddleware FTBFS in buster: test failure

Source: python-keystonemiddleware
Version: 5.2.0-2
Severity: serious
Tags: ftbfs
Control: close -1 9.1.0-2

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/python-keystonemiddleware.html

...
==
FAIL: 
keystonemiddleware.tests.unit.auth_token.test_auth_token_middleware.DiabloAuthTokenMiddlewareTest.test_valid_diablo_response
keystonemiddleware.tests.unit.auth_token.test_auth_token_middleware.DiabloAuthTokenMiddlewareTest.test_valid_diablo_response
--
_StringException: pythonlogging:'': {{{
Starting Keystone auth_token middleware
AuthToken middleware is set with 
keystone_authtoken.service_token_roles_required set to False. This is backwards 
compatible but deprecated behaviour. Please set this to True.
Use of the auth_admin_prefix, auth_host, auth_port, auth_protocol, 
identity_uri, admin_token, admin_user, admin_password, and admin_tenant_name 
configuration options was deprecated in the Mitaka release in favor of an 
auth_plugin and its related options. This class may be removed in a future 
release.
Using /tmp/tmpw1Tzc0/tmpwEj8yK as cache directory for signing certificate
Using the in-process token cache is deprecated as of the 4.2.0 release and may 
be removed in the 5.0.0 release or the 'O' development cycle. The in-process 
cache causes inconsistent results and high memory usage. When the feature is 
removed the auth_token middleware will not cache tokens by default which may 
result in performance issues. It is recommended to use  memcache for the 
auth_token token cache by setting the memcached_servers option.
Authenticating user token
REQ: curl -g -i -X GET https://keystone.example.com:1234/testadmin -H "Accept: 
application/json" -H "User-Agent: keystonemiddleware/5.2.0 
keystonemiddleware.auth_token/5.2.0 keystoneauth1/3.10.0 python-requests/2.21.0 
CPython/2.7.16"
RESP: [300]
RESP BODY: Omitted, Content-Type is set to None. Only application/json 
responses have their bodies logged.
Auth Token confirmed use of None apis
Making authentication request to 
https://keystone.example.com:1234/testadmin/v2.0/tokens
REQ: curl -g -i -X GET 
https://keystone.example.com:1234/testadmin/v2.0/tokens/b0cf19b55dbb4f20a6ee18e6c6cf1726
 -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -H 
"X-Auth-Token: {SHA1}fa97196656baf1ad10f66098a8b7476ecd6ed8da"
RESP: [200]
RESP BODY: Omitted, Content-Type is set to None. Only application/json 
responses have their bodies logged.
Invalid user token
Rejecting request
}}}

Traceback (most recent call last):
  File 
"keystonemiddleware/tests/unit/auth_token/test_auth_token_middleware.py", line 
396, in test_valid_diablo_response
resp = self.call_middleware(headers={'X-Auth-Token': self.token_id})
  File 
"keystonemiddleware/tests/unit/auth_token/test_auth_token_middleware.py", line 
311, in call_middleware
return self.call(self.middleware, **kwargs)
  File "keystonemiddleware/tests/unit/auth_token/base.py", line 61, in call
self.assertEqual(expected_status, resp.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 200 != 401


--
Ran 357 tests in 5.381s

FAILED (failures=1, skipped=4)
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1

Bug#988146: Linking the freedom-maker issue

Here's the related freedom-maker issue I created about this:
https://salsa.debian.org/freedombox-team/freedom-maker/-/issues/196

Linking it for completeness; the bug report and script contained therein is 
the result of further research into this, so it can easily be reproduced.

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

Bug#816176: linux-image-4.3.0-0.bpo.1-amd64: xhci_hub_control causes abnormally high CPU usage when no USB devices attached

Am Tue, Sep 25, 2018 at 08:19:13PM +0200 schrieb Yves-Alexis Perez:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, 28 Feb 2016 12:19:43 +0100 Anders Nylander 
> wrote:
> 
> > Following the removal of of the USB device, I noticed very high CPU usage
> > being caused by kworker and ksoftirqd.
> > Using perf to log 10s of data and then reading the report, I noticed that
> > xhci_hcd/xhci_hub_control was generating a LOT of work for the kworker
> > (~42%).
> 
> I'm experiencing a very similar behavior on my ThinkPad X250 attached to a
> dock. It doesn't happen every time I resume, but quite often these days (on
> 4.18.8-1). Unplugging an USB3 disk plugged to the dock fixed the problem for
> me, and replugging it worked as well, so maybe there's some kind of loop I
> managed to break with that.
> 
> I also noticed https://bugzilla.redhat.com/show_bug.cgi?id=1325488 on the
> exact same setup, but there's no other info there.
> 
> I'll try to dig upstream, but unfortunately it's not that easily reproducible
> here.

Is that still an issue with current kernels?

Cheers,
Moritz

Bug#988160: python-keystoneclient FTBFS in buster: test failures

Source: python-keystoneclient
Version: 1:3.17.0-2
Severity: serious
Tags: ftbfs
Control: close -1 1:4.1.1-2

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/python-keystoneclient.html

...
==
FAIL: 
keystoneclient.tests.unit.auth.test_identity_v2.V2IdentityPlugin.test_invalidate_response
keystoneclient.tests.unit.auth.test_identity_v2.V2IdentityPlugin.test_invalidate_response
--
_StringException: pythonlogging:'': {{{
Making authentication request to http://127.0.0.1:5000/v2.0/tokens
Making authentication request to http://127.0.0.1:5000/v2.0/tokens
}}}

Traceback (most recent call last):
  File "keystoneclient/tests/unit/auth/test_identity_v2.py", line 281, in 
test_invalidate_response
self.assertEqual({'X-Auth-Token': 'token1'}, s.get_auth_headers())
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: {'X-Auth-Token': 'token1'} != 
{'X-Auth-Token': u'token2'}


==
FAIL: 
keystoneclient.tests.unit.auth.test_identity_v3.V3IdentityPlugin.test_invalidate_response
keystoneclient.tests.unit.auth.test_identity_v3.V3IdentityPlugin.test_invalidate_response
--
_StringException: pythonlogging:'': {{{
Making authentication request to http://127.0.0.1:5000/v3/auth/tokens
{"token": {"methods": ["token", "password"], "expires_at": 
"2020-01-01T00:00:10.000123Z", "project": {"domain": {"id": 
"ab0458e9ce184281b519d41ec3d3920e", "name": 
"cf0e991c365543069ebdf1e577b1732e"}, "id": "4a5b01f95d48452cbc6919c8580a566d", 
"name": "79a67079e53e4cbc82e7f3102eed3d21"}, "catalog": [{"endpoints": [{"url": 
"http://cdn.admin-nets.local:8774/v1.0/;, "interface": "public", "region": 
"RegionOne"}, {"url": "http://127.0.0.1:8774/v1.0;, "interface": "internal", 
"region": "RegionOne"}, {"url": "http://cdn.admin-nets.local:8774/v1.0;, 
"interface": "admin", "region": "RegionOne"}], "type": "nova_compat"}, 
{"endpoints": [{"url": "http://nova/novapi/public;, "interface": "public", 
"region": "RegionOne"}, {"url": "http://nova/novapi/internal;, "interface": 
"internal", "region": "RegionOne"}, {"url": "http://nova/novapi/admin;, 
"interface": "admin", "region": "RegionOne"}], "type": "compute", "name": 
"nova"}, {"endpoints": [{"url": "http://glance/glanceapi/public;, "interface": 
"public", "region": "RegionOne"}, {"url": "http://glance/glanceapi/internal;, 
"interface": "internal", "region": "RegionOne"}, {"url": 
"http://glance/glanceapi/admin;, "interface": "admin", "region": "RegionOne"}], 
"type": "image", "name": "glance"}, {"endpoints": [{"url": 
"http://127.0.0.1:5000/v3;, "interface": "public", "region": "RegionOne"}, 
{"url": "http://127.0.0.1:5000/v3;, "interface": "internal", "region": 
"RegionOne"}, {"url": "http://127.0.0.1:35357/v3;, "interface": "admin", 
"region": "RegionOne"}], "type": "identity"}, {"endpoints": [{"url": 
"http://swift/swiftapi/public;, "interface": "public", "region": "RegionOne"}, 
{"url": "http://swift/swiftapi/internal;, "interface": "internal", "region": 
"RegionOne"}, {"url": "http://swift/swiftapi/admin;, "interface": "admin", 
"region": "RegionOne"}], "type": "object-store"}], "user": {"domain": {"id": 
"ab0458e9ce184281b519d41ec3d3920e", "name": 
"cf0e991c365543069ebdf1e577b1732e"}, "id": "859d1d589a414799b19a15065628f08b", 
"name": "859d1d589a414799b19a15065628f08b"}, "issued_at": 
"2013-05-29T16:55:21.468960Z"}}
Making authentication request to http://127.0.0.1:5000/v3/auth/tokens
{"token": {"methods": ["token", "password"], "expires_at": 
"2020-01-01T00:00:10.000123Z", "project": {"domain": {"id": 
"ab0458e9ce184281b519d41ec3d3920e", "name": 
"cf0e991c365543069ebdf1e577b1732e"}, "id": "4a5b01f95d48452cbc6919c8580a566d", 
"name": "79a67079e53e4cbc82e7f3102eed3d21"}, "catalog": [{"endpoints": [{"url": 
"http://cdn.admin-nets.local:8774/v1.0/;, "interface": "public", "region": 
"RegionOne"}, {"url": "http://127.0.0.1:8774/v1.0;, "interface": "internal", 
"region": "RegionOne"}, {"url": "http://cdn.admin-nets.local:8774/v1.0;, 
"interface": "admin", "region": "RegionOne"}], "type": "nova_compat"}, 
{"endpoints": [{"url": "http://nova/novapi/public;, "interface": "public", 
"region": "RegionOne"}, {"url": "http://nova/novapi/internal;, "interface": 
"internal", "region": "RegionOne"}, {"url": "http://nova/novapi/admin;, 
"interface": "admin", "region": "RegionOne"}], "type": "compute", "name": 
"nova"}, {"endpoints": [{"url": "http://glance/glanceapi/public;, "interface": 
"public", "region": "RegionOne"}, {"url": "http://glance/glanceapi/internal;, 
"interface":

Bug#988159: CVE-2020-36120

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

This was assigned CVE-2020-36120
https://github.com/saitoha/libsixel/issues/143

Cheers,
Moritz

Bug#988158: xscreensaver regularly crashes, leaving screen unlocked

2021-05-06 Thread Daniel Perelman

Package: xscreensaver
Version: 5.45+dfsg1-1
Severity: important
X-Debbugs-Cc: da...@cornell.edu

Dear Maintainer,

As of a few months ago (after a dist-upgrade + reboot), sometimes when I come
back to my desktop computer after leaving it alone for several hours, the
screen is unlocked with xscreensaver no longer running (i.e. locking the screen
no longer works until I run xscreensaver or xscreensaver-demo to restart it). I
haven't noticed any pattern of when it happens other than the screensaver
having been running for several hours, presumably undisturbed. Needless to say,
the screen being unlocked without a password is a security issue, although
admittedly a minor one for my setup.

If I leave xscreensaver running in a console inside screen, I can see output
like the following after a crash (no messages about it appear in dmesg):

$ xscreensaver
xscreensaver-systemd: 09:55:11: failed to connect as
org.freedesktop.ScreenSaver: File exists
xscreensaver:   signal: 0: child pid 3281394 (xscreensaver-systemd) exited
abnormally (code 1).
xscreensaver: 09:55:22: ClientMessage ignored while authentication dialog is
active
xscreensaver: 09:55:30: no keyboard or mouse data in /proc/interrupts?
xscreensaver: 12:05:53: ClientMessage ignored while authentication dialog is
active
xscreensaver: 15:36:23: ClientMessage ignored while authentication dialog is
active
xscreensaver: 19:11:55: ClientMessage ignored while authentication dialog is
active
XIO:  fatal IO error 0 (Success) on X server ":0.0"
  after 1702519 requests (1702495 known processed) with 0 events remaining.
$ X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Resource id in failed request:  0xe41bff8
  Serial number of failed request:  23
  Current serial number in output stream:  24
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Resource id in failed request:  0xe41bffc
  Serial number of failed request:  23
  Current serial number in output stream:  24
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Resource id in failed request:  0xe41bffa
  Serial number of failed request:  23
  Current serial number in output stream:  24


Apologies: the issue is sporadic, so I did not notice it immediately and
therefore did not take note of exactly what the version numbers were
before/after the issue started.

Not sure it's related, but I'm using https://github.com/alexanderk23/gluqlo as
my screensaver program and am using xscreensaver-command -watch to run some
scripts on lock/unlock, based on the Perl script in the man page for
xscreensaver-command in the -watch section.

Let me know if there's any way I can collect more debugging information that
may be useful.


(Not sure what might be related; here's the versions of a few other packages
that aren't listed explicitly as dependencies. I think all of them have been
updated at least once since the problem started.)
ii  linux-image-amd64   5.10.28-1
amd64Linux for 64-bit PCs (meta-package)
ii  nvidia-kernel-dkms  460.73.01-1
amd64NVIDIA binary kernel module DKMS source
ii  xorg1:7.7+22
amd64X.Org X Window System

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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)

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.60
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-4
ii  libcrypt11:4.4.18-4
ii  libglib2.0-0 2.66.8-1
ii  libgtk2.0-0  2.24.33-1
ii  libpam0g 1.4.0-7
ii  libpango-1.0-0   1.46.2-3
ii  libsystemd0  247.3-5
ii  libx11-6 2:1.7.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.45+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:2.0.6-4
ii  perl  5.32.1-3
ii  wamerican [wordlist]  2019.10.06-1
ii  xfonts-100dpi

Bug#933100: hg-git: autopkgtest needs update for new version of git

Control: found -1 0.8.12-1
Control: severity -1 serious
Control: tags -1 serious

On Fri, Jul 26, 2019 at 08:07:31PM +0200, Paul Gevers wrote:
>...
> /tmp/autopkgtest-lxc.4iq0arlz/downtmp/build.q7v/src/tests/test-illegal-contents.t
> +++
> /tmp/autopkgtest-lxc.4iq0arlz/downtmp/build.q7v/src/tests/test-illegal-contents.t.err
> @@ -48,7 +48,7 @@
>$ git clone hg/.hg/git git
>Cloning into 'git'...
>done.
> -  error: Invalid path 'nested/.git/hooks/post-update'
> +  error: invalid path 'nested/.git/hooks/post-update'
> 
>  Now check something that case-folds to .git, which might let you own
>  Mac users:
> 
> ERROR: test-illegal-contents.t output changed

There is now also a related FTBFS in buster, likely caused by a similar 
change in git 1:2.20.1-2+deb10u1:
https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/hg-git.html

cu
Adrian

Bug#988157: CVE-2021-3527

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

This was assigned CVE-2021-3527:
https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg00564.html

Cheers,
Moritz

Bug#970253: CVE-2020-15469

Am Sun, Sep 13, 2020 at 10:42:36PM +0200 schrieb Moritz Muehlenhoff:
> Package: qemu
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Not fixed upstream yet at this point:
> 
> https://www.openwall.com/lists/oss-security/2020/07/02/1
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg09961.html

Patches:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=520f26fc6d17b71a43eaf620e834b3bdf316f3d3
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4f2a5202a05fc1612954804a2482f07bff105ea2
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=24202d2b561c3b4c48bd28383c8c34b4ac66c2bf
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f867cebaedbc9c43189f102e4cdfdff05e88df7f
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b5bf601f364e1a14ca4c3276f88dfec024acf613
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=921604e175b8ec06c39503310e7b3ec1e3eafe9e
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c9fb3b784000c1df32231e1c2464bb2e3fc4620
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=735754aaa15a6ed46db51fd731e88331c446ea54

Cheers,
 Moritz

Bug#988156: breezy breaks breezy-loom autopkgtest: FAILED (failures=4)

2021-05-06 Thread Paul Gevers

Source: breezy, breezy-loom
Control: found -1 breezy/3.2.0-1
Control: found -1 breezy-loom/3.0.0+bzr167-1
Severity: serious
Tags: sid bullseye bullseye-ignore
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of breezy the autopkgtest of breezy-loom fails in
testing when that autopkgtest is run with the binary packages of breezy
from unstable. It passes when run with only packages from testing. In
tabular form:

passfail
breezy from testing3.2.0-1
breezy-loomfrom testing3.0.0+bzr167-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of breezy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package? Note, because we're in the freeze for
bullseye, we need to take a bit of care. I have marked this bug as
bullseye-ignore because I don't intent this bug to cause the removal of
breezy-loom from bullseye and the autopkgtest failure will keep this
version of breezy out of bullseye automatically.

More information about this bug and the reason for filing it can be found
on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=breezy

https://ci.debian.net/data/autopkgtest/testing/amd64/b/breezy-loom/12136628/log.gz

==
FAIL:
breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
2.916 creating repository in
file:///tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/.bzr/.
2.919 creating branch in
file:///tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/
2.926 trying to create missing lock
'/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/.bzr/checkout/dirstate'
2.926 opening working tree
'/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source'
2.933 opening working tree
'/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source'
2.937 opening working tree
'/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source'
2.945 preparing to commit
INFO Committing to:
/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/
2.948 Selecting files for commit with filter None
INFO Committed revision 1.
2.958 Committed revid b'bottom-1' as revno 1.
2.965 Base revid: b'null:'
INFO All changes applied successfully.
INFO Moved to thread 'top'.
INFO This thread is now empty, you may wish to run "bzr
combine-thread" to remove it.
2.976 preparing to commit
INFO Committing to:
/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/
2.978 Selecting files for commit with filter None
INFO Committed revision 2.
2.988 Committed revid b'top-1' as revno 2.
INFO All changes applied successfully.
INFO Moved to thread 'bottom'.
3.006 preparing to commit
INFO Committing to:
/tmp/testbzr-629rrjpc.tmp/breezy.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_many_commits/work/source/
3.008 Selecting files for commit with filter None
INFO Committed revision 2.
3.017 Committed revid b'bottom-2' as revno 2.
3.028 Base revid: b'bottom-1'
INFO All changes applied successfully.
INFO Moved to thread 'top'.
INFO This thread is now empty, you may wish to run "bzr
combine-thread" to remove it.
}}}

Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/breezy/plugins/loom/tests/test_tree.py",
line 186, in test_up_many_commits
self.assertEqual([b'top-1', b'bottom-2'], rev.parent_ids)
File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line
1307, in assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = [b'top-1', b'bottom-2']
b = [b'bottom-1']

==
FAIL:
breezy.plugins.loom.tests.blackbox.TestDown.test_down_thread_switches_history_ok
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
4.084 creating repository in

Bug#988155: CVE-2021-26291

Package: maven
Version: 3.6.3-3
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-26291
https://www.openwall.com/lists/oss-security/2021/04/23/5
https://issues.apache.org/jira/browse/MNG-7118

Patch:
https://github.com/apache/maven/commit/907d53ad3264718f66ff15e1363d76b07dd0c05f 
(3.8.x)

Cheers,
Moritz

Bug#988154: elixir-lang FTBFS in buster: test failures

Source: elixir-lang
Version: 1.7.4-0.1
Severity: serious
Tags: ftbfs
Control: close -1 1.10.3.dfsg-1.1

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/elixir-lang.html

...
  1) test recompiles modules with async tracking (Mix.Tasks.Compile.ElixirTest)
 test/mix/tasks/compile.elixir_test.exs:310
 Assertion with == failed
 code:  assert Mix.Tasks.Compile.Elixir.run(["--verbose"]) == {:ok, []}
 left:  {:noop, []}
 right: {:ok, []}
 stacktrace:
   test/mix/tasks/compile.elixir_test.exs:334: anonymous fn/0 in 
Mix.Tasks.Compile.ElixirTest."test recompiles modules with async tracking"/1
   (elixir) lib/file.ex:1443: File.cd!/2
   test/test_helper.exs:114: MixTest.Case.in_fixture/3
   test/mix/tasks/compile.elixir_test.exs:311: (test)



  2) test compiles dependent changed modules (Mix.Tasks.Compile.ElixirTest)
 test/mix/tasks/compile.elixir_test.exs:169
 No message matching {:mix_shell, :info, ["Compiled lib/a.ex"]} after 0ms.
 The process mailbox is empty.
 code: in_fixture("no_mixfile", fn ->
 stacktrace:
   test/mix/tasks/compile.elixir_test.exs:184: anonymous fn/0 in 
Mix.Tasks.Compile.ElixirTest."test compiles dependent changed modules"/1
   (elixir) lib/file.ex:1443: File.cd!/2
   test/test_helper.exs:114: MixTest.Case.in_fixture/3
   test/mix/tasks/compile.elixir_test.exs:170: (test)



  3) test does not treat remote typespecs as compile time dependencies 
(Mix.Tasks.Compile.ElixirTest)
 test/mix/tasks/compile.elixir_test.exs:421
 No message matching {:mix_shell, :info, ["Compiled lib/a.ex"]} after 0ms.
 The process mailbox is empty.
 code: in_fixture("no_mixfile", fn ->
 stacktrace:
   test/mix/tasks/compile.elixir_test.exs:440: anonymous fn/0 in 
Mix.Tasks.Compile.ElixirTest."test does not treat remote typespecs as compile 
time dependencies"/1
   (elixir) lib/file.ex:1443: File.cd!/2
   test/test_helper.exs:114: MixTest.Case.in_fixture/3
   test/mix/tasks/compile.elixir_test.exs:422: (test)

.

  4) test compiles mtime changed files (Mix.Tasks.Compile.ElixirTest)
 test/mix/tasks/compile.elixir_test.exs:117
 No message matching {:mix_shell, :error, [^message]} after 0ms.
 The following variables were pinned:
   message = "warning: mtime (modified time) for \"lib/a.ex\" was set to 
the future, resetting to now"
 The process mailbox is empty.
 code: in_fixture("no_mixfile", fn ->
 stacktrace:
   test/mix/tasks/compile.elixir_test.exs:133: anonymous fn/0 in 
Mix.Tasks.Compile.ElixirTest."test compiles mtime changed files"/1
   (elixir) lib/file.ex:1443: File.cd!/2
   test/test_helper.exs:114: MixTest.Case.in_fixture/3
   test/mix/tasks/compile.elixir_test.exs:118: (test)

..

  5) test xrefs if stale (Mix.Tasks.Compile.XrefTest)
 test/mix/tasks/compile.xref_test.exs:27
 Assertion with =~ failed
 code:  assert capture_io(:stderr, fun) =~ "no_func"
 left:  ""
 right: "no_func"
 stacktrace:
   (elixir) lib/file.ex:1443: File.cd!/2
   test/test_helper.exs:114: MixTest.Case.in_fixture/3
   test/mix/tasks/compile.xref_test.exs:28: (test)



Finished in 121.7 seconds (5.1s on load, 116.6s on tests)
8 doctests, 498 tests, 5 failures

Randomized with seed 847741
make[2]: *** [Makefile:102: test_mix] Error 1

Bug#988153: CVE-2020-25715

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

This was assigned CVE-2020-25715:
https://bugzilla.redhat.com/show_bug.cgi?id=1891016

Patch:
https://github.com/dogtagpki/pki/commit/13f4c7fe7d71d42b46b25f3e8472ef7f35da5dd6

Cheers,
Moritz

Bug#988152: CVE-2017-9271

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

CVE-2017-9271:
https://bugzilla.suse.com/show_bug.cgi?id=1050625

Cheers,
Moritz

Bug#973245: openrc: CVE-2018-21269: checkpath root privilege escalation following non-terminal symlinks

Am Sun, Jan 10, 2021 at 12:34:35AM +0100 schrieb Moritz Mühlenhoff:
> Am Tue, Oct 27, 2020 at 08:53:28PM +0100 schrieb Salvatore Bonaccorso:
> > Source: openrc
> > Version: 0.42-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://github.com/OpenRC/openrc/issues/201
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > Control: found -1 0.40.3-1
> > 
> > 
> > CVE-2018-21269[0]:
> > | checkpath in OpenRC through 0.42.1 might allow local users to take
> > | ownership of arbitrary files because a non-terminal path component can
> > | be a symlink.
> 
> This got fixed in
> https://github.com/OpenRC/openrc/commit/b6fef599bf8493480664b766040fa9b0d4b1e335

*ping*, can we get that fixed in bullseye?

Cheers,
Moritz

Bug#988151: CVE-2020-23922

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

CVE-2020-23922:
https://sourceforge.net/p/giflib/bugs/151/

Bug#988150: fail2ban FTBFS in buster: test failures

Source: fail2ban
Version: 0.10.2-2.1
Severity: serious
Tags: ftbfs
Control: close -1 0.11.2-1

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/fail2ban.html

...
==
FAIL: testSampleRegexsVSFTPD (fail2ban.tests.samplestestcase.FilterSamplesRegex)
--
Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 205, in testFilter
"Line not matched when should have")
AssertionError: True is not false : Line not matched when should have

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 250, in testFilter
fltName, e, logFile.filename(), logFile.filelineno(), line))
AssertionError: vsftpd: True is not false : Line not matched when should have 
on: 
/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/files/logs/vsftpd:17,
 line:
Thu Sep  8 00:39:49 2016 [pid 15019] [guest] FAIL LOGIN: Client 
":::192.0.2.1", "User is not in the allow user list."


==
FAIL: testSampleRegexsZONEMINDER 
(fail2ban.tests.samplestestcase.FilterSamplesRegex)
--
Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 205, in testFilter
"Line not matched when should have")
AssertionError: True is not false : Line not matched when should have

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 250, in testFilter
fltName, e, logFile.filename(), logFile.filelineno(), line))
AssertionError: zoneminder: True is not false : Line not matched when should 
have on: 
/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/files/logs/zoneminder:2,
 line:
[Mon Mar 28 16:50:49.522240 2016] [:error] [pid 1795] [client 10.1.1.1:50700] 
WAR [Login denied for user "username1"], referer: https://zoneminder/


==
FAIL: testSampleRegexsZZZ-SSHD-OBSOLETE-MULTILINE 
(fail2ban.tests.samplestestcase.FilterSamplesRegex)
--
Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 205, in testFilter
"Line not matched when should have")
AssertionError: True is not false : Line not matched when should have

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/samplestestcase.py",
 line 250, in testFilter
fltName, e, logFile.filename(), logFile.filelineno(), line))
AssertionError: zzz-sshd-obsolete-multiline: True is not false : Line not 
matched when should have on: 
/build/fail2ban-0.10.2/.pybuild/cpython3_3.7/build/fail2ban/tests/files/logs/sshd:215,
 line:
2015-04-16T18:02:50.321974+00:00 host sshd[2716]: pam_unix(sshd:auth): 
authentication failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=222.186.21.217  user=root


--
Ran 426 tests in 33.705s

FAILED (failures=44, errors=1, skipped=31)
make[1]: *** [debian/rules:55: override_dh_auto_test] Error 1

Bug#968850: software-properties: CVE-2020-15709

Am Sat, Aug 22, 2020 at 01:14:19PM +0200 schrieb Salvatore Bonaccorso:
> Source: software-properties
> Version: 0.96.20.2-2.1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 0.96.20.2-2
> Control: found -1 0.96.20.2-1
> 
> Hi,
> 
> The following vulnerability was published for software-properties.
> 
> CVE-2020-15709[0]:
> | ansi escape sequence injection in add-apt-repository

Can we still get that fixed for bullseye? Or is this really only relevant
for Ubuntu?

Cheers,
Moritz

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

Am Mon, Apr 19, 2021 at 11:42:54AM +0200 schrieb Moritz Muehlenhoff:
> On Sun, Apr 18, 2021 at 07:21:31PM +0200, Tormod Volden wrote:
> > Yes, I think dropping the set_cap is the easy way out of here. sonar
> > will still be visually pleasing, just not so interesting.
> 
> Let's do that for buster/bullseye? And when xscreensaver gets updated to 6.00
> after the release, it can be re-enabled?

*ping* :-)

Cheers,
Moritz

Bug#988149: mozjs60: Missing build dependency on tzdata

Source: mozjs60
Version: 60.2.3-3
Severity: serious
Tags: ftbfs
Control: fixed -1 60.2.3-4

...
## non262/Date/time-zones-posix.js: rc = 3, run time = 0.039505
non262/Date/time-zones-posix.js:83:5 Error: Assertion failed: got "Sun Apr 06 
2003 02:30:00 GMT-0400", expected "Sun Apr 06 2003 03:30:00 GMT-0400"
Stack:
  assertDateTime@non262/Date/time-zones-posix.js:83:5
  @non262/Date/time-zones-posix.js:95:5
  inTimeZone@non262/Date/time-zones-posix.js:63:9
  @non262/Date/time-zones-posix.js:93:1
TEST-UNEXPECTED-FAIL | non262/Date/time-zones-posix.js | (args: "") [0.0 s]
...
## non262/Date/time-zones-pedantic.js: rc = 3, run time = 0.040724
non262/Date/time-zones-pedantic.js:43:5 Error: Assertion failed: got "Sat Mar 
31 1984 23:00:00 GMT+", expected "Sat Mar 31 1984 23:00:00 GMT+0700"
Stack:
  assertDateTime@non262/Date/time-zones-pedantic.js:43:5
  @non262/Date/time-zones-pedantic.js:59:5
  inTimeZone@non262/Date/time-zones-pedantic.js:23:9
  @non262/Date/time-zones-pedantic.js:57:1
TEST-UNEXPECTED-FAIL | non262/Date/time-zones-pedantic.js | (args: "") [0.0 s]
...
## non262/Date/time-zones.js: rc = 3, run time = 0.033559
non262/Date/time-zones.js:41:5 Error: Assertion failed: got "Fri Jul 19 2002 
16:10:55 GMT+", expected "Fri Jul 19 2002 16:10:55 GMT+0100"
Stack:
  assertDateTime@non262/Date/time-zones.js:41:5
  @non262/Date/time-zones.js:57:5
  inTimeZone@non262/Date/time-zones.js:21:9
  @non262/Date/time-zones.js:55:1
TEST-UNEXPECTED-FAIL | non262/Date/time-zones.js | (args: "") [0.0 s]
...
make[3]: *** [Makefile:82: check-jstests] Error 1
make[3]: Leaving directory '/tmp/mozjs60-60.2.3/debian/build/js/src'
make[2]: *** [Makefile:352: check-jstests] Error 2
make[2]: Leaving directory '/tmp/mozjs60-60.2.3/debian/build'
check-jstests failed
make[1]: *** [debian/rules:135: override_dh_auto_test] Error 1
make[1]: Leaving directory '/tmp/mozjs60-60.2.3'
make: *** [debian/rules:68: binary] Error 2

Bug#986917: patch

2021-05-06 Thread Russell Coker

tags 986917 patch
thanks

The following patch makes it stop crashing.  The problem is that the code
treats a file for the ima_measurement command as being valid without any
checks and if the entry.header.pcr is ridiculously large then we access
some random memory.  There are probably several problems with this code and
I'm still not sure what it is supposed to do.  But having it display a
message describing the situation and exit is much better than a SEGV.

This whole thing seems very dubious to me, a file on disk specifying an
entry into an array it should be loaded into in RAM doesn't seem like a good
idea.

--- ima-evm-utils-1.1.orig/src/evmctl.c
+++ ima-evm-utils-1.1/src/evmctl.c
@@ -1471,6 +1471,11 @@ static int ima_measurement(const char *f
init_public_keys(params.keyfile);
 
while (fread(, sizeof(entry.header), 1, fp)) {
+   if(entry.header.pcr >= NUM_PCRS)
+   {
+   log_err("Format error on file %s, wrong 
entry.header.pcr\n", file);
+   goto out;
+   }
ima_extend_pcr(pcr[entry.header.pcr], entry.header.digest,
   SHA_DIGEST_LENGTH);

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#988147: psychopy: unhandled symlink to directory conversion: /usr/share/doc/psychopy/examples

Package: psychopy
Version: 2020.2.10+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster (which had no psychopy package, thus keeping the
 stretch version installed) -> bullseye

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

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

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


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

2m50.7s ERROR: installs objects over existing directory symlinks:
  /usr/share/doc/psychopy/examples/color_changer.py (psychopy) != 
/usr/lib/python2.7/dist-packages/psychopy/demos/color_changer.py (?)
/usr/share/doc/psychopy/examples -> 
../../../lib/python2.7/dist-packages/psychopy/demos
  /usr/share/doc/psychopy/examples/demos (psychopy) != 
/usr/lib/python2.7/dist-packages/psychopy/demos/demos (?)
/usr/share/doc/psychopy/examples -> 
../../../lib/python2.7/dist-packages/psychopy/demos
  /usr/share/doc/psychopy/examples/psychopy_helloworld.py (psychopy) != 
/usr/lib/python2.7/dist-packages/psychopy/demos/psychopy_helloworld.py (?)
/usr/share/doc/psychopy/examples -> 
../../../lib/python2.7/dist-packages/psychopy/demos
  /usr/share/doc/psychopy/examples/run_coder.py (psychopy) != 
/usr/lib/python2.7/dist-packages/psychopy/demos/run_coder.py (?)
/usr/share/doc/psychopy/examples -> 
../../../lib/python2.7/dist-packages/psychopy/demos


cheers,

Andreas


psychopy_2020.2.10+dfsg-1.log.gz
Description: application/gzip

Bug#887139: installation-reports: Debian Installer Bullseye RC 1 damages UEFI setup on Dell Latitude 5510

2021-05-06 Thread Thaddeus H. Black

Package: installation-reports
Followup-For: Bug #887139

Dear Maintainer,

Paul Gevers has asked subscribers to debian-devel-announce to try out
the debian-installer, so I tried it.

-- Package-specific info:

Boot method: netinst.iso on a USB flash drive
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc1/amd64/iso-cd/debian-bullseye-DI-rc1-amd64-netinst.iso
 as downloaded 2021-05-06 14:00 UTC
Date: 2021-05-06 14:30 UTC

Machine: Dell Latitude 5510 laptop, Intel Comet Lake i7-10610U CPU with 
associated Intel chipset, Intel Wifi, Intel integrated graphics

Partitions: the command "df -Tl" reports the following while *buster* is
running.  Is this information useful, though?  I include it only because
installation-report specifically requests it.
Filesystem  Type  1K-blocks  Used Available Use% Mounted on
udevdevtmpfs   16223268 0  16223268   0% /dev
tmpfs   tmpfs   3247352  9972   3237380   1% /run
/dev/nvme0n1p9  ext4  263174212  17009396 232726660   7% /
tmpfs   tmpfs  16236752 69528  16167224   1% /dev/shm
tmpfs   tmpfs  5120 4  5116   1% /run/lock
tmpfs   tmpfs  16236752 0  16236752   0% /sys/fs/cgroup
/dev/nvme0n1p11 ext4 1254007444 451985672 738251968  38% /arc
/dev/nvme0n1p1  vfat 50790411397904  22% /boot/efi
tmpfs   tmpfs   3247348 12756   3234592   1% /run/user/1000
/dev/sda1   iso9660  369664369664 0 100% /media/thb/Debian 
bullseye-DI-rc1 amd64 n

Partitions: the command "fdisk -l" reports the following. This may be
more informative than the above.  Buster is installed on p9; bullseye,
on p12.
Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: INTEL SSDPEKNW020T9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E40D7C7A-2099-49F3-808B-FB583DFE4C6C
Device   StartEndSectors   Size Type
/dev/nvme0n1p1204810260471024000   500M EFI System
/dev/nvme0n1p2 10260481288191 262144   128M Microsoft reserved
/dev/nvme0n1p3 1288192  774707199  773419008 368.8G Microsoft basic data
/dev/nvme0n1p4  3995934720 39979622392027520   990M Windows recovery 
environment
/dev/nvme0n1p5  3997962240 40007598072797568   1.3G Windows recovery 
environment
/dev/nvme0n1p6   774709245  774709245  1   512B Microsoft basic data
/dev/nvme0n1p7   774709246  774709246  1   512B Microsoft basic data
/dev/nvme0n1p8   774709247  774709247  1   512B Microsoft basic data
/dev/nvme0n1p9   774709248 1311580159  536870912   256G Linux filesystem
/dev/nvme0n1p10 1311580160 1378689023   6710886432G Linux swap
/dev/nvme0n1p11 1378689024 3928825855 2550136832   1.2T Linux filesystem
/dev/nvme0n1p12 3928825856 3995934719   6710886432G Linux filesystem

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [ ]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

The installation went as expected.  Unfortunately, after installation,

* bullseye testing (newly installed) booted normally but
* buster stable (already installed) booted abnormally.

Installation of bullseye on one partition disrupts buster on another
partition.  Insofar as bullseye's installer was not asked by me to touch
buster's partition, I assume that the problem is a UEFI problem.
It may be that bullseye's installer damages UEFI.

Buster still boots, but takes two or three minutes instead of the
usual 20 seconds or so.  Buster's boot stalled so long, I had time to
write down the messages that appeared live on the screen during the
stall (though I cannot promise that I have precisely copied all the
hexidecimal numbers and such):
fsckd-cancel-msg:Press Ctrl-C to cancel all filesystem checks in progress
[35.99] ioremap-errorr for 0x7698-0x76981000, requested 0x2, got 0x0
[some messages about iwlwifi]
[some messages about Plymouth]
[37.99] tpm tpm0: tpm_try_transmit send(): error -62
[37.99] tpm tpm0: [Firmware bug]: TPM interrupt not working, polling instead
[   ***   ] A start job is running for 
/dev/disk/by-uuid/ef70f152-a70a-4d70-8402-a3e2a0c6db90 (59s / 1min 30s)

To emphasize, the above messages appear during a stall when *buster*
boots after *bullseye* is installed.  There is no stall when bullseye
boots.

-- 

The following were generated while buster was running, not bullseye.

==
Installer

Bug#988148: initscripts: Can not umount /usr at shutdown

2021-05-06 Thread Hans-J. Ullrich

Package: initscripts
Version: 2.96-7
Severity: normal

Dear Maintainer,

I du not know, if thisis really a bug. However, when shutting system down, it 
hangs some time with the message "can not unmount /usr" and then after a while 
it shuts off.


A look at /etc/init.d/umountfs told me, that many devices are listed to be 
unmounted and also /usr. But, as I am using cryptdisks, my devices are called 
/dev/mapper/usr. Examination of the file is missing an entry "/dev/mapper/*" 
and so of course, every shutdown is waiting for a timeout and is producing the 
error message.

It is IMO a minor problem, does not much harm, but I would like to mention it. 

Please feel free, in case I am wrong, to close this case.

Thank you very much for reading this.

Best regards

Hans



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

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

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-7

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.2-1
ii  psmisc 23.4-2

initscripts suggests no packages.

-- Configuration Files:
/etc/rc.local changed:
setkeycodese055 235 # WLAN
setkeycodese056 236 # WLAN
setkeycodese004 129 # Bluetooth
setkeycodese012 208 # ACER Arcade
setkeycodese033 200 # '\xa4' character
setkeycodese034 201 # '$' character
exit 0


-- debconf-show failed

Bug#987985: Bug in Redis-server Package

2021-05-06 Thread Chris Lamb

Hi Benjamin,

> I think the actually version is 5.0.3-4+deb10u3!? I had this error with
> Debian Buster some Days ago.

You're absolutely right: I was testing this on stretch (not buster) by
mistake -- my apologies.  However, I still get the same "ERR syntax
error" when I run:

 $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "1" EX 
15
 $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "2" 
KEEPTTL

... on both 5:5.0.3-4+deb10u2 and 5:5.0.3-4+deb10u3.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

2021-05-06 Thread Pirate Praveen




On 2021, മേയ് 6 9:47:21 PM IST, Maximilian Stein  wrote:
>Hi,
>
>> You should be installing gitlab 13.11.2. You need to add contrib section to 
>> people.debian.org/~praveen/gitaly. This is mentioned in 
>> https://wiki.debian.org/gitlab/#New_changes
>>
>> All dependencies are compatible with this version.
>>
>Thanks for the hint, I hadn't gotton this.
>
>However, this actually doesn't not fully solves the basic problem: 
>Basically, I am forced to always update to the newest gitlab version as 
>fast as possible or otherwise risking that updates of a dependency 
>package breaks my installation. So, actually, the problems boils down 
>to: The Gitlab dependencies are tighter in the Gemfile than in the 
>package. That's why dependency packages are upgraded although they break 
>another package which is not upgraded.
>
>
>What about generating the required dependencies from the Gemfile? 
>Basically that is what I am doing manually: The ruby package "example" 
>is found in the Debian package "ruby-example" and then I only need to 
>get the version right.

We cannot support more than one version of gitlab at any time. Gitlab by nature 
has fast releases and only way to keep up is keep updating gitlab. Only if 
upstream provides a long term supported version, we can support a gitlab 
version for longer than a month. Currently our goal is to go along with the 
upstream releases.

If there are more volunteers we can probably extend it up to 3 months. Even 
more resources will be required if we want to provide support for more than 
that.

>Best,
>Maximilian
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#987985: Bug in Redis-server Package

2021-05-06 Thread Benjamin Kuhl

I think the actually version is 5.0.3-4+deb10u3!? I had this error with 
Debian Buster some Days ago.


Am 06.05.21 um 13:50 schrieb Chris Lamb:

Hi Benjamin,


At an earlier point im setting the kay-value like this,

      const ok = await RedisServer.setValue(ip, '1', 'EX', 15);

Where the variable ip is something like

"2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15"

This seems to work, but i only get the error when im changing the
key-value as i wrote. When im trying to access the entry and change the
number '1' to '2' and set 'KEEPTTL'.

So, to confirm, you are running the equivalent of:

  $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "1" EX 
15
  $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "2" 
KEEPTTL

... with the second command failing? If so, although I can reproduce
this error using 3:3.2.6-3+deb9u4, I can _also_ reproduce it using
deb9u3. Again, just trying to track down the regression...


Regards,

--
   ,''`.
  : :'  : Chris Lamb
  `. `'`  la...@debian.org  chris-lamb.co.uk
`-

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

2021-05-06 Thread Maximilian Stein


Hi,


You should be installing gitlab 13.11.2. You need to add contrib section to 
people.debian.org/~praveen/gitaly. This is mentioned in 
https://wiki.debian.org/gitlab/#New_changes

All dependencies are compatible with this version.


Thanks for the hint, I hadn't gotton this.

However, this actually doesn't not fully solves the basic problem: 
Basically, I am forced to always update to the newest gitlab version as 
fast as possible or otherwise risking that updates of a dependency 
package breaks my installation. So, actually, the problems boils down 
to: The Gitlab dependencies are tighter in the Gemfile than in the 
package. That's why dependency packages are upgraded although they break 
another package which is not upgraded.



What about generating the required dependencies from the Gemfile? 
Basically that is what I am doing manually: The ruby package "example" 
is found in the Debian package "ruby-example" and then I only need to 
get the version right.


Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#969279: mutt - could not create tempory files

2021-05-06 Thread Hans

Dear maintainers,

this issue exists still (or again?) in the latest version of debian-amd64/
testing. In debian-i386/testing mutt is working fine.

Best regards

Hans

Bug#988146: parted: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?)

Package: parted
Version: 3.4-1
Severity: important
X-Debbugs-Cc: freedombox-disc...@alioth-lists.debian.net

I first noticed this when trying to make an improvement to
freedom-maker, hence FB-discuss in CC, while this issue didn't present
itself with the Raspberry Pi image specs project.
The former uses 'mib', while the latter uses '%'.

To demonstrate it, I created a script to prove the issue:
==
#!/bin/sh
BUILD_DIR="temp"
IMAGE_NAME="parted-test.img"
IMAGE_PATH="$BUILD_DIR/$IMAGE_NAME"
IMAGE_SIZE="100M"

echo "BUILD_DIR: $BUILD_DIR"
echo "IMAGE_NAME: $IMAGE_NAME"
echo "IMAGE_PATH: $IMAGE_PATH"
echo "IMAGE_SIZE: $IMAGE_SIZE"

if [ ! -d "$BUILD_DIR" ] ; then
echo "directory $BUILD_DIR doesn't exist; create it"
mkdir $BUILD_DIR
fi

echo "Creating image at '$IMAGE_PATH' of size '$IMAGE_SIZE'"
qemu-img create -f raw "$IMAGE_PATH" "$IMAGE_SIZE"
echo "Image file created"

echo -n "Creating partition table ... "
/sbin/parted -s $IMAGE_PATH mklabel msdos
echo "Done"

echo -n "Creating 1st partition ('4mib' '20%') ... "
/sbin/parted -s $IMAGE_PATH mkpart primary fat32 '4mib' '20%'
echo "Done"

echo -n "Creating 2nd partition ('20%' '40%' ... "
/sbin/parted -s $IMAGE_PATH mkpart primary ext4 '20%' '40%'
echo "Done"

echo -n "Creating 3rd partition ('40mib' '60mib') ... "
/sbin/parted -s $IMAGE_PATH mkpart primary ext4 '40mib' '60mib'
echo "Done"

echo ""
echo "Showing partition layout"
/sbin/fdisk -l $IMAGE_PATH

echo ""

echo -n "Creating 4th partition ('60mib' '100%' ... "
/sbin/parted -s $IMAGE_PATH mkpart primary ext4 '60mib' '100%'
echo "Done"

==

And when I run that, I get this output:
==
diederik@bagend:~/tmp/parted$ ./parted-bug-test.sh
BUILD_DIR: temp
IMAGE_NAME: parted-test.img
IMAGE_PATH: temp/parted-test.img
IMAGE_SIZE: 100M
directory temp doesn't exist; create it
Creating image at 'temp/parted-test.img' of size '100M'
Formatting 'temp/parted-test.img', fmt=raw size=104857600
Image file created
Creating partition table ... Done
Creating 1st partition ('4mib' '20%') ... Done
Creating 2nd partition ('20%' '40%' ... Done
Creating 3rd partition ('40mib' '60mib') ... Done

Showing partition layout
Disk temp/parted-test.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x98f2bc17

DeviceBoot StartEnd Sectors Size Id Type
temp/parted-test.img1   8192  40959   32768  16M  c W95 FAT32 (LBA)
temp/parted-test.img2  40960  81919   40960  20M 83 Linux
temp/parted-test.img3  81920 122880   40961  20M 83 Linux

Creating 4th partition ('60mib' '100%' ... Error: You requested a partition 
from 62.9MB to 105MB (sectors 122880..204799).
The closest location we can manage is 62.9MB to 105MB (sectors 122881..204799).
Done
==

As the image size is (deliberately) 100M, one can swap the 'mib' and '%'
values. While it should produce the same output, it does not.

I (strongly) believe that with 'mib' the partition is created 1 sector
too large, hence the off-by-one in the subject.
Consequently, when the 'end' parameter is defined in 'mib' and then try
to create a new partition that starts at the previous end value, the
partition creation fails.


It looks like bug #902224 is related to it and possible also #835172.


Cheers,
  Diederik

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

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

Versions of packages parted depends on:
ii  libc6 2.31-12
ii  libparted23.4-1
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2

parted recommends no packages.

Versions of packages parted suggests:
ii  parted-doc  3.4-1

-- no debconf information

Bug#988145: libmail-dkim-perl in buster accesses the internet during the build

Source: libmail-dkim-perl
Version: 0.54-1
Severity: serious
Tags: ftbfs
Control: fixed -1 1.20200513.1-1

libmail-dkim-perl (1.20200513.1-1) unstable; urgency=medium
...
  * Turn off DNS queries during package build to comply with Debian policy.

 -- gregor herrmann   Fri, 15 May 2020 23:20:15 +0200


This also causes a FTBFS now.

Bug#988144: google-auth-java: misses two version numbers in the pom of oauth2_http

2021-05-06 Thread Pierre Gruet

Source: google-auth-java
Version: 0.18.0-1
Severity: normal
Tags: patch upstream

The sub-POM file oauth2_http/pom.xml has no version number for the dependencies
google-http-client and google-http-client-jackson2. It probably should be 
defined in the parent POM.
For that reason, projects depending on the oauth2-http artifact fail to resolve 
the version numbers of those two dependencies.

The attached patch, also committed to the VCS, solves the issue.

Best,
Pierre
diff -Nru google-auth-java-0.18.0/debian/changelog 
google-auth-java-0.18.0/debian/changelog
--- google-auth-java-0.18.0/debian/changelog2020-12-23 22:03:21.0 
+0100
+++ google-auth-java-0.18.0/debian/changelog2021-05-06 15:49:25.0 
+0200
@@ -1,3 +1,10 @@
+google-auth-java (0.18.0-2) UNRELEASED; urgency=medium
+
+  * Team upload
+  * Adding missing version number of two dependencies in the pom of oauth2_http
+
+ -- Pierre Gruet   Thu, 06 May 2021 15:49:25 +0200
+
 google-auth-java (0.18.0-1) unstable; urgency=high
 
   * New upstream release
diff -Nru 
google-auth-java-0.18.0/debian/patches/adding_version_of_http_client_for_oauth2.patch
 
google-auth-java-0.18.0/debian/patches/adding_version_of_http_client_for_oauth2.patch
--- 
google-auth-java-0.18.0/debian/patches/adding_version_of_http_client_for_oauth2.patch
   1970-01-01 01:00:00.0 +0100
+++ 
google-auth-java-0.18.0/debian/patches/adding_version_of_http_client_for_oauth2.patch
   2021-05-06 15:49:25.0 +0200
@@ -0,0 +1,27 @@
+Description: adding version information for two oauth2 dependencies
+ The dependencies google-http-client and google-http-client-jackson2 of
+ oauth2_http have no version number in the pom. I add them as dependencies in
+ the parent pom so that their version number is inherited.
+Author: Pierre Gruet 
+Forwarded: no
+Last-Update: 2021-05-06
+
+--- a/pom.xml
 b/pom.xml
+@@ -121,6 +121,16 @@
+ ${project.version}
+ test-jar
+   
++  
++  com.google.http-client
++  google-http-client
++  ${project.google.http.version}
++
++
++  com.google.http-client
++  google-http-client-jackson2
++  ${project.google.http.version}
++
+ 
+   
+ 
diff -Nru google-auth-java-0.18.0/debian/patches/series 
google-auth-java-0.18.0/debian/patches/series
--- google-auth-java-0.18.0/debian/patches/series   2020-12-23 
22:03:21.0 +0100
+++ google-auth-java-0.18.0/debian/patches/series   2021-05-06 
15:49:25.0 +0200
@@ -1,3 +1,4 @@
 verbose-build.patch
 no-appengine.patch
 use-default-debian-versions.patch
+adding_version_of_http_client_for_oauth2.patch

Bug#988143: ITP: wireplumber -- Session / policy manager for PipeWire

2021-05-06 Thread Arnaud Ferraris

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-de...@lists.debian.org, arnaud.ferra...@collabora.com

* Package name: wireplumber
  Version : 0.3.0
  Upstream Author : Collabora Ltd
* URL : https://gitlab.freedesktop.org/pipewire/wireplumber
* License : MIT
  Programming Lang: C, Lua
  Description : Session / policy manager for PipeWire

WirePlumber is a session / policy manager for PipeWire. It follows a
modular design, having plugins that implement the actual management
functionality.

WirePlumber also provides a high-level library wrapping the PipeWire
API that allows you to extend the WirePlumber daemon, to write
management or status tools for PipeWire (apps that don't do actual
media streaming) and to write custom session managers for embedded
devices.

I plan to maintain this package as part of the Utopia team.

Bug#988142: pandas FTBFS in buster: test failures

Source: pandas
Version: 0.23.3+dfsg-3
Severity: serious
Tags: ftbfs
Control: tags -1 fixed 0.23.3+dfsg-4

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/pandas.html

...
=== FAILURES ===
_ TestDatetime64.test_datetime_name_accessors[dsb_DE] __

self = 
time_locale = 'dsb_DE'

@pytest.mark.parametrize('time_locale', [
None] if tm.get_locales() is None else [None] + tm.get_locales())
def test_datetime_name_accessors(self, time_locale):
# Test Monday -> Sunday and January -> December, in that sequence
if time_locale is None:
# If the time_locale is None, day-name and month_name should
# return the english attributes
expected_days = ['Monday', 'Tuesday', 'Wednesday', 'Thursday',
 'Friday', 'Saturday', 'Sunday']
expected_months = ['January', 'February', 'March', 'April', 'May',
   'June', 'July', 'August', 'September',
   'October', 'November', 'December']
else:
with tm.set_locale(time_locale, locale.LC_TIME):
expected_days = calendar.day_name[:]
expected_months = calendar.month_name[1:]

# GH 11128
dti = DatetimeIndex(freq='D', start=datetime(1998, 1, 1),
periods=365)
english_days = ['Monday', 'Tuesday', 'Wednesday', 'Thursday',
'Friday', 'Saturday', 'Sunday']
for day, name, eng_name in zip(range(4, 11),
   expected_days,
   english_days):
name = name.capitalize()
assert dti.weekday_name[day] == eng_name
>   assert dti.day_name(locale=time_locale)[day] == name

../debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/indexes/datetimes/test_misc.py:272:
 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../debian/tmp/usr/lib/python2.7/dist-packages/pandas/core/indexes/datetimes.py:2553:
 in day_name
locale=locale)
pandas/_libs/tslibs/fields.pyx:107: in 
pandas._libs.tslibs.fields.get_date_name_field
???
pandas/_libs/tslibs/ccalendar.pyx:213: in 
pandas._libs.tslibs.ccalendar.get_locale_names
???
pandas/_libs/tslibs/ccalendar.pyx:229: in 
pandas._libs.tslibs.ccalendar.get_locale_names
???
pandas/_libs/tslibs/ccalendar.pyx:230: in 
pandas._libs.tslibs.ccalendar.get_locale_names
???
pandas/_libs/tslibs/strptime.pyx:396: in 
pandas._libs.tslibs.strptime.LocaleTime.__init__
???
pandas/_libs/tslibs/strptime.pyx:354: in pandas._libs.tslibs.strptime._getlang
???
/usr/lib/python2.7/locale.py:564: in getlocale
return _parse_localename(localename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

localename = 'dsb_DE'

def _parse_localename(localename):

""" Parses the locale code for localename and returns the
result as tuple (language code, encoding).

The localename is normalized and passed through the locale
alias engine. A ValueError is raised in case the locale name
cannot be parsed.

The language code corresponds to RFC 1766.  code and encoding
can be None in case the values cannot be determined or are
unknown to this implementation.

"""
code = normalize(localename)
if '@' in code:
# Deal with locale modifiers
code, modifier = code.split('@', 1)
if modifier == 'euro' and '.' not in code:
# Assume Latin-9 for @euro locales. This is bogus,
# since some systems may use other encodings for these
# locales. Also, we ignore other modifiers.
return code, 'iso-8859-15'

if '.' in code:
return tuple(code.split('.')[:2])
elif code == 'C':
return None, None
>   raise ValueError, 'unknown locale: %s' % localename
E   ValueError: unknown locale: dsb_DE

/usr/lib/python2.7/locale.py:477: ValueError
_ TestDatetime64.test_datetime_name_accessors[sah_RU] __

self = 
time_locale = 'sah_RU'

@pytest.mark.parametrize('time_locale', [
None] if tm.get_locales() is None else [None] + tm.get_locales())
def test_datetime_name_accessors(self, time_locale):
# Test Monday -> Sunday and January -> December, in that sequence
if time_locale is None:
# If the time_locale is None, day-name and month_name should
# return the english attributes
expected_days = ['Monday', 'Tuesday', 'Wednesday', 'Thursday',
 'Friday', 'Saturday', 'Sunday']
expected_months = ['January', 'February', 'March', 'April', 'May',

Bug#988141: impacket: CVE-2021-31800

2021-05-06 Thread Salvatore Bonaccorso

Source: impacket
Version: 0.9.22-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for impacket.

CVE-2021-31800[0]:
| Multiple path traversal vulnerabilities exist in smbserver.py in
| Impacket through 0.9.22. An attacker that connects to a running
| smbserver instance can list and write to arbitrary files via ../
| directory traversal. This could potentially be abused to achieve
| arbitrary code execution by replacing /etc/shadow or an SSH authorized
| key.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-31800
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31800
[1] 
https://github.com/SecureAuthCorp/impacket/commit/49c643bf66620646884ed141c94e5fdd85bcdd2f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#935591: opusfile 0.12

2021-05-06 Thread Amr Ibrahim


On 06/05/2021 14:58, IOhannes m zmölnig (Debian/GNU) wrote:

what makes you think so?
have you contacted them?


No, I haven't contacted them directly, but because of these reasons:

 * I sent this request one year ago to update opusfile, without an answer
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935591#10
 * I sent this request one year ago to update opus-tools, without an answer
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910261#10
 * I sent this request one year ago to update Speex and SpeexDSP,
   without an answer
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949717
 * A request 10 months ago to update xf86-input-wacom, without an answer
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964106
 * opus had to be NMUed to 1.3.1-0.1
   
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934809
 * libogg had to be NMUed to 1.3.4-0.1
   
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894158
 * All these issues (filed 10 months ago) will block the removal of
   debhelper compat 5 and 6 in bookworm, all without answers:
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965759
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965762
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965897
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965827
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965733
 o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965673

And in general the maintainer did not touch their packages in ~3 years.

That's why I concluded that the maintainer could have lost interest in 
maintaining their packages.

Bug#988140: Probably broken code example in installation-guide Appendix B.5 (Running custom commands)

2021-05-06 Thread Boyuan Yang

Source: installation-guide
Severity: normal
X-Debbugs-CC: sthiba...@debian.org

I received a user report that
https://www.debian.org/releases/bullseye/amd64/apbs05.en.html#preseed-hooks
provides an incorrect code example:

# This command is run immediately before the partitioner starts. It may be
# useful to apply dynamic partitioner preseeding that depends on the state
# of the disks (which may not be visible when preseed/early_command runs).
#d-i partman/early_command \
#   string debconf-set partman-auto/disk "$(list-devices disk | head -n1)"

The reporter claims that the $ sign should be escaped, like:

#d-i partman/early_command \
#string debconf-set partman-auto/disk "\$(list-devices disk | head -n1)"

Since I am not familiar with d-i and preseed at all, please verify whether
this makes sense. If this is a problem, it exists in the installation-guide of
both Debian Buster and Debian Bullseye. If it's not, please feel free to close
this bug report.

-- 
Thanks,
Boyuan Yang


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

Bug#987332: aprx automatically starts up with really bad default config

2021-05-06 Thread Apostolos Kefalas

Hello Hibby,

Please review the below patch


--- a/config.c
+++ b/config.c
@@ -340,6 +340,9 @@
config_STRUPPER(param1);
// Store these always, it helps with latter error diagnostics
mycall   = strdup(param1);
+   if (strcmp(mycall, "N0CALL-1") == 0) {
+   return 1;
+   }
 #ifndef DISABLE_IGATE
aprsis_login = mycall;
 #endif


thanks
Apostolos




On Wed, 2021-05-05 at 23:06 +0100, Hibby wrote:
> Hi all,
> 
> I had a quick look at the code - config.c carries a validate_callsign_input()
> function, which I think we could patch a check in to cause the program to exit
> with an incorrect callsign for APRS-IS error.
> 
> Alternatively, it’s checking for a 6 character callsign, so we could make
> N0CALL-1  longer by a character or two in the config to force an error.
> 
> Do either of these seem like a reasonable way to force an error, or will this
> just end up with the failed upgrades we want to avoid?
> 
> —
> Hibby
> MM0RFN

Bug#988131: falkon does not gain focus when called from external applications

2021-05-06 Thread Ritesh Raj Sarraf

On Thu, 2021-05-06 at 18:44 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2021-05-06 at 13:34 +0200, Georges Khaznadar wrote:
> > Dear Ritesh,
> > 
> > I tried to reproduce the bug you are describing, without success.
> > 
> > My attempt to reproduce the bug was:
> > 
> > - From a terminal, I type "falkon", then Enter key
> > - Falkon is launched and it gets the focus.
> > 
> > My desktop software is currently LXDE, version 10; the terminal is
> > gnome-terminal. When I do the same with x-www-browser, Falkon's
> > window
> > gets the focus too.
> 
> 
> Let me outline the steps
> 
> 1. Open Falkon main browser
> 2. Now open terminal
> 3. Run x-www-browser (falkon) www.debian.org
> 
> Expected behavior should be that Falkon will get focus and open the
> browser for you.

I made a video trying to visualize the problem I'm running into.

https://youtu.be/k1ijRR_7UmE

Hope you are okay with accessing it on YouTube. If not, please let
know. I'll make alternate arrangements.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

2021-05-06 Thread Benjamin Drung

Am Mittwoch, den 05.05.2021, 20:46 +0200 schrieb Jonas Smedegaard:
> Quoting Johannes Schauer Marin Rodrigues (2021-05-05 19:37:16)
> 
> > The patch should probably look something like this:
> > 
> > @@ -5461,10 +5461,8 @@ sub main() {
> >  '-c',
> >  '--exclude=./dev'
> >  );
> > -    # tar2sqfs and genext2fs do not support extended attributes
> > -    if ($format eq "squashfs") {
> > -    warning "tar2sqfs does not support extended attributes";
> > -    } elsif ($format eq "ext2") {
> > +    # genext2fs does not support extended attributes
> > +    if ($format eq "ext2") {
> >  warning "genext2fs does not support extended attributes";
> >  } else {
> >  push @taropts, '--xattrs';
> 
> @Benjamin: Will you have the honour?  You seem more expert in using 
> mmdebstrap and therefore more likely to catch flaws in this than
> me...

Uploaded as mmdebstrap 0.7.5-2.1 and pushed changes to salsa. The patch
can be directly applied with "git am" on the upstream project as well.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie
bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu
verwenden.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.



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

Bug#935591: opusfile 0.12

2021-05-06 Thread Debian/GNU


On 5/6/21 10:39, Amr Ibrahim wrote:
[...] as their current maintainer probably lost interest in 
the packages.


what makes you think so?
have you contacted them?


gfds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#988131: falkon does not gain focus when called from external applications

2021-05-06 Thread Ritesh Raj Sarraf

Hello Georges,


Thank you for the prompt response.

On Thu, 2021-05-06 at 13:34 +0200, Georges Khaznadar wrote:
> Dear Ritesh,
> 
> I tried to reproduce the bug you are describing, without success.
> 
> My attempt to reproduce the bug was:
> 
> - From a terminal, I type "falkon", then Enter key
> - Falkon is launched and it gets the focus.
> 
> My desktop software is currently LXDE, version 10; the terminal is
> gnome-terminal. When I do the same with x-www-browser, Falkon's
> window
> gets the focus too.


Let me outline the steps

1. Open Falkon main browser
2. Now open terminal
3. Run x-www-browser (falkon) www.debian.org

Expected behavior should be that Falkon will get focus and open the
browser for you.

> 
> Which desktop manager are you using?

I'm on KDE 5.81.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#988132: systemd-resolved stub resolver does not pass RRSIG data for applications to answer DNSSEC queries

2021-05-06 Thread Philip Stewart


Hi Michael,

Thanks for the quick reply!
On Thu, 6 May, 2021 at 12:46, Michael Biebl  wrote:


This would need convincing of the stable release managers, who 
usually prefer targetted, small fixes for stable uploads. I'm a bit 
skeptical that this one would qualify.


We do offer newer releases via stable backports though. So if this is 
an issue which concerns you, you will be able to get v248 (and later) 
via bullseye-backports.


Hopefully, this is an acceptable compromise for you.


I share your scepticism and indeed considered whether to file the 
report, or wait for the backport. I'm happy to pick up the backport but 
thought it worth highlighting at least.


All the best,
Phil

Bug#987398: network-manager: Network Manager doesn't see WiFi networks after boot


Am 06.05.2021 um 14:59 schrieb Michael Biebl:

Am 06.05.2021 um 13:28 schrieb Russell Stuart:

Spoke too soon.

The theory is wpa-supplicant didn't initial properly?  I've attached a
complete journal from boot, so you can see what wpa-supplicant says.

Same issue: NetworkManager sees no networks, "iw scan" sees networks,
after "systemctl stop NetworkManager; systemctl start NetworkManager" it
sees networks.


Can you run
"systemctl status wpa_supplicant.service" after stopping NetworkManager?
Maybe enable debug logging in both wpasupplicant and NetworkManager
https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_WiFi_Connections 



upstream also recommended to get a TRACE log:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/9eac9c846c6bb7b0baa77b72638aaf79df4a5ca6/contrib/fedora/rpm/NetworkManager.conf#L29

Bug#987398: network-manager: Network Manager doesn't see WiFi networks after boot


Am 06.05.2021 um 13:28 schrieb Russell Stuart:

Spoke too soon.

The theory is wpa-supplicant didn't initial properly?  I've attached a
complete journal from boot, so you can see what wpa-supplicant says.

Same issue: NetworkManager sees no networks, "iw scan" sees networks,
after "systemctl stop NetworkManager; systemctl start NetworkManager" it
sees networks.


Can you run
"systemctl status wpa_supplicant.service" after stopping NetworkManager?
Maybe enable debug logging in both wpasupplicant and NetworkManager
https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_WiFi_Connections

Bug#988139: khal fails to run with ModuleNotFoundError: No module named 'xdg.BaseDirectory' error

2021-05-06 Thread Filippo Rusconi

Package: khal
Version: 1:0.10.2-0.2
Severity: grave

Greetings,

this is the full error report:

Traceback (most recent call last):
  File "/usr/bin/khal", line 33, in 
sys.exit(load_entry_point('khal==0.10.2', 'console_scripts', 'khal')())
  File "/usr/bin/khal", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/khal/cli.py", line 35, in 
from .settings import InvalidSettingsError, get_config
  File "/usr/lib/python3/dist-packages/khal/settings/__init__.py", line 1, in 

from .settings import get_config  # noqa
  File "/usr/lib/python3/dist-packages/khal/settings/settings.py", line 26, in 

import xdg.BaseDirectory
ModuleNotFoundError: No module named 'xdg.BaseDirectory'

I have apt-file searched the BaseDirectory file and found that one dependency
could be python3-xdg, which was installed already on my system.

Thank you for your kind attention,

Filippo


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

Kernel: Linux 5.10.0-6-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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages khal depends on:
ii  python33.9.2-2
ii  python3-atomicwrites   1.4.0-2
ii  python3-click  7.1.2-1
ii  python3-click-log  0.2.1-2
ii  python3-configobj  5.0.6-4
ii  python3-dateutil   2.8.1-5
ii  python3-icalendar  4.0.3-4
ii  python3-pkg-resources  52.0.0-3
ii  python3-tz 2021.1-1
ii  python3-tzlocal2.1-1
ii  python3-urwid  2.1.2-1
ii  python3-xdg0.27-2

Versions of packages khal recommends:
ii  python3-setproctitle  1.2.1-1+b1

Versions of packages khal suggests:
pn  khal-doc  

-- no debconf information

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#868240: isc-dhcp-server refuses to start if pidfile is present even when dhcpd is not running

2021-05-06 Thread Nuno Oliveira


Hi,

I have a setup with 2 redundant (primary / secondary) DHCPd servers 
where both of them crash occasionally. This is a separate bug, but this 
solution was useful in restarting the daemons after crashing and leaving 
the pid files behind.


To automatically restart the daemons after this modification is 
introduced, edit the systemd service description with


systemctl edit isc-dhcp-server.service

and add something like

[Service]
Type=forking
PIDFile=dhcpd.pid
Restart=on-failure
StartLimitIntervalSec=60s
StartLimitBurst=8
RestartSec=5s

in the appropriate section. Then enable this configuration, and systemd 
will be able to restart DHCPd after they crash.

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

2021-05-06 Thread Steve McIntyre

On Thu, May 06, 2021 at 03:49:39PM +0300, Andrei POPESCU wrote:
>On Mi, 05 mai 21, 01:21:24, Steve McIntyre wrote:
>> On Tue, May 04, 2021 at 08:29:03AM +0300, Andrei POPESCU wrote:
>> >On Lu, 03 mai 21, 19:52:32, Steve McIntyre wrote:
>> >> 
>> >> Reassigning to debian-installer, as that builds the mini.iso.
>> >> 
>> >> I'll take a look when I get a chance...
>> >> 
>> >> Oh, hmmm - do you have secure boot enabled or not on your machine?
>> >
>> >It's not enabled (sorry, forgot to mention).
>> 
>> ACK, thanks.
>> 
>> OK, I've fixed the problem. The issue was a missing (redirecting)
>> grub.cfg in the image to redirect to the correct location where there
>> grub menu etc. is located. I've just pushed code to the d-i build repo
>> to add that now, and tested locally.
>> 
>> I think I'm probably too late to pick up the daily d-i build for
>> Wednesday, but this should definitely be fixed from Thursday onwards.
>
>It worked for me with the daily from today (didn't check the one from 
>yesterday), both the text and GTK versions.

\o/

>The GTK version now starts in a much lower (apparent) resolution, while 
>previously it was using the full native resolution of the display (a 
>Full HD TV).
>
>Is this intended? Not that I mind, the lower resolution does help with 
>readability ;)

Hmmm, odd. I've not touched that at all. But maybe it's part of the
debug that kibi is doing with fonts etc. atm...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

2021-05-06 Thread Andrei POPESCU

On Mi, 05 mai 21, 01:21:24, Steve McIntyre wrote:
> On Tue, May 04, 2021 at 08:29:03AM +0300, Andrei POPESCU wrote:
> >On Lu, 03 mai 21, 19:52:32, Steve McIntyre wrote:
> >> 
> >> Reassigning to debian-installer, as that builds the mini.iso.
> >> 
> >> I'll take a look when I get a chance...
> >> 
> >> Oh, hmmm - do you have secure boot enabled or not on your machine?
> >
> >It's not enabled (sorry, forgot to mention).
> 
> ACK, thanks.
> 
> OK, I've fixed the problem. The issue was a missing (redirecting)
> grub.cfg in the image to redirect to the correct location where there
> grub menu etc. is located. I've just pushed code to the d-i build repo
> to add that now, and tested locally.
> 
> I think I'm probably too late to pick up the daily d-i build for
> Wednesday, but this should definitely be fixed from Thursday onwards.

It worked for me with the daily from today (didn't check the one from 
yesterday), both the text and GTK versions.

The GTK version now starts in a much lower (apparent) resolution, while 
previously it was using the full native resolution of the display (a 
Full HD TV).

Is this intended? Not that I mind, the lower resolution does help with 
readability ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#972270: Acknowledgement (sogo: Webmail loads indefinitely when opening message with invitation)

2021-05-06 Thread Thomas Schneider

I see that this has been “Marked as fixed in versions sogo/4.0.8-1”.
However, this version is not in buster – would it be possible to update
it there?

Thanks,
Thomas

-- 
Allgemeiner Studierendenausschuss (AStA) der RWTH Aachen

Thomas Schneider
IT-Administration

Pontwall 3
52062 Aachen
Deutschland

Telefon: +49 241 80 93798
Web: https://www.asta.rwth-aachen.de

Bug#988138: libauthcas-perl: CAS autentication fails when a new line character is missing in xml file

2021-05-06 Thread Luis A. Martinez

Package: libauthcas-perl
Version: 1.5-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

CAS authentication fails when the xml file provided by CAS servers is missing a 
new line character after the XML declaration. We have tested that this 
declaration works fine:




but this one fails providing a "CAS ticket validation failed" error:



I understand that both forms of the XML file are syntactically valid and the 
file should be equally parsed.



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

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

Versions of packages libauthcas-perl depends on:
ii  libio-socket-ssl-perl  2.044-1
ii  libwww-perl6.15-1
ii  perl   5.24.1-3+deb9u7

libauthcas-perl recommends no packages.

libauthcas-perl suggests no packages.

-- no debconf information

Bug#988049: unblock: gavodachs/2.3+dfsg-3

2021-05-06 Thread Graham Inggs

Hi Ole

On Thu, 6 May 2021 at 14:13, Ole Streicher  wrote:
> You are right, however it should be ensured to migrate before Bullseye,
> as it downgrades an RC bug. This is not directly visible, since I
> downgraded the bug already after the upload.
>
> --> if you plan to release before May 24, the migration time should be
> shortened accordingly.

I already reduced the age requirement to 5 days. :)
You'll see it the next time the excuses are updated.  I should have
mentioned that.

Regards
Graham

Bug#988137: ITS: libalgorithm-checkdigits-perl

2021-05-06 Thread Andrius Merkys

Source: libalgorithm-checkdigits-perl
Version: 0.50-1.1
X-Debbugs-CC: bure...@debian.org,
pkg-perl-maintain...@lists.alioth.debian.org

Hello,

It seems that libalgorithm-checkdigits-perl is not very well maintained
anymore.

Last maintainer upload of the package happened in 2009. Since then many
upstream releases have happened, adding new features and, most
importantly, fixing bugs. Even the major version has changed, from 0.50
to 1.3.5. Last NMU happened in January 2021 (no-change rebuild).

There are two Severity: normal bugs for this package. Both are open
since 2020 and have no response from the maintainer.

>From the QA perspective, there are 20 lintian warnings. Most of them
concern outdated packaging practices, for example, deprecated debhelper
compat level 5, missing debian/source/format and the like.

I believe the package fulfills conservative package salvaging criteria
as per [1]. Formally speaking, there are bugs, missing upstream
releases, QA work AND upload(s) are needed to deal with these issues AND
there is no visible activity for over 10 years except for single
no-change NMU.

I propose moving libalgorithm-checkdigits-perl under pkg-perl umbrella.
I am volunteering to co-maintain the package.

[1]
https://wiki.debian.org/PackageSalvaging#Eligibility_requirements_for_a_package

Best,
Andrius

Bug#988136: python-django: CVE-2021-32052

2021-05-06 Thread Chris Lamb

Package: python-django
Version: 1:1.10.7-2+deb9u13
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

  CVE-2021-32052: Header injection possibility since URLValidator
  accepted newlines in input on Python 3.9.5+

  On Python 3.9.5+, URLValidator didn't prohibit newlines and tabs. If
  you used values with newlines in HTTP response, you could suffer from
  header injection attacks. Django itself wasn't vulnerable because
  HttpResponse prohibits newlines in HTTP headers.

  Moreover, the URLField form field which uses URLValidator silently
  removes newlines and tabs on Python 3.9.5+, so the possibility of
  newlines entering your data only existed if you are using this
  validator outside of the form fields.

  This issue was introduced by the bpo-43882 fix.

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:

  https://www.djangoproject.com/weblog/2021/may/06/security-releases/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#931003: Bug#931003: Removed package(s) from unstable

2021-05-06 Thread Gerardo Ballabio

Thanks for your answer.

That the Makefile, if present, should work is certainly a reasonable
expectation, but as far as I can see, it isn't a license requirement.
Note that the GPL also explicitly states that the program is provided
without warranty of any kind (clause 11 in GPLv2, 15 in GPLv3), that
is, if it doesn't build, you're on your own. Your quote says that the
build scripts are part of the source code, but doesn't give them any
special status: a bug in the Makefile is the same as a bug in a source
file.

So I'd say that if the Makefile is broken (and you say it "may or may
not work" so that isn't even sure?), that's a bug, but not a license
violation.

I am not a lawyer, so this is just my opinion.

Gerardo

Il giorno gio 6 mag 2021 alle ore 10:47 Santiago Vila
 ha scritto:
>
> On Thu, May 06, 2021 at 09:50:43AM +0200, Gerardo Ballabio wrote:
> > Santiago Vila wrote:
> > > Among those packages there is even a GPL violation in gcc-8-cross,
> > as the FTBFS problem happens because the Makefile is buggy (the GPL
> > says packages must be distributed with a working Makefile).
> >
> > I was very surprised to read that. I just reread the GPL and could not
> > find that condition. Could you please direct me to where it says so?
> > As far as I understand, the GPL doesn't (and shouldn't) even require
> > that packages have a Makefile at all. Indeed, I believe there are
> > plenty of GPL'd software that use other build systems.
> > And any requirement that software may not have bugs is of course 
> > unenforceable.
>
> Sorry, I didn't mean to say that packages should include a Makefile.
> I meant that the Makefile, if present, should *work*.
>
> Quoting GPL-2:
>
>  The source code for a work means [...] plus the scripts used to
>  control compilation and installation of the executable.
>
> This is a general reference to whatever procedure a program may have
> to be built. If the program normally needs a Makefile, you have to
> provide the Makefile, and I guess that it's reasonable to assume that
> the Makefile should work, because the purpose is to enable anybody
> who receives the source code to build the program.
>
> In the case of gcc-8-cross, there is a Makefile which may or may not
> work:
>
> https://jenkins-1.reliable-builds.org/job/gcc-8-cross/
>
> which I consider a GPL violation.
>
> Thanks.

Bug#988135: evince: zooming 100% ignores dpi as reported by xrandr

2021-05-06 Thread Helmut Grohne

Package: evince
Version: 3.38.2-1

When you zoom a document to 100% and hole an equally sized sheet of
paper on the screen, you expect them to match. That used to be the case
with evince, but it no longer does. I don't know precisely since when.

Usually, xrandr/xdpyinfo know both the logical (pixel count) and
physical (mm or inch) dimension of the screen. From those values, one
can derive a dpi value to adjust what 100% zoom means. Applications such
as djview still implement that.

It seems like evince chose to change that:
https://sources.debian.org/src/evince/3.38.2-1/libdocument/ev-document-misc.c/?hl=552#L562

The logic there essentially says: If your screen is taller than 1080
pixels in landscape, your dpi is 192 and otherwise it is 96. For a
typical 1900x1200 24" display that happens to have roughly a dpi of 96,
evince determines that it must be a HiDPI display at 192 dpi. As a
result, 100% actually presents more like 200%.

That's quite unhelpful. This used to work correctly.

Helmut

Bug#987985: Bug in Redis-server Package

2021-05-06 Thread Chris Lamb

Hi Benjamin,

> At an earlier point im setting the kay-value like this,
>
>      const ok = await RedisServer.setValue(ip, '1', 'EX', 15);
>
> Where the variable ip is something like
>
> "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15"
>
> This seems to work, but i only get the error when im changing the
> key-value as i wrote. When im trying to access the entry and change the
> number '1' to '2' and set 'KEEPTTL'.

So, to confirm, you are running the equivalent of:

 $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "1" EX 
15
 $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "2" 
KEEPTTL

... with the second command failing? If so, although I can reproduce
this error using 3:3.2.6-3+deb9u4, I can _also_ reproduce it using
deb9u3. Again, just trying to track down the regression...


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#988131: falkon does not gain focus when called from external applications

2021-05-06 Thread Georges Khaznadar

Dear Ritesh,

I tried to reproduce the bug you are describing, without success.

My attempt to reproduce the bug was:

- From a terminal, I type "falkon", then Enter key
- Falkon is launched and it gets the focus.

My desktop software is currently LXDE, version 10; the terminal is
gnome-terminal. When I do the same with x-www-browser, Falkon's window
gets the focus too.

Which desktop manager are you using?

Best regards,   Georges.

Ritesh Raj Sarraf a écrit :
> Package: falkon
> Version: 3.1.0+dfsg1-11
> Severity: normal
> 
> First of all, a big thank you to both, you and the upstream team, for
> doing an awesome job with Falkon. I desperately wanted a simple yet
> modern web browser and Falkon fits the bill quite well.
> 
> 
> While it has been just a couple of hours with me using it, I think I've
> come across an integration issue with Falkon.
> 
> 
> Falkon, when called through, say x-www-browser, doesn't gain focus.
> Looking closer, I noticed the behavior with plain Falkon too. 
> 
> If you call Falkon as in `falkon www.debian.org` from your terminal, the
> web browser does open the page in a new tab, but the web browser does
> not gain focus, which is what the usual expectation would be.
> 
> OTOH, if I invoke the same command with `-t`, as in, `falkon -t
> www.debian.org`, falkon gains the focus.
> 
> It is a minor glitch and would be nice to have it fixed.
> 
> There's also a behaviral bug when launching Falkot with -t, in that
> along with opening the requested page in a tab, Falkon also opens an
> extra empty tab.
> 
> 
> PS: I have looked through the preferences in Falkon to be sure that it
> is not a functionality enabled/disabled and to my understanding that
> doesn't seem to be the case. Apologies in case it is something obvious
> and I may have missed.
> 
> Thanks,
> Ritesh
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 
> 'stable'), (100, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_USER
> Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages falkon depends on:
> ii  kio  5.81.0-1~np1
> ii  libc62.31-12
> ii  libgcc-s110.2.1-6
> ii  libkf5coreaddons55.81.0-1~np1
> ii  libkf5crash5 5.81.0-1~np1
> ii  libkf5kiocore5   5.81.0-1~np1
> ii  libkf5kiowidgets55.81.0-1~np1
> ii  libkf5purpose-bin5.81.0-1~np1
> ii  libkf5purpose5   5.81.0-1~np1
> ii  libkf5wallet-bin 5.81.0-1~np1
> ii  libkf5wallet55.81.0-1~np1
> ii  libqt5core5a 5.15.2+dfsg-5
> ii  libqt5dbus5  5.15.2+dfsg-5
> ii  libqt5gui5   5.15.2+dfsg-5
> ii  libqt5network5   5.15.2+dfsg-5
> ii  libqt5printsupport5  5.15.2+dfsg-5
> ii  libqt5qml5   5.15.2+dfsg-5
> ii  libqt5quickwidgets5  5.15.2+dfsg-5
> ii  libqt5sql5   5.15.2+dfsg-5
> ii  libqt5sql5-sqlite5.15.2+dfsg-5
> ii  libqt5webchannel55.15.2-2
> ii  libqt5webenginecore5 5.15.2+dfsg-3
> ii  libqt5webenginewidgets5  5.15.2+dfsg-3
> ii  libqt5widgets5   5.15.2+dfsg-5
> ii  libqt5x11extras5 5.15.2-2
> ii  libssl1.11.1.1k-1
> ii  libstdc++6   10.2.1-6
> ii  libxcb1  1.14-3
> ii  qml-module-qtwebengine   5.15.2+dfsg-3
> 
> falkon recommends no packages.
> 
> Versions of packages falkon suggests:
> pn  qtwebengine5-dev-tools  
> 
> -- no debconf information

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#973445: ITP: human-theme-gtk -- Human theme for GTK


Updated to 1.3.0-1.

Bug#988070: unblock: libxml2/2.9.10+dfsg-6.5 (pre-approval)

2021-05-06 Thread Salvatore Bonaccorso

Hi Emilio,

On Thu, May 06, 2021 at 11:27:50AM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> Hi Salvatore,
> 
> On 06/05/2021 10:56, Salvatore Bonaccorso wrote:
> > Control: retitle -1 unblock: libxml2/2.9.10+dfsg-6.6
> > (pre-approval)
> > On Tue, May 04, 2021 at 11:04:52PM +0200, Salvatore Bonaccorso wrote:
> > > Hi,
> > > 
> > > On Tue, May 04, 2021 at 09:19:20PM +0200, Salvatore Bonaccorso wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: unblock
> > > > X-Debbugs-Cc: car...@debian.org
> > > > 
> > > > Dear release team
> > > > 
> > > > This is a pre-approval request to please unblock package libxml2 (not
> > > > yet uploaded to unstable, but to experimental so far as
> > > > 2.9.10+dfsg-6.4).
> > > > 
> > > > Please unblock package libxml2
> > > > 
> > > > [ Reason ]
> > > > 
> > > > The update would fix three CVEs recently reported, CVE-2021-3516
> > > > (#987739), CVE-2021-3517 (#987738) and CVE-2021-3518 (#987737).
> > > > Which are not very severe but we still wanted to try to get fixes into
> > > > bullseye.
> > > > 
> > > > [ Impact ]
> > > > 
> > > > Package still affected by those CVEs.
> > > > 
> > > > [ Tests ]
> > > > 
> > > > For those three CVEs pocs are available, which I had tested before and
> > > > with the fix, except CVE-2021-3516, which I could not trigger the
> > > > issue, but the change is simple.
> > > > 
> > > > Furthermore given I uploaded to experimental there was additional
> > > > exposure by the autopkgtests. From those as you can see from
> > > > https://release.debian.org/britney/pseudo-excuses-experimental.html
> > > > three marked regressions, but both balsa and kopanocore were already
> > > > before failing.  For libreoffice the tests somehow are flapping where
> > > > they fail, I do not see a relation to the libxml2 here. libreoffice
> > > > failed there in the last run for uicheck-sc test (triggered by
> > > > python3.9), but in the libxml2 case it failed for the uicheck-sw  test
> > > > and for the prvious failure it was again one other test.
> > > 
> > > To confirm: And in fact just one other run did not fail:
> > > https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/12125523/log.gz
> > 
> > Another CVE popped up, which I have included in a new upload, thus
> > retitling the bug and attaching the new debdiff.
> 
> Please go ahead and let us know once the package has been accepted.

Thank you very much. I have uploaded and it got accepted, and all
architectures built. 

Regards,
Salvatore

Bug#973447: ITP: python3-radexreader -- Python library for the RADEX RD1212 and ONE Geiger counters


Updated to 1.2.0-1.

Bug#959436: ITP: awf-gtk3 -- A widget factory is a theme preview application for GTK


Updated to 2.4.0-1.

Bug#959434: ITP: awf-gtk2 -- A widget factory is a theme preview application for GTK


Updated to 2.4.0-1.

Bug#959433: ITP: awf-gtk4 -- A widget factory is a theme preview application for GTK


Updated to 2.4.0-1.

Bug#988132: systemd-resolved stub resolver does not pass RRSIG data for applications to answer DNSSEC queries