date:20220618

Package: wnpp
Severity: normal
Control: affects -1 src:asmjit

I intend to orphan the asmjit package.
This package is in good shape.
This package is a dependency of some optional pytorch dependencies, but I've
forgotten the particular name. Anyway, I'm no longer planning to enable that
optional dependency.
So I'm no longer interested in maintaining this package.

The package description is:
 AsmJit is a complete JIT and AOT assembler for C++ language. It can generate
 native code for x86 and x64 architectures and supports the whole x86/x64
 instruction set - from legacy MMX to the newest AVX512. It has a type-safe API
 that allows C++ compiler to do semantic checks at compile-time even before the
 assembled code is generated and/or executed.
 .
 This package contains the header files and the static library.
Thank you for using reportbug

Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation

Control: close -1

It is not really necessary to package a volatile documentation project.
Looking up through internet is already convenient enough.

Bug#964543: ITP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning

Control: owner -1 w...@debian.org
Control: retitle -1 RFP: pymc3 -- Bayesian statistical modeling and 
Probabilistic Machine Learning

I'm no longer interested in packaging this on my own.

Bug#959123: ITP: fbgemm -- Facebook GEneral Matrix Multiplication

Control: close -1

I'm no longer interested in packaging this.
This package is only useful for pytorch. And I'm no longer
planning to enable this package in pytorch build.

Bug#1013213: gftools: version outdated, blocking build of cascadia code

Source: gftools
Version: 0.5.2+dfsg-2
Severity: wishlist

Dear maintainer,

I believe the gftools version in unstable is seriously outdated.
And fonts-cascadia-code 2111.01 requires a newer version to successfully build.
Please consider packaging a newer version if possible.


make[1]: Entering directory '/<>'
python3 build.py
Traceback (most recent call last):
  File "/<>/build.py", line 17, in 
from gftools.stat import gen_stat_tables_from_config
ImportError: cannot import name 'gen_stat_tables_from_config' from 
'gftools.stat' (/usr/lib/python3/dist-
packages/gftools/stat.py)
make[1]: *** [debian/rules:10: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2022-06-19T02:44:43Z

Bug#1013212: O: vim-julia -- Vim support for Julia language

Package: wnpp
Severity: normal
Control: affects -1 src:vim-julia

I intend to orphan the vim-julia package.
This package is in good shape.
This package is team-maintained, but in fact I'm the only effective maintainer.
I'm no longer interested in maintaining this package.

The package description is:
 An overview of some of the features:
  * Latex-to-Unicode substitutions
  * Block-wise movements and block text-objects
  * Changing syntax highlighting depending on the Julia version
 .
 The full documentation is available from Vim: after installation,
 you just need to type :help julia-vim.
 .
 To enable this vim addon, simply issue the following command:
  $ vam install julia
Thank you for using reportbug

Bug#1012759: debian-goodies: dgrep doesn't work with regexp for the package names

2022-06-18 Thread Axel Beckert

Hi again,

Axel Beckert wrote:
> Thanks for this bug report. These are actually multiple issues:

Actually no …

> * Documentation issue in the dgrep man page: dgrep uses dglob for
>   pattern matching

That's correct.

>   and that one uses wildcard pattern matching.

That's actually not correct. It solely seems to support substring
matching and calls that a "pattern" which is IMHO a bit misleading.

So actually the main bug is that the documentation in dgrep's man page
is wrong.

And the secondish issue is that dglob's man page could be less
misleading.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013210: O: nsync -- C library that exports various synchronization primitives

Package: wnpp
Severity: normal
Control: affects -1 src:nsync

I intend to orphan the nsync package.
This package is tensorflow dependency.
This package is in very good shape.
I'm no longer interested in maintaining tensorflow dependencies.

The package description is:
 nsync is a C library that exports various synchronization primitives:
 .
  * locks
  * condition variables
  * run-once initialization
  * waitable counter (useful for barriers)
  * waitable bit (useful for cancellation, or other conditions)
 .
 This package ships C++ shared object.
Thank you for using reportbug

Bug#1013209: O: farmhash -- FarmHash, a family of hash functions

Package: wnpp
Severity: normal
Control: affects -1 src:farmhash

I intend to orphan the farmhash package.
This package is tensorflow dependency.
This package is in good shape.
I'm no longer interested in maintaining tensorflow dependency.

The package description is:
 FarmHash provides hash functions for strings and other data.  The functions
 mix the input bits thoroughly but are not suitable for cryptography.
 .
 This package contains development files and document.
Thank you for using reportbug

Bug#1012759: debian-goodies: dgrep doesn't work with regexp for the package names

2022-06-18 Thread Axel Beckert

Hi Vincent,

Vincent Lefevre wrote:
> The dgrep(1) man page says:
> 
>   You can use POSIX regular expressions for the package names.
> 
> But
> 
>   dgrep represents 'libc6'
> 
> return matches, while
> 
>   dgrep represents 'libc6.*'
> 
> doesn't.

Thanks for this bug report. These are actually multiple issues:

* Documentation issue in the dgrep man page: dgrep uses dglob for
  pattern matching and that one uses wildcard pattern matching. I've
  fixed this one in git.

* dglob still doesn't work as documented:

~ → dglob libc6
libc6:amd64
libc6:i386
libc6-dbg:amd64
libc6-dev:amd64
libc6-dev-i386:amd64
libc6-dev-x32:amd64
libc6-i386:amd64
libc6-x32:amd64
~ → dglob libc6\*
~ → dglob libc6:\*
grep-dctrl: *scratch*:1: expected a colon.
~ →

I'm now considering the latter the actual bug tracked by this bug
report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013208: O: highwayhash -- Fast strong hash functions: SipHash/HighwayHash

Package: wnpp
Severity: normal
Control: affects -1 src:highwayhash

I intend to orphan the highwayhash package.
It is tensorflow dependency.
This package is in good shape.
I'm no longer interested in maintaining tensorflow dependencies.

The package description is:
 Highwayhash provides three 'strong' (well-distributed and unpredictable)
 hash functions: a faster version of SipHash, a data-parallel variant of
 SipHash using tree hashing, and an even faster algorithm called HighwayHash.
 .
 SipHash is a fast but 'cryptographically strong' pseudo-random function by
 Aumasson and Bernstein [https://www.131002.net/siphash/siphash.pdf].
 .
 SipTreeHash slices inputs into 8-byte packets and computes their SipHash in
 parallel, which is faster when processing at least 96 bytes.
 .
 HighwayHash is a new way of mixing inputs which may inspire new
 cryptographically strong hashes. Large inputs are processed at a rate of
 0.3 cycles per byte, and latency remains low even for small inputs.
 HighwayHash is faster than SipHash for all input sizes, with about 3.8 times
 higher throughput at 1 KiB.
 .
 This package ships the static library and development files.
Thank you for using reportbug

Bug#1013207: RM: nnpack/experimental -- ROM; FTBFS; don't want to maintain anymore

Package: ftp.debian.org
Severity: normal

This package has been FTBFS for a long period. I have no interest
in bringing it back into good shape.

Thank you for using reportbug

Bug#1013206: O: python-fire -- automatically generate CLIs from absolutely any Python object

Package: wnpp
Severity: normal
Control: affects -1 src:python-fire

I intend to orphan the python-fire package.
This package is in good shape.
I'm just not interested in maintaining this anymore.

The package description is:
 Python Fire is a library for automatically generating command line interfaces
 (CLIs) from absolutely any Python object.
 .
  * Python Fire is a simple way to create a CLI in Python.
  * Python Fire is a helpful tool for developing and debugging Python code.
  * Python Fire helps with exploring existing code or turning other people's
code into a CLI.
  * Python Fire makes transitioning between Bash and Python easier.
  * Python Fire makes using a Python REPL easier by setting up the REPL with
the modules and variables you'll need already imported and created.

Thank you for using reportbug

Bug#1013205: samba-common: samba no longer installable on sparc64 due to impossible version conflict

2022-06-18 Thread Rich Ercolani

Package: samba-common
Version: 2:4.13.5+dfsg-2
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com

Dear Maintainer,

Pretty simple report - since samba-common is only offered at 2:4.16.2+dfsg-1 in 
sid currently,
and all the binary samba packages for sparc64 are at 2:4.13.14+dfsg-1+b4, it's 
impossible to install
right now without either reaching into the archive snapshots or building 
yourself.

It would be nice if this wasn't breaking "apt upgrade".

- Rich

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, and attached

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

Kernel: Linux 5.10.0-8-sparc64
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages samba-common depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  ucf3.0043

Versions of packages samba-common recommends:
ii  samba-common-bin  2:4.13.5+dfsg-2

samba-common suggests no packages.

-- debconf information:
  samba-common/title:
  samba-common/do_debconf: true
  samba-common/workgroup: WORKGROUP
  samba-common/dhcp: false


dhcp.conf
Description: inode/empty

Bug#1012778: asymptote: Asymptote can't render static images

2022-06-18 Thread Alexandre Lymberopoulos

Hi there, Hilmar!

In fact, for some reason, setting that environment variable makes
asymptote render the static images in png and PDF formats.

I'll dig into this and check if it is necessary to file this on any
other package. Thanks for your prompt reply.

Best,
Alexandre

On Jun 17 2022, Hilmar Preuße wrote:
> Am 14.06.2022 um 00:44 teilte Alexandre Lymberopoulos mit:
> 
> Hi,
> 
> > I'm trying to render the intersection of two cylinders here.
> > Everything runs fine when output is an HTML file, but changing the
> > outformat to PDF or PNG produce the following output on terminal:
> > 
> > X Error of failed request:  GLXBadFBConfig
> >Major opcode of failed request:  153 (GLX)
> >Minor opcode of failed request:  0 ()
> >Serial number of failed request:  43
> >Current serial number in output stream:  43
> > 
> > I'm totally clueless on what's going on. Here is the asy file content:
> > 
> Works fine here. I'm pretty sure the error message is unrelated to
> asymptote. When googling for the first line, one finds for example this URL
> [1]. Does that describe and (eventually solve your issue)?
> 
> Hilmar
> 
> [1] 
> https://askubuntu.com/questions/1369900/x-error-of-failed-request-glxbadfbconfig
> -- 
> sigfault
> 




-- 
===
Alexandre Lymberopoulos - lym...@gmail.com
===

Bug#1013204: markdown-it-py: FTBFS with flit < 3.4 (<3.3?)

2022-06-18 Thread David (Plasma) Paul

Source: markdown-it-py
Version: 2.1.0-2
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

markdown-it-py fails to build from source with versions of flit earlier than
3.4 according to the package's pyproject.toml.[0] Attached is a patch
to fix the declared build dependency on flit in the debian/control file
to match the supported versions listed in the package's pyproject.toml
file.

[0] However, I was able to get markdown-it-py to build with flit
3.3.0-1~bpo11+1, so maybe the value in the pyproject.toml file is
higher than it strictly needs to be. Regardless of what the actual
exact minimum value is, I can confirm that flit 3.0.0 is insufficient.

-- 
Plasma
diff -Nru markdown-it-py-2.1.0/debian/control markdown-it-py-2.1.0/debian/control
--- markdown-it-py-2.1.0/debian/control	2022-05-20 14:21:22.0 -0500
+++ markdown-it-py-2.1.0/debian/control	2022-06-18 17:49:09.0 -0500
@@ -4,7 +4,8 @@
 Maintainer: Debian Python Team 
 Uploaders: Emmanuel Arias ,
 Build-Depends: debhelper-compat (= 13),
-   flit,
+   flit (>= 3.4),
+   flit (<< 4),
pybuild-plugin-pyproject,
python3-all,
python3-attr,

Bug#1013203: os-prober: Dual boot Windows 10 grub-probe error unknown filesystem

2022-06-18 Thread Steven Zalek

Package: os-prober
Version: 1.80
Severity: normal
X-Debbugs-Cc: zalek.ste...@gmail.com

Dear Maintainer,

What led to the situation:
Debian Testing new linux kernel 5.18.0-1 and updated grub 2.06-3 installed via
apt package manager; the new linux kernel installation prompted the update-grub
function to run.

By default this new version of grub does not run the the os-prober package,
hence, the Windows 10 partition was not detected and was eliminated from the
grub.cfg list of bootable partitions.

What I did that was effective/ineffective (part 1):
- Added 'GRUB_DISABLE_OS_PROBER=false' to /etc/default/grub and ran 'sudo
update-grub', forcing os-prober/grub to search for Windows partition
- this resulted in the Windows 10 partition on this computer (box0) to be
recognized, but with errors >>
  [incidentally, this exact procedure worked perfectly on my dual-boot Debian
Testing/Windows 10 laptop - no errors]

terminal output >>
---
zaleksf@box0:~$ sudo update-grub
[sudo] password for zaleksf:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.18.0-1-amd64
Found initrd image: /boot/initrd.img-5.18.0-1-amd64
Found linux image: /boot/vmlinuz-5.17.0-1-amd64
Found initrd image: /boot/initrd.img-5.17.0-1-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot
entries.
/usr/sbin/grub-probe: error: unknown filesystem.
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
/usr/sbin/grub-probe: error: unknown filesystem.
Adding boot menu entry for UEFI Firmware Settings ...
done
---

Outcome:
Upon rebooting and seeing the main grub list screen, there were the usual
entries for booting to Debian, Windows, etc. However, upon selecting the
Windows boot entry, I received an error indicating
'/EFI/Microsoft/Boot/bootmgfw.efi does not exist'

This was false, as I could find this file from both the Debian OS and Windows
OS file manager, and I could boot directly into Windows 10 from the BIOS using
the 'Enter/F12' key combination to bring up a list of boot partition choices
(which did show both Debian and Windows as options).

I investigated grub.cfg file and found that the 30_os-prober section for
Windows to be significantly truncated from its usual entry (and other Linux
kernel entries) >>

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os
$menuentry_id_option 'osprober-efi-/dev/sda1' {
insmod part_gpt
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###

What I did that was effective/ineffective (part 2):
Since my laptop (box1) also is dual-boot Debian Testing/Windows 10 with a
virtually identical set-up, I tried an experiment of copying its complete (and
functioning) 30_os-prober section to grub.cfg on this misbehaving desktop
system (box0). I tweaked this section (using logic) to point to the proper
Windows partition, etc. (since I really have no experience with grub at all).
Manually changed section 30_os-prober to this >>

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os
$menuentry_id_option 'osprober-efi-/dev/sda1' {
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-
efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  82CB-1126
else
  search --no-floppy --fs-uuid --set=root 54C7-5867
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###

Saved grub.cfg, rebooted machine and selected Windows entry from grub.

Outcome:

Can boot into the Windows 10 partition perfectly, just as before. All grub list
entries work correctly.

If I run 'update-grub' again, the grub-probe error is indicated in the
terminal, and the truncated/broken section 30_os-prober returns to
/boot/grub/grub.cfg

My machine (and Windows and Debian) works just fine. This machine has been
dual-boot Debian Testing/Windows 10 for the last 5 years and has never
experienced this issue before this version of grub/os-prober was introduced.

My recommendation is to look into why the os-prober successfully recognizes a
dual-boot Windows partition for some machines and not others. Please let me
know if I can send additional files to support troubleshooting and/or
development.

Best regards, SZ


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

Kernel: Linux 5.18.0-1-amd64 (SMP w/16 C

Bug#1013202: gnubik: Please remove dep on install-info

Package: gnubik
Version: 2.4.3-3+b3
Severity: minor

Dear Maintainer,

The package declares a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages gnubik depends on:
ii  dpkg1.21.8
pn  guile-2.2-libs  
ii  install-info6.8-4+b1
ii  libc6   2.33-7
ii  libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii  libgl1  1.4.0-1
ii  libglib2.0-02.72.2-2
ii  libglu1-mesa [libglu1]  9.0.2-1
pn  libgtk2.0-0 
pn  libgtkglext1

gnubik recommends no packages.

gnubik suggests no packages.

Bug#1013201: gettext: Please remove dep on install-info

Package: gettext
Version: 0.21-6
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages gettext depends on:
ii  dpkg   1.21.8
ii  gettext-base   0.21-6
ii  install-info   6.8-4+b1
ii  libc6  2.33-7
ii  libgomp1   12.1.0-4
ii  libunistring2  1.0-1
ii  libxml22.9.14+dfsg-1

Versions of packages gettext recommends:
ii  curl  7.83.1-2
ii  lynx  2.9.0dev.10-1
ii  wget  1.21.3-1+b2

Versions of packages gettext suggests:
ii  autopoint 0.21-6
pn  gettext-doc   
pn  libasprintf-dev   
pn  libgettextpo-dev  

-- no debconf information

Bug#1013200: w3m-el-snapshot: Please remove dep on install-info

Package: w3m-el-snapshot
Version: 1.4.632+0.20220414.2221.89ed3cf-1
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages w3m-el-snapshot depends on:
ii  dpkg1.21.8
pn  emacs-nox | emacs | emacs-snapshot  
ii  emacsen-common  3.0.4
ii  install-info6.8-4+b1
pn  w3m | w3m-ssl | w3mmee  

Versions of packages w3m-el-snapshot recommends:
pn  apel  
pn  flim  

Versions of packages w3m-el-snapshot suggests:
ii  bzip21.0.8-5
pn  discount | libtext-markdown-perl | markdown  
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b2
pn  libmoe1.5
pn  namazu2  
pn  perl-doc 
ii  poppler-utils [xpdf-utils]   22.02.0-3
pn  ppthtml  
pn  semi 
pn  wv   
pn  xlhtml

Bug#1013199: guile-cairo-dev: Please remove dep on install-info

Package: guile-cairo-dev
Version: 1.11.2-5
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages guile-cairo-dev depends on:
ii  dpkg   1.21.8
pn  guile-3.0-dev  
pn  guile-cairo
ii  install-info   6.8-4+b1
pn  libcairo2-dev  
ii  sgml-base  1.30

guile-cairo-dev recommends no packages.

guile-cairo-dev suggests no packages.

Bug#1013198: w3m-el: Please remove dep on install-info

Package: w3m-el
Version: 1.4.632+0.20210201.2305.54c3ccd-1
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages w3m-el depends on:
ii  dpkg1.21.8
pn  emacs-nox | emacs | emacs-snapshot  
ii  emacsen-common  3.0.4
ii  install-info6.8-4+b1
pn  w3m | w3m-ssl | w3mmee  

Versions of packages w3m-el recommends:
pn  apel  
pn  flim  

Versions of packages w3m-el suggests:
ii  bzip21.0.8-5
pn  discount | libtext-markdown-perl | markdown  
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b2
pn  libmoe1.5
pn  namazu2  
pn  perl-doc 
ii  poppler-utils [xpdf-utils]   22.02.0-3
pn  ppthtml  
pn  semi 
pn  wv   
pn  xlhtml

Bug#1013197: guile-3.0-doc: Please remove dep on install-info

Package: guile-3.0-doc
Version: 3.0.8-2
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages guile-3.0-doc depends on:
ii  dpkg  1.21.8
ii  install-info  6.8-4+b1

guile-3.0-doc recommends no packages.

guile-3.0-doc suggests no packages.

Bug#1013196: guile-2.2-doc: Please remove dep on install-info

Package: guile-2.2-doc
Version: 2.2.7+1-6
Severity: minor

Dear Maintainer,

The package declare a dep on "install-info". However this dep should only
be needed for info viewers, as they have to care about updating the info index.
Your package do not seem to be an info viewer hence the Dep on "install-info"
is not needed. Consider to remove it.

https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Many thanks,
  Hilmar Preuße

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

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

Versions of packages guile-2.2-doc depends on:
ii  dpkg  1.21.8
ii  install-info  6.8-4+b1

guile-2.2-doc recommends no packages.

guile-2.2-doc suggests no packages.

Bug#1013195: base-files: Please add AGPL-3 license

2022-06-18 Thread Salvo 'LtWorf' Tomaselli

Package: base-files
Version: 12.2
Severity: normal
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,
AGPL-3 license is not present in the base files.

This forces me to include verbatim the very long text of the license which
also gets duplicated if many binary packages are generated.

For ease of read from FTPmaster it would be preferrable to have the text
in base-files so that it can just be referenced.


Best

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

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

Versions of packages base-files depends on:
ii  mawk [awk]  1.3.4.20200120-3+b1

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

Control: severity -1 normal
Control: merge -1 1012835

On Saturday, 18 June 2022 21:52:41 CEST Thorsten Glaser wrote:
> Version: 5.10.120-1
> Severity: serious
> Tags: security

There has been a HUGE changeset applied between 5.10.118 and 5.10.119 and while
not entirely certain, I'm quite confident that this change was intentional. 
That and the severity of the bug I'm merging it with has severity normal, is
the reason I'm downgrading the severity to normal.
I'll leave it up to the maintainer to adjust it if needed.

https://lore.kernel.org/all/20220317232804.931702-1-ja...@zx2c4.com/ is 
probably the closest match of the 'cause' of these changes, but there's a good
chance that several patch sets were involved.

Here are some more 'random' threads I have found:
https://lore.kernel.org/all/20211221175047.341782-1-ja...@zx2c4.com/
https://lore.kernel.org/all/20220201161342.154666-1-ja...@zx2c4.com/

And as already mentioned in the bug I'm merging it with, you're not the only
one who noticed:
https://forum.openwrt.org/t/low-entropy-22-03-snapshot-change-in-kernel-entropy-pool-logic/129573

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

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

2022-06-18 Thread Thorsten Glaser

Bastian Blank dixit:

>The pool size for an RPNG is only the size of the state, nothing else.

Yes, and that is the problem. It was small before, it’s ridiculous now.

>might not have had any value before anyway.  You just need to reseed on
>a regular interval.

Ugh. I recall reading something about this on LWN, but I thought I
had time until bookworm to invent something to deal with this…

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

On Saturday, 18 June 2022 22:47:01 CEST Diederik de Haas wrote:
> Here are some more 'random' threads I have found:

And this seems like an entire document explaining it:
https://www.zx2c4.com/projects/linux-rng-5.17-5.18/

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

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

2022-06-18 Thread Bastian Blank

Control: severity -1 normal
Control: tags -1 wontfix

On Sat, Jun 18, 2022 at 09:52:41PM +0200, Thorsten Glaser wrote:
> /proc/sys/kernel/random/poolsize is now 256 instead of 4096 bits,
> which was already small before.

The pool size for an RPNG is only the size of the state, nothing else.
It does not in any way describe how much you could get out.

> Why was such a change allowed into stable?

Because upstream considered it important enough for their stable
release, aka it fixes something important.

> This also breaks rngd’s --fill-watermark option when not set to
> percent values. Another reason this should not be changed within
> a stable series.

The kernel does not longer provide a number that could be used here.  It
might not have had any value before anyway.  You just need to reseed on
a regular interval.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

Bug#1013194: ITP: django-rich -- Extensions for using Rich with Django

2022-06-18 Thread Carsten Schoenert

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

* Package name: django-rich
  Version : 1.4.0
  Upstream Author : Adam Johnson 
* URL : https://github.com/adamchainz/django-rich
* License : MIT
  Programming Lang: Python
  Description : Extensions for using Rich with Django

 Rich is a Python library for writing rich text (with color and style) to the
 terminal, and for displaying advanced content such as tables, markdown, and
 syntax highlighted code.
 .
 The djano-rich library is adding such functionality into a Django integration
 so colourized outputs and nice traceback rendering is possible.

This Django extension is an upcoming new requirement for NetBox next
minor version 3.3 (not yet released).

It will be maintained within the Debian Python Team.

Bug#1013193: ros-image-proc: missing Breaks+Replaces: libimage-proc-dev (<< 1.16.0-3)

2022-06-18 Thread Andreas Beckmann

Package: ros-image-proc
Version: 1.16.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../ros-image-proc_1.16.0-3_amd64.deb ...
  Unpacking ros-image-proc (1.16.0-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ros-image-proc_1.16.0-3_amd64.deb (--unpack):
   trying to overwrite '/usr/share/image_proc/package.xml', which is also in 
package libimage-proc-dev:amd64 1.16.0-2
  Errors were encountered while processing:
   /var/cache/apt/archives/ros-image-proc_1.16.0-3_amd64.deb


cheers,

Andreas


libimage-proc-dev=1.16.0-2_ros-image-proc=1.16.0-3.log.gz
Description: application/gzip

Bug#892908: puppet: Hiera 5 is now built-in, please drop hiera 3 dependency

2022-06-18 Thread Jérôme Charaoui




Hello,

At the moment, the Hiera 3 gem is still a required dependency when 
installing Puppet agent version 7.x


I've submitted a patch upstream to remove this requirement:
https://github.com/puppetlabs/puppet/pull/8906

However, upstream has identified a few small changes that still need to 
be made within Puppet before it's fully decoupled from Hiera 3.


Puppet 8 is expected to drop the Hiera 3 completely, but until then, 
it's required.


-- Jerome

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

2022-06-18 Thread Thorsten Glaser

Package: src:linux
Version: 5.10.120-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 


/proc/sys/kernel/random/poolsize is now 256 instead of 4096 bits,
which was already small before.

Why was such a change allowed into stable?

This also breaks rngd’s --fill-watermark option when not set to
percent values. Another reason this should not be changed within
a stable series.


-- Package-specific info:
** Version:
Linux version 5.10.0-15-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.120-1 (2022-06-09)

** Command line:
root=UUID=078df9a0-34f7-4171-b531-0cb628963204 ro clocksource=acpi_pm verbose

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information

** Loaded modules:
binfmt_misc
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
nfs_ssc
fscache
sunrpc
joydev
evdev
serio_raw
virtio_rng
rng_core
pcspkr
virtio_balloon
cirrus
drm_kms_helper
cec
drm
button
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_generic
usbhid
hid
virtio_blk
virtio_net
net_failover
failover
ata_generic
crc32c_intel
psmouse
virtio_pci
virtio_ring
virtio
i2c_piix4
ata_piix
uhci_hcd
libata
floppy
ehci_hcd
scsi_mod
usbcore
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-15-amd64 suggests:
pn  debian-kernel-handbook   
pn  grub-pc | grub-efi-amd64 | extlinux  
pn  linux-doc-5.10   

Versions of packages linux-image-5.10.0-15-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1012401: RFS: csoundqt/1.1.0-1 -- frontend for the csound sound processor

2022-06-18 Thread snd


thx again! its done :) https://mentors.debian.net/package/csoundqt/
hopefully its ok now

Am 18.06.22 um 10:50 schrieb Jeroen Ploemen:

Control: tags -1 moreinfo

On Mon, 6 Jun 2022 15:22:07 +0200
Dennis Braun  wrote:


I am looking for a sponsor for my package csoundqt:

hi Dennis,

* copyright is missing info for several files:
   bin/win-installer.iss
   src/Examples/CsoundQt/Miscellaneous/Circle_Map.csd
   src/Examples/CsoundQt/Synths/Sruti-Drone_Box.csd

   Note that the license for one of the examples is DFSG-incompatible
   because it carries a non-commercial clause.

* d/csoundqt.lintian-overrides overrides two tags, but the actual
   problem seems to be the presence of a shebang line in the desktop
   file (at line 1). That line shouldn't be there; patching it out
   would make the lintian hits disappear.


Please remove the moreinfo tag (and put me in the CC) once you have
an updated package ready.

Bug#1012616: xtrx-dkms: DKMS build fails with implicit declaration of functions

2022-06-18 Thread Witold Baryluk

Package: xtrx-dkms
Version: 0.0.1+git20190320.5ae3a3e-3
Followup-For: Bug #1012616
X-Debbugs-Cc: witold.bary...@gmail.com

I suggest escalating this to serious issue. As is causing live-build
build failures, and kernel upgrade issues interfering with the rest of
the system.

Due to chain of Depends and Recommends, xtrx-dkms is installed, even if
not requested or needed directly by user.

For example installing gnss-sdr, gqrx-sdr, gr-osmosdr would cause
xtrx-dkms to be attempted to be installed in many cases.

I think one of the things (beyond fixing the bug in the xtrx-dkms itself),
is changing Recommends to Suggests in libxtrxll0.
I would even say that using Recommends does not follow the Debian policy.


Other option is to remove xtrx related packages from Debian. Devices are
no longer available for purchase. Website has no updates since 2017,
crowsupply had last update in 2019, and github had last update 3-4 years
ago with various Issues and PR opened but not touched for over a year. So
it looks unmaintained. The developer and company now moved to other
projects (similar to xtrx). The driver is small, and has GPL, but there
was never any attempt to upstream it into mainline Linux, so it was
doomed to be abandoned and rot. popcon shows 142 "votes". But this might
be misleading, as there is no direct way to measure how many people
actually use it. If it is installed, it will be built on kernel upgrade,
so "accessed", doesn't mean it will be loaded and used. popcon graphs
also show sharp drop in last month, where people probably started
realising it breaks the kernel upgrade while doing standard apt upgrade.


Regards,
Witold





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

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

Versions of packages xtrx-dkms depends on:
ii  dkms  3.0.3-2

xtrx-dkms recommends no packages.

xtrx-dkms suggests no packages.

-- no debconf information

Bug#1013191: mdurl: FTBFS with flit < 3.2

2022-06-18 Thread David (Plasma) Paul

Source: mdurl
Version: 0.1.1-1
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

mdurl fails to build from source with versions of flit earlier than
3.2. Attached is a patch to fix the declared build dependency on flit
in the debian/control file to match the supported versions listed in
the package's pyproject.toml file.

-- 
Plasma
diff -Nru mdurl-0.1.1/debian/control mdurl-0.1.1/debian/control
--- mdurl-0.1.1/debian/control	2022-04-07 04:23:21.0 -0500
+++ mdurl-0.1.1/debian/control	2022-06-18 13:14:41.0 -0500
@@ -5,7 +5,8 @@
 Maintainer: Debian Python Team 
 Build-Depends: debhelper-compat (= 13),
dh-python,
-   flit,
+   flit (>= 3.2),
+   flit (<< 4),
pybuild-plugin-pyproject,
python3-all,
 	   python3-pytest ,

Bug#998627: sid enable

2022-06-18 Thread Mina Morcose Farage


hello

sid and teasting made for this purpose i  suggest to enable it in sid at 
least and see where it goes



Thanks

Mina

Bug#1013190: openems: Migration from vtk7 to vtk9

2022-06-18 Thread Francois Mazen

Package: openems
Severity: wishlist
Tags: patch
X-Debbugs-Cc: franc...@mzf.fr

Dear Maintainer,

OpenEMS package depends on vtk7 which is quite old and not maintained upstream.

I've succeeded to build OpenEMS with vtk9 by changing Build-Depends from
libvtk7-dev to libvtk9-dev and fixing CMake and build errors.
The patch is attached to this message.

Could you please update to vtk9?

Thanks,

François
--- a/openEMS/CMakeLists.txt
+++ b/openEMS/CMakeLists.txt
@@ -122,7 +122,7 @@
 )
 
 # vtk
-find_package(VTK COMPONENTS vtkIOXML vtkIOGeometry vtkIOLegacy vtkIOPLY 
NO_MODULE REQUIRED)
+find_package(VTK COMPONENTS IOXML IOGeometry IOLegacy IOPLY NO_MODULE REQUIRED)
 
 message(STATUS "Found package VTK. Using version " ${VTK_VERSION})
 if("${VTK_MAJOR_VERSION}" GREATER 5)
@@ -174,7 +174,7 @@
   ${HDF5_LIBRARIES}
   ${HDF5_HL_LIBRARIES}
   ${Boost_LIBRARIES}
-  ${vtk_LIBS}
+  ${VTK_LIBRARIES}
   ${MPI_LIBRARIES}
   hdf5_serial_hl
 )
--- a/CSXCAD/src/CSPrimPolyhedronReader.cpp
+++ b/CSXCAD/src/CSPrimPolyhedronReader.cpp
@@ -163,7 +163,7 @@
AddVertex(polydata->GetPoint(n));
 
vtkIdType numP;
-   vtkIdType *vertices = new vtkIdType[10];
+   vtkIdType const *vertices = new vtkIdType[10];
while (verts->GetNextCell(numP, vertices))
{
face f;
--- a/QCSXCAD/CMakeLists.txt
+++ b/QCSXCAD/CMakeLists.txt
@@ -6,7 +6,7 @@
   SET( CMAKE_BUILD_TYPE Release CACHE STRING "Set to either \"Release\" or 
\"Debug\"" )
 ENDIF()
 
-PROJECT( QCSXCAD CXX)
+PROJECT( QCSXCAD C CXX)
 
 cmake_minimum_required(VERSION 2.8)
 
@@ -100,6 +100,8 @@
 message(STATUS "Found package VTK. Using version " ${VTK_VERSION})
 include(${VTK_USE_FILE})
 INCLUDE_DIRECTORIES (${VTK_INCLUDE_DIRS})
+message("VTK_MAJOR_VERSION: ${VTK_MAJOR_VERSION}")
+add_compile_definitions(VTK_MAJOR_VERSION=${VTK_MAJOR_VERSION})
 
 # Qt 
 SET(RESOURCES resources.qrc)
--- a/QCSXCAD/QCSXCAD.cpp
+++ b/QCSXCAD/QCSXCAD.cpp
@@ -58,7 +58,7 @@
 #include "CSPrimWire.h"
 #include "CSPrimUserDefined.h"
 
-#include 
+#include 
 #include 
 #include 
 #include 
--- a/QCSXCAD/QVTKStructure.h
+++ b/QCSXCAD/QVTKStructure.h
@@ -21,7 +21,9 @@
 #include 
 
 #include "vtkCommand.h"
-#if VTK_MAJOR_VERSION>=8
+#if VTK_MAJOR_VERSION>=9
+  class QVTKOpenGLNativeWidget;
+#elif VTK_MAJOR_VERSION>=8
   class QVTKOpenGLWidget;
 #else
   class QVTKWidget;
@@ -100,7 +102,9 @@
unsigned int uID;
} VTKLayerStruct;
 
-#if VTK_MAJOR_VERSION>=8
+#if VTK_MAJOR_VERSION>=9
+   QVTKOpenGLNativeWidget *VTKWidget;
+#elif VTK_MAJOR_VERSION>=8
QVTKOpenGLWidget *VTKWidget;
 #else
QVTKWidget *VTKWidget;
--- a/QCSXCAD/QVTKStructure.cpp
+++ b/QCSXCAD/QVTKStructure.cpp
@@ -20,7 +20,10 @@
 #include "QVTKStructure.h"
 
 #include "vtkCommand.h"
-#if VTK_MAJOR_VERSION>=8
+#if VTK_MAJOR_VERSION>=9
+  #include "QVTKOpenGLNativeWidget.h"
+  #include "vtkGenericOpenGLRenderWindow.h"
+#elif VTK_MAJOR_VERSION>=8
   #include "QVTKOpenGLWidget.h"
   #include "vtkGenericOpenGLRenderWindow.h"
 #else
@@ -99,7 +102,10 @@
iResolution=32;
AllowUpdate=true;
 
-#if VTK_MAJOR_VERSION>=8
+#if VTK_MAJOR_VERSION>=9
+   VTKWidget = new QVTKOpenGLNativeWidget();
+   VTKWidget->SetRenderWindow(vtkGenericOpenGLRenderWindow::New());
+#elif VTK_MAJOR_VERSION>=8
VTKWidget = new QVTKOpenGLWidget();
VTKWidget->SetRenderWindow(vtkGenericOpenGLRenderWindow::New());
 #else
--- a/QCSXCAD/export_x3d.cpp
+++ b/QCSXCAD/export_x3d.cpp
@@ -17,7 +17,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -70,7 +70,7 @@
export_properties( Scene, properties, Material );
 
// create camera
-   vtkRendererCollection* collection = 
((QVTKWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
+   vtkRendererCollection* collection = 
((QVTKOpenGLNativeWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
vtkRenderer *r = collection->GetFirstRenderer();
if (!r)
return;
--- a/QCSXCAD/export_pov.cpp
+++ b/QCSXCAD/export_pov.cpp
@@ -18,7 +18,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -201,7 +201,7 @@
 
 QString export_pov::get_camera()
 {
-   vtkRendererCollection* collection = 
((QVTKWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
+   vtkRendererCollection* collection = 
((QVTKOpenGLNativeWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
vtkRenderer *r = collection->GetFirstRenderer();
if (!r)
return QString();
@@ -231,7 +231,7 @@
 
 QString export_pov::get_light()
 {
-   vtkRendererCollection* collection = 
((QVTKWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
+   vtkRendererCollection* collection = 
((QVTKOpenGLNativeWidget*)(m_CSX->StructureVTK->GetVTKWidget()))->GetRenderWindow()->GetRenderers();
v

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

2022-06-18 Thread Thomas Schmitt

Hi,

Zhang Boyang wrote:
> I will definitely try it

Meanwhile i got some insight into the riddle about diffs between merged.iso
and CUSTOM-1.iso like

  Only in /groundtruth/firmware: arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb
  Only in /groundtruth/firmware: gnome-firmware_3.36.0-1_amd64.deb

Indeed arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb does not exist in
the /firmware directory of DLBD-1 and thus did not get into merged.iso.

But /firmware/gnome-firmware_3.36.0-1_amd64.deb is in DLBD-1 as symbolic
link and its target is in DLBD-1, too.

Please verify that it is really not in merged.iso.
If so, then please record the messages of the next experiment with the
merge script and send them to me in private.

I now uploaded a new version of the script which merges the /firmware
directories. Just a guess, until i know what's up with /firmware.



To those who are familiar with debian-cd, especially Steve McIntyre:

/firmware is not mentioned in
  https://wiki.debian.org/DebianRepository/Format
So i guess that it is specific to debian-cd or the installer along
  https://wiki.debian.org/Firmware#Firmware_during_the_installation
and that i should merge the /firmware directories.
Correct ?

I am a bit confused by the fact that debian-11.2.0-amd64-DVD-2.iso has
no firmware directory at all. How come ?
Can this happen to a first ISO, too ?
(DVD-1 has a /firmware tree with only inhabitant dep11/README.txt.)


Have a nice day :)

Thomas

Bug#1011365: bullseye-pu: package nvidia-cuda-toolkit/11.2.2-3+deb11u2

2022-06-18 Thread Adam D. Barratt

On Mon, 2022-05-30 at 17:31 +0200, Andreas Beckmann wrote:
> On 29/05/2022 16.16, Adam D. Barratt wrote:
> > Unfortunately the amd64 upload got rejected:
> > 
> > Version check failed:
> > Your upload included the binary package nvidia-openjdk-8-jre,
> > version
> > 9.+8u332-ga-1~deb9u1~11.2.2-3+deb11u2, for amd64,
> > however experimental already has version 9.+8u332-ga-1~11.5.1-2.
> > Uploads to proposed-updates must have a lower version than present
> > in
> > experimental.
> 
> Oh yes. 1~d   < 1
>  1~d~1 > 1~1
> 
> Is there a similar constraint for sid as well? I would have expected
> that to trigger first ... and probably s/already/only/ ...
> 

Surprisingly not. I have a feeling there once was, but it was removed.
I'm not entirely sure on that though; memory can play tricks.

The current checks are:

adsb@coccia:$ dak admin v-c list-suite proposed-updates
proposed-updates MustBeNewerThan oldoldoldstable
proposed-updates MustBeNewerThan oldoldstable
proposed-updates MustBeNewerThan stable
proposed-updates Enhances stable
proposed-updates MustBeNewerThan oldstable
proposed-updates MustBeOlderThan experimental

> Before I upload a fix, I'd like you to double check that these
> versions do not validate the ordering rules:
> 
> nvidia-openjdk-8-jre_9.+8u332-ga-1~~deb9u1~11.2.2-3+deb11u3_amd64.deb
> nvidia-openjdk-8-jre_9.+8u312-b07-1~11.2.2+8u302-b08-1~11.2.2-
> 3+deb11u3_ppc64el.deb
> 

nvidia-openjdk-8-jre | 9.+8u332-ga-1~11.4.3-3 | testing/non-free  | 
amd64, ppc64el
nvidia-openjdk-8-jre | 9.+8u332-ga-1~11.4.3-3 | unstable/non-free | 
amd64, ppc64el
nvidia-openjdk-8-jre | 9.+8u332-ga-1~11.5.1-2 | experimental/non-free | 
amd64, ppc64el

$ dpkg --compare-versions "9.+8u332-ga-1~~deb9u1~11.2.2-3+deb11u3" lt 
"9.+8u332-ga-1~11.4.3-3" && echo y
y

$ dpkg --compare-versions "9.+8u312-b07-1~11.2.2+8u302-b08-1~11.2.2-3+deb11u3" 
lt "9.+8u332-ga-1~11.4.3-3" && echo y
y

Both look OK so far as I can see, and already sort below the version in
testing so don't present any issues with prop-ups etc.

Regards,

Adam

Bug#1013186: python3-geopandas: geopandas is missing PROJ data directory

2022-06-18 Thread Sebastiaan Couwenberg


Control: tags -1 unreproducible moreinfo

On 6/18/22 19:41, Akkana Peck wrote:

import geopandas
results in the following warning:

/usr/lib/python3/dist-packages/pyproj/__init__.py:91: UserWarning: Valid PROJ 
data directory not found. Either set the path using the environmental variable 
PROJ_LIB or with `pyproj.datadir.set_data_dir`.
   warnings.warn(str(err))


pyproj works as expected:

>>> import pyproj
>>> pyproj.datadir.get_data_dir()
'/usr/share/proj'


geopandas works too:

>>> import geopandas
>>> from geopandas.tools._show_versions import show_versions
>>> show_versions()

SYSTEM INFO
---
python : 3.10.5 (main, Jun  8 2022, 09:26:22) [GCC 11.3.0]
executable : /usr/bin/python3
machine: Linux-5.17.0-2-amd64-x86_64-with-glibc2.33

GEOS, GDAL, PROJ INFO
-
GEOS   : 3.10.3
GEOS lib   : /usr/lib/x86_64-linux-gnu/libgeos_c.so
GDAL   : 3.5.0
GDAL data dir: /usr/share/gdal
PROJ   : 9.0.0
PROJ data dir: /usr/share/proj

PYTHON DEPENDENCIES
---
geopandas  : 0.10.2
pandas : 1.3.5
fiona  : 1.8.21
numpy  : 1.21.5
shapely: 1.8.0
rtree  : 1.0.0
pyproj : 3.3.1
matplotlib : 3.5.1
mapclassify: None
geopy  : 2.2.0
psycopg2   : 2.9.2 (dt dec pq3 ext lo64)
geoalchemy2: None
pyarrow: None
pygeos : None


This suggests something is wrong in your environment.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1013187: python3-demjson fails to install

2022-06-18 Thread Adrian Bunk

Package: python3-demjson
Version: 2.2.4-6
Severity: serious

https://piuparts.debian.org/sid/fail/python3-demjson_2.2.4-6.log

...
  Setting up python3-demjson (2.2.4-6) ...
File "/usr/lib/python3/dist-packages/demjson.py", line 645
  class json_int( (1L).__class__ ):# Have to specify base this way to 
satisfy 2to3
   ^
  SyntaxError: invalid decimal literal
  dpkg: error processing package python3-demjson (--configure):
   installed python3-demjson package post-installation script subprocess 
returned error exit status 1

Bug#1013188: packagesearch: doesn't seem to search descriptions

2022-06-18 Thread Ross Boylan

Package: packagesearch
Version: 2.7.11+b2
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

packagesearch says it is searching the descriptions, but it doesn't seem to.

**To Reproduce**

1. Start packagesearch in the GUI (KDE for me)
2. Enter liblvm2 in the box labelled "search for pattern" on the upper left
3. hit enter
4. select liblvm2-dev in the bottom left pane.
5. The bottom right, with the default "Description" tab says "This package
contains files needed to develop applications that use the lvm2app library."
6. Return to the search box and enter lvm2app.  Hit enter.
7. Nothing appears in the lower left pane, i.e., no packages match.

Just in case, click on the "search descriptions" box just below the search box
and try again.  Still nothing.

**Expected Outcome**
Since liblvm2-dev has lvm2app in its description, it would show up in the
bottom left when I entered that search term in the top left.

**Comment**

I'm pretty sure this worked in Debian 10.

apt is set to use amd64 and i386 on this system.



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

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

Versions of packages packagesearch depends on:
ii  apt   2.2.4
ii  apt-xapian-index  0.52
ii  debtags   2.1.5
ii  libapt-pkg6.0 2.2.4
ii  libc6 2.31-13+deb11u3
ii  libept1.6.0   1.2.1
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5xml55.15.2+dfsg-9
ii  libstdc++610.2.1-6
ii  libxapian30   1.4.18-3
ii  xterm 366-1+deb11u1

Versions of packages packagesearch recommends:
ii  apt-file   3.2.2
ii  deborphan  1.7.33

packagesearch suggests no packages.


-BEGIN PGP SIGNATURE-

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmKuEEYeHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytgQWoH/3rlS4Ik8WZd3jJu
ms3piiFkEkfQxpuseh+hq3L5iBo5WOvFE5+KyxNAyUHTMLQTgHF/xjtad9ksSF/S
v2KdeL7Si7se3Jy5aMnaNFJD/LyhkpTG+EG5mHuczy07tqJCdUSPWg/Hw33alOtq
LuZfVSgBWDXiMNrXQhN4j1YE9PCeIpfmRFCT4Rh5ywvcby/7XabqmOzbqgAgAYPA
nQBJ7B9AzbCrp+xnI/hsd2ryHOW17aD8JxQmOp9BeJ5Ay2izaFCAbjCUG5I4e/g/
QQ0JKSMkxwJBmTdeNGw8lck/HIR4FpMHiKgEH3M4zu+BlkonLKSjJ3Z+apoXJvO2
wZs3W1E=
=WKZ8
-END PGP SIGNATURE-

Bug#1013186: python3-geopandas: geopandas is missing PROJ data directory

2022-06-18 Thread Akkana Peck

Package: python3-geopandas
Version: 0.10.2-1
Severity: normal
X-Debbugs-Cc: d...@shallowsky.com

Dear Maintainer,

import geopandas
results in the following warning:

/usr/lib/python3/dist-packages/pyproj/__init__.py:91: UserWarning: Valid PROJ 
data directory not found. Either set the path using the environmental variable 
PROJ_LIB or with `pyproj.datadir.set_data_dir`.
  warnings.warn(str(err))

If I create a new pythonenv and install geopandas there, e.g.:

python3 -m venv /path/to/new/env
source /path/to/new/env/bin/activate
pip install geopandas

then I can import geopandas without the warning.

I'm new to geopandas, just trying to work through some tutorials,
so I'm not sure yet how often this proj dir will be needed or how
important it is; the cartopy tutorial still works without it (I
guess it's getting its projections from cartopy instead of
geopandas).


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

Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-geopandas depends on:
ii  python3  3.10.4-1+b1
ii  python3-fiona1.8.21-1+b1
ii  python3-numpy1:1.21.5-1
ii  python3-pandas   1.3.5+dfsg-4
ii  python3-pyproj   3.3.1-1
ii  python3-shapely  1.8.0-1+b1
ii  python3-six  1.16.0-3

Versions of packages python3-geopandas recommends:
pn  python3-descartes   
pn  python3-geopy   
ii  python3-matplotlib  3.5.1-2+b1
ii  python3-psycopg22.9.2-2
pn  python3-rtree   

python3-geopandas suggests no packages.

-- no debconf information

Bug#1013185: python3-defaults: Python Policy missing from doc-base

2022-06-18 Thread David (Plasma) Paul

Source: python3-defaults
Version: 3.10.4-1
Severity: normal

Dear Maintainer,

The Python Policy[0] is missing from the Debian doc-base[1][2] system.
In the debian directory of the python3-defaults source package there is
a file, 'python.doc-base.python-policy'[3], that appears to have been
copied over from the earlier python-defaults source package. (The
description in that file refers to Python Policy as still having a
draft status which I don't think has been true for quite a while. The
file 'README.Debian' in the debian directory also refers to the Python
Policy as a draft. That file also refers to a python3.6 directory as if
it that is the current release of python, so that file should probably
be updated or deleted.) Because the filename
'python.doc-base.python-policy' starts with 'python.', it doesn't
correspond to any current binary package, so dh_installdocs[4] doesn't
end up installing it anywhere.

Starting with python3-defaults 3.9.2-1, the Python Policy was converted
from DocBook to Sphinx format. The file 'python.doc-base.python-policy'
still mentions the DocBook format, so that will need to be updated.
Also starting from that version, the generated HTML version of the
Python Policy files were moved to the python3-dev binary package, but
the generated plaintext version of the policy was left in the python3
package. AIUI, the doc-base system doesn't really support multiple
formats of the same document in different binary packages. All included
formats of a document need to be in the same binary package. It is,
of course, up to you how you'd like to resolve that, whether that means
moving the plaintext version to python3-dev, moving the HTML back to
python3, dropping the plaintext version, whatever.

[0] https://www.debian.org/doc/packaging-manuals/python-policy/
[1] https://www.debian.org/doc/debian-policy/ch-opersys.html#s-doc-base
[2] /usr/share/doc/doc-base/doc-base.html/index.html
[3]
https://sources.debian.org/src/python3-defaults/3.10.4-1/debian/python.doc-base.python-policy/
[4]
https://manpages.debian.org/bookworm/debhelper/dh_installdocs.1.en.html#debian/~5

--
Plasma

Bug#873955: another alternative

2022-06-18 Thread Antoine Beaupré

I'm kind of abusing this RFP here, but what the heck, I don't know where
else to put this.

I've been relunctant to start using selfspy because of the obvious
privacy and security implications of constantly running a keylogger on
my computer. So I'm looking at alternatives.

There's two things I want this thing to do:

 1. monitor the *number* and *amount* of keystrokes and mouse movement,
to give an idea of how badly I'm working (too much)

 2. figure out *what* I'm working on, for time tracking purposes like
billing

Workrave is what I currently use for the former, and it kind of works,
but it's really hard to pull the data out of there. It does nothing for
the latter.

Selfspy does both, but at a tremendous cost: it keeps all keystrokes in
a database! Ouch. That's not a requirement *I* have.

So timetrack is the other option I found:

https://github.com/joshmcguigan/timetrack

It keeps track of which *files* you're working on, using filesystem
monitoring tools. I am not sure it will work for things like "I am
writing to the BTS now" or "I'm wasting time on Hacker News" because
files are not involved there, but I found it was an interesting enough
approach that it was worth mentionning.

But once you step into timetracking territory, there's a *lot* of tools
that do things like that out there...

https://mjasnik.gitlab.io/timekpr-next/ (in Debian)
https://github.com/tagtime/TagTime
https://github.com/kimmobrunfeldt/git-hours
https://timesnapper.com/
https://hackage.haskell.org/package/arbtt (in Debian)
https://activitywatch.net/ (#990173)

The last two are especially interesting, I find. Activity Watch, in
particular, watches windows with all sorts of hooks in web browsers or
editors to figure out what's going on in there. It doesn't seem to keep
track of keystrokes, but maybe that's better left to a tiny little tool
instead.

In fact, I wonder if the kernel's input devices don't already have
counters for that kind of stuff we can use. Surely the kernel counts
keystrokes, right? :)

a.

-- 
We reject kings, presidents and voting.
We believe in rough consensus and running code.
- David Clark

Bug#1013177: ITP: mate-user-admin -- MATE User Manager

2022-06-18 Thread Simon McVittie

On Sat, 18 Jun 2022 at 15:18:02 +0200, Mike Gabriel wrote:
>  User and group management utility suitable as an alternative
>  for gnome-system-tools on more lightweight desktop environments
>  such as MATE or Xfce.

gnome-system-tools has been dead upstream since 2012 (#888670), so please
avoid implying that it's what GNOME uses. For GNOME, the replacement is
gnome-control-center, but g-c-c is not designed for non-GNOME desktops
(it's a "system settings" utility for GNOME as an integrated environment,
so for example it assumes you're using GNOME Shell).

I would suggest:

 User and group management utility suitable as an alternative
 for gnome-control-center on more lightweight desktop environments
 such as MATE or Xfce.

or just

 User and group management utility suitable for lightweight desktop
 environments such as MATE or Xfce.

If this is intended to replace current uses of gnome-system-tools in
MATE, Xfce and other GTK-based environments, describing it as a
replacement rather than an alternative might be appropriate, something
like this:

 User and group management utility suitable for lightweight desktop
 environments such as MATE or Xfce.
 .
 This utility is intended to replace the user-management functionality
 of the old gnome-system-tools package.

Thanks,
smcv

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

2022-06-18 Thread Zhang Boyang


Hello,

Thanks for making this program! I will definitely try it as soon as I 
finished my current work!


Thank you again :)

Best Regards,
Zhang Boyang

On 2022/6/15 19:17, Thomas Schmitt wrote:

Hi,

although it was not the final solution of this bug report, i beefed up
my merger script for Debian ISOs so that it can combine an arbitrary
number of ISOs (within the limits of /dev/loop* and mount(8)).
Maybe it can serve as answer for the next time this wish comes up.

Bug#1013175: python3-cattr: Please provide latest upstream release 22.1.0

2022-06-18 Thread Sandro Tosi

> (This bug is self-reported as I am part of the Debian Python Team, to
> tag the corresponding blocking bugs preventing this update currently)

do you know of any blockers?

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

Bug#1013183: src:datalad: invalid maintainer address

2022-06-18 Thread Ansgar

Source: datalad
Version: 0.16.5-1
Severity: serious
X-Debbugs-Cc: Yaroslav Halchenko 

The maintainer address for src:datalad is invalid, see below.

Ansgar

On Mon, 2022-06-13 at 14:11 +, Mail Delivery System wrote:
> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es)
> failed:
> 
>   t...@datalad.org
>     all hosts for 'datalad.org' have been failing for a long time and
> were last tried after this message arrived

Bug#1013184: bind9-dnsutils: dig returns an akamai server IP address when it should find nothing

2022-06-18 Thread Mike S


Package: bind9-dnsutils
Version: 1:9.16.27-1~deb11u1
Architecture: amd64

Dear Maintainer,

I needed to use docker under linux for testing purposes at work, where I 
only have a Windows 11 PC. I installed a vagrant box under hyper-v, and 
since I use bullseye on my own network at home, I chose the 
'generic/debian11' vagrant box.


I had problems with connectivity from containers via the docker 
'host-gateway', so started running tests.


I logged into a container and ran 'ping host-gateway' and found to my 
surprise that the target IP address was an external address and not my 
vagrant box (i.e. not actually the docker gateway host). This prevented 
messages from inside my docker containers being forwarded to the correct 
proxy.


I then ran 'dig host-gateway' on the container and on the debian11 
vagrant box, and got the IP address 23.217.138.108. I logged onto one of 
my home debian servers and confirmed that this is a public address 
mapped to an akamaitechnologies.com host name.


My home debian11 server did not initially exhibit the same issue, so I 
assumed there was something wrong with the vagrant box I was using, or 
possibly the vagrant deployment script. However, the resolv.conf files 
were pointing to different DNS servers - my server uses a local bind9 
service on my LAN, which forwards to my ISP, while the vagrant box 
configuration is using a few public DNS servers including 4.2.2.1 and 
4.2.2.2.


I thought I should also check if there was an issue with the DNS server, 
so I tried three further tests:


1) On the vagrant box I ran 'dig @[my local DNS server address] 
host-gateway'. This time I got the expected response (no ANSWER section, 
i.e. 'host-gateway not found'.


2) On my home server I ran 'dig @4.2.2.1 host-gateway', so forcing it to 
use the same DNS server that the vagrant box had been using. Now I once 
again got an ANSWER section including the address 23.217.138.108. My 
home server runs debian 11 on bare metal, so this is not an issue with 
vagrant or the vagrant box, or indeed with the Windows 11 hosting the box.


3) On my Windows PC I ran 'nslookup', set the DNS server to 4.2.2.1 and 
asked it for the address of 'host-gateway'. I got the expected response 
(service not found). This shows that this DNS server is not the source 
of the spurious address.


These tests appear to demonstrate that the problem is not in the vagrant 
deployment process, the vagrant box, or the DNS server at 4.2.2.1. The 
only common factor associated with the spurious reply is the Debian 11 
distro.


A few more tests revealed that this seems to happen whenever the 
requested host name ends with the string 'gateway', and the DNS server 
used is either 4.2.2.1 or 4.2.2.2. I did not get the same behaviour 
using 8.8.8.8, nor with my employer's DNS servers or my own server, but 
I didn't have time to try any others.


Obviously the case I stumbled on involved the docker 'host-gateway' 
name, which was chosen by docker because it should not resolve to any 
host on the Internet, allowing docker to insert its own binding with 
local scope. I don't know if the 'fake' ANSWER section is inserted when 
the real response contains an ANSWER. If yes, clients woud be unable to 
access the expected functions of the real server. If not, then clients 
would be directed to the wrong host only if there is no right host, so 
no functionality would be affected. But either way clients may send 
sensitive information to the akamaitechnologies host.


This seems to be very significant. Something seems to be recognising DNS 
requests to 4.2.2.1, and injecting a fake ANSWER section in the reply, 
directing clients to an akamaitechnologies host.


It seems possible this behaviour may be the result of malicious 
contamination rather than an accidental bug.



-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-15-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bind9-dnsutils depends on:
ii bind9-host [host] 1:9.16.27-1~deb11u1
ii bind9-libs 1:9.16.27-1~deb11u1
ii libc6 2.31-13+deb11u3
ii libedit2 3.1-20191231-2+b1
ii libidn2-0 2.3.0-5
ii libkrb5-3 1.18.3-6+deb11u1
ii libprotobuf-c1 1.3.3-1+b2

bind9-dnsutils recommends no packages.

bind9-dnsutils suggests no packages.

Bug#1013180: Undelivered Mail Returned to Sender

On zaterdag 18 juni 2022 17:13:33 CEST you wrote:
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> : host scaledteam.ru[81.30.221.145] said: 550 5.1.1
> : Recipient address rejected: User unknown in
> local recipient table (in reply to RCPT TO command)

Close now or wait some days?

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

Bug#1013182: twopaco FTBFS with oneTBB 2021.5.0

2022-06-18 Thread Adrian Bunk

Source: twopaco
Version: 0.9.4+dfsg-1
Severity: serious
Tags: ftbfs
Forwarded: https://github.com/medvedevgroup/TwoPaCo/issues/28

https://buildd.debian.org/status/logs.php?pkg=twopaco&ver=0.9.4%2Bdfsg-1

...
In file included from /<>/src/common/streamfastaparser.cpp:4:
/<>/src/common/streamfastaparser.h:8:10: fatal error: tbb/mutex.h: 
No such file or directory
8 | #include 
  |  ^
compilation terminated.

Bug#1013180: linux-image-5.18.0-1-amd64: System doesn't go to sleep in 5.18.0-1 kernel

On Saturday, 18 June 2022 16:28:57 CEST Alexandr Podgorniy wrote:
> Dear Maintainer, System doesn't go to sleep in 5.18.0-1 kernel, but it's
> fine in 5.16 and 5.15. System tries to go to sleep, but then it wakes up
> immidiately. 

This may be the same as #1012054 so please try if the problem is still present 
with the recently uploaded 5.18.5 version

> Dmesg shows some stacktrace-something after trying to sleep.

If it isn't fixed, sharing such info is expected. 

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

Bug#1013181: freerdp2-wayland: ERRCONNECT_TLS_CONNECT_FAILED with libssl3 and Server 2008 R2

2022-06-18 Thread Kevin Locke

Package: freerdp2-wayland
Version: 2.7.0+dfsg1-1+b1
Severity: normal

Dear Maintainer,

Attempting to connect to a computer running Remote Desktop Services on
Windows Server 2008 R2 (with default settings as far as I am aware)
using FreeRDP 2.7.0+dfsg1-1+b1 with default options fails with:

$ wlfreerdp /v:192.168.0.2
[08:00:38:003] [283611:283611] [ERROR][com.freerdp.core] - 
transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED 
[0x00020008]
[08:00:38:005] [283611:283611] [ERROR][com.freerdp.client.wayland] - Failed to 
connect

Using FreeRDP 2.7.0+dfsg1-1 (or 2.6.1+dfsg1-3+b1) works as expected.

This appears to be the same issue as Debian Bug 912206.  However, it
is now necessary to use seclevel 0 (by adding
/tls-ciphers:DEFAULT@SECLEVEL=0 or /tls-seclevel:0) rather than 1.

Since Server 2008 R2 is no longer generally supported, I wouldn't
recommend decreasing the default seclevel (unless there are other
supported RDP server versions which require it) but it would be nice
if the error message gave users some suggestions for likely causes of
ERRCONNECT_TLS_CONNECT_FAILED and how to address them.

Thanks,
Kevin


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

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

Versions of packages freerdp2-wayland depends on:
ii  libc6 2.33-7
ii  libfreerdp-client2-2  2.7.0+dfsg1-1+b1
ii  libfreerdp2-2 2.7.0+dfsg1-1+b1
ii  libuwac0-02.7.0+dfsg1-1+b1
ii  libwinpr2-2   2.7.0+dfsg1-1+b1

freerdp2-wayland recommends no packages.

freerdp2-wayland suggests no packages.

-- no debconf information

Bug#1012870: dbus-daemon

2022-06-18 Thread Jakob Unterwurzacher

earlyoom author here.

I have never seen dbus-daemon use more memory than firefox.
Is there an unfixed memory leak in the Debian version of dbus-deamon?

Bug#1013180: linux-image-5.18.0-1-amd64: System doesn't go to sleep in 5.18.0-1 kernel

2022-06-18 Thread Alexandr Podgorniy

Package: linux-image-5.18.0-1-amd64
Version: 5.18.0-1
Severity: normal
X-Debbugs-Cc: sac...@scaledteam.ru

Dear Maintainer, System doesn't go to sleep in 5.18.0-1 kernel, but it's fine
in 5.16 and 5.15. System tries to go to sleep, but then it wakes up
immidiately. Dmesg shows some stacktrace-something after trying to sleep.
Nvidia proprietary driver is installed on the system.


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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.18.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.141
ii  kmod29-1+b1
ii  linux-base  4.9

Versions of packages linux-image-5.18.0-1-amd64 recommends:
ii  apparmor 3.0.4-2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.18.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-3
pn  linux-doc-5.18

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

2022-06-18 Thread Ben Hutchings

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
[...]
> Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
> or 0.0015%
[...]

Or maybe not so incidentally: 4,967,591 / 2^16 ~= 75

Ben.


-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

2022-06-18 Thread Ben Hutchings

On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
[...]

> linux-image-4.19.0-17-amd64 4.19.194-1 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-2 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-3 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
[...]
> A significant pattern visible here is a short signature for the same
> module in multiple consecutive versions, where the module may have
> identical contents.  That implies that this is a reproducible issue for
> certain inputs that cannot be worked around by re-running the signing
> process.
>
> However, I have *not* yet verified that all short signatures really are
> invalid.

These module files are indeed identical, and their signatures are
rejected by the kernel.

I'm now looking at whether the missing bytes are recoverable (e.g. are
they always zeroes).

Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
or 0.0015%, so it's not surprising that other source packages have not
yet been affected.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


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

Bug#992131: R8169 CRASH! (rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100))

2022-06-18 Thread a...@prnet.info

I have seen these lines too yesterday on Debian 11, but on Linux 
5.15.0-0.bpo.3-amd64.
kernel: r8169 :03:00.1 eno1: rtl_txcfg_empty_cond == 0 (loop: 42, 
delay: 100).
kernel: r8169 :03:00.1 eno1: rtl_rxtx_empty_cond == 0 (loop: 42, 
delay: 100).
Out of sudden like 2 times, "nmcli network off && nmcli network on" 
helped to temporarily make interface working.
No big updates recently. Only these from apt log: 
https://paste.nolog.cz/?fc818de693f3fd26#ETu59xDaCm4Yeqv8PP4ch8ijdbwjaiuSLSgM2ESqWDhJ

Bug#1013078: New astropy breaks pyregion autopkgtest

2022-06-18 Thread Vincent Prat

Control: found -1 2.1.1-1

Bug#1012850: scribus: Please update for Poppler 22.06

2022-06-18 Thread Mattia Rizzolo

Hi,

On Wed, Jun 15, 2022 at 12:10:27PM -0300, Nathan Pratta Teodosio wrote:
> Since Poppler 22.06 made its way into experimental, Scribus will need
> compatibility changes that are already in upstream to build.
> 
> I cherry-picked the relevant changes in the attached patches. However, 
> although
> they apply fine with `patch` on the .orig, the patches won't apply with
> `debuild`, and I couldn't figure out why. I'm hoping you will spot it faster
> than I.

Well, you also included one patch ("#16734: Build break with poppler
22.2.0") that is already included in the package, there is little
surprise there.  And extra problem is that one patch has broken
newlines, messing with the new patches (I don't know if that's a quirk
of the svn→git export, or what, but I don't care so I replaced it with
the proper SVN patch instead).
And one change (the one bumping the required poppler version) is not
needed.  I guess you picked changes from the master branch instead of
v15x branch?

Also, note that scribus' original VCS is SVN, so please at least point
out where those commits where coming from.  And it would probably be
best to attach them in the form of patches, not plain diffs (so at least
they get authorship information, comments, probably also the svn-git
connection that would have made my life easier in finding the original
svn commits).

I'll soon be uploading a version with these changes, however I'd
appreciate if somebody else could test-build against poppler 22.06, as
I'm kind of overloaded at this time.

And if you are involved in poppler, I'd also appreciate if you could
work on https://bugs.debian.org/969907 (or point it to somebody
(jbicha?)), as it's IMHO being underestimated.

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#1013179: likwid: ships /usr/lib//libhwloc.so{,.5}

2022-06-18 Thread Andreas Beckmann

Package: likwid
Version: 5.2.1+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

  Selecting previously unselected package likwid.
  Preparing to unpack .../likwid_5.2.1+dfsg1-2_amd64.deb ...
  Unpacking likwid (5.2.1+dfsg1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/likwid_5.2.1+dfsg1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libhwloc.so', which is also 
in package libhwloc-dev:amd64 2.7.1-1
  Errors were encountered while processing:
   /var/cache/apt/archives/likwid_5.2.1+dfsg1-2_amd64.deb

These hwloc symlinks don't belong into likwid.


Andreas

Bug#1013178: transition: ceres-solver

2022-06-18 Thread Francois Mazen

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: franc...@mzf.fr

Dear release team,

I and Pierre Gruet (pgt@d.o) would like to transition ceres-solver to the new
SOVERSION (3).

The upstream changed the SOVERSION of the package without changing the major
version number (2.1.0). That's why we missed this ABI change, and Pierre
reverted the upload by uploading a new package with the +really suffix
(2.1.0+really2.0.0).
Upstream does not follow semantic versioning and confirmed that this behavior
is intentional [1].
So, a transition process is needed for the Debian package to handle this
SOVERSION update.

All reverse dependencies are building fine at least on amd64 [2].

Best Regards,
François

[1] https://github.com/ceres-solver/ceres-solver/issues/824
[2]
https://buildd.debian.org/status/package.php?p=colmap,openturns,sight&compact=compact


Ben file:

title = "ceres-solver";
is_affected = .depends ~ "libceres2" | .depends ~ "libceres3";
is_good = .depends ~ "libceres3";
is_bad = .depends ~ "libceres2";

Bug#1012316: dahdi-dkms: fails to build modules for Linux 5.17

2022-06-18 Thread Tzafrir Cohen

There are tons of warnings

The actual error is:

On Fri, Jun 03, 2022 at 10:23:00PM +0200, Andreas Beckmann wrote:
> /var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.5/build/drivers/dahdi/xpp/xbus-core.c:
>  In function 'xbus_read_proc_open':
> /var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.5/build/drivers/dahdi/xpp/xbus-core.c:1841:50:
>  error: implicit declaration of function 'PDE_DATA'; did you mean 
> 'NODE_DATA'? [-Werror=implicit-function-declaration]
>  1841 | return single_open(file, xbus_proc_show, PDE_DATA(inode));
>   |  ^~~~
>   |  NODE_DATA

that is also used in several other places in the code. Need to use
pde_data() in 5.17.

I wrote a patch, and then noticed that the build also fails with 5.18:

  CC [M]  
/home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.o
/home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:
 In function ‘wctdm_init_one’:
/home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2657:21:
 error: implicit declaration of function ‘pci_alloc_consistent’ 
[-Werror=implicit-function-declaration]
 2657 |wc->writechunk = pci_alloc_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 
* 2 * 2 * 4, &wc->writedma);
  | ^~~~
/home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2657:19:
 warning: assignment to ‘volatile unsigned int *’ from ‘int’ makes pointer from 
integer without a cast [-Wint-conversion]
 2657 |wc->writechunk = pci_alloc_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 
* 2 * 2 * 4, &wc->writedma);
  |   ^
/home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2677:5:
 error: implicit declaration of function ‘pci_free_consistent’ 
[-Werror=implicit-function-declaration]
 2677 | pci_free_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 * 2 * 2 * 4, 
(void *)wc->writechunk, wc->writedma);
  | ^~~
cc1: some warnings being treated as errors

BTW: as of two days ago or so, the official git repository and
potentially maybe also the bug tracker for dahdi-linux and dahdi-tools
are in Github:
https://github.com/asterisk/dahdi-linux
https://github.com/asterisk/dahdi-tools

I'm not completely sure what this means about requirements for CLA.

-- 
mail / xmpp / matrix: tzaf...@cohens.org.il

Bug#1012532: inkscape: PDF import no longer works

2022-06-18 Thread Mattia Rizzolo

Control: reassign -1 libpoppler-glib8
Control: forcemerge 969907 -1

On Wed, Jun 08, 2022 at 02:05:58PM -0700, Graeme Smecher wrote:
> Hi Dennis,
> 
> On 2022-06-08 13:35, Dennis Braun wrote:
> > This looks very similar to this old bug
> > https://bugs.launchpad.net/inkscape/+bug/1276871
> 
> On a hunch, I ensured libpoppler was up-to-date - an apt-get upgrade
> libpoppler* corrected the problem and I am now able to import PDFs again.

From your first mail:
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler118  22.02.0-3

So this is yet another case of libpoppler that gets out of sync with
libpoppler-glib and then something doesn't work.
It's not as bad as the crash #969907 but I blame it to that all the
same, without further debugging.

As such, I'm reassiging and merging.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1012723: runc 1.0.0~rc93+ds1-5+deb11u2 flagged for acceptance

package release.debian.org
tags 1012723 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: runc
Version: 1.0.0~rc93+ds1-5+deb11u2

Explanation: honour seccomp defaultErrnoRet; do not set inheritable 
capabilities [CVE-2022-29162]

Bug#1012723: runc 1.0.0~rc93+ds1-5+deb11u1 flagged for acceptance

package release.debian.org
tags 1012723 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: runc
Version: 1.0.0~rc93+ds1-5+deb11u1

Explanation: honour seccomp defaultErrnoRet

Bug#1012585: libintl-perl 1.26-3+deb11u1 flagged for acceptance

package release.debian.org
tags 1012585 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libintl-perl
Version: 1.26-3+deb11u1

Explanation: really install gettext_xs.pm

Bug#1008268: tigervnc 1.11.0+dfsg-2+deb11u1 flagged for acceptance

package release.debian.org
tags 1008268 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: tigervnc
Version: 1.11.0+dfsg-2+deb11u1

Explanation: fix GNOME desktop start up when using tigervncserver@.service; fix 
colour display when vncviewer and X11 server use different endianness

Bug#1010050: clementine 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1 flagged for acceptance

package release.debian.org
tags 1010050 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: clementine
Version: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1

Explanation: add missing dependency on libqt5sql5-sqlite

Bug#1008577: golang-github-russellhaering-goxmldsig 1.1.0-1+deb11u1 flagged for acceptance

package release.debian.org
tags 1008577 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: golang-github-russellhaering-goxmldsig
Version: 1.1.0-1+deb11u1

Explanation: fix null pointer dereference caused by crafted XML signatures 
[CVE-2020-7711]

Bug#1009077: minidlna 1.3.0+dfsg-2+deb11u1 flagged for acceptance