date:20210608

package release.debian.org
tags 989623 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: scrollz
Version: 2.2.3-1+deb10u1

Explanation: fix denial of service issue [CVE-2021-29376]

Bug#989631: nettle: CVE-2021-3580: Remote crash in RSA decryption via manipulated ciphertext

Source: nettle
Version: 3.7.2-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nettle.

CVE-2021-3580[0]:
| Remote crash in RSA decryption via manipulated ciphertext

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-3580
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3580
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1967983
[2] 
https://git.lysator.liu.se/nettle/nettle/-/commit/0ad0b5df315665250dfdaa4a1e087f4799edaefe
[3] 
https://git.lysator.liu.se/nettle/nettle/-/commit/485b5e2820a057e873b1ba812fdb39cae4adf98c
[4] 
https://git.lysator.liu.se/nettle/nettle/-/commit/485b5e2820a057e873b1ba812fdb39cae4adf98c

Regards,
Salvatore

Bug#989487: mmdebstrap: produces different tarball when building squashfs image

2021-06-08 Thread Vagrant Cascadian

On 2021-06-06, Johannes Schauer Marin Rodrigues wrote:
> Quoting Vagrant Cascadian (2021-06-05 19:39:56)
>> On 2021-06-05, Johannes Schauer Marin Rodrigues wrote:
>> > Quoting Vagrant Cascadian (2021-06-05 03:09:52)
>> > Is that such a common task? Are you running mmdebstrap manually and find
>> > yourself piping it to tar2sqfs by hand? Do you maybe suggest that the 
>> > default
>> > options might need changing? I'm trying to understand your use-case here.
>> 
>> Well, *mostly* just to build zstd squashfs instead of xz (the
>> performance on various hardware I use is considerable better with zstd
>> defaults). Being able to set the compression type directly from
>> mmdebstrap would be nice!
>> 
>> I think I also needed to pipe to tar2sqfs manually in the past to
>> workaround bugs that I think have since been fixed (e.g. the
>> --xattrs-exclude patches).
>
> But are you running mmdebstrap by hand or are you using it as part of a 
> script?

From a relatively simple script, but I have yet to figure out the ideal
arguments to pass to tar2sqfs.

I've also experimented with bdebstrap a bit, though it has been even
more difficult to enable zstd with yet another layer of
abstraction... though there are definitely elements of it I like.

>> The current default for tar2sqfs is xz, so passing --compressor xz is
>> redundant.
>
> Maybe I should just drop the "--compressor xz" option and use the tar2sqfs
> default and then you can post a bugreport about a good default with the
> tar2sqfs people instead of here. ;)

Good defaults may be context dependent... but if you really don't want
to make it possible to pass custom arguments to tar2sqfs, I can't make
you. :)

Playing "good defaults" whack-a-mole with a handful of projects down the
stack is not something I'm likely to pursue too much for fun. If it
comes to that, I'll most likely just deal with the consequences of 'xz'
or locally patch mmdebstrap.

Thanks for considering, I know it's always a balancing act to avoid
extra complication and still provide good defaults.

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

2021-06-08 Thread Josh Triplett

Package: e2fsprogs
Version: 1.46.2-2
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

"important" because this does cause data loss; not filing as
release-critical because using mke2fs on a full disk or full disk image
with a specified size to write a partition may be a niche use case.

mke2fs with a specified size and the default-enabled "discard" option
will discard data after that specified size. If using the size (and
potentially offset) to write a partition within a disk or disk image,
this will zero part of the following partition.

Steps to reproduce:

# Make a disk filled with 0x0a, to see which bytes get written
yes '' | dd iflag=fullblock of=test.img bs=1M count=128
# Show the disk filled with 0x0a
hd test.img
# Make a 1M filesystem
mkfs.ext4 -b 4096 -I 256 test.img 1M
# Show the disk, which has the first 16M of data discarded
hd test.img

This also applies if you pass an offset; for instance, passing
offset=4096 will discard data from 4096 to 16M+4096


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

Kernel: Linux 5.12.8 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e2fsprogs depends on:
ii  libblkid12.36.1-7
ii  libc62.31-12
ii  libcom-err2  1.46.2-2
ii  libext2fs2   1.46.2-2
ii  libss2   1.46.2-2
ii  libuuid1 2.36.1-7
ii  logsave  1.46.2-2

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.4-1

-- no debconf information

Bug#989629: ITP: elementary-code -- Essential code editor with tab support

2021-06-08 Thread Francisco M Neto

Package: wnpp
Severity: wishlist
Owner: Francisco M Neto 
X-Debbugs-Cc: debian-de...@lists.debian.org, fmn...@fmneto.com

* Package name: elementary-code
  Version : 3.4.1
  Upstream Author : elementary, Inc 
* URL : https://elementary.io
* License : GPL-3+, LGPL-3
  Programming Lang: Vala
  Description : Essential code editor with tab support

Elementary Code earlier called Scratch, is an IDE
designed with simplicity in mind. It offers essential functionalities
such as git support, multi-panel and miniview support and extensions
for integration with the Terminal and web visualization.

It is written from scratch, with support for plugins. Its purpose is
to be lightweight and extensible, with plenty of customization
options. It support syntax highlighting for a wide range of
programming languages.

It is a minimalist, extensible GTK-based IDE that is not dependent
on GNOME. It follows the Elementary Human Interface Guidelines.

As with other elementary OS-related packages, I'll need a sponsor
(at least for the time being).

Bug#989579: arm-trusted-firmware: Raspberry pi builds

2021-06-08 Thread Vagrant Cascadian

On 2021-06-07, Vagrant Cascadian wrote:
> On 2021-06-07, Nolan wrote:
>> While it won't provide any real security features, it would let people 
>> "fix" the pi's missing PSCI, which would enable the use of kexec.
>
> There appear to be two rpi platforms in arm-trusted-firmware
> v2.4. Reading the documentation on rpi3:
>
>   
> https://salsa.debian.org/debian/arm-trusted-firmware/-/blob/0f7062a50552947943316e83557dddb47fba3efe/docs/plat/rpi3.rst
>
> There appear to be many permutations of possible configuration options,
> so it is unclear exactly what to enable...
>
>
> The documentation for rpi4:
>
>   
> https://salsa.debian.org/debian/arm-trusted-firmware/-/blob/0f7062a50552947943316e83557dddb47fba3efe/docs/plat/rpi4.rst
>
> Is relatively simple and clear, though!
>
>
> Could you spell out a little more what you'd like enabled, ideally with
> a tested patch? :)

I ended up uploading to experimental with both rpi4 and rpi3. The rpi3
build instructions were confusing; hopefully the defaults are
reasonable.

Please test it when you get a chance!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#866502: ITP: element-web: web-based matrix client

2021-06-08 Thread Robbi Nespu


Hello! Is there any update for this ITP?
If there is pending issue, where I can take a look the existing work?


--
Email : Robbi Nespu 
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key : https://keybase.io/robbinespu/pgp_keys.asc

Bug#989628: base-files: shell profile check for bash and interactiveness

2021-06-08 Thread Christoph Anton Mitterer

Package: base-files
Version: 11.1
Severity: normal


Hi.


(CCing Georgios M. Zarkadas from #632887 for his comments on (3)
below, if any.)



Currently /usr/share/base-files/profile has:
if [ "${PS1-}" ]; then
  if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then


and /usr/share/base-files/dot.profile has:
if [ "$BASH" ]; then



I think there are several issues with that, respectively possible
improvements:


1) I'd say, both should do the same (i.e. /etc/profile and ~/.profile),
   so that should be aligned.


2) /etc/bash.bashrc already checks whether run interactively, so
   if it's just for whether /etc/bash.bashrc shall be sourced or not, the
   `if [ "${PS1-}" ]; then` is not really needed (other than avoiding the
   sourcing).
   
   But even then, using PS1 is IMO not optimal.
   The variable may exist in a non-interactive shell (e.g. when exported
   in a calling parent shell).
   The following:
if [ -n "${-##*i*}" ]  ||  [ -z "${-}" ]; then
return
fi
   uses the shell options which, I guess, one can assume are always right.
   The above code should be POSIXly correct and unlike some constructs
   with `case` avoid the hypothetical issue of a future option "I" being
   mistaken for "i", when bash's nocasematch option would be on.


3) The check for /bin/sh:
   - Shouldn't that also be in .profile?
   - Shouddn't it also cover the sourcing of /etc/profile.d/*.sh
 (for the same reasons)?
   - The check itself is IMO problematic:
 bash's manual talks about the "sh-like-behaviour" when invoked as
 `sh`, not necessarily as `/bin/sh`.
 Also this would break, should sh ever go to /usr/bin/sh as part of
 the usr-merge.
 
 So, wouldn't it be better to check e.g.:
 if [ -z "${0##*/sh}" ]  ||  [ "$0" = sh ] ; then
#it's run as sh
 ?
 I think $0 can never be empty, so there's no need to check that it's
 actually set to something.


4) $BASH might be bogus.
   Just export BASH, and then run dash...
   Well, it's no our business to prevent users from shooting themselves,
   at least not to every extent.

   But one could do:
   if  [ -n "${BASH-}" ]   &&   { [ "$(ps -p $$ -o exe=)" = /usr/bin/bash ]  || 
 [ "$(ps -p $$ -o exe=)" = /bin/bash ]; };  then

   That has the short-circuit that if BASH is not there, don't source bashrc.
   So there should be nearly no speed impact for shell scripts.

   But if it's there, the above would also check whether the executable
   is actually /usr/bin/bash or /bin/bash.
   The above is not fully POSIX-compatible (POSIX ps has no "exe").
   Calling ps twice is a bit ugly...  but I see no other way than using
   a helper variable. Maybe the `i` can be used, which is already used below
   when sourcing /etc/profile.d/*.sh .

   Also, ps isn't guaranteed to be there (procps isn't essential).
   So either one would need to check for that... or e.g. use /proc/$$/exe


Cheers,
Chris.

Bug#989627: ITA: rope -- Python refactoring library

2021-06-08 Thread Pablo Mestre

Package: wnpp
Severity: normal

Hello!

I would like to adopt this package.

Work has already been done at
https://salsa.debian.org/elMor3no-guest/rope 


Format: 1.8
Date: Mon, 24 May 2021 02:06:44 -0300
Source: rope
Binary: python3-rope
Architecture: source all
Version: 0.19.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team 
Changed-By: Pablo Mestre Drake 
Description:
 python3-rope - Python 3 refactoring library
Changes:
 rope (0.19.0-1) unstable; urgency=medium
 .
   [ Pablo Mestre Drake ]
   * New upstream version 0.19.0
   * Add salsa-ci.yml copied from Debian pipeline for Developers
   * debian/watch: Update parameters to check for newer versions
Checksums-Sha1:
 b73cf15a129d6170ae2b3f450752554f97c81c52 1132 rope_0.19.0-1.dsc
 7bc85c8029ff0d5776f704500bbf2e687579378b 252902 rope_0.19.0.orig.tar.gz
 308eb1aea011cfb0cef94b960e95c5a67e173634 3872 rope_0.19.0-1.debian.tar.xz
 c8b7ec9c344c14a4fa7d3ede0697d1b36b8b6608 137832 python3-rope_0.19.0-1_all.deb
 7e5f3ac0f3bee5210f395fadb3f47e968b4dcc70 5382 rope_0.19.0-1_amd64.buildinfo
Checksums-Sha256:
 e590d89a80d33cf5c742ea44a39d5633a2b11210bbf051a80dc7f9f5c43e00b2 1132 
rope_0.19.0-1.dsc
 64e6d747532e1f5c8009ec5aae3e5523a5bcedf516f39a750d57d8ed749d90da 252902 
rope_0.19.0.orig.tar.gz
 3214d6de2a0f4eaa7c3b17c1a2a6c875d1e4fede9c77315f1cc1bf0018211f20 3872 
rope_0.19.0-1.debian.tar.xz
 ac7423e4f7035590283bf3cfcb4aae922b61ecd9dfcf65257406ef6b5fae4823 137832 
python3-rope_0.19.0-1_all.deb
 312b271c796cd6b1c1a876ccd8b9ff9ff63a02cbb35fec9060921c9870f2710a 5382 
rope_0.19.0-1_amd64.buildinfo
Files:
 d337bf7373a8e79ab23dd72d734bf634 1132 devel optional rope_0.19.0-1.dsc
 8f844c0d5545b0034820074c1cd7ec10 252902 devel optional rope_0.19.0.orig.tar.gz
 dd0e2252025e9f5f67b7fb8fb479e2b0 3872 devel optional 
rope_0.19.0-1.debian.tar.xz
 bfc5d7d2b2d6dcbf18121ea015296959 137832 devel optional 
python3-rope_0.19.0-1_all.deb
 1d0a73b606204c920f7c5776efee06dc 5382 devel optional 
rope_0.19.0-1_amd64.buildinfo

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

2021-06-08 Thread Paul Wise

On Tue, Jun 8, 2021 at 6:54 AM clay stan wrote:

> Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek,
> not arm PC, They are not supported by Debian.

Debian can run on ARM mobile chips, probably a non-mainline Linux
kernel from outside of Debian will be needed though.

https://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/
https://wiki.debian.org/Mobile
https://mobian.debian.net/
https://wiki.debian.org/Mobian
https://mobian-project.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#989626: diffoscope: when comparing fonts with .ttx files, convert the font to .ttx first

2021-06-08 Thread Paul Wise

Package: diffoscope
Version: 177
Severity: wishlist

diffoscope currently prints a hex dump when comparing a TTF font with a
.ttx XML dump of a TTF font. If it used ttx (from fonttools) to convert
that TTF font to .ttx instead, then the comparison would become an XML
diff, which diffoscope treats as a text diff, which is better than hex.

   $ git clone -q https://gitlab.gnome.org/GNOME/gtksourceview
   
   $ diffoscope gtksourceview/data/fonts/BuilderBlocks.tt{f,x}
   --- gtksourceview/data/fonts/BuilderBlocks.ttf
   +++ gtksourceview/data/fonts/BuilderBlocks.ttx
   @@ -1,28 +1,259 @@
   -: 0001  0008 0080 0003  636d 6170  cmap
   -0010: 0021 0258  0114  004c 676c 7966  .!.X...Lglyf
   -0020: 2644 7e48  016c  0030 6865 6164  &D~H...l...0head
   -0030: 0733 9950  008c  0036 6868 6561  .3.P...6hhea
   -0040: 0c01 0402  00c4  0024 686d 7478  ...$hmtx
   -0050: 0400   0108  000a 6c6f 6361  loca
   -0060: 0024 000c  0160  000a 6d61 7870  .$.`maxp
   -0070: 0006 0005  00e8  0020 6e61 6d65  ... name
   ...
   +: 3c3f 786d 6c20 7665 7273 696f 6e3d 2231  ...  .

   -
   -
   -
   +
   +
   +
  

  



   -
   +




   -
   +


   -
   -
   +
   +





  
   ...

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

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

Versions of packages diffoscope depends on:
ii  diffoscope-minimal  177

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.2.53-10
ii  apksigner30.0.3-4
ii  apktool  2.5.0+dfsg.1-2
ii  binutils-multiarch   2.35.2-2
ii  bzip21.0.8-4
ii  caca-utils   0.99.beta19-2.2
ii  colord   1.4.5-3
ii  db-util  5.3.1+nmu1
ii  default-jdk [java-sdk]   2:1.11-72
ii  default-jdk-headless 2:1.11-72
pn  device-tree-compiler 
pn  docx2txt 
ii  e2fsprogs1.46.2-1
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:4.3.2-0+deb11u2
ii  fontforge-extras 1:20201107~dfsg-4
pn  fp-utils 
ii  genisoimage  9:1.1.11-3.2
ii  gettext  0.21-4
ii  ghc  8.8.4-2
ii  ghostscript  9.53.3~dfsg-7
ii  giflib-tools 5.1.9-2
ii  gnumeric 1.12.48-1+b2
ii  gnupg2.2.27-2
ii  gnupg-utils  2.2.27-2
pn  hdf5-tools   
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  jsbeautifier 1.13.0-1
ii  libarchive-tools 3.4.3-2+b1
ii  llvm 1:11.0-51+nmu5
ii  lz4 [liblz4-tool]1.9.3-2
pn  mono-utils   
ii  ocaml-nox4.11.1-4
pn  odt2txt  
pn  oggvideotools
ii  openjdk-11-jdk [java-sdk]11.0.11+9-1
ii  openssh-client   1:8.4p1-5
ii  openssl  1.1.1k-1
ii  pgpdump  0.33-2
ii  poppler-utils20.09.0-3.1
pn  procyon-decompiler   
ii  python3-argcomplete  1.8.1-1.5
ii  python3-binwalk  2.3.1+dfsg1-1
ii  python3-debian   0.1.39
ii  python3-defusedxml   0.6.0-2
ii  python3-guestfs  1:1.44.0-2
ii  python3-jsondiff 1.1.1-4
ii  python3-pdfminer 20200726-1
ii  python3-progressbar  2.5-2
ii  python3-pypdf2   1.26.0-4
ii  python3-pyxattr  0.7.2-1+b1
ii  python3-rpm  4.16.1.2+dfsg1-0.4
ii  python3-tlsh 3.4.4+20151206-1.3+b4
pn  r-base-core  
pn  radare2  
ii  rpm2cpio 4.16.1.2+dfsg1-0.4
ii  sng

Bug#989625: gqrx-sdr: Should not depend on pulseaudio package directly

2021-06-08 Thread Witold Baryluk

Package: gqrx-sdr
Severity: important
X-Debbugs-Cc: witold.bary...@gmail.com

I think this is a bug in the dependency info.

It probably should depend on `libpulse0`, not `pulseaudio`

This way it will also work with pipewire for example with pulseaudio
removed. Or if the libraries are installed, but not a deamon (there are
use cases for this too).

Regards,
Witold


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

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

Bug#986527: sagemath: FTBFS: how to address for Bullseye

2021-06-08 Thread John Scott

On Tue, 08 Jun 2021 17:15:44 +0200 Julien Puydt wrote:
> I've been convinced that getting a fragile sagemath in next stable
> wouldn't be a good thing.
You've put much more effort than I have into maintaining scientific
software in Debian, so I respect your opinion, but is it really
accurate to say that SageMath is fragile as a whole?

With respect to this particular issue, I'd like to share my perspective
wrangling with a package that poses a similar dilemma: GCC (I'm working
on packaging gcc-sh-elf). Like the status quo with SageMath in Debian,
GCC has a test suite where failures are normal, and in general it takes
an individual to watch out for what number of failures counts as "too
many." Rather than hardcode an arbitrary threshold for what number of
failing tests is acceptable, it seems that it's much better, and in the
interest of Debian ports and alternative build environments, to just
let the tests run for informative purposes.

This, I believe, is what the GCC team actually does; the test results
get sent to the team mailing list IIRC. Perhaps we should take a
similar philosophy towards the tests.

At least with GCC and DejaGnu, the test results get written out to a
file, so before a new upload, say, one can do a diff on the old and new
test results and see if any new regressions were introduced. In this
same respect, SageMath test results may be best consulted before new
uploads by hand.

I believe it's in the best interest of Debian users that this bug be
downgraded for Bullseye so Sage can be used in the mostly-wholesome
shape it's in, but since I lack expertise in maintaining it I too will
leave this to someone else.

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

Bug#964511: Tests are failing, need to depends on the svg loader

2021-06-08 Thread Paul Wise

On Tue, 2021-06-08 at 16:24 +0200, Ondřej Tůma wrote:

> I'm waiting for Ondrej N. now.

For future reference, if your usual sponsor doesn't have time, you can
file a request for sponsoring, details are available here:

   https://mentors.debian.net/intro-maintainers

> I was prepare new Debian 1.3.0.-2 version, which has backported all
> improvements with Sebastien's changes too.

When you do that, it is generally a good idea to notify the bug that
the fixed version is available and just waiting a sponsor. For low
severity bugs run tagpending from devscripts but for severity important
or higher bugs mailing the bug with details & tag pending is needed.

   https://manpages.debian.org/tagpending
   https://www.debian.org/Bugs/Reporting#control
   https://www.debian.org/Bugs/server-control#tag
   https://www.debian.org/Bugs/Developer#tags

These changes you have made need fixes:

 * the second test in debian/tests/control needs to be marked as a
   superficial test too according to #974458
 * debian/changelog for superficial issue should (Closes: #974458)
 * debian/changelog for rsvg issue should (Closes: #964511)
 * the reason for the addition of python3-docutils to the build deps
   should be documented in debian/changelog
 * the reason for the update of the X-Python3-Version field should be
   documented in debian/changelog
 * there is a debian/changelog entry about upstream metadata but those
   changes don't seem to be in the package

These changes made in 1.3.0-2 are not suitable under the freeze policy:

   https://release.debian.org/bullseye/freeze_policy.html

 * the release team usually reject debhelper compat bumps, unless you
   can prove that the change does not change the binary packages in a
   meaningful way. You can do that by building once with debhelper
   debian/compat 11 and once with debhelper-compat 12 and attach
   diffoscope output for the .changes files between the two builds.
   https://manpages.debian.org/diffoscope
   https://diffoscope.org/

> Here branch of debian's package git repository:
> https://github.com/ondratu/formiko-debian/tree/1.3.0

Please make the changes I have listed above, file an unblock request
(reportbug release.debian.org, select unblock), upload a source package
to mentors and file an RFS, then I will upload the package to Debian,
once the release team approve the changes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#989593: installation report Raspberry Pi 4 UEFI

2021-06-08 Thread Holger Wansing

Hi,

Cyril Brulebois  wrote (Tue, 8 Jun 2021 17:07:52 +0200):
> Marc Haber  (2021-06-08):
> > Since my default domain types differently with US and DE keyboard, I
> > guess this might be an actual regression, I would have noticed this in
> > earlier versions of the installer.
> 
> I guess someone could try various images outside the Pi 4 setup and see
> whether/when that regressed. Given the following issue (ssd), I wouldn't
> rule out some Pi-specific, but such a trivial thing seems a little
> strange… That being said, I test the graphical installer most of the
> time, and I don't know the specifics of the text version by heart.

I checked with rc1 and the *brandnew* rc2 netinst images on amd64 qemu
VM machine (text installer), and I cannot reproduce such issue with wrong 
keyboard layout; German is correctly available immediately after the 
"Configure keyboard" step.

So, I guess that a Pi-specific thingy somehow.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#989624: golang-github-klauspost-cpuid-dev: Outdated package

2021-06-08 Thread Peymaneh Nejad

Package: golang-github-klauspost-cpuid-dev
Version: 1.3.1
Severity: normal

Dear Maintainers,

I wish to package github.com/caddyserver/certmagic[1] which
depends on v2.0.6 of this library. Could you please update? 

I am happy to provide a patch if wished.

kind regards,
Peymaneh

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

Bug#989623: buster-pu: package scrollz/2.2.3-1+deb10u1

2021-06-08 Thread Mike Markley

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Version 2.2.3-2 of this package fixed a grave bug (#986215, a remote crash) in
this package for unstable with the smallest set of changes possible, by
applying an upstream PR targeting the specific issue. The fix was tested in
that version, and is now also in bullseye.

Version 2.2.3-1+deb10u1 is a rebuild of the same package targeted for buster.

I spoke with the security team and they did not feel a DSA was warranted, but
as it is a fairly serious issue with the client, I'm hoping this fix can be
included in a point release of buster.

-- 
Mike Markley 
diff -Nru scrollz-2.2.3/debian/changelog scrollz-2.2.3/debian/changelog
--- scrollz-2.2.3/debian/changelog  2014-11-05 17:37:01.0 -0700
+++ scrollz-2.2.3/debian/changelog  2021-06-06 10:16:54.0 -0600
@@ -1,3 +1,12 @@
+scrollz (2.2.3-1+deb10u1) buster; urgency=high
+
+  * Applied patch to ctcp.c to fix CVE-2021-29376 from
+https://github.com/ScrollZ/ScrollZ/pull/26 (Closes: #986215)
+  * Applied minor patch from upstream to the above fix
+  * Rebuild for buster
+
+ -- Mike Markley   Sun, 06 Jun 2021 10:16:54 -0600
+
 scrollz (2.2.3-1) unstable; urgency=low
 
   * New release.
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376.patch 
scrollz-2.2.3/debian/patches/CVE-2021-29376.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376.patch   1969-12-31 
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376.patch   2021-06-06 
10:12:06.0 -0600
@@ -0,0 +1,46 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index b977f9b..32a496a 100644
+--- a/source/ctcp.c
 b/source/ctcp.c
+@@ -31,7 +31,7 @@
+  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+  * SUCH DAMAGE.
+  *
+- * $Id: ctcp.c,v 1.56 2009-12-21 14:39:21 f Exp $
++ * $Id: ctcp.c,v 1.56 2021-04-26 19:57:28 t Exp $
+  */
+ 
+ #include "irc.h"
+@@ -1629,14 +1629,29 @@ do_utc(ctcp, from, to, args)
+   *to,
+   *args;
+ {
+-  time_t  tm;
++  time_t  tm = time(NULL),
++  curtime = time(NULL);
+   char*date = NULL;
+ 
+   if (!args || !*args)
+   return NULL;
+   tm = atol(args);
+-  malloc_strcpy(&date, ctime(&tm));
+-  date[strlen(date)-1] = '\0';
++  curtime = ctime(&tm);
++
++  if (curtime)
++  {
++  u_char *s = index(curtime, '\n');
++  if (s)
++  {
++  *s = '\0';
++  }
++  malloc_strcpy(&date, UP(curtime));
++  }
++  else
++  {
++  /* if we can't find a time, just return the number */
++  malloc_strcpy(&date, args);
++  }
+   return date;
+ }
+ 
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch 
scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch1969-12-31 
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch2021-06-06 
10:12:06.0 -0600
@@ -0,0 +1,13 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index 32a496a..2b661bd 100644
+--- a/source/ctcp.c
 b/source/ctcp.c
+@@ -1630,7 +1630,7 @@ do_utc(ctcp, from, to, args)
+   *args;
+ {
+   time_t  tm = time(NULL),
+-  curtime = time(NULL);
++  curtime;
+   char*date = NULL;
+ 
+   if (!args || !*args)
diff -Nru scrollz-2.2.3/debian/patches/series 
scrollz-2.2.3/debian/patches/series
--- scrollz-2.2.3/debian/patches/series 2014-10-22 16:08:28.0 -0600
+++ scrollz-2.2.3/debian/patches/series 2021-06-06 10:12:06.0 -0600
@@ -4,3 +4,5 @@
 spelling-errors.patch
 rijndael-prototypes.patch
 sys-stat-h.patch
+CVE-2021-29376.patch
+CVE-2021-29376-update.patch

Bug#989593: installation report Raspberry Pi 4 UEFI

2021-06-08 Thread Geert Stappers

On Tue, Jun 08, 2021 at 09:49:15PM +0200, Marc Haber wrote:
>
> The more pressing issue IMO is the deletion of /sbin/start-stop-daemon.
>

Repeating this:

If you were to retry the installation, saving /var/log/syslog manually
before rebooting into the installed system would be useful. Without it,
I fear much guessing would be needed to try and figure out what happened
on that system specifically. Unless someone else has better ideas of
course.

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

Bug#989622: linux-image-5.10.0-7-amd64: Sound regression on Dell Precision 5750

2021-06-08 Thread kilian

Package: src:linux
Version: 5.10.40-1
Severity: important
X-Debbugs-Cc: kil...@stanford.edu

Dear Maintainer,

I'm observing a regression on a Dell Precision 5750 running kernel 
5.10.0-7-amd64.

Sound (output and mic) used to work just fine, but a recent update must have
broken something, as no audio devices are detected anymore. Alsa config has not
changed, firmware files are still in place (Debian package firmware-sof-signed
1.6.1-2), but suddenly, the device initialization fails to happen properly.

The first error seems to be (cf. kernel logs below)
soundwire sdw:2:25d:1308:0: Probe not complete, timed out

Any idea what may cause this? The hardware is functional and works normally
when booting Windows, so a hardware issue can be ruled out.



-- Package-specific info:
** Version:
Linux version 5.10.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.40-1 (2021-05-28)

** Command line:
BOOT_IMAGE=/@/boot/vmlinuz-5.10.0-7-amd64 
root=UUID=29faa641-f583-4d0b-b6c6-0e0234095b2f ro rootflags=subvol=@ quiet 
splash resume=/dev/mapper/nvme0n1p5_crypt resume_offset=929516

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[9.200170] usbcore: registered new interface driver btusb
[9.201268] Bluetooth: hci0: Firmware revision 0.0 build 121 week 7 2021
[9.272816] iwlwifi :00:14.3: base HW address: 98:af:65:cb:44:54
[9.285627] thermal thermal_zone9: failed to read out thermal zone (-61)
[9.606850] dell_laptop: Using i8042 filter function for receiving events
[9.656050] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[9.656070] sof-audio-pci :00:1f.3: enabling device ( -> 0002)
[9.656198] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040100
[9.656330] sof-audio-pci :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[9.663052] sof-audio-pci :00:1f.3: use msi interrupt mode
[   10.004817] sof-audio-pci :00:1f.3: hda codecs found, mask 4
[   10.012891] sof-audio-pci :00:1f.3: firmware: direct-loading firmware 
intel/sof/sof-cml.ri
[   10.149982] sof-audio-pci :00:1f.3: Firmware info: version 1:6:1-53680
[   10.149985] sof-audio-pci :00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 
3:17:0
[   12.179894] soundwire sdw:2:25d:1308:0: Probe not complete, timed out
[   12.179897] soundwire sdw-master-2: Update Slave status failed:-110
[   12.179909] soundwire sdw:1:25d:1308:0: Probe not complete, timed out
[   12.179910] soundwire sdw-master-1: Update Slave status failed:-110
[   12.179916] soundwire sdw:0:25d:711:0: Probe not complete, timed out
[   12.179918] soundwire sdw-master-0: Update Slave status failed:-110
[   12.216315] soundwire sdw:3:25d:715:0: Probe not complete, timed out
[   12.216318] soundwire sdw-master-3: Update Slave status failed:-110
[   13.204624] ucsi_acpi USBC000:00: unknown error 0
[   13.204627] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
[   13.505796] intel_rapl_common: Found RAPL domain package
[   13.505798] intel_rapl_common: Found RAPL domain core
[   13.505799] intel_rapl_common: Found RAPL domain uncore
[   13.505800] intel_rapl_common: Found RAPL domain dram
[   13.505801] intel_rapl_common: Found RAPL domain psys
[   13.841323] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
[   13.859954] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[   13.927774] sof-audio-pci :00:1f.3: firmware: direct-loading firmware 
intel/sof-tplg/sof-cml-rt711-rt1308-rt715.tplg
[   13.927784] sof-audio-pci :00:1f.3: Topology: ABI 3:17:0 Kernel ABI 
3:17:0
[   13.943007] sof-audio-pci :00:1f.3: ASoC: Parent card not yet available, 
widget card binding deferred
[   13.966568] input: sof-soundwire Headset Jack as 
/devices/pci:00/:00:1f.3/sof_sdw/sound/card0/input27
[   13.966721] input: sof-soundwire HDMI/DP,pcm=5 as 
/devices/pci:00/:00:1f.3/sof_sdw/sound/card0/input28
[   13.966855] input: sof-soundwire HDMI/DP,pcm=6 as 
/devices/pci:00/:00:1f.3/sof_sdw/sound/card0/input29
[   13.967001] input: sof-soundwire HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sof_sdw/sound/card0/input30
[   16.882617] bbswitch: version 0.8
[   16.882621] bbswitch: Found integrated VGA device :00:02.0: 
\_SB_.PCI0.GFX0
[   16.882628] bbswitch: Found discrete VGA device :01:00.0: 
\_SB_.PCI0.PEG0.PEGP
[   16.882645] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
[   16.882718] bbswitch: detected an Optimus _DSM function
[   16.882728] bbswitch: Succesfully loaded. Discrete card :01:00.0 is on
[   16.883087] [drm] [nvidia-drm] [GPU ID 0x0100] Unloading dri

Bug#909473: fstrim shows incorrect trimmed size after reboot

2021-06-08 Thread Bastian Blank

Hi

On Tue, Jun 08, 2021 at 11:43:06PM +0200, Laurent Bigonville wrote:
> Well I would expect that if I'm running fstrim, the same blocks would not be
> trimmed again (even after reboot) if I'm running the command again

But how would it know that it was already trimmed?

> Here it seems that it's the case, the number of blocks that are being
> trimmed are the same after reboot.

Sure, you did not change the free space (much).

> Are the discard commands delayed and actually not executed when the command
> is run, or am I overlooking something?

You are overlooking that the information about discards is only in
memory.

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7

Bug#986001: buster-pu: package glib2.0/2.58.3-2+deb10u3

2021-06-08 Thread Simon McVittie

On Tue, 08 Jun 2021 at 21:48:31 +0100, Adam D. Barratt wrote:
> On Mon, 2021-05-31 at 01:52 +0200, Cyril Brulebois wrote:
> > In the interest of not delaying this any further, I'd probably
> > recommend accepting the package into p-u, and if for some reasons
> > tests
> > look bad when I get to them, I can always exclude prefer the version
> > currently in buster through some apt_preferences when building d-i
> > for
> > 10.10… (And we would have up to 10.11 to find a fix.)
> 
> That sounds good to me; thanks.
> 
> Simon - please feel free to upload.

Uploaded 2.58.3-2+deb10u3.

smcv

Bug#909473: fstrim shows incorrect trimmed size after reboot

2021-06-08 Thread Laurent Bigonville


Le 8/06/21 à 21:24, Bastian Blank a écrit :

Hi

Hello,

On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:

There is definitely something boggus here

Yes, just tested it now and  it's still happening with the kernel currently
in unstable (5.10.40-1)

Why do you think this numbers are wrong?  "fstrim" initially requests
discard of all unused blocks, so a large number.  But why should it do
the same on subsequent calls while it still knows what it did the last
time?

ext4 caches the information if a particular block group was trimmed, but
this information is not persistent.  (Using bit
EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)


Well I would expect that if I'm running fstrim, the same blocks would 
not be trimmed again (even after reboot) if I'm running the command again


Here it seems that it's the case, the number of blocks that are being 
trimmed are the same after reboot.


Are the discard commands delayed and actually not executed when the 
command is run, or am I overlooking something?

Bug#984458: (no subject)

2021-06-08 Thread Julian Groß


The issue is fixed in the newest 1.2.9-0.3 package.
Unfortunately I have no idea how to close this issue.

Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

2021-06-08 Thread John Scott

On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote:
> > I haven't encountered the maintainer previously, but believe in
> > good faith that these changes would be welcome and that the
> > LowThresholdNmu criterion are met by addressing a bug with
> > important severity. My interest in this bug, to introduce a newlib-
> > source binary package, is to unblock my progress on gcc-sh-elf,
> > which is otherwise almost ready.
> Probably still a good idea to CC them or file a bug in the BTS to
> document your intentions, as adding a binary package is not a usual
> change, even if the NMU criterias are fulfilled.
Okay, I made some noise on the bug report today and Cc'ed the debian-
toolchain mailing list on it. I'm not touching the moreinfo tag yet to
give them time to respond.

> Alternatively, you should consider ITS'ing the package.
> At least from your description it sounds as it would be a valid
> candidate, but I didn't check the details.
I do believe it would be a valid candidate, but I don't think it would
be a good idea to salvage it until I get gcc-sh-elf into the archive.
The best way forward for the Newlib package is to only provide a
newlib-source package, and make the respective GCC source packages
(like gcc-sh-elf and gcc-arm-none-eabi) build their own Newlib ports.

For reasons I won't repeat here, this should be best practice, but I am
not yet in a position to where I can assume responsibility for the ARM
packages that are currently built by the Newlib source package.

> please change to experimental. (Its anyway _always_ a good idea to
> clear NEW first via experimental…)
Done.


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

Bug#989621: texlive-latex-extra: incompatible regexpatch.sty version

2021-06-08 Thread Nelson

Package: texlive-latex-extra
Version: 2018.20190227-2
Severity: normal
Tags: upstream

Dear Maintainer,

The latest LaTeX executables (included in texlive-latex-base 2020.20210202-3)
removed some previously deprecated macros. The regexpatch package included in
texlive-latex-extra 2020.20210202-3 is too old and, therefore, fails with this
version of LaTeX. The current version of the package, available at ctan, fixes
this problem. A simple test document:

-
\documentclass{article}
\usepackage{regexpatch}

\def\mycommand{hello}

\xpatchcmd{\mycommand}{hello}{goodbye}{}{}

\begin{document}\mycommand\end{document}
-

Thanks!



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1568 Sep 30  2020 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28  2019 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  1  2019 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  1  2019 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 30  2019 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  1  2019 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  1  2019 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3394 Oct 30  2019 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 30  2019 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-2
ii  python 2.7.16-1
ii  tex-common 6.11
ii  texlive-base   2018.20190227-2
ii  texlive-binaries   2018.20181218.49446-1
ii  texlive-latex-recommended  2018.20190227-2
ii  texlive-pictures   2018.20190227-2

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2018.20190227-2
ii  texlive-plain-generic  2018.20190227-2

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.3.1+dfsg-1+deb10u2
ii  texlive-latex-extra-doc 2018.20190227-2

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.11
ii  texlive-binaries  2018.20181218.49446-1

-- no debconf

Bug#989619: task-kde-desktop: Wrong wallpaper installed on clean installation of Bullseye (Desktop & Lock)

2021-06-08 Thread Philip Hands

Andy Simpkins  writes:

...
> I beleive that this would be an embarissment if we fail to correctly
> theme the default desktop on KDE by bullseye release.
> Note I have also tested GNOME, XFCE, Gnome FlashBack, Cinnamon, Mate,
> LXQt, LXDE all sucessfully.

I can confirm that this is the case with daily builds too:

KDE:
  https://openqa.debian.net/tests/6537#step/_graphical_wait_login/10

vs. Gnome FlashBack (to pick one at random):

  https://openqa.debian.net/tests/6536#step/_graphical_wait_login/11

I had always presumed that the KDE team just preferred to stick with the
KDE styling, so it never occurred to me to report it as a bug.  I think
it's probably right that Debian looks obviously like Debian though.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

signature.asc
Description: PGP signature

Bug#986001: buster-pu: package glib2.0/2.58.3-2+deb10u3

2021-06-08 Thread Adam D. Barratt

Hi,

On Mon, 2021-05-31 at 01:52 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Adam D. Barratt  (2021-05-29):
> > Apologies for letting this fall through the cracks for a while.
> > 
> > As glib2.0 produces a udeb, this will need a KiBi-ack, so CCing and
> > tagging appropriately.
> 
> In the interest of not delaying this any further, I'd probably
> recommend accepting the package into p-u, and if for some reasons
> tests
> look bad when I get to them, I can always exclude prefer the version
> currently in buster through some apt_preferences when building d-i
> for
> 10.10… (And we would have up to 10.11 to find a fix.)
> 
> Would that work for you?

That sounds good to me; thanks.

Simon - please feel free to upload.

Regards,

Adam

Bug#989620: python-softlayer: autopkgtest regression since May 2021: http://something.com 301

2021-06-08 Thread Paul Gevers

Source: python-softlayer
Version: 5.8.5-1
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, since somewhere in May
it started to fail [1]. Looking at the error, it seems an external
resource changed. Can you fix the situation?

By the way, please mark tests that need internet access with the
needs-internet restriction.

Paul

[1] https://ci.debian.net/packages/p/python-softlayer/

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

=== FAILURES
===
_ TestRestAPICall.test_proxy_without_protocol
__
'NoneType' object is not iterable

During handling of the above exception, another exception occurred:
NOTE: Incompatible Exception Representation, displaying natively:

testtools.testresult.real._StringException: Traceback (most recent call
last):
  File
"/tmp/autopkgtest-lxc.q_r49c0h/downtmp/build.H42/src/SoftLayer/transports.py",
line 410, in __call__
message = json.loads(ex.response.text)['error']
  File "/usr/lib/python3.9/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.9/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.q_r49c0h/downtmp/build.H42/src/tests/transport_tests.py",
line 455, in test_proxy_without_protocol
self.assertRaises(SoftLayer.TransportError, self.transport, req)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 489,
in assertRaises
self.assertThat(our_callable, matcher)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 500,
in assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 551,
in _matchHelper
mismatch = matcher.match(matchee)
  File
"/usr/lib/python3/dist-packages/testtools/matchers/_exception.py", line
108, in match
mismatch = self.exception_matcher.match(exc_info)
  File
"/usr/lib/python3/dist-packages/testtools/matchers/_higherorder.py",
line 62, in match
mismatch = matcher.match(matchee)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 479,
in match
reraise(*matchee)
  File "/usr/lib/python3/dist-packages/testtools/_compat3x.py", line 16,
in reraise
raise exc_obj.with_traceback(exc_tb)
  File
"/usr/lib/python3/dist-packages/testtools/matchers/_exception.py", line
101, in match
result = matchee()
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line
1053, in __call__
return self._callable_object(*self._args, **self._kwargs)
  File
"/tmp/autopkgtest-lxc.q_r49c0h/downtmp/build.H42/src/SoftLayer/transports.py",
line 416, in __call__
raise exceptions.SoftLayerAPIError(resp.status_code, str(json_ex))
SoftLayer.exceptions.SoftLayerAPIError: SoftLayerAPIError(404):
Expecting value: line 1 column 1 (char 0)

- Captured stderr call
-
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1):
something.com:80
DEBUG:urllib3.connectionpool:http://something.com:80 "GET
/SoftLayer_Service/Resource.json HTTP/1.1" 301 None
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1):
something.com:443
DEBUG:urllib3.connectionpool:https://something.com:443 "GET
/SoftLayer_Service/Resource.json HTTP/1.1" 404 None
-- Captured log call
---
DEBUGurllib3.connectionpool:connectionpool.py:227 Starting new HTTP
connection (1): something.com:80
DEBUGurllib3.connectionpool:connectionpool.py:452
http://something.com:80 "GET /SoftLayer_Service/Resource.json HTTP/1.1"
301 None
DEBUGurllib3.connectionpool:connectionpool.py:973 Starting new HTTPS
connection (1): something.com:443
DEBUGurllib3.connectionpool:connectionpool.py:452
https://something.com:443 "GET /SoftLayer_Service/Resource.json
HTTP/1.1" 404 None
=== short test summary info

FAILED
tests/transport_tests.py::TestRestAPICall::test_proxy_without_protocol
== 1 failed, 1480 passed, 4 skipped in 13.07s
==



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989500: unblock eyed3/0.8.10-4

2021-06-08 Thread Paul Gevers

Control: tags -1 moreinfo

Hi

On Sat, 5 Jun 2021 15:06:31 +0200 Gaetano Guerriero 
wrote:
> Please unblock package eyed3

I haven't looked at the diff yet, but...

> Package is not blocked, but it is marked for removal from
> testing on 16 Jun and the auto migration period expires on 22 Jun.

I have pinged the RC bug. That should reset the autoremoval timer, so
the package should migrate on its own.

Don't hesitate to remove the moreinfo tag if you're seeing issues.

Paul

OpenPGP_signature
Description: OpenPGP digital signature

Bug#989602: dpkg-deb overwrites symlinks with directories

On Tue, Jun 08, 2021 at 05:34:57PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> dpkg-deb --fsys-tarfile dpkg*.deb | tar -C / --keep-directory-symlink 
> --extract --file -

That is totally unintuitive, though.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#989509: klibc 2.0.6-1+deb10u1 flagged for acceptance

package release.debian.org
tags 989509 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: klibc
Version: 2.0.6-1+deb10u1

Explanation: malloc: Set errno on failure; fix several overflow issues 
[CVE-2021-31873 CVE-2021-31870 CVE-2021-31872]; cpio: Fix possible crash on 
64-bit systems [CVE-2021-31871]; {set,long}jmp [s390x]: save/restore the 
correct FPU registers

Bug#989420: isc-dhcp 4.4.1-2+deb10u1 flagged for acceptance

package release.debian.org
tags 989420 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: isc-dhcp
Version: 4.4.1-2+deb10u1

Explanation: fix buffer overrun issue [CVE-2021-25217]

Bug#988974: fig2dev 3.2.7a-5+deb10u4 flagged for acceptance

package release.debian.org
tags 988974 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.7a-5+deb10u4

Explanation: fix buffer overflow [CVE-2021-3561]; several output fixes; rebuild 
testsuite during build and in autopkgtest

Bug#988453: rust-rustyline 3.0.0-2+deb10u1 flagged for acceptance

package release.debian.org
tags 988453 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rust-rustyline
Version: 3.0.0-2+deb10u1

Explanation: fix build with newer rustc

Bug#988936: mqtt-client 1.14-1+deb10u1 flagged for acceptance

package release.debian.org
tags 988936 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: mqtt-client
Version: 1.14-1+deb10u1

Explanation: fix denial of service issue [CVE-2019-0222]

Bug#987725: nvidia-graphics-drivers 418.197.02-1 flagged for acceptance

package release.debian.org
tags 987725 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 418.197.02-1

Explanation: fix improper access control vulnerability [CVE‑2021‑1076]

Bug#987726: nvidia-graphics-drivers-legacy-390xx 390.143-1~deb10u1 flagged for acceptance

package release.debian.org
tags 987726 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-legacy-390xx
Version: 390.143-1~deb10u1

Explanation: fix improper access control vulnerability [CVE‑2021‑1076]; fix 
installation failure on Linux 5.11 release candidates

Bug#989619: task-kde-desktop: Wrong wallpaper installed on clean installation of Bullseye (Desktop & Lock)

2021-06-08 Thread Andy Simpkins

Package: task-kde-desktop
Version: 3.67
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   Testing Weekly builds of DI ready for release  (build 2021-06-07)
   
  * What exactly did you do (or not do) that was effective (or
   ineffective)?
   Clean installation into seporate VMs of all installation
media.  Only
KDE desktop is affected.  All other desktops correctly install and
select the 'Homeworld' wallpaper and lock screens.


   * What was the outcome of this action?
   KDE desktopinstallation had 'shell' as default walpaper and as
   'lockscreen'
   
  * What outcome did you expect instead?
  I expected to see 'Homeworld' as the default wallpaper and lock
screen
- it wasn't 'shell' was set as the default.
Homeworld was installed, just not as the active setting
Login screen correctly showed 'homeworld'


I beleive that this would be an embarissment if we fail to correctly
theme the default desktop on KDE by bullseye release.
Note I have also tested GNOME, XFCE, Gnome FlashBack, Cinnamon, Mate,
LXQt, LXDE all sucessfully.

/RattusRattus

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

Bug#989618: unblock: libwebp/0.6.1-2.1

2021-06-08 Thread Moritz Muehlenhoff

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

Please unblock libwebp and age it to five days.

It fixes all open security issues. There is RC #914315
about updating to a new version, but bumping to 1.2.0
is obviously not a solution at this time of the freeze.
Still I think the RC bugs should stay open (bookworm
definitely must not release with 0.6 :-), so please tag it
bullseye-ignore.

unblock libwebp/0.6.1-2.1

Cheers,
Moritz

Debdiff:

diff -Nru libwebp-0.6.1/debian/changelog libwebp-0.6.1/debian/changelog
--- libwebp-0.6.1/debian/changelog  2018-03-01 21:51:06.0 +0100
+++ libwebp-0.6.1/debian/changelog  2021-06-05 19:35:57.0 +0200
@@ -1,3 +1,12 @@
+libwebp (0.6.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix multiple security issues: CVE-2018-25009, CVE-2018-25010, 
CVE-2018-25011
+CVE-2020-36328, CVE-2018-25013, CVE-2018-25014, CVE-2020-36329, 
CVE-2020-36330
+CVE-2020-36331, CVE-2020-36332
+
+ -- Moritz Muehlenhoff   Sat, 05 Jun 2021 19:35:57 +0200
+
 libwebp (0.6.1-2) unstable; urgency=medium
 
   * Fix lintian warning on manpage
diff -Nru libwebp-0.6.1/debian/patches/security-fixes.patch 
libwebp-0.6.1/debian/patches/security-fixes.patch
--- libwebp-0.6.1/debian/patches/security-fixes.patch   1970-01-01 
01:00:00.0 +0100
+++ libwebp-0.6.1/debian/patches/security-fixes.patch   2021-06-05 
19:34:56.0 +0200
@@ -0,0 +1,355 @@
+Patches for the following CVE IDs:
+
+CVE-2018-25009
+CVE-2018-25010
+CVE-2018-25011
+CVE-2020-36328
+CVE-2018-25013
+CVE-2018-25014
+CVE-2020-36329
+CVE-2020-36330
+CVE-2020-36331
+CVE-2020-36332
+
+Comprised of the following upstream commits:
+1344a2e947c749d231141a295327e5b99b444d63
+2c70ad76c94db5427d37ab4b85dc89b94dd75e01
+39cb9aad85ca7bb1d193013460db1f8cc6bff109
+569001f19fc81fcb5ab358f587a54c62e7c4665c
+907208f97ead639bd521cf355a2f203f462eade6
+95fd65070662e01cc9170cf5c0859a710097
+be738c6d396fa5a272c1b209be4379a7532debfe
+dad31750e374eff8e02fb467eb562d4bf236ed6e
+dce5d7643177633ebe3513af492ea8c08c299cf3
+eb82ce76ddca13ad6fb13376bb58b9fd3f850e9e
+
+--- libwebp-0.6.1.orig/src/dec/buffer_dec.c
 libwebp-0.6.1/src/dec/buffer_dec.c
+@@ -74,7 +74,8 @@ static VP8StatusCode CheckDecBuffer(cons
+   } else {// RGB checks
+ const WebPRGBABuffer* const buf = &buffer->u.RGBA;
+ const int stride = abs(buf->stride);
+-const uint64_t size = MIN_BUFFER_SIZE(width, height, stride);
++const uint64_t size =
++MIN_BUFFER_SIZE(width * kModeBpp[mode], height, stride);
+ ok &= (size <= buf->size);
+ ok &= (stride >= width * kModeBpp[mode]);
+ ok &= (buf->rgba != NULL);
+--- libwebp-0.6.1.orig/src/dec/idec_dec.c
 libwebp-0.6.1/src/dec/idec_dec.c
+@@ -283,10 +283,8 @@ static void RestoreContext(const MBConte
+ 
+ static VP8StatusCode IDecError(WebPIDecoder* const idec, VP8StatusCode error) 
{
+   if (idec->state_ == STATE_VP8_DATA) {
+-VP8Io* const io = &idec->io_;
+-if (io->teardown != NULL) {
+-  io->teardown(io);
+-}
++// Synchronize the thread, clean-up and check for errors.
++VP8ExitCritical((VP8Decoder*)idec->dec_, &idec->io_);
+   }
+   idec->state_ = STATE_ERROR;
+   return error;
+@@ -473,6 +471,12 @@ static VP8StatusCode DecodeRemaining(Web
+ MemDataSize(&idec->mem_) > MAX_MB_SIZE) {
+   return IDecError(idec, VP8_STATUS_BITSTREAM_ERROR);
+ }
++// Synchronize the threads.
++if (dec->mt_method_ > 0) {
++  if (!WebPGetWorkerInterface()->Sync(&dec->worker_)) {
++return IDecError(idec, VP8_STATUS_BITSTREAM_ERROR);
++  }
++}
+ RestoreContext(&context, dec, token_br);
+ return VP8_STATUS_SUSPENDED;
+   }
+--- libwebp-0.6.1.orig/src/dec/vp8l_dec.c
 libwebp-0.6.1/src/dec/vp8l_dec.c
+@@ -362,12 +362,19 @@ static int ReadHuffmanCodes(VP8LDecoder*
+   VP8LMetadata* const hdr = &dec->hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
++  // When reading htrees, some might be unused, as the format allows it.
++  // We will still read them but put them in this htree_group_bogus.
++  HTreeGroup htree_group_bogus;
+   HuffmanCode* huffman_tables = NULL;
++  HuffmanCode* huffman_tables_bogus = NULL;
+   HuffmanCode* next = NULL;
+   int num_htree_groups = 1;
++  int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+   int* code_lengths = NULL;
+   const int table_size = kTableSize[color_cache_bits];
++  int* mapping = NULL;
++  int ok = 0;
+ 
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+@@ -384,10 +391,42 @@ static int ReadHuffmanCodes(VP8LDecoder*
+   // The huffman data is stored in red and green bytes.
+   const int group = (huffman_image[i] >> 8) & 0x;
+   huffman_image[i] = group;
+-  if (group >= num_htree_groups) {
+-num_htree_groups = group + 1;
++

Bug#989593: installation report Raspberry Pi 4 UEFI

On Tue, Jun 08, 2021 at 09:27:57PM +0200, Holger Wansing wrote:
> I checked with rc1 and the *brandnew* rc2 netinst images on amd64 qemu
> VM machine (text installer), and I cannot reproduce such issue with wrong 
> keyboard layout; German is correctly available immediately after the 
> "Configure keyboard" step.
> 
> So, I guess that a Pi-specific thingy somehow.

On the Pi, keyboard-configuration, console-data etc only seem to get
installed at the end of the "installing the base system" step, after
which the keyboard setting works.

The more pressing issue IMO is the deletion of /sbin/start-stop-daemon.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#989495: bluez: diff for NMU version 5.55-3.1

Control: tags 989495 + patch
Control: tags 989495 + pending
Control: tags 989614 + patch
Control: tags 989614 + pending

Dear maintainer,

I've prepared an NMU for bluez (versioned as 5.55-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru bluez-5.55/debian/changelog bluez-5.55/debian/changelog
--- bluez-5.55/debian/changelog	2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/changelog	2021-06-08 21:34:10.0 +0200
@@ -1,3 +1,12 @@
+bluez (5.55-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * main: Don't warn for unset config option (Closes: #989495)
+  * shared/gatt-server: Fix not properly checking for secure flags
+(CVE-2020-26558, CVE-2021-0129) (Closes: #989614)
+
+ -- Salvatore Bonaccorso   Tue, 08 Jun 2021 21:34:10 +0200
+
 bluez (5.55-3) unstable; urgency=medium
 
   * Add d/salsa-ci.yml.
diff -Nru bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch
--- bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch	1970-01-01 01:00:00.0 +0100
+++ bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch	2021-06-08 21:34:10.0 +0200
@@ -0,0 +1,23 @@
+From: Luiz Augusto von Dentz 
+Date: Mon, 9 Nov 2020 14:57:56 -0800
+Subject: main: Don't warn for unset config option
+Origin: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=02e46e9df6b0d897e6ba67dc3ea18e5e9c510e44
+Bug-Debian: https://bugs.debian.org/989495
+Bug: https://github.com/bluez/bluez/issues/51
+
+Unset options shall not be printed if debug is not enabled.
+---
+ src/main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/main.c
 b/src/main.c
+@@ -444,7 +444,7 @@ static void parse_controller_config(GKey
+ 		int val = g_key_file_get_integer(config, "Controller",
+ 		params[i].val_name, &err);
+ 		if (err) {
+-			warn("%s", err->message);
++			DBG("%s", err->message);
+ 			g_clear_error(&err);
+ 		} else {
+ 			info("%s=%d", params[i].val_name, val);
diff -Nru bluez-5.55/debian/patches/series bluez-5.55/debian/patches/series
--- bluez-5.55/debian/patches/series	2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/patches/series	2021-06-08 21:34:10.0 +0200
@@ -10,3 +10,5 @@
 shared-gatt-client-Fix-segfault-after-PIN-entry.patch
 main.conf-Add-more-details-Closes-904212.patch
 headers-use-releative-symlinks.patch
+main-Don-t-warn-for-unset-config-option.patch
+shared-gatt-server-Fix-not-properly-checking-for-sec.patch
diff -Nru bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch
--- bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch	1970-01-01 01:00:00.0 +0100
+++ bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch	2021-06-08 21:34:10.0 +0200
@@ -0,0 +1,108 @@
+From: Luiz Augusto von Dentz 
+Date: Tue, 2 Mar 2021 11:38:33 -0800
+Subject: shared/gatt-server: Fix not properly checking for secure flags
+Origin: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit?id=00da0fb4972cf59e1c075f313da81ea549cb8738
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-26558
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-0129
+Bug-Debian: https://bugs.debian.org/989614
+
+When passing the mask to check_permissions all valid permissions for
+the operation must be set including BT_ATT_PERM_SECURE flags.
+---
+ src/shared/att-types.h   |  8 
+ src/shared/gatt-server.c | 25 +++--
+ 2 files changed, 15 insertions(+), 18 deletions(-)
+
+diff --git a/src/shared/att-types.h b/src/shared/att-types.h
+index 7108b4e94ab3..3adc05d9e357 100644
+--- a/src/shared/att-types.h
 b/src/shared/att-types.h
+@@ -129,6 +129,14 @@ struct bt_att_pdu_error_rsp {
+ #define BT_ATT_PERM_WRITE_SECURE	0x0200
+ #define BT_ATT_PERM_SECURE		(BT_ATT_PERM_READ_SECURE | \
+ 	BT_ATT_PERM_WRITE_SECURE)
++#define BT_ATT_PERM_READ_MASK		(BT_ATT_PERM_READ | \
++	BT_ATT_PERM_READ_AUTHEN | \
++	BT_ATT_PERM_READ_ENCRYPT | \
++	BT_ATT_PERM_READ_SECURE)
++#define BT_ATT_PERM_WRITE_MASK		(BT_ATT_PERM_WRITE | \
++	BT_ATT_PERM_WRITE_AUTHEN | \
++	BT_ATT_PERM_WRITE_ENCRYPT | \
++	BT_ATT_PERM_WRITE_SECURE)
+ 
+ /* GATT Characteristic Properties Bitfield values */
+ #define BT_GATT_CHRC_PROP_BROADCAST			0x01
+diff --git a/src/shared/gatt-server.c b/src/shared/gatt-server.c
+index b5f7de7dc3d9..970c35f94e51 100644
+--- a/src/shared/gatt-server.c
 b/src/shared/gatt-server.c
+@@ -444,9 +444,7 @@ static void process_read_by_type(struct async_read_op *op)
+ 		return;
+ 	}
+ 
+-	ecode = check_permissions(server, attr, BT_ATT_PERM_READ |
+-		BT_ATT_PERM_READ_AUTHEN |
+-		BT_ATT_PERM_READ_ENCRYPT);
++	ecode = check_p

Bug#989617: cimg-doc: cimg -- Fails to build reproducibly

2021-06-08 Thread Nilesh Patra

Package: cimg-doc
Version: 2.9.4+dfsg-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: nil...@debian.org, reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

cimg vendors a few docs which are non deterministic in nature.
However on tweaking around, it looks like those few files are not really
needed, hence removing them makes it reproducible.

I have already committed to
salsa(https://salsa.debian.org/science-team/cimg/-/commit/51931c53791d4958a04a9a5bb4dce1733f48ce25)
and will upload post bullseye release.
Pasting the patch too

--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ override_dh_install:
sed -i "s?#define cimg_plugin \"examples/$$file\"?#define 
cimg_plugin \"$$file\"?" $$file ; \
done
mv html/reference/* debian/$(doc)/usr/share/doc/cimg-dev/html
+   find debian -type f -name "_form*" -delete

 override_dh_auto_clean:
-cd examples && $(MAKE) clean


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

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

Versions of packages cimg-doc depends on:
ii  libjs-jquery  3.5.1+dfsg-4

cimg-doc recommends no packages.

cimg-doc suggests no packages.

Bug#909473: fstrim shows incorrect trimmed size after reboot

2021-06-08 Thread Bastian Blank

Hi

On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:
> > > There is definitely something boggus here
> Yes, just tested it now and  it's still happening with the kernel currently
> in unstable (5.10.40-1)

Why do you think this numbers are wrong?  "fstrim" initially requests
discard of all unused blocks, so a large number.  But why should it do
the same on subsequent calls while it still knows what it did the last
time?

ext4 caches the information if a particular block group was trimmed, but
this information is not persistent.  (Using bit
EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)

Bastian

-- 
Live long and prosper.
-- Spock, "Amok Time", stardate 3372.7

Bug#989616: netbeans: Package exists (as source only?) but not installable

[Big disclaimer: I'm not the maintainer but spotted the RC bug filled]

Hi,

On Tue, Jun 08, 2021 at 03:32:18PM -0400, benjamin melançon wrote:
> Source: netbeans
> Version: 12.1-3
> Severity: serious
> Tags: d-i ftbfs
> Justification: fails to build from source
> X-Debbugs-Cc: ben+deb...@agaric.coop
> 
> Dear Maintainer,
> 
> Trying to install Netbeans i thought i found it in testing (bullseye) -
> https://packages.debian.org/source/stretch/netbeans
> 
> I know realize that's only the 'source', but i feel that if there is no
> corresponding actual package some explanation should be identifiable on the
> source page.
> 
> Moreover the tracker makes it look like everything is OK:
> https://tracker.debian.org/pkg/netbeans
> 
> So, i'm trying to figure out how to 'sudo apt install netbeans' -- having that
> work, of course, would be fantastic, if there's just one minor hiccup with
> producing the package.
> 
> But i'm also hoping that messages on packages.debian.org, in apt, and in the
> Software app can be improved.  Status and next steps being clear to all would
> be very helpful for both users and potential contributors.

See the changelog entry from 12.1-1:

netbeans (12.1-1) unstable; urgency=medium

  * Only build libnb-absolutelayout-java from now on. Drop netbeans and Co
because it is not viable to maintain the editor in Debian. We recommend to
install the flatpack version from flathub instead.
(Closes: #925509, #929561, #960692, #815028, #805769, #920706, #922190)
(Closes: #960749, #653132, #877626, #935008)
  * Remove Andrew Ross from Uploaders. He is not active anymore.

 -- Markus Koschany   Sat, 03 Oct 2020 22:51:24 +0200

So this was on purpose.

Regards,
Salvatore

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

Am 08.06.2021 um 19:05 schrieb Matt Corallo:

On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.

Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?

Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login 
session.

I admit I am definitely not a systemd expert (which I suppose should be 
obvious by now :) ), so have no idea what this means, and systemd-run's 
man page doesn't really elucidate it. Not Debian's or your problem, of 
course, though.

If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that 
process.

Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other distros 
are patching systemd or changing cgroup settings such that interacting 
with systemd isn't required.

Similar to the discussion in 825394, having daemons  spontaneously 
killed is incredibly surprising, maybe it makes sense to enable-linger 
by default?

 > Did you use systemd-run in buster to start your lxc containers?
 > You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.

No, but also didn't need to, its only with bullseye that (systemd's ?) 
cgroup settings prevent direct calls to lxc-start, which is what makes 
the whole thing such a mess - one cannot simply call lxc functions 
anymore because systemd gets in the way. Using systemd for this, sadly, 
is an excercize in puzzling through man pages and lack of documentation 
for how to do any of this (half of the lxc docs for how to do this are 
because I had to ask lxc maintainers how to do basic lxc things with 
bullseye).

Antonio, Stéphane, do you have any input how we can improve the 
situation here?

A short summary: Debian bullseye switched to cgroupv2 which now makes it 
necessary to run lxc-start as unprivileged user via "systemd-run -p 
Delegate=yes".
This in turn makes the lxc processes part of the systemd --user session, 
not the login session. Which in turn requires "linger" to enable daemon 
processes to persist once a user logs out.

Maybe I missed something and linger is the only option in this case (and 
lxc's README.Debian could have a note about this). Or maybe there is a 
different way to achieve what Matt is trying to do?

Michael

OpenPGP_signature
Description: OpenPGP digital signature

Bug#989616: netbeans: Package exists (as source only?) but not installable

2021-06-08 Thread benjamin melançon

Source: netbeans
Version: 12.1-3
Severity: serious
Tags: d-i ftbfs
Justification: fails to build from source
X-Debbugs-Cc: ben+deb...@agaric.coop

Dear Maintainer,

Trying to install Netbeans i thought i found it in testing (bullseye) -
https://packages.debian.org/source/stretch/netbeans

I know realize that's only the 'source', but i feel that if there is no
corresponding actual package some explanation should be identifiable on the
source page.

Moreover the tracker makes it look like everything is OK:
https://tracker.debian.org/pkg/netbeans

So, i'm trying to figure out how to 'sudo apt install netbeans' -- having that
work, of course, would be fantastic, if there's just one minor hiccup with
producing the package.

But i'm also hoping that messages on packages.debian.org, in apt, and in the
Software app can be improved.  Status and next steps being clear to all would
be very helpful for both users and potential contributors.

Thank you!!!

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

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

Bug#989615: intel-microcode: CVE-2020-24511 CVE-2020-24512 CVE-2020-24513 CVE-2021-24489 (INTEL-SA-00464, INTEL-SA-00465, INTEL-SA-00442)

Source: intel-microcode
Version: 3.20210216.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20200609.2~deb10u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2020-24511[0] (INTEL-SA-00464), CVE-2020-24512[1]
(INTEL-SA-00464), CVE-2020-24513[2] (INTEL-SA-00465),
CVE-2021-24489[3] (INTEL-SA-00442).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-24511
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24511
[1] https://security-tracker.debian.org/tracker/CVE-2020-24512
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24512
[2] https://security-tracker.debian.org/tracker/CVE-2020-24513
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24513
[3] https://security-tracker.debian.org/tracker/CVE-2021-24489
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-24489
[4] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20210608

Regards,
Salvatore

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

Hi,

On Tue, Jun 08, 2021 at 08:01:49PM +0300, Михаил Осипов wrote:
>  > What led up to the situation?
> I have updated linux-image-amd64 to 5.10.0.7-amd64.
> 
> > What exactly did you do (or not do) that was effective (or ineffective)?
> Loaded laptop with new kernel.
> 
> > What was the outcome of this action?
> Boot freeze.
> 
> > What outcome did you expect instead?
> Normal boot.

Yes that is somehow clear ;-)

Did you see my question below?

> > I'm assuming here it is relating to the
> > https://lists.debian.org/debian-kernel/2021/06/msg00066.html report,
> > thus adjusting the found version to 5.10.38-1.
> >
> > Mikhail, we have only litte information here to sensibly tackle the
> > problem.
> >
> > When you boot 5.10.38-1 do you get any usefull information logged in
> > the logs? Can you attach those to the bug?
> >
> > Please try to boot without quiet (and splash), do you get more
> > information printed and indication where it hangs?

Is the system in such a state that you can get to those? (and if not
after a boot with the old kernel, do you find at least part of that
information swritten to the logs)?

Regards,
Salvatore

Bug#989614: bluez: CVE-2021-0129 CVE-2020-26558

Source: bluez
Version: 5.55-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for bluez.

CVE-2021-0129[0], and

CVE-2020-26558[1]:
| Bluetooth LE and BR/EDR secure pairing in Bluetooth Core Specification
| 2.1 through 5.2 may permit a nearby man-in-the-middle attacker to
| identify the Passkey used during pairing (in the Passkey
| authentication procedure) by reflection of the public key and the
| authentication evidence of the initiating device, potentially
| permitting this attacker to complete authenticated pairing with the
| responding device using the correct Passkey for the pairing session.
| The attack methodology determines the Passkey value one bit at a time.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-0129
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0129
[1] https://security-tracker.debian.org/tracker/CVE-2020-26558
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26558
[2] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00517.html
[3] 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=00da0fb4972cf59e1c075f313da81ea549cb8738

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 08.06.2021 um 20:12 schrieb Matt Corallo:



On 6/8/21 14:02, Michael Biebl wrote:
Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other 
distros are patching systemd or changing cgroup settings such that 
interacting with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?


No, I'm not sure, but that was the response any time I mentioned 
systemd-run was immediately "I assume Debian bullseye or something". Its 
possible it also impacts fedora and the Ubuntu folks just have some 
crazy workaround that doesn't really make sense.


lxc fiddles with cgroups. In cgroupv2 [1] mode, there can only be a 
single manager of the cgroup hierarchy. In a systemd based system, this 
is PID 1, i.e. systemd.


Which is why lxc needs to delegate this to systemd in bullseye.
I thought Ubuntu was following Debian here, but apparently they deviate 
here [2].


Sooner or later they'll switch to cgroupv2 as well, as cgroupv1 is 
basically dead.


Michael


[1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
[2] 
https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/rules?h=ubuntu/impish#n70




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

2021-06-08 Thread Gunnar Hjalmarsson


On 2021-06-07 08:51, Shengjing Zhu wrote:

On Mon, Jun 07, 2021 at 08:04:14AM +0200, Gunnar Hjalmarsson wrote:

How about uploading the "fcitx5" -> "fcitx" change to experimental
for now? And possibly upload to bullseye soon after the release of
Debian 11.


Yes, please. And after release, the change could be updated in
unstable ASAP to get more feedback from users.


I sync'ed im-config 0.47-1 to Ubuntu impish (coming 21.10), and asked 
the Ubuntu Kylin folks to test fcitx 5 and report back if they run into 
issues.


https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1928360/comments/27

--
Gunnar

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 07.06.2021 um 21:20 schrieb Matt Corallo:
Is there any further information I can provide to help debug this (or 
should it get a -moreinfo)?


Note that of interest may be that the workaround of spawning in a screen 
session only works if lxc-start is passed the -F command which places it 
in the foreground (though sshd still gets the -D option running inside 
the container).



Let me elaborate a bit more what's happening here.

A systemd --user session (user session) is typically tied to a login 
session. As long as you have 1 (or more) login sessions you have a 
single (reference counted) user session.
Once the last login session stops (has no more processes) the associated 
user session is stopped as well (unless you enabled lingering [1]).


Now, if you start a screen session inside your login session, you 
artifically keep your login session alive after loggin out 
(KillUserProcesses=no prevents screen from being killed).


As a result, your user session also kept alive as well.

Hope this clarifies.

Michael


[1] Linger will start the user session when the system boots and keep it 
always active. Which is why it's not a good idea to enable this globally.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

2021-06-08 Thread Matt Corallo





On 6/8/21 14:02, Michael Biebl wrote:
Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks 
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing 
cgroup settings such that interacting with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?


No, I'm not sure, but that was the response any time I mentioned systemd-run was immediately "I assume Debian bullseye 
or something". Its possible it also impacts fedora and the Ubuntu folks just have some crazy workaround that doesn't 
really make sense.


Similar to the discussion in 825394, having daemons  spontaneously killed is incredibly surprising, maybe it makes 
sense to enable-linger by default?


That's not a good idea I think.
Starting long running daemons from a user session is not the norm, I'd argue.


Would defer to you, I've never seen systemd-run used or mentioned anywhere 
outside of lxc.


In any case, I'm not sure there remains anything to be done on the systemd 
side. Afaics, everything behaves as documented.


Sounds good.

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

2021-06-08 Thread Tobias Frost

On Tue, Jun 08, 2021 at 02:50:47PM +0800, clay stan wrote:
> Tobias Frost  于2021年6月3日周四 上午1:33写道：
> >
> > Control: tags -1 moreinfo
> >
> > Hi Clay,
> >
> > here's a review:
> > - The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is not
> >   related to the patch
> 
> Thanks, I've updated.
> 
> > - The patch looks strange to me: Why do you patch the Makefile? What do you
> >   want to archieve? Parts of the patching seems ok (like avoiding stomping 
> > over
> > CFLAGS, but other parts seems excessive, removing sane parts to me…
> 
> The original compilation parameters will also cause Lintian to report errors,
> hardening no bind now, hardening no mandatory functions.
> I'll try to solve them in debian/rules by
> https://wiki.debian.org/Hardening, but it doesn't work
> 
>and the sane parts, you mean?

You've basically completly rewritten a (mostly) working Makefile
With your comment I assume that you just wanted to have hardening,
so _just_ those parts should have been patched.
And that would be:

--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 CC ?= gcc

-CFLAGS+=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99
+CFLAGS:=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99 
${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
 SANITY_FLAGS=-Wfloat-equal -Wshadow -Wpointer-arith

 PREFIX ?= /usr

(+ adding export DEB_BUILD_MAINT_OPTIONS = hardening=+all to d/rules)

So, see it as recommendation: I'd keep patches really minimal. Or they
will create you a lot of work…

It is a burden to carry such an intrusive patch, especially if upstream
explictly expressed that he does not generally welcome patches
if they target the Makefile.

Just one example where I think the upstream part is better:
-PREFIX ?= /usr
+PREFIX = /usr

Some other stuff could be done with debhelper overrides, so
that the patch can get smaller…

But you do you… I just strongly recommend to revisit the topic.
On top, non-upstreamable patches are bad…

> >   - Upstream seems to support arm, you patch that out?
> 
> Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek,
> not arm PC, They are not supported by Debian.

This is not a strong reason to disable arm support entirely…
(A quick internet search suggests that there is some support for Debian on e.g
Snapdragon. And there seems to be derivates; even if not, maybe someone wants
to enhance cpufetch on the basis of the Debian package.)

> >   - There is no LDCFLAGS -> did you mean LDFLAGS?
> 
> Yeah, I've updated. Thanks again.
> 
> >
> > - (not a blocker) Please send the manpage upstream for inclusion.

Regarding the manpage: I've diffed the manpage (cpufetch.1 and
debian/cpufetch.1). They are almost identical. With just small fixes done by
you. However, you claim (sole) copyright on it. That is not appropiate.

I would patch the manpage, if it needs fixing: The header of the upstream ones
says that upstream builds it using help2man (but hav not integrated that into
their Makefile), so possibly this is another route to go: Rebuild at build
time.

-- 
tobi

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

Am 08.06.2021 um 19:05 schrieb Matt Corallo:

On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.

Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?

Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login 
session.

I admit I am definitely not a systemd expert (which I suppose should be 
obvious by now :) ), so have no idea what this means, and systemd-run's 
man page doesn't really elucidate it. Not Debian's or your problem, of 
course, though.

If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that 
process.

Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other distros 
are patching systemd or changing cgroup settings such that interacting 
with systemd isn't required.

Are you sure? Which distros are that? Which exact version of that distro?

Similar to the discussion in 825394, having daemons  spontaneously 
killed is incredibly surprising, maybe it makes sense to enable-linger 
by default?

That's not a good idea I think.
Starting long running daemons from a user session is not the norm, I'd 
argue.

 > Did you use systemd-run in buster to start your lxc containers?
 > You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.

No, but also didn't need to, its only with bullseye that (systemd's ?) 
cgroup settings prevent direct calls to lxc-start, which is what makes 
the whole thing such a mess - one cannot simply call lxc functions 
anymore because systemd gets in the way. Using systemd for this, sadly, 
is an excercize in puzzling through man pages and lack of documentation 
for how to do any of this (half of the lxc docs for how to do this are 
because I had to ask lxc maintainers how to do basic lxc things with 
bullseye).

bullseye changed to cgroupv2 (see systemd's NEWS entry [1]). Other 
distros (like Fedora) made that switch a while ago

Maybe the best that can be done here is to document in lxc's 
README.Debian, that if you use unprivileged containers and you use 
systemd-run, you should also use linger if you want those daemons to 
persist.

In any case, I'm not sure there remains anything to be done on the 
systemd side. Afaics, everything behaves as documented.

Michael

[1] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.NEWS#L1

OpenPGP_signature
Description: OpenPGP digital signature

Bug#895201: trousers uninstallable / postinst relaxing / fixes

2021-06-08 Thread Dan Bungert

One note on the suggested fix from Florian:

I don't think we can use shopt with bare /bin/sh, so the suggested
change to the init script will also fail with an error.

I ended up using:

  if [ "$(echo /dev/tpm*)" != "/dev/tpm*" ]

which is good enough for my usage but I have not tested it further.

-Dan

Bug#989605: mirror submission for mirror.alwyzon.net

2021-06-08 Thread Michael Hohl

Hi!

Sure, I'm just not sure why you would think that Alwyzon.com runs on one 
Nameserver? There are two nameservers, ns1.alwyzon.net and ns3.alwyzon.net (for 
historical reasons, there is no longer a ns2). Both have IPv4 addresses 
assigned and run in geographically separate locations (Austria and the 
Netherlands):

> dig alwyzon.com NS

; <<>> DiG 9.10.6 <<>> alwyzon.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22643
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;alwyzon.com.   IN  NS

;; ANSWER SECTION:
alwyzon.com.86400   IN  NS  ns1.alwyzon.net.
alwyzon.com.86400   IN  NS  ns3.alwyzon.net.

;; Query time: 47 msec
;; SERVER: 2a0d:f302:100::100#53(2a0d:f302:100::100)
;; WHEN: Tue Jun 08 17:57:45 CEST 2021
;; MSG SIZE  rcvd: 87

> host ns1.alwyzon.net
ns1.alwyzon.net has address 193.219.97.6
ns1.alwyzon.net has IPv6 address 2a0d:f300::6

> host ns3.alwyzon.net
ns3.alwyzon.net has address 46.102.157.71
ns3.alwyzon.net has IPv6 address 2a0d:f302:101:1a2a::1

Regards,
Michael

Btw. your mail setup seems a bit off: the email has a "Reply-To: Debian Mirror 
Team <989...@debian.org>" header set, but that address doesn't seem to exist. I 
got a "550 unroutable address" from "mailly.debian.org[82.195.75.114]". If you 
are receiving this mail, I assume it should be "989...@bugs.debian.org" (just a 
guess as that was the sender domain used for the system notifications and used 
by your mail as Cc).

On 08.06.21, 17:49, "Peter Palfrader"  wrote:

Hi!

On Tue, 08 Jun 2021, Alwyzon wrote:

> Submission-Type: new
> Site: mirror.alwyzon.net
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Alwyzon 
> Country: AT Austria
> Location: Vienna
> Sponsor: Alwyzon https://www.alwyzon.com/

Can you tell us a bit more about your DNS setup?

It seems alwyzon.com only has a single IPv4 nameserver, and both
nameservers share the same IPv6 address.  How does the dns service for
this domain provide availability against spof?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

2021-06-08 Thread Matt Corallo

On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at
some point while testing set-linger before, sorry for the noise here.

Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the
default behavior should be that things aren't automatically killed in the background? Is that something that was an
intentional change?

Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login session.

I admit I am definitely not a systemd expert (which I suppose should be obvious by now :) ), so have no idea what this
means, and systemd-run's man page doesn't really elucidate it. Not Debian's or your problem, of course, though.

If you start a process as part of a user session (which is what systemd-run --user does), ending that user session will
stop that process.

Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing
cgroup settings such that interacting with systemd isn't required.

Similar to the discussion in 825394, having daemons spontaneously killed is incredibly surprising, maybe it makes sense
to enable-linger by default?

> Did you use systemd-run in buster to start your lxc containers?
> You need to be very explicit, otherwise I can only guess what exactly you
were/are doing.

No, but also didn't need to, its only with bullseye that (systemd's ?) cgroup settings prevent direct calls to
lxc-start, which is what makes the whole thing such a mess - one cannot simply call lxc functions anymore because
systemd gets in the way. Using systemd for this, sadly, is an excercize in puzzling through man pages and lack of
documentation for how to do any of this (half of the lxc docs for how to do this are because I had to ask lxc
maintainers how to do basic lxc things with bullseye).

Thanks,
Matt

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

2021-06-08 Thread Михаил Осипов

 > What led up to the situation?
I have updated linux-image-amd64 to 5.10.0.7-amd64.

> What exactly did you do (or not do) that was effective (or ineffective)?
Loaded laptop with new kernel.

> What was the outcome of this action?
Boot freeze.

> What outcome did you expect instead?
Normal boot.

P.S. Laptop Lenovo Ideapad 5 14ARE05.
-
С уважением, Михаил Осипов.


пн, 7 июн. 2021 г. в 14:38, Salvatore Bonaccorso :

> Control: notfound -1 5.10.28-1
> Control: found -1 5.10.38-1
> Control: tags -1 + moreinfo
>
> On Mon, Jun 07, 2021 at 02:09:20PM +0300, Mikhail Osipov wrote:
> > Package: src:linux
> > Version: 5.10.28-1
> > Severity: important
> > X-Debbugs-Cc: osm...@gmail.com
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
>
> I'm assuming here it is relating to the
> https://lists.debian.org/debian-kernel/2021/06/msg00066.html report,
> thus adjusting the found version to 5.10.38-1.
>
> Mikhail, we have only litte information here to sensibly tackle the
> problem.
>
> When you boot 5.10.38-1 do you get any usefull information logged in
> the logs? Can you attach those to the bug?
>
> Please try to boot without quiet (and splash), do you get more
> information printed and indication where it hangs?
>
> Regards,
> Salvatore
>

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

2021-06-08 Thread Thomas Landauer


Yeah, sorry, I forgot that.

BTW: The setting is `preserve_message_logs`, see 
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html#SECID260


You can close this (I don't know how to...)

Cheers,
Thomas

Am 08.06.21 um 18:05 schrieb Andreas Metzler:

On 2021-06-08 Thomas Landauer  wrote:

Package: exim4
Severity: wishlist



It looks like the /var/spool/exim4/msglog.OLD directory is only created by
Exim itself after the first messagelog is going to be written there.



If you need custom permissions on this directory, it would be nice to be
able to set those permissions right within the deployment process, i.e.
before Exim has sent any mail. So I'm suggesting to create it right away,
during the installation.



I've already suggested this at https://bugs.exim.org/show_bug.cgi?id=2768
but got the answer that this is more a distribution thing :-)


Hello Thomas,

/var/spool/exim4/msglog.OLD is only used if a specific exim4 setting is
enabled which is not enabled by default. So enabling this requires a
local manual step and when you do it you can also mkdir the directory
with specific local permissions. You can use dpkg-statoverride
which you could not use before, but that is a small win, imho.
The benefit-cost-ratio seems to be off, shipping an empty directory in
millions of installations that is going to be useless for all but a few
installations.

cu Andreas

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 08.06.2021 um 18:31 schrieb Michael Biebl:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?


Change to what exactly?


Did you use systemd-run in buster to start your lxc containers?
You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now either, 
its possible I had forgotten the --scope at some point while testing 
set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case 
that you do not need set-linger and the default behavior should be that 
things aren't automatically killed in the background? Is that something 
that was an intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login session.

If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that process.


The systemd-run manpage seems to indicate that with debian's default 
change of KillUserProcesses=no this should not occur with or without 
linger. In either case, it seems the manpage should be updated to 
describe this behavior, and maybe updated to mention that 
KilUserProcesses is *not* the default on Debian, which it states in the 
EXAMPLES section.


We had this discussion in the past. The man pages document the upstream 
default behaviour. Patching all man pages to reflect Debian specific 
changes is unfortunately not maintainable. Sorry.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989613: unblock: orthanc-dicomweb/1.5+dfsg-3

2021-06-08 Thread Sebastien Jodogne

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

Please unblock package orthanc-dicomweb

[ Reason ]
This version fixes issue #989128 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-dicomweb/1.5+dfsg-2) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-dicomweb/1.5+dfsg-3
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/changelog 
orthanc-dicomweb-1.5+dfsg/debian/changelog
--- orthanc-dicomweb-1.5+dfsg/debian/changelog  2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/changelog  2021-06-07 11:17:44.0 
+0200
@@ -1,3 +1,10 @@
+orthanc-dicomweb (1.5+dfsg-3) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute (backport from experimental).
+Closes: #989128
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 11:17:44 +0200
+
 orthanc-dicomweb (1.5+dfsg-2) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/control 
orthanc-dicomweb-1.5+dfsg/debian/control
--- orthanc-dicomweb-1.5+dfsg/debian/control2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/control2021-06-07 11:17:44.0 
+0200
@@ -26,6 +26,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  orthanc (>= 1.7.0)
+Built-Using: ${orthancframework:Built-Using}
 Description: Plugin to extend Orthanc with support of WADO and DICOMweb
  Orthanc DICOMweb is a plugin to Orthanc, the lightweight, RESTful Vendor
  Neutral Archive for medical imaging. It extends the Orthanc core with
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/rules 
orthanc-dicomweb-1.5+dfsg/debian/rules
--- orthanc-dicomweb-1.5+dfsg/debian/rules  2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/rules  2021-06-07 11:17:44.0 
+0200
@@ -24,6 +24,13 @@
 "-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem 
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid 
sqlite3 dcmdata dcmjpeg dcmjpls ofstd dcmimage" \
 -DCMAKE_BUILD_TYPE=None  # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989128
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Place back the jquery library from Debian
cp /usr/share/javascript/jquery/jquery.min.js 
Resources/Samples/JavaScript/jquery.min.js

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

2021-06-08 Thread Josh Triplett

Package: e2fsprogs
Version: 1.46.2-2
Severity: normal
File: /sbin/mke2fs
X-Debbugs-Cc: j...@joshtriplett.org

mke2fs with -E offset=N does not seem to take the offset into account
when checking the target to see if it seems to already contain
something. For instance:

/tmp$ truncate -s 1G disk.img
/tmp$ echo '8,+,L' | sfdisk --lock --no-reread --no-tell-kernel disk.img
Disk disk.img: 1 GiB, 1073741824 bytes, 2097152 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

>>> Created a new DOS disklabel with disk identifier 0x729c5118.
disk.img1: Created a new partition 1 of type 'Linux' and of size 1024 MiB.
disk.img2: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x729c5118

Device Boot Start End Sectors  Size Id Type
disk.img1   8 2097151 2097144 1024M 83 Linux

The partition table has been altered.
/tmp$ mkfs.ext4 -E offset=4096 disk.img
mke2fs 1.46.2 (28-Feb-2021)
Found a dos partition table in disk.img
Proceed anyway? (y,N)



I deeply appreciate that mke2fs checks for existing data before
overwriting it, and I'd prefer to not just pass -F here. I think the
"plausible" checks should take the offset into account.


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

Kernel: Linux 5.12.8 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e2fsprogs depends on:
ii  libblkid12.36.1-7
ii  libc62.31-12
ii  libcom-err2  1.46.2-2
ii  libext2fs2   1.46.2-2
ii  libss2   1.46.2-2
ii  libuuid1 2.36.1-7
ii  logsave  1.46.2-2

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.4-1

-- no debconf information

Bug#989192: diffoscope: Differences in file lists are repeated at each depth level

2021-06-08 Thread Chris Lamb

forwarded 989192 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/263
thanks

I've forwarded this upstream here (so all our bugs are in the same place):

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/263


Regards,

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

Bug#989611: unblock: orthanc-wsi/1.0-3

2021-06-08 Thread Sebastien Jodogne

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

Please unblock package orthanc-wsi

[ Reason ]
This version fixes issue #989126 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-wsi/1.0-2) is the addition of the "Built-Using" attribute
on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-wsi/1.0-3
diff -Nru orthanc-wsi-1.0/debian/changelog orthanc-wsi-1.0/debian/changelog
--- orthanc-wsi-1.0/debian/changelog2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/changelog2021-06-07 14:34:06.0 +0200
@@ -1,3 +1,9 @@
+orthanc-wsi (1.0-3) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute. Closes: #989126
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 14:34:06 +0200
+
 orthanc-wsi (1.0-2) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-wsi-1.0/debian/control orthanc-wsi-1.0/debian/control
--- orthanc-wsi-1.0/debian/control  2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/control  2021-06-07 14:34:06.0 +0200
@@ -24,6 +24,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Built-Using: ${orthancframework:Built-Using}
 Recommends: orthanc (>= 1.1.0),
 libopenslide0
 Description: Whole-slide imaging support for Orthanc (digital pathology)
diff -Nru orthanc-wsi-1.0/debian/rules orthanc-wsi-1.0/debian/rules
--- orthanc-wsi-1.0/debian/rules2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/rules2021-06-07 14:34:06.0 +0200
@@ -33,6 +33,13 @@
-DOPENLAYERS_JS=$(CURDIR)/BuildViewer/ol.min.js \
-DCMAKE_BUILD_TYPE=None   # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989126
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Configure the command-line tools
mkdir BuildApplications

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

2021-06-08 Thread Matt Corallo

Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at some
point while testing set-linger before, sorry for the noise here.

Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the default
behavior should be that things aren't automatically killed in the background? Is that something that was an intentional
change?

The systemd-run manpage seems to indicate that with debian's default change of KillUserProcesses=no this should not
occur with or without linger. In either case, it seems the manpage should be updated to describe this behavior, and
maybe updated to mention that KilUserProcesses is *not* the default on Debian, which it states in the EXAMPLES section.

Thanks,
Matt

On 6/8/21 10:19, Michael Biebl wrote:

Control: tags -1 + unreproducible

So, I've been following the instructions in /usr/share/doc/lxc/README.Debian to
allow unprivileged containers.

After that, I could successfully run a container. I used the command line as
suggested in that README.Debian:

$ systemd-run --scope --quiet --user --property=Delegate=yes \
lxc-start -n mycontainer

Once I logged out, the systemd --user session was stopped including the
container, which is expected, as ansgar wrote.

After enabling "linger" for that user, the systemd --user session was not stopped anymore after logging out and the
container continued running.

I'm thus marking this bug report as unreproducible.

(note that the lxc maintainers recommend to use --scope with systemd-run)

Michael

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

2021-06-08 Thread Andreas Metzler

On 2021-06-08 Thomas Landauer  wrote:
> Package: exim4
> Severity: wishlist

> It looks like the /var/spool/exim4/msglog.OLD directory is only created by
> Exim itself after the first messagelog is going to be written there.

> If you need custom permissions on this directory, it would be nice to be
> able to set those permissions right within the deployment process, i.e.
> before Exim has sent any mail. So I'm suggesting to create it right away,
> during the installation.

> I've already suggested this at https://bugs.exim.org/show_bug.cgi?id=2768
> but got the answer that this is more a distribution thing :-)

Hello Thomas,

/var/spool/exim4/msglog.OLD is only used if a specific exim4 setting is
enabled which is not enabled by default. So enabling this requires a
local manual step and when you do it you can also mkdir the directory
with specific local permissions. You can use dpkg-statoverride
which you could not use before, but that is a small win, imho.
The benefit-cost-ratio seems to be off, shipping an empty directory in
millions of installations that is going to be useless for all but a few
installations.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#989610: unblock: orthanc-webviewer/2.7-4

2021-06-08 Thread Sebastien Jodogne

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

Please unblock package orthanc-webviewer

[ Reason ]
This version fixes issue #989127 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-webviewer/2.7-3) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-webviewer/2.7-4
diff -Nru orthanc-webviewer-2.7/debian/changelog 
orthanc-webviewer-2.7/debian/changelog
--- orthanc-webviewer-2.7/debian/changelog  2021-02-26 14:41:24.0 
+0100
+++ orthanc-webviewer-2.7/debian/changelog  2021-06-07 14:21:25.0 
+0200
@@ -1,3 +1,9 @@
+orthanc-webviewer (2.7-4) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute. Closes: #989127
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 14:21:25 +0200
+
 orthanc-webviewer (2.7-3) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-webviewer-2.7/debian/control 
orthanc-webviewer-2.7/debian/control
--- orthanc-webviewer-2.7/debian/control2021-02-26 14:38:57.0 
+0100
+++ orthanc-webviewer-2.7/debian/control2021-06-07 14:21:25.0 
+0200
@@ -29,6 +29,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  orthanc (>= 1.7.1)
+Built-Using: ${orthancframework:Built-Using}
 Description: Web viewer of medical images for Orthanc
  Orthanc Web Viewer is a plugin to Orthanc, a lightweight, RESTful Vendor
  Neutral Archive for medical imaging. It extends Orthanc with an integrated
diff -Nru orthanc-webviewer-2.7/debian/rules orthanc-webviewer-2.7/debian/rules
--- orthanc-webviewer-2.7/debian/rules  2021-02-26 14:41:24.0 +0100
+++ orthanc-webviewer-2.7/debian/rules  2021-06-07 14:21:25.0 +0200
@@ -26,6 +26,13 @@
"-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem 
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid 
sqlite3" \
-DCMAKE_BUILD_TYPE=None   # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989127
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Place the third-party JavaScript libraries at the location
 # expected by CMake

Bug#989605: mirror submission for mirror.alwyzon.net

2021-06-08 Thread Peter Palfrader

Hi!

On Tue, 08 Jun 2021, Alwyzon wrote:

> Submission-Type: new
> Site: mirror.alwyzon.net
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Alwyzon 
> Country: AT Austria
> Location: Vienna
> Sponsor: Alwyzon https://www.alwyzon.com/

Can you tell us a bit more about your DNS setup?

It seems alwyzon.com only has a single IPv4 nameserver, and both
nameservers share the same IPv6 address.  How does the dns service for
this domain provide availability against spof?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989609: unblock: rdma-core/33.2-1

2021-06-08 Thread Benjamin Drung

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

Please unblock package rdma-core

The rdma-core projects follows a similar release process than the linux
kernel developers. The point releases only contain backported fixes. I
had a look at those commits between our git snapshot from 2021-03-17 and
the 33.2 release.

[ Reason ]
The 33.2 release contains more bugfixes.

[ Impact ]
Users with InfiniBand hardware might not benefit from the fixes.

[ Tests ]
The upstream project has test cases, but our package does not run the
tests, because they rely on having InfiniBand hardware.

[ Risks ]
The package is not a leaf package, but only needed for users with RDMA
hardware. Since we have a good upstream relationship, the code from
upstream is unchanged. In case of a regression, upstream will be
affected as well.

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

unblock rdma-core/33.2-1

-- 
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
diff -Nru rdma-core-33.1+git20210317/buildlib/centos6.spec 
rdma-core-33.2/buildlib/centos6.spec
--- rdma-core-33.1+git20210317/buildlib/centos6.spec2021-04-06 
10:12:51.0 +0200
+++ rdma-core-33.2/buildlib/centos6.spec2021-06-03 09:20:05.0 
+0200
@@ -1,5 +1,5 @@
 Name: rdma-core
-Version: 33.1
+Version: 33.2
 Release: 1%{?dist}
 Summary: RDMA core userspace libraries and daemons
 
diff -Nru rdma-core-33.1+git20210317/buildlib/RDMA_EnableCStd.cmake 
rdma-core-33.2/buildlib/RDMA_EnableCStd.cmake
--- rdma-core-33.1+git20210317/buildlib/RDMA_EnableCStd.cmake   2021-04-06 
10:12:51.0 +0200
+++ rdma-core-33.2/buildlib/RDMA_EnableCStd.cmake   2021-06-03 
09:20:05.0 +0200
@@ -58,9 +58,15 @@
   endif()
 endfunction()
 
+function(RDMA_Check_C_Compiles TO_VAR CHECK_PROGRAM)
+  set(CMAKE_REQUIRED_FLAGS "${ARGV2} -Werror")
+  CHECK_C_SOURCE_COMPILES("${CHECK_PROGRAM}" ${TO_VAR})
+  set(${TO_VAR} ${${TO_VAR}} PARENT_SCOPE)
+endfunction()
+
 function(RDMA_Check_Aliasing TO_VAR)
   SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O2")
-  CHECK_C_SOURCE_COMPILES("
+  RDMA_Check_C_Compiles(HAVE_WORKING_STRICT_ALIASING "
 struct in6_addr {unsigned int u6_addr32[4];};
 struct iphdr {unsigned int daddr;};
 union ibv_gid {unsigned char raw[16];};
@@ -80,8 +86,7 @@
map_ipv4_addr_to_ipv6(&a);
return set_ah_attr_by_ipv4(&h);
 }"
-HAVE_WORKING_STRICT_ALIASING
-FAIL_REGEX "warning")
+  )
 
   set(${TO_VAR} "${HAVE_WORKING_STRICT_ALIASING}" PARENT_SCOPE)
 endfunction()
@@ -107,20 +112,12 @@
 #endif
 ")
 
-  CHECK_C_SOURCE_COMPILES(
-"${SSE_CHECK_PROGRAM}"
-HAVE_TARGET_SSE
-FAIL_REGEX "warning")
+  RDMA_Check_C_Compiles(HAVE_TARGET_SSE "${SSE_CHECK_PROGRAM}")
 
   if(NOT HAVE_TARGET_SSE)
 # Older compiler, we can work around this by adding -msse instead of
 # relying on the function attribute.
-set(CMAKE_REQUIRED_FLAGS "-msse")
-CHECK_C_SOURCE_COMPILES(
-  "${SSE_CHECK_PROGRAM}"
-  NEED_MSSE_FLAG
-  FAIL_REGEX "warning")
-set(CMAKE_REQUIRED_FLAGS)
+RDMA_Check_C_Compiles(NEED_MSSE_FLAG "${SSE_CHECK_PROGRAM}" "-msse")
 
 if(NEED_MSSE_FLAG)
   set(SSE_FLAGS "-msse" PARENT_SCOPE)
diff -Nru rdma-core-33.1+git20210317/CMakeLists.txt 
rdma-core-33.2/CMakeLists.txt
--- rdma-core-33.1+git20210317/CMakeLists.txt   2021-04-06 10:12:51.0 
+0200
+++ rdma-core-33.2/CMakeLists.txt   2021-06-03 09:20:05.0 +0200
@@ -72,7 +72,7 @@
 set(PACKAGE_NAME "RDMA")
 
 # See Documentation/versioning.md
-set(PACKAGE_VERSION "33.1")
+set(PACKAGE_VERSION "33.2")
 # When this is changed the values in these files need changing too:
 #   debian/control
 #   debian/libibverbs1.symbols
@@ -233,26 +233,21 @@
 
 # At some point after 4.4 gcc fixed shadow to ignore function vs variable
 # conflicts
-set(SAFE_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
-  set(CMAKE_REQUIRED_FLAGS "-Wshadow")
-CHECK_C_SOURCE_COMPILES("
+RDMA_Check_C_Compiles(HAVE_C_WORKING_SHADOW "
  #include 
  int main(int argc,const char *argv[]) { int access = 1; return access; }"
-  HAVE_C_WORKING_SHADOW
-  FAIL_REGEX "warning")
+  "-Wshadow")
 if (HAVE_C_WORKING_SHADOW)
   RDMA_AddOptCFlag(CMAKE_C_FLAGS HAVE_C_WORKING_SHADOW "-Wshadow")
 endif()
-set(CMAKE_REQUIRED_FLAGS "${SAFE_CMAKE_REQUIRED_FLAGS}")
 
 # At some point around 5.4 gcc fixed missing-field-initializers to ignore this
 # common idiom we use extensively. Since this is a useful warning for
 # de

Bug#989602: dpkg-deb overwrites symlinks with directories

2021-06-08 Thread Johannes Schauer Marin Rodrigues

On Tue, 08 Jun 2021 14:08:46 +0200 Marc Haber  
wrote:
> dpkg-deb -x package.deb happily overwrites symlinks on the filesystems
> with directories. I don't know whether this is desired behavior.
> 
> tl;dr:
> For some reason, a system of mine ended up without
> /sbin/start-stop-daemon. Not knowing about dpkg --force-bad-path, I was
> unable to use dpkg to repair dpkg because dpkg refuses work if there is
> no /sbin/start-stop-daemon.
> 
> dpkg-deb -x /var/cache/apt/archives/dpkg*.deb / happily replaced the
> /sbin => /usr/sbin with an /sbin directory containing only
> /sbin/start-stop-daemon.
> 
> Wouldn't it be nicer to have dpkg follow symlinks before creating
> directories in the times of usrmerge?
> 
> Severity: minor because dpkg --force-bad-path --install dpkg*.deb works.

you can also use:

dpkg-deb --fsys-tarfile dpkg*.deb | tar -C / --keep-directory-symlink --extract 
--file -

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

2021-06-08 Thread Thomas Landauer


Package: exim4
Severity: wishlist

It looks like the /var/spool/exim4/msglog.OLD directory is only created 
by Exim itself after the first messagelog is going to be written there.


If you need custom permissions on this directory, it would be nice to be 
able to set those permissions right within the deployment process, i.e. 
before Exim has sent any mail. So I'm suggesting to create it right 
away, during the installation.


I've already suggested this at 
https://bugs.exim.org/show_bug.cgi?id=2768 but got the answer that this 
is more a distribution thing :-)




--
Schöne Grüße
Thomas Landauer

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

2021-06-08 Thread Julien Puydt

Hi,

Le mardi 08 juin 2021 à 14:58 +0200, Jochen Sprickerhof a écrit :
> 
> friendly ping on the sagemath issue as it will be dropped from
> testing 
> on the 18., otherwise.
> As far as I read there are a number of proposals (downgrade, ignore
> test 
> results..) besides fixing the tests. I'm happy to help with this but 
> leave it to the maintainers how to approach this.

I've been convinced that getting a fragile sagemath in next stable
wouldn't be a good thing.

Cheers,

JP

Bug#989593: installation report Raspberry Pi 4 UEFI

2021-06-08 Thread Cyril Brulebois

Marc Haber  (2021-06-08):
> The Raspi 4 has both Wifi and Ethernet interfaces named brcmsomething,
> so it's still kind of guessing, but I have verified in the mean time
> that it's actually really the Wifi firmware.

Alright, thanks for confirming.

> Text installer ("expert"). I have used the graphical installer just a
> handful of times in two decades.

OK, good guess then, but checking never hurts.

> Since my default domain types differently with US and DE keyboard, I
> guess this might be an actual regression, I would have noticed this in
> earlier versions of the installer.

I guess someone could try various images outside the Pi 4 setup and see
whether/when that regressed. Given the following issue (ssd), I wouldn't
rule out some Pi-specific, but such a trivial thing seems a little
strange… That being said, I test the graphical installer most of the
time, and I don't know the specifics of the text version by heart.

> > Simply /var/log/syslog for the main log. Other files are mentioned
> > there:
> >   
> > https://salsa.debian.org/installer-team/installation-report/-/blob/master/debian/installation-report.postinst
> 
> Is there anything you need from me to go on?

If you were to retry the installation, saving /var/log/syslog manually
before rebooting into the installed system would be useful. Without it,
I fear much guessing would be needed to try and figure out what happened
on that system specifically. Unless someone else has better ideas of
course.


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


signature.asc
Description: PGP signature

Bug#989607: ITP: 2geom -- robust computational geometry framework

2021-06-08 Thread Mattia Rizzolo

Package: wnpp
Severity: wishlist
Owner: Mattia Rizzolo 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org
Control: block 989606 by -1

* Package name: 2geom
  Version : 1.1
  Upstream Author : Inkscape developers
* URL : https://gitlab.com/inkscape/lib2geom
* License : LGPLG-2.1 or MPL-1.1
  Programming Lang: C++
  Description : robust computational geometry framework

The library is descended from a set of geometric routines present in
Inkscape, a vector graphics editor based around the Scalable Vector
Graphics format, the most widespread vector graphics interchange format
on the Web and a W3C Recommendation. Due to this legacy, not all parts
of the API form a coherent whole (yet).
Rendering is outside the scope of this library, and it is assumed
something like libcairo or similar is employed for this.  2geom
concentrates on higher level algorithms and geometric computations.



This library was developed mainly to be used by Inkscape, but it's
released separately in the hope to be useful to others.

I plan to maintain it within the Debian Multimedia team (like I do for
inkscape), and welcome others to join me.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#989603: ocsinventory-server: Does not start after install

2021-06-08 Thread Enrico Rossi

Hi,

finally copy/paste the same file from the Buster version seems to solve
the problem.

/usr/share/perl5/Apache/Ocsinventory/Plugins/Apache.pm

Tnx
E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi

Bug#985094: [RFS] ITP: ortools -- Google Optimization Tools

2021-06-08 Thread Romain Porte

X-Debbugs-Cc: debian-scie...@lists.debian.org

Hi,

The package has been pushed to debian-science team's salsa:

https://salsa.debian.org/science-team/ortools

Please review.

Best regards,

Romain.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 08.06.21 um 16:23 schrieb Michael Biebl:

Am 08.06.21 um 16:19 schrieb Michael Biebl:

After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued 
running.



# systemd-cgls


Attaching output as file, to avoid it getting mangled.



# systemd-cgls
Control group /:
-.slice
├─user.slice 
│ ├─user-0.slice 
│ │ ├─session-1.scope 
│ │ │ ├─ 438 /bin/login -p --
│ │ │ ├─ 553 -bash
│ │ │ └─1440 systemd-cgls
│ │ └─user@0.service …
│ │   └─init.scope 
│ │ ├─534 /lib/systemd/systemd --user
│ │ └─535 (sd-pam)
│ └─user-1000.slice 
│   └─user@1000.service …
│ ├─app.slice 
│ │ └─run-rc9609178954b49f684f37595d92e5171.scope 
│ │   ├─lxc.monitor.mycontainer 
│ │   │ └─1242 [lxc monitor] /home/michael/.local/share/lxc mycontainer
│ │   └─lxc.payload.mycontainer 
│ │ ├─init.scope 
│ │ │ └─1248 /sbin/init
│ │ └─system.slice 
│ │   ├─networking.service 
│ │   │ └─1350 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /…
│ │   ├─systemd-journald.service 
│ │   │ └─1326 /lib/systemd/systemd-journald
│ │   ├─console-getty.service 
│ │   │ └─1394 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1…
│ │   ├─system-container\x2dgetty.slice 
│ │   │ ├─container-getty@0.service 
│ │   │ │ └─1395 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/0 1…
│ │   │ ├─container-getty@2.service 
│ │   │ │ └─1397 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/2 1…
│ │   │ ├─container-getty@1.service 
│ │   │ │ └─1396 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/1 1…
│ │   │ └─container-getty@3.service 
│ │   │   └─1398 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/3 1…
│ │   ├─dbus.service 
│ │   │ └─1370 /usr/bin/dbus-daemon --system --address=systemd: --nofor…
│ │   └─systemd-logind.service 
│ │ └─1372 /lib/systemd/systemd-logind
│ └─init.scope 
│   ├─1182 /lib/systemd/systemd --user
│   └─1184 (sd-pam)
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─lxc-net.service 
  │ └─492 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order --bind-interf…
  ├─systemd-udevd.service 
  │ └─232 /lib/systemd/systemd-udevd
  ├─cron.service 
  │ └─402 /usr/sbin/cron -f
  ├─systemd-journald.service 
  │ └─214 /lib/systemd/systemd-journald
  ├─ssh.service 
  │ └─457 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─ifup@enp1s0.service 
  │ └─449 /sbin/dhclient -4 -v -i -pf /run/dhclient.enp1s0.pid -lf /var/lib/dhc…
  ├─rsyslog.service 
  │ └─411 /usr/sbin/rsyslogd -n -iNONE
  ├─lxcfs.service …
  │ └─407 /usr/bin/lxcfs /var/lib/lxcfs
  ├─dbus.service 
  │ └─403 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  ├─systemd-timesyncd.service 
  │ └─261 /lib/systemd/systemd-timesyncd
  ├─system-getty.slice 
  │ ├─getty@tty6.service 
  │ │ └─896 /sbin/agetty -o -p -- \u --noclear tty6 linux
  │ └─getty@tty2.service 
  │   └─1377 /sbin/agetty -o -p -- \u --noclear tty2 linux
  └─systemd-logind.service 
└─417 /lib/systemd/systemd-logind

# loginctl show-user michael
UID=1000
GID=1000
Name=michael
Timestamp=Tue 2021-06-08 16:08:20 CEST
TimestampMonotonic=280083967
RuntimePath=/run/user/1000
Service=user@1000.service
Slice=user-1000.slice
State=lingering
Sessions=
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Am 08.06.21 um 16:19 schrieb Michael Biebl:

After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued running.



# systemd-cgls
Control group /:
-.slice
├─user.slice 
│ ├─user-0.slice 
│ │ ├─session-1.scope 
│ │ │ ├─ 438 /bin/login -p --

│ │ │ ├─ 553 -bash
│ │ │ └─1440 systemd-cgls
│ │ └─user@0.service …
│ │   └─init.scope 
│ │ ├─534 /lib/systemd/systemd --user

│ │ └─535 (sd-pam)
│ └─user-1000.slice 
│   └─user@1000.service …
│ ├─app.slice 
│ │ └─run-rc9609178954b49f684f37595d92e5171.scope 
│ │   ├─lxc.monitor.mycontainer 
│ │   │ └─1242 [lxc monitor] /home/michael/.local/share/lxc mycontainer
│ │   └─lxc.payload.mycontainer 
│ │ ├─init.scope 
│ │ │ └─1248 /sbin/init
│ │ └─system.slice 
│ │   ├─networking.service 
│ │   │ └─1350 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /…
│ │   ├─systemd-journald.service 
│ │   │ └─1326 /lib/systemd/systemd-journald
│ │   ├─console-getty.service 
│ │   │ └─1394 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1…
│ │   ├─system-container\x2dgetty.slice 
│ │   │ ├─container-getty@0.service 
│ │   │ │ └─1395 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/0 1…
│ │   │ ├─container-getty@2.service 
│ │   │ │ └─1397 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/2 1…
│ │   │ ├─container-getty@1.service 
│ │   │ │ └─1396 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/1 1…
│ │   │ └─container-getty@3.service 
│ │   │   └─1398 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/3 1…
│ │   ├─dbus.service 
│ │   │ └─1370 /usr/bin/dbus-daemon --system --address=systemd: --nofor…
│ │   └─systemd-logind.service 
│ │ └─1372 /lib/systemd/systemd-logind
│ └─init.scope 
│   ├─1182 /lib/systemd/systemd --user

│   └─1184 (sd-pam)
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─lxc-net.service 
  │ └─492 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order --bind-interf…
  ├─systemd-udevd.service 
  │ └─232 /lib/systemd/systemd-udevd
  ├─cron.service 
  │ └─402 /usr/sbin/cron -f
  ├─systemd-journald.service 
  │ └─214 /lib/systemd/systemd-journald
  ├─ssh.service 
  │ └─457 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─ifup@enp1s0.service 
  │ └─449 /sbin/dhclient -4 -v -i -pf /run/dhclient.enp1s0.pid -lf /var/lib/dhc…
  ├─rsyslog.service 
  │ └─411 /usr/sbin/rsyslogd -n -iNONE

  ├─lxcfs.service …
  │ └─407 /usr/bin/lxcfs /var/lib/lxcfs
  ├─dbus.service 
  │ └─403 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  ├─systemd-timesyncd.service 
  │ └─261 /lib/systemd/systemd-timesyncd
  ├─system-getty.slice 
  │ ├─getty@tty6.service 
  │ │ └─896 /sbin/agetty -o -p -- \u --noclear tty6 linux
  │ └─getty@tty2.service 
  │   └─1377 /sbin/agetty -o -p -- \u --noclear tty2 linux
  └─systemd-logind.service 
└─417 /lib/systemd/systemd-logind


# loginctl show-user michael
UID=1000
GID=1000
Name=michael
Timestamp=Tue 2021-06-08 16:08:20 CEST
TimestampMonotonic=280083967
RuntimePath=/run/user/1000
Service=user@1000.service
Slice=user-1000.slice
State=lingering
Sessions=
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes





OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)


Control: tags -1 + unreproducible

So, I've been following the instructions in 
/usr/share/doc/lxc/README.Debian to allow unprivileged containers.


After that, I could successfully run a container. I used the command 
line as suggested in that README.Debian:


$ systemd-run --scope --quiet --user --property=Delegate=yes \
lxc-start -n mycontainer


Once I logged out, the systemd --user session was stopped including the 
container, which is expected, as ansgar wrote.


After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued running.


I'm thus marking this bug report as unreproducible.

(note that the lxc maintainers recommend to use --scope with systemd-run)

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989603: ocsinventory-server: Does not start after install

2021-06-08 Thread Enrico Rossi

Hi,

looks like the:

/usr/share/perl5/Apache/Ocsinventory/Plugins/Apache.pm

file is missing. It was present in the old (buster) version.

E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi

Bug#989606: inkscape: package 2geom separately

2021-06-08 Thread Mattia Rizzolo

Source: inkscape
Version: 1.1-1
Severity: minor

Starting with 1.1 inkscape wants 2geom, a library developed by the
inkscape developers themselves, and also bundled within inkscape in case
it's not available system-wide.

For now I'm using the bundled version, but we should decouple it and use
a system-installed shared library instead.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#989604: libssl1.1: segfault on arm64 (M1) with some ciphers e.g. curl https://dl.yarnpkg.com

2021-06-08 Thread David Scott

Package: libssl1.1
Version: 1.1.1d-0+deb10u6
Severity: normal

Dear Maintainer,

This bug appears to be fixed by 1.1.1k-1 in testing. I couldn't spot it
in the issue tracker but thought I'd mention it just in case.

On my arm64 machine (Apple M1) if I run Debian buster (in a Linux container
inside a qemu VM) with 1.1.1d-0+deb10u6 *and* expose the host's CPUID to the
VM running the container i.e.

```
root@1a99ac25e4fd:/# cat /proc/cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp 
asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit 
uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint
```

then this crashes:

```
root@1a99ac25e4fd:/# curl -vvv https://dl.yarnpkg.com
* Expire in 0 ms for 6 (transfer 0xfbedef30)
* Expire in 1 ms for 1 (transfer 0xfbedef30)
...
*   Trying 104.18.126.100...
* TCP_NODELAY set
* Expire in 149997 ms for 3 (transfer 0xfbedef30)
* Expire in 200 ms for 4 (transfer 0xfbedef30)
* Connected to dl.yarnpkg.com (104.18.126.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; 
CN=sni.cloudflaressl.com
*  start date: Aug 18 00:00:00 2020 GMT
*  expire date: Aug 18 12:00:00 2021 GMT
*  subjectAltName: host "dl.yarnpkg.com" matched cert's "*.yarnpkg.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xfbedef30)
> GET / HTTP/2
> Host: dl.yarnpkg.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
Segmentation fault
```

Other URLs work fine.

The `curl` succeeds if I hide some of the CPUID flags e.g. by
pretending the system is a cortex-a57 (with `qemu -cpu cortex-a57`):
```
/ # cat /proc/cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 fphp asimdhp cpuid 
dit
```

If I take a broken buster system and replace the `libcrypto.so.1.1` with
the one from testing, the bug is fixed.

So I think it's a bug in the buster version of libssl1.1, detecting some
CPU feature, misusing it and crashing. The bug appears to be fixed in
testing.

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.25-linuxkit (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- no debconf information

Thanks for all your work!
David

Bug#909473: fstrim shows incorrect trimmed size after reboot

2021-06-08 Thread Laurent Bigonville


Control: tags -1 - moreinfo

Le 28/05/21 à 21:28, Salvatore Bonaccorso a écrit :

Control: tags -1 + moreinfo

Hi Laurent,

On Mon, Sep 24, 2018 at 01:37:01PM +0200, Laurent Bigonville wrote:

Package: src:linux
Version: 4.18.8-1
Severity: normal

Hi,

Not sure who to blame here, but when running fstrim -va it show the size
of the disk it has trimmed, if I'm running fstrim again it shows 0 for
all the disk.

If I reboot, and then run fstrim again it shows (almost) the same value
as the 1st time. All the disks have the discard option enabled, all fs
are ext4, except /boot which is ext2/

See the logs:

bigon@valinor:~$ journalctl -u fstrim.service
-- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 
CEST. --
sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB 
(975245312 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB 
(10455736320 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB 
(967565312 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB 
(832487424 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.

There is definitely something boggus here

Is this still something you are able to reproduce this way with a
recent kernel?


Hello Salvatore,

Yes, just tested it now and  it's still happening with the kernel 
currently in unstable (5.10.40-1)

Bug#989603: ocsinventory-server: Does not start after install

2021-06-08 Thread Enrico Rossi

Package: ocsinventory-server
Version: 2.8+dfsg1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: e.ro...@tecnobrain.com

Dear Maintainer,

after installing the package on a clean and dedicated server, following
the README.Debian file provided on:

Post-installation notes
---

Please note that after first installation, or after an upgrade, it's recommended
to call http://your_ocs_server/ocsreports/install.php ;

but the apache server does not start with the error:

[Tue Jun 08 11:35:37.412729 2021] [perl:error] [pid 589] Can't locate 
Apache/Ocsinventory/Plugins/Apache.pm in @INC (you may need to install the 
Apache::Ocsinventory::Plugins::Apache module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 
/usr/local/lib/site_perl /etc/apache2) at (eval 13) line 1.\n
[Tue Jun 08 11:35:37.412792 2021] [perl:error] [pid 589] Can't load Perl module 
Apache::Ocsinventory::Plugins::Apache for server inventory.example.org:0, 
exiting...

Thanks for maintaining.
E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi

Bug#989589: Real fix just got merged

2021-06-08 Thread Christian Ehrhardt

FYI - at https://sourceforge.net/p/gptfdisk/code/merge-requests/26/ a
real fix for the underlying problem has been merged upstream.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#988781: hurfbuzz: please package harfbuzz-subset

2021-06-08 Thread Mattia Rizzolo

Hi Emilio,

thanks for reaching back.

On Tue, Jun 08, 2021 at 11:55:03AM +0200, Emilio Pozuelo Monfort wrote:
> > Could you please consider including it in the Debian packaging?
> 
> It's not packaged because the API was (maybe still is) unstable. From the 
> NEWS file:

I decided to ask upstream first:
https://github.com/harfbuzz/harfbuzz/issues/3012

> I think we can package it, as hopefully the API is (somewhat) stable now and
> we don't need transitions without SONAME changes (and with conflicting,
> renamed packages).
> 
> MRs welcome.

I'll open an MR against salsa/harfbuzz if I receive the go-ahead from
upstream, thank you.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#989589: Actually read/display is good now, but write was always wrong

2021-06-08 Thread Christian Ehrhardt

If you follow the discussion I linked when opening the bug as [3]
you'll find more.
But the TL;DR is that sgdisk/gdisk always (and still) write the
labels/names byte-swapped on s390x (or probably in general big
endian).

So I'd suggest to not revert the change, and instead wait for a fix to
the write code-path that then should be applied.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

2021-06-08 Thread Jochen Sprickerhof


Hi,

friendly ping on the sagemath issue as it will be dropped from testing 
on the 18., otherwise.
As far as I read there are a number of proposals (downgrade, ignore test 
results..) besides fixing the tests. I'm happy to help with this but 
leave it to the maintainers how to approach this.


Cheers Jochen

* Tobias Hansen  [2021-05-19 15:01]:

Hi,

On 5/18/21 8:25 PM, Jochen Sprickerhof wrote:


I think there are a number of problems:
- Tests not being executed due to the open file limit ("Killing test" in   the 
log). If you want to use the tests as an indicator if the build   works, you should make 
sure the all tests are executed, otherwise 200   tolerated failures is arbitrary.



I have been struggling with this for quite a while and I don't know how to fix 
it. It comes and goes and does not seem to affect vanilla upstream builds. This 
has impacted progress on the package since one cannot properly work on it when 
the test suite crashes. I tried asking upstream for help here and provided more 
details:

https://groups.google.com/g/sage-packaging/c/1G_3JiIcbvY



- I found a number of segfaults in the tests, like:
  sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed due 
to segmentation fault
- Looking at the amd64 log of the buildd:
  Error: 202 tests failed, up to 200 failures are tolerated
  Yes: 202 tests failed, up to 400 failures are tolerated for rerun
  Success: 192 tests failed, up to 200 failures are tolerated
  does that mean we ran the test twice and it passed the second time   cause 
there where 10 failures less? Can we be sure that this always   succeeds? 192 
is really close to 200.
- I still see cython: not found in the logs, so there are definitely   tests 
broken due to that. Maybe it makes sense to define tests which   are allowed to 
break and other which should succeed?



I agree, segfaults and the cython issue should be fixed. The number of failed 
tests always grows with time when dependencies change and sagemath is not 
adapted accordingly.

Best,

Tobias


signature.asc
Description: PGP signature

Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

2021-06-08 Thread Guilhem Moulin

Hi Jonas!

On Mon, 07 Jun 2021 at 21:54:50 +0200, Jonas Meurer wrote:
>> I'm not sure how what the best way to proceed for Bullseye.  Jonas,
>> what's your take about this?
> 
> First sorry for not responding earlier. I simply missed this mail in my
> backlog :-/

No worries!

> I would suggest to take the most pragmatic approach and don't care about
> this corner case. Given that, no stable release ever shipped with a faulty
> integritysetup and that I would expect every user who ran unstable/testing
> back when keys hat 106 bytes to still run unstable/testing, let's just keep
> it the way it is, no?

Great, then we're on the same page :-)  That's a good summary, AFAIK the
only report so far is this bug from nbf who is using a 106 bytes
truncation, and with that key size Bullseye's integritysetup isn't more
broken than Buster's.  So let's skip this for 11.0 and maybe revisit
later via s-p-u if needs be.

Thanks for the feedback!
-- 
Guilhem.

signature.asc
Description: PGP signature

Bug#987764: devscripts: [bts] bts bugs is racy

2021-06-08 Thread Romain Porte

Hello,

On Thu, 29 Apr 2021 09:18:59 +0200 Tobias Frost  wrote:

> Package: devscripts
> Version: 2.21.1
> Severity: normal
>
> bts bugs does (at least here) not work with (an already opened*) firefox,
> as the generated temporariy file is already deleted when firefox tries to
> open it.
> A workaround is to not delete the temporary file by saying UNLINK => 0 in
> line 3843 of /usr/bin/bts, but that is not a proper fix…
>
> (* Not tested if firefox was closed before.)

I can reproduce this bug locally. If firefox is closed, then the bug
will display fine, as the temporary file will be created before firefox
is opened, and deleted when firefox is closed. However, when already
running a firefox instance, the temporary file seems to be deleted early.

I think this is because calling `firefox` when another instance is
running will return immediatly (and open a new tab in the existing
instance). The devscript probably deletes the temporary file directly
upon program return.

Best regards,

Romain.

Bug#971530: dnspython 2.x breaks all of OpenStack

2021-06-08 Thread Filippo Giunchedi

On Tue, Jun 01, 2021 at 10:30:38AM +, Filippo Giunchedi wrote:
> Do you have pointers to these fixes I could look at? I ran into this bug while
> testing Swift on Bullseye, specifically container-reconciler + 
> memcache_servers
> with hostnames doesn't seem to work for me (while using ip addresses does 
> work).

FTR the specific bug for swift is now #989600

Bug#989602: dpkg-deb overwrites symlinks with directories

Package: dpkg
Version: 1.20.9
Severity: minor

Hi,

dpkg-deb -x package.deb happily overwrites symlinks on the filesystems
with directories. I don't know whether this is desired behavior.

tl;dr:
For some reason, a system of mine ended up without
/sbin/start-stop-daemon. Not knowing about dpkg --force-bad-path, I was
unable to use dpkg to repair dpkg because dpkg refuses work if there is
no /sbin/start-stop-daemon.

dpkg-deb -x /var/cache/apt/archives/dpkg*.deb / happily replaced the
/sbin => /usr/sbin with an /sbin directory containing only
/sbin/start-stop-daemon.

Wouldn't it be nicer to have dpkg follow symlinks before creating
directories in the times of usrmerge?

Severity: minor because dpkg --force-bad-path --install dpkg*.deb works.

Greetings
Marc


-- Package-specific info:

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

Kernel: Linux 5.12.9-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.3
pn  debsig-verify  

-- no debconf information

Bug#989593: installation report Raspberry Pi 4 UEFI