Bug#1015177: pypi2deb: py2dsp fails to build a GitHub package: "E: py2dsp py2dsp:167: 'info'"

[Julian Gilbey]

Package: pypi2deb
Version: 3.20220707
Severity: important

I just tried using this for the first time, and this is what happened:

$ py2dsp --gh https://github.com/scikit-build/scikit-build.git
/usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
E: py2dsp py2dsp:167: 'info'

The result directory is empty.

Not sure where to go from here...

Best wishes,

   Julian

Bug#1015176: guake fails to start

[Awtul]

Package: guake
Version: 3.9.0-1
Severity: important

Dear Maintainer,

guake fails to start. I get the following output when executing "guake" in 
terminal:



"Guake not running, starting it
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 177, in 
activate_name_owner
return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
return self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in 
call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could 
not get owner of name 'org.guake3.RemoteControl': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/guake/main.py", line 473, in main
remote_object = bus.get_object(DBUS_NAME, DBUS_PATH)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
return self.ProxyObjectClass(self, bus_name, object_path,
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 250, in __init__
self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 182, in 
activate_name_owner
self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 277, in 
start_service_by_name
return (True, self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in 
call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.guake3.RemoteControl was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/guake", line 33, in 
sys.exit(load_entry_point('guake==3.9.0', 'console_scripts', 'guake')())
  File "/usr/lib/python3/dist-packages/guake/main.py", line 648, in exec_main
if not main():
  File "/usr/lib/python3/dist-packages/guake/main.py", line 487, in main
from guake.guake_app import Guake
  File "/usr/lib/python3/dist-packages/guake/guake_app.py", line 49, in 
from guake import notifier
  File "/usr/lib/python3/dist-packages/guake/notifier.py", line 23, in 
gi.require_version("Notify", "0.7")
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available for version %s' %
ValueError: Namespace Notify not available for version 0.7".


Thanks for your work :)



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

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

Versions of packages guake depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gir1.2-glib-2.0   1.72.0-1+b1
ii  gir1.2-gtk-3.03.24.34-1
ii  gir1.2-keybinder-3.0  0.3.2-1.1
ii  gir1.2-notify-0.7 0.8.0-1
ii  gir1.2-pango-1.0  1.50.7+ds-1
ii  gir1.2-vte-2.91   0.68.0-1+b1
ii  gir1.2-wnck-3.0   40.1-1
ii  libglib2.0-bin2.72.3-1
ii  libutempter0  1.2.1-2
ii  python3   3.10.4-1+b1
ii  python3-cairo 1.20.1-3
ii  python3-dbus  1.2.18-3+b1
ii  python3-gi3.42.1-1
ii  python3-gi-cairo  3.42.1-1
ii  python3-importlib-metadata4.6.4-1
ii  python3-setuptools-scm7.0.4-1
ii  python3-yaml  5.4.1-1+b1

guake recommends no packages.

Versions of packages guake suggests:
ii  numix-gtk-theme  2.6.7-6

-- no debconf information

Bug#1002925: systemd-cron: please add support for cron.yearly

[Martin-Éric Racine]

Package: systemd-cron
Version: 1.15.19-1
Followup-For: Bug #1002925

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for enabling this.

Mind you, systemd-cron now ships with a /etc/cron.yearly/.placeholder file. 
This probably should go in cron-daemon-common instead.

Martin-Éric

- -- Package-specific info:
- -- output of systemd-delta

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages systemd-cron depends on:
ii  cron-daemon-common  3.0pl1-147
ii  libc6   2.33-8
ii  python3 3.10.4-1+b1
ii  systemd [systemd-sysusers]  251.3-1
ii  systemd-sysv251.3-1

Versions of packages systemd-cron recommends:
ii  nullmailer [mail-transport-agent]  1:2.2-3

systemd-cron suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmLTpGkACgkQrh+Cd8S0
17b3hg//Q2o3W4PmRwN6DZ5rjgz2gUBEAZ0ncjO87W1YqoEMnNC2YKzA8W0EpNe8
lOH0w63G0zDsHhJnJ+y0pPzQ/Cp6XnGjRvjg0JxtSqnZQWfqNbZge2l7ol2EQ+Ei
16/12xT8MuTyWJ/lK/+GGcvmTDUTvbOHr9VbAl1ninugCvnPQnuqhOCPaNdMyAsh
TrjCvXwd5WT3kn0edA8VYJW/XPyYTurru7G0pTmRfmskjIL3wJJUl3mcSSpRSGtA
l9UV3QV3RH4JQ11MpP5s8t2IHVSNpqYzCkV5f12WQCiQICrNN/rEsN4rUD1ZIP2+
eOxPLYqheKGXPze4RGFa0bPYILXEGnxTX+/ery6Gc32KL64ZZ7rfhjlj2y08YU37
VeIgdI9Zq4Jyv5xLcUV5H+su7yR518TwtkjhLKTCDp+grldZDSFHH0H5c0lVMOFh
2lmRiq56v/zmffr3W5YBdLaFxUWCY51d807/kSentyIojKhOhbqUYlfUonghl0j2
klbStWqCdqrxQXWl6cAUUKqBM6qaXruXUmbtslQjcbukQ9OQAIPJALnZm8rITnBz
gJuBQey6kEPNG2VI2hyUHo3K27knp47AIWyjy2VpydeQz3sfopDKWmFWIoGcUazh
MEUpT5FHLnmJLHwnZOWLZEnSMs3CEH70LpJtL2QAqUcfMuxcTTI=
=9ZK0
-END PGP SIGNATURE-

Bug#1015175: cron-daemon-common: please add .placeholder in /etc/cron.yearly

[Martin-Éric Racine]

Package: cron-daemon-common
Version: 3.0pl1-147
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Most cron variants support yearly tasks. cron-daemon-common would therefore 
need to ship with a /etc/cron.yearly directory and document its availability.

Thanks!

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmLTotIACgkQrh+Cd8S0
17YxrhAAgfBGPu0IBO7SR1o/PwW606IOVIpiXsGsAGQf7l+RoLs0gR88JAYMvM9V
4SIEUNSILgvvy12Ypvqk6PZYzGl6JpDb56IX+b05smJK4iwaJcfLyWtU0oPj/h/H
jPbcNBl1WRDUMvW3YFnNn7zKHgzEbYpNUtm+OjvOdatvj6phBF6VrC37e+kiO8IJ
8p6gpofyvXOG0JEZLd5Qo198j2mtR3Ri9rk/uimHMce2uzf9IQzGqSFMOChBtV+x
lbo9xVtFikPDhdt55PahrCeyOk9HGqbvuaVR8dz7A4kD0Kxqf89IgkUq0PXQ8323
Z9X6LePJlszM+abVN3JVEMYzpzKgihOu6zBdWUMR+ziGJV448PcEdpYXTL3Bf1EI
fW5Q1TGVqXDWyechPY8+QFAGq8pyo61jiJC/vYBz/ZzC3A9x02/NQ38CCHKyTfSt
HJH23C/YHj3ZLiEMZvKhc0cJT6XE4kv0McMJcDJAyLNvcBS/53RVamRBx3SoIiwS
8ZCiuChEptuF8V3l0pJjs0ncxmJ6uw/nPyeug2ncWhcrMFZj8XB08LUHiLGw6Bqc
l23awT3GokT0U0W1fh6k7hZ4F4/TsJOR7DhnwVM1wLpgOOOpM6kBXtL3PEYoTlb9
KUDYyPILX22om7vBLa6Y0JLNPuw+xTS2IojpSx6GTrpOjstme2w=
=J7e+
-END PGP SIGNATURE-

Bug#1015098: nng: FTBFS: Errors while running CTest

[GCS]

Control: tags -1 +moreinfo +unreproducible
Control: severity -1 important

Hi Lucas,

On Sat, Jul 16, 2022 at 4:03 PM Lucas Nussbaum  wrote:
> Source: nng
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
 Unfortunately I can't reproduce it. Tried in several ways. Do you
have time to repeat your build process and see if it builds this time?

Thanks,
Laszlo/GCS

Bug#1015172: marked as done (wiki.debian.org: Sid installation fails - No kernel modules found - Wiki issue)

[Cyril Brulebois]

Debian Bug Tracking System  (2022-07-17):
> This is a temporary issue that always happens after Linux kernel
> updates and then gets automatically fixed after some time. In this case
> there was also a cron job delay so it took a bit longer. The Debian
> Installer team say this should be fixed in the next few hours.
> 
> PS: the debian-boot list would have been the place to report this.

Sorry for the incomplete analysis I provided Paul with, the kernel issue
mismatch is usually temporary, but that's not a factor here: there seem
to be some weird things going on, mixing and matching bits from bullseye
and unstable?

Anyway, there's another issue for d-i builds in unstable currently:
lvm2-udeb is not installable, which is why some builds are failing. I've
filed a bug report but it's not showing up just yet.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Cyril Brulebois]

Package: lvm2-udeb
Version: 2.03.15-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@lists.debian.org

[ Please keep debian-boot@ cc'd. ]

Hi,

lvm2-udeb is no longer installable, which causes some d-i images to fail
to build:

The following packages have unmet dependencies:
 lvm2-udeb : Depends: libsystemd0 (>= 251.2) but it is not installable

This also causes some issues at runtime (even though it seems a little
strange to get that far, despite the dependency issue):
  https://lists.debian.org/debian-boot/2022/07/msg00015.html

A naive check (grepping in debian/*-udeb after an lvm2 build in unstable)
suggests that only /sbin/lvm in lvm2-udeb pulls such a NEEDED dependency
on libsystemd.so.0, for those symbols:

U sd_id128_get_machine_app_specific@LIBSYSTEMD_233
U sd_journal_printv_with_location@LIBSYSTEMD_209
U sd_journal_send_with_location@LIBSYSTEMD_209

I suppose the journal bits could be patched out for the udeb build (right
now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
could have for arrays built at installation time (the function call itself
is already guarded within an #ifdef/#endif block, so it seems somewhat
optional already).

Feel free to let us know, and whether you'd like us to try and come up
with a tentative patch.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1001788: neovim: undoing changes results in a mix of old and new text

[James McCoy]

On Tue, Mar 01, 2022 at 05:45:35PM +0100, Nicolas Évrard wrote:
> * James McCoy  [2021-12-17 22:31 +0100]:
> > On Thu, Dec 16, 2021 at 10:28:18AM +0100, Nicolas Évrard wrote:
> > > I am sorry for this bug report because it occurs on some rare occurence 
> > > and I
> > > don't have a scenario to reproduce it. Yet it's annoying enough to 
> > > deserve a
> > > bug report. Feel free to close it as unreproduceable ;).
> > > 
> > > With the arrival of LSP I switched my configuration from ALE to the 
> > > builtin LSP
> > > for linting and so on. I made this switch some days after the release of 
> > > neovim
> > > 0.5.0 ; since that time I have remarked that sometimes (I'd say 2 or 3 
> > > times a
> > > month), when I undo my changes (not just one press of 'u' multiple 
> > > presses), it
> > > results in a mix of old and new changes.
> > 
> > There were a number of fixes in the LSP stuff for 0.6.0, so can you let
> > me know if you see this again after upgrading to that?
> 
> Hello,
> 
> So after a while I thought that it had indeed disappeared but I had it twice
> today :(. It seems to be a problem with the virtual text and treesitter.
> 
> Here's a screenshot of the error in action.

If you encounter this again, can you see if running ":redraw!" fixes it?
That would help confirm whether it's just a display issue or the buffer
is actually in a bad state.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Thorsten Glaser]

On Sun, 17 Jul 2022, Craig Sanders wrote:

> > You most likely want some pinning.
>
> I've never found pinning to be of much use. When I did have an actual use for
[…]

No, not that. You need it to get apt to not even consider systemd
installable.

> wanted. Far more work than it was worth - I ended up just purging gnome and
> switching to xfce instead.

That anyway.

> Having `APT::Default-Release "unstable";` is enough for my needs. That allows
[…]
> Or `APT::Default-Release "stable";` allows a system to run stable and
> cherry-pick from testing/sid/experimental plus backports as needed.

No, not that. See above and below.

> > Just held in dpkg or even marked as XB-Important: yes often brings apt to
> > tears in sid, i.e. refusing to dist-upgrade at all.
>
> Yeah, but I **want** apt to chuck a wobbly, it alerts me to the fact that
> there are problems that need manual intervention and/or that I need to wait

Nope. These are things apt could, in theory, solve by itself but cannot
because it can only consider one solution but that’s uninstallable. By
forcing it to not even consider systemd by pinning it down to -1 you get
apt to consider an alternative solution instead.

In pbuilder, I pin down dconf-gsettings-backend for example, so it gets
gconf-gsettings-backend instead, which works without systemd. (Not that
this is actually used during the building, but dependencies are gonna
depend.)

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#1015173: ITP: pwncat -- reverse shell handler with all netcat features

[Marcos Talau]

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

* Package name: pwncat
  Version : 0.1.2
  Upstream Author : cytopia 
* URL : https://pwncat.org
* License : Expat
  Programming Lang: Python
  Description : reverse shell handler with all netcat features

pwncat is a fully compatible netcat fork written in Python with many more
aggressive network features on top.
.
It comes with a Python Scripting Engine (PSE) that allows you to manipulate
incoming and outgoing traffic to your needs. This can reach from wrapping
current TCP/UDP traffic into higher protocols such as HTTP, FTP, Telnet,
etc or even go to encrypting and decrypting your traffic.
.
Besides regular netcat features like full IPv4, IPv6 and UDP/TCP, IP ToS,
port scanning, server/client, bind, and reverse shells, it also comes with
pivoting features, ssh-less local and remote port-forwarding, port-hopping,
target self-injection and many more.

Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Craig Sanders]

On Sun, Jul 17, 2022 at 04:01:38AM +0200, Thorsten Glaser wrote:
> On Sun, 17 Jul 2022, Craig Sanders wrote:
>
> > and, of course:
> >
> > apt-mark hold sysvinit-core
> >
> > To prevent systemd from being auto-installed in some future upgrade.
>
> You most likely want some pinning.

I've never found pinning to be of much use. When I did have an actual use for
it (many years ago, during the gnome 2 -> gnome 3 transition), it required
constant work and tweaking of the pinning rules to get it to do what I
wanted. Far more work than it was worth - I ended up just purging gnome and
switching to xfce instead.

Having `APT::Default-Release "unstable";` is enough for my needs. That allows
me to run sid and cherry pick a few things (mostly nvidia-kernel-dkms and
friends) from experimental. With that default release, apt will only install
from unstable unless I explicitly force it to with `-t experimental`. Works
for me.

Or `APT::Default-Release "stable";` allows a system to run stable and
cherry-pick from testing/sid/experimental plus backports as needed.

> Just held in dpkg or even marked as XB-Important: yes often brings apt to
> tears in sid, i.e. refusing to dist-upgrade at all.

Yeah, but I **want** apt to chuck a wobbly, it alerts me to the fact that
there are problems that need manual intervention and/or that I need to wait
a few days/weeks for updated packages.  I don't run a dist-upgrade every day
anyway, so waiting is no big deal.

craig

--
craig sanders 

Bug#1015172: wiki.debian.org: Sid installation fails - No kernel modules found - Wiki issue

[Piscium]

Package: wiki.debian.org
Severity: normal
X-Debbugs-Cc: grok...@gmail.com

Dear Maintainer,

I tried to install Sid (on a VirtualBox VM) following the instructions in [1], 
section "Use the Unstable "mini.iso" image.". I downloaded the specified ISO 
[2] using the nearest mirror, did the sha256 check, proceeded with all the 
various options without any error, network configuration also succeeded, then 
at the step "Download installer components" I got the error "No kernel modules 
found". The mirror is the default and recommended [3].

Upon investigation with the help of the users mailing list it turns out that 
the file that the wiki says we should use does not work.

This is what it says in the wiki:
"Download the "mini.iso" for your location and CPU architecture located here: 
Debian mirrors under 
debian/dists/unstable/main/installer-*/current/images/netboot/".
The above points to a mini.iso that is one year old and does not work.

The following works (at least in amd64), replacing the word "unstable" with 
"bullseye". It may also work replacing it with "stable" although I have not 
tried it.
"Download the "mini.iso" for your location and CPU architecture located here: 
Debian mirrors under 
debian/dists/bullseye/main/installer-*/current/images/netboot/".

[1] https://wiki.debian.org/DebianUnstable
[2] 
http://ftp.uk.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso
[3] deb.debian.org

Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Thorsten Glaser]

On Sun, 17 Jul 2022, Craig Sanders wrote:

> and, of course:
> 
> apt-mark hold sysvinit-core
> 
> To prevent systemd from being auto-installed in some future upgrade.

You most likely want some pinning. Just held in dpkg or even marked
as XB-Important: yes often brings apt to tears in sid, i.e. refusing
to dist-upgrade at all.

Check the prevent-* packages in
http://www.mirbsd.org/~tg/Debs/dists/sid/wtf/Pkgs/mirabilos-support/
for inspiration. (I’ve moved from sid to bullseye though, so they
only get very mild testing in a chroot, and not with the latest
shenanigans yet.)

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


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

Bug#1013740: libtickit: Upgrade to 0.4.2a

[James McCoy]

On Sat, Jun 25, 2022 at 06:54:49AM +, Damyan Ivanov wrote:
> Please upgrade the libtickit package to version 0.4.2a, available from 
> https://www.leonerd.org.uk/code/libtickit/
> 
> It is needed for the new version of libtickit-perl.

I'll look into this over the next few days.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1007138: libgnutls30: fails on Let's Encrypt chains due to blacklisted expired root certificate

[Paul Wise]

Control: retitle -1 libgnutls30: fails to validate when there is junk in the 
cert chain, including duplicated server certs

On Sun, 17 Jul 2022 09:40:09 +0800 Paul Wise wrote:

> I have seen this issue (duplicate server cert) on several other
> sites.

Seems this issue is broader than just duplicate server certs, I just
found a site that has a Thawte CA cert as its first cert in the cert
chain instead of the LE/ISRG CA certs. This site works just fine with
OpenSSL and NSS but not with GnuTLS.

$ gnutls-cli neo900.org < /dev/null
Processed 127 CA certificate(s).
Resolving 'neo900.org:443'...
Connecting to '207.154.223.212:443'...
- Certificate type: X.509
- Got a certificate list of 4 certificates.
- Certificate[0] info:
 - subject `CN=neo900.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 
0x047b33482e681f3a1ac7d3c5ccfd88ec782a, RSA key 2048 bits, signed using 
RSA-SHA256, activated `2022-06-28 06:54:18 UTC', expires `2022-09-26 06:54:17 
UTC', pin-sha256="PwlhvXvPqmAlJKlxSnEAkmSmjkg4sAhebliU+AznV1k="
Public Key ID:
sha1:6613298f366b86c7f160c573fa2cd2a9207fe0bd

sha256:3f0961bd7bcfaa602524a9714a71009264a68e4838b0085e6e5894f80ce75759
Public Key PIN:
pin-sha256:PwlhvXvPqmAlJKlxSnEAkmSmjkg4sAhebliU+AznV1k=

- Certificate[1] info:
 - subject `CN=Thawte TLS RSA CA G1,OU=www.digicert.com,O=DigiCert Inc,C=US', 
issuer `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', 
serial 0x090ee8c5de5bfa62d2ae2ff7097c4857, RSA key 2048 bits, signed using 
RSA-SHA256, activated `2017-11-02 12:24:25 UTC', expires `2027-11-02 12:24:25 
UTC', pin-sha256="42b9RNOnyb3tlC0KYtNPA3KKpJluskyU6aG+CipUmaM="
- Certificate[2] info:
 - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet 
Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, RSA 
key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 UTC', 
expires `2025-09-15 16:00:00 UTC', 
pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="
- Certificate[3] info:
 - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer 
`CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 
0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using RSA-SHA256, 
activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', 
pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Craig Sanders]

On Sat, Jul 16, 2022 at 02:35:33PM +0100, Mark Hindley wrote:
> On Sat, Jul 16, 2022 at 11:07:47PM +1000, Craig Sanders wrote:
> > A little more investigation reveals that it's udev.
> >
> > udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on 'systemd | 
> > systemd-tmpfiles'.
>
> Great. systemd-tmpfiles is a virtual package that is also provided by
> systemd-standalone-tmpfiles. If you manually install that, I suspect you
> will find everything is OK again.


Thanks, I have just tried that and it seems to work.

Perhaps elogind should Suggest or Recommend systemd-standalone-tmpfiles?



BTW, I had already installed systemd, but hadn't rebooted yet, before I
saw this, but (after examining /var/log/dpkg.log to find out exactly which
packages had been removed because of that), running the following reverted my
system back to the way it was before.

apt-get install systemd-standalone-tmpfiles sysvinit-core elogind

and, of course:

apt-mark hold sysvinit-core

To prevent systemd from being auto-installed in some future upgrade.


indra:/var/log# grep -E ' (remove|purge) ' dpkg.log
2022-07-16 17:05:39 startup packages remove
2022-07-16 17:05:39 remove libelogind0:amd64 246.9.1-1+debian1 
2022-07-16 17:05:39 remove elogind:amd64 246.9.1-1+debian1 
2022-07-16 17:05:41 startup packages remove
2022-07-16 17:05:41 remove sysvinit-core:amd64 3.03-1 
2022-07-16 17:05:42 startup packages remove
2022-07-16 17:05:43 remove libpam-elogind:amd64 246.9.1-1+debian1 
2022-07-16 17:05:44 startup packages remove
2022-07-16 17:05:44 remove libpam-elogind-compat:amd64 1.3 

craig

Bug#1007138: libgnutls30: fails on Let's Encrypt chains due to blacklisted expired root certificate

[Paul Wise]

Control: severity -1 important
Control: retitle -1 libgnutls30: fails to validate when the server cert is 
duplicated in the cert chain

On Sat, 12 Mar 2022 07:43:28 +0100 Andreas Metzler wrote:

> ci.debian.net seems to be configured less than optimal, its cert-chain
> contains junk (0=server cert, 1=server cert *again*, etc.).

I have seen this issue (duplicate server cert) on several other sites.
For some of them I was able to convince the server operator to fix the
issue but for others I wouldn't even know who to contact. So I think
that this issue needs to be fixed in GnuTLS and that this bug should be
fixed before the release of Debian bookworm, because it makes programs
using GnuTLS somewhat unusable now. Please bump severity if you agree.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#817958:

[Nilson Silva]

Seems like it is abandoned. https://github.com/mbr/flask-bootstrap/issues/208:
But there is an alternative mentioned in 
https://github.com/helloflask/bootstrap-flask


Nilson F. Silva

Bug#990247: vlc: reproducible builds: Fix passing sort order to tar when generating default.vlt

[Vagrant Cascadian]

On 2022-05-17, Rémi Denis-Courmont wrote:
> On Wed, 23 Jun 2021 13:24:23 -0700 Vagrant Cascadian  builds.org> wrote:
>> In share/Makefile.am, when creating default.vlt it attempts to detect
>> the availability of the tar --sort= option, but then incorrectly passes
>> the variable to tar.
>> 
>> It does not appear to affect the sort order on
>> tests.reproducible-builds.org, but it does appear to cause issues when
>> testing with reprotest, and so may occur in other situations in the
>> wild.
>> 
>> 
>> The attached patch fixes this by passing it as a make variable rather
>> than a quoted shell variable.
>
> Such a patch should be submitted upstream but for a start, it does not look 
> right to me. Specifically $$tarsort is correct.

Ok, will try to take this upstream.

> AFAICT, the problem is that predicate for the assignment relies on
> locale-dependent behaviour and thus fails with non-English languages.

This also apparently happens with the C.UTF-8 locale:

  
https://buildd.debian.org/status/fetch.php?pkg=vlc&arch=amd64&ver=3.0.17.4-4%2Bb1&stamp=1656788338&raw=0

  tarsort= ; \
  tar --help|grep -q sort=ORDER && tarsort=--sort=name ; \
  GZIP=--no-name \
  tar cvvzf skins2/default.vlt.tmp \
--format=ustar $tarsort \
--owner=root --group=root --directory="./skins2" \
default/


live well,
  vagrant

p.s. please CC the submitter or nnn-submit...@bugs.debian.org if you
want them to notice!


signature.asc
Description: PGP signature

Bug#1015171: libzhuyin13: Unaligned access makes fcitx5-zhuyin FTBFS when building armhf on 64 bit hardware

[Adrian Bunk]

Package: libzhuyin13
Version: 2.6.2-1
Severity: serious
Tags: ftbfs patch
Forwarded: https://github.com/libpinyin/libpinyin/pull/152
Control: affects -1 src:fcitx5-zhuyin

https://buildd.debian.org/status/fetch.php?pkg=fcitx5-zhuyin&arch=armhf&ver=5.0.8-1&stamp=1657997016&raw=0

...
0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.02 sec

The following tests FAILED:
  1 - testzhuyinbuffer (Bus error)
Errors while running CTest
make[1]: *** [Makefile:74: test] Error 8


The fix is in the linked pull request above.

Bug#858331: dpkg -S doesn't work properly with usrmerge

[Guillem Jover]

Control: tags -1 - patch

On Sun, 2022-07-17 at 00:26:46 +0100, Luca Boccassi wrote:
> Control: tags -1 patch

> The attached patch from user uau is a working solution that would allow
> to lift this moratorium and also solve this bug. It is shared as-is,
> with permission and under the same license as src:dpkg.

As I mentioned at the time, this patch is a major hack, it is
conceptually broken as it hardcodes pathnames and remaps them behind
the involved packages back (action at a distance), it breaks
interfaces, it's incomplete, etc. Even the included README says as
much. So, no, it's not a "working solution"…

Guillem

Bug#1015170: RFS: presets/0.1.3-1 [ITP] -- Python module to handle default parameters of functions

[Nilson Silva]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: presets
   Version : 0.1.3-1
   Upstream Author : https://github.com/bmcfee/presets/issues
 * URL : https://github.com/bmcfee/presets
 * License : ISC
 * Vcs : https://salsa.debian.org/debian/presets
   Section : python

The source builds the following binary packages:

  python3-presets - Python module to handle default parameters of functions

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/presets/presets_0.1.3-1.dsc

Changes for the initial release:

 presets (0.1.3-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1015142)

Regards,
--

Nilson F. Silva

Bug#1015167: CPU stall while running fwupdmgr

[Marco d'Itri]

On Jul 17, Diederik de Haas  wrote:

> On Sunday, 17 July 2022 01:34:08 CEST Marco d'Itri wrote:
> > Source: linux
> > Version: 5.10.127-1
> > Severity: normal
...
> > Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> 
> Why is this bug filed against kernel version 5.10.127-1 and not 5.18.5-1?
I wondered myself, but I do not know why reportbug choose the version of 
the stable package.

ii  linux-image-5.18.0-2-amd64 5.18.5-1 amd64Linux 5.18 for 64-bit >

5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64 
GNU/Linux

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1015167: CPU stall while running fwupdmgr

[Diederik de Haas]

On Sunday, 17 July 2022 01:34:08 CEST Marco d'Itri wrote:
> Source: linux
> Version: 5.10.127-1
> Severity: normal
> 
> Updating the system firmware (Dell Latitude 7480) with fwupdmgr caused
> a CPU stall with the system being totally unresponsive.
> The logs follows.
> 
> root@bongo:~# fwupdmgr update
> ...
> Jul 17 01:22:32 bongo kernel: [773964.421815] Sending NMI from CPU 2 to CPUs
> 1: Jul 17 01:22:32 bongo kernel: [773964.421849] NMI backtrace for cpu 1
> Jul 17 01:22:32 bongo kernel: [773964.421851] CPU: 1 PID: 7860 Comm:
> gnome-panel Not tainted 5.18.0-2-amd64 #1  Debian 5.18.5-1 Jul 17 01:22:32
> bongo kernel: [773964.421854] Hardware name: Dell Inc. Latitude
> 7480/0R0YRF, BIOS 1.24.1 12/15/2021 Jul 17 01:22:32 bongo kernel:
> ...
> Jul 17 01:22:32 bongo kernel: [773964.422836] NMI backtrace for cpu 2
> Jul 17 01:22:32 bongo kernel: [773964.422856] CPU: 2 PID: 0 Comm: swapper/2
> Not tainted 5.18.0-2-amd64 #1  Debian 5.18.5-1 Jul 17 01:22:32 bongo
> kernel: [773964.422859] Hardware name: Dell Inc. Latitude 7480/0R0YRF, BIOS
> 1.24.1 12/15/2021 Jul 17 01:22:32 bongo kernel: [773964.422860] Call Trace:
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)

Why is this bug filed against kernel version 5.10.127-1 and not 5.18.5-1?

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

Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for common audio/music processing tasks

[Nilson Silva]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "mir-eval":

 * Package name: mir-eval
   Version : 0.7-1
   Upstream Author : https://github.com/craffel/mir_eval/issues
 * URL : https://github.com/craffel/mir_eval
 * License : Expat/MIT
 * Vcs : https://salsa.debian.org/debian/mir-eval
   Section : python

The source builds the following binary packages:

  python3-mir-eval - Common metrics for common audio/music processing tasks

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

  https://mentors.debian.net/package/mir-eval/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mir-eval/mir-eval_0.7-1.dsc

Changes for the initial release:

 mir-eval (0.7-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1015152)

Regards,

Nilson Silva

Bug#1015168: RFS: sphinx-multiversion/0.2.4-1 [ITP] -- Sphinx extensionfor common documentation

[Nilson Silva]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "sphinx-multiversion":

 * Package name    : sphinx-multiversion
   Version         : 0.2.4-1
   Upstream Author : https://github.com/Holzhaus/sphinx-multiversion/issues
 * URL             : https://github.com/Holzhaus/sphinx-multiversion
 * License         : BSD-2-Clause
 * Vcs             : https://salsa.debian.org/debian/sphinx-multiversion
   Section         : python

The source builds the following binary packages:

  python3-sphinx-multiversion - Add support for multiple versions to sphinx
  python-sphinx-multiversion-doc - Sphinx extensionfor common documentation

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

  https://mentors.debian.net/package/sphinx-multiversion/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sphinx-multiversion/sphinx-multiversion_0.2.4-1.dsc

Changes for the initial release:

 sphinx-multiversion (0.2.4-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1014666)

Regards,
-- 
  Nilson Silva.

Bug#1015167: CPU stall while running fwupdmgr

[Marco d'Itri]

Source: linux
Version: 5.10.127-1
Severity: normal

Updating the system firmware (Dell Latitude 7480) with fwupdmgr caused 
a CPU stall with the system being totally unresponsive.
The logs follows.

root@bongo:~# fwupdmgr update
...
╔══╗
║ Aggiornare System Firmware da 1.24.1 a 1.25.0?   ║
╠══╣
║ This stable release fixes the following issues:  ║
║  ║
║ • Firmware updates to address security vulnerabilities including.║
║  ║
║ Some new functionality has also been added:  ║
║  ║
║ Latitude 7480 deve rimanere collegato alla rete elettrica durante║
║ l'aggiornamento per evitare possibili danni. ║
╚══╝

Eseguire l'operazione? [Y|n]: y
Scaricamento…[***]
Scaricamento…[***]
Estrazione…  [***]
Autenticazione…  [***]
Attesa…  [***]
Scrittura…   [***]
Attesa…  [***]
Attesa…  [***]
Firmware installato con successo

Per essere completato, un aggiornamento richiede un riavvio. Riavviare ora? 
[y|N]: n



Jul 17 01:22:32 bongo kernel: [773964.420726] rcu: INFO: rcu_preempt 
self-detected stall on CPU
Jul 17 01:22:32 bongo kernel: [773964.420739] rcu:  2-...!: (1 ticks this 
GP) idle=645/1/0x4002 softirq=15070973/15070973 fqs=0 
Jul 17 01:22:32 bongo kernel: [773964.420745]   (t=8428 jiffies g=32003353 q=40)
Jul 17 01:22:32 bongo kernel: [773964.420748] rcu: rcu_preempt kthread timer 
wakeup didn't happen for 8427 jiffies! g32003353 f0x0 RCU_GP_WAIT_FQS(5) 
->state=0x402
Jul 17 01:22:32 bongo kernel: [773964.420751] rcu:  Possible timer handling 
issue on cpu=0 timer-softirq=21358785
Jul 17 01:22:32 bongo kernel: [773964.420752] rcu: rcu_preempt kthread starved 
for 8428 jiffies! g32003353 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
Jul 17 01:22:32 bongo kernel: [773964.420755] rcu:  Unless rcu_preempt 
kthread gets sufficient CPU time, OOM is now expected behavior.
Jul 17 01:22:32 bongo kernel: [773964.420756] rcu: RCU grace-period kthread 
stack dump:
Jul 17 01:22:32 bongo kernel: [773964.420758] task:rcu_preempt state:I 
stack:0 pid:   14 ppid: 2 flags:0x4000
Jul 17 01:22:32 bongo kernel: [773964.420762] Call Trace:
Jul 17 01:22:32 bongo kernel: [773964.420765]  
Jul 17 01:22:32 bongo kernel: [773964.420770]  __schedule+0x30b/0x9e0
Jul 17 01:22:32 bongo kernel: [773964.420781]  ? rcu_gp_cleanup+0x3f0/0x3f0
Jul 17 01:22:32 bongo kernel: [773964.420787]  schedule+0x4e/0xb0
Jul 17 01:22:32 bongo kernel: [773964.420789]  schedule_timeout+0x88/0x150
Jul 17 01:22:32 bongo kernel: [773964.420793]  ? __bpf_trace_tick_stop+0x10/0x10
Jul 17 01:22:32 bongo kernel: [773964.420797]  rcu_gp_fqs_loop+0xfc/0x380
Jul 17 01:22:32 bongo kernel: [773964.420800]  rcu_gp_kthread+0xac/0x160
Jul 17 01:22:32 bongo kernel: [773964.420803]  kthread+0xe8/0x110
Jul 17 01:22:32 bongo kernel: [773964.420806]  ? 
kthread_complete_and_exit+0x20/0x20
Jul 17 01:22:32 bongo kernel: [773964.420809]  ret_from_fork+0x22/0x30
Jul 17 01:22:32 bongo kernel: [773964.420816]  
Jul 17 01:22:32 bongo kernel: [773964.420817] rcu: Stack dump where RCU GP 
kthread last ran:
Jul 17 01:22:32 bongo kernel: [773964.420818] Sending NMI from CPU 2 to CPUs 0:
Jul 17 01:22:32 bongo kernel: [773964.420824] NMI backtrace for cpu 0
Jul 17 01:22:32 bongo kernel: [773964.420827] CPU: 0 PID: 0 Comm: swapper/0 Not 
tainted 5.18.0-2-amd64 #1  Debian 5.18.5-1
Jul 17 01:22:32 bongo kernel: [773964.420830] Hardware name: Dell Inc. Latitude 
7480/0R0YRF, BIOS 1.24.1 12/15/2021
Jul 17 01:22:32 bongo kernel: [773964.420830] RIP: 0010:task_h_load+0xe7/0x110
Jul 17 01:22:32 bongo kernel: [773964.420834] Code: 89 82 18 01 00 00 48 85 f6 
75 c7 49 8b 81 60 01 00 00 49 8b 88 a0 00 00 00 31 d2 49 0f af 80 18 01 00 00 
48 83 c1 01 48 f7 f1  4c 89 c2 48 8b 82 a0 00 00 00 48 89 ba 20 01 00 00 48 
89 82 18
Jul 17 01:22:32 bongo kernel: [773964.420835] RSP: 0018:b05140003a50 
EFLAGS: 0006
Jul 17 01:22:32 bongo kernel: [773964.420837] RAX:  RBX: 
a0ea84629000 RCX: 0005
Jul 17 01:22:32 bongo kernel: [773964.420838] RDX:  RSI: 

Bug#858331: dpkg -S doesn't work properly with usrmerge

[Luca Boccassi]

Control: tags -1 patch

Hello,

On top of the issue described in this bug, the Debian CTTE in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 also ruled
as follow because of the same missing functionality in dpkg:

"Moratorium on moving files' logical locations into /usr
<...>
The Technical Committee recommends that during the Debian 12
development
cycle, the maintainers of individual packages should not proactively
move files from the root filesystem to the corresponding locations in
/usr in the data.tar.* of packages. Files that were in /usr in the
Debian 11 release should remain in /usr, while files that were in /bin,
/lib* or /sbin in the Debian 11 release should remain in those
directories.  If files were moved from /bin, /lib* or /sbin into /usr
since the Debian 11 release, they should be moved back to their Debian
11 locations."

The attached patch from user uau is a working solution that would allow
to lift this moratorium and also solve this bug. It is shared as-is,
with permission and under the same license as src:dpkg.

-- 
Kind regards,
Luca Boccassi
diff --git a/README.usrmerge b/README.usrmerge
new file mode 100644
index 0..ee8b1646d
--- /dev/null
+++ b/README.usrmerge
@@ -0,0 +1,67 @@
+This is a proof of concept version of dpkg with explicit usrmerge
+support. This means the following file path conversions are done in
+various places:
+/lib -> /usr/lib
+/bin ->/ /usr/bin
+/sbin -> /usr/sbin
+
+Usrmerge also includes other links like "/libx32 -> /usr/libx32"
+depending on platform, but those are not handled. This shouldn't
+matter much for testing since few packages contain those anyway, and
+it does not matter much whether dpkg is aware of aliasing for those
+paths.
+
+The conversion is done at least in the following cases:
+- installing packages: any install path contained in .deb
+- reading list of existing installed files (/var/lib/dpkg/info/*.list)
+- dpkg-query (or dpkg) -S patterns beginning with '/'
+- reading existing statoverride locations, adding/removing
+- dpkg-statoverride --list glob patterns beginning with '/'
+- reading existing divert locations, adding/removing
+- dpkg-divert --list glob patterns beginning with '/'
+- file trigger locations
+- .md5sums file targets
+- .conffiles (should any exist with such paths)
+
+These conversions mean that dpkg should notice any file conflicts
+between /bin/x and /usr/bin/x, since both are now converted to the
+same literal path /usr/bin/x. Most maintainer scripts and tools should
+continue working, as the paths they use are automatically converted.
+However, there is some potential for maintainer scripts or other tools
+to break if they care about the exact paths returned from queries like
+"dpkg-divert --truename" or "dpkg-query -S" (since those will now
+refer to the real location under /usr).
+
+No separate database conversion step is required. Existing paths are
+converted as they are read from disk. Any files generated and written
+by dpkg will have the new paths, since they will have been converted
+before writing. This means newly created .list files use converted
+locations, but .triggers files do not (they are copied verbatim from
+the package, not generated from already parsed data). The
+dpkg-generated triggers/File file will contain converted locations
+when it is written. (Applies at least to udev /lib/udev/hwdb.d).
+
+The query conversions mean that for example "dpkg -S '/bin/ba*'"
+output will include "/usr/bin/bash" (as the query will be converted to
+"/usr/bin/ba*"), but "dpkg -S '/???/bash'" will find no matches since
+the query itself can not be converted and the pattern does not match
+the actual path "/usr/bin/bash".
+
+There's a minor cosmetic issue where the conversion does not add the
+"/usr" directory itself, so theoretically a package containing files
+only under /lib would be listed as containing the directory "/usr/lib"
+but not "/usr", but this shouldn't matter in practice (Debian packages
+contain /usr/share/doc/* anyway). Maybe it could cause issues when
+bootstrapping a new system in case this means trying to create
+/usr/bin before /usr? Could be worked around for example by just
+hardcoding "/usr" as contents of every package (in dpkg), more
+"correct" (and complex) fix, or disabling usrmerge logic for initial
+bootstrap as below.
+
+The usrmerge changes can be disabled by creating the file
+"/var/lib/dpkg/DISABLE_USRMERGE_LOGIC". There's no logic to create
+such a file automatically or to sanity check the existence of usrmerge
+links if the file does not exist. Expect things to break if you run
+this dpkg version on a system without the usrmerge links and without
+creating the file, or if you create the file on an usrmerged system
+after already running this dpkg without it existing.
diff --git a/debian/dpkg.docs b/debian/dpkg.docs
index 308db3568..ebdbd8139 100644
--- a/debian/dpkg.docs
+++ b/debian/dpkg.docs
@@ -1,5 +1,6 @@
 AUTHORS
 THANKS
+README.usrmerge
 debian/README.bug-use

Bug#1015166: RM: usrmerged -- ROM; was not supposed to be approved

[Marco d'Itri]

Package: ftp.debian.org
Severity: normal

I introduced in usrmerge 26 an additional package named usrmerged, but
on request of an ftpmaster I renamed it to usr-is-merged and 
consequently uploaded again the package as usrmerge 27.
I did not expect that usrmerge 26 would be approved, so please just
remove the binary package usrmerged from the archive.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1015165: ITP: coq-record-update -- automatic record fields updaters for Coq

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-record-update
  Version : 0.3.1
  Upstream Author : Tej Chajed
* URL : https://github.com/tchajed/coq-record-update
* License : Expat
  Programming Lang: Coq
  Description : automatic record fields updaters for Coq
 This package provides an automatic and generic way
 to update record fields in Coq.
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain it within the Debian OCaml Maintainers team, along with the
other Coq-related packages.

Cheers,

J.Puydt

Bug#977835: Please package the latest version >= 3.5.2

[Thorsten Glaser]

Nicholas D Steeves dixit:

>Sorry for the extremely belated reply.  I did read your reply soon after
>you sent it :)

No problem, we are all doing this in our spare time…

>Ah, now I see what you mean about 4.x being upstream focus.

They focus on it to the exclusion of 3.x support. It was similar
in the late stages of 3.x alphas for 2.x, but not as bad; they had
a working 2.x and users wanted fixes, and they gave them fixes, but
this resulted in 3.0 being delayed for over a year so they didn’t
want to repeat it. (Of course, 4.0 is still very much away, so it’s
obviously not (just) that…)

>If I run into a bug then I'll dig for new commits.

Thanks! Same here, I have a few queued up and just noticed an
error for the status line when capodaster is used which I’ll fix
since the status line code is from me (and the capo code apparently
was slapped on without fixing internal pitch housekeeping).

>> • parts of the playback functionality is now a “freeware” binary
>>   add-on plugin only available from their in-program download store
>
>Wow, that plugin doesn't sound very nice...  I wonder why it can't be
>released under a dfsg-compatible license?

Ostensibly (the formal answer I got to this when asking on the .org
forums) because “that would then require the sound libraries to also
be open-sourced”, which is obviously wrong. I called Daniel Ray out
on it but he never answered. Months later in an interview for Scoring
Notes, he’s indicated it is so they can use it in a commercial product
of Muse Group where the playback engine is basically the USP of their
iOS äpp, vs competitor äpps. So he lied, as I thought.

>Yes, I completely agree; This sounds like a case where the Debian model
>of a stable base plus backported fixes results in a more reliable tool
>than running the latest available release.

I agree, and most users agreed when I explained this to them.

Those who need chord playback or those other rare new-in-3.x features
can use the chords-to-notes plugin or use the upstream-provided
containerised images, which upstream promotes over the packaging
efforts anyway. (I feel underappreciated sometimes. I hinted at
licence compatibility problems for these, but I don’t really want
to stick time into *that* given the Debian packages are fine.)

>Also, it sounds like it will
>be best to wait for the future-4.x series' first beta before starting to
>work on a musecore4 package.
>
>Would you please consider keeping this bug open in case other people
>wonder why things are the way they are with Musescore in Debian?

Sure!

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#1002630: pipewire: enable roc module

[Dylan Aïssi]

Hi,

Le mar. 12 juil. 2022 à 21:48, Daniel Lundqvist
 a écrit :
>
> Hey,
>
> On Mon, 27 Dec 2021 21:36:43 -0500 nick black  wrote:
> > awesome. i've got one now, but it needs some prettification.
> > expect it soon.
>
> I'm also interested in this. Is there anything I can do to help?
>

The ROC library is still not available in Debian. Can you package it?

Best,
Dylan

Bug#1015149: vim-addon-manager is no longer desirable for packaging Vim plugins

[Antonio Terceiro]

Hi,

On Sat, Jul 16, 2022 at 10:15:02PM +0300, Nicholas Guriev wrote:
> Package: vim-addon-manager
> 
> This message states that deprecated vim-addon-manager(1) should not be used 
> within Debian codebase.
> VAM was written in aughts to simplify installation of third-party scripts for 
> Vim editor. Nowadays this editor has got a built-in replacement, Vim packages 
> (see doc in :help packages).
> 
> vim-addon-manager requires maintainers to manually track internal files in a 
> plugin, to write post{inst,rm} scripts risking of mistakes. There are many 
> chances things go wrong if a user interferes with symlinks under ~/.vim 
> controlled by VAM. And moreover, it does not work in NeoVim.
> 
> Debian packages that provide Vim plugins can put a symlink to /usr/share/vim/
> vimfiles/pack/*/{start,opt} and Vim will add it to 'runtimepath'. NeoVim 
> looks 
> into /usr/share/nvim/site/pack/*/{start,opt}. The helper dh_vim-addon(1) 
> automates this process in build time.
> 
> We are going to raise the bug report to RC after bookworm, so Debian 13 will 
> not offer vim-addon-manager.
> 
> All this also deprecates vim-registry(5) format of YAML files.

FWIW, I think this is the right thing to do.

Did you also, or are you planning to, report bugs against all packages
that currently rely on vim-addon-manager? e.g.

$ apt-file search /usr/share/vim/registry/
apparmor-utils: /usr/share/vim/registry/vim-apparmor.yaml
asymptote: /usr/share/vim/registry/asymptote.yaml
biosyntax-vim: /usr/share/vim/registry/biosyntax-vim.yaml
cernlib-base: /usr/share/vim/registry/cernlib-base.yaml
clustershell: /usr/share/vim/registry/clustershell.yaml
coccinelle: /usr/share/vim/registry/coccinelle.yaml
crmsh: /usr/share/vim/registry/vim-pcmk.yaml
di-netboot-assistant: /usr/share/vim/registry/disources.yaml
espeak-ng-data: /usr/share/vim/registry/espeak.yaml
global: /usr/share/vim/registry/global.yaml
gtypist: /usr/share/vim/registry/gtypist.yaml
halibut: /usr/share/vim/registry/halibut.yaml
mpop: /usr/share/vim/registry/mpop.yaml
msmtp: /usr/share/vim/registry/msmtp.yaml
nescc: /usr/share/vim/registry/vim-syntax-nesc.yaml
nginx-common: /usr/share/vim/registry/nginx.yaml
notmuch-vim: /usr/share/vim/registry/notmuch.yaml
ocaml-tools: /usr/share/vim/registry/vim-omlet.yaml
powerline: /usr/share/vim/registry/powerline.yaml
python-mako-doc: /usr/share/vim/registry/mako.yaml
python3-jinja2: /usr/share/vim/registry/jinja.yaml
ragel: /usr/share/vim/registry/ragel.yaml
sisu: /usr/share/vim/registry/vim-sisu.yaml
survex: /usr/share/vim/registry/vim-survex.yaml
systemtap-common: /usr/share/vim/registry/systemtap.yaml
tpp: /usr/share/vim/registry/tpp.yaml
vifm: /usr/share/vim/registry/vim-vifm.yaml
vim-addon-mw-utils: /usr/share/vim/registry/vim-addon-mw-utils.yaml
vim-airline: /usr/share/vim/registry/vim-airline.yaml
vim-airline-themes: /usr/share/vim/registry/vim-airline-themes.yaml
vim-autopep8: /usr/share/vim/registry/vim-autopep8.yaml
vim-bitbake: /usr/share/vim/registry/vim-bitbake.yaml
vim-command-t: /usr/share/vim/registry/command-t.yaml
vim-ctrlp: /usr/share/vim/registry/ctrlp.yaml
vim-editorconfig: /usr/share/vim/registry/vim-editorconfig.yaml
vim-fugitive: /usr/share/vim/registry/vim-fugitive.yaml
vim-haproxy: /usr/share/vim/registry/vim-haproxy.yaml
vim-julia: /usr/share/vim/registry/vim-julia.yaml
vim-khuno: /usr/share/vim/registry/vim-khuno.yaml
vim-lastplace: /usr/share/vim/registry/vim-lastplace.yaml
vim-latexsuite: /usr/share/vim/registry/vim-latexsuite.yaml
vim-migemo: /usr/share/vim/registry/vim-migemo.yaml
vim-pathogen: /usr/share/vim/registry/vim-pathogen.yaml
vim-python-jedi: /usr/share/vim/registry/python-jedi.yaml
vim-rails: /usr/share/vim/registry/vim-rails.yaml
vim-snipmate: /usr/share/vim/registry/vim-snipmate.yaml
vim-snippets: /usr/share/vim/registry/vim-snippets.yaml
vim-syntastic: /usr/share/vim/registry/vim-syntastic.yaml
vim-syntax-gtk: /usr/share/vim/registry/vim-syntax-gtk.yaml
vim-tabular: /usr/share/vim/registry/vim-tabular.yaml
vim-textobj-user: /usr/share/vim/registry/vim-textobj-user.yaml
vim-tjp: /usr/share/vim/registry/vim-tjp.yaml
vim-tlib: /usr/share/vim/registry/vim-tlib.yaml
vim-ultisnips: /usr/share/vim/registry/vim-ultisnips.yaml
vim-vimerl: /usr/share/vim/registry/vim-vimerl.yaml
vim-vimerl-syntax: /usr/share/vim/registry/vim-vimerl-syntax.yaml
vim-youcompleteme: /usr/share/vim/registry/vim-youcompleteme.yaml


signature.asc
Description: PGP signature

Bug#977835: Please package the latest version >= 3.5.2

[Nicholas D Steeves]

Hi Thorsten,

Sorry for the extremely belated reply.  I did read your reply soon after
you sent it :)

Thorsten Glaser  writes:

> (warning, bit of rambling, plus I was interruped multiple times while
> writing this and not fully awake yet either)
>

No worries, and I appreciate your detailed explanation!

> Nicholas D Steeves dixit:
>
>>In an earlier update you mentioned that there were numerous regressions
>>and problems with these new releases.  Are these limited to non-dfsg
>
> No, they are core UX, such as note input mode.
>

Oh, wow, yeah, that sounds like this would need a lot of work.

[snip rationale for sticking with 3.2.3]

> • 3.6.2 is a rather old (2021-02-08) and *also* buggy release
>

Oh my.

> • there’s a community 3.7 effort that’s already got no less than 323
>   commits with bugfixes relative to 3.6.2
>   ‣ this is what I’d probably work on if not for…
>   ‣ this is completely unsupported on mu͒.com *and* by upstream formally
>   ‣ it has no releases, only git snapshots, with occasional rebases,
> and occasionally introduces regressions on itself
>

Ah, now I see what you mean about 4.x being upstream focus.

> At this point in time, I believe that keeping the 3.2.3 we have and
> backporting bugfixes to that, in the musescore3 package, and packaging
> musescore4 once it’s out, is (given effort/gain) the best thing to do.
>

Agreed!

> You *can* help in identifying commits that have gone into 3.3+ that
> correct issues, I’m aware of at least the frame vs. pagebreak one.
> However, we *cannot* backport some changes because they alter the
> file format and the mu͒.com (and 3.3+) importers will see it’s a 3.2
> file and therefore expect certain issues to be present. I’m aware
> there’s at least one change we cannot do.
>

If I run into a bug then I'll dig for new commits.

> Note that our 3.2 package already has about a hundred backported
> fixes already, too… and also note that 3.3+ use QML much more, which
> involves qtweb* stuff more…
>

Wow, that's amazing.  Thank you again for your work :)

> We *can* package *either* 3.6.2 *or* the 3.7 community effort, but
> almost certainly(?) not both, in addition to the aforementioned plan.
> However:
> • until the UX regressions are addressed (and we’re sure that there
>   are no other regressions against the very stable 3.2 codebase we
>   currently use), I’d prefer this to not replace the 3.2 package
>   ‣ we do have musescore-snapshot, which we can use, even with sid
> ⇒ this name would fit the 3.7 community effort better ☻
> • ftpmasters might eventually protest the addition of even more
>   musescoreXXX packages; we have justifyable reason for at least
>   musescore{2,3,4} and probably -snapshot
> • losing mu͒.com support is certainly a disservice to users, but so
>   is updating to a >1-year-old known-buggy version :~
>

Agreed, it sounds like we'd be worse off with 3.6.2 or 3.7 at this
time.

> We could, on the other hand, package git master (“to be 4.x”) now
> already, to get a feeling for it. I’d treat it as almost completely
> new packaging project; certainly for d/copyright at least (much of
> the old code was removed, almost all of it was moved path‑ and file‐
> name-wise, and all was reindented). We could do it as m-snapshot in
> experimental, or even as musescore4, going through ftpmaster review
> for it (but maybe not this early yet?).

Agreed, from what you're saying it sounds like it's still too early.

> Things to watch out:
> • qtweb* stuff (not portable to all architectures, disable)
>   ‣ also: phones home, e.g. I disabled the Start Centre in 3.x
> because it loads from yandex.ru and lately also Google Analytics

Oh my...

> • phoning home in general (update checker, etc.)
> • parts of the playback functionality is now a “freeware” binary
>   add-on plugin only available from their in-program download store

Wow, that plugin doesn't sound very nice...  I wonder why it can't be
released under a dfsg-compatible license?

> • … maybe more
>
> If you have interest in *that*, it might be more long-term beneficial.
> They just (end of March 2022) released the first alpha of it. And I’ll
> be available for help and review, too, of course. My current focus is
> on backporting fixes to our known-good 3.2.3 version, though.
>
> Hmm. I seem to have lost my mental thread here. Eh, anyway, written
> a lot already — tell me what you think.

This is a perfect conclusion.  Thank you very much for taking the time
to explain all of the outstanding issues, and once again I'm sorry for
taking so long to reply.

Yes, I completely agree; This sounds like a case where the Debian model
of a stable base plus backported fixes results in a more reliable tool
than running the latest available release.  Also, it sounds like it will
be best to wait for the future-4.x series' first beta before starting to
work on a musecore4 package.

Would you please consider keeping this bug open in case other people
wonder why things are the way they are wit

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

On Thu, Jul 14, 2022 at 04:20:18PM -0400, Matt Barry wrote:
> On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote:
> > The use case below, and any other tools that create files and know to
> > set their permissions appropriately but don't expect unusual
> > ownership
> > by default:
> > > > In particular, it is common to build various kinds of filesystem,
> > > > container, or disk images, and to do so within your home
> > > > directory.
> > > > Users writing tools and scripts to build such images need to make
> > > > sure
> > > > to create files with an appropriate mode, but such scripts often
> > > > assume
> > > > (reasonably) that if they're running as root:root and they create
> > > > a
> > > > file, that file will be owned by root:root. Attempting to build
> > > > filesystems, containers, disk images, or similar in an
> > > > unexpectedly
> > > > setgid directory will produce unexpected results (leaving aside
> > > > that the
> > > > directory mode itself will be surprising).
> 
> Could you be just slightly more specific about a use case that fails? 
> Given how many times this has come up over the years, I'm trying to get
> a sense of what the *actual* issues are (as opposed to what they used
> to be).
> 
> Enough instruction that I can reproduce a specific problem(s) would be
> great.

Sure. Here's a sample of the kind of script I regularly encounter,
producing incorrect results in a setgid directory. The script expects to
produce files owned by root:root, but the files and directories get the
wrong group, and the setgid bit gets propagated to the constructed
filesystem image.

/tmp/testdir$ ls -ld
drwxr-sr-x 2 josh josh 4096 Jul 16 13:40 .
/tmp/testdir$ ls -l
total 4
-rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh
/tmp/testdir$ cat make-filesystem.sh
#!/bin/bash
if [ "$(id -u)" -ne 0 ]; then
echo Run as root >&2
exit 1
fi

umask 022

mkdir fsroot fsroot/bin fsroot/etc fsroot/srv
mkdir -m 0700 fsroot/srv/workdir
echo 'nameserver 169.254.169.253' > fsroot/etc/resolv.conf
printf '#!/bin/sh\necho example binary\n' > fsroot/bin/example
chmod a+x fsroot/bin/example

mke2fs -d fsroot root.img 16M
/tmp/testdir$ sudo ./make-filesystem.sh
mke2fs 1.46.5 (30-Dec-2021)
Creating regular file root.img
Creating filesystem with 16384 1k blocks and 4096 inodes
Filesystem UUID: ec2c8666-96d9-4bce-b964-4c32ed098638
Superblock backups stored on blocks:
8193

Allocating group tables: done
Writing inode tables: done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done

/tmp/testdir$ ls -l
total 1196
drwxr-sr-x 5 root josh 4096 Jul 16 13:41 fsroot
-rwxr-xr-x 1 josh josh  354 Jul 16 13:40 make-filesystem.sh
-rw-r--r-- 1 root josh 16777216 Jul 16 13:41 root.img
/tmp/testdir$ mkdir /tmp/testmount
/tmp/testdir$ sudo mount -o loop root.img /tmp/testmount
/tmp/testdir$ sudo ls -lR /tmp/testmount/
/tmp/testmount/:
total 15
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 bin
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 etc
drwx-- 2 root root 12288 Jul 16 13:41 lost+found
drwxr-sr-x 3 root josh  1024 Jul 16 13:41 srv

/tmp/testmount/bin:
total 1
-rwxr-xr-x 1 root josh 30 Jul 16 13:41 example

/tmp/testmount/etc:
total 1
-rw-r--r-- 1 root josh 27 Jul 16 13:41 resolv.conf

/tmp/testmount/lost+found:
total 0

/tmp/testmount/srv:
total 1
drwx--S--- 2 root josh 1024 Jul 16 13:41 workdir

/tmp/testmount/srv/workdir:
total 0

Bug#1015163: kodi-data: please provide an equivalent of the example 10-allow-update.pkla for polkit >= 0.106

[Simon McVittie]

Package: kodi-data
Version: 2:19.4+dfsg2-2
Severity: wishlist
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

kodi-data currently ships an example polkit 0.105 configuration fragment at
/usr/share/kodi/addons/service.xbmc.versioncheck/resources/polkit/10-allow-update.pkla,
but does not seem to have a polkit >= 0.106 equivalent.
I'm reporting this at wishlist level since it's only an example file and
not something that is used in production by default.

Newer upstream versions of polkit use a JavaScript-based policy rules
syntax. The equivalent of /etc/polkit-1/localauthority/50-local.d/*.pkla
for local sysadmin configuration is /etc/polkit-1/rules.d/*.rules.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

(These are installed into /var/lib/polkit-1/localauthority/10-vendor.d/
and /usr/share/polkit-1/rules.d/ respectively, because they are distro
vendor defaults rather than local configuration.)

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015162: ukui-session-manager: installs polkit configuration to a location reserved for the sysadmin

[Simon McVittie]

Package: ukui-session-manager
Version: 3.0.5-1
Severity: minor

ukui-session-manager installs its policy configuration for polkit <= 0.105
in /etc/polkit-1/localauthority/50-local.d/, which is a location that is
intended to be reserved for the sysadmin's local configuration.

Distribution vendor defaults for polkit <= 0.105 are meant to be installed
in /var/lib/polkit-1/localauthority/10-vendor.d/ instead, which allows a
local sysadmin to override them by writing files into
/etc/polkit-1/localauthority/. The systemd and flatpak packages are good
examples of setting this up correctly.

Thanks,
smcv

Bug#1015161: ukui-session-manager: please provide an equivalent of com.ubuntu.enable-hibernate.pkla for polkit >= 0.106

[Simon McVittie]

Package: ukui-session-manager
Version: 3.0.5-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

ukui-session-manager currently ships a polkit 0.105 configuration fragment at
/etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015160: sms4you: please provide an equivalent of sms4you.pkla for polkit >= 0.106

[Simon McVittie]

Package: sms4you
Version: 0.0.7-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

sms4you currently ships a polkit 0.105 configuration fragment at
/var/lib/polkit-1/localauthority/10-vendor.d/sms4you.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1014850: O: python-imaplib2 -- Threaded Python IMAP4 client (Python 3)

[Sudip Mukherjee]

Control: owner -1 !
Control: retitle -1 "ITA: python-imaplib2 -- Threaded Python IMAP4 client 
(Python 3)"
--


On Wed, Jul 13, 2022 at 10:43:29AM +0300, Ilias Tsitsimpis wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: Sudip Mukherjee , Ulises Vitulli 
> 
> Control: affects -1 src:python-imaplib2
> 
> I intend to orphan the python-imaplib2 package. Since this package is
> used by OfflineIMAP, I have reached out to Sudip Mukherjee (CC-ed) who
> is willing to adopt this package (thank you Sudip).

Thanks Ilias for maintaining this package for so many years.


--
Regards
Sudip

Bug#1015159: lomiri-schemas: please provide an equivalent of 50-com.lomiri.AccountsService.pkla for polkit >= 0.106

[Simon McVittie]

Package: lomiri-schemas
Version: 0.1.1-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

lomiri-schemas currently ships a polkit 0.105 configuration fragment at
/var/lib/polkit-1/localauthority/10-vendor.d/50-com.lomiri.AccountsService.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015158: cpupower-gui: please provide an equivalent of org.rnd2.cpupower-gui.pkla for polkit >= 0.106

[Simon McVittie]

Package: cpupower-gui
Version: 0.7.2-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

cpupower-gui currently ships a polkit 0.105 configuration fragment
at /var/lib/polkit-1/localauthority/10-vendor.d/org.rnd2.cpupower-gui.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015156: ayatana-indicator-sound: please provide equivalents of .pkla files for polkit >= 0.106

[Simon McVittie]

Package: ayatana-indicator-sound
Version: 22.2.0-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

ayatana-indicator-sound currently ships polkit 0.105 configuration fragments
at 
/var/lib/polkit-1/localauthority/10-vendor.d/50-org.ayatana.AccountsService.Sound.pkla
and 
/var/lib/polkit-1/localauthority/10-vendor.d/50-org.ayatana.indicator.sound.AccountsService.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015157: gnome-control-center: segfaults reproducibly on sharing panel

[Ansgar]

Package: gnome-control-center
Version: 1:42.3-1
Severity: normal
Tags: upstream

gnome-control-center segfaults reproducibly about 1-2 seconds after
opening the "Sharing" panel.  I've installed debug symbols and got the
following backtrace from the coredump caught by systemd-coredumpd:

+---
| (gdb) bt
| #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
| #1  0x7fee5a14f258 in gtk_editable_insert_text (editable=0x55664edfe490, 
text=0x0, length=-1, 
| position=0x7ffc55a116c4) at ../../../gtk/gtkeditable.c:504
| #2  0x7fee5a14f6e9 in gtk_editable_set_text (editable=0x55664edfe490, 
text=text@entry=0x0)
| at ../../../gtk/gtkeditable.c:617
| #3  0x55664d9db8fb in cc_sharing_panel_setup_remote_desktop_dialog 
(self=0x55664ed26250)
| at ../panels/sharing/cc-sharing-panel.c:1397
| #4  remote_desktop_name_appeared (connection=, name=, 
| name_owner=, user_data=) at 
../panels/sharing/cc-sharing-panel.c:1434
| #5  0x7fee5addfb53 in actually_do_call 
(call_type=CALL_TYPE_NAME_APPEARED, 
| name_owner=, connection=, 
client=0x55664e9e22f0)
| at ../../../gio/gdbusnamewatching.c:185
| #6  actually_do_call (call_type=CALL_TYPE_NAME_APPEARED, 
name_owner=, 
| connection=, client=0x55664e9e22f0) at 
../../../gio/gdbusnamewatching.c:173
| #7  do_call (client=0x55664e9e22f0, call_type=CALL_TYPE_NAME_APPEARED)
| at ../../../gio/gdbusnamewatching.c:248
| #8  0x7fee5ade0221 in call_appeared_handler (client=0x55664e9e22f0)
| at ../../../gio/gdbusnamewatching.c:260
| #9  call_appeared_handler (client=0x55664e9e22f0) at 
../../../gio/gdbusnamewatching.c:253
| #10 get_name_owner_cb (source_object=, res=, 
| user_data=user_data@entry=0x55664e9e22f0) at 
../../../gio/gdbusnamewatching.c:417
| #11 0x7fee5ad77fa9 in g_task_return_now (task=0x55664ebecd80) at 
../../../gio/gtask.c:1230
| #12 0x7fee5ad78b0b in g_task_return (type=, 
task=0x55664ebecd80)
| at ../../../gio/gtask.c:1299
| #13 g_task_return (task=0x55664ebecd80, type=) at 
../../../gio/gtask.c:1256
| #14 0x7fee5add587f in g_dbus_connection_call_done (source=, result=0x55664ebec900, 
| user_data=user_data@entry=0x55664ebecd80) at 
../../../gio/gdbusconnection.c:5879
| #15 0x7fee5ad77fa9 in g_task_return_now (task=0x55664ebec900) at 
../../../gio/gtask.c:1230
| #16 0x7fee5ad77fe9 in complete_in_idle_cb (task=0x55664ebec900) at 
../../../gio/gtask.c:1244
| #17 0x7fee5ab81eb4 in g_main_dispatch (context=0x55664e95ed10) at 
../../../glib/gmain.c:3417
| #18 g_main_context_dispatch (context=0x55664e95ed10) at 
../../../glib/gmain.c:4135
| #19 0x7fee5ab82258 in g_main_context_iterate 
(context=context@entry=0x55664e95ed10, 
| block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4211
| #20 0x7fee5ab8230f in g_main_context_iteration 
(context=context@entry=0x55664e95ed10, 
| may_block=may_block@entry=1) at ../../../glib/gmain.c:4276
| #21 0x7fee5ada79ad in g_application_run (application=0x55664e95b110, 
argc=argc@entry=1, 
| argv=argv@entry=0x7ffc55a11ae8) at ../../../gio/gapplication.c:2569
| #22 0x55664d958d84 in main (argc=1, argv=0x7ffc55a11ae8) at 
../shell/main.c:60
+---[ $ coredumpctl debug /usr/bin/gnome-control-center ]

Ansgar

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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:42.3-1
ii  gnome-desktop3-data   42.2-1
ii  gnome-remote-desktop  42.3-1
ii  gnome-settings-daemon 42.2-1
ii  gsettings-desktop-schemas 42.0-1
ii  libaccountsservice0   22.08.8-1
ii  libadwaita-1-01.1.2-1
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.41.0-4
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.3-1
ii  libgnome-bg-4-1   42.2-1
ii  libgno

Bug#1015155: neatvnc: copyright Joseph Werle for murmurhash missing

[Johannes Schauer Marin Rodrigues]

Source: neatvnc
Version: 0.5.1+dfsg-1
Severity: serious
Justification: Policy 2.3
X-Debbugs-Cc: jo...@debian.org

Hi,

your recent upload of neatvnc introduced murmurhash which is copyright
"2014 Joseph Werle" but you did not add that to d/copyright:

https://sources.debian.org/src/neatvnc/0.5.1%2Bdfsg-1/src/murmurhash.c/

Thanks!

cheers, josch

Bug#1015154: arctica-greeter: please provide an equivalent of arctica-greeter.pkla for polkit >= 0.106

[Simon McVittie]

Package: arctica-greeter
Version: 0.99.1.5-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: pkla-without-js

arctica-greeter currently ships a polkit 0.105 configuration fragment
at /var/lib/polkit-1/localauthority/10-vendor.d/arctica-greeter.pkla,
but does not seem to have a polkit >= 0.106 equivalent in
/usr/share/polkit-1/rules.d. This means the customizations to the default
polkit policies that are made by this package will not be taken into
account when running polkit >= 0.106.

Debian and Ubuntu are currently using polkit 0.105 with the old .pkla
rules (and an increasingly large patch series to fix 9 years' worth of
bugs and security vulnerabilities), but it has become clear that this
is not sustainable, and I'm looking at whether we can replace polkit
0.105 with version 121 or newer for Debian 12. You can try these newer
versions by installing the polkitd and polkitd-javascript packages
from experimental.

To make this transition go smoothly, packages that ship a
.pkla file should also provide an equivalent JavaScript file
/usr/share/polkit-1/rules.d/*.rules which will be used by newer versions
of polkit. Most already do, but this is one of a few that do not. It is
appropriate to contribute these .rules files upstream.

System administrators can override the rules in /usr/share/polkit-1/rules.d
by creating a file of the same name in /etc/polkit-1/rules.d, or add
local rules by creating a file with a different name in
/etc/polkit-1/rules.d.

Please don't remove the .pkla file when adding the .rules file: keep the
.pkla file in place until this transition has finished.

/usr/share/polkit-1/actions/*.policy files are not affected by this
transition: they are used by both the old and new versions of polkit.

For example, here's the .pkla file for systemd-networkd in stable, which
allows the systemd-network user to take some privileged actions:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.pkla/
and here's the JavaScript equivalent:
https://sources.debian.org/src/systemd/247.3-7/src/network/systemd-networkd.rules/

flatpak, fwupd and network-manager have other good examples.

Thanks,
smcv

Bug#1015153: uif: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: uif
Version: 1.99.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for uif
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of uif debconf templates to German
# Copyright (C) Cajus Pollmeier , 2003.
# Copyright (C) Helge Kreutzmann , 2008, 2022.
# Copyright (C) Mike Gabriel , 2013.
# This file is distributed under the same license as the uif package.
#
msgid ""
msgstr ""
"Project-Id-Version: uif 1.99.0-4\n"
"Report-Msgid-Bugs-To: u...@packages.debian.org\n"
"POT-Creation-Date: 2022-05-06 19:27+0200\n"
"PO-Revision-Date: 2022-07-16 21:46+0200\n"
"Last-Translator: Mike Gabriel \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#: ../templates:1001
msgid "don't touch"
msgstr "nicht ändern"

#. Type: select
#. Choices
#: ../templates:1001
msgid "workstation"
msgstr "Arbeitsstation"

#. Type: select
#. Choices
#: ../templates:1001
msgid "debian-edu-router"
msgstr "debian-edu-router"

#. Type: select
#. Description
#: ../templates:1002
msgid "Firewall configuration method"
msgstr "Firewall Konfigurationsmethode"

#. Type: select
#. Description
#: ../templates:1002
msgid ""
"Please choose whether the firewall should be configured now with a simple "
"\"workstation\" setup, given a specialized Debian Edu Router configuration, "
"or left unconfigured so that you can manually edit /etc/uif/uif.conf."
msgstr ""
"Bitte wählen Sie aus, ob die Firewall jetzt mit einer einfachen "
"»workstation«-Installation konfiguriert werden, eine spezialisierte Debian-"
"Edu-Router-Konfiguration erhalten oder unkonfiguriert verbleiben soll, so "
"dass Sie manuell /etc/uif/uif.conf bearbeiten können."

#. Type: string
#. Description
#: ../templates:2001
msgid "Trusted DNS hostnames:"
msgstr "Eingabe der vertrauenswürdigen Rechner/Netze:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"In workstation mode, you can specify some DNS hostnames to be globally "
"trusted. All incoming traffic coming from these will be allowed. Multiple "
"entries must be separated with spaces."
msgstr ""
"Im »Arbeitsstation«-Modus kann eine Liste von Rechnern oder Netzen angegeben "
"werden, die als vertrauenswürdig angesehen werden. Diese haben dann "
"kompletten Zugriff auf die Arbeitsstation. Mehrere Einträge sind durch ein "
"Leerzeichen zu trennen."

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"Hostnames provided here must be resolvable to both IPv4 and IPv6 addresses."
msgstr ""
"Hier angegebene Rechnernamen müssen sowohl auf IPv4- als auch auf IPv6-"
"Adressen auflösbar sein."

#. Type: string
#. Description
#: ../templates:2001
msgid "Example: trusted-host-v4-and-v6.mydomain.com"
msgstr "Beispiel: trusted-host-v4-and-v6.mydomain.com"

#. Type: string
#. Description
#: ../templates:3001
msgid "Trusted IPv4 hosts and/or networks:"
msgstr "Vertrauenswürdige IPv4-Rechner/Netzwerke:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"In workstation mode, you can specify some IPv4 hosts or networks to be "
"globally trusted. All incoming traffic coming from these will be allowed. "
"Multiple entries must be separated with spaces."
msgstr ""
"Im »Arbeitsstation«-Modus kann eine Liste von IPv4-Rechnern oder Netzen 
angegeben "
"werden, die als global vertrauenswürdig angesehen werden. Sämtlicher "
"eingehender Verkehr von diesen wird erlaubt. Mehrere Einträge sind durch ein "
"Leerzeichen zu trennen."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"If you want to trust DNS hostnames that only resolve to an IPv4 address, "
"please enter them here."
msgstr ""
"Falls Sie DNS-Rechnernamen vertrauen möchten, die nur über eine IPv4-Adresse "
"aufgelöst werden können, geben Sie diese bitte hier ein."

#. Type: string
#. Description
#: ../templates:3001
msgid "Example: 10.1.0.0/16 trusted-host-v4-only.mydomain.com 192.168.1.55"
msgstr "Beispiel: 10.1.0.0/16 trusted-host-v4-only.mydomain.com 192.168.1.55"

#. Type: string
#. Description
#: ../templates:4001
msgid "Trusted IPv6 hosts and/or networks:"
msgstr "Vertrauenswürdige IPv6-Rechner/Netzwerke:"

#. Type: string
#. Description
#: ../templates:4001
msgid ""
"In workstation mode, you can specify some IPv6 hosts or networks to be "
"globally trusted. All incoming traffic coming from these will be allowed. "
"Multiple entries must be separated with spaces."
msgstr ""
"Im »Arbeitsstation«-Modus kann eine Liste von IPv6-Rechnern oder Netzen 
angegeben "
"werden, die als global vertrauenswürdig angesehen werden. Sämtlicher "
"eingehender Verkehr von diesen wird erlaubt. Mehrere Einträge sind durch ein "
"Lee

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

Le 16/07/2022 à 18:50, Steven Robbins a écrit :

Thank you for the suggestion.  I was completely unaware of "apt-listbugs".

I have just re-titled and changed the severity of this bug.


Great, it can help other users to avoid the upgrade if they want to.


Due to the large dependencies, it is probably very difficult to
downgrade digikam to a version with video support once 4:7.7.0-1
is installed. I did not try for now.


I haven't tried either, so I don't know.  Maybe one can just pull the packages
from the last stable release?  Build the 7.6 source package ?

I would say that there may well be others in your situation so if you do find a
method please report back to this bug.


Reading bug reports (in particular [1] and [2]), the root cause comes from
the ffmpeg transition in Debian. Trying to reverse this would be very
difficult leading to lots of downgrade of other packages (going back to
stable versions).

I'm also afraid that the older digikam would run with a upgraded
database. I'm not sure this won't corrupt some internal tables...

If I've time, I would probably try to build local ffmpeg4 packages
(or to install previous one if they are coinstallable) and rebuild
digikam with ffmpeg4. Of cause, this would be a local workaround,
not something sutable for Debian.

  Thanks for your work on digikam packaging

  Vincent

[1] https://bugs.kde.org/show_bug.cgi?id=453840
[2] https://bugs.kde.org/show_bug.cgi?id=448681

Bug#999909: Downgrade severity

[Yadd]

Control: severity -1 important

Hi,

those 2 CVEs are tagged as no-dsa (minor issue), then severity can't be 
"grave". Fix pushed to unstable (4.19.0+dfsg-1)


Cheers,
Yadd

Bug#1015152: ITP: mir-eval -- Common metrics for common audio/music processing tasks

[Josenilson Ferreira da Silva]

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

* Package name: mir_eval
  Version : 0.7.0
  Upstream Author : Name Colin Raffel 
* URL : https://github.com/craffel/mir_eval
* License : Expat/MIT
  Programming Lang: Python
  Description : Common metrics for common audio/music processing tasks

Python library for computing common heuristic accuracy scores for
 various music/audio information retrieval/signal processing tasks.
 .
 Program is being packaged to meet documentation binary dependencies:
 ITP: librosa -- module for audio and music processing
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968467

Bug#1007025: I want to join the DPT

[Bastian Germann]

On Fri, 18 Mar 2022 13:07:11 -0400 anar...@debian.org wrote:

On 2022-03-18 22:22:25, Bo YU wrote:
> Thank you all. I have changed the RFP to ITP for the bug. I can't wait to
> start the adventure. :-)

You should also assign yourself to the ticket, by making your email
address the "owner".

What is the state of this? A Python Team DD should have contacted you about the 
RFS.

Bug#1015068: python-dbusmock: FTBFS: AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0 "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in b'1657951521.419 GetServe

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/martinpitt/python-dbusmock/pull/139

Ça va Lucas,

Lucas Nussbaum [2022-07-16 15:32 +0200]:
> > ==
> > FAIL: test_options (tests.test_notification_daemon.TestNotificationDaemon)
> > notify-send with some options
> > --
> > Traceback (most recent call last):
> >   File 
> > "/<>/.pybuild/cpython3_3.9/build/tests/test_notification_daemon.py",
> >  line 68, in test_options
> > self.assertRegex(log, b'[0-9.]+ Notify "fooApp" 0 "warning_icon" 
> > "title" "my text" \\[\\] {"urgency": 1} 27\n')
> > AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0 
> > "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in 
> > b'1657951503.818 GetServerInformation\n1657951503.819 
> > GetServerInformation\n1657951503.820 Notify "fooApp" 0 "warning_icon" 
> > "title" "my text" [] {"urgency": 1, "sender-pid": 168975} 27\n'

Thanks for the report! The tests need to be adjusted to the new libnotify 0.8.
I fixed this upstream, and will do a new release ASAP.

Bonne soirée,

Martin

Bug#1012935: gf-complete: ftbfs with GCC-12

[Marcos Talau]

Control: tags 1012935 confirmed

Hi there!

This week I've been working on this bug and I've come to some conclusions that
might help in your solution.

1. I confirmed the existence of the bug
 This bug occurs during "dh_auto_test" when gcc-12 is used in the "gf-complete"
compilation process. I used gcc-11 and verified that "dh_auto_test" ran without
errors. Switching to gcc-12 had the same problem reported here.

2. I compiled the package "qemu-user-static" with gcc-12
 After compiling, the problem persisted.

3. I compiled "qemu" using your latest version of git with gcc-12
 Using the development version of qemu also did not solve the problem.

4. I compiled each file that forms the library "libgf_complete.so.1.0.0" 
separately
 I created a script and used the gcc-11 compiler as default and performed the
compilation of each .c file in the "./src" directory. After that I tested with
the following command the existence of runtime errors:

LD_LIBRARY_PATH=/tests/gf-complete/src/.libs qemu-x86_64-static \
-cpu qemu64,-sse3,-ssse3,-sse4.1,-sse4.2 ./test/.libs/gf_unit 64 A -1 -

 Having no errors in the execution, I changed the compiler of each file to 
gcc-12,
until I found the files that had problems when gcc-12 was used. Finished the
process, I located the following files: gf.c, gf_w64.c, and gf_rand.c.

5. I checked the difference between the objects generated by gcc-11 and gcc-12
 Before checking the difference, I had already read the documents [1], [2], and
[3], and I had not found anything to justify the problem that was happening.

[1] https://gcc.gnu.org/gcc-12/porting_to.html
[2] https://gcc.gnu.org/gcc-12/changes.html
[3] https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/NEWS.gcc

 Rereading the qemu error message: "Illegal instruction", I decided to check if
there were any significant differences between the instructions generated by
the gcc-11 and gcc-12 compilers. To do this I used the "elfx86exts" software.
Taking object "libgf_complete_la-gf.o" as an example:

# wget 
https://github.com/pkgw/elfx86exts/archive/refs/tags/elfx86e...@0.5.0.tar.gz
# tar xvf elfx86exts\@0.5.0.tar.gz
# cd elfx86exts-elfx86exts-0.5.0
# cargo build

# cargo run -- /tmp/gcc-11/libgf_complete_la-gf.o
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
 Running `target/debug/elfx86exts /tmp/gcc-11/libgf_complete_la-gf.o`
MODE64 (push)
CMOV (cmovns)
SSE2 (movdqu)
SSE1 (movups)
CPU Generation: Intel Core

# cargo run -- /tmp/gcc-12/libgf_complete_la-gf.o
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
 Running `target/debug/elfx86exts /tmp/gcc-12/libgf_complete_la-gf.o`
MODE64 (push)
CMOV (cmovns)
SSE2 (movd)
SSE41 (pminsd)
SSE1 (movups)
CPU Generation: Penryn

 Comparing the instructions presented above, generated by the gcc-11 and gcc-12
compilers, it can be seen that gcc-12 generated instructions that gcc-11 does
not. That's why qemu gives the error of "Illegal instruction" when using gcc-12
with the options "-cpu qemu64,-sse3,-ssse3,-sse4.1,-sse4.2".


Best Regards,
mt


signature.asc
Description: PGP signature

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2+deb11u1
Severity: important
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com, t...@security.debian.org

This upgrade introduced a segmentation fault:

  firejail:amd64 0.9.64.4-2 → 0.9.64.4-2+deb11u1

This is a sample command where it fails:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 lynx -dump "$arbitrary_URL"

The network namespace “vnet0” is a Tor middlebox.  This command
previously had no problem, but now it crashes with the following
output:

===8<--
  firejail: util.c:910: create_empty_dir_as_root: Assertion `(s.st_mode & 
0) == (mode)' failed.
  Error: proc 23396 cannot sync with peer: unexpected EOF
  Peer 23406 unexpectedly killed (Segmentation fault)
===8<--

I have set the severity to /important/ because this defect makes it
impossible to restrict apps to the Tor network. There is no
workaround. Perhaps torsocks will work in cases where the app is
expected to access the network via common system calls, but in cases
where apps bypass systems calls we have a breach.  E.g. java apps tend
to not function with torsocks.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015150: haskell-product-isomorphic FTBFS: The constructor ‘PlainTV’ should have 2 arguments, but has been given 1

[Adrian Bunk]

Source: haskell-product-isomorphic
Version: 0.0.3.3-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-product-isomorphic&suite=sid

...
src/Data/Functor/ProductIsomorphic/TH/Internal.hs:47:10: error:
• The constructor ‘PlainTV’ should have 2 arguments, but has been given 1
• In the pattern: PlainTV n
  In an equation for ‘getTV’: getTV (PlainTV n) = n
  In an equation for ‘recordInfo'’:
  recordInfo'
= d
where
d (TyConI tcon)
  = do (tcn, bs, r) <- ... <|> ...
   
d _ = Nothing
getTV (PlainTV n) = n
getTV (KindedTV n _) = n
buildT tcn vns = foldl' appT (conT tcn) [varT vn | vn <- vns]
   |
47 |   getTV (PlainTV n)=  n
   |  ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1011620: newsboat - needs update for new gettext crates.

[Peter Michael Green]

While I did not originally plan to NMU this, the bug has gone well over 
a month with no maintainer response, and Fabian Grünbichler said on irc 
that he had tested the patched newsboat and it worked for him, so I have 
decided to NMU it.


Final debdiff attatched.
diff -Nru newsboat-2.21/debian/changelog newsboat-2.21/debian/changelog
--- newsboat-2.21/debian/changelog  2022-03-06 00:26:54.0 +
+++ newsboat-2.21/debian/changelog  2022-07-16 19:13:03.0 +
@@ -1,3 +1,11 @@
+newsboat (2.21-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependencies on gettext-sys, gettext-rs and proptest crates.
+(Closes: #1011620, #1013539)
+
+ -- Peter Michael Green   Sat, 16 Jul 2022 19:13:03 +
+
 newsboat (2.21-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control
--- newsboat-2.21/debian/control2022-03-05 21:46:48.0 +
+++ newsboat-2.21/debian/control2022-06-23 16:47:20.0 +
@@ -26,14 +26,14 @@
librust-nom-7-dev,
librust-curl-sys-0.4+ssl-dev,
librust-libc-0.2-dev,
-   librust-gettext-rs-0.4-dev,
+   librust-gettext-rs-0.7-dev,
librust-natord-1-dev,
librust-clap-2-dev,
-   librust-gettext-sys-0.19-dev,
+   librust-gettext-sys-0.21-dev,
librust-tempfile-3-dev,
-   librust-proptest-0.9+bit-set-dev,
-   librust-proptest-0.9+rusty-fork-dev,
-   librust-proptest-0.9+timeout-dev,
+   librust-proptest-1+bit-set-dev,
+   librust-proptest-1+rusty-fork-dev,
+   librust-proptest-1+timeout-dev,
librust-percent-encoding-2-dev,
librust-section-testing-0.0.4-dev
 Standards-Version: 4.5.0
diff -Nru newsboat-2.21/debian/patches/relax-deps.diff 
newsboat-2.21/debian/patches/relax-deps.diff
--- newsboat-2.21/debian/patches/relax-deps.diff2022-03-05 
21:43:42.0 +
+++ newsboat-2.21/debian/patches/relax-deps.diff2022-06-23 
16:45:28.0 +
@@ -20,7 +20,7 @@
  curl-sys = "0.4.5"
  libc = "0.2"
 -gettext-rs = "0.5.0"
-+gettext-rs = "0.4"
++gettext-rs = "0.7.0"
  natord = "1.0.9"
  lazy_static = "1.4.0"
  
@@ -29,7 +29,7 @@
  
  [dependencies.gettext-sys]
 -version = "0.19.9"
-+version = "0.19.8"
++version = "0.21.0"
  # Don't let the crate build its own copy of gettext; force it to use the one
  # built into glibc.
  features = [ "gettext-system" ]
@@ -38,7 +38,7 @@
  tempfile = "3"
 -# 0.9.6 fixes build failures on Nightly >=2020-04-08: 
https://github.com/newsboat/newsboat/issues/870
 -proptest = ">=0.9.6"
-+proptest = "0.9"
++proptest = "1.0"
  section_testing = "0.0.4"
 Index: newsboat-2.21/rust/regex-rs/Cargo.toml
 ===
@@ -49,4 +49,4 @@
  bitflags = "1.2"
  libc = ">=0.2.69"
 -gettext-rs = "0.5.0"
-+gettext-rs = "0.4.0"
++gettext-rs = "0.7.0"

Bug#1015128: FTBFS probably already resolved

[Dr. Tobias Quathamer]

Dear APT Development Team,

just as a quick info: this FTBFS bug is most likely already resolved 
with the new upload of po4a.


See https://bugs.debian.org/1015087 for a little longer explanation.

I'm not closing this bug, however, because I didn't try to build apt and 
therefore cannot be sure that the bug is resolved.


Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015099: wayvnc: FTBFS: ../src/main.c:504:9: error: too few arguments to function ‘nvnc_set_userdata’

[Johannes Schauer Marin Rodrigues]

Hi Boyuan,

recently you uploaded neatvnc 0.5.1+dfsg-1 without making sure that its reverse
dependencies don't break. This resulted in the following FTBFS for wayvnc. I'm
fixing that now, but in the future, please do a rebuild of your reverse
dependencies before uploading or upload to experimental and notify maintainers
of your reverse dependencies so that they can fix them before a mass bug filing
finds the problem.

Thanks!

cheers, josch

Quoting Lucas Nussbaum (2022-07-16 15:23:55)
> Source: wayvnc
> Version: 0.4.1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220716 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 
> > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always 
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 
> > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 
> > wayvnc.p/src_main.c.o -MF wayvnc.p/src_main.c.o.d -o wayvnc.p/src_main.c.o 
> > -c ../src/main.c
> > ../src/main.c: In function ‘init_nvnc’:
> > ../src/main.c:504:9: error: too few arguments to function 
> > ‘nvnc_set_userdata’
> >   504 | nvnc_set_userdata(self->nvnc, self);
> >   | ^
> > In file included from ../src/main.c:27:
> > /usr/include/neatvnc.h:125:6: note: declared here
> >   125 | void nvnc_set_userdata(void* self, void* userdata, nvnc_cleanup_fn);
> >   |  ^
> > ../src/main.c:508:9: warning: implicit declaration of function 
> > ‘nvnc_display_set_render_fn’; did you mean ‘nvnc_display_get_server’? 
> > [-Wimplicit-function-declaration]
> >   508 | nvnc_display_set_render_fn(self->nvnc_display, on_render);
> >   | ^~
> >   | nvnc_display_get_server
> > ../src/main.c: In function ‘wayvnc_damage_region’:
> > ../src/main.c:578:9: warning: implicit declaration of function 
> > ‘nvnc_display_damage_region’ [-Wimplicit-function-declaration]
> >   578 | nvnc_display_damage_region(self->nvnc_display, damage);
> >   | ^~
> > ../src/main.c: In function ‘wayvnc_process_frame’:
> > ../src/main.c:638:32: error: too few arguments to function ‘nvnc_fb_new’
> >   638 | self->buffer = nvnc_fb_new(width, height, format);
> >   |^~~
> > In file included from ../src/main.c:27:
> > /usr/include/neatvnc.h:144:17: note: declared here
> >   144 | struct nvnc_fb* nvnc_fb_new(uint16_t width, uint16_t height,
> >   | ^~~
> > ../src/main.c:639:17: warning: implicit declaration of function 
> > ‘nvnc_display_set_buffer’; did you mean ‘nvnc_display_feed_buffer’? 
> > [-Wimplicit-function-declaration]
> >   639 | nvnc_display_set_buffer(self->nvnc_display, 
> > self->buffer);
> >   | ^~~
> >   | nvnc_display_feed_buffer
> > [36/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 
> > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always 
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 
> > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 
> > wayvnc.p/src_seat.c.o -MF wayvnc.p/src_seat.c.o.d -o wayvnc.p/src_seat.c.o 
> > -c ../src/seat.c
> > [37/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 
> > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always 
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 
> > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 
> > wayvnc.p/src_output.c.o -MF wayvnc.p/src_output.c.o.d -o 
> > wayvnc.p/src_output.c.o -c ../src/output.c
> > [38/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 
> > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always 
> > -D_FILE_OFFSET_BITS=64 -Wall -W

Bug#1015149: vim-addon-manager is no longer desirable for packaging Vim plugins

[Nicholas Guriev]

Package: vim-addon-manager

This message states that deprecated vim-addon-manager(1) should not be used 
within Debian codebase.
VAM was written in aughts to simplify installation of third-party scripts for 
Vim editor. Nowadays this editor has got a built-in replacement, Vim packages 
(see doc in :help packages).

vim-addon-manager requires maintainers to manually track internal files in a 
plugin, to write post{inst,rm} scripts risking of mistakes. There are many 
chances things go wrong if a user interferes with symlinks under ~/.vim 
controlled by VAM. And moreover, it does not work in NeoVim.

Debian packages that provide Vim plugins can put a symlink to /usr/share/vim/
vimfiles/pack/*/{start,opt} and Vim will add it to 'runtimepath'. NeoVim looks 
into /usr/share/nvim/site/pack/*/{start,opt}. The helper dh_vim-addon(1) 
automates this process in build time.

We are going to raise the bug report to RC after bookworm, so Debian 13 will 
not offer vim-addon-manager.

All this also deprecates vim-registry(5) format of YAML files.

Info:
https://manpages.debian.org/sid/dh_vim-addon
https://tracker.debian.org/pkg/vim-addon-manager
https://vi.stackexchange.com/q/7266


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

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

[Christopher Schramm]

Still no decorations (with Gtk.MessageDialog(decorated=True).show()
followed by Gtk.main())


So you cannot even force decorations? Wow, weird.


Okay, so this is probably some sort of GTK / Xfce4 problem? Should I
report it against some other package (which?), or reassign this report?


Well, your tests where not blueman specific. I don't know what it could 
be. Might be some configuration or something. I'd say the problem sits 
somewhere between / in GTK and xfwm, yes.

Bug#1015132: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'

[Lucas Nussbaum]

On 16/07/22 at 22:17 +0300, Jussi Pakkanen wrote:
> On Sat, 16 Jul 2022 at 17:04, Lucas Nussbaum  wrote:
> 
> > Relevant part (hopefully):
> > > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main':
> > > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: 
> > > undefined reference to `hidden_function'
> > > collect2: error: ld returned 1 exit status
> 
> This is the second time (at least) that this issue has been
> incorrectly reported. This is not a test failure. As you can tell the
> test name has "failing build" in it, which means that failing to
> compile is the correct behaviour. If this report has been done by
> hand, please in the future report the thing that actually failed (if
> any). If this is an automated test then please fix it to not report
> spurious failures like this.

Hi,

The script I use to extract the failure from the log might have guessed
badly indeed, however the build still fails, as shown by the full log
linked in the bug:
http://qa-logs.debian.net/2022/07/16/meson_0.63.0-1_unstable.log
SO I wouldn't call that a "spurious failure".

However looking at the log I don't really understand why the
override_dh_auto_test target fails. Can you explain? Maybe I can improve
my script.

Lucas

Bug#1015148: new upstream (2.x)

[Daniel Baumann]

Package: python-pgspecial

Hi,

thank you for maintaining python-pgspecial in Debian.

While I happen to maintain all other packages from dbcli in Debian, I
noticed, that pgspecial is rather outdated.

Would you mind updating it to the current upstream release? Just in
case, I'm happy to help out if you'd like.

Regards,
Daniel

Bug#1015147: remmina: incompatible with spice-gtk built against libsoup3

[Jeremy Bicha]

Source: remmina
Version: 1.4.27+dfsg-1
Severity: important
Control: forwarded -1 https://gitlab.com/Remmina/Remmina/-/issues/2754

If remmina is run against spice-gtk built against libsoup3, Remmina
won't run but shows this error message:
libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same
process is not supported.

I suggest this temporary change: Drop the spice Build-Depends and stop
building the remmina-plugin-spice package. As long as that package
isn't installed, remmina will run fine.

It's hoped that Remmina will be fixed later this year as distros
package GNOME 43.

Thank you,
Jeremy Bicha

Bug#1015006: gir1.2-notify-0.7: Upgrade to version 0.8.0-1 breaks at least two packages that use Python

[Fabio Fantoni]

Control: affects -1 + cinnamon

This make unable to start also cinnamon-settings



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015146: rust-cbindgen_0.23.0-1~deb10u1_s390x-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-cbindgen
Version: 0.23.0-1~deb10u1
Severity: serious
X-Debbugs-Cc: po...@debian.org

On 2022-07-16 15:34, Debian FTP Masters wrote:
> 
> 
> cbindgen_0.23.0-1~deb10u1_s390x.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/doc/cbindgen/changelog.gz (Thu Nov 29 21:33:09 1973)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 


signature.asc
Description: PGP signature

Bug#1013420: corsix-th FTBFS with ffmpeg 5.0.1

[Alexandre Detiste]

lua-lpeg is orphaned ... someone has to take care of it first;
I might even adopt it.

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

I created a Merge Request:

https://salsa.debian.org/lua-team/lua-lpeg/-/merge_requests/1

Le sam. 16 juil. 2022 à 20:09, Alexandre Detiste
 a écrit :
>
> Hi,
>
> I imported and packaged corsix-th 0.66.
>
> This fix this one build time bug but not the run-time one.
>
> >Welcome to CorsixTH v0.66!
> >
> >An error has occurred in CorsixTH:
> >/usr/share/games/corsix-th/Lua/strict.lua:66: module 'lpeg' not found:
> >no field package.preload['lpeg']
> >no file './lpeg.lua'
> >no file './lpeg/init.lua'
> >[C]: in ?
> >/usr/share/games/corsix-th/Lua/audio.lua:662: attempt to index a nil >value 
> >(field 'ui')
>
> Greetings
>
> Alexandre Detiste

Bug#1012129:

[Fabio Pedretti]

This is fixed also in the dco branch now:
https://github.com/OpenVPN/openvpn/commits/dco?after=63409150834208582031876dab70beefa2ee48f6+34&branch=dco&qualified_name=refs%2Fheads%2Fdco

Bug#1015145: autopkgtest-virt-schroot: fails with restrictive permissions (umask 077)

[Ansgar]

Package: autopkgtest
Version: 5.22
Severity: normal

autopkgtest fails with restrictive permissions:

+---
| $ (umask 077; autopkgtest ../*_4.0.3-6_amd64.deb  . -- schroot unstable-amd64)
| autopkgtest [20:16:45]: starting date: 2022-07-16
| autopkgtest [20:16:45]: version 5.22
| autopkgtest [20:16:45]: host [...]; command line: /usr/bin/autopkgtest [...] 
. -- schroot unstable-amd64
| autopkgtest [20:16:45]: testbed dpkg architecture: amd64
| Unexpected error:
| Traceback (most recent call last):
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 768, in mainloop
| command()
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 697, in command
| r = f(c, ce)
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 635, in cmd_copyup
| copyupdown(c, ce, True)
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 519, in copyupdown
| copyupdown_internal(ce[0], c[1:], upp)
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 544, in 
copyupdown_internal
| copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host)
|   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 458, in 
copyup_shareddir
| shutil.copy(tb, host)
|   File "/usr/lib/python3.10/shutil.py", line 417, in copy
| copyfile(src, dst, follow_symlinks=follow_symlinks)
|   File "/usr/lib/python3.10/shutil.py", line 254, in copyfile
| with open(src, 'rb') as fsrc:
| PermissionError: [Errno 13] Permission denied: 
'/var/run/schroot/mount/unstable-amd64-efaeee30-3ea3-467d-ad24-d7ba96bb1072/tmp/autopkgtest.pbGOEr/testbed-packages'
| autopkgtest [20:16:45]: ERROR: testbed failure: cannot send to testbed: 
[Errno 32] Broken pipe
+---

The run is successful when I call autopkgtest with the unsafe umask 022.

Slighly unrelated: shouldn't `/usr/bin/autopkgtest-virt-schroot` be in
`/usr/lib/autopkgtest` or `/usr/libexec/autopkgtest`? It doesn't seem
to be a tool that users call interactively from their shell and thus
shouldn't be in PATH.

Ansgar

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.5.1
ii  libdpkg-perl1.21.9
ii  procps  2:3.3.17-7+b1
ii  python3 3.10.4-1+b1
ii  python3-debian  0.1.46

Versions of packages autopkgtest recommends:
pn  autodep8  

Versions of packages autopkgtest suggests:
pn  fakemachine   
pn  lxc   
pn  lxd   
ii  ovmf  2022.05-2
pn  ovmf-ia32 
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:7.0+dfsg-7
ii  schroot   1.6.10-16
pn  vmdb2 

-- no debconf information

Bug#1013420: corsix-th FTBFS with ffmpeg 5.0.1

[Alexandre Detiste]

Hi,

I imported and packaged corsix-th 0.66.

This fix this one build time bug but not the run-time one.

>Welcome to CorsixTH v0.66!
>
>An error has occurred in CorsixTH:
>/usr/share/games/corsix-th/Lua/strict.lua:66: module 'lpeg' not found:
>no field package.preload['lpeg']
>no file './lpeg.lua'
>no file './lpeg/init.lua'
>[C]: in ?
>/usr/share/games/corsix-th/Lua/audio.lua:662: attempt to index a nil >value 
>(field 'ui')

Greetings

Alexandre Detiste

Bug#1004831: transition: ffmpeg

[Steven Robbins]

On Saturday, July 16, 2022 12:28:33 P.M. CDT Christian Marillat wrote:
> On 16 juil. 2022 12:02, Steven Robbins  wrote:
> 
> [...]
> 
> > Certainly one can propose.  However, one cannot really expect upstream to
> > change their architecture away from ffmpeg by a given time any more than
> > one can expect them to adapt to ffmeg ABI break in that time.
> 
> Removed functions in version 5 have been deprecated in version 4
> released in July 2018
> 
> 4 years is more than enough to fix that. 

That's a judgement.  I respect your opinion on this.  Equally, I would suggest 
one should respect the upstream opinion on how they spend their development 
resources.  I'm not part of digikam upstream so I have no special knowledge of 
this, but perhaps the existing usage of ffmpeg sufficed and they had other 
priorities to work on.


> Some packages like mpd or mpv
> have been fixed since a long time.

Some have and clearly others have not.

Respectfully,
-Steve


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

Bug#1004831: transition: ffmpeg

[Christian Marillat]

On 16 juil. 2022 12:02, Steven Robbins  wrote:

[...]

> Certainly one can propose.  However, one cannot really expect upstream to 
> change their architecture away from ffmpeg by a given time any more than one 
> can expect them to adapt to ffmeg ABI break in that time.

Removed functions in version 5 have been deprecated in version 4
released in July 2018

4 years is more than enough to fix that. Some packages like mpd or mpv
have been fixed since a long time.

Christian

Bug#905460: Any news and hope for this one ?

[Jérémie Tarot]

Hey,

@per you here again ! ;-)

This one would be very nice to have in next stable as FreeCAD Path is
making steady progresses and uses it for advanced toolpaths features support

Someday I'll finally learn to package...

TY
J

Bug#1015039: gtk4 memorytexture test-case regresses with Mesa 22.1

[Simon McVittie]

Control: retitle -1 gtk4 memorytexture test-case regresses with Mesa 22.1
Control: reassign -1 src:gtk4,src:mesa
Control: found -1 gtk4/4.6.6+ds-1
Control: found -1 mesa/22.1.3-1

On Sat, 16 Jul 2022 at 15:49:25 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > ▶  11/681 
> > ERROR:../../../testsuite/gdk/memorytexture.c:389:compare_textures: 
> > assertion failed (expected_data[y * width + x] == test_data[y * width + 
> > x]): (0x55441155 == 0x) ERROR 
> >  11/681 gtk:gdk / memorytexture 
> > ERROR   0.98s   killed by signal 6 SIGABRT

Context for Mesa maintainers: gtk4 fails one of its build-time tests
when built in a current sid environment. In this test, it fills a local
memory buffer with a random colour, uploads it to a GL texture, downloads
it using glReadPixels and compares each pixel with a matching in-memory
texture. The good result is that the colour is the same; the failing
result observed is that the texture is transparent black, rgba(0,0,0,0).

I can reproduce this test failure with sid's mesa 22.1.3-1, but not with
bookworm's mesa, so it seems like this is probably a mesa regression (or
possibly a mesa behaviour change that means what gtk4 is doing no longer
works).

I can also reproduce this test failure without needing to rebuild gtk4,
by using the installed-tests provided in the gtk-4-tests package. Steps
to reproduce:

# apt build-dep gtk4
# apt install gtk-4-tests xvfb xauth dbus
# adduser --disabled-password user
# runuser -u user -- xvfb-run dbus-run-session -- \
  /usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture \
  || echo "failed with status $?"

In a debian:bookworm-slim podman container, this test succeeds.

With all packages except for src:mesa upgraded from bookworm to sid, this
test still succeeds (see attached working-packages.gz).

With all packages *including* those from src:mesa upgraded from bookworm
to sid, the test starts to fail (see attached not-working-packages.gz).

The test has a lot of versions of the scenario that I described, for
different texture sizes, pixel encodings and upload/download pairs: you
can run it as

/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -l

to list them, and then run with arguments like

/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -p 
/memorytexture/download_4x4/b8g8r8/gl

to run just one version.

>From a bit of experimenting, it seems like the pattern is:

* 1x1/*/gl: fails
* 4x4/*/gl: fails
* 192x192/*/gl: succeeds
* 1x1/*/gl-released: fails
* 4x4/*/gl-released: fails
* 192x192/*/gl-released: fails

The 1x1 or whatever refers to the pixel size of the test texture.
/gl is the sub-test that uploads the texture to GL and then downloads it
again. /gl-released is the same, but it also calls gdk_gl_texture_release(),
documented as:

Releases the GL resources held by a GdkGLTexture.

The texture contents are still available via the
gdk_texture_download() function, after this function has been called.

which seems to be implemented by downloading the GL texture into an
in-memory buffer which will be used as a source for subsequent downloads,
then discarding the actual GL resources. (I don't know why this makes a
difference to whether the 192x192 case succeeds.)

smcv

Bug#1004831: transition: ffmpeg

[Steven Robbins]

On Tue, 5 Jul 2022 10:13:20 +0200 Sebastian Ramacher  
wrote:

> > > Reverse dependencies had 4 months to fix their bugs, so I'm going
> > > ahead with this one.
> > 
> > Not even close to enough time for all affected upstream teams.
> 
> The 4 months only reflects the Debian timeline. If upstreams are not
> able to track the constant changes in ffmpegs API, please propose to
> them to switch to higher level abstractions such as ffms2 or gstreamer.

Certainly one can propose.  However, one cannot really expect upstream to 
change their architecture away from ffmpeg by a given time any more than one 
can expect them to adapt to ffmeg ABI break in that time.

> > Debian has GTK3 and GTK4, Qt5 and Qt6 etc., it's not ideal and it is a
> > lot of work but it may be necessary to have libavcodec4-dev and
> > libavcodec-dev with a new source package ffmpeg4 alongside ffmpeg.
> 
> ffmpeg has a bad history of security issues including RCEs. 

That's a fair observation, and one that deserves to be taken into 
consideration.  Another observation: the ffmeg hard transition means that some 
packages will either be removed or seriously degraded -- as one example, 
digikam has lost ability to process video over this [1].

I think that overall usability of the distribution is an important 
consideration in making design choices.  Certainly one doesn't want a 
distribution riddled with security issues; nor does one want functionality 
removed.  So the question is really one of balance.  If ffmpeg 4 and 5 are both 
offered, with packages strongly encouraged to migrate: the distribution overall 
has improved security stance AND it retains more functionality.

-Steve

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004769

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

Bug#991011: no background image, no font color setting

[肖盛文]

在 2022/7/16 22:52, Scorpion2185 写道:


The /boot/grub/grub.cfg updated like this:

if background_image /atzlinux/IMG_2021.jpg; then
  set color_normal=green/black
  set color_highlight=red/light-cyan
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi


Can you make it use always the first color values?
(And eventually other values like fonts etc.).

When "else" it's triggered.
So if grub doesn't find the image at least the other changes are applied.

I think this is the upstream logical.
If no background image finded or checked, the font color will use 
default color.


If no background image, there is not need to tune the font color, this 
also meet the most situations.




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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004769: Video not handled anymore for now

[Steven Robbins]

On Friday, July 15, 2022 6:27:51 P.M. CDT you wrote:
>Hi,
> 
>This bug is rather anoying as I'm using digikam to manage my video.

I agree it is annoying.  I feel the same pain.

Given the hard-transition of ffmpeg [1], it is not possible to build with video 
in unstable today.  Digikam was temporarily removed from Debian and the only 
way to re-introduce it is to not use ffmpeg at all which has the serious side 
effect to drop video.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004831


> The low severity (and the title of the bug) does not allow one to stop
> the upgrade with apt-listbugs. In my opinion, this bug is at lease
> important (to be seen by apt-listbugs) and its title should reflect
> that video is not handle by digikam for now (or a new bug can be
> created and blocked by this one)

Thank you for the suggestion.  I was completely unaware of "apt-listbugs".  

I have just re-titled and changed the severity of this bug.  

The manpage for apt-listbugs says it displays serious and above by default.  
Therefore, I have made it 'serious' according to the criteria "in the package 
maintainer's or release manager's opinion, makes the package unsuitable for 
release".

>Due to the large dependencies, it is probably very difficult to
> downgrade digikam to a version with video support once 4:7.7.0-1
> is installed. I did not try for now.

I haven't tried either, so I don't know.  Maybe one can just pull the packages 
from the last stable release?  Build the 7.6 source package ?

I would say that there may well be others in your situation so if you do find a 
method please report back to this bug.  

> I hope video will be soon back.

Upstream is certainly aware of the issue and work is underway to migrate to 
the newer ffmpeg.  I am monitoring the upstream mailing list and sources.  
Based on what I see at present, I'm not optimistic for the short term, so if 
you're using testing or unstable you may want to  look into the downgrade 
option.

I am more hopeful that things will be resolved in time for the next Debian 
release. 

Best,
-Steve

Bug#1015132: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'

[Jussi Pakkanen]

On Sat, 16 Jul 2022 at 17:04, Lucas Nussbaum  wrote:

> Relevant part (hopefully):
> > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main':
> > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: 
> > undefined reference to `hidden_function'
> > collect2: error: ld returned 1 exit status

This is the second time (at least) that this issue has been
incorrectly reported. This is not a test failure. As you can tell the
test name has "failing build" in it, which means that failing to
compile is the correct behaviour. If this report has been done by
hand, please in the future report the thing that actually failed (if
any). If this is an automated test then please fix it to not report
spurious failures like this.

Thanks,

Bug#1013985: golang-github-evanw-esbuild: ftbfs in experimental

[Shengjing Zhu]

Control: retitle -1 FTBFS: attempt to build with Go module

On Tue, Jun 28, 2022 at 9:30 PM Jérémy Lal  wrote:
>
> Source: golang-github-evanw-esbuild
> Version: 0.14.43-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> Happened when doing a nodejs 18.4.0 migration check.
> However it doesn't look like it is related to node at all.
> See attached log.
>

The log from reproducible-builds is much clearer. It tries to build
with the go module, which is not possible in the Debian build system.

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-evanw-esbuild.html

-- 
Shengjing Zhu

Bug#1015143: RFS: streamlink/4.2.0-1~bpo11+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bullseye-backports repository.

 * Package name: streamlink
   Version : 4.2.0-1~bpo11+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from various 
websites
  python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_4.2.0-1~bpo11+1.dsc

Changes since the last upload to bullseye-backports:
streamlink (4.2.0-1~bpo11+1) bullseye-backports; urgency=medium

  * Rebuild for bullseye-backports.
  * d/patches,d/control: fix build with older dependencies

 -- Alexis Murzeau   Sat, 16 Jul 2022 17:12:12 +0200

streamlink (4.2.0-1) unstable; urgency=medium

  * New upstream version 4.2.0
  * d/patches: update and rename to default names
  * d/control: update dependencies
  * d/README.source: update build command
  * d/s/lintian-overrides: update with new format
  * Bump Standards-Version to 4.6.1 (no changes)

 -- Alexis Murzeau   Sun, 10 Jul 2022 16:20:13 +0200

streamlink (4.1.0-1) unstable; urgency=medium

  * d/salsa-ci.yml: adjust config to disable non working ones
  * New upstream version 4.1.0
  * Update patches

 -- Alexis Murzeau   Wed, 08 Jun 2022 23:38:11 +0200



Differences from testing package (4.2.0-1):
  * d/README.source: added more information about the package maintenance
  * d/patches,d/control: fix build with older dependencies

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|





signature.asc
Description: OpenPGP digital signature

Bug#1015142: RFP: presets -- python module to manipulate default function parameters

[Bastian Germann]

Package: wnpp
Severity: wishlist
Control: block 968467 by -1

* Package name: presets
  Upstream Author : Brian McFee
* URL : https://github.com/bmcfee/presets
* License : ISC
  Programming Lang: Python
  Description : python module to manipulate default function parameters

Presets provides an object interface that can override common default parameter settings for all functions within a 
target module or package.


It's simple to use. Simply construct a Preset object with the target module as an argument, then set the default 
parameters via a dict-like interface. After that, your new object will act just as the target module, but it replaces 
the default arguments of any functions with values that you set.

Bug#1015141: RM: php-numbers-words -- RoQA; Not maintained upstream

[David Prévot]

Package: ftp.debian.org
Severity: normal

Hi,

php-numbers-words is not maintained upstream, and was not part of stable
since Stretch.

TIA

Regards

David


signature.asc
Description: PGP signature

Bug#1015140: RM: php-http-request -- RoQA; Superseded, not used anymore

[David Prévot]

Package: ftp.debian.org
Severity: normal

Hi,

php-http-request was superseded by php-http-request2, hasn’t seen an
upstream release in 14 years, is only used in Debian by
php-services-weather (removal requested in #1015139), and was not part
of Bullseye.

TIA

Regards

David


signature.asc
Description: PGP signature

Bug#1015139: RM: php-services-weather -- RoQA; Not maintained upstream

[David Prévot]

Package: ftp.debian.org
Severity: normal

Hi,

Last upstream release of php-services-weather was almost ten years ago,
and the package was last part of a stable release with Stretch.

TIA

Regards

David


signature.asc
Description: PGP signature

Bug#1015067: python-shapely: FTBFS: AttributeError: can't set attribute '_is_empty'

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending

On 7/16/22 15:32, Lucas Nussbaum wrote:

=== FAILURES ===
__ OperationsTestCase.test_parallel_offset_linestring __

self = 

 def test_parallel_offset_linestring(self):
 line1 = LineString([(0, 0), (10, 0)])
 left = line1.parallel_offset(5, 'left')
 self.assertEqual(left, LineString([(0, 5), (10, 5)]))
 right = line1.parallel_offset(5, 'right')

   self.assertEqual(right, LineString([(10, -5), (0, -5)]))

E   AssertionError:  != 
This is the actual reason for the FTBFS, not the AttributeError that 
occurs during the tests.


It's caused by changes in GEOS 3.11.0, and fixed upstream already.

The patch has been added to the package and a new upload will follow 
shortly.


Kind Regards,

Bas

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

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Mathieu Malaterre]

Andreas,

On Mon, Jul 11, 2022 at 9:03 PM Andreas Beckmann  wrote:
>
> On 11/07/2022 18.35, Mathieu Malaterre wrote:
> > Since the nvidia* package do the heavy lifting of downloading locally
> > binary, it would make sense to add yet-another package for firmware
> > related within the group.
>
> Putting a downloader package in contrib under the Nvidia Team umbrella
> is fine, but someone needs to come up with an initial implementation.
> A quick glance at the script gave me the impression that you need to
> extract firmware from the 340xx legacy or older drivers.
> Looking at existing packages (e.g. firmware-b43-installer), a name of
> firmware-nouveau-installer might work.

If I understand correctly, all I need is the file
`NVIDIA-Linux-x86-340.108.run` which is distributed directly in
contrib in package nvidia-graphics-drivers-legacy-340xx-340.108.

I'll see if I can patch this package directly instead of duplicating
the code in another package.

-M

Bug#1014995: kea-shell does use original includes

[Paride Legovini]

Hello Kilian and thanks for this bug report, which I can easily reproduce.

Kilian Krause wrote on 15/07/2022:
> Package: kea-ctrl-agent
> 
> After installation the kea-shell does not work because:
> # kea-shell
> Traceback (most recent call last):
>   File "/usr/sbin/kea-shell", line 27, in 
> from kea_conn import CARequest # CAResponse
> ModuleNotFoundError: No module named 'kea_conn'
> #
> 
> Quite obviously with the current python3-kea-connector in Debian
> the following patch does seem correct:
> ---(snip)---
> --- /usr/sbin/kea-shell.orig  2022-07-15 22:20:46.534324145 +0200
> +++ /usr/sbin/kea-shell   2022-07-15 22:21:12.590348119 +0200
> @@ -24,7 +24,7 @@
> 
>  sys.path.append('/usr/lib/python3.10/site-packages/kea')
> 
> -from kea_conn import CARequest # CAResponse
> +from kea.kea_conn import CARequest # CAResponse
> 
>  if sys.version_info[0] == 2:
>  # This is Python 2.x
> @@ -34,7 +34,7 @@
>  return unicode(string, 'utf-8')
>  elif sys.version_info[0] == 3:
>  # This is Python 3.x
> -import kea_connector3 as kea_connector
> +import kea.kea_connector3 as kea_connector
>  auth8 = str
>  else:
>  # This is... have no idea what it is.
> ---(snip)---

I don't think that's the right fix: what we want is this line (in your
patch context):

sys.path.append('/usr/lib/python3.10/site-packages/kea')

to be:

sys.path.append('/usr/lib/python3/site-packages/kea')

which is there the Python files are actually installed. That's templated
upstream:

https://gitlab.isc.org/isc-projects/kea/-/blob/585bd6b4a90287bc659adb414c8ae9cb806b23b1/src/bin/shell/kea-shell.in#L25

but the result is not correct in our case. I'll look into this.

Paride

Bug#882640: ITP: dm-zoned-tools -- utilities for the dm-zoned device mapper

[Ben Hutchings]

Control: retitle -1 RFP: dm-zoned-tools -- utilities for the dm-zoned device 
mapper
Control: noowner -1

I'm moving this back to RFP status, because this package didn't get
sponsored and seems to have disappeared now.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[韓達耐]

Thanks Lucas, I'll look at it tonight.

On Sat, 16 Jul 2022, 22:04 Lucas Nussbaum,  wrote:

> Source: latex-cjk-chinese-arphic
> Version: 1.24
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220716 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > Reading subfont definition file
> `/usr/share/texlive/texmf-dist/fonts/sfd/ttf2pk/Unicode.sfd'...
> > Writing extended font definition file `c70bsmi.fdx'...
> >
> > # Remove the *.enc files; they're not used.
> > ( cd build/bsmi00lp && rm -f *.enc )
> >
> > # Create a Type1 font map.
> >
> > # Create entries for the font definition file
> > # `c00bsmi.fd' (which uses UBig5 encoding).
> >
> > # Create entries for the font definition file
> > # `c70bsmi.fd' (which uses Unicode encoding).
> >
> > touch build-stamp.bsmi
> > E: Build killed with signal TERM after 150 minutes of inactivity
>
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2022/07/16/latex-cjk-chinese-arphic_1.24_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220716;users=lu...@debian.org
> or:
>
> https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20220716&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
>

Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Mark Hindley]

Adam,

On Sat, Jul 16, 2022 at 03:32:55PM +0200, Adam Borowski wrote:
> The _correct_ way would be to write that dependency as
> 'systemd-tmpfiles | systemd' which is no-op on systemd installs but
> avoids init switch elsewhere.

Thanks. That is a good suggestion.

Michael,

I know this issue was raised a few days ago in #1014805 and you rejected any
change, but, as they stand, the udev dependencies are causing problems to users
and apt does not readily find the solution which avoids switching init system.

In your rejection of #1014805 you correctly asserted the first alternative in a
dependency should be a real package. So, perhaps

 systemd-standalone-tmpfiles | systemd-tmpfiles

would satisfy the Policy requirements and not produce unexpected behaviour for
users? On systemd systems it would be noop as systemd provides systemd-tmpfiles
and it would avoid trying to install systemd on non-systemd systems which then
causes conflicts with elogind.

What do you think?

Thanks for your consideration.

Best wishes

Mark

Bug#1014879: Please do not depend on gnome-remote-desktop

[Jeremy Bicha]

On Thu, Jul 14, 2022 at 12:47 AM Marco Perosa  wrote:
> On Wed, 13 Jul 2022 22:51:05 +0200 Jeremy Bicha
>  wrote:
> > Please see https://launchpad.net/bugs/1980606 (which was mentioned in
> > the debian/changelog).
> >
> > Without that dependency, the app crashes.
>
> The above mentioned bug, in addition to being related to a different
> distribution, doesn't seem to be reproducible.

It was reproducible on Ubuntu 22.04 LTS. Thank you for the additional
details. I've made the requested change now.

Thanks,
Jeremy Bicha

Bug#1014984: [Pkg-utopia-maintainers] Bug#1014984: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0: undefined symbol: g_task_set_name in Debian 11

[Dwight Walker]

On Sat, July 16, 2022 15:49, Michael Biebl wrote:
> Am 16.07.22 um 04:56 schrieb Dwight Walker:
>>
>
>> Processing triggers for libglib2.0-0:amd64 (2.66.8-1) ...
>> /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas: symbol lookup
>> error: /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas:
>> undefined
>> symbol: g_task_set_name
>
> Please post the output of
> ldd /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas
>

root@ip-172-30-0-19:~# ldd
/usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas
   linux-vdso.so.1 (0x7ffccad47000)
   libgio-2.0.so.0 => /usr/local/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7fa2b6ad7000)
   libgmodule-2.0.so.0 =>
/usr/local/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x7fa2b68d3000)
   libglib-2.0.so.0 =>
/usr/local/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7fa2b658c000)
   libgobject-2.0.so.0 =>
/usr/local/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x7fa2b6338000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa2b6173000)
   libz.so.1 => /usr/local/lib/libz.so.1 (0x7fa2b5f57000)
   libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1
(0x7fa2b5ef8000)
   libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x7fa2b5ecc000)
   libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x7fa2b5eb2000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fa2b5e9)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa2b5e8a000)
   libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
(0x7fa2b5e8)
   /lib64/ld-linux-x86-64.so.2 (0x7fa2b6eab000)
   libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1
(0x7fa2b5e2d000)
   libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
(0x7fa2b5d95000)

-- 
Dwight Walker
WWWalker Web Development Pty Ltd
https://wwwalker.com.au

Bug#1015088: [Pkg-nagios-devel] Bug#1015088: icingadb: FTBFS: ../pkg/com/bulker.go:30:16: internal compiler error: assertion failed

[Sebastiaan Couwenberg]

reassign 1015088 src:golang-1.18
found 1015088 golang-1.18/1.18.4-1
affects 1015088 src:icingadb
thanks

On 7/16/22 15:21, Lucas Nussbaum wrote:

dh_auto_build
cd _build && go version
go version go1.18.4 linux/amd64
cd _build && go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/<>/_build/go-build"
GOENV="/sbuild-nonexistent/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/<>/_build/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/<>/_build"
GOPRIVATE=""
GOPROXY="off"
GOROOT="/usr/lib/go-1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.18/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/<>/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security"
CGO_CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2"
CGO_CXXFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security"
CGO_FFLAGS="-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong"
CGO_LDFLAGS="-Wl,-z,relro"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build898317925=/tmp/go-build -gno-record-gcc-switches"
cd _build && go install -trimpath -v -p 8 
github.com/icinga/icingadb/cmd/icingadb
[...]
github.com/icinga/icingadb/pkg/com
os/user
# github.com/icinga/icingadb/pkg/com
../pkg/com/bulker.go:30:16: internal compiler error: assertion failed

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new


This issue is introduced in golang-1.18 (1.18.4-1), icingadb built 
successfully with 1.18.3-1.


Kind Regards,

Bas

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

Bug#1001682: should be fixed by the upcoming 1.9.4 version

[Paolo Greppi]

Hi! and thanks for reporting.

I am in the process of packaging doxygen 1.9.4 and this issue seems to 
be fixed in that version.


To test, I did this twice:

cd `mktemp -d`
git clone https://github.com/BYVoid/OpenCC
cd OpenCC/
cd doc
# no need to run cmake etc. just quickly generate the Doxyfile ...
cp opencc.doxy.in Doxyfile
sed -i 's/@CMAKE_SOURCE_DIR@/../g' Doxyfile
sed -i 's/@OPENCC_VERSION/1.1.4/g' Doxyfile
doxygen -u
doxygen

the compared the dirs:

kdiff3 html/ ../../../tmp.bcQZ8jaXXy/OpenCC/doc/html

While with 1.9.1 I get:



with 1.9.4 I get:



so the build path is not embedded anymore.

If you have time to test yourself, you can try with this package here on 
unstable:


https://salsa.debian.org/debian/doxygen/-/jobs/3001759/artifacts/browse/debian/output/

Paolo

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

[duck]

Quack,

Thanks a lot for your feedback.

On 2022-07-16 14:56, Johannes Schauer Marin Rodrigues wrote:

Issue 1: your choice of _greetd lets my postinst fail because my 
NAME_REGEX in

/etc/adduser.conf is "^[a-z][-a-z0-9_]*\$"


This naming scheme is becoming quite common in Debian now. Since you do 
not have problem with _apt or _chrony etc, I wondered if there was any 
adduser magic option and indeed apt is using --force-badname. I'll add 
the option but please not chrony, and probably other packages, do not 
necessarily use it and you'll probably have to make an exception (or 
fill bug reports).


Issue 2: after installing it, I get a black screen printing "/bin/sh: 
1: exec:
agreety: not found" -- maybe this is because the user "greeter" doesn't 
have

/usr/sbin/ in their PATH?


I did not have time to test agreety and sway is in the path, but I 
checked and agreety does not work when run as non-root (not sure how 
useful that would be anyway) so I'm in favour of changing the default 
config to use the absolute path. Did you try this solution?



Issue 3: /etc/greetd/config.toml says:


I have not yet packaged wlgreet yet but that's coming; I added this 
config as example for the future.


The config I'm using is:
--
exec "wlgreet; swaymsg exit"

bindsym Mod4+shift+e exec swaynag \
-t warning \
-m 'What do you want to do?' \
-b 'Poweroff' 'systemctl poweroff -i' \
-b 'Reboot' 'systemctl reboot -i'

output * bg /etc/greetd/background fill

include /etc/sway/config.d/*
--

I guess I'll remove the background line, or maybe add another 
greetd-specific config directory for easy customization, I'm not sure 
yet.


[some time later…]

I pushed these changes, so hopefully that should help.

I could not get any reply from the Debian Rust team unfortunately, so 
enquote cannot be uploaded yet. I need to package greetd_ipc in the team 
too and that should be enough for wlgreet I think.

I'll keep you posted.

Regards.
\_o<

--
Marc Dequènes

Bug#1015138: gnome-books: FTBFS: ../data/meson.build:6:0: ERROR: Sandbox violation: Tried to grab file gd-main-view.h from a nested subproject.

[Lucas Nussbaum]

Source: gnome-books
Version: 40.0-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
>   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
> --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
> --localstatedir=/var --libdir=lib/x86_64-linux-gnu
> The Meson build system
> Version: 0.63.0
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: gnome-books
> Project version: 40.0
> C compiler for the host machine: cc (gcc 11.3.0 "cc (Debian 11.3.0-4) 11.3.0")
> C linker for the host machine: cc ld.bfd 2.38.90.20220713
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Run-time dependency gdk-pixbuf-2.0 found: YES 2.42.8
> Run-time dependency gjs-1.0 found: YES 1.72.0
> Run-time dependency evince-document-3.0 found: YES 42.3
> Run-time dependency evince-view-3.0 found: YES 42.3
> Run-time dependency glib-2.0 found: YES 2.72.3
> Run-time dependency gnome-desktop-3.0 found: YES 42.3
> Run-time dependency gobject-introspection-1.0 found: YES 1.72.0
> Run-time dependency gtk+-3.0 found: YES 3.24.34
> Run-time dependency tracker-sparql-3.0 found: YES 3.1.2
> Run-time dependency webkit2gtk-4.0 found: YES 2.36.4
> Library m found: YES
> Run-time dependency libgepub-0.6 found: YES 0.6.0
> Checking for function "cairo_surface_set_device_scale" with dependencies 
> gjs-1.0, evince-document-3.0, evince-view-3.0, glib-2.0, gnome-desktop-3.0, 
> gobject-introspection-1.0, gtk+-3.0, tracker-sparql-3.0, webkit2gtk-4.0, -lm: 
> YES 
> 
> Executing subproject libgd 
> 
> libgd| Project name: libgd
> libgd| Project version: undefined
> libgd| C compiler for the host machine: cc (gcc 11.3.0 "cc (Debian 11.3.0-4) 
> 11.3.0")
> libgd| C linker for the host machine: cc ld.bfd 2.38.90.20220713
> libgd| Dependency gtk+-3.0 found: YES 3.24.34 (cached)
> libgd| Library m found: YES
> libgd| Dependency gobject-introspection-1.0 found: YES 1.72.0 (cached)
> libgd| Dependency gobject-introspection-1.0 found: YES 1.72.0 (cached)
> libgd| Program g-ir-scanner found: YES (/usr/bin/g-ir-scanner)
> libgd| Dependency gobject-introspection-1.0 found: YES 1.72.0 (cached)
> libgd| Program g-ir-compiler found: YES (/usr/bin/g-ir-compiler)
> libgd| Build targets in project: 5
> libgd| Subproject libgd finished.
> 
> Configuring config.h using configuration
> Configuring config.js using configuration
> ../src/meson.build:82: WARNING: Project targets '>= 0.49.0' but uses feature 
> introduced in '0.50.0': install arg in configure_file.
> Configuring org.gnome.Books.service using configuration
> ../src/meson.build:90: WARNING: Project targets '>= 0.49.0' but uses feature 
> introduced in '0.50.0': install arg in configure_file.
> Configuring org.gnome.Books using configuration
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Program glib-compile-resources found: YES (/usr/bin/glib-compile-resources)
> 
> ../data/meson.build:6:0: ERROR: Sandbox violation: Tried to grab file 
> gd-main-view.h from a nested subproject.
> 
> A full log can be found at 
> /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
>   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
> ==> meson-logs/meson-log.txt <==
> Build started at 2022-07-16T05:58:32.557833
> Main binary: /usr/bin/python3
> Build Options: -Dprefix=/usr -Dlibdir=lib/x86_64-linux-gnu 
> -Dlocalstatedir=/var -Dsysconfdir=/etc -Dbuildtype=plain 
> -Dwrap_mode=nodownload
> Python system: Linux
> The Meson build system
> Version: 0.63.0
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: gnome-books
> Project version: 40.0
> Sanity testing C compiler: cc
> Is cross compiler: False.
> Sanity check compiler command line: cc sanitycheckc.c -o sanitycheckc.exe -g 
> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> -D_FILE_OFFSET_BITS=64 -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,-z,defs
> Sanity check compile stdout:
> 
> -
> Sanity check compile stderr:
> 
> -
> Running test binary command: 
> /<>/obj-x86_64-linux-gnu/meson-private/sanitycheckc.exe
> C compiler for the host machine: cc (gcc 11.3.0 "cc (Deb

Bug#1015137: mistral-dashboard: FTBFS: ImportError: cannot import name 'ugettext_lazy' from 'django.utils.translation' (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)

[Lucas Nussbaum]

Source: mistral-dashboard
Version: 14.0.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> NOSE_WITH_OPENSTACK=1 \
>   NOSE_OPENSTACK_COLOR=1 \
>   NOSE_OPENSTACK_RED=0.05 \
>   NOSE_OPENSTACK_YELLOW=0.025 \
>   NOSE_OPENSTACK_SHOW_ELAPSED=1 \
>   DJANGO_SETTINGS_MODULE=mistraldashboard.test.settings \
>   python3-coverage run \
>   /<>/manage.py test mistraldashboard 
> --settings=mistraldashboard.test.settings
> Found 7 test(s).
> Traceback (most recent call last):
>   File "/<>/manage.py", line 23, in 
> execute_from_command_line(sys.argv)
>   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 446, in execute_from_command_line
> utility.execute()
>   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 440, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
> "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", 
> line 24, in run_from_argv
> super().run_from_argv(argv)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 414, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 460, in execute
> output = self.handle(*args, **options)
>   File 
> "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", 
> line 68, in handle
> failures = test_runner.run_tests(test_labels)
>   File "/usr/lib/python3/dist-packages/django/test/runner.py", line 1006, in 
> run_tests
> self.run_checks(databases)
>   File "/usr/lib/python3/dist-packages/django/test/runner.py", line 925, in 
> run_checks
> call_command("check", verbosity=self.verbosity, databases=databases)
>   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 198, in call_command
> return command.execute(*args, **defaults)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 460, in execute
> output = self.handle(*args, **options)
>   File 
> "/usr/lib/python3/dist-packages/django/core/management/commands/check.py", 
> line 76, in handle
> self.check(
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 487, in check
> all_issues = checks.run_checks(
>   File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 
> 88, in run_checks
> new_errors = check(app_configs=app_configs, databases=databases)
>   File "/usr/lib/python3/dist-packages/django/core/checks/urls.py", line 14, 
> in check_url_config
> return check_resolver(resolver)
>   File "/usr/lib/python3/dist-packages/django/core/checks/urls.py", line 24, 
> in check_resolver
> return check_method()
>   File "/usr/lib/python3/dist-packages/django/urls/resolvers.py", line 480, 
> in check
> for pattern in self.url_patterns:
>   File "/usr/lib/python3/dist-packages/django/utils/functional.py", line 49, 
> in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "/usr/lib/python3/dist-packages/django/urls/resolvers.py", line 696, 
> in url_patterns
> patterns = getattr(self.urlconf_module, "urlpatterns", 
> self.urlconf_module)
>   File "/usr/lib/python3/dist-packages/django/utils/functional.py", line 49, 
> in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "/usr/lib/python3/dist-packages/django/urls/resolvers.py", line 689, 
> in urlconf_module
> return import_module(self.urlconf_name)
>   File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 1006, in _find_and_load_unlocked
>   File "", line 688, in _load_unlocked
>   File "", line 883, in exec_module
>   File "", line 241, in _call_with_frames_removed
>   File "/usr/lib/python3/dist-packages/openstack_dashboard/test/urls.py&quo

Bug#1015136: q2cli: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Lucas Nussbaum]

Source: q2cli
Version: 2021.8.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:239: python3.10 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:239: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.10/build/q2cli
> copying q2cli/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli
> copying q2cli/util.py -> /<>/.pybuild/cpython3_3.10/build/q2cli
> copying q2cli/__main__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli
> copying q2cli/commands.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli
> copying q2cli/_version.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli
> creating /<>/.pybuild/cpython3_3.10/build/q2cli/builtin
> copying q2cli/builtin/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/builtin
> copying q2cli/builtin/tools.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/builtin
> copying q2cli/builtin/dev.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/builtin
> copying q2cli/builtin/info.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/builtin
> creating /<>/.pybuild/cpython3_3.10/build/q2cli/click
> copying q2cli/click/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/click
> copying q2cli/click/parser.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/click
> copying q2cli/click/option.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/click
> copying q2cli/click/type.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/click
> copying q2cli/click/command.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/click
> creating /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/test_cli.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/test_dev.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/test_usage.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/test_core.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> copying q2cli/tests/test_tools.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/tests
> creating /<>/.pybuild/cpython3_3.10/build/q2cli/core
> copying q2cli/core/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/core
> copying q2cli/core/usage.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/core
> copying q2cli/core/cache.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/core
> copying q2cli/core/config.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/core
> copying q2cli/core/completion.py -> 
> /<>/.pybuild/cpython3_3.10/build/q2cli/core
> running egg_info
> creating q2cli.egg-info
> writing q2cli.egg-info/PKG-INFO
> writing dependency_links to q2cli.egg-info/dependency_links.txt
> writing entry points to q2cli.egg-info/entry_points.txt
> writing top-level names to q2cli.egg-info/top_level.txt
> writing manifest file 'q2cli.egg-info/SOURCES.txt'
> reading manifest file 'q2cli.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> adding license file 'LICENSE'
> writing manifest file 'q2cli.egg-info/SOURCES.txt'
> UPDATING /<>/.pybuild/cpython3_3.10/build/q2cli/_version.py
> set /<>/.pybuild/cpython3_3.10/build/q2cli/_version.py to 
> '2021.8.0'
> running build_scripts
> creating build
> creating build/scripts-3.10
> copying bin/tab-qiime -> build/scripts-3.10
> changing mode of build/scripts-3.10/tab-qiime from 644 to 755
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:239: cd /<>/.pybuild/cpython3_3.10/build; 
> python3.10 -m pytest 
> = test session starts 
> ==
> platform linux -- Python 3.10.5, pytest-7.1.2, pluggy-1.0.0
> rootdir: /<>
> collected 119 items
> 
> q2cli/tests/test_cli.py ...  [ 
> 36%]
> q2cli/tests/test_core.py [ 
> 46%]
> q2cli/tests/test_dev.py 

Bug#1015135: zaqar-ui: FTBFS: ImportError: cannot import name 'ugettext_lazy' from 'django.utils.translation' (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)

[Lucas Nussbaum]

Source: zaqar-ui
Version: 12.0.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> for i in 3.9 3.10 ; do \
>   
> PYTHONPATH=/<>/debian/python3-zaqar-ui/usr/lib/python3/dist-packages
>  \
>   NOSE_WITH_OPENSTACK=1 \
>   NOSE_OPENSTACK_COLOR=1 \
>   NOSE_OPENSTACK_RED=0.05 \
>   NOSE_OPENSTACK_YELLOW=0.025 \
>   NOSE_OPENSTACK_SHOW_ELAPSED=1 \
>   PYTHON=python$i \
>   python$i /<>/manage.py test zaqar_ui 
> --settings=zaqar_ui.test.settings ; \
> done
> WARNING:root:Error importing zaqar_ui.enabled._1510_project_messaging_group
> ERROR:root:cannot import name 'ugettext_lazy' from 'django.utils.translation' 
> (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)
> Traceback (most recent call last):
>   File 
> "/usr/lib/python3/dist-packages/openstack_dashboard/utils/settings.py", line 
> 58, in import_submodules
> submodule = import_module(name)
>   File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File "/<>/zaqar_ui/enabled/_1510_project_messaging_group.py", 
> line 15, in 
> from django.utils.translation import ugettext_lazy as _
> ImportError: cannot import name 'ugettext_lazy' from 
> 'django.utils.translation' 
> (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)
> WARNING:root:Error importing zaqar_ui.enabled._2510_admin_messaging_group
> ERROR:root:cannot import name 'ugettext_lazy' from 'django.utils.translation' 
> (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)
> Traceback (most recent call last):
>   File 
> "/usr/lib/python3/dist-packages/openstack_dashboard/utils/settings.py", line 
> 58, in import_submodules
> submodule = import_module(name)
>   File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File "/<>/zaqar_ui/enabled/_2510_admin_messaging_group.py", 
> line 15, in 
> from django.utils.translation import ugettext_lazy as _
> ImportError: cannot import name 'ugettext_lazy' from 
> 'django.utils.translation' 
> (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)
> Found 3 test(s).
> System check identified no issues (0 silenced).
> EEE
> ==
> ERROR: zaqar_ui.api.rest (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: zaqar_ui.api.rest
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.9/unittest/loader.py", line 377, in 
> _get_module_from_name
> __import__(name)
>   File "/<>/zaqar_ui/api/rest/__init__.py", line 24, in 
> from zaqar_ui.api.rest import zaqar  # noqa: F401
>   File "/<>/zaqar_ui/api/rest/zaqar.py", line 18, in 
> from django.utils.translation import ugettext_lazy as _
> ImportError: cannot import name 'ugettext_lazy' from 
> 'django.utils.translation' 
> (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)
> 
> 
> ==
> ERROR: zaqar_ui.content.queues (unittest.loader._FailedTest)
> 

Bug#1015134: mir: FTBFS: input_config_matchers.h:119:5: error: ISO C++ forbids declaration of ‘GTEST_DISALLOW_ASSIGN_’ with no type [-fpermissive]

[Lucas Nussbaum]

Source: mir
Version: 1.8.2+dfsg-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> cd /<>/build-amd64/tests/unit-tests/platforms/mesa/kms && 
> /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK 
> -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK 
> -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DEGL_NO_X11 
> -DGTEST_VERSION_MAJOR=1 -DGTEST_VERSION_MINOR=12 -DGTEST_VERSION_PATCH=1 
> -DLOG_NDEBUG=1 -DLTTNG_UST_HAVE_SDT_INTEGRATION -DMESA_EGL_NO_X11_HEADERS 
> -DMIR_BUILD_PLATFORM_EGLSTREAM_KMS -DMIR_BUILD_PLATFORM_MESA_KMS 
> -DMIR_BUILD_PLATFORM_MESA_X11 
> -DMIR_CLIENT_PLATFORM_VERSION=\"MIR_CLIENT_PLATFORM_5\" 
> -DMIR_DRMMODEADDFB_HAS_CONST_SIGNATURE -DMIR_LIBINPUT_HAS_ACCEL_PROFILE=1 
> -DMIR_SERVER_EGL_OPENGL_API=EGL_OPENGL_ES_API 
> -DMIR_SERVER_EGL_OPENGL_BIT=EGL_OPENGL_ES2_BIT 
> -DMIR_SERVER_GLEXT_H="" -DMIR_SERVER_GL_H="" 
> -DMIR_SERVER_GRAPHICS_PLATFORM_ABI_STRING=\"16\" -DMIR_VERSION_MAJOR=1 
> -DMIR_VERSION_MICRO=2 -DMIR_VERSION_MINOR=8 -D_FILE_OFFSET_BITS=64 
> -D_GNU_SOURCE -I/<>/include/core 
> -I/<>/include/common -I/<>/include/cookie 
> -I/<>/build-amd64/src/capnproto 
> -I/<>/build-amd64/src/protobuf 
> -I/usr/src/googletest/googlemock/include -I/<>/include/platform 
> -I/<>/include/miral -I/<>/include/server 
> -I/usr/include/uuid -I/<>/include/client 
> -I/<>/include/test -I/<>/include/renderer 
> -I/<>/include/renderers/gl -I/<>/tests/include 
> -I/<> -I/usr/include/libdrm -I/usr/include/umockdev-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/<>/include/renderers/sw -I/<>/src/include/cookie 
> -I/<>/src/include/platform -I/<>/src/include/server 
> -I/<>/src/include/client -I/<>/src/include/common 
> -I/<>/src/include/gl 
> -I/<>/src/platforms/common/client 
> -I/<>/src/platforms/common/server -I/usr/include/gio-unix-2.0 
> -I/usr/include/libmount -I/usr/include/blkid 
> -I/<>/include/platforms/mesa 
> -I/<>/src/platforms/mesa/server 
> -I/<>/include/wayland -I/<>/src/wayland/generated 
> -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -g 
> -std=c++14 -Wall -fno-strict-aliasing -pedantic -Wnon-virtual-dtor -Wextra 
> -fPIC -Wno-mismatched-tags -Wno-psabi -flto -ffat-lto-objects 
> -Wno-error=null-dereference -Wno-error=overloaded-virtual -Wno-sign-compare 
> -fno-lto -Dregister= -pthread -std=c++14 -Wno-variadic-macros -MD -MT 
> tests/unit-tests/platforms/mesa/kms/CMakeFiles/mir_unit_tests_mesa-kms.dir/test_display_buffer.cpp.o
>  -MF CMakeFiles/mir_unit_tests_mesa-kms.dir/test_display_buffer.cpp.o.d -o 
> CMakeFiles/mir_unit_tests_mesa-kms.dir/test_display_buffer.cpp.o -c 
> /<>/tests/unit-tests/platforms/mesa/kms/test_display_buffer.cpp
> In file included from 
> /<>/tests/integration-tests/input/test_single_seat_setup.cpp:53:
> /<>/tests/include/mir/test/input_config_matchers.h:119:5: error: 
> ISO C++ forbids declaration of ‘GTEST_DISALLOW_ASSIGN_’ with no type 
> [-fpermissive]
>   119 | GTEST_DISALLOW_ASSIGN_(InputConfigElementsMatcher);
>   | ^~
> [ 78%] Building CXX object 
> tests/unit-tests/platforms/mesa/kms/CMakeFiles/mir_unit_tests_mesa-kms.dir/test_display_multi_monitor.cpp.o
> cd /<>/build-amd64/tests/unit-tests/platforms/mesa/kms && 
> /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK 
> -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK 
> -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DEGL_NO_X11 
> -DGTEST_VERSION_MAJOR=1 -DGTEST_VERSION_MINOR=12 -DGTEST_VERSION_PATCH=1 
> -DLOG_NDEBUG=1 -DLTTNG_UST_HAVE_SDT_INTEGRATION -DMESA_EGL_NO_X11_HEADERS 
> -DMIR_BUILD_PLATFORM_EGLSTREAM_KMS -DMIR_BUILD_PLATFORM_MESA_KMS 
> -DMIR_BUILD_PLATFORM_MESA_X11 
> -DMIR_CLIENT_PLATFORM_VERSION=\"MIR_CLIENT_PLATFORM_5\" 
> -DMIR_DRMMODEADDFB_HAS_CONST_SIGNATURE -DMIR_LIBINPUT_HAS_ACCEL_PROFILE=1 
> -DMIR_SERVER_EGL_OPENGL_API=EGL_OPENGL_ES_API 
> -DMIR_SERVER_EGL_OPENGL_BIT=EGL_OPENGL_ES2_BIT 
> -DMIR_SERVER_GLEXT_H="" -DMIR_SERVER_GL_H="" 
> -DMIR_SERVER_GRAPHICS_PLATFORM_ABI_STRING=\"16\" -DMIR_VERSION_MAJOR=1 
> -DMIR_VERSION_MICRO=2 -DMIR_VERSION_MINOR=8 -D_FILE_OFFSET_BITS=64 
> -D_GNU_SOURCE -I/<>/include/core 
> -I/<>/include/common -I/<>/include/cookie 
> -I/

Bug#1015133: qtmir: FTBFS: gmock_fixes.h:49:7: error: ‘ActionResultHolder’ is not a class template

[Lucas Nussbaum]

Source: qtmir
Version: 0.7.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC -Wall -fno-strict-aliasing -Wextra -Wl,-z,relro 
> -Wl,-z,now -rdynamic 
> CMakeFiles/general_test.dir/general_test_autogen/mocs_compilation.cpp.o 
> CMakeFiles/general_test.dir/objectlistmodel_test.cpp.o 
> CMakeFiles/general_test.dir/timestamp_test.cpp.o 
> CMakeFiles/general_test.dir/__/__/__/src/common/timestamp.cpp.o -o 
> general_test  /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.4 
> ../../gmock/lib/libgtest.a ../../gmock/lib/libgtest_main.a 
> ../../gmock/lib/libgmock_main.a ../../gmock/lib/libgmock.a 
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.4 ../../gmock/lib/libgtest.a 
> -lpthread 
> In file included from /<>/tests/framework/mock_main_loop.h:21,
>  from /<>/tests/framework/mock_main_loop.cpp:17:
> /<>/tests/framework/gmock_fixes.h:49:7: error: 
> ‘ActionResultHolder’ is not a class template
>49 | class ActionResultHolder>
>   |   ^~
> /<>/tests/framework/gmock_fixes.h:50:40: error: expected 
> class-name before ‘{’ token
>50 | : public UntypedActionResultHolderBase {
>   |^
> /<>/tests/framework/gmock_fixes.h:104:3: error: ISO C++ forbids 
> declaration of ‘GTEST_DISALLOW_ASSIGN_’ with no type [-fpermissive]
>   104 |   GTEST_DISALLOW_ASSIGN_(ActionResultHolder);
>   |   ^~
> [ 74%] Building CXX object 
> tests/framework/CMakeFiles/qtmir-test-framework-static.dir/mock_mir_session.cpp.o
> [ 74%] Linking CXX executable MirALTests
> cd /<>/obj-x86_64-linux-gnu/tests/framework && /usr/bin/c++ 
> -DGTEST_VERSION_MAJOR=1 -DGTEST_VERSION_MINOR=12 -DGTEST_VERSION_PATCH=1 
> -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050900 
> -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_KEYWORDS 
> -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICK_LIB -DQT_USE_QSTRINGBUILDER 
> -DWITH_VALGRIND -I/<>/obj-x86_64-linux-gnu/tests/framework 
> -I/<>/tests/framework 
> -I/<>/obj-x86_64-linux-gnu/tests/framework/qtmir-test-framework-static_autogen/include
>  -I/<>/tests/include -I/<>/src/common 
> -I/<>/src/platforms/mirserver -I/<>/src/modules 
> -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
> /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/miral -isystem 
> /usr/include/mirclient -isystem /usr/include/mircookie -isystem 
> /usr/include/mircore -isystem /usr/include/mirserver -isystem 
> /usr/include/mirplatform -isystem /usr/include/mircommon -isystem 
> /usr/include/uuid -isystem /usr/include/mirrenderer -isystem 
> /usr/include/mirtest -isystem /usr/include/x86_64-linux-gnu/qt5/QtQuick 
> -isystem /usr/include/x86_64-linux-gnu/qt5/QtQmlModels -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtQml -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtDBus -isystem 
> /usr/src/googletest/googletest/include -isystem 
> /usr/src/googletest/googlemock/include -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall 
> -fno-strict-aliasing -Wextra -fPIC -std=gnu++14 -MD -MT 
> tests/framework/CMakeFiles/qtmir-test-framework-static.dir/mock_mir_session.cpp.o
>  -MF CMakeFiles/qtmir-test-framework-static.dir/mock_mir_session.cpp.o.d -o 
> CMakeFiles/qtmir-test-framework-static.dir/mock_mir_session.cpp.o -c 
> /<>/tests/framework/mock_mir_session.cpp
> cd /<>/obj-x86_64-linux-gnu/tests/mirserver/miral && 
> /usr/bin/cmake -E cmake_link_script CMakeFiles/MirALTests.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 -fPIC -Wall -fno-strict-aliasing -Wextra -Wl,-z,relro 
> -Wl,-z,now -rdynamic 
> CMakeFiles/MirALTests.dir/MirALTests_autogen/mocs_compilation.cpp.o 
> CMakeFiles/MirALTests.dir/edid_test.cpp.o -o MirALTests  
> -Wl,-rpath,/<>/obj-x86_64-linux-gnu/src/platforms/mirserver 
> ../../../src/platforms/mirserver/libqtmirserver.so.1 
> ../../gmock/lib/libgtest.a ../../gmock/lib/libgtest_main.a 
> ../../gmock/lib/libgmock_main.a ../../gmock/lib/libg