Bug#1060897: furo: documentation generated with Debian's furo package doesn't work standalone

[Raphaël Hertzog]

Package: furo
Version: 2023.09.10+dfsg-2
Severity: important
X-Debbugs-Cc: raph...@freexian.com

Hello Georges,

I was trying to use "furo" (as packaged in Debian) to build the debusine
documentation but I figured out that multiple things were not working
right:
https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html

- I have unwanted margins around the page, that's because "normalize.css"
  is not found, the Debian package hardcodes
  "/javascript/normalize.css/normalize.css" as the path... it's totally
  unreasonable to make that assumption for random documentation. It's
  great to reuse the Debian packaged version, but it should be reused in a
  way where it gets duplicated in the generated documentation so that
  the documentation is self-contained.

- the dark/light theme switcher is hidden because I have a ".no-js" class
  that is not removed by _static/scripts/furo.js because that script fails
  on the first import line (Uncaught SyntaxError: import declarations may
  only appear at top level of a module). This line has been patched
  by the Debian packaging, but I'm not sure if the change is the source of
  the problem.

Cheers,

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

Kernel: Linux 6.6.8-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 furo depends on:
ii  node-normalize.css  8.0.1-5
ii  python3 3.11.6-1
ii  python3-bs4 4.12.2-2
ii  python3-pygments2.15.1+dfsg-1
ii  python3-sphinx  7.2.6-3
ii  sphinx-basic-ng 1.0.0~beta2-1

furo recommends no packages.

furo suggests no packages.

-- no debconf information

Bug#1054532: autopkgtest: allow use of an alternate APT solver

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.30
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

The current way to schedule autopkgtest tests on reverse dependencies
prior to testing migration is not really satisfying:
- it relies entirely on APT pinning
- you don't have any control on the version used

While working on autopkgtest's integration in debusine, I tried to improve 
this by submitting the precise version of the updated package that I want
to validate on the command line (together with the .deb of the package
providing the autopkgtests). That works well as the packages gets
integrated in the local apt repository prepared.

However this doesn't work when the updated package has dependencies that
can only be solved in the extra repository. The requirement to use
--apt-default-release to stick to the base release means that apt will
refuse to install the dependencies from any other repository (unless we
use --pin-packages to increase their priority).

FTR here are the tries we made to reach that conclusion:
https://salsa.debian.org/freexian-team/debusine/-/issues/188

I'm looking for a solution where we don't have to do that analysis of the
dependency tree to figure out the set of deb that must be selected. It might
not be a big issue in the context of britney, but it's definitely a
showstopper in many other contexts.

Until apt gets improved (which might happen in time for trixie as juliank
told me he has plans to work on a better solver for APT), the best
solution is likely to make it possible to use an external APT solver in
that special case, just like buildd are doing for experimental builds.

In 
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300/diffs#note_434295
Paul Gevers said he considered the aspcud resolver but he decided against
as it's not the default. I agree that it should not be the default but I
still think that we should be able to opt-in to that solution for such
tests where we want to run a mixed environment and not have to provide
the exact combination of packages that have to be taken from the extra
repository.

This requires to install apt-cudf and aspcud in the image and then use a
command line like this (see man apt-cudf):
# apt-get --solver aspcud -o APT::Solver::Strict-Pinning=false -o 
APT::Solver::aspcud::Preferences="-count(solution,APT-Release:~/[an]=$extra,/),-removed,-changed,-new"
 install $package

I used a regex matching APT-Release here to match both codename (n=) and 
suites/archive (a=) and I anchored with the trailing comma to be sure to match 
the full name. FTR the APT-Release field looks like this in the EDSP data 
structure:

APT-Release: v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64
or
APT-Release: o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64

If we have multiple extra repositories, we will likely want to have $extra
be a regex like "(codename1|codename2)".

Note that this is not tested and just based on my personal research so far.

For reference, the buildd are using the following criteria for solving
build deps of experimental packages:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/blob/production/modules/buildd/templates/sbuild.conf.erb
$aspcud_criteria = 
'-count(solution,APT-Release:=/experimental/),-removed,-changed,-new';

Thanks for considering!

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 autopkgtest depends on:
ii  apt-utils   2.7.6
ii  libdpkg-perl1.22.0
ii  mawk1.3.4.20230808-1
ii  procps  2:4.0.4-2
ii  python3 3.11.4-5+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.32.1-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2023.05-2
pn  ovmf-ia32
ii  podman   4.6.2+ds1-4
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2023.05-2
ii  qemu-efi-arm 2023.05-2
ii  qemu-system  1:8.1.2+ds-1
ii  qemu-utils   1:8.1.2+ds-1
ii  schroot  1.6.13-3+b2
ii  util-linux   2.39.2-4
ii  vmdb20.27+really.0.26-1
ii  zerofree 1.1.1-1

-- no debconf information

Bug#1053892: lintian: Stop emitting masked tags

[Raphaël Hertzog]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

I just discovered the existence of masked tags and of the "Screen"
mechanism to exclude some tags. I also notice that they are
displayed together with overriden tags when you use --show-overrides.
Yet they are very different.

I believe that a tag that lintian decided to suppress should simply never be
emitted, not even as a masked tag. Thus I would suggest to stop emitting
masked tags.

But if you disagree with this, it might make sense to offer the
possibility to handle masked tags separately from overriden tags.

(Again this is a followup from a discussion here
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002)

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils2.41-5
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.0
ii  dpkg-dev1.22.0
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.29-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.0
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.41-5
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1053891: lintian: Document the existence of classification tags in the manual page

[Raphaël Hertzog]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

Hello,

the conversation in
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002
led me to realize that as a simple lintian user reading the manual page,
you can't discover the existence of classification tags and you can't
figure out the syntax to enable the display of those tags.

Please improve the manual page to explain what classification tags are,
that they are considered like normal tags with a priority lower than
everything else and that you can enable them with "--display-level
+=classification".

BTW in general, the whole explanation about --display-level is pretty
confusing, it's not clear to me what "S|C|S/C" is supposed to mean for
instance. And there's no global sorted list of usable severity so
it's hard to predict the result of --display-level '>=classification'.

Cheers,

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils2.41-5
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.0
ii  dpkg-dev1.22.0
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.29-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.0
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.41-5
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1053789: sbuild: should support --env=VAR=VALUE command line option like autopkgtest

[Raphaël Hertzog]

Package: sbuild
Version: 0.85.3
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

Hello,

it would be nice if sbuild supported the --env=VAR=VALUE command line
option like autopkgtest:

   --env=VAR=value
  Set arbitrary environment variable in the build and test.
  Can be specified multiple times.

I know that sbuild keeps the current environment but it does filter it and
getting rid of the filter requires setting up a configuration file I
assume. A bit complicated compared to the expressivenes of the above
command line option that clearly says "yes I want that variable".

This suggestion is the result of some design work in debusine where
we want to make it easy for Debian developers to experiment with
changes that can affect many packages. And we believe that the possibility
of setting up an arbitrary environment variable is important in that
context.

https://salsa.debian.org/freexian-team/debusine/-/issues/180

Thank you for considering that idea!

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sbuild depends on:
ii  adduser 3.137
ii  libsbuild-perl  0.85.3
ii  perl5.36.0-9

Versions of packages sbuild recommends:
ii  autopkgtest  5.30
ii  debootstrap  1.0.132
ii  schroot  1.6.13-3+b2
ii  uidmap   1:4.13+dfsg1-2

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.47.0-2+b1
ii  kmod   30+20230601-2
ii  wget   1.21.4-1+b1

-- no debconf information

Bug#1027276: apt: "apt install" should run "apt update" when some repositories metadata have not been fetched

[Raphaël Hertzog]

Package: apt
Version: 2.5.4
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: arna...@kali.org, raph...@offensive-security.com

Hello,

there are many cases where apt will not have fetched any repository
information yet:
- first run of a container (no metadata fetched to keep container small)
- when the user has manually added a new repository to sources.list
- when running from a live image
- other kind of fresh installation without network

In those situations, itt would be nice if apt could be smarter than this:

┌──(root㉿carbon)-[/work]
└─# apt install nano
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package nano is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'nano' has no installation candidate

Apt could, for instance, inform the user that some repository information
is missing and propose to run it for them.

# apt install nano
Apt is lacking metadata for some repositories. The missing metadata
can be downloaded by running "apt update".
Do you want to execute this command? [Y/n/q]
Get:1 
[...]
Fetched 41.8 MB in 15s (2782 kB/s)
The following NEW packages will be installed:
  nano
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[...]

Typing "q" would "quit" the whole process. "Y" would run apt update and
then follow with the requested installation. "n" would skip apt update and
still try to perform the installation.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 apt depends on:
ii  adduser 3.129
ii  base-passwd 3.6.1
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.40-1
ii  libapt-pkg6.0   2.5.4
ii  libc6   2.36-6
ii  libgcc-s1   12.2.0-9.1
ii  libgnutls30 3.7.8-4
ii  libseccomp2 2.5.4-1+b2
ii  libstdc++6  12.2.0-9.1
ii  libsystemd0 252.3-1

Versions of packages apt recommends:
ii  ca-certificates  20211016

Versions of packages apt suggests:
ii  apt-doc 2.5.4
ii  aptitude0.8.13-5
ii  dpkg-dev1.21.12
ii  gnupg   2.2.40-1
ii  powermgmt-base  1.37
ii  synaptic0.91.2

-- no debconf information

Bug#1020330: pipewire-pulse: Conflict with pulseaudio is badly resolved by apt full-upgrade

[Raphaël Hertzog]

Package: pipewire-pulse
Version: 0.3.58-1
Severity: important
X-Debbugs-Cc: raph...@freexian.com, seb...@debian.org, de...@lists.debian.org

APT will not let me upgrade pipewire-pulse to the latest version because
I have gnome-core installed. It will prefer to deinstall pipewire-pulse:

$ sudo apt full-upgrade
[...]
The following packages were automatically installed and are no longer required:
  libappstream-glib8 libatk1.0-data libmalcontent-ui-0-0 
libnautilus-extension1a libqpdf28
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  nautilus-extension-brasero pipewire-pulse
The following packages have been kept back:
  python3-twisted-bin tryton-client
The following packages will be upgraded:
  gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules 
libspa-0.2-modules nautilus
  nautilus-data pipewire pipewire-bin
8 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
Need to get 3958 kB of archives.
After this operation, 938 kB disk space will be freed.
Do you want to continue? [Y/n] n

If I try to force install pipewire-pulse, it will propose to remove
gnome-core:
$ LANG=C sudo apt install pipewire-pulse
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  hyphen-en-us libappstream-glib8 libatk1.0-data libbox2d2 libfreehand-0.1-1 
libgsf-bin
  libmalcontent-ui-0-0 libmspub-0.1-1 libpagemaker-0.0-0 
libproxy1-plugin-gsettings
  libproxy1-plugin-networkmanager libproxy1-plugin-webkit libqpdf28 
libqxp-0.0-0 libreoffice-draw
  libreoffice-gnome libreoffice-impress libzmf-0.0-0 mythes-en-us
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  gstreamer1.0-pipewire libldacbt-abr2 libpipewire-0.3-0 
libpipewire-0.3-modules libspa-0.2-bluetooth
  libspa-0.2-modules pipewire pipewire-bin
The following packages will be REMOVED:
  gnome gnome-core pulseaudio pulseaudio-module-bluetooth task-gnome-desktop
The following NEW packages will be installed:
  libldacbt-abr2 libspa-0.2-bluetooth
The following packages will be upgraded:
  gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules 
libspa-0.2-modules pipewire
  pipewire-bin pipewire-pulse
7 upgraded, 2 newly installed, 5 to remove and 4 not upgraded.
Need to get 1993 kB of archives.
After this operation, 5930 kB disk space will be freed.
Do you want to continue? [Y/n] n

The only way to get the latest version is to manually provide the working
solution by indicating that we also need libspa-0.2-bluetooth (to satisfy
gnome-core's "pulseaudio-module-bluetooth | libspa-0.2-bluetooth" together
with its "pulseaudio | pipewire-pulse").

$ LANG=C sudo apt install pipewire-pulse libspa-0.2-bluetooth
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libappstream-glib8 libatk1.0-data libmalcontent-ui-0-0 libqpdf28
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  gstreamer1.0-pipewire libldacbt-abr2 libpipewire-0.3-0 
libpipewire-0.3-modules libspa-0.2-modules
  pipewire pipewire-bin
The following packages will be REMOVED:
  pulseaudio pulseaudio-module-bluetooth
The following NEW packages will be installed:
  libldacbt-abr2 libspa-0.2-bluetooth
The following packages will be upgraded:
  gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules 
libspa-0.2-modules pipewire
  pipewire-bin pipewire-pulse
7 upgraded, 2 newly installed, 2 to remove and 4 not upgraded.
Need to get 1993 kB of archives.
After this operation, 5848 kB disk space will be freed.
Do you want to continue? [Y/n]

That looks like it will be a disaster for users doing a dist upgrade.
But I'm not sure what we can do about it.

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.57-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
pn  libspa-0.2-bluetooth  
ii  pulseaudio-utils  15.0+dfsg1-4+b1

-- no debconf information

Bug#1018288: waagent: Debian specific patch breaks kali support

[Raphaël Hertzog]

Package: waagent
Version: 2.7.3.0-1
Severity: important
User: de...@kali.org
Usertags: origin-kali

Hello,

this patch broke kali support:
https://salsa.debian.org/cloud-team/waagent/-/commit/dd8f1771d89bd255f96938f080b02b889da79ad7

The import of "DebianOSBaseUtil" has been dropped while it's clearly used
further down the road:

if distro_name == "kali":
return DebianOSBaseUtil()

Please re-add the import statement. There's a merge request lying around
since one year:
https://salsa.debian.org/cloud-team/waagent/-/merge_requests/3

But that merge request restores it in the wrong order so that would still
keep a diff compared to upstream. I have ask the MR submitter to update
it.

Cheers,

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 waagent depends on:
ii  bind9-host [host]  1:9.18.6-1
ii  ca-certificates20211016
ii  eject  2.38.1-1
ii  fdisk  2.38.1-1
ii  iptables   1.8.8-1
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-server 1:9.0p1-1+b1
ii  openssl3.0.5-2
ii  parted 3.5-1
ii  python33.10.6-1
ii  python3-distro 1.7.0-1
ii  python3-pkg-resources  59.6.0-1.2
ii  sudo   1.9.11p3-1
ii  util-linux 2.38.1-1

waagent recommends no packages.

waagent suggests no packages.

Bug#1016370: RM: python-django-jsonfield -- ROM; Abandoned upstream, replaced by native Django field

[Raphaël Hertzog]

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

Hello,

please remove python-django-jsonfield from unstable. Django 3.2 already
provides a generic JSONField similar to what's provided in
python-django-jsonfield:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield

Given this, python-django-jsonfield is no longer maintained upstream
and should replaced by the above field.

Everybody should switch to the Django native field.

There are no reverse dependencies in unstable.

Thank you,
  Raphaël Hertzog.

Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

[Raphaël Hertzog]

Package: openvpn
Version: 2.6.0~git20220518+dco-2
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@freexian.com

Hello Bernhard,

as Kali is based on Debian testing, our users started to experience
the git snapshot of OpenVPN that you uploaded. Unfortunately, we got
multiple reports that their VPN break because many VPN services ship .opvn
files that rely on --cipher.

At the same time, it's not really reasonable to expect (commercial)
services to be ready for a version of OpenVPN that is not released yet.

Upstream OpenVPN contributors are blaming Debian/Kali for this choice:
https://forums.openvpn.net/viewtopic.php?p=107165#p107154

As such I really believe that this git snapshot should have stayed in
experimental. Why was it uploaded to unstable before its upstream
release?

I assume it was due to OpenSSL 3 becoming the default. However I notice
that upstream released 2.5.7 on May 31 that adds limited support of
OpenSSL 3.x. Can we switch back to 2.5.7 until 2.6 is released upstream?

(We will likely do this in Kali with a version like 2.6.0~really2.5.7)

If we don't want to switch back to 2.5.x, it might make sense to
temporarily revert the backwards incompatible change
that breaks most people's setup, I'm speaking of this commit:
https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c

It seems to be the change that is causing most issues.

Thank you for maintaining such an important package!

Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1

[Raphaël Hertzog]

Package: wireplumber
Version: 0.4.10-2
Severity: important
X-Debbugs-Cc: hert...@debian.org, gland...@debian.org, 
team+pkg-mozi...@tracker.debian.org
Control: affects -1 firefox

Hello,

Following the recommendation of
https://tracker.debian.org/news/1329911/accepted-pipewire-media-session-041-3-source-into-unstable/
I installed "wireplumber". But after having switched, Firefox started to
behave strangely: any time that I would "right click" on a link or a
field, or anywhere where you can expect the right click to open a
contextual menu, it would "freeze" for a varying number of seconds and
it would not display the contextual menu once the freeze was over.

I switched back to pipewire-media-session and I created
/usr/share/pipewire/media-session.d/with-pulseaudio to get the sound back
and it works again now.

I'm not sure how both behaviour are related, but they seem to clearly be
related.

When I had the issue, I tried to open "about:support", it also triggered
one of those freezes but in the end I was able to see that firefox was
using "alsa" as audio-backend.

Now that I switched back to "pipewire-media-session" and that firefox is
now behaving correctly, I see that it uses the "pulse-rust" audio backend.

So somehow, wireplumber + pipewire-pulse is not properly
detected as something that can be controlled with the "pulse-rust" audio
backend when it likely should be that way...

I don't know if this needs a fix in firefox or in wireplumber. I'm
assigning it wireplumber for a start but I have cced Mike Hommey (the
firefox maintainer).

Thank you all for your great work on those packages!

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

Kernel: Linux 5.17.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 wireplumber depends on:
ii  init-system-helpers   1.63
ii  libc6 2.33-7
ii  libglib2.0-0  2.72.2-2
ii  libpipewire-0.3-0 0.3.51-1+b1
pn  libwireplumber-0.4-0  
ii  pipewire  0.3.51-1+b1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.51-1+b1

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  

Bug#1011292: openssh-client: scp -O should be doable with a configuration file entry (in ~/.ssh/config)

[Raphaël Hertzog]

Package: openssh-client
Version: 1:9.0p1-1+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: raph...@freexian.com

dput and dput-ng are using "scp" and don't offer any simple way to
configure command line parameters and the switch to "sftp-behind-the-back"
broke dput for me with some targets (cf #1011063).

I would have liked to be able to add something like this in ~/.ssh/config:

Host deb.freexian.com
UseLegacyScp true

And be done with it. But there's no such option. It would be nice if
upstream could implement this.

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 openssh-client depends on:
ii  adduser   3.121
ii  dpkg  1.21.7
ii  libc6 2.33-7
ii  libedit2  3.1-20210910-1
ii  libfido2-11.11.0-1+b1
ii  libgssapi-krb5-2  1.19.2-2+b2
ii  libselinux1   3.3-1+b2
ii  libssl3   3.0.3-4
ii  passwd1:4.11.1+dfsg1-2
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.1-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
pn  monkeysphere 
ii  ssh-askpass-gnome [ssh-askpass]  1:9.0p1-1+b1

-- no debconf information

Bug#1011291: dput: scp upload method can break due to implicit sftp usage

[Raphaël Hertzog]

Source: dput
Version: 1.1.0
Severity: important
X-Debbugs-Cc: raph...@freexian.com

This is the equivalent of #1011063 for dput instead of dput-ng.

When you run dput with openssh >= 9, and when dput is configured to use
"scp", "scp" will rely on the sftp protocol to do its job (unless you
pass the -O command line parameter).

When the server side has configured a forced command to restrict scp to a
specific directory (which is a good practice given scp's deficiencies),
then scp will badly fail.

Here's an example script that is configured with a ForceCommand associated
to the SSH key used for upload:

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
scp\ *)
exec scp -p -d -t /srv/deb.freexian.com/extended-lts/incoming
;;
chmod\ *)
find /srv/deb.freexian.com/extended-lts/incoming -user 
$(whoami) -type f | xargs --no-run-if-empty chmod 0644
exit 0
;;
*)
echo "ERROR: Forbidden command: $SSH_ORIGINAL_COMMAND"
echo "This SSH access can only be used to upload Debian 
packages."
exit 1
;;
esac


A recent scp will call /usr/lib/sftp-server as the remote command and the
case will match the third case and the sftp protocol will be confused by
the answer.

There's no good way to tweak that script to force sftp-server to be
restricted to a specific directory.

So either you switch to always "sftp" and do some other setup to restrict
sftp (with the Chroot directive), or you switch to "always plain scp"
by passing -O when you call scp.

Thus I'm suggesting that dput starts passing -O to scp when it detects a
recent OpenSSH. Or at least that it offers a way to pass command line
options to scp.

AfAIK ssh_config_options does not work for this. I's not an option that
can be passed to "-o" and it's really specific to scp and not to ssh
(which also gets called for the chmod IIRC).

Note that my "proper" fix to this regression has been to force usage of
sftp and to restrict sftp-server to a chroot, but dput has no support of
sftp so I had to switch to dput-ng. It would certainly makes sense for
dput to gain an sftp method!

Cheers,

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1008773: ftpsync: Using commands with parameters as hooks breaks ftpsync on bullseye/debian 11

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org
Control: affects -1 mirrors

In Kali we have started to switch some mirrors to Debian 11 and ftpsync
started to fail with errors like this:

Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync start
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: We got pushed from 192.99.45.140
/home/archvsync/bin/ftpsync: line 276: local: `--regex=^.*\.hook1$': not a 
valid identifier
/home/archvsync/bin/ftpsync: line 276: local: `--arg=kali': not a valid 
identifier
/home/archvsync/bin/ftpsync: line 276: local: `/home/archvsync/hooks': not a 
valid identifier
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync done with errors

Our ftpsync.conf contains entries like this:

## Configure hooks
HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"
HOOK2="run-parts --regex=^.*\\.hook2\$ --arg=kali /home/archvsync/hooks"
HOOK3="run-parts --regex=^.*\\.hook3\$ --arg=kali /home/archvsync/hooks"
HOOK4="run-parts --regex=^.*\\.hook4\$ --arg=kali /home/archvsync/hooks"
HOOK5="run-parts --regex=^.*\\.hook5\$ --arg=kali /home/archvsync/hooks"

>From a quick glance, it looks like the bash version in bullseye doesn't
like some construct. Here's a minimal reproducer:

$ cat ~/tmp/test.sh
#!/bin/bash

set -e
set -u
set -E

hook () {
ARGS='HOOK[@]'
local "${!ARGS}"
echo "HOOKSCR='$HOOKSCR'"
}

HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"

HOOK=(
HOOKNR=1
HOOKSCR=${HOOK1}
)
hook $HOOK

In buster it works fine:
$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'
$ echo $?
0

In bullseye it fails:
$ bash ~/tmp/test.sh
/home/rhertzog/tmp/test.sh: line 9: local: `--regex=^.*\.hook1$': not a valid 
identifier
/home/rhertzog/tmp/test.sh: line 9: local: `--arg=kali': not a valid identifier
/home/rhertzog/tmp/test.sh: line 9: local: `/home/archvsync/hooks': not a valid 
identifier
$ echo $?
1

It seems that you can quote the variable assignation for HOOKSCR and it
works again:
HOOK=(
HOOKNR=1
HOOKSCR="${HOOK1}"
)

$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on:
ii  postfix [mail-transport-agent]  3.6.4-1+b1
ii  rsync   3.2.3-8

Versions of packages ftpsync recommends:
ii  curl  7.82.0-2

ftpsync suggests no packages.

-- no debconf information

Bug#1005132: drf-yasg-nonfree: File conflicts between two different 1.20.1-1 versions

[Raphaël Hertzog]

Source: drf-yasg-nonfree
Version: 1.20.1-1
Severity: serious
User: de...@kali.org
Usertags: origin-kali

drf-yasg-nonfree 1.20.1-1 was uploaded as source only on January 23th,
the lack of binaries ended up in the package being removed by dak's 
auto-cruft. Then the maintainer rebuilt a new source package while keeping
the 1.20.1-1 version and uploaded it again.

deb.debian.org is a CDN and keeps in cache the package files for a very
long time because they are supposed to be immutable so if you try to
download drf-yasg-nonfree from deb.debian.org you get the first version
of the package while the metadata refers to the second version and as
such you get a checksum error (as I did in Kali, while trying to mirror
bookworm):

Wrong checksum during receive of
'http://deb.debian.org/debian/pool/non-free/d/drf-yasg-nonfree/drf-yasg-nonfree_1.20.1-1.dsc':
md5 expected: 5c87ae878afc6adf6708439e2a0b4e97, got: 
63c6925011f77e02306f451036181a13
sha256 expected: 
2b3265636ef93b490b633cee9897c8462fb1cb42d1fb65226fb5a8601631ecd9, got:
834fa39b7b970704f936fc2a293ca47f9efc1939a62f5a33fcd0cea4e4a0767c
size expected: 2467, got: 2434

This bug is just a request to upload 1.20.1-2 to get rid of this
inconsistency that will last in deb.debian.org for as long as we don't
upload a new version.

The package has been temporarily removed from testing by Julien Cristau
to make sure that mirroring bookworm out of deb.debian.org will work
again shortly.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1003927: debian-cd: Move grub-theme for UEFI boot from debian-cd to debian-installer?

[Raphaël Hertzog]

Package: debian-cd,debian-installer
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

Hello,

we were trying to harmonize our grub theme across all of Kali and we
(re-)discovered that for installer images, the grub theme is actually
handled at the debian-cd level (./data/$RELEASE/grub-theme.in used by
tools/boot/$RELEASE/boot-x86).

I believe that a derivative distribution should not have to fork debian-cd
to be able to customize the grub theme. It would be much more logical if
debian-cd reused files from debian-installer also for all its handling of
grub for UEFI boot. That's why this bug is filed against both packages
together, we really need some coordination here.

Note that this move would also help to fix #982496 where we ask arm64 boot
to make use of the grub theme.

I don't have any concrete proposal or patch but I wanted to have this
properly recorded. For now in Kali we have worked around this limitation
in our build scripts to not have to fork debian-cd and still ship our
own theme:
https://gitlab.com/kalilinux/build-scripts/live-build-config/-/commit/bb399b8bf63635f53d2ab546f41d1924a5c84467

Given that d-i already provides syslinux configuration files, couldn't it
also provide grub configuration files instead of letting debian-cd do its
own grub port of those files?

Cheers,
  Raphaël.

Bug#1003478: python-django: cannot import name 'RequestSite' from partially initialized module 'django.contrib.sites.requests' (most likely due to a circular import)

[Raphaël Hertzog]

Source: python-django
Version: 2:2.2.25-1~deb11u1
Severity: important
Tags: patch
X-Debbugs-Cc: hert...@debian.org

Hello,

Ever since we upgraded tracker.debian.org to Debian 11, I started to get
occasional failures like shown in the traceback below.

File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
  34. response = get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  115. response = self.process_exception_by_middleware(e, 
request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  113. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File "/usr/lib/python3/dist-packages/django/contrib/syndication/views.py" in 
__call__
  39. feedgen = self.get_feed(obj, request)

File "/usr/lib/python3/dist-packages/django/contrib/syndication/views.py" in 
get_feed
  127. current_site = get_current_site(request)

File "/usr/lib/python3/dist-packages/django/contrib/sites/shortcuts.py" in 
get_current_site
  15. from .requests import RequestSite

Exception Type: ImportError at /pkg/gdb/rss
Exception Value: cannot import name 'RequestSite' from partially initialized 
module 'django.contrib.sites.requests' (most likely due to a circular import)
(/usr/lib/python3/dist-packages/django/contrib/sites/requests.py)

I filed this upstream at https://code.djangoproject.com/ticket/33420 and I
was told that this has been fixed recently in the main branch with this
commit:
https://code.djangoproject.com/changeset/78163d1ac4407d59bfc5fdf1f84f2dbbb2ed3443/

But this has not been backported to older branches and it would be nice to
see this fixed in Debian stable (and bullseye-backport for 3.2) for the
benefit of tracker.debian.org and other Django packaged applications.

Cheers,

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.19
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org

Usage of --pin-packages=kali-dev=src:foo results in a file like this
in /etc/apt/preferences.d/autopkgtest-kali-dev

Package:  foo
Pin: release a=kali-dev
Pin-Priority: 995

Unfortunately the "a=kali-dev" only matches on the "Suite" or "Archive"
field in the Release file, and not on the "Codename" field (which in my
caces was the only field available).

I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
another syntax that seems to cover more cases:

Package: *
Pin: release kali-rolling
Pin-Priority: 990

However that syntax doesn't seem to be documented in apt_preferences.
If it's correct and allows to check on either of the 3 fields, then
we should likely use the same syntax in both files.

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.

Cheers,

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 autopkgtest depends on:
ii  apt-utils   2.3.13
ii  libdpkg-perl1.21.1
ii  procps  2:3.3.17-5
ii  python3 3.9.8-1
ii  python3-debian  0.1.42

Versions of packages autopkgtest recommends:
ii  autodep8  0.25

Versions of packages autopkgtest suggests:
pn  fakemachine   
pn  lxc   
pn  lxd   
ii  ovmf  2021.11-1
pn  ovmf-ia32 
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:6.1+dfsg-8+b2
ii  schroot   1.6.10-12
ii  vmdb2 0.24-1

-- no debconf information

Bug#998319: tryton-server: Should provide a ready-to-use production-grade server config

[Raphaël Hertzog]

Package: tryton-server
Version: 5.0.39-1
Severity: normal
X-Debbugs-Cc: raph...@freexian.com

When I deployed tryton-server, I simply followed the advice of
README.Debian and relied on the provided systemd service file
but now after having filed https://bugs.tryton.org/issue10921
I realize that it's (no longer?) the recommended way of deploying
the tryton server.

It would be nice if the Debian package could document a production-grade
way to deploy it and if it could provide everything required to make this
trivial (maybe some apache/nginx config snippet that we can include in a
new virtual host to configure the WSGI handler, or similar).

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 tryton-server depends on:
ii  adduser3.118
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
pn  python 
pn  python-dateutil
pn  python-genshi  
pn  python-lxml
pn  python-pkg-resources   
pn  python-polib   
pn  python-relatorio   
pn  python-sql 
pn  python-werkzeug
pn  python-wrapt   
ii  python33.9.2-3
ii  python3-bcrypt 3.2.0-1
ii  python3-dateutil   2.8.1-6
pn  python3-genshi 
ii  python3-lxml   4.6.3+dfsg-1
pn  python3-passlib
ii  python3-pkg-resources  58.2.0-1
pn  python3-polib  
pn  python3-relatorio  
pn  python3-sql
pn  python3-werkzeug   
ii  python3-wrapt  1.12.1-4+b1

Versions of packages tryton-server recommends:
ii  libreoffice-calc 1:7.2.2-1
ii  libreoffice-writer   1:7.2.2-1
ii  postgresql   14+231
pn  python-bcrypt
pn  python-levenshtein   
pn  python-psycopg2  
pn  python-pydot 
pn  python3-gevent   
ii  python3-html2text2020.1.16-1
ii  python3-levenshtein  0.12.2-2
ii  python3-pil  8.3.2-1
ii  python3-psycopg2 2.9.1-1
ii  python3-pydot1.4.2-1
pn  python3-weasyprint   
ii  ssl-cert 1.1.0+nmu1
ii  unoconv  0.7-2

Versions of packages tryton-server suggests:
ii  postgresql-client-13 [postgresql-client]  13.4-3
ii  postgresql-client-14 [postgresql-client]  14.0-1
pn  python-sphinx 
ii  python3-sphinx4.2.0-5
hi  tryton-client 5.0.33-1
pn  tryton-modules-all
pn  tryton-server-doc 

Bug#996776: RM: logidee-tools -- ROM; no longer maintained and no longer used

[Raphaël Hertzog]

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

The logidee tools are no longer maintained by anybody and I kept them
alive for as long as I had some use for them but the Logidée company
that created them is no longer using them and nobody else in Debian
is using them either (me included).

The package is currently affected by an RC bug that I don't intend
to fix.

Please remove logidee-tools from Debian.

Thank you.

Bug#996703: RM: gnome-shell-timer -- ROM; No upstream maintainer

[Raphaël Hertzog]

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

The upstream maintainer has abandoned this extension a long time ago. I
kept it alive for as long as I was using it but I'm no longer using it
as there's a better maintained alternative (though I haven't packaged it):
https://github.com/blackjackshellac/kitchenTimer
https://extensions.gnome.org/extension/3955/kitchen-timer/ 

So please remove gnome-shell-timer from Debian.

Thank you.

Bug#994808: atftpd: Impossible to upgrade from 0.7.git20210202-3

[Raphaël Hertzog]

Package: atftpd
Version: 0.7.git20210202-3
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org

Hello,

In 0.7.git20210202-4 you fixed the syntax of /etc/default/atftpd but
anyone that installed -1, -2 or -3 has a failed upgrade due to this syntax
mistake. And the error message is very misleading for casual users
and thus not trivial to fix:

Preconfiguring packages ...
/tmp/atftpd.config.b3vwmj: 3: /etc/default/atftpd: 69: not found
atftpd failed to preconfigure, with exit status 127
[...]
Setting up atftpd (0.7.git20210202-4+b1) ...
/var/lib/dpkg/info/atftpd.config: 3: /etc/default/atftpd: 69: not found
dpkg: error processing package atftpd (--configure):
 installed atftpd package post-installation script subprocess returned error 
exit status 127


Unfortunately, the version -3 reached Debian testing (some simple
autopkgtest could have avoided this) and was thus released as part of Kali
and we have many users that have thus installed -3.

Can we please include some upgrade code that detects the broken case and
fix it up?

Thank you in advance.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 atftpd depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.32-4
ii  libpcre3   2:8.39-13
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  tcpd   7.6.q-31
ii  update-inetd   4.51

Versions of packages atftpd recommends:
ii  openbsd-inetd [inet-superserver]  0.20160825-5

Versions of packages atftpd suggests:
ii  logrotate  3.18.1-2

Bug#992966: simple-cdd: fails to validate Release file with a good signature and a signature that can't be checked

[Raphaël Hertzog]

Package: simple-cdd
Version: 0.6.8
Severity: normal
X-Debbugs-Cc: raph...@freexian.com

Right now if you try to use simple-cdd on a stretch or buster system (to
build stretch/buster images), you get failures like this one:

> 2021-08-24 10:45:08 ERROR verify gpg signature exited with code 2
> 2021-08-24 10:45:08 ERROR Last 3 lines of standard error:
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Signature made Tue 24 
> Aug 2021 09:21:34 AM CDT
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg:using RSA 
> key A7236886F3CCCAAD148A27F80E98404D386FA1D9
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Can't check signature: 
> No public key
> 2021-08-24 10:45:08 ERROR Signature verification failed on ['gpg', '--batch', 
> '--no-default-keyring', '--keyring', 
> '/usr/share/keyrings/debian-archive-keyring.gpg', '--keyring', 
> '/srv/install/simple-cdd/.gnupg/pubring.gpg', '--verify', 
> '/srv/install/simple-cdd/tmp/mirror/extrafiles']
> FAILURE:  build-simple-cdd failed, exiting

The problem is that the Release file (and the extrafiles) of stretch and
buster is signed by 4 keys, including the recently added keys for
bullseye. But /usr/share/keyrings/debian-archive-keyring.gpg in
stretch/buster does not (yet) contain the new key and simple-cdd uses `gpg
--verify` which fails with error code 2 as soon as a single signature
can't be verified.

But simple-cdd should fail only if none of the signatures can't be
verified or if some signature fails to verify while the key is present
(a bit like APT does it...). But the absence of a key should not result in
a failure provided that the other signatures are working.

Elements of proof:

$ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release
$ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release.gpg
$ LANG=C gpg --keyring 
/srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg 
--verify Release.gpg Release
gpg: Signature made Sat Aug 14 09:43:24 2021 CEST
gpg:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
gpg: Good signature from "Debian Archive Automatic Signing Key (9/stretch) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: E1CF 20DD FFE4 B89E 8026  58F1 E0B1 1894 F66A EC98
 Subkey fingerprint: 16E9 0B3F DF65 EDE3 AA7F  323C 04EE 7237 B7D4 53EC
gpg: Signature made Sat Aug 14 09:43:25 2021 CEST
gpg:using RSA key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
gpg: Good signature from "Debian Archive Automatic Signing Key (10/buster) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
 Subkey fingerprint: 0146 DC6D 4A0B 2914 BDED  34DB 648A CFD6 22F3 D138
gpg: Signature made Sat Aug 14 10:46:19 2021 CEST
gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: Can't check signature: No public key
gpg: Signature made Sat Aug 14 10:26:43 2021 CEST
gpg:using RSA key 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500
gpg:issuer "debian-rele...@lists.debian.org"
gpg: Good signature from "Debian Stable Release Key (9/stretch) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 067E 3C45 6BAE 240A CEE8  8F6F EF0F 382A 1A7B 6500
$ echo $?
2
$ LANG=C gpg --keyring 
/srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg 
--with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: error reading key: No public key
$ LANG=C gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg 
--with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9
pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
  1F89983E0081FDE018F3CC9673A4F27B8DD47936
uid   [ unknown] Debian Archive Automatic Signing Key (11/bullseye) 

sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]
  A7236886F3CCCAAD148A27F80E98404D386FA1D9



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro

Bug#991167: ftpsync: Please document how to contribute

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

Looking at the README in https://salsa.debian.org/mirror-team/archvsync
I saw no instructions on how to contribute, nor any indication of where
bugs are welcome.

It would be nice to tell users that found an issue that they can file bugs
in the Debian BTS and that they can submit merge requests for patches (or
that they can send patch to the BTS if that's your preference).

IMO it would make sense to allow GitLab issues on the project too for
"upstream change", but YMMV.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  rsync   3.2.3-4

Versions of packages ftpsync recommends:
ii  curl  7.74.0-1.3+b1

ftpsync suggests no packages.

-- no debconf information

Bug#991166: ftpsync: Contents* and dep11/* metadata are incorrectly updated in stage1

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

In Kali we encountered many failed "apt update" with a mirror that was
slow to update and it always failed due to invalid checksums on
"Contents-amd64.gz".

Looking more closely, I discovered that "ftpsync" was not really kept
up-to-date with other files that are listed in the Release file and that
should be updated in stage 2 instead of stage 1.

I noticed in particular that dep11/* should also be handled like we
do for "i18n/*". And we might want to do it also for MD5SUMS/SHA256SUMS
files of debian-installer... although updates there are not very frequent.

Thank you in advance!

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  rsync   3.2.3-4

Versions of packages ftpsync recommends:
ii  curl  7.74.0-1.3+b1

ftpsync suggests no packages.

-- no debconf information

Bug#990281: APT make duplicate HTTP requests with mirrorbits

[Raphaël Hertzog]

Package: apt
Version: 2.2.3
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org
Control: found -1 apt/2.3.6

Hi,

in Kali we have been testing "mirrorbits" as a replacement for
"mirrorbrain". Our current mirrorbrain setup runs on http.kali.org
and mirrorbits runs on http-staging.kali.org.

We have seen strange behaviour from APT with mirrorbits where APT
seems to send some HTTP requests multiple times. Whereas with mirrorbrain,
it's fine.

$ cat /etc/apt/sources.list
deb http://http-staging.kali.org/kali kali-rolling main contrib non-free
$ apt install --dry-run aria2

The following additional packages will be installed:
  libaria2-0 libsqlite3-0 libssh2-1
The following NEW packages will be installed:
  aria2 libaria2-0 libsqlite3-0 libssh2-1
0 upgraded, 4 newly installed, 0 to remove.

$ sudo apt -y -d -q -o Debug::Acquire::http=true install aria2 2>&1 | grep -A1 
^GET
GET /kali/pool/main/s/sqlite3/libsqlite3-0_3.34.1-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /pub/Linux/kali/pool/main/s/sqlite3/libsqlite3-0_3.34.1-3_amd64.deb HTTP/1.1
Host: ftp.jaist.ac.jp
--
GET /kali/pool/main/libs/libssh2/libssh2-1_1.9.0-2_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /pub/Linux/kali/pool/main/libs/libssh2/libssh2-1_1.9.0-2_amd64.deb HTTP/1.1
Host: ftp.jaist.ac.jp
--
GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1
Host: mirror.anigil.com
--
GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1
Host: http-staging.kali.org
--
GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1
Host: mirror.anigil.com


As you can see, APT seems to send the same HTTP request to mirrorbits
multiple times, but the final download happens only once per file.
Depending on the exact case, we get fewer duplicate requests, but it's
easily reproducible.

We tried to compare the HTTP headers returned by the two servers and
mirrorbits/nginx sets those headers in addition to the usual ones when it
sends its redirect answer (compared to mirrorbrain/apache):

Content-Length: 0
Connection: keep-alive
Cache-Control: private, no-cache

I have also reproduced the issue with apt 2.3.6 in unstable.

If you want to reproduce, just tweak your sources.list and install
http://http.kali.org/pool/main/k/kali-archive-keyring/kali-archive-keyring_2020.2_all.deb
to have the kali archive key to authenticate the repository.

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Architecture: x86_64

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.20-1
ii  libapt-pkg6.0   2.1.18
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.0-5
ii  libseccomp2 2.5.1-1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.2-5

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.20.7.1kali1
ii  gnupg2.2.20-1
pn  powermgmt-base   

-- no debconf information

Bug#986843: smuxi-engine: Crash when editing server information

[Raphaël Hertzog]

Package: smuxi-engine
Version: 1.1-1
Severity: important
X-Debbugs-Cc: hert...@debian.org

I'm trying to edit server information through the gnome frontend and when
I validate the changes I get this crash:


Exception Type:
System.ArgumentNullException

Exception Message:
Value cannot be null.
Parameter name: value

Exception StackTrace:
  at Smuxi.Engine.UserConfig.Set (System.String key, System.Object value) 
[0x00079] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/UserConfig.cs:159
  at Smuxi.Engine.UserConfig.set_Item (System.String key, System.Object value) 
[0x4] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/UserConfig.cs:101
  at (wrapper remoting-invoke-with-check) 
Smuxi.Engine.UserConfig.set_Item(string,object)
  at Smuxi.Engine.ServerModel.Save (Smuxi.Engine.UserConfig config) [0x00135] 
in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/ServerModel.cs:232
  at Smuxi.Engine.ServerListController.SetServer (Smuxi.Engine.ServerModel 
server) [0x00029] in 
/build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/ServerListController.cs:178
  at Smuxi.Frontend.Gnome.ServerListView.Edit (Smuxi.Engine.ServerModel server) 
[0x0006e] in 
/build/smuxi-gSW6uG/smuxi-1.1/src/Frontend-GNOME/Preferences/ServerListView.cs:183
  at Smuxi.Frontend.Gnome.ServerListView.OnEditButtonClicked (System.Object 
sender, System.EventArgs e) [0x0002a] in 
/build/smuxi-gSW6uG/smuxi-1.1/src/Frontend-GNOME/Preferences/ServerListView.cs:256


I have attached the screenshot of the screen with the data that I'm
saving.

I do use a ssh connection between the engine and the frontend. The
engine side is running smuxi-engine 1.0.7-5.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 smuxi-engine depends on:
ii  liblog4net1.2-cil1.2.10+dfsg-7.1
ii  libmono-corlib4.5-cil6.8.0.105+dfsg-3
ii  libmono-posix4.0-cil 6.8.0.105+dfsg-3
ii  libmono-sqlite4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-core4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system-data-linq4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-data4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system-drawing4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-runtime-serialization4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-runtime4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-web4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-xml-linq4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system-xml4.0-cil6.8.0.105+dfsg-3
ii  libmono-system4.0-cil6.8.0.105+dfsg-3
ii  libnini1.1-cil   1.1.0+dfsg.2-5.1
ii  mono-runtime 6.8.0.105+dfsg-3

smuxi-engine recommends no packages.

Versions of packages smuxi-engine suggests:
pn  oidentd | ident-server  

-- no debconf information

Bug#984547: isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'"

[Raphaël Hertzog]

Package: isenkram
Version: 0.45
Severity: serious
X-Debbugs-Cc: hert...@debian.org

I saw this in my logs:
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: Traceback (most recent call 
last):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]:   File "/usr/bin/isenkramd", 
line 400, in uevent_callback
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if not 
is_pkg_installed(pkg):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]:   File "/usr/bin/isenkramd", 
line 340, in is_pkg_installed
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if 0 == line.find("ii "):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: TypeError: argument should 
be integer or bytes-like object, not 'str'

It looks like that the package was not fully tested in a Python 3 context
as this is a common failure when you mix binary content and text content.

Cheers,

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 isenkram depends on:
ii  gir1.2-gtk-3.0 3.24.24-3
ii  gir1.2-gudev-1.0   234-1
ii  gir1.2-notify-0.7  0.7.9-3
ii  gir1.2-packagekitglib-1.0  1.2.2-2
ii  isenkram-cli   0.45
ii  packagekit 1.2.2-2
ii  python33.9.1-1
ii  python3-gi 3.38.0-2

isenkram recommends no packages.

isenkram suggests no packages.

-- no debconf information

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Raphaël Hertzog]

Package: general
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org
Control: affects -1 ftp.debian.org dpkg-dev

Hi people,

After having been bitten (in Kali) by failures to import Debian packages
because a PGP signature file has been modified [1], this lead me to think
about this problem space and I concluded that the way we are storing
such signatures is not appropriate.

Those files are not really meant to be immutable:
- signing keys can expire and be revoked, upstream might want to update
  signatures of already released tarballs
- the set of "upstream release managers" might evolve over time and the
  official signature to use might change...

If we assume that the archive is meant to store immutable content
under a given filename (and to me that requirement seems to be a good
idea), then we should question ourselves whether we really want to store
those signatures in a filename that's associated to the upstream version.
They should either be tied to the Debian revision (so that they can change
over time without any new upstream release) or be incorporated in the
Debian tarball.

After all the key to verify those signatures is already stored in the
Debian tarball (when you use the uscan feature to verify those
signatures), so why not store the signature there as well?

I originally filed this in https://bugs.debian.org/949962 against
ftp.debian.org but the bug got closed because it's not really the
responsibility of ftpmasters to change this. So I'm starting a wider
discussion to gather feedback of all interested parties (at least
Guillem as dpkg maintainer). I won't drive this much further but
I wanted to have it properly recorded and considered.

Cheers,

[1] For details it happened in dbus-glib:
https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file
https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a
different .asc file

Bug#982496: debian-cd: Support grub theme on arm64

[Raphaël Hertzog]

Package: debian-cd
Version: 3.1.33
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

We're working on getting Kali to work as a VM on the Apple M1 and so we
are trying to build arm64 installer images with simple-cdd (and thus
debina-cd). In this process, Steev Klimaszewski 
discovered that the grub configuration used for the EFI boot on arm64 does
not take advantage of any theming, contrary to amd64/i386.

It would be nice if we could fix this by enabling the grub theme
everywhere. However this doesn't look entirely trivial as the theming
is handled through a mixture of code in tools/boot/bullseye/boot-x86
and tools/boot/bullseye/parse_isolinux, and arm64 is not relying on
isolinux at all.

Steve, your input is thus most welcome.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 debian-cd depends on:
ii  apt2.1.18
ii  bc 1.07.1-2+b2
ii  bzip2  1.0.8-4
ii  cpp4:10.2.1-1
ii  curl   7.74.0-1
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.20.7.1
ii  genisoimage9:1.1.11-3.2
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.20.7.1
ii  lynx   2.9.0dev.6-1
ii  make   4.3-4
ii  perl [libdigest-sha-perl]  5.32.1-2
ii  tofrodos   1.7.13+ds-5
ii  wget   1.21-1+b1
ii  xorriso1.5.2-1

Versions of packages debian-cd recommends:
ii  dosfstools   4.1-2
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.26-1
ii  netpbm   2:10.0-15.3+b2
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  syslinux-utils   3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

Bug#981007: systemd: default syscall-filter list is incomplete for i386 and breaks tar

[Raphaël Hertzog]

Package: systemd
Version: 241-7~deb10u5
Severity: important
Tags: patch upstream
User: de...@kali.org
Usertags: origin-kali
Control: fixed -1 systemd/244.1-1

We are running dist-upgrade tests within systemd-nspawn containers
and since we upgraded to buster, our i386 tests, running on an amd64
host machine, are failing with messages like this one:

---
Fetched 7044 MB in 1617d 11h 20min 34s (50 B/s)
tar: ./control: Cannot utime: Operation not permitted
tar: ./md5sums: Cannot utime: Operation not permitted
tar: ./shlibs: Cannot utime: Operation not permitted
tar: ./symbols: Cannot utime: Operation not permitted
tar: ./triggers: Cannot utime: Operation not permitted
tar: .: Cannot utime: Operation not permitted
tar: Exiting with failure status due to previous errors
dpkg-deb: error: tar subprocess returned error exit status 2
---

Thanks to https://bugzilla.redhat.com/show_bug.cgi?id=1770154 I understood
that this is actually related to the lack of some system calls
in the default whitelist maintained by systemd.

This has been fixed with this upstream pull request:
https://github.com/systemd/systemd/pull/13975

So this issue is only affecting the stable version 241-7~deb10u5.
The version in buster-backports is fine, as is the version in
testing/unstable.

But it would still be nice if this could be fixed via a point release.

Thanks for maintaining systemd!

Bug#979233: lshw-gtk: Drop recommends on menu

[Raphaël Hertzog]

Package: lshw-gtk
Version: 02.18.85-0.5
Severity: normal

Please drop the recommends on "menu". AFAIK the menu package does not add any
functionality to your application. Applications should not
depend/recommend menu, only window managers or desktop that benefit from
the menu system should trigger its installation.

Thank you!

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lshw-gtk depends on:
ii  libc6   2.31-6
ii  libgcc-s1   10.2.1-3
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.4-1
ii  libgtk2.0-0 2.24.33-1
ii  libstdc++6  10.2.1-3

Versions of packages lshw-gtk recommends:
pn  menu  
ii  pciutils  1:3.7.0-5
ii  usbutils  1:013-1

lshw-gtk suggests no packages.

-- no debconf information

Bug#977355: UserWarning: cannot parse package relationship "i", returning it raw

[Raphaël Hertzog]

Package: python3-debian
Version: 0.1.35
Severity: normal

The package tracker started to generate annoying messages in its cron job:

/usr/lib/python3/dist-packages/debian/deb822.py:1403: UserWarning: cannot parse 
package
relationship "i", returning it raw
  ' relationship "%s", returning it raw' % raw)

This is due to a buggy package containing a dependency on "i" (it's
libmagics++-dev, bug filed already) but I don't see any reason for deb822
to fail on this dependency. It's a very short package name that we should
likely not allow in Debian but I don't a reason to not be able to parse
it (in particular when nothing else in the build machinery choked on that
dependency, starting with dpkg-gencontrol).

Please update the __dep_RE regex to accept single-character dependencies:

   1421 __dep_RE = re.compile(
   1422 r'^\s*(?P[a-zA-Z0-9.+\-]{2,})'

Cheers,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 python3-debian depends on:
ii  python3  3.9.0-4
ii  python3-chardet  3.0.4-7
ii  python3-six  1.15.0-2

Versions of packages python3-debian recommends:
ii  python3-apt  2.1.7

Versions of packages python3-debian suggests:
ii  gpgv  2.2.20-1

-- no debconf information

Bug#976823: uscan: have an official way to document that there's no upstream source anymore

[Raphaël Hertzog]

Package: devscripts
Version: 2.20.5
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: jel...@debian.org

There are cases where there's no upstream source anymore so we have
nothing to put into debian/watch (either because there never was a real
upstream or because the upstream repository disappeared). At the same
time, the lack of debian/watch might just mean that someone forgot to
create the file. So what I usually do is that I create a debian/watch
file documenting the fact that I can't put anything in it... but the
result is that uscan will fail and tools like the janitor bot that try to
import a new upstream release will log an error, drawing the attention of
developers on this specific package.

Example:
$ cat debian/watch 
version=3
# This is just a script that was posted on a website. No download available.
$ uscan --report; echo $?
1

It would be better if there was a way to document that there's no upstream
source and let uscan succeed while printing a warning. Maybe with a
specific optional flag say "no-upstream".

Desired result:
$ cat debian/wa
version=4
opts=no-upstream
$ uscan --report; echo $?
uscan info: no upstream sources are known, skipping without failing
0

Thank you for considering this request!

Bug#976372: gnome-shell-xrdesktop: FTBFS and is not built against latest libmutter

[Raphaël Hertzog]

Package: gnome-shell-xrdesktop
Version: 3.36.1-2
Severity: serious
Justification: FTBFS
User: de...@kali.org
Usertags: origin-kali

I noticed gnome-shell-xrdesktop depends on libmutter-6-0 which is obsolete
in unstable. I wanted to rebuild the package to have it link against a
newer mutter version but the package failed to build for me:

PKG_CONFIG_PATH:
Called `/usr/bin/pkg-config --modversion xrdesktop-0.14` -> 1

CMake binary for MachineChoice.BUILD is not cached
None of 'CMAKE' are defined in the environment, not changing global flags.
CMake binary missing from cross or native file, or env var undefined.
Trying a default CMake fallback at cmake
Did not find CMake 'cmake'
Found CMake: NO
No CMake binary for machine 0 not found. Giving up.
Run-time dependency xrdesktop-0.14 found: NO (tried pkgconfig)

../meson.build:107:0: ERROR: Dependency "xrdesktop-0.14" not found, tried 
pkgconfig
dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu --libdir=/usr/lib 
-Dbash_completion=true -Denable-networkmanager=yes -Denable-systemd=yes 
returned exit code 1
make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-shell-xrdesktop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  evolution-data-server3.38.1-2
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.38.0-2
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.0-1
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2-1
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.2-1
ii  gir1.2-gtk-3.0   3.24.23-3
ii  gir1.2-gweather-3.0  3.36.1-1
ii  gir1.2-ibus-1.0  1.5.23-1
pn  gir1.2-mutter-6  
ii  gir1.2-nm-1.01.27.91-2
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-29
ii  gir1.2-rsvg-2.0  2.50.2+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.1-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.1-2
pn  gnome-shell-common-xrdesktop 
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-4
ii  libcairo21.16.0-4
ii  libecal-2.0-13.38.1-2
pn  libedataserver-1.2-24
ii  libgcr-base-3-1  3.38.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-8
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.1-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.3-1
ii  libglib2.0-bin   2.66.3-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.38.2-1
ii  libgraphene-1.0-01.10.2-1
ii  libgstreamer1.0-01.18.1-1
ii  libgtk-3-0   3.24.23-3
pn  libgulkan-0.14-0 
ii  libical3 3.0.8-2
pn  libinputsynth-0.13-0 
ii  libjson-glib-1.0-0   1.6.0-1
pn  libmutter-6-0
ii  libnm0   

Bug#976083: lintian: reports spelling-error-in-changelog for duplicate word even when punctuation and empty line separate two words

[Raphaël Hertzog]

Package: lintian
Version: 2.103.0
Severity: normal

I have this warning:
W: ccrypt: spelling-error-in-changelog Debian Debian (duplicate word) Debian

And I believe it matches this part of the changelog entry:
  * Configure git-buildpackage for Debian

  [ Debian Janitor ]

For me, it should not report this duplicate word. The empty line (and even
the square bracket) should be enough to not trigger the duplicate word
warning.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils2.35.1-3
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b6
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004003-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)

[Raphaël Hertzog]

Package: sbuild
Version: 0.80.0
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

I know that multiple developers started using podman and buildah to manage
containers where they build their Debian packages. With user namespace
supports, this allows rootless building (like the "unshare" chroot
mode)... you don't even need root to setup the "build chroot" since those
are containers that you can download (or rebuild if you prefer).

Thus it would be nice if sbuild had a "podman" chroot mode where it could
use podman containers to build the packages.

A "sbuild-create-oci" command would also be helpful to build the various
container images, either from scratch (so that you don't have to trust
images that you download) or on top of pre-existing OCI images (to
save time and effort). That command should not be hard to build on top
of buildah.

Some links:
http://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html
https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.80.0
ii  perl5.32.0-5

Versions of packages sbuild recommends:
ii  autopkgtest  5.15
ii  debootstrap  1.0.123
ii  schroot  1.6.10-11

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.45.6-1
ii  kmod   27+20200310-2
ii  wget   1.20.3-1+b3

-- no debconf information

Bug#975974: ITP: gnome-shell-extension-hamster -- GNOME Shell extension for the Hamster Time Tracker

[Raphaël Hertzog]

Package: wnpp
Severity: wishlist
Owner: Raphaël Hertzog 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gnome-shell-extension-hamster
  Version : 0.10.0+git20200509
  Upstream Author : Hamster Project
* URL : https://github.com/projecthamster/hamster-shell-extension
* License : GPL-3+
  Programming Lang: Javascript
  Description : GNOME Shell extension for the Hamster Time Tracker

The package will be maintained together with hamster-time-tracker in
https://salsa.debian.org/projecthamster-team/

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

[Raphaël Hertzog]

Package: dh-python
Version: 4.20200925
Followup-For: Bug #972726
User: de...@kali.org
Usertags: origin-kali

I made the same observation today. It seems to me that the breaks
was a bit too large. You can likely keep the same effect by using a
versioned breaks that would not conflict with the provides of
python-is-python2.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 dh-python depends on:
ii  python33.8.6-1
ii  python3-distutils  3.8.6-1

dh-python recommends no packages.

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

-- no debconf information

Bug#973861: apt: http acquire method still failing with "Undetermined error" or "Data left in the buffer"

[Raphaël Hertzog]

Package: apt
Version: 2.1.11
Severity: important
User: de...@kali.org
Usertags: origin-kali

Hello,

while the frequence of the error has really decreased since the last set
of fixes, we still have occasional failures where apt ends
up with "Undetermined error" or "Data left in the buffer".

It's pretty annoying for APT to be unreliable in that way.

The last case that triggered this bug for us in Kali was within a net-install
in d-i:

[...]
Nov  5 23:15:48 in-target: Err:2130 http://kali.download/kali kali-rolling/main 
amd64 llvm-10 amd64 1:10.0.1-6
Nov  5 23:15:48 in-target:   Undetermined Error [IP: 104.18.102.100 80]
[...]
Nov  5 23:16:14 in-target: Fetched 2,651 MB in 5min 20s (8,274 kB/s)
Nov  5 23:16:14 in-target: E: Failed to fetch 
http://kali.download/kali/pool/main/l/llvm-toolchain-10/llvm-10_10.0.1-6_amd64.deb
  Undetermined Error [IP: 104.18.102.100 80]
Nov  5 23:16:14 in-target: E: Unable to fetch some archives, maybe run apt-get 
update or try with --fix-missing?
Nov  5 23:16:14 in-target: tasksel: apt-get failed (100)

To try to reproduce it I invite you to configure a sources.lists with
kali.download as mirror. Do this on a server with a very good connection.

deb http://kali.download/kali kali-rolling main contrib non-free

And try to run this in a loop until you reproduce it:
# apt --download-only install kali-linux-large
# apt clean

It took me two tries to reproduce it... I had a download rate of more than
50MB/s.

I tried to reproduce it with debugging options enabled:
# while true; do apt -y --download-only install kali-linux-large -o 
Debug::Acquire::http=true -o Debug::pkgAcquire::Worker=true 2>log || break; apt 
clean; done

And I managed to reproduce it too but after a dozen of tries this time.
The log file is huge but it failed with this:
E: Failed to fetch 
http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
  Undetermined Error [IP: 104.18.102.100 80]

And here are the lines that seem relevant for that specific file:

 -> 
http:600%20URI%20Acquire%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aFilename:%20/var/cache/apt/archives/partial/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aExpected-SHA256:%202347b5fd2bb741cf87f01b4243e591d094445227bea63de5d53555752b322a45%0aExpected-SHA1:%20c465af27c6a567320661436f509043587735f996%0aExpected-MD5Sum:%206d11858477ba16d6b2ffb2d518dd2735%0aExpected-Checksum-FileSize:%20300172%0aTarget-Repo-URI:%20http://kali.download/kali/%0aTarget-Site:%20http://kali.download/kali%0aTarget-Release:%20kali-rolling%0aTarget-Base-URI:%20http://kali.download/kali/%0aTarget-Component:%20main%0aTarget-Codename:%20kali-rolling%0aTarget-Suite:%20kali-rolling%0aTarget-Architecture:%20all%0aTarget-Type:%20deb%0a%0a
 <- 
http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/x/xorg-sgml-doctools/xorg-sgml-doctools_1.11-1_all.deb%0aMessage:%20Waiting%20for%20headers
GET /kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0%2bdfsg1-5_all.deb 
HTTP/1.1^M
Host: kali.download^M
User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M
^M
[...]
 <- 
http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aMessage:%20Waiting%20for%20headers
GET 
/kali/pool/main/i/imagemagick/libmagickcore-6.q16-6-extra_6.9.11.24%2bdfsg-1%2bb1_amd64.deb
 HTTP/1.1^M
Host: kali.download^M
User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M
^M

Answer for: 
http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
HTTP/1.1 200 OK^M
Date: Fri, 06 Nov 2020 08:10:09 GMT^M
Content-Type: application/octet-stream^M
Content-Length: 300172^M
Connection: close^M
Set-Cookie: __cfduid=dcd44a60d11f41fb354d70f7609be4f1a1604650209; expires=Sun, 
06-Dec-20 08:10:09 GMT; path=/; domain=.kali.download; HttpOnly; SameSite=Lax^M
Last-Modified: Sun, 29 Dec 2019 15:40:32 GMT^M
ETag: "5e08c8f0-4948c"^M
Expires: Mon, 04 Nov 2030 08:10:09 GMT^M
Cache-Control: public, max-age=31536^M
CF-Cache-Status: HIT^M
Age: 264899^M
Accept-Ranges: bytes^M
cf-request-id: 063e342a5da30f222e81^M
Server: cloudflare^M
CF-RAY: 5edd5623cfbda30f-ORD^M
^M
 <- 
http:200%20URI%20Start%0aLast-Modified:%20Sun,%2029%20Dec%202019%2015:40:32%20+%0aSize:%20300172%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
 <- 
http:400%20URI%20Failure%0aTransient-Failure:%20true%0aMessage:%20Undetermined%20Error%20[IP:%20104.18.102.100%2080]%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
 -> 

Bug#970749: nautilus-dropbox: New upstream release available

[Raphaël Hertzog]

Package: nautilus-dropbox
Version: 2019.02.14-1
Severity: wishlist

Version 2020.03.04 is available in the upstream git repository:
https://github.com/dropbox/nautilus-dropbox/tags

It would be nice to have this version packaged.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 nautilus-dropbox depends on:
ii  gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5
ii  gir1.2-gtk-3.0   3.24.22-1
ii  libc62.31-3
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.22-1
ii  libnautilus-extension1a  3.36.3-1
ii  procps   2:3.3.16-5
ii  python3  3.8.2-3
ii  python3-gi   3.36.1-1

Versions of packages nautilus-dropbox recommends:
ii  python3-gpg  1.14.0-1

Versions of packages nautilus-dropbox suggests:
ii  nautilus  3.36.3-1

-- no debconf information

Bug#969458: perl crash in eval command trying a failing require statement

[Raphaël Hertzog]

Package: perl
Version: 5.30.3-4
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-d...@lists.debian.org
Control: found -1 5.32.0-2

In Kali, any source package build started to fail with a mysterious
error:
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127

After quite some investigation, I tracked this down to perl exiting with
that error code in the middle of an eval statement that should have failed:
https://sources.debian.org/src/dpkg/1.20.5/scripts/Dpkg/Vendor.pm/#L166

The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
code should fallback to Dpkg::Vendor::Debian and this works a few times
but after multiples calls, at some point it no longer works and the
require statement in the eval block just never returns, it seems to crash
the perl interpreter.

You can easily reproduce this on an up-to-date testing or unstable system
with dpkg 1.20.5 (that version is failing, the former version we had
in Kali was 1.19.7 and it was not triggering this issue):

$ sudo tee /etc/dpkg/origins/kali >/dev/null < Vendor: Kali
> Vendor-URL: https://www.kali.org/
> Parent: debian
> Bugs: https://bugs.kali.org/
> END
$ sudo ln -sf kali /etc/dpkg/origins/default
$ apt source hello
[...]
$ cd hello-*
$ dpkg-buildpackage -S
[...]
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building hello using existing ./hello_2.10.orig.tar.gz
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127


Note that I only reproduce this with "3.0 (quilt)" source packages. Native
packages have different code paths likely involving fewer calls to
run_vendor_hook() and the problem can't be reproduced with such a source
package.

I can also reproduce the bug with version 5.32.0-2 available in
experimental.

FWIW I'm working around this issue in Kali with the attached patch but
this really smells like a bug in perl, thus I'm reporting it here.

Guillem, I believe the attached patch should be applied to dpkg in any
case as it's a small optimization that avoids running the evaled code too
often.

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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 perl depends on:
ii  dpkg   1.20.5
ii  libperl5.305.30.3-4
ii  perl-base  5.30.3-4
ii  perl-modules-5.30  5.30.3-4

Versions of packages perl recommends:
ii  netbase  6.1

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.36-2+b1
ii  make 4.3-4
ii  perl-doc 5.30.3-4

-- no debconf information
>From 75631da697b9d2c5b3ff2c54bc225fc55d3ab9c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Thu, 3 Sep 2020 11:26:58 +0200
Subject: [PATCH] Work-around a perl crash during any package build

Somehow perl doesn't like the multiple execution of the eval code that tries
to "require Dpkg::Vendor::Kali;" and at some point perl just exits with
an error code of 127 when it tries to execute this line of code. When
it happens, the eval doesn't return.

To avoid the multiple execution of this code, we cache the result of the
lookup made on the parent vendor as the good result for the current
vendor as well.

There's likely some bug in perl here and somehow the update from
dpkg 1.19.7 to dpkg 1.20.5 started to trigger that bug.
---
 scripts/Dpkg/Vendor.pm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Vendor.pm b/scripts/Dpkg/Vendor.pm
index 196159156..5b8f66fd8 100644
--- a/scripts/Dpkg/Vendor.pm
+++ b/scripts/Dpkg/Vendor.pm
@@ -174,10 +174,12 @@ sub get_vendor_object {
 
 my $info = get_vendor_info($vendor);
 if (defined $info and defined $info->{'Parent'}) {
-return get_vendor_object($info->{'Parent'});
+$obj = get_vendor_object($info->{'Parent'});
 } else {
-return get_vendor_object('Default');
+$obj = get_vendor_object('Default');
 }
+$OBJECT_CACHE{$vendor} = $obj;
+return $obj;
 }
 
 =item run_vendor_hook($hookid, @params)
-- 
2.28.0

Bug#969173: RM: openvas openvas-libraries openvas-cli openvas-manager -- ROM; replaced by gvm

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-security-to...@lists.debian.org

Hello,

GVM is replacing OpenVAS and a bunch of source packages have been
renamed or are obsolete.

Please remove the following source packages from unstable:
* openvas(replaced by gvm)
* openvas-libraries  (replaced by gvm-libs)
* openvas-cli(obsolete)
* openvas-manager(replaced by gvmd)

Thank you!

Bug#968111: lintian-brush: is confused about non-existing pending changes

[Raphaël Hertzog]

Package: lintian-brush
Version: 0.74
Severity: normal

$ git clone https://salsa.debian.org/debian/cpputest.git
$ cd cpputest
$ lintian-brush
/home/rhertzog/tmp/cpputest: Please commit pending changes first.
$ LANG=C git status --ignored
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean


I have no idea why lintian-brush believes that there are pending
changes...

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.2-3
ii  python3-breezy   3.1.0-5
ii  python3-debian   0.1.37
ii  python3-debmutate0.4
ii  python3-distro-info  0.23
ii  python3-dulwich  0.20.2-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.10-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.3-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2
ii  lintian  2.87.0
ii  python3-asyncpg  0.20.1-1+b1
ii  python3-bs4  4.9.1-1
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
ii  postgresql-common  215

-- no debconf information

Bug#968108: lintian: False positive for no-dh-sequencer, maybe due to unexpected target dependency

[Raphaël Hertzog]

Package: lintian
Version: 2.87.0
Severity: normal

In the zim package I have this in debian/rules:

# Zim build system requires those environment variables...
export USER=fake
export HOME=$(CURDIR)/debian/fake-home

$(CURDIR)/debian/fake-home:
mkdir $(CURDIR)/debian/fake-home

%: $(CURDIR)/debian/fake-home
dh $@ --with python3 --buildsystem=pybuild


And this triggers the no-dh-sequencer tag... but as you can see, I'm using
it! It's just that I have a dependency on the target to ensure some
prerequisite.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libipc-run3-perl  0.048-2
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libperlio-gzip-perl   0.19-1+b6
ii  libsereal-decoder-perl4.018+ds-1
ii  libsereal-encoder-perl4.018+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  lzip  1.21-7
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#968041: lintian: fails with internal error

[Raphaël Hertzog]

Package: lintian
Version: 2.87.0
Followup-For: Bug #968041
User: de...@kali.org
Usertags: origin-kali

I get the same error for lzop as well as for unzip. You need to add a
dependency on lzop too.

Running lintian...
No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
eval {...} called at /usr/share/perl5/IPC/Run3.pm line 380
IPC::Run3::run3(ARRAY(0x55da48fbdba8), undef, SCALAR(0x55da48fbb910), 
SCALAR(0x55da48f85b38)) called at /usr/share/perl5/Lintian/IPC/Run3.pm line 74
Lintian::IPC::Run3::safe_qx("lzop", "--test", 
"/tmp/lintian-pool-nyK9V4GzPA/pool/a/aflplusplus/afl++-doc_2.6"...) called at 
/usr/share/lintian/checks/files/compressed/lzo.pm line 42

Lintian::files::compressed::lzo::visit_installed_files(Lintian::files::compressed::lzo=HASH(0x55da4ca63430),
 Lintian::Index::Item=HASH(0x55da484e5778)) called at 
/usr/share/perl5/Lintian/Check.pm line 88

Lintian::Check::visit_files(Lintian::files::compressed::lzo=HASH(0x55da4ca63430),
 "installed") called at /usr/share/perl5/Lintian/Check.pm line 117

Lintian::Check::run(Lintian::files::compressed::lzo=HASH(0x55da4ca63430)) 
called at /usr/share/perl5/Lintian/Check/Info.pm line 261

Lintian::Check::Info::run_check(Lintian::Check::Info=HASH(0x55da47da06b0), 
Lintian::Processable::Binary=HASH(0x55da47e60d50), 
Lintian::Group=HASH(0x55da45ed65d0)) called at 
/usr/share/perl5/Lintian/Group.pm line 419
eval {...} called at /usr/share/perl5/Lintian/Group.pm line 419
Lintian::Group::process(Lintian::Group=HASH(0x55da45ed65d0), 
HASH(0x55da45ef3e20), HASH(0x55da474e8730), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/perl5/Lintian/Pool.pm line 179
Lintian::Pool::process(Lintian::Pool=HASH(0x55da45eb97e0), 
Lintian::Profile=HASH(0x55da476f3920), SCALAR(0x55da474e8b80), 
HASH(0x55da474e8730), GLOB(0x55da477d6b80), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/lintian/commands/lintian.pm line 809
lintian::main() called at /usr/bin/lintian line 148
eval {...} called at /usr/bin/lintian line 148
internal error: cannot run files/compressed/lzo check on package 
binary:afl++-doc/2.66c-1/all
warning: skipping check of binary:afl++-doc/2.66c-1/all
No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
eval {...} called at /usr/share/perl5/IPC/Run3.pm line 380
IPC::Run3::run3(ARRAY(0x55da4ca633a0), undef, SCALAR(0x55da4c9e5690), 
SCALAR(0x55da4cc5fe48)) called at /usr/share/perl5/Lintian/IPC/Run3.pm line 74
Lintian::IPC::Run3::safe_qx("unzip", "-l", 
"/tmp/lintian-pool-nyK9V4GzPA/pool/a/aflplusplus/afl++-doc_2.6"...) called at 
/usr/share/lintian/checks/files/compressed/zip.pm line 45

Lintian::files::compressed::zip::visit_installed_files(Lintian::files::compressed::zip=HASH(0x55da4cde1618),
 Lintian::Index::Item=HASH(0x55da484ea570)) called at 
/usr/share/perl5/Lintian/Check.pm line 88

Lintian::Check::visit_files(Lintian::files::compressed::zip=HASH(0x55da4cde1618),
 "installed") called at /usr/share/perl5/Lintian/Check.pm line 117

Lintian::Check::run(Lintian::files::compressed::zip=HASH(0x55da4cde1618)) 
called at /usr/share/perl5/Lintian/Check/Info.pm line 261

Lintian::Check::Info::run_check(Lintian::Check::Info=HASH(0x55da47da05a8), 
Lintian::Processable::Binary=HASH(0x55da47e60d50), 
Lintian::Group=HASH(0x55da45ed65d0)) called at 
/usr/share/perl5/Lintian/Group.pm line 419
eval {...} called at /usr/share/perl5/Lintian/Group.pm line 419
Lintian::Group::process(Lintian::Group=HASH(0x55da45ed65d0), 
HASH(0x55da45ef3e20), HASH(0x55da474e8730), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/perl5/Lintian/Pool.pm line 179
Lintian::Pool::process(Lintian::Pool=HASH(0x55da45eb97e0), 
Lintian::Profile=HASH(0x55da476f3920), SCALAR(0x55da474e8b80), 
HASH(0x55da474e8730), GLOB(0x55da477d6b80), 
Lintian::Output::Standard=HASH(0x55da45c221c0)) called at 
/usr/share/lintian/commands/lintian.pm line 809
lintian::main() called at /usr/bin/lintian line 148
eval {...} called at /usr/bin/lintian line 148
internal error: cannot run files/compressed/zip check on package 
binary:afl++-doc/2.66c-1/all
warning: skipping check of binary:afl++-doc/2.66c-1/all


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils  2.35-1
ii  bzip2 

Bug#968003: lintian: bad name for duplicate-globbing-patterns and redundant-globbing-patterns

[Raphaël Hertzog]

Package: lintian
Version: 2.87.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I was hit with those errors (reproducible with commit
cd6b90a5295aa5a171a1ac9c3c51590f568ca075 in the openvas-scanner git
repository):

E: openvas-scanner source: duplicate-globbing-patterns 
tools/greenbone-nvt-sync.in in lines 12 12
E: openvas-scanner source: redundant-globbing-patterns 
[tools/greenbone-nvt-sync.in tools/greenbone-nvt-sync.in] for 
tools/greenbone-nvt-sync.in

I have multiple issues:

1/ it's not clear that the problem is in the copyright file, I first
looked up tools/greenbone-nvt-sync.in to look what was on line 12
please rename to
{duplicate,redundant}-globbing-patterns-in-debian-copyright for example.

2/ why do I have the same line number twice in the first error?

3/ minor, but ideally we would only report one of the two errors when it
applies to the same file...

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libipc-run3-perl  0.048-2
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libperlio-gzip-perl   0.19-1+b6
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  lzip  1.21-7
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#967905: glibc: Provide a libc6-lse package on arm64

[Raphaël Hertzog]

Source: glibc
Version: 2.31-2
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: st...@kali.org, rbal...@ubuntu.com

Hello,

in Kali we are providing many images for ARM devices and some of the ARM
devices that we support have support for the LSE (Large System Extensions)
atomics. We would like to be able use a version of glibc with LSE support
enabled to see whether we can get better performances.

Ubuntu is already shipping a libc6-lse package on arm64 and it would be
nice if Debian could do the same. Balint Reczey (in CC) implemented the
support in Ubuntu, maybe he can share some hints on what's involved and
whether we should expect some related issues.

The patch used by Ubuntu looks like this one:
https://git.launchpad.net/ubuntu/+source/glibc/commit/?id=d38433a40db82a14c006bb9f411d9fc22b594fa4
(except the hunk on debian/testsuite-xfail-debian.mk which is the other
change in that same upload)

Can you consider applying a similar change?

Thank you in advance for your feedback.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#966465: open-vm-tools-desktop: Stop recommending obsolete xserver-xorg-input-vmmouse

[Raphaël Hertzog]

Package: open-vm-tools-desktop
Version: 2:11.1.0-2
Severity: minor
User: de...@kali.org
Usertags: origin-kali

The package still recommends xserver-xorg-input-vmmouse but the package is
no longer available. It has been dropped a long time ago.

Please drop the recommends on this package.

Thank you!

Bug#966368: lintian gets stuck when run by sbuild within rebuildd

[Raphaël Hertzog]

Package: lintian
Version: 2.85.0
Severity: important
User: de...@kali.org
Usertags: origin-kali

In Kali, our build daemons run "rebuildd" with a build script that calls
sbuild --run-lintian. Since lintian 2.85 (I believe 2.84.0 is not affected),
the build process get stuck at the point when lintian is run. I see two lintian
processes (a parent and its child) and both are stuck in epoll_pwait()
according to strace.

In normal (non-verbose mode) there's no output of lintian before it gets stuck:
Example in this build log:
http://buildd-amd64.kali.org/build-logs/golang-github-projectdiscovery-gologger_1.0.0-0kali1-kali-dev-amd64-20200724-124452.3196.log

When I add the --debug option you see this:
http://buildd-amd64.kali.org/build-logs/kali-meta_2020.3.10-kali-dev-amd64-20200727-132744.3202.log

The last lines are like this:
N: Check script control-files for binary:kali-tools-forensics/2020.3.10/amd64 
done (0.015s)
N: Running check: cron on binary:kali-tools-forensics/2020.3.10/amd64  ...
N: Check script cron for binary:kali-tools-forensics/2020.3.10/amd64 done 
(0.009s)
N: Running check: cruft on binary:kali-tools-forensics/2020.3.10/amd64  ...
N: Check script cruft for binary:kali-tools-forensics/2020.3.10/amd64 done 
(0.015s)
N: Running check: deb-format on binary:kali-tools-forensics/2020.3.10/amd64  ...

The process tree is like this:
kalibui+ 32428  0.0  0.0  19640  3252 ?Ss   13:28   0:00  \_ /bin/sh 
/srv/build.kali.org/bin/build kali-meta 2020.3.10 amd64 kali-dev
kalibui+ 32431  0.2  0.1  89316 33428 ?S13:28   0:00  \_ 
/usr/bin/perl /usr/bin/sbuild --no-source --run-lintian --lintian-opts=-I 
--debug --nolog --apt-update --apt-upgrade --no-apt-distupgrade --arch=amd64 -d 
kali-dev --arch-all /srv/build.kali.org/build/work/kali-meta_2020.3.10.dsc
kalibui+ 32436  0.1  0.0  88388 30100 ?S13:28   0:00  \_ 
/usr/bin/perl /usr/bin/sbuild --no-source --run-lintian --lintian-opts=-I 
--debug --nolog --apt-update --apt-upgrade --no-apt-distupgrade --arch=amd64 -d 
kali-dev --arch-all /srv/build.kali.org/build/work/kali-meta_2020.3.10.dsc
root  4007  0.0  0.0  66528  6480 ?S13:28   0:00  \_ 
schroot -d /build/kali-meta-E2qWUi -c 
kali-dev-amd64-sbuild-a3951a2c-b417-47f2-915c-bb7f546b39ff --run-session -q -u 
kalibuild -p -- lintian -I --debug kali-meta_2020.3.10_amd64.changes 
kali-meta_2020.3.10.dsc
kalibui+  4008  3.3  0.2 123596 76080 ?S13:28   0:03  
\_ lintian -I --debug kali-meta_2020.3.10_amd64.changes kali-meta_2020.3.10.dsc
kalibui+  5628  0.0  0.2 123732 69692 ?S13:28   0:00
  \_ lintian -I --debug kali-meta_2020.3.10_amd64.changes 
kali-meta_2020.3.10.dsc

The open files are like this:
# ls -al /proc/4008/fd /proc/5628/fd
/proc/4008/fd:
total 0
dr-x-- 2 kalibuild kalibuild  0 Jul 27 13:38 .
dr-xr-xr-x 8 kalibuild kalibuild  0 Jul 27 13:28 ..
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:38 0 -> /dev/null
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 1 -> pipe:[689890348]
lr-x-- 1 kalibuild kalibuild 64 Jul 27 13:38 11 -> pipe:[689938177]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 13 -> 
/srv/build.kali.org/build/logs/i3-gaps_4.18.1-0kali2-kali-dev-i386-20200724-200857.3199.log
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 2 -> pipe:[689890348]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 3 -> 
/srv/build.kali.org/db/rebuildd.log
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 4 -> 
/srv/build.kali.org/db/rebuildd.log
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:38 5 -> socket:[8970131]
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:38 6 -> anon_inode:[eventpoll]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:38 7 -> 
/run/schroot/mount/kali-dev-amd64-sbuild-a3951a2c-b417-47f2-915c-bb7f546b39ff/dev/null
lr-x-- 1 kalibuild kalibuild 64 Jul 27 13:38 8 -> pipe:[689938176]
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:38 9 -> socket:[528586941]

/proc/5628/fd:
total 0
dr-x-- 2 kalibuild kalibuild  0 Jul 27 13:28 .
dr-xr-xr-x 8 kalibuild kalibuild  0 Jul 27 13:28 ..
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:28 0 -> /dev/null
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:28 1 -> pipe:[689890348]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:28 10 -> pipe:[689938176]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:28 12 -> pipe:[689938177]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:28 2 -> pipe:[689890348]
lrwx-- 1 kalibuild kalibuild 64 Jul 27 13:28 3 -> anon_inode:[eventpoll]
lr-x-- 1 kalibuild kalibuild 64 Jul 27 13:28 6 -> pipe:[689942617]
l-wx-- 1 kalibuild kalibuild 64 Jul 27 13:28 7 -> pipe:[689942617]
lr-x-- 1 kalibuild kalibuild 64 Jul 27 13:28 8 -> pipe:[689942618]

And the strace output is like this:
# strace -p 4008 -p 5628
strace: Process 4008 attached
strace: Process 5628 attached
[pid  5628] getpid( 
[pid  4008] getpid( 
[pid  5628] <... getpid resumed> )  = 5628
[pid  4008] <... getpid resumed> )  = 4008
[pid 

Bug#966024: lintian: send-patch tag is not properly detecting "Forwarded: not-needed"

[Raphaël Hertzog]

Package: lintian
Version: 2.85.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I have the following tags:
I: i3-gaps source: send-patch 
debian/patches/Disable-a-failing-test-due-to-source-package-not-being-gi.patch
I: i3-gaps source: send-patch 
debian/patches/Use-correct-shebang-for-perl-scripts.patch

But I have put the "Forwarded: not-needed" field:
$ head -n 10 debian/patches/*.patch
==> 
debian/patches/Disable-a-failing-test-due-to-source-package-not-being-gi.patch 
<==
From: =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
Date: Wed, 22 Jul 2020 11:24:19 +0200
Subject: Disable a failing test due to source package not being git
 controlled

Forwarded: not-needed
---
 testcases/t/193-ipc-version.t | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


==> debian/patches/Use-correct-shebang-for-perl-scripts.patch <==
From: =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
Date: Wed, 22 Jul 2020 12:26:10 +0200
Subject: Use correct shebang for perl scripts

Forwarded: not-needed
---
 contrib/dump-asy.pl | 2 +-
 contrib/gtk-tree-watch.pl   | 2 +-
 contrib/i3-wsbar| 2 +-
 contrib/per-workspace-layout.pl | 2 +-


Maybe the DEP3 parser of Lintian does not properly support the split
headers between real headers and pseudo-headers... but this is allowed
by DEP3:
https://dep-team.pages.debian.net/deps/dep3/
> The meta-information would be stored in one or two headers: sets of
> RFC-2822-like fields. [...] A header always ends on the first empty
> line. Free-form comments can follow and should be considered as
> supplementary lines of the long description (see detailed explanations
> of the field). A second header (the “pseudo-header”) can start on any
> new paragraph.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lintian depends on:
ii  binutils  2.34.90.20200706-1
ii  bzip2 1.0.8-3
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.014+ds-1
ii  libsereal-encoder-perl4.014+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.3.4-3
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

[Raphaël Hertzog]

Package: lintian
Version: 2.83.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

In this package https://gitlab.com/kalilinux/packages/i3-gaps we have the
following lintian errors:

E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3
E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3-sensible-pager

But they are wrong:

$ grep -r sensible-pager src/
src/bindings.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
errorfilename);
src/config_parser.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
errorfilename);

The program is calling i3-sensible-pager (provided in the same package)
and not "sensible-pager".

Cheers,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lintian depends on:
ii  binutils  2.34.90.20200706-1
ii  bzip2 1.0.8-3
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.014+ds-1
ii  libsereal-encoder-perl4.014+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.3.4-3
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#966013: devscripts: "salsa ls" started to report archived projects and it's not desired

[Raphaël Hertzog]

Package: devscripts
Version: 2.20.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

In the pkg-security team, we have some scripts that uses "salsa ls" to
figure out the list of projects and we parse its output to generate a
.mrconfig file.

Today, I wanted to update the reference .mrconfig file and found out
that there were many new projects... in fact all the "new" projects are
not new, they are old projects that are archived.

I'm 100% sure that "salsa ls" used to report only non-archived projects
and IMO it should continue to do that. Maybe it should have a command line
option to include archived projects... but the default is best kept
compatible with past behaviour, and it should not list archived projects.

Regards,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 devscripts depends on:
ii  dpkg-dev  1.20.5
ii  fakeroot  1.24-1
ii  file  1:5.38-5
ii  gnupg 2.2.20-1
ii  gnupg22.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.30-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004000-1
ii  libwww-perl   6.46-1
ii  patchutils0.3.4-3
ii  perl  5.30.3-4
ii  python3   3.8.2-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.7
ii  at  3.1.23-1+b1
ii  curl7.68.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.06.24
ii  dput-ng [dput]  1.29
ii  equivs  2.3.1
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.20.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-2
ii  licensecheck3.0.47-1
ii  lintian 2.83.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-6
ii  pristine-tar1.48
ii  python3-apt 2.1.3
ii  python3-debian  0.1.37
ii  python3-magic   2:0.4.15-4
ii  python3-requests2.23.0+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.26-3
ii  strace  5.5-3
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
ii  autopkgtest   5.13.1
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1+b1
ii  build-essential   12.8
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.2
pn  devscripts-el 
ii  diffoscope150
pn  disorderfs
ii  dose-extra5.0.1-14+b3
pn  duck  
ii  faketime  0.9.7-3
pn  gnuplot   
ii  how-can-i-help17
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.13.0-1
ii  libfile-desktopentry-perl 0.22-2
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3300-1
ii  libyaml-syck-perl 1.32-2
pn  mozilla-devscripts
ii  mutt  1.14.5-1
ii  openssh-client [ssh-client]   1:8.3p1-1
ii  piuparts  1.1.1
ii  postgresql-client 12+215
ii  postgresql-client-11 [postgresql-client]  11.7-0+deb10u1
ii  postgresql-client-12 [postgresql-client]  12.3-1+b1
ii  quilt 0.66-2.1
pn  ratt  
pn  

Bug#964774: freetype: libfreetype6-udeb should not depend on non-udeb libbrotli1

[Raphaël Hertzog]

Source: freetype
Version: 2.10.2+dfsg-2
Severity: serious
Tags: d-i
Justification: breaks d-i
User: de...@kali.org
Usertags: origin-kali

Builds of the debian-installer are failing lately due to changes in
libfreetype6-udeb. They are failing with:

The following packages have unmet dependencies:
 libfreetype6-udeb : Depends: libbrotli1 (>= 1.0.7) but it is not installable

An udeb is not allowed to depend on non-udeb packages and there's no
udeb package for libbrotli1.

Please either disable the feature that requires brotli support in the
udeb (meaning that you have to implement a double build like in some other
packages providing udebs, see openssh or cairo) or work with the brotli
maintainer to add the required udeb.

If you go for the latter, it would be nice to disable the brotli
dependency entirely until the udeb has been added and is gone through
NEW.

We don't think that support of WOFF fonts is important in the context of
debian-installer so after a quick chat in #debian-boot, the consensus
is leaning towards disabling that dependency in a separate udeb build.

Cheers,

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

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

Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification

[Raphaël Hertzog]

Package: smuxi-frontend-gnome
Version: 1.0.7-5
Severity: important

When I get a notification while I'm not im my smuxi window, if I
immediately click on the highlighted channel, then the application freezes
and I have no other choice than to kill it.

If I first click in a non-highlighted channel, and then click on the
highlighted channel, then everything works as usual.

This is very annoying...

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 smuxi-frontend-gnome depends on:
ii  libdbus-glib2.0-cil 0.6.0-1
ii  libdbus2.0-cil  0.8.1-2
ii  libglade2.0-cil 2.12.40-3
ii  libglib2.0-02.64.3-1
ii  libglib2.0-cil  2.12.40-3
ii  libgtk2.0-0 2.24.32-4
ii  libgtk2.0-cil   2.12.40-3
ii  libgtkspell02.0.16-1.3
ii  liblog4net1.2-cil   1.2.10+dfsg-7
ii  libmessagingmenu12.10-cil   1.0.1-1
ii  libmono-corlib4.5-cil   6.8.0.105+dfsg-3
ii  libmono-posix4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-core4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-web4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system4.0-cil   6.8.0.105+dfsg-3
ii  libnotify0.4-cil0.4.0~r3032-7
ii  librsvg2-common 2.48.4+dfsg-1
ii  mono-runtime6.8.0.105+dfsg-3
ii  smuxi-engine1.0.7-5

Versions of packages smuxi-frontend-gnome recommends:
ii  gnome-shell [notification-daemon]  3.36.2-1
ii  notification-daemon3.20.0-4
ii  ssh-askpass-gnome [ssh-askpass]1:8.2p1-4

smuxi-frontend-gnome suggests no packages.

-- no debconf information

Bug#962042: smuxi-frontend-gnome: clicking on a link does not open it in the web browser

[Raphaël Hertzog]

Package: smuxi-frontend-gnome
Version: 1.0.7-5
Severity: important

I have been a happy smuxi user for years but for a few months now I'm no
longer able to click on links... I can left click but nothing happens, the URL
no longer opens in the web browser. Same goes with right click + selecting
the open menu entry.

I tried to strace it and saw this:
[pid 779574] access("/usr/bin/xdg-open", X_OK) = 0
[pid 779574] write(1, "2020-06-02 14:33:45,415 [Thread Pool Worker] ERROR 
Smuxi.Frontend.Gnome.Frontend - OpenLink(): opening URL: 
'https://pbs.twimg.com/media/ESpweBhXgAAefGF?format=jpg=small' 
failed\nSystem.ComponentModel.Win32Exception (0x80004005): Cannot find the 
specified file\n  at System.Diagnostics.Process.StartWithShellExecuteEx 
(System.Diagnostics.ProcessStartInfo startInfo) [0x00129] in 
:0 \n  at System.Diagnostics.Process.Start () 
[0x00038] in :0 \n  at (wrapper 
remoting-invoke-with-check) System.Diagnostics.Process.Start()\n  at 
System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo 
startInfo) [0x0001e] in :0 \n  at 
System.Diagnostics.Process.Start (System.String fileName) [0x6] in 
:0 \n  at 
Smuxi.Frontend.Gnome.Frontend+c__AnonStorey6.<>m__0 (System.Object ) 
[0xf] in /build/smuxi-1.0.7/src/Frontend-GNOME/Frontend.cs:945 \n", 992 


I have no idea why the code is generating this exception.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 smuxi-frontend-gnome depends on:
ii  libdbus-glib2.0-cil 0.6.0-1
ii  libdbus2.0-cil  0.8.1-2
ii  libglade2.0-cil 2.12.40-3
ii  libglib2.0-02.64.2-1
ii  libglib2.0-cil  2.12.40-3
ii  libgtk2.0-0 2.24.32-4
ii  libgtk2.0-cil   2.12.40-3
ii  libgtkspell02.0.16-1.3
ii  liblog4net1.2-cil   1.2.10+dfsg-7
ii  libmessagingmenu12.10-cil   1.0.1-1
ii  libmono-corlib4.5-cil   6.8.0.105+dfsg-3
ii  libmono-posix4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-core4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-web4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system4.0-cil   6.8.0.105+dfsg-3
ii  libnotify0.4-cil0.4.0~r3032-7
ii  librsvg2-common 2.48.4+dfsg-1
ii  mono-runtime6.8.0.105+dfsg-3
ii  smuxi-engine1.0.7-5

Versions of packages smuxi-frontend-gnome recommends:
ii  gnome-shell [notification-daemon]  3.36.2-1
ii  notification-daemon3.20.0-4
ii  ssh-askpass-gnome [ssh-askpass]1:8.2p1-4

smuxi-frontend-gnome suggests no packages.

-- no debconf information

Bug#959716: live-build: 0140-remove-log-files.hook.chroot fails with fs.protected_regular = 2 and files in sticky directories

[Raphaël Hertzog]

Package: live-build
Version: 1:20191221
Severity: important
User: de...@kali.org
Usertags: origin-kali

live-build has been failing when run in Debian Testing and when your live
image includes a package like postgresql-12 which creates a log directory
with the sticky bit set (o+t):

2020-05-04 12:22:55] lb chroot_hooks
P: Begin executing hooks...
/root/0140-remove-log-files.hook.chroot: 8: cannot create 
/var/log/postgresql/postgresql-12-main.log: Permission denied
E: config/hooks/normal/0140-remove-log-files.hook.chroot failed (exit 
non-zero). You should check for errors.

After investigation and with the help of #debian-kernel, it turns out that
this is due to a recent procps change. Since version 2:3.3.16-1 the
package is setting some supplementary hardening restrictions in
/usr/lib/sysctl.d/protect-links.conf

The one that's causing us trouble here is "fs.protected_regular = 2"
because /var/log/postgresql is a group writable directory with the sticky
bit set:
(live)root@x260-buxy:/# ls -al /var/log/postgresql/
total 8
drwxrwxr-t  2 root postgres 4096 mai4 09:34 .
drwxr-xr-x 15 root root 4096 mai4 09:36 ..
-rw-r-  1 postgres adm 0 mai4 09:34 postgresql-12-main.log
(live)root@x260-buxy:/# :>/var/log/postgresql/postgresql-12-main.log
bash: /var/log/postgresql/postgresql-12-main.log: Permission denied

To me it really seems like live-build is doing nothing wrong... but at the
same time, the default change is likely desirable as well.

So I guess we will have to work around it in live-build.

Simple solution with truncate:
# truncate --no-create --size=0 /var/log/postgresql/postgresql-12-main.log

More complicated solution, detect sticky directories and run the command
as the user owning the file.

-- Package-specific info:

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 live-build depends on:
ii  debootstrap  1.0.123

Versions of packages live-build recommends:
ii  apt-utils   2.0.2
ii  bzip2   1.0.8-2
ii  cpio2.13+dfsg-2
ii  file1:5.38-4
ii  live-boot-doc   1:20190614
ii  live-config-doc 11.0.1
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages live-build suggests:
ii  e2fsprogs  1.45.6-1
pn  mtd-utils  
ii  parted 3.3-4

-- no debconf information

Bug#955478: nmu: python3.8_3.8.2-1

[Raphaël Hertzog]

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

nmu python3.8_3.8.2-1 . ANY . unstable . -m "rebuild against glibc 2.30"
nmu python3.7_3.7.7-1 . ANY . unstable . -m "rebuild against glibc 2.30"

Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954582 and
https://bugzilla.samba.org/show_bug.cgi?id=14100 I believe we need
to bin-nmu python3.8 so that we have a version of
/usr/include/x86_64-linux-gnu/python3.8/pyconfig.h that does not have
"#define HAVE_STROPTS_H 1"

We should probably also do it for python 3.7, though I'm not sure if
anything is affected by this.

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

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

Bug#955474: FTBFS: fatal error: stropts.h: No such file or directory

[Raphaël Hertzog]

Source: samba
Version: 2:4.11.5+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: de...@kali.org
Usertags: origin-kali

Trying to rebuild samba in sid fails with:

[2422/4221] Linking bin/default/source4/kdc/libdb-glue.so
08:56:24 runner ['/usr/bin/gcc', 
'-Wl,--version-script=/<>/bin/default/source4/kdc/db-glue.vscript',
 '-shared', '-Wl,-h,libdb-glue.so.0', 
'source4/librpc/gen_ndr/ndr_irpc_c.c.18.o', 'source4/kdc/db-glue.c.18.o', 
'source4/kdc/sdb.c.10.o', 
'-o/<>/bin/default/source4/kdc/libdb-glue.so', '-Wl,-Bstatic', 
'-Wl,-Bdynamic', '-L/<>/bin/default/nsswitch', 
'-L/<>/bin/default/libcli/registry', 
'-L/<>/bin/default/source4/libcli/ldap', 
'-L/<>/bin/default/nsswitch/libwbclient', 
'-L/<>/bin/default/libcli/dns', 
'-L/<>/bin/default/libds/common', 
'-L/<>/bin/default/lib/socket', 
'-L/<>/bin/default/libcli/cldap', 
'-L/<>/bin/default/libcli/nbt', 
'-L/<>/bin/default/source4/lib/socket', 
'-L/<>/bin/default/auth/gensec', 
'-L/<>/bin/default/lib/addns', 
'-L/<>/bin/default/libcli/smb', 
'-L/<>/bin/default/source4/lib/http', 
'-L/<>/bin/default/source4/libcli', 
'-L/<>/bin/default/lib/dbwrap', 
'-L/<>/bin/default/source4/lib/events', 
'-L/<>/bin/default/third_party/aesni-intel', 
'-L/<>/bin/default/lib/tdb_wrap', 
'-L/<>/bin/default/source4/auth/kerberos', 
'-L/<>/bin/default/lib/ldb-samba', 
'-L/<>/bin/default/libcli/auth', 
'-L/<>/bin/default/libcli/ldap', 
'-L/<>/bin/default/lib/krb5_wrap', 
'-L/<>/bin/default/libcli/util', 
'-L/<>/bin/default/source3', 
'-L/<>/bin/default/source4/cluster', 
'-L/<>/bin/default/lib', 
'-L/<>/bin/default/lib/util', 
'-L/<>/bin/default/librpc', 
'-L/<>/bin/default/lib/param', 
'-L/<>/bin/default/source4/librpc', 
'-L/<>/bin/default/auth/credentials', 
'-L/<>/bin/default/source4/dsdb', 
'-L/<>/bin/default/source4/heimdal_build', 
'-L/<>/bin/default/lib/replace', 
'-L/<>/bin/default/source4/lib/messaging', 
'-L/<>/bin/default/auth', 
'-L/<>/bin/default/libcli/security', '-L/usr/local/lib', 
'-L/usr/local/lib', '-lsamba-security', '-lcommon-auth', '-lMESSAGING', 
'-lreplace', '-lcom_err-samba4', '-lsamdb', '-lsamba-credentials', 
'-lndr-samba4', '-lkrb5-samba4', '-ldcerpc', '-lsamba-hostconfig', '-lndr', 
'-lMESSAGING-SEND', '-lserver-id-db', '-lsamba-sockets', '-lsamba-util', 
'-lndr-samba', '-lsamba-debug', '-ltalloc-report', '-lcluster', 
'-lmessages-util', '-lroken-samba4', '-lsamba-errors', '-lkrb5samba', 
'-lcli-ldap-common', '-lsamdb-common', '-lcliauth', '-lldbsamba', '-lauthkrb5', 
'-ltdb-wrap', '-lutil-tdb', '-laesni-intel', '-levents', '-lgssapi-samba4', 
'-ldbwrap', '-lndr-standard', '-lndr-krb5pac', '-lndr-nbt', '-lasn1-samba4', 
'-lheimbase-samba4', '-lwind-samba4', '-lhcrypto-samba4', '-lhx509-samba4', 
'-lsmbclient-raw', '-lhttp', '-lcli-smb-common', '-laddns', '-lgensec', 
'-ltevent-util', '-ldcerpc-samba', '-lnetif', '-lcli-nbt', '-ldcerpc-binding', 
'-lcli-cldap', '-lserver-role', '-lmessages-dgm', '-linterfaces', 
'-lsocket-blocking', '-liov-buf', '-lgenrand', '-lutil-setid', '-ltime-basic', 
'-lsys-rw', '-lasn1util', '-lflag-mapping', '-lCHARSET3', '-lsamba3-util', 
'-lsmbconf', '-lsmb-transport', '-lclidns', '-lsamba-modules', '-lwbclient', 
'-lcli-ldap', '-lmsghdr', '-lutil-reg', '-lsmbd-shim', '-lwinbind-client', 
'-lcap', '-lcups', '-lldap', '-llber', '-lnsl', '-lutil', '-lresolv', '-lz', 
'-lsystemd', '-lgnutls', '-lpthread', '-lldb', '-ltalloc', '-ljansson', 
'-ltalloc', '-lcrypt', '-lbsd', '-ltdb', '-ltevent', '-ltalloc', '-ldl', 
'-Wl,-z,relro', '-Wl,-z,now', '-Wl,--as-needed', '-Wl,-z,relro,-z,now', 
'-Wl,-no-undefined', '-Wl,--export-dynamic', '-Wl,--as-needed']
In file included from ../../source4/heimdal_build/krb5-types.h:8,
 from ../../source4/heimdal/lib/krb5/krb5.h:42,
 from ../../lib/replace/system/kerberos.h:33,
 from ../../auth/credentials/pycredentials.c:35:
../../lib/replace/system/network.h:91:10: fatal error: stropts.h: No such file 
or directory
   91 | #include 
  |  ^~~
compilation terminated.


What is weird is that this include is protected by #ifdef:

#ifdef HAVE_STROPTS_H
#include 
#endif

And that the configure log shows its absence:
Checking for header stropts.h: 08:49:46 runner 
['/usr/bin/gcc', '-D_SAMBA_BUILD_=4', '-DHAVE_CONFIG_H=1', '-g', '-O2', 
'-fdebug-prefix-map=/<>=.', '-fstack-protector-strong', 
'-Wformat', '-Werror=format-security', '-MMD', '-D_GNU_SOURCE=1', 
'-D_XOPEN_SOURCE_EXTENDED=1', '../../test.c', '-c', 
'-o/<>/bin/.conf_check_31eea1eb63d757d192f105191215e3cc/testbuild/default/test.c.1.o',
 '-Wdate-time', '-D_FORTIFY_SOURCE=2']
no 


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

Kernel: Linux 4.19.0-6-amd64 (SMP 

Bug#955344: RM: pyrit -- ROM; no python 3 version in sight

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal

Please remove pyrit from unstable, cf discussions in #937521.
There's no Python 3 version in sight currently.

We can always bring it back if the alluded python 3 rewrite happens at
some point.

(Requesting this as a member of the pkg-security team maintaining that
package)

Bug#954860: lintian: absolute-symbolic-link-target-in-source duplicates source-contains-unsafe-symlink

[Raphaël Hertzog]

Package: lintian
Version: 2.55.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I don't see the point of "absolute-symbolic-link-target-in-source" since
"source-contains-unsafe-symlink" is already triggered on such files.

Please remove that newly added tag.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lintian depends on:
ii  binutils 2.34-4
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.46-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-perl 4.02000-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-5
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#954090: override: tasksel:admin/optional

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal
User: de...@kali.org
Usertags: origin-kali

tasksel 3.57 changed its priority to optional and d-i is now installing it
when it needs it so it doesn't matter that it's no longer installed after
a debootstrap.

Please update the override accordingly.

Thank you.

Bug#952594: autopkgtest: lxd autopkgtest fails on Debian/Kali where lxd is not available

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.11
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Running the DEP-8 tests of autopkgtest fails in Debian/Kali because lxd is
not available and debian/tests/control requires it to run
debian/tests/lxd.

I would suggest to drop "lxd" from the Depends and install it manually
at the top of debian/tests/lxd. If it's not available, then the script
should just exit gracefully.

Example of failure in Kali where we run tests in qemu:
https://autopkgtest.kali.org/packages/a/autopkgtest/

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 autopkgtest depends on:
ii  apt-utils   1.8.4
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.16-1+b1
ii  python3 3.7.5-3
ii  python3-debian  0.1.36

Versions of packages autopkgtest recommends:
ii  autodep8  0.22

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20191122.bd85bf54-1
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:4.2-3
ii  schroot   1.6.10-9
ii  vmdb2 0.13.2+git20191220-1

-- no debconf information

Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

[Raphaël Hertzog]

Package: user-setup
Version: 1.83
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
the systemd-sulogin-shell binary run by rescue.service and
emergency.service now adds the --force flag for the sulogin call
when SYSTEMD_SULOGIN_FORCE is set to 1 in the environment.

https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c
explains that the expectation is that distributions should now
put service override files to set this environment variable.

Thus user-setup should create the appropriate configuration file when
the root account is not configured. Maybe this should be controlled
by some low priority debconf question as the password-less login through
the rescue boot entry can be seen as a security issue by some.

Cheers,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 user-setup depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  passwd 1:4.8.1-1

user-setup recommends no packages.

user-setup suggests no packages.

Bug#949962: ftp.debian.org: Storing upstream signatures next to file archives is problematic

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I first wanted to report that it's too easy to introduce conflicting files
with the same name in the case of upstream signatures (*.asc files
uploaded with the original tarballs) because it's really easy to drop
them in a subsequent upload, get them forgotten by dak and reintroduce a
conflicting file later one.

Consider dbus-glib:
https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file
https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a
different .asc file

And I wanted to suggest to not forget files for as long as the
corresponding source package is still there...

But after further thoughts, it appears to me that it's not a good idea to
store such files in that way... those files are not really meant to be
immutable:
- signing keys can expire and be revoked, upstream might want to update
  signatures of already released tarballs
- the set of "upstream release managers" might evolve over time and the
  official signature to use might change...

If we assume that the archive is meant to store immutable content
under a given filename (and to me that requirement seems to be a good
idea), then we should question ourselves whether we really want to store
those signatures in that way. They should either be tied to the Debian
revision (so that they can change over time without any new upstream
release) or be incorporated in the Debian tarball.

Cheers,
  Raphaël.

Bug#949255: simple-cdd: does not properly resolve dependencies on virtual packages when fetching packages

[Raphaël Hertzog]

Package: simple-cdd
Version: 0.6.8~kali2
Severity: important
User: de...@kali.org
Usertags: origin-kali

simple-cdd is not always including all the required packages in the local
mirror that it builds with reprepro. I can immediately see it because
dose-debcheck reports many uninstallable packages. I put some example below and
you will quickly see the pattern, they all involve an unsatisfied dependency on
a virtual package (where there's no real package mentioned like we can have for
"exim | mail-transport-agent", here's it's always a plain virtual package
alone, eg "sip-py3api-12.7").

When I review the content of the generated image, I can see that I have
the package with the dependency on the virtual package but that I don't have
any package providing the virtual package (e.g. I have libnet-ssleay-perl
depending on perl-openssl-abi-1.1 but I don't have perl-openssl-defaults).

Examples:

 package: python3-pyqt5.qtopengl
 version: 5.12.3+dfsg-3+b1
 architecture: amd64
 status: broken
 reasons:
  -
   missing:
pkg:
 package: python3-pyqt5
 version: 5.12.3+dfsg-3+b1
 architecture: amd64
 unsat-dependency: sip-py3api-12.7
depchains:
 -
  depchain:
   -
package: python3-pyqt5.qtopengl
version: 5.12.3+dfsg-3+b1
architecture: amd64
depends: python3-pyqt5 (= 5.12.3+dfsg-3+b1)

or

 package: python3-paramiko
 version: 2.6.0-1
 architecture: all
 status: broken
 reasons:
  -
   missing:
pkg:
 package: python3-bcrypt
 version: 3.1.7-1
 architecture: amd64
 unsat-dependency: python3-cffi-backend-api-min (<= 9729)
depchains:
 -
  depchain:
   -
package: python3-paramiko
version: 2.6.0-1
architecture: all
depends: python3-bcrypt (>= 3.1.3)

or

 package: libio-socket-ssl-perl
 version: 2.066-1
 architecture: all
 status: broken
 reasons:
  -
   missing:
pkg:
 package: libnet-ssleay-perl
 version: 1.88-2
 architecture: amd64
 unsat-dependency: perl-openssl-abi-1.1
depchains:
 -
  depchain:
   -
package: libio-socket-ssl-perl
version: 2.066-1
architecture: all
depends: libnet-ssleay-perl (>= 1.85-2~)

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.28~kali1
ii  lsb-release 11.1.0
ii  python3 3.7.5-3
ii  python3-simple-cdd  0.6.8~kali2
ii  reprepro5.3.0-1+b1
ii  rsync   3.1.3-8
ii  wget1.20.3-1+b2

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-14+b2

Versions of packages simple-cdd suggests:
ii  qemu-kvm  1:4.2-1

-- no debconf information

Bug#948568: nvidia-graphics-drivers: screen tearing with Linux 5.4 due to loss of "PRIME Synchronization"

[Raphaël Hertzog]

Source: nvidia-graphics-drivers
Version: 430.64-4
Severity: important
User: de...@kali.org
Usertags: origin-kali

We had multiple reports of nvidia users having refresh issues ever since
they switched to Linux 5.4.

I believe they are affected by the loss of "PRIME synchronization" as
explained in 
https://devtalk.nvidia.com/default/topic/1068045/linux/5-4-kernel-breaks-prime-synchronization-/

There's a patch for 440.44 in that thread but I don't know of any upstream
fix. Direct link to patch: https://gitlab.com/snippets/1927096

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

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

Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true

[Raphaël Hertzog]

Package: blhc
Version: 0.10-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

https://salsa.debian.org/pkg-security-team/aflplusplus/-/jobs/481494/raw

If you look in this blhc log, you will see that it complains of a dwz
invocation:

751:[31mLDFLAGS missing[0m (-Wl,-z,relro -Wl,-z,now)[33m:[0mdwz 
-mdebian/afl\+\+/usr/lib/debug/.dwz/x86_64-linux-gnu/afl\+\+.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/afl\+\+.debug -- 
debian/afl\+\+/usr/bin/afl-analyze debian/afl\+\+/usr/bin/afl-fuzz 
debian/afl\+\+/usr/bin/afl-gcc debian/afl\+\+/usr/bin/afl-gotcpu 
debian/afl\+\+/usr/bin/afl-showmap debian/afl\+\+/usr/bin/afl-tmin 
debian/afl\+\+/usr/lib/afl/afl-as debian/afl\+\+/usr/lib/afl/libdislocator.so 
debian/afl\+\+/usr/lib/afl/libtokencap.so

I'm not quite sure why it believe that this line would a linker call but this is
clearly wrong.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 blhc depends on:
ii  libdpkg-perl  1.19.7

blhc recommends no packages.

blhc suggests no packages.

-- no debconf information

Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[Raphaël Hertzog]

Source: rustc
Version: 1.39.0+dfsg1-3
Severity: serious
Justification: FTBFS

rustc is not migrating to testing (and thus holding up migration of the
latest thunderbird) because it fails to build on mipsel and mips64el with
too many test failures:

https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.39.0%2Bdfsg1-3=1575833439=0
 Debian rustc test report 
Specific test failures:
command did not execute successfully: 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/tidy" 
"/<>/src" "/usr/bin/cargo" "--verbose"
test [ui] ui/statics/static-function-pointer.rs ... FAILED
command did not execute successfully: 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
 "--compile-lib-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
"--run-lib-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
 "--rustc-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
"--src-base" "/<>/src/test/ui" "--build-base" 
"/<>/build/mips64el-unknown-linux-gnuabi64/test/ui" "--stage-id" 
"stage2-mips64el-unknown-linux-gnuabi64" "--mode" "ui" "--target" 
"mips64el-unknown-linux-gnuabi64" "--host" "mips64el-unknown-linux-gnuabi64" 
"--llvm-filecheck" "/usr/lib/llvm-8/bin/FileCheck" "--linker" 
"mips64el-linux-gnuabi64-gcc" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 
-Zunstable-options  
-Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
 "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
-Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
 "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
"--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
"--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" 
"--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
test [debuginfo-gdb+lldb] debuginfo/lexical-scope-in-unconditional-loop.rs ... 
FAILED
test [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs ... FAILED
command did not execute successfully: 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
 "--compile-lib-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
"--run-lib-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
 "--rustc-path" 
"/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
"--src-base" "/<>/src/test/debuginfo" "--build-base" 
"/<>/build/mips64el-unknown-linux-gnuabi64/test/debuginfo" 
"--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" 
"debuginfo-gdb+lldb" "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
"mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
"/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
"--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
-Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
 "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
-Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
 "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
"--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
"--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" 
"--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 60) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 62) ... FAILED
test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 60) ... FAILED
test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 62) ... FAILED
test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 60) ... FAILED
test num/mod.rs - sync::atomic::AtomicI64::fetch_min (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI64::fetch_min (line 62) ... FAILED
test num/mod.rs - sync::atomic::AtomicI8::fetch_max (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI8::fetch_max (line 60) ... FAILED
test num/mod.rs - sync::atomic::AtomicI8::fetch_min (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicI8::fetch_min (line 62) ... FAILED
test num/mod.rs - sync::atomic::AtomicIsize::fetch_max (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicIsize::fetch_max (line 60) ... FAILED
test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 49) ... FAILED
test num/mod.rs - sync::atomic::AtomicIsize::fetch_min (line 62) ... FAILED
test num/mod.rs - 

Bug#946689: munin-node: cidr_allow directive is sensitive to order when mixing IPv4 and IPv6

[Raphaël Hertzog]

Package: munin-node
Version: 2.0.33-1
Severity: normal

I recently migrated my munin server and thus I updated my munin-node
configuration to allow connections from 2 servers (on IPv4 and on IPv6)
with a config like this:

# Old server
cidr_allow 212.83.177.246/32
cidr_allow 2a01:e0b:21e3:3::1/128
# New server
cidr_allow 163.172.191.75/32
cidr_allow 2001:bc8:47c0:11f::1/128

It turns out that the new server would not manage to connect to the munin
nodes. The logs were showing a message like this:
2019/12/13-21:10:02 CONNECT TCP Peer: "[:::163.172.191.75]:49184" Local: 
"[:::212.83.178.2]:4949"
Invalid netblock: 42.1.14.11.33.227.0.3.0.0.0.0.0.0.0.1-163.172.191.75 at 
/usr/share/perl5/Net/Server.pm line 600.

This made no sense to me. After a lot of tweaking, I noticed that
all the "cidr_allow" for the IPv4 addresses have to be before the first
cidr_allow for an IPv6 address. So just sorting the rules differently
like this makes it work as expected (at least when connecting over IPv4):

# Old and new, with IPv4 first and IPv6 after
cidr_allow 212.83.177.246/32
cidr_allow 163.172.191.75/32
cidr_allow 2a01:e0b:21e3:3::1/128
cidr_allow 2001:bc8:47c0:11f::1/128

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 munin-node depends on:
ii  adduser  3.118
ii  gawk 1:5.0.1+dfsg-1
ii  init-system-helpers  1.57
pn  libmunin-node-perl   
pn  libnet-server-perl   
ii  lsb-base 11.1.0
pn  munin-common 
pn  munin-plugins-core   
ii  netbase  5.8
ii  perl 5.30.0-9
ii  procps   2:3.3.15-2+b1

Versions of packages munin-node recommends:
ii  gawk 1:5.0.1+dfsg-1
pn  libnet-snmp-perl 
pn  munin-plugins-core   
pn  munin-plugins-extra  
ii  procps   2:3.3.15-2+b1

Versions of packages munin-node suggests:
pn  acpi | lm-sensors 
pn  default-mysql-client  
ii  ethtool   1:4.19-1
ii  hdparm9.58+ds-4
pn  libcache-cache-perl   
ii  libcrypt-ssleay-perl  0.73.06-1+b2
pn  libdbd-mysql-perl 
ii  libdbd-pg-perl3.10.0-2
pn  liblwp-useragent-determined-perl  
pn  libnet-irc-perl   
ii  libtext-csv-xs-perl   1.40-1
ii  libwww-perl   6.43-1
ii  libxml-simple-perl2.25-1
pn  logtail   
pn  munin 
pn  munin-plugins-extra   
pn  munin-plugins-http
pn  munin-plugins-java
pn  munin-plugins-pgsql   
pn  munin-plugins-snmp
pn  mysql-client  
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python2.7.17-2
ii  ruby  1:2.5.2
pn  smartmontools 

Bug#946267: cpio -i --no-absolute-filenames breaks symlinks starting with / or /..

[Raphaël Hertzog]

Package: cpio
Version: 2.13+dfsg-1
Severity: serious
User: de...@kali.org
Usertags: origin-kali
Control: affects -1 live-build

live-build is able to repack the installer initrd to add custom files.
We use that feature in Kali and since last week, when cpio 2.13+dfsg-1
reached testing (and thus our ISO build chroots), our installer images are
badly broken and we get errors like “/usr/share/debconf/frontend: not
found” or “expr: not found”.

After a diffoscope run to compare the original and repacked initrd I saw
things like this:

│ │ ├── etc/mtab
│ │ │┄ symlink
│ │ │ @@ -1 +1 @@
│ │ │ -destination: /proc/mounts
│ │ │ +destination: proc/mounts
│ │ ├── usr/bin/expr
│ │ │┄ symlink
│ │ │ @@ -1 +1 @@
│ │ │ -destination: /bin/busybox
│ │ │ +destination: bin/busybox
│ │ ├── usr/share/debconf/frontend
│ │ │┄ symlink
│ │ │ @@ -1 +1 @@
│ │ │ -destination: ../../lib/cdebconf/debconf
│ │ │ +destination: lib/cdebconf/debconf

So the target of the symlinks have been modified. live-build uses
cpio in the following way to unpack the initrd and repack it:

# mkdir temp
# cd temp
# cpio -i --make-directories --no-absolute-filenames /somewhere/initrd-repacked

(see
https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/installer_debian-installer#L743
for actual code)

So it uses "--no-absolute-filenames" just to ensure that the files are
extracted in the current directory and to not extract them in the
root directory (in case the archive contains absolute filenames), but it
really doesn't want cpio to change the contents of the symlinks that it
extracts!

I looked in the manual page and could not find any option that would
result in the desired behavior. As this is is breaking live-build, I'm
putting this as a serious bug for now.

This regression is because the upstream fix for CVE-2015-1197 mangles
the symlinks in this way:
https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=45b0ee2b407913c533f7ded8d6f8cbeec16ff6ca

The original SuSE patch that we used was smarter, it would not change the
symlinks but it would refuse to extract over a symlink:
https://bugzilla.suse.com/attachment.cgi?id=599460=diff

FYI I'm putting the author of the above commit in copy so that he can
chime in and be aware of this regression.

Cheers,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 cpio depends on:
ii  libc6  2.29-3

cpio recommends no packages.

Versions of packages cpio suggests:
pn  libarchive1  

-- no debconf information

Bug#946054: git-buildpackage: Please support "Gbp-Dch: skip" as alternative to "Gbp-Dch: ignore"

[Raphaël Hertzog]

Package: git-buildpackage
Version: 0.9.17
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

When I don't look up the docs, I tend to write "Gbp-Dch: skip" instead of
"Gbp-Dch: ignore", the reason behind that is that all git commands working
interactively on range of commits have this --skip option (e.g. git rebase
--skip).

So it would be nice if you could support "skip" as a synonym to "ignore".

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 git-buildpackage depends on:
ii  devscripts 2.19.7
ii  git1:2.24.0-1
ii  man-db 2.9.0-1
ii  python33.7.5-3
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  41.4.0-1
ii  sensible-utils 0.0.12+nmu1

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.47
ii  python3-requests  2.21.0-1
ii  sbuild0.78.1-2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.29-1
ii  unzip6.0-25

-- no debconf information

Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running

[Raphaël Hertzog]

Package: dpkg
Version: 1.19.7
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

I just got a lintian warning "uses-dpkg-database-directly" on a script I
wrote a long time ago:
https://gitlab.com/kalilinux/packages/kali-menu/blob/kali/master/update-kali-menu

It's a script started in a postinst and/or in a DPkg::Post-Invoke hook. It
waits until dpkg is no longer running and then perform some work
(involving dpkg-divert to replace some files by our own).

In order to wait until dpkg is no longer running, I try to grab the dpkg
lock... and thus I have hardcoded /var/lib/dpkg/lock and lintian is not
happy.

To achieve this in a more elegant way, could you possibly implement some
"dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or
something similar ?

-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 dpkg depends on:
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-3
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  2.9-3+b1
ii  tar  1.30+dfsg-6+b1
ii  zlib1g   1:1.2.11.dfsg-1+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.4
pn  debsig-verify  

-- no debconf information

Bug#944640: gtk-d: FTBFS on armel/armhf with many "multiple definition" messages

[Raphaël Hertzog]

Source: gtk-d
Version: 3.9.0-2
Severity: important
Tags: ftbfs

Hi,

can you make a new source upload to let the package migrate to testing
please ?

I also noticed that the package still fails to build on armel/armhf with
hundreds of message like these:

/usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
`_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
`_DT24_D3gtk6Widget6Widget10__mixin37720setBuildablePropertyMFC3gtk7Builder7BuilderAyaC7gobject5Value5ValueZv';
 ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
/usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
`_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
`_DT24_D3gtk6Widget6Widget10__mixin37716buildableSetNameMFAyaZv'; 
./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [GNUmakefile:252: TestWindow] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: make -j8 "INSTALL=install --strip-program=true" test shared 
prefix=/usr returned exit code 2
make[1]: *** [debian/rules:19: override_dh_auto_build] Error 255


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

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

Bug#943953: linux: DKMS module builds are failing on arm64 due to lack of armhf cross-compiler

[Raphaël Hertzog]

Source: linux
Version: 5.3.7-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

https://salsa.debian.org/kernel-team/linux/commit/82c843e1577930c4eb168f626ab9bd483b118efc
seems to break DKMS on arm64:


root@pinebook-kali:/usr/src# dkms autoinstall

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
'make' -j4 ARCH=arm64 KVER=5.3.0-kali1-arm64 
KSRC=/lib/modules/5.3.0-kali1-arm64/build/...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.3.0-kali1-arm64 (aarch64)
Consult /var/lib/dkms/rtl8723cs/2019.07.31/build/make.log for more information.
root@pinebook-kali:/usr/src# cat 
/var/lib/dkms/rtl8723cs/2019.07.31/build/make.log 
DKMS make.log for rtl8723cs-2019.07.31 for kernel 5.3.0-kali1-arm64 (aarch64)
Fri Nov  1 03:50:50 CDT 2019
make ARCH=arm64 CROSS_COMPILE= -C /lib/modules/5.3.0-kali1-arm64/build/ 
M=/var/lib/dkms/rtl8723cs/2019.07.31/build  modules
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-kali1-arm64'
arch/arm64/Makefile:58: *** arm-linux-gnueabihf-gcc not found, check 
CROSS_COMPILE_COMPAT.  Stop.
make[1]: *** [/usr/src/linux-headers-5.3.0-kali1-common/Makefile:179: sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-kali1-arm64'
make: *** [Makefile:1670: modules] Error 2


Some more information gathered on IRC:

16:51  Oh, we have the Depends right, so I think the check in 
arch/arm64/Makefile needs to be suppressed when building out-of-tree modules
16:54  bwh: what do you mean with "we have the Depends right" (i.e. with 
or without the cross-compiler)? on what package are you looking?
16:55  The Depends for the linux-headers package don't include an armhf 
compiler, which is correct
16:55  but the kernel build system still looks for it, which is not
16:55  There are some upstream changes around this that might fix it

Cheers,
 Raphaël.

Bug#942493: lintian: Complain of too long header fields

[Raphaël Hertzog]

Package: lintian
Version: 2.27.0
Severity: wishlist

Based on the problem discovered in #942487 where a Provides line of more
than 256K slipped in the archive, I believe it would be nice if lintian
could:

1/ emit a warning when a field is larger than say 16K (somehow to force
   the maintainer to think twice whether's he's doing something
   reasonable)

2/ emit an error when a field is larger than 200K (it breaks reprepro
   above 256K)

This should be applied to .deb headers and .dsc headers. (.changes headers
are less interesting as they are auto-generated without much control by
the maintainer, or are a simple copy of fields already present in other
files).

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lintian depends on:
ii  binutils 2.33.1-1
ii  bzip21.0.8-2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-7
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphaël Hertzog]

Source: rust-web-sys
Version: 0.3.28-1
Severity: critical
Justification: breaks unrelated software
User: de...@kali.org
Usertags: origin-kali

$ apt-cache show librust-web-sys-dev|grep ^Provides:|wc -c
277998

This is a serious abuse of the Provides header... for a package that
provides 719 files.

And it breaks unrelated software processing the Debian archive, namely
reprepro:
Error parsing ./lists/unstable_unstable_main_arm64_Packages line 914113: 
Ridiculous long (>= 256K) control chunk!

For this reason, I'm going to NMU the package and disable/reduce the Provides
field until you find a reasonable solution.

Cheers,

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

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

Bug#942104: release.debian.org: Will fail if "Suite" field is missing

[Raphaël Hertzog]

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

britney assumes that if you have a Release file, it will contain a "Suite"
field. That's not true, the "Codename" entry is required but the "Suite"
one is optional.

Please handle properly that case:
[...]
I: [2019-10-10T12:39:21+] - Loading source packages from 
/srv/repo.kali.org/ftp/kali/dists/kali-dev/non-free/source/Sources.gz
Traceback (most recent call last):
  File "./britney.py", line 1529, in 
Britney().main()
  File "./britney.py", line 284, in __init__
self.__parse_arguments()
  File "./britney.py", line 463, in __parse_arguments
self.suite_info = suite_loader.load_suites()
  File "/srv/repo.kali.org/tools/britney2/britney2/inputs/suiteloader.py", line 
116, in load_suites
self._update_suite_name(suite)
  File "/srv/repo.kali.org/tools/britney2/britney2/inputs/suiteloader.py", line 
146, in _update_suite_name
suite.name = release_file['Suite']
KeyError: 'Suite'

Cheers,

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

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

Bug#942070: gnome-shell-extension-workspaces-to-dock: Must be updated to work with GNOME 3.34

[Raphaël Hertzog]

Package: gnome-shell-extension-workspaces-to-dock
Version: 51-1
Severity: grave
Tags: upstream
Justification: renders package unusable
User: de...@kali.org
Usertags: origin-kali

Please package version 52 that is documented to work with GNOME Shell
3.34.

The current version can be installed and loaded but it entirely breaks the
activities overview.

Thank you.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 gnome-shell-extension-workspaces-to-dock depends on:
ii  gnome-shell  3.34.0-2

gnome-shell-extension-workspaces-to-dock recommends no packages.

gnome-shell-extension-workspaces-to-dock suggests no packages.

Bug#941656: lintian: changelog-file-missing-explicit-entry false positive for 2 consecutive NMUs (-X.1, -X.2)

[Raphaël Hertzog]

Package: lintian
Version: 2.24.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I just uploaded ddd_3.3.12-5.2.dsc and I get this warning:
W: ddd source: changelog-file-missing-explicit-entry 1:3.3.12-5.1 -> 1:3.3.12-5 
(missing) -> 1:3.3.12-5.2

Yet the changelog file has all the entries and in the expected order:
$ grep ^ddd debian/changelog |head -n 3
ddd (1:3.3.12-5.2) unstable; urgency=medium
ddd (1:3.3.12-5.1) unstable; urgency=medium
ddd (1:3.3.12-5) unstable; urgency=low

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lintian depends on:
ii  binutils 2.32.51.20190909-1
ii  bzip21.0.8-2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.66-2
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#941642: desktop-base: split theme data files and desktop integrations in separate packages

[Raphaël Hertzog]

Package: desktop-base
Version: 10.0.3
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

In derivative distributions, you want to provide customized artwork and
you want that artwork to be used consistently. But you don't want to waste
space to store the Debian artwork.

Thus I would like to package separately:
- the various integrations that you provide that make many software use
  the desktop-base alternatives
- the actual data files providing those alternatives

The integrations could be provided by desktop-base itself, but it would
depend on "desktop-base-debian | desktop-base-data". desktop-base-debian
would be the other binary package that you provide with all the artwork
registered in all the alternatives.

That way in Kali we can ship our own package providing "desktop-base-data"
and not waste 10Mb for Debian artwork.

Cheers,

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 desktop-base depends on:
ii  fonts-quicksand  0.2016-2
ii  librsvg2-common  2.44.14-1

Versions of packages desktop-base recommends:
ii  plymouth-label  0.9.4-1.1+b1

Versions of packages desktop-base suggests:
ii  gnome  1:3.30+2

-- no debconf information

Bug#940699: scapy: Please drop the "Breaks" on python-scapy or restore the python 2 package

[Raphaël Hertzog]

Source: scapy
Version: 2.4.2-1
Severity: normal

Your latest upload dropped the python 2 version of scapy (python-scapy).
It was really too early as you broke reverse dependencies (websploit,
pyrit, dhcpig, ooniprobe) and we're trying to go through this transition 
sanely...

In Kali we have even more reverse dependencies that have not switched
to Python 3 yet.

I would really appreciate if you could restore python-scapy for a while...

But if you don't do that, please at least drop the "Breaks: python-scapy"
and keep only the "Replaces: python-scapy", this one is enough to take
over /usr/bin/scapy. Right now with the "Breaks: python-scapy", you can't
keep around python-scapy if you want to install python3-scapy and that's
really counter-productive for the transition on user's side. During the
transition on their machine, they need both packages installed at the same
time and this situation will last a while for Kali users since we have
many reverse dependencies not yet updated.

FWIW, we're handling the transition in Kali too[1] but we have more reverse
dependencies to handle for this package:
$ apt rdepends python-scapy
python-scapy
Reverse Depends:
  Recommends: pyrit (>= 2.0)
  Depends: odat
  Depends: wol-e
  Depends: wifitap
  Depends: wifiphisher
  Recommends: websploit
  Replaces: python3-scapy
  Breaks: python3-scapy
  Depends: apt2
  Depends: mana-toolkit
  Depends: kerberoast
  Depends: kali-linux-default
  Depends: ghost-phisher
  Depends: fruitywifi-module-wifirecon
  Depends: fruitywifi-module-stalker
  Depends: fruitywifi-module-hopper
  Depends: fruitywifi-module-devicefinder
  Depends: fruitywifi-module-detectrogue
  Depends: fruitywifi-module-detectdeauth
  Depends: fruitywifi-module-ap
  Depends: fern-wifi-cracker
  Depends: dhcpig

[1] 
https://gitlab.com/groups/kalilinux/-/issues?label_name%5B%5D=Project%3A%3APy2Removal

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

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

Bug#939057: python-tz: Invalid Vcs-Git and misleading maintainer

[Raphaël Hertzog]

Source: python-tz
Severity: normal

$ grep Vcs debian/control
Vcs-Browser: https://salsa.debian.org:/mckinstry/python-tz.git
Vcs-Git: https://salsa.debian.org:/mckinstry/python-tz.git

Those URL are unusual (incorrect?) with the colon. And they lead to a empty
repository:
https://salsa.debian.org/mckinstry/python-tz
(Note that we drop the trailing ".git" for Vcs-Browser)

Furthermore the Maintainer field indicates the python-modules team
but the package is not hosted there either. I couldn't find it
on https://salsa.debian.org/python-team/modules

$ grep Maintainer debian/control 
Maintainer: Debian Python Modules Team 


There's the zope team in Uploaders as well but there's no reason for this,
in particular given that the team as a whole is MIA.


Please fix all those inconsistencies and make the git repository
available. I believe it would be better withing the python modules team
ideally.

Thank you for your work maintaining this package!


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

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

-- no debconf information

Bug#935417: gnuradio: depends on conflicting libvolk1-bin and libvolk2-bin (via libvolk2.0)

[Raphaël Hertzog]

Source: gnuradio
Version: 3.8.0.0-2+b1
Severity: important
User: de...@kali.org
Usertags: origin-kali

TLDR: gnuradio depends on libvolk1-bin but unstable has volk version 2
and the last bin-nmu built gnuradio against the new version resulting
in Depends: libvolk1-bin, ..., libvolk2.0. But libvolk2.0 recommends
libvolk2-bin which breaks libvolk1-bin.

In theory, the package is still installable (by breaking the Recommends in
libvolk2.0) and that's why it migrated to testing but somehow apt doesn't
accept to to that.

Some Kali automated tests are failing due to gnuradio failing to install:
> # apt install gnuradio
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  gnuradio : Depends: libvolk1-bin but it is not going to be installed
> Recommends: python3-qwt-qt5 but it is not installable
> E: Unable to correct problems, you have held broken packages.

With some debug info it gives this:
> # apt -o debug::pkgProblemResolver=yes install gnuradio
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Starting pkgProblemResolver with broken count: 1
> Starting 2 pkgProblemResolver with broken count: 1
> Investigating (0) gnuradio:amd64 < none -> 3.8.0.0-2+b1 @un puN Ib >
> Broken gnuradio:amd64 Depends on libvolk1-bin:amd64 < none | 1.4-3+b1 @un uH >
>   Considering libvolk1-bin:amd64 1 as a solution to gnuradio:amd64 1
>   Re-Instated libvolk1-bin:amd64
> Investigating (0) libvolk2-bin:amd64 < none -> 2.0.0-2 @un uN Ib >
> Broken libvolk2-bin:amd64 Breaks on libvolk1-bin:amd64 < none -> 1.4-3+b1 @un 
> uN >
>   Considering libvolk1-bin:amd64 1 as a solution to libvolk2-bin:amd64 18
>   Added libvolk1-bin:amd64 to the remove list
>   Fixing libvolk2-bin:amd64 via keep of libvolk1-bin:amd64
> Investigating (1) gnuradio:amd64 < none -> 3.8.0.0-2+b1 @un puN Ib >
> Broken gnuradio:amd64 Depends on libvolk1-bin:amd64 < none | 1.4-3+b1 @un uH >
>   Considering libvolk1-bin:amd64 1 as a solution to gnuradio:amd64 1
> Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  gnuradio : Depends: libvolk1-bin but it is not going to be installed
> Recommends: python3-qwt-qt5 but it is not installable
> E: Unable to correct problems, you have held broken packages.

However it works with --no-install-recommends:
> # apt install gnuradio --no-install-recommends
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following additional packages will be installed:
>   fontconfig fontconfig-config fonts-dejavu-core freeglut3 gcc-9-base 
> libasan5 libasound2
> [...]
> 12 upgraded, 218 newly installed, 0 to remove and 8 not upgraded.
> Need to get 108 MB of archives.
> After this operation, 645 MB of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort.

Note that you should also update gnuradio-dev to depend on libvolk2-dev
instead of libvolk1-dev.

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

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

Bug#935403: aufs: Please update package for Linux 5.2

[Raphaël Hertzog]

Package: aufs-dkms
Version: 4.19+20190211-1
Severity: important
User: de...@kali.org
Usertags: origin-kali

The package aufs-dkms does not build any module for Linux 5.2, which
is the default kernel in Debian unstable currently.

FYI this bug is forwarded from Kali: https://bugs.kali.org/view.php?id=5647

Cheers,
 Raphael.

Bug#932986: salsa: more settings to configure related to merge requests and CI

[Raphaël Hertzog]

Package: devscripts
Version: 2.19.5
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

With the increased usage of merge requests and CI, there are other
settings that can be useful to configure with the salsa helper:

- more project settings (https://docs.gitlab.com/ee/api/projects.html):
  - only_allow_merge_if_pipeline_succeeds
  - only_allow_merge_if_all_discussions_are_resolved
  - resolve_outdated_diff_discussions
  - auto_cancel_pending_pipelines
  - merge_method

- ensure that a specific deploy key is installed:
  https://docs.gitlab.com/ee/api/deploy_keys.html#add-deploy-key

  My use case is special here, I want to setup a service that will update
  the upstream/latest branches automatically. So the deploy key needs
  write access to the repository. Read-only or read-write access should
  be configurable. But setting up deploy keys for each repository is too
  cumbersome.

Cheers,

Bug#932834: FTBFS: relocation R_X86_64_32 against symbol `PyVersion_Type' can not be used when making a shared object; recompile with -fPIC

[Raphaël Hertzog]

Source: python-apt
Version: 1.8.4
Severity: serious
Justification: FTBFS
User: de...@kali.org
Usertags: origin-kali

Trying to rebuild python-apt in unstable currently fails with:

x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now 
-g -O2 -fdebug-prefix-map=/<>=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-write-strings -DDATE="Mar 11 2019" 
-DTIME="11:49:18" -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-3.7/python/acquire.o 
build/temp.linux-x86_64-3.7/python/acquire-item.o 
build/temp.linux-x86_64-3.7/python/apt_pkgmodule.o 
build/temp.linux-x86_64-3.7/python/cache.o 
build/temp.linux-x86_64-3.7/python/cachegroup.o 
build/temp.linux-x86_64-3.7/python/cdrom.o 
build/temp.linux-x86_64-3.7/python/configuration.o 
build/temp.linux-x86_64-3.7/python/depcache.o 
build/temp.linux-x86_64-3.7/python/generic.o 
build/temp.linux-x86_64-3.7/python/hashes.o 
build/temp.linux-x86_64-3.7/python/hashstring.o 
build/temp.linux-x86_64-3.7/python/hashstringlist.o 
build/temp.linux-x86_64-3.7/python/indexfile.o 
build/temp.linux-x86_64-3.7/python/lock.o 
build/temp.linux-x86_64-3.7/python/metaindex.o 
build/temp.linux-x86_64-3.7/python/orderlist.o 
build/temp.linux-x86_64-3.7/python/pkgmanager.o 
build/temp.linux-x86_64-3.7/python/pkgrecords.o 
build/temp.linux-x86_64-3.7/python/pkgsrcrecords.o 
build/temp.linux-x86_64-3.7/python/policy.o 
build/temp.linux-x86_64-3.7/python/progress.o 
build/temp.linux-x86_64-3.7/python/python-apt-helpers.o 
build/temp.linux-x86_64-3.7/python/sourcelist.o 
build/temp.linux-x86_64-3.7/python/string.o 
build/temp.linux-x86_64-3.7/python/tag.o -lapt-pkg -o 
build/lib.linux-x86_64-3.7/apt_pkg.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: /tmp/ccZYGg3M.ltrans0.ltrans.o: relocation R_X86_64_32 against 
symbol `PyVersion_Type' can not be used when making a shared object; recompile 
with -fPIC
/usr/bin/ld: /tmp/ccZYGg3M.ltrans1.ltrans.o: relocation R_X86_64_32 against 
symbol `PyPolicy_Type' can not be used when making a shared object; recompile 
with -fPIC
/usr/bin/ld: /tmp/ccZYGg3M.ltrans2.ltrans.o: relocation R_X86_64_32 against 
symbol `PyAcquire_Type' can not be used when making a shared object; recompile 
with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1
dh_auto_build: python3.7 setup.py build --force returned exit code 1
make[1]: *** [debian/rules:19: override_dh_auto_build] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Build finished at 2019-07-23T16:52:03Z


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

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

-- no debconf information

Bug#931219: /usr/bin/autopkgtest-virt-qemu: should listen on 127.0.0.1 for SSH port forward

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.10
Severity: normal
File: /usr/bin/autopkgtest-virt-qemu
Tags: patch
User: de...@kali.org
Usertags: origin-kali kali-patch

When qemu is run by autopkgtest-virt-qemu, it will happily forward the
SSH port of the test VM to all network interfaces.

I'm not quite sure what's the purpose of this port forward (I thought
everything happened over serial terminals), but IMO it should really be
restricted to localhost only.

Here's the (untested & trivial) patch:

--- /usr/bin/autopkgtest-virt-qemu  2019-02-25 15:05:15.0 +0100
+++ /tmp/autopkgtest-virt-qemu  2019-06-28 15:02:38.942235854 +0200
@@ -540,7 +540,7 @@
 ssh_port = find_free_port(10022)
 if ssh_port:
 adtlog.debug('Forwarding local port %i to VM ssh port 22' % ssh_port)
-nic_opt = ',hostfwd=tcp::%i-:22' % ssh_port
+nic_opt = ',hostfwd=tcp:127.0.0.1:%i-:22' % ssh_port
 else:
 nic_opt = ''
 

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.2
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.18

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20181115.85588389-3
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:3.1+dfsg-8
ii  schroot   1.6.10-6+b1
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information

Bug#931210: debci: Display requestor and priority in the /status/pending/ pages

[Raphaël Hertzog]

Source: debci
Version: 2.1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

It would be nice if /status/pending/ pages could show the requestor of a
specific job as well as its priority.

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

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

Bug#931206: debci-worker: /etc/cron.daily/debci-worker will block for days when workers are not idle

[Raphaël Hertzog]

Package: debci-worker
Version: 2.1
Severity: important
User: de...@kali.org
Usertags: origin-kali

On our setup, we use the qemu backend on a big machine with lots of RAM
and CPU, so we have many workers running concurrently.

With a backlog, there's often no point in time where the qemu image is
not used at all. This means that /usr/share/debci/bin/debci-setup will
never get the exclusive lock that it is trying to get... and thus the
daily cron will get stuck indefinitely. They will even accumulate days
after days...

The cron should fail it's not able to get the lock it wants in a
reasonable timeframe. Given the time it can take until the lock is
acquired (some tests take multiple hours), the script should likely be
moved out of /etc/cron.daily/.

There should also be an option to stop the worker at the start so that the
update can happen immediately (and they should be restarted at the end
if they were running before).

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

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

Versions of packages debci-worker depends on:
ii  autodep8 0.18
ii  autopkgtest  5.10
pn  debci
ii  init-system-helpers  1.57
ii  schroot  1.6.10-6+b1

debci-worker recommends no packages.

debci-worker suggests no packages.

Bug#931022: recon-ng: New upstream version on github

[Raphaël Hertzog]

Package: recon-ng
Version: 4.9.6-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Announce: https://twitter.com/LaNMaSteR53/status/1143170464749109250

So it looks like there's a new recon-ng working with Python 3 that is
hosted in github and that is not picked up by uscan due to this:
https://github.com/lanmaster53/recon-ng

It would be nice to have this new version packaged.

https://github.com/lanmaster53/recon-ng/releases/tag/v5.0.0

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

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

Versions of packages recon-ng depends on:
ii  libjs-jquery3.3.1~dfsg-3
pn  libjs-skeleton  
ii  node-normalize.css  8.0.1-3
ii  python  2.7.16-1
pn  python-dicttoxml
ii  python-dnspython1.16.0-1
pn  python-flask
pn  python-jsonrpclib   
ii  python-lxml 4.3.3-2
ii  python-mechanize1:0.2.5-3
ii  python-olefile  0.46-1
pn  python-pypdf2   
pn  python-slowaes  
pn  python-unicodecsv   
pn  python-xlsxwriter   

recon-ng recommends no packages.

recon-ng suggests no packages.

Bug#931017: dkms: "install" loads modules immediately, and loads more than the newly installed modules

[Raphaël Hertzog]

Package: dkms
Version: 2.6.1-4
Severity: important
User: de...@kali.org
Usertags: origin-kali

While working on automatic installation of virtualbox-guest-dkms in
debian-installer when running in VirtualBox VM, I have discovered
that the package installation would break debian installer.

The reason is that "dkms install" runs this:
find /sys/devices -name modalias -print0 | xargs -0 cat | xargs modprobe -a -b 
-q

This will load the newly built modules but possibly also other modules...
and the fact that those modules get loaded, somehow breaks the
X server run by debian-installer.

This "feature" is new in buster compared to stretch. It would be nice to
have a way to disable this automatic loading... ideally an environment
variable makes it easy to disable this from debian-installer without
having to modify the target system. But a command line option (and/or an
entry in the configuration file) is certainly a good idea as well.

And it would be even better if it could just do its work on the modules
that the "dkms install" actually installed.

Cheers,

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

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

Versions of packages dkms depends on:
ii  build-essential  12.6
ii  coreutils8.30-3
ii  dpkg-dev 1.19.7
ii  gcc  4:8.3.0-1
ii  kmod 26-1
ii  make 4.2.1-1.2
ii  patch2.7.6-3

Versions of packages dkms recommends:
ii  fakeroot  1.23-1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-  
pn  linux-image   
ii  lsb-release   10.2019051400
ii  sudo  1.8.27-1

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

Bug#930929: libvirt: is no longer able to use kvm

[Raphaël Hertzog]

Source: libvirt
Version: 5.0.0-4
Severity: serious

For a few days/weeks (I'm not sure when it started exactly), I can no
longer run my VM with virt-manager.

On startup of libvirtd I have many messages like this one (one for each VM
I guess):
libvirtd[8281]: invalid argument: could not find capabilities for arch=x86_64 
domaintype=kvm 

When I try to start a VM I see this in the logs of libvirtd:
libvirtd[12569]: Unable to read from monitor: Connexion ré-initialisée par le 
correspondant
libvirtd[12569]: internal error: qemu unexpectedly closed the monitor: Could 
not access KVM kernel module: Permission denied
 2019-06-22T17:07:23.635870Z qemu-system-x86_64: failed to 
initialize KVM: Permission denied
libvirtd[12569]: internal error: process exited while connecting to monitor: 
Could not access KVM kernel module: Permission denied
 2019-06-22T17:07:23.635870Z qemu-system-x86_64: failed to 
initialize KVM: Permission denied

But I do have /dev/kvm and I have hardware virtualization enabled in the
BIOS.

$ ls -al /dev/kvm
crw-rw+ 1 root root 10, 232 juin  22 19:07 /dev/kvm
$ getfacl /dev/kvm
# file: dev/kvm
# owner: root
# group: root
user::rw-
user:rhertzog:rw-
group::---
mask::rw-
other::---

And I do have the required kernel modules:
$ lsmod|grep kvm
kvm_intel 245760  0
kvm   724992  1 kvm_intel
irqbypass  16384  1 kvm

I also have qemu-kvm installed:
$ dpkg -l qemu*|grep ^ii
ii  qemu-kvm   1:3.1+dfsg-8 amd64QEMU Full virtualization on 
x86 hardware
ii  qemu-system-common 1:3.1+dfsg-8 amd64QEMU full system emulation 
binaries (common files)
ii  qemu-system-data   1:3.1+dfsg-8 all  QEMU full system emulation 
(data files)
ii  qemu-system-gui1:3.1+dfsg-8 amd64QEMU full system emulation 
binaries (user interface and audio support)
ii  qemu-system-x861:3.1+dfsg-8 amd64QEMU full system emulation 
binaries (x86)
ii  qemu-user  1:3.1+dfsg-8 amd64QEMU user mode emulation 
binaries
ii  qemu-user-static   1:3.1+dfsg-8 amd64QEMU user mode emulation 
binaries (static version)
ii  qemu-utils 1:3.1+dfsg-8 amd64QEMU utilities

I removed virtualbox and rebooted to make sure it's not a bad interaction but 
it did not help.
I don't know what else I should look into.

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

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

Bug#930719: autopkgtest: Hangs with qemu backend when copyup destination failed

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.10
Severity: important
User: de...@kali.org
Usertags: origin-kali

In Kali we do have a debci setup at autopkgtest.kali.org, we have
configured it to use the qemu backend. Unfortunately, after a while
all our workers were stuck... upon investigation it looks like that
autopkgtest can get stuck with the qemu backend when the VM image
is not big enough for the "copyup" operation to complete.

We do have the problem with thunderbird with a 20Gb disk image
as created by autopkgtest-build-qemu and we already suggested
to increase the default value:
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/49

But the real problem is that autopkgtest gets stuck. It would
be nice if it could at least fail reliably...

Here are some elements from my investigation:

$ systemctl status debci-worker-amd64-qemu@1.service
● debci-worker-amd64-qemu@1.service - debci-worker instance 1 for arch=amd64 & 
backend=qemu
   Loaded: loaded (/etc/systemd/system/debci-worker-amd64-qemu@.service; 
enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-06-07 12:25:01 UTC; 1 weeks 4 days 
ago
 Docs: https://ci.debian.net/doc/
 Main PID: 10128 (amqp-consume)
Tasks: 14
   CGroup: 
/system.slice/system-debci\x2dworker\x2damd64\x2dqemu.slice/debci-worker-amd64-qemu@1.service
   ├─ 4866 /bin/sh /usr/share/debci/bin/debci-worker --do-request
   ├─ 4916 /bin/sh /usr/share/debci/bin/debci-worker --do-request
   ├─ 4918 /bin/sh /usr/share/debci/bin/debci-test --quiet --data-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT --suite kali-rolling --print-output 
--run-id=332825 thunderbird
   ├─ 4979 /bin/sh /usr/share/debci/bin/debci-test --quiet --data-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT --suite kali-rolling --print-output 
--run-id=332825 thunderbird
   ├─ 4981 /bin/sh /usr/share/debci/backends/qemu/test-package 
--output-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT/autopkgtest-incoming/kali-rolling/amd64/t/thunderbird/332825
 thunderbird
   ├─ 4985 /bin/sh /usr/share/debci/bin/debci-autopkgtest --user debci 
--output-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT/autopkgtest-incoming/kali-rolling/amd64/t/thunderbird/332825
 thunderbird -- qemu /var/lib/debci/qemu/kali-rolling-amd64.img
   ├─ 4986 /usr/bin/python3 -u /usr/bin/autopkgtest --no-built-binaries 
--user debci --output-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT/autopkgtest-incoming/kali-rolling/amd64/t/thunderbird/332825
 thunderbird -- qemu /var/lib/debci/qemu/kali-rolling-amd64.img
   ├─ 5007 tee /var/lib/debci/tmp/autopkgtest-fifo._ww_6t7s -a 
/dev/stderr
   ├─ 5010 cat /var/lib/debci/tmp/autopkgtest-fifo._ww_6t7s
   ├─10128 amqp-consume --url amqp://melpomene.kali.org -q 
debci-tests-amd64-qemu --prefetch-count 1 -- /usr/share/debci/bin/debci-worker 
--do-request
   └─12103 /usr/bin/python3 
/var/lib/debci/tmp/autopkgtest-qemu.8b256xg_/runcmd sh -ec cd 
/tmp/autopkgtest.ZCpmjh/build.QA0/src/; tar --warning=none -c . -f -

Jun 17 12:21:05 melpomene.kali.org debci[10128]: libreswan kali-dev/amd64 fail
Jun 17 12:21:05 melpomene.kali.org debci[10128]: octave-vibes 
kali-rolling/amd64 started
Jun 17 12:23:13 melpomene.kali.org debci[10128]: octave-vibes 
kali-rolling/amd64 pass
Jun 17 12:23:13 melpomene.kali.org debci[10128]: liblog-agent-perl 
kali-dev/amd64 started
Jun 17 12:25:42 melpomene.kali.org debci[10128]: liblog-agent-perl 
kali-dev/amd64 pass
Jun 17 12:25:42 melpomene.kali.org debci[10128]: libnet-https-any-perl 
kali-dev/amd64 started
Jun 17 12:28:15 melpomene.kali.org debci[10128]: libnet-https-any-perl 
kali-dev/amd64 pass
Jun 17 12:28:15 melpomene.kali.org debci[10128]: 
libbusiness-onlinepayment-transactioncentral-perl kali-rolling/amd64 started
Jun 17 12:30:48 melpomene.kali.org debci[10128]: 
libbusiness-onlinepayment-transactioncentral-perl kali-rolling/amd64 pass
Jun 17 12:30:48 melpomene.kali.org debci[10128]: thunderbird kali-rolling/amd64 
started
 
(at this point, the worker has been stuck on thunderbird for 2 days!)

-

Extract of ps auxf :

debci10128  0.0  0.0  24436  3140 ?Ss   Jun07   0:00 amqp-consume 
--url amqp://melpomene.kali.org -q debci-tests-amd64-qemu --prefetch-count 1 -- 
/usr/share/debci/bin/debci-worker --do-request
debci 4866  0.0  0.0  13104  3124 ?SJun17   0:00  \_ /bin/sh 
/usr/share/debci/bin/debci-worker --do-request
debci 4916  0.0  0.0  13104  2216 ?SJun17   0:00  \_ 
/bin/sh /usr/share/debci/bin/debci-worker --do-request
debci 4918  0.0  0.0  13096  3276 ?SJun17   0:00  \_ 
/bin/sh /usr/share/debci/bin/debci-test --quiet --data-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT --suite kali-rolling --print-output 
--run-id=332825 thunderbird
debci 4979  0.0  0.0  13096  2008 ?SJun17   0:00  
\_ /bin/sh /usr/share/debci/bin/debci-test --quiet --data-dir 
/var/lib/debci/tmp/tmp.xAIA5SX5eT --suite kali-rolling 

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Raphaël Hertzog]

Package: systemd
Version: 241-3
Severity: serious
File: systemd-networkd
User: de...@kali.org
Usertags: origin-kali

I upgraded an (OVH) dedicated server to Debian buster with systemd 241-3 and
while it rebooted correctly, the network did not came back. Looking into
the logs I saw the following messages:

May 20 12:37:10 euterpe systemd-networkd[756]: eno3: Could not bring up 
interface: Invalid argument
May 20 12:37:14 euterpe systemd-networkd[756]: eno3: Gained carrier
May 20 12:37:14 euterpe systemd-networkd[756]: eno3: could not set address: 
Permission denied

The configuration in use is the following:
$ cat /etc/systemd/network/50-default.network
# This file sets the IP configuration of the primary (public) network device.
# You can also see this as "OSI Layer 3" config.
# It was created by the OVH installer, please be careful with modifications.
# Documentation: man systemd.network or 
https://www.freedesktop.org/software/systemd/man/systemd.network.html

[Match]
MACAddress=ac:1f:6b:67:cd:e8

[Network]
Description=network interface on public network, with default route
DHCP=no
Address=54.39.104.6/24
Gateway=54.39.104.254
#IPv6AcceptRA=false
NTP=ntp.ovh.net
DNS=127.0.0.1
DNS=213.186.33.99
DNS=2001:41d0:3:163::1
Gateway=2607:5300:0203:39ff:ff:ff:ff:ff

[Address]
Address=2607:5300:0203:3906::/64

[Route]
Destination=2607:5300:0203:39ff:ff:ff:ff:ff
Scope=link

$ cat /etc/systemd/network/50-public-interface.link
# This file configures the relation between network device and device name.
# You can also see this as "OSI Layer 2" config.
# It was created by the OVH installer, please be careful with modifications.
# Documentation: man systemd.link or 
https://www.freedesktop.org/software/systemd/man/systemd.link.html

[Match]
MACAddress=ac:1f:6b:67:cd:e8

[Link]
Description=network interface on public network, with default route
MACAddressPolicy=persistent
NamePolicy=kernel database onboard slot path mac
#Name=eth0  # name under which this interface is known under OVH rescue 
system
#Name=eno3  # name under which this interface is probably known by systemd

The ethernet card is the following:
$ lspci -v
[...]
03:00.0 Ethernet controller: Intel Corporation Ethernet Connection X552/X557-AT 
10GBASE-T
Subsystem: Super Micro Computer Inc Ethernet Connection X552/X557-AT 
10GBASE-T
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at 383fffc0 (64-bit, prefetchable)
Memory at 383fffe04000 (64-bit, prefetchable)
Expansion ROM at fb18 [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Capabilities: [a0] Express Endpoint, MSI 00

03:00.1 Ethernet controller: Intel Corporation Ethernet Connection X552/X557-AT 
10GBASE-T
Subsystem: Super Micro Computer Inc Ethernet Connection X552/X557-AT 
10GBASE-T
Flags: bus master, fast devsel, latency 0, IRQ 10
Memory at 383fffa0 (64-bit, prefetchable)
Memory at 383fffe0 (64-bit, prefetchable)
Expansion ROM at fb10 [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
[...]

It is handled by the "ixgbe" kernel driver:
$ grep ixgbe /var/log/kern.log:
May 23 21:19:38 euterpe kernel: [1.896199] ixgbe: Intel(R) 10 Gigabit PCI 
Express Network Driver - version 5.1.0-k
May 23 21:19:38 euterpe kernel: [1.908671] ixgbe: Copyright (c) 1999-2016 
Intel Corporation.
May 23 21:19:38 euterpe kernel: [3.471556] ixgbe :03:00.0: Multiqueue 
Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0
May 23 21:19:38 euterpe kernel: [3.619415] ixgbe :03:00.0: MAC: 5, PHY: 
7, PBA No: 023A00-000
May 23 21:19:38 euterpe kernel: [3.628980] ixgbe :03:00.0: 
ac:1f:6b:67:cd:e8
May 23 21:19:38 euterpe kernel: [3.689232] ixgbe :03:00.0: Intel(R) 10 
Gigabit Network Connection
May 23 21:19:38 euterpe kernel: [5.487530] ixgbe :03:00.1: Multiqueue 
Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0
May 23 21:19:38 euterpe kernel: [5.627263] ixgbe :03:00.1: MAC: 5, PHY: 
7, PBA No: 023A00-000
May 23 21:19:38 euterpe kernel: [5.634459] ixgbe :03:00.1: 
ac:1f:6b:67:cd:e9
May 23 21:19:38 euterpe kernel: [5.696963] ixgbe :03:00.1: Intel(R) 10 
Gigabit Network Connection
May 23 21:19:38 euterpe kernel: [5.707134] ixgbe :03:00.1 eno4: renamed 
from eth1
May 23 21:19:38 euterpe kernel: [5.733678] ixgbe :03:00.0 eno3: renamed 
from eth0
May 23 21:19:39 euterpe kernel: [   22.934955] ixgbe :03:00.0: registered 
PHC device on eno3
May 23 21:19:43 euterpe kernel: [   27.453172] ixgbe :03:00.0 eno3: NIC 
Link is Up 1 Gbps, Flow Control: None


Trying to narrow 

Bug#927373: salsa: invalid warning "You're not member of this group" when using sub-group

[Raphaël Hertzog]

Package: devscripts
Version: 2.19.4
Severity: minor
User: de...@kali.org
Usertags: origin-kali

When you work on a sub-group, and if you have access to this group through
the parent group, then salsa will emit a warning "You're not member of
this group" which is not correct since I'm part of the group through the
membership of the parent group.

$ salsa --conf-file salsa-auth.conf --group-id 5034987 update_repo --no-fail 
--all --rename-head --source-branch master --dest-branch kali/master
salsa warn: You're not member of this group
You're going to configure 811 projects. Continue (N/y)

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBRELEASE_UPLOADER=dput
DEBRELEASE_DEBS_DIR=../build-area
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_PRESERVE=yes
DEBUILD_LINTIAN_OPTS="--color always -I"
DEBSIGN_KEYID=0x3E4FB7117877F589DBCF06D6E619045DF2AC729A
DEBSIGN_PROGRAM=gpg2
DEBCHANGE_AUTO_NMU=no
DEBCOMMIT_SIGN_TAGS=yes
DEBCOMMIT_SIGN_COMMITS=yes

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.13-1
ii  gnupg22.2.13-1
ii  gpgv  2.2.13-1
ii  libc6 2.28-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0
ii  at  3.1.23-1
ii  curl7.64.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.03.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.12.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
ii  autopkgtest   5.10
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
ii  dose-extra5.0.1-12
pn  duck  
ii  faketime  0.9.7-3
pn  gnuplot   
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-3
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.9p1-10
ii  piuparts  0.98
ii  postgresql-client 11+200+deb10u1
ii 

Bug#927367: salsa: uninitialized value warning when description is missing on a fresh repo

[Raphaël Hertzog]

Package: devscripts
Version: 2.19.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

We imported many repositories (through a manifest file) on gitlab.com and
they were all lacking descriptions. When I ran my update_safe command to
rename all the descriptions I got lots of unitialized values warnings:

$ salsa --conf-file salsa-packages.conf update_safe --all
[...]
Use of uninitialized value in string ne at 
/usr/share/perl5/Devscripts/Salsa/check_repo.pm line 45.
Use of uninitialized value in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Salsa/check_repo.pm line 45.
[...]

It would be nice if we could avoid this noise.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBRELEASE_UPLOADER=dput
DEBRELEASE_DEBS_DIR=../build-area
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_PRESERVE=yes
DEBUILD_LINTIAN_OPTS="--color always -I"
DEBSIGN_KEYID=0x3E4FB7117877F589DBCF06D6E619045DF2AC729A
DEBSIGN_PROGRAM=gpg2
DEBCHANGE_AUTO_NMU=no
DEBCOMMIT_SIGN_TAGS=yes
DEBCOMMIT_SIGN_COMMITS=yes

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.13-1
ii  gnupg22.2.13-1
ii  gpgv  2.2.13-1
ii  libc6 2.28-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0
ii  at  3.1.23-1
ii  curl7.64.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.03.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.12.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
ii  autopkgtest   5.10
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
ii  dose-extra5.0.1-12
pn  duck  
ii  faketime  0.9.7-3
pn  gnuplot   
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-3
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.9p1-10
ii  piuparts  0.98
ii  

Bug#927366: salsa: --no-fail does not work as expected with update_safe

[Raphaël Hertzog]

Package: devscripts
Version: 2.19.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I'm running this command:
$ salsa --conf-file salsa-auth.conf --conf-file +./salsa-packages.conf 
update_safe --all --yes --no-fail --verbose

salsa-auth.conf has my token and the API URL, and salsa-packages contains
instructions to configure my package repositories:
$ cat salsa-packages.conf 
#SALSA_GROUP=kalilinux/packages
SALSA_GROUP_ID=5034987

SALSA_DESC_PATTERN="%p packaging for Kali Linux"
SALSA_DESC=yes

SALSA_EMAIL=yes
SALSA_EMAIL_RECIPIENTS="someth...@example.net"

SALSA_SOURCE_BRANCH=master
SALSA_DEST_BRANCH=kali/master
SALSA_RENAME_HEAD=yes

SALSA_ENABLE_MR=yes
SALSA_ENABLE_ISSUES=no


Among all my repositories, I have some that have a "master" branch that
needs to be renamed into "kali/master" but I also have some repositories
that lack both "master" and "kali/master" and instead they have
"kali/dev". The --rename-head fails on the last set of repositories but
they are a minority so I wanted to go ahead anyway with the --no-fail.
But despite the --no-fail, the above command failed right after the first
error message:

$ salsa --conf-file salsa-auth.conf --conf-file +./salsa-packages.conf 
update_safe --all --yes --no-fail --verbose
[...]
salsa info: Error PUTing https://gitlab.com/api/v4/projects/11904256 (HTTP 
400): Bad Request {"message":{"base":["Could not change HEAD: branch... at 
/usr/share/perl5/Devscripts/Salsa/update_repo.pm line 83.
$ 

Note that it seems to work with "update_repo" however:
$ salsa --conf-file salsa-auth.conf --group-id 5034987 update_repo --no-fail 
--all --rename-head --source-branch master --dest-branch kali/master
You're going to configure 811 projects. Continue (N/y) y
salsa warn: Branch rename has failed for ruby-ruby-progressbar. Use --verbose 
to see errors
[...]

You might find "update_safe --yes" a bit weird, but I don't want the
noise/busy work of update_repo redoing all the configuration that hasn't
changed...

Cheers,

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBRELEASE_UPLOADER=dput
DEBRELEASE_DEBS_DIR=../build-area
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_PRESERVE=yes
DEBUILD_LINTIAN_OPTS="--color always -I"
DEBSIGN_KEYID=0x3E4FB7117877F589DBCF06D6E619045DF2AC729A
DEBSIGN_PROGRAM=gpg2
DEBCHANGE_AUTO_NMU=no
DEBCOMMIT_SIGN_TAGS=yes
DEBCOMMIT_SIGN_COMMITS=yes

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.13-1
ii  gnupg22.2.13-1
ii  gpgv  2.2.13-1
ii  libc6 2.28-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0
ii  at  3.1.23-1
ii  curl7.64.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.03.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.12.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate   

Bug#927350: salsa: does not accept sub-group in --group parameter

[Raphaël Hertzog]

Package: devscripts
Version: 2.19.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

$ salsa --group freexian-team list_groups
Id   : 3695
Name : Extended LTS
Full path: freexian-team/extended-lts
Parent id: 2925
$ salsa --group freexian-team/extended-lts group
salsa error Bad group value in command line

Thus you can't configure repositories in sub-groups except if you
work around this limitation by using "--group-id XXX" instead
of --group.

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.13-1
ii  gnupg22.2.13-1
ii  gpgv  2.2.13-1
ii  libc6 2.28-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0
ii  at  3.1.23-1
ii  curl7.64.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.03.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.12.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
ii  autopkgtest   5.10
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
ii  dose-extra5.0.1-12
pn  duck  
ii  faketime  0.9.7-3
pn  gnuplot   
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-3
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.9p1-10
ii  piuparts  0.98
ii  postgresql-client 11+200+deb10u1
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  postgresql-client-11 [postgresql-client]  11.2-2
ii  quilt 0.65-3
pn  ratt  
pn  reprotest 
ii  svn-buildpackage  0.8.7
ii  w3m   0.5.3-37

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/perl5/Devscripts/Salsa/Config.pm (from 
devscripts package)

Bug#927342: kgb-bot: support webhook with secret token instead of allowed IP range

[Raphaël Hertzog]

Source: kgb-bot
Version: 1.54-1
Severity: important
User: de...@kali.org
Usertags: origin-kali

We wanted to use kgb-bot with repositories hosted on gitlab.com but
the "webhook" support in KGB needs a whitelist of the IP that generates
the request. Unfortunately with a large infastructure such as gitlab's
one the number of IP is large and possibly dynamic so this is not
really a good way to authenticate the requests.

Instead you should consider implementing authentication through a secret
token:
https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#secret-token

Ideally that would require https support instead of http to avoid
attacks through network sniffing.

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

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