date:20211206

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-meowgorithm-babyenv
  Version : 1.3.1-1
  Upstream Author : Christian Rocha
* URL : https://github.com/meowgorithm/babyenv
* License : Expat
  Programming Lang: Go
  Description : Go environment var parsing, for babies

 Package babyenv collects environment variables and places them in
 corresponding struct fields. It aims to reduce the boilerplate in
 reading data from the environment.


Reason for packaging:
 Prerequisite for Glow @ https://github.com/charmbracelet/glow
TODO: perhaps reasoning

Bug#990541: cve was addressed upstream

Hi

On Tue, Dec 07, 2021 at 09:06:41AM +0900, yokota wrote:
> > For stretch, you would have to provide a patch based on the 5.6.6 change.
> 
> Do you know how to upload to stretch-update?
> I found how to upload to bullseye/buster by "reportbug" package, but
> not stretch.
> Or it's too late to upload to stretch?

I'm not sure if it is really worth of, because if you want to address
issues in stretch then you might other issues as well, Cf.
https://security-tracker.debian.org/tracker/source-package/unrar-nonfree
.

But that said, stretch is nowdays supported by the LTS project, cf.
https://wiki.debian.org/LTS and there are no more point releases for
stretch.

Regards,
Salvatore

Bug#1001259: ITP: golang-github-muesli-go-app-paths -- retrieve platform-specific paths (app-data, cache, config, etc.)

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-muesli-go-app-paths
  Version : 0.2.1-1
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/go-app-paths
* License : Expat
  Programming Lang: Go
  Description : retrieve platform-specific paths (app-data, cache, config, 
etc.)

 The go-app-paths package retrieves platform-specific paths
 (such as directories for app-data, cache, config, and logs).
 It is fully compliant with the XDG Base Directory Specification on Unix,
 but also provides implementations for macOS and Windows systems.

Reason for packaging:
 Prerequisite for Glow, https://github.com/charmbracelet/glow

Bug#1001258: FTBFS on mips64el

2021-12-06 Thread Stéphane Glondu

Source: llvm-toolchain-11
Version: 1:11.1.0-4
Severity: serious
Tags: ftbfs

Dear Maintainer,

llvm-toolchain-11 FTBFS (at least) on mips64el:

  https://buildd.debian.org/status/package.php?p=llvm-toolchain-11=sid

> [...]
> [ 74%] Building CXX object 
> lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600RegisterInfo.cpp.o
> cd /<>/build-llvm/tools/clang/stage2-bins/lib/Target/AMDGPU && 
> /<>/build-llvm/./bin/clang++ -D_GNU_SOURCE 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I/<>/build-llvm/tools/clang/stage2-bins/lib/Target/AMDGPU 
> -I/<>/llvm/lib/Target/AMDGPU -I/usr/include/libxml2 
> -I/<>/build-llvm/tools/clang/stage2-bins/include 
> -I/<>/llvm/include -fPIC -Wno-unused-command-line-argument 
> -Wno-unknown-warning-option -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion 
> -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -fvisibility=hidden  
> -fno-exceptions -std=c++14 -MD -MT 
> lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600RegisterInfo.cpp.o -MF 
> CMakeFiles/LLVMAMDGPUCodeGen.dir/R600RegisterInfo.cpp.o.d -o 
> CMakeFiles/LLVMAMDGPUCodeGen.dir/R600RegisterInfo.cpp.o -c 
> /<>/llvm/lib/Target/AMDGPU/R600RegisterInfo.cpp
> free(): invalid pointer
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
> backtrace, preprocessed source, and associated run script.
> Stack dump:
> 0.Program arguments: /<>/build-llvm/./bin/clang++ 
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS 
> -I/<>/build-llvm/tools/clang/stage2-bins/lib/Target/AMDGPU 
> -I/<>/llvm/lib/Target/AMDGPU -I/usr/include/libxml2 
> -I/<>/build-llvm/tools/clang/stage2-bins/include 
> -I/<>/llvm/include -fPIC -Wno-unused-command-line-argument 
> -Wno-unknown-warning-option -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion 
> -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -fvisibility=hidden 
> -fno-exceptions -std=c++14 -MD -MT 
> lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600OptimizeVectorRegisters.cpp.o
>  -MF CMakeFiles/LLVMAMDGPUCodeGen.dir/R600OptimizeVectorRegisters.cpp.o.d -o 
> CMakeFiles/LLVMAMDGPUCodeGen.dir/R600OptimizeVectorRegisters.cpp.o -c 
> /<>/llvm/lib/Target/AMDGPU/R600OptimizeVectorRegisters.cpp 
> 1. parser at end of file
> 2./<>/llvm/include/llvm/Support/GenericDomTree.h:669:8: 
> instantiating function definition 
> 'llvm::DominatorTreeBase::splitBlock'
> 3./<>/llvm/include/llvm/Support/GenericDomTree.h:802:8: 
> instantiating function definition 
> 'llvm::DominatorTreeBase false>::Split>'
> 4.
> /usr/lib/gcc/mips64el-linux-gnuabi64/11/../../../../include/c++/11/type_traits:1031:12:
>  instantiating class definition 
> 'std::is_nothrow_default_constructible *>>'
> 5.
> /usr/lib/gcc/mips64el-linux-gnuabi64/11/../../../../include/c++/11/type_traits:116:12:
>  instantiating class definition 
> 'std::__or_>, 
> std::is_function>, 
> std::is_void>, 
> std::__is_array_unknown_bounds>>'
> 6.
> /usr/lib/gcc/mips64el-linux-gnuabi64/11/../../../../include/c++/11/type_traits:116:12:
>  instantiating class definition 
> 'std::__or_>, 
> std::is_void>, 
> std::__is_array_unknown_bounds>>'
> /<>/build-llvm/bin/../lib/libLLVM-11.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x50)[0xffef61e960]
> clang-11: error: clang frontend command failed due to signal (use -v to see 
> invocation)
> Debian clang version 11.1.0-4+b2
> Target: mips64el-unknown-linux-gnuabi64
> Thread model: posix
> InstalledDir: /<>/build-llvm/./bin
> clang-11: note: diagnostic msg: 
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-11: note: diagnostic msg: /tmp/R600OptimizeVectorRegisters-a3d80c.cpp
> clang-11: note: diagnostic msg: /tmp/R600OptimizeVectorRegisters-a3d80c.sh
> clang-11: note: diagnostic msg: 
> 
> 
> make[8]: *** 
> [lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/build.make:961: 
> lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600OptimizeVectorRegisters.cpp.o]
>  Error 254
> make[8]: *** Waiting for unfinished jobs
> [...]
> make: *** [debian/rules:301: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2


Cheers,

-- 
Stéphane

-- System

Bug#990541: cve was addressed upstream

Hi,

On Tue, Dec 07, 2021 at 12:29:20AM +0100, Bastian Germann wrote:
> On 07.12.21 00:22, yokota wrote:
> > Hi,
> > 
> > > stretch is vulnerable (test case; misleading min. version in CVE 
> > > description) and bullseye is
> > > vulnerable according to the CVE description.
> > 
> > Do we needs unurar-nonfree 6.0.4 for stretch/bullseye?
> > I can make stretch/bullseye-update package for next point release.
> > 
> 
> I have just run the test on 6.0.3 and it also seems to be fine.
> So either the test case or the CVE description is bad.
> Since qopen.cpp is modified in 5.6.6 and not 6.0.4 I guess the CVE 
> description is bad.
> 
> For stretch, you would have to provide a patch based on the 5.6.6 change.

So I did a 'bisect' with the binary package builds, and the following
seems to support the above that 5.6.6 might be the right version:

With 1:5.5.8-1

$ ./CVE-2018-25018.sh 

UNRAR 5.50 freeware  Copyright (c) 1993-2017 Alexander Roshal

Corrupt header is found
Corrupt header is found
Corrupt header is found
QO - the file header is corrupt
Main archive header is corruptSegmentation fault
Exit status: 139

With 1:5.6.6-1

./CVE-2018-25018.sh 

UNRAR 5.61 beta 1 freeware  Copyright (c) 1993-2018 Alexander
Roshal

Corrupt header is found
Corrupt header is found
Corrupt header is found
QO - the file header is corrupt
Main archive header is corrupt
Corrupt header is found
QO - the file header is corrupt
Corrupt header is found
Corrupt header is found

Testing archive ./9845.rar

Corrupt header is found
QO - the file header is corrupt
Corrupt header is found
Corrupt header is found
No files to extract
Exit status: 3

Double-checking with an ASAN build:

./unrar t /build/9845.rar 

UNRAR 5.50 freeware  Copyright (c) 1993-2017 Alexander Roshal

Corrupt header is found
Corrupt header is found
Corrupt header is found
QO - the file header is corrupt
Main archive header is 
corrupt=
==22781==ERROR: AddressSanitizer: negative-size-param: (size=-65491)
#0 0x7f1e303eaa1f in __interceptor_memcpy 
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x5a844c  (/build/unrar-nonfree-5.5.8/unrar+0x5a844c)
#2 0x5a8c7d  (/build/unrar-nonfree-5.5.8/unrar+0x5a8c7d)
#3 0x5a91c9  (/build/unrar-nonfree-5.5.8/unrar+0x5a91c9)
#4 0x42f23b  (/build/unrar-nonfree-5.5.8/unrar+0x42f23b)
#5 0x472d34  (/build/unrar-nonfree-5.5.8/unrar+0x472d34)
#6 0x44fcea  (/build/unrar-nonfree-5.5.8/unrar+0x44fcea)
#7 0x457601  (/build/unrar-nonfree-5.5.8/unrar+0x457601)
#8 0x435c0d  (/build/unrar-nonfree-5.5.8/unrar+0x435c0d)
#9 0x4e16be  (/build/unrar-nonfree-5.5.8/unrar+0x4e16be)
#10 0x4e3999  (/build/unrar-nonfree-5.5.8/unrar+0x4e3999)
#11 0x5756ae  (/build/unrar-nonfree-5.5.8/unrar+0x5756ae)
#12 0x40e798  (/build/unrar-nonfree-5.5.8/unrar+0x40e798)
#13 0x7f1e2f516e49 in __libc_start_main ../csu/libc-start.c:314
#14 0x40f649  (/build/unrar-nonfree-5.5.8/unrar+0x40f649)

0x631247d4 is located 65492 bytes inside of 65536-byte region 
[0x63114800,0x63124800)
allocated by thread T0 here:
#0 0x7f1e30461097 in operator new[](unsigned long) 
../../../../src/libsanitizer/asan/asan_new_delete.cpp:102
#1 0x5a4551  (/build/unrar-nonfree-5.5.8/unrar+0x5a4551)
#2 0x42b81d  (/build/unrar-nonfree-5.5.8/unrar+0x42b81d)
#3 0x4e14cd  (/build/unrar-nonfree-5.5.8/unrar+0x4e14cd)
#4 0x4e3999  (/build/unrar-nonfree-5.5.8/unrar+0x4e3999)
#5 0x5756ae  (/build/unrar-nonfree-5.5.8/unrar+0x5756ae)
#6 0x40e798  (/build/unrar-nonfree-5.5.8/unrar+0x40e798)
#7 0x7f1e2f516e49 in __libc_start_main ../csu/libc-start.c:314

SUMMARY: AddressSanitizer: negative-size-param 
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
 in __interceptor_memcpy
==22781==ABORTING

Next I have not tried to isolate the change between 5.8.8 and 5.6.6,
but https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9845#c4
supports that the first fixed version ins 5.6.6, for the further
fuzzing 5.6.8 was applied via the pull request.

Regards,
Salvatore

Bug#990541: cve was addressed upstream

Hi,

On Tue, Dec 07, 2021 at 08:00:15AM +0900, yokota wrote:
> Hi,
> 
> > Can you give more information here? Where was it fixed?
> 
> I make autopkgtest `debian/tests/CVE-2018-25018.sh` and pass this test.
> 
> You can check this test code from "unrar-nonfree" source package or:
>  
> https://sources.debian.org/src/unrar-nonfree/1:6.1.2-1/debian/tests/CVE-2018-25018.sh/
> 
> And test results are held on CI log:
>  https://ci.debian.net/packages/u/unrar-nonfree/
> 
> Please reopen this bug if you want.

Yes in fact I used that test for both 6.0.3 and 6.0.4, which lead me
to think something is odd.

BTW, In fact, we never should trust CVE descriptions, there are
several reasons for that. Two which come to my mind are:

- They might be wrong, and noone followed up to correct that

- They reflect only a status in a specific point in time (and got not
  updated), e.g. say it was found to affect version X, but whoever
  reported the issue, did not full analysis, where it was introduced.
  It might be very well as well that then even the description
  mentions version X, that it was not fixed in X+1, and maybe only
  later in X+n.

That is, when we do triage for CVEs we should whenver possible be able
to poin point the respective source change fixing the issue (some
might just cover the issue as well, sometimes another change covers
the bug and does not make it visible with a reproducer, etc ...).
And take into account as well other distros triages and references.

Thanks to you both, for your time!

Regards,
Salvatore

Bug#1001257: sub...@bugs.debian.org

2021-12-06 Thread John Smith

Package: Apt
version: 2.0.6 (amd64)

system: Ubuntu cloud image: ubuntu-20.04-server-cloudimg-amd64-disk-kvm.img
& Ubuntu in general

I've had errors over the years of using apt. Almost every time it's related
to limited installation space. I appreciate all of the utilities of apt,
such as the necessary download size and storage required. As well as the
--fix-broken utility that repairs many problems. However, not all, such as
the one below. The install process froze as the space ran out.

"E: Sub-process /usr/bin/dpkg returned an error code (1)"

This is a difficult error to resolve. Partially because dpkg isnt conveying
the error information. To resolve it last time I had to erase some of the
config files for dpkg, but that's not working this time. Last time I had
removed some of the larger deb files to make space to at least install a
small package ncdu to find space hogs. This time with `apt upgrade` it
stopped when updating the kernel.

There are a couple of things that would in my view really help many, many
Linux users. The first would be to send a warning when the installation
will exceed the storage space. This should be trivial to implement.

Then, possibly more importantly, but I don't know the installation
procedures and whether there is something preventing it, but is there a way
to allow the removal of a package when there is an existing broken install?
That would really help. If I could remove LibreOffice or something to make
enough space to fix the broken install, that would go a very long way.

In fact, one more step back could be very, very useful if possible. How
about allowing the removal of the package that was broken because of not
enough space? I don't see why this couldn't be done.

All of this really underscores having a warning if there is not enough disk
space. It has caused problems almost every time I can think of. I cant
think of a time when it didnt. This is because of the other issues above,
it effectively blocks an operation of apt at all. (And I do overestimate my
free disk space occasionally, especially when setting up these small base
images trying to conserve space because there will be many copies of the VM
file).

It's really frustrating because with one easy to make error, there is no
way to undo it, and I have to find something to delete (not possible on
this small image) or go through the process of resizing, which isnt
something I wanted to do because shrinking can be problematic, and I was
actually just trying to get grub to work on this cloud image by trying to
see if upgrade was somehow related, which I dont think it is, but I thought
was worth trying.

I cant even install the reportbug package.

I really think these couple of improvements will really help the average
Linux user and take so much of the headache and hassle out of what is very
nearly the best OS today.

Thank you.

Bug#1000790: uhd: FTBFS on ppc64el: c++: error: unrecognized command-line option ‘-march=native’; did you mean ‘-mcpu=native’?

2021-12-06 Thread Steve Langasek

Package: uhd
Version: 4.1.0.4-3
Followup-For: Bug #1000790
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Hi Maitland,

It seems uhd 4.1.0.4-3 included a change that was intended to fix this
specific build failure, but the fix was incomplete.

Please find attached a debdiff which fixes the remaining references to
-march=native.  It has been uploaded to Ubuntu, where it's confirmed to fix
the build failure on ppc64el:

  https://launchpad.net/ubuntu/+source/uhd/4.1.0.4-3ubuntu1/+build/22596389

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru uhd-4.1.0.4/debian/patches/cmake-check-march 
uhd-4.1.0.4/debian/patches/cmake-check-march
--- uhd-4.1.0.4/debian/patches/cmake-check-march2021-12-05 
13:07:56.0 -0800
+++ uhd-4.1.0.4/debian/patches/cmake-check-march2021-12-06 
18:14:37.0 -0800
@@ -9,10 +9,10 @@
  host/lib/transport/uhd-dpdk/CMakeLists.txt | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
-diff --git a/host/lib/transport/uhd-dpdk/CMakeLists.txt 
b/host/lib/transport/uhd-dpdk/CMakeLists.txt
-index c19fcae78..a709f0761 100644
 a/host/lib/transport/uhd-dpdk/CMakeLists.txt
-+++ b/host/lib/transport/uhd-dpdk/CMakeLists.txt
+Index: uhd-4.1.0.4/host/lib/transport/uhd-dpdk/CMakeLists.txt
+===
+--- uhd-4.1.0.4.orig/host/lib/transport/uhd-dpdk/CMakeLists.txt
 uhd-4.1.0.4/host/lib/transport/uhd-dpdk/CMakeLists.txt
 @@ -10,8 +10,12 @@
  if(ENABLE_DPDK)
  if(NOT DEFINED UHD_DPDK_CFLAGS)
@@ -27,6 +27,16 @@
  message(STATUS "DPDK: Using default UHD_DPDK_CFLAGS=" 
${UHD_DPDK_CFLAGS})
  endif(NOT DEFINED UHD_DPDK_CFLAGS)
  
--- 
-2.30.2
-
+Index: uhd-4.1.0.4/host/tests/CMakeLists.txt
+===
+--- uhd-4.1.0.4.orig/host/tests/CMakeLists.txt
 uhd-4.1.0.4/host/tests/CMakeLists.txt
+@@ -196,7 +196,7 @@
+ ${CMAKE_SOURCE_DIR}/lib/transport/uhd-dpdk/dpdk_common.cpp
+ ${CMAKE_SOURCE_DIR}/lib/transport/uhd-dpdk/dpdk_io_service.cpp
+ ${CMAKE_SOURCE_DIR}/lib/transport/udp_dpdk_link.cpp
+-PROPERTIES COMPILE_FLAGS "-march=native -D_GNU_SOURCE"
++PROPERTIES COMPILE_FLAGS "${UHD_DPDK_CFLAGS} -D_GNU_SOURCE"
+ )
+ ENDIF(ENABLE_DPDK)
+

Bug#1001255: Fwd: binutils/mipsel: ld testsuite cost too much time due to lto, so failed

2021-12-06 Thread YunQiang Su

Package: src:binutils
Version: 2.37-10

Our mips32 build machines have so bad performance.
It costs to much time to run some ld testcase.

Here we just disable LTO for them.


mips32-ld-bootstrap-disable-lto.diff
Description: Binary data

Bug#1001009: Downloads external files on install

2021-12-06 Thread Tong Sun

Control: tags -1 + moreinfo
thanks

On Sun, Dec 5, 2021 at 8:23 PM Tong Sun wrote:
>
> On Sun, Dec 5, 2021 at 3:30 PM Tong Sun wrote:
> >
> > Hi Andrey,
> >
> > Would this fix the problem?
> > https://salsa.debian.org/debian/dbab/-/commit/40d960d7108051fc7ff07b1b4bbc8580722393c9
>
> W: dbab: unknown-section contrib
>
> Maybe not.
> So what exactly do you mean "moved to contrib", Andrey?
>
> > thx
> >
> > On Sun, Dec 5, 2021 at 9:56 AM Tong Sun
> >  wrote:
> > >
> > > Thanks Andrey,
> > >
> > > Two questions,
> > >
> > > By "moved to contrib", did you meant to change
> > >
> > > Section: net
> > >
> > > to
> > >
> > > Section: contrib
> > >
> > > in d/control?
> > >
> > > Now, let's define what "package cannot function" actually means. If
> > > functions normally without this or similar unpackaged file, but the
> > > program is completely data driven, i.e., no ads sites from the list
> > > are blocked unless the list is there.
> > >
> > > So, strictly speaking, the package indeed cannot function without this
> > > or similar unpackaged file, right? And the solution is just above,
> > > right?
> > >
> > > thx!
> > >
> > > On Thu, Dec 2, 2021 at 11:33 AM Andrey Rahmatullin  
> > > wrote:
> > > >
> > > > Package: dbab
> > > > Version: 1.3.2-1
> > > > Severity: serious
> > > >
> > > > The package runs `dbab-get-list` in postinst, which downloads
> > > > http://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq=0=plaintext
> > > >
> > > > If the package cannot function without this or similar unpackaged file, 
> > > > it
> > > > should be moved to contrib. If it can, the downloading should be done 
> > > > by the
> > > > user/administrator.
> > > >
> > > >
> > > > -- System Information:
> > > > Debian Release: bookworm/sid
> > > >   APT prefers unstable-debug
> > > >   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> > > > 'unstable'), (500, 'testing'), (101, 'experimental')
> > > > Architecture: amd64 (x86_64)
> > > > Foreign Architectures: i386
> > > >
> > > > Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
> > > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> > > > TAINT_UNSIGNED_MODULE
> > > > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
> > > > LANGUAGE not set
> > > > Shell: /bin/sh linked to /usr/bin/dash
> > > > Init: systemd (via /run/systemd/system)
> > > > LSM: AppArmor: enabled
> > > >
> > > > Versions of packages dbab depends on:
> > > > ii  bind9-dnsutils [dnsutils]  1:9.17.20-3
> > > > ii  curl   7.79.1-2
> > > > pn  dnsmasq
> > > > ii  perl   5.32.1-6
> > > >
> > > > dbab recommends no packages.
> > > >
> > > > dbab suggests no packages.

Bug#991967: (Presently) Not in 5.10 source

2021-12-06 Thread Elliott Mitchell

Having finally gotten to test this, the issue does NOT effect 5.10.70-1.
So far I've only gotten to try reboot, but that went fine.

Might have been an ACPI or Xen mismerge into 4.19.  Alas this may simply
disappear into history.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Paul Wise

gregor herrmann wrote:

> But this forked PPI seems like a blocker, at least I have no good
> idea how to handle it right now. [1]

It seems like the best option would be to talk to upstream about
depending on its dependencies instead of embedding/forking them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

2021-12-06 Thread Paul Wise

On Mon, 2021-12-06 at 21:56 +0100, Raphael Hertzog wrote:

> Why do you want a lists.debian.org link when you already have a
> tracker.debian.org link pointing to the same content?

I don't want a tracker.d.o link. Mainly I want a link with a Message-ID
in it, which are more likely to be long-term and supported by multiple
message archives than other software-specific links.

> Also there's no guaranty that all news are properly recorded in a Debian
> mailing lists. I assume testing migration mails aren't for example.

Sure, but most are and some of the mails that go to unarchived mailing
lists are archived on external services linked from the lists.d.o
Message-ID search 404 page. The testing migration mails definitely
aren't archived on lists.d.o right now but if @packages.d.o mails ever
get forwarded to lists.d.o and archived then they could be. Also filed
#1001254 to make tracker.d.o mail archives searchable by Message-ID.

> And this would be a feature that is really specific to Debian too,
> while the news feature is very generic and cleanly mixing both would
> require again some abstraction to add a vendor-specific behaviour in a
> generic part.

Not necessarily, there are several options for this that would make it
a very generic feature, some ideas:

When the List-Archive header exists and contains a URL, the link could
be to that URL. This works for Debian lists and mailman lists and
probably other types of lists too.

distro-tracker could have a list of domains that are known to have
Message-ID search URLs and then map the List-Id to those URLs.

For domains that have no Message-ID search URLs but do have archive
links for the Maintainer field, the link could be to just the top-level
archive link used for the Maintainer field.

Once #1001254 is implemented, then the link could be to the DPT
Message-ID search, in a similar way to how lists.d.o links to its
Message-ID search from the Message-ID field in its archives.

> In short, I find the cost really high for a relatively small value
> added.

I think the options I presented above are generic enough to have a low
enough cost. For cases not covered by them I think as a compromise, it
would be reasonable to just show the Message-ID header with no link.
That would allow copy-pasting the Message-ID to external services:

https://en.wikipedia.org/wiki/Message-ID#Use_in_mailing_list_archives

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1001254: tracker.debian.org: add Message-ID redirector for mails publicly visible in the news section

2021-12-06 Thread Paul Wise

Package: tracker.debian.org
Severity: wishlist

Currently the only place that testing migration mails are publicly
archived is on the tracker.debian.org news section. There are probably
other mails in a similar situation. It would be nice to be able to go
from such a mail in local email archives directly to a public web page
for those emails. The best option seems to be to be able to copy the
Message-ID header into a redirector service similar to the lists.d.o
one. That works by appending the Message-ID to the URL, or sending
GET/POST requests containing the Message-ID. In addition there are
options to show only links to the found message(s) or to just redirect
to the first found message. When a message is not found, the proposed
redirector should give a 404 page similar to the lists.d.o one; linking
to the lists.d.o redirector and the MARC and Mail-Archive.com ones and
also linking to the Wikipedia page of other Message-ID redirectors.

https://lists.debian.org/msgid-search/
https://lists.debian.org/msgid-search/20050606213954.gc...@finlandia.infodrom.north.de
https://lists.debian.org/msgid-search/20050606213954.gc...@finlandia.infodrom.north.de/links
https://lists.debian.org/msgid-search/20051008021705.ga19...@wolffelaar.nl/firsthit
https://lists.debian.org/msgid-search/not-a-working-messageid
https://en.wikipedia.org/wiki/Message-ID#Use_in_mailing_list_archives

   Sorry, no match found for message-id not-a-working-messageid
   
   It may take a few minutes until a new message is available in the
   archive.
   
   The archive is updated every 20 minutes.
   
   You can try searching MARC or Mail-Archive.com
   
   Other search engines for Message-IDs can be found at Wikipedia

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-06 Thread nick black

i went ahead and uploaded growlight 1.2.38 to experimental last
evening. it doesn't build now, of course, due to a dep on
missing libnotcurses3. i've asked my Application Manager (i'm
currently applying for DD status) to sponsor an upload of the
latter to experimental+NEW, so that i can begin the transition.
at the end of this process, i expect us to have a 1.2.38
uploaded to unstable which will remedy this annoyance.

also, just for the record, let me point out that the autopkgtest
regression is due in part to the way it's being run in the
autopkgtest environment--this is usually an interactive program.
i fully agree that it's important to get it resolved, but it's
not something that ought affect the majority of users.

in any case, things will be in much better shape when 1.2.38
hits unstable.


signature.asc
Description: PGP signature

Bug#1001253: wl-beta: After network change, cannot fetch email

2021-12-06 Thread peter

Package: wl-beta
Version: 2.15.9+0.20210629-1
Severity: normal

Dear Maintainer,

I have wl-beta to pick up Imap email from several places, over ssl.
This all works.
If I suspend my laptop, and resume it somewhere where /etc/resolv.conf
is different (home vs work for instance), any attempt to fetch email
gives:
  mailserver.name/993 Temporary failure in name resolution

Other emacs functions work properly:  I can do
   (dns-query "mailserver.name")
in a *scratch* buffer, and get the correct response.

strace shows an attempt to talk to the old nameserver.

Quitting wl and restarting it does not help.  The only solution is to
exit from Emacs and restart.



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:e
n
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wl-beta depends on:
ii  apel   10.8+0.20201106-1
ii  dpkg   1.20.9
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1
ii  emacsen-common 3.0.4
ii  flim   1:1.14.9+0.20210529-1
ii  install-info   6.8-3
ii  semi   1.14.7~0.20210613-1

Versions of packages wl-beta recommends:
ii  ca-certificates  20211016

Versions of packages wl-beta suggests:
pn  bbdb  
pn  bogofilter | bsfilter | spamassassin  
ii  gnupg 2.2.27-2
pn  gnutls-bin
pn  im
pn  maildir-utils 
pn  mhc   
pn  mu-cite   
pn  namazu2   
pn  notmuch   
ii  openssl   1.1.1l-1
pn  starttls  
pn  w3m-el
pn  x-face-el

Bug#1001252: devilspie2: Crashes when encountering X errors (e.g. undecorate after exit)

2021-12-06 Thread Matthew Horan

Package: devilspie2
Version: 0.43-4
Severity: normal
Tags: patch

Dear Maintainer,

The latest released version of devilspie2 calls a deprecated (and 
seemingly non-functional) function to trap X errors instead of 
terminating the caller. This means that any scripts that e.g.  
undecorate windows after exit will cause devilspie2 to crash.

This has been fixed on the unreleased master branch upstream but no new 
version has been released. Applying the following patch to this package 
resolves the crash for me: 
https://github.com/dsalt/devilspie2/commit/350dfc480d254c48aefcfaf6136d3e2cc4a0d75b

Note that there is another related fix to get_window_is_decorated on the 
master branch: 
https://github.com/dsalt/devilspie2/commit/547c31c63c63dffe03effab0570ecd99ecc8d859.

It would be great to see these patches applied to the Debian package and 
ideally backported to bullseye.

Thanks,
Matt

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

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

Versions of packages devilspie2 depends on:
ii  libc6 2.31-13+deb11u2
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  liblua5.1-0   5.1.5-8.1+b3
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.7.2-1

devilspie2 recommends no packages.

devilspie2 suggests no packages.

-- no debconf information

Bug#990541: cve was addressed upstream

2021-12-06 Thread yokota

> For stretch, you would have to provide a patch based on the 5.6.6 change.

Do you know how to upload to stretch-update?
I found how to upload to bullseye/buster by "reportbug" package, but
not stretch.
Or it's too late to upload to stretch?

--
YOKOTA Hiroshi

Bug#998701: correct lintian documentation site

2021-12-06 Thread Osamu Aoki

Hi,

Thanks for working on this but ...
On Mon, 2021-12-06 at 03:49 -0800, Felix Lechner wrote:
> Hi,
> 
> On Sun, Nov 21, 2021 at 1:00 AM Osamu Aoki  wrote:
> > 
> > Felix, what is your plan?
> 
> The Lintian manual is now published online. The URL is
> https://lintian.debian.org/manua/index.html. [1]

You skipped "l" here.

> We also provided a navigation entry on our website as well as a
> redirect to the index page. Thank you!

"Sorry, page not found" was the response of above URL :-)

You may consider adding link to the root page for wrong file path as the server
configuration.

Osamu

Bug#1001251: debcargo changed names of a feature package

2021-12-06 Thread Daniel Kahn Gillmor

Package: debcargo
Version: 2.5.0-2
Control: affects -1 src:rust-buffered-reader

debcargo 2.4.4 packaged rust-buffered-reader 1.0.1 with four non-virtual
packages:

librust-buffered-reader-dev
librust-buffered-reader+bzip2-dev
librust-buffered-reader+compression-dev
librust-buffered-reader+compression-deflate-dev

buffered-reader 1.1.1 does not differ in its features at all from 1.0.1,
but when i try to package it with debcargo 2.5.0, it produces the
following list instead:

librust-buffered-reader-dev
librust-buffered-reader+bzip2-dev
librust-buffered-reader+compression-dev
librust-buffered-reader+flate2-dev

note that previously, …+compression-deflate-dev Provides: a virtual …+flate2-dev
package.  Now, …+flate2-dev Provides: a virtual
…+compression-deflate-dev package.

Note that the [features] section of the upstream Cargo.toml has not
changed:


[features]
compression = ["compression-deflate", "compression-bzip2"]
compression-bzip2 = ["bzip2"]
compression-deflate = ["flate2"]
default = ["compression"]


This change does make for a consistency between the way the packages
represent the bzip2 and flate2 features, but the fact that the
non-virtual package name has changed means we're incurring a needless
round trip through NEW, which incurs more friction between the rust and
FTP teams.

To avoid the friction, i'll probably work around by overriding the
generated debian/control, but this is kind of a sledgehammer approach to
fix a problem that i think debcargo was meant to solve.

If there are any suggestions for how to handle this more gracefully, i'd
be interested.

   --dkg


signature.asc
Description: PGP signature

Bug#990541: cve was addressed upstream

2021-12-06 Thread Bastian Germann


On 07.12.21 00:22, yokota wrote:

Hi,


stretch is vulnerable (test case; misleading min. version in CVE description) 
and bullseye is
vulnerable according to the CVE description.


Do we needs unurar-nonfree 6.0.4 for stretch/bullseye?
I can make stretch/bullseye-update package for next point release.



I have just run the test on 6.0.3 and it also seems to be fine.
So either the test case or the CVE description is bad.
Since qopen.cpp is modified in 5.6.6 and not 6.0.4 I guess the CVE description 
is bad.

For stretch, you would have to provide a patch based on the 5.6.6 change.

Bug#1000982: transition: gnustep-base, gnustep-gui

2021-12-06 Thread Sebastian Ramacher

Control: tags -1 confirmed

On 2021-12-02 08:40:21 +0200, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
> 
> We would like the Release Team's permission to carry out a GNUstep
> transition, namely
> 
>   libgnustep-base1.27 -> 1.28
>   libgnustep-gui0.28  -> 0.29
> 
> As usual, it's better to be done simultaneously (only one round
> binNMUs for both libraries) since everything that depends on -gui also
> depends on -base.  As always, gnustep-back will need a sourceful
> upload and should not be binNMUed.
> 
> I have build-tested all rdeps and no problems were observed, at least
> on amd64.  The auto tracker(s) at release.d.o is/are correct.

Please go ahead

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990541: cve was addressed upstream

2021-12-06 Thread yokota

Hi,

> stretch is vulnerable (test case; misleading min. version in CVE description) 
> and bullseye is
> vulnerable according to the CVE description.

Do we needs unurar-nonfree 6.0.4 for stretch/bullseye?
I can make stretch/bullseye-update package for next point release.

--
YOKOTA Hiroshi

Bug#1001247: vim-doc: Please publish Vim packaging policy on the Web

2021-12-06 Thread James McCoy

On Mon, Dec 06, 2021 at 02:41:59PM -0800, Felix Lechner wrote:
> Lintian provides references to the Vim packaging in tag descriptions.
> [1] We determine the appropriate sections by scanning your HTML index
> file.  [2] Vim is somewhat special because your policy is not
> published.

https://vim-team.pages.debian.net/vim/

> Unfortunately, your URL structure is significantly different between
> the versions in stable and unstable. (For example, x73.html vs
> x65.html; please see below for details.)

That's an artifact of docbook2html, as far as I know.  I certainly don't
do anything to specifically generate those obtuse names.


Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1001194: libnitrokey-common: nitrokey 3A not recognized - at least missing udev entries

2021-12-06 Thread Norbert Preining

Hi Szczepan

thanks again for the explanations!

> We are still working on the smart card support, which is planned next year.

Ah, now I remember reading something about smart card firmware is in the
works, that explains it. Sorry for the noise.

> will inform users about the current update procedure on the each firmware
> release.

Ok, so for now I can assume no firmware update is necessary.

> Indeed. While the hardware is final, we still work on adding features to the
> Nitrokey 3 in the coming months, specifically smart card and Password Safe
> support.

Might I ask - *how* can I use the key *now*?
Which functionality is there available at the moment, and which
application can I use?

Best regards

Norbert

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

Bug#1001250: reprotest: code copied from autopkgtest is no longer compatible with current qemu

2021-12-06 Thread Simon McVittie

Package: reprotest
Version: 0.7.19
Severity: important

To reproduce: try building some random package using a VM image produced by
autopkgtest-build-qemu, on a sid host.

> $ reprotest . -- qemu ~/.cache/vectis/debian/sid/amd64/autopkgtest.qcow2
> WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus 
> to increase this.
> : failure: ['qemu-img', 'create', '-f', 'qcow2', '-b', 
> '/home/smcv/.cache/vectis/debian/sid/amd64/autopkgtest.qcow2', 
> '/tmp/autopkgtest-virt-qemu.wnvmilzt/overlay.img'] failed (exit status 1, 
> stderr 'qemu-img: /tmp/autopkgtest-virt-qemu.wnvmilzt/overlay.img: Backing 
> file specified without backing format\nDetected format of qcow2.')
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 847, in 
> run
> return 0 if check_func(*check_args) else 1
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 360, in 
> check
> proc = 
> test_args._replace(result_dir=result_dir).corun_builds(testbed_args)
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 114, in 
> start
> next(cr)
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 312, in 
> corun_builds
> with start_testbed(virtual_server_args, temp_dir, no_clean_on_error,
>   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
> return next(self.gen)
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 86, in 
> start_testbed
> testbed.open()
>   File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 
> 164, in open
> pl = self.command('open', (), 1)
>   File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 
> 435, in command
> ll = self.expect('ok', nresults)
>   File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 
> 403, in expect
> self.bomb('unexpected eof from the testbed')
>   File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70, in 
> bomb
> raise _type(m)
> reprotest.lib.adtlog.TestbedFailure: unexpected eof from the testbed

I think the necessary change to copy from autopkgtest is this one:

  * qemu: Guess format of main disk image (Closes: #968598)

from autopkgtest/5.14, but there have been a lot of other changes to
autopkgtest-virt-qemu, and it now depends on a new private module shared
with autopkgtest-build-qemu.

I would recommend depending on autopkgtest and running the autopkgtest
virt backends (autopkgtest-virt-*) from the PATH, rather than having
a private copy of them: the interface between autopkgtest and its virt
backends is stable (and documented!), even if the adtlog, adt_testbed
and VirtSubproc private Python modules are not currently suitable to be
shared as-is.

smcv

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

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

Versions of packages reprotest depends on:
ii  apt-utils  2.3.13
ii  libdpkg-perl   1.21.0
ii  procps 2:3.3.17-5
ii  python33.9.8-1
ii  python3-debian 0.1.42
ii  python3-distro 1.6.0-2
ii  python3-pkg-resources  59.4.0-1
ii  python3-rstr   2.2.6-3

Versions of packages reprotest recommends:
ii  diffoscope-minimal  195
ii  disorderfs  0.5.11-2
ii  faketime0.9.8-9
ii  locales-all 2.32-5
ii  sudo1.9.5p2-3

Versions of packages reprotest suggests:
ii  autodep8 0.25
ii  qemu-system  1:6.1+dfsg-8+b1
ii  qemu-utils   1:6.1+dfsg-8+b1
ii  schroot  1.6.10-12

-- no debconf information

Bug#990541: cve was addressed upstream

2021-12-06 Thread Bastian Germann


Control: tags -1 stretch bullseye
Control: fixed -1 1:5.6.6-1

On 06.12.21 20:56, Salvatore Bonaccorso wrote:

Hi,

On Mon, Sep 20, 2021 at 05:01:35PM +0200, Bastian Germann wrote:

fixed 990541 unrar-nonfree/1:6.0.4-1


Can you give more information here? Where was it fixed?


It was fixed in upstream version 6.0.4. There was a test case added in 
1:6.0.7-2.
The buster version is also fixed according to running the test case and the author's comment at 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9845#c4.


stretch is vulnerable (test case; misleading min. version in CVE description) and bullseye is 
vulnerable according to the CVE description.

Bug#1001249: apparmor blocks Tor Browser >= 10.5 starting with MOZ_ENABLE_WAYLAND

2021-12-06 Thread Carlos Aguilar

Package: apparmor
Version: 2.13.6-10
Severity: important
X-Debbugs-Cc: hacerespa...@gmail.com

Dear Maintainer,



   * What led up to the situation?
Istalling Tor Browser via the `torbrowser-launcher` (0.3.3-6) package in Debian
11.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Launching Tor in GNOME using the Wayland session with environmental variable
MOZ_ENABLE_WAYLAND=1 in my .bashrc lead to an unusable Tor.
However, Tor works fine in the X11 session or with MOZ_ENABLE_WAYLAND=0 under
the Wayland session in GNOME.

   * What was the outcome of this action?
Tor can't be used under Wayland.

   * What outcome did you expect instead?
To be able to run Tor with environmental variable MOZ_ENABLE_WAYLAND=1.

I found the following issue in torbrowser-launcher:

https://github.com/micahflee/torbrowser-launcher/issues/591

According to the submitter of the issue, Paul Wise:

>Since Tor Browser 10.5 (release notes, tbb#31729) when the MOZ_ENABLE_WAYLAND
environment variable is set, the Firefox build that is part of Tor Browser will
try to use Wayland IPC and if that fails then Tor Browser will not start. The
current torbrowser.Browser.firefox apparmor profile denies access to the
relevant Wayland IPC files/sockets:

>   Jul 07 08:23:15 audit[437003]: AVC apparmor="DENIED" operation="mknod"
profile="torbrowser_firefox" name="/dev/shm/wayland.mozilla.ipc.0" pid=437003
comm="Compositor" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

>I was able to workaround this issue using this command:

>   sudo sh -c 'echo "owner /dev/shm/wayland.mozilla.ipc.[0-9]* rw," >
/etc/apparmor.d/local/torbrowser.Browser.firefox ; apparmor_parser -r
/etc/apparmor.d/torbrowser.Browser.firefox'




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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  lsb-base   11.1.0

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
pn  apparmor-utils   

-- debconf information:

Bug#997513: dovecot: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

2021-12-06 Thread Timo Sirainen

On 6. Dec 2021, at 23.09, Adrian Bunk  wrote:
> 
> On Mon, Oct 25, 2021 at 08:54:45PM +0200, Christian Göttsche wrote:
>> The source of these test failure is LTO: it built fine with GCC 10.3
>> with LTO a month ago on buildd, GCC 11 without LTO works and Clang 13
>> with LTO also works.
>> So either there is some subtle undefined behaviour in dovecot (which
>> gets miscompiled) or the code generation in GCC 11 is buggy (maybe
>> related [1]).
>> 
>> For the mean time the simplest solution is probably to disable LTO
>> ...
> 
> Could you do this as temprorary workaround?

Looks like disabling the md4/md5 little-endian optimizations fixes this as 
well. I'll try to figure out the proper fix in upstream.

diff --git a/src/lib/md4.c b/src/lib/md4.c
index 06e3231bde..798292a16f 100644
--- a/src/lib/md4.c
+++ b/src/lib/md4.c
@@ -42,7 +42,7 @@
  * memory accesses is just an optimization.  Nothing will break if it
  * doesn't work.
  */
-#if defined(__i386__) || defined(__x86_64__) || defined(__vax__)
+#if 0 //defined(__i386__) || defined(__x86_64__) || defined(__vax__)
 /* uint_fast32_t might be 64 bit, and thus may read 4 more bytes
  * beyond the end of the buffer. So only read precisely 32 bits
  */
diff --git a/src/lib/md5.c b/src/lib/md5.c
index 6b5da6c307..c605639aa1 100644
--- a/src/lib/md5.c
+++ b/src/lib/md5.c
@@ -46,7 +46,7 @@
  * memory accesses is just an optimization.  Nothing will break if it
  * doesn't work.
  */
-#if defined(__i386__) || defined(__x86_64__) || defined(__vax__)
+#if 0 //defined(__i386__) || defined(__x86_64__) || defined(__vax__)
 #define SET(n) \
(*(const uint32_t *)[(n) * 4])
 #define GET(n) \

Bug#990541: cve was addressed upstream

2021-12-06 Thread yokota

Hi,

> Can you give more information here? Where was it fixed?

I make autopkgtest `debian/tests/CVE-2018-25018.sh` and pass this test.

You can check this test code from "unrar-nonfree" source package or:
 
https://sources.debian.org/src/unrar-nonfree/1:6.1.2-1/debian/tests/CVE-2018-25018.sh/

And test results are held on CI log:
 https://ci.debian.net/packages/u/unrar-nonfree/

Please reopen this bug if you want.

--
YOKOTA Hiroshi

Bug#1001248: grub-efi-amd64-bin: Add luks2 module

2021-12-06 Thread Marc Riedel

Package: grub-efi-amd64-bin
Version: 2.06-2
Severity: important
Tags: patch

Please add luks2 module to build-efi-images and please notice in the changelog,
that only PBKDF2 is currently supported.

Thanks in adavnce

Marc


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armehf, armhf

Kernel: Linux 5.15.0-1.slh.1-aptosid-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-bin recommends:
pn  efibootmgr 
pn  grub-efi-amd64-signed  

grub-efi-amd64-bin suggests no packages.

*** /tmp/build-efi-images.patch
--- build-efi-images.orig   2021-12-06 23:47:58.369609691 +0100
+++ build-efi-images2021-12-06 23:48:07.717711282 +0100
@@ -180,6 +180,7 @@
gcry_twofish
gcry_whirlpool
luks
+   luks2
lvm
mdraid09
mdraid1x

Bug#1001247: vim-doc: Please publish Vim packaging policy on the Web

2021-12-06 Thread Felix Lechner

Package: vim-doc
Severity: wishlist

Hi,

Lintian provides references to the Vim packaging in tag descriptions.
[1] We determine the appropriate sections by scanning your HTML index
file. [2] Vim is somewhat special because your policy is not
published. (Doc-base isn't either.) All we can do, therefore, is
provide URI into a user's file system.

Unfortunately, your URL structure is significantly different between
the versions in stable and unstable. (For example, x73.html vs
x65.html; please see below for details.) The Lintian maintainers are
therefore uncertain which version to provide. The easiest way would be
for you to publish your packaging policy on the Web. Several other
teams do so. [3]

You may be eligible for the same assistance that we were offered from
the official New Maintainer's guide. [4][5] For Lintian, we ended up
publishing the manual ourselves, but we have a website. [6]

Alternatively, I could replace the Vim policy reference in the tag
shown above [1] with a more permanent link. I believe that no other
tags refer to your policy. Thank you!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/data/authority/vim-policy
[3] https://salsa.debian.org/lintian/lintian/-/tree/master/data/authority
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998701#15
[5] https://www.debian.org/doc/manuals/maint-guide/index.en.html
[6] https://lintian.debian.org/

* * *

If  is an underscore, that line specifies the title and URL
for the whole manual.

bullseye:

_::Debian Packaging Policy for
Vim::file:///usr/share/doc/vim/vim-policy.html/index.html
1::Vim Addon Packaging in a
Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell
2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x73.html
3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x113.html
3.1::Addon 
Structure::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-structure
3.2::Addon 
Packages::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-packages
3.3::Registry 
Entries::file:///usr/share/doc/vim/vim-policy.html/x113.html#registry-entry
4::Tools::file:///usr/share/doc/vim/vim-policy.html/x221.html
A::Vim Registry Entry
Examples::file:///usr/share/doc/vim/vim-policy.html/a245.html

sid:

_::Debian Packaging Policy for
Vim::file:///usr/share/doc/vim/vim-policy.html/index.html
1::Vim Addon Packaging in a
Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell
2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x65.html
3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x126.html
3.1::Addon 
Structure::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-structure
3.2::Addon 
Packages::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-packages
4::Tools::file:///usr/share/doc/vim/vim-policy.html/x166.html

Bug#997104: closed by Fredrik Hallenberg ()

Control: fixed -1 0.13.2-7

On Mon, Dec 06, 2021 at 10:45:47PM +0100, Fredrik Hallenberg wrote:
> I made a mistake in the done-mail, the fix was actually done in version
> 0.13.2-7 which is available. What can I do to fix this?

The command above takes care of it.

cu
Adrian

Bug#1001246: libcaf-doc: package libcaf-doc has the same short description as libcaf-dev

2021-12-06 Thread Daniele Forsi

Package: libcaf-doc
Severity: minor
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the short description for libcaf-doc end with "development files2 buut it 
probably
should end with "docuemntation":

$ apt-cache search libcaf
[...]
libcaf-dev - Implementation of the Actor Model in C++, development files
libcaf-doc - Implementation of the Actor Model in C++, development files
[...]


thanks,
Daniele

Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

2021-12-06 Thread Chris Lamb

Hi Niels,

> I think it would something like this from the debhelper side:
>
>   https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>
> Would that work for you? :)

Indeed it would. Would strip-nondeterminism then simply Depend on the
version of debhelper this change gets released in? Or rather: should
we do something more involved than that?


Regards,

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

Bug#997513: dovecot: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

On Mon, Oct 25, 2021 at 08:54:45PM +0200, Christian Göttsche wrote:
> The source of these test failure is LTO: it built fine with GCC 10.3
> with LTO a month ago on buildd, GCC 11 without LTO works and Clang 13
> with LTO also works.
> So either there is some subtle undefined behaviour in dovecot (which
> gets miscompiled) or the code generation in GCC 11 is buggy (maybe
> related [1]).
> 
> For the mean time the simplest solution is probably to disable LTO
>...

Could you do this as temprorary workaround?

Thanks
Adrian

Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

2021-12-06 Thread Mike Hommey

On Mon, Dec 06, 2021 at 09:01:24PM +0100, Paul Gevers wrote:
> Source: firefox-esr
> Version: 78.14.0esr-1
> Severity: serious
> Tags: sid bookworm ftbfs
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 998679
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 60 days as having a Release Critical bug in testing
> [1]. Your package src:firefox-esr has been trying to migrate for 61 days
> [2]. Hence, I am filing this bug. You have an unresolved RC bug and the
> latest uploaded FTBFS on mipsel.

The RC bug is going to be fixed today with a new upstream. The FTBFS on
mipsel is not going to go away ever. The rust compiler needs more than 2GB
of memory to compile a specific crate in Firefox, and processes on
mipsel can only get 2GB memory. The only way around that would be to
cross-compile, which Debian doesn't do as of today.  We'll have to remove
firefox-esr on mipsel.

Mike

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

2021-12-06 Thread Mattia Rizzolo

On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:
> I have good experience with some of my upstreams where they supported me by
> adapting their build system to enable building without the bundled/vendored
> dependencies. Has this been tried? Would it be worth pursuing?

It has been, yes.

I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags).  Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.

I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#995416: netgen: autopkgtest regression on armhf: Fatal Python error: Bus error

Control: tags -1 ftbfs

On Thu, Sep 30, 2021 at 09:57:32PM +0200, Paul Gevers wrote:
> Source: netgen
> Version: 6.2.2006+really6.2.1905+dfsg-4
> X-Debbugs-CC: debian...@lists.debian.org
>...
> test_pickling.py Fatal Python error: Bus error
> 
> Current thread 0xf7af5730 (most recent call first):
>   File
> "/tmp/autopkgtest-lxc.aj0csnj9/downtmp/build.ieK/src/tests/pytest/test_pickling.py",
> line 31 in test_pickle_csg
>   File "/usr/lib/python3/dist-packages/_pytest/python.py", line 180 in
> pytest_pyfunc_call
>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
> _multicall
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in
> 
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
> _hookexec
>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
> __call__
>   File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1570 in
> runtest
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 153 in
> pytest_runtest_call
>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
> _multicall
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in
> 
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
> _hookexec
>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
> __call__
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 247 in
> 
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 294 in
> from_call
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 246 in
> call_runtest_hook
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 207 in
> call_and_report
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 117 in
> runtestprotocol
>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 100 in
> pytest_runtest_protocol
>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
> _multicall
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in
> 
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
> _hookexec
>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
> __call__
>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 321 in
> pytest_runtestloop
>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
> _multicall
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in
> 
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
> _hookexec
>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
> __call__
>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 296 in _main
>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 240 in
> wrap_session
>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 289 in
> pytest_cmdline_main
>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
> _multicall
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in
> 
>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
> _hookexec
>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
> __call__
>   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
> 157 in main
>   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
> 180 in console_main
>   File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 7 in
> 
>   File "/usr/lib/python3.9/runpy.py", line 87 in _run_code
>   File "/usr/lib/python3.9/runpy.py", line 197 in _run_module_as_main
> Bus error

This is also a FTBFS on 64bit hardware, see build2 at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/netgen.html

The package might be non-functional when running 32bit armhf code 
on 64bit hardware.

Usually these problems are alignment issues.

cu
Adrian

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

2021-12-06 Thread Dirk Eddelbuettel



Hi Mattia and Sebastian,

On 6 December 2021 at 22:44, Mattia Rizzolo wrote:
| Yes!  See https://wiki.debian.org/BuildProfileSpec for the
| documentation.
| 
| Unfortunately there have been a few troubles getting a formal and good
| specifical text that was "good enough" for the Debian Policy.

Ack, and understood.  Using 'Profiles' instead of 'Options' is clear.

I applied the patch, catching one typo (just two-chars switched in the
updated comments, nothing affecting functionality) and -3 is now in unstable.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

2021-12-06 Thread Mattia Rizzolo

Hi Dirk,

On Mon, Dec 06, 2021 at 03:15:22PM -0600, Dirk Eddelbuettel wrote:
> | Instead of doing that, this could also be solved with a build profile.
> | See https://wiki.debian.org/BuildProfileSpec and the attached patch. See
> | also gtk4 and libgtk-4-media-ffmpeg for an example.
> 
> I can apply the patch, that is easy enough.
> 
> The angle in debian/control in 'Build-Profiles: ' are on
> purpose? Odd syntaxt.  Anyway, will give it a whirl in a bit.

Yes!  See https://wiki.debian.org/BuildProfileSpec for the
documentation.

Unfortunately there have been a few troubles getting a formal and good
specifical text that was "good enough" for the Debian Policy.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#997104: closed by Fredrik Hallenberg ()

2021-12-06 Thread Fredrik Hallenberg

I made a mistake in the done-mail, the fix was actually done in version
0.13.2-7 which is available. What can I do to fix this?

On Mon, Dec 6, 2021 at 6:54 PM Adrian Bunk  wrote:

> Hi Fredrik,
>
> 0.13.2-8 is not in the archive, did something go wrong
> (e.g. uploading signed with an expired key)?
>
> cu
> Adrian
>

Bug#1001245: weechat: FTBS against Ruby 3.0

2021-12-06 Thread Lucas Kanashiro


Package: weechat
Version: 3.3-1
Severity: important
Tags: patch bookworm sid
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Dear maintainer,

The current version of weechat does not support Ruby 3.0, please apply 
the upstream patch below:


https://github.com/weechat/weechat/commit/fe9768f484304c28cf4e6d6eb980613b00ca6904 



It will fix the current FTBFS against ruby3.0.

TIA!

--
Lucas Kanashiro

Bug#1001159: libguestfs: debdiff for 1.44.2-1.1 NMU

2021-12-06 Thread Hilko Bengen

* Antonio Terceiro:

> Please follow attached a debdiff for the NMU I just uploaded as
> 1.44.2-1.1. This was the last item in the transition to add support for
> ruby3.0.

Thanks and sorry for not answering earlier. Feel free to push your
changes to the debian/master bracnch at
.

Cheers,
-Hilko

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

2021-12-06 Thread Dirk Eddelbuettel



Hi Sebastian,

On 6 December 2021 at 21:58, Sebastian Ramacher wrote:
| gsl needs another upload. It currently lists libgsl-prof as package that
| should be built, but it isn't. I've been told that in the past this has
| been worked around by manually changing the .dsc before uploading.

It has been a huge source of frustration to me too ...
 
| Instead of doing that, this could also be solved with a build profile.
| See https://wiki.debian.org/BuildProfileSpec and the attached patch. See
| also gtk4 and libgtk-4-media-ffmpeg for an example.

I can apply the patch, that is easy enough.

The angle in debian/control in 'Build-Profiles: ' are on
purpose? Odd syntaxt.  Anyway, will give it a whirl in a bit.

The builds seems to be progressing otherwise and the new SO number does its
job.  Thanks again for your help in getting here.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1001244: circuits: needs update for python3.10: 'Callable' from 'collections' is removed


Source: circuits
Version: 3.1.0+ds1-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

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


   passfail
python3-defaults   from testing3.9.8-1
circuits   from testing3.1.0+ds1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. 
https://docs.python.org/3.9/library/collections.html says:

"""
Deprecated since version 3.3, will be removed in version 3.10: Moved 
Collections Abstract Base Classes to the collections.abc module. For 
backwards compatibility, they continue to be visible in this module 
through Python 3.9.

"""
Time to move on.

Currently this regression is blocking the migration of python3-defaults 
to testing [1].


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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/c/circuits/17290349/log.gz

Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/circuits/__init__.py", line 22, 
in 

from .core import Event
  File "/usr/lib/python3/dist-packages/circuits/core/__init__.py", line 
12, in 

from .bridge import Bridge
  File "/usr/lib/python3/dist-packages/circuits/core/bridge.py", line 
23, in 

from .handlers import handler
  File "/usr/lib/python3/dist-packages/circuits/core/handlers.py", line 
10, in 

from collections import Callable
ImportError: cannot import name 'Callable' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)

autopkgtest [19:10:21]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001243: cloud-sptheme: autopkgtest needs update for new version of python3-defaults: python3.10: not found


Source: cloud-sptheme
Version: 1.10.1.post20200504175005-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

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


   passfail
python3-defaults   from testing3.9.8-1
cloud-sptheme  from testing1.10.1.post20200504175005-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems you test 
for all supported Python3 versions but you don't ensure they are 
actually all installed during autopkgtesting.


Currently this regression is blocking the migration of python3-defaults 
to testing [1]. Of course, python3-defaults shouldn't just break your 
autopkgtest (or even worse, your package), but it seems to me that the 
change in python3-defaults was intended and your package needs to update 
to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from python3-defaults should 
really add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cloud-sptheme/17290350/log.gz

=== python3.10 ===
/tmp/autopkgtest-lxc.gop2f388/downtmp/build.veH/src/debian/tests/unittests: 
8: python3.10: not found

autopkgtest [19:10:44]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001242: weex FTBFS: dh_testroot: error: You must run this as root (or use fakeroot).

Source: weex
Version: 2.8.4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=weex=2.8.4

...
# Add here commands to compile the package.
#/usr/bin/make prefix=`pwd`/debian/weex/usr
touch build-stamp
dh_testdir
dh_testroot
dh_testroot: error: You must run this as root (or use fakeroot).
make: *** [debian/rules:37: install] Error 25

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

2021-12-06 Thread Sebastian Ramacher

Hi Dirk

On 2021-12-02 16:52:25, Dirk Eddelbuettel wrote:
> On 2 December 2021 at 15:57, Dirk Eddelbuettel wrote:
> | Yep. It's in the queue by now. I sometimes forget if an experimental ->
> | unstable passage does or does not need an orig.tar.gz to go along or not but
> | the bots will tell me if so :)
> 
> And by now in unstable.
> 
> Thanks so much for looking after the transition.

gsl needs another upload. It currently lists libgsl-prof as package that
should be built, but it isn't. I've been told that in the past this has
been worked around by manually changing the .dsc before uploading.

Instead of doing that, this could also be solved with a build profile.
See https://wiki.debian.org/BuildProfileSpec and the attached patch. See
also gtk4 and libgtk-4-media-ffmpeg for an example.

Cheers
-- 
Sebastian Ramacher
diff --git a/debian/README.Debian b/debian/README.Debian
index c6658dc..3e8a802 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -25,7 +25,7 @@ i) download the gsl source (and the build dependencies if 
necessary):
 apt-get source libgsl0
 apt-get build-dep libgsl0
 ii) build a binary profiling package:
-DEB_BUILD_OPTIONS=buildprof dpkg-buildpackage -b -rfakeroot -us -uc
+DEB_BUILD_PROFILES=pkg.gsl.prof dpkg-buildpackage -b -rfakeroot -us -uc
 iii) install the resulting .deb
 dpkg -i ../libgsl0-prof_[version]_[arch].deb
 
diff --git a/debian/control b/debian/control
index adde0d0..4314854 100644
--- a/debian/control
+++ b/debian/control
@@ -131,6 +131,7 @@ Provides: libgsl0-prof
 Conflicts: libgsl0-prof
 Replaces: libgsl0-prof (<= 1.16+dfsg-4)
 Depends: libgsl27 (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: 
 Description: GNU Scientific Library (GSL) -- profiling symbols package
  The GNU Scientific Library (GSL) is a collection of routines for
  numerical analysis.  The routines are written from scratch by the GSL
diff --git a/debian/rules b/debian/rules
index 6380851..86be4e2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -70,10 +70,10 @@ endif
 LDFLAGS= $(shell dpkg-buildflags --get LDFLAGS)
 
 
-#setting DEB_BUILD_OPTIONS=buildprof means we build a package
+#setting DEB_BUILD_PORFILES=pkg.gsl.prof means we build a package
 #consisting of static libraries (renamed to libfoo_p.a) with
 #profiling information in.
-ifneq (,$(findstring buildprof,$(DEB_BUILD_OPTIONS)))
+ifneq (,$(findstring pkg.gsl.prof,$(DEB_BUILD_PROFILES)))
 CONFIGTARGET = configure-prof-stamp
 INSTALLTARGET = install-prof-stamp
 BINARYTARGET = binary-prof

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

2021-12-06 Thread Raphael Hertzog

Hi,

On Mon, 06 Dec 2021, Paul Wise wrote:
> In the news emails, please show the Message-ID header and make the
> value inside the angled brackets <> a link to the Debian lists
> msgid-search. For example [1] should link to [2].
> 
>    1. 
> https://tracker.debian.org/news/1284147/accepted-purple-discord-0920211124gitde899b3-1-source-into-unstable/
>    2. 
> https://lists.debian.org/msgid-search/e1mu1fi-0006i4...@fasolo.debian.org
> 
> This would be useful when doing an upload and then wanting a link to
> the mail about it for copying into blog posts or work reports etc.

Why do you want a lists.debian.org link when you already have a
tracker.debian.org link pointing to the same content?

Also there's no guaranty that all news are properly recorded in a Debian
mailing lists. I assume testing migration mails aren't for example.

And this would be a feature that is really specific to Debian too, while
the news feature is very generic and cleanly mixing both would require
again some abstraction to add a vendor-specific behaviour in a generic
part.

In short, I find the cost really high for a relatively small value added.

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

signature.asc
Description: PGP signature

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Felix Lechner

Hi,

On Mon, Dec 6, 2021 at 12:44 PM gregor herrmann  wrote:
>
> It's already in NEW (and the other requested package as well).

Thank you for your prompt assistance!

Lintian provides backports to stable (and some users run it in even
more adventurous ways). Is it acceptable for the Lintian maintainers
to upload backports of the new packages, or would the Perl team rather
handle them via bug reports?

I would prefer if the Perl team handled backports as well, but it
would be an extra burden. Please just let me know one way or the
other. Thanks!

Kind regards
Felix Lechner

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread gregor herrmann

On Mon, 06 Dec 2021 11:26:22 -0800, Felix Lechner wrote:

> On Mon, Dec 6, 2021 at 10:48 AM gregor herrmann  wrote:
> > I have no good idea how to handle it right now.
> Thank you for having a look!
> For Lintian, the functionality of Sub::StrictDecl is probably enough.

Alright, thanks.

Then I propose that we put perlimports on the backburner until
someone both has good ideas and the necessary time to
implement them.

> I requested it separately (and you already assumed ownership). [1]

It's already in NEW (and the other requested package as well).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Koko Taylor: Wang Dang Doodle


signature.asc
Description: Digital Signature

Bug#997348: magic: diff for NMU version 8.3.105+ds.1-1.1

Control: tags 997348 + patch
Control: tags 997348 + pending

Dear maintainer,

I've prepared an NMU for magic (versioned as 8.3.105+ds.1-1.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru magic-8.3.105+ds.1/debian/changelog magic-8.3.105+ds.1/debian/changelog
--- magic-8.3.105+ds.1/debian/changelog	2020-12-28 11:09:00.0 +0200
+++ magic-8.3.105+ds.1/debian/changelog	2021-12-06 22:32:27.0 +0200
@@ -1,3 +1,10 @@
+magic (8.3.105+ds.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with autoconf 2.71. (Closes: #997348)
+
+ -- Adrian Bunk   Mon, 06 Dec 2021 22:32:27 +0200
+
 magic (8.3.105+ds.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru magic-8.3.105+ds.1/debian/patches/autoconf2.71.patch magic-8.3.105+ds.1/debian/patches/autoconf2.71.patch
--- magic-8.3.105+ds.1/debian/patches/autoconf2.71.patch	1970-01-01 02:00:00.0 +0200
+++ magic-8.3.105+ds.1/debian/patches/autoconf2.71.patch	2021-12-06 22:32:27.0 +0200
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with autoconf 2.71
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/997348
+
+--- magic-8.3.105+ds.1.orig/scripts/configure.in
 magic-8.3.105+ds.1/scripts/configure.in
+@@ -4,7 +4,7 @@ dnl Use autoconf 2.52 or newer.
+ AC_INIT(magic,, magic-hack...@csl.cornell.edu)
+ AC_PREREQ(2.52)
+ AC_CONFIG_SRCDIR(rules.mak)
+-AC_CONFIG_AUX_DIR(.)
++AC_CONFIG_AUX_DIR(scripts)
+ 
+ AC_CANONICAL_SYSTEM
+ 
diff -Nru magic-8.3.105+ds.1/debian/patches/series magic-8.3.105+ds.1/debian/patches/series
--- magic-8.3.105+ds.1/debian/patches/series	2020-12-27 21:06:40.0 +0200
+++ magic-8.3.105+ds.1/debian/patches/series	2021-12-06 22:32:27.0 +0200
@@ -8,3 +8,4 @@
 0009-Tutorials-and-ps-files-installed-in-usr-share-doc-ma.patch
 0011-Add-bindings-to-scroll-with-shift-or-ctrl-pressed.patch
 0010-Keep_install_as_earlier_Debian_packages.patch
+autoconf2.71.patch

Bug#1001240: mate-control-center: upgrading mate-control-center fails if mate-system-tools still installed

2021-12-06 Thread J. Sequier

Package: mate-control-center
Version: 1.24.1-1
Severity: important
X-Debbugs-Cc: jerome.sequ...@ouvaton.org

Dear Maintainer,

for some reason, I still had an old mate-system-tools installed on my system.
Upgrading mate-control-center or mate-control-center-common tries to overwrite
files belonging to mate-system-tools causing an error and stalling upgrade.

removing mate-system-tools
# dpkg -r --force-depends mate-system-tools

allowed
# apt --fix-broken install
to complete upgrade.

Make mate-control-center remove mate-system-tools?
Finding a solution was not simple for me.

Versions of packages mate-control-center depends on:
iu  caja-common 1.24.0-1
it  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   3.38.0-2
ii  libaccountsservice0 0.6.55-3
ii  libc6   2.31-13+deb11u2
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libcanberra-gtk3-0  0.30-7
ii  libcanberra00.30-7
ii  libdbus-glib-1-20.110-6
ii  libdconf1   0.38.0-2
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgdk-pixbuf2.0-0  2.40.2-2
it  libglib2.0-02.66.8-1
ii  libglib2.0-bin  2.66.8-1
ii  libgtk-3-0  3.24.24-4
ii  libmarco-private2   1.24.1-3
ii  libmate-desktop-2-171.24.1-2
ii  libmate-slab0   1.24.1-1
ii  libmate-window-settings11.24.1-1
ii  libmatekbd4 1.24.1-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libpolkit-gobject-1-0   0.105-31
ii  libx11-62:1.7.2-1
ii  libxcursor1 1:1.2.0-2
ii  libxi6  2:1.7.10-1
ii  libxklavier16   5.4-4
ii  libxml2 2.9.10+dfsg-6.7
ii  libxss1 1:1.2.3-1
ii  marco-common1.24.1-3
ii  mate-control-center-common  1.24.1-1
ii  mate-desktop1.24.1-2
ii  mate-icon-theme 1.24.0-1
ii  mate-menus  1.24.1-1
ii  mate-settings-daemon1.24.1-1

mate-control-center recommends no packages.

Versions of packages mate-control-center suggests:
it  gconf2  3.2.6-7

Bug#1001239: python-lupa: FTBFS on mipsel during running the test

Source: python-lupa
Version: 1.10+dfsg-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: affects -1 python-fakeredis

Dear maintainer,

Your latest upload FTBFS on mipsel. This is delaying the Python3.10
transition.

==
FAIL: test_coroutine_while_status (lupa.tests.test.TestLuaCoroutines)
--
Traceback (most recent call last):
  File "/<>/lupa/tests/test.py", line 1510, in 
test_coroutine_while_status
self.assertEqual([0,1,0,1,0,1], result)
AssertionError: Lists differ: [0, 1, 0, 1, 0, 1] != [0, 1, 0, 1, 0, 0]

First differing element 5:
1
0

- [0, 1, 0, 1, 0, 1]
? ^

+ [0, 1, 0, 1, 0, 0]
? ^


--
Ran 264 tests in 7.487s

FAILED (failures=1)
Test failed: 
error: Test failed: 
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: 
python3.9 setup.py test 
dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned 
exit code 13
make: *** [debian/rules:14: binary-arch] Error 25

Bug#997304: gambc: diff for NMU version 4.9.3-1.2

Control: tags 997304 + patch
Control: tags 997304 + pending

Dear maintainer,

I've prepared an NMU for gambc (versioned as 4.9.3-1.2) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru gambc-4.9.3/debian/changelog gambc-4.9.3/debian/changelog
--- gambc-4.9.3/debian/changelog	2021-02-04 14:14:16.0 +0200
+++ gambc-4.9.3/debian/changelog	2021-12-06 22:16:55.0 +0200
@@ -1,3 +1,10 @@
+gambc (4.9.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Workaround FTBFS with autoconf 2.71. (Closes: #997304)
+
+ -- Adrian Bunk   Mon, 06 Dec 2021 22:16:55 +0200
+
 gambc (4.9.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gambc-4.9.3/debian/patches/autoconf2.71.patch gambc-4.9.3/debian/patches/autoconf2.71.patch
--- gambc-4.9.3/debian/patches/autoconf2.71.patch	1970-01-01 02:00:00.0 +0200
+++ gambc-4.9.3/debian/patches/autoconf2.71.patch	2021-12-06 22:16:55.0 +0200
@@ -0,0 +1,15 @@
+Description: Workaround FTBFS with autoconf 2.71
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/997304
+
+--- gambc-4.9.3.orig/configure.ac
 gambc-4.9.3/configure.ac
+@@ -127,7 +127,7 @@ C_PREPROC=$CPP
+ 
+ if test "$ENABLE_CPLUSPLUS" = yes; then
+ 
+-  AC_LANG(C++)
++  #AC_LANG(C++)
+   AC_PROG_CXX
+   AC_PROG_CXXCPP
+   C_COMPILER=$CXX
diff -Nru gambc-4.9.3/debian/patches/series gambc-4.9.3/debian/patches/series
--- gambc-4.9.3/debian/patches/series	2021-02-04 14:14:16.0 +0200
+++ gambc-4.9.3/debian/patches/series	2021-12-06 22:16:55.0 +0200
@@ -2,3 +2,4 @@
 itanium.patch
 reproducibility.patch
 s390x.patch
+autoconf2.71.patch

Bug#1001238: astropy breaks gwcs autopkgtest: module 'astropy.modeling.utils' has no attribute '_BoundingBox'


Source: astropy, gwcs
Control: found -1 astropy/5.0-1
Control: found -1 gwcs/0.16.1-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
astropyfrom testing5.0-1
gwcs   from testing0.16.1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of astropy to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gwcs/17333475/log.gz

=== FAILURES 
===
___ test_pixel_bounds[gwcs_2d_spatial_shift] 
___


wcsobj = forward_transform=Model: CompoundModel

Inputs: ('x0', 'x1')
Ou...ffset=1.)>

[1]: 
Parameters:
offset_0 offset_1
 
 1.0  2.0)>

@wcs_objs
def test_pixel_bounds(wcsobj):
assert wcsobj.pixel_bounds is None
>   wcsobj.bounding_box = ((-0.5, 2039.5), (-0.5, 1019.5))

/usr/lib/python3/dist-packages/gwcs/tests/test_api.py:314: _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = forward_transform=Model: CompoundModel

Inputs: ('x0', 'x1')
Ou...ffset=1.)>

[1]: 
Parameters:
offset_0 offset_1
 
 1.0  2.0)>
value = ((-0.5, 2039.5), (-0.5, 1019.5))

@bounding_box.setter
def bounding_box(self, value):
"""
Set the range of acceptable values for each input axis.
The order of the axes is 
`~gwcs.coordinate_frames.CoordinateFrame.axes_order`.
For two inputs and axes_order(0, 1) the bounding box is ((xlow, 
xhigh), (ylow, yhigh)).

Parameters
--
value : tuple or None
Tuple of tuples with ("low", high") values for the range.
"""
frames = self.available_frames
transform_0 = self.get_transform(frames[0], frames[1])
if value is None:
transform_0.bounding_box = value
else:
try:
# Make sure the dimensions of the new bbox are correct.

  mutils._BoundingBox.validate(transform_0, value)
E   AttributeError: module 'astropy.modeling.utils' has no 
attribute '_BoundingBox'


/usr/lib/python3/dist-packages/gwcs/wcs.py:1296: AttributeError
 test_ellipsis 
_


gwcs_3d_galactic_spectral = input_frame=detector, forward_transform=Model: CompoundModel

Inputs: ('x0', 'x1', 'x...   
   -44.0-29.0  0.1 -0.1 ...  180.0-39.0 
0.5 20.0)>


def test_ellipsis(gwcs_3d_galactic_spectral):
wcs = SlicedLowLevelWCS(gwcs_3d_galactic_spectral, Ellipsis)
assert wcs.pixel_n_dim == 3
assert wcs.world_n_dim == 3
assert wcs.array_shape == (30, 20, 10)
assert wcs.pixel_shape == (10, 20, 30)
assert wcs.world_axis_physical_types == ['pos.galactic.lat', 
'em.freq', 'pos.galactic.lon']

assert wcs.world_axis_units == ['deg', 'Hz', 'deg']
assert_equal(wcs.axis_correlation_matrix, [[True, False, 
True], [False, True, False], [True, False, True]])
assert wcs.world_axis_object_components == [('celestial', 
1, 'spherical.lat'),
('spectral', 0, 
'value'),
('celestial', 0, 
'spherical.lon')]
assert wcs.world_axis_object_classes['celestial'][0] is 
SkyCoord

assert wcs.world_axis_object_classes['celestial'][1] == ()
assert 
isinstance(wcs.world_axis_object_classes['celestial'][2]['frame'], Galactic)
assert wcs.world_axis_object_classes['celestial'][2]['unit'] == 
(u.deg, u.deg)

assert wcs.world_axis_object_classes['spectral'][0] is Quantity
assert wcs.world_axis_object_classes['spectral'][1] == ()
assert wcs.world_axis_object_classes['spectral'][2] == {'unit': 
'Hz'}
>   assert_allclose(wcs.pixel_to_world_values(29, 39, 44), (10, 
20, 25))


/usr/lib/python3/dist-packages/gwcs/tests/test_api_slicing.py:60: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Bug#1001236: libopencv-dnn4.5 lacks stable ABI

2021-12-06 Thread Steve Langasek

Control: reassign -1 src:opencv
Control: forcemerge 998140 -1

Sorry, I see that this has already been fixed in a subsequent Debian upload
and Ubuntu is just behind.


On Mon, Dec 06, 2021 at 12:13:57PM -0800, Steve Langasek wrote:
> Package:libopencv-dnn4.5
> Version: 4.5.4+dfsg-1
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy
> 
> libopencv-dnn is provided as a shared library in Debian, but it evidently
> does not have a stable ABI.
> 
> This shows up in the gyoto autopkgtests, which, miserably, don't exit
> non-zero on these errors:
> 
> $ ./debian/tests/gyoto-mk-video 
> WARNING: PatternDisk: not tested for repeat_phi_>1; check your results
> Traceback (most recent call last):
>   File "", line 2, in 
>   File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 823, in main
> mk_video(**args.__dict__)
>   File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 655, in 
> mk_video
> video=backend(output, fps, width, height)
>   File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 125, in 
> __init__
> import cv2
> ImportError: 
> /usr/lib/python3/dist-packages/cv2.cpython-39-x86_64-linux-gnu.so: undefined 
> symbol: _ZTIN2cv3dnn14dnn4_v202106085LayerE
> $
> 
> This symbol was present in opencv 4.5.3 but is not present in 4.5.4:
> 
> $ apt download libopencv-dnn4.5=4.5.3+dfsg-1ubuntu1
> Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libopencv-dnn4.5 
> amd64 4.5.3+dfsg-1ubuntu1 [972 kB]
> Fetched 972 kB in 3s (307 kB/s)   
> $ dpkg-deb -R libopencv-dnn4.5_4.5.3+dfsg-1ubuntu1_amd64.deb dnn-4.5.3
> $ objdump -T dnn-4.5.3/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5|grep 
> _ZTIN2cv3dnn14dnn4_v202106085LayerE
> 002fd448 gDO .data.rel.ro 0018  Base
> _ZTIN2cv3dnn14dnn4_v202106085LayerE
> $ apt download libopencv-dnn4.5
> Get:1 http://archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 
> libopencv-dnn4.5 amd64 4.5.4+dfsg-1ubuntu2 [1102 kB]
> Fetched 1102 kB in 2s (550 kB/s)
> $ dpkg-deb -R libopencv-dnn4.5_4.5.4+dfsg-1ubuntu2_amd64.deb dnn-4.5.4 
> $ objdump -T dnn-4.5.4/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5|grep 
> _ZTIN2cv3dnn14dnn4_v202106085LayerE
> $
> 
> opencv uses no symbols files to prevent ABI skew; and from the type name
> (dnn4_v20210608) it appears this is not a stable interface.  But it is
> exported, and it is used.
> 
> This is also not a one-off symbol change.
> 
> $ diff -u <(objdump -T 
> dnn-4.5.3/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5 | grep '\.text' | cut 
> -b50- |sort) <(objdump -T 
> dnn-4.5.4/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5 | grep '\.text' | cut 
> -b50- |sort) | grep -c ^- 
> 256
> $
> 
> Since upstream doesn't ship a stable ABI here, there are basically two
> choices:
> 
>  - change the binary package name and conflict with older versions of the
>library (libopencv-dnn4.5debian1 Conflicts: libopencv-dnn4.5)
>  - ship this as a static library only.
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1000974: [PATCH xfsprogs-5.14.2 URGENT] libxfs: hide the drainbamaged fallthrough macro from xfslibs

2021-12-06 Thread Kees Cook

On Sun, Dec 05, 2021 at 09:49:51AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong 
> 
> Back in mid-2021, Kees and Gustavo rammed into the kernel a bunch of
> static checker "improvements" that redefined '/* fallthrough */'
> comments for switch statements as a macro that virtualizes either that
> same comment, a do-while loop, or a compiler __attribute__.  This was
> necessary to work around the poor decision-making of the clang, gcc, and
> C language standard authors, who collectively came up with four mutually
> incompatible ways to document a lack of branching in a code flow.
> 
> Having received ZERO HELP porting this to userspace, Eric and I

Look, I know you don't like this feature, but claiming that you received
no help with it is just false. I explicitly offered to help with xfsprogs,
and even sent a first-attempt at a patch to do so[1], which looks very
similar to what you've got here, almost 6 months later. I even went
through and changed all the comments to an explicitly XFS-specific
macro when you made it clear you hated the statement-like "fallthrough"
macro name.

I continue to be baffled about this whole saga. We're all trying to help
make Linux better, and I went out of my way to help with xfsprogs too to
minimize the impact on you (since you said you wanted to have nothing to
do with it), yet Gustavo and I got continually flamed by yourself and
Dave, including even now in this very misleading commit log.

What is going on here?

-Kees

[1] https://lore.kernel.org/lkml/202105280915.9117D7C@keescook/

-- 
Kees Cook

Bug#1001236: libopencv-dnn4.5 lacks stable ABI

2021-12-06 Thread Steve Langasek

Package:libopencv-dnn4.5
Version: 4.5.4+dfsg-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

libopencv-dnn is provided as a shared library in Debian, but it evidently
does not have a stable ABI.

This shows up in the gyoto autopkgtests, which, miserably, don't exit
non-zero on these errors:

$ ./debian/tests/gyoto-mk-video 
WARNING: PatternDisk: not tested for repeat_phi_>1; check your results
Traceback (most recent call last):
  File "", line 2, in 
  File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 823, in main
mk_video(**args.__dict__)
  File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 655, in mk_video
video=backend(output, fps, width, height)
  File "/usr/lib/python3/dist-packages/gyoto/animate.py", line 125, in __init__
import cv2
ImportError: /usr/lib/python3/dist-packages/cv2.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: _ZTIN2cv3dnn14dnn4_v202106085LayerE
$

This symbol was present in opencv 4.5.3 but is not present in 4.5.4:

$ apt download libopencv-dnn4.5=4.5.3+dfsg-1ubuntu1
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libopencv-dnn4.5 
amd64 4.5.3+dfsg-1ubuntu1 [972 kB]
Fetched 972 kB in 3s (307 kB/s)   
$ dpkg-deb -R libopencv-dnn4.5_4.5.3+dfsg-1ubuntu1_amd64.deb dnn-4.5.3
$ objdump -T dnn-4.5.3/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5|grep 
_ZTIN2cv3dnn14dnn4_v202106085LayerE
002fd448 gDO .data.rel.ro   0018  Base
_ZTIN2cv3dnn14dnn4_v202106085LayerE
$ apt download libopencv-dnn4.5
Get:1 http://archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 
libopencv-dnn4.5 amd64 4.5.4+dfsg-1ubuntu2 [1102 kB]
Fetched 1102 kB in 2s (550 kB/s)
$ dpkg-deb -R libopencv-dnn4.5_4.5.4+dfsg-1ubuntu2_amd64.deb dnn-4.5.4 
$ objdump -T dnn-4.5.4/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5|grep 
_ZTIN2cv3dnn14dnn4_v202106085LayerE
$

opencv uses no symbols files to prevent ABI skew; and from the type name
(dnn4_v20210608) it appears this is not a stable interface.  But it is
exported, and it is used.

This is also not a one-off symbol change.

$ diff -u <(objdump -T dnn-4.5.3/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5 
| grep '\.text' | cut -b50- |sort) <(objdump -T 
dnn-4.5.4/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.5 | grep '\.text' | cut 
-b50- |sort) | grep -c ^- 
256
$

Since upstream doesn't ship a stable ABI here, there are basically two
choices:

 - change the binary package name and conflict with older versions of the
   library (libopencv-dnn4.5debian1 Conflicts: libopencv-dnn4.5)
 - ship this as a static library only.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1001237: ptl: autopkgtest regression on armhf: Floating point exception


Source: ptl
Version: 2.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
ptlfrom testing2.3.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Maybe the test 
gets a bit confused by the fact that this host has 160 cores?


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/p/ptl/17288801/log.gz

/usr/include/c++/11/bits/stl_algobase.h:527:5: note: parameter passing 
for argument of type ‘__gnu_cxx::__normal_iteratorstd::vector >’ changed in GCC 7.1

In file included from /usr/include/c++/11/bits/stl_algobase.h:67,
 from /usr/include/c++/11/algorithm:61,
 from /usr/include/PTL/Globals.hh:30,
 from /usr/include/PTL/Task.hh:33,
 from 
/tmp/autopkgtest-lxc.48w05yr2/downtmp/autopkgtest_tmp/common/utils.hh:25,
 from 
/tmp/autopkgtest-lxc.48w05yr2/downtmp/autopkgtest_tmp/basic/recursive_tasking.cc:26:
/usr/include/c++/11/bits/stl_iterator.h: In function ‘_Iterator 
std::__niter_base(__gnu_cxx::__normal_iterator<_Iterator, _Container>) 
[with _Iterator = const long long int*; _Container = std::vectorlong int>]’:
/usr/include/c++/11/bits/stl_iterator.h:1257:5: note: parameter passing 
for argument of type ‘__gnu_cxx::__normal_iteratorstd::vector >’ changed in GCC 7.1
 1257 | __niter_base(__gnu_cxx::__normal_iterator<_Iterator, 
_Container> __it)

  | ^~~~
[100%] Linking CXX executable recursive_tbb_tasking
[100%] Built target recursive_tbb_tasking


  ##
  !!! Backtrace is activated !!!
  ##

[ptl-minimal]> Number of threads: 160
[PTL::ThreadPool] Starting thread 1...
bash: line 1:  2328 Floating point 
exception/tmp/autopkgtest-lxc.48w05yr2/downtmp/build.SOP/src/debian/tests/examples 
2> >(tee -a /tmp/autopkgtest-lxc.48w05yr2/downtmp/examples-stderr >&2) > 
>(tee -a /tmp/autopkgtest-lxc.48w05yr2/downtmp/examples-stdout)

autopkgtest [16:13:41]: test examples



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001235: aiosignal: Source-only upload needed

2021-12-06 Thread Boyuan Yang

X-Debbugs-CC: pi...@debian.org
Control: tags 1001235 + patch
Control: tags 1001235 + pending

The patch for aiosignal/1.2.0-2 is as follows:

diff -Nru aiosignal-1.2.0/debian/changelog aiosignal-1.2.0/debian/changelog
--- aiosignal-1.2.0/debian/changelog2021-11-28 10:11:14.0 -0500
+++ aiosignal-1.2.0/debian/changelog2021-12-06 15:06:11.0 -0500
@@ -1,3 +1,11 @@
+aiosignal (1.2.0-2) unstable; urgency=high
+
+  * Team upload.
+  * Source-only upload to allow testing migration. (Closes: #1001235)
+  * debian/control: Use correct Vcs-* URLs.
+
+ -- Boyuan Yang   Mon, 06 Dec 2021 15:06:11 -0500
+
 aiosignal (1.2.0-1) unstable; urgency=low
 
   * Initial release
diff -Nru aiosignal-1.2.0/debian/control aiosignal-1.2.0/debian/control
--- aiosignal-1.2.0/debian/control  2021-11-28 10:11:14.0 -0500
+++ aiosignal-1.2.0/debian/control  2021-12-06 15:05:51.0 -0500
@@ -13,8 +13,8 @@
 #   python3-sphinxcontrib.spelling,
 Standards-Version: 4.6.0
 Homepage: https://github.com/aio-libs/aiosignal
-Vcs-Git: https://salsa.debian.org/python-team/modules/aiosignal.git
-Vcs-Browser: https://salsa.debian.org/python-team/modules/aiosignal
+Vcs-Git: https://salsa.debian.org/python-team/packages/aiosignal.git
+Vcs-Browser: https://salsa.debian.org/python-team/packages/aiosignal
 
 Package: python3-aiosignal
 Architecture: all

-- 
Thanks,
Boyuan Yang


在 2021-12-06星期一的 15:04 -0500，Boyuan Yang写道：
> Source: aiosignal
> Version: 1.2.0-1
> Severity: important
> X-Debbugs-CC: pi...@debian.org
> 
> Hi,
> 
> To deal with the mess of python-aiohttp{-timeout}
> ( https://bugs.debian.org/1000680 ), I believe one important thing is to get
> aiosignal into Debian Testing soon. According to
> https://tracker.debian.org/pkg/aiosignal , we need a source-only upload to
> achieve this. I will later make a no-change source-only upload onto
> DELAYED/1
> for package aiosignal. Also please let me know if there are other things I
> can
> help to solve the issue.


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

Bug#1001235: aiosignal: Source-only upload needed

2021-12-06 Thread Boyuan Yang

Source: aiosignal
Version: 1.2.0-1
Severity: important
X-Debbugs-CC: pi...@debian.org

Hi,

To deal with the mess of python-aiohttp{-timeout}
( https://bugs.debian.org/1000680 ), I believe one important thing is to get
aiosignal into Debian Testing soon. According to
https://tracker.debian.org/pkg/aiosignal , we need a source-only upload to
achieve this. I will later make a no-change source-only upload onto DELAYED/1
for package aiosignal. Also please let me know if there are other things I can
help to solve the issue.

Thanks,
Boyuan Yang


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

Bug#997281: xawtv: diff for NMU version 3.107-1.1

Control: tags 997281 + pending

Dear maintainer,

I've prepared an NMU for xawtv (versioned as 3.107-1.1) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru xawtv-3.107/debian/changelog xawtv-3.107/debian/changelog
--- xawtv-3.107/debian/changelog	2020-07-05 19:42:23.0 +0300
+++ xawtv-3.107/debian/changelog	2021-12-06 21:59:01.0 +0200
@@ -1,3 +1,11 @@
+xawtv (3.107-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with glibc 2.32,
+thanks to Jeremy Sowden. (Closes: #997281)
+
+ -- Adrian Bunk   Mon, 06 Dec 2021 21:59:01 +0200
+
 xawtv (3.107-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru xawtv-3.107/debian/patches/0001-Replace-sys_siglist-with-strsignal.patch xawtv-3.107/debian/patches/0001-Replace-sys_siglist-with-strsignal.patch
--- xawtv-3.107/debian/patches/0001-Replace-sys_siglist-with-strsignal.patch	1970-01-01 02:00:00.0 +0200
+++ xawtv-3.107/debian/patches/0001-Replace-sys_siglist-with-strsignal.patch	2021-12-06 21:56:31.0 +0200
@@ -0,0 +1,64 @@
+From 4bf2b3966eecad32b47472065706560f31314a92 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab 
+Date: Tue, 17 Aug 2021 10:46:22 +0200
+Subject: [PATCH] Replace sys_siglist with strsignal
+
+This is needed in order to compile with newer glibc versions.
+
+Signed-off-by: Mauro Carvalho Chehab 
+---
+ console/fbtools.c | 2 +-
+ console/record.c  | 2 +-
+ x11/rootv.c   | 4 ++--
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/console/fbtools.c b/console/fbtools.c
+index 9f876df32dac..07739ff687ec 100644
+--- a/console/fbtools.c
 b/console/fbtools.c
+@@ -520,6 +520,6 @@ fb_catch_exit_signals(void)
+ 
+ /* cleanup */
+ fb_cleanup();
+-fprintf(stderr,"Oops: %s\n",sys_siglist[termsig]);
++fprintf(stderr,"Oops: %s\n",strsignal(termsig));
+ exit(42);
+ }
+diff --git a/console/record.c b/console/record.c
+index 685221b4b5ae..90f0c852bb08 100644
+--- a/console/record.c
 b/console/record.c
+@@ -429,7 +429,7 @@ ctrlc(int signal)
+ {
+ if (verbose)
+ 	fprintf(stderr,"\n%s - exiting\n",
+-		sys_siglist[signal]);
++		strsignal(signal));
+ stop = 1;
+ }
+ 
+diff --git a/x11/rootv.c b/x11/rootv.c
+index 60a840641e33..4bf458b227a0 100644
+--- a/x11/rootv.c
 b/x11/rootv.c
+@@ -133,7 +133,7 @@ catch_sig(int signal)
+ termsig = signal;
+ if (verbose)
+ 	fprintf(stderr,"received signal %d [%s]\n",
+-		termsig,sys_siglist[termsig]);
++		termsig,strsignal(termsig));
+ }
+ 
+ static void usage(FILE *fp)
+@@ -422,7 +422,7 @@ main(int argc, char *argv[])
+ }
+ if (verbose && termsig)
+ 	fprintf(stderr,"exiting on signal %d [%s]\n",
+-		termsig,sys_siglist[termsig]);
++		termsig,strsignal(termsig));
+ if (do_mute && have_mute)
+ 	XvSetPortAttribute(dpy,port,XV_MUTE,1);
+ XvStopVideo(dpy,port,win);
+-- 
+2.33.0
+
diff -Nru xawtv-3.107/debian/patches/series xawtv-3.107/debian/patches/series
--- xawtv-3.107/debian/patches/series	2020-07-05 19:42:23.0 +0300
+++ xawtv-3.107/debian/patches/series	2021-12-06 21:58:58.0 +0200
@@ -7,3 +7,4 @@
 0007-Makefile.in-fix-make-distclean.patch
 0008-Makefile.in-honour-CPPFLAGS.patch
 CVE-2020-13696-error_message_fix.patch
+0001-Replace-sys_siglist-with-strsignal.patch

Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug


Source: firefox-esr
Version: 78.14.0esr-1
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 998679

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:firefox-esr has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. You have an unresolved RC bug 
and the latest uploaded FTBFS on mipsel.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have tagged this bug to only affect sid and bookworm, so it doesn't 
affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=firefox-esr



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990541: cve was addressed upstream

Hi,

On Mon, Sep 20, 2021 at 05:01:35PM +0200, Bastian Germann wrote:
> fixed 990541 unrar-nonfree/1:6.0.4-1

Can you give more information here? Where was it fixed? 

Regards,
Salvatore

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)


Hi,

On 06-12-2021 20:43, Noah Meyerhans wrote:

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.


I have good experience with some of my upstreams where they supported me 
by adapting their build system to enable building without the 
bundled/vendored dependencies. Has this been tried? Would it be worth 
pursuing?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001233: src:golang-github-hashicorp-go-slug: fails to migrate to testing for too long: autopkgtest regression


Source: golang-github-hashicorp-go-slug
Version: 0.5.0-2
Severity: serious
Control: close -1 0.7.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 997847

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:golang-github-hashicorp-go-slug has been 
trying to migrate for 61 days [2]. Hence, I am filing this bug. I filed 
the bug about the autopkgtest regression more than a month ago.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] 
https://qa.debian.org/excuses.php?package=golang-github-hashicorp-go-slug




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997948: Reassign to fp-units-rtl

2021-12-06 Thread Abou Al Montacir

Control: reassign -1 fp-units-rtl


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

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

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

MariaDB 10.6.5 has been uploaded to Sid and will replace 10.5 as soon as it
has the initial bugs weeded out and is same or better overall quality as
10.5.

Bug#996596: dkms: Patch

2021-12-06 Thread Achim Schaefer

Package: dkms
Version: 2.8.7-2
Followup-For: Bug #996596
X-Debbugs-Cc: bts.debian@schaefer-home.eu

patch to fix:
--- dkms.bak2021-10-01 11:34:34.0 +0200
+++ dkms2021-12-06 20:40:15.879443636 +0100
@@ -13,8 +13,8 @@
 
 if [ -x /usr/sbin/dkms ]; then
 while read line; do
-   name=`echo "$line" | awk '{print $1}' | sed 's/,$//'` | cut -d'/' -f1
-   vers=`echo "$line" | awk '{print $1}' | sed 's/,$//'` | cut -d'/' -f2
+   name=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f1`
+   vers=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f2`
arch=`echo "$line" | awk '{print $3}' | sed 's/:$//'`
echo "dkms: removing: $name $vers ($inst_kern) ($arch)" >&2
dkms remove -m $name -v $vers -k $inst_kern -a $arch



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:en_US
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.9
ii  coreutils8.32-4.1
ii  dctrl-tools  2.24-3+b1
ii  dpkg-dev 1.21.0
ii  gcc [c-compiler] 4:11.2.0-2
ii  gcc-11 [c-compiler]  11.2.0-12
ii  kmod 29-1
ii  lsb-release  11.1.0
ii  make 4.3-4.1
ii  patch2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.26-1
ii  linux-headers-amd64 [linux-headers-generic]  5.15.5-1
ii  sudo 1.9.5p2-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.4-1
ii  menu   2.1.48

-- Configuration Files:
/etc/kernel/prerm.d/dkms changed:
inst_kern=$1
remove_initrd_backup() {
for initrd in "initrd-$1.img" "initramfs-$1.img" "initrd.img-$1" 
"initrd-$1"; do
rm -fv /boot/"${initrd}".old-dkms >&2
done
}
if [ -x /usr/sbin/dkms ]; then
while read line; do
   name=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f1`
   vers=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f2`
   arch=`echo "$line" | awk '{print $3}' | sed 's/:$//'`
   echo "dkms: removing: $name $vers ($inst_kern) ($arch)" >&2
   dkms remove -m $name -v $vers -k $inst_kern -a $arch
done < <(dkms status -k $inst_kern 2>/dev/null | grep ": installed")
fi
remove_initrd_backup "$inst_kern"
rmdir --ignore-fail-on-non-empty \
"/lib/modules/$inst_kern/updates/dkms" \
"/lib/modules/$inst_kern/updates" 2>/dev/null
exit 0


-- debconf-show failed

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

2021-12-06 Thread Noah Meyerhans

On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
> >> So what's happening with chromium in both sid and stable? I saw on 
> >> d-release that it was removed from testing (#998676 and #998732), with a  
> >> discussion about ending security support for it in stable.
> >
> > The problem really is lack of maintenance. In my opinion, chromium deserves 
> > an active *team* to support it in Debian.  <...>  The security team doesn't 
> > have the bandwidth to do it themselves, they need a team to help them.
> 
> Sorry for a silly question, but whatʼs so wrong with the build done by 
> linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
> (limited) experience.
> 

Well, you can start with the fact that the Mint chromium source packages
don't even include the chromium source, let alone the sources for all
the other things they build (NodeJS, and more).

The biggest difficulty, as far as I can tell from my look at Chromium
from several months ago, is that our patch set [1] needs a lot of
attention with every chromium release.  Mint doesn't apply any patches
at all to the source, at least none of any real complexity.

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.

noah

1. 
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
2. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
3. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system

Bug#1001232: RM: r-cran-rsgcc [s390x] -- RoQA; indirect Build Depends removed from s390x


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

Dear ftp master,

In bug #1001119 I asked you to remove rgtk2 on s390x, thanks for doing 
so. r-cran-rsgcc is an *indirect* reverse (build) dependency via 
r-cran-gwidgetsrgtk2, which is arch:all. r-cran-rsgcc can't be installed 
on s390x anymore and as it also Build Depends on r-cran-gwidgetsrgtk2, 
it can also not be build anymore.


Please remove r-cran-rsgcc from s390x.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001231: ITP: golang-github-muesli-gitcha -- Go helpers to work with git repositories

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-muesli-gitcha
  Version : 0.2.0-1
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/gitcha
* License : Expat
  Programming Lang: Go
  Description : Go helpers to work with git repositories

 The gitcha package provides Go helpers to work with git repositories.
 .
 Examples of things gitcha can do:
  * return the directory of the git repository path is a member of:
  * find files from list in path, respecting .gitignores it finds
  * find files, excluding any matches in a given set of ignore

Reason for packaging:
 Prerequisite for Glow (https://github.com/charmbracelet/grow)

Bug#998909: closed by Debian FTP Masters (reply to Shengjing Zhu ) (Bug#998909: fixed in containerd 1.4.12~ds1-1~deb11u1)

2021-12-06 Thread Jakob Meng


Awesome! Thank you, Shengjing ☺️



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Felix Lechner

Hi,

On Mon, Dec 6, 2021 at 10:48 AM gregor herrmann  wrote:
>
> I have no good idea how to handle it right now.

Thank you for having a look!

For Lintian, the functionality of Sub::StrictDecl is probably enough.
I requested it separately (and you already assumed ownership). [1]
Thank you!

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/1001175

Bug#995227: Xephem : An interactive astronomical ephemeris for X

2021-12-06 Thread Miguel A. Vallejo

I would love to have Xephem back to Debian.

Bug#997213: i2p: FTBFS: [javac] /<>/apps/jetty/java/src/net/i2p/jetty/I2PRequestLog.java:25: error: package javax.servlet.http does not exist

The problem is a missing build dependency on libservlet3.1-java
(this was previously hidden by libjetty9-java depending on 
libservlet3.1-java).

I haven't checked whether a runtime dependency on libservlet3.1-java is 
also missing.

cu
Adrian

Bug#1001230: ITP: libalgorithm-backoff-perl -- modules providing various backoff strategies for retry

2021-12-06 Thread gregor herrmann

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalgorithm-backoff-perl
  Version : 0.009
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Algorithm-Backoff
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules providing various backoff strategies for retry

This package provides several classes that implement various backoff
strategies for setting delay between retry attempts.

Included modules:

 Algorithm::Backoff::Constant - Backoff using a constant delay
 Algorithm::Backoff::Exponential - Backoff exponentially
 Algorithm::Backoff::Fibonacci - Backoff using Fibonacci sequence
 Algorithm::Backoff::LILD - Linear Increment, Linear Decrement (LILD) backoff
 Algorithm::Backoff::LIMD - Linear Increment, Multiplicative Decrement (LIMD) 
backoff
 Algorithm::Backoff::MILD - Multiplicative Increment, Linear Decrement (MILD) 
backoff
 Algorithm::Backoff::MIMD - Multiplicative Increment, Multiplicative Decrement 
(MIMD) backoff

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1001202: about default locales LANGUAGE: set to C or unset

2021-12-06 Thread Vagrant Cascadian

On 2021-12-06, xiao sheng wen(肖盛文) wrote:
>   I suggestion set default locales LANGUAGE to C  or unset LANGUAGE env.
> At present, it set to en_US:en, this will cause some problems in no en env.
>
> The C LANGUAGE would be the default locales when set it.
> If no vary, not set LANG and LANGUAGE is also ok.

My understanding was that LANGUAGE, unlike LANG and LC_* is not valid as
"C", though I'm having a difficult time finding references for what are
valid settings for LANGUAGE.


live well,
  vagrant
  
> diff -u build.py atzlinux.build.py
> --- build.py2021-12-06 18:07:33.653809577 +0800
> +++ atzlinux.build.py   2021-12-06 18:12:17.407143396 +0800
> @@ -365,7 +365,7 @@
>  # list question.
>  def locales(ctx, build, vary):
>  if not vary:
> -return build.add_env('LANG', 'C.UTF-8').add_env('LANGUAGE',
> 'en_US:en')
> +return build.add_env('LANG', 'C.UTF-8').add_env('LANGUAGE', 'C')
>  else:
>  # if there is an issue with this being random, we could instead 
> select
> it
>  # based on a deterministic hash of the inputs


signature.asc
Description: PGP signature

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Jonas Smedegaard

Quoting gregor herrmann (2021-12-06 19:48:39)
> I looked a bit further, and this is not as trivial as most CPAN 
> distributions:
> 
> - perlimports in the CPAN tarball is a fat-packed script:
>   https://metacpan.org/dist/App-perlimports/source/script/perlimports
>   i.e. it embeds a couple of Perl modules;
>   now we could just live it but that's neither elegant nor clever
>   seurity-wise nor simple copyright-wise;
> - we could try to rip out the fat-packed parts (which still leaves
>   the copyright question for the source package); [0] but:
> - the fat-packing works with an author script:
>   https://github.com/oalders/App-perlimports/tree/main/author
>   which already says that it uses a forked PPI module (cf. also
>   .gitmodules in the upstream git repo)
> 
> With cpanminus we have a similar situation, there we take the tarball
> from GitHub and not from CPAN, and create the actual script without
> fatpacking. (Before that we removed the fatpacked modules from the
> script.)
> 
> But this forked PPI seems like a blocker, at least I have no good
> idea how to handle it right now. [1]

If the forked PPI is specific for building this module, I would find it 
sensible to embed that fork with this source package - e.g. using the 
"component" feature of uscan.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread gregor herrmann

On Sun, 05 Dec 2021 12:16:30 -0800, Felix Lechner wrote:

> On Sun, Dec 5, 2021 at 12:08 PM gregor herrmann wrote:
> > (Just as a note, and that means I won't upload this tonight :))
> Thank you for looking into it!

You're welcome.

I looked a bit further, and this is not as trivial as most CPAN
distributions:

- perlimports in the CPAN tarball is a fat-packed script:
https://metacpan.org/dist/App-perlimports/source/script/perlimports
i.e. it embeds a couple of Perl modules;
now we could just live it but that's neither elegant nor clever
seurity-wise nor simple copyright-wise;
- we could try to rip out the fat-packed parts (which still leaves
the copyright question for the source package); [0] but:
- the fat-packing works with an author script:
https://github.com/oalders/App-perlimports/tree/main/author
which already says that it uses a forked PPI module (cf. also
.gitmodules in the upstream git repo)

With cpanminus we have a similar situation, there we take the tarball
from GitHub and not from CPAN, and create the actual script without
fatpacking. (Before that we removed the fatpacked modules from the
script.)

But this forked PPI seems like a blocker, at least I have no good
idea how to handle it right now. [1]

Cc'ing my friendly fellow perl team members …

Cheers,
gregor

[0] Cf. also
https://github.com/oalders/App-perlimports/commit/7de596d7a607693ca298027bc63127e2a565f597
[1] I won't mention Monkey::Patch here.

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Joe Cocker: Rivers Rising

signature.asc
Description: Digital Signature

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

2021-12-06 Thread Adam D. Barratt

On Sat, 2021-12-04 at 12:07 -0800, Otto Kekäläinen wrote:
> > On Fri, 2021-11-26 at 22:32 -0800, Otto Kekäläinen wrote:
> > > Final changelog:
> > > 
> > > mariadb-10.5 (1:10.5.13-0+deb11u1) bullseye; urgency=medium
> ..
> > Please go ahead.
> 
> Uploading now

Something I should have spotted before is that this gives us a similar
issue to that we had with 10.3 for buster last year - namely, that the
upload to p-u is newer than the version of 10.5 in unstable and
testing.

Is there a plan for either updating 10.5 in unstable, or removing it?
Alternatively, are the new bullseye packages likely to work "as-is" if
they were pushed into testing and unstable during the point release?

Regards,

Adam

Bug#1001229: python3-nbconvert: 500 error when opening a notebook

2021-12-06 Thread Günter Frenz

Package: python3-nbconvert
Version: 6.1.0-1
Severity: normal

Dear Maintainer,

today I wanted to work again with my jupyter notebooks but when I try to open a 
notebook in the browser, I get a 500 internal server error and the log in the 
console where I started jupyter-notebook shows the following messages:

[guefz@corinnis:~/data/mineral] $ jupyter-notebook --no-browser --notebook-dir 
python-test/
[I 18:00:53.844 NotebookApp] Serving notebooks from local directory: 
/home/guefz/data/mineral/python-test
[I 18:00:53.844 NotebookApp] Jupyter Notebook 6.4.5 is running at:
[I 18:00:53.844 NotebookApp] 
http://localhost:/?token=01856103749006da3a0beaa7d83256462324e12ef589fa11
[I 18:00:53.844 NotebookApp]  or 
http://127.0.0.1:/?token=01856103749006da3a0beaa7d83256462324e12ef589fa11
[I 18:00:53.844 NotebookApp] Use Control-C to stop this server and shut down 
all kernels (twice to skip confirmation).
[C 18:00:53.847 NotebookApp]

To access the notebook, open this file in a browser:
file:///home/guefz/.local/share/jupyter/runtime/nbserver-48274-open.html
Or copy and paste one of these URLs:

http://localhost:/?token=01856103749006da3a0beaa7d83256462324e12ef589fa11
 or 
http://127.0.0.1:/?token=01856103749006da3a0beaa7d83256462324e12ef589fa11
[I 18:01:14.453 NotebookApp] 302 GET 
/?token=01856103749006da3a0beaa7d83256462324e12ef589fa11 (127.0.0.1) 0.71ms
[E 18:01:17.588 NotebookApp] Uncaught exception GET 
/notebooks/test-pyqtgraph2.ipynb (127.0.0.1)
HTTPServerRequest(protocol='http', host='localhost:', method='GET', 
uri='/notebooks/test-pyqtgraph2.ipynb', version='HTTP/1.1', 
remote_ip='127.0.0.1')
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/tornado/web.py", line 1704, in 
_execute
result = await result
  File "/usr/lib/python3/dist-packages/tornado/gen.py", line 775, in run
yielded = self.gen.send(value)
  File "/usr/lib/python3/dist-packages/notebook/notebook/handlers.py", line 
95, in get
self.write(self.render_template('notebook.html',
  File "/usr/lib/python3/dist-packages/notebook/base/handlers.py", line 
516, in render_template
return template.render(**ns)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1304, 
in render
self.environment.handle_exception()
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 925, in 
handle_exception
raise rewrite_traceback_stack(source=source)
  File "/usr/lib/python3/dist-packages/notebook/templates/notebook.html", 
line 1, in top-level template code
{% extends "page.html" %}
  File "/usr/lib/python3/dist-packages/notebook/templates/page.html", line 
153, in top-level template code
{% block header %}
  File "/usr/lib/python3/dist-packages/notebook/templates/notebook.html", 
line 115, in block 'header'
{% for exporter in get_frontend_exporters() %}
  File "/usr/lib/python3/dist-packages/notebook/notebook/handlers.py", line 
23, in get_frontend_exporters
from nbconvert.exporters.base import get_export_names, get_exporter
  File "/usr/lib/python3/dist-packages/nbconvert/__init__.py", line 4, in 

from .exporters import *
  File "/usr/lib/python3/dist-packages/nbconvert/exporters/__init__.py", 
line 3, in 
from .html import HTMLExporter
  File "/usr/lib/python3/dist-packages/nbconvert/exporters/html.py", line 
14, in 
from nbconvert.filters.highlight import Highlight2HTML
  File "/usr/lib/python3/dist-packages/nbconvert/filters/__init__.py", line 
6, in 
from .markdown import *
  File "/usr/lib/python3/dist-packages/nbconvert/filters/markdown.py", line 
13, in 
from .markdown_mistune import markdown2html_mistune
  File 
"/usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py", line 
31, in 
class MathBlockGrammar(mistune.BlockGrammar):
AttributeError: module 'mistune' has no attribute 'BlockGrammar'
[E 18:01:17.594 NotebookApp] {
  "Host": "localhost:",
  "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 
Firefox/91.0",
  "Accept": 
"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
  "Accept-Language": "de,en-US;q=0.7,en;q=0.3",
  "Accept-Encoding": "gzip, deflate",
  "Referer": "http://localhost:/tree;,
  "Dnt": "1",
  "Connection": "keep-alive",
  "Cookie": 
"username-localhost-=\"2|1:0|10:1638810074|23:username-localhost-|44:MzcyMTZhNWZlMDk0NGI0ZjhmZjg3ZmIyODQ3YTYxY2I=|7d1e98fc5a0ea3e90e787261d33c200d2e096fc98e98a9185e6380c563b6d276\";
 _xsrf=2|a5a9d73d|b4645908e0d526989c0ee2051ac0574f|1638810074",
  "Upgrade-Insecure-Requests": "1",
  "Sec-Fetch-Dest": "document",
  "Sec-Fetch-Mode": "navigate",
  "Sec-Fetch-Site": "same-origin",
  "Sec-Fetch-User": "?1"
}
[E 18:01:17.594 NotebookApp] 500 GET

Bug#1001228: ITP: jupyter-kernel-test -- tool to test Jupyter kernels

2021-12-06 Thread Joseph Nahmias

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
j...@nahmias.net

* Package name: jupyter-kernel-test
  Version : 0.4.2
  Upstream Author : Jupyter Development Team 
* URL : https://github.com/jupyter/jupyter_kernel_test
* License : BSD
  Programming Lang: Python
  Description : tool to test Jupyter kernels

jupyter_kernel_test is a tool for testing Jupyter kernels. It tests kernels
for successful code execution and conformance with the Jupyter Messaging
Protocol (currently 5.0).

Bug#997104: closed by Fredrik Hallenberg ()

Hi Fredrik,

0.13.2-8 is not in the archive, did something go wrong
(e.g. uploading signed with an expired key)?

cu
Adrian

Bug#1001227: locust: please make the build reproducible

2021-12-06 Thread Chris Lamb

Source: locust
Version: 1.4.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
locust could not be built reproducibly.

This is because it ships .pyc files in the examples/ directory. You
almost certainly don't want to do this anyway, so a patch is attached
that does not ship these.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-12-06 09:41:15.485749635 -0800
--- b/debian/rules  2021-12-06 09:45:24.193655462 -0800
@@ -19,3 +19,6 @@
 
 override_dh_auto_test:
-PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH={build_dir} 
{interpreter} -m pytest -v" dh_auto_test
+
+override_dh_installexamples:
+   dh_installexamples -X.pyc

Bug#997863: thunderbird-l10n-de: German version not taken into account

2021-12-06 Thread Sven Geuer

Dear Maintainer,

I observed the same issue as Pascal after today's upgrade of my
bookworm system from thunderbird version 1:78.14.0-1 to 1:91.3.2-1.
Thunderbird now ignores the installed thunderbird-l10n-de package.

Before this upgrade localisation worked flawlessly for me.

I suspect this bug not only applies to French and German but to
localisations in general.

Cheers,
Sven

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


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

Bug#1001185: flatpak: xdg-desktop-portal-gnome is not recommended

2021-12-06 Thread Sophie Herold

I understand. So I probably have reported against the wrong package 
here.


I'm using GNOME and had to manually install the -gnome package after 
the separation with -gtk happened. I know too little about decencies to 
say if this was avoidable and which package mabye should dep/rec the 
-gnome package.


Best,
Sophie

Bug#1001226: ITP: golang-github-segmentio-ksuid -- K-Sortable Globally Unique IDs

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-segmentio-ksuid
  Version : 1.0.4-1
  Upstream Author : Segment (https://segment.com/)
* URL : https://github.com/segmentio/ksuid
* License : Expat
  Programming Lang: Go
  Description : K-Sortable Globally Unique IDs

 ksuid is an efficient, comprehensive, battle-tested Go library for
 generating and parsing a specific kind of globally unique identifier
 called a *KSUID*. This library serves as its reference implementation.
 .
 What is a KSUID?
 .
 KSUID is for K-Sortable Unique IDentifier. It is a kind of globally
 unique identifier similar to a RFC 4122 UUID
 (https://en.wikipedia.org/wiki/Universally_unique_identifier), built
 from the ground-up to be "naturally" sorted by generation timestamp
 without any special type-aware logic.
 .
 In short, running a set of KSUIDs through the UNIX sort command will
 result in a list ordered by generation time.
 .
 Why use KSUIDs?
 .
 There are numerous methods for generating unique identifiers, so why
 KSUID?
 .
  1. Naturally ordered by generation time
  2. Collision-free, coordination-free, dependency-free
  3. Highly portable representations
 .
 Even if only one of these properties are important to you, KSUID is a
 great choice! :) Many projects chose to use KSUIDs *just* because the
 text representation is copy-and-paste friendly.
 .
 1. Naturally Ordered By Generation Time
 .
 Unlike the more ubiquitous UUIDv4, a KSUID contains a timestamp
 component that allows them to be loosely sorted by generation time. This
 is not a strong guarantee (an invariant) as it depends on wall clocks,
 but is still incredibly useful in practice. Both the binary and text
 representations will sort by creation time without any special sorting
 logic.
 .
 2. Collision-free, Coordination-free, Dependency-free
 .
 While RFC 4122 UUIDv1s *do* include a time component, there aren't
 enough bytes of randomness to provide strong protection against
 collisions (duplicates). With such a low amount of entropy, it is
 feasible for a malicious party to guess generated IDs, creating a
 problem for systems whose security is, implicitly or explicitly,
 sensitive to an adversary guessing identifiers.
 .
 To fit into a 64-bit number space, Snowflake IDs
 (https://blog.twitter.com/2010/announcing-snowflake) and its derivatives
 require coordination to avoid collisions, which significantly increases
 the deployment complexity and operational burden.
 .
 A KSUID includes 128 bits of pseudorandom data ("entropy"). This number
 space is 64 times larger than the 122 bits used by the well-accepted RFC
 4122 UUIDv4 standard. The additional timestamp component can be
 considered "bonus entropy" which further decreases the probability of
 collisions, to the point of physical infeasibility in any practical
 implementation.
 .
 3. Highly Portable Representations
 .
 The text *and* binary representations are lexicographically sortable,
 which allows them to be dropped into systems which do not natively
 support KSUIDs and retain their time-ordered property.
 .
 The text representation is an alphanumeric base62 encoding, so it "fits"
 anywhere alphanumeric strings are accepted. No delimiters are used, so
 stringified KSUIDs won't be inadvertently truncated or tokenized when
 interpreted by software that is designed for human-readable text, a
 common problem for the text representation of RFC 4122 UUIDs.
 .
 How do KSUIDs work?
 .
 Binary KSUIDs are 20-bytes: a 32-bit unsigned integer UTC timestamp and a
 128-bit randomly generated payload. The timestamp uses big-endian
 encoding, to support lexicographic sorting. The timestamp epoch is
 adjusted to May 13th, 2014, providing over 100 years of life. The
 payload is generated by a cryptographically-strong pseudorandom number
 generator.
 .
 The text representation is always 27 characters, encoded in alphanumeric
 base62 that will lexicographically sort by timestamp.
 .
 High Performance
 .
 This library is designed to be used in code paths that are performance
 critical. Its code has been tuned to eliminate all non-essential
 overhead. The KSUID type is derived from a fixed-size array, which
 eliminates the additional reference chasing and allocation involved in a
 variable-width type.
 .
 The API provides an interface for use in code paths which are sensitive
 to allocation. For example, the Append method can be used to parse the
 text representation and replace the contents of a KSUID value without
 additional heap allocation.
 .
 All public package level "pure" functions are concurrency-safe, protected
 by a global mutex. For hot loops that generate a large amount of KSUIDs
 from a single Goroutine, the Sequence type is provided to elide the
 potential contention.
 .
 By default, out of an abundance of caution, the cryptographically-secure
 PRNG is used to generate the random bits of a KSUID. This can be relaxed
 in extremely

Bug#1001225: tmate-ssh-server: CVE-2021-44512 CVE-2021-44513