Bug#1002677: v2.0.2 fails to compile

[Kyle Robbertze]

Control: -1 tags + help

The fix for this is to package liquidsoap v2. I have got some work on 
that in the git repo, however it is failing to detect camomile and I 
don't know enough of the ocaml via make build system to debug it. I 
think this may be an upstream issue, as the camomile package hasn't 
changed since the last liquidsoap version uploaded to Debian.


The relevant lines of the build log:

checking for ocaml camomile module >= 1.0.0... requires version >= 1.0.0 found [unspecified]. 
configure: error: Camomile provides charset detection and conversions. It is strongly advised to enable those features. If you really don't want this, use --disable-camomile.


Any help is appreciated.

Thanks
Kyle
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1003346: transition: log4cxx

[Tobias Frost]

On Sun, Jan 09, 2022 at 02:46:47PM +0100, Sebastian Ramacher wrote:
> Please go ahead

Done and it seems that all rebuild have been scheduled and completed already!

Thanks especially for that quick turnaround!

Cheers,
-- 
tobi

Bug#1003441: ITP: python-tempestconf -- automatic tempest configuration

[Thomas Goirand]

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

* Package name: python-tempestconf
  Version : 2.1.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openinfra/python-tempestconf
* License : Apache-2.0
  Programming Lang: Python
  Description : automatic tempest configuration

 python-tempestconf will automatically generate the tempest configuration based
 on your cloud.

Note: This is an indirect dependency for refstack-client, which is a tool to
validate an OpenStack deployment that I'm also going to package.

Bug#1002677: v2.0.2 fails to compile

[Stéphane Glondu]

Dear Kyle,

Le 10/01/2022 à 08:56, Kyle Robbertze a écrit :
> The fix for this is to package liquidsoap v2. I have got some work on
> that in the git repo, however it is failing to detect camomile and I
> don't know enough of the ocaml via make build system to debug it. I
> think this may be an upstream issue, as the camomile package hasn't
> changed since the last liquidsoap version uploaded to Debian.
> 
> The relevant lines of the build log:
> 
>> checking for ocaml camomile module >= 1.0.0... requires version >=
>> 1.0.0 found
>> [unspecified].   
>>  
>> configure: error: Camomile provides charset detection and conversions.
>> It is strongly advised to enable those features. If you really don't
>> want this, use --disable-camomile.
> 
> Any help is appreciated.

Master is still at debian/1.4.4-1. Can you push your current state of
the packaging, please?


Cheers,

-- 
Stéphane

Bug#1002677: v2.0.2 fails to compile

[Kyle Robbertze]

On 2022/01/10 10:10, Stéphane Glondu wrote:

Dear Kyle,

Le 10/01/2022 à 08:56, Kyle Robbertze a écrit :

The fix for this is to package liquidsoap v2. I have got some work on
that in the git repo, however it is failing to detect camomile and I
don't know enough of the ocaml via make build system to debug it. I
think this may be an upstream issue, as the camomile package hasn't
changed since the last liquidsoap version uploaded to Debian.

The relevant lines of the build log:


checking for ocaml camomile module >= 1.0.0... requires version >=
1.0.0 found
[unspecified].
configure: error: Camomile provides charset detection and conversions.
It is strongly advised to enable those features. If you really don't
want this, use --disable-camomile.


Any help is appreciated.


Master is still at debian/1.4.4-1. Can you push your current state of
the packaging, please?


Urg, pushed the other branches, but not master. Updated now

Cheers
Kyle

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1003442: ITP: refstack-client -- OpenStack platform validation client

[Thomas Goirand]

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

* Package name: refstack-client
  Version : 0.0.0~2021.08.18.fa73ef2524
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openinfra/refstack-client
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack platform validation client

 Refstack-client is a command line utility that allows you to execute Tempest
 test runs based on configurations you specify. When finished running Tempest
 it can send the passed test data to a RefStack API server.

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Ritesh Raj Sarraf]

IIRC, this is intentional. d-i doesn't provide libsystemd in the
installer environment.

In the installer environment, one is supposed to use iscsistart binary.


On Sat, 2022-01-08 at 23:29 +, Eugene wrote:
> open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in
> installer environment
> 
> PACKAGE:
> open-iscsi-udeb (only a bug in the installer environment)
> 
> FIX REQUIRED:
> * Add libsystemd0 to following packages in:
> https://salsa.debian.org/linux-blocks-team/open-iscsi
> debian/control
> open-iscsi "Depends"
> open-iscsi-udeb "Depends"
> 
> LOGIC/REASONING:
> 1) libsystemd is a "Build-Depends" for this package (but is omitted
> in the run-time dependency list "Depends" 
> 
> ---
> 
> 2) When running the debian-installer (partman-iscsi), this calls
> open-iscsi package to setup ISCSI drives at install time
> 
> 2.1) The iscsi setup fails because "/sbin/iscsid" cannot run due to
> being unable to find "libsystemd0.so"
> 
> 2.2) Further checks on the installer environment show that
> "libsystemd.so.0" is not present in /lib directory
> 
> ---
> 
> 3) "libsystemd.so.0" is present once installed (so this is purely
> installer related)
> 
> ---
> 
> *) It also complains about missing "/etc/iscsi/initiatorname.iscsi" -
> but I am hoping that is setup automatically once the daemon starts

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1002997: podman: Please provide a default /etc/containers/storage.conf

[Valentin Rothberg]

Hi folks,

Thanks for pulling me in.

On Sun, Jan 9, 2022 at 11:15 PM Reinhard Tartler  wrote:

> Control: reassign -1 storage-common
> Control: affects -1 podman
>
> Hi Philip,
>
> Thank you for your bug report. I'll defer to our overlay expert, Giuseppe.
>
> The Debian equivalent to Fedora's package 'containers-common' has the same
> name in debian, and does ship a 'storage.conf' file in
> /usr/share/containers/storage.conf. This is so that the local administrator
> can copy it to /etc/containers/storage.conf and do local modifications. The
> Debian package copies the storage.conf from the upstream source verbatim.
> As you can see at
> https://github.com/containers/storage/blob/375f77c66685b14fc580daad2dc6df607fb86dee/storage.conf#L95,
> the mount option 'metacopy=on' is missing even upstream.
>
> I am not sure why the Fedora package decided to patch the configuration
> file -- I couldn't find a comment in the .src.rpm that you linked. Also,
> looking at the kernel documentation you provided, it seems your concerns
> re: security are justified, and the option seems to have significant
> security implications:
>
> Do not use metacopy=on with untrusted upper/lower directories. Otherwise
>> it is possible that an attacker can create a handcrafted file with
>> appropriate REDIRECT and METACOPY xattrs, and gain access to file on lower
>> pointed by REDIRECT. This should not be possible on local system as setting
>> “trusted.” xattrs will require CAP_SYS_ADMIN. But it should be possible for
>> untrusted layers like from a pen drive.
>
>
> I'm not sure whether enabling it by default is a good idea. I need to
> think more about this.
>

@Giuseppe Scrivano  what do you think?


> I'd also appreciate hearing additional opinions on this, and have copied
> some friends from podman upstream. Do you happen to know what's the
> background / thinking in Fedora with enabling the option metacopy=on?
>
> Happy New Year!
>
> -rt
>
>
> On Sun, Jan 2, 2022 at 9:51 AM Philip  wrote:
>
>> Package: podman
>> Version: 3.0.1+dfsg1-3+b2
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> I had some problems running the dockerized version of the Unifi
>> controller jacobalberty/unifi-docker
>> with podman on Debian.
>> On a Fedora system, starting the container only takes a few seconds.
>> On a Debian system, it can take about 5 minutes.
>>
>> The reason is that on the Fedora system the mount-option metacopy=on
>> (see  [1] for this mount option) is set for the container overlayfs via a
>> default /etc/containers/storage.conf.
>> That makes quite the difference for this specific image because it does a
>> `chown unifi:unifi /usr/lib/unifi` during startup.
>> chown-ing these 6k files is fast with metacopy=on (on Fedora).
>> Without the option (on Debian), I think the files will be copied instead
>> of only their metadata, making it rather slow.
>>
>> So the solution for me was to copy /etc/containers/storage.conf from a
>> Fedora system. If anyone has a similar problem, the file can be extracted
>> from the
>> src rpm of the containers-common package which can be downloaded at [2].
>>
>> IMO it would be useful if Debian would also include a default
>> /etc/containers/storage.conf.
>> Thanks for considering this!
>> However I'm not sure if metacopy=on is a good idea from a security
>> perspective.
>>
>> Best
>> Philip
>>
>> -- 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-10-amd64 (SMP w/2 CPU threads)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US:en
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages podman depends on:
>> ii  conmon   2.0.25+ds1-1.1
>> ii  containernetworking-plugins  0.9.0-1+b6
>> ii  crun 0.17+dfsg-1
>> ii  golang-github-containers-common  0.33.4+ds1-1
>> ii  init-system-helpers  1.60
>> ii  iptables 1.8.7-1
>> ii  libc62.31-13+deb11u2
>> ii  libdevmapper1.02.1   2:1.02.175-2.1
>> ii  libgpgme11   1.14.0-1+b2
>> ii  libseccomp2  2.5.1-1+deb11u1
>>
>> Versions of packages podman recommends:
>> ii  buildah   1.19.6+dfsg1-1+b6
>> ii  catatonit 0.1.5-2
>> ii  fuse-overlayfs1.4.0-1
>> ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b7
>> ii  slirp4netns   1.0.1-2
>> ii  uidmap1:4.8.1-1
>>
>> Versions of packages podman suggests:
>> pn  containers-storage  
>> pn  docker-compose  
>>
>> -- no debconf information
>>
>>
>> [1]:
>> https://www.ke

Bug#1003443: libpam-ssh: Default profile "ssh-pwd" breaks common-auth configuration

[Andreas Kurth]

Package: libpam-ssh
Version: 2.3+ds-5
Severity: important
X-Debbugs-Cc: deb...@akurth.de

Dear maintainer,

after upgrading from 2.3+ds-3 to 2.3+ds-5 the default profile changed
to "ssh-pwd", which added the following line at the bottom of my
/etc/pam.d/common-auth:

  [success=0 default=ignore]pam_ssh.so use_first_pass

This leads to the following error:

  login[1089]: PAM pam_parse: expecting non-zero; [... default=ignore]

which in turn prohibits any login.

The former default profile "ssh" added the line:

  optional pam_ssh.so use_first_pass

Booting into rescue and changing the directive to "optional" fixed the
problem, as expected.

Cheers, Andreas.


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

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

Versions of packages libpam-ssh depends on:
ii  libc6   2.33-2
ii  libpam-runtime  1.4.0-11
ii  libpam0g1.4.0-11
ii  libssl1.1   1.1.1m-1

Versions of packages libpam-ssh recommends:
ii  libpam-tmpdir0.09+b2
ii  openssh-client [ssh-client]  1:8.7p1-4

libpam-ssh suggests no packages.

-- no debconf information

Bug#961481: ceph: Protocol incompatibility between armhf and amd64

[Bernhard Turmann]

  
  
Hello Val, hello Ard,
I am not sure, but the issue might be fixed. There is an interesting
comment in the upstream changelog [1] of Ceph Pacific v16.2.5:

A long-standing bug that prevented 32-bit
  and 64-bit client/server interoperability under msgr v2 has been
  fixed. In particular, mixing armv7l (armhf) and x86_64 or aarch64
  servers in the same cluster now works.

Ceph version 16.2.7 is now in sid/unstable which also passed
autopkgtest for armhf.

Many Thanks to Thomas, Bernd et al for their work, much appreciated.

[1]: https://ceph.com/en/news/blog/2021/v16-2-5-pacific-released/

Best Regards
Berni
  

Bug#1002997: podman: Please provide a default /etc/containers/storage.conf

[Giuseppe Scrivano]

Valentin Rothberg  writes:

> Hi folks,
>
> Thanks for pulling me in.
>
> On Sun, Jan 9, 2022 at 11:15 PM Reinhard Tartler  wrote:
>
>  Control: reassign -1 storage-common
>  Control: affects -1 podman
>
>  Hi Philip,
>
>  Thank you for your bug report. I'll defer to our overlay expert, Giuseppe.
>
>  The Debian equivalent to Fedora's package 'containers-common' has the same 
> name in debian, and does ship a 'storage.conf' file in 
> /usr/share/containers/storage.conf. This is so that the local
>  administrator can copy it to /etc/containers/storage.conf and do local 
> modifications. The Debian package copies the storage.conf from the upstream 
> source verbatim. As you can see at
>  
> https://github.com/containers/storage/blob/375f77c66685b14fc580daad2dc6df607fb86dee/storage.conf#L95,
>  the mount option 'metacopy=on' is missing even upstream.
>
>  I am not sure why the Fedora package decided to patch the configuration file 
> -- I couldn't find a comment in the .src.rpm that you linked. Also, looking 
> at the kernel documentation you provided, it
>  seems your concerns re: security are justified, and the option seems to have 
> significant security implications:
>
>  Do not use metacopy=on with untrusted upper/lower directories. Otherwise it 
> is possible that an attacker can create a handcrafted file with appropriate 
> REDIRECT and METACOPY xattrs, and
>  gain access to file on lower pointed by REDIRECT. This should not be 
> possible on local system as setting “trusted.” xattrs will require 
> CAP_SYS_ADMIN. But it should be possible for untrusted
>  layers like from a pen drive.
>
>  I'm not sure whether enabling it by default is a good idea. I need to think 
> more about this.
>
> @Giuseppe Scrivano what do you think?

please keep in mind that unprivileged overlay mounts cannot use
metacopy.  You still need root access on the host (CAP_SYS_ADMIN in
the initial user namespace) in order to use metacopy=on.

While it is safe to pull random images from the network and expect they
cannot exploit the system to gain access to files outside the image
itself, there is no guarantee when you are using a handcrafted storage
repository as you seem to imply with the pen drive example.
There are so many things that can be abused that metacopy=on is the last
I'd worry about :-)  For such cases, I suggest to use rootless, and rely
on the kernel to limit what the unpriviled user can do.

Regards,
Giuseppe



>  I'd also appreciate hearing additional opinions on this, and have copied 
> some friends from podman upstream. Do you happen to know what's the 
> background / thinking in Fedora with enabling the
>  option metacopy=on?
>
>  Happy New Year!
>
>  -rt
>
>  On Sun, Jan 2, 2022 at 9:51 AM Philip  wrote:
>
>  Package: podman
>  Version: 3.0.1+dfsg1-3+b2
>  Severity: wishlist
>
>  Dear Maintainer,
>
>  I had some problems running the dockerized version of the Unifi controller 
> jacobalberty/unifi-docker
>  with podman on Debian.
>  On a Fedora system, starting the container only takes a few seconds.
>  On a Debian system, it can take about 5 minutes.
>
>  The reason is that on the Fedora system the mount-option metacopy=on
>  (see  [1] for this mount option) is set for the container overlayfs via a 
> default /etc/containers/storage.conf.
>  That makes quite the difference for this specific image because it does a
>  `chown unifi:unifi /usr/lib/unifi` during startup.
>  chown-ing these 6k files is fast with metacopy=on (on Fedora).
>  Without the option (on Debian), I think the files will be copied instead of 
> only their metadata, making it rather slow.
>
>  So the solution for me was to copy /etc/containers/storage.conf from a
>  Fedora system. If anyone has a similar problem, the file can be extracted 
> from the
>  src rpm of the containers-common package which can be downloaded at [2].
>
>  IMO it would be useful if Debian would also include a default
>  /etc/containers/storage.conf.
>  Thanks for considering this!
>  However I'm not sure if metacopy=on is a good idea from a security
>  perspective.
>
>  Best
>  Philip
>
>  -- 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-10-amd64 (SMP w/2 CPU threads)
>  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
>  Shell: /bin/sh linked to /usr/bin/dash
>  Init: systemd (via /run/systemd/system)
>  LSM: AppArmor: enabled
>
>  Versions of packages podman depends on:
>  ii  conmon   2.0.25+ds1-1.1
>  ii  containernetworking-plugins  0.9.0-1+b6
>  ii  crun 0.17+dfsg-1
>  ii  golang-github-containers-common  0.33.4+ds1-1
>  ii  init-system-helpers  1.60
>  ii  iptables 1.8.7-1
>  ii  libc62.31-13+deb11u2
>  ii  libdevmapper1.02.1 

Bug#961481: ceph: Protocol incompatibility between armhf and amd64

[Bernhard Turmann]

Hello Val, hello Ard,
I am not sure, but the issue might be fixed. There is an interesting comment in
the upstream changelog [1] of Ceph Pacific v16.2.5:

A long-standing bug that prevented 32-bit and 64-bit client/server 
interoperability under msgr v2 has been fixed. In particular, mixing armv7l 
(armhf) and x86_64 or aarch64 servers in the same cluster now works.


Ceph version 16.2.7 is now in sid/unstable which also passed autopkgtest for 
armhf.

Many Thanks to Thomas, Bernd et al for their work, much appreciated.

[1]:https://ceph.com/en/news/blog/2021/v16-2-5-pacific-released/

Best Regards
Berni

Bug#1003444: cyrus-imapd: Warning from cron.daily script - wrong options for xargs

[Stefan Nobis]

Package: cyrus-imapd
Version: 3.2.6-2+deb11u1
Severity: normal
Tags: patch

Dear Maintainer,

after upgrading from buster to bullseye I get warnings from cron about
the cyrus-imapd (version 3.2.6-2+deb11u1) cron.daily script:

  xargs: warning: options --max-args and --replace/-I/-i are mutually 
exclusive, ignoring previous --max-args value

It seems in the script /etc/cron.daily/cyrus-imapd line 58

   xargs --null -n 1 -r -i'{1}' \

should be changed to

   xargs --null -r -I'{1}' \

where "-I" implies "-L 1" which is the correct replacement of "-n 1" in
the context of using the replacement mechanism of xargs.

Bug#1003171: calibre: Calibre version used in debian stable does not start

[Georges Gouriten]

On Wed, 5 Jan 2022 16:45:35 +0100 Julien Cristau  wrote:
> >   File "/usr/lib/calibre/calibre/devices/smart_device_app/driver.py", line 
> > 2044, in 
> > from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
> > ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' 
> > (/usr/local/lib/python3.9/dist-packages/zeroconf/__init__.py)
> > 
> You've got a zeroconf python package installed in /usr/local, outside
> the Debian package management, overriding the packaged version, and
> breaking things.

You are absolutely right, my bad.
To fix my problem, I just had to run (as root) pip uninstall zeroconf, it 
switched back to the debian version (located in 
/usr/lib/python3/dist-packages/), and calibre works again.

Feel free to delete my bug report.

Best regards

Bug#1002677: v2.0.2 fails to compile

[Stéphane Glondu]

Le 10/01/2022 à 09:21, Kyle Robbertze a écrit :
>>> The fix for this is to package liquidsoap v2. I have got some work on
>>> that in the git repo, however it is failing to detect camomile and I
>>> don't know enough of the ocaml via make build system to debug it. I
>>> think this may be an upstream issue, as the camomile package hasn't
>>> changed since the last liquidsoap version uploaded to Debian.
>>>
>>> The relevant lines of the build log:
>>>
 checking for ocaml camomile module >= 1.0.0... requires version >=
 1.0.0 found
 [unspecified].
 configure: error: Camomile provides charset detection and conversions.
 It is strongly advised to enable those features. If you really don't
 want this, use --disable-camomile.
>>>
>>> Any help is appreciated.
>>
>> Master is still at debian/1.4.4-1. Can you push your current state of
>> the packaging, please?
> 
> Urg, pushed the other branches, but not master. Updated now

It turns out the problem was in camomile: the version was not advertised
correctly. This was due to use of a wrong upstream tarball. I've just
fixed that in camomile 1.0.2+2-1, and liquidsoap builds successfully
with it.


Cheers,

-- 
Stéphane

Bug#879786: apt: Please explain in apt-secure(8) how to switch stable to oldstable

[Helge Kreutzmann]

Package: apt
Version: 2.2.4
Severity: wishlist

I just had to update a machine running (now) oldstable. It was last
updated before the release of bullseye, so it is not oldstabel.

Running apt-get update, I get lots of:
E: Repository 'http://security.debian.org buster/updates InRelease' changed its 
'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.
…

This is expected, and I read apt-secure(8) how to deal with this.
However,  the man page simply says:
Since version 1.5 the user
   must therefore explicitly confirm changes to signal that the
   user is sufficiently prepared e.g. for the new major release of
   the distribution shipped in the repository (as e.g. indicated
   by the codename).

However, there is no link how to do this, what steps are necessary.

After a quick online search, I found that:
apt-get update --allow-releaseinfo-change

does the trick. 

Since this is a common use case, please describe it, e.g. in an
EXAMPLE section. Possibly examples from other frontends (like apt,
aptitutude, dselect, …) could be added as well.

This would greatly reduce the workload for a part time administrator
(and would avoid trusing "random" web sources).

Before sending I found this bug (#879786) and I think it would be a
really good idea handling this, the EXAMPLE section should be fairly
quickly written.

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

Kernel: Linux 5.10.79 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2
ii  libapt-pkg6.0   2.2.4
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-5
ii  libseccomp2 2.5.1-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
ii  apt-doc  2.2.4
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.20.9
ii  gnupg2.2.27-2
ii  gnupg2   2.2.27-2
pn  powermgmt-base   

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#1003408: ITS: manpages-hu by transferring it to manpages-l10n

[Helge Kreutzmann]

Hello László,
On Sun, Jan 09, 2022 at 09:19:49PM +0100, László Böszörményi (GCS) wrote:
> On Sun, Jan 9, 2022 at 7:30 PM Helge Kreutzmann  wrote:
> > As I'm not a DD (but a DM), the exact timing depends on those of my
> > sponsor(s). But I will ensure that at least 21 days have passed since
> > this bug was filled.
>  Indeed, manpages-hu package is a thing of the distant past. Would it
> help if I immediately file for its removal or what would be the best
> action to help your efforts?

Yes, this would be great. Then I would enable the hungarian
translation in the next upload (~ mid February most likely).

Thanks!

Greetings

   helge

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


signature.asc
Description: PGP signature

Bug#1003395: plfit FTBFS on s390x

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/ntamas/plfit/issues/38

The issue is actually discussed upstream even before this bug was filed.

Bug#1003445: RM: igraph [s390x] -- ROM; Fails to build on s390x since using Debian packaged plfit

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1003...@bugs.debian.org, igr...@packages.debian.org

Hi,

as explained in bug #1003395 against plfit igraph can not migrate to
testing since the Debian packaged plfit does not build on this
architecture.  Please remove igraph for s390x architecture to enable
testing migration until upstream has fixed the issue[1].

Thanks a lot for your work as ftpmaster

Andreas.


[1] https://github.com/ntamas/plfit/issues/38

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

[Mattia Rizzolo]

On Sun, Jan 09, 2022 at 12:56:28AM -0500, Andres Salomon wrote:
> 
> On 1/8/22 15:57, Mattia Rizzolo wrote:
> > On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> > > If you want to try with chromium 97; it now builds as an official build, 
> > > so
> > > those DCHECKs shouldn't even be compiled in. It also supports wayland
> > > automatically, in case that's related to your slowdowns.
> > > 
> > > https://salsa.debian.org/dilinger/chromium/-/tree/v97
> > I wanted to do this, but could it be that this version is for some
> > reason taking much more space than the previous one?  Here I have ~40 GB
> > free, and v96 built just fine (though I wasn't looking when it was
> > running), but now this failed already twice due to ENSPC.
> > 
> > I'll try looking for someplace more spacy but it's odd :)
> > 
> 
> Yeah, I think it's the debugging info; it's also breaking lld. It's a result
> of enabling official build, I'm working on it.

I see.

Well, it took me longer than I would have liked, but I finally got a
build out of that v97 branch (commit
2c2685aee67a677c85dd752aea08a7e571312116).

This one looks fully functional, gmail is as reactive as it used to be
(u.U after a few days with v96 and that slowness, now it feels so much
better lol) in the past, and after ~15 minutes of random usage it hasn't
crashed on me yet! \o/


It also fixed a problem I had with v93 where document google sheets
would look totally blank... so double happy now!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote:
> Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
> with cleaned-up commits. That's what I'll use for the NMU, which I'm
> preparing now.

If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.

I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again.  (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)


Regarding the git repository/team on salsa.  What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1003447: pgplot5: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Andreas Beckmann]

Source: pgplot5
Version: 5.2.2-19.4
Severity: serious
Tags: ftbfs sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package pgplot5 uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1003446: bugs.debian.org: bugspam.cgi fails with 7-digit bug numbers

[gregor herrmann]

Package: bugs.debian.org
Severity: normal
Tags: patch

I wanted to report a bug as containing spam via the web interface,
and bugspam.cgi failed with "No valid bug number."

My hunch was that this might be related to the BTS having passed the
1,000,000 mark and a regexp possibly needing an update.

So I cloned https://bugs.debian.org/debbugs-source/debbugs.git (not
sure if this is the correct/production repo) and indeed: SOmething
like the following would probably fix the issue:

#v+
diff --git a/examples/debian/misc/bugspam.cgi b/examples/debian/misc/bugspam.cgi
index 46bc17f..7830aee 100755
--- a/examples/debian/misc/bugspam.cgi
+++ b/examples/debian/misc/bugspam.cgi
@@ -16,7 +16,7 @@ sub quitcgi($;$) {
 }
 
 my $bug = param('bug') or quitcgi('No bug specfied', '400 Bad Request');
-quitcgi('No valid bug number', '400 Bad Request') unless $bug =~ /^\d{3,6}$/;
+quitcgi('No valid bug number', '400 Bad Request') unless $bug =~ /^\d{3,7}$/;
 my $remote_host = remote_host or quitcgi("No remote host");
 my $ok = param('ok');
 if (not defined $ok) {
#v-


Cheers,
gregor

Bug#1003307: restfuldb: FTBFS against sqlite3 3.37 or newer

[Andrius Merkys]

Control: owner 1003307 !
Control: tags 1003307 + confirmed upstream

Hello,

On 2022-01-08 00:02, Dan Bungert wrote:
> When built against sqlite 3.37 or newer, the build will fail in test.
> Example:
> https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/restfuldb/20220107_080256_a18a5@/log.gz
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/restfuldb/17950775/log.gz
> 
> tests/cases/Database.pm_001.sh:FAILED:
> 2c2
> <   'image' => 'blob'
> ---
>>   'image' => 'BLOB'
> 
> +many more of a similar nature.

Thank you for drawing attention to this issue. Your workaround works
fine, but it may hide possible future regressions where letter case is
actually important. Since I am one of the upstream developers I will see
how this could be fixed upstream.

Best,
Andrius

Bug#977469: matplotlib: Please make package bootstrappable

[Laurent Bigonville]

Hello,

As suggested in an other bug report, moving the build-dependencies that 
are only needed to build -doc/arch:all packages to Build-Depends-Indep 
would also help here I guess


Kind regards,

Laurent Bigonville

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Diederik de Haas]

On Monday, 10 January 2022 01:24:59 CET Ben Hutchings wrote:
> You'll be pleased to hear that in master, zstd with compression level 9
> is now the default.

Shouldn't the Recommends be on libzstd1 instead of on zstd?
Because the zstd package also supports and depends on liblz4-1, liblzma5 and 
zlib1g, while I'm *assuming* that that isn't needed for initramfs.

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

Bug#934366: Bug's gone in Bullseye

[Kovacs Lajos]

Dear Maintainers,

This bug was corrected, all is well in Bullseye, libreoffice-calc version
7.0.4-4+deb11u1.

Thank You!

Bug#1002223: simde: FTBFS: dh_auto_test: error: cd clang_test && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 6

[Nilesh Patra]

Andreas,

On Thu, 30 Dec 2021 09:07:08 +0100 Andreas Tille  wrote:
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/simd-everywhere/simde/issues/936
> 
> Hi,
> 
> I'm able to reproduce this issue in a local pbuilder chroot and have
> forwarded the issue upstream.

Quoting Michael's message from our matrix channel:

| Michael Crusoe
||gargantua_kerr
||Michael Crusoe: would you have free cycles to look into this simde FTBFS 
bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002223
| We can skip testing on clang, since we only use GCC to build with SIMDe in 
Debian

So I think you could simply do so and reduce the severity of the bug after a 
re-title since it is not exactly a 'fix' but a workaround

What do you think?

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1002569: rsplib: FTBFS on mipsel

[Thomas Dreibholz]

Hi,

unfortunately, version 3.4.0 did not fix the issue for misel. Version
3.4.1 provides the fix, successfully building on mipsel and mips64el.

I uploaded a new version on the mentors server for review:
https://mentors.debian.net/package/rsplib/ .

Den 04.01.2022 11:15, skrev Thomas Dreibholz:
> Hi,
>
> version 3.4.0 should fix the issue, by linking libatomic.
>
> I uploaded a new version on the mentors server for review:
> https://mentors.debian.net/package/rsplib/ .
>
> Den 01.01.2022 13:24, skrev Thomas Dreibholz:
>> Hi,
>>
>> confirmed. I am currently testing a fix.
>>
>> Den 24.12.2021 12:20, skrev Bastian Germann:
>>> Source: rsplib
>>> Severity: serious
>>> Version: 3.3.3-1
>>>
>>> rsplib fails to build on sid/mipsel:
>>> https://buildd.debian.org/status/fetch.php?pkg=rsplib&arch=mipsel&ver=3.3.3-1&stamp=1640318034&raw=0
>>>
>>>
>>> ...
>>> [ 55%] Linking CXX executable cspmonitor
>>> cd /<>/obj-mipsel-linux-gnu/src && /usr/bin/cmake -E
>>> cmake_link_script CMakeFiles/cspmonitor.dir/link.txt --verbose=1
>>> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=.
>>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>>> -D_FORTIFY_SOURCE=2 -Wall -Wl,-z,relro -Wl,-z,now -rdynamic
>>> CMakeFiles/cspmonitor.dir/cspmonitor_autogen/mocs_compilation.cpp.o
>>> CMakeFiles/cspmonitor.dir/cspmonitor.c.o -o cspmonitor
>>> -Wl,-rpath,/<>/obj-mipsel-linux-gnu/src:
>>> librspcsp.so.3.3.3 libtdbreakdetector.so.3.3.3 -lsctp -lpthread
>>> librspdispatcher.so.3.3.3 libtdnetutilities.so.3.3.3
>>> libtdstringutilities.so.3.3.3 libtdrandomizer.so.3.3.3
>>> libtdstorage.so.3.3.3 libtdloglevel.so.3.3.3
>>> libtdthreadsafety.so.3.3.3 libtdtimeutilities.so.3.3.3 -lm -lsctp
>>> -lpthread
>>> /usr/bin/ld: libtdbreakdetector.so.3.3.3: undefined reference to
>>> `__atomic_store_8'
>>> /usr/bin/ld: libtdbreakdetector.so.3.3.3: undefined reference to
>>> `__atomic_load_8'
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [src/CMakeFiles/cspmonitor.dir/build.make:128:
>>> src/cspmonitor] Error 1
>>> make[3]: Leaving directory '/<>/obj-mipsel-linux-gnu'
>>> make[2]: *** [CMakeFiles/Makefile2:1525:
>>> src/CMakeFiles/cspmonitor.dir/all] Error 2
>>> ...

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Diederik de Haas]

On Monday, 10 January 2022 11:10:52 CET Diederik de Haas wrote:
> On Monday, 10 January 2022 01:24:59 CET Ben Hutchings wrote:
> > You'll be pleased to hear that in master, zstd with compression level 9
> > is now the default.
> 
> Shouldn't the Recommends be on libzstd1 instead of on zstd?
> Because the zstd package also supports and depends on liblz4-1, liblzma5 and
> zlib1g, while I'm *assuming* that that isn't needed for initramfs.

It was just pointed out to me that dpkg already depends on liblzma5 and 
zlib1g, so my worry about bloat turns out to be unfounded.
(apart from that libzstd1 may not have a CLI interface itself, which looks to 
be needed)

Sorry for the noise.

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

Bug#980555: Missing ec_sys module

[Tim Connors]

Package: linux-image-amd64
Version: 5.10.84-1
Followup-For: Bug #980555
X-Debbugs-Cc: Bastian Blank , GengYu Rao 

>> What would you need this module for?  It's described as debugging and
>> development aid, not something a user wants to use.
> EC stands for embedded controller, which can be used to configure fans, 
> LED lights and other things on laptop.
> 
> I'm trying to use it to control fan speed on my laptop.

Basically anyone with a laptop and a default BIOS fan control profile
that is awful must resort to ec_sys.

For example, my Clevo P15SM needs this:
https://github.com/SkyLandTW/clevo-indicator/blob/master/src/clevo-indicator.c

It'd be really nice if I could quieten down my laptop from
jet-taking-off-at-maximum-throttle when the CPU temperature is only
50!

There seems no reason *not* to compile ec_sys as a module when the
debian kernel is so full of other debugging modules.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 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), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-10-amd64  5.10.84-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#879786: apt: Please explain in apt-secure(8) how to switch stable to oldstable

[Julian Andres Klode]

Control: notfound -1 2.2.4
Control: merge 879786 -1

On Mon, Jan 10, 2022 at 10:30:00AM +0100, Helge Kreutzmann wrote:
> Package: apt
> Version: 2.2.4
> Severity: wishlist
> 
> I just had to update a machine running (now) oldstable. It was last
> updated before the release of bullseye, so it is not oldstabel.
> 
> Running apt-get update, I get lots of:
> E: Repository 'http://security.debian.org buster/updates InRelease' changed 
> its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
> …

This was fixed in 1.8.2.3 and 2.1.10, see Bug#931566

> 
> This is expected, and I read apt-secure(8) how to deal with this.
> However,  the man page simply says:
> Since version 1.5 the user
>must therefore explicitly confirm changes to signal that the
>user is sufficiently prepared e.g. for the new major release of
>the distribution shipped in the repository (as e.g. indicated
>by the codename).
> 
> However, there is no link how to do this, what steps are necessary.
> 
> After a quick online search, I found that:
> apt-get update --allow-releaseinfo-change
> 
> does the trick. 
> 
> Since this is a common use case, please describe it, e.g. in an
> EXAMPLE section. Possibly examples from other frontends (like apt,
> aptitutude, dselect, …) could be added as well.
> 
> This would greatly reduce the workload for a part time administrator
> (and would avoid trusing "random" web sources).
> 
> Before sending I found this bug (#879786) and I think it would be a
> really good idea handling this, the EXAMPLE section should be fairly
> quickly written.

But why did you report a duplicate?

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

Bug#879786: apt: Please explain in apt-secure(8) how to switch stable to oldstable

[Julian Andres Klode]

On Mon, Jan 10, 2022 at 11:47:14AM +0100, Julian Andres Klode wrote:
> Control: notfound -1 2.2.4
> Control: merge 879786 -1
> 
> On Mon, Jan 10, 2022 at 10:30:00AM +0100, Helge Kreutzmann wrote:
> > Package: apt
> > Version: 2.2.4
> > Severity: wishlist
> > 
> > I just had to update a machine running (now) oldstable. It was last
> > updated before the release of bullseye, so it is not oldstabel.
> > 
> > Running apt-get update, I get lots of:
> > E: Repository 'http://security.debian.org buster/updates InRelease' changed 
> > its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this repository can 
> > be applied. See apt-secure(8) manpage for details.
> > …
> 
> This was fixed in 1.8.2.3 and 2.1.10, see Bug#931566
> 
> > 
> > This is expected, and I read apt-secure(8) how to deal with this.
> > However,  the man page simply says:
> > Since version 1.5 the user
> >must therefore explicitly confirm changes to signal that the
> >user is sufficiently prepared e.g. for the new major release of
> >the distribution shipped in the repository (as e.g. indicated
> >by the codename).
> > 
> > However, there is no link how to do this, what steps are necessary.
> > 
> > After a quick online search, I found that:
> > apt-get update --allow-releaseinfo-change
> > 
> > does the trick. 
> > 
> > Since this is a common use case, please describe it, e.g. in an
> > EXAMPLE section. Possibly examples from other frontends (like apt,
> > aptitutude, dselect, …) could be added as well.
> > 
> > This would greatly reduce the workload for a part time administrator
> > (and would avoid trusing "random" web sources).
> > 
> > Before sending I found this bug (#879786) and I think it would be a
> > really good idea handling this, the EXAMPLE section should be fairly
> > quickly written.
> 
> But why did you report a duplicate?

I have now realized that you did not, just used a full bug report
template to comment on an old bug so it *looked* like you reported
a new one. BTS is hard.

Also the subject changed, so conversation tracking in gmail broke,
but then I only looked at gmail after I looked in mutt, so well,
wouldn't have helped anyway. Could have expanded the thread in
notmuch, but was so sure it was a new one. Sigh!

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

Bug#1003399: Correct configuration of Exim

[karsten]

Hello Marc,

thank you for the response.

Am 09.01.22 um 19:05 schrieb Marc Haber:

Yes - the other possibility is to prevent upgrades of this package.


That is a decidedly bad idea. Exim is a huge suid binary (a design one
out never choose today, the concept was valid 25 years ago) and you need
security updates for that.


That's of course true.
Hopefully the version of Exim will not change until the configuration could be 
adapted.
Security updates will not need a new version of Exim within this stable 
distribution?


But there are additional other problems like spamassasin does not work any more,
so the configuration must be updated in many kinds.


Spamassassin in YOUR configuration doesn't work any more. My systems
using spamassassin via exiscan-ACL have not even ridden a bump during
the upgrade.


Maybe you are so kind to provide an example how you have included Spamassassin 
in Exim,
so that it will run with the packages of Debian 11?


Is there a default configuration for a private virtual mail server on dynamic 
IP's ?


Not that I am aware of. But if you roll yourself, you need to be able to
take care of it. I think there might be solutions that might be better
suited to your needs than Exim.


Indeed i am thinking that maybe Postfix is a better choice as MTA, because Exim 
seems to be
more and more complicated to configure?


btw, this triggers me, as "virtual mail" does not have a definition, it
leaves like ten way to interpret the task at hand.


I would define an virtual mail system as email server for different domains,
that can ideally be managed with entries in an database like Mariadb.

Greetings
karsten

Bug#879786: apt: Please explain in apt-secure(8) how to switch stable to oldstable

[Helge Kreutzmann]

Hello Julian,
On Mon, Jan 10, 2022 at 11:47:14AM +0100, Julian Andres Klode wrote:
> Control: notfound -1 2.2.4
> Control: merge 879786 -1

I read the man page on stable, i.e. 2.2.4. if I'm not mistaken, thus
the version. (The system in question is different, though).

> On Mon, Jan 10, 2022 at 10:30:00AM +0100, Helge Kreutzmann wrote:
> > Package: apt
> > Version: 2.2.4
> > Severity: wishlist
> > 
> > I just had to update a machine running (now) oldstable. It was last
> > updated before the release of bullseye, so it is not oldstabel.
> > 
> > Running apt-get update, I get lots of:
> > E: Repository 'http://security.debian.org buster/updates InRelease' changed 
> > its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this repository can 
> > be applied. See apt-secure(8) manpage for details.
> > …
> 
> This was fixed in 1.8.2.3 and 2.1.10, see Bug#931566

I just did this upgrade on an (now oldstable) machine and got the
described output (no longer reproducible). This machine is,
unfortunately, rarely updated.

> > This is expected, and I read apt-secure(8) how to deal with this.
> > However,  the man page simply says:
> > Since version 1.5 the user
> >must therefore explicitly confirm changes to signal that the
> >user is sufficiently prepared e.g. for the new major release of
> >the distribution shipped in the repository (as e.g. indicated
> >by the codename).
> > 
> > However, there is no link how to do this, what steps are necessary.
> > 
> > After a quick online search, I found that:
> > apt-get update --allow-releaseinfo-change
> > 
> > does the trick. 
> > 
> > Since this is a common use case, please describe it, e.g. in an
> > EXAMPLE section. Possibly examples from other frontends (like apt,
> > aptitutude, dselect, …) could be added as well.
> > 
> > This would greatly reduce the workload for a part time administrator
> > (and would avoid trusing "random" web sources).
> > 
> > Before sending I found this bug (#879786) and I think it would be a
> > really good idea handling this, the EXAMPLE section should be fairly
> > quickly written.
> 
> But why did you report a duplicate?

Apologies, after discovering the missing content in apt-secure(8) I
searched for the solution and intended to report this (hiding errors
is no good) as new bug. Then I saw #879786 and instead of reporting a
new bug, I send this to this bug, which seemed applicable.

So if apt in Testing/Unstable has an expanded apt-secure(8), then this
bug can be of course closed, otherwise the content should IMHO be
added there (it's probably just a few lines). I skimmed over #931566,
if this implies the error will not occur in the future, then of course
this could be closed without action (but then the error message
pointing to apt-secure(8) might need to be updated as well).

I personally would prefere an update of apt-secure(8).

Greetings

  Helge

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


signature.asc
Description: PGP signature

Bug#1003379: Not yet reproducible per Salsa-CI (Was: last-align: reproducible-builds: cpu-specific features embedded in manpages)

[Andreas Tille]

Hi Vagrant,

I applied your patch but according to Salsa-CI[1] last-align does
not yet build reproducibly.

Thanks a lot for the reproducible builds effort anyway

 Andreas.


[1] https://salsa.debian.org/med-team/last-align/-/jobs/2355125

-- 
http://fam-tille.de

Bug#1003448: mirror submission for ftp.psnc.pl

[PSNC mirrors team]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.psnc.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: PSNC mirrors team 
Country: PL Poland
Location: Poznań
Sponsor: Poznan Supercomputing and Networking Center https://www.psnc.pl/




Trace Url: http://ftp.psnc.pl/debian/project/trace/
Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp-master.debian.org
Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp.psnc.pl

Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

[Bastian Germann]

On 09.01.22 22:00, Fabio Fantoni wrote:

Il 08/01/2022 13:15, Bastian Germann ha scritto:

a.out should be excluded. Please do not forget to add a +dfsg suffix to the 
upstream version.
first time I do a repack in many years (if I remember correctly), seems ok from a fast look but if 
you want check is right probably is better, after I'll push also to the Debian/memtest86plus: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commits/debian/experimental


The repack is okay.



Missing copyright info in the following files:
bootsect.S
dmi.c
head.S
multiboot.[ch]
serial.h
smp.h


tried to do: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commit/1d24dd88c9f53110d20cc70769f6e0c7b63ef04d


but smp.h have only "partial" header, license I suppose can be one of the BSD but I'm not sure what 
to put exactly in d/copyright


can you tell me what I should do with smp.h entry and if there are other changes to do about other 
entries or are ok please?


smp.h is GPL-2 licensed. It falls back to the general project license (README). There is no hint for 
it being BSD licensed.


debian/patches/multiboot.patch has to have "License: GPL-2 and Expat" because multiboot.c is 
licensed under GPL-2 and only multiboot.h under Expat.

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[Paul Gevers]

Hi,

On 09-01-2022 23:22, David Prévot wrote:
This is important because some of these packages are currently allowed to migrate to testing without php-defaults (were it not for the autopgktest failure), and would 
break functionality in testing. We need to find out how to fix that.


I assume you pointed to logs in testing where php-defaults is pulled from unstable. Actually, php-defaults (source package, version 91, from unstable) builds php-xml 
(binary package, version 2:8.1+91) that correctly depends on php8.1-xml. According to the log (and that’s not a surprise given the error message you pointed out), the 
php-xml version actually installed in the autopkgtest environment is 2:7.4+76 (i.e. the version from testing, built from php-defaults 76). My question is: how is that 
possible? If the autopkgtest environment is supposed to pull (the binary packages built by) php-defaults, it looks like this failed.


The logs I pointed at were NOT for php-defaults, but for respectively 
php-amqp [1] and php-apcu [2], both of which aren't migrating because of 
this [3, 4]. But if these failures are *because* php-defaults from 
unstable isn't pulled in, there is a missing versioned dependency or 
breaks somewhere. Ondřej suggested breaks from src:php-defaults need to 
propagate to reverse (build) dependencies somehow, I think the easiest 
would be if this is covered by packages that provide the phpapi (as long 
as all relevant packages properly depend on that).


Paul

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-monolog/18158564/log.gz
[2] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-cache/18158566/log.gz

[3] https://qa.debian.org/excuses.php?package=php-amqp
[4] https://qa.debian.org/excuses.php?package=php-apcu


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003449: texlive-base: Reproducible configuration file ls-R: sychronise both variants of mktexlsr

[Roland Clobus]

Package: texlive-base
Version: 2021.20211217-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hello Debian TeX Task Force,

While working on the “reproducible builds” effort [1], I have noticed that the
output of the shell script and the output of the Perl script for 'mktexlsr'
produce different output, as seen in '/var/lib/texmf/ls-R'.

This was demonstrated in the Cinnamon live image for bookworm and sid [2], as
built on Jenkins [3].
If the Perl version is used as the last step in postinst (e.g. when invoked
from fmtutil), the output is not reproducible.

I've attached two patches, feel free to use either of them.

The file synchronise_mktexlsr_shell_and_perl.patch makes the output identical,
assuming that the Perl script is started with '--sort':
* The shell script occasionally outputs a double empty line, 'cat -s' removes
this
* The Perl script had an empty line before './:' and had a trailing empty line

The file synchronise_mktexlsr_shell_and_perl_and_remove_sort.patch contains the
same and additionally removes the functionality of the '--sort' flag (by always
sorting), while still allowing the flag to be passed.

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: https://tests.reproducible-builds.org/debian_live_build/cinnamon-
unstable.html
 [3]:
https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_cinnamon_sid


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 81 Jan  9 11:33 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 1769 Jan  9 11:33 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Sep  4 11:34 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Dec 18 00:07 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Dec 18 00:07 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep 10 06:56 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Dec 18 00:07 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Dec 18 00:07 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2862 Dec 20 17:56 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 15  2013 mktex.cnf
-rw-r--r-- 1 root root 475 Sep 10 06:56 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libpaper-utils 1.1.28+b1
ii  sensible-utils   

Bug#1003450: qemu-system: dns resolution does not work within the guest if the host have only nameserver in /etc/resolv.conf

[mc36]

Package: qemu-system
Version: 1:6.2+dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
i recently moved to an ipv6-only network for testing purposes...

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
i ceased ipv4 completely from my desktop for a while...

   * What was the outcome of this action?
for example "qemu-system-x86_64 -enable-kvm -cdrom
debian-11.2.0-amd64-netinst.iso" cannot complete mirror selection because dns
resolution does not work within the guest when resolt.conf have only ipv6
entries...

   * What outcome did you expect instead?
qemu should notice that it have only ipv6 recursive resolver available and use
that when forwarding guest's requests...

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


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

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

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:6.2+dfsg-1
ii  qemu-system-mips   1:6.2+dfsg-1
ii  qemu-system-misc   1:6.2+dfsg-1
ii  qemu-system-ppc1:6.2+dfsg-1
ii  qemu-system-sparc  1:6.2+dfsg-1
ii  qemu-system-x861:6.2+dfsg-1

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Bug#1003189: Giving up on packaging fiji

[Roland Mas]

I spent quite a few hours spent following dependencies, and it seems 
that Fiji is much more work than initially expected. Even building 
ImageJ2 requires a host of unpackaged modules, each with their own set 
of dependencies and so on. My gut feeling is that packaging Fiji would 
require tens or hundreds of Java modules first… which makes it 
unpractical. I therefore retitle this ITP to RFP.


Roland.

Bug#1002736: Giving up on packaging TomoJ

[Roland Mas]

I spent quite a few hours spent following dependencies, and it seems 
that TomoJ is much more work than initially expected, due to the 
dependency chain… which makes it unpractical. I therefore retitle this 
ITP to RFP.


Roland.

Bug#1003452: dpkg: missing alternatives for x-terminal-emulator

[Vincent Lefevre]

Package: dpkg
Version: 1.21.1
Severity: important

I notice that /usr/bin/mlterm is missing from the alternatives
for x-terminal-emulator:

cventin:~> update-alternatives --display x-terminal-emulator
x-terminal-emulator - manual mode
  link best version is /usr/bin/gnome-terminal.wrapper
  link currently points to /usr/bin/xterm
  link x-terminal-emulator is /usr/bin/x-terminal-emulator
  slave x-terminal-emulator.1.gz is /usr/share/man/man1/x-terminal-emulator.1.gz
/usr/bin/gnome-terminal.wrapper - priority 40
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/gnome-terminal.1.gz
/usr/bin/koi8rxterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/koi8rxterm.1.gz
/usr/bin/lxterm - priority 30
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/lxterm.1.gz
/usr/bin/urxvt - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/urxvt.1.gz
/usr/bin/uxterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/uxterm.1.gz
/usr/bin/xterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/xterm.1.gz

This was also the case for the xterm related programs until
I reinstalled xterm with dpkg -i.

Concerning mlterm and x-terminal-emulator, I can see in
the /var/log/alternatives.log* log files from the latest
mlterm upgrade until I noticed the issue:

update-alternatives 2021-08-16 16:27:55: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/mlterm 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/mlterm.1.gz
update-alternatives 2021-08-22 01:56:43: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-09-13 09:49:58: run with --remove x-terminal-emulator 
/usr/bin/urxvtcd
update-alternatives 2021-09-13 09:50:00: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/urxvt 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/urxvt.1.gz
update-alternatives 2021-09-27 14:08:32: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-11-23 13:29:02: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-12-06 13:49:47: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-12-06 13:49:47: link group x-terminal-emulator updated 
to point to /usr/bin/gnome-terminal.wrapper
update-alternatives 2022-01-05 11:01:08: run with --remove x-terminal-emulator 
/usr/bin/urxvtcd
update-alternatives 2022-01-05 11:04:12: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/urxvt 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/urxvt.1.gz

I wonder whether some upgrade of gnome-terminal or rxvt trashed the 
alternatives.

-- Package-specific info:

-- 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)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-1
ii  liblzma5 5.2.5-2
ii  libselinux1  3.3-1+b1
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.3.13
pn  debsig-verify  

-- no debconf information

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

Bug#712104: Buna dimineata,

[albertdoe . associate]

 Buna dimineata,

Sunt încântat să iau legătura cu dumneavoastră, în ceea ce privește
moștenirea (fondul) defunctului meu client cu care purtați același nume de
familie. Vă îndemn să reveniți la pentru mai multe detalii.

Avocatul Albet Doe.

Bug#1003453: Old bug is back, needs a rebuild.

[Roman Lebedev]

Package: qtcreator
Version: 6.0.1-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Looks like qtcreator (and iwyu/etc) need to be rebuilt again.
After some recent updates, qtcreator again shows errors
about certain C++ types not being known.

Roman


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

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

Versions of packages qtcreator depends on:
ii  clang-13   1:13.0.1~+rc1-1~exp4
ii  libc6  2.33-2
ii  libclang1-13   1:13.0.1~+rc1-1~exp4
ii  libdw1 0.186-1
ii  libelf10.186-1
ii  libgcc-s1  11.2.0-13
ii  libkf5syntaxhighlighting5  5.88.0-2
ii  libqt5concurrent5  5.15.2+dfsg-14
ii  libqt5core5a [qtbase-abi-5-15-2]   5.15.2+dfsg-14
ii  libqt5designer55.15.2-5+b1
ii  libqt5designercomponents5  5.15.2-5+b1
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5help55.15.2-5+b1
ii  libqt5network5 5.15.2+dfsg-14
ii  libqt5printsupport55.15.2+dfsg-14
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-9
ii  libqt5quick5   5.15.2+dfsg-9
ii  libqt5quickwidgets55.15.2+dfsg-9
ii  libqt5serialport5  5.15.2-2
ii  libqt5sql5 5.15.2+dfsg-14
ii  libqt5sql5-sqlite  5.15.2+dfsg-14
ii  libqt5svg5 5.15.2-4
ii  libqt5test55.15.2+dfsg-14
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libqt5xml5 5.15.2+dfsg-14
ii  libstdc++6 11.2.0-13
ii  libyaml-cpp0.7 0.7.0+dfsg-8
ii  libzstd1   1.4.8+dfsg-3
ii  qml-module-qtqml-models2   5.15.2+dfsg-9
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick25.15.2+dfsg-9
ii  qtchooser  66-2
ii  qtcreator-data 6.0.1-1

Versions of packages qtcreator recommends:
pn  clang-tidy 
ii  gdb10.1-2
ii  konsole [x-terminal-emulator]  4:21.08.2-1
ii  make   4.3-4.1
ii  qmlscene   5.15.2+dfsg-9
pn  qt5-doc
ii  qt5-qmltooling-plugins 5.15.2+dfsg-9
ii  qtbase5-dev-tools  5.15.2+dfsg-14
pn  qtcreator-doc  
ii  qtdeclarative5-dev-tools   5.15.2+dfsg-9
ii  qttools5-dev-tools 5.15.2-5+b1
ii  qttranslations5-l10n   5.15.2-2
ii  qtxmlpatterns5-dev-tools   5.15.2-3
ii  xterm [x-terminal-emulator]370-1

Versions of packages qtcreator suggests:
pn  clazy  
ii  cmake  3.22.1-1+b1
ii  g++4:11.2.0-2
ii  git1:2.34.1-1
ii  meson  0.60.3-1
pn  python3-pylsp  
ii  subversion 1.14.1-3+b2
ii  valgrind   1:3.18.1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAmHcJ2QACgkQCDw+u0oW
ieCsyhAAlol3UkpwhpKZf0vvdmoMCEc3sBzQYm2FfEQ3/3cwvTh5f+JIDSNTxYgV
3lIPFlMv7IKcc55p0e/MXFlBOHOG2q/bYVdTuf5h/cuAafX6Y2zr5m2TjFUNqffX
646hQS4rkoipR1r3l4ou5gomBpW+WoqEExnpc02/GfwxvVOTrQuZe8C1nXj2OlzZ
YFYOgCQBv6hdzxVcMTx7v4RQetLmJ/c+GegATqjLOEHdtr5D4KHRxkS/tbr/itQE
8wkaD0G4PRTRtGtDPJf53UTBD7rBLcz44HIWp5bn62dMO4epwY5EXnjNRt1aO9HO
7LxfcmAnC8w42tOB7T3wIEbw+qyPTCCaw8H4jYmVlQfptpGk7lG5CInqwfBGQLNb
JPzq7AVAmksssbeOyzxZbh6TzGqOrhJeCxdOqyRtn6/FR1uubIBco8U2Bzz7Tk12
dPse/gzvtrBky3fWeY1VQ83dhihsb5Jcg2lsaHW7eVA4n9EIdJTgMRdxgdOOW6XE
IYnad72iPzTQfTFUhGGiV2Fjc7sJxqTaXikHw1ZqjxNVnsi0+6LQ0Vbbq1rR4bDz
4hmKDjTCPZv5etaOxYTA678kLSbk9DYGqRLRmcn7I8KZmvvQIUAIOplP360IYCQy
iXDFFo9QGGNulF4E2Xuv6i3cqOR32hiqi6gBpfcjxsfeanndwNU=
=BDsi
-END PGP SIGNATURE-

Bug#1003451: Acknowledgement (mirror submission for mirror.ihost.md)

[Maxim Macovei]

Hello sirs.

Also I would like to know the procedure to receive access to Debian syncproxy

Thank you. 

Maxim Macovei 
Chief Executive Officer 
iHost | Chisinau, Moldova | 3 Tighina Street | www.ihost.md 
Office: +373 (22) 81 | Mobile: +373 78666999 | E-mail: m...@ihost.md 

Customer Service : +373 (22) 81 
24/7 Helpdesk : [ https://my.ihost.md/ | my.ihost.md ] 
Network Operations Center : n...@ihost.md 

Sent from webmail

- Original Message -
From: "Debian Bug Tracking System" 
To: "noc" 
Sent: Monday, January 10, 2022 1:54:06 PM
Subject: Bug#1003451: Acknowledgement (mirror submission for mirror.ihost.md)

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1003451: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003451.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 1003...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1003451: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003451
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1002073: src:tryton-modules-country: Tests fail with new iso-codes

[Stuart Prescott]

FYI a new version of pycountry has now been released upstream and it includes 
the iso-codes 4.8.0 data which presumably makes the tests fail upstream. tryton 
upstream seem to want to be reactive rather than proactive in dealing with this 
problem, so now is the time for them act, I guess.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1002223: simde: FTBFS: dh_auto_test: error: cd clang_test && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 6

[Nilesh Patra]

Control: severity -1 important

On Mon, 10 Jan 2022 15:53:01 +0530 Nilesh Patra  wrote:
> Andreas,
> 
> On Thu, 30 Dec 2021 09:07:08 +0100 Andreas Tille  wrote:
> > Control: tags -1 upstream
> > Control: forwarded -1 https://github.com/simd-everywhere/simde/issues/936
> > 
> > Hi,
> > 
> > I'm able to reproduce this issue in a local pbuilder chroot and have
> > forwarded the issue upstream.
> 
> Quoting Michael's message from our matrix channel:
> 
> | Michael Crusoe
> ||gargantua_kerr
> ||Michael Crusoe: would you have free cycles to look into this simde 
> FTBFS bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002223
> | We can skip testing on clang, since we only use GCC to build with SIMDe in 
> Debian
> 
> So I think you could simply do so and reduce the severity of the bug after a 
> re-title since it is not exactly a 'fix' but a workaround
> 
> What do you think?

As discussed offline, I did the above and just uploaded, and hence decreasing 
severity.

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#995995: RFS: nemo-compare/5.0.1-1 [ITP] -- Context menu comparison extension for Nemo file manager

[Bastian Germann]

On 09.01.22 17:00, Fabio Fantoni wrote:

@Bastian: is it good now?


Yes. But I am not sponsoring this, as already written in some Salsa comment.

Bug#998999: tix: missing required debian/rules targets build-arch and/or build-indep

[Ole Streicher]

Control: tags -1 + patch

Dear maintainer,

I have a package (ftools-fv) that depends on tix, which is scheduled for 
autoremoval on 2021/02/08. To avoid this, I prepared an NMU, which I am 
going to upload to DELAYED/7. This NMU just fixed this one issue 
(debdiff attached).


When looking into the package, I would recommend a few more small steps:

 * simplify d/rules using debhelper,
 * put the package under tcltk team maintainance
 * create a repository on Salsa to help maintaining it

Best regards

Olediff -Nru tix-8.4.3/debian/changelog tix-8.4.3/debian/changelog
--- tix-8.4.3/debian/changelog  2017-07-12 09:45:53.0 +0200
+++ tix-8.4.3/debian/changelog  2022-01-10 14:01:21.0 +0100
@@ -1,3 +1,10 @@
+tix (8.4.3-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/rules: Add build_indep and build_arch targets (Closes: #998999)
+
+ -- Ole Streicher   Mon, 10 Jan 2022 14:01:21 +0100
+
 tix (8.4.3-10) unstable; urgency=medium
 
   * added a symlink Tix8.4 -> Tix8.4.3, by postinst and postrm
diff -Nru tix-8.4.3/debian/rules tix-8.4.3/debian/rules
--- tix-8.4.3/debian/rules  2017-07-12 09:45:53.0 +0200
+++ tix-8.4.3/debian/rules  2022-01-10 13:56:06.0 +0100
@@ -35,6 +35,8 @@
 d_run  = debian/$(p_run)
 d_dev  = debian/$(p_dev)
 
+build_indep:
+build_arch: build
 build: build-static build-shared
 
 build-static: build-static-stamp

Bug#995788: [src:spread-sheet-widget] Updating the spread-sheet-widget Uploaders list

[Friedrich Beckmann]

I guess we will do a new release of pspp together with a new release of the 
spread-sheet-widget in sooner future.

Bug#1003454: py-lmdb: Non-functional d/watch and new versions available

[Bastian Germann]

Source: py-lmdb

py-lmdb scans GitHub releases but it should scan tags (which used to be shown 
in releases as well).
Please fix d/watch for the new GitHub web interface.

Please import the latest version to Debian.

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

[Leandro Cunha]

Hi,

On Sat, Jan 1, 2022 at 3:39 PM Andres Salomon  wrote:
>
> On Thu, 23 Dec 2021 01:49:53 -0500
> Andres Salomon  wrote:
>
> > On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > > On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> > >> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > >>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > >>> Exactly that.
> > >>>
> > >>> I'd suggest anyone who's interested in seeing Chromium supported
> > >>> to first update it in unstable (and then work towards updated in
> > >>> bullseye-security).
> > >> I started doing just that:
> > >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> > >> branches).

I am replying to the email with the chromium. It seems ok and ready
for upload. Thank you for your excellent work!

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#995995: RFS: nemo-compare/5.0.1-1 [ITP] -- Context menu comparison extension for Nemo file manager

[Fabio Fantoni]

Il 10/01/2022 14:01, Bastian Germann ha scritto:

On 09.01.22 17:00, Fabio Fantoni wrote:

@Bastian: is it good now?


Yes. But I am not sponsoring this, as already written in some Salsa 
comment.


from a fast look I saw your comments only in one xapp PR and was about 
the upload of other cinnamon components for new major version, now 
solved with permission to Nobert


about this and other new packages a DD with upload permission is needed, 
in the debian-cinnamon team there are Maxy and Marga but are not active 
anymore in the team, I tried some time ago to send them a mail (when 
there was problem about upload of packages for new version) but didn't 
replied


or your comment was about something else?

thanks for any reply



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003455: blt: FTBFS with -j4

[Bálint Réczey]

Source: blt
Version: 2.5.3+dfsg-4.1
Severity: important
Tags: ftbfs

Hi,

Building blt with higher parallelism level fails.
$ sbuild -d sid blt -j4
...
 mkdir /<>/debian/tmp/usr/share/man/mann
 mkdir /<>/debian/tmp/usr/share/man/man3
mkdir: cannot create directory
‘/<>/debian/tmp/usr/share/man/man3’: File exists
make[3]: *** [Makefile:50: mkdirs] Error 1
make[3]: *** Waiting for unfinished jobs
...

Cheers,
Balint

Bug#911997: git: Apply diff from Ubuntu

[Matthieu Baerts]

On 15/09/2019 04:55, Anders Kaseorg wrote:
> Never mind, it looks like I wasn’t added to the Debian upload ACL, so my 
> upload was rejected.
> 
> Anders
> 
> 

-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Bug#1003456: Excessive memory use with large binaries

[Ben Hutchings]

Package: lintian
Version: 2.114.0
Severity: important

I tried running lintian on a full amd64 build of linux.  lintian
allocated about 23 GiB of VM and then was OOM-killed before generating
any output.

I notice that  has no
information, probably because of this.

This is a regression in lintian, but I don't know how long ago it
happened.

Ben.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.16-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.37-10
ii  libtext-template-perl  1.60-1

-- no debconf information

Bug#911997: git: Apply diff from Ubuntu

[Matthieu Baerts]

Hello,

On 15/09/2019 04:55, Anders Kaseorg wrote:
> Never mind, it looks like I wasn’t added to the Debian upload ACL, so my 
> upload was rejected.

Sorry to jump into this discussion but it looks like the "git" package
in Ubuntu is still different from the one in Debian.

It looks like everything is/was ready but it was not applied for some
reasons.

Is there anything blocking to apply this diff from Ubuntu? Is there
something I can do to help?

Cheers,
Matt

PS: oops, it looks like I accidentally sent the previous draft of this
message, pressing "Send" instead of "Save", sorry for that... The week
is starting well... :)
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Bug#678962: lintian: [new-check] installs-initramfs-but-does-not-call-update

[Ben Hutchings]

On Mon, 25 Jun 2012 12:51:36 +0100 Dmitrijs Ledkovs
 wrote:
> Package: lintian
> Version: 2.5.9
> Severity: wishlist
> 
> If a binary package installs files in:
>  * /usr/share/initramfs/hooks
>  * /usr/share/initramfs/scripts
> 
> In postinst:
>  * the said binary or it's Depends:${binary:Version} packages must
>    have a call update-initramfs
[...]

It should now use dpkg-trigger and *not* run update-initramfs directly.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#1003456: Excessive memory use with large binaries

[Felix Lechner]

Hi,

On Mon, Jan 10, 2022 at 5:45 AM Ben Hutchings  wrote:
>
> lintian allocated about 23 GiB

Thanks for reporting this!

That is one of several mysterious results of what happened when I
simplified the code. It's possibly due to excessive regex usage,
although Perl usually catches that. Another possibility is an
accidental recursion in Lintian's copy of your package's file index.
Either way, I will shortly add helpful profiling information that you
will be able to examine on our website.

On the positive side, I broke Lintian's 23 original checks into 353
pieces (and counting). It makes issues much easier to monitor and
isolate.

Kind regards
Felix Lechner

Bug#1003457: noisy fwupd error messages with (disabled) TPM 1.2

[Sergio Gelato]

Package: fwupd
Version: 1.5.7-4

fwupd[150732]: 
ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:110:Tss2_Sys_ExecuteFinish() 
Unsupported device. The device is a TPM 1.2
fwupd[150732]: 
ERROR:esys:src/tss2-esys/api/Esys_Startup.c:216:Esys_Startup_Finish() Received 
a non-TPM Error
fwupd[150732]: ERROR:esys:src/tss2-esys/api/Esys_Startup.c:78:Esys_Startup() 
Esys Finish ErrorCode (0x00080001)
fwupd[150732]: 05:40:45:0110 FuEngine failed to add device (null): 
failed to initialize TPM

The hardware is what it is (old, vendor no longer provides BIOS updates, fwupd 
may still be useful for firmware updates on peripherals), but surely fwupd 
could be handling this more elegantly?

Possibly relevant information from the kernel on this system:

kernel: [   10.755156] tpm_tis 00:07: 1.2 TPM (device-id 0xB, rev-id 16)
kernel: [   10.803696] tpm tpm0: TPM is disabled/deactivated (0x7)

Bug#1003458: kleopatra: Cannot sign only

[rpnpif]

Package: kleopatra
Version: 4:18.08.3-1
Severity: normal

Dear Maintainer,

I clicked on Sign/Encrypt button.
I selected a file.
I deselected (disabled) Encrypt* keeping only Sign as.
I deselected (disabled) Encrypt / Sign each file separately.
I clicked on the Sign / Encrypt button.
The message "filetosign -> filetosign.gpg Signing and encryption succeeded".

The file is encrypted and signed and not only signed as requested.

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

Kernel: Linux 5.10.0-0.bpo.9-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kleopatra depends on:
ii  dirmngr   2.2.27-2~bpo10+1
ii  gnupg 2.2.27-2~bpo10+1
ii  gpgsm 2.2.27-2~bpo10+1
ii  libassuan02.5.2-1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libgpg-error0 1.35-1
ii  libgpgmepp6   1.12.0-6
ii  libkf5codecs5 5.54.0-1
ii  libkf5configcore5 5.54.0-1+deb10u1
ii  libkf5configgui5  5.54.0-1+deb10u1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5itemmodels5 5.54.0-1
ii  libkf5kcmutils5   5.54.0-1
ii  libkf5libkleo54:18.08.3-2
ii  libkf5mime5abi1   18.08.3-1
ii  libkf5notifications5  5.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqgpgme71.12.0-6
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u4
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libstdc++68.3.0-6
ii  paperkey  1.6-1
ii  pinentry-qt   1.1.0-2

kleopatra recommends no packages.

kleopatra suggests no packages.

-- no debconf information

Bug#678962: lintian: [new-check] installs-initramfs-but-does-not-call-update

[Ben Hutchings]

On Mon, 2022-01-10 at 14:38 +0100, Ben Hutchings wrote:
> On Mon, 25 Jun 2012 12:51:36 +0100 Dmitrijs Ledkovs
>  wrote:
> > Package: lintian
> > Version: 2.5.9
> > Severity: wishlist
> > 
> > If a binary package installs files in:
> >   * /usr/share/initramfs/hooks
> >   * /usr/share/initramfs/scripts
> > 
> > In postinst:
> >   * the said binary or it's Depends:${binary:Version} packages must
> >     have a call update-initramfs
> [...]
> 
> It should now use dpkg-trigger and *not* run update-initramfs directly.

Sorry, that's wrong, it should include a triggers control file which
will look something like:

# Triggers added by dh_installinitramfs/13.3.4
activate-noawait update-initramfs

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#1003307: restfuldb: FTBFS against sqlite3 3.37 or newer

[Dan Bungert]

On Mon, Jan 10, 2022 at 12:06:31PM +0200, Andrius Merkys wrote:
> On 2022-01-08 00:02, Dan Bungert wrote:
> > When built against sqlite 3.37 or newer, the build will fail in test.
> > tests/cases/Database.pm_001.sh:FAILED:
> > 2c2
> > <   'image' => 'blob'
> > ---
> > >   'image' => 'BLOB'
> Your workaround works fine, but it may hide possible future regressions where
> letter case is actually important. Since I am one of the upstream developers
> I will see how this could be fixed upstream.

Yes, that's entirely sensible.  I came to a similar conclusion when I realized
that the 'create table' statements in the premade db files needed an update to
be compatible with both 3.37 and 3.36.

-Dan

Bug#1003456: Excessive memory use with large binaries

[Ben Hutchings]

On Mon, 2022-01-10 at 05:56 -0800, Felix Lechner wrote:
> Hi,
> 
> On Mon, Jan 10, 2022 at 5:45 AM Ben Hutchings  wrote:
> > 
> > lintian allocated about 23 GiB
> 
> Thanks for reporting this!
> 
> That is one of several mysterious results of what happened when I
> simplified the code. It's possibly due to excessive regex usage,

I'm not aware of regex processing ever requiring lots of memory.

> although Perl usually catches that. Another possibility is an
> accidental recursion in Lintian's copy of your package's file index.
> Either way, I will shortly add helpful profiling information that you
> will be able to examine on our website.

I don't really want to examine it, I want you or some other lintian
contributor to fix it.

> On the positive side, I broke Lintian's 23 original checks into 353
> pieces (and counting). It makes issues much easier to monitor and
> isolate.

OK, but it's no longer working for me or probably anyone working on a
larger package.

I just tested with some older releases.  The performance got worse
between buster and bullseye, but the bullseye version is still usable
for me (~ 1.3 GiB VM used, 17 min wallclock time).  So the regression
is since bullseye.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#984063: itk libtiff test issues (Was: Bug#984063)

[Adrian Bunk]

On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote:
> Hi there,
> 
> About the build error I caught with itk4 on , this
> looks to be caused by a gcc bug in the headers files [1],
> causing failures to build source code including  with
> clang, compiler which is in use through castxml, which in turn
> is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
> not affected as wrappers are not built anymore on its side, so
> disabling wrappers for itk4 too might be a viable option while
> #1000398 is being worked on (to at least reproduce the tiff test
> failures).  The build error may otherwise solve by itself with
> an upcoming gcc version.
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398
>...

This bug has been fixed in the meantime.

> Kind Regards,

cu
Adrian

Bug#1001685: mailman: CVE-2021-44227 and updated fix for CVE-2021-42097

[Thomas Arendsen Hein]

Hi Salvatore,

* Salvatore Bonaccorso  [20220106 06:51]:
> Friendly ping back on this: there are as said pending versions for the
> next point release in proposed-updates. Would you be able to test
> those so we can make sure the packages for buster have seen some real
> situation testing?

Sorry, unfortunately I don't have a buster system with mailman2
available. Due to a 3rd-party dependency we're still running stretch.
I've just checked, there is no updated mailman package in
stretch-proposed-updates, which I would happily test for you.

Regards,

Thomas

-- 
Thomas Arendsen Hein 
OpenPGP key: https://intevation.de/~thomas/thomas_pgp.asc (0xD45DE28FF3A2250C)
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Bug#944667: firejail-profiles: ansible cannot run ssh with default profile

[Reiner Herrmann]

Control: tags -1 - moreinfo unreproducible
Control: forward -1 https://github.com/netblue30/firejail/issues/4440

While trying to again reproduce this issue I'm now also having problems
with ansible when ssh is firejailed.
It's not the issue from the original post, which I think was related
to known_hosts, but the problem is now that ansible starts ssh
with ControlMaster/ControlPath which keeps an ssh process running in the
jail (in the background).
Because of this ansible "hangs" at the first step because the "firejail
ssh" process does not terminate.

There are some related upstream issues about this:
 https://github.com/netblue30/firejail/issues/1518
 https://github.com/netblue30/firejail/issues/3491
 https://github.com/netblue30/firejail/issues/4440

Might be fixed/worked-around by https://github.com/netblue30/firejail/pull/4635
in the next release.


signature.asc
Description: PGP signature

Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

[Andreas Tille]

Am Mon, Jan 10, 2022 at 05:25:59PM +0200 schrieb Adrian Bunk:
> On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote:
> > Hi there,
> > 
> > About the build error I caught with itk4 on , this
> > looks to be caused by a gcc bug in the headers files [1],
> > causing failures to build source code including  with
> > clang, compiler which is in use through castxml, which in turn
> > is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
> > not affected as wrappers are not built anymore on its side, so
> > disabling wrappers for itk4 too might be a viable option while
> > #1000398 is being worked on (to at least reproduce the tiff test
> > failures).  The build error may otherwise solve by itself with
> > an upcoming gcc version.
> > 
> > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398
> >...
> 
> This bug has been fixed in the meantime.
> 
> > Kind Regards,
> 
> cu
> Adrian
> 
> 

-- 
http://fam-tille.de

Bug#1001451: Candidate script updates

[Salvatore Bonaccorso]

Hi Neil,

On Thu, Jan 06, 2022 at 02:13:38PM +, Neil Williams wrote:
> Hi Salvatore,
> 
> On Mon, 20 Dec 2021 12:30:36 +0100 Salvatore Bonaccorso
>  wrote:
> > Hi Neil,
> >
> > Btw, if you want "real" cases why not to do automatic merges:
> > https://tracker.debian.org/news/1287752/accepted-epiphany-browser-412-1-source-into-unstable/
> > typo in CVE, and
> > https://tracker.debian.org/news/1287534/accepted-bluez-562-1-source-into-unstable/
> > where one CVE was actually not really fixed.
> 
> So for that epiphany tracker, there is a typo in the d.changelog -
> the automated link for CVE-2021-4508 is a 404.
> 
> I've updated the script to catch this and report the error. From the
> security-tracker source-package page for epiphany, it looks like the
> d.changelog entry should be CVE-2021-45088 - a simple typo to omit the
> final repeated digit.
> 
> Currently, I'm handling this by advising that the script is re-run
> using the offline support and a corrected list of CVE IDs.
> 
> This also adds a --force-version option to the offline support, in case
> sid has moved ahead of the fixed version by the time the CVE list is
> updated.

Ack, this works indeed in this case as the CVE-2021-4508 does not
exist (yet). But in other cases typos are e.g. just wapping a number
or misstype the year, or other typos, which lead to an existing CVE.
So basically this all really boils down to, people working on
security-tracker trying as much as possible, in the human limits :),
to do a diligent work as possible.

But if you spot an easy or obvious to detect case which the script can
warn of, then this can be helpful! After all you are trying to write
up scripts which should help the workflow.

> Should the script also advise that a (normal|minor) bug is filed
> against the source-package to fix the d.changelog (retrospectively or
> in the next changelog entry?) or is it sufficient that the
> security-tracker has the correct information?

it is suficient thath the tracker will have correct information, IMHO.
Basically there are as well different policies in teams on "touching
old changelog entries". For instance for the kernel-team, now
switching hat, we almost never touch an old entry. What has been
written, has been written (we e.g. do not add retrospecively for
instance a CVE id, or change a CVE id which was rejected, and assigned
a new CVE).

> For the bluez case, the 5.62-1 upload would update both CVEs. My
> expectation is that finding out that CVE-2021-41229 was not fixed would
> result in a separate change to data/CVE/list to remove the fixed
> version of 5.62-1. Then when 5.62-2 as uploaded, CVE-2021-41229 would
> be marked as fixed in 5.62-2 as normal. In case a separate change is
> not made to data/CVE/list, I've adjusted the script so that if the fix
> version is older than the version from the retrieved changes entry, the
> CVE is updated to show the newer version. i.e. 5.62-1 would be changed
> to 5.62-2. This introduces a dependency on python3-apt to be able to
> get the correct version comparison support, hopefully that is OK.
> (python3-debian doesn't have dpkg --compare-versions type support.)

Hmm not sure. In if we can say that in general. In the particular
bluez case I spotted that while reviewing the entry, because I had in
the back of my mind still some information about the triage of the
bluez issues, knowing that one was fixed in a new upstream version and
the other not yet, which puzzled me then that both were mentioned, and
so i double checked the source again, confirming that no cherry-picked
patch was applied. So probably yes, if I would not have had this
information then *probably* i would have initially marked wrongly both
CVEs as fixed in 5.62-1. But again this boils down in people doing
this review work to be as carefull as possible, still acknowledging we
do a lot of mistakes which hopefully can be spotted by peer review of
commits (at least jmm/Moritz reviews most of the commits done by
another team member, so we have some backup of each other).

What does that mean for the above: having that support to adjust the
version would be ok, but i expect here that hopefully the 5.62-1 wrong
marking would live in the tracker only for a very short time after a
peer review has spotted a possible mistake.

> It's hard to see how to best test these scripts properly on an ongoing
> basis. The "correct" output of each script depends entirely on the
> current state of data/CVE/list and the setup_paths support gets in the
> way of using a static CVE list in a test directory.
> 
> I yet may push all of the non-argparse code into a lib.python.sectracker
> module to at least have some way to test individual functions with
> carefully mangled static copies of data/CVE/list content.

In general I would find it perfect if we can have a sort of testsuite
or CI for the code part indeed of the security-tracker. In fact the
situation now without any tests has potential for many breackages when
one want to fix so

Bug#1003378: More data for Bug 1003378

[Patrick Matthäi]

Hi,

@JB:
Maybe you have got an idea?
Full report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003378

On 09.01.22 07:37, Kingsley G. Morse Jr. wrote:

I tried again.

This time, I did

 $ aptitude install kde-standard

and then tried adding the same .mp4 file to
Kdenlive's project bin.

Kdenlive didn't crash this time, but it

 1.) openned an orange error window that says

 "Cannot open file
 /home/kingsley/doc/movies/public_domain/
 Twelve+Days+of+Christmas+(Instrumental)+(feat.
 +Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"

and

 2.) printed this on the console

 === REG FOCUS:  true
 qml: item not found
 === REG FOCUS:  false
 /// starting to add bin clips
 /// found list 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 /// creatclipsfromlist 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 true "-1"
 /// createClipFromFile 
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 "-1"
 === GOT DROPPED MIME:  "video/mp4"
 /// final xml "\n /home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"
 == STARTING TASK FOR:  4
 /// creatclipsfromlist return false
 STARTING LOAD TASK FOR:  
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"

 :::
 QFSFileEngine::open: No file name specified
 // WARNING EMPTY CLIP HASH:
 == READY FOR TASK DELETION ON:  4
 = REMOVING MASTER PRODUCER; CURRENT COUNT:  0
 :::

You can try to replicate it with the video at

 https://invidious.snopyta.org/watch?v=F-b6WYUHBWY

Download the version...

 "audio/mp4 @ 131.141k audio only"

I wonder if a bug is in

 creatclipsfromlist

or

 createClipFromFile

Thanks,
Kingsley


I couldnt reproduce your issue. I tried:

* My current testing state with kdenlive 21.12.0 => working

* Testing and just upgrade kdenlive to 21.12.1 => working

* Full upgrade to unstable => working

* Also with your filename full of special chars => working


"kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not 
found
/// found list 
(QUrl("file:///home/me/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
/// creatclipsfromlist 
(QUrl("file:///home/me/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4")) 
true "-1"
/// createClipFromFile 
"/home/me/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4" 
"-1"

=== GOT DROPPED MIME:  "video/mp4"
/// final xml "\n name=\"resource\">/home/me/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"

== STARTING TASK FOR:  2
STARTING LOAD TASK FOR: 
 "/home/me/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"


:::
/// creatclipsfromlist return false
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 3304, 
resource id: 18874443, major code: 40 (TranslateCoords), minor code: 0

### ProjectClip::setproducer
### ClipController::updateProducer
### ClipController::addmasterproducer
=
READY FOR THUMB ClipType::AV "


Does it work for you again if you only downgrade kdenlive and 
kdenlive-data again to 21.12.0-1?




OpenPGP_0x12D9B04A90CBD8E4.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#919619: network-manager: breaking configuration when updating

[Diederik de Haas]

On 05 Feb 2021 12:37:04 +0100 Michele Cane  wrote:
> Package: network-manager
> 
> Reading on the previous echanges tehre was a mention of NM not developing/
> maintaining iwd backend but I see that they have recent commits (Nov 2020)
> 
> It would be great if we could reconsider this discussion, especially if the 
> iwd backend in NM is being debeloped.

I'm using NM with iwd too and I'd like to give a +1 to this feature request.

The previous mail is now almost a year old and it's almost 3 years since the 
bug has been filed. Since then a lot has changed.

- 22 commits in 2021 in src/core/devices/wifi/nm-device-iwd.c in the upstream 
repo, so it doesn't look abandoned to me
- popularity has risen to 408/347 and doesn't include me (and likely others 
who haven't enabled/installed popularity-contest)
- several new releases of iwd
- Bullseye has been released and there's still plenty of time to fix possible 
issues *if* they occur, before Bookworm gets released, so now is an ideal time 
to introduce this feature

Cheers,
  Diederik

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

Bug#1002286: Acknowledgement (transition: Gazebo + Ignition libraries)

[Jose Luis Rivero]

I have received no negative feedback or blockers in the last 20 days, I'm
afraid that we can not wait
much longer since this bug is blocking others (like Dartsim transition). My
plan would be to proceed
with the plan in the next few days unless feedback appears in the next 48
hours.

Thanks!

Bug#1003460: ITP: golang-github-mdlayher-socket -- low-level network connection type to provide asynchronous I/O

[Benjamin Drung]

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

* Package name: golang-github-mdlayher-socket
  Version : 0.1.1-1
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/socket
* License : Expat
  Programming Lang: Go
  Description : Package socket provides a low-level network
connection type which integrates with Go's runtime network poller to
provide asynchronous I/O and deadline support. MIT Licensed.

 The socket package provides a low-level network connection type which
 integrates with Go's runtime network poller to provide asynchronous 
 I/O and deadline support.
 .
 This package focuses on UNIX-like operating systems which make use of
 BSD sockets system call APIs. It is meant to be used as a foundation
 for the creation of operating system-specific socket packages, for 
 socket families such as Linux's AF_NETLINK, AF_PACKET, or AF_VSOCK.
 This package should not be used directly in end user applications.
 .
 Any use of package socket should be guarded by build tags, as one
 would also use when importing the syscall or golang.org/x/sys 
 packages.

golang-github-mdlayher-socket is a new dependency for
https://github.com/mdlayher/netlink v1.5.0 (which in turn is a
dependency for prometheus-node-exporter).

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#919619: [Pkg-utopia-maintainers] Bug#919619: network-manager: breaking configuration when updating

[Michael Biebl]

On 10.01.22 17:36, Diederik de Haas wrote:

On 05 Feb 2021 12:37:04 +0100 Michele Cane  wrote:

Package: network-manager

Reading on the previous echanges tehre was a mention of NM not developing/
maintaining iwd backend but I see that they have recent commits (Nov 2020)

It would be great if we could reconsider this discussion, especially if the
iwd backend in NM is being debeloped.


I'm using NM with iwd too and I'd like to give a +1 to this feature request.

The previous mail is now almost a year old and it's almost 3 years since the
bug has been filed. Since then a lot has changed.

- 22 commits in 2021 in src/core/devices/wifi/nm-device-iwd.c in the upstream
repo, so it doesn't look abandoned to me
- popularity has risen to 408/347 and doesn't include me (and likely others
who haven't enabled/installed popularity-contest)
- several new releases of iwd
- Bullseye has been released and there's still plenty of time to fix possible
issues *if* they occur, before Bookworm gets released, so now is an ideal time
to introduce this feature


You can use iwd with NM.
The package is still built with support for it
https://salsa.debian.org/utopia-team/network-manager/-/blob/debian/master/debian/rules#L43



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003461: Missing syslinux-utils package breaks network booting of live ISO images

[Sébastien Béhuret]

Package: live-boot
Severity: important
Version: 1:20210208

Dear Maintainers,

Debian Live project includes code to detect Syslinux's MEMDISK and enable
network booting of live ISO images. This is however conditioned by the
existence of the binary file /usr/bin/memdiskfind, which is provided by
package syslinux-utils. This package is currently not included in any of
the Debian Live ISO images, which breaks network booting.

Suggested fix: Include package syslinux-utils in Debian Live builds, or at
least binary file /usr/bin/memdiskfind.

Current code from Debian Live project is reproduced below for reference:

[1/2] File /usr/share/initramfs-tools/hooks/live from package
live-boot-initramfs-tools:

# Program: memdisk
if [ -x /usr/bin/memdiskfind ]
then
[ "${QUIET}" ] || echo -n " memdisk"
 copy_exec /usr/bin/memdiskfind
 manual_add_modules phram
 manual_add_modules mtdblock
fi

[2/2] File /lib/live/boot/9990-main.sh from package live-boot:

if [ -x /usr/bin/memdiskfind ]
then
if MEMDISK=$(/usr/bin/memdiskfind)
then
# We found a memdisk, set up phram
# Sometimes "modprobe phram" can not successfully create /dev/mtd0.
# Have to try several times.
max_try=20
while [ ! -c /dev/mtd0 ] && [ "$max_try" -gt 0 ]; do
modprobe phram "phram=memdisk,${MEMDISK}"
sleep 0.2
if [ -c /dev/mtd0 ]; then
break
else
rmmod phram
fi
max_try=$((max_try - 1))
done

# Load mtdblock, the memdisk will be /dev/mtdblock0
modprobe mtdblock
fi
fi

Many thanks and kind regards,
Sebastien

Bug#1002286: Acknowledgement (transition: Gazebo + Ignition libraries)

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-01-10 17:41:17, Jose Luis Rivero wrote:
> I have received no negative feedback or blockers in the last 20 days, I'm
> afraid that we can not wait
> much longer since this bug is blocking others (like Dartsim transition). My
> plan would be to proceed
> with the plan in the next few days unless feedback appears in the next 48
> hours.

These transitions are self-contained and gazebo is not in testing. I
think you can just go ahead with the uploads.

Cheers

> 
> Thanks!

-- 
Sebastian Ramacher

Bug#1003404: Acknowledgement (debian-i18n: Dead keys functionality associated to some keyboards is not working)

[Parodper]

Hi,

Just a little note, please describe the problem in plain text and 
without inlining images, or rename the images and reference them from 
inside the text. Check https://bugs.debian.org/1003404 to see how it 
looks like to other people.

Bug#919619: [Pkg-utopia-maintainers] Bug#919619: network-manager: breaking configuration when updating

[Diederik de Haas]

On Monday, 10 January 2022 18:05:51 CET Michael Biebl wrote:
> On 10.01.22 17:36, Diederik de Haas wrote:
> 
> > On 05 Feb 2021 12:37:04 +0100 Michele Cane 
> > wrote:
> > 
> >> Package: network-manager
> >>
> >> Reading on the previous echanges tehre was a mention of NM not
> >> developing/
> >> maintaining iwd backend but I see that they have recent commits (Nov
> >> 2020)
> >>
> >> It would be great if we could reconsider this discussion, especially if
> >> the iwd backend in NM is being debeloped.
> > 
> > I'm using NM with iwd too and I'd like to give a +1 to this feature
> > request.
 
> > The previous mail is now almost a year old and it's almost 3 years since
> > the bug has been filed. Since then a lot has changed.
> > 
> > - 22 commits in 2021 in src/core/devices/wifi/nm-device-iwd.c in the
> > upstream repo, so it doesn't look abandoned to me
> > - popularity has risen to 408/347 and doesn't include me (and likely
> > others who haven't enabled/installed popularity-contest)
> > - several new releases of iwd
> > - Bullseye has been released and there's still plenty of time to fix
> > possible issues *if* they occur, before Bookworm gets released, so now
> > is an ideal time to introduce this feature
> 
> You can use iwd with NM.

Yes, otherwise I wouldn't be able to say "I'm using NM with iwd".

> The package is still built with support for it
> https://salsa.debian.org/utopia-team/network-manager/-/blob/debian/master/de
> bian/rules#L43
 
But I still can't remove wpasupplicant as it isn't defined as an alternative 
(backend) for networkmanager.
I'd like to remove wpasupplicant as I have no use for it and *either* iwd OR 
wpasupplicant should be used to make the wireless connection, but not both.

If the Depends was changed to "wpasupplicant | iwd" I would be able to get rid 
of wpasupplicant.

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

Bug#1003462: RM: manpages-hu -- RoM; abandoned upstream

[GCS]

Package: ftp.debian.org
Severity: normal
Usertags: rm

Hi,

This package contains very old manpages and very old translation
attempts. Original translators are MIA, new ones are not existent.
Even the format used for translation is outdated.

Please remove it from the archives.

Regards,
Laszlo/GCS

Bug#1003463: Functionally broken with current PHP

[Roman Lebedev]

Package: arcanist
Version: 0~git20200925-2
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I *think* this has been fixed upstream in
https://github.com/phacility/arcanist/commit/3626582354e4fc62191927a80b274ec71284cb77
and
https://github.com/phacility/arcanist/commit/b50a646a3f49c8b842cf0764c59ea2c38c2f9567

llvm-project$ /usr/bin/arc patch --nobranch D116766
PHP Deprecated:  Function libxml_disable_entity_loader() is deprecated in 
/usr/share/arcanist/support/init/init-script.php on line 92

Deprecated: Function libxml_disable_entity_loader() is deprecated in 
/usr/share/arcanist/support/init/init-script.php on line 92
PHP Fatal error:  Uncaught Exception: Error while loading file 
"/usr/share/arcanist/src/object/Phobject.php": Return type of 
Phobject::rewind() should either be compatible with Iterator::rewind(): void, 
or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in /usr/share/arcanist/src/init/lib/PhutilBootloader.php:275
Stack trace:
#0 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(207): 
PhutilBootloader->executeInclude()
#1 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(422): 
PhutilBootloader->loadLibrarySource()
#2 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(277): 
PhutilSymbolLoader->loadSymbol()
#3 /usr/share/arcanist/src/init/init-library.php(23): 
PhutilSymbolLoader->selectAndLoadSymbols()
#4 /usr/share/arcanist/src/filesystem/Filesystem.php(18): __phutil_autoload()
#5 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(247): 
include_once('...')
#6 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(207): 
PhutilBootloader->executeInclude()
#7 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(422): 
PhutilBootloader->loadLibrarySource()
#8 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(277): 
PhutilSymbolLoader->loadSymbol()
#9 /usr/share/arcanist/src/init/init-library.php(23): 
PhutilSymbolLoader->selectAndLoadSymbols()
#10 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(97): 
__phutil_autoload()
#11 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(21): 
PhutilBootloader->registerLibrary()
#12 /usr/share/arcanist/src/init/init-library.php(70): 
PhutilBootloader::newLibrary()
#13 /usr/share/arcanist/support/init/init-script.php(96): require_once('...')
#14 /usr/share/arcanist/support/init/init-script.php(115): 
__arcanist_init_script__()
#15 /usr/share/arcanist/support/init/init-arcanist.php(3): require_once('...')
#16 /usr/share/arcanist/bin/arc(10): require_once('...')
#17 {main}
  thrown in /usr/share/arcanist/src/init/lib/PhutilBootloader.php on line 275

Fatal error: Uncaught Exception: Error while loading file 
"/usr/share/arcanist/src/object/Phobject.php": Return type of 
Phobject::rewind() should either be compatible with Iterator::rewind(): void, 
or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in /usr/share/arcanist/src/init/lib/PhutilBootloader.php:275
Stack trace:
#0 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(207): 
PhutilBootloader->executeInclude()
#1 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(422): 
PhutilBootloader->loadLibrarySource()
#2 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(277): 
PhutilSymbolLoader->loadSymbol()
#3 /usr/share/arcanist/src/init/init-library.php(23): 
PhutilSymbolLoader->selectAndLoadSymbols()
#4 /usr/share/arcanist/src/filesystem/Filesystem.php(18): __phutil_autoload()
#5 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(247): 
include_once('...')
#6 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(207): 
PhutilBootloader->executeInclude()
#7 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(422): 
PhutilBootloader->loadLibrarySource()
#8 /usr/share/arcanist/src/symbols/PhutilSymbolLoader.php(277): 
PhutilSymbolLoader->loadSymbol()
#9 /usr/share/arcanist/src/init/init-library.php(23): 
PhutilSymbolLoader->selectAndLoadSymbols()
#10 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(97): 
__phutil_autoload()
#11 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(21): 
PhutilBootloader->registerLibrary()
#12 /usr/share/arcanist/src/init/init-library.php(70): 
PhutilBootloader::newLibrary()
#13 /usr/share/arcanist/support/init/init-script.php(96): require_once('...')
#14 /usr/share/arcanist/support/init/init-script.php(115): 
__arcanist_init_script__()
#15 /usr/share/arcanist/support/init/init-arcanist.php(3): require_once('...')
#16 /usr/share/arcanist/bin/arc(10): require_once('...')
#17 {main}
  thrown in /usr/share/arcanist/src/init/lib/PhutilBootloader.php on line 275



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /

Bug#1003465: src:ucommon: fails to migrate to testing for too long: FTBFS on armel, armhf, i386, mipsel and s390x

[Paul Gevers]

Source: ucommon
Version: 7.0.0-19
Severity: serious
Control: close -1 7.0.0-20
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ucommon has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source on several architectures. In the first log it seems symbols are 
being dropped (or different on different architectures).


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003466: src:fftw: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: fftw
Version: 2.1.5-4.2
Severity: serious
Control: close -1 2.1.5-5
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 999821

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:fftw has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003404: Acknowledgement (debian-i18n: Dead keys functionality associated to some keyboards is not working)

[Ramiro Arias-Amaya]

Good morning
Please tell me if this layout comply with your requirements.

I want to add further information about the problem I reported.
The image below shows the computer that I reported as:

PC 2. Debian 11 32-bit. Spanish keyboard. Setup as Spanish (dead tilde)

This computer (a laptop) has an external Spanish keyboard.
The laptop's keyboard is a US English keyboard.
This explains why there are two keyboards layout set up.
See image

[neeihkenbeldlaji.png

(image/png, inline)]

If I click on Behavior tab and want to type *música* I obtain:

[hedcfgmdenbmedcf.png

(image/png, inline)]


On the other hand Panel 1 does not know that there is a Spanish (dead
tilde) keyboard setup in the OS,
as you can see in the image below.

[pjabaaalepficmop.png

(image/png, inline)]


Accidentally I found why the OS shows English - English (US) on panel 1.
It is because IBus Preferences  (Applications > Settings > IBus
Preferences) contains what is shown below:

[dglomjbgdlkohiig.png

(image/png, inline)]


A temporary solution is to add the appropriate layouts in IBus and
remove the original one, as shown below:

[gicijhnmddfjcbig.png

(image/png, inline)]



Now panel 1 shows the correct keyboard layouts, being Spanish (dead
tilde) the main layout:

[ljamjphlkkljeakd.png

(image/png, inline)]



Now I can use any application and type using the dead keys funtionality
as shown below:

[ihbajlogefeipfkd.png

(image/png, inline)]



I said this is a temporary solution because I had trouble installing
Debian 11 32-bit (the problem is not present in Debian 11 64-bit),
because the installer has this flaw and I realized something was wrong
with the installer regarding the keyboard layout but I could not tell at
the moment what was going on. Of course I realized that the best at
installation time was to let the keyboard with the default layout:
English US.

On top of that I accidentally found the solution. I think that a user
installing Debian for the first time would not think that the problem
can be fixed tweaking IBus.

Anyway, you can count on me if you need anymore information about this.

Cheers
Ramiro

Bug#998999: tix: missing required debian/rules targets build-arch and/or build-indep

[Georges Khaznadar]

Dear Ole, thank you for your work!

I shall upload the new package shortly, with some enhancements among
your propositions, see below:

Ole Streicher a écrit :
> Control: tags -1 + patch
> 
> Dear maintainer,
> 
> I have a package (ftools-fv) that depends on tix, which is scheduled for
> autoremoval on 2021/02/08. To avoid this, I prepared an NMU, which I am
> going to upload to DELAYED/7. This NMU just fixed this one issue (debdiff
> attached).
> 
> When looking into the package, I would recommend a few more small steps:
> 
>  * simplify d/rules using debhelper,
 not done currently

>  * put the package under tcltk team maintainance
 if you are part of the tcltk team maintainance, please feel free to
 move the package to the right section of salsa.debian.org

>  * create a repository on Salsa to help maintaining it
 the repository is created at https://salsa.debian.org/georgesk/tix,
 and the package is up to date there, in version 8.4.3-11
 The file debian/changelog bears a few other notifications.

Best regards,   Georges.

> 
> Best regards
> 
> Ole

> diff -Nru tix-8.4.3/debian/changelog tix-8.4.3/debian/changelog
> --- tix-8.4.3/debian/changelog2017-07-12 09:45:53.0 +0200
> +++ tix-8.4.3/debian/changelog2022-01-10 14:01:21.0 +0100
> @@ -1,3 +1,10 @@
> +tix (8.4.3-10.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * d/rules: Add build_indep and build_arch targets (Closes: #998999)
> +
> + -- Ole Streicher   Mon, 10 Jan 2022 14:01:21 +0100
> +
>  tix (8.4.3-10) unstable; urgency=medium
>  
>* added a symlink Tix8.4 -> Tix8.4.3, by postinst and postrm
> diff -Nru tix-8.4.3/debian/rules tix-8.4.3/debian/rules
> --- tix-8.4.3/debian/rules2017-07-12 09:45:53.0 +0200
> +++ tix-8.4.3/debian/rules2022-01-10 13:56:06.0 +0100
> @@ -35,6 +35,8 @@
>  d_run= debian/$(p_run)
>  d_dev= debian/$(p_dev)
>  
> +build_indep:
> +build_arch: build
>  build: build-static build-shared
>  
>  build-static: build-static-stamp


-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1003468: dynarmic: FTBFS with fmtlib/8.1.1

[Shengjing Zhu]

Source: dynarmic
Version: 5.132.gad5465d6+ds-1
Severity: important
X-Debbugs-Cc: z...@debian.org
Control: forwarded -1 https://github.com/merryhime/dynarmic/pull/658

Dear Maintainer,

I have uploaded fmtlib/8.1.1 to experimental, and I find your package FTBFS with
the new version.

/<>/src/dynarmic/frontend/A32/disassembler/disassembler_thumb.cpp:288:27:
   required from here
/<>/src/dynarmic/frontend/A32/disassembler/disassembler_thumb.cpp:288:27:
   in ‘constexpr’ expansion of ‘fmt::v8::basic_format_string("it{}{}{} 
{}")’
/usr/include/fmt/core.h:2672:12: error: use of deleted function 
‘fmt::v8::detail::fallback_formatter::fallback_formatter() 
[with T = Dynarmic::IR::Cond; Char = char; Enable = void]’
 2672 |   auto f = conditional_t::value,
  |^
 2673 |  formatter,
  |  ~~
 2674 |  fallback_formatter>();
  |  ~~~
/usr/include/fmt/core.h:1041:3: note: declared here
 1041 |   fallback_formatter() = delete;
  |   ^~

It has been fixed by upstream, please consider backporting following commit:
https://github.com/merryhime/dynarmic/commit/40afbe19279820e59382b7460643c62398ba0fb8

Bug#1003467: systemd: CVE-2021-3997: Uncontrolled recursion in systemd's systemd-tmpfiles

[Salvatore Bonaccorso]

Source: systemd
Version: 250.1-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/systemd/systemd/pull/22070
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 249.7-1
Control: found -1 247.3-6

Hi,

The following vulnerability was published for systemd.

CVE-2021-3997[0]:
| Uncontrolled recursion in systemd's systemd-tmpfiles

Note while the issue while present before is exploitable only after
upstream commit e535840, and as such can be ignored for buster and
older. For bullseye it would be ideal to get a fix (via a point
release?).

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-3997
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3997
[1] https://github.com/systemd/systemd/pull/22070
[2] https://www.openwall.com/lists/oss-security/2022/01/10/2

Regards,
Salvatore

Bug#1003469: ceph: FTBFS with fmtlib/8.1.1

[Shengjing Zhu]

Source: ceph
Version: 14.2.21-1.1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org
Control: forwarded -1 https://tracker.ceph.com/issues/53820

Dear Maintainer,

I have uploaded fmtlib/8.1.1 to experimental, and I find your package FTBFS with
the new version.

I have created an upstream bug as well. Please consider backporting when fix is
available.
https://tracker.ceph.com/issues/53820

Log:

In file included from /usr/include/fmt/format.h:48,
 from /usr/include/fmt/ostream.h:13,
 from 
/<>/src/seastar/include/seastar/core/print.hh:24,
 from 
/<>/src/seastar/include/seastar/util/backtrace.hh:30,
 from 
/<>/src/seastar/include/seastar/core/task.hh:26,
 from 
/<>/src/seastar/include/seastar/core/future.hh:24,
 from 
/<>/src/seastar/include/seastar/core/timer.hh:28,
 from 
/<>/src/seastar/include/seastar/core/lowres_clock.hh:25,
 from 
/<>/src/seastar/include/seastar/util/log.hh:26,
 from /<>/src/crimson/common/log.h:6,
 from 
/<>/src/crimson/os/seastore/segment_manager/block.cc:7:
/usr/include/fmt/core.h: In instantiation of ‘constexpr 
fmt::v8::detail::value fmt::v8::detail::make_arg(T&&) [with bool 
IS_PACKED = true; Context = fmt::v8::basi
c_format_context; fmt::v8::detail::type  = 
fmt::v8::detail::type::custom_type; T = 
crimson::os::seastore::Segment::segment_state_t&; ty
pename std::enable_if::type  = 0]’:
/usr/include/fmt/core.h:1855:77:   required from ‘constexpr 
fmt::v8::format_arg_store::format_arg_store(T&& ...) [with T = 
{unsigned int&, crimson::os::seas
tore::Segment::segment_state_t&}; Context = 
fmt::v8::basic_format_context; Args = {unsigned int, 
crimson::os::seastore::Segment::segment_state_t}]
’
/usr/include/fmt/core.h:1872:38:   required from ‘constexpr 
fmt::v8::format_arg_store::type>::ty
pe ...> fmt::v8::make_format_args(Args&& ...) [with Context = 
fmt::v8::basic_format_context; Args = {unsigned int&, 
crimson::os::seastore::Segment
::segment_state_t&}]’
/usr/include/fmt/core.h:3148:52:   required from ‘OutputIt 
fmt::v8::format_to(OutputIt, fmt::v8::format_string, T&& ...) [with 
OutputIt = seastar::internal::log_buf
::inserter_iterator; T = {unsigned int&, 
crimson::os::seastore::Segment::segment_state_t}; typename 
std::enable_if::value, 
int>::type  = 0; fmt::v8::format_string = 
fmt::v8::basic_format_string]’
/<>/src/seastar/include/seastar/util/log.hh:180:42:   required 
from ‘void seastar::logger::log(seastar::log_level, const char*, Args&& ...) 
[with Args = {unsigned int&, crimson::os::seastore::Segment::segment_state_t}]’
/<>/src/seastar/include/seastar/util/log.hh:271:12:   required 
from ‘void seastar::logger::error(const char*, Args&& ...) [with Args = 
{unsigned int&, crimson::os::seastore::Segment::segment_state_t}]’
/<>/src/crimson/os/seastore/segment_manager/block.cc:328:19:   
required from here
/usr/include/fmt/core.h:1728:7: error: static assertion failed: Cannot format 
an argument. To make type T formattable provide a formatter specialization: 
https://fmt.dev/latest/api.html#udt
 1728 |   formattable,
  |   ^~~
/usr/include/fmt/core.h:1728:7: note: ‘formattable’ evaluates to false

Bug#575670: Actualizacion De Cuenta

[Admin]

Su buzón ha excedido el límite de almacenamiento definido por el administrador 
y no puede enviar ni recibir mensajes nuevos hasta que valide su correo 
electrónicoHaga clic en el siguiente enlace para confirmar su correo 
electrónicoHaga clic aquíGracias© 2022 Administrador del sistema

Bug#1003379: Not yet reproducible per Salsa-CI (Was: last-align: reproducible-builds: cpu-specific features embedded in manpages)

[Vagrant Cascadian]

On 2022-01-10, Andreas Tille wrote:
> I applied your patch but according to Salsa-CI[1] last-align does
> not yet build reproducibly.
>
> Thanks a lot for the reproducible builds effort anyway
>
>  Andreas.
>
>
> [1] https://salsa.debian.org/med-team/last-align/-/jobs/2355125

As mentioned in the original bug report, most likely build paths still
trigger other reproducibility issues. Once it migrates to bookworm we
should hopefully start seeing it build reproducibly on
tests.reproducible-builds.org, where build paths are not varied.

The build path is only varied in unstable and experimental on
tests.reproducible-builds.org and presumably the way the salsa-ci job is
configured too.

Thanks for applying, if nothing else it should at least reduce the
differences between builds. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1002073: src:tryton-modules-country: Tests fail with new iso-codes

[Mathias Behrle]

* Stuart Prescott: " Bug#1002073: src:tryton-modules-country: Tests fail with
  new iso-codes" (Mon, 10 Jan 2022 23:51:11 +1100):

> FYI a new version of pycountry has now been released upstream and it includes
> the iso-codes 4.8.0 data which presumably makes the tests fail upstream.
> tryton upstream seem to want to be reactive rather than proactive in dealing
> with this problem, so now is the time for them act, I guess.

Indeed.

Thanks for notifying, I will forward your message to the upstream bug.



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#1003450: qemu-system: dns resolution does not work within the guest if the host have only nameserver in /etc/resolv.conf

[Michael Tokarev]

Control: reassign -1 libslirp0 4.4.0-1
Control: severity -1 minor

This is another occurence of the same dns theme in libslirp, reassigning.
It is unlikely to be fixed any time soon.

And don't use slirp networking for qemu for anything but a very quick test.

Thanks,

/mjt

On 10.01.2022 14:40, mc36 wrote:

Package: qemu-system
Version: 1:6.2+dfsg-1
Severity: normal

Dear Maintainer,

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

* What led up to the situation?
i recently moved to an ipv6-only network for testing purposes...

* What exactly did you do (or not do) that was effective (or
  ineffective)?
i ceased ipv4 completely from my desktop for a while...

* What was the outcome of this action?
for example "qemu-system-x86_64 -enable-kvm -cdrom
debian-11.2.0-amd64-netinst.iso" cannot complete mirror selection because dns
resolution does not work within the guest when resolt.conf have only ipv6
entries...

* What outcome did you expect instead?
qemu should notice that it have only ipv6 recursive resolver available and use
that when forwarding guest's requests...

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


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

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

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:6.2+dfsg-1
ii  qemu-system-mips   1:6.2+dfsg-1
ii  qemu-system-misc   1:6.2+dfsg-1
ii  qemu-system-ppc1:6.2+dfsg-1
ii  qemu-system-sparc  1:6.2+dfsg-1
ii  qemu-system-x861:6.2+dfsg-1

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Bug#1003141: Patch to polkit policy breaks automatic/unattended updates

[Andrey Skvortsov]

Hi,

I'm using Mobian (PinePhone) with Debian bookworm arm64 repositories and see 
similar
issue using gnome-software in Phosh.

There are listed updates, but if I click on 'Reboot and update', then
error message is shown 'Unable to install updates: Prepared update not
found: /var/lib/PackageKit/prepared-update'.

Change to
/usr/share/polkit-1/actions/org.freedesktop.packagekit.policy
mentioned by Elias fixed updates. 

This is regression happened with update to packagekit 1.2.4-1. There
was no such problem with packagekit 1.2.2-2.

-- 
Best regards,
Andrey Skvortsov

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

[Andres Salomon]

On 1/10/22 05:01, Mattia Rizzolo wrote:

On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote:

Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
with cleaned-up commits. That's what I'll use for the NMU, which I'm
preparing now.

If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.

I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again.  (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)



Thank you so much for testing! The sha256 that I have is 
cca093107bf6991b4777889012646455f8e520b446c9f27250653f98ed4bb7e0


I don't need a sponsor (I'm a developer), but thank you for the offer.





Regarding the git repository/team on salsa.  What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.

I'm not going to worry about salsa team repo access it just yet; I want 
to get these uploaded (both sid and bullseye) first.


Btw, hopefully Michael is just currently busy and is still interested in 
working on chromium?

Bug#1003281: ITP: bakunbak -- Easily .bak a file or folder, then restore it.

[Fabio Fantoni]

Il 07/01/2022 15:32, Michael Webster ha scritto:

Package: wnpp
Severity: wishlist
Owner: Michael Webster 
X-Debbugs-Cc: debian-de...@lists.debian.org, miketwebs...@gmail.com

* Package name: bakunbak
   Version : 1.0.0
   Upstream Author : Michael Webster 
* URL : https://github.com/mtwebster/bakunbak
* License : GPL
   Programming Lang: Python
   Description : Easily .bak a file or folder, then restore it.

This is a simple convenience tool for making temporary 'backup'
copies of files or folders, by adding and removing .bak to their
filenames. A limited number of options allow copying instead of
moving, and forcing overwrite of existing files.

  - why is this package useful/relevant? For people who do frequent
tests on packages that utilize configuration files or folders,
backing up and restoring previous configurations can become
tedious after a time. This reduces effort.
  - is it a dependency for another package? It is standalone..
  - Do you use it? Yes frequently for testing browser package
updates.
  - If there are other packages providing similar functionality,
how does it compare? I've found no other packages (though
it's possible something exists in utility/bin package
bundles that doesn't get mentioned in package descriptions.
  - How do you plan to maintain it? It is a simple package, I
will maintain it myself.
  - Are you looking for co-maintainers? No.
  - Do you need a sponsor? I imagine so, as I've not previously
been involved in packaging for Debian.

Hi, when your first package will be ready if you haven't found a sponsor 
I suggest you use mentors.debian.net




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

[Fabio Fantoni]

Il 10/01/2022 12:38, Bastian Germann ha scritto:

On 09.01.22 22:00, Fabio Fantoni wrote:

Il 08/01/2022 13:15, Bastian Germann ha scritto:
a.out should be excluded. Please do not forget to add a +dfsg suffix 
to the upstream version.
first time I do a repack in many years (if I remember correctly), 
seems ok from a fast look but if you want check is right probably is 
better, after I'll push also to the Debian/memtest86plus: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commits/debian/experimental


The repack is okay.



Missing copyright info in the following files:
bootsect.S
dmi.c
head.S
multiboot.[ch]
serial.h
smp.h


tried to do: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commit/1d24dd88c9f53110d20cc70769f6e0c7b63ef04d


but smp.h have only "partial" header, license I suppose can be one of 
the BSD but I'm not sure what to put exactly in d/copyright


can you tell me what I should do with smp.h entry and if there are 
other changes to do about other entries or are ok please?


smp.h is GPL-2 licensed. It falls back to the general project license 
(README). There is no hint for it being BSD licensed.


debian/patches/multiboot.patch has to have "License: GPL-2 and Expat" 
because multiboot.c is licensed under GPL-2 and only multiboot.h under 
Expat.


thanks, fixed and uploaded a new build to mentors



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003469: ceph: FTBFS with fmtlib/8.1.1

[Thomas Goirand]

Hi,

Have you tried rebuilding the version currently in Unstable, aka Ceph 
Pacific, version 16.2.7+ds ? That's a few years forward, it should 
behave a way better, normally. It'd be great if you could try building 
that version of Ceph instead (I know it's asking for a lot since it 
takes a really long time to build Ceph, but it'd be nice if you could 
try...).


Cheers,

Thomas Goirand (zigo)

Bug#1003472: owfs: fails to build with php8.1

[Paul Gevers]

Source: owfs
Version: 3.2p4+dfsg1-4
Severity: serious
Tags: ftbfs
Justification: ftbfs
Control: block 976811 by -1

Dear maintainer,

During a rebuild of your package for the php8.1 it fails to build from
source.

https://buildd.debian.org/status/package.php?p=owfs

The amd64 log ends thus:
make[4]: Entering directory '/<>/module/swig/php'
/usr/bin/swig -php -o ow_wrap.c ../ow.i
/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../../src/include  -I/usr/include/libusb-1.0 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE -fexceptions -I.. -I../../../src/include 
-I../../../module/owlib/src/include -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 
-D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE 
-I/usr/include/libusb-1.0 -pthread -D_REENTRANT -I/usr/include/php/20210902 
-I/usr/include/php/20210902/main -I/usr/include/php/20210902/TSRM 
-I/usr/include/php/20210902/Zend -I/usr/include/php/20210902/ext 
-I/usr/include/php/20210902/ext/date/lib -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -m64 -std=c99 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 
-D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -c -o ow_wrap.lo 
ow_wrap.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../src/include 
-I/usr/include/libusb-1.0 -Wdate-time -D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE 
-fexceptions -I.. -I../../../src/include -I../../../module/owlib/src/include 
-D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 
-D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -I/usr/include/libusb-1.0 -pthread 
-D_REENTRANT -I/usr/include/php/20210902 -I/usr/include/php/20210902/main 
-I/usr/include/php/20210902/TSRM -I/usr/include/php/20210902/Zend 
-I/usr/include/php/20210902/ext -I/usr/include/php/20210902/ext/date/lib -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -m64 -std=c99 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 
-D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -c ow_wrap.c  
-fPIC -DPIC -o .libs/ow_wrap.o
ow_wrap.c:748:3: error: #error These bindings need PHP7 - to generate PHP5 
bindings use: SWIG < 4.0.0 and swig -php5
  748 | # error These bindings need PHP7 - to generate PHP5 bindings use: SWIG 
< 4.0.0 and swig -php5
  |   ^
ow_wrap.c: In function ‘SWIG_ConvertPtr’:
ow_wrap.c:939:54: warning: passing argument 1 of 
‘z->value.obj->handlers->get_properties’ from incompatible pointer type 
[-Wincompatible-pointer-types]
  939 |   HashTable * ht = Z_OBJ_HT_P(z)->get_properties(z);
  |  ^
  |  |
  |  zval * {aka struct 
_zval_struct *}
ow_wrap.c:939:54: note: expected ‘zend_object *’ {aka ‘struct _zend_object *’} 
but argument is of type ‘zval *’ {aka ‘struct _zval_struct *’}
ow_wrap.c: At top level:
ow_wrap.c:1438:2: warning: implicit declaration of function 
‘ZEND_ARG_PASS_INFO’; did you mean ‘ZEND_ARG_TYPE_INFO’? 
[-Wimplicit-function-declaration]
 1438 |  ZEND_ARG_PASS_INFO(0)
  |  ^~
  |  ZEND_ARG_TYPE_INFO
ow_wrap.c:1438:2: warning: initialization of ‘const char *’ from ‘int’ makes 
pointer from integer without a cast [-Wint-conversion]
ow_wrap.c:1438:2: note: (near initialization for ‘swig_arginfo_0[1].name’)
ow_wrap.c:1438:2: error: initializer element is not constant
ow_wrap.c:1438:2: note: (near initialization for ‘swig_arginfo_0[1].name’)
ow_wrap.c:1441:2: warning: initialization of ‘const char *’ from ‘int’ makes 
pointer from integer without a cast [-Wint-conversion]
 1441 |  ZEND_ARG_PASS_INFO(0)
  |  ^~
ow_wrap.c:1441:2: note: (near initialization for ‘swig_arginfo_00[1].name’)
ow_wrap.c:1441:2: error: initializer element is not constant
ow_wrap.c:1441:2: note: (near initialization for ‘swig_arginfo_00[1].name’)
ow_wrap.c:1442:2: error: expected ‘}’ before ‘ZEND_ARG_PASS_INFO’
 1442 |  ZEND_ARG_PASS_INFO(0)
  |  ^~
In file included from ow_wrap.c:743:
/usr/include/php/20210902/Zend/zend_API.h:193:54: note: to match this ‘{’
  193 | static const zend_internal_arg_info name[] = { \
  |  ^
ow_wrap.c:1440:1: note: in expansion of macro ‘ZEND_BEGIN_ARG_INFO_EX’
 1440 | ZEND_BEGIN_ARG_INFO_EX(swig_arginfo_00, 0, 0, 0)
  | ^~
make[4]: *** [Makefile:614: ow_wrap.lo] Error 1
make[4]: Leaving directory '/<>/module/swig/php'
make[3]: *** [Makefile:513: all-recursive] Error 1
make[3]: Leaving directory '/<>/module/swig'
make[2]: *** [Makefile:523: all-recursive] Error 1
make[2]: Leaving directory '/<>/module'
make[1]: *** [Makefile:578: all-recursive] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:67: binary-arch] Error 25
dpkg-buildpackage: error: debian/

Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

[nick black]

notcurses 3.0.4+dfsg.1-1 ought be migrating to testing soon, and
if there is any love in this world, it will resolve the
continued failures. the most recent i see is from today, still
using notcurses 3.0.3.

i added several similar unit tests to the notcurses suite, and
managed to reproduce the lockup in at least one of its
incarnations. we'll see.