Bug#1004951: Not displaying attachments that contain a slash (/) in their name

[Erik Thiele]

Package: thunderbird
Version: 1:91.5.0-2~deb10u1

Thunderbird is not displaying attachments that contain a slash (/) in
their name. There is also no error message.


Steps to reproduce:

- Open thunderbird to send yourself an email with an attachment, for
  example a PDF file. it is called "doc.pdf" in this example here.

- Click on the received email. Click on the attachment and see that it
  correctly opens.

- Now right click on the received mail in the mail list and do "save
  as". save the email with filename "working.eml"

- quit thunderbird.

- in a shell go in the directory where working.eml is saved and do:
  thunderbird working.eml
  You will see thunderbird starting, opening the mail. click on the
  attachment and see it opens.
  quit thundebird again.

- copy working.eml to not_working.eml
  open a text editor on not_working.eml

now search for this:

Content-Type: application/pdf; name="doc.pdf"
Content-Disposition: attachment; filename="doc.pdf"
Content-Transfer-Encoding: base64

add slashes at the same position in both filenames like this:

Content-Type: application/pdf; name="do/c.pdf"
Content-Disposition: attachment; filename="do/c.pdf"
Content-Transfer-Encoding: base64

save the file.

- now do
  thunderbird not_working.eml
  the email opens, you see the attachment named "do/c.pdf"
  you can click the attachment, but nothing opens.
  no error message, just nothing happens.
  but you can right click the attachment and save it.
  notice that thunderbird wants to save with "do-c.pdf", so it replaced
  the slash (/) by a minus (-).
  you can check that the saved file correctly matches the original file.

As you see something is wrong when receiving attachments that contain a
slash (/) in their name.

When you investigate thunderbird with strace like this:

strace - thunderbird working.eml 2>strace_working.txt
then click on the attachment and quit thunderbird

then do

strace - thunderbird not_working.eml 2>strace_not_working.txt
then click on the attachment and quit thunderbird

then do:
grep pdf strace_working.txt |grep open
you will see:
[pid 17250] openat(AT_FDCWD, "/tmp/doc.pdf", O_WRONLY|O_CREAT...

compare this to:
grep pdf strace_not_working.txt |grep open
you will see no try of even saving the attachment.




The way I created the not-working email with a text editor may seem
the source of the problem, but it isn't. I regularly get emails with
slashes in attachment names. I simply did not find a way to create such
an email with commandline tools. All seem to dislike slashes in
attachment names. But since I am regularly receiving this kind of
emails in real life, there must be some (non-unix?) mail program
creating such (bad) attachments.




cu
Erik

Bug#1002113: gr-gsm: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'

[Adrian Bunk]

On Sat, Jan 29, 2022 at 02:33:25PM +0100, Petter Reinholdtsen wrote:
> [Lucas Nussbaum]
> > Relevant part (hopefully):
> > > /usr/bin/ld: CMakeFiles/cmTC_af046.dir/src.c.o: in function `main':
> > > ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference 
> > > to `pthread_create'
> > > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:12: 
> > > undefined reference to `pthread_detach'
> > > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:13: 
> > > undefined reference to `pthread_cancel'
> > > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:14: 
> > > undefined reference to `pthread_join'
> > > collect2: error: ld returned 1 exit status
> 
> Look like something, somewhere, is missing -lpthread to find the
> required functions.  Anyone got a patch to fix it?

Blindly dumping the end of the build log is often not helpful.

The actual problem is:

...
CMake Error at swig/CMakeLists.txt:37 (include):
  include could not find requested file:

GrSwig


CMake Error at swig/CMakeLists.txt:51 (GR_SWIG_MAKE):
  Unknown CMake command "GR_SWIG_MAKE".


-- Configuring incomplete, errors occurred!
...


AFAIK this is due to a change in gnuradio 3.9.


> Happy hacking
> Petter Reinholdtsen

cu
Adrian

Bug#1004471: Pending patch for terser-webpack-plugin in webpack 5 till a new upstream for node-terser is uploaded

[Caleb Adepitan]

Hi,

I just arrived at a working patch for terser-webpack-plugin to circumvent 
breaking changes in node-terser 5 which is required by the package. The 
available version of node-terser in debian is 4 which is behind the terser 
package upstream.

This patch is an ad-hoc fix for the bug pending the node-terser package is 
updated to a compatible version.

Here is the proposed patch:

https://salsa.debian.org/calebpitan/node-webpack/-/commit/208febe14d117dc134543fd9773c8eca02d1d68c.patch

--- a/terser-webpack-plugin/src/utils.js
+++ b/terser-webpack-plugin/src/utils.js
@@ -264,8 +264,11 @@ async function terserMinify(
 
   // Let terser generate a SourceMap

   if (sourceMap) {
-// @ts-ignore
-terserOptions.sourceMap = { asObject: true };
+const pkg = require("terser/package.json")
+if (parseInt(pkg.version) > 4) {
+  // @ts-ignore
+  terserOptions.sourceMap = { asObject: true };
+}
   }
 
   /** @type {ExtractedComments} */

@@ -284,7 +287,11 @@ async function terserMinify(
   }
 
   const [[filename, code]] = Object.entries(input);

-  const result = await minify({ [filename]: code }, terserOptions);
+  let result = minify({ [filename]: code }, terserOptions);
+
+  if (result instanceof Promise) {
+result = await result
+  }
 
   return {

 code: /** @type {string} **/ (result.code),


OpenPGP_0x8A1B2CC96775D2D7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Anton Khirnov]

Hi,
Quoting Santiago Garcia Mantinan (2022-02-03 23:09:43)
> On Xan 20 2022, Anton Khirnov wrote:
> > Attaching a patch. I still couldn't think of a reason this code should
> > ever disable IPv6 on the physical interface, so it's removed
> > unconditionally. If anyone can think of such a reason, then I guess an
> > option could be added?
> 
> Well, the thing here is that since de beginning of the bridge code it was
> recommended not to add ip addresses to the bridge ports, this was a long
> time ago, and maybe it has changed, if so, I'd like to know when.
> 
> But anyway... why would you want to have
> an IP v4 or v6 on the bridge ports? why not having it on the bridge itself?

This is NOT about addresses on bridge ports (and I agree those are not
needed or desirable), but the case where the bridge port is a VLAN
interface. Then the current code prevents you from using not just the
VLAN interface (e.g. eth0.3), but also the underlying physical interface
(i.e. eth0). I see no reason why you should not use both of these
simultaneously.

The patch I sent does not change anything about disabling ipv6 on the
bridge port interface, only for the underlying physical interface for a
VLAN bridge port.

-- 
Anton Khirnov

Bug#1004947: Loses keystrokes until dialog displayed

[Jamie Zawinski]

https://www.jwz.org/xscreensaver/faq.html#typeahead

This is an inevitable consequence of the new security model introduced in 
XScreenSaver 6.00. The old behavior will not be returning, so get used to 
clicking the mouse or tapping "Shift" before you start typing your password.

Just typing blindly had always been bad opsec anyway: if the screen was only 
blanked but not locked, you probably would have accidentally typed part of your 
password into another window.

Bug#1004946: Cannot hold down backspace to delete password

[Jamie Zawinski]

For some reason, the XInput2 extension doesn't auto-repeat certain keys that 
used to auto-repeat when read the "old" way. Unfortunately there's nothing I 
can do about this. I process only the keystrokes that I receive.

However you can use the traditional keystrokes ^U and ^X to  clear the whole 
line.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#1004948: tmpreaper : should not send a warning from cron when RUNFROMCRON is false

[Erwan David]

Package: tmpreaper
Version: 1.6.16
Severity: minor


Setting RUNFROMCRON to false, (and keeping SHOWWARNING at true) I was surprised 
to get a warning sent by the cron job.
It would be cleaner that no cron warning is sent if tmpreaper is not run from 
cron.



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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 tmpreaper depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.33-5
ii  libmount1  2.37.3-1+b1

tmpreaper recommends no packages.

tmpreaper suggests no packages.

-- Configuration Files:
/etc/tmpreaper.conf changed:
SHOWWARNING=false
RUNFROMCRON=false
TMPREAPER_PROTECT_EXTRA=''
TMPREAPER_DIRS='/tmp/.'
TMPREAPER_DELAY='256'
TMPREAPER_ADDITIONALOPTIONS=''


-- debconf information:
* tmpreaper/readsecurity:
* tmpreaper/readsecurity_upgrading:
* tmpreaper/confignowexists:
* tmpreaper/TMPREAPER_TIME:

Bug#990522: libtpms: CVE-2021-3623

[Seunghun Han]

Hello Moritz and Bastian,
Thank you for your information. I have updated libtpms to the latest
version and uploaded it.

Best regards,

Seunghun

On Tue, Feb 1, 2022 at 8:33 AM Bastian Germann  wrote:
>
> Please update to the latest version, which has this CVE fixed.

Bug#1004947: Loses keystrokes until dialog displayed

[martin f krafft]

Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: normal

For the past decades, you could walk up to an XScreensaver-protected 
machine and hammer in the password before the dialog was shown, and 
it just worked. With version 5.x I started noticing that sometimes 
it would lose the first couple of characters when doing so 
(especially when typing fast).

With version 6, it loses all keystrokes until the dialog is actually 
displayed, which on my system sometimes takes a second or two. That 
breaks decades of muscle memory and also stretches my patience, 
since I don't want to first have to instruct the computer to show 
the dialog before it allows me to punch in the password. Instead, I 
want to just hammer the password and have it work, no matter how 
quickly the dialog gets displayed. Like it used to work for decades.


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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.61
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-5
ii  libcrypt11:4.4.27-1.1
ii  libglib2.0-0 2.70.3-1
ii  libgtk2.0-0  2.24.33-2
ii  libpam0g 1.4.0-11
ii  libpango-1.0-0   1.50.3+ds1-6
ii  libsystemd0  250.3-2
ii  libx11-6 2:1.7.2-2+b1
ii  libxext6 2:1.3.4-1
ii  libxft2  2.3.2-2
ii  libxi6   2:1.8-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.12+dfsg-5+b1
ii  libxrandr2   2:1.5.2-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.02+dfsg1-2

Versions of packages xscreensaver recommends:
ii  gsfonts-x11   0.28
ii  libjpeg-turbo-progs   1:2.1.2-1
ii  perl  5.32.1-6
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.4+nmu1.1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   97.0.4692.99-1
ii  elinks [www-browser] 0.13.2-1+b2
ii  firefox [www-browser]96.0.3-1
ii  fortune-mod [fortune]1:1.99.1-7.1
pn  gdm3 | kdm-gdmcompat 
ii  lynx [www-browser]   2.9.0dev.10-1
pn  qcam | streamer  
ii  w3m [www-browser]0.5.3+git20210102-6
pn  xdaliclock   
pn  xfishtank
pn  xscreensaver-data-extra  
ii  xscreensaver-gl  6.02+dfsg1-2
pn  xscreensaver-gl-extra

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1004946: Cannot hold down backspace to delete password

[martin f krafft]

Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: normal

If I know I mistyped the password, I am used to holding down 
backspace to erase all characters, effectively making use of the key 
repeat. This stopped working with version 6, and now holding down 
the key only ever removes a single character.

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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.61
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-5
ii  libcrypt11:4.4.27-1.1
ii  libglib2.0-0 2.70.3-1
ii  libgtk2.0-0  2.24.33-2
ii  libpam0g 1.4.0-11
ii  libpango-1.0-0   1.50.3+ds1-6
ii  libsystemd0  250.3-2
ii  libx11-6 2:1.7.2-2+b1
ii  libxext6 2:1.3.4-1
ii  libxft2  2.3.2-2
ii  libxi6   2:1.8-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.12+dfsg-5+b1
ii  libxrandr2   2:1.5.2-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.02+dfsg1-2

Versions of packages xscreensaver recommends:
ii  gsfonts-x11   0.28
ii  libjpeg-turbo-progs   1:2.1.2-1
ii  perl  5.32.1-6
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.4+nmu1.1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   97.0.4692.99-1
ii  elinks [www-browser] 0.13.2-1+b2
ii  firefox [www-browser]96.0.3-1
ii  fortune-mod [fortune]1:1.99.1-7.1
pn  gdm3 | kdm-gdmcompat 
ii  lynx [www-browser]   2.9.0dev.10-1
pn  qcam | streamer  
ii  w3m [www-browser]0.5.3+git20210102-6
pn  xdaliclock   
pn  xfishtank
pn  xscreensaver-data-extra  
ii  xscreensaver-gl  6.02+dfsg1-2
pn  xscreensaver-gl-extra

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1001153: acpitool exits with an assertion if moe than 4 power sources in sysfs

[Seunghun Han]

Hello Dietz and Dave,
Thank you for your information. I have included Dietz's patch and uploaded it.

If you have any other problems, please let me know.

Best regards,

Seunghun

Bug#1004945: Please specify required version of Sphinx build-dep

[Dato Simó]

Package: sqlalchemy
Version: 1.4.23+ds1-5

Hello!

To make the life of backporters slightly easier, could you please
version your build-dependency on Sphinx? I think >= 3.5 should be
enough:

```
dh_installdocs -O--buildsystem=pybuild
debian/rules override_dh_sphinxdoc
cd doc/build && python3 -m sphinx -N -E -b html ...

Running Sphinx v1.8.5

Sphinx version error: This project needs at least Sphinx v3.5.0
and therefore cannot be built with this version.

make[1]: *** [debian/rules:40: override_dh_sphinxdoc] Error 2
```

Bug#1004944: RM: mariadb-10.5/unstable -- RoM; obsoleted by mariadb-10.6

[Otto Kekäläinen]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove src:mariadb-10.5 from unstable.

MariaDB 10.5 has been replaced by MariaDB 10.6, which is now available
in unstable and testing.

Ref:
https://tracker.debian.org/pkg/mariadb-10.5
https://tracker.debian.org/pkg/mariadb-10.6

Bug#1004943: qemu-guest-agent shutdown now depends on systemd-logind > dbus?

[MichaIng]

Package: qemu-guest-agent
Version: 1:5.2+dfsg-11+deb11u1

When using qemu-guest-agent within a Proxmox VM running Debian Bullseye, 
we recognised that sending the shutdown command from the host only has 
any effect when systemd-logind run within the VM and hence dbus is 
installed. The latter is a native requirement for systemd-logind, which 
hence seems to be the now used by qemu-guest-agent to trigger the VM 
shutdown.


This was not the case with Debian Buster and qemu-guest-agent 1:3.1. Is 
this an expected change, or maybe also a matter of the build or runtime 
configuration? I couldn't find a related QEMU changelog entry.


If it is required now, I guess systemd and dbus should be added as 
dependencies to qemu-guest-agent, given that the VM shutdown without 
direct console access is a major feature and reason to install 
qemu-guest-agent? Though this would be a huge dependency, hence I'm 
wondering whether alternatives without systemd are possible, either with 
different build flags or other setup or config changes within the VM.


Best regards,

Micha

Bug#1004942: ITP: glyphsets -- Python API for evaluating glyph sets in font projects

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: glyphsets
  Version : 0.2.1
  Upstream Author : 2017.Google.Inc.
* URL : https://github.com/googlefonts/glyphsets 
* License : Apache-2.0
  Programming Lang: Python
  Description : Python API for evaluating glyph sets in font projects

 This python module provides an API with data about glyph sets for many
 different scripts and languages. This was crafted to specify the sets of
 characters that fonts in the Google Fonts collection are expected to provide
 glyphs for.
 .
 If you are a font developer or typeface designer,
 see the Lib/glyphsets/encodings/GF Glyph Sets subdirectory which provides
 glyph set definition "standards" that are typically useful sets to draw.
 .
 On the other hand, the nam files on the Lib/glyphsets/encodings directory are
 probably more useful for expert web developers. Those files explain how the
 Unicode Range subsets are defined, typically per script (writing system),
 in the Google Fonts css API.
 Python API for evaluating coverage of glyph sets in font projects.

Bug#1004330: makes the package useless with PHP 8

[Axel Beckert]

Hi Francesco,

Francesco Potortì wrote:
> I hope the package gets upgraded soon, because dokuwiki simply
> stopped working with PHP 8

I have a more or less working package of the most recent upstream
release plus one or two patches at
https://salsa.debian.org/abe/dokuwiki

It runs in production on https://swissmk.ch/

Actually I'd be happy if someone else could try it out as well as
Dokuwiki is a rather huge chunk of code and I'm not sure if I got
everything right.

I intend to do an NMU (due to no reaction of the maintainer on either
RC bug for over a week), but for that the package still needs a bit
more fine-tuning (like handling the other RC bug which actually no
more is one after the recent TC decision on that topic).

I also still have some strange behaviour with regards to mail
notifications (notifications for changes which either never happaned
or which happened years ago — at least they're not visible in the web
interface at the time the mails were sent) where I'm not sure what
part of the upgrade caused them.

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

Bug#982809: Packaging Godot Engine

[Wookey]

Have you looked at all at packaging godot engine itself?

I have a need for this, but have not yet looked at how big a job it is. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1003659: bullseye-pu: package python-django/2:2.2.26-1~deb11u1

[Chris Lamb]

Hi Adam,

>> * Fix a traceback around the handling of RequestSite/get_current_site() 
>> due
>>   to a circular import by backporting commit 78163d1a from upstream. 
>> Thanks
>>   to Raphaël Hertzog for the report. (Closes: #1003478)
>
> That change doesn't look like it made it to unstable yet; is that
> correct?

I'm sorry, I had assumed it would have been incorporated into the
latest upstream releases that I uploaded around the same time. Now
that I look, it is not in the cutting-edge version in experimental
either.

(I assume you would want to see it there before accepting this pu,
right?)


Regards,

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

Bug#1004941: mirror listing update for mirror.johnnybegood.fr

[Valentin DI BETTA]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirror.johnnybegood.fr
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Valentin DI BETTA 
Country: FR France
Location: Paris, France




Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/mirror.johnnybegood.fr

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Ryan Armstrong]

Perhaps I spoke too hastily earlier, or perhaps the issue only manifests for 
certain update sets. I have seen the issue again a couple times in the past 
week or so.

When I performed a manual `apt install` to install a random package after, I 
received a notice that a newer kernel is available. Perhaps that's it?

Also note that I have never actually received a desktop notification from 
debconf-kde-helper, if that was supposed to be the intended behaviour, so 
perhaps this bug should just be reassigned to that package?

Ryan

On Sunday, January 2, 2022 8:22:19 A.M. EST Ryan Armstrong wrote:
> So, I actually just installed my regular updates today with Discover and
> noticed a few library changes. The update completed properly. If I run
> needrestart after (or do an apt install), it confirms it wants to restart
> some libraries. I can continue to install other packages with Discover as
> well. So it looks like that package was all I needed.
> 
> Thanks,
> Ryan
> 
> On Saturday, January 1, 2022 8:42:26 A.M. EST Thomas Liske wrote:
> > Hi,
> > 
> > could you check running needrestart as root on cli if you have any
> > pending restarts?
> > 
> > You might try to reinstall a lib to trigger needrestart (i.e. via apt-
> > get install --reinstall libnss3 - this *should* not break anything) to
> > force to get a pending restarts.
> > 
> > Please check if needrestart and debconf-kde-helper are working when
> > using KDE Discover afterwards.
> > 
> > 
> > Regards,
> > Thomas
> > 
> > On Fri, 2021-12-31 at 10:10 -0500, Ryan Armstrong wrote:
> > > I did not, but your message prompted me to go looking a bit. I found
> > > I had
> > > not installed debconf-kde-helper. I would have expected a package
> > > like this to
> > > get pulled in when I installed KDE, so I expect it is missing as a
> > > dependency
> > > (for plasma-discover perhaps?)
> > > 
> > > In my setup, KDE was installed onto an existing setup by running `apt
> > > install
> > > kde-plasma-desktop`
> > > 
> > > I did one update after installing the helper, but didn't notice
> > > anything (it
> > > didn't stall, though). As long as that fixes the problem, I guess
> > > this bug
> > > should be redirected as a dependency issue?
> > > 
> > > Ryan
> > > 
> > > On Friday, December 31, 2021 9:54:02 A.M. EST you wrote:
> > > > Hi Ryan,
> > > > 
> > > > needrestart should not block if it is run non-interactive. On
> > > > Debian it
> > > > uses the debconf frontend which also has graphical frontends. Do
> > > > you
> > > > get debconf dialogs in KDE Discover when installing/updating
> > > > packages
> > > > at all? (Sorry I do not have an KDE environment for testing.)
> > > > 
> > > > 
> > > > Regards,
> > > > Thomas
> > > > 
> > > > On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote:
> > > > > Package: needrestart
> > > > > Version: 3.5-5
> > > > > Severity: normal
> > > > > 
> > > > > Dear Maintainer,
> > > > > 
> > > > > When I performed an update with KDE Discover, I noticed it
> > > > > stalled at
> > > > > 99% complete status and would not finish. When I checked the
> > > > > process
> > > > > tree with htop, I noticed the following lines from packagekitd
> > > > > and
> > > > > 
> > > > > needrestart:
> > > > >2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20
> > > > > 
> > > > > ├─
> > > > > /usr/libexec/packagekitd
> > > > > 
> > > > >2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >   14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >   14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24
> > > > > 
> > > > > │
> > > > > └─ /usr/libexec/packagekitd
> > > > > 
> > > > >   25864 root   20   0  494M 51924  2336 S  0.0  0.3  0:00.00
> > > > > 
> > > > > │ └─ /usr/libexec/packagekitd
> > > > > 
> > > > >   25872 root   20   0  2472   704   616 S  0.0  0.0  0:00.00
> > > > > 
> > > > > │└─ sh -c test -x /usr/lib/needrestart/apt-pinvoke &&
> > > > > /usr/lib/needrestart/apt-pinvoke || true
> > > > > 
> > > > >   25873 root   20   0 35864 27816  6140 S  0.0  0.2  0:00.64
> > > > > 
> > > > > │   └─ /usr/bin/perl /usr/sbin/needrestart
> > > > > 
> > > > > It appears that packagekit is still running needrestart to ask if
> > > > > I
> > > > > want to restart systemd services. However, this prompt is
> > > > > obviously
> > > > > not
> > > > > visible to me through KDE Discover, so it's stuck waiting
> > > > > forever.
> > > > > 
> > > > > If I use kill on needrestart, the Discover session completes.
> > > > > 
> > > > > Since, this is an interaction between Discover, packagekit, apt
> > > > > and
> > > > > needrestart (possibly others?), I'm not 100% sure this is 

Bug#984209: libsynthesis: diff for NMU version 3.4.0.47.5+syncevolution-1.5.3-1.1

[Jonas Smedegaard]

Quoting Adrian Bunk (2022-02-04 01:09:52)
> Control: forcemerge -1 1002146
> 
> On Wed, Nov 03, 2021 at 06:36:28PM +0100, Jonas Smedegaard wrote:
> > Control: tags 984209 + patch
> > Control: tags 984209 + pending
> > 
> > Dear maintainer,
> > 
> > I've released an NMU for libsynthesis (versioned as 
> > 3.4.0.47.5+syncevolution-1.5.3-1.1)
> > fixing the release-cricical bug#984209.
> 
> Did this upload get lost somewhere?

Ohh, indeed it did: Upload was rejected at my end due to accidentally 
having UNRELEASED as target suite.

I'll fix that and release it.

Thanks!

 - 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#996048: postfix-mta-sts-resolver: diff for NMU version 1.0.0-4.1

[Adrian Bunk]

Control: tags 996048 + patch
Control: tags 996048 + pending

Dear maintainer,

I've prepared an NMU for postfix-mta-sts-resolver (versioned as 1.0.0-4.1)
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru postfix-mta-sts-resolver-1.0.0/debian/changelog postfix-mta-sts-resolver-1.0.0/debian/changelog
--- postfix-mta-sts-resolver-1.0.0/debian/changelog	2020-12-05 21:24:01.0 +0200
+++ postfix-mta-sts-resolver-1.0.0/debian/changelog	2022-02-04 02:21:27.0 +0200
@@ -1,3 +1,11 @@
+postfix-mta-sts-resolver (1.0.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/control: Add allow-stderr restriction.
+(Closes: #996048)
+
+ -- Adrian Bunk   Fri, 04 Feb 2022 02:21:27 +0200
+
 postfix-mta-sts-resolver (1.0.0-4) unstable; urgency=low
 
   [ Debian Janitor ]
diff -Nru postfix-mta-sts-resolver-1.0.0/debian/tests/control postfix-mta-sts-resolver-1.0.0/debian/tests/control
--- postfix-mta-sts-resolver-1.0.0/debian/tests/control	2020-12-05 21:24:01.0 +0200
+++ postfix-mta-sts-resolver-1.0.0/debian/tests/control	2022-02-04 02:21:27.0 +0200
@@ -1,3 +1,3 @@
 Tests: run
 Depends: @, dnsmasq, nginx-extras, postfix, python3-cryptography
-Restrictions: breaks-testbed, isolation-container, needs-root
+Restrictions: breaks-testbed, isolation-container, needs-root, allow-stderr

Bug#984209: libsynthesis: diff for NMU version 3.4.0.47.5+syncevolution-1.5.3-1.1

[Adrian Bunk]

Control: forcemerge -1 1002146

On Wed, Nov 03, 2021 at 06:36:28PM +0100, Jonas Smedegaard wrote:
> Control: tags 984209 + patch
> Control: tags 984209 + pending
> 
> Dear maintainer,
> 
> I've released an NMU for libsynthesis (versioned as 
> 3.4.0.47.5+syncevolution-1.5.3-1.1)
> fixing the release-cricical bug#984209.

Did this upload get lost somewhere?

> Regards,
> 
>  - Jonas
>...

cu
Adrian

Bug#968679: debci: self-service multipackage pinning does not work as documented

[Drew Parsons]

On 2022-02-02 19:21, Paul Gevers wrote:

Followup-For: Bug #968679

This bug is still live.



I just tried with:

src:pytest-mpi, src:python-sybil, experimental

and

src:pytest-mpi,src:python-sybil, experimental

Both worked.

Did you maybe miss this line on the page: """Note: each suite can be
only present once. please separate by line."""



Well, no.  I even copied the lines you've given here, it's still 
failing to work, in the same way.
Is it some kind of permissions configuration error, if it works for you 
and not for me?


This is the full debci output from the last attempt:

autopkgtest [23:58:01]: starting date: 2022-02-03
autopkgtest [23:58:01]: version 5.19
autopkgtest [23:58:01]: host ci-worker13; command line: 
/usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo 
'"'"'pytest-mpi unstable/amd64'"'"' > /var/tmp/debci.pkg 2>&1 || true' 
'--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' > 
/etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade 
--add-apt-release=experimental 
--pin-packages=experimental=src:pytest-mpi 
--add-apt-release=experimental 
--pin-packages=experimental=src:python-sybil --output-dir 
/tmp/tmp.K9p1hcSGlj/autopkgtest-incoming/unstable/amd64/p/pytest-mpi/18927884 
pytest-mpi -- lxc --sudo --name ci-034-e8032c86 
autopkgtest-unstable-amd64

autopkgtest [23:58:12]:  test bed setup
Get:1 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:2 http://deb.debian.org/debian experimental/contrib Sources [4,180 
B]

Get:3 http://deb.debian.org/debian experimental/main Sources [376 kB]
Get:4 http://deb.debian.org/debian experimental/non-free Sources [3,884 
B]
Get:5 http://deb.debian.org/debian experimental/contrib amd64 Packages 
[6,200 B]
Get:6 http://deb.debian.org/debian experimental/non-free amd64 Packages 
[14.1 kB]
Get:7 http://deb.debian.org/debian experimental/main amd64 Packages [406 
kB]

Fetched 886 kB in 1s (1,327 kB/s)
Reading package lists...
Hit:1 http://deb.debian.org/debian experimental InRelease
Reading package lists...
W: Target Sources (main/source/Sources) is configured multiple times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Sources (contrib/source/Sources) is configured multiple times 
in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Sources (non-free/source/Sources) is configured multiple times 
in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Packages (main/binary-amd64/Packages) is configured multiple 
times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Packages (main/binary-all/Packages) is configured multiple 
times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Packages (contrib/binary-amd64/Packages) is configured 
multiple times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Packages (contrib/binary-all/Packages) is configured multiple 
times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Packages (non-free/binary-amd64/Packages) is configured 
multiple times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Packages (non-free/binary-all/Packages) is configured multiple 
times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
W: Target Sources (main/source/Sources) is configured multiple times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Sources (contrib/source/Sources) is configured multiple times 
in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Sources (non-free/source/Sources) is configured multiple times 
in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4
W: Target Packages (main/binary-amd64/Packages) is configured multiple 
times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and 

Bug#1004330: makes the package useless with PHP 8

[Francesco Potortì]

I hope the package gets upgraded soon, because dokuwiki simply stopped working 
with PHP 8

I used a stopgap, by looking at the Apache errors end modifying the php source 
files generating the error, but that's long and tedious.  And I cannot be sure 
that everything works...

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#1004940: gr-iio seems to be integrated into gnuradio now

[Adrian Bunk]

Package: gr-iio
Version: 0.3-9
Severity: serious
Tags: bookworm sid

https://www.gnuradio.org/news/2022-01-17-gnuradio-v3.10.0.0-release/

- New in-tree module gr-iio

Bug#1004939: debhelper: Drop -DCMAKE_SKIP_RPATH=on in compat v14

[Vagrant Cascadian]

Package: debhelper
Version: 13.6
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath toolchain
X-Debbugs-Cc: Vagrant Cascadian , 
reproducible-b...@lists.alioth.debian.org

The debhelper compat level v14 is still experimental, and I think it
might be worth dropping -DCMAKE_SKIP_RPATH=on, as there are cases where
it actually can trigger build failures, while
-DCMAKE_BUILD_PATH_USE_ORIGIN=ON can provide all of the reproducibility
benefits, with less liklihood to trigger build failures.

From the debhelper manpage:

  The cmake buildsystem now passes -DCMAKE_SKIP_RPATH=ON and
  -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to cmake(1) to avoid some
  reproducibility issues.

  This can cause issues with running binaries directly from the build
  directories as they might now require a manually set LD_LIBRARY_PATH.
  If you need to override this change, we recommend that you try to pass
  the -DCMAKE_SKIP_RPATH=OFF option first to see if that fixes the
  problem (leaving CMAKE_BUILD_RPATH_USE_ORIGIN at its new default).
  This should undo the need for LD_LIBRARY_PATH and avoid the
  reproducibility issues on Linux, where $ORIGIN is supported by the
  runtime linkers.

If -DCMAKE_SKIP_RPATH=ON was not included in the first place, this
latter section could be dropped and it would be easier for affected
package maintainers to adopt debhelper v14 (e.g. not having to
explicitly override the default with -DCMAKE_SKIP_RPATH=OFF) while still
gaining the reproducibility benefits.

I am not aware of cases where having -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
but not -DCMAKE_SKIP_RPATH=ON triggers reproducibility issues.

Are there issues with embedding relative RPATHs as
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON does, or other strong reasons to
exclude RPATH entirely by default?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#980316: Update yarnpkg to 2.x versions using corepack repo

[Jérémy Lal]

Package: yarnpkg
Version: 1.22.10+~cs22.25.14-5
Followup-For: Bug #980316

Hi,

i just realized that corepack was indeed not installed
by nodejs source package.

There is a reason for that: unfortunately corepack source is
not bundled into nodejs source tarball.

The distributed files are the compiled ones, and instead of
complicating things i'm just going to dfsg-exclude corepack
from nodejs source tarball.


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 yarnpkg depends on:
ii  ca-certificates20211016
ii  node-asap  2.0.6+~2.0.0-1
ii  node-babel7-runtime7.16.12+~cs214.260.189-2
ii  node-bytes 3.1.0-2
ii  node-camelcase 6.3.0-1
ii  node-chalk 4.1.2-1
ii  node-chownr2.0.0-1
ii  node-ci-info   3.2.0+~cs4.2.0-4
ii  node-cli-table 0.3.11+~cs0.13.3-1
ii  node-commander 6.2.1-2
ii  node-death 1.1.0-2
ii  node-debug 4.3.2+~cs4.1.7-1
ii  node-deep-equal2.0.5+~cs32.11.68-2
ii  node-detect-indent 6.0.0-2
ii  node-duplexify 4.1.2-1
ii  node-emoji 1.10.0+~1.8.1-1
ii  node-fast-levenshtein  2.0.6+ds-3
ii  node-glob  7.1.7+~cs7.5.19-2
ii  node-imports-loader0.8.0-5
ii  node-ini   2.0.1-1
ii  node-inquirer  8.2.0+~cs26.5.5-1
ii  node-invariant 2.2.4-1
ii  node-is-builtin-module 3.1.0-1
ii  node-js-yaml   4.1.0+dfsg+~4.0.5-6
ii  node-loud-rejection2.2.0-2
ii  node-micromatch4.0.4+~4.0.2-1
ii  node-minimatch 3.0.4+~3.0.5-1
ii  node-mkdirp1.0.4+~1.0.2-1
ii  node-object-path   0.11.8+~0.11.1-1
ii  node-path-root 0.1.1-2
ii  node-prepend-http  3.0.1-2
ii  node-proper-lockfile   4.1.2-1
ii  node-puka  1.0.1+dfsg-2
ii  node-pump  3.0.0-5
ii  node-pumpify   2.0.1-2
ii  node-read  1.0.7-3
ii  node-request   2.88.1-5
ii  node-request-capture-har   1.2.2-2
ii  node-resolve   1.20.0+~cs5.27.9-1
ii  node-rimraf3.0.2-1
ii  node-semver7.3.5+~7.3.8-1
ii  node-sort-keys 4.0.0-1
ii  node-ssri  8.0.1-2
ii  node-strict-uri-encode 2.0.0+~2.0.0-1
ii  node-strip-ansi6.0.1-1
ii  node-strip-bom 4.0.0-2
ii  node-tar-stream2.2.0+~cs3.2.2-1
ii  node-through2  4.0.2-2
ii  node-uuid  8.3.2+~8.3.3-1
ii  node-validate-npm-package-license  3.0.4-2
ii  node-yn4.0.0-2
ii  nodejs 12.22.9~dfsg-1

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

Bug#1003567: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Hi Michael,

"Michael R. Crusoe"  wrote on 24/01/2022 at 11:39:23+0100:

> [[PGP Signed Part:No public key for 3C26763F6C67E6E2 created at 
> 2022-01-24T11:39:23+0100 using RSA]]
> On Tue, 11 Jan 2022 22:38:44 +0100 p...@debian.org wrote:
>> Package: python3-schema-salad
>> Severity: wishlist
>>
>> Dear maintainer,
>>
>> Your package python3-schema-salad depends on python3-mistune 0.8.4
>> which is no longer maintained and deprecated in favour of version
>> 2.0.0.
>>
>> As python3-mistune 2.0.0 is not backward compatible, I reverted the
>> upload of it that I did in unstable and python3-mistune 0.8.4 will
>> stay around a bit longer.
>>
>> In the meantime, please try to see if upstream of
>> python3-schema-salad either released a version that is compatible
>> with python3-mistune 2.0.0 or if python3-schema-salad can easily be
>> fixed to support such a version. As soon as you're ready to upload
>> your package please update this bug report and we'll try to
>> coordinate so that I release python3-mistune at a time that is fit
>> for you to also release python3-schema-salad.
>
> Dear Pierre-Elliott Bécue,
>
> Thank you for trying to find a way forward in this mess. I am also the
> upstream maintainer for schema-salad. We have yet to find a way to 
> support mistune 2.x
>
> Here is our attempt so far:
>
> https://github.com/common-workflow-language/schema_salad/pull/496/files?short_path=5c6a130#diff-5c6a1301c6b59b30a040d747d065e861d3dd98bde0e5a4356d92d594e9835986
>
> And an issue I opened with mistune directly about a regression in
> multi-line list handling that goes against multiple markdown specs: 
> https://github.com/lepture/mistune/issues/296
>
> We have not decided if we will switch to another library, wait for a
> fixed mistune 2.x release, or keep with the older version.
>
>> I intend to upload src:mistune 2.0.0 to unstable between March the
>
>> 15th and April the 15th (depending on the progress of its
>> reverse-dependencies). I'll raise the severity of this bug
>> approximately a month before making such an upload.
>
> Since Mistune 2.0.0 regresses its support for standard markdown, I ask
> that a separate package be made for mistune 2.x to give more time for 
> mistune 0.8.x users to migrate to mistune 2.x or another library entirely.
>
> Cheers,

I'm not formally against it, but it's not really standard in my
opinion. It'd lead to maintenance of two packages, probably on some long
term (as it'd relieve the pressure to migrate for maintainers of
reverse-deps of mistune).

Besides, having a source package named "mistune2" while upstream's
package is named "mistune" adds also another layer of complexity.

I'd like to have some python team members' opinion on this, and I am not
sure to be eager to do it as of now.

Cheers!
-- 
PEB


signature.asc
Description: PGP signature

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Santiago Garcia Mantinan]

On Xan 20 2022, Anton Khirnov wrote:
> Attaching a patch. I still couldn't think of a reason this code should
> ever disable IPv6 on the physical interface, so it's removed
> unconditionally. If anyone can think of such a reason, then I guess an
> option could be added?

Well, the thing here is that since de beginning of the bridge code it was
recommended not to add ip addresses to the bridge ports, this was a long
time ago, and maybe it has changed, if so, I'd like to know when.

But anyway... why would you want to have
an IP v4 or v6 on the bridge ports? why not having it on the bridge itself?

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)

[Hans-Christoph Steiner]

> - you add to your pull request a change of the virtualized disk
> controller from virtio-blk to virtio-scsi and to the default libvirt
> vagrantfile the "unmap" option so that deletion of blocks in the guest
> are propagated om host storage

I looked into this a bit more.  These feature weren't added to vagrant-libvirt 
until 0.4.0, so no stable Debian package of vagrant-libvirt could support this 
yet.  Debian/testing has 0.7.0, and a backport to stable would be possible.  I 
guess a lot of people just use `vagrant plugin install ...`. It might be 
possible to make it work with older vagrant-libvirt versions by using a hack 
like this:


https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692#issuecomment-922329049


There is a little more info here:
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/999#issuecomment-487728207


```
ENV['VAGRANT_EXPERIMENTAL'] = 'typed_triggers'

require 'open3'

Vagrant.configure('2') do |config|
  ...
  config.vm.provider :libvirt do |lv, config|
lv.storage :file, :size => '3G', :device => 'sda', :bus => 'scsi', :discard 
=> 'unmap', :cache => 'unsafe'
config.trigger.before 
:'VagrantPlugins::ProviderLibvirt::Action::StartDomain', type: :action do |trigger|

  trigger.ruby do |env, machine|
stdout, stderr, status = Open3.capture3(
  'virt-xml', machine.id,
  '--edit', 'type=scsi',
  '--controller', 'model=virtio-scsi')
if status.exitstatus != 0
  raise "failed to run virt-xml to modify the controller model. 
status=#{status.exitstatus} stdout=#{stdout} stderr=#{stderr}"

end
  end
end
...
  end
end
```

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

On Thu, 2022-02-03 at 13:37 +0100, Paul Gevers wrote:
> I ran across this issue again. Just a sanity check, you did take care
> of this, right?
> 
> """
> rw-build-tree

Hey Paul,

Yes, indeed. The test's Restrictions stanza is as follows: rw-build-
tree, build-needed, allow-stderr, isolation-container.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1004452: gnuplot 5.4.1+dfsg1-1+deb11u1 flagged for acceptance

[Daniel Kahn Gillmor]

Hi Adam--

No problem, i've made way worse copy/paste mistakes myself 

On Thu 2022-02-03 06:41:21 +, Adam D. Barratt wrote:
> Control: tags -1 - pending

For clarity, I'm assuming this means that the GnuPG upload for bullseye
(#1004452) is *not* yet approved, and i will wait for additional
feedback from you or other release managers before continuing.

Thanks for the quick followup!

--dkg


signature.asc
Description: PGP signature

Bug#1004938: Invalid encoding of spam mail causes offlineimap to crash

[Wouter Verhelst]

Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20211018.e64c254+dfsg-1
Severity: normal

An email in my spam folder has started causing the following crash:

Folder spam [acc: Test]:
 Syncing spam: IMAP -> Maildir
 Copy message UID 1353368115 (1/88) Folk:spam -> Local:spam
 Copy message UID 1353368116 (2/88) Folk:spam -> Local:spam
Copy message from Folk:spam:
 ERROR: Copying message 1353368115 [acc: Test]
  'ascii' codec can't encode characters in position 1541-1579: ordinal not in 
range(128)
Thread 'Copy message from Folk:spam' terminated with exception:
Traceback (most recent call last):
  File "/usr/share/offlineimap3/offlineimap/threadutil.py", line 146, in run
Thread.run(self)
  File "/usr/lib/python3.9/threading.py", line 910, in run
self._target(*self._args, **self._kwargs)
  File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 815, in 
copymessageto
new_uid = dstfolder.savemessage(uid, message, flags, rtime)
  File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 409, in 
savemessage
tmpname = self.save_to_tmp_file(messagename, msg)
  File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 359, in 
save_to_tmp_file
fd.write(msg.as_bytes(policy=output_policy))
  File "/usr/lib/python3.9/email/message.py", line 178, in as_bytes
g.flatten(self, unixfrom=unixfrom)
  File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
  File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
  File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
  File "/usr/lib/python3.9/email/generator.py", line 276, in _handle_multipart
g.flatten(part, unixfrom=False, linesep=self._NL)
  File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
  File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
  File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
  File "/usr/lib/python3.9/email/generator.py", line 362, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False, linesep=self._NL)
  File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
  File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
  File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
  File "/usr/lib/python3.9/email/generator.py", line 268, in _handle_multipart
self.write(subparts)
  File "/usr/lib/python3.9/email/generator.py", line 410, in write
self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
1541-1579: ordinal not in range(128)

I'm not entirely sure what the message is that causes the exact error,
but I can look that up if you need me to.

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

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

Versions of packages offlineimap depends on:
ii  offlineimap3  0.0~git20211018.e64c254+dfsg-1

offlineimap recommends no packages.

offlineimap suggests no packages.

-- no debconf information

Bug#1001068: samba: Missing upstream commit 0a546be0 on bullseye, bookworm and sid (part of CVE-2020-25717)

[Salvatore Bonaccorso]

Hi Jörg,

On Fri, Dec 03, 2021 at 03:44:02PM +0100, Jörg Behrmann wrote:
> Package: samba
> Version: 2:4.13.13+dfsg-1~deb11u2
> Severity: important
> X-Debbugs-Cc: t...@security.debian.org
> 
> The upstream samba commit 0a546be0 is included in the buster security release
> 2:4.9.5+dfsg-5+deb10u2 via the patch file bug-14901-v4-9.patch, but is missing
> in the bullseye security release 2:4.13.13+dfsg-1~deb11u2.
> 
> Pleae apply that patch in bullseye as well, so that the idmap_nss fallback via
> SID mapping works.

In case you have the possiblity, can you test the packages from
https://people.debian.org/~carnil/tmp/samba/2022-01-31/bullseye/ ?

Regards,
Salvatore

Bug#1004886: dmesg: colorization of emerg/notice/info/debug not handled

[Chris Hofstaedtler]

Hello Eric Estievenart,

* Eric Estievenart  [220202 23:00]:
> Hello,
> please find attached a very simple patch which allows consistent customization
> of the coloring schemes  of the emerg, notice, info and debug levels in dmesg.
> (currently only alert, crit, err and warn coloring schemes could be 
> customized).
> 
> output changes (when coloring enabled):
>   emerg level takes a default reverse+red, as alert and crit.
>   debug level takes dark gray (seems reasonable)
> 
> As my color choices might not suit the masses (or even offend them!),
> notice and info levels are unaffected and keep a default reset vt100 sequence.
> Afterall, they could then be customized via 
> /etc/terminal-colors.d/dmesg.scheme
> 
> == LEGAL STUFF ==
> Due to the triviality of the patch, I HEREBY EXPLICITELY DISMISS any right, 
> copyrights, whatsoever,
> applying to this patch, with or without changes, and grant the rights to the 
> Debian maintainer,
> and/or upstream maintainers, or anybody, to have it applied to Debian and/or 
> upstream, even on his/her own name,
> without even mentioning me, hoping this will make things faster and paperless.
> (If this is not sufficient or explicit enough, please tell, but, honestly...)

Thank you for submitting a patch. It is best if you submit your
patch directly to upstream. Please read this document, which
explains how to do it and what the legal requirements are:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/Documentation/howto-contribute.txt

Many thanks,
Chris

Bug#1003176: transition: perl 5.34

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-01-23 12:45:16, Sebastian Ramacher wrote:
> Control: block -1 by 1002681
> Control: forwarded -1 
> https://release.debian.org/transitions/html/perl-5.34.html
> 
> On 2022-01-05 17:00:54 +, Niko Tyni wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org
> > Control: block -1 with 1002093 997267 997189
> > 
> > Hi,
> > 
> > we'd like a transition slot for Perl 5.34.
> > 
> > Should have done this months ago, but real life has interfered. Sorry
> > about that.
> > 
> > Perl 5.36 is scheluded for May or so, and I expect that will be our target
> > for bookworm.  Nevertheless, it's probably best to do this incrementally
> > and have a 5.34 transition now in case 5.36 turns out to be difficult
> > for some reason.
> > 
> > The changes in 5.34 are quite small, as upstream spent most of that
> > release cycle planning Perl 7 (which did not quite work out.) This
> > reflects in the very low number regressions we found in our test
> > rebuilds, visible at
> > 
> >   
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org
> > 
> > with just one bug open (openscap, not in testing).
> > 
> > I did a full archive test rebuild back in May, and partial test rebuilds
> > in August. Coming back to this now, I've done another round of test
> > rebuilds for those packages that will need binNMUs. I don't think another
> > full round is necessary: it seems unlikely that the other packages might
> > have introduced any Perl 5.34 related regressions in the meantime.
> > 
> > There's a few packages that have unrelated build failures in current sid.
> > I'm marking the ones in testing as blockers for this.
> 
> Some packages are also involved in the ongoing ocaml transition. So
> let's wait for ocaml to be done.

ocaml is done, so please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1004937: python-opcua: fix collections import under python 3.10+

[Andreas Hasenack]

Package: python-opcua
Version: 0.98.11-1
Severity: normal

Dear Maintainer,

python-opcua is showing this failure under python 3.10:

$ debian/tests/basic-import-py3
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/ubuntu/git/packages/python-opcua/python-opcua/opcua/__init__.py",
line 8, in 
from opcua.common.subscription import Subscription
  File 
"/home/ubuntu/git/packages/python-opcua/python-opcua/opcua/common/subscription.py",
line 7, in 
from collections import Iterable
ImportError: cannot import name 'Iterable' from 'collections'
(/usr/lib/python3.10/collections/__init__.py)

Upstream has this fix in 0.98.12:
https://github.com/FreeOpcUa/python-opcua/commit/34d98f992f9f7e494be20f028cdf9a05b3b62540

>From 34d98f992f9f7e494be20f028cdf9a05b3b62540 Mon Sep 17 00:00:00 2001
From: Nick James <20824939+driftreg...@users.noreply.github.com>
Date: Fri, 19 Jun 2020 03:56:17 +0800
Subject: [PATCH] remove DeprecationWarning: import Iterable from
 collections.abc if python >= 3.6 (#1075)

Co-authored-by: Nick James 
---
 opcua/common/subscription.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/opcua/common/subscription.py b/opcua/common/subscription.py
index 19b8d1a8..defbafb0 100644
--- a/opcua/common/subscription.py
+++ b/opcua/common/subscription.py
@@ -4,7 +4,11 @@
 import time
 import logging
 from threading import Lock
-from collections import Iterable
+import sys
+if sys.version_info.major == 3 and sys.version_info.minor >= 6:
+from collections.abc import Iterable
+else:
+from collections import Iterable

 from opcua import ua
 from opcua.common import events

Bug#1004936: RFS: diodon/1.12.0-1 -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "diodon":

 * Package name: diodon
   Version : 1.12.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : LGPL-2.1+, GPL-2+, LGPL-3+
 * Vcs : 
https://git.launchpad.net/~diodon-team/+git/debian-packaging

   Section : utils

It builds those binary packages:

  diodon - GTK+ Clipboard manager
  libdiodon0 - GTK+ Clipboard manager (main library)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  diodon-dev - GTK+ Clipboard manager (development files)

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/diodon/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.12.0-1.dsc


Changes since the last upload:

 diodon (1.12.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Avoid history being empty on first run (Closes: #961604)

Regards,

Bug#1004935: connman: CVE-2022-23096 CVE-2022-23097 CVE-2022-23098

[Salvatore Bonaccorso]

Source: connman
Version: 1.36-2.3
Severity: grave
Tags: security upstream
Forwarded: https://lore.kernel.org/connman/20220125090026.5108-1-w...@monom.org/
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.36-2.2
Control: found -1 1.36-2.1~deb10u1
Control: found -1 1.36-2.1~deb10u2

Hi,

The following vulnerabilities were published for connman.

CVE-2022-23096[0]:
| An issue was discovered in the DNS proxy in Connman through 1.40. The
| TCP server reply implementation lacks a check for the presence of
| sufficient Header Data, leading to an out-of-bounds read.


CVE-2022-23097[1]:
| An issue was discovered in the DNS proxy in Connman through 1.40.
| forward_dns_reply mishandles a strnlen call, leading to an out-of-
| bounds read.


CVE-2022-23098[2]:
| An issue was discovered in the DNS proxy in Connman through 1.40. The
| TCP server reply implementation has an infinite loop if no data is
| received.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-23096
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23096
[1] https://security-tracker.debian.org/tracker/CVE-2022-23097
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23097
[2] https://security-tracker.debian.org/tracker/CVE-2022-23098
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23098

Regards,
Salvatore

Bug#1004934: mailman3: CVE-2021-34337

[Salvatore Bonaccorso]

Source: mailman3
Version: 3.3.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.2.1-1

Hi,

The following vulnerability was published for mailman3.

CVE-2021-34337[0]:
| password checking timing attack in administrative REST API

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-34337
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34337
[1] 
https://gitlab.com/mailman/mailman/-/commit/e4a39488c4510fcad8851217f10e7337a196bb51

Regards,
Salvatore

Bug#1004790: avifile: should this package be removed?

[Ying-Chun Liu (PaulLiu)]

Hi Sebastian,

I've maintained onscripter, which uses avifile to play animation in game.
So it is still needed for me for that package.
I think I can spend my time fixing #1004789 - forward porting to ffmpeg 5.0.

Will fix #1004789 and then close this bug too on next upload.

Yours,
Paul

Sebastian Ramacher 於 2022/2/2 05:25 寫道:

Source: avifile
Version: 1:0.7.48~20090503.ds-21
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

Upstream development of avifile has ceased over a decode ago. Given that
avifile fails to build with ffmpeg 5.0 (see ##1004789) as it did with
all the previous major releases of ffmpeg, I wonder if is still
sustainable to keep this package in Debian. Should this package be
removed from unstable?

Cheers


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004933: RM: gif2apng -- RoQA; dead upstream, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gif2apng, it's dead upstream and has open security issues

Cheers,
Moritz

Bug#1004748: guestfs-tools ftbfs with new ocaml

[Sergio Durigan Junior]

Control: tags -1 + patch

On Tuesday, February 01 2022, Matthias Klose wrote:

> guestfs-tools ftbfs with new ocaml
>
> [...]
> Use the equivalent signed form: +C+D+E+F+L+M+P+S+U+V+Y+Z+X+52-3.
> Hint: Enabling or disabling a warning by its mnemonic name requires a + or - 
> prefix.
> Hint: Did you make a spelling mistake when using a mnemonic name?
> File "perl_edit.ml", line 30, characters 2-13:
> 30 |   c_edit_file (verbose ()) g (Guestfs.c_pointer g) file expr
>^^^
> Error (warning 6 [labels-omitted]): label verbose was omitted in the 
> application
> of this function.
> make[4]: *** [Makefile:1806: perl_edit.cmx] Error 2
> make[4]: *** Waiting for unfinished jobs
> touch stamp-virt-customize.pod
> make[4]: Leaving directory '/packages/tmp/guestfs-tools-1.46.1/customize'
> make[3]: *** [Makefile:939: all] Error 2
> make[3]: Leaving directory '/packages/tmp/guestfs-tools-1.46.1/customize'
> make[2]: *** [Makefile:855: all-recursive] Error 1
> make[2]: Leaving directory '/packages/tmp/guestfs-tools-1.46.1'
> make[1]: *** [Makefile:769: all] Error 2
> make[1]: Leaving directory '/packages/tmp/guestfs-tools-1.46.1'
> dh_auto_build: error: make -j64 returned exit code 2
> make: *** [debian/rules:19: binary-arch] Error 25

Upstream already has a fix:

https://github.com/rwmjones/guestfs-tools/commit/577f7aee4b1c720f4c4826115b49a0c3870b149e

The following debdiff should fix it on Debian (feel free to
remove/rewrite the changelog entry).

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index a849c22..67427d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+guestfs-tools (1.46.1-5) UNRELEASED; urgency=medium
+
+  [ Hilko Bengen ]
+  * Run tests on more architectures: ppc64el, s390x
+
+  [ Sergio Durigan Junior ]
+  * d/p/Disable-OCaml-warning-6-completely.patch:
+Disable OCaml warning 6 completely, fixing FTBFS with new ocaml.
+(Closes: #1004748)
+
+ -- Sergio Durigan Junior   Thu, 03 Feb 2022 14:14:11 
-0500
+
 guestfs-tools (1.46.1-4) unstable; urgency=medium
 
   * Add missing build-dependencies
diff --git a/debian/patches/Disable-OCaml-warning-6-completely.patch 
b/debian/patches/Disable-OCaml-warning-6-completely.patch
new file mode 100644
index 000..0c0e427
--- /dev/null
+++ b/debian/patches/Disable-OCaml-warning-6-completely.patch
@@ -0,0 +1,41 @@
+From: "Richard W.M. Jones" 
+Date: Fri, 10 Dec 2021 10:20:34 +
+Subject: Disable OCaml warning 6 completely
+
+Warning 6 "labels-omitted" is not useful.  It's fine to omit labels on
+positional arguments.
+
+Example:
+
+  File "perl_edit.ml", line 30, characters 2-13:
+  30 |   c_edit_file (verbose ()) g (Guestfs.c_pointer g) file expr
+ ^^^
+  Warning 6 [labels-omitted]: label verbose was omitted in the application of 
this function.
+
+The function is specified as:
+
+  external c_edit_file : verbose:bool -> Guestfs.t -> int64 -> string -> 
string -> unit
+
+The complaint is that the verbose: label has been omitted from the
+first argument when the function is called, but IMO this is a
+stylistic thing, not a bug.
+
+Origin: backport, 
https://github.com/rwmjones/guestfs-tools/commit/577f7aee4b1c720f4c4826115b49a0c3870b149e
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004748
+---
+ m4/guestfs-ocaml.m4 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/m4/guestfs-ocaml.m4 b/m4/guestfs-ocaml.m4
+index f5ac7ef..bc80e0f 100644
+--- a/m4/guestfs-ocaml.m4
 b/m4/guestfs-ocaml.m4
+@@ -166,7 +166,7 @@ EOF
+ ])
+ 
+ dnl Flags we want to pass to every OCaml compiler call.
+-OCAML_WARN_ERROR="-warn-error CDEFLMPSUVYZX+52-3"
++OCAML_WARN_ERROR="-warn-error +C+D+E+F+L+M+P+S+U+V+Y+Z+X+52-3-6 -w -6"
+ AC_SUBST([OCAML_WARN_ERROR])
+ OCAML_FLAGS="-g -annot $safe_string_option"
+ AC_SUBST([OCAML_FLAGS])
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..1e2c7c0
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+Disable-OCaml-warning-6-completely.patch


signature.asc
Description: PGP signature

Bug#1004071: closed by Debian FTP Masters (Bug#1004075: Removed package(s) from unstable)

[Andreas Beckmann]

Control: reopen -1
Control: reassign -1 google-guest-agent 2026.00-1

With python3-google-compute-engine gone, you should add

  Breaks+Replaces: python3-google-compute-engine

to google-guest-agent, to ensure there are no upgrade issues if 
python3-google-compute-engine from oldstable is still installed.



Andreas

Bug#1004929:

[Andreas Hasenack]

Salsa PR at 
https://salsa.debian.org/debian/python-orderedmultidict/-/merge_requests/12

Bug#1004932: ITS: lifelines

[Boyuan Yang]

Source: lifelines
Version: 3.0.61-2.1
Severity: important
X-Debbugs-CC: f...@debian.org

Dear package lifelines maintainer in Debian,

After looking into the package you maintain (lifelines, 
https://tracker.debian.org/pkg/lifelines), I found that this package
received no maintainer updates in the past 10 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release, clean up packaging,
fix RC bugs, and orphan the package to allow possible external contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Feb. 24, 2022) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1004930: build-depends on obsolete versioned lcl packages.

[peter green]

Package: astap-cli
Version: 0.9.588-3
Serverity: serious
Tags: patch

astap-cli build-depends on the lcl-2.0 lcl-utils-2.0 and lcl-nogui-2.0 packages 
which
are no longer built by the lazarus source package. They are still present in 
unstable
as cruft packages, but are completely gone from testing.

I prepared a patch changing the package to use the unversioned 
lcl/lcl-utils/lcl-nogui
packages and was able to get a succesful build in sid.

diff -Nru astap-cli-0.9.588/debian/changelog astap-cli-0.9.588/debian/changelog
--- astap-cli-0.9.588/debian/changelog  2021-11-02 20:30:51.0 +
+++ astap-cli-0.9.588/debian/changelog  2022-02-03 18:40:02.0 +
@@ -1,3 +1,10 @@
+astap-cli (0.9.588-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on unversioned lcl packages.
+
+ -- Peter Michael Green   Thu, 03 Feb 2022 18:40:02 +
+
 astap-cli (0.9.588-3) unstable; urgency=medium
 
   * debian/rules: set primary config file of lazarus to /etc/lazarus
diff -Nru astap-cli-0.9.588/debian/control astap-cli-0.9.588/debian/control
--- astap-cli-0.9.588/debian/control2021-11-02 01:31:06.0 +
+++ astap-cli-0.9.588/debian/control2022-02-03 18:40:02.0 +
@@ -7,9 +7,9 @@
, lazarus
, fpc
, fp-compiler
-   , lcl-2.0
-   , lcl-utils-2.0
-   , lcl-nogui-2.0
+   , lcl
+   , lcl-utils
+   , lcl-nogui
 Standards-Version: 4.6.0
 Homepage: http://www.hnsky.org/astap.htm
 Rules-Requires-Root: binary-targets

Bug#1004928: build-depends on obsolete versioned lcl packages.

[peter green]

Package: astap
Version: 0.9.588-2
Serverity: serious
Tags: patch

astap build-depends on the lcl-2.0 lcl-utils-2.0 and lcl-nogui-2.0 packages 
which
are no longer built by the lazarus source package. They are still present in 
unstable
as cruft packages, but are completely gone from testing.

I prepared a patch changing the package to use the unversioned 
lcl/lcl-utils/lcl-nogui
packages and was able to get a succesful build in sid.
diff -Nru astap-0.9.588/debian/changelog astap-0.9.588/debian/changelog
--- astap-0.9.588/debian/changelog  2021-11-02 20:30:51.0 +
+++ astap-0.9.588/debian/changelog  2022-02-03 18:40:02.0 +
@@ -1,3 +1,10 @@
+astap (0.9.588-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on unversioned lcl packages.
+
+ -- Peter Michael Green   Thu, 03 Feb 2022 18:40:02 +
+
 astap (0.9.588-2) unstable; urgency=medium
 
   * debian/rules: set primary config file of lazarus to /etc/lazarus
diff -Nru astap-0.9.588/debian/control astap-0.9.588/debian/control
--- astap-0.9.588/debian/control2021-11-01 19:57:51.0 +
+++ astap-0.9.588/debian/control2022-02-03 18:39:55.0 +
@@ -7,9 +7,9 @@
, lazarus
, fpc
, fp-compiler
-   , lcl-2.0
-   , lcl-utils-2.0
-   , lcl-nogui-2.0
+   , lcl
+   , lcl-utils
+   , lcl-nogui
 Standards-Version: 4.6.0
 Homepage: http://www.hnsky.org/astap.htm
 Rules-Requires-Root: no

Bug#1004929: python-orderedmultidict: fix collections import under py3.10

[Andreas Hasenack]

Package: python-orderedmultidict
Version: 1.0-4
Severity: normal

Dear Maintainer,

in python 3.10, "from collections import " doesn't work anymore
and should be imported from collections.abc.

$ sh debian/tests/unittest

   [0/1942]
EE
==
ERROR: test_itemlist (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_itemlist
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/tests/test_itemlist.py",
line 18, in 
from orderedmultidict.itemlist import itemlist
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/orderedmultidict/__init__.py",
line 14, in 
from .orderedmultidict import *  # noqa
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/orderedmultidict/orderedmultidict.py",
line 15, in 
from collections import MutableMapping
ImportError: cannot import name 'MutableMapping' from 'collections'
(/usr/lib/python3.10/collections/__init__.py)


==
ERROR: test_orderedmultidict (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_orderedmultidict
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/tests/test_orderedmultidict.py",
line 20, in 
from orderedmultidict.orderedmultidict import omdict
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/orderedmultidict/__init__.py",
line 14, in 
from .orderedmultidict import *  # noqa
  File 
"/home/ubuntu/git/packages/python-orderedmultidict/python-orderedmultidict/orderedmultidict/orderedmultidict.py",
line 15, in 
from collections import MutableMapping
ImportError: cannot import name 'MutableMapping' from 'collections'
(/usr/lib/python3.10/collections/__init__.py)


--
Ran 2 tests in 0.000s


Upstream fixed it in
https://github.com/gruns/orderedmultidict/commit/154e2c52a0368715c22e856f0c135e9770365d4d
which is part of the 1.0.1 release:

>From 2a3d04c5bbb28804320d7f457d65ead3bcc07c10 Mon Sep 17 00:00:00 2001
From: Simon Brunning 
Date: Sat, 2 Feb 2019 09:13:36 +
Subject: [PATCH] Fix #19, warning importing from collections rather than
 collections.abc.

---
 orderedmultidict/orderedmultidict.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/orderedmultidict/orderedmultidict.py
b/orderedmultidict/orderedmultidict.py
index 2d21239..bcb6481 100644
--- a/orderedmultidict/orderedmultidict.py
+++ b/orderedmultidict/orderedmultidict.py
@@ -13,19 +13,23 @@
 from __future__ import absolute_import

 from itertools import chain
-from collections import MutableMapping

 import six
 from six.moves import map, zip_longest

 from .itemlist import itemlist
+import sys
+
+if six.PY3:
+from collections.abc import MutableMapping
+else:
+from collections import MutableMapping

 try:
 from collections import OrderedDict as odict  # Python 2.7 and later.
 except ImportError:
 from ordereddict import OrderedDict as odict  # Python 2.6 and earlier.

-import sys
 items_attr = 'items' if sys.version_info[0] >= 3 else 'iteritems'

 _absent = object()  # Marker that means no parameter was provided.

Bug#1004926: libgd-graph-perl: FTBFS with libgd-perl >= 2.75

[gregor herrmann]

Source: libgd-graph-perl
Version: 1.48-2
Severity: serious
Tags: upstream ftbfs sid bookworm
Justification: fails to build from source
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=140940

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As noticed by ci.d.n, libgd-graph-perl has test failures with recent
versions of libgd-perl (first 2.75-1, now 2.76-1).

The current failure is:

Problems reading t/images/logo_xbm_noext (tried: libgd best-guess) at 
t/bugfixes.t line 46.

#   Failed test '_read_logo_file succeeds for xbm without file extension'
#   at t/bugfixes.t line 46.

#   Failed test 'undef isa 'GD::Image''
#   at t/bugfixes.t line 48.
# undef isn't defined
# Looks like you failed 2 tests of 33.
t/bugfixes.t ... 
1..33
ok 1 - use GD::Graph;
ok 2 - Got an object from new()
ok 3 - An object of class 'GD::Graph' isa 'GD::Graph'
ok 4 - _read_logo_file succeeds for gif with file extension
ok 5 - An object of class 'GD::Image' isa 'GD::Image'
ok 6 - _read_logo_file succeeds for gif without file extension
ok 7 - An object of class 'GD::Image' isa 'GD::Image'
ok 8 - _read_logo_file succeeds for jpeg with file extension
ok 9 - An object of class 'GD::Image' isa 'GD::Image'
ok 10 - _read_logo_file succeeds for jpeg without file extension
ok 11 - An object of class 'GD::Image' isa 'GD::Image'
ok 12 - _read_logo_file succeeds for jpeg with alternate extension
ok 13 - An object of class 'GD::Image' isa 'GD::Image'
ok 14 - _read_logo_file succeeds for png with file extension
ok 15 - An object of class 'GD::Image' isa 'GD::Image'
ok 16 - _read_logo_file succeeds for png without file extension
ok 17 - An object of class 'GD::Image' isa 'GD::Image'
ok 18 - _read_logo_file succeeds for png with alternate extension
ok 19 - An object of class 'GD::Image' isa 'GD::Image'
ok 20 - _read_logo_file succeeds for xbm with file extension
ok 21 - An object of class 'GD::Image' isa 'GD::Image'
not ok 22 - _read_logo_file succeeds for xbm without file extension
not ok 23 - undef isa 'GD::Image'
ok 24 - Skipping: GD *really* doesn't support importing XPM files
ok 25 - Skipping: GD *really* doesn't support importing XPM files
ok 26 - Skipping: GD *really* doesn't support importing XPM files
ok 27 - Skipping: GD *really* doesn't support importing XPM files
ok 28 - use GD::Graph::bars;
ok 29 - freakish divide-by-zero trick
ok 30 - No fatalities on the above
ok 31 - Survived 20792
ok 32 - and got a result
ok 33 - No timeout
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/33 subtests 


This is tracked upstream at https://rt.cpan.org/Ticket/Display.html?id=140940
and https://rt.cpan.org/Ticket/Display.html?id=140910


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmH8Hw9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbsZhAAurp7E0WDXHqB1PTcwOcOjHhUp8nvJDUlSxZyIFaoHAisJ9XFNynvRbs3
Z3qTSk50jmsQtEnUjAfQoW1QWnyRv2GCCiohcPx/8BPLjFL8/PLVhkIEX26QMTsh
nVlxwxlYeEWZxLTFyThWdlzHm49xOxAov4Iexe3vvyf5JZN3HcVsqYe3nprDW+8H
2QNL//Di12HRubFOGnkkYtDjOGuin7sDD+e083+CUabZHRlL/u9euOknZU2FvFh3
12SglgjdR4SOiJOOQ7OPUqwBJlllX0NYU629iILCwfJNDXJHTZUWZgqLt99vL2hm
NLYd9dMT1ZIqrtw4wNE1jC2JQbPh9+W1+PofcGltp+8ykgrc5mtqaz20tlgaP8I0
N8ts8LDxENVY5iFI0VweyQDeTG4wsG522v3WCRlpNqAuVJp7LxP9pDxY3CufDVS9
y09xKwznr6waDM8S4CnL4GCqOyQZw7D2TvEtl0hT/JwmsDcGgDEjD2wK2dgMiC6K
wn+DHSeDSvKt2m9MvFaA1QDiu9Ir0W78q0kLFosUyIcxUUy6UAthGOkSQ1NZpH3N
nl2+dX/S0bdksClNt5ir5hbuFYAJ/neJwv2n9hdmsRa3wRwS5ViPA76XZ1qLZkw7
ZkK2iOTc3YRwnU9mvxbUevExNFjQ2fjS2BmzW7jEz505xRXmrvE=
=9COu
-END PGP SIGNATURE-

Bug#1004927: ITP: libtree -- ldd as a tree

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libtree
  Version : 3.0.2
  Upstream Authors: Harmen Stoppels
  URL : https://github.com/haampie/libtree
* License : MIT
  Description : ldd as a tree
 This is tool like ldd with these features:
 - turns ldd into a tree
 - explains why shared libraries are found and why not

Bug#766385: Generating /boot/initrd... seen twice in a single aptitude full-upgrade

[Oswald Buddenhagen]

some more context probably helps:

...
Setting up linux-image-5.15.0-3-amd64 (5.15.15-2) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.15.0-3-amd64:.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.15.0-3-amd64
...
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-3-amd64
Found initrd image: /boot/initrd.img-5.15.0-3-amd64
...
Setting up virtualbox-dkms (6.1.32-dfsg-1+b1) ...
Loading new virtualbox-6.1.32 DKMS files...
Building for 5.15.0-3-amd64
Building initial module for 5.15.0-3-amd64
...
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.15.0-3-amd64
...

so it would appear that the mistake is that the kernel postinst does an 
instantaneous initramfs update, rather than letting the trigger take 
care of it, after DKMS has built the modules of other upgraded packages.


it may also make sense to sequence the grub setup after the initrd 
setup, so it doesn't register kernels for which building the initrd 
failed.

Bug#793660: Is still an issue

[Timo Aaltonen]

Marc Haber kirjoitti 3.2.2022 klo 18.20:

Control: tags -1 - moreinfo + confirmed
thanks

On Thu, Feb 03, 2022 at 02:54:24PM +0100, Marc Haber wrote:

On Wed, Feb 02, 2022 at 07:55:07PM +0100, Borden wrote:

Just reinstalled again, ran a sudo command and got

debian: Feb  2 18:47:09 : borden : problem with defaults entries ; TTY=pts/1 ; 
PWD=/home/borden ; USER=root ;

Delivered to my inbox. I'm not sure if that's a bug problem or a me problem


I have never seen such a message delivered via e-mail. Is this a strange
syslog configuration, or a container setup? Normally, message like this
end up in auth.log.


Ok, I now understand what you mean, and I can reproduce the issue.
Excuse me for being so stupid.

The linked Red Hat bugreport was help for me
(https://bugzilla.redhat.com/show_bug.cgi?id=879633). You don't need an
LDAP server, you don't need sssd running, it is just necessary to
install sudo and libsss-sudo and have "sudoers: files sss" in
nssswithc.conf.

Any sudo call will result in a single e-mail message like this being sent
out:
| From: Marc Haber 
| Subject: *** SECURITY information for testsid85.zugschlus.de ***
| To: r...@testsid85.zugschlus.de
| Date: Thu, 03 Feb 2022 16:54:27 +0100
|
| testsid85.zugschlus.de : Feb  3 16:54:26 : mh : problem with defaults entries 
; TTY=pts/0 ; PWD=/home/mh ; USER=root ;

The Red Hat Bug Report links to a patch,
https://bugzilla-attachments.redhat.com/attachment.cgi?id=650460, but I am
not sure whether this patch makes sense (it only seems to turn off the error
exit code in case of sss_error == ENOENT). @Timo, is that a valid solution?

I am also bothered by the error text "problem with defaults entries". I
have filed upstream bug 1022
(https://bugzilla.sudo.ws/show_bug.cgi?id=1022) for a better error
message.

Any ideas?

Greetings
Marc



I dont' see Fedora ever shipping that patch, so AFAICT they should have 
the same bug still.



--
t

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[Diederik de Haas]

On Thursday, 3 February 2022 18:04:45 CET jim_p wrote:
> However, cpupower in debian does not come with a systemd service and it does
> not have /etc/default/cpupower so as to set a desired governor.
> I really need such functionality, because as I have said, I set my governor
> to powersave from May to September every year and now I have no way to.

Yes you can. You can create your own 'boot-up script' or make your own systemd 
unit file and enable that.

# cpupower frequency-info
This tells you the frequencies/governor available and currently selected. The 
governor is likely 'schedutil'.
In the 'available cpufreq governors' you probably don't see 'powersave', but 
you can modprobe that with `modprobe cpufreq-powersave` and after that lsmod 
should tell you it's loaded and `cpupower frequency-info` will now also list 
it as an available governor.

# cpupower frequency-set --governor powersave
This will switch the governor to 'powersave'

So if you put the following lines in the 'Service' section of a systemd unit 
file and install/enable it, you should have the functionality that you want.
You'll have to figure out the rest of the fields yourself, but that shouldn't 
be 
too hard as there are plenty .service files on your system and the internet.

ExecStart=/sbin/modprobe  cpufreq-powersave
ExecStart=/usr/bin/cpupower frequency-set --governor powersave

HTH,
  Diederik

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

Bug#1004925: inkscape: Wrong and inconsistent linespacing (AppImage and Snap OK)

[Anthony Fok]

Package: inkscape
Version: 1.1.1-3
Severity: normal
X-Debbugs-Cc: f...@debian.org

Hi!

As reported on Reddit:

https://www.reddit.com/r/Inkscape/comments/rkjktp/for_come_reason_my_line_spacing_is_inconsistent/

The linespacing after the 1st line "seems" OK (but actually too large),
but linespacing in subsequent lines are even larger.

I am running into the same issue with Debian Inkscape .deb package.

When I open the same file (with multiline text objects) with:

 * AppImage (Inkscape-3bf5ae0-x86_64.AppImage, i.e. 1.1.1)
 * Windows (same version, 1.1.1, 3bf5ae0d25, 2021-09-20)
 * Snap (1.1.1-26b7af14f2-2022-01-19)

the linespacing is actually correct and consistent across all lines.

So, I just come to the realization that an Inkscape file that seems to
look OK when open with Debian's Inkscape would actually look wrong
everywhere else.  I was lucky that a recent file that I sent for
CNC routing purposes, I had the text objects converted to paths first

Many thanks for looking into this!

Anthony

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, 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)
LSM: AppArmor: enabled

Versions of packages inkscape depends on:
ii  lib2geom1.1.0  1.1-2+b1
ii  libatkmm-1.6-1v5   2.28.2-1
ii  libboost-filesystem1.74.0  1.74.0-14
ii  libc6  2.33-5
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libdbus-glib-1-2   0.112-2
ii  libfontconfig1 2.13.1-4.3
ii  libfreetype6   2.11.1+dfsg-1
ii  libgc1 1:8.0.6-1.1
ii  libgcc-s1  11.2.0-14
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.3-1
ii  libglibmm-2.4-1v5  2.66.2-2+b1
ii  libgomp1   11.2.0-14
ii  libgsl27   2.7.1+dfsg-3
ii  libgspell-1-2  1.9.1-2
ii  libgtk-3-0 3.24.31-1
ii  libgtkmm-3.0-1v5   3.24.5-1
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.1.2-1
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3
ii  libpango-1.0-0 1.50.3+ds1-4
ii  libpangocairo-1.0-01.50.3+ds1-4
ii  libpangoft2-1.0-0  1.50.3+ds1-4
ii  libpangomm-1.4-1v5 2.46.1-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler102  20.09.0-3.1
ii  libpotrace01.16-2
ii  libreadline8   8.1.2-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.52.5+dfsg-3+b1
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.74.2-3
ii  libstdc++6 11.2.0-14
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.2-2+b1
ii  libxml22.9.12+dfsg-5+b1
ii  libxslt1.1 1.1.34-4
ii  python33.9.8-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4
ii  fig2dev  1:3.2.8b-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.8.4-17+b1
ii  python3-lxml 4.7.1-1
ii  python3-numpy1:1.21.5-1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
ii  pstoedit  3.78-1
pn  python3-uniconvertor  
ii  ruby  1:2.7.6

-- no debconf information

Bug#1004888: inn2: libinn2-dev ships list.3, conflicting with man-pages

[наб]

Hi!

On Thu, Feb 03, 2022 at 08:04:49AM +, Julien ÉLIE wrote:
> > As of now, libinn2-dev ships list.3 with an inn2-specific list
> > implementation. However, Linux man-pages ships list.3 that documents
> > sys/queue.h, a popular, if obscure, double-linked list implementation
> > available on all modern BSDs.
> >
> > See patch below, which just re-names the file to list-inn2.3
> 
> This is a good point.  I think we should  thenhomogenize the name
> of all our library man pages.
> As the routines described in list(3) are built in libinn(3), I suggest
> prefixing all of them with "libinn_".  This way we would have:
> libinn_clientlib(3)
> libinn_dbz(3)
> libinn_inndcomm(3)
> libinn_list(3)
> libinn_qio(3)
> libinn_tst(3)
> libinn_uwildmat(3)

The consistency here is much nicer than my minimum-viable solution,
yeah :)

> along with untouched:
> libinn(3)
> libauth(3)
> libinnhist(3)
> libstorage(3)
> 
> Though maybe we should also rename libauth(3) and libstorage(3)
> man pages to libinnauth(3) and libinnstorage(3)?
> And of course also generate libinnauth.so and libinnstorage.so
> instead of libauth.so and libstorage.so, to be consistent.

That's less of an issue since these don't conflict with anything,
but if you've already got an ABI break coming then it'd be much nicer
from a namespacing/usage perspective, agreed.

> If that looks OK, prefixing with "libinn_" could be done in the
> upcoming INN 2.6.5 release (in a few days/weeks),

In that case, the next release of man-pages should (semi-, there's a
script that picks up the file list from sid, but the maintainer doesn't
seem to always run it? but they will this time to close #951598)
automatically include list.3.

Thanks,
наб


signature.asc
Description: PGP signature

Bug#1004885: intel-compute-runtime: switch to llvm-toolchain-13

[Andreas Beckmann]

On 02/02/2022 22.51, Sebastian Ramacher wrote:

Source: intel-compute-runtime
Version: 21.32.20609-1



The current default version of llvm is llvm-toolchain-13. To reduce the
number of llvm versions, please consider switchting to llvm-toolchain-13
(or the unversioned counterpart).


This is theoretically easy to fix: we don't need any llvm 
build-dependency (or most of the other B-D) at all.


Unfortunately, I'm currently only able to build intel-compute-runtime 
(either this or the latest upstream version) with 
intel-graphics-compiler built with llvm-11. With some patching/disabling 
of tests it should be possible to use intel-graphics-compiler built with 
llvm-12.


Andreas

Bug#1004883: intel-graphics-compiler: switch to llvm-toolchain-13

[Andreas Beckmann]

Control: forwarded -1 
https://github.com/intel/intel-graphics-compiler/issues/227


On 02/02/2022 22.43, Sebastian Ramacher wrote:

Source: intel-graphics-compiler
Version: 1.0.8744-2



The current default version of llvm is llvm-toolchain-13. To reduce the
number of llvm versions, please consider switchting to llvm-toolchain-13
(or the unversioned counterpart).


Switching to llvm-13 seems to be easy, at least after upgrading to the 
latest upstream release. It builds. Unfortunately building 
intel-compute-runtime against intel-graphics-compiler built with llvm-13 
causes errors:

https://github.com/intel/intel-graphics-compiler/issues/227
while the same works fine if built against llvm-11 (and maybe llvm-12 
with some patching).


Upstream Status:

LLVM 11 Support: Production
https://github.com/intel/intel-graphics-compiler/projects/1

LLVM 12 Support: Beta
https://github.com/intel/intel-graphics-compiler/projects/2

LLVM 13 Support: Experimental
https://github.com/intel/intel-graphics-compiler/projects/3

So for now using llvm-11 to build intel-graphics-compiler seems to be 
the best solution to get intel-compute-runtime working again.


In order to build intel-graphics-compiler against llvm-11 we would need 
to reintroduce spirv-llvm-translator and intel-opencl-clang built 
against llvm-11. These are tightly coupled to the llvm version being 
used and will change the soname accordingly. I would therefore 
reintroduce them as new source packages with '-11' appended.

Would adding two more source packages depending on llvm-11 be OK?
That's the only solution I see for making intel-compute-runtime 
buildable again on a short time frame.



Andreas

PS: The insane setup that we currently have: building 
intel-graphics-compiler with llvm-12 or llvm-11 while using 
intel-opencl-clang built with llvm-13 does not work. And nobody is going 
to debug that.

Bug#1004920: HTTP apt requests to ftp.uk.debian.org now redirecting to HTTPS when requested via 127.0.0.1 forward

[Julian Andres Klode]

(not the mirror operator, they might fix this, but
 here's an explanation)

On Thu, Feb 03, 2022 at 04:51:44PM +, Matthew Jones wrote:
> Package: mirrors
> We have an ssh tunnel forwarding traffic via a Debian Stretch server to 
> ftp.uk.debian.org. This is because the requesting 
> client (also Debian Stretch) only has outbound ssh access (no other ports 
> open). The tunnel is as follows:
> ssh client@server -L 127.0.0.1:2081:ftp.uk.debian.org:80
> And we then have the following line amongst others in the apt sources list:
> deb http://127.0.0.1:2081/debian/ stretch main contrib non-free
> For a few years now, whenever we run apt-get update, it works.

See, each HTTP request includes a Host: header line telling the
server which host you accessed.

If you talk to http://ftp.uk.debian.org/ it does something like

GET /debian/dists/stretch/InRelease HTTP/1.1
Host: ftp.uk.debian.org

With your tunnel, you tell the server you want to access the host
127.0.0.1 instead:

GET /debian/dists/stretch/InRelease HTTP/1.1
Host: 127.0.0.1

This is fine as long as the virtual host for 127.0.0.1 is the same
as the one for ftp.uk.debian.org, which seemingly was the case, but
no longer is.

If you want to resolve this properly, I suggest you deploy a squid
cache on the "server" that allows requests to ftp.uk.debian.org,
and then configure that as a proxy in apt, with ftp.uk.debian.org
sources.list.

Alternatively, you can configure all clients to have in their /etc/hosts
an entry of the form

127.0.0.1   ftp.uk.debian.org

and then use ftp.uk.debian.org.

Either approach will ensure the server sees the correct hostname.

I contemplated adding support for this to APT once, such that you could
have written http://ftp.uk.debian.org[127.0.0.1]:2081/ but haven't moved
on it.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1004924: xkb: Alt key ceased working after last update

[Carlos]

Package: xkb
Severity: normal
X-Debbugs-Cc: cplo...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
updating packages with apt
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
press key combinations that involve Alt keys. For example: Alt + . used 
to produce a middle dot, and I have a shortcut defined with Super+Alt+T, which 
opens thunderbird. The most simple possible test I could imagine was opening 
xev, and pressing different keys. The only one I could find not working are Alt 
keys (no events are produced).
   * What was the outcome of this action?
No keypress events are produced with the alt keys
   * What outcome did you expect instead?
Keypress events should be produced when pressing Alt keys.


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

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

Bug#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Vincent Lefevre]

On 2022-02-03 17:30:28 +0100, Marc Haber wrote:
> Do you see this TLS error with other remotes?

No, but the machine only has 11 days of logs, while I don't use it
much in these times. So that's almost nothing.

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

Bug#1004909: Bug#1004905: sudo: FTBFS on non-linux architectures

[Laurent Bigonville]

Le 3/02/22 à 17:39, Marc Haber a écrit :

On Thu, Feb 03, 2022 at 11:39:37AM +0100, Laurent Bigonville wrote:

On kfreebsd, the attached patch fixes the compilation (that should
probably be reported upstream), but it still fails in the tests

Can you please try the following upstream patch instead and report back?

https://www.sudo.ws/repos/sudo/rev/10775e14164a

I can confirm that the patch fix the compilation indeed (no the tests)

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@outlook.com

Preface: In case I did not mention it above, I had a suspicion that the issue
might be related to cpu frequency scaling.

1+ month has passed with 5.15. The blank screen issue appeared a few more times
the following days. A couple of days later, I decided to disable cpufrequtils,
which set my frequency scheduler to schedutil (from ondemand). And the issue
has not happened since then!

Then I checked debian wiki, which says that cpufrequtils is replaced in favor
of cpupower, so I removed it completely and installed cpupower (linux-cpupower
package).
However, cpupower in debian does not come with a systemd service and it does
not have /etc/default/cpupower so as to set a desired governor.
I really need such functionality, because as I have said, I set my governor to
powersave from May to September every year and now I have no way to.


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

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

Bug#1004923: autopkgtest failure due to removed libRemoteIndex*.a

[Sergio Durigan Junior]

Source: llvm-toolchain-12
Version: 1:12.0.1-19
Severity: serious

Hi,

The following commit:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/87ee3c332f9b0736064a588bdf974bbda0288d58

is causing an autopkgtest failure because the build system still
requires the libraries libRemoteIndex{ServiceProto,Proto}.a to exist
when running the command1 unittest, as can be seen in the logs:

--8<---cut here---start->8---
# "Test: CMake find LLVM and Clang in default path"
(cd cmaketest/standard && CC=clang-$VERSION CXX=clang++-$VERSION cmake .. > 
/dev/null)
CMake Error at /usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake:720 
(message):
  The imported target "RemoteIndexProto" references the file

 "/usr/lib/llvm-12/lib/libRemoteIndexProto.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/cmake/clang-12/ClangConfig.cmake:20 (include)
  CMakeLists.txt:9 (find_package)


autopkgtest [16:06:06]: test command1: ---]
autopkgtest [16:06:06]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
--8<---cut here---end--->8---

I don't know the details regarding why these libraries are being removed
(according to the comment on d/rules, it's just because they're unused),
so maybe the solution here is to just revert the change.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1004922: RFS: kmscon/8+40-1 [ITP] -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "kmscon":

 * Package name: kmscon
   Version : 8+40-1
   Upstream Author : https://github.com/Aetf/kmscon/issues
 * URL : https://github.com/Aetf/kmscon
 * License : LGPL-2.1+, Expat, HPND-Kuhn, GPL-2 with Font exception, 
Expat and HPND, public-domain
 * Vcs : https://salsa.debian.org/viccie30/kmscon
   Section : utils

It builds those binary packages:

  kmscon - Simple terminal emulator based on Kernel Mode Setting

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/kmscon/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/k/kmscon/kmscon_8+40-1.dsc

Changes for the initial release:

 kmscon (8+40-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1004919)

Regards,
-- 
  Victor Westerhuis

Bug#1004921: libtsm: Package too old for kmscon

[Victor Westerhuis]

Source: libtsm
Version: 3-1
Severity: wishlist
Tags: patch
Control: block 1004919 by -1

I've just opened an ITP bug for kmscon, #1004919. This package
depends on libtsm version 4.0.0 or greater.

Upstream development has long stopped on libtsm and kmscon depends
on a fork by the same author at https://github.com/Aetf/libtsm.

I have prepared packaging for version 4.0.1 from the fork at
https://salsa.debian.org/viccie30/libtsm. You are welcome to use
that, but I'm also willing to take over maintenance if you want.

It looks like there are no reverse dependencies on the current
versions of libtsm3 and libtsm-dev, so the upgrade should create
no problems.


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1004888: inn2: libinn2-dev ships list.3, conflicting with man-pages

[Russ Allbery]

Julien ÉLIE  writes:

> This is a good point.  I think we should  thenhomogenize the name
> of all our library man pages.
> As the routines described in list(3) are built in libinn(3), I suggest
> prefixing all of them with "libinn_".  This way we would have:
> libinn_clientlib(3)
> libinn_dbz(3)
> libinn_inndcomm(3)
> libinn_list(3)
> libinn_qio(3)
> libinn_tst(3)
> libinn_uwildmat(3)

> along with untouched:
> libinn(3)
> libauth(3)
> libinnhist(3)
> libstorage(3)

Yes, I agree.  There's really no reason for us to consume so much
namespace.

> Though maybe we should also rename libauth(3) and libstorage(3)
> man pages to libinnauth(3) and libinnstorage(3)?
> And of course also generate libinnauth.so and libinnstorage.so
> instead of libauth.so and libstorage.so, to be consistent.

This is more intrusive but I think this is also a good idea.  We used
libinnhist for the name of the history library from the start and I think
that was wiser.

-- 
Russ Allbery (r...@debian.org)  

Bug#1004920: HTTP apt requests to ftp.uk.debian.org now redirecting to HTTPS when requested via 127.0.0.1 forward

[Matthew Jones]

Package: mirrors
We have an ssh tunnel forwarding traffic via a Debian Stretch server to 
ftp.uk.debian.org. This is because the requesting 
client (also Debian Stretch) only has outbound ssh access (no other ports 
open). The tunnel is as follows:
ssh client@server -L 127.0.0.1:2081:ftp.uk.debian.org:80
And we then have the following line amongst others in the apt sources list:
deb http://127.0.0.1:2081/debian/ stretch main contrib non-free
For a few years now, whenever we run apt-get update, it works. But today it 
seems the above address is being redirected to HTTPS, e.g.:
Answer for: 
http://127.0.0.1:2081/debian/dists/stretch-backports/contrib/Contents-armhf.lzma
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.18.0
Date: Thu, 27 Jan 2022 16:25:20 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: 
https://127.0.0.1/debian/dists/stretch-backports/contrib/Contents-armhf.lzma
Also, the port specified in the initial request doesn’t appear to be honoured, 
according to the last line above.
We then get:
Err:5 https://127.0.0.1/debian stretch/main armhf Packages
server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none

If we change the ssh port forward to instead use 
ftp.de.debian.org, it works fine, just as the UK 
version used to, with no 302 redirect (different package extracted from earlier 
logs, but otherwise comparable):
Answer for: 
http://127.0.0.1:2081/debian/dists/stretch-backports/non-free/i18n/by-hash/SHA256/ecdde85fe38ffd2be1ba30e194d7e380cd5d18a0ae21c994bda09a4246ccaacb
HTTP/1.1 200 OK
Date: Thu, 27 Jan 2022 16:35:23 GMT
Server: Apache/2.4.25 (Debian)
Last-Modified: Mon, 13 Jul 2020 13:57:07 GMT
ETag: "9676-5aa5310fc3ad2"
Accept-Ranges: bytes
Content-Length: 38518
More interestingly, if I temporarily make it so that the client has HTTP 
access, and point apt directly at “deb http://ftp.uk.debian.org/debian/ stretch 
main contrib non-free”, then it works fine over HTTP as before, so it’s not an 
indiscriminately applied redirect. It’s as though the Nginx instance at the 
other end is now behaving differently depending on request hostname or perhaps 
port number.
I should add that there’s nothing in the chain that isn’t apparent from the ssh 
options “-L 127.0.0.1:2081:ftp.uk.debian.org:80”, it’s just a simple forward to 
the outside world.
We have a lot of kit in the field with this symptom, and would be nice to know 
if this can/will be fixed so that we can act accordingly.
I am using apt 1.4.6 (armhf) on Debian GNU/Linux 9

Regards,

[cid:image716390.png@3185E099.A4D73DB5]
MATTHEW JONES​
CLOUD SOLUTIONS ARCHITECT
RAMTECHGLOBAL.COM
SOCIAL MEDIA LINKEDIN 
 | YOUTUBE 
 | 
TWITTER
EMAIL matthew.jo...@ramtechglobal.com
OFFICE +44 (0)115 957 8282
This email has been sent by and on behalf of one or more of Ramtech Electronics 
Limited, Ramtech Overseas Limited, Ramtech North America Inc or Ashton Lister 
Investments Limited, (together, ‘Ramtech’). This e-mail, including attachments, 
is private and may be confidential and is for the intended recipient only. If 
you are not the intended addressee, please notify us by telephone (+44 (0)115 
957 8282) or by email (priv...@ramtechglobal.com) and confirm that it has been 
deleted from your system and any copies destroyed. If you are not the intended 
recipient you are strictly prohibited from using, printing, copying, 
distributing or disseminating this e-mail or any information contained in it. 
Ramtech use reasonable endeavours to virus scan all e-mails leaving the firms 
but no warranty is given that this e-mail and any attachments are virus free. 
You should undertake your own virus checking. The right to monitor e-mail 
communications through our networks is reserved by us. Each of Ramtech 
Electronics Limited (registered no. 02538255), Ramtech Overseas Limited 
(registered no. 10162495) and Ashton Lister Investments Limited (registered no. 
05617735) are companies registered in England and Wales and whose registered 
office is at: Ramtech House, Castlebridge Office Village, Castle Marina Rd, 
Nottingham NG7 1TN. Ramtech North America Inc principle place of business is 
5126 South Royal Atlanta Dr. Tucker, GA 30084, USA. To understand how we 
respect and protect your personal data, please see our privacy statement at 
https://ramtechglobal.com/privacy-statement

Bug#962300: allow udevadm to fail

[GCS]

Hi Johannes,

On Thu, Feb 3, 2022 at 12:41 PM Johannes Schauer Marin Rodrigues
 wrote:
> this bug is currently preventing the creation of unprivileged system chroots.
> If you don't have any objections, I can NMU dmraid for you with the patch from
> my last mail.
>
> What do you think?
 Thanks for the heads-up. Going to upload it, crediting you of course.

Thanks,
Laszlo/GCS

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

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

* Package name: kmscon
  Version : 8+40
  Upstream Author : Aetf 
* URL : https://github.com/Aetf/kmscon
* License : Expat
  Programming Lang: C
  Description : Simple terminal emulator based on Kernel Mode Setting

kmscon is a system console for linux. It does not depend on any
graphics-server on your system (like X.org), but instead provides
a raw console layer that can  be used independently.
It can replace the linux kernel console entirely but was designed to
work well side-by-side, too.
Even though initially targeted at providing internationalization to
the system-console, it has grown into a fully modularized console
layer including features like multi-head support, internationalized
font rendering, XKB-compatible keyboard handling,
hardware-accelerated graphics access and more.

I have used this package since Linux dropped scrollback support
from the kernel in 2020 [1]. The original upstream [2] has been
dead since 2014, but Aetf has picked up development.

Kmscon depends on a newer, forked version of libtsm. I'll file
a separate bug to address that.

[1]: 
https://www.phoronix.com/scan.php?page=news_item=Linux-5.9-Drops-Soft-Scrollback
[2]: https://www.freedesktop.org/wiki/Software/kmscon/

Bug#1004909: Bug#1004905: sudo: FTBFS on non-linux architectures

[Marc Haber]

On Thu, Feb 03, 2022 at 11:39:37AM +0100, Laurent Bigonville wrote:
> On kfreebsd, the attached patch fixes the compilation (that should
> probably be reported upstream), but it still fails in the tests

Can you please try the following upstream patch instead and report back?

https://www.sudo.ws/repos/sudo/rev/10775e14164a

Greetings
Marc

Bug#1001583: fish: Version info is empty

[Wolodja Wentland]

Package: fish
Version: 3.3.1+ds-2
Followup-For: Bug #1001583
X-Debbugs-Cc: deb...@babilen5.org

Hello,

I am seeing the following behaviour when using fzf-history-widget:

--- snip ---
Argument is not a number: ''
Standard input (line 64): 
  if [ "$FISH_MAJOR" -gt 2 -o \( "$FISH_MAJOR" -eq 2 -a "$FISH_MINOR" -ge 4 
\) ];

in function 'fzf-history-widget'
--- snip ---

which is a direct effect of fish not providing its version information
correctly.

Ultimately, the following code is broken in fzf:

--- snip ---
set -l FISH_MAJOR (echo $version | cut -f1 -d.)
set -l FISH_MINOR (echo $version | cut -f2 -d.)
if [ "$FISH_MAJOR" -gt 2 -o \( "$FISH_MAJOR" -eq 2 -a "$FISH_MINOR" -ge 4 \) ];
  ...
--- snip ---

It would be fantastic if this issue could be addressed as it also
breaks other packages.

Thank you,
Wolodja

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
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 fish depends on:
ii  bsdextrautils   2.37.3-1+b1
ii  firefox [www-browser]   96.0.3-1
ii  fish-common 3.3.1+ds-2
ii  google-chrome-stable [www-browser]  98.0.4758.80-1
ii  groff-base  1.22.4-8
ii  libc6   2.33-5
ii  libpcre2-32-0   10.39-3
ii  libstdc++6  11.2.0-14
ii  libtinfo6   6.3-2
ii  lynx [www-browser]  2.9.0dev.10-1
ii  man-db  2.9.4-4
ii  python3 3.9.7-1
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#801822: deb-systemd-helper does not support template units (e.g. foo@.service)

[Victor Westerhuis]

Package: init-system-helpers
Version: 1.61
Followup-For: Bug #801822
Control: tags -1 patch

I've opened a merge request on Salsa with another possible fix.
It works for me locally, but I would like any feedback if I made a mistake 
somewhere.

I've attached the patch as an attachment and the MR is at 
https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/20.


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii  perl-base  5.32.1-6

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
pn  insserv  

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/sbin/update-rc.d (from init-system-helpers package)
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 7e929ed..c27e5da 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -192,8 +192,11 @@ sub get_link_closure {
 my ($scriptname, $service_path) = @_;
 
 my @links;
+my @wants_dirs;
 
 my $unit_name = basename($service_path);
+my $template = $unit_name =~ /\@\.\w+$/;
+my $default_instance = $unit_name unless $template;
 
 # The keys parsed from the unit file below can only have unit names
 # as values. Since unit names can't have whitespace in systemd,
@@ -210,7 +213,7 @@ sub get_link_closure {
 my $wants_dir = "/etc/systemd/$instance/$value";
 $wants_dir .= '.wants' if $1 eq 'WantedBy';
 $wants_dir .= '.requires' if $1 eq 'RequiredBy';
-push @links, { dest => $service_path, src => 
"$wants_dir/$scriptname" };
+push @wants_dirs, "$wants_dir/";
 }
 }
 
@@ -231,9 +234,20 @@ sub get_link_closure {
 }
 }
 }
+
+if ($template && $line =~ 
/^\s*DefaultInstance=\s*(["']?+)(.+)\g1\s*$/i) {
+$default_instance = $2;
+$default_instance = $unit_name =~ 
s/^(.*\@)(\.\w+)$/$1$default_instance$2/r;
+}
 }
 close($fh);
 
+if ($default_instance) {
+for my $wants_dir (@wants_dirs) {
+push @links, { dest => $service_path, src => $wants_dir . 
$default_instance };
+}
+}
+
 return @links;
 }
 

Bug#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Marc Haber]

On Thu, Feb 03, 2022 at 02:51:10PM +0100, Vincent Lefevre wrote:
> On 2022-02-03 14:21:58 +0100, Marc Haber wrote:
> > Is the bug repeatable by unfreezing the message and forcing a delivery
> > attempt? If so, you might be able to get a core dump from the delivering
> > exim.
> 
> The delivery was successful. There was still a "TLS error on
> connection (recv): The TLS connection was non-properly terminated."
> error, but no 450:
> 
> 2022-02-02 13:42:28 Start queue run: pid=150965 -qff
> 2022-02-02 13:42:28 1nEt2b-0008jG-97 Unfrozen by forced delivery
> 2022-02-02 13:42:31 1nEt2b-0008jG-97 H=mx1.mailchannels.net [54.189.39.249] 
> TLS error on connection (recv): The TLS connection was non-properly 
> terminated.

Just for the protocol: gnutls-cli --insecure -s -p 25 54.189.39.249
allows me to simulate an EHLO/STARTTLS/EHLO/QUIT session that gets
properly terminated. Andreas as GnuTLS maintainer might make more sense
from that finding.

> 2022-02-02 13:42:31 1nEt2b-0008jG-97 => xxx@yyy R=dnslookup T=remote_smtp 
> H=mx1.mailchannels.net [54.189.39.249] 
> X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes 
> DN="CN=*.mailchannels.net" C="250 2.0.0 Ok: queued as 6D9D5201EF"
> 2022-02-02 13:42:31 1nEt2b-0008jG-97 Completed
> 2022-02-02 13:42:31 End queue run: pid=150965 -qff

That doesn't help though, we neeed the error to happen ;-)

Do you see this TLS error with other remotes?

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#793660: Is still an issue

[Marc Haber]

Control: tags -1 - moreinfo + confirmed
thanks

On Thu, Feb 03, 2022 at 02:54:24PM +0100, Marc Haber wrote:
> On Wed, Feb 02, 2022 at 07:55:07PM +0100, Borden wrote:
> > Just reinstalled again, ran a sudo command and got
> > 
> > debian: Feb  2 18:47:09 : borden : problem with defaults entries ; 
> > TTY=pts/1 ; PWD=/home/borden ; USER=root ;
> > 
> > Delivered to my inbox. I'm not sure if that's a bug problem or a me problem
> 
> I have never seen such a message delivered via e-mail. Is this a strange
> syslog configuration, or a container setup? Normally, message like this
> end up in auth.log.

Ok, I now understand what you mean, and I can reproduce the issue.
Excuse me for being so stupid.

The linked Red Hat bugreport was help for me
(https://bugzilla.redhat.com/show_bug.cgi?id=879633). You don't need an
LDAP server, you don't need sssd running, it is just necessary to
install sudo and libsss-sudo and have "sudoers: files sss" in
nssswithc.conf.

Any sudo call will result in a single e-mail message like this being sent
out:
| From: Marc Haber 
| Subject: *** SECURITY information for testsid85.zugschlus.de ***
| To: r...@testsid85.zugschlus.de
| Date: Thu, 03 Feb 2022 16:54:27 +0100
| 
| testsid85.zugschlus.de : Feb  3 16:54:26 : mh : problem with defaults entries 
; TTY=pts/0 ; PWD=/home/mh ; USER=root ;

The Red Hat Bug Report links to a patch,
https://bugzilla-attachments.redhat.com/attachment.cgi?id=650460, but I am
not sure whether this patch makes sense (it only seems to turn off the error
exit code in case of sss_error == ENOENT). @Timo, is that a valid solution?

I am also bothered by the error text "problem with defaults entries". I
have filed upstream bug 1022
(https://bugzilla.sudo.ws/show_bug.cgi?id=1022) for a better error
message.

Any ideas?

Greetings
Marc

Bug#961834: Any updates?

[Zbynek Michl]

Hello,

is reported issue still valid? I use this theme in Debian Bookworm (Xfce
4.16) and I can't see any trouble with it.

I would appreciate returning the package to the repo if there is no real
blocker anymore.

Thank you
Zbynek

Bug#1001070: command-not-found: confirmation

[Julian Andres Klode]

On Thu, Feb 03, 2022 at 05:02:10PM +0100, wim wrote:
> Package: command-not-found
> Version: 20.10.1-1
> Followup-For: Bug #1001070
> X-Debbugs-Cc: wim.bert...@ucll.be
> 
> Hello,
> 
> a confirmation of this bug

I understand it's broken, I fixed it upstream, but haven't gotten around
to merging it back into Debian (I also merged most Debian changes
upstream).

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1001070: command-not-found: confirmation

[wim]

Package: command-not-found
Version: 20.10.1-1
Followup-For: Bug #1001070
X-Debbugs-Cc: wim.bert...@ucll.be

Hello,

a confirmation of this bug

hth,
Wim

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

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

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:
ii  snapd  2.49-1+b5

-- no debconf information

Bug#1004825: hedgewars: FTBFS with ffmpeg 5.0

[Gianfranco Costamagna]

Hello,

I probably crafted a patch, but my ffmpeg knowledge is zero, so help is 
appreciated

Attached the patch.

G.


On Tue, 1 Feb 2022 23:38:47 +0100 Sebastian Ramacher  
wrote:

Source: hedgewars
Version: 1.0.0-14
Severity: important
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm ftbfs
Usertags: ffmpeg5.0

hedgewars FTBFS with ffmpeg 5.0 in experimental:

[  6%] Generating hedgewars_it.qm
cd /<>/obj-x86_64-linux-gnu/share/hedgewars/Data/Locale && /usr/lib/qt5/bin/lrelease 
/<>/share/hedgewars/Data/Locale/hedgewars_it.ts -qm 
/<>/obj-x86_64-linux-gnu/share/hedgewars/Data/Locale/hedgewars_it.qm
Updating 
'/<>/obj-x86_64-linux-gnu/share/hedgewars/Data/Locale/hedgewars_gl.qm'...
Generated 223 translation(s) (177 finished and 46 unfinished)
Ignored 910 untranslated source text(s)
Updating 
'/<>/obj-x86_64-linux-gnu/share/hedgewars/Data/Locale/hedgewars_hu.qm'...
Generated 1181 translation(s) (1181 finished and 0 unfinished)
Updating 
'/<>/obj-x86_64-linux-gnu/share/hedgewars/Data/Locale/hedgewars_it.qm'...
Generated 1133 translation(s) (1133 finished and 0 unfinished)
/<>/hedgewars/avwrapper/avwrapper.c: In function ‘AddAudioStream’:
/<>/hedgewars/avwrapper/avwrapper.c:174:26: error: ‘AVStream’ has 
no member named ‘codec’
  174 | g_pAudio = g_pAStream->codec;
  |  ^~
/<>/hedgewars/avwrapper/avwrapper.c:176:5: warning: implicit 
declaration of function ‘avcodec_get_context_defaults3’ [-Wimplicit-function-declaration]
  176 | avcodec_get_context_defaults3(g_pAudio, g_pACodec);
  | ^
/<>/hedgewars/avwrapper/avwrapper.c: In function ‘WriteAudioFrame’:
/<>/hedgewars/avwrapper/avwrapper.c:230:5: warning: 
‘av_init_packet’ is deprecated [-Wdeprecated-declarations]
  230 | av_init_packet();
  | ^~
In file included from /usr/include/x86_64-linux-gnu/libavcodec/avcodec.h:45,
 from /<>/hedgewars/avwrapper/avwrapper.c:25:
/usr/include/x86_64-linux-gnu/libavcodec/packet.h:506:6: note: declared here
  506 | void av_init_packet(AVPacket *pkt);
  |  ^~
/<>/hedgewars/avwrapper/avwrapper.c:247:9: warning: implicit 
declaration of function ‘avcodec_encode_audio2’; did you mean ‘avcodec_encode_subtitle’? 
[-Wimplicit-function-declaration]
  247 | if (avcodec_encode_audio2(g_pAudio, , pFrame, _packet) 
!= 0)
  | ^
  | avcodec_encode_subtitle
/<>/hedgewars/avwrapper/avwrapper.c: In function ‘AddVideoStream’:
/<>/hedgewars/avwrapper/avwrapper.c:282:26: error: ‘AVStream’ has 
no member named ‘codec’
  282 | g_pVideo = g_pVStream->codec;
  |  ^~
/<>/hedgewars/avwrapper/avwrapper.c: In function ‘WriteFrame’:
/<>/hedgewars/avwrapper/avwrapper.c:384:5: warning: 
‘av_init_packet’ is deprecated [-Wdeprecated-declarations]
  384 | av_init_packet();
  | ^~
In file included from /usr/include/x86_64-linux-gnu/libavcodec/avcodec.h:45,
 from /<>/hedgewars/avwrapper/avwrapper.c:25:
/usr/include/x86_64-linux-gnu/libavcodec/packet.h:506:6: note: declared here
  506 | void av_init_packet(AVPacket *pkt);
  |  ^~
/<>/hedgewars/avwrapper/avwrapper.c:408:13: warning: implicit 
declaration of function ‘avcodec_encode_video2’; did you mean ‘avcodec_encode_subtitle’? 
[-Wimplicit-function-declaration]
  408 | if (avcodec_encode_video2(g_pVideo, , pFrame, _packet) 
< 0)
  | ^
  | avcodec_encode_subtitle
/<>/hedgewars/avwrapper/avwrapper.c: In function ‘AVWrapper_Init’:
/<>/hedgewars/avwrapper/avwrapper.c:503:5: warning: implicit 
declaration of function ‘av_register_all’ [-Wimplicit-function-declaration]
  503 | av_register_all();
  | ^~~
/<>/hedgewars/avwrapper/avwrapper.c:506:15: warning: assignment 
discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]Description: Add compatibility with new ffmpeg 5.0, based on patch available here:
https://github.com/opencv/opencv/issues/21455

Author: Gianfranco Costamagna 
Origin: other
Bug-Debian: https://bugs.debian.org/1004825
Forwarded: irc
Last-Update: 2022-02-03

Index: hedgewars/hedgewars/avwrapper/avwrapper.c
===
--- hedgewars.orig/hedgewars/avwrapper/avwrapper.c
+++ hedgewars/hedgewars/avwrapper/avwrapper.c
@@ -27,6 +27,10 @@
 #include "libavutil/avutil.h"
 #include "libavutil/mathematics.h"
 
+#if LIBAVCODEC_VERSION_MAJOR >= 59
+#include 
+#endif
+
 #if (defined _MSC_VER)
 #define AVWRAP_DECL __declspec(dllexport)
 #elif ((__GNUC__ >= 3) && (!__EMX__) && (!sun))
@@ -171,7 +175,13 @@
 }
 g_pAStream->id = 1;
 
+#if LIBAVCODEC_VERSION_MAJOR < 59
 g_pAudio = g_pAStream->codec;
+#else
+const AVCodec *audio_st_codec = avcodec_find_decoder(g_pAStream->codecpar->codec_id);
+g_pAudio = avcodec_alloc_context3(audio_st_codec);
+

Bug#1004915: transition: ruby2.7-rm

[Lucas Kanashiro]

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

Hi,

We would like to add ruby3.0 as the default and remove ruby2.7 support.

Ben file:

title = "ruby2.7-rm";
is_affected = (.depends ~ /ruby2.7/ | .depends ~ /ruby3.0/) & !.source ~ 
/^(ruby2.7|ruby3.0|ruby-defaults)$/;
is_good = ! .depends ~ /ruby2.7/;
is_bad = .depends ~ /ruby2.7/;


This part of the transition was already done in Ubuntu, so I do not expect
any blocker, this is the transition tracker page there:

https://people.canonical.com/~ubuntu-archive/transitions/html/ruby2.7-rm.html

ruby-defaults/1:3.0~exp1 is already in experimental (which makes ruby3.0 the
default and remove ruby2.7), I'll be waiting for your acknowledgement to
upload it to unstable.

--
Lucas Kanashiro

Bug#1004918: ITP:php-slack - PHP package for Slack

[Katharina Drexel]

Package: php-slack

* Package name: php-slack
  Upstream Author : Alexander Chibrikin 
* License : BSD-2-clause
  Description : PHP package for Slack
 A simple PHP package for sending messages to Slack with incoming webhooks,
 focused on ease-of-use and elegant syntax.

Regards
Katharina

Bug#1004633: gmerlin-avdecoder: FTBFS with ffmpeg 5.0

[Debian GNU|Linux]

On Sun, 30 Jan 2022 23:04:11 +0100 Sebastian Ramacher 
 wrote:

Source: gmerlin-avdecoder
Version: 1.2.0~dfsg-11
Severity: important
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm ftbfs
Usertags: ffmpeg5.0


urgh.

i have done a quick search, but haven't found any upgrading guide to 
migrate code-bases from ffmpeg4 to ffmpeg5.


am i missing something?

gfamsdf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004917: evolution: Contacts API is deprecated. Migrate to People API to retain programmatic access to Google Contacts

[Martin Tharby Jones]

Package: evolution
Version: 3.38.3-1
Severity: important
X-Debbugs-Cc: mar...@brasskipper.org.uk

Dear Maintainer,

evolution dislays the following error. I believe this is fixed in testing,
please build evolution in bullseye-backports so that the fix is avalible to
those using stable.

Failed to connect address book “mar...@brasskipper.org.uk : Contacts”

Invalid request URI or header, or unsupported nonstandard parameter: Contacts
API is being deprecated. Migrate to People API to retain programmatic access to
Google Contacts. See https://developers.google.com/people/contacts-api-
migration.


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

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

Versions of packages evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-13+deb11u2
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.34.4-1~deb11u1
ii  libxml22.9.10+dfsg-6.7
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2
ii  network-manager 1.30.0-2

Bug#1004916: at: the Debian bug tracker URL should be updated to https

[Vincent Lefevre]

Package: at
Version: 3.2.4-2
Severity: minor

"at -V" and "atq -V" output

[...]
Please report bugs to the Debian bug tracking system (http://bugs.debian.org/)
or contact the maintainers (a...@packages.debian.org).

The URL http://bugs.debian.org/ should be updated to https.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 at depends on:
ii  libc6   2.33-5
ii  libpam-runtime  1.4.0-11
ii  libpam0g1.4.0-11
ii  libselinux1 3.3-1+b1
ii  lsb-base11.1.0

Versions of packages at recommends:
ii  postfix [mail-transport-agent]  3.6.4-1

at suggests no packages.

-- Configuration Files:
/etc/at.deny [Errno 13] Permission denied: '/etc/at.deny'

-- no debconf information

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

Bug#975016: #975016 - OpenJDK 17 support state for Bullseye

[Thorsten Glaser]

Hi Holger,

> and filed against src:debian-security-support, as openjdk-17 seems to be
> supported and src:debian-security-support's purpose is to documented what's

no, 11 is supported, 17 is just for users to run third-party
stuff on (IIUC).

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1004913:

[Andreas Hasenack]

I created a salsa PR at
https://salsa.debian.org/debian/python-fysom/-/merge_requests/2

Bug#1004902: openrct2: FTBFS TTF.cpp:358:32: error: invalid conversion from 'const TTF_Font*' to 'TTF_Font*'

[Mathias Gibbens]

tags 1004902 + pending
thanks

  Thanks for the report! I've fixed the error locally and plan to get a
new version uploaded in the near future.

Mathias

On Thu, 2022-02-03 at 11:13 +0100, Andreas Beckmann wrote:
> Source: openrct2
> Version: 0.3.5.1+ds-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in
> the past)
> 
> Hi,
> 
> openrct2 recently started to FTBFS, probably due to a change in a
> build
> dependency:
> 
> /build/openrct2-0.3.5.1+ds/src/openrct2/drawing/TTF.cpp: In function
> 'bool ttf_provides_glyph(const TTF_Font*, codepoint_t)':
> /build/openrct2-0.3.5.1+ds/src/openrct2/drawing/TTF.cpp:358:32:
> error: invalid conversion from 'const TTF_Font*' to 'TTF_Font*' [-
> fpermissive]
>   358 | return TTF_GlyphIsProvided(font, codepoint);
>   |    ^~~~
>   |    |
>   |    const TTF_Font*
> In file included from /build/openrct2-
> 0.3.5.1+ds/src/openrct2/drawing/../config/../drawing/Font.h:10,
>  from /build/openrct2-
> 0.3.5.1+ds/src/openrct2/drawing/../config/../drawing/Drawing.h:16,
>  from /build/openrct2-
> 0.3.5.1+ds/src/openrct2/drawing/../config/Config.h:13,
>  from /build/openrct2-
> 0.3.5.1+ds/src/openrct2/drawing/TTF.cpp:21:
> /usr/include/SDL2/SDL_ttf.h:184:59: note:   initializing argument 1
> of 'int TTF_GlyphIsProvided(TTF_Font*, Uint16)'
>   184 | extern DECLSPEC int SDLCALL TTF_GlyphIsProvided(TTF_Font
> *font, Uint16 ch);
>   |
> ~~^~~~
> make[3]: *** [CMakeFiles/libopenrct2.dir/build.make:2347:
> CMakeFiles/libopenrct2.dir/src/openrct2/drawing/TTF.cpp.o] Error 1
> 
> 
> I have a successful build from Jan 07, the most "promising" build
> dependency
> change since then seems to be
> 
> -Setting up libsdl2-ttf-2.0-0:amd64 (2.0.15+dfsg1-2) ...^M
> +Setting up libsdl2-ttf-2.0-0:amd64 (2.0.18+dfsg-2) ...^M
> 
> -Setting up libsdl2-ttf-dev:amd64 (2.0.15+dfsg1-2) ...^M
> +Setting up libsdl2-ttf-dev:amd64 (2.0.18+dfsg-2) ...^M
> 
> 
> Andreas



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

Bug#1004914: libclang-common-13-dev: /usr/bin/s390x-linux-gnu-ld: cannot find /usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.builtins-s390x.a: No such file or directory

[Nicholas Guriev]

Package: libclang-common-13-dev

Dear maintainer,

The package seems to be missing libclang_rt.builtins-s390x.a, compiler
runtime library, and so Clang is unable to produce useful binaries on
s390x platform. Can you please look at this error? This is especially
critical for C++ code with exceptions which require internal __cxa
routines.

(llvm_archive20220130_s390x)builder@barberry:/$ LANG=C clang -v 
-rtlib=compiler-rt -x c <(echo 'int main(){return 0;}') -o /dev/null
Debian clang version 13.0.1-+rc3-1~exp1+b1
Target: s390x-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/11
Selected GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/lib/llvm-13/bin/clang" -cc1 -triple s390x-unknown-linux-gnu -emit-obj 
-mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier 
-discard-value-names -main-file-name 63 -mrelocation-model static 
-mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases 
-target-cpu z196 -debugger-tuning=gdb -v -fcoverage-compilation-dir=/ 
-resource-dir /usr/lib/llvm-13/lib/clang/13.0.1 -internal-isystem 
/usr/lib/llvm-13/lib/clang/13.0.1/include -internal-isystem /usr/local/include 
-internal-isystem 
/usr/bin/../lib/gcc/s390x-linux-gnu/11/../../../../s390x-linux-gnu/include 
-internal-externc-isystem /usr/include/s390x-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdebug-compilation-dir=/ -ferror-limit 19 -fno-signed-char 
-fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o /tmp/63-d7855c.o -x c 
/dev/fd/63
clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target s390x-linux-gnu
ignoring nonexistent directory 
"/usr/bin/../lib/gcc/s390x-linux-gnu/11/../../../../s390x-linux-gnu/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-13/lib/clang/13.0.1/include
 /usr/local/include
 /usr/include/s390x-linux-gnu
 /usr/include
End of search list.
 "/usr/bin/s390x-linux-gnu-ld" --build-id --eh-frame-hdr -m elf64_s390 
-dynamic-linker /lib/ld64.so.1 -o /dev/null /lib/s390x-linux-gnu/crt1.o 
/lib/s390x-linux-gnu/crti.o /usr/bin/../lib/gcc/s390x-linux-gnu/11/crtbegin.o 
-L/usr/bin/../lib/gcc/s390x-linux-gnu/11 -L/lib/s390x-linux-gnu 
-L/usr/lib/s390x-linux-gnu -L/usr/lib/llvm-13/bin/../lib -L/lib -L/usr/lib 
/tmp/63-d7855c.o 
/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.builtins-s390x.a 
--as-needed -lgcc_s --no-as-needed -lc 
/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.builtins-s390x.a 
--as-needed -lgcc_s --no-as-needed 
/usr/bin/../lib/gcc/s390x-linux-gnu/11/crtend.o /lib/s390x-linux-gnu/crtn.o
/usr/bin/s390x-linux-gnu-ld: cannot find 
/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.builtins-s390x.a: No 
such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)



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

Bug#1004912: Acknowledgement (rarcrack dead upstream?)

[Mathieu Malaterre]

Should we switch to:

https://github.com/jaredsburrows/rarcrack

?

Bug#1004913: python-fysom: incompatible import from collections in py3.10

[Andreas Hasenack]

Package: python-fysom
Version: 2.1.5-3
Severity: normal

Dear Maintainer,

in python 3.10, "from collections import Mapping" doesn't work anymore
and should be imported from collections.abc
$ python3 debian/tests/import3
Traceback (most recent call last):
  File "/home/ubuntu/deb/python-fysom/python-fysom/debian/tests/import3",
line 4, in 
fsm = Fysom({'initial': 'green',
  File "/usr/lib/python3/dist-packages/fysom/__init__.py", line 162,
in __init__
if isinstance(e, collections.Mapping):
AttributeError: module 'collections' has no attribute 'Mapping'

Upstream fixed this in 2.1.6, and this is the patch:
https://github.com/mriehl/fysom/commit/1ed6950d2b683a9a2a2ab35dfd0ea79dc2963dc3

>From 1ed6950d2b683a9a2a2ab35dfd0ea79dc2963dc3 Mon Sep 17 00:00:00 2001
From: Karthikeyan Singaravelan 
Date: Thu, 9 Apr 2020 14:32:14 +
Subject: [PATCH] Import ABC from collections.abc instead of collections for
 Python 3 compatibility.

---
 src/main/python/fysom/__init__.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/main/python/fysom/__init__.py
b/src/main/python/fysom/__init__.py
index 6458bbb..179512f 100644
--- a/src/main/python/fysom/__init__.py
+++ b/src/main/python/fysom/__init__.py
@@ -27,12 +27,16 @@
 # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #

-import collections
 import functools
 import weakref
 import types
 import sys

+try:
+from collections.abc import Mapping
+except ImportError:
+from collections import Mapping
+
 __author__ = 'Mansour Behabadi'
 __copyright__ = 'Copyright 2011, Mansour Behabadi and Jake Gordon'
 __credits__ = ['Mansour Behabadi', 'Jake Gordon']
@@ -159,7 +163,7 @@ def __init__(self, cfg={}, initial=None,
events=None, callbacks=None,
 # convert 3-tuples in the event specification to dicts
 events_dicts = []
 for e in cfg["events"]:
-if isinstance(e, collections.Mapping):
+if isinstance(e, Mapping):
 events_dicts.append(e)
 elif hasattr(e, "__iter__"):
 name, src, dst = list(e)[:3]
@@ -520,7 +524,7 @@ def is_very_angry(self, event):
 # convert 3-tuples in the event specification to dicts
 events_dicts = []
 for e in cfg["events"]:
-if isinstance(e, collections.Mapping):
+if isinstance(e, Mapping):
 events_dicts.append(e)
 elif hasattr(e, "__iter__"):
 name, src, dst = list(e)[:3]

Bug#1004912: rarcrack dead upstream?

[Mathieu Malaterre]

Source: rarcrack
Version: 0.2

Could someone shed some light on this? Is upstream dear or not ?
I do not even understand why I get a redirect to:

This: http://rarcrack.sourceforge.net/

Goes to:

https://sourceforge.net/projects/jpassrecovery/

Bug#1004911: flex: Line numbers in C code incorrect for .l source

[Bill Currie]

Package: flex
Version: 2.6.4-8
Severity: normal

Dear Maintainer,

Line numbers refering to the source .l file are generally out by one,
making it difficult to handle compiler error messages (especially when
gcc tries to be helpful by displaying the line, but instead shows the
wrong line) or to debug in gdb as gdb shows the wrong line.

Injecting an error into the code:
^#{s}+{D}+{s}+\"(\.|[^"\n])*\".*$ { li ne_info (yytext + 1); } // line 120

Produces:
../tools/qfcc/source/qc-lex.l:121:3: error: unknown type name ‘li’
  121 | ^#line{s}+{D}+{s}+\"(\.|[^"\n])*\".*$ { line_info (yytext + 5); }

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.33-2
ii  m4 1.4.18-5

Versions of packages flex recommends:
ii  clang-3.4 [c-compiler]  1:3.4.2-16
ii  gcc [c-compiler]4:11.2.0-2
ii  gcc-10 [c-compiler] 10.3.0-13
ii  gcc-11 [c-compiler] 11.2.0-13
ii  gcc-4.6 [c-compiler]4.6.4-7
ii  gcc-4.7 [c-compiler]4.7.4-3
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.4-2
ii  gcc-5 [c-compiler]  5.5.0-12
ii  gcc-6 [c-compiler]  6.4.0-18
ii  gcc-8 [c-compiler]  8.4.0-6
ii  gcc-9 [c-compiler]  9.4.0-4+b1
ii  libfl-dev   2.6.4-8

Versions of packages flex suggests:
ii  bison2:3.8.2+dfsg-1
ii  build-essential  12.9
pn  flex-doc 

-- no debconf information

Bug#1004910: need an autopkgtest for libsss-sudo

[Marc Haber]

Source: sudo
Version: 1.9.8p2-1
Severity: wishlist

Hi,

to be better able to debug sudo with libsss-sudo, an autopkgtest
similiar to debian/tests/03-getroot-ldap using sss would be helpful.

I am unfortunately not in the situation to write such a thing in these
days, since I neither know sss nor have enough LDAP knowledge to do
this.

Greetings
Marc

Bug#975016: #975016 - OpenJDK 17 support state for Bullseye

[Holger Levsen]

hi,

almost exactly a year ago...

On Sun, Feb 07, 2021 at 11:59:23AM +0100, Matthias Klose wrote:
> So I'm going with option 1, preparing for an openjdk-17 in bullseye, and
> preparing release notes and notes for security support.  This is more
> conservative than option 2, but allows to do better than the commitment made.
> 
> The option also has the advantage that approval is only needed by the security
> team.  openjdk-17 already is in testing.  granting unblock requests for new
> snapshot builds by the release team would be appreciated, but isn't strictly
> necessary as long as we can build newer snapshots. And that can be checked in
> unstable.

so, as I see it, openjdk-17 is in bullseye and now I'm wondering what
I should do with  #975016 titled "OpenJDK 17 support state for Bullseye"
and filed against src:debian-security-support, as openjdk-17 seems to be
supported and src:debian-security-support's purpose is to documented what's
unsupported.

so, should I just close this bug?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

A ship is always safe at shore, but that is not what it's built for.
(Albert Einstein)


signature.asc
Description: PGP signature

Bug#793660: Is still an issue

[Marc Haber]

On Wed, Feb 02, 2022 at 07:55:07PM +0100, Borden wrote:
> Just reinstalled again, ran a sudo command and got
> 
> debian: Feb  2 18:47:09 : borden : problem with defaults entries ; TTY=pts/1 
> ; PWD=/home/borden ; USER=root ;
> 
> Delivered to my inbox. I'm not sure if that's a bug problem or a me problem

I have never seen such a message delivered via e-mail. Is this a strange
syslog configuration, or a container setup? Normally, message like this
end up in auth.log.

Can you give the exact sudo command you ran, your config, what the sudo
command printed, and maybe the result of stracing sudo?

I need more information about reproducing this. Please don't assume that
I have an LDAP/sss installation handy and am familiar with using
libsss-sudo.

@Timo, can you help here? Did you save the Fedora patch back in 2015?

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#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Vincent Lefevre]

On 2022-02-03 14:21:58 +0100, Marc Haber wrote:
> Is the bug repeatable by unfreezing the message and forcing a delivery
> attempt? If so, you might be able to get a core dump from the delivering
> exim.

The delivery was successful. There was still a "TLS error on
connection (recv): The TLS connection was non-properly terminated."
error, but no 450:

2022-02-02 13:42:28 Start queue run: pid=150965 -qff
2022-02-02 13:42:28 1nEt2b-0008jG-97 Unfrozen by forced delivery
2022-02-02 13:42:31 1nEt2b-0008jG-97 H=mx1.mailchannels.net [54.189.39.249] TLS 
error on connection (recv): The TLS connection was non-properly terminated.
2022-02-02 13:42:31 1nEt2b-0008jG-97 => xxx@yyy R=dnslookup T=remote_smtp 
H=mx1.mailchannels.net [54.189.39.249] 
X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes 
DN="CN=*.mailchannels.net" C="250 2.0.0 Ok: queued as 6D9D5201EF"
2022-02-02 13:42:31 1nEt2b-0008jG-97 Completed
2022-02-02 13:42:31 End queue run: pid=150965 -qff

> If the 450 is casued by greylisting on the remote side, that debugging
> attempt must be close to the first time of sending the message so that
> the 450 is still there.

Unfortunately, I can't control that.

Perhaps the bug is due to the combination of both a "TLS error on
connection (recv): The TLS connection was non-properly terminated."
error and a 450, e.g. in case exim does something valid only if
there were no errors. A potential security issue?

If I understand correctly, the error comes from

  record_io_error(state, (int)inbytes, US"recv", NULL);

in src/tls-gnu.c, tls_read().

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

Bug#1004905: sudo: FTBFS on non-linux architectures

[Marc Haber]

Control: tags -1 moreinfo
thanks

This will be the bugreport we will use to investgate the failing tests.

On Thu, Feb 03, 2022 at 11:39:37AM +0100, Laurent Bigonville wrote:
> On hurd, it fails in the tests
> 
> On kfreebsd, 

(...)

> , but it still fails in the tests

Build log for hurd is here: 
https://buildd.debian.org/status/fetch.php?pkg=sudo=hurd-i386=1.9.9-1=1643664021=0

I don't see any failed tests, but
Makefile:636: recipe for target 'check' failed
make[3]: *** [check] Error 3
make[3]: Leaving directory '/<>/build-simple/plugins/sudoers'
Makefile:114: recipe for target 'check' failed
make[2]: *** [check] Error 2
make[2]: Leaving directory '/<>/build-simple'
dh_auto_test: error: cd build-simple && make -j1 check VERBOSE=1 returned exit 
code 2
debian/rules:50: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 255
make[1]: Leaving directory '/<>'
debian/rules:37: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

That doesn't make sense to me from the logs.

It would help if I got access to lemon.debian.net; maybe the local admin
can also give information why the build fails. What do I do to get
access to lemon and sudo's build-depends installed?

Greetings
Marc

Bug#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Marc Haber]

On Thu, Feb 03, 2022 at 03:46:22AM +0100, Vincent Lefevre wrote:
> On 2022-02-03 03:29:24 +0100, Vincent Lefevre wrote:
> > On 2022-02-02 18:20:48 +0100, Andreas Metzler wrote:
> > > Any chance of getting a coredump?
> > 
> > exim didn't leave a coredump. I could see that Mutt disables coredumps
> > after some time. I don't know under which condition.
> 
> I've eventually found that coredumps are disabled when I start Mutt
> from my window manager (FVWM), but not from a terminal (actually,
> that's the same wrapper in both cases). The reason seems that
> disabled coredumps is the default (according to /proc/.../limits),
> but I re-enable them in my shell.

Is the bug repeatable by unfreezing the message and forcing a delivery
attempt? If so, you might be able to get a core dump from the delivering
exim.

If the 450 is casued by greylisting on the remote side, that debugging
attempt must be close to the first time of sending the message so that
the 450 is still there.

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#1004908: ITP: faber -- software build system

[Steffen Moeller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: faber -- software build system
Package: wnpp
Owner:  
Severity: wishlist

* Package name: faber
  Version : 0.6.0.dev1
  Upstream Author : Stefan Seefeld
* URL : http://stefan.seefeld.name/faber/
* License : Boost-1.0
  Programming Lang: Python
  Description : software build system
 Software developers prepare a bunch of files with their source code
 that may be taken as they are or somehow processed to constitute
 the final software package. This can be tricky when the processing
 itself is tricky, and because the processing of one file may depend
 on the processing of other files, e.g. to link against a library.
 And when linking against external libraries, this need to be in the
 right version. And then there are tests performed to check that
 all is fine on that particular platoform that the build is performed on.
 And finally, the developer wants an easy way to be pointed to where
 the problem occurred.
 .
 Traditionally, the building of software is done with Make, but many
 new tools have evolved ever since, often adapted to a new programming
 language. This package provides the executable of the faber software
 build system that was adopted by the Python Boost interface but is not
 specific for Python.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/faber