Bug#1020940: debian-live: A large number of locales are created by default

[Roland Clobus]

Hello Green,

On 29/09/2022 03:10, Green wrote:

Installing from Debian Live installs a large number of non-Japanese locales by 
default, which takes extra time and disk space when updating.


The live image contains many locales, which allows Debian to create only 
a single image for all those locales.
When you install from the live image, you'll get a copy of the live 
image on your hard disc, minus the things that are specific to booting 
live images. This means that all locales will be available for you as 
well. If you only want to have some specific locales, you'll need to 
customise the installed image, as you have done.



You can remove them all at once by the following procedure. After removal, 
reinstall firefox-esr-l10n-en. (The same problem occurs with 
libreoffice-help-*.)
This is a situation not intended by the user, so it is considered a bug.


I consider this to be a feature :-)

However, given that you are not the first to wonder about the amount of 
localisation packages, this bug report could be considered to become a 
feature request: have the installer(s) ask which locales you would like 
to keep.


With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#949422: osmo: diff for NMU version 0.4.4-1.1

[Hugh McMaster]

Control: tags 949422 + patch


Dear maintainer,

I've prepared an NMU for osmo (versioned as 0.4.4-1.1). The diff
is attached to this message.

As this package is marked LowNMU, I will seek sponsorship to
upload shortly. Please let me know if you would prefer to upload
this version yourself.

Kind regards,

Hugh

diff -Nru osmo-0.4.4/debian/changelog osmo-0.4.4/debian/changelog
--- osmo-0.4.4/debian/changelog	2020-07-15 10:06:11.0 +1000
+++ osmo-0.4.4/debian/changelog	2022-09-29 14:59:38.0 +1000
@@ -1,3 +1,10 @@
+osmo (0.4.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Use pkg-config to find libxml2 (Closes: #949422).
+
+ -- Hugh McMaster   Thu, 29 Sep 2022 14:59:38 +1000
+
 osmo (0.4.4-1) unstable; urgency=medium
 
   * New upstream version 0.4.4.
diff -Nru osmo-0.4.4/debian/patches/libxml2.patch osmo-0.4.4/debian/patches/libxml2.patch
--- osmo-0.4.4/debian/patches/libxml2.patch	1970-01-01 10:00:00.0 +1000
+++ osmo-0.4.4/debian/patches/libxml2.patch	2022-09-29 12:04:07.0 +1000
@@ -0,0 +1,29 @@
+Description: Use pkg-config to find libxml2
+Author: Maxim Gordienko 
+Bug-Debian: https://bugs.debian.org/949422
+Origin: upstream, https://sourceforge.net/p/osmo-pim/osmo/ci/843cf52c73f7fe9e89982b0795a206be1b90784d/
+Last-Update: 2022-09-27
+
+--- a/configure.ac
 b/configure.ac
+@@ -57,8 +57,7 @@
+ AM_PATH_GTK_3_0(3.10.0,,
+ AC_MSG_ERROR([GTK+ not found or too old (version < 3.10)]))
+ 
+-AM_PATH_XML2(2.0.0,,
+-AC_MSG_ERROR([You do not appear to have libxml2 installed.]))
++PKG_CHECK_MODULES([XML], [libxml-2.0 >= 2.9])
+ 
+ PKG_CHECK_MODULES(GTHREAD, gthread-2.0 >= 2.6.0)
+ 
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -6,7 +6,7 @@
+ VERSION_MICRO := $(shell echo $(VERSION) | awk -F "." '{print $$3}')
+ AM_CPPFLAGS = -DREPO=$(ISREPO) -DREVISION=$(REVISION) -DLOCALEDIR=\"$(datadir)/locale\" -DDATADIR=\"$(datadir)\" \
+ 			  -DVERSION_MAJOR=\"$(VERSION_MAJOR)\" -DVERSION_MINOR=\"$(VERSION_MINOR)\" -DVERSION_MICRO=\"$(VERSION_MICRO)\" \
+-			  -DSOUNDSDIR=\"$(datadir)/sounds\" @GTK_CFLAGS@ @XML_CPPFLAGS@ -Wall -DGDK_DISABLE_DEPRECATION_WARNINGS \
++			  -DSOUNDSDIR=\"$(datadir)/sounds\" @GTK_CFLAGS@ @XML_CFLAGS@ -Wall -DGDK_DISABLE_DEPRECATION_WARNINGS \
+ 			  -DICONSDIR=\"$(datadir)/icons\" -DPIXMAPSDIR=\"$(datadir)/pixmaps\" \
+ 			  -DG_DISABLE_CAST_CHECKS
+ 
diff -Nru osmo-0.4.4/debian/patches/series osmo-0.4.4/debian/patches/series
--- osmo-0.4.4/debian/patches/series	1970-01-01 10:00:00.0 +1000
+++ osmo-0.4.4/debian/patches/series	2022-09-29 12:04:07.0 +1000
@@ -0,0 +1 @@
+libxml2.patch

Bug#1016254: lomiri-url-dispatcher: FTBFS: overlay-tracker-mir.cpp:95:45: error: variable ‘std::array urls’ has initializer but incomplete type

[Andres Salomon]

Control: tags -1 patch

Here's a fix for this one, which is blocking geary from bookworm. I've 
also a MR upstream, with the MR link in the patch.


Description: Fix build failure from missing header in gcc 12.1.0 (#1016254)
Author: Andres Salomon 
Forwarded: https://gitlab.com/ubports/development/core/lomiri-url-dispatcher/-/merge_requests/17

diff --git a/service/overlay-tracker-mir.cpp b/service/overlay-tracker-mir.cpp
index 3fe47b8267395c1235f425fb1cc4bccc91cb1237..d81a7b8c41ec1be6fc71d60097d0d0802f5d3687 100644
--- a/service/overlay-tracker-mir.cpp
+++ b/service/overlay-tracker-mir.cpp
@@ -17,6 +17,8 @@
  *   Ted Gould 
  */
 
+#include 
+
 #include "overlay-tracker-mir.h"
 #include 
 

Bug#1008735: /etc/os-release should contain VERSION variables for testing and unstable

[Petter Reinholdtsen]

[Gioele Barabucci]
> Users of `lsb_release` are affected by the lack of `VERSION_CODENAME` as
> well.

I discovered it when the Github CI build started failing for LinuxCNC,
see
https://github.com/LinuxCNC/linuxcnc/actions/runs/3140903147/jobs/5102782128 >
for an example.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Gunnar Wolf]

Hi Ansgar,

Ansgar dijo [Wed, Sep 28, 2022 at 10:18:26PM +0200]:
> Any package relevant for successful boot. Any upgrade.
> 
> As far as I can tell, the submitter requires some guarantees
> significantly stronger than what Debian requires for essential
> packages.
> 
> In particular, boot-relevant packages are demanded to work in
> unconfigured state, with not fully satisfied dependencies (possibly not
> even unpackaged?), in partly unpackaged states, after maintainer script
> errors, and all of that in combination with system crashes that might
> result in partly written data to filesystems. And possibly in other
> interesting system states too.

Humm, as the maintainer for raspi-firmware, this definitively
addresses an area where I'm responsible. So this is naturally
interesting for me even outside my TC role.

There is a point I somewhat agree with Bug#1020920's submitter:
Packages modifying the packages involved in system boot need to be
extra careful to reduce the window of vulnerability for an unbootable
system as much as possible.

However, no matter how careful we are, I do not think it's expectable
that we can guarantee the atomic interaction mode Zack W. suggests —
There is no syscall matching "rename and create a symlink". And even
if we had one, it would most probably still become two separate
filesystem operations in the end. Of course, the supported
filesystems' code could be modified so that said operation sequence
could be added to the journal beforehand, so they can be effectively
considered as atomic, but...

That's quite an unrealistic expectation. We cannot expect to implement
actions not expressable in the set of primitives Linux exposes to
us. We cannot expect a (quite invasive I'd expect) kernel patch to be
applied just because we want to run usrmerge.

> > (2) The TC is a decision-making body of last resort.  The bug you
> >     mention was filed today.  Might this be premature?
> 
> Well, if we close it or don't act on it, people will complain and/or
> demand to remove us from Debian for not acting on it (the latter might
> be limited to people just sitting on their porch).
> 
> The other tech-ctte bug about usrmerge also suggested it would just end
> up here either way.

There is a high chance we might end up getting this bug in the TC,
given the spirits we have seen around merged-/usr. However, I agree
with Sean: This bug is too early to summon the TC.

I know that if I suggest you to bring the issue to d-devel@l.d.o it
will fuel a flamewar, but I see no other proper way to handle _this
particular mail_. Maybe the request could be phrased differently, in a
way it could encompass this bug report (i.e. "ask the TC whether we
might use sloppy techniques when upgrading, considering the risks we
take as acceptable" (of course, I don't mean your job is sloppy, it's
just an example text that will not be accepted if asked )

So... I'm also inclined to ask you to please close this TC bug, as it
is not acceptable for a TC ruling. (Also, how many rulings does it
make sense for the TC to hold on the same tired topic of merged-/usr?)

Greetings,

- Gunnar.


signature.asc
Description: PGP signature

Bug#1013276: fixed in pipewire 0.3.58-1

[Paul Wise]

On Fri, 16 Sep 2022 14:36:19 + Dylan Aïssi wrote:

>[ Sebastien Bacher ]
>* Let pipewire-pulse conflicts on pulseaudio
>(Closes: #1013276, LP: #1975823)

This has made it difficult to switch back and forth between pulseaudio
and pipewire-pulse while evaluating pipewire. Before you could install
both and switch easily by masking the systemd user services, but now
you have to uninstall/reinstall instead, which requires root.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1020463: usrmerge: breaks Hurd systems

[Marco d'Itri]

On Sep 22, Samuel Thibault  wrote:

> On usr merge attempt on a hurd-i386 system, things go really bad:
I am quite disappointed that it took 7 years to find out that the 
package does not work at all on Hurd.
You are requesting major changes to an algorithm which has been in use 
since ~2015, and I do not want to risk introducing bugs now that the 
package is installed by default on all existing systems.
I am not opposed to fixing this, but we need to find a way to make sure 
that it will not introduce new bugs.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1020941: gnome-control-center: Night Light is unavailable on a system where it was working earlier

[Chandra Sekar Srinivasan]

Package: gnome-control-center
Version: 1:43.0-1
Severity: normal
X-Debbugs-Cc: chandru...@gmail.com

Dear Maintainer,

The Night Light panel under Display settings says,

"Night Light Unavailable

This could be the result of the graphics driver being used, or the desktop 
being used remotely"

I have an AMD graphics card and Night Light used to work on this system.

$ lspci | grep VGA
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Cezanne (rev c9)

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
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:43.0-1
ii  gnome-desktop3-data   43-2
ii  gnome-settings-daemon 43.0-2
ii  gsettings-desktop-schemas 43.0-1
ii  libaccountsservice0   22.08.8-1
ii  libadwaita-1-01.2.0-1
ii  libc6 2.35-1
ii  libcairo2 1.16.0-6
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1+b1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.5
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.74.0-2
ii  libgnome-bg-4-2   43-2
ii  libgnome-bluetooth-ui-3.0-13  42.4-1
ii  libgnome-desktop-4-2  43-2
ii  libgnome-rr-4-2   43-2
ii  libgnutls30   3.7.7-2
ii  libgoa-1.0-0b 3.46.0-1
ii  libgoa-backend-1.0-1  3.46.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.34-3
ii  libgtk-4-14.8.1+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.27-2
ii  libkrb5-3 1.20-1
ii  libmalcontent-0-0 0.11.0-3
ii  libmm-glib0   1.18.12-1
ii  libnm01.40.0-1
ii  libnma-gtk4-0 1.10.2-1
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   16.1+dfsg1-2
ii  libpulse0 16.1+dfsg1-2
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.16.5+dfsg-1
ii  libsnapd-glib11.60-1
ii  libudisks2-0  2.9.4-3
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.4.0-3
ii  libx11-6  2:1.8.1-2
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1+b1
ii  webp-pixbuf-loader0.0.5-5

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-4+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.4-1
ii  gnome-online-accounts 3.46.0-1
ii  gnome-remote-desktop  43.0-2
ii  gnome-user-docs   43.0-1
ii  gnome-user-share  43.0-1
ii  iso-codes 4.11.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 251.4-3
ii  malcontent-gui0.11.0-3
ii  network-manager-gnome 1.28.0-1
ii  policykit-1   0.105-33
ii  power-profiles-daemon 0.12-1
pn  pulseaudio-module-bluetooth   
ii  realmd0.17.0-2
ii  rygel 0.40.4-1
ii  rygel-tracker 0.40.4-1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
pn  gnome-software | gnome-packagekit  
ii  gstreamer1.0-pulseaudio1.20.3-1
ii  x11-xserver-utils  7.7+9+b1

-- no debconf information

Bug#1020582: kitty: CVE-2022-41322

[James McCoy]

On Fri, Sep 23, 2022 at 08:38:27PM +0200, Salvatore Bonaccorso wrote:
> CVE-2022-41322[0]:
> | In Kitty before 0.26.2, insufficient validation in the desktop
> | notification escape sequence can lead to arbitrary code execution. The
> | user must display attacker-controlled content in the terminal, then
> | click on a notification popup.

> Please adjust the affected versions in the BTS as needed.

This feature was introduced in 0.19.0, so I've marked it found in
the first upload after that -- 0.19.1-1.

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

Bug#1020902: page not in the users language

[matthias . geiger1024]

 Reported upstream as #91.

Bug#1020940: debian-live: A large number of locales are created by default

[Green]

Package: debian-live
Severity: important

Dear Maintainer,

Installing from Debian Live installs a large number of non-Japanese locales by 
default, which takes extra time and disk space when updating. You can remove 
them all at once by the following procedure. After removal, reinstall 
firefox-esr-l10n-en. (The same problem occurs with libreoffice-help-*.)
This is a situation not intended by the user, so it is considered a bug.

debian@user:~$ sudo apt remove firefox-esr-l10n-*
 ( --- 途中省略 --- )
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
  hunspell-gl-es hunspell-sv-se
これを削除するには 'sudo apt autoremove' を利用してください。
以下のパッケージは「削除」されます:
  firefox-esr-l10n-ar firefox-esr-l10n-ast firefox-esr-l10n-be 
firefox-esr-l10n-bg firefox-esr-l10n-bn firefox-esr-l10n-bs
  firefox-esr-l10n-ca firefox-esr-l10n-cs firefox-esr-l10n-cy 
firefox-esr-l10n-da firefox-esr-l10n-de firefox-esr-l10n-el
  firefox-esr-l10n-en-gb firefox-esr-l10n-eo firefox-esr-l10n-es-ar 
firefox-esr-l10n-es-cl firefox-esr-l10n-es-es
  firefox-esr-l10n-es-mx firefox-esr-l10n-et firefox-esr-l10n-eu 
firefox-esr-l10n-fa firefox-esr-l10n-fi firefox-esr-l10n-fr
  firefox-esr-l10n-ga-ie firefox-esr-l10n-gl firefox-esr-l10n-gu-in 
firefox-esr-l10n-he firefox-esr-l10n-hi-in firefox-esr-l10n-hr
  firefox-esr-l10n-hu firefox-esr-l10n-id firefox-esr-l10n-is 
firefox-esr-l10n-it firefox-esr-l10n-ja firefox-esr-l10n-kk
  firefox-esr-l10n-km firefox-esr-l10n-kn firefox-esr-l10n-ko 
firefox-esr-l10n-lt firefox-esr-l10n-lv firefox-esr-l10n-mk
  firefox-esr-l10n-mr firefox-esr-l10n-nb-no firefox-esr-l10n-ne-np 
firefox-esr-l10n-nl firefox-esr-l10n-nn-no firefox-esr-l10n-pa-in
  firefox-esr-l10n-pl firefox-esr-l10n-pt-br firefox-esr-l10n-pt-pt 
firefox-esr-l10n-ro firefox-esr-l10n-ru firefox-esr-l10n-si
  firefox-esr-l10n-sk firefox-esr-l10n-sl firefox-esr-l10n-sq 
firefox-esr-l10n-sr firefox-esr-l10n-sv-se firefox-esr-l10n-ta
  firefox-esr-l10n-te firefox-esr-l10n-th firefox-esr-l10n-tr 
firefox-esr-l10n-uk firefox-esr-l10n-vi firefox-esr-l10n-zh-cn
  firefox-esr-l10n-zh-tw
アップグレード: 0 個、新規インストール: 0 個、削除: 66 個、保留: 6 個。
この操作後に 45.9 MB のディスク容量が解放されます。
続行しますか? [Y/n]

Thank you,
Green

Bug#892664: my use case. Petition to have zst support in dpkg

[Yaroslav Halchenko]

We build both debian and ubuntu backports for http://neuro.debian.net/ .
And then we use https://snapshot.debian.org/ engine to provide snapshots
over our archive, which we run in a Debian environment. Unfortunately
dpkg-deb used by snapshot pukes on Ubuntu packages due to "unknown
compression for member 'control.tar.zst'".  I would be eager to see this
issue addressed.  Pretty please!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1020939: graphviz: mingle manual broken, doesn't request eqn

[наб]

Package: graphviz
Version: 2.42.2-5
Severity: minor

Dear Maintainer,

man mingle shows:
-- >8 --
MINGLE(1)   General Commands Manual  MINGLE(1)



delim $$

NNAAMMEE
   mingle - fast edge bundling

SSYYNNOOPPSSIISS
   mmiinnggllee [ _o_p_t_i_o_n_s ] [ --oo 
_o_u_t_f_i_l_e ] [ _f_i_l_e_s ]

DDEESSCCRRIIPPTTIIOONN
   mmiinnggllee takes as input a graph in DOT format with node 
position informa‐
   tion (the _p_o_s attribute) and bundles the edges.

OOPPTTIIOONNSS
   The following options are supported:

   --mm _k   indicates which method to use for bundling. A value of 0  
corre‐
  sponds  to a force-directed bundling.  A value of 2 uses a clus‐
  ter plus ink saving approach. If available, a value 1 denotes an
  agglomerative  ink  saving method. Normally, the last is the de‐
  fault.

   --aa _k   specifies the maximum turning angle, in degrees, as a  
non-nega‐
  tive  real.   The  larger the value, the more edges may bend. If
  the value is 0, there is no limitation on the turning angle. The
  default  is  40.   The  parameter  is not used in force-directed
  bundling.

   --cc _v   specifies which compatability measure to use. The value  0, 
 the
  default,  uses  a  distance metric, while a value of 1 relies on
  full compatability. This value is only  used  in  force-directed
  bundling.

   --ii _k   gives  the maximum number of iterative divisions of edges 
allowd
  in force-directed bundling.  The default is 4.

   --kk _k   gives the number of neighbors to be used in  forming  a  
nearest
  neighbor graph. This parameter is only used in the agglomerative
  method. The default is 10.

   --KK _k   is a positive real value  giving  the  force  constant  
used  in
  force-directed bundling. By default, the value is determined au‐
  tomatically.

   --oo _f_i_l_e
  puts output in _f_i_l_e. Default output is stdout

   --pp _k   Except for the force-directed method, bundling minimizes 
$ink  *
  (k  -  cos(turning angle))$. The larger the value of _k, the less
  emphasis is put on avoiding sharp turning angles and the  faster
  the bundling.  The default value is -1.

   --rr _k   is  a  non-negative  integer  giving the maximum recursion 
level
  used in the agglomerative method. The default is 100.

   --TT _f_m_t specifies the output format. At present, the output is 
always in
  the  DOT  format.  If  _f_m_t  is "simple", the output is a 
simple,
  schematic representation of the drawing. Only the node positions
  and  edges are retained from the original graph. If _f_m_t is 
"gv",
  the drawing information is attached to the input graph.

   --vv _k   determines the verbose level used for tracing the 
algorithm. The
  value _k is optional; if not provided, the value 1 is used.

   --?? Print usage and exit.


BBUUGGSS
   At present, mmiinnggllee does not handle graphs with loops or 
directed multi‐
   edges. So, a graph with edges _a _-_> _b and _b _-_> _a is 
acceptable, but  not
   if it has edges _a _-_> _b and _a _-_> _b or _a _-_- _b and 
_a _-_- _b.

AAUUTTHHOORR
   Emden R. Gansner , Yifan Hu 

SSEEEE AALLSSOO
   sfdp(1), neato(1), gvpr(1)

   Emden  R.  Gansner,  Yifan Hu, Stephen C. North and Carlos Scheidegger,
   ``Multilevel  Agglomerative  Edge  Bundling   for   Visualizing   Large
   Graphs'', IEEE Pacific Visualization Symposium PacificVis, pp. 187‐194,
   2011.



16 August 2013   MINGLE(1)
-- >8 --

You need
'\" e
as the first line to demand eqn.

This obviously applies to all pages that use eqn.

Best,
наб

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

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

Versions of packages graphviz depends on:
ii  libann01.1.2+doc-7
ii  libc6  2.31-13+deb11u4
ii  libcdt52.42.2-5
ii  libcgraph6 2.42.2-5
ii  libexpat1  2.2.10-2+deb11u4
ii  libgcc-s1  10.2.1-6
ii  libgd3   

Bug#1020938: khard: missing Python dependency python3-pkg-resources

[Sebastian Crane]

Package: khard
Version: 0.17.0-1
Severity: grave
X-Debbugs-Cc: none, Sebastian Crane 

Dear Maintainer,

Khard fails to start on Debian 11 if the python3-pkg-resources package
is unavailable. It seems that this package is commonly found on desktop
Debian systems, but is not present in container images published by
Docker Inc.

I intend to fix this bug by adding python3-pkg-resources to Khard's
dependencies - I'll make a pull request to the relevant Git repository
on Salsa.

Best wishes,

Sebastian Crane

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Package: libgtk-3-0
Version: 3.24.24-4+deb11u2
Severity: wishlist
Tags: patch

Dear Maintainer,

when using GTK on platforms with a GLES-only GL implementation like some
raspberry pi or iMX platforms with vivante driver, GTK fails to
initialize its GL stack because it tries to bind to regular GL first
anyway before using the correct API as configured.

This can be tested by running gtk3-demo and the OpenGL area demo, which
will show nothing as no GL implementation could be found -- but it also
affects real GTK applications like epiphany (gnome web).

This was reported upstream a couple of years ago:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
and I submitted a patch yesterday:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062
(note as said there, this is already fixed in gtk 4)

Assuming the patch does get positive feedback and gets merged (I'm not
asking to backport some code before upstream review!!), what would the
way forward be?
gtk3 hasn't had a point release since May, and bullseye didn't get
updated to the latest stable release, so I assume we could backport the
patch? Would that be acceptable?

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

Kernel: Linux 5.10.145-0-at (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u2
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4+deb11u2
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4+deb11u2
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs  

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
pn  libcanberra-gtk3-module   
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1020936: RFP: hydrogen-doc -- Manual and Tutorial for the Hydrogen drum machine

[Nicholas D Steeves]

Also, I have to cut the tutorial.html from what would have been
src:hydrogen_1.2.0~beta1-1~exp1, because it's no longer DFSG-compliant.
If I remember correctly, this used to be a hand-written file, but
sometime in the past few years it began to be generated based on the
proposed src:hydrogen-doc upstream project.  See the following upstream
statement:

The [src:hydrogen] tarball includes the generated documentation for
1.0. The other files are the source files of the documentation, so
in my opinion they are not needed in the tarball. For development
purposes, you need the git repo, not the tarball.
(Mauser, 
https://github.com/hydrogen-music/hydrogen/issues/926#issuecomment-687332145)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1020929: RFS: tex-gyre/20180621-4 -- scalable PostScript and OpenType fonts based on URW Fonts

[Bastian Germann]

Am 29.09.22 um 00:20 schrieb Hilmar Preuße:

Am 28.09.2022 um 22:47 teilte Bastian Germann mit:

Hi Bastian,


Is this a team upload? If so, please add an entry to the changelog.


I've added "* Team upload." to the top of the changelog. Now lintian complains:

unnecessary-team-upload

The debian/changelog file refers to a "Team upload" but the uploader is listed 
amongst the Maintainer/Uploaders.

What would be correct here?


As you have added yourself to the Uploaders with 
https://github.com/debian-tex/tex-gyre/commit/5b1a987a6abb0f57ee6ba4af45abab17124b03ae please mention this change 
instead. I checked on the

current unstable version.

Bug#1020936: RFP: hydrogen-doc -- Manual and Tutorial for the Hydrogen drum machine

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Dennis Braun , Debian Multimedia 
Maintainers 

* Package name: hydrogen-doc
  Version : 1.1.1
  Upstream Author : The hydrogen development team 

* URL : https://github.com/hydrogen-music/documentation
* License : TBD, but almost certainly GPL-2+ 
(https://github.com/hydrogen-music/documentation/issues/73)
  Programming Lang: XML
  Description : Manual and Tutorial for the Hydrogen drum machine

This is the documentation and translation project for the Hydrogen
drum machine.  In includes a manual in Catalan, English, Spanish,
French, Italian, and Dutch, as well as a tutorial in English, French,
and Italian.

Upstream's preferred form of modification for these docs is an
independent git project, so it looks to me like it would be best to
create a new src:hydrogen-doc package to takeover bin:hydrogen-doc,
rather than to migrate src:hydrogen to the multitarball format.

Ideally this package should be maintained on the Debian Multimedia
team.

I might package it in a month, if I can find time then, and if no one
steps forward before then, but I'd sincerely appreciate if someone
else has the time motivation to maintain this new package :)

Regards,
Nicholas

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 17:59 -0400, Zack Weinberg wrote:
> On 2022-09-28 5:30 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote:
> > > "Available and usable at all times" is orthogonal to "maintainer
> > > scripts
> > > do not render the system unbootable".  As I read things, *all*
> > > packages
> > > bear the responsibility of not rendering the system unbootable.
> > 
> > No, it's a significantly weaker requirement than what you want to
> > impose. If it is not available and usable at all time, it can
> > clearly
> > render the system unbootable (by not being available or usable at
> > boot).
> 
> The vast majority of Debian packages provide programs, libraries,
> etc. 
> that are not used at all during the boot process.  Therefore, *even
> if* 
> those packages are currently unusable, due to a crash in the middle
> of 
> an upgrade that left them unpacked-but-not-configured, or whatever,
> they 
> can't prevent the system from coming up at least as far as the point 
> where it's possible to get a root shell and run `dpkg -a --
> configure`.

Yes, those packages are irrelevant and I wasn't talking about them
anywhere. So I don't know why you mention them now.

> The small subset of packages that *are* used at boot time, do need to
> take extra care to keep working even if they are unpacked but not 
> configured, and that subset and that extra requirement is codified as
> the rules for (transitively) Essential packages.

No, that is not correct. The set of packages required for boot is
significantly larger than essential and not well defined.

Common examples include: kernel, boot loaders, init system, ...; they
are often required for boot, but not essential.

I also don't think the essential requirements are sufficient for "works
after system crash".

> But *all* packages must take particular care *in their maintainer 
> scripts* to not render the system unbootable, because maintainer scripts 
> are all run with full root privileges, at a time when the system is in a 
> partially ill-defined state (since it is in the process of being 
> upgraded --

No, they usually aren't run in an ill-defined state.

> this is why we have the "postinst scripts can't assume any 
> non-Essential functionality works" rule),

There is no such rule. Seriously, this is getting nowhere.

If you want to tell maintainers they are wrong and everything they do
must be reverted, please at least inform yourself a bit more before
filing bugs with tech-ctte or vague release-critical bugs. Especially
if you do so for issues where people are already tired of talking
about.

> and yet it could still be in 
> active use (there has never been a requirement to take the system to 
> single-user mode before running 'apt-get upgrade').

That would be a different problem from "must work after arbitrary
system crash". I would prefer if we would not switch between different
problems.

> > I tried searching for that justification and a major internet
> > search
> > provider just says 'Your search - "potentially renders the system
> > unbootable" - did not match any documents.'
> 
> https://www.debian.org/Bugs/Developer#severities
> 
> The official wording appears to be "makes unrelated software on the 
> system (or the entire system) break".  I hope you will agree that a 
> system that doesn't boot is entirely broken.
> 
> https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L79
>  
> is where I got the "unbootable" phrasing.

No, there is a significant difference between "renders the entire
system unusable (e.g., unbootable [...]" and "potentially renders the
system unbootable".

Anyway, please take it to the ctte bug or just close this bug.

Ansgar

Bug#1020935: Idea

[Bower, Jesse (LNG-HBE)]

Maybe at 
https://salsa.debian.org/go-team/packages/git-lfs/-/blob/master/go.mod#L32

Bug#1020929: RFS: tex-gyre/20180621-4 -- scalable PostScript and OpenType fonts based on URW Fonts

[Hilmar Preuße]

Am 28.09.2022 um 22:47 teilte Bastian Germann mit:

Hi Bastian,


Is this a team upload? If so, please add an entry to the changelog.

I've added "* Team upload." to the top of the changelog. Now lintian 
complains:


unnecessary-team-upload

The debian/changelog file refers to a "Team upload" but the uploader is 
listed amongst the Maintainer/Uploaders.


What would be correct here?

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

[Eduard Bloch]

Hallo,
* Helge Deller [Wed, Sep 28 2022, 10:12:52PM]:
> On 9/28/22 21:52, Eduard Bloch wrote:

> If you call readdir() a few lines below, this readdir will not be able
> to store the file info in the dirent struct (if the file is located in
> high area of discs), instead returns NULL with errno set (e.g. E2BIG or like 
> that).
> Finally the readdir() will not work as expected as it doesn't find some files.
>
> [*] _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64

Both of them? I don't think so. _LARGEFILE_SOURCE will export some XYZo
functions of the C API, but I don't use them.

And _FILE_OFFSET_BITS IS set, I have no idea what you are talking about.
Check the logs, like 
https://buildd.debian.org/status/fetch.php?pkg=apt-cacher-ng=i386=3.7.4-1%2Bb1=1652551064=0

> I found a similiar issue with glibc right recently:
> https://sourceware.org/bugzilla/show_bug.cgi?id=29583
>
> > So do you have your cache on NFS with thousands of files in a single
> > directory?
>
> No, but a disc of TB size on a 32-bit platform.

Exactly, no. So where is the problem you are observing actually coming
from? So far I saw a weak theory, observation of some error status, and
pointing at "missing LFS". And the last part is not even true as far as
I could see.

> > > Sometimes I see a cron job warning:
> > > /etc/cron.daily/apt-cacher-ng:
> > > Aborted
> > > run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134
> > >
> > > Change is trivial, just add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS:
> >
> > This does not make sense. That would only inject a couple of runtime
> > influencing defines.
>
> Well, not just runtime influencing. More importantly: Build-time.

Obviously.

> They enlarge the dirent struct for 64-bit wide inode numbers and
> thus allow readdir() [which actually calls the readdir64 syscall then]
> to function properly.

You don't need to teach me the basics. I have added LFS support over a
decade ago. Please do at least some basic research to find things like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588048 .

> > apt-cacher-ng has been adding those defines since
> > the early days of its creation.
>
> Really?
> I don't find the CFLAGS _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64 in the 
> sources.

Strange, my grep command has no problems doing right that.

$ grep FILE_OFFSET src/* CMakeLists.txt
src/config.h:// added in Makefile... #define _FILE_OFFSET_BITS 64
src/meta.h:// _FILE_OFFSET_BITS mostly irrelevant. But if it's set, watch out 
for user's "experiments".
src/meta.h:#if _FILE_OFFSET_BITS == 32
src/meta.h:#error Unsupported: _FILE_OFFSET_BITS == 32 with large long size
src/meta.h:#if 64 == _FILE_OFFSET_BITS
src/meta.h:#if 32 == _FILE_OFFSET_BITS
CMakeLists.txt:SET(ACNG_COMPFLAGS "-D_FILE_OFFSET_BITS=64")

MfG,
Eduard.

Bug#1017098: decopy: may overturn the hierarchy of files w.r.t. the base debian/copyright file

[Francesco Poli]

On Fri, 23 Sep 2022 22:02:25 +0200 Jochen Sprickerhof wrote:

> Hi Francesco,

Hello Jochen,
thanks for your reply.

> 
> * Francesco Poli (wintermute)  [2022-08-13 19:08]:
> >I applied the following patch to the Makefile:
> >
> >  -CEX := po/
> >  +CEX := po/.*\.mo
> 
> This includes the po/*.po in the file list which where excluded, 
> previously.

Yes, that's intentional: the goal was to let decopy scan po/*.po files
too, in order to automatically pick updates (for instance, when their
copyright years change).

Is this the wrong way to achieve this result?

> 
> >Honestly, I expected that decopy would abide by this new base copyright
> >file and regenerate an identical debian/copyright file.
> 
> It works just fine if you do a debclean before generating it.

I checked and I confirm that it indeed works, after a debclean.

However, I added all the generated files to the --exclude argument,
precisely in order to avoid the need for a debclean.
I wanted decopy to act as if the generated files were absent.
Apparently, this is not what's happening.
Why?
Is the syntax I used for the --exclude option incorrect?


> 
> >Well, this looks (almost) technically correct,
> 
> Yes and I think that's all you can ask for for such a tool. To me decopy 
> is a good first step to create a d/copyright file but it always need 
> some human eyes.

Do you mean that you only use decopy for a first rough draft of the
debian/copyright file and then you modify it by hand?
That's what I thought to do myself.

But then, what do you do, when the source tree changes and the
debian/copyright file has to be updated?
Do you update it by hand?
Or do you re-run decopy with the outdated debian/copyright file as a
base for the processing?
My intention was to follow the latter strategy, hence my Makefile
target 'debian-copyright'...

Did I misunderstand how decopy should be used?

> 
> >Firstly, decopy decided that the license for po/* applies to * !!!
> 
> I don't know all the decopy code but I think it has some heuristics for 
> which copyright block should be the top one.

Well, I suspect the heuristics should be improved a bit...
I think that, when a preexisting debian/copyright file is used as a
base for processing, decopy should not change which copyright block is
used as the top one, unless there is a really strong reason to do so.

Do you agree?

> 
> >Then, I see that apt-listbugs.1 is listed among the special cases.
> >But that file is generated, and I thought it was excluded through
> >the --exclude option of decopy. Apparently, it is not! Why?
> 
> I guess exclude is only for the content not for the file list. Maybe 
> that's what meant in #997814..

Wait a second: do you mean that the --exclude option only prevents
decopy from looking inside the excluded files, but does not make decopy
ignore their existence?!?

If this is confirmed, I think a new option should be added (we could
perhaps call it "--ignore") that makes decopy act as if the ignored
files were absent.

> 
> >Finally, I fail to understand where the "2002-2020, Masato Taruishi"
> >additional Copyright come from.
> >It seems to me that every copyright notice referring to Masato Taruishi
> >in the source tree is either followed by his e-mail address or by "et al.".
> >So where does this additional Copyright come from?
> 
> decopy strips the et al.:
> 
> https://sources.debian.org/src/decopy/0.2.4.7-0.2/decopy/res.py/#L509
> 
> So with the Makefile change above the .po files are searched again and 
> the entry is added.

Ah, I see, thanks for the explanation.

But why does decopy strip "et al."?

And what's the correct way to specify that a copyright is owned
by one main owner plus many other co-owners?
I mean, the correct way for decopy.


Please let me know what you think about my doubts.
Thanks for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpPDXa_hrCOY.pgp
Description: PGP signature

Bug#1020926: Update architectures support

[Teresa Cancino]

Update of the mirrored architectures:

Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el s390x

Sorry for this modification, first time trying to publish a public mirror of 
Debian.

Thanks!
Regards
Teresa

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 5:30 PM, Ansgar wrote:

On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote:

"Available and usable at all times" is orthogonal to "maintainer scripts
do not render the system unbootable".  As I read things, *all* packages
bear the responsibility of not rendering the system unbootable.


No, it's a significantly weaker requirement than what you want to
impose. If it is not available and usable at all time, it can clearly
render the system unbootable (by not being available or usable at
boot).


The vast majority of Debian packages provide programs, libraries, etc. 
that are not used at all during the boot process.  Therefore, *even if* 
those packages are currently unusable, due to a crash in the middle of 
an upgrade that left them unpacked-but-not-configured, or whatever, they 
can't prevent the system from coming up at least as far as the point 
where it's possible to get a root shell and run `dpkg -a --configure`.


The small subset of packages that *are* used at boot time, do need to 
take extra care to keep working even if they are unpacked but not 
configured, and that subset and that extra requirement is codified as 
the rules for (transitively) Essential packages.


But *all* packages must take particular care *in their maintainer 
scripts* to not render the system unbootable, because maintainer scripts 
are all run with full root privileges, at a time when the system is in a 
partially ill-defined state (since it is in the process of being 
upgraded -- this is why we have the "postinst scripts can't assume any 
non-Essential functionality works" rule), and yet it could still be in 
active use (there has never been a requirement to take the system to 
single-user mode before running 'apt-get upgrade').


But most packages don't *do* anything in their maintainer scripts that 
has any serious *risk* of rendering the system unbootable, and therefore 
we don't have to worry about them.  The subset of packages that do 
dangerous things in their maintainer scripts *overlaps* the set of 
Essential packages, but there are members of each set that are not 
members of the other.


There is also a set of packages where it's the *installed software* that 
might have bugs that render the system unbootable, such as 
implementations of fsck for particular filesystems.


Do you understand the distinctions I am making?  If you don't, please 
explain what doesn't make sense about what I just said, because I don't 
think we're going to get any further with this discussion until you do.



One of the several documented
justifications for that severity is "potentially renders the system
unbootable".  I see nothing anywhere that limits the scope of that
justification to essential packages, or to any other subset of the archive.


I tried searching for that justification and a major internet search
provider just says 'Your search - "potentially renders the system
unbootable" - did not match any documents.'


https://www.debian.org/Bugs/Developer#severities

The official wording appears to be "makes unrelated software on the 
system (or the entire system) break".  I hope you will agree that a 
system that doesn't boot is entirely broken.


https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L79 
is where I got the "unbootable" phrasing.


zw

Bug#1020935: Old Version of go used to build git-lfs

[Bower, Jesse (LNG-HBE)]

Package: git-lfs
Version: 2.13.2-1+b5

After I install git-lfs the docker image is seen as having the following cve's:

CVE-2022-23806
CVE-2021-38297
CVE-2022-27664
CVE-2022-30631
CVE-2022-32189
CVE-2022-30632
CVE-2022-30635
CVE-2022-28131
CVE-2022-30630
CVE-2022-30633
CVE-2022-23773
CVE-2022-24921
CVE-2022-24675
CVE-2022-28327
CVE-2022-30580
CVE-2021-41772
CVE-2021-41771
CVE-2021-44716
CVE-2021-39293
CVE-2022-23772
CVE-2021-33194
CVE-2021-33195
CVE-2021-33196
CVE-2021-33198
CVE-2021-29923

Seen from the version of go used to build git-lfs,

"name": "go",
"version": "1.15.9",
"path": "/usr/bin/git-lfs",
"layerTime": 0,
"knownVulnerabilities": 72


Example Dockerfile used for testing

FROM debian:stable-slim

RUN apt-get update && apt-get upgrade -y && apt-get install -y git-lfs

I suggest that the version of go used to build git-lfs is updated to a current 
version.

Thank you,
Jesse Bower

Bug#906882: qt-gstreamer: diff for NMU version 1.2.0-5.2

[Sebastian Ramacher]

Control: tags 906882 + pending
Control: tags 997252 + pending

Dear maintainer,

I've prepared an NMU for qt-gstreamer (versioned as 1.2.0-5.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru qt-gstreamer-1.2.0/debian/changelog qt-gstreamer-1.2.0/debian/changelog
--- qt-gstreamer-1.2.0/debian/changelog	2021-02-22 19:31:22.0 +0100
+++ qt-gstreamer-1.2.0/debian/changelog	2022-09-28 23:40:14.0 +0200
@@ -1,3 +1,14 @@
+qt-gstreamer (1.2.0-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Simon McVittie ]
+  * debian/patches: Fix arguments passed to __atomic_load (Closes: #997252)
+  * debian/control: Add missing dependencies on Glib/GStreamer -dev packages
+(Closes: #906882)
+
+ -- Sebastian Ramacher   Wed, 28 Sep 2022 23:40:14 +0200
+
 qt-gstreamer (1.2.0-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru qt-gstreamer-1.2.0/debian/control qt-gstreamer-1.2.0/debian/control
--- qt-gstreamer-1.2.0/debian/control	2021-02-22 19:31:22.0 +0100
+++ qt-gstreamer-1.2.0/debian/control	2022-09-28 23:38:00.0 +0200
@@ -127,6 +127,9 @@
 Section: libdevel
 Architecture: any
 Depends: libboost-dev (>= 1.39),
+ libglib2.0-dev,
+ libgstreamer-plugins-base1.0-dev (>= 1.1.90),
+ libgstreamer1.0-dev,
  libqt5glib-2.0-0 (= ${binary:Version}),
  libqt5gstreamer-1.0-0 (= ${binary:Version}),
  libqt5gstreamerquick-1.0-0 (= ${binary:Version}),
@@ -134,6 +137,7 @@
  libqt5gstreamerutils-1.0-0 (= ${binary:Version}),
  qtbase5-dev,
  ${misc:Depends}
+Recommends: qtdeclarative5-dev
 Suggests: qtgstreamer-doc
 Description: Development headers for QtGStreamer - Qt 5 build
  QtGStreamer provides C++ bindings for GStreamer with a Qt-style API,
diff -Nru qt-gstreamer-1.2.0/debian/patches/Drop-unnecessary-volatile-qualifier-from-g_once_init_ente.patch qt-gstreamer-1.2.0/debian/patches/Drop-unnecessary-volatile-qualifier-from-g_once_init_ente.patch
--- qt-gstreamer-1.2.0/debian/patches/Drop-unnecessary-volatile-qualifier-from-g_once_init_ente.patch	1970-01-01 01:00:00.0 +0100
+++ qt-gstreamer-1.2.0/debian/patches/Drop-unnecessary-volatile-qualifier-from-g_once_init_ente.patch	2022-09-28 23:36:54.0 +0200
@@ -0,0 +1,32 @@
+From: Simon McVittie 
+Date: Fri, 22 Jul 2022 02:10:35 +0100
+Subject: Drop unnecessary volatile qualifier from g_once_init_enter()
+ argument
+
+When compiling with gcc, g_once_init_enter() is a macro implemented
+in terms of gcc's C++11-style atomic operations. Since gcc 11 it is
+considered to be an error to pass a volatile pointer to these built-in
+functions.
+
+The volatile qualifier appears to have been added as a result of a
+past misunderstanding about whether volatile is beneficial for
+thread-safety in C/C++ (it is not).
+
+Bug-Debian: https://bugs.debian.org/997252
+---
+ elements/gstqtvideosink/gstqtvideosinkplugin.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/elements/gstqtvideosink/gstqtvideosinkplugin.h b/elements/gstqtvideosink/gstqtvideosinkplugin.h
+index dc04671..a72c572 100644
+--- a/elements/gstqtvideosink/gstqtvideosinkplugin.h
 b/elements/gstqtvideosink/gstqtvideosinkplugin.h
+@@ -27,7 +27,7 @@ GST_DEBUG_CATEGORY_EXTERN(gst_qt_video_sink_debug);
+ #define DEFINE_TYPE_FULL(cpp_type, type_name, parent_type, additional_initializations) \
+ GType cpp_type::get_type() \
+ { \
+-static volatile gsize gonce_data = 0; \
++static gsize gonce_data = 0; \
+ if (g_once_init_enter(_data)) { \
+ GType type = 0; \
+ GTypeInfo info; \
diff -Nru qt-gstreamer-1.2.0/debian/patches/series qt-gstreamer-1.2.0/debian/patches/series
--- qt-gstreamer-1.2.0/debian/patches/series	2021-02-22 19:31:22.0 +0100
+++ qt-gstreamer-1.2.0/debian/patches/series	2022-09-28 23:37:21.0 +0200
@@ -4,3 +4,4 @@
 Furter-workarounds-for-build-failures-now-boost-1.61-and-.patch
 gstreamer-1.16.patch
 qt-gstreamer-1.18.patch
+Drop-unnecessary-volatile-qualifier-from-g_once_init_ente.patch

Bug#1020934: httest: Drop Build-Depends: libpcre++-dev

[Bastian Germann]

Source: httest
Version: 2.4.23-1.2
Severity: minor
Control: block 1017984 by -1

Please replace the obsolete build dependency libpcre++-dev with libpcre3-dev,
which is the right (and currently transitive) dependency.
Then libpcre++-dev can be removed.

Maybe you can find a way to get rid of libpcre3-dev as well, which is also 
obsolete.

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote:
> On 2022-09-28 3:45 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 15:39 -0400, Zack Weinberg wrote:
> > > On 2022-09-28 3:29 PM, Ansgar wrote:
> > > > On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote:
> > > > > On 2022-09-28 3:06 PM, Ansgar wrote:
> > > > > > Your requirement is that a system must *never* become
> > > > > > unbootable in
> > > > > > *all* of these states.
> > > > > 
> > > > > Yes, and furthermore I think Debian has required this for many,
> > > > > many
> > > > > years.
> > > > 
> > > > No, it never did.
> > > 
> > > I told you why I think it does.  Unless you can provide _evidence_
> > > that it doesn't, you're not going to change my mind.
> > 
> > Policy makes a special guarantee about essential packages:
> > 
> > +---
> > > Essential is defined as the minimal set of functionality that must
> > > be available and usable on the system at all times, even when
> > > packages are in the “Unpacked” state.
> > +---
> 
> "Available and usable at all times" is orthogonal to "maintainer scripts 
> do not render the system unbootable".  As I read things, *all* packages 
> bear the responsibility of not rendering the system unbootable.

No, it's a significantly weaker requirement than what you want to
impose. If it is not available and usable at all time, it can clearly
render the system unbootable (by not being available or usable at
boot).

> Naturally, most packages don't need to take particular care to avoid 
> rendering the system unbootable, since they don't do anything in their 
> maintainer scripts that would risk that.  But some do -- like bash, like 
> libc6, and like usrmerge -- and so they do need to take extra care, and 
> have always been expected to do so.

Maintainer scripts are only one part; not fully installed packages can
make the system unbootable for other reasons as mentioned earlier.

As you now only talk about maintainer scripts, are these no longer
relevant?

> > Please provide evidence that the even harder guarantees you demand are
> > made somewhere for a much larger set of packages that are critical for
> > boot. And are actually fulfilled in practice.
> 
> I already told you the answer to that question: it's inherent in the 
> definition of a severity:critical bug.  One of the several documented
> justifications for that severity is "potentially renders the system 
> unbootable".  I see nothing anywhere that limits the scope of that 
> justification to essential packages, or to any other subset of the archive.

I tried searching for that justification and a major internet search
provider just says 'Your search - "potentially renders the system
unbootable" - did not match any documents.'

Anyway, please send follow-ups not just to me, but the bug tracker and
ideally the tech-ctte bug.

Ansgar

Bug#1020933: cadabra: Drop Build-Depends: libpcre++-dev

[Bastian Germann]

Source: cadabra
Version: 1.46-5
Severity: minor
Control: block 1017984 by -1

Please drop the optional build dependency libpcre++-dev to contribute to the 
effort of getting rid of libpcre3: #159

Bug#1004022: clasp: diff for NMU version 3.3.5-4.1

[Sebastian Ramacher]

Control: tags 1004022 + pending

Dear maintainer,

I've prepared an NMU for clasp (versioned as 3.3.5-4.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru clasp-3.3.5/debian/changelog clasp-3.3.5/debian/changelog
--- clasp-3.3.5/debian/changelog	2020-12-28 13:26:04.0 +0100
+++ clasp-3.3.5/debian/changelog	2022-09-28 23:21:38.0 +0200
@@ -1,3 +1,12 @@
+clasp (3.3.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Lukas Märdian ]
+  * Use system-provided catch (Closes: #1004022)
+
+ -- Sebastian Ramacher   Wed, 28 Sep 2022 23:21:38 +0200
+
 clasp (3.3.5-4) unstable; urgency=medium
 
   * Bug fix: "non-standard gcc/g++ used for build (gcc-9)", thanks to
diff -Nru clasp-3.3.5/debian/control clasp-3.3.5/debian/control
--- clasp-3.3.5/debian/control	2020-12-26 22:25:24.0 +0100
+++ clasp-3.3.5/debian/control	2022-09-28 23:21:01.0 +0200
@@ -6,6 +6,7 @@
 Build-Depends: debhelper-compat (= 13),
  dpkg-dev (>= 1.16.1~),
  g++-10 (>= 10.2.1),
+ catch,
  cmake (>= 3.1.0)
 Rules-Requires-Root: no
 Standards-Version: 4.5.1
diff -Nru clasp-3.3.5/debian/patches/series clasp-3.3.5/debian/patches/series
--- clasp-3.3.5/debian/patches/series	2020-12-26 21:49:38.0 +0100
+++ clasp-3.3.5/debian/patches/series	2022-09-28 23:21:01.0 +0200
@@ -1,2 +1,3 @@
 clasp-manpage.patch
 link-libatomic-check-gcc.patch
+use-system-catch-for-glibc-2.34-compat.patch
diff -Nru clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch
--- clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch	1970-01-01 01:00:00.0 +0100
+++ clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch	2022-09-28 23:21:01.0 +0200
@@ -0,0 +1,296 @@
+Description: Fix 'catch' (CTest) compatibility with glibc-2.34
+ The clasp package contains an embedded copy of the 'catch' v1 (CTest)
+ library. That copy is outdated and incompatible with glibc-2.34.
+ This patch updates the test sources to use the system provided versions of
+ 'catch' instead, to fix this issue.
+ C.f.: https://github.com/catchorg/Catch2/issues/2178
+Author: Lukas Märdian 
+Origin: vendor, Ubuntu
+Forwarded: no
+Bug: https://github.com/potassco/clasp/issues/73
+Last-Update: 2022-01-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- clasp-3.3.5.orig/libpotassco/tests/main.cpp
 clasp-3.3.5/libpotassco/tests/main.cpp
+@@ -16,4 +16,4 @@ int enableDebugHeap() {
+ static int eh = enableDebugHeap();
+ #endif
+ #define CATCH_CONFIG_MAIN  // This tells Catch to provide a main() - only do this in one cpp file
+-#include "catch.hpp"
++#include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_application.cpp
 clasp-3.3.5/libpotassco/tests/test_application.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_aspif.cpp
 clasp-3.3.5/libpotassco/tests/test_aspif.cpp
+@@ -24,7 +24,7 @@
+ #ifdef _MSC_VER
+ #pragma warning (disable : 4996)
+ #endif
+-#include "catch.hpp"
++#include 
+ #include "test_common.h"
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_options.cpp
 clasp-3.3.5/libpotassco/tests/test_options.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_smodels.cpp
 clasp-3.3.5/libpotassco/tests/test_smodels.cpp
+@@ -22,7 +22,7 @@
+ // IN THE SOFTWARE.
+ //
+ 
+-#include "catch.hpp"
++#include 
+ #include "test_common.h"
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_string_convert.cpp
 clasp-3.3.5/libpotassco/tests/test_string_convert.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_text.cpp
 clasp-3.3.5/libpotassco/tests/test_text.cpp
+@@ -22,7 +22,7 @@
+ // IN THE SOFTWARE.
+ //
+ 
+-#include "catch.hpp"
++#include 
+ #include "test_common.h"
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_value.cpp
 clasp-3.3.5/libpotassco/tests/test_value.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ // IN 

Bug#1020230: transition: qtbase-opensource-src

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/qtbase-abi-5-15-6.html

On 2022-09-18 17:58:30 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: block -1 by 1019974
> 
> Dear Release team,
> 
> I would like to upgrade Qt 5 from 5.15.4 to 5.15.6. The packages are prepared
> in experimental. As usual, packages which use private ABI need to be rebuilt.

Please go ahead

Cheers

> 
> The only blocker I am aware of is uim FTBFS which affects armhf and maybe
> other architectures like armel (#1019974). The previous maintainer stepped
> down, so it's unlikely that we get it fixed anytime soon. Perhaps the binaries
> may be removed on this architecture(s).
> 
> Here is the ben file (no qtwebengine this time):
> 
> title = "Qt 5.15.6";
> is_affected = .depends ~ "qtbase-abi-5-15-4" | .depends ~ 
> "qtdeclarative-abi-5-15-4" | .depends ~ "qtbase-abi-5-15-6" | .depends ~ 
> "qtdeclarative-abi-5-15-6";
> is_good = .depends ~ "qtbase-abi-5-15-6" | .depends ~ 
> "qtdeclarative-abi-5-15-6";
> is_bad = .depends ~ "qtbase-abi-5-15-4" | .depends ~ 
> "qtdeclarative-abi-5-15-4";
> 
> --
> Dmitry Shachnev



-- 
Sebastian Ramacher

Bug#1020932: restinio: Drop Build-Depends: libpcre++-dev

[Bastian Germann]

Source: restinio
Version: 0.6.16-0.1
Severity: minor
Control: block 1017984 by -1

Please drop the optional build dependency libpcre++-dev to contribute to the 
effort of getting rid of libpcre3: #159

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

Well, I added that to my crypttab, and everything is fine again on my 
side :)


what happens next is up to you,  thank you for your help

El 26/9/22 a las 13:16, Michael Biebl escribió:


Am 20.09.22 um 06:47 schrieb ng:

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

Done,  I hope I did it right.



Thanks for forwarding this issue upstream.

It turns out, that adding "x-initrd.attach" to /etc/crypttab for the 
device holding the root fs does fix the issue.


This is nicely documented in systemd's man crypttab. Unfortunately we 
don't install this man page atm due to [1] which appears to go nowhere.


I guess we should do two things:
a/ dpkg-divert the cryptsetup provided man page and install the man 
page which we currently remove [2]


b/ clone this bug report and reassign it to d-i/partman so the debian 
installer adds the x-initrd.attach option when creating the luks+lvm 
setup.


Thoughts?

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981405
[2] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules#L219

Bug#993755: Comment

[David Wagner]

Otto's workaround also resolved the issue for me, thanks Otto!

I do not know what caused the issue as I did not upgrade, but some details
below just in case it is helpful for anybody:

I'm on Debian 10. Did not upgrade. Last I remember before issue was adding
some cryptographic libraries with pip/conda and following instructions here
[0] to add to apt sources to upgrade system Python. Found out because could
not SSH into GCP instance next day after restart. sshd was failing on start
finding libcrypto. Tried adding apt commands to startup script for VM and
using chpasswd to add temporary password for access through the serial
console, but both of those commands similarly failed without libcrypto.
Adding Otto's fixes to the VM's startup script got SSH working again.

[0] -
https://www.linode.com/docs/guides/how-to-install-python-on-debian-10/#how-to-upgrade-from-python-37-to-39

Bug#1020931: sord: Drop Build-Depends: libpcre++-dev

[Bastian Germann]

Package: sordi
Version: 0.16.14-1
Severity: minor
Control: block 1017984 by -1

Please drop the optional build dependency libpcre++-dev to contribute to the 
effort of getting rid of libpcre3: #159

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Ansgar]

On Wed, 2022-09-28 at 13:05 -0700, Sean Whitton wrote:
> On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote:
> > Package: tech-ctte
> > X-Debbugs-Cc: Zack Weinberg 
> > Control: block 1020920 by -1
> > 
> > Hi,
> > 
> > please clarify if atomic updates are mandatory for the Debian system.
> > Or other measures to ensure that system crashes at *any* time do not
> > render a system unbootable.
> > 
> > See also: https://bugs.debian.org/1020920
> 
> (1) Do you mean any package update?  Certain packages?  dist-upgrade?

Any package relevant for successful boot. Any upgrade.

As far as I can tell, the submitter requires some guarantees
significantly stronger than what Debian requires for essential
packages.

In particular, boot-relevant packages are demanded to work in
unconfigured state, with not fully satisfied dependencies (possibly not
even unpackaged?), in partly unpackaged states, after maintainer script
errors, and all of that in combination with system crashes that might
result in partly written data to filesystems. And possibly in other
interesting system states too.

> (2) The TC is a decision-making body of last resort.  The bug you
>     mention was filed today.  Might this be premature?

Well, if we close it or don't act on it, people will complain and/or
demand to remove us from Debian for not acting on it (the latter might
be limited to people just sitting on their porch).

The other tech-ctte bug about usrmerge also suggested it would just end
up here either way.

Ansgar

Bug#1020930: lintian: fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb

[Lucas Nussbaum]

Package: lintian
Version: 2.115.3
Severity: important

Hi,

lintian fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb
which can be downloaded at
http://ftp.debian.org/debian/pool/main/l/latex-cjk-chinese-arphic/latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb


$ lintian latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb 
Warning in processable latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb: In file 
usr/share/texmf/fonts/type1/arphic/gbsnu/gbsnuv.pfb: cp1252 "\x81" does not map 
to Unicode at /usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm 
line 57.
warning: cannot run fonts/postscript/type1 check on package 
binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all
skipping check of binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all
$ echo $?
1

Lucas



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

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

Versions of packages lintian depends on:
ii  binutils2.35.2-2
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.12
ii  dpkg-dev1.20.12
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2+deb11u2
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.6.0-1
ii  libapt-pkg-perl 0.1.39
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.12
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libhtml-tokeparser-simple-perl  3.16-3
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmldbm-perl   2.05-2.1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.59-2+b1
ii  libregexp-wildcards-perl1.05-2
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.21-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libwww-mechanize-perl   2.03-1
ii  libwww-perl 6.52-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip [lzip-decompressor]1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-4+deb11u2
ii  t1utils 1.41-4
ii  unzip   6.0-26+deb11u1
ii  xz-utils5.2.5-2.1~deb11u1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.2-2
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#1012893: [Help] anfo: ftbfs with GCC-12

[Aaron M. Ucko]

Andreas Tille  writes:

> Could anybody have a look at this gcc failure?

Per GCC's hint, please try formally substituting unique_ptr for
auto_ptr.  I haven't tested that approach for this package, but it's
typically a safe drop-in replacement, and generally yields compilation
errors in the rare cases where its usage would be problematic.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

[Helge Deller]

On 9/28/22 22:12, Helge Deller wrote:

The problem here is, that if those flags [*] aren't set, the "struct dirent"
will only be able to hold file numbers which are max. 32bits width.


"File numbers" is wrong... I meant "Inode number" (of the file).

Helge

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

[Helge Deller]

On 9/28/22 21:52, Eduard Bloch wrote:

Hallo,


Hallo Eduard,


* Helge Deller [Wed, Sep 28 2022, 12:46:53PM]:

Package: apt-cacher-ng
Severity: 3.7.4-1
Tags: lfs, hppa, patch

Please enable large file support.
apt-cacher-ng uses readdir() which can fail on 32-bit arches
running on large discs.


This does not make sense. readdir() does not care about large discs. It
might care about the file number in a directory. And while there are
some limitations with readdir for virtual filesystems (like NFS) there
should be no issue with local filesystem where kernel is maintaining the
internal handle with proper means.


In apt-cacher-ng-3.7.4/src/dirwalk.cc, line 100ff you find:

struct dirent *dp;
...
while ( nullptr != (dp = readdir(dir)) )
{
if (strcmp(dp->d_name, ".") && strcmp(dp->d_name, ".."))
{
The problem here is, that if those flags [*] aren't set, the "struct dirent"
will only be able to hold file numbers which are max. 32bits width.
If you call readdir() a few lines below, this readdir will not be able
to store the file info in the dirent struct (if the file is located in
high area of discs), instead returns NULL with errno set (e.g. E2BIG or like 
that).
Finally the readdir() will not work as expected as it doesn't find some files.

[*] _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64

I found a similiar issue with glibc right recently:
https://sourceware.org/bugzilla/show_bug.cgi?id=29583


So do you have your cache on NFS with thousands of files in a single
directory?


No, but a disc of TB size on a 32-bit platform.


Sometimes I see a cron job warning:
/etc/cron.daily/apt-cacher-ng:
Aborted
run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134

Change is trivial, just add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS:


This does not make sense. That would only inject a couple of runtime
influencing defines.


Well, not just runtime influencing. More importantly: Build-time.
They enlarge the dirent struct for 64-bit wide inode numbers and
thus allow readdir() [which actually calls the readdir64 syscall then]
to function properly.


apt-cacher-ng has been adding those defines since
the early days of its creation.


Really?
I don't find the CFLAGS _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64 in the 
sources.


And how would that affect readdir related syscalls?


I hope I explained above.

Helge

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Sean Whitton]

Hello,

On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote:

> Package: tech-ctte
> X-Debbugs-Cc: Zack Weinberg 
> Control: block 1020920 by -1
>
> Hi,
>
> please clarify if atomic updates are mandatory for the Debian system.
> Or other measures to ensure that system crashes at *any* time do not
> render a system unbootable.
>
> See also: https://bugs.debian.org/1020920

(1) Do you mean any package update?  Certain packages?  dist-upgrade?

(2) The TC is a decision-making body of last resort.  The bug you
mention was filed today.  Might this be premature?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017752: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM

[Andreas Tille]

Hi mips porters,

in bug #1017752 a

   FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory

is reported.  This remains for the new upstream version I've just
uploaded to experimental[1].  Do you see any chance to fix the memory
constraint for the autobuilder VM?  If not I'll remove mipsel from the
list of supported architectures to enable testing migration.

Kind regards

 Andreas.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=nheko=mipsel=0.10.1-1=1664394936=0

-- 
http://fam-tille.de

Bug#1020857: libc6: 2.35-1 breaks gdb on hppa

[John David Anglin]

If I start gdb with /lib/ld.so.1, it runs okay with glibc 2.35-1:

dave@mx3210:~/debian/gdb/gdb-12.1$ /lib/ld.so.1 /usr/bin/gdb
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) quit

dave@atlas:~/gnu/gdb/objdir$ /lib/ld.so.1 /usr/bin/gdb -c core /usr/bin/gdb
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gdb...
Reading symbols from 
/usr/lib/debug/.build-id/26/0797847dd13b287f99df369368a8a943c3d2f3.debug...
[New LWP 3873]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/home/dave/gnu/glibc/objdir/nptl_db/libthread_db.so.1".
Core was generated by `gdb'.
--Type  for more, q to quit, c to continue without paging--
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x4bc63f08 in ?? ()
(gdb) bt
#0  0x4bc63f08 in ?? ()
#1  0x006b5534 in operator new (sz=340)
    at /build/gdb-2W62n4/gdb-12.1/gdbsupport/new-op.cc:59
#2  0xf2ae4c00 in boost::basic_regex > >::do_assign(char const*, char const*, 
unsigned int) ()

   from /lib/hppa-linux-gnu/libboost_regex.so.1.74.0
#3  0xf4a98434 in ?? () from /lib/hppa-linux-gnu/libsource-highlight.so.4
#4  0xf773ae50 in call_init (env=0xf4b2f7dc, argv=0xf4b2f76c, argc=9790160,
    l=) at dl-init.c:70
#5  call_init (l=, argc=9790160, argv=0xf4b2f76c,
    env=0xf4b2f7dc) at dl-init.c:26
#6  0xf773af88 in _dl_init (main_map=0xf4b574c8, argc=-189597732, argv=0x0,
    env=0x9562d0) at dl-init.c:117
#7  0xf7750f9c in _dl_start_user () from /lib/ld.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

So, it looks like we die running array initializers:

  /* Next see whether there is an array with initialization functions.  */
  ElfW(Dyn) *init_array = l->l_info[DT_INIT_ARRAY];
  if (init_array != NULL)
    {
  unsigned int j;
  unsigned int jm;
  ElfW(Addr) *addrs;

  jm = l->l_info[DT_INIT_ARRAYSZ]->d_un.d_val / sizeof (ElfW(Addr));

  addrs = (ElfW(Addr) *) (init_array->d_un.d_ptr + l->l_addr);
  for (j = 0; j < jm; ++j)
    ((dl_init_t) addrs[j]) (argc, argv, env);
    }

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

[Eduard Bloch]

Hallo,
* Helge Deller [Wed, Sep 28 2022, 12:46:53PM]:
> Package: apt-cacher-ng
> Severity: 3.7.4-1
> Tags: lfs, hppa, patch
>
> Please enable large file support.
> apt-cacher-ng uses readdir() which can fail on 32-bit arches
> running on large discs.

This does not make sense. readdir() does not care about large discs. It
might care about the file number in a directory. And while there are
some limitations with readdir for virtual filesystems (like NFS) there
should be no issue with local filesystem where kernel is maintaining the
internal handle with proper means.

So do you have your cache on NFS with thousands of files in a single
directory?

> Sometimes I see a cron job warning:
> /etc/cron.daily/apt-cacher-ng:
> Aborted
> run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134
>
> Change is trivial, just add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS:

This does not make sense. That would only inject a couple of runtime
influencing defines. apt-cacher-ng has been adding those defines since
the early days of its creation.

And how would that affect readdir related syscalls?

Best regards,
Eduard.

--
Wenn wir bedenken, daß wir alle verrückt sind, ist das Leben erklärt.
-- Mark Twain (eigl. Samuel Langhorne Clemens)

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 15:39 -0400, Zack Weinberg wrote:
> On 2022-09-28 3:29 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote:
> > > On 2022-09-28 3:06 PM, Ansgar wrote:
> > > > Your requirement is that a system must *never* become
> > > > unbootable in
> > > > *all* of these states.
> > > 
> > > Yes, and furthermore I think Debian has required this for many,
> > > many
> > > years.
> > 
> > No, it never did.
> 
> I told you why I think it does.  Unless you can provide _evidence_
> that it doesn't, you're not going to change my mind.

Policy makes a special guarantee about essential packages:

+---
| Essential is defined as the minimal set of functionality that must
| be available and usable on the system at all times, even when
| packages are in the “Unpacked” state.
+---

Please provide evidence that the even harder guarantees you demand are
made somewhere for a much larger set of packages that are critical for
boot. And are actually fulfilled in practice.

Ansgar

Bug#1020929: RFS: tex-gyre/20180621-4 -- scalable PostScript and OpenType fonts based on URW Fonts

[Hilmar Preusse]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "tex-gyre":

 * Package name : tex-gyre
   Version  : 20180621-4
   Upstream contact : http://www.gust.org.pl/projects/e-foundry/tex-gyre/
 * URL  : https://www.gust.org.pl/projects/e-foundry/tex-gyre/
 * License  : GUST-Font-License, GUST-Font-License and DejaVu-License
 * Vcs  : https://github.com/debian-tex/tex-gyre
   Section  : tex

The source builds the following binary packages:

  tex-gyre - scalable PostScript and OpenType fonts based on URW Fonts
  fonts-texgyre - OpenType fonts based on URW Fonts
  fonts-texgyre-math - OpenType math fonts based on URW Fonts

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

  https://mentors.debian.net/package/tex-gyre/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tex-gyre/tex-gyre_20180621-4.dsc

Changes since the last upload:

 tex-gyre (20180621-4) unstable; urgency=medium
 .
   [ Hilmar Preusse ]
   * Lintian
 W: tex-gyre source: package-has-a-duplicate-build-relation
 W: tex-gyre source: debhelper-but-no-misc-depends
 I: tex-gyre source: unused-override no-debian-copyright-in-source
 I: fonts-texgyre: unused-override extra-license-file
 P: tex-gyre source: silent-on-rules-requiring-root
 P: tex-gyre source: no-dep5-copyright
 X: tex-gyre: maintainer-script-supports-ancient-package-version
   * Lintian Overrides:
 I: tex-gyre source: debian-watch-file-is-missing
 I: tex-gyre(-math): package-contains-documentation-outside-usr-share-doc
 I: tex-gyre: font-in-non-font-package
 I: tex-gyre: font-outside-font-dir
 .
   [ Norbert Preining ]
   * separate math fonts out into their own package
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Move source package lintian overrides to debian/source.
   * Bump debhelper from old 11 to 13.
   * Add missing build dependency on dh addon.
   * Update renamed lintian tag names in lintian overrides.
   * Remove Section on tex-gyre that duplicates source.
   * Remove constraints unnecessary since stretch:
 + Build-Depends: Drop versioned constraint on tex-common.
 + fonts-texgyre: Drop versioned constraint on tex-gyre in Replaces.
 + fonts-texgyre: Drop versioned constraint on tex-gyre in Breaks.
 + Remove 2 maintscript entries from 1 files.
   * Use secure URI in Homepage field.
   * Remove 1 obsolete maintscript entry.

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#1020894: glibc: Firefox 88 broken after glibc upgrade

[Aurelien Jarno]

control: found -1 2.34-1
control: found -1 2.35-1

Hi,

On 2022-09-28 07:51, программист некто wrote:
> Source: glibc
> Version: 2.36-1
> Severity: important
> 
> Hello. Tabs in Firefox 88 stop working after upgrade glibc to 2.36-1 from 
> 2.33-8. Every new opened tab immediately crashes.

For security reasons, Firefox use a sandbox filter based on seccomp for
the tabs processes. It explicitly lists the syscalls that can be used by
the tabs processes, however as Firefox uses glibc, when glibc start
using a new syscall (in your case clone3), this list needs to be updated
on the Firefox side. In the case of clone3, this has been done in
Firefox 91, you can find more details here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1715254

To continue using Firefox 88, you might want to disable the sandbox
filter by setting the MOZ_DISABLE_CONTENT_SANDBOX environment variable
to 1 (e.g. export MOZ_DISABLE_CONTENT_SANDBOX=1) before launching
Firefox, but please be aware of the security implications.

> I try to install old version glibc and found that 2.34 and 2.35 also breaks 
> Firefox 88.

Thanks for testing older versions, I have updated the bug report to
reflect that.

> There is a regression in glibc.

The problem is actually on the firefox side, which does not support
newer glibc version. Nevertheless we'll add a Breaks against firefox and
firefox-esr (<< 91) to the libc6 package to ensure smooth upgrade and
prevent this bug to happen.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote:
> On 2022-09-28 3:06 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote:
> > > On 2022-09-28 2:40 PM, Ansgar wrote:
> > > > > If I thought there was a bug in some other package that posed
> > > > > a
> > > > > significant risk of rendering Debian systems unbootable on
> > > > > upgrade, I
> > > > > would have filed a report against THAT PACKAGE.
> > > > 
> > > > Okay, so I understand this is an arbitrary requirement for
> > > > *just*
> > > > usrmerge. Any other package may still break the system (as
> > > > there are
> > > > enough critical packages).
> > > 
> > > I don't understand how you got from what I said to "this is an
> > > arbitrary
> > > requirement just for usrmerge".
> > > 
> > > It is, in fact, a *non*-arbitrary requirement, spelled out in
> > > Policy as
> > > such, that applies to *all* packages.  "Potentially breaks the
> > > entire
> > > system (e.g. by rendering it unbootable)" = critical-severity
> > > bug.
> > 
> > During upgrades, package dependencies might not be satisfied, there
> > is
> > no guarantee that non-essential (as in the Policy meaning of
> > essential)
> > packages work at all, partly-unpacked essential packages are likely
> > also interesting.
> > 
> > The system can crash while any of this is the case, not even
> > involving
> > more complex parts like maintainer scripts.
> > 
> > This obviously also includes boot loaders and similar.
> > 
> > Your requirement is that a system must *never* become unbootable in
> > *all* of these states. 
> 
> Yes, and furthermore I think Debian has required this for many, many
> years.

No, it never did.

> > So again: please show that other packages don't have such issues in
> > general.
> 
> I do not think it is reasonable for you to ask that I investigate the
> possibility of bugs existing in other packages before I file a bug on
> your package.

If you want to impose requirements on this package that are not imposed
elsewhere...

Ansgar

Bug#1012361: Interest in patch file?

[Soren Stoutner]

Would you be interested in a patch that updates this package to the current 
upstream (4.3.2)?  If so, I would be willing to submit a MR to the Salsa 
repository.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 3:06 PM, Ansgar wrote:

On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote:

On 2022-09-28 2:40 PM, Ansgar wrote:

If I thought there was a bug in some other package that posed a
significant risk of rendering Debian systems unbootable on upgrade, I
would have filed a report against THAT PACKAGE.


Okay, so I understand this is an arbitrary requirement for *just*
usrmerge. Any other package may still break the system (as there are
enough critical packages).


I don't understand how you got from what I said to "this is an arbitrary
requirement just for usrmerge".

It is, in fact, a *non*-arbitrary requirement, spelled out in Policy as
such, that applies to *all* packages.  "Potentially breaks the entire
system (e.g. by rendering it unbootable)" = critical-severity bug.


During upgrades, package dependencies might not be satisfied, there is
no guarantee that non-essential (as in the Policy meaning of essential)
packages work at all, partly-unpacked essential packages are likely
also interesting.

The system can crash while any of this is the case, not even involving
more complex parts like maintainer scripts.

This obviously also includes boot loaders and similar.

Your requirement is that a system must *never* become unbootable in
*all* of these states. 


Yes, and furthermore I think Debian has required this for many, many years.


So again: please show that other packages don't have such issues in
general.


I do not think it is reasonable for you to ask that I investigate the 
possibility of bugs existing in other packages before I file a bug on 
your package.


zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote:
> On 2022-09-28 2:40 PM, Ansgar wrote:
> > > If I thought there was a bug in some other package that posed a
> > > significant risk of rendering Debian systems unbootable on upgrade, I
> > > would have filed a report against THAT PACKAGE.
> > 
> > Okay, so I understand this is an arbitrary requirement for *just*
> > usrmerge. Any other package may still break the system (as there are
> > enough critical packages).
> 
> I don't understand how you got from what I said to "this is an arbitrary 
> requirement just for usrmerge".
> 
> It is, in fact, a *non*-arbitrary requirement, spelled out in Policy as 
> such, that applies to *all* packages.  "Potentially breaks the entire
> system (e.g. by rendering it unbootable)" = critical-severity bug.

During upgrades, package dependencies might not be satisfied, there is
no guarantee that non-essential (as in the Policy meaning of essential)
packages work at all, partly-unpacked essential packages are likely
also interesting.

The system can crash while any of this is the case, not even involving
more complex parts like maintainer scripts.

This obviously also includes boot loaders and similar.

Your requirement is that a system must *never* become unbootable in
*all* of these states. Unless of course, it is just usrmerge that is
required to provide guarantees that no other package is.

(Or change the entire system to mandatory A/B updates or similar
things.)

So again: please show that other packages don't have such issues in
general. I very much don't think so and do not think it is
particularily useful to demand this from one specific package.


Ansgar

Bug#1020927: ruby-all-dev: cross rbconfig is wrong package

[Helmut Grohne]

Package: ruby-all-dev,ruby3.0-dev
Version: 1:3.0+3.1
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:kross-interpreters

kross-interpreters fails to cross build for a number of reasons. Reason
one is that it depends on ruby rather than ruby:native and thus cannot
run ruby. This is not the problem I'm reporting here.

The next issue is that it needs the ruby-crossbuild's rbconfig.rb.
Unfortunately, that's not installed as it only depends on ruby,
ruby-dev. Thus I think that
/usr/lib//ruby-crossbuild/3.0.0/rbconfig.rb resides in the
wrong package. It should reside in ruby3.0-dev rather than ruby-all-dev.

And finally, kross-interpreters needs to set up a suitable RUBYLIBDIR.

Of these issues, only the ownership of the cross rbconfig.rb is reported
here.

Antonio, can I ask you to perform the move?

I suppose we first need to upload a new ruby-defaults that drops these
files (thus breaking all cross builds). Then we need to upload rubyVER
adding it back together with suitable Breaks+Replaces. I don't think the
new ruby-defaults need versioned Depends to ensure the presence of these
files, because they are absent in stable. I'll have to deal with the
temporary breakage of cross builds.

Do you agree with this?

Helmut

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 2:16 PM, Marco d'Itri wrote:

it appears to be possible
for the next boot to find the root filesystem in a state where /lib or
/bin doesn’t exist at all.  Recovery from this state will require
booting from installation media.

This is technically correct.
But after 8 years of development in Debian, and after Ubuntu converting
all their user base on upgrades, no such event has been reported.


I don't think you can draw conclusions from Ubuntu in this context since 
their upgrade process is radically different.  If I remember correctly, 
they invoke convert-usrmerge at a point when the system is effectively 
in single-user mode, and thus other processes are much less likely to 
interfere.


I also don't think you can draw conclusions from 8 years of past 
development within Debian because the vast majority of Debian 
installations that were originally installed unmerged (pre-bullseye or 
opt out) *have not yet been converted*.  Most people who maintain Debian 
installations, after all, aren't paying any attention to this process. 
They'll get the conversion *only* when they upgrade to bookworm.


As such I think we haven't yet seen *most* of the truly weird conditions 
under which convert-usrmerge will be invoked, and I think you should 
reconsider.


zw

Bug#1012893: [Help] anfo: ftbfs with GCC-12

[Andreas Tille]

Control: tags -1 help

Could anybody have a look at this gcc failure?

Thanks in advance

  Andreas.

-- 
http://fam-tille.de

Bug#1020926: mirror submission for mirror.hnd.cl

[Teresa Cancino]

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

Submission-Type: new
Site: mirror.hnd.cl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Teresa Cancino 
Country: CL Chile
Location: Santiago, Chile
Sponsor: Hostednode SpA https://hnd.cl
Comment: Resend request as rsync isnt available at this time.




Trace Url: http://mirror.hnd.cl/debian/project/trace/
Trace Url: http://mirror.hnd.cl/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.hnd.cl/debian/project/trace/mirror.hnd.cl

Bug#1020925: mirror submission for mirror.hnd.cl

[Teresa Cancino]

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

Submission-Type: new
Site: mirror.hnd.cl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Teresa Cancino 
Country: CL Chile
Location: Santiago, Chile
Sponsor: Hostednode SpA https://hnd.cl




Trace Url: http://mirror.hnd.cl/debian/project/trace/
Trace Url: http://mirror.hnd.cl/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.hnd.cl/debian/project/trace/mirror.hnd.cl

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 14:32 -0400, Zack Weinberg wrote:
> On 2022-09-28 2:04 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote:
> > > On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:
> > > > No, you would need to atomically replace the *entire* system,
> > > > not
> > > > just
> > > > individual directories.
> > > 
> > > ??? Atomic replacement of each affected directory is, as far as I
> > > can
> > > see, both necessary and sufficient to prevent the system being
> > > rendered unbootable.
> > 
> > No. It is not sufficient. Upgrading packages can affect multiple
> > directories and half-upgraded packages can easily render systems
> > unbootable.
> 
> Do I really have to spell this out for you?
> 
> Atomic replacement of each directory replaced with a symlink by 
> convert-usrmerge should be sufficient [unless I missed something
> while 
> reading through convert-usrmerge's code] to prevent the system being 
> unbootable AS A CONSEQUENCE OF ACTIONS PERFORMED BY convert-usrmerge.
> 
> If I thought there was a bug in some other package that posed a 
> significant risk of rendering Debian systems unbootable on upgrade, I
> would have filed a report against THAT PACKAGE.

Okay, so I understand this is an arbitrary requirement for *just*
usrmerge. Any other package may still break the system (as there are
enough critical packages).

Of course, if not correct, you can demonstrate there are no other
packages that will make the system unbootable if half-upgraded
(including combinations involving multiple packages).

Ansgar

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Russ Allbery]

Zack Weinberg  writes:

> That does not clearly say that a *pair* of packages, where one installs
> files in /path and the other one installs files in /usr/path, is not 
> allowed.  I'm guessing it was the *intent*, but the example, at least,
> makes it sound like it's only talking about within a single package.

Thanks, good catch.  We've been dealing with this elsewhere as the other
replies pointed out, but we should update the wording in Policy to make
this explicit.

I'll open a separate bug for that.

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

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 2:04 PM, Ansgar wrote:

On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote:

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:

No, you would need to atomically replace the *entire* system, not
just
individual directories.


??? Atomic replacement of each affected directory is, as far as I can
see, both necessary and sufficient to prevent the system being
rendered unbootable.


No. It is not sufficient. Upgrading packages can affect multiple
directories and half-upgraded packages can easily render systems
unbootable.


Do I really have to spell this out for you?

Atomic replacement of each directory replaced with a symlink by 
convert-usrmerge should be sufficient [unless I missed something while 
reading through convert-usrmerge's code] to prevent the system being 
unbootable AS A CONSEQUENCE OF ACTIONS PERFORMED BY convert-usrmerge.


If I thought there was a bug in some other package that posed a 
significant risk of rendering Debian systems unbootable on upgrade, I 
would have filed a report against THAT PACKAGE.


zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On 2022-09-28 2:16 PM, Russ Allbery wrote:

"Zack Weinberg"  writes:


1. Is there already a rule (or multiple rules) somewhere that forbids
the existence of pairs of packages where one ships /X/Y and the
other ships /usr/X/Y, where X is a directory on non-merged-/usr
systems and a symlink on merged-/usr systems, and Y is any name?


Policy 10.1:

 To support merged-/usr systems, packages must not install files in
 both /path and /usr/path. For example, a package must not install both
 /bin/example and /usr/bin/example.


That does not clearly say that a *pair* of packages, where one installs 
files in /path and the other one installs files in /usr/path, is not 
allowed.  I'm guessing it was the *intent*, but the example, at least, 
makes it sound like it's only talking about within a single package. 
Suggest maybe the editorial addition of


For another example, if one package installs /bin/example, then
no package which is coinstallable with that package may install
/usr/bin/example.

(the "coinstallable with" clause means to clarify that the existing pair 
discussed upthread is fine because there's a package-level Conflicts)


zw

Bug#1020787: Xen: After updating to 5.19 kernel the VMs are started without XSAVE CPU flags

[Hans van Kranenburg]

Hi!

On 9/28/22 00:55, Diederik de Haas wrote:
> On Wednesday, 28 September 2022 00:24:27 CEST Patrick wrote:
>> I just applied the patch
>> (xen.git-c3bd0b83ea5b7c0da6542687436042eeea1e7909.patch) to the xen
>> packages and can confirm that this fixes the problems. The xsave flags are
>> available again and thus the binaries work too.
> 
> That is awesome, thank you :-)
> 
> IIUC:
> - Xen upstream will backport the patch to the stable branches; I do not know 
> when that will happen
> - Debian's package will probably be updated before that and 4.16.2-2 will be 
> uploaded to Sid Soon (tm) with that patch applied

Thanks for doing the investigation!

I'm currently preparing 4.16.2-2 which includes the fix.

Hans

Bug#1018118: transition: mutter & gnome-shell 43

[Simon McVittie]

On Wed, 28 Sep 2022 at 00:56:10 +0200, Sebastian Ramacher wrote:
> On 2022-09-11 07:53:01 -0400, Jeremy Bicha wrote:
> > As in previous gnome-shell transitions, there are still lots of
> > packaged gnome-shell extensions that aren't compatible and will need
> > to be ported or removed from Testing.

The number of incompatible extensions has gone down dramatically
(most have been fixed). Please remove these two remaining incompatible
extensions from testing:

gnome-shell-extension-sound-device-chooser/43-1 (#1018277)
gnome-shell-extension-volume-mixer/41.1+dfsg-2 (#1018284)

Thanks,
smcv

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Svante Signell]

Hi,

I would really appreciate if you quote your reply properly:
It was not Andreas Metzler who sent the below:

> On Tue, 2022-09-27 at 18:25 +0200, Andreas Metzler wrote:
> > On 2022-09-27 Zack Weinberg  wrote:
> > [...]

On Wed, 2022-09-28 at 11:55 +0100, Luca Boccassi wrote:

> > 
> > > This number is of usrmerged systems is so large that we cannot mark
> > > them as unsupported ("Please reinstall"). Whether this percentage
> > > is 25% or 90% does not matter.
> > 
> > You can easily revert any system having usrmerge installed with dpkg-
> > fsys-usrunmess. This should be known by all Debian users, by some
> > suitable channel.
> > 
> > And for example the latest init-system-helpers release should add
> > this to the package description (if not reverted). This applies to
> > other present and future packages having usrmerge as a dependency
> > too.
> 
> Please note that this will result in an unsupported system, as per CTTE
> decision. It is important to note this, for the record. So no, that
> will not be added anywhere, package description or otherwise, and in
> fact the last time it was "made known by all Debian users" it caused
> quite a lot of damage, and was forcefully reverted.

Please learn how to properly quote/reply to peoples postings :(

Thanks!

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Marco d'Itri]

Control: severity -1 wishlist

On Sep 28, Zack Weinberg  wrote:

> convert-usrmerge is nominally idempotent and restartable, but (as it
> says in the script’s own documentation) if “the system crashes at a
> really bad time” during the conversion process it might not be
> possible to recover without manual intervention.  Unfortunately, it’s
> worse than that: if the system crashes at _just_ the wrong time
> (specifically, in the middle of a convert_directory operation, in
> between the rename() and symlink() calls) it appears to be possible
> for the next boot to find the root filesystem in a state where /lib or
> /bin doesn’t exist at all.  Recovery from this state will require
> booting from installation media.
This is technically correct.
But after 8 years of development in Debian, and after Ubuntu converting 
all their user base on upgrades, no such event has been reported.
Hence I believe that adding significant complexity to the package is not 
justified at this point because the risk of introducing more bugs would 
be higher than the (actually measured) risk of what you described 
actually happening.

> To fix this, I think some technique for replacing directories with
> symlinks _atomically_ needs to be found.
Such a tecnique is described in the TODO file in the source package.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Russ Allbery]

"Zack Weinberg"  writes:

> 1. Is there already a rule (or multiple rules) somewhere that forbids
>the existence of pairs of packages where one ships /X/Y and the
>other ships /usr/X/Y, where X is a directory on non-merged-/usr
>systems and a symlink on merged-/usr systems, and Y is any name?

Policy 10.1:

To support merged-/usr systems, packages must not install files in
both /path and /usr/path. For example, a package must not install both
/bin/example and /usr/bin/example.

If a file is moved between /path and /usr/path in revisions of a
Debian package, and a compatibility symlink at the old path is needed,
the symlink must be managed in a way that will not break when /path
and /usr/path are the same underlying directory due to symlinks or
other mechanisms.

We've had that rule in Policy since May of 2017.

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

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote:
> On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:
> > No, you would need to atomically replace the *entire* system, not
> > just
> > individual directories.
> 
> ??? Atomic replacement of each affected directory is, as far as I can
> see, both necessary and sufficient to prevent the system being
> rendered unbootable.

No. It is not sufficient. Upgrading packages can affect multiple
directories and half-upgraded packages can easily render systems
unbootable.

Ansgar

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Luca Boccassi]

Control: severity -1 wishlist

On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote:
> On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:
> > No, you would need to atomically replace the *entire* system, not just
> > individual directories.
> 
> ??? Atomic replacement of each affected directory is, as far as I can see, 
> both necessary and sufficient to prevent the system being rendered unbootable.
> 
> > But please explain how this is specifc to usrmerge and not many other
> > packages.
> 
> As I already said, this code needs to be extra robust because it is being run 
> from a postinst script, at some unpredictable moment in the middle of an 
> upgrade to bookworm (in most cases).

You _said_ it, but you really didn't explain it. Let's ask again: why
should this be any different than any other package that can bork a
system if it crashes just at the right time, of which there are many?

Given there's no rationale nor explanation, let's downgrade for now.

-- 
Kind regards,
Luca Boccassi


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

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Ansgar]

Package: tech-ctte
X-Debbugs-Cc: Zack Weinberg 
Control: block 1020920 by -1

Hi,

please clarify if atomic updates are mandatory for the Debian system.
Or other measures to ensure that system crashes at *any* time do not
render a system unbootable.

See also: https://bugs.debian.org/1020920

Thanks,
Ansgar

Bug#1020922: usrmerge: please split convert-* scripts into separate package from the postinst that actually performs the conversion

[Luca Boccassi]

Control: tags -1 moreinfo

On Wed, 2022-09-28 at 13:41 -0400, Zack Weinberg wrote:
> Source: usrmerge
> Version: 31
> Severity: wishlist
> X-Debbugs-Cc: z...@owlfolio.org
> 
> It would be significantly easier to experiment with convert-usrmerge
> under exotic conditions if the scripts were installable without also
> pulling the postinst that performs the conversion.

On all systems, usrmerge is either already installed or can be
installed as a no-op because usr-is-merged is already present. What use
case would that solve that is thus not already covered?

-- 
Kind regards,
Luca Boccassi


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

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:
> No, you would need to atomically replace the *entire* system, not just
> individual directories.

??? Atomic replacement of each affected directory is, as far as I can see, both 
necessary and sufficient to prevent the system being rendered unbootable.

> But please explain how this is specifc to usrmerge and not many other
> packages.

As I already said, this code needs to be extra robust because it is being run 
from a postinst script, at some unpredictable moment in the middle of an 
upgrade to bookworm (in most cases).

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote:
> Hi Zack,
>
> On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
>> I thought about this a bunch yesterday evening and I believe I see a
>> concrete scenario that can cause problems but is not covered by the
>> moratorium: Suppose there exist two packages, one of which ships
>> /bin/foo, and the other ships /usr/bin/foo.  On a non-merged system,
>> these packages can coexist.  On a merged system, they have a file
>> conflict that dpkg will not detect.
>
> $ ssh delfin.debian.org sqlite3 
> /srv/dedup.debian.org/database/dedup.sqlite3 '"'"SELECT * FROM content 
> AS ca JOIN content AS cb ON ca.filename = './usr' || 
> substr(cb.filename, 2) WHERE cb.filename NOT LIKE './usr/%';"'"'
> 166447797|96615|./usr/bin/systemctl|201531|221889683|4004|./bin/systemctl|1173136
> 210029518|32365|./usr/sbin/update-service|2917|223295080|31077|./sbin/update-service|4573
> $
>
> So we have systemctl vs systemd and daemontools-run vs runit, both of
> which declare Conflicts.

*nod* I don't think we need to worry about this when there's a declared 
package-level conflict.

> Depends on whether you consider that one-liner above tooling I guess.

Good enough for now, probably -- it would be nice to have some automation 
searching for such overlaps in packages that *don't* declare Conflicts, and 
filing bugs, but I won't call that a blocker.

> Do you see any other issues?

Not at present, but I'm not the person you should be asking!  The only person 
who could possibly say "yeah, the rules in place are sufficient to prevent 
problems post-bookworm until the bugs are actually fixed", with the level of 
confidence we need before proceeding with this transition, is ... the dpkg 
maintainer.

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Wed, Sep 28, 2022, at 5:08 AM, Svante Signell wrote:
>
> You can easily revert any system having usrmerge installed with dpkg-
> fsys-usrunmess. This should be known by all Debian users, by some
> suitable channel.

Having used it myself a couple of times, I would question "easily".  If all 
goes well, yes, you run it and you reboot and you're done, but if all *doesn't* 
go well you're left having to manually repair a system with important files not 
existing in *either* their unmerged or their merged location, which may require 
booting from recovery media.

I'd say that if Debian were going to widely advertise the availability of 
dpkg-fsys-usrunmess, first it ought to be revamped to ensure that it's fully 
restartable, idempotent, and never, not even transiently, places the system in 
a state where it cannot boot at least as far as single user mode (in systemd 
terms, rescue.target, *not* just emergency.target).

Of course the exact same criticism applies to convert-usrmerge -- skimming its 
code just now, it appears to be idempotent and restartable in principle, but if 
"the system crashes at a really bad time" (to quote its own comments) I think 
it _could_ leave the system in a state where it cannot boot as far as 
rescue.target.  In fact, see #1020920.

zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Ansgar]

On Wed, 2022-09-28 at 13:39 -0400, Zack Weinberg wrote:
> convert-usrmerge is nominally idempotent and restartable, but (as it
> says in the script’s own documentation) if “the system crashes at a
> really bad time” during the conversion process it might not be
> possible to recover without manual intervention.  Unfortunately, it’s
> worse than that: if the system crashes at _just_ the wrong time
> (specifically, in the middle of a convert_directory operation, in
> between the rename() and symlink() calls) it appears to be possible
> for the next boot to find the root filesystem in a state where /lib
> or /bin doesn’t exist at all.  Recovery from this state will require
> booting from installation media.

There are many packages that will render a package unbootable if the
system crashes at just the wrong time...

You need a very, very large change to how Debian works to change that.

> To fix this, I think some technique for replacing directories with
> symlinks _atomically_ needs to be found.

No, you would need to atomically replace the *entire* system, not just
individual directories.

But please explain how this is specifc to usrmerge and not many other
packages.

Ansgar

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Helmut Grohne]

Hi Zack,

On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
> I thought about this a bunch yesterday evening and I believe I see a
> concrete scenario that can cause problems but is not covered by the
> moratorium: Suppose there exist two packages, one of which ships
> /bin/foo, and the other ships /usr/bin/foo.  On a non-merged system,
> these packages can coexist.  On a merged system, they have a file
> conflict that dpkg will not detect.

$ ssh delfin.debian.org sqlite3 /srv/dedup.debian.org/database/dedup.sqlite3 
'"'"SELECT * FROM content AS ca JOIN content AS cb ON ca.filename = './usr' || 
substr(cb.filename, 2) WHERE cb.filename NOT LIKE './usr/%';"'"'
166447797|96615|./usr/bin/systemctl|201531|221889683|4004|./bin/systemctl|1173136
210029518|32365|./usr/sbin/update-service|2917|223295080|31077|./sbin/update-service|4573
$

So we have systemctl vs systemd and daemontools-run vs runit, both of
which declare Conflicts.

> So questions for you and everyone else reading this:
> 
> 1. Is there already a rule (or multiple rules) somewhere that forbids
>the existence of pairs of packages where one ships /X/Y and the
>other ships /usr/X/Y, where X is a directory on non-merged-/usr
>systems and a symlink on merged-/usr systems, and Y is any name?

I think Marco et al have been filing bugs about these kind of issues and
NMUing the remainders a very long time ago way before debootstrap
defaulted to merged /usr.

> 2. Does Debian already have tooling that can *find* pairs of such
>packages?  (This is a fully independent question from 1.  If
>there's a rule but no automation to enforce it then we don't *know*
>nobody's breaking the rule.  If there is no rule then, before we
>consider adding such a rule, we need to know whether any packages
>exist that break it.)

Depends on whether you consider that one-liner above tooling I guess.

Do you see any other issues?

Helmut

Bug#1020922: usrmerge: please split convert-* scripts into separate package from the postinst that actually performs the conversion

[Zack Weinberg]

Source: usrmerge
Version: 31
Severity: wishlist
X-Debbugs-Cc: z...@owlfolio.org

It would be significantly easier to experiment with convert-usrmerge
under exotic conditions if the scripts were installable without also
pulling the postinst that performs the conversion.


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

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

Bug#1020921: openttd FTCBFS: requires native strgen

[Helmut Grohne]

Source: openttd
Version: 12.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Since openttd 12.1, upstream requires building the strgen utility in a
separate build pass for cross builds. The packaging has not been updated
to accommodate this. As such, it fails running strgen. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru openttd-12.2/debian/changelog openttd-12.2/debian/changelog
--- openttd-12.2/debian/changelog   2022-04-20 15:17:01.0 +0200
+++ openttd-12.2/debian/changelog   2022-09-28 09:58:26.0 +0200
@@ -1,3 +1,10 @@
+openttd (12.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build native strgen. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 28 Sep 2022 09:58:26 +0200
+
 openttd (12.2-1) unstable; urgency=medium
 
   * [789d2fd] Fix typo in Suggests: timidity (Closes: #1003269)
diff --minimal -Nru openttd-12.2/debian/clean openttd-12.2/debian/clean
--- openttd-12.2/debian/clean   1970-01-01 01:00:00.0 +0100
+++ openttd-12.2/debian/clean   2022-09-28 09:58:24.0 +0200
@@ -0,0 +1 @@
+build-native
diff --minimal -Nru openttd-12.2/debian/rules openttd-12.2/debian/rules
--- openttd-12.2/debian/rules   2022-04-20 15:17:01.0 +0200
+++ openttd-12.2/debian/rules   2022-09-28 09:58:26.0 +0200
@@ -2,6 +2,8 @@
 # -*- makefile -*-
 # Makefile to build the openttd debian package.
 
+include /usr/share/dpkg/architecture.mk
+
 # Use debhelper default for all targets (but some are overridden below).
 %:
dh $@ --buildsystem=cmake
@@ -37,7 +39,11 @@
 # to be explicit about the dependencies, in case we're not running in a
 # clean build root.
 override_dh_auto_configure:
-   dh_auto_configure -- $(CMAKE_CONFIG_ARGUMENTS)
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
-Bbuild-native -- -DOPTION_TOOLS_ONLY=ON
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build -Bbuild-native
+endif
+   dh_auto_configure -- $(CMAKE_CONFIG_ARGUMENTS) $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,-DHOST_BINARY_DIR=$(CURDIR)/build-native)
 
 execute_after_dh_install-arch:
# Prevent installing duplicate license file

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

Package: usrmerge
Version: 31
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: z...@owlfolio.org

convert-usrmerge is nominally idempotent and restartable, but (as it
says in the script’s own documentation) if “the system crashes at a
really bad time” during the conversion process it might not be
possible to recover without manual intervention.  Unfortunately, it’s
worse than that: if the system crashes at _just_ the wrong time
(specifically, in the middle of a convert_directory operation, in
between the rename() and symlink() calls) it appears to be possible
for the next boot to find the root filesystem in a state where /lib or
/bin doesn’t exist at all.  Recovery from this state will require
booting from installation media.

Since the current plan for the usrmerge transition is to run
convert-usrmerge from usrmerge’s postinst, during (for most
installations where a conversion is required) a bullseye->bookworm
upgrade, which system administrators may choose to do *without*
dropping to single user mode, a crash at exactly that point is
plausible due to interactions with other concurrent processes.
Imagine that a watchdog process picks exactly the moment where /bin is
being replaced to check whether it can exec /bin/true, or (perhaps
more plausible) a server picks exactly the moment where /lib is being
replaced to try to load an NSS module, fails, crashes, and then a
watchdog notices the server crash and triggers a reboot.

To fix this, I think some technique for replacing directories with
symlinks _atomically_ needs to be found.


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

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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-5

usrmerge recommends no packages.

usrmerge suggests no packages.

Bug#1009990: libmutter-11-0: Night Light is unavailable on a system where it was working earlier

[Jeremy Bicha]

On Wed, Sep 28, 2022 at 9:00 AM Chandra Sekar Srinivasan
 wrote:
> Even after upgrading mutter to 43.0.2, the Night Light panel under
> Display settings says,
>
> "Night Light Unavailable
>
> This could be the result of the graphics driver being used, or the desktop 
> being used remotely"
>
> I have an AMD graphics card and Night Light used to work on this system
> until one of the updates in the past broke it, as described in the
> original report.
>
> $ lspci | grep VGA

You should file a new bug since your specific issue may not be the
same as the original issue.

I know that there is a bug where gnome-control-center says that Night
Light is Unavailable but it may actually work.

Thank you,
Jeremy Bicha

Bug#1020293: waiting how to proceed

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Alexandre,

please remove the moreinfo tag or close the bug according to whether the 
package shall go or stay.

(or change the Subject: in case something else should happen)

  Thorsten

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Jonas Smedegaard]

Quoting Lev Lamberov (2022-09-28 09:35:00)
> Since now SWI-Prolog in Debian supports setting an arch-independent path
> to the interpreter (8.4.3+dfsg-1, uploaded on 2022-09-18, in testing
> since 2022-09-21), I'm reassigning this bug report to eye. The eye
> package needs rebuild against the mentioned new swi-prolog version using
> something like this command:
> 
> swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl

Hmm - seems I will need some additional guidance - the above does not
work for me.

This is the command that was used previously:

  swipl -q -f eye.pl -g main -- --image eye.pvm

I tried replacing with the following command:

  swipl -q -c eye.pl -g main --emulator=/usr/bin/swipl -o eye.pvm

...but that did *not* generate file "eye.pvm" but instead "a.out" which
did not behave as expected (running `./a.out --help` ended in some
prompt - I guess a SWI-Prolog prompt).

I then tried this command:

  swipl -o myexe --emulator=/usr/bin/swipl -c eye.pl

...which generated expected file, but again it offered some prompt not
expected eye interface.

Can you help suggest a command?


 - Jonas

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

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

signature.asc
Description: signature

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Ansgar]

On Wed, 2022-09-28 at 12:29 -0400, Zack Weinberg wrote:
> 1. Is there already a rule (or multiple rules) somewhere that forbids
>    the existence of pairs of packages where one ships /X/Y and the
>    other ships /usr/X/Y, where X is a directory on non-merged-/usr
>    systems and a symlink on merged-/usr systems, and Y is any name?

*sigh*

There has been such a rule for many, many years already.

I really feel you lack investigating the issue before filing yet
another ctte bug about it.

Ansgar

Bug#1008985: Fwd: Bug#1008985: mirror listing update for debian.cs.nctu.edu.tw

[鐘凡]

-- Forwarded message -
寄件者： 鐘凡 
Date: 2022年9月29日 週四 凌晨12:43
Subject: Re: Bug#1008985: mirror listing update for debian.cs.nctu.edu.tw
To: Julien Cristau 


Hi Julien,

Sure, I have modified it!

--
Best regards,
Fan Chung,
Computer Center, Department of Computer Science,
National Yang Ming Chiao Tung University, Taiwan.
1001 University Road, Hsinchu, Taiwan 300, ROC.




Julien Cristau  於 2022年9月17日 週六 晚上9:10寫道：

> Hi,
>
> Could you please change the mirror name (MIRRORNAME variable in
> ftpsync.conf) to the new name?  Our monitoring expects this to match the
> hostname on the mirrors list.
>
> Thanks,
> Julien
>
> On Tue, Apr 05, 2022 at 03:07:45PM +, NYCU CSIT wrote:
> > Package: mirrors
> > Severity: minor
> > User: mirr...@packages.debian.org
> > Usertags: mirror-list
> >
> > Submission-Type: update
> > Site: debian.cs.nctu.edu.tw
> > Type: leaf
> > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > Archive-http: /debian/
> > Archive-rsync: debian/
> > Maintainer: NYCU CSIT 
> > Country: TW Taiwan
> > Location: Asia Taiwan
> > Sponsor: IT Center, Department of Computer Science, National Yang Ming
> Chiao Tung University https://it.cs.nycu.edu.tw/
> > Comment: Hi,
> >  we would like to change our mirror domain name and contact information
> due to our school being merged with NYMU into NYCU (National Yang Ming
> Chiao Tung University).
> >
> >  The following is our new information, and we also have enabled https
> support additionally:
> >  http: http://debian.cs.nycu.edu.tw
> >  https: https://debian.cs.nycu.edu.tw
> >  rsync (debian): rsync://debian.cs.nycu.edu.tw/debian/
> >
> >
> >
> >
> > Trace Url: http://debian.cs.nctu.edu.tw/debian/project/trace/
> > Trace Url:
> http://debian.cs.nctu.edu.tw/debian/project/trace/ftp-master.debian.org
> > Trace Url:
> http://debian.cs.nctu.edu.tw/debian/project/trace/debian.cs.nctu.edu.tw
> >
>

Bug#1020919: socat: FTBFS on hurd-i386

[Svante Signell]

Source: socat
Version: 1.7.4.3-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Cc: bug-hurd

Hi,

Currently socat FTBFS on GNU/Hurd due to differing values for O_RDONLY,
O_WRONLY and O_RDWR compared to Linux systems.

The attached patch, xioinitialize.c.patch, fixes the build problem.
Unfortunately, since util-linux build-depends on socat, that package
cannot be built.

A problem is that socat depends on netstat or ip to function properly,
and is used in the tests, not being available for GNU/Hurd. So building
the package w/o tests is recommended. (No patch is attached to disable
tests in this posting).

Additionally ifconfig is needed for the tests, but probably inetutils-
ifconfig can be used as a replacement. That package just need to add a
link of /usr/bin/inetutils-ifconfig to /sbin/ifconfig.

Thanks!





--- a/xioinitialize.c	2019-04-04 10:59:55.0 +0200
+++ b/xioinitialize.c	2022-09-02 19:20:22.0 +0200
@@ -27,10 +27,15 @@
assert(sizeof(uint32_t)==4);
 
/* assertions regarding O_ flags - important for XIO_READABLE() etc. */
+#ifdef __GNU__
+   assert(O_RDONLY==1);
+   assert(O_WRONLY==2);
+   assert(O_RDWR==3);
+#else
assert(O_RDONLY==0);
assert(O_WRONLY==1);
assert(O_RDWR==2);
-
+#endif
assert(SHUT_RD==0);
assert(SHUT_WR==1);
assert(SHUT_RDWR==2);

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Jonas Smedegaard]

Quoting Lev Lamberov (2022-09-28 09:35:00)
> Since now SWI-Prolog in Debian supports setting an arch-independent path
> to the interpreter (8.4.3+dfsg-1, uploaded on 2022-09-18, in testing
> since 2022-09-21), I'm reassigning this bug report to eye. The eye
> package needs rebuild against the mentioned new swi-prolog version using
> something like this command:
> 
> swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl

Thanks for reminding me.  I'll look at it shortly...

 - Jonas

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

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

signature.asc
Description: signature

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 4:12 PM, Sebastian Ramacher wrote:
> On 2022-09-27 10:26:36 -0400, Zack Weinberg wrote:
>> On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote:
>> >> I'd like to make sure that the bug submitter has not identified
>> >> something new here.
>> >
>> > I've not seen any new issues appearing since the last round I file bugs.
>>
>> I wasn’t aware that you have been filing bugs related to the
>> transition.  What criteria are you using to find and file those bugs?
>
> I only checked for packages violating the moratorium. Thankfully a check
> for that was implemented by Luca in piuparts. If we have additional
> patterns that could cause issues for upgrades, the check would ideally
> be extended with that information.

I thought about this a bunch yesterday evening and I believe I see a
concrete scenario that can cause problems but is not covered by the
moratorium: Suppose there exist two packages, one of which ships
/bin/foo, and the other ships /usr/bin/foo.  On a non-merged system,
these packages can coexist.  On a merged system, they have a file
conflict that dpkg will not detect.

For practical reasons I doubt that two such packages actually exist --
nobody wants the concrete implementation of "foo" to be selected by
what order the user happened to list /usr/bin and /bin in their PATH,
this is what alternatives are for -- but, I don't see anything in
Policy that *forbids* it outright.  (I could have missed something.)
Also, the undetected file conflict can happen in *any* directory that
is converted to a symlink on a merged system, and  it's at least
vaguely plausible to me that there might be packages shipping
small variations on the same library as /lib/foo.so and /usr/lib/foo.so
(perhaps one has fewer dependencies, to be used during early boot).

So questions for you and everyone else reading this:

1. Is there already a rule (or multiple rules) somewhere that forbids
   the existence of pairs of packages where one ships /X/Y and the
   other ships /usr/X/Y, where X is a directory on non-merged-/usr
   systems and a symlink on merged-/usr systems, and Y is any name?

2. Does Debian already have tooling that can *find* pairs of such
   packages?  (This is a fully independent question from 1.  If
   there's a rule but no automation to enforce it then we don't *know*
   nobody's breaking the rule.  If there is no rule then, before we
   consider adding such a rule, we need to know whether any packages
   exist that break it.)

zw

Bug#1020918: doxygen: FTBFS on hurd-i386

[Samuel Thibault]

Svante Signell, le mer. 28 sept. 2022 18:09:58 +0200, a ecrit:
> On Wed, 2022-09-28 at 17:50 +0200, Samuel Thibault wrote:
> > Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514
> > 
> > Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit:
> > > Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.
> > 
> > This issue was already forwarded upstream on
> > https://github.com/doxygen/doxygen/pull/9514
> > 
> > they said it was actually imported from another project:
> > https://github.com/gulrak/filesystem/pull/154
> > 
> > In the meanwhile we already have patched version 1.9.4-2+hurd.1
> > available in unreleased.
> 
> Thanks, I did not know about this. Maybe you can create a version
> 1.9.4-3.hurd.1 version to avoid doxygen-latex not being held when
> upgrading.

Well, I could do that but that would be moot whenever a newer
doxygen package gets uploaded again.

Samuel

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote:
> On 2022-09-27 Zack Weinberg  wrote:
> [...]
>> What I am asking for is a schedule change: specifically, that the
>> merged /usr transition not be allowed to proceed past the status quo
>> as of two weeks ago (i.e. *before* init-system-helpers added a
>> dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
>> fixed to the satisfaction of the dpkg maintainers.
> [...]
>
> Hello Zack,
>
> Afaiui the only thing the change two weeks caused is an increased
> percentage of usrmerged Debian installations.

It is *conceivable* that a system that has been *converted* to
merged-/usr, in the way usrmerge does it, is different from a system
that was originally installed with merged /usr, in a way that matters
to whether the dpkg bugs can be triggered on that system.  I thought I
had come up with just such a scenario yesterday, in fact.  On further
consideration I was wrong -- but that doesn't mean there are no such
scenarios.

However:

> Afaict the problem is unchanged: There is a very large number of
> usrmerged systems (every system installed with bullseye installer or
> newer unless some very specific steps were taken to avoid this) which
> are prone to bugs due to dpkg not having been changed *first*. This
> number is of usrmerged systems is so large that we cannot mark them as
> unsupported ("Please reinstall"). Whether this percentage is 25% or 90%
> does not matter.

I basically agree with this assertion.  For instance, I think it's not
realistic to roll back every such system to an un-merged state, and
then restart the entire transition, this time following the procedure
that was used when /usr/man was moved to /usr/share/man, which is, it
appears to me, what Guillem would ideally like to have happen.

(I will point out, though, that if we had done it that way starting in
2015 or even 2017, *we would be done by now*, since that process takes
exactly three releases to complete.)

If I had had the authority to make the relevant decision at the time,
I probably would have insisted on getting the dpkg bugs fixed before
the installer's default could be changed.  But that ship has sailed.

However, I think there's still value from a process-management
perspective in declaring that non-merged systems may not be converted,
and are to remain supported, until all critical components of the
distribution -- in particular dpkg -- fully support the merged state.
For instance, it means that the proponents of the transition have a
concrete incentive to get *all* of the remaining work done, and not
just the piece that matters to them.

zw

Bug#1020918: doxygen: FTBFS on hurd-i386

[Svante Signell]

On Wed, 2022-09-28 at 17:50 +0200, Samuel Thibault wrote:
> Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514
> 
> Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit:
> > Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.
> 
> This issue was already forwarded upstream on
> https://github.com/doxygen/doxygen/pull/9514
> 
> they said it was actually imported from another project:
> https://github.com/gulrak/filesystem/pull/154
> 
> In the meanwhile we already have patched version 1.9.4-2+hurd.1
> available in unreleased.

Thanks, I did not know about this. Maybe you can create a version
1.9.4-3.hurd.1 version to avoid doxygen-latex not being held when
upgrading. (when upgrading/dist-upgrading it is very annoying to see
these messages).

Thanks again, your solution is much better than mine (though very
similar).

thanks!

Bug#1020918: doxygen: FTBFS on hurd-i386

[Samuel Thibault]

Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514

Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit:
> Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.

This issue was already forwarded upstream on
https://github.com/doxygen/doxygen/pull/9514

they said it was actually imported from another project:
https://github.com/gulrak/filesystem/pull/154

In the meanwhile we already have patched version 1.9.4-2+hurd.1
available in unreleased.

Samuel

Bug#1020592: [Pkg-javascript-devel] Bug#1020592: Bug#1020592: nodejs: Testsuite is using smoil keys

[Jérémy Lal]

Le ven. 23 sept. 2022 à 23:21, Jérémy Lal  a écrit :

>
>
> Le ven. 23 sept. 2022 à 23:03, Sebastian Andrzej Siewior <
> sebast...@breakpoint.cc> a écrit :
>
>> control: found -1 odejs/18.7.0+dfsg-5
>>
>> On 2022-09-23 22:55:23 [+0200], Jérémy Lal wrote:
>> > Thanks, I'm already aware of the need to run nodejs testsuite using
>> > their own specific openssl.cnf.
>> > It seems you are reporting a bug against a version of nodejs that has
>> never
>> > made it
>> > to debian. Did you mean to report to ubuntu or some other distribution
>> > instead ?
>> > If that's the case please close this bug and open a new one at the right
>> > place.
>>
>> Ehm. It seems I forgot a 1 while copy paste. The current openssl version
>> in unstable is blocked due that reason:
>> |   autopkgtest for nodejs/18.7.0+dfsg-5: amd64: Regression
>>
>> so I think I am at the right place ;)
>>
>
> I'll upload nodejs 18.9.1 this week-end, along with a/your fix for that
> issue.
>

Sorry for the delay,
while your patch helps for some tests, some others just fail because of
weak keys.
It happens that upstream has upgraded its test suite keys.
I have troubles figuring out how to merge upstream patch - quilt doesn't
support binary git diff :(

But the fix is coming, soon.

Jérémy


> Jérémy
>
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#1019218: snakeyaml: CVE-2022-25857

[Salvatore Bonaccorso]

Hi Tony

Thanks for the update.

On Wed, Sep 28, 2022 at 08:30:07AM -0700, tony mancill wrote:
> On Tue, Sep 27, 2022 at 05:41:21PM +0200, Salvatore Bonaccorso wrote:
> > > snakeyaml 1.31 has been uploaded to unstable.  I will start work on
> > > 1.33, which addresses other non-DSA CVEs [1].
> 
> Hello Salvatore,
> 
> After reviewing the remaining CVEs more closely, I believe I missed
> documenting CVE-2022-38749 as resolved by the 1.31 upload.
> 
> CVE-2022-38749
> 
> https://nvd.nist.gov/vuln/detail/CVE-2022-38749 states that the issue
> exists in versions up to (excluding) 1.31, implying that it was addressed
> in 1.30.
> 
> The state of CVE-2022-38752 is more nuanced.
> 
> CVE-2022-38752
> 
> https://nvd.nist.gov/vuln/detail/CVE-2022-38752 states that the issue
> exists in versions up to (excluding) 1.32, implying that it was addressed
> in 1.31.  However, upstream [1] claims this as a false-positive and
> has addressed it by adding a unit-test [2] in 1.32.
> 
> Therefore, I don't believe version 1.31 is actually impacted.  However,
> in order to keep the security scanners happy and because upstream has
> done a lot of code reformatting between 1.31 and 1.33 (which would make
> porting future patches more difficult), I still intend update 1.33 after
> completing the usual vetting (r-deps build, japi-compliance-checker
> check, etc.)

We have to actually be quite cautious about the CVE descriptions. They
might not be accurate describing the affected versions and often only
reflect a given point in time. Not mentioning a version as affected
might just be that the version was not yet released or other reasons.
So when evaluation a CVE we can have the hints from the descriptions
but actually never rely on it but investigate based on the source,
issues, reports, etc.

That said, thanks for the above information, will try to look and as
needed then update accordingly the tracker.

Thank you!

Regards,
Salvatore

Bug#1020918: doxygen: FTBFS on hurd-i386

[Svante Signell]

Source: doxygen
Version: 1.9.4-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.

The attached patch, filesystem_filesystem.hpp.diff, fixes the build
problem by special-casing for Hurd. In fact the patch could be applied
to all glibc-based systems and upstreamed. 

However, it is not very C++-ish, maybe some better solution could be
used. Cc-ing bug-hurd for comments, WDYT?

Thanks!




Index: doxygen-1.9.4/filesystem/filesystem.hpp
===
--- doxygen-1.9.4.orig/filesystem/filesystem.hpp
+++ doxygen-1.9.4/filesystem/filesystem.hpp
@@ -56,6 +56,8 @@
 #define GHC_OS_MACOS
 #elif defined(__linux__)
 #define GHC_OS_LINUX
+#elif defined(__GNU__)
+#define GHC_OS_GNU
 #if defined(__ANDROID__)
 #define GHC_OS_ANDROID
 #endif
@@ -4081,6 +4083,13 @@ GHC_INLINE path current_path(std::error_
 return path();
 }
 return path(std::wstring(buffer.get()), path::native_format);
+#elif defined(GHC_OS_GNU)
+char* buffer = ::getcwd (NULL, 0);
+if (buffer == nullptr) {
+ec = detail::make_system_error();
+return path();
+}
+return path(buffer);
 #else
 size_t pathlen = static_cast(std::max(int(::pathconf(".", _PC_PATH_MAX)), int(PATH_MAX)));
 std::unique_ptr buffer(new char[pathlen + 1]);

Bug#1020330: pipewire-pulse: Conflict with pulseaudio is badly resolved by apt full-upgrade

[Amr Ibrahim]

Package: pipewire-pulse
Version: 0.3.57-1
Followup-For: Bug #1020330

Hello,

I'm on Debian testing, and I think I have to wait to first upgrade gnome-core
to 1:42+8 in testing before upgrading pipewire to 0.3.58-2 in testing,
otherwise pipewire-pulse will get removed. I don't mind having pulseaudio
removed though.

pipewire 0.3.58-1 should probably have not been uploaded in unstable before
gnome-core 1:42+8, but meh! It is what it is!

Best,
Amr


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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.57-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.57-1
ii  pulseaudio-utils  16.1+dfsg1-2

-- no debconf information

Bug#1019218: snakeyaml: CVE-2022-25857

[tony mancill]

On Tue, Sep 27, 2022 at 05:41:21PM +0200, Salvatore Bonaccorso wrote:
> > snakeyaml 1.31 has been uploaded to unstable.  I will start work on
> > 1.33, which addresses other non-DSA CVEs [1].

Hello Salvatore,

After reviewing the remaining CVEs more closely, I believe I missed
documenting CVE-2022-38749 as resolved by the 1.31 upload.

CVE-2022-38749

https://nvd.nist.gov/vuln/detail/CVE-2022-38749 states that the issue
exists in versions up to (excluding) 1.31, implying that it was addressed
in 1.30.

The state of CVE-2022-38752 is more nuanced.

CVE-2022-38752

https://nvd.nist.gov/vuln/detail/CVE-2022-38752 states that the issue
exists in versions up to (excluding) 1.32, implying that it was addressed
in 1.31.  However, upstream [1] claims this as a false-positive and
has addressed it by adding a unit-test [2] in 1.32.

Therefore, I don't believe version 1.31 is actually impacted.  However,
in order to keep the security scanners happy and because upstream has
done a lot of code reformatting between 1.31 and 1.33 (which would make
porting future patches more difficult), I still intend update 1.33 after
completing the usual vetting (r-deps build, japi-compliance-checker
check, etc.)

Thank you,
tony

[1] 
https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081#comment-64048637
[2] 
https://bitbucket.org/snakeyaml/snakeyaml/commits/481078991274c1c8a0a550634164a230b4c23334


signature.asc
Description: PGP signature

Bug#1020917: debos: Please package new upstream release 1.1.0

[Manuel Traut]

Package: debos
Version: 1.0.0+git20210707.c66a48d-2+b2
Severity: normal
X-Debbugs-Cc: manuel.tr...@mt.com

Dear Maintainer,

there is a new upstream version that fixes some known issues.
It would be nice to have this version in Debian (bookworm)

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

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

Versions of packages debos depends on:
ii  busybox1:1.35.0-2
ii  debootstrap1.0.127
ii  libc6  2.34-8
ii  libglib2.0-0   2.74.0-1
ii  libostree-1-1  2022.5-3
ii  qemu-system-x861:7.1+dfsg-2
ii  qemu-user-static   1:7.1+dfsg-2
ii  systemd-container  251.4-3

Versions of packages debos recommends:
ii  bmap-tools 3.6-1
ii  bzip2  1.0.8-5+b1
ii  e2fsprogs  1.46.6~rc1-1
ii  linux-image-amd64  5.19.6-1
ii  mount  2.38.1-1
ii  ovmf   2022.08-1
ii  parted 3.5-2
ii  udev   251.4-3
ii  xz-utils   5.2.5-2.1
ii  zip3.0-12

debos suggests no packages.

-- no debconf information

Bug#1020396: systemd-boot: kernel installation/initrd update hooks double the initrd like #970213 since #826045

[Michael Biebl]

Control: tags -1 + pending

Supposed to be fixed by
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/170

So marking as pending

Michael

On Wed, 21 Sep 2022 03:25:48 +0200 =?utf-8?B?0L3QsNCx?= 
 wrote:

Package: systemd-boot
Version: 251.4-3
Severity: normal
Tags: patch

Dear Maintainer,

In the default installation, both a bare initrd and a versioned one are
installed:
  /boot/efi/HASH/5.16.0-1-amd64/initrd.img-5.16.0-1-amd64
  /boot/efi/HASH/5.16.0-1-amd64/linux
  /boot/efi/HASH/5.16.0-1-amd64/initrd

In #970213, I worked around this by only installing the generated
as the standard "initrd" fallback if none was passed;
I've been using a simple 
  #!/bin/sh

  bootctl is-installed > /dev/null || exit 0
  exec kernel-install add "$1" "/boot/vmlinuz-$1" "/boot/initrd.img-$1"
/etc/kernel/postinst.d/kernel-install (and analogous remove),
so this works for that case perfectly.

In #826045, upstream hooks were added:
  debian/extra/kernel/post{inst,rm}.d/systemd-boot
  (74127387dacf23f037f3a55a808951fae93024c6)
and
  debian/extra/initramfs/post-update.d/systemd-boot
  (9a6d87f1c6f7fbde8ff8e7beab30973944221244)
to integrate with bootctl out-of-box. This is great!

However, /etc/kernel/postinst.d/systemd-boot runs:
  kernel-install add "$1" "$2"
and /etc/initramfs/post-update.d/systemd-boot runs:
  kernel-install add "$1" "/boot/vmlinuz-$1" "$2"

And the former installs:
  /boot/efi/HASH/5.16.0-1-amd64/linux
  /boot/efi/HASH/5.16.0-1-amd64/initrd
but the latter installs:
  /boot/efi/HASH/5.16.0-1-amd64/initrd.img-5.16.0-1-amd64
  /boot/efi/HASH/5.16.0-1-amd64/linux
hence the situation at the top I wanted to avoid in #970213;
ESPs tend to be really small!

I've opened MR 169 on Salsa:
  https://salsa.debian.org/systemd-team/systemd/-/merge_requests/169
and am attaching a patch for this that makes it so
/etc/kernel/postinst.d/systemd-boot calls 
  kernel-install add "$1" "$2" "/boot/initrd.img-$1"

if the latter exists, and the previous
  kernel-install add "$1" "$2"
otherwise, which always installs the versioned initrd,
as well as one that will order this bootloader hook
with the other bootloader hooks at the end (cf. message).


Installation logs that demonstrate this follow.

Implicit image:
  root@zoot2:~# kernel-install -v add $(uname -r) /boot/vmlinuz-5.16.0-1-amd64


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020916: RFP: libcommons-imaging-java -- Apache Commons Imaging - Pure-Java Image Library

[Thomas Uhle]

Package: wnpp
Severity: wishlist
Control: block 983715 by -1
X-Debbugs-CC: Debian Java Maintainers 


* Package name: libcommons-imaging-java
  Version : 1.0-alpha3
  Upstream Author : The Apache Software Foundation
* URL or Web page : https://commons.apache.org/imaging/
* License : Apache 2.0
  Description : Apache Commons Imaging - Pure-Java Image Library

Apache Commons Imaging is a library that reads and writes a variety of 
image formats, including fast parsing of image information (size, color 
space, ICC profile, etc.) and metadata.
This library is pure Java. Compared to typical image I/O libraries in 
native code, it is more portable, and should be more reliable and more 
secure against corrupt/malicious images, yet still performs reasonably 
well. It is easier to use than ImageIO/JAI/java.awt.Toolkit (Sun/Java's 
image support), supports more formats (and supports them more 
correctly). It also provides easy access to metadata.




Dear maintainers,

this library is needed for a complete build of libitext5-java that 
also includes itext-extra (cf. https://bugs.debian.org/983715).


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1020637: RM: netkit-tftp -- RoQA; orphaned, tftp transitioned to tftp-hpa

[Salvatore Bonaccorso]

Hi Bastian,

On Wed, Sep 28, 2022 at 05:08:01PM +0200, Bastian Germann wrote:
> On Sat, 24 Sep 2022 17:35:48 +0200 Salvatore Bonaccorso  
> wrote:
> > As per #1020629 src:netkit-tftp is orphaned: tftp built from it is
> > already a transitional package to tftp-hpa. tftpd was not transitioned
> > itself to tftpd-hpa, but Alberto mentioned in #1020629 that it might
> > be the better option to remove src:netkit-tftp.
> 
> The source package should not be removed before the booworm release because 
> the transitional
> package has not been in a release yet.
> 
> If you want the binary tftpd to be removed without a transition just 
> QA-upload the package
> with that tftpd removed and let the cruft automation delete it from the 
> archive.

Ah yes this makes perfectly sense. So let's keep netkit-tftp until
after the bookworm release.

Thanks for spotting the thinko :)

Regards,
Salvatore

Bug#1017073: python-suntime: reproducible builds: Timestamps recorded for all packaged files

[James Addison]

Source: python-suntime
Followup-For: Bug #1017073
X-Debbugs-Cc: j...@jp-hosting.net
Control: close -1 1.2.5-5

The package's changelog format is valid again in salsa following a refresh[1] 
that re-combined a divergent development history.  Release 1.2.5-5 looks good 
in terms of build reproducibility.

[1] - 
https://salsa.debian.org/python-team/packages/python-suntime/-/commit/683a9656a89bdcade60fa6c8b839026fdf23f1e1