Bug#1026969: ruby-aruba - build-dependencies unsatisfiable in bookworm/sid

[Peter Michael Green]

Package: ruby-aruba
Version: 2.1.0-1
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable

ruby-aruba build-depends on rubocop (<< 1.0) but bookworm and sid have version 
1.39.0+dfsg-1

Bug#1026968: gcc-12: fix support for loong64

[Han Gao]

Source: gcc-12
Version: 12.2.0-10
Severity: wishlist

Dear Maintainer,

  In #1023785, the patch is now no longer suitable

  1.It should be modified as follow.

--- a/src/gcc/config/loongarch/t-linux
+++ b/src/gcc/config/loongarch/t-linux
@@ -32,22 +32,19 @@ ifneq ($(call if_multiarch,yes),yes)
 else
 # Only define MULTIARCH_DIRNAME when multiarch is enabled,
 # or it would always introduce ${target} into the search path.
-MULTIARCH_DIRNAME = $(LA_MULTIARCH_TRIPLET)
+MULTIARCH_DIRNAME = $(call if_multiarch,loongarch64-linux-gnuf64)
 endif

 # Don't define MULTILIB_OSDIRNAMES if multilib is disabled.
 ifeq ($(filter LA_DISABLE_MULTILIB,$(tm_defines)),)

 MULTILIB_OSDIRNAMES = \
-  mabi.lp64d=../lib64$\
-  $(call if_multiarch,:loongarch64-linux-gnuf64)
+  mabi.lp64d=../lib$(call if_multiarch,:loongarch64-linux-gnuf64)

 MULTILIB_OSDIRNAMES += \
-  mabi.lp64f=../lib64/f32$\
-  $(call if_multiarch,:loongarch64-linux-gnuf32)
+  mabi.lp64f=../lib$(call if_multiarch,:loongarch64-linux-gnuf32)

 MULTILIB_OSDIRNAMES += \
-  mabi.lp64s=../lib64/sf$\
-  $(call if_multiarch,:loongarch64-linux-gnusf)
+  mabi.lp64s=../lib$(call if_multiarch,:loongarch64-linux-gnusf)
 endif


2. gcc didn't enable with_pie, It should add loong64

https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.defs#L1434-L1438

Bug#1026967: llvm: broken-symlink /usr/share/man/man1/llvm-reduce.1.gz -> llvm-reduce-14.1.gz

[Paul Wise]

Package: llvm
Version: 1:14.0-55.3
Severity: normal
File: /usr/share/man/man1/llvm-reduce.1.gz
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

llvm-defaults 0.55.3 introduced a broken symlink:

   /usr/share/man/man1/llvm-reduce.1.gz -> llvm-reduce-14.1.gz

It looks like what happened is that the llvm-defaults symlink machinery
expects every LLVM binary to have a manual page, but the llvm-reduce
binary doesn't have a manual page.

Here is some more information about the broken symlink:

   Log started: 2022-12-25  12:23:00
   apt-listchanges: Reading changelogs...
   apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
   apt-listchanges: Reading changelogs...
   Preparing to unpack .../0-clangd_1%3a14.0-55.3_amd64.deb ...
   Unpacking clangd:amd64 (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../1-clang-tools_1%3a14.0-55.3_amd64.deb ...
   Unpacking clang-tools:amd64 (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../2-clang-format_1%3a14.0-55.3_amd64.deb ...
   Unpacking clang-format:amd64 (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../3-clang-tidy_1%3a14.0-55.3_amd64.deb ...
   Unpacking clang-tidy (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../4-clang_1%3a14.0-55.3_amd64.deb ...
   Unpacking clang (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../5-llvm-dev_1%3a14.0-55.3_amd64.deb ...
   Unpacking llvm-dev (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../6-llvm_1%3a14.0-55.3_amd64.deb ...
   Unpacking llvm (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Preparing to unpack .../7-llvm-runtime_1%3a14.0-55.3_amd64.deb ...
   Unpacking llvm-runtime:amd64 (1:14.0-55.3) over (1:14.0-55.2+b1) ...
   Setting up clang-format:amd64 (1:14.0-55.3) ...
   Setting up clang-tidy (1:14.0-55.3) ...
   Setting up clangd:amd64 (1:14.0-55.3) ...
   Setting up clang (1:14.0-55.3) ...
   Setting up llvm-runtime:amd64 (1:14.0-55.3) ...
   Setting up llvm (1:14.0-55.3) ...
   Setting up clang-tools:amd64 (1:14.0-55.3) ...
   Setting up llvm-dev (1:14.0-55.3) ...
   Processing triggers for man-db (2.11.1-1) ...
   Log ended: 2022-12-25  12:24:01
   
   $ adequate llvm
   llvm: broken-symlink /usr/share/man/man1/llvm-reduce.1.gz -> 
llvm-reduce-14.1.gz
   
   $ readlink /usr/share/man/man1/llvm-reduce.1.gz
   llvm-reduce-14.1.gz
   
   $ ls -l /usr/share/man/man1/llvm-reduce.1.gz
   lrwxrwxrwx 1 root root 19 Dec 12 21:34 /usr/share/man/man1/llvm-reduce.1.gz 
-> llvm-reduce-14.1.gz
   
   $ chase /usr/share/man/man1/llvm-reduce.1.gz
   chase: /usr/share/man/man1/llvm-reduce-14.1.gz: No such file or directory
   
   $ ls -l /usr/share/man/man1/llvm-reduce-14.1.gz
   ls: cannot access '/usr/share/man/man1/llvm-reduce-14.1.gz': No such file or 
directory
   
   $ apt-file search llvm-reduce-14.1.gz
   
   $ apt-file search llvm-reduce-14
   llvm-14: /usr/bin/llvm-reduce-14
   
   $ apt-file search llvm-reduce
   llvm: /usr/bin/llvm-reduce
   llvm: /usr/share/man/man1/llvm-reduce.1.gz
   llvm-13: /usr/bin/llvm-reduce-13
   llvm-13: /usr/lib/llvm-13/bin/llvm-reduce
   llvm-14: /usr/bin/llvm-reduce-14
   llvm-14: /usr/lib/llvm-14/bin/llvm-reduce
   llvm-15: /usr/bin/llvm-reduce-15
   llvm-15: /usr/lib/llvm-15/bin/llvm-reduce
   llvm-16: /usr/bin/llvm-reduce-16
   llvm-16: /usr/lib/llvm-16/bin/llvm-reduce
   
   $ find /usr/share/man/man1/llvm-* -type l -print0 | xargs -0 chase
   /usr/share/man/man1/llvm-addr2line-14.1.gz
   /usr/share/man/man1/llvm-ar-14.1.gz
   /usr/share/man/man1/llvm-as-14.1.gz
   /usr/share/man/man1/llvm-bcanalyzer-14.1.gz
   /usr/share/man/man1/llvm-config-14.1.gz
   /usr/share/man/man1/llvm-cov-14.1.gz
   /usr/share/man/man1/llvm-cxxfilt-14.1.gz
   /usr/share/man/man1/llvm-diff-14.1.gz
   /usr/share/man/man1/llvm-dis-14.1.gz
   /usr/share/man/man1/llvm-dwarfdump-14.1.gz
   /usr/share/man/man1/llvm-exegesis-14.1.gz
   /usr/share/man/man1/llvm-extract-14.1.gz
   /usr/share/man/man1/llvm-lib-14.1.gz
   /usr/share/man/man1/llvm-link-14.1.gz
   /usr/share/man/man1/llvm-mc-14.1.gz
   /usr/share/man/man1/llvm-mca-14.1.gz
   /usr/share/man/man1/llvm-nm-14.1.gz
   /usr/share/man/man1/llvm-objcopy-14.1.gz
   /usr/share/man/man1/llvm-objdump-14.1.gz
   /usr/share/man/man1/llvm-pdbutil-14.1.gz
   /usr/share/man/man1/llvm-profdata-14.1.gz
   /usr/share/man/man1/llvm-ranlib-14.1.gz
   /usr/share/man/man1/llvm-readelf-14.1.gz
   /usr/share/man/man1/llvm-readobj-14.1.gz
   chase: /usr/share/man/man1/llvm-reduce-14.1.gz: No such file or directory
   /usr/share/man/man1/llvm-rtdyld-14.1.gz
   /usr/share/man/man1/llvm-size-14.1.gz
   /usr/share/man/man1/llvm-stress-14.1.gz
   /usr/share/man/man1/llvm-strings-14.1.gz
   /usr/share/man/man1/llvm-strip-14.1.gz
   /usr/share/man/man1/llvm-symbolizer-14.1.gz
   /usr/share/man/man1/llvm-tblgen-14.1.gz

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 

Bug#1026966: ITP: xdoctest -- Xdoctest - Execute doctests. A Python package for executing tests in documentation strings!

[Bo YU]

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

* Package name: xdoctest
  Version : 1.1.0 
  Upstream Author : Jon Crall 
* URL : https://github.com/Erotemic/xdoctest 
* License : Apache-2.0 license
  Programming Lang: Python,
  Description : Xdoctest - Execute doctests. A Python package for executing 
tests in documentation strings!

A rewrite of Python's builtin doctest module (with pytest plugin integration) 
with AST instead of REGEX.

This blocks #1025513

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025513

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#890950: initramfs-tools: Resuming from hibernated swapfile fails

[Christoph Anton Mitterer]

Hey.

Is this still followed up or already supported to some extent in the
meantime?

I've looked through the previous messages and suggested patches and
some notes on these:

- Auto-detection of resume device, when resuming happens, is most
  likely a security hole, as I've described previously in #1020713.

  Similarly, auto-detection of a resume device when performing the
  hibernation, could be quite disastrous for the security of people:
  Just imagine someone has attached some HDD which has swap partition
  (unencrypted)... and the system would somehow automatically start to
  use that and thereby leak likely sensitive data (at least the dm-
  crypt keys of the running system.
  
  For those who run some full disk encryption, it should be possible 
  to disable any such auto-detections and only use a statically
  configured swap device/swapfile instead.


- People may have their swapfile on top of some dm-crypt block layer...
  either directly (in case of a swap "partition") or indirectly (in
  case of a swapfile where the fs and possibly further DM layers are in
  between.)


- The auto-detection of the resume_offset using filefrag does not
  generally work, as the values will be wrong for swap files on btrfs
  (the kernel wants the physical offset with respect to the block
  device, which filefrag doesn't give with btrfs.

  btrfs-progs 6.1 brought a new command for that:
 btrfs inspect-internal map-swapfile
  with the --resume-offset option.
  Btw. there's now also:
 btrfs filesyste mkswapfile


- Also on btrfs, people that want to use btrfs and a swapfile will
  most likely want to have that in a separate btrfs subvolume.
  The reason for this is subvolumes containing a swapfile have several
  limitations (e.g. no snapshots).

  This in turn however, may need some further support from any
  integration into initramfs-tools:
  
  One could have something like e.g. /var/local/hibernate/swapfile
  where hibernate is a btrfs subvolume, that is really created at that
  path (i.e. not just mounted at it).
  That should subvolume should then be available as soon as the fs is
  mounted.
  Even if / is not the actual / on the btrfs.
  E.g. when the real top-level subvolume of the btrfs contains:
/root-subvol/var/local/hibernate/swapfile
  and is mounted with -o subvol=/root-subvol to / things should still
  be there as soon as the root fs is there.

  It could however be, that people choose a different layout, with the
  top-level subvolume containing:
 /root-subvol/
 /hibernate/swapfile
  where both, /root-subvol and /hibernate are subvols and where
  /root-subvol/ is / ... in which case hibernate would not even be
  visible in the normal system, unless manually mounted to some point
  below / .
  In this case, initramfs-tools need to either support this, or at
  least somehow fail gracefully.


Some further questions that came to my mind:


Does anyone here know, whether the kernel somehow invalidates the swap
file once it has been unhibernated from - or does initramfs-tools
somehow disable it from being used again?

I ask because in my e.g. my case I boot from USB stick (which contains
GRUB/kernel/intiamfs)... and that USB stick is typically already gone
once the system has finished booting... so initramfs-tools couldn't
just regenerate the initramfs with new information to not use the swap
file on next boot.


Not sure whether this would even work right now, but in principle
people may want to disable swap until it's really actually needed for
hibernation.

The problem is that vm.swappiness doesn't really disable swapping (even
if set to 0, the kernel still might swap). Also it would affect any
swap area and not just the one that should only be used for
hibernation.

So my hope would be that systemd's hibernate.target could perhaps be
used to make some other service (that actually starts the hibernation-
swap on-demand only, right before needed) reverse depend on the former.
It could perhaps even allow to create the swapfile right on-demand
(freeing up disk space otherwise).

But in that case, and if initramfs-tools also do some work with the
file (e.g. determining the offset) it would kinda need to support
something like this, or at least it would be nice if it did.



So... is there any consensus already, how hibernation from swapfiles
should look like in Debian?


Thanks,
Chris. 

Bug#1026928: wget: “Cannot write to ‘myfile.mp3’ (Permission denied).” when using the default profile.

[debbug . firejail]

Package: firejail
Version: 0.9.64.4-2
Followup-For: Bug #1026928
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

> I can't reproduce it yet. What do you mean with "local directory"?
> Your home directory? Is there anything special about this directory?
> Please provide full output when running firejail with --debug.

I meant the "$CWD", which was something like /collection/music. There
is nothing special about the directory. I have write permission and in
fact it has no problem writing the file if I use --noprofile.

I ran it again using --debug. There is a huge amount of output which
would be cumbersome to sanitize, but not enough output at the very end
where it fails:

===8<--
Current directory: /collection/music
…
Connecting to web.archive.org (web.archive.org)|207.241.237.3|:80... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://web.archive.org/web/«url» [following]
--«timestamp»--   http://web.archive.org/web/«url»
Reusing existing connection to web.archive.org:80.
HTTP request sent, awaiting response... 200 OK
Length: 33763692 (35M) [audio/mpeg]
myfile.mp3: Permission denied

Cannot write to ‘myfile.mp3’ (Permission denied).
Sandbox monitor: waitpid 15 retval 15 status 768
===8<--

Perhaps it was fixed in a later version. I’m using Firejail 0.9.64.4-2
(apparently with cgroup=no for some reason) & GNU Wget 1.21.

Bug#1026312: meson: diff for NMU version 1.0.0-1.1

[Eli Schwartz]

This patch is non-upstreamable.

I must confess however that I am surprised that setuptools is installed
in your buildd at all -- Meson doesn't use it, and projects using Meson
most likely don't also need setuptools at the same time. So this should
be a moot point.

If setuptools is not installed, it cannot overwrite the stdlib
distutils. And there's a viable approach to not using distutils by the
time distutils is removed from the stdlib.

-- 
Eli Schwartz

Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors

[tony mancill]

On Sat, Dec 24, 2022 at 08:22:43PM +0100, Aurelien Jarno wrote:
> Source: openjfx
> Version: 11.0.11+0-1.1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> openjfx tries to build with -j64 on zani.debian.org, which only has 2
> processors and 8GB of RAM:
> 
> buildd   3853047  0.0  0.0  67668 4 ?S11:07   0:00 cmake 
> --build 
> /build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release
>  --config Release -- -j64
> buildd   3853048  0.0  0.0   3200   272 ?S11:07   0:00 
> /usr/bin/gmake -f Makefile -j64
> 
> This hogs the buildd resources and we had to kill the build.

Yeah, that seems excessive.  FWIW, the most recent upload didn't change
anything related to the build options, so this has built successfully in
the past.

It built successfully on armel with the auto-detected value -j4, so it's
surprising to see it pick 64 if there are only 2 processors.  The only
reference to the number of compile threads is this bit of Groovy from
build.gradle:

defineProperty("NUM_COMPILE_THREADS", 
"${Runtime.runtime.availableProcessors()}")

I will have a look to try to determine where the value of 64 is coming
from.  We can clamp the value if need be.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1024252: boost1.74: diff for NMU version 1.74.0-18.1

[Stefano Rivera]

Control: tags 1024252 + patch


Dear maintainer,

I've prepared an NMU for boost1.74 (versioned as 1.74.0-18.1). The diff
is attached to this message.

Regards.

SR
diff -Nru boost1.74-1.74.0/debian/changelog boost1.74-1.74.0/debian/changelog
--- boost1.74-1.74.0/debian/changelog	2022-12-17 16:19:02.0 -0400
+++ boost1.74-1.74.0/debian/changelog	2022-12-24 21:06:20.0 -0400
@@ -1,3 +1,11 @@
+boost1.74 (1.74.0-18.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update PEP-3149 patch to add support for Python 3.11 (which dropped the SO
+sysconfig variable). (Closes: #1024252)
+
+ -- Stefano Rivera   Sat, 24 Dec 2022 21:06:20 -0400
+
 boost1.74 (1.74.0-18) unstable; urgency=medium
 
   * [754888a] Disable blhc-check in gitlab-ci.
diff -Nru boost1.74-1.74.0/debian/patches/0001-Add-PEP-3149-compliant-extension-suffix-discovery.patch boost1.74-1.74.0/debian/patches/0001-Add-PEP-3149-compliant-extension-suffix-discovery.patch
--- boost1.74-1.74.0/debian/patches/0001-Add-PEP-3149-compliant-extension-suffix-discovery.patch	2022-12-17 16:09:48.0 -0400
+++ boost1.74-1.74.0/debian/patches/0001-Add-PEP-3149-compliant-extension-suffix-discovery.patch	2022-12-24 18:36:21.0 -0400
@@ -32,7 +32,7 @@
 +# Discover and set extension suffix
 +#
 +debug-message "Checking for extension suffix..." ;
-+local full-cmd = "from __future__ import print_function; import sysconfig; print(sysconfig.get_config_var('SO'))" ;
++local full-cmd = "from __future__ import print_function; import sysconfig; print(sysconfig.get_config_var('EXT_SUFFIX'))" ;
 +local full-cmd = $(interpreter-cmd)" -c \"$(full-cmd)\"" ;
 +debug-message "running command '$(full-cmd)'" ;
 +local result = [ SHELL $(full-cmd) : strip-eol : exit-status ] ;

Bug#1023561: yubico-piv-tool: selfsign-certificate fails nondescriptively, update needed?

[Richard Hansen]

Control: tags -1 patch

On Sun, 06 Nov 2022 17:58:06 + Jamie Lentin  wrote:

Does the package need updating?


Can you try merge request #7 [1] to see if it works for you?  You can find 
pre-built .deb files in the CI artifacts [2] for that merge request.

(Disclaimer: I'm not a maintainer for yubico-piv-tool, just someone who wants 
to update it.)

[1] https://salsa.debian.org/auth-team/yubico-piv-tool/-/merge_requests/7
[2] 
https://salsa.debian.org/rhansen/yubico-piv-tool/-/jobs/3701682/artifacts/browse/debian/output/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025702: gimp: Failed dum text editing

[Bernhard Übelacker]

Dear Maintainer,
this backtrace looks similar to the ones shown in these upstream bugs:

https://gitlab.gnome.org/GNOME/gimp/-/issues/1891   (open)
https://gitlab.gnome.org/GNOME/gimp/-/issues/3103   (closed)
https://gitlab.gnome.org/GNOME/gimp/-/issues/6457   (closed)

With the instructions in the last one I could quite
fast reproduce this crash, showing the same backtrace.
(See "Thread 1" below.)
Seems in the end the function `g_str_hash` gets called
with an unexpected null pointer.

Kind regards,
Bernhard



LANG=C gimp
- File - New - OK
- Select Text tool in toolbox at the left
- Click at the font selection button in the Text tools options at the middle 
left (opens the drop down list of fonts)
- Click at one entry and drag it to the right (needs sometimes a few tries)







```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
12.2.0-7' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-zpDQmA/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-zpDQmA/gcc-12-12.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-7)

# Libraries #
using babl version 0.1.98 (compiled against version 0.1.96)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.74.2 (compiled against version 2.74.1)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.10 (compiled against version 1.50.10)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```

fatal error: Segmentation fault


Stack trace:
```

# Stack traces obtained from PID 282910 - Thread 282910 #

[New LWP 282911]
[New LWP 282912]
[New LWP 282913]
[New LWP 282914]
[New LWP 282915]
[New LWP 282916]
[New LWP 282917]
[New LWP 282918]
[New LWP 282919]
[New LWP 282920]
[New LWP 282921]
[New LWP 282922]
[New LWP 282923]
[New LWP 282924]
[New LWP 282925]
[New LWP 282941]
[New LWP 282942]
[New LWP 282961]
[New LWP 282962]
[New LWP 283017]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffcd58a1e70, fd=15) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target IdFrame
* 1Thread 0x7f509bcedec0 (LWP 282910) "gimp"__GI___libc_read 
(nbytes=256, buf=0x7ffcd58a1e70, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f509b1416c0 (LWP 282911) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f509a9406c0 (LWP 282912) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7f509213f6c0 (LWP 282913) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f509a13f6c0 (LWP 282914) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f509993e6c0 (LWP 282915) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f509913d6c0 (LWP 282916) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f509893c6c0 (LWP 282917) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f5093fff6c0 (LWP 282918) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  10   Thread 0x7f50937fe6c0 (LWP 282919) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  11   Thread 

Bug#1026910: calamares-settings-mobian: file conflicts with calamares-settings-debian

[undef]

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.



Hi, Thanks for the bug report.


   dpkg: error processing archive 
/tmp/apt-dpkg-install-MPIdXZ/147-calamares-settings-mobian_0.2.6_all.deb 
(--unpack):
trying to overwrite '/etc/calamares/modules/mount.conf', which is also in 
package calamares-settings-debian 12.0.3-1



I believe this here is the problem. Calamares-settings-mobian and 
calamares-settings-debian implement exactly the same functionality, 
though Mobian does it for devices with small touch-only screens. I'll 
add a `Conflicts:`  to ensure the two are never installed at the same time.

Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]

[Albert Nash]

Package: linux-image-5.10.0-20-amd64
Version: 5.10.158-2
How to reproduce:
1) Boot Debian GNU/Linux 11 (bullseye), which is „stable“ now, on Lenovo 
ThinkPad T14s Gen 1 with Intel Core i7-10610U.
2) Search for „Error“ in the output of dmesg.
3) Find
ACPI Error: Needed [Integer/String/Buffer], found [Package] 0b621212 
(20200925/exresop-469)
[ 4.387053] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for 
[OpcodeName unavailable] (20200925/dswexec-431)
[ 4.387198] ACPI Error: Aborting method \ADBG due to previous error 
(AE_AML_OPERAND_TYPE) (20200925/psparse-529)
[ 4.387346] ACPI Error: Aborting method \_SB.HIDD._DSM due to previous error 
(AE_AML_OPERAND_TYPE) (20200925/psparse-529)
[ 4.387486] ACPI: \_SB_.HIDD: failed to evaluate _DSM (0x3003)
The anonymized prefix of the dmesg output till this error is attached.
Now, since we see an “error”, we wonder what exactly goes wrong.  How do we 
translate this into plain English?  What exactly should we worry about?
Thanks in advance,
Albert
[0.00] Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.158-2 (2022-12-13)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 
root=UUID=994be375-5bdc-4b91-b60b-00f80de5f90b ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9a681fff] usable
[0.00] BIOS-e820: [mem 0x9a682000-0x9e85] reserved
[0.00] BIOS-e820: [mem 0x9e86-0x9fbe9fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9fbea000-0x9fc4efff] ACPI data
[0.00] BIOS-e820: [mem 0x9fc4f000-0x9fc4] usable
[0.00] BIOS-e820: [mem 0x9fc5-0xa7ff] reserved
[0.00] BIOS-e820: [mem 0xa800-0xa8bf] usable
[0.00] BIOS-e820: [mem 0xa8c0-0xae7f] reserved
[0.00] BIOS-e820: [mem 0xfed2-0xfed7] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00084d7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x77e46018-0x77e56057] usable ==> usable
[0.00] e820: update [mem 0x77e46018-0x77e56057] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009efff] 
usable
[0.00] reserve setup_data: [mem 0x0009f000-0x000f] 
reserved
[0.00] reserve setup_data: [mem 0x0010-0x77e46017] 
usable
[0.00] reserve setup_data: [mem 0x77e46018-0x77e56057] 
usable
[0.00] reserve setup_data: [mem 0x77e56058-0x9a681fff] 
usable
[0.00] reserve setup_data: [mem 0x9a682000-0x9e85] 
reserved
[0.00] reserve setup_data: [mem 0x9e86-0x9fbe9fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x9fbea000-0x9fc4efff] 
ACPI data
[0.00] reserve setup_data: [mem 0x9fc4f000-0x9fc4] 
usable
[0.00] reserve setup_data: [mem 0x9fc5-0xa7ff] 
reserved
[0.00] reserve setup_data: [mem 0xa800-0xa8bf] 
usable
[0.00] reserve setup_data: [mem 0xa8c0-0xae7f] 
reserved
[0.00] reserve setup_data: [mem 0xfed2-0xfed7] 
reserved
[0.00] reserve setup_data: [mem 0x0001-0x00084d7f] 
usable
[0.00] efi: EFI v2.70 by Lenovo
[0.00] efi: TPMFinalLog=0x9fbe2000 SMBIOS=0x9cc83000 SMBIOS 
3.0=0x9cc76000 ACPI=0x9fc4e000 ACPI 2.0=0x9fc4e014 MEMATTR=0x9602d018 
ESRT=0x9b107000 MOKvar=0x9601d000 RNG=0x9fc4d018 TPMEventLog=0x77e57018 
[0.00] efi: seeding entropy pool
[0.00] random: crng init done
[0.00] Kernel is locked down from EFI Secure Boot; see man 
kernel_lockdown.7
[0.00] secureboot: Secure boot enabled
[0.00] SMBIOS 

Bug#1026835:

[Nilson Silva]

fix for correct package:

* Package name:  python-deprecation-alias
  Version : 0.3.1
  Upstream Author : Dominic Davis-Foster 
* URL : https://github.com/briancurtin/deprecation
* License : Apache License 2.0
  Programming Lang: Python
  Description : A wrapper around 'deprecation' providing support for 
deprecated aliases


Additional information:

this package, (python-deprecation-alias), is needed for:
python-consolekit -- Additional utilities for click:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026963

and the python-consolekit -- Additional utilities for click
it's a dependency for the :
"whey" package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204

Bug#1026964: transition: wxwidgets3.2

[Scott Talbert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: wxwidgets...@packages.debian.org
Control: affects -1 + src:wxwidgets3.2

Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to 
rebuilding with GLX support instead of EGL support. See bug #1024147.
Updated wxwidgets3.2 package has been uploaded to experimental.

Ben file:

title = "wxwidgets3.2";
is_affected = .depends ~ "libwxbase3.2-0" | .depends ~ "libwxgtk-media3.2-0" | 
.depends ~ "libwxgtk-webview3.2-0" | .depends ~ "libwxgtk3.2-0" | .depends ~ 
"libwxbase3.2-1" | .depends ~ "libwxgtk-media3.2-1" | .depends ~ 
"libwxgtk-webview3.2-1" | .depends ~ "libwxgtk3.2-1";
is_good = .depends ~ "libwxbase3.2-1" | .depends ~ "libwxgtk-media3.2-1" | 
.depends ~ "libwxgtk-webview3.2-1" | .depends ~ "libwxgtk3.2-1";
is_bad = .depends ~ "libwxbase3.2-0" | .depends ~ "libwxgtk-media3.2-0" | 
.depends ~ "libwxgtk-webview3.2-0" | .depends ~ "libwxgtk3.2-0";

Bug#1026963: ITP: python-consolekit -- Additional utilities for click

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-consolekit
  Version : 1.4.1
  Upstream Author : Dominic Davis-Foster 
* URL : https://github.com/domdfcoding/consolekit
* License : MIT/expat
  Programming Lang: Python
  Description : Additional utilities for click

 package required for "whey" building:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204

Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors

[Aurelien Jarno]

Source: openjfx
Version: 11.0.11+0-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

openjfx tries to build with -j64 on zani.debian.org, which only has 2
processors and 8GB of RAM:

buildd   3853047  0.0  0.0  67668 4 ?S11:07   0:00 cmake 
--build 
/build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release 
--config Release -- -j64
buildd   3853048  0.0  0.0   3200   272 ?S11:07   0:00 
/usr/bin/gmake -f Makefile -j64

This hogs the buildd resources and we had to kill the build.

Bug#1023964: 28.0.1 also has memory leaks

[Melvin Vermeeren]

Hi all,

I also would like to see a new version of obs-studio. Early version of 28 
turned out to have a nasty memory leak if SRT streams are used. This leaks 
about 10MB/s on a high-bitrate stream, which is very problematic for streaming 
usage.

Upstream has fixed these issues already in a newer release, see:
https://github.com/obsproject/obs-studio/issues/7305

Would very much appreciate an update!

Cheers,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#975032: [PATCH] watchdog: Incorrect pagesize used to calculate allocatable memory on arm

[Mark Glines]

I see this bug on aarch64 too.  Thanks for opening this ticket.

The attached patch seems to work for me.  It just replaces EXEC_PAGESIZE 
with a call to getpagesize().



Here's what my watchdog logs say before:

Dec 23 17:12:09 ceph00 watchdog[8178]:  memory: minimum pages = 800 
free, 0 allocatable, max swap 0 (65536 byte pages)


And after:

Dec 24 18:46:50 ceph00 watchdog[315682]:  memory: minimum pages = 800 
free, 0 allocatable, max swap 0 (4096 byte pages)
diff -uNr orig/memory.c src/memory.c
--- orig/memory.c	2020-04-24 04:56:46.0 -0400
+++ src/memory.c	2022-12-24 13:41:36.871213261 -0500
@@ -70,7 +70,7 @@
 
 static long kb_per_page(int pages)
 {
-	return pages * (long)(EXEC_PAGESIZE / 1024);
+	return pages * (long)(getpagesize() / 1024);
 }
 
 /*
@@ -181,7 +181,7 @@
 int check_allocatable(void)
 {
 	char *mem;
-	size_t len = EXEC_PAGESIZE * (size_t)minalloc;
+	size_t len = getpagesize() * (size_t)minalloc;
 
 	if (minalloc <= 0)
 		return 0;
diff -uNr orig/watchdog.c src/watchdog.c
--- orig/watchdog.c	2020-04-24 04:56:46.0 -0400
+++ src/watchdog.c	2022-12-24 13:42:04.186439954 -0500
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 		/* For EXEC_PAGESIZE */
 #include 
 #include 
 #ifdef __linux__
@@ -251,7 +250,7 @@
 		log_message(LOG_INFO, " memory not checked");
 	else
 		log_message(LOG_INFO, " memory: minimum pages = %d free, %d allocatable, max swap %d (%d byte pages)",
-			minpages, minalloc, maxswap, EXEC_PAGESIZE);
+			minpages, minalloc, maxswap, getpagesize());
 
 	if (target_list == NULL)
 		log_message(LOG_INFO, " ping: no machine to check");

Bug#1026119: transition: matplotlib

[Sandro Tosi]

> I'll update this report when i've uploaded a new release in experimental and
> with the results of some autopkgtests.

matplotlib/3.6.2-2 is in experimental and the results from autopkgtest
at https://qa.debian.org/excuses.php?experimental=1=matplotlib
are quite promising.

Looking at the errors:

* dolfin is a real bug, that needs to be correct:
https://bitbucket.org/fenics-project/dolfin/src/588d3acdb58727b6331588f9278d611534f4c93e/python/dolfin/common/plotting.py#lines-279
uses a now removed argument to `gca()`,
https://matplotlib.org/3.6.2/api/prev_api_changes/api_changes_3.6.0.html#:~:text=Keyword%20arguments%20to%20gca()

* lmfit-py, all failures seem unrelated to the new mpl, mostly missing modules

* mplcursors, seems like a valid bug, but it's unclear to me what the
failing test is trying to accomplish (catching warnings?) and so it
looks like an upstream fix (currently not available AFAICT) is neede

* poretools, not sure if this is a bug in this package or matplotlib

All in all, i think this transition is rather manageable and i'd like
to upload to unstable, if you're ok with it.

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

Bug#1026570: python-streamz: FTBFS: ValueError: I/O operation on closed file.

[Nilesh Patra]

Control: fix blocked by 1026590

Pretty sure this stems from dask.distributed itself, as I see similar error 
messages
there.

On Tue, 20 Dec 2022 18:23:56 +0100 Lucas Nussbaum  wrote:
> Source: python-streamz
> Version: 0.6.3-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> >  debian/rules binary
> > dh binary --with python3 --buildsystem=pybuild
> >dh_update_autotools_config -O--buildsystem=pybuild
> >dh_autoreconf -O--buildsystem=pybuild
> >dh_auto_configure -O--buildsystem=pybuild
> > I: pybuild base:240: python3.11 setup.py config 
> > running config
> > I: pybuild base:240: python3.10 setup.py config 
> > running config
> >dh_auto_build -O--buildsystem=pybuild
> > I: pybuild base:240: /usr/bin/python3.11 setup.py build 
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/graph.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/__init__.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/dask.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/orderedweakset.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/plugins.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/core.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/utils_test.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/sources.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/collection.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/batch.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/sinks.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > copying streamz/utils.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz
> > creating 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
> > copying streamz/dataframe/__init__.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
> > copying streamz/dataframe/core.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
> > copying streamz/dataframe/aggregations.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
> > copying streamz/dataframe/utils.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
> > creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/__init__.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/py3_test_core.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_plugins.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_sinks.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_core.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_batch.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_sources.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_graph.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_dask.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > copying streamz/tests/test_kafka.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
> > creating 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests
> > copying streamz/dataframe/tests/test_dataframe_utils.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests
> > copying streamz/dataframe/tests/test_dataframes.py -> 
> > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1026961: openconnect: fails to restore previous network configuration

[Francesco Poli (wintermute)]

Package: openconnect
Version: 9.01-2
Severity: normal

Hello and thanks for maintaining this package in Debian!

I tried it to connect to a Fortinet SSL VPN.
I used the following command:

  # openconnect --prot=fortinet -u $VPNUSER $VPNSERVER

It worked, in the sense that I was able to connect to the VPN.

However, when I decided to disconnect, I used [Ctrl+C] to end the
session: the session ended as expected (good!), but I was left with
a non-working network configuration (outside of the VPN).
In other words, openconnect failed to restore the network configuration
that was in place before its invocation!
Even pinging a remote host resulted in "Network unreachable" errors.

I had to bring my Ethernet network interface down:

  # ifdown $INTERFACE

and then up again:

  # ifup $INTERFACE

in order to get back to a working network configuration (this resulted
in obtaining the network parameters back from the DHCP server and
everything was working fine again).

At the end of the session, I expected openconnect to automatically
restore the network configuration as it had found it at the beginning of
the session.
Please note that another VPN client (package 'openfortivpn', which is
specific for Fortinet VPNs) transparently restores the previous network
configuration, when the user hits [Ctrl+C] to disconnect from the VPN...

I acknowledge that this misbehavior by openconnect is not a big flaw,
but having to manually issue an ifdown/ifup command is anyway annoying.

Please fix this issue and/or forward this bug report upstream, as
appropriate.

Thanks for your time!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
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 openconnect depends on:
ii  libc62.36-6
ii  libgnutls30  3.7.8-4
ii  libopenconnect5  9.01-2
ii  libproxy1v5  0.4.18-1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  vpnc-scripts 0.1~git20220510-1

Versions of packages openconnect recommends:
ii  python3 3.10.6-1
ii  python3-asn1crypto  1.5.1-2
ii  python3-mechanize   1:0.4.8+pypi-4
ii  python3-netifaces   0.11.0-2

Versions of packages openconnect suggests:
ii  bash-completion  1:2.11-6
ii  xdg-utils1.1.3-4.1

-- no debconf information

Bug#1026960: ITP: ruby-telesignenterprise -- TeleSign Enterprise Ruby SDK

[Vinay]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-telesignenterprise
 Version   : 2.2.2
 Upstream Author   : 2017 TeleSign Corp
*URL   :https://github.com/TeleSign/ruby_telesign_enterprise
*License   : Expat
 Programming Lang  : Ruby
*Description   : TeleSign Enterprise Ruby SDK

 TeleSign Ruby SDK lets you easily integrate with our REST API
.

This gem is required for gitlab.

- Vinay Keshava

Bug#1025269: ITP: dotnet-sdk-6.0

[Andres Salomon]

Hi,

Do you have a git repo somewhere with this being worked on? Are you 
basing your work off of Ubuntu's dotnet6* packages (which have some 
bootstrapping challenges)?


Thanks,
Andres


* 

Bug#1026959: ITP: ruby-oj-introspect -- Oj introspect parser

[Vinay]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-oj-introspect
 Version   : 0.7.1
 Upstream Author   : 2022 Mehmet Emin INAC
*URL   :https://github.com/meinac/oj-introspect
*License   : Expat
 Programming Lang  : Ruby
*Description   : Oj introspect parser

 Embeds start and end byte offsets of JSON objects into generated Ruby hashes.
.

This gem is required for gitlab.

- Vinay Keshava

Bug#1026792: How libre is the license

[Bálint Réczey]

Hi Geert,

On Wed, 21 Dec 2022 10:22:36 +0100 Geert Stappers  wrote:
> > * Package name: firebuild
> > * URL : https://firebuild.com
> > * License : Firebuild-license
>
> Qouting website:
>
>   License
>
>   Free for personal use or commercial trial.
>
>   Non-trial commercial use requires per-computer license available below:
>
>   Buy license(s) or manage license(s)

Thanks for raising this, he website is now updated to list the full
license also present in the package:

Free for personal use or commercial trial.
Non-trial commercial use requires per-computer license: Buy license(s)
or manage license(s)
Modification and redistribution are permitted, but commercial use of
derivative works is subject to the same requirements of this license

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

>
> I do like the 'Buy license', it states "it has value".
>
> When sending money are the 100 freedoms still there?
>
>   001 Use every where, even for crypto mining

There is no restriction on the field, thus it can be used even for
crypto mining.
The license is per computer, thus using it on 5 computers needs 5
licenses, but that's all.
There are services such as GitLab's and GithHub's CI which the current
license does not cover (unless they are running locally), but
licensing for GitHub will be available soon.

>   010 Share with others

Yes, the source and binaries can be shared under the same license.

>   011 Study the source
>   100 Modify when deemed

Modification and redistribution of the modified source and binaries
are allowed and it implies that the source code can be studied.
Patches are also welcome! :-)

Cheers,
Balint

>
>
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
>
>

Bug#1026957: mozillavpn: Multiple packaging issues

[Lisandro Damián Nicanor Pérez Meyer]

On Sat, 24 Dec 2022 at 14:42, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> Hi! My first goal was to warn you that you no longer need to have
> qt6-qpa-plugins as a dependency of your package. This was due to an
> error on qt6-base's packaging. Fell free to drop it.
>
> Now after looking at debian/control I see you are manually listing all
> the qt dependencies. This should not be necessary at all as
> ${shlibs:Depends} should take care of this. If it's not then you have
> some important bug in your packaging/build system.

Worth to mention: the dependencies on qml-* are OK. If at runtime you
are having a dependency issue it might be a bug on some qml-* package
not depending on the right library. Please do not hesitate in
contacting us / filing a bug if that's the case.

Bug#1026958: qt6ct: Should probably no longer depend upon qt6-qpa-plugins

[Lisandro Damián Nicanor Pérez Meyer]

Source: qt6ct
Version: 0.7-2
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi!

Your package currently depends upon qt6-qpa-plugins. This was needed due
to a bug on qt6-base's packaging, which is now solved. Please cosider
dropping this dependency.

Kinds regards, Lisandro.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#1026957: mozillavpn: Multiple packaging issues

[Lisandro Damián Nicanor Pérez Meyer]

Source: mozillavpn
Version: 2.1.0-1
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi! My first goal was to warn you that you no longer need to have
qt6-qpa-plugins as a dependency of your package. This was due to an
error on qt6-base's packaging. Fell free to drop it.

Now after looking at debian/control I see you are manually listing all
the qt dependencies. This should not be necessary at all as
${shlibs:Depends} should take care of this. If it's not then you have
some important bug in your packaging/build system.

Kinds regards, Lisandro.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#1026956: focuswriter: Probably uneeded dependency upon qt6-qpa-plugins

[Lisandro Damián Nicanor Pérez Meyer]

Source: focuswriter
Version: 1.8.3-1
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi!

Your package currently depends upon qt6-qpa-plugins. This used to be
necessary due to a bug in qt6-base. This package is most probably not
needed now, as the necessary plugins will be installed along qt6 gui.

Reagrds, Lisandro.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#1026955: expeyes: Depends on qt6-qpa-plugins

[Lisandro Damián Nicanor Pérez Meyer]

Source: expeyes
Version: 5.3.0+repack-1
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi! Your package currently depends upon qt6-qpa-plugins. This used to be
required in order for the app to work due to a bug in qt6-base's
packaging. The dependency is most probably no longer necessary, please
check if you can drop it from the dependency list.

Kinds regards, Lisandro.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#1026954: calibre: Remove (now) unnecesary dependency on qt6-qpa-plugins

[Lisandro Damián Nicanor Pérez Meyer]

Source: calibre
Version: 6.10.0+dfsg-2
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi! Your package currently depends on qt6-qpa-plugins (##1014953). This
was a bug in qt6-base which is already fixed. Please drop the dependency
on this package, except you still have a good reason to keep it.

Thanks, Lisandro.



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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#1026953: Please update fonts-sil-alkalami to latest release 2.000

[Amr Ibrahim]

Package: fonts-sil-alkalami

Hallo,

Please update fonts-sil-alkalami to the latest release 2.000:

https://github.com/silnrsi/font-alkalami/releases/latest

And please fix the watch file.

Best,
Amr

Bug#1026952: Please update fonts-sil-scheherazade to latest release 3.300

[Amr Ibrahim]

Package: fonts-sil-scheherazade

Hallo,

Please update fonts-sil-scheherazade to the latest release 3.300:

https://github.com/silnrsi/font-scheherazade/releases/latest

And please fix the watch file.

Best,
Amr

Bug#1026951: Please update fonts-sil-lateef to latest release 2.000

[Amr Ibrahim]

Package: fonts-sil-lateef

Hallo,

Please update fonts-sil-lateef to the latest release 2.000:

https://github.com/silnrsi/font-lateef/releases/latest

And please fix the watch file.

Best,
Amr

Bug#1026230: debhelper: Unable to successfully build in read-only source directory.

[Guillem Jover]

On Sat, 2022-12-17 at 12:07:22 +0100, Niels Thykier wrote:
> On Fri, 16 Dec 2022 13:13:34 -0500 Garrett Kajmowicz wrote:
> > One other possibly-related item of note (I can file a separate bug if you 
> > like)
> > and which may have an existing solution:
> > Passing in --buildinfo-option=-u/out still results in a -O option which
> >   refers to the wrong directory. That is, I get the following:
> > dpkg-genbuildinfo -u/out --build=binary 
> > -O../_2.0.6-1_amd64.buildinfo
> > dpkg-genbuildinfo: error: cannot write 
> > ../_2.0.6-1_amd64.buildinfo.new: Permission denied
> > 
> > This resulted from an experiment where I was copying the source code to
> > a temporary directory with read/write permissions, but where the parent
> > directory was not writable.

> If it is a bug, then it is a separate one for dpkg. I will let Guillem
> comment on that.

After checking this, I think I'd consider this at most a missing
feature, related to the overall request here, and as part of that to be
able to specify a different global "upload-files-dir".

But for now I think you should be able to overcome this by using the
dpkg-buildpackage --buildinfo-file option.

Thanks,
Guillem

Bug#1026950: Please update fonts-sil-awami-nastaliq to latest release 3.000

[Amr Ibrahim]

Package: fonts-sil-awami-nastaliq

Hallo,

Please update fonts-sil-awami-nastaliq to the latest release 3.000:

https://github.com/silnrsi/font-awami/releases/latest

And please fix the watch file.

Best,
Amr

Bug#1026949: Please update fonts-hosny-amiri to latest release 1.000

[Amr Ibrahim]

Package: fonts-hosny-amiri

Hallo,

Please update fonts-hosny-amiri to the latest release 1.000:

https://github.com/aliftype/amiri/releases/latest

And please fix the watch file.

Best,
Amr

Bug#1026858: Dependency on debconf dropped prematurely

[Holger Wansing]

Control: tags -1 + pending


Cyril Brulebois  wrote (Thu, 22 Dec 2022 23:06:05 +0100):
> Faidon Liambotis  (2022-12-22):
> > Going forward there are a few options:
> >   * Revert the change and depend on debconf again. This is the safest
> > option, as this has been the status quo since 2007.
> 
> That would look good to me.

Fixed in git.


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

Bug#1026928: wget: “Cannot write to ‘myfile.mp3’ (Permission denied).” when using the default profile.

[Reiner Herrmann]

Hi,

On Fri, Dec 23, 2022 at 11:01:20PM -0500, debbug.firej...@sideload.33mail.com 
wrote:
> There is no problem if the --noprofile option is given.  But if
> firejail is allowed to use the default profile
> (/etc/firejail/wget.profile), fetched files cannot be written to the
> local directory.
[...]
>   Cannot write to ‘myfile.mp3’ (Permission denied).

I can't reproduce it yet. What do you mean with "local directory"?
Your home directory? Is there anything special about this directory?
Please provide full output when running firejail with --debug.

Kind regards,
  Reiner

Bug#1026312: meson: diff for NMU version 1.0.0-1.1

[Stefano Rivera]

Control: tags 1026312 + patch
Control: tags 1026312 + pending

Dear maintainer,

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

Regards.

SR
diff -Nru meson-1.0.0/debian/changelog meson-1.0.0/debian/changelog
--- meson-1.0.0/debian/changelog	2022-12-23 12:24:54.0 -0400
+++ meson-1.0.0/debian/changelog	2022-12-24 11:22:03.0 -0400
@@ -1,3 +1,11 @@
+meson (1.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Correctly select the Debian python scheme with modern distutils.
+Closes: #1026312.
+
+ -- Stefano Rivera   Sat, 24 Dec 2022 11:22:03 -0400
+
 meson (1.0.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru meson-1.0.0/debian/patches/3-debian-sysconfig-layout.patch meson-1.0.0/debian/patches/3-debian-sysconfig-layout.patch
--- meson-1.0.0/debian/patches/3-debian-sysconfig-layout.patch	1969-12-31 20:00:00.0 -0400
+++ meson-1.0.0/debian/patches/3-debian-sysconfig-layout.patch	2022-12-24 11:22:03.0 -0400
@@ -0,0 +1,60 @@
+From 9cea9e351d20d58f447b06baa7bb9a3f5cc40ea4 Mon Sep 17 00:00:00 2001
+From: Stefano Rivera 
+Date: Mon, 19 Dec 2022 19:56:32 -0400
+Subject: [PATCH] Update the Debian Python path detection for setuptools >= 60
+
+Debian now (since Python 3.10.2-6) adds the deb_system scheme to
+sysconfig. Newer distutils (such as bundled with setuptools >= 60) adds
+fetch schemes from sysconfig, rather than duplicating the sysconfig
+schemes statically in distutils.command.install.
+
+This change broke meson's deb_system check.
+
+This patch replaces that mechanism (for newer Debian releases) with
+explicit scheme selection, which is far simpler.
+But it also retains the old mechanism, for older Debian releases that
+require it (Debian <= 11).
+
+Fixes: #8739 (for python module, and makes similar minimal changes to the python3 module)
+
+Fixes: https://bugs.debian.org/1026312
+
+Forwarded: https://github.com/mesonbuild/meson/pull/11211
+---
+ mesonbuild/modules/python.py | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/mesonbuild/modules/python.py b/mesonbuild/modules/python.py
+index f74d10e4c..68632af2d 100644
+--- a/mesonbuild/modules/python.py
 b/mesonbuild/modules/python.py
+@@ -363,15 +363,23 @@ def get_distutils_paths(scheme=None, prefix=None):
+ # default scheme to a custom one pointing to /usr/local and replacing
+ # site-packages with dist-packages.
+ # See https://github.com/mesonbuild/meson/issues/8739.
+-# XXX: We should be using sysconfig, but Debian only patches distutils.
++# Until version 3.10.2-6, Debian only patched distutils, not sysconfig.
+ 
+ if 'deb_system' in distutils.command.install.INSTALL_SCHEMES:
++# Debian systems before setuptools-bundled distutils was used by default
+ paths = get_distutils_paths(scheme='deb_system')
+ install_paths = get_distutils_paths(scheme='deb_system', prefix='')
+ else:
+-paths = sysconfig.get_paths()
++if 'deb_system' in sysconfig.get_scheme_names():
++# Use Debian's custom deb_system scheme (with our prefix)
++scheme = 'deb_system'
++elif sys.version_info >= (3, 10):
++scheme = sysconfig.get_default_scheme()
++else:
++scheme = sysconfig._get_default_scheme()
++paths = sysconfig.get_paths(scheme=scheme)
+ empty_vars = {'base': '', 'platbase': '', 'installed_base': ''}
+-install_paths = sysconfig.get_paths(vars=empty_vars)
++install_paths = sysconfig.get_paths(vars=empty_vars, scheme=scheme)
+ 
+ def links_against_libpython():
+ from distutils.core import Distribution, Extension
+-- 
+2.35.1
+
diff -Nru meson-1.0.0/debian/patches/series meson-1.0.0/debian/patches/series
--- meson-1.0.0/debian/patches/series	2021-02-14 08:58:40.0 -0400
+++ meson-1.0.0/debian/patches/series	2022-12-24 11:22:03.0 -0400
@@ -1,2 +1,3 @@
 1-disable-openmpi.patch
 2-disable-rootdir-test.patch
+3-debian-sysconfig-layout.patch

Bug#1026715: cpplint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.11 3.10" returned exit code 13

[Jochen Sprickerhof]

Control: forwarded -1 https://github.com/cpplint/cpplint/pull/214

Hi,

I've send a patch upstream for this and can also do a NMU in the coming 
days if you don't disagree.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1026948: schleuder: FTBFS with ruby-sinatra >= 3.0: ERROR: Test "ruby3.1" failed: NoMethodError:

[Antonio Terceiro]

Source: schleuder
Version: 4.0.3-6
Severity: important
Justification: FTBFS
Tags: sid ftbfs
User: debian-r...@lists.debian.org
Usertags: sinatra-3

Hi,

While trying rebuilds with src:ruby-sinatra 3.0.5-1, your package failed to
build on amd64. Please try to support sinatra 3 as soon as possible, as we
would like to have that version in bookworm.

Relevant part (hopefully):
>   NoMethodError:
> undefined method `first_plaintext_part' for nil:NilClass
> 
>   expect(mail.first_plaintext_part.decoded).to 
> include("Refreshing all keys from the keyring of list #{list.email} resulted 
> in this")
>  ^
>   # ./spec/schleuder/integration/cli_spec.rb:56:in `block (3 levels) in 
> '
>   # ./spec/spec_helper.rb:64:in `block (3 levels) in '
>   # ./spec/spec_helper.rb:63:in `block (2 levels) in '
> 
> Finished in 3 minutes 13.9 seconds (files took 0.93149 seconds to load)
> 543 examples, 18 failures
> 
> Failed examples:
> 
> rspec ./spec/schleuder/unit/list_spec.rb:512 # Schleuder::List#fetch_keys 
> fetches one key by fingerprint
> rspec ./spec/schleuder/unit/list_spec.rb:526 # Schleuder::List#fetch_keys 
> fetches one key by URL
> rspec ./spec/schleuder/unit/list_spec.rb:540 # Schleuder::List#fetch_keys 
> fetches one key by email address
> rspec ./spec/schleuder/unit/list_spec.rb:554 # Schleuder::List#fetch_keys 
> does not import non-self-signatures
> rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:212 # GPGME::Ctx#refresh_keys 
> does not import non-self-signatures
> rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:200 # GPGME::Ctx#refresh_keys 
> reports errors from refreshing keys
> rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:186 # GPGME::Ctx#refresh_keys 
> updates keys from the keyserver
> rspec ./spec/schleuder/integration/keywords_spec.rb:1444 # user sends keyword 
> x-fetch-key with fingerprint
> rspec ./spec/schleuder/integration/keywords_spec.rb:1516 # user sends keyword 
> x-fetch-key without arguments
> rspec ./spec/schleuder/integration/keywords_spec.rb:1480 # user sends keyword 
> x-fetch-key with fingerprint of unchanged key
> rspec ./spec/schleuder/integration/keywords_spec.rb:1330 # user sends keyword 
> x-fetch-key with URL
> rspec ./spec/schleuder/integration/keywords_spec.rb:1408 # user sends keyword 
> x-fetch-key with unknown fingerprint
> rspec ./spec/schleuder/integration/keywords_spec.rb:1294 # user sends keyword 
> x-fetch-key with unknown email-address
> rspec ./spec/schleuder/integration/keywords_spec.rb:1258 # user sends keyword 
> x-fetch-key with email address
> rspec ./spec/schleuder/integration/keywords_spec.rb:1368 # user sends keyword 
> x-fetch-key with invalid URL
> rspec ./spec/schleuder/integration/cli_spec.rb:25 # cli #refresh_keys updates 
> keys from the keyserver for only a specific list
> rspec ./spec/schleuder/integration/cli_spec.rb:5 # cli #refresh_keys updates 
> keys from the keyserver
> rspec ./spec/schleuder/integration/cli_spec.rb:48 # cli #refresh_keys reports 
> errors from refreshing keys
> 
> Randomized with seed 37252
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.


schleuder.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1026946: ruby-omniauth-auth0: FTBFS with ruby-sinatra >= 3.0: ERROR: Test "ruby3.1" failed: ArgumentError:

[Antonio Terceiro]

Source: ruby-omniauth-auth0
Version: 2.0.0-1
Severity: important
Justification: FTBFS
Tags: sid ftbfs
User: debian-r...@lists.debian.org
Usertags: sinatra-3

Hi,

While trying rebuilds with src:ruby-sinatra 3.0.5-1, your package failed to
build on amd64. Please try to support sinatra 3 as soon as possible, as we
would like to have that version in bookworm.

Relevant part (hopefully):
>   ArgumentError:
> key must be 32 bytes
>   # 
> /usr/share/rubygems-integration/all/gems/rack-protection-3.0.5/lib/rack/protection/encryptor.rb:24:in
>  `key='
>   # 
> /usr/share/rubygems-integration/all/gems/rack-protection-3.0.5/lib/rack/protection/encryptor.rb:24:in
>  `encrypt_message'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-protection-3.0.5/lib/rack/protection/encrypted_cookie.rb:241:in
>  `write_session'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-2.2.4/lib/rack/session/abstract/id.rb:388:in
>  `commit_session'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-2.2.4/lib/rack/session/abstract/id.rb:268:in
>  `context'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-2.2.4/lib/rack/session/abstract/id.rb:260:in
>  `call'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-2.2.4/lib/rack/null_logger.rb:11:in
>  `call'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-2.2.4/lib/rack/head.rb:12:in 
> `call'
>   # 
> /usr/share/rubygems-integration/all/gems/sinatra-3.0.5/lib/sinatra/base.rb:219:in
>  `call'
>   # 
> /usr/share/rubygems-integration/all/gems/sinatra-3.0.5/lib/sinatra/base.rb:2007:in
>  `call'
>   # 
> /usr/share/rubygems-integration/all/gems/sinatra-3.0.5/lib/sinatra/base.rb:1566:in
>  `block in call'
>   # 
> /usr/share/rubygems-integration/all/gems/sinatra-3.0.5/lib/sinatra/base.rb:1782:in
>  `synchronize'
>   # 
> /usr/share/rubygems-integration/all/gems/sinatra-3.0.5/lib/sinatra/base.rb:1566:in
>  `call'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-test-2.0.2/lib/rack/test.rb:358:in
>  `process_request'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-test-2.0.2/lib/rack/test.rb:165:in
>  `custom_request'
>   # 
> /usr/share/rubygems-integration/all/gems/rack-test-2.0.2/lib/rack/test.rb:114:in
>  `get'
>   # ./spec/omniauth/strategies/auth0_spec.rb:253:in `block (3 levels) in 
> '
> 
> Finished in 0.3384 seconds (files took 0.77957 seconds to load)
> 23 examples, 14 failures
> 
> Failed examples:
> 
> rspec ./spec/omniauth/strategies/auth0_spec.rb:72 # 
> OmniAuth::Strategies::Auth0 oauth redirects to hosted login page
> rspec ./spec/omniauth/strategies/auth0_spec.rb:161 # 
> OmniAuth::Strategies::Auth0 oauth callback basic oauth to succeed
> rspec ./spec/omniauth/strategies/auth0_spec.rb:165 # 
> OmniAuth::Strategies::Auth0 oauth callback basic oauth has credentials
> rspec ./spec/omniauth/strategies/auth0_spec.rb:171 # 
> OmniAuth::Strategies::Auth0 oauth callback basic oauth has basic values
> rspec ./spec/omniauth/strategies/auth0_spec.rb:185 # 
> OmniAuth::Strategies::Auth0 oauth callback basic oauth w/refresh token to 
> succeed
> rspec ./spec/omniauth/strategies/auth0_spec.rb:189 # 
> OmniAuth::Strategies::Auth0 oauth callback basic oauth w/refresh token has 
> credentials
> rspec ./spec/omniauth/strategies/auth0_spec.rb:204 # 
> OmniAuth::Strategies::Auth0 oauth callback oidc to succeed
> rspec ./spec/omniauth/strategies/auth0_spec.rb:208 # 
> OmniAuth::Strategies::Auth0 oauth callback oidc has credentials
> rspec ./spec/omniauth/strategies/auth0_spec.rb:215 # 
> OmniAuth::Strategies::Auth0 oauth callback oidc has basic values
> rspec ./spec/omniauth/strategies/auth0_spec.rb:220 # 
> OmniAuth::Strategies::Auth0 oauth callback oidc has info
> rspec ./spec/omniauth/strategies/auth0_spec.rb:227 # 
> OmniAuth::Strategies::Auth0 oauth callback oidc has extra
> rspec ./spec/omniauth/strategies/auth0_spec.rb:235 # 
> OmniAuth::Strategies::Auth0 error_handling fails when missing client_id
> rspec ./spec/omniauth/strategies/auth0_spec.rb:243 # 
> OmniAuth::Strategies::Auth0 error_handling fails when missing client_secret
> rspec ./spec/omniauth/strategies/auth0_spec.rb:251 # 
> OmniAuth::Strategies::Auth0 error_handling fails when missing domain
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.


ruby-omniauth-auth0.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1026945: bullseye-pu: package guix/1.2.0-4

[Vagrant Cascadian]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: g...@packages.debian.org vagr...@debian.org
Control: affects -1 + src:guix

[ Reason ]

This fixes a FTBFS of due several test suites using expired OpenPGP
keys. At the time the current packages in Debian were built, the keys
had not yet expired, but was later fixed upstream:

  https://issues.guix.gnu.org/55506

And was reported in Debian against the 1.3.x versions and fixed by
applying the upstream patch:

  https://bugs.debian.org/1011863

[ Impact ]

Future security updates will not be able to be fixed without fixing
this issue first or disabling the affected tests.

[ Tests ]

Building the package succeeds with the patch; test suites pass.

[ Risks ]

None known at this time.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Replaces the OpenPGP keys that have expired with keys with no
expiration date.

[ Other info ]

None.


live well,
  vagrant
diff -Nru guix-1.2.0/debian/changelog guix-1.2.0/debian/changelog
--- guix-1.2.0/debian/changelog 2021-03-27 19:18:29.0 -0700
+++ guix-1.2.0/debian/changelog 2022-12-24 07:16:17.0 -0800
@@ -1,3 +1,11 @@
+guix (1.2.0-4+deb11u1) bullseye; urgency=medium
+
+  [ Santiago Vila ]
+  * debian/patches: Remove expiration dates on openpgp keys used in test
+suite. (Closes: #1011863).
+
+ -- Vagrant Cascadian   Sat, 24 Dec 2022 07:16:17 -0800
+
 guix (1.2.0-4) unstable; urgency=medium
 
   * debian/patches: Fix privilege escalation issue in
diff -Nru guix-1.2.0/debian/patches/series guix-1.2.0/debian/patches/series
--- guix-1.2.0/debian/patches/series2021-03-18 15:14:54.0 -0700
+++ guix-1.2.0/debian/patches/series2022-12-24 06:55:26.0 -0800
@@ -38,3 +38,4 @@
 0028-tests-lint.scm-Disable-several-lint-tests-that-fail-.patch
 0029-tests-swh.scm-Disable-tests-the-fail-with-guile-2.2.patch
 security/daemon-Prevent-privilege-escalation-with-keep-failed.patch
+tests-Ensure-test-OpenPGP-keys-never-expire.patch
diff -Nru 
guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch
--- guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
1969-12-31 16:00:00.0 -0800
+++ guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
2022-12-24 06:55:26.0 -0800
@@ -0,0 +1,55 @@
+From 3ae7632ca0a1edca9d8c3c766efb0dcc8aa5da37 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
+Date: Wed, 18 May 2022 23:20:21 +0200
+Subject: [PATCH] tests: Ensure test OpenPGP keys never expire.
+
+All these keys had expiration dates.  'tests/keys/ed25519.pub' expired
+on 2022-04-24.
+
+Fixes .
+
+* tests/keys/ed25519.pub, tests/keys/ed25519-2.pub,
+tests/keys/ed25519-3.pub: Remove expiration date.
+---
+ tests/keys/ed25519-2.pub | 11 +--
+ tests/keys/ed25519-3.pub | 10 +-
+ tests/keys/ed25519.pub   | 10 +-
+ 3 files changed, 15 insertions(+), 16 deletions(-)
+
+Adjusted to apply to older locations present in 1.3.0.
+
+--- a/tests/ed25519bis.key
 b/tests/ed25519bis.key
+@@ -1,10 +1,9 @@
+ -BEGIN PGP PUBLIC KEY BLOCK-
+ 
+ mDMEXtVsNhYJKwYBBAHaRw8BAQdAnLsYdh3BpeK1xDguJE80XW2/MSmqeeP6pbQw
+-8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IlgQTFggA
+-PhYhBKBDaY1jer75FlruS4IkDtyrgNqDBQJe1Ww2AhsDBQkDwmcABQsJCAcCBhUK
+-CQgLAgQWAgMBAh4BAheAAAoJEIIkDtyrgNqDM6cA/idDdoxo9SU+witdTXt24APH
+-yRzHbX9Iyh4dZNIek9JwAP9E0BwSvDHB4LY9z4RWf2hJp3dm/yZ/jEpK+w4BGN4J
+-Ag==
+-=JIU0
++8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IkAQTFggA
++OAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBKBDaY1jer75FlruS4IkDtyr
++gNqDBQJihWJtAAoJEIIkDtyrgNqDbs0BAPOaGSYf3pX3DReEe1zbxxVQrolX9/AZ
++VP0AOt0TAgkzAP0Sr7G1NuCtjWWGK1WmlyTFPhOWLhNriKgZFkBZrGypAw==
++=pdTB
+ -END PGP PUBLIC KEY BLOCK-
+--- a/tests/ed25519.key
 b/tests/ed25519.key
+@@ -2,9 +2,9 @@
+ 
+ mDMEXqNaoBYJKwYBBAHaRw8BAQdArviKtelb4g0I3zx9xyDS40Oz8i1/LRXqppG6
+ b23Hdim0KEVkIFR3by1GaWZ0eSA8bHVkbyt0ZXN0LWVjY0BjaGJvdWliLm9yZz6I
+-lgQTFggAPhYhBETTHiGvcTj5tjIoCncfScv6rgctBQJeo1qgAhsDBQkDwmcABQsJ
+-CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHcfScv6rgctq4MA/1R9G0roEwrHwmTd
+-DHxt211eLqupwXE0Z7xY2FH6DHk9AP4owEefBU7jQprSAzBS+c6gdS3SCCKKqAh6
+-ToZ4LmbKAw==
+-=FXMK
++kAQTFggAOAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBETTHiGvcTj5tjIo
++CncfScv6rgctBQJihWH6AAoJEHcfScv6rgctfPMBAPv+yPmEgM+J6D1nZjXsO4zW
+++4e3y2Ez+QxgI2tn8Z2xAQDBUWyyu0X+8dguGmVlsaiQdkazaUSpexvIhh9zONYw
++Bg==
++=s4Vp
+ -END PGP PUBLIC KEY BLOCK-


signature.asc
Description: PGP signature

Bug#1026944: upstream homepage returns 404

[Lee Garrett]

Package: ksmtuned
Version: broken link to upstream homepage
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

d/control points to https://git.centos.org/summary/rpms!qemu-kvm, which returns
404. I tried finding the new upstream homepage, but a quick google search didn't
find it.

Regards,
Lee

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

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

Versions of packages ksmtuned depends on:
ii  libc6  2.31-13+deb11u5

Versions of packages ksmtuned recommends:
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11+deb11u2

ksmtuned suggests no packages.

Bug#1026943: ITP: constellations -- mutations for the SARS-CoV-2 virus

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: constellations -- mutations for the SARS-CoV-2 virus
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: constellations
  Version : 0.1.10
  Upstream Author : Andrew Rambaut, Rachel Colquhoun,  Áine O'Toole,
* URL : https://github.com/cov-lineages/constellations
* License : GPL-3
  Programming Lang: Python
  Description : mutations for the SARS-CoV-2 virus
 Descriptions of constellations of mutations for the SARS-CoV-2 virus.
 .
 A constellation is a collection of mutations which are functionally
 meaningful, but which may arise independently a number of times.
 .
 Included are files that define:
 .
   * lineages of concern - for these lineages, the defining mutations
 have been extracted so that individual sequences can be classified
 deterministically
   * genomically interesting regions e.g. RBD sites which interact with
 ACE2
 .
 In addition we include a JSON file describing the reference sequence and
 the coordinates of genes/proteins. Mutations can therefore be described
 with respect to the amino acid position within these features.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/constellations

Bug#1026942: ITP: hut -- A CLI tool for sr.ht

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block -1 by 1023210

* Package name: hut
  Version : 0.2.0-1
  Upstream Author : Simon Ser 
* URL : https://sr.ht/~emersion/hut/
* License : AGPL-3.0-only
  Programming Lang: Go
  Description : A CLI tool for sr.ht

hut is a command line tool to interact with the sr.ht code forge (aka
SourceHut). hut uses the GraphQL APIs to interact with the various
sr.ht services.


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Gervase]

Hi Joseph.

The last paragraph of this e-mail is specifically addressed to you, but
most of this e-mail is addressed generally.

Also, apologies if this message is a bit rushed.  I have a few things to
do today.

> I have yet to investigate intrigeri's suggestions from 2017,

I was planning to try out intrigeri's solution on a VM but have not had
the chance to do this.

> however I would suggest that this is something that needs to be
> upgraded from wishlist in 2022, and here's the reason simply enough:
> 
> root@aki:~# nvme smart-log /dev/nvme0
> Smart Log for NVME device:nvme0 namespace-id:
> [..]
> unsafe_shutdowns  : 106
> [..]
> num_err_log_entries   : 284
> [..]
> root@aki:~# nvme smart-log /dev/nvme1
> Smart Log for NVME device:nvme1 namespace-id:
> [..]
> unsafe_shutdowns  : 121
> [..]
> num_err_log_entries   : 291
> [..]

I agree that this should be higher than wishlist for the above reason
plus Lukas's ZFS shutdown problem mentioned in the initial
description/submission of this bug.

This really should be fixed for Bookworm.

Awhile back, I did have a look around the fix.  From what I remembered,
intrigeri's solution used a systemd shutdown 'script' to check for
devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
commands to umount the partitions.

However, I think my memory may be bad because I "now" don't see evidence
of such umounts in intrigeri's solution!

I would like to try things out today but maybe too rushed.

Jo, have you been able to try out intrigeri's solution (in GENERAL as
opposed to his specific patch/fix, which is mentioned in this bug report
and may have bits missing)?  The reason I say this is because you would
have the exact recreation steps and be able to do it easily.  For me, it
would be a shot in the dark or awkward for me to recreate.  I would only
be able to check that root LVM on LUKS would not cause any untoward
problems.

Thanks,
Gervase.

Bug#1026941: ITP: scorpio -- serious constellations of reoccurring phylogenetically-independent origin

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: scorpio -- serious constellations of reoccurring 
phylogenetically-independent origin
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: scorpio
  Version : 0.3.17
  Upstream Author : Rachel Colquhoun, Áine O'Toole, Andrew Rambaut, Ben Jackson 
* URL : https://github.com/cov-lineages/scorpio
* License : GPL-3
  Programming Lang: Python
  Description : serious constellations of reoccurring 
phylogenetically-independent origin
 Scorpio is a tool that is used by pangolin to deal with sets of 
lineage-defining
 constellations of reoccurring phylogenetically-independent origin.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/scorpio

Bug#1026940: ITP: pangolin-data -- data for pangolin assignments

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: pangolin-data -- data for pangolin assignments
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: pangolin-data
  Version : 1.17
  Upstream Author : Áine O'Toole, Angie Hinrichs, Rachel Colquhoun 
* URL : https://github.com/cov-lineages/pangolin-data
* License : GPL-3
  Programming Lang: Python
  Description : data for pangolin assignments
 Repository for storing latest Pangolin model, protobuf, designation
 hash and alias files for pangolin assignments.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pangolin-data

Bug#1025698: fails to add windows boot loader entry to menu

[Bernhard Übelacker]

I upgraded from 2.04-20 to 2.06-7, and after rebooting I discovered
that I could no longer boot my Windows partition.

Downgrading back to 2.04-20 solved this, so only the grub packages
are causing this.

The whole os-prober section is omitted with 2.06-7. This is what
should be there (diff between working and new version):



Hello Paul,
is this issue what the NEWS [1] file notifies about,
to check the need of GRUB_DISABLE_OS_PROBER?

[1] https://sources.debian.org/src/grub2/2.06-7/debian/NEWS/

Kind regards,
Bernhard

Bug#1026857: Installation media not bootable for architecture ppc64el on Tyan TN71-BP012

[oliviosu_ppc64el]

Hello Steve,

No special setup installed on the system,
but searching for the kernel command line used to boot,
find that on disk boot command line use boot=UUID= ... ro quiet
with Kernel and init.rd
So I try to boot media with adding petitboot entry:
selecting : /dev/sdb (the USB device)
Kernel: /install/vmlinux
Initrd: /install/initrd.gz
Boot arguments: root=/dev/sdb/ ro quiet

And it work fine,
I'm sorry didn't find it before by-myself.

It worked for Debian 10 without root device,
since Debian 11 it's needed

I'll get new SSD and will make installation report,
for 11.6 and bookworm

Thanks lot for your help,
Best regards
Olivier

Bug#1024086: [Pkg-rust-maintainers] Bug#1024086: rust-zip: please upgrade to v0.6

[Peter Michael Green]

On 15/11/2022 20:52, Peter Green wrote:

Please upgrade to v0.6, needed by projects I am preparing for Debian.


Unfortunately upstream do not seem to provide a changelog.

There seem to be three reverse dependencies, elan, rust-grcov and
rust-coreutils.

And since this message was written, more reverse dependencies have
appears, rust-tealdear and sccache.

Anyway I've now prepared an updated rust-zip package, uploaded it
to experimental and gone through the reverse dependencies, status
is as follows.

elan - needs code changes, I've made a patch but ideally i'd like
feedback from upstream and/or from the package's maintainer
in debian.

rust-coreutils - no changes needed

rust-grcov - needs hunk removing from dependency patch

tealdeer - needs dependency patch (or update, but I had other issues 
trying to update), no code changes needed


sccache - needs dependency change in Debian packaging.

Bug#1026939: python3-exceptiongroup: Please upgrade

[Matthias Urlichs]

Package: python3-exceptiongroup
Version: 1.0.4-4
Severity: important
X-Debbugs-Cc: sm...@smurf.noris.de

Upstream is at 1.1 and some packages require it.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'oldstable'), (500, 
'stable-security'), (500, 'unstable'), (450, 'focal'), (350, 'oldoldstable'), 
(300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-exceptiongroup depends on:
ii  python3  3.10.6-1

python3-exceptiongroup recommends no packages.

python3-exceptiongroup suggests no packages.

-- debconf-show failed

Bug#1026918: dgit: shows warnings if debian/source/include-binaries mentions files in debian/

[Simon McVittie]

On Sat, 24 Dec 2022 at 01:15:15 +, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1026918: dgit: shows warnings if 
> debian/source/include-binaries mentions files in debian/"):
> > According to dpkg-source(1), all non-text files in a 3.0 (quilt) package[1]
> > need to be listed in debian/source/include-binaries, whether they're
> > additions to the upstream source or part of the debian/ directory
> 
> I don't think this behaviour by dpkg-source serves any
> kind of purpose (if indeed it still does this thing)

The only purpose I can think of is that it's a safety-catch against
the maintainer accidentally including built binaries, vim swapfiles
and other binary detritus in the source package, which seems a lot
less likely to happen anyway with a package that's maintained in a VCS,
particularly with dgit and `gbp buildpackage --git-export-dir` providing
two orthogonal methods to ensure we're working with a clean git tree -
but I've seen such files added by mistake by an overzealous `git add`,
so perhaps there is still value in having that safety-catch.

smcv

Bug#1024218: apitrace: diff for NMU version 11.1+repack-1.1

[Sebastian Ramacher]

Control: tags 1024218 + patch
Control: tags 1024218 + pending

Dear maintainer,

I've prepared an NMU for apitrace (versioned as 11.1+repack-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru apitrace-11.1+repack/debian/changelog apitrace-11.1+repack/debian/changelog
--- apitrace-11.1+repack/debian/changelog	2022-05-25 15:54:07.0 +0200
+++ apitrace-11.1+repack/debian/changelog	2022-12-24 13:13:35.0 +0100
@@ -1,3 +1,10 @@
+apitrace (11.1+repack-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/: Switch to libproc2-dev (Closes: #1024218)
+
+ -- Sebastian Ramacher   Sat, 24 Dec 2022 13:13:35 +0100
+
 apitrace (11.1+repack-1) unstable; urgency=medium
 
   [ David Heidelberg ]
diff -Nru apitrace-11.1+repack/debian/control apitrace-11.1+repack/debian/control
--- apitrace-11.1+repack/debian/control	2022-05-25 15:54:07.0 +0200
+++ apitrace-11.1+repack/debian/control	2022-12-24 13:13:25.0 +0100
@@ -19,7 +19,7 @@
  libsnappy-dev,
  libpng-dev,
  libbsd-dev,
- libprocps-dev,
+ libproc2-dev,
  libgtest-dev,
 Standards-Version: 4.6.0
 Homepage: https://apitrace.github.io
diff -Nru apitrace-11.1+repack/debian/patches/libproc-2.patch apitrace-11.1+repack/debian/patches/libproc-2.patch
--- apitrace-11.1+repack/debian/patches/libproc-2.patch	1970-01-01 01:00:00.0 +0100
+++ apitrace-11.1+repack/debian/patches/libproc-2.patch	2022-12-24 13:13:35.0 +0100
@@ -0,0 +1,88 @@
+Description: Build for libproc2
+ Replace libprocps with libproc2
+Author: Craig Small 
+Reviewed-by: Craig Small 
+Last-Update: 2022-11-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: apitrace-11.1+repack/lib/os/os_memory.hpp
+===
+--- apitrace-11.1+repack.orig/lib/os/os_memory.hpp
 apitrace-11.1+repack/lib/os/os_memory.hpp
+@@ -30,13 +30,46 @@
+ 
+ #pragma once
+ 
+-#ifdef HAVE_READPROC_H
++#ifdef HAVE_LIBPROC2_PIDS_H
++#include 
++#elif defined(HAVE_READPROC_H)
+ #include 
+ #endif
+ 
+ namespace os {
+ 
+-#if defined(HAVE_READPROC_H)
++#ifdef HAVE_LIBPROC2_PIDS_H
++inline long long
++getVsize(void) {
++enum pids_item Item[] = {PIDS_VSIZE_BYTES};
++struct pids_info *info = NULL;
++struct pids_stack *stack;
++unsigned long value=0;
++if (
++(procps_pids_new(, Item, 1) == 0) &&
++((stack = fatal_proc_unmounted(info, 1)) == NULL)) {
++value = PIDS_VAL(0, ul_int, stack, info);
++}
++procps_pids_unref();
++return value;
++}
++
++inline long long
++getRss(void) {
++enum pids_item Item[] = {PIDS_RSS};
++struct pids_info *info = NULL;
++struct pids_stack *stack;
++unsigned long value=0;
++if (
++(procps_pids_new(, Item, 1) == 0) &&
++((stack = fatal_proc_unmounted(info, 1)) == NULL)) {
++value = PIDS_VAL(0, ul_int, stack, info);
++}
++procps_pids_unref();
++return value;
++}
++
++#elif defined(HAVE_READPROC_H)
+ 
+ inline long long
+ getVsize(void) {
+Index: apitrace-11.1+repack/CMakeLists.txt
+===
+--- apitrace-11.1+repack.orig/CMakeLists.txt
 apitrace-11.1+repack/CMakeLists.txt
+@@ -490,6 +490,10 @@ if (NOT WIN32 AND NOT ENABLE_STATIC_EXE)
+ if (PKG_CONFIG_FOUND)
+ pkg_check_modules (BROTLIDEC IMPORTED_TARGET libbrotlidec>=1.0.7)
+ pkg_check_modules (BROTLIENC IMPORTED_TARGET libbrotlienc>=1.0.7)
++pkg_check_modules (LIBPROC2 IMPORTED_TARGET libproc2)
++if (LIBPROC2_FOUND)
++add_definitions (-DHAVE_LIBPROC2_PIDS_H)
++endif ()
+ endif ()
+ 
+ find_package (GTest)
+Index: apitrace-11.1+repack/lib/os/CMakeLists.txt
+===
+--- apitrace-11.1+repack.orig/lib/os/CMakeLists.txt
 apitrace-11.1+repack/lib/os/CMakeLists.txt
+@@ -38,3 +38,8 @@ if (BUILD_TESTING)
+ add_gtest (os_thread_test os_thread_test.cpp)
+ target_link_libraries (os_thread_test os)
+ endif ()
++
++if (LIBPROC2_FOUND)
++target_link_libraries(os PUBLIC PkgConfig::LIBPROC2)
++endif ()
++
diff -Nru apitrace-11.1+repack/debian/patches/series apitrace-11.1+repack/debian/patches/series
--- apitrace-11.1+repack/debian/patches/series	2022-05-25 15:54:07.0 +0200
+++ apitrace-11.1+repack/debian/patches/series	2022-12-24 13:13:18.0 +0100
@@ -4,3 +4,4 @@
 highlight.py-fix1.patch
 highlight.py-fix2.patch
 disable-submodule-check.patch
+libproc-2.patch

Bug#1016737: Loop in POST when using --removable option in grub-install

[Pascal Hambourg]

Hello,

I observe the same behaviour on my laptop.
My workaround is to remove EFI/BOOT/fbx64.efi from the EFI partition.
IMO --removable should not install this file.

Bug#1026938: i2pd: FTBFS on riscv64 (undefined reference to `__atomic_exchange_1')

[Eric Long]

Source: i2pd
Version: 2.43.0-1
Severity: serious
Tags: ftbfs patch upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer(s),

i2pd failed to build on riscv64 due to not linking to libatomic:

```
[100%] Linking CXX executable i2pd
/usr/bin/cmake -E cmake_link_script CMakeFiles/i2pd.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O3 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Winvalid-pch 
-Wno-unused-parameter -std=c++17 -pipe -fPIC -Wl,-z,relro -Wl,-z,now 
"CMakeFiles/i2pd.dir/<>/daemon/Daemon.cpp.o" 
"CMakeFiles/i2pd.dir/<>/daemon/HTTPServer.cpp.o" 
"CMakeFiles/i2pd.dir/<>/daemon/I2PControl.cpp.o" 
"CMakeFiles/i2pd.dir/<>/daemon/i2pd.cpp.o" 
"CMakeFiles/i2pd.dir/<>/daemon/UPnP.cpp.o" 
"CMakeFiles/i2pd.dir/<>/daemon/UnixDaemon.cpp.o" -o i2pd  
libi2pd.a libi2pdclient.a libi2pdlang.a 
/usr/lib/riscv64-linux-gnu/libboost_system.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_filesystem.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_program_options.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_date_time.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libssl.so /usr/lib/riscv64-linux-gnu/libcrypto.so 
/usr/lib/riscv64-linux-gnu/libminiupnpc.so /usr/lib/riscv64-linux-gnu/libz.so 
/usr/bin/ld: libi2pdclient.a(HTTPProxy.cpp.o): in function 
`std::__exception_ptr::exception_ptr::~exception_ptr()':
/usr/include/c++/12/bits/exception_ptr.h:200: undefined reference to 
`__atomic_exchange_1'
/usr/bin/ld: libi2pdclient.a(HTTPProxy.cpp.o): in function 
`std::__new_allocator::deallocate(char*, unsigned long)':
/usr/include/c++/12/bits/new_allocator.h:158: undefined reference to 
`__atomic_exchange_1'
/usr/bin/ld: libi2pdclient.a(I2PService.cpp.o): in function 
`i2p::client::TCPIPPipe::Terminate()':
./obj-riscv64-linux-gnu/./libi2pd_client/I2PService.cpp:170: undefined 
reference to `__atomic_exchange_1'
/usr/bin/ld: libi2pdclient.a(I2PService.cpp.o): in function 
`__gnu_cxx::__atomic_add_single(int*, int)':
/usr/include/c++/12/ext/atomicity.h:92: undefined reference to 
`__atomic_exchange_1'
/usr/bin/ld: libi2pdclient.a(I2PService.cpp.o): in function 
`std::__shared_count<(__gnu_cxx::_Lock_policy)1>::__shared_count(std::__shared_count<(__gnu_cxx::_Lock_policy)1>
 const&)':
/usr/include/c++/12/bits/shared_ptr_base.h:1075: undefined reference to 
`__atomic_exchange_1'
/usr/bin/ld: 
libi2pdclient.a(I2PService.cpp.o):/usr/include/c++/12/ext/atomicity.h:111: more 
undefined references to `__atomic_exchange_1' follow
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/i2pd.dir/build.make:191: i2pd] Error 1
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=i2pd=riscv64=2.43.0-1=1669692730=0

I've attached a patch that replaces CheckAtomic.cmake with the newer LLVM ones.
This is also submitted upstream [1]. If more help is needed, please let me know.

Cheers,
Eric

[1]: https://github.com/PurpleI2P/i2pd/pull/1828
--- a/build/cmake_modules/CheckAtomic.cmake
+++ b/build/cmake_modules/CheckAtomic.cmake
@@ -1,18 +1,23 @@
 # atomic builtins are required for threading support.
 
 INCLUDE(CheckCXXSourceCompiles)
+INCLUDE(CheckLibraryExists)
 
 # Sometimes linking against libatomic is required for atomic ops, if
 # the platform doesn't support lock-free atomics.
 
 function(check_working_cxx_atomics varname)
   set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
-  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++11")
   CHECK_CXX_SOURCE_COMPILES("
 #include 
 std::atomic x;
+std::atomic y;
+std::atomic z;
 int main() {
-  return x;
+  ++z;
+  ++y;
+  return ++x;
 }
 " ${varname})
   set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
@@ -27,6 +32,7 @@
 std::atomic x (0);
 int main() {
   uint64_t i = x.load(std::memory_order_relaxed);
+  (void)i;
   return 0;
 }
 " ${varname})
@@ -34,15 +40,16 @@
 endfunction(check_working_cxx_atomics64)
 
 
-# This isn't necessary on MSVC, so avoid command-line switch annoyance
-# by only running on GCC-like hosts.
-if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
+# Check for (non-64-bit) atomic operations.
+if(MSVC)
+  set(HAVE_CXX_ATOMICS_WITHOUT_LIB True)
+else()
   # First check if atomics work without the library.
   check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
   # If not, check if the library exists, and atomics work with it.
   if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
 check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
-if( HAVE_LIBATOMIC )
+if(HAVE_LIBATOMIC)
   list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
   check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
   if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
@@ -58,21 +65,34 @@
 if(MSVC)
   set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True)
 else()
+  # First check if atomics work without the library.
   check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)

Bug#1024859: cctbx: (autopkgtest) needs update for python3.11: initialization of scitbx_linalg_ext raised unreported exception

[Graham Inggs]

Control: tags -1 + ftbfs

With #1025658 fixed in boost1.74, the autopkgtest of cctbx now fails as follows:

Testing dxtbx with python3.10:
= test session starts ==
platform linux -- Python 3.10.9, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /tmp/autopkgtest-lxc.1endj91b/downtmp/autopkgtest_tmp
plugins: mock-3.8.2, dials-data-2.4.0
collected 745 items / 2 skipped

tests/test_FormatCBFFull.py ss   [  0%]
tests/test_beam.py . [  0%]
tests/test_beamline_definitions.py ..[  0%]
tests/test_compression.py .  [  0%]
tests/test_crystal_model_equivalence.py .[  0%]
tests/test_datablock.py ss   [  1%]
tests/test_dataset_as_flex.py Fatal Python error: Segmentation fault


I suspected a rebuild might solve this, but cctbx now FTBFS with:

Processing: "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/scitbx/libtbx_refresh.py"
  Generating C++ header files in:

"/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/.pybuild/cpython3_3.11/build_/include/scitbx/array_family"
  Generating C++ files in:

"/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/.pybuild/cpython3_3.11/build_/include/scitbx/array_family/boost_python"
  Using fable to convert scitbx/lbfgs.f
Updating entry points for scitbx
  1 entries for entry point pytest_randomly.random_seeder
Traceback (most recent call last):
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/configure.py",
line 34, in 
if not run():
   ^
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/configure.py",
line 29, in run
libtbx.env_config.cold_start(sys.argv)
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/env_config.py",
line 3042, in cold_start
env.refresh()
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/env_config.py",
line 2264, in refresh
module.process_libtbx_refresh_py()
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/env_config.py",
line 2585, in process_libtbx_refresh_py
exec(to_str(fh.read()), global_vars)
  File "", line 25, in 
  File "/build/1st/cctbx-2022.9+ds2+~3.11.2+ds1/libtbx/pkg_utils.py",
line 242, in define_entry_points
setuptools.setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
86, in setup
_install_setup_requires(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
78, in _install_setup_requires
dist.parse_config_files(ignore_option_errors=True)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 862,
in parse_config_files
self._parse_config_files(filenames=inifiles)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 704,
in _parse_config_files
filenames = self.find_config_files()

  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py",
line 337, in find_config_files
files = [str(path) for path in self._gen_paths() if os.path.isfile(path)]
^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py",
line 337, in 
files = [str(path) for path in self._gen_paths() if os.path.isfile(path)]
^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py",
line 346, in _gen_paths
sys_dir = pathlib.Path(sys.modules['distutils'].__file__).parent
   ~~~^
KeyError: 'distutils'

Bug#1019380: UDD: import ports.d.o data to ports tables instead of derivatives tables

[Lucas Nussbaum]

Control: close -1

On 24/12/22 at 16:58 +0800, Paul Wise wrote:
> Control: reopen -1
> 
> On Sat, 2022-12-24 at 09:04 +0100, Lucas Nussbaum wrote:
> 
> > OK, I imported ports to ports_* tables.
> 
> Thanks, but they don't appear to have any data yet and
> the derivatives tables still have ports data in them.
> 
> https://qa.debian.org/cgi-bin/madison.cgi?package=chromium-bsu=ports===#
> https://qa.debian.org/cgi-bin/madison.cgi?package=chromium-bsu=derivatives===#
> 
> pabs@quantz:~$ PAGER=cat psql service=udd
> psql (11.18 (Debian 11.18-0+deb10u1), server 13.9 (Debian 13.9-0+deb11u1))
> WARNING: psql major version 11, server major version 13.
>  Some psql features might not work.
> SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, 
> compression: off)
> Type "help" for help.
> 
> udd=> select * from ports_sources limit 1;
>  source | version | maintainer | maintainer_name | maintainer_email | format 
> | files | uploaders | bin | architecture | standards_version | homepage | 
> build_depends | build_depends_indep | build_conflicts | build_conflicts_indep 
> | priority | section | distribution | release | component | vcs_type | 
> vcs_url | vcs_browser | python_version | ruby_versions | checksums_sha1 | 
> checksums_sha256 | original_maintainer | dm_upload_allowed | testsuite | 
> autobuild | extra_source_only | build_depends_arch | build_conflicts_arch 
> +-++-+--++---+---+-+--+---+--+---+-+-+---+--+-+--+-+---+--+-+-++---++--+-+---+---+---+---++--
> (0 rows)
> 
> > I'm closing this bug, assuming you will track the rmadison change in a
> > separate one.
> 
> I've added the ports table to madison.cgi:
> 
> https://salsa.debian.org/qa/qa/commit/09765f3fa5b7a26c90c82f005593385afbe2220e
> 
> Once the above issue is resolved I'll fix rmadison in devscripts.

It's OK now (and I cleaned up derivatives_* as well). I was a bit too
optimistic about the importer finishing, while it was stuck in a
transactionn.

Lucas

Bug#1024219: cpu-x: diff for NMU version 4.5.1-1.1

[Sebastian Ramacher]

Control: tags 1024219 + patch
Control: tags 1024219 + pending

Dear maintainer,

I've prepared an NMU for cpu-x (versioned as 4.5.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru cpu-x-4.5.1/debian/changelog cpu-x-4.5.1/debian/changelog
--- cpu-x-4.5.1/debian/changelog	2022-10-26 21:55:18.0 +0200
+++ cpu-x-4.5.1/debian/changelog	2022-12-24 13:03:04.0 +0100
@@ -1,3 +1,12 @@
+cpu-x (4.5.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Apply upstream patch to fix build with procps 4 (Closes:
+#1024219)
+  * debian/control: Change libprocps-dev to libproc2-dev.
+
+ -- Sebastian Ramacher   Sat, 24 Dec 2022 13:03:04 +0100
+
 cpu-x (4.5.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru cpu-x-4.5.1/debian/control cpu-x-4.5.1/debian/control
--- cpu-x-4.5.1/debian/control	2022-10-21 09:59:15.0 +0200
+++ cpu-x-4.5.1/debian/control	2022-12-24 13:03:01.0 +0100
@@ -15,7 +15,7 @@
libjson-c-dev,
libncurses-dev,
libpci-dev,
-   libprocps-dev,
+   libproc2-dev,
libstatgrab-dev,
nasm,
pkg-config,
diff -Nru cpu-x-4.5.1/debian/patches/2765e68dc4650b7306255e0c10056508d5ab44f8.patch cpu-x-4.5.1/debian/patches/2765e68dc4650b7306255e0c10056508d5ab44f8.patch
--- cpu-x-4.5.1/debian/patches/2765e68dc4650b7306255e0c10056508d5ab44f8.patch	1970-01-01 01:00:00.0 +0100
+++ cpu-x-4.5.1/debian/patches/2765e68dc4650b7306255e0c10056508d5ab44f8.patch	2022-12-24 13:01:52.0 +0100
@@ -0,0 +1,39 @@
+From 2765e68dc4650b7306255e0c10056508d5ab44f8 Mon Sep 17 00:00:00 2001
+From: Xorg 
+Date: Tue, 25 Oct 2022 23:52:53 +0200
+Subject: [PATCH] Update for procps-ng 4.0.1rc3
+
+https://gitlab.com/procps-ng/procps/-/issues/239#note_1145660376
+---
+ src/CMakeLists.txt | 2 +-
+ src/core.c | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index 3d9e8394..3e00af35 100644
+--- a/src/CMakeLists.txt
 b/src/CMakeLists.txt
+@@ -97,7 +97,7 @@ endif(WITH_OPENCL)
+ set(LIBSYSTEM 0)
+ set(LIBPROC2 -1)
+ if(WITH_LIBPROCPS AND ${CMAKE_SYSTEM_NAME} MATCHES "Linux" AND NOT FORCE_LIBSTATGRAB)
+-	pkg_check_modules(LIBPROC2 libproc-2)
++	pkg_check_modules(LIBPROC2 libproc2)
+ 	if(LIBPROC2_FOUND)
+ 		include_directories(${LIBPROC2_INCLUDE_DIRS})
+ 		link_directories(${LIBPROC2_LIBRARY_DIRS})
+diff --git a/src/core.c b/src/core.c
+index 54a785b9..663a83fb 100644
+--- a/src/core.c
 b/src/core.c
+@@ -60,8 +60,8 @@
+ #endif
+ 
+ #if HAS_LIBPROC2
+-# include 
+-# include 
++# include 
++# include 
+ #endif
+ 
+ #if HAS_LIBPROCPS
diff -Nru cpu-x-4.5.1/debian/patches/series cpu-x-4.5.1/debian/patches/series
--- cpu-x-4.5.1/debian/patches/series	2022-10-21 14:01:55.0 +0200
+++ cpu-x-4.5.1/debian/patches/series	2022-12-24 13:02:05.0 +0100
@@ -1,3 +1,4 @@
 2001_build-with-PIE.patch
 2002_avoid-format-security-compiler-flag.patch
 1001_typo-fix.patch
+2765e68dc4650b7306255e0c10056508d5ab44f8.patch

Bug#1025329: bullseye-pu: package cwltool/3.0.20210124104916-3+deb11u1

[Adam D. Barratt]

On Fri, 2022-12-02 at 16:33 +0100, Michael R. Crusoe wrote:
> cwltool is not usable without the python3-distutils package also
> installed. This is rare, but can happen on fresh Debian installs.
> 
> I discovered this today while testing instructions for WSL2 users.
> 
> The cwltool version in unstable/testing does not have this problem.
> 

FWIW, the metadata for #1025327 disagrees. Assuming that newer versions
aren't affected, please add an appropriate fixed version so that the
BTS knows that.

Regards,

Adam

Bug#1026937: python3-grpcio: ImportError: undefined symbol: _ZN4absl7debian313hash_internal15MixingHashState5kSeedE

[Sebastian Ramacher]

Package: python3-grpcio
Version: 1.51.1-2
Severity: serious

The Python modules included in python3-grpcio are underlinked and cannot
be imported:

>>> import grpc
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/grpc/__init__.py", line 22, in 
from grpc import _compression
  File "/usr/lib/python3/dist-packages/grpc/_compression.py", line 20, in 

from grpc._cython import cygrpc
ImportError: 
/usr/lib/python3/dist-packages/grpc/_cython/cygrpc.cpython-310-x86_64-linux-gnu.so:
 undefined symbol: _ZN4absl7debian313hash_internal15MixingHashState5kSeedE

This issue causes autopkgtest regressions for python-tooz.

Cheers
-- 
Sebastian Ramacher

Bug#1026936: davmail-server: trying to overwrite '/etc/davmail/davmail.properties', which is also in package davmail

[gregor herrmann]

Package: davmail-server
Version: 6.0.1.3390-2
Severity: serious
Justification: fails to install

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When updating davmail from 6.0.1.3390-1.1 to 6.0.1.3390-2,
davmail-server is pulled in as a new dependency, and it fails to
install:

Preparing to unpack .../davmail-server_6.0.1.3390-2_all.deb ...
Unpacking davmail-server (6.0.1.3390-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/davmail-server_6.0.1.3390-2_all.deb (--unpack):
 trying to overwrite '/etc/davmail/davmail.properties', which is also in 
package davmail 6.0.1.3390-1.1


Cheers,
gregor


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages davmail-server depends on:
ii  adduser   3.129
ii  default-jre-headless [java9-runtime-headless] 2:1.17-73
hi  init-system-helpers   1.64
ii  libcommons-codec-java 1.15-1
ii  libcommons-logging-java   1.2-3
ii  libhtmlcleaner-java   2.26-1
ii  libhttpclient-java4.5.14-1
ii  libjackrabbit-java2.20.3-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.5.1-1
ii  libjna-java   5.12.1-1
ii  liblog4j1.2-java  1.2.17-11
ii  libmail-java  1.6.5-1
ii  libslf4j-java 1.7.32-1
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.21.0-1
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.17+8-2
ii  openjdk-17-jre-headless [java9-runtime-headless]  17.0.5+8-2
ii  sysvinit-utils [lsb-base] 3.06-2

davmail-server recommends no packages.

davmail-server suggests no packages.

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmOm47JfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qga1rw/+NMw8fcQDIYDtlJh9TMjfdnJwmLb3DYtliWPWbdeJSqihIzjI+AP8vYtk
AXmYYfovDLqwhK4X94wPOz35VJFQQsVcDnx2LCEgg6z0hUJz2a9wJX49ErgIi2qt
ZlJekxIfNgFm9FSkcEhUyR6NtVznWBHCti5vYlqDhZymx6gmMpJTGElEb/8Yu96r
ehIyDdgGo4IrcRyz8+yxCOh8K2RcDV8PKKr5muQueqTApJ1QF2e6ZOK3uvHt6V0R
y9rj6Ejk7eA4PS37FK3wOj5mbB7/ZLLtWP4sihZ3uZ6BCr/Pl4dVk23WpNGkNbbI
nTmmriW5nlaIezlIw7X3d2aPC9t0UetInWSNQrg4YSuOvsdMCL4InRjM1lKX7PNB
fTcuUXaMwuVLi3Z05OxMU0v1UOqL+kL7GppMJyFLxeRggFhMGNCMYvsI88AcLeZm
9Ck8y8l7hxionXoyGwZc8ZB1Cm2jjiPWEb7sJ84OqYaG2HlXWdk5ec1uHUFrTFpe
waBU6go7U9pq17l33kpNIONFf5SApyvv/fqiXTiLXa8P6xCyP3xJ2I9z3M8IBP40
lyzF2ETwiyCT/+53B39ZuejJQDYt5GioiG0X5F8kWZGDzh03M8J+dVRlsMCRP92s
UtzaPeY7YrfXRAaoBPJaJTLk3LYAWp3JMOXGD/y2p5KTGik+t64=
=Xdst
-END PGP SIGNATURE-

Bug#1026877: Salsa reprotest CI not picky enough? (Was: Bug#1026877: opari2: please make the build reproducible)

[Samuel Thibault]

Hello,

Vagrant Cascadian, le ven. 23 déc. 2022 16:01:48 -0800, a ecrit:
> The example for the salsa-ci suggests that build paths variations are
> enabled by default under the "Adding extra arguments to reprotest":
> 
>   
> https://salsa.debian.org/salsa-ci-team/pipeline/-/tree/master#adding-extra-arguments-to-reprotest
> 
>   variables:
> SALSA_CI_REPROTEST_ARGS: --variations=-build_path
> 
> You could try inverting it, and passing --variations=+build_path

That seems to be working indeed:

https://salsa.debian.org/debian/opari2/-/jobs/3702025

I let the reproducibility team discuss with CI about really having
--variations=+all enabled by default :)

Samuel

Bug#1025997: libqt5core5a: Qt applications sometimes crashing at display configuration changes or power savings

[Bernhard Übelacker]

On Tue, 13 Dec 2022 01:28:39 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:


Dear Maintainer,
I experienced since about a month ago sometimes crashes in applications
running in fullscreen, when doing display configuration changes
or lately when waking up the screen from power saving.
(See below for an example backtrace.)

I opened these upstream bug reports, where the
Qt bug received a patch hopefully fixing this issue:

   https://bugs.kde.org/show_bug.cgi?id=461723
   https://bugreports.qt.io/browse/QTBUG-109226
   
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=6a3627b6c5aa5109a80024f3d7b0f938504f7ffe
   (Unfortunately it looks like the qt-5.15 cerry-pick is not publicly visible.)

I create this bug also to ask how chances are that this
commit reaches Qt before or during the freeze period?

Kind regards,
Bernhard


I forgot to mention, this might also be related to a dual monitor setup.
With "power savings" is meant just the monitors turning off.

Short after opening this bug the Qt "Gerrit Bot" added the information
the fixed upstream version seems to be 5.15.12.

And reading up release plans [1] I think 5.15.12 is way out of reach,
therefore the next option might be picking the patch into the
packaged by Debian version 5.15.7, depending if there arrive other
reports about this issue.

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

Kind regards,
Bernhard

Bug#1026935: Missing emacsen compat file

[Takeshi Soejima]

Package: emacs-calfw
Version: 1.6+git20180118-1.1

Dear Maintainer,

While installing this package on bullseye (emacs 1:27.1+1-3.1),
I met the following error (though the functionaliy seems fine).

  Performing actions...
  Selecting previously unselected package emacs-calfw.
  (Reading database ... 325957 files and directories currently installed.)
  Preparing to unpack .../emacs-calfw_1.6+git20180118-1.1_all.deb ...
  Unpacking emacs-calfw (1.6+git20180118-1.1) ...
  Setting up emacs-calfw (1.6+git20180118-1.1) ...
  ERROR: emacs-calfw is broken - called emacs-package-install as a new-style 
add-on, but has no compat file.
  Install emacs-calfw for emacs
  Install emacs-calfw for emacs

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Adam Borowski]

On Sat, Nov 19, 2022 at 11:29:15PM +0100, Christoph Anton Mitterer wrote:
> Hey Jonas :-)

Jonas, ping: any chance of uploading this?

> On Thu, 2022-11-17 at 18:45 +0100, Jonas Smedegaard wrote:
> > What helps the most, and also seems possibly, is to name it
> > "delta" - just not right now - and with that long-term plan I think
> > it
> > is double confusing to introduce a _third_ name (since the name
> > "git-delta" has already been introduced by some downstreams).
> 
> Well the best would be if upstream could give another name, but if
> that's unlikely... this might be the best option.

The executable name is free.

> > Oke way you can help is to initiate the process of (attempting to) kick
> > out (or alternatively rename) current package "delta" from Debian.

> I'm not really sure whether I like this either. ;-)
> 
> I had a small look at the current "delta" package, and while the
> package is maintained by the QA group and the upstream website
> (http://delta.tigris.org/) named in the copyright file seems dead...
> the program might be still useful to some people... and it had the name
> first.

Its use is basically mandatory any time you submit a bug to gcc, thus
there's no chance it goes away -- even if indeed no one is stepping up
for full-time maintenance.  It's just code that works well enough, and
doesn't seem to require new upstream updates basically ever.

> Asking them now to rename,... well even if done politely, they may feel
> somehow obligated to do... or even drop the package at all, which I
> think would be bad.

A package rename would take at least a couple of Debian releases, thus
isn't something that works in a reasonable timeframe.

Thus, you'd need to upload as git-delta or such now, then maybe be able
to take over the name in the future...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026934: Package colortbl does not work with dinbrief anymore

[Joey Schulze]

Package: texlive-latex-base
Version: 2020.20210202-3
Severity: normal
X-Debbugs-Cc: j...@infodrom.org

Hi,

I have found an incompatibility between the package colortbl and the
dinbrief documentclass.

The problem sneaked into bullseye and did not exist in buster.  It
seems to be still present in bookwork unfortunately (for verification
i copied both colortbl.sty and dinbrief.cls into the directory
containing the sample LaTeX file).

Please see this minimal LaTeX files to reproduce the problem


This file can be compiled:


\documentclass[11pt]{article}
\usepackage{colortbl}

\begin{document}
foo
\end{document}


This file cannot be compiled:


\documentclass[11pt]{dinbrief}
\usepackage{colortbl}

\begin{document}
foo
\end{document}


Compiling the second file results in this error:


! Undefined control sequence.
\set@color ->\special {color push \current@color 
 }\aftergroup \reset@color 
\@outputpage ...t {\vfil \color@hbox \normalcolor 
  \hb@xt@ \textwidth {\@theh...

\@opcol ...lumn \@outputdblcol \else \@outputpage 
  \fi \global \@mparbottom \...
 ...specialoutput \else \@makecol \@opcol 
  \@startcolumn \@whilesw \i...

\newpage ...prevdepth \fi \fi \vfil \penalty -\@M 
  
\enddocument ->\@checkend {document} \newpage 
  \begingroup \if@filesw \ifnum ...

\end  ...ook {env/#1/end}}\csname end#1\endcsname 
  \@checkend {#1}\expandafte...
l.7 \end{document}


All the best

Joey

Versions of packages texlive-latex-base depends on:
ii  fonts-lmodern 2.004.5-6.1
ii  tex-common6.16
ii  texlive-base  2020.20210202-3
ii  texlive-binaries  2020.20200327.54578-7

texlive-latex-base recommends no packages.

Versions of packages texlive-latex-base suggests:
pn  texlive-latex-base-doc  

Versions of packages tex-common depends on:
ii  dpkg  1.20.12
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.4

Versions of packages texlive-latex-base is related to:
ii  tex-common6.16
ii  texlive-binaries  2020.20200327.54578-7

-- no debconf information

Bug#1026933: Transition Qt 6.4.2

[Patrick Franz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: delta...@debian.org,debian-qt-...@lists.debian.org

Hi Release Team,

we would like to request a transition for Qt 6.4.2.

It is not a huge transition as only the following packages are affected 
by it (if I'm not mistaken):

* calibre
* fcitx-qt5
* fcitx5-qt
* pyqt6
* qbs
* qt6ct
* qtcreator


Now, Qt 6.4.2 has not been released yet, but we have started packaging
and should be finished with it in 1-2 days.
Unfortunately, we don't know yet the exact date yet of the release.
The Qt Company is aware of the transition freeze and would really like
to get Qt 6.4.2 into bookworm, and thus they are trying to get it 
released as soon as possible. Though, it might take until the first
week in January until it is released.


Here is the Ben file:

---
title = "Qt 6.4.2";

is_affected = .depends ~ /qt6-base-abi \(= 6\.3\.1\)/ | .depends ~ 
/qt6-base-abi \(= 6\.4\.2\)/;
is_good = .depends ~ /qt6-base-abi \(= 6\.4\.2\)/;
is_bad = .depends ~ /qt6-base-abi \(= 6\.3\.1\)/;
---

Thank you very much.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Tobias Hansen]

On 12/23/22 12:56, Nilesh Patra wrote:
> On Sat, 10 Dec 2022 18:07:53 +0530 Nilesh Patra  wrote:
>> On Mon, 28 Nov 2022 21:05:07 + Tobias Hansen  wrote:
>>> On 11/27/22 19:24, Nilesh Patra wrote:
 On Sun, Nov 27, 2022 at 05:35:17PM +, Tobias Hansen wrote:
> On 11/27/22 06:37, Nilesh Patra wrote:
>> Tobias, since this is done, would you consider to check sagemath now and 
>> get the ball rolling? :-) 
> Hi,
>
> I actually tried building with the new pari and gap versions a while ago 
> (using sagemath 9.5 with upstream patches for the new pari and gap 
> versions, I pushed them to the git repo today) and got stuck with a lot 
> of errors like this (might be unrelated to pari and gap):
 I am having a hard time building/reproducing this because sage tends to 
 need a lot of compute power that I currently do not have, and it takes 
 forever to porter box too.
 But looking at the error, my hunch is that this is a setuptools related 
 monkeypatch issue (there are similar RC bugs filed for many packages). So 
 re-ordering cython import
 in sage/misc/cython.py file after setuptools along with ensuring distutils 
 is imported after setuptools will (very) likely help.

 Here is a related link that I found for the same


 https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t

>>> Thanks. The attached patch removed the error, but now there are these 
>>> warnings when cython is used in doctests:
>>>
>>> UserWarning: Distutils was imported before Setuptools, but importing 
>>> Setuptools also replaces the `distutils` module in `sys.modules`.
>> 
>>
>> Apologies for late response. I suppose the line above is the crux? 
>> setuptools monkey-patches distutils so it should be imported _before_ 
>> distutils.
>> Somewhere in the doctests, it is other way round and hence the error.
>>
>> Did you get a chance to build sage yet?
> Sorry to pester you, but since softfreeze is near - did you happen to have 
> any update about this yet? Can I be of help in any way?
>
> Let me know.
>
Last time I tried to build sage, I reported here what happened. I tried to 
figure out why upstream is not having this problem. My best guess is the 
mismatch in setuptools versions. Upstream is still at 63.4.3 while Debian 
updated to 65.5.0.

Upstream has a (maybe unrelated?) problem with higher setuptools versions 
described here:
https://trac.sagemath.org/ticket/34442

Unfortunately I don't have much time to work on this. If someone can come up 
with a patch, that would be highly appreciated.

Best wishes,

Tobias

Bug#861923:

[Fabio Pedretti]

The entry in the changelog tells a different bug (_9_61923), please correct
it in the next upload.
Thanks

Bug#1019380: UDD: import ports.d.o data to ports tables instead of derivatives tables

[Paul Wise]

Control: reopen -1

On Sat, 2022-12-24 at 09:04 +0100, Lucas Nussbaum wrote:

> OK, I imported ports to ports_* tables.

Thanks, but they don't appear to have any data yet and
the derivatives tables still have ports data in them.

https://qa.debian.org/cgi-bin/madison.cgi?package=chromium-bsu=ports===#
https://qa.debian.org/cgi-bin/madison.cgi?package=chromium-bsu=derivatives===#

pabs@quantz:~$ PAGER=cat psql service=udd
psql (11.18 (Debian 11.18-0+deb10u1), server 13.9 (Debian 13.9-0+deb11u1))
WARNING: psql major version 11, server major version 13.
 Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, 
compression: off)
Type "help" for help.

udd=> select * from ports_sources limit 1;
 source | version | maintainer | maintainer_name | maintainer_email | format | 
files | uploaders | bin | architecture | standards_version | homepage | 
build_depends | build_depends_indep | build_conflicts | build_conflicts_indep | 
priority | section | distribution | release | component | vcs_type | vcs_url | 
vcs_browser | python_version | ruby_versions | checksums_sha1 | 
checksums_sha256 | original_maintainer | dm_upload_allowed | testsuite | 
autobuild | extra_source_only | build_depends_arch | build_conflicts_arch 
+-++-+--++---+---+-+--+---+--+---+-+-+---+--+-+--+-+---+--+-+-++---++--+-+---+---+---+---++--
(0 rows)

> I'm closing this bug, assuming you will track the rmadison change in a
> separate one.

I've added the ports table to madison.cgi:

https://salsa.debian.org/qa/qa/commit/09765f3fa5b7a26c90c82f005593385afbe2220e

Once the above issue is resolved I'll fix rmadison in devscripts.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1025662: patch

[Andrej Shadura]

Control: tags -1 fixed-upstream

Hi,

On Sat, 24 Dec 2022, at 02:40, Russell Coker wrote:
> The following patch appears to make this work correctly.

The upstream has already fixed this too, it should work in the next version.

-- 
Cheers,
  Andrej

Bug#1026782: Issues in apt-src man page (for your information)

[Helge Kreutzmann]

Hello Américo,
I just noticed that you also have a pending translation for apt-src. I
just did the German translation and reported some issues in the
english originals in #1026896.

So be aware, in case these issues are fixed (and the new translations
are integrated) you might need to react appropriately, especially if
the maintainers make it before the freeze.

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026932: gammaray: FTBFS on ppc64el: test failure

[Sebastian Ramacher]

Source: gammaray
Version: 2.11.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=gammaray=ppc64el=2.11.3-1%2Bb3=1671837701=0


96% tests passed, 2 tests failed out of 53

Total Test time (real) = 1766.53 sec

The following tests FAILED:
 20 - signalspycallbacktest (Timeout)
 21 - integrationtest (Subprocess aborted)
Errors while running CTest
make[2]: *** [Makefile:94: test] Error 8
make[2]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'

Cheers
-- 
Sebastian Ramacher

Bug#1026931: rocminfo: fails with error "lsmod: not found"

[Cordell Bloor]

Package: rocminfo
Version: 5.2.3-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

After installing rocminfo on a fresh new Debian image, I ran the command
and saw the error:

sh: 1: lsmod: not found
ROCk module is NOT loaded, possibly no GPU devices

After running `apt install kmod`, this problem was resolved and I saw
normal output:

ROCk module is loaded


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages rocminfo depends on:
ii  libc6   2.36-5
ii  libgcc-s1   12.2.0-9
ii  libhsa-runtime64-1  5.2.3-1
ii  libstdc++6  12.2.0-9
ii  pciutils1:3.9.0-2
ii  python3 3.10.6-3

rocminfo recommends no packages.

rocminfo suggests no packages.

-- no debconf information