Bug#1014372: ITP: journal-brief -- Show interesting new systemd journal entries

[Marc Haber]

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

* Package name: journal-brief
  Version : 1.1.8
  Upstream Author : Tim Waugh 
* URL : https://github.com/twaugh/journal-brief
* License : GPL-2+
  Programming Lang: Python
  Description : Show interesting new systemd journal entries

 This program can be used to show entries from the systemd
 journal with configurable, flexible filters. Cursor files
 are used to keep information about when journal-brief was
 run for the last time and starts from there. journal-brief
 can output to stdout or send via SMTP.
 .
 journal-brief can, for example, be used to send out e-mail
 after a systemd timer was run, imitating cron's behavior.

Bug#1014311: ftp.debian.org: Signing service occasionally generates bad 254-byte signatures

[Daniel Lewart]

Does the signing service use a non-free YubiKey?

Thank you!
Dan
Urbana, Illinois

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

[Daniel Lewart]

It's like déjà vu all over again:
#942881 - snd-hda-codec-hdmi signature corruption
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881

Thank you!
Dan
Urbana, Illinois

Bug#826283: ITA: apngdis -- deconstruct APNG file into a sequence of PNG frames

[肖盛文]

Control: retitle -1 ITA: apngdis -- deconstruct APNG file into a 
sequence of PNG frames

Control: owner -1 atzli...@sina.com


--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014354: depmod: WARNING: could not open modules.builtin.modinfo

[Marco d'Itri]

On Jul 04, Sebastien KALT  wrote:

> Since update to kmod version 30+20220630-1, I have this warning when launching
> (via apt upgrade or manually) :
#1014319 actually.
It's harmless.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1013662: core-async-clojure: FTBFS: make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1

[Jérôme Charaoui]

Hello,

I'm unable to reproduce this bug locally.

When I diff, the build logs, the only relevant element I can find is 
that in my build environment, the "clojure_1.10.3-1" package is 
installed, whereas in the failing build log, it appears to be absent.


I think it would be worth it to attempt to build it again.

Thanks,

-- Jerome

Bug#1014371: bind9-libs: SIGIOT when nslookup

[Yangfl]

Package: bind9-libs
Version: 1:9.18.1-1

When nslookup, libisc aborts due to SIGIOT. This happens from time to
time. Two examples:

$ nslookup xx
netmgr/netmgr.c:1703: REQUIREhandle) != ((void *)0) && ((const
isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H')
<< 8 | ('D' && extension ({ auto_type __atomic_load_ptr =
(&(handle)->references); __typeof ((void)0, *__atomic_load_ptr)
__atomic_load_tmp; __atomic_load (__atomic_load_ptr,
&__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back
trace
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x369ef)[0x7f87f58369ef]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc_assertion_failed+0xa)[0x7f87f583694a]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nmhandle_attach+0x63)[0x7f87f581fb03]
nslookup(+0xeb8a)[0x5565de836b8a]
nslookup(+0xfa85)[0x5565de837a85]
nslookup(+0x11f2b)[0x5565de839f2b]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_async_readcb+0xad)[0x7f87f58230fd]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_readcb+0x97)[0x7f87f5823227]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x31f88)[0x7f87f5831f88]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_udp_read_cb+0x46)[0x7f87f5833896]
/lib/x86_64-linux-gnu/libuv.so.1(+0x1f24b)[0x7f87f57b524b]
/lib/x86_64-linux-gnu/libuv.so.1(+0x22f75)[0x7f87f57b8f75]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x114)[0x7f87f57a58c4]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x24a6a)[0x7f87f5824a6a]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__trampoline_run+0x16)[0x7f87f585eb56]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7d80)[0x7f87f5da5d80]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f87f532176f]
[1]6808 IOT instruction  xx

...some successful runs

$ nslookup -timeout=2 xx
;; Got SERVFAIL reply from 50.50.1.46, trying next server
netmgr/netmgr.c:1703: REQUIREhandle) != ((void *)0) && ((const
isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H')
<< 8 | ('D' && __extension__ ({ __auto_type __atomic_load_ptr =
(&(handle)->references); __typeof__ ((void)0, *__atomic_load_ptr)
__atomic_load_tmp; __atomic_load (__atomic_load_ptr,
&__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back
trace
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x369ef)[0x7f488a4369ef]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc_assertion_failed+0xa)[0x7f488a43694a]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nmhandle_attach+0x63)[0x7f488a41fb03]
nslookup(+0xeb8a)[0x562945d16b8a]
nslookup(+0xfa85)[0x562945d17a85]
nslookup(+0x11f2b)[0x562945d19f2b]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_async_readcb+0xad)[0x7f488a4230fd]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_readcb+0x97)[0x7f488a423227]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x31f88)[0x7f488a431f88]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__nm_udp_read_cb+0x46)[0x7f488a433896]
/lib/x86_64-linux-gnu/libuv.so.1(+0x1f24b)[0x7f488a37124b]
/lib/x86_64-linux-gnu/libuv.so.1(+0x22f75)[0x7f488a374f75]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x114)[0x7f488a3618c4]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(+0x24a6a)[0x7f488a424a6a]
/lib/x86_64-linux-gnu/libisc-9.18.1-1-Debian.so(isc__trampoline_run+0x16)[0x7f488a45eb56]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7d80)[0x7f488a38ad80]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f4889f2176f]
[1]8320 IOT instruction  nslookup -timeout=2 xx

Bug#1014370: wordwarvi: shows wrong (negative) lines/sec value

[Nobuhiro Ban]

Package: wordwarvi
Version: 1.0.4-2
Severity: minor
Tags: patch

Dear Maintainer,

wordwarvi shows some metrics before quitting the game.
But the lines/sec value is negative, clearly wrong.

>ban@blackbox$ wordwarvi
(snip)
>363 frames / 12 seconds, 30.25 frames/sec
>Total lines = 476481, lines/sec = -1656883213.999712
>ban@blackbox$

This patch will fix it:
--- wordwarvi-1.0.4.orig/wordwarvi.c
+++ wordwarvi-1.0.4/wordwarvi.c
@@ -11340,7 +11340,7 @@ void really_quit()
  (0.0 + nframes) / (0.0 + end_time.tv_sec - start_time.tv_sec));
  printf("Total lines = %lu, lines/sec = %f\n", total_line_count,
  (double) total_line_count /
- (double) end_time.tv_sec - start_time.tv_sec);
+ (double) (end_time.tv_sec - start_time.tv_sec));
  destroy_event();
 }


Regards,
Nobuhiro Ban

Bug#1014369: Regression: incorrect icon used in 0.8.0

[Konomi Kitten]

Package: pasystray
Version: 0.8.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: konomikit...@gmail.com

Dear Maintainer,

After updating pasystray to 0.8.0 from 0.7.1 the icon displayed in the systray
no longer respects the theme set by the user. I've reported this bug upstream
[1].

[1] https://github.com/christophgysin/pasystray/issues/161


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

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

Versions of packages pasystray depends on:
ii  adwaita-icon-theme  42.0-2
ii  libavahi-client30.8-6
ii  libavahi-common30.8-6
ii  libavahi-glib1  0.8-6
ii  libayatana-appindicator3-1  0.5.91-1
ii  libc6   2.33-7
ii  libglib2.0-02.72.3-1
ii  libgtk-3-0  3.24.34-1
ii  libnotify4  0.7.12-1
ii  libpulse-mainloop-glib0 15.0+dfsg1-4+b1
ii  libpulse0   15.0+dfsg1-4+b1
ii  libx11-62:1.7.5-1

pasystray recommends no packages.

Versions of packages pasystray suggests:
pn  paman   
ii  paprefs 1.2-1
ii  pavucontrol 5.0-2
pn  pavumeter   
ii  pulseaudio-module-zeroconf  15.0+dfsg1-4+b1

-- no debconf information

Bug#1014368: dmesg: --human output not paged if less not installed

[http]

Package: util-linux
Version: 2.38
Severity: serious

The documentation for dmesg states that "A pager is enabled by default for --human output." However, if the less pager is not 
installed, the output is not sent to a pager unless the PAGER variable is set.


This means that there is a hard-coded and undocumented dependency on the less package for correct behaviour. At the least, this 
appears to be a violation of the Debian Policy Manual, section 3.5.

https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies

Possible solutions, not in any order:
- Default to the more pager (included in the same package as dmesg)
- Default to /etc/alternatives/pager
- Declare a dependency on sensible-utils, to use sensible-pager from that 
package
- Declare a dependancy on the less package
- Update documentation to reflect actual behaviour and suggest setting the 
PAGER variable

Temporary workaround:
- set PAGER to the preferred pager.



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

Kernel: Linux 5.16.0-5-powerpc
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  libblkid1 2.38-4
ii  libc6 2.33-7
ii  libcap-ng00.8.3-1
ii  libcrypt1 1:4.4.28-1
ii  libmount1 2.38-4
ii  libpam0g  1.4.0-13
ii  libselinux1   3.4-1
ii  libsmartcols1 2.38-4
ii  libsystemd0   251.2-2
ii  libtinfo6 6.3+20220423-2
ii  libudev1  251.2-7
ii  libuuid1  2.38-4
ii  util-linux-extra  2.38-4
ii  zlib1g1:1.2.11.dfsg-4

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
ii  util-linux-locales  2.38-4

Bug#1014367: ITP: xmrig-cuda -- NVIDIA CUDA plugin for XMRig

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ben Westover 
X-Debbugs-Cc: kwestover...@gmail.com
Severity: wishlist

* Package name: xmrig-cuda
  Version : 6.17.0
  Upstream Author : XMRig 
* URL : https://xmrig.com
* License : GPL-3+
  Programming Lang: C, C++, CUDA
  Description : NVIDIA CUDA plugin for XMRig

xmrig-cuda is a CUDA plugin for XMRig that adds support for CUDA mining
on NVIDIA graphics cards, which is faster than OpenCL in most cases.

This package will be in contrib, because while xmrig-cuda itself is
free, it depends on CUDA and the proprietary NVIDIA drivers which are
both in non-free. I will not be maintaining this package within a team,
so I will need a sponsor as I am not a DD.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014365: debian-keyring: README.gz contains information about a package that no longer exists in Debian

[Marcos Talau]

Package: debian-keyring
Version: 2022.06.26
Severity: normal

Dear Maintainer,

The "README.gz" file contains information about a package that no longer exists
in Debian.

This occurs in the first paragraph of the "Generate a key pair" section:

GPG is used for security, and security can be a bit tricky.
Please install the gnupg-doc package and read the GPG manual (located
in /usr/share/doc/gnupg-doc/GNU_Privacy_Handbook) before generating a
key pair. The actual generation is trivial. You must use at least
2048 bits, but 4096 bit RSA keys are recommended.

The "gnupg-doc" package was removed from Debian in the year 2016.


Best Regards,
mt

Bug#715491: Z I M B R A

[Webmail Admin]

 Z  I  M  B R A ZIMBRA EMAIL NOTICE
 
  This is to inform you that your mailbox personal Security key has expired. As 
we are upgrading our server  For your online safety  Click Here  to reactivate 
your key by upgrading your mail box.

Failure to do this may render your account inactive
 
 Upgrade Now  Best Regards,  2022© Mail Report

Bug#1013867: Don't use user ntpsec if package ntp is installed

[Richard Laager]

On 6/26/22 02:18, Klaus Ethgen wrote:

When package ntp is installed (from long history), the ntp daemon is
started by this /etc/init.d/ntp which uses user ntp:ntp. So all
auxiliary directories and files are owned by ntp:ntp.


I agree this is the expected "before" state.


When ntpsec starts to start the same daemon with ntpsec:ntpsec (which is
counter expected) the ntp daemon is not running properly and more over,
it is creating/changing some file rights so neither daemon is running
properly afterwards.


The expected transition behavior is:
- /etc/default/ntp is copied to /etc/default/ntpsec if and only if it 
was modified.
- /etc/ntp.conf is copied to /etc/ntpsec/ntp.conf, with ntp.drift and 
ntpstats paths updated.
- /etc/init.d/ntp should be renamed too, though that uses 
dpkg-maintscript-helper mv_conffile, which means I might be missing 
something (vs custom code that I can easily see what it is doing). Also, 
I can't recall if I've even tested this. Debian's default is systemd.


You'll have to be more specific about what's broken. A reproducible test 
case would be ideal.


If the problem is specific to sysvinit, your best bet is to submit a 
patch (to the ntpsec package).



Even better would be to drop that ntpsec:ntpsec user fully and use
ntp:ntp as this would be the expected user a ntp is running under.

And please, don't conflict for ntp package as usually ntp is managed by
configuration management which is depending on ntp init script named
ntp. Nobody would expect init script ntpsec!


The ntpsec package uses "ntpsec" all over the place because that was the 
decision made at the time that it was introduced to Debian, when both 
packages existed. I actually tried to use /etc/init.d/ntp for ntpsec. 
That turns out to not work, even in some cases contrary to documented 
behavior. Ultimately, other developers said that was a bad idea, and 
said I should namespace things separately. So that's what I did, for 
better and worse (and yes, it's some of each).


Even if the long term plan were to eliminate the "ntpsec" namespacing 
(e.g. match upstream ntpsec more closely)*, I don't think it's a good 
idea to attempt that now. That increases the number of transitions.


* I'm not even sure that we have a consensus that it is a good idea to 
do this rename at all, at least while the upstream "ntp" project still 
exists.


--
--
Richard

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Michael Biebl]

Since this appears to be a regression in v251, please file this upstream 
at https://github.com/systemd/systemd/issues


Thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009122: systemd-quotacheck : does not work on root file system

[Michael Biebl]

Control: tags -1 + upstream
On Fri, 8 Apr 2022 10:32:05 +0200 Laurent Bonnaud 
 wrote:

On 4/7/22 18:41, Laurent Bonnaud wrote:

> However I got it to work nevertheless by adding the "ro" mount option
> in /etc/fstab for the root file system

This "solves" the quotacheck problem, but unfortunately it has many other 
negative consequences, such as:

Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Swap process exited, 
code=exited, status=255/EXCEPTION
Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Failed with result 
'exit-code'.
Apr 08 05:01:29 hostname systemd[1]: Failed to activate swap /swapfile.

Apr 08 05:01:30 hostname systemd-tmpfiles[522]: rm_rf(/tmp): Read-only file 
system

Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service: Failed to set 
up mount namespacing: /run/systemd/unit-root/dev: Read-only file system
Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service: Failed at 
step NAMESPACE spawning /lib/systemd/systemd-timesyncd: Read-only file system

Such this "solution" can only be used as a "one shot" trick followed by a 
proper reboot with a rw file system.



I assume you are using stable.
Can you please test, if you can still reproduce this with v250 from 
bullseye-backports and if so, report this upstream at

https://github.com/systemd/systemd/issues

Thanks,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014364: firefox-esr: Indeed.com thinks my browser is out of date

[Tim McConnell]

Package: firefox-esr
Version: 91.11.0esr-1
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? went to Indeed.com
   * What exactly did you do (or not do) that was effective (or ineffective)?
View the web page
   * What was the outcome of this action? Get a banner saying my browser is out
of date
   * What outcome did you expect instead? Not to see that stupid banner.

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


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.18.0-2-rt-amd64 (SMP w/1 CPU thread; 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 firefox-esr depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-2
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.2-2
ii  libgtk-3-0   3.24.34-1
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libstdc++6   12.1.0-2
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxrender1  1:0.9.10-1.1
ii  procps   2:3.3.17-7+b1
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.4.2-1+b3

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.19.2-2+b2
ii  pulseaudio 15.0+dfsg1-4+b1

-- no debconf information

Bug#1014363: ITP: bash-it -- collection of community Bash commands and scripts for Bash

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: bash-it
  Version : 3.0.2
  Upstream Author : Bash-it Team
* URL : https://github.com/Bash-it/bash-it
* License : Expat
  Programming Lang: Shell
  Description : collection of community Bash commands and scripts for Bash

 Includes autocompletion, themes, aliases, custom functions, a few stolen
 pieces from Steve Losh, and more.
 .
 Bash-it provides a solid framework for using, developing and maintaining
 shell scripts and custom commands for your daily work. If you're using the
 Bourne Again Shell (Bash) regularly and have been looking for an easy way on
 how to keep all of these nice little scripts and aliases under control, then
 Bash-it is for you.
 .
 Stop polluting your ~/bin directory and your .bashrc file, fork/clone
 Bash-it and start hacking away.

Bug#1014362: Please, drop me from Uploaders

[David Prévot]

Source: pdf.js
Version: 2.6.347+dfsg-3
Severity: wishlist

Hi,

Please, drop me from Uploaders, as well as Debian Mozilla Extension
Maintainers. I haven’t contributed to this package in years, and don’t
intend to take care of it again. Also, since the Mozilla extension is
not built from this package anymore, there is little point keeping the
team as Uploaders.

Regards

David


signature.asc
Description: PGP signature

Bug#1014361: coreutils: du --time-style=/$TIME_STYLE error message wrong

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: minor

Dear Maintainer,

Quoth du(1):
--time-style=STYLE
  show times using STYLE, which can be: full-iso, long-iso, iso, or 
+FORMAT; FORMAT is interpreted like in 'date'

But:
  $ du LICENCE --time  --time-style=asd
  du: invalid argument ‘asd’ for ‘time style’
  Valid arguments are:
- ‘full-iso’
- ‘long-iso’
- ‘iso’
  Try 'du --help' for more information.
  $ TIME_STYLE=asd du LICENCE --time
  du: invalid argument ‘asd’ for ‘time style’
  Valid arguments are:
- ‘full-iso’
- ‘long-iso’
- ‘iso’
  Try 'du --help' for more information.

This is very obviously wrong:
  nabijaczleweli@tarta:~/code/voreutils/aac$ du LICENCE --time  
--time-style=+asd%Z
  5   asdCEST LICENCE

(Also, these seem to be prefix-matched, which is unnoted: try speccing
 the empty string ("ambiguous"), "l", or "la".)

Best,
наб

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

Kernel: Linux 5.10.0-15-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1008725: systemd-logind option KillUserProcesses=true kills mount.davfs of user mount units

[Michael Biebl]

Andreas,

can you please follow-up at the upstream bug report, specifically the 
question at

https://github.com/systemd/systemd/issues/23580#issuecomment-1174162464


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013700: Strangely rare pytest 7.x bug report

[Julian Gilbey]

Hi Carles,

It is utterly, utterly bizarre.  But I think I've found the problem.
There's a pytest.ini file in the package, but it's not copied into the
test directory.  So when pytest is run in the .pybuild directory, it
climbs all the way back up the directory tree to the python-qtpy-2.1.0
until it discovers the pytest.ini file there and uses that.  It sees
that we are requesting qtpy/tests, which it then expands into the
directory path .pybuild/cpython3_3.10_qtpy/build/qtpy/tests, starting
from the directory in which it found pytest.ini, and this causes the
breakage.

The solution is to copy the pytest.ini file into the .pybuild
directories by adding it to debian/pybuild.testfiles

Why this behaviour changed between pytest 6.x and pytest 7.x I don't
know; I don't see it obviously documented.  But that at least resolves
this problem.

Thanks for your help!

Best wishes,

   Julian

On Mon, Jul 04, 2022 at 08:39:32PM +0100, Carles Pina i Estany wrote:
> 
> Hi Julian,
> 
> On Jul/04/2022, Julian Gilbey wrote:
> > Hi Carles,
> > 
> > Thanks for your thoughts!  Yes, indeed that seems to be the issue.
> > But what I don't understand is why the import is turned into
> > .pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
> 
> I see how pytest does it (but keep reading)
> 
> > a longer path, and why only this package fails in this way.  Perhaps
> > this is the only package that has an import statement in
> > pytest_configure?
> 
> This I don't know and I'm curious, and it might help disecting the issue
> (or understanding it). Do you know of any other python3 package that you
> expected to fail? (using pytest in a similar way).
> 
> I might try to get both and follow what they do different (to hopefully
> know what is python-qtpy doing different :-) )
> 
> I'm sure that there are tons of packages that use pytest :-) I'm
> wondering if you had a good candidate.
> 
> Best regards,
> 
> > 
> > Best wishes,
> > 
> >Julian
> > 
> > On Mon, Jul 04, 2022 at 04:03:39PM +0100, Carles Pina i Estany wrote:
> > > 
> > > Hi,
> > > 
> > > I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
> > > wanted to have a look. I don't have a solution (I might look more
> > > another time if time permits) but I might have something that might help
> > > someone who knows the tools better.
> > > 
> > > I am not familiar with Python Debian packaging details/tools neither
> > > with pytest :-( so take all of this with a pinch of salt.
> > > 
> > > If it helps the error comes from:
> > > /usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
> > > it does:
> > > """
> > > if name.startswith('.'):
> > > if not package:
> > > msg = ("the 'package' argument is required to perform a 
> > > relative "
> > >"import for {!r}")
> > > raise TypeError(msg.format(name))
> > > """
> > > 
> > > When the import fails the "name" parameter of "import_modules" function
> > > is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
> > > from the hidden dirctory ".pybuild" as created by default by "pybuild".
> > > 
> > > I think that the initial "." is used only as a directory name but Python
> > > assumes that is a relative import requiring the package parameter.
> > > 
> > > Just to check my thoughts, and after running dpkg-buildpackage and
> > > failing let's try again:
> > > 
> > > $ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; 
> > > cd -
> > > Fails with the:
> > > 
> > > TypeError: the 'package' argument is required to perform a relative 
> > > import for '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
> > > /home/carles/git/python-qtpy
> > > 
> > > Then let's try to avoid the initial "." confusion:
> > > 
> > > $ mv .pybuild pybuild
> > > $ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd 
> > > -
> > > 
> > > It works.
> > > 
> > > I don't know why this is the only package affected by this though...
> > > 
> > > Hopefully it helps a bit!
> > > 
> > > On Jul/04/2022, Julian Gilbey wrote:
> > > > Dear all,
> > > > 
> > > > I wonder whether you might have any clue about
> > > > https://bugs.debian.org/1013700
> > > > I have mostly worked out the "cause" of the bug, but I haven't quite
> > > > got to the bottom of it.
> > > > 
> > > > When running the command
> > > > PYTHONPATH=. python3.10 -m pytest qtpy/tests
> > > > in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
> > > > message:
> > > > 
> > > > ImportError while loading conftest 
> > > > '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
> > > > TypeError: the 'package' argument is required to perform a relative 
> > > > import for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'
> > > > 
> > > > If the directory .pybuild is renamed to pybuild, the tests run without
> > > > a problem.  So there seems to be something funny about 

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

[Ansgar]

Hi,

On Mon, 2022-07-04 at 22:00 +0200, Ansgar wrote:
> The correct signature (using OpenSSL) has:
> 
> +---
> > 138 256:   OCTET STRING
> >    : 00 00 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6
> +---[ data.ko.p7s.success ]
> 
> The incorrect signature from the YK has:
> 
> +---
> > 138 254:   OCTET STRING
> >    : 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6 E7
> +---[ data.ko.p7s.fail ]
> 
> So there is also a wrong byte at the beginning.
> The incorrect signature also misses one byte at the end.

As a further test I tried a different PKCS#11 module:

Modify reproduce.sh and set

+---
| 
pkcs11_uri="pkcs11:token=Test%20Key;manufacturer=piv_II;model=PKCS%2315%20emulated"
| export PKCS11_MODULE_PATH=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
+---

This results in yet a different error:

+---
| 138 256:   OCTET STRING
|: 00 00 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C
+---

The total size is correct, but it includes one incorrect byte at the
beginning (byte #3, 0x82) and the last byte is missing.

I've attached this signature as well.

Ansgar




data.ko.p7s.fail-opensc
Description: Binary data

Bug#1013373: ITA: python-matrix-nio -- python no-IO library for the matrix chat protocol - Python3 library

[Jonas Smedegaard]

Hi Jochen,

Quoting Jochen Sprickerhof (2022-07-04 21:44:24)
> Control: retitle -1 ITA: python-matrix-nio -- python no-IO library for the 
> matrix chat protocol - Python3 library
> Control: owner -1 !
> 
> Hi Jonas,
> 
> I would like to adopt the python-matrix-nio, package as I use it with 
> weechat-matrix. I have experience with Python packages and pushed some 
> fixes (including the FTBFS) here: 
> 
> https://salsa.debian.org/jspricke/python-matrix-nio/-/commits/debian/master
> 
> I was not able to reproduce #1002380, would you agree to simply close 
> it?
> 
> Also, I'm part of the Matrix Packaging Team on Salsa but I was not 
> allowed to push to the python-matrix-nio repo there, can you give me 
> access?

Package was (not just offered for adoption but) *orphaned*, so you need
not ask my permission to adopt it, simply do so (as technically you
already did!).

I have now promoted you to owner in the Matrix team.  But really, you
shouldn't ask me specifically but ask the team about team issues like
that.


Enjoy,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1014358: src:why3: fails to migrate to testing for too long: blocked by dependency

[Paul Gevers]

Source: why3
Version: 1.4.1-2
Severity: serious
Control: close -1 1.5.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:why3 has been trying to migrate for 62 
days [2]. Hence, I am filing this bug. why3 is waiting for menhir to 
migrate, which is waiting for js-of-ocaml to migrate, which can't 
migrate because ocaml-logs somehow isn't in the right state (I don't 
understand how ocaml packaging works).


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

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

[Ansgar]

Hi,

I experimented a bit more and could reproduce the problem with a local
YK (Yubikey 4, Firmware 4.3.7) and a known private key and certificate.

The correct signature (using OpenSSL) has:

+---
| 138 256:   OCTET STRING
|: 00 00 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6
+---[ data.ko.p7s.success ]

The incorrect signature from the YK has:

+---
| 138 254:   OCTET STRING
|: 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6 E7
+---[ data.ko.p7s.fail ]

So there is also a wrong byte at the beginning.
The incorrect signature also misses one byte at the end.

The attached archive contains:

 - data.ko: random data to be signed
 - data.ko.p7s.fail: incorrect signature generated by YK4
 - data.ko.p7s.success: correct signature generated by OpenSSL
 - reproduce.sh: sign with YK4 (set serial# in the first lines)
 - reproduce2.sh: sign with OpenSSL
 - sign-file: make this a symlink to linux' sign-file
 - test.key: private key
 - test.pem: self-signed certificate

The test.{key,pem} need to be loaded in the Digital Signature (Slot 9c)
slot of the PIV application.

I haven't checked if this is reproducible with another YK with the same
data/key/cert, but it is reproducible with the same key.

Ansgar



ykcs11-signature-failure.tar.gz
Description: application/compressed-tar

Bug#1014357: coreutils: du -d0 documented to be the same as -s, but isn't, in two different ways

[наб]

Package: coreutils
Version: 8.32-4.1
Severity: normal

Dear Maintainer,

Quoth du(1):
   -d, --max-depth=N
  print  the total for a directory (or file, with --all) only if it 
is N or fewer levels below the command
  line argument;  --max-depth=0 is the same as --summarize

But:
  $ du -as /dev/null
  du: cannot both summarize and show all entries
  Try 'du --help' for more information.
  $ du -ad0 /dev/null
  0   /dev/null
  $ du -sd0 /dev/null
  du: warning: summarizing is the same as using --max-depth=0
  0   /dev/null
  $ du -ss /dev/null
  0   /dev/null

The -as invocation is as-expected (and even matches POSIX!).
The -ad0 one isn't: it should error the same way as -as.
The -sd0 one isn't either: ex def. if it's the same then it should be
equivalent to -ss (which, as expected, is equivalent to just -s).

A solution would be to either
  (a) make it /actually/ be -s, matching the documentation, or
  (b) stop lying in the documentation.

Best,
наб

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

Kernel: Linux 5.10.0-15-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1014355: adduser: ADD_EXTRA_GROUPS does not work

[Matt Barry]

Package: adduser
Version: 3.122~1
Severity: normal



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 adduser depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  passwd 1:4.11.1+dfsg1-2

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron4.1-0.1
ii  liblocale-gettext-perl  1.07-4+b2
ii  perl5.34.0-4

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

-- debsums errors found:
debsums: changed file /usr/share/man/man5/adduser.conf.5.gz (from adduser 
package)
debsums: changed file /usr/share/man/man8/adduser.8.gz (from adduser package)

Bug#1014356: update-exim4.conf.8 (second patch): remove unnecessary macos and split a too long line

[Bjarni Ingi Gislason]

Package: exim4-config
Version: 4.95-6
Severity: minor
Tags: patch

  Output from: mandoc -lint :

mandoc: update-exim4.conf.new:5:25: STYLE: normalizing date format to: TH June 
25, 2005
mandoc: update-exim4.conf.new:23:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:27:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:54:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:109:92: STYLE: input text line longer than 80 
bytes: in /etc/exim4/update...
mandoc: update-exim4.conf.new:146:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:152:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:161:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:215:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:322:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:334:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:340:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:342:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:346:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:351:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:357:2: WARNING: skipping paragraph macro: PP empty
mandoc: update-exim4.conf.new:365:2: WARNING: skipping paragraph macro: PP empty

 Patch (after patch in Debian Bug#1014347):

--- update-exim4.conf.new   2022-07-04 18:40:07.0 +
+++ update-exim4.conf.new.new   2022-07-04 18:49:29.0 +
@@ -20,11 +20,9 @@
 .SH NAME
 update\-exim4.conf \- Generate exim4 configuration files.
 .
-.LP
 .SH SYNOPSIS
 .B update\-exim4.conf [\-v|\-\-verbose] [\-h|\-\-help] [\-\-keepcomments] 
[\-\-removecomments] [\-o|\-\-output file]
 .
-.LP
 .SH OPTIONS
 .TP
 .I \-\-check
@@ -51,7 +49,6 @@ Remove comment lines from the output fil
 .I \-v|\-\-verbose
 Enable verbose mode
 .
-.LP
 .SH DESCRIPTION
 The script
 .B update\-exim4.conf
@@ -106,7 +103,8 @@ install your own handcrafted version as
 Exim will use this file if it exists and ignore the autogenerated one.
 Additionally you might want to set
 .I dc_eximconfig_configtype=none
-in /etc/exim4/update\-exim4.conf.conf to stop debconf from asking you 
questions about exim4.
+in /etc/exim4/update\-exim4.conf.conf to stop debconf from asking you
+questions about exim4.
 .
 .LP
 .B update\-exim4.conf
@@ -143,13 +141,11 @@ expressions that are expanded at run tim
 If the new configuration will be written to some other file, no
 validity checking occurs and that file will always be overwritten.
 .
-.LP
 .SH EXAMPLES
 You want to be able to check exim's queue as normal user: Generate a new
 file, e.g. /etc/exim4/conf.d/main/40_local_mailq, containing only the line
 .I queue_list_requires_admin = false
 .
-.LP
 .SH NOTES
 .B update\-exim4.conf
 changes the file permissions of the output file to the value of the environment
@@ -158,7 +154,6 @@ variable CFILEMODE. If CFILEMODE is neit
 Change this to 0640 if you are keeping sensitive information (LDAP credentials
 et. al.) in there.
 .
-.LP
 .SH CONFIGURATION VARIABLES
 All lists given in configuration variables are semicolon-separated. In
 the past, they used to be colon separated. This was changed to
@@ -212,7 +207,6 @@ no configuration at this time
 .PD
 .RE
 .
-.LP
 .TP
 .I dc_hide_mailname
 Boolean option that controls whether the local mailname in the headers of
@@ -319,7 +313,6 @@ macros.
 the package being installed for convenient inclusion in the
 configuration.
 .
-.LP
 .SH RECOMMENDED USAGE
 If you are running exim as daemon (as it is in the default setup of the
 Debian packages) you should not invoke
@@ -331,30 +324,24 @@ file. You should use
 .I invoke\-rc.d exim4 restart
 instead.
 .
-.LP
 .SH BUGS
 This manual page needs a major re-work. If somebody knows better groff
 than us and has more experience in writing manual pages, any patches
 would be greatly appreciated.
 .
-.LP
 .SH FILES
-.LP
 .TP
 .B /var/lib/exim4/config.autogenerated
 Exim's main configuration file
-.LP
 .TP
 .B /etc/exim4/exim4.conf
 Optional manually managed Exim main configuration file. Takes precedence over
 debconf managed one if it exists.
-.LP
 .TP
 .B /etc/exim4/update-exim4.conf.conf
 Configuration file being written by exim4-config maintainer scripts,
 which may be hand-edited, and is read as input by update-exim4.conf.
 .
-.LP
 .SH SEE ALSO
 .BR exim (8),
 .BR exim4-config_files (5),
@@ -362,7 +349,6 @@ which may be hand-edited, and is read as
 with debconf
 /usr/share/doc/exim4\-base/README.Debian.gz
 .
-.LP
 .SH AUTHOR
 Andreas Metzler 
 .br

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

Kernel: Linux 5.18.5-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, 

Bug#1013373: ITA: python-matrix-nio -- python no-IO library for the matrix chat protocol - Python3 library

[Jochen Sprickerhof]

Control: retitle -1 ITA: python-matrix-nio -- python no-IO library for the 
matrix chat protocol - Python3 library
Control: owner -1 !

Hi Jonas,

I would like to adopt the python-matrix-nio, package as I use it with 
weechat-matrix. I have experience with Python packages and pushed some 
fixes (including the FTBFS) here: 


https://salsa.debian.org/jspricke/python-matrix-nio/-/commits/debian/master

I was not able to reproduce #1002380, would you agree to simply close 
it?


Also, I'm part of the Matrix Packaging Team on Salsa but I was not 
allowed to push to the python-matrix-nio repo there, can you give me 
access?


Cheers Jochen

* Jonas Smedegaard  [2022-06-23 08:24]:

Package: wnpp
Severity: normal
X-Debbugs-Cc: Matrix Packaging Team , 
Debian Python Team 
Control: affects -1 src:python-matrix-nio

I intend to orphan the python-matrix-nio package.

The package description is:
Nio is a multilayered Matrix client library.
The underlying base layer doesn't do any IO on its own.
On top of the base layer,
a no-IO HTTP client implementation exists,
as well as a full fledged batteries included asyncio layer
using aiohttp.
.
Matrix is an open standard and lightweight protocol
for real-time communication.
.
This package provides matrix-nio module
for Python 3.

- Jonas



signature.asc
Description: PGP signature

Bug#1013700: Strangely rare pytest 7.x bug report

[Carles Pina i Estany]

Hi Julian,

On Jul/04/2022, Julian Gilbey wrote:
> Hi Carles,
> 
> Thanks for your thoughts!  Yes, indeed that seems to be the issue.
> But what I don't understand is why the import is turned into
> .pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or

I see how pytest does it (but keep reading)

> a longer path, and why only this package fails in this way.  Perhaps
> this is the only package that has an import statement in
> pytest_configure?

This I don't know and I'm curious, and it might help disecting the issue
(or understanding it). Do you know of any other python3 package that you
expected to fail? (using pytest in a similar way).

I might try to get both and follow what they do different (to hopefully
know what is python-qtpy doing different :-) )

I'm sure that there are tons of packages that use pytest :-) I'm
wondering if you had a good candidate.

Best regards,

> 
> Best wishes,
> 
>Julian
> 
> On Mon, Jul 04, 2022 at 04:03:39PM +0100, Carles Pina i Estany wrote:
> > 
> > Hi,
> > 
> > I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
> > wanted to have a look. I don't have a solution (I might look more
> > another time if time permits) but I might have something that might help
> > someone who knows the tools better.
> > 
> > I am not familiar with Python Debian packaging details/tools neither
> > with pytest :-( so take all of this with a pinch of salt.
> > 
> > If it helps the error comes from:
> > /usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
> > it does:
> > """
> > if name.startswith('.'):
> > if not package:
> > msg = ("the 'package' argument is required to perform a 
> > relative "
> >"import for {!r}")
> > raise TypeError(msg.format(name))
> > """
> > 
> > When the import fails the "name" parameter of "import_modules" function
> > is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
> > from the hidden dirctory ".pybuild" as created by default by "pybuild".
> > 
> > I think that the initial "." is used only as a directory name but Python
> > assumes that is a relative import requiring the package parameter.
> > 
> > Just to check my thoughts, and after running dpkg-buildpackage and
> > failing let's try again:
> > 
> > $ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
> > Fails with the:
> > 
> > TypeError: the 'package' argument is required to perform a relative import 
> > for '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
> > /home/carles/git/python-qtpy
> > 
> > Then let's try to avoid the initial "." confusion:
> > 
> > $ mv .pybuild pybuild
> > $ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
> > 
> > It works.
> > 
> > I don't know why this is the only package affected by this though...
> > 
> > Hopefully it helps a bit!
> > 
> > On Jul/04/2022, Julian Gilbey wrote:
> > > Dear all,
> > > 
> > > I wonder whether you might have any clue about
> > > https://bugs.debian.org/1013700
> > > I have mostly worked out the "cause" of the bug, but I haven't quite
> > > got to the bottom of it.
> > > 
> > > When running the command
> > > PYTHONPATH=. python3.10 -m pytest qtpy/tests
> > > in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
> > > message:
> > > 
> > > ImportError while loading conftest 
> > > '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
> > > TypeError: the 'package' argument is required to perform a relative 
> > > import for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'
> > > 
> > > If the directory .pybuild is renamed to pybuild, the tests run without
> > > a problem.  So there seems to be something funny about conftest.py
> > > (and removing all of the other files from the qtpy/tests directory
> > > except for the empty __init__.py gives the same error); here's a link
> > > to it:
> > > 
> > > https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py
> > > 
> > > But there doesn't seem to be anything out of the ordinary about this.
> > > So I am mystified: why does pytest 7.x seem to not give this error on
> > > any other Debian package?
> > > 
> > > The only solution I currently have for this package is skip the tests
> > > at build time and rely on autopkgtest to do them.
> > > 
> > > Best wishes,
> > > 
> > >Julian
-- 
Carles Pina i Estany
https://carles.pina.cat

Bug#1014354: depmod: WARNING: could not open modules.builtin.modinfo

[Sebastien KALT]

Package: kmod
Version: 30+20220630-1
Severity: normal

Dear Maintainer,

Since update to kmod version 30+20220630-1, I have this warning when launching
(via apt upgrade or manually) :

# update-initramfs -k 5.18.0-2-amd64 -u
update-initramfs: Generating /boot/initrd.img-5.18.0-2-amd64
depmod: WARNING: could not open modules.builtin.modinfo at
/tmp/user/0/mkinitramfs_BKkoUw/lib/modules/5.18.0-2-amd64: No such file or
directory

It doesn't seem to have any effect on my laptop, I can reboot and it seems
fully functional.

Regards,

Sébastien KALT


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

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

Versions of packages kmod depends on:
ii  libc6 2.33-7
ii  libkmod2  30+20220630-1
ii  liblzma5  5.2.5-2.1
ii  libssl3   3.0.4-2
ii  libzstd1  1.5.2+dfsg-1
ii  lsb-base  11.2

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

Bug#1014352: dpkg: error processing package initramfs-tools (--configure)

[Marc Haber]

On Mon, Jul 04, 2022 at 08:45:05PM +0200, g.l. gragnani wrote:
> I don't know if this is a bug in initramfs-tools or in lvm2 or something else.

That's #1014314 in lvm2.

Greetings
Marc

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

Bug#1014352: dpkg: error processing package initramfs-tools (--configure)

[g.l. gragnani]

Package: initramfs-tools
Version: 0.141
Severity: important

Dear Maintainer,
after the last upgrade I received the following message:
Setting up lvm2 (2.03.15-1) ...
Installing new version of config file /etc/lvm/lvm.conf ...
Installing new version of config file /etc/lvm/lvmlocal.conf ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.141) ...
update-initramfs: Generating /boot/initrd.img-5.18.0-2-amd64
E: /usr/share/initramfs-tools/hooks/lvm2 failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.18.0-2-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
Processing triggers for libc-bin (2.33-7) ...
Processing triggers for man-db (2.10.2-1) ...
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)


I don't know if this is a bug in initramfs-tools or in lvm2 or something else.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 77M Sep 17  2021 /boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1 root root 69M May  2 21:45 /boot/initrd.img-5.17.0-1-amd64
-rw-r--r-- 1 root root 70M May 23 21:10 /boot/initrd.img-5.17.0-2-amd64
-rw-r--r-- 1 root root 70M May 30 18:49 /boot/initrd.img-5.17.0-3-amd64
-rw-r--r-- 1 root root 70M Jul  3 20:03 /boot/initrd.img-5.18.0-2-amd64
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.18.0-2-amd64 
root=UUID=fa63bf8d-27fd-4705-aec9-8c451e1e7c0a ro quiet

-- resume
RESUME=UUID=60de0e0a-131e-4201-bc1c-590cce2025fe
-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
pktcdvd49152  0
sr_mod 28672  0
cdrom  73728  2 pktcdvd,sr_mod
8021q  40960  0
garp   16384  1 8021q
mrp20480  1 8021q
cdc_ether  24576  0
usbnet 53248  1 cdc_ether
mii16384  1 usbnet
uas32768  0
usb_storage81920  1 uas
xt_CHECKSUM16384  1
xt_MASQUERADE  20480  3
xt_conntrack   16384  1
ipt_REJECT 16384  2
nf_reject_ipv4 16384  1 ipt_REJECT
xt_tcpudp  20480  0
nft_compat 20480  7
nft_chain_nat  16384  2
nf_tables 278528  156 nft_compat,nft_chain_nat
nfnetlink  20480  2 nft_compat,nf_tables
bridge307200  0
stp16384  2 bridge,garp
llc16384  3 bridge,stp,garp
iptable_nat16384  0
rfcomm 90112  6
nf_nat 57344  3 nft_chain_nat,iptable_nat,xt_MASQUERADE
cmac   16384  3
nf_conntrack  176128  3 xt_conntrack,nf_nat,xt_MASQUERADE
algif_hash 16384  1
algif_skcipher 16384  1
nf_defrag_ipv6 24576  1 nf_conntrack
af_alg 36864  6 algif_hash,algif_skcipher
nf_defrag_ipv4 16384  1 nf_conntrack
iptable_mangle 16384  0
iptable_filter 16384  0
qrtr   45056  4
bnep   28672  2
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
coretemp   20480  0
sunrpc651264  1
binfmt_misc24576  1
kvm_intel 368640  0
btusb  65536  0
btrtl  28672  1 btusb
btbcm  24576  1 btusb
btintel45056  1 btusb
btmtk  16384  1 btusb
kvm  1060864  1 kvm_intel
bluetooth 876544  36 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
irqbypass  16384  1 kvm
ghash_clmulni_intel16384  0
iwlmvm368640  0
snd_hda_codec_conexant28672  1
jitterentropy_rng  16384  1
snd_hda_codec_generic98304  1 snd_hda_codec_conexant
ledtrig_audio  16384  1 snd_hda_codec_generic
uvcvideo  122880  0
snd_hda_codec_hdmi 73728  1
sha512_ssse3   49152  1
mac80211 1085440  1 iwlmvm
videobuf2_vmalloc  20480  1 uvcvideo
videobuf2_memops   20480  1 videobuf2_vmalloc
mei_hdcp   24576  0
snd_hda_intel  57344  4
sha512_generic 16384  1 sha512_ssse3
aesni_intel   380928  4
intel_rapl_msr 20480  0
snd_intel_dspcfg   32768  1 snd_hda_intel
videobuf2_v4l2 36864  1 uvcvideo
crypto_simd16384  1 aesni_intel
libarc416384  1 mac80211
snd_intel_sdw_acpi 20480  1 snd_intel_dspcfg
videobuf2_common   65536  4 
videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
nls_ascii  16384  1
ctr16384  0
cryptd 24576  3 crypto_simd,ghash_clmulni_intel
snd_hda_codec 176128  4 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
nls_cp437  20480  1

Bug#1014114: installation of crypt.h in the multiarch location breaks the GCC and LLVM multilib builds

[Helmut Grohne]

Hi,

On Thu, Jun 30, 2022 at 05:15:32PM +0200, Helmut Grohne wrote:
> > > For libsanitizer, crypt.h is needed to determine the size of a struct, the
> > > library itself is not needed.  Moving it to the MA location makes it
> > > unavailable for the non-multilib builds.
> 
> Again, the lack of precision is not constructive. Linking to a failure
> would help a lot here.

I now understand that the libsanitizer aspect is separate to the
multilib aspect. Therefore, my proposed solution is a non-solution and
adding multilib packages is a non-solution as well. It is way worse and
completely messed up.

A gcc build (cross compiler stage3 or native) requires a target
architecture crypt.h. Trying to do without breaks libsanitizer (no
multilib involved). Example from
https://jenkins.debian.net/job/rebootstrap_ppc64_gcc12_nobiarch/5/consoleText

| /bin/bash ../libtool  --tag=CXX   --mode=compile 
/tmp/buildd/gcc3/gcc-12-12.1.0/build/./gcc/xgcc -shared-libgcc 
-B/tmp/buildd/gcc3/gcc-12-12.1.0/build/./gcc -nostdinc++ 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/src 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/src/.libs
 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/libsupc++/.libs
 -B/usr/powerpc64-linux-gnu/bin/ -B/usr/powerpc64-linux-gnu/lib/ -isystem 
/usr/powerpc64-linux-gnu/include -isystem /usr/powerpc64-linux-gnu/sys-include 
-isystem /tmp/buildd/gcc3/gcc-12-12.1.0/build/sys-include-D_GNU_SOURCE 
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I. 
-I../../../../src/libsanitizer/sanitizer_common -I..  -I 
../../../../src/libsanitizer/include -I ../../../../src/libsanitizer -isystem 
../../../../src/libsanitizer/include/system  -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden 
-Wno-variadic-macros -I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/powerpc64-linux-gnu 
-I../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14  
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I 
../../../../src/libsanitizer/../libbacktrace -I ../libbacktrace -I 
../../../../src/libsanitizer/../include -include 
../../../../src/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 
-D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF 
.deps/sanitizer_platform_limits_posix.Tpo -c -o 
sanitizer_platform_limits_posix.lo 
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
| libtool: compile:  /tmp/buildd/gcc3/gcc-12-12.1.0/build/./gcc/xgcc 
-shared-libgcc -B/tmp/buildd/gcc3/gcc-12-12.1.0/build/./gcc -nostdinc++ 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/src 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/src/.libs
 
-L/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libstdc++-v3/libsupc++/.libs
 -B/usr/powerpc64-linux-gnu/bin/ -B/usr/powerpc64-linux-gnu/lib/ -isystem 
/usr/powerpc64-linux-gnu/include -isystem /usr/powerpc64-linux-gnu/sys-include 
-isystem /tmp/buildd/gcc3/gcc-12-12.1.0/build/sys-include -D_GNU_SOURCE 
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I. 
-I../../../../src/libsanitizer/sanitizer_common -I.. -I 
../../../../src/libsanitizer/include -I ../../../../src/libsanitizer -isystem 
../../../../src/libsanitizer/include/system -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden 
-Wno-variadic-macros -I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/powerpc64-linux-gnu 
-I../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14 
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I 
../../../../src/libsanitizer/../libbacktrace -I ../libbacktrace -I 
../../../../src/libsanitizer/../include -include 
../../../../src/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 
-D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF 
.deps/sanitizer_platform_limits_posix.Tpo -c 
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
  -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
| 
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:155:10:
 fatal error: crypt.h: No such file or directory
|   155 | #include 
|   |  ^
| compilation terminated.
| make[6]: *** [Makefile:616: sanitizer_platform_limits_posix.lo] Error 1
| make[6]: Leaving directory 
'/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libsanitizer/sanitizer_common'
| make[5]: *** [Makefile:533: all-recursive] Error 1
| make[5]: Leaving directory 
'/tmp/buildd/gcc3/gcc-12-12.1.0/build/powerpc64-linux-gnu/libsanitizer'
| make[4]: *** 

Bug#1008164: RM: obfs4proxy/0.0.8-1

[Adam D. Barratt]

Control: retitle -1 RM: obfs4proxy -- RoM; security issues
Control: tags -1 + moreinfo

On Sat, 2022-03-26 at 21:21 +0100, Paul Gevers wrote:
> Control: tag -1 bullseye
> 
> Hi Ana,
> 
> On 23-03-2022 13:13, Ana Custura wrote:
> > Opening this bug after a recomendation from debian-security.
> > Version 0.0.8 of obfs4proxy has a security bug, which has only been
> > fixed in a later
> > version (0.0.13, see bug number #1004374), and also suffers from
> > incompatibilty issues
> > with later versions of the package. Version 0.0.13 is already in
> > bullseye-backports.
> 
> So this want's removal from bullseye, setting the right tag to have
> it on the radar of the SRM.

obfs4proxy has a reverse-dependency in bullseye:

Checking reverse dependencies...
# Broken Depends:
onionshare: onionshare

Dependency problem found.

Regards,

Adam

Bug#1013700: Strangely rare pytest 7.x bug report

[Julian Gilbey]

Hi Carles,

Thanks for your thoughts!  Yes, indeed that seems to be the issue.
But what I don't understand is why the import is turned into
.pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
a longer path, and why only this package fails in this way.  Perhaps
this is the only package that has an import statement in
pytest_configure?

Best wishes,

   Julian

On Mon, Jul 04, 2022 at 04:03:39PM +0100, Carles Pina i Estany wrote:
> 
> Hi,
> 
> I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
> wanted to have a look. I don't have a solution (I might look more
> another time if time permits) but I might have something that might help
> someone who knows the tools better.
> 
> I am not familiar with Python Debian packaging details/tools neither
> with pytest :-( so take all of this with a pinch of salt.
> 
> If it helps the error comes from:
> /usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
> it does:
> """
> if name.startswith('.'):
> if not package:
> msg = ("the 'package' argument is required to perform a relative "
>"import for {!r}")
> raise TypeError(msg.format(name))
> """
> 
> When the import fails the "name" parameter of "import_modules" function
> is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
> from the hidden dirctory ".pybuild" as created by default by "pybuild".
> 
> I think that the initial "." is used only as a directory name but Python
> assumes that is a relative import requiring the package parameter.
> 
> Just to check my thoughts, and after running dpkg-buildpackage and
> failing let's try again:
> 
> $ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
> Fails with the:
> 
> TypeError: the 'package' argument is required to perform a relative import 
> for '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
> /home/carles/git/python-qtpy
> 
> Then let's try to avoid the initial "." confusion:
> 
> $ mv .pybuild pybuild
> $ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
> 
> It works.
> 
> I don't know why this is the only package affected by this though...
> 
> Hopefully it helps a bit!
> 
> On Jul/04/2022, Julian Gilbey wrote:
> > Dear all,
> > 
> > I wonder whether you might have any clue about
> > https://bugs.debian.org/1013700
> > I have mostly worked out the "cause" of the bug, but I haven't quite
> > got to the bottom of it.
> > 
> > When running the command
> > PYTHONPATH=. python3.10 -m pytest qtpy/tests
> > in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
> > message:
> > 
> > ImportError while loading conftest 
> > '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
> > TypeError: the 'package' argument is required to perform a relative import 
> > for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'
> > 
> > If the directory .pybuild is renamed to pybuild, the tests run without
> > a problem.  So there seems to be something funny about conftest.py
> > (and removing all of the other files from the qtpy/tests directory
> > except for the empty __init__.py gives the same error); here's a link
> > to it:
> > 
> > https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py
> > 
> > But there doesn't seem to be anything out of the ordinary about this.
> > So I am mystified: why does pytest 7.x seem to not give this error on
> > any other Debian package?
> > 
> > The only solution I currently have for this package is skip the tests
> > at build time and rely on autopkgtest to do them.
> > 
> > Best wishes,
> > 
> >Julian

Bug#1014080: zutty: crashes on startup

[Ricardo Mones]

Hi David,

On Wed, 29 Jun 2022 21:14:48 -0300
David Bremner  wrote:

> Package: zutty
> Version: 0.12.2.20220528.131633+dfsg1-1
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This might be specific to my configuration (amd64 GPU, free drivers),
> but zutty doesn't work at all on my machine.
> 
> ╭─ convex:~ 
> ╰─% zutty
> E [charvdev.cc:277] Error: Compiling compute shader:
> 
> terminate called after throwing an instance of 'std::system_error'
>   what():  Resource deadlock avoided
> zsh: IOT instruction  zutty

Indeed, seems something specific, had never seen a similar error. A list
of questions which I think would be useful to know before forwarding this
upstream:

 • What GPU and drivers are you using?
 • What OpenGL version? (glxinfo | grep "OpenGL version")
 • Are compute shaders supported? (glxinfo | grep ARB_compute_shader)

regards,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «What about WRITING it first and rationalizing it afterwords? :-) -- 
 Larry Wall in <8...@jpl-devvax.jpl.nasa.gov>»


pgpqez0JtotaQ.pgp
Description: Firma digital OpenPGP

Bug#1014351: hiredis: FTBFS test.c:151: send_hello: Assertion `reply != NULL && reply->type == expected' failed.

[Andreas Beckmann]

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

Hi,

hiredis/experimental recently started to FTBFS after some (transitive)
build-dependency got updated. The package in sid is not affected.

[...]
Testing against TCP connection (127.0.0.1:56379):
#48 Is able to deliver commands: ESC[0;32mPASSEDESC[0;0m
#49 Is a able to send commands verbatim: ESC[0;32mPASSEDESC[0;0m
#50 %s String interpolation works: ESC[0;32mPASSEDESC[0;0m
#51 %b String interpolation works: ESC[0;32mPASSEDESC[0;0m
#52 Binary reply length is correct: ESC[0;32mPASSEDESC[0;0m
#53 Can parse nil replies: ESC[0;32mPASSEDESC[0;0m
#54 Can parse integer replies: ESC[0;32mPASSEDESC[0;0m
#55 Can parse multi bulk replies: ESC[0;32mPASSEDESC[0;0m
#56 Can handle nested multi bulk replies: ESC[0;32mPASSEDESC[0;0m
#57 Can pass NULL to redisGetReply: ESC[0;32mPASSEDESC[0;0m
#58 RESP3 PUSH messages are handled out of band by default: 
ESC[0;32mPASSEDESC[0;0m
#59 We can set a custom RESP3 PUSH handler: ESC[0;31mFAILEDESC[0;0m
#60 With no handler, PUSH replies come in-band: ESC[0;32mPASSEDESC[0;0m
#61 With no PUSH handler, no replies are lost: ESC[0;31mFAILEDESC[hiredis-test: 
test.c:151: send_hello: Assertion `reply != NULL && reply->type == expected' 
failed.
Aborted
make[2]: *** [Makefile:224: check] Error 134
make[2]: Leaving directory '/build/hiredis-1.0.2'
make[1]: *** [debian/rules:30: override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/hiredis-1.0.2'
make: *** [debian/rules:11: binary] Error 2


Andreas


hiredis_1.0.2-1.log.gz
Description: application/gzip

Bug#1006941: checkname logic

[Marc Haber]

On Mon, Jul 04, 2022 at 08:57:54AM -0400, Matt Barry wrote:
> On Mon, 2022-07-04 at 08:54 +0200, Marc Haber wrote:
> > On Sun, Jul 03, 2022 at 09:16:49PM -0400, Matt Barry wrote:
> > > 1st check: all-numeric, always rejected
> > > 2nd check: ieee 1003.1-2001, minimal requirements [0]
> > > 3rd check: user-configurable *NAME_REGEX
> > > 4th: (possible override --allow-badname)
> > 
> > So the hardcoded
> > if ($name !~ /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/) {
> > is the IEEE 1003.1-2001 check? Does it make sense to have this
> > non-overridable?
> 
> I think there should be *some* non-overrideable minimum standard, if
> only to keep unicode usernames out.  (which I suggest just because I
> have no idea what could break.  I'm not a zealot for 1003.1-2001, but
> its as good a line as any to draw.)  

We've been having this for quite a while, didn't we? If so, we should
keep it.

>From my experience, Enterprise directory services either allow next to
nothing, because they still honor the limitation of a 1970ies mainframe
(four character user names, 7 bit ascii only, the first character being
the department letter, resulting in user names like ub1e or uncu) or
everything that AD alows including cyrillic, arabian and emojis.

But since we are exclusively worrying about local system accounts (phew,
we finally got rid of the vision to support arbitrary directory
services), 1003.1-2001 is just fine.

> > While the error message is clear, how about having this at least in a
> > variable like $ieee1003_regex?
> 
> Sure, that's easy enough.

I like that very much, many people don't read comments too exactly. And
I am guilty as charged in that regard, your honor.

> > How deeply are we testing the username checks in the suite? I'd like
> > the
> > test suite to throw some corner cases on both sides of the red line
> > at
> > adduser and see whether it does what is intended.
> 
> Fairly basic (valid_username.t).  Tests a numeric username, tests a
> dotted name with and without the configuration to pass it, tests
> NAME_REGEX and SYS_NAME_REGEX.  More edge cases could certainly be
> added here.

Thank you, that sounds good. Maybe we should add at least one entirely
absurd user name just for the laughs.

Greetings
Marc

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

Bug#1014350: ITP: nuxhash -- NiceHash cryptocurrency mining client for Linux

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ben Westover 
X-Debbugs-Cc: kwestover...@gmail.com
Severity: wishlist

* Package name: nuxhash
  Version : None (program is in beta, using git HEAD currently)
  Upstream Author : Ryan Young 
* URL : https://github.com/YoRyan/nuxhash
* License : GPL-3
  Programming Lang: Python
  Description : NiceHash cryptocurrency mining client for Linux

nuxhash is a NiceHash cryptocurrency mining client for Linux.
It consists of a headless daemon and an optional wxPython-based GUI.

I am packaging this so I can mine with NiceHash on my Debian machine.
This package will be in contrib because while the package itself is
free, it depends on NVIDIA's proprietary drivers and CUDA, which are in
non-free. It also downloads and executes a proprietary miner called
Excavator. I will maintain this package inside the Python team.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014347: update-exim4.conf.8: some source errors in format, style, and use of a macro

[Andreas Metzler]

Control: tags -1 pending

On 2022-07-04 Bjarni Ingi Gislason  wrote:
> Package: exim4-config
> Version: 4.95-6
> Severity: minor
> Tags: patch

> Dear Maintainer,

>* What led up to the situation?

> Reading the man page with "man" (uses "groff").

>* What was the outcome of this action?

> Output on the standard error stream (circumventing default "man"
> behaviour).
[...]
>   Patch:
[...]

applied in GIT, thanks.

cu Andreas

Bug#1014349: exim4-config_files.5: some source errors in format, style, and use of a macro

[Bjarni Ingi Gislason]

Package: exim4-config
Version: 4.95-6
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Reading the man page with "man" (uses "groff").

   * What was the outcome of this action?

Output on the standard error stream (circumventing default "man"
behaviour).

   * What outcome did you expect instead?

No output on standard error stream.

###

[ "test-groff" is a developmental version of "groff" ]

Input file is /usr/share/man/man5/exim4-config_files.5.gz

  Output from test-groff -b -man -dAD=l -rF0 -rHY=0 -t -w w -z :


an.tmac:exim4-config_files.5:68: style: blank line in input
an.tmac:exim4-config_files.5:74: style: blank line in input
an.tmac:exim4-config_files.5:76: style: blank line in input
an.tmac:exim4-config_files.5:81: style: blank line in input
an.tmac:exim4-config_files.5:86: style: blank line in input
an.tmac:exim4-config_files.5:98: style: blank line in input
an.tmac:exim4-config_files.5:101: style: blank line in input
an.tmac:exim4-config_files.5:103: style: blank line in input
an.tmac:exim4-config_files.5:112: style: blank line in input
an.tmac:exim4-config_files.5:116: style: blank line in input
an.tmac:exim4-config_files.5:122: style: blank line in input
an.tmac:exim4-config_files.5:133: style: blank line in input
an.tmac:exim4-config_files.5:136: style: blank line in input
an.tmac:exim4-config_files.5:138: style: blank line in input
an.tmac:exim4-config_files.5:147: style: blank line in input
an.tmac:exim4-config_files.5:151: style: blank line in input
an.tmac:exim4-config_files.5:157: style: blank line in input
an.tmac:exim4-config_files.5:163: style: blank line in input
an.tmac:exim4-config_files.5:170: style: blank line in input
an.tmac:exim4-config_files.5:179: style: blank line in input
an.tmac:exim4-config_files.5:188: style: blank line in input
an.tmac:exim4-config_files.5:191: style: blank line in input
an.tmac:exim4-config_files.5:200: style: blank line in input
an.tmac:exim4-config_files.5:204: style: blank line in input
an.tmac:exim4-config_files.5:207: style: blank line in input
an.tmac:exim4-config_files.5:211: style: blank line in input
an.tmac:exim4-config_files.5:213: style: blank line in input
an.tmac:exim4-config_files.5:216: style: blank line in input
an.tmac:exim4-config_files.5:221: style: blank line in input
an.tmac:exim4-config_files.5:225: style: blank line in input
an.tmac:exim4-config_files.5:228: style: blank line in input
an.tmac:exim4-config_files.5:232: style: blank line in input
an.tmac:exim4-config_files.5:234: style: blank line in input
an.tmac:exim4-config_files.5:237: style: blank line in input
an.tmac:exim4-config_files.5:244: style: blank line in input
an.tmac:exim4-config_files.5:251: style: blank line in input
an.tmac:exim4-config_files.5:254: style: blank line in input
an.tmac:exim4-config_files.5:260: style: blank line in input
an.tmac:exim4-config_files.5:265: style: blank line in input
an.tmac:exim4-config_files.5:269: style: blank line in input
an.tmac:exim4-config_files.5:272: style: blank line in input
an.tmac:exim4-config_files.5:296: style: blank line in input
an.tmac:exim4-config_files.5:302: style: blank line in input
an.tmac:exim4-config_files.5:308: style: blank line in input
an.tmac:exim4-config_files.5:311: style: blank line in input
an.tmac:exim4-config_files.5:315: style: blank line in input
an.tmac:exim4-config_files.5:318: style: blank line in input
troff: backtrace: file 'exim4-config_files.5':319
troff:exim4-config_files.5:319: warning: trailing space in the line
an.tmac:exim4-config_files.5:321: style: blank line in input
troff: backtrace: file 'exim4-config_files.5':322
troff:exim4-config_files.5:322: warning: trailing space in the line
troff: backtrace: file 'exim4-config_files.5':326
troff:exim4-config_files.5:326: warning: trailing space in the line
an.tmac:exim4-config_files.5:329: style: blank line in input
an.tmac:exim4-config_files.5:333: style: blank line in input
an.tmac:exim4-config_files.5:335: style: blank line in input
an.tmac:exim4-config_files.5:340: style: blank line in input
troff: backtrace: file 'exim4-config_files.5':341
troff:exim4-config_files.5:341: warning: trailing space in the line
an.tmac:exim4-config_files.5:344: style: blank line in input
troff: backtrace: file 'exim4-config_files.5':345
troff:exim4-config_files.5:345: warning: trailing space in the line
an.tmac:exim4-config_files.5:350: style: blank line in input
an.tmac:exim4-config_files.5:355: style: .BR expects at least 2 arguments, got 1
an.tmac:exim4-config_files.5:357: style: .BR expects at least 2 arguments, got 1
an.tmac:exim4-config_files.5:360: style: .BR expects at least 2 arguments, got 1
an.tmac:exim4-config_files.5:361: style: blank line in input
an.tmac:exim4-config_files.5:364: style: blank line in input


  Patch:

--- exim4-config_files.52022-07-04 15:59:32.0 +
+++ exim4-config_files.5.new2022-07-04 16:06:09.0 +
@@ -65,25 +65,30 @@ handled equally. For more 

Bug#1014345: eog: recommend heif-gdk-pixbuf

[Christoph Anton Mitterer]

Oh and btw:

There won't be much formats where not some pool, troll, etc. claims it
would held some IP one it.

If you go by that you can also drop any AV1 support, cause there's also
folks out there claiming they'd held patents for that.


Cheers,
Chris.

Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows

[Christopher Schramm]

Those popup windows are a fallback for when the required 
notification-daemon does not work. blueman is intended to be used with a 
running notification-daemon.

Bug#1012717: Have you got an ETA?

[Ferenc Wágner]

Hi Guido!

Hope you're doing fine.  Have you got any plans for the next GBP PyPI
release yet?  I understand there're only two patches committed since
0.9.27 and I don't want to hurry you, just need to plan an immediate way
forward, because this bug breaks our automated workflow.  "Don't expect
anything until after Debconf at least" would be a perfectly fine answer,
I'd just rather not make a mess for no reason.
-- 
Thanks,
Feri

Bug#1014345: eog: recommend heif-gdk-pixbuf

[Christoph Anton Mitterer]

On Mon, 2022-07-04 at 11:40 -0400, Jeremy Bicha wrote:
> There are patent concerns with libheif so I personally would rather
> not install it by default. Sorry.

Well then Suggest - doesn't get installed per default.

Cheers,
Chris.

Bug#1014345: eog: recommend heif-gdk-pixbuf

[Jeremy Bicha]

Control: tags -1 +wontfix

On Mon, Jul 4, 2022 at 11:33 AM Christoph Anton Mitterer
 wrote:
> eog cannot display these unless heif-gdk-pixbuf is installed.

There are patent concerns with libheif so I personally would rather
not install it by default. Sorry.

Thank you,
Jeremy Bicha

Bug#1014348: ITP: golang-github-go-macaroon-bakery-macaroon-bakery -- High level operations for building systems with macaroons (library)

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Owner: Mathias Gibbens 

* Package name: golang-github-go-macaroon-bakery-macaroon-bakery
  Version : 3.0.0
  Upstream Author : Canonical Inc
* URL : https://github.com/go-macaroon-bakery/macaroon-bakery
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : High level operations for building systems with macaroons 
(library)

 This library is a companion to http://github.com/go-macaroon/macaroon.
 It holds higher level operations for building systems with macaroons.

Packaging major version 3 of this library is a dependency for updating
golang-github-canonical-candid. This package will be team-maintained
within the Debian Go Packaging Team.


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

Bug#1014347: update-exim4.conf.8: some source errors in format, style, and use of a macro

[Bjarni Ingi Gislason]

Package: exim4-config
Version: 4.95-6
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Reading the man page with "man" (uses "groff").

   * What was the outcome of this action?

Output on the standard error stream (circumventing default "man"
behaviour).

   * What outcome did you expect instead?

No output on standard output.

###

[ "test-groff" is a developmental version of "groff" ]

Input file is /usr/share/man/man8/update-exim4.conf.8.gz

  Output from test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z :

an.tmac::22: style: blank line in 
input
an.tmac::25: style: blank line in 
input
an.tmac::51: style: blank line in 
input
an.tmac::75: style: blank line in 
input
an.tmac::82: style: blank line in 
input
troff: backtrace: file '':84
troff::84: warning: trailing space 
in the line
an.tmac::97: style: blank line in 
input
an.tmac::104: style: blank line in 
input
an.tmac::109: style: blank line in 
input
an.tmac::120: style: blank line in 
input
troff: backtrace: file '':122
troff::122: warning: trailing space 
in the line
an.tmac::127: style: blank line in 
input
an.tmac::131: style: blank line in 
input
an.tmac::134: style: blank line in 
input
an.tmac::139: style: blank line in 
input
an.tmac::147: style: blank line in 
input
an.tmac::159: style: blank line in 
input
an.tmac::163: style: blank line in 
input
troff: backtrace: file '':173
troff::173: warning: trailing space 
in the line
an.tmac::176: style: blank line in 
input
an.tmac::179: style: use of 
deprecated macro: .PD
an.tmac::195: style: use of 
deprecated macro: .PD
an.tmac::197: style: blank line in 
input
an.tmac::270: style: .BR expects at 
least 2 arguments, got 1
an.tmac::273: style: .BR expects at 
least 2 arguments, got 1
an.tmac::276: style: .BR expects at 
least 2 arguments, got 1
an.tmac::279: style: .BR expects at 
least 2 arguments, got 1
an.tmac::282: style: .BR expects at 
least 2 arguments, got 1
an.tmac::285: style: .BR expects at 
least 2 arguments, got 1
an.tmac::288: style: .BR expects at 
least 2 arguments, got 1
an.tmac::303: style: blank line in 
input
an.tmac::314: style: blank line in 
input
an.tmac::319: style: blank line in 
input
an.tmac::335: style: blank line in 
input
an.tmac::338: style: .BR expects at 
least 2 arguments, got 1
an.tmac::342: style: blank line in 
input


  Patch:

--- update-exim4.conf.8 2022-07-03 15:20:59.0 +
+++ update-exim4.conf.8.new 2022-07-03 15:49:29.0 +
@@ -19,10 +19,12 @@
 .\" \(lqthis text is enclosed in double quotes\(rq
 .SH NAME
 update\-exim4.conf \- Generate exim4 configuration files.
-
+.
+.LP
 .SH SYNOPSIS
 .B update\-exim4.conf [\-v|\-\-verbose] [\-h|\-\-help] [\-\-keepcomments] 
[\-\-removecomments] [\-o|\-\-output file]
-
+.
+.LP
 .SH OPTIONS
 .TP
 .I \-\-check
@@ -48,7 +50,8 @@ Remove comment lines from the output fil
 .TP
 .I \-v|\-\-verbose
 Enable verbose mode
-
+.
+.LP
 .SH DESCRIPTION
 The script
 .B update\-exim4.conf
@@ -72,16 +75,18 @@ processes the /etc/exim4/conf.d subdirec
 router, transport, retry, rewrite and auth. Within each directory it takes
 files in lexical sort order by file name. It concatenates all these files
 and makes the debconf replacement described below.
-
+.
+.LP
 If you are not using split configuration
 .B update\-exim4.conf
 concatenates
 /etc/exim4/exim4.conf.localmacros
 (if this file exists) and /etc/exim4/exim4.conf.template (in this order) and
 makes the debconf replacement described below.
-
+.
+.LP
 In either case, before outputting the result
-to /var/lib/exim4/config.autogenerated, 
+to /var/lib/exim4/config.autogenerated,
 .B update\-exim4.conf
 generates a number of exim configuration macros from the contents of
 dc_something from /etc/exim4/update\-exim4.conf.conf and inserts them
@@ -94,19 +99,22 @@ earlier definitions.
 makes no other changes to the configuration.
 This makes it very simple to make small changes to the configuration and
 still have the benefits of debconf.
-
+.
+.LP
 On the other hand if you don't want to manage exim4.conf with debconf
 install your own handcrafted version as /etc/exim4/exim4.conf.
 Exim will use this file if it exists and ignore the autogenerated one.
 Additionally you might want to set
 .I dc_eximconfig_configtype=none
 in /etc/exim4/update\-exim4.conf.conf to stop debconf from asking you 
questions about exim4.
-
+.
+.LP
 .B update\-exim4.conf
 exits silently and does nothing if /etc/exim4/exim4.conf exists and \-o
 was not used to direct the output to a different file than
 /var/lib/exim4/config.autogenerated.
-
+.
+.LP
 .B update\-exim4.conf
 will only use files in the conf.d directory that have a filename which
 consists only of letters, numbers, underscores and hyphens
@@ -117,26 +125,31 @@ Additionally,
 will use /etc/exim4/conf.d/foo/bar.rul instead of
 /etc/exim4/conf.d/foo/bar if the .rul file exists. This is meant to be
 helpful for easy interaction with packages extending Exim.
-
+.
+.LP
 If the new 

Bug#1014345: eog: recommend heif-gdk-pixbuf

[Christoph Anton Mitterer]

Package: eog
Version: 42.2-1
Severity: wishlist


Hi.

Most new smartphones procude natively HEIC images (and only
convert to JPEG, when an option is selected to do so on
sharing).

eog cannot display these unless heif-gdk-pixbuf is installed.


Perhaps it makes sense to recommend/suggest that.
Or maybe even alternatively or in addition in some higher
level GNOME metapackage?

If the latter is choosen, then heif-thumbnailer should
perhaps also be recommended (and/or in nautilus?).


Depending on what you go for, I'd then ask the cinnamon packagers
to do the same (in their metapackages and/or nemo).


Thanks,
Chris.

Bug#1014346: buster-pu: package apache2/2.4.38-3+deb10u8

[Roberto C. Sanchez]

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

[ Reason ]
In preparation for the final buster point release before the transition
to LTS, it would be beneficial for users to update the apache2 package
to address the currently open CVEs.  The CVEs are addressed by
backporting patches from upstream releases 2.4.53 and 2.4.54.

[ Impact ]
If this update is not approved then users of buster will not benefit
from fixes to the currently open CVEs.

[ Tests ]
I have executed autopkgtest for buster, stretch, and jessie.  All tests
passed on all three tested suites.

[ Risks ]
The backports were straightforward, requiring minimal adjustment/change
for the patches to apply to apache2/2.4.38-3+deb10u7 (most hunks applied
cleanly, with only a few requiring manual integration).

[ 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 ]
  * CVE-2022-22719: denial of service in mod_lua via crafted request body.
  * CVE-2022-22720: HTTP request smuggling.
  * CVE-2022-22721: integer overflow leading to buffer overflow write.
  * CVE-2022-23943: heap memory overwrite via crafted data in mod_sed.
  * CVE-2022-26377: mod_proxy_ajp: Possible request smuggling.
  * CVE-2022-28614: read beyond bounds via ap_rwrite().
  * CVE-2022-28615: Read beyond bounds in ap_strcmp_match().
  * CVE-2022-29404: Denial of service in mod_lua r:parsebody.
  * CVE-2022-30522: mod_sed denial of service.
  * CVE-2022-30556: Information Disclosure in mod_lua with websockets.
  * CVE-2022-31813: mod_proxy X-Forwarded-For dropped by hop-by-hop mechanism.

-- 
Roberto C. Sánchez
diff -Nru apache2-2.4.38/debian/changelog apache2-2.4.38/debian/changelog
--- apache2-2.4.38/debian/changelog 2021-12-21 11:50:43.0 -0500
+++ apache2-2.4.38/debian/changelog 2022-06-20 15:03:00.0 -0400
@@ -1,3 +1,20 @@
+apache2 (2.4.38-3+deb10u8) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2022-22719: denial of service in mod_lua via crafted request body.
+  * CVE-2022-22720: HTTP request smuggling.
+  * CVE-2022-22721: integer overflow leading to buffer overflow write.
+  * CVE-2022-23943: heap memory overwrite via crafted data in mod_sed.
+  * CVE-2022-26377: mod_proxy_ajp: Possible request smuggling.
+  * CVE-2022-28614: read beyond bounds via ap_rwrite().
+  * CVE-2022-28615: Read beyond bounds in ap_strcmp_match().
+  * CVE-2022-29404: Denial of service in mod_lua r:parsebody.
+  * CVE-2022-30522: mod_sed denial of service.
+  * CVE-2022-30556: Information Disclosure in mod_lua with websockets.
+  * CVE-2022-31813: mod_proxy X-Forwarded-For dropped by hop-by-hop mechanism.
+
+ -- Roberto C. Sánchez   Mon, 20 Jun 2022 15:03:00 -0400
+
 apache2 (2.4.38-3+deb10u7) buster-security; urgency=medium
 
   * Fix possible NULL dereference or SSRF in forward proxy configurations
diff -Nru apache2-2.4.38/debian/patches/CVE-2022-22719.patch 
apache2-2.4.38/debian/patches/CVE-2022-22719.patch
--- apache2-2.4.38/debian/patches/CVE-2022-22719.patch  1969-12-31 
19:00:00.0 -0500
+++ apache2-2.4.38/debian/patches/CVE-2022-22719.patch  2022-06-20 
15:03:00.0 -0400
@@ -0,0 +1,95 @@
+From 1b96582269d9ec7c82ee0fea1f67934e4b8176ad Mon Sep 17 00:00:00 2001
+From: Yann Ylavic 
+Date: Mon, 7 Mar 2022 14:51:19 +
+Subject: [PATCH] mod_lua: Error out if lua_read_body() or lua_write_body()
+ fail.
+
+Otherwise r:requestbody() or r:parsebody() failures might go unnoticed for
+the user.
+
+
+Merge r1898689 from trunk.
+Submitted by: rpluem
+Reviewed by: rpluem, covener, ylavic
+
+
+git-svn-id: 
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1898694 
13f79535-47bb-0310-9956-ffa450edef68
+---
+ modules/lua/lua_request.c | 33 -
+ 1 file changed, 20 insertions(+), 13 deletions(-)
+
+diff --git a/modules/lua/lua_request.c b/modules/lua/lua_request.c
+index 493b2bb431..1eab7b6a47 100644
+--- a/modules/lua/lua_request.c
 b/modules/lua/lua_request.c
+@@ -235,14 +235,16 @@ static int lua_read_body(request_rec *r, const char 
**rbuf, apr_off_t *size,
+ {
+ int rc = OK;
+ 
++*rbuf = NULL;
++*size = 0;
++
+ if ((rc = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR))) {
+ return (rc);
+ }
+ if (ap_should_client_block(r)) {
+ 
+ /**/
+-char argsbuffer[HUGE_STRING_LEN];
+-apr_off_trsize, len_read, rpos = 0;
++apr_off_tlen_read, rpos = 0;
+ apr_off_t length = r->remaining;
+ /**/
+ 
+@@ -250,18 +252,18 @@ static int lua_read_body(request_rec *r, const char 
**rbuf, apr_off_t *size,
+ return APR_EINCOMPLETE; /* Only room for incomplete data chunk :( 
*/
+ }
+ *rbuf = (const char 

Bug#1014344: ITP: gatk-bwamem -- interface to call Heng Li's bwa mem aligner from Java code

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: gatk-bwamem
  Version : 1.0.4
  Upstream Author : Broad Institute
* URL : https://github.com/broadinstitute/gatk-bwamem-jni/
* License : BSD-3-Clause
  Programming Lang: Java
  Description : interface to call Heng Li's bwa mem aligner from Java code

BWA (Burrows-Wheeler Aligner) is a software package for mapping low-divergent
sequences against a large reference genome, such as the human genome. It is
written in C.

gatk-bwamem provides a Java library and a shared library to allow one to use
BWA from Java code.

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

[Ben Hutchings]

On Mon, 2022-07-04 at 14:04 +0200, Ansgar wrote:
> On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > > they always zeroes).
> > [...]
> > 
> > I wrote a script to try all possible byte values for 2 bytes before or
> > after the short signature.  For this particular file, none of them
> > producd a valid signature.  So the short signatures seem to be
> > corrupted in a more complex way.
> 
> The "OCTET STRING" containing the actual signature is shorter for the
> seemingly corrupted signatures:
[...]

Yes I know, and my script uses a library to manipulate the ASN.1
structure when adding bytes.  I'm attaching the script, so you can
check the logic.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
#!/usr/bin/python3

# Fix broken detached signatures

import os.path
import sys

import asn1crypto.algos
import asn1crypto.cms
import asn1crypto.core

from M2Crypto import BIO, SMIME, X509


# Signature algorithm should be RSA
SIG_ALGO_OID = asn1crypto.core.ObjectIdentifier('1.2.840.113549.1.1.1')


# Signature length should match key length (2048 bits)
SIG_LEN = 2048 // 8


def make_smime_context(cert):
# We don't verify against a CA, just one specific certificate
smime = SMIME.SMIME()
signer_key = X509.X509_Stack()
signer_key.push(X509.load_cert(cert))
smime.set_x509_stack(signer_key)
smime.set_x509_store(X509.X509_Store())
return smime


def verify_payload(smime, sig, data):
smime.verify(
SMIME.load_pkcs7_bio_der(BIO.MemoryBuffer(sig.dump(force=True))),
BIO.MemoryBuffer(data),
flags=(SMIME.PKCS7_BINARY | SMIME.PKCS7_DETACHED
   | SMIME.PKCS7_NOVERIFY))


def brute_force_sig_2bytes(smime, sig, sig_os, data):
orig_raw_sig = bytes(sig_os)
for byte1 in range(256):
for byte2 in range(256):
sig_os.set(bytes((byte1, byte2)) + orig_raw_sig)
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'prepended {byte1}, {byte2} to start of sig')
return True

sig_os.set(bytes((byte1,)) + orig_raw_sig + bytes((byte2,)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'added {byte1}, {byte2} at start and end of sig resp.')
return True

sig_os.set(orig_raw_sig + bytes((byte1, byte2)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'appended {byte1}, {byte2} to end of sig')
return True

return False


def fix_detached_sig(smime, sig, bin_name):
# The ContentInfo should be a SEQUENCE with signed data at index 1
if len(sig) < 2 or not isinstance(sig[1], asn1crypto.cms.SignedData):
return 'no signed data found', False
sd = sig[1]

# The SignedData should be a SEQUENCE with signer infos at index 5
if len(sd) < 6 or not isinstance(sd[5], asn1crypto.cms.SignerInfos):
return 'no signer infos found', False
infos = sd[5]

# The SignerInfos should be a SET with 1 item
if len(infos) != 1:
return f'found { len(infos) } signer infos; expected 1', False
info = infos[0]

# The SignerInfo should be a SEQUENCE with the signature algorithm
# at index 4 and signature at index 5
if (len(info) < 6
or not isinstance(info[4], asn1crypto.algos.SignedDigestAlgorithm)
or len(info[4]) < 1
or not isinstance(info[5], asn1crypto.core.OctetString)):
return 'expected fields not found in signer info', False

# Check the signature algorithm and length (see bug #1012741)
if info[4][0] != SIG_ALGO_OID:
return f'unexpected signature algorithm { info[4][0].dotted }', False
actual_sig_len = len(bytes(info[5]))

with open(bin_name, 'rb') as f:
data = f.read()

if (actual_sig_len == SIG_LEN - 2
and brute_force_sig_2bytes(smime, sig, info[5], bin_name)):
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }; filled in missing 2 bytes',
True)

if actual_sig_len != SIG_LEN:
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }',
False)

verify_payload(smime, sig, data)
return None, False


def load_detached_sig(name):
with open(name, 'rb') as f:
return asn1crypto.cms.ContentInfo.load(f.read())


def save_detached_sig(sig, name):
with open(name, 'wb') as f:
f.write(sig.dump())


def main(sig_dir, bin_dir, cert):
err_count = 0

smime = make_smime_context(cert)

for dirpath, dirnames, filenames in os.walk(sig_dir):
for 

Bug#1013700: Strangely rare pytest 7.x bug report

[Carles Pina i Estany]

Hi,

I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
wanted to have a look. I don't have a solution (I might look more
another time if time permits) but I might have something that might help
someone who knows the tools better.

I am not familiar with Python Debian packaging details/tools neither
with pytest :-( so take all of this with a pinch of salt.

If it helps the error comes from:
/usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
it does:
"""
if name.startswith('.'):
if not package:
msg = ("the 'package' argument is required to perform a relative "
   "import for {!r}")
raise TypeError(msg.format(name))
"""

When the import fails the "name" parameter of "import_modules" function
is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
from the hidden dirctory ".pybuild" as created by default by "pybuild".

I think that the initial "." is used only as a directory name but Python
assumes that is a relative import requiring the package parameter.

Just to check my thoughts, and after running dpkg-buildpackage and
failing let's try again:

$ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
Fails with the:

TypeError: the 'package' argument is required to perform a relative import for 
'.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
/home/carles/git/python-qtpy

Then let's try to avoid the initial "." confusion:

$ mv .pybuild pybuild
$ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -

It works.

I don't know why this is the only package affected by this though...

Hopefully it helps a bit!

On Jul/04/2022, Julian Gilbey wrote:
> Dear all,
> 
> I wonder whether you might have any clue about
> https://bugs.debian.org/1013700
> I have mostly worked out the "cause" of the bug, but I haven't quite
> got to the bottom of it.
> 
> When running the command
> PYTHONPATH=. python3.10 -m pytest qtpy/tests
> in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
> message:
> 
> ImportError while loading conftest 
> '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
> TypeError: the 'package' argument is required to perform a relative import 
> for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'
> 
> If the directory .pybuild is renamed to pybuild, the tests run without
> a problem.  So there seems to be something funny about conftest.py
> (and removing all of the other files from the qtpy/tests directory
> except for the empty __init__.py gives the same error); here's a link
> to it:
> 
> https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py
> 
> But there doesn't seem to be anything out of the ordinary about this.
> So I am mystified: why does pytest 7.x seem to not give this error on
> any other Debian package?
> 
> The only solution I currently have for this package is skip the tests
> at build time and rely on autopkgtest to do them.
> 
> Best wishes,
> 
>Julian
-- 
Carles Pina i Estany
https://carles.pina.cat

Bug#1014343: d-i live installer: /etc/mailname contains debian-BULLSEYE-live-builder-AMD64

[Ansgar]

Package: installation-reports
Severity: normal

Boot method: CD
Image version: debian-live-11.3.0-amd64-standard.iso
Date: 2022-07-04

Machine: qemu VM

Comments/Problems:

I installed Debian using d-i from the live image. The file
/etc/mailname on the installed system says:

+---
| debian-BULLSEYE-live-builder-AMD64
+---[ file:///etc/mailname ]

Ansgar

Bug#1014341: util-linux: "lsblk -JO" prduces invalid json.

[Gernot Schilling]

Package: util-linux
Version: 2.38-4+exp2
Severity: normal
X-Debbugs-Cc: gernot.schill...@iserv.eu

Dear Maintainer,

a monitoring script that uses "lsblk -JO" fails, because the produced
json output is invalid.

a shorter output "lsblk -J -o zone-app" (just an example field, others are also 
affected)
also produces invalid json:

~~~
lsblk -J -o zone-app /dev/dm-0
{
   "blockdevices": [
  {
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  },{
 "zone-app": 0B
  }
   ]
}

~~~

Other Fields put the 0B into quotation marks

~~~
lsblk -JO|grep -Eo '["][^"]*["][:].*0B.*[,]'|sort -u
"disc-gran": "0B",
"disc-max": "0B",
"wsame": "0B",
"zone-app": 0B,
"zone-sz": 0B,
"zone-wgran": 0B,
~~~

fields 
disc-gran, disc-max and wssam do quote,
zone-ap, zone-sz and zone-wgran do not quote.

as a test "json_pp" from the package "perl" 

"lsblk -JO|json_pp" prints an error message



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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
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 util-linux depends on:
ii  libblkid1 2.38-4
ii  libc6 2.33-7
ii  libcap-ng00.8.3-1
ii  libcrypt1 1:4.4.28-1
ii  libmount1 2.38-4
ii  libpam0g  1.4.0-13
ii  libselinux1   3.4-1
ii  libsmartcols1 2.38-4
ii  libsystemd0   251.2-7
ii  libtinfo6 6.3+20220423-2
ii  libudev1  251.2-7
ii  libuuid1  2.38-4
ii  util-linux-extra  2.38-4
ii  zlib1g1:1.2.11.dfsg-4

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
ii  util-linux-locales  2.38-4

-- no debconf information

Bug#1014340: bts severity: Use of uninitialized value in lc

[Jakub Wilk]

Package: devscripts
Version: 2.22.2
Severity: minor

I got a warning about an uninitialized value when I inadvertently passed 
too few arguments to "bts severity":


  $ bts severity 99
  Use of uninitialized value in lc at /usr/bin/bts line 1846.
  bts severity: set #99's severity to what?

--
Jakub Wilk

Bug#1013300: openbsd-inetd: default services (echo, discard, chargen, {,day}time) not provided nor documented

[Thorsten Glaser]

Marco d'Itri dixit:

>On Jun 21, Thorsten Glaser  wrote:
>
>> The /etc/inetd.conf file does not contain even commented-out
>> lines for the standard services.
>I am surely not going to encourage people configuring the UDP small
>services, which are a source of reflection DoS attacks.

Oh damn, I didn’t look at who the package maintainer is… *sigh*…

>> It’d also be a good idea to document all internal services in the
>> manual pages.

>They are:
>
> inetd provides several “trivial” services internally by use of routines
> within itself.  These services are “echo”, “discard”, “chargen” (charac‐
> ter generator), “daytime” (human readable time), and “time” (machine

Huh, indeed, but…

> readable time, in the form of the number of seconds since midnight, Janu‐
> ary 1, 1900).  All of these services are TCP based.  For details of these

… this isn’t right, they also do work over UDP. (This is very useful
when testing network services.)

> services, consult the appropriate RFC from the Network Information Cen‐
> ter.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#1014314: Workaround

[Damián Cinich]

It seems that the package lvm2 renamed:

- /lib/udev/rules.d/69-lvm-metad.rules

To:

- /lib/udev/rules.d/69-lvm.rules

I needed to copy the file manually to workaround the issue:

- cp -a /lib/udev/rules.d/69-lvm.rules /lib/udev/rules.d/69-lvm-metad.rules

Bug#1014339: ITP: rust-rmp -- pure Rust MessagePack serialization

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-rmp
  Version : 0.8.10
  Upstream Author : Evgeny Safronov 
* URL : https://github.com/3Hren/msgpack-rust
* License : MIT
  Programming Lang: Rust
  Description : pure Rust MessagePack serialization

 RMP is a pure Rust MessagePack implementation
 of an efficient binary serialization format,
 providing low-level core functionality,
 writers and readers for primitive values
 with direct mapping between binary MessagePack format.
 See packages librust-rmp-serde-dev and librust-rmpv-dev
 for high-level interfaces on top of this one.
 .
 MessagePack is a computer data interchange format,
 aiming to be compact and simple.

This package also covers Rust crates rmp-serde and rmpv.
It is needed by safe-network (bug#1008016);
it will be maintained in the Debian section at Salsa, here:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLC73sACgkQLHwxRsGg
ASHRqw//c6zGIVHZ6RRF+iDznLc/0InaYml3BWOfias1ogQHjIM4R2klKGEtToqv
yE4C3sO/KLmWMpszp/eghng6aDvbacsuOXRIP3C7lDDliJ2p0jbH3XNP5IWZhFar
lVsQEtlsnIDwHb5w9lpLeshY6jVIhd3LLP3px57uLboIlljv9dC1wdsoKW6T09i4
6C8HE9Rcz15wPF1Va9p+FzX35G/UK6GOn8agmw+4jrM+vq9B8Uz0g7u895j4LUbF
dnl5Xss6SU03Opv5CasX08kU/k8Zt4Z6jmGAZibGXFN8i9Sxd4f+c5Ls3Qx/VdIx
tmzGzzCzgFUE6NqY5Da74TY9mWgOTp1F/1k2Uf+EL7vGrqsh5lbGxiX3gqUlIMpW
G0Al3ZUs6npevWvd39vJfTGzS/EogjNQ2lJoLqLd07KII8sKVP545aW2K4fcPYUi
thauxZG4dJB7+tTkvum7kX1ZTAdzaXARQgSp4WIbecIF44F/QCiAPoAwdgTYmIQd
mOBYhddIAtMQjFFQyxU/MvXB5ihSu1NFe4a7afKQoOPvOkJemFIN4XuvLSwZ9Da9
AjCoL+gV8GnX5tvnAY9hdjpEciqMoTlP7p8kkBt9WjLAXusFVZFbnE4/RclDaNnY
TJEg5w6Jj+eHwWX4eomBAZAbrscE7pp1/wrbQUL60Lg+/rc4azw=
=Y5ej
-END PGP SIGNATURE-

Bug#1014338: openlibm: ftbfs on riscv64('No rule to make target 'riscv64/Make.files')

[Bo YU]

Source: openlibm
Version: 0.7.0+dfsg-2
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear openlibm Maintainer,

The openlibm has a ftbfs issue on riscv64 arch:
```
No rule to make target 'riscv64/Make.files'
```

The buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=openlibm=riscv64=0.7.0%2Bdfsg-2=1593571040=0

There are two solutions to this issues:

One: Upgrade openlibm to 0.81[0]. The PR has enable openlibm to 
support riscv64;

Two: The patches attached are to fix the issue and I can build the 
package on my real riscv64 hardware(Unmatched board) with it if 
it is not convenient to upgrade here for openlibm.

Please let me know if here need me to do more tests.

Bo

[0]: 
https://github.com/JuliaMath/openlibm/commit/428e7af2148894e287801a0539b7a1756f451e88
-- 
Best Regards,

# SymbolsHelper-Confirmed: 0.7.0 amd64 arm64 armel armhf i386 mips64el mipsel 
powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64
libopenlibm.so.3 libopenlibm3 #MINVER#
* Build-Depends-Package: libopenlibm-dev
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_aT@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_atanhi@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_atanlo@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS0@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS1@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS2@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS3@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS4@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS5@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pS6@Base 0.4
 (arch=arm64)_ItL_pS7@Base 0.6.0
 (arch=arm64)_ItL_pS8@Base 0.6.0
 (arch=arm64)_ItL_pS9@Base 0.6.0
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_pi_lo@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_qS1@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_qS2@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_qS3@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_qS4@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)_ItL_qS5@Base 0.4
 (arch=arm64)_ItL_qS6@Base 0.6.0
 (arch=arm64)_ItL_qS7@Base 0.6.0
 (arch=arm64)_ItL_qS8@Base 0.6.0
 (arch=arm64)_ItL_qS9@Base 0.6.0
 __exp__D@Base 0.4
 __fe_dfl_env@Base 0.4
#MISSING: 0.5.0# (arch=!armhf)__fedisableexcept@Base 0.4
#MISSING: 0.5.0# (arch=!armhf)__feenableexcept@Base 0.4
 __fpclassifyd@Base 0.4
 __fpclassifyf@Base 0.4
 (arch=!armhf)__fpclassifyl@Base 0.4
 (arch=i386 kfreebsd-i386 hurd-i386)__has_sse@Base 0.4
 __ieee754_rem_pio2@Base 0.4
 __ieee754_rem_pio2f@Base 0.4
 __isfinite@Base 0.4
 __isfinitef@Base 0.4
 (arch=!armhf)__isfinitel@Base 0.4
 __isinff@Base 0.4
 (arch=!armhf)__isinfl@Base 0.4
 __isnanf@Base 0.4
 (arch=!armhf)__isnanl@Base 0.4
 __isnormal@Base 0.4
 __isnormalf@Base 0.4
 (arch=!armhf)__isnormall@Base 0.4
 __kernel_cos@Base 0.4
 __kernel_cosdf@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)__kernel_cosl@Base 0.4
 __kernel_rem_pio2@Base 0.4
 __kernel_sin@Base 0.4
#MISSING: 0.5.0# __kernel_sincos@Base 0.4
#MISSING: 0.5.0# __kernel_sincosdf@Base 0.4
 __kernel_sindf@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)__kernel_sinl@Base 0.4
 __kernel_tan@Base 0.4
 __kernel_tandf@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)__kernel_tanl@Base 0.4
 __ldexp_cexp@Base 0.4
 __ldexp_cexpf@Base 0.4
 __ldexp_exp@Base 0.4
 __ldexp_expf@Base 0.4
 __log__D@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)__p1evll@Base 0.5.0
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)__polevll@Base 0.5.0
 __scan_nan@Base 0.5.0
 __signbit@Base 0.4
 __signbitf@Base 0.4
 (arch=!armhf)__signbitl@Base 0.4
 (arch=i386 kfreebsd-i386 hurd-i386)__test_sse@Base 0.4
#MISSING: 0.5.0# _scan_nan@Base 0.4
 acos@Base 0.4
 acosf@Base 0.4
 acosh@Base 0.4
 acoshf@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)acoshl@Base 0.5.0
 (arch=!mips64el !powerpc !ppc64 !ppc64el !riscv64 !s390x)acosl@Base 0.4
 asin@Base 0.4
 asinf@Base 0.4
 asinh@Base 0.4
 asinhf@Base 0.4
 (arch=!armhf !mips !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x)asinhl@Base 0.5.0
 

Bug#1014337: gocr: provide static and shared libraries for -lPgm2asc

[Andrius Merkys]

Source: gocr
Version: 0.52-3
Tags: patch
Control: block 682760 by -1

Hello,

I am building osra (#682760) with gocr-dev. During configuration stage,
osra attempts to link with either static or shared library -lPgm2asc and
fails. To build these libraries the following has to be added to
debian/rules:

override_dh_auto_build:
dh_auto_build -- all libs

Shared library should be provided by libpgm2asc0 binary package.

Andrius

Bug#1014314: lvm2: Missing 69-lvm-metad.rules causes lvm2 initramfs-tools hook to fail

[Anatoly Pugachev]

Package: lvm2
Version: 2.03.15-1
Followup-For: Bug #1014314

Dear Maintainer,

I have to remove offending lines from
/usr/share/initramfs-tools/hooks/lvm2 file, so my "update-initramfs -u"
to start working again.

I don't have /etc/udev/rules.d/56-lvm.rules nor 69-lvm-metad.rules
installed on my system.

Can someone please look?!

Thanks.



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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.183-1
ii  dmsetup   2:1.02.183-1
ii  init-system-helpers   1.63
ii  libaio1   0.3.113-2
ii  libblkid1 2.38-4
ii  libc6 2.33-7
ii  libdevmapper-event1.02.1  2:1.02.183-1
ii  libdevmapper1.02.12:1.02.183-1
ii  libedit2  3.1-20210910-1
ii  libselinux1   3.4-1
ii  libsystemd0   251.2-7
ii  libudev1  251.2-7
ii  lsb-base  11.2

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/hooks/lvm2 (from lvm2 package)

Bug#1000510: systemd: all server programs fail when they are set to specified interfaces

[Michael Biebl]

On Fri, 26 Nov 2021 00:57:09 -0500 westlake  
wrote:

there is new criteria I can add to this original bugreport:

here I did additional tests and noticed new light of observations that 
your override does not take effect for ifupdown(networking.service), 
even though it should by the information you have provided.


the summary I can make of things so far regarding this is,

1) the override (from your suggestion of After=, Wants=)   only works 
only when the user opts to adopt "systemd-networkd"

and


I'm pretty sure it works with NetworkManager as well (which provides 
NetworkManager-wait-online.service, which hooks into network-online.target).


2) the override does nothing when the user stays with the default 
networking.service (it is supposed to but it doesn't)


^ According to you the systemd override should work whether the user 
uses networking.service or systemd-networkd -- but this isn't happening.




Well, obviously networking.service (as provided by ifupdown) needs to 
hook into network-online.target for this target to be useful.


Please read the documentation at https://systemd.io/NETWORK_ONLINE/

In case of ifupdown, you probably want to enable 
ifudpown-wait-online.service or use type auto.
That said, I don't use ifupdown anymore, so can't really help you with 
its configuration.



Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013700: Strangely rare pytest 7.x bug report

[Julian Gilbey]

Dear all,

I wonder whether you might have any clue about
https://bugs.debian.org/1013700
I have mostly worked out the "cause" of the bug, but I haven't quite
got to the bottom of it.

When running the command
PYTHONPATH=. python3.10 -m pytest qtpy/tests
in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
message:

ImportError while loading conftest 
'/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
TypeError: the 'package' argument is required to perform a relative import for 
'.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'

If the directory .pybuild is renamed to pybuild, the tests run without
a problem.  So there seems to be something funny about conftest.py
(and removing all of the other files from the qtpy/tests directory
except for the empty __init__.py gives the same error); here's a link
to it:

https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py

But there doesn't seem to be anything out of the ordinary about this.
So I am mystified: why does pytest 7.x seem to not give this error on
any other Debian package?

The only solution I currently have for this package is skip the tests
at build time and rely on autopkgtest to do them.

Best wishes,

   Julian

Bug#1014335: lnav: FTBFS: 1 test fails due to quoting differences

[Andreas Beckmann]

Source: lnav
Version: 0.10.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Control: found -1 0.9.0-2

Hi,

lnav in sid and experimental recently started to FTBFS, since some
(transitive) build-depends seems to have changed the quoting style in
the stuff it generates. Is the new one even correct?
(Looks to me like the change from an array to a string.)

FAIL: test_sql_json_func.sh
===

test: ./drive_sql SELECT id, json_group_object(key, value) as stack FROM ( 
SELECT 1 as id, 1 as key, 10 as value UNION ALL SELECT 1 as id, 2 as key, 
json_array(1, 2, 3) as value UNION ALL SELECT 1 as id, 3 as key, 30.5 as value)
json_group_object with number keys does not work
--- -   2022-07-04 06:29:15.368031500 +
+++ test_sql_json_func.sh_32.tmp2022-07-04 06:29:15.346400398 +
@@ -1,3 +1,3 @@
 Row 0:
   Column id: 1
-  Column  stack: {"1":10,"2":[1,2,3],"3":30.5}
+  Column  stack: {"1":10,"2":"[1,2,3]","3":30.5}
FAIL test_sql_json_func.sh (exit status: 1)


Testsuite summary for lnav 0.10.1

# TOTAL: 36
# PASS:  35
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See test/test-suite.log


Andreas


lnav_0.10.1-2.log.gz
Description: application/gzip

Bug#1006941: checkname logic

[Matt Barry]

On Mon, 2022-07-04 at 08:54 +0200, Marc Haber wrote:
> Hi Matt,
> 
> thanks for checking this.
> 
> On Sun, Jul 03, 2022 at 09:16:49PM -0400, Matt Barry wrote:
> > 1st check: all-numeric, always rejected
> > 2nd check: ieee 1003.1-2001, minimal requirements [0]
> > 3rd check: user-configurable *NAME_REGEX
> > 4th: (possible override --allow-badname)
> 
> So the hardcoded
> if ($name !~ /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/) {
> is the IEEE 1003.1-2001 check? Does it make sense to have this
> non-overridable?

I think there should be *some* non-overrideable minimum standard, if
only to keep unicode usernames out.  (which I suggest just because I
have no idea what could break.  I'm not a zealot for 1003.1-2001, but
its as good a line as any to draw.)  

> 
> While the error message is clear, how about having this at least in a
> variable like $ieee1003_regex?

Sure, that's easy enough.

> 
> 
> > The docs desribe --force-badname as "weak checks applied"; this
> > could
> > be clarified, but I don't think its urgent.
> 
> We have this in #774046, I planned to do some work o this myself.
> 
> > As I write this, the most confusing part is that there are three
> > separate checks for all-numeric names; I have a patch to simplify
> > this.
> 
> Thank you.
> 
> How deeply are we testing the username checks in the suite? I'd like
> the
> test suite to throw some corner cases on both sides of the red line
> at
> adduser and see whether it does what is intended.

Fairly basic (valid_username.t).  Tests a numeric username, tests a
dotted name with and without the configuration to pass it, tests
NAME_REGEX and SYS_NAME_REGEX.  More edge cases could certainly be
added here.

Cheers,
Matt


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

Bug#1014334: debhelper: mixing execute_after_dh_foo and execute_after_dh_foo-{arch,indep}

[Andreas Beckmann]

Package: debhelper
Version: 13.7.1
Severity: normal

Hi,

I just accidentally split an execute_after_dh_auto_clean into
execute_after_dh_auto_clean-indep and execute_after_dh_auto_clean
(w/o -arch !) and it didn't work as planned since dh would only runs
execute_after_dh_auto_clean ... (seen on compat 13).
I assume it works the same way for execute_before_* and override_*
(haven't tried that).

Is that intentional? I didn't find any documentation about it.

Thinking about it again, I might actually want dh to run *all* of them,
e.g.

* execute_after_dh_auto_clean cleans up something that has been done for
both -arch and -indep builds, e.g. by execute_before_dh_auto_configure
* execute_after_dh_auto_clean-indep cleans up something created by the
-indep build, using some B-D-I for both building and cleaning.

If it's intentional that some of the override/hooks targets are ignored,
there should be at least a warning about such "weird targets in d/rules".

Andreas

Bug#1004769: digikam: FTBFS with ffmpeg 5.0

[Steven Robbins]

control: severity -1 normal

On Fri, 25 Feb 2022 22:55:12 +0100 Sebastian Ramacher  
wrote:
> On 2022-02-21 16:05:37 -0600, Steven Robbins wrote:
> > On Tue, 1 Feb 2022 21:01:39 +0100 Sebastian Ramacher 
 
> > wrote:
> > > Source: digikam
> > > Version: 4:7.1.0-2
> > 
> > I have just uploaded Digikam 7.5.0 to unstable.  If you have a chance to 
re-
> > try the build, would appreciate knowing if it now builds with new ffmpeg.
> 
> 7.5.0 fails to build with the same error.

I have temporarily disabled video player in Digikam 7.7.0-1 upload, so 
lowering this bug severity.

-Steve


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

Bug#1013082: wine: CombineZP doesn't display a picture

[Günter Frenz]

Hi,

the bug still exists in wine version 7.0~repack-3 in the same way.

Regards

Günter

-- 
---
Günter Frenz
Börschgasse 16a, D-51143 Köln
(h) gu...@guefz.de, gu...@freenet.de
(w) g.frenz@gso.schule.koeln
---




pgp6R6SaNFO6C.pgp
Description: Digitale Signatur von OpenPGP

Bug#995692: please increase severity

[debbug2]

Dear packager!

This is biting me more and more often. It's real annoying that I have to 
compile from source with such extensive dependencies because of this one 
missing configure setting. For me, severity of this bug is becoming major.

Bug#1012846: Acknowledgement (karbon: Please update for Poppler 22.06)

[Nathan Teodosio]

I now attach the full debdiff since a new dependency in d/control is required.diff -Nru calligra-3.2.1+dfsg/debian/changelog 
calligra-3.2.1+dfsg/debian/changelog
--- calligra-3.2.1+dfsg/debian/changelog2022-06-21 18:48:42.0 
-0300
+++ calligra-3.2.1+dfsg/debian/changelog2022-06-30 10:03:11.0 
-0300
@@ -1,3 +1,9 @@
+calligra (1:3.2.1+dfsg-5ubuntu1) kinetic; urgency=medium
+
+  * debian/patches/upstream_Fix-compile-with-poppler-22-06.patch
+
+ -- Nathan Pratta Teodosio   Thu, 30 Jun 2022 
10:03:11 -0300
+
 calligra (1:3.2.1+dfsg-5build2) kinetic; urgency=medium
 
   * No-change rebuild against libpoppler122
diff -Nru calligra-3.2.1+dfsg/debian/control calligra-3.2.1+dfsg/debian/control
--- calligra-3.2.1+dfsg/debian/control  2022-06-21 18:48:42.0 -0300
+++ calligra-3.2.1+dfsg/debian/control  2022-06-30 10:03:11.0 -0300
@@ -60,6 +60,7 @@
libphonon4qt5-dev,
libphonon4qt5experimental-dev,
libpoppler-private-dev,
+   libpoppler-qt5-dev,
libqca-qt5-2-dev,
libqt5opengl5-dev (>= 5.3.0),
libqt5svg5-dev (>= 5.3.0),
diff -Nru calligra-3.2.1+dfsg/debian/patches/series 
calligra-3.2.1+dfsg/debian/patches/series
--- calligra-3.2.1+dfsg/debian/patches/series   2022-03-20 06:27:11.0 
-0300
+++ calligra-3.2.1+dfsg/debian/patches/series   2022-06-30 10:03:11.0 
-0300
@@ -4,3 +4,4 @@
 upstream_Update-Cmake-and-deps-Fix-Freetype-and-FontConfig-Li.patch
 upstream_Remove-old-std-c-11-setting-for-Vc.patch
 upstream_Fix-compile-with-newer-versions-of-poppler.patch
+upstream_Fix-compile-with-poppler-22-06.patch
diff -Nru 
calligra-3.2.1+dfsg/debian/patches/upstream_Fix-compile-with-poppler-22-06.patch
 
calligra-3.2.1+dfsg/debian/patches/upstream_Fix-compile-with-poppler-22-06.patch
--- 
calligra-3.2.1+dfsg/debian/patches/upstream_Fix-compile-with-poppler-22-06.patch
1969-12-31 21:00:00.0 -0300
+++ 
calligra-3.2.1+dfsg/debian/patches/upstream_Fix-compile-with-poppler-22-06.patch
2022-06-30 10:03:11.0 -0300
@@ -0,0 +1,147 @@
+From 236bacbe13739414e919de868283b0caf2df5d8a Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid 
+Date: Wed, 13 Apr 2022 01:25:44 +0200
+Subject: [PATCH] PdfImport: Fix compile with newer poppler
+
+Brings a dependency on poppler-qt5 to be able to include the version
+header, honestly it's not strictly needed, one could do a
+check_cxx_source_compiles, but I don't care about Calligra enough to
+spend more time making it compile while it's using poppler the wrong
+way.
+
+From 6b75bec784c9835c78993349845d8c2ef22ec3de Mon Sep 17 00:00:00 2001
+From: Dag Andersen 
+Date: Wed, 13 Apr 2022 14:45:33 +0200
+Subject: [PATCH] PdfImport: Fix compile with newer poppler
+
+Also fixes odg2pdf filter.
+
+Same solution as commit 236bacbe13739414e919de868283b0caf2df5d8a
+by ac...@kde.org.
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 7d098c46a9e..de54f71ed20 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -959,6 +959,7 @@ calligra_drop_product_on_bad_condition( FILTER_WPG_TO_ODG
+ calligra_drop_product_on_bad_condition( FILTER_PDF_TO_SVG
+ NOT_WIN "not supported on Windows"
+ PopplerXPDFHeaders_FOUND "poppler xpdf headers not found"
++Poppler_FOUND "poppler qt5 headers not found"
+ )
+ 
+ calligra_drop_product_on_bad_condition( FILTER_HTML_TO_ODS
+diff --git a/filters/karbon/pdf/CMakeLists.txt 
b/filters/karbon/pdf/CMakeLists.txt
+index 94d4071da3d..849baa70f12 100644
+--- a/filters/karbon/pdf/CMakeLists.txt
 b/filters/karbon/pdf/CMakeLists.txt
+@@ -19,7 +19,7 @@ set(pdf2svg_PART_SRCS PdfImportDebug.cpp PdfImport.cpp 
SvgOutputDev.cpp )
+ add_library(calligra_filter_pdf2svg MODULE ${pdf2svg_PART_SRCS})
+ calligra_filter_desktop_to_json(calligra_filter_pdf2svg 
calligra_filter_pdf2svg.desktop)
+ 
+-target_link_libraries(calligra_filter_pdf2svg komain Poppler::Core)
++target_link_libraries(calligra_filter_pdf2svg komain Poppler::Core 
Poppler::Qt5)
+ 
+ install(TARGETS calligra_filter_pdf2svg DESTINATION 
${PLUGIN_INSTALL_DIR}/calligra/formatfilters)
+ 
+@@ -29,6 +29,6 @@ set(pdf2odg_PART_SRCS PdfImportDebug.cpp Pdf2OdgImport.cpp 
SvgOutputDev.cpp)
+ add_library(calligra_filter_pdf2odg MODULE ${pdf2odg_PART_SRCS})
+ calligra_filter_desktop_to_json(calligra_filter_pdf2odg 
calligra_filter_pdf2odg.desktop)
+ 
+-target_link_libraries(calligra_filter_pdf2odg kopageapp karbonui 
Poppler::Core)
++target_link_libraries(calligra_filter_pdf2odg kopageapp karbonui 
Poppler::Core Poppler::Qt5)
+ 
+ install(TARGETS calligra_filter_pdf2odg DESTINATION 
${PLUGIN_INSTALL_DIR}/calligra/formatfilters)
+diff --git a/filters/karbon/pdf/Pdf2OdgImport.cpp 
b/filters/karbon/pdf/Pdf2OdgImport.cpp
+index f8a24c000b7..d23cc7ae1df 100644
+--- a/filters/karbon/pdf/Pdf2OdgImport.cpp
 b/filters/karbon/pdf/Pdf2OdgImport.cpp
+@@ -27,6 +27,8 @@
+ 
+ #include 
+ 
++#include 
++
+ // Don't show this warning: it's an issue in 

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

[Ansgar]

On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > they always zeroes).
> [...]
> 
> I wrote a script to try all possible byte values for 2 bytes before or
> after the short signature.  For this particular file, none of them
> producd a valid signature.  So the short signatures seem to be
> corrupted in a more complex way.

The "OCTET STRING" containing the actual signature is shorter for the
seemingly corrupted signatures:

+---
| $dumpasn1 
./linux-image-4.19.0-21-amd64-unsigned/lib/modules/4.19.0-21-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 404: SEQUENCE {
| [...]
| 151 254:   OCTET STRING
+---

vs

+---
| $ dumpasn1 
./linux-image-4.19.0-21-cloud-amd64-unsigned/lib/modules/4.19.0-21-cloud-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 407: SEQUENCE {
| [...]
| 151 256:   OCTET STRING
+---

Given the number of corrupted signatures is pretty much the number of
signatures where the two leading bytes should be 0 (as stated in [1]),
I suspect something (incorrectly?) outputs a shorter OCTET STRING
leaving out the 0 (as one might for a large integer type), but the
other side expects a fixed size?

If so, the file should validate if one injects two leading 0 bytes in
the OCTET STRING (and updates all length values). I would need to check
how to manipulate files using ASN.1's DER encoding to try this...

Ansgar

  [1]: https://bugs.debian.org/1012741#48

Bug#1014333: uscan: please add indirect signature check with signed hashes

[Timo Röhling]

Package: devscripts
Version: 2.22.2
Severity: wishlist
Control: block 802304 by -1

Dear maintainers,

CMake provides its source tarballs with an indirect signature
scheme [1]: instead of signing the .zip and .tar.gz archives
individually, they collect the SHA256 hashes of all files in
a dedicated .txt file and then sign that.

It would be nice if uscan could verify this signature scheme
automatically, but I must admit I have no good proposal how to
extend the watch file format.


Cheers
Timo


[1] https://cmake.org/download/

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1014323: wine-binfmt: postinst fails due to incorrect import directory

[Miguel A. Vallejo]

Package: wine-binfmt
Version: 7.0~repack-3
Severity: important

There are also problems with the version 7.0~repack-3 today in Sid:

Setting up wine-binfmt (7.0~repack-3) ...
update-binfmts: warning: unable to open /usr/share/binfmts/wine: No
such file or directory
update-binfmts: warning: couldn't find information about 'wine' to import
update-binfmts: exiting due to previous errors
dpkg: error processing package wine-binfmt (--configure):
installed wine-binfmt package post-installation script subprocess
returned error exit status 2
Errors were encountered while processing:
wine-binfmt
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1014331: wordwarvi: wrong manpage description about option --bw

[Nobuhiro Ban]

Package: wordwarvi
Version: 1.0.4-2
Severity: minor
Tags: patch

Dear Maintainer,

The manpage says:
>Options:
>   --bw   Render the game in black and white, as if on graph paper.

but this graph paper effect was removed.


The graph paper effect was introduced at [1].
And reverted the code later at [2], but the manpage was not reverted then.

[1] 
https://github.com/smcameron/wordwarvi/commit/7f0c6c661a14a416c1c6fabc70bd6a43c35eb49a
[2] 
https://github.com/smcameron/wordwarvi/commit/880a21f699b58c8aad10651cbd2a4461f8927a3e


This patch reverts wordwarvi.6 change in [1]:

--- wordwarvi-1.0.4.orig/wordwarvi.6
+++ wordwarvi-1.0.4/wordwarvi.6
@@ -26,7 +26,7 @@ in the cluster to do it all over again.
 .SH Options:
 .TP
 \fB\--bw\fR
-Render the game in black and white, as if on graph paper.
+No color, just black and white.
 .TP
 \fB\--blueprint\fR
 Render the game to look like a blueprint.



Regards,
Nobuhiro Ban

Bug#1014330: highway: NEON and VFPv4 are not part of the armhf baseline

[Adrian Bunk]

Source: highway
Version: 0.17.0-6
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Mathieu Malaterre 

NEON and VFPv4 are not part of the armhf baseline:
https://wiki.debian.org/ArchitectureSpecificsMemo#armhf

Plenty of hardware (inluding some of our buildds)
do not support NEON.

Plenty of hardware (inluding some of our buildds)
do not support VFPv4.

Bug#1014329: anbox: Not working after removing ashmem module

[Shengjing Zhu]

Package: anbox
Version: 0.0~git20211020-3
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/anbox/anbox/issues/2042
X-Debbugs-Cc: z...@debian.org

ashmem_linux module has been removed from kernel 5.18.

https://github.com/torvalds/linux/commit/721412ed3d819e767cac2b06646bf03aa158aaec
https://salsa.debian.org/kernel-team/linux/-/commit/7d080ca22b66848115547ebc7da839d18db956f4

Bug#1014115: uninstall does not properly remove enablement symlinks

[Luca Boccassi]

On Mon, 4 Jul 2022 at 11:55, Michael Biebl  wrote:
>
>
> Am 04.07.22 um 12:36 schrieb Luca Boccassi:
> > I have uploaded i-s-h, should we close this one now?
>
> I've seen the upload. Thanks!
>
> I was debating with myself whether systemd-homed should get a tightened,
> versioned Depends on i-s-h to prevent this issue from happening.
>
> This would make a backport a bit harder, but maybe a stable upload of
> i-s-h with this fix is a good idea anyway?
>
> Regards,
> Michael

It's a new package and optional, so maybe it's not worth it - but up
to you, if you want to add that and a backport to be safer, I don't
have any objection.

Kind regards,
Luca Boccassi

Bug#1012999: To be fixed in 8.1-1

[NG]

Thanks for the report.
The compilation problem will hopefully fixed in the upcoming 8.1-1
version of the pacakge.
BR
/Gábor

Bug#1014328: RFP: soju -- user-friendly IRC bouncer

[David Bremner]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: soju
  Version : 0.4.0
  Upstream Author : Simon Ser https://emersion.fr
* URL : https://git.sr.ht/~emersion/soju
* License : AGPLv3
  Programming Lang: Go
  Description : user-friendly IRC bouncer

The author says:

soju is a user-friendly IRC bouncer. soju connects to upstream IRC
servers on behalf of the user to provide extra functionality. soju
supports many features such as multiple users, numerous IRCv3
extensions, chat history playback and detached channels. It is
well-suited for both small and large deployments.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmLCx1IACgkQA0U5G1Wq
FSFGhBAAiAS3dFtSSKzvYv9kUxh5ePVOrElPqWmxaC3VHJWhEtWj923NhEYs3eY/
91BTcryl8jiRK9h+zRkeZNvhNF8TtgTqKMJav7Tx9uKhjp1WIGr16VF6IUl/M7Ix
LZVza7Ylr15sfsJne1H/Fii82Zh4mmjlIYbENTCOcRQ7Sk2We0qD2okUzhBex8T9
yoMHbVP/kxCBhW5su/aXCO+XRKORVIKtG1+W6HG6DfFtQ3B1lfFU17QKQzOoPH6S
VEDb9E+Fv/oAezcXCadE0nDj/afBQjdZVs0JClVfCozbVdPsPBahcG8/XDiAPRpW
QcOzD4GrQANV59zJI2X8dxGv27UOt9EPQotlgKSp/EFWxfh8DZF5j9eIKZK0NX97
ZTmlypMbbvhuOJcb+xcxjaxAjsyZKm5RZAoYgf+QxZpd0rvYW39HVA7apb2ygt6i
2/lXa3r6rYBh1Nhk5YhmcnJI7m+Lz9xIVQvoLYvQ3c77lMH8QX/VCwTaqdU+rTT9
oc59SWAesMt69n8pX2+walm60oW7WHXuBPcmjwNzyo9z3MKqP68TA0iWLVXIqbhN
DEXOq2Gz9t5bzenA3/zZyHeeBbUX1GCBf/Bh43RVSiwn+Pr8r7BtoNKk54rxjG9j
LqHHLQegUv0LzQVGLpxABtNRXFLmmXO9Kr48BMxQITB0yHSofjI=
=B5So
-END PGP SIGNATURE-

Bug#1014115: uninstall does not properly remove enablement symlinks

[Michael Biebl]

Am 04.07.22 um 12:36 schrieb Luca Boccassi:

I have uploaded i-s-h, should we close this one now?


I've seen the upload. Thanks!

I was debating with myself whether systemd-homed should get a tightened, 
versioned Depends on i-s-h to prevent this issue from happening.


This would make a backport a bit harder, but maybe a stable upload of 
i-s-h with this fix is a good idea anyway?


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#913079: ITP: strawberry -- an audio player and music collection organizer fully based on Qt5

[Peter B]

Updating the ITP as all recent comments went to the RFS
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010663


Strawberry is packaged here
https://salsa.debian.org/debian/strawberry

and is currently in the NEW queue
https://ftp-master.debian.org/new/strawberry_1.0.5-1.html


Cheers,
Peter

Bug#1014115: uninstall does not properly remove enablement symlinks

[Luca Boccassi]

On Sat, 2 Jul 2022 at 20:40, Michael Biebl  wrote:
>
> Am 02.07.22 um 18:30 schrieb Luca Boccassi:
> > On Fri, 1 Jul 2022 at 20:20, Michael Biebl  wrote:
> >>
> >>
> >> Am 30.06.22 um 22:31 schrieb Luca Boccassi:
> >>> The problem is some files leftover, no? Just delete them in the
> >>> postinst or postrm?
> >>
> >> My main motivation is to "stop the bleeding" as quickly as possible.
> >>
> >> If we continue to create those broken state files, we'd have to keep
> >> those postinst/postrm cleanup routines for a possibly long time.
> >
> > I'd rather just fix i-s-h, here's a MR, it fixes the issue for me, can
> > you give it a go as well please? I'll do an upload once it's confirmed
> > and reviewed
> >
> > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/21
>
> Thank you, bluca.
> Without having tested it and without knowing Perl very well, the MR
> looks ok to me.
> I think Felipe is a bit more familiar with Perl, so if he could give his
> ack, that would be good I think.
>
> Cheers,
> Michael

I have uploaded i-s-h, should we close this one now?

Kind regards,
Luca Boccassi

Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects

[Moessbauer, Felix]

Hi Stephan,

Thanks for the review. I changed the name of the package, renamed the project 
on salsa and cut the release.
This one should be ready to be uploaded.

PS: Looks like the repology site currently has some TLS issues.

Happy Coding!
Felix

From: Stephan Lachnit 
Sent: Sunday, July 3, 2022 11:35 AM
To: Moessbauer, Felix (T CED SES-DE) 
Cc: 1012...@bugs.debian.org
Subject: Re: ITP: shtab -- generator for shell tab completion files for python 
projects

Hi Felix,

The package is looking good so far, I only request one change, namely renaming 
the source package from shtab to python-shtab. The reason for this prefix is 
that else 
repology.org
 won't be able to map the package automatically.

Cheers,
Stephan

On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit 
mailto:stephanlach...@debian.org>> wrote:
Hi Felix,

I will take a look at the package sometime next week. I'm currently packing my 
stuff to move to Geneva, so I don't really have that much time right now. Feel 
free to ping though in case I forget :)

Cheers,
Stephan

On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix 
mailto:felix.moessba...@siemens.com>> wrote:

Dear maintainers,

the initial packaging of shtab is implemented in [1] and should be ready for a 
review.

@stephan It would be great if you could sponsor this package.
We talked about that at Debian Reunion Hamburg.

[1] 
https://salsa.debian.org/python-team/packages/shtab

Best regards,
Felix Moessbauer
Siemens AG

Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java

[Moessbauer, Felix]

Hi Stephan,

Thanks for the review. I changed the name of the package, renamed the project 
on salsa and cut the release.
This one should be ready to be uploaded.

Happy Coding!
Felix

From: Stephan Lachnit 
Sent: Sunday, July 3, 2022 11:43 AM
To: Moessbauer, Felix (T CED SES-DE) 
Cc: 1013...@bugs.debian.org
Subject: Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating 
engine compatible with Velocity for Java

Hi Felix,

Looking good as well. Please also rename the source to python-airspeed and do a 
dch -r, then I'll upload.

Cheers,
Stephan

On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit 
mailto:stephanlach...@debian.org>> wrote:
Hi Felix,

If there is nobody else, I can sponsor this as well. Will try to find some time 
on Sunday to review your work :)

Cheers,
Stephan

On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix 
mailto:felix.moessba...@siemens.com>> wrote:
Dear maintainers,

the initial packaging for python3-airspeed is now ready at [1] and has a green 
salsa CI.
It should be ready for a review.

@Stephan: Would you like to sponsor this package as well?

[1] 
https://salsa.debian.org/python-team/packages/airspeed

Best regards,
Felix Moessbauer
Siemens AG

Bug#1014273: ITP: pastaignore -- makes gitignores easier

[Philip Hands]

Hi,

It's not clear to me what this does that makes it more useful than other
more-general-purpose commands that we already have packaged, such as
find or (for simpler usage) fdfind (from the fd-find package).

For instance, the example in your readme of:

  pastaignore ".*\.o" not "\.\/demo\/important.*\.o"

can (unless I'm missing something) be done with fdfind thus:

  fdfind -E '^demo/important*' ".o$"

BTW does pastaignore take the current .gitignore into account, or does
it just put out all filenames including the already ignored ones?  I
only ask becuase fdfind does use .gitignores (optionally) so will only
list files that are not already ignored, which seems like a useful
feature in such a program.

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

Bug#1014156: lintian: very-long-line-length-in-source-file for non-text source files

[Peter B]

I'm also seeing this with strawberry. Several hits from binary sound
files in it's test suite.

Thanks for that list as well. One item though caught my eye:


P: strawberry source: very-long-line-length-in-source-file 3435 > 512 
[dist/macos/strawberry.icns:5678]

The suffix "icns" is already in the blacklist since 2.115.2. With
which version of Lintian did you generate that list?



Hi Axel,

I use Testing, so it was 2.115.1  It is indeed fixed in 2.115.2


Trying on duma, I got several hits on binary files (with 2.115.1 & 2.115.2)

P: duma source: very-long-line-length-in-source-file 1628 > 512 
[win32-msvc.net/detoursexample1/detoursexample1.suo:2]
P: duma source: very-long-line-length-in-source-file 2810 > 512 
[win32-msvc.2005/example2/example2.suo:7]
P: duma source: very-long-line-length-in-source-file 2938 > 512 
[win32-msvc.2005/example1/example1.suo:8]
P: duma source: very-long-line-length-in-source-file 5025 > 512 
[docs-data/Data/SymbolTable.nd:6]
P: duma source: very-long-line-length-in-source-file 6371 > 512 
[win32-msvc.2005/dumadll/dumadll.aps:5]
P: duma source: very-long-line-length-in-source-file 6371 > 512 
[win32-msvc.net/dumadll/dumadll.aps:5]
P: duma source: very-long-line-length-in-source-file 814 > 512 
[kduma/docs-data/Data/SymbolTable.nd:18]


Cheers,
Peter

Bug#1014327: bullseye-pu: package cargo-mozilla/0.57.0-7~deb11u1

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

This brings cargo 0.57 into bullseye as src:cargo-mozilla, following the
packaging changes done in previous releases (e.g. cargo-mozilla 0.47.0 in
buster). This is needed for the upcoming Firefox 102 ESR.

I'm attaching a diff from cargo 0.57. Since this is a separate source and
binary, it won't affect the rust ecosystem, unless you intentionally install
this in place of bin:cargo.

Cheers,
Emilio
diff -ruNp cargo-0.57.0/debian/cargo.bash-completion 
cargo-mozilla-0.57.0/debian/cargo.bash-completion
--- cargo-0.57.0/debian/cargo.bash-completion   2022-03-15 13:09:01.0 
+0100
+++ cargo-mozilla-0.57.0/debian/cargo.bash-completion   1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-src/etc/cargo.bashcomp.sh cargo
diff -ruNp cargo-0.57.0/debian/cargo.dirs cargo-mozilla-0.57.0/debian/cargo.dirs
--- cargo-0.57.0/debian/cargo.dirs  2022-03-15 13:09:01.0 +0100
+++ cargo-mozilla-0.57.0/debian/cargo.dirs  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-usr/bin
diff -ruNp cargo-0.57.0/debian/cargo-doc.docs 
cargo-mozilla-0.57.0/debian/cargo-doc.docs
--- cargo-0.57.0/debian/cargo-doc.docs  2022-03-15 13:09:01.0 +0100
+++ cargo-mozilla-0.57.0/debian/cargo-doc.docs  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-target/doc
diff -ruNp cargo-0.57.0/debian/cargo.manpages 
cargo-mozilla-0.57.0/debian/cargo.manpages
--- cargo-0.57.0/debian/cargo.manpages  2022-03-15 13:09:01.0 +0100
+++ cargo-mozilla-0.57.0/debian/cargo.manpages  1970-01-01 01:00:00.0 
+0100
@@ -1,2 +0,0 @@
-src/etc/man/cargo-*.1
-src/etc/man/cargo.1
diff -ruNp cargo-0.57.0/debian/cargo-mozilla.bash-completion 
cargo-mozilla-0.57.0/debian/cargo-mozilla.bash-completion
--- cargo-0.57.0/debian/cargo-mozilla.bash-completion   1970-01-01 
01:00:00.0 +0100
+++ cargo-mozilla-0.57.0/debian/cargo-mozilla.bash-completion   2022-03-15 
13:09:01.0 +0100
@@ -0,0 +1 @@
+src/etc/cargo.bashcomp.sh cargo
diff -ruNp cargo-0.57.0/debian/cargo-mozilla.dirs 
cargo-mozilla-0.57.0/debian/cargo-mozilla.dirs
--- cargo-0.57.0/debian/cargo-mozilla.dirs  1970-01-01 01:00:00.0 
+0100
+++ cargo-mozilla-0.57.0/debian/cargo-mozilla.dirs  2022-03-15 
13:09:01.0 +0100
@@ -0,0 +1 @@
+usr/bin
diff -ruNp cargo-0.57.0/debian/cargo-mozilla-doc.docs 
cargo-mozilla-0.57.0/debian/cargo-mozilla-doc.docs
--- cargo-0.57.0/debian/cargo-mozilla-doc.docs  1970-01-01 01:00:00.0 
+0100
+++ cargo-mozilla-0.57.0/debian/cargo-mozilla-doc.docs  2022-03-15 
13:09:01.0 +0100
@@ -0,0 +1 @@
+target/doc
diff -ruNp cargo-0.57.0/debian/cargo-mozilla.manpages 
cargo-mozilla-0.57.0/debian/cargo-mozilla.manpages
--- cargo-0.57.0/debian/cargo-mozilla.manpages  1970-01-01 01:00:00.0 
+0100
+++ cargo-mozilla-0.57.0/debian/cargo-mozilla.manpages  2022-03-15 
13:09:01.0 +0100
@@ -0,0 +1,2 @@
+src/etc/man/cargo-*.1
+src/etc/man/cargo.1
diff -ruNp cargo-0.57.0/debian/changelog cargo-mozilla-0.57.0/debian/changelog
--- cargo-0.57.0/debian/changelog   2022-05-02 22:57:46.0 +0200
+++ cargo-mozilla-0.57.0/debian/changelog   2022-07-03 21:40:34.725134208 
+0200
@@ -1,3 +1,15 @@
+cargo-mozilla (0.57.0-7~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to bullseye as cargo-mozilla.
+  * Build-dep on rustc-mozilla.
+  * Don't build the doc package.
+  * Vendor libgit2 1.3.0, the system one is too old.
+  * Build-dep on libpcre3-dev, for libgit2.
+  * Disable build::close_output_during_drain test as it hangs in bullseye.
+
+ -- Emilio Pozuelo Monfort   Fri, 01 Jul 2022 12:25:10 +0200
+
 cargo (0.57.0-7) unstable; urgency=medium
 
   * Team upload.
diff -ruNp cargo-0.57.0/debian/control cargo-mozilla-0.57.0/debian/control
--- cargo-0.57.0/debian/control 2022-05-02 22:57:07.0 +0200
+++ cargo-mozilla-0.57.0/debian/control 2022-07-02 20:43:20.894722653 +0200
@@ -1,4 +1,4 @@
-Source: cargo
+Source: cargo-mozilla
 Section: devel
 Maintainer: Rust Maintainers 
 Uploaders: Luca Bruno ,
@@ -11,16 +11,17 @@ Build-Depends:
  debhelper (>= 12~),
  dpkg-dev (>= 1.17.14),
  cargo:native(>= 0.17.0),
- rustc:native(>= 1.16),
- libstd-rust-dev (>= 1.16),
+ rustc-mozilla:native(>= 1.16),
+ libstd-rust-mozilla-dev (>= 1.16),
  pkg-config,
  bash-completion,
  python3:native,
  libcurl4-gnutls-dev | libcurl4-openssl-dev,
  libssh2-1-dev,
- libgit2-dev (>= 1.3.0),
- libgit2-dev (<< 1.4~~),
+# libgit2-dev (>= 1.3.0),
+# libgit2-dev (<< 1.4~~),
  libhttp-parser-dev,
+ libpcre3-dev,
  libssl-dev,
  zlib1g-dev,
  git 
@@ -29,7 +30,7 @@ Standards-Version: 4.2.1
 Vcs-Git: https://salsa.debian.org/rust-team/cargo.git
 Vcs-Browser: https://salsa.debian.org/rust-team/cargo
 
-Package: cargo
+Package: cargo-mozilla
 Architecture: any
 Multi-Arch: allowed
 Depends: ${shlibs:Depends}, 

Bug#943989: command-not-found: Same problem

[Maxime Frieh]

Package: command-not-found
Version: 20.10.1-1
Followup-For: Bug #943989

Dear Maintainer,

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

command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.123-meson64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  11.1.0
ii  python3  3.9.2-3
ii  python3-apt  2.2.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information

Bug#1014326: bullseye-pu: package rust-cbindgen/0.23.0-1~deb11u1

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This is an update for rust-cbindgen, needed to build Firefox/Thunderbird.
We need 0.23 to build FF/TB 102. This update vendors the dependencies (as
we have done in the past with other versions, e.g. on buster/stretch).
I'm attaching a diff of the debian dir excluding the vendor dir.

Thanks,
Emilio
diff -ruNp rust-cbindgen-0.20.0/debian/changelog 
rust-cbindgen-0.23.0/debian/changelog
--- rust-cbindgen-0.20.0/debian/changelog   2021-12-02 12:49:31.0 
+0100
+++ rust-cbindgen-0.23.0/debian/changelog   2022-07-04 10:59:17.608005927 
+0200
@@ -1,3 +1,20 @@
+rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to bullseye.
+  * Vendor dependencies, they are not available in bullseye.
+  * Only build the cbindgen binary.
+  * Lower dh-cargo build-dep.
+  * Build with rust-mozilla.
+
+ -- Emilio Pozuelo Monfort   Mon, 04 Jul 2022 10:53:21 +0200
+
+rust-cbindgen (0.23.0-1) unstable; urgency=medium
+
+  * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
+
+ -- Sylvestre Ledru   Fri, 03 Jun 2022 11:20:37 +0200
+
 rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -ruNp rust-cbindgen-0.20.0/debian/control 
rust-cbindgen-0.23.0/debian/control
--- rust-cbindgen-0.20.0/debian/control 2021-08-22 14:26:42.0 +0200
+++ rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.349338635 +0200
@@ -2,27 +2,27 @@ Source: rust-cbindgen
 Section: utils
 Priority: optional
 Build-Depends: debhelper (>= 12),
- dh-cargo (>= 24),
+ dh-cargo (>= 17),
  cargo:native,
- rustc:native,
- libstd-rust-dev,
- librust-clap-2+default-dev,
- librust-heck-0.3+default-dev,
- librust-indexmap-1+default-dev,
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev,
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.3-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.3-~~),
- librust-syn-1+full-dev (>= 1.0.3-~~),
- librust-syn-1+parsing-dev (>= 1.0.3-~~),
- librust-syn-1+printing-dev (>= 1.0.3-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev,
+ rustc-mozilla:native,
+ libstd-rust-mozilla-dev,
+# librust-clap-3+default-dev (>= 3.1-~~),
+# librust-heck-0.4+default-dev,
+# librust-indexmap-1+default-dev,
+# librust-log-0.4+default-dev,
+# librust-proc-macro2-1+default-dev,
+# librust-quote-1+default-dev,
+# librust-serde-1+derive-dev (>= 1.0.103-~~),
+# librust-serde-json-1+default-dev,
+# librust-syn-1+clone-impls-dev (>= 1.0.88-~~),
+# librust-syn-1+extra-traits-dev (>= 1.0.88-~~),
+# librust-syn-1+full-dev (>= 1.0.88-~~),
+# librust-syn-1+parsing-dev (>= 1.0.88-~~),
+# librust-syn-1+printing-dev (>= 1.0.88-~~),
+# librust-tempfile-3+default-dev,
+# librust-toml-0.5+default-dev,
  help2man,
- librust-serial-test-dev,
+# librust-serial-test-dev,
  cython3
 Maintainer: Debian Rust Maintainers 

 Uploaders:
@@ -32,55 +32,55 @@ Vcs-Git: https://salsa.debian.org/rust-t
 Vcs-Browser: 
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/cbindgen
 Rules-Requires-Root: no
 
-Package: librust-cbindgen-dev
-Architecture: any
-Multi-Arch: same
-Depends:
- ${misc:Depends},
- librust-heck-0.3+default-dev,
- librust-indexmap-1+default-dev,
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev,
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.3-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.3-~~),
- librust-syn-1+full-dev (>= 1.0.3-~~),
- librust-syn-1+parsing-dev (>= 1.0.3-~~),
- librust-syn-1+printing-dev (>= 1.0.3-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev
-Recommends:
- librust-cbindgen+clap-dev (= ${binary:Version})
-Provides:
- librust-cbindgen-0-dev (= ${binary:Version}),
- librust-cbindgen-0.20-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0-dev (= ${binary:Version})
-Description: Generating C bindings to Rust code - Rust source code
- This package contains the source for the Rust cbindgen crate, packaged by
- debcargo for use with cargo and dh-cargo.
-
-Package: librust-cbindgen+clap-dev
-Architecture: any
-Multi-Arch: same
-Depends:
- ${misc:Depends},
- librust-cbindgen-dev (= ${binary:Version}),
- librust-clap-2+default-dev
-Provides:
- librust-cbindgen+default-dev (= ${binary:Version}),
- librust-cbindgen-0+clap-dev (= ${binary:Version}),
- librust-cbindgen-0+default-dev (= ${binary:Version}),
- librust-cbindgen-0.20+clap-dev (= ${binary:Version}),
- librust-cbindgen-0.20+default-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0+clap-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0+default-dev (= ${binary:Version})
-Description: Generating C bindings to Rust 

Bug#1014325: ITP: megapixels-postprocessd -- Image processing utility meant as companion for megapixels application

[Evangelos Ribeiro Tzaras]

Package: wnpp
Severity: wishlist
Owner: Evangelos Ribeiro Tzaras 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: megapixels-postprocessd
  Version : 0.2.1
  Upstream Author : Martijn Braam 
* URL : https://git.sr.ht/~martijnbraam/postprocessd
* License : GPL-3+
  Programming Lang: C
  Description : Image processing utility meant as companion for Megapixels 
application

Companion project to Megapixels providing a native postprocessing pipeline,
It aims to improve the quality of pictures taken with Megapixels.

It can be used as a drop-in replacement for the postprocess.sh,
that gets shipped as part of the megapixels package.

As this package is closely related to Megapixels
It should also be maintained in the DebianOnMobile team.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

Upstream report updated.

https://github.com/OpenPrinting/cups-filters/issues/472#issuecomment-1173388702

I have added the following comments:

'It is notable that no such issues exist on Debian 10.0 (Buster) with the 
latest cups-oldstable,now available - driverless queues are created and 
everything prints as expected - and no trace of avahi, whereas cups[-browsed?] 
seems to depend on it in 11.3, where avahi cannot be purged without removing 
very much else too.

It is also notable that when adding the driverless MFC-L2740DW printer in 
cups-web on Buster, there is no "Fax, driverless" option. The fax details seem 
to be included in driverless PPDs on Bullseye whether a "model" including "Fax" 
is chosen or not.'

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

[Sven Joachim]

Control: tags -1 + patch

On 2022-07-04 10:00 +0200, Vincent Lefevre wrote:

> On 2022-07-04 15:01:13 +1000, Konomi Kitten wrote:
>> When update-initramfs runs I receive the following message:
>>
>> depmod: WARNING: could not open modules.builtin.modinfo at
>> /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or
>> directory
>
> I also got such a warning on two of my machines. It seems to
> be triggered when upgrading kmod (which provides depmod) to
> 30+20220630-1.

Same here.  The following patch takes care of the problem.

Cheers,
Sven

From e41183925d51bd97cd0b85660b6abdaad0fd5b69 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 4 Jul 2022 08:35:46 +0200
Subject: [PATCH] Copy modules.builtin.modinfo into initramfs

As of kmod version 30, depmod issues a warning if this file is
missing.

Closes: #1014319
---
 mkinitramfs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mkinitramfs b/mkinitramfs
index a4d16f6..df1b940 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -316,10 +316,10 @@ for d in conf/conf.d etc run scripts ${MODULESDIR}; do
 	mkdir -p "${DESTDIR}/${d}"
 done

-# Copy in modules.builtin and modules.order (not generated by depmod)
+# Copy in modules.builtin, modules.builtin.modinfo and modules.order (not generated by depmod)
 # and modules.builtin.bin (generated by depmod, but too late to avoid
 # error messages as in #948257)
-for x in modules.builtin modules.builtin.bin modules.order; do
+for x in modules.builtin modules.builtin.bin modules.builtin.modinfo modules.order; do
 	if [ -f "${MODULESDIR}/${x}" ]; then
 		cp -p "${MODULESDIR}/${x}" "${DESTDIR}${MODULESDIR}/${x}"
 	fi
--
2.36.1

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

[Vincent Lefevre]

On 2022-07-04 10:00:04 +0200, Vincent Lefevre wrote:
> On 2022-07-04 15:01:13 +1000, Konomi Kitten wrote:
> > When update-initramfs runs I receive the following message:
> > 
> > depmod: WARNING: could not open modules.builtin.modinfo at
> > /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or
> > directory
> 
> I also got such a warning on two of my machines. It seems to
> be triggered when upgrading kmod (which provides depmod) to
> 30+20220630-1.

And downgrading to kmod 29-1+b1 makes this warning disappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1014323: wine-binfmt: postinst fails due to incorrect import directory

[Giacomo Mulas]

Package: wine-binfmt
Version: 7.0~repack-2
Severity: important
Tags: patch

Dear Maintainer,

the latest version of wine-binfmt in sid fails to configure, 
because its postinst just calls

update-binfmts --import wine

which by default assumes that the importdir is /usr/share/binfmts/, 
while the current package installs the binfmt definition as
/usr/lib/binfmt.d/wine

The postinst script works flawlessly if the correct importdir is
explicitly specified, i.e.

update-binfmts --importdir /usr/lib/binfmt.d --import wine 

I also added the optional "--package wine-binfmt" option, which while
not required does not hurt either.

Best regards
Giacomo Mulas


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 wine-binfmt depends on:
ii  binfmt-support  2.2.2-1
ii  systemd 251.2-7
ii  wine [wine] 7.0~repack-2

wine-binfmt recommends no packages.

wine-binfmt suggests no packages.

Versions of packages wine depends on:
ii  wine32  7.0~repack-2
ii  wine64  7.0~repack-2

Versions of packages wine suggests:
pn  dosbox   
ii  exe-thumbnailer  1~icoextract-0.1.2-2
ii  kio-extras   4:21.12.3-1
ii  playonlinux  4.3.4-3
ii  q4wine   1.3.12-1
pn  winbind  
ii  winetricks   20220411-1

Versions of packages libwine depends on:
ii  libasound2   1.2.6.1-2+b1
ii  libc62.33-7
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libglib2.0-0 2.72.3-1
ii  libgphoto2-6 2.5.29-1
ii  libgphoto2-port122.5.29-1
ii  libgstreamer-plugins-base1.0-0   1.20.3-dmo1
ii  libgstreamer1.0-01.20.3-1
ii  libldap-2.5-02.5.12+dfsg-2
ii  libopenal1   1:1.19.1-2
ii  libpcap0.8   1.10.1-4
ii  libpulse015.0+dfsg1-4+b1
ii  libudev1 251.2-7
ii  libunwind8   1.3.2-2
ii  libusb-1.0-0 2:1.0.26-1
ii  libvkd3d11.2-12
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libz-mingw-w64   1.2.12+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.14-3

Versions of packages libwine recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 7.0~repack-2
ii  gstreamer1.0-plugins-good  1.20.3-dmo1
ii  libasound2-plugins 1:1.2.6-dmo2
ii  libcups2   2.4.2-1
ii  libdbus-1-31.14.0-1
ii  libgl1 1.4.0-1
ii  libgl1-mesa-dri22.0.5-1
ii  libgnutls303.7.6-2
ii  libgssapi-krb5-2   1.19.2-2+b2
ii  libkrb5-3  1.19.2-2+b2
ii  libodbc2   2.3.11-2
ii  libosmesa6 22.0.5-1
ii  libsdl2-2.0-0  2.0.22+dfsg-6
ii  libv4l-0   1.22.1-4
ii  libvkd3d-shader1   1.2-12
ii  libvulkan1 1.3.216.0-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxfixes3 1:6.0.0-1
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine suggests:
ii  cups-bsd   2.4.2-1
ii  gstreamer1.0-libav 1:1.20.3-dmo2
ii  gstreamer1.0-plugins-bad   1:1.20.3-dmo2
ii  gstreamer1.0-plugins-ugly  1:1.20.3-dmo1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32 depends on:
ii  libc62.33-7
ii  libwine  7.0~repack-2

Versions of packages wine32 recommends:
ii  wine [wine]  7.0~repack-2

Versions of packages wine32 suggests:
ii  wine32-preloader  7.0~repack-2

Versions of packages wine64 depends on:
ii  libc62.33-7
ii  libwine  7.0~repack-2

Versions of packages wine64 recommends:
ii  wine [wine]  7.0~repack-2
ii  wine32   7.0~repack-2

Versions of packages wine64 suggests:
ii  wine64-preloader  7.0~repack-2

Versions of packages wine64-tools depends on:
ii  gcc4:11.2.0-2
ii  libc6  2.33-7
ii  libgettextpo0  0.21-6
ii  libwine-dev7.0~repack-2
ii  perl   5.34.0-4

Versions of packages wine64-tools recommends:
ii  g++  4:11.2.0-2
ii  wine [wine]  7.0~repack-2

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

[Vincent Lefevre]

On 2022-07-04 15:01:13 +1000, Konomi Kitten wrote:
> When update-initramfs runs I receive the following message:
> 
> depmod: WARNING: could not open modules.builtin.modinfo at
> /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or
> directory

I also got such a warning on two of my machines. It seems to
be triggered when upgrading kmod (which provides depmod) to
30+20220630-1.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#920900: I am Ms Vivian Rabia . Did you receive my previous message? Is your email still active? Because I have a serious business offer for you. Hope to hear from you as soon as possible.

[Vivian Rabia]

Bug#975378: O: opensysusers

[Thomas Goirand]

On 7/3/22 22:27, Andrea Pappacoda wrote:

Hi Thomas, I'd be happy to maintain this package :)


Please go ahead.


On Sat, 21 Nov 2020 11:50:14 +0100 Thomas Goirand  wrote:
 > I don't want to deal with the hostility attached with packaging this 
anymore.

 > Anyone with more energy is welcome to take over.

What hostility are you referring to? I mean, this is related to systemd, 
but still...


I've had to get involved in debates which I didn't want to hear about, 
like, if opensysusers had value, and how should opensysusers should use 
dpkg-divert to get itself installed (which is the most stupid way ever 
to get it to replace systemd's version), and from my perspective, 
un-cooperative systemd maintainers. I don't care enough to waste my 
time, suffer too much exposition, and deal with politics on this.


I'll wait for your reply before moving forward; I've attempted adopting 
a package before (glm) but I haven't been successful as I'm not yet a 
DM/DD.


Please take over ASAP. Good luck!

Cheers,

Thomas Goirand (zigo)